Глава 1 1

Дальнейшая нормализация: формы ШФ, 2НФ, ЗНФ и НФБК

11.1. Введение

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

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

P {Pi, PNAME, COLOR, WEIGHT, CITY } PRIMARY KEY { Pi }

SP { Si, Pi, QTY }

PRIMARY KEY { Si, Pi }

FOREIGN KEY { Si } REFERENCES S

FOREIGN KEY { Pi } REFERENCES P

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

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

На рис. 11.1 легко заметить один недостаток, свойственный организации переменной-отношения SCP, а именно — ее избыточность. Говоря конкретнее, в каждом кортеже пере­менной-отношения SCP для поставщика с номером 'S1' содержится информация о том, что этот поставщик находится в Лондоне; в каждом кортеже переменной-отношения SCP для по-

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

s#	CITY	P#	QTY
SI	London	PI	300
SI	London	P2	200
SI	London	P3	400
SI	London	P4	200
SI	London	P5	100
SI	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

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

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

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

Однако некоторая переменная-отношение может быть нормализованной в указанном смысле и все еще обладать определенными нежелательными свойствами. Примером мо­жет служить переменная-отношение SCP, показанная на рис. 1.1. Принципы дальнейшей нормализации позволяют распознать подобные случаи и привести такие переменные-отношения к более приемлемой форме. В случае переменной-отношения SCP эти прин­ципы позволили бы точно установить ее недостатки и указать на необходимость ее раз­биения на две "более приемлемые" переменные-отношения: одну с заголовком {Si, CITY} и другую с заголовком {Si, Pi, QTY}.

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

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

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

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