преобразование в ЗНФ. Чтобы преобразовать информационную модель в третью нормальную форму, нужно просто руководствоваться здравым смыслом, призвать на помощь интуицию и помнить старую пословицу: Все атрибуты сущности должны зависеть от ключа, только от ключа и ни от чего, кроме ключа (и да поможет мне Кодд) *.

Некоторые опытные люди с подготовкой в области нереляционных систем баз данных (например, иерархических и сетевых) смотрят на процесс нормализации с определенной долей скептицизма. Они считают, что мы создаем при этом большое количество таблиц. (Действительно, переходя от рис. 3.11 к рис. 3.13, мы получили вместо одной сущности четыре.) Эти критики также трактуют низкую производительность периода выполнения как результат соединения таблиц с целью перегруппирования данных в первоначальную форму.

С одной точки зрения (но только с одной), они правы: если у нас есть уникальный ключ, по которому можно выбрать отдельную ненормализованную запись, то размещение всех данных в общем котле даст нам самое короткое время выборки. С другой стороны, Oracle? не так уж медленно выполняет соединение четырех таблиц, когда это нужно. Однако даже при этом несколько утрачивается суть: ведь большинство запросов, которые придется написать по нормализованным структурам данных, не будут пытаться полностью восстановить исходную плоскую модель, с которой мы начали на рис. 3.11, и вначале у них не будет столь удобного уникального идентификатора. Многие будут соединять четыре нормализованные таблицы с помощью ключей Origin ( Пункт отправления ) и Departure Date ( Дата убытия ). А такие нерегламентированные запросы исключительно дороги по сравнению с ненормализованными структурами, не говоря уже о всех остальных недостатках, которые мы уже обсудили.

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

Что за третьей портальной формой? Большинство тех, кто имеют дело с реляционными системами, конечно же знают о ЗНФ. Однако, дойдя до третьей нормальной формы, не обязательно нужно остановиться на достигнутом. За третьей нормальной формой следуют:

нормальная форма Бойса-Кодда (НФБК);

четвертная нормальная форма (4НФ);

пятая нормальная форма (5НФ).

Здесь мы лишь кратко опишем эти формы, а более подробную информацию вы можете почерпнуть из прекрасной книги Криса Дейта.**

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

Ссылка на д-ра Е Кодда, отца реляционной базы данных

Date, а , An InlroducUon to Database Systems, 6-e издание, Addison-Wesley, 1995

какие проблемы эти формы решают. Эти проблемы - неизбежный результат применения составных первичных ключей, в которых лишь часть ключа сама J по себе содержит информацию. Любая структура, находящаяся в ЗНФ и не имеющая составных ключей, должна также находиться в 5НФ.

Нормальная форма Бойса-Кодда (НФБК). НФБК устанавливает дополни-1 тельное правило: все транзитивные зависимости должны быть удалены. Таблица R находится в нормальной форме Бойса-Кодда, если для каждой нетривиальной ФЗ X А X - суперключ. Что это означает на практике?

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

Таблица 3.1. Распределение экипажа: таблица в ЗНФ, противоречащая НФБК

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

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

Таблица 3.2 Руководители групп: новая таблица, введенная для обеспечения (оответствия НФБК

Теперь, если Уэллса сбросят в море, мы все равно узнаем, что Реймуол руководит группой наблюдения (несмотря на то, что число членов данной группы будет равно нулю). Нового члена группы теперь можно назначить в подчинение Реймуолу.

Четвертая нормальная форма (4НФ). Эта форма оперирует многозначными зависимостями (МЗЗ). Она решает проблему, вызванную наличием в таблице более одной МЗЗ. Давайте рассмотрим таблицу, содержащую сведения о кораблях, совершаемых ими рейсах и капитанах, которые управляют кораблями в этих рейсах. В качестве иллюстрации послужит ER-диаграмма, показанная на рис. 3.14.

Рис. 3.14 Пример, иллюстрирующий нарушение 4НФ

Что здесь неправильно? В сущности Voyage ( Рейс ) регистрируется слишком много подробностей. Полученная из нее таблица показана ниже (табл. 3.3). Здесь нет ФЗ, поэтому она соответствует НФБК. Тем не менее, аномалия удаления сохранилась. Если Эйрен уволиться и мы уничтожим записи о нем, то потеряем все сведения о том, что корабль Флейта плавает Между Брюгге и Бостоном. Более того, если удалить новый рейс, то может Понадобиться ввести в табл. 3.3 не одну, а несколько строк.