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

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

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

Отсутствие функциональной зависимости обозначается А—/-> В.

Рассмотрим пример с атрибутами ФИО и ГР (год рождения) в отношении R1.

Рисунок 2.4 Отношение (ФИО, ГР)

Предположим, что в столбце ФИО представлены сведения о разных людях и соответствующие значения в столбце не повторяются. Тогда можно утверждать наличие функциональной зависимости ФИО -> ГР, поскольку каждому значению атрибута ФИО в отношении R1 соответствует единственное значение атрибута ГР. Можно утверждать, что это ограничение будет соблюдаться и далее, так как оно перефразируется в утверждение: у каждого человека единственный год рождения, которое справедливо.

Практически каждое ограничение для проверки функциональной зависимости можно преобразовать в утверждение о свойствах объектов предметной области, которое можно проверить, не анализируя множество значений соответствующего отношения. Именно так мы и будем поступать в дальнейшем. Наличие в столбце ГР повторяющихся годов (1960) не опровергает установленной нами зависимости, но это означает ГР —/-> ФИО.

Одновременное соблюдение двух зависимостей вида А —> В и В —> А называется взаимно-однозначным соответствием и обозна­чается А <--> В.

В качествепримера рассмотрим отношение R2 с атрибутами Магазин и Расч (номер расчетного счета).

Рисунок 2.5 Отношение R2(Магазин, Расч)

Можно утверждать, что у каждого магазина единственный номер расчетного счета и каждый расчетный счет принадлежит единственному магазину. Это доказывает справедливость функциональных зависимостей Магазин —> Расч и Расч —> Магазин, т.е. Магазин < —>Расч.

Наконец, самыми распространенными являются случаи отсутствия функциональных зависимостей, например, ФИО —/—> Дисциплина и Дисциплина —/-> ФИО в отношении R3, описывающем экзамены студентов. Здесь каждый студент сдает экзамены по нескольким дисциплинам, и по каждой дисциплине экзамен сдается многими студентами.

Рисунок 2.6 Отношение R3 (ФИО, Дисциплина)

Таким образом, для атрибутов А и В некоторого отношения возможны следующие ситуации:

- отсутствие функциональной зависимости,

- наличие А —> В (или В —> А), но не обе зависимости вместе,

- наличие взаимно –однозначного соответствия А< —> В.

Понятие функциональной зависимости распространяется на ситуацию с тремя и более атрибутами в следующей форме. Группа атрибутов (для определенности А,В,С) функционально определяет атрибут D в отношении T(A,B,C,D,....), если каждому сочетанию значений (а,Ь,с) соответствует единственное значение d (а - значение A, b - значение В, с - значение С, d - значение D). Наличие такой функциональной зависимости будем обозначать А,В,С —> D.

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

Рисунок 2.7 Отношение Т1(ФИО, Дисц., Дата, Преподав., Оценка)

ФИО, Дата —> Дисциплина,

ФИО, Дата —> Преподаватель,

ФИО, Дата —> Оценка.

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

Для показателя со множеством атрибутов-признаков Р= {Р 1 ,Р2,... ,Рп} и атрибутом-основанием Q справедлива функциональная зависимость Р —> Q, хотя нельзя утверждать, что это единственная зависимость на указанных атрибутах.

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

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

Рассмотрим пример: отношение ТЗ (имена и значения атрибутов - условные):

Рисунок 2.8 Отношение Т3 (ZEN, RAM, AST, SРМ, BIG)

Можно утверждать, что вероятным ключом отношения ТЗ является атрибут ZEN (значения в столбце ZEN не повторяются). Кроме того, еще один вероятный ключ представлен парой атрибутов RAM, AST.

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

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

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

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

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

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

Каждое значение первичного ключа встречается только в одной строке отношения. Значение любого атрибута в этой строке также единственное. Если через К обозначить атрибуты первичного ключа в отношении R(A,B,C,... ,J), то справедливы следующие функциональные зависимости К —> А, К —> В, К —>С,..., К —> J. Набор атрибутов первичного ключа функционально определяет любой атрибут отношения. Обратное также верно: если найдена группа атрибутов, которая функционально определяет все атрибуты отношения по отдельности, и эту группу нельзя сократить, то найден первичный ключ отношения.

Вернемся к отношению Т1 с функциональными зависимостями:

ФИО, Дата —> Дисциплина,

ФИО, Дата —> Преподаватель,

ФИО, Дата —> Оценка.

Нетрудно установить, что

ФИО, Дата —> ФИО,

ФИО, Дата — > Дата

(в каждом сочетании значений ФИО, Дата значение ФИО встречается один раз). Следовательно, первичный ключ в отношении Т1 составляют атрибуты ФИО, Дата и при поиске ключа не потребовались конкретные значения Т1.

Знание ключа отношения позволяет устанавливать ряд функциональных зависимостей, например, в ТЗ ZEN—> BIG, RAM, AST —> BIG.

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

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

Центральная задача проектирования базы данных ЭИС - определение количества отношений (или иных составных единиц информации) и их атрибутного состава.

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

- минимальность избыточности представления информации,

- корректировка отношений не должна приводить к двусмысленности или потере информации,

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

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

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

Отношение в первой нормальной форме (сокращенно 1 НФ) - это обычное отношение с двухуровневой структурой. Недопустимость в структуре отношения третьего и последующих уровней является ограничением, определяющим 1НФ отношения.

Следует отметить определенное терминологическое несоответствие - нормализация СЕИ приводит к 1НФ, а нормализация отношений реляционной БД обычно производится до ЗНФ или 4НФ.

Реляционная база данных в целом характеризуется 1НФ, если все ее отношения соответствуют 1НФ.

2.4 Вторая и третья нормальные формы отношений

Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и не содержит неполных функциональных зависимостей.

Неполная функциональная зависимость - это две зависимости:

- вероятный ключ отношения функционально определяет некоторый неключевой атрибут,

- часть вероятного ключа функционально определяет этотже неключевой атрибут.

Отношение, не соответствующее 2НФ, характеризуется избыточностью хранимых данных.

Например: Функциональные зависимости отношения Т4:

Рисунок 2.9 Отношение Т4(Магазин, Изделие, Цена, План)

(1) Магазин, Изделие—> План 2006 г.,

(2) Изделие —>Цена.

Вероятным ключом в Т4 являются атрибуты Магазин, Изделие. Для доказательства можно сослаться на функциональные зависимости:

Магазин, Изделие —> План 2006 г.,

(3) Магазин, Изделие —> Цена,

(4) Магазин, Изделие —> Магазин,

(5) Магазин, Изделие —> Изделие.

Зависимости (3) и (2) вместе образуют неполную функциональную зависимость, по этой причине отношение Т4 находится лишь в 1НФ,а не во2НФ.

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

Т41=Т4[Магазин, Изделие, План 2006 г.], Т42=Т4[Изделие, Цена] (рис.2.10).

Ключом в Т41 служат атрибуты Магазин, Изделие; в Т42 -Изделие, и легко определить, что оба отношения соответствуют требованиям 2НФ.

База данных находится в 2НФ, если все ее отношения находятся в 2НФ.

Рисунок 2.10 База данных во 2НФ

Отношение соответствует ЗНФ, если оно соответствует 2НФ и среди его атрибутов отсутствуют транзитивные функциональные зависимости (ФЗ).

Транзитивная ФЗ - это две ФЗ:

- вероятный ключ отношения функционально определяет не ключевой атрибут,

- этот атрибут функционально определяет другой не ключевой атрибут.

Если К - ключ отношения. А, В - не ключевые атрибуты и К —> А, А —> В - справедливые ФЗ, то они являются транзитивными. Частный случай транзитивной ФЗ - неполная ФЗ, когда К = (С,Е) и К—> Е, а Е—>А.

Рассмотримпример.Функциональные зависимости Т5:

Рисунок 2.11База данных

(6) ФИО —> Группа,

(7) Группа —>Факультет,

(8) ФИО —> Факультет.

Ключ отношения Т5 - ФИО. Зависимости (6) и (7) вместе образуют транзитивную ФЗ, поэтому Т5 находится в 2НФ, но не в ЗНФ.

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

Переход от Т5 к отношениям в ЗНФ дает следующие результаты:

Т51=Т5[ФИО, Группа],

Т52=Т5[Группа, Факультет].

Рисунок 2.12 База данных в 3НФ

2.5 Ациклические базы данных

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

Если в отношении R(A,B,C) существует многозначная зависимость (МЗ), например А ->->В (многозначное определение), то при этом А->->С, т.к. многозначные зависимости всегда встречаются парами.

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

Для определения понятия ациклической схемы БД введем граф соединений на множестве отношений {Sl,S2,...,Sk}. Вершинами графа соединений являются имена отношений. Дуга графа, содержащего 2 вершины, существует, если между ними имеется общий атрибут. Этот атрибут называется весом дуги.

Рис. 2.13. Пример графа соединений:

На рисунке (а) изображён цикл, который можно разорвать, и получится ациклическая БД (рисунок б). На рисунке (в) изображена циклическая БД.

Алгоритм проверки структуры БД на ацикличность:

Шаг 1. Если некоторый атрибут встречается только в одном отношении, вычеркнуть данный атрибут из этого отношения.

Шаг 2. Если все атрибуты некоторого отношения находят­ся среди атрибутов другого отношения, то первое отношение вычеркивается из списка.

Шаги 1 и 2 можно применять в любой последовательности.

Если в результате будут вычеркнуты все отношения, то БД является ациклической. В обратном случае - БД циклическая.

Восстановление свойств ацикличности БД может быть произведено двумя способами.

1- Добавление в БД нового отношения с атрибутами, рав­ными объединению весов дуг, образующих цикл. В этом случае возможны неопределенные значения в новом отношении.

2- Добавление новых атрибутов, переименование и разделение атрибутов. Такое решение не создает дополнительных неопределенностей.

Рассмотрим, например, зависимости: Служащий —>Отдел и От­дел, Заказчик —> Тема. Это ситуация, показанная на рис.в). Для преодоления цикличности необходимо разделить роли атрибута Отдел, например, ввести атрибут «Отдел_служащего».

Циклическая база данных может содержать два, три и более циклов. Поэтому после преобразования БД рекомендуется заново проверить её на ацикличность.

2.6 Сетевая модель данных

Информационными конструкциями в сетевой модели дан­ных являются отношения и веерные отношения, хотя в некоторых сетевых СУБД допускаются от­ношения с многоуровневой (три и более) структурой.

Сетевая БД представляется как множество отношений и ве­ерных отношений. Отношения разделяются на основные и за­висимые.

Веерным отношением W(R,S) называется пара отношений, состоящая из одного основного R, одного зависимого отноше­ния S и связи между ними при условии, что каждое значение зависимого отношения связано с единственным значением ос­новного отношения.

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

Допустимые в сетевой модели данных операции представ­ляют собой различные варианты выборки.

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

Ограничение двухуровневых сетей состоит в том, что каж­дое отношение может существовать в одной из перечисленных ниже ролей:

- вне каких-либо веерных отношении,

- в качестве основного отношения в любом количестве ве­ерных отношений,

- в качестве зависимого отношения в любом количестве ве­ерных отношений.

Многоуровневые сети не предусматривают никаких ограни­чений на взаимосвязь веерных отношений.

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

Для двухуровневых сетевых СУБД вводятся еще два огра­ничения (с теоретической точки зрения необязательные):

- первичный ключ основного отношения может быть толь­ко одноатрибутным,

- веерное отношение существует, если первичный ключ ос­новного отношения является частью первичного ключа зависимого отношения.