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

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

атрибут полю (типу, а не экземпляру). Однако это соответствие в лучшем случае

приблизительное. Отношение следует рассматривать не как "просто файл", а как

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

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

следствие, в упрощении операторов, необходимых для работы с этими объектами.

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

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

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

принципом"). В частности, этими явными значениями представляются логические

связи в отношении и между отношениями; не существует видимых для пользователя

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

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

6[1]

Если рассматривать отношения как таблицы, то мы могли бы сказать, что, например,

переменная отношения S в разное время представляет разные таблицы. Однако заметьте, что в

этих разных таблицах будут разные строки, а столбцы будут одинаковые.

7[2]

Для читателей, знакомых с языком SQL, отметим, что в SQL существует возможность добавлять

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

ALTER TABLE. Однако эту операцию лучше рассматривать не как изменение существующей

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

заголовком.

8[3]

Точнее, всегда существует по крайней мере один потенциальный ключ. Мы предполагаем, что

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

приведено в главе 5.

9[4]

Понятие "последовательности" требуется для интерфейса между реляционной базой данных и

базовым языком, таким как С или COBOL. Но это требование для базовых языков, а не для

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

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

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

прикладного программного интерфейса—они не видны конечному пользователю.

10[5]

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

(S1,Smith,20,London) соответствует кортежу {<S#:'S1'>, <SNAME:'Smith'>, <STATUS:20>, <CITY:

'London'>}.

Целостность реляционных данных (стр. 113-130)

Глава 5

Целостность

реляционных данных:

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

1. 5.1. Введение

Часть реляционной модели, связанная с целостностью данных, с годами

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

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

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

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

версий этих определений имели догматический, а не логический характер. В этой

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

предпочтительными; и вообще, мы старались представить материал так, как сочли

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

отклонения от более ранних определений и описаний, мы даем некоторые замечания

относительно этих изменений и их причин.

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

немного философии.

1. 1. В любой момент времени любая база данных содержит некую определенную

конфигурацию значений данных, и, конечно, предполагается, что эта

конфигурация "отражает Действительность", т.е. является моделью или

представлением части реального мира.

2. 2. Просто определенная конфигурация значений не имеет смысла, если значения в

этой конфигурации не представляют определенного состояния реального мира.

Например, конфигурация для базы данных поставщиков и деталей, которая в

отношении Р содержала бы кортеж "деталь Р7 весит минус 25 фунтов", наверное,

не имела бы смысла, поскольку вес не может быть отрицательным в реальном

мире.

3. 3. Следовательно, определение базы данных нуждается в расширении,

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

информировать СУБД о разного рода ограничениях реального мира (таких как

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

предотвращать появление таких недопустимых конфигураций значений. В

примере с весом детали, конечно, все СУБД должны контролировать операции

INSERT и UPDATE на отношении Р, а также отказывать в выполнении операции,

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

Большинство баз данных подчиняется очень многим правилам целостности, и

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

легко включить следующие правила:

■ ■BBBBBBB номера поставщиков должны быть в форме Snnnn, где пппп может принимать

значение до четырех десятичных цифр;

■ ■BBBBBBB номера деталей должны быть в форме Рппппп, где ппппп может принимать

значение до пяти десятичных цифр;

■ ■BBBBBBB значение статуса поставщика должно быть в диапазоне 1-100;

■ ■BBBBBBB города поставщиков и деталей должны выбираться из определенного списка;

■ ■BBBBBBB цвета деталей должны выбираться из определенного списка;

■ ■BBBBBBB вес деталей должен быть больше нуля;

■ ■BBBBBBB количество при отправке должно быть умножено на 100;

■ ■BBBBBBB все красные детали должны сдаваться на хранение в Лондоне;

■ ■BBBBBBB если город поставщика — Лондон, то статус поставщика должен быть равен

20; и т.д.

Любое данное правило целостности является специфическим для базы

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

вышеприведенные примеры в этом смысле, Очевидно, тоже специфичны для

определенной базы данных. Однако в дополнение к специфическим правилам

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

далее в этой книге) в реляционной модели есть два общих особых правила

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

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

особых правила относятся к потенциальным (и первичным) ключам и ко внешним

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

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

имеется, к сожалению, один осложняющий дело фактор— это null-значения

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

допускать null-значения, портит всю картину. Из педагогических соображений при

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

влияние позже в этой главе.

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

Правила целостности будут рассматриваться главным образом с точки зрения их

применения к базовым отношениям. Причина, конечно, в том, что именно базовые

отношения должны отражать действительность, а значит, именно для базовых

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

правдоподобной, конфигурации значений. Однако на самом деле к производным

отношениям также применяются правила целостности. Например, если к базовому

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

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

этого отношения.

Как видно из этого примера, производными отношениями автоматически

наследуются определенные правила целостности отношений, от которых они

произведены. Но возможно, что для производных отношений существуют

некоторые дополнительные правила целостности, противоречащие или

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

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

отношений в явном виде. Примером тому может служить определение

потенциального ключа для представления.

Этот вопрос еще будет обсуждаться в последующих главах. В этой главе мы

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

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

то обо всем остальном нечего и думать.

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

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

нестрого, то первичный ключ — это просто уникальный идентификатор для

некоторого отношения. Однако первичный ключ на самом деле является частным

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

последнего понятия. Пусть R — некоторое отношение. Тогда потенциальный ключ,

скажем, К для R — это подмножество множества атрибутов R, обладающее

следующими свойствами:

1. 1.BBBBBB Свойством уникальности.

Нет двух различных кортежей в отношении R с одинаковым значением К.

1. 2.BBBBBB Свойством неизбыточности.

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

Обратите внимание, что (как было указано в главе 4) каждое отношение имеет,

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

кортежей; т.е. поскольку кортежи уникальны, то, по крайней мере, комбинация всех

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

■ ■BBBBBBB Либо эта комбинация обладает свойством неизбыточности, а значит, будет

потенциальным ключом (на самом деле единственным потенциальным ключом).

■ ■BBBBBBB Либо существует по крайней мере одно подходящее подмножество этой

комбинации, заведомо обладающее свойством уникальности и к тому же

обладающее свойством неизбыточности.

(Обсуждение свойства неизбыточности смотрите ниже.) На практике вместо

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

меньшая комбинация. Конечно, возможно отношение, в котором единственным

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

"сплошным ключом". Примером такого отношения может служить отношение SP из

базы данных поставщиков и деталей, если убрать из него атрибут QTY.

Обратите особое внимание на то, что данное выше определение

потенциального ключа относится к самому отношению (т.е. к значениям

отношения), а не к переменным отношения. Когда мы рассматриваем переменные

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

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

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

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

■ ■BBBBBBB Например, если мы говорим, что комбинация атрибутов {S#, P#} — это

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

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

значением этой комбинации; мы имеем в виду, что для всех возможных

отношений R, которые могут быть значениями SP, нет двух различных кортежей

отношения R с одинаковым значением этой комбинации. Поэтому для

переменных отношения нам нужно дополнить определение потенциального

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

Пусть R — некоторая переменная отношения. Тогда потенциальный ключ,

скажем, К для R — это подмножество множества атрибутов Я, всегда обладающее

следующими свойствами:

1. 1.BBBBBB Свойством уникальности.

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

одинаковым значением К.

2. 2.BBBBBB Свойством неизбыточности.

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

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

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

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

базового отношения (отметьте, что каждый оператор create base relation должен

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

candidate-key-definition

::= CANDIDATE KEY (attribute-commalist)

׀ PRIMARY KEY (attribute-commalist)

Примеры смотрите на рис. 3.9 и 4.3. (Однако обратите внимание, что на этих

рисунках показан лишь случай первичного, а не потенциального ключа. Случай

потенциального ключа обсуждается далее в этой главе.)

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

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

■ ■BBBBBBBBBBBB Во-первых, хотя на практике отношения чаще всего имеют только один

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

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

элементов. У каждого элемента есть уникальное имя, уникальное обозначение

(например, обозначение свинца — "Рb") и уникальное атомное число. Поэтому

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

CREATE BASE RELATION ELEMENTS

(NAME … ,

SYMBOL … ,

NUMBER … ,

… … ,

CANDIDATE KEY (NAME)

CANDIDATE KEY (SYMBOL)

CANDIDATE KEY (NUMBER)

■ ■BBBBBBBBBBBB Во-вторых, заметьте, что потенциальные ключи определены как

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

множества", т.е. фигурные скобки. Например, в базе данных поставщиков и

деталей {S#} — это потенциальный ключ отношения S, (Р#) — это

потенциальный ключ отношения Р, {S#, P#} — это потенциальный ключ

отношения SP. Однако в неформальном контексте скобки обычно опускают,

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

например, что S# (вместо {S#}) — это потенциальный ключ отношения S.

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

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

называется простым.

Кроме того, понятие неизбыточности требует некоторого уточнения. Дело в

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

неизбыточным, системе не будет известно об этом и потому она не сможет

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

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

{S#,CITY} вместо S#. Тогда система не сможет соблюдать ограничение,

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

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

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

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

лишних атрибутов для идентификации уникальности.

Замечание. Есть еще одна серьезная причина требования неизбыточности

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

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

(если бы такое было возможно), был бы также "избыточным" и отношение,

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

нормализации.

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

этой книги) неизбыточность часто называют минимальностью. Однако

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

говорим, что потенциальный ключ К1 "минимален", мы не имеем в виду, что не

существует другого потенциального ключа К2 с меньшим количеством атрибутов;

вполне возможно, что, например, ключ K1 состоит из четырех атрибутов, а ключ К2

только из двух. Поэтому мы будем использовать термин "неизбыточность".

■ ■BBBBBBBBBBBB И наконец, обратите внимание на то, что логическое понятие

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

индекса, хотя последний часто играет роль потенциального ключа. Другими

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

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

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

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

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

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

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

системе. Следовательно, единственный гарантируемый системой способ точно

указать на какой-нибудь кортеж — это указать значение некоторого

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

S WHERE S# = 'S3'

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

Аналогично, если атрибут

SNAME также будет потенциальным ключом для отношения S (обратите внимание,

что данные, приведенные на рис. 4.6, согласуются с этой гипотезой), с помощью

выражения

S WHERE SNAME = 'Blake'

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

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

с помощью выражения "

S WHERE CITY = 'Paris'

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

Таким образом, потенциальные ключи имеют такое же фундаментальное значение

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

успешной работы машины, на которой эта система установлена. И в качестве

выводов приведем следующее:

1. 1.BB "Отношения", которые не имеют потенциальных ключей, т.е. "отношения",

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

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

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

в возможностях отображения состояния, которое не является «действительно

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

дублирования кортежей.

Упоминающееся выше поведение с «нарушениями или отклонениями» и «не совсем

реляционное», связано с такими процессами, как обновление представлений и

оптимизация. (Но об этом в следующих частях книги.)

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

Как мы уже убедились, базовое отношение может иметь (хотя это, возможно,

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

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

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

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

ключами. В примере отношения ELEMENTS, приведенном выше в этой главе, мы

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

"название элемента" и "атомное число" будут альтернативными ключами. В случае

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

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

отношении. Следовательно, каждое базовое отношение должно всегда иметь

первичный ключ.

Замечание. Если множество потенциальных ключей имеет более одного

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

произвольным.

Наше мнение по этому вопросу следующее: выбор одного потенциального

ключа (если есть из чего выбирать) в качестве первичного определенно желателен

во многих случаях (даже в большинстве случаев), но это не подтверждается во всех

случаях, Аргументы в пользу этой точки зрения даны в [5.8].

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

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

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

во многих ситуациях весьма полезным (хотя с философской точки зрения это

выходит за рамки модели как таковой). Другими словами, первичные ключи могут

еще отстаивать свою немалую практическую (или по крайней мере историческую)

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

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

лишь подчеркиваем, что каждое базовое отношение должно иметь по крайней мере

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

Что касается наших собственных примеров, в основном, но не постоянно мы

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

отношений будет иметь первичный ключ (и мы будем продолжать помечать

первичные ключи в рисунках двойным подчеркиванием).

Вот соответствующий синтаксис (он уже приводился выше в этой главе):

Candidate-key-definition

:: = CANDIDATE KEY ( attribute-coimmalist )

|PRIMARY KEY ( attribute-commalist )

(Как уже упоминалось ранее, commalist означает список указанных

элементов через запятую.)

Внутри любого конкретного оператора create base relation должно быть, по

крайней мере, одно определение потенциального ключа. Но лишь одно из этих

определений может объявлять первичный ключ, т.е. только в одном определении

может содержаться выражение primary key.

И последнее замечание относительно терминологии. Термины

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

сокращением ключ. Термин "ключ" уже имеет слишком много значений в мире баз

данных. Например, только одна реляционная модель имеет потенциальные,

альтернативные, первичные и внешние ключи. В других контекстах используются

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

ключи, поисковые ключи, основные ключи, подчиненные ключи, ключи

шифрования, ключи расшифровки, ключи секретности и т.д., пока не надоест.

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

назначению, чтобы избежать возможной путаницы.

(В предыдущем издании этой книги мы договорились, что если какой-нибудь

один ключ и заслуживает называться этим термином (просто "ключ") и быть

выделенным из всего многообразия ключей, то это, очевидно, первичный ключ!

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

было бы правильнее использовать его в значении потенциальный ключ. Тот факт,

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

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

подходящими.)

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

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

S# отношения SP. Ясно, что данное значение для такого атрибута должно быть

допустимо для базы данных лишь в случае, если такое же значение существует в

качестве значения первичного ключа S# отношения S (в противном случае база

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

включать для отношения SP поставку для поставщика, скажем, S8, если бы в

отношении S не существовало поставщика S8. Аналогично, данное значение для

атрибута Р# отношения SP должно быть допустимо для базы данных лишь в случае,

если такое же значение есть в качестве значения первичного ключа Р# отношения Р;

и опять же не имело бы смысла включать для отношения SP поставку для

поставщика, скажем, Р8, если бы в отношении Р не существовало поставщика Р8.

Атрибуты S# и Р# отношения SP, таким образом, являются примерами того, что мы

называем внешними ключами.

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

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

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

первичным ключам, а не просто потенциальным ключам (например, [5.2]). Эта

позиция поддерживается и в предыдущей редакции этой книги, и в других

публикациях автора (например, [5.3, 5.4]). Однако наша сегодняшняя позиция

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

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

случаев; но это не подтверждается во всех случаях. (Аргументы в поддержку этой

позиции можно найти в [5.8].) Что касается примеров в этой книге, то мы

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

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

описание.

Пришло время уточнить основные идеи. Вот определение термина "внешний

ключ".

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

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

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

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

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

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

пояснениях.

1. 1.BBBBBB Заметьте, что внешние ключи, как и потенциальные, определены как

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

множества" (фигурные скобки). Например, в отношении SP базы данных

поставщиков и деталей внешние ключи, строго говоря, — это {S#} и {Р#}, а не

S# и Р#. Однако в неформальном контексте скобки обычно опускают, если это

множество содержит только один атрибут.

2. 2.BBBBBB По определению каждое значение данного внешнего ключа должно являться

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

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

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

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

поставщиков и деталей (примерные значения показаны на рис. 3.8) поставщик с

номером S5 не поставляет в данный момент никаких деталей.

3. 3.BBBBBB Данный внешний ключ будет составным, т.е. будет состоять из более чем

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

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

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

4. 4.BBBBBB Каждый атрибут, входящий в данный внешний ключ, должен быть

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

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

5. 5.BBBBBB Для внешнего ключа не требуется, чтобы он был компонентом первичного

ключа или какого-либо потенциального ключа в содержащем его отношении,

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

обладают таким свойством (в действительности два внешних ключа в

отношении SP вместе составляют первичный ключ этого отношения). Вот еще

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

3.6, показано в упрощенной форме):

В этой базе данных атрибут DEPT# отношения ЕМР является внешним ключом,

соответствующим первичному ключу DEPT# отношения DEPT; однако он, конечно,

не является компонентом первичного ключа ЕМР# (и никакого другого

потенциального ключа) отношения ЕМР. В действительности внешним ключом

может быть любой атрибут или какое-либо сочетание атрибутов (в базовом

отношении).

6. 6.BBBBBB Терминология. Значение внешнего ключа представлено ссылкой к кортежу,

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

кортеж или целевой кортеж). Поэтому проблема обеспечения того, что база

данных не включает никаких неверных значений внешних ключей, известна как

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

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

потенциальных ключей, называют ссылочным ограничением. Отношение,

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

отношение, которое содержит соответствующий потенциальный ключ, —

ссылочным отношением или целевым отношением (target relation).

7. 7.BBBBBB Ссылочные диаграммы. Рассмотрим снова базу данных поставщиков и

деталей. Существующие в базе данных ссылочные ограничения можно

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

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

которого стрелка выходит; этот ключ специфически ссылается

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

Замечание. Для простоты здесь игнорируется небольшая тонкость, которую

необходимо учитывать, когда имеешь дело с внешним ключом, ссылающимся на

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

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

именами атрибутов (именем атрибута), которые составляют соответствующий

внешний ключ. Например:

В этой книге, однако, мы будем использовать такие пометки лишь в тех

случаях, когда их отсутствие может привести к путанице или двусмысленности.

8. 8.BBBBBB Отношение, конечно, может быть одновременно ссылочным и