8.6. "Золотое правило"

Замечание. Материал этого раздела имеет фундаментальное значение. Однако во­просы, которые здесь рассматриваются, на практике, к сожалению, не нашли ни ши­рокой поддержки, ни даже достаточного понимания, хотя, в принципе, они довольно простые. Предупреждение для читателя.

В разделе 3.4 главы 3 мы установили, что любое отношение имеет связанный с ним предикат, а кортежи этого отношения выражают истинные высказывания, по­рождаемые данным предикатом. В разделе 5.3 главы 5 упоминалось допущение замкнутости мира, согласно которому, если в определенном отношении не сущест­вует определенного кортежа, мы имеем право предположить, что соответствующее ему высказывание ложно.

Мы не подчеркивали этот факт прежде, но читателю должно быть понятно, что пере­менная-отношение тоже имеет предикат, а именно — предикат, который будет общим для всех возможных отношений, представляющих допустимые значения для данной пе­ременной-отношения. Например, рассмотрим переменную-отношение поставщиков S. Предикат для этой переменной-отношения можно сформулировать примерно так.

⁴ В действительности в [3.3] предлагается множественная форма присвоения, которая по­зволила бы вставлять детали и поставки в пределах одной операции. Если бы такие операции присвоения поддерживались системой, то ограничения базы данных могли бы контролироваться немедленно

Поставщик с данным номером поставщика (Si) имеет данное имя (SNAME), дан­ное значение статуса (STATUS) и размещается в данном городе (CITY), кроме того, в любой заданный момент никакие два поставщика не имеют одинаковых номеров поставщика.

Это утверждение и не точное, и не полное, но вполне приемлемое для наших целей.

Также должно быть понятно, что предикат данной переменной-отношения по свой сути является критерием приемлемости изменений для рассматриваемой переменной-отношения, т.е. он предписывает, будет ли допустима определенная операция INSERT, UPDATE или DELETE для данной переменной-отношения. Например, попытка вставить све­дения о новом поставщике с тем же номером поставщика, что и номер уже существую­щего поставщика, несомненно, должна быть отвергнута.

Следовательно, в идеальном случае СУБД должен быть известен и понятен предикат каждой переменной-отношения в базе данных, что позволит системе корректно обраба­тывать всевозможные попытки внесения изменений. Но такая цель, конечно, недости­жима. Например, не существует способа сформулировать для СУБД понятие о том, что определенный поставщик должен быть "в" определенном городе. Также неясно, каким образом СУБД может быть заранее известно, что предикат для переменной-отношения поставщиков является таким, что, например, первый из приведенных ниже кортежей бу­дет допустимым, а второй — нет.

{St : St ( 'SI' ) ,

SNAME : NAME ( 'Smith' ) ,

STATUS : 20 ,

CITY : 'London' }

{ St SNAME STATUS CITY

St ( 'S6' )

NAME ( 'Smith' ) ,

50

'Rome' }

Конечно, если пользователь предоставит последний кортеж для ввода в базу дан­ных, то все, что система сможет сделать, — это убедиться, что никаких нарушений из­вестных ей ограничений целостности нет. И, несомненно, система затем примет кор­теж для добавления в базу данных и в дальнейшем будет воспринимать его как ис­тинное высказывание.

Итак, можем сделать вывод, что система "не знает и не понимает" (и "не может знать и понимать") предикат переменной-отношения поставщиков на все 100%. Однако ей из­вестно достаточно хорошее приближение к этому предикату, а конкретнее — ей из­вестны ограничения целостности, которые применимы к записям о поставщиках. Следо­вательно, мы определяем предикат переменной-отношения для переменной-отношения поставщиков (или в общем случае для любой переменной-отношения) как ло­гическое умножение (логическая операция И) всех ограничений переменной-отношения, которые установлены для данной переменной-отношения. Например, предикат перемен­ной-отношения для переменной-отношения S выглядит примерно так.

( IS_EMPTY ( S WHERE STATUS < 1 OR STATUS > 100 ) ) AND

( IS EMPTY ( S WHERE CITY = 'London' AND STATUS Ф 20 ) ) AND

( COUNT ( S ) = COUNT ( S { St } ) )

(Кроме того, системе, конечно, известно, что атрибуты St, SNAME, STATUS и CITY должны иметь типы St, NAME, INTEGER и CHAR соответственно.)

Отметим, что реально существуют два предиката, связанных с любой данной пере­менной-отношением: неформальный, или внешний, предикат, который понятен поль­зователям, но непонятен системе, и формальный, или внутренний, который понятен и пользователям, и системе. Конечно, внутренним предикатом является именно тот пре­дикат, который мы подразумеваем под "предикатом переменной-отношения", и имен­но внутренний предикат система проверяет всякий раз, когда предпринимаются по­пытки изменить данную переменную-отношение. В дальнейшем под термином преди­кат (когда он используется в связи с переменной-отношением) мы будем подразуме­вать именно внутренний предикат, кроме случаев, когда явно будет указано противо­положное.

Исходя из предшествующих определений теперь можно сформулировать золотое правило (по крайней мере его первую версию).

Ни одна из операций изменения не имеет права переводить переменную-отношение в состояние, нарушающее ее собственный предикат.

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

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

Ни одна из операций изменения не имеет права переводить переменную-отношение в состояние, нарушающее ее собственный предикат. Аналогично ни одна из транзакций изменения не имеет права переводить базу данных в со­стояние, нарушающее ее собственный предикат.