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

0

В  конце  1990-х  годов  некоторые  поставщики  выпустили   программные продукты  объектно-реляционных  СУБД,  известные   также   под  названием универсальных  серверов.  К  примерам  таких   продуктов  относятся  версия Universal Database  СУБД DB2, опция  Universal Data Option сервера Informix Dynamic  Server  и  программный   продукт  Oracle  Universal  Server  (для  этих продуктов  используются  и  другие  названия).  Выпуская все  эти  программные продукты, поставщики  руководствовались тем основным замыслом, что в них должна     обеспечиваться     поддержка     и     объектных,     и     реляционных возможностей;   иными   словами,   рассматриваемые   продукты   представляли собой попытку добиться сближения этих двух технологий.

Но, по глубокому убеждению автора, любое такое сближение должно  быть полностью основано на реляционной модели (которая в конечном итоге является

фундаментом  всей  современной  технологии  баз  данных  в  целом,  как  было описано в части II этой книги).

Итак, мы стремимся к тому, чтобы реляционные системы развивались1  и включали в себя  средства  (или,  по  крайней  мере,  положительные  средства)  объектных  систем (безусловно, мы не допускаем возможности полного отказа от  реляционных систем, а также не хотим того, чтобы нам пришлось иметь дело с двумя отдельными системами, реляционной и объектной, существующими бок о бок). И такое мнение разделяют многие другие специалисты, включая, в частности, авторов "Манифеста систем баз данных третьего поколения" [26.44], которые категорически утверждают, что СУБД третьего поколения должны быть созданы на основе СУБД второго поколения. (Кратко поясним, что подразумевается под поколениями СУБД: название СУБД первого поколения относится к дореляционным системам, таким как IMS, СУБД второго поколения — это системы SQL, а СУБД третьего поколения — те, что придут за ними.) Но очевидно, что такое мнение не разделяют некоторые поставщики объектных систем, а также определенные специалисты в области объектной технологии.  Ниже приведена типичная цитата, подтверждающая эту мысль [26.7].

Компьютерная наука видела много поколений средств управления данными, начиная с индексированных файлов, затем сетевых и иерархических СУБД, …  [а] в последнее время появились реляционные СУБД… Теперь мы становимся свидетелями появления очередного поколения систем баз данных, … [которые] обеспечивают управление объектами, [поддерживая] гораздо более сложные виды данных.

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

Причина, по которой мы не согласны с этой позицией, состоит в том, что реляционные  системы  действительно не  похожи  на  другие  средства  доступа  к  данным [26.17]. Их отличительная особенность состоит в том, что  они созданы не по случаю. Более   старые    дореляционные   системы    создавались    под   влиянием   конкретной потребности;  они  могли   обеспечивать   решение  некоторых  важных  проблем  того

времени, но не были основаны на каком-либо солидном теоретическом фундаменте. К сожалению, сторонники реляционного подхода (в том числе и автор данной книги) в те далекие дни оказали сами себе плохую услугу, когда вступили в дискуссию по поводу относительных достоинств реляционных и дореляционных систем; в то время доводы в пользу  реляционных  были  нужны,   но  имели  непредвиденный  эффект,  поскольку заложили идею, будто  реляционные и дореляционные СУБД по сути представляют

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

А что можно сказать об объектных системах? Созданы ли они по случаю? В этот вопрос позволяет внести ясность следующая цитата из "Манифеста объектно-ориентированных систем баз данных" [20.2], [25.1]: "Что касается спецификации данной системы,

1  Следует отметить, что мы, безусловно, заинтересованы в том, чтобы технология баз данных развивалась эволюционным, а не революционным путем. В отличие от этого, заслуживает внимания следующая цитата из [25.11]: "[Объектные СУБД] являются проявлением  революционного, а не эволюционного направления развития" (курсив автора). Автор не считает,  что весь рынок баз данных в целом готов к революции, а также не думает, что она нужна или должна произойти; именно поэтому написанный с его участием Третий Манифест [3.3] по своему характеру специально подготовлен как эволюционный, а не революционный.

то мы являемся сторонниками дарвиновского подхода — мы надеемся, что после создания целого ряда экспериментальных прототипов [произойдет  естественный отбор и] появится подходящая [объектная] модель". Иными словами, здесь явно прослеживается мысль, что необходимо разрабатывать код и создавать системы без какой-либо заранее определенной модели, а затем смотреть, что из этого получится!

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

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

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

2 В частности, современные системы стали причиной появления широко распространенных ошибочных взглядов, что реляционные системы способны поддерживать лишь ограниченное количество очень простых типов. Весьма типичными являются следующие цитаты: "Реляционные… системы  поддерживают  небольшую, фиксированную коллекцию  типов  данных  (например,  целые  числа,  даты,   строки)"  [26.34],  "реляционные  СУБД  способны поддерживать только свои встроенные типы [по существу, лишь целые числа, строки, значения даты и времени]" [25.31],  "объектно-реляционные  модели  данных  расширяют  реляционную  модель  данных,  предоставляя  более развитую систему типов" [16.21] и т.д.

В качестве примера снова вернемся к некоторым незаконченным темам из главы 25 и рассмотрим качественное реляционное решение задачи с прямоугольниками. (Это решение дано на языке Tutorial D; подготовку его аналога на языке SQL оставляем читателю в качестве упражнения.) Вначале определим тип прямоугольника следующим образом.

TYPE RECTANGLE POSSREP ( X1 RATIONAL, Y1 RATIONAL,

X2 RATIONAL, Y2 RATIONAL ) … ;

Предполагается, что прямоугольники представлены физически с помощью одной из тех структур данных, которые специально предназначены для эффективной поддержки пространственных данных: деревьев квадрантов (квадрадеревьев), R-деревьев и т.д. [26.37].

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

OPERATOR OVERLAP ( R1 RECTANGLE, R2 RECTANGLE ) RETURNS BOOLEAN ;

RETURN ( THE_X1 ( Rl ) < THE_X2 ( R2 ) AND THE_Y1 ( Rl ) < THE_Y2 ( R2 ) AND THE_X2 ( Rl ) > THE_X1 ( R2 ) AND THE_Y2 ( Rl ) > THE_Y1 ( R2 ) ) ; END OPERATOR ;

Этот оператор реализует эффективную сокращенную форму проверки того, перекрываются ли прямоугольники (чтобы вспомнить, что подразумевается под этой сокращенной формой, вернитесь к главе 25) применительно к эффективной структуре хранения данных (в виде R-дерева или какой-то другой).

После этого пользователь может создать базовую переменную отношения с атрибутом типа RECTANGLE следующим образом.

VAR RECTANGLES BASE RELATION { R RECTANGLE, … } KEY { R } ;

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

RECTANGLES

WHERE OVERLAP ( R, RECTANGLE ( 0.0, 0.0, 1.0, 1.0 ) )

В данном решении преодолены все недостатки, обсуждавшиеся в связи с этим запросом в главе 25.

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

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

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

26.5 демонстрируются преимущества подлинной объектно-реляционной системы  (т.е.

системы, в которой нет "следов" ни одного из этих двух заблуждений). В разделе  26.6

описаны соответствующие средства SQL. В разделе 26.7 представлено резюме.

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

По теме:

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