    Глава 5 

    Целостность реляционных данных: потенциальные ключи и другие аспекты 

    5.1. Введение 

    Часть реляционной модели, связанная с целостностью данных, с годами 
подвергалась наибольшему изменению. Причина такого положения, несомненно, 
кроется в том, что эта часть модели, скажем прямо, имеет наименее твердую 
научную основу по сравнению с другими частями. Именно в этой области несколько 
раз изменялись некоторые основные определения, а некоторые аспекты отдельных 
версий этих определений имели догматический, а не логический характер. В этой 
главе даются определения и пояснения, которые в данный момент мы считаем 
предпочтительными; и вообще, мы старались представить материал так, как сочли 
необходимым во время написания книги. Там, где есть особенно серьезные 
отклонения от более ранних определений и описаний, мы даем некоторые замечания 
относительно этих изменений и их причин. 
    Начав с такой необычной преамбулы, продолжим в том же духе. Сначала 
немного философии. 
    1. В любой момент времени любая база данных содержит некую определенную 
конфигурацию значений данных, и, конечно, предполагается, что эта конфигурация 
"отражает действительность", т.е. является моделью или представлением части 
реального мира. 
    2. Просто определенная конфигурация значений не имеет смысла, если 
значения в этой конфигурации не представляют определенного состояния реального 
мира. Например, конфигурация для базы данных поставщиков и деталей, которая в 
отношении Р содержала бы кортеж "деталь Р7 весит минус 25 фунтов", наверное, 
не имела бы смысла, поскольку вес не может быть отрицательным в реальном мире. 
    3. Следовательно, определение базы данных нуждается в расширении, 
включающем правила целостности, назначение которых в том, чтобы информировать 
СУБД о разного рода ограничениях реального мира (таких как ограничение на вес 
детали, который не может быть отрицательным), а значит, и предотвращать 
появление таких недопустимых конфигураций значений. В примере с весом детали, 
конечно, все СУБД должны контролировать операции INSERT и UPDATE на отношении 
Р, а также отказывать в выполнении операции, если в ней проводится попытка 
ввести отрицательное значение атрибута веса. 
    Большинство баз данных подчиняется очень многим правилам целостности, и 
это важно понимать. Например, список правил для поставщиков и деталей мог бы 
легко включить следующие правила: 
    • номера поставщиков должны быть в форме Snnnn, где гтпп может принимать 
значение до четырех десятичных цифр; 
    • номера деталей должны быть в форме Рппппп, где ппппп может принимать 
значение до пяти десятичных цифр; 
    • значение статуса поставщика должно быть в диапазоне 1-100; 
    • города поставщиков и деталей должны выбираться из определенного списка; 

    Глава 5. Целостность реляционных данных... 107 

    •  цвета деталей должны выбираться из определенного списка; 
    •   вес деталей должен быть больше нуля; 
    •  количество при отправке должно быть умножено на 100; 
    •  все красные детали должны сдаваться на хранение в Лондоне; 
    •  если город поставщика — Лондон, то статус поставщика должен быть равен 
20; и т.д. 
    Любое данное правило целостности является специфическим для базы данных в 
' том смысле, что оно применяется к одной конкретной базе данных, и все 
вышеприведенные примеры в этом смысле, очевидно, тоже специфичны для 
определенной базы данных. Однако в дополнение к специфическим правилам 
(которые кратко рассматриваются в следующей главе и подробно будут описаны 
далее в этой книге) в реляционной модели есть два общих особых правила 
целостности. Эти особые правила применяются к любой базе данных, а не только к 
некоторым определенным, таким как базы данных поставщиков и деталей. Эти два 
особых правила относятся к потенциальным (и первичным) ключам и ко внешним 
ключам. Потенциальные и внешние ключи будут рассмотрены ниже в этой главе. 
    Хотя основная идея потенциальных и внешних ключей довольно проста, 
имеется, к сожалению, один осложняющий дело фактор — это null-значения 
(неопределенные значения). Возможность того, что данный внешний ключ может 
допускать null-значения, портит всю картину. Из педагогических соображений при 
изложении материала вначале мы не будем касаться null-значений, а рассмотрим 
их влияние позже в этой главе. 
    Прежде чем углубиться в детали, необходимо сделать еще одно замечание. 
Правила целостности будут рассматриваться главным образом с точки зрения их 
применения к базовым отношениям. Причина, конечно, в том, что именно базовые 
отношения должны отражать действительность, а значит, именно для базовых 
отношений необходимы ограничения по содержанию верной или, по крайней мере 
правдоподобной, конфигурации значений. Однако на самом деле к производным 
отношениям также применяются правила целостности. Например, если к базовому 
отношению S применимо правило, гласящее, что номер поставщика должен быть 
уникальным, это правило, очевидно, также применимо к каждой выборке строк 
этого отношения. 
    Как видно из этого примера, производными отношениями автоматически 
наследуются определенные правила целостности отношений, от которых они 
произведены. Но возможно, что для производных отношений существуют некоторые 
дополнительные правила целостности, противоречащие или дополняющие 
автоматически наследуемые правила. А значит, может возникнуть необходимость 
указать все правила целостности для определенных производных отношений в явном 
виде. Примером тому может служить определение потенциального ключа для представления. 
    Этот вопрос еще будет обсуждаться в последующих главах. В этой главе мы 
ограничимся лишь базовыми отношениями, потому что после их освоения можно 
перейти и к другому материалу. Но если вы не справитесь с базовыми 
отношениями, то обо всем остальном нечего и думать. 

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

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

    108 Часть II. Реляционная модель 

    1.  Свойством уникальности. 
    Нет двух различных кортежей в отношении R с одинаковым значением К. 
1.  Свойством неизбыточности. 
    Никакое из подмножеств К не обладает свойством уникальности. 
    Обратите внимание, что (как было указано в главе 4) каждое отношение 
имеет, по крайней мере, один потенциальный ключ, так как не содержит 
одинаковых кортежей; г.е. поскольку кортежи уникальны, то, по крайней мере, 
комбинация всех атрибутов обладает свойством уникальности и поэтому возможны 
два варианта. 
    • Либо эта комбинация обладает свойством неизбыточности, а значит, будет 
потенциальным ключом (на самом деле единственным потенциальным ключом). 
    • Либо существует по крайней мере одно подходящее подмножество этой 
комбинации, заведомо обладающее свойством уникальности и к тому же обладающее 
свойством неизбыточности. 
    (Обсуждение свойства неизбыточности смотрите ниже.) На практике вместо 
необходимости использовать все атрибуты, как правило, подходит некоторая 
меньшая комбинация. Конечно, возможно отношение, в котором единственным 
потенциальным ключом будет комбинация всех атрибутов, т.е. отношение будет 
"сплошным ключом". Примером такого отношения может служить отношение SP из 
базы данных поставщиков и деталей, если убрать из него атрибут QTY. 
    Обратите особое внимание на то, что данное выше определение потенциального 
ключа относится к самому отношению (т.е. к значениям отношения), а не к 
переменным отношения. Когда мы рассматриваем переменные отношения, особенно 
базовые отношения, то концентрируем свое внимание с точки зрения целостности 
не столько на определенном отношении, ставшем значением переменной отношения в 
определенный момент времени, сколько на множестве всех возможных отношений, 
которые могут быть значениями этой переменной. 
    • Например, если мы говорим, что комбинация атрибутов {S#,P#} — это 
потенциальный ключ для базового отношения SP, мы не имеем в виду, что просто в 
данный момент в отношении нет двух кортежей с одинаковым значением этой 
комбинации; мы имеем в виду, что для всех возможных отношений R, которые могут 
быть значениями SP, нет двух различных кортежей отношения R с одинаковым 
значением этой комбинации. 
    Поэтому для переменных отношения нам нужно дополнить определение 
потенциального ключа следующим образом (дополнения выделены жирным). 
    Пусть R— некоторая переменная отношения. Тогда потенциальный ключ, скажем, 
К для R —- это подмножество множества атрибутов R, всегда обладающее 
следующими свойствами: 
    1. Свойством уникальности. 
    Нет двух различных кортежей в текущем значении переменной R с одинаковым 
значением К. 
    1. Свойством неизбыточности. 
    Никакое из подмножеств К не обладает свойством уникальности. 
    Впредь будем использовать термин "потенциальный ключ" в этом более 
требовательном значении (за исключением специальных оговорок). 
    Ниже приведен синтаксис операторов определения потенциального ключа для 
базового отношения (отметьте, что каждый оператор CREATE BASE RELATION должен 
включать в себя, по крайней мере, одно определение потенциального ключа): 
    Candidate-key-definition 
    : :=	CANDIDATE KEY ( attribute-comnalist ) | PRIMARY KEY   (  
attribute-coiwna-tist ) 

    Глава 5. Целостность реляционных данных... 109 

    Примеры смотрите на рис. 3.9 и 4.3. (Однако обратите внимание, что на этих 
рисунках показан лишь случай первичного, а не потенциального ключа. Случай 
потенциального ключа обсуждается далее в этой главе.) 
    Прежде чем продолжить дискуссию о важности потенциальных ключей, нам 
необходимо выяснить несколько весьма важных вопросов. 
    • Во-первых, хотя на практике отношения чаще всего имеют только один 
потенциальный ключ, их, конечно же, может быть несколько. Пусть, например, у 
нас есть отношение ELEMENTS, представляющее таблицу химических элементов. У 
каждого элемента есть уникальное имя, уникальное обозначение (например, 
обозначение свинца — "РЬ") и уникальное атомное число. Поэтому ясно, что в 
отноше нии есть три различных потенциальных ключа: 

    CREATE BASE RELATION ELEMENTS ( NAME   ... , SYMBOL  . . . , NUMBER .... 
    CANDIDATE KEY	( NAME ) 
    CANDIDATE KEY	( SYMBOL ) 
    CANDIDATE KEY	( NUMBER ) 

    Во-вторых, заметьте, что потенциальные ключи определены как множества 
атрибутов. Поэтому при ссылке на них используются "скобки множества", т.е. 
фигурные скобки. Например, в базе данных поставщиков и деталей {S#} — это 
потенциальный ключ отношения S, {Р#} — это потенциальный ключ отношения Р, 
{S#,P#} — это потенциальный ключ отношения SP. Однако в неформальном контексте 
скобки обычно опускают, если это множество содержит только один атрибут. 
Поэтому можно сказать, например, что S# (вместо {S#}) — это потенциальный ключ 
отношения S. 
    Терминология. Потенциальный ключ, состоящий из более чем одного атрибута, 
называется составным. Потенциальный ключ, состоящий из одного атрибута, 
называется простым. 
    Кроме того, понятие неизбыточности требует некоторого уточнения. Дело в 
том, что, если мы определили "потенциальный ключ", не являющийся неизбыточным, 
системе не будет известно об этом и потому она не сможет обеспечить должным 
образом соответствующее ограничение целостности. Пусть, например, мы 
определили потенциальный ключ отношения S как комбинацию {S#,CITY} вместо S#. 
Тогда система не сможет соблюдать ограничение, обеспечивающее уникальность 
номера поставщика в "глобальном смысле"; вместо этого в системе будет 
выполняться более слабое ограничение, согласно которому номер поставщика будет 
уникальным в "локальном смысле", т.е. в пределах одного города. Таким образом, 
настоящие потенциальные ключи не должны включать лишних атрибутов для 
идентификации уникальности. 
    Замечание. Есть еще одна серьезная причина требования неизбыточности 
потенциальных ключей, которая связана с внешними ключами. Дело в том, что 
любой внешний ключ, на который ссылается "избыточный" потенциальный ключ (если 
бы такое было возможно), был бы также "избыточным" и отношение, содержащее 
его, практически наверняка противоречило бы принципам дальнейшей нормализации. 
    Между прочим, в этом смысле в литературе (включая предыдущие издания этой 
книги) неизбыточность часто называют минимальностью. Однако "минимальность" — 
это не совсем точное выражение, поскольку, когда мы говорим, что потенциальный 
ключ К1 "минимален", мы не имеем в виду, что не существует дру

    110 Часть II. Реляционная модель 

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

    Для чего предназначены потенциальные ключи 

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

    S WHERE S# =   'S3' 

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

    S WHERE SNAME =  'Blake' 

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

    S WHERE CITY =  ' Paris' 

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

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

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

    Глава 5. Целостность реляционных данных...	111 

    будут альтернативными ключами, В случае же, когда есть лишь один 
потенциальный ключ, в реляционной модели, опять же традиционно, он должен быть 
выбран в качестве первичного ключа в базовом отношении. Следовательно, каждое 
базовое отношение должно всегда иметь первичный ключ. 
    Замечание. Если множество потенциальных ключей имеет более одного 
элемента, то выбор ключа в качестве первичного, по существу, может быть произвольным. 
    Наше мнение по этому вопросу следующее: выбор одного потенциального ключа 
(если есть из чего выбирать) в качестве первичного определенно желателен во 
многих случаях (даже в большинстве случаев), но это не подтверждается во всех 
случаях, Аргументы в пользу этой точки зрения даны в [5.8]. 
    Конечно, если в отношении лишь один потенциальный ключ, то именование его 
первичным вызывает небольшое раздражение. Но если есть несколько потенциальных 
ключей, то выбор одного из них в качестве первичного может быть во многих 
ситуациях весьма полезным (хотя с философской точки зрения это выходит за 
рамки модели как таковой). Другими словами, первичные ключи могут еще 
отстаивать свою немалую практическую (или по крайней мере историческую) 
важность. Поэтому ниже приведен синтаксис для их объявления. Но мы не 
настаиваем на том, что каждое базовое отношение должно иметь первичный ключ, а 
лишь подчеркиваем, что каждое базовое отношение должно иметь по крайней мере 
один потенциальный ключ. 
    Что касается наших собственных примеров, в основном, но не постоянно мы 
будем соблюдать правило первичных ключей, т.е. большинство наших базовых 
отношений будет иметь первичный ключ (и мы будем продолжать помечать первичные 
ключи в рисунках двойным подчеркиванием). 
    Вот соответствующий синтаксис (он уже приводился выше в этой главе): 

    Candidate-key-defini tion 
    ::=	CANDIDATE KEY  (  attribute-commalist ) | PRIMARY KEY  ( 
attribute-commalist ) 

    (Как уже упоминалось ранее, commalist означает список указанных элементов 
через запятую.) 
    Внутри любого конкретного оператора CREATE BASE RELATICN должно быть, по 
крайней мере, одно определение потенциального ключа. Но лишь одно из этих 
определений может объявлять первичный ключ, т.е. только в одном определении 
может содержаться выражение PRIMARY KEY. 
    И последнее замечание относительно терминологии. Термины "потенциальный 
ключ" и "первичный ключ" не должны заменяться простым сокращением ключ. Термин 
"ключ" уже имеет слишком много значений в мире баз данных. Например, только 
одна реляционная модель имеет потенциальные, альтернативные, первичные и 
внешние ключи. В других контекстах используются такие понятия, как индексные 
ключи, хеш-ключи, ключи сортировки, вторичные ключи, поисковые ключи, основные 
ключи, подчиненные ключи, ключи шифрования, ключи расшифровки, ключи 
секретности и т.д., пока не надоест. Поэтому предпочтительнее, по мнению 
автора, всегда использовать термины по назначению, чтобы избежать возможной путаницы. 
    (В предыдущем издании этой книги мы договорились, что если какой-нибудь 
один ключ и заслуживает называться этим термином (просто "ключ") и быть 
выделенным из всего многообразия ключей, то это, очевидно, первичный ключ! 
Сейчас нам кажется, что если неудачный термин "ключ" использовать всегда, то 
было бы правильнее использовать его в значении потенциальный ключ. Тот факт, 
что мы изменили свое мнение в этом отношении, придает еще больший вес 
первоначальному аргументу, что термины должны быть всегда наиболее подходящими.) 

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

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

    112	Часть II. Реляционная модель 

    ния первичного ключа S# отношения S (в противном случае база данных не 
может рассматриваться как целостная). Например, не имело бы смысла включать 
для отношения SP поставку для поставщика, скажем, S8, если бы в отношении S не 
существо-зало поставщика S8. Аналогично, данное значение для атрибута Р# 
отношения SP должно быть допустимо для базы данных лишь в случае, если такое 
же значение есть в качестве значения первичного ключа Р# отношения Р; и опять 
же не имело бы смысла включать для отношения SP поставку для поставщика, 
скажем, Р8, если бы в огношении Р не существовало поставщика Р8. Атрибуты S# и 
Р# отношения SP, таким образом, являются примерами того, что мы называем 
внешними ключами. 
    Прежде чем продолжить, следует обратить внимание на то, что мы затронули 
область, в которой ведется дискуссия по определенным вопросам. Реляционная 
модель традиционно требует, чтобы внешние ключи в точности соответствовали 
первичным ключам, а не просто потенциальным ключам (например, [5.2]). Эта 
позиция поддерживается и в предыдущей редакции этой книги, и в других 
публикациях автора (например, [5.3, 5.4]). Однако наша сегодняшняя позиция 
сходна с позицией по первичным ключам вообще: требование точного соответствия 
внешних ключей первичным желательно во многих случаях, даже в большинстве 
случаев, но это не подтверждается во всех случаях. (Аргументы в поддержку этой 
позиции можно найти в [5.8].) Что касается примеров в этой книге, то мы 
придерживались правила о том, что внешние ключи в действительности ссылаются 
точно на первичные ключи; однако делалось это только для того, чтобы упростить описание. 
    Пришло время уточнить основные идеи. Вот определение термина "внешний ключ". 
    Пусть R2 — базовое отношение. Тогда внешний ключ, скажем, FK в отношении 
R2 — это подмножество множества атрибутов R2, такое что: 
    • существует базовое отношение Rl (R1 и R2 не обязательно различны) с 
потенциальным ключом СК; 
    • каждое значение FK в текущем значении R2 всегда совпадает со значением 
СК некоторого кортежа в текущем значении R1. 
    Определение нуждается в пояснениях. 
    1. Заметьте, что внешние ключи, как и потенциальные, определены как 
множества атрибутов. Поэтому для них необходимо использовать "скобки 
множества" (фигурные скобки). Например, в отношении SP базы данных поставщиков 
и деталей внешние ключи, строго говоря, — это {S#} и {Р#}, а не S# и Р#. 
Однако в неформальном контексте скобки обычно опускают, если это множество 
содержит только один атрибут. 
    2. По определению каждое значение данного внешнего ключа должно являться 
значением соответствующего потенциального ключа. Однако заметьте, что обратное 
не требуется; т.е. потенциальный ключ, соответствующий данному внешнему ключу, 
может содержать значение, которое в данный момент не является значением 
внешнего ключа. Например, в случае базы данных поставщиков и деталей 
(примерные значения показаны на рис. 3.8) поставщик с номером S5 не поставляет 
в данный момент никаких деталей. 
    3. Данный внешний ключ будет составным, т.е. будет состоять из более чем 
одного атрибута, тогда и только тогда, когда соответствующий потенциальный 
ключ также будет составным. Он будет простым тогда и только тогда, когда 
соответствующий потенциальный ключ также будет простым. 
    4. Каждый атрибут, входящий в данный внешний ключ, должен быть определен 
на том же домене, что и соответствующий атрибут соответствующего 
потенциального ключа. 
    5. Для внешнего ключа не требуется, чтобы он был компонентом первичного 
ключа или какого-либо потенциального ключа в содержащем его отношении, хотя в 
примере базы данных поставщиков и деталей оба внешних ключа обладают таким 

    Глава 5. Целостность реляционных данных...	113 

    свойством (в действительности два внешних ключа в отношении SP вместе 
составляют первичный ключ этого отношения). Вот еще один пример (определение 
базы данных отделов и сотрудников из главы 3, рис. 3.6, показано в упрощенной 
s форме):	! 

    DEFT ( DEPT#, ONAME, BUDGET ) 
    PRIMARY KEY ( DEPT# ) EMP  ( EMPt, EWAME, DEPT#, SALARY ) 
    PRIMARY KEY ( EMP# ) 
    FOREIGN KEY ( DEPTtt ) REFERENCES DEPT 

    В этой базе данных атрибут DEPT# отношения EMP является внешним ключом, 
соответствующим первичному ключу DEPT# отношения DEPT; однако он, конечно, не 
является компонентом первичного ключа ЕМР# (и никакого другого потенциального 
ключа) отношения ЕМР. В действительности внешним ключом может быть любой 
атрибут или какое-либо сочетание атрибутов (в базовом отношении). 
    6.   Терминология, Значение внешнего ключа представлено ссылкой к кортежу, 
содержащему соответствующее значение потенциального ключа (ссылочный кортеж 
или целевой кортеж). Поэтому проблема обеспечения того, что база данных не 
включает никаких неверных значений внешних ключей, известна как проблема 
ссылочной целостности. Ограничение, по которому значения данного внешнего 
ключа должны быть адекватны значениям соответствующих потенциальных ключей, 
называют ссылочным ограничением. Отношение, которое содержит внешний ключ, 
называется ссылающимся отношением, а отношение, которое содержит 
соответствующий потенциальный ключ, — ссылочным отношением или целевым 
отношением (target relation). 
    7.  Ссылочные диаграммы. Рассмотрим снова базу данных поставщиков и 
деталей. Существующие в базе данных ссылочные ограничения можно представить 
средствами следующей ссылочной диаграммы: 

    S <- SP --» Р. 

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

    S <- SP -» Р 

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

    R3 -» R2 ~> R1. 

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

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

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

    114	Часть II. Реляционная модель 

    9. Заметьте, что отношения R1 и R2 в определении внешних ключей не 
обязательно различны, т.е. некоторое отношение может включать внешний ключ, 
значения которого должны соответствовать значениям некоторых потенциальных 
ключей в том же отношении. В качестве примера рассмотрим следующее отношение: 
    ЕМР ( ЕМР#, . . ., SALARY, . . ., MGR__EMP#, ... ) PRIMARY KEY ( EMP# ) 
FOREIGN KEY ( RENAME MGR_EMP# AS EMP# ) REFERENCES EMP 
    В этом отношении атрибут MGR_EMP# представляет номер служащего для 
менеджера, который идентифицируется атрибутом ЕМР# как служащий. Здесь ЕМР# — 
первичный ключ, a MGR_EMP# — внешний ключ, который ссылается на этот 
первичный. (Например, кортеж для служащего Е4 может включать значение MGR_EMP# 
кортежа ЕЗ, который представляет ссылку к кортежу ЕМР для служащего ЕЗ. Ниже 
будет разъяснена конструкция RENAME.) Такие отношения иногда называют самоссылающимися. 
    10. Самоссылающиеся отношения, такие как отношение ЕМР в предыдущем 
примере, в действительности представляют собой специальный случай более общей 
ситуации, когда могут возникать ссылочные циклы. Отношения Rn, R(n-l), ..., 
R2, R1 образуют ссылочный цикл, если отношение Rn включает внешний ключ, 
ссылающийся на R(n-l), отношение R(n-l) включает внешний ключ, ссылающийся на 
R(n-2), ... и наконец, отношение R1 включает внешний ключ, ссылающийся вновь 
на Rn. Или более кратко: ссылочный цикл существует, если есть ссылочный путь 
из некоторого отношения Rn к себе: 
    Rn -> R(n-l)  -> R(n-2)  -»...-» R2 -» R1-» Rn. 
    11. Соответствие внешний-к-потенциальному-ключу иногда называют "клеем", 
который удерживает базу данных как единое целое. То же самое можно сказать и 
иначе: такое соответствие представляет собой некоторое отношение или 
взаимосвязь между кортежами. Однако обратите внимание, что не все отношения 
представлены этими соответствиями. Например, есть отношение между размещенными 
в одном городе поставщиками и деталями, представленное атрибутами CITY 
отношений S и Р. Однако такие атрибуты CITY не являются внешними ключами. Они 
могли бы стать внешними ключами, если бы в базу данных было добавлено 
отношение с атрибутом CITY как потенциальным ключом. 
    Вот синтаксис для указания внешнего ключа (обратите внимание, что данный 
оператор CREATE BASE RELATION может включать нуль или более определений 
внешних ключей): 

    FOREIOt KEY  (  element-comnalist )   REFERENCES base-relation 

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

    FENJME attribute AS attribute 

    Здесь первый параметр attribute является именем атрибута содержащего его 
отношения, а второй параметр attribute представляет собой новое имя для такого 
атрибута, который реально заменяет первое имя при работе с данным внешним 
ключом. Полное множество имен атрибутов для внешнего ключа должно совпадать с 
множеством имен атрибутов для некоторого потенциального ключа базового 
отношения, указанного после оператора REERENCES. Некоторые примеры можно найти 
на рис. 3.9 или 4.3 (простой случай); также смотрите выше пример внешнего 
ключа MGR_EMP# (случай с использованием оператора RENAME). Дальнейшее 
обсуждение применения оператора RENAME будет приведено в следующих главах книги. 

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

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

    Глава 5. Целостность реляционных данных...	115 

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

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

    Правило целостности, сформулированное в предыдущем разделе, выражено 
исключительно в терминах состояний базы данных. Любое состояние базы данных, 
не удовлетворяющее этому правилу, некорректно; но как избежать таких 
некорректных состояний? В самом правиле об этом не говорится. 
    Одна из возможностей состоит в том, чтобы просто запретить любые операции, 
приводящие к некорректному состоянию. Однако в некоторых случаях 
предпочтительнее допустить такую операцию, но при необходимости выполнить 
некоторые компенсирующие операции, чтобы гарантировать, что в результате 
система останется в корректном состоянии. Например, если пользователь пытается 
удалить поставщика S1 из отношения S, система сама может удалить поставки 
поставщика S1 из отношения SP без каких-либо последующих действий со стороны 
пользователя (предполагается, конечно, что требовалось получить именно такой 
результат "каскадного удаления"). 
    Следовательно, для этой базы данных у пользователя (или в этом контексте у 
разработчика базы данных) должна быть возможность определить, какие операции 
должны быть запрещены, а какие разрешены, нужны ли для разрешенных операций 
компенсирующие, и если да, то какие. Поэтому мы кратко обсудим эту возможность 
в настоящем разделе. Однако заметьте, что при этом мы выходим за рамки 
обсуждения самой реляционной модели. 
    Основная идея состоит в следующем. Для каждого внешнего ключа необходимо 
ответить на два важных вопроса. 
    1. Что должно случиться при попытке удалить объект ссылки внешнего ключа? 
Например, удалить поставщика, для которого есть, по крайней мере, одна 
поставка. Для определенности рассмотрим именно этот случай. В общем существует 
по меньшей мере две возможности: 
    • ОГРАНИЧИТЬ — "ограничить" операцию удаления, до момента, когда не будет 
существовать соответствующих поставок (в противном случае операция запрещается); 
    • КАСКАДИРОВАТЬ — "каскадировать" операцию удаления, удаляя также 
соответствующие поставки. 
    2.  Что должно случиться при попытке обновить потенциальный ключ, на 
который } ссылается внешний ключ? Например, при попытке обновить номер 
поставщика, для которого существует, по крайней мере, одна соответствующая 
поставка. И вновь рассмотрим именно этот случай для определенности. Как и для 
удаления | здесь существует по меньшей мере две возможности:	'• 
    • ОГРАНИЧИТЬ —• "ограничить" операцию обновления до момента, когда не 
будет существовать соответствующих поставок (в противном случае операция запрещается); 

    116	Часть II. Реляционная модель 

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

    FOREIGN KEY  (...)   REFERENCES base-relation DELETE option UPDATE option 

    Здесь параметр option может принимать значение RESTRICTED (ограничить) или 
CASCADES (каскадировать). В связи с этим возникают следующие вопросы. 
    1. Конечно, опции RESTRICTED и CASCADES для.правил удаления и обновления 
внешнего ключа не ограничивают возможности: они лишь представляют два случая, 
которые обычно используются на практике. А в принципе может быть любое 
количество возможностей при попытке удаления определенного поставщика. Например: 
    • может быть инициирован диалог с конечным пользователем; 
    • информация может быть занесена в некоторую архивную базу данных; 
    1 поставки удаляемого поставщика могут быть приписаны какому-либо другому поставщику. 
    Конечно, дать названия всем возможным действиям нереально. Поэтому в общем 
случае параметр option в нашем синтаксисе должен включать возможность вызова 
определенной при установке процедуры баз данных (иногда называемой "хранимой 
процедурой" или "процедурой триггеров"). 
    2. Пусть Ю и R2 — соответственно ссылающееся и ссылочное отношение (R2 ->• RI). 
    И пусть для этого ссылочного ограничения установлено правило каскадного 
удаления, т.е. удаление данного кортежа из отношения R1 повлечет удаление 
определенных кортежей отношения R2 (в общем случае). Теперь предположим, что 
на отношение R2, в свою очередь, ссылается некоторое отношение R3: 

    R3 -> R2 -» R1. 

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

    Глава 5, Целостность реляционных данных...	117 

    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-ЗНаЧСНИЯ Н6  допустимы).) 

    Если данному атрибуту не разрешено содержать null-значения, 
система будет отвергать любые попытки ввода null-значения в эту позицию. 
    Как уже отмечалось, мы не намерены рассматривать здесь содержание понятия 
null-значений во всех деталях. Но хотелось бы внести ясность: по нашему 
мнению, null-значения — и целая теория трехзначной логики, на которой они 
базируются, — являются фундаментальным заблуждением и не должны иметь места в 
чистой формальной системе, такой какой подразумевается реляционная модель. На 
самом деле, мы считаем, что: а) проблема отсутствия информации еще не до конца 
осмыслена; б) в настоящее время не известно ни одного полного 
удовлетворительного решения проблемы; в) включение null-значений или любых 
других подобных свойств в модель на сегодняшний день преждевременно. Но нужно 
также подчеркнуть, что другие авторы полагают совсем противоположное: в 
частности, Кодд фактически рассматривает null-значения как неотъемлемую часть 
реляционной модели [4.4]. 
    Как бы то ни было, давайте возвратимся к главной теме нашего обсуждения и 
рассмотрим влияние null-значений на концепции потенциальных и внешних ключей, 
которые описывались ранее. 

    118	Часть II, Реляционная модель 

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

    Как разъяснялось выше в этой главе, реляционная модель традиционно 
требует, чтобы (для базовых отношений, по крайней мере) в качестве первичного 
ключа для данного отношения был выбран ровно один потенциальный ключ, а 
оставшиеся ключи, если они есть, были бы тогда альтернативными ключами. Вместе 
с понятием первичного ключа модель включает правило целостности объектов: 
    • Целостность объектов. 
    Ни один элемент первичного ключа базового отношения не может быть null-значением. 
    Другими словами, определение каждого атрибута первичного ключа любого 
базового отношения должно явно или неявно включать спецификацию NULL NOT 
ALLOWED. Это правило объясняется следующим: 
    • Базовые отношения, точнее, кортежи базовых отношений соответствуют 
объектам в реальном мире. Например, базовое отношение S соответствует реальным поставщикам. 
    • По определению объекты реального мира различимы, т.е. они некоторым 
образом опознаваемы. 
    • Поэтому соответствующие представления объектов в базе данных также 
должны быть различимы (опознаваемы). 
    • В реляционной модели первичные ключи выполняют функцию уникальной 
идентификации (т.е. служат для представления необходимых идентификаторов объектов). 
    • Поэтому в качестве примера предположим, что базовое отношение S включает 
кортеж, для которого значение S# является null-значением. Тогда можно сказать, 
что есть реальный поставщик, который не имеет идентичности (по крайней мере, 
идентичность его не установлена). 
    • Более того, что такое null-значение означает? Если это означает, что 
"свойство не применяется", то, очевидно, такой кортеж не имеет смысла; как 
разъяснялось выше, объекты должны обладать идентичностью, следовательно, 
свойство должно применяться. Если это означает "неизвестное значение", то 
количество всевозможных проблем возрастет. Например, мы сейчас еще даже не 
знаем (в общем), представляет ли кортеж одного из поставщиков, о котором мы 
знаем (поскольку неизвестно, что значит "не знаем"!). Таким образом, например, 
на вопрос: "Сколько имеется поставщиков?" — следует ответ: "Не знаем". 
    • Точно такие же аргументы применимы и ко всем остальным возможным 
интерпретациям null-значения. На самом деле объект с отсутствующей 
идентичностью является противоречием, которое выражается так: "Объект, который 
не имеет идентичности, не существует" (поэтому правило и называется правилом 
"целостности объекта"). 
    • Аргументы, аналогичные предыдущим, могут использоваться для демонстрации 
того, что в базовом отношении с составным первичным ключом значения первичного 
ключа, которые являются частично null-значениями, должны быть также запрещены. 
    • Подытожим: если реальный объект настолько важен, что требуется его явное 
представление в базе данных, то этот объект должен быть определенно и 
недвусмысленно идентифицируемым, в противном случае какие бы то ни было 
разумные рассуждения о нем не возможны. Поэтому правило целостности объектов 
иногда формулируют в следующей форме: 
    В реляционной базе данных мы никогда не записываем информацию о чем-то, 
чего мы не можем идентифицировать. 

    Глава 5. Целостность реляционных данных,,.	119 

    Мимоходом отметим общепринятое, но ошибочное мнение, что правило 
целостности объектов гласит нечто в духе: "Первичные ключи должны быть 
уникальны". Это не так. Уникальность первичных ключей требуется в части 
основного определения понятия первичных ключей как таковых. Правило же 
целостности объектов гласит (повторяем), что первичные ключи в базовых 
отношениях не должны содержать ни одного null-значения. 
    Теперь давайте поближе рассмотрим это правило. Поскольку оно использует не 
одно, а два понятия — первичные ключи и null-значения, в которых мы нашли 
нечто, подвергаемое сомнению. Здесь необходимо сделать еще несколько замечаний. 
    •   Это правило применяется только для базовых отношений. Другие отношения 
действительно могут иметь первичный ключ, для которого null-значения 
допустимы. Приведем простой пример. Предположим, что для цвета детали 
"допустимы null-значения" и что в отношении Р есть дополнительный кортеж, 
скажем, для детали Р7, в котором атрибут COLOR (цвет) на самом деле является 
null-значением. Теперь рассмотрим отношение, представляющее собой результат 
запроса "Список всех цветов деталей". Такое отношение просто имеет один 
атрибут, который является потенциальным ключом и, следовательно, первичным 
ключом, а один из кортежей отношения имеет null-значение в области первичного 
ключа. Таким образом, правило целостности объектов предполагает неприятное (и 
совершенно неоправданное) разграничение между базовыми и другими отношениями. 
Что случится, если мы, например, попытаемся сохранить результат запроса 
"Список всех цветов деталей" как новое базовое отношение? 
    •  Это правило применяется только для первичных ключей. Для альтернативных 
ключей null-значения могут быть запрещены или разрешены. Но если 
альтернативный ключ является таким, для которого разрешены null-значения, то 
он не может быть выбран в качестве первичного ключа по правилу целостности 
объектов. Так каков же точный смысл выражения, что альтернативный ключ 
является "потенциальным" ключом в первую очередь? И наоборот, если мы говорим, 
что альтернативные ключи также не должны иметь null-значений, тогда правило 
целостности объектов должно относиться ко всем потенциальным ключам — а не 
только к первичному ключу. 
    •  В действительности объяснение правила целостности объектов, данное 
выше, применимо в равной мере к каждому атрибуту всех базовых отношений, а 
следовательно, null-значения должны быть запрещены везде! Так для чего же 
предназначены null-значения? 
    •  Относительно понятия первичных ключей в [5.2] было предложено запретить 
ссылаться к первичным ключам, которым разрешены null-значения, именно как к 
первичным ключам, а ссылаться лишь как к "слабым идентификаторам". Другими 
словами, некоторые отношения не будут иметь собственного уникального 
идентификатора совсем. По нашему мнению, в этом нет ничего страшного, но 
весьма сомнительно поддерживать заведомо подозрительную позицию. Более того, в 
[4.4] автор настаивает на требовании, чтобы кортежи, которые в каждой позиции 
атрибута ничего кроме null-значений не содержат, "мягко и неожиданно исчезли", 
что кажется еще более подозрительным. 
    •  Предположим, что мы полностью отказались от идеи null-значений и вместо 
представления отсутствующей информации используем значения по умолчанию (т.е. 
так, как мы поступаем на практике). Например, если зарплата служащего Джо не 
известна по некоторым причинам, мы можем представить это в базе данных с 
помощью значения -1 (обсуждение этого вопроса приводится в дальнейших главах 
книги). Тогда правило целостности объекта не имело бы больше никакого значения 
и могло бы быть отброшено безо всякого ущерба. 

    120	Часть II. Реляционная модель 

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

    SURVEY 
    BIRTHDAY	AVGSAL	MAXSAL	MINSAL 
    1940	85К	130K	33K 
    1941	82К	125K	32K 
    1942	77К	99K	32K 
    1943	78К	97K	35K 
    1970	29К	35K	12K 
    ????	56К	117K	20K 

    Рис. 5.1. Отношение SURVEY 


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

    Обратимся вновь к базе данных отделов и служащих из главы 3. Предположим, 
что в компании, представленной этой базой данных, допустимо, чтобы служащий не 
был причислен ни к одному из отделов. Поэтому в кортеже ЕМР такого служащего 
нет настоящего номера отдела, который может быть соответствующим значением для 
внешнего ключа DEPT#. 
    В качестве другого примера рассмотрим самоссылающееся отношение ЕМР, 
которое обсуждается выше в этой главе. Каким будет значение атрибута MGR_EMP# 
для президента компании? 
    Для решения вопросов, подобных приведенным в предыдущих примерах, 
реляционная модель традиционно разрешает появление null-значений в позициях 
внешних ключей. (Заслуживает внимания, между прочим, то, что эти null-значения 
подходят для представления атрибутов типа "значение не существует", а не 
"значение неизвестно".) Поэтому приведенное выше определение внешнего ключа 
требует некоторой небольшой доработки с учетом следующего дополнения (которое 
выделено жирным шрифтом). 
    Пусть R2 — базовое отношение. Тогда внешний ключ, скажем, FK в отношении 
R2 — это подмножество множества атрибутов R2, такое что: 
    • существует базовое отношение Rl (R1 и R2 не обязательно различны) с 
потенциальным ключом СК; 
    • всегда каждое значение FK в текущем значении R2 или является 
null-значением, или совпадает со значением СК некоторого кортежа в текущем 
значении R1. 
    Правило ссылочной целостности "База данных не должна содержать никаких не 
соответствующих значений внешних ключей" остается неизменным, но значение 
выражения "не соответствующих значений внешних ключей" расширено до ссылки к 
не-пи11-значению внешнего ключа, для которого не существует адекватного 
значения соответствующего потенциального ключа в соответствующем целевом отношении. 

    Глава 5. Целостность реляционных данных... 121 

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

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

    FOREIGN KEY (...) REFERENCES base-relation DELETE option 
    UPDATE option	. . NULLS null-option 

    (где параметр null-option может принимать значения ALLOWED (разрешено) или 
NOT ALLOWED (не разрешено)), чтобы позволить проектировщику записать свое решение. 
    2.  Если данный внешний ключ FK составной и null-значения действительно 
разрешены, то в этом случае существуют разные мнения относительно того, можно 
ли разрешать данному значению ключа FK иметь некоторые компоненты равными 
null, а остальные не равными, или необходимо настаивать на том, чтобы каждое 
значение составного ключа FK было полностью null-значением или полностью 
не-null-значением. В этой дискуссии мы занимаем вторую (более простую) 
позицию. (См. [5.4, 5.7], где детально рассматривается эта дискуссия.) 
    3.  И вновь обратимся к вопросу о том, что должно случиться при попытке 
удалить целевой объект, на который ссылается внешний ключ: например, попытке 
удалить кортеж поставщика, для которого существует, по крайней мере, одна 
соответствующая поставка. Для определенности давайте еще раз рассмотрим этот 
случай подробно. Если для рассматриваемого внешнего ключа, например SP.S#, 
null-значения разрешены, то имеется и другая возможность для правила удаления 
(т.е. другое возможное значение в синтаксисе для параметра option), а именно 
NULLIFIES (аннулировать). 
    • В соответствии с опцией NULLIFIES внешний ключ устанавливается равным 
null для всех соответствующих поставок, а кортеж поставщика затем удаляется. 
    4.  Также еще раз вернемся к вопросу о том, что должно случиться при 
попытке обнов-_ления потенциального ключа, на который ссылается внешний ключ: 
например, попытке обновить номер поставщика, для которого существует, по 
крайней мере, одна соответствующая поставка. И этот случай давайте рассмотрим 
еще раз подробно. Если для рассматриваемого внешнего ключа, например SP.S#, 
null-значения разрешены, то имеется и другая возможность для правила 
обновления (т.е. другое возможное значение в синтаксисе для параметра option), 
а именно NULLIFIES. 
    • В соответствии с опцией NULLIFIES внешний ключ устанавливается равным 
null для всех соответствующих поставок, а кортеж поставщика затем обновляется. 

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

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

    122	Часть II. Реляционная модель 

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

    5.9. Резюме 

    Эта глава может показаться несколько путанной, поскольку в ней было 
необходимо представить как традиционный подход, так и современные перспективы 
по обсуждаемой теме. Материал этой главы с течением времени существенно 
изменился. Но так или иначе подведем итоги. 
    •  Мы начали с обсуждения правил целостности и подчеркнули, что любое 
данное правило обязательно является специфическим для конкретной базы данных. 
    Затем мы сосредоточили внимание на "общих" свойствах целостности в 
реляционной модели. Мы определили потенциальные ключи для отношений вообще и 
для переменных отношения (главным образом для базовых отношений) в частности. 
Потенциальные ключи должны быть уникальными и неизбыточными, а каждое 
отношение должно иметь, по крайней мере, один потенциальный ключ. Никаких исключений! 
    •  Потенциальные ключи важны, поскольку они предоставляют в реляционной 
модели механизм адресации на уровне кортежа. 
    •  Исторически в соответствии с моделью требовалось, чтобы один 
потенциальный ключ был спроектирован как первичный (по крайней мере, для 
базовых отношений); а все остальные потенциальные ключи назывались 
альтернативными. Но согласно последним исследованиям [5.8] первичные ключи 
имеют не такое важное значение, как потенциальные ключи в общем (в особенности 
потому, что нет формальных оснований для выбора одного из потенциальных ключей 
первичным). Однако, учитывая возможные прагматические (и исторические) 
аргументы в пользу сохранения понятия первичного ключа, мы продолжаем 
использовать первичные ключи в примерах этой книги. 
    •  Далее было дано определение внешним ключам и нескольким связанным 
понятиям — ссылочному ограничению, ссылочному пути, ссылочному циклу и другим. 
Исторически в соответствии с моделью требовалось, чтобы внешние ключи 
ссылались только на первичные ключи, а не просто на потенциальные ключи, 
однако согласно последним исследованиям [5.9] это требование очень сильное и 
есть несколько существенных причин, по которым внешние ключи должны ссылаться 
на потенциальные ключи, не являющиеся первичными. Но в книге будут 
использоваться в примерах внешние ключи, ссылающиеся на первичные, так как это 
несколько упрощает изложение. 
    •  После этого были описаны два правила внешних ключей — правило удаления 
и правило обновления, которые хотя и не являются частью реляционной модели как 
таковой, но необходимы на практике в качестве основы декларативного механизма 
для поддержания ссылочной целостности как того требует модель. Для каждого из 
этих правил можно установить опцию RESTRICTED (ограничить) или CASCADES (каскадировать). 
    • Далее, немного отклонившись от темы, мы представили понятие 
null-значений, на основе которого обрабатывается отсутствующая информация. Мы 
указали (не предоставив, однако, достаточных оснований), что необходимо 
полностью отказаться от идеи null-значений в пользу схемы, основанной на 
значениях, задаваемых по умолчанию. 

    Глава 5. Целостность реляционных данных...	123 

    •   И наконец, мы обсудили, как null-значения соотносятся с потенциальными 
и внешними ключами. В частности, мы ввели правило целостности объектов и 
пришли к выводу, что одна из версий этого правила может быть полезным 
наставлением при проектировании баз данных, но его нельзя рассматривать как 
твердое требование. Мы также объяснили значение опции NULLIFIES (аннулировать) 
для правил удаления и обновления внешних ключей. 
    Вопрос отсутствующей информации подробнее будет обсуждаться в последующих 
главах этой книги, а пока понятие null-значений будет полностью 
игнорироваться. В частности, в главах 6 и 7 не будет рассматриваться, как 
null-значения влияют на действия реляционных операторов. 
    И в завершение отметим следующее. Реляционная модель часто описывается как 
включающая "два общих правила целостности", а именно: целостности объектов и 
ссылочной целостности. Однако было бы точнее называть эти правила 
метаправилами, а не правилами как таковыми, и это мы сейчас поясним. 
    •  Рассмотрим, например, правило ссылочной целостности. Это правило 
гласит, что значения внешних ключей подразумеваются соответствующими значениям 
потенциальных ключей (если, конечно, говорить не строго). 
    •  Теперь обратимся к базе данных поставщиков и деталей. По правилу 
ссылочной целостности такая база данных должна иметь специфическое для базы 
данных правило, которое требует, чтобы значения атрибута S# в отношении SP 
соответствовали значениям атрибута S# в отношении S; она должна также иметь 
другое точно такое же правило для атрибута Р# в отношении SP и атрибута Р# в 
отношении Р. Таким образом, правило ссылочной целостности является правилом 
другого вида в отличие от специфического для базы данных правила. В сущности, 
это правило гласит, что должно быть некоторое другое правило, и именно это мы 
понимаем под метаправилом. 
    •  Аналогичные замечания также касаются и правила целостности объектов. 
    И последнее замечание. В начале этой главы мы сказали, что в реляционной 
модели есть два основных средства обеспечения целостности: потенциальные ключи 
и внешние ключи. Однако точнее будет сказать, что таких средств три. Третьим 
средством являются домены, и для этого средства также есть свое метаправило, в 
действительности более фундаментальное, чем два первых: 
    •   Целостность атрибута. 
    Значения каждого атрибута берутся из соответствующего домена. 
    Например, в случае базы данных поставщиков и деталей это метаправило 
требует наличия специальных для такой базы данных правил, которые гласят, что 
значения атрибута S# в отношении S берутся из домена номеров поставщиков, 
значения атрибута SNAME в отношении S берутся из домена имен и т.д. 

    Упражнения 

    5.1. Скорректируйте свой ответ на упр. 4.6 в главе 4, чтобы включить 
соответствующий набор правил внешних ключей для базы данных поставщиков, 
деталей и проектов. 
    5.2. Используя значения примерных данных поставщиков, деталей и проектов 
из рис. 4.6, скажите, какой будет результат каждой из следующих операций: 
    а) обновить проект J7, установив атрибут CITY равным New York; 
    б) обновить деталь Р5, установив атрибут Р# равным Р4; 
    в) обновить поставщика S5, установив атрибут S# равным S8, если для 
соответствующего правила обновления установлена опция RESTRICTED; 

    124	Часть II. Реляционная модель 

    г) удалить поставщика S3, если для соответствующего правила удаления 
установлена опция CASCADES; 
    д) удалить деталь Р2, если для соответствующего правила удаления 
установлена опция RESTRICTED; 
    е) удалить проект J4, если для соответствующего правила удаления 
установлена опция CASCADES; 
    ж) обновить поставку S1-P1-J1, установив атрибут S# равным S2; з) обновить 
поставку S5-P5-J5, установив атрибут J# равным J7; и) обновить поставку 
S5-P5-J5, установив атрибут J# равным J8; к) вставить поставку S5-P6-J7; л) 
вставить поставку S4-P7-J6; 
    м) вставить поставку S1 -P2-jjj, (где jjj — значение номера проекта по умолчанию). 
    5.3. Учебная база данных включает информацию о системе процесса обучения 
внутри компании. Для каждого курса обучения база данных содержит подробности 
обо всех необходимых условиях и предложениях такого курса; а для каждого 
предложения она содержит подробности обо всех преподавателях и студентах, 
зарегистрированных для такого предложения. База данных также содержит 
информацию о сотрудниках. Соответствующие отношения описаны ниже: 

    COURSE	( COURSE», TITLE ) 
    PREREQ	( SUP_COURSE#, SUB_COURSE# ) 
    OFFERING	( COURSE*, OFF», OFFDATE, LOCATION ) 
    TEACHER	( COURSE», OFF», EMP» ) 
    ENROLLMENT	( COURSE», OFF*, EMP#, GRADE ) 
    EMPLOYEE	( EMP#, ENAME, JOB ) 

    Смысл отношения PREREQ (необходимое условие) заключается в том, что 
старший курс (SUP_COURSE#) имеет подчиненный курс (SUB_COURSE#) в качестве 
непосредственного необходимого условия; другие отношения должны быть понятны 
без дополнительных пояснений. Начертите для этой базы данных соответствующую 
ссылочную диаграмму. Дайте соответствующие определения базы данных (т.е. 
запишите соответствующие операторы CREATE 

    DOMAIN И CREATE BASE RELATION). 

    5.4. Два следующих отношения представляют базу данных, содержащую 
информацию об отделах и служащих: 

    DEPT   (DEPT#,   ...,   M3R_EMP#,   ...   ) EMP     (EMP#,   ...,   DEPT#, 
  ...   ) 

    В каждом отделе есть менеджер (MGR_EMP#), для каждого из служащих есть 
отдел (DEPT#). Начертите ссылочную диаграмму и необходимое определение данных 
для этой базы данных. 
    5.5. Два следующих отношения представляют базу данных, содержащую 
информацию о служащих и программистах: 
    ЕМР     (ЕМР#,   ...,   JOB,   ...   ) PGMR   (ЕМР#,   ...,   LANG,   ...  
 ) 
    Каждый программист является служащим, но не наоборот. Начертите ссылочную 
диаграмму и необходимое определение данных для этой базы данных. 
    5.6. В главе обсуждались правила удаления и обновления внешних ключей, но 
не рассматривалось "правило вставки" внешних ключей. Почему? 

    Глава 5. Целостность реляционных данных...	125 

    5.7. В ответе к упр. 4.5 главы 4 мы представили специальные (очень важные) 
отношения DEE и DUM степени 0. Какие потенциальные ключи есть в этих отношениях? 
    5.8. Пусть R — отношение степени п. Какое максимальное количество 
потенциальных ключей может иметь это отношение? 

    Список литературы 

    5.1. Codd E.F. Extending the Relational Database Model to Capture More 
Meaning// ACM TODS. — 1970. — 4, № 4. 
    Общая цель этой статьи, как гласит название, — представить некоторые 
предварительные "семантические" дополнения к основной реляционной модели. 
Однако, прежде чем вдаваться в подробности предлагаемых дополнений, в статье 
подводятся итоги возможностей основной модели (1979 года), где кроме прочего 
впервые приведено правило целостности объектов и правило ссылочной целостности 
(однако в формулировке, несколько отличной от формулировки настоящей главы). 
Эти правила более или менее четко сформулированы в [4.1], но ранее в явной 
форме они не публиковались. В статье также можно найти первую версию 
предложения Кодда о null-значениях и трехзначной логике, как серьезное 
наступление на проблему отсутствующей информации. 
    Другой термин, иногда встречающийся в литературе, первичный домен, также 
впервые определен в этой статье. Первичный домен — это домен, на котором 
определен, по крайней мере, один первичный ключ с единственным атрибутом (не 
составной ключ). В случае поставщиков и деталей, например, первичными доменами 
будут домены S# и Р#. 
    5.2. Codd E.F. Domains, Keys, and Referential Integrity in Relational 
Databases // InfoDB. — 1988. —3,№ 1. 
    Предприняты попытки внести ясность в понятия домена, первичного ключа и 
внешнего ключа. Эта статья, очевидно, авторитетная, поскольку Кодд является 
автором всех трех понятий; однако, по мнению автора данной книги, к сожалению, 
в статье еще осталось слишком много неразрешенных и невыясненных вопросов. 
Между прочим, в статье приводятся следующие аргументы в пользу соблюдения 
требования, чтобы один потенциальный ключ выбирался в качестве первичного 
ключа: "Отказаться от этого правила — это то же самое, что пытаться 
использовать компьютер со схемой адресации для основной памяти и для вторичной 
памяти, в которой изменяется система исчисления при определенных условиях 
(например, если встретился адрес, являющийся простым числом)." Рассуждая таким 
образом, можно прийти к выводу, что для всех видов объектов необходимо 
использовать одну схему адресации. (На самом деле эта идея глобальной 
универсальной схемы адресации заслуживает дальнейшего обсуждения. К этому мы 
еще вернемся в следующих частях этой книги.) 
    5.3. Date C.J. Referential Integrity // Proc. 7th Intern. Conf. on Very 
Large Data Bases. — Cannes, France, 1981. 
    Позднее была издана пересмотренная версия (Date C.J. Relational Database: 
Selected Writings. —Reading, Mass.: Addison-Wesley, 1986). 
    В статье представлены правила внешних ключей (опции RESTRICTED, CASCADES, 
NULLIFIES), которые обсуждались в этой главе. Основное различие между первой 
версией статьи (VLDB 1981) и пересмотренной версией состоит в том, что в 
первой версии для внешнего ключа допустимо несколько целевых отношений, а в 
пересмотренной версии автор не придерживается такой чрезмерно общей позиции 
(об этом было сказано выше в этой главе. 

    126	Часть II, Реляционная модель 

    5.4. Date C.J. Referential Integrity and Foreign Keys. Part I: Basic 
Concepts; Part II: Further Considerations // C.J. Date. Relational Database 
Writings 1985-1989.— Reading, Mass.: Addison-Wesley, 1990. 
    В первой части этой обширной статьи (она занимает в общем более 80 
страниц) обсуждается история понятия ссылочной целостности, а также предложен 
ряд основных определений (с пояснениями). Во второй части приводятся 
расширенные аргументы в пользу приведенных определений и некоторые 
практические рекомендации; в частности, обсуждаются проблемы, вызванные 
перекрывающимися внешними ключами, возникновением значений составных внешних 
ключей, частично являющихся null-значениями, смежные ссылочные пути (т.е. 
различные ссылочные пути, у которых совпадают начальная и конечная точки). 
    Замечание. Некоторые позиции, изложенные в этой статье, частично (не очень 
существенно) опровергнуты аргументами статьи [5.8]. 
    5.5. Date C.J. Integrity // C.J. Date and Colin J. White. A Guide to DB2 
(4th ed.). — Reading, Mass.: Addison-Wesley, 1993. 
    Во время написания книги продукт DB2 корпорации IBM обеспечивал наиболее 
полную среди всех коммерческих систем декларативную поддержку первичных и 
внешних ключей. В этой статье содержится расширенное описание такой поддержки. 
    Следует отметить, что упомянутая поддержка DB2 пострадала от нескольких 
ограничений в реализации, общая цель которых обеспечить предсказуемое 
поведение системы. Приведем простой пример. Пусть отношение R содержит только 
два кортежа со значениями первичного ключа — 1 и 2 соответственно, рассмотрим 
запрос на обновление: "Удвоить каждое значение первичного ключа в отношении 
/?". При правильном выполнении запроса значения первичных ключей в кортежах 
будут равны соответственно 2 и 4. Если в DB2 в начале обновляется значение 2 
(оно заменяется на 4), а затем обновляется значение 1 (заменяется на 2), то 
запрос выполняется успешно. Но если вначале попытаться обновить значение 1 
(заменяя его на 2), то будет утрачена уникальность первичного ключа и запрос 
не будет выполнен (база данных останется неизменной). Итак, мы видим, что 
результат выполнения запроса непредсказуем. Чтобы избежать подобной 
непредсказуемости, в DB2 просто запрещены ситуации, в которых она может 
возникнуть. Однако, к сожалени ю, некоторые из этих ограничений довольно 
жесткие [5.11]. 
    Обратите внимание, что в предыдущем примере система производит 
"запланированную проверку", т.е. правила целостности применяются для каждого 
кортежа после его обновления. Такая проверка логически не оправдана 
(обсуждение операций обновления будет продолжено в главе 6), но осуществляется 
в целях повышения производительности. 
    5.6. Date C.J. Composite Keys // C.J. Date and Hugh Darwen. Relational 
Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992. 
    Цитата из резюме этой статьи: "Собраны аргументы за и против включения 
составных [первичных и внешних ключей] при проектировании реляционной базы 
данных и ... предложены некоторые рекомендации." 
    5.7. Date C.J. Composite Foreign Keys and Nulls // Ibid. 
    5.8. Date C.J. The Primacy of Primary Keys: An Invistigation // InfoDB. — 
1992. — 7, №3. 
    5.9. Horowitz В. М. A Run-Time Execution Model for Referential Integrity 
Maintenance. // Proc. 8th Intern. Data Engineering Conf. — Phoenix, Ariz., 1992. 

    Глава 5. Целостность реляционных данных...	127 

    Хорошо известно, что комбинации 
    1)   ссылочных структур (т.е. наборов отношений, которые взаимосвязаны с 
помощью ссылочных ограничений), 
    2)   правил удаления и обновления внешних ключей, 
    3)   реальных значений данных в базе данных 
    вместе могут привести к определенным конфликтным ситуациям и потенциально 
стать причиной непредсказуемого поведения по части реализации. Существует три 
общих подхода к решению этой проблемы: а) оставить все это пользователю; б) 
заставить систему выявлять и запрещать попытки определить структуры, которые 
потенциально могут привести к конфликтам во время выполнения каких-либо 
процессов; в) заставить систему отслеживать действительные конфликты во время 
выполнения. Первый подход не стоит рассматривать, а подход (б) часто приводит 
к чрезмерным ограничениям; поэтому автор предлагает остановиться на подходе 
(в). В статье приведен набор правил для действий во время выполнения и 
показана их корректность. Обратите внимание, что вопрос о преимуществах такой 
динамической проверки не рассматривается. 
    Автор статьи г-н Хорвиц (Horowitz) является активным членом комитета, 
работающего над текущей версией стандарта SQL, и предложения, высказанные в 
этой статье, действительно учитываются в разделах стандарта, связанных со 
ссылочной целостностью. 
    5.10. Markowitz V. M. Referential Integrity Revisited: An Object-Oriented 
Perspective // Proc. 16th Intern. Conf. on Very Large Data Bases. — Brisbane, 
Australia, 1990. "Объектно-ориентированная перспектива" соответствует позиции 
автора, изложением которой начинается статья: "Ссылочная целостность лежит в 
основе реляционного представления объектно-ориентированных структур". Однако в 
статье не идет речь об объектно-ориентированных системах вообще. В ней 
представлен алгоритм, генерирующий на основе диаграммы объект-отношение 
определение реляционной базы данных, в которой не возникает некоторых проблем, 
указанных в [5.4] (перекрывающиеся внешние ключи, возникновение значений 
составных внешних ключей, частично являющихся null-значениями). В статье также 
обсуждаются три коммерческих продукта (DB2, SYBASE и INGRES) с точки зрения 
ссылочной целостности. СУБД DB2, которая предоставляет декларативную 
поддержку, показана чрезмерно ограниченной; системы SYBASE и INGRES, которые 
предоставляют про цедурную поддержку (соотв етственно с помощью "триггеров" и 
"правил"), показаны менее ограниченными, чем DB2, однако громоздкими и 
сложными для использования (хотя и сказано, что процедурная поддержка СУБД 
INGRES "технически превосходит" поддержку системы SYBASE). 
    5.11. Markowitz V. M. Safe Referential Integrity Structures in Relational 
Databases // Proc. 17th Intern. Conf. on Very Large Data Bases. — Barselona, 
Spain, 1991. Предлагается два формальных "условия безопасности", которые будут 
гарантировать, что определенные проблемные ситуации, описанные, например, в 
[5.4, 5.9], не возникнут. В статье также рассматривается, что подразумевается 
под соответствием этим условиям в системах DB2, SYBASE и INGRES. Применительно 
к СУБД DB2 показано, что некоторые реализованные ограничения, налагаемые в 
целях безопасности [5.5], логически излишни, хотя в то же время другие 
недостаточны (т.е. в системе DB2 еще допустимы некоторые небезопасные 
ситуации). Относительно систем SYBASE и INGRES отмечено, что процедурная 
поддержка в этих продуктах не предоставляет возможностей для определения 
опасных (и даже некорректных!) ссылочных спецификаций. 

    128	Часть II. Реляционная модель 

    Ответы к некоторым упражнениям 

    5.1. Ниже показан возможный оператор CREATE BASE RELATION (только) для 
отношения SPJ: 

    CREATE BASE RELATION SPJ 
    ( S#    DOMAIN ( S# ), S#    DOMAIN ( P# ), J#    DCMAIN ( J# ), OTY   
DCMAIN ( QTY ) ) PRIMARY KEY ( S#, P#, J# ) FOREIGN KEY ( S# ) REFERENCES S 
DELETE CASCADES UPDATE RESTRICTED FOREIGN KEY ( P# ) REFERENCES P DELETE 
CASCADES UPDATE RESTRICTED FOREIGN KEY ( J# ) REFERENCES J DELETE CASCADES 
UPDATE RESTRICTED ; 

    5.2. а) операция допустима; 
    б) операция не допустима (нарушение уникальности потенциального ключа); 
    в) операция не допустима (нарушение правила обновления с установленной 
опцией RESTRICTED); 
    г) операция допустима (удаляется кортеж поставщика S3 и соответствующие 
поставки поставщика S3); 
    д) операция не допустима (нарушение правила обновления с установленной 
опцией RESTRICTED); 
    е) операция допустима (удаляется кортеж проекта J4 и соответствующие 
поставки для проекта J4); ж) операция допустима; 
    з) операция не допустима (нарушение уникальности потенциального ключа); и) 
операция не допустима (нарушение ссылочной целостности); к) операция 
допустима; л) операция не допустима (нарушение ссылочной целостности); 
    м) операция не допустима (нарушение ссылочной целостности — номер проекта 
по умолчанию jjj не существует в отношении J). 
    5.3. Ссылочная диаграмма показана на рис. 5.2. Возможны определения, 
представленные ниже. 
    Замечание. Для выразительности единственный потенциальный ключ каждого 
отношения определен явно выражением CANDIDATE KEY. He повредит (на самом деле 
это не имеет значения), если мы заменим все выражения или некоторые из них 
выражением PRIMARY KEY. 

    Глава 5. Целостность реляционных данных...	129 5 Введение в системы баз данных 

    |       PREREQ SUP_COURSE#  |           | SUB_COURSE# COURSE COURSE* 
COURSE#,OFF# ,       OFFE'R^G     |. COURSE#,OFF# TEACHER                      
                       ENROLLMENT 1 ————— J     EMPLOYEE      • ————— 1 FMn±t  
       1 ————— . ——— ——— .           FMDit 
    EMP# 
    EMP# 

    Рис. 5.2. Ссылочная диаграмма для учебной базы данных 

    CREATE DOMAIN COURSE#       CHAR(5) ; CREATE DOMAIN TITLE CHAR(256) ; 
CREATE DOMAIN OFF* CHAR(5) ; CREATE DOMAIN OFFDATE       DATE ; 
    CREATE DOMAIN CITY CHAR(15) ; 
    CREATE DOMAIN EMP* CHAR (6) ; CREATE DOMAIN NAME CHAR{20) ; CREATE DOMAIN 
JOB  CHAR (48) ; CREATE DOMAIN GRADE CHAR(l) ; 
    CREATE BASE RELATION COURSE 
    ( COURSE# DOMAIN ( COURSE» ), 
    TITLE  DOMAIN ( TITLE ) ) CANDIDATE KEY ( COURSES ) ; 
    CREATE BASE RELATION PREREQ 
    ( SUP_COURSE# DOMAIN ( COURSE! ), SUB_COURSE# DOMAIN ( COURSE* ) ) 
    CANDIDATE KEY ( SDP_COURSE#, SUB_COURSE# ) 
    FOREIGN KEY ( RENAME SUP_COURSE# AS COURSE* ) 
    REFERENCES COURSE DELETE CASCADES UPDATE CASCADES 
    FOREIGN KEY ( RENAME SUB_COURSE# AS COURSE* ) REFERENCES S 
    REFERENCES COURSE DELETE CASCADES UPDATE CASCADES ; 
    CREATE BASE RELATION OFFERING 
    ( COURSE* DOMAIN ( COURSE* ), OFF*   DOMAIN ( OFF* ), OFFDATE DOMAIN ( 
OFFDATE ), 

    130 Часть II. Реляционная модель 

    LOCATION DOMAIN ( CITY ) ) CANDIDATE KEY ( COURSE*, OFF* ) FOREIGN KEY ( 
COURSE* ) REFERENCES COURSE 
    DELETE CASCADES UPDATE CASCADES ; 
    CREATE BASE RELATION EMPLOYEE 
    ( EMP*   DOMAIN ( EMP* ), ENAME  DOMAIN ( NAME ), JOB    DCMAIN ( JOB ) ) 
CANDIDATE KEY ( EMP# ) ; 
    CREATE BASE RELATION TEACHER 
    ( COURSE* DCMAIN ( COURSE* ) , OFF*   DOMAIN ( OFF* ), EMP*   DCMAIN ( 
EMP* ) ) CANDIDATE KEY ( COURSE*, OFF*, EMP* ) FOREIGN KEY ( COURSE*, OFF* ) 
REFERENCES OFFERING 
    DELETE CASCADES UPDATE CASCADES 
    FOREIGN KEY ( EMP* )      REFERENCES EMP 
    DELETE CASCADES UPDATE CASCADES ; 
    CREATE BASE RELATION ENROLLMENT 
    ( COURSE* DCMAIN ( COURSE* ), OFF*    DOMAIN ( OFF* ) , EMP*   DCMAIN ( 
EMP* ) , GRADE  DOMAIN ( GRADE ) ) CANDIDATE KEY ( COURSE*, OFF*, EMP* ) ; 
    FOREIGN KEY ( COURSE*, OFF* )      REFERENCES OFFERING 
    DELETE CASCADES UPDATE CASCADES 
    FOREIGN KEY { EMP* )      REFERENCES EMP 
    DELETE CASCADES UPDATE CASCADES ; 

    Пояснения: 

    1.   Атрибуты COURSES в отношении TEACHER и COURSE* в отношении ENROLLMENT 
можно также рассматривать как внешние ключи, ссылающиеся на отношение COURSE. 
Однако если ссылочные ограничения от отношения TEACHER к OFFERING, от 
ENROLLMENT к OFFERING и от OFFERING к COURSE поддерживаются должным образом, 
то ссылочные ограничения от отношения TEACHER к COURSE будут поддерживаться 
автоматически. (Более глубокое обсуждение этого вопроса приведено в [5.4].) 

    Глава 5. Целостность реляционных данных...	131 

    2.  Отношение OFFERING в этом примере является одновременно ссылающимся и 
ссылочным: существует ссылочное ограничение к отношению OFFERING от ENROLLMENT 
и от отношения OFFERING к COURSE: 

    ENROLLMENT -> OFFERING -» COURSE 

    3.  Обратите внимание, что существует два различных ссылочных пути от 
отношения ENROLLMENT к отношению COURSE: один непосредственный (внешний ключ 
COURSES в отношении ENROLLMENT) и один неявный через отношение OFFERING (через 
внешние ключи {COURSE#,OFF#} в отношении ENROLLMENT и COURSE* в отношении OFFERING): 

    I	\ 
    ENROLLMENT -» OFFERING -> COURSE 

    Однако в действительности эти пути не являются независимыми (верхний путь 
представляет собой комбинацию двух нижних). (Более глубокое обсуждение этого 
вопроса приведено в [5.4].) 
    Существует два различных ссылочных пути от отношения PREREQ к COURSE, но 
на этот раз они полностью независимы (и имеют совсем различное значение). 
(Более глубокое обсуждение этого вопроса приведено в [5.4].) 
    
    5.4. Ссылочная диаграмма показана на рис. 5.3. Так как в базе данных есть 
ссылочный цикл (т.е. существует ссылочный путь от каждого из двух отношений к 
себе), то либо в одном или двух потенциальных ключах должно быть допустимо 
использование null-значений (однако мы не одобряем такого подхода), либо 
проверка целостности должна быть отложена (об этом в дальнейших главах книги). 
    
    Рис. 5.3. Ссылочная диаграмма с циклом 

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

    5.5. Мы приводим только оператор CREATE BASE RELATION (схематически): 

    CREATE BASE RELATION EMP ( EMP# ... , 
    ...... / 
    JOB  ... ) PRIMARY KEY ( EMP# ) ) ; 
    CREATE BASE RELATION PGMR ( EMP# ... , 
    LANG ... ) 
    PRIMARY KEY ( EMPt ) FOREIGN KEY ( EMP# ) REFERENCES EMP DELETE CASCADES 
UPDATE CASCADES ; 
    
    DEPT         | MGR_EMP#       i                    DEPT# |           EMP   
       | 
    
    132	Часть II. Реляционная модель 

    Пояснения: 
    1.   В этом примере иллюстрируется наше замечание о том, что внешний ключ 
может быть также потенциальным ключом в отношении, содержащем его. В отношении 
ЕМР содержится список всех служащих, а в отношении PGMR — список тех служащих, 
которые работают программистами; поэтому каждый номер служащего, находящегося 
в отношении PGMR, должен также находиться в отношении ЕМР (заметьте, что 
обратное не верно). Первичный ключ отношения PGMR является внешним ключом, 
ссылаясь на первичный ключ отношения ЕМР; обратите внимание, что эти два 
отношения можно рассматривать соответственно как су-пертип объектов (служащие) 
и подтип объектов (программисты). Обычно именно таким образом в реляционных 
базах данных представляют супертипы и подтипы объектов. (Об этом пойдет речь 
далее в книге.) 
    2.  Заметьте, что в этом примере существует еще одно ограничение 
целостности, которое также необходимо поддерживать: служащий должен быть 
представлен в отношении PGMR тогда и только тогда, когда значение атрибута 
EMP.JOB для этого служащего — "программист". Но это не ссылочное ограничение. 
    5.6. Не существует "правила вставки" в явном виде для потенциальных 
ключей, потому что операции вставки для ссылающегося отношения (а также 
операции обновления для внешнего ключа в ссылающемся отношении) контролируются 
с помощью самого правила ссылочной целостности, т.е. с помощью требования, 
гласящего, что не должно быть несогласованных значений внешнего ключа. Поясним 
это другими словами на примере базы данных поставщиков и деталей. 
    • Попытка вставить кортеж поставки будет успешной, если номер поставщика в 
этом кортеже существует как номер поставщика в отношении S и номер детали в 
этом кортеже существует как номер детали в отношении Р. 
    • Попытка обновить кортеж поставки будет успешной, если номер поставщика в 
этом кортеже существует как номер поставщика в отношении S и номер детали в 
этом кортеже существует как номер детали в отношении Р. 
    Обратите также внимание, что "правило вставки" применяются к ссылающемуся 
отношению, а правила удаления и обновления применяются к ссылочному отношению. 
Поэтому "правило вставки" нельзя рассматривать как правило, схожее с правилами 
удаления и обновления. Это еще одна причина, по которой мы избегаем 
употреблять название "правило вставки". 
    5.7. В обоих отношениях существует в точности один потенциальный ключ, а 
именно пустое множество атрибутов {} (обычно обозначаемое 0). 
    Понятие пустого потенциального ключа требует некоторого уточнения. Такой 
потенциальный ключ может быть только в отношениях DEE и DUM. Однако если 
пустое множество является потенциальным ключом отношения /?, то должны быть 
выполнены следующие условия: 
    • Этот потенциальный ключ должен быть единственным потенциальным ключом 
отношения R, так как любое другое множество атрибутов этого отношения будет 
включать в себя пустое множество, а значит, будет нарушено требование 
неизбыточности. (Этот потенциальный ключ будет также и первичным, если должен 
быть выбран первичный ключ.) 
    • В отношении R не может содержаться более одного кортежа, потому что в 
пустом множестве атрибутов любой кортеж имеет одно и то же значение. 
    Обратите внимание, что с помощью нашего синтаксиса мы не сможем определить 
такое отношение. Например: 

    Глава 5. Целостность реляционных данных...	133 

    CREATE BASE RELATION R ( X . . ., Y..., Z ... ) PRIMARY KEY ( ) ; 

    Мы также не сможем определить отношение без атрибутов, т.е. отношение, 
которое может принимать только значения DEE и DUM: 

    CREATE BASE RELATION R ( ) 
    PRIMARY KEY ( ) ; 

    Вернемся к вопросу о пустом потенциальном ключе: конечно, если 
потенциальный ключ может быть пустым, то может быть пустым и соответствующий 
ему внешний ключ. Отметим, что согласно определениям пустые потенциальный и 
внешний ключи не являются ни простыми, ни составными. 
    5.8. Пусть от — наименьшее целое число, большее либо равное и/2. 
    Отношение R будет иметь максимально возможное количество потенциальных 
ключей, если либо все возможные множества из т атрибутов являются 
потенциальными ключами, либо п — нечетное число и все возможные множества из 
/и-1 атрибутов являются потенциальными ключами. В обоих случаях максимальное 
количество потенциальных ключей равно 
    п\/(т\*(п-т)\). 
    Ниже приведены два примера отношений с максимальным количеством 
потенциальных ключей. Первый — это упрощенная форма отношения ELEMENTS, 
описанного в этой главе: 

    CREATE BASE RELATION ELEMENTS 
    ( NAME .. . , SYMBOL ... , NUMBER .. .) CANDIDATE KEY ( NAME ) CANDIDATE 
KEY ( SYMBOL ) CANDIDATE KEY ( NUMBER ) 
    Во втором отношении описываются браки: 
    CREATE BASE RELATION MARRIAGES 
    ( WIFE ... , HUSBAND ... , WEDDING_DATE. .. ) CANDIDATE KEY ( WIFE, 
HUSBAND ) CANDIDATE KEY ( HUSBAND, WEDDING_DATE ) CANDIDATE KEY ( 
WEDDING_DATE, WIFE ) 

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

    134	Часть II, Реляционная модель 

