Глава 10 Дальнейшая нормализация:

1Нф, 2нф, 3нф, нфбк

10.1. Введение

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

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, Р и SP, для которых заданы некоторые атрибуты, например: для товара — атрибут COLOR (цвет) в отношении Р, для города поставщика CITY (город) в отношении S, для количества товаров — QTY (количество) в отношении SP и т.д. Но откуда это известно? Некоторый намек на ответ можно получить, изменяя определенным образом макет базы данных. Предположим, например, что атрибут CITY удален из отношения поставщиков S и добавлен к отношению поставок SP (хотя интуитивно это действие можно охарактеризовать как ошибочное, так как понятие “город поставщика" очевидным образом связано с поставщиками, а не с поставками). На рис. 10.1 показана таблица с образцами записей для такого измененного отношения поставок. (Чтобы избежать путаницы с обычным исходным отношением SP, измененное отношение будет далее обозначаться SCP, как и в главе 9.)

SCP
	s#	CITY	P#	QTY
	Sl	London	PI	300
	Sl	London	P2	200
	Sl	London	P3	400
	Sl	London	P4	200
	Sl	London	P5	100
	Sl	London	P6	100
	S2	Paris	PI	300
	S2	Paris	P2	400
	S3	Paris	P2	200
	S4	London	P2	200
	S4	London	P4	300
	S4	London	P5	400

Рис. 10.1. Таблица отношения SCP

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

Конечно, отношения в реляционной базе данных всегда нормализованы в том смысле, что содержат только "скалярные" значения. (Определение понятия "скаляр­ный" в этом смысле будет дано в последующих главах книги.) На рис. 4.5 в главе 4 показан пример приведения ненормализованного отношения к эквивалентной норма­лизованной форме. Однако некоторое отношение может быть нормализовано в этом смысле и все еще обладать некоторыми нежелательными свойствами, например от­ношение SCP, показанное на рис. 10.1. Принципы дальнейшей нормализации позво­ляют распознать подобные случаи и свести такие отношения к более приемлемой форме. В примере с отношением SCP эти принципы позволили бы найти недостатки отношения и указать на необходимость его разбиения на два "более приемлемых" от­ношения: одно с атрибутами {S#, CITY}, а другое с атрибутами {S#, P#, QTY}.

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

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

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

Пространство отношений ( нормализованных и ненормализованных)

Отношения в 1НФ( нормализованные отношения )

Отношения в 2 НФ

Отношения в 3НФ

Отношения в НФБК

Отношения в 4НФ

Отношения в 5НФ

Рис. 10.2. Нормальные формы

На рис. 10.2 показано несколько нормальных форм, которые определены к на­стоящему времени. Первые три (1НФ, 2НФ, ЗНФ) были определены Коддом (Codd) [9.4]. Как показано на рис. 10.2, все нормализованные отношения находятся в 1НФ, некоторые отношения 1Нф находятся также в 2НФ и некоторые отношения 2НФ находятся также в 3НФ. Мотивом для введения дополнительных определений было то, что вторая нормальная форма «более желательна» (в смысле, который будет разъяснен позже), чем первая, а третья, в свою очередь, «более желательна», чем вторая. Таким образом, при проектировании базы данных вообще следует использовать отношения не только в первой или во второй, но также и в третьей форме.

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

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

Впоследствии Фейгином (Fagin) в [11.8] была определена новая, четвертая нормальная форма (4НФ), которая стала четвертой по счету, поскольку в момент ее создания нормальная форма Бойса-Кодда считалась третьей. Совсем недавно Фейгин в [11.9] дал определение еще одной нормальной формы, которую он назвал проективно-соединительной нормальной формой, она также называется пятой нормальной формой, или 5НФ. Как показано на рис. 10.2, некоторые отношения в НФБК также находятся в 4НФ, а некоторые отношения в 4НФ также находятся в 5НФ.

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

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

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

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

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

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

2. Как упоминалось выше, процедура нормализации будет использована в качестве ос­новы при описании различных нормальных форм. Однако это не значит, что на практике создание макета базы данных будет выполняться с помощью этой проце­дуры. На самом деле, скорее всего, для этого будет использована описанная в главе 12 схема типа "сверху вниз". Затем идеи нормализации можно использовать для проверки того, чтобы полученный в результате макет непроизвольно не нарушал никаких принципов нормализации. Тем не менее, процедура нормализации является удобным способом представления этих принципов. Для упрощения изложения в данной главе будет сделано полезное допущение о том, что проектирование выпол­няется с помощью процедуры нормализации.