Название: Базы данных. Концепция баз данных, реляционная модель данных, языки SQL и XML (Токмаков Г. П.)

Жанр: Информационные системы и технологии

Просмотров: 1403


8.2. использование xml с базами данных

 

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

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

– Вывод в формате XML. Данные одной или более строк результата запроса легко представить в виде XML-документа. Поддержка выходных данных в фор-

мате XML означает, что в ответ на SQL-запрос СУБД вместо обычного набора строк и столбцов может генерировать XML-документ.

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

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

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

разуются в формат базы данных.

– Интеграция данных XML. Это более высокий уровень поддержки интегри-

рованного хранения данных в формате XML, суть которого состоит в том, что СУБД

может выполнить синтаксический анализ XML-документа, разделить его на состав- ляющие, и сохранить отдельные элементы в отдельных столбцах. После этого для поиска данных в полученной таблице может использоваться обычный SQL  таким образом реализуется поддержка поиска элементов и XML-документе. В ответ на за- прос СУБД может снова собрать ХМL-документ из хранящихся в таблице состав- ляющих элементов.

 

8.2.1.  Х РАНЕ Н И Е  ДАНН ЫХ  В  ФОРМАТЕ  XML

 

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

Если СУБД на базе SQL поддерживает большие объекты, это означает, что она уже содержит элементарные средства поддержки, хранения и извлечения XML-Документов. Некоторые коммерческие базы данных хранят и извлекают большие текстовые документы при помощи двух типов данных: больших сим- вольных объектов (CLOB) и больших двоичных объектов (BLOB). Во многих ком- мерческих продуктах поддерживаются значения типа BLOB или CLOB объемом до

4  Гбайт,  что  достаточно  для  хранения  подавляющего  большинства  XML-

документов.

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

логии нужно определить таблицу с одним столбцом типа BLOB или CLOB для хра- нения текста документа и несколькими вспомогательными столбцами (стан- дартных типов данных) для хранения атрибутов, идентифицирующих данный документ. Например, если в таблице должны храниться документы с заказами товаров, в дополнение к столбцу типа CLOB для хранения XML-документов можно определить вспомогательные столбцы для хранения номера заказчика, даты за- каза и номера заказа, используя тип данных INTEGER, VARCHAR или DATE. Тогда мож- но будет выполнять поиск документов в таблице заказов по номеру документа, дате заказа или номеру клиента, и для извлечения или хранения XML-документа использовать технологии обработки CLOB-данных.

Преимуществом этого подхода является то, что его относительно просто реализовать. Он поддерживает четкое разделение между операциями SQL (таки-

ми, как обработка запросов) и операциями XML. Недостатком же его является очень низкий уровень интеграции между XML и СУБД. В простейшей реализа- ции XML-документ совершенно прозрачен для СУБД. Последняя ничего не знает о его содержимом. Его нельзя искать по значению одного из его атрибутов или

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

вится не таким уж значительным.

Используемые для обмена данными между приложениями XML-документы,

хранящиеся в файлах или базах данных в столбцах типа CLOB, всегда имеют тек-

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

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

– Document Object model (DOM). DOM-анализаторы преобразуют XML-документ в

иерархическую древовидную структуру. После этого при помощи API DOM про-

грамма может перемещаться по дереву вверх и вниз, следуя иерархии документа. Интерфейс API DOM облегчает программистам доступ к структуре документа и его элементам.

– Simple XPI for XML (SAX). SAX-анализаторы преобразуют XML-документ в по-

следовательность обратных вызовов программы, которые информируют програм-

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

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

DOM-анализатор удобен в тех случаях, когда размер XML-документа относи-

тельно мал; этот анализатор генерирует в оперативной памяти древообразное представление документа, занимающее вдвое больше места, чем исходный до-

кумент.

Анализатор типа SAX позволяет обрабатывать большие документы неболь-

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

 

8.2.2.  В ЫВОД  В  ФОРМАТЕ  XML

 

Одним из самых естественных способов объединения технологий баз дан- ных и XML является использование XML в качестве формата выходных данных SQL-запросов. Результаты запроса имеют структурированный табличный фор- мат, который легко преобразовать в XML-представление. Рассмотрим простой запрос из учебной базы данных:

 

SELECT ID_ORDER, ID_MFR, ID_PRD, COUNT, PRICE_ALL FROM ZAKAZY

WHERE ID_CLN = 12103;

 

ID_ORDER

ID_MFR

ID_PRD

COUNT

PRICE_ALL

312963

ВАЗ

41004

28

$3,276.00

312983

ВАЗ

41004

5

$702.00

313027

ВАЗ

41002

54

$4,104.00

312987

ВАЗ

4100Y

11

$27,500.00

 

Если СУБД получила команду вывести результаты запроса в формате XML,

те же выходные данные могут быть представлены так:

 

SELECT ID_ORDER, ID_MFR, ID_PRD, COUNT, PRICE_ALL FROM ZAKAZY

WHERE ID_CLN = 12103;

 

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

– один корневой элемент <queryResults>;

– четыре вложенных элемента <row>;

– для каждого элемента <row> пять вложенных элементов, расположенных в одном и том же порядке.

Возможность получать результаты запросов в XML-формате бывает очень полезной по следующим причинам.

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

2. Их можно переслать по сети другой системе, и благодаря XML-формату,

содержащему описания элементов, любая получающая система или приложе-

ние интерпретируют результаты запроса одинаково  как четыре строки по пять элементов в каждой.

3. А поскольку выходные данные имеют текстовый формат, то исключается их неправильная интерпретация из-за различий двоичного представления дан- ных в системе-отправителе и системе-получателе.

4. Наконец, если XML-документ передается через HTTP с использованием стандартного протокола Simple Object Access Protocol (SOAP), он может прохо-

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

Однако у выходного формата XML имеется и несколько недостатков. Один их них связан с размером строки данных. В XML-документе строка содержит

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

мени.

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

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

Кроме того, в данном простейшем XML-формате теряется некоторая инфор-

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

 

8.2.3.  В ВОД  В  ФОРМАТЕ  XML

 

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

 

INSERT INTO OFFICY (ID_OFC, CITY, REGION, SALES) VALUES (321, 'Киров', 'Кировская', 835915.00)

 

легко преобразовать в эквивалентную гибридную SQL/XML-инструкцию:

 

INSERT INTO OFFICY (ID_OFC, CITY, REGION, SALES) VALUES (<?xml version="1.0"?>

 

Аналогичным образом выполняется обновление базы данных. Например,

приведенную ниже инструкцию UPDATE

UPDATE OFFICY

SET TARGET = 200000.00, MNGR = 2108

WHERE OFFICE = 23

можно преобразовать в такую гибридную SQL/XML инструкцию:

UPDATE OFFICY

WHERE ID_OFC = 321

 

 

В инструкции DELETE необходимо указать только предложение WHERE, для задания которого используются те же соглашения.

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

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

таксиса SQL/XML пока еще не разработаны.

Хотя в небольшом XML-документе значения для вставки или обновления представляются очень просто, и здесь есть некоторые проблемы. Например,

список столбцов в SQL-инструкции INSERT будет излишним, если в XML-доку- менте наряду со значениями данных, которые необходимо вставить, также со- держатся имена столбцов базы данных, заданные с помощью имен элементов

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

Для программного использования SQL проблема заключается в том, что XML-

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

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

 

8.2.4.  О БМЕН  Д АННЫМИ  В  ФОРМАТЕ  XML

 

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

данных. Обмен данными XML может быть по-настоящему полезен в том случае,

если он более явно поддерживается СУБД.

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

Обратите внимание, что использование предлагаемых СУБД возможностей импорта/экспорта данных таблиц в формате XML не ограничивает их использова-

ние для обмена между базами данных.

 

8.2.5.  И НТЕГРАЦИЯ  ДАНН ЫХ  В  ФОРМАТЕ  XML

 

Хранение XML-документов в базе данных в виде больших объектов очень удобно для определенных типов интеграции SQL/XML. Если XML-документы, на- пример, представляют собой деловые документы текстового типа или же явля- ются текстовыми компонентами Web-страниц, СУБД не обязательно понимать их внутреннюю структуру. Каждый документ может идентифицироваться од- ним или несколькими ключевыми словами или атрибутами, которые можно из- влекать из документа и хранить в обыкновенных столбцах, используемых для поиска данных.

А вот если XML-документ содержит данные в форме набора записей, пред-

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

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

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

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

Проблема возникает при преобразовании XML-документов (которые замеча-

тельно подходят для внешнего представления данных) во внутреннее представ-

ление данных (более удобное для программной обработки), так как внутреннее представление не является уникальным для различных систем управления ба- зами данных.

Та же проблема существует и в языке Java, когда XML-документ преобразу-

ется в набор экземпляров классов Java для внутренней обработки.

Процесс декомпозиции XML-документа на составляющие элементы и атри-

буты называется демаршалингом. А процесс повторной сборки текста XML-доку-

мента из составляющих элементов и атрибутов носит название маршалинга.

Для очень простого XML-документа процесс маршалинга и демаршалинга несложен, и коммерческие СУБД развиваются в направлении его поддержки.

Давайте еще раз рассмотрим простой документ, содержащий заказ товаров, показанный на Ошибка! Источник ссылки не найден.. Его элементы можно поставить в соответствие (один к одному) отдельным столбцам таблицы ZAKAZY. В простейшем случае имена элементов или атрибутов будут идентичны именам соответствующих столбцов.

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

Однако многие реальные XML-документы имеют несколько более сложную структуру и их нельзя преобразовать в отдельные строки таблицы. На Рис. 8.2.

показан такой же заказ, как на Ошибка! Источник ссылки не найден., но с несколько расширенной структурой: этот заказ содержит не одну, а несколько позиций заказываемых товаров. Как же выполнить демаршалинг этого доку-

мента для помещения его в нашу учебную базу данных?

 

 

Рис. 8.2.          XML-документ, содержащий расширенный заказ товаров

 

Можно поместить каждую строку заказа в отдельную строку таблицы ZA‐ KAZY. (Для этого примера мы проигнорируем требования уникальности номе- ров-заказов в таблице ZAKAZY, связанное с тем, что номер заказа является пер-

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

Кроме того, это усложнит маршалинг данных для восстановления докумен-

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

Приведенный пример с многострочным заказом затрагивает лишь самые по-

 

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

 

 

 

 

 

id_cln

id_order

date_order

id_slzh

12119

312650

2009-09-09

2112

12117

312961

2009-12-17

2106

 

12125

312767

2009-11-24

2122

 

 

id_mfr

id_prd

count

price_all

id_order

ВАЗ

41003

207

3519.00

312650

УАЗ

2444L

7

31500.00

312961

Утес

775C

5

7125.00

312650

УПЗ

41003

1

652.00

312961

ПМЗ

XK48A

37

6549.00

312767

 

 

ship

bill

1

red

Net432

2

ground

Net30

3

yellow

Net555

 

 

 

 
Рис. 8.3.          Маршалинг и демаршалинг XML-документа

 

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

XML-элемент более высокого уровня (такой как адрес, состоящий из элементов номера дома, улицы, города, области, страны и индекса) может сопоставляться одному столбцу абстрактного типа ADDRESS с собственной внутренней иерархией. Однако при этом усложняется структура базы данных, и для упрощения преоб- разования между базой данных и XML приходится поступиться гибкостью струк- туры строки/столбцы.

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