Ограничения

Поддержание целостности данных в СУБД

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

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

CREATE TABLE dept (dname char(10),

budget money,

expenses money,

CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget));

{Бюджет должен быть положительным, а расходы не должны выходить за рамки бюджета}

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

Приведем пример ссылочного ограничения:

CREATE TABLE emp (ename char(10),

edept char(10) references dept(dname));

{Ни один работник не должен числиться в неизвестном отделе}

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

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

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

CREATE TABLE dept (name char(10) NOT NULL,

location char(20),

CONSTRAINT dept_unique UNIQUE(name));

CREATE TABLE emp (name char(10),

salary decimal(10,2),

edept char(10) CONSTRAINT empref REFERENCES dept(name));

Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:

ALTER TABLE dept

DROP CONSTRAINT dept_unique cascade;

Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений. В СУБД INGRES делается попытка примирить контроль ограничений и эффективность функционирования. При массовом копировании данных контроль ограничений отключается. Это значит, что необходимо дополнять копирование запуском процедуры глобальной проверки целостности.