Функциональная зависимость атрибутов

 

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

В следующем примере отношения

ПЕРСОНАЛ(Табельный номер, ФИО, Должность, Номер проекта, Дата окончания)

можно определить следующие функциональные зависимости:

Табельный номер ФИО

Табельный номер Должность

Табельный номер Номер проекта

Номер проекта Дата окончания

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

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

Например, пусть имеется множество атрибутов А, В, С и их значения, собранные в отношении R.

А	В	С
M
N
M
L
N
L

 

А	В	С
M
M
N
N
L
L

Попытаемся установить следующие зависимости А В и А С. Для этого отсортируем отношение по домену А:

 

 

Из таблицы видно, что каждому значению атрибута А соответствует только одно значение атрибута В и разные значения атрибута С. Следовательно А функционально определяет В, а С не зависит от А.

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

Табельный номер Номер проекта Дата окончания

Здесь Дата окончания зависит от атрибута Табельный номер через Номер проекта, т.е. имеет место транзитивная зависимость.

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

 

Вторая нормальная форма

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

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

ЗАКАЗ(Код поставщика, Код товара, Наименование поставщика, Адрес, Наименование товара, Характеристики товара, Цена)

В этом отношении ключ состоит из пары атрибутов Код поставщика, Код товара. При этом Наименование поставщика, Адрес функционально зависят от атрибута Код поставщика, Наименование товара, Характеристики товара зависят от Код товара, а Цена от ключа отношения. Такое разнообразие функциональных зависимостей приводит к следующим проблемам.

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

Если из отношения удаляются сведения о поставщике, то удалятся и сведения о товарах.

Для изменения адреса поставщика, наименование товара нужно проделывать это в нескольких строках отношения.

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

ПОСТАВЩИКИ(Код поставщика, Наименование поставщика, Адрес)

ТОВАРЫ(Код товара, Наименование товара, Характеристики товара)

ЗАКАЗ(Код поставщика, Код товара, Цена)

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

 

Третья нормальная форма

 

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

ПЕРСОНАЛ(Табельный номер, ФИО, Должность, Номер проекта, Дата окончания)

Дата окончания зависит от ключа через Номер проекта. Наличие транзитивной зависимости приводит к следующим проблемам:

1. при известных номере проекта и дате окончания их негде разместить пока не появятся сведения хотя бы об одном исполнителе;

2. Если изменилась дата окончания проекта, ее надо менять в стольких кортежах, сколько людей работает над данным проектом.

Устранение этих проблем можно сделать, преобразовав исходное отношение к третьей нормальной форме:

ПЕРСОНАЛ(Табельный номер, ФИО, Должность, Номер проекта)

ПРОЕКТЫ(Номер проекта, Дата окончания)

Такое преобразование решает все отмеченные проблемы. Действительно, в отношение ПРОЕКТЫ заносятся сведения о существующих проектах независимо от того, работает над ними кто либо. При изменении даты окончания корректировка вносится только в один кортеж отношения ПРОЕКТЫ.

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

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

 

Схема проектирования реляционной модели данных (эмпирический подход)

 

Для создания реляционной модели данных при разработке базы данных для заданного объекта – предприятия необходимо выполнить следующие действия:

· Обследование информационной деятельности предприятия;

· Анализ информационных потоков и интеграция требований;

· Проектирование сетевой модели, отражающей структуру и информационные связи предприятия;

· Преобразование сетевой модели к реляционной;

· Нормализация отношений реляционной модели

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

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

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

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

Основы реляционной алгебры

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

Реляционной алгеброй или алгеброй отношений называют систему операций манипулирования отношениями, каждый оператор которой в качестве операнда (операндов) имеет одно или несколько отношений, образуя новое отношение по заранее обусловленному правилу. Основными операциями реляционной алгебры являются:

Операция проекции;

Операция объединения;

Операция разности;

Операция декартова произведения;

Операция селекции.

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

Операция проекции

Обозначение π_R(A).

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

Пример.

Сессия

Студент	Предмет	Семестр	Оценка
А..	Математика
А…	Информатика
Б..	Математика
Б…	Информатика
Б…	История
В...	Математика
В...	Информатика
В...	История

 

Проекция отношения π_{Сессия(Студент)} будет выглядеть так:

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Математика

 

 

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

Операция объединения

Обозначение операции R U S. Объединение отношений R и S представляет собой множество кортежей, которые принадлежат отношениям либо R, либо S, либо им обоим. Для того, чтобы объединение было возможным, отношения операнды (R и S) должны быть совместимы для объединения – количество и типы объединяемых доменов должны быть одинаковы.

Пример. Пусть даны два отношения результатов сессии за 1 и 2 семестр.

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Математика

Сессия1

 

 

Сессия2

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Информатика
В...	История

 

 

Выполнение операции Сессия1 U Сессия2

Студент	Предмет	Семестр	Оценка
А..	Математика
Б..	Математика
В...	Математика
А..	Математика
Б..	Математика
В...	Информатика
В...	История

 

Операция разности

Математическое обозначение R – S.

Разностью отношений называется множество кортежей входящих в R, но не входящих в S. Замечание по совместимости отношений справедливо и для разности.

Пример. Пусть даны списки студентов получивших зачет и экзамен. Требуется выявить студентов, сдавших только зачет.

Зачет Экзамен Зачет – Экзамен

ФИО

Аверьянов

Грачев

 

ФИО

Аверянов

Баранов

Вольский

Грачев

Григорьев

Дмитриев

ФИО

Баранов

Вольский

Григорьев

Дмитриев

Петров

Семенов