Варианты использования
Упоминавшийся нами во введении Рональд Буре собирается подготовить обзор вариантов использования прирожденных XML -СУБД. С этой целью он подготовил документ [], в котором содержатся его предварительные соображения о вариантах использования и вопросы к разработчикам и пользователям прирожденных XML -СУБД. Нельзя сказать, чтобы все соображения Буре были обоснованными, а некоторые даже производят впечатление не вполне продуманных фантазий. Однако на сегодняшний день этот материал является единственным, исходящим от независимого эксперта. Коротко обсудим некоторые из вариантов использования из списка Буре и соотнесем их с возможностями СУБД Sedna . (В начале каждого из следующих четырех пунктов приводится пересказ текста Буре, за которым следует наш коментарий.)
Вариант 1: Большие документы. Во многих приложениях XML -документы обрабатываются в модели DOM или преобразуются с использованием процессоров XSLT . В обоих случаях, как правило, требуется присутствие в прямо адресуемой памяти всего обрабатываемого элемента. Поскольку для хранения документа, например, в модели DOM требуется примерно в десять раз больше памяти, чем для исходного XML -документа, большие документы обрабатывать оказывается невозможно. Здесь может помочь прирожденная XML -СУБД, в базе данных которой DOM или XSLT будут хранить узлы документа, извлекая их по мере потребности.
Конечно, любая прирожденная (скорее всего, и любая приспособленная к XML ) СУБД справится с поддержкой DOM или XSLT . Но кажется, что в подобных приложениях будет использоваться только незначительная часть функциональных возможностей системы. Нужна ли здесь, например, полная поддержка XQuery , или достаточен XPath ? Требуется ли поддержка транзакционности? И т.д.
Вариант 2: Документно-центрические ( document - centric ) XML -данные. Прирожденные XML -СУБД хорошо подходят для управления документно-центрическими XML -данными, потому что в них сохраняется порядок документа, и они легко справляются с обработкой смешанного контента (чего нет в большинстве СУБД, приспособленных к XML ). При управлении контентом могут оказаться востребованными развитые средства формулировки запросов. Однако Буре приводит ряд доводов в пользу того, что на практике для хранения фрагментов документов в системах управления контентом ( content management system ) оказывается достаточным применение CLOB 'ов SQL -ориентированных баз данных, если в соответствующей СУБД поддерживается полнотекстовый поиск с учетом специфики XML . Более развитые запросы могут быть полезны, но пользователи могут без них и обойтись.
Как кажется нам, при анализе этого варианта использования нельзя говорить как про полезность абстрактных прирожденных XML -СУБД вообще, так и про потребности абстрактных систем управления контентом. Если (как в случае СУБД Sedna ) в системе полностью поддерживается язык XQuery , и его средства запросов и трансформации данных хорошо оптимизированы, а приложению требуется не только формировать, но и визуализировать контент, то этот вариант использования прирожденных XML -СУБД выглядит очень заманчивым (см. также конец этого раздела).
Вариант 3: Управление полуструктурированными данными. В соответствии с Буре, полуструктурированным данными свойственны следующие характеристики: самоописательность – метаданные ассоциируются с элементарными частями данных; возможность представления разными способами одного и того же вида данных; возможность наличия произвольных дополнительных полей; разреженность данных. XML и прирожденные XML -СУБД весьма пригодны для представления полуструктурированных данных и управления ими соответственно: наличие схемы необязательно, разреженные данные представляются эффективно (последнее свойство отсутствует – по Буре! – в реляционных системах.
Здесь снова опасно говорить про пригодность для управления полуструктурированными данными абстрактной прирожденной XML -СУБД. Имеется сильная зависимость от конкретных технических особенностей индивидуальной системы. Например, СУБД Sedna пригодна для этого варианта использования, поскольку в основе структуры хранения XML -документа и обеспечения доступа к его узлам лежит описывающая схема, которая строится вне зависимости от наличия или отсутствия предписывающей схемы. Язык XQuery позволяет формулировать запросы без предварительного знания схемы документа. Все, что потеряется в СУБД Sedna при работе с базой XML -данных без предписывающей схемы, – это возможность выполнения некоторых оптимизационных преобразований запросов (см. выше), полезных, но не обязательных.
Вариант 4: Иерархические данные. Модель данных XML является иерархической, поэтому иерархические данные представляют собой естественный вариант использования прирожденных XML-СУБД. Иерархические данные могут быть однородными или неоднородными. У однородных иерархических данных большая часть узлов ветвления или все узлы имеют один и тот же тип. Однородные иерархические данные могут иметь произвольную глубину. В неоднородных иерархических данных – к которым относится большая часть иерархических данных – узлы потомков имеют типы, отличные от типов своих предков. По определению, неоднородные иерархии имеют фиксированную глубину. Реляционные базы данных могут управлять и однородными, и неоднородными иерархическими данными, хотя в каждом случае могут встретиться проблемы. Большая часть данных в реляционных базах данных используется для построения неоднородных иерархий. Здесь ограничивающим фактором является глубина. Каждая таблица представляет отдельный тип узла, и для построения иерархии требуется соединение данных из нескольких таблиц. Построение глубокой иерархии означает выполнение многих соединений, что, в конце концов, вызовет деградацию производительности до недопустимого уровня. Вот почему в базах данных, приспособленных к работе с XML путем использования объектно-реляционных отображений, возникают проблемы эффективности при работе с глубоко вложенными XML-документами. Однородные иерархии хранятся в одной таблице. Имеется ряд способов запросов однородных иерархических данных, большинству из которых свойственны проблемы
Конечно, прирожденные XML -СУБД обеспечивают возможности работы и с однородными, и с неоднородными иерархическими данными. Конечно, такие возможности существуют и в SQL -ориентированных СУБД. Например, в стандарте SQL :1999 имеются средства формулировки рекурсивных запросов, прямо оптимизированные для эффективной работы с однородными иерархиями неизвестной глубины. По всей видимости, сравнивать эффективность можно только на разных классах запросов. При выполнении запросов над иерархическими данными, в которых соединения требуются только для воссоздания иерархии, прирожденные XML -СУБД могут оказаться эффективнее реляционных. Для тех запросов, в которых потребность в соединениях возникает и в реляционных СУБД, и в прирожденных XML -СУБД, более эффективными могут оказаться реляционные системы (по крайней мере, до тех пор, пока методы выполнения операции соединения в прирожденных XML -СУБД не будут оптимизированы до такого же уровня, как в реляционных системах).
На этом мы прекратим обсуждение вариантов использования из списка Рональда Буре, поскольку оставшиеся пять вариантов являются менее понятными, и кратко рассмотрим еще один вариант, для которого оптимизирована XML -СУБД Sedna . Предлагаемый вариант использования можно назвать “ XML -СУБД как платформа Web -приложений управления контентом”.
Основная идея (которая в менее явной форме затрагивалась в первых разделах статьи) состоит в следующем. В настоящее время во многих прирожденных XML -СУБД поддерживается язык XQuery . Этот язык можно считать не только языком запросов и трансформации XML -данных, но и функциональным языком программирования общего назначения (поскольку он полон по Тьюрингу, и в нем поддерживается возможность определения пользовательских функций – к сожалению, только функций первого порядка). Поэтому на языке XQuery можно реализовать Web -приложение целиком, не только ту часть, которая связана с запросами XML -данных, но и визуализацию путем трансформации XML -данных в форматы XHTML , VoiceML и т.д., а также и логику приложений. В этом случае XML -СУБД являлась бы единственным движущим механизмом всего Web -приложения.
Некоторым разработчикам предложение использовать XQuery (с применением XML для представления структур данных) для выражения логики приложения может показаться неожиданным и даже пугающим, но эта возможность вполне реальна и обеспечивает ряд преимуществ.
Во-первых, этот подход позволяет избежать потребности в решении проблемы потери соответствия ( impedance mismatch ), которая возникает при одновременном использовании ряда языков, основанных на разных моделях и парадигмах. Например, если разработчик использует Java (для выражения логики приложения) и XSLT (для визуализации), он вынужден заботиться об отображении между объектно-ориентированной моделью данных и моделью данных XML . Обеспечение такого отображения не только чревато техническими сложностями, но может также привести и к общему падению эффективности.
Во-вторых, становится возможной статическая проверка наличия ошибок. Например, если динамическая XHTML -страница генерируется с использованием некоторого (обычно, скриптового) языка, не основанного на модели данных XML (например, Java / JSP ), то ошибки в динамической части страницы могут быть обнаружены только во время выполнения. Если же динамическая XHTML -страница реализуется с использованием XQuery , то ее динамическая часть может быть проверена на предмет наличия ошибок путем использования механизма статического вывода типов XQuery.
Наконец, если в XML -СУБД наряду со средствами управления собственными базами данных поддерживаются средства интеграции данных, то тот же язык XQuery может быть использован для запросов внешних источников данных (например, реляционных баз данных) в терминах XML . В этом случае XQuery позволяет избежать еще одной потери соответствия – между моделью языка, на котором выражается логика приложения, и моделью данных внешнего источника данных.
Из описания особенностей СУБД Sedna , приведенного в первых разделах статьи, легко увидеть, что система действительно оптимизируется в расчете на этот вариант использования. Чтобы обеспечить эффективное выполнение запросов и операций обновления наряду с эффективным выполнением “программ” XQuery , в системе хранения СУБД Sedna поддерживаются прямые указатели в 64-разрядном адресном пространстве базы данных, эффективно отображаемые в указатели 32-разрядной виртуальной памяти. При выполнении операций XQuery исполнитель динамически изменяет режим исполнения с ленивого на строгий, и наоборот в зависимости от природы исполняемой операции (связана ли эта операция с интенсивным потреблением данных, или же в основном имеет вычислительный характер).
Для обеспечения эффективного использования XQuery в качестве языка трансформаций введена операция отложенного конструирования XML -элемента. Использование этой операции позволяет при выполнении большинства трансформационных запросов XQuery избежать дорогостоящего глубокого копирования XML -элементов.
Наконец, еще одна возможность, не упоминавшаяся ранее в этой статье. В предыдущем проекте группы MODIS была реализована система виртуальной интеграции BizQuery [], обеспечивающая доступ через глобальную схему к совокупности распределенных внешних источников данных. В планах группы MODIS числится включение возможностей BizQuery в СУБД Sedna.
