Модели хранения XML-данных:
единственного варианта на все случаи нет

Марк Скардина, Oracle Magazine RE Январь/Февраль 2004
(XML Storage Models: One Size Does Not Fit All, by Mark Scardina)
Источник: Oracle Technology Network, журнал “Oracle Magazine”, раздел article_online_only, 02 июля 2003,

Выбор модели хранения XML-данных для вашего приложения может определить его успех или неудачу

Подобно многим протоколам, файловым системам и технологиям World Wide Web, Extensible Markup Language (XML) – расширяемый язык разметки – прошел путь от скромного старта к широкому применению за сравнительно короткий период времени.

Первоначально получивший известность среди публикаторов в Web как технология совместного использования документов, XML развился в среду хранения и передачи данных, признанную во всей отрасли.

Когда-то документы, публикуемые в Web, состояли почти только из текстов и изображений, ныне же эти документы (уже на основе XML) становятся наиболее предпочитаемой средой для доставки данных, выбранных из баз данных внутренних (back end) систем, а также приложений и документов среднего (middle tier) уровня и внешних (front end) систем.

Но теперь XML начинает проникать и в базы данных, становясь обязательным элементом структур хранения данных.

Если раньше наборы разработчиков Oracle XML Developers Kits (XDKs) использовались для оперирования с данными в формате XML (или XML-данными) вне баз данных, то в настоящее время разработчики приложений могут распределять обработку этих данных между всеми уровнями, на которых используются интерфейсы прикладного программирования этих наборов -- XDK APIs либо интерфейсы SQL XML.

Перемещение XML в базы данных

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

• либо использовать разборщик (parser), чтобы деконструировать/разложить данные документа в реляционные данные и хранить их как таковые в базе данных,
• либо хранить документ целиком как текстовый файл (в базе как запись), сохраняя тем самым его структуру.

Важно помнить, что “перемещение” XML в базы данных нельзя сделать единым для всех случаев образом. У каждой модели хранения данных есть свои плюсы и минусы. Понимание того, какая модель хранения данных XML наилучшим образом соответствует потребностям вашего приложения, критично для вашего успеха и важнее, чем приспособление вашего приложения к некоторой модели хранения данных XML.

Одна из целей этой статьи и заключается в том, чтобы помочь вам определить оптимальную для себя модель. В этой статье я объясню обе модели хранения:

• “расщепления” ("shredding") документа (деконструирование XML-файла в реляционные данные и затем оперирование с ними через SQL) и модель хранения большого символьного объекта - Character Large Object (CLOB).

Затем я представлю вам репозиторий Oracle's XML DB и собственный (native) XMLType, которые являются комбинацией этих двух моделей с рядом добавленных возможностей. В идеальном случае, вы получите хорошее представление о той модели хранения, которая наилучшим образом соответствует вашему приложению. (См. врезку.)

Какая модель для каких приложений? Приложения для XMLType CLOB Приложения, работающие с документами в целом Web-сайты, приложения управления контентом, архивы документов Приложения, требующие быстрейшей вставки и выборки целых документов Приложения, в которых изменения замещают весь документ Подходящие для документов, описываемых DTD Приложения, требующие памяти для хранения широкого диапазона XML-данных Требуется сохранность/целостность (fidelity) на побайтном уровне Нет требования использовать типы данных Приложения, которые используют поиск в тексте Не требуется доступ через интерфейсы прикладного прогроаммирования (API) XML (DOM, SAX, JAXB). Приложения для XMLType View Приложения, работающие с отдельными данными документов Электронный бизнес, интеграция приложений, синхронизация данных, использование данных для других целей Нет требований сохранить XML-документ на побайтном уровне Приложения, использующие XML как мощное средство передачи данных Приложения, требующие широкого использования всех DML-операций Приложения, требующие полного использования оптимизации SQL Приложения, использующие подробный (fine-grained) доступ и изменение данных Приложения, в которых данные из “источника правды” (“source of truth") переинтрепретируются Приложения, поддноживающие множество XML-схем с единой схемой баз данных. Приложения для XML DB Repository Приложения, работающие как с документами в целом, так и с их отдельными данными Обработка деловых документов, управление контентп (CM) с поддержкой типов данных, динамическая публикация Приложения, требующие структур хранения для данных, определяемыми схемами, в случае стабильной схемы Приложения, требующие применения как SQL, так и текстового поиска Приложения, использующие ограничения и оптимизации SQL Приложения, требующие подробного (fine-grained) изменения данных Приложения, которым необходимы отношения один-ко-многим в документе Приложения, которые необходимы документы с иерархической организацией.

XMLType CLOB

В некотором смысле, использование некоторого XMLType CLOB – это простейший способ хранения XML-файла. При этом документы в формате XML интерпретируются именно как документы. XML-файл сохраняется в структуре внешней памяти как полный текстовый документ (с пробелами (whitespace), комментариями и т.д. в нетронутом виде), при этом он запоминается просто как одна запись (строка символов) в базе данных. Следовательно, файлы любого размера и глубины (уровня вложенности, depth) могут быть сохранены, если они сформированы в формате XML.

Однако, хотя вы можете определить типы данных (datatypes) в документе для проверки по схеме (базы данных), этими данными нельзя манипулировать или выбирать их с применением SQL-запросов.

Из-за этого ограничения для поиска данных в документе нужно использовать механизм текстового поиска (text search engine), а не SQL-запросы, в которых можно воспользоваться функциональностью query rewrites, функциональными индексами и т.д. Эффективное изменение документа ограничено, так как оно требует выборки всего файла, совершения изменений и замены документа (в базе данных). Если, однако, основным назначением ваших XML-документов заключается инкапсуляция контента в некоторую структуру для преобразования (это прежде всего относится к публикации в Web, управлению контентом, архивированию документов и т.д.) и большинство изменений контента совершаются на уровне документа (в целом), тогда XMLType CLOB – это ваш оптимальный выбор для структур хранения XML-данных. В этих случаях, вряд ли вам нужен SQL-контекст для ваших данных и у вас будет гарантия побайтной сохранности (byte-by-byte fidelity). (См. во врезке примеры таких приложений.)

Представления типов данных XML

Альтернативой для CLOB XML Type является создание виртуального XML-документа “поверх” набора реляционных таблиц как "XML view." Такой подход позволяет пользователю вставлять, изменять и уничтожать данные в XML-файле таким же образом, как если бы это были SQL-данные. Так как вы определяете виртуальный XML-документ “поверх” структуры хранения данных, то вы не ограничены только одним представлением данных как с CLOB; наоборот, вы можете иметь множество XML-"документов".

Хранение данных в реляционных таблицах также означает, что вы можете изменять отдельные элементы без выборки всего документа. В целом, с XMLType Views вы получите все преимущества и эффективность, связанные с операциями SQL, так как “движок” реляционной базы данных оптимизирован для такого рода выборок. Наконец, вы можете использовать операции SQL с типами данных для обработки типов данных XML вместо интерпретации их как текста. (Например, дата может быть интерпретирована именно как дата с точки зрения SQL, а не как строка симолов.)

Однако, этому подходу присущи некоторые недостатки. Определение XMLType views, в которых уровень вложенности структур велик (то есть, больше 8-10 уровней) может првести к значительной деградации производительности. Вставка и изменение представлений (views) требует применения тирггеров типа instead-of-triggers, и эти операции трудны в сопровождении, так как вы должны включить код приложения в эти тригерры.

Большим преимуществом применения CLOB является полное сохранение структуры документа и гарантия его сохранности на уровне байтов. Но с XMLType View вы теряете гарантию сохранения упорядоченности документа, так как многие элементы (такие как комментарии и инструкции по обработке) исчезнут при размещении (shredding) данных документа в таблицы (базы данных).

Но это все не имеет значения, конечно, если вы размещаете (в базе данных) ваши данные для использования приложениями, ориентированными на работу с отдельными данными (data-centric applications), и для которых не имеет значения структура документа (в целом). Если вам нужно размещать/выбирать данные в/из базы данных и сохранить метаданные нетронутыми (в качестве единственного контекста) и вы хотите воспользоваться все преимуществами операций DML, то применение XMLType Views – это наилучшее решение: Начните со схемы базы данных и сгенерируйте соответствующую XML-схему. В этом случае, следовательно, нет нужды в упорядоченности документа; любая требуемая упорядоченность секций может быть явно определена через ROWIDs или другие специфичные для приложения методы. В состав СУБД и XDK включены функции для создания XML-схем автоматически из XMLType Views.

Этот метод особенно полезен, если вы работаете с несколькими XML Schemas с различными именами тэгов и структурой и не хотите их определять в схеме вашей базы данных (как в случае, когда от существующих “унаследованных” приложений баз данных требуется поддержка XML и при этом их функциональность должна быть сохранена). В типичном случае, вы можете перенацелить одно и то же хранилище данных для использования рядом заказчиков, которые диктуют форматы и шаблоны вам. Вы просто определяете некоторый XML view для каждого заказчика и когда вы выбираете или вставляете данные, используя этот view, они будут иметь формат, подходящий соответствующему заказчику. (Еще раз см. врезку).

XML-данные, хранимые в XML DB Repositoty

Но можно и приготовить торт, и съесть его, хотя бы до некоторой степени: Вы можете хранить ваш документ как некоторый Native XML Type (см. ниже) в репозитории XML DB (Oracle's XML DB repository), который целиком побайтно сохранит весь документ, а также “разнесет” его в SQL-таблицы. Такой подход предоставляет вам полную достоверность и в то же время позволяет вам выполнять все DML-операции с документом, которые доступны через XML Views. У вас по-прежнему сохраняется детализированное управление данными, и можно создавать множество представлений и документов на основе этих SQL-данных. После регистрации вашей XML-схемы вы запоминаете свои XML-данные в своей базе данных, просто вставляя файл XML-документа с применением SQL, PL/SQL, Java, FTP, HTTP или WebDAV. Выборка XML-данных из базы данных совершается выполнением SQL-запроса или чтением файла одним из стандартных протоколов Internet. Эта функциональность реализована благодаря поддержке встроенной перезаписи запросов (query re-write), которая снимает необходимость в триггерах типа instead-of-triggers.

Помимо легкости работы с XML в форме документа (в целом) или (отдельных) данных, вы получите расширение интерфейсов прикладного программирования объектной модели документа (Document Object Model (DOM) APIs) стандарта косорциума W3C при программном доступе. При разборе XML из файла вы можете построить в оперативной памяти представление в виде дерева всего файла для того чтобы манипулировать с ним. (Такой подход используют и другие XML-процессоры, такие как XSLT.) С возможностью “виртуальная DOM-модель” ("virtual DOM") собственного XMLType, описанной ниже, вы строите такое дерево по требованию: не только сохраняя ресурсы при применении интерфейсов DOM (DOM APIs) и XSLT, но в случае больших документов или наборов строк ваше приложение просто работает (а не падает).

Применение репозитория XML DB дает немало преимуществ, но это неверно для каждого приложения. Могут быть велики накладные расходы при поддержке отношения между полным документом и его “разложенными” (по таблицам) данными. Однако, основная проблема связана с эволюцией схемы. Так как документ (его структура) определяет процесс запоминания (отображение (mapping), какие данные в какие таблицы), то тогда, когда вы хотите изменить схему документа, этот процесс уже не абстракция, он “тонко” привязан к схеме базы данных, чья структура влияет на него. Это означает, что вы не можете выполнить большинство нетривиальных изменений схемы базы данных или документа, если не выполните экспорт всех данных и затем их импорт в базу данных.

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

Собственный XML Type

XML DB в СУБД Oracle вводит собственный (native - “родной”) XMLType как объектный тип Oracle и новый, определяемый пользователем, тип данных, который позволяет абстрагироваться от используемой модели хранения. Он предлагает вам как CLOB, так и объектно-реляционное представление “разложенного” (по базе данных) XML-документа. Это единственный, совместимый с XML Schema 1.0 тип, который может использовать команды как SQL, так и SQL-XML с расширенной функциональностью, включая использование встроенных в базу данных PL/SQL и Java.

Этот тип данных XML предоставляет следующие возможности для управления структурами хранения XML:

• XPath for XML extraction and updating (XPath для XML извлечения и обновления): Пользователи могут использовать XPath чтобы изменять элементы или атрибуты XML-документов без выборки всего документа. Поддержка XPath предоставляется в форме методов extract() и existsNode() XMLType и выражений Xpath, которые могут быть использованы для навигации по экземпляру XMLType и для поиска по множеству экземпляров XMLType. Oracle также дал расширение SQL (совместимое с появляющимся стандартом SQL-XML), так что пользователи могут специфицировать элементы для запросов (к базе данных) или создавать их через XPath, а затем использовать SQL-операторы с этими элементами.
• Virtual DOM (Виртуальная DOM): Одной из проблем обработки DOM-моделей заключается в том, что для оперирования с документом весь этот документ должен быть размещен в оперативной памяти как модель объекта, что приводит к увеличению его размеров во много раз. С большими документами это может быть серьезной проблемой. Но XML DB, однако, позволяет пользователям материализовать DOM-модель “на лету” при обработке запросов (виртуальная ("virtual") или ленивая ("lazy") DOM), при этом, чем делая все сразу; деревья данных загружаются по мере того, как они запрашиваются, предварительно загруженные секции документа отбрасываются, если использование оперативной памяти становится чрезмерным. Эта возможность полностью прозрачна.
• XSL Transformations for XMLType (XSL транформация в XMLType ): Виртуальная DOM-модель особенно полезна при выполнении XSL-преобразований. Как только XSLT-процесс затребует DOM-модель из входного XML-потока, многие пользователи сталкиваются с тем, что документ слишком велик, чтобы завершить этот процесс. Используя виртуальную DOM, однако, пользователи могут обрабатывать только те данные, которые им нужны, отсылать их, фильтровать и получать результаты. Вы можете использовать оператор XML Transform() или метод transform() с любым XMLType.
• Schema caching (Кэширование схемы): XML DB удерживает структурную информацию (такую, как тэги элементов, типы данных и расположение структур хранения) в кэше схемы, чтобы минимизировать время доступа и расходы на память хранения. Этот кэш расположен на уровне процесса, чтобы минимизировать сетевой трафик и тем самым улучшить производительность при сохранении целостности данных.

В будущем Oracle предполагает добавить несколько новых возможностей к этому списку, включая дополнительную функциональность базы данных и XML, такие как XQuery, который будет языком специально разработанным для запросов XML-данных в контексте документа, а а не в контексте строк и таблиц SQL. (Прототип языка XQuery доступен для загрузки на OTN.) XQuery подобен SQL в том, что он обладает специфической грамматикой и использует ключевые слова, но в этом случае предикаты и функции базируются на XPath.

Следующие шаги Посетите и сделайте закладки XML Technology Center сети OTN: http://otn.oracle.com/tech/ xml/content.html Скачайте Oracle XDK: http://otn.oracle.com/tech/xml/ xdk/content.html Прочитайте техническую статью "Oracle XML DB": http://otn.oracle.com/tech/xml/ xmldb/pdf/xmldb_92twp.pdf

Нет волшебных пуль

XML DB в СУБД Oracle – это наиболее продвинутая реализация XML в СУБД и предлагает широкую функциональность, сравнимую с моделями хранения CLOB или XMLType Views. Для приложений подобных тем, которые перечислены в верхней врезке, XML DB предлагает разработчикам мощное и эффективное решение для хранения, запрашивания и манипулирования XML-данных таким способами, которые ранее были невозможны.

Я сравнил и выявил особенности трех различных моделей хранения для XML-данных в СУБД, реализованных в Oracle9i Database Rel 2 чтобы дать вам лучшее представление о том, что лучше соответствует вашим целям. Тщательно выбирайте, исходя из потребностей ваших приложений; и не ориентируйтесь на последние новинки других компаний, преподносимых как полные решения для интеграции XML-документов и баз данных – это очень важно. Такой выбор буквально может означать разницу между созданием успешного прототипа и его внедрением в производство.

---

Марк Скардина (Mark Scardina), проповедник (Evangelist) XML для серверных продуктов Oracle. Он менеджер группы продуктов в подразделении CORE and XML Development Group, его задачи – обеспечение компонентов XML-инфраструктуры, используемых во всех продуктах Oracle, включая XML Developer's Kits. Марк возглавляет комитет Oracle XML Standards и является редактором рабочей группы по W3C XSL. Он часто выступает на отраслевых форумах и конференциях и является соавтором книги The Oracle9i XML Handbook (Oracle Press, 2001).