Внешние ключи и null-значения

Обратимся вновь к базе данных отделов и служащих из главы 3. Предположим, что в компании, представленной этой базой данных, допустимо, чтобы служащий не был причислен ни к одному из отделов. Поэтому в кортеже ЕМР такого служащего нет настоящего номера отдела, который может быть соответствующим значением для внешнего ключа DEPT#.

В качестве другого примера рассмотрим самоссылающееся отношение ЕМР, которое обсуждается выше в этой главе. Каким будет значение атрибута MGR_EMP# для президента компании?

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

Пусть R2 — базовое отношение. Тогда внешний ключ, скажем, FK в отношении R2 — это подмножество множества атрибутов R2, такое что:

■ ■ существует базовое отношение R1 (R1 и R2 не обязательно различны) с потенциальным ключом СК;

■ ■ всегда каждое значение FK в текущем значении R2 или является null-значением, или совпадает со значением СК некоторого кортежа в текущем значении R1.

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

Рассмотрим детальнее.

1. 1. Теперь есть другое правило внешнего ключа (в дополнение к правилам удаления и обновления, рассмотренным выше в этой главе) для обсуждения, а именно правило null-значений, т.е. для каждого внешнего ключа разработчик базы данных должен решить, может или нет внешний ключ использовать null-значения. Необходимо расширить синтаксис определения внешнего ключа следующим образом:

(где параметр null-option может принимать значения ALLOWED (разрешено) или NOT ALLOWED (не разрешено)), чтобы позволить проектировщику записать свое решение.

2. 2. Если данный внешний ключ FK составной и null-значения действительно разрешены, то в этом случае существуют разные мнения относительно того, можно ли разрешать данному значению ключа FK иметь некоторые компоненты равными null, а остальные не равными, или необходимо настаивать на том, чтобы каждое значение составного ключа FK было полностью null-значением или полностью не-пи11-значением. В этой дискуссии мы занимаем вторую (более простую) позицию. (См. [5.4, 5.7], где детально рассматривается эта дискуссия.)

3. 3. И вновь обратимся к вопросу о том, что должно случиться при попытке удалить целевой объект, на который ссылается внешний ключ: например, попытке удалить кортеж поставщика, для которого существует, по крайней мере, одна соответствующая поставка. Для определенности давайте еще раз рассмотрим этот случай подробно. Если для рассматриваемого внешнего ключа, например SP.S#, null-значения разрешены, то имеется и другая возможность для правила удаления (т.е. другое возможное значение в синтаксисе для параметра option), а именно NULLIFIES (аннулировать).

• • В соответствии с опцией NULLIFIES внешний ключ устанавливается равным null для всех соответствующих поставок, а кортеж поставщика затем удаляется.

4. 4. Также еще раз вернемся к вопросу о том, что должно случиться при попытке обновления потенциального ключа, на который ссылается внешний ключ: например, попытке обновить номер поставщика, для которого существует, по крайней мере, одна соответствующая поставка: И этот случай давайте рассмотрим еще раз подробно. Если для рассматриваемого внешнего ключа, например SP.S#, null-значения разрешены, то имеется и другая возможность для правила обновления (т.е. другое возможное значение в синтаксисе для параметра option), а именно NULLIFIES.

• • В соответствии с опцией NULLIFIES внешний ключ устанавливается равным null для всех соответствующих поставок, а кортеж поставщика затем обновляется.

Наша точка зрения

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

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

¹ Точнее, мы получим отношение, состоящее не более чем из одного кортежа

Реляционная алгебра (стр. 142-151)

Глава 6

Реляционные

4.17. операторы:

Date: 2016-05-25; view: 752; Нарушение авторских прав