Что хотят услышать интервьюеры:

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

Определение:

Нормализация — это приведение структуры базы данных к форме, при которой уменьшается дублирование данных и снижается риск несогласованности. Если нормализация выполнена неправильно, база начинает либо хранить одни и те же данные в нескольких местах, либо становится слишком «разобранной» на множество таблиц, что усложняет использование.

Основные негативные последствия:

дублирование данных и рост объёма хранения;
аномалии обновления, когда одно изменение нужно вносить в несколько строк;
аномалии вставки, когда невозможно добавить данные без лишних зависимостей;
аномалии удаления, когда удаление одной записи случайно уничтожает полезную информацию;
усложнение запросов из-за большого числа JOIN;
падение производительности на чтении или записи в зависимости от степени нормализации.

Пример использования:

Допустим, в таблице заказов хранятся и данные клиента, и данные заказа:

CREATE TABLE orders (
    order_id   BIGINT,
    customer_id BIGINT,
    customer_name VARCHAR(100),
    customer_phone VARCHAR(20),
    product_name VARCHAR(100),
    order_date DATE
);

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

Более нормализованный вариант обычно разделяет сущности:

CREATE TABLE customers (
    customer_id BIGINT PRIMARY KEY,
    name VARCHAR(100),
    phone VARCHAR(20)
);

CREATE TABLE orders (
    order_id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    product_name VARCHAR(100),
    order_date DATE,
    FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Пояснение кода:

Код показывает разницу между денормализованной и более нормализованной структурой.

В первом варианте:

Данные клиента повторяются в каждой записи заказа.
При изменении телефона нужно обновлять много строк.
При удалении заказа можно случайно потерять данные клиента.
Таблица становится шире и быстрее накапливает несогласованность.

Во втором варианте:

Данные клиента хранятся отдельно.
Заказ ссылается на клиента через customer_id.
Изменение телефона делается в одном месте.
Связь между сущностями сохраняется через внешний ключ.

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

Ключевые моменты:

Неправильная нормализация ведёт либо к избыточности, либо к чрезмерной фрагментации данных.
Основные риски: аномалии вставки, обновления и удаления.
Избыточность ухудшает целостность и увеличивает объём хранения.
Слишком сильная нормализация может усложнить JOIN-ы и снизить производительность.
На практике важно выбирать баланс между нормализацией, читаемостью схемы и скоростью запросов.

Какие негативные последствия могут возникнуть при неправильной нормализации базы данных?