Этапы нормализации отношений реляционной модели данных.

Под нормализацией отношения подразумевается процесс приведения отношения к одной из так называемых нормальных форм (или в дальнейшем НФ). Однако перед рассмотрением НФ следует сказать несколько слов, зачем нужна нормализация.

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

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

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

С этими требованиями трудно не согласиться, выглядят они вполне разумно. Но еще труднее следовать им на практике, если они сформулированы столь туманно и неопределенно.

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

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

Впрочем, не все обстоит так плохо. Нормализация может не представлять такую уж проблему, если БД проектируется сразу по определенным канонам. Другими словами, можно сначала сделать БД как попало, а потом нормализовать ее, или же с самого начала строить ее по правилам, чтобы в дальнейшем не пришлось переделывать. Сейчас мы пойдем первым путем, т.е. возьмем в качестве примеров никуда не годные БД и попытаемся привести их в порядок. При этом будем иметь в виду, что при профессиональном подходе к проектированию БД используется одна из хорошо проработанных технологий (я предпочитаю IDEF1X), и, возможно, какие-либо инструментальные средства, поддерживающие эту технологию (мой выбор - AllFusion Data Modeler производства Computer Associates).

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

1. 1-я НФ (обычно обозначается также 1НФ).
2. 2НФ.
3. 3НФ.
4. НФ Бойса-Кодда (НФБК).
5. 4НФ.
6. 5НФ.

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