Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil
Шрифт:
Полный синтаксис ограничения внешнего ключа (с возможностью создавать ограничения на основании нескольких полей) приведен ниже:
<tconstraint> = [CONSTRAINT constraint] FOREIGN KEY ( col [,
col } ) REFERENCES other_table [ ( other__col [ , other_col ...] } ]
[ON DELETE {NO ACTION CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE (NO ACTION|CASCADE|SET DEFAULT SET NULL}]
Как видите, определения содержат большой набор опций. Для начала давайте рассмотрим базовое определение внешнего ключа, которое наиболее часто используется в реальных базах данных, а затем разберем возможные опции.
Чаще всего употребляются декларативная
Пример такого определения при создании таблицы:
CREATE TABLE Inventory2(
...
FK_TABLE INTEGER NOT NULL CONSTRAINT fkinv REFERENCES
TITLE(ID_TITLE)
...) ;
Обратите внимание, что в этом определении опущены ключевые слова FOREIGN KEY, а также подразумевается, что в качестве внешнего ключа будет использоваться единственное поле - FK_TITLE.
А в следующем примере приведена более полная форма создания внешнего ключа одновременно с таблицей:
CREATE TABLE Inventory2(
...
FK_TABLE INTEGER NOT NULL,
CONSTRAINT fkinv FOREIGN KEY (FKJTABLE) REFERENCES
TITLE(IDJTITLE)
...) ;
Использование NULL в полях внешнего ключа
В полях, на основе которых создается внешний ключ, допускается применение NULL-полей. Эта возможность добавлена для разрешения взаимных ссылок. Например, еспи есть две таблицы, ссылающиеся друг на друга с помощью внешних ключей Ьсли не разрешить пустую ссылку (т. е. на NULL) в этих внешних ключах, то в связанные таблицы невозможно будет добавить ни одной записи: чтобы добавить запись в первую таблицу, надо будет иметь запись во второй таблице, и наоборот.
Использование NULL в качестве пустой ссылки позволяет организовать взаимные ссылки двух перекрестно ссылающихся таблиц, а также хранить иерархические структуры в реляционных таблицах - при этом корневые узлы ссылаются на "п\стые" записи (т. е. просто содержат NULL).
Расширенные возможности поддержки ссылочной целостности с помощью внешнего ключа
Обычно вполне достаточно декларативного варианта ограничения внешнего ключа, при котором сервер только следит за тем, чтобы в таблицу с внешним ключом нельзя было вставить некорректные значения или - при попытке сделать это возникает ошибка. Но InterBase позволяет выполнять ряд автоматических действий при изменении/удалении внешнего ключа. Для этого служит следующий набор опций внешнего ключа:
[ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}]
[ON UPDATE {NO ACTIONjCASCADEjSET DEFAULT]SET NULL}]
Эти опции позволяют определить различные действия при изменении или удалении значения внешнего ключа.
Например, мы можем указать, что при удалении первичного ключа в таблице-мастере необходимо удалять все записи с таким же внешним ключом в подчиненной таблице. Для этого следует так определить внешний ключ:
ALTER TABLE INVENTORY
ADD CONSTRAINT fkautodel
FOREIGN KEY (FK_TITLE) REFERENCES TITLE(ID_TITLE)
ON DELETE CASCADE
Фактически для реализации этих действий создается системный триггер, который и выполняет определенные действия. В табл. 1.2 приведено описание происходящих действий при различных опциях (обратите внимание, что опции NO ACTION|CASCADE|SET DEFAULT|SET NULL не могут использоваться совместно в одном предложении ON XXX).
| Событие | Действие | |||
| NO ACTION | CASCADE | SET DEFAULT | SET NULL | |
| ON DELETE | При | При удалении удалить все связанные записи из подчиненной таблицы | При изменении установить поле внешнего ключа в значение по умолчанию | При изменении установить поле внешнего ключа в NULL |
| ON UPDATE | При изменении ничего не делать - используется по умолчанию | При изменении записи изменить во всех связанных записях в подчиненных таблицах | При удалении установить поле внешнего ключа в значение по умолчанию | При удалении установить поле внешнего ключа в NULL |
Если мы ничего не указываем или указываем NO ACTION, то необходимо позаботиться об изменении внешнего ключа (в случае изменения первичного) самостоятельно, а при удалении первичного ключа предварительно удалить записи из подчиненной таблицы.
Осторожно надо обращаться с опцией CASCADE: неосторожное ее использование может привести к удалению большого количества связанных записей.
Ограничение CHECK
Одним из наиболее полезных ограничений в базе данных является ограничение проверки. Идея его очень проста - проверять вставляемое в таблицу значение на какое-либо условие и, в зависимости от выполнения условия, вставлять или не вставлять данные.
Синтаксис его достаточно прост:
<tconstraint> = [CONSTRAINT constraint] CHECK (
<search_condition>)}
Здесь constraint - имя ограничения; <search_condition> - условие поиска, в котором в качестве параметра может участвовать вставляемое/изменяемое значение. Если условие поиска выполняется, то вставка/изменение этого значения разрешаются, если нет - возникает ошибка.
Самый простой пример проверки:
create table checktst(
ID integer CHECK(ID>0));
Эта проверка устанавливает, больше ли нуля вставляемое/изменяемое значение поля ID, и в зависимости от результата позволяет вставить/изменить новое значение или возбудить исключение (см. главу "Расширенные возможности языка хранимых процедур InterBase" (ч. 1)).
Возможны и более сложные варианты проверок. Полный синтаксис условия поиска <search_condition> следующий:
<search_condition> = {<val> <operator>
{ <val> | (<select_one>)}
|<val> [NOT] BETWEEN <val> AND <val>
| <val> [NOT] LIKE <val> [ESCAPE <val>]
| <val> [NOT] IN ( <val> [ , <val> ...] | <select_list>)
| <val> IS [NOT] NULL
| <val> {[NOT] {= | < | >} | >= | <=}
{ALL | SOME | ANY} (<select_list>)
|EXISTS ( <select_expr>)
| SINGULAR ( <select_expr>)
| <val> [NOT] CONTAINING <val>
|<val> [NOT] STARTING [WITH] <val>
| (<search_condition>)
| NOT <search_condition>
| <search_condition> OR <search_condition>
| <search_condition> AND <search_condition>}