Теоретична частина. Умови цілісності даних. Нормалізація даних

Умови цілісності даних. Нормалізація даних

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

· категорійна цілісність;

· посилальна цілісність.

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

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

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

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

Основні проблеми, що виникають при роботі з ненормалізованими таблицями:

· надлишковість даних;

· аномалія оновлення;

· аномалія видалення:

· аномалія уведення.

Щоб проілюструвати виникаючі проблеми розглянемо стіл замовлень деякого книжкового складу. Якщо уявити собі таблицю замовлень у вигляді { Код замовлення, прізвище, ім’я, по батькові, адреса, телефон, назви книг, автори, кількість замовлених екземплярів, вартість, дата замовлення}, то легко бачити, що при такій її побудові існує маса вад. Наприклад, якщо замовлено кілька книг, то атрибут назви книг не може бути єдиним (атомарним), що спричинить неатомарність полів автори, кількість замовлений екземплярів і вартість. Якщо ж спробувати зробити його атомарним, то інформація про замовника буде повторюватися стільки раз, скільки замовлень він може зробити. Крім того, інформація про книги може з’явитися лише тоді, коли буде зроблене замовлення. Якщо замовник видаляється з таблиці, то може бути загублена інформація про книги, наявні на складі. Точно в такий самий спосіб може бути загублена інформація про клієнта, якщо деякі назви книг будуть вилучені.

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

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

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

Код	Прізвище	Ім’я	По батькові	Дата народження	Діти	Дата народження дітей
	Іванов	Іван	Петрович	12.09.63	Ганна Петро	24.05.93 14.02.96
	Іванова	Ганна	Сергіївна	30.11.69	Ганна Петро	24.05.93 14.02.96
	Петрова	Інна	Петрівна	23.06.74	Іван	24.05.94
	Рощин	Сергій	Олегович	20.12.60	Сергій Павло Ірина	12.12.85 18.03.91 24.09.96

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

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

Код	Прізвища	Ім'я	По батькові	Дата народження
	Іванов	Іван	Петрович	12.09.63
	Іванова	Ганна	Сергіївна	30.11.69
	Петрова	Інна	Петрівна	23.06.74
	Рощин	Сергій	Олегович	20.12.60

Діти

Код	Прізвище	Ім'я	По батькові	Дата народження
	Іванов	Петро	Іванович	12.09.63
	Іванова	Ганна	Іванівна	24.05.93
	Петров	Іван	Сергійович	24.05.94
	Рощин	Сергій	Сергійович	12.12.85
	Рощин	Павло	Сергійович	18.03.91
	Рощина	Ірина	Сергіївна	24.09.96

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

Код співробітника	Код дитини

Рис. 1. Схема даних

Ассеss не підтримує типи зв’язків «багато до багатьох», тому уведення такого відношення знімає цю проблему. У вікні «Схема даних» цей зв’язок виглядає, як показано на рис. 2.

Для підтримки цілісності даних при встановленні зв’язків необхідно забезпечити цілісність даних, яка підтримується Ассеss. Вікно, що встановлює забезпечення цілісності даних, представлене на рис. 2.

Рис. 2. Зміна зв’язків

Друга нормальна форма. Відношення перебуває в другій нормальній формі в тому й тільки в тому випадку, коли це відношення перебуває в першій нормальній формі й кожний неключовий атрибут повністю залежить від первинного ключа. Наприклад, розглянемо репертуар драматичного театру на наступний місяць. У таблиці визначені наступні поля {код актора; ПІБ актора; звання; дата народження; назва п’єси; автор; роль; дата постановки}. Ключем є (код актора)+(назва п’єси)+роль.

Щоб перейти від першої нормальної форми до другої потрібно виконати наступні дії:

· Визначити на які частини можна розбити первинний ключ так, щоб неключові поля залежали тільки від однієї із цих частин;

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

· Видалити з вихідної таблиці переміщені поля

Наприклад, таблицю можна перетворити в такий спосіб: одна таблиця буде визначати особистість актора { код актора; ПІБ актора; звання; дата народження), а друга буде пов’язана з виконуваною роллю, { код ролі; код актора; роль; назва п’єси; автор; дата постановки).

Третя нормальна форма. Розглянемо другу з отриманих вище таблиць. Між полями (назва п’єси)+автор і роль існує функціональна залежність. Справді, ми не зможемо внести в таблицю назву п’єси, якщо не відбувся розподіл ролей. Відношення перебуває в третій нормальній формі в тому і тільки в тому випадку, коли воно перебуває в другій нормальній формі й кожен неключовий атрибут нетранзитивно залежить від первинного ключа. Щоб перейти від другої нормальної форми до третьої необхідно виконати наступні перетворення.

· Визначити всі поля (або групи полів), від яких залежать інші поля.

· Створити нову таблицю для кожного такого поля (або групи полів) і групи залежних від нього полів і перемістити їх у цю таблицю.

· Видалити переміщені поля з вихідної таблиці.

У розглянутому випадку перетворення другої таблиці можна представити так, як це показано на рис. 4.

Рис. 3. Схема даних, що перебувають у третій нормальній формі