Если Вы уже начали работать с базами данных, то рано или поздно Вы столкнётесь с таким термином как нормализация. Возможно кто-то спросит о проекте «нормализована ли эта база?». И ответом будет «О, конечно.». Зачастую нормализацию воспринимают как лишнее излишество, выдуманное университетскими умниками и страшно далеко оторванной от практики. В любом случае понимание принципов нормализации и применение их в повседневной практике разработки проекта базы данных позволяет радикально поднять все её технические характеристики. Кроме того, грамотная нормализация существенно уменьшит лично вашу головную боль, как разработчика базы данных.

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

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

Сообщество разработчиков баз данных выдвинуло определённые руководящие принципы обеспечивающие определение степени нормализации базы данных. Они описываются нормальными формами и пронумерованы от 1 (самая низкая форма нормализации) до 5. В практическом программировании чаще всего встречается 1NF, 2NF, и 3NF, иногда встречается 4NF, крайне редко 5NF. 4NF и 5NF мы не будем рассматривать в данной статье.

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

Мы начинаем наш обзор первого из трех основных принципов нормализации, известной как первая нормальная форма (1NF).

1NF требует атомарности данных в таблицах, т.е. данные в таблицах должны быть представлены в виде минимально возможных и далее неделимых кусочков информации. А как на практике применять это правило? На самом деле все это очень просто.

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

Изначально мы, скорее всего, разместили бы эту информацию следующим образом:

Ну что же, давайте выполнять требования 1NF об атомарности данных, и создавать соответствующую нормализованную таблицу. Тогда мы получаем что-то типа этого:

Теперь наша таблица в первой нормальной форме! Но удобно ли с ней работать?

Итак, мы сделали первый шаг в приведении нашей базы в нормализованое состояние - привели к 1NF. Сейчас же мы продолжим рассмотрение принципов второй нормальной формы.

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

Поняли? Ну ничего, это проще, чем написано в определении. Мы должны убрать повторяющиеся данные из нашей таблицы в отдельные таблицы и установить связь между этими таблицами. Все просто.

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

Давайте посмотрим, что мы получили. Первое, что бросается в глаза - разное написание покупателя ООО "Пупкин". Это явление постоянно встречается в плохо нормализованых базах данных и носит название "аномалии ввода" - в одном месте вводят одно, в другом другое. Если вы надеетесь, что оператор базы данных не сможет ввести в базу слово из четырех букв пятью разными способами, то вы наивный человек. Кроме аномалий ввода существуют еще, как вы понимаете, аномалии удаления и обновления.

Теперь давайте поговорим о связях между нашими таблицами. Если с таблицами "Покупатели" и "Авторы" все ясно, то с таблицей "Книги" есть вопрос. Этот вопрос - поле ISBN. По идее, оно уникально и однозначно определяет книгу, но в реальности отмечены случаи дублирования этого номера для разных книг. В теории баз данных этот вопрос, частным случаем которого является применение ISBN в качестве первичного ключа таблицы, называется проблемой применения естественных или синтетических ключей. Зачастую обсуждения этого вопроса носят характер религиозного холивара.

Но вернемся к нашим таблицам. После того, как мы определили первичные ключи для таблиц, они приобрели такой вид:

Обратите внимание, что в таблице "Книги" мы определили еще и внешний ключ (AutorID) для связи с таблицей "Авторы". Рассуждая аналогичным образом в отношении таблицы продаж, получим такую вот структуру:

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

Третья нормальная форма, известная также как 3NF, требует от нас, чтобы структура базы данных

Обратимся к нашему примеру. Мы видим, что в таблице OrdersDetail поле Сумма зависит от поля Колво. Аналогичное расчетное поле - Итого таблицы Orders. Убираем их. Наша таблица продаж теперь выглядит следующим образом:

Вот теперь наши таблицы находятся в 3 нормальной форме.

Второе название процесса нормализации - "формальное проектирование базы данных". Ключевым словом в этом определении является слово "формальное". Проводя нормализацию, мы добиваемся сокращения (а в идеале - полного отсутствия) избыточности информации, что уменьшает вероятность появления аномалий ввода, обновления и удаления, облегчает администрирование базы и уменьшает ее размер. С другой стороны нормализация усложняет ввод-вывод информации в базу - приходится создавать сложные запросы, которые, к тому же, могут отрабатывать довольно медленно. Еще одной из причин проведения выборочной денормализации могут быть принятые в организации бизнес-процессы. Это как раз наш случай.

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

Первый вариант усложнит и замедлит вывод данных о суммах продаж, поэтому мы пойдем по второму пути и вернем обратно поля Сумма и Итого. Наша итоговая структура базы данных теперь выглядит так: