Базы данных конспект лекций - Коллектив авторов (2007)

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

Для исключения возможности их появления при объявлении значения внешнего ключа задается одно из трех имеющихся правил поддержания ссылочной целостности, применяемых соответственно при обновлении значения ключа в родительском отношении (т. е., как мы уже упоминали раньше, on update) или при удалении кортежа из родительского отношения (on delete). Необходимо отметить, что добавление нового кортежа в родительское отношение не может нарушить ссылочную целостность по вполне понятным причинам. Ведь, если этот кортеж только что добавили в базовое отношение, раньше на него не мог ссылаться ни один атрибут по причине его отсутствия!

Итак, что же это за три правила, применяющиеся для поддержания в базах данных ссылочной целостности? Перечислим их.

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

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

Пусть даны два отношения:

Родительское отношение

Дочернее отношение

Мы видим, что кортежи дочернего отношения (2, …) и (2, …) ссылаются на кортеж (…, 2) родительского отношения, а кортеж (3, …) дочернего отношения ссылается на кортеж (…, 3) родительского отношения. Кортеж (100, …) дочернего отношения является висящим, он недопустим.

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

Составим оператор создания базового отношения, включающего в себя объявление всех вышеназванных ключей:

Create tableРодительское отношение

Primary_key

Integer

not Null

primary key (Primary_key)

Create tableДочернее отношение

Foreign_key

Integer

Null

foreign key (Foreign_key) referencesРодительское отношение (Primary_key)

on update Restrict

on delete Restrict

2. Cascade, или правило каскадной модификации. Если при объявлении внешних ключей в нашем базовом отношении мы использовали правило поддержания ссылочной целостности Cascade, то обновление ключа в родительском отношении или удаление кортежа из родительского отношения вызывает автоматическое обновление или удаление соответствующих ключей и кортежей дочернего отношения.

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

Родительское отношение

и

Дочернее отношение