Назови три нормальные формы в SQL

Три основные нормальные формы в SQL

В теории реляционных баз данных нормализация — это процесс организации данных для уменьшения избыточности и улучшения их целостности. Три первые и наиболее важные нормальные формы (1NF, 2NF, 3NF) являются фундаментальными ступенями этого процесса.

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

Первая нормальная форма устанавливает базовые требования для структуры таблицы:

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

Пример нарушения 1NF и ее приведение:

-- НЕ 1NF: в колонке 'phones' хранится список значений
CREATE TABLE contacts (
    id INT,
    name VARCHAR(100),
    phones VARCHAR(255) -- Например: "123-456, 789-012"
);

-- 1NF: атомарные значения, отдельная строка для каждого телефона
CREATE TABLE contacts_1nf (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    phone VARCHAR(20) -- Один телефон на строку
);

Чтобы привести к 1NF, "составные" данные нужно разделить на отдельные строки или колонки.

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

Таблица находится во второй нормальной форме, если:

• Она уже удовлетворяет 1NF.
• Все неключевые атрибуты полностью зависят от всего первичного ключа, а не от какой-то его части.

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

Пример нарушения 2NF и исправление:

-- НЕ 2NF: составный PK (order_id, product_id). 'supplier_name' зависит только от product_id.
CREATE TABLE order_details (
    order_id INT,
    product_id INT,
    quantity INT,
    supplier_name VARCHAR(100), -- Атрибут частичной зависимости!
    PRIMARY KEY (order_id, product_id)
);

-- 2NF: Разделяем на две таблицы, удаляя частичную зависимость
CREATE TABLE orders_products (
    order_id INT,
    product_id INT,
    quantity INT,
    PRIMARY KEY (order_id, product_id)
);

CREATE TABLE products (
    product_id INT PRIMARY KEY,
    supplier_name VARCHAR(100)
);

Атрибут supplier_name был перемещен в таблицу products, от которой он зависит полностью.

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

Таблица находится в третьей нормальной форме, если:

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

Если атрибут A зависит от атрибута B, а B зависит от первичного ключа PK, то существует транзитивная зависимость PK → B → A. Атрибут A нужно вынести.

Пример нарушения 3NF и приведение к ней:

-- НЕ 3NF: 'department_phone' зависит от 'department', который зависит от PK (employee_id).
CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100),
    department VARCHAR(50),
    department_phone VARCHAR(20) -- Транзитивная зависимость!
);

-- 3NF: Удаляем транзитивную зависимость, создавая отдельную таблицу для department.
CREATE TABLE employees_3nf (
    employee_id INT PRIMARY KEY,
    name VARCHAR(100),
    department_id INT -- Ссылка на ключ из новой таблицы
);

CREATE TABLE departments (
    department_id INT PRIMARY KEY,
    department_name VARCHAR(50),
    phone VARCHAR(20)
);

Теперь телефон отдела хранится непосредственно в своей сущности (departments), и зависимость employee_id → department_id → phone становится прямой через связь по ключу, что соответствует 3NF.

Практическое значение и выводы

• 1NF — базовый технический стандарт для работы с SQL.
• 2NF и 3NF — логические шаги для минимизации аномалий при обновлении, удалении и добавлении данных. Они предотвращают:

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

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

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