Досі збентежений щодо ідентифікації та неідентифікації відносин

Отже, я читав про виявлення та неідентифікацію відносин у моїй базі даних, і ряд відповідей на SO здаються мені суперечливими. Ось два запитання, які я розглядаю:

1. Яка різниця між виявленням та неідентифікацією стосунків
2. Проблема з прийняттям рішення про встановлення або неідентифікацію стосунків

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

У відповіді на перше запитання йдеться, що ідентифікуючий зв'язок "описує ситуацію, коли існування рядка в дочірній таблиці залежить від рядка в батьківській таблиці". Наведений приклад: "Автор може написати багато книг (співвідношення 1 до n), але книга не може існувати без автора". Для мене це має сенс.

Однак, коли я читаю відповідь на друге запитання, мене бентежить, як там сказано: "якщо дитина ідентифікує свого батька, це ідентифікуючі стосунки". Далі у відповідь наводяться такі приклади, як номер соціального страхування (ідентифікаційний номер особи), але адреса - ні (оскільки багато людей можуть проживати за адресою). Для мене це звучить більше як випадок рішення між первинним та не первинним ключами.

Моє власне відчуття кишечника (і додаткові дослідження на інших сайтах) вказує на перше запитання та відповідь на нього правильним. Однак я хотів перевірити це, перш ніж продовжувати рухатися вперед, оскільки я не хочу вчитися чогось неправильного, оскільки працюю над розумінням дизайну бази даних. Заздалегідь спасибі.

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

CREATE TABLE AuthoredBook (
  author_id INT NOT NULL,
  book_id INT NOT NULL,
  PRIMARY KEY (author_id, book_id),
  FOREIGN KEY (author_id) REFERENCES Authors(author_id),
  FOREIGN KEY (book_id) REFERENCES Books(book_id)
);

Подивитися? book_id- зовнішній ключ, але це також один із стовпців первинного ключа. Отже, ця таблиця має ідентифікаційний зв’язок із таблицею, на яку посилаються Books. Так само вона має ідентифікуючі стосунки з Authors.

Коментар до відео на YouTube має ідентифікаційний зв’язок із відповідним відео. video_id Повинна бути частиною первинного ключа Commentsтаблиці.

CREATE TABLE Comments (
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  PRIMARY KEY (video_id, user_id, comment_dt),
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

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

CREATE TABLE Comments (
  comment_id SERIAL PRIMARY KEY,
  video_id INT NOT NULL,
  user_id INT NOT NULL,
  comment_dt DATETIME NOT NULL,
  FOREIGN KEY (video_id) REFERENCES Videos(video_id),
  FOREIGN KEY (user_id) REFERENCES Users(user_id)
);

Це може приховати випадки, коли таблиці мають ідентифікаційний зв’язок.

Я не вважав би, що SSN представляє ідентифікаційні відносини. Деякі люди існують, але не мають SSN. Інші люди можуть подати документи, щоб отримати новий SSN. Отже, SSN насправді є лише атрибутом, а не частиною первинного ключа людини.

Повторний коментар від @Niels:

Отже, якщо ми використовуємо сурогатний ключ замість складеного первинного ключа, немає помітної різниці між використанням ідентифікуючих чи неідентифікуючих відносин?

Я теж так думаю. Я вагаюся відповісти «так», тому що ми не змінили логічного співвідношення між таблицями, використовуючи сурогатний ключ. Тобто ви все ще не можете зробити коментар без посилання на існуюче відео. Але це просто означає, що video_id не повинен бути НУЛЬНИМ. І логічний аспект для мене справді полягає у визначенні стосунків.

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

Виявлення взаємозв’язків здається важливим лише заради діаграмування взаємозв’язків сутності, і це з’являється в засобах моделювання даних графічного інтерфейсу.

"оскільки я не хочу вчитися чогось неправильного".

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

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

Ніколи діаграма ER не може наблизитися до точності, точності та повноти проекту бази даних, офіційно виписаного в D.

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

Наприклад, припустимо, що ваша таблиця застосовує два ключі-кандидати, A та B. Нехай A також є зовнішнім ключем у цій таблиці. Представлене таким чином відношення вважається "ідентифікуючим", якщо A призначено "первинним" ключем, але воно не ідентифікує, якщо B є первинним ключем. Проте форма, функція та значення таблиці однакові в кожному випадку! Ось чому, на мій погляд, я не вважаю, що поняття ідентифікації / неідентифікації насправді є дуже важливим.

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

частиною питання тут є плутанина термінології. визначення відносин корисно для уникнення довгих шляхів з'єднання.

Найкраще визначення, яке я бачив, це "ідентифікаційні відносини включають ПК від батьків у дочірньому ПК. Іншими словами, ПК дитини включає ФК до батьків, а також" фактичний "ПК дитини.

Так, ідіть із першим, але я не думаю, що другий суперечить першому. Це просто сформульовано трохи заплутано ..

ОНОВЛЕННЯ:

Щойно перевірено - відповідь на друге запитання є неправильною у деяких припущеннях, .. книга-автор не обов'язково має відношення 1: n, як це може бути m: n. У реляційних базах даних, що створює таблицю перетину для цього відношення m: n, ви отримуєте ідентифікаційні відносини між таблицею перетину та іншими двома таблицями.

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

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

Ідентифікаційні стосунки - це справді концепція ERD, оскільки це область концептуального моделювання, що моделює наше розуміння „всесвіту дискурсу”. Це стосунки батьків та дітей, за допомогою яких ми моделюємо той факт, що ідентичність кожного дочірнього об’єкта (принаймні частково) встановлюється / визначається ідентичністю батьківського об’єкта. Тому він є обов’язковим і незмінним.

Приклад у реальному світі - це багаторічний виклик ідентифікації людей. Унікальна ідентичність людини може (частково) визначатися її стосунками з народженою матір’ю та батьком. Коли вони відомі, це незмінні факти. Тому стосунки між народженими батьками та дитиною є ідентифікуючими відносинами, оскільки вони (незмінно) сприяють визначенню особистості дитини.

Саме ці якості та використання реляційних конструкцій dbms призводять до того, що PK дитини є складеним ключем, що включає, через FK, PK батька. Як ПК, особа дитини є обов'язковою і незмінною (вона не може змінитися). "Зміна" в ПК фактично є створенням нового об'єкта. Тому PK не можна змінювати. Слід також обмежити незмінність ПК. Обмеження БД можуть бути використані для реалізації такої якості ПК.