Интеграция данных в формате XML

Хранение XML-документов в базе данных в виде больших объектов очень удоб­но для определенных типов интеграции SQL/XML. Если XML-документы, на­пример, представляют собой деловые документы текстового типа или же являются текстовыми компонентами Web-страниц, СУБД не обязательно понимать их внутреннюю структуру. Каждый документ может идентифицироваться одним или несколькими ключевыми словами или атрибутами, которые можно извле­кать из документа и хранить в обыкновенных столбцах, используемых для поис­ка данных.

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

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

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

Та же проблема существует и в языке Java, когда XML-документ преобразуется в набор экземпляров классов Java для внутренней обработки.

Процесс декомпозиции XML-документа на составляющие элементы и атрибуты называется демаршалингом. А процесс повторной сборки текста XML-документа из составляющих элементов и атрибутов носит название маршалинга.

Для очень простого XML-документа процесс маршалинга и демаршалинга несложен, и коммерческие СУБД развиваются в направлении его поддержки.

Давайте еще раз рассмотрим простой документ, содержащий заказ товаров, показанный на Рис. 8.1. Его элементы можно поставить в соответствие (один к одному) отдельным столбцам таблицы ZAKAZY. В простейшем случае имена элементов или атрибутов будут идентичны именам соответствующих столбцов.

СУБД может получить XML-документ, подобный приведенному на этом рисунке, автома­тически преобразовать его элементы (или, в зависимости от стиля документа его атрибуты) в значения столбцов, используя имена элементов (или атрибутов). Восстановление такого XML-документа выполняется так же просто. Если имена элементов в XML-документе не соответствуют именам столбцов, СУБД придется проделать немного больше работы. В этом случае необходима дополнитель­ная информация о соответствии между столбцами и элементами или атрибутами. Та­кую информацию проще всего поместить в системный каталог СУБД.

Однако многие реальные XML-документы имеют несколько более сложную струк­туру и их нельзя преобразовать в отдельные строки таблицы. На Рис. 8.2 пока­зан такой же заказ, как на Рис. 8.1, но с несколько расширенной структурой: этот заказ содержит не одну, а несколько позиций заказываемых товаров. Как же выполнить демаршалинг этого документа для помещения его в нашу учебную базу данных?

Можно поместить каждую строку заказа в отдельную строку таб­лицы ZAKAZY. (Для этого примера мы проигнорируем требования уникальности номеров-заказов в таблице ZAKAZY, связанное с тем, что номер заказа является первичным ключом этой таблицы.) В результате некоторые данные таблицы будут повторяться, в нескольких строках будет стоять один и тот же номер заказ, его дата, номер клиента и номер продавца.

<?xml version-"1.0"?> <purchaseOrder> <id_cln>12117</id_cln> <id_order>312961</id_order> <date_order>1989-12-17</date_order> <id_slzh>2106</id_slzh> <terms ship="ground" bill="Net30"></terms> <orderItem> <id_mfr>УАЗ</id_mfr> <id_prd>2A44L</id_prd> <count>7</count> <price_all>31500.00</price_all> </orderItem> <orderItem> <id_mfr>УПЗ</id_mfr> <id_prd>41003</id_prd> <count>1</count> <price_all>652.00</price_all> </orderItem> </purchaseOrder>
Рис. 8.2 - XML-документ, содержащий расширенный заказ товаров

Кроме того, это усложнит маршалинг данных для восстановления документа - СУБД должна будет знать, что в строки с одним номером заказа нужно собрать в один многострочный XML-документ. Очевидно, что для маршалинга и демаршалинга даже такого просто документа требуется достаточно сложная информация о соответствии между компонентами документа, таблицами и столбцами базы данных.

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

Если СУБД поддерживает объектно-реляционные расширения, такие как струк­туриро­ванные типы данных, маршалинг и демаршалинг одновременно и услож­няются и упрощаются. Упрощение достигается за счет того, что отдельные столб­цы таблицы могут иметь иерархическую структуру. В этом случае XML-элемент более высокого уровня (такой как адрес, состоящий из элементов номера дома, улицы, города, области, страны и индекса) может сопоставляться одному столбцу абстрактного типа ADDRESS с собственной внутренней иерархией. Однако при этом усложняется структура базы данных, и для упрощения преобразования между базой данных и XML приходится поступиться гибкостью структуры строки/столбцы.

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

Рис. 8.3 - Маршалинг и демаршалинг XML-документа

СПИСОК ЛИТЕРАТУРЫ

1. Четвериков и др. Базы и банки данных. – М.: Высшая школа, 1987 г.

2. Мартин Дж. Организация баз данных в вычислительных системах. – М.: Мир, 1980 г.

3. Горев А., Эффективная работа с СУБД. – СПб.: Питер, 1997.

4. Хансен Г., Хансен Дж. Базы данных: разработка и управление. – М.: АО БИНОМ, 1999.

5. Епанешников А.М., DELPHI 5. Базы данных. – М.: Диалог – МИФИ, 2000.

6. Рудикова Л.В. Базы данных. Разработка приложений. – СПб.: БХВ-Петербург, 2006 г.

7. Голицына О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. – М.: Форум: Инфра-М, 2006 г.

8. Голицына О.Л., Партыка Т.Л., Попов И.И. Системы управления базами данных: Учебное пособие. – М.: Форум: Инфра-М, 2006 г.

ПРИЛОЖЕНИЕ. Учебные базы данных


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: