Процесс нормализации – приведение структуры базы данных в соответст-
вие с некоторым набором формальных правил.
Сущности и атрибуты, выявленные в процессе моделирования предметной
области, могут быть преобразованы в таблицы (отношения) и связи различны-
ми способами. Требуется выявить способы, наиболее адекватные реляционной
модели. Нужно убедиться, что созданная реляционная модель не порождает
противоречий в данных.
Нормализация позволяет устранить недостатки в реляционной структуре
данных и устранить аномалии проектирования. Нормализация особенно акту-
альна для больших проектов, содержащих множество сущностей с большим
числом взаимосвязей.
Для проверки правильности разработанной структуры применяют так назы-
ваемые нормальные формы – правила, которым должны отвечать отношения
(таблицы).
Нормальные формы пронумерованы и имеют вложенную взаимосвязь.
Это означает, что, если отношение соответствует некоторой нормальной
форме, оно также соответствует нормальным формам с меньшими номерами.
Первая нормальная форма (1НФ). Таблица соответствует 1НФ, если в
ней отсутствуют повторяющиеся группы.
Повторяющаяся группа – столбец, имеющий несколько значений в каждой
строке. Повторяющиеся группы в реляционной модели соответствуют много-
значным атрибутам в модели «сущность-связь». Пример многозначного ат-
рибута рассматривался выше. Решение проблемы – создание новой таблицы
(сущности) для хранения экземпляров из повторяющейся группы.
Вторая нормальная форма (2НФ). Таблица соответствует 2НФ, если она
соответствует 1НФ и все атрибуты, не входящие в первичный ключ, связаны с
ним полной функциональной зависимостью.
Атрибут B функционально зависит от атрибута A той же таблицы, если в
любой заданный момент времени для каждого из различных значений поля А
обязательно существует только одно из различных значений поля В (иначе го-
воря, если известно A, можно однозначно установить B).
Пример 2.6. Наличие функциональной зависимости. Пусть имеется сле-
дующая таблица:
Персона(Номер, Фамилия, Имя, Отчество, ДатаРождения)
Очевидно, что существует функциональная зависимость атрибутов:
Номер Фамилия, Имя, Отчество, ДатаРождения
Полная функциональная зависимость: все атрибуты зависят от составно-
го ключа и не зависят ни от какой его части.
Пример 2.7. Нарушение условия 2НФ. Дана таблица:
Кафедра(КодИнститута, КодКафедры, Название, Телефон, Адрес)
Здесь составной ключ - «КодИнститута, КодКафедры» (поле «КодКафед-
ры» идентифицирует кафедру внутри института).
Имеет место функциональная зависимость:
КодИнститута, КодКафедры
Название, Телефон, Адрес
Для каждой кафедры указывается адрес. Однако, скорее всего, адрес на са-
мом деле зависит только от кода института (т.е. от части ключа).
Для исправления ситуации адрес должен стать атрибутом института. Если
же институт имеет несколько площадок (корпусов), у каждой из которых соб-
ственный адрес, можно ввести новую сущность (таблицу) «Корпус» и для каж-
дой кафедры указывать корпус, в котором она размещается.
Третья нормальная форма (3НФ). Таблица соответствует 3НФ, если она
соответствует 2НФ и не существует транзитивных зависимостей.
Если A B и B C, то A C (C зависит от A транзитивно).
Пример 2.8. Нарушение условий 3НФ.
Кафедра(КодКафедры, Название, Телефон, Корпус, Адрес)
В отличие от примера 2.7, первичный ключ состоит только из одного атри-
бута. Следовательно, все неключевые атрибуты связаны с ним полной функ-
циональной зависимостью (условие 2NF соблюдено). Однако здесь адрес также
не на своем месте, как и в предыдущем случае. Можно выделить две зависимо-
сти:
КодКафедры Название, Телефон, Корпус
Корпус Адрес
Адрес определяется корпусом, в котором размещается кафедра. Следова-
тельно, имеет место транзитивная зависимость:
КодКафедры Корпус Адрес
