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

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

³ Точнее, стрелки должны начинаться с суперключей. Но если множество ФЗ является не­приводимым, все функциональные зависимости (или "стрелки ") будут неприводимы слева.

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

Итак, ниже дается предварительное определение ЗНФ.

■ Третья нормальная форма (очень неформальное определение). Переменная-отношение находится,в ЗНФ тогда и только тогда, когда ее неключевые атрибуты (если они вообще есть) являются:

а) взаимно независимыми;

б) неприводимо зависимыми от первичного ключа.

Понятия "неключевые атрибуты" и "взаимно независимые атрибуты" поясняют­ся ниже.

• Неключевой атрибут — это атрибут, который не входит в состав первичного ключа рассматриваемой переменной-отношения.

• Два или более атрибутов называются взаимно независимыми, если ни один из них функционально не зависит от какой-либо комбинации остальных атрибутов. По­добная независимость подразумевает, что каждый такой атрибут может обнов­ляться независимо от значений остальных атрибутов.

Например, согласно приведенному ниже определению переменная-отношение Р (переменная-отношение деталей) находится в ЗНФ, а именно: атрибуты PNAME (название детали), COLOR (цвет), WEIGHT (вес) и CITY (город) независимы (т.е. цвета деталей можно менять, не изменяя их вес и т.д.) и неприводимо зависимы по отношению к первичному ключу {Pi} (номер детали).

Такое неформальное определение ЗНФ может быть интерпретировано следующим, еще более неформальным образом.

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

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

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

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

Фактически в этом определении всего лишь утверждается, что все переменные-отношения всегда находятся в ШФ, что, несомненно, верно. Однако переменная-отношение, которая находится только в ШФ (т.е. не находится ни во второй, ни в треть­ей нормальной форме), обладает структурой, не совсем желательной по некоторым при­чинам. Для иллюстрации этого факта допустим, что информация о поставщиках и по­ставках содержится не в двух переменных-отношениях S и SP, а в одной, имеющей следующую структуру.

FIRST { St, STATUS, CITY, Pt, QTY } PRIMARY KEY { St, Pt }

Это расширенная версия переменной-отношения SCP, приведенной выше, в разде­ле 11.1. Ее атрибуты имеют тот же смысл, что и ранее, за исключением следующего до­полнительного ограничения, специально введенного в этом примере.

CITY -» STATUS

(Иными словами, атрибут STATUS функционально зависим от атрибута CITY; и смысл этого ограничения состоит в том, что статус поставщика определяется его местонахождением, на­пример все поставщики из Лондона должны иметь статус 20.) Кроме того, для упрощения ат­рибут SNAME далее будет игнорироваться. Первичным ключом переменной-отношения FIRST является комбинация атрибутов {St, Pt}, а диаграмма ее функциональных зависимостей бу­дет иметь вид, представленный на рис. 11.5.

Обратите внимание, что эта диаграмма функциональных зависимостей "сложнее" ана­логичной диаграммы для переменной-отношения в ЗНФ. Как было сказано в преды­дущем разделе, на диаграмме ФЗ для перемен­ной-отношения в ЗНФ стрелки всегда выходят только из потенциальных ключей, тогда как на диаграмме ФЗ для переменной-отношения, которая не находится в ЗНФ (например, на Рис 115 Функциональные зависимости _диаГрамме ФЗ для переменной-отношения в переменной-отношении FIRST FIRST), есть стрелки, начинающиеся с потен­циальных ключей, и дополнительные стрелки, усложняющие всю картину. Фактиче­ски в переменной-отношении FIRST нарушаются оба условия, указанные в приведен­ном выше определении ЗНФ. не все неключевые атрибуты взаимно независимы, по­скольку атрибут STATUS зависит от атрибута CITY (одна дополнительная стрелка), и не все неключевые атрибуты неприводимо зависимы от первичного ключа, поскольку ат­рибуты STATUS и CITY, каждый в отдельности, зависимы от атрибута St (еще две до­полнительные стрелки).

Для иллюстрации некоторых трудностей, порождаемых этими дополнительными стрелками, на рис. 11.6 приведен пример данных в переменной-отношении FIRST. Это тот же набор значений, который обычно используется нами в примерах, но значение 30 статуса поставщика с номером 'S3' заменено значением 10 в соответствии с новым ог­раничением, согласно которому значение атрибута CITY определяет значение атрибута STATUS. Возникшая в результате избыточность данных вполне очевидна, поскольку в ка­ждом кортеже для поставщика с номером 'S1' атрибут CITY имеет значение 'London' и, кроме того, в каждом кортеже со значением ' London' в атрибуте CITY указано значение 20 для атрибута STATUS.

Избыточность в переменной-отношении FIRST приводит к разным аномалиям об­новления, получившим такое название по историческим причинам. Под этим понимаются определенные трудности, появляющиеся при выполнении операций об­новления INSERT, DELETE и UPDATE. Для начала рассмотрим избыточность вида

FIRST

"поставщик-город", соответствующую функциональной зависимости Si —> CITY. Ни­же поясняются проблемы, которые возникнут при выполнении каждой из указанных операций обновления.

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
S4	20	London	P4		300
S4	20	London	P5		400

Рис. 11.6. Пример данных в переменной-отношении FIRST

• Операция INSERT. Нельзя поместить в переменную-отношение FIRST информа­цию о том, что некоторый поставщик находится в определенном городе, не ука­зав сведения хотя бы об одной детали, поставляемой этим поставщиком. Дейст­вительно, в таблице на рис. 11.6 нет сведений о поставщике с номером 'S5' из Афин, поскольку до тех пор, пока этот поставщик не начнет поставку какой-либо детали, для него невозможно будет сформировать значение первичного ключа. (Как и в разделе 9.4, в этой главе предполагается (достаточно обосно­ванно), что атрибуты первичных ключей не могут иметь значений, принимае­мых по умолчанию.)

• Операция DELETE. Если из переменной-отношения FIRST удалить кортеж, кото­рый является единственным для некоторого поставщика, будет удалена не только информация о поставке поставщиком некоторой детали, но также информация о том, что этот поставщик находится в определенном городе. Например, если из пе­ременной-отношения FIRST удалить кортеж со значением 'S3' в атрибуте Si и значением 'Р2' в атрибуте Р#, будет утрачена информация о том, что поставщик с номером 'S3' находится в Париже. (По сути, проблемы удаления и вставки явля­ют собой две стороны одной медали.)

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

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

■ Операция UPDATE. Название города для каждого поставщика повторяется в пере­менной-отношении FIRST несколько раз, и эта избыточность приводит к возник­новению проблем при обновлении. Например, если поставщик с номером 'S1' пе­реместится из Лондона в Амстердам, то необходимо будет отыскать в переменной-отношении FIRST все кортежи, в которых значения 'S1' и 'London' связаны меж­ду собой (для внесения соответствующих изменений), иначе база данных окажется в противоречивом состоянии (в одних кортежах городом поставщика с номером ' S1' будет Лондон, а в других — Амстердам).

Для решения всех этих проблем, как предлагалось выше, необходимо заменить пере­менную-отношение FIRST двумя следующими переменными-отношениями.

SECOND { Si, STATUS, CITY }

SP { Si, Pi, QTY }

Диаграммы функциональных зависимостей для этих двух переменных-отношений пока­заны на рис. 11.7, а наборы данных— на рис. 11.8. Обратите внимание, что теперь в них имеется и информация о поставщике с номером ' S5' (в переменной-отношении SECOND, но не в переменной-отношении SP), а содержимое переменной-отношения SP теперь в точно­сти совпадает с содержимым нашей обычной переменной-отношения поставок.

S#

CITY

STATUS!

s# p#
		QTY

Рис. 11.7. Функциональные зависимости в пе­ременных-отношениях SECOND и SP

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

• Операция INSERT. Теперь информацию о том, что поставщик с номером 'S5' на­ходится в Афинах, можно поместить в базу данных, вставив соответствующий кортеж в переменную-отношение SECOND, причем даже в том случае, если он в на­стоящее время не поставляет никаких деталей.

• Операция DELETE. Теперь уже можно исключить информацию о поставке, в которой соединены сведения о поставщике с номером ' S3' и о детали с номером ' Р2'. Доста­точно удалить соответствующий кортеж из переменной-отношения SP, причем инфор­мация о том, что поставщик с номером ' S3' находится в Париже, не утрачивается.

s#	STATUS	CITY	SP	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

Рис. 11.8. Пример данных в переменных-отношениях SECOND и SP

■ Операция UPDATE. В переработанной структуре название города для каждого по­ставщика указывается всего один раз, поскольку существует только один кортеж для данного поставщика в переменной-отношении SECOND (атрибут Si является первичным ключом этой переменной-отношения). Иначе говоря, избыточность данных Si-CITY устранена. Благодаря этому теперь можно изменить название го­рода Лондон для поставщика с номером ' S1' на Амстердам, не рискуя привести базу данных в несогласованное состояние, поскольку достаточно изменить назва­ние города в единственном кортеже переменной-отношения SECOND.

Сравнивая рис. 11.7 и 11.5, можно заметить, что суть разбиения переменной-отношения FIRST на переменные-отношения SECOND и SP состояла в исключении зависимостей, кото­рые не являлись неприводимыми. Именно благодаря этому в новом варианте удается избе­жать упомянутых ранее трудностей. Интуитивно понятно, что в переменной-отношении FIRST атрибут CITY описывал не сущность, которая идентифицируется первичным ключом (поставка), а поставщика, выполнявшего эту поставку (аналогичное утверждение можно сделать и об атрибуте STATUS). Смешивание этих двух типов информации в одной перемен­ной-отношении и стало причиной возникновения описанных выше проблем.

Теперь пришло время дать определение второй нормальной формы⁶.

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

⁶ Строго говоря, 2НФ может быть определена только по отношению к заданному множе­ству зависимостей, но в неформальном контексте эта особенность обычно игнорируется. Ана­логичные замечания приложилт также ко всем нормальным формам (кроме, конечно же, первой нормальной формы).

Обе переменные-отношения (и SECOND, и SP) находятся во второй нормальной форме (их первичные ключи— {Si} и {Si, Pi} соответственно), тогда как переменная-отношение FIRST не находится в этой форме. Всякую переменную-отношение, которая находится в пер­

вой нормальной форме, но не находится во второй, всегда можно свести к эквивалентному множеству переменных-отношений, находящихся в 2НФ. Этот процесс заключается в замене переменной-отношения в 1НФ подходящим набором проекций, эквивалентных исходной пе­ременной-отношению в том смысле, что ее при необходимости можно будет восстановить с помощью обратной операции соединения данных проекций. В нашем примере переменные-отношения SECOND и SP — это проекции переменной-отношения FIRST, которая является со­единением переменных-отношений SECOND и SP по атрибуту Sf⁷.

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

R { А, В, С, D }

PRIMARY KEY { А, В }

/* Предполагается наличие функциональной зависимости А —» D */

Процедура нормализации предусматривает замену этой переменной-отношения сле­дующими двумя проекциями R1 и R2.

Rl { A, D } PRIMARY KEY { А }

R2 { А, В, С }

PRIMARY KEY { А, В }

FOREIGN KEY { А } REFERENCES Rl

Переменная-отношение R всегда может быть восстановлена посредством соединения переменных-отношений R1 и R2 по внешнему и соответствующему ему первичному клю­чам этих переменных-отношений.

За исключением того факта, что переменная-отношение SECOND может содержать дополни­тельные кортежи (например, кортеж для поставщика с номером 'S5'), которые не будут иметь аналога в переменной-отношении FIRST (см. рис. 11.8). Иначе говоря, новая структура может содер­жать информацию, которую невозможно будет представить в исходной структуре. В этом смысле новую структуру можно рассматривать как более корректное представление реального мира.

Вернемся к нашему примеру. Следует отметить, что выбранная структура перемен­ных-отношений SECOND и SP все еще может вызвать некоторые проблемы. Структура пе­ременной-отношения SP вполне удовлетворительна, поскольку она фактически находит­ся в ЗНФ. Поэтому мы больше не будем уделять ей внимание до конца данного раздела. Однако в переменной-отношении SECOND неключевые атрибуты все еще не являются вза­имно независимыми. Диаграмма функциональных зависимостей для нее по-прежнему имеет вид более сложный, чем это требуется для диаграммы ФЗ переменной-отношения, находящейся в ЗНФ. В частности, зависимость атрибута STATUS от атрибута St хотя и яв­ляется функциональной и действительно неприводимой, одновременно является тран­зитивной (через атрибут CITY). Это означает, что каждое значение атрибута St опреде­ляет значение атрибута CITY, а значение атрибута CITY, в свою очередь, определяет зна­чение атрибута STATUS. В общем случае, как уже объяснялось в главе 10, если имеют ме­сто две функциональные зависимости А —» В и В —» С, то имеет место и транзитивная функциональная зависимость А —> С. Однако наличие транзитивных зависимостей мо­

жет привести к возникновению описанных ниже аномалий обновления. (В данном случае основное внимание будет сосредоточено на избыточности данных типа "город — статус", отвечающей функциональной зависимости CITY —> STATUS.)

• Операция INSERT. Нельзя поместить в базу данных сведения об определенном городе, обладающем некоторым статусом (например, нельзя указать, что все по­ставщики из Рима должны обладать статусом 50), до тех пор, пока в этом городе не появится конкретный поставщик.

• Операция DELETE. При удалении из переменной-отношения SECOND кортежа для не­которого города, представленного в ней этим единственным кортежем, будут удале­ны не только сведения о поставщике из данного города, но и информация о том, ка­ким статусом обладал сам город. Например, при удалении из переменной-отношения SECOND кортежа для поставщика с номером ' S5' будет утрачена инфор­мация о том, что для Афин был установлен статус 30. (И в этом случае операции вставки и удаления фактически являются двумя сторонами одной и той же медали.)

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

■ Операция UPDATE. В переменной-отношении SECOND значение статуса для каждого города повторяется несколько раз (поэтому она все еще обладает некоторой избы­точностью). Следовательно, при необходимости изменить для Лондона значение статуса 20 на 30 потребуется отыскать в переменной-отношении SECOND все кортежи, в которых значения 'London' и 20 связаны между собой (для внесения соответст­вующих изменений). В противном случае база данных окажется в противоречивом состоянии (в одних кортежах статус для Лондона будет равен 20, а в других — 30).

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

SC { St, CITY }

CS { CITY, STATUS }

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

s#			CITY
CITY				STATUS

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

И на этот раз вполне очевидно, что подобное изменение структуры переменных-отношений позволяет устранить все описанные выше проблемы в операциях обновления. Читателю предлагается самостоятельно разобраться в подробностях решения этих про­блем. Сравнивая рис. 11.9 и 11.7, можно заметить, что благодаря дальнейшей декомпо­зиции удалось исключить транзитивную зависимость атрибута STATUS от атрибута St. Это позволило избавиться ото всех существовавших трудностей. Интуитивно понятное объяснение состоит в том, что в переменной-отношении SECOND атрибут STATUS описы­вал сущность, отличную от сущности, которая идентифицировалась первичным ключом отношения (т.е. номером поставщика), т.е. город поставщика. Именно смешивание этих двух типов информации в одной переменной-отношении приводило к возникновению описанных выше проблем.

Теперь можно дать определение третьей нормальной формы.

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

Переменные-отношения SC и CS находятся в третьей нормальной форме, причем пер­вичными ключами в них являются атрибуты {St} и {CITY} соответственно. Переменная-отношение SECOND не находится в третьей нормальной форме. Переменная-отношение, которая находится в 2НФ, но не находится в ЗНФ, всегда может быть преобразована в эквивалентный набор переменных-отношений в ЗНФ. Как говорилось ранее, этот про­цесс обратим и, следовательно, никакая информация при подобном преобразовании не утрачивается. Однако результирующий набор отношений в ЗНФ способен содержать та­кую информацию, которая не могла быть представлена в исходной переменной-отношении в 2НФ (например, сведения о том, что статус Рима равен 50)⁸.

Отсюда следует, что как комбинация переменных-отношений "SECOND— SP" может рас­сматриваться в качестве более корректного представления реального мира по сравнению с перемен­ной-отношением FIRST, так и комбинация переменных-отношений "SC— CS" корректнее перемен­ной-отношения SECOND, находящейся в 2НФ.

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

R { А, В, С }

PRIMARY KEY { А }

/* Предполагается наличие функциональной зависимости В —» С */

Процедура нормализации предусматривает замену этой переменной-отношения сле­дующими двумя проекциями R1 и R2.

R1 { В, С }

PRIMARY KEY { В }

R2 { А, В }

PRIMARY KEY { А }

FOREIGN KEY { В } REFERENCES Rl

Переменная-отношение R всегда может быть восстановлена посредством соединения переменных-отношений R1 и R2 по внешнему и соответствующему ему первичному клю­чам этих переменных-отношений.

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