Обновление (UPDATE). Имеет место дублирование данных о сотруднике, если он руководит несколькими проектами. Если данные о сотруднике изменяются, необходимо менять несколько записей (по числу ведомых проектов).

Вставка (INSERT). Невозможно ввести данные о сотруднике, если он в данный момент не руководит проектами.

Удаление (DELETE). Если сотрудник временно прекращает руководство проектами, данные о нем теряются.

На рис. 2.51 показана сущность Проект, приведенная ко второй нормальной форме.

Третья нормальная форма (3NF). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой неключевой атрибут не зависит от другого неключевого атрибута (не должно быть взаимозависимости между неключевыми атрибутами).

На рис. 2.49 сущность Сотрудник находится во второй нормальной форме (имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части ключа), но неключевой атрибут Оклад зависит от другого неключевого атрибута – Должности.

Для приведения сущности ко второй нормальной форме следует:

создать новую сущность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

использовать атрибут(ы), определяющий эту зависимость, в качестве первичного ключа новой сущности;

установить неидентифицирующую связь от новой сущности к старой (рис. 2.52).

Рис. 2.52. Сущность "Сотрудник", приведенная к третьей нормальной форме

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

Обновление (UPDATE). Имеет место дублирование данных об окладе, если должность занимают несколько сотрудников. Если оклад соответствующих должности меняется, необходимо менять несколько записей (по числу сотрудников на одной должности).

Вставка (INSERT). Невозможно ввести данные об окладе, соответствующем должности, если в данный момент нет сотрудника, занимающего эту должность.

Удаление (DELETE). В случае удаления из таблицы сотрудника, занимающего уникальную должность, данные об окладе теряются.

Четвертая нормальная форма (4NF) требует отсутствия многозначных зависимостей между атрибутами.

В примере на рис. 2.53 (слева) преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет и Группа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.

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

Рис. 2.53. Иллюстрация четвертой нормальной формы

Поддержка нормализации в ERwin. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила "один факт - в одном месте". Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

Денормализация. В результате нормализации все взаимосвязи данных становятся правильно определены, исключаются аномалии при оперировании с данными, модель данных становится легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Рассмотрим примеры на рис. 2.47 и 2.52. Для получения полной информации о сотруднике из ненормализованной структуры данных достаточно обратиться к одной таблице (см. рис. 2.47). После приведения структуры данных к третьей нормальной форме (рис. 2.52) информация о сотруднике содержится уже в четырех таблицах. Хотя общее количество строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу БД необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много. раз превосходить время выполнения запроса к одной таблице, другими словами, в приведенном примере общая производительность ИС в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.