10.6. Резюме

На этом заканчивается первая из двух глав, посвященных процессу дальнейшей нормализации. В ней были описаны концепции первой, второй, третьей формы и нормальной формы Бойса-Кодда. Несколько уровней нормализации образуют общую структуру, в которой (n+1)-я нормальная форма автоматически находится в п-ой нормальной форме, тогда как обратное утверждение не верно, т.е. существуют отношения в п-ой нормальной форме, которые не находятся в (п+1) -ой нормальной форме. (Если п=3, то выражение "в (п+1)-ой нормальной форме” означает НФБК, а не 4НФ! Подробнее это обсуждается в следующей главе.) Более того, всегда можно выполнить приведение к НФБК, т.е. данное отношение всегда можно заменить эквивалентным множеством отношений, которые находятся в НФБК. Такое приведение используется для того, чтобы избежать избыточности и, следовательно, возникновения некоторых аномалий обновления.

Процесс приведения заключается в замене данного отношения некоторыми проекциями таким образом, чтобы обратное соединение этих проекций позволило вновь получить исходное отношение. Иначе говоря, этот процесс является обратимым (или декомпозиция выполняется без потерь информации). Также было показано, что функциональные зависимости играют решающую роль в этом процессе; фактически теорема Хеза утверждает, что если некоторая ФЗ выполняется, то некоторая декомпозиция выполняется без потерь. Такое положение дел может рассматриваться как еще одно подтверждение заявления, сделанного в главе 9 о том, что Ф3 “не совсем фундаментальны, но близки к ним".

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

В заключение предлагается весьма элегантное (и точное) определение 3НФ и НФБК, данное Заниоло (Zaniolo) [10.7]. Сначала будет дано определение

3НФ.

 Пусть дано отношение R, X является некоторым множеством атрибутов отношения R, a A – некоторым атрибутом отношения R. Отношение R находится в третьей нормальной форме тогда и только тогда, когда для каждой функциональной зависимости X -> A отношения R истинно по крайней мере одно из следующих утверждений:

1. X содержит А (т.е. эта ФЗ тривиальна).

2. Х содержит потенциальный ключ отношения R (таким образом, Х является су­перключом).

3. А содержится в потенциальном ключе отношения R.

(Следует напомнить, что суперключом называется множество атрибутов, вклю­чающее подмножество некоторого потенциального ключа, которое не обязательно является собственным подмножеством.) Определение НФБК можно получить из дан­ного определения для ЗНФ, просто опуская третье утверждение. Именно третье ут­верждение является причиной "неадекватности" оригинального определения Кодда для ЗНФ [9.4], которое упоминалось во введении к этой главе.

Упражнения

10.1. Докажите теорему Хеза. Будет ли верной обратная теорема?

10.2. Существует мнение, что каждое бинарное отношение находится в НФБК. Верно ли это утверждение?

10.3. На рис. 10.17 приведено иерархическое (т.е. ненормализованное) представ­ление информации, которая должна храниться в базе данных о персонале не­которой компании.

• В компании есть несколько отделов.

• В каждом отделе (Department) есть несколько сотрудников (Employee), не­сколько проектов (Project) и несколько кабинетов (Office).

 Каждый сотрудник имеет план работы (Job), т.е. несколько заданий, кото­рые он должен выполнить. Для каждой такой работы существует ведомость (Salary history), т.е. перечень денежных сумм, полученных сотрудником за выполнение данной работы.

 В каждом кабинете есть несколько телефонов (Phone).

department

employee

project

office

job

phone

Salary history

Рис. 10.17. Ненормализованное представление информации, которая должна храниться в базе данных о персонале компании

В базе данных должна храниться следующая информация:

Для каждого отдела: номер отдела (уникальный), бюджет и номер сотрудника, который возглавляет этот отдел (уникальный).

Для каждого сотрудника: номер сотрудника (уникальный), номер текущего проекта, номер кабинета, номер телефона, а также название выполняемой работы вместе с датами и размерами всех оплат, полученных за выполнение данной работы.

• Для каждого проекта: номер проекта (уникальный) и бюджет.

Для каждого кабинета: номер кабинета (уникальный), площадь в квадратных футах, номера (уникальные) всех телефонов, установленных в этом кабинете.

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

10.4. В базе данных системы учета заказов содержится информация о клиентах, товарах и заказах согласно приведенному ниже плану.

• Для каждого клиента:

номер клиента (уникальный);

. адрес доставки (несколько для каждого клиента);

баланс;

максимальный размер кредита;

скидка.

• Для каждого заказа:

информация заголовка:

номер клиента,

адрес доставки,

дата выполнения заказа;

строки данных (несколько для каждого заказа):

номер товара

количество данного товара.

Для каждого товара:

номер товара (уникальный);

заводы-изготовители;

количество товара на каждом заводе;

максимальное количество хранимого товара на каждом заводе;

описание товара.

Для внутреннего учета также вводится величина "количество для доставки”, связанная с каждой строкой каждого заказа. Эта величина сначала устанавливается равной количеству заказанного товара, а после выполнения поставки обнуляется.

Составьте макет такой базы данных, а также, как и в предыдущем упражнении, укажите семантические утверждения на основе заданных Ф3.

10.5. Предположим, что в упр. 10.4 только очень малая часть клиентов, например, процент или даже меньше, имеют больше одного адреса доставки. (Такова реальная ситуация, в которой незначительное число исключений может не вписываться в предлагаемую однородную структуру.) Каковы в таком случае недостатки решения, предложенного для упр. 10.4? Какие усовершенствования можно внести для их устранения?

10.6. (Модифицированная версия упр. 9.13.) Отношение TIMETABLE определяется со следующими атрибутами:

D День недели (1-5)

P Период времени в течение дня (1-8)

C Номер аудитории

Т Имя преподавателя.

S Имя студента.

L Название урока.

Кортеж {D:d, P:p, С:с, T:t, L:l} является элементом этого отношения тогда и только тогда, когда в момент времени {D:d, P:p} некоторый студент s посе­щает урок l, который преподается учителем t в аудитории с.

Можно предположить, что урок имеет длительность одного периода, а каждый урок имеет название, уникальное по отношению ко всем другим урокам данной недели. Сведите отношение TIMETABLE к более приемлемой структуре.

10.7. (Модифицированная версия упр. 9.14.) Дано отношение NADDR с атрибутами NAME (уникальное), STREET, CITY, STATE и ZIP. Причем каждому почтовому индексу соответствует только один город и штат, каждой улице, городу и штату— только один почтовый индекс. Находится ли отношение NADDR в НФБК, ЗНФ, 2НФ? Можно ли создать для этого отношения улучшенный макет?

Список литературы

Помимо приведенного списка литературы, следует также обратить внимание на ссылки к главе 9, особенно [9.4, 9.5] (т.е. ссылки на оригинальные статьи Кодда о 1НФ,2НФиЗНФ).

10.1. Bernstein P.A. Synthesizing Third Normal Form Relations from Functional Dependencies //ACM TODS. — 1976. — 1, № 4.

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

Замечание. Точно так же можно было бы рассмотреть заданное множество атрибутов и ФЗ как универсальное отношение, которое удовлетворяет за­данному множеству зависимостей. В этом случае процесс "синтеза" можно заменить процессом декомпозиции этого универсального отношения на про­екции в ЗНФ. Но, далее в данном обсуждении будет использоваться интер­претация на основе синтеза.

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

Возражением, принятым Бернстайном относительно такого подхода, являет­ся то, что манипуляции, выполняемые на основе такого алгоритма, чисто синтаксические и не имеют никакого отношения к семантике. Например, тре­тья из приведенных ниже функциональных зависимостей может или не мо­жет быть избыточной (т.е. подразумевается первой и второй из них) в зави­симости от значения R, S и Т.

A -> B в отношении R{A, B}

B -> C в отношении S {B, C}

A -> C в отношении T {A, C}

В качестве примера, в котором избыточность отсутствует, допустим, что A обозначает номер сотрудника, В — номер кабинета, С — номер отдела, R -- кабинет сотрудника, S— отдел, к которому относится кабинет, Т - отдел сотрудника. Рассмотрим случай, когда некоторый сотрудник работа работает в кабинете не своего отдела. Согласно алгоритму синтеза атрибуты S. C и T. C равны (как правило, имена отношений при этом не рассматриваются). Таким образом, предполагается наличие некоторого внешнего механизма (т.е. вмешательство человека) для предотвращения семантически неверных манипуляций. В данном случае следовало бы еще при определении исходных Ф3 использовать различные имена атрибутов, например С1 и С2 вместо S. С и T. C.

10.2. Codd E.F. Recent Investigations into Relational Data Base Systems // Pr Congress. — Stockholm, Sweden, 1974.

Здесь приводится обзор некоторых других работ на данную тему. В частности, дается "улучшенное определение третьей нормальной формы", торой фактически подразумевается нормальная форма Бойса-Кодда. Среди других тем можно найти обсуждение представлений и обновления представлений, подъязыков данных, обмена данными и исследования на эту тему( по состоянию на 1974 год).

10.3. Date C.J. A Normalization Problem // The Relational J. — 1992. — 4, № 2

Согласно аннотации в этой статье рассматривается простая задача нормализации, которая используется для представления некоторых идей в области составления макета базы данных и явного объявления ограничений целостности. Задача сформулирована на основе простой базы данных некоторой авиакомпании с перечисленными ниже ФЗ, где приняты следующие обозначения: FLIGH1 название авиарейса, DESTINATION — место назначения, HOUR — время в часах, DAY — день недели, GATE — место посадки на самолет, PILOT — пилот.

1. { FLIGHT } -> DESTINATION

2. { FLIGHT } -> HOUR

3. { DAY, FLIGHT } -> GATE

4. { DAY, FLIGHT } -> PILOT

5. { DAY, HOUR, GATE } -> DESTINATION

6. { DAY, HOUR, GATE } -> FLIGHT

7. { DAY, HOUR, GATE }. -> PILOT .

8. { DAY, HOUR, PILOT } -> DESTINATION

9. { DAY, HOUR, PILOT } -> FLIGHT

10. { DAY, HOUR, PILOT } -> GATE

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

10.4. Heath I.J. Unacceptable File Operations in a Relational Database // Proc.1971 ACM SIGFIDET Workshop on Data Description, Access, and Control.-San Diego, Calif, 1971.

В работе дается определение ЗНФ, которое на самом деле является первым опубликованным определением НФБК. В ней также приводится доказательство теоремы, которая в данной главе называется теоремой Хеза. Следует отметить, что упомянутые в настоящей главе три этапа процедуры нормализации представляют собой практические воплощения этой теоремы.

10.5 Kent W A Simple Guide to Five Normal Forms in Relational Database Theory//CACM. – 1983. 26.№2.

10.6. Rissanen J. Independent Components of Relations // ACM TODS. — 1977. — 2, № 4.

10.7. Zaniolo C. A New Normal Form for the Design of Relational Database Schemata // Ibid.—1982.— 7, № 3.

Первоисточник элегантных определений ЗНФ и НФБК, упомянутых в этой главе. Основная цель статьи — определение новой нормальной формы, нормальной формы с элементарными ключами — НФЭК, которая занимает промежуточное положение между ЗНФ и НФБК и "содержит все преимуще­ства обеих этих форм", но лишена всех их недостатков (например, ЗНФ явля­ется "очень нестрогой", а НФБК "склонна к вычислительной сложности"). В статье также показано, что алгоритм Бернстайна [10.1] приводит к генерации отношений, которые уже находятся в НФЭК.

Ответы к упражнениям

10.1. Теорема Хеза утверждает, что если отношение R{A, В, С} удовлетворяет функциональной зависимости А —> В (где А, В и С являются множествами ат­рибутов), то R равносильно соединению его проекций R1 с атрибутами {А, В} и R2 с атрибутами {А, С}.

Далее в этом доказательстве будет использована сокращенная неформальная запись (а, b, с) для кортежа [А: а, В:b, С:с}.

Сначала следует показать, что ни один кортеж отношения R не утрачивается при разбиении на проекции и обратном соединении этих проекций. Пусть (а, Ь, с) R, тогда (а, b)  R1 и (а, с)  R2, а значит (а, b, с)  R1 JOIN R2.

Затем следует показать, что каждый кортеж этого соединения действительно является кортежем отношения R (т.е. при соединении не было получено ни­каких "побочных" и нежелательных кортежей). Пусть (а, b, с)  R1 JOIN R2. Тогда для генерации кортежа соединения должны выполняться зависимости (а, b)  R1 и (a, с)  R2. Следовательно, для генерации кортежа (а, с)  R2 для некоторого атрибута b* должен существовать кортеж (а, b*, с)  R. Тогда должен также существовать кортеж (а, b*)  R1. Теперь у нас есть (а, b)  R1 и (а, b*)  R1, а поскольку А —> В, значит b=b*. Отсюда (а, Ь, с)  R.

Теорема, обратная теореме Хеза, утверждает, что если отношение R{A, В, С} равносильно соединению его проекций R1 с атрибутами {А, В} и R2 с атри­бутами {А, С}, то R удовлетворяет зависимости А —> В. Это утверждение не­верно. В качестве примера отношения, которое равняется соединению двух его проекций и вовсе не удовлетворяет никакой (нетривиальной) ФЗ, можно предложить отношение СТХ из главы 11.

10.2. Это утверждение почти (но не совсем) верно. Приведенный ниже экзотиче­ский пример обратной ситуации взят из [5.6]. Рассмотрим отношение USA {COUNTRY, STATE}, которое интерпретируется как "STATE (штат) яв­ляется членом COUNTRY (страны)", где под страной в каждом кортеже под­разумеваются Соединенные Штаты Америки. Тогда в данном отношении бу­дет выполняться приведенная ниже ФЗ.

{ } -> COUNTRY

А поскольку пустое множество { } не является потенциальным ключом, от­ношение USA не находится в НФБК.

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

10.3. На рис. 10.18 показаны все наиболее важные Ф3: как те, которые подразумевались в упражнении, так и те, которые соответствуют разумным семантическим утверждениям (они перечислены ниже). Атрибутам даны такие имена, которые могли бы пояснить их значения.

Рис. 10.18. Диаграмма зависимостей для упр. 10.3

Семантические утверждения:

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

отделов.

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

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

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

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

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

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

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

Этап 0.

Прежде всего отметим, что исходную иерархическую структуру можно рассматривать как ненормализованное отношение DEPTO:

DEPTO ( DEPT#, DBUDGET, MGR#, XEMPO, XPROJO, XOFFICEO ) CANDIDATE KEY ( DEPT# )

CANDIDATE KEY ( MGR# )

Здесь смысл атрибутов DEPT# (номер отдела), DBUDGET (ведомость) и MGR# (номер руководителя отдела) ясен из сокращенных названий, а доме- ны, соответствующие атрибутам XEMPO (сотрудник), XPROJO (проект) и XOFFICEO (кабинет), состоят из значений-отношений и для них требуется дополнительное разъяснение.

Для начала рассмотрим домен значений-отношений, соответствующий атрибуту XPROJO. Пусть РВ является множеством всех возможных пар PROJ#-PBUDGET (т.е. декартовым произведением доменов для атрибутов PROJ# и PBUDGET). Тогда значение атрибута XPROJO, соответствующее любому заданному значению DEPT#, является некоторым подмножеством множества пар в РВ. Таким образом, соответствующий атрибуту XPROJ0# домен значений-отношений является множеством всех возможных подмножеств множества PB- так называемые мощное множество множества PB( попросту говоря, здесь игнорируется тот факт, что существует Ф3 атрибута PROJ# с атрибутом PBUDGET; на практике это означает, что некоторые подмножества множества PB не являются допустимыми значениями для атрибута XPROJO.)

Аналогичные замечания можно привести для атрибутов ХЕМРО, XOFFICEO и действительно для всех атрибутов данного примера, домены которых пред­ставляют значения-отношения. В каждом таком случае домен является мощ­ным множеством множества всех возможных кортежей некоторого частного типа (эти кортежи не обязательно нормализованы, т.е. они могут содержать повторяющиеся группы). Обозначим каждый такой атрибут значе­ний-отношений приставкой "X". Таким образом, заданная иерархия может быть представлена следующим "вложением" нормализованных и ненормали­зованных отношений. (Здесь курсивом выделены атрибуты, которые являют­ся "уникальными внутри родительских отношений" или глобально уникаль­ными, если таких родителей не существует.)

DEPTO ( DEPT#, DBUDGET, MGR#,

ХЕМРО ( EMP#, PROJ#, OFF#, PHONE#, XJOBO ( JOBTITLE,

XSALHISTO ( DATE, SALARY ) ) ),

XPROJO ( PROJ#, PBUDGET ),

XOFFICE ( OFF#, AREA, XPHQNEO ( PHONE# ) ) )

Этап 1.

Для простоты предположим, что каждое отношение имеет первичный ключ, т.е. всегда можно задать один потенциальный ключ в качестве первичного. В частности, для DEPTO в качестве первичного ключа выберем DEPT# (таким образом, MGR# становится альтернативным ключом). Теперь можно привес­ти данное отношение к набору отношений в 1НФ. Предварительный процесс приведения, предложенный Коддом, выглядит следующим образом.

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

• Затем необходимо удалить из родительского отношения все атрибуты значе­ний-отношений (т.е. атрибуты, заданные на доменах значений-отношений), удалить корневую вершину иерархии и повторить ту же последовательность действий для каждой из оставшихся подчиненных иерархий.

После выполнения этих действий будет получен приведенный ниже набор отношений в 1НФ. Обратите внимание, что при этом будут утрачены все ат­рибуты значений-отношений. (Действительно, рассматривая каждую подчи­ненную иерархию отдельно, мы тем самым непосредственно исключим все многозначные зависимости, которые не являются ФЗ. Подробнее это обсуж­дается в главе 11.)

DEPT1 ( DEPT#, DBUDGET, MGR# )

PRIMARY KEY ( DEPT# ) ALTERNATE KEY ( MGR# )

EMP1 ( DEPT#, EMP#, PROJ#, OFF#, PHONE# )

PRIMARY KEY ( DEPT#, EMP# )

JOB1 ( DEPT#, EMP#, JOBTITLE ) .

PRIMARY KEY ( DEPT#, EMP#, JOBTITLE )

SALHIST1 ( DEPT#, EMP#, JOBTITLE, DATE, SALARY )

PRIMARY KEY ( DEPT#, EMP#, JOBTITLE, DATE )

PROJ1 ( DEPT#, PROJ#, PBUDGET )

PRIMARY KEY ( DEPT#, PROJ# )

OFFICE1 ( DEPT#, OFF#, AREA )

PRIMARY KEY ( DEPT#, OFF# )

PHQNE1 ( DEPT#, OFF#, PHONE )

PRIMARY KEY ( DEPT#, OFF#, PHONE# )

Этап 2.

Теперь можно привести отношения, находящиеся в 1НФ, к эквивалентной совокупности отношений в 2НФ, исключая неприводимые зависимости. Ни­же все отношения в 1НФ рассматриваются последовательно одно за другим.

DEPT1 Это отношение уже находится в 2НФ.

EMP1 Прежде всего, следует отметить, что DEPT# является избыточным компонентом первичного ключа данного отношения. В ка­честве первичного ключа здесь можно принять атрибут ЕМР#, и в таком виде данное отношение уже будет находиться в 2НФ.

JOB1 Опять отметим, что не обязательно использовать DEPT# в каче­стве компонента первичного ключа. Поскольку DEPT# функцио­нально зависит от ЕМР#, то имеется неключевой атрибут (DEPT#), который не находится в полной функциональной зави­симости от первичного ключа (комбинации {ЕМР#, JOBTITLE}), и, следовательно, JOB1 не находится в 2НФ. Это отношение можно заменить двумя другими:

JOB2A ( ЕМР#, JOBTITLE )

PRIMARY KEY ( ЕМР#, JOBTITLE )

и

JOB2B ( EMP#, DEPT# )

PRIMARY KEY ( EMP# )

Однако JOB2A является проекцией SALHIST2 (ниже это описано подробнее), а JOB2B — проекцией EMP1 (далее переименованного в ЕМР2). Следовательно, оба отношения могут быть удалены.

SALHIST1 Так же, как и в случае с JOB1, можно полностью удалить атри­бут DEPT#. Более того, JOBTITLE не требуется в качестве компонента первичного ключа. В качестве первичного ключа можно использовать комбинацию {ЕМР#, DATE}, чтобы полу­чить следующее отношение в 2НФ:

SALHIST2 ( ЕМР#, DATE, JOBTITLE, SALARY ) PRIMARY KEY ( EMP#, DATE )

PROJ1 Так же, как и в случае с EMP1, можно рассматривать DEPT# как неключевой атрибут, тогда данное отношение находится в 2НФ.

OFFICE1 Здесь можно привести аналогичное рассуждение.

PHONE1 DEPT# можно удалить совсем, поскольку отношение (DEPT#, OFF#) является проекцией отношения OFFICE1 (переименованного далее в OFFICE2). Кроме того, OFF# функционально зависит от PHONE#, поэтому в качестве первичного ключа можно принять только PHONE# с получением приведенного ниже отношения в 2НФ:

PHONE2 ( PHONE#, OFF# )

PRIMARY KEY ( PHONE# )

Обратите внимание, что это отношение не обязательно является проекцией ЕМР2 (телефоны и кабинеты могут существовать и без соотнесения их с конкретными сотрудниками), поэтому его нельзя удалить.

Таким образом, может быть получен следующий набор отношений в 2НФ:

DEPT2 (DEPT#, DBUDGET, MGR#)

PRIMARI KEY (DEPT#)

ALTERNATE KEY (MGR#)

EMP2 (EMP#, DEPT#, PROJ#, OFF#, PHONE#)

PRIMARY KEY (EMP#)

SALHIST2 ( EMP#, DATE, JOBTITLE, SALARY )

PRIMARY KEY ( EMP#, DATE )

PROJ2 ( PROJ#, DEPT#, PBUDGET )

PRIMARY KEY ( PROJ# )

OFFICE2( OFF#, DEPT#, AREA )

PRIMARY KEY ( OFF# )

PHONE2 ( PHONE#, OFF# )

PRIMARY KEY ( PHONE# )

Этап 3.

Теперь, исключая транзитивные зависимости, можно привести отношения, на­ходящиеся в 2НФ, к эквивалентной совокупности отношений в ЗНФ. Единст­венным отношением, которое находится в 2НФ и не находится в ЗНФ, является отношение ЕМР2, в котором атрибуты OFF# и DEPT# транзитивно зависят от первичного ключа EMP#: OFF# через PHONED, DEPT# через PROJ#, а также через OFF# (а следовательно, и через PHONED). Таким образом, отношению ЕМР2 соответствуют следующие отношения (проекции) в ЗНФ:

EMP3 ( EMP#, PROJ#, PHONE# )

PRIMARY KEY ( EMP# )

X ( PHONE#, OFF# )

PRIMARY KEY ( PHONE# )

Y ( PROJ#, DEPT# )

PRIMARY KEY ( PROJ# )

Z ( OFF#, DEPT# )

PRIMARY KEY ( OFF# )

Однако отношение Х — это аналог отношения PHONE2, Y — проекции PROJ2, Z — проекции OFFICE2. Следовательно, данная совокупность отношений в ЗНФ будет выглядеть следующим образом:

DEPT3 ( DEPT#, BUDGET, MGR# )

PRIMARY KEY ( DEPT# )

ALTERNATE KEY ( MGR#)

EMP3 ( EMP#, PROJ#, PHONE# )

PRIMARY KEY ( EMP# )

SALHIST3 ( EMP#, DATE, JOBTITLE, SALARY )

PRIMARY KEY ( EMP#, DATE )

PROJ3 ( PROJ#, DEPT#, PBUDGET )

PRIMARY KEY ( PROJ# )

OFFICE3 ( OFF#, DEPT#, AREA )

PRIMARY KEY ( OFF# )

PHONE3 ( PHONE#, OFF# )

PRIMARY KEY ( PHONE# )

Наконец, каждое из этих отношений в ЗНФ уже находится в НФБК (а точнее, в 4НФ благодаря приведению к 1НФ на этапе 1; подробнее это обсуждается в главе 11).

Следует отметить, что при некоторых (разумных) дополнительных семантических ограничениях этот набор отношений становится сильно избыточным [4.1], так как проекция отношения PROJ3 с комбинацией {PROJ#, DEPT#} является проекцией соединения отношений EMP3, PHONE3 и OFFICE3.

В заключение отметим, что отношения в НФБК можно «обнаружить» на основе диаграммы ФЗ. Замечание. Это значит, что «обнаружить» декомпозицию НФБК можно не всегда, а лишь в некоторых практических случаях. Точнее, для данного отношения R, удовлетворяющего множеству функциональных зависимостей S, показанный ниже алгоритм (пункты 0-8) гарантирует декомпозицию D отношения R на отношения в ЗНФ (но не НФБК), которая выполняется одновременно без потерь инфор­мации и с сохранением зависимости.

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

1. Пусть I является неприводимым покрытием для S.

2. Пусть Х является множеством атрибутов с левой части некоторой зависи­мости Х —> Y в I.

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

4. Пусть Z является объединением У1, Y2,... Yn.

5. Заменим D объединением D и проекцией отношения R по атрибутам Х и Z.

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

7. Пусть A1, A2, ...An являются неучтенными до сих пор атрибутами отно­шения R (например, такими, которые не включены в любое отношение в D). Заменим D объединением D и проекцией отношения R по атрибутам А, А2,...Ап.

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

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

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

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

3. Заменим отношение T в D двумя проекциями, а именно: одной по атрибу­там Х и Y, а другой — по всем атрибутам, за исключением Y. Возвращаясь к примеру с персоналом компании, можно предложить читате­лю еще одно упражнение, которое относится не только к самой нормализа­ции, но и макету базы данных в целом. Попробуйте расширить описанный выше макет базы данных, включая в него все необходимые спецификации внешних ключей.

10.4. На рис. 10.19 показаны наиболее важные ФЗ, а семантические допущения сформулированы и приведены ниже.

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

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

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

ADDRES

CUST#

CREDLIM

BAL

QTYORD

ORD#

DISCOUNT

DATE

QTYOUT

LINE#

ITEM#

DESCN

QTYOH

PLANT#

DANGER

Рис. 10.19. Диаграмма зависимостей для упр. 10.4

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

CUST ( CUST #, BAL, CREDLIM, DISCOUNT ) PRIMARY KEY ( CUST# )

SHIPTO ( ADDRESS#, CUST# )

PRIMARY KEY ( ADDRESS )

ORDHEAD ( ORD#, ADDRESS, DATE )

PRIMARY KEY ( ORD# )

ORDLINE ( ORD#, LINE#, ITEM#, QTYORD, QTYOUT ) PRIMARY KEY ( ORD#, LINE# )

ITEM ( ITEM#, DESCN )

PRIMARY KEY ( ITEM# )

IP ( ITEM#, PLANT#, QTYOH, DANGER )

PRIMARY KEY ( ITEM#, PLANT# )

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

RETRIEVE CUST WHERE CUST# = input. CUST# ;

проверить баланс, максимальный размер кредита и т.д. ;

RETRIEVE SHIPTO WHERE ADDRESS = input.ADDRESS ;

AND CUST# == input.CUST#

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

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

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

CUST ( CUST#, ADDRESS, BAL, CREDLIM, DICOUNT )

PRIMARY KEY ( CUST# )

А отношение SHIPTO можно заменить отношением

SECOND ( ADDRESS, CUST# )

PRIMARY KEY ( ADDRESS )

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

RETRIEVE CUST WHERE CUST# = input. CUST# ;

проверить баланс, максимальный размер кредита и т.д. ;

if CUST. ADDRESS <> input.ADDRESS then

RETRIEVE SECOND WHERE ADDRESS = input.ADDRESS ;

AND CUST# = input.CUST#

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

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

Ниже перечислены некоторые преимущества такого подхода.

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

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

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

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

10.6. SCHED ( L, Т, С, D, Р )

CANDIDATE KEY ( L )

CANDIDATE KEY ( Т, D, P )

CANDIDATE KEY ( C, D, P )

STUDY ( S, L )

CANDIDATE KEY ( S, L )

10.7. Отношение NADDR находится в 2НФ, но не в ЗНФ и не в НФБК. Усовер­шенствованный макет может иметь следующий вид:

NSZ ( NAME, STREET, ZIP )

PRIMARY KEY ( NAME )

ZCS ( ZIP, CITY, STATE )

PRIMARY KEY ( ZIP )

Оба отношения находятся в НФБК, однако следует обратить внимание на пе­речисленные ниже особенности.

• Поскольку STREET (улица), CITY (город) и STATE (штат) почти всегда используются совместно (например, для создания списка рассылки), почто­вые индексы меняются не очень часто, тогда приведенная декомпозиция вряд ли потребуется.

• В частности, для извлечения полного адреса для заданного в атрибуте NAME имени потребуется выполнить соединение (хотя это соединение можно заменить определением отношения NADDR как представления от­ношений NSZ и ZCS). Иначе говоря, нормализация до НФБК хороша для обновления, но плоха для извлечения данных, т.е. избыточность, которая имеет место в отсутствие полной нормализации, может вызвать проблемы с обновлением, но может оказаться полезной при извлечении данных. (С дру­гой стороны, такая избыточность может значительно затруднить некоторые выборки данных, т.е. привести к замедлению выполнения соответствующих запросов.) Трудности вызываются неконтролируемой избыточностью, а контролируемая избыточность (т.е. избыточность, которая задана и управ­ляется в СУБД ) может быть вполне приемлемой в некоторых ситуациях.

• Функциональная зависимость { STREET, CITY, STATE } —> ZIP явно не представлена в этом макете, а поддерживается отдельно: либо декларативно (об этом будет подробнее сказано в дальнейших главах этой книги), либо процедурно. На самом деле отношения NSZ и ZCS не являются независи­мыми в смысле Риссанена [10.6].