Зависимости между атрибутами

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

Обознач-ся:А В

2. Если существует функциональная зависимость вида А В и В А, то между А и В имеется взаимосвязанное соответствие или функциональная взаимозависимость

Обозн: А В

Частичная функциональная зависимость это зависимость неключевого атрибута от части составного ключа.

Полная функциональная зависимость

Когда неключевой атрибут полностью зависит от составного ключа.

Пр: Кафедра(ФИО, должен, оклад, стаж, д_стаж, кафедра, предмет, группа, вид занятий)

ФИО кафедра

ФИО должность

Атрибут С зависит от А транзитивно если для атрибутов А,В,С выполняется условие А В и В С, но нет обратной зависимости А С

Пример. ФИО должность оклад

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

Обозн. А В, А В, А В ФИО предмет

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

Два или более атрибутов называются взаимонезависимыми, если не один из этих атрибутов не зависит функционально от других атрибутов (Обозн. А¬
В).

Выявление зависимостей между атрибутами

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

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

A1 A3

Кроме того, А2 ¬ А1, А3 ¬ А1

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

Зная некоторые функциональные зависимости, с помощью аксиом вывода можно получить полное множество F + для какого-либо отношения.

Для отношения “кафедра”:

ФИО оклад

ФИО должность

ФИО стаж

ФИО кафедра

ФИО д_стаж

Стаж д_стаж

Должность оклад

Оклад должность

ФИО.Преподаватель.Группа Вид занятий

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

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

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

2НФ В основном используются три нормальных формы.

Для всех нормальных форм соблюдается правило вложенности

Преимущества нормализации :

Лучшая организация БД, что облегчает работу пользователям и администраторам БД.

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

Минимизируется дублируемая информация.

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

Большая безопасность БД.

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

Недостатки :

Снижение производительности при выполнении запросов в БД.

Определения:

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

Значение является не атомарным, если оно используется приложением по частям.

Перевод отношения в следующую нормальную форму осуществляется методом декомпозиции без потерь.

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

Основной операцией в методе является операция проекции.

r (A,B,C,D,E) C D

r1(A,B,C,E) r2(C,D)π CD (r)

Частичная зависимость от ключа неключевых атрибутов приводит к следующему:

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

Следствием избыточного дублирования является проблема редактирования данных. Часть избыточности устраняется при переходе в 2НФ.

Отношение находится в 2НФ, если:

Отношение находится в 1НФ.

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

Для устранения частичной зависимости и перевода отношения в 2НФ необходимо:

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

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

В результате получим два отношения r1,r2, находящихся во 2НФ:

			Вид занятий
Иванов И.М			Практика
Иванов И.М			Практика
Петров М.И
Петров М.И			Практика
Сидоров Н.Г
Сидоров Н.Г
Егоров В.В

Переход ко 2НФ позволяет исключить явную избыточность данных в отношении r2, тем не менее, дублирование данных сохраняется и поэтому необходимо преобразоватьr2 в 3НФ.

Опр.1: Отношение находится в 3НФ, если:

Удовлетворяются все требования 2НФ.

Если каждый неключевой атрибут не транзитивно зависит от первичного ключа.

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

ФИО оклад должность

ФИО стаж Д_стаж

ФИО должность оклад

Транзитивные зависимости также порождают избыточное порождение данных.

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

В результате получим:

	Д_стаж

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

Если в отношении имеется зависимость атрибутов составного ключа от неключевых атрибутов, то необходимо перейти к усиленной 3НФ, она называется НФБК.

Опр. Отношение находится в НФБК, если оно находится в 3НФ, и в нем отсутствуют зависимости ключей (атрибутов составного ключа) от неключевых атрибутов.

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

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

Информация > формализация >> данные

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

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

Функциональная зависимость: «правильное решение = программа (программист)» и условие: «непрерывное соответствие задаче» действительны в большинстве случаев, но только совместно. Но это не та математическая основа, которая применяется при создании баз данных.

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

и базы данных

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

Основные варианты хранения, отличающиеся вариантами использования данных:

• файлы;
• базы данных.

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

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

Личный опыт и коллективный разум

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

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

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

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

• солидный Oracle;
• требовательный MS SQL Server;
• популярный MySQL.

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

Особенности программирования и данных

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

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

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

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

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

БД: простая зависимость в данных

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

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

Имя каждой колонки в каждой таблице должно быть уникальным в контексте задачи. Одно и то же данное не может быть в двух таблицах. Знать смысл понятий:

• «определить сущности»;
• «исключить избыточность»;
• «зафиксировать взаимосвязи»;
• «обеспечить достоверность».

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

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

Функциональная зависимость: логика и смысл

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

Не обязательно, но вовсе не помешает представлять функциональную зависимость как:

F(x1, x2, …, xN) = (y1, y2, …, yN).

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

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

Можно утверждать, что свойства функциональных зависимостей базы данных доступны через диалект используемого языка SQL. Но гораздо важнее понимать: после всех перипетий развития, не так много баз данных выжило, но диалектов этого языка много и особенностей внутренних конструкций в базах тоже.

О старом добром Excel

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

• PHP, Perl, JavaScript, C++, Delphi.
• MySQL, Oracle, Visual FoxPro.

• Word.
• Excel.

Некоторые пользователи умудряют делать самостоятельно (без помощи программистов) в Word базы данных - реальный нонсенс.

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

Табличная идея, определила понятие функциональной зависимости наглядно и доступно, но нюансы есть у каждой базы данных. У каждой свое «лицо», но все от Excel до Oracle манипулируют простыми квадратами, то есть таблицами.

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

Что такое функциональная зависимость, с чем, куда, почему… очевидно только автору или коллективу таковых.

О том, куда реляционные отношения идут

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

Как бы ни была прекрасна функциональная зависимость в контексте математики:

Это не бинарные отношения, точнее, это повод переосмыслить идею устанавливать отношения между множеством атрибутов, исследовать связи «один к многим», «многие к одному», «многие ко многим» или «многие вообще, а одни в частности».

Вариантов отношений можно придумать великое множество. Это математика с логикой, и она строгая! Информация - это своя математика, особенная. В ней о формальности можно говорить только с очень большим минусом.

Можно формализовать работу отдела кадров, написать АСУ для добычи нефти или производства молока, хлеба, сделать выборку в огромной базе гугла, яндекса или рамблера, но результат будет всегда статичен и каждый момент времени одинаков!

Если функциональная зависимость = строгая логика и математика = основа для баз данных, то о какой динамике можно вести речь. Любое решение будет формальным, любая формальная модель данных + строгий алгоритм = точное и однозначное решение. Информация и область применения любой программы меняются всегда.

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

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

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

Если сменить тон и прислушаться к пульсу динамики, то все можно расписать на объекты. В первом приближении имя колонки в таблице - это объект, список имен - тоже объект, короче таблица - это объект шапки и в нем имена колонок в шапке. И шапки может вовсе не быть...

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

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

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

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

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

Сессия (№ зачетной книжки , Фамилия, Имя, Отчество, Предмет , Оценка);

Атрибуты «№ зачетной книжки» и «Предмет» образуют составной (так как ключом объявлены два атрибута) первичный ключ этого отношения. Действительно, по двум этим атрибутам можно однозначно определить значения всех остальные атрибутов.

Однако, помимо ограничения уникальности, связанной с этим ключом, на отношение непременно должно быть наложено то условие, что одна зачетная книжка выдается обязательно одному конкретному человеку и, следовательно, в этом отношении кортежи с одинаковым номером зачетной книжки должны содержать одинаковые значения атрибутов «Фамилия», «Имя» и «Отчество».

Если у нас имеется следующий фрагмент какой-то определенной базы данных студентов учебного заведения после какой-то сессии, то в кортежах с номером зачетной книжки 100, атрибуты «Фамилия», «Имя» и «Отчество» совпадают, а атрибуты «Предмет» и «Оценка» – не совпадают (что и понятно, ведь в них речь идет о разных предметах и успеваемости по ним). Это значит, что атрибуты «Фамилия», «Имя» и «Отчество» функционально зависят от атрибута «№ зачетной книжки», а атрибуты «Предмет» и «Оценка» функционально не зависят.

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

Теперь дадим строгое определение функциональной зависимости.

Определение : пусть X, Y – подсхемы схемы отношения S, определяющие над схемой S схему функциональной зависимости X > Y (читается «X стрелка Y»). Определим ограничения функциональной зависимости inv > Y> как утверждение о том, что в отношении со схемой S любые два кортежа, совпадающие в проекции на подсхему X, должны совпадать и в проекции на подсхему Y.

Запишем это же определение в формулярном виде:

Inv > Y> r (S ) = t 1 , t 2 ? r (t 1 [X ] = t 2 [X ] ? t 1 [Y ] = t 2 [Y ]), X , Y ? S;

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

Интересно заметить, что в случае функциональной зависимости Y от X, говорят также, что X функционально определяет Y или что Y функционально зависит от X. В схеме функциональной зависимости X > Y подсхема X называется левой частью, а подсхема Y – правой частью.

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

Конец определения .

В частном случае, когда правая часть функциональной зависимости, т. е. подсхема Y, совпадает со всей схемой отношения, ограничение функциональной зависимости переходит в ограничение уникальности первичного или кандидатного ключа. Действительно:

Inv <K > S > r (S ) = ? t 1 , t 2 ? r (t 1 [K ] = t 2 [K ] > t 1 (S ) = t 2 (S )), K ? S ;

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

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

{№ зачетной книжки} > {Фамилия, Имя, Отчество};

{№ зачетной книжки, Предмет} > {Оценка};

2. Правила вывода Армстронга

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

Хорошим примером таких специальных правил являются правила вывода Армстронга.

Но прежде чем приступать к анализу самих правил вывода Армстронга, введем в рассмотрение новый металингвистический символ «+», который называется символом метаутверждения о выводимости . Этот символ при формулировании правил записывается между двумя синтаксическими выражениями и свидетельствует о том, что из формулы, стоящей слева от него, выводится формула, стоящая справа от него.

Сформулируем теперь сами правила вывода Армстронга в виде следующей теоремы.

Теорема. Справедливы следующие правила, называемые правилами вывода Армстронга.

Правило вывода 1. + X > X;

Правило вывода 2. X > Y+ X ? Z > Y;

Правило вывода 3. X > Y, Y ? W > Z + X ? W > Z;

Здесь X, Y, Z, W – произвольные подсхемы схемы отношения S. Символ метаутверждения о выводимости разделяет списки посылок и списки утверждений (заключений).

1. Первое правило вывода называется «рефлексивность » и читается следующим образом: «выводится правило: “X функционально влечет за собой X”». Это самое простое из правил вывода Армстронга. Оно выводится буквально из воздуха.

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

2. Второе правило вывода называется «пополнение » и читается таким образом: «если X функционально определяет Y, то выводится правило: “объединение подсхем X и Z функционально влечет за собой Y”». Правило пополнения позволяет расширять левую часть ограничения функциональных зависимостей.

3. Третье правило вывода называется «псевдотранзитивность » и читается следующим образом: “если подсхема X функционально влечет за собой подсхему Y и объединение подсхем Y и W функционально влекут за собой Z, то выводится правило: «объединение подсхем X и W функционально определяют подсхему Z»”.

Правило псевдотранзитивности обобщает правило транзитивности, соответствующее частному случаю W: = 0. Приведем формулярную запись этого правила:

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

Правило вывода 1. inv X> r(S);

Правило вывода 2. inv Y> r(S) ? inv Y> r(S);

Правило вывода 3. inv Y> r(S) & inv Z> r(S) ? inv Z> r(S);

Проведем доказательства этих правил вывода.

1. Доказательство правила рефлексивности следует непосредственно из определения ограничения функциональной зависимости при подстановке вместо подсхемы Y – подсхемы X.

Действительно, возьмем ограничение функциональной зависимости:

Inv Y> r(S) и подставим в него X вместо Y, получим:

Inv X> r(S), а это и есть правило рефлексивности.

Правило рефлексивности доказано.

2. Доказательство правила пополнения проиллюстрируем на диаграммах функциональной зависимости.

Первая диаграмма – это диаграмма посылки:

посылка: X > Y

Вторая диаграмма:

заключение: X ? Z > Y

Пусть кортежи равны на X ? Z. Тогда они равны на X. Согласно посылке они будут равны и на Y.

Правило пополнения доказано.

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

Первая диаграмма – первая посылка:

посылка 1: X > Y

посылка 2: Y ? W > Z

И, наконец, третья диаграмма – диаграмма заключения:

заключение: X ? W > Z

Пусть кортежи равны на X ? W. Тогда они равны и на X, и на W. Согласно Посылке 1, они будут равны и на Y. Отсюда, согласно Посылке 2, они будут равны и на Z.

Правило псевдотранзитивности доказано.

Все правила доказаны.

3. Производные правила вывода

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

Что это за правила, как они получаются?

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

Необходимо специально отметить, что эти самые произвольные правила являются «производными» именно от пройденных нами ранее правил вывода Армстронга.

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

Теорема.

Следующие правила являются производными от правил вывода Армстронга.

Правило вывода 1. + X ? Z > X;

Правило вывода 2. X > Y, X > Z + X ? Y > Z;

Правило вывода 3. X > Y ? Z + X > Y, X > Z;

Здесь X, Y, Z, W, так же как и в предыдущем случае, – произвольные подсхемы схемы отношения S.

1. Первое производное правило называется правилом тривиальности и читается следующим образом:

«Выводится правило: “объединение подсхем X и Z функционально влечет за собой X”».

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

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

2. Второе производное правило называется правилом аддитивности и читается следующим образом: «Если подсхема X функционально определяет подсхему Y, и X одновременно функционально определяет Z, то из этих правил выводится следующее правило: “X функционально определяет объединение подсхем Y и Z”».

3. Третье производное правило называется правилом проективности или правилом «обращение аддитивности ». Оно читается следующим образом: «Если подсхема X функционально определяет объединение подсхем Y и Z, то из этого правила выводится правило: “X функционально определяет подсхему Y и одновременно X функционально определяет подсхему Z”», т. е., действительно, это производное правило является обращенным правилом аддитивности.

Любопытно, что правила аддитивности и проективности применительно к функциональным зависимостям с одинаковыми левыми частями позволяют объединять или, наоборот, расщеплять правые части зависимости.

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

Проведем доказательства перечисленных произвольных правил вывода.

1. Доказательство правила тривиальности .

Проведем его, как и все последующие доказательства, по шагам:

1) имеем: X > X (из правила рефлексивности вывода Армстронга);

Правило тривиальности доказано.

2. Проведем пошаговое доказательство правила аддитивности :

1) имеем: X > Y (это посылка 1);

2) имеем: X > Z (это посылка 2);

3) имеем: Y ? Z > Y ? Z (из правила рефлексивности вывода Армстронга);

4) имеем: X ? Z > Y ? Z (получаем при помощи применения правила псевдотранзитивности вывода Армстронга, а потом как следствие первого и третьего шагов доказательства);

5) имеем: X ? X > Y ? Z (получаем, применяя правило псевдотранзитивности вывода Армстронга, а после следует из второго и четвертого шагов);

6) имеем X > Y ? Z (следует из пятого шага).

Правило аддитивности доказано.

3. И, наконец, проведем построение доказательства правила проективности :

1) имеем: X > Y ? Z, X > Y ? Z (это посылка);

2) имеем: Y > Y, Z > Z (выводится при помощи правила рефлексивности вывода Армстронга);

3) имеем: Y ? z > y, Y ? z > Z (получается из правила пополнения вывода Армстронга и следствием из второго шага доказательства);

4) имеем: X > Y, X > Z (получается, применением правила псевдотранзитивности вывода Армстронга, а затем как следствие из первого и третьего шагов доказательства).

Правило проективности доказано.

Все производные правила вывода доказаны.

4. Полнота системы правил Армстронга

Пусть F (S ) - заданное множество функциональных зависимостей, заданных над схемой отношения S.

Обозначим через inv <F (S )> ограничение, накладываемое этим множеством функциональных зависимостей. Распишем его:

Inv <F (S )> r (S ) = ?X > Y ?F (S ) [inv Y> r (S )].

Итак, это множество ограничений, накладываемое функциональными зависимостями, расшифровывается следующим образом: для любого правила из системы функциональных зависимостей X > Y, принадлежащего множеству функциональных зависимостей F (S ), действует ограничение функциональных зависимостей inv Y> r (S ), определенных над множеством отношения r (S ).

Пусть какое-то отношение r (S ) удовлетворяет этому ограничению.

Применяя правила вывода Армстронга к функциональным зависимостям, определенным для множества F (S ), можно получить новые функциональные зависимости, как уже было сказано и доказано нами ранее. И, что показательно, ограничениям этих функциональных зависимостей отношение F (S ) будет автоматически удовлетворять, что видно из расширенной формы записи правил вывода Армстронга. Напомним общий вид этих расширенных правил вывода:

Правило вывода 1. inv < X > X > r (S );

Правило вывода 2. inv Y> r (S ) ? inv ? Z > Y> r (S );

Правило вывода 3. inv Y> r (S ) & inv ? W > Z> r (S ) ? inv ? W > Z>;

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

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

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

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

Если записать только что сказанное в формулярном виде, то получим:

F (S ) ? F + (S ), [F + (S )] + = F + (S );

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

X > Y ? F + (S ) ? ?r (S ) [inv <F (S )> r (S ) ? inv Y> r (S )];

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

(Доказательство этой теоремы мы рассматривать не будем, так как сам процесс доказательства не столь важен в нашем конкретном курсе лекций.)

Метод нормальных форм

Преподаватель

ФИО	Долж	Оклад	Стаж	Надб	Каф	Предм	Группа	ВидЗан
Иванов И.М.	преп					СУБД		Лабор
Иванов И.М.	Преп					Информ		Лабор
Петров М.И.	Ст.преп					СУБД		Лекция
Петров М.И.	Ст.преп					Графика		Лабор
Сидоров Н.Г.	Преп					Информ		Лекция
Сидоров Н.Г.	Преп					Графика		Лекция
Егоров В.В.	Преп					ПЭВМ		Лекция

Рис. 6.4. Исходное отношение ПРЕПОДАВАТЕЛЬ

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

Исключение избыточности состоит в нормализации отношений.

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

Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональная зависимость В от А обозначается записью А ® В. Это означает, что во всех кортежах с одинаковым значением атрибута а АТРИБУТ в БУДЕТ ИМЕТЬ ТАКЖЕ ОДНО И ТО ЖЕ ЗНАЧЕНИЕ. Атрибуты А и В могут быть составными – состоять из двух и более атрибутов. В отношении Преподаватель Функциональные зависимости следующие: ФИО ® Каф, ФИО ® Долж, Долж ® Оклад и др.

Функциональная взаимозависимость. Если существует функциональная зависимость вида А ® В и В ® А, то между А и В имеется взаимно однозначное соответствие, или функциональная взаимозависимость. Математически взаимозависимость обозначается как А « В или В « А.

Пример. Атрибут N (серия и номер паспорта) находится в функциональной взаимозависимости с атрибутом ФИО (фамилия, имя и отчество), если предполагается, что ситуация наличия в отношении полного совпадения фамилий, имен и отчеств у двух людей исключена.

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

Полная функциональная зависимость – зависимость неключевого атрибута от всего составного ключа. Например, атрибут ВидЗан находится в полной функциональной зависимости от составного ключа.

Атрибут С зависит от атрибута А транзитивно (существует транзитивная зависимость ), если для атрибутов А, В, С выполняются условия А ® В и В ® С, но обратная зависимость отсутствует. В примере транзитивной зависимостью связаны атрибуты:

ФИО ® Долж ® Оклад

В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R. Многозначные зависимости могут быть «один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М:М), Обозначаемые соответственно: А Þ В, А Ü В и А Û В.

В рассматриваемом примере имеется многозначная зависимость М:М между атрибутами ФИО Û Предмет (один преподаватель может вести несколько предметов и один предмет могут вести несколько преподавателей).

Поскольку зависимость между атрибутами является причиной аномалий, то стараются такие отношения разделить на несколько отношений. В результате образуется совокупность связанных отношений (таблиц) со связями вида 1:1, 1:М, М:1 и М:М. Связи между таблицами отражают зависимости между атрибутами различных отношений.

Взаимно независимые атрибуты. Два или более атрибутов называются взаимно независимыми, если ни один из этих атрибутов не является функционально зависимым от других атрибутов. Математически отсутствие зависимости атрибута А от атрибута В обозначается как А Ø® В. Если имеет место А Ø® В и В Ø® А, то взаимная независимость обозначается А Ø= В.

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

Пример. Пусть задано отношение R со схемой R(А1, А2, А3) вида:

А1	А2	А3

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

А1®А2 и А2®А3.

Из анализа видно, что в отношении существуют еще зависимости:

А1®А3, А1А2®А3, А1А2А3®А1А2, А1А2®А2А3 и т.п..

В отношении отсутствует функциональная зависимость атрибута А1 от атрибута А2 и от атрибута А3, т.е.

А2 Ø® А1, А3 Ø® А1.

Отсутствие зависимости А1 от А2 объясняется тем, что одному и тому же значению атрибута А2 (21) соответствуют разные значения атрибута А1 (12 и 17).

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

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

ФИО ® Оклад

ФИО ® Долж

ФИО ® Стаж

ФИО ® Надб

ФИО ® Каф

Стаж ® Надб

Долж ® Оклад

Оклад ® Долж

ФИО. Предм. Группа ® Оклад

Рис. 6.5. Зависимости между атрибутами.

Предполагается, что один преподаватель в одной группе может проводить один вид занятий (лекции или лабораторные работы). ФИО – уникальны. Имеется зависимость ФИО ® Стаж, а обратное утверждение не верно, т.к. одинаковый стаж имеют несколько преподавателей. Относительно других зависимостей рассуждения аналогичны. Между должностью и окладом устанавливается взаимно однозначная зависимость.

Один преподаватель в одной группе по разным предметам может проводить разные виды занятий. Определение ВидаЗанятий связано с указанием ФИО, Предмета и Группы. Действительно, Петров М.И. в 256-й группе читает лекции и проводит лабораторные занятия, но лекции читает по СУБД, а лабораторные работы по Графике.

Зависимости между атрибутами ФИО, Предмет и Группа не выведены, т.к. они образуют составной ключ и не учитываются в процессе нормализации отношения (таблицы).

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

Выделяют следующую последовательность нормальных форм:

° Первая нормальная форма (1НФ);

° Вторая нормальная форма (2НФ);

° Третья нормальная форма (3НФ);

° Усиленная третья нормальная форма, или нормальная форма Бойса-Кодда (БКНФ);

° Четвертая нормальная форма (4НФ);

° Пятая нормальная форма (5НФ).

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

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

Основной операцией метода декомпозиции является операция проекции.

Пример. Пусть в отношении R(A,B,C,D,E,…) имеется функциональная зависимость С ® D. Декомпозиция отношения R на два новых отношения R1(A, B,C,E,…) и R2(C,D) устранит функциональную зависимость атрибутов и переведет отношение R в следующую нормальную форму. Отношение R2 является проекцией отношения R на атрибуты C и D.

Исходное отношение Преподаватель имеет составной ключ ФИО, Предм, Группа и находится в 1НФ. Атрибуты Стаж, Надб, Каф, Долж, Оклад находятся в функциональной зависимости от части составного ключа – атрибута ФИО . Эта частичная зависимость приводит к явной и неявной избыточности данных, что создает проблемы их редактирования. Часть избыточности устраняется при переводе отношения во 2НФ.

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

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

° Построить проекцию без атрибутов, находящихся в частичной зависимости от первичного ключа;

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

Переведем отношение Преподаватель во 2НФ. В результате получим два отношения R1 и R2.

R1

ФИО	Предм	Группа	ВидЗан
Иванов И.М.	СУБД		Лабор
Иванов И.М.	Информ		Лабор
Петров М.И.	СУБД		Лекция
Петров М.И.	Графика		Лабор
Сидоров Н.Г.	Информ		Лекция
Сидоров Н.Г.	Графика		Лекция
Егоров В.В.	ПЭВМ		Лекция

Рис. 6.6. Отношения базы данных ПРЕПОДАВАТЕЛЬ во 2 НФ

В отношении R1 первичный ключ составной ФИО, Предм, Группа , в отношении R2 ключ – ФИО. В результате исключена явная избыточность данных о преподавателях. В R2 по-прежнему имеет место неявное дублирование данных.

Для дальнейшего совершенствования переведем отношения в 3НФ.