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

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

 

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

 

Номер телефона 4328 в таблице 8.1 повторяет несколько раз, хотя для каждого служащего он уникален. При удалении одного из номеров будет утеряна информация о том, по какому номеру можно дозвониться до сотрудника.

Таблица 8.1

Телефоны служащих

 

Сотрудник	Телефон
Иванов
Баранов
Сидоров

Пример: избыточное дублирование (см. таблицу 8.2).

Таблица 8.2

Телефоны служащих

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

Сотрудник	Телефон	Номер комнаты
Иванов
Баранов
Сидоров

 

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

Необходимо разделить данную таблицу на две, для устранения избыточного дублирования данных (см. таблицы 8.3 и 8.4).

 

Таблица 8.3 Таблица 8.4

Телефоны служащих Служащие

Телефон	Номер комнаты		Сотрудник	Номер комнаты
			Иванов
			Баранов
			Сидоров
			Егоров

 

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

 

Таблица 8.5

Отделы предприятия

 

№ отдела	Название отдела	№ руководителя	Бюджет	Расположение
	продаж			Москва
	продаж			Зеленоград
	разработок			Тверь
	продаж			Калуга

 

Для приведения этой таблицы к 1НФ необходимо устранить поле «Расположение» из таблицы «Отделы предприятия» (см. таблицу 8.6).

Таблица 8.6

Расположение отделов Отделы предприятия

№ отдела	Расположение		№ отдела	Название отдела	Бюджет	№ руководителя
	Москва			продаж
	Зеленоград			разработок
	Тверь
	Калуга

ВТОРАЯ НОРМАЛЬНАЯ ФОРМА

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

 

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

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

Таблица 9.1.

Проекты предприятия

 

Таб.номер	Код проекта	ФИО работника	Название проекта	Продукт
	БРЖ	Иванов И.И.	Биржа	программа
	ДОК	Петров П.П.	Документы	программа
	УПР	Сидоров С.С.	Управление	адм.меры

 

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

1) атрибуты «Название проекта» и «Продукт» зависят от атрибута «Код проекта» (являющегося частью первичного ключа), но не зависят от атрибута «Таб.номер»;

2) атрибут «ФИО работника» зависит от атрибута «Таб.номер», но не зависит от атрибута «Код проекта».

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

Для нормализации таблицы «Проекты предприятия» удалим из нее атрибуты «Таб. номер» и «ФИО работника» и объединим их в таблицу «Работники предприятия».

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

Работники предприятия Проекты предприятия Работник в проекте

 

Таб. номер	ФИО работника		Код проекта	Название проекта	Продукт		Таб. номер	Код проекта
	Иванов И.И.		БРЖ	Биржа	программа			БРЖ
	Петров П.П.		ДОК	Документы	программа			ДОК
	Сидоров С.С.		УПР	Управление	адм.меры			УПР

ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА

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

 

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

Добавим поля «№ руководителя» и «Телефон» в таблицу «Проекты предприятия», находящуюся в 2НФ (первичным ключом является поле «Код проекта»).

Атрибут «Телефон» логически связан с атрибутом «№ руководителя», неключевым полем, но не с атрибутом «Код проекта», являющимся первичным ключом (см. таблицу 10.1).

Таблица 10.1.

Проекты предприятия

 

Код проекта	№ руководителя	Телефон	Название проекта	Продукт
БРЖ		2-21	Биржа	программа
ДОК		2-43	Документы	программа
УПР		2-56	Управление	адм.меры

 

Для нормализации этой таблицы удалим атрибут «Телефон». Сделаем атрибут «№ руководителя» внешним ключом, ссылающимся на атрибут «№ работника» (первичный ключ) в таблице «Работники» (см.таблицы 10.2 и 10.3).

Таблица 10.2.

Проекты предприятия

 

Код проекта	руководитель	Название проекта	Продукт
БРЖ		Биржа	программа
ДОК		Документы	программа
УПР		Управление	адм.меры

 

Таблица 10.3.

Работники предприятия

 

№ работника	Телефон
	2-21
	2-56
	2-43