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

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

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

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

Примером денормализации могут служить производные атрибуты, которые являются нарушением первой нормальной формы (см. 2.2.2). Другой пример денормализации приведен на рис. 2.54.

Рис. 2.54. Пример денормализации

Слева данные находятся в третьей нормальной форме, но для получения из БД информации о сотруднике, включая его оклад, приходится обра­щаться к таблицам Должность и Сотрудник. Если в таблицу Сотрудник добавить колонку Оклад (рис. 2.54, справа), то тогда при выборке инфор­мации о сотруднике достаточно обратиться только к таблице Сотрудник (исключается объединение). При этом нарушается третья нормальная фор­ма и возникают аномалии, в том числе аномалии при обновлении (если оклад соответствующих должности меняется, необходимо менять несколько записей по числу сотрудников на одной должности). Для решения пробле­мы можно делать выборку только из таблицы Сотрудник, а обновлять зна­чение оклада только в таблице Должность. Но при этом возникает проти­воречие между старым значением оклада, хранящимся в таблице Сотруд­ник, и новыми данными, хранящимися в таблице Должность. Чтобы избе­жать противоречия, можно создать утилиту (процедуру сервера), которая будет запускаться во время минимальной загрузки сервера, например но- 1 чью, и выравнивать значения колонок. Если при выборке должности всегда необходимо самое свежее значение, то такое решение неприемлемо. Если задача позволяет подождать до начала следующего дня после редактирова­ния справочника Должность, то такое решение вполне допустимо.

Заметим, что приведенный пример следует воспринимать исключительно как иллюстрацию, а не как руководство к действию.

Еще один пример денормализации данных будет рассмотрен в подразделе 2.2.8, посвященном проектированию хранилищ данных.

Поддержка денормализации в ER-win. Денормализация, как правило, проводится на уровне физической модели. ER-win позволяет сохранить на уровне логической модели нормализованную структуру, при этом постро­ить на уровне физической модели структуру (возможно, денормализованную), которая обеспечивает лучшую производительность, используя осо­бенности конкретной СУБД и бизнес-правил предметной области.

ER-win имеет следующую функциональность для поддержки денормализации:

Сущности, атрибуты, ключи и домены можно создавать только на уров­не логической модели, включив в соответствующих редакторах опцию Logical Only (см., например, рис. 2.10 и 2.15). Такие объекты не будут ото­бражаться на уровне физической модели и не будут создаваться при гене­рации БД.

Таблицы, колонки, домены и индексы можно создавать только на уров­не физической модели (опция Physical Only, см. 2.3). Например, на уровне только физической модели может быть создана колонка Оклад таблицы Сотрудник, см. рис. 2.54.

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