своении не видно), поскольку в действительности данное присвоение является сокращением следующего выражения.

Е := ELLIPSE ( ТНЕ А ( Е ), LENGTH ( 6.0 ), THE CTR ( Е ) ) ;

Здесь в правой части операции присвоения явно показано обращение к оператору выбора, при выполнении которого и будет зафиксирована ошибка.

8.3. Ограничения атрибута

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

VAR S BASE RELATION { S# S#,

SNAME NAME, STATUS INTEGER, CITY CHAR } ... ;

В этой переменной-отношении значения атрибутов St, SNAME, STATUS и CITY ограничены типами St, NAME, INTEGER и CHAR соответственно. Другими словами, ограничения атрибутов являются частью определения этих атрибутов и могут быть идентифицированы по соответствующим именам атрибутов. Отсюда следует, что ограничение атрибута может быть устранено только путем удаления самого атрибута (что на практике чаще всего означает удаление переменной-отношения, включающей данный атрибут).

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

8.4. Ограничения переменной-отношения

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

CONSTRAINT SC5

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

Смысл: Поставщики в Лондоне должны обладать статусом, равным 20 .

Иначе говоря (и несмотря на то, что мы явно не ссылались на главу 5), псевдопеременные TEE не являются логически необходимьши! .Любое присвоение значения псевдопере.менной ТНЕ всегда логически эквивалентно (и фактически было определено просто как сокращенная запись) присвоению обычной переменной результата вызова определенного оператора выбора.

CONSTRAINT PC4

15 ЕМРТУ ( P WHERE COLOR = COLOR ( Red ) ) AND CITY Ф London ) ;

Смысл: Красные детали должны храниться в Лондоне .

CONSTRAINT SCK

COUNT ( S ) = COUNT ( S { S# } ) ;

Смысл: Номера поставщиков должны быть уникальны или, более формально, Ключ {SI} -это потенциальный ключ отношения поставщиков (раздел 8.8).

CONSTRAINT РС7

IF NOT ( IS EMPTY ( P ) ) THEN

COUNT ( P WHERE COLOR = COLOR ( Red ) ) > 0 END IF ;

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

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

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

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

CONSTRAINT DBC1

IS EMPTY ( ( S JOIN SP )

WHERE STATUS < 20 AND QTY > QTY ( 500 ) ) ;

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

Упражнение. Какие операции должны отслеживаться СУБД для приведения офаничения DBC1 в действие?

CONSTRAINT DBC2 SP { S } < S { S# } ;

Смысл: Каждый номер поставщика в переменной-отношении поставок должен присутствовать и в переменной-отношении поставщиков . (Напомним, что, как указывалось в главе 6, знак здесь означает подмножество .) Поскольку атрибут St в переменной-отношении S составляет потенциальный ключ, по сути, это офаничение является ссы-лочньш ограничением для поставок в отношении поставщиков (т.е. ключ {St} в переменной-отношении SP является внешним ключом, посредством которого сведения о поставках связываются с соответствующими поставщиками). Обсуждение этого вопроса будет продолжено в разделе 8.8.

CONSTRAINT DBC3 SP { Pt } = Р { Pt } ;

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

Замечание. Конечно, возможен случай, когда каждая поставка включает точно одну деталь, как следствие того факта, что ключ {Pt} в переменной-отношении Р является потенциальным ключом для деталей и сушествует ссылочное ограничение в отношении поставок и деталей. Однако мы не будем приводить это офаничение здесь, а обсуждение данного вопроса продолжим, опять же, в разделе 8.8.

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

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

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

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

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

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

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

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