Рас. 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) в физической модели создается новая таблица и структура данных может быть дополнена только на уровне физической модели.

Домены

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

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

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

Для создания домена в логической модели служит диалог Domain Dictionary Editor, (рис. 2.55). Его можно вызвать из меню Edit/Domain Dictionary по кнопке, расположенной в верхней левой части закладки General диалога Attribute Editor (см. рис. 2.14). Для создания нового домена ^в Диалоге Domain Dictionary Editor следует:

Рис. 2.SS. Диалог Domain Dictionary Editor

- щелкнутьно кнопке New. Появляется диалог New Domain (рис. 2.56);

- выбрать родительский домен из списка Domain Parent. Новый домен можно создать на основе уже созданного пользователем домена либо на основе изначально существующего. По умолчанию ER-win имеет четыре предопределенных домена (String, Number, Blob, Datetime). Новый домен наследует все свойства родительского домена. Эти свойства в дальнейшем можно переопределить;

- набрать имя домена в поле Logical Name. Можно также указать имя домена на физическом уровне в поле Physical Name. Если физическое имя не указано, по умолчанию оно принимает значение логического имени;

- щелкнуть по кнопке ОК.

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

Рис. 2.56. Диалог New Domain

Каждый домен может быть описан в закладке Definition, снабжен ком­ментарием в закладке Note или свойством, определенным пользователем в закладке UDP.

Рис 2.57. Создание нового атрибута с помощью диалога Independent Attribute Browser

ER-win имеет специальный инструмент, который значительно облегчает создание новых

атрибутов в модели, используя описание доменов, - Independent Attribute Browser. Этот диалог вызывается (и скрывается) по горячему ключу CTRL+B. С его помощью можно выбрать в списке домен и по методу drag& drop перенести его в какую-либо сущность. В ней будет, создан новый атрибут с именем, которое следует задать в окне Name Inherited by Attribite диалога Domain Dictionary Editor. Если значение поля не задано, но умолчанию принимается имя домена. На рис. 2.57 для домена " Возраст" значение этого поля было " Атрибут Возраст". В дальнейшем в случае необходимости имя атрибута можно изменить.

Рис. 2.58. Диалог Domain Dictionary Editor на физическом уровне

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

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

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

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

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

Visual Basic - PowerBuilder. Задание специальных свойств домена для кодогенерации клиентского приложения.

Рис. 2.59. Закладка General диалога Domain Dictionary Editor

Домены могут быть использованы при генерации схемы БД для созда­ния типов, определяемых пользователем для тех СУБД, которые поддержи­вают такие конструкции (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.

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