Какая разница между идентифицирующей и неидентифицирующей связей?

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

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

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

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

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

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

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

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

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

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

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

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

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 второй ответ пример книги и автор отношения получил 576 голосование ups?!!! , как говорится:

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

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

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

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

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

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

неидентифицирующем отношении

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

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 и языком тоже.

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

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

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

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

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

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

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

do атрибуты перенесены из родительской в дочернюю help определение¹ ребенка?

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

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

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

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

¹ FK ребенка является частью первичного ключа ребенка или (ненулевого) уникального ограничения.

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

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

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

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

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

user
--------
id
name


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

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

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

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

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

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

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

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

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