Пример 9.2

Ограничения баз данных

Ограничение БД – ограничение, устанавливающее взаимосвязь между различными переменными-отношениями.

CONSTRAINT DBC1

IS_EMPTY((S JOIN SP)

WHERE STATUS < 20 AND QTY > 500)

Смысл: «Поставщики со статусом, меньшим 20, не могут поставлять детали в количестве свыше 500 штук».

CONSTRAINT DBC2 SP {P#} = P{P#}

Смысл: «Каждая деталь должна быть поставлена хотя бы один раз»

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

Если во время выполнения оператора COMMIT будет обнаружено нарушение ограничения БД, то это вызовет откат данной транзакции.

9.6 «Золотое правило»

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

Предикат некоторой переменной-отношения является критерием приемлемости изменений для рассматриваемой переменной-отношения, т.е. он предписывает, будет ли допустима определенная операция (INSERT, DELETE, UPDATE) для переменной-отношения.

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

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

Итак, можем сделать вывод, что система «не знает и не понимает» предикат переменной-отношения полностью, однако ей известно достаточно хорошее приближение к этому предикату, а конкретнее – ей известны ограничения целостности, которые применимы к данным в БД. Следовательно, предикат переменной-отношения определяется как логическое умножение всех ограничений переменной-отношения, которые установлены для нее.

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

Тогда «золотое правило» можно сформулировать следующим образом:

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

Для всей базы данных также имеется связанный с ней предикат, предикат базы данных, который определяется как логическое умножение (логическая операция И) всех ограничений БД и всех ограничений переменных-отношений, которые установлены в ней. Другая формулировка «золотого правила» для БД:

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

Дата добавления: 2015-05-09