КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Этап 1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей.Стр 1 из 2Следующая ⇒ Методология проектирования реляционных баз данных Концептуальное проектирование базы данных Этап 1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей. Построение локальной концептуальной модели данных предприятия с точки зрения представления о функционировании предприятия каждого из существующих типов пользователей. Этап 1.1. Определение типов сущностей. Определение основных типов сущностей, присутствующих в представлении данного пользователя о предметной области приложения. Документирование выделенных типов сущностей. Объектное ядро предметной области образует совокупность объектов, о которых можно задавать вопросы (запросы). Слово "объект" употребляется как синоним слова "реалия". Объект необязательно имеет материальную, "вещную" природу. Термин "объект" является первичным, неопределяемым понятием. Синонимами служат слова тип сущности», "сущность" (Entity), событие (Event). Быть объектом значит быть дискретным и различимым. Данный этап состоит в определении основных объектов, которые могут интересовать пользователя. Эти объекты являются типами сущностей, входящих в модель. Один из методов идентификации сущностей состоит в изучении конкретных функций пользователя на предприятии и извлечении всех используемых в них существительных или сочетаний существительных и прилагательных. Затем среди них выбираются самые крупные объекты или представляющие интерес и исключаются все существительные, которые просто определяют другие объекты. Определяется, являются ли выделенные типы сущностей сильными (независимыми) или слабыми (зависимыми). По отношению к объекту возникает две основных проблемы: идентификация и адекватное описание объекта, определение его свойств. Имена дают способ прямой идентификации объектов. Однако существует много различных способов косвенной идентификации объектов. Косвенная идентификация основана на использовании ключей. Применение ключей зависит от способов описания объекта и тесно связано с конкретной идентификацией. Этап 1.2. Определение типов связей. Определение важнейших типов связей, существующих между сущностями, выделенными на предыдущем этапе. Определение кардинальности связей и ограничений участия его членов. Документирование типов связей. При необходимости могут использоваться диаграммы «сущность-связь» (ER- диаграммы). Одним из методов определения связей является выборка всех глаголов, присутствующих в спецификации на проект. В большинстве случаев связи являются парными, другими словами, связи существуют только между двумя сущностями. Однако следует проявлять осторожность и тщательно проверять наличие в проекте комплексных связей, объединяющих более двух сущностей различных типов, а также рекурсивных связей, существующих между сущностями одного и того же типа. Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей. Связывание атрибутов с соответствующими типами сущностей или связей. Идентификация простых и составных атрибутов, простых и множественных атрибутов, а также производных атрибутов. Документирование сведений об атрибутах. Необходимо выявить все данные, описывающие сущности и связи. Следует выбрать все существительные и содержащие их фразы. Выбранное существительное представляет атрибут в том случае, если оно описывает свойство, качество, идентификатор или характеристику некоторой сущности или связи. Каждому выделенному атрибуту следует присвоить осмысленное имя, понятное пользователям. Для каждого атрибута необходимо определить: · имя атрибута и его описание; · тип данных и размерность значения; · значение, принимаемое для атрибута по умолчанию; · является ли атрибут обязательным (т.е. может ли он отсутствовать или иметь значение NULL); · является ли атрибут составным и, если это так, из каких простых атрибутов он состоит; · является ли данный атрибут производным и, если это так, какой метод следует использовать для вычисления его значения; · является ли данный атрибут множественным. Этап 1.4. Определение доменов атрибутов. Определение доменов для всех атрибутов в каждой локальной концептуальной модели данных. Документирование сведений о доменах атрибутов. Домены должны содержать набор допустимых значений для атрибута и сведения о размере и формате каждого из полей атрибутов. Этап 1.5. Определение атрибутов, являющихся потенциальными и первичными ключами. Определение потенциального ключа для каждого типа сущности, если таких ключей окажется несколько, выбор среди них первичного ключа. Документирование сведений о первичных и альтернативных ключах для каждой сильной сущности. При выборе первичного ключа среди нескольких потенциальных можно руководствоваться следующими рекомендациями: · используйте потенциальный ключ с минимальным набором атрибутов; · используйте тот потенциальный ключ, который имеет минимальную вероятность потери уникальности значений в будущем; · используйте потенциальный ключ, значения которого имеют минимальную длину (в случае текстовых атрибутов); · остановите свой выбор на потенциальном ключе, с которым будет проще всего работать (с точки зрения пользователя). Этап 1.6. Специализация или генерация типов сущностей (необязательный этап). Определение суперклассов и подклассов для типов сущностей. Этап 1.7. Создание диаграммы «сущность-связь». Разработка диаграмм «сущность - связь» (ER- диаграмм), содержащих концептуальное отражение представлений пользователя о предметной области приложения.
Пример построения ER-диаграммы с помощью Microsoft Visio / Chen ERD
Пример построения ER-диаграммы с помощью Microsoft Visio / Database Model Diagramm
Пример использования категоризации Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями. Обсуждение локальных концептуальных моделей данных с конечными пользователя для получения подтверждения того, что данная модель корректно отражает представления пользователя о приложении и предприятии.
|