Преимущества и недостатки нормализации

Сегодня мы еще раз, теперь — подробнее — остановимся на важной теме: преимущества и недостатки нормализации, чтобы вы лучше разобрались, как эти концепции применяются в реальной жизни. Итак, пристёгивайте ремни — мы начинаем!

Устранение избыточности данных

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

Пример:

-- До нормализации
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. Иногда избыточность полезна

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

2

Задача

SQL SELF, 26 уровень, 4 лекция

Недоступна

Построение денормализованного представления

Построение денормализованного представления

Открыть

1

Опрос

Анализ существующих баз данных, 26 уровень, 4 лекция

Недоступен

Анализ существующих баз данных

Анализ существующих баз данных

Открыть