автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.11, диссертация на тему:Аспектный подход к созданию объектно-ориентированных систем управления базами данных

кандидата физико-математических наук
Книжник, Константин Александрович
город
Москва
год
1999
специальность ВАК РФ
05.13.11
цена
450 рублей
Диссертация по информатике, вычислительной технике и управлению на тему «Аспектный подход к созданию объектно-ориентированных систем управления базами данных»

Текст работы Книжник, Константин Александрович, диссертация по теме Математическое и программное обеспечение вычислительных машин, комплексов и компьютерных сетей

, ' / /.,. .........

/ - ^чУ ~ • ,, ... ..V

/

МИНИСТЕРСТВО ОБЩЕГО И ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ РФ МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНДУСТРИАЛЬНЫЙ УНИВЕРСИТЕТ

Книжник Константин Александрович

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

Специальность 05.13.11 "Математическое и программное обеспечение вычислительных машин, комплексов, систем и сетей"

Диссертация на соискание ученой степени кандидата физико-математических наук

Научный руководитель Абрамов Игорь Вячеславович

Москва 1999

Оглавление

1 Введение 4

2 Применение объектной технологии к СУБД 9

2.1 Ограничения традиционных реляционных СУБД............9

2.2 Обзор проблемы и возможные пути ее решения..............12

2.3 Свойства объектно-ориентированных СУБД..................16

2.3.1 Сложные объекты и идентификаторы объектов ... 19

2.3.2 Использование абстрактных типов или классов ... 20

2.3.3 Иерархия классов...............................21

2.3.4 Совместное использование, переопределение и позднее связывание............................................23

2.3.5 Сохранение объектов и управление вторичной памятью 25

2.3.6 Параллельность и восстановление......................26

2.3.7 Дополнительные возможности ООСУБД..............28

2.3.8 Альтернативные направления..........................30

2.4 Обзор существующих ООСУБД................................31

2.4.1 GemStone..................................................31

2.4.2 ONTOS DB................................................38

2.4.3 ObjectStore................................................45

2.4.4 VERSANT................................................54

2.4.5 ITASCA..................................59

2.4.6 Objectivity/DB............................................63

2.4.7 02 ..........................................................66

2.4.8 MATISSE..................................................72

3 Общие принципы построения GOODS 78

4 Метаобъекты в GOODS 87

4.1 Аспектно-ориентированное программирование................87

4.2 Интерфейс метаобъектов..........* . . .............88

4.2.1 Управление совместным доступом к объектам различных клиентов..........................................88

4.2.2 Синхронизация доступа внутри процесса..............91

4.2.3 Управление кэш памятью объектов....................96

4.2.4 Описание протокола......................................96

4.3 Стандартные метаобъекты......................................108

4.3.1 Базовый метаобъект......................................108

4.3.2 Оптимистический подход................................111

4.3.3 Пессимистический подход................................113

4.3.4 Указание метаобъекта для объекта....................117

4.4 Концепция транзакций в GOODS..............................118

5 Архитектура сервера GOODS 125

5.1 Менеджер доступа к объектам....................126

5.2 Менеджер распределения памяти ..............................128

5.2.1 Распределение памяти с помощью битовой карты . . 129

5.2.2 Непрерывное распределение памяти и копирующий сборщик мусора..........................................130

5.2.3 Распределение памяти в GOODS ......................133

5.2.4 Сборка мусора в GOODS................................134

5.3 Менеджер классов................................................143

5.4 Менеджер файлового пула ......................................147

5.5 Менеджер транзакций............................................149

5.6 Оптимизация пересылки объектов между сервером и клиентом 156

6 Интерфейс приложений с базой данных 159

6.1 Интерфейс с хранилищем........ ........................159

6.2 Использование языка С++ для доступа к базе данных . . . 167

7 Заключение 177 А Определение объектных ссылок в GOODS 179 В Стандартные классы GOODS 184

Глава 1

Введение

Объектно-ориентированные базы данных появились в середине 80 годов как результат осознания того, что реляционная модель плохо подходит для некоторых классов приложений. Все более возрастающая сложность запросов приложений показала необходимость расширения традиционной технологии реляционных баз данных, особенно для таких областей применения баз данных, как системы автоматизированного проектирования (CAD/CAM), системы поддержки принятия решения (CASE), системы автоматизации документооборота, географические и информационные системы. ООСУБД объединяют возможности СУБД с возможностями традиционных языков программирования, таких как С++ и Smalltalk. Было разработано достаточно большое количество ООСУБД, используемых преимущественно в специализированных приложениях. По мере развития ООСУБД, к ним добавились непроцедурный язык запросов и средства администрирования, сходные с предлагаемыми реляционными СУБД. В результате появилась возможность использования ООСУБД для более широкого круга приложений.

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

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

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

Основной особенностью ООСУБД является предоставление разработчику приложения всех средств современных объектно-ориентированных языков программирования для доступа к базе данных. При этом, с самого начала развития ООСУБД, наблюдалась тенденция использования хорошо известных языков программирования, таких как С++, Smalltalk, CLOS для взаимодействия с базой.

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

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

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

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

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

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

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

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

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

ки платформно-независимой модели параллелизма, позволяющей наиболее эффективно использовать возможности современных многопроцессорных систем.

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

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

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

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

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

Глава 2

Применение объектной технологии к СУБД

2.1 Ограничения традиционных реляционных СУБД

Для большинства существующих систем управления базами данных характерна жесткая связь СУБД с поддерживаемой ее моделью данных. В частности реляционные СУБД реализует реляционную модель данных. Реляционная модель определяет:

• единую концепцию структуризации данных, называемую отношением (или таблицей) для представления всех данных в базе,

• набор операций над отношениями, называемый реляционной алгеброй (эти операции включают выборку, проекцию, объединение, пересечение. ..),

• ряд ограничений, например значения колонки таблицы должно быть атомарным.

Реляционные СУБД кроме того предоставляют:

• набор стандартных типов данных, которые могут быть использованы в колонках таблицы (CHAR, DATETIME, FLOAT...),

• непроцедурный язык манипулирования данными, который может быть определен в терминах реляционной алгебры (SQL),

• реализацию этого языка.

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

Такая схема взаимодействия с СУБД оказалась очень эффективной для большинства основных приложений для бизнеса, однако при попытки применить РСУБД для более сложных (в смысле модели данных) приложений, таких как САПР, ГИС, а также для работы с мультимедиа данными, стало ясно, что для удовлетворения потребности этих приложений необходимы расширения традиционных РСУБД.

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

использование комплексной арифметики, работа с массивами и матрицами. Бизнес п�