1.4 Основания дипломной работы
В отношении избранных математических моделей
Значительная часть этой дипломной работы основывается на двух математических моделях.
Модель единого представления данных поведений
и сообщений в объектно-ориентированной базе данных
Модель [17] замечательна тем, что не только описывает что представляют из себя объекты и как они взаимодействуют между собой, но и является замкнутой, самодостаточной. Она позволяет описать качественно новый вид взаимодействия в объектно-ориентированной системе: алгебру объектов. Эта алгебра является по своей сущности и важности аналогом реляционной алгебры в теории реляционных баз данных. В этой алгебре объектов определяется что представляют из себя такие операции, как селекция, проекция и другие хорошо известные из теории реляционных баз данных операции. Таким образом, эта модель объединяет два способа получения информации: посылка сообщения объекту (что типично для объектно-ориентированного программирования) и выполнение запроса над совокупностью хранимых данных (что типично для реляционных баз данных).
Модель согласованного управления в объектно-ориентированной базе данных
Эта модель [19] также оказала значительное влияние на данную работу, поскольку дополнила собой модель представления данных. Ни одна современная система управления базой данных не может обойтись без подсистемы транзакций. Природа транзакций в таких приложениях, как CAD, мультимедийные базы данных, является весьма различной. Эти приложения характеризуются совместно выполняемыми продолжительными транзакциями с произвольными операциями. У продолжительных пользовательских транзакций время выполнения может быть растянуто на часы, а то и дни. Это условие приводит к тому, что хорошо известный, и ставший уже классическим для традиционных баз данных, критерий сериализуемости становится неприменим непосредственно.
О самом критерии сериализуемости и способах реализации механизма транзакций достаточно подробно изложено в [9] и [22].
Механизм согласованного управления позволяет повысить производительность СУООБД за счет составления расписания выполнения транзакций, в том числе продолжительных, предоставляет транзакциям использовать промежуточные результаты других транзакций, учитывает объектную ориентированность данных и допускает обобщение операций (не только чтение и запись).
Другие работы, также повлиявшие на организацию структуры системы управления
В статье [20] излагается довольно интересная точка зрения на состояние объектно-ориентированного программирования, а также рассказывается о применении несколько отличного от традиций объектно-ориентированного программирования подхода. В частности, наследование реализуется с помощью механизмов включения и делегирования. Это позволяет решить проблему множественного наследования. Вводится понятие фильтров, представляющих собой продукции, которые могут обрабатывать входящие сообщения и даже перенаправлять их на другие объекты, сохраняя в теле этих сообщений ссылку на первоначальный объект, к которому было послано сообщение. Причем, фильтры могут реагировать не только на входящие, но и на исходящие от объекта сообщения.
Принципы журнализации заимствованы из системы POSTGRES [23] и [15].
Принципы кэширования взяты из [1].
В отношении языка реализации
Было решено реализовывать прототип СУООБД на ДССП. ДССП – диалоговая система структурного программирования – была разработана в 1980 году Н.П.Брусенцовым в МГУ [5]. Система имеет под собой теоретическое обоснование. Принцип ДССП «Слово есть слово», т.е. одно слово программы соответствует одному слову кода. Принципы управляющих конструкций наследуются от троичной вычислительной машины Сетунь-70, имевшей память на магнитных сердечниках. Словарь и обозначения – от языка Ч.Мура Forth. ДССП превосходит Forth по многим параметрам. Язык ДССП обладает существенно более низкой, чем язык ассемблера трудоемкостью в программировании, не уступая ему в компактности кода и быстродействии, позволяет проверять работу подпрограмм в интерактивном режиме и имеет возможность модификации программ практически без внесения изменений в остальные части кода.
Основные черты ДССП: . Двухстековая архитектура . Обратная польская запись . Словари . Поддержка нисходящего программирования . Встроенный отладчик с рекомпиляцией . Высокоуровневые структуры данных и операции . Высокоуровневый механизм программных прерываний и исключительных ситуаций . Компактный код . Гибкость, мобильность, наращиваемость . Наличие сопрограммного механизма
К сожалению, при всех этих достоинствах, ДССП на данный момент является только системой программирования. Она не предоставляет сервис СУБД и не взаимодействует ни с одной СУБД. Данная работа направлена на то, чтобы обеспечить ДССП возможность обрабатывать данные в качестве СУБД, создав тем самым дешевый (Jasmine стоит порядка $15000), но эффективный инструмент, способный работать даже в самых непритязательных условиях, которые так часто встречаются сейчас в России. Разработка не ограничивается расширением ДССП и способна работать в качестве сервера ООБД на файл-сервере ЛВС.
1.5 Анализ полученного результата
В результате проделанной работы изучена литература по организации реляционных баз данных, подходы к организации объектно-ориентированных баз данных. Были отобраны математические модели, на основании которых была определена архитектура базы данных и принципы ее функционирования. Программно реализованы подсистемы управления виртуальной памятью и кэширования объектов. Сама работа носит исследовательский характер, являясь шагом от чистой теории к идеям реализации ООБД. Обширность тематики не позволила проработать детально все вопросы, касающиеся организации ООБД. В частности, очень мало места уделено средствам повышения производительности поиска в БД (индексирование). Тем не менее, некоторые найденные решений, на мой взгляд, являются весьма перспективными. Это касается организации виртуальной памяти, позволяющей организовать произвольную степень вложенности данных, и механизма кэширования, которые подробно рассматриваются в работе.
В виде программного кода реализовано:
. Создание, открытие ООБД
. Менеджер виртуальной памяти
. Система управления каналами
. Система управления кэшированием объектов
. Создание основных объектов
. Клонирование объектов
. Переопределение поведений и действий
. Изменение данных в объектах
. Журнализация изменений в объектах
. Выполнение действий (knowhow)
2. Уточнение методов решения задачи
2.1 Наследование
Наследование является мощным средством моделирования (поскольку кратко и точно описывает мир) и помогает программисту разрабатывать новые версии классов и методов, не опасаясь повредить работающую систему. Наследование способствует повторному использованию кода, потому что каждая программа находится на том уровне, на котором ее может использовать наибольшее число объектов.
Совокупности свойств объекта в объектно-ориентированной базе данных уделяется большее внимание, чем во многих объектно-ориентированных языках программирования, поскольку они являются также целью запросов. Объект=состояние+поведение. Чаще всего существует только одна иерархия наследования. Этот подход перешел и в C++. Однако, возможно разделение иерархий наследования данных и наследования поведений. Не всегда желательно иметь точно такую же иерархию наследования поведения, как и иерархию наследования свойств. Разделение этих двух иерархий повышает возможности переиспользования (reuse) поведений.
Значение переиспользования поведений
Предположим, мы имеем класс Студент и хотим создать класс Аспирант. Чтобы стать аспирантом, человек должен сначала получить высшее образование как студент. В общем случае экземпляры этих классов различны. Мы не можем наследовать Аспирант от Студент, т.к. аспирант не является студентом. В противном случае, мы имели бы право рассматривать аспиранта как экземпляр класса Аспирант и, с тем же правом, как экземпляр класса студент. Тем не менее, оба класса обладают общими атрибутами, такими как: имя, адрес, номер_личной_карточки, а также большинством общих поведений. Это обстоятельство побуждает создать класс Аспирант, унаследовав свойства и поведения Студента. Однако, хотя экземпляры класса Аспирант будут подмножеством всех экземпляров класса Студент (т.к. все аспиранты были студентами, но не все студенты стали аспирантами), это представление будет некорректно с точки зрения моделирования ситуации в реальном мире.
На рисунке представлено дерево наследования:
[pic]
Рис. 2: Диаграмма наследования
Свойства классов Студент и Аспирант наследуются от класса Учащийся.
Поведение класса Аспирант наследуется от Студент. Обычно подкласс наследует все атрибуты и методы из суперклассов. В приложении к наследованию поведений это означает, что класс-ученик (demandclass) состоит в отношении Переиспользовать-от (Reuse-Of) с другим классом, называемым классом-учителем (supplyclass), и класс-ученик должен наследовать все поведения от класса-учителя.
Эталоны наследования: классы или прототипы?
В системе отсутствуют классы и типы. Роль класса может брать на себя любой объект, называемый объектом-образцом. Такой вид наследования называется наследованием на основе прототипов.
Как правило, системы с наследованием на основе прототипов концептуально более просты по сравнению с системами на основе классов. Порождение экземпляра достигается копированием объекта-образца. Копия получает от системы уникальный идентификатор, отличный от идентификатора любого другого объекта в системе.
Независимо от модели наследования (классы или прототипы) существует две различные стратегии реализации механизма наследования: делегирование и конкатенация.
Способ наследования: делегирование или конкатенация?
Делегирование представляет собой такую форму наследования, в которой объединение интерфейсов реализовано посредством разделения родительских интерфейсов, т.е. с использованием ссылок. Конкатенация достигает аналогичного эффекта посредством копирования родительских интерфейсов в интерфейс порождаемого класса или объекта, – как результат, полученный интерфейс является непрерывным. В любом случае дочерний объект способен отвечать как на сообщения, определенные в родительских интерфейсах, так и на сообщения, добавленные к интерфейсу объекта. При делегировании те сообщения, которые не могут быть обработаны объектом, должны быть направлены родителям. При конкатенации каждый объект является самодостаточным, и необходимость перенаправления сообщений отсутствует. Введение идентификаторов полей позволяет распространить подходы делегирования и конкатенации и на агрегатные объекты.
Страницы: 1, 2, 3, 4, 5, 6, 7
