Какие плюсы и минусы нормализации?

Плюсы и минусы нормализации баз данных

Нормализация базы данных — это процесс структурирования данных для уменьшения избыточности и повышения целостности. Это основной принцип проектирования реляционных БД, но у него есть как преимущества, так и недостатки.

Что такое нормализация

Нормализация приводит БД в одну из нормальных форм (1NF, 2NF, 3NF, BCNF, 4NF, 5NF). Каждая форма устраняет определенные типы аномалий.

-- Ненормализованная таблица (содержит дублирование)
CREATE TABLE Orders (
    order_id INT,
    customer_name VARCHAR(100),
    customer_email VARCHAR(100),
    customer_phone VARCHAR(20),
    product_name VARCHAR(100),
    product_price DECIMAL,
    product_category VARCHAR(50),
    quantity INT
);

-- Нормализованная схема (3NF)
CREATE TABLE Customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    phone VARCHAR(20)
);

CREATE TABLE Products (
    product_id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL,
    category_id INT,
    FOREIGN KEY (category_id) REFERENCES Categories(category_id)
);

CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    FOREIGN KEY (customer_id) REFERENCES Customers(customer_id)
);

CREATE TABLE OrderItems (
    order_item_id INT PRIMARY KEY,
    order_id INT,
    product_id INT,
    quantity INT,
    FOREIGN KEY (order_id) REFERENCES Orders(order_id),
    FOREIGN KEY (product_id) REFERENCES Products(product_id)
);

Плюсы нормализации

1. Уменьшение дублирования данных

# Ненормализованная таблица
# Данные о каждого клиента повторяются для каждого заказа
orders_denormalized = [
    {'order_id': 1, 'customer_name': 'Alice', 'customer_email': 'alice@example.com', 'product': 'Laptop'},
    {'order_id': 2, 'customer_name': 'Alice', 'customer_email': 'alice@example.com', 'product': 'Mouse'},
    {'order_id': 3, 'customer_name': 'Bob', 'customer_email': 'bob@example.com', 'product': 'Keyboard'},
]

# Если у Alice изменится email, нужно обновить несколько строк
# Нормализованная схема решает эту проблему

Преимущество:

• Меньше места занимает в памяти
• Проще обновлять информацию (одно место изменения)
• Экономия на хранилище

2. Обеспечение целостности данных

-- Нормализованная схема предотвращает аномалии
INSERT INTO Customers (customer_id, name, email) VALUES (1, 'Alice', 'alice@example.com');
INSERT INTO Orders (order_id, customer_id) VALUES (1, 1);

-- В ненормализованной таблице могли бы быть противоречия:
-- Order 1: Alice with email alice1@example.com
-- Order 2: Alice with email alice2@example.com
-- Какой email правильный?

Преимущество:

• Внешние ключи (Foreign Keys) гарантируют согласованность
• Аномалии обновления исключены
• Аномалии удаления исключены
• Аномалии вставки исключены

3. Аномалии обновления (Update Anomaly)

-- Ненормализованная таблица
UPDATE Orders SET customer_email = 'newemail@example.com' 
WHERE customer_name = 'Alice';
-- Нужно обновить ВСЕ строки с Alice. Если забыть — рассинхронизация!

-- Нормализованная таблица
UPDATE Customers SET email = 'newemail@example.com' 
WHERE customer_id = 1;
-- Одна строка для обновления

4. Упрощение запросов и логики приложения

# После нормализации проще работать с отдельными сущностями
from sqlalchemy import Column, Integer, String, ForeignKey
from sqlalchemy.orm import relationship

class Customer:
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)
    orders = relationship("Order", back_populates="customer")

class Order:
    id = Column(Integer, primary_key=True)
    customer_id = Column(Integer, ForeignKey('customer.id'))
    customer = relationship("Customer", back_populates="orders")

# Запросы становятся более структурированными
for order in customer.orders:
    print(order.id)

5. Масштабируемость

• Проще добавлять новые таблицы и отношения
• Упрощается управление схемой при росте
• Снижает сложность

Минусы нормализации

1. Усложнение запросов (много JOINов)

-- Простой запрос в ненормализованной таблице
SELECT * FROM Orders WHERE customer_name = 'Alice';

-- Сложный запрос в нормализованной таблице
SELECT o.*, c.*, p.*, cat.* 
FROM Orders o
JOIN Customers c ON o.customer_id = c.customer_id
JOIN OrderItems 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
WHERE c.name = 'Alice';

Недостаток:

• Много JOINов = сложнее читать
• Сложнее оптимизировать
• Может быть медленнее (зависит от индексов)

2. Производительность может упасть

# Ненормализованная таблица — один SELECT
query = "SELECT * FROM orders WHERE customer_name = 'Alice'"

# Нормализованная таблица — несколько SELECT или один сложный JOIN
query = """
SELECT o.*, c.*, oi.*, p.*
FROM Orders o
JOIN Customers c ON o.customer_id = c.customer_id
LEFT JOIN OrderItems oi ON o.order_id = oi.order_id
LEFT JOIN Products p ON oi.product_id = p.product_id
WHERE c.name = 'Alice'
"""

# При наличии миллионов строк разница может быть заметна
# Решение: добавить индексы!

3. Необходимость индексов

-- Без индексов нормализованная таблица будет медленной
CREATE INDEX idx_customer_id ON Orders(customer_id);
CREATE INDEX idx_customer_name ON Customers(name);
CREATE INDEX idx_product_id ON OrderItems(product_id);

-- Это требует дополнительного планирования и мониторинга

4. Избыточная нормализация (над-нормализация)

-- Иногда нормализация идёт слишком далеко
CREATE TABLE NameParts (
    id INT PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50)
);

CREATE TABLE Customers (
    id INT PRIMARY KEY,
    name_id INT,
    FOREIGN KEY (name_id) REFERENCES NameParts(id)
);

-- Это усложняет всё, не давая никаких реальных преимуществ
-- Правило: нормализуйте до 3NF, редко нужна дальше

5. Сложнее работать с денормализованными данными

# При нормализации сложнее получить "флэтовые" данные
# Нужно делать JOIN или собирать данные в приложении

# Ненормализованная
result = {
    'order_id': 1,
    'customer_name': 'Alice',
    'customer_email': 'alice@example.com',
    'product_name': 'Laptop',
    'quantity': 1
}

# Нормализованная (нужна обработка)
result = {
    'order': {'id': 1, 'customer_id': 1},
    'customer': {'id': 1, 'name': 'Alice', 'email': 'alice@example.com'},
    'items': [{
        'product': {'id': 1, 'name': 'Laptop'},
        'quantity': 1
    }]
}

6. Транзакции и ACID требования

-- В нормализованной БД операция может затрагивать несколько таблиц
BEGIN TRANSACTION;
    INSERT INTO Orders (order_id, customer_id) VALUES (1, 1);
    INSERT INTO OrderItems (order_id, product_id, quantity) VALUES (1, 1, 2);
    UPDATE Products SET stock = stock - 2 WHERE product_id = 1;
COMMIT;

-- Если что-то пойдет не так, нужна откат
-- В ненормализованной таблице это был бы один UPDATE

Таблица: плюсы vs минусы

Когда выбрать нормализацию

✅ Используйте нормализацию, когда:

• Много операций записи (INSERT, UPDATE, DELETE)
• Данные часто обновляются
• Целостность критична
• Бюджет на хранилище ограничен
• Долгосрочное приложение
• Нужна масштабируемость

❌ Избегайте полной нормализации, когда:

• Много операций чтения
• Данные редко обновляются
• Производительность критична
• Работаете с аналитикой (Data Warehouse)
• Нужны быстрые отчёты

Практический компромисс: 3NF + денормализация

-- Нормализованная схема
CREATE TABLE Customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

-- Добавим денормализованное поле для частых запросов
CREATE TABLE Orders (
    order_id INT PRIMARY KEY,
    customer_id INT,
    customer_name VARCHAR(100),  -- Денормализованное поле!
    order_date DATE,
    total_amount DECIMAL,  -- Кешированное вычисление
    FOREIGN KEY (customer_id) REFERENCES Customers(customer_id)
);

-- Добавим индекс для оптимизации
CREATE INDEX idx_customer_name ON Orders(customer_name);

Вывод

Нормализация — это баланс:

• В OLTP системах (operational, много операций): используйте нормализацию (3NF+)
• В OLAP системах (analytical, много чтения): используйте денормализацию (Star Schema)
• В реальных проектах: комбинируйте оба подхода

Золотое правило:

Нормализуйте до 3NF, потом денормализуйте где нужно производительность

Не следуйте нормализации слепо — анализируйте паттерны запросов и оптимизируйте под них!