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

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

МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОНИКИ И МАТЕМАТИКИ

Кафедра автоматизации и Интеллектуализации Действий Управления

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

К дипломной работе

На тему: «Разработка макета системы управления
объектно-ориентированной базой данных»

Студент

Управляющий дипломной работы:

Особая часть:

М О С К В А

1 9 9 9

Содержание

1. Введение………………………………………………………………………………………………………………………….. 3

1.1 Предпосылки возникновения объектно-ориентированных баз данных………………………………………….. 3

1.2 Подходы в разработке ООБД……………………………………………………………………………………………. 4

1.3 Лаконичный сравнительный анализ постреляционных и обычных баз данных…………….. 5

1.4 Основания дипломной работы………………………………………………………………………………………… 5

1.5 Анализ приобретенного результата……………………………………………………………………………………… 7

2. Уточнение способов решения задачки…………………………………………………………………… 8

2.1 Наследование………………………………………………………………………………………………………………….. 8

2.2 Инкапсуляция……………………………………………………………………………………………………………….. 10

2.3 Идентификатор объекта…………………………………………………………………………………………………. 11

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

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

2.6 действие (knowhow)………………………………………………………………………………………………………. 14

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

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

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

3. Разработка структуры СУ………………………………………………………………………………………… 18

3.1 Положение дел в области интероперабельности систем…………………………………………………. 18

3.2 Менеджер памяти…………………………………………………………………………………………………………… 20

3.3 Виртуальная память и каналы………………………………………………………………………………………. 20

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

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

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

4. системы……………………………………………………………………………………………… 28

4.2 Строение объекта…………………………………………………………………………………………………………… 28

4.3 Контекст транзакции……………………………………………………………………………………………………… 30

5. Описание операций над объектами в БД…………………………………………………………. 31

6. Требования к техническим и программным средствам……………………………. 33

7. Реализация макета……………………………………………………………………………………………. 34

7.1 Построитель…………………………………………………………………………………………………………………… 34

7.2 Заголовочный модуль для каналов……………………………………………………………………………….. 34

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

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

7.5 Система управления каналами……………………………………………………………………………………… 39

7.6 Работа с базисными объектами……………………………………………………………………………………….. 40

7.7 Выполнение действий……………………………………………………………………………………………………. 42

7.8 кэширование объектов………………………………………………………………………………………………….. 42

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

9. Оценка трудозатратности разработки ПО с внедрением обычного и предлагаемого подходов………………………………………………………………………………………….. 45

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

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

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

9.4 Будущее внедрения разных баз данных…………………………………………………………………. 46

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

1. Введение

1.1 Предпосылки возникновения

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

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

На шаге зарождения технологии баз данных при построении какой-нибудь базы данных строилась физическая модель. С накоп­лени­ем опыта сделалось понятно, что нужен переход к даталогической модели, ко­торая дозволяет абстрагироваться от определенной СУБД. Возникло поня­тие схемы базы данных, описывающей компанию данных в СУБД. Программки стали работать с базой данных не впрямую, а через схему БД. Таковой подход обеспечил возможность поменять струк­туру БД без необходимости изменять логику программ. Возникновение и стандартизация SQL предоставила единый интерфейс для работы с данными. Иерархическая и сетевая модели баз данных стали применяться очень изредка. Это было вызвано, до этого всего, труд­ностью модификации схем иерар­хических и сетевых баз данных и силь­но зависящей от приложений навигацией в этих базах данных.

Дальше, развитие объектно-ориенти­рован­ного анализа и объ­ектно-ориентированного про­ек­ти­­ро­ва­ния как эффектив­ных под­ходов для формализации пред­мет­ной о­лас­ти, при­ве­ло к появ­ле­нию инфо­ло­ги­ческой модели пред­мет­ной о­ласти. сейчас, при разработке базы дан­­ных составлялось три модели пред­став­ле­ния инфы пред­метной области: инфо­логическая, да­­та­логическая и физическая, не счи­­тая локальных пользовательских пред­став­лений.

Рис 1:

Так как физи­ческая модель добивалась вербования профессионала в области определенной СУБД для получения действенного размещения дан­ных, физическая модель стала строиться самой СУБД из схемы БД, вводимой поль­зователем на базе дата­логической модели предметной области. Потом возникли CASE-средства, дозволяющие создавать инфо­логи­ческую модель предметной области и транслирующие ее в дата­логи­ческую модель.

Чудилось бы, что цель достигнута, – проектировщик работает толь­ко с инфо­логи­ческой моделью, но по сути, до того времени, пока работа происходит с реля­ционной базой данных, существует разрыв меж­ду языком программирования (логикой поль­зователя) и языком описания данных (представлением данных), который преодо­левать дол­жен прог­рам­мист. Сущность разрыва можно сконструировать так: воз­мож­ности ра­бо­ты с данными программки и с данными СУБД должны быть оди­наковы.

В конце 80-х – начале 90-х годов общее внедрение персо­наль­ных компов привело к развитию мультимедиа-технологий и на­настолько­ных САПР, структуры данных в каких очень сложны для про­цедур­ного программирования либо же необыкновенны (нап­ример, звук). Это, также то, что объектно-ориентированное программирование позво­ляет су­щест­венно понизить сложность разработки и обеспечить адекватное пред­став­ле­нию моделирование предметной области, при­вело к тому, что в области языков програм­мирования вышло сли­яние стилей языков вы­сокого уровня. Доминирующим под­ходом сделалось внедрение в их технологий объектно-ориентированного прог­рам­ми­рова­ния. Не остались в стороне и языки, интегрированные в СУБД. В качестве примера выше­изло­женного можно привести продукт Visual FoxPro компании Microsoft. Эта СУБД обла­дает объектно-ориен­тированным языком прог­рам­ми­ро­вания, но, на самом деле, является реля­цион­ной СУБД, так как хранимые дан­ные представлены в виде таб­лиц, а таблицы пред­ставляют собой мно­жество кортежей, которые содер­жат атомарные значения. Такое несо­­ответствие и привело к буму в области разработки постреляционных баз данных.

Сложившаяся ситуация хотя кое-чем и припоминает время перехода к реляционным базам данных, но почти во всем и отли­чается. До этого всего, отсутствует мате­мати­чес­кая модель, кото­рая бы­ла бы совершенно точно признана всеми ведущими разра­ботчиками пост­ре­ляционных СУБД. Нет документа, который одноз­начно опре­разделял бы требования к таковым СУБД. И, в конце концов, нет самой системы, которая числилась бы образцом для остальных систем, как это было с СУБД System-R компании IBM.

Одним из главных критериев выбора СУБД постоянно была произ­водительность. Одна­ко, невзирая на то, что объектно-ориентированные базы данных есть уже около 10 лет, обычных тестов на про­из­водительность пока нет. Тому есть несколько обстоятельств: отсутствие обычного языка запросов, канонических приложений, разница в архи­тектуре и т.д.

Что все-таки есть? Имеется бессчетный опыт разработок, нап­ри­мер Jasmine, POSTGRES, и остальных. Три документа, содержащих поже­ла­ния относительно возмож­ностей постреляционных СУБД : [3], [12] и [14].

1.2 Подходы в разработке ООБД

За время существования баз данных накоплено большущее количество инфор­мации. Создано большущее количество приложе­ний для работы с базами данных. Это при­вело к возникновению 2-ух кон­ку­ри­рующих концепций архитектур постреляционных СУБД:

1. Объектно-реляционные базы данных

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

Объектно-реляционные базы данных представляют собой реля­цион­ные базы дан­ных, дополненные надстройкой, пред­ставляющей эти дан­ные как объекты. Все как и раньше хранится в ви­де таблиц. Этот под­ход дозволяет плавненько перейти от технологии хра­ни­лища таблиц к технологии хранилища объектов. Остается воз­можность подборки данных при помощи SQL-запросов. Сам SQL расширен командами работы с объ­ектами. Более известным про­дуктом, в каком реализован подоб­ный подход является Oracle ver.8. Комитет ANSI X3H2, разработавший стан­дарт SQL–92, на данный момент ра­бо­та­ет над SQL3. Главными усо­вер­шен­ство­ваниями в SQL3 должны стать возможность процедурного доступа на­равне с декларативным и под­держка объектов. Главным недос­тат­ком объ­ект­но-реляционных СУБД является необходимость разбирать объ­екты для размещения их в таблицах и собирать их для передачи поль­зователю из таблиц [2].

Объектно-ориентированные базы данных хранят объекты цели­ком. Для подборки объектов при помощи запросов разра­батывается язык OQL (Object Query Language), в который был вклю­чен эталон SQL’92. Единство описания структуры БД достигается при­менением языка определения объектов ODL (Object Definition Language), пред­ло­женного ODMG (Object Database Management Group), являющегося расширением языка IDL. Эти виды баз данных владеют высочайшей произ­води­тель­но­стью, нередко в несколько раз наиболее высочайшей, чем реляционные базы дан­ных. Более известными ООСУБД явля­ются Jasmine, ObjectStore и POET.

Из российских разработок в области пост­реляционных баз дан­ных достоверно извест­но только о существовании ООСУБД ODB-Jupiter. Похоже, она была написана специ­ально для сотворения продукта ODB-Text. По последней мере, ни о каких остальных приложениях написанных на ODB-Jupiter ничего не понятно. Также в Internet было найдено опи­сание некоторой российскей объектно-ориентированной базы данных вер­сии 1.2. Поточнее, это был модуль, предоставляющий функции объектно-ориен­ти­ро­ван­ной СУБД. Доку­мент даже не имел наименования. В нем деталь­но рассматривалась орга­низа­ция хранения данных и принцип работы. Похоже, разработка обос­новывалась только на принципах, которым долж­на удовлетворять СУООБД. Более увлекательная мысль: предназначение строчкам неповторимых идентификаторов и удаление строк лишь при упаковке базы. Это дает значимый выигрыш в сопоставлении строк, потому что объекты-строки с схожим содержанием имеют однообразные идентификаторы.

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

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

Хотя есть некие сходства, как, к примеру, исполь­зование указателей и вложенная структура записей в сетевой модели. Но нужно отметить, что СУООБД употребляют логические указатели для обеспечения целостности, также поддерживают иерархию классов, наследование и способы. Таковых средств нет в иерархических и сете­вых моделях [4].

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

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

1.4 Основания дипломной работы

В отношении избранных математических моделей

Значимая часть данной дипломной работы основывается на 2-ух мате­мати­чес­ких моделях.

Модель одного представления данных поведений
и сообщений в объектно-ориентированной базе данных

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

Модель согласованного управления в объектно-ориентированной базе данных

Эта модель [19] также оказала существенное воздействие на данную работу, так как дополнила собой модель представления данных. Ни одна современная система управ­ления базой данных не может обойтись без подсистемы транзакций. Природа тран­зак­ций в таковых при­ложениях, как CAD, мультимедийные базы данных, является весь­ма раз­лич­ной. Эти приложения характеризуются вместе выпол­ня­емыми продол­обитатель­ными транзакциями с случайными опера­ци­ями. У длительных поль­клича­тель­ских транзакций время выпол­не­ния быть может растянуто на часы, а то и деньки. Это усло­вие при­водит к тому, что отлично извест­ный, и ставший уже традиционным для тра­ди­ци­он­ных баз данных, кри­те­рий сериализуемости становится непри­меним конкретно.

О са­мом аспекты сериализуемости и спо­собах реализации меха­низ­ма транзакций довольно тщательно из­ло­жено в [9] и [22].

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

Остальные работы, также повлиявшие на компанию структуры системы управления

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

Принципы журнализации взяты из системы POSTGRES [23] и [15].

Принципы кэширования взяты из [1].

В отношении языка реализации

Было принято решение реализовывать макет СУООБД на ДССП. ДССП – диалоговая система структурного программирования – была разра­ботана в 1980 году Н.П.Брусенцовым в МГУ [5]. Система имеет под собой теоре­ти­ческое обоснование. Принцип ДССП «Слово есть слово», т.е. одно слово программки соответствует одному слову кода. Принципы управляющих конструкций наследуются от троичной вычислительной машинки Сетунь-70, имевшей память на магнитных сердечниках. Словарь и обозначения – от языка Ч.Мура Forth. ДССП превосходит Forth по почти всем характеристикам. язык ДССП владеет значительно наиболее низ­кой, чем язык ассемблера трудозатратностью в прог­рам­­ми­ро­ва­нии, не усту­пая ему в компактности кода и быстродействии, позво­ляет про­верять работу подпрограмм в интерактивном режиме и имеет возможность моди­фи­кации прог­рамм фактически без внесения из­ме­нений в осталь­ные части ко­да.

Главные черты ДССП:

· Двухстековая архитектура

· Оборотная польская запись

· Словари

· Поддержка нисходящего программирования

· Интегрированный отладчик с рекомпиляцией

· Высокоуровневые структуры данных и операции

· Высокоуровневый механизм программных прерываний и исключительных ситуаций

· Малогабаритный код

· Упругость, мобильность, наращиваемость

· наличие сопрограммного механизма

К огорчению, при всех этих плюсах, ДССП на данный мо­мент является лишь системой программирования. Она не предос­тав­ляет сервис СУБД и не взаи­мо­действует ни с одной СУБД. Данная рабо­та ориентирована на то, чтоб обеспечить ДССП воз­можность обра­батывать данные в качестве СУБД, создав тем дешевенький (Jasmine стоит порядка $15000), но действенный инструмент, спо­соб­ный работать даже в самых беспритязательных критериях, которые так нередко встре­чаются на данный момент в Рф. Разработка не ограничивается расширением ДССП и способна работать в ка­честве сервера ООБД на файл-сервере ЛВС.

1.5 анализ приобретенного результата

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

В виде программного кода реализовано:

· Создание, открытие ООБД

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

· Система управления каналами

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

· Создание главных объектов

· Клонирование объектов

· Переопределение поведений и действий

· Изменение данных в объектах

· Журнализация конфигураций в объектах

· Выполнение действий (knowhow)

2. Уточнение способов решения задачки

2.1 Наследование

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

Совокупы параметров объекта в объектно-ориентированной базе данных уделя­ет­ся большее внимание, чем в почти всех объектно-ориентированных языках прог­рам­миро­ва­ния, так как они являются также целью запросов. объект=состояние+поведение. Почаще всего существует лишь одна иерархия наследования. Этот подход перебежал и в C++. Но, может быть разделение иерархий наследования данных и наследования по­ве­де­ний. Не постоянно лучше иметь буквально такую же иерархию наследования пове­де­ния, как и иерархию наследования параметров. Разделение этих 2-ух иерархий увеличивает способности переиспользования (reuse) поведений.

Значение переиспользования поведений

Представим, мы имеем класс Студент и желаем сделать класс Аспирант. Чтоб стать аспирантом, человек должен поначалу получить высшее образование как студент. В общем случае экземпляры этих классов различны. Мы не можем наследовать Аспирант от Студент, т.к. аспирант не является студентом. В неприятном случае, мы имели бы право разглядывать аспиранта как экземпляр класса Аспирант и, с этим же правом, как экземпляр класса студент. Тем не наименее, оба класса владеют общими атрибутами, таки­ми как: имя, адресок, номер_личной_карточки, также большинством общих пове­де­ний. Это событие вдохновляет сделать класс Аспирант, унаследовав характеристики и по­веде­ния Студента. Но, хотя экземпляры класса Аспирант будут подмножеством всех экземпляров класса Студент (т.к. все аспиранты были студентами, но не все студенты стали аспирантами), это

Рис. 2:

характеристики классов Студент и Аспирант наследуются от класса Учащийся.

способы из суперклассов. В приложении к наследованию поведений это значит, что класс-ученик (demandclass) состоит в отношении Переиспользовать-от (Reuse-Of) с остальным классом, именуемым классом-учителем (supplyclass), и класс-ученик должен наследовать все поведения от класса-учителя.

Образцы наследования: классы либо макеты?

В системе отсутствуют классы и типы. Роль класса может брать на себя хоть какой объект, именуемый объектом-образцом. Таковой вид наследования именуется насле­до­ванием на базе прототипов.

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

Независимо от модели наследования (классы либо макеты) существует две раз­личные стратегии реализации механизма наследования: делегирование и конкате­цивилизация.

метод наследования: делегирование либо конкатенация?

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

И конкатенация, и делегирование имеют свои плюсы и недочеты. Делеги­рование обеспечивает возможность гибкого распространения конфигураций: хоть какое измене­ние параметров родителя автоматом отражается на потомках. Подход, использующий конкатенацию, допускает изменение параметров родителей и потомков независимо друг от друга, что также быть может полезно в почти всех ситуациях. Делегирование обычно тре­бует наименьших издержек по памяти, в то время как конкатенация является наиболее эффек­тивной по времени. Simula и C++ являются примерами языков, которые реализуют на­следование на базе классов с внедрением делегирования. В Smalltalk реализовано наследование на базе прототипов с внедрением делегирования.

Обоснование избранного механизма наследования

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

Система поддерживает множественное наследование. Необходимость множест­венного наследования остается предметом жарких споров. Практика гласит о том, что «множественное наследование играет роль парашюта: в нем нет неизменной необхо­димости, но если он вдруг пригодился, то огромное счастье иметь его под рукою»[8].

Определение родства

Остается принципиальный вопросец: как найти, является ли объект потомком другого объекта? Разделение наследований состояния и поведения приводит к тому, что слово «потомок объекта» обретает двоякое значение. С одной стороны, это потомок по данным, с иной стороны, это потомок по поведению.

По сути, в незапятанной объектно-ориентированной системе данные объектов накрепко защищены от вмешательства юзера через механизм инкапсуляции. Доступ к данным делается через способы. Таковым образом, родство объектов следует определять только через их интерфейсы. В системе на базе классов обычно строится дерево наследования. В системе на базе прототипов с конкатенацией опре­деление родства получается из-за операций пересечения интерфейсов. означает для опреде­ления родства нужно выполнить операцию пересечения множеств. Если получив­шийся в итоге пересечения интерфейс совпадает с интерфейсом 1-го из 2-ух сравниваемых объектов, то иной объект – его потомок. Практически, это метод оп­ределения общего предка 2-ух объектов. Внедрение множеств для хранения интер­фейсов дозволяет посмотреть на операцию наследования конкатенацией как на операцию слияния множеств.

2.2 Инкапсуляция

Мысль инкапсуляции в языках программирования происходит от абстрактных типов данных. С данной точки зрения объект делится на интерфейсную часть и реализа­ционную часть. Интерфейсная часть является спецификацией набора допустимых над объектом операций. Лишь эта часть объекта видима. Реализационная часть состоит из части данных (состояние объекта) и процедурной части (реализация операций).

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

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

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

Инкапсуляция обеспечивает что-то вроде “логической независимости данных”: мы можем поменять реализацию типа, не меняя каких-то программ, использующих этот тип. Таковым образом, прикладные программки защищены от реализационных конфигураций на нижних слоях системы.

Тут уместно вспомянуть о “дилемме 2000 года”, появившейся из-за того, что в СУБД отводилось всего два разряда на год даты. Чтоб поправить возникающую ошиб­ку, необходимо пересмотреть поновой весь код приложения! В ООБД для решения анало­гичной трудности требуется исправление маленького количества способов, работающих с данными даты.

2.3 Идентификатор объекта

Предназначение идентификатора

Объекты в БД владеют индивидуальностью. Даже при изменении структуры и поведения объекта, его особенность сохраняется. Два объекта в системе отлича­ются своими идентификаторами. Идентификатор является чертой индиви­дуальности. понятие особенности ново для реляционных баз данных. В чисто реляционной БД все кортежи в границах одной таблицы различаются меж собой. Черта различия – первичный ключ. Почти все современные реляционные базы данных допускают существование в границах одной таблицы схожих кортежей. И потребность в этом есть, по другому не было бы квалификатора DISTINCT в операторе SQL SELECT.

Идентификатор объекта в БД дозволяет различить меж собой два схожих по значению объекта. Практически, он играет роль дескриптора адреса объекта. Таковым образом, юзер работает с объектом не через его адресок, а через его иденти­фи­катор.

Строение идентификатора

В современных ООБД для убыстрения доступа к объектам идентификаторы наде­ляются составной структурой.

Имеются два главных подхода для идентификации объектов:

· Составной адресок (Structured address)

· Заменитель (Surrogate)

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

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

В работе [16] описан подход к построению идентификаторов-заменителей. Иденти­фикатор состоит из 2-ух частей: кода кластера и номера в последовательности. Таковой подход основывается на последующих 3-х принципах:

1) Идентификатор объекта должен содержать информацию о кластере, который группирует вместе применяемые объекты

2) Должны быть допустимы произвольные размеры кластеров

3) Идентификаторы объектов должны подчиняться довольно монотонному представлению, чтоб они могли выступать в качестве псевдоключей динамического хеширования.

Есть три признака, по которым СУБД могут принимать решение о месте размещения объектов:

1) Правила, данные в схеме БД

2) Указание юзера

3) Статистика доступа

В дипломной работе, невзирая на заманчивость идеи кластеризации, принят очевидный подход: идентификатор новейшего объекта – это один. Объекты также хранятся не в виде кластеров и не вкладываются друг в друга. Хотя система управления памятью дозволяет организовать и таковой метод хранения.

Идентичность и эквивалентность

В ООБД при сопоставлении 2-ух объектов меж собой различают идентичность и эквивалентность объектов.

Определение идентичности

Два объекта являются схожими, если их идентификаторы совпадают. Так как в системе не быть может 2-ух объектов с схожими идентификаторами, это значит, что это один и этот же объект, на который ссылаются с 2-ух различных мест. Идентичность обозначается так: o1
º o2
.

Определение
N-эквивалентности

Пусть 0-эквивалентность (обозначается »0
) то же самое, что проверка идентичности º. Тогда для всех 2-ух объектов o1
, o2
ÎO
, o1
и o2
n-эквивалентны (обозначается o1
»n
o2
) для n > 0, если:

Существует атомарный объект
, таковой, что
(o1
) =
(o2
) и их поведения схожи;

Существует объект-агрегат
, таковой, что FID всякого поля
находится в o1
и o2
, также правильно оборотное: FID всякого поля
1
(
2
) находится в
,

(
1
)=[A1
:
1
, …, Am
:
m
] и
(
2
)=[A1
:
1
, …, Am
:
m
], и при всем этом
i
»n-1

i
для 1£ i £ n; либо

Существует объект-условие
, таковой, что
(
1
) = <
1
,
2
,
3
> и
(
2
) = <
1
,
2
,
3
> и
i
»n-1

i
для 1£ i £ 3; либо

Существует объект-множество
, таковой, что
(
1
) = {
1
, …,
l
} и
(
2
)
= {
1
, …,
m
} и
=
и для всякого
i
(
j
) существует один
j
(
i
) :
i
»n-1

j
для 1£ i,j £
; либо

Существует объект-список
, таковой, что
(
1
) = (
1
, …,
l
) и
(
2
) = (
1
, …,
m
) и
=
и
i
»n-1

i
для 1£ i £
.

Два объекта именуются эквивалентными (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 вызываются по окончании деяния транзакции при выполнении операции удаления транзакционных зависимостей.

Все триггеры множеств и последовательностей можно разбить на две систематизации: это триггеры, следящие за целостностью огромного количества (последо­ва­тель­нос­ти), сохраняя отношение порядка на последовательности, ограничение суммы чисел эле­ментов огромного количества и др.; и следящие за целостностью 1-го элемента, что соответствует проверке значения на соответствие домену.

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

Перечень POST_TRIGGERS дозволяет исключить часть данных из результата выполненной объектом операции, создав тем локальное пользовательское к примеру, в [9] и [18].

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

Действие представляет собой объект типа “строчка”, хранящий текст ДССП-процедуры. ссылка на действие может хранится в поле OBJKH объекта, через который и происходит вызов деяния. метод выбора выполняемого деяния рассматривается ниже. В интерфейсах объектов указаны идентификаторы объектов, которые в поле OBJKH хранят идентификатор деяния. значения этих объектов являются именованием деяния. Более комфортно применять для данной цели строковые объекты. Использова­ние поля OBJKH дозволяет делать одно и то же действие для разных способов разных объектов.

При вызове деяния с идентификатором OIDKH делается вызов слова с именованием kh$<OIDKH>. К примеру, для объекта с OIDKH=0x00000DFC это будет KH$00000DFC. Если возникает ситуация EXERR, означает слово в словаре отсутствует и подлежит компиляции. Для компиляции текст деяния дополняется префиксом “: KH$<oid> ” и суффиксом “ ;”, опосля что компилируется командой TEXEC и производится. Словарь действий именуется $KH_VOC.

При изменении текста способа нужно вполне очистить словарь ДССП $KH_VOC, хранящий откомпилированные деяния, так как эти деяния содержат в собственном коде абсолютные ссылки на прежнюю откомпилированную версию деяния. Вообщем, эта процедура чистки словаря производится только при переопределении текста деяния, что бывает довольно изредка.

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

В отсутствии классов, хранить способы в любом объекте было бы очень затратно. Вынесение правил поведения в отдельный объект дозволяет уменьшить издержки на хранение объектов-данных. Математическая модель ООБД в [17], также делит дан­ные и поведения, что добавочно дает возможность переиспользовать объект-поведение представляет собой огромное количество объектов-методов, которое и назы­ва­ется интерфейсом объекта.

При посылке на вход случайного объекта OID2
сообщения OID1
(которое тоже является объектом), поначалу проверяется, содержится ли OID1
в интерфейсе объекта OID2
(проверка идентичности). Если да, то производится действие объекта OID1
, по другому сравниваются значения OID1
и объектов интерфейса (проверка эквивалентности). Если соответствие найдено, производится действие, обозначенное в отысканном в интерфейсе объекте.

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

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

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

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

·

определения операций Select и Pickup алгебры объектов можно отыскать в [17]. тут оно не рассматривается по той причине, что является надстройкой над управлением посылкой сообщений и описывается через механизм посылки сообщений. Другими словами операции алгебры объектов могут быть заданы через операции посылки сообщений, без исправления структуры СУБД. Полная алгебра объектов является замкнутой и состоит из последующих операций: Select s, Pickup d, Apply r, Expression Apply l, Project p, Combine c, Union È, Interselect Ç, Subtract -, Collapse v, Assimilate a. Объектная алгебра наиболее выразительна, чем реляционная, так как поддерживает полиморфность. Оператор 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
– Набор_параметров и
и
– два объекта в O
.

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

(1)
(B
) ~>
º
;
(B
) ~>
º
;

(2)
(B
) ~>
º
;
(B
) ~>
º
;

(когда

)

(3)
(B
) ~>
º
;
(B
) ~>
º
;

(когда

и

)

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

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

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

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

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

(5) Если существует способ
в
либо его объектах-учителях (объектов, от которых наследуется Message sending), владеет сложной структурой.

Всеохватывающие сообщения

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

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

(B
) ~>
º [A1
:
1
(B
) ~>
1
, …, An
:
n
(B
) ~>
n
], если 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).

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

(B
) ~>
º
(B
) ~>
если
(B
) Ï {False
,
}

(B
) ~>
º
(B
) ~>
по другому

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

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

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

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

(B
) ~>
º
(B
) ~>
,
=
{
} опосля
(B
) ~>

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

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

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

(B
) ~>
º
n
(B
) ~>(…~>(
2
(B
) ~>(
1
(B
) ~>
))…) где
= (s1

, s2

, …, sn

)

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

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

>определяется последующим образом:

Таблица 1:

Условие

(B
) ~1

>
º

(B
) ~>
не

º

(B
) ~>

AGG(o) & o = [A1
: o1
, …, An
: on
]
[A1
:
(B
) ~>
1
, …, An
:
(B
) ~>
n
]

BIO(
) &
не

º

(B
) ~>

BIO(
) &
º

(B
) ~>

SET(
) &
= {
1

n
}
{
(B
) ~>
1
, …,
(B
) ~>
n
}

SEQ(
) &
= (
1

n
)
(
(B
) ~>
1
, …,
(B
) ~>
n
)

По другому

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 Виртуальная память и каналы

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

Рис 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 Система управления кэшированием объектов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для определения подмножества объектов кэша, подлежащих вытеснению, можно применить метод решения задачки о ранце. Если б все объекты имели схожую длину, без этого можно было бы обойтись. Хотя метод решения задачки о ранце NP-сложен, решение можно компактно записать в виде рекурсивного метода, нахо­дя­ще­го решение за счет внедрения принципа динамического программирования Беллмана. Таковой метод более эффективен, когда размер кэша составляет 32 объекта, посколь­ку огромное количество избранных объектов можно представить битовыми полями в длинноватом слове. При большем размере кэша растут утраты памяти и быстродействия, и во­зникает вопросец о месте расположения данных промежных вызовов. Рекурсивный вызов в среде ДССП просит малых издержек ресурсов, а время расчета окупается за счет времени обмена с наружной памятью, работа с которой много медлительнее, чем с оператив­ной.

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

Журнализация предназначена во-1-х, для обеспечения способности отката неправильных действий транзакций, и, во-2-х, для восстановления базы данных опосля аппаратного сбоя. В ООБД журнализацию можно проводить на 3-х уровнях: инфологическом, даталогическом и физическом. На инфологическом уровне журнальчик фиксирует сообщения, циркулирующие в системе. На даталогическом уровне фик­си­руется какие примитивы были вызваны на выполнение сообщениями. На физи­че­ском уровне фиксируются низкоуровневые операции: по какому адресу в которой вирту­альной памяти выполнялась запись, как поменялись границы виртуальной памяти.

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

Для журнализации избран подход, примененный в СУБД Postgres, разработанной в институте г.Беркли, Калифорния под управлением М.Стоунбрейкера, как более обычный в реализации и предоставляющий полезные способности, труднодоступные в базах данных с обыденным типом журнализации (см. [23]). В данной системе, во-1-х, не ведется рядовая журнализация конфигураций базы данных, и одномоментно обеспечивается корректное состояние базы данных опосля перевызова системы с утратой состояния оперативки. Во-2-х, система управления памятью поддерживает истори­ческие данные. Запросы могут содержать временные свойства интересующих объектов. Реализационно эти два нюанса соединены.

СУБД, имеющие таковой вид журнализации, именуются темпоральными СУБД. Главный тезис темпоральных систем заключается в том, что для хоть какого объекта данных, сделанного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны юзерам) все его состояния во временном интервале [t1, t2). Система не только лишь хранит информацию о прошедших состояниях объекта, да и предоставляет юзеру доступ к ней через язык запросов.

Т.е. журнальчик состоит из меток времен и значений объектов. СУБД POSTGRES является экспериментальной и, а именно, предполагается, что она работает на вычислительной аппаратуре, снаряженной статической оперативной памятью, не теряющей инфы при выключении наружного питания. Вообщем, Издержки на 100­ти­ческую память возмещатся быстродействием СУБД и доп возмож­нос­тями, приобретаемыми при таком подходе, а конкретно: возможность получить

Совершенно говоря, любой объект в системе состоит из 3-х частей: Заголовка объекта, данных и истории. В заголовке объекта имеется поле VALUE, которое содержит ссылку на начало расположения снутри объекта данных о его состоянии. объект, с которым юзер желает работать, автоматом загружается системой в кэш, где ему выделяются 4 канала:

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

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

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

4. канал истории конфигураций объекта на диске

Прикладной программер не работает впрямую с каналами. С каналами работают примитивы доступа к содержимому объекта. Прикладной программер рабо­тает с объектами лишь через их идентификаторы. А идентификаторам объектов 100­вятся в соответствие каналы в системе кэширования объектов.

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

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

Любой объект владеет поведением, реализуемым через способы (операции). Если операция работает лишь с внутренними данными объекта, то она является локальной, если же она отправляет сообщения остальным объектам, то – глобальной. Посланное к другому объекту сообщение порождает на нем выполнение соответственной операции. Через транзитивное замыкание можно представить процесс порождения отношением предок – потомок.

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

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

Все действия хоть какой операции на объекте, попадают под одну из 4 категорий: запрос, создание, модификация, удаление. Для каждой операции на объекте определяются надлежащие огромного количества.

Огромное количество запросов QS(opi
(O)) определяется рекурсивно как QS(opi
(O)) = LocalQS(opi
(O)) È GlobalQS(opi
(O)), где

· LocalQS = Æ, если нет собственных ivj
из O «запрошенных» операцией opi
. {O}, по другому.

· GlobalQS =

opi
, отправляет сообщение к Os
для выполнения способа opj
, где Os
Î Scope(opi
(O)), и Ogq
ÎQS(opj
(Os
)).

Аналогично определяются можества сотворения модификации и удаления операции opi
на объекте O.

Огромное количество замен определяется как объединение множеств сотворения, модифи­ка­ции и удаления. Конфликт операций – выполнение 1-го из последующих критерий:

1. US(opi
(O)) Ç US(opj
(O’)) ¹Æ

2. QS(opi
(O)) Ç US(opj
(O’)) ¹Æ

3. US(opi
(O)) Ç QS(opj
(O’)) ¹Æ

Пользовательские транзакции можно разглядывать как операции над специ­альным объектом базы данных.

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

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

Для роста производительности СУБД, некие операции могут вести взаимодействие друг с другом в базе данных. Некие из этих операций могут производиться на одном объекте. Совместное выполнение почти всех операций (псевдо­параллельность) может приводить к произвольному чередованию операций (либо их шагов). порядок чередования именуется
. Потому что «пользовательские транзакции» являются лишь операциями на особом объекте, ОО-расписание можно найти на этом объекте как пару (S,<расп
), где S – огромное количество всех шагов (как локальных, так и глобальных), а <расп
– частичный порядок на огромном количестве шагов в S. Глобальные шаги в S – это итог воззвания операций к остальным объектам, и шаги основанные на итоге этих воззваний также врубаются в расписание.

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

В работе [19] утверждается, что расписание
для T на особом объекте является корректным объектно-ориентированным расписанием, если:

1. Расписание состоит лишь из шагов операций, порожденных действием T, и любой из этих шагов производится буквально раз в Sch.

2. В расписании сохраняется отношение порядка выполнения шагов операций для всех транзакций.

3. Если порожденная от T транзакция имеет две операции над одним объектом, находящиеся в способе на этом же уровне вложенности, то времена выполнения этих операций не пересекаются; все вызванные подоперации одной операции заканчиваются до начала выполнения иной операции. Очередность выполнения задается системой управления транзакциями.

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

Этот аспект правильности подменяет собой аспект сериализуемости в ООБД.

Эквивалентность расписаний

Для определения эквивалентности расписаний: вводится последующее правило: если итог одной операции выходит на базе результата иной операции, то в любом корректном расписании порядок следования конфликтующих операций схож. Если конфликта нет, то допустимым является хоть какой порядок следования операций. Если при всем этом получаются различные результаты, то любой из их, тем не наименее, является пра­виль­ным. Этот феномен можно проиллюстрировать на последующем примере:

Положим, имеются две операции: прирастить сумму на счете в два раза и прирастить сумму на счете на 10%. Разумеется, что итог будет различным зависимо от порядка следования операций. Но, так как операции независимы, в любом случае он считается правильным.

Воздействие наличия позднего связывания на составление расписания операций в ООБД

Если объекты, которые доступны разным транзакциям, заблаговременно известны, задачка механизма согласованного управления относительно ординарна. Априорная инфор­мация упрощает статичное определение конфликтующих операций; как следует, стра­тегия управления чередованием операций быть может сформулирована. Но, позд­нее связывание (late binding), соответствующая черта объектно-ориентированных систем, приводит к трудности подготовительного определения объектов доступа. При отсутствии такового познания, одним из выходов является блокировка неких транзакций до того времени, пока вид объектов доступа не станет известен. Но, для длительных (long-duration) транзакций (к примеру, запись звука в мультимедийной БД) , таковая блокировка может привести к очень большенному времени ожидания.

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

Одним из способов решения данной трудности заключается в том, чтоб ограничить сумму откатов. Для этого употребляется мысль точек проверки, ограничивающих глубину отката. Если происходит событие приводящее к обрыву либо откату, эффект, произведенный действиями за точкой проверки должен быть отменен. Это минимизирует утраты ресур­сов и в то же время уменьшает длительные ожидания.

Спецификация точки проверки

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

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

состояние пользовательских транзакций на объектах

Любой объект O в системе хранит состояние каждой пользовательской транзакции в системе. состояние пользовательской транзакции (т.е. операции на DBIO) может принимать одно из последующих значений:

(Never Activated)
Неважно какая пользовательская транзакция, которая не воздействовала на O прямо либо косвенно, находится в этом состоянии на O. Это эквивалентно тому, что не имеется никакой инфы о пользовательской транзакции в O.

(Completed)
Пользовательская транзакция находится в состоянии Завершена на O, если операция вызванная ей на O окончила выполнение всех собственных шагов.

(Chekpoint)
Пользовательская транзакция не произвела никаких действий с того времени, как оказалась в точке проверки.

(BlockedForCheckPoint)
Пользовательская транзакция ждет выполнения критерий, которые будут удовлетворять переводу ее в Точку проверки.

(Executing)
Пользовательская транзакция производится на O, если операция op(O), вызванная данной транзакцией производится.

Рис 4:

Таблица 4:

Деяния
Новое состояние транзакции

Никогда не активизировалась

объект O получил запрос на выполнение op(O) в первый раз для транзакции Tr(op(O)) и op(O) начинает производиться
Производится

Операция транзакции достигнула описанной для нее точки проверки, все другие активные операции на O «никогда не активизировались» в точке проверки
Находится в точке проверки

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

Tr(op(O)) окончила все свои шаги
Завершена

Таковым образом, если объект имеет точки проверки, описанные для собственных операций, то операции встречаются (рандеву) в точке проверки. Если операции в точке проверки произведены удачно, то в дальнейшем нет необходимости хоть какой операции откатываться (rollback) за точку проверки.

Шаги протокола согласованного управления

1. Операция запрошена (requested)

2. Операция вызывает другую операцию

3. Вызванная операция ворачивается

4. Операция завершена

5. Точка разрыва (breakpoint) достигнута

6. Точка проверки (checkpoint) достигнута

7. В точке проверки получено сообщение

Детально метод выполнения шагов описан в [19].

4. системы

Системе известны последующие базисные объекты: ROOT, FAIL, NULL, SAME, ATOMIC, INT, STR, DATIME, BIO, AGG, SET, SEQ.

1. ROOT – корень – предок всех объектов. Данных не имеет.

2. FAIL, копия ROOT – ворачивается, если при действии произошла ошибка.

3. NULL, копия ROOT – объект-заменитель при отсутствующем значении. Эта неувязка появилась не так давно, но в теории реляционных баз данных пока не отыскала применимого решения. Сущность трудности состоит в том, что при вводе данных, некие из их могут отсутствовать (к примеру, не известен год рождения), потому недозволено сказать, чему они в точности равны. В неких вариантах нуль может являться значением, для этого и вводится особое обозначение (NULL).

4. SAME, копия ROOT – объект, позволяющий создавать копии. Он значит, что для взаимодействующего с ним объекта создается копия.

5. ATOMIC – предок всех атомарных объектов. Задает для их главные способы поведения.

6. INT – целое.

7. STR – строчка.

8. DATIME – дата и время

9. BIO – условный объект

10.AGG – агрегат

11.SET – огромное количество

12.SEQ – последовательность

4.2 Строение объекта

Любому объекту выделяется персональное виртуальное место. Объект предваряется заголовком. За заголовком следуют виртуальные места данных и журнальчика. Любой объект имеет неповторимый идентификатор в границах системы.

Таблица 5:
(все поля 32-битные)

Поле
Семантика

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

OBJBHR
Идентификатор объекта-поведения (способы)

OBJKH
Идентификатор объекта-действия

TRCOOBJ
Идентификатор транзакционного сообъекта

VALUE
адресок заголовка вложенного канала, хранящего адресок заголовка вложенного канала, хранящего историю конфигураций

Блок данных объекта

Атомарный объект хранит снутри блока данных свое

объект-условие хранит снутри блока данных три идентификатора в последующем порядке: идентификатор методаусловия, идентификатор способа, выполняемого, если условие выполнено («правда») и идентификатор способа, выполняемого, если условие не выполнено ( «ересь»).

У объектов агрегат, перечень и огромное количество 1-ое слово блока данных – размер элемента. Для перечня и огромного количества он равен 4. Для агрегата – 12.

Элементом перечня и огромного количества является идентификатор объекта. Элементом агрегата является кортеж:

· идентификатор объекта-значения (он непременно является потомком объекта-образца)

· идентификатор поля (FID)

· идентификатор объекта-образца

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

Таблица 6:

Длина в б
денек

1
Час

1
Минутки

1
Секунды

2
Толики секунд

Таковая структура журнальчика позво­ляет фиксировать конфигурации не только лишь данных, да и поведений, knowhow…

Таблица 7:

Число б
адресок размещения в заголовке

4
Замененное денек

1
Час

1
Минутки

1
Секунды

2
Толики секунд

информация о транзакциях в системе

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

Таблица 8:
(агрегата)

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

DSR
Огромное количество обретенных зависимостей

DS
Огромное количество зависимостей

Огромное количество зависимостей выходит объединением множеств локальных, уна­сле­дованных и обретенных зависимостей. Любой элемент какого-нибудь из этих мно­жеств зависимостей – пара номеров транзакций (Ti
,Tj
). Если трактовать это мно­жест­во как огромное количество ребер графа, в кото­ром верхушки – номера транзакций, а реб­ра – зави­симости меж транзакциями, то наличие цикла в графе значит некор­рект­ное выпол­нение транзакций.

В целях упрощения принято решение отрешиться от таблицы конфликтов. Таблица кон­флик­тов обрисовывает какие операции конфликтуют меж собой, т.е. может ли выпол­нять­ся операция A, если в данных момент производится операция B. Ячейка таблицы может принимать одно из 3-х значений: «Конфликтует», «Не конфликтует», «Непонятно».
Транзакции и объекты-поведения

Объекты поведения представляют собой огромное количество объектов, поле OBJKH кото­рых хранит идентификатор выполняемого деяния. Это огромное количество имеет ширину эле­мента не 4, как обыденное огромное количество, хранящее данные, а 8. В последующих 4 бай­тах может храниться идентификатор перечня – строчки таблицы чередований в точках разрыва (части подсистемы транзакций). Таблица чередований появляется из точек раз­рыва и группировки спецификаций для объекта. Она дозволяет найти: в которых точ­ках разрыва каких операций можно переключиться на выполнение операции, соответ­ствующей данной строке таблицы чередований. Это статическая информация, ко­торая быть может сформирована перед началом работы системы. Элемент строчки та­блицы чередований состоит из 2 значений: идентификатора операции и иденти­фикатора мно­жества, хранящего номера точек разрыва.

4.3 Контекст транзакции

В системе есть объект DBIO (Database User-Intarface Object), которому известны состояния всех транзакций. Этот объект представляет собой огромное количество, элементами которого являются объекты-агрегаты, описывающие контекст транзакции.

Таблица 9:

имя поля
Размер в б
Значение

TR_MESS
4
OID сообщения

TR_KH
4
OID knowhow

TR_PARAM
4
OID агрегата с параметрами

TR_TARGET
4
OID мотивированного объекта сообщения

TR_RES
4
OID результата

TR_STACK
4
OID стека

TR_N
4
Номер транзакции

TR_HOSTN
4
Номер вызвавшей транзакции

TR_STATUS
1
состояние транзакции

TR_POINT
2
Точка разрыва, в какой находимся

Для каждой транзакции выделяется собственный стек. Механизм сохранения и вос­100­нов­ления стеков описан в [7]. Стеки сохраняются в атомарных объектах.

5. Описание операций над объектами в БД

[] DB.NEW [] — сделать новейшую БД

[] DB.OPEN [] — открыть БД

[] DB.CLOSE [] — закрыть БД

Операции клонирования:

[oid] CLONE [oid’] — клонировать объект

[] CLONE_ROOT [oid’] — Сделать объект от «Корень»

[int] CLONE_INT [oid’] — Сделать объект «Целое»

[«string»] CLONE_STR [oid’] — Сделать объект «Строчка»

[«string»] CLONE_AGG [oid’] — Сделать объек-агрегат

[oid_if oid_then oid_else]

CLONE_BIO [oid’] — Сделать объект-условие

[] CLONE_SET [oid’] — Сделать объект-множество

[] CLONE_SEQ [oid’] — Сделать объект-последовательность

OIDROOT, OIDINT, OIDAGG, …, OIDSEQ -– Выяснить идентификаторы соотв. Объектов

[oid_bhr] SET_BHR [] — переопределить действие

[] GET_KH [oid] — выяснить действие

[oid] GET_INT [int] — Получить целое число из объекта-целого

[int oid] SET_INT [] — Занести целое число в объект-целое

[oid] PRINT_STR [] — Печатать на дисплее содержимое строчки

[«string» oid] SET_STR [] — Занести строчку в объект-строку

[oid_super oid] SUPER+ [] — наследовать данные из oid_super в oid

[oid] DELOBJ [] — удалить объект

Операции над обилием:

[oid_el oid] SET+E [] — добавить элемент в огромное количество

[oid_el oid] SET-E [] — удалить элемент из огромного количества

[oid_el oid] SET?E [0/1] — отыскать элемент в огромном количестве

[oid1 oid] SET+ [] — объединение

[oid1 oid] SET- [] — разность

[oid1 oid] SET* [] — пересечение

Операции над перечнем:

[oid_el n oid] SEQ+E [] — добавить элемент в последовательность

[n oid] SEQ-E [] — удалить n-й элемент из

последовательности

[oid_el oid] SEQ?E [0/n] — отыскать позицию в последовательности

[n oid] SEQ?N [0/oid] — найти oid n-го элемента послед-ти

Операции над агрегатом:

[fid oid_etalon oid] AGG+F [] — добавить поле к объекту

[fid oid] AGG-F [] — удалить поле из объекта

[fid oid] ETALON [oid] — получить идентификатор объекта-эталона

[fid oid] FIELD [oid] — получить идентификатор

объекта-значения

Операции над объектом-условием:

[oid] GET_BIO

[oid_else oid_then oid_if] — Получить характеристики объекта-условия

[oid_else oid_then oid_if oid]

SET_BIO [] — Сохранить характеристики объекта-условия

Особые операции:

[oid_str oid] SET_NAMEOBJ [oid] — называть объект

[oid_str fid] SET_NAMEFID [fid] — называть поле

[oid_str] NAMEOBJ [oid] — получить идентификатор по имени

[oid_str] NAMEFID [fid] — получить идентификатор поля по имени

[oid_mess oid_par oid] SEND [] — отправить сообщение объекту

[oid_mess oid_obj] METHOD? [] — найти идентификатор способа

[oid1 oid] CHIELD [1/0] — найти, является ли oid1 потомком oid

[oid_kh] RUN_KH [] — выполнить knowhow

[] NCHAN [chan] — выяснить номер текущего канала

[chan] !NCHAN [] — переключиться на данный канал

Операции просмотра:

[oid] JVIEW [] — просмотр журнальчика

[] A.VIEW [] — просмотр адресов объектов в БД

[] Q.VIEW [] — просмотр очереди

[] IC [] — просмотр состояния канала

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

ДССП реа­лизована на огромном количестве компьютерных платформ (VAX, PDP-11, IBM PC, R3000, MC68020, SPARC) и операционных систем (MSDOS, MSDOS-экстендеры, unix, RT-11, RSX, OS9, CPM и др.). В дан­ный момент фактически закон­чена разработка ДССП на Си, что обес­печивает перенос данной системы на всякую платформу, где есть Си.

Аппаратные средства:

Неважно какая платформа, на которой работает ДССП, с объемом оперативки для нужд БД не наименее 1 Мб.

Программные средства:

ДССП с диспетчером параллельных действий (версия 4.42) и Операционная Система.

Разрабатываемая СУООБД может также работать в качестве host-программы на файл-сервере, обрабатывая команды с рабочих станций, поступающие в их индивидуальные ящики на файл-сервере. Ответ рабочие станции получают также через почтовые ящики.

В предстоящем, могут быть реализованы сетевые протоколы тогда и СУООБД будет являться сервером в клиент-серверных приложениях.

Внедрение отдельных почтовых ящиков для нескольких параллельно работающих юзеров дозволяет возложить на СУООБД функции монитора [6], осуществляющего линеаризацию поступающих запросов к содержимому СУООБД.

7. Реализация макета

7.1 Построитель

LOAD TIMEM

LOAD M0

LOAD M2

LOAD Soms

LOAD CHMS

LOAD SYSOBJS

LOAD M3

LOAD LS_CASH

UNDEF

PROGRAM $KH_VOC

7.2 Заголовочный модуль для каналов

PROGRAM $M0

B16

1000 VALUE TOTMEMLEN

TOTMEMLEN BYTE VCTR MEMORY

: T-1 D -1 ;

: *4 SHL SHL ;

: &0FF 0FF & ;

: <= 1+ < ;

: >= 1- > ;

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

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

: !NCHAN ! NCHAN ;

5 VALUE NBASECH [1-ый не базисный канал]

: 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 <= BR+ COST1 COST2 [HARD soft] ;

: COST1 [N FREE] T0 E2 [0 N] ;

: COST2 [N FREE] C PUSH — POP [N-FREE FREE] ;

: UPSIZEI [N_soft] BUSYLEN + !BUSYLEN 1 !CHGCTX SCTX ;

: UPSIZEO [N_HARD] NCHAN BR 0 USO0 1 USO1 2 USO1 ELSE USON ;

: USO1 C GOBOTTOM TEKADR E2 DO OBS-0 [!TEKADR] BSGOTO

C BUSYLEN + !BUSYLEN LEN + !LEN 1 !CHGCTX SCTX ;

: USO0 NOMEMORY [Сюда можно вставить упаковку] ;

[Спецификация: увеличение размера (жестко, т.е. за счет нижнего уровня)]

: USON [N] SYNCADDR LASTADDR USON1 RELCTX [>] 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 [<can more…] NEWVM1

[SYNCADR] GOTO 5 LCTX [4 UPSIZE 8 OLS] DEFMAXID

CHMS.INIT ;

: WRI_8OLS 8 OLS ;

7.5 Система управления каналами

PROGRAM $CHMS

3 VALUE LENGRP [Вместимость уровня приоритетов]

4 VALUE QChannels

LENGRP 3 * 1+ VALUE LenPrioQue [длина очереди приоритетов. Очередь — с 0]

: N2CH [N] QChannels * 0A + [NCHAN] ;

LenPrioQue 1+ N2CH 10 * LONG VCTR CHDATA [память характеристик каналов]

[для каждого канала можно завести 16. различных параметров]

: CHMS.INIT 0 !!! PrioQueOID

0 LenPrioQue DO SETNQ D ;

: SETNQ C C ! PrioQueNUM C N2CH [NUM CHAN1]

[вычислили номер канала для очередного объекта кэша]

C C3 1 ! Channels

1+ C C3 2 ! Channels

1+ C C3 3 ! Channels

1+ C C3 4 ! Channels D 1+ ;

[при воззвании к объекту необходимо повысить его Ценность]

: HIPRIODD D HIPRIO ;

: HIPRIO [OID] FINDOID C BR- D HIPRIO1 ;

: HIPRIO1 [N] C LENGRP / D C IF+ 1- LENGRP * [N N’] E2 UPOID [] ;

[Новейший объект добавляется на последн. поз-ю, а потом к нему примен. HIPRIO]

LenPrioQue LONG VCTR PrioQueOID [список OID]

LenPrioQue Word VCTR PrioQueNUM [номера записей в массиве каналов]

LenPrioQue QChannels 2 Word ARR Channels

[обменять в очереди с соседним вышестоящим]

: SWP2OBJ [N] C IF0 LEAVE C PrioQueOID C2 1- PrioQueOID

C3 ! PrioQueOID C2 1- ! PrioQueOID

C PrioQueNUM C2 1- PrioQueNUM C3 ! PrioQueNUM C2 1- ! PrioQueNUM 1- [N-1] ;

: SWP2OBJDD SWP2OBJ DD ;

: FINDOID [OID] 0 LenPrioQue DO CMPOID E2D C LenPrioQue = IF+ T-1 [-1/N] ;

: CMPOID [OID] C PrioQueOID [OID N OID(N)] C3 = EX+ 1+ ;

[Поднять объект от N_DOWN к N_UP в очереди]

: UPOID [N_UP N_DOWN ] C E3 — DO SWP2OBJ D [] ;

[Просмотр очереди (кэш объектов)]

: Q.VIEW 0 LenPrioQue

.» M.Hdr D.Hdr M.Dat D.His»

DO QELVIEW D ;

: QELVIEW [n] CR C C 2 TON LENGRP / E2D BR0 #- #) TOB

C PrioQueOID .» OID=» .D C PrioQueNUM .» Num=» .

.» Channels= » 1 QChannels DO PriNCH

DD 1+ ;

: PriNCH [NOID NCH] C2C2 Channels 4 TON SP SP 1+ [NOID NCH+1] ;

7.6 Работа с базисными объектами

PROGRAM $SYSOBJS

B16

LONG VAR ADRSTR LONG VAR LENSTR

0 VALUE N_OID 4 VALUE N_BHR 8 VALUE N_KH

0C VALUE N_TRC 10 VALUE N_VAL 14 VALUE N_HIS

13 VALUE JRECLEN

: G_OID N_OID GOTO ; : W_OID G_OID OLS ;

: G_BHR N_BHR GOTO ; : W_BHR G_BHR OLS ;

: G_KH N_KH GOTO ; : W_KH G_KH OLS ;

: G_TRC N_TRC GOTO ; : W_TRC G_TRC OLS ;

: G_VAL N_VAL GOTO ; : W_VAL G_VAL OLS ;

: G_HIS N_HIS GOTO ; : W_HIS G_HIS OLS ;

18 VALUE SZ_HDROBJ

: W_NULLBLK -1 OLS -1 OLS 0 OLS 0 OLS ;

[Описание системных объектов]

ACT VAR DATWR

LONG VAR OIDV

LONG VAR VALINT

[**** ROOT ****]

SZ_HDROBJ HSIZE+ HSIZE+ 4+ VALUE SIZE_ROOT

:: : CLONE_ROOT » DATWRROOT ! DATWR NEWOBJ1 ;

:: : CLONE_INT ! VALINT » DATWRINT ! DATWR NEWOBJ1 ;

:: : CLONE_SET 4 CLONE_INT ;

:: : CLONE_SEQ 4 CLONE_INT ;

:: : CLONE_AGG 0C CLONE_INT ;

:: : CLONE_STR [A L] ! LENSTR ! ADRSTR » DATWRSTR ! DATWR

LENSTR SIZE_ROOT + 4- ! SIZE_X NEWOBJ3 ;

:: : SET_BHR [OID_BHR OID] N_BHR E2 SET_X1 ;

:: : SET_KH [OID_KH OID] N_KH E2 SET_X1 ;

: SET_X1 [ADR OID] C2C2 N_TRSC E2 NEWJREC

C LOADOBJ FINDOID C BR- DD SET_X11 ;

: SET_X11 PrioQueNUM 2 Channels !NCHAN GOTO OLS ;

:: : SET_INT [int oid] C HIPRIO PUSH ! VALINT 4 » OLSI POP NEWDREC ;

: OLSI VALINT OLS ;

:: : GET_INT [OID] TODATA ILS ;

:: : TODATA [OID] C LOADOBJ C HIPRIO FINDOID PrioQueNUM

3 Channels !NCHAN 0 GOTO ;

:: : SET_STR [A L OID] C HIPRIO

PUSH ! LENSTR ! ADRSTR LENSTR » OLSS POP NEWDREC ;

: OLSS ADRSTR LENSTR DO DWS1 D ;

ACT VAR BYTE_STR

:: : PRINT_STR » PRIS ! BYTE_STR ACCESS_STR ;

:: : COPY2BUF_STR » C2BUF ! BYTE_STR ACCESS_STR ;

:: : ACCESS_STR [OID] TODATA LENVMEM 0 GOTO DO BYTE_STR ;

: PRIS IBS TOB ;

: C2BUF IBS ABUF !TB !1+ ABUF ;

: DD_ROOT

OIDV OLS 0 OLS 0 OLS 0 OLS SZ_HDROBJ HSIZE+ OLS [val]

SZ_HDROBJ OLS [his]

W_NULLBLK [W_NULLBLK] DATWR ;

LONG VAR SIZE_X

: DATWRROOT -1 OLS -1 OLS 0 OLS 4 OLS 0 OLS ;

: DATWRINT -1 OLS -1 OLS 4 OLS 4 OLS VALINT OLS ;

: DATWRSTR -1 OLS -1 OLS LENSTR OLS LENSTR OLS ADRSTR LENSTR DO DWS1 D ;

: DWS1 [A] C @B OBS 1+ ;

: NEWOBJ1 [] SIZE_ROOT ! SIZE_X NEWOBJ3 ;

: NEWOBJ3 » DD_ROOT ! WRI_DATA

NEWID C ! OIDV SIZE_X C2 D.NEWOBJ [OID] ;

9 VALUE LCH

LCH LONG VCTR CLONEHDR VAR DATCH LONG VAR LENVMEM1

:: : CLONE [OID] C HIPRIO

C LOADOBJ FINDOID PrioQueNUM C PUSH 2 Channels !NCHAN 0 GOTO

CLONE1 []

» CC_ROOT ! WRI_DATA NEWID C 0 ! CLONEHDR SZ_HDROBJ HSIZE+ C2 D.NEWOBJ

[OID] POP 3 Channels C ! DATCH !NCHAN LENVMEM C ! LENVMEM1

C2 [OID_NEW LEN OID_NEW] CLONE_DATA [OID_NEW] ;

: CLONE1

ILS 1 ! CLONEHDR [BHR] ILS 2 ! CLONEHDR [KH]

ILS 3 ! CLONEHDR [TRC] 0 4 ! CLONEHDR

SZ_HDROBJ 5 ! CLONEHDR -1 6 ! CLONEHDR

-1 7 ! CLONEHDR 0 8 ! CLONEHDR

0 9 ! CLONEHDR ;

: CCR1 [N] C CLONEHDR OLS 1+ ;

: CC_ROOT 0 LCH 1+ DO CCR1 D ;

: CLONE_DATA [LEN OID] » COPY_DATA E2 NEWDREC [] ;

: COPY_DATA [] DATCH NCHAN LENVMEM1 DO_IOBSCC DD ;

:: 0 VALUE N_TRSC

[Запись новейших данных, запись в журнальчик]

: NEWDREC [SIZED PROC OID] N_VAL N_TRSC C3 NEWJREC FINDOID

PrioQueNUM [SIZE PROC N] C PUSH

2 Channels !NCHAN

[SIZED PROC] ! WRI_DATA NEWVM1 G_VAL C OLS [ADR_DATA]

[перечитать канал данных]

GOTO POP 3 Channels LCTX [] ;

[новенькая запись в журнальчик. На вх: номер транз. и адресок из заголовка]

: NEWJREC [addr_hdr TRANS OID] C LOADOBJ FINDOID PrioQueNUM

[. TRANS N] C PUSH 4 Channels

!NCHAN JRECLEN UPSIZE OLS POP NCHAN PUSH 2 Channels !NCHAN

C GOTO ILS POP !NCHAN

E2 OWS OLS W_DATIME [] ;

B10

[Запись текущего времени]

: W_DATIME 1979 OWS 12 OBS 31 OBS TMGET TMS ;

: TMS [num] N2T GBR E2 GBR E2 GBR E2 OBS OBS OBS 100 * OWS ;

B16

[просмотр журнала объекта]

[Переключиться на журнальчик]

: OBJ.J [OID]

C LOADOBJ FINDOID PrioQueNUM 4 Channels !NCHAN ;

: JVIEW [oid] CR .»Updated data:»

OBJ.J LENVMEM JRECLEN / D 0 GOTO DO JVIEW1 ;

: JVIEW1 CR .»Trans= » ILS .D SP

IWS BR N_BHR .»Behav.=» N_VAL .»AddrVal=» N_KH .»Knowhow=»

ELSE .»?????? =» ILS SP .D SP JDATAV1 ;

: JDATAV1 S( BASE@ ) B10 IWS IBS IBS 2 TON #. TOB 2 TON #. TOB 4 TON

SP SP #: POS2 #: POS2 #. POS2 # IWS 4 TON TOB ;

: POS2 [B] IBS 2 TON TOB ;

[Определить размер объекта в памяти = заголовок + данные]

: SIZEMEMOBJ [N] C PrioQueOID BR0 T0 SMEMO1 [0/size] ;

: SMEMO1 3 Channels !NCHAN LENVMEM HSIZE+ HSIZE+ SZ_HDROBJ + [size] ;

7.7 Выполнение действий

PROGRAM $M3

[Выполнение действий (knowhow)]

FIX 1000 BYTE VCTR BUFTXT [Буфер для текста действий]

FIX LONG VAR ABUF

: BEGABUF 0 ‘ BUFTXT ! ABUF ;

: RUNCMD [OID_KH] BEGABUF «KH$» S2BUF N2BUF ABUF BEGABUF ABUF E2 C2 —

TEXEC ;

: MAKECMD [OID_KH] BEGABUF «: KH$» S2BUF C N2BUF # ABUF !TB !1+ ABUF

COPY2BUF_STR » ; » S2BUF

ABUF BEGABUF ABUF E2 C2 — TEXEC ;

: S2BUF [A L] DO S2BUF1 D ;

: S2BUF1 C @B ABUF !TB !1+ ABUF 1+ ;

: N2BUF [N] 8 DO CTN-SB D 8 [C1 .. Cn n] DO CTB ;

: CTN-SB [N] C 0F & #0 + E2 -4 SHT [C N’] ;

: CTB ABUF !TB !1+ ABUF ;

LONG VAR OIDK

: NEW_VOC «PROGRAM $KH_VOC» TEXEC ;

: RUN_KH [OID_KH] NEW_VOC C MAKECMD RUNCMD ;

7.8 кэширование объектов

PROGRAM $LS_CASH

[ Каналы: 1 — Header M.Obj 2 — Header D.Obj 3 — M.Data 4 — D.History ]

[Считаем, что все объекты — стабильные]

: LOADOBJ [OID] C FINDOID [искали в кэше] C BR- LOADOBJ-1 DD ;

: LOADOBJ-1 D [OID] [Отыскиваем в каталоге БД объект] [C] LOADOBJ1 [LOADOBJ2]

LenPrioQue 1- HIPRIO1 [] ;

: LOADOBJ1 6 LOADOBJ3 ;

[открыть дисковый объект в кэше]

: LOADOBJ3 [OID NDIRCH] EL_FIND [OID 1/0] IF0 O_NOTFND [Нет такого объекта]

C LenPrioQue 1- ! PrioQueOID [Внесли в кэш идентификатор объекта]

ILS [OID ADDR_MEM] [получили адрес размещения в дисковой памяти]

LenPrioQue 1- PrioQueNUM

[получили номер отведенной для работы с объектом группы каналов]

[OID ADDR_MEM NUM]

C 2 Channels [OID ADDR_MEM NUM CHANOBJ]

NCHAN NBASECH — !NCHAN [получили номер базового канала]

C3 GOTO LCTX [OID ADDR_MEM NUM] [загрузили заголовок дискового объекта]

E2D [O N]

C 4 Channels [OID NUM CHANHIST] [получили канал для истории]

G_HIS ILS

[O N C HISTORY] [HISTORY д.б. <>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] CLONE_AGG

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

Определим ему цвет

«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]

«способы

…

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

«Идти» 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) ~> psumma
(sClient.num_sch=Schet.num_sch
(Schet, Client)), «:=»(True) ~> pPremia
(Client)}

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

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

1.1Операция селекции выбирает огромное количество счетов

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

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

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

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

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

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

Примечание 2
: Оба конфигурации происходят в границах одной транзакции, посколь­ку эти деяния являются экземплярами 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] С. Кузнецов “Сохранность и целостность, либо Худший неприятель для себя — это ты сам”

]]>