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

Размещено на http://www.allbest.ru/

Содержание

Введение

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

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

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

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

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

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

3. Encina и DCE

4. X/Open DTP

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

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

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

8. Практическая часть

Заключение

Литература

транзакция атомарность монитор

Введение

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

Транзакционная система, OLTP (Online Transaction Processing), -- обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этомклиенту требуется от системы минимальное время отклика [1].

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

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

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

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

Основные функции и особенности транзакционных систем (на примере их использования для реализации банковских технологий) приведены в табл.1 [3].

Таблица 1 Основные функции и особенности транзакционных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из свойств ACID для субтранзакций выполняются свойства атомарности, согласованности и изолированности. Но поскольку COMMIT WORK для субтранзакции на самом деле не означает ее фиксации до фиксации всей транзакции, то свойство долговечности не выполняется, поэтому субтранзакции не эквивалентны плоским транзакциям.

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

Хотя можно представить себе приложения и системы, в которых многозвенные и вложенные транзакции были бы полезны, однако лишь в начале 90-х годов в коммерческих приложениях на смену плоским транзакциям начали приходить другие. Интересно, впрочем, отметить, что при изучении транзакций SQL можно обнаружить некоторые признаки "псевдовложенности", по крайней мере, в способах обработки операторов (это в настоящее время недоступно разработчикам приложений; однако принятый в настоящее время стандарт SQL3 содержит контрольные точки и, вероятно, в него войдут операторы управления многозвенными транзакциями).

На рис. 5 показано выполнение транзакции SQL. Каждый оператор внутри транзакции, которая представляет собой, например, последовательность операторов UPDATE и DELETE, может завершиться успешно или неуспешно. Даже если один или несколько операторов завершаются неудачей, транзакция в целом может продолжаться, если в ее логике для этих случаев явно не предусмотрено прерывание с откатом в начальное состояние. Все успешно завершившиеся до прерывания операторы (которые в этой модели можно представлять как субтранзакции) будут отменены, если происходит откат всей транзакции [5].

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

3. Encina и DCE

Монитор обработки транзакций Encina корпорации Transarc можно рассматривать как коммерческий продукт второго поколения, однако более развитый, отражающий новейшие достижения в этой области. Encina включает модель вложенных транзакций и расширяет возможности среды DCE (Distributed Computing Environment), предложенной организацией OSF (Open Software Foundation).

Прообразом Encina был прототип системы обработки транзакций Camelot, разработанный в университете Карнеги-Меллон в Питтсбурге. Технология, лежащая в основе Camelot, и применяемый в этой системе язык программирования Avalon описаны в работе Camelot and Avalon: A Distributed Transaction Processing Facility. Camelot считается "первой реализацией вложенных транзакций в системе обработки транзакций" (в отличие от псевдовложенности, которую мы обсуждали в предыдущем разделе, или от внутрисистемной вложенности, недоступной для

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

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

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

Encina включает язык разработки приложений Transactional C, содержащий набор макросов и библиотек для определения транзакций и управления ими. Ключевое слово TRANSACTION служит для определения транзакций верхнего уровня или вложенных. Функции, задаваемые при помощи ключевых слов ONABORT и ONCOMMIT, описывают действия, выполняемые при откате или, соответственно, фиксации транзакции любого уровня. Программа может вызвать ENCINA_ABORT_ALL, чтобы вызвать прерывание всей транзакции.

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

4. X/Open DTP

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

OSI-TP для сервисов обработки транзакций, 1992 г.;

OSI-CCR для фиксации, управления и восстановления, 1990г.

Стандарты OSI определяют форматы и протоколы, но не прикладные программные интерфейсы для стандартного протокола двухфазовой обработки транзакций (2PC), спроектированного как надстройка над стеком коммуникационных протоколов OSI [4].

Стандарт API разработан комитетом X/Open и получил название X/Open Distributed Transaction Processing (DTP) API. X/Open DTP позволяет менеджерам транзакций использовать комбинацию закрытых и OSI-TP-протоколов для внутренних и межоперабельных окружений соответственно. X/Open DTP - стандарт, находящийся в стадии начального развития и имеющий определенные противоречия. В частности, не очень хорошо согласуются две его цели: (1) определение среды монитора TP как стандартизированного окружения и (2) поддержка удаленных вызовов процедур транзакций (TRPC - Transactional Remote Procedure Calls) наряду с "равноправными" (peer-to-peer) моделями коммуникаций (по крайней мере в настоящее время модель X/Open DTP содержит оба подхода).

X/Open DTP поддерживает не только плоские транзакции, но также многозвенные и вложенные (в последней из этих моделей при прерывании одной из ветвей происходит прерывание всей транзакции в целом).

В стандартизированной распределенной среде TP для описания взаимодействий между компонентами применяется комбинация стандартных протоколов. Некоторые из них, например ROSE (Remote Operations Service), относятся к общему стеку протоколов OSI; другие являются специфическими для окружения X/Open DTP или OSI-TP.

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

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

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

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

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

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

S - множество узлов.

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

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

В разд. 4 была рассмотрена Encina - монитор транзакций корпорации Transarc - который включает множество библиотек и макросов, составляющих среду разработки Transactional C. Альтернативный способ задания директив обработки транзакций состоит в применении специального языка. В качестве примера рассмотрим язык InterBase Parallel Language (IPL), входящий в состав неоднородной распределенной cреды баз данных InterBase, которую мы обсуждали в гл. 6. IPL разработан с учетом поддержки высокой степени параллелизма и взаимодействия между субтранзакциями, принадлежащими общей глобальной транзакции. IPL предназначался для поддержки транзакций разных типов (т. е. смешанных транзакций), а также как системно-независимый декларативный язык, обеспечивающий прозрачность управления транзакциями.

Программа на IPL представляет собой блок, обрамленный ключевыми словами program - endprogram, и включает декларации записей и описания субтранзакций. Поскольку IPL постоянно развивается и в настоящее время в стадии исследований находится графический интерфейс, а также объектно-ориентированная версия этого языка, то за более полной информацией мы отсылаем читателя к материалам проекта InterBase, который ведется в Университете Пурдью [2].

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

Значение этих средств определяется отчасти тем, что они способствуют интеграции концептуального моделирования процессов и данных. Классические процедуры интеграции 1970-х годов ориентировались, например, на отображение диаграмм потоков данных (DFD - Data Flow Diagram), на сущности и атрибуты диаграмм сущность-связь (ERD - Entity-Relation Diagram). Объектно-ориентированное моделирование обеспечивает определение объектов вместе с присущими им операциями, но ни тот ни другой вид моделирования не содержит средств для описания семантики транзакций. Выработка языков описания транзакций по отношению к некоторой модели данных с последующим переносом языковых средств в среду, обеспечивающую графическое представление вложенных, многозвенных и других развитых моделей транзакций, даст в будущем значительное увеличение продуктивности и надежности проектирования систем обработки транзакций [5].

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

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

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

- Интеграция с дисциплиной потоков работ. Независимые средства моделирования и спецификации транзакций, отмеченные в предыдущем пункте, необходимо соединить с формирующейся в настоящее время дисциплиной потоков работ. Для описания потоков информации, которой обмениваются между собой пользователи, процессы, приложения, может применяться некоторый высокоуровневый язык или графическая система. При этом семантику транзакций можно было бы описывать непосредственно над спецификациями потоков работ, подобно тому как ее можно было бы задавать относительно некоторой семантической модели данных. Имея среду разработки, снабженную инструментами генерации систем, можно было бы генерировать окружения управления транзакциями (совместимые, по всей вероятности, с X/Open DTP) вместе с процедурами и представлениями данных, необходимыми для реализации комбинированной модели "потоки работ - транзакции - данные" [6].

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

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

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

- Масштабируемость. Архитектура обработки транзакций, оптимальная для 100 узлов, может оказаться неэффективной для среды из 1000 или 10 000 узлов. Мониторы TP следующего поколения должны обладать свойством масштабируемости с учетом переменного числа и объема различных ресурсов (возможно, за счет упоминавшихся выше средств поддержки расширяемости).

8. Практическая часть

Практической частью работы является создание транзакционной базы данных в пакете программ Microsoft Excel. Алгоритм создания изображен на рисунке 1.

Рис. 1 Алгоритм создания транзакционной базы данных

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

- данные по товару: идентификационный код, название, цена, количество на складе, количество на прилавке, остаток на конец дня, наличие на начало дня;

- данные по поставкам: дата поставки, данные о поставщике, сумма поставки, срок годности;

- данные по продажам: дата продажи, сумма продажи, количество продаж, номер кассы.

Эти данные связаны формулами между двумя таблицами. Пакет Excel не позволяет полностью автоматизировать учет данных, поэтому были автоматизированы только математические операции.

Заключение

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

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

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

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

Список литературы

1. Компания «Википедия» [Электронный ресурс] / Продукция компании. - Режим доступа: https://ru.wikipedia.org/wiki/, свободный. - Загл. с экрана.

2. Издательство «Открытые системы» [Электронный ресурс] / Продукция компании. - Режим доступа: http://www.osp.ru/dbms/1997/02/13031539/, свободный. - Загл. с экрана.

3. Компания «БИС» [Электронный ресурс] / Продукция компании. - Режим доступа: http://www.bis.ru/pr/pub_detail.php, свободный. - Загл. с экрана.

4. У. Дайял. Мониторы транзакций третьего поколения, 1993

5. Дж. Грей и A. Реутер. Транзакции: Лекции и практика. - Сан Франциско: Морган Кауфман, 1993.

6. A. Д. Вольф, Дж. Транскар. Монитор транзакций Encina. Ноябрь, 1992.

Размещено на Allbest.ru