- 74 -

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

Кафедра Автоматизации и Интеллектуализации Процессов Управления

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К дипломной работе

На тему: «Разработка прототипа системы управления
объектно-ориентированной базой данных»

Студент Юдин Илья Викторович

Руководитель дипломной работы: Нечаев Анатолий Михайлович

Специальная часть: Титов Виктор Иванович

М О С К В А

1 9 9 9

Содержание

1. Введение 3

1.1 Причины появления объектно-ориентированных баз данных 3

1.2 Подходы в разработке ООБД 4

1.3 Краткий сравнительный анализ постреляционных и традиционных баз данных 5

1.4 Основания дипломной работы 5

1.5 Анализ полученного результата 7

2. Уточнение методов решения задачи 8

2.1 Наследование 8

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

2.3 Идентификатор объекта 11

2.4 Идентификатор поля агрегата 13

2.5 Триггеры. Ограничение доступа 13

2.6 Действие (knowhow) 14

2.7 Объекты-поведения 14

2.8 Принципы взаимодействия объектов 14

2.9 Транзакции и механизм согласованного управления 17

3. Разработка структуры СУ 18

3.1 Положение дел в области интероперабельности систем 18

3.2 Менеджер памяти 20

3.3 Виртуальная память и каналы 20

3.4 Система управления кэшированием объектов 21

3.5 Система управления журнализацией и восстановлением 23

3.6 Принципы реализации механизма согласованного управления 24

4. Представление данных в ООБД 28

4.1 Базовые объекты системы 28

4.2 Строение объекта 28

4.3 Контекст транзакции 30

5. Описание операций над объектами в БД 31

6. Требования к техническим и программным средствам 33

7. Реализация прототипа 34

7.1 Построитель 34

7.2 Заголовочный модуль для каналов 34

7.3 Менеджер виртуальной памяти 35

7.4 Система управления хранением объектов 38

7.5 Система управления каналами 39

7.6 Работа с базовыми объектами 40

7.7 Выполнение действий 42

7.8 Кэширование объектов 42

8. Контрольный пример, демонстрирующий возможности технологии 44

9. Оценка трудоемкости разработки ПО с использованием традиционного и предлагаемого подходов 45

9.1 Табличные базы данных с низкоуровневыми операциями доступа 45

9.2 Реляционные базы данных 45

9.3 Объектно-ориентированные базы данных 46

9.4 Будущее применения различных баз данных 46

10. Литература 47

1. Введение

1. Причины появления

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

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

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

Далее, развитие объектно-ориенти­рован­ного анализа и объ­ектно-ориентированного про­ек­ти­­ро­ва­ния как эффектив­ных под­ходов для формализации пред­мет­ной об­лас­ти, при­ве­ло к появ­ле­нию инфо­ло­ги­ческой модели пред­мет­ной об­ласти. Теперь, при разработке базы дан­­ных составлялось три модели пред­став­ле­ния информации пред­метной области: инфо­логическая, да­­та­логическая и физическая, не счи­­тая локальных пользовательских пред­став­лений.

Рис 1: Этапы проектирования Б

Д

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

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

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

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

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

Что же есть? Имеется многочисленный опыт разработок, нап­ри­мер Jasmine, POSTGRES, и других. Три документа, содержащих поже­ла­ния относительно возмож­ностей постреляционных СУБД : [3], [12] и [14].

1.2 Подходы в разработке ООБД

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

1. Объектно-реляционные базы данных

2. Объектно-ориентированные базы данных

Объектно-реляционные базы данных представляют собой реля­цион­ные базы дан­ных, дополненные надстройкой, пред­ставляющей эти дан­ные как объекты. Все по-прежнему хранится в ви­де таблиц. Этот под­ход позволяет плавно перейти от технологии хра­ни­лища таблиц к технологии хранилища объектов. Остается воз­можность выборки данных с помощью SQL-запросов. Сам SQL расширен командами работы с объ­ектами. Наиболее известным про­дуктом, в котором реализован подоб­ный подход является Oracle ver.8. Комитет ANSI X3H2, разработавший стан­дарт SQL–92, сейчас ра­бо­та­ет над SQL3. Основными усо­вер­шен­ство­ваниями в SQL3 должны стать возможность процедурного доступа на­равне с декларативным и под­держка объектов. Основным недос­тат­ком объ­ект­но-реляционных СУБД является необходимость разбирать объ­екты для размещения их в таблицах и собирать их для передачи поль­зователю из таблиц [2].

Объектно-ориентированные базы данных хранят объекты цели­ком. Для выборки объектов с помощью запросов разра­батывается язык OQL (Object Query Language), в который был вклю­чен стандарт SQL'92. Единство описания структуры БД достигается при­менением языка определения объектов ODL (Object Definition Language), пред­ло­женного ODMG (Object Database Management Group), являющегося расширением языка IDL. Эти виды баз данных обладают высокой произ­води­тель­но­стью, часто в несколько раз более высокой, чем реляционные базы дан­ных. Наиболее известными ООСУБД явля­ются Jasmine, ObjectStore и POET.

Из отечественных разработок в области пост­реляционных баз дан­ных достоверно извест­но лишь о существовании ООСУБД ODB-Jupiter. Похоже, она была написана специ­ально для создания продукта ODB-Text. По крайней мере, ни о каких других приложениях написанных на ODB-Jupiter ничего не известно. Также в Internet было обнаружено опи­сание некой отечественной объектно-ориентированной базы данных вер­сии 1.2. Точнее, это был модуль, предоставляющий функции объектно-ориен­ти­ро­ван­ной СУБД. Доку­мент даже не имел названия. В нем деталь­но рассматривалась орга­низа­ция хранения данных и принцип работы. Похоже, разработка обос­новывалась лишь на принципах, которым долж­на удовлетворять СУООБД. Наиболее интересная идея: назначение строкам уникальных идентификаторов и удаление строк только при упаковке базы. Это дает существенный выигрыш в сравнении строк, так как объекты-строки с одинаковым содержанием имеют одинаковые идентификаторы.

1. Краткий сравнительный анализ постреляционных и традиционных баз данных

Постреляционные базы данных вобрали в себя все лучшие черты иерархических, сетевых и реляционных баз данных.

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

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

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

1.4 Основания дипломной работы

В отношении избранных математических моделей

Значительная часть этой дипломной работы основывается на двух мате­мати­чес­ких моделях.

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

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

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

Эта модель [19] также оказала значительное влияние на данную работу, поскольку дополнила собой модель представления данных. Ни одна современная система управ­ления базой данных не может обойтись без подсистемы транзакций. Природа тран­зак­ций в таких при­ложениях, как CAD, мультимедийные базы данных, является весь­ма раз­лич­ной. Эти приложения характеризуются совместно выпол­ня­емыми продол­житель­ными транзакциями с произвольными опера­ци­ями. У продолжительных поль­зова­тель­ских транзакций время выпол­не­ния может быть растянуто на часы, а то и дни. Это усло­вие при­водит к тому, что хорошо извест­ный, и ставший уже классическим для тра­ди­ци­он­ных баз данных, кри­те­рий сериализуемости становится непри­меним непосредственно.

О са­мом критерии сериализуемости и спо­собах реализации меха­низ­ма транзакций достаточно подробно из­ло­жено в [9] и [22].