1. Вступ
Перетворивши таблиці бази даних на звичайні таблиці, ти можеш проаналізувати зв'язки, що є між ними. Кількість елементів, що взаємодіють між двома зв'язаними таблицями, називається кардинальністю. Кардинальність допоможе тобі проконтролювати, наскільки ефективно дані розбито на таблиці.
Теоретично всі сутності можуть підтримувати між собою зв'язки, проте на практиці виділяються три різновиди зв'язків між сутностями:
- Один до одного
- Один до багатьох
- Багато багатьох
2. Зв'язок один до одного
Якщо на кожен екземпляр сутності Б припадає лише один екземпляр сутності А, вважається, що між ними існує зв'язок один до одного (який часто позначається 1:1). На ER-діаграмах такий зв'язок позначається лінією з невеликою межею на кожному кінці:
Зв'язок 1:1 зазвичай вказує на те, що, якщо в тебе немає вагомих причин тримати їх окремо, дані двох таблиць краще об'єднати в одну.
Проте, за деяких обставин, використання таблиць зі зв'язками 1:1 цілком доцільно. Якщо у твоїх таблицях є поля з необов'язковими даними, наприклад описами, і в багатьох випадках вони порожні, є сенс перенести всі описи до окремої таблиці, що дозволить тобі позбавитися частих прогалин і підвищити ефективність роботи своєї бази даних.
Потім, щоб правильно зіставити дані, тобі доведеться включити як мінімум один ідентичний стовпець до кожної таблиці (для цього краще вибрати первинний ключ).
3. Зв'язок один до багатьох
Відносини такого роду виникають, коли запис однієї таблиці пов'язаний з декількома сутностями іншої. Наприклад, той самий клієнт міг розмістити кілька замовлень, а відвідувач бібліотеки за один візит запозичити одразу декілька книг. Зв'язки «один до багатьох» (або скорочено «1:М») виражаються на схемі у вигляді нотації «воронячої лапки», як показано на прикладі нижче:
Щоб застосувати зв'язок 1:М під час планування бази даних, просто додай первинний ключ з таблиці «один» як атрибут до таблиці «багато». Якщо первинний ключ знаходиться в іншій таблиці, він має назву «зовнішній ключ». Таблиця «один» вважається батьківською, тоді як таблиця «багато» — дочірня.
4. Зв'язок «багато до багатьох»
Коли кілька сутностей однієї таблиці можуть бути з'єднані з декількома сутностями іншої, вважається, що між ними існує зв'язок типу «багато до багатьох» (або «М:М»). Наприклад, такий зв'язок існує між студентами та заняттями, оскільки кожен студент може відвідати кілька різних занять, а на кожне заняття, відповідно, може прийти багато студентів.
На ER-діаграмі цей тип зв'язку відображається так:
На жаль, безпосередньо реалізувати такий зв'язок у базі даних неможливо. Тому її доведеться розбити на два зв'язки на кшталт «один до багатьох».
Для цього тобі знадобиться створити нову сутність між двома таблицями. Якщо зв'язок М:М встановлений між продажами та товарами, нову сутність можна назвати «продані товари», оскільки в ній буде представлений вміст кожного продажу.
З «проданими товарами» і в таблиці «продажу», і в таблиці «товари» буде встановлено зв'язок типу 1:М. У різних моделях такі проміжні сутності називаються по-різному — «сполучні таблиці», «асоціативні сутності» або «вузлові таблиці».
Кожний запис сполучної таблиці поєднує між собою дві різні сутності сусідніх таблиць (а також може містити додаткову інформацію). Наприклад, сполучна таблиця між студентами та заняттями може виглядати так:
5. Обов'язково чи ні?
Ще один підхід до аналізу зв'язків полягає в тому, щоб встановити, яка зі сполучених сутностей є обов'язковою умовою наявності іншої сутності. Необов'язкова сторона зв'язку відзначається довкола сполучної лінії.
Наприклад, щоб у держави був власний представник в ООН, вона має існувати на карті світу, проте твердження про протилежне буде хибним:
Дві сутності можуть бути взаємозалежними (тобто одна не може існувати без іншої).
Рекурсивні зв'язки
Іноді таблиця може посилатися на себе. Наприклад, у таблиці співробітників може бути атрибут «менеджер», який відсилатиме нас до іншого співробітника в тій же таблиці. Це і є рекурсивний зв'язок.
Зайві зв'язки
Зв'язки вважаються зайвими, якщо вони виражаються більше ніж один раз. Як правило, один можна видалити без втрати важливої інформації. Наприклад, якщо сутність «студенти» пов'язані з сутністю «викладачі» не лише безпосередньо, а й опосередковано, через «заняття», є сенс видалити зв'язок між сутностями «студенти» і «викладачі». Обґрунтовано це рішення тим, що призначити студентів викладачам можна лише за допомогою занять.
6. Цілісність посилань даних
Під час зміни первинних та зовнішніх ключів слід дотримуватись такого аспекту як посилальна цілісність даних (referential integrity). Її основна ідея полягає в тому, щоб дві таблиці в базі даних, які зберігають ті самі дані, підтримували їхню узгодженість.
Цілісність даних являє собою правильно збудовані відносини між таблицями з коректною установкою посилань між ними. У яких випадках цілісність даних може порушуватись:
- Аномалія видалення (deletion anomaly). Виникає у разі видалення рядка з головної таблиці. У цьому випадку зовнішній ключ із залежної таблиці продовжує посилатися на віддалений рядок із головної таблиці.
- Аномалія вставки (insertion anomaly). Виникає при вставці рядка у залежну таблицю. У цьому випадку зовнішній ключ із залежної таблиці не відповідає первинному ключу жодного рядка з головної таблиці.
- Аномалії оновлення (update anomaly). При подібній аномалії кілька рядків однієї таблиці можуть містити дані, які належать одному й тому об'єкту. Під час зміни даних в одному рядку вони можуть суперечити даними з іншого рядка.
Аномалія видалення
Для вирішення аномалії видалення для зовнішнього ключа слід встановлювати одне з двох обмежень:
Якщо рядок із залежної таблиці обов'язково вимагає наявності рядка із головної таблиці, то для зовнішнього ключа встановлюється каскадне видалення. Тобто при видаленні рядка із головної таблиці відбувається видалення зв'язаного рядка (рядків) із залежної таблиці.
Якщо рядок із залежної таблиці допускає відсутність зв'язку з рядком із головної таблиці (тобто такий зв'язок необов'язковий), то для зовнішнього ключа при видаленні зв'язаного рядка із головної таблиці задається встановлення значення NULL. У цьому стовпець зовнішнього ключа повинен допускати значення NULL.
Аномалія вставки
Для розв'язання аномалії вставки при додаванні в залежну таблицю даних стовпець, який представляє зовнішній ключ, повинен допускати значення NULL. І таким чином, якщо об'єкт, що додається, не має зв'язку з головною таблицею, то в стовпці зовнішнього ключа стоятиме значення NULL.
Аномалії оновлення
Для вирішення проблеми аномалії оновлення застосовується нормалізація, яку було розглянуто раніше.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ