МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ
Кафедра Автоматизации и Интеллектуализации Процессов Управления
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
К дипломной работе
На тему: «Разработка прототипа системы управления
объектно-ориентированной базой данных»
Студент Юдин Илья Викторович
Руководитель дипломной работы: Нечаев Анатолий Михайлович
Специальная часть: Титов Виктор Иванович
М О С К В А
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 предоставила единый интерфейс для работы с данными. Иерархическая и сетевая модели баз данных стали применяться крайне редко. Это было вызвано, прежде всего, трудностью модификации схем иерархических и сетевых баз данных и сильно зависящей от приложений навигацией в этих базах данных.
[pic]
Далее, развитие объектно-ориентированного анализа и объектно- ориентированного проектирования как эффективных подходов для формализации предметной области, привело к появлению инфологической модели предметной области. Теперь, при разработке базы данных составлялось три модели представления информации предметной области: инфологическая, даталогическая и физическая, не считая локальных пользовательских представлений.
Рис 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. Точнее, это был модуль, предоставляющий функции объектно-ориентированной СУБД. Документ даже не имел названия. В нем детально рассматривалась организация хранения данных и принцип работы. Похоже, разработка обосновывалась лишь на принципах, которым должна удовлетворять СУООБД. Наиболее интересная идея: назначение строкам уникальных идентификаторов и удаление строк только при упаковке базы. Это дает существенный выигрыш в сравнении строк, так как объекты- строки с одинаковым содержанием имеют одинаковые идентификаторы.
4 Краткий сравнительный анализ постреляционных и традиционных баз данных
Постреляционные базы данных вобрали в себя все лучшие черты иерархических, сетевых и реляционных баз данных.
Хотя существуют некоторые сходства, как, например, использование указателей и вложенная структура записей в сетевой модели. Однако надо отметить, что СУООБД используют логические указатели для обеспечения целостности, а также поддерживают иерархию классов, наследование и методы. Таких средств нет в иерархических и сетевых моделях [4].
Реляционные СУБД, идеально соответствующие своему назначению в традиционных областях применения баз данных, — банковское дело, системы резервирования и т.д. — в данном случае оказываются неудобными и неэффективными по многим причинам. Основное требование реляционной модели — нормализация — в случае сложноструктурированных данных с многочисленными взаимосвязями приводит к сложным запросам с соединением таблиц. То есть к тому, к чему реляционные СУБД не приспособлены, поскольку не могут обеспечить высокую производительность, требуемую интерактивным системам.
Страницы: 1, 2, 3, 4, 5, 6, 7
