it-roy-ru.com

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

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

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

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

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

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

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


Смотрите также мой ответ на Все еще не понимаете, как идентифицировать и не идентифицировать отношения

1001
Bill Karwin

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

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

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

860
user287724

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

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

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

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

24
Daniel Dinnyes

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

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

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

24
CMS

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

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

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
14
Andy White

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

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

Это очень запутанный пример и определенно недопустимый пример для 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 (FK), country_id (FK), объем импорта, цена, импортированные единицы, способ транспортировки (воздух, море)) we may use the (product_id, thecountry_id`) для идентифицировать каждую строку импорта, "если они все в одном и том же году", здесь оба столбца могут составлять первичный ключ в дочерней таблице (импорт), а также ссылаться на родительские таблицы.

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

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

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

10
Accountant م

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

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

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

7
Skarllot

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

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

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

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

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

3
Daishi

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

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

3
chanchal dixit

Идентифицируют ли атрибуты, перенесенные из родительской в ​​дочернюю помощь 1 ребенок?

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

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

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

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


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

2
Branko Dimitrijevic

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

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

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

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

1
Daniel Pinheiro

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

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

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

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

1
Walter Mitty

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

user
--------
id
name


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

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

0
Sarvar Nishonboev

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

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

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

0
sp1rs