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

WITH XMLNAMESPACES (http: schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelManuInstructions AS PI)

SELECT pm.ProductModelID,

pmi.Location.value(./©LocationID, int) AS LocationID,

pmi .Location.value(./©LaborHours, decimal(5,2)) AS LaborHours

FROM Production.ProductModel pm

CROSS APPLY pm.Instructions.nodes(/PI:root/PI:Location) AS pmi(Location)

Напоминаем, что все URL должны быть введены в виде одной строки.

Следует отметить, что благодаря использованию метода .nodes одна таблица (ProductModel) по существу преобразуется в две таблицы (в исходную таблицу и таблицу с результатами применения метода .nodes к столбцу Instructions таблицы ProductModel). Рассмотрим сформированные результаты: ProductModellD LocationID LaborHours

(23 row(s) affected)

Вполне очеввдно, что получено несколько строк в расчете на то, что было первоначально единственной строкой в таблице ProductModel. Например, значению идентификатора модели товара ProductModellD, равному 7, соответствует шесть различных экземпляров элемента Location, поэтому было получено шесть строк вместо той единственной строки, которая присутствует в таблице ProductModel.

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

Метод .exist

Метод . exist по своему назначению немного напоминает оператор EXISTS языка SQL. В вызове этого метода используется выражение (в данном случае выражение XQuery, а не выражение SQL) и происходит возврат булева значения, указывающего на то, является ли это выражение истинным или нет. (Еще одним возможным результатом является получение NULL-значения.)

Если бы в рассматриваемом примере применения метода .modify потребовалось сформировать строки, содержащие описания шагов инструкции step, которые включают элементы specs, то достаточно было бы воспользоваться методом . exist:

WITH XMLNAMESPACES (http: schemas .microsoft.com/sqlserver/2004/07/adventure-works/ ProductModelManuInstructions AS PI)

SELECT ProductModellD, Instructions FROM Production.ProductModel

WHERE Instructions.exist(/PI:root/PI:Location/PI:step/PI:specs) = 1

Обратите особое внимание на то, в какой точке применяется проверяемое условие!

В частности, в этом примере были бы показаны строки, в которых по крайней мере один элемент step содержит элемент specs, поскольку не предъявляется обязательное требование, чтобы в каждом элементе step присутствовал элемент specs. Если бы нужно было проверить каждый элемент, то потребовалось бы либо извлекать все элементы из отдельных строк (с использованием метода . nodes), либо применять условие проверки, заданное в выражении XQuery.

Напоминаем также, что все URL должны быть введены в виде одной строки.

Предписание ограничений целостности дополнительно к тому, что регламентируют коллекции схем

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

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

Еще раз следует отметить, что автор был немного удивлен тем, что в версии SQL Seruer 2005 не предусмотрена возможность использовать методы типа данных XML в объявлении CONSTRAINT, а такие объекты, как функции, применять разрешается. Единственное, что я могу сказать по этому поводу, - причины принятия такого решения не совсем очевидны. Остается лишь надеяться на то, что корпорация Microsoft учтет это замечание в будущем выпуске, поскольку указанная недоработка выглядит как существенное упущение, которое не так уж трудно исправить (я согласен с тем, что и в этом случае проще сказать, чем сделать, поскольку вносить изменения в программное обеспечение придется не мне!).

Выборка реляционных данных в формате XML

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

Конструкция FOR XML

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

Еще раз рассмотрим синтаксис оператора SELECT, приведенный в главе 3:

select <column list> [from <source table(s)>] [where <restrictive condition>]

[group by <со1ипш name or expression using a column in the select list> [having <restrictive condition based on the group by results>] [order by <column list>]

[for xml {rawautoexplicitpath}

[, xmldata][, elements][, binary base64]] [option (<query hint>, [, -n])]

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

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