Здесь SX - переменная кортежа, которая изменяется на отношении поставшиков S.

По ходу отметим, что логическое выражение в офаничениях, представленных в виде выражений реляционного исчисления, должно быть закрытой формулой WFF (см. раздел 7.2 главы 7) и чаше всего будет иметь форму FORALL х(...). Следовательно, выражение в данном примере означает, что все значения статуса поставщиков должны находиться в указанном диапазоне. На практике, конечно, достаточно, чтобы система просто проверяла лишь вновь вводимые или обновляемые значения статуса поставщиков, а не все те значения, которые уже хранятся в базе данных.

После того как новое офаничение будет объявлено, необходимо, чтобы оно было проверено системой, т.е. нужно убедиться, что база данных в текущий момент удовлетворяет вновь установленному офаничению. Если это не так, новое ограничение отвергается; в противном случае оно принимается (т.е. сохраняется в каталоге) и с этого момента вступает в силу. Объявление в системе приведенного выше ограничения приведет к тому, что СУБД будет контролировать все операции, которые подразумевают вставку кортежа для нового поставщика или изменение статуса существующего поставщика.

Конечно, дополнительно требуется, чтобы существовала возможность отмены установленного ранее офаничения.

DROP CONSTRAINT <имя ограничения ; Например:

DROP CONSTRAINT SC3 ;

Замечание. Как вы, наверное, уже заметили, наше обсуждение сосредоточено на декларативной поддержке ограничений целостности. К сожалению, на сегодняшний день лишь немногие продукты предоставляют что-либо существенное в плане реализации такой поддержки, хотя ситуация в этом направлении пусть медленно, но все же улучшается. В некоторых продуктах (особенно в нереляционных) практикуется совсем другой подход, т.е. применяется процедурная поддержка ограничений целостности, построенная на использовании хранимых, или триггерных, процедуре. Однако можно предположить, что если бы существующие СУБД действительно предоставляли необходимую декларативную поддержку, то по крайней мере 90% текста определений типичной базы данных составляли бы объявления ограничений целостности данных. Таким образом, предоставляющая подобную поддержку система значительно облегчила бы труд прикладных программистов и позволила бы существенно повысить производительность их труда. Декларативная поддержка ограничений целостности является очень важным аспектом СУБД.

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

Хранимые, или триггерные, процедуры - это заранее скомпилированные процедуры, которые могут вызываться из прикладных программ. В качестве примера можно упомянуть определенные пользователем операторы ABS, DIST, REFLECT и т.д., которые рассматривались в разделе 5.2 (подраздел Объявление оператора ). Такие процедуры логически можно рассматривать как расширение СУБД (в системах клиент/сервер они чаще всего хранятся и выполняются на сервере). Мы еще поговорим об этих процедурах в разделе 8.8, в аннотациях к некоторым публикациям в конце данной главы, а также в главе 20.

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

Схема классификации ограничений

в [3.3] ограничения целостности классифицируются по четырем основным категориям: ограничения типа (домена), атрибута, переменной-отношения и базы данных.

В ограничениях типа задаются допустимые значения для данного типа.

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

В офаничениях целостности атрибута задаются допустимые значения для данного атрибута.

В Офаничениях целостности переменной-отношения задаются допустимые значения для данной переменной-отношения.

В Офаничениях целостности базы данных задаются допустимые значения для этой базы данных.

Подробнее указанные виды офаничений рассматриваются в разделах 8.2-8.5 соответственно.

8.2. Ограничения типа

По существу, ограничение типа является перечнем (или логическим эквивалентом перечня) допустимых значений типа. Вот простой пример офаничения типа для типа WEIGHT (Вес).

TYPE WEIGHT POSSREP ( RATIONAL )

CONSTRAINT THE WEIGHT ( WEIGHT ) > 0.0 ;

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

Замечание. Если вам необходимо восстановить в памяти назначение операторов POSSREP и ТНЕ , возвратитесь к главе 5.

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

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

Вот еще один пример офаничения типа.

TYPE POINT POSSREP CARTESIAN ( X RATIONAL, Y RATIONAL ) CONSTRAINT ABS ( THE X (POINT) ) < 100.0 AND ABS ( THE Y (POINT) ) < 100.0 ;

Здесь контроль типа осуществляется (концептуально) в результате обращения к оператору выбора CARTESIAN. Обратите внимание на применение определенного пользователем оператора ABS (см. раздел 5.2 главы 5).

Приведем более сложный пример - определение типа компонентов эллипса.

TYPE ELLIPSE POSSREP ( А LENGTH, В LENGTH, CTR POINT ) CONSTRAINT THE A ( ELLIPSE ) > THE B ( ELLIPSE ) ;

Здесь представлены возможные компоненты, а именно - А, В и CTR, которые соответствуют длине большой полуоси а, длине малой полуоси b и точке центра ctr рассматриваемого эллипса. Предположим, что скалярная переменная Е объявлена с типом ELLIPSE, ее текущее значение длины большой полуоси равно 5, а значение длины малой полуоси равно 4. Теперь рассмотрим следующее присвоение.

ТНЕ В ( Е ) := LENGTH ( 6.0 ) ;

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

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