приведенного выше списьса). Для этого достаточно определить ссылающийся столбец 1сак имеющий конструкцию NOT NULL. Таким образом, в столбце родительской таблицы не будет разрешено использование NULL-значений, а поскольку столбец внешнего ключа будет обязан содержать только значения, отличные от NULL, чтобы обеспечить согласование со значениями в таблице, указанной в ссылке, то заведомо удастся обеспечить согласование каждой строки ссылающейся таблицы хотя бы с одной из строк таблицы, указанной в ссылке. Иными словами, связь между родительской и дочерней таблицами становится обязательной.

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

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

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

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

В отличие от ограничения первичного ключа применение ограничения UNIQUE не приводит к тому, что автоматически исключается возможность вставить в соответствующий столбец NULL-значение. В данном случае возможность применения NULL-значений зависит от того, как задана опция NULL для указанного столбца таблицы. Но следует учитывать, что даже если вставка NULL-значений разрешена, фактически допускается вставка в столбец только одного такого значения. Хотя одно NULL-значение не равно другому NULL-значению, с точки зрения применения ограничения UNIQUE эти значения все равно рассматриваются как дубликаты.

Итак, к описанию данного ограничения больше нельзя что-либо добавить (к тому же при его изучении применим основной объем сведений, касающихся первичных ключей), поэтому приступим непосредственно к изучению примеров кода. Для этого создадим еще одну таблицу в базе данных Accounting. Но в данном случае необходимо создать таблицу Shippers:

CREATE TABLE Shippers (

ShipperlD int IDENTITY NOT NULL

PRIMARY KEY,

ShipperName varchar(30) NOT NULL,

Address varchar(30) NOT NULL,

City varchar(25) NOT NULL,

State char(2) NOT NULL,

Zip varchar(10) NOT NULL,

PhoneNo varchar(14) NOT NULL

UNIQUE

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

Создание ограничений unique на существующих таблицах

Как уже было сказано, ограничение UNIQUE действует в основном по таким же принципам, как и ограничения первичных и внешних ключей. Рассмотрим следую-ш;ий пример создания ограничения UNIQUE на таблице Employees:

ALTER TABLE Employees

ADD CONSTRAINT AK EmployeeSSN UNIQUE (SSN)

Сразу же после применения процедуры sp helpconstraint обнаруживается, что ограничение создано в соответствии с запланированным действием и правильно указаны столбцы, относяш;иеся к ограничению.

Отмешкм, что в приведенном выше примере аббревиатура АК, используемая в имени ограничения, расшифровывается как Alternate Key (альтернативный ключ). С другой стороны, для обозначения первичных ключей и внешних ключей применяются аббревиатуры РК (Primary Key) и FK (Foreign Key). А в именах ограничений UNIQUE часто используется префикс UQ, или просто U.

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

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

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

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

Таблица 5.2. Примеры критериев, применяемых в ограничении check Назначение Код SQL

Обеспечение применения в столбце Month between i and 12 только допустимых значений

Правильное форматирование номера like [0-9] [0-9] [0-9] - [0-9] [0-9] -

карточки социального обеспечения [0-9] [0-9] [0-9] [0-9]

Регламентация списка допустимых значений in ( ups , Fed Ex , usps ) в поле Shippers

Регламентация применения только UnitPrice >= о

положительных значений цены

Ссылка на другое поле в той же строке ShipDate >= OrderDate

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

ALTER TABLE Customers ADD DatelnSystem datetime

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

ALTER TABLE Customers

ADD CONSTRAINT CN CustomerDateInSystem CHECK

(DatelnSystem <= GETDATE ())

Теперь попытаемся вставить строку со значением, нарушающим ограничение CHECK. Эта попытка должна привести к возникновению ошибки:

insert INTO Customers

(CustomerName, Addressl, Address2, City, State, Zip, Contact, Phone, FedlDNo, DatelnSystem) VALUES

( Customerl, Addressl, Add2, MyCity, NY, 55555, No Contact, 553-1212, 930984954, 12-31-2049) Msg 547, Level 16, State 0, 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.

Если после этого будет внесено такое исправление, чтобы данные, вводимые в столбец DatelnSystem, соответствовали критерию, заданному в ограничении CHECK (относились к дате, совпадающей с нынешней или предшествующей ей), то попытка выполнить оператор INSERT завершится успешно.

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

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