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

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

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

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

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

неидентифицирующие отношения определяют регулярную связь между объектами 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 таблица и также ПК на 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: ((, поэтому, пожалуйста, не говорите мне, что я ошибаюсь со всеми этими голосами за a совершенно некорректный пример

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

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

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

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

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

Если дочерний элемент должен быть сохранен, даже если родитель удален, то это неидентифицирующий relatioǹship.

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

user
--------
id
name


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

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

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

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

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

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

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

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

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