Global Elements

Global Elements

Suppose that we want to use XML Schema to represent a document that extends the customer data in Figure 12-8 to include the salesperson assigned to that customer. Further, suppose that both customers and salespeople have address and phone data. We can use the techniques shown thus far to represent this new customer structure, but, if we do so, we will duplicate the definition of Phone and Address.

Figure 12-8

Example of a Structured Schema

(a) Structured XML Schema

Part 5 Database Access Standards

(b) Graphical Representation of the XML Schema

Figure 12-8

Continued

(c) Schema-Valid XML Document

In the relational world, we worry about duplication of data, not so much because of wasted file space, but more because there is always the chance of inconsistent data when one copy of the data is changed and the other copy is not changed. Similarly, in the document-processing world, people worry about the duplicate definition of elements because there is always the chance that they will become inconsistent when one is changed and the other is not. As shown in Figure 12-9, elements can be declared globally and then reused to eliminate the definition duplication.

Chapter 12 Database Processing with XML

(a) XML Schema with Global PhoneType Element

Figure 12-9

Example of a Schema with (b) Graphical Representation of the PhoneType Global Elements

Global Element

In Figure 12-9(a), for example, the Address group is defined as the global element AddressType, and the Phone group is defined as the global element PhoneType. According to the XML Schema standard, these are global elements because they reside at the top level of the schema.

Part 5 Database Access Standards

Figure 12-9

Continued (c) Graphical Representation of the XML Schema If you examine Figure 12-9(a) further, you will see that both Customer and Salesperson

within Customer use the AddressType and PhoneType global definitions. They are referenced by the notations type = “AddressType” and type = “PhoneType.” By using these global defini- tions, if either PhoneType or AddressType is changed, the definition of Customer and Salesperson will inherit the change.

One other change in this figure is that the cardinality of the Phone group of Salesperson has been set to 1.3. This notation means that at least one Phone group is required and as many as three are allowed. As you learned in Chapter 5, representing such multivalued attributes in the entity-relationship model requires the definition of an ID-dependent entity. That entity will later

be transformed into a table in the relational model. We will ignore this issue here. This notation is shown only so that you can see how multivalued elements are documented in an XML Schema. Figure 12-9(b) shows how XMLSpy graphically represents the PhoneType global element, and Figure 12-9(c) illustrates the way that the PhoneType reference is shown for Customer and Salesperson.

In the VRG table structure we specified in Chapter 7 and used in Chapters 10, 10A, and 10B, no SALESPERSON table was defined. The XML Schema in

Figure 12-9, however, suggests how we could add a SALESPERSON table to the VRG database.

Chapter 12 Database Processing with XML

Creating XML Documents from Database Data

SQL Server, Oracle Database, and MySQL have facilities for generating XML documents from database data. The Oracle XML features require the use of Java. Because we do not assume that you are a Java programmer, we will not discuss those features further in this chapter. If you are

a Java programmer, you can learn more about Oracle’s XML features at www.oracle.com. The facilities in SQL Server, Oracle Database, and MySQL are undergoing rapid develop- ment. In the case of SQL Server, version 7.0 added the expression FOR XML to SQL SELECT syntax. That expression was carried forward to SQL Server 2000. In 2002, the SQL Server group extended the SQL Server capabilities with the SQLXML class library. SQLXML, which was produced by the SQL Server group, is different from ADO.NET. All of these features and functions were merged together in SQL Server 2005 and are carried forward in SQL Server 2008 and SQL Server 2008 R2.