Рассмотрим пример отношения, содержащего данные о студенте университета Иванове (таблица 7.1).

Таблица 7.1. Данные о студенте
Номер	Фамилия	Курсовые проекты	Предметы	Оценка	Комната	тел.
1000	Иванов		Математика		417	51-11
		Компиляторы	Системное программирование	5/4
			Физика
		Окисление серы	Химия	5/5

Пример. Универсальное отношение.

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

Таблица 7.2. Отношение СТУДЕНТ
Номер	Фамилия	Курсовые проекты	Предметы	Оценка	Комната	Тел.
1000	Иванов	Нет	Математика		417	51-11
1000	Иванов	Компиляторы	Системное программирование	5/4	417	51-11
1000	Иванов	Нет	Физика		417	51-11
1000	Иванов	Окисление серы	Химия	5/5	417	51-11

Если в отношение включены все атрибуты из предметной области базы данных, то его называют универсальным отношением . Универсальное отношение находится в 1НФ. Как известно, отношением в 1НФ порождается множество аномалий в обработке данных (обновление, удаление, добавление, избыточность). Для того чтобы поместить универсальное отношение в базу данных, его необходимо нормализовать - разбить на совокупность более мелких отношений. При этом возникают следующие три вопроса:

1. распознать отношения, подлежащие разбиению?

2. Как осуществлять разбиение?

3. Когда окончить процесс разбиения?

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

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

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

Декомпозиция схем отношений, свойства соединения без потерь и сохранения ФЗ

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

Введем определение декомпозиции схемы отношения .

Определение 1. Декомпозицией схемы отношений называется замена ее совокупностью подмножества R .

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

Рассмотрим алгоритм проверки свойства соединения без потерь.

Алгоритм. Проверка декомпозиции на свойство соединения без потерь

input: схема отношения R(A 1 , A 2 , ..., A k), множество ФЗ F,

декомпозиция d={R 1 , R 2 , ..., R k }.

output: Булева переменная истина или ложь.

Алгоритм

1. Построим таблицу с n столбцами и k строками, где столбец j соответствует атрибуту А j , а строка i - схеме отношения R i . На пересечении строки i и столбца j поместим символ aj , если атрибут A j принадлежит R i . В противном случае поместим символ b ij .

2. Многократно просматриваем каждую ФЗ из F , до тех пор, пока внесение изменений в таблицу станет невозможным. Просматривая зависимость, ищем строки, которые совпадают по всем столбцам, соответствующим атрибутам из Х . При обнаружении таких строк отождествляем их символы в столбцах, соответствующих атрибутам из Y , по правилу a j в a j , b ij в b ij .

3. Если после модификации строк таблицы оказывается, что некоторая строка равна a 1 , a 2 , ..., a k , то декомпозиция d обладает свойством соединения без потерь. В противном случае декомпозиция d таким свойством не обладает.

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

Рассмотрим пример применения алгоритма, используя отношение ПОСТАВКИ (Поставщик, Адрес, Товар, Стоимость). Обозначим его атрибуты как: А - поставщик, В - адрес, C - товар, D - стоимость, при этом имеют место ФЗ.

При декомпозиции одной схемы отношения на две другие схемы отношений используется более простая проверка: декомпозиция обладает свойством соединения без потерь, если только. Такая ФЗ должна принадлежать F + .

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

Введем следующее определение.

Определение 2. Проекцией множества ФЗ F на множество атрибутов Х , обозначаемой, называется множество ФЗ в F+ , таких, что.

Говорят, что декомпозиция обладает свойством сохранения ФЗ, если из объединения всех ФЗ, принадлежащих, логически следуют все зависимости из F .

Рассмотрим отношение (Город, Адрес, Почтовый_индекс). Обозначим его атрибуты как: А - город, В - адрес, C - почтовый индекс, при этом имеют место ФЗ. Декомпозиция схемы этого отношения ABC на AC и BC обладает свойством соединения без потерь, поскольку верна ФЗ. Однако проекция на BC дает только тривиальные зависимости, проекция на АС дает ФЗ и тривиальные ФЗ. Из ФЗ не следует зависимость. Поэтому данная декомпозиция не сохраняет ФЗ, хотя и обладает свойством соединения без потерь.

Рассмотрим пример нарушения ФЗ при декомпозиции.

Пример. Нарушение ФЗ при декомпозиции

R 1 (B, C) R 2 (A, C)

Лесная, 6 132432 Черноголовка, МО 132432

Лесная, 6 132431 Черноголовка, МО 132431

R(A, B, C)

Черноголовка, МО 132432 Лесная, 6

Черноголовка, МО 132431 Лесная, 6

R = R 1 >< R 2 , для R 2 справедлива С \to А, для R не справедлива АВ \ to С.

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

· исключать избыточное дублирование;

· исключать потенциальную противоречивость данных;

· обладать свойством соединения без потерь;

· обладать свойством сохранения ФЗ.

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

Методы проектирования на основе декомпозиции отношений

Понятие о методах декомпозиции отношений

Предположим, что схема базы данных содержит F-зависимости. Из положений теории о F-зависимостях следует, что если отношения базы данных находятся в нормальной форме Бойса-Кодда (НФБК), то проектирование логической модели базы данных можно считать завершенным в этом классе зависимостей. Как видно, теория дает полезный (!) критерий останова проектирования.

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

Определение 3. Пусть дана ФЗ: , и В функционально не зависит от любого подмножества А, тогда А называется детерминантом В.

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

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

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

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

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

Алгоритм метода декомпозиции отношений

Алгоритм

1. Разработка универсального отношения для базы данных.

2. Определение всех ФЗ между атрибутами отношения.

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

4. Повторение пунктов 2 и 3 для каждого нового отношения, полученного в результате декомпозиции.

Уточним некоторые аспекты метода декомпозиции.

Во-первых, как выполнить декомпозицию отношения на два отношения. Пусть отношение R(A, B, C, D, ...) содержит ФЗ и, следовательно, не находится в НФБК. Атрибут С является детерминантом , но не возможным ключом. Для выполнения декомпозиции отношения R создаются два отношения R 1 (A, B, C, ...) и R 2 (C, D) , в одно из которых выделяется ФЗ. Такая декомпозиция является декомпозицией без потерь при естественном соединении . Далее с тех же позиций рассматриваются отношения R 1 и R 2 .

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

Если, то в качестве ФЗ для осуществления проекции используется крайняя правая зависимость или "конец цепочки" .

Методы проектирования на основе синтеза отношений

Некоторые проблемы метода декомпозиции

Алгоритм метода декомпозиции отношений не является совершенным. Мир ФЗ очень разнообразен. Он представляет собой хороший рабочий инструмент и, учитывая типы ФЗ, может совершенствоваться. Обратим внимание на две проблемные ситуации, связанные с применением метода декомпозиции. Пусть имеется отношение R(A, B, C, D, ...) из примера выше.

Первая ситуация: в процессе декомпозиции потеряна ФЗ, и если отношения R 1 и R 2 будут использованы для создания базы данных, то нельзя гарантировать, что связи между этими атрибутами будут внесены в БД корректно. Отсюда вытекает второе эмпирическое правило выбора ФЗ для выполнения проекции: не следует использовать ФЗ в качестве ФЗ для осуществления проекции, если ее левая часть является детерминантом другой ФЗ. Эта проблема разрешается путем применения правила цепочки.

Вторая ситуация: один атрибут зависит от двух детерминантов - один возможный ключ {A, C} и два детерминанта А и С . Эта ситуация является более критичной. Отношение не находится в НФБК; в отношении отсутствуют цепочки ФЗ, и правило цепочек к нему неприменимо. Эта проблема не разрешается с помощью стандартного метода декомпозиции. Решением является разложение исходного отношения на два отношения, в основе которого лежит утверждение о том, что все ФЗ с одинаковыми детерминантами необходимо выделять в отдельные группы и каждой такой группе отводить свое собственное отношение. Полученные отношения следует проверять на соответствие НФБК. Такой подход к проектированию логической модели реляционной базы данных получил название метода синтеза. Метод синтеза может использоваться как самостоятельно, так и в сочетании с методом декомпозиции по проекции. Приведенные примеры позволяют понять ряд потенциальных недостатков декомпозиции как метода проектирования лог ических моделей реляционных баз данных.

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

Понятие о методах синтеза отношений

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

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

Избыточные ФЗ следует удалять по одной, каждый раз проводя анализ полученного набора ФЗ на избыточность.

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

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

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

Кроме того, задача приведения исходных отношений к НФБК может оказаться невыполнимой. Такой факт имел место в практике проектирования. Поскольку НФБК может не существовать на заданном наборе ФЗ, то логичным было бы отказаться от требования приведения отношений базы данных к этой форме. Эта ситуация подкрепляется и теоретически: при любом заданном множестве F-зависимостей над схемой r БД можно построить схему БД в 3НФ.

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

Алгоритм метода синтеза отношений

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

Мы уже рассматривали примеры декомпозиции с потерей ФЗ. Причиной потери ФЗ является некоторая ФЗ, которая не может быть исключена из множества F-зависимостей, связанных с получаемыми отношениями R 1 или R 2 . Таким образом, суть проблемы сводится к нарушению замкнутости реляционных операций над ФЗ на полученной схеме базы данных. Для того чтобы ее решить, необходимо пополнить минимальное покрытие ФЗ, или, как говорят, усилить минимальное покрытие.

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

Введем определение.

Определение 4. Реляционная база данных называется полной, если:

· все ФЗ усилены ключами;

· все отношения находятся в 3НФ;

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

Почти всегда в предметной области базы данных можно выделить набор отношений, обладающих свойством полноты. Доказана теорема [Мейер], что существует алгоритм, который выводит полную базу данных из множества заданных ФЗ.

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

Пример. Универсальный ключ и ложные соединения

Пусть отношение R имеет кортежи:

1 1 1 1

4 1 2 2

Случай 1. Отсутствие ложных соединений

Разбиение на отношения

R 1 =ABC и R 2 =BCD

1 1 1	1 1 1
4 1 2	1 2 2

не дает ложных соединений.

Случай 2. Наличие ложных соединений

Разбиение на отношения

R 1 = AB и R 2 = BCD

1 1	1 1 1
4 1	1 2 2

дает ложные соединения

ABCD

1 1 1 1	1 1 2 2
4 1 1 1	4 1 2 2

Поскольку, то решить проблему можно, введя универсальный ключ {A,C} . Тогда можно добавить в исходную схему отношение

AC

1 1

1 2

и выполнить соединение отношений AB, BCD и AC , которое восстановит исходное отношение ABCD .

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

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

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

Введем некоторые обозначения. Составной ФЗ называется ФЗ: , где Y может быть пусто. С каждой составной ФЗ можно связать набор ФЗ: . Пусть С - множество составных ФЗ, fd(C) - множество всех ФЗ, связанных с ФЗ из С.

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

Алгоритм поэтапного синтеза отношений

Вход: F - множество ФЗ предметной области базы данных

Выход: схема полной базы данных

Этап 1. Нахождение неизбыточного покрытия F 1 для F

Для каждой ФЗ из F проверяется, может ли данная ФЗ быть выведена из оставшихся ФЗ. Если да, то ФЗ удаляется. Этап завершается после перебора всех ФЗ из F . В результате выполнения этапа получается множество ФЗ F 1 .

Этап 2. Сокращение слева элементов F 1

Удаляются последовательно один за другим атрибуты из левых частей ФЗ F 1 ; проверяется, может ли полученная ФЗ быть выведена из исходных ФЗ F 1 F 1 F 2 .

Этап 3. Сокращение справа элементов F 2

Удаляются последовательно один за другим атрибуты ФЗ из правых частей ФЗ F 2 ; проверяется, может ли исходная ФЗ быть выведена из полученной ФЗ и имеющихся ФЗ F 2 . Если да, то исходная ФЗ заменяется на новую ФЗ. Этап завершается после перебора всех ФЗ F 2 . В результате получается множество ФЗ F 3 .

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

Этап 4. Разделение F 3 на классы эквивалентности по правым частям

Строится разбиение F 3 на группы: две ФЗ принадлежат одной и той же группе тогда и только тогда, когда их правые части эквивалентны. В результате получается множество классов эквивалентности ФЗ.

Этап 5. Удаление в классах эквивалентности избыточных ФЗ

Для всех пар ФЗ fd i и fd j из одной и той же группы проверяется, может ли ФЗ левой стороны fdj от правой стороны fd j быть выведена из этой группы ФЗ. Если да, то из fd j ФЗ удаляется и добавляется в правую часть этой ФЗ к правой fd i . Новая ФЗ будет находиться в той же группе, что и исходная ФЗ. В результате получается минимальное число ФЗ F 5 , покрывающих F 3 .

Этап 6. Получение классов эквивалентности по левым частям F 5 и составных ФЗ C 1

Для каждого множества ФЗ с эквивалентными левыми частями из F 5 создается составная ФЗ. Если какой-либо атрибут из Y есть в X i , то этот атрибут удаляется. В результате получается множество составных ФЗ С 1 .

Этап 7. Удаление избыточных зависимостей из С 1

Для каждой составной ФЗ из С 1 и для каждого атрибута X i из левой части С сдвигаются атрибуты в правую часть. В результате получается множество составных ФЗ С" . Если fd(C") эквивалентно fd(C 1) , то С 1 заменяется на С" . В результате получается множество ФЗ С 2 .

Этап 8. Формирование кольцевого минимального покрытия

Для каждой составной ФЗ c из С 2 и каждого атрибута A из правой части c удаляется атрибут А . В результате получается С" , состоящее из с" . Если fd(C") эквивалентно fd(C 2) , то С 2 заменяется на С" . В результате получается множество ФЗ С 3 .

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

Для каждой составной ФЗ с из С 3 формируется таблица атрибутов, которые появляются в с . Ключами для этой таблицы являются Х i из левой части с . Таблица послужит для усиления ФЗ в F .

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

Создание логической модели реляционной базы данных методом декомпозиции: преобразование ER -диаграмм в отношения базы данных

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

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

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

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

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

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

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

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

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

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

Сформулируем первое правило.

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

Исходное отношение является одновременно и конечным отношением.

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

Это правило может быть применено во втором варианте, когда исходное отношение уже требует декомпозиции. Исходное отношение ПРЕПОДАВАТЕЛЬ_1 содержит проблему нуль-значений: данные о предметах, которые не читаются в данный момент, не могут быть внесены в базу данных.

Результирующее отношение ПРЕПОДАВАТЕЛЬ_2 не имеет проблемы нуль-значений. В результирующем отношении ПРЕДМЕТЫ эта проблема исключается: для предмета, который в данный момент не читается, определяется специальное непустое значение по умолчанию. Миграция ключа необходима для восстановления исходного отношения. Таким образом, миграция ключа в методе декомпозиции представляет собой перенос первичного ключа одного отношения в другое отношение для предотвращения потери данных при соединении.

Сформулируем третье правило.

Правило 3. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей не является обязательным, то требуется построение трех отношений - по одному на каждую объектную сущность и одному для связывающего отношения. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи, с первичным ключом, составленным из ключей объектных сущностей. Это правило можно применить в третьем варианте поведения предметной области, когда исходное отношение необходимо разбить на три отношения. Разбиение на два отношения не позволит исключить проблему нуль-значений. В случае трех отношений такая проблема исключается: в отношение ПРЕДМЕТЫ для предмета, который в данный момент не читается, определяется непустое значение по умолчанию.

Сформулируем четвертое правило.

Правило 4. Если степень бинарной связи 1:N , и класс принадлежности n-связной сущности является обязательным, то достаточно построить два отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения, а ключ 1-связной сущности добавляется в отношение для n -связной сущности в качестве атрибута.

Сформулируем пятое правило.

Правило 5. Если степень бинарной связи 1:N и класс принадлежности n-связной сущности не является обязательным, то необходимо построить три отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами последнего отношения.

Отметим, что если степень бинарной связи 1:N , то фактором, определяющим выбор одного из правил (правила 4, 5), является класс принадлежности n-связной сущности. Класс принадлежности 1-связной сущности не влияет на конечный результат декомпозиции. В ситуации правила 4 имеет место проблема нуль-значений по атрибуту Предмет, в ситуации правила 5 имеет место проблема нуль-значений по атрибутам Предмет и Преподаватель. Поэтому во избежание дублирования и нуль-значений в ситуации правил 4 и 5 необходимо строить два и три результирующих отношения соответственно. Миграция ключа 1-связной сущности выполняется для восстановления исходного отношения при соединении.

Если степень бинарной связи N:M , то во избежание дублирования и нуль-значений необходимо всегда строить три отношения. Сформулируем шестое правило.

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

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

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

Аналогично для отношения с n-сторонней связью требуется построение n+1 отношений.

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

Следует помнить, что после предварительного разбиения исходного отношения необходимо показать, используя ФЗ и ключи отношений, что полученная схема реляционной базы данных находится в НФ Бойса-Кодда (НФБК) (или 3НФ). Только тогда полученная схема отношений может считаться окончательной. Обычно проектировщики баз данных при использовании метода декомпозиции не выполняют таких действий, так как в большинстве случаев (но не всегда!) применение правил преобразования дает НФБК.

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

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

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

Рассмотрим иной вариант представления данных о служащих кафедры. Будем считать заведующего кафедрой и преподавателей служащими, и представим их функции как роли, которые данный служащий может играть. Тогда Отношение СЛУЖАЩИЙ представляет собой родительское отношение - супертип для двух подчиненных отношений - подтипов ЗАВ. КАФЕДРОЙ и ПРЕПОДАВАТЕЛЬ, которые соединяются связью Руководит.

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

Результирующие отношения:

СЛУЖАЩИЙ (#служащий, общие атрибуты для всех служащих)

ЗАВЕДУЮЩИЙ (#заведующий, ....)

ПРЕПОДАВАТЕЛЬ (#преподаватель, ..., #заведующий)

Заметим, что связь, которая соединяет две роли одной исходной сущности, называется рекурсивной (служащие руководят служащими). Связь, которая соединяет роли двух различных сущностей, не является рекурсивной.

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

Сформулируем восьмое правило.

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

Пример преобразования ER-диаграмм в отношения базы данных

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

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

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

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

3. Предположим, что только один телефон связан с данным адресом. .

4. Каждому клиенту может быть приписан телефон. .

5. Для каждого клиента определяется рейтинг (активность, частота обращений и т.д.) за период по конкретной теме. Рейтинг клиента однозначно определяется по его номеру.

6. Консультации носят тематический характер. Каждая тема имеет свой идентификатор.

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

Рассмотрим детерминанты и возможные ключи отношения КОНСУЛЬТАНТ.

Возможные ключи	Детерминанты
{Номер, Тема, Семестр}	{Номер, Тема, Семестр}
	{Номер}
	{Телефон}
	{Адрес}

Согласно критерию Кодда, поскольку не каждый детерминант в отношении есть возможный ключ, то отношение не находится в НФБК. Выполним декомпозицию отношения КОНСУЛЬТАНТ R0 (Номер, Тема, Семестр, Фамилия, Адрес, Телефон, Рейтинг). Кандидатами на выполнение проекции являются следующие ФЗ:

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

Проверим, находится ли отношение R2 в НФБК.

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

Проверим, находится ли отношение R1 в НФБК.

Возможные ключи	Детерминанты
{Номер, Тема, Семестр}	{Номер, Тема, Семестр}
	{Номер}
	{Адрес}

Отношение R1 не находится в НФБД, необходимо продолжить его декомпозицию. Выберем ФЗ и выполним разбиение R1 на R3(Номер, Тема, Семестр, Рейтинг) и R4 (Номер, Фамилия, Адрес).

Проверим, находится ли отношение R3 в НФБК.

Возможные ключи	Детерминанты
{Номер, Тема, Семестр}	{Номер, Тема, Семестр}

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

Проверим, находится ли отношение R4 в НФБК.

Возможные ключи	Детерминанты
{Номер}	{Номер}

Отношение R4 находится в НФБК. Декомпозиция закончена.

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

Декомпозиция схем отношений

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

· Декомпозицией схемы отношений R называется замена ее совокупностью схем r=(R 1 , R 2 , ... , R K), где R i Ì R и R i такие, что R 1 ÈR 2 È... ÈR K = R, при этом не требуется, чтобы R i Ç R j =Æ, хотя и допустимо.

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

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

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

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

Целостность в БД отражается путем построения логической схемы.

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

· Если состояние БД не соответствует семантике связей между данными, то такое явление называют нарушением целостности данных или БД.

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

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

Ограничения приложений делятся на:

Статические ограничения и ограничения перехода;

Ограничения для кортежей и множеств;

Отложенные и безотлагательные ограничения целостности.

· Статические ограничения - те ограничения, которые выполняются независимо от состояния БД.

· Ограничения, устанавливаемые между старым и новым значением атрибута, называется ограничениями перехода.

Пример : при обновлении значения атрибута “давление” новое значение не должно отличаться от старого более чем на 20 %.

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

· Частным случаем такого ограничения является ограничение атрибута.

· Ограничение для множеств - если они представляют собой ограничение на некоторое итоговое значение, полученное в результате использования совокупности кортежей.

Пример : при измерении температуры очередное значение не должно отличаться от скользящего среднего Mx (текущего математического ожидания) на некоторую величину e. Все значения не попавшие в диапазон [ M x - e, M x + e] отбрасывают.

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

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

Для отложенного ограничения имеет значение следующее понятие:

· Логический элемент работы - непрерывное управление данными, при котором БД из одного целостного состояния переводится в другое целостное состояние. Этот прием еще называют транзакцией.

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

Декомпозицией схемы отношения R = {А 1 , А 2 , ...,А n } называется замена ее совокупностью подмножеств R , таких, что их объединение дает R . При этом допускается, чтобы подмножества были пересекающимися .

Алгоритм декомпозиции основан на следующей теореме.

Теорема о декомпозиции . Пусть R(A, B, C) – отношение , A, B, C – атрибуты .

Если R удовлетворяет зависимости A->B , то R равно соединению его проекций A, B и A, C

R(A, B, C) = R(A, B), R(A, C)

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

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

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

8.4 .Выбор рационального набора схем отношений путем нормализации

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

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

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

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

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

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

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

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

Мотивировка третьей нормальной формы

Третья нормальная форма исключает избыточность и аномалии включения и удаления .

К сожалению, 3НФ не предотвращает все возможные аномалии.

Нормальная форма Бойса-Кодда (НФБК)

Если в R для каждой зависимости X->A , где А не принадлежит X, X включает в себя некоторый ключ, то говорят, что данное отношение находится в нормальной форме Бойса-Кодда .

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

Отношение находится в НФБК тогда и только тогда, когда каждый его детерминант является потенциальным ключом .

НФБК является более строгой версией 3НФ. Иными словами, любое отношение, находящееся в НФБК, находится в 3НФ. Обратное неверно .

Мотивировка нормальной формы Бойса-Кодда

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

8.5. Пример нормализации до 3НФ

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

Продолжим рассмотрение примера с отношением ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ

В начале этой лекции мы привели отношение к первой нормальной форме .

Код студента	Фамилия	Код экзамена	Предмет	Дата	Оценка
1	Сергеев	1	Математика	5.08.03	4
2	Иванов	1	Математика	5.08.03	5
1	Сергеев	2	Физика	9.08.03	5
2	Иванов	2	Физика	9.08.03	5

Ключом данного отношения будет совокупность атрибутов – Код студента и Код экзамена.

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

КС – код студента, КЭ – код экзамена, Ф – фамилия, П – предмет, Д – дата, О - оценка.

Выпишем функциональные зависимости

КС, КЭ -> Ф, П, Д, О КС, КЭ -> Ф КС, КЭ -> П КС, КЭ -> Д КС, КЭ -> О КЭ -> П КЭ -> Д КС -> Ф

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

Имеем отношение R(КС, Ф, КЭ, П, Д, О) . Возьмем зависимость КС -> Ф в соответствии с формулировкой теоремы исходное отношение равно соединению его проекций R1(КС, Ф) и R2(КС, КЭ, П, Д, О) .

В отношении R1(КС, Ф) существует функциональная зависимость КС -> Ф , ключ КС – составной, не ключевой атрибут Ф не зависит от части ключа. Это отношение находится в 2НФ. Так как в этом отношении нет транзитивных зависимостей, отношение R(КС, Ф) находится в 3НФ, что и требовалось.

Рассмотрим отношение R2(КС, КЭ, П, Д, О) с составным ключом КС, КЭ . Здесь есть зависимость КЭ -> П, КЭ -> Д, КЭ -> П, Д . Атрибуты П,Д зависят от части ключа, следовательно

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

8.5. Пример нормализации до 3НФ

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

Продолжим рассмотрение примера с отношением ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ

В начале этой лекции мы привели отношение к первой нормальной форме.

Ключом данного отношения будет совокупность атрибутов – Код студента и Код экзамена.

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

КС – код студента, КЭ – код экзамена, Ф – фамилия, П – предмет, Д – дата, О-оценка.

Выпишем функциональные зависимости

КС, КЭ à Ф, П, Д, О

КС, КЭ à Ф

КС, КЭ à П

КС, КЭ à Д

КС, КЭ à О

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

Имеем отношение R (КС, Ф, КЭ, П, Д, О). Возьмем зависимость КС à Ф в соответствии с формулировкой теоремы исходное отношение равно соединению его проекций R 1(КС, Ф) и R 2(КС, КЭ, П, Д, О).

В отношении R 1(КС, Ф) существует функциональная зависимость КС à Ф, ключ КС – составной не ключевой атрибут Ф не зависит от части ключа. Это отношение находтся в 2 НФ. Так как в этом отношении нет транзитивных зависимостей, отношение R (КС, Ф) находится в 3НФ, что и требовалось.

Рассмотрим отношение R 2(КС, КЭ, П, Д, О) с составным ключом КС, КЭ. Здесь есть зависимость КЭ à П, КЭ à Д, КЭ à П, Д. Атрибуты П,Д зависят от части ключа, следовательно отношение не находится в 2НФ. В соответствии с теоремой о декомпозиции исходное отношение (используем функциональную зависимость КЭ à П, Д) равно соединению проекций R 3(КЭ, П, Д), R 4(КС, КЭ, О). В отношении R 3(КЭ, П, Д) существуют функциональные зависимости КЭ à П, КЭ à Д, КЭ à П, Д. Зависимости неключевых атрибутов от части ключа нет, следовательно отношение находится в 2НФ. Транзитивных зависимостей в этом отношении так же нет, следовательно отношение находится в 3НФ.

Таким образом, исходное отношение приведено в к трем отношениям, каждое из которых находится в третьей нормальной форме R 1(КС, Ф), R 3(КЭ, П, Д), R 4(КС, КЭ, О).

Заметим, что в отношении R 4 атрибуты КС, КЭ являются внешними ключами, используемыми для установления связей с другими отношениями. Представим полученную модель в виде диаграммы объектов-связей (ER-диаграммы). Для наглядности и возможности последующего программирования перейдем к английским названиям объектов (отношений) и атрибутов.

Отношение R 1 представляет объект student с атрибутами id_st (первичный ключ), surname.

Отношение R 3 представляет объект exam_st c атрибутами id_ex (первичный ключ), subject, date.

Отношение R 4 представляет объект mark_st c атрибутами id_st (внешний ключ), id_ex (внешний ключ), mark. Первичный ключ здесь id_st, id_ex.

Соответствующая ER-диаграмма изображена на рис. 8.1.

Рис. 8.1. ER-диаграмма, представляющая рассмотренный фрагмент предметной области.

8.6. Целостная часть реляционной модели.
Реализация условия целостности данных в современных СУБД

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

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

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

Пример внешнего ключа.

СТУДЕНТ (Код студента, Фамилия) сдает ЭКЗАМЕН (Код студента, Предмет, Оценка).

Атрибут Код студента сущности ЭКЗАМЕН называется внешним ключом , поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения – отно­шения Студент (мы предполагаем, что поле Код студента является ключом отношения Студент).

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

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

Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. (В Access для этого предназначена специальная реализация целочисленного поля – поле типа «Счетчик».) С целостностью по ссылкам дела обстоят несколько более сложно.

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

Но как быть при удалении кортежа из отношения, на которое ведет ссылка?

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

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

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

Краткие итоги: Лекция посвящена вопросам оптимизации схем отношений (структуры реляционной базы данных) на основе формальных методов теории реляционных баз данных. Здесь рассматривается ряд необходимых для этого понятий (функциональная зависимость, нормальные формы, декомпозиция схем отношений). Разбирается пример приведения таблицы к третьей нормальной форме, оптимальной по ряду показателей (исключающей избыточность, аномалии включения и удаления). Рассматриваются вопросы реализации целостности данных в реляциионных СУБД.

В лекции рассматриваются вопросы использование формального аппарата для оптимизации схем отношений. Сформулирована проблема выбора рациональных схем отношений и пути реализации такого выбора путем нормализации (последовательного преобразования схемы отношения в ряд нормальных форм). Для формального описания соответствующего процесса определены понятие функциональной зависимости (зависимости между атрибутами отношения), ключа, сформулированы правила вывода множества функциональных зависимостей, понятие декомпозиции схемы отношения. Определены первая, вторая, третья нормальные формы и нормальная форма Бойса-Кодда. Приведен пример нормализации до 3НФ. Рассмотрены вопросы реализации условий целостности данных в реляционных СУБД.

Вопросы настоящей лекции рассматриваются в .

Контрольные тесты

Задача 1. В чем состоит задача выбора рациональных схем отношений?

Вариант 1.

Какие проблемы устраняются за счет выбора рациональных схем отношений?

ð+ дублирование

ð+ потенциальная противоречивость

ð+ потенциальная возможность потери сведений

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

ð увеличение количества схем отношений

Вариант 2.

С чем связано основное дублирование информации в реляционной базе данных?

ð с повторением одинаковых строк в одной таблице

ð с повторением одинаковых столбцов в одной таблице

ð+ с повторением одинаковых значений атрибутов в одной таблице

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

Вариант 3.

Какие аномалии необходимо устранить при проектировании реляционной базы данных?

ð создания

ð+ удаления

ð+ обновления

ð+ включения

ð выключения

Задача 2. Как механизм используется для выбора рациональных схем отношений?

Вариант 1.

Как осуществляется выбор рациональных схем отношений?

ð+ путем нормализации

ð+ путем последовательного преобразования отношений к ряду нормальных форм

ð путем объединения схем отношений

ð+ путем декомпозиции схем отношений

Вариант 2.

Что такое нормализация?

ð+ последовательное преобразование отношений к ряду нормальных форм

ð определенное объединение схем отношений

ð+ определенная декомпозиция схем отношений

ð преобразование отношений с использованием операций реляционной алгебры

Вариант 3.

Что такое первая нормальная форма?

ð+ значения всех атрибутов отношения являются простыми

ð+ значения всех атрибутов отношения являются неделимыми

ð+ значения всех атрибутов отношения являются атомарными

ð значения всех атрибутов отношения являются кортежами

ð значения некоторых атрибутов отношения являются атомарными

ð значения некоторых атрибутов отношения являются кортежами

Задача 3. Дать характеристику функциональных зависимостей.

Вариант 1.

Что такое X функционально определяет Y ?

ð+ каждое значение множества X Y

ð+ X Y

ð Y является функцией X

ð Y зависит от X

ð каждое значение множества Y связано с одним значением множества X

ð если два кортежа совпадают по значениям Y , то они совпадают по значениям X

Вариант 2.

Что характеризуют функциональные зависимости?

ð схему отношения

ð+ все возможные значения отношения

ð+ все возможные значения строк отношения

ð+ отношение как переменную

Вариант 3.

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

ð+ как ограничения целостности

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

ð для проверки правильности работы прикладных программ

ð для автоматизированного формирования соответствующих данных

Задача 4. Как осуществляется нормализация схем отношений?

Вариант 1.

Что такое декомпозиция схемы отношения?

ð замена схемы отношения R = {А 1 , А 2 , …А n } совокупностью подмножеств R : R 1, R 2 таких, что R = R 1 Ç R 2

ð+ замена схемы отношения R = {А 1 , А 2 , …А n } совокупностью подмножеств R : R 1, R 2 таких, что R = R 1 È R 2

ð замена схемы отношения R = {А 1 , А 2 , …А n }совокупностью подмножеств R : R 1, R 2 таких, что R = R 1 ´ R 2

ð замена схемы отношения R = {А 1 , А 2 , …А n }совокупностью подмножеств R : R 1, R 2 таких, что R = R 1 + R 2

Вариант 2.

Как формулируется теорема о декомпозиции?

ð+ если R (A, B, C ) удовлетворяет зависимости A àB , то R равно соединению проекций

R (A, B ), R (A, C )

ð если R (A, B, C ) удовлетворяет зависимости A àB , то R равно соединению проекций

R (A, B ), R (B, C )

ð если R (A, B, C ) удовлетворяет зависимости A àB , то R равно соединению проекций

R (A, C ), R (B, C )

ð+ если R (A, B, C ) удовлетворяет зависимости A àB , то R равно соединению проекций

R (A, C ), R (A, B )

Вариант 3.

Какими свойствами должны обладать декомпозиции при нормализации?

ð+ сохранение функциональных зависимостей

ð+ соединения без потерь

ð разбиение без потерь

ð сохранение ключа

Задача 5. Приведение ко второй нормальной форме.

Вариант 1.

При каких условиях отношение находится во второй нормальной форме?

ð+ если оно находится в первой нормальной форме и каждый неключевой атрибут зависит от всего первичного ключа

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

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

ð+ если оно находится в первой нормальной форме и каждый неключевой атрибут не зависит от части первичного ключа

Вариант 2.

Как осуществляется приведение ко второй нормальной форме?

ð+

ð сначала схема отношения приводится к первой нормальной форме

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

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

Вариант 3.

Какие аномалии устраняются второй нормальной формой?

ð удаления

ð избыточность

ð обновления

ð включения

ð+ никакие

Задача 6. Приведение к третьей нормальной форме.

Вариант 1.

При каких условиях отношение находится в третьей нормальной форме?

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

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

ð+ если оно находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа

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

Вариант 2 .

Как осуществляется приведение к третьей нормальной форме?

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

ð+ сначала схема отношения приводится ко второй нормальной форме

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

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

Вариант 3.

Какие аномалии устраняются третьей нормальной формой?

ð удаления

ð+ избыточность

ð обновления

ð+ включения

ð+ никакие

Задача 7. Анализ функциональных зависимостей следующего отношения.

Вариант 1 .

Какие из перечисленных зависимостей существуют в этом отношении?

ð+ Код студента →Фамилия

ð+ Предмет→Дата

ð+ Код экзамена →Дата

ð Код студента→Оценка

Вариант 2.

Каких из перечисленных зависимостей не существует в этом отношении?

ð Код студента, Фамилия→Фамилия

ð Предмет→Дата

ð Код экзамена →Дата

ð+ Код студента→Оценка

ð Код студента, Предмет→Оценка

Вариант 3.

В какой зависимости определен первичный ключ отношения?

ð Код студента, Фамилия→Фамилия, Предмет

ð Предмет→Дата

ð Код экзамена →Дата

ð Код студента→Оценка

ð Код студента, Предмет→Оценка

ð+ Код студента, Код предмета →Дата, Оценка

Задача 8. Как осуществляется поддержка целостности данных в реляционных СУБД?

Вариант 1.

Какие требования должны выполняться для поддержки целостности данных в реляционных СУБД?

ð+ уникальность любого кортежа отношения

ð+ наличие у любого отношения первичного ключа

ð+

ð

Вариант 2 .

В чем состоят ограничения целостности сущности и по ссылкам?

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

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

ð должны быть экземпляры сущностей

ð+ экземпляры сущностей должны уникально идентифицироваться

Вариант 3.

Какие варианты поддержки ограничений целостности по ссылкам используются в современных СУБД?

ð+ запрещается удалять кортеж, на который существуют ссылки.

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

ð+ при удалении кортежа, на который существуют ссылки, из ссылающегося отношения удаляются все ссылающиеся кортежи

ð при удалении кортежа, на который существуют ссылки, удаляется ссылающееся отношение

Литература

1. Карпова Т. Базы данных. Модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

2. Конноли Т., Бэгг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

3. Ульман Дж. Д., Уидом Дж. Введение в системы баз данных: Пер. с англ. – М.: Лори, 2000. – 374 с.

4. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для вузов. – СПб.: КОРОНА принт, 2000. – 416 с.

5. Толстобров А.П. Управление данными. Учебное пособие. Воронеж: Изд-во Воронежского ГУ, 2007 – 205 с.

6. Хансен Г., Хансен Дж. Базы данных: разработка и управление: Пер. с англ. – М.: ЗАО «Издательство «БИНОМ», 1999. – 704 с.

7. Дейт К.Дж. Введение в системы баз данных: Пер. с англ. – 6-е изд. – К.: Диалектика, 1998. – 784 с.

8. Швецов В.И., Визгунов А.Н., Мееров И.Б. Базы данных. Учебное пособие. Н.Новгород: Изд-во ННГУ, 2004. 271 с.

Лекция 9. Физические модели данных
(внутренний уровень)

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

Ключевые термины: физические модели данных, структуры хранения, представление данных в памяти ЭВМ, физическая запись, последовательный файл, списковая структура, В-дерево, хэш-функция, индексирование.

Цель лекции: дать представление об основных типовых способах организации данных в памяти ЭВМ в СУБД с оценкой соответствующих моделей по времени доступа к данным в базе данных и по объему занимаемой памяти.

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

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

В настоящей лекции будут рассмотрены типовые физические модели организации данных в конкретных СУБД.

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

9.1. Структура памяти ЭВМ

Важнейшей особенностью памяти ЭВМ, в значительной степени определяющей методы организации данных и доступа к ним, является её неоднородность. Существуют два разных типа памяти – оператив­ная (ОП) и внешняя (ВП), причем процессор работает только с данными из оперативной памяти (рис. 9.1.).

Рис. 9.1. Схема работы ЭВМ

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

Отметим основные свойства оперативной памяти:

· единицей памяти является байт;

· память прямоадресуема (каждый байт имеет адрес);

· процессор выбирает для обработки нужные данные, непосредственно адресуясь к последовательности байтов, содержащих эти данные.

Отметим основные свойства внешней памяти:

· минимальной адресуемой единицей является физическая запись;

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

· время чтения записи в ОП (занесения записи из ОП в ВП) на несколько порядков выше времени обработки процессором записи из ОП;

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

9.2. Представление экземпляра логической записи

Логическая запись представляется в оперативной памяти следующим образом:

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

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

В большинстве современных СУБД используется формат записей фиксированной длины. В этом случае все записи имеют одинаковую длину, определяемую суммарной длиной полей, составляющих запись. В СУБД другие форматы записей (переменной длины, неопределенной длины) встречаются гораздо реже, поэтому в данной книге эти форматы не рассматриваются. Заметим, что поля записи, принимающие значения существенно разной длины в различных экземплярах записей, в предметной области встречаются достаточно часто. Примером может служить поле резюме в записи СОТРУДНИК. Резюме может составлять полстраницы текста, страницу и т.д. Возникает проблема – как эту информацию переменной длины представить в записи фиксированной длины. Возможным вариантом является установление размера соответствующего поля по максимальному значению. В этом случае у многих экземпляров записи указанное поле будет заполнено не полностью и, таким образом, память ЭВМ будет использоваться неэффективно. Более эффективный и часто используемый в СУБД прием организации таких записей состоит в следующем. Вместо поля (полей), принимающего значение существенно разной длины, в запись включается поле-указатель на область памяти, где будет размещаться значение исходного поля. Как правило, эта область является областью внешней памяти прямого доступа. В процессе ввода соответствующего значения в выделенной области занимается столько памяти, какова длина этого значения.

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

Рис. 9.2. Представление полей переменной длины

Конкретной реализацией такой схемы является поле типа МЕМО в СУБД (dBase III+, FoxPro, Access и т.д.).

9.3. Организация обмена между оперативной
и внешней памятью

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

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

· в ОП последовательно вводятся k экземпляров логических записей (кортежей);

· введенные k экземпляров объединяются в физическую запись (блок);

· физическая запись заносится во внешнюю память.

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

Рис. 9.3. Схема занесения записей во внешнюю память

Обработка данных, хранящихся во внешней памяти, осуществляется следующим образом:

· физическая запись (блок) считывается в оперативную память;

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

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

9.4. Структуры хранения данных во внешней памяти ЭВМ

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

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

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

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

Физическая запись с номером I содержит логические записи с номерами

(I – 1) k +1

(I – 1) k +2

(I – 1) k +k

I = 1, 2, …, ;

знаком обозначим ближайшее целое, большее или равное N/k, – целое сверху.

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

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

Аномалии модификации данных

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

Рассмотрим эти аномалии на примере отношения со следующими атрибутами (атрибуты, входящие в ключ, выделœены подчёркиванием):

ПОСТАВКИ (Номер поставки, Название товара , Цена товара, Количество, Дата поставки, Название поставщика, Адрес поставщика)

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

1. Аномалия обновления : в отношении ПОСТАВКИ она может возникнуть, в случае если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во всœе кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы.
2. Аномалия удаления : при удалении записей обо всœех поставках определённого поставщика всœе данные об этом поставщике будут утеряны.
3. Аномалия добавления : в нашем примере она возникнет, в случае если с поставщиком заключен договор, но поставок от него ещё не было. Сведения о таком поставщике нельзя внести в таблицу ПОСТАВКИ , т.к. для него не определён ключ (номер поставки и название товара) и другие обязательные атрибуты.

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

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

Декомпозицией схемы отношения R принято называть замена её совокупностью схем отношений А i таких, что

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

Покажем нормализацию на примере отношения КНИГИ (табл. 8.1):

Id	- идентификатор (первичный ключ),
Code	- шифр рубрики (по ББК – библиотечно-библиографической классификации),
Theme	- название рубрики (по ББК),
Title	- название книги,
Author	- автор(ы),
Editor	- редактор(ы),
Type	- тип издания (учебник, учебное пособие, сборник и.т.п.),
Year	- год издания
Pg	- количество страниц

Таблица 8.1. Исходное отношение КНИГИ

Нормализация и декомпозиция отношений - понятие и виды. Классификация и особенности категории "Нормализация и декомпозиция отношений" 2017, 2018.