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

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

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

{ SI SNAME STATUS CITY

{ SI SNAME STATUS CITY

SI ( SI )

NAME ( Smith ) ,

London }

SI ( S6 )

NAME ( Smith ) ,

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 { S# } ) )

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

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

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

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

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

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

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

8.7. Ограничения состояния и ограничения перехода

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

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

никогда не состоял в браке - состоит в браке;

состоит в браке - овдовел;

состоит в браке - разведен;

разведен - состоит в браке.

Среди недопустимых типов переходов можно назвать такие:

никогда не состоял в браке - овдовел;

никогда не состоял в браке - разведен;

овдовел - разведен;

разведен - овдовел.

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

CONSTRAINT TRC1 IS EMPTY

( ( ( S { S#, STATUS } RENAME STATUS AS STATUS ) JOIN S { S#, STATUS } ) WHERE STATUS > STATUS ) ;

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

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

CONSTRAINT TRC2 IS EMPTY

{ { ( SUMMARIZE SP PER S { S# } ADD SUM ( QTY ) AS SQ ) JOIN

( SUMMARIZE SP PER S { S# } ADD SUM ( QTY ) AS SQ ) ) WHERE SQ > SQ ) ;