Ответ
Денормализация — это намеренное дублирование данных или объединение таблиц в контексте реляционных баз данных для повышения производительности чтения, ценой увеличения избыточности данных и усложнения операций обновления.
Зачем это нужно? В нормализованной схеме данные разделены по многим таблицам для минимизации аномалий. Для сложных аналитических запросов (OLAP) или в высоконагруженных OLTP-системах это приводит к большому количеству JOIN-операций, что замедляет чтение. Денормализация решает эту проблему.
Пример: Нормализованная схема для интернет-магазина:
-- Много JOIN для получения отчета
SELECT o.order_id, o.date, c.name, p.product_name, oi.quantity
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id;
Денормализованная таблица для отчетов (Data Mart):
CREATE TABLE sales_fact (
order_id INT,
order_date DATE,
customer_name VARCHAR(255), -- Дублируем из customers
product_name VARCHAR(255), -- Дублируем из products
quantity INT,
total_amount DECIMAL(10,2)
);
-- Теперь запрос быстрый и без JOIN:
SELECT * FROM sales_fact WHERE order_date > '2024-01-01';
Типичные сценарии применения:
- Хранилища данных (DWH) и витрины данных: Создание широких фактологических таблиц для ускорения аналитических запросов.
- Высоконагруженные веб-приложения: Дублирование часто запрашиваемых данных (например, имени пользователя в таблице комментариев) для избежания JOIN к основной таблице пользователей.
- Системы отчетности.
Недостатки:
- Избыточность данных: Увеличивается размер базы.
- Сложность обновлений: Изменение данных должно быть синхронизировано во всех дублирующихся местах (часто решается через ETL-процессы или триггеры).
- Риск несогласованности: При ошибках в процессе обновления данные могут разойтись.
Вывод: Денормализация — это компромисс. Она применяется осознанно там, где скорость чтения критически важна, а обновления происходят реже или управляются отдельными процессами.