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

Однако существует следующая зависимость – Преподаватель, Дата определяют ( ) Аудитория.

Нарушается определение формы БК – данный составной атрибут является детерминантом, но не является потенциальным ключом.

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

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

Выход – разбиение исходного отношения на два.

РАСПИСАНИЕ КОНСУЛЬТАЦИЙ (Группа, Дата, Время, Преподаватель)

АУДИТОРИИ (Преподаватель, Дата, Аудитория)

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

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

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

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

В настоящее время можно выделить два способа применения нормализации.

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

115

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

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

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

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

Рассмотрим пример из предметной области зачисления абитуриен-

тов.

Рис. 31. Фрагмент ER-диаграммы

116

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

То же самое можно сказать про сущности «mark» и «exam». Проверка на соответствие третьей нормальной форме остальной части модели предоставляется в качестве упражнения читателю.

Рассмотрим пример применения первого подхода.

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

Сведем все данные, которые у нас есть, в одну таблицу. Она будет выглядеть примерно так (для упрощения мы не рассматриваем часть атрибутов):

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

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

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

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

117

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

В данной таблице существуют неполные зависимости.

Код абитуриента функционально определяет Имя и Фамилию. Код экзамена функционально определяет Предмет и Дату. Выделим из нашей таблицы новые таблицы, соответствующие не-

полным зависимостям. Получаем следующие отношения: АБИТУРИЕНТЫ (Код абитуриента, Имя, Фамилия). Ключ – Код абитуриента.

ЭКЗАМЕНЫ (Код экзамена, Предмет, Дата). Ключ – Код экзамена.

В исходном отношении остаются атрибуты Код абитуриента, Код экзамена, Оценка.

ОЦЕНКИ (Код абитуриента, Код экзамена, Оценка). Ключ, попрежнему, совокупность атрибутов Код абитуриента и Код экзамена.

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

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

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

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

Напомним, что под целостностью базы данных понимается то, что

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

вреляционных БД основана на выполнении следующих требований.

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

118

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

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

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

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

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

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

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

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

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

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

119

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

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

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

120