Принципов нормализации

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

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

Процесс нормализации может быть проведен уже к концептуальной модели «сущность-связь», тогда после перехода к реляционной модели получим нормализованную схему БД.

Построение схемы БД может быть выполнено двумя путями:

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

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

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

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

2.3.1. Функциональные зависимости

В процессе нормализации рассматриваются различные функциональные зависимости. Функциональные зависимости определяют не текущее состояние БД, а все возможные ее состояния, то есть они отражают те связи между атрибутами, которые присущи реальному объекту, моделируемые в БД.

Функциональная зависимость. Атрибут Y некоторого отношения функционально зависит от X (атрибуты могут быть составными), если в любой момент времени каждому значению X соответствует одно значение Y. Функциональная зависимость обозначается X Y.

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

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

Транзитивная функциональная зависимость. Пусть X, Y, Z – три атрибута некоторого отношения. При этом X Y и Y Z, но обратное соответствие отсутствует, т.е. Z -/-> Y и Y -/-> X. Тогда Z транзитивно зависит от X.

Многозначная зависимость. Пусть X, Y, Z – три атрибута отношения R. В отношении R существует многозначная зависимость R.X ->> R.Y только в том случае, если множество значений Y, соответствующее паре значений X и Z, зависит только от X и не зависит от Z. В общем случае необходимо проводить нормализацию к пятой нормальной форме (5НФ). На практике зачастую оказывается достаточным приведение к третьей нормальной форме (3НФ).

2.3.2. Первая нормальная форма

Первая нормальная форма (1НФ): отношение находится в 1НФ, если значения всех его атрибутов атомарны.

Иначе можно сказать, что в каждой позиции пересечения столбца и строки таблицы расположено в точности одно значение, а не набор значений. Отношения в 1НФ часто называются просто нормализованными отношениями.

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

Пример ненормализованного и нормализованного (в 1НФ) отношений приведен на Рис. 2-16.