Андреев А.М., Березкин Д.В., Самарев Р.С., Интелтек Плюс
Компьютерные технологии вышли на такой виток эволюции, что отчетливо просматривается стремление перенести в виртуальный мир объекты мира реального с минимальными потерями. Объектная СУБД именно то средство, которое обеспечивает запись объектов в базу данных "как есть", сохраняя их целостность и связи между ними. Поэтому решающим аргументом в пользу выбора ОСУБД является, то обстоятельство, что с их помощью можно наиболее полно перенести семантику объектов и процессов реального мира в сферу данных информационных систем. Кроме того, использование объектного подхода к проектированию систем [8], также поднимает роль ОСУБД как средств наиболее естественного хранения и манипулирования создаваемыми объектами. Об этом мы более подробно писали [3]. Можно указать также работы [1,7], где также рассматриваются особенности ОСУБД и проводится их сравнение с современными реляционными и объектно-реляционными СУБД.
ОСУБД базы находят широкое применение в телекоммуникациях и сети Интернет. Ведь Интернет - это собрание разнородных данных, поступающих из разных источников, с разнородными форматами. Поэтому не удивителен выбор именно ОСУБД для разработки Интернет-приложений. Естественное хранение мультимедиа - одна из сильнейших сторон объектных баз. Текст, картинки, видео и звук из которых составляется страничка в Интернете, хранятся в объектной СУБД как набор объектов, подготовленный к передаче на программу-клиент, чем достигается быстрая реакция сервера на запрос. Все большую популярность получают активные Web-серверы. Содержимое страничек они генерируют на лету, широко используя язык Java. Практически все крупнейшие разработчики объектных СУБД сделали Java одним из основных языков программирования своих СУБД. Таким образом, несмотря на наличие многих теоретических проблем, сложности строгой формализации объектной модели данных, большинство экспертов в области баз данных считают, что именно за этими системами будущее [8]. Наиболее типичными областями применения являются телекоммуникации, электронная торговля, системы прогнозирования экономических рисков и другие ресурсоемкие приложения.
История Versant начинается в 1988 году, когда были начаты работы по созданию масштабируемой, распределенной объектно-ориентированной архитектурой, а также алгоритмами кэширования данных. Основным продуктом компании является ОСУБД Versant Object Database Management System. Рекомендуемые области применения - телекоммуникации, построение приложений для анализа финансовых рынков, анализа рисков, систем сбора данных реального времени. Клиентами являются такие компании как AT&T, Alcatel, BNP/Paribas, British Airways, Chicago Stock Exchange, Department of Defense, Ericsson, ING Barings, MCI/Worldcom, Neustar, SIAC, Siemens, TRW, Telstra.
Компания Versant представляет следующие программные продукты: Versant Developer Suite являющийся сервером ОСУБД и Versant enJin, представляющий собой сервер объектно-ориентированного промежуточного уровня. Основной упор делается на разработку приложений средствами Java, хотя при этом обеспечивается работа с ОСУБД на языках C, C++, Smalltalk.
Другой производитель промышленных ОСУБД - компания POET Software. Область применения - построение электронных магазинов, систем электронной коммерции в Интернет. Основные принципы - быстрый доступ к хранилищу объектов и быстрый поиск объектов.
В настоящее время она представляет следующий продукты:
Poet Database - сервер хранилища данных;
Poet Object Server - диспетчер объектов (ОСУБД), предназначенный для работы совместно с Poet Database;
SQL Object Factory - сервер объектно-ориентированного промежуточного уровня, обеспечивающий прозрачную работу пользователей как с собственным сервером ОСУБД, так и с инородными для нее СУБД типа Oracle, DB2, MS SQL. Значительное внимание уделяется на разработку Java-приложений.
Разработчиком этой ОСУБД является компания НПЦ "ИНТЕЛТЕК ПЛЮС". Основное назначение - построение архивных, архивно-справочных документальных информационных и информационно-поисковых систем средних и крупных предприятий. В настоящее время коммерческий продукт - информационно-поисковая система ODB-Text. ИПС ODB-Text является документ-ориентированной системой, поэтому базовым понятием в ней является документ, который в свою очередь является объектом ОСУБД ODB-Jupiter, имеющий некоторый набор реквизитов-атрибутов.
Объектная модель данных в соответствии со стандартом ODMG 3.0 [12] характеризуется следующими свойствами:
Каждый тип имеет внешнюю спецификацию и одну или несколько реализаций. Спецификация определяет внешние характеристики типа, т.е. пользователю для работы с объектом предоставляется набор операций и набор атрибутов объекта, при помощи которых можно работать с реальными экземплярами. Реализация определяет внутреннее содержание объектов, например операции или каких-либо другие особенностей.
Рис 1. Основные элементы объектной модели
Тип является объектом. Поддерживается организация супертипов и подтипов, реализуя таким образом стандартный механизм объектно-ориентированного программирования - наследование.
Приведем следующий пример (рис. 2).
Рис. 2 Применение базовых понятий объектной модели в ОСУБД.
ОСУБД обслуживает множество баз данных (БД1, БД2, БД3). Каждая из этих баз содержит определенное множество типов. В БД могут существовать объекты соответствующего типа из множества типов. Каждый тип, имеет набор свойств, а каждый объект характеризуется состоянием, определяемым значением каждого свойства. Операции, определяющие поведение типа, едины для всех объектов одного типа. Свойство едино для всего типа, т.е. все объекты типа также имеют одинаковый набор свойств. Значение свойства относится к конкретному объекту.
Применяемые в ОСУБД Versant, Poet и ODB-Jupiter схемы данных в целом отражают основные требования стандарта ODMG.
ОСУБД Poet имеет такое понятие, как словарь. Словарь представляет собой самостоятельную базу данных, содержащую информацию о классах схемы данных базы данных. При этом один словарь может использоваться несколькими базами данных, но любая база данных может иметь только один словарь.
ОСУБД Versant и ODB-Jupiter не имеют непосредственной возможности организации единой схемы данных для нескольких баз данных, хотя в целом, на наш взгляд, без такой функции можно обойтись, так как:
Стандарт ODMG разработан с некоторым опозданием по сравнению с первыми ОСУБД, поэтому не предусматривает некоторые реализованные и, иногда весьма полезные функции. Отличия от стандарта ODMG, как правило, возникают при реализации интерфейсных функций ОСУБД, а также в результате характера внутренней реализации. Например, ОСУБД ODB-Jupiter позволяет хранить объекты, индексировать их атрибуты и производить их поиск даже в случае отсутствия этого типа объекта в схеме данных. Достигается это, во-первых, за счет того, что в схеме данных предусмотрено понятие анонимного типа, во-вторых, за счет внутренней организации объекта, когда любой объект, независимо от его типа, хранит полное описание своих атрибутов, включая их внутренние идентификаторы, а также описание типов атрибутов. Вследствие этого, появляется возможность серверу ОСУБД анализировать и обрабатывать объекты даже в том случае, если в схеме данных отсутствует какая-либо информация о них.
Существует несколько различных подходов для построения клиент-серверных архитектур. При этом основное внимание уделяется вопросу промежуточного хранения данных и организации параллельной работы. Особенностью объектных СУБД (рис. 3) является то, что их клиент-серверная архитектура подразумевает, что как сервер СУБД, так и клиент имеют собственное локальное хранилище объектов. Наиболее глубоко в этом направлении продвинулась фирма Versant [13], реализовав в своем одноименном продукте возможность организации помимо локальных хранилищ оперативных данных, полноценных персональных баз данных. Такой подход приводит к тому, что сервер выполняет меньшее число обращений к хранилищу данных, а клиент выполняет меньшее число обращений к серверу по сравнительно медленному сетевому протоколу.
Рис 3. Клиент-серверная архитектура ОСУБД.
При построении баз данных используют следующие основные подходы распределения вычислительной нагрузки системы (рис. 4): сервер-центрированная, клиент-центрированная и балансированная клиент-серверная архитектуры. балансированная клиент-серверная архитектура подразумевает, что часть вычислительных затрат по хранению, выборке и некоторой обработке берет на себя сервер, а часть - клиент. Такая архитектура и применяется в ОСУБД, где клиент, помимо отображения данных и формирования запросов, контролирует построение и отображение объектов, внедренных объектов, массивов внедренных объектов и др. На сервер ОСУБД, в отличии от сервера РСУБД при этом не возлагается обязанность по "разнесению" данных на различные таблицы, а ограничивается только необходимостью сохранения их в хранилище. При этом, если клиент задает запрос на условную выборку данных, разбором объектов (их индексов) уже занимается сервер ОСУБД.
Рис 4. Клиент-серверные архитектуры СУБД.
С точки зрения реализации конкретной ОСУБД, можно выделить несколько возможных вариантов организации, например Versant предлагает использовать отдельно Versant DBMS [14] и Versant enJin. Poet предлагает использовать свои программные продукты Poet Database - сервер хранилища данных, Poet Object Server - диспетчер объектов (ОСУБД) [10], SQL Object Factory [11] в любых комбинациях. А ОСУБД ODB-Jupiter [4] сочетает функции диспетчера объектов и объектной надстройки.
Одним из ключевых моментов функционирования любой базы данных является хранилище данных. К сожалению, рассмотреть конкретную структуру хранилищ существующих объектных баз данных не представляется возможным, поскольку информация эта является закрытой.
Общий подход к организации хранилищ имеет следующий вид.
База данных объединяет несколько хранилищ. Каждое хранилище ассоциируется с одним или несколькими файлами. Хранятся как метаданные (класс, атрибут, определения операций), так и пользовательские данные. Выделяют три типа хранилищ:
Организация базы данных ОСУБД Versant [14] имеет следующий вид:
Все базы данных делятся на групповые (group database) и персональные (personal database). База данных состоит из нескольких физических разделов (volume):
Для ОСУБД ODB-Jupiter [4] база данных состоит из:
Безусловно, для разных хранилищ различных ОСУБД существуют различные методы обеспечения восстановления после сбоев, а также методов избежания сбоев. В частности в случае применения в одной базе данных нескольких хранилищ объектов пользователей применяется т.н. двухфазном принятии транзакций, при котором подтверждение пользователю выдается только в том случае, если все принимающие участие в транзакции хранилища, выдали подтверждение транзакций серверу ОСУБД. Если происходит сбой в каком-либо хранилище, то, соответственно, происходит откат в целом.
Независимо от хранилищ объектов пользователя располагается хранилище индексов данных. Например, ОСУБД ODB-Jupiter имеет разделенные диспетчер объектов (сервер ОСУБД) и сервер данных, взаимодействующие между собой, используя среду CORBA. Это позволяет наиболее равномерно распределить вычислительную нагрузку отдельных серверов, формируя различные комбинации серверов (рис. 5). В частности любой сервер ОСУБД может хранить индекс данных на локальном хранилище, а если есть необходимость разгрузить серверы ОСУБД, возможно выделение отдельной ЭВМ, занимающейся исключительно индексацией.
 |
 |
Рис 5. Варианты организации хранилища индекса ODB-Jupiter.
Практически обязательной функцией современной ОСУБД является функция поддержания версий объектов. Возможна различная организация внутреннего механизма ведения версий. В качестве примера организации версионности рассмотрим ОСУБД Versant [14]. Для всех объектов возможно сохранение всех версий их изменения. При этом создается граф происхождения версий. Имеют место следующие свойства:
Проиллюстрируем сказанное примером ведения версий в ОСУБД Versant. На рис 6 представлена схема создания версий объекта и управления его перемещением между различными базами данных.
Рис 6 Управление версиями в ОСУБД Versant
В этом примере создание версий объектов соответствует некоторому моменту времени t0 .. t10. Приведем действия, соответствующие каждому моменту времени:
Таблица 1. Соответствие моментам времени выполняемых действий.
| Время | Действие |
|---|---|
| t0 | Создан объект (версия 1) в личной БД db1 |
| t1 | Создана версия 2 объекта на основе версии 1 в личной БД db1 |
| t2 | Создана версия 1 объекта в результате операции регистрации (check in) из БД db1 в БД db2 |
| t3 | В качестве иллюстрации образования параллельных версий создана версия 3 в БД db1 |
| t4 | Выполнена операция check out из групповой БД db2 в личную БД db3. Создана версия 1 БД db3. |
| t5 | Создана версия 2 объекта на основе версии 1 в личной БД db3 |
| t6 | Создана версия 4 объекта на основе версии 2 в личной БД db1 |
| t7 | Параллельная версия 3 создана в личной БД db3 |
| t8 | Создана версия 4 объекта на основе версии 2 в личной БД db3 |
| t9 | Создана версия 2 объекта в результате операции регистрации объекта версии 4 БД db3 в БД db2. Объект версии 1 в БД db2 является предком объекта, помещенного в БД db2 зарегистрированным из БД db3, поэтому новому объекту присвоена версия 2. |
| t10 | Аналогичная ситуация при выполнении операции check out к версии объекта 2 БД db2 из БД db1. Объект версии 2 в БД db1 является предком объекта версии 2 в БД db2, следовательно новому объекту в БД db1 присвоена версия 5 по графу версий БД db1. |
Рассмотрим организацию одного из наиболее важных механизмов любой СУБД - механизм транзакций. На примере ОСУБД Versant рассмотрим наиболее типичные виды транзакций.
ОСУБД Versant поддерживает 3 вида транзакций:
Короткие транзакции характеризуются малым временем выполнения, т.е. могут существовать только в рамках сеанса работы с ОСУБД. Это наиболее простой вид транзакций, реализованный во всех современных СУБД. Все объекты, подлежащие изменениям, блокируются и, соответственно, после принятия транзакции, разблокируются, а изменения записываются в базу данных.
Длинные транзакции предназначены для увеличения производительности при групповой работе. В настоящее время они также являются одной из характеристик ОСУБД. Реализовано это следующим образом: Versant позволяет создавать персональные и групповые базы. При работе большого количества пользователей с одной базой неминуемо возникает проблема перегрузки аппаратных ресурсов вычислительной системы. Для снижения нагрузки на центральный сервер Versant предлагает организовывать пользователям, постоянно работающим с определенными объектами, персональную базу данных. Пользователи работают со своей базой данных, а объекты из этой базы синхронизируются с групповой базой данных. Таким образом, пользователь, начав длинную транзакцию, отмечает объекты, с которыми предстоит работать в групповой базе данных (операция check out). Эти объекты копируются в его персональную базу, а в групповой базе данных - блокируются, причем блокирование может быть как на запись, так и на чтение. Versant создает в групповой базе объект, содержащий все данные о длинных транзакциях. В случае повреждения групповой базы или физического отключения сервера групповой базы пользователь сможет продолжать работать с объектами в его персональной базе и после восстановления групповой базы - синхронизировать свои объекты. Перед завершение длинной транзакции пользователь должен поместить все измененные объекты обратно в основную базу, для чего выполняет операцию check in. После этого объекты копируются в основную базу, а блокировка снимается. В случае аварийного завершения со стороны пользователя длинной транзакции все изменения будут потеряны.
Вложенные транзакции по принципу функционирования близки коротким транзакциям. В процессе выполнения одной транзакции формируются другие. Причем следует отметить, что если в текущей сессией работает один процесс, то создается стек транзакций, в случае, если в текущей сессии работает несколько процессов, то в этом случае - дерево транзакций.
Назначение блокировок - гарантировать монопольность использования объекта конкретным пользователем с целью предотвращения одновременного изменения данных.
В соответствии с терминологией ОСУБД Versant [14], существуют следующие виды блокировок:
Короткие (short lock) - предназначены для обеспечения последовательного доступа к данных при многопользовательском режиме работы. Один из видов коротких блокировок - короткая блокировка на обновление - автоматически выполняется во время выполнения коротких транзакций.
Продолжительные блокировки (persistent lock) обеспечивают блокирование объектов в случае, когда необходимо блокирование на продолжительное время - часы, дни, недели. Объекты могут быть заблокированы на выполнение операций чтения, записи, а также установлен специальный вид блокировки, позволяющий получать извещения об изменении объектов. Продолжительные блокировки применяются, как правило, совместно с длинными транзакциями. При этом объект может быть заблокирован несколькими способами:
Оптимистические блокировки (optimistic lock) используются в том случае, когда для работы необходимо прочитать множество объектов, однако модифицироваться будет меньшая часть из них. В этом случае не рационально использовать механизм продолжительных блокировок. Существует некоторая особенность операций check in и check out, заключающаяся в том, что выполнение операции check in для объектов, которые не были заблокированы операцией check out приведет к созданию нового объекта, а не к обновлению существующего. Выполнение оптимистические блокировок происходит следующим образом: все объекты, которые предполагается блокировать таким образом должны иметь поле даты и времени (timestamp), в которое помещается значение даты и времени блокировки. Далее пользователь может прочитать все интересующие его объекты. В случае необходимости изменить объект - можно непосредственно его изменять и выполнять операцию check in. При этом, хотя доступ другим пользователям и не закрыт, действует механизм извещений, позволяющий им корректно обработать изменение объекта. Завершение транзакций, использующих оптимистические блокировки, происходит обычным способом.
ОСУБД Versant позволяет отслеживать факты блокировок и изменений их состояний, для чего предусмотрен механизм извещений.
Группа ODMG разработала язык OQL, который стал стандартным языком запросов ОСУБД. Основная конструкция языка, подобно SQL, это конструкция SELECT...FROM...WHERE. Следует также отметить отсутствие модифицирующих данные конструкций в этом языке. Поскольку язык OQL разработан как объектно-ориентированный, результат запросов представляет собой множество объектов. Сложные взаимосвязи объектов могут напрямую указываться в запросе, что является одной из отличительных особенностей OQL.
На примере ОСУБД Versant рассмотрим реализацию языка запросов OQL. Применяемая далее терминология соответствует ОСУБД Versant, поэтому приведем несколько определений.
Запрос - выражение, по которому просматривается группа объектов и возвращаются те из них, которые удовлетворяют поисковому условию.
Результат выполнения запроса: может быть получен как в виде ссылок на объекты, так и в виде значений, т.е. в виде объектов.
Чтобы проиллюстрировать допустимые имена атрибутов, приведем следующий пример:
Предположим, что имеют место следующие структуры, описанные на языке C++:
struct Date {
int day;
Base b;
};
struct Base {
int id;
int code;
};
Тогда допустимыми для запроса атрибутами являются следующие имена:
Date::day Date::b.Base::id Date::b.Base::code
Если в базовой схеме данных имеет место отношение по указателю, то допустимыми будут следующие имена:
Date::day Date::b->Base::id Date::b->Base::code
Среди операторов сравнения используются следующие группы операторов:
Возможно управление логическими путями в запросах, что позволяет значительно упростить поисковый запрос, вместе с тем указать комбинацию флагов управления логическими путями, т.е. указать, каким именно образом обрабатывать наличие или отсутствие значение атрибута, являющимся ссылкой на другие объекты, а также различные комбинации для множественных ссылок.
Язык OQL является сильно функционально ограниченным языком, назначение которого - стандартизовать операции с объектами, работу с иерархической наследственной структурой объектов, навигацию по ссылкам. Из этого вытекает ряд проблем, решаемый расширением языка, например языком VQL (Versant Query Language), добавляющий несколько дополнительных конструкций:
| COMMIT | Commit transaction. |
| DELETE | Delete objects. |
| INSERT | Insert objects. |
| QUIT | Terminate application. |
| ROLLBACK | Roll back transaction. |
| SELECT | Find objects. |
| UPDATE | Update objects. |
Помимо этого производители ОСУБД обычно расширяют функциональность языка запросов до стандарта SQL, по крайней мере стандарта 92 года и SQL ODBC для того, чтобы обеспечить совместимость с ОСУБД обще принятых механизмов обмена данными.
В шестом поколении ОСУБД Versant появилось концептуальное нововведение виртуальных атрибутов. Их назначение - обеспечить работу с текстовыми данными на различных языках. Они не описываются в схеме данных, однако, являются производными от существующих атрибутов класса. При этом они вычисляются в реальном времени, но вместе с тем могут быть проиндексированы.
Пример: требуется для немецкой базы данных произвести выборку всех книг, имеющих названия начиная с буквы "U" до "V":
PClassObject<Book>::Object().select(NULL,FALSE,
PPredicate(PAttribute("/national de_DE utf8 Book::title") > "U" " &&
PAttribute("/national de_DE utf8 Book::title") ==
" "V" "));
Очевидно, что стандартный латинский алфавит не подходит для этой цели, поскольку не включает букву "U-умляут". Имея возможность указать тип используемой кодировки
national de_DE utf8, получим книги, имеющие названия, начинающиеся со всех трех букв данного диапазона ("U", "U" и "V").
Другой пример применения: обеспечить выборку данных, где поле
LastNameбудет без учета регистра соответствовать
{samuel},
а поле
Firstnameв точности соответствовать
{Mohan M}.
select * from Employee where `/tuple { /nocase ascii LastName }
Firstname` == "{samuel} {Mohan M}";
Часто необходимо обеспечить поиск текстовых данных в соответствии с особенностями конкретного языка, не заставляя пользователя формировать сложные запросы. В таких случаях применяются, т.н. средства полнотекстового поиска. В частности ОСУБД Poet имеет систему Verity®. ОСУБД ODB-Jupiter уже содержит встроенные средства обработки русского языка, поскольку основное ее назначение - обеспечить хранение и поиск именно текстовых данных на русском языке.
В последнее время наметилась тенденция на широкое распространение систем т.н. промежуточного уровня.
Промежуточного уровня обеспечивает:
Последний пункт рассмотрим более подробно. Существует множество различных СУБД как по их внутренней организации, так и по внешнему интерфейсу обмена данными. В крупных организациях, где развитие информационных систем происходило децентрализовано, скорее всего применяется несколько различных СУБД для разных задач. Очевидно, что для построения клиентского приложения, использующего их данные одновременно, придется затратить много усилий. Современная тенденция построения приложений среднего уровня - организация единого клиентского интерфейса, обеспечивающего работу с данными в концепции ОСУБД. При этом в функции промежуточного слоя ставиться преобразование данных и запросов, а также организация функциональности базовой для них ОСУБД в инородных СУБД.
При использовании РСУБД возникает ряд проблем:
Среди производителей ОСУБД фактически становиться стандартом построение объектно-ориентированных серверов промежуточного уровня для связи с РСУБД. Так компания Versant выпускает сервер Versant enJin, компания Poet - Poet SQL Object Factory, а компания НПЦ ИНТЕЛТЕК ПЛЮС - ODB-Jupiter, уже содержащую в себе функции ОСУБД и объектной надстройки РСУБД.
Рассмотрим организацию работы одного из объектно-ориентированных серверов промежуточного уровня на примере продукта Poet SQL Object Factory[11].
Фактическое назначение промежуточного уровня - обеспечить однообразность интерфейса прикладных программ при работе с различными СУБД. Другими словами, независимо от используемой СУБД используемая объектная модель должна оставаться неизменной (рис. 7).
Рис 7 Варианты организации внутреннего взаимодействия ОСУБД Poet.
В Poet SQL Object Factory применяется понятие "словарь", которое обозначает базу данных схемы данных. Poet SQL Object Factory рассматривает РСУБД как хранилище данных. Для работы с РСУБД предусмотрен механизм трансляции словаря в программу на языке определения данных конкретной РСУБД. В процессе такого преобразования также следует выполнить специфичную для конкретной РСУБД настройку параметров базы данных. Компания Poet заявляет, что Poet SQL Object Factory обеспечит полную функциональность полноценной ОСУБД Poet при использовании любой реляционной базы данных в качестве хранилища.
Рассмотрим пример преобразования объектной схемы данных в реляционную:
Описание класса на языке C++:
persistent class Person
{
PtString name;
int age;
PtDate birthDate;
};
Результат преобразования в запрос на языке определения данных РСУБД:
CREATE TABLE SCHEMA.PERSONC101V0( -- Identity columns OID NUMBER (38) not null, CID NUMBER (38) not null, -- Columns for class members NAME0V0 VARCHAR2 (50), AGE1V0 NUMBER (38), BIRTHDATE2V0 DATE, PRIMARY KEY ( OID ));
При этом обязательным полем становится идентификатор объекта. Это поле также является ключевым.
Одна из специфических особенностей ОСУБД - кэширование объектов, выливается в данном случае в кэширование строк таблиц.
В объектной модели ОСУБД Poet существуют два типа связей между объектами: по указателю и "по запросу". Отличие последнего метода от указателей заключается в том, что объект загружается в память клиента только в случае явного обращения к нему. При трансляции схемы данных ссылка на объект будет заменена атрибутом идентификатора объекта.
Практически аналогично работает механизм отображения коллекций атрибутов типов SetOfObject, BagOfObject, VarrayOfObject, ListOfObject.
Пример C++ POET Object Model:
persistent class Car
{
PtString make;
PtString model;
int year;
};
persistent class RichPerson
{
PtString name;
lset<Car *> fleet;
lset<PtString> villas;
};
Результат отображения на схему РСУБД Oracle:
-- Note that a unique table name was generated for each set -- memberName + classId + uniqueId -- FLEET + C102 + P0V0 CREATE TABLE SCHEMA.RICHPERSONC102V0 ( OID NUMBER (38) not null, CID NUMBER (38) not null, NAME0V0 VARCHAR2 (50), PRIMARY KEY ( OID ) ); CREATE TABLE SCHEMA.FLEETC102P0V0 ( OID NUMBER (38) not null, CID NUMBER (38) not null, EID NUMBER (38) not null, -- An Object ID points to the actual persistent object. CAROID0V0 NUMBER (38), CARCID1V0 NUMBER (38), PRIMARY KEY ( OID, EID ) ); CREATE TABLE SCHEMA.VILLASC102P1V0 ( OID NUMBER (38) not null, CID NUMBER (38) not null, EID NUMBER (38) not null, DATA0V0 VARCHAR2 (50), -- PtString elements PRIMARY KEY ( OID, EID )
Существует возможность отображения множеств атрибутов (Set) класса в единое поле типа BLOB. При отображении множеств на реляционную схему данных, были бы созданы соответствующие таблицы и, соответственно, каждый элемент множества потребовал бы отдельной реляционной записи. При чтении объекта в целом, следовало бы произвести несколько обращений к серверу РСУБД, а в этом случае весь объект может быть прочитан за одно обращение. При этом можно выиграть в производительности за счет того, что объект записывается и считывается за один проход, а также за счет того, что количество записей в кэше строк становиться меньше, а следовательно также увеличивается скорость их чтения и повышается эффективность опережающего чтения.
Для обеспечения работоспособности механизма блокировок, который здесь выливается в блокировку строк, предназначен т.н. сервер контроля параллельных операций.
С целью обеспечения интернационализации, все текстовые атрибуты хранятся в кодировке UNICODE.
Имеются также некоторые особенности при работе с SQL запросами. В частности для ОСУБД Poet символ '*' в условии на значение атрибута означает "все", а при выполнении такого запроса через Poet SQL Object Factory могут быть потеряны записи, в которых при внесении в базу данных, это атрибут оказался равным NULL.
Необходимо напомнить, что РСУБД не поддерживает механизм наследования непосредственно. Для его реализации в Poet SQL Object Factory 3 предусмотрено вида реализации (рис. 8):
Рис 8 Варианты организации наследования в Poet SQL Object Factory.
Вариант "Store Default" подразумевает, что для каждого класса будет создана своя таблица, причем она будет содержать все его атрибуты, в том числе и унаследованные. С точки зрения хранения - наиболее экономичный вариант и довольно быстрый вариант, однако для запрос на выборку объектов определенного класса должен обеспечивать выборку всех потомков этого класса, а в данном случае это может быть обеспечено за счет увеличения сложности запросов.
Второй вариант "Store All" предполагает, что таблица класса предка содержит значения атрибутов как своих объектов, так и объектов потомка, а таблица класса потомка содержит все атрибуты объектов, в том числе и унаследованные. Метод обеспечивает большую производительность при выборке данных, однако серьезно замедляет процесс добавления и удаления объектов, поскольку для потомка необходимо удалить записи уже из нескольких таблиц.
Третий вариант "Store Universal" предполагает, что все данные будут храниться в одной таблице, содержащей полны набор атрибутов потомка. В этом случае при хранении объектов класса предка часть полей окажется незаполненной, однако обеспечивается наибольшая производительность, как при добавлении данных, так и при выборке. Серьезный недостаток - чрезмерный расход памяти при большом различии набора атрибутов предка и потомка и большом количестве объектов класса предка.
Ведение версий объектов обеспечивается введением поля типа дата. Следует отметить, что ОСУБД Poet не поддерживает автоматическое формирование версий (автоинкрементное), поэтому операции по добавлению версии должны выполняться вручную.
Poet SQL Object Factory обеспечивает выполнение параллельных и вложенных транзакций, не характерных для большинства реляционных баз данных. Наибольшая сложность здесь заключается в том, что необходимо обеспечить промежуточное хранение данных текущей транзакции, которое при ее принятии должны быть внесены в РСУБД.
В заключение следует отметить, что наглядно просматривается тенденция в области построения ОСУБД среди различных производителей ОСУБД - ориентация не на чистое использование ОСУБД, а на совместную работу с уже имеющимися СУБД, в том числе РСУБД, обеспечивая им недостающую функциональность. Широко продвигается идея использования языка Java как основного языка разработки, хотя значительное число разработок все еще ведется с использованием языка C++.
Базовый язык OQL также подвергается многочисленным доработкам самими разработчиками ОСУБД, приближая его таким образом по функциональности к стандартам SQL.
В связи со значительным развитием систем передачи данных широко применяется концепция распределенных информационных систем, что позволяет разделить функциональные компоненты ОСУБД и использовать их с наивысшей эффективностью, предоставляя также возможность использовать компоненты ОСУБД сторонним приложениям.