Целостность реляционных данных

Ограничения целостности

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

Например, кортеж отношения P (Детали) — деталь Р7 весит минус 25 кг —не имеет смысла, поскольку вес в реальном мире не может быть отрицательным. Следовательно, определение БД нуждается в расширении, включающем правила целостности, назначение которых в том, чтобы информировать СУБД о разного рода ограничениях реального мира, а значит и предотвращать появление таких недопустимых конфигураций значений.

Большинство БД подчиняется очень многим специальным правилам целостности, в том смысле, что они применяются к одной конкретной БД. Например, (1) Вес деталей должен быть больше нуля, (2) Значения статуса поставщиков должны быть в диапазоне 1-100, (3) Статус поставщиков из города Красноярск должен быть равен 40.

Однако в реляционной модели есть два особых общих правила целостности, которые применяются к любой БД. То есть во 2-й части реляционной модели определяются два ограничения, которые должны выполняться в любой реляционной БД:

(1) целостность сущностей (связана с первичным ключом),

(2) ссылочная целостность (связана с внешними ключами).

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

(1) Свойством уникальности — нет двух различных кортежей в R с одинаковым значением K.

(2) Свойством неизбыточности — никакое из подмножеств К не обладает свойством уникальности (т.е. настоящий потенциальный ключ не должен включать лишних атрибутов для идентификации уникальности.).

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

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

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

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

PS:

Потенциальные ключи обеспечивают основной механизм адресации на уровне кортежей в реляционной системе. Следовательно, единственный гарантируемый системой способ точно указать на какой-нибудь кортеж — это указать значение некоторого первичного ключа. Например, S# — первичный ключ, тогда с помощью выражения S WHERE S# = ‘S3’ мы получим не больше одного кортежа. CITY — не первичный ключ и с помощью выражения S WHERE CITY = ‘КАНСК’ мы получим в общем случае количество кортежей, которое нельзя предсказать. Таким образом, первичные ключи имеют такое же фундаментальное значение для успешной работы реляционной системы, как адресация основной памяти для успешной работы компьютера.

Целостность сущностей

Так как первичные ключи фактически служат идентификаторами объектов, то есть предназначены для различения объектов, то значения этих идентификаторов не могут содержат Null-значения (неопределенные значения).

Метаправило целостности сущностей: атрибуты, входящие в состав первичного ключа, не могут принимать null-значения.

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

Null-значение — специальный маркер, используемый для представления отсутствующей информации (это не нули или пробелы!). Например, поставка существует, но количество товара не известно.

Null-значение обозначает тот факт, что значение неизвестно.

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

Различные объекты предметной области, информация о которых хранится в БД, всегда взаимосвязаны друг с другом.

Важно выяснить, каким образом данные, хранящиеся в отношениях Поставщик, Товар, Поставка, связаны друг с другом. Эта связь определяется семантикой предметной области и описывается фразами: Один Поставщик может выполнять несколько Поставок, Один Товар может поставляться несколькими Поставками.

Это основной вид связи — один-ко-многим. Отношение, входящее в связь со стороны один, называют родительским отношением. Отношение, входящее в связь со стороны много, называется дочерним отношением.

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

Взгляните на атрибут S# (Номер поставщика) отношения SPJ (Поставка). Ясно, что значение этого атрибута допустимо только в том случае, если такое же значение существует в качестве значения первичного ключа S# отношения S (Поставщики). Например, не имеет смысла включать в SPJ поставку для поставщика S8, если в отношении S не существует поставщика S8. Таким образом, атрибут S# отношения SPJ являются примером внешнего ключа.

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

(1) существует базовое отношение R1 с первичным ключом К,

(2) каждое значение внешнего ключа FK в отношении R2 является или null-значением, или совпадает со значением первичного ключа К некоторого кортежа в отношении R1.

R1 — родительское отношение, R2 — дочернее отношение.

PS:

1. Внешний ключ, так же как и потенциальный, может быть простым и составным.

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

3. Для внешнего ключа не требуется, чтобы он был компонентом некоторого потенциального ключа (как было в нашем примере).

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

5. Так как внешние ключи фактически служат ссылками на кортежи в другом отношении, то эти ссылки не должны указывать на несуществующие объекты.

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

То есть если В ссылается на А, то А должно существовать.

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

Метаправило ссылочной целостности выражено в терминах состояния БД. Любое состояние БД не удовлетворяющее этому правилу, некорректно, но как избежать таких состояний? Для этого существуют правила внешних ключей — правила удаления и обновления, которые задаются при определении внешнего ключа.

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