Заметим, что атрибут cert# в MovieExec, на который ссылается внешний ключ, фактически является первичным ключом этого отношения. Для того чтобы в от>юше-нии studio корректно объявить атрибут presC# внешним ключом, ссылающимся на cert# из MovieExec, атрибут cerW обязательно должен быть объявлен первичным ключом своего отношения.

Смысл любого из приведенньк описаний внешнего ключа заключается в следующем. Если какое-то значение появляется в компоненте presC# кортежа из Studio, > оно должно появиться и в компоненте cert* одного из кортежей MovieExec. Единственным исключением является то, что при наличии значения NULL в компоненте presCff кортежа из Studio не требуется, чтобы оно было значением и в компоненте cert# (фактически разумно вообще не допускать NULL в качестве атрибута, являющегося первичным ключом; см. раздел 6.3.1). □

6.2.2 Применение ссылочной целостности

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

Правило по умолчанию:

отвергать изменения, нарушающие ограничения

в SQL по умолчанию принимается правило, согласно которому система отвергает любое измврнение, нарушающее ссылочную целостность. Обратимся к примеру 6.3, в котором требовалось, чтобы значение presC# отношения Studio было также значением свг1# отношения MovieExec. В данном случае следующие действия будут отвергнуты системой (и вызовут ошибку выполнения операций):

L Попытка ввести в Studio новый кортеж, в котором значение компонента presC# не совпадает ни с NULL, ни со значением компонента cert# любого кортежа из MovieExec. Действие отвергается, и такой кортеж никогда не вводится в Studio.

2. Попытка обновить кортеж из Studio, изменив presC# на отличное от NULL значение, которого нет в компоненте сег1# любого кортежа из MovieExec. Изменение отвергается, и кортеж остается в прежнем виде.

3. Попытка удаления кортежа из MovieExec, компонент которого cert# входит как компонент presC# в один или несколько кортежей из Studio. Удаление отвергается, и кортеж остается в MovieExec.

4. Попытка изменения кортежа в MovieExec, при котором меняется значение cert#, но при ЭТ0.М старое значение cert# остается значением presC# в Studio. Изменение отвергается, и кортеж остается в прежнем виде.

Правило каскада

Существует и другой подход к выполнению удалений и изменений в отношении, на которое делается ссылка, и назьшается он правилом каскада. Согласно этому правилу для соблюдения ссылочной целостности при удалении из MovieExec кортежа, обозначающего президента студии, система удаляет соответствующие ему кортежи из отношения Studio. Изменения выполняются аналогично. Если cert# администратора ф1и1ьма изменяется с с, на и в Studio есть кортеж со значением с, в компоненте presC#, система изменит это значение на Cj.

Е Висящие кортежи и правила изменений

1 Кортеж со значением внешнего к.чюча, не появляющимся в отношении, 5 на которое делается ссылка, называется висящим кортежем. Кортеж, не участ-I вуюшнм в соединении, тоже называется висящим. Такое совпааение терминов I неслучайно. Если значения внешнего ключа кортежа нет в отношении, на которое делается ссылка, то ои не участвует в соединении этого отношения с отношением, в которое он входит.

Именно висящие кортежи нарушают ссылочную целостность для ограничения по внешнему ключу.

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

Правило каскада состоит в удалении или изменении всех созданных висящих кортежей (в зависимости от удалений или изменений в отношении, на которое делается ссылка).

Правшю установки в NULL заключается в установке значения внешнего ключа в NULL в каждом висящем кортеже.

Пример 6.4. Рассмотрим, как можно изменеть описание отношения

Studio(name, address, presC#)

приведенное в примере 6.3, чтобы можно было проводить удаления и изменения в отношении

Movie Exec(name, address, cert#, netWorth)

Ha рис. 6.3 показано расширение первой из приведенных в примере 6.3 формулировок CREATE TABLE с помощью дополнительных предложений ON DELETE и ON UPDATE.

1) CREATE TABLE Studio (

2) name CHAR(30) PRIMARY KEY.

3) address VARCHAR(255),

4) presC# INT REFERENCES MovieEKec(cert#)

5) ON DELETE SET NULL

6) ON UPDATE CASCADE

pHt. 6.3. Выбор стратегии сохронений референциольной целосгноаи

Правило установки зкачсенил NULL

Третий подход к рассматриваемой проблеме заключается в том, чтобы заменить значение presC#. обозначаюшее удаленного или замененного президента студии, на NULL. Такой подкол получ!Ш название установки NULL

Последние два npawwa применяются для удалений м изменений независимо дру 03 друга и фиксируются и описании внешнего кчюча с помошью ключевых слон ON DELETE или ON UPDATE, за которыми следуют SET NULL или CASCADE.

Строка (5) означает, что при удалении кортежа из MovieExec компонент presC#, относящийся к президент) любой студии, устанавливается в значение NULL. Согласно строке (6), при изменении значения компонента cert# кортежа из MovieExec таким же образом изменяются все кортежи из Studio, имеющие такое же значение вкомпоненте presC#.

Заметим, что в данном примере при удалении лучше применять правило установки в NULL, а прн изменениях - правило каскада. 1Иожно предположить, например, что после ухода президента студия некоторое время будет существовать вообще без президента. Изменение же номера сертификата президента студии, скорее всего, лишь формальное изменение. Человек продолжает существовать и быть президентом студии, поэтому желательно, чтобы такое же изменение было внесено и в атрибут presC# из Studio. □

6.2.3 Упражнения к разделу 6.2

Упрожнение 6.2.1. Опиингге перечисленные ниже ограничения ссылочной целостности для БД фильмов

Movie(title, year, length, inColor, studioName. producerC#) Starsln(movieTitle. movieYear, starName) MovieStar(name, address, gender, birttidate) MovieExec(name, address. cert#. netWorth) . Studio(name, address, presC#)

a) Продюсером фильма должен бьпъ человек, упомянутый в MovieExec. Изменения отношения MovieExec, нарушающие это ограничение, отвергаются.

b) Ограничение то же, что и в пункте (а), но в результате его нарушения значение producerC# в отношении Movie устанавливается в NULL.

c) Ограничение то же, что и в пункте (а), но в результате его нарушения из отношения Movie удаляется кортеж, который вызывает нарушение.

d) Фильм, появляющийся в Starsin, должен появиться и в Movie. При нарушении этого ограничения изменения отвергаются.

e) Кинозвезда, появляющаяся в Starsin, должна появиться и в MovieStar. При нарушении этого ограничения удаляются кортежи, вызывающие нарушение.

Упражнение 6.2.2. Введите ограничение, согласно которому каждый фильм из отношения Movie должен появиться по крайней мере с одной кинозвездой в отношении Starsin. Можно ли это сделать путем ограничения внешним ключом? Обоснуйте свой ответ.

Упражнение 6.2.3. Опишите перечисленные ниже ограничения ссылочной иелостности на основе схемы БД из уттражнения 4.1.3

Classes(class, type, country. numGuns. bore, displacement) Ships(name, class, launched) Battles(name, date) Outcomes(ship, battle, result)