(А, С) в тому і тільки в тому випадку, коли існує MVD А -> -> В ¦ С.
Під відображенням без втрат розуміється такий спосіб декомпозиції відношення, при якому початкове відношення повністю і без надмірності відновлюється шляхом природного з'єднання отриманих відносин.
Визначення 11. Четверта нормальна форма
Відношення R знаходиться в четвертій нормальній формі (4NF) в тому і тільки в тому випадку, якщо у разі існування багатозначної залежності А -> -> В всі інші атрибути R функціонально залежать від А.
У нашому прикладі можна зробити декомпозицію відношення ПРОЕКТИ в два відношення ПРОЕКТИ-СПІВРОБІТНИКИ і ПРОЕКТИ-ЗАВДАННЯ:
ПРОЕКТИ-СПІВРОБІТНИКИ (ПРО_НОМЕР, ПРО_СПІВР)
ПРОЕКТИ-ЗАВДАННЯ (ПРО_НОМЕР, ПРО_ЗАВДАН)
Обидва ці відносини знаходяться в 4NF і вільні від відмічених аномалій.
6.1.5. П’ята нормальна форма
У всіх розглянутих до цього моменту нормалізаціях проводилася декомпозиція одного відношення в два. Іноді це зробити не вдається, але можлива декомпозиція в більше число відносин, кожне з яких володіє кращими властивостями.
Розглянемо, наприклад, відношення
СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ (СПІВР_НОМЕР, ВІД_НОМЕР, ПРО_НОМЕР)
Передбачимо, що один і той же співробітник може працювати в декількох відділах і працювати в кожному відділі над декількома проектами. Первинним ключем цього відношення є повна сукупність його атрибутів, відсутня функціональна і багатозначна залежність.
Тому відношення знаходиться в 4NF. Однак в ньому можуть існувати аномалії, які можна усунути шляхом декомпозиції в три відношення.
Визначення 12. Залежність з'єднання
Відношення R (X, Y,. .., Z) задовольняє залежність з'єднання * (X, Y,. .., Z) в тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y,. .., Z.
Визначення 13. П'ята нормальна форма
Відношення R знаходиться в п'ятій нормальній формі (нормальній формі проекції-з'єднання - PJ/NF) в тому і тільки в тому випадку, коли будь-яка залежність з'єднання в R виходить з існування деякого можливого ключа в R.
Введемо наступні імена складових атрибутів:
СВ = {СПІВР_НОМЕР, ВІД_НОМЕР}
СП = {СПІВР_НОМЕР, ПРО_НОМЕР}
ВП = {ВІД_НОМЕР, ПРО_НОМЕР}
Передбачимо, що у відношенні СПІВРОБІТНИКИ-ВІДДІЛИ-ПРОЕКТИ існує залежність з'єднання:
* (СВ, СП, ВП)
На прикладах легко показати, що при вставках і видаленнях кортежів можуть виникнути проблеми. Їх можна усунути шляхом декомпозиції початкового відношення в три нових відношення:
СПІВРОБІТНИКИ-ВІДДІЛИ (СПІВР_НОМЕР, ВІД_НОМЕР)
СПІВРОБІТНИКИ-ПРОЕКТИ (СПІВР_НОМЕР, ПРО_НОМЕР)
ВІДДІЛИ-ПРОЕКТИ (ВІД_НОМЕР, ПРО_НОМЕР)
П'ята нормальна форма - це остання нормальна форма, яку можна отримати шляхом декомпозиції. Її умови досить нетривіальні, і на практиці 5NF не використовується. Помітимо, що залежність з'єднання є узагальненням як багатозначної залежності, так і функціональної залежності.
6.2. Семантичне моделювання даних, ER-діаграми
Широке поширення реляційної СУБД і їх використання в самих різноманітних додатках показує, що реляційна модель даних достатня для моделювання предметних областей. Однак проектування реляційної бази даних в термінах відносин на основі стисло розглянутого нами механізму нормалізації часто являє собою дуже складний і незручний для проектувальника процес.
При цьому виявляється обмеженість реляційної моделі даних в наступних аспектах:
Модель не надає достатніх коштів для представлення значення даних. Семантика реальної предметної області повинна незалежним від моделі способом представлятися в голові проектувальника. Зокрема, це відноситься до згадуваної нами проблеми представлення обмежень цілісності.
Для багатьох додатків важко моделювати предметну область на основі плоских таблиць. У ряді випадків на самої початковій стадії проектування проектувальнику доводиться проводити насильство над собою, щоб описати предметну область у вигляді однієї (можливо, навіть ненормалізованої) таблиці.
Хоч весь процес проектування відбувається на основі обліку залежності, реляційна модель не надає яких-небудь коштів для представлення цієї залежності.
Незважаючи на те, що процес проектування починається з виділення деяких істотних для додатку об'єктів предметної області ("сутностей") і виявлення зв'язків між цими сутностями, реляційна модель даних не пропонує якого-небудь апарату для розділення сутностей і зв'язків.
6.2.1. Семантичні моделі даних
Потреби проектувальників баз даних в більш зручних і могутніх коштах моделювання предметної області спричинили до життя напрям семантичних моделей даних. При тому, що будь-яка розвинена семантична модель даних, як і реляційна модель, включає структурну, маніпуляційну і цілісну частини, головним призначенням семантичних моделей є забезпечення можливості вираження семантики даних.
Раніше, ніж ми коротко розглянемо особливості одній з поширених семантичних моделей, зупинимося на їх можливих застосуваннях.
Найчастіше на практиці семантичне моделювання використовується на першій стадії проектування бази даних. При цьому в термінах семантичної моделі проводиться концептуальна схема бази даних, яка потім вручну перетворюється до реляційної (або який-небудь інший) схеми. Цей процес виконується під управлінням методик, в яких досить чітко обумовлені всі етапи такого перетворення.
Менш часто реалізовується автоматизована компіляція концептуальної схеми в реляційну. При цьому відомі два підходи: на основі явного представлення концептуальної схеми як початкової інформації для компілятора і побудови інтегрованих систем проектування з автоматизованим створенням концептуальної схеми на основі інтерв'ю з експертами предметної області. І в тому, і в іншому випадку в результаті проводиться реляційна схема бази даних в третій нормальній формі (більш точно слід би сказати, що автору невідомі системи, що забезпечують більш високий рівень нормалізації).
Нарешті, третя можливість, яка ще не вийшла (або тільки виходить) за межі дослідницьких і експериментальних проектів, - це робота з базою даних в семантичній моделі, тобто СУБД, заснована на семантичних моделях даних. При цьому знов розглядаються два варіанти: забезпечення призначеного для користувача інтерфейсу на основі семантичної моделі даних з автоматичним відображенням конструкцій в реляційну модель даних (це задача приблизно такого ж рівня складності, як автоматична компіляція концептуальної схеми бази даних в реляційну схему) і пряма реалізація СУБД, заснована на якій-небудь семантичній моделі даних. Найбільш близько до другого підходу знаходиться сучасна об'єктно-орієнтована СУБД, моделі даних яких по багатьох