Из-за наличия большого количества работ, посвящённых методам объектно-реляционного отображения (ОРО), широкую популярность получили инструменты, позволяющие организовать объектную систему на основе РСУБД [1-4]. В данной статье описан один из подходов, использованный при организации объектной системы в среде СУБД Microsoft SQL Server 2005, на основе которого разработан инструмент, успешно применяемый автором в течение последних пяти лет при разработке крупной ERP-системы.
Проектирование и реализация любого программного продукта (ПО) начинается с формулирования требований (критериев) оптимальности (КО), которым должна соответствовать полученная реализация. Для инструмента, позволяющего организовать объектную систему в среде РСУБД, были выдвинуты следующие КО:
- Поддержка обширной метаинформации;
- Поддержка связей между отношениями;
- Трансформация отношений в классы;
- Поддержка методов обработки данных;
- Поддержка отношений наследования и возможности полиморфизма для методов.
Рассмотрим каждый критерий более подробно. Поддержка обширной метаинформации соответствует современной тенденции в области объектно-ориентированных языков программирования. В русле описанной задачи выполнение данного критерия подразумевает создание вспомогательных таблиц, предназначенных для сохранении информации о классах, об атрибутах, типе данных атрибутов, иерархии наследования, отношениях, связывающих классы и т.п. Поддержка данной информации на стороне СУБД позволяет создавать (автоматически генерировать) вспомогательные объекты БД, такие как представления, хранимые процедуры, табличные функции.
Физическая структура реляционной базы данных реального приложения содержит множество таблиц и связей. Поэтому необходим общий унифицированный механизм представления связей между отношениями (КО2). Следует учесть главное отличие между внешним ключом, организующим ссылочную целостность между таблицами и принципы реализации отношений между классами. В первом случае в подчинённой таблице создаётся поле, значение которого должно равняться null или быть равным одному из имеющихся значений альтернативного ключа в главной таблице. Во втором случае, в классе, находящемся в отношении "один-ко-многим", со стороны "один" объявляется атрибут, типом которого является коллекция классов, представленная в отношении со стороны "многие" [3]. Для выполнения данного критерия (КО2) необходимо наличие обширной метаинформации (КО1) и предусмотреть возможность трансформации отдельных отношений в классы предметной области (КО3).
Выполнение КО3 позволяет неограниченно расширять физическую структуру БД и автоматизировать процесс трансформации конкретной таблицы в класс предметной области, атрибуты и методы которого детально описаны в метамодели (reverse engineering). В связи с этим в структуре БД присутствует постоянный состав таблиц, в которых имеется информация обо всех классах предметной области (метамодель) (КО1).
Ключевым достоинством объектно-ориентированной парадигмы является возможность объявления классов, состоящих из данных, предназначенных для хранения состояния объекта (экземпляра класса) и методов обработки. Для выполнения требований КО4 и учёта специфики разработки современных объектных систем нами выделены две категории методов:
- Методы обработки данных извлекают значения атрибутов класса из таблиц БД и обрабатывают их. К методам относятся: представления, хранимые процедуры, функции и т.п.
- Методы визуализации данных предназначены для графического отображения данных в клиентском приложении. К ним относятся формы представления нескольких экземпляров классов, формы редактирования одного экземпляра и связанных объектов, форма подстановки, предназначенная для выбора объекта (занесения значений внешним ключам), форма печати отчёта.
Отметим, что у класса может быть любое количество методов.
Отношение наследования активно используется при разработке крупных объектных систем, поэтому необходимо предусмотреть возможность описания производных классов (КО5). При этом в производном классе можно не только добавить новый атрибут или метод, но и переопределить метод, реализованный в базовом классе (полиморфизм). Т.к. в производном классе разработчик ИС добавляет различные атрибуты, то необходимо изменить как методы обработки данных (для извлечения значений атрибутов для объекта), так и методы визуализации, которые отвечают за отображения значений добавленных атрибутов в графическом интерфейсе пользователя.
Разработка объектной системы, отвечающей выделенным критериям оптимальности, позволит получить следующие преимущества:
- Унифицированная система абстрактных типов данных, способствующая повторному использованию написанных ранее классов.
- Ускорение процесса разработки приложений за счёт хранения всей информации (классов предметной области и метаклассов) в единой БД, что позволяет создать вспомогательные инструменты, ускоряющие процесс разработки ИС.
- Упрощение процесса внесения модификаций, которые в нашем случае представляют добавление производных классов, объявление новых атрибутов, создание новых методов и изменение существующих.
- Возможность программной генерации методов обработки и визуализации по имеющейся метаинформации.
Рассмотрим реализацию описанных принципов организации объектной системы, удовлетворяющую выделенным критериям оптимальности на гипотетическом примере (рис. 1).
Рис. 1. - Принципы организации объектной системы в РСУБД
Рисунок требует пояснений. В левой части рисунка расположены две таблицы (MasterTable(главная) и DetailTable (подчинённая)), объединённые связью "один-ко-многим". Для организации такой связи в DetailTable присутствует внешний ключ MFld01, который ссылается на первичный ключ таблицы MasterTable (поле MFld01). Отметим, что все поля таблиц описаны с помощью встроенных типов данных целевой РСУБД (Microsoft SQL Server 2005).
В соответствии с КО3 каждая из таблиц трансформируется в классы. При этом каждый класс становится корневым для своей иерархии и предоставляется возможность объявить производные классы (КО5). Суть в том, что все экземпляры иерархии данного и производных классов сохраняются в этой таблице. Такой подход напоминает реализацию метода ОРО «Наследование с одной таблицей (Single Table Inheritance)» [1,3], однако, в нашем случае в таблице присутствуют только атрибуты корневого класса. Значения атрибутов производных классов сохраняются в одной общей таблице ChildAttValue. Состав и структура полей данной таблицы соответствует хорошо известному методу ОРО, названному "Сущность-Атрибут-Значение" (САЗ) [4]. В отличие от классической реализации, использующей для сохранения значений атрибутов всех классов иерархии единую таблицу, в нашем случае в ChildAttValue сохраняются только значения атрибутов производных классов. В итоге мы реализовали метод, который комбинирует в себе архитектурные решения двух известных паттёрнов ОРО. Этот подход имеет следующие преимущества:
- Для извлечения значений атрибутов базового класса, которые необходимы для всех классов иерархии, требуется выполнить лишь одну операцию выборки данных из таблицы;
- В структуре БД присутствует лишь одна таблица, представляющая иерархию классов, что позволяет физически группировать экземпляры подобных классов;
- Минимизация дискового пространства, т.к. в базовой таблице хранятся значения атрибутов, присутствующих во всех классах. А в ChildAttValue сохраняются не пустые (не NULL) значения атрибутов.
В представленной реализации поддерживается обширная метаинформация (КО1), которая сохраняет информацию как об иерархии атомарных литеральных типов (классы, унаследованные от Literal), так и о иерархии классов предметной области (например, о MasterTable, DetailTable). Возможная реализация иерархии атомарных литеральных типов в среде РСУБД Microsoft SQL Server 2005 представлена в работе [5]. Ключевой особенностью, в разрезе нашего обсуждения, является возможность объявления атрибутов для литеральных типов и задания для них значений. При трансформации таблиц в классы (КО3) каждое поле таблицы преобразуется в атрибут класса, при этом тип атрибута определяется в соответствии с типами данных (классами), имеющимися в метамодели (КО1). Так, поле Fld01 (DetailTable) типа Integer трансформируется в атрибут Att01 (DetailClass), типом которого является атомарный литерал IntLiteral. При этом внешний ключ MFld01 (DetailTable), который также является целым числом, преобразуется в атрибут Att01 (DetailClass), типом которого выступает класс MasterClass. Таким способом реализуются поддержка связей между отношениями на уровне объектной системы (КО2). Отметим, что класс MasterClass получен после трансформации таблицы MasterTable. Как видно из рис. 1, имеется возможность объявления производных классов (КО5). Так, класс MCChild01 унаследован от класса MasterClass и значения его свойств сохраняются в таблице ChildAttValue.
Перейдём к критерию оптимальности 4 и рассмотрим методы, присутствующие в классе DetailClass. Часть методов физически представляют собой объекты БД. Метод View является представлением и возвращает значения всех атрибутов класса в виде единого набора данных. В производном классе (Child01) этот метод переопределён, так как необходимо вернуть значения атрибутов, объявленных в этом классе (ChAtt01, ChAtt04). Метод ProcView физически представляет собой хранимую процедуру (ХП), которая на основе переданного фильтра (в виде XML) формирует результат, представляющий собой множество объектов. Для получения значений атрибутов одного конкретного объекта и для их изменения используется процедура ProcSupport. Для представления нескольких экземпляров классов в графическом интерфейсе пользователя объявлен метод FormView; для редактирования – FormAU, для удаления – FormDel. На рис. 1, в классе DetailClass присутствует метод FormLookup, который предназначен для подстановки значений в поля внешнего ключа. Отметим, что все методы могут быть перегружены (см. атрибуты класса Child01, помеченные стереотипом «ovveride»), т.е. реализуется полиморфизм на уровне БД (КО5).
Общая схема извлечения информации и отображения её в клиентском приложении представлена на рис. 2.
Рис. 2. – Схема извлечения данных
Все данные (элементы метамодели и экземпляры бизнес-сущностей) физически сохраняются в таблицах базы данных и извлекаются с помощью представления (View). Ключевым достоинством представления является то, что на сервере СУБД представление сохранено в откомпилированном (оптимизированном) виде и имеется возможность создания индексов по некоторым полям. Всё это значительно повышает скорость выполнения запросов по сравнению с выполнением динамических запросов, которое применяется в существующих инструментах ОРО. Однако необходимо предусмотреть возможность выполнения произвольных запросов на основании переданного условия фильтрации. Для этих целей используются хранимые процедуры (ProcSupport, ProcView). В конечном итоге, все данные отображаются в графических формах (FormView, FormAU, FormDel, FormLookup).
Описанный подход использован при реализации объектной надстройки над реляционной СУБД Microsoft SQL Server 2005, названной AxSystem ORC (Object-Relation Core). Надстройка применялась при разработке крупной КИС, автоматизирующей деятельность международной корпорации, занимающейся закупкой и продажей сельхозпродукции, выпуском растительного масла и последующим бутилированием. В настоящее время создана собственная интегрированная среда разработки, в которой реализована автоматизированная система учёта движения морских судов AxSystem Shipping Global Control [6]. В ближайшее время демонстрационная версия этой программы будет выложена на сайте http://www.axsystem.ru.
Благодарность
Автор выражает благодарность системному аналитику Аверину Алексею Ивановичу, одному из разработчиков описанного подхода, который нашёл свободное время в своём плотном графике, ознакомился с первой версией статьи и внёс ряд ключевых замечаний
Литература
- Ambler S.W. Agile Database Techniques—Effective Strategies for the Agile Soft-ware, John Wiley & Sons, 2003, 373p.
- Keller W. Mapping Objects to Tables. A Pattern Language
- Флауер М. Архитектура корпоративных программных приложений, Пер. с англ. – М.: Издательский дом «Вильямс», 2004. – 544 с.: ил. – Парал. тит. англ.
- Nadkarni P. M., Brandt C. A., Morse R., Matthews K., Sun K., Deshpande A. M., Gadagkar R., Cohen D. B., Miller P. L. Metadata-driven creation of data marts from an EAV-modeled clinical research database // International Journal of Medical Informatics 65, 2002,p.225-241.
- Олейник П.П. Принципы организации иерархии атомарных литеральных типов объектной системы на основе РСУБД Microsoft SQL Server 2005
- Аверин А.И., Олейник П.П. Автоматизированная система учёта коммерческой составляющей движения морских и речных судов AxSystem Shipping Global Control. Свидетельство об официальной регистрации программы для ЭВМ № 2008611185, 6 марта 2008 г.
