инструкция INSERT или UPDATE обращается к таблице, содержащей этот столбец. В отличие от процедуры проверки данных в СУБД DB2, правила в SQL Server создаются с использованием диалекта Transact-SQL Ниже приведена инструкция Transact-SQL, устанавливающая правило для столбца QUOTA таблицы SALESREPS:

CREATE RULE QUOTA LIMIT

AS gVALUE BETWEEN COO AND 500000.00

Это правило запрещает вводить в столбец quota отрицательные числа, а также числа, большие 500000. Как видно из примера, тому или иному правилу в SQL Server можно присвоить имя (в данном случае это quota limit). Однако, как и процедуры проверки данных в DB2, правила в SQL Server не имеют доступа к столбцам или другим объектам базы данных.

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

Ограничения на значения столбца

Ограничение на значения столбца в SQL2 аналогично условию отбора в предложении WHERE и возвращает значение TRUE или false. Если для столбца задано офаничение, то при каждом добавлении новой строки или обновлении старой СУБД автоматически проверяет, выполняется ли ограничение для значения в этом столбце. Если оно не выполняется, то инструкция insert или update завершается ошибкой Ограничение на значения столбца задается при определении столбца в инструкции CREATE TABLE.

Рассмотрим фрагмент инсфукции create table, создающей таблицу salesreps с тремя дополнительными офаничениями:

CREATE T.ABLE SALESREPS

(EMPL NUM INTEGER NOT NULL

CHECK (EMPL NUM BETWEEN 101 AND 199), AGE INTEGER

CHECK (AGE >= 21),

QUOTA MONEY

CHECK (MONEY >= 0.0),

Первое Офаничение (для столбца EMPL !mum) фебует, чтобы идентификаторы Служащих представляли собой трехзначные числа в диапазоне от 101 до 199. Второе .Таничение (для столбца age) запрещает нанимать на работу людей младше 21 года, фетье Офаничение (для столбца quota) не позволяет назначать служащему плановый объем продаж меньше $0,00.

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

Домены

Домен в SQL2 обобщает понятие ограничения на значения столбца и позволяет применять одно и то же ограничение для различных столбцов. Домен представляет собой именованное описание множества значений, которые могут храниться в столбце. Он создается с помощью инструкции create domain, появившейся в SQL2. В ней также имеется офаничение check, содержащее условие отбора. Вот пример инструкции, создающей домен valid employee id, который включает все множество допустимых значений идентификаторов служащих:

CREATE DOMAIN VALID EMPLOYEE ID INTEGER CHECK (VALUE BETWEEN 101 AND 199) i

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

create table для таблицы salesreps МОЖНО записать так

CREATE TABLE SALESREPS

(EMPL NUM VALID EMPLOYEE ID, AGE INTEGER

CHECK (AGE >= 21),

QUOTA MONEY

CHECK (MONEY >= 0.0),

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

CREATE TABLE OFFICES

(OFFICE INTEGER NOT NULL,

CITY VARCHAR(15) NOT NULL, REGION VARCHAR(IO) NOT NULL,

MGR VALID EMPLOYEE ID, TARGET MONEY, SALES MONEY NOT NULL,

Другим очевидным преимушеством доменов является то, что все определения допустимых данных (как допустимые идентификаторы служащих в показанном

примере) хранятся в одном месте базы данных. Если определение домена впоследствии потребуется изменить (к примеру, компания разрастется и возникнет необходимость расширить диапазон идентификаторов до 299), то намного проше сделать это один раз, чем менять определения столбцов во всей базе данных.

Целостность таблицы

Каждая строка таблицы должна иметь уникальное значение первичного ключа, иначе база данных потеряет свою целостность и перестанет быть адекватной моделью внешнего мира. Например, если бы две строки таблицы salesreps имели в столбце empl num значение 106, то невозможно было бы сказать, какая из них относится к реальному субъекту - Биллу Адамсу, имеюшему идентификатор 106. По этой причине требование, чтобы первичные ключи имели уникальные значения, называется условием целостности таблицы.

В ранних коммерческих СУБД первичные ключи отсутствовали, но сейчас они стали повсеместно распространенными. В DB2 первичные к;1ючи появились в 1988 году, а в стандарт SQL1 они были добавлены в виде промежуточного изменения, внесенного перед появлением полного стандарта SQL2. Как в DB2, так и в стандарте ANSI/ISO первичные ключи создаются с помощью инструкции create table. В описания всех таблиц учебной базы данных в Приложении А включены также описания первичных ключей в соответствии с синтаксисом DB2 и ANS1/1S0.

СУБД автоматически проверяет уникальность первичного ключа для каждой инструкции insert или update. Попытка добавить строку с уже существующим значением первичного ключа или обновить строку таким образом, что ее первичный ключ потеряет свою уникальность, завершится выдачей сообщения об ошибке.

Прочие условия уникальности столбцов

Иногда требуется, чтобы столбец, не являющийся первичным ключом таблицы, все же содержал во всех строках уникальные значения. Предположим, например, что требуется ограничить данные в таблице salesreps таким образом, чтобы не было двух служащих с одинаковыми именами. Достичь этой цели можно, наложив условие уникальности на столбец name. СУБД обеспечивает выполнение этого условия точно так же, как обеспечивает уникальность первичного ключа. Любая попытка добавить или обновить строку, нарушающая условие уникальности, завершится неуспешно

В соответствии со стандартом ANSI/ISO условие уникальности для столбцов или комбинаций столбцов определяется в инструкции create table. Однако в DB2 условия уникальности были реализованы задолго до того, как они вошли в стандарт ANSI/ISO, поэтому в DB2 они являлись частью инструкции create index. Это одна из административных инструкций реляционной базы данных, имеющая дело с физической памятью на диске, где хранится информация базы данных. Обычно пользователю не приходится беспокоиться об этих инструкциях; их применяет только администратор базы данных.

В отношении условий уникальности столбцов многие коммерческие СУБД Первоначально придерживались соглашений DB2, а не стандарта ANS1/1S0, требуя использования инструкции create index. Но со временем разработчики DB2 перенесли условия уникальности в инструкцию create table Поэтому большинство Поставщиков СУБД планируют придерживаться синтаксиса ANSI/ISO по мере рас-1ЧИрения поддержки стандарта SQL2.