Третья нормальная форма

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

Рис. 6.6 Диаграмма функциональной зависимости в 3НФ

ОтношенияАи Б в 3НФ, первичные ключи D и Имя_детали. Следовательно, этапы нормализации следующие:

1. Создание проекций для исключения "приводимых" ФЗ.

2. Создание проекций для исключения транзитивных ФЗ.

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

• Отношение находится в нормальной форме Бойса-Кодда тогда и только тогда, когда каждая нетривиальная и неприводимая слева ФЗ обладает потенциальным ключом в качестве детерминанта (левая часть ФЗ). На диаграмме стрелки ФЗ начинаются только с потенциальных ключей. Если убрать связь имя_детали→ количество и ввести дополнительный независимый атрибут, например DD, в качестве потенциального ключа, то схема, показанная на диаграмме, будет находиться в НФБК.

Рис. 6.7 Диаграмма функциональной зависимости в НФБК

Для веса и материала можно также ввести потенциальные ключи, ФЗ усложнится.

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

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

Пятая нормальная форма

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

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

Избыточное дублирование данных и аномалии

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

 Таблица 13

Код сотрудника	ФИО	Должность	Номер отдела	Наименование отдела	Квалификация
7513	Иванов И.И.	Программист	128	Отдел проектирования	C, Java
9842	Сергеева С.С.	Администратор БД	42	Финансовый отдел	DB2
6651	Петров П.П.	Программист	128	Отдел проектирования	VB, Java
9006	Николаев Н.Н.	Системный администратор	128	Отдел проектирования	Windows, Linux

При использовании универсального отношения возникают две проблемы:

·     избыточность данных;

·     потенциальная противоречивость (аномалии).

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

Аномалии – это проблемы, возникающие в данных из-за дефектов проектирования БД. Существуют три вида аномалий: вставки, удаления и модификации.

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

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

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