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

Первая нормальная форма (1НФ, First Normal Form, 1NF) – это основа реляционной системы. В 1НФ нельзя хранить несколько значений в одном столбце. В терминах теории баз данных каждое значение в столбце таблицы является элементарным (атомарным), то есть состоящим из одного экземпляра.

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

Номер заказа	Код товара	Стоимость заказа
1	1220, 1405, 1602, 1201, 1000	1174
2	2001, 1001, 2245	61
2	2021, 4000	186

Рис. 2.17. Фрагмент системы обеспечения продажи товаров

Чтобы реализовать систему обеспечения продажи, удовлетворяющую условию 1НФ, необходимо иметь заказ, представленный комбинацией от 1 до N записей, содержащих информацию о коде элементов заказа. Это решение усложняет выборку информации о содержании товаров в конкретном заказе, т.к. в этом случае требуется извлекать каждую ассоциированную с заказом запись и проверять, что извлекается именно нужная запись. Результат применения первого прохода при нормализации таблицы базы данных приведен на рис. 2.18.

Номер заказа	Код товара	Наименование товара	Оптовая цена
1	1220	Болты	12
1	1405	Молоток	20
1	1602	Гвозди	10
1	1201	Гайки	16
1	1000	Электропила	880
2	2001	Напильник	19
2	1001	Ключ гаечный	14
2	2245	Отвертка	15
2	2021	Стамеска	24
2	4000	Рубанок	124

Рис. 2.18. Фрагмент организации данных, удовлетворяющих условию 1НФ

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

Первым требованием второй нормальной формы (2НФ, Second Normal Form, 2NF) является выполнение требований первой нормальной формы. В соответствии со вторым требованием каждая строка в таблице базы данных должна быть уникально идентифицирована.

В таблице заказов на рис. 2.18 на первый взгляд все выглядит так, как будто структура соответствует этому правилу. Мы установили идентификатор заказа (номер заказа). Если его скомбинировать с идентификатором товара (код товара), то получится уникальный указатель на строку – составной ключ. Однако можно отметить неполную функциональную зависимость атрибута "Наименование товара" от этого ключа, поскольку семантика отношения для данного атрибута на самом деле включает следующие функциональные зависимости:

Номер заказа, Код товара  Наименование товара;

Код товара  Наименование товара.

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

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

Аномалия удаления. Если какой-либо товар удалить из базы данных (снят с продажи), то при этом будет потеряна не только информация о тех заказах, в которых присутствовал этот товар, но и об оптовой цене на этот товар.

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

Для того чтобы выполнить требование второй нормальной формы для нашего примера, достаточно добавить к таблице новый столбец – идентификатор товара в заказе (код товара в заказе на рис. 2.19). Хотя новый товар был добавлен под номером 11, он по-прежнему относится к заказу, определенному порядковым номером заказа. В результате обеспечивается уникальная идентификация строк в таблице путем ввода нового первичного ключа и преодолевается проблема, связанная с операциями включения данных. Проблемы, связанные с операциями удаления и обновления, в данном случае не решаются, и необходима дальнейшая нормализация.

Код товара в заказе	Номер заказа	Код товара	Наименование товара	Оптовая цена
1	1	1220	Болты	12
2	1	1405	Молоток	20
2	1	1602	Гвозди	10
4	1	1201	Гайки	16
5	1	1000	Электропила	880
6	1	1220	Болты	12
1	2	2001	Напильник	19
2	2	1001	Ключ гаечный	14
2	2	2245	Отвертка	15
1	2	2021	Стамеска	24
2	2	4000	Рубанок	124

Рис. 2.19. Фрагмент организации данных, удовлетворяющих условию 2НФ