Обработка с помощью транзакций

Служебная информация

Журнальная информация

Хеширование

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

Функция перевода по ключу – хэш-функция.

Ключ ® А хранения

Ключи 1 ¸ 1000

1 ® 0001

600 ® 0600

1000 ® 1000

при таком хранении ключей требуется много памяти:

ключи: 20, 20, 444, 981; память: 20 ¸ 981

Поэтому, как правило ХЭШ (свёртка) выдаёт значение, когда нескольким ключам соответствует один А хранения. Тогда вычисляется: А = hash (ключ). По этому А проверяется наличие какой-либо цифры, если она есть, то организуется список (ключей) информации, если нет, то сохраняется исходное значение.

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

Служебная информация необходима для корректной работы с внешней памятью. В число файлов служебной информации входят:

– внутренние каталоги, которые описывают свойства объектов БД;

– описатели свободной и занятой памяти в терминах страницы;

– информация, которая связывает страницы одного отношения (если в одном файле внешней памяти располагается несколько отношений, то страницы каждого отношения должны быть связаны между собой).

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

На основе транзакций строится безопасная работа, а также обеспечивается изолированность пользователей.

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

Т: а₁, а₂, …, а_n; Commit (зафиксировать во внешней памяти); – транзакция закончена;

Т: а₁, а₂, …, а_n; Rollback (все действия отменяются);

Рассмотрим следующие проблемы:

1. целостности данных в БД: транзакции появились в ответ на ограничения целостности.

СОТРУДНИКИ (СОТР_ИМЯ, СОТР_ОТД, …)

ОТДЕЛЫ (ОТД_№, ОТД_НАЧ, ОТД_ КОЛ, …)

При изменении числа сотрудников будет нарушаться условие целостности: число кортежей = значению атрибута. Чтобы не нарушать ограничение целостности надо ввести транзакцию: Т(добавление в СОТРУДНИКИ; модификация атрибута в ОТДЕЛЫ; COMMIT). Для поддержания ограничений целостности можно допустить нарушение их в ходе транзакций, но в конце транзакции Commit должен проверить все отложенные ограничения.

Ограничения целостности можно разделить на 2 группы:

А) откладываемые;

Б) неотложные (которые прямо препятствуют выполнению операций), связанные с типом и значением.

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

2. изолированность пользователей необходимо в многопользовательских системах. Главная задача изолированности пользователей – создать у каждого пользователя иллюзию, что он работает с БД в одиночку. Изолированная работа означает, что пользователь не видит нарушения данных, связанных с работой других пользователей.

Уровни изолированности:

I. обеспечивает отсутствие потерянных изменений;

II. отсутствие чтения “грязных данных”;

III. отсутствие неповторяющихся чтение.

Рассмотрим I.

Т1 модифицирует объект А БД. После окончания Т1 – А’ (модифицированный). Если во время Т1 выполняется Т2, который тоже модифицирует объект, а по окончании Т2 Rollback (откат), то произойдёт восстановление А, т.е. потаря изменения Т1 (А ® А’).

Рассмотрим II.

Т1 изменяет объект А и параллельно с этим Т2 читает объект А. Т.к. Т1 ещё не завершена, то Т2 видит объект А в несогласованном (“грязном”) состоянии. Чтобы этого избежать, необходимо, чтобы до завершения модификации никакая транзакция на имела право читать объект.

Рассмотрим III.

Вторая операция чтения даёт неповторяющиеся данные, т.к. Т2 закончилась commit. Чтобы этого избежать: до завершения Т1 никакая другая транзакция не должна изменять объект А.

Итак, чтобы избежать I, необходимо запретить модификацию, если объект начал модифицироваться другими транзакциями – это минимальное требование для независимости параллельно выполняемых транзакций. Если рассмотреть III, то можно сказать, что условие запрещения модификаций является максимальным требованием. II является промежуточным.

Требование I-го уровня является достаточным для поддержания целостности в простых системах. Чем сложнее связи между данными, тем выше должны быть соблюдаемые условия.

При выполнении всех условий теряется выгода от параллельного использования транзакций. Поэтому запрещать целиком выполнение транзакций – это неэффективное решение.

Параллелизм выполнения транзакций описывается термином: сериализация транзакций.

Дата добавления: 2014-12-25