Функциональные зависимости. Основные определения

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

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

• Описание концептуальной схемы БД в терминах выбранной СУБД.
• Описание внешних моделей в терминах выбранной СУБД.
• Описание декларативных правил поддержки целостности базы данных.
• Описание процедур поддержки семантической целостности базы данных.

Однако перед тем как описывать построенную схему в терминах выбранной СУБД, нам надо выстроить эту схему. Именно этому процессу и посвящен данный раздел. Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.

ОПРЕДЕЛЕНИЕ

Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД.

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

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

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

• первая нормальная форма (1НФ);
• вторая нормальная форма (2НФ);
• третья нормальная форма (3НФ);
• нормальная форма Бойса—Кодда (НФБК);
• четвертая нормальная форма (4НФ);
• пятая нормальная форма, или форма проекции-соединения (5НФ).

Основные свойства нормальных форм:

• каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;
• при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

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

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

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

Приведем ряд основных определений.

Функциональная зависимость(ФЗ) является связью типа многие – к – одному между множествами атрибутов внутри данного отношения.

Пусть R – отношение, а А и В – произвольные подмножества множества атрибутов отношения R. Тогда В функционально зависит от А (A B), если каждое значение множества А отношения R определяет одно значение множества В отношения R. Иначе говоря, если два кортежа отношения R совпадают по значению А, они также совпадают и по значению В.

Левая и правая части ФЗ называются детерминантом и зависимой частью соответственно.

Если ФЗ выполняется для всех возможных значений отношения, то она является ограничением целостности для отношения, т.к. при этом накладываются определенные ограничения на все допустимые значения.

Если А является потенциальным ключом отношения R, напр., А является первичным ключом, то все атрибуты отношения R должны быть функционально зависимы от А (это следует из определения потенциального ключа).

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

Очевидным способом сокращения множества ФЗ является исключение тривиальных ФЗ.

Функциональная зависимость тривиальна, если ее правая часть является подмножеством левой части. Например, для БД поставщиков и деталей тривиальная ФЗ:

(PNUM, DNUM)®PNUM

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

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

Взаимно-независимые атрибуты — это такие атрибуты, которые не зависят функционально один от другого.