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

Question

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

Answer 1

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

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

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

• Неидентифицирующая связь - это когда атрибуты первичного ключа родительского элемента не должны становиться атрибутами первичного ключа дочернего элемента. Хорошим примером этого является справочная таблица, например внешний ключ на 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

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

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

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

Answer 6

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

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

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 7

Как user287724 второй пример ответа книги и отношения автора получил 576 голосов?!!! как говорится:

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

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

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

---

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

Вы можете удалить автора (FK) из строки книги и все же можете идентифицировать строку книги по некоторому другому полю (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 стол, а также ПК в printers_details Таблица, это идентификационная связь, потому что Product_ID(FK) в таблице принтеров ИДЕНТИФИЦИРУЕТ строку в дочерней таблице, мы не можем удалить product_id из дочерней таблицы, потому что мы больше не можем идентифицировать строку, потому что мы потеряли это первичный ключ

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

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

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

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

Answer 8

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

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

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

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

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

Answer 9

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

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

Answer 10

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

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

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

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

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

---

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

Answer 11

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

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

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

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

Answer 12

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

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

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

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

Answer 13

Дополнение к ответу Дэниела Диннеса:

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

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

Обратите внимание, что не имеет значения, является ли FK "ненулевым" или нет!;-)

Answer 14

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

user
--------
id
name


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

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

Answer 15

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

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

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