Денормализация

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

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

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

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

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

ночью, и выравнивать значения колонок. Если при выборке должности все-
гда необходимо самое свежее значение, то такое решение неприемлемо. Ес-
ли задача позволяет подождать до начала следующего дня после редак-
тирования справочника Должность, то такое решение вполне допустимо.

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

Еще один пример денормализации данных будет рассмотрен в гл. 6.

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

Для поддержки денормализации ERwin позволяет создавать сущности,
атрибуты, ключи и домены только на уровне логической модели, включив
в соответствующих редакторах опцию Logical Only (см., например,
рис. 2. 2. 1 и 2. 2. 7). Такие объекты не будут отображаться на уровне физиче-
ской модели и не будут создаваться при генерации базы данных. С другой
стороны, таблицы, колонки, домены и индексы можно создавать только
на уровне физической модели (опция Physical Only).

Кроме того, ERwin имеет набор инструментов, сведенных в панель тран-
сформации (табл. 2. 2. 2), который может быть использован для денормали-
зации модели.

Таблица 2. 2. 2. Панель трансформации таблиц (Transforms)

Рассмотрим каждую кнопку панели трансформации таблиц.
Преобразование связи "многие ко многим" было рассмотрено в гл. 2. 2. 3.
Замена иерархии наследования идентифицирующими связями. Причи-
ной преобразований иерархии наследования может быть желание упростить

модель или увеличить производительность ИС. В любом случае такие пре-
образования должны проводиться только после анализа производительно-
сти выполнения SQL-запросов.

Для преобразования следует щелкнуть по символу иерархии и затем
по кнопке замены иерархии на палитре инструментов. Возникает диалог Super-
type Subtype Identifying Wizard, который предлагает 4 шага для преобразования
связи. Для перехода к следующему шагу надо щелкнуть по кнопке Next (Далее).
На втором шаге следует задать имя преобразования (рис. 2. 2. 52).

На рис. 2. 2. 53 показана иерархия категории до и после преобразования.

Все преобразования показываются во вкладке Model окна Model Explorer
(рис. 2. 2. 54).

Преобразование можно удалить из списка. Щелкнув правой кнопкой
по имени преобразования (на рис. 2. 2. 54 - "Преобразование категории Со-
трудник"), следует выбрать в каскадном меню Delete/Reverse Transform.
В результате преобразование "откатывается" - две идентифицирующие свя-
зи превращаются в категорию. Если выбрать Delete/Resolve Transform,
то имя преобразования исчезает из списка, но идентифицирующие связи ос-
таются, т. е. преобразование становится необратимым.

Миграция первичного ключа и неключевых атрибутов в иерархии
наследования от потомков к предку. Это преобразование также применя-
ется для иерархии категорий. Для преобразования следует щелкнуть по сим-
волу иерархии и затем по кнопке миграции первичного ключа и неключе-
вых атрибутов в иерархии наследования от потомков к предку на палитре
инструментов. В результате преобразования (рис. 2. 2. 55, справа) потомки
Удаляются, а все их атрибуты мигрируют в предка.

Миграция первичного ключа и неключевых атрибутов в иерархии
наследования от предка к потомкам. Для преобразования следует щелк-
нуть по символу иерархии и затем по кнопке миграции первичного ключа
и неключевых атрибутов в иерархии наследования от предка к потомкам
на палитре инструментов. В результате преобразования (рис. 2. 2. 56, справа)
предок удаляется, а все его атрибуты мигрируют в каждого из потомков.

Домены

Домен можно определить как абстрактный атрибут, на основе которого
можно создавать обычные атрибуты, при этом создаваемые атрибуты будут
иметь все свойства домена-прародителя. Каждый атрибут может быть опре-
делен только на одном домене, но на каждом домене может быть определе-
но множество атрибутов. В понятие домена входит не только тип данных,
но и область значений данных. Например, можно определить домен "Воз-
раст" как положительное целое число и определить атрибут Возраст со-
трудника как принадлежащий этому домену.

В ERwin домен может быть определен только один раз и использоваться
как в логической, так и в физической модели.

Домен может быть создан на основе другого домена и наследовать все
свойства домена-прародителя. По умолчанию ERwin имеет 4 предопреде-
ленных домена: String, Number, Blob, Datetime.

Домены позволяют облегчить работу с данными как разработчикам
на этапе проектирования, так и администраторам баз данных на этапе экс-
плуатации системы. На логическом уровне домены можно описать без кон-
кретных физических свойств. На физическом уровне они автоматически по-
лучают специфические свойства, которые можно изменить вручную. Так,
домен "Возраст" может иметь на логическом уровне тип Number, на физи-
ческом уровне колонкам домена будет присвоен тип INTEGER.

Создать домен можно во вкладке Domains окна Model Explorer
(см. рис. 2. 1. 13).

Для создания нового домена во вкладке Domains следует выбрать роди-
тельский домен из списка Domains (см. рис. 2. 1. 13), щелкнуть по нему пра-
вой кнопкой мыши и выбрать пункт Properties. Появляется диалог Domain
Dictionary (рис. 2. 2. 57), где следует щелкнуть по кнопке New. В появившем-
ся диалоге New Domain (рис. 2. 2. 58) следует набрать имя домена в поле
Logical Name. Можно также указать имя домена на физическом уровне
в поле Physical Name, после чего щелкнуть по кнопке ОК. Если физическое
имя не указано, по умолчанию оно принимает значение логического имени.

Новый домен можно создать на основе уже созданного пользователем
домена либо на основе изначально существующего. Новый домен наследует
все свойства родительского домена. Эти свойства в дальнейшем можно пе-
реопределить. В случае изменения свойств родительского домена (напри-
мер, имени порождаемого атрибута, Name Inherited by Attribite) это свойство
автоматически изменяется у дочернего домена и в порожденных атрибутах.

В диалоге Domain Dictionary Editor можно связать домен и иконкой,
с которой он будет отображаться в списке доменов (Domain Icon), и икон-
кой, с которой атрибут, определенный на домене, будет отображаться
в модели (Icon Inherited by Attribite).

Каждый домен может быть описан во вкладке Definition, снабжен ком-
ментарием во вкладке Note или свойством, определенным пользователем
во вкладке UDP. Во вкладке Datatype может быть задан абстрактный тип
данных домена, правила валидации и значение по умолчанию. Соответствие

абстрактных типов данных и типов данных конкретного сервера будет рас-
смотрено ниже.

Для создания атрибута на основе домена необходимо выбрать домен
в списке окна Model Explorer и по методу drag & drop перенести его в ка-
кую-либо сущность (рис. 2. 2. 59). В ней будет создан новый атрибут с име-
нем, которое было задано в поле Name Inherited by Attribute диалога Domain
Dictionary. Если значение поля не задано, по умолчанию принимается имя
домена. В дальнейшем в случае необходимости имя атрибута можно изме-
нить. При задании имени атрибута в поле Name Inherited by Attribute можно
использовать макросы (подробнее макросы ERwin будут рассмотрены
в гл. 2. 3). Например, если для домена Адрес задано имя %EntityName()%Att-
Domain, то при создании атрибута в сущности Сотрудник он получит имя
СотрудникАдрес.

На физическом уровне диалог Domain Dictionary Editor позволяет редак-
тировать физические свойства домена. На рис. 2. 2. 60 показана вкладка
ORACLE. Имя этой вкладки зависит от выбранного сервера базы данных.
На ней можно задать конкретный тип данных, соответствующих домену,
правила присвоения NULL-значений, правила валидации (правила проверки
допустимых значений) и задания значения по умолчанию. Правила валида-
ции и значения по умолчанию должны быть предварительно описаны
и именованы (создание правил валидации и значений по умолчанию будет
описано в гл. 2. 3). Для вызова диалогов редактирования правил валидации
и значений по умолчанию служат кнопки справа от соответствующего
списка выбора (Valid и Default).

Рассмотрим функции других вкладок диалога Domain Dictionary Editor.

General. Задание родительского домена (Domain Parent) и имени, при-
сваиваемого колонке при ее создании с помощью Independent Column
Browser. С помощью опции Physical Only домен можно определить только
на уровне физической модели.

Comment. Внесение комментария к атрибуту.

UDP. Свойства, определяемые пользователем.

Домены могут быть использованы при генерации схемы базы данных
для создания типов, определяемых пользователем для тех СУБД, которые
поддерживают такие конструкции (DB2, Rdb, Interbase, SQL Anywhere, SQL
Server и SYBASE). Типы, определяемые пользователем, представляют собой
синонимы существующих в базе данных типов, создаваемых для удобства
работы с данными.

При выборе соответствующего сервера на вкладке General появляется
флажок:

• Distinct Types - для DB2/CS и DB2/UDB;

• Domains - для Rdb и Interbase;

• User Datatypes - для SQL Anywhere, SQL Server и SYBASE.

Для создания типов, определяемых пользователем, необходимо вклю-
чить соответствующую опцию. При генерации схемы базы данных колонки,
определенные на соответствующем домене, будут иметь тип, определяемый
пользователем.