Главная » SQL, Базы данных » Дальнейшая нормализация: формы 1НФ, 2НФ, 3НФ и НФБК

0

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

S { S#, SNAME, STATUS, CITY } PRIMARY KEY { S# }

P { P#, PNAME, COLOR,

WEIGHT, CITY } PRIMARY KEY

{ P# }

SP { S#, P#, QTY }

PRIMARY KEY { S#, P# }

FOREIGN KEY { S# } REFERENCES S

FOREIGN KEY { P# } REFERENCES P

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

На первый взгляд этот проект базы кажется вполне приемлемым. И действительно, в нем предусмотрены три переменные отношения (s, P и SP), необходимые для представления всей рассматриваемых данных, а в переменные отношения включены подходящие атрибуты. В частности, кажется "вполне очевидным", что атрибут CITY для города поставщика должен быть определен в переменной отношения S, атрибут COLOR для цвета детали — в переменной отношения Р, атрибут QTY для количества деталей — в переменной отношения SP и т.д. Но на чем основана такая уверенность? Причины, которыми обусловлен выбор именно такого проекта базы данных, можно понять, изменив его определенным образом. Предположим, например, что атрибут CITY удален из переменной отношения поставщиков S и добавлен в переменную отношения поставок SP. (Однако интуитивно это действие воспринимается как ошибочное, поскольку понятие "город

поставщика" очевидным образом связано с поставщиками, а не с  поставками.) На рис. 12.1 представлен пример содержимого переменной отношения поставок, измененной подобным образом (исходный вариант приведен на рис. 11.1 в главе 11).

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

На  рис.  12.1  можно  легко  заметить  существенный  недостаток  этого  проекта  — избыточность.   А   именно,   в   каждом   кортеже   переменной   отношения   SCP   для поставщика с номером S1 содержится информация о том, что этот поставщик находится в Лондоне; в каждом кортеже переменной отношения SCP для поставщика с номером S2 приведены данные о том, что  этот  поставщик находится в Париже, и т.д. Иначе говоря, сведения о городе, в котором находится конкретный поставщик, повторяются в отношении   столько   раз,   сколько   поставок   выполняет   данный   поставщик.   Эта избыточность, в  свою очередь, приводит к некоторым другим проблемам. Например, после  обновления данных1  о местонахождении поставщика с номером S1 в одном из кортежей может быть указан Лондон, а в другом — Амстердам. Таким  образом,  для создания  хорошего  проекта  следует  придерживаться  принципа  "по  одному  факту  в одном   месте"   (т.е.   избегать   избыточности   данных).   Предметом   нормализации,   в сущности, становится всего лишь формализация  подобных простых идей, однако это должна быть формализация, которая действительно будет иметь большое практическое

значение при проектировании базы данных.

Конечно, как уже упоминалось в главе 6, сами отношения в реляционной модели всегда нормализованы.   Можно   сказать,  что   переменная  отношения   также   нормализована, поскольку   ее   допустимыми   значениями   являются    нормализованные   отношения. Следовательно, в

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

контексте  реляционной  модели  переменная  отношения  также  всегда  нормализована. Аналогично можно сказать, что переменные отношения (и значения отношения) всегда находятся в первой нормальной форме, или 1НФ.  Иначе говоря, понятия "нормализованная переменная отношения" и "переменная отношения в 1НФ" означают в точности одно и то же, хотя следует иметь в виду, что понятие "нормализованная переменная отношения" может также относиться к нормализации более высоких уровней (обычно это выражение служит для обозначения третьей нормальной формы, или ЗНФ). Последний вариант  использования этого термина не совсем точен, но достаточно широко распространен.

Рис. 12.1. Пример значений данных в переменной отношения SCP

Однако некоторая переменная отношения может быть нормализованной в указанном смысле и все еще обладать определенными нежелательными свойствами. Примером может служить переменная отношения SCP, показанная на рис. 12.1. Принципы дальнейшей нормализации позволяют распознать подобные случаи и привести такие переменные отношения к более приемлемой  форме. В случае переменной отношения SCP эти принципы позволили бы точно установить ее недостатки и указать на необходимость ее разбиения на две "более приемлемые" переменные отношения: одну с атрибутами S# и CITY, а другую с атрибутами s#, P# и QTY.

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

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

На рис. 12.2 показано несколько нормальных форм, которые определены к  настоящему времени. Первые три (1НФ, 2НФ и ЗНФ) были описаны Коддом (Codd) [11.6]. Как видно из рис. 12.2, все нормализованные переменные отношения находятся в 1НФ, некоторые переменные отношения в 1НФ также находятся в 2НФ, и некоторые переменные отношения в 2НФ также находятся в ЗНФ.  Мотивом, которым руководствовался Кодд при введении дополнительных определений, было то, что вторая нормальная форма "более желательна" (в смысле, который будет разъяснен ниже), чем первая, а третья, в

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

Рис. 12.2. Уровни нормализации

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

Возвращаясь к рассмотрению собственно нормальных форм, заметим, что, как будет показано в разделе 12.5, оригинальное определение Кодда для ЗНФ [11.6] приводит к некоторой неадекватности. Переработанное и более точное определение, приведенное Бойсом (Воусе) и Коддом в [12.2], является более строгим в том смысле, что любая переменная отношения в ЗНФ по новому определению является таковой и по старому определению, но не всякая переменная отношения в ЗНФ по старому определению может являться таковой по новому определению. Для того чтобы эти определения можно было различать, переменную отношения в ЗНФ по новому определению обычно называют нормальной формой Бойса-Кодда — НФБК.

Впоследствии Фейгином (Fagin) в [12.8] была определена новая, четвертая нормальная форма (4НФ), которая стала четвертой по счету, поскольку в момент  ее создания нормальная форма Бойса-Кодда считалась третьей. Затем в [12.9] Фейгин дал определение еще одной нормальной формы, которую назвал проекционно-соединительной нормальной

Глава 12. Дальнейшая нормализация: формы 1НФ, 2НФ, ЗНФ и НФБК     461

формой (ПСНФ); ее называют также петой нормальной формой или 5НФ. Как показано на рис. 12.2, некоторые переменные отношения в НФБК находятся также в 4НФ, а некоторые переменные отношения в 4НФ находятся также в 5НФ.

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

Структура главы

Назначение данной главы — предоставить описание концепции дальнейшей нормализации до уровня нормальной формы Бойса— Кодда включительно. Оставшиеся формы будут рассмотрены в главе 13. В целом, материал будет излагаться по следующему плану. После этого несколько затянувшегося введения  в разделе 12.2 описывается фундаментальная концепция декомпозиции без потерь и демонстрируется важное значение понятия функциональной зависимости (ФЗ) в этой концепции. (Действительно, понятие функциональной зависимости является основой выделения трех нормальных форм Кодда и нормальной формы  Бойса-Кодца.) Далее, в разделе 12.3, подробно рассматриваются три начальные нормальные формы и на примере некоторой переменной отношения демонстрируется, как выполняется нормализация вплоть до достижения ЗНФ. В разделе 12.4 будет сделано небольшое отступление в целях обсуждения вопроса альтернативных декомпозиций, т.е. проблемы выбора "наилучшей декомпозиции" для конкретной переменной отношения, если, конечно, такой выбор возможен.  В разделе 12.5 обсуждается НФБК, а в разделе 12.6 рассматриваются особенности работы с атрибутами, принимающими отношения в качестве значений. Наконец, в разделе 12.7 приводится краткое резюме и дается несколько заключительных замечаний.

Важно отметить, что далее изложение ведется не столь строго, как раньше, и в своих рассуждениях автор в основном полагается на интуитивное понимание. Подобный подход  может  быть  оправдан  тем,  что  такие  понятия,  как  "декомпозиция  без  потерь", "нормальная форма Бойса—Кодда" и другие, несмотря на их таинственные и загадочные названия, по сути весьма просты и общедоступны. Во многих работах, на которые даны ссылки в настоящей книге, этот материал излагается в более строгой форме. Хороший учебник можно найти в [12.5].

Кроме того, следует сделать еще два предварительных замечания.

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии