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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

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

Ответ 10

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

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

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

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

Ответ 11

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

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

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

Ответ 12

Скажем, у нас есть эти таблицы:

user
--------
id
name


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

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

Ответ 13

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

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

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

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