Нормалізація баз даних з мінімальною надмірністю - IONOS

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

надмірністю

  1. Що таке нормалізація?
  2. Нормалізація: Як нормалізувати базу даних
    1. 1. Звичайна форма (1NF)
    2. 2. Звичайна форма (2NF)
    3. 3. Звичайна форма (3NF)
  3. Більш нормальні форми
    1. Нормальна форма Бойса-Кодда (3,5NF)
    2. 4. Нормальна форма
    3. 5. Нормальна форма
  4. Плюси і мінуси нормалізації

Що таке нормалізація?

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

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

У наступній таблиці наведено збережені дані рахунків-фактур для фіктивного монтера компанії. Макс Мустерманн замовив для своєї компанії 10 моніторів, 12 накладок для миші та 1 офісне крісло. Замовлення від Erika Musterfrau включає 2 ноутбуки та 2 гарнітури.

У базі даних Інтернет-магазину дані рахунків-фактур присвоюються атрибутам номер рахунку-фактури (R.No.), дата, клієнт, номер клієнта (K.No.), адреса, номер позиції рахунку-фактури (P.No.), артикул, номер статті (Art.- No), номер (номер) та присвоєна ціна. Кожен рядок таблиці означає один запис даних. Такий запис називається Кортеж призначений.

Розділ бази даних, показаний вище, діє як a Приклад aпоганий дизайн бази даних. На перший погляд помітно, що таблиця має численні надмірності. Крім того, діапазони значень у стовпцях Замовник та Адреса містять багатозначні дані. Можна говорити про ненормовану базу даних.

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

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

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

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

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

Нормалізація: Як нормалізувати базу даних

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

1. Звичайна форма (1NF)

Таблиця в реляційній базі даних відповідає 1-й нормальній формі (1NF), якщо виконуються наступні вимоги:

  • Усі дані є атомними.
  • Усі стовпці таблиці містять подібні значення.

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

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

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

Якщо перелічений розділ бази даних повинен бути нормалізований відповідно до 1-ї звичайної форми, потрібна наступна процедура:

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

Для того, щоб записати дані в прикладі таблиці в атомну форму, атрибути замовника та адреси повинні бути розбиті на більш конкретні атрибути: ім'я та прізвище чи вулиця, номер будинку (H.-Nr.), поштовий індекс (поштовий індекс) та місто.

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

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

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

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

2. Звичайна форма (2NF)

Таблиця, яка повинна відповідати 2-й нормальній формі, повинна відповідати всім вимогам 1-ї нормальної форми, а також відповідати наступним умовам:

  • Кожен неключовий атрибут повинен повністю функціонально залежати від первинного ключа.

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

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

У нашому прикладі можливий супер ключ виходить із атрибутів номер рахунку-фактури (R.-Nr.), номер клієнта (K.-Nr.) та номер елемента рахунку-фактури (P.-Nr.). Ми виділили супер-колір кольором у таблиці нижче.

Ключ, що складається з номера рахунку-фактури, номера клієнта та номера елемента рахунку-фактури зі значеннями, дозволяє, наприклад, однозначно назвати запис даних, який представляє покупку ноутбука у Erika Musterfrau:

Однак не всі деталі вибраного суперключа потрібні для такої унікальної ідентифікації. Комбінації номера рахунку-фактури та номера позиції рахунку-фактури - тобто підмножини суперключа - було б достатньо для ідентифікації окремих записів даних. Такі ключі з мінімальною кількістю атрибутів будуть Ключові кандидати або Альтернативний ключ зателефонував.

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

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

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

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

Якщо ви уважно подивитесь на таблицю зразків, то побачите, що Вимоги до 2-ї нормальної форми з наступних причин не виконано: Стовпець дати залежить лише від номера рахунку-фактури (R.-Nr.), але не від номера позиції рахунку-фактури (P.-Nr.). Те саме стосується імені клієнта, імені, прізвища, вулиці, номера будинку (H.-Nr.), поштового індексу та міста.

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