Главная » SQL, Базы данных » Целостность данных

0

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

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

1.          Значение статуса каждого поставщика должно находиться в пределах от 1 до 100

включительно.

2.          Каждый поставщик из Лондона имеет статус 20.

3.          Если вообще имеются какие-либо детали, то по меньшей мере одна из них должна иметь синий цвет.

4.          Разные поставщики не могут иметь одинаковые номера поставщиков.

5.          Каждая поставка выполняется существующим поставщиком.

6.          Ни один поставщик со статусом меньше 20 не поставляет любые детали в количе стве больше 500.

Данные примеры будут широко использоваться в настоящей главе.

Очевидно, что ограничения должны быть формально объявлены для СУБД, после чего СУБД должна предписывать их выполнение. Объявление  ограничений сводится

просто к использованию соответствующих средств языка базы данных, а  соблюдение

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

CONSTRAINT SC1

IS_EMPTY ( S WHERE STATUS < 1 OR STATUS > 100 ) ;

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

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

(т.е. записывается в каталог системы) и начиная с этого момента соблюдается. Кстати, следует отметить, что в данном примере ограничению присвоено имя — SCI ("suppliers constraint one" — ограничение для поставщиков номер один).  При условии, что это ограничение принято СУБД, оно будет зарегистрировано в  каталоге под этим именем, после чего указанное имя будет появляться в диагностических сообщениях, вырабатываемых системой в ответ на попытки нарушить данное ограничение.

Ниже показаны еще две возможные формулировки ограничения из примера 1, в которых теперь используется версия языка Tutorial D на основе реляционного исчисления (здесь SX — переменная области значений, которая принимает свои значения среди номеров поставщиков).

CONSTRAINT SC1

NOT EXISTS SX ( SX.STATUS < 1 OR SX.STATUS > 100 ) ;

CONSTRAINT SC1

FORALL SX ( SX.STATUS > 1 AND SX.STATUS < 100 ) ;

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

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

DROP CONSTRAINT <constraint name> ;

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии