- БАЗЫ ДАННЫХ -
УДК 004.652, 004.045
ОРГАНИЗАЦИЯ ИЕРАРХИИ АТОМАРНЫХ ЛИТЕРАЛЬНЫХ ТИПОВ В ОБЪЕКТНОЙ СИСТЕМЕ, ПОСТРОЕННОЙ НА ОСНОВЕ РСУБД
© 2009 г. П. П. Олейник
ООО "Астон"
344002 Ростов-на-Дону, промзона "Заречная", ул. 1-ая Луговая, 3б
E-mail: xsl@list.ru Поступила в редакцию 11.04.2006 г.
Современные корпоративные информационные системы (КИС) разрабатываются с применением объектно-ориентированной парадигмы. При этом основные принципы ООП используются как при реализации клиентской части приложения, так и при реализации серверной части (на сервере СУБД). Основной проблемой, возникающей при реализации бизнес-логики приложения, является обеспечение возможности сохранения сложных структур (объектов в БД). Для сохранения объектов в долговременной памяти чаще всего используются следующие подходы:
1. Использование в качестве хранилища информации объектно-ориентированной СУБД. Стандартом, определяющим функциональные возможности данных СУБД, является спецификация ODMG 3.0 [1, 2].
2. Реализация бизнес-логики приложения в среде объектно-реляционной СУБД. Основным стандартом, регламентирующим объектные расширения, присутствующие в реляционной СУБД, является стандарт SQL:2003 [3, 4].
3. Организация объектной системы в среде реляционной СУБД (объектно-реляционное отображение, ОРО, object-relational mapping, ORM) [5-9].
В настоящее время самое широкое распространение получили методы ОРО. Суть приме-
нения данных методов заключается в возможности реализации объектных элементов на основе реляционной БД. Особое внимание уделяется проблеме сохранения экземпляров классов, значений атрибутов и т.п. С точки зрения реализации все методы ОРО можно разделить на две категории:
1. методы ОРО без поддержки метаинформа-ции [5-7];
2. методы ОРО с поддержкой метаинформации [7-9].
Под метаинформацией подразумевается наличие информации об объектной системе, такой как состав и структура классов, описание иерархии наследования и принадлежности атрибутов к определенным классам.
Учитывая тенденцию повсеместного добавления метаинформации в объектно-ориентированные языки программирования (ООЯП), можно утверждать, что именно методы второй категории наиболее перспективны.
Несмотря на различие в подходах, конечным результатом применения методов является реализации возможности описания классов и сохранения объектов, представляющих сущности предметной области. При этом происходит выделение атрибутов классов и определение типов данных, значения которых представляют атрибут. Большая часть атрибутов описывается
атомарным литеральным типом данных (целые числа, строки, символы, дробные числа и т.п.). Именно поэтому унификация иерархии таких типов является ключевой проблемой, возникающей при организации объектной системы.
Несмотря на наличие достаточно большого количества работ, посвященных методам объектно-реляционного отображения, в каждой из них уделяется недостаточно внимания принципам организации атомарных литеральных типов в объектной системе. При этом существует несколько ортогональных подходов к решению описанной проблемы. В работах, посвященных методам ОРО без поддержки метаинформа-ции, атрибуты классов отображаются непосредственно на поля таблиц, в которых сохранены экземпляры классов [5-7]. При этом используются типы данных, присутствующие в СУБД. Так как данные методы предполагают выделение таблиц для сохранения объектов конкретной предметной области, то в них не предполагается унификация литеральных типов. В методах ОРО с поддержкой метаинформации, например, в "Сущность-Атрибут-Значение" (САЗ, Entity-Attribute-Value, EAV) выполняется выделение отдельных таблиц для представления конкретного типа данных [8-9]. При этом для каждого атрибута указывается имя таблицы, в которой будет физически сохраняться значение для конкретного объекта. Рассмотрим недостатки подходов, имеющиеся в организации объектной системы в РБД, и причины, не позволяющие успешно решать описанную задачу:
1. Жесткая привязка типов атрибута к конкретной БД. Причина в том, что многие авторы представляют реализации, ориентированные на конкретную СУБД. При этом смена СУБД потребует изменить большое количество кода. Кроме того, жесткая привязка снижает возможности добавления нового атомарного литерального типа данных к существующей системе.
2. Отсутствие единой спецификации. В отличие от объектных расширений языка SQL, базирующихся на стандарте SQL:2003, и от объектных БД, для которых существу-
ет спецификация ОБМС 3.0, для объектно-реляционных отображений стандарта не существует.
3. Отсутствие описания принципов организации уровня доступа к данным. Все существующие методы ОРО представляют собой архитектурные решения, предназначенные для реализации структуры классов в РБД. При этом авторы не уделяют внимания принципам применения и организации таких структур, как хранимые процедуры, функции, представления, необходимые для унификации объектного ядра системы. Как правило, каждый автор описывает набор собственных методов извлечения данных, применяемых для конкретной предметной области.
Целью данной статьи является разработка унифицированной иерархии атомарных литеральных типов, применимой в любой объектной системе, построенной на основе реляционной базы данных. В полученной реализации должны отсутствовать недостатки, присущие имеющимся реализациям, и все выделенные типы не должны зависеть ни от типов, присутствующих в РСУБД, ни от метода ОРО, примененного при построении объектной системы.
Для проектирования оптимальной иерархии необходимо рассмотреть имеющиеся решения сходных задач, т.е. как спецификацию объектных расширений языка (SQL:2003), так и спецификацию объектно-ориентированных БД (ОБМС 3.0).
Рассмотрим спецификацию ОБМС 3.0. На рис. 1 изображен фрагмент метамодели ОБМС 3.0 [1].
Рисунок требует пояснений. Для представления литеральных типов выделены класс йРтгшШуеТуре и перечисление й-ТуреМ. Причина выделения единственного класса в том, что в спецификации ОБМС метамодель объектной системы логически отделена от базовых классов, имеющихся в системе (чисел, строк, коллекций, множеств и т.п.). С нашей точки зрения, такой подход имеет ряд недостатков. Присутствие одного класса предполагает наличие фиксированного набора атрибутов класса.
Рис. 1. Метамодель объектной системы стандарта ODMG 3.0.
Т.е. каждый атомарный литеральный тип описывается определенным количеством параметров. Поэтому заранее необходимо выделить максимальное число атрибутов, часть из них для некоторых типов данных не будут иметь смысла. Так, для типа String, представляющего символьную строку, достаточно указать лишь длину (количество символов). В свою очередь, для типа Numeric, позволяющего сохранять дробные числа, потребуется указать уже два свойства: одно для определения максимального количества символов в числе, а второе - для определения точности значения (количества симво-
лов после запятой). Для занесения информации об этих типах данных в классе dPrimitiveType потребуется объявить оба свойства. При этом для типа String второе свойство избыточно, и его значение не анализируется. В модели ODMG для определения встроенных атомарных литеральных типов выделено перечисление dTypeld, которое содержит список зарезервированных констант. Этот список не может модифицироваться с целью отражения потребностей конкретного приложения. То есть недопустимо добавление новых литеральных типов. Тем не менее, имеется возможность соз-
Atomic Lite га I
I
1 1 1 1 1 1
long short unsigned long unsigned short float double
boolean octet char string enumo long long
Рис. 2. Диаграмма классов иерархии атомарных литеральных типов стандарта ОБМС 3.0.
Рис. 3. Онтология типов данных, реализующих объектные расширения языка SQL:2003.
дать псевдонимы типов, для представления которых выделен класс й-ЛИавТуре. Кроме того, в й-РггтШуе-Туре отсутствует атрибут, предназначенный для сохранения информации о базовом классе примитивного типа. Однако, в стандарте предполагается организация атомарных литеральных типов в иерархию на уровне конкретного языка программирования. Рекомендованная реализация представлена на рис. 2 [1].
Ключевым недостатком, по нашему мнению, является представление всех классов непосредственно унаследованными от абстрактного базового класса ЛЬотгсЬИега1. Введение промежуточных классов в иерархию наследования способствует более четкому разделению классов по категориям и подкатегориям (например, числа, целые числа, числа с фиксированной точкой и т.п.) и описанию для каждой из них (представленной
собственным корневым подклассом) только требуемых атрибутов.
Перейдем к рассмотрению языка SQL. На рис. 3 представлена онтология типов данных, реализующих объектные расширения языка SQL:2003 [10].
На рис. 3 видно, что для представления атомарных литеральных типов, которые в стандарте называются предопределенными, выделен единственный класс Predefined. Т.е. стандарту SQL:2003 присущи недостатки, описанные в отношении представления литеральных типов в метамодели ODMG 3.0.
Для реализации оптимальной, с нашей точки зрения, иерархии атомарных литеральных классов необходимо определить критерии оптимальности (КО):
1. Выделение единой иерархии, включающей как классы метамодели объектной системы, так и классы доменов, присутствующие в ней. Это позволит создавать производные классы от базовых доменов, в том числе и от атомарных литералов (строк, чисел, символов и т.п.), что дает возможность неограниченно расширять ядро объектной системы.
2. Представление всей иерархии с помощью одиночного наследования. Множественное наследование затрудняет и усложняет реализацию объектной системы, поэтому от него необходимо отказаться, как это и сделано во многих современных ООЯП, в которых применяется синтаксическая конструкция, называемая интерфейс (interface).
3. Унификация всей иерархии базовых классов. Для данного требования сформулированы три подкритерия:
• Независимость от типов данных, присутствующих в конкретной РСУБ
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.