Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 34

2.  Ввод неправильных данных при использовании DML-операторов и хранимых процедур. Для того чтобы исключить возможность сохранения заведомо некорректных значений в БД при выполнении операторов DML, используются объекты-ограничения: базовые ОЦ и триггеры.

5.1. Управление транзакциями

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

Обработка транзакций, состояние данных во время ее работы и после завершения должны соответствовать требованиям ACID (Atomicity, Consistency, Isolation and Durability):

·  Атомарность (Atomicity). Все команды, выполненные в транзакции, рассматриваются как единый минимальный блок. При условии, что все команды отработали удачно, сделанные ими изменения фиксируются в БД после завершения транзакции. Иначе данные восстанавливаются в том состоянии, которое было до начала транзакции. Говорят, что в первом случае происходит фиксация транзакции, а во втором – откат транзакции.

·  Согласованность (Consistency). Каждая транзакция должна переводить БД из одного согласованного состояния в другое согласованное состояние. В частности, к моменту фиксации все данные должны удовлетворять существующим в БД ограничениям целостности.

·  Изолированность (Isolation). Если одна транзакция выполняет изменение данных в БД, то результат этих изменений не должен сказываться на работе других транзакций до тех пор, пока данная транзакция не будет зафиксирована или отменена.

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

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

1. BEGIN TRAN

Обозначает начало новой транзакции.

2. COMMIT [TRAN]

Завершает транзакцию, фиксируя все внесенные изменения.

3. ROLLBACK [TRAN]

Выполняет откат транзакции. После отката транзакция завершается.

4. SAVE TRAN

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

Упрощенный синтаксис команды SAVE TRAN имеет вид:

SAVE TRAN имя_точки_сохранения

Чтобы вернуть транзакцию в состояние, которое было на момент создания точки сохранения, используется команда ROLLBACK TRAN с указанием имени точки сохранения.

5.2. Управление параллельностью работы транзакций

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

1. Проблема последнего изменения.

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

2. Чтение после записи («грязное» чтение).

Возникает, когда одна транзакция выполняет модификацию данных, а другая в это же время пытается их считать и использовать в своих вычислениях. Проблема состоит в том, что вторая транзакция считывает результаты нефиксированных изменений, которые через некоторое время могут быть отменены. Проиллюстрируем данную ситуацию следующим примером (табл. 5.1): транзакция T2 считывает значение поля «счет», модифицированное, но не зафиксированное транзакцией T1 (200 рублей). Через некоторое время T1 отменяется, но T2, несмотря на это, продолжает использовать неправильное значение для своих вычислений. В результате поле «счет» принимает значение 190, которое, по всей видимости, является неверным.