Реферат: Объектно-ориентированная СУБД (прототип)

Модель единого представления данных поведений
и сообщений в объектно-ориентированной базе данных

Модель [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) поведений.

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

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

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

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

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

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

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

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

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

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

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

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

И конкатенация, и делегирование имеют свои достоинства и недостатки. Делеги­рование обеспечивает возможность гибкого распространения изменений: любое измене­ние свойств родителя автоматически отражается на потомках. Подход, использующий конкатенацию, допускает изменение свойств родителей и потомков независимо друг от друга, что также может быть полезно во многих ситуациях. Делегирование обычно тре­бует меньших затрат по памяти, в то время как конкатенация является более эффек­тивной по времени. Simula и C++ являются примерами языков, которые реализуют на­следование на основе классов с использованием делегирования. В Smalltalk реализовано наследование на основе прототипов с использованием делегирования.

Обоснование избранного механизма наследования

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

Система поддерживает множественное наследование. Необходимость множест­венного наследования остается предметом горячих споров. Практика говорит о том, что «множественное наследование играет роль парашюта: в нем нет постоянной необхо­димости, но если он вдруг понадобился, то большое счастье иметь его под рукой» [8].

Определение родства

Остается важный вопрос: как определить, является ли объект потомком другого объекта? Разделение наследований состояния и поведения приводит к тому, что слово «потомок объекта» обретает двойственное значение. С одной стороны, это потомок по данным, с другой стороны, это потомок по поведению.

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

2.2 Инкапсуляция

Идея инкапсуляции в языках программирования происходит от абстрактных типов данных. С этой точки зрения объект делится на интерфейсную часть и реализа­ционную часть. Интерфейсная часть является спецификацией набора допустимых над объектом операций. Только эта часть объекта видима. Реализационная часть состоит из части данных (состояние объекта) и процедурной части (реализация операций).

Интерпретация этого принципа для баз данных состоит в том, что объект инкапсулирует и программу и данные.

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

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

Страницы: 1, 2, 3, 4, 5, 6, 7, 8