Всегда состоит только из одного атрибута.

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

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

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

Здесь, вероятно, стоит заметить, что суррогаты не являются (как полагают некоторые авторы) тем же, что и идентификаторы кортежей , потому что последние идентифицируют кортежи, а суррогаты идентифицируют сущности, между тем как никакой прямой связи типа один к одному между кортежами и сущностями не существует (в частности, вспомните об идентификаторах производных кортежей). Более того, идентификаторы кортежей обладают дополнительными преимуществами в отнощений производительности, чего не скажешь о суррогатах, поскольку доступ к кортежу через идентификатор кортежа происходит очень быстро (предполагается, что кортежи базового отношения отображаются непосредственно на физическую структуру хранения, что в действительности имеет место во многих современных профаммных продуктах). Кроме того, идентификаторы кортежа обычно скрыты от пользователя, тогда как суррогаты чаще всего - нет (по принципу информации), т.е. идентификатор кортежа нельзя сохранить, как значение атрибута, а суррогат можно. Короче говоря, суррогаты являются логической концепцией, а идентификаторы кортежей - физической. 13.I7.Halpin Т. Conceptual Schema and Relational Database Design (2nd edition). - Sydney, Australia: Prentice-Hall of Australia Pty., Ltd. 1995.

Подробное описание ORM-модели (см. аннотации к двум следующим работам). I3.18.Halpin Т. Business Roles and Object-Role Modeling DBP&D, № 10, October, 1996. Великолепное введение в объектно-ролевое моделирование (object-role modeling- ORM) [13.17]. Автор начинает с наблюдения, что [в отличие от] ER-модели, для которой существуют десятки разных диалектов, ORM-модель имеет лишь несколько диалектов с незначительными различиями . {Замечание. Один из таких диалектов называется NIAM-моделью [13.29].) ORM-моделирование также называется .моделирование. на основе фактов, потому что проектировщик начинает процесс моделирования с записи (на естественном языке или с помощью специальных графических обозначений) ряда элементарных фактов (или, точнее, типов фактов), которые в совокупности характеризуют все особенности моделируемой организации. Ниже приводятся некоторые примеры таких типов фактов.

Каждый работник имеет одно имя.

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

Если работник el отчитывается перед работником е2, то обратное (т.е. работник е2 отчитывается перед работником el) невозможно.

Ни один работник не может руководить одним и тем же проектом и оценивать результаты его выполнения.

Как видите, типы фактов на самом деле представляют собой предикаты или бизнес-правила. Как следует из названия этой статьи, подход к проектированию базы данных в ORM-модели очень близок к тем методам, которые предпочитают сторонники использования бизнес-правил [8.18], [9.19] и сам автор. В общем случае факты представляют собой роли, выполняемые объектами в отношениях между собой (отсюда и название объектно-ролевое моделирование ). Обратите внимание, что объекты в действительности представляют сущности, а не объекты в конкретном смысле этого термина, описанном в части VI этой книги, а связи между ними вовсе не обязательно являются бинарными. Однако факты действительно являются элементарными, т.е. они не могут быть декомпозированы на меньшие факты.

Замечание. Основная идея о том, что база данных на концептуальном уровне должна содержать только элементарные (или неприводимые) факты, принадлежит Холлу (НоИ), Оулетту (Owlett) и Тодду (Todd) [13.16].

Обратите внимание, что в ORM-модели нет понятия атрибут . В результате, как показано в этой статье, ORM-проекты концептуально проше и устойчивее, чем их аналоги, выполненные в RM-модели (в этой связи см. также [13.19]). Однако атрибуты могут появляться и действительно появляются при автоматической генерации на основе ORM-макета соответствуюшего SQL-описания проекта или его RM-макета. В ORM-модели также особо подчеркивается использование фактов-образцов (т.е. экземпляров фактов-образцов, которые иначе можно было бы назвать предложениями) в качестве способа проверки корректности проекта со стороны конечного пользователя. Как утверждается в данной статье, такой подход достаточно просто реализовать при моделировании на основе фактов, но гораздо труднее реализовать при работе с ER-моделью.

Конечно, существует много логически эквивалентных способов описания данного предприятия и соответственно много логически эквивалентных ORM-схем. По этой причине ORM-моделирование включает набор правил преобразования, позволяющих выполнять преобразования с получением логически эквивалентных схем. Поэтому ORM-инструменты позволяют выполнять некоторую оптимизацию проектов в соответствии с требованиями разработчика. Как уже говорилось выше, с их помощью можно также генерировать SQL-описание проекта или его RM-модель, опираясь на созданную ORM-модель, либо выполнять обратную процедуру восстановления ORM-модели из SQL-описания проекта или его RM-модели. В зависимости от используемой СУБД созданное SQL-описание проекта может включать объявление ограничений целостности (в стиле SQL/92) или предусматривать их поддержку с помощью хранимых процедур или триггеров. В отношении ограничений отметим, что в отличие от ER-модели ORM-модель по определению содержит развитый язык для формулирования ограничений . (Однако в [13.19] автор признает, что не все бизнес-правила можно выразить с помощью принятых в ORM-модели графических обозначений. Для некоторых из них все же придется использовать текстовые формулировки.)

Наконец, ORM-модель, безусловно, может рассматриваться как высокоуровневое абстрактное представление базы данных (на самом деле следовало бы возразить, что оно, скорее, ближе к чистому, возможно, даже в некоторой степени строгому, реляционному представлению). Благодаря этому появляется возможность задавать запросы непосредственно ей самой [13.19]. 13.19.Halpin Т. Conceptual Queries Data Base Newsletter, 26 № 3, March-April, 1998.

Цитата из аннотации к этой работе: Формулировка нетривиальных запросов с помощью таких реляционных языков профаммирования, как SQL и QBE, может оказаться очень сложной задачей для конечных пользователей. Язык ConQuer является новым концептуальным языком создания запросов, который основан на объектно-ролевом моделировании и предоставляет простой и понятный пользователям способ формулирования запросов... В этой статье описаны преимущества [такого языка] по сравнению с традиционными языками запросов в отношении формулирования запросов и бизнес-правил .

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

Работник

+-В0ДИТ Машину +-работает в Отделе

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

SELECT DISTINCT XI.EMPt, Xl.BRANCHt FROM EMPLOYEE AS XI, DRIVES AS X2 WHERE XI.EMPt = X2.EMPt ;

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

SELECT DISTINCT Xl.EMPt, X3.BRANCHt

FROM EMPLOYEE AS XI, DRIVES AS X2, WORKS FOR AS X3

WHERE Xl.EMPt = X2.EMPt AND Xl.EMPt = X3.EMPt;

Однако в запрос на языке ConQuer никаких изменений вносить не потребуется. Как видно из предыдущего примера, язык ConQuer может рассматриваться, как весьма строгий вариант реализации логической независимости от данных. Для объяснения этого замечания придется несколько уточнить архитектуру ANSI/SPARC [2.1], [2.2]. Как говорилось в главе 2, логическая независимость от данных означает независимость от изменений концептуальной схемы, но дело в том, что в предыдущем примере не было сделано никаких изменений концептуальной схемы! Причина в том, что современные SQL-продукты поадерживают работу с концептуальной схемой не совсем должным образом. Вместо этого они, скорее всего, поадерживают работу с 51-схемой. При этом SQL-схема может рассматриваться как некий промежуточный уровень между истинным концептуальным