Инструментальное средство для трансляции иерархических документов в реляционные базы данных

Вашенков О.Е.

1

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

И ТЕХНОЛОГИИ

ИНСТРУМЕНТАЛЬНОЕ СРЕДСТВО ДЛЯ ТРАНСЛЯЦИИ ИЕРАРХИЧЕСКИХ ДОКУМЕНТОВ В РЕЛЯЦИОННЫЕ БАЗЫ

ДАННЫХ

O.E. Вашенков

Научный руководитель - кандидат технических наук, доцент A.B. Лямин

В работе рассматривается метод трансляции иерархических документов XML в реляционные базы данных. Суть метода - в разработке специальных правил транслирования для установки соответствия между иерархическим документом и реляционной структурой.

Данные, представленные в иерархическом формате с XML-разметкой (extensible Markup Language - расширяемый язык разметки), удобны для прочтения человеком и для машинной обработки. Существует множество средств для обработки и преобразования таких данных, например, язык преобразований XSL (extensible Stylesheet Language - расширяемый язык таблиц стилей) [1, 2]. Однако в основном такие средства позволяют преобразовать документы в удобный для прочтения человеком вид.

Хранение данных в базе данных (БД) предполагает иную структуру - реляционную. Стандартные средства для обработки XML-документов не способны самостоятельно транслировать произвольные документы в реляционные структуры. В данной работе рассматривается вариант, когда данные в XML-документе распределяются по таблицам базы данных, а не хранятся в виде документов XML в отдельных ячейках таблиц. Оба подхода описаны в главе 27 книги [3]. Развитие языка SQL (Structured Query Language - структурированный язык запросов) для поддержки XML рассмотрено в работе [4]. Языки запросов, основанные на XML, представлены в работе [5]. Недостатки совместного использования реляционных и иерархических структур описаны в главе 25 книги [3] ив работе [6]. Третий подход с использованием XML-ориентированных баз данных в данной статье не рассматривается. Решение, когда документ хранится как отдельный атрибут в кортеже, предложено компанией Oracle в системе управления базами данных (СУБД) Oracle 9. Соответствующий атрибут имеет тип данных XMLTYPE. В языке SQL этой СУБД представлены средства для выборки данных из XML-документов по выражениям XPath (XML Path Language - язык для поиска фрагментов в XML-документах) [7, 8]. В книге [9] приводится описание работы с полями типа XMLTYPE в СУБД Oracle 9. Детальное описание подхода компании IBM к решению данной проблемы при работе с DB2 описано в [10]. Наш подход не требует усложнения языка запросов к базе данных, накладываются только некоторые ограничения на XML-документы и структуру БД для корректного функционирования правил транслирования. На уровне базы данных можно работать со стандартным языком запросов SQL.

Для реализации такого подхода были поставлены следующие задачи:

1. разработка набора правил для отображения иерархических XML-документов в реляционную СУБД;

2. разработка требований для XML-документов;

3. разработка требований к структуре базы данных;

Введение

4. разработка программного обеспечения для прямой и обратной трансляции иерархических документов на основе разработанных DTD-определений (Document Type Definition - определение типа документа) и структуры БД, отвечающей разработанным правилам.

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

Трансляция данных

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

Элементы электронных учебно-методических комплексов (УМК) системы дистанционного обучения (ДО) СПбГУ ИТМО, представленные XML-документами, описывают множество различных учебных документов: учебные планы, дисциплины, семестровые курсы и сами учебные элементы. К последним относятся электронные конспекты, тесты, виртуальные лабораторные работы, практикумы и информационные ресурсы. Документы, используемые для описания этих элементов, имеют сложную иерархическую структуру, допускающую изменения в ходе всего цикла разработки системы ДО. Поэтому от системы трансляции требовалась гибкость и универсальность.

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

Импорт данных

В процессе импорта требуется определить таблицы текущей схемы базы данных и их поля. Этой задачей занимается модуль интроспекции базы данных. Определение таблиц для внесения данных определяется по названиям элементов XML-документа. Элемент, которому сопоставлена таблица в базе данных, подлежит внесению. Атрибуты элементов представляют поля таблиц, названия которых совпадают с текущим или верхним по иерархии элементом. Таким образом, реализовано правило «всплытия» атрибутов, когда атрибуты, не сопоставленные таблице текущего элемента, вносятся в таблицу верхнего по иерархии элемента. Существует отдельное правило внесения элемента Data. Этот элемент представляет текстовое поле размерностью до 4000 символов и интерпретируется как поле таблицы текущего или верхнего по иерархии элемента.

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

Реляционная структура представлена на рис. 1.

Program comment

ID ProgramName ID Data Program

Рис. 1. Структурабазыданных

В этом случае таблицам будут сопоставлены элементы Program и Comment. Специальный элемент Data представляет текстовые данные в таблице Comment. Атрибут ProgramName из элемента Comment «всплывает» и заносится в поле таблицы Program. Поле Program таблицы Comment является внешним ключом для связи с таблице Program. Для корректного заполнения этого поля в DTD-определении исходного документа следует использовать атрибут с именем Program и спецификатором #FIXED "ID".

<!ELEMENT Program (Head)> <!ATTLIST Program

ID CDATA #REQUIRED

>

<!ELEMENT Head (Comment)> <!ELEMENT Comment (Data?)> <!ATTLIST Comment ProgramName CDATA #REQUIRED

Program CDATA #FIXED "ID"

>

<!ELEMENT Data (#PCDATA)>

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

<!ELEMENT FrameIndex (...)> <!ATTLIST FrameIndex FrameID CDATA #REQUIRED Weight CDATA #REQUIRED

IsKey CDATA #FIXED "Yes"

>

Дополнительный атрибут IsKey не допускает загрузки одинаковых записей в таблицу Framelndex. Проверка происходит на основе полей-атрибутов FramelD и Weight.

Еще одной особенностью является внесение внешних файлов, ссылки на которые указаны в XML-документах. Для организации ссылки в элементе определен атрибут Src, в базе данных ему сопоставляется текстовое поле Src для имени файла и поле типа BLOB или CLOB с названием Cnt для хранения содержания.

При внесении текстовых данных в поля Data или Cnt в них могут содержаться ссылки на внешние файлы, например в документах HTML (Hypertext Markup Language - язык разметки гипертекста). Для таких полей среда трансляции запоминает путь к данным (таблица и имя поля) для преобразования ссылок. Процесс преобразования ссылок запускается после внесения всех данных, а логика преобразования реализована на стороне базы данных в виде пакета хранимых процедур. Среда трансляции для каждой записи в подготовленном списке таблиц и полей вызывает хранимую процедуру для преобразования ссылок. Пути к реальным файлам преобразуются в запросы протокола HTTP (HyperText Transfer Protocol - протокол передачи гипертекста) на получение вложений. Процесс преобразования схематично представлен на рис. 2.

Среда трансляции

список полей для преобразования ссылок

№ таблица название_поля Идентификатор

1 TestFrame Data 1

V

Вызов хранимой процедуры преобразования ссылок

Входные параметры:

- название таблицы

- название поля

- идентификатор

restFrame. Data:

< img src="l. jpg ' >

"таблица"_Attach Attach

ID Attach —^ ID src

Поиск всех включении src в тексте и замена на команду получения вложения по протоколу http

TestFrame.Data:

<img

src= "distribut edCDEPR U 7 e=G£TA TTACH&A TT_ID=1 ' >

Рис. 2. Преобразование ссылок

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

Организация связей

Рассмотрим процесс преобразования иерархических данных к реляционным данным с соблюдением реляционных связей.

Существует два способа организации связи «многие к одному». Первый реализуется с помощью атрибутов-ссылок, т.е. атрибутов, названия которых совпадают с названиями таблиц. В основном такой подход используется для ссылки на таблицы-словари. Поиск в таблице-словаре происходит по значению атрибута, которое, после поиска, заменяется на идентификатор записи в таблице-словаре. Для каждой таблицы определены поля, по которым происходит поиск, и поля-идентификаторы. Эти определения хранятся в самой базе данных в отдельной таблице и дополняют метаданные, предоставляемые драйвером СУБД.

Рассмотрим пример организации связи «многие к одному» для таблиц-словарей. Предположим, элементу поставлена в соответствие таблица в базе данных.

Таблица TestFrame содержит поле Language, являющееся внешним ключом на таблицу Language. Таблица Language - словарь со списком доступных языков.

Среда трансляции проверит наличие записи в таблице Language по значению, представленному в атрибуте, и в поле TestFrame.Language будет занесен идентификатор записи. Процесс уточнения идентификатора записи представлен на рис. 3.

Рис. 3. Организация связи «многие к одному»

Второй способ используется при организации связи «многие к одному» по составному ключу. В этом случае используются вложенные элементы в иерархическом документе. Составным ключом служит набор атрибутов вложенного элемента, таблицей-словарем - соответствующая по названию таблица базы данных. Для предотвращения импорта данных в таблицы-словари используются служебные атрибуты ¡БКеу в ВТО-определениях. Альтернатива этого способа для организации связи между элементами на различных уровнях иерархии описана ниже.

Связь «многие ко многим» организуется также за счет использования иерархии: если один элемент вложен в другой в ХМЬ-документе и существует таблица связи с

названием «Элемент 1_Элемент2», то после внесения записей в две таблицы идентификаторы заносятся в таблицу связи.

Пример реализации связи «многие ко многим» показан ниже.

<!ELEMENT TestFrame(..Data, Attach*,.. .)>

<!ATTLIST TestFrame

>

<!ELEMENT Attach>

<!ATTLIST Attach

Src CDATA #REQUIRED

>

</TestFrame>

Элемент TestFrame является контейнером для вопроса, вариантов ответа и вложений в системе тестирования знаний. Вложения представлены элементами Attach.

В терминах реляционной СУБД кратность отношений TestFrame и Attach - «многие ко многим». Данные документа соответствуют реляционной структуре, представленной на рис. 4.

Рис. 4. Организация связи «многие ко многим»

Для организации связи между двумя элементами, каждый из которых представляет запись в таблице, т.е. не является ссылкой на данные в таблице-словаре, используются служебные атрибуты. Когда один элемент вложен в другой, в ВТО-определении элемента указывается служебный атрибут, название которого совпадает с названием связанного элемента. Далее рассмотрим пример реализации связи «многие к одному». Исходному ХМЬ-документу соответствует ВТО-определение:

<!ЕЬЕМЕЖ TextBookUnit(PageIndex*)>

<!ЕЬЕМЕЖ PageIndex(TextBookPage)>

<!АТТЫБТ PageIndex ... >

<!ЕЬЕМЕЖ TextBookPage>

<!АТТЫБТ TextBookPage

TextBookUnit СВАТА #Б1ХЕВ "ГО"

PageIndex СВАТА #Б1ХЕВ "ГО"

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

>

Исходный документ:

<ТехШоокШ£> <Ра§е1пёех ...> <Тех1БоокРа§е .../> </Ра§е1пёех> </ТехШсоШпй>

Элементы Тех1ВоокЦш1 соответствуют пунктам оглавления электронных учебников. Ра§е1пёех - элемент, которому соответствует таблица индексирования страниц электронных учебников. Тех1БоокРа§е - контейнер для данных конкретной страницы электронного учебника. Таким образом организована связь «многие к одному» для элементов, расположенных на разных уровнях иерархии.

В структуре реляционной СУБД отношение Тех1БоокРа§е связано с отношениями Ра§е1пёех и Тех1Воокиш! связью «многие к одному». Данные документа будут преобразованы в данные табличного пространства, представленного на рис. 5.

Рис. 5. Связь элементов на разных уровнях иерархии Экспорт данных

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

Рассмотрим табличное пространство, представленное на рис. 6.

Рис. 6. Табличное пространство со связью типа «многие ко многим»

Требуется выполнить экспорт из таблиц TestFrame и Attach, итоговый документ XML может выглядеть следующим образом:

<?xml version="1.0" encoding="Windows-1251"?> <TestFrames>

При этом название корневого элемента TestFrames и список таблиц для экспорта указывает пользователь.

Практическая реализация

Новые технологии в области разработки программного обеспечения, такие как XML и Java, позволили разработать и реализовать механизм трансляции. Язык Java позволил реализовать кросс-платформенную оболочку для разбора и проверки XML-документов, сбора метаданных БД, преобразования документов в структуру БД и обратно. Уменьшение связанности со структурой документов обеспечивается при использовании XML-формата. При работе с СУБД оболочка динамически собирает метаин-формацию о структуре. Статически описаны только правила трансляции иерархических документов XML и операторы языка SQL, информация о таблицах и полях собирается на основе названий элементов XML-документа, служебных таблиц-словарей и метаданных, предоставленных JDBC-драйвером базы данных (JDBC, Java Data Base Connectivity - общий модуль соединения с базами данных для Java). Корректность составления XML-документов гарантируется DTD-определениями.

Слабая связь с конкретной базой данных обеспечивается за счет интерфейса JDBC и разработанного драйвера базы данных, задача которого - выполнение базовых операций языка DML (Data Manipulation Language - язык манипулирования данными).

От JDBC-драйвера конкретной СУБД требуется обеспечение доступа к метаинформа-ции, выполнение SQL-инструкций и обеспечение работы с LOB-объектами (Large Object - поле в базе данных без явного ограничения размера для размещения данных большого объема).

Динамическое решение является альтернативой системам со статическим форматом хранения ресурсов, структурой БД и кодом импорта/экспорта. Динамический метод позволяет избежать следующих проблем:

1. изменение структуры БД или документов приводит к необходимости изменения кода транслятора;

2. написание модуля обратной трансляции - это отдельная задача, требующая знания формата документов и структуры БД;

3. описание связей между данными при статической организации осложняется ограничениями в реализации ПО.

При использовании динамического метода наиболее сложным моментом реализации становится модуль обработки исключений, возникающих во время операций трансляции. На этапе проверки XML-документа подробные сообщения об ошибках доступны через средства Java для работы с XML. При загрузке же для вывода доступны только системные сообщения СУБД. «Незнание» системы трансляции структуры документа осложняет процесс. Однако разработанный модуль обработки ошибок позволяет пользователю определить путь к элементу, при трансляции которого произошло исключение, и системное сообщение, что упрощает поиск ошибки. А СУБД, например Oracle, позволяет установить системные сообщения для конкретных ошибок, связанных с нарушением целостности данных.

В настоящий момент программа, реализующая алгоритмы трансляции, используется в системе дистанционного обучения СПбГУ ИТМО. Как показывает практика, разработанные методы и правила позволяют менять структуру документов и базы данных без изменения кода программы, а программное средство позволяет полностью автоматизировать заполнение базы данных.

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

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

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

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

Заключение

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

Литература

1. Валиков А. Технология XSLT. СПб: БХВ-Петербург, 2002. 544 с.

2. http://www.w3.org/TR/1999/REC-xslt-19991116 - нормативный документ спецификации XSLT.

3. Дейт К.Дж. Введение в системы баз данных. / 8-е издание.: пер. с англ. М.: Издательский дом «Вильяме», 2005. 1328 с.

4. International Organization for Standardization (ISO). «XML-Related Specifications (SQL/XML) Working Draft», Document ISO/IEC JTC1/SC32/WG3:DRS-020. - August 2002.

5. Bonifati A., Ceri. Corporative Analysis of Five XML Query Languages // ACM SIGMOD Record. March 2000. 29, №1.

6. Bosak J., Bray T. XML and the Second-Generation Web. // http://www.sciam.com May 1999.

7. Lehmann M. From XML to Storage and Back. // Oracle Magazine March 2003. http: //www. oracle. com/technology/oramag/oracle/03 -mar/index. html

8. Dillon S. XML to Relational: Bridging the Gap. // Oracle Magazine September 2005. http://www.oracle.com/technology/oramag/oracle/05-sep/index. html

9. Scardina M., Chang B., Wang J. Oracle 10g XML & SQL: Design, Build & Manage XML Applications in Java, C, C++ & PL/SQL. // Osborne, 2004. 600 p.

10. Steegmans B., Bourret R., Guyennet O., Kulkarni S., Priestly S., Cline O., Sylenko V., Wahli U. XML for DB2 Information Integration. 2004. http://www.redbooks.ibm.com/redbooks.nsf/redbooks

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Вашенков О. Е.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Вашенков О. Е.

Текст научной работы на тему «Инструментальное средство для трансляции иерархических документов в реляционные базы данных»