11.2. Это утверждение почти (но не совсем) верно. Приведенный ниже экзотический пример обратной ситуации взят из [5.5], Рассмотрим переменную-отношение USA {COUNTRY,

STATE}, которая интерпретируется как STATE (штат) является членом COUNTRY (страны) , где под страной в каждом кортеже подразумеваются Соединенные Штаты Америки. Тогда в данной переменной-отношении будет вьшолняться приведенная ниже ФЗ.

{ } COUNTRY

А поскольку пустое множество { } не является потенциальным ключом, переменная-отношение USA не находится в НФБК (она может быть декомпозирована без потерь на две унарные проекции, хотя остается спорным утверждение о том, что она может быть подвергнута дальнейшей нормализации).

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

11.3. На рис. 11,20 показаны все наиболее важные функциональные зависимости: как те, которые подразумевались в упражнении, так и те, которые соответствуют разумным семантическим утверждениям (они перечислены ниже). Атрибутам присвоены имена, поясняющие их значения.

Рис. 11.20. Диаграмма зависимостей для упр. 11.3 Семантические утверждения

Ни один сотрудник не является руководителем одновременно нескольких отделов.

Ни один сотрудник не работает одновременно более чем в одном отделе.

Ни один сотрудник не работает одновременно более чем с одним проектом.

Ни один сотрудник не имеет одновременно более одного офиса.

Ни один сотрудник не имеет одновременно более одного телефона.

Ни один сотрудник не имеет одновременно более одного задания.

Ни один проект не выполняется одновременно более чем одним отделом.

Ни один офис не принадлежит одновременно более чем одному отделу. Этап 0. Определение структуры исходной переменной-отношения

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

DEPTO { DEPTt, DBUDGET, MGR EMP#, XEMPO, XPROJO, XOFFICEO } KEY { DEPTi } KEY { MGR EMPi }

Здесь смысл атрибутов DEPTi (номер отдела), DBUDGET (бюджет) и MGR EMP (личный номер руководителя отдела) ясен из их названий, а домены, соответствующие атрибутам ХЕМРО (сотрудник), XPROJO (проект) и XOFFICEO (офис), состоят из значений, представляющих собой отношения, и нуждаются в дополнительных разъяснениях.

Значение атрибута XPROJO в составе каждого кортежа переменной-отношения DEPTO представляет собой отношение с атрибутами PROJi и PBUDGET.

Аналогично значение атрибута XOFFICEO в составе каждого кортежа переменной-отношения DEPTO представляет собой отношение с атрибутами OFFi, AREA и, скажем, XPHONE0, где атрибут XPHONE0, в свою очередь, имеет значения, представляющие собой отношения. Отношения, являющиеся значениями атрибута XPHONE0, имеют только один атрибут PHONEi.

Наконец, значение атрибута ХЕМРО в составе каждого кортежа переменной-отношения DEPTO представляет собой отношение с атрибутами EMPi, PROJi, OFFi, PHONEi и, скажем, XJOBO, где атрибут XJOB0, в свою очередь, имеет значения, представляющие собой отношения. Отношения, являющиеся значениями атрибута XJOB0, имеют атрибуты JOBTITLE и, скажем, XSALHISTO, где атрибут XSALHISTO, опять же, имеет значения, представляющие собой отношения. Отношения, являющиеся значениями атрибута XSALHISTO, содержат атрибуты DATE и SALARY.

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

DEPTO { DEPTi, DBUDGET, MGR EMPi,

XEMPO { EMPi, PROJiT OFFi, PHONEi, XJOBO { JOBTITLE,

XSALHISTO { DATE, SALARY } } }, XPROJO { PROJi, PBUDGET },

XOFFICEO { OFFi, AREA, XPHONEO { PHONEi } } }

Замечание. Вместо описания потенциальных ключей здесь использовано выделение курсивом для обозначения тех атрибутов, которые по крайней мере уникальны внутри родителя (на самом деле атрибуты DEPTi, EMPi, PROJi, OFFi и PHONEi являются глобально уникальными согласно утверждениям, сделанным выше).

Этап /. Исключение атрибутов, содержащих значения-отношения

Для простоты предположим, что каждая переменная-отношение имеет первичный ключ, т.е. всегда на каком-то основании (не важно, на каком) можно выбрать один из потенциальных ключей в качестве первичного. В частности, для переменной-отношения DEPTO в качестве первичного ключа выберем атрибут DEPT# (таким образом, атрибут MGR EMPi становится альтернативным ключом).

Теперь можно приступить к исключению из переменной-отношения DEPTO атрибутов, содержаш[их значения-отношения, поскольку (как отмечалось в разделе 11.6) они являются нежелательными.

Для каждого атрибута переменной-отношения DEPTO, значениями которого являются отношения (т.е. для атрибутов ХЕМРО, XPROJ0 и XOFFICE0), создадим новую переменную-отношение с атрибутами, состояшими из атрибутов соответствуюшего отношения плюс атрибут первичного ключа переменной-отношения DEPTO. Первичным ключом каждой из вновь созданных расширенных переменных-отношений будет комбинация того атрибута, который в исходном отношении являлся уникальным внутри родителя , и первичного ключа переменной-отношения DEPTO. (Обратите внимание, что многие из созданных первичных ключей содержат атрибуты, которые являются избыточными для уникальной идентификации кортежей; впоследствии они будут исключены.) Удаляем атрибуты ХЕМРО, XPROJ0 и XOFFICE0 из переменной-отношения DEPTO.

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

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

DEPT1 { DEPTi, DBUDGET, MGR EMPi } PRIMARY KEY { DEPTi } ALTERNATE KEY { MGR EMPi }

EMPI { DEPTi, EMPi, PROJi, OFFi, PHONEi } PRIMARY KEY { DEPTi, EMPi }

JOBl { DEPTi, EMPi, JOBTITLE }

PRIMARY KEY { DEPTi, EMPi, JOBTITLE }

SALHISTl { DEPTi, EMPi, JOBTITLE, DATE, SALARY }

PRIMARY KEY { DEPTi, EMPi, JOBTITLE, DATE }

PROJI { DEPTi, PROJi, PBUDGET }

PRIMARY KEY { DEPTi, PROJi }

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