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

Question

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

user
--------
id
name


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

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

Answer 4

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

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

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