non identifying relationship что это
Какая разница между идентифицирующими и неидентифицирующими отношениями?
Я не смог полностью понять различия. Можете ли вы описать обе концепции и использовать примеры реального мира?
ОТВЕТЫ
Ответ 1
идентифицирующая связь заключается в том, что существование строки в дочерней таблице зависит от строки в родительской таблице. Это может сбивать с толку, потому что в наши дни это обычная практика, чтобы создать псевдокей для дочерней таблицы, но не сделать внешний ключ родительской частью дочернего первичного ключа. Формально «правильный» способ сделать это состоит в том, чтобы сделать внешнюю ключевую часть дочернего первичного ключа. Но логическая связь заключается в том, что ребенок не может существовать без родителя.
Мы можем думать о номере (телефонах), принадлежащем человеку, хотя они моделируются как атрибуты отдельной таблицы. Это сильная подсказка, что это идентифицирующая связь (даже если мы не будем в буквальном смысле включать person_id в первичный ключ PhoneNumbers ).
Не идентифицирующее отношение может быть необязательным или обязательным, что означает, что столбец внешнего ключа допускает NULL или запрещает NULL соответственно.
Ответ 2
В реальном мире есть еще одно объяснение:
Ответ 3
Определяющее отношение указывает, что дочерний объект не может существуют без родительского объекта
Неидентифицирующие отношения задают регулярную ассоциацию между объектами, 1:1 или 1: n.
Не идентифицирующие отношения могут быть указаны как необязательные, если родительский элемент не является обязательный или обязательный, если требуется родитель родительская таблица.
Ответ 4
Вот хорошее описание:
Отношения между двумя объектами могут быть классифицированы как «идентифицирующие» или «не идентифицирующие». Идентификация отношений существует, когда первичный ключ родительского объекта включен в первичный ключ дочернего объекта. С другой стороны, неидентифицирующая связь существует, когда первичный ключ родительского объекта включен в дочерний объект, но не как часть первичного ключа дочернего объекта. Кроме того, не идентифицирующие отношения могут быть далее классифицированы как «обязательные» или «необязательные». Обязательная неидентификационная связь существует, когда значение в дочерней таблице не может быть нулевым. С другой стороны, необязательная неидентификационная связь существует, когда значение в дочерней таблице может быть нулевым.
Вот простой пример идентифицирующего отношения:
Здесь соответствующее неидентифицирующее соотношение:
Ответ 5
Не идентифицирующие отношения
Не идентифицирующая связь означает, что ребенок связан с родителем, но он может быть идентифицирован по своему усмотрению.
Отношения между ACCOUNT и PERSON не идентифицируются.
Идентификация отношения
Относительная взаимосвязь означает, что родительский элемент необходим для присвоения личности ребенку. Ребенок существует только из-за родителя.
Это означает, что внешний ключ также является первичным ключом.
Отношения между ITEM_LANG и ITEM определяются. И между ITEM_LANG и LANGUAGE тоже.
Ответ 6
Ответ на ответ правильный, но шокирует, что среди всех других ответов никто не указывает на наиболее важный аспект.
Снова и снова говорят, что в и идентифицирующем отношении ребенок не может существовать без родителя. (например, user287724). Это правда, но полностью упускает из виду. Для этого достаточно, чтобы внешний ключ был не нулевым, чтобы достичь этого. Он не должен быть частью первичного ключа.
Итак, вот настоящая причина:
Цель идентифицирующего отношения заключается в том, что внешний ключ НЕ МОЖЕТ ИЗМЕНИТЬ, поскольку он является частью первичного ключа. поэтому идентификация.
Ответ 7
как user287724 второй ответный пример книги и авторских отношений получил 576 голосов up. как говорится:
Однако книга написана автором, и автор мог написать несколько книг. Но книга должна быть написана автором, она не может существовать без автора. Поэтому связь между книгой и автором является идентифицирующей связью.
Я, наконец, понимаю разницу между обоими отношениями: ((, поэтому, пожалуйста, не путайте меня с этим количеством голосов!
да, книга не может быть написана без хотя бы одного автора, но автор (это внешний ключ) книги НЕ ИДЕНТИФИКАЦИЯ книги в таблице книг!
вы можете удалить автора (FK) из строки книги и по-прежнему можете идентифицировать строку книги каким-либо другим полем (ISBN, ID. и т.д.), НО НЕ автор книги!!
Я считаю, что допустимым примером identifying relationship будет соотношение между (таблица продуктов) и (таблица конкретных продуктов) 1:1
если вы хотите поместить его в две строки:
идентифицирующее отношение является отношением, когда FK в дочерняя таблица считается PK (или идентификатором) в дочерней таблице, тогда как все еще ссылается на родительскую таблицу
пожалуйста, я рад, что, наконец, понимаю концепцию identifying relationship и non identifying relationship : ((), поэтому, пожалуйста, не говорите мне, что я ошибаюсь во всех этих голосованиях для полностью недействительного примера
да логически книга не может быть написана без автора, но книга может быть идентифицирована без автора, на самом деле она не может быть идентифицирована с автором!
Ответ 8
Идентификация relaionship означает, что дочерний объект полностью зависит от существования родительского объекта. Пример таблицы персонализированной таблицы учетных записей и personaccount. Таблица учетных записей пользователей определяется только наличием таблицы учета и персоны.
Несвязанное отношение означает, что дочерняя таблица не идентифицируется по наличию родительской таблицы Например, есть таблица как тип учетной записи, а таблица account.accounttype не идентифицируется с наличием таблицы счетов.
Ответ 9
Если вы считаете, что дочерний элемент должен быть удален при удалении родителя, то это идентифицирующая связь.
Если дочерний элемент должен быть сохранен, даже если родитель удален, то это не идентифицирующий реляционный файл.
В качестве примера у меня есть учебная база данных со стажерами, тренингами, дипломами и учебными занятиями:
Только учебные занятия должны быть удалены, если один из связанных стажеров, учебных курсов или дипломов удален.
Ответ 10
Таким образом, отношения между дочерними элементами между заказами и позициями являются идентифицирующими. Тесно связанную концепцию в ER-моделировании занимает название «subentity», где позиция является сущностью порядка. Как правило, субобъект имеет обязательное отношение идентификации родителя-родителя к сущности, подчиненной ему.
В классическом дизайне базы данных основным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые из современных дизайнеров предоставили элементу отдельный ItemID, который служит в качестве первичного ключа и автоматически учитывается СУБД. В этом случае я рекомендую классический дизайн.
Ответ 11
Относительная связь между двумя сильными сущностями. Неидентифицирующее отношение не всегда может быть отношением между сильным сущностью и слабым сущностью. Там может существовать ситуация, когда сам ребенок имеет первичный ключ, но существование его объекта может зависеть от его родительского объекта.
Например: отношения между продавцом и книгой, в которой продается книга продавцом, могут существовать там, где у продавца может быть свой первичный ключ, но его сущность создается только тогда, когда книга продается
Ссылка, основанная на Билле Карвине
Ответ 12
Скажем, у нас есть эти таблицы:
связь между этими двумя таблицами будет идентифицировать отношения. Потому что комментарии могут принадлежать только его владельцу, а не другим пользователям. например. Каждый пользователь имеет собственный комментарий, а когда пользователь удаляется, комментарии этого пользователя также должны быть удалены.
Ответ 13
Как хорошо объяснено в приведенной ниже ссылке, идентифицирующее отношение несколько напоминает слабое отношение типа объекта к его родительскому элементу в концептуальной модели ER. CAD-модели UML для моделирования данных не используют символы или концепции ER, а вид отношений: идентификация, неидентификация и неспецифичность.
Идентифицирующими являются отношения parent/child, где ребенок является видом слабого объекта (даже в традиционной модели ER, называемой идентифицирующей связью), которая не имеет реального первичного ключа по своим собственным атрибутам и поэтому не может быть однозначно идентифицирована по своему усмотрению. Каждый доступ к дочерней таблице на физической модели будет зависеть (включительно семантически) от родительского первичного ключа, который превращается в часть или итог дочернего первичного ключа (также являющегося внешним ключом), как правило, приводя к созданию сложного ключа на детской стороне. Возможными существующими ключами самого ребенка являются только псевдо-или частичные ключи, не достаточные для идентификации любого экземпляра этого типа Entity или Entity Set без родительского PK.
Неидентифицирующими отношениями являются обычные отношения (частичные или тотальные), полностью независимые сущности, экземпляры которых не зависят от первичных ключей друг от друга, которые должны быть однозначно идентифицированы, хотя им могут потребоваться внешние ключи для частичных или тотальных отношений, но не как первичный ключ ребенка. У ребенка есть свой первичный ключ. Родительский idem. Оба они независимы. В зависимости от мощности отношения, PK одного идет как FK к другому (сторона N), а если частичная, может быть нулевой, если total, должна быть не нулевой. Но в такой ситуации FK никогда не будет PK ребенка, так как когда идентифицирующая связь имеет место.
Какая разница между идентифицирующей и неидентифицирующей связей?
Я не смог полностью понять различия. Можете ли вы описать обе концепции и использовать примеры из реального мира?
14 ответов
An определение отношения это когда существование строки в дочерней таблице зависит от строки в родительской таблице. Это может быть запутанным, потому что в наши дни распространена практика создания псевдокея для дочерней таблицы, но не сделайте внешний ключ к родительской части первичного ключа ребенка. Формально «правильный» способ сделать это-сделать внешний ключ частью первичного ключа ребенка. Но логическая связь заключается в том, что ребенок не может существовать без родителя.
мы можем думать о телефонном номере(ах) как принадлежащем человеку, даже если они моделируются как атрибуты отдельной таблицы. Это сильный ключ к тому, что это идентифицирующие отношения (даже если мы буквально не включаем person_id в первичном ключе PhoneNumbers ).
неидентифицирующие отношения могут быть дополнительно или обязательное, что означает, что столбец внешнего ключа позволяет NULL или запрещает NULL соответственно.
есть еще одно объяснение из реального мира:
книга принадлежит владельцу, а владелец может владеть несколькими книгами. Но, книга может существовать и без владельца, а собственность на нее может меняться от одного владельца к другому. Отношения между книгой и владельцем-это неидентифицирующие отношения.
идентифицирующая связь указывает, что дочерний объект не может существовать без родительского объекта
неидентифицирующие отношения указывает регулярную связь между объектами 1:1 или 1:n количество элементов.
неидентифицирующие отношения могут быть указаны как необязательные, если родитель не обязательными, где родитель требует установки родительская таблица мощности.
Билл правильно, но это видеть что среди всех других ответов никто не указывает на самый существенный аспект.
говорят снова и снова, что в и идентифицирующих отношениях ребенок не может существовать без родителя. (например,user287724). Это верно, но совершенно упускает суть. Этого было бы достаточно, чтобы внешний ключ был non-null, чтобы добиться этого. Не нужно быть частью первичного ключа.
так вот настоящая причина:
цель идентифицирующих отношений заключается в том, что внешний ключ никогда не может измениться, потому что это часть первичного ключа. определение.
вот хорошее описание:
отношения между двумя сущностями могут быть классифицированы как «идентифицирующие»или» не идентифицирующие». Существует определение отношения, когда первичный ключ родительской сущности входят в первичный ключ дочерней сущности. С другой стороны, неидентифицирующая связь существует, когда первичный ключ родительской сущности включен в дочернюю сущность, но не является частью первичного ключа дочерней сущности. Кроме того, неидентификация отношения могут быть далее классифицированы как» обязательные «или»необязательные». Обязательное неидентифицирующее отношение существует, когда значение в дочерней таблице не может быть null. С другой стороны, необязательное неидентифицирующее отношение существует, когда значение в дочерней таблице может быть null.
вот простой пример определения отношения:
вот соответствующее неидентифицирующее отношение:
книга, однако, написана автором, и автор мог бы написать несколько книг. Но книга должна быть написана автором, он не может существовать без автора. Таким образом, отношения между книгой и автором являются идентифицирующими отношениями.
я, наконец, понимаю разницу между обоими отношениями: ((, поэтому, пожалуйста,не путайте меня с этим количеством голосов!!
да, книга не может быть написана без хотя бы одного автора, но автор(это внешний ключ), книги НЕ ИДЕНТИФИЦИРУЯ книга в таблице книг!
я думаю, что действительный пример identifying relationship будет отношением между (таблица продуктов) и (таблица конкретных сведений о продукте) 1:1
в этом примере Product_ID на printers_details таблица считается FK ссылается на products.id таблица и также PK на printers_details таблица, это идентифицирующая связь потому что Product_ID (FK) в таблице принтеров ИДЕНТИФИЦИРУЕТ строка внутри дочерней таблицы мы не можем удалить product_id из дочерней таблицы, потому что мы больше не можем идентифицировать строку, потому что мы потеряли ее первичный ключ
если вы хотите поместить его в 2 строки:
идентифицирующим отношением является отношение, когда FK в дочерняя таблица считается PK (или идентификатором) в дочерней таблице, в то время как все еще ссылается на родителя таблица
другой пример может быть, когда у вас есть 3 таблицы (импорт-продукты-страны) в импорте и экспорте для базы данных некоторых стран
пожалуйста, я рад, что наконец-то понял концепцию identifying relationship и non identifying relationship : ((, поэтому, пожалуйста, не говорите мне, что я не прав со всеми этими голосами за совершенно некорректный пример
да логически книга не может быть написана без автора, но книга может быть идентифицирована без автора, на самом деле она не может быть идентифицирована с автором!
неидентифицирующем отношении
неидентифицирующие отношения означают, что ребенок связан с родителем, но может быть идентифицирован своим собственным.
связь между учетной записью и лицом не идентифицируется.
определение отношения
идентифицирующая связь означает, что родитель нужен, чтобы дать личности ребенка. Ребенок существует исключительно благодаря родителю.
этот означает, что внешний ключ-это первичный ключ.
связь между ITEM_LANG и ITEM идентифицирует. И между ITEM_LANG и языком тоже.
идентификация relaionship означает, что дочерняя сущность полностью зависит от существования родительской сущности. Пример таблицы учетных записей person table и personaccount.Таблица счета лица определяется только существованием таблицы счета и лица.
не идентифицирующее отношение означает, что дочерняя таблица не идентифицируется существованием родительской таблицы пример есть таблица как accounttype и account.таблица accounttype не идентифицируется с существованием таблица счетов.
Если вы считаете, что дочерний элемент должен быть удален при удалении родительского элемента, то это идентифицирующее отношение.
Если дочерний элемент должен храниться, даже если родитель удален, то это неидентифицирующее отношение.
в качестве примера, у меня есть обучающая база данных с обучаемыми, тренингами, дипломами и тренировками:
только учебные занятия должны быть удалены, если один из связанных стажера, обучение или диплом удаляется.
do атрибуты перенесены из родительской в дочернюю help определение 1 ребенка?
обратите внимание, что идентификация-зависимость подразумевает существование-зависимость, но не наоборот. Каждый ненулевой FK означает, что ребенок не может существовать без родителя, но это само по себе не делает идентификацию отношений.
для получения дополнительной информации об этом (и некоторых примерах), взгляните на раздел «идентификация отношений»Руководство По Методам ERwin.
P. S. Я понимаю, что я (очень) опоздал на вечеринку, но я чувствую, что остальные ответы являются не совсем точными (определение его в терминах существования-зависимость вместо идентификации-зависимость), или несколько извилистая. Надеюсь, этот ответ даст больше ясности.
1 FK ребенка является частью первичного ключа ребенка или (ненулевого) уникального ограничения.
хорошим примером является обработка заказов. Заказ от клиента обычно имеет номер заказа, который идентифицирует заказ, некоторые данные, которые происходят один раз на заказ, такие как дата заказа и идентификатор клиента, и ряд позиций строки. Каждая номенклатура строки содержит номер номенклатуры, идентифицирующий номенклатуру строки в заказе, заказанный продукт, количество этого продукта, цену продукта и сумму для номенклатуры строки, которая может быть вычислена путем умножения количества на цена.
в классическом дизайне базы данных первичным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые современные дизайнеры дадут пункту отдельный идентификатор элемента, который служит в качестве первичного ключа, и несколькими СУБД. В этом случае я рекомендую классический дизайн.
Допустим, у нас есть эти таблицы:
связь между этими двумя таблицами будет идентифицировать связь. Потому что комментарии могут принадлежать только его владельцу, а не другим пользователям. например. У каждого пользователя есть свой комментарий, и когда пользователь удаляется, комментарии этого пользователя также должны быть удалены.
Как хорошо объяснено в приведенной ниже ссылке, идентифицирующее отношение несколько похоже на слабое отношение типа сущности к своему родителю в концептуальной модели ER. CAD в стиле UML для моделирования данных не используют ER-символы или понятия, а отношения: идентифицирующие, неидентифицирующие и неспецифические.
идентифицирующими являются отношения родитель / ребенок, где ребенок является слабой сущностью (даже в традиционной модели ER ее называют идентифицирующей связью), которая не имеют реальный первичный ключ по своим собственным атрибутам и поэтому не могут быть идентифицированы однозначно по своим собственным. Каждый доступ к дочерней таблице на физической модели будет зависеть (включая семантически) от первичного ключа родителя, который превращается в часть или сумму первичного ключа ребенка (также являющегося внешним ключом), что обычно приводит к составному ключу на дочерней стороне. Возможные существующие ключи самого ребенка являются только псевдо-или частичными ключами, недостаточными для идентификации любого экземпляра этот тип сущности или набора сущностей без родительского ПК.
неидентифицирующие отношения-это обычные отношения (частичные или полные) полностью независимых наборов сущностей, экземпляры которых не зависят от уникальных первичных ключей друг друга, хотя им могут потребоваться внешние ключи для частичных или полных отношений, но не как первичный ключ ребенка. У ребенка есть свой первичный ключ. Родитель идем. Оба независимо. В зависимости от мощности отношение, PK одного идет как FK к другому (n стороне), и если частичное, может быть нулевым, если полное, должно быть не нулевым. Но в таких отношениях FK никогда не будет также ПК ребенка, как в случае идентифицирующих отношений.
идентифицирующая связь между двумя сильными сущностями. Неидентифицирующие отношения не всегда могут быть отношениями между сильной сущностью и слабой сущностью. Может существовать ситуация, когда сам ребенок имеет первичный ключ, но существование его сущности может зависеть от его родительской сущности.
например: отношения между продавцом и книгой, где книга продается продавцом, могут существовать, когда продавец может иметь свой собственный первичный ключ, но его сущность создана только когда книга продается
В чем разница между идентифицирующими и неидентифицирующими отношениями?
Я не смог полностью понять различия. Можете ли вы описать обе концепции и использовать примеры из реального мира?
Мы можем думать о телефонных номерах как о принадлежащих человеку, даже если они смоделированы как атрибуты отдельной таблицы. Это сильный признак того, что это идентифицирующие отношения (даже если мы не включаем их буквально person_id в первичный ключ PhoneNumbers ).
Есть еще одно объяснение из реального мира:
Ответ Билла правильный, но шокировать тот факт, что среди всех остальных ответов никто не указывает на самый важный аспект.
Снова и снова говорится, что в идентифицирующих отношениях ребенок не может существовать без родителя. (например, user287724 ). Это правда, но совершенно не соответствует сути. Для этого достаточно, чтобы внешний ключ был ненулевым, чтобы достичь этого. Это не должно быть частью первичного ключа.
Так вот настоящая причина:
Идентификационная связь указывает, что дочерний объект не может существовать без родительского объекта.
Неидентифицирующие отношения определяют регулярную связь между объектами, 1: 1 или 1: n кардинальности.
Вот хорошее описание:
Отношения между двумя объектами могут быть классифицированы как «идентифицирующие» или «неидентифицирующие». Идентификационные отношения существуют, когда первичный ключ родительского объекта включен в первичный ключ дочернего объекта. С другой стороны, неидентифицирующая связь существует, когда первичный ключ родительского объекта включен в дочерний объект, но не является частью первичного ключа дочернего объекта. Кроме того, неидентифицирующие отношения могут быть дополнительно классифицированы как «обязательные» или «необязательные». Обязательная неидентифицирующая связь существует, когда значение в дочерней таблице не может быть нулевым. С другой стороны, существует необязательная неидентифицирующая связь, когда значение в дочерней таблице может быть нулевым.
Вот простой пример идентификации отношений:
Вот соответствующие неидентифицирующие отношения:
Ответ user287724 дает следующий пример отношения книги и автора:
Однако книга написана автором, и автор мог написать несколько книг. Но книга должна быть написана автором, она не может существовать без автора. Следовательно, отношения между книгой и автором являются идентифицирующими отношениями.
Я думаю, что правильным примером identifying relationship будет связь между (таблица продуктов) и (таблица данных конкретного продукта) 1:1
Если вы хотите поместить его в 2 строки:
Да, логически книга не может быть написана без автора, но книга может быть идентифицирована без автора, на самом деле она не может быть идентифицирована с автором!
Неидентифицирующая связь
Неидентифицирующая связь означает, что ребенок связан с родителем, но его можно идентифицировать самостоятельно.
Отношения между ACCOUNT и PERSON не являются идентифицирующими.
Выявление отношений
Идентификационные отношения означают, что родитель необходим для идентификации личности ребенка. Ребенок существует исключительно из-за родителя.
Это означает, что внешний ключ также является первичным ключом.
Связь между ITEM_LANG и ITEM является идентифицирующей. И между ITEM_LANG и LANGUAGE тоже.
Если вы считаете, что дочерний элемент должен быть удален при удалении родительского элемента, то это идентифицирующая связь.
Если дочерний элемент следует сохранить, даже если родительский элемент удален, то это неидентифицирующая связь.
Например, у меня есть учебная база данных с обучаемыми, тренингами, дипломами и тренингами:
Только тренинги должны быть удалены, если один из связанных стажер, обучение или диплом удаляются.
Идентификационная связь означает, что дочерняя сущность полностью зависит от существования родительской сущности. Пример таблицы счетов таблицы person и personaccount. Таблица счетов person определяется только наличием таблицы account и person.
Неидентифицирующая связь означает, что дочерняя таблица не идентифицируется существованием примера родительской таблицы. Существует таблица как accounttype, а таблица account.accounttype не идентифицируется с существованием таблицы account.
Как хорошо объяснено в приведенной ниже ссылке, идентифицирующее отношение в некоторой степени похоже на слабое отношение типа сущности к его родителю в концептуальной модели ER. В САПР в стиле UML для моделирования данных не используются символы или понятия ER, и тип отношений: идентифицирующий, неидентифицирующий и неспецифичный.
Помогают ли атрибуты, перенесенные с родителя на ребенка, идентифицировать 1 ребенка?
Обратите внимание, что идентификация-зависимость подразумевает существование-зависимость, но не наоборот. Каждый ненулевой FK означает, что ребенок не может существовать без родителя, но это само по себе не позволяет идентифицировать отношения.
1 FK ребенка является частью ограничения PRIMARY KEY или (не NULL) UNIQUE ребенка.
В классическом дизайне базы данных первичным ключом таблицы LineItems будет (OrderNumber, ItemNumber). Некоторые из современных дизайнеров присваивают элементу отдельный ItemID, который служит первичным ключом и автоматически внедряется СУБД. Я рекомендую классический дизайн в этом случае.
Допустим, у нас есть эти таблицы:
Отношения между этими двумя таблицами будут определять отношения. Потому что только комментарии могут принадлежать его владельцу, а не другим пользователям. например. Каждый пользователь имеет свой комментарий, и когда пользователь удаляется, комментарии этого пользователя также должны быть удалены.
Идентифицирующая связь между двумя сильными сущностями. Неидентифицирующие отношения не всегда могут быть отношениями между сильной и слабой сущностью. Может существовать ситуация, когда у самого ребенка есть первичный ключ, но существование его объекта может зависеть от его родительского объекта.
Например: отношения между продавцом и книгой, когда книга продается продавцом, могут существовать, когда продавец может иметь свой собственный первичный ключ, но его сущность создается только тогда, когда книга продается