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

Question

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

Answer 1

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

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

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

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

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

---

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

Answer 2

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

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

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

Answer 3

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

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

Так вот реальная причина:

Цель идентифицирующего отношения состоит в том, что внешний ключ НИКОГДА НЕ ИЗМЕНЯЕТСЯ , потому что он является частью первичного ключа ... поэтому идентифицирует !!!

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

пользователь 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 строки:

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

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

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

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

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

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

Answer 7

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

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

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

Отношения между СЧЕТОМ и ЛИЦОМ не идентифицируют.

Идентификационные отношения

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

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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

Answer 10

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

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

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

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

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

---

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