Что такое нормализация базы данных: формы, этапы и примеры

Что такое нормализация базы данных

Нормализация БД — метод проектирования реляционных СУБД, при котором данные организуются по правилам функциональных зависимостей. Метод называется итеративным: таблицы последовательно приводятся к нормальным формам путём декомпозиции — разбиения одной таблицы на несколько связанных.

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

Нормализация данных в БД применяется прежде всего в транзакционных системах (OLTP), где данные часто добавляются и изменяются.

Откуда появилась нормализация: Эдгар Кодд

Эдгар Кодд (Edgar F. Codd), исследователь IBM, в 1970 году опубликовал статью «A Relational Model of Data for Large Shared Data Banks» и заложил теоретическую основу метода нормальных форм. Уильям Кент в 1983 году сформулировал практический ориентир, ставший эталонным: «атрибут должен зависеть от ключа, от всего ключа и ни от чего, кроме ключа». Эта формула описывает требования 2НФ и 3НФ одновременно.

Зачем нужна нормализация: три аномалии данных

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

Отдельный антипаттерн — хранение нескольких значений в одной ячейке: products = ‘Кола, Пицца’. Поиск через LIKE ‘%Кола%’ по такой строке — признак избыточности данных в базе данных: индексы не работают, GROUP BY невозможен. Три аномалии — симптомы одной причины. Нормализация устраняет её: разносит факты по отдельным таблицам.

Ключевые понятия: ключи и функциональные зависимости

Перед разбором форм — три понятия, без которых принципы нормализации базы данных не работают.

Иерархия ключей. Суперключ — любое множество атрибутов, однозначно идентифицирующих строку. Потенциальный ключ — минимальный суперключ. Один из потенциальных назначается первичным. Составной ключ состоит из нескольких атрибутов.

Функциональная зависимость A→B: значение A однозначно определяет значение B. Например, product_id → product_name.

Частичная зависимость нарушает 2НФ: атрибут зависит от части составного ключа, а не от всего ключа. Транзитивная зависимость в базе данных нарушает 3НФ: цепочка A→B→C, где A — ключ, B и C — неключевые атрибуты. Именно по функциональным зависимостям в БД определяют, какие атрибуты нужно вынести в отдельную таблицу.

Этапы нормализации: 1НФ, 2НФ и 3НФ

Нормализация кумулятивна: каждая следующая форма включает требования предыдущей. Уровни нормализации базы данных проходятся последовательно. Сквозной пример — таблица orders(order_id, customer, phone, products, price) — шаг за шагом нормализуется от ненормализованной формы (UNF) до 3НФ.

Первая нормальная форма (1НФ): атомарные значения

Правило 1НФ: каждая ячейка содержит одно неделимое (атомарное) значение. Никаких списков через запятую, никаких массивов.

Нарушение: products = ‘Кола, Пицца’. Решение — развернуть каждый товар в отдельную строку:

— До 1НФ

CREATE TABLE orders (

order_id INT,

customer VARCHAR(100),

phone VARCHAR(20),

products VARCHAR(255), — ‘Кола, Пицца’ — нарушение 1НФ

price DECIMAL(10,2)

);

— После 1НФ

CREATE TABLE orders_1nf (

order_id INT,

customer VARCHAR(100),

phone VARCHAR(20),

product VARCHAR(100),

price DECIMAL(10,2),

PRIMARY KEY (order_id, product) — составной ключ

);

После приведения к 1 нф в БД GROUP BY по товару становится возможен. Побочный эффект: данные клиента всё ещё дублируются в каждой строке — это устранит 2НФ.

Вторая нормальная форма (2НФ): устранение частичных зависимостей

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

В нашей таблице ключ составной: (order_id, product). Цена зависит только от товара — это частичная зависимость, нарушение 2НФ.

— Вторая нормальная форма: декомпозиция

CREATE TABLE products (

product_id SERIAL PRIMARY KEY,

name VARCHAR(100),

price DECIMAL(10,2)

);

CREATE TABLE order_items (

order_id INT REFERENCES orders(order_id),

product_id INT REFERENCES products(product_id),

quantity INT,

PRIMARY KEY (order_id, product_id)

);

Цена хранится в одном месте: изменение в products отражается везде автоматически.

Третья нормальная форма (3НФ): устранение транзитивных зависимостей

Правило 3НФ: ни один неключевой атрибут не зависит от другого неключевого. Именно это описывает формула Уильяма Кента: «зависит от ключа, от всего ключа и ни от чего, кроме ключа».

В таблице после 2НФ остаётся цепочка: order_id → customer → phone. Телефон зависит от имени клиента, а не от заказа — транзитивная зависимость в БД.

— Третья нормальная форма: выносим клиентов

CREATE TABLE customers (

customer_id SERIAL PRIMARY KEY,

name VARCHAR(100),

phone VARCHAR(20)

);

CREATE TABLE orders (

order_id SERIAL PRIMARY KEY,

customer_id INT REFERENCES customers(customer_id),

order_date DATE

);

Итог: четыре связанных таблицы вместо одной — customers, orders, order_items, products. Каждый факт хранится ровно один раз. Процесс нормализации отношения завершён: изменение в любой таблице требует правки ровно в одном месте.

Нормализация и денормализация: когда правила нарушают осознанно

Нормализация модели базы данных оптимальна для транзакционных систем (OLTP) с частыми операциями записи. Аналитические системы (OLAP) и хранилища данных (DWH) преследуют другую цель — скорость чтения больших объёмов, — и используют противоположный подход.

Денормализация — осознанный компромисс: скорость чтения растёт за счёт дублирования данных. Самый распространённый паттерн в DWH — Star Schema (схема «звезда»): центральная таблица фактов (fact_orders) окружена таблицами измерений (dim_customers, dim_products, dim_dates). Такой подход используют колоночные СУБД — ClickHouse, BigQuery, Redshift.

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

Формы выше 3НФ: BCNF, 4НФ и 5НФ

Для большинства продуктовых баз данных нормальные формы СУБД выше третьей применяются редко. Три строгих варианта — в таблице.

Усложнение схемы без конкретной технической причины не окупается: 3НФ достаточна для подавляющего большинства типов нормализации баз данных в продуктовых OLTP-проектах.

Хотите разобраться в проектировании баз данных и освоить SQL профессионально? В рамках федерального проекта «Активные меры содействия занятости» можно пройти обучение по востребованным IT-направлениям — аналитика, информационные системы, 1С — бесплатно и без отрыва от работы. Смотрите каталог программ обучения.

Часто задаваемые вопросы

Что такое нормализация базы данных простыми словами?

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

Какие аномалии устраняет нормализация?

Три типа: аномалия обновления — одно изменение требует правки множества строк; аномалия вставки — нельзя добавить клиента без заказа; аномалия удаления — удаляя заказ, теряем данные о клиенте. Все три вызваны дублированием данных. Нормализация устраняет первопричину — разносит факты по отдельным таблицам.

Чем 1НФ, 2НФ и 3НФ отличаются друг от друга?

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

Что такое транзитивная зависимость в базе данных?

Цепочка A→B→C, где A — ключ, B и C — неключевые атрибуты. Пример: order_id → customer_id → phone. Телефон зависит от клиента, а не от заказа — это транзитивная зависимость в БД. Она нарушает 3НФ. Решение — вынести клиентов в отдельную таблицу customers.

Когда денормализация оправдана?

В аналитических системах (OLAP, DWH), где приоритет — скорость чтения больших объёмов. Аналитические запросы с десятками JOIN замедляют работу. Решение — Star Schema или плоские таблицы. Ключевое правило: денормализация всегда осознанная — ответственность за согласованность дублей ложится на код, а не на СУБД.

Достаточно ли третьей нормальной формы?

Для большинства продуктовых (OLTP) баз — да. BCNF нужна при перекрывающихся составных ключах, 4НФ — при многозначных зависимостях, 5НФ — при JOIN-зависимостях. Эти случаи редки в типовых приложениях. Усложнение схемы выше 3НФ не окупается без конкретной технической причины.

Что значит нормализация отношений в реляционной базе данных?

В теории реляционных баз «отношение» — математический термин для таблицы. Нормализация отношений — приведение каждой таблицы к нормальной форме по правилам функциональных зависимостей. Это синоним нормализации базы данных, используемый в академической литературе и учебниках по теории СУБД.

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

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