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

и значение(o2)

= {y1, …, ym} и l = m и для каждого xi(yj) существует один yj(xi) : xi

(n-1 yj для 1( i,j ( l; или

Существует объект-список c, такой, что значение(o1) = (x1, …, xl) и

значение(o2) = (y1, …, ym) и l = m и xi (n-1 yi для 1( i ( l.

Два объекта называются эквивалентными (o1 ( o2) тогда и только тогда,

когда

o1 (n o2 для некоторого n > 0.

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

Введение идентификатора поля позволяет преодолеть трудность

определения размещения данных полей агрегатов. Суть проблемы заключается в

том, что если мы наследуем классы B и C от класса A, а затем наследуем

множественно класс D от классов B и C, то экземпляр класса D одновременно

является экземпляром классов A, B и C. При этом важно, чтобы "старый" класс

(например, A) умел работать с объектами класса D. Эта проблема

рассматривается в работе [10], в которой авторы вводят следующие

ограничения целостности структуры объектов:

1. В БД не могут существовать отдельные собственные части подклассов

2. Каждой части сложного объекта должна соответствовать только одна

собственная часть.

В качестве решения они предлагают использование ссылок на классы и

каждую собственную часть класса хранить отдельно.

В дипломной работе предлагается вместо хранения ссылок на классы

установить для каждого поля свой идентификатор. При наследовании поле

сохраняет свой идентификатор. Таким образом, переименование полей не

нарушает связь наследования. Переименование может быть автоматическим,

например, из-за конфликтов имен полей при множественном наследовании.

Аналогично поступает оператор SQL Select, когда в качестве результата

запроса ему нужно вернуть несколько столбцов, имеющих одинаковые имена.

Идентификаторы полей уникальны в пределах базы данных, т.е. при

объявлении нового поля в классе, идентификатор поля в дальнейшем появляется

только в классах-наследниках и только через наследование.

Кроме того, программисты могут использовать для имен полей привычный

для них родной язык, другими словами: есть возможность создавать синонимы

имен полей.

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

В множество поведений любого объекта можно включить два списка с

предопределенными именами «PRE_TRIGGERS» и «POST_TRIGGERS». Список

PRE_TRIGGERS содержит объекты, обрабатывающие входящее сообщение. Как

правило, это объекты-условия. Такой подход называется фильтрацией [20].

Список POST_TRIGGERS содержит объекты, которые проверяют результат

воздействия и могут произвести откат. POST_TRIGGERS вызываются по окончании

действия транзакции при выполнении операции удаления транзакционных

зависимостей.

Все триггеры множеств и последовательностей можно разбить на две

классификации: это триггеры, следящие за целостностью множества

(последовательности), сохраняя отношение порядка на последовательности,

ограничение суммы чисел элементов множества и др.; и следящие за

целостностью одного элемента, что соответствует проверке значения на

соответствие домену.

Список PRE_TRIGGERS позволяет организовать ограничение доступа,

фильтруя сообщения, посланные объектом, ктороый не имеет полномочий для

выполнения команды, содержащейся в сообщении.

Список POST_TRIGGERS позволяет исключить часть данных из результата

выполненной объектом операции, создав тем самым локальное пользовательское

представление.

Впрочем, тема безопасности заслуживает отдельного рассмотрения. Как,

например, в [9] и [18].

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

Действие представляет собой объект типа “строка”, хранящий текст ДССП-

процедуры. Ссылка на действие может хранится в поле OBJKH объекта, через

который и происходит вызов действия. Алгоритм выбора выполняемого действия

рассматривается ниже. В интерфейсах объектов указаны идентификаторы

объектов, которые в поле OBJKH хранят идентификатор действия. Значения этих

объектов являются именем действия. Наиболее удобно использовать для этой

цели строковые объекты. Использование поля OBJKH позволяет выполнять одно и

то же действие для различных методов различных объектов.

При вызове действия с идентификатором OIDKH делается вызов слова с

именем kh$. Например, для объекта с OIDKH=0x00000DFC это будет

KH$00000DFC. Если возникает ситуация EXERR, значит слово в словаре

отсутствует и подлежит компиляции. Для компиляции текст действия

дополняется префиксом “: KH$ ” и суффиксом “ ;”, после чего

компилируется командой TEXEC и выполняется. Словарь действий называется

$KH_VOC.

При изменении текста метода необходимо полностью очистить словарь ДССП

$KH_VOC, хранящий откомпилированные действия, поскольку эти действия

содержат в своем коде абсолютные ссылки на прежнюю откомпилированную версию

действия. Впрочем, эта процедура очистки словаря выполняется лишь при

переопределении текста действия, что бывает достаточно редко.

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

В отсутствии классов, хранить методы в каждом объекте было бы слишком

накладно. Вынесение правил поведения в отдельный объект позволяет уменьшить

затраты на хранение объектов-данных. Математическая модель ООБД в [17],

также разделяет данные и поведения, что дополнительно дает возможность

переиспользовать поведение другого объекта.

Объект-поведение представляет собой множество объектов-методов, которое и

называется интерфейсом объекта.

При посылке на вход произвольного объекта OID2 сообщения OID1 (которое

тоже является объектом), сначала проверяется, содержится ли OID1 в

интерфейсе объекта OID2 (проверка идентичности). Если да, то выполняется

действие объекта OID1, иначе сравниваются значения OID1 и объектов

интерфейса (проверка эквивалентности). Если соответствие найдено,

выполняется действие, указанное в найденном в интерфейсе объекте.

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

Есть два основных способа управления объектами:

. Посылка сообщений

. Алгебра объектов

.

Определения операций Select и Pickup алгебры объектов можно найти в

[17]. Здесь оно не рассматривается по той причине, что является надстройкой

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

сообщений. То есть операции алгебры объектов могут быть заданы через

операции посылки сообщений, без исправления структуры СУБД. Полная алгебра

объектов является замкнутой и состоит из следующих операций: Select (,

Pickup (, Apply (, Expression Apply (, Project (, Combine (, Union (,

Interselect (, Subtract (, Collapse (, Assimilate (. Объектная алгебра

более выразительна, чем реляционная, поскольку поддерживает полиморфность.

Оператор Select, например, может работать с любыми видами операндов, а не

только с множествами.

Согласно [17], любое сообщение в системе является объектом. Любой

объект может иметь связанное с ним действие (knowhow), или не иметь его.

Алгоритм определения метода для выполнения

При посылке объекта проверяется, находится ли идентификатор объекта-

сообщения в интерфейсе объекта-получателя. Если да, то выполняется knowhow,

связанное с этим идентификатором. Если нет – проверяется, совпадает ли

значение объекта-сообщения со значением какого-либо метода из интерфейса

объекта-получателя. Если да, то выполняется связанное с этим методом

действие. Иначе возвращается объект fail.

Параметры методов

Набор_параметров (Blackboard) представляет собой множество меток,

аргументных пар { (L1, arg1), … , (Ln, argn) }. Li ?A, argi ?O для 1 ? i ?

n и ?i, j ? 1,…,n : i ? j ? Li ? Li.

Впрочем, базовые методы также используют передачу параметров через

стек, как более эффективный способ программирования.

Синтаксис посылки сообщения

Воздействие(Набор_параметров) (( Получатель. Объект, называемый

Воздействие (Invoker), является сообщением (message) и посылается к другому

объекту, названному Получателем (Reciver), используя Набор_параметров,

предоставляющий необходимые аргументы. Если параметры в Наборе_параметров

отсутствуют, то можно записать короче: Воздействие (( Получатель. Посланное

сообщение всегда возвращает объект, называемый Результат (Result).

Посылка простого сообщения

Пусть B – Набор_параметров и m и r – два объекта в O.

Примитивные взаимодействия

(1) m(B) (( fail ( fail; fail(B) (( r ( fail;

(2) m(B) (( null ( null; null(B) (( r ( null;

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

|Условие |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) образуют набор классов и объектов, поддерживающих полезные во

многих прикладных системах функции. Прикладные объекты представляют

прикладные системы конечных пользователей и обеспечивают функции,

уникальные для данной прикладной системы.

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