Нормализация данных¶

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

¶История и предпосылки

Концепция нормализации была впервые предложена американским математиком и пионером реляционной теории баз данных Эдгаром Коддом в 1970 году в его статье «A Relational Model of Data for Large Shared Data Banks». Кодд определил три первые нормальные формы (1НФ, 2НФ, 3НФ). Позднее, в 1974 году, британский учёный Рэймонд Бойс совместно с Коддом разработали более строгую форму — нормальную форму Бойса — Кодда (НФБК). В 1970-х — 1980-х годах Рональд Фейгин и другие исследователи предложили четвёртую (4НФ) и пятую (5НФ) нормальные формы, а также доменно-ключевую нормальную форму (ДКНФ). Развитие теории нормализации было обусловлено практической необходимостью борьбы с избыточностью данных в первых коммерческих реляционных СУБД, таких как Oracle, DB2 и Ingres.

¶Основные понятия

¶Избыточность данных

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

¶Аномалии

Выделяют три основных типа аномалий:

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

¶Функциональная зависимость

Функциональная зависимость (ФЗ) — это отношение между наборами атрибутов таблицы, при котором значение одного набора однозначно определяет значение другого набора. Например, для таблицы «Сотрудники» атрибут «Табельный номер» функционально определяет атрибут «Фамилия». Обозначается как: {Табельный номер} → {Фамилия}.

¶Ключи

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

¶Нормальные формы

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

¶Первая нормальная форма (1НФ)

Таблица находится в 1НФ, если все её атрибуты содержат только атомарные (неделимые) значения, и в каждом столбце хранятся данные одного типа. Запрещается использование повторяющихся групп (например, нескольких значений в одной ячейке) и массивов. Для приведения к 1НФ необходимо:

• Разделить составные атрибуты (например, «Адрес» разбить на «Город», «Улица», «Дом»).
• Устранить повторяющиеся группы путём создания отдельных строк для каждого значения.

¶Вторая нормальная форма (2НФ)

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

• Выделить атрибуты, зависящие только от части ключа, и вынести их в отдельные таблицы.

¶Третья нормальная форма (3НФ)

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

• Выделить атрибуты, образующие транзитивную зависимость, в отдельную таблицу.

¶Нормальная форма Бойса — Кодда (НФБК)

Таблица находится в НФБК, если для каждой нетривиальной функциональной зависимости X → Y (где Y не является подмножеством X) выполняется условие: X является потенциальным ключом. НФБК является более строгой версией 3НФ и устраняет аномалии, связанные с перекрывающимися потенциальными ключами. Большинство таблиц, находящихся в 3НФ, автоматически находятся и в НФБК, однако существуют исключения.

¶Четвёртая нормальная форма (4НФ)

Таблица находится в 4НФ, если она находится в НФБК и не содержит многозначных зависимостей. Многозначная зависимость возникает, когда один атрибут однозначно определяет множество значений другого атрибута, независимо от третьего. Для приведения к 4НФ необходимо разделить таблицу на две, каждая из которых содержит пару атрибутов, связанных многозначной зависимостью.

¶Пятая нормальная форма (5НФ)

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

¶Доменно-ключевая нормальная форма (ДКНФ)

Таблица находится в ДКНФ, если каждое ограничение целостности является логическим следствием ограничений доменов и ключей. ДКНФ считается теоретически идеальной формой, но её достижение на практике часто невозможно.

¶Процесс нормализации на примере

Рассмотрим таблицу «Заказы»:

• 1НФ: Таблица уже находится в 1НФ, так как все значения атомарны.
• 2НФ: Первичный ключ — составной (ID заказа, Товар). Атрибут Цена товара зависит только от Товар, а не от всего ключа. Атрибуты Клиент и Город клиента зависят только от ID заказа. Следовательно, таблица не находится во 2НФ. Для приведения к 2НФ создаём три таблицы:
• Заказы (ID заказа, Клиент, Город клиента)
• Товары (Товар, Цена товара)
• Состав заказа (ID заказа, Товар)
• 3НФ: В таблице Заказы атрибут Город клиента транзитивно зависит от ID заказа через Клиент. Для приведения к 3НФ создаём:
• Клиенты (Клиент, Город клиента)
• Заказы (ID заказа, Клиент)
• Товары (Товар, Цена товара)
• Состав заказа (ID заказа, Товар)

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

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

¶Применение

Нормализация данных является стандартным этапом проектирования реляционных баз данных. Она применяется:

• При разработке корпоративных информационных систем (ERP, CRM).
• В системах управления базами данных (СУБД) для обеспечения целостности.
• При проектировании схем данных в банковской сфере, здравоохранении, логистике.
• В научных исследованиях, где требуется хранение структурированных данных с минимальной избыточностью.

Однако в современных NoSQL-базах данных (например, MongoDB, Cassandra) нормализация часто не применяется, так как они ориентированы на хранение денормализованных, документо-ориентированных данных для обеспечения масштабируемости.

¶Критика

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

• Сложность проектирования: необходимость анализа функциональных зависимостей и последовательного применения нормальных форм может быть трудоёмкой.
• Снижение производительности: большое количество таблиц и соединений (JOIN) может замедлять выполнение запросов.
• Избыточность в теории: некоторые исследователи считают, что на практике достаточно достижения 3НФ или НФБК, а более высокие формы (4НФ, 5НФ) имеют ограниченное применение.

Тем не менее, нормализация остаётся фундаментальным принципом реляционной теории и обязательным элементом обучения проектированию баз данных.

¶Источники

1. Кодд Э. Ф. «A Relational Model of Data for Large Shared Data Banks» (1970).
2. Дейт К. Дж. «Введение в системы баз данных» (8-е издание).
3. Фейгин Р. «Multivalued Dependencies and a New Normal Form for Relational Databases» (1977).
4. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. «Системы баз данных. Полный курс».
5. ISO/IEC 9075:2023 — стандарт языка SQL.