Аспекты построения системы управления объектно-ориентированными базами данных

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Аспекты построения системы управления объектно-ориентированными базами данных

Правдин А.Л.

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

Основные задачи, решение которых требуется при построении любой СУООБД, складываются из традиционных задач построения баз данных и задач, привнесённых объектной парадигмой. Примем следующие определения. Классом будем считать абстракцию множества объектов, обладающих общим набором свойств и одинаковым поведением, выраженным методами. Объектом будем считать экземпляр класса [2, стр. 20]. Тогда, для построения СУООБД нам потребуется определить решения следующих задач: хранение данных классов, хранение данных объектов, выборка данных; представление данных в приложении; реализация транзакций. Отметим, что по каждой задаче сложился определённый набор альтернативных решений, которые мы далее рассмотрим.

Хранение данных классов

В спецификации объектной модели стандарта ODMG сказано, что само по себе определение класса также является объектом. Это действительно так, потому что определение класса имеет как явные, так и зависящие от реализации свойства. Так определение класса содержит описание свойств и методов. Каждое свойство может быть описано парой «идентификатор: тип». Каждый метод может иметь несколько реализаций с различными сигнатурами, таким образом, множество методов описывается множеством троек «идентификатор: сигнатура: код». Каждый класс имеет имя - явный атрибут класса.

Основной момент, которым определяется способ хранения данных классов - это представление методов объектов. В идеальном случае, они должны быть описаны на некотором промежуточном языке, который должен служить связью между СУООБД и приложениями, использующими её. Однако подобная реализация влечёт необходимость использования как промежуточного языка описания интерфейсов, так и менеджера объектных запросов [4], включающего фабрику объектов. Это усложняет реализацию, однако делает систему переносимой и расширяемой. Менеджер объектных запросов - центральный элемент объектной модели стандарта OMG, однако здесь мы опустим его описание, из-за наличия достаточного количества литературы по данному вопросу. Если не использовать менеджер объектных запросов, то можно определить два направления хранения и обработки методов:

- их написание на языке программирования целевого приложения;

- написание методов на некотором абстрактном языке.

Вариант с использованием абстрактного языка запросов, несмотря на большую гибкость, требует реализации множества аспектов, таких, как:

- вычислительная полнота языка;

- наличие эффективного механизма интерпретации запросов, включающего их оптимизацию и проверку вычисляемости [5].

Вариант с использованием языка программирования целевого приложения для определения методов классов является частным случаем использования менеджера объектных запросов, так как наличие классов, определённых на уровне программы, приводит к необходимости формирования фабрики объектов также на уровне объектов. Т.е. промежуточный язык описания классов совпадает с языком программирования целевого приложения, а фабрика объектов становится его частью.

Хранение данных объектов

Хранение данных объектов это хранение информации о каждом уникальном экземпляре данных. Данная информация составляет основу БД. Существует два исторически сложившихся альтернативных решения хранения данных объектов:

- использование реляционной СУБД в качестве основы;

- использование файлов, т.е. собственной подсистемы.

Для хранения объекта требуется сохранить его уникальную внутри класса информацию, которой является его состояние - совокупность значений его свойств. Свойства объекта, в соответствии со стандартом ODMG, представляют собой: атомарные значения, ссылки на другие объекты, либо коллекции - множества атомарных значений или ссылок. Указанные типы данных с учётом идентифицируемости объектов достаточно просто отображаются на реляционной модели.

Важным моментом при использовании реляционной СУБД в качестве основы для хранения объектной информации выступают стратегии отображения классов объектно-ориентированной модели на отношения реляционной. В статье [3] приводится подробная классификация отображения, и рассматриваются конкретные варианты подобного преобразования, которые называются шаблонами. Шаблоны указывают способ сопоставления классов иерархии и отношений реляционной модели с учётом наследования атрибутов. Выделяются такие шаблоны как «одна иерархия - одна таблица», «один класс - одна таблица», «один путь наследования - одна таблица» и другие.

В пользу решения хранения данных объектов в реляционной базе говорит наличие доступных и эффективных реализаций СУБД.

Использование файлов в качестве основы подсистемы хранения объектов представляет большое разнообразие решений и большую возможность управлять свойствами готового продукта. Так, можно использовать традиционную для реляционных систем структуру фала БД, можно использовать потоки данных для хранения разнородной информации в одном файле, как это реализовано в технологии Microsoft^® COM.

Простейшее решение на основе файлов, предлагаемое нами, заключается в следующем. Данные объектов хранятся в неупорядоченном бинарном файле. Для доступа к этим данным создаётся индексный файл, содержащий сопоставление «имя класса: идентификатор объекта: адрес в бинарном файле».

Выборка данных

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

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

Выдача данных запросов зависит от архитектуры системы. Если классы определяются на промежуточном языке, и используется брокер объектных запросов, то решение задачи определяется его функциональностью. Если же классы определяются на языке программирования целевого приложения, то задача отпадает. Однако, ввиду того, что подсистема хранения данных объектов хранит только их свойства, а на выходе запроса мы ожидаем объекты, с которыми можно обращаться точно так же, как с объектами, созданными в программе, требуется некоторый менеджер объектов [5]. В его функции входит связывание данных объектов с данными классов для формирования объектов на выходе запроса.

Представление данных в программе

При переносе объектов из оперативной памяти во внешнюю возникает необходимость сохранения ссылок объектов друг на друга. Проблема решается идентификацией объектов. Более серьезная проблема возникает при восстановлении объектов в оперативной памяти. Процесс, происходящий при этом, называется «pointer swizzling» - настройка по адресам [6]. Суть проблемы - обеспечить доступ к объекту, на который ссылается другой объект, что требует преобразования ссылки-идентификатора в ссылку-адрес.

Различают стратегии «активного» и «ленивого» преобразования. «Активное» преобразование заключается в преобразовании всех ссылок-идентификаторов внутри объекта в ссылки-адреса при загрузке объекта в оперативную память. При «ленивом» преобразовании требуемые объекты загружаются только тогда, когда к ним происходит обращение. Существуют различные варианты реализации механизма настройки по адресам. Если мы используем стратегию активного преобразования, то имеет смысл дополнить необходимым кодом метод загрузки объекта из базы данных. Если же используется ленивая стратегия, то уместно обращение к объектам по их идентификаторам через некоторую функцию СУООБД, преобразующую идентификатор объекта в его адрес.

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

Транзакции

Транзакции - один из наиболее важных механизмов любой СУБД, который необходим для сохранения данных в непротиворечивом состоянии. Транзакции - совокупность действий, которая переводит данные в БД из одного непротиворечивого состояния в другое [7]. В контексте объектно-ориентированных баз данных выделяют несколько разновидностей транзакций [8]: короткие, длинные и вложенные.

Короткие транзакции характеризуются малым временем выполнения: существуют только в рамках сеанса работы с ОСУБД. Все объекты, подлежащие изменениям, блокируются; после принятия транзакции - разблокируются; изменения записываются в базу данных. Длинные транзакции предназначены для увеличения производительности при групповой работе. Пользователи блокируют данные на долгое время, после чего происходит синхронизация. Процесс отличается от репликации в реляционных системах тем, что на время работы пользователя объекты, требуемые ему, блокируются определённым образом. Вложенные транзакции образуются в том случае, если действия в рамках одной транзакции порождают новые транзакции. При этом если в текущей сессии работает один процесс, то создается стек транзакций; в случае, если в текущей сессии работает несколько процессов, то создаётся дерево транзакций.

Для физической реализации транзакций существует 2 основных метода: метод упреждающей журнализации и метод теневых страниц [9].

Ещё один момент при реализации транзакций - выбор наименьшего элемента, который должен быть подвергнут блокировке. Можно привести иерархию таких элементов [10, стр. 165]: База данных -> Файл / Класс -> Страница / Кортеж / Объект. Чем меньше элемент блокировки, тем выше функциональность системы.

Выбор метода реализации транзакций равно как и определение достижимой функциональности зависят от способа хранения данных классов и объектов. Например, при использовании реляционной СУБД в качестве основы хранения данных объектов, отпадает необходимость реализации механизма коротких транзакций на других уровнях системы. Однако остаётся потребность в некоторых логических элементах работы [10, стр. 153], определенных на более высоких уровнях.

Мы коротко рассмотрели основные аспекты построения СУООБД, которые повлияли на создание нашей системы. На рисунке приведена обобщенная схема нашей системы в нотации языка UML [2].

управление программа транзакция база

Обобщённая схема СУООБД

Как видим, система состоит из трёх необходимых компонентов, которые отражают подсистемы хранения данных классов (модель), объектов и менеджер объектов. Связи между компонентами означают, что компонент слева на рисунке использует функциональность, предоставляемую компонентом справа.

Описание классов может быть на языке программирования целевого приложения, либо на промежуточном языке. «Менеджер объектов» преобразует данные из подсистемы хранения данных объектов в объектную форму, т.е. связывает свойства объектов с их методами, выполняет объектные запросы и реализует некоторые общие механизмы, например транзакции.

Литература

1. Т. Коннолли. Базы данных: проектирование, реализация и сопровождение. Теория и практика. / Т. Коннолли, К. Бегг, А. Страчан. 2-е изд.: Пер. с англ.: Уч. пос. - Издательский дом «Вильямс», 2000. - 1120 с.: ил. - Парал. тит. англ.

2. Леоненков А.В. Самоучитель UML. - СПб.: БХВ-Петербург, 2001. - 304 с.: ил. ISBN 5-94157-008-2

3. Семенов В.А. Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов. / Семенов В.А., Морозов С.В., Порох С.А. Электронный ресурс. Доступно по адресу: http://www.citforum.ru/database/articles/strategy/

4. Орфали Р. Основы CORBA. / Орфали Р., Харки Д., Эдвардс Д. Пер. с англ. - М., МАЛИП, 1999. - 318 с.: ил. ISBN 5-93517-001-9 (рус.)

5. Dave D. Straube. Queries and query processing in object-oriented database systems. / A thesis submitted for the degree of Doctor of Philosophy. Edmonton, Alberta, 1991. Электронный ресурс. Доступно по адресу: http://citeseer.ist.psu.edu/straube90querie.html

6. Kemper A. Adaptable pointer swizzling strategies in object bases: design, realization and quantitative analysis. / A. Kemper, D. Kossmann. Электронный ресурс. Доступно по адресу: http://citeseer.ist.psu.edu/kemper93adaptable.html

7. Домбровская Г.Р. Нестандартные модели транзакций. / Электронный ресурс. Доступно по адресу: http://meta.math.spbu.ru/publication/Programmirovanit96.pdf

8. Андреев А.М. Внутренняя организация ОСУБД на примере Versant, Poet, ODB-Jupiter. / Андреев А.М. Березкин Д.В. Самарев Р.С. Электронный ресурс. Доступно по адресу: http://www.inteltec.ru/publish/articles/objtech/cordb.shtml

9. Кузнецов С.Д. Семейство алгоритмов ARIES. / Кузнецов С.Д., П. Чардин. Открытые системы №3 / 2004. Электронный ресурс. Доступно по адресу: http://www.osp.ru/os/2004/03/

10. М. Нагао. Структуры и базы данных. / М. Нагао, Т. Катаяма, С. Уэмура. Пер. с япон. - М.: Мир, 1986. - 197 с., ил.

Размещено на Allbest.ru