Что такое идентифицирующая связь
Перейти к содержимому

Что такое идентифицирующая связь

  • автор:

Что такое идентифицирующая связь

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы. По умолчанию имя связи на диаграмме не показывается. На логическом уровне можно установить идентифицирующую связь «один-ко-многим», связь «многие-ко-многим» и неидентифицирующую связь «один-ко-многим».

В IDEFIX различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – FK.

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

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

Мощность связей (Cardinality) – служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают четыре типа сущности:

  1. общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности; не помечается каким-либо символом;
  2. символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
  3. символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
  4. цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи «один-ко-многим», идентифицирующей или неидентифицирующей, достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent.

Пред. Уровень выше След.
19.5. Сущности и атрибуты Начало | ToC 19.7. Типы сущностей и иерархия наследования

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

В IDEF1X и в IE различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin DM автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами (сущность Заказ на рис. 45). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 45 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает.

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ — (Foreign Key — FK) (рис. 45). В дальнейшем, при генерации схемы базы данных, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.

Рис. 45. Идентифицирующая связь.

При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родитель­ской сущности мигрируют в состав неключевых компонентов дочерней сущности. Неидентифицирующая связь служит для связывания независи­мых сущностей. На рис. 46 экземпляр сущности Сотрудник может существовать безотносительно к какому-либо экземпляру сущности Отдел, т. е. сотрудник может работать в организации, не числясь в каком-либо отделе.

Рис. 46. Неидентифицирующая связь.

Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (рис. 45), неидентифицирующая — пунктирной (рис. 46).

Рис. 47. Диалог Relationships.

Для создания новой связи следует:

  • щелкнуть левой кнопкой мышки по кнопке рисования связи в панели инструментов ERwin (табл. 11);
  • щелкнуть сначала по родительской, а затем по дочерней сущности.

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

Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по линии связи и выбрать в контекстном меню пункт Relationship Properties.

В появившемся диалоге Relationships в закладке General можно задать имя связи (раздел Verb Phrase), мощность (раздел Cardinality), тип связи (раздел Relationship Type) (рис. 47).

Имя связи (Verb Phrase) — фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи «один ко многим» (иденти­фицирующей или неидентифицирующей) достаточно указать имя, характе­ризующее отношение от родительской к дочерней сущности (Parent-to-Child) (рис. 45, 46). Для связи «многие ко многим» следует указывать имя как Parent-to-Child, так и Child-to-Parent.

Мощность связи (Cardinality) служит для обозначения отношения чис­ла экземпляров родительской сущности к числу экземпляров дочерней. Различают 4 типа мощности, которые были рассмотрены в разделе «Особенности методологий IDEF1X и IE». По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для его отображения следует в контекстном меню, кото­рое появляется, если щелкнуть правой кнопкой мыши по любому месту диа­граммы, не занятому объектами модели, выбрать пункт Relationship Display и затем включить опцию Cardinality.

Тип связи (Relationship Type). Можно изменить тип связи: идентифицирующая или неидентифицирующая. Для неиден­тифицирующей связи в разделе Nulls можно выбрать переключатель обязательности связи:

  • NoNullsобязательная неидентифицирующая связь. При генерации схемы базы данных атрибут внеш­него ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности.
  • NullsAllowedнеобязательная неидентифицирующая связи. Внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис 46).

В закладке Definition диалога Relationships можно дать более полное определение связи. В закладке RI Actions определяют правила ссылочной целостности (referential integrity), о которых будет рассказано позднее. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диалог User Defined Property (меню Model/UDP Dictionary) как свойства связи (Relationship). В закладке Rolename (рис.48) можно задать имя роли.

Рис. 48. Закладка Rolename диалога Relationships.

Имя роли (функциональное имя) — показывает, какую роль играет мигрировавший атрибут в дочерней сущности. В примере, приведенном на рис. 49, в сущности Сотрудник внешний ключ Номер отдела имеет функциональное имя «Где работает«, которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полно­го имени атрибута (имя роли + имя мигрировавшего атрибута) в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, следует вы­брать пункт Entity Display и затем включить опцию Rolename/Attribute. Полное имя показывается как имя роли, имя мигрировавшего атрибута, разде­ленные точкой (рис. 49).

Рис. 49. Пример имен ролей внешних ключей.

Обязательным является применение имен ролей в том случае, когда два или более атрибута одной и той же сущности имеют одинаковую область значений, но разный смысл. На рис. 50 сущность Продажа валюты содержит информацию об акте обмена валюты, в котором участвуют две валюты — проданная и купленная. Информация о валютах содержится в сущности Валюта. Следовательно, сущности Продажа валюты и Валюта должны быть связаны дважды, и первичный ключ Номер валюты должен дважды мигрировать в сущность Продажа валюты в качестве внешнего ключа. Требуется различать два атрибута, мигрировавших из сущности Валюта: один содержит номер проданной валюты, а другой содержит номер купленной валюты,- они имеют общую область значений и ссылаются на одну и ту же сущность Валюта. В примере на рис. 50 атрибутам присвоены разные имена ролей: Проданная и Купленная.

Рис. 50. Пример обязательного использования имен ролей.

Другим примером обязательности присвоения имен ролей являются ре­курсивные связи, когда одна и та же сущность является и родительской и дочерней од­новременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущно­сти. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. 49 сущность Сотрудник содержит атрибут первичного ключа Табельный но­мер. Информация о руководителе сотрудника содержится в той же сущно­сти, поскольку руководитель работает в той же организации. Чтобы со­слаться на руководителя сотрудника, следует создать рекурсивную связь (на рис. 49 связь Руководит/Подчиняется) и присвоить имя роли (Руко­водитель). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в со­став первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии — у дерева под­чиненности должен быть корень — сотрудник, который никому не подчиняется. ­Связь руководит/подчиняется на рис. 49 позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчинен­ный имеет только одного руководителя (рис. 51 слева).

Рис. 51. Подчиненность экземпляров сущности в рекурсии.

Другим видом рекурсии является сетевая рекурсия (network recursion) (рис. 51 справа), когда руководитель может иметь множество подчиненных и, наоборот, подчиненный может иметь множество руководителей. Сетевая рекурсия за­дает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи «многие ко многим». Для разрешения связи «многие ко многим» необходимо создать новую сущность (подробно связь «многие ко многим» будет рас­смотрена ниже).

На рис. 52 рассмотрен пример реализации сетевой рекурсии. Струк­тура моделирует родственные отношения между членами семьи любой сложности. Атрибут Тип отношения может принимать значения «отец-сын», «мать-дочь», «дед-внук», «свекровь-невестка», «тесть-зять» и т. д. По­скольку родственное отношение связывает всегда двух людей, от сущности Родственник к сущности Родственное отношение установлены две иден­тифицирующие связи с именами ролей «Старший» и «Младший». Каждый член семьи может быть в родственных отношениях с любым другим членом семьи, более того, одну и ту же пару родственников могут связывать разные типы родственных отношений.

Рис. 52. Пример реализации сетевой рекурсии.

Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более — только имя роли. На рис. 53 изображена структура данных, которая содержит сущность Команда, сущность Игрок, в которой хранится информация об игроках каждой команды, и сущность Гол, содержащая информацию о голах, которые забивает каждый игрок. Атрибут внешнего ключа Номер команды сущности Игрок имеет имя роли В какой команде играет. На следующем уровне, в сущности Гол, отображается только имя роли соответствующего атрибута внешнего ключа (В какой команде играет).

Рис. 53. Пример миграции имен ролей.

Правила ссылочной целостности (RI — referential integrity) – правила определяющие, что произойдет в случае, если будут произведены изменения в родительской или дочерней сущности: добавление (INSERT), обновление (UPDATE), удаление (DELETE). Правила ссылочной целостности позволяют избежать «висячих» данных и позволяют придерживаться бизнес правил.

ERwin DM автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем доба­вить ее в диаграмму. В закладке RI Actions диалога Model Properties (меню Model/Model Properties) можно изменить правила ссылочной целостности по умолчанию. На основе этих правил при генерации схемы базы данных будут сгенерированы:

  • правила деклара­тивной ссылочной целостности для ка­ждой связи,
  • триггеры, обеспечивающие ссылочную целостность.

Переопределить правила ссылочной целостности для конкретной связи можно в закладке RI Actions диалога Relationships (рис. 54).

Рис. 54. Закладка RI Actions диалога Relationships.

Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления. По умолчанию ERwin DM генерирует триггеры, дублирующие декларативную ссылочную целостность.

Для связей в модели ERwin DM можно определить следующие типы действий триггеров ссылочной целостности (в зависимости от выбранной СУБД и ее версии этот список может быть короче):

  • Restrict. Не разрешает удалять, обновлять или редактировать экземпляр в родительской или дочерней сущности (таблице), если существует один или более связанных с ним экземпляров в дочерней или родительской сущности (таблице).
  • Cascade. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то каждый связанный экземпляр в дочерней сущности (таблице) также удаляется, вставляется или обновляется.
  • Setnull. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждого связанного экземпляра дочерней сущности (таблице) устанавливается в Null.
  • Setdefault. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждому связанному экземпляру дочерней сущности (таблице) назначается определенное значение по умолчанию.
  • NoAction. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то во всех связанных экземплярах дочерней сущности никакие действия не производятся.
  • None. Не требуются действия по поддержанию ссылочной целостности.

Для отображения на диаграмме установленных правил ссылочной целостности следует в меню Format выбрать пункт Relationship Display, затем Referential Integrity.

В таблице 13 приведены примеры правил ссылочной целостности при удалении строки родительской таблицы.

Таблица 13. Примеры правил ссылочной целостности при удалении строки родительской таблицы.

Parent Delete RESTRICT — удаление с ограничением

На рис. 53 между сущностями Команда и Игрок существует идентифицирующая связь. Экземпляр сущности Игрок не может существовать без Команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать зна­чение NULL).

Правило запрещает удаление команды, по­ка в ней числится хотя бы один игрок (для удаления команды сначала нуж­но удалить всех игроков).

При попытке выполнить удаление строки из родительской таблицы Команда, в которой есть хотя бы один игрок, сервер реляционной СУБД возвратит ошибку.

Parent Delete CASCADE — удаление каскадом

На рис. 53 между сущностями Команда и Игрок существует идентифицирующая связь. Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать зна­чение NULL).

Согласно правилу вместе с командой удаляются сразу все ее игроки.

Примечание. Сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и в случае удаления каскадом команды будут удалены все игроки этой команды и все голы, которые они забили. Выполнение команды на удаление одной строки фактически может привести к удалению тысяч строк в базе дан­ных, поэтому использовать правило удаления каскадом следует с осторож­ностью.

Parent Delete SET NULL — удаление с установкой в Null

На рис. 46 установлена необязательная неидентифицирующая связь между сущностями Отдел и Сотрудник. Экземпляр сущности Сотрудник может существовать без ссылки на отдел (атрибут внешнего ключа Где ра­ботает. Номер отдела может принимать значение NULL).

Согласно правилу при удале­нии отдела атрибут внешнего ключа сущности СотрудникГде работает. Номер отдела примет значение NULL. Это означает, что при удалении от­дела сотрудник остается работать в организации, не будучи приписан к ка­кому-либо отделу, и информация о нем сохраняется.

Parent Delete SET DEFAULT — удаление с установкой значений по умолчанию

На рис. 53 существует идентифицирующая связь между сущностями Команда и Игрок.

Согласно правилу атрибут внешнего ключа получит значение по умолчанию.

Т.е. при удалении команды атрибут первичного ключа в сущности Игрок (В какой команде играет. Номер команды) получит значение по умолчанию. Например, при удалении команды ее игроки могут быть переведены в другую команду.

Parent Delete NONE — простое удаление

На рис. 53 существует идентифицирующая связь между сущностями Команда и Игрок.

Согласно правилу при удалении значение атрибута внешнего ключа не меняется.

Запись об игроке «повисает в воздухе», т. е. ссылается на несуществующую уже команду.

Ситуация, когда при удалении значение атрибута внешнего ключа не меняется (режим Parent Delete NONE) характерна для «плоских» таблиц. На­пример, если информация об игроках и командах хранится в dbf-файлах, можно удалить запись о команде, при этом файл игроков «ничего не будет знать» о том, что соответствующей команды не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.

Правила удаления управляют тем, что будет происходить в базе данных при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет происходить с базой данных, если строки изменяются или до­бавляются. Например, можно установить правило, которое разрешает вносить новую команду только в том случае, когда в нее зачислен хотя бы один игрок. Желаемое поведение может быть достигнуто следующими действиями:

  • Задать мощность связи между сущностями Командаи Игрок, равную 1 или более (тип Р). Предполагается, что установлена идентифицирующая связь.
  • Присвоить действие RI-триггера ParentInsertCASCADE для того, чтобы при создании новой строки в таблице Команда автоматически создава­лась хотя бы одна строка в дочерней таблице Игрок. (рис. 54)
  • Присвоить связи действие RI-триггера ParentDeleteCASCADE для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись (рис. 54).

Идентифицирующая или неидентифицирующая связь?

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

  • Вопрос задан более трёх лет назад
  • 26621 просмотр

Комментировать
Решения вопроса 0
Ответы на вопрос 1

Nipheris

Смысл в том, что при идентифицирующей связи внешний ключ в дочерний сущности также становится частью первичного ключа. В этом и смысл фразы «зависимая сущность» — т.к. внешний ключ есть часть первичного, то сущность просто не может существовать без указания значения внешнего ключа.

Хороший пример — сущность «элемент заказа» (OrderItem). Не может быть элемента заказа без самого заказа. Поэтому идентифицирующая связь из отношения «заказ» (Order) отлично тут подойдет. Если у заказа первичный ключ Id, то первичный ключом OrderItem будет, к примеру, такая пара: (OrderId, Number), где OrderId — внешний ключ в таблицу заказов, добавленный идентифицирующей связью, а Number — номер элемента заказа (строки в чеке, если так понятнее), позволяющий иметь несколько заказанных товаров в одном заказе.

Неидентифицирующая связь, соответственно, НЕ добавляет колонки внешнего ключа в первичный ключ. Соответственно, значение внешнего ключа при неидентифицирующей связи может быть как NULL, так и NOT NULL.

Модель сущность-связь

Домен не указывает конкретный физический тип, однако позволяет указать, какие атрибуты будут иметь одинаковый тип в физической модели. Так, например, атрибуты $FirstName$ и $LastName$ сущности $Student$ будут обладать одним физическим типом.

Типы доменов:

  • Простой — атомарное значение, например, $id$
  • Составной — состоящий из нескольких значений, например, passport

Свойства атрибутов:

Обозначение Свойство
M Обязательное (англ. mandatory)
O Необязательное (англ. optional)
PK Основной ключ (англ. primary key)
Kn Дополнительный ключ $n$ (англ. key)
  • Так как любой атрибут обладает либо свойством обязательности, либо свойством необязательности, будем считать атрибуты необязательными по умолчанию, не указывая это свойство явно.
  • Основной ключ можно выделить, подчеркнув атрибуты, входящие в него, сплошной линией.

Связи

Пример связи

Связь обозначается линией с двумя концами и обладает следующими характеристиками:

  • Имя
  • Связываемые сущности и их роли
  • Тип связи (задается типами концов)

На примере показано, что студен принадлежит одной группе, а в группе может быть несколько студентов (в том числе нуль).

Типы концов:

Тип Обозначение
Один
Много
Обязательный
Необязательный

Можно выбрать значение по умолчанию, которое будет обозначаться сплошной линией без символов.

Связь Значение По умолчанию
Многие ко многим Единственность, необязательность
Один ко многим Единственность, обязательность
Один к одному Единственность, обязательность

Замечание: В дальнейшем будем считать, что значениями по умолчанию будет «один» и «необязательный».

Ассоциации

Определение:
Ассоциацией (англ. association) называется многосторонняя связь, нагруженная произвольными не ключевыми атрибутами.

Графическое обозначение ассоциации

  • Ассоциация обозначается прямоугольником с закругленными краями
  • Может содержать не ключевые атрибуты
  • Имеет произвольное количество концов с произвольными ролями и типами

Пример с ассоциацией

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

Как понять, что использовать: ассоциацию, связь или сущность?

  • Если нужно два конца и нет нагруженности, используем связь
  • Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов
  • Иначе используется ассоциация

Многосторонние ассоциации

Пример неоднозначности интерпретации связей

Многостороннюю ассоциацию можно интерпретировать по-разному. Так, например, на рисунке может быть обозначено следующее:

  • У каждого контракта есть один поручитель
  • Можно быть поручителем у ровно одного контракта
Ограничение по Чену
(англ. Chen-like, Look-across)
Chen-like.png Зафиксировав остальные сущности, получаем
ограничение на рассматриваемую.
У каждого контракта есть поручитель.
Ограничение по Мерис
(англ. Merise-like, Look-here)
Merise-like.png Ограничение непосредственно на сущность.
Можно быть поручителем у одного контракта.

Все ограничения.png

Также существуют обобщенные ограничения (англ. generic), позволяющие зафиксировать произвольное подмножество.

Выразительная мощность ограничений

  • Для ассоциаций с двумя концами:
    • Чен = Мерис = Обобщенные
    • Чен + Мерис = Обобщенные
    • Чен + Мерис < Обобщенные

    Слабые сущности

    Определение:
    Слабой сущностью называется сущность, у которой недостаточно атрибутов для идентификации.

    Слабая сущность обозначается прямоугольником с двойной границей.

    Определение:
    Идентифицирующей связью называется связь, позволяющая слабой сущности получить атрибуты, необходимые для ее идентификации.

    Пример слабой сущности

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

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

    Альтернативные нотации

    Выше рассматривалась нотация Crow’s foot, предложенная Гордоном Эверестом.

    Нотация Питера Чена

    Модель Сущность-связь была предложена Питером Ченом в 1976 году, им же была предложена следующая графическая нотация:

    Нотация Питера Чена.png

    UML-нотация

    Для каждой таблицы явно подписывается, что она обозначает (ассоциацию, сущность и т.д.). Ограничения прописываются в виде $i..k$ (например, $1..n$), это позволяет наложить ограничение $2..n$, что было невозможно в Crow’s foot.

    UML-нотация.png

    Object Definition Language

    Позволяет задавать схему базы данных кодом.

    Рассмотрим пример. У студента есть идентификатор Id , имя Name , а также ссылка на группу group . Явно указываем, что противоположностью этой ссылки является соответствующее поле класса Group : inverse Group::students .

    У группы есть Id и смножество студентов students , учащихся в группе. Указываем, что у студентов ссылка хранится в поле group .

    В данном примере выражена связь один ко многим: студент зачислен в одну группу, в каждой группе есть несколько студентов.

    class Student < int Id; string Name; Group group inverse Group::students; >class Group < int id; Setstudents inverse Student::group; >

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *