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





7 Answers

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

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

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

to push write

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




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

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

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

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




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




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

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




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

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

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

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

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

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




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

user
--------
id
name


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

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




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

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

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




Related