Нормалізація бази даних
Нормалізація бази даних
Нормалізація таблиць бази даних - перший крок на шляху проектування структури реляційної бази даних. Строго кажучи, звичайно, не найперший - спочатку треба вирішити, що ж ми взагалі будемо зберігати в базі, тобто визначитися зі структурою полів, їх типами і розмірністю, сенсом зберігається в них інформації. Але це, так би мовити, мається на увазі за замовчуванням.
Теорія нормалізації реляційних баз даних була розроблена в кінці 70-х років 20 століття. Відповідно до неї, виділяються шість нормальних форм, п'ять з яких так і називаються: перша, друга, третя, четверта, п'ята нормальна форма, а також нормальна форма Бойса-Кодда, що лежить між третьою і четвертою.
База даних вважається нормалізованої, якщо її таблиці (по крайней мере, більшість таблиць) представлені як мінімум в третій нормальній формі. Часто багато таблиці нормалізуються до четвертої нормальної форми, іноді, навпаки, проводиться денормализация. Використання таблиць в п'ятій нормальній формі (вірніше сказати, свідомого приведення їх до п'ятої нормальної форми) в реальних базах даних я особисто не зустрічав.
Головна мета нормалізації бази даних - усунення надмірності та дублювання інформації. В ідеалі при нормалізації треба домогтися, щоб будь-яке значення зберігалося в базі в одному екземплярі, причому значення це не має бути отримано розрахунковим шляхом з інших даних, що зберігаються в базі.
Перша нормальна форма
Перша нормальна форма:
- забороняє повторювані стовпці (що містять однакову за змістом інформацію).
- забороняє множинні стовпці (що містять значення типу списку і т.п.).
- вимагає визначити первинний ключ для таблиці, тобто той стовпець або комбінацію стовпців, які однозначно визначають кожен рядок.
Друга нормальна форма
Друга нормальна форма вимагає, щоб неключових стовпці таблиць залежали від первинного ключа в цілому, але не від його частини. Маленька ремарочка: якщо таблиця знаходиться в першій нормальній формі і первинний ключ у неї складається з одного стовпця, то вона автоматично знаходиться і в другій нормальній формі.
Третя нормальна форма
Щоб таблиця перебувала в третій нормальній формі, необхідно, щоб неключових стовпці в ній не залежали від інших неключових стовпців, а залежали лише від первинного ключа. Найпоширеніша ситуація в даному контексті - це розрахункові стовпці, значення яких можна отримати шляхом будь-яких маніпуляцій з іншими стовпцями таблиці. Для приведення таблиці в третю нормальну форму такі стовпці з таблиць треба видалити.
Нормальна форма Бойса-Кодда
Нормальна форма Бойса-Кодда вимагає, щоб в таблиці був тільки один потенційний первинний ключ. Найчастіше у таблиць, що знаходяться в третій нормальній формі, так і буває, але не завжди. Якщо виявився другий стовпець (комбінація стовпців), що дозволяє однозначно ідентифікувати рядок, то для приведення до нормального формі Бойса-Кодда такі дані треба винести в окрему таблицю.
Четверта нормальна форма
Для приведення таблиці, що знаходиться в нормальній формі Бойса-Кодда, до четвертої нормальної форми необхідно усунути наявні в ній багатозначні залежності. Тобто забезпечити, щоб вставка / видалення будь-якого рядка таблиці не вимагала б вставки / видалення / модифікації інших рядків цієї ж таблиці.
П'ята нормальна форма
Таблицю, що знаходиться в четвертій нормальній формі і, здавалося б, уже нормалізовану до межі, в деяких випадках ще можна буває розбити на три або більше (але не на дві # 33;) таблиць, з'єднавши які, ми отримаємо вихідну таблицю. Утворені в результаті такої, як правило, досить штучної, декомпозиції таблиці і називають знаходяться в п'ятій нормальна формі. Формальне визначення п'ятої нормальної форми таке: це форма, в якій усунуті залежності з'єднання. У більшості випадків практичної користі від нормалізації таблиць до п'ятої нормальної форми не спостерігається.
Така ось теорія. Розроблено спеціальні формальні математичні методи нормалізації таблиць реляційних баз даних. На практиці ж тлумачний проектувальник баз даних, детально ознайомившись з предметною областю, як правило, досить швидко накидає структуру, в якій більшість таблиць знаходяться в четвертій нормальній формі.
Короткі підсумки. Навіщо потрібна нормалізація.
Головне, чого ми доб'ємося, провівши нормалізацію бази даних - це усунення (або, принаймні, серйозне скорочення) надмірності, дублювання даних. Як наслідок, значно скорочується вірогідність появи суперечливих даних, полегшується адміністрування бази і оновлення інформації в ній, скорочується обсяг дискового простору.
Але не все так біло і пухнасто. Найчастіше, щоб отримати інформацію з нормалізованої бази даних, доводиться конструювати дуже складні запити, які до того ж, буває, працюють досить повільно - через, головним чином, великої кількості з'єднань таблиць. Тому, щоб збільшити швидкість вибірки даних і спростити програмування запитів, нерідко доводиться йти на вибіркову денормализация бази.
Я і є демон # 33; У моєму світі демоном був ти, але в поточний момент я в твоєму світі, з цього демон я.
Нормальна форма - вимога до структури таблиць в теорії реляційних баз даних для усунення з бази надлишкових функціональних залежностей між атрибутами (полями таблиць).
Нормалізація може застосовуватися до таблиці, спочатку відповідає таким вимогам:
- Таблиця містить нуль або більше записів.
- Всі записи таблиці мають один і той же безліч полів, причому однойменні поля відносяться до однакових типів даних.
- Таблиця не може містити двох повністю ідентичних записів.
Перша нормальна форма (1NF)
Таблиця знаходиться в першій нормальній формі, якщо кожен її атрибут атомарен і всі рядки різні. Під виразом «атрибут атомарен» розуміється, що атрибут може містити тільки одне значення. Таким чином, не відповідають 1NF таблиці, в полях яких можуть зберігатися списки значень. Для приведення таблиці до 1NF зазвичай потрібно розбити таблицю на кілька окремих таблиць.
Приклад приведення таблиці до першої нормальної формі
Вихідна, ненормалізованих, таблиця:
Таблиця, наведена до 1NF:
Питання про атомарности атрибутів вирішується на основі семантики даних, тобто їх смислового значення. Атрибут атомарен, якщо його значення втрачає сенс при будь-якому розбитті на частини або переупорядочивания. І навпаки, якщо який-небудь спосіб розбиття на частини не позбавляє атрибут сенсу, то атрибут неатомарен. Одне і те ж значення може бути атомарним або неатомарним в залежності від змісту цього значення. Наприклад, значення «4286» є
- атомарним, якщо його зміст - «пін-код кредитної карти» (при розбитті на частини або переупорядочивания сенс втрачається)
- неатомарним, якщо його зміст - «парні цифри» (при розбитті на частини або переупорядочивания сенс не втрачається)
Хорошим способом прийняття рішення про необхідність розбиття атрибута на частини є питання: «чи будуть частини атрибута використовуватися окремо?». Якщо так, то атрибут слід розділити (але так, щоб збереглися осмислені частини атрибута). Далі необхідно знову задатися тим же питанням для нової структури і так до тих пір, поки не залишиться атрибутів, що допускають розбиття.
Друга нормальна форма (2NF)
Таблиця знаходиться в другій нормальній формі, якщо вона знаходиться в першій нормальній формі, і при цьому будь-який її атрибут, який не входить до складу первинного ключа, функціонально повно залежить від первинного ключа. Функціонально повна залежність означає, що атрибут функціонально залежить від усього первинного ключа, але при цьому не перебуває у функціональній залежності від будь-якої його частини.
Приклад приведення таблиці до другої нормальної форми
Нехай Начальник і Посада разом утворюють первинний ключ в такій таблиці:
Зарплату співробітнику кожен начальник встановлює сам, але її межі залежать від посади. Наявність же комп'ютера у співробітника залежить тільки від посади, тобто залежність від первинного ключа не повна.
В результаті приведення до 2NF отримаємо дві таблиці:
Тут первинний ключ, як і в початковій таблиці, складовою, але єдиний не входить в нього атрибут Зарплата залежить тепер від усього ключа, тобто повно.
Третя нормальна форма (3NF)
Таблиця знаходиться в третій нормальній формі, якщо вона знаходиться в другій нормальній формі, і при цьому будь-який її неключових атрибут функціонально залежить тільки від первинного ключа.
При вирішенні практичних завдань в більшості випадків третя нормальна форма є достатньою. Процес проектування реляційної бази даних, як правило, закінчується приведенням до 3NF.
Приклад приведення таблиці до третьої нормальної формі
В результаті приведення до 3NF отримаємо дві таблиці:
Між третьою і четвертою формами існує ще один різновид - нормальна форма Бойса-Кодда (НФБК). Відповідно до її вимог при наявності декількох можливих ключів для кожного з них створюється окрема сутність. Щоб сутність відповідала НФБК, вона повинна перебувати в третій нормальній формі. Будь-яка сутність з єдиним можливим ключем, що відповідає вимогам третьої нормальної форми, автоматично знаходиться в НФБК.
Четверта нормальна форма (4NF)
Таблиця знаходиться в 4NF, якщо вона знаходиться в BCNF і не містить нетривіальних багатозначних залежностей. Багатозначна залежність не є функціональною, вона існує в тому випадку, коли з факту, що в таблиці міститься деяка рядок X, слід, що в таблиці обов'язково існує деяка певна рядок Y.
Тобто, таблиця знаходиться в 4NF, якщо всі її багатозначні залежності є функціональними.
П'ята нормальна форма (5NF)
Таблиця знаходиться в 5NF, якщо вона знаходиться в 4NF і будь-яка багатозначна залежність з'єднання в ній є тривіальною.
П'ята нормальна форма в більшій мірі є теоретичним дослідженням, і практично не застосовується при реальному проектуванні баз даних. Це пов'язано зі складністю визначення самого наявності залежностей «проекції - з'єднання», оскільки твердження про наявність такої залежності має бути зроблено для всіх можливих станів БД.
Я і є демон # 33; У моєму світі демоном був ти, але в поточний момент я в твоєму світі, з цього демон я.