А.3.2.3.1.3. Транзакции баз данных

Обновление баз данных основано на концепции транзакций, свойства которых описываются термином ACID (A - атомарность, С - согласованность, I - изолированность, D - долговечность). Транзакции включают серию операций базы данных, которая — с точки зрения приложения — не должна прерываться. Это означает, что с точки зрения приложений согласование базы данных производится лишь в том случае, если транзакция доведена до конца. В случае же ошибки выполняется «откат», т.е. данные возвращаются в состояние, предшествовавшее транзакции. Это свойство транзакций называется атомарностью. База данных обновляется лишь при условии успешного завершения транзакции.

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

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

Транзакции характеризуются понятиями «начало транзакции» и «конец транзакции». В рамках этих двух этапов может заключаться любое число команд записи в файл или чтения. Транзакции также используются в качестве единиц для измерения числа этапов восстановления данных.

С точки зрения проектирования программ, транзакции могут интерпретироваться как модули, поэтому на рис. 123 мы вводим ТРАНЗАКЦИИ как конкретизацию понятия МОДУЛЬ. На стадии спецификации проекта мы говорили, что модули можно связывать друг с другом в сети. Та же ситуация и здесь.

Рис. 123. Концепция транзакций

Несколько операций базы данных группируются в одну транзакцию, в результате чего ОПЕРАЦИЯ БАЗЫ ДАННЫХ (БД) превращается в ассоциацию между ТИПОМ ОПЕРАЦИИ БД (как в процессе чтения или записи в файл), соответствующей ТРАНЗАКЦИЕЙ и упоминавшимся ранее ИНФОРМАЦИОННЫМ ОБЪЕКТОМ.

А.3.2.3.2. Управление посредством триггеров

Базы данных являются не только средством для пассивного хранения корпоративных данных. К ним также подсоединяются компоненты, реагирующие на определенные события и действия, связанные с приложениями. Эти компоненты инициируют обновление базы данных (активные системы баз данных) и называются триггерами. Понятие «триггер» мы ввели в разделе А.2.3.3.3, когда рассматривали условия целостности при спецификации проекта на уровне модели данных.

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

Говоря кратко, триггеры состоят из описания инициирующих событий, контролируемых условий и действий, инициируемых в случае, если эти условия удовлетворяются. Действия представляют собой операции (т.е. транзакции) обновления данных. Более точно, в соответствии с механизмом событие/триггер (ЕТМ) (Kotz. Triggermechanismus in Datenbanksystemen. 1989, с. 54) триггером называется пара действий, состоящая из результата и собственно действия {Т = (Е,А)}. Таким образом, действие А выполняется, как только происходит событие типа Е.

Например, если в процессе разработки продукта по завершении этапа «фаза проектирования 1» запускается процедура проверки результата, то триггер будет выглядеть следующим образом:

EVENT end_of_design_phase_l (design object: DB_ID);

ACTION verification_procedure_A (verif_obj: DB_ID)

=<Verification of verif_obj>;

TRIGGER Tl =

ON end_of_design_phase_l

DO verification_procedure_A (design_object);

(Kotz. Triggermechanismus in Datenbanksystemen. 1989, c. 64).

Здесь к событиям и действиям привязываются идентификаторы различных обрабатываемых объектов. В данном примере проектируемый объект именуется design_object (с идентификатором базы данных DB_ID), а объект, подлежащий проверке действием, именуется verification_object (с идентификатором базы данных DB_ID).

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

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

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

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

На рис. 124 концепция триггеров представлена в виде метамодели, где класс СОБЫТИЕ является связующим звеном с уровнем определения требований.

Рис. 124. Структура концепции триггеров

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

После инициации того или иного триггера различные состояния базы данных могут проверяться в соответствии с правилами, описанными для триггеров. На это указывает ассоциация УСЛОВИЯ, связывающая ТРИГГЕР с ИНФОРМАЦИОННЫМ ОБЪЕКТОМ.

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