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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.5. Денор]мализация

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

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

2. Большое количество логически независимых переменных-отношений означает наличие большого количества физически отдельно хранимых файлов.

3. Большое количество физически отдельно хранимых файлов означает большое количество операций ввода-вывода.

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

Замечание. Материал этого раздела в значительной степени основан на работе [12.6].

Что такое денор]\1ализация

Кратко говоря, нормализация переменной-отношения R означает ее замену таким множеством проекций R1, Rn для всех возможных значений г переменной-

отношения R, что результатом обратного соединения значений г1, ..., rn проекций R1, ..., Rn обязательно будет значение г. Конечной целью нормализации является сокращение уровня избыточности данных за счет приведения проекций R1, Rn к максимально высокому уровню нормализации (т.е. к 5НФ).

Теперь можно перейти к определению понятия денормализации. Пусть R1, Rn является множеством переменных-отношений. Тогда денормализацией этих переменных-отношений называется такая замена переменных-отношений их соединением R, что для всех возможных значений г1, rn переменных-отношений R1, Rn операция проекции значения г переменной-отношения R по атрибутам Ri обязательно снова приводит к созданию значений ri (где i = 1, п). Конечной целью денормализации является увеличение уровня избыточности данных за счет приведения переменной-отношения R к более низкому уровню нормализации, чем исходные переменные-отношения R1, Rn. Точнее, преследуется цель сократить количество соединений, которые потребуется выполнять во время работы приложений, за счет предварительного создания этих соединений на одном из этапов проектирования базы данных.

В качестве примера рассмотрим денормализацию переменных-отношений деталей и поставок для получения переменной-отношения PSQ, представленной на рис. 12.6 *. Следует отметить, что переменная-отношение PSQ находится в 1 НФ, а не в 2НФ.

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