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

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

VAR S BASE RELATION { SI St,

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

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

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

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

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

CONSTRAINT SC5

IS_EMPTY { S WHERE CITY = 'London' AND STATUS * 20 ) ;

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

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

CONSTRAINT PC4

IS_EMPTY ( P WHERE COLOR = COLOR { 'Red' ) ) AND CITY Ф 'London' ) ;

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

CONSTRAINT SCK

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

Смысл: "Номера поставщиков должны быть уникальны" или, более формально, "Ключ {St} — это потенциальный ключ отношения поставщиков" (раздел 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 { St } < S { Si } ;

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

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

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

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

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

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