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

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

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

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

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

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

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). Одна и та же виртуальная память не может

быть загружена в два канала. При переходе от верхнего канала к нижнему

выполняется трансляция адреса.

[pic]

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

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

|Параметр канала |Семантика |

|NCHAN |Номер текущего канала |

|LOWCH |Нижний канал; в него вложен этот канал |

|CHGCTX |Признак изменения данных заголовка фрагмента |

|TEKADR |Текущая позиция для чтения/записи |

|SYNCADDR |Адрес начала заголовка текущего сегмента в нижнем |

| |канале |

|TEKADR0 |Позиция, соответствующая началу данных фрагмента |

|PREDADDR |Адрес заголовка предыдущего фрагмента (–1, если его |

| |нет) |

|NEXTADDR |Адрес заголовка следующего фрагмента (–1, если его |

| |нет) |

|BUSYLEN |Занятая длина |

|LEN |Выделенная длина |

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

|Операция |Семантика (все операции работают с текущим каналом) |

|IBS |Чтение байта из канала |

|OBS |Запись байта в канал |

|GOTO |Переход по адресу в канале |

|@GOTO |Переход по смещению в канале |

|UPSIZE |Выделить доп. память в конце канала и встать на ее |

| |начало |

|DEFRAG |Сделать виртуальную память непрерывной на уровне |

| |нижнего канала (т.е. однофрагментной) |

Начало виртуальной памяти соответствует нулевому значению TEKADR.

Доступ осуществляется через операции позиционирования (GOTO и @GOTO),

чтения байта (IBS) и записи байта (OBS). Остальные функции, реализуются

через них (например, чтение длинного слова). К памяти может быть применена

функция UPSIZE с аргументом, содержащим необходимое количество байт для

выделения. Память может гарантированно выделяться до заполнения всей

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

нижестоящему уровню о выделении дополнительной памяти. Если такой запрос

применяется к каналу ниже 5-го, соответствующего дисковому файлу, файл

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

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

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

ситуация NOMEMORY. При попытке доступа за пределы определенной виртуальной

памяти (например, чтение после расположения данных), возникает ситуация

OUTDATA.

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

Самостоятельное кэширование данных – неотъемлемая черта любой СУБД.

Кэш состоит из двух частей: очереди кэшируемых объектов и памяти для

кэшируемых объектов. Память для кэшируемых объектов – это оперативная

память, в которую объект загружается. В этой памяти могут располагаться

только те объекты, идентификаторы которых находятся в очереди кэшируемых

объектов. Удаляемый из очереди объект выгружается в дисковую память. В

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

(Persistent), т.е. они обязательно сохраняются на диске и могут быть

использованы после открытия базы данных для использования.

Задача управления кэшированием объектов подобна задаче управления

памятью в операционной системе. В операционной системе для организации

процесса обмена между оперативной и внешней памятью информация представлена

набором сегментов (блоки переменной длины) или страниц (блоки фиксированной

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

определяет состав сегментов или страниц в более быстродействующей основной

памяти. Таким образом, частота обращений к внешней памяти, а,

следовательно, и быстродействие двухуровневой памяти (уровень внешней

памяти и уровень оперативной памяти) в целом, существенно зависят от

выбранного алгоритма замещения. Наибольшее распространение получила

страничная структура памяти.

В дипломной работе роль страницы играет объект. Минимальную частоту

обращений к ВП (внешней памяти) давал бы алгоритм, замещающий те объекты в

ОП (оперативной памяти), обращение к которым в будущем произойдет через

максимально долгое время. Однако реализовать такой алгоритм невозможно,

поскольку заранее неизвестна информация о будущих обращениях к объектам

программой.

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

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

объект,

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

всех находившийся в оперативной памяти,

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

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

которым было обращение в течении времени (, назад от текущего момента,

5. Лестничный алгоритм (ЛЕСТН): в списке объектов при обращении к объекту

он меняется местами с объектом, находящемся ближе к голове списка. При

обращении к отсутствующему в ОП объекту объект, находящийся в последней

позиции вытесняется.

Для алгоритма замещения желательно, чтобы он обладал двумя отчасти

противоречивыми свойствами: с одной стороны, он должен сохранять в ОП

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

обновлять содержимое ОП при смене множества рабочих объектов.

Например, алгоритм РПРУ эффективен только в отношении быстрого

обновления ОП, он не выделяет в списке объектов объекты, обращения к

которым происходят чаще, чем к остальным. Алгоритм НДИ также позволяет

быстро обновлять содержимое ОП. Однако последовательность одиночных

обращений достаточной длины к объектам, находящимся во ВП, вытеснит из ОП

все объекты, к которым, в среднем, обращения происходят чаще всего.

В [1] описывается класс многоуровневых алгоритмов замещения (,

которые позволяют решить эту проблему. Они зависят от конечного числа

параметров и при адаптивном подборе этих параметров соединяют свойство

быстрого обновления части ОП со свойством сохранения в ОП тех объектов,

которые наиболее часто запрашиваются.

В дипломной работе решено использовать алгоритм замещения из класса (,

при следующих параметрах: лимит времени нахождения объекта в ОП

отсутствует, размеры подсписков на всех уровнях одинаковы, параметр l=1

(это соответствует алгоритму замещения НДИ для объектов всех подсписков;

если i – положение объекта в подсписке, и i ( l, то при обращении к нему

применяется алгоритм РПРУ, иначе НДИ).

Неэффективным является подход простого освобождения от объектов,

которые стоят в конце списка кэша, поскольку они могут быть малы по

размеру, а требуется загрузить объект, который занимает значительное

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

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

времени при их повторной загрузке.

Для определения подмножества объектов кэша, подлежащих вытеснению,

можно применить алгоритм решения задачи о рюкзаке. Если бы все объекты

имели одинаковую длину, без этого можно было бы обойтись. Хотя алгоритм

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

рекурсивного алгоритма, находящего решение за счет применения принципа

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

когда размер кэша составляет 32 объекта, поскольку множество выбранных

объектов можно представить битовыми полями в длинном слове. При большем

размере кэша возрастают потери памяти и быстродействия, и возникает вопрос

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

среде ДССП требует малых затрат ресурсов, а время расчета окупается за счет

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

оперативной.

3.5 Система управления журнализацией и восстановлением

Журнализация предназначена во-первых, для обеспечения возможности

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

базы данных после аппаратного сбоя. В ООБД журнализацию можно проводить на

трех уровнях: инфологическом, даталогическом и физическом. На

инфологическом уровне журнал фиксирует сообщения, циркулирующие в системе.

На даталогическом уровне фиксируется какие примитивы были вызваны на

выполнение сообщениями. На физическом уровне фиксируются низкоуровневые

операции: по какому адресу в какой виртуальной памяти производилась запись,

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

Обычные БД хранят мгновенный снимок модели предметной области. Любое

изменение в момент времени t некоторого объекта приводит к недоступности

состояния этого объекта в предыдущий момент времени. Интересно, что при

этом в большинстве развитых СУБД предыдущее состояние объекта сохраняется в

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

закрыта.

Для журнализации избран подход, примененный в СУБД Postgres,

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

М.Стоунбрейкера, как наиболее простой в реализации и предоставляющий

полезные возможности, недоступные в базах данных с обычным типом

журнализации (см. [23]). В этой системе, во-первых, не ведется обычная

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

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

оперативной памяти. Во-вторых, система управления памятью поддерживает

исторические данные. Запросы могут содержать временные характеристики

интересующих объектов. Реализационно эти два аспекта связаны.

СУБД, имеющие такой вид журнализации, называются темпоральными СУБД.

Основной тезис темпоральных систем состоит в том, что для любого объекта

данных, созданного в момент времени t1 и уничтоженного в момент времени t2,

в БД сохраняются (и доступны пользователям) все его состояния во временном

интервале [t1, t2). Система не только хранит информацию о прошлых

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

запросов.

Т.е. журнал состоит из меток времен и значений объектов. СУБД POSTGRES

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

функционирует на вычислительной аппаратуре, оснащенной статической

оперативной памятью, не теряющей информации при отключении внешнего

питания. Впрочем, затраты на статическую память компенсируются

быстродействием СУБД и дополнительными возможностями, приобретаемыми при

таком подходе, а именно: возможность получить значение объекта в

произвольный момент времени.

Вообще говоря, каждый объект в системе состоит из трех частей:

Заголовка объекта, данных и истории. В заголовке объекта имеется поле

VALUE, которое содержит ссылку на начало расположения внутри объекта данных

о его состоянии. Объект, с которым пользователь хочет работать,

автоматически загружается системой в кэш, где ему выделяются 4 канала:

1. Канал объекта в кэше

2. Канал объекта на диске

3. Канал данных объекта в кэше

4. Канал истории изменений объекта на диске

Прикладной программист не работает напрямую с каналами. С каналами

работают примитивы доступа к содержимому объекта. Прикладной программист

работает с объектами только через их идентификаторы. А идентификаторам

объектов ставятся в соответствие каналы в системе кэширования объектов.

3.6 Принципы реализации механизма согласованного управления

Область действия операции

Каждый объект обладает поведением, реализуемым через методы

(операции). Если операция работает только с внутренними данными объекта, то

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

– глобальной. Посланное к другому объекту сообщение порождает на нем

выполнение соответствующей операции. Через транзитивное замыкание можно

представить процесс порождения отношением предок – потомок.

Областью действия операции на объекте являются:

Данные состояния объекта, входные параметры операции, системные

объекты, а также все объекты, обладающие определенным поведением, если это

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

Воздействие операции

Все воздействия любой операции на объекте, попадают под одну из

четырех категорий: запрос, создание, модификация, удаление. Для каждой

операции на объекте определяются соответствующие множества.

Множество запросов QS(opi(O)) определяется рекурсивно как QS(opi(O)) =

LocalQS(opi(O)) ( GlobalQS(opi(O)), где

. LocalQS = (, если нет собственных ivj из O "запрошенных" операцией

opi. {O}, иначе.

. GlobalQS =

opi , посылает сообщение к Os для выполнения метода opj, где.

Аналогично определяются можества создания модификации и удаления

операции opi на объекте O.

Множество замен определяется как объединение множеств создания,

модификации и удаления. Конфликт операций – выполнение одного из следующих

условий:

1. US(opi(O)) ( US(opj(O')) ( (

2. QS(opi(O)) ( US(opj(O')) ( (

3. US(opi(O)) ( QS(opj(O')) ( (

Пользовательские транзакции можно рассматривать как операции над

специальным объектом базы данных.

Пользовательские операции могут быть разбиты на ряд шагов, каждый из

которых выполняет некоторую логическую единицу работы. Шаги эти также можно

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

разрыва. Точка разрыва ставится между двумя шагами на одном уровне любой

операции.

Объектно-ориентированное расписание

Для увеличения производительности СУБД, некоторые операции могут

взаимодействовать друг с другом в базе данных. Некоторые из этих операций

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

(псевдопараллельность) может приводить к произвольному чередованию операций

(или их шагов). Порядок чередования называется объектно-ориентированным

расписанием. Так как "пользовательские транзакции" являются только

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

объекте как пару (S,= 1- > ;

[20 WORD VCTR CHAN] [каналы. Начиная с 5-го]

VAR NCHAN [Номер текущего канала]

: !NCHAN ! NCHAN ;

5 VALUE NBASECH [Первый не базовый канал]

: GETDATA NCHAN 10 * + CHDATA ;

: PUTDATA NCHAN 10 * + ! CHDATA ;

[Размер заголовка блока в байтах]

FIX VAR HSIZE 10 ! HSIZE

: HSIZE+ HSIZE + ;

[Pred, Next, BusyLen, Len]

1 *4 VALUE ctfPREDADDR

[$M4] [как самодостаточный]

0 VALUE ctLOWCH [Нижний канал.]

[0=Оперативная/1=Дисковая память/2=Журнал/-1=свободен]

1 VALUE ctTEKADR [Логический адрес внутри участка (по данным)]

2 VALUE ctBUSYLEN [Длина фрагмента, занятая данными]

3 VALUE ctLEN [Максимальная допустимая длина данных фрагмента]

4 VALUE ctTEKADR0 [=TEKADR, когда TEKADR стоит на нулевом байте данных

фрагм]

5 VALUE ctNEXTADDR [Адрес начала заголовка следующего фрагмента (пф)]

6 VALUE ctPREDADDR [Адрес начала заголовка предыдущего фрагмента (пф)]

7 VALUE ctSYNCADDR [Адрес начала заголовка фрагмента (пф)]

8 VALUE ctCHGCTX [признак изменения контекста]

9 VALUE ct1STLONG [Первое число в канале]

[в начальном блоке в начальном слове данных лежит адрес начала данных]

: LOWCH ctLOWCH GETDATA ; : !LOWCH ctLOWCH PUTDATA ;

: TEKADR ctTEKADR GETDATA ; : !TEKADR ctTEKADR PUTDATA ;

: TEKADR0 ctTEKADR0 GETDATA ; : !TEKADR0 ctTEKADR0 PUTDATA ;

: TEKADR++ TEKADR 1+ !TEKADR ; : !+TEKADR TEKADR + !TEKADR ;

: BUSYLEN ctBUSYLEN GETDATA ; : !BUSYLEN ctBUSYLEN PUTDATA ;

: LEN ctLEN GETDATA ; : !LEN ctLEN PUTDATA ;

: NEXTADDR ctNEXTADDR GETDATA ; : !NEXTADDR ctNEXTADDR PUTDATA ;

: PREDADDR ctPREDADDR GETDATA ; : !PREDADDR ctPREDADDR PUTDATA ;

: SYNCADDR ctSYNCADDR GETDATA ; : !SYNCADDR ctSYNCADDR PUTDATA ;

: CHGCTX ctCHGCTX GETDATA ; : !CHGCTX ctCHGCTX PUTDATA ;

: FSTLONG ct1STLONG GETDATA ; : !FSTLONG ct1STLONG PUTDATA ;

TRAP NOMEMORY NOMEMORY#

: NOMEMORY# ."

No free memory" ;

TRAP OUTDATA OUTDATA#

: OUTDATA# ."

Out of data. " ;

TRAP OUTMEM OUTMEM#

: OUTMEM# ."

Out of memory. " ;

TRAP UNKCH UNKCH#

: UNKCH# ."

Unknown primitive channel:" NCHAN .D CR ;

TRAP O_NOTFND NOTFND#

: NOTFND# ."

Object not found. OID=" . CR ;

[*** Информация по каналу ***]

: IC CR

." NCHAN=" NCHAN .D SP ." LOWCH=" LOWCH .D CR

."SYNCADDR=" SYNCADDR .D SP ."PREDADDR=" PREDADDR .D SP ."NEXTADDR="

NEXTADDR .D CR

." BUSYLEN=" BUSYLEN .D SP ." LEN=" LEN .D CR

." TEKADR0=" TEKADR0 .D SP ." TEKADR=" TEKADR .D CR ;

CHANNEL DATACH "DATA." CONNECT DATACH

7.3 Менеджер виртуальной памяти

PROGRAM $M2

B16 [физическая организация памяти]

[вычисление физического адреса и номера базового канала]

:: : POSIX [addr(i)] NCHAN C NBASECH < BR+ LEAVE [addr nchan] D

GOTO DELTA2 S( NCHAN ) TOLOW POSIX [addr(i-1)] ;

:: : TOLOW LOWCH !NCHAN ;

[Пересчет адреса в адрес нижнего уровня: TEKADR(i) -> TEKADR(i-1)]

:: : DELTA2 SYNCADDR HSIZE + TEKADR TEKADR0 - + ;

:: : IBS EON OUTDATA OUTDATA# LAST?

TEKADR POSIX TEKADR++ S( NCHAN ) !NCHAN BSGOTO

NCHAN BR 0 IBS0 1 IBS1 [2 IBS2] ELSE UNKCH ;

:: : OBS EON OUTDATA OUTDATA# LAST?

TEKADR POSIX TEKADR++ S( NCHAN ) !NCHAN BSGOTO

NCHAN BR 0 OBS0 1 OBS1 [2 OBS2] ELSE UNKCH ;

: LAST? TEKADR BUSYLEN TEKADR0 + = IF0 LEAVE NEXTBLK ;

[переход для базового канала ]

: BSGOTO [ADDR] NCHAN BR 0 BSGOTO0 1 BSGOTO1 [2 BSGOTO2] ELSE UNKCH ;

: BSGOTO0 !TEKADR ;

: BSGOTO1 C !TEKADR HSIZE+ SPOS DATACH ;

[ : BSGOTO2 C !TEKADR HSIZE+ SPOS JOURCH ;]

0 %IF

: ADDR [PARAGRAF OFFSET] + [address] ; [Сейчас пгф=1 байту]

[Для файлов можно сделать неск. файлов и распределить по ним пространство]

%FI

: IBS0 TEKADR HSIZE+ MEMORY &0FF TEKADR++ ;

: IBS1 IB DATACH &0FF TEKADR++ ;

[: IBS2 IB JOURCH &0FF TEKADR++ ;]

: OBS0 &0FF TEKADR HSIZE+ ! MEMORY TEKADR++ ;

: OBS1 &0FF OB DATACH TEKADR++ ; [Запись байта]

[: OBS2 &0FF OB JOURCH TEKADR++ ;] [Запись байта]

:: : GOTO NCHAN NBASECH < BR+ BSGOTO VGOTO ;

: VGOTO TEKADR - @GOTO ;

[Переход по смещению]

:: : @GOTO C BRS @GOTO- D @GOTO+ ;

: @GOTO+ DO @GOTO1+ ;

: @GOTO- NEG DO @GOTO1- ;

: @GOTO1+

EON OUTDATA OUTDATA#

TEKADR TEKADR0 BUSYLEN + =

IF+ NEXTBLK TEKADR 1+ !TEKADR ;

: @GOTO1-

EON OUTDATA OUTDATA#

TEKADR TEKADR0 =

IF+ PREDBLK TEKADR 1- !TEKADR ;

: NEXTBLK CHGCTX IF+ SCTX NEXTADDR NOEXIST? !SYNCADDR RELCTX

TEKADR !TEKADR0 ;

: NOEXIST? [ADDR] C -1 = IF+ OUTDATA [ADDR] ;

[Pred, Next, BusyLen, Len]

:: : LCTX' [UPCH] PUSH TEKADR ILS ILS ILS ILS POP

NCHAN E2 !NCHAN !LOWCH !LEN !BUSYLEN !NEXTADDR !PREDADDR !SYNCADDR

0 !CHGCTX ;

[Грузить параметры канала]

:: : LCTX [newch] LCTX' 0 !TEKADR 0 !TEKADR0 ;

: RELCTX TEKADR0 TEKADR NCHAN SYNCADDR TOLOW GOTO LCTX !TEKADR !TEKADR0

;

: PREDBLK CHGCTX IF+ SCTX PREDADDR NOEXIST? !SYNCADDR RELCTX

TEKADR BUSYLEN - !TEKADR0 ;

: IBSC [CHAN] S( NCHAN ) !NCHAN IBS ;

: ILSC S( NCHAN ) !NCHAN ILS ;

: OBSC [N CHAN] S( NCHAN ) !NCHAN OBS ;

: IOBSCC [SRC DST] C2 IBSC C2 OBSC ;

: DO_IOBSCC [SRC_CH DST_CH N] S( NCHAN )

C3 !NCHAN 0 GOTO DO IOBSCC [SRC DST] ;

: IWS IBS IBS SWB &0 ;

: ILS IWS IWS SETHI ; [SWW &0]

: OWS C OBS SWB OBS ;

: OLS C OWS SWW OWS ;

[Перейти к конечному блоку]

: GOTOENDBK NEXTADDR -1 = EX+ BUSYLEN TEKADR0 +

NEXTADDR !SYNCADDR RELCTX C !TEKADR0 !TEKADR ;

: GOBOTTOM RP GOTOENDBK BUSYLEN TEKADR0 + GOTO ;

: LENVMEM GOBOTTOM TEKADR [LEN] ; [длина виртуальной памяти]

: LASTADDR SYNCADDR LEN + HSIZE+ ;

: OBS-0 NCHAN BR 0 OBS00 1 OBS01 [2 OBS02] ELSE OBS0N ;

: OBS00 0 OBS0 ; : OBS01 0 OBS1 ; [: OBS02 0 OBS2 ;] : OBS0N 0 OBS ;

[Спецификация: Размер увеличивается на N байт. Если это невозможно,

возникает исключительная ситуация NOMEMORY.

После работы мы стоим в том же канале в начале выделенного пространства.

]

: UPSIZE [N] GOBOTTOM TEKADR E2 UPSIZE' GOTO [] ;

: UPSIZE' [N] GOBOTTOM LEN BUSYLEN - CALCOST [HARD SOFT] UPSIZEI

C BR0 D UPSIZEO ;

: CALCOST [N FREE] C2C2 ] UPSIZE' ;

: USON1 S( NCHAN ) TOLOW BUSYLEN = BR+ USON_ADD USON_NEW ;

[Расширение увеличением длины фрагмента]

: USON_ADD C2 [N SYNCADDR N] UPSIZE' C BUSYLEN E2 - HSIZE - E2

[N LEN SYNCADDR] 3 *4 + GOTO OLS [N] [UPSIZEI] ;

[Расширение созданием нового фрагмента]

: USON_NEW C2 [N SYNCADDR N] [GOBOTTOM] C HSIZE+ UPSIZE'

[N SYNCADDR N] C2 -1 0 C4 TEKADR PUSH WRITECTX D 4+ GOTO POP OLS [N]

;

: WRITECTX [PRED NEXT BUSY LEN] C4 OLS C3 OLS C2 OLS C OLS DD DD ;

FIX VAR UPCONST 10 ! UPCONST [Этому числу байт кратно увеличение]

[Увеличение размера нижнего уровня]

[увеличение физического размера этого уровня]

: SCTX CHGCTX IF0 LEAVE 0 !CHGCTX NCHAN BR 0 NOP 1 SCTX1 [2 SCTX2]

3 NOP 4 NOP ELSE SCTXN ;

: SCTXN TEKADR NCHAN LEN BUSYLEN NEXTADDR

PREDADDR SYNCADDR TOLOW GOTO 4 DO OLS !NCHAN GOTO ;

: SAVEALL NOP ; [СОХРАНИТЬ ВЕСЬ КАНАЛ НА ПЕРВИЧНОМ УСТРОЙСТВЕ (ИСТОЧНИКЕ)]

: SCTX1 POS DATACH 8 SPOS DATACH BUSYLEN OL DATACH LEN OL DATACH SPOS

DATACH ;

[

: SCTX2 POS JOURCH 8 SPOS JOURCH BUSYLEN OL JOURCH LEN OL JOURCH SPOS

JOURCH ;

]

[Новая виртуальная память]

0 %IF

: NEWVM [N] TEKADR C2 HSIZE+ UPSIZE GOTO -1 -1 C3 C WRITECTX D ;

%FI

: NEWVM [N] C HSIZE+ UPSIZE TEKADR PUSH -1 -1 0 C4 WRITECTX DO OBS-0

POP [SYNCADR] ;

: END? NEXTADDR -1 = TEKADR BUSYLEN TEKADR0 + = & ;

: NEWVM1 [N] C HSIZE+ UPSIZE TEKADR PUSH -1 -1 E3 C WRITECTX WRI_DATA

POP [SYNCADR] ;

: LOADCH0 0 !NCHAN 0 !LOWCH 0 !TEKADR 0 !BUSYLEN

TOTMEMLEN !LEN 0 !TEKADR0 0 !SYNCADDR -1 !NEXTADDR -1 !PREDADDR ;

[ДЛЯ БАЗОВЫХ КАНАЛОВ LOWCH=NCHAN]

7.4 Система управления хранением объектов

PROGRAM $SOMS

B16

[СИСТЕМА УПРАВЛЕНИЯ ХРАНЕНИЕМ ОБЪЕКТОВ]

FIX LONG VAR MAXID

1 ! MAXID

: NEWID MAXID !1+ MAXID ;

: DEFMAXID 6 EL_MAX 1+ ! MAXID ;

[5 КАНАЛ = ОПЕРАТИВНАЯ ПАМЯТЬ; 6 КАНАЛ = ДИСКОВАЯ ПАМЯТЬ]

: L_SUHO 0 !NCHAN 0 GOTO 5 LCTX 1 !NCHAN 0 GOTO 6 LCTX ;

[создание структуры СУХО для ОП]

[9 -- Размер, занимаемый элементом списка]

LONG VAR SIZE_EL 8 ! SIZE_EL

[создать новый объект]

ACT VAR WRI_DATA

: M.NEWOBJ [SIZE OID] 0 E2 8 5 X.NEWOBJ [] ;

: D.NEWOBJ [SIZE OID] 1 E2 8 6 X.NEWOBJ [] ;

: X.NEWOBJ [SIZE LOWCH OID SIZE_EL DIR_CHAN] C PUSH S( NCHAN ) !NCHAN

UPSIZE

[.. OID] OLS [basechan] !NCHAN NEWVM1 [SYNCADDR] POP !NCHAN OLS []

;

:: : M.VIEW 5 !NCHAN CR ."RAM:" VIEW.OBJ' ;

:: : D.VIEW 6 !NCHAN CR ."HDD:" VIEW.OBJ' ;

:: : A.VIEW M.VIEW D.VIEW ;

: IC.VIEW [A L] SHR SHR E2 GOTO DO IC1.V ;

: IC1.V TEKADR CR .D #> TOB SP SP ILS .D ;

: VIEW.OBJ' 0 GOTO ILS D [Пропустили длину элемента]

CR ." OID ADDRESS" RP SHOWPAROBJ ;

: SHOWPAROBJ END? EX+ ILS C BR0 SPO1 SPO2 ;

: SPO1 D ILS D ;

: SPO2 CR .D SP ILS .D SP ;

: M.DEL [OID] 5 X.DEL ; : D.DEL [OID] 6 X.DEL ;

: A.DEL [OID] C M.DEL D.DEL ;

ACT VAR EL_AVAR

:: : X.DEL [OID NCHAN] EL_FIND [OID 1/0] IF+ EL_DEL D ;

[найти элемент в списке по ID и встать на след. за OID слово]

: EL_DEL -4 @GOTO 0 OLS ;

:: : EL_FIND [OID NCHAN] '' EL_COMPAR ! EL_AVAR EL_PEREBOR ;

: EL_PEREBOR !NCHAN 0 GOTO ILS D RP EL_FIND0 [OID 1/0] ;

: EL_FIND0 END? 0 E2 EX+ D ILS C BR0 D EL_AVAR ILS D ;

: EL_COMPAR [OUR_OID TEK_OID] C2 = C EX+ D ;

:: : EL_MAX [DIR-NCHAN] 0 E2 '' MAX ! EL_AVAR EL_PEREBOR D [OID] ;

:: : DB.NEW !1 MAXID WOPEN DATACH

-1 OL DATACH -1 OL DATACH 14 OL DATACH 14 OL DATACH

-1 OL DATACH -1 OL DATACH 4 OL DATACH 4 OL DATACH

8 OL DATACH CLOSE DATACH

[ WOPEN JOURCH

-1 OL JOURCH -1 OL JOURCH 14 OL JOURCH 14 OL JOURCH

-1 OL JOURCH -1 OL JOURCH 4 OL JOURCH 4 OL JOURCH

8 OL JOURCH CLOSE JOURCH ]

DB.OPEN ;

: DB.CLOSE CLOSE DATACH [CLOSE JOURCH] ;

: DB.OPEN -1 !!! CHDATA

[DATA]

OPEN DATACH 1 !NCHAN 0 !TEKADR 0 !TEKADR0 1 !LOWCH

IL DATACH !PREDADDR IL DATACH !NEXTADDR 0 !SYNCADDR

IL DATACH !BUSYLEN IL DATACH !LEN 6 LCTX

[RAM]

0 !NCHAN 0 !LOWCH 0 !TEKADR 0 !BUSYLEN

TOTMEMLEN !LEN 0 !TEKADR0 0 !SYNCADDR -1 !NEXTADDR -1 !PREDADDR

'' WRI_8OLS ! WRI_DATA [длина элемента каталога]

4 [0]

GOTO NCHAN E2 LCTX [Открыли историю в канале] !NCHAN [O N]

C 3 Channels G_VAL ILS GOTO LCTX [временно открыли канал данных

напрямую с жесткого диска]

[LOADDM]

NOP [Здесь нужно установиться на объект в памяти и канал данных перекл. на

него]

DD [] ;

VAR NCHANDAT

VAR NCHANOBJ LONG VAR LENDAT

: COPY_DAT1 [] NCHANOBJ 0 GOTOC [NCHANOBJ] NCHAN 0 GOTO 8 DO_IOBSCC D 14

OLS

0 OLS 10 GOTOC NCHAN 4 DO_IOBSCC DD -1 OLS -1 OLS LENDAT OLS LENDAT OLS

COPY_DAT ;

: GOTOC [NCHAN n] C2 S( NCHAN ) !NCHAN GOTO [NCHAN] ;

: COPY_DAT [] NCHANDAT NCHAN [SRC_CH DST_CH]

C2 !NCHAN LENVMEM [SRC_CH DST_CH LEN] 0 GOTO DO_IOBSCC DD ;

8. Контрольный пример, демонстрирующий возможности технологии

DB.NEW

Создадим объект "Поведение клоуна" для клоуна

[] "Поведение клоуна" CLONE_STR

[oid_str] OIDSET GET_BHR CLONE

[oid_str oid] SET_NAMEOBJ [oid]

Создадим объект "Клоун":

[.. ] "Клоун" CLONE_STR

[.. oid_str] CLONE_AGG

[.. oid_str oid] SET_NAMEOBJ [.. oid]

Определим ему поведение

[oid_bhr oid] SET_BHR

Определим в нем поля: X, Y, Цвет

"X" NEWFID SET_NAMEFID [fid] OIDINT "Клоун" NAMEOID AGG+F []

В ДССП можно определить новое слово

: NEWFIELD [ "Имя объекта" "Имя поля"] NEWFID SET_NAMEFID [A L FID]

OIDINT C4C4 NAMEOID AGG+F DD [] ;

"Клоун" "Y" NEWFIELD

"Клоун" "Цвет" NEWFIELD

Создадим методы.

Создать метод "Идти".

"" CLONE_STR [oid_kh]

[oid_kh] "Идти" CLONE_STR E2 C2 SET_KH [OID_STRKH]

"Поведение клоуна" NAMEOBJ SET+E

Аналогично создаются другие методы

...

Подготовка для вызова метода по идентификатору:

"Идти" CLONE_STR C "Клоун" NAMEOBJ METHOD? E2 DELOBJ

Подготовка для вызова метода по имени:

"Идти" CLONE_STR

Вызов

[oid] 0 "Клоун" NAMEOBJ [oid_mth 0 oid_obj] SEND

9. Оценка трудоемкости разработки ПО с использованием традиционного и

предлагаемого подходов

В этом разделе будет проведен качественный анализ трудоемкости. Это

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

классических ЯВУ.

Далее, в качестве примера, рассматривается следующая задача:

Клиенты имеют счета. Каждый счет увеличить на 10% и после этого

пометить пользователя как получившего премию.

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

В качестве примера можно привести FoxPro 2.6 [11]. В ней есть

недостаточное для обычных нужд подмножество SQL (SELECT, INSERT INTO);

обычно взаимодействие с БД происходит с помощью операторов REPLACE,

SCATTER, GATHER, SCAN … ENDSCAN и непосредственного присвоения с указанием

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

программы практически непереносимы на клиент-серверные технологии, логика

программ весьма сложна и приводит при программировании к трудно

обнаруживаемым ошибкам. Достоинствами же являются простота реализации языка

таких СУБД и малая требовательность к ресурсам.

Программный код обработки (MS FoxPro 2.6):

SELECT CLIENT

SCAN

SELECT SCHET

REPLACE SUMMA WITH SUMMA*1.1 FOR SCHET.NUM_SCH=CLIENT.NUM_SCH

SELECT CLIENT

REPLACE PREMIA WITH .T.

ENDSCAN

9.2 Реляционные базы данных

Реализация языка SQL позволяет работать с базой данных исключительно

средствами SQL. Поддерживаются триггеры, отношения между таблицами,

хранимые процедуры. Это типичные клиент-серверные СУБД. Управление

целостностью данных возлагается на СУБД. Триггеры позволяют вынести

практически все проверки из логики программы. Недостатком является

необходимость нормализации таблиц, что затрудняет добавление новых таблиц

при сопровождении программного средства, а иногда требует перенормализации,

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

новые ошибки.

Программный код обработки (MS Visual FoxPro 3.0 и выше):

BEGIN TRANSACTION

UPDATE SCHET SET SUMMA=SUMMA*1.1

WHERE NUM_SCH IN (SELECT NUM_SCH FROM CLIENT)

UPDATE CLIENT SET PREMIA = .T.

END TRANSACTION

9.3 Объектно-ориентированные базы данных

Позволяют хранить данные произвольной степени сложности (детали САПР)

и вида (звук, изображение). Позволяют программировать на уровне

инфологической модели, т.е. исчезают заботы о нормализации. Новые алгоритмы

могут работать одновременно со старыми, обеспечивая преемственность.

Например, если бухгалтерские проводки в следующем году проходят по новой

схеме, переход на нужную схему в зависимости от даты СУБД выполнит сама.

Реализация для ООБД на формальном языке:

{«*»(1.1) ~> (summa((Client.num_sch=Schet.num_sch(Schet, Client)),

«:=»(True) ~> (Premia(Client)}

Порядок действий:

1. Умножение счетов на 1.1

1. Операция селекции выбирает множество счетов

2. Операция проекции выбирает интересующую часть счета – сумму

3. На суммы посылается операция «умножить» с аргументом 1.1

2. Пометка клиентов, как получивших премию

1. Операция проекции выделяет интересующую часть информации о клиенте –

атрибут «премия»

2. Операция присвоения посылается на выделенный атрибут «премия» с

аргументом True

Примечание 1: В операция селекции и проекции имеется некоторое отличие

от операций реляционной алгебры. Например, операция проекции, выбирающая

сумму, возвращает множество сумм. На самом деле множество сумм содержит не

суммы, а идентификаторы атомарных объектов, хранящих суммы. Поэтому

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

данных с оригинальным объектом-хранителем (счетом).

Примечание 2: Оба изменения происходят в пределах одной транзакции,

поскольку эти действия являются экземплярами одного множества. Оба порядка

действий: «сначала умножить, потом – пометить» и «Сначала пометить, потом –

умножить» равноправны, поскольку действия хранятся в множестве. Если

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

необходимо использовать не множество, а последовательность.

Операции над сложными структурами транзитивно распространяются на

операции над компонентами по алгоритмам, описанным выше в разделе

«Уточнение методов решения задачи». Таким образом, нет нужды во многих

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

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

обработки циклов.

9.4 Будущее применения различных баз данных

В прошлые годы много внимания уделялось вопросу трудоемкости

разработки программного обеспечения. Возросшая сложность программ и объемы

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

нуля». Теперь вперед выходят технологии, позволяющие создавать легко

сопровождаемые программы.

Но реляционные базы данных, скорее всего, по-прежнему останутся в

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

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

кино, которых не вытеснило телевидение.

10. Литература

[1] О.И.Авен Я.А.Коган “Управление вычислительным процессом” М.

Энергия 1978

[2] А.М.Андреев Д.В.Березкин, Ю.А.Кантонистов «Среда и хранилище:

ООБД»

Мир ПК №4 1998 (стр 74-81)

[3] М. Аткинсон, Ф. Бансилон и др. «Манифест систем объектно-

ориентированных баз данных», СУБД № 4 1995

[4] В.Бобров "Объектно-ориентированные базы данных, мультимедийные

типы данных и их обработка" Read.Me №4, 1996

[5] Н.П.Брусенцов, В.Б.Захаров и др. «Развиваемый адаптивный язык РАЯ

диалоговой системы программирования ДССП» Москва МГУ 1987

[6] Бурцев А.А "Параллельное программирование. Учебное пособие по

курсу "Операционные системы" - Обнинск : ИАТЭ, 1994 - 90 с.

[7] Бурцев А.А. «Сопрограммный механизм в ДССП как основа для

построения мониторов параллельных процессов»

[8] Г.Буч «Объектно-ориентированное проектирование (с примерами

применения)» М.Конкорд 1992

[9] К.Дж.Дейт «Введение в системы баз данных» 1998 Киев Диалектика

[10] Мутушев Д.М. Филиппов В.И. "Объектно-ориентированные базы данных"

Программирование. - М., 1995 №6 стр. 59-76

[11] В.Ремеев «FoxPro. Версия 2.5 для MS-DOS. Описание команд и

функций» М. «Мистраль» 1994

[12]СУБД № 2 1995 «Системы баз данных третьего поколения: Манифест»

[13]СУБД № 1 1996 «Стандарт систем управления объектными базами данных

ODMG-93: краткий обзор и оценка состояния» Л.А.Калиниченко

[14]СУБД № 1 1996 «ТРЕТИЙ МАНИФЕСТ» Х.Дарвин, К.Дэйт

[15]СУБД № 5-6 1996 “Введение в СУБД часть 9” стр. 136-153 С.Д.

Кузнецов

[16]Data & Knowledge Engineeging №15 (1995) стр 169-183 “Selection of

object surrogates to support clustering” Jukka Teuhola

[17] Data & Knowledge Engineering. Amsterdam 1996 Том 18 №1 стр.29-54

"Unifying data, behaviours, and messages in object-oriented databases"

Sylvia L. Osborn, Li Yu

[18] IEEE Transactions On Knowledge And Data Engineering Том 7 №2

Апрель 1995 стр. 274-292 «Security Constraint Processing in a Multilevel

Secure Distributed Database Management System» B.Thuraisingham, W.Ford

[19] Journal of systems and software - N.Y., 1996 Том 35 №3 стр. 169-

183

Shah P. Wong J. "Concurency control in a object-oriented data base

system"

Документы в Internet (http://www.citforum.ru):

[20] В. Индриков, АО ВЕСТЬ “Объектно-ориентированный подход и

современные мониторы транзакций”

[21] Л.Калиниченко “Архитектуры и технологии разработки

интероперабельных систем”, Институт проблем информатики РАН

[22] С.Д. Кузнецов "Основы современных баз данных"

[23] С. Кузнецов “Безопасность и целостность, или Худший враг себе -

это ты сам”

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