Модель данных PowerDesigner

В пакете используется двухуровневая модель данных:

1. Концептуальная модель данных (CDM) представляет собой формализованное представление общей структуры данных информационной системы без привязки к конкретной реализации на базе СУБД. Модель строиться в виде графической схемы, называемой диаграммой "сущность-связь". Как правило, при работе на концептуальном уровне системных аналитик создает абстрактную схему данных; выделяет сущности из предметной области; устанавливает связи между ними; задает бизнес-правила работы с данными. Для построения концептуальной модели в PowerDesigner используется нотации IE (Information Engineering) и Merise.

2. Физическая модель данных (PDM) соответствует реализации концептуальной модели на конкретной платформе (СУБД). Работая на физическом уровне, администратор БД или программист задает типы данных; проводит денормализацию; создает индексы и триггера на SQL-диалекте выбранной СУБД. Физическая модель имеет однозначное отображение в DDL-скрипт (набор инструкций на SQL). Графическая интерпретация модели может быть представлена в нотациях Relational (стрелка связи указывает на первичной ключ родительской таблицы), CODASYL (стрелка указывает на внешний ключ дочерней таблицы) и IE (аналогично CDM).

Как уже было отмечено выше, двухуровневая модель данных с возможностью прямого и обратного инжиниринга, а так же слияния моделей (merge) позволяет вести итерационную разработку структуры данных. К примеру, системный аналитик формирует концептуальную модель (CDM), которая преобразуется в физическую (PDM). Последняя дорабатывается программистом, отлаживается на СУБД. Затем проводится обратный инжиниринг для обновления CDM. Системный аналитик продолжает доработку модели на следующей итерации…

Основы проектирования реляционной БД достаточно хорошо описаны в литературе (например, в учебном курсе С. Д. Кузнецева [3]), поэтому в этом обзоре дополним несколько слов о наследовании.

Наследование

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

Нотация IE поддерживает только одинарное наследование (то есть одна базовая сущность-родитель передает атрибуты дочерним сущностям), в то время как IDEF1X допускает так же и множественное наследование (то есть когда дочерняя сущность наследует атрибуты нескольких родителей).

PowerDesigner поддерживает одинарное наследование двух типов:

1. Обычное наследование, когда одной записи базовой сущности могут соответствовать наборы атрибутов всех дочерних сущностей (рис. 9);

2. Исключающие наследование (mutually exclusive children), когда только одна дочерняя запись связана с записью базовой сущности (рис. 10).

Рис. 9. Обычное наследование (а-CDM, б-PDM)

Рис. 10. Исключающие наследование (а-CDM, б-PDM)

Физическая реализация этих двух типов наследования может выглядеть по-разному (несколько таблиц, связанных отношением "один-к-одному" или одна таблица, содержащая атрибуты базовой и дочерней сущностей).

Настройка параметров наследования в PowerDesigner производится на концептуальном уровне (рис. 11).

Рис. 11. Диалог настройки наследования

Заключение

Завершая обзор, отметим сильные и слабые стороны объектно-реляционной модели.

Рассмотренный подход наследует все преимущества реляционной модели, дополняя их совместимостью с приложениями объектно-ориентированной архитектуры:

• Высокий уровень производительности и масштабируемости позволяет использовать модель в сложных системах с большим потоком транзакций (банковская сфера, электронная коммерция). Такой уровень пока не доступен в объектно-ориентированных СУБД (в частности, в XML-СУБД);

• Сохраняется преемственность по отношению к традиционным СУБД.

Среди недостатков модели можно выделить следующие:

• Структура класса жестко привязана к структуре таблицы (Сложно сохранять в базе данных объекты с динамической структурой, так как программист фиксирует отображение класса в таблицу на стадии проектирования. Так, затруднена работа с документами XML произвольной схемы);

• Отсутствует полноценная реализация объектно-ориентированной среды. (В частности, невозможно использовать объектно-ориентированный язык запросов).

Впрочем, перечисленные недостатки часто не актуальны для реальных приложений.