Таблица базы данных Oracle считается находящейся в третьей нормальной форме тогда, когда она уже находится во второй нормальной форме и когда в ней каждый не входящий в состав ключа атрибут является полностью и непосредственно зависимым от первичного ключа. Для приведения таблицы к третьей нормальной форме требуется исключать из нее столбцы, которые не зависят от ключа. Любой атрибут, который не вносит никакого вклада в описание ключа, должен переноситься в отдельную таблицу.
Таблица сотрудников (приводившаяся в этом посте - таблица 1) удовлетворяет требованиям первой нормальной формы, поскольку не содержит никаких повторяющихся групп. Она также удовлетворяет и требованиям второй нормальной формы (2NF), поскольку не имеет составного ключа. Роль первичного ключа в ней, однако, выполняет столбец номера сотрудника (Employee Number), а, как видно, столбцы названия (Department Name) и расположения отдела (Department Location) от него никак не зависят — они зависят от значений в столбце номера отдела (Department Number). Поэтому для приведения этой таблицы к третьей нормальной форме нужно перенести из нее все атрибуты отделов в отдельную таблицу. Эту новую таблицу можно назвать таблицей отделов (Departments) и сделать для нее первичным ключом столбец номера отдела (Department Number).
Причина для разбиения таблицы сотрудников на две отдельных таблицы вполне очевидна: это позволит избежать вероятности возникновения аномалий удаления и обновления. Предположим, что в организации появился новый отдел, для которого пока не было нанято ни одного сотрудника. Текущая модель не позволит внести запись об этом отделе в таблицу сотрудников. В табл. 1 показано, как в рассматриваемом примере должны выглядеть таблицы в третьей нормальной форме.
Таблица 1. Таблицы в третьей нормальной форме
| Таблица сотрудников (Employees Table) | Таблица отделов (Departments Table) | Таблица навыков (Skills Table) | Таблица навыков сотрудника Employee Skills Table) |
| Номер сотрудника (Employee Number) | Номер отдела (Department Number) | Идентификатор навыка (Skill ID) | Номер сотрудника (Employee Number) |
| Имя сотрудника (Employee Name) | Название отдела (Department Name) | Наименование навыка (Skill Name) | Идентификатор навыка (Skill ID) |
| Номер отдела (Department Number) | Расположение отдела (Department Location) | Уровень владения навыком (Skill Level) |
Если вся изложенная выше информация вначале покажется немного запутанной, не стоит сдаваться. Ниже приведено утверждение, представляющее собой более легкий способ запомнить и понять весь процесс приведения связи к третьей нормальной форме:
Связь считается находящейся в третьей нормальной форме, если все не входящие в состав ключа атрибуты полностью зависят от первичного ключа, целого первичного ключа и от ничего кроме первичного ключа.
Хотя существуют и более совершенные формы нормализации, повсеместно принято считать, что нормализация до третьей формы подходит для удовлетворения большинства производственных потребностей. Для полноты изложения материала, однако, в следующих заметках я все равно приведу краткое описание остальных популярных нормальных форм.
