Усім привіт! Сьогодні ми з Вами докладно розглянемо другу нормальну форму (2NF) бази даних, зокрема Ви довідаєтеся, які вимоги пред’являються до таблиць, щоб база даних перебувала в другій нормальній формі, і для наочності ми як завжди розглянемо кілька прикладів.
Перед тем як переходити до процесу приведення таблиць бази даних до другої нормальної форми, необхідно щоб ці таблиці вже перебували в першій нормальній формі, докладно процес приведення таблиць бази даних до першої нормальної форми, а також усі вимоги, пропоновані до першої нормальної форми, ми розглядали в попередній статті – перша нормальна форма (1NF).
Після того як таблиці бази даних перебувають у першій нормальній формі, ми можемо починати приводити базу даних до другої нормальної форми й розглядати відповідні вимоги.
Вимоги другої нормальної форми (2NF)
Щоб база даних перебувала в другій нормальній формі (2NF), необхідно щоб її таблиці задовольняли наступним вимогам:
- Таблиця повинна перебувати в першій нормальній формі
- Таблиця повинна мати ключ
- Усі неключові стовпці таблиці повинні залежати від повного ключа (у випадку якщо він складовій)
Ключ – це стовпець або набір стовпців, по яких гарантовано можна відрізнити рядка друг від друга, тобто ключ ідентифікує кожний рядок таблиці. По ключу ми можемо звернутися до конкретного рядка даних у таблиці.
Якщо ключ складової, тобто складається з декількох стовпців, то всі інші неключові стовпці повинні залежати від усього ключа, тобто від усіх стовпців у цьому ключі. Якщо якийсь атрибут (стовпець) залежить тільки від одного стовпця в ключі, виходить, база даних не перебуває в другій нормальній формі.
Іншими словами, у таблиці не повинне бути даних, які можна одержати, знаючи тільки половину ключа, тобто тільки один стовпець зі складеного ключа.
Головне правило другої нормальної форми (2NF) звучить у такий спосіб
Таблиця повинна мати правильний ключ, по якому можна ідентифікувати кожний рядок.
Приклад приведення таблиці до другої нормальної форми
Представимо, що нам потрібно зберігати список співробітників організації, і для цього ми створили наступну таблицю.
| ФІО | Посада | Підрозділ | Опис підрозділу |
|---|---|---|---|
| Іванов І.І. | Програміст | Відділ розробки | Розробка й супровід додатків і сайтів |
| Сергеєв С.С. | Бухгалтер | Бухгалтерія | Ведення бухгалтерського й податкового обліку фінансово-господарчої діяльності |
| John Smith | Продавець | Відділ реалізації | Організація збуту продукції |
Ми бачимо, що вона задовольняє умовам першої нормальної форми, тобто в ній немає дублюючих рядків і всі значення атомарны.
Тепер ми можемо почати процес нормалізації цієї таблиці до другої нормальної форми.
Що для цього нам потрібно зробити? Нам потрібно впровадити первинний ключ.
Попрацювавши небагато із предметною областю, ми з’ясовуємо, що в цій організації кожному співробітникові привласнюється унікальний табельний номер, який ніколи не буде змінений.
Тому очевидно, що для таблиці, яка буде зберігати список співробітників, первинним ключем може виступати табельний номер, знаючи який ми можемо чітко ідентифікувати кожного співробітника, тобто кожний рядок нашої таблиці. Якби такого табельного номера в нас не було або в рамках організації він міг повторюватися (наприклад, співробітник звільнився, і через час його номер привласнили новому співробітникові), то для первинного ключа ми могли б створити штучний ключ із целочисленным типом даних, який автоматично збільшувався б у випадку додавання нових записів у таблицю. Тим самим ми б точно також чітко ідентифікували кожний рядок у таблиці.
Таким чином, щоб привести цю таблицю до другої нормальної форми, ми повинні додати в неї ще один атрибут, тобто стовпець із табельним номером.
| Табельний номер | ФІО | Посада | Підрозділ | Опис підрозділу |
|---|---|---|---|---|
| 1 | Іванов І.І. | Програміст | Відділ розробки | Розробка і супровід сайтів |
| 2 | Сергеєв С.С. | Бухгалтер | Бухгалтерия | Ведення фінансового і податкового обліку, фінансово-господарскої діяльності |
| 3 | John Smith | Продавець | Відділ реалізації | Організація збуту продукції |
У результаті, тому що наш первинний ключ є простим, а не складовим, наша таблиця автоматично переходить у другу нормальну форму.
Іншими словами, якщо первинний ключ простий (не складовій, тобто, що полягає з одного стовпця), друга вимога, яка пред’являється до таблиць для переходу в другу нормальну форму, виконувати не потрібно, тому що воно ставиться тільки до таблиць, у яких первинний ключ складової.
Приклад приведення таблиці до другої нормальної форми (первинний ключ складової)
А тепер давайте розглянемо іншу ситуацію, у якій первинний ключ у нас буде складовим.
Представимо, що наша організація виконує кілька проектів, у яких може бути задіяне трохи учасників, і нам необхідно зберігати інформацію про ці проекти. Зокрема ми прагнемо знати, хто бере участь у кожному із проектів, тривалість цього проекту, ну й можливо якісь інші відомості. При цьому ми розуміємо, що окремо взятий співробітник може брати участь у декількох проектах.
Для зберігання таких данных ми створили наступну таблицю.
| Назва проекту | Участник | Посада | Термін проекту (міс.) |
|---|---|---|---|
| Впровадження додатка | Іванов І.І. | Програміст | 8 |
| Впровадження додатка | Сергеєв С.С. | Бухгалтер | 8 |
| Впровадження додатка | John Smith | Менеджер | 8 |
| Відкриття нового магазину | Сергеєв С.С. | Бухгалтер | 12 |
| Відкриття нового магазину | John Smith | Менеджер | 12 |
Як бачимо, вона в першій нормальній формі, виходить, ми можемо намагатися приводити її до другої нормальної форми.
Як Ви пам’ятаєте, щоб привести таблицю до другої нормальної форми, необхідно визначити для неї первинний ключ.
Подивившись на цю таблицю, ми розуміємо, що чітко ідентифікувати кожний рядок ми можемо тільки за допомогою комбінації стовпців, наприклад, “Назва проекту” + “Учасник”, іншими словами, знаючи “Назву проекту” і “Учасника”, ми можемо чітко визначити конкретний запис у таблиці, тобто кожна комбінація значень цих стовпців є унікальним.
Таким чином, ми визначили первинний ключ і він у нас складовій, тобто, що полягає їх двох стовпців.
| Назва проекту | Участник | Посада | Термін проекту (міс.) |
|---|---|---|---|
| Впровадження додатка | Іванов І.І. | Програміст | 8 |
| Впровадження додатка | Сергеєв С.С. | Бухгалтер | 8 |
| Впровадження додатка | John Smith | Менеджер | 8 |
| Відкриття нового магазину | Сергеєв С.С. | Бухгалтер | 12 |
| Відкриття нового магазину | John Smith | Менеджер | 12 |
Тому що первинний ключ складової, нам необхідно перевірити ще й другу вимогу, яка говорить, що “Усі неключові стовпці таблиці повинні залежати від повного ключа”.
Інакше кажучи, інші стовпці, які не входять у первинний ключ, повинні залежати від усього первинного ключа, тобто від усіх стовпців, а не від якогось одного.
Щоб це перевірити, ми можемо задати собі кілька питань.
ЧИМожемо ми визначити “Посада”, знаючи тільки назву проекту? Немає. Для цього нам необхідно знати й учасника. Виходить, поки всі добре, по цій частині ключа ми не можемо чітко визначити значення неключового стовпця. Ідемо далі й перевіряємо іншу частину ключа.
ЧИМожемо ми визначити “Посада” знаючи тільки учасника? Так, можемо. Значить наш первинний ключ поганий, і вимога другої нормальної форми не виконується.
Що робити в цьому випадку?
У цьому випадку ми будемо виконувати дія, яка виконується, напевно, в 99% випадків протягом усього процесу нормалізації бази даних – це декомпозиція.
Декомпозиція – це процес розбивки одного відношення (таблиці) на трохи
Щоб декомпозировать нашу таблицю й привести базу даних до нормалізованої форми, ми повинні створити наступні таблиці.
| Ідентифікатор проекта | Назва проекта | Термін проекта (мес.) |
|---|---|---|
| 1 | Впровадження додатка | 8 |
| 2 | Відкриття нового магазину | 12 |
| Ідентифікатор учасника | Учасник | Посада |
|---|---|---|
| 1 | Іванов І.І. | Програміст |
| 2 | Сергеєв С.С. | Бухгалтер |
| 3 | John Smith | Менеджер |
| Ідентифікатор проекта | Ідентифікатор учасника |
|---|---|
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
| 2 | 2 |
| 2 | 3 |
Ми створили 3 таблиці:
- Проекти, у неї ми додали штучний первинний ключ
- Учасники, у неї ми також додали штучний первинний ключ
- Зв’язок між проектами й учасниками, вона потрібна для реалізації зв’язку “Багато до багатьом”, тому що між цими таблицями зв’язок саме така
Після того як ми привели таблиці бази даних до другої нормальної форми, ми можемо переходити до приведення таблиць до третьої нормальної форми (3NF). Опис, вимоги й приклад приведення таблиць до третьої нормальної форми ми розглянемо в наступному матеріалі.
П.С. Поцуплено з https://info-comp.ru
Магнітний підсилювач – це як забута технологія колись дуже розвинутої цивілізації. Може виникнути питання – “Якого рожена я це дістав і стряхую столітний пил”. Як . . .
Сьогодні ми з Вами поговоримо про першу нормальну форму бази даних, зокрема Ви довідаєтеся, які вимоги пред’являються до таблиць, щоб база даних перебувала в першій . . .
