Еще одним элементом диаграммы «сущность-связь» является отношение.
Отношение в самом общем виде представляет собой связь между двумя сущностями. |
Другими словами:
сущности представляют собой базовые типы информации, хранимой в базе данных,
а отношения показывают, как эти типы данных взаимоувязаны друг с другом.
Введение подобных отношений преследует две основополагающие цели:
обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
использование этой информации различными приложениями.
Связь - это логическое выражение отношений сущностей.
Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис.1).
Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:
Пример 1. Система должна позволять учитывать проекты: определять перечень проектов каждого клиента и перечень проектов, которые выполняет каждый сотрудник.
В этом случае можно именовать связи следующим образом:
Заказчик <Заказывает> проект;
Сотрудник <Выполняет> проект.
Рис.1. Пример имен связей - Relationship Verb Phrases
В данном примере (рис1.) связи показывают, какие именно проекты заказал заказчик и какой именно сотрудник выполняет проект.
1 способ.
Анализируются отношения между объектами предметной области,
причем, только теми объектами, которым соответствуют уже выделенные сущности .
Если информация об этих отношениях востребована в процессе обработки, то она должна быть хранима и, следовательно, в модели будет установлена связь между этими сущностями.
В примере 1 использован именно этот способ (рис 1). Так как надо определять перечень проектов каждого клиента и перечень проектов, которые выполняет каждый сотрудник, то необходимо установить связи между сущностями Заказчик и Проект , а также между сущностями Сотрудник и Проект.
2 способ.
Если в процессе атрибутного анализа из исходной сущности выделяются в самостоятельную сущность часть ее атрибутов (неатомарные или специфические только для группы экземпляров),то связи между исходной и новой сущностями модели устанавливаются обязательно.
Пример 2. Пусть в процессе дополнительного анализа выяснилось, что недостаточно хранить информацию только об одном телефоне заказчика, необходимо знать номера нескольких телефонов, а также их тип (домашний, рабочий, для связи и т.д.).
В этом случае ,по правилам атрибутного анализа, необходимо выделить в отдельную сущность атрибуты телефон и тип телефона, так как они не удовлетворяют сразу нескольким требованиям (телефон , как выяснилось неатомарен, кроме того количество номеров телефонов, которое надо знать для каждого заказчика не является строго определенным - может быть 1, а может быть и больше)(рис.2).
Новая сущность телефон заказчика будет связана с исходной , так как была выделена из нее.
Рис.2 Связь между исходной и выделенной сущностью
Задание 1. Определите в своей модели все пары сущностей, между которыми должны быть установлены связи.
Для каждой связи укажите способ выделения и обоснование ее установления - бизнес правило .
Полученные результаты занесите в свой отчет в раздел "Идентификация связей" ( пример оформления этой части отчета)
Каждая связь в модели должна иметь:
имя;
Правила именования связей.
Имя связи должно быть :
Рис.3. Именование связей.
Задание 2. Определите имена всех связей в своей модели.
В разделе отчета Идентификация связей добавьте и заполните столбец Имя связи ( пример оформления).
Требования к описанию связей
Полное описание каждой связи должно включать:
ERwin поддерживает несколько типов связей:
связи типа «один-ко-многим»:
идентифицирующая
неидентифицирующая;
связь типа
«многие-ко-многим»;
категориальная связь.
Связи «один-ко-многим»
Идентифицирующая и неидентифицирующая связи отражают взаимодействие между двумя сущностями, называемое «один-ко-многим». Это означает, что один экземпляр первой сущности взаимодействует с несколькими экземплярами другой сущности.
Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями.
Обозначение идентифицирующей связи
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи. (рис.4)
Рис.4. Пример обозначения идентифицирующей связи
На рис.4 сущность Проект является зависимой.
Сущность может быть связана одновременно с несколькими сущностями, поэтому может быть зависимой в одной связи и независимой в другой.
Следствие установления идентифицирующей связи
При установлении идентифицирующей связи каждый экземпляр дочерней сущности идентифицируется (распознается) с помощью атрибутов родительской сущности.
Если помнить, что идентификация отдельных экземпляров сущности выполняется с помощью первичного ключа, то становиться понятно, что атрибуты первичного ключа родительской сущности должны входить в состав первичного ключа дочерней сущности.
Мигрировавшие атрибуты называются внешними ключами.
Пример сущностей, связанных идентифицирующей связью приведен на рис 5.
В этом примере в сущности телефон заказчика первичный ключ является составным и содержит код заказчика - атрибут , мигрировавший из сущности Заказчик.
Это вызвано тем, атрибут номер телефона заказчика не может быть первичным ключом сущности телефон заказчика , поскольку не является уникальным (заказчики могут например иметь одинаковые рабочие телефоны). Включение в состав первичного ключа сущности телефон заказчика атрибута код заказчика из сущности Заказчик обеспечивает уникальность нового первичного ключа.
Рис.5. Пример идентифицирующей связи
Внешний ключ обозначается как (FК).
FK является сокращением от Foreign Key (внешний ключ).
На рис.5 - в сущности телефон заказчика внешний ключ-Код заказчика.
Внешний ключ в ERwin создается автоматически при установлении связи между сущностями.
Внешний ключ удаляется из сущности только при удалении связи, породившей его.
Для отображения связи необходимо:
Пусть при анализе предметной области было установлено, что у заказчика может быть несколько проектов. Причем информация о том, кто заказал проект, востребована, следовательно должна быть хранима.
Вывод: Между сущностями Заказчик и проект должна быть установлена связь.
По определению, идентифицирующая связь устанавливается, если экземпляр одной сущности идентифицируется через ее связь с другой сущностью.
Пусть в нашем примере номера проектов состоят из 2 частей - кода заказчика и номера проекта у этого заказчика (например, номер третьего проекта у второго заказчика выглядит как 2.3).
Вывод: Можно использовать идентифицирующую связь, так как проекты идентифицируются только через своих заказчиков.
Для установления правильного направления связи необходимо проанализировать правила и ограничения предметной области и определить, какая из сущностей идентифицируется с помощью другой. К сожалению, это не всегда очевидно, как в нашем примере.
В случае затруднений воспользуйтесь следующими рекомендациями:
количество экземпляров первой сущности | количество экземпляров второй сущности |
1 проект | 1 заказчик |
1 заказчик | N проектов |
Для нашего примера 1 заказчик - N проектов.
Вывод: Родительская сущность - Заказчик( именно он "подарит" свой первичный ключ сущности проект).
Проект будет в результате дочерней, зависимой сущностью.
Неправильный выбор направления связи приведет к нарушению принципа атомарности атрибутов .
В нашем примере выбор сущности Проект в качестве родительской приведет к миграции ее первичного ключа (Номер проекта) в область первичных ключей сущности Заказчик(рис.6).
В этот атрибут нужно будет записать каждому заказчику номера всех проектов, выполняемых для него (а у него их может быть много!) - налицо нарушение!
Рис.6. Неправильный выбор направления связи
Для того, чтобы установить идентифицирующую связь, выполните следующие шаги:
Откройте сохраненный Вами файл Lab2.(если файл утерян, то воспользуйтесь файлом модели\3\ex3)
Выберите тип создаваемого элемента –
идентифицирующая связь с помощью кнопки
в палитре инструментов;
Щелкните мышкой сначала по родительской сущности Заказчик, а затем по дочерней сущности Проект.
Идентифицирующая связь отобразится на диаграмме сплошной линией с жирной точкой на дочернем конце связи, то есть на сущности Проект.
При установлении идентифицирующей связи (Рис.7) атрибуты первичного ключа Код заказчика родительской сущности Заказчик автоматически переносятся в состав первичного ключа дочерней сущности Проект. В дочерней сущности Проект новый атрибут помечается как внешний ключ - (FK).
Рис.7. Идентифицирующая связь между независимой и зависимой сущностью
Отображение внешних ключей
Если внешние ключи не отображаются, то измените режим отображения сущностей, используя пункт контекстного меню Entity Display(рис.8)
Рис.8. Изменение режима отображения внешних ключей
Отображение миграции атрибутов при установлении связей
Если при установлении связи миграция атрибутов не отображается, то измените режим отображения сущностей, используя пункт контекстного меню Entity Display (рис.9)
Рис.9. Изменение режима отображения миграции атрибутов.
Именование связи
Для того, чтобы задать имя связи выполните следующие действия:
Щелкните правой кнопкой мыши по связи, в меню выберите пункт Relationship Properties (рис.10)
Рис. 10. Вызов диалога Relationships
В появившемся диалоге Relationships в поле Parent-to-Child (родитель - ребенок) введите имя связи Заказывает (рис. 11).
Имя будет характеризовать отношение от родительской сущности Заказчик к дочерней сущности Проект .
Рис.11. Диалог Relationships
Задание 3. Самостоятельно задайте имя связи от сущности проект к сущности заказчик - принадлежит.
Для отображения имени связи в модели измените режим отображения связей(рис.12).
Рис.12. Изменение режима отображения связей
6. Мощность связи
Мощность связи (Cardinality) – представляет собой соотношение количества экземпляров родительской сущности к количеству экземпляров дочерней сущности.
В случае связи типа "один-ко-многим" :
Мощность показывает какое количество экземпляров дочерней сущности связано с одним экземпляром родительской сущности.
Различают четыре типа мощности:
Для этого необходимо :
Пусть, в ходе анализа предметной области было выяснено, что Заказчик может заказать выполнение нескольких проектов, но регистрация заказчика выполняется только после оформления договора на выполнение первого проекта .
Вывод: Заказчик должен иметь хотя бы 1 проект или много проектов, следовательно - мощность данной связи - 1 или много, то есть Р.
Рис.13. Вызов диалога для изменения свойств связи
В появившемся окне диалога на вкладке General в поле Cardinality установите тип мощности (в нашем случае это тип One or More)(рис.14)
Рис. 14. Установление типа связи
Для отображения мощности в модели измените режим отображения связей(рис.15)
Рис.15. Изменение режима отображения мощностей
Результат, который Вы получите должен выглядеть примерно также, как на рис.16.
Рис.16. Отображение имени и мощности связи.
7. Описание связи
Для описания связи :
Рис.17. Вызов диалога для изменения свойств связи
В появившемся окне диалога на вкладке Definition введите описание связи - бизнес правила , касающиеся отношения, которое она выражает (рис.18)
Рис. 18. Описание связи.
Сохраните модель в файле Задание3_5 в своей папке.
Удаление связи
Для удаления связи необходимо:
выделить связь (щелчком левой кнопки мыши) ;
воспользоваться клавишей Delete;
в появившемся окне подтвердить удаление (рис.19)
Рис.19. Окно запроса об подтверждении удаления связи.
Сохраните модель в файле Задание 3_6.
Если необходимо измените бизнес - правила так, чтобы в вашей модели было не менее трех идентифицирующих связей.
Полученные результаты занесите в свой отчет в раздел "Идентификация связей" ( пример оформления этой части отчета)