metBD (1084482), страница 13

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

Текст из файла (страница 13)

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

Описание концептуальной схемы БД в терминах выбранной СУБД.

Описание внешних моделей в терминах выбранной СУБД.

Описание декларативных правил поддержки целостности базы данных.

Разработка процедур поддержки семантической целостности базы данных.

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

Мы должны построить корректную схему БД, ориентируясь на реляционную модель данных.

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

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

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

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

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

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

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

• первая нормальная форма (1NF);

• вторая нормальная форма (2NF);

• третья нормальная форма (3NF);

• нормальная форма Бойса-Кодда (BCNF);

• четвертая нормальная форма (4NF);

• пятая нормальная форма, или форма проекции-соединения (5NF или PJNF)

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

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

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

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

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

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

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

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

Функциональной зависимостью набора атрибутов В отношения R от набора ат­рибутов А того же отношения, обозначаемой как

R. A -> R. B или А -> В

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

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

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

 А1  A  R.A -/-> R. B,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Транзитивность: если А->В В->C , то А->С.

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

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

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

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

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

Таблица 32

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

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

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

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

Таблица 33

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

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

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

(ФИО. Номер. зач.кн.. Группа)

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

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

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

Характеристики

Список файлов книги