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

Размещено на http://www.allbest.ru/

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

Литвиненко Александр Николаевич, кандидат технических наук, доцент кафедры информатики и вычислительной электроники,

Ширшин Иван Сергеевич, аспирант механико-математического факультета Южного федерального университета

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

Из-за все возрастающей важности XML и систем управления баз данных (далее СУБД), их интеграция с учетом хранения, получения и обновления содержимого крайне необходима [2, Bourret R.].

В зависимости от рассматриваемой СУБД, виды интеграции можно классифицировать по 4-м разным подходам [7, Kappel G.]. Первый вариант, специализированные СУБД, созданы для хранения, получения и обновления XML документов. Примерами могут служить исследовательские прототипы Rufus и Lore или коммерческие системы, такие как eXcelon и Tamino [2, Bourret R.]. Второй вариант, объектно-ориентированные СУБД, из-за своих богатых возможностей в моделировании данных прекрасно приспособлены для хранения документов с гипертекстом. Однако, они, также как и специализированные СУБД, недостаточно широко распространены и недостаточно развиты для эффективной обработки данных в больших масштабах. Третьи, объектно-реляционные СУБД могут также подойти для построения соответствия с и между XML документами, так как структура наследования объектно-реляционной модели хорошо работает с моделью XML документа. Четвертой, наиболее перспективной альтернативой для хранения XML документов являются реляционные СУБД [5, Florescu D.]. Такая интеграция предоставит несколько преимуществ, таких как:

- использование уже развитой технологии;

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

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

В зависимости от типа хранения информации внутри реляционной базы данных (далее РДБ), существуют три основных варианта.

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

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

Третий подход в сопоставлении структуры XML документов с соответствующей реляционной схемой, когда XML документы хранятся согласно этому сопоставлению [7, Kappel G.].

Только последний из рассмотренных вариантов позволяет действительно использовать возможности реляционных СУБД, таких как механизмы запросов, оптимизации, контроля целостности и так далее. Несмотря на все преимущества использования сопоставления, существует проблема - при определении соответствия XML DTD и реляционной схемы, необходимо учитывать, что существуют фундаментальные отличия между предоставляемыми XML и РСУБД концептами, которые нужно учитывать при конкретном сопоставлении. Эти отличия включают в себя проблемы структурирования, типизации и идентификации, связи и порядка хранимых элементов. И даже если структура XML документа и реляционная схема, с которой XML документ должен быть сопоставлен, описывают одно и то же, то их дизайн, скорее всего, будет различаться. Причиной, например, могут быть разные цели при дизайне [4, Fernandez M.].

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

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

- использование того же синтакса XML;

- поддержка множества типов данных;

- большая гибкость в задании ограничений.

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

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

- атрибуты не могут содержать несколько значений;

- они не могут описывать структуры;

- наконец, их сложно расширять в случае будущих изменений.

Однако, пользователь может поступить иначе без нарушения правил XML документов.

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

1. Для каждого поля его тип данных может быть использован для описания содержимого типа элемента в XML схеме.

<ElementType name=”distance” dt:type=”float”>

<ElementType name=”birthdate” dt:type=”date”>

приложение реляционный база документ

2. Атрибут порядкового номера для каждого элемента может быть сгенерирован автоматически согласно последовательности набора данных. Пользователь может также задать явный порядок дочерних тэгов элемента result.

3. Метаданные о возможности поля принимать null значения могут быть использованы для описания минимального и максимального числа появления тегов каждого элемента. Например, если поле distance может иметь null значение, то его определим следующим образом:

<ElementType name=”distance” minoccurs=”0” maxoccurs=”1”>

Если же поле, наоборот, не допускает null значения, то

<ElementType name=”distance” minoccurs=”1” maxoccurs=”1”>

4. Для задания необходимости наличия поля в выдаваемом документе можно также использовать соответствующие метаданные:

<ElementType name=”distance” required=”yes”>

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

<ElementType name=”dependent” minoccurs=”0” maxoccurs=”5”>

6. Метаданные о ключевых полях применяются для задания типа данных соответствующего элемента (ID объекта). Аналогично можно использовать информацию о полях внешнего ключа и задать тип данных элементов IDREF.

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

8. Для поля, представленного в виде атрибута, а не элемента, мы можем поместить метаданные о его значении «по умолчанию» в его описании (в XML схеме такие значения могут быть только у атрибутов, не у элементов)

<attribute name=”state” default=”running”>

9. Определение атрибута в XML схеме позволяет задать набор принимаемых им значений:

<attribute name=”state” dt:type=”enumeration”

Dt:values=”running cycling swimming”/>

10. Пользователь также может автоматически группировать элементы, создавая добавочный родительский элемент. Например, столбцы city, street, zipcode в наборе данных могут быть автоматически сгруппированы в элемент address.

<address>

<city>…</city>

<street>…</ street >

< zipcode >…</ zipcode >

</address>

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

<emp>

<name>…</name>

<age>…</age>

<dept>1</dept> //FK field

…

<emp>

Предыдущий документ может быть аналогичен следующей структуре:

<emp>

<name>…</name>

<age>…</age>

<dept>

<name>…</name>

<Location>…</Location>

….

</dept>

….

<emp>

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

<result>

<row1>

<name>john</name>

<subject>math</subject>

<points>90</points>

</row1>

<row2>

<name>john</name>

<subject>physics</subject>

<points>95</points>

</row2>

<row3>

<name>john</name>

<subject>DB</subject>

<points>97</points>

</row3>

</result>

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

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

Литература

1. Abiteboul, S., Buneman, P., Suciu, D.: Data on the Web: From Relations to Semistructured Data and XML. Morgan Kaufmann Publishers, 2005.

2. Bourret, R., Bornhvцd, C., Buchmann, A.P.: A Generic Load/Extract Utility for Data Transfer Between XML Documents and Relational Databases. 2nd Int. Workshop on Advanced Issues of EC and Web-based Information Systems (WECWIS), San Jose, California, June, 2000.

3. Deutsch, A., Fernandez, M., Suciu, D.: Storing Semi structured Data in Relations. Workshop on Query Processing for Semi structured Data and Non-Standard Data Formats, Jerusalem, Jan., 1999.

4. Fernandez, M., Tan, W-C., Suciu, D.: SilkRoute: Trading between Relations and XML. 9thInt. World Wide Web Conf. (WWW), Amsterdam, May, 2000.

5. Florescu, D., Levy, A., Mendelzon, A.: Database Techniques for the World Wide Web: A Survey. ACM SIGMOD Record, Vol. 27, No. 3, September, 1998.

6. Kappel, G., Kapsammer, E., Rausch-Schott, S., Retschitzegger, W.: X-Ray - Towards Integrating XML and Relational Database Systems. Proc. Of the 19th Int. Conf. on Conceptual Modeling (ER), LNCS 1920, Springer, Salt Lake City, USA, Oct.,2000 .

7. Kappel, G., Kapsammer, E., Retschitzegger, W.: Architectural Issues for Integrating XML and Relational Database Systems - The X-Ray Approach. The XML Technologies and Software Engineering Workshop (XSE 2001) of the 23th Int. Conf. On Software Engineering, Toronto, Canada, May 2001.

8. Lee, D., Chu, W. W.: Constraints-preserving Transformation from XML Document Type Definition to Relational Schema. Proc. of the 19 Th Int. Conf. on Conceptual Modeling (ER), LNCS 1920, Springer, Salt Lake City, USA, Oct., 2000.

9. Schmidt, A. R., Kersten, M. L., Windhouwer, M. A., Waas, F.: Efficient Relational Storage and Retrieval of XML Documents. Workshop on the Web and Databases (WebDB), Dallas, May, 2006.

10. World Wide Web Consortium (W3C): XML 1.0 Specification, http://www.w3.org/TR/2000/REC-xml.

Размещено на Allbest.ru