В этом техническом описании мы расскажем, что такое моделированием данных, почему оно имеет такое значение, и какие концепции и методы лежат в основе моделирования данных.
ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА (3НФ)
Третья нормальная форма - это нормальная форма, в которой большинство моделей данных и баз данных уже являются нормализованными. Третья нормальная форма требует, чтобы модель данных соответствовала форме 2НФ, и добавляет требование отсутствия транзитивных зависимостей. Транзитивная зависимость имеет место в том случае, если неключевой атрибут некоторой сущности зависит от другого неключевого атрибута, который, в свою очередь, зависит от первичного ключа в этой же сущности. То есть, если существует атрибут, который зависит от другого атрибута, не являющегося часть первичного ключа, то этот атрибут имеет транзитивную зависимость.
Как и для первой и второй нормальной форм, обычный метод разрешения проблемы - это создание новой сущности, содержащей неправильные атрибуты. В примере с исполнителями, записывающими альбомы, создание новой сущности для информации о складе позволит нам перенести всю специфическую для склада информацию в эту новую сущность. Однако у нас все еще есть информация о поставщике. Знание наименования компании-поставщика, которая продает изделия, существенно в логическом отношении, но не помогает нам эффективно хранить информацию о поставщике. В данном случае наименование поставщика зависит от идентификатора поставщика, который не является ключевым атрибутом. Итак, чтобы разрешить проблему, мы создаем сущность Поставщик и переносим всю информацию о поставщике в эту сущность (оставив ИдентификаторПоставщика в сущности Изделия для создания отношения между этими двумя сущностями).
Обычно при нормализации базы данных до второй нормальной формы вы подсознательно почти доводите ее до третьей нормальной формы, потому что вы создаете сущности и храните в каждой сущности только присущие ей атрибуты. Затем, при создании отношений, вы добавляете только те атрибуты, которые связаны с другими сущностями, и не добавляете атрибуты, принадлежащие только к родительским сущностям. Несмотря на это, обязательно проверьте модель на отсутствие транзитивных зависимостей, чтобы гарантировать отсутствие проблем с обновлением в физической базе данных.
НОРМАЛЬНАЯ ФОРМА БОЙСА-КОДДА (БКНФ)
Нормальная форма Бойса-Кодда - это форма, разработанная для того, чтобы справиться с проблемой, которая может возникнуть в моделях данных, нормализованных до третьей нормальной формы. В принципе, 3НФ на самом деле никогда не требовала, чтобы сущность не содержала более одного потенциального первичного ключа (простого или составного). Довольно очевидно, что каждую сущность, имеющую более одного первичного ключа, следовало бы разбить на несколько сущностей. БКНФ формально документирует это положение в качестве правила.
ОСТАЛЬНЫЕ НОРМАЛЬНЫЕ ФОРМЫ
Официально существует как минимум еще две нормальных формы: 4НФ и 5НФ. Четвертая нормальная форма утверждает, что первичный ключ не может иметь многозначную зависимость. Многозначная зависимость имеет место в том случае, если некоторый атрибут в составном первичном ключе связан с несколькими значениями в другом атрибуте в первичном ключе. Как и для большинства нормальных форм, для исправления ситуации необходимо создать новую сущность. Пятая нормальная форма определяет требования именно к отношениям между тремя или более сущностями, которые часто называют тернарными отношениями. Пятая нормальная форма требует, чтобы сущности, для которых определены отношения, можно было рассматривать как отдельные сущности, не зависящие от других отношений. Однако из-за связи сущностей друг с другом пятая нормальная форма обычно требует наличия некоей физической сущности, которая выполняла бы функции разрешающей сущности для связи других сущностей между собой. Эта дополнительная сущность должна иметь три или более внешних ключей - по числу сущностей в отношении - определяющих, как эти сущности связаны между собой. Именно так на практике реализуются отношения "многие ко многим". Таким образом, если отношение "многие ко многим" реализовано должным образом, то база данных соответствует пятой нормальной форме.
Разрабатываются и другие нормальные формы, в частности, для пространственных и временных баз данных. Однако разработка этих форм не закончена, в них возможны изменения, поэтому здесь такие формы не рассматриваются. Для большинства реляционных моделей данных и соответствующих баз данных описанные нормальные формы обеспечивают создание стабильного, работоспособного решения.
ДЕНОРМАЛИЗАЦИЯ
Хотя нормализованная по всем правилам база данных обеспечивает высокую производительность и гибкость для оперативных транзакционных баз данных (OLTP), обслуживающих, например, системы обработки заказов, существует ряд ситуаций, в которых может возникнуть необходимость в денормализации сущностей/таблиц по соображениям производительности. В частности, для генерации отчетов и складских ситуаций выполнение запросов требует соединений огромных объемов данных и выполнения агрегирования этих данных. Выполнение этих видов запросов к нормализованной (по четвертой или пятой нормальной форме) базе данных приведет к необходимости соединения огромного количества таблиц, что повысит издержки и вызовет снижение производительности. Чтобы можно было удовлетворить такие запросы, возможно, окажется необходимым создать таблицы, содержащие несколько сущностей, обладающих атрибутами, которые имеют слабосвязанные логические отношения между собой. Обычно создается отдельная база данных, содержащая денормализованные версии таблиц, и процесс загрузки данных для перемещения данных из нормализованной базы данных в денормализованную базу данных для целей генерации отчета и ситуаций на складе. Поэтому не бойтесь денормализации, просто имейте в виду, что следует создать отдельные объекты для удовлетворения этих требования; если вы денормализуете объекты, которые используются системой OLTP, то это будет ударом по производительности.
ЗАКЛЮЧЕНИЕ
Моделирование данных - ключ к успешному проектированию любой базы данных. Сбор требований и проектирование модели данных до каких-либо реальных действий по разработке может помочь в создании более четких определений данных для базы данных и для кода приложения, что повысит эффективность разработки и уменьшит количество несогласованностей. Кроме того, правильно нормализованная база данных будет хорошо работать в большинстве баз данных для оперативной обработки транзакций с операциями чтения/записи.
Джош Джонс (Josh Jones) и Eric Johnson (Эрик Джонсон) являются, соответственно, консультантами по операционным системам и системам управления базами данных в компании Consortio Services (www.consortioservices.com). Эрик и Джош являются авторами серии из трех книг, в том числе, готовящейся к публикации книги "Architecting Database Model for SQL Server" (Разработка архитектуры баз данных для SQL Server).