1. XML Structures For Existing Databases Ref: http://www- 106.ibm.com/developerworks/xml/library/x-struct/

2. 2 XML schema Validator The Sun Multi-Schema XML Validator (MSV) is a Java[tm] technology tool to validate XML documents against several kinds of XML schemata: download: http://wwws.sun.com/software/xml/developers/multis chema/ http://wwws.sun.com/software/xml/developers/multis chema/

3. 3 Document Type Definitions DTDs are associated with the entire element tree via the document element.

4. 4 Writing DTDs Example1.dtd Example1.xml XML How to write DTD

5. 5 Validating Sun Validator Invoking the Validator: java -jar C:\pathName\msv.jar Example1.dtd Example2.xml Output: start parsing a grammar. validating Example1.xml the document is valid.

6. 6 ID Attribute Type Attributes using the ID type serve as unique identifiers for a given instance of an element. The value of an ID attribute must be a valid XML name, unique within a document and use the #IMPLIED or #REQUIRED default value. #IMPLIED: No default value. The attribute is optional. #REQUIRED: The attribute must appear in every element type. #FIXED: Attributes may be optional, but when present are constrained to the given value. There may only be one ID attribute for one element type.

7. 7 Example 2 Two One

8. 8 Example 3 <!ATTLIST Order OrderId ID #REQUIRED > <!ATTLIST Item ItemId ID #REQUIRED > Item1 20.00 Item2 20.00 Item3 20.00 Item4 20.00

9. 9 Example 4 <!ATTLIST Order OrderId ID #REQUIRED > <!ATTLIST Item ItemId ID #REQUIRED Manf IDREF #REQUIRED > Item1

10. 10 Example 5 <!ATTLIST Order OrderId ID #REQUIRED > <!ATTLIST Item ItemId %ID_Req; Manf IDREF #REQUIRED > Item1 &Greetings ;

11. 11 Modeling Relationships Primary Keys: Invoice: invoiceId LineItem: lineItemId Foreign Keys: invoiceId in LineItem

12. 12 Modeling Relationships One-to-one and one to many relationships are best represented by containment. In the following DTD, mostly attributes are used to represent the information in LineItem and Invoice. <!ATTLIST Invoice orderDate CDATA #REQUIRED customerId CDATA #REQUIRED> <!ATTLIST LineItem itemDesc CDATA #REQUIRED price CDATA #REQUIRED quantity CDATA #REQUIRED >

13. 13 Example

14. 14 Modeling Relationships Many to many relationships can be represented using pointers, that is ID/IDREF pairs. Using containment in this situation will result in redundancy of information Example: <!ATTLIST Invoice orderDate CDATA #REQUIRED customerId CDATA #REQUIRED> <!ATTLIST LineItem itemIDREF IDREF #REQUIRED price CDATA #REQUIRED quantity CDATA #REQUIRED > <!ATTLIST Item itemId ID #REQUIRED itemName CDATA #REQUIRED itemDesc CDATA #REQUIRED >

15. 15 XML Design For Data Some Issues To Consider Establish the scope of the document Identify the structures to model Identify the relationships between entities Identify data points that need to be associated with each structure

16. 16 XML Design For Data Some Issues To Consider Example: Let us take two purchase orders and model them in XML. Books, Inc Purchase Order Order date: 6/25/2002 Shipping Date:6/27/2002 Customer: Mary Jones 500 Alameda Santa Clara, Santa Clara, CA 95013 Shipping Co:UPS Item No (ISBN)Descriptionquantitypricetotal Q1234Cosmos150.0050.00 Q555XML225.0050.00 Total$100.00

17. 17 XML Design For Data Some Issues To Consider Books, Inc Purchase Order Order date: 7/28/2002 Shipping Date:7/30/2002 Customer: John Smith 555 Spring Ct Santa Clara, Santa Clara, CA 95013 Shipping Co:fedex Item No (ISBN)Descriptionquantitypricetotal Q333Java530.00150.00 Q555XML125.0025.00 Total$175.00

18. 18 Establish the scope: –One XML document per PurchaseOrder –One XML document to represent a number of PurchaseOrders.

19. 19 Identify the Structures to model Orders –PurchaseOrders –Customer –Item –LineItem

20. 20

21. 21 Creating The XML DTD Start With the Structures and establish the Elements

22. 22 Add the Data points to the Elements We will use attributes to represent the data points <!ATTLIST Orders StartDateCDATA #REQUIRED EndDateCDATA#REQUIRED …. …. …. ….

23. 23 Model the relationships Use containment whenever possible. Relationships: –Each Orders contains many PurchaseOrders. –Each PurchaseOrder has one Customer. –Each Customer may be associated with more than one PurchaseOrder. –Each LineItem has one Item. –Each Item may be in more than one LineItem

24. 24 Each Orders contains many PurchaseOrders. Each PurchaseOrder contains many LineItems <!ATTLIST Orders StartDateCDATA #REQUIRED EndDateCDATA#REQUIRED …. …. …. ….

25. 25 Modeling Relationships Modeling Relationships: Each PurchaseOrder has one Customer. Each Customer may be associated with more than one PurchaseOrder. Each LineItem has one Item. Each Item may be in more than one LineItem –To avoid the repetition of data for Customer and Item, we will use ID/IDREF to represent the one to many relationship. –The elements Customer and Item are promoted to the document scope

26. 26 … <!ATTLIST PurchaseOrder orderDateCDATA#REQUIRED shippingDate CDATA#REQUIRED shippingCo(fedex | ups) #REQUIRED customerIDREFIDREF#REQUIRED …. <!ATTLIST Customer customerId ID #REQUIRED name CDATA #REQUIRED …

27. 27 XML Structures For Existing Databases Migrating a Database To XML Scoping the XML Document Creating the Root Element Model the tables Model the non-foreign key values Adding ID attributes Handling Foreign Keys Adding the Relationships

28. 28 Scoping the XML Document Choose the data to include in the XML document – Based on the business requirements the XML document will be fulfilling, decide which tables and columns will need to be included in the xml documents.

29. 29 Creating The Root Element Create a Root Element Create a root element for the document. Declare any attributes of that element that are required to hold additional semantic information.

30. 30 Model the tables Content tables: Contain a set of records. Eg: Customer information Lookup tables: Contain a list of ID-description pairs that are used to further classify information. Eg: Shipping Company Relation tables: Express many to many relationships as separate tables. These will be treated as content tables.

31. 31 Content Tables Create an element in the DTD for each content table. Model the Non-foreign key values: As Attributes: As attributes in the ATTLIST associated with ach element; each attribute should have a type, CDATA and if it cannot take nulls in the database should include #REQUIRED; Otherwise, should be #IMPLIED. As Elements: If the attribute in database allows nulls, use ? as suffix; otherwise, use no suffix.

32. 32 Adding ID attributes Add an ID attribute to each of the Elements (with the exception of root element). Use the element name followed by ID for the name of the new attribute, watching for name collisions. Note that a unique ID (unique across all elements in the document) will need to be created for each of the instance of an element. If there are row-based primary keys, use them by prefixing them with the table name.

33. 33 Handling Foreign Keys Foreign keys serve as glue to connect the different tables in a database. In XML, relationships between elements can be represented –using containment (via nesting). –Using ID/IDREF pairs

34. 34 Modeling Lookup Tables For each foreign key that we have chosen to include in our XML structures that references a lookup table: –Create an attribute on the element representing the table in which the foreign key is found. –Give the attribute the same name as the table referenced by foreign key. –Make the attribute of the enumerated list type. –Example: <!ATTLIST PurchaseOrder shippingCo(fedex | ups) #REQUIRED

35. 35 Add Element content to the Root Element Add a child element or elements to the allowable content of the root element for each table that models the content information in the document.

36. 36 Modeling the relationships Walk the relationships between tables to add ID/IDREF where applicable. We walk the relationships in the direction that makes the most business sense, for example, from PurchaseOrder to LineItem. If the relationship is 1 to 1 or 1 to n, in the direction that is being navigated, and no other relationship leads to the child within the selected subset, then add the child element as element content of the parent element with the appropriate cardinality.

37. 37 Many-to-one or multiple-parent relationships: Identify each relationship that is many-to-one in the direction we have defined it, or whose child is a child in more than one relationship we have defined. For each of these relationships, add an IDREF or IDREFS attribute to the element on the parent side of the relationship, which points to the ID of the element on the child side of the relationship.

38. 38 Add missing elements to the root element: For any element that is pointed to in the structure so far, add that element as allowable element content of the root element. Discard unreferenced ID attributes: Remove unwanted ID attributes. Remove ID attributes that are not referenced by IDREF or IDREFS attributes elsewhere in the XML structures.