<< Вернуться у выбору материала

Тема № 7 Проектирование реляционных БД на основе принципов нормализации

Введите ваш запрос для начала поиска.

Грпш-13-2ну1 gazpromgaz.ru.

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

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

Этапы проектирования БД

Рис. 6.2 Этапы проектирования БД

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ЕR-модели.

3. Дата логическое или логическое проектирование БД, то есть описание БД в терминах принятой дата логической модели данных.

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

Между вторым и третьим этапами необходимо принять решение, с использованием какой стандартной СУБД будет реализовываться наш проект..

4.1 Системный анализ предметной области

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

В общем случае существуют два подхода к выбору состава и структуры предметной области:

1. Функциональный подход — он реализует принцип движения «от задач» и применяется тогда, когда заранее известны функции некоторой группы лиц и комплексов задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. В этом случае мы можем четко выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.

2. Предметный подход — когда информационные потребности будущих пользователей БД жестко не фиксируются. Они могут быть многоаспектными и весьма динамичными. Мы не можем точно выделить минимальный набор объектов предметной области, которые необходимо описывать. В описание предметной области в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и наиболее существенны для нее. БД, конструируемая при этом, называется предметной, то есть она может быть использована при решении множества разнообразных, заранее не определенных задач. Конструирование предметной БД в кажется более заманчивым, однако трудность всеобщего охвата предметной области с невозможностью конкретизации потребностей пользователей может привести к избыточно сложной схеме БД, которая для конкретных задач будет неэффективной.

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

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

Пример описания предметной области.

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

1) уникальный шифр;

2) название;

3) фамилии авторов (могут отсутствовать);

4) место издания (город);

5) издательство;

6) год издания;

7) количество страниц;

8) стоимость книги;

9) количество экземпляров книги в библиотеке.

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

В библиотеке ведется картотека читателей. На каждого читателя в картотеку заносятся следующие сведения:

1) фамилия, имя, отчество;

2) домашний адрес;

3) телефон (будем считать, что у нас два телефона — рабочий и домашний);

4) дата рождения.

5) каждому читателю присваивается уникальный номер читательского билета.

6) каждый читатель может одновременно держать на руках не более 5 книг.

7) читатель не должен одновременно держать более одного экземпляра книги одного названия.

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

1) уникальный инвентарный номер;

2) шифр книги, который совпадает с уникальным шифром из описания книг;

3) место размещения в библиотеке.

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

1) номер билета читателя, который взял книгу;

2) дата выдачи книги;

3) дата возврата.

Предусмотреть следующие ограничения на информацию в системе:

Книга может не иметь ни одного автора.

В библиотеке должны быть записаны читатели не моложе 17 лет.

В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.

Каждый читатель может держать на руках не более 5 книг.

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

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

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

1) библиотекари;

2) читатели;

3) администрация библиотеки.

При работе с системой библиотекарь должен иметь возможность решать следующие задачи:

1. Принимать новые книги и регистрировать их в библиотеке.

2. Относить книги к одной или к нескольким областям знаний.

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

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

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

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

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

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

Читатель должен иметь возможность решать следующие задачи:

1. Просматривать системный каталог, то есть перечень всех областей знаний, книги по которым есть в библиотеке.

2. По выбранной области знаний получить полный перечень книг, которые числятся в библиотеке.

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

4. Для выбранного автора получить список книг, которые числятся в библиотеке.

Администрация библиотеки должна иметь возможность получать:

сведения о должниках - читателях библиотеки, которые не вернули вовремя взятые книги;

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

сведения о стоимости конкретного экземпляра, для того чтобы установить возможность возмещения стоимости утерянной книги или возможность замены ее другой книгой;

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

Этот совсем небольшой пример показывает, что перед началом разработки необходимо иметь точное представление о том, что же должно выполняться в информационной системе, какие пользователи в ней будут работать, какие задачи будет решать каждый пользователь. И это правильно, ведь когда мы строим здание, мы заранее предполагаем: для каких целей оно предназначено, в каком климате оно будет стоять, на какой почве, и в зависимости от этого проектировщики предлагает нам тот или иной проект. Но, к сожалению, очень часто по отношению к базам данных считается, что все можно определить потом, когда часть системы уже создана. Отсутствие четких целей создания БД может свести на нет все усилия разработчиков, и проект БД получится «плохим», не соответствующим ни реально моделируемому объекту, ни задачам, котрые должны решаться с использованием данной БД.

4.2 Дата логическое проектирование

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

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

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

Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

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

Проектирование схемы БД может быть выполнено двумя путями:

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

2 Путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

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

Основные свойства нормальных форм:

1.1 каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;

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

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

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

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

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

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

Приведем ряд основных определений.

Функциональной зависимостью набора атрибутов В отношения R от набора атрибутов А того же отношения, обозначаемой как R.A -> R.B или А -> В называется такое соотношение проекций R[A] и R[B], при котором в каждый момент времени любому элементу проекции R[A] соответствует только один элемент проекции R[B], входящий вместе с ним в какой-либо кортеж отношения R.

Функциональная зависимость R.A -> R.B называется полной, если набор атрибутов В функционально зависит от А и не зависит функционально от любого подмножества А, то есть

R.A -> R.B называется полной, если:

" А1 сАÎ R. A -/-> R.B, что читается следующим образом:

для любого А1, являющегося подмножеством А, R.B функционально не зависит от R.A, в противном случае зависимость R.A -> R.B называется неполной.

Функциональная зависимость R.A -> R.B называется транзитивной, если существует набор атрибутов С такой, что:

1. С не является подмножеством А.

2. С не включает в себя В.

3. Существует функциональная зависимость R.A -> R.C.

4. Не существует функциональной зависимости R.C -> R.A.

5. Существует функциональная зависимость R.C -> R.B.

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

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

Отношение - это подмножество декартова произведения множества доменов.

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

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

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

Взаимно-независимые атрибуты — это такие атрибуты, которые не зависят функционально один от другого.

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

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

1. Рефлексивность: если В является подмножеством А, то А->В

2. Дополнение: если А->В , то АС->ВС

3. Транзитивность: спи Л В и В->Г то А->С.

4.3 Формы нормальных отношений

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

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

Преподатель День недели Номер пары Название дисциплины Тип занятий Группа
Ветров В. И. Понед. 1 Тсор. выч.проц. Лекция 4906
Вторник 1 Комп. графика Лаб. раб. 4907
Вторник 2 Коми. графика Лаб. раб. 4906
Киров В. А. Понсд. 2 Тсор. информ. Лекция 4906
Вторник 3 Пр-е на C++ Лаб. раб. 4907
Вторник 4 Пр-е на C++ Лаб. раб. 4906
Серов А. А. Понед. 3 Зашита ипф. Лекция 4944
Среда 3 Пр-е на VB Лаб. раб. 4942
Четверг 4 Пр-с на VB Лаб. раб. 4922

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

Для приведения отношения «Расписание» к первой нормальной форме необходимо дополнить каждую строку фамилией преподавателя.

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

Преподатель День недели Номер пары Название дисциплины Тип занятий Группа
Петров В.И Понсд. 1 Тсор. ныч. upon. Лекция 4906
Петров В.И Вторник 1 Коми. графика Лаб. раб. 4907
Петров В.И Вторник 2 Комн. графика Лаб. раб. 4906
Киров В. А. Понед. 2 Теор. информ. Лекция 4906
Киров В. А. Вторник 3 Пр-е на C++ Лаб. раб. 4907
Киров В. А. Вторник 4 Пр-е на C++ Лаб. раб. 4906
Серов А. А. Понед. 3 Защита ии4). Лекция 4944
Серов А. А. Среда 3 Пр-е на VB Лаб. раб. 4942
Серов А. А. Четверг 4 Пр-е на VB Лаб. раб. 4922

Рассмотрим отношение, моделирующее сдачу студентами текущей сессии. Структура этого отношения определяется следующим набором атрибутов:

(ФИО. Номер зач.кн.. Группа, Дисциплина. Оценка)

Так как каждый студент сдает целый набор дисциплин в процессе сессии, то первичным ключом отношения может быть (Номер, зач.кн. Дисциплина), который однозначно определяет каждую стоку отношения. С другой стороны, атрибуты ФИО и Группа зависят только от части первичного ключа - от значения атрибута Номер зач. кн., поэтому мы должны констатировать наличие неполных функциональных зависимостей в данном отношении. Для приведения данного отношения ко второй нормальной форме следует разбить его на проекции, при этом должно быть соблюдено условие восстановления исходного отношения без потерь. Такими проекциями могут быть два отношения:

(ФИО, Номер.зач.кн.. Группа) (Номер зач.кн.. Дисциплина. Оценка)

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

А почему надо приводить отношения ко второй нормальной форме? Иначе говоря, какие аномалии или неудобства могут возникнуть, если мы оставим исходное отношение и не будем его разбивать на два? Давайте рассмотрим ситуацию, когда студент переведен из одной группы в другую. Тогда в первом случае (если мы не разбивали исходное отношение на два) мы должны найти все записи с данным студентом и в них изменить значение атрибута Группа на новое. Во втором же случае меняется только один кортеж в первом отношении. И конечно, опасность нарушения корректности (непротиворечивости содержания) БД в первом случае выше. Может получиться так, что часть кортежей поменяет |значения атрибута Группа, а часть по причине сбоя в работе аппаратуры останется в старом состоянии. И тогда наша БД будет содержать записи, которые относят одного студента одновременно к разным группам. Чтобы этого не произошло, мы должны принимать дополнительные непростые меры, например организовывать процесс согласованного изменения с использованием сложного механизма транзакций, который рассматрим в теме, посвященных вопросам распределенного доступа к БД. Если же мы перешли ко второй нормальной форме, то мы меняем только один кортеж. Кроме того, если у нас есть студенты, которые еще не сдавали экзамены, то в исходном отношении мы вообще не можем хранить о них информацию, а во второй схеме информация о студентах и их принадлежности к конкретной группе хранится отдельно от информации, которая связана со сдачей экзаменов, и поэтому мы можем в этом случае отдельно работать со студентами и отдельно хранить и обрабатывать информацию об успеваемости и сдаче экзаменов, что в действительности и происходит.

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

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

(ФИО, Номер зач.кн.. Группа. Факультет. Специальность. Выпускающая кафедра)

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

Номер зач.кн. -> ФИО Номер зач.кн. -> Группа Номер зач.кн. -> Факультет Номер зач.кн. -> Специальность Номер зач.кн. -> Выпускающая кафедра

Группа -> Факультет

Группа -> Специальность

Группа -> Выпускающая кафедра

Выпускающая кафедра -> Факультет

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

(Номер.зач.кн., ФИО. Специальность, Группа) (Группа. Выпускающая кафедра) (Выпускащая кафедра, Факультет)

Первичные ключи отношений выделены.

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

Полученный набор отношений находится в третьей нормальной форме.

Отношение находится в нормальной форме Бойса—Кодда, если оно находится в третьей нормальной форме, и каждый детерминант отношения является возможным ключом отношения.

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

(Номер зач.кн.. Идентификатор_студента. Дисциплина, Дата. Оценка)

Возможными ключами отношения являются Номер_зач. кн, Дисциплина, Дата и Идентификатор студента, Дисциплина, Дата.

Какие функциональные зависимости у нас имеются?

Номер_зач.кн, Дисциплина. Дата -> Оценка;

Идентификатор_студента. Дисциплина. Дата -> Оценка;

Номер зач.кн. -> Идентификатор_студента:

Иден.тификатор_студента -> Номер зач.кн.

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

Это отношение находится в третьей нормальной форме, потому что нет неполных функциональных зависимостей не первичных атрибутов от атрибут возможного ключа здесь не присутствует и нет транзитивных зависимостей А как же третья и четвертая зависимости, разве они не являются неполными? Нет, потому что зависимым не является не первичный атрибут, то ее атрибут, не входящий ни в один возможный ключ. Поэтому придраться к этому мы не можем. Но под четвертую нормальную форму наше отношение не подходит, потому что у нас есть два детерминанта Номер зач.кн. Идентификатор студента, которые не являются возможными ключами отношений. Для приведения отношения к нормальной форме Бойса—Кодда необходимо разбить отношение, например, на два со следующими схемами:

(Идентификатор_студента, Дисциплина. Дата, Оценка) (Номер зач.кн.. Идентификатор_студента)

или наоборот:

(Номер зач.кн.. Дисциплина, Дата. Оценка) (Номер зач.кн., Идентификатор_студента)

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

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

В отношении R (А, В, С) существует многозначная зависимость (multi valid dependence, MVD) R.A -> R.B в том и только в том случае, если множество значений В, соответствующее паре значений А и С, зависит только от А и не зависит от С.

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

(Номер зач.кн.. Группа. Дисциплина)

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

В данном отношении существуют следующие две многозначные зависимости

Группа -» Дисциплина Группа -» Номер зач.кн.

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

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

Эти аномалии модификации отношения как раз и связаны с наличием двухзначных зависимостей.

В теории реляционных баз данных доказывается, что в общем случае n отношений R (А, В, С) существует многозначная зависимость R.A -> R.B в том и только в том случае, когда существует многозначная зависимость R.A -> R.C.

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

Отношение R (А, В, С) можно спроецировать без потерь в отношения R1 (А, В) и R2 (А, С) в том и только и том случае, когда существует MVD А -> В ½ С ( что равнозначно наличию двух зависимостей А -> В и А ->С).

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

Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости А -> В все остальные атрибуты R функционально зависят от А.

В нашем примере можно произвести декомпозицию исходного отношения в два отношения:

(Номер зач.кн.. Группа) (Группа. Дисциплина)

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

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

Отношение R (X, У, ..., Z) удовлетворяет зависимости соединения (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, .... Z. Здесь X, Y, ..., Z — наборы атрибутов отношения R.

Наличие PJ-зависимости в отношении делает его в некотором роде избыточным и затрудняет операции модификации.

Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения — PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.

Рассмотрим отношение Rl: Преподаватель. Кафедра. Дисциплина)

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

Введем следующие обозначения наборов атрибутов:

ПК (Преподаватель. Кафедра) ПД (Преподаватель. Дисциплина) КД (Кафедра. Дисциплина)

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

R2 (Преподаватель, Кафедра) R3 (Преподаватель. Дисциплина) R4 (Кафедра. Дисциплина-\

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

Рейтинг@Mail.ru