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

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

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

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

Лекция 05

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

 

 

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

 

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

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

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

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

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

 

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

 

ЗаказИнфо

 

Номер заказа Код клиента Город Улица Вес заказа Дата заказа Код валюты Наименование валюты
АА Минск Правды 11 01.02.06 Бел рубль
АА Минск Правды 11 01.02.06 Бел рубль
АС Пуховичи Широкая 1 10.03.06 Росс рубль
АС Пуховичи Широкая 1 11.03.06 Росс рубль
АС Пуховичи Широкая 1 12.03.06 Евро
АС Пуховичи Широкая 1 10.03.06 Росс рубль
АС Пуховичи Широкая 1 15.04.06 Росс рубль
АС Пуховичи Широкая 1 15.04.06 Доллар США
АС Пуховичи Широкая 1 15.04.06 Росс рубль
АВ Мюнхен Лейбница 8 20.04.06 Евро
АВ Мюнхен Лейбница 8 20.04.06 Евро
АД Минск Захарова 20 08.05.06 Доллар
АС Пуховичи Широкая 1 15.05.06 Росс рубль
АС Пуховичи Широкая 1 15.05.06 Росс рубль

 

 

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

 

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

 

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

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

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

 

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

 

 

1-й шаг

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

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

 

 

ЗаказИнфо1

Номер заказа Код клиента Город Улица Вес заказа Дата заказа Код валюты Наименование валюты
АА Минск Правды 11 01.02.06 Бел рубль
АС Пуховичи Широкая 1 10.03.06 Росс рубль
АВ Мюнхен Лейбниц 8 20.04.06 Евро
АД Минск Захарова 20 08.05.06 Доллар

 

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

 

2-й шаг

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

 

 

Клиенты

 

Код клиента Город Улица
АА Минск Правды 11
АС Пуховичи Широкая 1
АВ Мюнхен Лейбниц 8
АД Минск Захарова 20

 

 

ЗаказИнфо2

Код клиента Номер заказа Вес заказа Дата заказа Код валюты Наименование валюты
АА 01.02.06 Бел рубль
АА 01.02.06 Бел рубль
АС 10.03.06 Росс рубль
АС 11.03.06 Росс рубль
АС 12.03.06 Евро
АС 10.03.06 Росс рубль
АС 15.04.06 Росс рубль
АС 15.04.06 Доллар США
АС 15.04.06 Росс рубль
АВ 20.04.06 Евро
АВ 20.04.06 Евро
АД 08.05.06 Доллар США
АС 15.05.06 Росс рубль
АС 15.05.06 Росс рубль

 

 

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

 

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

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

 

 

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

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

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

 

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