Часть VI

Объектные и объектно-реляционные базы данных

Объектная технология является важной областью в сфере разработки программного обеспечения в целом. Поэтому возникает естественный вопрос, важна ли эта технология, в частности, в сфере управления базами данных, и если важна, то какова ее значимость для этой сферы. Единого мнения, однако, по этому вопросу пока нет! Одни авторитетные источники считают, что в недалеком будущем объектные системы баз данных получат признание во всем мире и полностью заменят реляционные системы. Другие же полага­ют, что объектные системы подходят лишь для определенного, очень ограниченного круга задач и никогда не займут сколько-нибудь значительную часть рынка баз данных. Совсем недавно начали появляться системы, поддерживающие "третий путь": они объе­диняют объектную и реляционную технологии и пытаются везде поспеть. В двух главах этой заключительной части книги приведенный выше вопрос рассматривается достаточ­но глубоко: в главе 24 обсуждаются чисто объектные системы, а в главе 25 — более но­вые объектно-реляционные системы.

Глава

_{Объектные базы данных}

24.1. Введение

Большой интерес представляют результаты исследований, полученные за последнее деся­тилетие в области объектно-ориентированных систем баз данных (или сокращенно — объ­ектных систем). Некоторые специалисты рассматривают объектные системы как серьезного конкурента реляционных систем (или, во всяком случае, конкурента SQL-систем), и если не в полном объеме, то по крайней мере для определенных приложений. В этой главе подробно рассматриваются объектные системы. Сначала мы познакомимся с основными объектными концепциями, а затем основательно их проанализируем и предоставим некоторые выводы от­носительно перспектив включения этих концепций в системы баз данных в будущем.

Почему же возник такой большой интерес к объектным системам? Общеизвестно, что уже ставшие классическими SQL-системы несовершенны во многих отношениях. И не­которые специалисты — но не автор этой книги! — считают, что и теория (т.е. реляци­онная модель), которая служит основой для таких систем, также не отвечает современ­ным требованиям. Как бы то ни было, некоторые из новых возможностей, которые счи­таются необходимыми в современных СУБД, уже много лет существуют в объектно-ориентированных языках программирования, например в С++ и Smalltalk. И, вполне ес­тественно, возникла идея внедрить эти возможности в системы баз данных, что и было сделано многими исследователями и несколькими производителями СУБД.

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

Безусловно, повышение уровня абстракции — цель чрезвычайно привлекательная, и объектные понятия успешно использовались для ее достижения в сфере языков про­граммирования [24.15]. Поэтому возникает естественный вопрос, можно ли те же поня-

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

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

• Прикладная программа по определению предназначена для решения некоторых конкретных задач.

• База данных (опять же, по определению) предназначена для решения множества различных задач, формулировка которых может быть даже неизвестна в момент создания базы данных.

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

(Кстати, точно такой же аргумент может быть использован против дореляционных СУБД наподобие системы IMS. Объект отдела, содержащий набор объектов сотрудни­ков, концептуально очень похож на иерархию системы IMS, в которой "родительские сегменты" отделов содержали подчиненные "дочерние сегменты" сотрудников. Такая иерархия весьма удобна для выполнения запросов наподобие "Найти сотрудников, кото­рые работают в бухгалтерии", но не очень удобна для выполнения запросов типа "Найти отделы, в которых принимают на работу сотрудников, окончивших бизнес-колледж". Та­ким образом, многие аргументы, высказанные против иерархического подхода в 70-х го­дах, применимы и теперь в контексте объектно-ориентированного подхода.)

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

• системы автоматизированного проектирования и автоматизированного управле­ния производством;

• системы комплексного автоматизированного управления технологическими про­цессами;

• системы автоматизированной разработки программного обеспечения;

• геоинформационные системы;

• наука и медицина;

• системы хранения и поиска документов и т.д.

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

В данной главе основное внимание уделяется объектной технологии в целом. Поэтому необходимо представить наиболее важные концепции объектного подхо­да и, в частности, рассмотреть эти концепции с точки зрения перспективы при­менения для управления базами данных (заметим, что большая часть имею­щихся публикаций посвящена перспективам применения объектного подхода для программирования). Данная глава имеет определенную структуру. В следующем подразделе представлен специальный пример, наглядно демонстрирующий неспо­собность современных реляционных продуктов удовлетворительно решать неко­торые задачи, в результате чего у объектной технологии появляется шанс предос­тавить лучший вариант решения этой задачи. Затем, в разделе 24.2, предлагается обзор объектов, классов, сообщений и методов, а в разделе 24.3 уделяется внима­ние некоторым особенностям этих понятий, а также подробно обсуждается их со­держание. В разделе 24.4 представлен достаточно простой пример. В разделе 24.5 обсуждаются некоторые дополнительные вопросы. И наконец, в разделе 24.6 под­водятся итоги обсуждения темы главы.

В заключение сделаем следующее замечание. Вопреки тому, что объектные системы изначально предназначались для создания "сложных" приложений, таких как САПР/АСУТП, в дальнейшем для краткости и простоты изложения будут рассматри­ваться только очень простые примеры (отделы и сотрудники и т.п.). При этом такой уп­рощенный подход нисколько не уменьшает значимости объектной технологии; во всяком случае, если объектные базы данных работают хорошо, они должны легко справляться и с "простыми" задачами.

Специальный пример

Рассмотрим простой пример, предложенный Стоунбрейкером (Stonebraker) и описан­ный автором этой книги в [24.17]. Данный пример иллюстрирует некоторые проблемы, присущие современным SQL-продуктам. База данных, которая может рассматриваться как существенно упрощенная версия базы данных САПР/АСУТП, содержит сведения о прямоугольниках, заданных в такой системе координат, оси X и Y которой параллельны сторонам этих прямоугольников, т.е. все их стороны либо вертикальные, либо горизон­тальные. Следовательно, каждый прямоугольник может быть уникальным образом пред­ставлен с помощью координат (xl,yl) и (х2,у2) нижнего левого и верхнего правого уг­лов соответственно (рис. 24.1). На языке SQL это определение можно записать с помо­щью следующего оператора.

CREATE TABLE RECTANGLE

( XI ... , Yl ... , Х2 ... , Y2 ....... ,

UNIQUE ( XI, Yl, X2, Y2 ) ) ;

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

У2
yi
	х1 х2

(0,1)

(0,0)

(1.1)

(1,0)

Рис. 24.1. Прямоугольник с координатами Рис. 24.2. Квадрат с координатами (0, 0, (xl, х2. yl, у2) 1, 1)

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

Х2 >= 1 AND Yl >= О AND Yl <= нижний край пересекает квадрат XI <= 1 AND Yl <= О AND Y2 >=

XI <= 1 AND Yl >= 0 AND Yl <= 1 ) нижний левый угол внутри квадрата Х2 <= 1 AND Y2 >= О AND Y2 <= 1 ) верхний правый угол внутри квадрата XI <= 1 AND Y2 >= О AND Y2 <= 1 ) верхний левый угол внутри квадрата Х2 <= 1 AND Yl >= О AND Yl <= 1 ) нижний правый угол внутри квадрата Х2 >= 1 AND Yl <= О AND Y2 >= 1 )

1 )

Х2 <= 1 AND Yl <= О AND Y2 >= 1 ) фавый край пересекает квадрат Х2 >= 1 AND Y2 >= О AND Y2 <= 1 ) ; -- верхний край пересекает квадрат

(Упражнение. Убедитесь в том, что эта формулировка действительно корректна.) Однако нетрудно догадаться, что данный запрос можно сформулировать и в более простой форме.

SELECT ...

FROM RECTANGLES

WHERE ( XI <= 1 AND Yl <= 1

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

— верхний правый угол находится выше и правее точки (0,0)

(В упр. 24.3 в конце главы предлагается убедиться, что эта формулировка также корректна.)

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

В любом случае, несмотря на то что краткая формулировка "более эффективна", ее производительность может оказаться неприемлемо низкой в большинстве современных реляционных продуктов, в которых используются обычные структуры памяти, например индексы в виде В-деревьев. (В среднем, система будет проверять 50% элементов индекса для каждой из координат Xl, Х2, Y1 и Y2.)

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

Замечание. В главе 25 (раздел 25.1) будет приведено "эффективное" решение задачи о прямоугольниках.