Неидентифицирующие связи

Идентификация связей

В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Если вы хотите, чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), то можете создать идентифицирующую взаимосвязь между родительской и дочерней сущность.

Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.

В IDEF1X, как показано на рис.7, в конце линии со стороны дочернего объекта ставится точка. В IE в конце линии со стороны дочернего объекта ставится “куриная лапка”.

Примечание: В стандарте IE нет закругленных углов на объектах. Это IDEF1X символ, добавленный ERwin’ом в стандарт IE для совместимости.

Как вы могли заметить при обсуждении независимых и зависимых сущностей, правила, обозначающие то, что связь является идентифицирующей, определяются идентификацией дочерней сущности за счет использования идентификатора родительской сущности. В нашем примере ФИЛЬМОВ и КОПИЙ ФИЛЬМОВ для идентификации копии мы могли выбрать ее собственный уникальный номер. Однако, мы решили использовать идентификатор ФИЛЬМА и добавить вторую часть (номер копии) для того, чтобы отличить одну копию от другой.

Примечание: Как вы можете обнаружить, существует несколько преимуществ при передачи ключей дочерней сущности за счет идентификации связей, связанных с тем, что при этом упрощаются некоторые запросы к физической системе. Однако существуют и некоторые недостатки. С точки зрения реляционной теории предполагается, что передача ключей не должна происходить таким образом. Вместо этого, каждый сущность должен быть идентифицирована не только при помощи своего первичного ключа, но и при помощи логического дескриптора (handle) или дополнительного ключа, невидимого для пользователя системы. У этой теории существует убедительное доказательство и интересующиеся могут обратиться к работе E.F.Codd и C.J.Date на эту тему.

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

Неидентифицирующие связи отображаются пунктирной линией между объектами. Если вы свяжите объекты КОМАНДА и ИГРОК посредством неидентифицирующей связи, то модель будет выглядеть как показано на рис. 9.

Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущность, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и КОМАНДА, и ИГРОК рассматриваются как независимые сущности.

Тем не менее взаимосвязь может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.

Примечание: Идентифицирующие и неидентифицирующие связи не являются особенностью IE метода. Однако, эта информации включена в вашу ERwin диаграмму в виде сплошной линии связи или пунктирной линии связи для обеспечения совместимости между IE и IDEF1X методами.

Роль (Rolename)

Когда внешние ключи мигрируют от родительской сущности через связь к дочерней сущности, они служат в модели двойную службу. Для понимания обеих ролей, иногда является полезным переименовать передаваемый ключ, для того, чтобы показать, какую он играет роль в дочерней сущности. Имя, назначаемое этому атрибуту, называется ролью.

10. Пример имени Роли

Внешний ключ ИГРОКа “игрок-команда id.команда id” (рис.10) демонстрирует синтаксис определения и отображения имени роли. Первая половина (перед точкой) – это имя роли. Вторая часть – это собственное имя внешнего ключа, иногда называемое базовым именем.

Примечание: Имена Ролей также используются для совместимости модели с наследуемыми моделями данных, где внешний и первичный ключи имели разные названия.

Роли передаются посредством связи, также, как и другие атрибуты. Например, предположим, что мы расширили пример для того, чтобы показать какие ИГРОКИ забивали голы в различных матчах в сезоне. Имя роли “Игрок-команда-id” передается в сущность РЕЗУЛЬТАТИВНАЯ ИГРА (вместе с любым другим первичным ключом из родительской сущности), как показано ниже.


Диаграмма, показывающая миграцию FK атрибута, имеющего ролевое имя


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: