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