Главная » SQL, Базы данных » Объектные базы данных

0

В период с конца 1980-х годов до середины 1990-х годов системы объектноориентированных баз данных (или сокращенно — объектные системы) вызывали значительный интерес. В тот период некоторые  исследователи рассматривали объектные системы как серьезного  конкурента реляционных систем (или, во всяком  случае,  конкурента   систем  SQL).  В  наши  дни  с  такой  позицией соглашаются    лишь     немногие;    большинство    специалистов    в    области информационных    технологий   теперь   считают,   что   объектные   системы, возможно,  имеют определенную область применения, но эта область является довольно   ограниченной   [25.33].   Тем   не   менее,   такие   системы   все   еще заслуживают  внимательного  изучения.  Поэтому  в  данной  главе   подробно рассматриваются объектные системы; здесь представлены и описаны основные объектные понятия; там, где это уместно, эти  понятия подвергнуты анализу и критике,  а  также  приведены  некоторые   выводы  относительно  перспектив применения этих понятий в системах баз данных в будущем.

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

объектно-ориентированных языках программирования, например в C++ и Smalltalk. И, вполне естественно, возникла идея реализовать эти возможности в системах баз данных, что и было сделано многими исследователями и  несколькими производителями СУБД.

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

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

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

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

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

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

В частности, ниже перечислены наиболее важные различия.

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

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

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

могут оказаться полезными, а в других — нет. Они позволяют упростить решение одних задач, но в то же время усложнить или даже сделать невозможным решение других задач.

Кстати, точно такой же довод может быть приведен в отношении  дореляционных

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

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

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

■     системы автоматизированного проектирования и автоматизированного управле ния производством (САПР/АСУП);

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

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

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

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

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

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

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

вариант решения этих задач. Затем, в разделе 25.2, предлагается обзор основных понятий, таких как объекты, классы, сообщения и методы. В разделе 25.3 определенное внимание уделено описанию некоторых особенностей этих понятий, а также подробно обсуждается их содержание. В разделе 25.4 представлен всеобъемлющий пример  применения объектной базы данных, а в разделе 25.5 обсуждаются некоторые дополнительные вопросы. Наконец, в разделе 25.6 приведено резюме.

В заключение необходимо сделать приведенные ниже замечания.

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

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

В данном разделе рассматривается простой пример, первоначально  предложенный Стоунбрейкером (Stonebraker), доработанный автором этой книги и описанный в [25.15]. Данный пример иллюстрирует некоторые проблемы, присущие классическим продуктам SQL. База данных, которая может рассматриваться как существенно упрощенная версия базы данных САПР/АСУП, содержит сведения о прямоугольниках, заданных в такой системе координат, оси Х и Y которой параллельны сторонам этих прямоугольников, т.е. все стороны прямоугольников являются либо вертикальными, либо горизонтальными. Следовательно, каждый прямоугольник может быть уникальным образом представлен с помощью  координат  (x1,y1)  и  (х2,у2)  нижнего  левого  и  верхнего   правого  углов, соответственно (рис. 25.1). На языке SQL это определение можно  записать с помощью следующего оператора.

CREATE TABLE RECTANGLES

( X1 . . . , Y1 . . . , Х2 . . . , Y2 . .

.,…, PRIMARY KEY ( X1, Y1, X2, Y2

) ) ;

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

Рис. 25.1. Прямоугольник с координатами (xl, yl,x2, у2)

Рис. 25.2. Единичный квадрате координатами (0, 0,1,1)

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

SELECT …

FROM RECTANGLES

WHERE ( X1 >= 0 AND X1 <= 1 AND Yl >= 0 AND Yl <= 1 )

/* нижний левый угол внутри единичного квадрата */ OR ( Х2 >= 0 AND X2 <= 1 AND Y2 >= О AND Y2 <= 1 )

/* верхний правый угол внутри единичного квадрата */ OR ( X1 >= 0 AND X1 <= 1 AND Y2 >= О AND Y2 <= 1 )

/* верхний левый угол внутри единичного квадрата */

OR ( Х2 >= О AND X2 <= 1 AND Yl >= 0 AND Yl <= 1 )

/* нижний правый угол внутри единичного квадрата */ OR ( X1 <= О AND Х2 >= 1 AND Yl <= О AND Y2 >= 1 )

/* прямоугольник полностью включает единичный квадрат

*/ OR ( X1 <= О AND X2 >= 1 AND Yl >= 0 AND Yl <= 1 )

/* нижний край пересекает единичный квадрат */

OR ( X1 >= О AND X1 <= 1 AND Yl <= 0 AND Y2 >= 1 )

/* левый край пересекает единичный квадрат */

OR ( Х2 >= О AND X2 <= 1 AND Yl <= 0 AND Y2 >= 1 )

/* правый край пересекает единичный квадрат */

OR ( X1 <= О AND X2 >= 1 AND Y2 >= 0 AND Y2 <= 1 ) ;

/* верхний край пересекает единичный квадрат */

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

SELECT …

FROM RECTANGLES

WHERE ( X1 <= 1 AND Yl <= 1

/* нижний левый угол находится ниже и левее точки

(1,1) */ AND X2 >= О AND Y2 >= 0 ) ;

/* верхний правый угол находится выше и правее

точки (0.0) */

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

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

сделав ее более эффективной? В [25.15] приведено доказательство того, что это почти всегда исключено, по крайней мере, оптимизаторы современных коммерческих продуктов такой возможностью не обладают.

В любом случае, несмотря на то, что краткая формулировка "более эффективна", ее производительность может оказаться неприемлемо низкой в большинстве современных

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

только в том, что отсутствует достаточно хорошая оптимизация.

Таким образом, можно утверждать, что классические продукты SQL  действительно несовершенны в некоторых отношениях. Точнее говоря, проблемы, подобные описанной

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

для развития объектных систем.

Примечание. В следующей главе (раздел 26.1) будет приведено "эффективное" решение задачи о прямоугольниках1.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии