Отношения и предикаты

Каждое отношение имеет некоторую интерпретацию. Например, интерпретация отношения ПОСТАВЩИКИ может быть следующей:

Поставщик с определенным номером (НОМЕР_ПОСТ) имеет определенное имя (ИМЯ) и располагается в определенном городе (АДРЕС); кроме того, нет двух поставщиков с одинаковыми номерами. Предыдущее утверждение это пример того, что называютпредикатом,или функцией значения истинности; здесь функцией трех аргументов. Подстановка значений этих аргументов эквивалентна вызову функции (или «подтверждению предиката»), а значит, получению выражения, называемоговысказыванием, которое может быть либоистинойлибо ложью.

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

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

• Значение НОМЕР_ПОСТ принадлежит домену номеров поставщиков.

• Значение ИМЯ принадлежит домену имен.

• Значение АДРЕС принадлежит домену адресов (городов).

• Значение НОМЕР_ПОСТ должно быть уникальным среди всех значений отношения.

Null-значения; потенциальные и внешние ключи

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

Обратите внимание, null-значенияэто не то же самое, что пробелы или числовые нули; фактически они вообще не являются реальными значениями.

В общем, для данного атрибута может быть разрешено или не разрешено содержать null-значения. Например, вMSAccessследует установить свойство атрибута «Обязательное поле» в значение «Нет», чтобы данное поле допускало вводnull-значений. Если данному атрибуту не разрешено содержатьnull-значения, система будет отвергать любые попытки вводаnull-значения в эту позицию.

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

Это правило применяется только для базовых отношений. Другие отношения действительно могут иметь первичный ключ, для которого null-значения допустимы. Рассмотрим такой пример. Предположим, что для цвета детали «допустимыnull-значения». Теперь рассмотрим отношение, представляющее собой результат запроса «Список всех цветов деталей». Такое отношение имеет один атрибут, который является потенциальным ключом и, следовательно, первичным ключом, а один из кортежей отношения имеетnull-значение в области первичного ключа. Таким образом, правило целостности объектов предполагает (неприятное по Дейту) разграничение между базовыми и другими отношениями. Неприятность заключается в том, что если мы попытаемся сохранить результат запроса как новое базовое отношение, его атрибут мы не сможем определить в качестве первичного ключа. В связи с этим отметим, что реальные СУБД не всегда и не во всем строго соответствуют реляционной теории. Так, например, в СУБДMSAccessдопустимы базовые отношения, не имеющие потенциальных ключей. При попытке сохранить такое отношение будет предложено создать первичный ключ (добавить дополнительное поле, обеспечивающее уникальный идентификатор типа счетчик), однако можно отказаться от такой возможности.

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

Обратимся к базе данных отделов и сотрудников. Возможна ситуация, когда отдельный сотрудник не причислен ни к одному из отделов (например, директор предприятия). Для решения подобных вопросов реляционная модель традиционно разрешает появление null-значений в полях внешних ключей.Null-значения подходят для представления атрибутов типа «значение не существует» и «значение не известно».

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

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

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

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