Замечания по поводу Tutorial D
Позвольте мне ненадолго сконцентрироваться на Tutorial D. Можно было бы подумать, что следующая конструкция является формулировкой парадокса Эпименида в терминах Tutorial D (и в этом случае решить, что проблема кроется именно в этом языке):
VAR R { } KEY { } ;
CONSTRAINT EPIMENIDES COUNT ( R ) = 0 ;
Более конкретно, можно было бы подумать, что ограничение EPIMENIDES является формальным выражением предиката P («Отсутствуют истинные инстанциации предиката P», или, эквивалентно, «Число истинных инстанциаций предиката P равняется нулю»). Но это не так. И причина состоит не в том, что к ограничениям не применима гипотеза о замкнутом мире. В гипотезе о замкнутости мира (говоря вольно) утверждается, что relvar R в данный момент времени должна содержать те и только те кортежи, которые в этот момент удовлетворяют предикату переменной R. Но в Tutorial D не поддерживается и не может поддерживаться знание предикатов relvar; в этом языке могут быть известны только ограничения relvar. И нет – и не может быть – такого требования, что relvar R в данный момент времени содержит те и только те кортежи, которые удовлетворяют в этот момент ограничениям, применимым к R. Так что тот факт (в примере), что relvar R всегда является пустой, сам по себе не приводит ни к какому парадоксу.
Попробуем подойти по-другому. Вот еще одна попытка сформулировать парадокс Эпименида в терминах Tutorial D:
VAR R { } KEY { } ;
CONSTRAINT EPIMENIDES
IF COUNT ( R ) = 1 THEN COUNT ( R ) = 0 AND
IF COUNT ( R ) = 0 THEN COUNT ( R ) = 1 ;
Здесь ограничение EPIMENIDES логически эквивалентно следующему:
Если в relvar R существует кортеж, то relvar R должна быть пустой, а если relvar R является пустой, то в ней должен существовать кортеж.
Другими словами, это ограничение является противоречием. (Заметьте, пожалуйста, что я использую здесь термин противоречие в его формальном логическом смысле, имея в виду предикат, любой вызов которого гарантированно приводит к результату FALSE вне зависимости от того, какие аргументы поставлены в соответствие его параметрам.) Но если ограничение является противоречием, то, прежде всего, отсутствует – или, по крайней мере, должна отсутствовать – какая-либо возможность добавления его к системе! Более точно, если какой-либо пользователь пытается определить некоторое новое ограничение для некоторой базы данных, то система, прежде всего, должна проверить, что база данных в настоящее время удовлетворяет этому ограничению.
Если эта проверка не удается, то ограничение, очевидно, должно быть отброшено; и если это ограничение является противоречием, то база данных ни коем образом не может удовлетворять ему в настоящее время.
Конечно, здесь я в целях обсуждения предполагаю, что система действительно может обнаружить тот факт, что база данных не удовлетворяет некоторому предлагаемому ограничению. В сопутствующей статье [1] обсуждается, что происходит при недействительности этого предположения. Однако для полноты я привожу здесь краткий набросок того, что должно происходить в правильно организованной системе, когда некоторый пользователь пытается определить некоторое новое ограничение базы данных DC:
