За время существования баз данных накоплено огромное количество информации. Разработано огромное количество приложений для работы с базами данных. Это привело к появлению двух конкурирующих концепций архитектур постреляционных СУБД:
1. Объектно-реляционные базы данных
2. Объектно-ориентированные базы данных
Объектно-реляционные базы данных представляют собой реляционные базы данных, дополненные надстройкой, представляющей эти данные как объекты. Все по-прежнему хранится в виде таблиц. Этот подход позволяет плавно перейти от технологии хранилища таблиц к технологии хранилища объектов. Остается возможность выборки данных с помощью SQL-запросов. Сам SQL расширен командами работы с объектами. Наиболее известным продуктом, в котором реализован подобный подход является Oracle ver.8. Комитет ANSI X3H2, разработавший стандарт SQL–92, сейчас работает над SQL3. Основными усовершенствованиями в SQL3 должны стать возможность процедурного доступа наравне с декларативным и поддержка объектов. Основным недостатком объектно-реляционных СУБД является необходимость разбирать объекты для размещения их в таблицах и собирать их для передачи пользователю из таблиц [2].
Объектно-ориентированные базы данных хранят объекты целиком. Для выборки объектов с помощью запросов разрабатывается язык OQL (Object Query Language), в который был включен стандарт SQL'92. Единство описания структуры БД достигается применением языка определения объектов ODL (Object Definition Language), предложенного ODMG (Object Database Management Group), являющегося расширением языка IDL. Эти виды баз данных обладают высокой производительностью, часто в несколько раз более высокой, чем реляционные базы данных. Наиболее известными ООСУБД являются Jasmine, ObjectStore и POET.
Из отечественных разработок в области постреляционных баз данных достоверно известно лишь о существовании ООСУБД ODB-Jupiter. Похоже, она была написана специально для создания продукта ODB-Text. По крайней мере, ни о каких других приложениях написанных на ODB-Jupiter ничего не известно. Также в Internet было обнаружено описание некой отечественной объектно-ориентированной базы данных версии 1.2. Точнее, это был модуль, предоставляющий функции объектно-ориентированной СУБД. Документ даже не имел названия. В нем детально рассматривалась организация хранения данных и принцип работы. Похоже, разработка обосновывалась лишь на принципах, которым должна удовлетворять СУООБД. Наиболее интересная идея: назначение строкам уникальных идентификаторов и удаление строк только при упаковке базы. Это дает существенный выигрыш в сравнении строк, так как объекты-строки с одинаковым содержанием имеют одинаковые идентификаторы.
Постреляционные базы данных вобрали в себя все лучшие черты иерархических, сетевых и реляционных баз данных.
Хотя существуют некоторые сходства, как, например, использование указателей и вложенная структура записей в сетевой модели. Однако надо отметить, что СУООБД используют логические указатели для обеспечения целостности, а также поддерживают иерархию классов, наследование и методы. Таких средств нет в иерархических и сетевых моделях [4].
Реляционные СУБД, идеально соответствующие своему назначению в традиционных областях применения баз данных, — банковское дело, системы резервирования и т.д. — в данном случае оказываются неудобными и неэффективными по многим причинам. Основное требование реляционной модели — нормализация — в случае сложноструктурированных данных с многочисленными взаимосвязями приводит к сложным запросам с соединением таблиц. То есть к тому, к чему реляционные СУБД не приспособлены, поскольку не могут обеспечить высокую производительность, требуемую интерактивным системам.
Производительность реляционных СУБД в таких случаях может уступать СУООБД во много раз. Кроме того, приложения развиваются, и число таблиц увеличивается. Небольшое изменение в организации данных может привести к необходимости изменить исходные тексты программы. При этом вносятся дополнительные ошибки. Объектно-ориентированные языки БД позволяют достичь того же результата локальными изменениями в свойствах и методах интересующих объектов. Кроме того, методы работы с объектами хранятся в базе вместе с объектами.
Значительная часть этой дипломной работы основывается на двух математических моделях.
Модель [17] замечательна тем, что не только описывает что представляют из себя объекты и как они взаимодействуют между собой, но и является замкнутой, самодостаточной. Она позволяет описать качественно новый вид взаимодействия в объектно-ориентированной системе: алгебру объектов. Эта алгебра является по своей сущности и важности аналогом реляционной алгебры в теории реляционных баз данных. В этой алгебре объектов определяется что представляют из себя такие операции, как селекция, проекция и другие хорошо известные из теории реляционных баз данных операции. Таким образом, эта модель объединяет два способа получения информации: посылка сообщения объекту (что типично для объектно-ориентированного программирования) и выполнение запроса над совокупностью хранимых данных (что типично для реляционных баз данных).
Эта модель [19] также оказала значительное влияние на данную работу, поскольку дополнила собой модель представления данных. Ни одна современная система управления базой данных не может обойтись без подсистемы транзакций. Природа транзакций в таких приложениях, как CAD, мультимедийные базы данных, является весьма различной. Эти приложения характеризуются совместно выполняемыми продолжительными транзакциями с произвольными операциями. У продолжительных пользовательских транзакций время выполнения может быть растянуто на часы, а то и дни. Это условие приводит к тому, что хорошо известный, и ставший уже классическим для традиционных баз данных, критерий сериализуемости становится неприменим непосредственно.
О самом критерии сериализуемости и способах реализации механизма транзакций достаточно подробно изложено в [9] и [22].
Механизм согласованного управления позволяет повысить производительность СУООБД за счет составления расписания выполнения транзакций, в том числе продолжительных, предоставляет транзакциям использовать промежуточные результаты других транзакций, учитывает объектную ориентированность данных и допускает обобщение операций (не только чтение и запись).
В статье [20] излагается довольно интересная точка зрения на состояние объектно-ориентированного программирования, а также рассказывается о применении несколько отличного от традиций объектно-ориентированного программирования подхода. В частности, наследование реализуется с помощью механизмов включения и делегирования. Это позволяет решить проблему множественного наследования. Вводится понятие фильтров, представляющих собой продукции, которые могут обрабатывать входящие сообщения и даже перенаправлять их на другие объекты, сохраняя в теле этих сообщений ссылку на первоначальный объект, к которому было послано сообщение. Причем, фильтры могут реагировать не только на входящие, но и на исходящие от объекта сообщения.
Принципы журнализации заимствованы из системы POSTGRES [23] и [15].
Принципы кэширования взяты из [1].
Было решено реализовывать прототип СУООБД на ДССП. ДССП – диалоговая система структурного программирования – была разработана в 1980 году Н.П.Брусенцовым в МГУ [5]. Система имеет под собой теоретическое обоснование. Принцип ДССП «Слово есть слово», т.е. одно слово программы соответствует одному слову кода. Принципы управляющих конструкций наследуются от троичной вычислительной машины Сетунь-70, имевшей память на магнитных сердечниках. Словарь и обозначения – от языка Ч.Мура Forth. ДССП превосходит Forth по многим параметрам. Язык ДССП обладает существенно более низкой, чем язык ассемблера трудоемкостью в программировании, не уступая ему в компактности кода и быстродействии, позволяет проверять работу подпрограмм в интерактивном режиме и имеет возможность модификации программ практически без внесения изменений в остальные части кода.
Основные черты ДССП:
· Двухстековая архитектура
· Обратная польская запись
· Словари
· Поддержка нисходящего программирования
· Встроенный отладчик с рекомпиляцией
· Высокоуровневые структуры данных и операции
· Высокоуровневый механизм программных прерываний и исключительных ситуаций
· Компактный код
· Гибкость, мобильность, наращиваемость
· Наличие сопрограммного механизма
К сожалению, при всех этих достоинствах, ДССП на данный момент является только системой программирования. Она не предоставляет сервис СУБД и не взаимодействует ни с одной СУБД. Данная работа направлена на то, чтобы обеспечить ДССП возможность обрабатывать данные в качестве СУБД, создав тем самым дешевый (Jasmine стоит порядка $15000), но эффективный инструмент, способный работать даже в самых непритязательных условиях, которые так часто встречаются сейчас в России. Разработка не ограничивается расширением ДССП и способна работать в качестве сервера ООБД на файл-сервере ЛВС.