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

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

Таблица 5.5 – Алгоритмы предупреждения тупиковых ситуаций

Выявление тупиковых ситуаций

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

Взаимная блокировка имеет место в том случае, если в графе ожиданий имеется цикл (рис. 5.1).

Рисунок 5.1 – Графическое изображение взаимной блокировки

5.3. Реализация требований целостности в базах данных

5.3.1. Общие сведения о требованиях целостности

В главе 1 говорилось о том, что любая предметная область включает в себя множество ограничений. Каждое ограничение представляет собой либо простое условие, при помощи которого задается множество допустимых значений некоторого атрибута, либо правило логического согласования значений нескольких атрибутов разных сущностей и (или) связей. Ограничения предметной области находят отражение в требованиях целостности, которые формулирует и предъявляет заказчик АИС; задача разработчика – реализовать программные механизмы поддержки этих требований.

Приведем конкретные примеры требований целостности. Известно, что масса перевозимого груза по определению не может быть отрицательной. Это означает, что предметная область накладывает ограничение на атрибут «масса» сущности ГРУЗ: его значение должно быть больше либо равно нулю. Известно также, что у нескольких человек не может быть одинаковых ИНН. Следовательно, для предметных областей, связанных с обработкой ИНН, существует ограничение: ИНН должен быть уникальным для каждого сотрудника. Можно привести и более сложный пример – на согласование атрибутов разных сущностей. Рассмотрим предметную область: пассажирские перевозки. В ней можно выделить следующее ограничение: номер места в купейном вагоне не должен превышать значение 36 (так как в купейном вагоне 36 мест). ВАГОН и МЕСТО - разные, хотя и взаимосвязанные, сущности. Тем не менее, существует ограничение, которое согласовывает значения атрибутов обеих сущностей: тип вагона (атрибут сущности ВАГОН) и номер места (атрибут сущности МЕСТО).

АИС должна выполнять автоматическую проверку данных на соответствие требованиям целостности. Если во время ввода или обработки данных появляются недопустимые значения или комбинации значений, АИС должна либо автоматически исправлять их, либо – при невозможности автокоррекции – запрещать выполнение самой операции, приводящей к возникновению ошибки. От разработчика требуется реализация соответствующих программных механизмов автоматического контроля целостности в АИС. К таким механизмам относятся ограничения целостности и триггеры, упоминавшиеся в одной из предыдущих глав под общим названием объекты-ограничения баз данных. Речь о них пойдет несколько позже, после того, как будут рассмотрены основные вопросы, связанные с выявлением и способами описания требований целостности.