SELECT 2, 1,

р.ProductID,

soh.SalesOrderlD,

soh.SalesOrderlD,

soh.OrderDate FROM Production.Product AS p JOIN Sales.SalesOrderDetail AS sod ON p.ProductID = sod.ProductID JOIN Sales.SalesOrderHeader AS soh

ON sod.SalesOrderlD = soh.SalesOrderlD WHERE soh.OrderDate BETWEEN 2003-03-27 AND 2003-03-31 ORDER BY [Product!1!ProductID], [Order 12!OrderlD!id], [Product!1!OrderList!idrefs] FOR XML EXPLICIT, XMLDATA

Следует отметить, что в приведенном выиле примере немного расширен диапазон обрабатываемых дат, благодаря чему увеличивается количество идентификаторов товаров, относящихся к данному диапазону, что позволяет более наглядно представить связь многие ко многим

Но полученная схема в конечном итоге во многом напоминает схему, которая была получена при использовании директивы idref:

<Schema name= S,chema4 xmlns= urn: schemas -microsof t - com: xml - data xmlns:dt= urn:schemas-microsoft-com:datatypes > <ElementType name= Product content= mixed model= open > <AttributeType name= ProductID dt:type= i4 /> <AttributeType name= OrderList dt:type= idrefs /> <attribute type= ProductID /> <attribute type= OrderList /> </ElementType>

<ElementType name= Order content= mixed model= open > <AttributeType name= OrderlD dt:type= id /> <AttributeType name= OrderDate dt:type= dateTime /> <attribute type= OrderlD /> <attribute type= OrderDate /> </E1ementType > </Schema>

Тем не менее различия между элементами становятся весьма существенными:

<Product xmlns= x-schema:#Schema4 ProductID= 763 OrderList= 49790 49797 > <Order OrderID= 49790 OrderDate= 2003-03-28T00:00:00 /> <Order OrderID= 49797 OrderDate= 2003-03-29T00:00:00 />

</Product>

Таким образом, при использовании директив id, idref и idref s приходится решать очень сложные задачи. Но благодаря этому появляется возможность обеспечить строгий контроль типов выходных данных. Разумеется, в большинстве практических ситуаций нет необходимости добиваться столь высокого уровня контроля и брать на себя все связанные с этим сложности, но бывают и такие обстоятельства, в которых без применения этих трех директив буквально невозможно обойтись.

Директива xml text

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

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

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

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

Все элементы, вложенные в удаляемый элемент, становятся вложенными элементами комбинированного элемента.

Если в директиве xml data указано имя атрибута, то сохранившиеся данные помещаются в элемент с указанным именем. Новый элемент становится дочерним по отношению к элементу, в котором содержитс5Г7иректива.

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

Директива cdata

Сам принцип включения в документ данных с помощью директивы cdata впервые был применен в определениях DTD и в языке SGML. (SGML- это язык разметки, применяемый в индустрии обработки графической информации в течение длительного времени, на основе которого разработаны языки HTML и XML. DTD - это определение типа документа, содержащее описание правия, которым должны соответствовать документы SGML, HTML и XML.) По существу, директива cdata (сокращение от character data) предназначена для включения в документ символьных данных. В синтаксических анализаторах XML данные, содержащиеся в разделах cdata, полностью игнорируются. Проверка данных, находящихся в разделе cdata, не выполняется, поэтому нет необходимости применять для данных какую-либо кодировку, соответствующую требованиям XML, т.е. данные могут быть совершенно произвольными. Еще одним примером применения этой директивы может служить такая ситуация, когда требуется с помощью средств XML передать данные из одного места в другое, но невозможно заранее определить, каковыми являются эти данные (поэтому предугадать, будут ли возникать проблемы при их обработке и передаче или все пройдет успешно).

В качестве иллюстрации применения директивы cdata рассмотрим достаточно простой пример- таблицу Product ion. Document базы данных AdventureWorks. В этой таблице имеется столбец, относящийся к типу данных nvarchar (max). По существу, содержимое этого столбца ничем не регламентировано, поскольку в нем содержатся примечания к данным о служащих. Для преобразования текста, содержащегося в этих примечаниях, в код XML можно применить примерно такой запрос:

SELECT 1 as Tag,

NULL as Parent,

DocumentID as [Document!1DocumentID],

DocumentSummary as [Document 111!cdata]

FROM Production.Document Document WHERE DocumentID BETWEEN 6 AND 8 ORDER BY [Document!l!DocumentID] FOR XML EXPLICIT

Выходные данные этого запроса довольно несложные: <Document DocumentID= 6 >

<1[CDATA[Guidelines and recommendations for lubricating the required components of your Adventure Works Cycles bicycle. Component lubrication is vital to ensuring a smooth and safe ride and should be part of your standard maintenance routine. Details instructions are provided for each bicycle component requiring regular lubrication including the frequency at which oil or grease should be applied. ]]>

</DocumentxDocument DocumentID= 7 ><! [CDATA [It is important that you maintain your bicycle and keep it in good repair. Detailed repair and service guidelines are provided along with instructions for adjusting the tightness of the suspension fork.

]]>

</Document >

<Document DocumentID= 8 >

<![CDATA[Worn or damaged seats can be easily replaced following these simple instructions. Instructions are applicable to these Adventure Works Cycles models: Mountain 100 through Mountain 500. Use only Adventure Works Cycles parts when replacing worn or broken components.

]]>

</Document>

Итак, очевидно, что применение директивы cdata является довольно простым. Опция PATH

в предыдущих разделах рассматривались конструкции, которые в большей степени соответствуют подходу, применяемому в программном обеспечении корпорации Microsoft, а данный раздел посвящен описанию способов обработки данных, главным образом соответствующих подходу, предусмотренному в самом языке XML. Этот подход основан на использовании опции PATH.

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