Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
dbbook(2010.04.15).pdf
Скачиваний:
51
Добавлен:
09.06.2015
Размер:
2.14 Mб
Скачать

X ! Y 2 F +(S) ) 8r(S)finvhF (S)ir(S) ) invhX ! Y ir(S)g

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

Из теоремы следует практически важные выводы.

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

2.Достаточно ограничиться рассмотрением полностью нетривиальных зависимостей, в которых левые и правые части не пересекаются.

3.Функциональные зависимости с одинаковыми левыми частями допускают произвольное объединение и разбиение правых частей (согласно правилам аддитивности и проективности).

4.2. Нормальные формы

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

1)декларативно с помощью объявления первичных, кандидатных и внешних ключей,

2)процедурно с помощью написания программного кода триггеров.

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

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

Вариант 1 схемы БД

Сессия(№ ЗК, Ф, И, О, МнемоП, Оценка) primary key(№ ЗК, МнемоП)

{№ ЗК} ! {Ф, И, О}

Здесь для поддержания целостности данных, то есть для выполнения ограничения функциональной зависимости {№ ЗК} ! {Ф, И, О}, при изменении фамилии необходимо просматривать все кортежи отношения и вводить необходимые изменения (что чревато ошибками; ситуация усугубляется, если Ф, И, О имеются и в других отношениях). Однако поддержку этой функциональной зависимости можно реализовать автоматически с помощью объявлений ключей, если провести декомпозицию этого отношения так, чтобы ненавязанная функциональная зависимость {№ ЗК} ! {Ф, И, О} была навязана объявлением ключа № ЗК в отношении, полученным из исходного проекцией на объединение атрибутов левой и правой частей функциональной зависимости (рис. 4.1).

Вариант 2 схемы БД

Студенты(№ ЗК, Ф, И, О) primary key(№ ЗК)

Сессия(№ ЗК, МнемоП, Оценка)

primary key(№ ЗК, МнемоП)

foreign key(№ ЗК) references Студенты(№ ЗК)

Рис. 4.1.: Результат декомпозиции отношения (см. табл. 4.1)

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

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

4.2.1. Первая нормальная форма (1NF)

На ранних стадиях проектирования схем баз данных для краткости используются

1)наряду с простыми, то есть атомарными, и составные атрибуты, составленные из нескольких разнородных атрибутов;

2) наряду с однозначными и многозначные атрибуты, представляющие множества значений.

Возможны различные комбинации простых или составных и однозначных или многозначных атрибутов (табл. 4.2).

Таблица 4.2.: Примеры атрибутов различных видов

АТРИБУТ

простой

составной

однозначный

Телефон

Адрес

многозначный

Телефоны

Адреса

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

Конец определения.

Рассмотрим пример ненормализованного отношения:

Вариант 1 схемы БД

Должности(КодД, Наименование) primary key(КодД)

candidate key(Наименование)

Сотрудники(№ таб, ФИО, КодД, Телефоны, ДатаПУ) primary key(№ таб)

foreign key(КодД) references Должности(КодД)

Здесь имеются следующие ошибки нормализации:

1)атрибут ФИО является составным, то есть составленным из разнородных атрибутов;

2)атрибут Телефоны является многозначным, то есть его значением является множество значений;

3)атрибут ДатаПУ (Дата приема или увольнения) не имеет однозначной семантики.

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

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

Для приведения отношения к первой нормальной форме следует:

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

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

После приведения отношения Сотрудники к первой нормальной форме получим:

Вариант 2 схемы БД

Должности(КодД, Наименование) primary key(КодД)

candidate key(Наименование)

Сотрудники(№ таб, Ф, И, О, КодД, Дата приема, Дата увольнения: null)

primary key(№ таб)

foreign key(КодД) references Должности(КодД)

Телефоны(№ таб, Телефон) primary key(№ таб, Телефон)

foreign key(№ таб) references Сотрудники(№ таб)

Примечание. В отношении Телефоны атрибут № таб является одновременно атрибутом первичного ключа и внешним ключом, ссылающимся на первичный ключ отношения Сотрудники

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

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

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

В левой части функциональной зависимости могут быть представлены атрибуты, не образующие в совокупности первичный или кандидатный ключ («не ключ»), так как зависимости с левой частью, образующей ключ, навязываются ограничениями уникальности при объявлении ключей.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]