Почему мы нуждаемся в relvar?
Как отмечалось в аннотации, термин relvar является сокращением для термина реляционная переменная (relation variable). Он был введен нами с Хью Дарвеном в [9], первым опубликованном варианте Третьего Манифеста. Кодд в своих первых статьях о реляционной модели [3-4] использовал вместо него термин изменяемое во времени отношение (time-varying relation), но «изменяемые во времени отношения» – это те же relvar под другим именем. Конечно, мы не утверждаем, что были первыми, кто установил наличие этого факта, но мы полагаем, что были первым, уделившими ему серьезное внимание. Замечание: В публикации [2], появившейся на несколько лет ранее Третьего Манифеста, также проводится явное различие между отношениями и relvar (в ней они называются таблицами и табличными переменными соответственно). Однако это было сделано только под непосредственным влиянием моих комментариев, сделанных по поводу раннего варианта работы, в котором такое различие не проводилось.
Далее, мы полагаем, что понятие relvar и родственное понятие реляционного присваивания являются существенными, если нам требуется возможность обновления базы данных. Заметим, что переменные и присваивания действуют рука об руку (невозможно иметь одно без другого) – наличие переменной означает возможность присваивания этой переменной, а наличие возможности присваивания чему-либо означает, что это «что-либо» является переменной. Заметим также, что «возможность присваивания» («assignable to») и возможность обновления («updatable») означают ровно одно и то же; следовательно, возражения против relvar являются возражениями против реляционного обновления (эквивалентно, возражения против реляционного обновления являются возражениями против relvar).
По-видимому, здесь требуется небольшое дополнительное пояснение. Большая часть людей, говоря про реляционное обновление вообще, вероятно, имеет в виду традиционные операции INSERT, DELETE и UPDATE, а не реляционное присваивание – в особенности, в связи с тем, что, в частности, в SQL не поддерживается реляционное присваивание, хотя, конечно, поддерживаются INSERT, DELETE и UPDATE.
Но, в конечном счете, оказывается, что INSERT, DELETE и UPDATE являются всего лишь сокращенными формами некоторых видов реляционного присваивания. Например, предположим, что имеется обычная база данных поставщиков и деталей (примерный набор значений см. на рис. 1). Тогда оператор INSERT языка Tutorial D
INSERT SP RELATION
{ TUPLE { S# S#('S3'), P# P#('P1'), QTY QTY(150) },
TUPLE { S# S#('S5'), P# P#('P1'), QTY QTY(500) } } ;
является сокращенной формой оператора присваивания
SP := ( SP ) UNION ( RELATION
{ TUPLE { S# S#('S3'), P# P#('P1'), QTY QTY(150) },
TUPLE { S# S#('S5'), P# P#('P1'), QTY QTY(500) } } ) ;
Аналогично, оператор DELETE языка Tutorial D
DELETE S WHERE CITY = 'Athens' ;
является сокращенной формой оператора присваивания
S := S WHERE NOT ( CITY = 'Athens' ) ;
Рис. 1. База данных поставщиков и деталей – примерные значения
И оператор UPDATE языка Tutorial D
UPDATE P WHERE CITY = 'London'
( WEIGHT := 2 * WEIGHT, CITY := 'Oslo' ) ;
(немного более хитрым образом) является сокращенной формой оператора присваивания
P := WITH ( P WHERE CITY = 'London' ) AS T1,
( EXTEND T1
ADD ( 2 * WEIGHT AS NW, 'Oslo' AS NC ) ) AS T2,
( T2 { ALL BUT WEIGHT, CITY } ) AS T3,
( T3 RENAME ( NW AS WEIGHT, NC AS CITY ) ) AS T4,
( P MINUS T1 ) AS T5 :
T5 UNION T4 ;
Поэтому должно быть понятно, что реляционное присваивание, по существу, является единственной требуемой операцией реляционного обновления. По этой причине далее в этой статье я сфокусируюсь именно на реляционном присваивании. Кроме того, далее в статье я буду использовать (a) неуточненный термин присваивание в смысле реляционного присваивания и (b) неуточненный термин отношение в смысле значения отношения (за исключением, возможно, цитат из работ других авторов).
