12.4. Общая схема процедуры нормализации

До данного момента в этой (и предшествующей) главе описывалась технология де­композиции без потерь, предназначенная для использования в процессе проектирования базы данных. Основная идея состоит в следующем. Пусть дана некоторая переменная-отношение R, представленная в ШФ, в совокупности с набором определенных для нее функциональных зависимостей, многозначных зависимостей и зависимостей соединения. Задача заключается в систематическом разбиении исходной переменной-отношения R на набор меньших (т.е. имеющих меньшую степень) переменных-отношений, который в некотором заданном смысле будет эквивалентен переменной-отношению R, но с определенной точки зрения будет более предпочтительным. (Исходная переменная-отношение R может быть получена за счет предварительного ис­ключения тех атрибутов, которые принимают в качестве значений отношения, как было описано в разделе 12.2 или в ответе к упр. 11.3.) Каждый этап процесса нормализации заключается в разбиении на проекции переменных-отношений, полученных на преды­дущем этапе. При этом на каждом этапе нормализации существующие ограничения ис­пользуются для выбора тех проекций, которые будут получены в этот раз. Весь процесс можно неформально определить с помощью перечисленных ниже правил.

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

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

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

Замечание. Правила 1-3 могут быть объединены в одно: "Исходную перемен­ную-отношение следует разбить на проекции, позволяющие исключить все функциональные зависимости, в которых детерминанты не являются потенци­альными ключами".

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

Замечание. На практике такие многозначные зависимости обычно исключаются перед выполнением этапов 1-3 ("устранение независимых МЗЗ"), как упоминалось при рассмотрении примера с переменной-отношением СТХ в разделе 12.2.

5. Полученные переменные-отношения в 4НФ следует разбить на проекции, позво- ляющие исключить любые зависимости соединения, которые не подразумеваются потенциальными ключами (хотя в данном случае в определение следовало бы до- бавить фразу "если их удастся выявить"). В результате будет получен набор пере- менных-отношений в 5НФ.

По поводу приведенных выше правил можно сделать несколько дополнительных замечаний.

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

2. Обратите внимание, что (как было впервые отмечено Фейгином в [12.14]) сущест­вует довольно привлекательный набор следующих альтернативных определений НФБК, 4НФ и 5НФ.

■ Переменная-отношение R находится в НФБК тогда и только тогда, когда каждая функциональная зависимость подразумевается ее потенциальными ключами.

• Переменная-отношение R находится в 4НФ тогда и только тогда, когда каждая многозначная зависимость подразумевается ее потенциальными ключами.

■ Переменная-отношение R находится в 5НФ тогда и только тогда, когда каждая зависимость соединения подразумевается ее потенциальными ключами.

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

3. Общее назначение процесса нормализации заключается в следующем:

• исключение некоторых типов избыточности;

• устранение некоторых аномалий обновления;

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

■ упрощение процедуры описания необходимых ограничений целостности. Последний пункт данного списка следует рассмотреть отдельно. Общая идея (как отмечалось ранее, в главах 8, 10 и др.) состоит в том, что одни ограничения цело­стности подразумевают другие ограничения, В качестве простейшего примера можно привести ограничение для суммы зарплаты, которая должна быть выше $10 ООО, а следовательно, выше нуля. Таким образом, если ограничение А подразу­мевает ограничение В, то после приведения в действие ограничения А будет авто­матически задействовано также ограничение В (для этого даже не потребуется объявлять ограничение В явным образом, за исключением случаев, когда это будет сделано в виде комментария). Тогда приведение к 5НФ представляет собой про­стой путь наложения некоторых важных и весьма распространенных ограничений. Главное — обеспечить поддержку уникальности потенциальных ключей, после че­го все зависимости соединения (а также все многозначные и функциональные зави­симости) будут реализованы СУБД автоматически, поскольку все они подразуме­ваются потенциальными ключами.

4. Необходимо вновь подчеркнуть тот факт, что данные рекомендации по поводу нормализации являются всего лишь рекомендациями и, вероятно, могут сущест- вовать соображения, по которым нормализацию не следует выполнять предло- женным выше образом, причем "от начала и до конца". Классическим примером ситуации, когда полная нормализация не желательна, является переменная-

отношение типа "имя — адрес" NADDR (из упр. 11.7 главы 11), хотя следует при­знать, что этот пример не совсем убедителен. Как правило, нормализацию реко­мендуется выполнять полностью.

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

6. Исходя из сказанного выше, необходимо отметить, что хотя идеи нормализации чрезвычайно полезны для проектирования баз данных, они вовсе не являются уни­версальным средством. Ниже перечислены некоторые причины подобного положе­ния дел [12.9].

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

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

• Как упоминалось в разделе 11.5 (пример декомпозиции переменной-отношения SJT), преследование одновременно двух целей, т.е. приведение к НФБК и сохра­нение зависимостей, в некоторых случаях приводит к конфликтной ситуации.

• Процедура нормализации позволяет избавиться от избыточности за счет разбие­ния на проекции, однако не всякую избыточность можно устранить таким обра­зом ("проблема переменной-отношения CTXD", см. аннотацию к [12.13]).

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