Объектно-ориентированная СУБД (прототип)
базам данных. Природа транзакций в таких
приложениях, как CAD, мультимедийные базы данных, является весьма
различной. Эти приложения характеризуются совместно выполняемыми
продолжительными транзакциями с обобщающими операциями. Поскольку результат
выполнения транзакции может быть основан на промежуточных результатах
других транзакций, критерий сериализуемости не может быть применим
непосредственно в этом случае.
Сериализуемость состоит в том, что результат совместного выполнения
транзакций эквивалентен результату их некоторого последовательного
исполнения, называемого планом выполнения транзакций. Это обеспечивает
реальную независимость пользователей. Существует теорема Эсварана о
двухфазной блокировке: если все транзакции подчиняются протоколу двухфазной
блокировки, то для всех возможных существующих графиков запуска (порядков
выполнения транзакций) существует возможность упорядочения. Эта тема хорошо
освещена в [9] и [22].
В зависимости от организации протокола совместного выполнения
транзакций он является пессимистическим или оптимистическим.
Пессимистический метод ориентирован на ситуации, когда конфликты
возникают часто. Конфликты распознаются и разрешаются немедленно при их
возникновении. Оптимистический метод основан на том, что результаты всех
операций модификации базы данных сохраняются в рабочей памяти транзакций.
Реальная модификация базы данных производится только на стадии фиксации
транзакции. Тогда же проверяется, не возникают ли конфликты с другими
транзакциями.
Протокол согласованного управления СУООБД обеспечивает:
. Управление совместно выполняющимися продолжительными транзакциями
. Усиливает корректность критерия другого, чем сериализуемость
. Учитывает объектную ориентированность данных
. Допускает обобщение операций (не только чтение и запись)
Подробное описание и теоретическое обоснование протокола
согласованного управления для ООБД содержится в [19].
3. Разработка структуры СУ
3.1 Положение дел в области интероперабельности систем
Рост мощности программных приложений привел к выделению нового
архитектурного слоя – информационной архитектуры систем, определяющей
способность совместного использования, совместной деятельности (в
дальнейшем будет использоваться термин "интероперабельность") компонентов
(информационных ресурсов) для решения задач [21]. Этот слой расположен
обычно над сетевой архитектурой, являющейся необходимой предпосылкой такой
совместной деятельности компонентов, обеспечивающей их взаимосвязь.
Деятельность по созданию технологии интероперабельных систем
охватывает весь мир. Наиболее существенный вклад в принимаемые
идеологические, архитектурные и технологические решения интероперабельных
систем вносит Object Management Group (OMG) (http://www.omg.org) -
крупнейший в мире консорциум разработки программого обеспечения, включающий
свыше 600 членов - компаний - производителей программного продукта,
разработчиков прикладных систем и конечных пользователей. Целью OMG
является создание согласованной информационной архитектуры, опирающейся на
теорию и практику объектных технологий и общедоступные для
интероперабельности спецификации интерфейсов информационных ресурсов. Эта
архитектура должна обеспечивать повторное использование компонентов, их
интероперабельность и мобильность, опираясь на коммерческие продукты.
Другие организации, которые работают в кооперации с OMG, например, с
целью доведения результатов OMG до официальных стандартов в различных
аспектах, включают: ANSI, ISO, CCITT, ANSA, X/Open Company, Object Database
Management Group (ODMG).
Развитие возможностей информационных систем и Internet и желание
обеспечить их взаимодействие между собой, привело к необходимости
разработки единого протокола взаимодействия. Для этого была создана OMG,
которая и занялась этим вопросом. В результате была разработана эталонная
модель, которая определяет концептуальную схему для поддержки технологии,
удовлетворяющей техническим требованиям OMG. Она идентифицирует и
характеризует компоненты, интерфейсы и протоколы, составляющие Архитектуру
Управления Объектами OMG (Object Management Architecture (OMA)), не
определяя, впрочем, их детально.
Согласованная с OMA прикладная система состоит из совокупности классов
и экземпляров, взаимодействующих при помощи Брокера Объектных Заявок
(Object Request Broker (ORB)). Объектные Службы (Object Services)
представляют собой коллекцию служб, снабженных объектными интерфейсами и
обеспечивающих поддержку базовых функций объектов. Общие Средства (Common
Facilities) образуют набор классов и объектов, поддерживающих полезные во
многих прикладных системах функции. Прикладные объекты представляют
прикладные системы конечных пользователей и обеспечивают функции,
уникальные для данной прикладной системы.
CORBA (Common Object Request Broker Architecture) определяет среду для
различных реализаций ORB (Object Request Broker), поддерживающих общие
сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций
объектов между различными ORB.
Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам
посылать или принимать заявки, отвечать на них и получать результаты, не
заботясь о положении в распределенной среде и способе реализации
взаимодействующих с ними объектов.
Объектные Службы:
. Служба Уведомления Объектов о Событии (Event Notification Service).
. Служба Жизненного Цикла Объектов (Object Lifecycle Service).
. Служба Именования Объектов (Name Service).
. Служба Долговременного Хранения Объектов (Persistent Object Service).
. Служба Управления Конкурентым Доступом (Concurrency Control Service).
. Служба Внешнего Представления Объектов (Externalization Service).
. Служба Объектных Связей (Relationships Service).
. Служба Транзакций (Transaction Service).
. Служба Изменения Объектов (Change Management Service).
. Служба Лицензирования (Licensing Service)/
. Служба Объектных Свойств (Properties Service).
. Служба Объектных Запросов (Object Query Service).
. Служба Безопасности Объектов (Object Security Service).
. Служба Объектного Времени (Time Service).
Общие Средства заполняют концептуальное пространство между ORB и
объектными службами с одной стороны, и прикладными объектами с другой.
Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы –
фундаментальные объектные интерфейсы, а задача Общих Средств – поддержка
интерфейсов сервисов высокого уровня. Общие Средства подразделяются на две
категории: "горизонтальные" и "вертикальные" наборы средств.
"Горизонтальный" набор средств определяет операции, используемые во многих
системах, и не зависящие от конкретных прикладных систем. "Вертикальный"
набор средств представляет технологию поддержки конкретной прикладной
системы (вертикального сегмента рынка), такого, как здравоохранение,
производство, управление финансовой деятельностью, САПР и т.д.
. Средства поддержки пользовательского интерфейса (User Interface Common
Facilities)
. Средства управления информацией (Information Management Common
Facilities)
. Средства управления системой (System Management Common Facilities)
. Средства управления задачами (Task Management Common Facilities)
. Вертикальные общие средства (Vertical Common Facilities)
. Вертикальные общие средства предназначены для использования в качестве
стандартных для обеспечения интероперабельности в специфических
прикладных областях.
. Поддержка интероперабельности брокеров в стандарте CORBA 2.0
О роли СУООБД в архитектуре OMG можно прочесть в [13].
На основе анализа вышеизложенного, были выбраны в качестве основания
следующие базовые службы СУООБД:
. Служба Долговременного Хранения Объектов – управление хранением объектов
. Служба Управления Конкурентным Доступом и Служба Транзакция – объединены
вместе протоколом согласованного управления.
. Служба Изменения Объектов – управление журнализацией изменений
3.2 Менеджер памяти
Менеджер памяти является ключевым модулем системы.
Его наличие позволяет
. Абстрагироваться от особенностей обращения к различным видам памяти.
. Создавать сколь угодно вложенные друг в друга структуры данных.
. Иметь единый интерфейс на каждом уровне вложенности.
. Организовать кэширование объектов
В состав менеджера памяти входит 3 системы управления:
1. Система управления виртуальной памятью
2. Система управления каналами
3. Система управления кэшированием объектов
3.3 Виртуальная память и каналы
Виртуальная память представляет собой непрерывную для пользователя, с
ней работающего, область памяти, которая может быть вложена в другую
виртуальную память. Виртуальная память состоит из сегментов, связанных
между собой в двунаправленную цепь. Каждому сегменту известно его положение
относительно нижнего логического уровня. Работа с виртуальной памятью
происходит через канал, выделенный для нее. Канал – это набор характеристик
описывающих: где расположена виртуальная память, и в каком ее месте мы
находимся. Количество каналов ограничено, поэтому канал выделяется той
виртуальной памяти, которая нужна
| |  скачать работу |
Объектно-ориентированная СУБД (прототип) |
