Сьогодні ми ще раз, тепер — детальніше — зупинимось на важливій темі: переваги та недоліки нормалізації, щоб ти краще розібрався, як ці концепції працюють у реальному житті. Отже, пристібай ремені — ми починаємо!
Усунення надлишковості даних
Коли дані в таблиці не нормалізовані, ти можеш помітити, що одна й та сама інформація дублюється у різних рядках. Наприклад, у таблиці з замовленнями може бути повторювана адреса клієнта для кожного замовлення. Нормалізація прибирає такі дублювання, перекладаючи спільні дані в окремі таблиці.
Приклад:
-- До нормалізації
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT,
order_date DATE
);
-- Після нормалізації
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE
);Чому це важливо? Менше дубльованих даних означає менше шансів на помилки. Якщо адреса клієнта зміниться, тобі треба буде оновити дані лише в одному місці.
Забезпечення цілісності даних
Коли дані розділені на логічні таблиці, легко керувати їх зв'язками. Використання зовнішніх ключів допомагає підтримувати цілісність даних автоматично. Наприклад, ти не зможеш випадково видалити клієнта, на якого посилаються записи в таблиці замовлень.
Приклад:
-- Зовнішній ключ гарантує, що видалення клієнта видалить і пов'язані замовлення
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;
Ти можеш бути впевнений, що структура бази даних не дозволить появу "осиротілих" даних.
Спрощення оновлень
Коли твоя база даних нормалізована, оновлення стають легкими і менш схильними до помилок. Повернемось до прикладу з клієнтами — якщо клієнт змінює адресу, ти оновлюєш його запис лише в одній таблиці. У ненормалізованих таблицях ймовірно, що ти забудеш оновити адресу в деяких рядках, що призведе до неузгодженості даних.
Мінімізація аномалій
Аномалії вставки: у ненормалізованій таблиці ти можеш зіткнутись із ситуацією, коли неможливо додати запис без зайвої інформації. Наприклад, не можна додати замовлення, поки невідоме ім'я клієнта.
Аномалії оновлення: можуть виникати помилки при оновленні даних. Наприклад, при зміні імені клієнта в одному рядку в іншому воно залишиться старим.
Аномалії видалення: видалення запису може призвести до втрати важливої інформації. Наприклад, видалення замовлення також видаляє ім'я клієнта, якщо ці дані зберігаються в одній таблиці.
Зменшення обсягу даних
Нормалізація часто зменшує розмір бази даних, бо прибирається дублювання даних. Це важливий аспект для зберігання великих обсягів інформації.
Недоліки нормалізації
1. Складність структури бази даних
З часом нормалізація може призвести до складної структури бази даних, що складається з тисяч(!) пов'язаних таблиць. У таких випадках для отримання даних, які раніше були в одній таблиці, треба писати складні SQL-запити з багатьма з'єднаннями (JOIN).
Приклад складності:
-- Запит для отримання інформації про замовлення з деталями по товарам і категоріям
SELECT
o.order_id,
o.order_date,
c.customer_name,
p.product_name,
cat.category_name,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;
Якщо кількість таблиць і зв'язків зростає, час виконання запитів може сильно збільшитись.
2. Зниження продуктивності при частих з'єднаннях
Часто з'єднання таблиць (JOIN) може бути ресурсоємним, особливо якщо таблиці великі й не мають індексів. В аналітичних системах, де запити вимагають обробки мільйонів рядків, нормалізація призводить до значних штрафів по продуктивності.
3. Потреба у додаткових операціях для денормалізації
Якщо нормалізована структура бази даних використовується для аналітичних цілей, її доводиться тимчасово денормалізувати для прискорення аналітичних запитів. Це може включати створення представлень (VIEW) або таблиць для агрегації даних.
Приклад:
-- Денормалізоване представлення для аналітики
CREATE VIEW orders_with_customers AS
SELECT
o.order_id,
o.order_date,
c.customer_name,
c.customer_address
FROM
orders o
JOIN
customers c ON o.customer_id = c.customer_id;
4. Високий поріг входу
Для новачків нормалізація може здаватись складною. Замість однієї таблиці, що містить всі дані, доводиться працювати з кількома таблицями і розбиратись у їх зв'язках. Це може сповільнити розробку, особливо якщо команда не має високого рівня компетенції у базах даних.
5. Іноді надлишковість корисна
У реальних проектах іноді вигідніше зберігати надлишкові дані заради підвищення продуктивності. Наприклад, якщо застосунок часто використовує дані, які можна отримати лише шляхом складного з'єднання, то краще зберігати їх в одній таблиці.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ