Правила внешних ключей

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

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

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

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

1. 1. Что должно случиться при попытке удалить объект ссылки внешнего ключа? Например, удалить поставщика, для которого есть, по крайней мере, одна поставка. Для определенности рассмотрим именно этот случай. В общем существует по меньшей мере две возможности:,

• • ОГРАНИЧИТЬ — "ограничить" операцию удаления, до момента, когда не будет существовать соответствующих поставок (в противном случае операция запрещается);

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

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

• • • ОГРАНИЧИТЬ — "ограничить" операцию обновления до момента, когда не будет существовать соответствующих поставок (в противном случае операция запрещается);

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

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

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

1. 1. Конечно, опции RESTRICTED и CASCADES для правил удаления и обновления внешнего ключа не ограничивают возможности: они лишь представляют два случая, которые обычно используются на практике. А в принципе может быть любое количество возможностей при попытке удаления определенного поставщика. Например:

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

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

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

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

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

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

Тогда неявное удаление кортежей отношения R2 рассматривается как попытка удалить эти кортежи непосредственно; т.е. оно зависит от правила удаления, определенного для ссылочного ограничения из R3 к R2. Если это неявное удаление не выполняется (согласно правилу удаления для ссылочной зависимости R3 от R2 или по другой причине), то не выполняется и вся операция, и база данных остается неизмененной. И так далее рекурсивно для любого количества уровней.

Аналогичные замечания можно сделать также относительно правила каскадного обновления с необходимыми изменениями, если внешний ключ в отношении R2 имеет какие-либо совместные атрибуты с потенциальным ключом того отношения, на которое ссылается внешний ключ в отношении R3.

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

3. 3. То обстоятельство, что могут возникать ссылочные циклы, вероятно, означает, что некоторые проверки ограничений не могут быть выполнены во время отдельного обновления, а вместо этого должны быть отложены на более позднее время, например на время фиксации (эта тема выходит за рамки данной части). В противном случае не будет возможности вставить кортеж в базу данных.

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-значений на концепции потенциальных и внешних ключей, которые описывались ранее.