![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Рас. 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 для домена " Возраст" заданы соответственно правило валидации " Проверка_возраста" и значение поумолчанию " Возраст по умолчанию"). Для вызова диалогов редактирование правил валидации и значений по умолчанию служат кнопки Рассмотрим функции других закладок диалога 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. Для создания типов, определяемых пользователем, необходимо включить соответствующую опцию. При генерации схемы БД колонки, определенные соответствующем домене, будут иметь тип, определяемый пользователем.
|