В.З. ПЕРВИЧНЫЕ И ВНЕШНИЕ КЛЮЧИ
Единственным и самым важным аспектом сущностей в реальном мире является их отличимость. Следовательно, при рассмотрении проблемы представления сущностей в базе данных нужно ответить на единственный самый важный вопрос, каким образом представители этих сущностей отличаются друг от друга, т. е. каким образом идентифицируются сущности в базе данных.
В последующем, в процедуре проектирования, которая в общих чертах рассматривается в следующем разделе, каждый тип сущностей (поставщики, служащие, поставки, заказы на закупки и т. д.) независимо от того, являются ли они стержневыми, характеристическими или ассоциативными, будет отображаться в базовую таблицу системы DB2. Свойства типа сущностей будут отображаться в поля этой базовой таблицы. Вследствие того что функцию идентификации в реляционной модели выполняют первичные ключи (см. определение этого термина в Приложении А), каждая такая базовая таблица должна иметь первичный ключ, представляющий идентифицирующее свойство рассматриваемого типа сущностей Ниже приведены первичные ключи для базы данных поставщиков и деталей:
— таблица S : поле S НОМЕР_ПОСТАВЩИКА
— таблица Р : поле Р. НОМЕР_ДЕТАЛИ
— таблица SP : составное поле SP.(НОМЕР_ПОСТАВЩИКА, НОМЕР_ДЕТАЛИ)
Таким образом, для каждой базовой таблицы в проекте проектировщик базы данных должен специфицировать поле или комбинацию полей, образующих первичный ключ для этой базовой таблицы. Ниже, в разделе В.5 приводятся некоторые предложения относительно способа записи такой спецификации.
Далее, если сущности представляются базовыми таблицами, то соединения между сущностями представляются с помощью внешних ключей в этих базовых таблицах (определение этого термина см. опять таки в Приложении А). Более строго:
— Если сущности типа В обозначают сущность типа А и если эти типы сущностей представлены базовыми таблицами соответственно ТВ и ТА, то ТВ будет включать внешний ключ, соответствующий первичному ключу ТА.
— Подобным же образом, если сущности типа С являются ассоциациями между сущностями типа А и сущностями типа В, и эти типы сущностей представлены базовыми таблицами соответственно ТС, ТА и ТВ, то ТС будет включать внешний ключ, соответствующий первичному ключу ТА, и внешний ключ, соответствующий первичному ключу ТВ. Примером для этого последнего случая могут служить поставки, где внешними ключами являются SP.НОМЕР_ПОСТАВЩИКА, соответствующий первичному ключу НОМЕР_ПОСТАВЩИКА таблицы S, и SP.НОМЕР_ДЕТАЛИ, соответствующий первичному ключу НОМЕР_ДЕТАЛИ таблицы Р. Рассмотрим теперь пример, иллюстрирующий предыдущий случай. Снова предположим, что служащие обозначают отделы. Тогда таблица служащих (например, СЛУЖАЩИЕ) будет включать внешний ключ (к примеру, СЛУЖАЩИЕ.НОМЕР_ОТДЕЛА), соответствующий первичному ключу (например, НОМЕР_ОТДЕЛА) таблицы отделов (например, ОТДЕЛЫ).
Таким образом, при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных основной вопрос, на который следует получить ответ: «Каковы внешние ключи?». Но на этом дело не заканчивается. Для каждого внешнего ключа необходимо решить три дальнейших вопроса:
1. Может ли данный внешний ключ принимать неопределенные значения? Иными словами, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? В случае поставок это, по всей вероятности, невозможно — поставка, осуществляемая неизвестным поставщиком, или поставка неизвестной детали не имеют смысла. Но в случае со служащими такая ситуация однако могла бы иметь смысл — вполне возможно, что какой-либо служащий в данный момент не зачислен вообще ни в какой отдел. Заметим для ясности, что ответ на рассматриваемый вопрос (допускаются ли неопределенные значения для заданного внешнего ключа) зависит не от прихоти проектировщика базы данных, а от фактического образа действий, принятого в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют, конечно, отношение и к вопросам 2 и 3, обсуждаемым ниже.
2. Что должно случиться при попытке удаления целевой сущности, на которую ссылается внешний ключ? Например, может быть предпринята попытка удаления поставщика, для которого существует по крайней мере одна соответствующая поставка. Для определенности рассмотрим этот случай подробнее. Вообще говоря, существуют три возможности:
| — CASCADES (КАСКАДИРУЕТСЯ) | Операция удаления «каскадируется» с тем, чтобы удалить также эти соответствующие поставки.. |
| — RESTRICTED (ОГРАНИЧИВАЕТСЯ) | Операция удаления «ограничивается» случаями, где нет таких соответствующих поставок. В противном случае она отвергается |
| — NULLIFIES (УСТАНАВЛИВАЕТСЯ НЕОПРЕДЕЛЕННОЕ ЗНАЧЕНИЕ) | Для всех таких соответствующих поставок внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен принимать неопределенных значений. |
3. Что должно происходить при попытке обновления первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются, вообще говоря, те же самые три возможности, как и в случае операции DELETE:
| — CASCADES (КАСКАДИРУЕТСЯ) | Операция обновления «каскадируется» с тем, чтобы обновить также и внешний ключ в этих соответствующих поставках. |
| — RESTRICTED (ОГРАНИЧИВАЕТСЯ) | Операция обновления «ограничивается» случаями, где нет таких соответствующих поставок. В противном случае она отвергается. |
| — NULLIFIES (УСТАНАВЛИВАЕТСЯ НЕОПРЕДЕЛЕННОЕ ЗНАЧЕНИЕ) | Для всех таких соответствующих поставок внешний ключ устанавливается в неопределенное значение, а затем обновляется этот поставщик. Такая возможность, конечно, неприменима, если данный внешний ключ не может принимать неопределенных значений. |
Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющие этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на три указанных выше вопроса, т. е. три ограничения, которые относятся к этому внешнему ключу. Некоторые предложения о способе записи таких спецификаций опять-таки можно найти ниже в разделе В.5.
Завершим этот раздел кратким замечанием относительно характеристик. По определению характеристика является обозначающей сущностью, существование которой зависит от типа сущностей, которые она обозначает. Обозначение будет, конечно, представляться внешним ключом в таблице, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:
NULLS NOT ALLOWED
return false">ссылка скрытаDELETE (цель) CASCADES
UPDATE (первичный ключ целевой сущности) CASCADES
Указанные спецификации представляют зависимость по существованию характеристических сущностей. Здесь использован синтаксис, рассматриваемый ниже в разделе В.5.