Главная » SQL, Базы данных » ПРИМЕНЕНИЕ ЯЗЫКА XML В БАЗАХ ДАННЫХ

0

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

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

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

1.    Документ может быть разделен (это— технический термин!), и разные его фраг менты представлены в виде значений различных атрибутов различных кортежей различных отношений.

2.    Документ может быть сохранен не в обычной базе данных, а скорее "собственно в базе данных XML" (т.е. в такой базе данных, которая вместо отношений содержит документы XML как таковые).

Рассмотрим каждый из этих вариантов по очереди.

Хранение документов в виде значений атрибута

Такой подход кратко упоминался в подразделе "Разработка языка XML" раздела 27.3, где была указана возможность дополнения переменной отношения деталей Р для включения атрибутов DRAWING и DESCRIPTION. По сути, такую идею можно реализовать, как описано ниже.

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

20   По-видимому, исключением следует считать "flower power" ("всемогущее выражение  FLWOR")?

(Автор приносит свои извинения, поскольку он не мог удержаться от соблазна привести этот каламбур.)

Примечание. Как было показано выше, язык XML как таковой является довольно многословным; любой документ XML вполне может в пять или десять раз превышать по объему представленные в нем ^отформатированные данные, поэтому обработка таких документов в исходной форме иногда становится чрезвычайно неэффективной. Таким образом, может оказаться целесообразной организация хранения подобных документов в некоторой сжатой форме (возможно, в виде                                             данных, подвергнутых синтаксическому анализу). Но, безусловно, такие сообра                                           жения не имеют никакого отношения к рассматриваемой модели.

■     Кортежи, содержащие значения XMLDOC, можно вставлять и удалять с использо ванием обычных реляционных операторов INSERT И DELETE, а значения XMLDOC, содержащиеся в таких кортежах, полностью заменять с применением обычного реляционного оператора UPDATE. Кроме того, безусловно, значения XMLDOC могут

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

■     Как и все типы, тип XMLDOC должен иметь множество связанных с ним операто ров. Рассматриваемые операторы предположительно должны предоставлять возможность выборки и обновления атрибутов со значениями в виде XMLDOC на более низком уровне детализации, обеспечивая (например) доступ к отдельным элементам или атрибутам XML. В случае выборки такие операторы, по-видимому, должны быть очень похожими на операторы, применяемые в языке XQuery; они могут даже вызываться с помощью "замаскированных" вызовов выражений XQuery, хотя встроенная (непосредственная) поддержка должна быть более дружественной

по отношению к пользователю. Но должны также поддерживаться операторы обновления.

■     Необходимо также предусмотреть операторы для проверки того, что данное кон кретное значение XMLDOC соответствует некоторому заданному определению DTD или некоторой заданной схеме XML (т.е. является допустимым). (Безусловно, зна чения XMLDOC должны быть формально правильными по определению, но они всё еще могут оказаться недопустимыми.)

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

■     Документы уже существуют.

■     Операции обычно выполняются со всем документом в целом, а не с отдельными его фрагментами.

■     Документы редко обновляются.

■     При выполнении поиска обычно за основу берется небольшое, известное множе ство элементов или атрибутов.

■     Документы должны храниться в неизменном виде для целей аудита.

По существу, этот подход является приемлемым для приложений, которые иногда называют "приложениями, ориентированными на работу с документами" [27.7]. Таковыми являются приложения, в которых в конечном итоге  рассматриваемые документы в основном предназначены для использования людьми и состоят главным образом из текста на естественном языке.

Принцип "разделяй и публикуй"

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

Но следует отметить, что при этом в прикладной программе предусмотрена возможность создать документ XML из обычных данных базы, поэтому фактически достигается вторая из первоначально заданных целей! А именно, предоставляется возможность получить результат запроса к обычным данным  (отличным от XML) и преобразовать их в форму XML. Такое преобразование называется публикацией (рассматриваемых данных); таким образом, термин публикация, в том смысле, в каком он применяется в данном контексте, является  противоположным термину разделение, также определенному в этом разделе.  Кстати, следует отметить, что правила преобразования, которыми руководствуются в своих действиях программы при выполнении таких операций разделения и публикации, сами обычно хранятся в форме документов XML.

Между прочим, способность публиковать отличные от XML данные в форме  XML

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

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

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

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

кортежи в отношении не упорядочены. Поэтому, если задан определенный документ D на языке XML, то возможна ситуация, что некоторые свойства документа D (информационные или другие) будут потеряны после разделения и сохранения D в реляционной базе данных. А если это происходит, то нельзя дать гарантии, что при публикации данных в форме XML будет выполнена реконструкция документа D в его точной первоначальной форме. В частности, вполне вероятно, что не будет одинаковой расстановка пробельных символов в оригинальной и (повторно) опубликованной версии D.

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

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

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

■     Операции часто выполняются с отдельными элементами или атрибутами.

■     Операция обновления применяются часто и важно обеспечить высокую произво дительность обновления.

■     В обрабатывающих программах используются существующие реляционные ин терфейсы.

Вообще говоря, подход по принципу "разделяй и публикуй" является наиболее подходящим для таких приложений, которые иногда называют "приложениями, ориентированными на обработку данных" [27.7]. Таковыми являются  приложения, в которых документы содержат (как правило) оперативную информацию, или информацию, предназначенную для поддержки принятия решений, а не текст на естественном языке.

Базы данных XML

Основная причина, по которой в данной главе упоминается этот третий подход, состоит просто в стремлении всесторонне рассмотреть данную тему. В конечном итоге, как показано в главе 3, реляционная модель является необходимой и достаточной для представления вообще любых данных. Невозможно также оспаривать то, что сделаны огромные вложения в исследования и разработку, а также в создание коммерческих продуктов в той области, которую можно в  целом  назвать "реляционной инфраструктурой" (т.е. сделаны огромные усилия по обеспечению поддержки восстановления, организации параллельной работы, защиты и оптимизации, не говоря уже о поддержке целостности, а также по всем другим направлениям, которые рассматривались в этой книге!). Поэтому, по мнению автора, было бы неразумно полностью переключаться на разработку принципиально новой технологии баз данных, притом что нельзя найти каких-либо достаточно убедительных причин для принятия подобного решения, не говоря уже о том, что любая такая технология будет, безусловно, страдать от недостатков, аналогичных тем, которые уже обнаруживаются в технологии иерархических баз данных (см., например, главу 13 работы [1.5] или аннотации к [27.3] и [27.6]).

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

По теме:

  • Комментарии