Яка різниця між ідентифікаційними та неідентифікаційними стосунками?

Я не зміг повністю зрозуміти відмінності. Чи можете ви описати обидва поняття та використати приклади реального світу?

• Ідентифікації відносин , коли існування рядки в дочірній таблиці залежить від рядка в батьківській таблиці. Це може бути заплутаним, оскільки в наші дні прийнято створювати псевдокілька для дочірньої таблиці, але не робити зовнішній ключ до батьківської частини первинного ключа дитини. Формально "правильний" спосіб зробити це - зробити зовнішній ключ частиною первинного ключа дитини. Але логічна залежність полягає в тому, що дитина не може існувати без батька.

  Приклад: А Personмає один або більше номерів телефонів. Якби у них був лише один номер телефону, ми могли б просто зберегти його у стовпці Person. Оскільки ми хочемо підтримувати декілька телефонних номерів, ми робимо другу таблицю PhoneNumbers, в основний ключ якої person_idпосилається Personтаблиця.

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

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

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

Дивіться також мою відповідь до все ще плутаного щодо виявлення та невизначення відносин

Є ще одне пояснення з реального світу:

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

Проте книгу пише автор, і автор міг написати кілька книг. Але книгу має писати автор - вона не може існувати без автора. Тому відносини між книгою та автором є ототожнюючими відносинами.

Відповідь Білла правильна, але шокуюче бачити, що серед усіх інших відповідей ніхто не вказує на найбільш вагомий аспект.

Повторно і знову говориться, що в ідентифікуванні стосунків дитина не може існувати без батька. (наприклад, user287724 ). Це правда, але повністю пропускає суть. Достатньо, щоб зовнішній ключ був ненульовим, щоб досягти цього. Він не повинен бути частиною первинного ключа.

Тож ось справжня причина:

Мета ідентифікаційного зв’язку полягає в тому, щоб зовнішній ключ НІКОЛИ не міняв , тому що він є частиною первинного ключа ... тому ідентифікуючи !!!

Ідентифікаційне співвідношення вказує, що дочірній об’єкт не може існувати без батьківського об'єкта

Неідентифікаційні відносини визначають регулярну асоціацію між об'єктами, кардинальність 1: 1 або 1: n.

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

Ось хороший опис:

Відносини між двома суб'єктами можуть бути класифіковані як "ідентифікуючі" або "неідентифікуючі". Ідентифікаційні зв'язки існують, коли первинний ключ материнської сутності включений у первинний ключ дочірньої сутності. З іншого боку, неідентифікуючі відносини існують, коли первинний ключ материнської сутності включений у дочірнє сутність, але не є частиною первинного ключа дочірньої сутності. Крім того, неідентифікаційні відносини можуть бути додатково класифіковані як "обов'язкові" або "не обов'язкові". Обов'язкове неідентифікаційне відношення існує, коли значення в дочірній таблиці не може бути нульовим. З іншого боку, необов'язкове неідентифікаційне відношення існує, коли значення в дочірній таблиці може бути нульовим.

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

Відповідь користувача 287724 дає такий приклад стосунків книги та автора:

Однак книга написана автором, і автор міг написати кілька книг. Але книгу має писати автор, вона не може існувати без автора. Тому відносини між книгою та автором є ідентифікаційними відносинами.

Це дуже заплутаний приклад і, безумовно, не є дійсним прикладом для identifying relationship.

Так, bookне може бути написана без принаймні одного author, але author(це зовнішній ключ) з bookце НЕ ВИЗНАЧИТИbook в booksтаблиці!

Ви можете видалити author(FK) з bookрядка і до сих пір можна визначити книгу рядки якої - або іншій області ( 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 рядки:

ідентифікаційне співвідношення - це відношення, коли ФК у дочірній таблиці вважається ПК (або ідентифікатором) у дочірній таблиці, поки він посилається на батьківську таблицю

Інший приклад може бути, коли у вас є три таблиці (імпорт - продукція - країни) для імпорту та експорту для деяких країн

importТаблиця є дитина , який має наступні поля ( product_id(ФК), то country_id(FK), обсяг імпорту, ціна, одиниці імпорту шлях транспорту (повітря, море)) we may use the (product_id , thecountry_id`) для ідентифікації кожного рядок імпорту "якщо вони всі в тому ж році", тут обидва стовпці можуть складати первинний ключ у дочірній таблиці (імпорт), а також посилаючись на там батьківські таблиці.

Будь ласка, я щасливий, що я нарешті зрозумів концепцію, identifying relationshipі non identifying relationship, будь ласка, не кажіть мені, що я помиляюся з усіма цими голосуваннями за абсолютно недійсний приклад

Так, логічно книга не може бути написана без автора, але книгу можна ідентифікувати без автора. Насправді вона не може бути ототожнена з автором!

Ви можете 100% видалити автора з рядка книги і все одно можете ідентифікувати книгу! .

Неідентифікаційні відносини

Неідентифікаційні відносини означають, що дитина пов'язана з батьком, але її можна ідентифікувати самостійно.

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

Якщо ви вважаєте, що дочірній елемент слід видалити, коли батьків вилучено, то це ідентифікаційні відносини.

Якщо дочірній елемент слід зберігати, навіть якщо батьківський вилучений, це відношення, що не визначає.

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

• слухачі мають ідентифікаційний зв’язок із навчальними заняттями
• тренінги мають ідентифікаційний зв’язок із навчальними заняттями
• але слухачі не мають ідентифікаційних стосунків з дипломами

Видаляються лише навчальні заняття, якщо вилучений один із пов’язаних слухачів, навчання чи диплом.

Ідентифікаційне відношення означає, що дочірнє сутність повністю залежить від існування материнської сутності. Приклад таблиці особи та облікового запису облікового запису. Таблиця облікових записів осіб ідентифікується за наявністю лише таблиці рахунків та осіб.

Взаємозв'язок неідентифікації означає, що дочірня таблиця не ідентифікується за наявністю прикладу батьківської таблиці. Є таблиця як тип облікового запису та рахунок account.accounttype не ідентифікується із наявністю таблиці рахунків.

Як добре пояснено у нижченаведеному посиланні, ідентифікаційне відношення дещо нагадує слабке відношення типу сутності до свого батьківського в концептуальній моделі ER. CAD стилі UML для моделювання даних не використовують символи чи поняття ER, а тип відносин: ідентифікаційний, неідентифікаційний та неспецифічний.

Ідентифікуючі стосунки - це стосунки батька / дитини, де дитина є слабким утворенням (навіть у традиційній моделі ЕР його називають ідентифікаційним відношенням), який не має реального первинного ключа за власними атрибутами і тому не може бути визначений однозначно власним . Кожен доступ до дочірньої таблиці, за фізичною моделлю, буде залежати (включаючи семантично) від первинного ключа батьків, який перетворюється на частину або загальну кількість первинного ключа дитини (також є іноземним ключем), що, як правило, призводить до складеного ключа з боку дитини. Можливі існуючі ключі самої дитини є лише псевдо або частковими ключами, недостатніми для ідентифікації жодного примірника цього типу сутності чи сутності, без ПК батька.

Неідентифікуючі відносини - це звичайні відносини (часткові чи тотальні) повністю незалежних наборів сутностей, екземпляри яких не залежать від первинних ключів один одного, щоб бути однозначно ідентифікованими, хоча їм можуть знадобитися зовнішні ключі для часткових або повних відносин, але не як основний ключ дитини. У дитини є свій первинний ключ. Батьківський ідем. Обидва незалежно. Залежно від кардинальності відносин, ПК одного переходить як ФК в інший (N сторона), і якщо частковий, може бути недійсним, якщо є загальним, не повинен бути нульовим. Але, у таких відносинах, ФК ніколи не буде також ПК дитини, як коли це стосується виявлення відносин.

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

Чи допомагають атрибути, перенесені від батьків до дитини, ідентифікувати ¹ дитину?

• Якщо так : ідентифікаційна залежність існує, зв’язок виявляється, і дочірнє утворення є "слабким".
• Якщо ні : залежність від ідентифікації не існує, зв’язок неідентифікується, а дочірнє утворення "сильне".

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

Докладніше про це (та деякі приклади) дивіться у розділі "Виявлення відносин" у Посібнику з методів ERwin .

PS Я усвідомлюю, що я (вкрай) запізнююсь на партію, але я вважаю, що інші відповіді або не зовсім точні (визначаючи це в залежності від існування, а не ідентифікаційної залежності), або дещо химерні. Сподіваємось, ця відповідь надає більше ясності ...

¹ ФК дитини є частиною ОСНОВНОГО КЛЮЧА дитини або (НЕ НУЛЬНИХ) УНІКАЛЬНИХ обмежень.

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

Номер, який ідентифікує позицію, ідентифікує її лише в контексті одного замовлення. Перша позиція в кожному порядку - номер позиції "1". Повна ідентифікація позиції - це номер позиції разом із номером замовлення, частиною якого він є.

Таким чином, взаємовідносини батька між замовленнями та позиціями є ідентифікаційними відносинами. Тісно пов’язана концепція в моделюванні ER походить під назвою "суб'єкт", де позиція - це суб'єкт порядку. Як правило, суб'єкт має обов'язкові відносини дитини та батьків до особи, якій він підпорядковується.

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

Скажімо, у нас є такі таблиці:

user
--------
id
name


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

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

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

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

Довідка на основі Білла Карвіна