BEGIN TRANSACTION ; /* Перевести $$$ со счета А на счет В */

UPDATE account А ; /* Снятие денег со счета А */

UPDATE account В ; /* Помещение денег на счет В */

IF <Все выполнено успешно

THEN COMMIT ; /* Нормальное завершение */

ELSE ROLLBACK ; /* Аварийное завершение */

END IF ;

Отметим некоторые свойства транзакций.

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

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

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

3. Для транзакций также гарантируется изолированность одной транзакции от другой. Под этим подразумевается, что изменения в базе данных, выполненные некоторой транзакцией Т1, не будут видимы для любой транзакции 77 до тех пор, пока и только пока транзакцией Т] не будет успешно выполнена операция COMMIT. После выполнения операции COMMIT изменения, которые были лроизве-дены некоторой транзакцией, становятся видимыми для других транзакций. О таких изменениях говорят, что они зафиксированы, и гарантируется, что они никогда не будут отменены. Если же, напротив, транзакцией была выполнена операция ROLLBACK, все изменения, которые были внесены в базу данных в процессе выполнения этой транзакции, будут отменены (выполнен откат изменений). В последнем случае конечный результат будет таким, как если бы данная транзакция вообше не выполнялась.

4. При параллельном выполнении нескольких транзакций, операции которых чередуются между собой, обычно гарантируется, что осушествление этих операций будет упорядоченным (serializable). Иначе говоря, результат выполнения каждой из транзакций будет точно таким же, как при строго последовательном выполнении этих же транзакций в некотором произвольном порядке.

Развернутое обсуждение всех остальных аспектов данной темы будет продолжено в главах 14 и 15.

3.9. База данных поставщиков и деталей

На протяжении почти всей этой книги используется пример, названный нами базой данных поставщиков и деталей (поддерживаемой, как уже упоминалось в главе 1, вымышленной компанией KnowWare, Inc.). Назначение настоящего раздела- позна-

комить читателя с этой базой данных, которая будет служить примером для ссылок в последующих главах. На рис. 3.8 показано множество значений ее данных. Именно эти конкретные значения будут фактически использоваться в дальнейшем (где это имеет смысл). На рис. 3.9 показано определение базы данных, для которого снова используется (несколько измененный) язык Tutorial D. В частности, обратите внимание на спецификации первичных и внешних ключей. Кроме того, обратите внимание на то, что несколько столбцов имеют типы данных, которым присвоено название, аналогичное названию соответствующего столбца. Столбцы STATUS и CITY определены как имеющие не пользовательский, а встроенный тип данных- INTEGER (целое) и CHAR (строка символов произвольной длины) соответственно. Наконец, необходимо отметить, что в отношении значений, показанных в столбцах на рис. 3.8, должно быть сделано одно важное замечание, однако мы еще не готовы к этому. Поэтому обсуждение упомянутого замечания будет отложено до главы 5, точнее - до подраздела Внутренний уровень в разделе 5.2.

Рис. 3.8. База данных поставщиков и деталей (пример значений) В базе данных предполагается следующая семантика.

Переменная-отношение S представляет поставщиков. Каждый поставщик имеет уникальный номер (Si); имя (SNAME), необязательно уникальное (хотя оно может быть уникальным, как в случае, представленном на рис. 3.8); значение рейтинга или статуса (STATUS); место расположения (CITY). Предполагается, что каждый поставщик находится только в одном городе.

Переменная-отношение Р представляет детали (точнее, виды деталей). У каждого вида детали есть номер детали (Pi), который является уникальным; название детали (PNAME); цвет (COLOR); вес (WEIGHT); город, где хранится этот вид деталей (CITY). Предполагается (где это имеет значение), что вес детали приведен в фунтах. Также предполагается, что каждый отдельный вид детали имеет только один цвет и хранится на складе только в одном городе.

Переменная-отношение SP представляет поставки. Она в известном смысле служит для организации логической связи двух других переменных-отношений. Например, первая строка переменной-отношения SP на рис. 3.8 связывает поставщика с номером S1 из переменной-отношения S с соответствующей деталью, имеющей номер Р1 в переменной-отношении Р, т.е. представляет факт поставки деталей типа Р1 поставщиком с номером S1 (а также указывает количество деталей - 300 штук). Таким образом, каждая поставка характеризуется номером поставщика (SI), номером детали (Р) и количеством (QTY). Предполагается, что в одно и то же время может быть не более одной поставки для одного поставщика и одной детали, поэтому для каждой поставки комбинация значений столбцов St и Р уникальна с точки зрения набора текущих поставок, представленных в переменной-отношении SP.

Замечание. На рис. 3.8 умышленно показано одно значение поставщика (с номером S5), для которого не существует ни одной поставки.

TYPE SI ... ; TYPE NAME ... ; TYPE PI ... ; TYPE COLOR ... ; TYPE WEIGHT ... ; TYPE QTY ... ;

VAR S BASE RELATION { SI SI,

SNAME NAME,

STATUS INTEGER,

CITY CHAR } PRIMARY KEY { Si } ;

VAR P BASE RELATION { PI PI,

PNAME NAME,

COLOR COLOR,

WEIGHT WEIGHT,

CITY CHAR } PRIMARY KEY { PI } ;

VAR SP BASE RELATION { SI SI,

PI PI,

QTY QTY }

PRIMARY KEY { Si, PI }

FOREIGN KEY { SI } REFERENCES S

FOREIGN KEY { PI } REFERENCES P

Puc. 3.9. База данных поставщиков и деталей (определение данных)