Именно такая универсальная таблица, как показано в табл. 16.2, требуется для того, чтобы с помощью опции EXPLICIT бьши получены точно такие же результаты, как и при выполнении запроса с опцией AUTO, который рассматривался в предыдущем примере.

На первый взгляд может показаться, что нет особой необходимости использовать опцию EXPLICIT, если ее применение приводит к получению таких же результатов, как и с помощью AUTO. Но в действительности результаты, полученные с помощью опций EXPLICIT и AUTO, совпадают, в частности, лишь в данном конкретном примере, который быя специетьно подготовлен автором для иллюстрации некоторых функциональных отличий нового варианта кода по сравнению с тем вариантом, который рассматривался выиле. Но ниже в данном разделе будет показано, что опция EXPLICIT позволяет реализовать дополнительные функции форматирования, неосуществимые с помощью опции AUTO или RAW (но реализуемые с помощью опции PATH), поэтому текущий пример отнюдь ш лишен смысла.

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

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

Действительные имена столбцов соответствуют специальному формату (который служит также для предоставления дополнительных метаданных).

Данные упорядочены в соответствии с их иерархией.

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

Столбцы Tag и Parent

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

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

Таким образом, если имеются данные, которые выглядят, как показано в табл. 16.3, то первая строка будет связана с элементом верхнего уровня (станет атрибутом самого внешнего элемента или самим элементом), а вторая строка будет связана с элементом, вложенным в элемент верхнего уровня (поскольку значение Parent второй строки, равное 1, согласуется со значением Tag первой строки).

Таблица 16.3. Пример заполнения столбцов Tag и Parent

Соглашение об именовании столбцов

Откровенно говоря, когда я впервые приступил к изучению конструкции EXPLICIT, эта часть, касающаяся именования столбцов, оказалась для меня наиболее сложной из всех. Безусловно, столбцы Tag и Parent имеют вполне определенное назначение (не зря же этим столбцам присвоены собственные имена), а имена остальных столбцов включают несколько фрагментов метаданных, которые соединены друг с другом в виде одной строки. Единственным обозначением, позволяющим определить, где заканчивается один фрагмент метаданных и начинается другой, служит восклицательный знак (!).

Для именования столбцов применяется такой формат: <element name>!<tag>l[<attribute

name>][!{elementhideIDIDREFIDREFSxmlxmltextcdata}]

В качестве фрагмента <element name>, безусловно, применяется именно то, что под этим подразумевается, - имя элемента в коде XML. Для любого конкретного уровня дескрипторов задано такое условие: после того как определен столбец с некоторым именем, все другие столбцы с тем же дескриптором должны иметь то же имя, что и в предьщущем столбце (столбцах), с тем же номером дескриптора. Например, если некоторый столбец уже определен как имеющий имя [МуЕ1 ement! 2 ! MyCol] , то другой столбец может быть назван как [MyElement 12 IMyOtherCol] , но не как [SomeOtherNameI2IMyOtherCol] .

Дескриптор связывает столбец со строками, имеющими совпадающий номер дескриптора. При обработке в СУБД SQL Server универсальной таблицы вначале считывается номер дескриптора, а затем анализируются столбцы с тем же номером дескриптора. Поэтому при обнаружении в СУБД SQL Server строки, приведенной в табл. 16.4, проверяется номер дескриптора и обнаруживается, что он равен 1.

На основании этого СУБД определяет, что должны быть обработаны столбцы с именами Customer 11! CustomerlD и Customer 11! CompanyName, однако не следует обрабатывать столбец Order! 2 1 OrderlD.

Таблица 16.4. Пример формирования строки с данными

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

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

Атрибут является запрещенным. Это означает, что место для атрибута должно оставаться пустым (тем не менее для обозначения того места, где должен находиться атрибут, все равно необходимо применить восклицательный знак). Именно такая ситуации возникает при использовании директивы CDATA.

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

Атрибут все еще является обязательным. Данное условие является истинным для директив elements и xml. В этом случае имя атрибута становится именем полностью нового элемента, который создается в результате применения директивы elements или xml.

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

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

Рассматриваемый запрос приведен ниже (очевидно, что он слишком сложен).

USE AdventureWorks

SELECT 1 as Tag,

NULL as Parent,

e.ContactID as [c11!ContactID],

c.LastName as [clllLastName],

c.FirstName as [clllFirstName],