Некоторые выводы:
Неявно заданныйоператор ROLLBACK. В данном примере явно предусмотрено выполнение проверок на наличие ошибок и явный вызов на выполнениеоператора ROLLBACKв случае обнаружения ошибки. Но не следует предполагать (и само это предположение не имеет смысла), что транзакции всегда включают явно заданные проверки на случай всех возможных ошибок. Поэтому система должна вызывать на выполнение неявно заданныйоператор ROLLBACKДЛЯ всех транзакций, которые по какой-то причине окончились неудачей и не достигли этапа планового за вершения (здесь под тоновым завершением подразумевается явно заданный опера тор COMMIT РИГИ ROLLBACK).
Обработка сообщений. Типичная транзакция не только вносит (или пытается внести) обновления в базу данных, но и передает конечному пользователю те или иные сообщения, позволяющие ему узнать, что происходит. Например, можно предусмотреть передачу сообщения "Перевод денег со счета на счет выполнен", если достигнутоператор COMMIT, или сообщение "Ошибка — перевод денег со счета на счет не выполнен" в противном случае. Обработка сообщений, в свою очередь, требует применения дополнительных средств восстановления.
Журнал восстановления. На первый взгляд не всегда очевидно, как можно обеспечить отмену обновления. Ответ на этот вопрос состоит в том, что в системе ведется журнал на ленте или (чаще всего) на диске, в котором регистрируются подробные сведения обо всех обновлениях, в частности, значения обновляемых объектов (например кортежей) до и после каждого обновления, иногда называемые образами данных до и после обновления. Поэтому, если возникает необходимость отменить некоторые конкретные обновления, система использует соответствующую запись журнала для восстановления предыдущего значения обновленного объекта.
Примечание.В действительности это описание слишком упрощено. На практике журнал состоит из двух частей — активной (или оперативной) части и архивной (или автономной) части. Оперативной называется та часть журнала, которая используется в процессе текущей эксплуатации системы для регистрации подробных сведений об обновлениях по мере их выполнения, и обычно хранится на диске. После заполнения пространства памяти, отведенного для оперативной части журнала, ее содержимое передается в автономную часть, которая теперь может быть записана на ленту (поскольку всегда обрабатывается последовательно).
Неразрывность операций. Система должна гарантировать, что выполнение отдельных операций (весь процесс их выполнения) должно происходить неразрывно. Такое требование становится особенно важным в реляционных системах, по скольку в них операции выполняются на уровне множества и обычно затрагивают одновременно большое количество кортежей, поэтому нельзя допустить, чтобы такие операции оканчивались неудачей в ходе выполнения и оставляли базу данных в противоречивом состоянии (например, в таком состоянии, что некоторые кортежи обновлены, а другие — нет). Иными словами, если в ходе выполнения подобного оператора возникла ошибка, то база данных должна остаться полностью в неизменном состоянии. Кроме того, как описано в главах 9 и 10, это условие остается в силе, даже если рассматриваемая операция неявно требует выполнения дополнительных обновлений (например, из-за того, что применяется правило каскадного удаления или происходит обновление представления, в котором предусмотрено соединение таблиц).
Выполнение программы как последовательности транзакций. Необходимо обратить особое внимание на то, что операторыCOMMITИROLLBACKзавершают транзакцию, а не прикладную программу.
Отсутствие вложенных транзакций. Если явно не указано иное, то в данной главе предполагается, что в прикладной программеоператор BEGIN TRANSACTIONможет быть вызван на выполнение, только если в настоящее время в этой программе не выполняется какая-либо другая транзакция. Иными словами, транзакция не может содержать в себе вложенную транзакцию. Но необходимо отметить, что в следующей главе это предположение будет пересмотрено.
Допустимость. По определению база данных должна всегда находиться, по меньшей мере, в непротиворечивом состоянии. Под понятием непротиворечивости, согласно главе 9 (а также общепринятому толкованию этого термина), мы подразумеваем отсутствие нарушений каких-либо известных ограничений целостности. Следует также отметить, что непротиворечивость базы данных, рассматриваемая с точки зрения такого определения данного термина, обеспечивается средствами самой СУБД. Из этого следует (также по определению), что транзакции всегда переводят базу данных из одного непротиворечивого состояния в другое. Но одной непротиворечивости недостаточно; база данных должна отвечать требованиям допустимости, а не только непротиворечивости! Например, в случае транзакции, требуется, чтобы суммарное количество денег на счетах 123 и 456 в результате транзакции не изменилось. Но было бы неразумно ставить перед собой задачу по подготовке ограничения целостности, которое соответствовало бы такому требованию (объясните, почему), и поэтому нельзя рассчитывать на то, что СУБД сможет следить за соблюдением данного требования. В действительности, непротиворечивость не подразумевает правильность. Поэтому, к сожалению, все, что мы можем сделать (и чего мы вообще можем добиться с помощью СУБД), это просто принять предположение, что транзакции являются правильными, в том смысле, что они достоверно отражают лишь те операции реального мира, которые были реализованы с их помощью. Точнее, мы предполагаем, что если т — транзакция, которая переводит базу данных из состояния Б1 в состояние Б2 и состояние Б1 является правильным, то Б2 также является правильным2. Но еще раз отметим, что это желаемое свойство не может быть обеспечено самой системой.
Множественное присваивание. В базе данных необходимо предусмотреть поддержку множественной формы присваивания, которая позволяет выполнять одновременно любое количество отдельных операций присваивания (т.е. обновлений). Например, две отдельные операции UPDATE, могут быть заменены следующим одним оператором (обратите внимание на применяемый в нем разделитель в виде запятой).
UPDATE ACC 123 { BALANCE := BALANCE - $100 } , UPDATE ACC 456 { BALANCE := BALANCE + $100 } ; Теперь эта транзакция будет включать только одну операцию обновления, поэтому ее воздействие на базу данных будет неразрывным по определению и операторы BEGIN TRANSACTION, COMMIT И ROLLBACK больше не потребуются (ПО крайней мере, В ДЭННОМ конкретном случае). Современные программные продукты не поддерживают множественное присваивание (или поддерживают эту операцию не полностью). Поэтому по практическим соображениям до конца данной главы возможность применения множественного присваивания не рассматривается. (Безусловно, при проведении оригинальной исследовательской работы, посвященной транзакциям, возможность применения множественного присваивания фактически даже не рассматривалась.