4.1 Вступ

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

Теоретично всі сутності можуть підтримувати між собою зв'язки, проте на практиці виділяється три різновиди зв'язків між сутностями:

  • Один до одного
  • Один до багатьох
  • Багато хто до багатьох

4.2 Зв'язок "один до одного"

Якщо на кожен екземпляр сутності Б припадає лише один екземпляр сутності А, вважається, що між ними існує зв'язок один до одного (який часто позначається «1:1»). На ER-діаграмах такий зв'язок позначається лінією з невеликою межею на кожному кінці:

Зв'язок 1:1 зазвичай вказує на те, що, якщо у вас немає вагомих причин тримати їх окремо, дані двох таблиць найкраще об'єднати в одну.

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

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

4.3 Зв'язок «один до багатьох»

Відносини такого роду виникають, коли запис однієї таблиці пов'язані з кількома сутностями інший. Наприклад, той самий клієнт міг розмістити кілька замовлень, а відвідувач бібліотеки — за один візит запозичити відразу кілька книг. Зв'язки «один до багатьох» (або скорочено «1:М») виражаються на схемі у вигляді нотації «воронячі лапки», як показано на прикладі нижче:

Щоб застосувати зв'язок 1:М при плануванні бази даних, просто додайте первинний ключ з таблиці "один" як атрибут до таблиці "багато". Якщо первинний ключ знаходиться в іншій таблиці, він має назву «зовнішній ключ». Таблиця «один» вважається батьківською, тоді як таблиця «багато» — дочірня.

4.4 Зв'язок «багато хто до багатьох»

Коли кілька сутностей однієї таблиці можуть бути з'єднані з декількома сутностями іншої, вважається, що між ними існує зв'язок типу «багато хто до багатьох» (або «М:М»). Наприклад, такий зв'язок існує між студентами та заняттями, оскільки кожен студент може відвідати декілька різних занять, а на кожне заняття, відповідно, може прийти безліч студентів.

На ER-діаграмі цей тип зв'язку відображається так:

На жаль, безпосередньо реалізувати такий зв'язок у базі даних неможливо. Тому її доведеться розбити на два зв'язки на кшталт «один до багатьох».

Для цього вам знадобиться створити нову сутність між двома таблицями. Якщо зв'язок М:М встановлений між продажами та товарами, нову сутність можна назвати «продані товари», оскільки в ній буде представлений вміст кожного продажу.

З «проданими товарами» і в таблиці «продажу», і в таблиці «товари» буде встановлено зв'язок типу 1:М. У різних моделях такі проміжні сутності називаються по-різному - "сполучні таблиці", "асоціативні сутності" або "вузлові таблиці".

Кожен запис сполучної таблиці поєднує між собою дві різні сутності сусідніх таблиць (а також може містити додаткову інформацію). Наприклад, сполучна таблиця між студентами та заняттями може виглядати так:

4.5 Обов'язково чи ні?

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

Наприклад, щоб у держави був власний представник в ООН, вона має існувати на карті світу, проте твердження про протилежне буде хибним:

Дві сутності можуть бути взаємозалежними (тобто одна не може існувати без іншої).

Рекурсивні зв'язки

Іноді таблиця може посилатися на себе. Наприклад, у таблиці співробітників може бути атрибут «менеджер», який відсилатиме нас до іншого співробітника в тій же таблиці. Це і є рекурсивний зв'язок.

Зайві зв'язки

Зв'язки вважаються зайвими, якщо вони виражаються більше одного разу. Як правило, одну можна видалити без втрати важливої ​​інформації. Наприклад, якщо сутність «студенти» пов'язані з сутністю «викладачі» як безпосередньо, а й опосередковано через «заняття», є сенс видалити зв'язок між сутностями «студенти» і «викладачі». Обґрунтовано це рішення тим, що призначити студентів викладачам можна лише за допомогою занять.

4.6 Посилальна цілісність даних

При зміні первинних і зовнішніх ключів слід дотримуватися такого аспекту, як посилальна цілісність даних (referential integrity). Її основна ідея у тому, щоб дві таблиці у базі даних, які зберігають одні й самі дані, підтримували їх узгодженість.

Цілісність даних представляє правильно збудовані відносини між таблицями з коректною установкою посилань між ними. У яких випадках цілісність даних може порушуватися:

  • Аномалія вилучення (deletion anomaly). Виникає у разі видалення рядка з головної таблиці. У цьому випадку зовнішній ключ із залежної таблиці продовжує посилатися на віддалений рядок із головної таблиці.
  • Аномалія вставки (insertion anomaly). Виникає при вставці рядка у залежну таблицю. У цьому випадку зовнішній ключ із залежної таблиці не відповідає первинному ключу жодного з рядків із головної таблиці.
  • Аномалії оновлення (update anomaly). При подібній аномалії кілька рядків однієї таблиці можуть містити дані, які належать одному й тому об'єкту. При зміні даних в одному рядку вони можуть суперечити даними з іншого рядка.

Аномалія видалення

Для вирішення аномалії видалення зовнішнього ключа слід встановлювати одне з двох обмежень:

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

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

Аномалія вставки

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

Аномалії оновлення

Для вирішення проблеми аномалії оновлення застосовується нормалізація, яку було розглянуто раніше.

Вебінар JavaRush