Быстрый поиск

Реферат: Объектно-ориентированная СУБД (прототип)

Комплексные сообщения

Если Воздействие является объектом-агрегатом, то

s(B) ~> o º null, если s=[ ]

s(B) ~> o º [A1 : s1(B) ~> o1, …, An : sn(B) ~> on], если s=[A1 : s1, …, An : sn]

где oj » o, oj неº o) и orf(oi) Ç orf(o) = Æ для j = 1,..,n и для любого i, j Î [1,..,n], если i ¹ j тогда oj неº o и orf(oi) Ç orf(oj) = Æ (т.е. o1,…,on являются глубокими копиями объекта-получателя o).

Если Воздействие является объектом-условием, то

s(B) ~> o º s.then(B) ~> o, если s.if(B) Ï {False, fail}

s(B) ~> o º s.else(B) ~> o, иначе.

Где s.if, s.then, s.else обозначение if-части, then-части и else-части s соответственно.

Если Воздействие является объектом-множеством, то

s(B) ~> o º null, если s={ }

s(B) ~> o º s1(B) ~> o, если s={s1}

s(B) ~> o º s’(B) ~> o, s’= s – {x} после x(B) ~> o

где x – произвольно выбранный элемент из множества s.

Если Воздействие является объектом-списком, то

s(B) ~> o º null, если s=( )

s(B) ~> o º sn(B) ~>(… ~>( s2(B) ~>( s1(B) ~> o))…) где s = (s1, s2, …, sn)

Семантика дробящейся посылки

Пусть B – Набор_параметров и пусть s, oÎO. Тогда оператор дробящейся посылки, обозначаемый ~1> определяется следующим образом:

Таблица 1: Семантика дробящейся посылки

Условие	S(B) ~1> o º
s(B) ~> o неº fail	s(B) ~> o
AGG(o) & o = [A1 : o1, …, An : on]	[A1 : s(B) ~> o1, …, An : s(B) ~> on]
BIO(o) & o.if неº null	s(B) ~> o.then
BIO(o) & o.if º null	s(B) ~> o.else
SET(o) & o = {o1,…,on}	{s(B) ~> o1, …, s(B) ~> on}
SEQ(o) & o = (o1,…,on)	(s(B) ~> o1, …, s(B) ~> on)
Иначе	Fail

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

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

В отличие от традиционных баз данных, исследования в области согласованного управления для объектно-ориентированных баз данных были ограничены. Это в значительной мере связано с уникальностью требований к объектно-ориентированным базам данных. Природа транзакций в таких приложениях, как 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 Виртуальная память и каналы

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

Рис 3: Связь каналов с хранилищами объектов

Таблица 2: Параметры канала

Параметр канала	Семантика
NCHAN	Номер текущего канала
LOWCH	Нижний канал; в него вложен этот канал
CHGCTX	Признак изменения данных заголовка фрагмента
TEKADR	Текущая позиция для чтения/записи
SYNCADDR	Адрес начала заголовка текущего сегмента в нижнем канале
TEKADR0	Позиция, соответствующая началу данных фрагмента
PREDADDR	Адрес заголовка предыдущего фрагмента (–1, если его нет)
NEXTADDR	Адрес заголовка следующего фрагмента (–1, если его нет)
BUSYLEN	Занятая длина
LEN	Выделенная длина