Декомпозиция документов XML с помощью технологии pureXML в IBM DB2

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Исходные тексты примера Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Берт Линден, архитектор технологии pureXML в DB2, IBM

06.04.2009

Начиная с версии 9.1, DB2 предоставляет значительно расширенный набор возможностей для хранения, управления и поиска в XML-данных. Одним из новшеств является возможность подвергать документы XML декомпозиции с помощью аннотированных XML-схем, что позволяет “раскладывать” (shred) документы по частям, сохраняя их в реляционных таблицах. Существует и альтернативный подход к решению этой задачи – использовать функцию SQL/XML под названием XMLTABLE. В данной статье рассматриваются оба способа декомпозиции. Кроме того, производится сравнение обоих способов, а также приводятся рекомендации для выбора одного из них в зависимости от ситуации.

Введение

К сожалению, несмотря на то, что использование XML становится все более популярным в корпоративных приложениях, хранение XML-документов в родном формате не всегда представляется возможным. Например, подобные трудности возникают при поддержке старых приложений или при наличии других требований, из-за которых приходится использовать реляционные данные. В частности, существуют приложения, которые отправляют и принимают сообщения в формате XML, но хранят их данные в реляционных таблицах. В подобных случаях, когда хранение данных в виде XML невозможно, вам помогут две возможности DB2: функции публикации SQL/XML и декомпозиция XML-документов. Функции публикации служат для создания документов XML из реляционного представления данных. Описание этих функций выходит за рамки нашей статьи - его можно найти в статье "SQL-запросы на получение XML-данных в DB2" (developerWorks, март 2006 г.), в которой также приводится общая информация на тему запрашивания XML-данных в DB2.

В данной статье основное внимание уделяется "разложению" (shredding) документов XML в DB2. Разложение – это процесс сопоставления элементов и атрибутов в XML столбцам в реляционных таблицах. Один из способов осуществления подобной декомпозиции основывается на использовании аннотированных XML-схем. Это наиболее простой и быстрый подход, работающий в случае, если декомпозируемый документ содержит XML-схему. Кроме того, существуют программные средства для автоматизации этапов сопоставления и разложения, что значительно облегчает процесс, особенно в сложных случаях, когда происходит разложение документа на несколько таблиц.

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

Ниже в статье приводятся примеры разложения документов XML как на основе аннотированных схем, так и с помощью функции XMLTABLE. Кроме того, демонстрируются примеры сопоставлений, осуществимых при использовании XMLTABLE, но не поддерживаемых методом на основе схем. Наконец, в статье содержится сравнение данных подходов и приводятся рекомендации по использованию каждого из них.

В начало

Декомпозиция на основе аннотированных схем

Для сохранения документов XML в реляционные таблицы можно использовать возможности DB2 на основе аннотированных XML-схем. Как следует из названия, в данном способе в качестве языка описания соответствия документа XML и реляционных таблиц выступают аннотации в XML-схеме. Для каждого документа XML необходимо указать, какая схема, хранящаяся в репозитории XML-схем в DB2 (DB2 XML Schema Repository - XSR), должна использоваться для декомпозиции. Сама декомпозиция (или разложение) документа происходит за счет вызова хранимой процедуры DB2 или при помощи процессора командной строки (CLP).

Одним из способов добавления аннотаций к XML-схемам является использование продукта IBM Data Studio. Data Studio – это бесплатная интегрированная среда разработки для создания, редактирования, отладки, развертывания и тестирования приложений, работающих с базами данных DB2, включая создание хранимых процедур и пользовательских функций (cсылки на страницу для скачивания приведены в разделе Ресурсы). Data Studio включает в себя редактор аннотаций XML-схем для описания соответствий. Он позволяет сопоставлять XML- и реляционную схемы, используя простой и интуитивно понятный графический интерфейс. Редактор автоматически добавляет аннотации к XML-схеме на основе графических связей между элементами XML и столбцами в реляционных таблицах DB2. После этого остается только сохранить схему, зарегистрировать ее в XSR, и можно начинать процесс декомпозиции и записи документов XML в базу данных DB2.

Для декомпозиции на основе аннотированных XML-схем служит хранимая процедура xdbDecompXML. Существует несколько версий данной процедуры, оптимизированных под разные размеры документов. Они называются следующим образом:

• XdbDecompXML
• XdbDecompXML10MB
• XdbDecompXML25MB
• XdbDecompXML50MB
• XdbDecompXML75MB
• XdbDecompXML100MB

Вся разница между этими процедурами, как и следует из названия, заключается в размере декомпозируемых документов. Например, для декомпозиции документов XML размером до 1 MБ следует использовать процедуру xdbDecompXML, а для документов до 10 МБ - xdbDecompXML10MB. Все функции принимают на вход восемь параметров, три из которых зарезервированы и должны содержать NULL. Ниже приведен список параметров:

• rschema
  Название схемы SQL, являющееся частью имени объекта, зарегистрированного в репозитории XSR.

• xmlschemaname
  Название XML-схемы – вторая часть имени, зарегистрированного в XSR.

• xmldoc
  Декомпозируемый документ XML, передаваемый в функцию в виде BLOB-объекта. Вызываемая функция определяется размером данного объекта.

• documentid
  Идентификатор декомпозируемого документа XML, который затем может быть использован в аннотациях внутри XML-схемы, а именно, в выражениях db2-xdb:expression и db2-xdb:condition.

• validation
  Целочисленный параметр, указывающий на то, должен ли декомпозируемый документ проверяться на соответствие XML-схеме. 0 означает проверку, а 1 – отсутствие проверки.

• reserved
  Последние три параметра зарезервированы и в качестве их значений должен передаваться NULL.

Функция xdbDecompXML в DB2 декомпозирует и сохраняет документ XML в соответствующих таблицах на основе информации, которая содержится в аннотациях внутри XML-схемы, хранящейся в XSR.

Подробное обсуждение аннотаций, используемых в XML-схемах, а также семейства функций xdbDecompXML, выходит за рамки данной статьи. В “Руководстве по DB2 версии 9” (см. Ресурсы) приведена более подробная информация о декомпозиции на основе аннотированных схем, включающая в себя описания таких возможностей, как условная декомпозиция на основе содержимого, а также задание преобразования содержимого документа перед вставкой в таблицы. Тем из вас, кто знаком с продуктом XML Extender и использующимся в нем способе для декомпозиции, рекомендуется ознакомиться со статьей “От DAD к декомпозиции на основе аннотированных XML- схем” (developerWorks, апрель 2006 г.).

В начало

Декомпозиция при помощи функции XMLTABLE

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

Общий синтаксис функции XMLTABLE выглядит следующим образом:

        
XMLTABLE( xquery-expression  PASSING xml-source 
COLUMNS 
column-name	column-(sql)data-type PATH path-xquery-expression
,...)

Параметр xml-source представляет собой документ XML, содержащий входные данные для выражений XQuery. Документ может храниться как внутри DB2, например, в столбце типа XML, так и вне ее. Параметр xquery-expression определяет выражение XQuery, в результате вычисления которого генерируются новые строки в таблице. В таблицу (результат выполнения функции) добавляется по одной строке на каждый элемент выходной последовательности. Структура итоговой таблицы определяется в разделе COLUMNS, в котором описываются характеристики каждого столбца, а именно: имя столбца (column-name), тип данных (column-(sql)data-type) и откуда берется значение столбца. Значение столбца может генерироваться путем вычисления выражения XQuery (параметр path-xquery-expression), указанного в разделе PATH функции XMLTABLE. Этот параметр задает значение столбца относительно элемента, выбранного в процессе вычисления выражения xquery-expression. Более подробная информация приведена в примерах ниже.

При помощи функции XMLTABLE данные извлекаются из документов XML и представляются в табличном виде. Вызов функции можно выполнять совместно с оператором INSERT для немедленной вставки данных в реляционную таблицу. Это позволяет достичь той же функциональности, что и при использовании аннотированных XML-схем. Иногда подобный сценарий называют оператором "Insert-from-XMLTABLE" (вставка-из-XMLTABLE). В данной статье предпочтение отдается термину “декомпозиция при помощи XMLTABLE”.

Данные, передаваемые оператору INSERT, необязательно должны ограничиваться результатом выполнения функции XMLTABLE. Источниками данных могут служить промежуточные переменные, другие таблицы и вызовы XMLTABLES, или даже другие функции, возвращающие таблицы. Сочетание мощи XQuery и SQL придает методу декомпозиции при помощи XMLTABLE особую гибкость. Однако оператор INSERT позволяет вставить данные только в одну таблицу, поэтому требуется несколько вызовов INSERT в случае, если документ XML раскладывается на несколько таблиц. По этой причине вызовы XMLTABLE часто помещают внутрь хранимых процедур. Таким образом, приложению достаточно вызвать процедуру всего один раз, вне зависимости от того, сколько таблиц участвуют в процессе декомпозиции. Это также способствует выигрышу в производительности, потому как внутри хранимой процедуры SQL документ XML разбирается только один раз, даже в случае множественных вызовов функции XMLTABLE.

В начало

Пример декомпозиции документа XML

Пришло время рассмотреть примеры использования обоих подходов к декомпозиции документов XML: на основе аннотированных XML-схем и при помощи функции XMLTABLE.

Пример XML-данных

Допустим, есть данные в формате XML, представляющие собой почтовые сообщения. Ниже показан типичный пример подобного документа.

        
<email:mails xmlns:email="http://mymail.com/mails">
   <mail>
	<envelope>
         <from></from>
	   <to></to>
	   <email:Date></email:Date>
	   <subject></subject>
	</envelope>
	<body></body>
	<attachment></attachment>
   </mail>
   <mail>
	...
   </mail>
	...
</email:mails>

Каждое сообщение (элемент <mail>) состоит из оболочки, тела и вложения. При этом документ XML может содержать неограниченное число сообщений. Для упрощения будем считать, что в качестве вложений могут выступать только текстовые фрагменты, а не двоичные данные.

Реляционная схема

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

        
create table envelopext (
docID 		integer not null generated always as identity primary key, 
mailfrom 	varchar(100), 
mailto		varchar(100), 
maildate 	varchar(30), 
subject 	varchar(100)
);

create table bodyxt (
bodyId		integer not null generated always as identity primary key,
body		varchar(30000)
);

create table attachxt (
attachId	integer not null generated always as identity primary key,
attachment	varchar(100)
);

В начало

Декомпозиция и сохранение XML в реляционных таблицах методом на основе аннотированных XML-схем

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

В приложениях на Java хранимая процедура xdbDecompXML DB2, выполняющая декомпозицию документа XML, может вызываться через JDBC. При этом файл XML передается непосредственно в функцию при помощи класса InputStream. Пример показан в листинге 4.

        
String sql = "{CALL xdbDecompXML(?,?,?,?,?,NULL,NULL,NULL)}";
CallableStatement cstmt = con.prepareCall( sql );

String filename = "mail.xml";
File currFile = new File( filename );
long length = currFile.length();

// Имя SQL-схемы, предположим NULL
cstmt.setNull( 1, Types.VARCHAR );

// Имя XML-схемы
cstmt.setString( 2, "\"TEST001\"" );

// Декомпозируемый XML-документ в виде объекта BLOB
BufferedInputStream bis = 
new BufferedInputStream( new FileInputStream( filename ) );
cstmt.setBinaryStream( 3, bis, ( int ) length );

// Идентификатор документа XML
cstmt.setString( 4, "TEST001" );

// Параметр для активации проверки соответствия документа XML-схеме
int validate = 0;
cstmt.setInt( 5, validate );

/*
Последние 3 параметра зарезервированы для будущего использования
На данный момент в качестве их значений должен быть передан NULL
*/

cstmt.execute();
con.commit();

cstmt.close(); 

С точки зрения приложения, происходит просто обыкновенный вызов хранимой процедуры. Благодаря тому, что XML-схема была заблаговременно аннотирована и зарегистрирована в XSR, вся оставшаяся работа по декомпозиции документа XML и сохранению его в таблицах выполняется внутри данной процедуры.

В начало

Декомпозиция и сохранение XML в реляционных таблицах при помощи функции XMLTABLE

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

Перед тем, как заглянуть внутрь самой процедуры, напишите код для ее вызова. Пример показан в листинге 5.

        
// Вызов хранимой процедуры SQL
String sql = "{CALL XMLTINSERT(?)}";
		
CallableStatement cstmt = con.prepareCall( sql );
String filename = "mail.xml";

File currFile = new File( filename );
long length = currFile.length();
		
BufferedInputStream bis = 
new BufferedInputStream( new FileInputStream( filename ) );

cstmt.setBinaryStream( 1, bis, ( int ) length );
cstmt.execute();
con.commit();
cstmt.close();

Для хранимой процедуры определен один входной параметр типа XML. В остальном ее вызов аналогичен вызову функции xdbDecompXML. Как и ранее, для передачи XML-данных в процедуру используется Java-класс InputStream.

SQL-код хранимой процедуры SQL, внутри которой происходят вызовы функции XMLTABLE для декомпозиции документа XML из вышеприведенного примера, показан в листинге 6.

        
CREATE PROCEDURE XMLTINSERT (IN db2xml XML)
	SPECIFIC XMLTINSERT
------------------------------------------------------------------------
-- Хранимая процедура SQL
-- db2xml - входной параметр типа XML
------------------------------------------------------------------------
P1: BEGIN

-- Вставка в таблицу ENVELOPEXT
INSERT INTO ENVELOPEXT (MAILFROM, MAILTO, MAILDATE, SUBJECT)
SELECT MAILFROM, MAILTO, MAILDATE, SUBJECT
FROM
XMLTABLE(XMLNAMESPACES(
'http://www.sal.com/mails' AS "email"),
'$doc/email:mails/mail'
PASSING  DB2XML AS "doc" 
	COLUMNS 
MAILFROM 	VARCHAR (100)	PATH 'envelope/from',
MAILTO 		VARCHAR (100) 	PATH 'envelope/to',
MAILDATE 	VARCHAR (30) 	PATH 'envelope/email:Date',
SUBJECT 	VARCHAR (100) 	PATH 'envelope/Subject') AS T;
	    
-- Вставка в таблицу BODYXT
INSERT INTO BODYXT (BODY)
SELECT BODY
FROM
XMLTABLE(XMLNAMESPACES(
'http://www.sal.com/mails' AS "email"),
'$doc/email:mails/mail'
PASSING  DB2XML AS "doc" 
	COLUMNS 
BODY 		VARCHAR (30000)	PATH 'body') AS T;
	
-- Вставка в таблицу ATTACHXT
INSERT INTO ATTACHXT (ATTACHMENT)
SELECT ATTACHMENT
FROM
XMLTABLE(XMLNAMESPACES(
'http://www.sal.com/mails' AS "email"),
'$doc/email:mails/mail'
PASSING  DB2XML AS "doc" 
	COLUMNS 
ATTACHMENT 	VARCHAR (100) PATH 'attachment/@email:name') AS T;

END P1%

Обратите внимание на три оператора INSERT – они необходимы потому, что документ должен сохраняться в трех различных таблицах. Также происходят три вызова функции XMLTABLE. Рассмотрим первый оператор INSERT поподробнее:

INSERT INTO ENVELOPEXT (MAILFROM, MAILTO, MAILDATE, SUBJECT)

Это стандартный синтаксис оператора INSERT. Он говорит о том, что будет происходить вставка данных в столбцы MAILFROM, MAILTO, MAILDATE и SUBJECT таблицы ENVELOPEXT. Далее следует раздел, описывающий вставляемые данные:

SELECT MAILFROM, MAILTO, MAILDATE, SUBJECT
FROM

Источником данных является результат выполнения оператора SELECT, возвращающего таблицу со столбцами MAILFROM, MAILTO, MAILDATE и SUBJECT. Здесь-то и начинается самое интересное: оператор SELECT выбирает данные, извлеченные из XML функцией XMLTABLE.

XMLTABLE(XMLNAMESPACES(
'http://www.sal.com/mails' AS "email"),
'$doc/email:mails/mail'
PASSING  DB2XML AS "doc"

XMLTABLE принимает на вход выражение XQuery. В данном случае выражением является следующее:

'$doc/email:mails/mail'

Мы вернемся к этому выражению чуть позже, а пока обратите внимание, как в функцию передается документ XML:

PASSING  DB2XML AS "doc" 

XML-данные хранятся в переменной DB2XML типа XML, являющейся входным (IN) параметром в хранимой процедуре. Выражение XQuery вычисляется над переданным XML-документом (DB2XML) с учетом значения, заданного в разделе AS. Таким образом, результатом вычисления выражения '$doc/email:mails/mail' будет последовательность элементов, соответствующая данному пути в документе XML.

Необходимо упомянуть еще об одном моменте: обратите внимание на пространство имен, сопутствующее описанию пути в выражении XQuery. Для правильного вычисления выражения необходимо точно указать DB2, к какому пространству имен оно относится. Функцию XMLNAMESPACES служит для облегчения подобных действий:

XMLNAMESPACES('http://www.sal.com/mails' AS "email")

При помощи данной функции можно включать пространства имен в статический контекст выражений XQuery, благодаря чему можно избежать повторных объявлений одного и того же пространства имен при описании нескольких выражений. Разумеется, подобные объявления можно включать в прологи выражений XQuery, но вся прелесть использования XMLNAMESPACES заключается в том, что пространства имен могут объявляться единожды для всех выражений, выступающих в качестве аргументов XMLTABLE, ликвидируя, тем самым, дублирование кода.

Табличные функции возвращают результат в виде таблицы, чьи столбцы определяются в разделе COLUMNS:

	COLUMNS 
MAILFROM 	VARCHAR (100)	PATH 'envelope/from',
MAILTO 		VARCHAR (100) 	PATH 'envelope/to',
MAILDATE 	VARCHAR (30) 	PATH 'envelope/email:Date',
SUBJECT 	VARCHAR (100) 	PATH 'envelope/Subject') AS T;

Каждый раздел PATH описывает собственное выражение XPath, но оно вычисляется в контексте не всего документа, а относительно главного выражения, описанного выше ($doc/email:mails/mail'). Таким образом, выражение envelope/From задает путь относительно элемента <mail>. Типом столбца MAILFROM является VARCHAR(100), а значения выбираются по абсолютному пути $doc/email:mails/mail/envelope/from. Другие столбцы заполняются данными по аналогичному принципу.

Данные из таблицы-результата выполнения функции XMLTABLE вставляются в другую таблицу - ENVELOPEXT. Аналогичным образом вставляются данные в таблицы BODYXT и ATTACHXT. Обратите внимание, что в процессе выполнения всей процедуры документ XML хранится в переменной, что означает, что он разбирается всего один раз.

Вспомните, как выглядел исходный документ XML. При выполнении функции XMLTABLE создается по строке на каждый элемент <mail>, таким образом, при вызове одной хранимой процедуры будет сгенерировано множество строк в нескольких таблицах. Например, если документ содержал 20 элементов <mail>, то в таблицу ENVELOPEXT будет вставлено 20 строк.

Сохранив текст процедуры в файле под именем xtinsert.db2, саму процедуру вы или ваш администратор DB2 можете создать, используя следующую команду CLP (она также может быть выполнена программным способом):

db2 -td% -vf xtinsert.db2

В начало

Особые случаи при декомпозиции документов XML

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

Декомпозиция документов XBRL, содержащих отношения типа “многие-ко-многим” между дочерними элементами

С технической точки зрения расширяемый язык деловой отчетности (eXtensible Business Reporting Language - XBRL) представляет интерес благодаря своему подходу к описанию отношений между элементами. Данные отношения служат для представления реальных бизнес-процессов.

В листинге 7 приведен пример простого документа XBRL.

        
<?xml version="1.0" encoding="utf-8"?>
<linkbase 
   xmlns="http://www.xbrl.org/2003/linkbase" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:xlink="http://www.w3.org/1999/xlink" 
   xsi:schemaLocation="http://www.xbrl.org/2003/linkbase xbrl-linkbase-2003-12-31.xsd">
                                                     
  <calculationLink 
	xlink:type="extended" 
	xlink:role=http://www.xbrl.org/2003/role/link 
	xlink:title="Calculations, All">

    <loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_TotalPropertyPlantEquipment" 
	xlink:label="ci_TotalPropertyPlantEquipment" />

    <loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_Land" 
	xlink:label="ci_Land" />

    <loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_Building" 
	xlink:label="ci_Building" />

    <loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_FurnitureFixtures" 
	xlink:label="ci_FurnitureFixtures" />

    <loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_ComputerEquipment" 
	xlink:label="ci_ComputerEquipment" />

    <loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_Other" 
	xlink:label="ci_Other" />

    <calculationArc 
	xlink:type="arc" 
	xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" 
	xlink:from="ci_TotalPropertyPlantEquipment" 
	xlink:to="ci_Land" order="1" weight="1" use="optional" />

    <calculationArc 
	xlink:type="arc" 
	xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" 
	xlink:from="ci_TotalPropertyPlantEquipment" 
	xlink:to="ci_Building" order="2" weight="1" use="optional" />

    <calculationArc 
	xlink:type="arc" 
	xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" 
	xlink:from="ci_TotalPropertyPlantEquipment" 
	xlink:to="ci_FurnitureFixtures" order="3" weight="1" use="optional" />

    <calculationArc 
	xlink:type="arc" 
	xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" 
	xlink:from="ci_TotalPropertyPlantEquipment" 
	xlink:to="ci_ComputerEquipment" order="4" weight="1" use="optional" />

    <calculationArc 
	xlink:type="arc" 
	xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" 
	xlink:from="ci_TotalPropertyPlantEquipment" 
	xlink:to="ci_Other" order="5" weight="1" use="optional" />

  </calculationLink>
</linkbase>

XBRL: Расширяемый язык деловой отчетности XBRL – это язык на основе XML, используемый для обмена деловой и финансовой информацией. Основным применением этого открытого, набирающего популярность стандарта является сбор данных и предоставление финансовых отчетов. XBRL предоставляет средства для описания отношений между объектами, что позволяет представлять информацию о соответствующих им финансовых показателях, а также о том, можно ли отнести объекты к категориям, определенным в целях структурирования или представления данных. Ссылки на источники более подробной информации приведены в разделе Ресурсы.

XBRL является семантическим расширением XML. Одним из ключевых расширений является возможность соединения объектов в XML при помощи ребер (arc). В данном документе интерес представляют элементы <calculationArc>, определяющие отношения между активами. С помощью атрибутов "arcrole", значениями которых являются URI, указывается, что ребра данного вида описывают отношения суммирования между атрибутами "to" и "from". Атрибуты “to” содержат идентификаторы суммируемых объектов, например, "ci_Land" и "ci_Building". В результате суммирования вычисляется стоимость объекта, идентифицируемого значением атрибута "from", в данном случае, "ci_TotalPropertyPlantEquipment".

Значения атрибутов "to" и "from", например, "ci_Land" или "ci_Building", на самом деле являются метками. Для определения того, к какому объекту относится данная метка, служат элементы <loc>. Обратите внимание на элемент <loc>, чей атрибут "label" содержит значение "ci_Land".

<loc 
	xlink:type="locator" 
	xlink:href="BasicCalculation.xsd#ci_Land" 
	xlink:label="ci_Land" />

Как видите, этот элемент содержит атрибут “href”, указывающий на XML-схему "BasicCalculation.xsd". Если заглянуть в этот файл, то можно найти фактическое значение объекта "ci_land".

Подробный анализ данных в формате XBRL выходит за рамки данной статьи, но легко представить задачу декомпозиции подобных XML-документов c целью сохранения атрибутов "from" и "to" их в таблице отношений. Однако вместо меток желательно сохранять полные ссылки на фактические значения.

Таблица будет содержать три столбца: автоматически генерируемое поле ARCID, а также ARCFROM и ARCID (см. листинг 8).

        
CREATE TABLE ARC (
  ARCID		integer not null generated always as identity primary key,
  ARCFROM	varchar(100),
  ARCTO		varchar(100)
);

В процессе декомпозиции значения атрибутов "from" и "to" элементов <calculationArc> заменяются значениями атрибутов "href" в соответствующих элементах <loc>. В качестве примера рассмотрим следующий элемент:

<calculationArc 
	xlink:type="arc" 
	xlink:arcrole="http://www.xbrl.org/2003/arcrole/summation-item" 
	xlink:from="ci_TotalPropertyPlantEquipment" 
	xlink:to="ci_Land" order="1" weight="1" use="optional" />

Значения BasicCalculation.xsd#ci_TotalPropertyPlantEquipment и BasicCalculation.xsd#ci_Land, содержащиеся в элементе <loc> вставляются в столбцы ARCFROM и ARCTO таблицы ARC. Эти значения соответствуют меткам from="ci_TotalPropertyPlantEquipment" и to="ci_Land" в элементе <calculationArc>. Другие строки таблицы создаются аналогичным образом.

Подобного рода декомпозицию, предполагающую сохранение множественных связей типа “многие ко многим” и условную вставку строк в таблицы, при которой необходимо принимать во внимания значения элементов, невозможно осуществить при помощи аннотированных XML-схем. В этом случае вас выручит функция XMLTABLE. Как уже говорилось ранее, данный метод основан на вычислении выражений языка XQuery, что и делает его столь мощным инструментом.

Код хранимой процедуры, выполняющей декомпозицию, приведен в листинге 9.

        
CREATE PROCEDURE XMLTINSERT2 ( IN db2xml XML )
	SPECIFIC XMLTINSERT2
------------------------------------------------------------------------
-- Хранимая процедура SQL
-- db2xml 
------------------------------------------------------------------------
P1: BEGIN
INSERT INTO ARC
	(ARCFROM,
	ARCTO) 
SELECT	
	ARCFROM,
	ARCTO 
	FROM XMLTABLE(
	'$doc/*:linkbase/*:calculationLink/*:calculationArc' 
		PASSING DB2XML AS "doc"
		COLUMNS
ARCFROM VARCHAR(100) PATH 'let $x := . return $x/../*:loc[@*:label=$x/@*:from]/@*:href',
ARCTO 	VARCHAR(100) PATH 'let $x := . return $x/../*:loc[@*:label=$x/@*:to]/@*:href'
	)AS T;	
END P1%

Сначала в качестве контекста устанавливается элемент <calculationArc>. Это делается с помощью следующего выражения XQuery:

'$doc/*:linkbase/*:calculationLink/*:calculationArc'

Обратите внимание, что исходный документ XBRL содержит несколько разных пространств имен. В данном выражении они не играют никакой роли, поэтому используется символ-шаблон (*). Если бы в документе содержалось несколько элементов <calculationArc>, принадлежащих разным пространствам имен, то это представляло бы некоторые трудности, но в данном случае все проще.

Все остальные данные можно получить, находясь в данном контексте. Взгляните на выражение PATH в разделе COLUMNS. Для получения значения для столбца ARCFROM необходимо найти элемент, который содержит атрибут "label", соответствующий значению атрибута "from" в текущем контексте. Для осуществления подобной проверки можно использовать дополнительную переменную $x, определяющую текущий элемент. Для этого служит ключевое слово let в языке XQuery. Затем необходимо переместиться на уровень выше текущего контекста, найти элемент <loc>, чей атрибут “label” равен текущему атрибуту “from”, и вернуть значение атрибута “href”.

'let $x := . return $x/../*:loc[@*:label=$x/@*:from]/@*:href'

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

Документы XML, содержащие рекурсивные элементы

В листинге 10 приведен еще один распространенный на практике пример документа XML.

        
<?xml version="1.0" encoding="UTF-8"?>
<items>
   <item desc="computersystem" model="L1234123">
	  <part desc="computer" partnum="5423452345">
		<part desc="motherboard" partnum="5423452345">
			<part desc="CPU" partnum="6109486697">
				<part desc="register" partnum="6109486697"/>
			</part>
			<part desc="memory" partnum="545454232">
				<part desc="transistor" partnum="6109486697"/>
			</part>
		</part>
		
		<part desc="diskdrive" partnum="6345634563456">
			<part desc="spindlemotor" partnum="191986123"/>
		</part>
		<part desc="powersupply" partnum="098765343">
			<part desc="powercord" partnum="191986123"/>
		</part>
	  </part>
	
	  <part desc="monitor" partnum="898234234">
		<part desc="cathoderaytube" partnum="191986123"/>
	  </part>
	
	  <part desc="keyboard" partnum="191986123">
		<part desc="keycaps" partnum="191986123"/>
	  </part>
	
	  <part desc="mouse" partnum="98798734">
		<part desc="mouseball" partnum="98798734"/>
	  </part>
   </item>
</items>

Подобного рода документы XML часто называют “материальной ведомостью”. В данном примере документ содержит только один объект, но потенциально их может быть сколь угодно много. Интерес в этом примере представляет рекурсивный элемент <part>. Элементы <item> могут содержать дочерние элементы <part>, которые в свою очередь могут являться родительскими по отношению к элементам <part> следующего уровня и так далее до бесконечности.

Рассмотрим процесс декомпозиции и сохранения данного документа в таблицу ITEM со столбцами ITEMNAME, PART и PARENT.

        
CREATE TABLE ITEM (
  PID		integer not null generated always as identity primary key,
  ITEMNAME	varchar(25),
  PART		varchar(25),
  PARENT	varchar(25)
);

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

        
CREATE PROCEDURE XMLTINSERT3 ( IN db2xml XML )
	SPECIFIC XMLTINSERT3
------------------------------------------------------------------------
-- Хранимая процедура SQL
-- db2xml 
------------------------------------------------------------------------
P1: BEGIN
INSERT INTO ITEM
	(ITEMNAME,
	PART,
	PARENT) 
SELECT 	
	A.ITEMNAME,
	B.PART,
	B.PARENT
	FROM 
	XMLTABLE('$doc/items/item' PASSING DB2XML AS "doc"
	COLUMNS
		ITEMNAME 	VARCHAR(25)	PATH './@desc',
		ITEM		XML			PATH '.'
	)AS A,
	XMLTABLE('$doc//part' PASSING A.ITEM AS "doc"
	COLUMNS
		PART 		VARCHAR(30) PATH './@desc',
		PARENT		VARCHAR(35) PATH '../@desc'
	)AS B;	
END P1%

В этом примере при помощи оператора INSERT вставляются данные, поступающие из двух источников (вызовов XMLTABLE). Первый вызов функции XMLTABLE возвращает список названий каждого объектов, используя в качестве контекстной вершины $doc/items/item. Кроме того, извлекается поддерево для каждого элемента item, которое затем декомпозируется внутри второго вызова XMLTABLE.

Вторая функция XMLTABLE использует выражение XQuery, которое выбирает все элементы <part> из поддерева, относящегося к текущему элементу <item> (A.ITEM). При этом выражение $doc//part говорит о том, что уровень вложенности элементов <part> не играет никакой роли.

Элементы <part> составляют описание текущего объекта. Для получения описания родительского объекта необходимо подняться на один уровень вверх. Содержимое таблицы ITEM после вызова хранимой процедуры и декомпозиции документа XML приведено в таблице 2.

Иерархия частей может быть легко восстановлена из табличного представления при помощи столбца PARENT. Например, строка 4 относится к части "register". Исходя из данных в столбце PARENT, ее родительским объектом является "CPU". Родителем по отношению к "CPU" является "motherboard", в свою очередь являющийся дочерним элементом "computer". Наконец родительский элемент "computer" – это "computersystem" – элемент верхнего уровня.

В начало

Сравнение производительности

FpML: Язык разметки для финансовых продуктов Язык разметки для финансовых продуктов (Financial products Markup Language - FpML) - это индустриальный протокол, применяющийся в сложных финансовых приложениях. FpML служит для представления внебиржевых производных операций, чья стоимость вычисляется на основе активов, торги по которым происходят в двустороннем порядке между участниками (в отличие от открытых торгов). Подобные операции играют значительную роль на современных финансовых рынках, а участвующие в них компании вкладывают серьезные средства в их техническое обеспечение с целью минимизации рисков. В примере, который приведен в разделе, посвященном сравнению производительности, используется рекомендуемая спецификация FpML, выпущенная 14 июля 2005 г. Ссылки на более полные источники информации приведены в разделе Ресурсы.

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

Простой вариант декомпозиции

Сначала была проведена декомпозиция XML на основе расширенной, проприетарной XML-схемы, описывающей модель содержимого FpML-сообщений. Схема состояла из 23 документов общим размером 871 КБ, а декомпозиция заключалась в том, что 12 наиболее часто встречающихся элементов XML раскладывались по 12 столбцам в одной реляционной таблице. В этой ситуации, при которой декомпозиция затрагивает лишь небольшое число столбцов, разница в производительности между методами на основе аннотированных схем и при помощи функции XMLTABLE была фактически незаметной.

Сложный вариант декомпозиции

Кроме того, мы провели эксперименты с использованием проприетарной аннотированной XML-схемы, предоставленной одним из клиентов. Схема представляла собой единый документ XML объемом примерно 142 КБ. Сами данные декомпозировались и сохранялись 21 таблице, причем общее количество столбцов составляло несколько сотен. Некоторые элементы XML сохранялись в одной строке таблицы, другие же распределялись по нескольким. В таких условиях метод на основе аннотированной схемы показывал производительность примерно на 40% выше, чем при использовании функции XMLTABLE.

Соображения на тему результатов

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

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

В начало

Рекомендации по выбору метода декомпозиции

Как видите, методы на основе аннотированных схем и при помощи функции XMLTABLE – это два различных подхода к декомпозиции и сохранения документов XML в реляционных таблицах. Можно привести несколько рекомендаций, которые должны помочь вам решить, как из методов лучше подходит для использования в ваших приложениях.

XML-данные и XML-схема

Наиболее очевидный момент, о котором не следует забывать – это то, что использовании функции XMLTABLE не требуется наличия XML-схемы; все, что требуется – это сами данные. В случае использования второго метода соответствие должно описываться в виде аннотаций внутри XML-схемы.

Последствия внесения изменений в сопоставление

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

При использовании XMLTABLE соответствие описывается при помощи выражений XQuery, поэтому его изменение влечет за собой необходимость ручного редактирования всех соответствующих выражений. Если XMLTABLE вызывается внутри хранимой процедуры (как в примерах выше), то для внесения изменений придется пересоздать процедуру.

Гибкость описания сопоставления

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

При использовании метода на основе XMLTABLE может быть несколько источников данных, вставляемых в таблицы с помощью оператора INSERT, причем в качестве источников могут выступать любые табличные данные, а не только результат выполнения XMLTABLE. Кроме того, язык XQuery позволяет создавать сколько угодно сложные выражения, что делает процесс описания соответствий значительно более гибким. Другими словами, гибкость ограничивается только фантазией разработчика. В то же время, за эту гибкость приходится платить повышением сложности, что приводит к тому, что разработчики, плохо знакомые с языком XQuery, могут иметь трудности с пониманием сопоставления. Наконец, описание сопоставления с помощью выражений XQuery может превратиться в утомительное занятие, особенно при большом количестве таблиц и столбцов в каждой таблице.

В начало

Заключение

Share this tutorial Digg this story Post to del.icio.us Slashdot it!

В целом, оба метода декомпозиции – на основе аннотированных XML-схем и при помощи функции XMLTABLE – являются гибкими и мощными инструментами, и выбор одного из них часто становится делом вкуса. Однако есть ситуации, при которых использование того или иного способа предпочтительнее.

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

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

Использование декомпозиции при помощи XMLTABLE рассматривалось в данной статье в качестве альтернативы методу на основе аннотированных XML-схем. В статье были приведены некоторые рекомендации и типичные сценарии использования обоих методов. Оба подхода поддерживаются в pureXML – технологии работы с XML в DB2. Благодаря этим возможностям разработчики и администраторы могут выбирать способ работы с данными, который подходит наилучшим образом в той или иной ситуации.

Благодарности

Авторы благодарят следующих разработчиков из команды DB2 pureXML Development, базирующейся в лаборатории IBM в Силиконовой Долине (IBM Silicon Valley Lab), за множество полезных замечаний и отзывов о данной статье: Силин Чеюн (Seeling Cheung), Дана Нгуена (Dung Nguyen), Маянка Прадана (Mayank Pradhan), Дэвида Салинеро (David Salinero) и Синтию Саракко (Cynthia Saracco).

В начало

Загрузка

	Информация о методах загрузки

Ресурсы

• Оригинал статьи: “Shred XML documents using DB2 pureXML” (Сальвадор Ледесма, Берт ван дер Линден, январь 2008 г.). (EN)
  
  
• Обратитесь к страницам Wiki, описывающим поддержку XML в DB2. Прочитав данные материалы, вы быстро получите навыки работы с XML в DB2. Кроме того, эти страницы содержат ссылки на множество руководств, справочных статей и другие ресурсы, описывающие возможности DB2 для хранения и поиска в данных XML. (EN)
  
  
• Прочитайте статью “SQL-запросы на получение XML-данных в DB2” (developerWorks, март 2006 г.), в которой содержится введение в функции публикации SQL/XML, а также общая информация о написании запросов на получение XML-данных в DB2. (EN)
  
  
• Ознакомьтесь с 10-ой главой руководства по использованию XML в DB2 версии 9 для Linux, Unix и Windows, под заголовком: “Декомпозиция на основе аннотированных XML-схем”. (EN)
  
  
• Прочитайте статью “От схемы DAD к декомпозиции на основе аннотированных XML-схем” (developerWorks, апрель 2006 г.), в которой описывается переход от варианта декомпозиции, используемом в XML Extender к декомпозиции на основе аннотированных XML-cхем. (EN)
  
  
• Ознакомьтесь со статьей “Разработка Java-приложений для работы с XML-данными в DB2” (developerWorks, май 2006 г.), рассказывающей о доступе к XML-данным в DB2, в том числе и при помощи вызова хранимых процедур, из приложений Java.
  
  
• Узнайте больше о языке XBRL. (EN)
  
  
• Узнайте больше о языке FpML. (EN)
  
  
• Обратитесь к магазину технической литературы, содержащему книги на данную и другие темы. (EN)
  
  

• Загрузите DB2 9.5 и опробуйте в деле ее возможности для работы с XML. (EN)
  
  
• Загрузите IBM Data Studio – среду для быстрой разработки приложений, работающих с базами данных. (EN)
  
  
• Загрузите ознакомительные версии программных продуктов IBM и получите навыки использования инструментов для разработки приложений и связующего ПО для DB2®, Lotus ®, Rational®, Tivoli® и WebSphere®. (EN)

• Примите участие в обсуждении материала на форуме.
  
  
• Читайте блоги developerWorks и становитесь членами нашего сообщества. (EN)
  
  

Об авторе

		Берт (Bert van der Linden) присоединился к команде разработчиков IBM в 2001 г., начав работать над проектом XML в DB2 в качестве одного из первых архитекторов. Берт пришел в IBM из молодой компании Propel, в которой он руководил проектированием и разработкой распределенного и отказоустойчивого программного обеспечения для хостинга масштабного приложения электронной коммерции. Перед этим Берт много лет работал в компании Tandem Computers над продуктом NonStop SQL – СУБД, которая используется в работе многих ключевых приложений финансовой индустрии.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

Поделиться этой статьей: забобрить сохранить в memori

В начало