Интеграция данных в формате 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 г.
Дата добавления: 2015-02-03; просмотров: 1014;