Программирование >>  Хронологические базы данных 

1 ... 128 129 130 [ 131 ] 132 133 134 ... 348


Глава

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

11.1. Введение

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

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

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

SP { SI, PI, QTY }

PRIMARY KEY { S, Pi }

FOREIGN KEY { SI } REFERENCES S

FOREIGN KEY { P } 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 в одном из кортежей может быть указан Лондон, а в другом - Амстердаме Таким образом, для создания хорошего макета следует придерживаться принципа по одному факту в одном месте (т.е. следует избегать избыточности данных). Предметом нормализации, в сущности, является всего лишь формачшация подобных простых идей, однако это должна быть формализация, которая действительно будет иметь большое практическое значение при проектировании базы данных.

CITY

London

London

London

London

London

London

Paris

Paris

Paris

London

London

London

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

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

Далее в этой и последующих главах нужно сделать (достаточно правдоподобное!) предположение о том, что контроль предикатов переменных-отношений поддерживается не в полном объеме. Это необходимо, поскольку в противном случае описанные выше проблемы просто не могли бы возникнуть (было бы невозможно обновить данные о городе поставщика с номером 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НФ

Переменные-отношения в ЗНФ

Переменные-отношения в НФБК

Переменные-отношения в 4НФ

Переменные-отношения в5Нф

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

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



1 ... 128 129 130 [ 131 ] 132 133 134 ... 348

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика