Главная » SQL, Базы данных » МАНИПУЛИРОВАНИЕ ДАННЫМИ XML

0

Теперь перейдем к вопросу о языках манипулирования данными XML. Было предложено много таких языков, но стандартным, по-видимому, должен стать XQuery [27.29]. Как будет вскоре показано, язык XQuery (работа над которым ко  времени написания данной книги еще не была закончена) основан на  нескольких более ранних языках, включая, в частности, XPath [27.27]; в действительности, язык XQuery полностью включает в себя XPath.

Язык XQuery обеспечивает только чтение. Обновление в случае необходимости должно выполняться либо с применением модели DOM [27.24], либо с помощью некоторых специализированных средств (предоставляемых отдельными  поставщиками), но, безусловно, оба этих подхода характеризуются определенными недостатками, как указано ниже.

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

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

В настоящее время ведется разработка языка, не зависящего от конкретных поставщиков, который называется XUpdate [27.30], но ко времени написания данной книги эти работы еще находились на предварительном этапе, поэтому рассматривать здесь этот

язык было бы еще слишком рано. В связи с этим ограничимся описанием в данном разделе только языка XQuery (и XPath).

Язык XQuery произошел от ранее созданного языка Quilt [27.9], на который в свою очередь оказали влияние SQL, OQL и некоторые более старые языки из семейства языков XML, в том числе XQL, XML-QL и Lorel (описание языка OQL приведено в [25.11], а информация, касающаяся XQL, XML-QL и Lorel, приведена в [27.5] и [25.18]). Отметим, что в целом язык XQuery является весьма развитым и сложным, поэтому в книге такого характера, как данная, нет смысла пытаться привести его исчерпывающее описание. В связи с этим здесь просто показан ряд примеров с комментариями, которых, по мнению автора, должно быть достаточно, чтобы получить общее представление о возможностях, области применения и характере этого языка. Но прежде чем приступить к изучению этих примеров, необходимо отметить, что язык XQuery в действительности вообще не оперирует с документами XML как таковыми! Причины этого перечислены ниже.

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

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

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

Поэтому язык XQuery определен как язык, предназначенный для функционирования не в терминах документов XML как таковых, а скорее в терминах документов XML, которые преобразованы в некоторую абстрактную форму (полученную в результате обработки документа синтаксическим анализатором). Абстрактная форма любого конкретного документа XML называется "экземпляром модели данных XQuery" [27.29]; ее можно рассматривать как инфонабор18 (т.е. как структурную иерархию), аналогичный приведенному на рис. 27.2 (в подразделе "Структура документа XML" раздела 27.3). Поэтому заслуживает особого внимания то, что результат запроса, выраженного на языке XQuery, представляет собой инфонабор, а не документ XML. В [27.29] об этом сказано так: "В настоящее время вопрос о том, как обеспечить [обратное] преобразование экземпляра модели данных в документ XML, остается  открытым".  В действительности, результат вычисления выражения XQuery может даже оказаться не строго определенным инфонабором, поскольку (как будет показано ниже) он может даже не быть формально правильным.

Язык XPath

В языке XQuery широко используются характерные выражения — обозначения пути (path expression) языка XPath, поэтому начнем с краткого описания таких  выражений. Концептуально эти выражения сохраняют строгое подобие обозначениям пути, которые описаны в главах 25 и 26. А именно, обозначением пути в языке Xpath является такое выражение, которое позволяет, начиная от некоторого указанного исходного узла (или узлов)

18   Точнее, эта абстрактная форма состоит из дополненного инфонабора, называемого  "инфонабором, полученным после проверки по схеме" (Post Schema Validation Infoset — PSVI), который преобразован в форму модели данных XQuery.

в некотором заданном инфонаборе пройти по заданному пути (или путям) в этом инфонаборе, чтобы найти некоторый желаемый целевой узел (или узлы).

Примечание. Термины исходный узел и целевой узел не являются официально принятыми терминами языка XPath.

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

[/ \/  /  ]  step/step / …/ step

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

Ниже приведено несколько простых примеров, основанных на документе  PartsRelation из подраздела "Определения типа документа" раздела 27.4  (напомним, что этот

документ содержит элементы PartTuple с данными о деталях P1, P2 и РЗ):

■     Приведенное ниже выражение возвращает последовательность узлов, соответст вующих этим трем элементам PartTuple.

/PartsRelation/PartTuple

Приведенное ниже выражение возвращает пустую последовательность узлов, поскольку корневой узел не имеет дочерних узловРаrТuр1е. /PartTuple

Примечание. В данном случае корневым узлом является не узел PartsRelation, a скорее узел всего документа (см. описание рис. 27.2 в разделе 27.3). Такое же замечание, безусловно, относится как к предыдущему примеру, так и к следующему.

■     Приведенное ниже выражение возвращает тот же результат, что и выражение из первого примера.

//PartTuple

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

1.  Ось, определяющая направление, в котором должно продолжаться перемещение.

Чаще всего перемещение продолжается в направлении вверх, по оси  родительского узла (parent) или узла-предка (ancestor), вниз, по оси  дочернего узла (child) или узла-потомка (descendant), влево, по оси  предшествующего узла

(preceding) или предшествующего сестринского узла (preceding-sibling), и

вправо, по оси следующего узла (following) или следующего сестринского узла

(fol l o w i ngsi b l i ng).

2.    Выражение для проверки узла, которое определяет тип (типы) узла (узлов), пред ставляющего интерес для поиска.

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

Примечание. Конкретные "родительские" (parent), "дочерние" (child) и  другие оси, перечисленные в первом пункте, не исчерпывают всех возможностей — они указаны просто в качестве иллюстрации. Если не определена ни одна ось, то по умолчанию применяется ось child (т.е. в процессе перемещения происходит переход к дочерним узлам контекстного узла).

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

/PartsRelation/PartTuple[WEIGHT="17.0"]

Пояснение

1.          Первоначальный символ "/" указывает корневой узел (т.е. узел документа) в каче стве контекстного узла для шага, непосредственно следующего за этим символом.

2.          Обозначения пути могут записываться (и обычно записываются) в сокращенной форме. Поэтому в данном примере выражение "PartsRelation" является со кращением  от выражения  "child: : PartsRelation"  (где   "child" —ось,  а "PartsRelation" — выражение для проверки узла). Таким образом, результатом

этого шага является узел PartsRelation — единственный дочерний узел корневого узла.

3.          Аналогичным образом, "PartTuple" — это сокращение от "child: : PartTuple"; выполнение этого шага приводит к получению последовательности из трех узлов PartTuple, которые являются дочерними по отношению к узлу PartsRelation.

4.          Наконец, предикат [WEIGHT="17 .0" ] исключает все узлы PartTuple, кроме уз ла, в котором дочерний элемент WEIGHT имеет значение 17.0.

Примечание. Выражение "WEIGHT" само является сокращением; этот предикат в полной форме имеет следующий вид.

[child::WEIGHT="17.0"]

Поэтому окончательным результатом становится последовательность из двух узлов

PartTuple, соответствующих деталям Р2 и РЗ (в указанном порядке).

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

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

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

По теме:

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