
- •4 Основы проектирования баз данных
- •4.1 Основные цели и этапы проектирования баз данных
- •4.2 Подходы к проектированию и проблемы определения структур данных
- •4.2.1 Подходы к проектированию бд
- •4.2.2Избыточное дублирование данных
- •4.2.3 Аномалии обновления отношений
- •4.2.4 Формирование исходного отношения
- •4.3 Основы теории функциональных зависимостей
- •4.3.1 Общие положения и определение понятия функциональной зависимости данных
- •4.3.2 Виды функциональных зависимостей
- •4.3.3 Аксиомы Армстронга
- •4.4 Метод нормальных форм
- •4.4.1 Цели и порядок проведения нормализации отношений
- •4.4.2 Первая нормальная форма и основная операция нормализации
- •4.4.3 Вторая нормальная форма
- •4.4.4 Третья нормальная форма
- •4.4.5 Нормальная форма Бойса-Кодда
- •4.5 Рекомендации по разработке структур данных
4.3 Основы теории функциональных зависимостей
4.3.1 Общие положения и определение понятия функциональной зависимости данных
При проектировании реляционной базы данных часто приходится делать выбор из множества альтернативных вариантов схем отношений. По различным причинам одни варианты оказываются более удобными, чем другие. Нужно уметь строить хорошую схему базы данных (множество схем отношений). Для этого нужно владеть основами теории функциональных зависимостей между атрибутами отношений.
Основной задачей, решаемой в процессе проектирования БД, является задача нормализации ее отношений. Рассматриваемый ниже метод нормальных форм (классический метод проектирования реляционных БД) основан на фундаментальном в теории реляционных баз данных понятии зависимости между атрибутами отношений.
Во многих случаях из известных фактов о реальном мире следует, что не каждое конечное множество кортежей может быть текущим значением некоторого отношения, даже если бы эти кортежи имели правильную арность и их компоненты были выбраны из правильных доменов. Существуют два вида ограничений на отношения;
Ограничения, которые зависят от семантики элементов домена. Эти ограничения основаны на понимании того, что означают компоненты кортежей. Например, рост человека не может быть равен 6 метрам, как и ни один человек со стажем работы 37 лет не может иметь возраст 25 лет.
Ограничения на отношения, которые зависят только от равенства или неравенства значений. Эти ограничения связаны не с конкретным значением некоторого заданного компонента, а с тем, совпадают ли определенные компоненты двух кортежей. В данном пункте мы обсудим наиболее важные из таких ограничений, называемые функциональными зависимостями (ФЗ),т.к. они имеют наибольшее влияние на проектирование схем БД.
Пусть R ( A1 , A2 ,…, Аn ) — схема отношения, аXиY— подмножества {A1 , A2 , ... , Ап}. Говорят, что «X функционально определяет Y» или «Yфункционально зависит отX», и обозначают это какX Y, если в любом отношении r, являющемся текущим значением R, не могут содержаться два кортежа, компоненты которых совпадают по всем атрибутам, принадлежащим множеству X, но не совпадают по одному или более атрибутам, принадлежащим множеству Y. Возможна более простая формулировка. Атрибут В функционально зависит от атрибута А, т.е. А—>В, если каждому значению А соответствует в точности одно значение В. Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. Здесь А и В могут быть составными - состоять из двух и более атрибутов.
Единственный способ определения функциональных зависимостей для схемы отношения R заключается в том, чтобы внимательно проанализировать семантику атрибутов. Зависимости являются, фактически, высказываниями о реальном мире. Они не могут быть доказаны. Но они должны проводиться в жизнь средствами СУБД, если ей этопредписано. Например, многие системы поддерживают функциональные зависимости, вытекающие из того, что ключ определяет другие атрибуты отношения. Некоторые системы поддерживают даже произвольные функциональные зависимости,
Нужно отметить, что декларация функциональной зависимости в базе данных — это решение, которое может быть принято только проектировщиком. Польза такой декларации заключается, например, в том, что СУБД будет далее поддерживать для пользователя ограничение целостности. Кроме того, благодаря наличию функциональной зависимости, возможно, существует более эффективная реализация отношения.
Понятие функциональной зависимости является базовым, так как на его основе формулируются определения всех остальных видов зависимостей
Пусть, вообще, F есть множество функциональных зависимостей для схемы отношения R и X Y — некоторая функциональная зависимость. Говорят, что зависимость X Y логически следует из F, если для каждого отношения r со схемой R, удовлетворяющего зависимостям из F, удовлетворяется также X Y. Пусть F+ обозначает замыкание F — множество функциональных зависимостей, которые логически следуют из F. Если F = F+, то говорят, что F — полное семейство зависимостей.
Рассматривая наборы объектов, мы предполагали, что существует ключ — множество атрибутов, которое уникально определяет объект. Аналогичное понятие существует и для отношений с функциональными зависимостями. Если R — схема отношения с атрибутами A1 , A2 ,…, Аn и функциональными зависимостями F, а X — подмножество A1 , A2 ,…, Аn, то X называется ключом R, если:
X A1 A2 … Аn принадлежит F+.
Ни для какого собственного подмножества Y ≤ X зависимость Y A1 A2…Аn не принадлежит F+.
Поскольку для отношения может существовать более одного ключа, один из них назначается первичным ключом. Любой ключ по нашему желанию может быть первичным. Используется также термин возможный ключ, обозначающий любое минимальное множество атрибутов, которое функционально определяет все атрибуты, а термин «ключ» резервируется для одного назначенного возможного ключа. Иногда используется термин сверхключ для обозначения любого множества атрибутов, содержащего ключ.
Помимо этого используется термин детерминант. Атрибут (или группа атрибутов) называется детерминантом, если от него функционально зависит какой-либо другой атрибут. Другими словами, если имеется функциональная зависимость A → B, то A – детерминант.