Домены

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

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

мена: String, Number, Blob, Datetime.

Создать домен можно в закладке Model навигатора модели Model Explorer. Для этого следует выбрать родительский домен из списка Domains, щелкнуть по нему правой кнопкой мышки и выбрать пункт Properties. В появившемся диалоге Domain Dictionary в закладке General (рис. 68) щелкнуть по кнопке New.

Рис. 68. Диалог Domain Dictionary.

69

В появившемся диалоге New Domain (рис. 69) требуется указать имя домена в поле Logical Name. Можно указать имя домена на физическом уровне в поле Physical Name, после чего нажать ОК. Если не указывать физическое имя, то по умолчанию оно скопируется из логического имени.

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

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

уатрибута, определенного на домене (список Icon Inherited by Attribute на рис. 68). В строке ввода Name Inherited by Attribute можно задать правило формирования имен атрибутов, порождаемых из домена. В правиле используются макросы ERwin DM.

Взакладке Datatype можно указать абстрактный тип данных домена и обязательность значений (опция Not Nulls). Соответствие абстрактных типов данных и типов данных конкретного сервера можно настроить в диа-

логах Model Datatype Options и Datatype Standards Editor (меню

Tools/Datatypes). В закладке Constraint определяют правила валидации – правила проверки допустимых значений (раздел Validation Constraint) и значение по умолчанию (раздел Default). Правила валидации и значения по умолчанию должны быть предварительно описаны и именованы. Каждому домену можно дать описание в закладке Definition, ввести комментарий в закладке Note, означить пользовательские свойства в закладке UDP.

Для создания атрибута на основе домена следует выбрать домен в списке доменов окна навигатора Model Explorer и «перетащить» его в сущ-

70

ность на диаграмме (см. рис. 12). В результате в сущности создастся новый атрибут, причем имя атрибута будет сформировано согласно правилу, за-

данному в поле Name Inherited by Attribute диалога Domain Dictionary.

Например, если в правило состоит из макроса %AttDomain, то имя атрибута будет совпадать с именем домена-родителя, а если правило имеет вид %AttDomain %OwnerEntity, то имя порождаемого из домена атрибута будет составлено из имени домена и имени сущности, в которую «перемещен» домен, разделенных пробелом. Так на рис. 12 домен с именем ИД «перетащили» в сущность Тест, в результате чего автоматически создался атрибут с именем ИД тест.

На физическом уровне диалог Domain Dictionary позволяет редактировать физические свойства домена. Для переключения на физический уровень следует в верхней части диалога в списке Edit Mode (рис. 68) выбрать Physical. На физическом уровне диалог содержит другой набор закладок: General, SQL Server (или другое имя в зависимости от выбранного сервера базы данных), Constraint, Comment, UDP, - но по смыслу они похожи на соответствующие закладки логического уровня.

Нормализация и денормализация

Нормализация – процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. В результате нормализации должна быть создана структура данных, в которой информация о каждом факте хранится только в одном месте. Нормализация позволяет значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известно 6 нормальных форм (Для углубленного изучения нормализации следуют обратиться к книге К. Дж. Дейта «Введение в системы баз данных»). На практике ограничиваются приведением данных к третьей нормальной форме (полная атрибутивная модель). На рис. 70 приведен пример ненормализованной сущности, а на рис. 71 – соответствующая структура данных, приведенная к третьей нормальной форме.

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

71

Рис. 70. Пример ненормализованной сущности.

Рис. 71. Результат нормализации сущности «Сотрудник» (3НФ).

Часто нормализация не ведет к повышению производительности информационной системы в целом. Например, информация о сотрудниках (рис. 70) в результате приведения к третьей нормальной норме была рассредоточена в четырех связанных таблицах (рис. 71). Хотя общее число строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу базы данных необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много раз превосходить время выполнения запроса к одной таблице. В приведенном примере общая производительность информационной системы в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм, чтобы использовать возможности конкретного сервера или информационной системы в целом, т.е. проводить денормализацию. В каждом конкретном случае приходится искать конкретные решения по денормализации, учитывающие специфику информационной системы и бизнес-правила предметной области.

ERwin DM позволяет сохранить на логическом уровне нормализованную структуру, при этом построить на физическом уровне структуру (возможно, денормализованную), которая обеспечит лучшую производитель-

72