BC/NW 2006, №2, (9) :7.3
ИНФОРМАЦИОННЫХ СИСТЕМ, ИСПОЛЬЗУЮЩИХ РЕЛЯЦИОННЫЕ БАЗЫ
ДАННЫХ И СРЕДСТВА ОБЪЕКТНО-РЕЛЯЦИОННОГО ОТОБРАЖЕНИЯ
В. А. Федин,
Ю. Ю. Фуников
(Москва,
Московский Энергетический Институт (ТУ), Россия)
Применение объектно-ориентированных (ОО) методов на
различных этапах проектирования и реализации частей информационной системы,
относящихся к РСУБД можно представить в виде следующих схем:
·
традиционная
разработка схемы реляционной БД:
A. ER → R-модель
→ DDL
·
разработка системы,
основанная на ОО-методе:
A. UML → R-модель → DDL
B. UML → ОО-язык → ORM → R-модель
→ DDL
Как видно, это применение (А) основано на простой
замене одной нотации другой. Это позволило использовать при проектировании
такие более выразительные и высокоуровневые средства как UML и обеспечило общий фундамент для всей системы (в
случае если остальные части системы используют ОО- нотацию). С другой стороны,
обработка информации, хранящейся в БД, никаких изменений не претерпела. Мы
используем все тот же SQL, а сама СУБД
ничего не знает о той семантике хранимых данных, которая присутствует в
объектно-ориентированной модели. Проблему потери семантики модели можно решать
двумя путями а) использовать ОСУБД, б) использовать средства
объектно-реляционного отображения (Object-Relational Mapping, ORM). Первые находятся вне поля зрения нашей статьи,
вторые, несмотря на то, что они являются настоящим прорывом в области
разработки приложений с использованием ОО - подхода и РСУБД, на сегодняшний
день обладают рядом архитектурных ограничений. Эти ограничения можно условно
разделить на две части. Первая часть обусловлена неоптимальным распределением
обязанностей между СУБД и клиентским приложением, обрабатывающим данные из этой
СУБД. Так, часть обязанностей СУБД, отвечающих за манипулирование данными, делегируется ORM, но только часть. Дело в том, что для выполнения
функций СУБД ОRM должны обладать данными,
хранящимися в СУБД. Вторая часть проблем связана, с одной стороны, с самим
ОО-подходом, а с другой стороны, с тем фактом, что хранилищем метаинформации о
модели у этих средств является описание классов на каком-либо
объектно-ориентированном языке. Оказалось, что, хотя сами домены являются
устойчивыми сущностями, для реализации алгоритмов часто нужно работать только с
частями объектов или с результатами произвольных запросов. Средства же ORM могут контролировать состояние домена, только если
клиент работает через ORM с этим
доменом целиком. Рассмотрение домена целиком как атомарной единицы обработки
зачастую является крайне неоптимальным и в случае сложных доменов ведет к
большим накладным расходам. Домен, как целое, может быть описан на уровне
модели, но не конкретного языка программирования. Все это приводит к
парадоксальной ситуации: мы располагаем, с одной стороны, низкоуровневым средством
представления данных и высокоуровневым декларативным механизмом их обработки
средствами РСУБД, а с другой стороны, высокоуровневым средством представления и
низкоуровневым средством манипулирования (процедурный подход какого-либо ОО –
языка) со стороны ОО – клиента.
Цель
нашей работы, во-первых, исследовать различные способы декларативной обработки
данных, описанных в виде объектно-ориентированной модели и, во-вторых,
предложить возможные варианты будущей архитектуры ORM-подобных систем. В работе мы будем полагаться на
такие средства и стандарты, как универсальный язык моделирования UML и MOF, стандарт на
средства объектно-реляционного отображения EJB 3.0, популярное средство ORM в Java – Hibernate, а также на классическую реляционную модель и ее реализации
в виде современных СУБД.
Мы займемся формализацией такого понятия как домен и
его отличиями от других объектов и артефактов ОО-проектирования. Кроме того, мы
считаем, что информацию о структуре классов и взаимосвязях между объектами этих
классов можно использовать для оптимизации многих алгоритмов работы СУБД, таких
, например, как язык запросов и механизм транзакций.
Основным отличием от других известных способов
объединения реляционной и объектной моделей данных является, по нашему мнению,
решение описать среду для обработки объектных данных, в которой объекты
представлены в “разобранном” на атрибуты и связи состояния, для которых
обеспечивается централизованное управление и контроль за целостностью данных.
Также важным элементом работы является ее ориентированность на модель (под
моделью мы понимаем абстракцию, представляющую некоторую предметную область,
описанную определенным языком). Модель является центральным разделяемым
хранилищем метаинформации о пользовательских типах. Выше мы ввели такой особый
вид классов, как домены. Домен - это
класс, описывающий данные, их структуру и допустимые значения, т.е. это
целостная единица с определенной структурой. Будем считать, что домен состоит
из набора атрибутов, описания связей с другими доменами, ограничений
целостности и произвольного количества методов, в том числе и полиморфных. При
этом связи между доменами могут быть двух основных видов – это наследование и
ассоциация. В случае наследования домен-потомок, участвующий в связи, сохраняет контракт своих родителей. Под контрактом домена мы понимаем его
набор атрибутов, ассоциативных связей и ограничений целостности. Текущим
значением домена или его состоянием мы будем называть совокупность значений
всех его атрибутов, а также совокупность состояний принадлежащих (агрегированных им) ему других доменов. Таким
образом, контракт домена d типа D -
это система вида (A, R, C, M), где A-множество
атрибутов, R – множество связей, C- множество ограничений целостности и M – множества произвольных операций.
Ассоциация объявляет возможность некоторой связи между
объектами. Она описывает типы участников, играющих в ней определенные роли, и
их множественность, т.е. количество объектов каждого типа, которое может
участвовать в связи.
Формально n-арная
ассоциация может быть определена в виде такой структуры 
, т.е. ассоциация состоит из набора концов ассоциации,
представленных типами участников и множественностью, с которой каждый из них
участвует в связи. Для нас важно, что, зная только характеристики связи,
система сама предоставляет поддержку ассоциативных связей через такой
интерфейс: 
, состоящий из функции принадлежности связи и двух
операторов – помещения новых объектов в связь и удаления их из нее.
Теперь мы дадим краткое описание части модели,
отвечающей за работу с доменами. Ключевыми объектами здесь являются отношения,
представляющие собой реляционные отношения, в которых домены могут выступать в
качестве типов, переменные которых хранятся в атрибутах кортежей. Основным
отличием от реляционных отношений является тот факт, что отношения ОМД не несут
никакой семантической нагрузки (это задача доменов). Задачей же отношений
является организация среды или системы, удобной для определенного вида
обработки данных.
Опишем
процесс построения схемы БД по известной модели из доменов. Пусть существует
модель M, состоящая из m взаимосвязанных доменов 
.
1.
Тогда схема БД
будет представлять собой n отношений (n<=m). Каждое
отношение Ri будет
иметь один атрибут, для переменных типа Di.
2.
Все связи модели
должны быть завершены. Под этим понимается существование соответствующих
отношений для всех участников связи.
3.
Для всех доменов,
связанных наследованием, должно выполняться 
, т.е . система должна гарантировать, что отношение,
состоящее из множества всех экземпляров домена Dj, должно содержать экземпляры доменов всех его
потомков.
4.
Система должна
обеспечивать неявный учет участников всех ассоциативных связей модели. Это
значит, что система должна поддерживать такую систему операторов 
для любой связи
A.
Итак,
основываясь на реляционной модели данных и таких подходах, как ORM и обладая средством описания структуры классов (такими, как UML), мы
описали некоторую гибридную модель данных. Ключевым объектом наших исследований
является так называемый домен – специализированный класс, предназначенный для
описания новых пользовательских типов данных. Наша модель оперирует информацией
о структуре подобных типов с целью предоставления декларативного подхода к
обработке таких данных. Другими словами, при таком подходе внутренняя структура
типа перестает быть “пассивным” элементом схемы БД, а наоборот, становится
основным фактором, определяющим эту схему. СУБД, основывающаяся на такой модели
данных, сможет выполнять хранение и обработку описанной с помощью доменов
информации, предоставляя определенную объектно-реляционную среду.
ЛИТЕРАТУРА
1.
Codd E.F. A Relational
Model of Data for Large Shared Data Banks. // Communications of the ACM, 1970,
377–387.
2.
Документация
к средству объектно-реляционного отображения Hibernate http://www.hibernate.org/hib_docs/v3/reference/en/html/
3.
Спецификация
на язык моделирования UML 2.0 http://www.uml.org/#UML2.0
4.
Спецификация
на средства объектно-реляционного отображения в java EJB 3.0 http://jcp.org/aboutJava/communityprocess/pfd/jsr220/index.html