Нормалізація СУБД: приклад бази даних 1NF, 2NF, 3NF

Що таке нормалізація бази даних?

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

Винахідник реляційна модель Едгар Кодд запропонував теорію нормалізації даних із введенням першої нормальної форми, і він продовжував розширювати теорію за допомогою другої та третьої нормальної форми. Later він приєднався до Реймонда Ф. Бойса для розробки теорії нормальної форми Бойса-Кодда.

Типи нормальних форм у СУБД

Ось список звичайних форм у SQL:

1NF (перша нормальна форма): Гарантує, що таблиця бази даних організована таким чином, що кожен стовпець містить атомарні (неподільні) значення, а кожен запис є унікальним. Це усуває повторювані групи, тим самим структуруючи дані в таблиці та стовпці.
2NF (друга нормальна форма): На основі 1NF нам потрібно видалити зайві дані з таблиці, яка застосовується до кількох рядків. і розмістити їх в окремих таблицях. Він вимагає, щоб усі неключові атрибути були повністю функціональними на первинному ключі.
3NF (Третя нормальна форма): Розширює 2NF, гарантуючи, що всі неключові атрибути не тільки повністю функціональні на первинному ключі, але й не залежать один від одного. Це усуває транзитивну залежність.
BCNF (нормальна форма Бойса-Кодда): Удосконалення 3NF, яке усуває аномалії, які не обробляються 3NF. Він вимагає, щоб кожен визначник був ключем-кандидатом, що забезпечує ще суворіше дотримання правил нормалізації.
4NF (четверта нормальна форма): Вирішує багатозначні залежності. Це гарантує відсутність кількох незалежних багатозначних фактів про сутність у записі.
5NF (п'ята нормальна форма): Також відомий як «звичайна форма проекції-об’єднання» (PJNF), він стосується реконструкції інформації з менших, по-різному впорядкованих фрагментів даних.
6NF (шоста нормальна форма): Теоретичний і мало впроваджений. Він має справу з тимчасовими даними (обробка змін у часі) шляхом подальшої декомпозиції таблиць для усунення всіх нечасових надмірностей.

Теорія нормалізації даних в MySQL сервер продовжує розвиватися. Наприклад, є дискусії навіть на 6^th Нормальна форма. Однак у більшості практичних застосувань нормалізація досягає найкращих результатів у 3^rd Нормальна форма. Еволюція нормалізації в теоріях SQL проілюстрована нижче:

Нормальні форми бази даних

Нормалізація бази даних із прикладами

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

Ось бачите Стовпець "Фільми напрокат" має кілька значень. Тепер давайте перейдемо до першої нормальної форми:

Перша звичайна форма (1NF)

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

Наведена вище таблиця в 1НФ-

1НФ Приклад

Перш ніж продовжити, давайте зрозуміємо кілька речей —

Що таке КЛЮЧ у SQL

A КЛЮЧ у SQL це значення, яке використовується для унікальної ідентифікації записів у таблиці. КЛЮЧ SQL — це один стовпець або комбінація кількох стовпців, які використовуються для унікальної ідентифікації рядків або кортежів у таблиці. Ключ SQL використовується для виявлення повторюваної інформації, а також допомагає встановити зв’язок між кількома таблицями в базі даних.

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

Що таке первинний ключ?

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

Він має такі атрибути

A primary key не може бути NULL
Значення первинного ключа має бути унікальним
Значення первинного ключа слід рідко змінювати
Коли вставляється новий запис, первинному ключу має бути надано значення.

Що таке композитний ключ?

Складений ключ — це первинний ключ, що складається з кількох стовпців, які використовуються для унікальної ідентифікації запису

У нашій базі даних є дві людини з однаковим іменем Роберт Філ, але вони живуть у різних місцях.

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

Давайте перейдемо до другої нормальної форми 2NF

Друга нормальна форма (2NF)

Правило 1 - Будьте в 1NF
Правило 2. Первинний ключ з одним стовпцем, який функціонально не залежить від будь-якої підмножини відношення ключа-кандидата

Зрозуміло, що ми не можемо рухатися вперед, щоб зробити нашу просту базу даних у 2^nd Форма нормалізації, якщо ми не розділимо таблицю вище.

Ми розділили нашу таблицю 1NF на дві таблиці, а саме: Таблиця 1 і Таблиця 2. Таблиця 1 містить інформацію про учасників. Таблиця 2 містить інформацію про взяті напрокат фільми.

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

База даних – зовнішній ключ

У таблиці 2 Membership_ID є зовнішнім ключем

Зовнішній ключ посилається на первинний ключ іншої таблиці! Це допомагає з’єднати ваші таблиці

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

Навіщо потрібен зовнішній ключ?

Припустимо, новачок вставляє запис у таблицю B, наприклад

Ви зможете вставляти у свій зовнішній ключ лише ті значення, які існують в унікальному ключі в батьківській таблиці. Це сприяє цілісності посилання.

Зазначену вище проблему можна подолати, оголосивши ідентифікатор членства з Table2 як зовнішній ключ ідентифікатора членства з Table1

Тепер, якщо хтось спробує вставити значення в поле ідентифікатора членства, якого немає в батьківській таблиці, буде показано помилку!

Що таке транзитивні функціональні залежності?

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

Розглянемо таблицю 1. Зміна неключового стовпця ПІБ може змінити привітання.

Переходимо до 3NF

Третя нормальна форма (3NF)

Правило 1 - Будьте в 2NF
Правило 2 - Не має транзитивних функціональних залежностей

Щоб перемістити нашу таблицю 2NF в 3NF, нам знову потрібно знову розділити нашу таблицю.

3НФ Приклад

Нижче наведено приклад 3NF у базі даних SQL:

Ми знову розділили наші столи та створили нову таблицю, яка зберігає привітання.

Немає транзитивних функціональних залежностей, і тому наша таблиця знаходиться в 3NF

У таблиці 3 ID привітання є первинним ключем, а в таблиці 1 ID привітання є стороннім для первинного ключа в таблиці 3

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

Нормальна форма Бойса-Кодда (BCNF)

Навіть якщо база даних знаходиться в 3^rd Нормальна форма, все одно будуть аномалії, якщо вона має більше ніж одну кандидат Ключ.

Іноді BCNF також називають 3.5 Нормальна форма.

Четверта нормальна форма (4NF)

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

П'ята нормальна форма (5NF)

Стіл знаходиться в 5^th Нормальна форма, лише якщо вона знаходиться в 4NF і її не можна розкласти на будь-яку кількість менших таблиць без втрати даних.

Запропонована шоста нормальна форма (6NF).

6^th Звичайна форма не є стандартизованою, однак вона деякий час обговорюється експертами з баз даних. Сподіваюся, ми матимемо чітке та стандартизоване визначення для 6^th Нормальна форма найближчим часом…

Переваги нормальної форми

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

Недоліки нормалізації

Підвищена складність: Нормалізація може призвести до складних відносин. Величезною кількістю таблиць із зовнішніми ключами може бути важко керувати, що призводить до плутанини.
Знижена гнучкість: Через суворі правила нормалізації гнучкість зберігання даних, які не відповідають цим правилам, може бути меншою.
Збільшені вимоги до сховища: Хоча нормалізація зменшує надмірність, може знадобитися виділити більше місця для зберігання додаткових таблиць та індексів.
Накладні витрати на продуктивність: Об’єднання кількох таблиць може бути дорогим з точки зору продуктивності. Чим більше нормалізовані дані, тим більше потрібно об’єднань, що може сповільнити час отримання даних.
Контекст втрати даних: Нормалізація розбиває дані на окремі таблиці, що може призвести до втрати бізнес-контексту. Перегляд пов’язаних таблиць необхідний для розуміння контексту частини даних.
Потреба в експертних знаннях: Реалізація нормалізованої бази даних вимагає глибокого розуміння даних, зв’язків між даними та правил нормалізації. Це вимагає експертних знань і може зайняти багато часу.

Це все для нормалізації SQL!!!

Висновок

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

Детальніше

Вам може сподобатися: