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

Что такое нормализация БД

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

Преимущества:

• Пользователь может получить нужную ему информацию, используя только простые запросы.
• Существенно снижается вероятность потери данных, а также минимизируется возможное искажение информации.
• Если всё делать по правилам, то в дальнейшем не будет проблем с наращиванием БД.
• Можно избежать избыточности (дублирования данных), что позволит оптимизировать размер БД (будет занимать меньше места).
• Нормализация позволяет убрать несогласованные зависимости, которые существенно замедляют доступ к данным, хранящимся в базе.

Если подробнее рассмотреть преимущества процедуры, становится понятно, что она является необходимой для поддержки нормального функционирования БД. Но стоит заметить, что данный процесс может занять достаточно продолжительное время. И желательно на время проведения процедуры отключать базу. Впрочем, всё зависит от того, по какой схеме была реализована СХД для хранения базы.

Основные термины

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

• Атрибут. Под этим термином в большинстве случаев понимается поле таблицы. Однако в книгах подаётся определение немного иное — «свойство некой сущности».
• Домен атрибута. Характеристика домена атрибута включает в себя разрешенные варианты значений, которые атрибут может принимать. Обычно таких значений бывает множество.
• Кортеж. Термин «кортеж» обозначает набор атрибутов, описывающих конкретный объект или сущность. Как правило, кортеж ассоциируется с строкой в таблице данных.
• Отношение. Представляет собой готовую таблицу, то есть, набор уже сформированных кортежей.
• Схема отношения. Описывает структуру таблицы и включает в себя набор определенных полей.
• Проекция. Представляет собой таблицу, полученную путем перестановки некоторых атрибутов.
• Нормальная форма (НФ). Это требование к структуре таблицы в теории баз данных.   Метод НФ включает в себя процесс сбора и максимально эффективного использования информации об объектах в пределах одного конкретного отношения, а затем разбиение этого отношения.
• Аномалия. Это ситуация в таблице, которая может привести к противоречиям в базе данных и значительно усложнить ее обработку. Существуют аномалии модификации, удаления и добавления.

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

Что такое транзитивная зависимость

Транзитивной зависимостью (ТЗ) в БД обычно называют косвенную связь между атрибутами в одном отношении (таблице), которая в свою очередь вызывает функциональную зависимость. Практически во всех известных ситуациях, ТЗ состоит из 3 атрибутов минимум (столбцов с данными), которые в то же время являются функционально зависимыми.
Основным отличием транзитивной зависимости от функциональной является то, что первая возникает только в том случае, если косвенная связь вызывает функциональную зависимость. Иными словами, ТЗ не может существовать без ФЗ и полностью зависит от неё. Эту информацию необходимо знать для проведения успешной нормализации.

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

Теперь стоит рассмотреть нормальные формы, которые применяются при проектировании любой базы данных. Знание основных форм не позволит совершить ошибку в процессе нормализации БД. Эти формы являются составляющими общей реляционной модели данных.

1НФ

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

Здесь можно наблюдать нарушение в строке о BMW – перечислено сразу несколько моделей, чего делать категорически нельзя, ведь получается отсутствие атомарности. Если преобразовать таблицу в соответствии с требованиями 1НФ, то она примет такой вид:

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

2НФ

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

По своей структуре эта таблица соответствует первой нормальной форме, но возникают трудности с второй нормальной формой. Стоимость автомобиля зависит как от производителя, так и от модели, в то время как предоставляемая скидка зависит только от производителя. Здесь присутствует частичная зависимость от первичного ключа. Чтобы это исправить, необходимо разделить данные на две отдельные таблицы, учитывая оба направления зависимости (то есть, создать две отдельные правильные таблицы).

Таблица 1:

Таблица 2:

Теперь отношения полностью соответствуют 2НФ, поскольку неключевые атрибуты полностью зависят от первичного ключа. 

3НФ

Третья нормальная форма предполагает, что вся таблица должна находиться в 2НФ, но любой неключевой столбец при этом обязательно должен зависеть только от первичного ключа. Ниже будет представлена таблица, в которой атрибут с первичным ключом слово «Модель», а атрибут «Телефон» от ключа никак не зависит – отсюда ошибка.

В этой таблице имеются следующие зависимости: «Модель-Магазин», «Магазин-Телефон», «Модель-Телефон». Зависимость «Модель-Телефон» является неверной и потому отношение не соответствует 3НФ. Для исправления ситуации нужно разделить таблицу на две отдельные, выставив корректные зависимости. Выглядеть это будет так.

Таблица 1:

Таблица 2:

Эти две таблицы полностью соответствуют 3НФ, а это значит, что очередной этап нормализации прошёл успешно.   

НФБК

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

Причём стоит учитывать, что каждый тариф уникален и зависит от выбранной стоянки и наличия льгот. В итоге наблюдаются составные первичные ключи (например, «Номер стоянки-Окончание»). Однако таблица полностью соответствует 3НФ. Условия 2НФ также полностью выполнены, поскольку все атрибуты входят в какой-либо из потенциальных ключей. 

Но существует функциональная зависимость «Тариф-Номер стоянки», в которой левая часть не является ключом отношения. Поэтому и нет соответствия НФБК. К тому же, благодаря подобной структуре, можно по ошибке тариф «Эконом» можно приписать ко второй стоянке, которая не предназначена для льготников. Поэтому лучше декомпозировать отношение на два и добавить атрибут.

Таблица 1. Тарифы:

Таблица 2. Бронирование:

4НФ

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

Приведем пример с ресторанами. Представим, что есть несколько ресторанов, предлагающих различные виды суши, и их службы доставки работают только в определенных районах города. Первичным составным ключом в этом случае будет набор из трех атрибутов: ресторан, вид суши, район доставки. Однако эта таблица не соответствует четвёртой нормальной форме из-за многозначной зависимости «ресторан-вид суши, ресторан-район доставки».

Это означает, что при добавлении нового вида суши придется вносить новые данные для каждого района доставки, что, в свою очередь, может привести к логической аномалии. Аномалия заключается в том, что определенному виду суши будут соответствовать только определенные районы доставки.

Для того чтобы устранить эту аномалию, необходимо провести декомпозицию отношения, разместив независимые факты в различных таблицах. Например, можно использовать схему «ресторан-вид суши» и «ресторан-район доставки». После выполнения данной операции отношение будет соответствовать четвёртой нормальной форме. Однако появится больше таблиц, что в дальнейшем может негативно сказаться на скорости чтения базы данных.

5НФ

Отношение соответствует пятой нормальной форме только в том случае, если оно было создано в 4НФ и при этом в нём отсутствуют сложные зависимые изменения между атрибутами. Это достаточно жёсткое требование, которое получается выполнить только при наличии дополнительных условий.

5НФ изначально предназначена для работы с зависимыми соединениями. Тем не менее, на практике такие соединения встречаются крайне редко. Более того, привести отношение в 5НФ, зачастую, просто невозможно. Именно поэтому специалисты в своей практике обычно не используют 5НФ, предпочитая нормализацию по другим формам.

Доменно-ключевая нормальная форма

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

6НФ

Переменная отношения может соответствовать шестой нормальной форме только в том случае, если она удовлетворяет всем нетривиальным зависимостям. Но нужно, чтобы изначально переменная соответствовала 5НФ. На практике добиться полного соответствия 6НФ вообще нереально. Как раз поэтому идея «декомпозиции до конца», некогда ходившая в определённых кругах, была отвергнута специалистами.

Некоторые особенности нормализации

Согласно правилам проведения процедуры нормализации, есть 7 основных НФ. Но в большинстве случаев оптимизировать базы до такого уровня невозможно, поскольку в результате получится большое количество отдельных таблиц с собственными зависимостями. Это может существенно замедлить работу БД и даже вызвать более серьёзные проблемы.

Поэтому компетентные специалисты рекомендуют проводить нормализацию до 3НФ включительно. В этом случае не должно возникнуть никаких проблем. В идеале процесс нормализации нужно прописать ещё на этапе проектирования базы и привести её к соответствию 3НФ. Тогда проблем с наращиванием её объёмов будет гораздо меньше.

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

Некоторые специалисты в области СУБД считают, что полная нормализация слишком вредна для БД, так как негативно влияет на её производительность чтения за счёт появления большого количества таблиц (отношений). Такие профессионалы предлагают время от времени проводить денормализацию БД для того, чтобы, пожертвовав скоростью записи повысить скорость чтения. Ведь по статистике, большинство процедур в БД как раз относятся к чтению.

В результате, денормализация – это намеренное добавление избыточных копий и неудовлетворительных зависимостей в заранее нормализованную базу для повышения скорости чтения. Этот процесс можно проводить только на оптимизированных и нормализованных базах. К тому же, он имеет свои положительные стороны только в том случае, если БД предназначена в основном для чтения.

Выводы

Итак, процедура нормализации БД является необходимой в том случае, если нужно обеспечить базе нормальную работу. Тем не менее, проводить полную нормализацию по всем формам особого смысла не имеет, так как все нормальные формы после третьей крайне тяжело реализовать на практике. К тому же, идеальный порядок вреден для БД, поскольку существенно снижается скорость чтения за счёт появления большого количества таблиц (отношений).

Более того, если основная операция БД – чтение, рекомендуется производить денормализацию. Но только в том случае, если база была предварительно нормализована. Специалисты в области СУБД проводят процедуру нормализации вручную, поэтому она может занять достаточно много времени (специализированного ПО для решения этой задачи нет). Однако после подобной оптимизации (если е выполнял компетентный профессионал) общая производительность БД улучшится.