Курсовая работа: Модели транзакций

Курсовая работа: Модели транзакций

АГЕНСТВО ПО ОБРАЗОВАНИЮ

Федеральное государственное образовательное учреждение высшего профессионального образования

«Чувашский государственный университет имени И.Н.Ульянова»

Алатырский филиал

Кафедра Высшей математики и информационных технологий

КУРСОВАЯ РАБОТА

по дисциплине «Базы данных и СУБД»

на тему: «Модели транзакций»

Выполнил: студент

группы АФТ 61-05

Краснов Д.П.

Руководитель:

ст. преп. Алякина Л.А.

2010

ОГЛАВЛЕНИЕ

Введение

ГЛАВА 1. Общие сведения о транзакциях

1.1 Поддержка транзакций

1.2 Свойства транзакций

ГЛАВА 2.Модели транзакций

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

2.2 Модель вложенных транзакций

2.3 Хроники

2.4 Модель многоуровневых транзакций

2.5 Модель рабочих потоков

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

Заключение

Литература

ВВЕДЕНИЕ

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

. поддержка транзакций;

. свойства транзакций;

. модели транзакций;

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

ГЛАВА 1 Общие сведения о транзакциях

1.1 Поддержка транзакций

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

Транзакция является логической единицей работы, выполняемой в базе данных. Она может быть представлена отдельной программой, частью программы или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения администратора базы данных эксплуатация любого приложения может расцениваться как ряд транзакций, в промежутках между которыми выполняется обработка данных, осуществляемая вне среды базы данных.

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

(рис. 1)

модель транзакция хроника

На (рис. 1) используется обозначение read (staffNo = x, salary), указывающее, что требуется считать элемент данных salary для записи, в которой ключевое значение равно х. В данном примере транзакция состоит из двух операций, выполняемых в базе данных (read и write), и одной операции, выполняемой вне базы данных (salary = salary * 1.1).

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

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

Порядок выполнения операций транзакции принято обозначать с помощью диаграммы переходов. Пример такой диаграммы приведен на (рис. 2). Следует отметить, что на этой диаграмме, кроме очевидных состояний ACTIVE, COMMITTED и ABORTED имеются еще два состояния, описанные ниже.

(рис. 2.)

PARTIALLY COMMITTED. Это состояние возникает после выполнения последнего оператора. В этот момент может быть обнаружено, что в результате выполнения транзакции нарушены правила упорядочения или ограничения целостности, поэтому транзакцию необходимо завершить аварийно. Еще один вариант развития событий состоит в том, что в системе происходит отказ и все данные, обновленные в транзакции, невозможно успешно записать во внешнюю память. В подобных случаях транзакция должна перейти в состояние FAILED и завершиться аварийно. А если транзакция выполнена успешно, то все результаты обновления могут быть надежно записаны во внешней памяти и транзакция может перейти в состояние COMMITTED.

FAILED. Такое состояние возникает, если транзакция не может быть зафиксирована или произошло ее аварийное завершение, когда она находилась в состоянии ACTIVE, Это аварийное завершение могло возникнуть из-за отмены транзакции пользователем или в результате действия протокола управления параллельным доступом вызвавшего аварийное завершение транзакции для обеспечения упорядочиваемости операций базы данных.

1.2 Свойства транзакций

Существуют определенные свойства, которыми должна обладать любая из транзакций. Ниже представлены четыре основных свойства транзакций, которые принято обозначать аббревиатурой ACID (Atomicity, Consistency, Isolation, Durability — неразрывность, согласованность, изолированность, устойчивость), состоящей из первых букв названий этих свойств.

Неразрывность. Это свойство, для описания которого применимо выражение "все или ничего". Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вообще. За обеспечение неразрывности отвечает подсистема восстановления СУБД.

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

Изолированность. Все транзакции выполняются независимо друг от друга. Иными словами, промежуточные результаты незавершенной транзакции не должны быть доступны для других транзакций. За обеспечение изолированности отвечает подсистема управления параллельным выполнением.

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

ГЛАВА 2. Модели транзакций

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

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

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

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

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

2.2 Модель вложенных транзакций

Модель вложенных транзакций. Транзакция рассматривается как коллекция взаимосвязанных подзадач или субтранзакций, каждая из которых также может состоять из любого количества субтранзакций. Модель вложенных транзакций была предложена Моссом (Moss) в 1981 году. В этой модели вся транзакция рассматривается как набор связанных подзадач, называемых субтранзакциями, каждая из которых также может состоять из произвольного количества субтранзакций. В данном определении полная транзакция представляет собой древовидную структуру или некоторую иерархию субтранзакций. В модели вложенных транзакций присутствует транзакция верхнего уровня, содержащая некоторое количество дочерних транзакций, каждая из которых, в свою очередь, может включать вложенные транзакции, и т.д. В исходном варианте, предложенном Моссом, выполнять операции в базе данных разрешается только транзакциям самого нижнего уровня (субтранзакциям самого нижнего уровня вложенности). В табл. 2 приведен пример вложенной транзакции Т1, в которой выполняется резервирование места в гостинице, заказ билетов на самолет и аренду автомобиля. Она включает субтранзакции заказа авиабилетов (Т2), бронирования места в отеле (Т5) и найма автомобиля (Т6). Транзакция заказа авиабилетов тоже является вложенной и состоит из двух субтранзакций: заказа билета для перелета из Лондона в Париж (Т3) и бронирования места на соответствующем рейсе из Парижа в Нью-Йорк (Т4). Завершение работы транзакций должно происходить в направлении снизу вверх. Следовательно, транзакции Т3 и Т4 должны закончить свою работу до завершения работы их родительской транзакции T2, а работа транзакции Т2 должна быть завершена до окончания работы ее родительской транзакции Т1. Однако отмена транзакции на некотором уровне не оказывает влияния на выполнение транзакций более высоких уровней. Вместо этого родительской транзакции разрешается выполнить свою собственную операцию восстановления нормальной работы, воспользовавшись одним из следующих допустимых способов.

Повторить выполнение субтранзакции.

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

Прекратить свое выполнение.

Обновления, выполненные завершенными субтранзакциями промежуточных уровней, должны быть видны только в транзакциях, которые являются по отношению к ним родительскими. Поэтому, когда транзакция Т3 будет завершена, внесенные ею изменения будут видны только в транзакции Т2. Они будут недоступны транзакции Т1 или любой другой транзакции, внешней по отношению к транзакции Т1. Более того, завершение субтранзакции является условно зависимым от нормального завершения или отмены ее родительских транзакций. При использовании данной модели транзакция верхнего уровня обладает всеми четырьмя свойствами (ACID), которыми должны обладать традиционные плоские (не допускающие вложенности) транзакции.

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

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

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

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

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

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

Табл. 2. Пример вложенной транзакции

2.3 Хроники

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

Концепция хроник (sagas), которая была введена Гарсия-Молина (Garsia-Molina) и Салемом (Salem) в 1987 году, построена на использовании понятия компенсирующих транзакций. СУБД гарантирует, что либо все входящие в хронику транзакции будут успешно завершены, либо будут запущены компенсирующие транзакции, необходимые для устранения достигнутых частичных результатов. В отличие от метода вложенных транзакций, допускающего произвольный уровень вложения, метод хроник разрешает наличие единственного уровня вложения. Более того, для каждой выделенной субтранзакции должна существовать соответствующая компенсирующая транзакция, которая будет семантически правильно аннулировать результаты, достигаемые с помощью данной субтранзакции. Таким образом, если имеется хроника, состоящая из последовательности n транзакций Т1, Т2, ..., Тn с соответствующим набором компенсирующих транзакций С1, C2, ..., Cn, то окончательный результат выполнения хроники будет определяться одной из приведенных ниже последовательностей транзакций.

1.T1, Т2, …, Tn — если вся транзакция была успешно завершена.

2.T1, T2, ..., Ti, Сi-1, ..., C2, С1 — если выполнение субтранзакции Тi было аварийно прекращено.

Поэтому, если обратиться к примеру с резервированием места в гостинице, описанному выше, то при подготовке соответствующей хроники потребуется изменить структуру транзакции с целью удаления вложенной транзакции бронирования авиабилетов: T3, T4, T5, T6.

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

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

2.4 Модель многоуровневых транзакций

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

Одним из вариантов модели открытых вложенных транзакций является модель многоуровневых транзакции, в которой дерево субтранзакций является сбалансированным. Узлы одного и того же уровня дерева соответствуют операциям одного и того же уровня абстракции в СУБД. Ребра древовидного графа модели многоуровневых транзакций моделируют реализацию операции посредством последовательности операций более низкого уровня. Уровни n-уровневой транзакции обозначаются как L0, L1, …, Ln, где L0 — самый низкий уровень дерева, a Ln — корень дерева. Методы обработки обычных плоских транзакций гарантируют, что на самом низком уровне (L0) конфликты будут отсутствовать. Основная концепция модели многоуровневых транзакций состоит в том, что две операции на уровне Li могут не конфликтовать, даже если их реализации на следующем, более низком уровне Li-1 конфликтуют. Поскольку в ней используется информация о конфликтах на конкретном уровне, модель многоуровневых транзакций позволяет достичь более высокой степени параллельности по сравнению с моделями обработки плоских транзакций.

2.5 Модели рабочих потоков

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

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

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

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

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

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

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

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

С появлением множества стандартизированных систем обработки транзакций нового поколения полезным представляется проведение их классификации с точки зрения спектра предоставляемых ими функций. Подобную классификацию, включающую пять измерений, предложили Абрахам Лефф и Калтон Пу из Колумбийского университета:

M - множество машин;

P - множество процессов;

H - степень неоднородности машин и программного обеспечения;

D - множество логических данных; S - множество узлов.

Эта классификация характеризует любую систему обработки транзакций, от простейших (P1, M1, H1, D1, S1) до более сложных многоузловых неоднородных окружений с поддержкой разнотипных наборов данных (Pn, Mn, Hn, Dn, Sn). В статье, написанной в 1991 г., эти авторы представили трехмерную классификацию, которую они применили для оценки различных исследовательских и коммерческих систем.

Заключение

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

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

Литература

1.  Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. 2-е издание, дополненное и переработанное. СПб.: КОРОНА принт, 2006. 672 с.

2.  Конноли, Томас, Бегг, Каролин. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. 3-е издание. : пер. с англ. – М. : издательский дом «Вильяме», 2003. – 1440 с. ил. – Парал. тит. англ.