На рис. 24.4 экземпляры объектов представлены в том виде, в котором они реально существуют, т.е. на рисунке отображается компонент структуры данных объектной модели , что позволяет яснее представить саму объектную модель. Обычно в книгах или документации такие диаграммы не используются; вместо этого данные представляются так, как на рис. 24.5, на более высоком уровне абстракции, что, как принято считать, облегчает понимание объектной модели.

DEPT:

DEPT#: D01 DNAME: Mktg

BUDGET: MGR:

$1 ООО ООО

EMP#: E001 ENAME: Smith

SALARY: $50 ООО POSITION:

EMPS:

EMP#: E001 ENAME: Smith

SALARY: POSITION:

$50 ООО

Puc. 24.5. Пример представленш экземпляров объектов DEPT и ЕМР в соответствии с иерархией их вложения

Приведенная на рис. 24.5 схема в большей степени согласуется с интерпретацией на основе иерархии вложения. Однако в ней остается скрытым важный факт: в объектах часто содержатся не собственно другие объекты, а их идентификаторы. Например, согласно рис. 24.5 можно предположить, что объект класса DEPT для отдела с номером D01 содержит два экземпляра объекта класса ЕМР для сотрудника с номером Е001 (при этом, помимо всего прочего, может получиться, что сотрудник с номером Е001 получает две различные зарплаты). Такая ситуация может привести к путанице, поэтому предпочтение следует отдавать схемам, подобным приведенной на рис. 24.4.

В дополнение к этому следует заметить, что реальные объектные определения данных способствуют возникновению запутанных ситуаций, поскольку переменные экземпляра в них обычно определяются не на основе ссылок (как в приведенных выше выражениях с использованием гипотетического синтаксиса), а на основе непосредственного отображения иерархии вложения. Например, переменные экземпляра EMPS в объектном классе DEPT обычно определяются не как REF(SET(REF(EMP))), а в более краткой форме: SET (ЕМР). Несмотря на некоторую громоздкость полной записи, мы все же предпочитаем наш стиль, как более ясный и точный.

Следует отметить, что вся прежняя критика иерархического подхода (например, иерархии вложения, воплощенной в СУБД IMS) в основном относилась именно к иерархиям вложения. Подробное рассмотрение данного вопроса заняло бы слишком много места, поэтому достаточно сказать, что основным аргументом такой критики было отсутствие симметрии. В частности, иерархии не совсем удобны для представления отнощений типа многие ко многим . Например, для рассматриваемого ранее отношения поставщиков и деталей может возникнуть вопрос, содержатся ли объекты-поставщики в объектах-деталях или наоборот. А может, верно и то, и другое? А что можно сказать об отношениях поставщиков, деталей и проектов?

Действительно, подобных вопросов больше, чем можно было бы предположить. С одной стороны, как мы убедились, объекты представляют собой иерархию, и к ним также относятся привычные критические замечания относительно иерархий. А с другой стороны, как явствует из рис. 24.4, такие объекты на самом деле образуют не иерархию, а кортежи с перечисленными ниже компонентами.

1. Неизменяемые подобъекты , т.е. самоидентифицируемые значения, такие как целые числа и денежные суммы.

2. Идентификаторы изменяемых подобъектов , т.е. ссылки или указатели на другие (возможно, совместно используемые) изменяемые объекты.

3. Множества, списки, массивы и т.д. объектов, перечисленных в пп. 1, 2 и в этом пункте.

К этому списку следует также добавить скрытые идентификаторы объектов, идентификаторы объектов, определяющих классы, и т.д. В частности, обратите внимание на п. 3: обычно объектные системы поддерживают несколько коллекций генераторов типов (SET, LIST, ARRAY и др.), но обычно не поддерживают тип RELATION (отношение). Такие генераторы могут сочетаться сколь угодно сложно. Например, массив списков пакетов массивов указателей на целые переменные может составлять при определенных условиях отдельный изменяемый объект. В следующем подразделе мы продолжим обсуждение этого вопроса.

Еще раз об идентификаторе объекта

Чтобы сослаться на объект или идентифицировать его, в современных реляционных СУБД обычно используются ключи, определяемые и управляемые пользователями (далее для краткости будем называть их пользовательскими ключами), хотя, как нам известно из главы 3, в реляционных базах данных указатели наподобие идентификаторов объектов фактически намеренно запрещены. Также хорошо известно, что применение пользовательских ключей сопряжено с некоторыми проблемами. Эти проблемы достаточно подробно рассматриваются в [13.10] и [13.16], где сделан вывод, что реляционные СУБД, по крайней мере в качестве альтернативы, должны поддерживать и ключи, определяемые систе.мой ( суррогатные ). Аргументы в пользу идентификаторов объектов в объектных системах подобны аргументам в пользу суррогатных ключей в реляционных системах. (Однако их не следует приравнивать друг к другу, поскольку суррогатные ключи - это доступные пользователю значения, а идентификаторы объектов - это адреса или указатели, которые, по крайней мере концептуально, от пользователя скрыты. В [24.19] широко обсуждается это различие и другие связанные с ним вопросы.)

Здесь следует отметить некоторые важные моменты.

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

2. Что является идентификатором производного объекта, например соединения некоторого объекта класса ЕМР и соответствующего объекта класса DEPT или проекции объекта класса DEPT по атрибутам BUDGET и MGR? Это очень важный вопрос для производных объектов, рассмотрение которого мы отложим до раздела 24.5.

3. Идентификаторы объектов часто служат предметом критических замечаний, вызванных тем, что объектные системы выглядят, как модифицированный стандарт CODASYL . Стандарт CODASYL использовался для сетевых систем управления базами данных (например, для СУБД IDMS), которые были созданы до появления реляционного подхода. Использование идентификаторов объектов приводит к низкоуровневому стилю программирования (см. раздел 24.4.), что очень напоминает устаревщий стиль программирования согласно стандарту CODASYL. Кроме того, поскольку идентификаторы объектов являются указателями, часто можно услышать, что системы типа CODASYL ближе к объектным системам, чем реляционные, и что реляционные системы основаны на значениях, в то время как объектные системы - на идентичности.

Классы, экземпляры и коллекции

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

Замечание. Вызываемый этим сообщением метод иногда называют конструктором класса.

Ниже приводится пример такого сообщения, записанного с помощью некоторого гипотетического синтаксиса.

Е := ЕМР NEW ( Е001, Smith, MONEY ( 50000 ), POS ) ;

Здесь программная переменная POS содержит идентификатор некоторого объекта класса JOB, а метод NEW вызывается для создания нового экземпляра класса ЕМР, инициализации его переменных экземпляра заданными значениями, возвращения идентификатора нового экземпляра и присвоения его программной переменной Е.

Как уже подчеркивалось в разделе 24.2, в некоторых системах используются оба понятия- и тип , и класс . В этих системах тип означает тип, т.е. содержание или сущность понятия, а класс означает применение этого понятия, т.е. определенную коллекцию, или иногда реализацию данного типа. В других системах данные термины используются иначе... Мы же по-прежнему будем употреблять термин класс для обозначения типа в том смысле, что и в главе 5.