Обозначение сущностей
Очевидна потребность в уникальных и неизменных идентификаторов сущностей базы данных, таких как служащие, поставщики, детали и т.п. Первоначально в реляционной модели для этой цели предназначались определяемые и контролируемые пользователями первичные ключи. Однако имеется три трудности при использовании контролируемых пользователем ключей в качестве неизменных суррогатов (permanent surrogate) сущностей.
- Фактические значения контролируемых пользователем ключей определяются пользователями и, следовательно, должны подвергаться изменениям с их стороны (если, например, сливаются две компании, то две базы данных служащих могут быть объединены таким образом, что некоторые или все последовательные номера служащих могут при этом измениться).
- Два отношения могут иметь контролируемые пользователем ключи, определенные на различных доменах (скажем, в одном из них используется код социального страхования, в то время как в другом – последовательный номер служащего), и тем не менее эти сущности обозначают одно и то же.
- Может оказаться необходимой поддержка информации о сущности либо перед тем, как ей был присвоено значение контролируемого пользователем ключа, либо после того, как она прекратила его иметь (допустим, претендент на работу и уволившийся).
Эти трудности имеют важное следствие – эквисоединение на общих значениях ключей может не давать того же результата, что и соединение на общих сущностях. Решение этой проблемы, предложенное частично в [4] и в более полном виде в [14], сводится к тому, чтобы ввести домены сущностей, которые содержат назначаемые системой суррогаты. Пользователи базы данных могут заставить систему сгенерировать или удалить некоторый суррогат, но они не имеют контроля над значением суррогата, и это значение им даже не демонстрируется.
Суррогаты ведут себя так, как будто у каждой сущности (независимо от типа) имеется свой собственный неизменный суррогат, уникальный во всей базе данных. Фактически, если взглянуть глубже, таким суррогатам, вероятно, придется изменяться (например, когда две ранее независимых базы данных объединяются в одну), однако всегда сохраняется следующее свойство: в реляционной модели два суррогата являются равными тогда и только тогда, когда они обозначают одну и ту же сущность в воспринимаемом мире сущностей.
Заметим, что система создала бы для двух сущностей, вводимых пользователями, различные суррогаты, что, по существу, предполагает различие этих сущностей. Специальная объединяющая (coalescing) команда позволяет пользователю сказать системе, что два объекта, которые ранее считались различными, на самом деле являются одним и тем же объектом.
В любой базе данных, основанной на RM/T, один из основных доменов служит источником всех суррогатов. Он называется E-доменом. Все атрибуты, определенные на E-домене, называются E-атрибутами. Для того чтобы можно было легко распознавать такие атрибуты, примем соглашение, что им даются имена заканчивающиеся специальным символом "
".С введением E-доменов, E-атрибутов и суррогатов не отменяются ключи, контролируемые пользователем. У пользователей часто будет возникать потребность в идентификаторах (таких как серийный номер детали), которые находятся полностью под их контролем, хотя они больше не обязаны изобретать ключ, контролируемый пользователем, если они того не желают.
Они должны будут, однако, помнить, что теперь имеется суррогат, который является первичным ключом и действительно обеспечивает неизменную идентификацию каждой сущности. Возможность выполнения эквисоединения на суррогатах предполагает, что пользователи видят заголовки таких столбцов, но не конкретные значения в этих столбцах.
