Реляционные ключи.

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

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

Первичный ключ – потенциальный ключ, который выбран для уникальной идентификации кортежей.

Альтернативный ключ – потенциальный ключ, не ставший первичным ключом.

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

См. предыдущий пример концептуальной модели

РАБОЧИЙ (Шифр _рабочего, Фамилия, Адрес)

НАЗНАЧЕНИЕ (Шифр _рабочего, Шифр _ задания, Дата, Продолжительность)

ЗАДАНИЕ (Шифр _ задания, Адрес _ задания, Тип, Статус)

Ясно, что значения атрибутов Шифр_рабочего и Шифр_задания в отношении НАЗНАЧЕНИЕ должны соответствовать значениям присутствующим в отношениях РАБОЧИЙ и ЗАДАНИЕ.

Атрибуты Шифр_рабочего и Шифр–задания в отношении НАЗНАЧЕНИЕ являются примерами того, что мы называем внешними ключами.

Ссылочная целостность. Вместе с понятием внешнего ключа реляционная модель включает правило ссылочной целостности:

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

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

Правила внешних ключей. Некорректных состояний БД можно избежать:

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

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

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

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

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

1. Что должно случиться при попытке удалить объект ссылки внешнего ключа?

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

• Ограничить – «ограничить», операцию удаления, до момента, когда не будет существовать соответствующих поставок (в противном случае операция запрещается);

• Каскадировать – «каскадировать» операцию удаления, удаляя также соответствующие поставки.

2. Что должно случиться при попытке обновить потенциальный ключ, на который ссылается внешний ключ?

• Ограничить – «ограничить» операцию обновления до тех пор, когда не будет существовать соответствующих поставок (в противном случае операция запрещается);

• Каскадировать – «каскадировать» операцию обновления, обновляя также внешний ключ в соответствующих поставках.

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

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

На рис. показаны три отношения: отношение R3 ссылается на R2, а отношение R2 - на R1.

Рис. 2. Цепочка отношений

Если для пары R2_R1 установлено правило КАСКАД, а для пары R3R2 – правило ОГРАНИЧЕНИЕ, то СУБД будет фиксировать противоречивость этих правил:

с одной стороны допускается каскадное удаление записей из отношений R2, а с другой стороны действует правило типа ОГРАНИЧЕНИЕ, которое запрещает удаление этих записей. Следовательно, не выполняется цепочка операций и база данных остается неизменной.

Целостность реляционных данных. Большинство баз данных поддерживает следующие правила целостности:

1. Целостность объектов – ни один элемент первичного ключа отношения не может быть Null – значением.

2. Целостность атрибута – значения каждого атрибута берутся из соответствующего домена.

3. Ссылочная целостность – база данных не должна содержать несогласованных значений внешних ключей.

4. Корпоративные ограничения. Пользователи сами могут указывать специфические ограничения на значения атрибутов.

Например, список правил для поставщиков деталей может включать следующие правила:

• номера поставщиков должны принимать значения до четырех десятичных цифр;

• значение статуса поставщика должно быть в диапазоне

  1-10;

• если город поставщика – Москва, то статус поставщика должен быть 10;

и т. д.