Текст книги "Базы данных: конспект лекций"
Автор книги: авторов Коллектив
Жанр:
Базы данных
сообщить о нарушении
Текущая страница: 8 (всего у книги 12 страниц)
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. Приведем формулярную запись этого правила:
X →Y, Y → Z ├X → Z.
Необходимо отметить, что посылки и заключения, приведенные ранее, были представлены в сокращенной форме обозначениями схем функциональной зависимости. В расширенной форме им соответствуют следующие ограничения функциональных зависимостей.
Правило вывода 1. inv
Правило вывода 2. inv
Правило вывода 3. inv
Проведем доказательства этих правил вывода.
1. Доказательство правила рефлексивности следует непосредственно из определения ограничения функциональной зависимости при подстановке вместо подсхемы Y – подсхемы X.
Действительно, возьмем ограничение функциональной зависимости:
Inv
Inv
Правило рефлексивности доказано.
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) имеем далее: X ∪ Z → 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
r(S)].
Итак, это множество ограничений, накладываемое функциональными зависимостями, расшифровывается следующим образом: для любого правила из системы функциональных зависимостей X → Y, принадлежащего множеству функциональных зависимостей F(S), действует ограничение функциональных зависимостей inv
Пусть какое-то отношение r(S) удовлетворяет этому ограничению.
Применяя правила вывода Армстронга к функциональным зависимостям, определенным для множества F(S), можно получить новые функциональные зависимости, как уже было сказано и доказано нами ранее. И, что показательно, ограничениям этих функциональных зависимостей отношение F(S) будет автоматически удовлетворять, что видно из расширенной формы записи правил вывода Армстронга. Напомним общий вид этих расширенных правил вывода:
Правило вывода 1.inv < X → X > r(S);
Правило вывода 2.inv
Правило вывода 3.inv
Возвращаясь к нашим рассуждениям, пополним множество 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
r(S)];
Итак, теорема полноты системы правил вывода Армстронга утверждает, что внешняя импликация может совершенно законно и обоснованно быть заменена эквивалентностью.
(Доказательство этой теоремы мы рассматривать не будем, так как сам процесс доказательства не столь важен в нашем конкретном курсе лекций.)
Лекция № 10. Нормальные формы
1. Смысл нормализации схем баз данных
Понятие, которое мы будем рассматривать в данном разделе, связано с понятием функциональных зависимостей, т. е. смысл нормализации схем баз данных неразрывно связан с понятием ограничений, накладываемых системой функциональных зависимостей, и во многом следует из этого понятия.
Исходной точкой любого проектирования базы данных является представление предметной области в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих «улучшенными» свойствами. Таким образом, процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами, в некотором смысле лучшими, чем предыдущая.
Каждой нормальной форме соответствует определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений. Примером может служить ограничение первой нормальной формы – значения всех атрибутов отношения атомарны.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
1) первая нормальная форма (1 NF);
2) вторая нормальная форма (2 NF);
3) третья нормальная форма (3 NF);
4) нормальная форма Бойса – Кодда (BCNF);
5) четвертая нормальная форма (4 NF);
6) пятая нормальная форма, или нормальная форма проекции-соединения (5 NF или PJ/NF).
(В данный курс лекций включается подробное рассмотрение первых четырех нормальных форм базовых отношений, поэтому мы не будем подробно разбирать четвертую и пятую нормальные формы.)
Основные свойства нормальных форм состоят в следующем:
1) каждая следующая нормальная форма в некотором смысле лучше предыдущей нормальной формы;
2) при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.
В основе процесса проектирования лежит метод нормализации, т. е. декомпозиции отношения, находящегося в предыдущей нормальной форме, на два или более отношений, которые удовлетворяют требованиям следующей нормальной формы (с этим мы столкнемся, когда нам самим придется по мере прохождения материала проводить нормализацию того или иного базового отношения).
Как уже упоминалось в разделе, посвященном созданию базовых отношений, заданные множества функциональных зависимостей, накладывают соответствующие ограничения на схемы базовых отношений. Эти ограничения в общем случае реализуются двумя методами:
1) декларативно, т. е. с помощью объявления в базовом отношении различного вида первичных, кандидатных и внешних ключей (это метод, получивший наибольшее распространение);
2) процедурно, т. е. написанием программного кода (использованием упомянутых выше так называемых триггеров).
При помощи простой логики можно понять, в чем же заключается смысл нормализации схем баз данных. Нормализовывать базы данных или приводить базы данных к нормальному виду – это значит определять такие схемы базовых отношений, чтобы максимально уменьшить необходимость написания программного кода, увеличить производительность работы базы данных, облегчить поддержку целостности данных по состоянию и ссылочной целостности. То есть сделать код и работу с ним максимально простой и удобной разработчикам и пользователям.
Для того чтобы наглядно в сравнении продемонстрировать работу ненормализованной и нормализованной базы данных, рассмотрим следующий пример.
Пусть у нас имеется базовое отношение, содержащее информацию о результатах экзаменационной сессии. Такую базу данных мы уже рассматривали раньше.
Итак, вариант 1 схемы базы данных.
Сессия (№ зачетной книжки, Фамилия, Имя, Отчество, Предмет, Оценка)
В этом отношении, как видно из изображения схемы базового отношения, задан составной первичный ключ:
Primary key (№ зачетной книжки, Предмет);
Также в этом отношении задана система функциональных зависимостей:
{№ зачетной книжки} → {Фамилия, Имя, Отчество};
Приведем табличный вид небольшого фрагмента базы данных с данной схемой отношения. Этот фрагмент мы уже применяли в рассмотрении ограничений функциональных зависимостей, поэтому на его примере нам будет довольно легко понять и данную тему.
Здесь для поддержания целостности данных по состоянию, т. е. для выполнения ограничения системы функциональной зависимости {№ зачетной книжки} → {Фамилия, Имя, Отчество} при изменении, например, фамилии необходимо просматривать все кортежи этого базового отношения и последовательно вводить необходимые изменения. Однако так как это довольно громоздкий и трудоемкий процесс (особенно если мы имеем дело с базой данных большого учебного заведения), разработчики систем управления базами данных пришли к выводу, что этот процесс необходимо автоматизировать, т. е. сделать автоматическим. Теперь контроль выполнения этой (и любой другой) функциональной зависимости можно организовывать автоматически при помощи правильного объявления в базовом отношении различных ключей и так называемой декомпозиции (т. е. разбиения чего-либо на несколько самостоятельных частей) этого отношения.
Итак, нашу имеющуюся схему отношения «Сессия» разобьем на две схемы: схему «Студенты», содержащую только информацию о студентах данного учебного заведения, и схему «Сессия», содержащую информацию о последней прошедшей сессии. А затем объявим ключи таким образом, чтобы можно было без труда получить любую необходимую информацию.
Покажем, как будут выглядеть эти новые схемы отношений со своими ключами.
Вариант 2 схемы базы данных.
Студенты (№ зачетной книжки, Фамилия, Имя, Отчество),
Primary key (№ зачетной книжки).
Сессия (№ зачетной книжки, Предмет, Оценка),
Primary key (№ зачетной книжки, Предмет),
Foreign key (№ зачетной книжки) references Студенты (№ номер зачетной книжки).
Что мы имеем теперь? В отношении «Студенты» первичный ключ «№ зачетной книжки» функционально определяет остальные три атрибута: «Фамилия», «Имя» и «Отчество». А в отношении «Сессия» составной первичный ключ «№ зачетной книжки, Предмет» также однозначно, т. е. буквально функционально определяет последний атрибут этой схемы отношения – «Оценка». И связь между этими двумя отношениями налажена: она осуществляется посредством внешнего ключа отношения «Сессия» «№ зачетной книжки», который ссылается на одноименный атрибут отношения «Студенты» и при соответствующем запросе представляет всю необходимую информацию.
Покажем теперь, как будут выглядеть отношения, представленные таблицами, отвечающие второму варианту задания соответствующих схем баз данных.
Таким образом, мы видим, что целью нормализации в аспекте ограничений, накладываемых функциональными зависимостями, является необходимость навязать любой базе данных требуемые функциональные зависимости при помощи объявлений различного вида первичных, кандидатных и внешних ключей базовых отношений.
2. Первая нормальная форма (1NF)
На ранних стадиях проектирования баз данных и разработки схем их управления использовались простые и однозначные атрибуты как наиболее продуктивные и рациональные единицы кода. Тогда применяли наряду с простыми и составные атрибуты, а также наряду с однозначными и многозначные атрибуты. Поясним значения каждого из этих понятий.
Составные атрибуты, в отличие от простых, – это атрибуты, составленные из нескольких простых атрибутов.
Многозначные атрибуты, в отличие от однозначных, – это атрибуты, представляющие множество значений.
Приведем примеры простых, составных, однозначных и многозначных атрибутов.
Рассмотрим следующую таблицу, представляющую отношение:
Здесь атрибут «Телефон» – простой, однозначный, а атрибут «Адрес» – простой, но многозначный.
Теперь рассмотрим другую таблицу, с другими атрибутами:
В этом отношении, представленном таблицей, атрибут «Телефоны» – простой, но многозначный, а атрибут «Адреса» – и составной, и многозначный.
Вообще возможны различные комбинации простых или составных атрибутов. В разных случаях таблицы, представляющие отношения, могут выглядеть следующим общим образом:
При нормализации схем базовых отношений программистами может быть использована одна из четырех наиболее распространенных видов нормальных форм: первая нормальная форма (1NF), вторая нормальная форма (2NF), третья нормальная форма (3NF) или нормальная форма Бойса – Кодда (NFBC). Поясним: сокращение NF – это аббревиатура от англоязычного словосочетания Normal Form. Формально, кроме вышеназванных, существуют и другие виды нормальных форм, но вышеназванные – одни из самых востребованных.
В настоящее время разработчики баз данных стараются избегать составных и многозначных атрибутов, чтобы не усложнять написание кода, не перегружать его структуру и не запутывать пользователей. Из этих соображений логически и вытекает определение первой нормальной формы.
Определение. Любое базовое отношение находится в первой нормальной форме тогда и только тогда, когда схема этого отношения содержит только простые и только однозначные атрибуты, причем обязательно с одной и той же семантикой.
Для наглядного объяснения различий нормализованных и ненормализованных отношений рассмотрим пример.
Пусть, имеется ненормализованное отношение, со следующей схемой.
Итак, вариант 1 схемы отношения с заданным на ней простым первичным ключом:
Сотрудники (№ табельный, Фамилия Имя Отчество, Код должности, Телефоны, Дата приема или увольнения);
Primary key (№ табельный);
Перечислим, какие в этой схеме отношения имеются ошибки, т. е. назовем те признаки, которые и делают собственно эту схему ненормализованной:
1) атрибут «Фамилия Имя Отчество» является составным, т. е. составленным из разнородных элементов;
2) атрибут «Телефоны» является многозначным, т. е. его значением является множество значений;
3) атрибут «Дата приема или увольнения» не имеет однозначной семантики, т. е. в последнем случае не понятно, какая именно дата внесена.
Если, например, ввести дополнительный атрибут, чтобы поточнее определить смысл даты, то для этого атрибута значение будет семантически понятно, но тем не менее остается возможность хранения только какой-то одной из указанных дат для каждого сотрудника.
Что же необходимо сделать для приведения этого отношения к нормальной форме?
Во-первых, необходимо провести разбиение составных атрибутов на простые, для того, чтобы исключить эти самые составные атрибуты, а также атрибуты с составной семантикой.
А во-вторых, необходимо провести декомпозицию этого отношения, т. е. нужно разбить его на несколько новых самостоятельных отношений, с тем чтобы исключить многозначные атрибуты.
Таким образом, с учетом всего вышесказанного после приведения отношения «Сотрудники» к первой нормальной форме или 1NF путем его декомпозиции мы получим систему следующих отношений с заданными на них первичными и внешними ключами.
Итак, вариант 2 отношения:
Сотрудники (№ табельный, Фамилия, Имя, Отчество, Код должности, Дата приема, Дата увольнения);
Primary key (№ табельный);
Телефоны (№ табельный, Телефон);
Primary key (№ табельный, Телефон);
Foreign key (№ табельный) references Сотрудники (№ табельный);
Итак, что мы видим? Составного атрибута «Фамилия Имя Отчество» больше в нашем отношении нет, вместо него присутствуют три простых атрибута «Фамилия», «Имя» и «Отчество», поэтому эта причина «ненормальности» отношения исключилась.
Кроме того, вместо атрибута с неясной семантикой «Дата приема или увольнения» у нас появилось два атрибута «Дата приема» и «Дата увольнения», каждый из которых имеет однозначную семантику. Следовательно, вторая причина того, что наше отношение «Сотрудники» не находится в нормальной форме, также благополучно устранена.
И, наконец, последняя причина того, что отношение «Сотрудники» не было приведено к нормальной форме, – это наличие многозначного атрибута «Телефоны». Чтобы избавиться от этого атрибута, и необходимо было провести декомпозицию всего отношения. Из исходного отношения «Сотрудники» в результате этой декомпозиции был исключен атрибут «Телефоны» вообще, но зато образовалось второе отношение – «Телефоны», в котором присутствуют два атрибута: «№ табельный» сотрудника и «Телефон», т. е. все атрибуты – опять-таки простые, условие принадлежности к первой нормальной форме выполняется. Эти атрибуты «№ табельный» и «Телефон» образуют составной первичный ключ отношения «Телефоны», а атрибут «№ табельный», в свою очередь, является внешним ключом, ссылающимся на одноименный атрибут отношения «Сотрудники», т. е. в отношении «Телефоны» атрибут первичного ключа «№ табельный» является одновременно внешним ключом, ссылающимся на первичный ключ отношения «Сотрудники». Таким образом, обеспечивается связь между этими двумя отношениями. Посредством этой связи можно по номеру табельному любого сотрудника без особого труда и затрат времени вывести весь список его телефонов, не прибегая к использованию составных атрибутов.
Заметим, что в случае наличия в отношении системы ограничений функциональных зависимостей после всех вышеприведенных преобразований нормализация не была бы завершена. Однако в данном конкретном примере нет ограничений функциональных зависимостей, поэтому дальнейшая нормализация этого отношения не требуется.