Ограничения

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

Поддержание сущностной и ссылочной целостности данных

Информационная безопасность систем управления базами данных

Надежда Вьюкова, Владимир Галатенко
АО "Инфосистемы Джет"

http://www.citforum.ru/database/kbd96/49.shtml

http://www.citforum.ru/database/kbd96/50.shtml

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

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

С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения и правила.

Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах 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 делается попытка примирить контроль ограничений и эффективность функционирования. При массовом копировании данных контроль ограничений отключается. Это значит, что необходимо дополнять копирование запуском процедуры глобальной проверки целостности.

Дата добавления: 2014-01-04