Содержание

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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