Глава 24

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

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 которой параллельны сторонам этих прямоугольников, т.е. все их стороны либо вертикальные, либо горизонтальные. Следовательно, каждый прямоугольник может быть уникальным образом представлен с помощью координат (х1,у1) и (х2,у2) нижнего левого и верхнего правого углов соответственно (рис. 24.1). На языке SQL это определение можно записать с помощью следующего оператора.

CREATE TABLE RECTANGLE

( XI ... , Yl ... , X2 ... , Y2 ... , ... ,

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

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