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

(когда m¹ fail)

(3) m(B) ~> same º same;  same(B) ~> r º r;

(когда m¹ fail и m¹ null)

При совпадении идентификатора

(4) Если существует метод x из r такой, что x º m и sig(x) = (A1,c1) ´ …´ (An,cn)® cr и {(A1,a1) ´ …´ (An,an)} ÍB и FID каждого поля сi присутствует в ai (в терминах ОО-програм­мирования: ci является предком по значению для ai), тогда

m(B) ~> r º r.kh(x)(A1 : a1, … , An : an )

иначе проверяется совпадение значения.

При совпадении значения

(5) Если существует метод x в r или его объектах-учителях (объектов, от которых наследуется поведение) такой, что x » m и sig(x) = (A1,c1) ´ …´ (An,cn)® cr и {(A1,a1) ´ …´
´ (An,an)}ÍB и FID каждого поля сi присутствует в ai, тогда

m(B) ~> r º r.kh(x)(A1 : a1, … , An : an )

иначе

(6) Если r является атомарным, то m(B) ~> r º fail.

Иначе m(B) ~> r является комплексным сообщением (complex message sending), обладает сложной структурой.

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

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

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: Семантика дробящейся посылки

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

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

В отличие от традиционных баз данных, исследования в области согласованного управления для объектно-ориентированных баз данных были ограничены. Это в значи­тельной мере связано с уникальностью требований к объектно-ориентированным базам данных. Природа транзакций в таких приложениях, как CAD, мультимедийные базы данных, является весьма различной. Эти приложения характеризуются совместно вы­полняемыми продолжительными транзакциями с обобщающими операциями. Поскольку результат выполнения транзакции может быть основан на промежуточных результатах других транзакций, критерий сериализуемости не может быть применим непо­сред­ственно в этом случае.

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

В зависимости от организации протокола совместного выполнения транзакций он является пессимистическим или оптимистическим.

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

Протокол согласованного управления СУООБД обеспечивает:

·     Управление совместно выполняющимися продолжительными транзакциями

·     Усиливает корректность критерия другого, чем сериализуемость

·     Учитывает объектную ориентированность данных

·     Допускает обобщение операций (не только чтение и запись)

Подробное описание и теоретическое обоснование протокола согласованного управления для ООБД содержится в [19].

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: Параметры канала

Таблица 3: Операции доступа к данным виртуальной памяти

Начало виртуальной памяти соответствует нулевому значению TEKADR. Доступ осуществляется через операции позиционирования (GOTO и @GOTO), чтения байта (IBS) и записи байта (OBS). Остальные функции, реализуются через них (например, чтение длинного слова). К памяти может быть применена функция UPSIZE с аргументом, содер­жащим необходимое количество байт для выделения. Память может гаранти­ро­ванно вы­деляться до заполнения всей выделенной длины. При исчерпании выделенной длины, делается запрос к нижестоящему уровню о выделении дополнительной памяти. Если та­кой запрос применяется к каналу ниже 5-го, соответствующего дисковому файлу, файл увеличивается в размере, если его выделен­ная длина исчерпана. Если увеличение раз­мера файла невозможно из-за нехватки дискового пространства, то, в случае невоз­можности выделения памяти за счет упаковки, возбуждается ситуация NOMEMORY. При попытке доступа за пределы определенной вирту­альной памяти (например, чтение после расположения данных), возни­кает ситуация OUTDATA.

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

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

Задача управления кэшированием объектов подобна задаче управления памятью в операционной системе. В операционной системе для организации процесса обмена между оперативной и внешней памятью информация представлена набором сегментов (блоки переменной длины) или страниц (блоки фиксированной длины). Способ управ­ле­ния памятью называется алгоритмом замещения, который определяет состав сегментов или страниц в более быстродействующей основной памяти. Таким образом, частота об­ращений к внешней памяти, а, следовательно, и быстродействие двухуровневой памяти (уровень внешней памяти и уровень оперативной памяти) в целом, существенно зависят от выбранного алгоритма замещения. Наибольшее распространение получила стра­нич­ная структура памяти.

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

Наиболее популярны следующие пять алгоритмов замещения:

1.   Случайное замещение (СЗ): с равной вероятностью может быть замещен любой объект,

2.   Раньше пришел – раньше ушел (РПРУ, или FIFO): замещается объект дольше всех находившийся в оперативной памяти,

3.   Замещение наиболее давно использовавшегося объекта (НДИ),

4.   Алгоритм рабочего комплекта (РК): хранятся в памяти только те объекты, к которым было обращение в течении времени t, назад от текущего момента,

5.   Лестничный алгоритм (ЛЕСТН): в списке объектов при обращении к объекту он ме­ня­ется местами с объектом, находящемся ближе к голове списка. При обращении к от­сутствующему в ОП объекту объект, находящийся в последней позиции вытесняет­ся.

Для алгоритма замещения желательно, чтобы он обладал двумя отчасти противоречивыми свойствами: с одной стороны, он должен сохранять в ОП объекты к которым обращения происходят наиболее часто, с другой – быстро обновлять содер­жимое ОП при смене множества рабочих объектов.

Например, алгоритм РПРУ эффективен только в отношении быстрого обновления ОП, он не выделяет в списке объектов объекты, обращения к которым происходят чаще, чем к остальным. Алгоритм НДИ также позволяет быстро обновлять содержимое ОП. Однако последовательность одиночных обращений достаточной длины к объектам, находящимся во ВП, вытеснит из ОП все объекты, к которым, в среднем, обращения происходят чаще всего.

 В [1] описывается класс многоуровневых алгоритмов замещения c, которые поз­воляют решить эту проблему. Они зависят от конечного числа параметров и при адап­тивном подборе этих параметров соединяют свойство быстрого обновления части ОП со свойством сохранения в ОП тех объектов, которые наиболее часто запра­ши­ва­ются.

В дипломной работе решено использовать алгоритм замещения из класса c, при следующих параметрах: лимит времени нахождения объекта в ОП отсутствует, размеры подсписков на всех уровнях одинаковы, параметр l=1 (это соответствует алгоритму замещения НДИ для объектов всех подсписков; если i – положение объекта в подсписке, и i £ l, то при обращении к нему применяется алгоритм РПРУ, иначе НДИ).

Страницы: 1, 2, 3, 4, 5