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

* Потеря изменений (lost updates) появляется, когда два пользователя просматривают один и тот же набор, и один пользователь выполняет изменения, за которыми сразу же следуют изменения другого пользователя, перекрывающие работу первого пользователя.

* "Грязное" чтение (dirty read) позволяет одному пользователю видеть изменения, которые у другого пользователя находятся в процессе выполнения, без гарантии того, что изменения другого пользователя являются окончательными.

* Невоспроизводимое чтение (non-reproducible-reads) позволяет одному пользователю непрерывно выбирать строки, которые другие пользователи изменяют или удаляют. Эта проблема зависит от среды. Например, финансовые процессы по концу месяца или инвентаризация будут ошибочными в этих условиях, поскольку приложению продажи билетов нужно содержать все пользовательские представления синхронизированными, чтобы исключить двойные заказы.

* Фантомные строки (phanthom rows) появляются, когда один пользователь может выбирать некоторые, но не все новые строки, введенные другими пользователями. Опять же, это может быть применимо в одних ситуациях, однако это будет искажать результаты некоторых процессов.

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

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

! ! !

ПРИМЕЧАНИЕ. Firebird не допускает "грязное" чтение. При некоторых условиях он специально позволяет невоспроизводимое чтение.

. ! .

Сейчас прошло уже более 20 лет с того времени, как два исследователя, Тэо Хедер (Theo Haerder) и Андреас Рютер (Andreas Reuter), опубликовали обзор, описывающий поддержание целостности базы данных в параллельно изменяемой среде. Они объединили требования в четыре правила, названные атомарность (atomicity), согласованность (consistency), изолированность (isolation) и устойчивость (durability) - аббревиатура ACID [87] . В течение последующих лет концепция ACID стала эталоном для реализации транзакций в системах баз данных.

Транзакция (называемая также единицей работы) описывается как множество действий, преобразующих данные. Чтобы быть "атомарной", транзакция должна быть реализована таким образом, чтобы обеспечить принцип "все или ничего, когда выполняются либо все операции, либо ни одна из них" [88] . Транзакция либо завершается полностью (подтверждается, commit), либо отменяется (откатывается, rollback).

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

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

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