1. Введение

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

Существует два фундаментальных подхода к решению этой проблемы. Первый подход связан с построением хранилищ данных (Data Warehouses), когда интегрируемые данные из разных источников трансформируются в соответствии с целевой моделью данных и помещаются в одну локальную базу данных. Этому подходу посвящено множество публикаций (см., например, [1]).

Второй подход связан с понятием виртуальной интеграции гетерогенных источников данных, когда данные не материализуются в локальной базе данных, а промежуточное программное обеспечение транслирует пользовательские запросы в подзапросы к источникам и формирует окончательный результат. Краткий обзор эволюции систем, использующий виртуальный подход, включая мультибазы данных [2] и федеративные базы данных [3], можно найти в [4]. Подход этих систем характеризуется, прежде всего, тем, что интегрируются данные с четкой структурой (хотя структура данных разных источников может различаться). На следующем этапе появились системы интеграции, основанные на использовании медиаторов [5] и создаваемые на базе полуструктурированных данных [6]. Возникновение XML [7] и сопутствующих технологий (XSLT [8], Xquery [9]) вызвало всплеск новых разработок технологии виртуальной интеграции ([10], [11] и т.д.).

Обсуждаемая в этом докладе система виртуальной интеграции BizQuery основа на использовании технологий XML [7] и UML [12]. Система разработана группой MODIS Института системного программирования РАН (www.ispras.ru/^modis), которая на протяжении последних трех лет занимается вопросами исследования и разработки методов управления XML-данными. BizQuery обладает следующими основными чертами:

• обеспечение интегрированного доступа к нескольким источником данных, каждый из которых может содержать реляционные данные, либо XML-данные;
• использование XML как для внутреннего представления данных, так и для представления результирующих данных запроса;
• представление глобальной схемы интегрированных данных как в терминах UML, так и в терминах XML;
• использование деклативных языков запросов UQL(разработан в ходе выполнения проекта [4]) и XQuery для формулировки запросов к интегрированным данным в терминах UML и XML соответственно;
• полнофункциональная обработка запросов, включающая оптимизацию запросов, их декомпозицию с выделением частичных запросов, адресованных индивидуальным источникам данных, и формирование окончательного результата путем выполнения соединений и трансформаций частичных результатов.

2. Архитектура системы

Рассмотрим архитектуру системы BizQuery и поясним назначение основных компонентов. Выделим две фазы использования системы: подготовительную фазу, или фазу внедрения системы (рис. 1a) и фазу выполнения, когда системе интеграции можно адресовать запросы (рис. 1b).

Рис. 1. Архитектура системы: (a) – фаза внедрения; (b) – фаза выполнения

2.1 Фаза внедрения

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

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

Затем глобальная UML-схема преобразуется в XML-документ в формате XMI [13]. Этот документ представляет собой глобальную XML-схему. Именно глобальная XML-схема является ключом для функционирования системы, независимо от того, каким образом она была произведена. Иначе говоря, для интеграции данных в терминах XML (если не требуется обеспечивать доступ на уровне UML) совершенно не обязательно создавать UML-схему, если есть возможность сразу предоставить XML-схему.

На этом этапе требуются только схемы хранимых данных интегрируемых источников. В первых версиях BizQuery разработчиков интересовала, прежде всего, структурная информация о схемах источников, и поэтому для хранения схемы использовался формат DTD. В настоящее время для функционирования системы стала существенной более полная информация о схемах источников, и происходит процесс миграции к использванию формата Relax NG[14]. Для источников XML-данных схема данных должна быть предоставлена явно, для реляционных источников схема формируется автоматически средствами системы.

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

Итак, схема B получается из схемы A итеративным путем, посредством последовательного применения функций трансформации. Операции применения функции трансформации замкнуты относительно множества схем, то есть представляют собой алгебру. Единственным ограничением является то, что результирующая схема должна быть выводимой из исходной. На практике это означает, что в трансформациях не должно быть зависимости по данным, например, недопустима ситуация, когда содержимое элемента становится именем нового элемента.

С помощью обеспечиваемых BizQuery Mapper операций, которые манипулируют поддеревьями, а не узлами или последовательностями узлов XML-документа, многие трансформационные запросы выражаются проще, чем на XQuery. Тем не менее, отображение, построенное в высокоуровневых терминах, переводится в целевой язык системы интеграции Xquery, микрооперации которого проще оптимизировать и выполнять.

2.2 Фаза выполнения

Подсистема BizQuery времени выполнения состоит из двух основных компонентов: BizQuery Integration Server (BQIS) and User Interface Management Server (UIMS). BQIS отвечает за обработку запросов, сформулированных на языках UQL или XQuery. Все UQL-запросы транслируются в XQuery-запросы, и реальная обработка запроса выполняется в терминах XML. Эта возможность обеспечивается благодаря наличию метаданных, которые, с одной стороны, описывают исходную модель, а с другой стороны, сами представлены на XML.

В обрабатываемый XQuery-запрос прежде всего подставляются представления, хранимые в репозитории BizQuery Repository (заметим, что в результате этой подстановки запрос переформулируются в терминах схем локальных источников, и структура запроса обычно существенно усложняется). После этого запрос оптимизируется логическим оптимизатором системы, который пребразует запрос на основе правил перезаписи, значительно упрощая и “улучшая” его формулировку. В действительности, этот шаг является одним из наиболее важным в процессе обработки запроса. Используемые методы оптимизации являются достаточно сложными с технической точки зрения и не будут более подробно обсуждаться в этом докладе. Детали можно найти, например, в [15].

Оптимизированный запрос подвергается декомпозиции в набор частичных запросов (представленных на языке XQuery), каждый из которых сформулирован в терминах локальной схемы единственного соответствующего локального источника. Каждый частичный запрос транслируется “оберткой” (wrapper) соответствующего локального источника на язык запросов, понимаемый локальным источником данных (поддрживаются обертки SQL и XQuery). Трансляция на XQuery тривиальна, но переформулирование произвольного XQuery-запроса к реляционным данным в виде SQL-запроса является не очень простой задачей. Опустим технические детали.

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

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

BQIS реализует API для взаимодействия клиентских приложений с сервером интеграции посредством задания Xquery- и UQL-запросов, то есть поддерживает низкоуровневый интерфейс доступа к данным, использование которого, вообще говоря, затруднительно для конечного пользователя. Основное назначение UIMS состоит в сглаживании разрыва между пользователем и BQIS. UIMS предоставляет три вида графических интерфейсов пользователя для доступа к данным в терминах UML. Каталоги обеспечивают навигационный интерфейс доступа к данным, когда пользователь имеет возможность просматривать существующие экземпляры классов UML-модели и переходить по ссылкам от одного экземпляра к другому. Два других интерфейса — Forms и Graphic Map — являются декларативными. Они позволяют перемещаться по UML-модели и накладывать условия на атрибуты экземпляров класса. Во всех случаях в результате действия пользователя генерируется UQL-запрос, который адресуется BQIS, а полученный результат отображается на экране. Поскольку пользователь оперирует только понятиями UML-модели, выразительных средств UQL оказывается достаточно для формулирования запроса.

UIMS реализован в виде Web-приложения и обеспечивает развитые возможности настройки, поскольку в нем используется XSLT. Графический интерфейс пользователя генерируется автоматически по UML-модели, хранящейся в репозитории BizQuery.

3. Анализ производительности

В этом разделе представлены результаты тестирования производительности системы BizQuery. Необходимо заметить, что в открытом доступе сегодня не существует средств тестирования производительности систем, подобных BizQuery. Поэтому разработчикам пришлось воспользоваться пакетом XMark [16], предназначенным для тестирования XML СУБД, и адаптировать его для BizQuery.

Документ, соответствующий DTD XMark auctions, был разбит на части, которые были распределены по трем источникам — одному XML-источнику и двум реляционным. В качестве XML-источника выступала программа QuiP [17] компании Software AG, представляющая собой XQuery-процессор над файловой системой. В качестве реляционного источника использовалась СУБД Oracle 8i. Необходимо заметить, что программный прототип QuiP не является полноценной СУБД. Поэтому его производительность была невысокой, что повлияло на распределение данных. Кроме того, чтобы представить определенные части исходного документа в виде реляционных таблиц, пришлось упростить эти части (например, избавлением от вложенности элементов).

Таким образом, первый реляционный источник содержал 5 таблиц, суммарное количество картежей которых превышало 1,8 миллиона. Второй реляционный источник содержал 3 таблицы с более чем 4,2 миллионами кортежей. Суммарный объем XML файлов, по которым строились реляционные таблицы, превышает 700Mb. XML источник содержал 4 файла, общим объемом 5,8Mb.

Для измерения производительности использовалась следующая конфигурация. BizQuery Integration Server работал на Pentium-IV 1500Mhz c 512Mb RAM. Для XML источника данных (QuiP) использовалась такая же машина. Оба сервера реляционных СУБД (Oracle) работали на машинах одинаковой конфигурации —Pentium-III 733Mhz с 256Mb RAM. Все машины работали под управлением Windows 2000.

В таб. 1 приведены запросы, для которых приводятся результаты измерения.

Q1	for $x in document("real:sql1/item")/table/tuple where $x/QUANTITY="5" and $x/location="Germany" return $x
Q2	for $y in document("real:sql2/interest")/table/tuple for $z in document("real:sql2/people")/table/tuple[business="yes" and city="Moscow"] for $x in document("real:sql1/categories")/table/tuple[name="all"] where $y/ref_category=$x/id_category and $y/ref_person=$z/id_person return ($x, $z)
Q3	document("virtual:closed_auction.xml")
Q4	for $v in document("virtual:item.xml")/item[location="United States"] for $z in document("real:sql1/mailbox")/table/tuple[mail_date="12/11/99"] where $v/id=$z/ref_item return element {name($v)} {$v/*[not empty(./text())]}

Таб. 1. Запросы, использованные при тестировании

Запрос Q1 адресован к реальному документу item (таблице реляционного источника 1) и просто налагает условие на данные. Запрос Q2 содержит два соединения, одно из которых выполняется между документами одного источника, а второе соединение — кроссдоменное — между разными реляционными источниками. Запрос Q3 показывает возможность построения виртуального документа closed_auctions.xml целиком. И наконец, запрос Q4 выполняет соединение между виртуальным документом item.xml и реальным документом mailbox из второго реляционного источника. Результаты выполнения представлены в таб. 2.

Номер запроса	Размер результатав (в Kб)	Общее время работы источников	Время работы BizQuery	Общее время выполнения
Q1	23	5,984	0,078	6,062
Q2	12	82,485	1,796	84,281
Q3	3673	67,907	3,093	71,000
Q4	27	52,766	0,938	53,704

Таб. 1. Результаты тестирования

Во всех четырех запросах, в независимости от общего времени выполнения, чистое время работы BizQuery (включающее оптимизацию и, если необходимо, выполнение кроссдоменных операций) относительно невелико. Это обеспечивается посредством перезаписи запросов (особенно в запросе Q4, где производится соединение виртуального документа с реальным) и декомпозиции запросов, которое приводит к выделению наиболее ресурсоемкой части запроса источнику. Необходимо заметить, что общее время выполнения запроса можно снизить, вводя дополнительные индексы в источниках, однако рассмотрение данного вопроса выходит за рамки доклада.

4. Заключение

Доклад посвящен краткому изложению результатов проекта BizQuery, выполняемого группой MODIS ИСП РАН. В состав группы входят К.В. Антипин, М.В. Гринев, С.Д. Кузнецов, П.О. Плешачков, Л.Г. Новак, М.П. Рекуц, А.В. Фомичев, Д.Р. Ширяев.

В докладе была представлена архитектура системы виртуальной интеграции данных BizQuery, основанной на модели данных XML/Xquery. Система позволяет обращаться к данным как в терминах XML, так и в терминах UML. Были обсуждены разработанные средства построения отображения глобальной схемы на локальные схемы источников. Была рассмотрена роль декларативных языков запросов UQL и XQuery в системе BizQuery. Предложены средства для автоматического построения пользовательского интерфейса по описанию модели интегрируемых данных в виде диаграммы классов UML. Наконец, были продемонстрированы некоторые результаты тестовых испытаний системы.

Литература

Максим Гринев
ИСП РАН, ф-т ВМиК МГУ
grinev@ispras.ru