Введение в системы БД (542480), страница 264
Текст из файла (страница 264)
Рассмотрим, например, объекты сотрудников и обьектный класс ЕЯЕТ. В принципе, может существовать любое количество экземпляров класса ЕБЕТ, и каждое полмножество экземпляров класса ЕЯЕТ может содержать ссылку на некоторого конкретного сотрудника. 24.10.Существует шесть возможных иерархий.
Я содержит ( Р содержит ( Л ) ) Я содержит ( Ю содержит ( Р ) ] Р содержит ( а содержит ( Я ) ) Р содержит ( Я содержит ( Л ) ) Ю содержит ( Я содержит ( Р ] ) Л содержит ( Р содержит ( Я ] ] Без какой-либо дополнительной информации невозможно дать ответ на вопрос "Какой из вариантов является лучшим?", но можно почти с полной уверенностью сказать, что все они одинаково плохи. 24.11.Существует по мере двенадцать "очевидных" макетов иерархии контейнеров. Ниже только четыре из них. Б содержит ( Р содержит ( е ) ) Я содержит ( а содержит ( Р ) ) Б содержит ( сначала Р, затем Л ) Я содержит ( сначала Ю, затем Р ) Существует достаточно много других возможных макетов, например обьект ЯР, который прямо указывает на то, какими поставщиками какие детали поставляются, а также включает два внедренных множества проектов; одно для поставщиков, другое — лля деталей.
Можно также составить проект безо всяких иерархий из объектов ЯР, РЮ и ЮЯ. 24.12.Среди основных факторов, оказывающих влияние на производительность, были перечислены следующие: кластерзгзауия, кэширование, заиена указателей н выполнение методов на сервере. Все эти способы обработки данных могут применяться в любой системе для обеспечения разумного уровня независимости от данных, поэтому они характерны не только для объектных систем.
На самом деле, идея использования определения логической базы данных для выбора типа физической кластеризации (используемой в той или иной объектной системе) может рассматриваться как некий фактор, потенциально подрывающий независимость от данных. Заиечанззе. Следует отметить, что другой очень важный фактор, оказывающий влияние на производительность, а именно — аптииизация, обычно не учитывается в объектных системах. 24.13.По мнению автора, декларативная поддержка, если она возможна, всегда лучше процедурной (по многим причинам, а не только для создания ограничений целостности).
Короче говоря, декларативная поддержка означает, что система выполняет некоторую работу вместо пользователя. Вот почему в реляционной системе поддерживаются декларативные запросы, декларативные определения представлений, декларативные ограничения целостности и т.д. 998 Часть И. Объектные и объектно-реляционные базы данных глава 25 Объектно-реляционные базы данных 25.1. Введение Со времени выхода предыдущего издания прошло около пяти лет. За это время несколько изготовителей выпустили "объектно-реляционные" СУБД, известные на рынке как универсазьные серверы. Среди них — 1)пгчегза! РагаЬазе чеггйоп оГ РВ2, 1)п!чегза! Раза Оргюп Гог !пГопп!х Рупаппс Бегчег и Огас!е ь! 1)п!чегза! Бегчег, РагаЬазе Бегчег или Епгегргйе Яегчег (по-видимому, используются все три названия).
Основная идея, положенная в основу всех перечисленных продуктов, заключается в том, что они должны поддерживать как объектные, так и реляционные возможности, иначе говоря, они представляют попытку сближения этих двух технологий. По глубокому убеждению автора, такое сближение должно основываться на реляционной модели (которая, как объяснялось ранее в этой книге, помимо всего прочего, служит основой современной технологии баз данных в целом). Это значит, что следует таким образом изменить реляционную систему, чтобы в нее вошли по крайней мере самые лучшие возможности объектных систем'.
При этом не следует полностью отказываться от реляционных систем, но также не нужно параллельно развивать две разные системы, реляционную и объектную. Это мнение разделяется многими специалистами, включая авторов манифеста "ТЬ!гд Сепегайоп РагаЬазе Яумегп Мап!Гезго" !25.34]. Они в весьма категоричной форме заявляют, что СУБД третьего поколения должны включать СУБД второго поколения, где под СУБД первого поколения подразумеваются дореляционные СУБД, под СУБД второго поколения — ЗО1,- системы и под СУБД третьего поколения — системы будущего.
Некоторые разработчики объектных систем, очевидно, такое мнение не разделяют, подтверждением чему может служить следующее высказывание из !25,4]. "Развитие компьютерных наук сопровождалась появлением многих поколений методов управления данными, начиная с индексных грайзав, сетевых и иерархических СУБД... и заканчивая более савременныии реляционными СУБД.. Теперь мы наблюдаеи палезенив егцв одного поколения СУБД., в которых обеспечивается управление объектами поддерживаются гораздо бтее ложные виды данных.
" Отметиль чта мы, несомненно, поддерживаем эволюционный, а не революционный иуть развитии СУБД. Дзя сравнения приведен цитату из книги группы ОВМС Г24.з'34: 'ТОбьектные СУБД/ — эта результат революционного, а не эволюционною развития". Мы нг верим, чта рынак в целим готов к революционным переменам, и не считаем, чта ани неабхадииы изи должны непременно произойти. Б частности, поэтому работа "Тбв Тыгд МапЦезга" Г3.34' — эта, па сути, именно эволюционный манифест, а не ревалюцианный. Глава 25.
Объекпзно-реаль!ионные базы данных Здесь четко выражена мысль, что, как реляционные системы в свое время заменили иерархические и сетевые, так и объектные системы заменят реляционные. Причина несогласия автора настоящей книги с этим мнением состоит в том, что реляционный подход значительно опыичается [25.131 от объектного, так как он предполагает теоретическую обоснованность принимаемых решений. Напротив, более старые системы, существовавшие до появления первых реляционных систем, строились на совершенно произвольных посылках. Они позволяли решать важные текущие задачи, но не имели сколько-нибудь прочного теоретического обоснования.
К сожалению, приверженцы реляционного подхода (н автор этой книги в том числе) в начальный период оказали себе в некотором роде "медвежью" услугу, восхваляя относительные достоинства как реляционных систем, так и их предшественниц. Эти похвалы были уместны в свое время, но впоследствии благодаря им у многих сложилось впечатление, что реляционные и предшествующие им системы были, по сути. одинаковы. И это ошибочное представление, в свою очередь, привело к процитированному выше выводу, что объекты по сравнению с отношениями — это такой же шаг вперед, какой был при замене иерархий и сетей отношениями.
Так что же можно сказать об объектах? Является ли эта методология также произвольной? На этот вопрос проливает свет следующая цитата из манифеста объектноориентированных СУБД "Тйе ОЬ)есг-Ог(епгег) РагаЬазе Буягегп Мап1геыо" (24.1): "В отношении объектно-ориентированных систем следует применить принцип естественного отбора, описанный Дарвином, т.е. наиболее пригодная объектно-ориентированная модель появится на основе создания некоторого множества экспериментальных прототипов".
Иными словами, предложение заключается в том, что мы должны писать код и строить системы без какой-либо заранее определенной теоретической модели и смотреть, что из этого получится! Исходя из этого, мы принимаем в качестве аксиомы, как, кстати, и большинство основных производителей СУБД, что реляционные системы будут обогащены за счет добавления в них самых лучших возможностей объектной технологии. При этом не следует отвергать реляционную технологию, перечеркивая 30-летний опыт исследований и разработки реляционного подхода. В главе 24 утверждалось (см.
также комментарии к (25.231), что в ориентации на объекты есть только одна хорошая идея, а именно — совершенная поддержка типов данных (или две хорошие идеи, если считать наследование типов отдельно). Тогда возникает вопрос. каким образом можно включить в реляционную модель наллежащую поддержку типов данных. Ответ на этот вопрос, как вы уже, по-видимому, догадались, прост — такая поддержка существует в форме доменов (которые мы все же предпочитаем называть пигпами). Другими словами, для реляционной модели ничего не требуется, чтобы достичь объектной функциональности в реляционной системе, т.е.
ничего, кроме ее реализации, полной и правильной, которую большинство современных систем с треском провалилоз. 2 В частности, пгакие систяиы послужгти слиигком широкому распространению забяуждення, что реллционные систелгы могут поддерживать только ограниченное количество очень простыл типов Вот довольно типичные выдержки излипгературы по обьектныи базагг данные "Реляционные системы баз данны поддерживают очень .иаяый гриксированный набор типов данных" (25.25З, "Реляционная СУБД может поддерживать лишь ..
встроенные типы (в основ- 1ООО Часть 1'1 Объектные и объектно-реляционньзе базы данньп Поэтому мы считаем, что реляционная система, которая в полной мере поддерживала бы домены„могла бы справляться со всеми такими "проблемными" типами данных, которые, как часто утверждают, в объектных системах могут обрабатываться, а в реляционных системах — нет, К таким данным обычно относят хронологические последовательности данных, биологические данные, финансовые данные, данные технического проектирования, данные автоматизации офиса и т,д, Поэтому мы считаем, что истинная "объектно-реляционная" система мо~ла бы быть ни чем иным, как истинной реляционной системой, т.е, системой, которая поддерживает реляционную модель со всеми вытекающими отсюда последствиями.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
