Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Introduction to XQuery in SQL Server 2005 From Microsoft

Introduction to XQuery in SQL Server 2005 From Microsoft

Ratings: (0)|Views: 912 |Likes:
Published by join lucky

More info:

Published by: join lucky on Jun 06, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Introduction to XQuery in SQL Server 2005
Prasadarao K. VithanalaMicrosoft CorporationJune 2005
This white paper provides an introduction to various features of XQuery implemented inSQL Server 2005 such as the FLWOR statement, operators in XQuery, if-then-else construct, XMLconstructors, built-in XQuery functions, type casting operators, and examples of how to use each of these features. Non-supported features of XQuery in SQL Server 2005 and workarounds aredescribed in this article. It also presents three scenarios where XQuery is useful. (30 printed pages)
XML was developed for use as a document format. However, the additional features of XML, such asextensibility, support for internationalization, the ability to represent both structured and semi-structured data, and easy readability by humans and machines, have rendered XML an immenselypopular platform-independent data representation format. As XML gains wide acceptance, usersapply XML to solve complex business problems such as those involving data integration. There aremany scenarios where it is recommended that information be stored in XML format rather than tostore it in tables and then compose XML messages from the information. For more informationabout these scenarios, see the MSDN articleXML Best Practices for Microsoft SQL Server 2005. Theapplication of XML for storing documents and for representing semi-structured data has led to theevolution of XML as a data storage format that simplifies data management at the server.
This evolution, however, posed a problem—extracting information from the XML data stored inrelational tables as BLOBs required a query language to extract and shape information representedin the XML. Microsoft SQL Server 2000 provided OpenXML which could be used for querying, butwas designed for mapping XML data to relational form and thus could not provide full support forthe XML data model (see Table 1).The relational data model and the XML data model differ in a lot of ways. The following tableoutlines the major differences between the two data models.
Table 1 Differences between the relational and XML data models
FeatureRelational Data ModelXML DataModel
Flat structured dataUses flat tables to store data in a column form.Recommended way to store flat structured data.Useful when it isrequired to preserve thedocument order or when theschema isflexible or unknown.Semi-structured dataIt is difficult to model semi-structured data using relationalmodel.Providesexcellent supportfor representingsemi-structureddata withvariable or evolving schema.Markup dataNot suitable for storing markup data beyond BLOBstorage.Excellent for storing markupdata such asHTML, RTF andso on. Nested or hierarchical data structuresSupports nested data by using multiple tables and linkingthem with foreign keys, but the complexity of queriesrequired for searching nested data stored in relational formincreases when the depth of nesting increases or isunknown.Providesexcellent supportfor expressingnested andhierarchical data.Order of dataNot preserved.Preserved.Input dataHomogeneous.Heterogeneous.Result setHomogeneous.Heterogeneous.
Both the increasing need to deal with more heterogeneously structured data and the necessity of having an implied order are two of the most important reasons why the relational data model isbeing extended to store XML documents natively. In addition, the limitations of the SQL language inhandling semi-structured or markup information resulted in the development of the XQuerylanguage. The XQuery language has been designed from scratch taking into consideration thenature of XML data and the issues involved in processing it.SQL Server 2005 has built-in support for the native storage of XML data using the XML data type.XQuery 1.0 is a language that is being defined by the World Wide Web Consortium (W3C) XMLQuery Working Group to formulate queries over XML data. XQuery, like SQL, is a declarative querylanguage that, as we will see later, can be easily understood with a basic knowledge of SQL andXPath.
This paper is based on the implementation of XQuery 1.0 in SQL Server 2005, which in turn is basedon the XQuery 1.0 July 2004 working draft. The first section of this paper provides an overview of the new XML data type and its associated features. Subsequent sections introduce the new XQuerylanguage and its advantages, the FLWOR statement, various operators in XQuery, built-in functionsin XQuery, type-related expressions, and non-supported features in SQL Server 2005, respectively.Finally, the last sections provide information on best practices and guidelines, XML datamodification, and XQuery usage scenarios.
The XML Data Type in SQL Server 2005
The new XML data type introduced in SQL Server 2005 provides users with the ability to store XMLdocuments and fragments in the database. An XML data type can be used to create a column, aparameter to a stored procedure or function, or a variable.Additionally, the user can associate a column of type XML with an XML schema collection to create atyped XML column. The XML schemas in the collection are used to validate and type the XMLinstances.
Typed vs. Untyped XML Data Type
An XML data type can be associated with an XML schema collection to have schema constraintsenforced on XML instances. If the XML data is associated with an XML schema collection, it is called
typed XML
. Otherwise, it is called
untyped XML
.The SQL Server 2005 XML data type implements the ISO SQL-2003 standard XML data type. It canstore not only well-formed XML 1.0 documents, but also so-called XML content fragments with top-level text nodes and an arbitrary number of top-level elements. Checks for well-formedness of thedata are performed, and these checks do not require the XML data type to be bound to XMLschemas. Data that is not well-formed (subject to the SQL-2003 content relaxations) is rejected.Untyped XML is useful when the schema is not known
a priori 
. It is also useful when the schema isknown but changing rapidly and thus hard to maintain, or multiple schemas exist and are latebound to the data based on external requirements. Furthermore, untyped XML is useful when theXML schemas contain XML Schema constructs not supported by the database engine (e.g.key/keyref, lax validation). In that case, you could use the System.XML validator inside a CLR(common language runtime) user-defined function to provide validation.If you have XML schemas in an XML schema collection describing your XML data, you can associatethe XML schema collection with the XML column to yield typed XML. The XML schemas are used tovalidate the data, perform more precise type checks than untyped XML during compilation of queryand data modification statements, and optimize storage and query processing.Typed-XML columns, parameters, and variables can store XML documents or content fragments,which you can specify as an option (DOCUMENT or CONTENT, respectively, with CONTENT as thedefault) at the time of declaration. Furthermore, you have to provide the collection of XML schemas.Specify DOCUMENT if each XML instance has exactly one top-level element; otherwise, use

Activity (3)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
jreismota liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->