Ограничения домена

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

CREATE DOMAIN COLOR CHAR(6) DEFAULT ??? CONSTRAINT VALID COLORS CHECK ( VALUE IN

( Red, Yellow, Blue, Green, ??? ) ) ;

Предположим, что оператор CREATE TABLE для базовой таблицы Р (таблицы деталей) выглядит следующим образом.

CREATE TABLE Р ( ... , COLOR COLOR, ... ) ;

Если пользователь вставляет в таблицу Р только часть новой строки, не содержащую значение для столбца COLOR, то по умолчанию в этот столбец будет помещено значение ???. Если же пользователь jK-flf-ew значение для столбца COLOR, но это значение не будет принадлежать диапазону допустимых для него значений, то операция не будет выполнена и система выдаст сообщение, в котором будет указано о нарущении пользователем Офаничения VALID COLORS.

Как было показано в разделе 8.2, концептуально офаничения домена являются (или, скорее, должны являться) ничем иным, как перечнем значений, которые составляют этот домен, и приведенный выще пример офаничения VALID COLORS, конечно, следует этому определению. Однако в общем случае язык SQL позволяет включать в определение офаничений доменов логические выражения произвольной сложности. Это предоставляет возможность указывать, например, что допустимые значения некоторого домена D могут зависеть от значений указанного атрибута, присутствующих в настоящий момент в некоторой таблице Т. Читатель может поразмышлять о возможных последствиях такой неоправданной вседозволенности.

Ограничения базовой таблицы

в языке SQL существуют следующие виды офаничений базовой таблицы:

определение потенциального ключа;

определение внешнего ключа;

определение проверочного условия .

Ниже каждое из них обсуждается подробнее.

Замечание. В языке SQL каждому определению офаничений может предшествовать предложение вида CONSTRAINT <имя orpaHH4eHHJi>, задающее имя нового офаничения (это замечание верно и для офаничений доменов, как мы уже убедились на примере офаничения VALID COLORS). В приводимых ниже примерах мы будем игнорировать эту возможность.

Потенциальные ключи

Определение потенциального ключа записывается в следующем виде. UNIQUE ( <список имен столбцов> )

Возможна и другая форма записи. PRIMARY KEY ( <список имен столбцов> )

В обоих случаях параметр <список имен столбцов> не должен быть пустым. Для заданной базовой таблицы может существовать не более одной спецификации PRIMARY KEY (первичный ключ) и любое количество спецификаций UNIQUE (альгернативные ключи). В случае первичного ключа для каждого из указанных столбцов дополнительно подразумевается наличие в определении спецификации NOT NULL, даже если эта спецификация не была указана явно. Проверка выполнения ограничений будет обсуждаться ниже.

Внешние ключи

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

FOREIGN KEY ( <список имен столбцов> )

REFERENCES <имя базовой таблицы> [ ( <список имен столбцов> ) ] [ ON DELETE <ссылочная операциЯ> ] [ ON UPDATE <ссылочная операциЯ> ]

Здесь параметр <ссылочная операциЯ> может принимать значения N0 ACTION (по умолчанию), CASCADE, SET DEFAULT и SET NULL. Опции SET DEFAULT и SET NULL будут рассматриваться в главе 18. Второй параметр <список имен столбцов> необходим в том случае, если внешний ключ ссылается на потенциальный ключ, который не является первичным ключом.

Замечание. Соответствие внешний ключ - потенциальный ключ устанавливается не на основе имен столбцов, а на основе позиции (слева направо) в списках имен атрибутов.

Проверочные условия

Определение проверочного условия (проверочного ограничения) имеет следующий вид. CHECK ( <условное выражение> )

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

Замечание. Условное выражение в языке SQL является аналогом того, что ранее мы называли логическим (или булевым) выражением. Эти выражения подробно рассматриваются в приложении А. В частности, отметим, что в данном контексте условное выражение может быть сколь угодно сложным. Не требуется, чтобы условие ограничения включало ссылки только на таблицу Т; оно может иметь ссылки на что угодно в базе данных. Читателю, опять-таки, будет полезно поразмышлять над тем, какими могут быть последствия такой неоправданной вседозволенности.

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

CREATE TABLE SP

( S# S# NOT NULL, P# P# NOT NULL, QTY QTY NOT NULL, PRIMARY KEY ( St, Pt ), FOREIGN KEY ( St ) REFERENCES S

ON DELETE CASCADE

ON UPDATE CASCADE, FOREIGN KEY ( P# ) REFERENCES P

ON DELETE CASCADE

ON UPDATE CASCADE, CHECK ( QTY > 0 AND QTY < 5001 ) ) ;

Здесь подразумевается, что домены St, Pt и QTY уже определены, а атрибуты Si и Р# явно определены как первичные ключи для таблиц S и Р соответственно. Также здесь умышленно применяется соглашение по сокрашению, благодаря которому проверочное условие вида

CHECK ( <имя стол6ца> IS NOT NULL )

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

Завершая подраздел, обратим внимание на некоторую странность : считается, что Офаничение базовой таблицы SQL всегда удовлетворено, если базовая таблица пуста, причем даже в случае офаничения вида эта таблица не должна быть пустой !

Утверждения

Рассмотрим третий случай: обшие ограничения, иначе называемые утверждениями. Общие ограничения создаются с помощью оператора CREATE ASSERTION, имеющего следующий синтаксис.

CREATE ASSERTION <имя ограничения> CHECK ( <условное выражение> ) ;

Здесь параметр <имя ограничения> задает имя создаваемого ограничения, а параметр <условное выражение> определяет проверяемое условное выражение. Для отмены общего ограничения используется оператор DROP ASSERTION.

DROP ASSERTION <имя ограничениЯ> ;

Отметим, что в отличие от всех других форм SQL-оператора отмены DROP, приведенных в этой книге (DROP DOMAIN, DROP TABLE, DROP VIEW), оператор DROP ASSERTION не содержит опций RESTRICT и CASCADE.

Вот несколько примеров утверждений, создаваемых с помощью оператора CREATE ASSERTION.

L Каждый поставщик должен иметь статус не менее 5.

CREATE ASSERTION IC13 CHECK

( ( SELECT MIN ( S.STATUS ) FROM S ) > 4 ) ;

2. Значение веса любой детали должно быть положительным.

CREATE ASSERTION IC18 CHECK

( NOT EXISTS ( SELECT * FROM P

WHERE NOT ( P.WEIGHT > 0 ) ) ) ;