Физическая и логическая модели данных

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

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

Документирование модели. Многие СУБД имеют ограничение на име-
нование объектов (например, ограничение на длину имени таблицы или за-

прет использований специальных символов - пробела и т. п.). Зачастую раз-
работчики ИС имеют дело с нелокализованными версиями СУБД. Это озна-
чает, что объекты базы данных могут называться короткими словами, толь-
ко латинскими символами и без использования специальных символов
(т. е. нельзя назвать таблицу предложением - только одним словом). Кроме
того, проектировщики баз данных нередко злоупотребляют "техническими"
наименованиями, в результате таблица и колонки получают наименования
типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру
могут понять только специалисты (а чаще всего только авторы модели), ее
невозможно обсуждать с экспертами предметной области. Разделение моде-
ли на логический и физический уровни позволяет решить эту проблему.
На физическом уровне объекты базы данных могут называться так, как того
требуют ограничения СУБД. На логическом уровне можно этим объектам
дать синонимы - имена более понятные неспециалистам, в том числе на ки-
риллице и с использованием специальных символов. Например, таблице
CUST_A12 может соответствовать сущность Постоянный клиент. Такое
соответствие позволяет лучше задокументировать модель и дает возмож-
ность обсуждать структуру данных с экспертами предметной области.
Масштабирование. ERwin позволяет создавать модели трех типов:

• модель, имеющую только логический уровень;

• модель, имеющую только физический уровень;

• модель, имеющую как логический уровень, так и физический уровень.

Создание модели данных, как правило, начинается с создания логиче-
ского уровня. После описания логического уровня проектировщик может
выбрать необходимую СУБД. В модели, имеющей оба уровня (логический
и физический), ERwin автоматически создаст соответствующую физиче-
скую модель. Это означает, что каждому объекту логического уровня соот-
ветствует объект физического, например каждой сущности соответствует
таблица. Модель, имеющая только логический уровень, может быть син-
хронизирована с несколькими моделями, имеющими только физический
уровень (рис. 2. 1. 1). Это позволяет эффективно разрабатывать гетерогенные
2. На основе одной логической модели можно создавать несколько физи-
ческих, соответствующих СУБД разных производителей (например, Oracle,
Informix, MS SQLServer, Sybase и др.). Синхронизация моделей будет рас-
смотрена в последующих главах.

При создании новой модели в диалоге Create Model (рис. 2. 1. 2) можно
выбрать тип новой модели.

На основе физической модели ERwin может сгенерировать системный ката-
лог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым
проектированием (Forward Engineering). Тем самым достигается масштабируе-
мость - создав одну логическую модель данных, можно сгенерировать физиче-
ские модели под любую поддерживаемую ERwin СУБД. С другой стороны,
ERwin способен по содержимому системного каталога или SQL-скрипту воссоз-
дать физическую и логическую модель данных (Reverse Engineering). На основе
полученной логической модели данных можно сгенерировать физическую мо-
дель для другой СУБД и затем сгенерировать ее системный каталог. Следова-
тельно, ERwin позволяет решить задачу по переносу структуры данных с одного
сервера на другой. Например, можно перенести структуру данных с Oracle
на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную
СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-
серверной ИС. Заметим, однако, что формальный перенос структуры "плоских"
таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь

выгоды от перехода на клиент-серверную технологию, структуру данных следу-
ет модифицировать. Процессы прямого и обратного проектирования будут рас-
смотрены ниже.

Для переключения между логической и фи-
зической моделью данных служит список вы-
бора в стандартной панели инструментов
ERwin (рис. 2. 1. 3).

При переключении, если физической модели
еще не существует, она будет создана автома-
тически.