Наглядным примером АС, в которой над БД требуется параллельно выполнять целый ряд процессов обработки, являются системы продажи авиа- или железнодорожных билетов.
В этих системах к БД имеют одновременный доступ большое количество операторов, работающих в различных транспортных агентствах, но выполняющих одни и те же функции по продаже билетов пассажирам, и, причем, выполняют они свои функции, используя одну и ту же БД, общую для всех операторов. Так как оператор не только читает данные из базы (поиск свободных мест на требуемые рейсы), но и вносит изменения в базу (отмечает проданные места, возвращаемые билеты), то необходимо принять специальные меры, регулирующие доступ к БД, чтобы исключить возможность продажи билетов на одно и то же место нескольким пассажирам.
Если выполняется только операция чтения данных из базы и в этот период нет операций записи, то нарушения целостности данных при параллельной обработке не происходит.
Однако как только пользователи получают возможность выполнять операции изменения одних и тех же данных в базе, то ситуация резко изменяется. Вернемся снова к системе продажи билетов. Например, три различных оператора, находясь в различных транспортных агентствах города, одновременно запросили один билет до Санкт-Петербурга на 1 августа в поезде № 2, в купированном вагоне. Как в таком случае говорят, будет независимо друг от друга выполнено три процесса, или три транзакции. Под транзакцией в данном случае понимается разовое выполнение некоторой программы.
Чтобы устранить нарушения ограничений целостности данных, необходимо разграничить доступ транзакций к базе. Решить задачу можно введением блокировок доступа к данным.
Для реализации механизма блокировок БД разбивается структурно на элементы, которые можно блокировать. Выбор характера и размера элементов, подлежащих блокированию, выполняется исходя из специфики решаемых системой функциональных (прикладных) задач. При этом следует помнить, что выбор больших по размеру элементов, подлежащих блокированию (например, в реляционной базе данных-отношений), приводит к снижению накладных расходов системы по поддержанию блокировок, однако снижает также и возможности параллельного исполнения процессов. С другой стороны, выбор малых по размеру элементов, подлежащих блокированию (например, кортежи или даже компоненты кортежей отношений в реляционной БД), расширяет возможности системы с точки зрения параллельного исполнения транзакций, однако приводит к увеличению затрат ее ресурсов на поддержание блокировок.
Для поддержания механизма блокировок в состав СУБД вводится специальный функциональный программный модуль для управления блокировками. Этот модуль назначает (планирует) и регистрирует блокировки, выполняет собственно блокирование, решает конфликтные ситуации между двумя (и более) запросами на блокирование одних и тех же элементов.
Модели блокировок
Различают простую модель блокировки и модель с блокировками для чтения и записи. В простой модели не вводится различие блокировок для операции чтения или операции записи элемента X. В ней используются две команды:
УСТАНОВИТЬ БЛОКИРОВКУ X
и
СНЯТЬ БЛОКИРОВКУ X.
Установление блокировки предотвращает доступ к элементу X от других транзакций как по операции чтения, так и по операции записи до тех пор, пока этот элемент не будет разблокирован.
Модель с блокировками для чтения и записи. В данной модели проводится различие между видами доступа к элементу X:
доступ только для чтения;
доступ для чтения и записи.
Соответственно различают два типа команд блокировки.
1. Команда блокировки элемента X по записи. Транзакция, в которой требуется выполнить только чтение элемента X, осуществляет его блокировку по записи. Блокировка по записи запрещает любой другой транзакции выполнять запись нового значения элемента X, пока он не будет разблокирован. Блокировку элемента X по записи могут одновременно устанавливать несколько транзакций (т.е. допускается параллельная работа по чтению данных для нескольких транзакций).
2. Команда блокировки элемента X по чтению и записи. Эта команда соответствует команде блокировки в простой модели, т.е. предотвращается доступ к элементу X от других транзакций как по чтению, так и по записи. Если некоторая транзакция установила блокировку элемента X по чтению и
записи, то никакая другая транзакция не сможет его заблокировать ни по записи, ни по чтению.
Как блокировка по чтению, так и блокировка по чтению и записи, снимаются одной командой:
СНЯТЬ БЛОКИРОВКУ X.
В модели допускается ситуация, когда транзакция может вначале устанавливать блокировку элемента X по чтению, а затем блокировку элемента X по чтению и записи (в том случае, если возникает необходимость большего ограничения поведения других транзакций).