Нормальні форми відносин

Етапи розробки бази даних

Метою розробки будь-якої бази даних є зберігання і використовування інформації про яку-небудь предметну область. Для реалізації цієї мети є наступні інструменти:

Реляційна модель даних - зручний спосіб представлення даних предметної області.

Мова SQL - універсальний спосіб маніпулювання такими даними.

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

У даному розділі розглядаються способи "хорошого" або "правильного" проектування реляційних відносин. Спочатку ми обговоримо, що значить "хороші" або "правильні" моделі даних. Потім будуть введені поняття першою, другою і третьою нормальних форм відносин (1НФ, 2НФ, 3НФ) і показано, що "хорошими" є відносини в третій нормальній формі.

При розробці бази даних звичайно виділяється декілька рівнів моделювання, за допомогою яких відбувається перехід від предметної області до конкретної реалізації бази даних засобами конкретної СУБД. Можна виділити наступні рівні:

Сама предметна область

Модель предметної області

Логічна модель даних

Фізична модель даних

Власне база даних і додатки

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

Модель предметної області. Модель предметної області - це наші знання про предметну область. Знання можуть бути як у вигляді неформальних знань в мозку експерта, так і виражені формально за допомогою яких-небудь засобів. Як такі засоби можуть виступати текстові описи предметної області, набори посадових інструкцій, правила ведення справ в компанії і т.п. Досвід показує, що текстовий спосіб представлення моделі предметної області украй неефективний. Набагато більш інформативними і корисними при розробці баз даних є описи предметної області, виконані за допомогою спеціалізованих графічних нотацій. Є велика кількість методик опису предметної області. З найвідоміших можна назвати методику структурного аналізу SADT і засновану на ньому IDEF0, діаграми потоків даних Гейна-Сарсона, методику об'єктно-орієнтованого аналізу UML, і ін. Модель предметної області описує швидше процеси, що відбуваються в предметній області і дані, що використовуються цими процесами. Від того, наскільки правильно змодельована предметна область, залежить успіх подальшої розробки додатків.

Логічна модель даних. На наступному, більш низькому рівні знаходиться логічна модель даних предметної області. Логічна модель описує поняття предметної області, їх взаємозв'язок, а також обмеження на дані, що накладаються предметною областю. Приклади понять - "співробітник", "відділ", "проект", "зарплата". Приклади взаємозв'язків між поняттями - "співробітник числиться рівно в одному відділі", "співробітник може виконувати декілька проектів", "над одним проектом може працювати декілька співробітників". Приклади обмежень - "вік співробітника не менше 16 і не більше 60 років".

Логічна модель даних є початковим прототипом майбутньої бази даних. Логічна модель будується в термінах інформаційних одиниць, але без прив'язки до конкретної СУБД. Більш того, логічна модель даних необов'язково повинна бути виражена засобами саме реляційної моделі даних. Основним засобом розробки логічної моделі даних зараз є різні варіанти ER-діаграм (Entity-Relationship, діаграми сутність-зв'язок). Одну і ту ж ER-модель можна перетворити як в реляційну модель даних, так і в модель даних для ієрархічних і мережних СУБД, або в постреляційну модель даних. Проте, оскільки ми розглядаємо саме реляційні СУБД, то можна вважати, що логічна модель даних для нас формулюється в термінах реляційної моделі даних.

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

При розробці логічної моделі даних виникають питання: чи добре спроектовані відносини? Чи правильно вони відображають модель предметної області, а отже і саму предметну область?

Фізична модель даних. На ще більш низькому рівні знаходиться фізична модель даних. Фізична модель даних описує дані засобами конкретної СУБД. Ми вважатимемо, що фізична модель даних реалізована засобами саме реляційної СУБД, хоча, як вже сказано вище, це необов'язково. Відносини, розроблені на стадії формування логічної моделі даних, перетворяться в таблиці, атрибути стають стовпцями таблиць, для ключових атрибутів створюються унікальні індекси, домени перетворюються в типи даних, прийняті в конкретній СУБД.

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