Что такое нормальные формы в базе данных?

Нормальные формы в реляционных базах данных

Нормальные формы (НФ) — это набор правил и принципов проектирования реляционных баз данных, направленных на устранение избыточности, аномалий при вставке, обновлении и удалении данных, а также на обеспечение логической целостности. Нормализация — это процесс приведения структуры базы данных к соответствию этим правилам. Основная цель — создание эффективной, непротиворечивой и легко поддерживаемой структуры данных.

Зачем нужна нормализация?

• Устранение избыточности данных: Одни и те же данные не должны храниться в нескольких местах. Это экономит место и, что важнее, предотвращает рассогласование данных при обновлениях.
• Предотвращение аномалий:

    *   **Аномалии вставки:** Невозможность добавить данные о новом объекте, пока нет информации о связанном объекте (например, нельзя добавить нового сотрудника, пока не назначен его отдел).
    *   **Аномалии обновления:** Необходимость обновлять одни и те же данные в нескольких строках, что может привести к противоречивости.
    *   **Аномалии удаления:** Потеря связанных данных при удалении основной записи (например, удаление последнего сотрудника отдела ведет к потере информации о самом отделе).

• Обеспечение логической целостности: Данные организованы в логичные, семантически цельные сущности.

Основные нормальные формы (от 1NF до 3NF и BCNF)

Процесс нормализации обычно последователен: достижение 1NF является обязательным условием для перехода к 2NF, а 2NF — для 3NF.

---

1. Первая нормальная форма (1NF)

Требование: Все атрибуты (столбцы) таблицы должны быть атомарными (неделимыми), а в таблице не должно быть повторяющихся групп.

• Атомарность: Значение в каждой ячейке должно быть единственным, не составным (не список, не массив).
• Отсутствие повторяющихся групп: Не должно быть столбцов типа Телефон1, Телефон2, ТелефонN.

Пример нарушения 1NF: Таблица Заказы со столбцом Товары: "Ноутбук, Мышь, Клавиатура" (составное значение) или Телефоны: "123; 456".

Приведение к 1NF: Составные значения выносятся в отдельные строки или столбцы. Чаще для связи "один-ко-многим" создается отдельная таблица.

-- НЕ 1NF (повторяющаяся группа)
CREATE TABLE orders_non1nf (
    order_id INT,
    customer_name VARCHAR(100),
    item1 VARCHAR(100),
    item2 VARCHAR(100) -- Что если заказ на 3 товара?
);

-- 1NF: Выносим позиции заказа в отдельную таблицу
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    customer_name VARCHAR(100)
);

CREATE TABLE order_items (
    order_item_id INT PRIMARY KEY,
    order_id INT,
    item_name VARCHAR(100),
    FOREIGN KEY (order_id) REFERENCES orders(order_id)
);

2. Вторая нормальная форма (2NF)

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

Это правило актуально для таблиц с составным первичным ключом. Если ключ простой, то таблица в 1NF автоматически находится и во 2NF.

Пример нарушения 2NF: Таблица Заказ_Позиция (order_id, product_id, product_name, quantity). Здесь составной ключ (order_id, product_id). Атрибут product_name зависит только от product_id (части ключа), но не от всего ключа (order_id, product_id).

Приведение к 2NF: Выносим атрибуты, зависящие от части ключа, в отдельную таблицу.

-- НЕ 2NF: product_name зависит только от product_id
CREATE TABLE order_details_non2nf (
    order_id INT,
    product_id INT,
    product_name VARCHAR(100), -- Нарушение!
    quantity INT,
    PRIMARY KEY (order_id, product_id)
);

-- 2NF: Выносим информацию о товаре
CREATE TABLE products (
    product_id INT PRIMARY KEY,
    product_name VARCHAR(100)
);

CREATE TABLE order_details (
    order_id INT,
    product_id INT,
    quantity INT,
    PRIMARY KEY (order_id, product_id),
    FOREIGN KEY (product_id) REFERENCES products(product_id)
);

3. Третья нормальная форма (3NF)

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

Пример нарушения 3NF: Таблица Сотрудники (employee_id, department_id, department_name, department_location). Здесь department_name и department_location зависят от department_id (неключевой атрибут), а тот, в свою очередь, зависит от первичного ключа employee_id. Это транзитивная зависимость.

Приведение к 3NF: Выносим атрибуты, имеющие зависимость от другого неключевого атрибута, в отдельную таблицу.

-- НЕ 3NF: department_name зависит от department_id (неключевой атрибут)
CREATE TABLE employees_non3nf (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100),
    department_id INT,
    department_name VARCHAR(100) -- Нарушение! Транзитивная зависимость.
);

-- 3NF: Создаем отдельную сущность "Отдел"
CREATE TABLE departments (
    department_id INT PRIMARY KEY,
    department_name VARCHAR(100)
);

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100),
    department_id INT,
    FOREIGN KEY (department_id) REFERENCES departments(department_id)
);

4. Нормальная форма Бойса-Кодда (BCNF / 3.5NF)

Более строгая версия 3NF. Требует, чтобы каждая определяющая функциональная зависимость была зависимостью от потенциального ключа (кандидатного ключа).

Главное отличие от 3NF: В 3NF допускается зависимость неключевого атрибута от другого неключевого атрибута (если он является частью кандидатного ключа). BCNF устраняет эту оговорку.

На практике большинство таблиц, приведенных к 3NF, уже находятся и в BCNF. Явные нарушения BCNF встречаются реже и часто связаны с перекрывающимися кандидатными ключами.

Денормализация

На практике строгое следование всем нормальным формам, особенно для сложных аналитических запросов (OLAP), может привести к необходимости большого количества JOIN операций и снижению производительности чтения. Денормализация — это сознательный процесс добавления контролируемой избыточности или объединения таблиц для оптимизации скорости выполнения запросов. Это компромисс между производительностью чтения и целостностью/эффективностью записи. Часто используется в хранилищах данных (Data Warehouses).

Заключение

Нормализация до 3NF/BCNF является стандартом для OLTP-систем (оперативная обработка транзакций), где критична целостность данных и эффективность операций обновления. Понимание нормальных форм — фундаментальный навык backend-разработчика, позволяющий проектировать устойчивые, масштабируемые и логически правильные модели данных, что напрямую влияет на надежность и производительность всего приложения.