Здесь можно найти учебные материалы, которые помогут вам в написании курсовых работ, дипломов, контрольных работ и рефератов. Так же вы мажете самостоятельно повысить уникальность своей работы для прохождения проверки на плагиат всего за несколько минут.
ЛИЧНЫЙ КАБИНЕТ 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

 
Поиск учебного материала на сайте
Поиск по названию работы
Поиск по тексту работы

Повышение оригинальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение оригинальности любого файла в формате MS Word. После такого повышения оригинальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, РУКОНТЕКСТ, etxt.ru. Программа «StudentHelp» работает по уникальной технологии так, что на внешний вид, файл с повышенной оригинальностью не отличается от исходного.

Результат поиска


Наименование:
курсовая работа Базы данных Вар. 1

Информация:

 Тип работы: курсовая работа. Добавлен: 07.05.2012. Год: 2011. Страниц: 7. Уникальность по antiplagiat.ru: < 30%

Описание (план):

Содержание

Введение….………………..3
Основная часть……………….5
1 Основы обработки транзакций ……….………..……...5
1.1 Структура транзакций ……….……….………..………..………5
1.2 Параллельное выполнение транзакций ..……….…….………..……..….7
1.3 Транзакции и восстановление данных ..……….………..………..…8
2 Принципы и модели обработки транзакций ………..….………......9
2.1 Плоские транзакции ……….………..………...……9
2.2 Контрольные точки ……….………..…….........11
2.3 Многозвенные транзакции ………..………...13
2.4 Вложенные транзакции ..………..….……….…..…..14
3 Классификация систем обработки транзакций.………...………..…..17
3.1 Encino и DCE Список использованных источников………..………..…17
3.2 Языки транзакций ….……….……….…..… 19
3.3 Мониторы обработки транзакций третьего поколения….………...………..…..20
3.4 X/Open DTP….…...…..………..……….…………….………22
Заключение………...……………….….……24
Глоссарий………...………….…….………...……….…..26
Список использованных источников………...…….………...……….…….…..29
Приложения………...…...………...………..……….……30

Введение

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


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

Основная часть

    1 Основы обработки транзакций


    1.1Структура транзакций

Можно рассматривать обработку транзакций в самом общем виде, включая множество парадигм – от пакетной и простой терминально-интеракт вной обработки (на самом деле концептуальными источниками компьютерной обработки транзакций можно считать шумерские глиняные таблички с записями торговых операций, сделанными за многие тысячелетия до зарождения идеи вычислительной машины). Более конкретно, дисциплина транзакций включает в себя различные функции для поддержки компьютерных приложений, основанных на коммуникациях. В самом общем смысле системы обработки транзакций могут охватывать все, что может присутствовать в компьютерной системе: базы данных, сети, операционные системы и т.д.
В области обработки транзакций имеет место следующая классификация1:
Первое поколение. Единые монолитные системы, взаимодействующие с пользователем посредством простейших терминалов.
Второе поколение. Поддержка продуктов многих поставщиков, интеллектуальные клиентские системы, поддержка множества систем баз данных, как правило, при помощи протоколов двухфазовой фиксации (второе поколение отражает нынешнее положение дел в этой области).
Третье поколение. Зарождающееся поколение систем, более адекватно, чем это возможно сегодня, отражающее потребности бизнеса.
Хотя понятие "обработка транзакций" применимо практически к любой компьютерной среде, в особенности в мире бизнеса, однако традиционно использование мониторов обработки транзакций ограничивалось окружениями крупномасштабных центров обработки данных, функционирующих на базе мэйнфреймов, в таких прикладных областях, как резервирование авиабилетов или международные банковские операции. За последние годы, отчасти за счет того, что корпоративные информационные системы все более приобретают черты распределенности и неоднородности, мониторы обработки транзакций стали применяться и во многих других вертикальных приложениях (здравоохранение, страхование, торговля)2.
Структура каждой транзакции строится на основании имеющейся спецификации требований пользователей. Для создания этой спецификации разработано множество методов, включающих специальную систему для определения нужных пользователям транзакций. Подобные транзакции могут представлять собой сложные операций, которые в результате анализа раскладываются на несколько более простых операций, каждая из которых представляет собой отдельную транзакцию.
Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции. Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (roll back) транзакции. Зафиксированная транзакция не может быть отменена. Если оказывается, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. Эту транзакцию называют компенсирующей3. Следует отметить, что отмененная транзакция может быть еще раз запущена позже и в зависимости от причин предыдущего отказа вполне успешно завершена и зафиксирована в базе данных.
Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично в случае ее аварийного завершения в базе данных автоматически будет выполнена команда ROLLBACK.

    1.2 Параллельное выполнение транзакций

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

    1.3 Транзакции и восстановление данных

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

    2 Принципы и модели обработки транзакций


    2.1 Плоские транзакции

Транзакция обладает четырьмя важными свойствами, известными как свойства ACID: (Atomicity) Атомарность. Транзакция выполняется, как атомарная операция либо выполняется вся транзакция целиком, либо она целиком не выполняется. (Consistency) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.
(Isolation) Изоляция. Транзакции разных пользователей не должны мешать друг другу (например, как если бы они выполнялись строго по очереди).
(Durability) Долговечность. Если транзакция выполнена, то результаты ее работы должны сохраниться в базе данных, даже если в следующий момент произойдет сбой системы.
Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и продолжается до тех пор, пока не произойдет одно из следующих событий:
Подана команда COMMIT WORK (зафиксировать транзакцию).
Подана команда ROLLBACK WORK (откатить транзакцию).
Произошло отсоединение пользователя от СУБД.
Произошел сбой системы.
Команда COMMIT WORK завершает текущую транзакцию и автоматически начинает новую транзакцию. При этом гарантируется, что результаты работы завершенной транзакции фиксируются, т.е. сохраняются в базе данных. Команда ROLLBACK WORK приводит к тому, что все изменения, сделанные текущей транзакцией откатываются, т.е. отменяются так, как будто их вообще не было. При этом автоматически начинается новая транзакция.
При сбое системы происходят более сложные процессы. Кратко суть их сводится к тому, что при последующем запуске системы происходит анализ выполнявшихся до момента сбоя транзакций. Те транзакции, для которых была подана команда COMMIT WORK, но результаты работы которых не были занесены в базу данных выполняются снова (накатываются). Те транзакции, для которых не была подана команда COMMIT WORK, откатываются5.При отсоединении пользователя от СУБД происходит автоматическая фиксация транзакций.
Существуют многочисленные модели транзакций, поддерживающих эти принципы. Они варьируются от простейших, таких как "плоские" транзакции, до более изощренных, таких как вложенные или многозвенные. Рассмотрим эти модели более подробно, поскольку именно сложные модели в значительной мере пределяют особенности обработки транзакций в коммерческих информационных системах будущего.
Модели плоских транзакций соответствует один управляющий слой, которому подчинено произвольное число элементарных действий. В современных информационных системах - это, как правило, единственная поддерживаемая на прикладном уровне модель транзакций, хотя внутренние компоненты системы (например, SQL) могут включать более изощренные средства обработки транзакций; однако они не доступны на уровне прикладного программирования.
Плоские транзакции - это основные строительные блоки для реализации принципа атомарности; иначе говоря, выделение некоторой последовательности действий в виде плоской транзакции обеспечивает принцип "все или ничего"6.
Во многих прикладных окружениях, в особенности с централизованными обработкой и управлением ресурсами (например, базами данных и файлами), механизм плоских транзакций на протяжении многих лет предоставлял вполне удовлетворительные возможности как для создания, так и для выполнения приложений. Простые преобразования состояний системы вполне укладывались в рамки атомарных единиц работы.
По мере того как данные и вычисления становятся все более распределенными, атомарность плоских транзакций становится значительным неудобством. Согласно правилам обработки плоских транзакций, либо должны успешно завершиться все компоненты глобальной транзакции, либо не должна завершиться ни одна из них. Например, если неудачей завершилось только изменение одной удаленной базы данных под управлением некоторого менеджера ресурсов, то и все остальные компоненты должны быть возвращены в состояние, предшествовавшее началу транзакции. Учитывая количество информации, обрабатываемой в крупной или даже средней организации со множеством серверов LAN на ПК и, возможно, с мобильными базами данных, можно предположить, что вероятность отказа хотя бы одного узла весьма высока. Если применяется модель плоских транзакций, то придется заново выполнять все составные части транзакции, что существенно повышает требования к вычислительным ресурсам и отнимает значительную долю пропускной способности системы.
Очевидно, что в наш век сильно распределенных вычислений необходимо каким-то образом проводить декомпозицию плоских транзакций. Модификация модели плоских транзакций, сохраняющая свойство атомарности, но снижающая потребность в повторном выполнении действий (т. е. в "переработках&q ot;), включает понятие контрольных точек, которое мы обсудим в следующем разделе.

    2.2 Контрольные точки

При наступлении определенного события (например, количество страниц в dirty-списке превысило определенный порог, или количество свободных страниц в буфере уменьшилось и достигло критического значения) система принимает контрольную точку7. Принятие контрольной точки включает выталкивание во внешнюю память содержимого буферов базы данных и специальную физическую запись контрольной точки, которая представляет собой список всех осуществляемых в данный момент транзакций. Контрольные точки устанавливаются в прикладной программе для того, чтобы отметить моменты, начиная с которых можно продолжить вычисления в случае возникновения проблем. В идеале контрольные точки должны соответствовать частично согласованным состояниям (например, после построения вспомогательной таблицы в программе, которая затем будет использоваться для вычислений с участием еще какой-либо таблицы).
По достижении очередной контрольной точки в транзакции создается новое атомарное действие, которое запускается на выполнение. Только последнее атомарное действие всей последовательности может выполнить фиксацию (COMMIT WORK) транзакции; оператор COMMIT WORK передается всем предыдущим атомарным действиям, пока все они не будут зафиксированы. В отличие от модели многозвенных транзакций, которые мы рассмотрим в следующем разделе, контрольная точка не приводит к необратимой фиксации, выполненной до этого момента работы.
Прерывания (ROLL BACK) или откаты, транзакции могут инициироваться из любого атомарного действия, а не только из последнего; хотя в любой заданный момент времени прерывание может инициировать только действие, запущенное последним. (Это значит, что если для какого-то атомарного действия была достигнута контрольная точка, то для этого действия уже не может быть в дальнейшем принято решение об откате.) Откат может быть произведен до любой из предыдущих контрольных точек, поэтому менеджер обработки транзакций должен воспринимать параметр, указывающий, до какой именно контрольной точки нужно произвести откат (в идеале логика приложения должна предусматривать определение контрольной точки, до которой в случае неудачи следует откатить выполнение).8
Проводились исследовательские работы по изучению применимости так называемых устойчивых (persistent) контрольных точек, которые фиксируются в дисковой или другой долговременной памяти, для того чтобы результаты выполнения были доступны после системных крахов. Однако Грей и Рейтер отмечают, что "здесь не видно пока никакого решения, которое можно было бы принять безоговорочно". Это вряд ли следует считать большой проблемой, поскольку две новые модели транзакций - вложенные и многозвенные транзакции - предоставляют схожие возможности притом, что формальные определения этих парадигм значительно лучше проработаны и общеприняты. Рассмотрим вначале многозвенные транзакции.

2.3 Многозвенные транзакции

Модель многозвенных транзакций концептуально подобна модели контрольных точек, но она предполагает фиксацию части работы, сделанной до некоторого момента; возможность отката зафиксированных действий исключается.
Приложение тем не менее остается в состоянии транзакции; т. е. при этом не происходит инициации очередной транзакции, ее завершения, инициации следующей и ее завершения и т. д. В рамках многозвенной транзакции сохраняются все необходимые элементы контекста выполнения (курсоры баз данных, открытые файлы и т. д.), хотя ресурсы, ставшие ненужными, можно освобождать.
Модель многозвенных транзакций, (смотри приложение А), включает оператор CHAIN WORK - неделимую комбинацию операторов COMMIT WORK и BEGIN WORK, - которая неравноценна последовательному выполнению операторов COMMIT WORK и BEGIN WORK по отдельности.
При выполнении этих операторов по отдельности контекст пропадает; некоторая другая транзакция может "вклиниться&quo ; и изменить значения в базе данных, которые нужны для выполнения следующего "звена" многозвенной транзакции, прежде чем это звено начнет выполняться.
Таким образом, многозвенные транзакции концептуально эквивалентны транзакциям с контрольными точками с той разницей, что откат может производиться только до последней зафиксированной точки, а не до любой предыдущей контрольной точки.
Обе модели транзакций - многозвенные и с контрольными точками - позволяют описывать последовательности действий; различия касаются лишь возможностей отката и устойчивости выполненных до заданной точки действий. Последняя модель, которую мы обсудим, - это модель, которая позволяет описывать не последовательности, а иерархии субтранзакций.

2.4 Вложенные транзакции

Модель вложенных транзакций включает понятие головной транзакции9, которая управляет выполнением всей иерархии. В рамках иерархии могут присутствовать транзакции разных уровней вложенности. Концевые узлы иерархии представляют собой плоские транзакции. Отдельные ветви иерархии могут иметь разную длину, т. е. концевые транзакции могут находиться на разном "расстоянии" от головной транзакции (корня дерева транзакций).
Правила и модели вложенных транзакций были впервые разработаны Элиотом Моссом в 1981 году. В модели Мосса реальные действия могли производиться только концевыми субтранзакциями, но Грей и Реутер отмечают, что это правило ограничивает функции вложения транзакций и, что его отмена дает дополнительные возможности распараллеливания действий над разделяемыми объектами при введении абстракции многоуровневых объектов.Мосс сформулировал три правила для управления вложенными транзакциями:Правило фиксации. Выполнение оператора COMMIT WORK в некоторой субтранзакции делает ее результаты видимыми только для родительской транзакции. Фактическая фиксация субтранзакции происходит только после фиксации всех ее предков вплоть до головной транзакции. Правило прерывания (отката). Если субтранзакция некоторого уровня, включая головную, откатывается, то же самое должно быть сделано для всех ее потомков, независимо от статуса фиксации любой из них на локальном уровне. Правило видимости. Все действия, выполненные в рамках субтранзакции, при ее фиксации становятся видимыми родительской транзакции. Все объекты, захваченные некоторой транзакцией, доступны ее потомкам. Соседние транзакции (относящиеся к одному уровню и имеющие общего родителя) "не видны" друг другу ни в том, ни в другом смысле, что позволяет выполнять их параллельно.
Из свойств ACID для субтранзакций выполняются свойства атомарности, согласованности и изолированности. Но поскольку COMMIT WORK для субтранзакции на самом деле не означает ее фиксации до фиксации всей транзакции, то свойство долговечности не выполняется, поэтому субтранзакции не эквивалентны плоским транзакциям. Например. Если транзакция Б запущена внутри транзакции А, и для транзакции Б подана команда COMMIT WORK, то фиксация данных транзакции Б является условной, т.к. внешняя транзакция А может откатиться. Результаты работы внутренней транзакции Б будут окончательно зафиксированы только если будет зафиксирована внешняя транзакция А.
Как и другие модели, вложенные транзакции имеют вариации, (смотри приложение Б), в том числе модель многоуровневых (multilevel) транзакций, где субтранзакция ST1 "предварительно фиксирует" свои результаты. При этом для нее предусмотрена компенсирующая субтранзакция, которая может отменить выполненные ST1 действия, если происходит прерывание всей транзакции в целом. Компенсирующие транзакции позволяют отменять результаты почти в реальном времени; в их отсутствие приходится применять сценарии восстановления с анализом времени произведенных изменений, для чего используются дорогостоящие оперативные ресурсы, обеспечивающие возврат базы данных в согласованное состояние (например, с применением журналов или путем "сопоставления фрагментов" головоломки-мозаики для того чтобы определить, каким должно быть согласованное состояние базы данных).
Хотя можно представить себе приложения и системы, в которых многозвенные и вложенные транзакции были бы полезны, однако лишь в начале 90-х годов в коммерческих приложениях на смену плоским транзакциям начали приходить другие. Интересно, впрочем, отметить, что при изучении транзакций SQL можно обнаружить некоторые признаки "псевдовложеннос и", по крайней мере в способах обработки операторов (это в настоящее время недоступно разработчикам приложений; однако принятый в настоящее время стандарт SQL3 содержит контрольные точки и, вероятно, в него войдут операторы управления многозвенными транзакциями).
Каждый оператор внутри транзакции, которая представляет собой, например, последовательность операторов UPDATE и DELETE, может завершиться успешно или неуспешно. Даже если один или несколько операторов завершаются неудачей, транзакция в целом может продолжаться, если в ее логике для этих случаев явно не предусмотрено прерывание с откатом в начальное состояние. Все успешно завершившиеся до прерывания операторы (которые в этой модели можно представлять как субтранзакции) будут отменены, если происходит откат всей транзакции. Разработчикам приложений приходилось как-то компенсировать недоступность имеющихся в SQL свойств псевдовложенности, применяя различные ухищрения для построения архитектур транзакций, более соответствующих их потребностям, чем простейшие плоские транзакции. Когда на рынке утвердится стандарт SQL3, и начнут появляться совместимые с ним продукты, разработчики приложений на основе SQL СУБД смогут непосредственно пользоваться преимуществами новых моделей транзакций.












    3 Классификация систем обработки транзакций


    3.1 Encino и DCE

С появлением множества стандартизированных систем обработки транзакций нового поколения полезным представляется проведение их классификации с точки зрения спектра предоставляемых ими функций. Подобную классификацию, включающую пять измерений, предложили Абрахам Лефф и Калтон Пу из Колумбийского университета:
M - множество машин;
P - множество процессов;
H - степень неоднородности машин и программного обеспечения;
D - множество логических данных;
S - множество узлов.
Эта классификация характеризует любую систему обработки транзакций, от простейших (P1, M1, H1, D1, S1) до более сложных многоузловых неоднородных окружений с поддержкой разнотипных наборов данных (Pn, Mn, Hn, Dn, Sn). В статье, написанной в 1991 г., эти авторы представили трехмерную классификацию, которую они применили для оценки различных исследовательских и коммерческих систем.
Монитор обработки транзакций Encina10 корпорации Transarc можно рассматривать как коммерческий продукт второго поколения, однако более развитый, отражающий новейшие достижения в этой области. Encina включает модель вложенных транзакций и расширяет возможности среды DCE (Distributed Computing Environment), предложенной организацией OSF (Open Software Foundation).
Прообразом Encina был прототип системы обработки транзакций Camelot, разработанный в университете Карнеги-Меллон в Питтсбурге. Технология, лежащая в основе Camelot, и применяемый в этой системе язык программирования Avalon описаны в работе Camelot and Avalon: A Distributed Transaction Processing Facility. Camelot считается "первой реализацией вложенных транзакций в системе обработки транзакций" (в отличие от псевдовложенности, которую мы обсуждали в предыдущем разделе, или от внутрисистемной вложенности, недоступной для разработчиков приложений).
Архитектура соответствует степени распределенности, характерной для разрабатываемых или проектируемых в настоящее время информационных систем. Использование серверов приложений здесь соответствует философии выделения процедур обработки данных, в отличие от философии выделения самих данных. Хотя пользователи, имеющие достаточные полномочия, могут непосредственно осуществлять доступ к удаленным данным, но в данном случае цель состоит в том, чтобы полностью передать управление данными серверам приложений.
Монитор Encina использует предоставляемые DCE абстрактные уровни управления ресурсами и коммуникационных менеджеров и сам обеспечивает прямое подключение к ресурсам и коммуникационным менеджерам, не подчиненным DCE. Модульность и многоуровневость - черты, характерные для современных открытых систем и корпоративных вычислительных архитектур, - находят отражение и в обработке транзакций. Можно с уверенностью предположить, что концепции открытых систем в дальнейшем будут еще более активно применяться в сфере обработки транзакций.
Одна из задач, решаемых монитором Encina, - это поддержка свойств ACID в среде баз данных клиент-сервер при условии, что клиенты и серверы независимо хранят записи о состоянии транзакций.
В Encina код, обеспечивающий соблюдение свойств ACID, заключен в менеджерах ресурсов; приложения и другие программы верхнего уровня выдают запросы на фиксацию или прерывание транзакций, которые менеджеры транзакций реализуют на соответствующих ресурсах нижнего уровня.
Encina включает язык разработки приложений Transactional C, содержащий набор макросов и библиотек для определения транзакций и управления ими. Ключевое слово TRANSACTION служит для определения транзакций верхнего уровня или вложенных. Функции, задаваемые при помощи ключевых слов ONABORT и ONCOMMIT, описывают действия, выполняемые при откате или, соответственно, фиксации транзакции любого уровня.
Интересно было бы понаблюдать, как пойдет развитие не только конкретного продукта Encina, но и всей области "открытой обработки транзакций" в целом. Тенденции усиления распределенности и неоднородности, которые направляют развитие технологий баз данных и информационного управления, требуют определенной степени открытости всех компонентов информационных систем (в том числе сервисов операционных систем, безопасности, баз данных, мониторов транзакций). Хотя старые "закрытые" продукты и аппаратные платформы, поддерживаемые ими, просуществуют еще довольно долго, но тенденции неизбежно будут оказывать все более значительное влияние на развитие систем обработки транзакций.

3.2 Языки транзакций

В разделе 3.1. была рассмотрена Encina - монитор транзакций корпорации Transarc - который включает множество библиотек и макросов, составляющих среду разработки Transactional C. Альтернативный способ задания директив обработки транзакций состоит в применении специального языка11. В качестве примера рассмотрим язык InterBase Parallel Language (IPL), входящий в состав неоднородной распределенной cреды баз данных InterBase. IPL разработан с учетом поддержки высокой степени параллелизма и взаимодействия между субтранзакциями, принадлежащими общей глобальной транзакции. IPL предназначался для поддержки транзакций разных типов (т. е. смешанных транзакций), а также как системно-независимый декларативный язык, обеспечивающий прозрачность управления транзакциями.
Программа на IPL представляет собой блок, обрамленный ключевыми словами program - endprogram, и включает декларации записей и описания субтранзакций. Поскольку IPL постоянно развивается и в настоящее время в стадии исследований находится графический интерфейс, то за более полной информацией мы отсылаем читателя к материалам проекта InterBase.
Альтернативный подход к спецификации транзакций - использование языка, ориентированного не на глобальную схему или на специфическую для какого-либо продукта реализацию, а на нейтральную семантическую модель данных. В связи с возрастающей ролью моделирования данных применение архитектур транзакций непосредственно к семантической модели также приобретает важное значение.
. Классические процедуры интеграции 1970-х годов ориентировались на отображение диаграмм потоков данных (DFD - Data Flow Diagram), на сущности и атрибуты диаграмм сущность-связь (ERD - Entity-Relation Diagram). Объектно-ориентирова ное моделирование обеспечивает определение объектов вместе с присущими им операциями, но ни тот ни другой вид моделирования не содержит средств для описания семантики транзакций. Выработка языков описания транзакций по отношению к некоторой модели данных с последующим переносом языковых средств в среду, обеспечивающую графическое представление вложенных, многозвенных и других развитых моделей транзакций, даст в будущем значительное увеличение продуктивности и надежности проектирования систем обработки транзакций.12

3.3 Мониторы обработки транзакций третьего поколения

Обратимся еще раз к мониторам обработки транзакций третьего поколения13, о которых упоминалось в разд. 2.
К важнейшим характеристикам нового поколения средств обработки транзакций относятся следующие:
Моделирование бизнес-процессов и управление ими. В предыдущем разделе мы рассмотрели основные направления развития языков описания транзакций. Философия обработки транзакций в настоящее время, даже для окружений, совместимых с OSI-TP и X/Open DTP, ориентирована на встраивание спецификаций транзак
и т.д.................

Смотреть работу подробнее



Скачать работу


Скачать работу с онлайн повышением оригинальности до 90% по antiplagiat.ru, etxt.ru


Смотреть полный текст работы бесплатно


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.
© 2009...2024
WEBKURSOVIK.RU – ЭФФЕКТИВНАЯ ПОМОЩЬ СТУДЕНТУ
webkursovik@yandex.ru