45007 (664111)

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла

Содержание

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

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

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

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

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

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

2.4. Вложенные транзакцию………………………………………......... 11

3. Encina и DCE…………………………………………………………………. 14

4. X/Open DTP…………………………………………………………………... 17

5. Классификация систем обработки транзакций……………………………. 19

6. Языки транзакций………………………………………………………......... 20

7. Мониторы обработки транзакций третьего поколения…………..……….. 21

Заключение……………………………………………………………………….24

Литература

Введение

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

• принципы обработки транзакций в информационных системах;

• последние достижения в мире коммерческих систем обработки транзакций;

• языки обработки транзакций;

• стандарты;

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

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

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

В области обработки транзакций имеет место следующая классификация (рис. 1).

Рисунок 1. Поколения систем обработки транзакций.

- Первое поколение. Единые монолитные системы, взаимодействующие с пользователем посредством простейших терминалов.

- Второе поколение. Поддержка продуктов многих поставщиков, интеллектуальные клиентские системы, поддержка множества систем баз данных, как правило, при помощи протоколов двухфазовой фиксации (второе поколение отражает нынешнее положение дел в этой области).

- Третье поколение. Зарождающееся поколение систем, более адекватно, чем это возможно сегодня, отражающее потребности бизнеса.

Хотя понятие "обработка транзакций" применимо практически к любой компьютерной среде, в особенности в мире бизнеса, однако традиционно использование мониторов обработки транзакций ограничивалось окружениями крупномасштабных центров обработки данных, функционирующих на базе мэйнфреймов, в таких прикладных областях, как резервирование авиабилетов или международные банковские операции. За последние годы, отчасти за счет того, что корпоративные информационные системы все более приобретают черты распределенности и неоднородности, мониторы обработки транзакций стали применяться и во многих других вертикальных приложениях (здравоохранение, страхование, торговля). По оценкам Gartner Group, к 1995 г. в 50% вновь создаваемых приложениях на основе реляционных СУБД будут применяться средства обработки транзакций.

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

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

Ко всем типам транзакций предъявляется набор требований, известный под названием ACID (atomocity, consistency, isolation, durability). Смысл этих требований заключается в следующем.

- Атомарность. Транзакция представляет собой некоторый набор действий. Система обеспечивает их выполнение по принципу "все или ничего" - либо выполняются все действия, т. е. транзакция фиксируется, либо не выполняется ни одно, т. е. транзакция прерывается.

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

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

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

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

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

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

Плоские транзакции - это основные строительные блоки для реализации принципа атомарности; иначе говоря, выделение некоторой последовательности действий в виде плоской транзакции обеспечивает принцип "все или ничего".

Во многих прикладных окружениях, в особенности с централизованными обработкой и управлением ресурсами (например, базами данных и файлами), механизм плоских транзакций на протяжении многих лет предоставлял вполне удовлетворительные возможности как для создания, так и для выполнения приложений; простые преобразования состояний системы вполне укладывались в рамки атомарных единиц работы.

По мере того как данные и вычисления становятся все более распределенными, атомарность плоских транзакций становится значительным неудобством. Рассмотрим пример на рис. 2. Согласно правилам обработки плоских транзакций, либо должны успешно завершиться все компоненты глобальной транзакции, либо не должна завершиться ни одна из них. Например, если неудачей завершилось только изменение одной удаленной базы данных под управлением некоторого менеджера ресурсов, то и все остальные компоненты должны быть возвращены в состояние, предшествовавшее началу транзакции. Учитывая количество информации, обрабатываемой в крупной или даже средней организации со множеством серверов LAN на ПК и, возможно, с мобильными базами данных, можно предположить, что вероятность отказа хотя бы одного узла весьма высока. Если применяется модель плоских транзакций, то придется заново выполнять все составные части транзакции, что существенно повышает требования к вычислительным ресурсам и отнимает значительную долю пропускной способности системы.

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

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

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

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

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

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

Проводились исследовательские работы по изучению применимости так называемых устойчивых (persistent) контрольных точек, которые фиксируются в дисковой или другой долговременной памяти, для того чтобы результаты выполнения были доступны после системных крахов. Однако Грей и Реутер отмечают, что "здесь не видно пока никакого решения, которое можно было бы принять безоговорочно". Это вряд ли следует считать большой проблемой, поскольку две новые модели транзакций - вложенные и многозвенные транзакции - предоставляют схожие возможности при том, что формальные определения этих парадигм значительно лучше проработаны и общеприняты. Рассмотрим вначале многозвенные транзакции.

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

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

Рисунок 3. Концептуальное представление многозвенных транзакций.

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

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

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

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

Модель вложенных транзакций включает понятие головной транзакции, которая управляет выполнением всей иерархии. В рамках иерархии могут присутствовать транзакции разных уровней вложенности (рис. 4). Концевые узлы иерархии представляют собой плоские транзакции. Отдельные ветви иерархии могут иметь разную длину, т. е. концевые транзакции могут находиться на разном "расстоянии" от головной транзакции (корня дерева транзакций).

Рисунок 4. Структура вложенных транзакций.

Правила и модели вложенных транзакций были впервые разработаны Эллиотом Моссом в 1981 году. В модели Мосса реальные действия могли производиться только концевыми субтранзакциями, но Грей и Реутер отмечают, что это правило ограничивает функции вложения транзакций и, что его отмена дает дополнительные возможности распараллеливания действий над разделяемыми объектами при введении абстракции многоуровневых объектов.

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

- Правило фиксации. Выполнение оператора COMMIT WORK в некоторой субтранзакции делает ее результаты видимыми только для родительской транзакции. Фактическая фиксация субтранзакции происходит только после фиксации всех ее предков вплоть до головной транзакции.

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

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

Список файлов реферата