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

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

ALTER TABLE Customers CHECK

CONSTRAINT CN CustomerPhoneNo

После вызова на вьшолнение того же оператора INSERT для проверки функционирования ограничения появится такое же сообщение об ошибке, как и раньше: Msg 547, Level 16, State О, Line 1

The INSERT statement conflicted with the CHECK constraint

CN CustomerDateInSystem . The conflict occurred in database Accounting , table dbo.Customers , column DatelnSystem. The statement has been terminated.

Безусловно, и в данном случае рекомендуется снова вызвать на вьшолнение процедуру sp helpconstraint и ознакомиться с содержимым столбца status enabled. Если в этом столбце указано состояние Enabled (Разрешено), то рассматриваемое ограничение снова должно действовать.

Конструкции, подобные ограничениям, - правила и значения, применяемые по умолчанию

Такие конструкции, как правила и заданные по умолчанию значения, были предусмотрены в СУБД SQL Server намного раньше, чем ограничения CHECK и DEFAULT. В определенном смысле эти конструкции можно рассматривать как унаследованные от прежних версий SQL Server, но они не лишены определенных преимуществ.

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

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

Правила

Правила весьма напоминают ограничения CHECK. Правила имеют свойства, аналогичные описанным выше свойствам ограничений CHECK, за единственным исключением, - область применения праврш ограничена тем, что они позволяют работать одновременно только с одним столбцом. Одно и то же правршо можно связать отдельно с несколькими столбцами в таблице, но это правило будет действовать независимо применительно к каждому столбцу, поскольку в нем вообще не учитывается наличие других столбцов. Это означает, что ограничение, определенное как (QtyShipped < = QtyOrdered), не может применяться в качестве правила. Ведь в нем упоминается больше чем один столбец. С другой стороны, ограничение LIKE ([0-9] [0-9] [0-9]) относится только к тому столбцу, с которым связано соответсгвующее правршо.

Вначале определим правршо, чтобы можно было проще показать его отличие от ограничения:

CREATE RULE SalaryRule AS ©Salary > 0

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

После создания данного праврша можно проверить, как оно представлено в базе данных. Для этого можно воспользоваться процедурой sp lielptext: EXEC sp helptext SalaryRule

После вызова этого оператора на выполнение отображается точное определение праврша: Text

CREATE RULE SalaryRule AS ©Salary > 0

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

Для активизации этого правила используется специальная хранимая процедура sp bindrule. Предположим, что требуется выполнить привязку правила SalaryRule к столбцу Salary таблицы Employees. Для этого применяется следующий синтаксис: sp bindrule <rule>, <object name>, [<futureonly flag>]

Часть < rule > этого определения является достаточно простой - в ней должно быть указано правршо, подлежащее привязке. Часть < оЬj ect name > также не представляет никаких сложностей. Она указывает на объект (столбец или определяемый пользователем тип данных), к которому следует выполнить привязку правила. Определенные нюансы следует учитывать только при использовании параметра < f utureonly f lag >, который применяется лишь в случае привязки правила к определяемому пользователю типу данных. По умолчанию этот параметр имеет значение off. Но если при вызове процедры sp bindrule < rule > в качестве него будет задано True или 1, то связывание праврша будет осуществляться только применительно к новым столбцам, для которых задается соответствующий тип данных, определяемый пользователем. Во всех столбцах, для которых уже был определен

тот же тип данных в старой форме, будет по-прежнему использоваться форма, для которой еще не было задано правило.

В рассматриваемом случае происходит просто привязка правила к столбцу, поэтому согласно синтаксическому определению требуются только первые два параметра: sp bindrule SalaryRule, Employees.Salary

Рассмотрим более внимательно параметр < оЬ j ect name >. Входящие в его состав имена Employees and Salary разделены точкой (.). Причина такого положения дел заключается в следующем. Дело в том, что правило не относится к какой-либо конкретной таблице до тех пор, пока не будет выполнена его привязка, поэтому необходимо указывать и таблицу, и столбец, к которому должно быть привязано это правило. Если не используется структура именования tablename . column, то СУБД SQL Server действует согласно предположению, что указанное имя относится к определяемому пользователем типу данньгх. Если же таковое не обнаруживается, то появляется сообщение об ошибке, которое довольно трудно понять в той ситуации, когда фактически не предпринималась попытка привязки правила к типу данных:

Msg 15148, Level 16, State 1, Procedure sp bindrule. Line 190

The data type or table column Salary does not exist or you do not have

permission.

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

Чтобы отменить привязку правила к столбцу, можно воспользоваться процедурой sp unbindrule:

EXEC sp unbindrule Employees.Salary

Синтаксическая структура процедуры sp unbindrule также предусматривает возможность применения параметра futureonly f lag, но в данном конкретном примере этот вариант не рассматривается. Если процедура sp unbindrule вызывается на вьшолнение с параметром f utureonly f lag, которому присвоено значение on, а объектом действия процедуры является тип данных, определяемый пользователем (а не конкретный столбец), то отмена привязки распространяется только на те случаи, в которых этот тип данньгх будет использоваться в дальнейшем, а в существующих столбцах с указанным типом данных по-прежнему будет применяться то же правило.

Удаление правил

Если из базы данных необходимо полностью удалить определение некоторого правила, то можно воспользоваться оператором DROP, применение которого было показано выше на примере таблиц:

DROP RULE <rule name>

Значения по умолчанию

Заданные по умолчанию значения еще в большей степени напоминают свои аналоги, ограничения DEFAULT, чем правила напоминают ограничения CHECK. И действительно, заданные по умолчанию значения и ограничения DEFAULT действуют полностью одинаково, а единственное реальное различие между ними заключается в том, что они по-разному закрепляются за таблицей. Кроме того, заданные по умолчанию значения (которые в отличие от ограничений представляют собой объекты базы данных) поддерживают определяемые пользователем типы данных.