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

Другая общепринятая ссылочная операция задается спецификатором RESTRICT (она не имеет ничего общего с операцией выборки (restrict) реляционной алгебры). В данном случае спецификатор RESTRICT указывает, что выполнение операции DELETE допускается, если в переменной-отношении поставок нет ни одного кортежа с соответствующим внешним ключом. В противном случае операция удаления отвергается. Опускание конкретного спецификатора ссылочной операции при определении некоторого внешнего ключа равносильно заданию спецификатора N0 ACTION (никаких действий), означающего, что операция DELETE будет выполняться в точности так, как она описана, и не более того. (Если спецификатор N0 ACTION применить к нашему примеру, то при удалении поставщика, для которого имеются сведения о выполняемых им поставках, установленное ограничение ссылочной целостности, безусловно, будет нарушено.) Рассмотрим некоторые случаи применения ссылочных операций.

1. Операция DELETE - это не единственная операция, для которой имеет смысл определение ссылочных операций. Например, что должно произойти при попытке изменить номер поставщика, для которого уже имеются сведения хотя бы об одной поставке? Очевидно, что необходимо использовать правило обновления, подобное обсуждавшемуся выше правилу удаления. В общем случае для операции обновления существует тот же набор ссылочных действий, что и для операции удаления.

CASCADE- каскадно распространить операцию обновления посредством обновления значений всех соответствующих внешних ключей в переменной-отношении поставок.

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

N0 ACTION - операция обновления выполняется в точности так, как она записана.

2. Безусловно, спецификаторы CASCADE, RESTRICT и N0 ACTION не следует считать единственно возможными вариантами ссылочных операций. Это минимальный набор спецификаторов, отражающий только те варианты действий, которые чаще всего применяются на практике. Однако, в принципе, может существовать произвольное количество возможных решений при попытке, например, удалить определенного поставщика. Укажем некоторые из возможных действий.

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

Поставки для одного поставщика передаются другому поставщику.

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

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

3. Пусть R1 и R2 - ссылающаяся и ссылочная переменные-отношения соответственно.

R2 -> R1

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

R3 -> R2 -> R1

Тогда результат неявного удаления кортежей из переменной-отношения R2 по сути ничем не будет отличаться от попытки непосредственного удаления этих кортежей явно заданной операцией удаления. Иначе говоря, выполнение неявного удаления требует соблюдения правила удаления, установленного как ограничение ссылочной целостности между переменными-отношениями R3 и R2. Если в результате требуемое удаление выполнено не будет (согласно установленному правилу удаления для ссылочной зависимости между переменными-отношениями R3 и R2 или же по какой-либо другой причине), то должно быть отменено и выполнение всей операции в целом, а база данных сохранена в неизменном состоянии. И так далее рекурсивно для любого количества уровней.

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

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

Триггерные процедуры

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

тельная ситуация (в частности, нарушение некоторого установленного офаничения целостности) или истечение заданного времени. Простейшим примером триггерной процедуры могут служить ссылочные действия, выполняемые при указании спецификатора CASCADE (заметьте, при декларативном указании!).

В обшем случае триггерные процедуры могут применяться и для решения более широкого круга проблем, а не только для рассматриваемых в этом разделе вопросов обеспечения ссылочной целостности. (С перечнем таких применений можно ознакомиться в [8.1].) Однако это большая самостоятельная тема, которая выходит далеко за рамки данной книги. (Заинтересованный читатель может обратиться к [8.22], где эти вопросы излагаются подробно.) Хотелось бы отметить, что, несмотря на то что использование триггерных процедур может быть чрезвычайно полезным для достижения самых различных целей, его не следует считать хорошим подходом для обеспечения целостности базы данных по очевидным причинам: декларативный подход, если он только возможен, всегда предпочтительнее.

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

8.9. Средства языка SQL

Классификация офаничений целостности в языке SQL довольно сильно отличается от схемы, описанной в разделах 8.1-8.5. В языке SQL все офаничения делятся на три категории:

ограничения домена;

ограничения базовой таблицы;

общие Офаничения (иначе называемые утверждениями).

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

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

Понятие ограничения домена в языке SQL представляет некоторую сомнительную обобщенную форму нашего ограничения атрибута (напомним, что домены в стиле языка SQL в реляционном смысле доменами не являются).

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

Также отметим, что в языке SQL совершенно отсутствует поддержка ограничений перехода. В настоящее время не поддерживаются и триггерные процедуры, хотя их поддержка уже включена в новый стандарт SQL3 (см. приложение Б).