В чем разница между идентифицирующими и неидентифицирующими отношениями?


800

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


11
ответы на этот вопрос настолько запутанные, что это не смешно
Деннис

Хороший вопрос, колесо не должно быть заново изобретено: Питер Чен. Модель отношений сущностей, к унифицированному представлению данных, § 2.3.2 1976 года : « Если связи используются для идентификации сущностей, мы будем называть это слабым отношением сущностей. Если связи не используются для идентификации сущностей, мы будем вызывать это регулярное отношение сущности ". Вопрос ОП сводится к следующему: что такое слабые / регулярные отношения сущностей? ,
минут

Ответы:


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

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

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

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

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


См. Также мой ответ на « Все еще в замешательстве» по поводу идентификации и неидентификации отношений


9
+1: Билл, «в наши дни принято создавать псевдоключ для дочерней таблицы, но не делать внешний ключ для родительской части первичного ключа дочернего элемента» - есть какие-либо ссылки на то, почему это так? Google подводит меня.
hobodave

17
Кажется, что «правильное» построение идентифицирующих отношений приведет к неприятно огромным первичным ключам. Например, в здании есть этаж, в номере есть кровать. PK для кровати будет (bed_id, floor_id, room_id, building_id). Кажется странным, что я никогда не видел это на практике и не слышал, чтобы это предлагалось как способ что-либо сделать. Это много избыточных данных в ПК.
hobodave

24
@hobodave: я видел многоколонные первичные ключи, которые еще больше. Но я понимаю вашу точку зрения. Учтите, что многоколонные первичные ключи передают больше информации; Вы можете запросить Bedsтаблицу для всех кроватей в конкретном здании, не делая каких-либо соединений.
Билл Карвин

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

4
Я никогда не буду использовать это, чтобы смоделировать это. Лучший ответ из приведенного ниже «aqsa rao» гласит следующее: «Идентификационные отношения означают, что дочерняя таблица не может быть однозначно идентифицирована без родителя». Потому что ваше определение добавляет ненужную семантику, которая может сбить людей с толку. Это не зависимость между сущностями, причина, по которой вы создаете идентифицирующую или неидентифицирующую связь.
Себастьян

888

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

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

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


2
Достойное объяснение, но я считаю, что также полезно немного расширить пример. Книга имеет несколько страниц. Он не может существовать без страниц, и поэтому мы можем заключить, что связь между книгой и количеством страниц в ней также является идентифицирующей. Но будет ли атрибут количества страниц быть частью какой-либо схемы идентификации (ключа) для книги? Возможно нет. Термин «идентифицирующие отношения» обычно зарезервирован для отношений, включающих идентифицирующие атрибуты - основные атрибуты в реляционных терминах.
nvogel

13
Что произойдет, если книга была написана более чем одним автором? Это не идентифицирует отношения как тип M: N, почему?
NGix

2
Эти реальные примеры бесполезны. Когда вы поймете, как вы создаете таблицы в ER и как сохранится целостность данных, вы отбрасываете эти примеры. Если вы создаете прочные отношения между двумя сущностями, вы вынуждены создавать первичный ключ в таблице сущностей в сочетании с PK от другой сущности. Если ваша модель допускает, что в одной и той же книге может быть несколько авторов, значит быть сильным. Но если ваша модель позволяет вам только 1 автора 1 книгу, вы не можете иметь это ограничение, используя сильные отношения, потому что PK(Book.id, Book.person_id).
Себастьян

2
но реальное использование - «может ли книга существовать без автора?». Ответ на самом деле да, потому что люди будут искать книгу напрямую. Поэтому на практике для этого случая у них всегда должны быть «неидентифицирующие отношения».
windmaomao

3
что происходит, ребята !!, это не правильный пример для the Identifying relationship !!! да, книгу нельзя написать без автора, но поле автора в таблице книг НЕ ОПРЕДЕЛЯЕТ строку книги !!!
Бухгалтер م

33

Ответ Билла правильный, но шокировать тот факт, что среди всех остальных ответов никто не указывает на самый важный аспект.

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

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

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


2
+1 за «Достаточно, чтобы внешний ключ был ненулевым, чтобы достичь этого». Этого должно быть достаточно, но, к сожалению, это не так, когда речь идет о чем-то вроде Entity Framework, который работает неправильно, если вы не используете идентифицирующее отношение, но тогда поле «Id» объекта теряет свою уникальность в результате того, что оно просто часть составного ключа.
Трийнко

25

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

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

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


6
Это больше похоже на описание общего участия в отношениях, чем на идентифицирующие отношения.
Томас Падрон-Маккарти

1
Вы буквально соревнуетесь с парнем, который имеет репутацию 218 КБ. Просто добавлю это, потому что вы оба точно знаете больше, чем я.
Марк ДиМилло

Я не согласен с приведенными выше определениями. У вас может быть объект, который зависит от его родителя, и вы хотите, чтобы этот объект ограничивался связью только с 1 родительской строкой. А Houseимеет Wallс. Вы убираете дом и у вас нет стен. Но стена принадлежит только дому. Так что прочные отношения не сработают: PK(Wall.id, House.id)вы сможете вставить в модель ту же стену в другой дом.
Себастьян

15

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

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

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Вот простой пример идентификации отношений:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

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

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

1
Ваш ответ противоречит ответу Билла Карвина на разницу между тем, является ли внешний ключ «нет» или «не должен» быть частью первичного ключа в строке «ребенок».
Николь

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

10

Ответ user287724 дает следующий пример отношения книги и автора:

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

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

Да, bookне может быть написана без по крайней мере одного author, но author(это внешний ключ) из bookэто НЕ ОПРЕДЕЛИТЬbook вbooks таблице!

Вы можете удалить author(FK) из bookстроки и до сих пор можно определить книгу строки какой - либо другой области ( ISBN, ID, ... и т.д.), но не автор книги !!

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

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

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

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

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

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

importТаблица является ребенок , который имеет следующие поля ( product_id(ФК), то country_id(FK), объем импорта, цена, единицы импорта путь транспорта (воздух, море)) we may use the (product_id , thecountry_id`) для идентификации каждого В строке импорта «если все они в одном и том же году» здесь оба столбца могут составлять вместе первичный ключ в дочерней таблице (импорт), а также ссылаться на родительские таблицы.

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

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

Вы можете на 100% удалить автора из ряда книг и все же можете идентифицировать книгу! ,


5
Вы правы, если у вас есть только таблицы книг и авторов. Там нет идентифицирующих отношений там. Но если вы используете третью таблицу для представления отношения «многие ко многим», первичный ключ этой третьей таблицы состоит из двух внешних ключей, ссылающихся на таблицу книг и таблицу авторов. Эта таблица имеет отношение к книгам и авторам. См. Мой пример в stackoverflow.com/questions/2814469/…
Билл Карвин

8

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

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

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

Отношения между ACCOUNT и PERSON не являются идентифицирующими.

Выявление отношений

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

Это означает, что внешний ключ также является первичным ключом.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

Связь между ITEM_LANG и ITEM является идентифицирующей. И между ITEM_LANG и LANGUAGE тоже.


2
Как ЛИЧНОСТЬ и УЧЕТНАЯ ЗАПИСЬ не идентифицируют? Как может СЧЕТ существовать без ЛИЧНОСТИ?
MrRobot9

почему нет ответа на предыдущий комментарий? @ MrRobot9
AAEM

4

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

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

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

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

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


3

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

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


2

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

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

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

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships


2

Помогают ли атрибуты, перенесенные с родителя на ребенка, идентифицировать 1 ребенка?

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

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

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

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


1 FK ребенка является частью ограничения PRIMARY KEY или (не NULL) UNIQUE ребенка.


1

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

Число, которое идентифицирует позицию, идентифицирует ее только в контексте одного заказа. Первая позиция в каждом заказе - это позиция "1". Полная идентификация позиции - это номер позиции вместе с номером заказа, частью которого она является.

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

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


0

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

user
--------
id
name


comments
------------
comment_id
user_id
text

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


0

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

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

Ссылка на основе Билла Карвина


5
Это может помочь определить, что вы подразумеваете под «сильной» и «слабой» сущностью здесь.
Обнуляемость
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.