Принципы журнализации заимствованы из системы POSTGRES [23] и [15].

Принципы кэширования взяты из [1].

В отношении языка реализации

Было решено реализовывать прототип СУООБД на ДССП. ДССП – диалоговая система структурного программирования – была разра­ботана в 1980 году Н.П.Брусенцовым в МГУ [5]. Система имеет под собой теоре­ти­ческое обоснование. Принцип ДССП «Слово есть слово», т.е. одно слово программы соответствует одному слову кода. Принципы управляющих конструкций наследуются от троичной вычислительной машины Сетунь-70, имевшей память на магнитных сердечниках. Словарь и обозначения – от языка Ч.Мура Forth. ДССП превосходит Forth по многим параметрам. Язык ДССП обладает существенно более низ­кой, чем язык ассемблера трудоемкостью в прог­рам­­ми­ро­ва­нии, не усту­пая ему в компактности кода и быстродействии, позво­ляет про­верять работу подпрограмм в интерактивном режиме и имеет возможность моди­фи­кации прог­рамм практически без внесения из­ме­нений в осталь­ные части ко­да.

Основные черты ДССП:

· Двухстековая архитектура

· Обратная польская запись

· Словари

· Поддержка нисходящего программирования

· Встроенный отладчик с рекомпиляцией

· Высокоуровневые структуры данных и операции

· Высокоуровневый механизм программных прерываний и исключительных ситуаций

· Компактный код

· Гибкость, мобильность, наращиваемость

· Наличие сопрограммного механизма

К сожалению, при всех этих достоинствах, ДССП на данный мо­мент является только системой программирования. Она не предос­тав­ляет сервис СУБД и не взаи­мо­действует ни с одной СУБД. Данная рабо­та направлена на то, чтобы обеспечить ДССП воз­можность обра­батывать данные в качестве СУБД, создав тем самым дешевый (Jasmine стоит порядка $15000), но эффективный инструмент, спо­соб­ный работать даже в самых непритязательных условиях, которые так часто встре­чаются сейчас в России. Разработка не ограничивается расширением ДССП и способна работать в ка­честве сервера ООБД на файл-сервере ЛВС.

1.5 Анализ полученного результата

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

В виде программного кода реализовано:

· Создание, открытие ООБД

· Менеджер виртуальной памяти

· Система управления каналами

· Система управления кэшированием объектов

· Создание основных объектов

· Клонирование объектов

· Переопределение поведений и действий

· Изменение данных в объектах

· Журнализация изменений в объектах

· Выполнение действий (knowhow)

2. Уточнение методов решения задачи

2.1 Наследование

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

Совокупности свойств объекта в объектно-ориентированной базе данных уделя­ет­ся большее внимание, чем во многих объектно-ориентированных языках прог­рам­миро­ва­ния, поскольку они являются также целью запросов. Объект=состояние+поведение. Чаще всего существует только одна иерархия наследования. Этот подход перешел и в C++. Однако, возможно разделение иерархий наследования данных и наследования по­ве­де­ний. Не всегда желательно иметь точно такую же иерархию наследования пове­де­ния, как и иерархию наследования свойств. Разделение этих двух иерархий повышает возможности переиспользования (reuse) поведений.

Значение переиспользования поведений

Предположим, мы имеем класс Студент и хотим создать класс Аспирант. Чтобы стать аспирантом, человек должен сначала получить высшее образование как студент. В общем случае экземпляры этих классов различны. Мы не можем наследовать Аспирант от Студент, т.к. аспирант не является студентом. В противном случае, мы имели бы право рассматривать аспиранта как экземпляр класса Аспирант и, с тем же правом, как экземпляр класса студент. Тем не менее, оба класса обладают общими атрибутами, таки­ми как: имя, адрес, номер_личной_карточки, а также большинством общих пове­де­ний. Это обстоятельство побуждает создать класс Аспирант, унаследовав свойства и по­веде­ния Студента. Однако, хотя экземпляры класса Аспирант будут подмножеством всех экземпляров класса Студент (т.к. все аспиранты были студентами, но не все студенты стали аспирантами), это представление будет некорректно с точки зрения моде­лиро­вания ситуации в реальном мире.

На рисунке представлено дерево наследования:

Рис. 2: Диаграмма наследования

Свойства классов Студент и Аспирант наследуются от класса Учащийся.

Поведение класса Аспирант наследуется от Студент. Обычно подкласс наследует все атрибуты и методы из суперклассов. В приложении к наследованию поведений это означает, что класс-ученик (demandclass) состоит в отношении Переиспользовать-от (Reuse-Of) с другим классом, называемым классом-учителем (supplyclass), и класс-ученик должен наследовать все поведения от класса-учителя.

Эталоны наследования: классы или прототипы?

В системе отсутствуют классы и типы. Роль класса может брать на себя любой объект, называемый объектом-образцом. Такой вид наследования называется насле­до­ванием на основе прототипов.

Как правило, системы с наследованием на основе прототипов концептуально более просты по сравнению с системами на основе классов. Порождение экземпляра дости­гает­ся копированием объекта-образца. Копия получает от системы уникальный иденти­фикатор, отличный от идентификатора любого другого объекта в системе.

Независимо от модели наследования (классы или прототипы) существует две раз­личные стратегии реализации механизма наследования: делегирование и конкате­нация.

Способ наследования: делегирование или конкатенация?

Делегирование представляет собой такую форму наследования, в которой объединение интерфейсов реализовано посредством разделения родительских интер­фей­сов, т.е. с использованием ссылок. Конкатенация достигает аналогичного эффекта посредством копирования родительских интерфейсов в интерфейс порож­даемого класса или объекта, – как результат, полученный интерфейс является непре­рывным. В любом случае дочерний объект способен отвечать как на сообщения, опреде­ленные в роди­тельских интерфейсах, так и на сообщения, добавленные к интерфейсу объекта. При делегировании те сообщения, которые не могут быть обработаны объектом, должны быть направлены родителям. При конкатенации каждый объект является самодостаточным, и необходимость перенаправления сообщений отсутствует. Введение идентификаторов полей позволяет распространить подходы делегирования и конкатенации и на агре­гатные объекты.