1. Ключи и целостность реляционных данных

Реляционная модель базы данных связана с тремя аспектами данных: структурой, обработкой и целостностью. Первые два аспекта были кратко рассмотрены в разделе 1. Целостность (от англ. integrity – неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, при вводе номера дня недели нельзя обнаружить, что вводимое значение 5 в действительности должно быть равно 3. Но значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Для этого ей следует сообщить, что номера дней недели должны выбираться из домена (1,2,3,4,5,6,7).

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

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

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

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

2. Свойством неизбыточности (никакое из подмножеств K не обладает свойством уникальности).

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

С понятием первичного ключа в реляционной модели связывают правило целостности объектов: Ни один элемент первичного ключа базового отношения не может быть Null-значением. Понятие Null-значения было предложено Е. Коддом для представления отсутствующей информации: если данный кортеж имеет Null-значение данного атрибута, то это означает, что в таком кортеже значение атрибута по некоторой причине отсутствует. Null-значения – это не то же самое, что пробел или числовой ноль. Это не реальные значения, а маркеры. Правило целостности объектов применяется только для базовых отношений и только для первичных ключей.

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

Сотрудники WHERE Табель=’В3'

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

Сотрудники WHERE Код_отдела=’А1'

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

Итак, потенциальный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый кортеж отношения. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать кортеж по оставшимся атрибутам. Каждое отношение обладает хотя бы одним потенциальным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так, для идентификации студента можно использовать либо уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества, номера группы и, может быть, дополнительных атрибутов, так как не исключено появление в одной группе двух студентов с одинаковыми фамилиями, именами и отчествами. Не допускается, чтобы первичный ключ отношения (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение (Null-значение). Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью кортеж отношения (экземпляр сущности). По тем же причинам необходимо обеспечить уникальность первичного ключа.

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

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

2. Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

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

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

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

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

В общем случае существует по меньшей мере две возможности:

• ограничение – «ограничить» операции до момента появления первой ссылки;

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

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

Реляционная модель допускает появление Null-значений среди атрибутов внешних ключей. Например, в некоторых организациях допускается, чтобы отдельные сотрудники не числились ни в одном отделе. В таком случае в соответствующем кортеже отношения «Сотрудники» будет отсутствовать код отдела, который должен быть значением для внешнего ключа. Поэтому значение внешнего ключа должно либо быть равным значению первичного ключа цели, либо быть полностью неопределенным. В связи с этим, более строгое определение внешнего ключа может быть таким: Внешний ключ FK в отношении R2 – это подмножество множества атрибутов R2 такое, что существует базовое отношение R1 с потенциальным ключом CK, для которого каждое значение FK в текущем значении R2 или является Null-значением, или совпадает со значением CK некоторого кортежа в текущем значении R1.

В дополнении к целостности отношений и целостности по ссылкам существует целостность, определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 1 до 10), принадлежность набору значений (пол "М" или "Ж"). В этом случае средством обеспечения целостности являются домены. С ними связано такое понятие, как целостность атрибута: Значение каждого атрибута берется из соответствующего домена. Это более фундаментальное правило, чем первые два.