11.7. Резюме

¹² Это действительно возможно! Следует отметить, что это невозможно в случае пере­менной-отношения RVK, по крайней мере непосредственно (т.е. без введения некоторой разно­видности атрибута СШАМЕ, предназначенного для указания "имени потенциального ключа").

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

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

RVK

RVNAME

СК

ATTRNAME

S#

SP

ATTRNAME

S# P#

MARRIAGE

ATTRNAME

HUSBAND DATE

MARRIAGE

ATTRNAME

DATE WIFE

MARRIAGE

ATTRNAME

WIFE HUSBAND

Рис. 11.18. Переменная-отношение RVK, входящая в каталог некоторой базы данных

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

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

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

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

■ Пусть дана переменная-отношение R, X является некоторым подмножеством атри­бутов этой переменной-отношения R и А является некоторым отдельным атрибу­том переменной-отношения R. Переменная-отношение R находится в третьей нормальной форме тогда и только тогда, когда для каждой функциональной за­висимости X —» А в переменной-отношении R истинно по крайней мере одно из следующих утверждений.

1. Подмножество X включает атрибут А (т.е. данная ФЗ тривиальна).

2. Подмножество X является суперключом переменной-отношения R.

3. Атрибут А входит в состав некоторого потенциального ключа переменной-отношения R.

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

Упражнения

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

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

3. На рис. 11.19 показана структура информации о персонале компании, которая должна быть помешена в базу данных. Она представлена в том виде, который ис­пользуется при работе с иерархической СУБД, подобной продукту Information Management System (IMS) фирмы IBM (см. главу 1). Эта структура удовлетворяет следующим правилам.

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

• В каждом отделе (Department) есть некоторое количество сотрудников (Employee), занятых в нескольких проектах (Project) и размещающихся в не­скольких офисах (Office).

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

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

DEPARTMENT

EMPLOYEE

PROJECT

OFFICE

JOB

PHONE

SALARY HISTORY

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

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

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

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

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

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

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

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

■ Для каждого клиента: номер клиента (уникальный);

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

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

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

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

детальные строки (несколько на один заказ): номер детали,

заказанное количество.

■ Для каждой детали: номер детали (уникальный); заводы-изготовители; запас деталей на каждом заводе;

минимальное количество деталей на складе для каждого завода; описание детали.

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

5. Предположим, что в упр. 11.4 лишь очень незначительная часть клиентов, напри­мер один процент или даже меньше, имеет более одного адреса доставки. (Это обычная ситуация в реальной жизни, когда лишь незначительное число исключе­ний— но достаточно важных— может не вписываться в предлагаемую общую структуру.) Можете ли вы в этом случае указать на какие-либо недостатки решения, которое было предложено вами для упр. 11.4? Какие усовершенствова­ния целесообразно было бы внести для их устранения?

6. (Модифицированная версия упр. 10.13.) Переменная-отношение TIMETABLE вклю­чает следующие атрибуты.

D Р С

т

S L

День недели (1-5) Время в течение дня (1-8)

Номер аудитории Имя преподавателя Имя студента

Название лекции

Кортеж {D:d, Р:р, С:с, T:t, L:l} будет допустимым для этой переменной-отношения тогда и только тогда, когда в момент {D:d, Р:р} некоторый студент s по­сещает лекцию 1, которая читается преподавателем t в аудитории с. Можно предпо­ложить, что каждая лекция продолжается только один академический час и имеет на­звание, уникальное по отношению ко всем другим лекциям, читаемым на данной не­деле. Сделайте структуру переменной-отношения TIMETABLE более приемлемой. 11.7. (Модифицированная версия упр. 10.14.) Дана переменная-отношение NADDR с атри­бутами NAME (уникальное имя), STREET, CITY, STATE и ZIP. Причем каждому почто­вому индексу соответствует только один город и штат, а каждой улице, городу и штату— только один почтовый индекс. Находится ли переменная-отношение NADDR в НФБК, ЗНФ, 2НФ? Можно ли предложить улучшенный вариант этой пе­ременной-отношения?

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

Помимо приведенного здесь списка литературы, следует также обратить внимание на ссылки к главе 10, особенно [10.4, 10.5] (т.е. ссылки на оригинальные статьи Кодда о ШФ, 2НФиЗНФ).

11.1. Bernstein Р.А. Synthesizing Third Normal Form Relations from Functional Dependencies // ACM TODS. — December, 1976. — 1, Ш 4.

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

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

А —> В (в R{A,B}) В -» С (в S{B,C}) А -» С (в Т{А,С})

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

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

11.2. Codd E.F. Recent Investigations into Relational Data Base Systems // Proc. IFIP Congress. — Stockholm, Sweden, 1974.

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

11.3. Date C.J. A Normalization Problem // The Relational J. — 1992. — 4, N° 2.

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

{ FLIGHT } -> DESTINATION

{ FLIGHT } -» HOUR

{ DAY, FLIGHT } -» GATE

{ DAY, FLIGHT } ~> PILOT

{ DAY, HOUR, GATE } -» DESTINATION

{ DAY, HOUR, GATE } -» FLIGHT

{ DAY, HOUR, GATE } -> PILOT

{ DAY, HOUR, PILOT } -> DESTINATION

{ DAY, HOUR, PILOT ) -> FLIGHT

{ DAY, HOUR, PILOT ) -» GATE

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

11.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., November, 1971.

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

11.5. Kent W. A Simple Guide to Five Normal Forms in Relational Database Theory // CACM. — February, 1983. — 26, № 2.

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

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

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

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

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

11.1. Теорема Хита утверждает, что если переменная-отношение R{A, В, С} удовле­творяет функциональной зависимости А ~» В (где А, В и С являются множества­ми атрибутов), то R равносильна соединению ее проекций R1 с атрибутами {А, В} и R2 с атрибутами {А, С}. Далее в этом доказательстве будет использо­ван сокращенный неформальный вариант записи вида (а, Ь, с) для представ­ления кортежа {Asa, B:b, С:с}.

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

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

Теорема, обратная теореме Хита, утверждает, что если переменная-отношение R{A, В, С} равносильна соединению ее проекций Rl с атрибутами {А, В} и R2 с атрибутами {А, С}, то R удовлетворяет зависимости А -» В. Это утверждение не­верно. В качестве примера переменной-отношения, которая равняется соединению двух ее проекций и вовсе не удовлетворяет никакой нетривиальной ФЗ, можно предложить переменную-отношение СТХ, которая показана на рис. 12.2.

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

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

{ } -> COUNTRY

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

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

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

AREA

DBUDGET

OFF#

DEPT#

MGR ЕМРЩ

PHONE*

EMP#

PROJ#

PBUDGET

JOBTITLE

DATE

SALARY

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

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

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

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

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

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

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

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

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

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

DEPTO { DEPTi, DBUDGET, MGR EMPi, XEMPO, XPROJO, XOFFICEO } KEY { DEPTi } KEY { MGR_EMPi }

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

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

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

• Наконец, значение атрибута ХЕМРО в составе каждого кортежа переменной-отношения DEPT0 представляет собой отношение с атрибутами EMPi, PROJi, OFFi, PHONEi и, скажем, XJOB0, где атрибут XJOB0, в свою очередь, имеет зна­чения, представляющие собой отношения. Отношения, являющиеся значения­ми атрибута XJOB0, имеют атрибуты J0BTITLE и, скажем, XSALHIST0, где атри­бут 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, OFFt и PHONEi являются глобально уникальными согласно утверждениям, сде­ланным выше).

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

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

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

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

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

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

DEFT1 { DiPT#, DBUDGET, MGR EMPl } PRIMARY KEY { DEPTi }~ ALTERNATE KEY { MGR_EMP§ }

EMPl < DEPTI, EMPi, PROJt, OFFi, PHONIi } PRIMARY KEY { DEPTi, EMPi }

J0B1 { DEPTi, EMPi, JOBTITLE }

PRIMARY KEY { DEPTi, EMPi, JOBTITLE }

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

PRIMARY KEY { DEPTi, EMPi, JOBTITLE, DATE }

PR0J1 { DEPTi, PROJi, PBUDGET }

PRIMARY KEY { DEPTi, PROJi }

0FFICE1 { DEPTI, OFFI, AREA }

PRIMARY KEY { DEPTi, OFFi }

PHONEI { DEPTi, OFFi, PHONEi }

PRIMARY KEY { DEPTi, OFFi, PHONEi }

Этап 2. Приведение отношений к 2НФ

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

DEPT1 ЕМР1

J0B1

SALHIST1

PRO Л

0FFICE1

Эта переменная-отношение уже находится в 2НФ. Прежде всего следует отметить, что атрибут DEPTi является избыточным компонентом первичного ключа данной переменной-отношения. В каче­стве первичного ключа здесь можно принять атрибут EMPi, причем в та­ком виде данная переменная-отношение уже будет находиться в 2НФ. Опять отметим, что необязательно использовать атрибут DEPTi в качест­ве компонента первичного ключа. Поскольку атрибут DEPTi функцио­нально зависит от атрибута EMPi, имеется неключевой атрибут (DEPTi), зависимость которого от первичного ключа (комбинации атрибутов {EMPi, JOBTITLE}) не является неприводимой и, следовательно, пере­менная-отношение J0B1 не находится во 2НФ. Эту переменную-отношение можно заменить двумя другими.

J0B2A { EMPi, JOBTITLE }

PRIMARY KEY { EMPi, JOBTITLE }

JOB2В { EMPi, DEPTi } PRIMARY KEY { EMPi }

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

Так же, как и в случае переменной-отношения J0B1, атрибут DEPTi можно полностью удалить. Более того, как компонент первичного ключа атрибут JOBTITLE не требуется. В качестве первичного ключа достаточно использовать комбинацию атрибутов {EMPi, DATE}. В ре­зультате будет получена следующая переменная-отношение, находя­щаяся в 2НФ.

SALHIST2 { EMPi, DATE, JOBTITLE, SALARY } PRIMARY KEY { EMPi, DATE }

Так же, как и в случае с переменной-отношением ЕМР1, можно рассмат­ривать атрибут DEPTi как неключевой, причем данная переменная-отношение будет находиться в 2НФ. Здесь можно применить аналогичное рассуждение.

PH0NE1 Атрибут DEPTf можно удалить совсем, поскольку переменная-отношение {DEPTI, OFFf) является проекцией переменной-отношения 0FFICE1 (переименованной далее в 0FFICE2), Кроме того, атрибут 0FF# функцио­нально зависит от атрибута PHONEf, поэтому в качестве первичного клю­ча достаточно принять только атрибут PHONEf, в результате чего будет получена приведенная ниже переменная-отношение в 2НФ.

PHONE2 { PHONEf, 0FF# }

PRIMARY KEY { PHONEf }

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

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

DEPT2 { DEPTf, DBUDGET, MGR EMPf } PRIMARY KEY { DEPTf }~ ALTERNATE KEY { MGR_EMPf }

EMP2 { EMPf, DEPTf, PROJf, OFFf, PHONEf } PRIMARY KEY { EMPf }

SALHIST2 { EMPf, DATE, JOBTITLE, SALARY } PRIMARY KEY { EMPf, DATE }

PR0J2 { PROJf, DEPTf, PBDDGET } PRIMARY KEY { PROJf }

0FFICE2 { OFFf, DEPTf, AREA } PRIMARY KEY { OFFf }

PHONE2 { PHONEf, OFFf }

PRIMARY KEY { PHONEf }

Этап 3. Приведение к ЗНФ

Теперь можно привести переменные-отношения, находящиеся в 2НФ, к эквивалент­ному набору переменных-отношений в ЗНФ, для чего необходимо исключить тран­зитивные зависимости. Единственной переменной-отношением, которая находится в 2НФ и не находится в ЗНФ, является переменная-отношение ЕМР2, в которой атрибу­ты OFFf и DEPTf транзитивно зависят от первичного ключа EMPf: атрибут OFFf через атрибут PHONEf, а атрибут DEPTf — через атрибут PROJf, а также через атрибут OFFf (следовательно, и через атрибут PHONEf). Таким образом, переменной-отношению ЕМР 2 соответствует следующий набор переменных-отношений (проекций) в ЗНФ.

ЕМРЗ { EMPf, PROJf, PHONEf }

PRIMARY KEY { EMPf } X { PHONEf, OFFf }

PRIMARY KEY { PHONEf }

Y { PROJI, DEPTi } PRIMARY KEY { PROJi }

Z { OFFI, DEPTt } PRIMARY KEY { OFFf }

Однако переменная-отношение X — это аналог переменной-отношения PH0NE2, пе­ременная-отношение Y — это проекция переменной-отношения PR0J2, а перемен­ная-отношение Z — это проекция переменной-отношения 0FFICE2. Следовательно, окончательная совокупность переменных-отношений в ЗНФ будет выглядеть сле­дующим образом.

DEPT3 { DEPTt, DBDDGET, MGR_EMPt } PRIMARY KEY { DEPTt } ALTERNATE KEY { MGR_EMP# }

EMP3 { EMPt, PROJt, PHONEi } PRIMARY KEY { EMPt }

SALHIST3 { EMPi, DATE, JOBTITLE, SALARY } PRIMARY KEY { EMPt, DATE }

PR0J3 { PROJt, DEPTt, PBUDGET } PRIMARY KEY { PROJi }

0FFICE3 { OFFi, DEPTt, AREA } PRIMARY KEY { OFFl }

PH0NE3 { PHONEi, OFFi }

PRIMARY KEY { PHONEi }

Наконец, отметим, что каждая из этих переменных-отношений в ЗНФ уже находит­ся в НФБК. |

Следует указать на то, что при учете некоторых (разумных) дополнительных семан­тических ограничений этот набор переменных-отношений становится сильно избы­точным [5.1], так как проекция переменной-отношения PR0J3 по атрибутам {PROJi, DEPTi} практически всегда эквивалентна проекции, выполненной для ре­зультата соединения переменных-отношений ЕМРЗ, PH0NE3 и 0FFICE3.

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

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

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

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

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

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

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

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

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

7. Пусть Al, А2,An являются неучтенными до сих пор атрибутами переменной-отношения R (т.е. такими, которые еще не включены в какую-либо из перемен­ных-отношений в множестве d). Заменим декомпозицию d объединением теку­щего значения d с проекцией переменной-отношения R по атрибутам Al, А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 показаны наиболее важные функциональные зависимости, а соответ­ствующие семантические допущения приведены ниже.

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

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

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

QTYORD

QTYOUT

LINE#

DESCN

ITEM#

QTYOH

PLANT*

DANGER

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

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

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

SHIPTO { ADDRESS, CUSTi }

PRIMARY KEY ( ADDRESS )

ORDHEAD { ORDl, ADDRESS, DATE } PRIMARY KEY { ORDl }

ORDLINE { ORDl, LINE*, ITEM#, QTYORD, QTYOUT } PRIMARY KEY { ORDl, LINE! }

ITEM { ITEM!, DESCN }

PRIMARY KEY { ITEM* }

IP { ITEM*, PLANT*, QTYOH, DANGER } PRIMARY KEY { ITEM*, PLANT* }

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

RETRIEVE CUST WHERE CUST* = input.CUST* ;

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

RETRIEVE SHIPTO WHERE ADDRESS = input.ADDRESS ;

AND CUST* = input.CUST*

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

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

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

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

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

SECOND { ADDRESS, CUSTt } KEY { ADDRESS }

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

RETRIEVE CUST WHERE CUSTt = input.CUSTt ;

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

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

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

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

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

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

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

Рис. 11.22. Диаграмма функциональных зависимостей для упр. 11.6

SCHED { L, Т, С, D, Р } KEY { L } KEY { Т, D, Р } KEY { С, D, Р }

STUDY { S, L }

KEY { S, L }

11.7. Переменная-отношение NADDR находится в 2НФ, но не в ЗНФ (и, следовательно, не в НФБК). Усовершенствованный вариант может иметь следующий вид.

NSZ { NAME, STREET, ZIP } KEY { NAME }

ZCS { ZIP, CITY, STATE } KEY { ZIP }

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

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

• В частности, при извлечении полного адреса для заданного в атрибуте NAME имени потребуется выполнить соединение (хотя явное выполнение этого со­единения можно заменить определением переменной-отношения NADDR как представления на базе переменных-отношений NSZ и ZCS). Иначе говоря, нор­

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

■ Функциональная зависимость { STREET, CITY, STATE } -» ZIP явно не пред­ставлена в этом макете, а поддерживается отдельно: либо декларативно (если в СУБД поддерживается декларативный язык указания ограничений целостно­сти, аналогичный языку, кратко описанному в главе 8), либо процедурно. На самом деле переменные-отношения NSZ и ZCS не являются независимыми в смысле определения Риссанена [11.6].

Глава

Дальнейшая нормализация: более высокие нормальные формы