    Часть     VI 

    Объектно-ориентированные системы 

    Объектно-ориентированная технология (object-oriented technology) является 
важной новой областью в сфере управления базами данных. К сожалению, эта 
область все еще остается очень запутанной, и читатель вскоре сможет убедиться 
в этом. Частично это связано с тем, что в отличие от реляционной технологии 
здесь не существует общепринятой, абстрактной и формально определенной 
"объектной модели данных". Скорее, аббревиатура ОО, образованная от 
словосочетания "объектно-ориентированный", просто является удобным ярлыком для 
целой совокупности некоторых взаимосвязанных идей. Среди них есть тесно 
связанные между собой и совсем несвязанные, существенные и несущественные, 
хорошие и не очень, новые (на самом деле новых идей не так уж много) и не 
очень новые, имеющие прямое отношение к базам данных и не имеющие никакого 
отношения к ним и т.д. 
    Еще одним источником путаницы является то, что термин "ОО" (или 
"объектно-ориентированный") используется во многих совершенно разных областях. 
Например, для описания стиля графического интерфейса, стиля программирования, 
некоторых языков профаммирования, некоторого набора методик анализа и 
проектирования и, конечно, в сфере управления базами данных. Причем в одних 
областях применение объектно-ориентированной методики может быть полезным, в 
других — нет. 
    В следующих главах будет представлено вводное описание 
объектно-ориентированного подхода в применении к базам данных, критический 
анализ основных концепций объектно-ориентированных баз данных, а также 
сравнительная характеристика объектно-ориентированной и реляционной технологий 
в области баз данных. 

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


    Глава 22 

    Основные концепции объектно-ориентированной технологии 

    22.1. Введение 

    Общеизвестно, что современные реляционные продукты по ряду причин нельзя 
назвать адекватными. Причем некоторые специалисты (но только не автор этой 
книги) считают, что лежащая в их основе реляционная модель также неадекватна. 
В течение ряда лет объектно-ориентированные языки программирования приобрели 
многие свойства, крайне необходимые в СУБД. Потому совершенно естественно 
попробовать использовать эти черты и свойства в СУБД, а также рассмотреть 
возможность создания объектно-ориентированных СУБД. Именно так и поступают в 
последние годы многие исследователи, разработчики и поставщики программного обеспечения. 
    Таким образом, объектно-ориентированные СУБД берут свое начало от 
объектно-ориентированных языков программирования. Основная идея, объединяющая 
эти две области, состоит в том, что пользователям приходится оперировать не 
понятиями, связанными с аппаратным обеспечением, например биты и байты (или 
даже записи и поля), а понятиями, которые более всего отвечают структуре 
реального мира, а именно объектами и операциями, определенными для этих 
объектов. Например, вместо манипулирования терминами типа "кортеж DEPT" 
(кортеж отношения отделов) с набором соответствующих "кортежей ЕМР" (кортежей 
отношения сотрудников), которые содержат "значения внешних ключей" с 
"указателями" на "значение первичного ключа" в "кортеже DEPT", пользователь 
может непосредственно представить себе объект отдела, который содержит 
соответствующее множество объектов сотрудников. И вместо выполнения операции 
"вставки" "кортежа" в "отношение ЕМР" с соответствующим "значением внешнего 
ключа", который "указывает" на "значени е первичного ключа" некот орого 
"кортежа" в "отношении DEPT", пользователь может непосредственно "нанять" 
сотрудника (как объект) в соответствующем объекте отдела. Иначе говоря, 
фундаментальной идеей объектно-ориентированного подхода является повышение 
уровня абстракции. 
    Безусловно, повышение уровня абстракции — цель чрезвычайно желанная, и 
объектно-ориентированная парадигма была успешно использована для достижения 
этой цели в сфере языков программирования [22.3]. Однако естественно было бы 
спросить, можно ли ту же парадигму использовать также в сфере управления 
базами данных. Действительно, с точки зрения пользователя, инкапсулированные 
объекты, например объекты отдела, которые "знают как" нанять сотрудника, 
сменить менеджера или урезать бюджет, выглядят более привлекательно (по 
крайней мере на первый взгляд), чем отношения, обновления кортежей, внешние 
ключи и т.д. 
    Однако здесь необходимо сделать следующее предостережение. Несмотря на то 
что области языков программирования и управления базами данных имеют много 
общего, в некоторых весьма важных аспектах они все же различаются. В 
частности, по определению прикладная программа предназначена для решения одних 
специфических задач, а база данных — для решения совершенно других задач, 
формулировка которых может быть даже не известна в момент создания базы 
данных. Инкапсулированным объектам при разработке прикладной программы, 
очевидно, не помешала бы некоторая доля "разумности", поскольку это позволило 
бы сократить код

    600	Часть VI. Объектно-ориентированные системы 

управления этими объектами, повысить продуктивность программиста, улучшить 
сопровождение программы и т.д. Для базы данных некоторая доля "разумности" 
может оказаться в одних ситуациях полезной, а в других — нет. Например, это 
может упростить одни задачи, но в то же время усложнить или даже сделать 
невозможным выполнение других задач. 
    (Эта особенность — один из основных аргументов против СУБД типа системы 
IMS, в которых не использовался реляционный подход. Объект отдела, содержащий 
набор объектов сотрудников, концептуально очень похож на иерархию системы IMS, 
в которой "сегменты" отделов (согласно принятой в IMS терминологии) содержат 
"сегменты" сотрудников. Такая иерархия весьма удобна для выполнения запросов 
типа "Найти сотрудников, которые работают в бухгалтерии", но не очень удобна 
для выполнения запросов типа "Найти отделы, в которых принимают на работу 
сотрудников, окончивших бизнес-колледж". Таким образом, многие аргументы, 
высказанные против иерархического подхода в 70-х годах, применимы и теперь в 
контексте объектно-ориентированного подхода.) 
    Несмотря на приведенное выше предупреждение, все еще бытует мнение о том, 
что объектно-ориентированные системы являются перспективным этапом на пути 
развития технологий управления базами данных. В частности, считается, что 
объектно-ориентированные технологии весьма перспективны в следующих новых 
прикладных областях: системы автоматизированного проектирования и управления 
производством, географические информационные системы, наука, медицина, 
хранение и извлечение документов и др. 
    Обратите внимание, что перечислены именно те области, в которых применение 
традиционных реляционных продуктов сопряжено со значительными трудностями. В 
последние годы на эту тему опубликовано огромное количество технических 
статей, а также выпущено несколько коммерческих продуктов. Однако в этой части 
книги основное внимание все же уделяется объектно-ориентированной технологии. 
    В данной главе представлены наиболее важные концепции 
объектно-ориентированного подхода с точки зрения перспективы их применения для 
управления базами данных (в то время как большая часть имеющихся публикаций 
посвящена перспективам применения объектно-ориентированного подхода для 
программирования). Эта глава начинается с введения и примера, в котором 
наглядно демонстрируется неспособность современных реляционных продуктов 
удовлетворительно решать некоторые поставленные задачи по сравнению с 
объектно-ориентированным подходом. Затем предлагается обзор объектов, 
объектных классов, сообщений и методов. После этого некоторые представленные 
идеи излагаются более детально. Далее кратко рассматриваются иерархии классов 
и некоторые вспомогательные вопросы. И наконец, приводится резюме. 
    В заключение следует отметить: вопреки тому, что объектно-ориентированные 
системы были изначально задуманы для создания "сложных" прикладных программ 
типа САПР/АСУП и т.п., в дальнейшем для краткости и простоты изложения будут 
рассматриваться только очень простые примеры. При этом такой упрощенный подход 
нисколько не уменьшает значимости объектно-ориентированной технологии, которая 
в равной мере полезна для решения как простых, так и сложных задач. 

    22.2. Пример использования объектно-ориентированного подхода 

    Рассмотрим простой пример, предложенный Стоунбрейкером (Stonebraker) 
[19.10] и описанный автором этой книги в [22.5]. Этот пример иллюстрирует 
некоторые проблемы, присущие современным реляционным продуктам. База данных, 
которая может рассматриваться как существенно упрощенная версия базы данных 
типа САПР/АСУП, оперирует прямоугольниками, заданными в системе координат со 

    Глава 22, Основные концепции объектно-ориентированной технологии	601 

сторонами, параллельными осям X и Y, т.е. все их стороны либо вертикальные, 
либо горизонтальные. Следовательно, каждый прямоугольник может быть уникальным 
образом представлен с помощью координат (xl,yl) и (х2, у2) соответственно 
нижнего левого и верхнего правого углов (рис. 22.1). На языке SQL это можно 
записать с помощью следующего утверждения: 

    CREATE TABLE RECTANGLES 
    ( RECTID ... , XI . . ., X2 ... , Yl ... , Y2 ... , ... , UNIQUE ( RECTID 
) , UNIQUE ( XI, X2, Yl, Y2 ) } ; 

    Теперь рассмотрим запрос "Найти все прямоугольники, которые покрывают 
какую-нибудь область квадрата (О, 1, О, 1)" (рис. 22.2). 

    у2 
    у1 
    х1 
    х2 
    (0,1) 
    (0,0) 
    (1,1) 
    
    (1,0) 

    Рис. 22.1. Прямоугольник (х1, х2, у1, у2) 

    Рис. 22.2. Квадрат (0, 1,0, 1) 

    На языке SQL это можно записать "очевидным образом" с помощью следующего утверждения: 

    SELECT ... 
    FRCM RECTANGLES 
    WHERE ( XI >= О AND XI <= 1 AND Yl >= 0 AND Yl <= 1 ) 
    
    - нижний левый угол внутри квадрата OR ( Х2 >= О AND X2 <= 1 AND Y2 >= О 
AND Y2 <= 1 ) 
    - верхний правый угол внутри квадрата OR ( XI >= О AND XI <= 1 AND Y2 >= О 
AND Y2 <= 1 ) 
    - верхний левьй угол внутри квадрата OR ( Х2 >= О AND X2 <= 1 AND Yl >= О 
AND Yl <= 1 ) 
    - нижний правый угол внутри квадрата OR ( XI <= О AND X2 >= 1 AND Yl <= О 
AND Y2 >= 1 ) 
    - прямоугольник полностью покрывает квадрат OR ( XI <= О AND X2 >= 1 AND 
Yl >= О AND Yl <= 1 ) 
    - нижний край пересекает квадрат OR ( XI >= О AND XI <= 1 AND Yl <= О AND 
Y2 >= 1 ) 
    - левьй край пересекает квадрат OR ( Х2 >= О AND X2 <= 1 AND Yl <= О AND 
Y2 >= 1 ) 
    - правый край пересекает квадрат OR ( XI <= О AND X2 >= 1 AND Y2 >= О AND 
Y2 <= 1 ) 
    - верхний край пересекает квадрат 
    Возможно, вам понадобится некоторое время, чтобы убедиться в том, что эта 
формулировка действительно корректна. В таком случае полезно было бы 
использовать технику построения диаграмм. 
    Однако нетрудно догадаться, что этот запрос можно сформулировать в более 
простой форме: 

    SELECT ... 
    FRCM RECTANGLES 
    WHERE ( XI <= 1 AND Yl <= 1 

    - нижний левый угол находится ниже и левее точки (1,1) AND    X2 >= О AND 
Y2 >= 0 ) 
    - верхний правый угол находится выше и правее точки (0,0) 

    602 Часть VI. Объектно-ориентированные системы 

    В этом случае также было бы полезно использовать технику построения 
диаграмм для выяснения корректности такой формулировки. 
    Возникает вопрос, может ли системный оптимизатор преобразовать исходную 
длинную форму запроса в соответствующую ему краткую форму? Иначе говоря, 
предположим, что пользователь выражает запрос в "очевидной" (и очевидно 
неэффективной) длинной форме. Может ли система перед исполнением запроса 
сократить его формулировку, сделав ее более эффективной. В [22.5] приведено 
доказательство того, что это почти всегда невозможно, по крайней мере 
оптимизаторы современных коммерческих продуктов такой возможностью не обладают. 
    В любом случае, вопреки тому, что краткая формулировка "более эффективна", 
ее производительность может оказаться неприемлемо низкой в большинстве 
современных реляционных продуктов. 
    Таким образом, можно утверждать, что современные реляционные продукты 
действительно неадекватны в некоторых отношениях. Точнее говоря, проблемы, 
подобные описанной выше, иллюстрируют, что "простые" запросы пользователя: 
    а) достаточно громоздко формулируются; 
    б) выполняются с неприемлемо низкой производительностью. 
    Именно эти соображения послужили основным побудительным мотивом для 
развития объектно-ориентированных систем. 

    Замечание. "Эффективное" решение задачи с прямоугольниками представлено в 
главе 25. 


    22.3. Объекты, методы и сообщения 

    Ниже вводятся некоторые основные термины и описываются концепции 
объектно-ориентированного подхода, а именно понятия объекта, объектного 
класса, метода и сообщения. Там, где это возможно и уместно, эти понятия 
сравниваются с более знакомыми терминами и концепциями. Действительно, в 
несколько грубой форме объектно-ориентированную терминологию можно сравнить с 
терминологией традиционного программирования (рис. 22.3). 

    О&ьектно-ориентированная терминология	Терминология традиционного	программирования 
    О&ьект Объектный класс Метод Сообщение	Переменная  (если о&ьект 
"изменчив")  или значение (если объект "неизменчив") Тип данных Функция Вызов функции 

    Рис. 22.3. Сравнение объектно-ориентированной терминологии с терминологией 
традиционного программирования 


    Предупреждение. Прежде чем переходить к подробному изложению данной темы, 
необходимо предупредить читателя, что впредь не следует ожидать точности 
изложения, присущей реляционным СУБД. Действительно, многие 
объектно-ориентированные концепции (или опубликованные определения таких 
концепций) выражены не очень точно, при их формулировке единства мнений не 
достигается, а разногласия возникают даже по самым основным вопросам (в этом 
можно убедиться, просматривая работы [22.2, 22.10, 22.11, 22.14, 22.16]). 
Например, не существует ни абстрактной формальной "объектной модели данных", 
ни консенсуса в отношении иефор-мальной модели. (Поэтому в книге термин 
"объектно-ориентированная модель" приводится в кавычках.) Точно так же 
существует большая путаница с определением уровней абстракции, особенно при 
определении различий между сомой моделью и ее воплощением. 

    Глава 22, Основные концепции объектно-ориентированной технологии 603 

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

    Обзор основных понятий объектно-ориентированного подхода 

    Вопрос: Что такое объект? Ответ: Объект — это все! 
    Основным принципом объектно-ориентированного подхода является условие 
"объектом может быть все, что угодно". Некоторые объекты являются примитивными 
и неизменчивыми; в качестве примера можно привести числа (например, 3, 42) и 
символьные строки (например, "Mozart", "Экономика и бизнес"). Согласно 
традиционной терминологии такие объекты соответствуют значениям. Другие 
объекты, которые обычно задаются пользователем и являются изменчивыми, 
устроены более сложным образом, например EMP, DEPT, VEHICLE и т.д. Эти более 
сложные объекты соответствуют переменным с произвольной внутренней сложностью, 
т.е. такие объекты могут содержать любое количество типов данных, 
присутствующих в обычных языках программирования, и конструкторов типов — 
чисел, строк, списков, массивов, стеков и т.д. (Однако обратите внимание, что 
термин переменная в объектно-ориентированных системах относится к программной 
переменной, которая используется для идентификатора объекта. Более подробно 
это понятие поясняется ниже.) 

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

    Каждый объект обладает типом (классом, согласно объектно-ориентированной 
терминологии). Отдельные объекты иногда называются экземплярами, чтобы их 
можно было отличить от соответствующего объектного типа или класса. Обратите 
внимание, что термин "тип" здесь используется в смысле, принятом в 
традиционном профаммировании. Это значит, что внутренняя структура любого 
заданного типа состоит из набора операторов или функций (методов, согласно 
объектно-ориентированной терминологии), которые могут применяться для 
экземпляров этого типа (об этом речь идет ниже при обсуждении понятия 
инкапсуляции). Далее предполагается, что тип объекта задается в момент его 
создания, хотя, как отмечается ниже при обсуждении иерархии классов, объект 
может характеризоваться одновременно несколькими типами с динамическим 
увеличением или уменьшением числа типов. 
    В дополнение к этому следует отметить, что некоторые 
объектно-ориентированные системы поддерживают как типы, так и классы, а потому 
в них эти концепции имеют разный смысл. Более подробно такие системы 
рассматриваются ниже в этой главе. 
    Теперь следует пояснить понятие инкапсуляции. Все объекты являются 
инкапсулированными, т.е. представление или внутренняя структура заданного 
объекта, например объекта DEPT, остается скрытой от пользователей. Вместо 
этого пользователю известно только, что данный объект в состоянии выполнять 
некоторые функции ("методы"). Например, к объектам DEPT могут применяться 
методы HIRE_EMP (нанять сотрудника), FIRE_EMP (уволить сотрудника), CUTJBUDGET 
(урезать бюджет) и т.д. Обратите внимание также, что к данным объектам могут 
применяться ТОЛЬКО те операции, которые упомянуты среди этих методов. Доступ к 
внутреннему представлению таких объектов разрешен только коду, с помощью 
которого

    604	Часть VI, Объектно-ориентированные системы 

воплощены эти методы, т.е., употребляя жаргон, можно сказать, что эти (и 
только эти) методы могут "взломать инкапсулированный объект". 
    Преимущество инкапсуляции состоит в том, что она позволяет изменять 
внутреннее представление объектов, не переделывая приложений, в которых 
используются эти объекты. Это, конечно, возможно при условии, что любое такое 
изменение внутреннего представления сопровождается соответствующим изменением 
кода, с помощью которого воплощаются применяемые к этому объекту методы. Иначе 
говоря, инкапсуляция подразумевает независимость данных. 
    В соответствии с идеей инкапсуляции объектам иногда приписывается частная 
память и общедоступный интерфейс. 
    •   Частная память состоит из переменных (или экземпляров переменных), 
которые также называются членами или атрибутами. Их значения представляют 
внутреннее состояние этого объекта. В истинно объектно-ориентированной системе 
экземпляры переменных являются совершенно частными и скрыты от пользователей, 
однако, как было сказано выше, они доступны для методов. Тут следует добавить, 
что многие объектно-ориентированные системы не являются "чистыми" в этом 
смысле, поскольку разрешают пользователям осуществлять доступ к некоторым 
экземплярам переменных. Подробнее эта тема обсуждается ниже. 
    •   Общедоступный интерфейс состоит из определений интерфейса (т.е. 
определений операций ввода и вывода) для методов этого объекта. Код этих 
методов, как и экземпляры переменных, скрыт от пользователя. Замечание. 
Точнее, надо было бы сказать, что общедоступный интерфейс является частью 
объекта, определяющего класс рассматриваемого объекта, а не частью самого 
рассматриваемого объекта. Код методов объекта хранится с объектом, 
определяющим класс, а не с определенным объектом. 
    Обратите внимание, что если для манипулирования объектами заданы только 
заранее определенные методы, то незапланированные запросы невозможны, если 
только для объектов не задана некая специализированная структура. Этот вопрос 
более подробно рассматривается далее в этой книге. 
    Методы вызываются с помощью сообщений, которые, по сути, являются вызовами 
функций (причем они могут быть асинхронными) и в которых синтаксически выделен 
один аргумент (получатель или цель). Например, ниже приводится сообщение, 
записанное с использованием гипотетического синтаксиса, для отдела D о приеме 
на работу сотрудника Е: 

    D HIRE_EMP   (   Е  ) 

    Аргументы D и Е этого сообщения описаны ниже в данной главе. Получателем 
или целью в этом примере является аргумент D. Согласно синтаксису 
традиционного программирования это же сообщение было бы сформулировано иначе: 

    HIREJMP   (  D,   Е  ) 

    Для удобства любая объектно-ориентированная система обычно содержит 
некоторый набор встроенных классов и методов. В частности, в ней почти всегда 
присутствуют числовые (с методами типа "=", "<", "+", "-" и т.д.), символьные 
(с методами типа "=", "<", "||" (конкатенация) и т.д.) и другие классы. 

    Экземпляры переменных 

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

    Глава 22, Основные концепции объектно-ориентированной технологии	505 

    Предположим, что имеется объектный класс линейных сегментов LINESEG. 
Пользователь может представить себе, что отдельный линейный сегмент имеет 
начало (точка START) и конец (точка END), и составить запрос о длине такого 
сегмента. Внутренняя структура сегмента может состоять из данных о средней 
точке (MIDPOINT), длине (LENGTH) и наклоне (SLOPE). Причем переменные 
внутренней структуры будут доступны только для методов объектного класса 
LINESEG. В данном примере START и END — общедоступные экземпляры переменных, а 
MIDPOINT, LENGTH и SLOPE — частные. 
    Невзирая на сказанное выше, концепция общедоступных экземпляров переменных 
не является логически необходимой. Таким образом, даже если пользователю 
разрешено записать выражение такого типа, как fo.START, для ссылки на точку 
START объекта Is класса LINESEG, это выражение будет рассматриваться как 
сокращенная запись вызова метода START, "возвращающего" точку START объекта Is 
класса LINESEG. В соответствии с общепринятой практикой далее будет 
предполагаться (до особо оговариваемых случаев), что объекты действительно 
имеют один или несколько общедоступных экземпляров переменных. 
    Стоит отметить также, что порой некоторые аргументы экземпляров переменных 
требуются для создания объектов специфического класса, которые не будут 
доступны для произвольного использования. Предположим, например, что для 
создания линейного сегмента требуются значения START и END. Отсюда не следует, 
что можно составить запрос, например, для получения сведений обо всех линейных 
сегментах, которые обладают некоторым значением START. Возможность выполнения 
такого запроса зависит от того, был ли определен подходящий для этого метод. 
    Наконец, следует отметить, что некоторые системы поддерживают особый вид 
экземпляров переменных под названием защищенных переменных. Если объекты 
класса С имеют защищенную переменную Р, то переменная Р доступна только для 
методов, определенных для класса С, и для методов, определенных для любого 
подкласса (на любом уровне) класса С. Более подробно подклассы описаны ниже в 
этой главе. 

    Идентификатор объекта 

    Каждый объект обладает уникальным объектным идентификатором ("object ID" — 
OID). Такие примитивные ("неизменчивые") объекты, как целое число 3, являются 
самоидентифщирующимися, т.е. они имеют свои собственные идентификаторы 
объекта. Другие ("изменчивые") объекты имеют в качестве идентификаторов 
концептуальные адреса. Эти адреса можно использовать повсюду в базе данных как 
концептуальные указатели на данные объектов. Один из выводов (и одно из 
отличий объектно-ориентированной модели от реляционной) состоит в том, что 
объекты могут не иметь определенных пользователем потенциальных ключей. 
Обратите внимание, что идентификаторы объектов скрыты от пользователя. Более 
подробно данная тема обсуждается далее в этой книге. 
    Иногда можно встретить утверждения о том, что, с точки зрения 
пользователя, преимущество объектно-ориентированных систем заключается в 
абсолютной идентичности двух разных объектов, т.е. они могут быть дубликатами 
по отношению друг к другу, но отличаться своими идентификаторами. Однако, с 
точки зрения автора этой книги, подобное утверждение обманчиво. Ибо каким же 
образом пользователь действительно сможет внешне различить оба объекта? (Более 
подробно этот вопрос описан в [4.5,4.11].) 

    22.4. Еще раз об объектах и объектных классах 

    Теперь рассмотрим более сложный пример с двумя объектными классами: DEPT 
(отдел) и ЕМР (сотрудник). Предположим, что определенные пользователем классы 
MONEY (деньги) и JOB (работа) уже созданы, а класс CHAR (символьная

    606	Часть VI. Объектно-ориентированные системы 

переменная) является встроенным. Тогда операции, необходимые для создания классов 
DEPT и ЕМР, могут выглядеть следующим образом (с использованием некоторого 
гипотетического синтаксиса): 

    CREATE OBJECT CLASS DEPT 
    PUBLIC  { DEPTtt	CHAR, 
    DNAME	CHAR, 
    BUDGET	MONEY, 
    MGR	REF ( EMP ), 
    EMPS	REF ( SET ( REF ( EMP )))),., 
    METHODS ( HIRE_EMP	( REF ( EMP ) ) ... код .,., 
    FIRE_EMP	( REF ( EMP ) ) ... код ... , ... ) ... ; 
    CREATE OBJECT CLASS EMP 
    PUBLIC  ( EMP#      CHAR, 
    ENAME     CHAR, 
    SALARY    MONEY, 
    POSITION  REF ( JOB ) ) ... METHODS ( ... ) ... ; 

    Необходимо отметить несколько важных особенностей. 
    1.  В этом примере модель отделов и сотрудников построена на основе 
иерархии контейнеров, в которой объекты ЕМР концептуально содержатся внутри 
объектов DEPT. Таким образом, объект класса DEPT содержит общедоступную 
переменную MGR, представляющую менеджера данного отдела (общедоступные 
переменные также называются PUBLIC-переменными, так как они объявляются с 
помощью инструкции PUBLIC), а также переменную EMPS, представляющую 
сотрудников данного отдела. Точнее, объекты класса DEPT содержат общедоступную 
переменную MGR, значение которой является ссылкой (REF) на некоторого 
сотрудника, и другую переменную EMPS, значение которой является ссылкой на 
совокупность ссылок на сотрудников. (Под "ссылкой" здесь подразумевается 
идентификатор объекта, который подробнее описан ниже.) Понятие иерархии 
контейнеров в более широкой форме представлено несколько позже. 
    2.  В интересах данного примера в объекты класса ЕМР, которые ссылаются на 
объекты класса DEPT, не была включена переменная для "внешнего ключа". Это 
решение согласуется с моделью отделы-сотрудники на основе иерархии 
контейнеров. Однако оно также означает, что не существует никакого прямого 
соответствия заданного объекта ЕМР адекватному ему объекту DEPT. Более 
подробно данный вопрос обсуждается далее в этой книге. 
    Обратите внимание, что каждая инструкция CREATE OBJECT CLASS содержит 
определения (подробности кода в ней опущены) методов, которые применяются для 
объектов этого класса. 
    На рис. 22.4 показан пример экземпляров объектов для определенных ранее 
классов DEPT и ЕМР. Рассмотрим объект ЕМР, показанный в верхней части рисунка 
(с идентификатором (OID) еее), который содержит перечисленные ниже компоненты. 
    • Примитивный объект (т.е. значение) "Е001" (символьная строка) в 
общедоступной переменной ЕМР#. 
    • Примитивный объект "Smith" (другая символьная строка) в общедоступной 
переменной ENAME. 
    • Определенный пользователем объект $50 000 (объект класса MONEY) в 
общедоступной переменной SALARY. 
    • Идентификатор определенного пользователем объекта класса JOB в 
общедоступной переменной POSITION. 

    Глава 22, Основные концепции объектно-ориентированной технологии	607 

    Объект ЕМР также включает по крайней мере две частных переменных, одна из 
которых (ОШ) содержит идентификатор еее этого объекта, а другая (CLASS) — 
идентификатор, определяющий класс объекта (class-defining object— CDO) для 
объектов сотрудников (чтобы можно было найти код методов данного объекта). 
    Замечание. Эти два идентификатора физически могут храниться как вместе, 
так и раздельно с их объектом. Например, не обязательно, чтобы значение еее 
хранилось как часть соответствующего объекта ЕМР, необходимо только, чтобы в 
приложении был задан некоторый способ обнаружения объекта ЕМР по данному 
значению еее (т.е. было задано некоторое отображение величины еее на 
физический адрес объекта ЕМР). Однако концептуально пользователь всегда может 
представить себе идентификатор объекта как часть этого объекта. 
    
    
    IOID      ЕМР	*         ENAME	SALARY        POS	TION        CLASS j 
    р— | еее        Е001	Smith	$50 000                 •	•      I 
    объ JO	—— L_r_l ект             CDO для ЕМР В 
    т ————— i — L
    [ою      DE	PT#       DNAME	BUDGET       MG	*    EMPS    CLASS | 
    | ddd        DO	1              Mktg	$1 000 000       •	*             *     
  I 
    ——— L_{__l CDO для DEPT 
    
    
    [™-			CLASS  | 
    •        I 
    
    
    1--т 1	"      I       I идентифин	I агоры (DID)	r i- J _|    CDO для SET 
(REF) (EMP) 
    объектов ЕМР 

    Рис. 22.4. Пример экземпляров объектов DEPT и ЕМР 

    Теперь рассмотрим объект DEPT, расположенный в центре рисунка (с 
идентификатором (OID) ddd), который содержит перечисленные ниже объекты. 
    •   Примитивный объект (т.е. значение) "D01" (символьная строка) в 
общедоступной переменной DEPT#. 
    •   Примитивный объект "Mktg" (другая символьная строка) в общедоступной 
переменной DNAME. 
    •  Определенный пользователем объект $1 000 000 (объект класса MONEY) в 
общедоступной переменной BUDGET. 
    •   Идентификатор еее определенного пользователем объекта класса ЕМР в 
общедоступной переменной MGR (это идентификатор объекта, представляющего 
менеджера (руководителя) отдела). 
    •  Идентификатор sss определенного пользователем объекта класса 
SET(REF(EMP)) в общедоступной переменной EMPS, которая подробнее описана ниже. 
    •  Две частных переменных, содержащих идентификатор (OID) ddd объекта DEPT 
и идентификатор соответствующего объекта, определяющего класс (CDO). 
    Объект с идентификатором sss состоит из набора идентификаторов 
индивидуальных объектов класса ЕМР (а также обычных частных переменных). 
    На рис. 22.4 экземпляры объектов представлены в том виде, в котором они 
реально существуют. Причем эта схема структуры данных объектно-ориентированной 
модели отличается от иллюстрации (рис. 22.5), обычно используемой в книгах или 
документации. (Рис. 22.5 может рассматриваться как более высокий уровень абстракции.) 

    608 Часть VI. Объектно-ориентированные системы 

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

    DEPT: 
    DEPT#:    D01 DNAME:   Mktg 
    BUDGET: MGR:|——— 
    $1 000 000 
    EMP#:    E001 ENAME:  Smith 
    SALARY:   |   $50 OOP POSITION:   I job I 
    EMPS: 
    EMP#:    E001 ENAME:  Smith 
    SALARY:	$50 000 | 
    POSITION: 
    job 
    
    
    Рис, 22.5. Образцы экземпляров объектов DEPT и ЕМР с точки зрения иерархии контейнеров 


    В дополнение к этому следует заметить, что реальные 
объектно-ориентированные определения данных способствуют возникновению 
запутанных ситуаций, поскольку экземпляры переменных в них обычно определяются 
не на основе "ссылок" (как это делалось в приведенных выше выражениях с 
использованием гипотетического синтаксиса), а на основе непосредственного 
отображения иерархии контейнеров. Например, экземпляры переменных EMPS в 
объектном классе DEPT обычно определяются не как REF(SET(REF(EMP))), а в более 
краткой форме SET(EMP). В дальнейшем изложении будет применяться более краткая 
форма записи. 
    Следует отметить, что вся прежняя критика иерархий в целом (например, 
воплощенной в системе IMS иерархии) в основном относилась к иерархиям 
контейнеров. Подробное рассмотрение этого вопроса заняло бы слишком много 
места, поэтому достаточно сказать, что основным аргументом этой критики был 
вопрос отсутствия симметрии. В частности, иерархии не совсем удобны для 
представления отношений типа многие-ко-многим. Например, для рассматриваемого 
ранее отношения поставщиков и деталей может возникнуть вопрос, содержатся ли 
объекты-поставщики в объектах-деталях или наоборот, а может, верно и то и 
другое? А что можно сказать для отношения поставщиков, деталей и проектов? 
    Таким образом, создается впечатление, что, вопреки всеобщему мнению об 
"иерархиях контейнеров", на самом деле эти объекты не образуют иерархии. 
Вместо этого, как показано на рис. 22.4, они являются кортежами с 
перечисленными ниже компонентами. 

    Глава 22, Основные концепции объектно-ориентированной технологии 609 

    1.  Самоидентифицирующиеся значения (например, целые числа). 
    2.  Простые "подчиненные объекты" (например, объекты MONEY), для которых 
не допускается совместное использование. 
    3.  Идентификаторы других, возможно, совместно используемых "подчиненных 
объектов" (об этом ниже в данной главе). 
    4.  Множества, списки и массивы перечисленных объектов. 
    К этому списку следует также добавить скрытые идентификаторы объектов, 
идентификаторы объектов, определяющих классы, и т.д. Обратите внимание, что (в 
истинно объектно-ориентированной системе) такие кортежи являются инкапсулированными. 

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

    Для указания и идентификации некоторых объектов современные реляционные 
СУБД обычно основаны на ключах, определенных и управляемых пользователями 
(далее для краткости они будут называться "пользовательскими ключами"). Однако 
хорошо известно, что применение пользовательских ключей сопряжено с некоторыми 
проблемами. Эти проблемы достаточно подробно рассматриваются в [12.12], где 
сделан вывод. что в реляционных СУБД следует использовать заданные системой 
ключи ("суррогаты"). Аргумент в пользу идентификаторов объектов в 
объектно-ориентированных системах напоминает аргумент в пользу суррогатов в 
реляционных системах. (Однако их не следует приравнивать друг к другу, 
поскольку суррогаты — это доступные пользователю значения, а идентификаторы 
объектов — это адреса или указатели, которые, по крайней мере концептуально, 
скрыты от пользователя.) Здесь следует отметить некоторые важные моменты. 
    1.  Во-первых, необходимо понимать, что (как будет показано в главе 23) 
применение идентификаторов объектов не позволяет полностью исключить 
применение пользовательских ключей. Точнее говоря, пользовательские ключи 
необходимы для общения с внешним миром, хотя внутри базы данных все объекты 
могут ссылаться друг на друга только с помощью идентификаторов объектов. 
    2.  Что является идентификатором производного объекта, например соединения 
ЕМР и DEPT или проекции DEPT по атрибутам BUDGET и MGR? Это очень важный 
вопрос, который более подробно рассматривается в главе 25. 
    3.  Идентификаторы объектов часто служат предметом критических замечаний, 
вызванных тем, что объектно-ориентированные системы выглядят как 
"модифицированный стандарт CODASYL". Стандарт CODASYL использовался для 
сетевых систем управления базами данных (например, для системы IDMS), которые 
были созданы до появления реляционного подхода. Применение идентификаторов 
объектов приводит к низкоуровневому стилю программирования, что очень 
напоминает устаревший стиль программирования согласно стандарту CODASYL. Кроме 
того, поскольку идентификаторы объектов являются указателями, а не вызываемыми 
значениями, часто можно услышать, что системы типа CODASYL ближе к 
объектно-ориентированным системам, чем реляционные. 

    22.6. Классы, экземпляры и семейства 

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

    610	Часть VI. Объектно-ориентированные системы 

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

    Е  := ЕМР NEW   (   'Е0011,   'Smith1,   $50000,   POS  )   ; 

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

    :REATE OBJECT CLASS EMP_COLL_CLASS 
    PUBLIC ( EMP_COLL REF ( SET ( REF ( EMP ) ) ) )  ... ; 
    JU.TiFMPS := EMP_COLL_CLASS NEW ( )  ; 
    MiEMPS ADD  (  E )   ; 

    Пояснения: 
    •  Объект класса EMP_COLL_CLASS содержит одну общедоступную переменную под 
названием EMP_COLL, значением которой является набор указателей 
(идентификаторов) на отдельные объекты класса ЕМР. 
    •  ALLEMPS — это переменная, значением которой является идентификатор 
объекта класса EMP_COLL_CLASS. После выполнения операции присвоения она будет 
содержать идентификатор объекта, значением которого, в свою очередь, будет 
идентификатор пустого множества идентификаторов объектов ЕМР. 
    •  ADD — это метод объектов класса EMP_COLL_CLASS. В данном примере этот 
метод применяется для объекта класса, идентификатор которого содержится в 
переменной ALLEMPS. Этот метод предназначен для добавления идентификатора 
объекта ЕМР, который содержится в переменной Е, к набору идентификаторов 
(изначально пустому). Причем идентификатор этого набора содержится в объекте 
EMP_COLL_CLASS, идентификатор которого находится в переменной ALLEMPS. 
    Рассмотрев приведенные выше выражения, можно заметить, что переменная 
ALLEMPS связана с набором объектов ЕМР, который в данный момент содержит 
только один объект, а именно сотрудника Е001. Помимо прочего, обратите 
внимание на необходимость упомянуть ключ пользователя в последнем предложении! 
    Конечно, в некоторый заданный момент может существовать любое количество 
разных и, возможно, перекрывающихся "наборов сотрудников", например следующих: 

    PROGRAMMERS   := EMP_COLL_CLASS NEW   (   )   ; PROGRAMMERS ADD   (  E  )  
 ; 
    HIGHLY_PAID   := EMPJTOLL _CLASS NEW   (   )   ; BIGHLY_PAID ADD   (  E  ) 
  ;" 

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

    ЖЕАТЕ TABLE ЕМР ( ЕМР# ... , ENAME ... , SALARY . . . , POSITION ... ) ... ; 

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

    Глава 22. Основные концепции объектно-ориентированной технологии	511 

содержанию таблицы. Точно так же приведенное ниже SQL-выражение позволяет 
одновременно создать отдельную строку ЕМР и добавить ее к семейству ЕМР: 

    INSERT INTO ЕМР (...) VALUES ( ... ) ; 

    Таким образом, организация этих действий с помощью языка SQL 
характеризуется такими особенностями: 
    1. Отдельный объект класса ЕМР не может существовать, не являясь частью 
некоторого семейства, фактически какого-то единственного семейства. (В 
литературе семейство объектов также называют коллекцией.) 
    2.  Не существует непосредственного способа создания двух различных 
семейств объектов одного и того же класса ЕМР (подробности описаны ниже). 
    3.  Не существует непосредственного способа для совместного использования 
одного и того же объекта в нескольких семействах объектов ЕМР (подробности 
описаны ниже). 
    Именно с такими требованиями порой можно встретиться, однако они не 
выдерживают серьезной критики. Говоря конкретнее, для достижения равноценного 
эффекта в каждом случае может использоваться реляционный метод на основе 
внешнего ключа. Например, можно определить две базовых таблицы под названием 
PROGRAMMERS (программисты) и HIGHLY_PAID (высоко оплачиваемые), каждая из 
которых состоит из номеров соответствующих сотрудников. Или для достижения 
того же эффекта может быть использован реляционный метод на основе 
представлений. Например, можно определить таблицы PROGRAMMERS и HIGHLY_PAID 
как представления базовой таблицы ЕМР. 

    CREATE VIEW PROGRAMMERS 
    AS SELECT EMP#, ENAME, SALARY, POSITION FROM      EMP WHERE     POSITION = 
'Programmer1 ; 
    CREATE VIEW HIGHLY_PAID 
    AS SELECT EMP#, ENAME, SALARY, POSITION FROM EMP WHERE SALARY > некоторое 
значение, например $75 000 ; 
    
    Теперь один и тот же объект сотрудника можно одновременно разместить в 
двух или более семействах. Более того, участие в семействах, которые являются 
представлениями, управляется автоматически системой, а не вручную программистом. 
    Завершая эту тему, следует упомянуть об одной интересной параллели, 
существующей между объектами объектно-ориентированных систем и явно заданными 
динамическими переменными некоторых языков программирования (например, 
базовыми переменными языка PL/I). Явно заданная динамическая переменная, 
подобно объектно-ориентированному объекту, может иметь любое количество разных 
экземпляров, хранение которых выполняется явно заданными указаниями 
программиста. Более того, эти экземпляры переменных, как и отдельные 
экземпляры объектов, т имеют имен, а потому на них можно ссылаться только с 
помощью указателей. Например, в языке PL/I можно записать такую 
последовательность выражений: 

    DCL XYZ ... BASED ;       /* XYZ является базовой переменной */ DCL P 
POINTER ;	/* Р является указателем */ 
    ALLOCATE XYZ SET ( Р );    /* создание нового экземпляра XYZ, */ 
    /* на который указывает Р */ 
    Р -> XYZ = 3 ;	/* присвоение значения 3 экземпляру XYZ, */ 
    /* на который указывает Р */ 

    Этот записанный на языке PL/I код очень похож на рассмотренный ранее 
объектно-ориентированный код. В частности, объявление базовой переменной 
подобно созданию объектного класса, а операция ALLOCATE — созданию нового 
экземпляра этого класса. Таким образом, основная причина, по которой 
идентификаторы необходимы в "объектно-ориентированной модели" (точно так же, 
как необходимы базовые переменные в языке PL/I) заключается в том, что 
объекты, которые они идентифицируют, не обладают уникальными именами. 

    612	Часть VI. Объектно-ориентированные системы 


    22.7. Иерархии классов 

    Описание концепций объектно-ориентированного подхода было бы неполным без 
рассмотрения иерархий классов (их не следует путать с иерархиями контейнеров). 
Однако объектно-ориентированная концепция "иерархии классов", в сущности, 
является тем же, что и концепция иерархии типов, рассмотренная ранее в этой 
книге. Следовательно, здесь можно ограничиться несколькими краткими 
определениями (большей частью это перефразированные выражения из главы 19) и 
соответствующими примерами. 
    Начнем с того, что объектный класс Y является подклассом X, а объектный 
класс X— суперклассом объектного класса У тогда и только тогда, когда объект 
класса Y является объектом класса X (т.е. "У ISA Л"). Тогда объект класса 
Унаследует экземпляры переменных и методы класса X. В результате пользователь 
может всегда вместо объекта X воспользоваться объектом У. Этот принцип 
называется способностью к замещению и весьма полезен для повторного 
использования кода. 
    Замечание. Наследуемые экземпляры переменных относятся к структурному 
на-сгедованию, а наследуемые методы — к поведенческому наследованию. 
Способность использовать один и тот же метод для разных классов или, скорее, 
применять разные методы с одним и тем же именем для разных классов (при этом 
может потребоваться переопределить метод класса X для использования с классом 
У) называется полиморфизмом. 
    В качестве примера предположим, что класс RECTANGLE (прямоугольник) 
является подклассом класса POLYGON (многоугольник), который, в свою очередь, 
является подклассом класса PLANE_FIGURE (плоская фигура). Тогда объявления 
этих объектных классов будут иметь следующий вид: 

    CREATE OBJECT CLASS PLANE__FIGURE PUBLIC ( AREA  ... ) ... METHODS ( 
OVERLAP ... ) ... ; 
    CREATE OBJECT CLASS POLYGON ISA ( PLANE_FIGURE ) PUBLIC ( VERTICES  ... ) 
... METHODS ( COUNT_VERTICES ... ) ... ; 
    CREATE OBJECT CLASS RECTANGLE ISA ( POLYGON ) 
    PUBLIC ( DIAGONAL_LENGTH  ... ) ... METHODS ( TRANSPOSE ... ) ... ; 

    Экземпляр класса RECTANGLE схематически показан на рис. 22.6. В частности, 
обратите внимание на то, что он содержит переменные классов PLANE_FIGURE и 
POLYGON, а также переменные самого класса RECTANGLE. Обратите внимание и на 
способ воплощения нового экземпляра RECTANGLE, сравнив его с представлением 
тех же данных в реляционной модели (рис. 22.7). 

    CLASS | _      _J --Н TANGLE CDO 
    | OID U- .	AREA и т.д.	VERTICES и т.д.	DIAGONALJ-ENGTH и т.д. 
    \ГГГ 
    
    
    REC 

    Рис. 22.6. Пример экземпляра RECTANGLE 

    Система может быть оснащена некоторыми встроенными иерархиями классов. 
Например, в языке OPAL каждый класс рассматривается в качестве подкласса (на 
некотором уровне) встроенного класса OBJECT. Встроенные подклассы класса 
OBJECT содержат классы BOOLEAN, CHAR, INTEGER, COLLECTION. Класс 

    Глава 22, Основные концепции объектно-ориентированной технологии 613 

    COLLECTION, в свою очередь, имеет подчиненный класс BAG (это то же самое 
множество, за исключением того, что в нем допускаются дубликаты), причем BAG 
является другим названием SET (и т.д.). 
    Наконец, повторим сказанное в главе 19, а именно: в некоторых системах 
поддерживается понятие множественного наследования, согласно которому данный 
класс может быть одновременно подклассом нескольких суперклассов. В такой 
системе "иерархии" классов действительно становятся решетками классов в том 
смысле, что для данного "дочернего" класса могут существовать разные 
"родительские" классы (тем не менее, обычно в этом случае сохраняется 
"иерархическая" терминология). 

    Рис. 22.7. Реляционная версия объектов, представленных на рис. 22.6 
    
    
    OID	AREA и т.д. 
    
    ОЮ	VERTICES и т.д. 
    
    
    OID	DIAGONALJ.ENGTH и т.д. 
    
    
    22.8. Дополнительные замечания 

    Приведем несколько дополнительных замечаний в отношении объектов. 
    1. Определенный объект может динамически приобретать и утрачивать новые 
типы. Например, некоторый сотрудник может стать владельцем акций или перестать 
им быть. Таким образом, в системе поддерживается способность изменять 
расположение каждого объекта внутри иерархии классов, например перемещаться 
"вверх или вниз" внутри данной иерархии. Или, что более сложно, объект может 
быть присоединен (или отсоединен) к произвольной вершине иерархии в любой 
момент времени. 
    2.  Часто предполагается, что объектно-ориентированный метод позволяет 
упростить проектирование и разработку (а также использование) базы данных с 
помощью обеспечения и поддержки высокоуровневых модельных конструкций 
непосредственно в системе. (Что касается реляционных систем, то в них 
содержится дополнительный уровень для отображения объектов реального мира на 
отношения, атрибуты, внешние ключи и т.д.) Однако в таком случае возникает 
вопрос: каким образом можно конкретно спроектировать объектно-ориентированную 
базу данных? Например, что следует выбрать для представления определенной 
совокупности объектов: множество, список или массив? Следует ли представить 
данные в явном виде (с помощью экземпляров переменных) или процедурно (с 
помощью методов)? 
    3.  Наконец, необходимо отметить, что в объектно-ориентированной системе 
объекты (т.е. индивидуальные объекты, а не объектные классы) являются прежде всего: 
    • естественной единицей безопасности и предоставления прав доступа, 
    • естественной единицей восстановления, 
    • естественной единицей параллелизма 
    (за исключением случаев, когда это запрещено требованиями ограничений 
целостности, которые охватывают эти объекты). 

    614 Часть VI. Объектно-ориентированные системы 


    22.9. Резюме 

    В этой главе, посвященной концепциям объектно-ориентированного подхода, на 
примере объектов класса RECTANGLES рассматривались следующие понятия: 
    •  Объекты (т.е. экземпляры объектов), которые в традиционной терминологии 
соответствуют понятиям переменные (если объект является изменчивым) или 
значения (если объект является неизменчивым). 
    •  Объектные классы, которые соответствуют типам данных, 
    •   Методы и сообщения, которые соответствуют функциям и вызовам. 
    В дополнение к этому отмечалось, что в области традиционного 
программирования "изменчивые" объекты соответствуют явно заданным динамическим 
переменным, а потому доступ к ним следует организовывать с помощью указателей 
(например, идентификаторов). 
    Объекты могут быть инкапсулированными, т.е. их внутренняя структура может 
быть скрыта от пользователей объекта и вместо этого пользователям может быть 
известно только то, что объектом можно управлять с помощью специально заданных 
методов. Объекты иногда обладают частной памятью и общедоступным интерфейсом. 
Частную память образуют переменные (или экземпляры переменных), а 
общедоступный интерфейс — определения операций ввода-вывода для методов. В 
немногих примерах истинно объектно-ориентированных систем только методы (или 
внешние методы) не скрыты от пользователя. Методы данного объекта хранятся 
вместе с объектом, определяющим класс этого объекта. 
    Каждый объект обладает уникальным идентификатором, который используется 
другими объектами или переменными для организации ссылок на этот объект. Здесь 
следует подчеркнуть, что идентификатор объекта является указателем, а не 
значением. Наиболее важные вопросы, касающиеся этой темы, подробнее 
рассматриваются далее в этой книге. 
    Несмотря на то что, по мнению автора, эта концепция не совсем точна, в 
данной главе были описаны иерархии контейнеров. Было бы точнее рассматривать 
объекты не как иерархии, а как (инкапсулированные) кортежи, компонентами 
которых могут быть самоидентифицирующиеся значения, простые "подчиненные 
объекты", идентификаторы других (возможно, используемых совместно) подчиненных 
объектов или различные их комбинации. 
    Затем были представлены концепции класса, экземпляра и семейства, имеющие 
совершенно разный смысл для объектно-ориентированных систем. Для демонстрации 
этих концепций были приведены простые примеры выражений, которые затем 
сравнивались с выражениями, используемыми в реляционных системах. 
    Затем кратко (поскольку некоторые детали и подробности уже обсуждались в 
главе 19) рассматривалась концепция иерархии классов. Наконец, в заключение 
было сделано несколько дополнительных замечаний в отношении объектов. 

    Упражнения	^ 

    22.1. Что такое объект? 
    22.2. Что означает термин инкапсуляция! 
    22.3. Объясните, что такое общедоступная, частная или защищенная переменная? 
    22.4. В чем заключается различие между классом и типом! 
    22.5. Дайте определение понятия идентификатор объекта. В чем заключаются 
недостатки и преимущества использования идентификаторов объектов? 
    22.6. Как может быть воплощен идентификатор объекта? 

    Глава 22. Основные концепции объектно-ориентированной технологии	615 

    22.7. Что такое объект, определяющий класс? 
    22.8. Что означает по-вашему понятие "конструктор"? Какие аналогичные 
понятия (если они есть) существуют в традиционных языках программирования? 
    22.9. Объясните и приведите доводы в пользу концепции иерархии контейнеров! 
    22.10. Объясните идею и концептуальное воплощение "совместно используемых 
подчиненных объектов". 
    22.11. Приведите пример множественного наследования. 
    22.12. В этой главе были приведены две формулировки на языке SQL (длинная 
и короткая) для запроса "Найдите все прямоугольники, которые перекрывают 
квадрат единичной площади". Докажите эквивалентность этих двух формулировок. 

    Список литературы 

    Публикации [22.1-22.3, 22.6, 22.11] представляют собой курс по 
объектно-ориентированным методам и связанным с ними вопросам, [22.9, 22.16] — 
сборники научно-исследовательских работ, а [22.7, 22.8, 22.10, 22.12] —учебные пособия. 
    22.1. Booch G. Object Oriented Design, with Applications.— Redwood City, 
Calif Benjamin/Cummings, 1991. 
    22.2. Cattell R.G.G. Object Data Management. — Reading, Mass.: 
Addison-Wesley, 1991. 
    Первое подробное учебное пособие о применении объектно-ориентированного 
метода специально для систем управления базами данных. Цитируемый ниже текст 
дает представление о том, что эта область еще далека от достижения какой-либо 
формы единства мнений: "языкам программирования может понадобиться новый 
комбинированный синтаксис... интеграция [более подробно этот вопрос описан в 
главе 24], репликация, а также новые методы доступа, нуждаются в дальнейшем 
исследовании... требуются новые прикладные программы и средства их 
разработки... необходимо разработать более мощные языки составления 
запросов... необходимо исследовать управление параллелизмом... синхронизация и 
семантика параллелизма на основе объектов также нуждается в более детальном 
исследовании... необходимы также модели представления... новые исследования в 
области управления знаниями следует также интегрировать с инструментами 
управления объектами и данными... это приведет к сложной задаче оптимизации, и 
совсем немного исследовател ей обладают необходимым опытом... необходимо 
изучить объединения нескольких объектно-ориентированных баз данных". 
    22.3. Сох B.J. Object Oriented Programming: An Evolutionary Approach. — 
Reading, Mass.: Addison-Wesley, 1986. 
    Учебное пособие по использованию объектно-ориентированных методов в 
области программирования, некоторое внимание в нем уделяется применению этих 
методов для разработки программного обеспечения. 
    22.4. Dahl O.J., Myhrhaug В, Nygaard К. The SIMULA 67 Common Base 
Language. Pub. S-22. — Oslo, Norway: Norwegian Computing Center, 1970. 
    Язык SIMULA 67 спроектирован специально для создания имитационных 
приложений. Именно на основе таких языков программирования и был создан 
объектно-ориентированный метод. Фактически язык SIMULA 67 был первым 
объектно-ориентированным языком. 
    22.5. Date C.J. An Optimization Problem // C.J. Date and Hugh Darwen. 
Relational Database Writings 1989-1991. — Reading, Mass.: Addison-Wesley, 1992. 

    616	Часть VI. Объектно-ориентированные системы 

    22.6. Goldberg A., Robson D, Smalltalk-80: The Language and its 
Implementation. — Reading, Mass.: Addison-Wesley, 1983. 
    Перечень передовых исследований специалистов из исследовательского центра 
фирмы Xerox в Пало Альто, посвященных проектированию и созданию системы 
Smalltalk-80. Первая часть этой книги содержит подробное описание языка 
программирования Smalltalk-80, на котором основан язык OPAL и система GemStone. 
    22.7. Goodman N. Object Oriented database Systems // InfoDB. — 1989. — 4, 
№ 3, См. комментарий к этой статье в списке литературы главы 25. 
    22.8. Goodman N. The Object Database Debate // InfoDB. — 1990-91. — 5, № 
4. Goodman N. The Object Data Model // Ibid. — 1991. — 6, № 1. Goodman N. The 
Object Data Model in Action // Ibid. — № 2. 
    22.9. Kim  W.,  Lochovsky  F.H.  (eds.)  Object-Oriented Concepts,  
Databases and Applications. — Reading, Mass.: Addison-Wesley, 1989. 
    22.10. King R. My Cat Is Object-Oriented (опубликовано в [22.9]). 
    22.11. Parsaye К., Chignell M., Koshafian S., Wong H. Intelligent 
Databases. — New York, N.Y.: John Wiley & Sons, 1989. 
    22.12. Stein J., Maier D. Concepts in Object-Oriented Data Management // 
Database Programming & Design, — 1988. — 1, № 4. 
    Прекрасный учебный материал по объектно-ориентированным концепциям, 
представленный создателями системы GemStone. 
    22.13. Stonebraker M. Introduction to "New Data Models"; Introduction to 
"Extendibility" // M. Stonebraker. Readings in Database Systems. — San Mateo, 
Calif.: Morgan Kaufmann, 1988. 
    Обе работы содержат интерпретацию объектно-ориентированных концепций, 
выполненную Стоунбрейкером на основе традиционных терминов, а также краткий 
анализ объектно-ориентированного метода и его перспектив. 
    22.14. Tsichritzis D.C., Nierstrasz O.M. Directions in OO Research 
(опубликовано в [22.9]). 
    В этой статье также подтверждается высказанная автором настоящей книги 
мысль об отсутствии единства мнений в области объектно-ориентированных 
подходов: "...разногласия существуют по самым основным понятиям, например: что 
такое объект? ... Однако причин для беспокойства нет, поскольку нестрогие 
определения неизбежны, а порой они даже крайне желательны во время динамичного 
развития научных исследований. Они должны стать и неизбежно станут строгими 
спустя некоторое время". Однако объектно-ориентированные концепции известны 
уже более 25 лет! 
    22.15. Vossen G. Data Models, Database Languages, and Database Management 
Systems. — Reading, Mass.: Addison-Wesley, 1991. 
    22.16. Zdonik S.B., Maier D. Readings in Object-Oriented Database 
Systems.— San Mateo, Calif.: Morgan Kaufmann, 1990. 
    Ответы к некоторым упражнениям 
    22.1. Отчасти проводить обсуждение объектно-ориентированных концепций 
очень трудно, поскольку некоторые наиболее фундаментальные из них не имеют 
ясного и общепринятого определения. Ниже приведено несколько "определений" 
термина объект, которые можно найти в литературе. 

    Глава 22, Основные концепции объектно-ориентированной технологии	617 

    • "Объектами называются многократно используемые программные модули, в 
которых хранятся данные, информация о связях между данными, приложениями и 
процессами, контролирующими данные и связи" (из анонса коммерческого 
программного продукта). 
    • "Объектом называется область частной памяти с общедоступным интерфейсом" [22.12]. 
    • "Объектом называется абстрактная конструкция, определяющая протокол, с 
помощью которого могут общаться пользователи этого объекта" [22.16]. 
    • "Объектом называется программная структура, которая содержит данные и 
программы" [22.7]. 
    • "...все, что угодно, является объектом... объект имеет частную память и 
общедоступный интерфейс" [22.15]. 
    • "...объектно-ориентированная модель основана на семействах объектов. 
Объект содержит значения, хранимые в переменных внутри объектов... эти 
значения сами по себе являются объектами... Объект также содержит фрагменты 
кода, называемые методами, с помощью которых можно управлять этим объектом...". 
    В данной главе было приведено еще одно толкование этого понятия. 
    22.5. Ниже перечисляются преимущества идентификаторов. 
    • В некотором смысле идентификаторы не характеризуются "разумностью' [12.8]. 
    • Все объекты объектно-ориентированной базы данных идентифицируются 
одинаковым образом (в отличие от реляционных баз данных). 
    • Идентификаторы никогда не изменяются до тех пор, пока существуют 
объекты, которые они идентифицируют. 
    • При ссылке на объекты не нужно повторять пользовательские ключи; кроме 
того, нет необходимости использовать правило обновления внешних ключей ON UPDATE. 
    • В некотором смысле идентификаторы не характеризуются излишней сложностью. 
    Некоторые недостатки были кратко перечислены в этой главе (например, 
низкоуровневый стиль программирования с "поиском указателей", возможность 
применения только для "базовых" объектов). 
    22.6. Среди возможных способов воплощения идентификаторов нужно указать следующие: 
    • Физические дисковые адреса (это очень высокопроизводительный способ, но 
он характеризуется слабой независимостью данных). 
    • Логические дисковые адреса (т.е. адреса страниц и смещений; это тоже 
высокопроизводительный способ, причем он характеризуется большей 
независимостью данных). 
    • Искусственные идентификаторы (например, временные метки, номер по 
порядку; для такого способа требуется также дополнительное отображение на 
действительные адреса). 

    618	Часть VI. Объектно-ориентированные системы 

