Рекомендации при выборе первичного ключа
Первичный ключ должен быть подобран таким образом, чтобы по значениям атрибутов, в него включенных, можно было точно идентифицировать экземпляр сущности.
Никакой из атрибутов первичного ключа не должен иметь нулевое значение.
Значения атрибутов первичного ключа не должны меняться. Если значение изменилось, значит, это уже другой экземпляр сущности.
Рис. 1.5. Диалог New Attribute
При выборе первичного ключа можно внести в сущность дополнительный атрибут и сделать его ключом. Так, для определения первичного ключа часто используют уникальные номера, которые могут автоматически генерироваться системой при добавлении экземпляра сущности в БД.
5. Задайте для сущностей следующие атрибуты
КЛИЕНТ: Фамилия (LastName, String), Имя (FirstName, String), Отчество (Patron, String), Паспорт (NumPasport, String), Учетный номер (NumC, Number), Телефон (Phone, String).
АГЕНТ: Фамилия (LastName, String), Имя (FirstName, String), Отчество (Patron, String), Учетный номер (NumC, Number), Телефон (Phone, String).
ИМУЩЕСТВО: Описание (Decription, String)., Город (City, String), Улица (Street, String), Дом (House, String), Квартира (Appat, String).
СТРАХОВОЙ ДОГОВОР: Дата страхования (DatStrax, DateTime), Страховая сумма (StraxSum, Number).
СТРАХОВАЯ УСЛУГА: Описание (Decription, String), Страховой процент
СТРАХОВОЙ ФАКТОР: Описание (Decription, String), Процент скидки.
Результаты работы показаны на рис. 1.6. Если атрибуты не отображаются в рабочем окне измените уровень просмотра модели (смотри табл. 1.1)
Рис. 1.6. Внесение атрибутов в диаграмму
5. Определите связи между сущностями. Напомним, что для задания связи между двумя сущностями необходимо указать имя связи, тип связи, направление связи (родительская и дочерняя сущности), мощность связи, допустимость пустых (null) значений, требования по обеспечению ссылочной целостности, а в некоторых случаях и роль.
Неидентифицирующая связь служит для связывания независимых сущностей.
При концептуальном проектировании были выявлены следующие связи.
· Клиент заключает Страховой договор.
· Агент обслуживает Страховой договор.
· Имущество страхуется в Страховом договоре.
· Страховая услуга указывается в Страховом договоре
· Страховой фактор учитывается в Страховом договоре.
Все пять связи являются связями «один-ко-многим». Во всех случаях сущность СТРАХОВОЙ ДОГОВОР является дочерней.
Все связи неидентифицирующие, т.к. любой экземпляр сущности СТРАХОВОЙ ДОГОВОР может быть однозначно идентифицирован по коду сделки, то есть вне зависимости от экземпляров других сущностей.
Все связи, кроме первой, могут иметь мощность 0, 1 или более. Первая и третья связи не могут иметь мощность 0, (любой человек становится КЛИЕНТОМ только тогда, когда он совершает хотя бы один раз страхует свое имущество, аналогично, любая мебель, бытовая техника становится ИМУЩЕСТВОМ только тогда, когда она фигурирует хотя бы в одном страховом договоре).
Во всех связях родительские сущности не могут принимать пустые значения, поскольку при отсутствии экземпляра хотя бы одной из родительских сущностей экземпляр сущности Страховой договор перестает описывать страховое соглашение.
6. Задайте связи между сущностями. Для этого следует:
· установить курсор на нужной кнопке (идентифицирующая или неидентифицирующая связь) в палитре инструментов (смотри табл.1.2) и нажать левую кнопку мыши;
· щелкнуть сначала по родительской, а затем по дочерней сущности.
Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать в контекстном меню пункт Relationship Properties (рис.1.7).
Рис. 1.7. Меню вызова редактора связи.
Во вкладке General появившегося диалога можно задать мощность, имя и тип связи (рис.1.8).
Рис. 1.8. Панель диалога редактора связей
Имя связи (Verb Phrase) – это фраза, характеризующая отношение между родительской и дочерней сущностями. Эти фразы (т.е. имена связей) можно взять непосредственно из связей, которые были получены при концептуальном проектировании.
Для всех связей кроме СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР необходимо указать тип – неиндентифицирующая с указанием опции No Nulls.
Для связи СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР необходимо указать тип связи – неиндентифицирующая с указанием опции Nulls Allowed.
Мощность связи (Cardinality) для всех связей кроме СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР выбирается один или многие (One or More). Для связи СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР указывается мощность 0, 1 или многие.
Задание ограничений ссылочной целостности, а также указание ролей производится на закладке Rolename/RI Action панели диалога редактора связей (смотри рис.1.8).
Имя роли (функциональное имя) – это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности.
Введем следующие имена ролей для связей:
· КЛИЕНТ-СТРАХОВОЙ ДОГОВОР – кто страхуется.
· АГЕНТ-СТРАХОВОЙ ДОГОВОР – кто предоставляет услуги страхования.
· ИМУЩЕСТВО-СТРАХОВОЙ ДОГОВОР – что страхуется.
· СТРАХОВАЯ УСЛУГА-СТРАХОВОЙ ДОГОВОР – от чего страхуется.
· СТРАХОВОЙ ФАКТОР-СТРАХОВОЙ ДОГОВОР – что снижает страховой риск.
Ограничения ссылочной целостности, задаваемые по умолчанию ERwin, в данном случае можно оставить без изменений.
После задания связей между сущностями диаграмма будет выглядеть, как на рис. 1.9.
Рис.1.9. Внесение связей в диаграмму
Контрольные вопросы
1. Сколько уровней имеет логическая модель данных в соответствии с нотацией IDEF1X?
2. Сколько уровней имеет физическая модель данных в соответствии с нотацией IDEF1X?
3. Какие работы выполняются на стадии «Проектирование» жизненного цикла базы данных?
4. Что такое диаграмма сущность-связь?
5. В чем цель диаграммы сущность-связь?
6. Какая связь называется идентифицирующей?
7. Какая связь называется неидентифицирующей?
8. Что включает в себя диаграмма сущность-связь?
9. Какие кнопки панели инструментов позволяют изменить уровень просмотра модели?
10. Как добавить сущность на диаграмму?
11. Что называется сущностью?
12. Сформулируйте принцип именования сущностей.
13. Что показывает взаимосвязь между сущностями?
14. Что такое мощность связи?
15. Что такое имя роли (функциональное имя)?
16. Опишите механизм проверки адекватности логической модели.