Создание среды хранения объектов над иерархической субд

Создание среды хранения объектов над иерархической СУБД.
Порай Д.С., Голоусикова А.А.

Аннотация

Описывается опыт создания среды хранения объектов, реализованного над иерархической СУБД Ника. Механизмы работы с объектами основаны на технологии Component Object Model фирмы Microsoft. Хранилище позволяет одновременно хранить в БД экземпляры классов разных версий, экземпляры классов, которых не существовало на момент написания прикладной программы, обладает интерфейсом с языками программирования C++, VisualBasic, Pascal with Objects, Java, позволяет строить программы из самостоятельных модулей, обрабатывать существующие COM-объекты (без переписывания их кода).

1. Введение

В настоящее время в области разработки программного обеспечения для баз данных сложилась сложная ситуация. С одной стороны, большинство программ пишется с привлечением идей объектно-ориентированного программирования [1]. Считается, что это наиболее прогрессивный из всех известных сейчас подходов к построению сложных систем. Он позволяет создавать продукт из модулей, допускающих повторное использование, причем степень повторного использования превышает результат, получаемый при процедурном проектировании. Характерной особенностью такого продукта является большое количество взаимосвязанных типов данных (классов) со сложной структурой. Для языков программирования, поддерживающих сложные структуры, требуется адекватная модель базы данных. С другой стороны, большинство современных СУБД являются реляционными системами. Теория реляционных СУБД была разработана, в основном, в 70-х и 80-х годах и нынешние реализации слабо приспособлены к хранению данных со сложной структурой. Слабая приспособленность выражается, главным образом, в низкой скорости обработки запросов.
Таким образом, на стыке объектных языков программирования и современных средств хранения данных сложилась противоречивая ситуация. Исправить эту ситуацию призваны объектно-ориентированные СУБД.

2. Предметная область

2.1. Задача хранения объектов

Одна из задач, неизбежно встающих в процессе разработки любой программы –сохранение данных в долговременной памяти (например, на жестких дисках) и восстановление обратно. Для программ, написанных на объектно-ориентированных языках, это означает способность сохранять и восстанавливать объекты.
Предложено несколько способов решения этой задачи:

Возложить ответственность на сам объект. Каждый объект способен самостоятельно сохранять свое состояние в виде последовательного потока байт и восстанавливать его на основе такой же последовательности байт.
Хранить объекты в объектно-ориентированной базе данных. СУБД сама умеет записывать объекты в базу и загружать их обратно. Для этого все объекты предоставляют вовне (в данном случае СУБД) информацию о своей структуре (имеющиеся переменные и методы).
Хранить объекты в системе с одноуровневой памятью. Система сохраняет фрагменты оперативной памяти побайтно, не вникая в сущность объектов. При этом нет необходимости разбираться в связях между объектами, т.к. при сохранении синхронно всех объектов системы, автоматически будут верны все ссылки (в данном случае это просто указатели). Примером операционной системы, построенной на таких принципах, является Grasshopper [8].

Следует отметить, что первый способ идейно является самым простым, но является недостаточно гибким (связи между объектами можно указывать лишь для тех объектов, которые сохраняются в одном потоке) и требует написания дополнительного кода для каждого нового класса (в отличие от двух других способов).

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

Особенный интерес представляет второй способ (объектно-ориентированные базы данных). Рассмотрим его более подробно.

2.2. Объектно-ориентированные базы данных

Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем.
Большое число работ не означает, что все проблемы ООБД полностью решены. Современная ситуация с ООБД напоминает ситуацию с реляционными системами середины 1970-х. При наличии большого количества экспериментальных проектов (и даже коммерческих систем) отсутствует общепринятая объектно-ориентированная модель данных, и не потому, что нет ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле, имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.

2.3. Объектная модель

Для того чтобы СУБД могла сохранять и восстанавливать состояние объектов, ей необходима некоторая информация (список переменных объекта и его методов), а также способность считывать и устанавливать значения переменных объекта, являющегося экземпляром любого класса. Также СУБД должна уметь самостоятельно создавать экземпляры произвольного класса и уничтожать их. Все эти дополнительные возможности – это и есть объектная модель. В некоторых языках программирования (например, в JAVA), объектная модель – неотъемлемая часть самого языка, в других (таких, как C++) язык не предоставляет таких возможностей и объектную модель приходится реализовывать на уровне библиотек.
Фактически, объектная модель – это иерархия классов, которые предоставляют весь необходимый сервис. Наиболее распространены сейчас следующие объектные модели: OMG Object Model (предлагаемая организацией Object Management Group) [9], Component Object Model (предлагаемая Microsoft), объектная модель языка JAVA (набор классов java.lang.* и java.lang.reflect.*) [2], иерархия классов библиотеки Visual Component Library (доступная из сред программирования Delphi и C++ Builder компании Inprise, известной ранее как Borland).

2.4. Языки программирования ООБД

Разработчики объектно-ориентированных СУБД стремятся сократить разрыв между традиционными языками программирования и СУБД. Есть два пути решения этой задачи: двигаться от языка программирования (встраивать в существующий язык средства общения с СУБД или же создавать новый с теми же возможностями) и, наоборот, двигаться от СУБД (оперировать на уровне библиотек).
Первый путь очень интересен. Он приводит к созданию фактически новых языков, в которых доступ к базе осуществляется максимально простым путём. Однако он сопряжен с большими затратами на создание своего транслятора, его поддержку (обеспечение совместимости с новыми стандартами на язык, на базе которого построен данный), переносом на другие платформы и т.д. Новый язык строится, как правило, на основе какого-либо из существующих объектно-ориентированных языков: Smalltalk, Java, C++, ObjectLisp, Modula, Oberon и т.д. Такой способ избрали, например, создатели Модула-90К [5].
Второй значительно проще из-за того, что он не требует затрат на создание своего транслятора. Зато обеспечивается возможность совместной работы с существующими и будущими версиями трансляторов сторонних производителей. Он не завязан на единственный язык программирования, а предоставляет выбор между некоторым количеством, обеспечивая возможность разработки модулей программы, работающих с одной и той же базой, на различных языках.
Наибольшее распространение получил второй подход, поэтому на нём остановимся подробнее. Традиционно язык программирования СУБД состоит из трех частей: язык описания данных, язык манипулирования данными и язык запросов.
Существует два способа задания структуры БД:

Описание создается сначала на каком-нибудь специальном языке (ODL в CORBA, IDL в COM), затем оно компилируется во внутренний формат СУБД и в модуль на языке программирования.
Описание создается сразу на языке программирования. Оно обрабатывается специальным препроцессором, который создает файл во внутреннем формате, воспринимаемый СУБД. В случае, когда язык специализированный, эта фаза совмещена с фазой компиляции программы и проходит незаметно для программиста.

И в том, и в другом случае, на выходе получаются два вида модулей: программные, в которых описание данных – это классы и структуры в терминах языка, и модули описания в формате СУБД (благодаря им она не связана с конкретным языком программирования).
Манипулирование данными кодируется непосредственно на целевом языке. В программах используются объекты и структуры, которые помещаются в базу данных, и для их хранения не требуется прикладывать особые усилия. Создатели объектных СУБД стараются максимально облегчить жизнь программисту, поэтому сохранение объектов обеспечивается прозрачным образом. Благодаря применению одного языка программирования для создания логики приложения, разработки интерфейса и общения с базой данных, прикладные программы могут быть выполнены с минимальными затратами средств и времени.
Запросы к базе разделяются на два вида и реализуются, соответственно, двумя способами:

Типовые запросы. Они известны на стадии проектирования системы и реализуются чаще всего с помощью вызовов функций навигации по базе (позиционирование с использованием индексов).
Незапланированные запросы. Необходимость в таких запросах появляется на стадии отладки системы и в процессе ее функционирования. Как правило, это единичные запросы, которые выполняются изредка и предназначены для сложного анализа данных, сбора статистики и т.д. Такие запросы реализуются с помощью полноценного языка запросов.

Существуют три подхода к построению языков запросов:

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

Независимо от подхода, применяемого для разработки языка запросов, перед разработчиками встает одна концептуальная проблема, решение которой не укладывается в традиционное русло объектно-ориентированного программирования. Понятно, что основой для формулирования запроса должен служить класс, представляющий в ООБД множество однотипных объектов. Но что может представлять собой результат запроса? Набор основных понятий объектно-ориентированного подхода не содержит подходящего к данному случаю понятия. Обычно из положения выходят, вводя концепцию множества объектов, и полагая, что результатом запроса является некоторое подмножество объектов-экземпляров класса. Это ограничительный подход, поскольку автоматически исключает возможность наличия в языке запросов средств, аналогичных реляционному оператору соединения.

2.5. Управление доступом

Во всех современных СУБД в той или иной мере встроена поддержка механизмов безопасности. Все они удовлетворяют стандарту (или близки к этому), описанному в «The Orange Book» [10]. Он описывает «действующих лиц» системы: пассивные объекты (защищаемая информация), активные субъекты (пользователи, которые хотят получить доступ к информации) и механизмы предоставления доступа («правила игры»). На сегодняшний день существует два вида таких механизмов:

обязательные. Каждому объекту присваивается метка (уровень доступа, «гриф секретности»). Каждому субъекту (обычно пользователю) при регистрации также присваивается метка. Механизм работает следующим образом - при обращении данного субъекта к конкретному объекту их метки сравниваются, и субъект либо получает разрешение, либо ему отказывают в доступе. Если метка - это «гриф секретности», то сравнение состоит просто в операции «больше или равно».
избирательные. Для каждого класса объектов создается список действий, которые субъект потенциально может выполнить над ними. Каждому объекту в системе приписывают список доступа (Access Control List), в котором каждому субъекту приписан список действий, которые он может совершить с данным объектом. При выполнении каждого такого действия система проверяет, есть ли пара «данный субъект – данное действие» в списке. По результатам проверки действие либо разрешается, либо отвергается.

Очевидно, что первый из этих двух методов обладает значительно меньшими накладными расходами, а второй существенно более гибкий. Поэтому в современных системах чаще всего применяется именно избирательное управление доступом. Однако для ускорения работы подсистемы безопасности, разработчики базы зачастую создают неизменный список достаточно обобщенных действий. Такой подход недостаточно гибок, и пользоваться им неудобно.

2.6. Другие методы хранения информации. СУБД Ника.

В настоящее время наибольшее распространение получили реляционные СУБД. Однако существуют также системы, относящиеся к так называемой «дореляционной эпохе». Это иерархические и сетевые СУБД. Они практически вытеснены с коммерческого рынка реляционными системами, однако существуют несколько удачных реализаций. К ним относится иерархическая СУБД Ника [6].
Ника является оригинальной отечественной разработкой, при ее создании использовался опыт разработки и массового внедрения системы ИНЕС [4]. Ника имеет богатое окружение и поставляется в виде набора программных продуктов, основными из которых являются конструктор схемы БД, редактор БД и библиотеки функций для создания прикладных программ. Программное обеспечение системы открыто пользователю на всех уровнях, отдельные ее части могут использоваться независимо от других.
СУБД Ника позволяет работать со сколь угодно сложными (иерархическими) объектами, имеющими произвольные (сетевые) связи. База данных состоит из двух файлов – файла описания данных и файла данных. Каждый из них представляет собой простое дерево. Рассмотрим его подробнее.
Основной способ хранения информации в Нике – простое дерево (метод доступа TREE). Он позволяет работать с данными, имеющими иерархическую структуру. Никаких ограничений на глубину иерархии и количество вершин не накладывается. Единственное ограничение – объем памяти на диске. Основное понятие системы TREE – вершина. Вершина состоит из ключа, идентифицирующего эту вершину, и данного. Данное может быть либо простым (целое или вещественное число, текст, бинарное данное), либо составным (последовательность вершин, подчиненных данной).
Размещение информации на диске организовано следующим образом: файл состоит из отдельных страниц, которые образуют иерархическую структуру. Дерево страниц согласовано с деревом данных в следующем смысле: всякое поддерево исходного дерева хранится в некотором поддереве дерева страниц. Такая организация обеспечивает физическую кластеризацию данных – вершины, расположенные в непосредственной близости друг от друга (например, на одном уровне или одна в подчинении у другой) с большой вероятностью окажутся в одном блоке и в файле. Это существенно уменьшает количество обращений к диску и повышает скорость работы прикладных программ.
Ника позволяет работать с базой данных не только как с целым (схемой и данным), но и использовать метод доступа TREE отдельно. Это позволяет использовать его независимо от СУБД Ника, например, для создания других СУБД.
Существует сетевая версия СУБД Ника. Она обеспечивает работу в режиме клиент/сервер. Возможен доступ к удаленным файлам как в режиме базы данных, так и с помощью метода TREE. Для поддержки целостности используется механизм транзакций. Одновременно может быть открыто сколь угодно много транзакций на чтение или одна транзакция на запись.
В систему включены утилиты для проверки целостности, упаковки БД, редактор схемы и самой БД.
Недостатками Ники являются:

Отсутствие параллельных транзакций на запись.
Отсутствие встроенных средств безопасности.
Отсутствие языка запросов.

3. Положение в данной области

3.1. Стандарты

В современных технологиях без стандартов не обойтись, особенно разработчикам приложений. Не составляют исключения и технологии объектных СУБД. Поэтому в 1992 г. ведущие разработчики объектных СУБД образовали группу ODMG (Object Database Management Group) по выработке и согласованию стандартов. Специфика ее деятельности заключается не в создании новых стандартов, а в развитии уже существующих в OMG (Object Management Group ANSI, группа выработки стандартов объектного программирования) и разработке порядка их использования для достижения совместимости конечных прикладных программ с интерфейсом любой объектной СУБД. К настоящему времени выработаны стандарты языка описания объектов ODL (Object Definition Language), языка запросов OQL (Object Query Language), дополнения языков программирования C++, Smalltalk, Java.
Объектная модель, установленная ODMG, базируется на модели группы OMG, созданной несколькими годами ранее. В дополнение к известным объектным концепциям в новом стандарте предложены расширения для обмена с базой данных, например, вводятся понятия транзакций, отношений между объектами. Язык описания объектов ODL, являющийся расширением языка определения интерфейсов IDL (Interface Definition Language), предназначен только для описания интерфейса объекта с внешним миром, а реализацию базы он никак не затрагивает и не ограничивает. Следует иметь в виду, что IDL принят в качестве стандарта описания объектных интерфейсов в CORBA. Язык запросов OQL включает объектное расширение языка SQL-92 таким образом, что большинство запросов, адресованных реляционной СУБД, будут выполняться и в объектных базах данных. Стандарт ODMG осуществляет поддержку операций над стабильными объектами, помогает встраивать в программы на C++, Smalltalk, Java выражения на языке OQL и содержит средства управления транзакциями и средства навигации по объектам базы данных.
Прямым конкурентом OMG является фирма Microsoft, разработавшая собственную объектную модель Component Object Model. COM не является стандартом в том смысле, что ее развитием и продвижением на рынке занимается единственная компания, а не консорциум. Она не обладает той многоплатформенностью, которая изначально заложена в CORBA, а рассчитана почти исключительно на рынок, где главенствующее положение занимают операционные системы семейства Windows. Она поставляется со всеми современными версиями ОС этого семейства, причем часть модулей Windows написаны с её привлечением. Благодаря такой тесной интеграции с операционной системой COM является стандартом де-факто на этом рынке. Многие разработчики прибегают к этой модели как к средству построения модульных программ, способных интегрироваться с другими системами.
COM является языково-нейтральным стандартом. В нем присутствуют механизмы совместной работы с динамически распределяемой памятью, сборка мусора (методом подсчета ссылок), язык описания данных (Interface Definition Language – IDL, не путать с одноименным языком OMG), а также большой набор интерфейсов. Существует версия COM, предназначенная для распределенной работы – DCOM (Distributed COM).

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

3.2. Существующие реализации

Ниже представлена таблица ([7]), в которой кратко описаны существующие коммерческие объектно-ориентированные СУБД (объектно-реляционные намеренно опущены).

	Разработчик	СУБД	Языки
1	Objectivity/DB www.objy.com	Objectivity 5.0	C++, Java, Smalltalk
	Компания добилась успехов в области автоматизации предприятий и использования ее СУБД в сфере науки. Например, она установлена в CERN (Швейцария) для накопления данных о результатах экспериментов на ускорителе элементарных частиц.
2	Ontos, Inc. www.ontos.com	Ontos DB 2.5	C++, Visual Basic, Java
	Предлагает технологии для накопления данных на предприятии. Разработчики Ontos делают особый акцент на идеальной поддержке данных реляционных баз
3	Versant Object Technology www.versant.com	Versant, Release 5	C++, Java, Smalltalk
	В отличие от других производителей объектных СУБД фирма декларирует основное направление своей деятельности в сфере телекоммуникаций, транспорта и автоматизации предприятий, создания баз данных в распределенных средах. В СУБД Versant имеются средства, необходимые для функционирования в сетях Internet/intranet.
4	Object Design, Inc. www.odi.com	ObjectStore 5.0	C++, Java
	Имеет несколько вариантов СУБД ObjectStore от демонстрационного до полномасштабного комплекса программ, позволяющего разработчику и пользователю обращаться к разнообразным средствам конфигурирования, управления и создания прикладных программ. Наряду со средой разработки программ поддерживает любой компилятор C++, удовлетворяющий стандарту ANSI. Netscape использует облегченную версию для хранения кеша браузера Navigator 4.x
5	Gemstone, Inc. www.gemstone.com	Gemstone 5.0	Smalltalk, Java
	Одна из первых коммерческих СУБД, в которой идея объектной системы наиболее полно реализована. В самой базе данных хранятся атрибуты объекта и методы, т. е. для выполнения программы нужно передавать все объекты на клиентское место. Программа-клиент может послать серверу код сообщения, который вызовет загрузку объекта в пространство адресов сервера и выполнение задания там же. Язык СУБД – расширение Smalltalk.
6	Poet Software GmbH www.poet.com	Poet 5.0	C++, Java, Visual Basic
	СУБД Poet компактна: ядро базы данных занимает около 1 Мбайт. Рекомендуется использование в среде Windows, Windows NT. Имеет собственную среду разработки и средства стыковки интерфейса базы с компиляторами C++ компаний Borland и Microsoft. Программный интерфейс поддерживает языки Java, Visual Basic и Active/X-элементы.
7	Ardent Software http://www.ardentsoftware.com/database/object/	O2 5.0	C++, Java, Smalltalk
	Предлагает богатый инструментарий для создания приложений и администрирования базы данных. СУБД О2 предназначена для разработчиков, сделавших выбор в пользу C++ и Java. Имеются оптимизатор запросов к базе данных, система управления версиями объектов, возможность подключения реляционных банков данных, поддерживаются стандарты ODBC, CORBA и связь через Internet.
8	Ibex Object Systems http://www.ibex.ch/	Itasca 5.0	Lisp, CLOS, C++, C
	Объектная СУБД Itasca – наследница проекта Orion, существовавшего с 1985 по 1989 г. В качестве демо-версии предлагается полномасштабная версия с ограниченным временем использования. Языки программирования базы – ObjectLisp, CLOS, C++. На основе использования СУБД Itasca компания Ibex Object Systems работает в области системной интеграции, предлагая клиент/серверные решения, построенные по трехуровневой схеме, что позволяет создавать новые приложения, интегрирующие уже существующие, а также накопленные данные. Ibex поставляет удобные и мощные средства управления и конфигурирования для баз данных.
9	UniSQL, Inc. www.unisql.com	UniSQL 3.2	ANSI C, Smalltalk, Microsoft Visual C
	Компанию возглавляет авторитетный специалист Вон Ким, принимавший участие в ряде крупных проектов по созданию реляционных и объектных СУБД.
10	Computer Associates, Inc. www.cai.com	Jasmine 1.1	C++, C, Visual Basic
	СУБД Jasmine вобрала в себя опыт предыдущих работ, включив много необходимого для объектного программирования. Как коммерческий продукт имеет максимальный потенциал на рынке СУБД. Она снабжена визуальной средой разработки JADE, отличающейся продуманным, удобным и интуитивно понятным интерфейсом.
11	НПЦ "Интелтек Плюс" www.inteltec.ru	ODB Jupiter 2.1	C++
	Отечественная коммерческая объектная СУБД, обладающая рядом интересных особенностей, например, в ней интегрирована библиотека индексации и обработки поисковых запросов на естественном языке. База ODB Jupiter не требовательна к ресурсам, вполне приемлемо сервер работает на компьютере с процессором 80386 и 8 Мбайт памяти.

4. Цель данной работы

Цель данной работы состоит в создании системы хранения объектов, обладающей следующими преимуществами перед существующими СУБД:

Возможность одновременного храненения в БД экземпляров классов разных версий.
Возможность строить приложения из отдельных компонент – различные классы могут разрабатываться разными людьми на разных машинах, в составе разных проектов. После инсталляции на клиентской машине все они автоматически приобретают возможность сохраняться в базу данных.
Возможность хранения в БД классов, которых не существовало на момент написания прикладной программы.
Возможность хранения в базе существующих COM-объектов.
Наличие интерфейса с языками программирования C++, Visual Basic, Pascal with Objects (Delphi), Java и другими, имеющими интерфейс с COM.
Расширяемость подсистемы физического доступа к данным – возможно использование различных иерархических хранилищ (реализованы модули над Никой и реестром Windows).

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

5. Реализация среды хранения объектов

5.1. Объектная модель

В качестве объектной модели выбрана Microsoft COM, т.к. она является наиболее распространенной на платформе Windows.
Важной особенностью COM является возможность получать информацию о внутренней структуре класса через интерфейсы IDispatch, ITypeInfo, IProvideClassInfo. Эти интерфейсы используются следующим образом:

IProvideClassInfo – обеспечивает идентификацию класса, экземпляром которого является данный объект.
GetClassInfo – возвращает CLSID – глобальный идентификатор класса.
IDispatch – интерфейс, предоставляющий доступ ко внутренней структуре класса.
GetTypeInfo – возвращает описатель класса (ITypeInfo)
Invoke – позволяет прочитать/установить значения свойств.
ITypeInfo – интерфейс, обеспечивающий некоторую информацию о классе.
GetTypeAttr – выдает (в том числе) количество свойств.
GetFuncDesc – выдает описание функций и свойств (количество параметров, тип результата и т.д.)

5.2. Методы сохранения стандартных COM-объектов

Для сохранения объектов используются стандартные интерфейсы IDispatch, IPersistStream, IPersistStorage, IPersistPropertyBag.
IPersistStream, IPersistStorage, IPersistPropertyBag являются надежными в том смысле, что если объект реализует какой-либо из них, то он гарантирует свою способность сохранять свое состояние и восстанавливать его из IStream, IStorage или IPropertyBag. Следует отметить, что из этих трех интерфейсов самыми необходимыми являются IPersistStream и IPersistStorage, т.к. они является самым распространенными.

Недостатком IPersistStream и IPersistStorage является то, что объект сохраняется целиком, и при этом нет возможности просмотреть или исправить его внутреннюю структуру.

Более предпочтительный вариант – IDispatch. Он позволяет сохранять в базе структуру объектов, открывает возможности для прозрачного хранения ссылок и рекурсивных структур. Однако для корректного использования IDispatch COM-класс должен обладать таким свойством: состояние объекта – это совокупное состояние всех его свойств. Т.е. не каждый объект, реализующий IDispatch, окажется после восстановления из БД в том же состоянии, что и перед сохранением в нее. Это серьезная проблема, но есть частичное решение: интерфейс IDispatch проверяется в последнюю очередь (после IPersistObject, IPersistStorage, IPersistStream, IPersistPropertyBag). Следует отметить, что если объект не реализует ни одного IPersist-интерфейса, а реализует лишь IDispatch и, при этом, не выполняется сформулированное выше свойство, то такой объект не может быть сохранен в БД.

5.3. Организация ссылок

Объект, на который имеется ровно одна ссылка, сохраняется в дереве непосредственно под объектом, который на него ссылается.

Сохранение объекта, на который имеется более чем одна ссылка, происходит следующим образом: он сохраняется под одним из объектов, который на него ссылается, а под остальными объектами «подвешиваются» ссылки. Выбор выделенного объекта осуществляется простым способом - это первый в последовательности сохранения.

Несмотря на простоту, такая схема достаточно эффективна, т.к. чаще всего объект «сильно» связан только с одним объектом, и «слабо» - с остальными (обычно это ссылки из индексов). При этом обеспечивается физическая кластеризация (объект хранится в непосредственной близости от того объекта, с которым он сильно связан), что положительно сказывается на времени доступа как при чтении, так и при записи.

5.4. Доступ к рекурсивным структурам. Загрузка по требованию.

До тех пор, пока все поля объекта являются экземплярами простых типов, загрузку объекта из БД можно производить последовательной загрузкой всех его полей. Если же одним из полей является объект, то его загрузка может привести к попытке загрузить в память значительную часть (или даже всю) БД и, в конечном итоге, к краху системы по причине нехватки оперативной памяти. Решение этой проблемы состоит в том, чтобы не загружать подобъект сразу, а отложить эту операцию до момента, когда он действительно потребуется. Если же он не вообще не будет востребован, то никаких лишних операций выполнено не будет. Этот механизм называется загрузка по требованию.
Загрузка по требованию реализуется следующим образом: в библиотеке есть класс-посредник PDS.OnDemandDispatch, реализующий IDispatch. В процессе загрузки из БД создается экземпляр класса PDS.OnDemandDispatch, и он отдается пользователю вместо настоящего объекта. При этом посредник запоминает вершину в БД, в которой лежит настоящий объект. И лишь когда произойдет реальное обращение к данным (метод Invoke), посредник загрузит настоящий объект из базы и передаст управление его методу Invoke.

5.5. Хранение неограниченных массивов.

Для хранения неограниченных массивов введена дополнительная структура данных – класс PDS.SimpleUnlimitedArray. Это ключевой массив, в котором в качестве ключа может выступать только простое данное (целое, вещественное, булевское, строка), а в качестве данного – любой COM-объект. Этот объект может включать в себя произвольную иерархию подобъектов, а также другие объекты типа PDS.SimpleUnlimitedArray. Элементы массива всегда загружаются только при обращении к ним, т.е. массив может состоять из большого количества элементов, общий объем которых может многократно превышать объем оперативной памяти.

5.6. Методы сохранения «своих» объектов

Все объекты, которые «знают» о существовании СУБД, реализуют интерфейс IPersistObject. Они могут делать это полностью самостоятельно или с помощью агрегации класса PDS.PersistObject.

5.7. Схема БД

В данной системе фактически не существует «схемы базы данных» в классическом понимании этого термина. Описания COM-классов хранятся в библиотеках вместе с программным кодом самих классов. То есть схема – это совокупность описаний, находящихся во всех библиотеках (являющихся COM-серверами), проинсталлированных на данном компьютере. А в базе хранятся лишь данные экземпляров. При этом объект любого типа можно сохранить в любую точку базы. Данные сохраняются вместе с информацией о классе, позволяющей в последствии восстановить объект.
Запись в БД происходит следующим образом: в базу помещается идентификатор COM-класса (ProgID), экземпляром которого является данный объект, и данные объекта. В случае IPersistStream это бинарные данные, IPersistStorage – иерархия бинарных данных, IDispatch – список свойств с их идентификаторами и значениями. Для получения этих списков используется описание данных COM (доступное в TypeLibrary).
При таком подходе существенно облегчается процесс разработки большого приложения. Каждый программист работает со своими модулями (COM-классами), фактически это «подсхема» всей базы данных. В процессе сборки компоненты переносятся на одну машину, и все они автоматически приобретают возможность сохраняться в общую базу программы. Процесс разработки сложных систем (в котором участвуют несколько человек) существенно упрощается благодаря распараллеливанию. При этом благодаря большей модульности повышается качество программ и скорость их разработки.
Кроме того, появляется возможность сохранять в БД классы, которых не существовало на момент написания прикладной программы. Это очень актуально в настоящее время, когда все больше и больше разработчиков создают расширяемые пакеты прикладных программ. В таких системах существует возможность разрабатывать дополнения (Extensions или Plugins), которые создаются независимыми производителями программного обеспечения и распространяются отдельно от самого продукта. Эти дополнения тесно взаимодействуют с основной программой, в частности, они могут оперировать со своими собственными данными, которые необходимо сохранять в базу данных. Применение данной разработки позволяет построить систему так, чтобы о хранении объектов заботилась основная программа, а не дополнения к ней.

5.8. Версии классов

Идентификатор класса (ProgID) состоит из двух частей – собственно имя класса и его версия. Такая структура позволяет одновременно хранить в базе экземпляры разных версий одного и того же класса. При этом сам класс должен поддерживать совместимость «снизу вверх». Это позволит производить конвертацию лишь при необходимости (если точнее, то при операции «открыть экземпляр, созданный старой версией класса» - «изменить его» - «сохранить»).
Например, на одной машине установлен Microsoft Word 95. С его помощью был создан документ и сохранен в базе. Этот документ – экземпляр класса Word.Document.6. На другой машине установлен Microsoft Word 97. С его помощью был создан второй документ и также сохранен в базе. Этот документ – экземпляр класса Word.Document.8. Два документа одновременно находятся в одном и том же хранилище и не противоречат друг другу. Если со второй машины кто-то попытается открыть первый документ, то он успешно это сделает (т.к. Microsoft Word поддерживает совместимость «снизу вверх»). Если же, наоборот, с первой машины попытаться открыть второй документ, то это закончится неудачей, т.к. совместимость «сверху вниз» обычно не обеспечивают (хотя в случае Microsoft Word существует специальный конвертор, который позволит это сделать; но это все же исключение из правила).

5.9. Клиент/серверный режим

Среда хранения объектов имеет слоеную архитектуру (подробнее см. «6.2. Классы и их взаимоотношения»). Принципиально система может работать с разными типами хранилищ. Механизмы работы с конкретным хранилищем обеспечиваются нижним слоем (например, Никой). Система не имеет четких представлений о том, является ли она посредником при работе с удаленной или локальной базой. Основным хранилищем системы является Ника, а она обеспечивает работу в режиме клиент/сервер, поэтому при работе с ней и сама система становится клиент/серверной.

5.10. Блокировки

Заблокировать можно только объекты, реализующие IPersistObject. Фактическую блокировку осуществляет нижний слой системы (подробнее см. «6.2. Классы и их взаимоотношения»). В случае Ники используются возможности, предоставляемые Ника-сервером.

6. Описание библиотеки классов для программного доступа к системе хранения объектов

Среда хранения объектов состоит из нескольких модулей:

Библиотека COM-классов, являющаяся программным интерфейсом к системе.
Сервер НИКИ.
Сервисные утилиты.

В настоящее время в качестве сервисных утилит используются программы НИКИ:

Название	Описание
nk.exe	Используется в качестве редактора БД. Он имеет существенный недостаток: показывает фактически внутренний формат, в котором хранятся объекты. Это чревато тем, что можно случайно исправить файл БД таким образом, что он уже не будет корректным с точки зрения системы. В будущем предполагается написать собственную программу, которая обеспечивала бы просмотр/редактирование базы в виде объектов.
nkchk.exe	Проверяет целостность файла БД с точки зрения Ники. Это недостаточная проверка, т.к. программа не обнаруживает нарушений целостности файла в смысле базы данных среды хранения объектов (целостности служебной информации и ссылочной целостности). В будущем планируется написать утилиту, которая будет осуществлять полноценную проверку.
nkpack.exe	Упаковывает файл БД. Упаковка происходит за счет удаления внутренней фрагментации, присущей любому файлу с деревом Ники.

6.1. Требования к COM-объектам

Для того чтобы система могла сохранить данный COM-объект в базу, он должен реализовать хотя бы один из интерфейсов:

IPersistObject
IPersistStorage
IPersistStream
IDispatch (с учетом ограничения, оговоренного в пункте «5.2. Методы сохранения стандартных COM-объектов»).

6.2. Классы и их взаимоотношения

Все классы библиотеки разбиты на три группы.

Программист, использующий библиотеку, работает с верхним уровнем (за исключением класса - наследника BackEndDescription, который описывает параметры конкретного хранилища).

Средний уровень – абстрактные классы, описывающие некоторое хранилище.

Нижний уровень – конкретная реализация хранилища.

FrontEnd

Верхний слой, с которым работает клиент

TransactionManager

Менеджер транзакций

SimpleUnlimitedArray

Неограниченный ключевой массив

EnumArrayItem

Итератор по элементам SimpleUnlimitedArray

…

Другие сервисные классы

BackEnd

Абстрактное хранилище

BackEndCursor

Курсор в BackEnd

BackEndDescription

Класс, описывающий параметры BackEnd

NikaBackEnd

Хранилище на базе НИКИ

RegistryBackEnd

Хранилище на базе реестра Windows

…

Другие хранилища

7. Реализованные хранилища нижнего уровня

7.1. Хранилище над реестром Windows

Класс называется PDS.RegistryBackEnd. Он сохраняет данные в реестре Windows под ключом с заданным именем, что позволяет использовать систему для удобного хранения настроек программ (settings).
IRegistryBackEndDescription – описатель параметров подключения к реестру.

Свойства:

Имя	Тип	Описание
KeyName	BSTR	Название ключа в реестре. Полный путь к ключу следующий: HKEY_CURRENT_USER\Software\KeyName

7.2. Хранилище над Никой.

Класс называется PDS.NikaBackEnd. Это основное хранилище, которое используется в библиотеке. В качестве метода доступе используется простое дерево (TREE). Выбор именно простого дерева, а не полноценной СУБД Ника (метод доступа ACCESS) объясняется следующими причинами:

Информация о внутренней структуре классов (имена полей, их идентификаторы, типы, и т.д.) уже содержится в библиотеке типов (TypeLibrary) и нет смысла дублировать её в базе. Т.е. необходимость в схеме полностью отпадает.
Ссылки Ники недостаточно гибкие (невозможно создать ссылку на произвольную вершину в базе).
Использовать дополнительные типы данных, предоставляемых ACCESS, нецелесообразно, т.к. хранятся лишь типы, описываемые через VARIANT.
Индексы только глобальные (нельзя сделать массив в массиве так, чтобы в каждом внешнем массиве был индекс на элементы внутреннего массива).

INikaBackEndDescription – описатель параметров подключения к базе.

Свойства:

Имя	Тип	Описание
ServerName	BSTR	Название сервера. Если NULL, то локальная база. Если «LOCAL», то локальный сервер (для совместной работы с одной базой из нескольких процессов).
FileName	BSTR	Путь к файлу (если указан ServerName, то на сервере, если нет, то локальный).

8. Исследование скоростных характеристик

Целью данного исследования является измерение основных скоростных показателей данной разработки и их сравнение с аналогичными показателями других СУБД.
В сравнительном анализе участвовали следующие программы:

Access 97
Interbase 5.0
POET 5.0.1
Данная разработка (на графиках обозначена PDS)

Работа проводилась с базами данных, имеющими следующую структуру:

Объектно-ориентированные – БД состоит из коллекции однотипных объектов. Каждый объект имеет десять переменных-членов:

Название	Тип
I1	INTEGER
I2	INTEGER
I3	INTEGER
I4	INTEGER
S1	STRING
S2	STRING
S3	STRING
S4	STRING
F1	FLOAT
F2	FLOAT

При занесении в коллекцию строится индекс по переменной I1. В последствии выполняется поиск по этой же переменной.
Реляционные – БД состоит из одной таблицы, которая, в свою очередь, состоит из 10 полей, описанных выше. Поле I1 является первичным ключем в таблице.
Программа тестирования состояла из трех задач:

Заполнение базы данных.
Последовательная выборка всей базы.
Выборка с произвольным доступом.

Исследование проводилось на компьютере следующей конфигурации:

Процессор	Intel Pentium II/233
Оперативная память	64 Мб
Жесткий диск	3 Гб
Операционная система	Windows NT 4.0

Результаты тестирования представлены на графиках:

База данных из 80000 записей занимала следующий объем:

СУБД	Объем БД, Мб
Access	18
Interbase	23
Poet	14
PDS	14

На графиках видно, что на основных тестах (запись в БД и произвольная выборка данных - самая частая операция в реальных задачах) данная разработка опережает как объектно-ориентированную СУБД POET, так и реляционные ACCESS и INTERBASE.

9. Перспективы развития

Автоматическое построение индексов

В систему будет встроена возможность создания индексов на массивы объектов, реализующих IDispatch. В индексы будут автоматически заноситься ссылки на оригинальные объекты.

Управление доступом

Все механизмы управления доступом будут реализованы в виде отдельной библиотеки, состоящей из нескольких COM-классов. Субъектами будут являться пользователи Windows NT, объектами – все COM-объекты, реализующие IPersistObject.

Транзакции

Недостатком Ники является отсутствие параллельных транзакций на запись. Предлагается исправить этот недостаток собственной надстройкой над Никой, которая обеспечивала бы возможность многовариантной блокировки: одновременно выполняются сколь угодно много транзакций на чтение и сколь угодно много непересекающихся транзакций на запись (которые не «трогают» одни и те же данные) [3].

Шифрование

Планируется встроить механизмы шифрования данных как при хранении, так и при передаче по сети (в клиент/серверном режиме).

Языки запросов

Планируется реализовать подмножество языка OQL (Object Query Language).

Заключение

В данной работе создана принципиально новая среда хранения объектов, которая в дальнейшем будет развиваться до полноценной объектно-ориентированной СУБД.
Преимущества перед СУБД, построенными на других моделях:

Возможность одновременного хранения в БД экземпляров классов разных версий.
Возможность строить приложения из модулей.
Возможность хранения в БД классов, которых не существовало на момент написания прикладной программы.
Возможность хранения в базе существующих COM-объектов.
Наличие интерфейса с языками C++, Visual Basic, Pascal with Objects (Delphi), Java и другими, имеющими интерфейс с COM.
Интеграция с COM (позволяет легко взаимодействовать с существующими приложениями под Windows).
Отсутствует преобразование данных при передаче в/из БД.
Возможность определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании данных со сложной структурой. В будущем эти операции могут быть использованы при запросах к БД.

Преимущества перед реляционными СУБД:

Естественное представление данных со сложной структурой.
Высокоскоростной доступ к данным.

Преимущества перед «чистой» Никой:

Отсутствие преобразования данных в типы Ники и обратно.
Обработка ошибок с помощью исключительных ситуаций (без применения кодов ошибок).
Потокозащищенность (multi-threading).
Наличие встроенного механизма для совместной работы с локальной базой из нескольких процессов.

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

Список литературы

Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Пер. с англ. М.: Бином; СПб.: Невский диалект, 1998.
Гарольд Э. Р. Java Beans / Пер. с англ. М.: Лори, 1999.
Дейт К. Дж. Введение в системы баз данных / Пер. с англ. 6-е изд. К.: Диалектика, 1998.
Емельянов Н. Е. Введение в СУБД ИНЕС. М.: Наука, гл. ред. физ.-мат. лит., 1998.
Система программирования баз данных Модула-90К / Лютый В. Г., Мерков А. Б., Леонтьев Ю. В. и др. М.: ВЦ РАН, 1994.
Системы управления базами данных и знаний: Справ. изд. / А. Н. Наумов, А. М. Вендров, В. К. Иванов и др.; Под ред. А.Н. Наумова. М.: Финансы и статистика, 1991.
Среда и хранилище: ООБД / Андреев А.М., Березкин Д.В., Кантонистов Ю.А. // Мир ПК, 1998, № 4, С. 74-81.
Grasshopper: An Orthogonally Persistent Operating System / Dearle A., Bona R., Farrow J. and others. // Computing Systems, 7(3), pp 289-312, Summer 1994.
Sessions R. Object Persistence beyond object-oriented databases / Upper Saddle River, N.J.: Prentice Hall, 1996.
The Orange Book. Department of Defense standard, DoD 5200.28-STD, December 1985.

- -