0. в качестве начального значения для декомпозиции D зададим пустое множество.

1. Пусть множество I является неприводимым покрытием для множества функциональных зависимостей S.

2. Пусть X является множеством атрибутов в левой части некоторой зависимости X -> Y, входящей в множество I.

3. Пусть полное множество ФЗ в I с левой частью, равной множеству атрибутов X, состоит из зависимостей X Yl, X Y2,X Yn.

4. Пусть Z является объединением множеств атрибутов Y1, Y2,Yn.

5. Заменим декомпозицию D объединением текущего значения D с проекцией переменной-отношения R по атрибутам X и Z.

6. Повторим пп. 3-5 для каждого атрибута из множества X.

7. Пусть Al, А2,An являются неучтенными до сих пор атрибутами переменной-отношения R (т.е. такими, которые еще не включены в какую-либо из переменных-отношений в множестве D). Заменим декомпозицию D объединением текущего значения D с проекцией переменной-отношения R по атрибутам А1, А2, An.

8. Если ни одна из переменных-отношений в декомпозиции D не содержит потенциального ключа R, заменим декомпозицию D объединением текущего значения D с проекцией переменной-отношения R по ее некоторому потенциальному ключу.

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

0. Зададим в качестве начального значения для декомпозиции D переменную-отношение R.

1. Для каждой переменной-отношения Т (которая не находится в НФБК) из состава декомпозиции D выполним действия, перечисленные в пп. 2 и 3.

2. Пусть X -> Y является функциональной зависимостью в переменной-отношении Т, в которой нарушаются некоторые требования НФБК.

3. Заменим переменную-отношение Т в декомпозиции D двумя проекциями, а именно: одной по атрибутам X и Y, а другой - по всем атрибутам, за исключением Y.

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

11.4. На рис. 11.21 показаны наиболее важные функциональные зависимости, а соответствующие семантические допущения приведены ниже.

Никакие два клиента не имеют одинаковых адресов доставки.

Каждый заказ имеет уникальный номер.

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

ADDRESS

CUST#

QTYORD

QTYOUT

ORD#

LINE#

DESCN

DATE

CREDLIM DISCOUNT

ITEM#

PLANT#

QTYOH

DANGER

Puc. 11.21. Диаграмма зависимостей для упр. 11.4

Соответствующий набор переменных-отнощений в НФБК будет выглядеть приблизительно так.

CUST { CUST#, BAL, CREDLIM, DISCOUNT } PRIMARY KEY { CUST# }

SHIPTO { ADDRESS, CUSTI }

PRIMARY KEY ( ADDRESS )

ORDHEAD { ORDI, ADDRESS, DATE } PRIMARY KEY { ORDt }

ORDLINE { ORDt, LINEt, ITEMt, QTYORD, QTYOUT } PRIMARY KEY { ORDt, LINEt }

ITEM { ITEMI, DESCN }

PRIMARY KEY { ITEMt }

IP { ITEMI, PLANTI, QTYOH, DANGER } PRIMARY KEY { ITEMt, PLANTi }

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

RETRIEVE CUST WHERE CUSTl = input.CUSTi ;

<проверка остатка на счету, установленного размера кредита и т.д.> ;

RETRIEVE SHIPTO WHERE ADDRESS = input.ADDRESS ;

AND CUSTI = input.CUSTI

/* проверка адреса доставки */ ;

IF <все в порядке>, THEN <продолжить обработку заказов> ; END IF;

Если 99% клиентов имеют только один адрес доставки, было бы весьма неэффективно помещать адрес в какую-либо другую переменную-отношение, кроме CUST (если рассматривать только эти 99%, то ADDRESS функционально зависит от CUSTI). Исправить ситуацию можно следующим образом. Для каждого клиента укажем один адрес доставки в качестве первичного адреса, который для 99% клиентов будет единственным. Любые другие адреса будут рассматриваться как вторичные. Тогда переменную-отношение CUST можно переопределить следующим образом.

CUST { CUSTI, ADDRESS, BAL, CREDLIM, DISCOUNT } KEY { CUSTI }

A переменную-отношение SHIPTO можно заменить такой переменной-отношением.

SECOND { ADDRESS, CUSTI } KEY { ADDRESS }

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

RETRIEVE CUST WHERE CUSTI = input.CUSTi ;

<проверка остатка на счету, установленного размера кредита и т.д.> ; IF CUST.ADDRESS Ф input.ADDRESS THEN

RETRIEVE SECOND WHERE ADDRESS = input.ADDRESS ; AND CUSTI = input.CUSTI /* проверка адреса доставки */ ; END IF;

IF <Bce в порядке>, THEN <продолжить обработку заказов> ; END IF; Ниже перечислены некоторые преимущества такого подхода.

Для 99% клиентов обработка заказов становится проще и эффективнее.

Если в поступающем заказе опущен адрес доставки, то по умолчанию будет использован первичный адрес.

Предположим, что клиент имеет различные скидки для разных адресов доставки. При первом подходе (показанном в виде ответа к предыдущему упражнению) атрибут DISCOUNT должен быть помещен в переменную-отношение SHIPTO, что приводит к значительному усложнению обработки заказов. Однако при усовершенствованном подходе первичная скидка (соответствующая первичному адресу) может быть представлена посредством введения атрибута DISCOUNT в переменную-отношение CUST, а вторичная скидка- путем введения атрибута DISCOUNT в переменную-отношение SECOND. При этом обе переменные-отношения все еще остаются в НФБК, а обработка заказов упрощается для 99% клиентов.