2. Обычно поддерживается не реляционная структура, а множество других структур, которые основываются на пакетах, массивах и т.д. В связи с этим напомним наше утверждение, что классы, т.е. типы, плюс отношения необходимы и достаточны на логическом уровне (см. главу 3). А поскольку речь идет об основной модели, мы считаем, что массивы и все остальное является ненужным и нежелательным. На наш взгляд, причиной того, что в объектных системах отдано предпочтение коллекциям, а не отношениям (фактически отношения почти полностью отвергнуты), является, опять же, путаница между понятиями модели и реализации.

В связи с выполнением произвольных запросов возникает еше один важный вопрос, а именно: какой класс является результатом. Предположим, например, что необходимо выполнить запрос Получить имена и размер заработной платы всех служащих в отделе программирования по базе данных отделов и служащих из раздела 24.3. Предположительно результат будет содержать открытые переменные экземпляра ENAME и SALARY. Однако в базе данных нет класса, который имеет такую структуру. Должны ли мы предварительно определить такой класс, прежде чем выполнять запрос? (Обратите внимание на последствия: если бы было необходимо определить такой класс, для класса с п переменными экземпляра потребовалось бы по крайней мере 2 предварительно определенных класса только для поддержки операций выборки!) А если есть какой-либо класс результатов, то какие методы применимы к нему?

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

Возможно, из-за того, что на такие вопросы нелегко ответить, опираясь на чисто объектную структуру, в некоторых объектных системах поддерживаются операции прохождения пути (см. [24.25], [24.47]) вместо самих операций соединения. Для базы данных OPAL из раздела 24.4, например, допустимо следующее выражение пути.

ENROLLMENT . OFFERING . COURSE

Оно означает следующее. Найти уникальный объект класса COURSE, на который ссылается уникальный объект класса OFFERING, на который ссылается данный объект класса ENROLLMENT Реляционный аналог этого выражения обычно включает две операции соединения и одну операцию проекции. Иными словами, в результате прохождения пути предоставляется доступ только по предварительно определенным путям (как в дореляци-онных системах) и только к объектам предварительно определенных классов (опять же, как в дореляционных системах).

Целостность базы данных

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

На самом деле это выражение не является допустимым путем для базы данных, как мы ее определили, поскольку указатели определяют неверное направление. Например, объекты класса OFFERING не ссылаются на объекты класса COURSE: наоборот, объекты класса COURSE ссылаются на них.

прикладных профамм. Рассмотрим, например, следующее Офаничение (или бизнес-правило ) из раздела 8.5: Поставщики со статусом меньше 20 не должны поставлять более 500 деталей . Для того чтобы обеспечить выполнение этого Офаничения, в процедуре ее реализации должны содержаться по крайне мере следующие методы.

Метод для создания объекта поставки

Метод для изменения количества поставляемых деталей

Метод для изменения статуса поставщика

Метод для переназначения некоторой поставки другому поставщику

При внимательном изучении этого примера можно отметить важные особенности.

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

2. Как убедиться в том, что все эти методы содержат весь необходимый для поддержки целостности базы данных код?

3. Как, например, при создании объектного класса для поставок предостеречь пользователя от случайного пренебрежения методом создания поставки и ошибочного непосредственного использования метода NEW (т.е. без проверки целостности)?

4. Как при изменении ограничений целостности найти и внести соответствующие изменения во все методы, в которых они были определены?

5. Как убедиться в корректности кода, с помощью которого приводятся в действие Офаничения целостности?

6. Как выполнить проверку целостности для отложенных (во время выполнения) операций?

7. Как поступить с фанзитными ограничениями?

8. Как узнать обо всех офаничениях, которые заданы для данного объекта или комбинации объектов?

9. Будут ли Офаничения целостности приводиться в действие во время зафузки системы или во время выполнения каких-либо других действий?

10. Можно ли осуществить семантическую оптимизацию (т.е. упростить запросы с помощью Офаничений целостности так, как описано в главе 17)?

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

Реализация связей

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

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

2. Объекты отделов могут иметь набор идентификаторов, ссылающихся на объекты сотрудников. Эта возможность соответствует подходу, использующему иерархию вложения и описанному в разделе 24.3.

3. Кроме того, указанные выше подходы могут комбинироваться, как в следующих определениях.

CLASS ЕМР ...

{ ... DEPT REF ( DEPT ) INVERSE DEPT.EMPS ) ... CLASS DEPT ...

( ... EMPS REF

( SET ( REF ( EMP ) ) ) INVERSE EMP.DEPT ) ... ;

Отметим, что ключевое слово INVERSE относится к двум переменным: ЕМР.DEPT и DEPT.EMPS. Говорят, что эти две переменные являются обратными одна по отношению к другой. Переменная ЕМР. DEPT - это ссылочная переменная, а DEPT. EMPS - переменная набора ссылок. (Если бы обе переменные были переменными набора ссылок, то связь имела бы тип многие ко многим , а не один ко многим .)

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

Кроме того, зачем нужно вводить асимметрию, задавать направленность и два разных имени для одного и того же понятия? Например, рассмотрим два следующих реляционных выражения.

SP.P# WHERE SP.S# = S#(S1) SP.St WCodeHERE SP.Pt = Pt(Pl)

Их объектные аналоги выглядят так.

S.PARTS.Р# WHERE S.S# = S#(S1) P.SUPPS.S# WHERE P.P# = P#(P1)

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