ЯКА ТРЕТЯ НОРМАЛЬНА ФОРМА? (БАЗИ ДАНИХ) - ТЕХНОЛОГІЯ - 2025

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

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

Джерело: pixabay.com

Для досягнення цієї мети можуть бути використані деякі методи проектування баз даних, серед яких - нормалізація.

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

Він починається з вивчення функціонального зв’язку або залежності між атрибутами. Вони описують деяку властивість даних або взаємозв'язок між ними.

Нормальні форми

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

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

Перша нормальна форма (1FN)

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

За визначенням реляційна база даних завжди буде нормалізована до першої нормальної форми, оскільки значення атрибутів завжди атомні. Усі відносини в базі даних є в 1FN.

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

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

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

Некритичний атрибут - це будь-який атрибут, який не є частиною первинного ключа для відносин.

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

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

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

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

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

Тому, щоб відносини в базі даних були в третій звичайній формі, вона повинна відповідати:

- Усі вимоги 2FN.

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

Приклади третьої нормальної форми

Приклад 1

Нехай таблиця буде STUDENT, основним ключем якої є ідентифікація студента (STUDENT_ID) і складається з таких атрибутів: STUDENT_NAME, STREET, CITY та POST_CODE, які відповідають умовам 2FN.

У цьому випадку STREET та CITY не мають прямого зв’язку з первинним ключем STUDENT_ID, оскільки вони безпосередньо не пов'язані зі студентом, але повністю залежать від поштового індексу.

Оскільки студент розташований на сайті, визначеному CODE_POSTAL, STREET та CITY пов'язані саме з цим атрибутом. Через цю другу ступінь залежності зберігати ці атрибути в таблиці СТУДЕНТІ не потрібно.

Створіть нову таблицю

Припустимо, що в одному і тому ж поштовому індексі розташовано кілька студентів, при цьому таблиця СТУДЕНТ має величезну кількість записів, і потрібно змінити назву вулиці чи міста, тоді цю вулицю чи місто потрібно шукати та оновлювати у всій таблиці СТУДЕНТ.

Наприклад, якщо вам потрібно змінити вулицю "Ель Лімон" на "Ель Лімон II", вам доведеться шукати "Ель Лімон" у всій таблиці СТУДЕНТІВ, а потім оновити її на "Ель Лімон II".

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

Натомість ці дані можна зберігати в окремій таблиці (POSTCARD), яка пов'язана з таблицею STUDENT, використовуючи атрибут POST_CODE.

У таблиці POST буде порівняно менше записів, і цю таблицю POST потрібно буде оновити лише один раз. Це буде автоматично відображено в таблиці СТУДЕНТ, спрощуючи базу даних та запити. Тож таблиці будуть у 3FN:

Приклад 2

Нехай наступна таблиця використовується з полем Project_Num в якості основного ключа та з повторними значеннями в атрибутах, які не є ключами.

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

Атрибут Project_Manager не може бути можливим ключем у таблиці Проекти, оскільки той самий менеджер управляє більш ніж одним проектом. Рішення для цього - видалити атрибут із повторними даними (Телефон), створивши окрему таблицю.

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

Для дотримання третьої нормальної форми створюється нова таблиця (Менеджери) для вирішення проблеми. Обидві таблиці пов’язані через поле Project_Manager:

Список літератури

1. Терадата (2019). Перша, друга та третя нормальні форми. Взято з: docs.teradata.com.
2. Кубок підручника (2019). Третя нормальна форма (3NF). Взято з: tutorialcup.com.
3. База даних Dev (2015). Третя нормальна форма (3NF) - нормалізація вашої бази даних. Взято з: databasedev.co.uk.
4. Реляційний дизайн БД (2019). Вступ до третьої нормальної форми. Взято з: relationaldbdesign.com.
5. Манекени (2019). Перша, друга та третя нормальні форми SQL. Взято з: dummies.com.