Декларативная целостность данных. Реализация декларативной целостности данных. Ограничения PRIMARYKEY И UNIQUE

В SQL Server проверить целостность данных можно двумя способами: с помощью декларативной целостности данных или с помощью процедурной целостности данных.

Декларативная целостность данных — это набор правил, которые применяются к таблице и ее столбцам в инструкциях CREATE TABLE или ALTER TABLE. ЭТИ правиланазывают ограничениями.

Процедурная целостность данных реализуется либо с помощью хранимой процедуры, которой предоставляется возможность проверки допустимости данных, либо с помощью создания триггеров, проверяющих данные до или после задания инструкции языка манипулирования данными (DML) (такой как INSERT, UPDATE ли DELETE).  

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

Реализация декларативной целостности данных

Декларативная целостность данных реализуется с помощью ограничений. Есть тать типов ограничений: PRIMARY KEY, UNIQUE, FOREIGN KEY, CHECK И DEFAULT.

Ограничения PRIMARYKEY И UNIQUE. Первичные ключи и ограничения UNIQUE определяют столбец или комбинацию столбцов, которые однозначно идентифицируют строку в таблице. Реализуется это созданием уникального индекса, т. е. индекса, для которого не допустимы дублирующиеся значения. По этой причине первичный ключ и ограничения UNIQUE имеют одни и те же ограничения размера, что и ключ индекса, они не могут включать в себя более 15 столбцов или 900 байтов данных.

Если больше ничего не задано, для первичного ключа создается кластеризованный индекс (clustered index), а для ограничений UNIQUE— некластеризованный индекс (nonclustered index). Но это поведение можно изменить, задав тип создаваемого индекса в инструкции ALTER TABLE или CREATE.

Ограничения FOREIGNKEY. Ограничения внешнего ключа (FOREIGN KEY) определяют столбец или комбинацию столбцов, чьи значения должны существовать в другом столбце или комбинации столбцов в той же или другой таблице одной той же базы данных. Ограничения внешнего ключа управляют ссылочной целостностью между таблицами или в одной таблице. Для реализации ограничения внешнего ключа вы должны следовать правилам.

♦ Столбцы, на которые ссылаются, должны иметь точно такой же тип данных (и набор параметров символьной обработки для строковых столбцов), что и местные столбцы.

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

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

Вы также можете создавать внешние ключи на базе вычисляемых столбцов Информацию об имеющихся в вашей базе данных ограничениях внешнего ключа можно найти, запросив представления каталога sys.foreign_keys и sys.foreign_key_columns.

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

Есть четыре варианта действий, из которых можно выбирать:

Пример Далее приведен пример реализации.

CREATE TABLE Test.Customers (CustomerId INT PRIMARY KEY);

CREATE TABLE Test.Orders (OrderId INT PRIMARY KEY  

    ,CustomerId INT NULL

            REFERENCES Test.Customers 

ON DELETE SЕТ NULL

ON UPDATE CASCADE)

Стандартное поведение для ограничения внешнего ключа — NO ACTION. Если внешний ключ обнаруживает нарушение и задано NO ACTION, SQL Server отменяет действие инструкции, нарушившей ограничение, и генерирует сообщение об ошибке.

SЕТ NULL и SЕТ DEFAULT вместо генерации сообщения об ошибке и отката инструкции присваивают всем значениям, на которые делается ссылка, либо NULL (для SЕТ NULL), либо DEFAULT (для SЕТ DEFAULT, если конечно для столбца значение по умолчанию задано).

В связанных таблицах Orders (Заказы) и Customers(Клиенты), показанных в примере программного кода, если удаляется клиент, столбцу CustomerId (ID клиента) присваивается значение NULL во всех заказах, принадлежащих этому клиенту, и вызвавшему приложению не посылается никакого сообщения об ошибке.