Николай Птицын,
МГТУ им. Н. Э. Баумана, каф. ИУ5

Вступление

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

• Репозиторий является средством организации совместной работы разработчиков и обеспечивает хранение версий проекта, синхронизацию обновлений, контроль целостности;
• Визуальные инструменты проектирования и анализа обеспечивает работу с диаграммами UML (модель приложения), ER (модель данных), DFD (модель потоков данных) и пр.
• Прямой инжиниринг предполагает генерацию модели более низкого уровня или генерацию программного кода из рассматриваемой модели;
• Обратный инжиниринг обеспечивает соответственно обратное преобразование из модели или программного кода в рассматриваемую модель более высокого уровня (например, из физической в концептуальную);
• Среда быстрой разработки приложений (RAD), включающая оболочку и компилятор языка 4GL, генераторы программных кодов, мастера и пр.;
• Система документирования;
• Средства тестирования.

В этом обзоре мы рассмотрим объектно-реляционную методологию, реализованную в CASE-пакете Sybase PowerDesigner. Более подробно остановимся на модели “сущность-связь”, так как, по мнению автора, компонент проектирования баз данных в PowerBuilder заслуживает особого внимания и может быть использован независимо от всего остального (не менее успешно, чем ERwin- популярный продукт Computer Associates).

Объектно-реляционная парадигма

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

Наиболее актуальной задачей является сохранение объекта (serialization) из кучи оперативной памяти (heap), доступной приложению, в базу данных с последующим восстановлением (deserialization). Объекты, которые должны “запоминаться”, будем называть постоянными (persistent).

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

Одновременно с хранением объектов желательно обеспечить выполнение запросов на выборку на основе заданного условия (значения атрибута), а так же другие манипуляции с объектами – обновление и удаление. То есть речь идет о переходе от уровня работы с записями на уровень работы с объектами.

Одним из решений этой задачи является адаптация реляционной СУБД к объектной модели. (Альтернативным подходом является полный переход на объектно-ориентированную СУБД.) Рассмотрим механизм преобразования, который, мог бы обеспечить хранение объектов в реляционной таблице и, следовательно, работу с атрибутами объекта как с полями записи
(рис. 1).

Сопоставим каждому классу ООМ реляционное отношение (таблицу) следующего вида:

• Первичный ключ генерируется базой данной и становится уникальным идентификатором сохраняемого объекта;
• Каждый атрибут класса ставиться в соотношение колонке таблицы:
• Если атрибут класса – скаляр, то атрибут реляционного отношения представляет собой внешний ключ таблицы, описывающей класс этого атрибута. Простые атрибуты (char, int, double и т.д) могут сохраняться в таблице класса сразу вместо внешнего ключа;
• Если атрибут класса – вектор (массив элементов), то имеем неатомарный атрибут отношения, что в явном виде не поддерживается реляционной моделью. Такая многозначная связь между атрибутом отношения и записями таблицы класса этого атрибута может быть установлена с помощью дополнительной таблицы, соответствующей “массиву элементов данного класса”.
• Наследование в явном виде не поддерживается в реляционной модели, но может быть реализовано следующим способами:
• Атрибуты таблицы, соответствующей базовому классу (в частности, абстрактному), могут переноситься физически в таблицы наследующих классов. Как правило, эти мигрирующие атрибуты отмечаются разработчиком сразу в концептуальной модели. Объекту финального класса будет соответствовать одна запись в таблице наследующего класса. Базовая таблица вообще не включается в окончательную структуру базы данных.
• Между базовой и наследующей таблицами может быть установлена связь 1:1. В этом случае наследуемые атрибуты хранятся в таблице, соответствующей базовому классу, а дополнительные – в таблице наследующего класса. Объекту финального класса соответствует пара записей (или большее число, в зависимости от глубины иерархии) в базовой и наследующей таблицах. Реализация механизма наследования в PowerDesigner описана ниже в разделе Модель данных PowerDesigner.

Здесь в свойствах связи Держатель Счета (Account Holder) и Адрес Держателя (Holder Address) был определен класс Holder как контейнер для классов Account и Address. В результате в атрибутах Holder появились массивы ссылок accounts и addresses. Скелет класса, который выдает кодогенератор на основе модели UML имеет следующие вид (рис. 3).

рис. 3 Генерируемый код класса Holder на языке Java

С учетом того, что все классы объектов должны “запоминаться” в базе данных, преобразуем эту ООМ в реляционную модель физического уровня. Как видно на рис. 4 ассоциативные (association/composition, в терминологии RUP – aggregation) и наследственные (generalization) связи ООМ заменяются на реляционные отношения между таблицами, устанавливаемые с помощью внешних ключей (<fk>).

рис. 4 Диаграмма “сущность связь” Держатель и Счета

Таким образом, интеграция двух моделей с помощью рассмотренного механизма приводит к возникновению понятия объектно-реляционной модели (ОРМ).

Отметим, что в таком понимании объектно-реляционная СУБД существенно отличается от объектно-ориентированной СУБД. Первая представляет собой традиционную реляционную СУБД дополненной схемой преобразования классов в таблицы (mapping layer). Это позволяет сохранять данные объектно-ориентрованного приложения в “обычной” базе данных.

Более серьезное разногласие объектно-ориентированного и реляционного подходов заключается в концепции хранения данных и программирования. Так, в ООМ используется процедурный язык программирования, ориентированный на работу со скалярными значениями, в то время как SQL представляет собой декларативный язык запросов и предназначен для работы со множествами. Эта явление принято называть потерей соответствия (impedance mismatch).

В индустрии распространенны два подхода к реализации ОРМ:

1. Проектировщик строит ООМ и разрабатывает приложение, не заботясь о том, каким образом объекты буду “запоминаться” в базе данных. Дополнительное программное обеспечение (например, Sun JavaBlend, [7]) берет на себя прозрачное преобразование:
1. классов в реляционное отношение и обратно (в процессе проектирования);
2. объектов в записи таблиц и обратно (в процессе работы приложения);
2. Состыковка объектно-ориентированной и реляционной моделей на этапе концептуального проектирования. Например, такая идеология заложена в продукте Sun EJB (Enterprise Java Beans). Забота о синхронизации структуры классов и соответствующей структуры таблиц лежит на плечах разработчика (или на его CASE-инструментах).

Подход имеет преимущества – исключается “промежуточное” программное обеспечение, выполняющие преобразования, что повышает быстродействие и гибкость приложения. Структура базы данных контролируется разработчиком, поэтому может быть адаптирована для решения каких-либо задач (например, для организации SQL-взаимодействия с другими СУБД).
Именно такой вариант объектно-реляционного проектирования мы рассмотрим подробнее в пакете Sybase PowerDesigner.

рис. 5 Уровни проектирования объектно-реляционного ПО

На схеме выделены 4 уровня приложения, на которых ведутся его разработка и тестирование:

1. Концептуальный уровень (включает ООМ и концептуальную модель данных (CDM);
2. Физический уровень (привязывается к прикладному средству разработки);
3. Уровень программного кода (исходные тексты на языке программирования);
4. Уровень выполняемого кода (готовое приложение)

Продолжение статьи

За дополнительной информацией обращайтесь в Interface Ltd.