    Глава 10 

    Дальнейшая нормализация: 1НФГ 2НФГ ЗНФГ НФБК 

    10.1. Введение 

    До сих пор в этой книге в качестве примера рассматривалась база данных 
поставщиков и деталей с приведенной ниже логической структурой, 

    S ( SI, SNAKE, STATUS, CITY ) PRIMARY KEY ( S# ) 
    P ( PI, PNAME, COLOR, WEIGHT, CITY ) PRIMARY KEY ( P# ) 
    SP ( Stt, PI, OTY ) 
    PRIMARY KEY ( Si, Pi ) 
    FOREIGN KEY ( S# ) REFERENCES S 
    FOREIGN KEY ( P# ) REFERENCES P 

    В принципе, каждая деталь является товаром, который поставляет 
определенный поставщик. Поэтому далее о поставке деталей мы будем говорить как 
о поставке определенных товаров, т.е. база данных поставщиков и деталей может 
служить базой данных поставщиков и товаров, которые они поставляют. 
    Теперь структура такой базы данных становится понятнее. В ней, очевидно, 
должны содержаться три отношения — S, P и SP, для которых заданы некоторые 
атрибуты, например: для товара — атрибут COLOR (цвет) в отношении Р, для 
города поставщика — CITY (город) в отношении S, для количества товаров — QTY 
(количество) в отношении SP и т.д. Но откуда это известно? Некоторый намек на 
ответ можно получить, изменяя определенным образом макет базы данных. 
Предположим, например, что атрибут CITY удален из отношения поставщиков S и 
добавлен к отношению поставок SP (хотя интуитивно это действие можно 
охарактеризовать как ошибочное, так как понятие "город поставщика" очевидным 
образом связано с поставщиками, а не с поставками). На рис. 10.1 показана 
таблица с образцами записей для такого измененного отношения поставок. (Чтобы 
избежать путаницы с обычным исходным отношением SP, измененное отношение будет 
далее обозначаться SCP, как и в главе 9.) 

    SCP 

    s#	CITY	P#	OTY 

    31	London	PI	300 
    SI	London	P2	200 
    SI	London	P3	400 
    SI	London	P4	200 
    SI	London	P5	100 
    SI	London	P6	100 
    S2	Paris	PI	300 
    S2	Paris	P2	400 
    S3	Paris	P2	200 
    S4	London	P2	200 
    S4	London	P4	300 
    S4	London	P5	400 
    
    
    Рис, 10.1. Таблица отношения SCP 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК   275 


    В приведенной таблице легко заметить один из недостатков такой 
организации, а именно ее избыточность. Конкретнее, в каждом кортеже отношения 
SCP для поставщика S1 содержится информация о том, что поставщик S1 находится 
в Лондоне; в каждом кортеже отношения SCP для поставщика S2 содержится 
информация о том, что поставщик S2 находится в Париже, и т.д. В общем 
информация о городе данного поставщика повторяется столько раз, сколько 
поставок имеет данный поставщик. Эта избыточность, в свою очередь, приводит к 
некоторым другим проблемам. Например, после обновления данных местонахождением 
поставщика S1 в одном из кортежей может быть указан Лондон, а в другом — 
Амстердам. Таким образом, для создания хорошего макета следует придерживаться 
принципа "по одному факту в одном месте" (т.е. избегать избыточности). 
Предметом дальнейшей нормализации будет всего лишь формализация подобных 
простых идей, однако это должна быть формализация, действительно имеющая 
большой практический смысл при проектирова нии базы данных. 
    Конечно, отношения в реляционной базе данных всегда нормализованы в том 
смысле, что содержат только "скалярные" значения. (Определение понятия 
"скалярный" в этом смысле будет дано в последующих главах книги.) На рис. 4.5 
в главе 4 показан пример приведения ненормализованного отношения к 
эквивалентной нормализованной форме. Однако некоторое отношение может быть 
нормализовано в этом смысле и все еще обладать некоторыми нежелательными 
свойствами, например отношение SCP, показанное на рис. 10.1. Принципы 
дальнейшей нормализации позволяют распознать подобные случаи и свести такие 
отношения к более приемлемой форме. В примере с отношением SCP эти принципы 
позволили бы найти недостатки отношения и указать на необходимость его 
разбиения на два "более приемлемых" отношения: одно с атрибутами {S#, CITY}, а 
другое с атрибутами {S#, P#, QTY}. 

    Нормальные формы 

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

    Пространство отношений (нормализованных и ненормализованных) 

    Отношения в 1НФ (нормализованные отношения) 
    Отношения в 2НФ 
    
    Отношения в ЗНФ 
    Этношения в НФБК 
    Отношения в 4НФ 
    Отношения в 5НФ 
    
    
    Рис. 10.2. Нормальные формы 

    На рис. 10.2 показано несколько нормальных форм, которые определены к 
настоящему времени. Первые три (1НФ, 2НФ, ЗНФ) были определены Коддом (Codd) 
[9.4]. Как показано на рис. 10.2, все нормализованные отношения находятся в 1НФ, 

    276     Часть III. Проектирование базы данных 

    некоторые отношения 1НФ находятся также в 2НФ и некоторые отношения 2НФ 
находятся также в ЗНФ. Мотивом для введения дополнительных определений было 
то, что вторая нормальная форма "более желательна" (в смысле, который будет 
разъяснен позже), чем первая, а третья, в свою очередь, "более желательна", 
чем вторая. Таким образом, при проектировании базы данных вообще следует 
использовать отношения не только в первой или во второй, но также и в третьей форме. 
    В [9.4] также приводится описание процедуры нормализации, с помощью 
которой отношение заданной формы, например 2НФ, может быть преобразовано в 
множество отношений в другой, более желательной, нормальной форме, например 
ЗНФ. (В исходном варианте эта процедура определена только до третьей формы, 
но, как будет показано дальше в этой главе, она может быть последовательно 
расширена до пятой формы.) Такую процедуру можно охарактеризовать как 
последовательное приведение данного набора отношений к некоторой более 
желательной форме. Эта процедура обратима, т.е. всегда можно использовать ее 
результат (например, множество отношений, находящихся в ЗНФ) для обратного 
преобразования (в исходное отношение, находящееся в 2НФ). Возможность 
выполнения обратного преобразования является весьма важной характеристикой, 
поскольку означает, что в процессе нормализации информация не утрачивается. 
    Как будет показано ниже в этой главе, оригинальное определение Кодда для 
ЗНФ [9.4] приводит к некоторой неадекватности. Переработанное и более точное 
понятие, данное Бойсом (Воусе) и Коддом в [10.2], является более строгим в том 
смысле, что любое отношение в ЗНФ по новому определению является таковым и по 
старому определению, но не всякое отношение в ЗНФ по старому определению может 
являться таковым по новому определению. Для того чтобы эти определения можно 
было различать, отношение в ЗНФ по новому определению обычно называют 
нормальной формой Бойса-Кодда — НФБК. 
    Впоследствии Фейгином (Fagin) в [11.8] была определена новая, четвертая 
нормальная форма (4НФ), которая стала четвертой по счету, поскольку в момент 
ее создания нормальная форма Бойса-Кодда считалась третьей. Совсем недавно 
Фейгин в [11.9] дал определение еще одной нормальной формы, которую он назвал 
проективно-соединителъной нормальной формой', она также называется пятой 
нормальной формой, или ЗНФ. Как показано на рис. 10.2, некоторые отношения в 
НФБК также находятся в 4НФ, а некоторые отношения в 4НФ также находятся в 5НФ. 
    Возникает вопрос, нельзя ли продлить эту операцию дальше для получения 
шестой нормальной формы, седьмой и так до бесконечности. К ответу на этот 
вопрос мы вернемся в главе 11, а пока следует заметить, что действительно 
существуют дополнительные нормальные формы, которые не показаны на рис. 10.2. 
Здесь же ЗНФ в некотором (и очень важном) смысле рассматривается как 
"окончательная" нормальная форма. 

    Структура главы 

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

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	277 

    Важно отметить, что далее изложение ведется с меньшей строгостью и в 
рассуждениях автор в основном полагается на интуицию. Подобный подход может 
быть оправдан тем, что такие понятия, как декомпозиция без потерь, нормальная 
форма Бой-са-Кодда и другие, несмотря на их таинственные и загадочные 
названия, весьма просты и общедоступны. Во многих работах, на которые имеются 
ссылки, этот материал излагается в более строгой форме. 
    Кроме того, следует сделать еще два вводных замечания. 
    1.  Как уже отмечалось, общая идея нормализации заключается в том, чтобы 
при проектировании базы данных предполагалось использование отношений в 
"окончательной" нормальной форме (т.е. в пятой). Однако эту рекомендацию не 
следует толковать как обязательное правило, поскольку возможны ситуации, когда 
принципами нормализации необходимо пренебречь (об этом упоминается в 
упражнениях в конце главы). Однако очень важно, чтобы отношения находились, по 
крайней мере, в первой нормальной форме. Действительно, здесь следует 
подчеркнуть, что проектирование базы данных может представлять собой 
чрезвычайно сложную задачу (по крайне мере, в "достаточно большой базе 
данных", поскольку макеты "малых" баз данных обычно очень просты). 
Нормализация значительно упрощает этот процесс, но не является панацеей. Хотя 
составителю макета базы данных рекомендуется знать основные принципы 
нормализации, это не значит, что макет обязательно должен быть создан на 
основе одних только принципов нормализации. В главе 12 обсуждается несколько 
аспектов проектирования базы данных, которые имеют весьма отдаленное отношение 
или совсем не имеют отношения к нормализации как таковой. 
    2.   Как упоминалось выше, процедура нормализации будет использована в 
качестве основы при описании различных нормальных форм. Однако это не значит, 
что на практике создание макета базы данных будет выполняться с помощью этой 
процедуры. На самом деле, скорее всего, для этого будет использована описанная 
в главе 12 схема типа "сверху вниз". Затем идеи нормализации можно 
использовать для проверки того, чтобы полученный в результате макет 
непроизвольно не нарушал никаких принципов нормализации. Тем не менее, 
процедура нормализации является удобным способом представления этих принципов. 
Для упрощения изложения в данной главе будет сделано полезное допущение о том, 
что проектирование выполняется с помощью процедуры нормализации. 
    10.2. Декомпозиция без потерь и функциональные зависимости 
    Прежде чем приступить к рассмотрению подробностей процедуры нормализации, 
следует обсудить один существенный аспект этой процедуры, а именно концепцию 
декомпозиции без потерь. Как уже упоминалось, процедура нормализации включает 
разбиение, или декомпозицию данного отношения на другие отношения, причем 
декомпозиция должна быть обратимой, т.е. выполняться без потерь информации. 
Иначе говоря, интерес представляют только те операции, которые выполняются без 
потерь информации. Вопрос о том, происходит ли утрата информации при 
декомпозиции, тесно связан с концепцией функциональной зависимости. 
    В качестве примера рассмотрим уже знакомое отношение поставщиков S с 
атрибутами {S#, STATUS, CITY} (для упрощения задачи атрибут SNAME в данном 
случае игнорируется). На рис. 10.3 показан пример записей этого отношения 
(некоторое подмножество, приводимых ранее значений этого примера) с указанием 
двух его возможных декомпозиций: (а) и (б). 
    Внимательно ознакомившись с этими декомпозициями, можно заметить две особенности. 
    1. В случае (а) информация не утрачивается, поскольку отношения SST и SC 
все еще содержат данные о том, что поставщик S3 имеет статус 30 и находится в 
Париже (Paris), а поставщик S5 имеет статус 30 и находится в Афинах (Athens). 
Иначе говоря, первая декомпозиция действительно является декомпозицией без потерь. 

    278	Часть III. Проектирование базы данных 

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

    S 
    Si	STATUS     CITY 
    S3 S5	30         Paris 30        Athens 
    
    
    a)   SST			sc 
    SI	STATUS				S#    CITY 
    S3 S5	30 30				S3    Paris S5    Athens 
    
    
    б)   SST			STC 
    Stt	STATUS				STATUS     | CITY 
    S3 S5	30 30				30         Paris 30         Athens 
    
    
    Рис. 10.3. Отношение S и две его возможные декомпозиции 

    Почему получилось так, что одна декомпозиция происходит без потерь, а 
другая — с потерей информации? Прежде всего, следует отметить, что процесс, 
который до сих пор назывался "декомпозицией", на самом деле является 
проектированием, т.е. каждое из показанных на рис. 10.3 отношений— SST, SC и 
STC — в действительности является проекцией исходного отношения S. Таким 
образом, оператор декомпозиции в процедуре нормализации фактически является 
оператором проектирования. 
    Обратите внимание, что в случае (а) сохранение информации в полном объеме 
означает, что при обратном соединении отношений SST и SC будет получено 
исходное отношение S. В случае (б), наоборот, при обратном соединении 
отношений SST и SC не будет получено исходное отношение S, а это значит, что 
некоторая информация будет утрачена. (Точнее, в исходном отношении S вместе со 
всеми кортежами будут содержаться "ложные" кортежи. Поскольку не существует 
общего метода для различения ложных и подлинных кортежей, информация в этом 
случае будет утеряна.) Иначе говоря, "обратимость" означает, что исходное 
отношение равно соединению его проекций. Если оператором декомпозиции в 
процедуре нормализации является операция проектирования, то обратной операцией 
должна быть операция соединения (конечно, в смысле естественного соединения по 
атрибутам с общими именами). 
    Исходя из сказанного выше, можно задать следующий вопрос. Пусть R1 и R2 — 
проекции некоторого отношения R, содержащие все атрибуты отношения R. Какие 
условия должны быть соблюдены для того, чтобы при обратном соединении R1 и R2 
гарантировать получение исходного отношения R7 Именно для ответа на этот 
вопрос и возникает необходимость использования функциональных зависимостей. В 
рассматриваемом примере отношение S удовлетворяет представленному ниже 
неприводимому множеству ФЗ. (Далее в этой главе будет считаться, что ФЗ 
независимы от времени, т.е. выполняются для всех допустимых значений 
соответствующего отношения. Подробнее неприводимые множества ФЗ описаны в 
главе 9.) 

    S# -» STATUS S# -> CITY 

    При условии, что данное отношение удовлетворяет приведенным ФЗ, можно 
предположить, что отношение S равно соединению его проекций {S#, STATUS} и 
{S#, CITY}. И это действительно так, что подтверждается теоремой Хеза (Heath) [10.4]. 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 279 

    •  Теорема Хеза. Пусть R{A, В, С} является отношением, где А, В и С— 
атрибуты этого отношения. Если R удовлетворяет зависимости А —> В, то R равно 
соединению его проекций {А, В} и {А, С}. 
    Если обозначить А как S#, В как STATUS, С как CITY, то эта теорема 
утверждает, как уже отмечалось выше, что отношение S может быть разбито с 
помощью операции декомпозиции на проекции {S#, STATUS} и {S#, CITY} без утраты информации. 
    В то же время уже известно, что отношение S не может быть разбито без 
потери информации на проекции {S#, STATUS} и {STATUS, CITY}. Теорема Хеза не 
дает объяснения, почему так происходит. (Дело в том, что она формулируется как 
"если..., то...", а не "тогда и только тогда, когда...". Об этом также идет 
речь в упражнениях в конце главы. Более строгая формулировка теоремы Хеза 
будет представлена в главе 11.) Однако интуитивно можно предположить, что при 
такой декомпозиции утрачивается одна из функциональных зависимостей, т.е. 
зависимость S# —> STATUS еще будет присутствовать (благодаря проекции {S#, 
STATUS}), а зависимость S# -» CITY будет утрачена. 

    Еще о функциональных зависимостях 

    В завершение перечислим некоторые дополнительные замечания, касающиеся ФЗ. 
    1. Неприводимые слева ФЗ. Согласно главе 9 функциональная зависимость 
называется неприводимой слева, если ее левая часть "не очень велика". 
Рассмотрим, например, отношение SCP, приведенное выше в этой главе, которое 
удовлетворяет следующей ФЗ: 
    {   S#,   Р#   }  -» CITY 
    Однако атрибут Р# в левой части является избыточным для этой ФЗ, и она 
может быть переписана: 
    S# -» CITY 
    (Атрибут CITY функционально зависит от S#.) Эта последняя ФЗ является 
неприводимой слева. Таким образом, можно сказать, что атрибут CITY неприводимо 
зависим от S#, но не неприводимо зависим от {S#, P#}. (Здесь термины 
"неприводимо зависим" и "неприводимая слева ФЗ" используются вместо терминов 
"полная ФЗ" и "полностью зависимая", которые часто можно встретить в 
литературе и прежних изданиях этой книги. Хотя последние термины отличаются 
краткостью, они менее информативны и потому не очень удобны.) 
    Неприводимые слева ФЗ и неприводимые зависимости играют важную роль для 
определения второй и третьей нормальной формы (подробнее это обсуждается в 
разделе 10.3). 
    
    
    PNAME 
    SNAME 
    COLOR 
    s#			STATUS					QTY		P# 
    
    
    WEIGHT 
    CITY			•    ТГ							CITY 
    
    
    
    
    Рис. 10,4. Диаграмма ФЗ для отношений S, SP и Р 

    Диаграммы ФЗ (также называются схемами ФЗ). Пусть дано отношение R и 
некоторое неприводимое множество зависимостей / для этого отношения, которое 
можно представить в виде диаграммы функциональных зависимостей (диаграммы ФЗ). 
На рис. 10.4 показаны достаточно понятные по построению диаграммы ФЗ для 
отношений S, SP и Р соответственно. Такие диаграммы будут часто использоваться 
далее в этой главе. 

    280 Часть III. Проектирование базы данных 

    Как видно из рис. 10.4, каждая стрелка начинается с потенциального ключа 
(на самом деле с первичного ключа) соответствующего отношения. По определению 
стрелки должны начинаться с каждого потенциального ключа, поскольку одному 
значению такого ключа всегда соответствует, по крайней мере, еще одно какое-то 
значение. Некоторые стрелки следовало бы исключить ввиду того, что они 
вызывают определенные трудности, но стрелки, начинающиеся с потенциальных 
ключей, никогда не могут быть исключены. Таким образом, процедуру нормализации 
можно было бы неформально охарактеризовать как процедуру исключения стрелок, 
которые не начинаются с потенциальных ключей. 
    3.  ФЗ как семантическое понятие. Конечно, ФЗ— это особый вид ограничений 
целостности, а потому это, несомненно, семантическое понятие. Распознавание ФЗ 
является частью процесса выяснения смысла тех или иных данных, ведь если 
отношение S удовлетворяет зависимости S# —> CITY, это значит, что каждый 
поставщик находится точно в одном городе. Иначе эту ситуацию можно 
охарактеризовать следующим образом. 
    • В реальном мире существует некоторое ограничение, представленное в этой 
базе данных, а именно: каждый поставщик находится точно в одном городе. 
    • Поскольку это ограничение является частью семантики, оно должно быть 
каким-то образом представлено в базе данных. 
    • Для этого ограничение следует задать в определении базы данных таким 
образом, чтобы оно могло быть приведено в действие в СУБД. 
    • Способом задания ограничения в определении базы данных является 
объявление ФЗ. 
    Как будет показано ниже, концепции нормализации приводят к весьма простым 
способам объявления ФЗ. 

    10.3. Первая, вторая и третья нормальные формы 

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

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	281 

    •  Два или несколько атрибутов называются взаимно независимыми, если ни 
один из них не зависит функционально от какой-либо комбинации остальных 
атрибутов. Подобная независимость подразумевает, что каждый такой атрибут 
может быть обновлен независимо от остальных. 
    Например, отношение Р (отношение товаров) находится в ЗНФ согласно 
следующему определению: атрибуты PNAME (название товара), COLOR (цвет), WEIGHT 
(вес) и CITY (город) независимы (т.е. у товаров можно менять цвета без 
изменения их веса) и неприводимо зависимы по отношению к первичному ключу Р#. 
    Такое неформальное определение ЗНФ может быть интерпретировано в следующей 
более интуитивной форме. 
    •  Отношение находится в третьей нормальной форме тогда и только тогда, 
когда каждый кортеж состоит из значения первичного ключа, которое 
идентифицирует некоторую сущность, и набора пустых значений или значений 
взаимно независимых атрибутов, некоторым образом описывающих эту сущность. 
    К отношению Р применимо и это определение, так как каждый кортеж отношения 
Р состоит из значения первичного ключа (номер товара), идентифицирующего 
некоторый товар реального мира, и четырех дополнительных взаимно независимых 
значений (название товара, цвет товара, вес товара и город, в котором 
находится этот товар). 
    Теперь можно вернуться к описанию процедуры нормализации и дать 
определение 1НФ. 
    •  Отношение находится в первой нормальной форме тогда и только тогда, 
когда все используемые домены содержат только скалярные значения. 
    В этом определении всего лишь утверждается, что любое нормализованное 
отношение находится в 1НФ. Однако отношение, которое находится только в 1НФ 
(т.е. не находится ни во второй, ни в третьей нормальной форме) обладает 
структурой, по некоторым причинам не совсем желательной. Для иллюстрации этого 
факта допустим, что информация о поставщиках и поставках содержится не в двух 
отношениях S и SP, а в одном: 

    FIRST ( S#, STATUS, CITY, P#, QTY ) PRIMARY KEY ( S#, P# ) 

    Это расширенная версия приведенного выше отношения SCP с теми же обычными 
значениями атрибутов, за исключением следующего дополнительного ограничения: 

    CITY -> STATUS 

    (Атрибут STATUS функционально зависим от атрибута CITY; значение этого 
ограничения состоит в том, что статус поставщика определяется его 
местонахождением, например все поставщики из Лондона должны иметь статус 20.) 
Кроме того, для упрощения изложения атрибут SNAME далее будет игнорироваться. 
Тогда первичным ключом отношения FIRST является комбинация {S#, P#}, а 
диаграмма ФЗ будет иметь вид, показанный на рис. 10.5. 

    CITY QTY Р# 
    STATUS 

    Рис. 10.5. Функциональные зависимости отношения FIRST 

    Обратите внимание, что эта диаграмма ФЗ "сложнее" диаграммы для отношения 
в ЗНФ. Как было сказано выше, в диаграмме ФЗ для отношения в ЗНФ стрелки начи

    282 Часть III. Проектирование базы данных 

    наются только с первичных ключей (взгляните на рис. 10.4). Тогда как в 
диаграмме ФЗ для отношения, которое не находится в ЗНФ (например, диаграмма 
отношения FIRST), с первичных ключей начинаются также дополнительные стрелки, 
которые и запутывают всю картину. Фактически в отношении FIRST нарушаются оба 
условия, (а) и (б), из приведенного выше определения ЗНФ, т.е. неключевые 
атрибуты не все взаимно независимы, поскольку атрибут STATUS зависит от 
атрибута CITY (одна дополнительная стрелка), и не все неприводимо зависимы от 
первичного ключа, поскольку атрибуты STATUS и CITY каждый в отдельности 
зависимы от атрибута S# (еще две дополнительные стрелки). 
    Для иллюстрации некоторых трудностей, порождаемых этими стрелками, на рис. 
10.6 приведена таблица данных для отношения FIRST. Эти значения показаны в 
обычном виде, за исключением того, что статус поставщика S3 изменен со 
значения 30 на значение 10, чтобы удовлетворить новому ограничению, согласно 
которому значение атрибута CITY определяет значение атрибута STATUS. Таким 
образом, избыточность очевидна, поскольку в каждом кортеже для поставщика S1 
указано значение London для атрибута CITY и, кроме того, в каждом кортеже для 
значения London указано значение 20 для атрибута STATUS. 

    FIRST 
    S#	STATUS	CITY	P#	QTY 
    SI	20	London	PI	300 
    SI	20	London	P2	200 
    SI	20	London	P3	400 
    SI	20	London	P4	200 
    SI	20	London	P5	100 
    SI	20	London	P6	100 
    S2	10	Paris	PI	300 
    S2	10	Paris	P2	400 
    S3	10	Paris	P2	200 
    S4	20	London	P2	200 
    34	20	London	P4	300 
    S4	20	London	P5	400 
    
    
    Рис. 10.6. Таблица данных отношения FIRST 

    Избыточность в отношении FIRST приводит к разным аномалиям обновления, 
получившим такое название по историческим причинам, т.е. к трудностям при 
выполнении операций обновления типа INSERT (вставка), DELETE (удаление) и 
UPDATE (обновление). Для начала рассмотрим избыточность типа поставщик-город, 
соответствующую функциональной зависимости S# -> CITY, и перечисленные ниже 
проблемы с операциями обновления. 
    •   INSERT. Нельзя вставить данные о том, что некоторый поставщик 
находится в некотором городе, не указывая хотя бы один товар, поставляемый 
этим поставщиком. Действительно, в таблице на рис. 10.6 не показан поставщик 
S5 из Афин потому, что до тех пор, пока этот поставщик не поставляет некоторый 
товар, для него не задано значение первичного ключа. (Здесь предполагается, 
что на отношение FIRST наложено соответствующее ограничение целостности, более 
подробно описанное в главе 5.) 
    •   DELETE. Если удалить только один кортеж отношения FIRST для некоторого 
поставщика, при этом будет удалена не только информация о поставке товара 
некоторым поставщиком, но также и информация о том, что этот поставщик 
находится в некотором городе. Например, если в отношении FIRST удалить кортеж 
со значением S3 атрибута S# и значением Р2 атрибута Р#, будет утрачена 
информация о том, что поставщик S3 находится в Париже. (Образно говоря, 
удаление и вставка в некотором смысле обратные стороны одной медали.) 

    Глава 10. Дальнейшая нормализация; 1НФ, 2НФ, ЗНФ, НФБК 283 

    Замечание. В действительности проблема заключается в том, что в отношении 
FIRST содержится очень много совместной информации, поэтому при удалении 
некоторого кортежа приходится удалять слишком много другой информации. А 
точнее, отношение FIRST содержит информацию о поставках и информацию о 
поставщиках. Таким образом, удаление информации о поставке вызывает также 
удаление информации о поставщике. Для решения этой проблемы нужно разделить 
информацию на несколько частей, т.е. разместить информацию о поставках в одном 
отношении, а о поставщиках — в другом (как раз этому и посвящен данный 
раздел). Таким образом, неформально процедуру нормализации можно 
охарактеризовать как процедуру разбиения логически несвязанной информации по 
отдельным отношениям. 
    •   UPDATE. Название города для определенного поставщика повторяется в 
отношении FIRST множество раз, и это приводит к возникновению проблем при 
обновлении. Например, если поставщик S1 переместится из Лондона в Амстердам, 
то возникает проблема, связанная либо с поиском в отношении FIRST всех 
кортежей, в которых соединены S1 и Лондон (для внесения соответствующих 
изменений), либо с получением несовместимого результата (в одном кортеже 
городом поставщика SI будет Лондон, а в другом — Амстердам). 
    Для решения этой проблемы, как уже упоминалось, нужно заменить отношение 
FIRST двумя следующими: 

    SECOND { S#, STATUS, CITY } SP { S#, P#, QTY } 

    Диаграммы ФЗ для этих двух отношений показаны на рис. 10.7, а таблицы 
данных — на рис. 10.8. Обратите внимание, что теперь в них включена информация 
о поставщике S5 (в отношение SECOND, но не в отношение SP), а отношение SP 
теперь точно совпадает с отношением поставок. 

    QTY 

    Рис. 10.7.   Функциональные  зависимости  отношений SECOND и SP 

    SECOND				SP 
    S#	STATUS	CITY		S#	P#	QTY 
    SI	20	London		SI	PI	300 
    S2	10	Paris		SI	P2	200 
    S3	10	Paris		SI	P3	400 
    S4	20	London		SI	P4	200 
    S5	30	Athens		SI	P5	100 
    SI	P6	100 
    S2	PI	300 
    S2	P2	400 
    S3	P2	200 
    S4	P2	200 
    S4	P4	300 
    S4	P5	400 
    
    
    Рис. 10.8. Примеры данных для отношений SECOND и SP 

    284 Часть III. Проектирование базы данных 

    Важно отметить, что переработанная таким образом структура позволяет 
преодолеть все перечисленные ранее проблемы, связанные с операциями обновления. 
    •   INSERT. Теперь с помощью вставки соответствующего кортежа в отношение 
SECOND можно включить информацию о том, что поставщик S5 находится в Афинах, 
даже если он в настоящий момент не поставляет никаких товаров. 
    •   DELETE. Теперь можно исключить информацию о поставке, в которой 
соединены сведения о поставщике S3 и о товаре Р2, удаляя соответствующий 
кортеж из отношения SP, при этом информация о том, что поставщик S3 находится 
в Париже, не утрачивается. 
    •   UPDATE. В переработанной структуре название города для каждого 
поставщика появляется всего один раз, поскольку существует только один кортеж 
для данного поставщика в отношении SECOND (атрибут S# является первичным 
ключом для такого отношения). Иначе говоря, избыточность данных S#-CITY 
устранена. Благодаря этому теперь можно раз и навсегда изменить в 
соответствующем кортеже отношения SECOND название города для поставщика S1, 
например вместо Лондона задать Амстердам. 
    Сравнивая рис. 10.7 и 10.5, можно заметить, что суть разбиения отношения 
FIRST на отношения SECOND и SP состоит в исключении зависимостей, которые не 
были неприводимыми, и именно благодаря этому удается избежать упомянутых ранее 
трудностей. Интуитивно можно сказать, что в отношении FIRST с помощью атрибута 
CITY описывается не сущность, идентифицируемая первичным ключом (поставка), а 
поставщик, выполняющий эту поставку (аналогичное утверждение можно сделать и 
об атрибуте STATUS). Перемешивание двух этих типов информации в одном и том же 
отношении и стало причиной возникновения указанных ранее проблем. 
    Теперь пришло время определить 2НФ при условии, что существует только один 
потенциальный ключ, который является первичным ключом. 
    •  Отношение находится во второй нормальной форме тогда и только тогда, 
когда оно находится в первой нормальной форме и каждый неключевой атрибут 
неприводимо зависим от первичного ключа. 
    Оба отношения, SECOND и SP, находятся во второй нормальной форме с 
первичными ключами S# и {S#, P#} соответственно, а отношение FIRST не 
находится в ней. Всякое отношение, которое находится в 1НФ и не находится в 
2НФ, всегда можно свести к эквивалентному набору отношений, находящихся в 2НФ. 
    Этот процесс заключается в замене отношения в 1НФ подходящим набором 
проекций, эквивалентных исходному отношению в том смысле, что его можно 
восстанавливать с помощью обратного соединения этих проекций. В данном примере 
отношения SECOND и SP — проекции отношения FIRST, которое является соединением 
отношений SECOND и SP по атрибуту S#. (За исключением того факта, что 
отношение SECOND может содержать кортежи, например, такого типа, как кортеж 
для поставщика S5, который не имеет аналога в отношении FIRST (см. рис. 10.8). 
Иначе говоря, новая структура может даже содержать информацию, которую 
невозможно представить в исходной структуре. В этом смысле новую структуру 
можно рассматривать как более правдоподобное представление реального мира.) 
    Таким образом, первым этапом процедуры нормализации является создание 
проекций для исключения "приводимых" функциональных зависимостей. 
    Рассмотрим в качестве примера приведенное ниже отношение R: 

    R ( А, В, С, D ) 
    PRIMARY KEY ( Л, В )         /* Первичный ключ */ А -» В 

    Согласно порядку нормализации это отношение следует заменить двумя 
проекциями, R1 и R2: 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	285 

    Rl ( A, D ) 
    PRIMARY KEY ( A )	/* Первичный клют */ 
    R2 ( А, В, С } 
    PRIMARY KEY ( А, В )	/* Первичный ключ */ FOREIGN KEY ( Л ) REFERENCES Rl  

     /* Внешний ключ */ 

    Отношение R может быть восстановлено с помощью соединения отношений R1 и 
R2 по внешнему и совпадающему с ним первичному ключу этих отношений. 
    Однако структура отношений SECOND-SP все еще может вызвать некоторые 
проблемы. Что касается отношения SP, оно вполне удовлетворительно, находится в 
ЗНФ и потому останется без изменений до конца этого раздела. С другой стороны, 
неключевые атрибуты в отношении SECOND не являются взаимно независимыми. 
Диаграмма ФЗ для отношения SECOND все еще остается "более сложной", чем 
диаграмма ФЗ для отношения в ЗНФ. В частности, зависимость атрибута STATUS от 
атрибута S# хотя и является функциональной и действительно неприводимой, она 
также транзитивна (через атрибут CITY), т.е. каждое значение S# определяет 
значение CITY, а значение CITY, в свою очередь, определяет значение STATUS. В 
общем, как уже объяснялось в главе 9, если выполняются обе зависимости А -> В 
и В -> С, то выполняется также зависимость А —> С. Таким образом, транзитивные 
зависимости могут опять привести к перечисленным ниже аномалиям обновления. 
(Здесь основное внимание будет сосредоточено на избыточности данных типа 
город-статус, соответствующей функцион альной зависимости CITY -» STATUS.) 
    •  INSERT. Нельзя включить данные о некотором городе, обладающем некоторым 
статусом, например, нельзя указать, что все поставщики из Рима обладают 
статусом 50, до тех пор пока в этом городе не существует некоторого 
конкретного поставщика (здесь вновь предполагается, что задано некое правило с 
ограничением целостности). 
    •   DELETE. При удалении из отношения SECOND кортежа для некоторого города 
будет удалена не только информация о данном поставщике, но также информация о 
том, каким статусом обладал этот город. Например, при удалении из отношения 
SECOND кортежа для поставщика S5 будет утрачена информация о том, что для Афин 
был задан статус 30. (Здесь, образно говоря, операции вставки и удаления 
являются двумя сторонами одной медали.) 
    Замечание. Вновь причиной этих неприятностей является совместная 
информация: отношение SECOND содержит информацию о поставщиках и вместе с ней 
информацию о городах. Для разрешения этой ситуации следует поступить так, как 
и раньше, т.е. "разобрать" всю эту информацию и перенести в одно отношение 
сведения о поставщиках, а в другое — сведения о городах. 
    •   UPDATE. В отношении SECOND статус для каждого города повторяется 
несколько раз (поэтому оно все еще характеризуется некоторой избыточностью). 
Таким образом, при изменении значения статуса Лондона с 20 на 30 возникнет 
либо проблема необходимости поиска в отношении SECOND всех кортежей для 
Лондона (для внесения соответствующих изменений), либо проблема получения 
несовместимого результата (в одном кортеже статус для Лондона может быть равен 
20, а в другом — 30). 
    Вновь для решения этой проблемы нужно заменить исходное отношение SECOND 
двумя следующими проекциями: 

    SC { S#, CITY } 
    CS { CITY, STATUS } 

    Диаграммы ФЗ для этих двух отношений показаны на рис. 10.9, а таблицы 
данных— на рис. 10.10. Обратите внимание, что информация о статусе Рима (Rome) 
включена только в отношение CS. Данное преобразование обратимо, поскольку 
отношение SECOND является соединением отношений SC и CS по атрибуту CITY. 

    286	Часть III. Проектирование базы данных 

    Следует еще раз отметить, что переработанная структура позволяет 
преодолеть все описанные проблемы с операциями обновления. Читателю 
предлагается самостоятельно разобраться с подробностями решения этих проблем. 
Сравнивая рис. 10.9 и 10.7, можно заметить, что благодаря дальнейшей 
декомпозиции удалось исключить транзитивную зависимость атрибута STATUS от 
атрибута S# с разрешением всех существовавших до этого трудностей. Интуитивно 
можно утверждать, что атрибут STATUS в отношении SECOND описывает не сущность, 
идентифицируемую первичным ключом (т.е. поставщика), а город поставщика. 
Именно смешивание двух этих типов информации в одном отношении ранее приводило 
к описанным проблемам. 

    s# 
    CITY 

    Рис, 10.9. Функциональные зависимости в отношениях SC и CS 

    SC			CS 
    Stt	CITY		CITY	STATUS 
    31	London		Athens	30 
    52	Paris		London	20 
    S3	Paris		Paris	10 
    S4	London		Rome	50 
    S5	Athens 

    Рис. 10.10. Таблицы данных отношений SC и CS 

    Теперь можно дать определение для ЗНФ при условии, что существует только 
один потенциальный ключ, который также является первичным ключом. 
    •   Отношение находится в третьей нормальной форме тогда и только тогда, 
когда оно находится во второй нормальной форме и каждый неключевой атрибут 
нетранзитивно зависит от первичного ключа. (Под "нетранзитивной зависимостью" 
подразумевается отсутствие какой-либо взаимной зависимости в изложенном выше смысле.) 
    Отношения SC и CS находятся в ЗНФ, причем первичными ключами в них 
являются атрибуты S# и CITY соответственно, а отношение SECOND не находится в 
ЗНФ. Отношение, которое находится в 2НФ, но не находится в ЗНФ, всегда может 
быть приведено к эквивалентному набору отношений в ЗНФ. Как уже говорилось 
ранее, этот процесс обратим и, следовательно, никакая информация при таком 
приведении не утрачивается. Однако в ЗНФ может содержаться такая информация 
(например, статус Рима равен 50), которая не может быть представлена в 
исходном отношении в 2НФ. (Отсюда следует, что если комбинация отношений 
SECOND-SP может рассматриваться как более правдоподобное представление 
реального мира, чем отношение FIRST, то и комбинация отношений SC-CS 
правдоподобнее отношения SECOND, которое находится в 2НФ.) 
    Подводя итог, можно сказать, что вторым этапом нормализации является 
создание проекций для исключения транзитивных зависимостей. Рассмотрим в 
качестве примера отношение R: 

    R ( А, В, С ) 
    PRIMARY KEY ( A )        /* Первичный ключ */ В -» С 

    Согласно порядку нормализации это отношение следует заменить двумя 
проекциями, R] и R2: 

    R1 ( В, С ) 
    PRIMARY KEY ( В )	/* Первичный клкн */ 
    R2 ( А, В ) 
    PRIMARY KEY ( А )	/* Первичный клш */ FOREIGN KEY ( В ) REFERENCES Rl      
    /* Внешний ключ */ 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 287 

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

    10.4. Сохранение зависимости 

    В процессе приведения отношений часто возникают ситуации, когда данное 
отношение может быть подвергнуто операции декомпозиции разными способами. 
Рассмотрим снова приведенное выше отношение SECOND с функциональными 
зависимостями S# —> CITY, CITY —» STATUS и, следовательно, транзитивной 
зависимостью S# —> STATUS (на рис. 10.11 транзитивная зависимость показана 
пунктирной стрелкой). 
    
    
    CITY 
    1 
    s# 
    1		STATUS 
    
    
    
    Рис. 10.11. Функциональные зависимости в отношении SECOND 

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

    SC  {  S#,   CITY }	И           CS   { CITY,   STATUS  } 

    Назовем эту декомпозицию просто "декомпозицией А", имея в виду, что для 
нее существует альтернативная "декомпозиция fi": 

    SC   {  S#,   CITY }	И           S3   {   S#,   STATUS  } 

    При этом обе проекции SC одинаковы как для А, так и для В. Декомпозиция В 
происходит также без потери информации, а обе ее проекции находятся в ЗНФ. 
Однако по некоторым причинам декомпозиция В менее желательна, чем декомпозиция 
А. Например, после выполнения декомпозиции В все еще невозможно вставить 
информацию о том, что некоторый город имеет некоторый статус, без указания 
поставщика из этого города. 
    Рассмотрим этот пример подробнее. Прежде всего заметим, что зависимости 
проекций в декомпозиции А отмечены сплошными стрелками (см. рис. 10.11), тогда 
как одна из зависимостей проекций декомпозиции В отмечена пунктирной стрелкой. 
В декомпозиции А две проекции независимы друг от друга в следующем смысле: 
обновления в каждой из проекций могут быть выполнены совершенно независимо 
друг от друга. (Конечно, за исключением ограничения целостности для SC и CS.) 
Если такое обновление допустимо только в контексте данной проекции, т.е. не 
нарушается уникальность первичного ключа для этой проекции, то соединение этих 
двух проекций после обновления всегда будет равносильно отношению SECOND (т.е. 
при соединении не будут нарушены ограничения, наложенные на ФЗ в отношении 
SECOND). В декомпозиции В, 

    288	Часть III. Проектирование базы данных 

    наоборот, обновление любой из двух проекций должно тщательно 
фиксироваться, чтобы гарантировать отсутствие нарушения зависимости CITY —> 
STATUS (если два поставщика находятся в одном и том же городе, они должны 
иметь одинаковый статус; в качестве примера разберите случай, когда в 
декомпозиции В поставщик S1 переместится из Лондона в Париж). Иначе говоря, 
обе проекции декомпозиции В не являются независимыми одна от другой. 
    Основная проблема заключается в том, что в декомпозиции В функциональная 
зависимость CITY —> STATUS становится ограничением между отношениями. (Следует 
отметить, что во многих современных программных продуктах это ограничение 
должно поддерживаться с помощью процедурной обработки.) В декомпозиции А, 
наоборот, транзитивная зависимость S# —» STATUS является ограничением между 
отношениями, которое автоматически выполняется при задействовании двух 
ограничений внутри отношений: S# -> STATUS и CITY —> STATUS. Привести в 
действие эти ограничения достаточно просто за счет соответствующих 
ограничений, наложенных на уникальность первичных ключей. 
    Концепция независимых проекций, таким образом, обеспечивает критерий 
выбора одной из нескольких возможных декомпозиций. Декомпозиция с независимыми 
проекциями в приведенном выше общем смысле предпочтительнее той, в которой 
проекции зависимы. Риссанен (Rissanen) [10.6] показал, что проекции R1 и R2 
отношения R независимы в упомянутом выше смысле тогда и только тогда, когда 
    •   каждая ФЗ в отношении R является логическим следствием функциональных 
зависимостей в проекциях R1 и /?2; 
    •   общие атрибуты проекций RJ и R2 образуют потенциальный ключ, по 
крайней мере, для одной из них. 
    Рассмотрим заданные выше декомпозиции А и В. В декомпозиции А две проекции 
независимы, поскольку их общий атрибут CITY является первичным ключом для 
отношения CS и каждая ФЗ отношения SECOND либо находится в одной из проекций, 
либо является логическим следствием имеющихся. В декомпозиции В, наоборот, две 
проекции не являются независимыми, поскольку зависимость CITY -> STATUS не 
может быть выведена из ФЗ этих проекций, хотя их общий атрибут S# является 
потенциальным ключом для обеих проекций. 
    (Следует отметить, что третий вариант декомпозиции с заменой отношения 
SECOND проекциями {S#, STATUS} и {CITY, STATUS} не является допустимой 
декомпозицией, поскольку выполняется с потерей информации. Упражнение. 
Докажите это утверждение.) 
    Терминология. Отношение, которое не может быть подвергнуто декомпозиции с 
получением независимых проекций, называется атомарным [10.6]. Однако это не 
значит, что любое неатомарное отношение может быть разбито на атомарные 
компоненты. Например, отношения S и Р из рассматриваемой ранее базы данных 
поставщиков и товаров (поставщиков и деталей) не являются атомарными, но 
дальнейшая их декомпозиция была бы бессмысленной. Отношение SP, наоборот, 
является атомарным. 
    Идея нормализации с декомпозицией на независимые проекции (в смысле 
Рисса-нена) называется декомпозицией с сохранением зависимости. В заключение 
следует привести несколько более строгих замечаний по поводу этой идеи. 
    1.  Пусть дано некоторое отношение R, которое после выполнения всех этапов 
процедуры нормализации заменяется множеством отношений Rl, R2,... Rn (конечно, 
все они являются проекциями отношения R). 
    2.  Пусть также задано множество зависимостей S для исходного отношения R, 
и множества зависимостей SI, S2,... Sn для отношений Rl, R2,... Rn. 
    3.  Каждая ФЗ множества Si будет относиться только к атрибутам множества 
Ri (/=1, 2, 3, ..., п). Таким образом, приведение в действие ограничений (ФЗ) 
в лю

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	


289 10 Введение в системы баз данных 

    бом заданном множестве Si представляется достаточно простой задачей. 
Однако в данном случае необходимо задействовать ограничения из исходного 
множества S. При этом следовало бы выбрать такую декомпозицию на отношения R], 
R2, ... Rn, для которой совместное приведение в действие отдельных множеств 
ограничений SI, S2, ... Sn эквивалентно приведению в действие ограничений в 
исходном множестве S. Иначе говоря, декомпозиция должна выполняться с 
сохранением зависимостей. 
    4.   Пусть S' является объединением множеств зависимостей SI, S2, ... Sn. 
Обратите внимание, что в общем случае равенство S'=S не выполняется, однако 
для выполнения декомпозиции с сохранением зависимостей достаточно, чтобы 
замыкания S и S' были равны друг другу (понятие замыкания множества ФЗ 
рассматривалось в главе 9). 
    5.   В общем случае не существует эффективного способа вычисления 
замыкания S множества ФЗ, поэтому вычисление и сравнение двух замыканий 
трудноосуществимо. Тем не менее, существует эффективный метод проверки, будет 
ли данная декомпозиция выполняться с сохранением зависимости. Описание 
подробностей этого алгоритма выходит за рамки данной книги, однако они 
описываются в книге Ульмана (Ullman) [7.16]. 
    Замечание. В ответах на упражнения в конце этой главы описан алгоритм 
выполнения декомпозиции без потерь и с сохранением зависимости для 
произвольного отношения с разбиением на множество проекций в ЗНФ. 

    10.5. Нормальная форма Бойса-Кодда 

    В этом разделе опускается упрощающее допущение о том, что каждое отношение 
имеет только один потенциальный ключ (а именно первичный ключ), и 
рассматривается достаточно общий случай. Дело в том, что оригинальное 
определение Кодда для ЗНФ [9.4] не совсем подходит для отношений с 
перечисленными ниже условиями. 
    1.	Отношение имеет два (или более) потенциальных ключа. 
    2.	Два потенциальных ключа являются сложными. 
    3.	Они перекрываются (т.е. имеют, по крайней мере, один общий атрибут). 
    Поэтому оригинальное определение ЗНФ было впоследствии заменено более 
строгим определением Бойса-Кодда (Boyce/Codd) [10.2], для которого было 
принято отдельное название — нормальная форма Бойса-Кодда, НФБК. (На самом 
деле строгое определение "третьей" нормальной формы, эквивалентное определению 
нормальной формы Бойса-Кодда, было впервые дано Хезом (Heath) в 1971 году 
[10.4], и этой форме следовало бы дать название "нормальная форма Хеза".) 
    Замечание. Комбинация условий 1, 2 и 3 не часто встречается на практике, и 
для отношения без этих условий ЗНФ и НФБК эквивалентны. 
    Для объяснения понятия НФБК потребуется использовать понятие детерминанта, 
введенное в главе 9 для левой части ФЗ, а также тривиальной функциональной 
зависимости, т.е. ФЗ, в которой левая часть является супермножеством правой части. 
    •  Отношение находится в нормальной форме Бойса-Кодда тогда и только 
тогда, когда каждая нетривиальная и неприводимая слева ФЗ обладает 
потенциальным ключом в качестве детерминанта. Менее формальное определение 
имеет другую формулировку. 
    •  Отношение находится в нормальной форме Бойса-Кодда тогда и только 
тогда, когда детерминанты являются потенциальными ключами. 
    Иначе говоря, на диаграмме ФЗ стрелки будут начинаться только с 
потенциальных ключей. Согласно данному определению никакие другие стрелки не 
допускаются и, следовательно, никакие стрелки не могут быть исключены с 
помощью процедуры нормализации. 

    290	Часть III. Проектирование базы данных 

    ' Замечание. Выражаясь более кратко и неформально, различие между двумя 
определениями НФБК заключается в том, что детерминанты "не очень велики" и все 
ФЗ нетривиальны. Для простоты изложения далее в этой главе будут использованы 
точно такие же допущения, за исключением особо оговоренных случаев. 
    Стоит отметить также, что определение НФБК концептуально проще, чем 
прежнее определение ЗНФ, поскольку в нем нет явных ссылок на первую и вторую 
нормальную форму, а также не используется концепция транзитивной зависимости. 
Кроме того, хотя (как уже отмечалось выше) определение НФБК является более 
строгим, чем определение ЗНФ, все же любое определенное отношение может быть 
подвергнуто декомпозиции без потерь информации в эквивалентный набор отношений 
в НФБК. 
    Прежде чем рассматривать примеры отношений с несколькими потенциальными 
ключами, убедимся, что отношения FIRST и SECOND, которые не находятся в ЗНФ, 
также не находятся и в НФБК. А также убедимся, что отношения SP, SC и CS, 
которые находятся в ЗНФ, находятся и в НФБК. Отношение FIRST содержит три 
детерминанта, а именно: S#, CITY и {S#, P#}, из которых только {S#, P#} 
является потенциальным ключом. Поэтому отношение FIRST не находится в НФБК. 
Аналогичное утверждение верно для отношения SECOND, поскольку детерминант CITY 
не является потенциальным ключом. Отношения SP, SC и CS, с другой стороны, 
находятся в НФБК, поскольку в каждом случае единственный потенциальный ключ 
является единственным детерминантом в этом отношении. 
    Теперь следует рассмотреть пример, включающий два неперекрывающихся 
потенциальных ключа. Допустим, что в отношении поставщиков 

    S   {   Stt,   SNAME,   STATUS,   CITY  } 

    атрибуты S# и SNAME являются потенциальными ключами (т.е. в этом случае 
каждый поставщик имеет уникальный номер и уникальное имя). Предположим, однако 
(как, впрочем, всюду в этой книге), что атрибуты STATUS и CITY совершенно 
независимы, т.е. введенная специально для частных целей предыдущих разделов 
функциональная зависимость CITY -> STATUS больше не выполняется. В этом случае 
диаграмма ФЗ будет иметь вид, показанный на рис. 10.12. 

    —— г^ 
    s#				STATUS I 
    
    
    SNAME				CITY 
    
    
    Рис. 10.12. Диаграмма функциональных зависимостей в отношении S, если 
атрибут SNAME является потенциальным ключом (зависимость CITY —» STATUS не выполняется) 

    Это отношение S находится в НФБК. Хотя данная диаграмма существенно 
"сложнее" диаграммы зависимостей для отношения в ЗНФ, тем не менее, в этом 
случае все детерминанты являются потенциальными ключами, а все стрелки 
начинаются с потенциальных ключей. Таким образом, иметь несколько 
потенциальных ключей не так уж и плохо. Однако желательно, чтобы атрибут SNAME 
был представлен как потенциальный ключ еще при определении базы данных, чтобы 
в СУБД было задействовано требуемое ограничение уникальности. После реализации 
всех перечисленных условий отношение S будет выглядеть так: 

    S { S#, SNAME, STATUS, CITY } CANDIDATE KEY { S# } CANDIDATE KEY { SNAME } 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 291 

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

    SSP  {  S#,   SNAME,   P#,   QTY  } 

    Потенциальными ключами в нем являются {S#, P#} и {SNAME, Р#}. Однако это 
отношение не находится в НФБК, так как содержит два детерминанта, S# и SNAME, 
которые не являются потенциальными ключами этого отношения (S# и SNAME — 
детерминанты, поскольку они определяют друг друга). Некоторые значения этого 
отношения SSP показаны на рис. 10.13. Как видно из этого рисунка, в отношении 
SSP содержится некоторая доля избыточности, присущая отношениям SCP, FIRST и 
SECOND из предыдущих разделов этой главы, поэтому оно характеризуется такими 
же аномалиями обновления. Например, изменение имени поставщика S1 точно так же 
приведет либо к выполнению поиска, либо к получению несовместимых результатов. 
К тому же, отношение SSP находится в ЗНФ, поскольку согласно старому 
определению не требуется, чтобы атрибут был неприводимо зависим от каждого 
потенциального ключа, если он сам является компонентом некоторого 
потенциального ключа данного отношения. Таким образом, тот факт, что атрибут 
SNAME приводимо завис им от {S#, P#}, игнорируе тся. (Под термином "ЗНФ" здесь 
подразумевается определение, данное Коддом в [9.4], а не упрощенное 
определение, данное выше в этой главе.) 
    
    
    SSP	s#	SNAME	P#	QTY 
    SI	Smith	PI	300 
    SI	Smith	P2	200 
    SI	Smith	P3	400 
    SI	Smith	P4	200 
    
    
    Рис. 10.13. Часть таблицы с данными для отношения SSP 

   Для решения проблемы отношение SSP следует разбить на две проекции: 

    S3   {  St,   SNAME  }  И  SP  {  S#,   Р#,   QTY  }. 

    Однако для разбиения можно выбрать также альтернативные проекции 

    SS   {   S#,   SNAME  }   И  SP   {   SNAME,   P#,   QTY  }. 

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

    292 Часть III. Проектирование базы данных 

    ципов здравого смысла, что, конечно же, весьма непростая задача. Однако 
если такая задача может быть выполнена, то такие принципы могут быть 
автоматизированы, т.е. можно написать программу для выполнения ее с помощью 
компьютера. Критики метода нормализации обычно упускают этот момент из виду, 
поскольку совершенно справедливо заявляют, что эти идеи в основном 
представляют собой всего лишь соображения здравого смысла. Однако при этом не 
принимается во внимание, что возможность формальной и строгой формулировки 
"соображений здравого смысла" сама по себе уже является значительным достижением. 
    Теперь вернемся к основной теме данного раздела и рассмотрим второй пример 
с перекрывающимися потенциальными ключами на основе отношения SJT с атрибутами 
S, J и Т, которые обозначают студента, предмет и преподавателя соответственно 
(следует предупредить, что это всего лишь пример, к тому же достаточно 
экзотический). Кортеж {S>:s, J:y, T:t} отношения SJT означает, что некоторый 
студент s обучается некоторому предмету у некоторым преподавателем /. При этом 
накладываются перечисленные ниже ограничения. 
    •   Каждый студент, изучающий данный предмет, обучается только одним преподавателем. 
    •   Каждый преподаватель ведет только один предмет (но каждый предмет 
может преподаваться несколькими преподавателями). 
    На рис. 10.14 показан пример таблицы этого отношения. 

    SJT 
    s	J	Т 
    Smith	Math	Prof. White 
    Smith	Physics	Prof. Green 
    Jones	Math	Prof. White 
    Jones	Physics	Prof . Brown 
    
    
    Рис. 10.14. Пример таблицы с данными для отношения SJT 

    Какие функциональные зависимости существуют в данном отношении? 
    Из первого ограничения следует зависимость атрибута Т от комбинации 
атрибутов {S, J}, а из второго — зависимость атрибута J от атрибута Т. 
Следовательно, диаграмма ФЗ будет иметь вид, показанный на рис. 10.15. 

    И
    И 

    Рис. 10.15. Диаграмма функциональных зависимостей отношения SJT 

    Опять в рассматриваемом примере есть два перекрывающихся потенциальных 
ключа, а именно: комбинация {S, J} и комбинация {S, Т}. Снова отношение 
находится в ЗНФ, а не в НФБК и характеризуется некоторыми аномалиями 
обновления. Например, если требуется удалить информацию о том, что Джонс 
(Jones) изучает физику, это нельзя будет сделать, не утрачивая информацию о 
том, что профессор Браун (Prof. Brown) преподает физику. Эти трудности вызваны 
тем, что Т является детерминантом, но не является потенциальным ключом. Опять 
для решения этой проблемы исходное отношение следует разбить на две проекции, 
которые находятся в НФБК: 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 293 

    ST  {  S,   Т }         И         TJ {  Т,   J } 

    Читателю предлагается в качестве упражнения составить таблицы данных для 
этих двух отношений, соответствующие данным из таблицы на рис. 10.14, 
нарисовать соответствующую диаграмму ФЗ для проверки того, что эти две 
проекции в действительности находятся в НФБК (какие атрибуты являются 
потенциальными ключами?), а также убедиться, что эта декомпозиция позволяет 
устранить все проблемы. 
    Нельзя не отметить тот факт, что, несмотря на разрешение некоторых проблем 
с помощью такой декомпозиции, к сожалению, она характеризуется другими 
трудностями. Дело в том, что две проекции, ST и TJ, не являются независимыми в 
смысле Риссанена (подробнее это обсуждалось выше в данной главе). Точнее 
говоря, ФЗ 

    {  S,   J }  -> Т 

    не может быть выведена из единственной ФЗ, которая присутствует в двух 
данных проекциях, 

    Т -» J. 

    В результате эти две проекции не могут быть обновлены независимо. 
Например, попытка вставить в отношение ST кортеж для Смита (Smith) и 
профессора Брауна (Prof. Brown) должна быть отвергнута, поскольку профессор 
Браун преподает физику, а Смит уже обучается физике у профессора Грина (Prof. 
Green). Однако обнаружить этот факт без проверки отношения TJ система не 
может. Таким образом, можно прийти к неприятному выводу, что две цели, а 
именно: декомпозиция отношения на отношения, находящиеся в НФБК, и 
декомпозиция на независимые компоненты, могут привести к конфликтной ситуации. 
Поэтому не всегда возможно удовлетворять обеим целям одновременно. 
    Замечание. В действительности отношение SJT является атомарным (атомарные 
отношения обсуждались выше в этой главе), даже если оно не находится в НФБК. 
Однако то, что атомарное отношение не может быть подвергнуто декомпозиции на 
независимые компоненты, не означает, что оно не может быть подвергнуто 
декомпозиции вовсе (где "декомпозиция" означает декомпозицию без потерь). 
"Атомарное отношение" — не совсем подходящий термин для этой концепции, по 
крайней мере с интуитивной точки зрения, так как такая атомарность не является 
ни необходимым, ни достаточным условием создания хорошего макета базы данных. 
    В третьем, и последнем, примере отношения с перекрывающимися 
потенциальными ключами рассмотрим отношение EXAM с атрибутами S (студент), J 
(предмет) и Р (место). Смысл кортежа {S>:s, i:j, Р:р} отношения EXAM 
заключается в том, что некоторый студент s экзаменуется по определенному 
предметуу и занимает определенное место р в списке. Допустим также следующее ограничение: 
    •  никакие два студента не могут занять одно и то же место в списке по 
одному и тому же предмету. 
    В таком случае диаграмма ФЗ будет такой, как на рис. 10.16. 

    Ш 

    Рис. 10.16. Диаграмма функциональных зависимостей в отношении EXAM 

    В этом примере опять появляются два перекрывающихся потенциальных ключа— 
{S, J} и {J, P}, поскольку для данного студента и предмета существует точно 
одно соответствующее им место в списке, а также для данного предмета и места в 

    294 Часть III. Проектирование базы данных 

    списке существует точно один соответствующий им студент. Однако такое 
отношение находится в НФБК, поскольку эти потенциальные ключи являются 
единственными детерминантами. Читатель может убедиться, что данное отношение 
не характеризуется аномалиями обновления, подобными упомянутым ранее в этой 
главе. Таким образом, наличие перекрывающихся потенциальных ключей не всегда 
приводит к возникновению проблем такого рода. 
    В заключение следует подчеркнуть, что концепция НФБК позволяет избавиться 
от некоторых проблем, присущих, по крайней мере теоретически, формам, 
соответствующим старому определению ЗНФ. Более того, новое определение 
концептуально проще старого, так как в нем не используются понятия 1НФ, 2НФ, 
первичного ключа или транзитивной зависимости. Кроме того, понятие 
потенциального ключа может быть заменено введением более фундаментального 
понятия функциональной зависимости (в определении, данном в [10.2], фактически 
сделана такая замена). С другой стороны, концепции первичного ключа, 
транзитивной зависимости и т.д. весьма полезны на практике, поскольку 
позволяют представить идею постепенного процесса, выполняемого разработчиком 
для приведения произвольного отношения к эквивалентному набору отношений в НФБК. 
    Наконец, заметим, что в ответах на упражнения в конце этой главы 
содержится алгоритм, согласно которому произвольное отношение может быть 
подвергнуто декомпозиции без потерь информации в набор проекций, находящихся в НФБК. 

    10.6. Резюме 

    На этом заканчивается первая из двух глав, посвященных процессу дальнейшей 
нормализации. В ней были описаны концепции первой, второй, третьей нормальной 
формы и нормальной формы Бойса-Кодда. Несколько уровней нормализации образуют 
общую структуру, в которой («+1)-я нормальная форма автоматически находится в 
п-\л нормальной форме, тогда как обратное утверждение не верно, т.е. 
существуют отношения в и-й нормальной форме, которые не находятся в (/?-И)-й 
нормальной форме. (Если «=3, то выражение "в («+1)-й нормальной форме" 
означает НФБК, а не 4НФ! Подробнее это обсуждается в следующей главе.) Более 
того, всегда можно выполнить приведение к НФБК, т.е. данное отношение всегда 
можно заменить эквивалентным множеством отношений, которые находятся в НФБК. 
Такое приведение используется для того, чтобы избежать избыточности и, 
следовательно, возникновения некоторых аномалий обновления. 
    Процесс приведения заключается в замене данного отношения некоторыми 
проекциями таким образом, чтобы обратное соединение этих проекций позволило 
вновь получить исходное отношение. Иначе говоря, этот процесс является 
обратимым (или декомпозиция выполняется без потерь информации). Также было 
показано, что функциональные зависимости играют решающую роль в этом процессе; 
фактически теорема Хеза утверждает, что если некоторая ФЗ выполняется, то 
некоторая декомпозиция выполняется без потерь. Такое положение дел может 
рассматриваться как еще одно подтверждение заявления, сделанного в главе 9 о 
том, что ФЗ "не совсем фундаментальны, но близки к ним". 
    Также в этой главе обсуждалась концепция Риссанена о независимых проекциях 
и было сделано предположение о том, что в тех случаях, когда есть возможность 
выбора, следует разбивать исходное отношение не на зависимые проекции, а на 
независимые. В этом случае декомпозиция называется сохраняющей зависимость. К 
сожалению, следует отметить, что стремление к достижению этих двух целей, а 
именно: декомпозиции без потерь с приведением к НФБК и сохранению зависимости, 
может привести к конфликтной ситуации. 
    В заключение предлагается весьма элегантное (и точное) определение ЗНФ и 
НФБК, данное Заниоло (Zaniolo) [10.7]. Сначала будет дано определение ЗНФ. 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	295 

    •   Пусть дано отношение R, X является некоторым множеством атрибутов 
отношения R, а А — некоторым атрибутом отношения R. Отношение R находится в 
третьей нормальной форме тогда и только тогда, когда для каждой функциональной 
зависимости X—> А отношения R истинно по крайней мере одно из следующих утверждений: 
    1. Xсодержит А (т.е. эта ФЗ тривиальна). 
    2. X содержит потенциальный ключ отношения R (таким образом, X является суперключом). 
    3. А содержится в потенциальном ключе отношения R. 
    (Следует напомнить, что суперключом называется множество атрибутов, 
включающее подмножество некоторого потенциального ключа, которое не 
обязательно является собственным подмножеством.) Определение НФБК можно 
получить из данного определения для ЗНФ, просто опуская третье утверждение. 
Именно третье утверждение является причиной "неадекватности" оригинального 
определения Кодда для ЗНФ [9.4], которое упоминалось во введении к этой главе. 

    Упражнения 

    10.1. Докажите теорему Хеза. Будет ли верной обратная теорема? 
    10.2. Существует мнение, что каждое бинарное отношение находится в НФБК. 
Верно ли это утверждение? 
    10.3. На рис. 10.17 приведено иерархическое (т.е. ненормализованное) 
представление информации, которая должна храниться в базе данных о персонале 
некоторой компании. 
    • В компании есть несколько отделов. 
    • В каждом отделе (Department) есть несколько сотрудников (Employee), 
несколько проектов (Project) и несколько кабинетов (Office). 
    • Каждый сотрудник имеет план работы (Job), т.е. несколько заданий, 
которые он должен выполнить. Для каждой такой работы существует ведомость 
(Salary history), т.е. перечень денежных сумм, полученных сотрудником за 
выполнение данной работы. 
    • В каждом кабинете есть несколько телефонов (Phone). 
    Office Phone 
    Рис. 10.17. Ненормализованное представление информации, которая должна 
храниться в базе данных о персонале компании 296 

    Часть III. Проектирование базы данных 

    В базе данных должна храниться следующая информация: 
    • Для каждого отдела: номер отдела (уникальный), бюджет и номер 
сотрудника, который возглавляет этот отдел (уникальный). 
    • Для каждого сотрудника: номер сотрудника (уникальный), номер текущего 
проекта, номер кабинета, номер телефона, а также название выполняемой работы 
вместе с датами и размерами всех оплат, полученных за выполнение данной работы. 
    • Для каждого проекта: номер проекта (уникальный) и бюджет. 
    • Для каждого кабинета: номер кабинета (уникальный), площадь в квадратных 
футах, номера (уникальные) всех телефонов, установленных в этом кабинете. 
    Составьте соответствующее множество нормализованных отношений для 
представления этой информации, а также семантические утверждения на основе 
заданных ФЗ. 
    10.4. В базе данных системы учета заказов содержится информация о 
клиентах, товарах и заказах согласно приведенному ниже плану. 
    • Для каждого клиента: 
    номер клиента (уникальный); 
    адрес доставки (несколько для каждого клиента); 
    баланс; 
    максимальный размер кредита; 
    скидка. 
    • Для каждого заказа: 
    информация заголовка:	номер клиента, 
    адрес доставки, дата выполнения заказа; 
    строки данных (несколько для каждого заказа):    номер товара, 
    количество данного товара. 
    • Для каждого товара: 
    номер товара (уникальный); 
    заводы-изготовители; 
    количество товара на каждом заводе; 
    максимальное количество хранимого товара на каждом заводе; 
    описание товара. 
    Для внутреннего учета также вводится величина "количество для доставки", 
связанная с каждой строкой каждого заказа. Эта величина сначала 
устанавливается равной количеству заказанного товара, а после выполнения 
поставки обнуляется. 
    Составьте макет такой базы данных, а также, как и в предыдущем упражнении, 
укажите семантические утверждения на основе заданных ФЗ. 
    10.5. Предположим, что в упр. 10.4 только очень малая часть клиентов, 
например процент или даже меньше, имеют больше одного адреса доставки. (Такова 
реальная ситуация, в которой незначительное число исключений может не 
вписываться в предлагаемую однородную структуру.) Каковы в таком случае 
недостатки решения, предложенного для упр. 10.4? Какие усовершенствования 
можно внести для их устранения? 
    10.6. (Модифицированная версия упр. 9.13.) Отношение TIMETABLE 
определяется со следующими атрибутами: 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	297 

    D	День недели (1-5). 
    Р	Период времени в течение дня (1-8). 
    С	Номер аудитории. 
    Т	Имя преподавателя. 
    S	Имя студента. 
    L	Название урока. 
    Кортеж {D:d, P:p, C:c, T:t, 1:1} является элементом этого отношения тогда 
и только тогда, когда в момент времени {D:d, Р:р] некоторый студент s посещает 
урок /, который преподается учителем / в аудитории с. 
    Можно предположить, что урок имеет длительность одного периода, а каждый 
урок имеет название, уникальное по отношению ко всем другим урокам данной 
недели. Сведите отношение 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 и Т. 

    298	Часть III. Проектирование базы данных 

    А -> В в отношении R{A,В] В -> С в отношении S{B, С} А —> С в отношении Т 
(А, С] 

    В качестве примера, в котором избыточность отсутствует, допустим, что А 
обозначает номер сотрудника, В— номер кабинета, С— номер отдела, R — кабинет 
сотрудника, S— отдел, к которому относится кабинет, Т— отдел сотрудника. 
Рассмотрим случай, когда некоторый сотрудник работает в кабинете не своего 
отдела. Согласно алгоритму синтеза атрибуты S.С и Т.С равны (как правило, 
имена отношений при этом не рассматриваются). Таким образом, предполагается 
наличие некоторого внешнего механизма (т.е. вмешательство человека) для 
предотвращения семантически неверных манипуляций. В данном случае следовало бы 
еще при определении исходных ФЗ использовать различные имена атрибутов, 
например С1 и С2 вместо S.С и Т.С. 
    10.2. Codd E.F. Recent Investigations into Relational Data Base Systems // 
Proc. 1FIP Congress. — Stockholm, Sweden, 1974. 
    Здесь приводится обзор некоторых других работ на данную тему. В частности, 
дается "улучшенное определение третьей нормальной формы", под которой 
фактически подразумевается нормальная форма Бойса-Кодда. Среди других тем 
можно найти обсуждение представлений и обновления представлений, подъязыков 
данных, обмена данными и исследования на эту тему (по состоянию на 1974 год). 
    10.3. Date C.J. A Normalization Problem // The Relational J. — 1992. — 4, 
№ 2. 
    Согласно аннотации в этой статье рассматривается простая задача 
нормализации, которая используется для представления некоторых идей в области 
составления макета базы данных и явного объявления ограничений целостности. 
Задача сформулирована на основе простой базы данных некоторой авиакомпании с 
перечисленными ниже ФЗ, где приняты следующие обозначения: FLIGHT— название 
авиарейса, 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. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	299 

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

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

    10.1. Теорема Хеза утверждает, что если отношение R{A, В, С} удовлетворяет 
функциональной зависимости А -» В (где А, В и С являются множествами 
атрибутов), то R равносильно соединению его проекций R1 с атрибутами {А, В} и 
R2 с атрибутами {А, С}. 
    Далее в этом доказательстве будет использована сокращенная неформальная 
запись (а, Ь, с) для кортежа {А:а, В:Ь, С:с}. 
    Сначала следует показать, что ни один кортеж отношения R не утрачивается 
при разбиении на проекции и обратном соединении этих проекций. Пусть (а, Ь, с) 
е R, тогда (а, Ь) е RI и (а, с) е R2, а значит (а, Ь, с) е Rl JOIN R2. 
    Затем следует показать, что каждый кортеж этого соединения действительно 
является кортежем отношения R (т.е. при соединении не было получено никаких 
"побочных" и нежелательных кортежей). Пусть (а, Ь, с) е Rl JOIN R2. Тогда для 
генерации кортежа соединения должны выполняться зависимости (а, Ь) е R1 и (а, 
с) е R2. Следовательно, для генерации кортежа §а, с) е R2 для некоторого 
атрибута Ь* должен существовать кортеж (а, Ь*, с) е R. Тогда должен также 
существовать кортеж (а,Ь*) Е R1. Теперь у нас есть (a, b) e R1 и (а, Ь*) е R1, 
а поскольку А -> В, значит Ь=Ь*. Отсюда (а, Ь, с) е R. 
    Теорема, обратная теореме Хеза, утверждает, что если отношение R{A, В, С} 
равносильно соединению его проекций RI с атрибутами {А, В} и R2 с атрибутами 
{А, С}, то R удовлетворяет зависимости А —> В. Это утверждение неверно. В 
качестве примера отношения, которое равняется соединению двух его проекций и 
вовсе не удовлетворяет никакой (нетривиальной) ФЗ, можно предложить отношение 
СТХ из главы 11. 
    10.2. Это утверждение почти (но не совсем) верно. Приведенный ниже 
экзотический пример обратной ситуации взят из [5.6]. Рассмотрим отношение US A 
{COUNTRY, STATE}, которое интерпретируется как "STATE-(штат) является членом 
COUNTRY (страны)", где под страной в каждом кортеже подразумеваются 
Соединенные Штаты Америки. Тогда в данном отношении будет выполняться 
приведенная ниже ФЗ. 

    {   }   -» COUNTRY 

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

    300	Часть III. Проектирование базы данных 

    Попутно следует заметить, что в общем случае вполне возможно существование 
потенциального ключа, который является пустым множеством! Более подробно это 
было описано в упражнениях главы 5. 
    10.3. На рис. 10.18 показаны все наиболее важные ФЗ: как те, которые 
подразумевались в упражнении, так и те, которые соответствуют разумным 
семантическим утверждениям (они перечислены ниже). Атрибутам даны такие имена, 
которые могли бы пояснить их значения. 

    AREA                                                                       
        DBUDGET OFF#     [• ———————————————————————— •   DEPT#   • —————— -    
MGR# _____ Н ———————————————— i              i ———————————————— > ———— _ ———— 
PHONE# « ——————— —   EMP# | — ——————— •   PROJ#    ——————— > PBUDGET JOBTITLE 
« ———————          DATE          ——————— SALARY 

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

    Семантические утверждения: 
    • Ни один сотрудник не является одновременно руководителем нескольких отделов. 
    • Ни один сотрудник не работает одновременно более чем в одном отделе. 
    • Ни один сотрудник не работает одновременно более чем с одним проектом. 
    • Ни один сотрудник не имеет одновременно более одного кабинета. 
    • Ни один сотрудник не имеет одновременно более одного телефона. 
    • Ни один сотрудник не имеет одновременно более одного задания. 
    • Ни один проект не дается одновременно более чем одному отделу. 
    • Ни один кабинет не относится одновременно более чем к одному отделу. 

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

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

    Здесь смысл атрибутов DEPT# (номер отдела), DBUDGET (ведомость) и MGR# 
(номер руководителя отдела) ясен из сокращенных названий, а домены, 
соответствующие атрибутам ХЕМРО (сотрудник), XPROJO (проект) и XOFFICEO 
(кабинет), состоят из значений-отношений и для них требуется дополнительное разъяснение. 
    Для начала рассмотрим домен значений-отношений, соответствующий атрибуту 
XPROJO. Пусть РВ является множеством всех возможных пар PROJ#-PBUDGET (т.е. 
декартовым произведением доменов для атрибутов PROJ# и PBUDGET). Тогда 
значение атрибута XPROJO, соответствующее любому заданному значению DEPT#, 
является некоторым подмножеством множества пар в РВ. Таким образом, 
соответствующий атрибуту XPROJO домен значений-отношений является множеством 
всех возможных подмно

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 301 

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

    DEPTO   (  DEPTi,   DBUDGET,   MCR#, 
    ХЕМРО   (  EMPtt,   PROJ#,   OFF#,   PHONE*, XJOBO   (  JOBTITLE, 
    XSALHISTO   (  DATE,   SALARY )   )   ), XPROJO   (  PROJ#,   PBUDGET  ), 
XOFFICE   (   OFFi,   AREA,   XPHONEO   (   PHCNEtf )   )   ) 

    Этап 1. 

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

    DEPT1 ( DEPT#, DBUDGET, MGR# } 
    PRIMARY KEY ( DEPT# ) ALTERNATE KEY ( MGR# ) 
    EMP1 ( DEPT#, EMP#, PROJtt, OFF#, PHONES ) PRIMARY KEY ( DEPT#, EMP# } 
    JOB1 ( DEPT#, EMP#, JOBTITLE ) 
    PRIMARY KEY ( DEPT#, EMP#, JOBTITLE ) 

    302	Часть III. Проектирование базы данных 

    SALHIST1 ( DEPTtt, НУ1Р#, JOBTITLE, DATE, SALARY ) 
    PRIMARY KEY ( DEPT#, EMPtt, JOBTITLE, DATE ) 
    PROJ1 ( DEPT#, PROJ#, PBUDGET ) 
    PRIMARY KEY ( DEPT#, PROJ# ) 
    OFFICE1 ( DEPTff, OFF#, AREA ) 
    PRIMARY KEY ( DEPT#, OFF* ) 
    РНШЕ1 ( DEPT#, OFFtt, PHONE ) 
    PRIMARY KEY ( DEPTtt, OFF#, PHONE# ) 

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

    JOB2A ( ЕМР#, JOBTITLE ) 
    PRIMARY KEY ( EMPtt, JOBTITLE ) 
    И 
    JOB2B ( EMPtt, DEPT# ) 
    PRIMARY KEY ( EMPt ) 

    Однако JOB2A является проекцией SALHIST2 (ниже это описано подробнее), a 
JOB2B — проекцией ЕМР1 (далее переименованного в ЕМР2). Следовательно, оба 
отношения могут быть удалены. 
    SALHIST1     Так же, как и в случае с JOB1, можно полностью удалить 
атрибут DEPT#. Более того, JOBTITLE не требуется в качестве компонента 
первичного ключа. В качестве первичного ключа можно использовать комбинацию 
{ЕМР#, DATE}, чтобы получить следующее отношение в 2НФ: 
    SALHIST2 ( ЕМР#, DATE, JOBTITLE, SALARY ) PRIMARY KEY ( EMP#, DATE ) 
    PROJ1	Так же, как и в случае с ЕМР1, можно рассматривать DEPT# как 
неключевой атрибут, тогда данное отношение находится в 2НФ. 
    OFFICE1        Здесь можно привести аналогичное рассуждение. 
    PHONE I DEPT# можно удалить совсем, поскольку отношение (DEPT#, OFF#) 
является проекцией отношения OFFICE! (переименованного далее в OFFICE2). Кроме 
того, OFF# функционально зависит от PHONE#, поэтому в качестве первичного 
ключа можно принять только PHONE# с получением приведенного ниже отношения в 2НФ: 

    PHONE2 ( PHONE*, OFF# ) 
    PRIMARY KEY ( PHONE* ) 

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

    Глава 10, Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 303 

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

    DEPT2 ( DEPT#, DBODGET, MGR* ) 
    PRIMARY 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*, PBDDGET ) PRIMARY KEY ( PROJ# ) 
    OFFICE2 ( OFF*, DEPT*, AREA ) 
    PRIMARY KEY { OFF* ) 
    РНОЫЕ2 ( PHONE*, OFF* ) 
    PRIMARY KEY ( PHONE* ) 

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

    ЕМРЗ ( ЕМР#, PROJ#, PHONE# ) 
    PRIMARY KEY ( EMP* ) 
    X ( PHONE*, OFF* } 
    PRIMARY KEY ( PHONE* ) 
    Y ( PROJ#, DEFT* ) 
    PRIMARY KEY ( PROJ* ) 
    2 ( OFF*, DEPT* ) 
    PRIMARY KEY ( OFF* ) 

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

    DEPT3 ( DEPT*, DBUDGET, 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* ) 
    OFFICES ( OFF*, DEPT*, AREA ) 
    PRIMARY KEY { OFF* ) 
    PHONES ( PHONE*, OFF* ) 
    PRIMARY KEY ( PHONE* ) 

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

    304	Часть III. Проектирование базы данных 

    [4.1], так как проекция отношения PROJ3 с комбинацией {PROJ#, DEPT#} 
является проекцией соединения отношений ЕМРЗ, PHONES и OFFICES. 
    В заключение отметим, что отношения в НФБК можно "обнаружить" на основе 
диаграммы ФЗ (как это можно сделать?). Замечание. Это значит, что "обнаружить" 
декомпозицию НФБК можно не всегда, а лишь в некоторых практических случаях. 
Точнее, для данного отношения R, удовлетворяющего множеству функциональных 
зависимостей S, показанный ниже алгоритм (пункты 0-8) гарантирует декомпозицию 
D отношения R на отношения в ЗНФ (но не НФБК), которая выполняется 
одновременно без потерь информации и с сохранением зависимости. 
    0.  Зададим пустое множество в качестве начального значения для D. 
    1.   Пусть / является неприводимым покрытием для S. 
    2.  Пусть X является множеством атрибутов с левой части некоторой 
зависимости Х—> Y в I. 
    3.   Пусть полное множество ФЗ в / с левой частью X состоит из 
зависимостей X-+Yl,X-+ Y2,...X-+ Yn. 
    4.   Пусть Z является объединением Yl, Y2,... Yn. 
    5.  Заменим D объединением D и проекцией отношения R по атрибутам X и Z. 
    6.   Повторим пункты 3-5 для каждого атрибута множестваX. 
    1.  Пусть А1,А2, ...An являются неучтенными до сих пор атрибутами 
отношения R (например, такими, которые не включены в любое отношение в П). 
Заменим D объединением D и проекцией отношения R по атрибутам А1,А2,...Ап. 
    8.   Если ни одно из отношений в D не содержит потенциального ключа R, 
заменим D объединением D и проекцией R по некоторому потенциальному ключу 
отношения R. 
    В приведенном ниже алгоритме гарантируется получение декомпозиции D 
отношения R на отношения в НФБК, которая выполняется без потерь информации, но 
не обязательно с сохранением зависимости. 
    0.  Зададим отношение R в качестве начального значения для D. 
    1.  Для каждого отношения Г (которое не находится в НФБК) из D выполним 
действия, перечисленные в пунктах 2-3. 
    2.   Пусть X-* Y является функциональной зависимостью в отношении Т, в 
котором нарушаются некоторые требования НФБК. 
    3.   Заменим отношение Т в D двумя проекциями, а именно: одной по 
атрибутам X и Y, а другой — по всем атрибутам, за исключением Y. Возвращаясь к 
примеру с персоналом компании, можно предложить читателю еще одно упражнение, 
которое относится не только к самой нормализации, но и макету базы данных в 
целом. Попробуйте расширить описанный выше макет базы данных, включая в него 
все необходимые спецификации внешних ключей. 
    10.4. На рис. 10.19 показаны наиболее важные ФЗ, а семантические допущения 
сформулированы и приведены ниже. 
    • Никакие два клиента не имеют одинаковых адресов доставки. 
    • Каждый заказ имеет уникальный номер. 
    • Каждая строка данных заказа имеет номер строки, уникальный для данного заказа. 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК	305 

    QTYORD			ORD#				DATE 
    
    QTYOUT			LINE* 

    DESCN			ITEM*				QTYOH 
    
    
    PLANT*				DANGER 
    
    Рис. 10.19. Диаграмма зависимостей для упр. 10.4 

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

    CUST ( CUST#, BAL, CREDLIM, DISCOUNT ) PRIMARY KEY ( COST* ) 
    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 COST* = input.CUST* ; 

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

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

    CUST ( CUST*, ADDRESS, BAL, CREDLIM, DISCOUNT } PRIMARY KEY ( CUST* ) 

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

    SECOND ( ADDRESS, CUST* ) 
    PRIMARY KEY ( ADDRESS ) 

    306 Часть III. Проектирование базы данных 

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

    RETRIEVE CUST WHERE CUST# = input.CUST# ; 

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

    if COST.ADDRESS * input.ADDRESS then 
    RETRIEVE SECOND WHERE ADDRESS = input.ADDRESS ; 
    AND CUST# = input.CUSTl /* проверить адрес доставки */ ; если все в 

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

    Рис. 10.20. Диаграмма зависимостей для упр. 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НФ, но не в ЗНФ и не в НФБК. 
Усовершенствованный макет может иметь следующий вид: 

    Глава 10. Дальнейшая нормализация: 1НФ, 2НФ, ЗНФ, НФБК 307 

    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]. 

    308	Часть III. Проектирование базы данных 

