Tải bản đầy đủ - 0 (trang)
3-10. Loading and Shredding Relational Tables from an XML Source File

3-10. Loading and Shredding Relational Tables from an XML Source File

Tải bản đầy đủ - 0trang

Chapter 3 ■ XML Data Sources

type = "xsd:integer" sql:field = "ID" />

sql:field = "InvoiceNumber" />

sql:field = "DeliveryCharge" />

sql:relation = "Invoice_Lines_XML_Multi"

sql:relationship = "InvoiceToLine" >

sql:field = "InvoiceID" />

sql:field = "SalePrice" />


Locate your data file (stored here as












Run this example after you have altered the vbs script to refer to the new .XML and

.XSD files by modifying the objBL.Execute statement, as follows:

objBL.Execute "C:\SQL2012DIRecipes\CH03\SQLXMLBulkLoadImportReferential.xsd", 




Chapter 3 ■ XML Data Sources

How It Works

This recipe’s example builds on the approach from the previous recipe. However, it does presume the following


Destination tables with primary key to foreign key relationships. This is why we have to

re-create the destination tables.

Source data where the “parent-child” data relationship is directly expressed in the XML

structure. This is the case in the source data where the  element contains one or

more  elements.

More generally, if the source XML is hierarchically structured to map to a relational source, then SQLXML

Bulk Load can shred the data into SQL Server tables while maintaining foreign key relationships. Here, as was

the case in the previous recipe, any potential difficulty lies in the definition and creation of the XSD file. Indeed,

everything that is important is in the schema file. I’ll explain the salient points.

First, note the  and  elements at the start of the schema file. The foreign key

mapping is specified inside these elements. It must be present—and correctly defined—for the load to work.

Then, inside these elements, you have the sql:relationship name = "InvoiceToLine" element. This names,

or identifies if you will, each relationship between tables as part of the appinfo, as it will then be used as part of

the sql:element definition for a “table” in the schema file. The relationship definitions are as follows:

parent = "Invoice_XML_Multi": The “parent” table.

parent-key = "ID": The primary key column of the “parent” table.

child = "Invoice_Lines_XML_Multi": The “child” table.

child-key = " InvoiceID ": The foreign key column of the “child” table.

sql:relationship = "InvoiceToLine": Inside the XML element, which contains the

child elements, this attribute specifies the relationship to use.

As you can see from this information, the ID field is now considered as a primary key in the Invoice_XML_

Multi table, and the InvoiceID is taken to be the foreign key in the Invoice_Lines_XML_Multi table. Executing

the .vbs script loads the data into the two tables, while maintaining the ID as the foreign key constraint for the


If you have a mapping schema that defines a primary key/foreign key relationship between two tables (such

as between Invoice and Invoice_Lines), the table with the primary key must be described first in the schema.

The table with the foreign key column must appear later in the schema.

You also need to know that SQLXML Bulk Load generates records as their nodes enter into scope, and sends

those records to SQL Server as their nodes exit scope. This means that the data for the record must be present

within the scope of the node. Consequently, the data for the “child” table cannot follow the data for the “parent”

table, as was the case for loading multiple (independent) tables.

In all the SQLXML Bulk Load examples used so far, we have used element-centric XML in the source data. As

I do not want to give the impression that this is the only option available to you, I would like to make it clear that

you can, of course, use attribute-centric XML as well—or indeed a mixture of the two.

So, to resume, where so far you have seen:

It could just as easily have been:



Chapter 3 ■ XML Data Sources

I have not given a complete example using just XML attributes, but the schema file given here should be

enough to allow you to create a schema file where the source data is all attribute-based. In any case, as long as the

mapping is accurate, your data will load.

Indeed, you are not limited to using just XML elements or attributes, but can mix the two in an XML Bulk

load, as shown in the following example:

The XML schema is the following (stored as

C:\SQL2012DIRecipes\CH03\SQLXMLBulkLoadImportElementAndAttribute.xsd). The destination table is one we

have used before—Client_XMLBulkLoad:

xmlns:sql = "urn:schemas-microsoft-com:mapping-schema">

The following is the data (stored as C:\SQL2012DIRecipes\CH03\SQLXMLSourceDataElementAndAttribute.xml):

 John Smith


To run this example, you need to alter the .vbs script to refer to the new .xml and .xsd files (objBL.Execute


"C:\SQL2012DIRecipes\CH03\SQLXMLSourceDataElementAndAttribute.xml"). Running the script will load the

data into the destination tables while maintaining relational integrity.

■■Note  Loading tables while maintaining referential integrity can be considerably slower than a multiple table load

where there is no referential integrity.

3-11. Overcoming Bulk Loading Challenges for XML Files


You want to use all the power of SQLXML Bulk Load to ensure a fast and trouble-free bulk XML data load.


Apply the relevant SQLXML Bulk Load options to accelerate the load and/or resolve potential load issues.

The available options are shown in Table 3-2.



Chapter 3 ■ XML Data Sources

Table 3-2.  SQLXML Bulk Load Options





No data will be loaded—however, the table structure will be

generated (assuming that SchemaGen is specified).



Ensures that the data being inserted into the tables applies all

constraints that have been specified on the tables (primary

and foreign key constraints, for example). The process fails if

this parameter is set to True, and constraints are violated.



This property applies a table lock, which reduces load time.

However, if a table lock cannot be obtained, the process will fail.



Issues a COMMIT for every row inserted (requiring the

Transaction property to be set to False). Be warned, this

is very slow!



Specifies that IDENTITY values from the source XML be used.

SQL Server will not generate IDENTITY values during the load




Any NULLS in the source data will be inserted into the

destination table(s).



Setting this property to True will create the destination table(s).

The mapping defined in the XML schema file will serve as the

basis for the table structure. The table must not already exist,

or the whole process will fail.



Setting this property to True will drop any existing destination

table(s)—provided that there are no foreign key constraints,

for instance.



Specifies the path to the temp file that is used if the process is

in a transaction. This allows you to specify a different disk array

for increased speed.




Guarantees that the operation is a transaction—that is, loads

or fails entirely.



This property specifies that the XML data file is an XML

fragment (has no single top-level node). This must be set for

XML fragments, or the whole process will fail.


How It Works

SQLXML Bulk Loader can go far beyond the examples given in the previous recipes. It seems a shame not to take

advantage of its immense power, including the ability to

Mix XML attributes and elements in the source data.

Use the available XML data types.

Create and drop the destination table automatically (as well as enable or disable

constraints and transactions).



Tài liệu bạn tìm kiếm đã sẵn sàng tải về

3-10. Loading and Shredding Relational Tables from an XML Source File

Tải bản đầy đủ ngay(0 tr)