Candidate-key-definition

:: = CANDIDATE KEY (attribute-coimmalist)

|PRIMARY KEY (attribute-commalist)

(Как уже упоминалось ранее, commalist означает список указанных элементов через запятую.)

Внутри любого конкретного оператора create base relation должно быть, по крайней мере, одно определение потенциального ключа. Но лишь одно из этих определений может объявлять первичный ключ, т.е. только в одном определении может содержаться выражение primary key.

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

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

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

Обратимся вновь к базе данных поставщиков и деталей и рассмотрим атрибут 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, такое что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом отношении атрибут MGR_EMP# представляет номер служащего для менеджера, который идентифицируется атрибутом ЕМР# как служащий. Здесь ЕМР# — первичный ключ, a MGR_EMP# — внешний ключ, который ссылается на этот первичный. (Например, кортеж для служащего Е4 может включать значение MGR_EMP# кортежа ЕЗ, который представляет ссылку к кортежу ЕМР для служащего ЕЗ. Ниже будет разъяснена конструкция RENAME.) Такие отношения иногда называют самоссылающимися.

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

11. 11. Соответствие внешний к потенциальному ключу иногда называют "клеем", который удерживает базу данных как единое целое. То же самое можно сказать и иначе: такое соответствие представляет собой некоторое отношение или взаимосвязь между кортежами. Однако обратите внимание, что не все отношения представлены этими соответствиями. Например, есть, отношение между размещенными в одном городе поставщиками и деталями, представленное атрибутами CITY отношений S и Р. Однако такие атрибуты CITY не являются внешними ключами. Они могли бы стать внешними ключами, если бы в базу данных было добавлено отношение с атрибутом CITY как потенциальным ключом.

Вот синтаксис для указания внешнего ключа (обратите внимание, что данный оператор CREATE BASE RELATION может включать нуль или более определений внешних ключей):

FOREIGN KEY (element-commalist) REFERENCES base-relation

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

Date: 2016-05-25; view: 517; Нарушение авторских прав