Что такое нормальные формы в БД?

Нормальные формы в базах данных: обеспечение целостности и эффективности

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

Основные нормальные формы (1NF — 3NF)

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

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

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

• Атомарность: Значение в каждой клетке — одно, не составное. Например, поле "Адрес" должно быть разделено на "Город", "Улица", "Дом".
• Отсутствие повторений: Не должно быть, например, колонок "Телефон1", "Телефон2".

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

-- НЕ в 1NF: составное значение и повторяющаяся группа
CREATE TABLE Clients (
    id INT,
    name VARCHAR,
    phone_numbers VARCHAR -- Может содержать "123-456, 789-012"
);

-- В 1NF: атомарные значения
CREATE TABLE Clients (
    id INT PRIMARY KEY,
    name VARCHAR
);

CREATE TABLE ClientPhones (
    client_id INT,
    phone VARCHAR -- Одно значение на строку
);

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

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

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

Пример (заказ товаров):

-- НЕ в 2NF: цена товара зависит только от товара, а не от "заказ+товар"
CREATE TABLE OrderDetails (
    order_id INT,
    product_id INT,
    quantity INT,
    product_price DECIMAL, -- Атрибут зависит только от product_id!
    PRIMARY KEY (order_id, product_id)
);

-- В 2NF: разделяем зависимости
CREATE TABLE Orders (
    order_id INT PRIMARY KEY
);

CREATE TABLE Products (
    product_id INT PRIMARY KEY,
    price DECIMAL
);

CREATE TABLE OrderDetails (
    order_id INT,
    product_id INT,
    quantity INT,
    PRIMARY KEY (order_id, product_id)
);

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

Таблица должна быть в 2NF, и неключевые атрибуты должны быть независимы друг от друга. То есть не должно быть транзитивных зависимостей (A → B → C, где A — ключ).

• Если атрибут X зависит от атрибута Y, а Y зависит от ключа, то X также нужно выделить в отдельную таблицу.

Пример (сотрудники и отделы):

-- НЕ в 3NF: город зависит от отдела, а не напрямую от сотрудника
CREATE TABLE Employees (
    emp_id INT PRIMARY KEY,
    name VARCHAR,
    dept_name VARCHAR,
    dept_city VARCHAR -- Транзитивная зависимость: emp_id → dept_name → dept_city
);

-- В 3NF: устранение транзитивной зависимости
CREATE TABLE Employees (
    emp_id INT PRIMARY KEY,
    name VARCHAR,
    dept_id INT
);

CREATE TABLE Departments (
    dept_id INT PRIMARY KEY,
    name VARCHAR,
    city VARCHAR
);

Дополнительные нормальные формы

• BCNF (Нормальная форма Бойса-Кодда): Усиленная версия 3NF для случаев, когда есть несколько возможных ключей (кандидатов). Она требует, чтобы каждый детерминант (атрибут, от которого зависят другие) был кандидатом на ключ.
• 4NF: Устраняет многозначные зависимости, когда один атрибут зависит от другого не функционально, а множественно (например, один сотрудник может иметь несколько специализаций и несколько телефонных номеров независимо).
• 5NF (Нормальная форма проекции-join): Решает проблемы, возникающие при соединении таблиц, гарантируя, что исходная таблица может быть точно восстановлена из её проекций без потери информации.

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

Применение нормальных форм (обычно до уровня 3NF) в разработке на Go и работе с базами данных (например, через database/sql или ORM) дает ключевые преимущества:

1. Снижение избыточности: Экономия дискового пространства и предотвращение противоречий данных.
2. Упрощение операций CRUD: Обновление, удаление или добавление данных затрагивает минимальное количество строк.
3. Улучшение производительности запросов: Четкая структура позволяет эффективно использовать индексы и оптимизировать JOIN-операции.
4. Повышение целостности: Легче поддерживать ссылочную целостность через FOREIGN KEY и избегать аномалий.
5. Масштабируемость и гибкость: Нормализованная схема легче адаптируется к изменению бизнес-логики.

Важно помнить, что нормализация — это дизайнерский выбор. Степень нормализации зависит от конкретных требований приложения. Чрезмерная нормализация может привести к большому количеству таблиц и сложным JOIN-запросам, что иногда негативно влияет на производительность чтения. В таких случаях допустимо контролируемое денормализация — сознательное отступление от нормальных форм для оптимизации частых операций чтения, особенно в системах, ориентированных на аналитику (OLAP).