Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Создание интернет-магазина от 350 руб!
Большой выбор шаблонов. Поддержка 24/7. Месяц бесплатно!

 

BizQuery: система вируальной интеграции данных на основе языка XML

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

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. Наконец, были продемонстрированы некоторые результаты тестовых испытаний системы.

Литература

1. A Selection of Papers on Datawarehousing, Computer, Vol. 14, No. 12 (2001)

2. Batini, C., Lenzerini, M., and Navathe, S.: A Comparative Analysis of Methodologies for Database Schema Integration, ACM Computer Surveys 18(4) (1986) 323-364

3. Sheth, A., Larson, J.: Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases, ACM Computing Surveys 22(3) (1990) 183-236

4. Grinev, M., Kuznetsov, S.: UQL: A Query Language on Integrated Data in Terms of UML, Programming and Computer Software, Vol. 28, No. 4 (2002) 189-196

5. Wiederhold, G.: Mediators in the Architecture of Future Information Systems, IEEE Computer 25(3) (1992) 38-49

6. Chawathe, S., Garcia-Molina, H., Hammer J., Ireland, K., Papakonstantinou, Y., Ullman, J., Widom, J.: The TSIMMIS Project: Integration of Heterogeneous Information Sources, IPSJ (1994) 7-18

7. Extensible Markup Language (XML) 1.0, W3C Recommendation, 2nd edition (2000) http://www.w3.org/TR/2000/REC-xml-20001006

8. XSL Transformations (XSLT) 2.0, W3C Working Draft 15 November 2002, http://www.w3.org/TR/2002/WD-xslt20-20021115/

9. XQuery 1.0: An XML Query Language, W3C Working Draft 15 November 2002, http://www.w3.org/TR/2002/WD-xquery-20021115/

10. The Tukwila Data Integration System, University of Washington, http://data.cs.washington.edu/integration/tukwila/

11. Xperanto Project, IBM Almaden Research Center, http://www.almaden.ibm.com/software/dm/Xperanto/index.shtml

12. Unified Modeling Language (UML), Specification Version 1.4, http://www.omg.org/technology/documents/formal/uml.htm

13. XML Metadata Interchange (XMI), Version 1.2 http://www.omg.org/technology/documents/formal/xmi.htm

14. RELAX NG Specification, Committee Specification 3 December 2001, http://www.oasis-open.org/committees/relax-ng/spec-20011203.html

15. Grinev, M., Kuznetsov S.: Towards an Exhaustive Set of Rewriting Rules for XQuery Optimization: BizQuery Experience, 6th East-European Conference on Advances in Databases and Information Systems (ADBIS), LNCS 2435 (2002) 340-345

16. XMark — An XML Benchmark Project, http://www.xml-benchmark.org

17. QuiP. Software AG’s prototype of XQuery, http://developer.softwareag.com/tamino/quip/

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

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...