Главная » SQL, Базы данных » ОТСУТСТВУЮЩИЕ ЗНАЧЕНИЯ И КЛЮЧИ

0

Примечание. Далее вместо термина UNK мы будем использовать более традиционную терминологию, т.е. термин NULL.

Вопреки всему сказанному в предыдущем разделе, на практике неопределенные значения (NULL) и трехзначная логика широко поддерживаются  в большинстве современных программных продуктов. Резонно предположить, что такая поддержка имеет очень важные последствия, особенно в отношении  ключей. Именно это и будет предметом дальнейшего краткого рассмотрения в этом разделе.

Первичные ключи

Как уже отмечалось в разделе 9.10, исторически сложилось так, что в реляционной модели, по крайней мере, в базовых переменных отношения, из всего набора потенциальных ключей в качестве первичного ключа переменной отношения должен быть выбран один (и только один) потенциальный ключ. Все остальные потенциальные ключи (если таковые имеются) считаются альтернативными. Помимо концепции первичного ключа, в эту модель по некоторым историческим причинам входит следующее метаограничение, или правило (правило поддержки целостности сущности).

■  Правило поддержки целостности сущности. Ни один компонент первичного ключа любой базовой переменной отношения не может содержать неопределенные значения (NULL).

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

В связи с этим приведем ряд соображений.

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

2.         Из этого следует вывод, что альтернативные ключи, по-видимому, могут содер жать неопределенные значения (NULL). Но если некий ключ АК является альтер нативным ключом, в котором допускаются неопределенные значения (NULL), то он не может использоваться в качестве первичного ключа, поскольку для него на рушается требование сохранения целостности сущности. Тогда в каком смысле ключ АК является потенциальным? И наоборот, если выдвинуть требование, что альтернативные  ключи также  не  могут содержать  неопределенные  значения (NULL), то правило сохранения целостности сущности будет относиться ко всем потенциальным ключам, а не только к первичным ключам. В любом из этих двух вариантов указанное правило выглядит не вполне приемлемым.

3.         Наконец, отметим, что правило сохранения целостности сущности применимо только для базовых переменных отношения, тогда как другие переменные отноше ния, по-видимому, могут содержать первичные ключи с неопределенными значе ниями (NULL). В качестве тривиального и очевидного примера рассмотрим проек цию переменной отношения R по атрибуту А, в котором допускается присутствие неопределенных значений (NULL). Очевидно, что правило сохранения целостно сти сущности нарушает принцип взаимозаменяемости (для базовых и производных переменных отношения). По мнению автора, это может послужить серьезным до водом для отказа от него (данная концепция будет отвергнута нами независимо от включения неопределенных значений (NULL)).

Теперь допустим, что мы отказались от идеи применять неопределенные  значения (NULL) и для представления недостающей информации вместо них применили специальные значения6  аналогично тому, как это делается в реальном мире (подробные сведения приведены в разделе 19.6). Тогда модифицированная версия правила сохранения целостности сущности будет иметь следующий вид:  "Никакой компонент первичного ключа любой базовой переменной отношения не может содержать подобных специальных значений". Это требование может использоваться как рекомендация, но не является нерушимым законом (так же, как идеи дальнейшей нормализации служат в качестве рекомендаций, а не  строгих законов). На рис. 19.2 приведен пример базовой переменной отношения SURVEY, для которой может потребоваться нарушить эту рекомендацию. В ней  представлены результаты опроса сотрудников о размере их зарплаты, которые включают среднее, максимальное и минимальное значения для группы  сотрудников с

определенным годом рождения. (Здесь атрибут BIRTHYEAR является первичным ключом.) Кортеж со специальным значением "????" атрибута BIRTHYEAR представляет тех служащих, которые отказались ответить на вопрос о годе рождения.

Рис. 19.2. Пример значений данных в базовой переменной отношения SURVEY

Внешние ключи

Еще раз обратимся к базе данных отделов и сотрудников, содержимое которой показано на рис. 19.1. Возможно, вы не обратили на это внимания, однако в свое время автор намеренно не указал, что на данном рисунке атрибут DEPT# переменной отношения ЕМР является внешним ключом. Предположим теперь, что это так. Сразу становится понятно следующее: требуется уточнить формулировку  определения ограничений ссылочной целостности с учетом того, что внешние ключи могут содержать неопределенные значения7  (NULL), а это очевидно  противоречит исходной формулировке данного ограничения, приведенной в главе 9.

■     Ограничение ссылочной целостности (исходная формулировка). База данных не должна содержать никаких несогласованных значений внешних ключей.

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

6  Часто необоснованно называемые значениями, заданными по умолчанию ([19.12]).

7  Следует отметить, что такие неопределенные значения явились бы нарушением указанного прави ла, даже если бы в соответствующей переменной отношения, на которую указывает внешний ключ, был кортеж с неопределенным значением соответствующего потенциального ключа!

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

Из этого следуют приведенные ниже выводы.

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

2.  Возможность присутствия неопределенных значений (NULL) во внешних ключах требует введения нового типа ссылочного действия, SET  NULL, которое можно будет указывать в правиле удаления DELETE или обновления UPDATE при опреде лении внешних ключей, например, следующим образом.

VAR SP BASE RELATION { … } …

FOREIGN KEY { S# } REFERENCES S ON DELETE SET NULL ON UPDATE

SET NULL ;

При использовании этих спецификаций операция DELETE в переменной отношения поставщиков приведет  к помещению  неопределенных значений  (NULL) В  атрибут внешнего ключа всех кортежей с данными о соответствующих поставках, и только после  этого  сведения  об  указанных   поставщиках  будут  удалены.  Аналогичным образом, операция UPDATE для атрибута s# в переменной отношения поставщиков вызовет помещение  неопределенных значений (NULL) в атрибут внешнего ключа всех  кортежей  с  данными  о  соответствующих  поставках,  и  только  после  этого сведения  об  указанных поставщиках будут обновлены. Примечание. Спецификация SET   NULL  может  быть  указана  только  для  тех  внешних  ключей,  в   которых допускается наличие неопределенных значений (NULL). 3. Наконец, следует отметить, что "необходимости" разрешить присутствие  неопределенных  значений (NULL) во внешних ключах вполне можно избежать  за счет соответствующего проектирования базы  данных  [19.19].  Еще  раз  обратимся  к  примеру  с  отделами  и  сотрудниками. Возможна ситуация, когда  некоторые сотрудники действительно не относятся ни к одному из отделов. Но тогда, как уже предполагалось в конце предыдущего раздела, логичнее   было   бы  не  включать  атрибут  номера  отдела  DEPT#  в  переменную отношения  ЕМР,  а  создать  отдельную  переменную  отношения  (скажем)   ED  с атрибутами  ЕМР#  и  DEPT#,  предназначенную  для  представления  того  факта,  что указанный  сотрудник  работает  в  данном  отделе.  Если  некоторый  сотрудник  не относится  ни  к  одному  отделу,  ситуацию  легко  можно  представить,  не  включая кортеж для этого сотрудника из переменной отношения ED.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии