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

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

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

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

• полное имя сотрудника (СОТР_ИМЯ),

• номер его удостоверения (СОТР_НОМЕР),

• информацию о его соответствии занимаемой должности (для простоты, "да" или "нет") (СОТР_СТАТУС),

• размер зарплаты (СОТР_ЗАРП),

• номер отдела, где он работает (СОТР_ОТД_НОМЕР),

• номер выполняемого им проекта (СОТР_ПРО_НОМЕР).

• имя руководителя отдела (СОТР_ОТД_РУК), поскольку мы хотим ограничиться одним файлом.

Функции нашей информационной системы требуют, чтобы обеспечивалась возможность многоключевого доступа к этому файлу по уникальным ключам (недублируемым в разных записях) СОТР_ИМЯ и СОТР_НОМЕР. Кроме того, должна обеспечиваться возможность выбора всех записей с общем значением СОТР_ОТД_НОМЕР или СОТР_ПРО_НОМЕР, то есть доступ по неуникальному ключу. Для того, чтобы получить численность отдела или общий размер зарплаты, каждый раз при выполнении такой функции информационная система должна будет выбрать все записи о сотрудниках отдела или о сотрудниках, выполняющих данный проект, посчитать соответствующие общие значения.

Таким образом, мы видим, что даже для такой простой системы ее реализация на базе файловой системы, во-первых, требует создания достаточно сложной надстройки для многоключевого доступа к файлам, и, во-вторых, вызывает требование существенной избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя) и выполнение массовой выборки и вычислений для получения суммарной информации об отделах. Кроме того, если в ходе эксплуатации системы нам захочется, например, выдавать списки сотрудников, получающих заданную зарплату, то придется либо полностью просматривать файл, либо реструктуризовывать его, объявляя ключевым поле СОТР_ЗАРП.

Рассмотрим на примере этого файла задачу его нормализации. Предположим наш файл (таблица) о сотрудниках содержит следующие поля СОТР_ИМЯ, СОТР_НОМЕР, СОТР_ОТД_НОМЕР, СОТР_ПРО_НОМЕР. При этом будем предполагать, что один сотрудник может быть задействован в нескольких проектах, например, в трех. Тогда последнее поле в нашей таблице СОТР_ПРО_НОМЕР нужно в таблице представить в виде трех полей СОТР_ПРО_НОМЕР1, СОТР_ПРО_НОМЕР2, СОТР_ПРО_НОМЕР3.

Требование первой нормальной формы состоит в том, чтобы таблицы не содержали повторяющихся групп. Однако в нашей таблице появились эти повторяющиеся группы и, следовательно, она не удовлетворяет требованиям 1НФ. Тем более, не всегда известно в скольких проектах задействован данный сотрудник: в одном, двух или трех. Решается этот вопрос просто. В структуретаблицы остается одно поле СОТР_ОТД_НОМЕР, а количество записей для одного сотрудника, участвующего в нескольких проектах будет соответствовать количеству проектов, в которых он участвует.

Предположим, что мы работаем с базой данных, состоящей из таблицы, содержащей информацию СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ. Таблица имеет следующую структуру: (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН).

Первичным ключем этой таблицы будет составной ключ СОТР_НОМЕР, ПРО_НОМЕР, так как мы уже говорили, что один сотрудник может участвовать в нескольких проектах. Рассмотрим зависимости полей таблицыот первичного ключа. Хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, поля СОТР_ЗАРП и ОТД_НОМЕР функционально зависят лишь от части первичного ключа: поля СОТР_НОМЕР. В результате, если в таблицу необходимо вставить запись, в которой содержится информация о сотруднике, не выполняющем пока ни одного проекта, то мы этого сделать не можем, так как первичный ключ не может содержать неопределенное значение. При удалении записи мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все записи, описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.

Можно произвести следующую декомпозицию таблицы СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в две таблицы СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ следующей структуры:

СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)

Первичный ключ:

СОТР_НОМЕР

Функциональные зависимости:

СОТР_НОМЕР (r) СОТР_ЗАРП

СОТР_НОМЕР (r) ОТД_НОМЕР

ОТД_НОМЕР (r) СОТР_ЗАРП

СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Первичный ключ:

СОТР_НОМЕР, ПРО_НОМЕР

Функциональные зависимости:

СОТР_НОМЕР, ПРО_НОМЕР (r) CОТР_ЗАДАН

Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем).

Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся во 2NF. Заметим, что заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это для примера всегда можно предположить).

Другими словами функциональная зависимость СОТР_НОМЕР (r) СОТР_ЗАРП является следствием функциональных зависимостей СОТР_НОМЕР (r) ОТД_НОМЕР и ОТД_НОМЕР (r) СОТР_ЗАРП. Другими словами, В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении записи, описывающей последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все записи, описывающие сотрудников этого отдела. Т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.