Автор: Кимбро Стэйкин, 31 октября 2001, Оригинал статьи

Перевод: А.Устюжанин, Л.Птицына, 6 марта 2002, www.raleigh.ru

Практика обработки и хранения XML потребовала создания новых типов программных инструментальных средств, одним из которых является "естественные XML-базы данных" (в дальнейшем мы будем пользоваться сокращением NXD, Native XML Database). В данной статье описываются основные принципы таких баз данных.

Что такое NXD?

Термин "естественная база данных" (NXD) может ввести в некоторое заблуждение. Дело в том, что многие так называемые естественные базы данных по существу не являются самостоятельными базами данных в привычном смысле этого слова. Они не хранят XML в чистом виде (например, как текст). Чтобы лучше понять, что же это такое в действительности, давайте рассмотрим определение NXD, предложенное Инициативой XML:DB, членом которой является автор.

Естественная XML-база данных...

• Определяет (логическую) модель XML-документа -- в отличие от данных, содержащихся в этом самом документе -- и сохраняет и извлекает документы в соответствии с этой моделью. Как минимум, модель должна включать элементы, атрибуты, блоки PCDATA, а также порядок документа. Примером таких моделей может служить модель данных XPath, XML Infoset, а также модели, реализованные с помощью DOM или событий SAX 1.0.
• Документ XML выступает в качестве основной единицы (логического) хранения, также как строка является основной единицей (логического) хранения в теории реляционных баз данных.
• Не обязана иметь в основе какую-либо конкретную физическую модель хранения. Например, она может быть построена на основе реляционной, иерархической или объектно-ориентированной БД или использовать закрытый формат хранения, такой как проиндексированные и сжатые файлы.

Если попробовать переформулировать это определение покороче, то мы получим следующие три базовых утверждения.

1. База данных предназначена для хранения XML-данных, а также всех компонент XML-модели.
2. Документы на входе и документы на выходе.
3. NXD может не быть реальной самостоятельной базой данных.

Как должно быть понятно из этого определения, NXD в действительности не представляют собой новую низкоуровневую модель баз данных, и они не призваны заменить уже существующие базы данных. Это просто инструментарий, цель которого - помочь разработчику, обеспечивая надежное хранение и манипулирование XML-документами.

Особенности NXD

Хотя не все NXD полностью идентичны, у них есть характерные черты, которые мы и рассмотрим ниже. Однако здесь мы не будем обсуждать конкретные продукты; если вам будет интересно составить свое мнение о них, вы можете обратиться к полному списку реализаций XML-баз данных, созданному Рональдом Буреттом (Ronald Bourret). Большинство софтверных компаний предлагают сейчас продукты первого поколения, и только немногие, более мощные компании предлагают решения следующего поколения. Модель NXD только развивается и будет продолжать развиваться еще в течение нескольких лет. Таким образом между существующими реализациями есть довольно ощутимые отличия, поэтому утверждения, сформулированные в следующих разделах, применимы лишь для большинства таких реализаций, но не для всех.

Хранение XML

NXD хранит XML-документы, как единое целое, и создаст модель, подобную XML или одной из XML-технологий, например Infoset или DOM. Эта модель включает произвольные уровни вложенности и сложности, а также полную поддержку смешанных и слабоструктурированных данных. Эта модель автоматически отображается с помощью NXD в базовый механизм хранения. Это отображение обеспечит поддержку заданную XML-модель данных. Сохранив данные, вам придется продолжать использовать инструментальные средства NXD, если, конечно, вы хотите увидеть более удобное представление данных. Например, если вы используете NXD поверх реляционной базы данных, доступ к данным напрямую с помощью SQL может показаться не таким удобным, как вы могли ожидать. Причина очевидна -- данные, которые вы увидите, скорее являются моделью XML-документа (например, элементы и атрибуты), чем бизнес-сущностями, представляющими эти данные. Модель бизнес-сущностей существует в рамках XML-документов, но не в рамках физической системы хранения данных. Чтобы работать с данными, с ними следует работать, как с XML.

Если разработчику удобно работать с XML-инструментарием, таким как DOM, SAX, XPath и XSLT, то возможно они подойдут и для работы с NXD. База данных избавляет от всех ненужных деталей хранения XML и оставляет разработчику при построении приложений свободу в использовании любых XML-технологий.

Коллекции

NXD управляет коллекциями документов, позволяя вам запрашивать и манипулировать этими документами как множеством. Это сильно похоже на реляционную концепцию таблицы. Отличие NXD от концепции таблиц в том, что не все естественные XML-базы данных требуют, чтобы с коллекцией была ассоциирована схема. Это означает, что вы можете хранить любой XML-документ в коллекции, независимой от схемы. При этом вы также можете составлять запросы по всем документам коллекции. NXD с поддержкой таких возможностей называются независимыми от схем.

Наличие таких независимых от схемы коллекций документов придает некоторую гибкость базе данных, а также облегчает процесс разработки приложений. К сожалению, помимо всего прочего, эта особенность доставляет администраторам баз данных немало хлопот из-за риска слабой целостности данных. Здесь уместна старая мудрость о том, что для каждой работы нужен подходящий инструмент. Если вам нужна надежная структура схемы, тогда либо удостоверьтесь, что вы используете NXD, поддерживающую схемы, либо найдите другой способ хранения ваших XML-данных.

Некоторые продукты имеют встроенную поддержку валидации с DTD, и лишь немногие способны работать с коллекциями документов, используя собственный язык схем. Скорей всего, в будущем W3C XML Schema будет использоваться в качестве общего языка схем в NXD. Однако, сейчас его поддержка весьма ограничена.

Запросы

В настоящее время языком запросов для NXD является XPath. Для нормального функционирования в качестве языка запросов баз данных XPath слегка расширен. Так добавлена возможность построения запросов к коллекции документов. Однако, к сожалению, XPath изначально не был предназначен для этой области применения и в некоторых случаях его использование ограничено.

Наиболее очевидные ограничения накладывают недостатки группировки, сортировки, перекрестных объединений документов, а также недостаточная поддержка типов данных. Из-за этих проблем XPath следует применять как часть более полного языка. Так, чтобы заполнить некоторые пробелы, можно было бы использовать XSLT, однако сейчас в разработке находится XQuery -- язык, более ориентированный на базы данных. Некоторые производители уже даже начали использовать прототип XQuery в своих реализациях баз данных.

Для улучшения обработки запросов NXD поддерживают создание индексов для данных, хранимых в коллекциях. Эти индексы могут быть использованы, чтобы значительно повысить скорости выполнения запросов. Детали того, что можно индексировать и как эти индексы создавать, широко варьируются в различных продуктах, но большинство из продуктов поддерживают эту возможность в нескольких формах.

Обновления

Обновления являются слабым звеном современных NXD. Большинство программных продуктов требуют, чтобы вы извлекли документ, изменили его с помощью своего любимого XML API, а потом возвратили его в базу данных. Некоторые программные продукты имеют собственный специальный язык, который позволяет осуществлять обновления на сервере; плюс еще парочка Open Source NXD поддерживает XML:DB XUpdate для этой же цели. Скорее всего, эта проблема не разрешится, пока XQuery не дополнится языком обновления. До этого времени манипулирование с помощью DOM, вероятно, будет самым приемлемым методом обновления.

Области применения

Существует только одно строгое требование к любому приложению, работающему с NXD: приложение должно использовать XML. Помимо этого нет никаких других обязательных правил, регламентирующих какой тип приложений можно или нельзя реализовывать с NXD, и всё-таки предложить некоторые рекомендации имеет смысл. Вообще, более сильной стороной NXD является хранение документ-ориентированных данных (например XHTML, или DocBook), данных, которые имеют очень сложную структуру с глубокой вложенностью, а также слабоструктурированных данных. Как правило, если данные представлены в формате XML и при этом "немного нечетки" (по-моему, прекрасный технический термин), применение NXD будет хорошим решением. NXD может сохранять любые типы XML-данных, но, вероятно, это не самое лучшее инструментальное средство при работе с чем-либо, подобным системе бухгалтерского учета, где данные очень точно определены и жестко заданы.

Перечислим некоторые потенциальные области применения:

• Корпоративыне информационные порталы
• Данные каталогов
• Базы данных частных производств
• Хранение медицинской информации
• Системы управления документами
• Журналы B2B-транзакций
• Персонализационные базы данных

Кроме того, NXD -- просто новое инструментальное средство, и принесенная им польза будет определяться творческим потенциалом разработчиков, использующих его.

Заключение

NXD не являются панацеей и, что совершенно точно, не претендуют на то, чтобы заменить существующие системы баз данных. Это просто другие инструментальные средства, которые разработчик может положить в свой профессиональный багаж. Примененные в нужный момент, при подходящих обстоятельствах, они могут принести значительную пользу. Если вы работаете с большим количеством XML-данных, которые надо сохранять, NXD заслуживает вашего внимания, и вы убедитесь, что это прекрасное средство для решения различных задач.