Принципи нормалізації
Лекція 4. Нормалізація таблиць реляційних баз даних
Правила тризначної логіки
Таблиця істинності оператора and
| and | true | false | Null |
| true | true | false | Null |
| false | false | false | False |
| null | null | false | Null |
Таблиця істинності оператора or
| or | true | false | Null |
| true | true | true | True |
| false | true | false | Null |
| null | true | null | Null |
Таблиця істинності оператора немає.
| not | true | false | Null |
| false | true | Null |
1. Принципи нормалізації.
2. Нормальні форми
Після того, як структура предметної області розроблена, вона піддається аналізу та реструктуризації. У ході реструктуризації використовується низка принципів, які дозволяють привести таблиці баз даних до нормального вигляду (форми). У процесі нормалізації вихідні таблиці поділяються на ряд самостійних таблиць, що складаються з меншої кількості стовпців.
1) Принцип одноразового введення та надмірного зберігання даних.
Відповідно до теорії нормалізації кожен елемент даних повинен вводитися до бази лише один раз і зберігатися в єдиному екземплярі в одній таблиці. Порушення цього принципу призводить до нераціонального зберігання дискової пам'яті та суперечливості даних.
Суперечності виникають тоді, коли властивості одного й того самого об'єкта в різних таблицях мають різні значення.
Водночас можлива ситуація, коли один ітой самий елемент зберігається у основі кількох примірниках. Необхідність зв'язати батьківську та дочірню таблиці вимагає включити до складу полів дочірньої таблиці ключ із батьківської таблиці. Внаслідок цього значення ключа з батьківської таблиці може зустрітися також у відповідному полі дочірньої таблиці. У разі, якщо в організації використовується розподілена база даних, що складається з декількох самостійних підбаз, то відповідно до принципу нормалізації одноразового введення та безнадлишнього зберігання дані вводяться тільки в одній з підбаз і передаються по мережі або якимось іншим способом на всі інші підбази.
2) Принцип атомарності (неподільності) всіх полів бази даних.
Кожне поле повинно включати лише один реквізит, який не поділяється на поля самостійних реквізитів.
Внаслідок цього кожен із отриманих реквізитів повинен відповідати самостійному полю.
Досить часто розробники свідомо порушують принцип атомарності для досягнення більшої продуктивності системи, але порушення цього принципу може призвести до певних проблем при подальшому розвитку та нарощуванні бази даних.
Свідоме порушення принципу атомарності допускається у разі, коли це порушення не відбивається на функціональності бази даних.
3) Принцип відсутності повторюваних груп полів.
Кожна група полів може бути в таблиці лише один раз. За наявності груп полів, що повторюються, структура таблиці повинна бути змінена. В результаті зміни структури замість однієї вихідної буде отримано кілька вужчих таблиць.
4) Принцип залежності всіх неключових полів від первинного ключа.
Для дотримання цього принципу, як і попереднього, важливо правильно вибрати ключові поля. Після того якце буде зроблено, необхідно перевірити інші поля щодо залежності між собою.
5) Принцип незалежності неклячових полів між собою.
Неключові поля що неспроможні залежати друг від друга, якщо у вихідної таблиці зв'язок між ключовими полями все-таки виявлено, ця таблиця має бути розбита кілька окремих таблиць, у яких аналізований принцип було б дотримано.
6) Принцип відсутності у таблицях обчислюваних полів.
Зберігання даних на машинному носії пов'язане з використанням дискової пам'яті, тому в базах даних не повинна зберігатися інформація, яка може бути розрахована і на ті реквізити, значення яких можуть бути визначені на основі інших реквізитів. При необхідності необхідні обчислення виконуються досить швидко, у зв'язку з чим у користувачів створюється враження присутності цих даних у таблицях бази.
Присутність у таблиці реквізитів, які можуть бути розраховані на основі інших реквізитів, може потенційно стати причиною суперечливості даних.
Наприклад, у таблиці є поля: кількість, ціна, сума. Необхідність зберігати всі три реквізити відсутня, оскільки сума може бути розрахована як добуток кількості та ціни, або ціна може бути визначена як приватна сума та кількість.
Практичне застосування принципів нормалізації.
Індивідуальний підприємець отримує три види продукції від постачальників із різних міст заповнює журнал постачання наступного виду:
| №№ пп | Найменування постачальника | Місто | Постачання продукції виду | Сума постачання | |
| I | II | III | |||
| у | ціна | до | ц | до | ц |
Порушено принцип відсутності повторюванихгруп полів. Для поля “Постачання продукції виду” у таблиці передбачені поля “Кількість” та “Ціна”, які повторюються тричі, чого не повинно бути. Для дотримання принципу вихідну таблицю необхідно розбити на дві: "Види продукції" і "Постачання":
| Види продукції | ||
| Код виду продукції | … | … |
У таблиці "Постачання" поля "Кількість" і "Ціна" будуть в однині.
| Постачання | |||
| … | Кількості | Ціна | … |
Присутність обчислюваних полів у таблиці також є порушенням принципів нормалізації. Сума поставки може бути знайдена як добуток кількості та ціни продукції, тому це поле з таблиці має бути виключено.
У таблиці не дотримано принципу одноразового введення та зберігання інформації і одночасно не дотримується принципу незалежності неключових полів між собою. Недотримання цих принципів викликано такими особливостями структури таблиці: кожної поставки вказуються найменування постачальника, місто і банківські реквізити; атрибути "Місто" та "Банківські реквізити" функціонально залежать від найменування постачальника. Щоб принципи нормалізації були дотримані, вихідну таблицю потрібно розбити на дві: “Постачальники” і “Поставки” (рис. 4.1.1).
| Постачальники |
| Види продукції |
| Постачання |
Мал. 4.1.1 Схема структури предметної галузі Постачання
У таблиці «Журнал постачання» дотримано лише принципу залежності всіх неключових полів від первинного ключа.
У процесі нормалізації, коли вихідна таблиця розбивається кілька дрібніших, необхідно забезпечити зв'язок між таблицями. Для цього у дочірнютаблицю додається ключове полі з батьківської, причому цей випадок єдиний, коли дані зберігаються у кількох примірниках, тобто. в одному примірнику елемент даних зберігається у родовій таблиці та в одному примірнику – у дочірній. Виправдовується це необхідністю забезпечення зв'язок між таблицями.