- •Содержание
- •Основные понятия
- •Понятие данных
- •Файловые системы
- •Системы баз данных
- •История развития субд
- •Трехуровневая архитектура ansi/sparc
- •Общая характеристика моделей данных
- •Основные понятия модели данных
- •Представление статических и динамических свойств
- •Общая характеристика структурных компонентов. Множества: домены и атрибуты
- •Общая характеристика структурных компонентов. Отношения: сущности
- •Общая характеристика структурных компонентов. Отношения: связи
- •Общая характеристика ограничений целостности
- •Модель данных «сущность – связь»
- •Уровни представления информации
- •Уровень 1 – информация о сущностях и связях
- •Уровень 2. Структура информации
- •Ограничения целостности в модели сущность-связь
- •Расширенная модель данных сущность-связь: нотация idef1x
- •Реляционная модель данных
- •Базовые структурные компоненты реляционной модели данных
- •Целостная часть реляционной модели данных
- •Языковые средства описания данных
- •Манипуляционная часть реляционной модели данных
- •Подмножество sql для манипулирования данными
- •Примеры написания запросов
- •I. И еще несколько примеров написания запросов из документации [10]
- •Краткая характеристика языка sql pl db2® udb
- •Дополнительные возможности описания ограничений целостности
- •Дополнительные возможности db2
- •Описание данных
- •Манипулирование данными
- •Дополнительные возможности формирования запросов
- •Типы данных, определенные пользователем
- •Функции, определенные пользователем
- •Теория проектирования реляционных баз данных
- •Цели проектирования
- •Функциональные зависимости
- •1. Рефлексивность
- •2. Пополнение
- •3. Транзитивность
- •4. Псевдотранзитивность
- •5. Аддитивность (объединение)
- •6. Декомпозиция (проективность)
- •7. Композиция
- •Нормализация отношений
- •Внутренние структуры хранения
- •Структурная схема обработки запроса
- •Бинарные деревья
- •Многоходовые деревья
- •Сравнение методов индексирования
- •Создание индексов в db2®
- •Организация файлов базы данных в db2®
Функциональные зависимости
Основные понятия
Имеем некоторую схему отношения – R(A1A2…An). Функциональная зависимость представляет собой один из возможных типов зависимостей между атрибутами отношения. Она определяет, что:
значение одного подмножества атрибутов Y ⊆ R зависит от значения другого подмножества X ⊆ R. Например, в приведенном выше отношении ПОСТАВКА_ТОВАРОВ атрибут CITY зависит от атрибута S#;
одному и тому же значению X соответствует одно и то же значение Y.
Возможные способы определения функциональных зависимостей:
есть конкретная реализация отношения r1(R), и для нее на основании анализа конкретных значений атрибутов можно определить функциональные зависимости;
на основе анализа предметной области можно определить функциональные зависимости для всех возможных реализаций отношения r1(R), r2(R), … в разные моменты времени.
Конечно, для проектирования базы данных необходимо использовать второй способ.
Определение функциональной зависимости
Пусть R(A1A2…An) – схема отношения с атрибутами из некоторого универсального множества атрибутов U = {A1, A2, …, An}. Пусть также X ⊆ U и Y ⊆ U – некоторые подмножества множества атрибутов схемы R. Тогда говорят, что Y функционально зависит от X (или X функционально определяет Y) тогда и только тогда, когда для любой допустимой реализации отношения r(R) каждое значение множества атрибутов X связано в точности с одним значением множества атрибутов Y.
Формальная запись: f : X Y
Здесь X – детерминант, а Y – зависимость.
Другими словами, для любой допустимой реализации отношения r(R) если какие-то два кортежа имеют одинаковые значения атрибутов из X, они обязательно имеют и одинаковые значения атрибутов из Y: πY (σX=x (r)) – всегда дает только один кортеж для любого значения x атрибутов X из r.
Примеры:
Очевидный пример: так как первичный ключ PK однозначно определяет каждый кортеж отношения, PK A1A2…An, а также и любое подмножество атрибутов из U.
Из рассматриваемого примера ПОСТАВКА ТОВАРА очевидно, что
S# SNAME
P# PNAME
(S#,P#) QTY
Важно! Функциональные зависимости являются утверждением обо всех реализациях отношения, которые удовлетворяют схеме отношения R. Нельзя, рассматривая конкретную реализацию отношения, на ее основе определить функциональные зависимости.
Рассмотрим пример. Пусть дана некоторая реализация отношения, удовлетворяющая схеме R:
R |
(S# |
P# |
QTY) |
|
S1 |
P1 |
100 |
|
S1 |
P2 |
100 |
|
S2 |
P1 |
200 |
|
S2 |
P3 |
200 |
|
S3 |
P1 |
100 |
Из приведенной реализации можно сделать вывод, что S# QTY. Но в какой-то следующий момент времени в реализации отношения может появиться кортеж <S1, P3, 200>, который нарушает предполагаемую функциональную зависимость.
Как определять функциональные зависимости
Декларация функциональных зависимостей – решение, которое может быть принято только проектировщиком на основе анализа семантики атрибутов. Функциональные зависимости не могут быть доказаны, но они будут претворяться в жизнь средствами СУБД, если ей это предписано (это определяется установленными ограничениями целостности).
На что влияют функциональные зависимости
Функциональные зависимости гарантируют, что СУБД в дальнейшем будет поддерживать определенные ими ограничения целостности.
Возможно, обеспечат более эффективную реализацию отношения.
Но! Делают невозможным хранение некоторой информации.
Рассмотрим пример, иллюстрирующий важность определения функциональных зависимостей. Пусть, например, определена следующая схема отношения: ОТДЕЛ ( Название, Номер помещения, Телефон). Очевидно, что такая схема отношения определяет функциональную зависимость Название Телефон. Возможная реализация отношения:
ОТДЕЛ (Название Номер помещения Телефон)
Бухгалтерия 128 123-4567
… … …
Это означает, что никакой отдел не может иметь несколько телефонов.
Еще один пример. Уже говорилось, что в любом отношении есть функциональная зависимость
PK R. Если для некоторой схемы R кроме указанной функциональной зависимости существуют еще и другие, типа A B, то, вообще говоря, схема отношения R будет характеризоваться некоторой избыточностью. Действительно, рассмотрим следующую схему отношения:
ПОСТАВЩИК (Номер поставщика, Имя, Город, Код города)
В этой схеме определена функциональная зависимость Город Код города. Следовательно, в каждом кортеже для каждого значения атрибута Город будет повторяться соответствующее значение атрибута Код города.
Чем это плохо?
Функциональные зависимости определяют некоторые ограничения целостности, которые должны проверяться при каждом обновлении состояния базы данных. Если таких ограничений много – слишком много времени будет тратиться на их проверку, что, конечно же, не очень хорошо. Например, если в некоторой реализации приведенного выше отношения ПОСТАВЩИК несколько десятков (или более) кортежей имеют одно и то же значение атрибута Город (например, Москва), и поменялся код этого города, необходимо внести изменения во все кортежи отношения.
Таким образом, функциональные зависимости рассматриваются как средство задания ограничений целостности для схемы отношения R, и они будут проверяться.
Вопрос: Как определить все функциональные зависимости? Можно ли, и как, определить минимальное количество функциональных зависимостей?
Замыкание множества функциональных зависимостей
Для каждой схемы отношения существует вполне определенное конечное множество функциональных зависимостей. Некоторые функциональные зависимости определяются проектировщиком из анализа семантики атрибутов. Из них могут быть выведены другие функциональные зависимости. Например, если существует некоторая схема отношения R(A,B,C) и для нее определены функциональные зависимости A B и B C, то интуитивно понятно, что существует и функциональная зависимость A C.
Действительно, рассмотрим два кортежа u ∈ r и v ∈ r, где r – некоторая реализация отношения, удовлетворяющая схеме R. Пусть u[A] = v[A]. Что можно сказать о u[B] и v[B]? u[C] и v[C]? Если эти кортежи не совпадают по атрибуту B, т.е. для этих кортежей u[B] ≠ v[B], значит, нарушена функциональная зависимость A B. Если же кортежи не совпадают по атрибуту C – u[C] ≠ v[C], тогда будет нарушена функциональная зависимость B C.
Рассмотрим некоторые определения.
Определение
Пусть F – множество функциональных зависимостей для схемы отношения R, и имеется еще одна функциональная зависимость f : X Y. Говорят, что функциональная зависимость X Y логически следует из F, если для любой реализации отношения r(R), удовлетворяющей всем зависимостям из F, удовлетворяется также и зависимость X Y.
Пример: Пусть существует схема отношения R(A,B,C), и для нее определено следующее множество функциональных зависимостей F = {A B, B C}. Тогда функциональная зависимость A C логически следует из F.
Определение
Логическим замыканием F (обозначается как F+) называется полное множество функциональных зависимостей, которые логически следуют из F.
Правила вывода Армстронга
Важно иметь возможность из F получить F+. F+ получается из F с помощью специальных правил вывода.
Правила вывода – это правила, устанавливающие, что если некоторая схема отношения R удовлетворяет определенной функциональной зависимости, то оно должно удовлетворять и некоторым другим функциональным зависимостям.
Правила вывода позволяют по заданному множеству F функциональных зависимостей получить F+. Причем эти правила являются:
полными, в том смысле, что для заданного множества F функциональных зависимостей эти правила позволяют вывести все функциональные зависимости, принадлежащие F+;
надежными (исчерпывающими), в том смысле, что, используя их, нельзя вывести из F некоторую функциональную зависимость, не принадлежащую F+.
Рассмотрим правила вывода. Введем следующие обозначения:
R(A1A2…An) – схема отношения;
U = {A1, A2, …An} – универсальное множество атрибутов;
X ⊆ U, Y ⊆ U, Z ⊆ U, W ⊆ U – некоторые подмножества атрибутов из U;
XY – объединение атрибутов: X ∪ Y ≡ XY
