18.5.Правила удаления и обновления

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

• RESTRICT (NO ACTION) – запрещает удаление строки из таблицы – предка, если строка имеет потомков. Инструкция DELETE, пытающаяся удалить такую строку, отбрасывается, и выдается сообщение об ошибке. В некоторых СУБД данное правило носит название no action. Следует также иметь в виду, что данное правило зачастую воспринимается СУБД по умолчанию и не требует явного задания.

• CASCADE — определяет, что при удалении строки – предка все строки-потомки также автоматически удаляются из таблицы-потомка. Данное правило опасно в употреблении, в случае если в базе существуют разнообразные множественные связи.

• SET NULL – определяет, что при удалении строки-предка внешним ключам во всех ее строках – потомках автоматически присваивается значение NULL. Таким образом, удаление строки из таблицы – предка вызывает установку значений NULL в некоторых столбцах таблицы-потомка.

• SET DEFAULT – определяет, что при удалении строки – предка внешним ключам, всем ее строкам – потомкам присваивается определенное значение, по умолчанию установленное для данного столбца. Таким образом, удаление строки из таблицы – предка вызывает “установку значений по умолчанию” в некоторых столбцах таблицы-потомка.

Аналогично тому, как правила удаления определяют действия СУБД при попытке удалить строку из таблицы – предка, так правила обновления определяют действия СУБД, когда пользователь пытается обновить значение первичного ключа в таблице – предке. Регламентируются четыре правила обновления, аналогичные правилам удаления:

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

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

• SET NULL – определяет, что при обновлении значения первичного ключа в строке – предке внешним ключам во всех ее строках – потомках автоматически присваивается значение NULL.

• SET DEFAULT – определяет, что при обновлении значения первичного ключа в строке – предке внешним ключам во всех ее строках – потомках по умолчанию присваивается определенное значение, установленное для данного столбца.

Для одного и того же отношения предок/потомок правила удаления и обновления могут быть различными, хотя в большинстве случаев они совпадают. Так на рисунке 14 приведена реляционная схема базы данных некоего малого предприятия:

Рисунок 14 Реляционная схема базы данных малого

предприятия

В данной базе для отношений предок/потомок логично предусмотреть следующие правила по удалению и обновлению строк – предков:

• для отношения IS_FOR следует, по-видимому, применять правило RESTRICT (как для удаления, так и для обновления). Нельзя удалить информацию о продукции или изменить её идентификатор, если в настоящий момент на этот товар имеются заказы.

• для отношения между заказом и заказчиком, сделавшим его, следует, по-видимому, использовать правило CASCADE (как при удалении, так и при обновлении). Если заказчик прекращает сотрудничество с предприятием, то из базы данных необходимо удалить его строку. В этом случае вместе с данными о заказчике следует также удалить и все его текущие заказы. Аналогично, изменение идентификатора заказчика следует автоматически распространить на все его заказы.

• для отношения между заказом и служащим, принявшим его, следует, по-видимому, применять правило SET NULL. Если служащий покидает предприятие, то все заказы, принятые им, останутся без служащего (будут заказами “неизвестного служащего”) до тех пор, пока их не закрепят за другим служащим. Что касается правила обновления, то для этого отношения необходимо, вероятно, применять правило CASCADE, чтобы автоматически распространять изменение идентификатора служащего на таблицу ORDERS.

В заключение следует отметить, что некоторые СУБД, в частности ORACLE не поддерживают правил SET NULL и SET DEFAULT , а правило CASCADE требует явного задания и поддерживается только для удалений. Правила каскадного обновления в системе ORACLE недействительны, поддерживается только запрет на изменение строк – предков.