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

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

Пример: Рейс (номер_рейса, пункт_назначения, Расписание)

Расписание (день, время_вылета)

Пусть имеются следующие данные о рейсах:

Р101 Владивосток пон. 9:40

вт. 9:30

пятн. 10:30

Р800 Москва пон. 7:30

чет. 7:30

пятн. 7:30

Преобразовать эти данные в 1НФ можно 2 способами:

1) В составной таблице Рейс заменить таблицу Расписание соответствующими атрибутами:

Рейс (номер_рейса, пункт_назначения, день, время_вылета)

номер	пункт_назначения	день	время_вылета
Р101	Владивосток	пон.	9:40
Р101	Владивосток	вт.	9:30
Р101	Владивосток	пятн.	10:30
Р800	Москва	пон	7:30
Р800	Москва	чет.	7:30
Р800	Москва	пятн.	7:30

Недостатки этого способа:

а) избыточность; б) необходимость определения нового ключа.

2) Таблица с множественными значениями указывает на то, что существует, по крайней мере, один объект (сущность), который должен описываться отдельной таблицей. Нужно выделить из имеющейся таблицы этот объект, определить его структуру (поля), и провести декомпозицию таблицы так, чтобы каждая из полученных таблиц находилась в 1НФ:

Рейс (номер_рейса, пункт_назначения)

Расписание (день, время_вылета, номер_рейса) – будем считать, что 2 разных самолета не могут вылететь одновременно!)

Рейс <--->> Расписание

В таблице Расписание можно избавиться от составного ключа день, время_вылета, добавив уникальное поле, например, код_расписания, и выбрав его в качестве первичного ключа:

Расписание (код_расписания, день, время_вылета, номер_рейса),

однако делать этого до полной нормализации не рекомендуется.

Вторая нормальная форма (2нф)

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

Пример:

Пусть имеется таблица Поставка, содержащая данные о поставщиках (идентифицируемых номером), поставляемых ими товарах и их ценах.

Поставка (номер_поставщика, товар, цена)

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

номер_поставщика, товар  цена

товар  цена

Можно отметить неполную функциональную зависимость атрибута цена от ключа.

Это приводит к следующим аномалиям:

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

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

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

Разложение таблицы Поставка на две таблицы устранит неполную функциональную зависимость:

Поставка (номер_поставщика, товар)

Цена_товара (товар, цена)

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