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

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

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

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

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

Создание физического уровня модели

На стадии реализациисоздаются физическая модель. Существует два уровня физических моделей: трансформационная модель (TransformationModel) и модель СУБД.

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

Процесс генерации модели из схемы базы данных называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обратного проектирования имеющейся базы данных. После того как модель создана, можно переключиться на другой сервер (модель будет конвертирована) и произвести прямое проектирование структуры базы данных для другой СУБД. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания ИС.

Трансформационная модель— это физическая модель, полученная путем преобразования логической модели по следующему принципу: сущности становятся таблицами, атрибуты становятся столбцами, а ключевые атрибуты становятся первичными ключами.

Трансформационная модель позволяет проектировщикам и администраторам БД представлять, какие объекты БД хранятся в словаре данных, и проверить, насколько физическая модель данных удовлетворяет требованиям информационной системы. Фактически из трансформационной модели автоматически можно получить модель СУБД, которая является точным отображением системного каталога СУБД.

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

Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:

• физическая модель данных должна соответствовать требованиям, предъявляемым к проектируемой системе;

• выбор определенной физической модели должен быть аргументирован;

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

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

Физический уровень модели зависит от выбранного сервера. Для выбора СУБД служит редактор TargetServer(менюDatabase/ChooseDatabaseдоступно только на физическом уровне).

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

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

Последним шагом на этапе создания физической модели данных является написание триггеров и хранимых процедур. Этот шаг является необязательным, т. к. в ERwinсуществуют библиотеки готовых шаблонов триггеров и хранимых процедур. Но при желании разработчик может вносить в них свои изменения.