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

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

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

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

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

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

В 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 можно выбрать переключатель обязательности связи:

No Nulls – обязательная неидентифицирующая связь. При генерации схемы базы данных атрибут внеш­него ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности.

Nulls Allowed – необязательная неидентифицирующая связи. Внешний ключ может принимать значение 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. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то каждый связанный экземпляр в дочерней сущности (таблице) также удаляется, вставляется или обновляется.

Set null. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждого связанного экземпляра дочерней сущности (таблице) устанавливается в Null.

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

No Action. Если экземпляр в родительской сущности (таблице) удаляется, вставляется или обновляется, то во всех связанных экземплярах дочерней сущности никакие действия не производятся.

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-триггера Parent Insert—CASCADE для того, чтобы при создании новой строки в таблице Команда автоматически создава­лась хотя бы одна строка в дочерней таблице Игрок. (рис. 54)

Присвоить связи действие RI-триггера Parent Delete—CASCADE для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись (рис. 54).

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

Основные типы связей

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

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

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

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

Одно из многих важных различий, обнаруживаемых при сравнении инструментальных средств формирования ER-диаграмм типа IE и ШЕЕ IX с собственными средствами подготовки ER-диаграмм, применяемыми в СУБД SQL Server, заключается втом, что в этих программах применяются разные определения сущности. Определение сущности примерно соответствует таблице (насколько оправданным является это утверждение, зависит также от того, идет ли речь о логической или физической модели). Определение сущности должно соответствовать такому требованию, чтобы с его помощью можно было легко определить имя сущности, первичный ключ и все атрибуты (по существу эквивалентные столбцам), которые имеет сущность. Кроме того, на самой ER-диаграмме может быть представлена другая информация, такая как тип данных атрибута или указание на то, определен ли для сущности внешний ключ. В качестве примера рассмотрим определение сущности, показанное на рис. 7.1.

Имя сущности должно находиться над прямоугольником.

в котором представлено определение сущности. Кроме того. Рис. 7.1. Пример опре-в верхней части общего прямоугольника, но в отдельной рамке деления сущности

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

Теперь рассмотрим немного другое определение сущности (рис. 7.2).

Это определение характеризуется наличием некото-рьгх особенностей, перечисленных ниже.

Lineltem ТЕХТ(50) OrderlD INT (FK)

PartNo TEXT(5) Qty INT

Указаны типы данных (поскольку перед формированием ER-диаграммы разрешена соответст- Рис. 7.2. Еще один пример вующая опция). опредепения сущности

Заданы внешние ключи (внешние ключи отображаются, если они определены, но и в этом случае должна быть разрешена относящаяся к этому опция).

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

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

Некоторые инструментальные средства создания ER-диаграмм позволяют задавать определения типов данных непосредственно в составе ER-диаграммы. Связи между сущностями на ER-диаграмме обозначаются линиями связи (пример применения обозначений связей приведен ниже). При этом предусмотрена возможность показывать с помощью линий связи внешние ключи. Большинство применяемых инструментальных средств создания ER-диаграмм позволяет даже автоматически определять указанный в ссылке столбец (столбцы) в связи с внешним ключом как являющийся частью первичного ключа (или, возможно, составляющий весь первичный ключ) в ссылающейся таблице.

Линии связи, применяемые в ER-диаграммах, подразделяются на два типа и полностью соответствуют описанным выше типам связей.

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

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

Штриховой или пунктирной линией обозначается неидентифицирующая связь (рис. 7.4).

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

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

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

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

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

1:6 (эта связь соответствует определению один ко многим , но регламентирована гораздо более определенно, в частности, содержит указание на то, что количество строк на стороне многие не может превышать шести).

Ниже описано, из каких частей состоит признак конца, и показано, что они означают.

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

Верхняя половина обозначения признака конца, показанного на рис. 7.5, соответ ствует начальному пределу диапазона изменения 1сардинальности связи. В данном случае минимальное значение кардинальности связи равно нулю. Нижняя половина обозначения признака конца на рис. 7.5 позволяет узнать, каковым является конечный предел диапазона изменения кардинальности связи; в данном случае применяется условное обозначение многие . Итак, на рис.7.5 приведено обозначение стороны связи нуль, один или многие .

Какая разница между идентифицирующей и неидентифицирующей связей?

Я не смог полностью понять различия. Можете ли вы описать обе концепции и использовать примеры из реального мира?

14 ответов

An определение отношения это когда существование строки в дочерней таблице зависит от строки в родительской таблице. Это может быть запутанным, потому что в наши дни распространена практика создания псевдокея для дочерней таблицы, но не сделайте внешний ключ к родительской части первичного ключа ребенка. Формально «правильный» способ сделать это-сделать внешний ключ частью первичного ключа ребенка. Но логическая связь заключается в том, что ребенок не может существовать без родителя.

Пример: A Person имеет один или несколько телефонных номеров. Если бы у них был только один номер телефона, мы могли бы просто сохранить его в столбце Person . Поскольку мы хотим поддерживать несколько телефонных номеров, мы делаем вторую таблицу PhoneNumbers , первичный ключ которой входит person_id ссылок Person таблица.

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

A неидентифицирующем отношении когда атрибуты первичного ключа родителя не должен станьте атрибутами первичного ключа ребенка. Хорошим примером этого является таблица поиска, например внешний ключ на Person.state ссылка на первичный ключ States.state . Person является дочерней таблицей с уважение к States . Но ряд в Person не идентифицируется его . Т. е. state не является частью первичного ключа Person .

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

есть еще одно объяснение из реального мира:

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

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

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

неидентифицирующие отношения указывает регулярную связь между объектами 1:1 или 1:n количество элементов.

неидентифицирующие отношения могут быть указаны как необязательные, если родитель не обязательными, где родитель требует установки родительская таблица мощности.

Билл правильно, но это видеть что среди всех других ответов никто не указывает на самый существенный аспект.

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

так вот настоящая причина:

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

вот хорошее описание:

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

вот простой пример определения отношения:

вот соответствующее неидентифицирующее отношение:

как user287724 второй ответ пример книги и автор отношения получил 576 голосование ups. , как говорится:

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

это очень запутанный пример и это определенно недопустимый пример на identifying relationship .

я, наконец, понимаю разницу между обоими отношениями: ((, поэтому, пожалуйста,не путайте меня с этим количеством голосов!!

да, книга не может быть написана без хотя бы одного автора, но автор(это внешний ключ), книги НЕ ИДЕНТИФИЦИРУЯ книга в таблице книг!

вы можете удалить автора (FK) из строки книги и все еще можете определите строку книги по другому полю (ISBN, ID. и т. д.) , но не автор книги!!

я думаю, что действительный пример identifying relationship будет отношением между (таблица продуктов) и (таблица конкретных сведений о продукте) 1:1

в этом примере Product_ID на printers_details таблица считается FK ссылается на products.id таблица и также PK на printers_details таблица, это идентифицирующая связь потому что Product_ID (FK) в таблице принтеров ИДЕНТИФИЦИРУЕТ строка внутри дочерней таблицы мы не можем удалить product_id из дочерней таблицы, потому что мы больше не можем идентифицировать строку, потому что мы потеряли ее первичный ключ

если вы хотите поместить его в 2 строки:

идентифицирующим отношением является отношение, когда FK в дочерняя таблица считается PK (или идентификатором) в дочерней таблице, в то время как все еще ссылается на родителя таблица

другой пример может быть, когда у вас есть 3 таблицы (импорт-продукты-страны) в импорте и экспорте для базы данных некоторых стран

the import таблица является дочерним, который имеет эти поля (the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) ) мы можем использовать (product_id, country_id) для идентификации каждой строки импорта» если они все в том же году», здесь оба столбца могут составлять первичный ключ в дочерней таблице (импорт) , а также ссылаться на родительский таблицы.

пожалуйста, я рад, что наконец-то понял концепцию identifying relationship и non identifying relationship : ((, поэтому, пожалуйста, не говорите мне, что я не прав со всеми этими голосами за совершенно некорректный пример

да логически книга не может быть написана без автора, но книга может быть идентифицирована без автора, на самом деле она не может быть идентифицирована с автором!

вы можете 100% удалить автора из строки книги и все еще могу идентифицировать книгу . , пожалуйста, не говорите мне, что я не понял 🙁

неидентифицирующем отношении

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

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

определение отношения

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

этот означает, что внешний ключ-это первичный ключ.

связь между ITEM_LANG и ITEM идентифицирует. И между ITEM_LANG и языком тоже.

идентификация relaionship означает, что дочерняя сущность полностью зависит от существования родительской сущности. Пример таблицы учетных записей person table и personaccount.Таблица счета лица определяется только существованием таблицы счета и лица.

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

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

Если дочерний элемент должен храниться, даже если родитель удален, то это неидентифицирующее отношение.

в качестве примера, у меня есть обучающая база данных с обучаемыми, тренингами, дипломами и тренировками:

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

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

do атрибуты перенесены из родительской в дочернюю help определение 1 ребенка?

• если да: существует идентификация-зависимость, отношения идентифицируют, а дочерняя сущность «слаба».
• если не: идентификация-зависимость не существует, отношения не идентифицируют и дочерняя сущность «сильна».

обратите внимание, что идентификация-зависимость подразумевает существование-зависимость, но не наоборот. Каждый ненулевой FK означает, что ребенок не может существовать без родителя, но это само по себе не делает идентификацию отношений.

для получения дополнительной информации об этом (и некоторых примерах), взгляните на раздел «идентификация отношений»Руководство По Методам ERwin.

P. S. Я понимаю, что я (очень) опоздал на вечеринку, но я чувствую, что остальные ответы являются не совсем точными (определение его в терминах существования-зависимость вместо идентификации-зависимость), или несколько извилистая. Надеюсь, этот ответ даст больше ясности.

1 FK ребенка является частью первичного ключа ребенка или (ненулевого) уникального ограничения.

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

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

таким образом, родительская дочерняя связь между заказами и элементами строки является идентифицирующей связью. Тесно связанная концепция в ER-моделировании называется «subentity» , где элемент строки в части объекта заказа. Как правило, субентичность имеет обязательное отношение дочернего родителя к сущности, которой она подчинена.

в классическом дизайне базы данных первичным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые современные дизайнеры дадут пункту отдельный идентификатор элемента, который служит в качестве первичного ключа, и несколькими СУБД. В этом случае я рекомендую классический дизайн.

Допустим, у нас есть эти таблицы:

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

Как хорошо объяснено в приведенной ниже ссылке, идентифицирующее отношение несколько похоже на слабое отношение типа сущности к своему родителю в концептуальной модели ER. CAD в стиле UML для моделирования данных не используют ER-символы или понятия, а отношения: идентифицирующие, неидентифицирующие и неспецифические.

идентифицирующими являются отношения родитель / ребенок, где ребенок является слабой сущностью (даже в традиционной модели ER ее называют идентифицирующей связью), которая не имеют реальный первичный ключ по своим собственным атрибутам и поэтому не могут быть идентифицированы однозначно по своим собственным. Каждый доступ к дочерней таблице на физической модели будет зависеть (включая семантически) от первичного ключа родителя, который превращается в часть или сумму первичного ключа ребенка (также являющегося внешним ключом), что обычно приводит к составному ключу на дочерней стороне. Возможные существующие ключи самого ребенка являются только псевдо-или частичными ключами, недостаточными для идентификации любого экземпляра этот тип сущности или набора сущностей без родительского ПК.

неидентифицирующие отношения-это обычные отношения (частичные или полные) полностью независимых наборов сущностей, экземпляры которых не зависят от уникальных первичных ключей друг друга, хотя им могут потребоваться внешние ключи для частичных или полных отношений, но не как первичный ключ ребенка. У ребенка есть свой первичный ключ. Родитель идем. Оба независимо. В зависимости от мощности отношение, PK одного идет как FK к другому (n стороне), и если частичное, может быть нулевым, если полное, должно быть не нулевым. Но в таких отношениях FK никогда не будет также ПК ребенка, как в случае идентифицирующих отношений.

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

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