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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 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% удалить автора из ряда книг и все же можете идентифицировать книгу! ,

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

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

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 тоже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

user
--------
id
name


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

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

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

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

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