25.1. Введение

Со времени выхода предыдущего издания прошло около пяти лет. За это время не­сколько изготовителей выпустили "объектно-реляционные" СУБД, известные на рынке как универсальные серверы. Среди них— Universal Database version of DB2, Universal Data Option for Informix Dynamic Server и Oracle 8i Universal Server, Database Server или Enterprise Server (по-видимому, используются все три названия). Основная идея, поло­женная в основу всех перечисленных продуктов, заключается в том, что они должны поддерживать как объектные, так и реляционные возможности, иначе говоря, они пред­ставляют попытку сближения этих двух технологий.

По глубокому убеждению автора, такое сближение должно основываться на реля­ционной модели (которая, как объяснялось ранее в этой книге, помимо всего прочего, служит основой современной технологии баз данных в целом). Это значит, что следует таким образом изменить реляционную систему, чтобы в нее вошли по крайней мере самые лучшие возможности объектных систем¹. При этом не следует полностью отка­зываться от реляционных систем, но также не нужно параллельно развивать две раз­ные системы, реляционную и объектную. Это мнение разделяется многими специали­стами, включая авторов манифеста "Third Generation Database System Manifesto" [25.34]. Они в весьма категоричной форме заявляют, что СУБД третьего поколения должны включать СУБД второго поколения, где под СУБД первого поколения подразумеваются дореляционные СУБД, под СУБД второго поколения— SQL-системы и под СУБД третьего поколения — системы будущего. Некоторые разработ­чики объектных систем, очевидно, такое мнение не разделяют, подтверждением чему может служить следующее высказывание из [25.4].

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

Здесь четко выражена мысль, что, как реляционные системы в свое время заменили иерархические и сетевые, так и объектные системы заменят реляционные.

Причина несогласия автора настоящей книги с этим мнением состоит в том, что ре­ляционный подход значительно отличается [25.13] от объектного, так как он предпо­лагает теоретическую обоснованность принимаемых решений. Напротив, более старые системы, существовавшие до появления первых реляционных систем, строились на со­вершенно произвольных посылках. Они позволяли решать важные текущие задачи, но не имели сколько-нибудь прочного теоретического обоснования. К сожалению, при­верженцы реляционного подхода (и автор этой книги в том числе) в начальный период оказали себе в некотором роде "медвежью" услугу, восхваляя относительные достоин­ства как реляционных систем, так и их предшественниц. Эти похвалы были уместны в свое время, но впоследствии благодаря им у многих сложилось впечатление, что реля­ционные и предшествующие им системы были, по сути, одинаковы. И это ошибочное представление, в свою очередь, привело к процитированному выше выводу, что объ­екты по сравнению с отношениями — это такой же шаг вперед, какой был при замене иерархий и сетей отношениями.

Так что же можно сказать об объектах? Является ли эта методология также произ­вольной? На этот вопрос проливает свет следующая цитата из манифеста объектно-ориентированных СУБД "The Object-Oriented Database System Manifesto" [24.1]: "В от­ношении объектно-ориентированных систем следует применить принцип естественного отбора, описанный Дарвином, т.е. наиболее пригодная объектно-ориентированная мо­дель появится на основе создания некоторого множества экспериментальных прототи­пов". Иными словами, предложение заключается в том, что мы должны писать код и строить системы без какой-либо заранее определенной теоретической модели и смотреть, что из этого получится!

Исходя из этого, мы принимаем в качестве аксиомы, как, кстати, и большинство ос­новных производителей СУБД, что реляционные системы будут обогащены за счет до­бавления в них самых лучших возможностей объектной технологии. При этом не следует отвергать реляционную технологию, перечеркивая 30-летний опыт исследований и раз­работки реляционного подхода.

В главе 24 утверждалось (см. также комментарии к [25.23]), что в ориентации на объекты есть только одна хорошая идея, а именно — совершенная поддержка типов данных (или две хорошие идеи, если считать наследование типов отдельно). Тогда возникает вопрос, каким образом можно включить в реляционную модель надлежа­щую поддержку типов данных. Ответ на этот вопрос, как вы уже, по-видимому, дога­дались, прост— такая поддержка существует в форме доменов (которые мы все же предпочитаем называть типами). Другими словами, для реляционной модели ничего не требуется, чтобы достичь объектной функциональности в реляционной системе, т.е. ничего, кроме ее реализации, полной и правильной, которую большинство современ­ных систем с треском провалило².

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

В качестве примера вернемся к незаконченным исследованиям из раздела 24.1 гла­вы 24 и покажем подходящее реляционное решение задачи о прямоугольниках. Прежде всего следует определить тип прямоугольника (назовем его RECT).

TYPE RECT POSSREP ( XI RATIONAL, Yl RATIONAL,