поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность;
установить идентифицирующую связь от прежней сущности к новой (рис. 2.51).
![]()
Рис. 2.51. Сущность "Проект", приведенная ко второй нормальной форме
Вторая нормальная форма позволяет избежать следующих аномалий при выполнении операций:
Обновление (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). Время выполнения запроса с объединением может во много. раз превосходить время выполнения запроса к одной таблице, другими словами, в приведенном примере общая производительность ИС в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.
В отличие от процесса нормализации денормализация не может быть представлена в виде четко сформулированных правил. К сожалению, в каждом конкретном случае приходится искать конкретные решения, которые используют специфику ИС и предметной области и не могут быть тиражированы.
Примером денормализации могут служить производные атрибуты, которые являются нарушением первой нормальной формы (см. 2.2.2). Другой пример денормализации приведен на рис. 2.54.
![]()
Рис. 2.54. Пример денормализации
Слева данные находятся в третьей нормальной форме, но для получения из БД информации о сотруднике, включая его оклад, приходится обращаться к таблицам Должность и Сотрудник. Если в таблицу Сотрудник добавить колонку Оклад (рис. 2.54, справа), то тогда при выборке информации о сотруднике достаточно обратиться только к таблице Сотрудник (исключается объединение). При этом нарушается третья нормальная форма и возникают аномалии, в том числе аномалии при обновлении (если оклад соответствующих должности меняется, необходимо менять несколько записей по числу сотрудников на одной должности). Для решения проблемы можно делать выборку только из таблицы Сотрудник, а обновлять значение оклада только в таблице Должность. Но при этом возникает противоречие между старым значением оклада, хранящимся в таблице Сотрудник, и новыми данными, хранящимися в таблице Должность. Чтобы избежать противоречия, можно создать утилиту (процедуру сервера), которая будет запускаться во время минимальной загрузки сервера, например ночью, и выравнивать значения колонок. Если при выборке должности всегда необходимо самое свежее значение, то такое решение неприемлемо. Если задача позволяет подождать до начала следующего дня после редактирования справочника Должность, то такое решение вполне допустимо.
Заметим, что приведенный пример следует воспринимать исключительно как иллюстрацию, а не как руководство к действию.
