Вторая нормальная форма.

Первая нормальная форма.

Нормализация данных в реляционных таблицах

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ Ч.2

Лекция 05

Технологии баз данных и знаний

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

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

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

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

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

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

Предположим, что сначала все заказы клиентов были сведены в одну таблицу ЗаказИнфо:

ЗаказИнфо

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

Проблемы такой таблицы:

· Узнаем адрес клиента, только в том случае если он что- то заказал

· При удалении записи о продукте одновременно удаляются все сведения о самом заказе и о клиенте

· Если сменил адрес, например, то его надо менять в каждой записи

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

1-й шаг

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

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

ЗаказИнфо1

В исходной таблице поле Код клиента определяется как внешний ключ

2-й шаг

В исходной таблице определяем поля, которые зависят только от первичного ключа, т.е. их значения не меняются при одинаковом значении записи первичного ключа. Очевидно, что это поля Город и Улица Только эти поля остаются в таблице ЗаказИнфо1, остальные поля удаляются. Таблица ЗаказИнфо1 переименуем в таблицу Клиенты. Из исходной таблицы ЗаказИнфо эти же поля удаляются и исходная таблица ЗаказИнфо перименовываем в таблицу ЗаказИнфо2:

Клиенты

ЗаказИнфо2

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

Клиенты ЗаказИнфо2

Код клиента (ПК)		Код клиента (ВК)
Город		Номер заказа
Улица		Вес заказа
		Дата заказа
		Код валюты
		Наименование валюты

Во второй нормальной форме можно также заметить аномалии, в частности в таблице ЗакзаИнфо2:

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

· при удалении заказа может быть удалено и наименование валюты

Вывод: необходимо преобразовать таблицу ЗаказИнфо2, чтобы устранить указанную аномалию.