8.8. Ключи

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

Замечание Основная идея понятия ключа достаточно проста, но, к сожалению, имеет место одно существенное затруднение — NULL-значения. Возможность того, что, на­пример, для данного внешнего ключа разрешены NULL-значения, существенно услож­няет дело. Однако проблема NULL-значений представляет собой отдельную обширную тему для обсуждения и было бы нецелесообразно рассматривать ее в настоящий момент. Поэтому по методическим соображениям в настоящем разделе мы практически не Гудем обращать внимания на ее существование. Мы вернемся к ней в главе 18 и рассмотрим проблему NULL-значений в общем случае, в частности рассмотрим, как эти значения влияют на понятие ключа. (На самом деле, по нашему твердому убеждению, понятие NULL-значения является ошибочным и совсем не должно использоваться, но было бы неправильным полностью игнорировать его в подобной книге.)

Потенциальные ключи

Пусть R — некоторая переменная-отношение. По определению множество всех атри­бутов переменной-отношения R обладает свойством уникальности, т е. в любой момент в значении переменной-отношении R никакие два кортежа не дублируют друг друга. На практике же часто некоторое допустимое подмножество множества всех атрибутов пе­ременной-отношения R также обладает подобным свойством уникальности. Например, в переменной-отношении поставщиков S этим свойством обладает подмножество из одно­го атрибута St. Подобные случаи служат основой интуитивного понимания смысла фор­мального определения потенциального ключа.

■ Пусть К — множество атрибутов переменной-отношения R. В этом случае множе­ство К будет потенциальным ключом переменной-отношения R тогда и только тогда, когда оно обладает следующими свойствами⁶.

⁶ Обратите внимание, что определение применяется именно к переменным-отношениям Аналогичное понятие можно определить и для значений отношения (см [3 3]), но переменные-отношения представляют более важный случай

а) Уникальность. Никакие допустимые значения переменной-отношения R не содержат двух различных кортежей с одинаковыми значениями атрибутов множества К.

б) Неизбыточность. Никакое из собственных подмножеств множества К не обла­дает свойством уникальности.

Обратите внимание, что каждая переменная-отношение имеет по крайней мере один потенциальный ключ. Свойство уникальности подобных ключей не требует до­полнительных разъяснений. Относительно свойства неизбыточности следует предос­тавить некоторые пояснения. Суть в том, что если определить "потенциальный ключ", который не будет обладать свойством неизбыточности, системе об этом ничего не бу­дет известно и она не сможет должным образом обеспечить выполнение соответст­вующего ограничения целостности. Пусть, например, мы определили потенциальный ключ отношения поставщиков не как атрибут St, а как комбинацию атрибутов {S#,CITY}. Тогда система не сможет соблюдать ограничение, требующее "глобальной" уникальности номера поставщика; вместо этого в ней будет поддерживаться более слабое ограничение, согласно которому номер поставщика должен быть уникальным в масштабе одного города. По этой причине среди прочих условий требуется, чтобы по­тенциальные ключи не содержали какие-либо атрибуты, которые не имеют отношения к обеспечению его уникальной идентификации⁷.

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

Для описания потенциального ключа в определении переменной-отношения будем использовать следующий синтаксис языка Tutorial D.

KEY { <список имен атрибутов> } Ниже приведено несколько примеров.

■ VAR S BASE RELATION { St St,

SNAME NAME, STATUS INTEGER, CITY CHAR } KEY { St } ;

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

Замечание. В предыдущей главе мы уже приводили это определение с ис­пользованием фразы PRIMARY KEY вместо KEY. Подробности можно найти в подразделе "Первичные и альтернативные ключи", приведенном ниже в этом разделе.

■ VAR SP BASE RELATION

{ SI SI,

Pt Pt,

QTY QTY } KEY { SI, Pt } ... ;

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

■ VAR ELEMENT BASE RELATION {NAME NAME,

SYMBOL CHAR,

ATOMIC! INTEGER } KEY { NAME } KEY { SYMBOL } KEY { ATOMICI } ;

В этом примере показана переменная-отношение с несколькими различными (простыми) потенциальными ключами.

■ VAR MARRIAGE BASE RELATION {HUSBEND /* Муж */ NAME,

WIFE /* Жена */ NAME,

DATE /* Дата бракосочетания */ DATE } /* Подразумевается, что муж может иметь лишь одну жену, а жена */ /* лишь одного мужа, а также, что каждый из супругов состоит в */ /* браке первый раз */

• KEY { HUSBEND, DATE } KEY { DATE, WIFE } KEY { WIFE, HUSBEND } ;

В этом примере показана переменная-отношение с несколькими различными составными (и перекрывающимися) потенциальными ключами.

Конечно, как указывалось в разделе 8.4, определение потенциального ключа, по существу, представляет собой просто сокращенную запись определенного ограниче­ния переменной-отношения. Эта сокращенная запись весьма удобна, поскольку по­нятие потенциального ключа очень важно с практической точки зрения. Говоря кон­кретнее, в реляционной модели потенциальные ключи обеспечивают основной ме­ханизм адресации на уровне кортежей. Это утверждение означает, что единствен­ный гарантируемый системой способ точно указать на какой-то конкретный кортеж состоит в указании значения одного из его потенциальных ключей. Например, с по­мощью приведенного ниже выражения гарантированно будет получено не более од­ного кортежа (точнее, будет получено отношение, состоящее не более чем из одно­го кортежа).

S WHERE Si = St ( 's3' )

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

S WHERE CITY = 'Paris'

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

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

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

Упомянутое выше "нетипичное или аномальное" либо "отличное от типично реляци­онного" поведение чаще всего будет связано с такими процессами, как обновление пред­ставлений и оптимизация (подробности приводятся в главах 9 и 17 соответственно).

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

• Надмножество потенциального ключа является суперключом. Например, мно­жество атрибутов {St,CITY)— это суперключ переменной-отношения S. Су­перключ обладает свойством уникальности, но необязательно -— свойством не­избыточности (поэтому потенциальный ключ, естественно, является частным случаем суперключа).

• Если множество SK является суперключом переменной-отношения R и А — это ат­рибут переменной-отношения R, то функциональная зависимость SK —» А в пере­менной-отношении R является истинной (эта важная концепция подробно будет обсуждаться в главе 10). Фактически суперключ можно определить как подмно­жество SK, состоящее из таких атрибутов переменной-отношения R, что функцио­нальная зависимость SK —> А является истинной для всех атрибутов А перемен­ной-отношения R.

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

Первичные и альтернативные ключи

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

ключи будут называться альтернативными. В приведенном выше в этой главе примере с переменной-отношением ELEMENT в качестве первичного ключа можно выбрать атрибут обозначения элемента {SYMBOL}; тогда атрибут названия элемента {NAME} и атрибут атомного числа элемента {ATOMIC!} будут альтернативными ключами. В том случае, ко­гда в базовой переменной-отношении существует только один потенциальный ключ, со­гласно реляционной модели (опять же, традиционно) именно он должен быть выбран в качестве ее первичного ключа. Следовательно, каждая базовая переменная-отношение всегда должна иметь первичный ключ.

Выбор одного потенциального ключа (если есть из чего выбирать) в качестве первич­ного, определенно, желателен во многих случаях (даже в большинстве случаев), но это не означает, что во всех случаях. Аргументы в пользу этой точки зрения приведены в [8.13]. Здесь же мы просто отметим, что если есть несколько потенциальных ключей, то не имеет существенного значения, какой из них будет выбран в качестве первичного. Приведем цитату из работы Кодда [8.8]: "Обычно обоснования [выбора ключа] доста­точно просты, однако этот вопрос выходит за рамки реляционной модели". Что касается наших собственных примеров, иногда мы первичный ключ определяем, а иногда не оп­ределяем (но мы всегда будем, конечно, определять хотя бы один потенциальный ключ).

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

Если не придерживаться формальностей, то внешний ключ можно определить как мно­жество атрибутов одной переменной-отношения R2, значения которых должны совпадать со значениями некоторого потенциального ключа некоторой другой переменной-отношения R1. Например, рассмотрим множество атрибутов {Si} (состоящее из одного ат­рибута) переменной-отношения SP. Ясно, что каждое значение множества {Si} должно быть допустимым для переменной-отношения SP лишь в том случае, если такое же значе­ние присутствует в качестве значения единственного потенциального ключа {Si} для пе­ременной-отношения S (не имеет смысла описывать поставку несуществующего поставщи­ка). Аналогично заданное значение множества атрибутов {Pi} переменной-отношения SP будет допустимым лишь в том случае, если существует такое же значение единственного потенциального ключа {Pi} переменной-отношения Р (невозможно поставить несущест­вующую деталь). Эти примеры послужат нам обоснованием следующего определения.

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

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

б) каждое значение внешнего ключа FK в текущем значении переменной- отношения R2 обязательно совпадает со значением ключа СК некоторого корте- жа в текущем значении переменной-отношения R1.

Данное определение нуждается в дополнительных пояснениях.

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

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

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

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

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

5. Ссылочные диаграммы. Еще раз обратимся к базе данных поставщиков и деталей. Существующие в этой базе данных ссылочные ограничения можно представить по­средством следующей ссылочной диаграммы.

S < SP > Р

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

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

st Pi s <— SP —> P

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

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

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

r3 > r2 > r1

Удобно будет ввести термин ссылочный путь. Пусть имеются переменные-отношения Rn, R(n-l), R2, R1, такие, что существует ссылочное ограничение из переменной-отношения Rn в переменную-отношение R(n-l), ссылочное ограниче­ние из переменной-отношения R(n-l) в переменную-отношение R(n-2), ... и ссы­лочное ограничение из переменной-отношения R2 в переменную-отношение R1.

Rn > R(n-l) > R(n-2) > ... > R2 > Rl

Тогда цепочка стрелок из Rn в R1 будет представлять ссылочный путь из пере­менной-отношения Rn в переменную-отношение R1.

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

VAR EMP BASE RELATION

{ EMPf EMPI,..., MGR_EMPf EMPl, ... } PRIMARY KEY { EMPf }

FOREIGN KEY { RENAME MGR_EMPf AS EMPl } REFERENCES EMP ;

Здесь атрибут MGR_EMP| представляет номер того служащего, который является ме­неджером для служащего, определяемого значением атрибута EMPt. Например, кортеж для служащего с номером 'е4' в качестве значения атрибута MGR_EMPi мо­жет включать значение 'ЕЗ', которое, по сути, представляет собой ссылку на кор­теж переменной-отношения ЕМР для служащего с номером 'ЕЗ'. (Обратите внима­ние, что в этом примере необходимо переименовать атрибут внешнего ключа, что­бы обеспечить приведенное выше требование из п. 3.) Подобные переменные-отношения иногда называют самоссылающимися.

Упражнение. Придумайте какие-нибудь данные для этого примера.

8. Самоссылающиеся переменные-отношения, подобные переменной-отношению ЕМР в предыдущем примере, на самом деле представляют собой специальный случай более общей ситуации, при которой могут возникать ссылочные циклы. Перемен- ные-отношения Rn, R(n-l), R2, Rl образуют ссылочный цикл, если перемен- ная-отношение Rn содержит внешний ключ, ссылающийся на переменную- отношение R(n-l), переменная-отношение R(n-l) содержит внешний ключ, ссы- лающийся на переменную-отношение R(n-2), и наконец, переменная- отношение R1 содержит внешний ключ, ссылающийся вновь на переменную- отношение Rn. Или более кратко: ссылочный цикл существует, если есть ссылоч- ный путь из некоторой переменной-отношения Rn к самой себе.

Rn > R(n-l) > R(n-2) > ... > R2 » Rl > Rn

9. Соответствие между внешними и потенциальными ключами иногда называют клеем, который объединяет базу данных в единое целое. То же самое можно сказать иначе: такое соответствие представляет собой определенную связь ме-

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

10. Исторически понятие внешнего ключа было определено лишь для базовых пере­менных-отношений — факт, который сам по себе поднимает некоторые вопросы (подробности приводятся при обсуждении принципа взаимозаменяемости в разде­ле 9.2 главы 9). Мы не навязываем здесь подобных ограничений, однако для про­стоты изложения ограничим наше обсуждение лишь базовыми переменными-отношениями (где это не связано с какими-либо различиями).

11. В реляционной модели первоначально требовалось, чтобы внешние ключи ссылались конкретно на первичные ключи, а не просто на потенциальные ключи (например, [8.8]). В общем случае мы отвергаем такое ограничение как излишнее и нежелатель­ное, хотя на практике оно позволяет поддерживать в системе определенный порядок [8.13]. Обычно мы будем следовать такому порядку в наших примерах.

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

■ Ссылочная целостность. База данных не должна содержать значений внешних ключей, не имеющих соответствия⁹.

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

Ниже приведен синтаксис для определения внешнего ключа.

FOREIGN KEY { <список элементов> } REFERENCES <ямя переменной-отношения>

Это предложение должно присутствовать в определении ссылающейся переменной-отношения. Дополнительно отметим следующее.

■ Каждое значение в параметре <список элементов> представляет собой или пара­метр <имя атрибута>, определяющий атрибут ссылочной переменной-отношения, или выражение следующего вида.

Правило ссылочной целостности можно рассматривать как метаограничение. Оно означает, что любая база данных должна быть объектом определенных ограничений целостности, специфи­ческих именно для нее. В совокупности эти ограничения гарантируют, что правило ссылочной цело­стности не будет наругиено в конкретной базе данных. По ходу дела отметим, что в отношении реляционной модели обычно считается, что она включает другое "метаограничение"— правило целостности сущностей. Однако это правило тесно связано с концепцией NULL-значений, поэтому мы отложим его обсуждение до главы 18.

RENAME <имя атрибута> AS <имя атрибута>

(В качестве примера построения предложения RENAME может служить приведенное выше определение самоссылающейся переменной-отношения ЕМР.)

■ Параметр <имя переменной-отношения> идентифицирует ссылочную переменную-отношение.

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

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

Ссылочные операции

Рассмотрим следующий оператор. DELETE S WHERE SI = SI ( 'SI' ) ;

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

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

Однако существует и альтернативный подход, который в определенных случаях может оказаться предпочтительнее. При этом подходе предполагается, что системой выполняются соответствующие компенсирующие операции, гарантирующие, что ко­нечный результат будет удовлетворять существующим ограничениям. В нашем приме­ре очевидной компенсирующей операцией могло бы быть "автоматическое" удаление сведений обо всех поставках поставщика с номером 'S1'. Достичь этого можно, рас­ширив определение внешнего ключа.

VAR SP BASE RELATION { ... } ...

FOREIGN KEY { Si } REFERENCES S

ON DELETE CASCADE ;

Спецификация ON DELETE CASCADE определяет правило удаления для данного кон­кретного ключа, которое будет применяться при обработке операторов DELETE. Здесь спецификация CASCADE определяет тип ссылочной операции для этого правила удаления. Смысл определений состоит в том, что обработка операторов DELETE для переменной-отношения поставщиков должна сопровождаться "каскадным" удалением всех соответ­ствующих кортежей из переменной-отношения поставок.

Другая общепринятая ссылочная операция задается спецификатором RESTRICT (она не имеет ничего общего с операцией выборки (restrict) реляционной алгебры). В данном случае спецификатор RESTRICT указывает, что выполнение операции DELETE допускается, если в переменной-отношении поставок нет ни одного кортежа с соответствующим внешним ключом. В противном случае операция удаления отвергается. Опускание кон­кретного спецификатора ссылочной операции при определении некоторого внешнего ключа равносильно заданию спецификатора NO ACTION (никаких действий), означающе­го, что операция DELETE будет выполняться в точности так, как она описана, и не более того. (Если спецификатор N0 ACTION применить к нашему примеру, то при удалении по­ставщика, для которого имеются сведения о выполняемых им поставках, установленное ограничение ссылочной целостности, безусловно, будет нарушено.) Рассмотрим некото­рые случаи применения ссылочных операций.

1. Операция DELETE — это не единственная операция, для которой имеет смысл опре- деление ссылочных операций. Например, что должно произойти при попытке из- менить номер поставщика, для которого уже имеются сведения хотя бы об одной поставке? Очевидно, что необходимо использовать правило обновления, подобное обсуждавшемуся выше правилу удаления. В общем случае для операции обновле- ния существует тот же набор ссылочных действий, что и для операции удаления.

• CASCADE— "каскадно" распространить операцию обновления посредством об­новления значений всех соответствующих внешних ключей в переменной-отношении поставок.

• RESTRICT — ограничить выполнение операции обновления только теми случая­ми, когда не существует никаких соответствующих поставок. Иначе выполнение операции запрещается.

• N0 ACTION — операция обновления выполняется в точности так, как она записана.

2. Безусловно, спецификаторы CASCADE, RESTRICT и N0 ACTION не следует считать единственно возможными вариантами ссылочных операций. Это минимальный на- бор спецификаторов, отражающий только те варианты действий, которые чаще всего применяются на практике. Однако, в принципе, может существовать произ- вольное количество возможных решений при попытке, например, удалить опреде- ленного поставщика. Укажем некоторые из возможных действий.

• Информация записывается в некоторую архивную базу данных.

• Поставки для одного поставщика передаются другому поставщику.

И т.д. Однако невозможно предоставить декларативный синтаксис для всех мыс­лимых решений. Поэтому в общем случае просто должна существовать возмож­ность указать ссылочные действия в виде выражения CALL ргос{...), где proc — имя процедуры, определяемой пользователем.

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