Дейт К. Введение в системы баз данных

Подождите немного. Документ загружается.

ссылающимся, как в случае отношения R2 в следующей диаграмме:

Удобно ввести термин "ссылочный путь". Пусть отношения Rn, R(n-1), ..., R2,

R1 такие, что имеется ссылочное ограничение из Rn в R(n-1), ссылочное

ограничение из R(n-1) в R(n-2),... и ссылочное ограничение из R2 в R1:

Тогда цепочка стрелок из Rn в R1 представляет ссылочный путь из Rn в R1

9. 9.BBBBBB Заметьте, что отношения R1 и R2 в определении внешних ключей не

обязательно различны, т.е. некоторое отношение может включать внешний

ключ, значения которого должны соответствовать значениям некоторых

потенциальных ключей в том же отношении. В качестве примера рассмотрим

следующее отношение:

В этом отношении атрибут MGR_EMP# представляет номер служащего для

менеджера, который идентифицируется атрибутом ЕМР# как служащий. Здесь

ЕМР# — первичный ключ, a MGR_EMP# — внешний ключ, который ссылается на

этот первичный. (Например, кортеж для служащего Е4 может включать значение

MGR_EMP# кортежа ЕЗ, который представляет ссылку к кортежу ЕМР для

служащего ЕЗ. Ниже будет разъяснена конструкция RENAME.) Такие отношения

иногда называют самоссылающимися.

10. 10.BB Самоссылающиеся отношения, такие как отношение ЕМР в предыдущем

примере, в действительности представляют собой специальный случай более

общей ситуации, когда могут возникать ссылочные циклы. Отношения Rn, R(n-

1),..., R2, R1 образуют ссылочный цикл, если отношение Rn включает внешний

ключ, ссылающийся на R(n-1), отношение R(n-1) включает внешний ключ,

ссылающийся на R(n-2), ... и наконец, отношение R1 включает внешний ключ,

ссылающийся вновь на Rn. Или более кратко: ссылочный цикл существует, если

есть ссылочный путь из некоторого отношения Rn к себе:

11. 11.BB Соответствие внешний к потенциальному ключу иногда называют "клеем",

который удерживает базу данных как единое целое. То же самое можно сказать и

иначе: такое соответствие представляет собой некоторое отношение или

взаимосвязь между кортежами. Однако обратите внимание, что не все

отношения представлены этими соответствиями. Например, есть, отношение

между размещенными в одном городе поставщиками и деталями,

представленное атрибутами CITY отношений S и Р. Однако такие атрибуты

CITY не являются внешними ключами. Они могли бы стать внешними

ключами, если бы в базу данных было добавлено отношение с атрибутом CITY

как потенциальным ключом.

Вот синтаксис для указания внешнего ключа (обратите внимание, что данный

оператор CREATE BASE RELATION может включать нуль или более определений

внешних ключей):

FOREIGN KEY (element-commalist) REFERENCES base-relation

Синтаксис категории element здесь представлен или именем атрибута

базового отношения, содержащего его (обычный случай), или выражением вида

RENAME attribute AS attribute

Здесь первый параметр attribute является именем атрибута содержащего

его отношения, а второй параметр attribute представляет собой новое имя для

такого атрибута, который реально заменяет первое имя при работе с данным

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

совпадать с множеством имен атрибутов для некоторого потенциального ключа

базового отношения, указанного после оператора REERENCES. Некоторые примеры

можно найти на рис. 3.9 или 4.3 (простой случай); также смотрите выше пример

внешнего ключа MGR_EMP# (случай с использованием оператора RENAME).

Дальнейшее обсуждение применения оператора rename будет приведено в

следующих главах книги.

Ссылочная целостность

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

правило (правило ссылочной целостности):

■ ■BBBBBBB Ссылочная целостность.

База данных не должна содержать несогласованных значений внешних ключей.

Здесь "несогласованное значение внешнего ключа" — это значение внешнего

ключа, для которого не существует отвечающего ему значения соответствующего

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

правило утверждает, что если В ссылается на А, тогда А должно существовать.

И наконец, отметим, что понятия "внешний ключ" и "ссылочная целостность"

определены в терминах друг друга. То есть невозможно объяснить, что такое

внешний ключ, без упоминания понятия ссылочной целостности (по крайней мере,

неявным образом), и точно так же невозможно объяснить, что такое ссылочная

целостность, без упоминания понятия внешнего ключа (опять-таки, по крайней

мере, неявным образом). Таким образом, понятия "поддержка ссылочной

целостности" и "поддержка внешних ключей" означают в точности одно и то же.

5. 5.5. Правила внешних ключей

Правило целостности, сформулированное в предыдущем разделе, выражено

исключительно в терминах состояний базы данных. Любое состояние базы данных,

не удовлетворяющее этому правилу, некорректно; но как избежать таких

некорректных состояний? В самом правиле об этом не говорится.

Одна из возможностей состоит в том, чтобы просто запретить любые операции,

приводящие к некорректному состоянию. Однако в некоторых случаях

предпочтительнее допустить такую операцию, но при необходимости выполнить

некоторые компенсирующие операции, чтобы гарантировать, что в результате

система останется в корректном состоянии. Например, если пользователь пытается

удалить поставщика S1 из отношения S, система сама может удалить поставки

поставщика S1 из отношения SP без каких-либо последующих действий со стороны

пользователя (предполагается, конечно, что требовалось получить именно такой

результат "каскадного удаления").

Следовательно, для этой базы данных у пользователя (или в этом контексте у

разработчика базы данных) должна быть возможность определить, какие операции

должны быть запрещены, а какие разрешены, нужны ли для разрешенных операций

компенсирующие, и если да, то какие. Поэтому мы кратко обсудим эту возможность

в настоящем разделе. Однако заметьте, что при этом мы выходим за рамки

обсуждения самой реляционной модели.

Основная идея состоит в следующем. Для каждого внешнего ключа

необходимо ответить на два важных вопроса.

1. 1.BBBBBB Что должно случиться при попытке удалить объект ссылки внешнего ключа?

Например, удалить поставщика, для которого есть, по крайней мере, одна

поставка. Для определенности рассмотрим именно этот случай. В общем

существует по меньшей мере две возможности: ,

• •BBBBB ОГРАНИЧИТЬ — "ограничить" операцию удаления, до момента, когда не

будет существовать соответствующих поставок (в противном случае операция

запрещается);

• •BBBBB КАСКАДИРОВАТЬ — "каскадировать" операцию удаления, удаляя также

соответствующие поставки.

2. 2.BBBBBB Что должно случиться при попытке обновить потенциальный ключ, на

который ссылается внешний ключ? Например, при попытке обновить номер

поставщика, для которого существует, по крайней мере, одна соответствующая

поставка. И вновь рассмотрим именно этот случай для определенности. Как и

для удаления здесь существует по меньшей мере две возможности:

• •BBBBB • ОГРАНИЧИТЬ — "ограничить" операцию обновления до момента, когда

не будет существовать соответствующих поставок (в противном случае

операция запрещается);

• •BBBBB • КАСКАДИРОВАТЬ — "каскадировать" операцию обновления, обновляя

также внешний ключ в соответствующих поставках.

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

базы данных должен не только указать атрибут или комбинацию атрибутов,

составляющую данный внешний ключ в соответствующем целевом отношении, но и

ответить на указанные выше вопросы (т.е. указать специальные правила внешних

ключей для данного внешнего ключа). Поэтому нам необходимо расширить

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

Здесь параметр option может принимать значение RESTRICTED (ограничить)

или CASCADES (каскадировать). В связи с этим возникают следующие вопросы.

1. 1.BBBBBB Конечно, опции RESTRICTED и CASCADES для правил удаления и

обновления внешнего ключа не ограничивают возможности: они лишь

представляют два случая, которые обычно используются на практике. А в

принципе может быть любое количество возможностей при попытке удаления

определенного поставщика. Например:

• •BBBBBBBBBB может быть инициирован диалог с конечным пользователем;

• •BBBBBBBBBB информация может быть занесена в некоторую архивную базу данных;

• •BBBBBBBBBB поставки удаляемого поставщика могут быть приписаны какому-либо

другому поставщику.

Конечно, дать названия всем возможным действиям нереально. Поэтому в

общем случае параметр option в нашем синтаксисе должен включать возможность

вызова определенной при установке процедуры баз данных (иногда называемой

"хранимой процедурой" или "процедурой триггеров").

2. 2.BBBBBB Пусть R1 и R2 — соответственно ссылающееся и ссылочное отношение (R2

®R1).

И пусть для этого ссылочного ограничения установлено правило каскадного

удаления, т.е. удаление данного кортежа из отношения R1 повлечет удаление

определенных кортежей отношения R2 (в общем случае). Теперь предположим, что

на отношение R2, в свою очередь, ссылается некоторое отношение R3:

Тогда неявное удаление кортежей отношения R2 рассматривается как попытка

удалить эти кортежи непосредственно; т.е. оно зависит от правила удаления,

определенного для ссылочного ограничения из R3 к R2. Если это неявное удаление

не выполняется (согласно правилу удаления для ссылочной зависимости R3 от R2

или по другой причине), то не выполняется и вся операция, и база данных остается

неизмененной. И так далее рекурсивно для любого количества уровней.

Аналогичные замечания можно сделать также относительно правила

каскадного обновления с необходимыми изменениями, если внешний ключ в

отношении R2 имеет какие-либо совместные атрибуты с потенциальным ключом

того отношения, на которое ссылается внешний ключ в отношении R3.

Из сказанного выше следует, что с логической точки зрения операции

обновления базы данных всегда атомарны (все или ничего), даже если под

прикрытием они выполняют несколько обновлений нескольких отношений

вследствие, например, правила каскадного удаления.

3. 3.BBBBBB То обстоятельство, что могут возникать ссылочные циклы, вероятно,

означает, что некоторые проверки ограничений не могут быть выполнены во

время отдельного обновления, а вместо этого должны быть отложены на более

позднее время, например на время фиксации (эта тема выходит за рамки данной

части). В противном случае не будет возможности вставить кортеж в базу

данных.

6. 5.6. Null-значения

Сейчас мы объяснили основные идеи, лежащие в основе понятий

потенциальных и внешних ключей в реляционной модели. К сожалению,

существует один главный усложняющий фактор, который мы умышленно

игнорировали до сих пор, — null-значения.

Тема null-значений представляет собой самостоятельный весьма обширный

предмет обсуждения, она будет рассматриваться в следующих частях книги. Но,

чтобы объяснить роль null-значений для целостности в реляционной модели,

очевидно, необходимо сначала немного рассказать о null-значениях вообще.

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

Когда говорят о null-значениях, то в основном подразумевают базис,

используемый при решении проблемы отсутствующей информации. Эта проблема

наиболее часто встречается в реальной жизни. Например, в исторических записях

иногда встречаются такие, как "Дата рождения неизвестна"; в повестке дня собрания

часто докладчик указан, как "Будет объявлен"; полицейские доклады могут

включать такие записи, как "В настоящее время местонахождение неизвестно".

Следовательно, необходимо иметь некоторый подход, когда сталкиваешься с такими

ситуациями в формальных системах баз данных.

В [5.1] Коддом был предложен подход к этой проблеме, в котором для

представления отсутствующей информации используются специальные маркеры,

называемые null-значениями. Идея заключается в следующем: если данный кортеж

имеет null-значение в данной позиции атрибута, то это означает, что в таком

кортеже значение атрибута по некоторой причине отсутствует. Например, кортеж

поставки может иметь null QTY (количество) — нам известно, что поставка

существует, но неизвестно количество отгружаемого; или деталь может иметь

COLOR (цвет) null — возможно, покраска не применяется для некоторых видов

деталей или не имеет значения. Обратите внимание, null-значения — это не то же

самое, что пробелы или числовые нули; фактически они вообще не являются

реальными значениями в обычном смысле этого, термина, поэтому мы и назвали их

"маркерами" (и поэтому, между прочим, общепринятый термин "нулевое значение"

резко осуждается).

В общем, для данного атрибута может быть разрешено или не разрешено

содержать null-значения; это будет зависеть от определения данного атрибута, по

крайней мере, для базовых отношений. (Иначе говоря, синтаксис "определения

атрибута" в операторе create base relation должен быть расширен для включения

спецификации вида nulls allowed (null – значения допустимы) или nulls not allowed

(null-значения не допустимы)). Если данному атрибуту не разрешено содержать null-

значения, система будет отвергать любые попытки ввода null-значения в эту

позицию.

Как уже отмечалось, мы не намерены рассматривать здесь содержание понятия

null-значений во всех деталях. Но хотелось бы внести ясность: по нашему мнению,

null-значения — и целая теория трехзначной логики, на которой они базируются, —

являются фундаментальным заблуждением и не должны иметь места в чистой

формальной системе, такой какой подразумевается реляционная модель. На самом

деле, мы считаем, что: а) проблема отсутствия информации еще не до конца

осмыслена; б) в настоящее время не известно ни одного полного

удовлетворительного решения проблемы; в) включение null-значений или любых

других подобных свойств в модель на сегодняшний день преждевременно. Но

нужно также подчеркнуть, что другие авторы полагают совсем противоположное: в

частности, Кодд фактически рассматривает null-значения как неотъемлемую часть

реляционной модели [4.4].

Как бы то ни было, давайте возвратимся к главной теме нашего обсуждения и

рассмотрим влияние null-значений на концепции потенциальных и внешних ключей,

которые описывались ранее.

7. 5.7. Потенциальные ключи и null-значения

Как разъяснялось выше в этой главе, реляционная модель традиционно требует,

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

данного отношения был выбран ровно один потенциальный ключ, а оставшиеся

ключи, если они есть, были бы тогда альтернативными ключами. Вместе с

понятием первичного ключа модель включает правило целостности объектов:

■ ■BBBBBBB Целостность объектов. Ни один элемент первичного ключа базового

отношения не может быть null-значением.

Другими словами, определение каждого атрибута первичного ключа любого

базового отношения должно явно или неявно включать спецификацию null not

allowed.

Это правило объясняется следующим:

■ ■BBBBBBB Базовые отношения, точнее, кортежи базовых отношений соответствуют

объектам в реальном мире. Например, базовое отношение S соответствует

реальным поставщикам.

■ ■BBBBBBB По определению объекты реального мира различимы, т.е. они некоторым

образом опознаваемы.

■ ■BBBBBBB Поэтому соответствующие представления объектов в базе данных также

должны быть различимы (опознаваемы).

■ ■BBBBBBB В реляционной модели первичные ключи выполняют функцию уникальной

идентификации (т.е. служат для представления необходимых идентификаторов

объектов).

■ ■BBBBBBB Поэтому в качестве примера предположим, что базовое отношение S

включает кортеж, для которого значение $# является null-значением. Тогда

можно сказать, что есть реальный поставщик, который не имеет идентичности

(по крайней мере, идентичность его не установлена).

■ ■BBBBBBB Более того, что такое null-значение означает? Если это означает, что

"свойство не применяется", то, очевидно, такой кортеж не имеет смысла; как

разъяснялось выше, объекты должны обладать идентичностью, следовательно,

свойство должно применяться. Если это означает "неизвестное значение", то

количество всевозможных проблем возрастет. Например, мы сейчас еще даже не

знаем (в общем), представляет ли кортеж одного из поставщиков, о котором мы

знаем (поскольку неизвестно, что значит "не знаем"!): Таким образом, например,

на вопрос: "Сколько имеется поставщиков?"— следует ответ: "Не знаем".

■ ■BBBBBBB Точно такие же аргументы применимы и ко всем остальным возможным

интерпретациям null-значения. На самом деле объект с отсутствующей

идентичностью является противоречием, Которое выражается так: "Объект,

который не имеет идентичности, не существует" (поэтому правило и называется

правилом "целостности объекта").

■ ■BBBBBBB Аргументы, аналогичные предыдущим, могут использоваться для

демонстрации того, что в базовом отношении с составным .первичным ключом

значения первичного ключа, которые являются частично null-значениями,

должны быть также запрещены.

■ ■BBBBBBB Подытожим: если реальный объект настолько важен, что требуется его явное

представление в базе данных, то этот объект должен быть определенно и

недвусмысленно идентифицируемым, в противном случае какие бы то ни было

разумные рассуждения о нем не возможны. Поэтому правило целостности

объектов иногда формулируют в следующей форме:

В реляционной базе данных мы никогда не записываем информацию о чем-то,

чего мы не можем идентифицировать.

Мимоходом отметим общепринятое, но ошибочное мнение, что правило

целостности объектов гласит нечто в духе: "Первичные ключи должны быть

уникальны". Это не так. Уникальность первичных ключей требуется в части

основного определения понятия первичных ключей как таковых. Правило же

целостности объектов гласит (повторяем), что первичные ключи в базовых

отношениях не должны содержать ни одного null-значения.

Теперь давайте поближе рассмотрим это правило. Поскольку оно использует не

одно, а два понятия — первичные ключи и null-значения, в которых мы нашли

нечто, подвергаемое сомнению. Здесь необходимо сделать еще несколько

замечаний.

■ ■BBBBBBB Это правило применяется только для базовых отношений. Другие отношения

действительно могут иметь первичный ключ, для которого null-значения

допустимы. Приведем простой пример. Предположим, что для цвета детали

"допустимы null-значения" и что в отношении Р есть дополнительный кортеж,

скажем, для детали Р7, в котором атрибут COLOR (цвет) на самом деле является

null-значением. Теперь рассмотрим отношение, представляющее собой результат

запроса "Список всех цветов деталей". Такое отношение просто имеет один

атрибут, который является потенциальным ключом и, следовательно, первичным

ключом, а один из кортежей отношения имеет null-значение в области

первичного ключа. Таким образом, правило целостности объектов предполагает

неприятт ное (и совершенно неоправданное) разграничение между базовыми и

другими отношениями. Что случится, если мы, например, попытаемся сохранить

результат запроса "Список всех цветов деталей" как новое базовое отношение?

■ ■BBBBBBB Это правило применяется только для первичных ключей. Для

альтернативных ключей null-значения могут быть запрещены или разрешены.

Но если альтернативный ключ является таким, для которого разрешены null-

значения, то он не может быть выбран в качестве первичного ключа по правилу

целостности объектов. Так каков же точный смысл выражения, что

альтернативный ключ является "потенциальным" ключом в первую очередь? И

наоборот, если мы говорим, что альтернативные ключи также не должны иметь

null-значений, тогда правило целостности объектов должно относиться ко всем

потенциальным ключам — а не только к первичному ключу.

■ ■BBBBBBB В действительности объяснение правила целостности объектов, данное

выше, применимо в равной мере к каждому атрибуту всех базовых отношений,

а следовательно, null-значения должны быть запрещены везде! Так для чего же

предназначены null-значения?

■ ■BBBBBBB Относительно понятия первичных ключей в [5.2] было предложено

запретить ссылаться к первичным ключам, которым разрешены null-значения,

именно как к первичным ключам, а ссылаться лишь как к "слабым

идентификаторам". Другими словами, некоторые отношения не будут иметь

собственного уникального идентификатора совсем. По нашему мнению, в этом

нет ничего страшного, но весьма сомнительно поддерживать заведомо

подозрительную позицию. Более того, в [4.4] автор настаивает на требовании,

чтобы кортежи, которые в каждой позиции атрибута ничего кроме null-значений

не содержат, "мягко и неожиданно исчезли", что кажется еще более

подозрительным.

■ ■BBBBBBB Предположим, что мы полностью отказались от идеи null-значений и вместо

представления отсутствующей информации используем значения по умолчанию

(т.е. так, как мы поступаем на практике). Например, если зарплата служащего

Джо не известна по некоторым причинам, мы можем представить это в базе

данных с помощью значения -1 (обсуждение этого вопроса приводится в

дальнейших главах книги). Тогда правило целостности объекта не имело бы

больше никакого значения и могло бы быть отброшено безо всякого ущерба.

Замечание. Мы, возможно, захотим сохранить измененную версию этого

правила "Никаким первичным ключам базовых отношений не разрешается

принимать значения по умолчанию" в качестве генеральной линии, а не как

нерушимое правило (почти так же, как идея дальнейшей нормализации служит

генеральной линией, а не является нерушимым правилом). На рис. 5.1 приведен

пример отношения, называемого SURVEY (отчет), для которого мы вполне можем

пожелать нарушить эту генеральную линию; этот пример представляет результаты

отчета по зарплате, показывающего среднюю, максимальную и минимальную

зарплаты по годам рождения для определенной категории населения (BIRTHYEAR

(год рождения) служит первичным ключом). А кортеж со значением года рождения

по умолчанию ("????") представляет людей, которые уклонились от ответа на вопрос

"Когда вы родились?".

8. 5.8. Внешние ключи и null-значения

Обратимся вновь к базе данных отделов и служащих из главы 3. Предположим,

что в компании, представленной этой базой данных, допустимо, чтобы служащий не

был причислен ни к одному из отделов. Поэтому в кортеже ЕМР такого служащего

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

для внешнего ключа DEPT#.

В качестве другого примера рассмотрим самоссылающееся отношение ЕМР,

которое обсуждается выше в этой главе. Каким будет значение атрибута

MGR_EMP# для президента компании?

Для решения вопросов, подобных приведенным в предыдущих примерах,

реляционная модель традиционно разрешает появление null-значений в позициях

внешних ключей. (Заслуживает внимания, между прочим, то, что эти null-значения

подходят для представления атрибутов типа "значение не существует", а не

"значение неизвестно".) Поэтому приведенное выше определение внешнего ключа

требует некоторой небольшой доработки с учетом следующего дополнения (которое

выделено жирным шрифтом).

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

R2 — это подмножество множества атрибутов R2, такое что:

■ ■BBBBBBB существует базовое отношение R1 (R1 и R2 не обязательно различны) с

потенциальным ключом СК;

■ ■BBBBBBB всегда каждое значение FK в текущем значении R2 или является null-

значением, или совпадает со значением СК некоторого кортежа в текущем

значении R1.

Правило ссылочной целостности "База данных не должна содержать никаких не

соответствующих значений внешних ключей" остается неизменным, но значение

выражения "не соответствующих значений внешних ключей" расширено до ссылки

к не-null-значению внешнего ключа, для которого не существует адекватного

значения соответствующего потенциального ключа в соответствующем целевом

отношении.

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

1. 1.BBBBBB Теперь есть другое правило внешнего ключа (в дополнение к правилам

удаления и обновления, рассмотренным выше в этой главе) для обсуждения, а

именно правило null-значений, т.е. для каждого внешнего ключа разработчик

базы данных должен решить, может или нет внешний ключ использовать null-

значения. Необходимо расширить синтаксис определения внешнего ключа

следующим образом:

(где параметр null-option может принимать значения ALLOWED (разрешено) или

NOT ALLOWED (не разрешено)), чтобы позволить проектировщику записать свое

решение.

2. 2.BBBBBB Если данный внешний ключ FK составной и null-значения действительно

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

можно ли разрешать данному значению ключа FK иметь некоторые компоненты

равными null, а остальные не равными, или необходимо настаивать на том,

чтобы каждое значение составного ключа FK было полностью null-значением

или полностью не-пи11-значением. В этой дискуссии мы занимаем вторую

(более простую) позицию. (См. [5.4, 5.7], где детально рассматривается эта

дискуссия.)

3. 3.BBBBBB И вновь обратимся к вопросу о том, что должно случиться при попытке

удалить целевой объект, на который ссылается внешний ключ: например,

попытке удалить кортеж поставщика, для которого существует, по крайней мере,

одна соответствующая поставка. Для определенности давайте еще раз

рассмотрим этот случай подробно. Если для рассматриваемого внешнего ключа,

например SP.S#, null-значения разрешены, то имеется и другая возможность для

правила удаления (т.е. другое возможное значение в синтаксисе для параметра

option), а именно NULLIFIES (аннулировать).

• •BBBBB В соответствии с опцией NULLIFIES внешний ключ устанавливается

равным null для всех соответствующих поставок, а кортеж поставщика затем

удаляется.

4. 4.BBBBBB Также еще раз вернемся к вопросу о том, что должно случиться при попытке

обновления потенциального ключа, на который ссылается внешний ключ:

например, попытке обновить номер поставщика, для которого существует, по

крайней мере, одна соответствующая поставка: И этот случай давайте

рассмотрим еще раз подробно. Если для рассматриваемого внешнего ключа,

например SP.S#, null-значения разрешены, то имеется и другая возможность для

правила обновления (т.е. другое возможное значение в синтаксисе для параметра

option), а именно NULLIFIES.

• •BBBBB В соответствии с опцией NULLIFIES внешний ключ устанавливается

равным null для всех соответствующих поставок, а кортеж поставщика затем

обновляется.

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

Наше общее мнение состоит в том, что null-значения не желательны и не стоит

разрушать всю реляционную модель просто из-за того, что иногда соответствующий

целевой кортеж не существует для некоторого определенного внешнего ключа (т.е.

для некоторого внешнего ключа неизбежно должны быть разрешены null-значения).

(В следующих главах мы объясним, почему, по нашему мнению, null-значения

"разрушают модель".)

Поэтому предположим, как предлагалось ранее, что мы решили отвергнуть

идею null-значений, а вместо этого используем значения по умолчанию для

представления отсутствующей информации. Тогда, очевидно, можно создать

"целевой кортеж по умолчанию" со значениями по умолчанию для

соответствующего потенциального ключа и при необходимости использовать эти же

значения (вместо null-значений) для соответствующих внешних ключей. Этот

подход не очень элегантен, но он имеет существенное преимущество, поскольку не

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

специального указания мы будем игнорировать все аспекты поддержки null-

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

возможность иметь null-значения.

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

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