Создание диаграммы IDEF1X в среде AllFusion ERwin Data Modeler

⇐ ПредыдущаяСтр 6 из 9Следующая ⇒

Рассмотрим в качестве предметной области предприятие, в структуре которого имеются отделы, и спроектируем БД для хранения сведений о служащих, работающих в отделах, и их детях. Основные сущности будут следующие: СОТРУДНИК, ОТДЕЛ, РЕБЕНОК.

1. Для создания новой модели запустите Erwin, выберете File à New. В результате появится диалоговое окно, представленное на рис. 1.26.

рис. 1.26. Диалоговое окно создания новой модели

В данном окне установите переключатель на Logical/Physical. Это будет означать, что в данном примере будет создана как логическая модель данных, так и соответствующая ей физическая модель данных для СУБД Access.

2. Для создания сущности кликните на значок на панели инструментов. Задайте имя сущности: СОТРУДНИК.

3. Для определения атрибутов щелкните правой кнопкой мыши по сущности и выберете в контекстном меню пункт Attributes. Появится диалоговое окно, представленное на рис. 1.27.

рис. 1.27. Диалоговое окно редактирования атрибутов сущности

Щелкните по кнопке New… для создания нового атрибута. В появившемся диалоговом окне укажите тип данных (Number), имя атрибута для отображения на логической модели (Attribute Name: Табельный номер), название колонки для отображения на физической модели (Column Name: EmpID). Далее для сущности СОТРУДНИК создайте еще атрибуты согласно данным, приведенным в Таблица 1.6.

Таблица 1.6

Структура сущности СОТРУДНИК

Имя атрибута	Название колонки	Тип данных
Табельный номер	EmpID	Number
Фамилия	Familyname	String
Имя	Name	String
Дата рождения	Birthday	Datetime
Адрес	Address	String
Пол	Gender	String

4. В качестве первичного ключа укажите Табельный номер (рис. 1.28).

рис. 1.28. Определение первичного ключа

Результат выполнения данного этапа представлен на рис. 1.29.

рис. 1.29.сущность СОТРУДНИК

По аналогии создайте сущности ОТДЕЛ и РЕБЕНОК согласно данным, представленным в Таблица 1.7 и Таблица 1.8.

Таблица 1.7

Структура сущности ОТДЕЛ

Имя атрибута	Название колонки	Тип данных
Номер отдела	DepID	Number
Название отдела	DepName	String

Таблица 1.8

Структура сущности РЕБЕНОК

Имя атрибута	Название колонки	Тип данных
Код ребенка	ChildID	Number
Имя ребенка	ChildName	String
Дата рождения ребенка	ChildDate	Datetime

После создания сущностей необходимо задать связи между ними.

5.Сущности СОТРУДНИК и ОТДЕЛ будут связаны неидентифицирующей связью «один-ко-многим» (в данном примере в одном отделе работает несколько сотрудников, но каждый сотрудник числится только в одном отделе). Для этого необходимо щелкнуть по кнопке на панели инструментов, далее кликнуть мышкой по сущности ОТДЕЛ (сторона «один»), а затем по сущности СОТРУДНИК (сторона «многим»). В сущности СОТРУДНИК появился новый атрибут Номер отдела, который является внешним ключом.

Несмотря на то, что каждый служащий “подчинен” отделу, он идентифицируется своим табельным номером независимо от отдела, в котором работает. Так как при установлении неидентифицирующей связи, первичный ключ сущности ОТДЕЛ мигрирует в состав непервичных атрибутов сущности СОТРУДНИК. Независимая сущность изображается в виде прямоугольного блока, внутри которого указан список атрибутов.

6.Сущности СОТРУДНИК и РЕБЕНОК будут связаны идентифицирующей связью «один-ко-многим». Для этого необходимо щелкнуть по кнопке на панели инструментов, далее кликнуть мышкой по сущности СОТРУДНИК (сторона «один»), а затем по сущности РЕБЕНОК (сторона «многим»). В сущности РЕБЕНОК появился новый атрибут Табельный номер, который является внешним ключом и входит в состав первичных атрибутов данной сущности. Таким образом сущность РЕБЕНОК является зависимой, т.е. невозможно добавить в таблицу новую запись о ребенке, не зная информации о его родителе. Зависимая сущность - это сущность, однозначная идентификация экземпляра которой зависит от его подчиненности другой сущности. Зависимая сущность изображается в виде блока с закругленными углами.

Результат создания связей между сущностями приведен на рис. 1.30.На данном рисунке отображена логическая модель данных, а соответствующая ей физическая модель данных представлена на рис. 1.33.

рис. 1.30. Результат создания связей между сущностями

Согласно медологии IDEF1X необходимо задать имена связей между сущностям. Связи именуются глаголами. В нашем случае связи будут именоваться следующим образом:

· СОТРУДНИК имеет РЕБЕНКА,

· РЕБЕНОК принадлежит СОТРУДНИКУ,

· ОТДЕЛ состоит из СОТРУДНИКОВ,

· СОТРУДНИКИ принадлежат ОТДЕЛУ.

Для задания имени связи необходимо вызвать контекстное меню связи и выбрать пункт Relationship Properties. Появится диалоговое окно, представленное на рис. 1.31. В появившемся диалоговом окне, находясь во вкладке General, в области Verb Phrase вводятся имена связи в обоих направлениях. В данном примере для связи СОТРУДНИК-РЕБЕНОК в поле Parent-to-Child указываем имя имеет, а в поле Child-to-Parent – принадлежит.

рис. 1.31.Диалоговое окно Relationship

Аналогичным образом задаем имена для связи СОТРУДНИК-ОТДЕЛ.

По умолчанию имя связи на диаграмме не показывается. Для отображения имени связи следует в контекстном меню поля диаграммы выбрать пункт меню Relationship Display и затем щелкнуть Verb Phraze. Результат представлен на рис. 1.32.

рис. 1.32. Логическая модель данных с именованным связями

На данном рисунке отображена логическая модель данных, а соответствующая ей физическая модель данных представлена на рис. 1.33.

рис. 1.33.Физическая модель данных

В результате выполнения данного пункта получили инфологическую модель базы данных и соотвествующую ей физическую модель данных, которая является отображением системного каталога выбранной нами СУБД.

Задание правил валидации и значений по умолчанию

На этапе создания физической модели данных вводятся правила валидации колонок, определяющие списки допустимых значений и значения по умолчанию. Правило валидации задает список допустимых значений и/или правила проверки допустимых значений. Значение по умолчанию – значение, которое нужно ввести в колонку, если никакое другое значение не задано явным образом во время ввода данных.

Для задания правил валидации необходимо, находясь в режиме редактирования физической модели данных, вызвать контекстное меню необходимой таблицы, выбрать пункт меню Columns, в появившемся диалоговом окне Columns выбрать название нужной колонки, перейти во вкладку Constraint и там щелкнуть по кнопке в области Validation Constraint. Появится диалоговое окно, представленное на рис. 1.34.

рис. 1.34.Диалоговое окно для создания правил валидации

К примеру, зададим, что дата рождения сотрудника должна быть в пределах 01/01/1920 и 01/01/1990. Для этого в появившемся диалоговом окне щелкнем на кнопке New. В результате появится диалоговое окно для задания имени нового правила валидации (рис. 1.35).

рис. 1.35.Задание имени для нового правила валидации

После задания имени для правила валидации в окне Validation Rules во вкладке General выберем Min/Max и укажем соответствующий диапазон ( рис. 1.36 ).

рис. 1.36.Задания правила валидации для проверки возраста

После создания правила валидации проассоциируем его с необходимой нам колонкой (в данном случае – Birthday). Результат представлен на рис. 1.37.

рис. 1.37. Результат создания правила валидации для колонки Birthday

По аналогии для колонки Gender зададим список допустимых значений: «М» и «Ж». Для этого, во-первых, необходимо создать новое правило валидации для соответствующей колонки. Далее во вкладке General диалогового окна Validation Rules необходимо установить переключатель на Valid Values List и в появившейся таблице Valid Value в колонку Valid Value ввести значения М и Ж.

⇐ Предыдущая 1 2 3 4 567 8 9 Следующая ⇒