Третья нормальная форма (3NF)

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

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

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

Здесь неключевые атрибуты Название должностиi  и Окладi  находятся в транзитивной зависимости.

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

В рассмотренной ситуации нужно было создать новую сущность "Должность" с находящимися в транзитивной зависимости атрибутами - Название должностиi  и Окладi  и сделать ссылку от "Сотрудника" на "Должность":

 

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

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

В заключение рассмотрим еще один пример.

Пример: Имеется сущность "Наряд на изготовление изделий" с атрибутами: номер наряда, дата и номер смены, на которую выписан наряд, фамилия, имя, отчество и табельный номер исполнителя, наименование операции 1, стоимость ее выполнения, необходимое количество1, наименование операции 2, стоимость ее выполнения, необходимое количество 2, …, общая стоимость работ. Пусть наряды в каждом цехе ежедневно нумеруются с единицы.

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

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

Избыточная информация - вычисляемый атрибут: «О бщая стоимость работ», которая определяется как сумма произведений стоимости выполнения операции на количество операций; удаляем этот атрибут.

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

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

Проверяем неключевые атрибуты сущности "Выполняемая операция" на зависимость от первичного ключа: наименование и цена зависят лишь от кода операции. Выделяем их в родительскую сущность "Операция" с первичным ключом код операции.