отсутствие значения). Частично проблемы могут возникнуть потому, что невозможно на основании одного только определения данных указать те объекты, которые содержат ссылку на объект X, или хотя бы даже сказать, сколько их существует. Рассмотрим, например, объекты сотрудников и объектный класс ESET. В принщ1пе, может существовать любое количество экземпляров класса ESET, и каждое подмножество экземпляров класса ESET может содержать ссылку на некоторого конкретного сотрудника. 24.10.Существует шесть возможных иерархий.

S содержит ( Р содержит ( J ]

S содержит ( J содержит ( Р ]

Р содержит ( J содержит ( S ]

Р содержит ( S содержит ( J ]

J содержит ( S содержит ( Р ]

J содержит ( Р содержит ( S ]

Без какой-либо дополнительной информации невозможно дать ответ на вопрос Какой из вариантов является лучшим? , но можно почти с полной уверенностью сказать, что все они одинаково плохи.

24.11. Су шествует по мере двенадцать очевидных макетов иерархии контейнеров. Ниже только четыре из них.

S содержит ( Р содержит ( J ) ) S содержит ( J содержит ( Р ) ) S содержит ( сначала Р, затем J ) S содержит ( сначала J, затем Р )

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

Можно также составить проект безо всяких иерархий из объектов SP, PJ и JS.

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

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

Глава

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

25.1. Введение

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

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

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

Отметим, что мы, несомненно, поддерживаем эволюционный, а не революционный путь развития СУБД. Для сравнения приведем цитату из книги группы ODMG [24.13]: [Объектные СУБД] - это результат революционного, а не эволюционного развития . Мы не верим, что рынок в цело.м готов к революционным переменам, и не считаем, что они необходимы или должны непременно произойти. В частности, поэтому работа The Third Manifesto [3.3] - это, по сути, именно эволюционный манифест, а не революционный.

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

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

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

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

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

В частности, такие системы послужили слишком широко.му распространению заблуждения, что реляционные системы могут поддер.живать только ограниченное ко.пичество очень простых типов. Вот довольно типичные выдержки из литературы по обьектньш базам данных: Реляционные системы баз данных поддерживают очень малый фиксированный набор типов данных [25.25], Реляционная СУБД может поддерживать лишь... встроенные типы [в основ-