You create XML schema collections by using the following DDL syntax:
CREATE XML SCHMEA COLLECTION RelationalSchema.SqlIdentifier AS Expression
In the syntax, RelationalSchemais the name of the schema being imported. This is optional, but if a relational schema is not specified, a default is relational schema is supplied. SqlIdentifieris the name of the schema collection. Expressionis the string constant or variable schema syntax of (n)varchar, (n)varbinary, or xmltype.
Don’t confuse a relational schema with an XML schema. In this case, a relational schema contains database objects such as tables, views, and stored procedures. Relational schemas have database owners, and the owner can be a database user or database role. For example, there is a dborelational schema.
The following is an example using a relational schema when creating an XML schema collection:
CREATE XML SCHEMA COLLECTION dbo.MotocrossCollectionTest AS...
For more information on relational schemas, consult the SQL Server documentation.
Before jumping in to some examples, I should make a few comments regarding the components created when a schema is imported into the database.
When an XML schema collection is created, several components related to the schema are imported into the database. The components are stored in a number of SQL Server system tables and include the following:
❑ Attributes
❑ Elements
What is important to remember is that when a schema is imported into the database, the schema is not stored, but rather the components themselves are stored. Each component falls into one of the following categories:
These categories define how a schema is stored in the database. When a schema is added or imported in the database, the schema is parsed and each component is stored by its type. The schema itself as a whole is not stored. For example, an <element>tag is not stored, but its components — such as values or attributes — are stored by the appropriate type.
The last tidbit of information is that a schema can be imported into the collection with or without a namespace.
For example, the following code creates an XML schema collection and imports a schema that does not contain a namespace:
CREATE XML SCHEMA COLLECTION MotocrossCollection AS ‘
<xs:schema xmlns=”” xmlns:xs=”http://www.w3.org/2001/XMLSchema”
The CREATE XML SCHEMA COLLECTIONstatement allows you to specify which database to create the schema collection in, so make sure you are in the correct database when creating the schema collection.
Figure 7-1 shows the newly created schema collection in the appropriate database.
Figure 7-1
In the example, the Manufacturer, NationalNumber, Type, and Classattributes belong to the ATTRIBUTEcategory, and the Team, Rider, and Nameelements belong to the ELEMENTcategory.
Now that the schema is created, you can use it for XML instance validation. For example, it can be applied to an xmldata type column, as shown in Figure 7-2.
Figure 7-2
Now any time an XML instance is inserted into this column it is validated against the schema collection.
If an XML instance passes the validation, it is inserted into the database. For example, the following XML instance passes the validation and is inserted into the table because it contains the appropriate ele-ments and attributes as defined by the XML schema:
INSERT INTO Motocross (MotocrossID, MotocrossInfo) VALUES (1,
<Name>Jeremy McGrath</Name>
However, the following XML instance does not pass validation, nor is it inserted into the table because each rider has a BikeSizeattribute, which is not defined by the schema:
INSERT INTO Motocross (MotocrossID, MotocrossInfo) VALUES (2,
If you try to insert this XML document, the following error is generated:
XML Validation: Undefined or prohibited attribute specified: ‘BikeSize’
Another way to create the schema collection is to assign the schema to a variable and use that variable in the CREATE XML SCHEMAstatement. The following example creates an xmldata type variable, sets the schema syntax to the variable, and then uses the variable in the CREATE XML SCHEMAstatement (to save space and for better readability, most of the schema syntax has been left out):
DECLARE @xmlvar xml
SET @xmlvar = ‘<xs:schema ...</xs:schema>’
CREATE XML SCHEMA COLLECTION MotocrossCollection AS @xmlvar
Before moving on to the next example, look at the results of the CREATE XML SCHEMA COLLECTION statement from a system table perspective. Open a query window and run the following query:
SELECT sys.xml_schema_collections.name FROM sys.xml_schema_collections
The results return a single column with two rows containing the default sysschema collection, and the MotocrossCollectionschema just added. It should look like the following:
Name ----Sys
MotocrossCollection
Now modify the query to look like the following:
SELECT sys.xml_schema_collections.name
The results of running this query return a single column with a single row, containing the name of the collection you added, as follows:
Name
----MotocrossCollection
When the MotocrossCollectionschema collection was added, no namespace was provided and there-fore no system table namespace record exists for the MotocrossCollectionschema collection.
This next example imports multiple schemas into the collection, both of which contain namespaces:
CREATE XML SCHEMA COLLECTION ProductModelSchemaCollection AS
‘<xsd:schema
<xsd:complexType name=”StepType” mixed=”true”>
<xsd:choice minOccurs=”0” maxOccurs=”unbounded”>
<xsd:element name=”tool” type=”xsd:string” />
<xsd:element name=”material” type=”xsd:string” />
<xsd:element name=”blueprint” type=”xsd:string” />
<xsd:element name=”specs” type=”xsd:string” />
<xsd:element name=”diag” type=”xsd:string” />
</xsd:choice>
<xsd:element name=”step” type=”StepType” minOccurs=”1” maxOccurs=”unbounded” />
</xsd:sequence>
<xsd:attribute name=”LocationID” type=”xsd:integer” use=”required” />
<xsd:attribute name=”SetupHours” type=”xsd:decimal” use=”optional” />
<xsd:attribute name=”MachineHours” type=”xsd:decimal” use=”optional” />
<xsd:attribute name=”LaborHours” type=”xsd:decimal” use=”optional” />
<xsd:attribute name=”LotSize” type=”xsd:decimal” use=”optional” />
</xsd:complexType>
<xs:element name=”Summary” type=”Summary” minOccurs=”0” />
</xs:sequence>
The second schema imports the first schema, as illustrated by the following code. This importreference is necessary if some of the components you want to add to your collection already exist in the collection.
Equally necessary, this importstatement is required when your components need to reference compo-nents in the same target space:
<xs:import namespace=”http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/ProductModelManuInstructions” />
Now run the following query:
SELECT * FROM sys.xml_schema_namespaces
The results (see Figure 7-3) show the addition of the namespaces from the two schemas in the system tables.
Figure 7-3
XML schema collections provide instant XML schema validation and data type information. This takes the validation away from the client and in turn provides a performance increase and optimized storage.
Are they required? No, not at all, but adding the schema validation wouldn’t hurt if the case calls for it.