Нормалізація і нормальні форми

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

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

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

Таблиця 2.18

Подання відносини з функціональними залежностями

Атрибут 1

Атрибут 2

Атрибут 3

А1

Б1

В 1

А1

Б2

В 1

Л2

Б1

В 2

А2

БЗ

ВЗ



У представленому прикладі (див. Табл. 2.18) між сукупністю атрибутів "Атрибут 1" і "Атрибут 2" щодо атрибута "Атрибут 3" існує функціональна залежність. Якщо розглянути сукупність значень перших двох атрибутів, то кожна сукупність значень однозначно пов'язана з єдиним значенням третього атрибута. Однак тут не видно історичного розвитку відносини і у відриві від предметної області складно говорити про однозначно виявленої функціональної залежності, оскільки невідомі умови, що накладаються на сукупність атрибутів "Атрибут 1" і "Атрибут 2", а також їх зв'язок з атрибутом "Атрибут 3". Щоб виявити на технічному рівні функціональну залежність, необхідно представити відношення з усіма можливими значеннями по кожному атрибуту, що, в силу мінливості сукупності даних в предметної області, практично неможливо, крім випадків, коли розглядаються зв'язку між незмінними даними, що подаються класифікаторами. Тому, щоб однозначно виявити функціональну залежність між атрибутами, необхідно проводити логічний аналіз предметної області та визначати обмеження, що накладаються на значення, але кожному атрибуту або сукупності атрибутів в зв'язку з іншою сукупністю атрибутів. Тільки такий логічний аналіз дасть можливість розробнику обгрунтовано прийняти рішення про знаходження функціональної залежності і необхідності се вивчення і проведення операцій нормалізації.

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

{ "Атрибут 1", "Атрибут 2") - "" Атрибут 3 ". (2.2)

Ця запис розділяє формулу на дві складові: детермінант і залежну частину.

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

Безліч атрибутів детермінанта може складатися з одного або декількох атрибутів, то ж відноситься і до безлічі атрибутів залежної частини.

В кожному відношенні виділяють два види функціональних залежностей: тривіальну і нетривіальну. Різниця в цих видах полягає в тому, що тривіальна залежність не може не виконуватися.

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

{ "Атрибут 1", "Атрибут 3") -> "Атрибут 3". (2.3)

Якщо безліч атрибутів залежної частини всім своїм складом входить в безліч атрибутів детермінанта, то тоді формується тривіальна залежність і залежна частина, будучи, як правило, в сукупності

своїх значень унікальною, в нормалізованому відношенні представляється первинним ключем.

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

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

Наприклад, використовуючи представлений приклад (див. Табл. 2.18), можна помітити, що між атрибутами "Атрибут 1" і "Атрибут 3" є функціональна залежність, яка може бути розглянута у відриві від атрибута "Атрибут 2". "Атрибут 2" є тут надлишковим, характеризуючи дані атрибута "Атрибут 1", він не пов'язаний з атрибутом "Атрибут 3". Звичайно, в цьому випадку сукупність атрибутів "Атрибут 1" і "Атрибут 3" потрібно розглядати незалежно від атрибута "Атрибут 2", прибираючи виникає надмірність даних. Цей процес реалізують за допомогою нормалізації (рис. 2.70), переводячи відносини в відповідну нормальну форму.

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

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

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

image110

Мал. 2.70. рівні нормалізації

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

Таблиця 2.19

Приклад вихідного відносини

співробітник

Посада

Сфера відповідальності

Іванов І. І.

Менеджер

електроніка

Комис П. В.

Менеджер

Побутова техніка

Уявімо, що в електронному магазині менеджери відповідають за роботу з клієнтами відповідно до типу продукції. В результаті декомпозиції може бути отримана модель відносин без втрати даних (табл. 2.20).


Співробітник Посада Іванов І. І. Менеджер комис П. В. Менеджер
Результат декомпозиції без втрат

співробітник

Сфера відповідальності

Іванов І.І.

електроніка

Комис П.В.

Побутова техніка


Оскільки в розглянутому відношенні атрибут "Співробітник" є унікальним і його можна розглядати як сполучна ланка між одержуваними відносинами, то зворотний процес об'єднання одержані відносин призведе до точного відтворення вихідного відносини в тому вигляді, як воно було представлено спочатку. Тобто в процесі декомпозиції (проекції) не відбулася втрата даних. У варіанті, коли сполучною ланкою стає атрибут "Посада", неможливо дотримання унікальності взаємозв'язків з іншими атрибутами, і в результаті декомпозиції (проекції) відбувається втрата даних (табл. 2.21).

Таблиця 2.21

Співробітник Посада Іванов І. І. Менеджер комис П. В. Менеджер

Посада Сфера відповідальності Менеджер Електроніка Менеджер Побутова техніка

Результат декомпозиції з втратою даних



Об'єднавши отримані відносини, враховуючи сполучною атрибутом "Посада", отримуємо відношення з великою кількістю примірників, ніж це повинно бути але вихідного відношенню (табл. 2.22).

Таблиця 2.22

Результат об'єднання відносин, декомпозіровано з втратою даних

співробітник

Посада

Сфера відповідальності

Іванов І. І.

Менеджер

електроніка

Комис П. В.

Менеджер

електроніка

Іванов І. І.

Менеджер

Побутова техніка

Комис П. В.

Менеджер

Побутова техніка



Отримані додаткові екземпляри є фіктивними і не відображають реалій предметної області і вихідного відносини. В результаті було виявлено втрата інформації в частині коректного закріплення співробітника за певною продукцією.

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


 
< Попер   ЗМІСТ   Наст >