The Web Server Environment - Database Processing: Fundamentals, Design, and Implementation - page 495

By ThE WAy Elements and attributes both carry data, and you may be wondering when
to use one or the other. As a general rule, for database/XML applications,
use elements to store data and attributes to store metadata. For example, define an
ItemPrice element to store the value of a price, and define a Currency attribute to store
the currency type of that price, such as USD, Aus$, or Euros.
The XML standards do not require that elements and attributes be used in this
way. It is a matter of style, and in subsequent sections, we will show how it is possible
to cause SQL Server to place all of the column values in attributes, to place all of them
in elements, or to mix them up so that some columns are placed in attributes and oth-
ers are placed in elements. Thus, these decisions are a matter of design choice rather
than XML standard.
By default, the cardinality of both simple and complex elements is 1.1, meaning that a
single value is required and no more than a single value can be specified. For the schema in
Figure 11-51(a), the minOccurs = "0" expressions indicate that the defaults are being overrid-
den for Birthdate and DeceasedDate so that they need not have a value. This is similar to the
NULL constraint in SQL schema definitions.
Figure 11-51(b) shows the XML Schema in a diagram format as drawn by Altova's XMLSpy
XML editing tool (see www.altova.com/xml-editor/ ) . Being able to see an XML Schema as a
diagram often makes it easier to interpret exactly what the XML Schema is specifying. In this
diagram, note that required elements (NOT NULL in SQL terms) are indicated with solid lines
and box outlines, whereas optional elements (NULL in SQL terms) are indicated by dashed
lines and box outlines.
By ThE WAy You can find out more about this excellent product from a small company,
which is not yet owned by Microsoft or some other behemoth corporation,
from the Web site www.altova.com . A 30-day trial version is available. You can process
all of the XML code in this chapter using XMLSpy.
Figure 11-51(c) shows an XML document that is valid on the schema shown in Figure 11-51(a).
Observe that the value of the ArtStyle attribute is given with the heading of the Artist element. Also
note that a namespace of xsi is defined. This namespace is used just once—for the noNamespace-
SchemaLocation attribute. Do not be concerned about the name of this attribute; it is simply a
means of telling the XML parser where to find the XML Schema for this document. Focus your at-
tention on the relationship of the structure of the document and the description in the XML Schema.
Flat Versus Structured Schemas
Figure 11-52 shows an XML Schema and an XML document that represent the columns of
the CUSTOMER table in the View Ridge database. As shown in Figure 11-52(a), CustomerID,
LastName, and FirstName are required, but all of the other elements are not required.
XML Schemas like the one shown in Figure 11-52(a) are sometimes called flat because
all of the elements reside at the same level. Figure 11-52(b) shows a diagram of the XML
Schema as drawn by XMLSpy, and this diagram graphically depicts why this schema is called
flat. The XML document in Figure 11-52(c) contains one of the rows of the CUSTOMER table.
If you think about the elements in Figure 11-52(a) for a moment, you will realize that
something about the semantics of them has been left out. In particular, the group {Street,
City, State, ZipPostalCode, Country} is part of an Address theme. Also, the group {AreaCode,
PhoneNumber} is part of a Phone theme. As you know, in the relational model, all columns are
considered equal, and there is no way to represent these themes.