Нормалізація бд

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

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

Нормальні форми змінюються в порядку від першої до п'ятої. Кожна наступна форма задовольняє вимогам попередньої. Коротко сформулюємо стандарти нормалізації.

Реляційна таблиця (РТ) знаходиться в першій НФ, якщо значення в ній є атомарними для кожного атрибута.

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

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

Четверта НФ забороняє незалежні відносини типу один - до багатьох між ключовими і неключових стовпцями.

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

Відобразимо концептуальну модель ПО на логічну схему, орієнтуючись на СУБД MS Access, отримаємо фрагмент логічної моделі БД "Бухгалтерський облік на підприємстві" (мал. 3).

Рис. 3. Логічна модель БД

Усі таблиці мають четверту НФ. У таблиці ЖГО простий первинний ключ - поле Номер операції. Простий ключ складається з одного поля, складовою - з декількох полів. У таблиці Валюти первинний ключ складової - з двох полів Код валюти і Дата. У таблиці План рахунків первинний ключ - поле Номер рахунку. У таблиці Контрагенти первинний ключ - поле Код контрагента. У таблиці ЖГО поля Код валюти, Дата, Дебет, Код контрагента - зовнішні ключі, тип зв'язків ∞ ↔ 1.

Наступний етап - фізичне проектування: логічна модель даних відображається на фізичну схему, в результаті виходить фізична модель, яка визначає розміщення даних, методи доступу й техніку індексування. Фізична модель відповідає внутрішньому рівню архітектури будь-якої АІС. У сучасних СУБД (у тому числі MS Access) процес фізичного проектування БД здійснюється автоматизовано засобами самої СУБД.

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

1) аналіз ПО, виявлення інформаційних потреб користувачів (запити, звіти і т.д.);

2) вибір інформаційних об'єктів, їх властивостей, визначення зв'язків між ними;

3) подання концептуальної моделі ПО у вигляді EAR-діаграм;

4) вибір конкретної СУБД для реалізації БД, наприклад, MS Access;

5) відображення концептуальної моделі на логічну: кожен прямокутник EAR-діаграми - реляційна таблиця;

6) визначення ключів кожної таблиці (первинних і зовнішніх), уточнення зв'язків між таблицями;

7) створену "начорно" структуру БД (сукупність взаємопов'язаних таблиць) слід проаналізувати на предмет відповідності правилам нормалізації, при необхідності внести зміни (в СУБД MS Access цієї мети служить інструмент Аналізатор таблиць);

8) тепер Ви готові до безпосереднього створення БД в конкретній СУБД, тобто до етапу фізичного проектування;

9) потім слід оцінити свою розробку з точки зору того, чи задовольняють Вас і Ваших користувачів отримані результати, якщо ні - повернутися до пункту 1.