1. 1 SCHEMALESS APPROACH OF MAPPING XML DOCUMENTS INTO RELATIONAL DATABASE Ibrahim Dweib, Ayman Awadi, Seif Elduola Fath Elrhman, Joan Lu CIT 2008 Sydney, Australia 8-11 July 2008

2. 2 Why schema-less schema-less Many applications deal with highly flexible XML documents from different sources, which make it difficult to define their structure by a fixed schema or a DTD. Therefore, it is necessary for schema-less approaches to deal with such XML documents.

3. 3 The method aims to overcome the challenges faced due to fixed shredding  No loss of information while shredding.  Reconstruction of original XML documents is easier and much faster.  Maintaining XML document structure.  Preserve the ordering nature of XML data.

4. 4 Theory guidance The main mathematical concepts that are used in this method are: Definition 1: Definition 1: XML tree is composed of many sub-trees of different levels; it can be define as the following: i=1, 2 … n, represent the levels of XML tree, 0 represents the root i=1, 2 … n, represent the levels of XML tree, 0 represents the root Where, E i is a finite set of elements in the level i. A i is a finite set of attributes in the level i. X i is a finite set of texts in the level i. r i-1 is the root of the sub-tree of level i.

5. 5 Theory guidance (Con ’ t) Definition 2: A dynamic fragment (shred) df(i) is defined to be the attributes and texts (leaf children) of the sub-tree i of the XML tree plus its root r i-1, as follows: df(i) = (A i, X i, r i-1 ), Where: A i is a finite set of attributes in the level i X i is a finite set of texts in the level i. r i-1 is the root of the sub-tree of level i. r i-1 is the root of the sub-tree of level i.

6. 6 Design framework A master table for documents. Called "documents “ table, to keep information about documents themselves, A master table for documents. Called "documents “ table, to keep information about documents themselves, documents(doc_id, doc_structure, ….. ), Additional fields may be added to keep all information about the document itself such as dates, statistics, types … etc.  The doc_id is a unique id generated per document to identify documents.  The doc_structure is a big text field containing a coded string describing each document structure, any changes on the document structure should be reflected in this field, such as adding a new tag or property, deleting an existing tag or property, or relocating a given tag or property to a different location in the same document

7. 7 Design framework (Con ’ t) A second table to store the actual contents for all documents. Documents will be shredded into pieces of data that will be called tokens, each document element, tag, or property will be considered a token, the tokens table will have at the minimum this structure, A second table to store the actual contents for all documents. Documents will be shredded into pieces of data that will be called tokens, each document element, tag, or property will be considered a token, the tokens table will have at the minimum this structure, tokens(doc_id, token_id, token_name, token_value).  The token_id is the primary generated id for each token.  The doc_id is the foreign key linking the tokens table to the documents table.  token_name is the tag name or the property name as found in the original XML document.  token_value is the text value of the XML tag property.

8. 8 Design framework, (Con ’ t) “ doc_structure ” field construction rules: The doc_structure field is where the document structure maintained. The doc_structure field is where the document structure maintained. It consists of long series of related keys. It consists of long series of related keys. Each key should start with a given alphabet character, Each key should start with a given alphabet character,  The letter 'T' for element (child), and the letter 'A' for attribute,  These letters are necessary to delimit keys in the sequence.  Then the letter is followed by a numeric number representing the token_id that this key is referring to, Example: T120 is a key referring to a token in the tokens table whose token_id = 120. Example: T120 is a key referring to a token in the tokens table whose token_id = 120.

9. 9 Design framework, “ doc_structure ” field construction rules: (Con ’ t) If the token has properties then If the token has properties then the key representing this token in the doc_structure will be followed with a set of keys defining these properties. Example: T120A12A17A2 is a valid key string for token number 120 which has three properties defined by tokens number 12, 17, and 2. Example: T120A12A17A2 is a valid key string for token number 120 which has three properties defined by tokens number 12, 17, and 2. These properties appear in the original document in this order. These properties appear in the original document in this order.

10. 10 Design framework, “ doc_structure ” field construction rules: (Con ’ t) If the token has some children tags then If the token has some children tags then these children will be represented as a key-string surrounded by angle brackets. Example: T120 T77> is a valid string that can be read, token 120 has three sub tags in this order: token 12, followed by token 7, then token 77, and token 7 itself has also two sub tags 2, and 1 in the given order. Example: T120 T77> is a valid string that can be read, token 120 has three sub tags in this order: token 12, followed by token 7, then token 77, and token 7 itself has also two sub tags 2, and 1 in the given order.

11. 11 Theory implementation on simple case study Theory implementation on simple case study <books> M. John M. John Computer Science 101 Computer Science 101 A. Mark A. Mark Applied Math 101 Applied Math 101 Math Math </books> Figure 1: XML document

12. 12 Theory implementation on simple case study Theory implementation on simple case study Figure 2: A tree representation for XML document in figure 1 Books 99 104 105 100 Book author name M. John CS 101 Id "11210" Category "fiction" Id "a1" Sex "m" 101 102 103 106 Book authorsubjectname A. Mark Math Applied Math 101 Id "11211" 107 108 110 109 111 Books 99 104 105 100 Book author name M. John CS 101 Id "11210" Category "fiction" Id "a1" Sex "m" 101 102 103 106 Book authorsubjectname A. Mark Math Applied Math 101 Id "11211" 107 108 110 109 111 Books 99 104 105 100 Book author name M. John CS 101 Id "11210" Category "fiction" Id "a1" Sex "m" 101 102 103 106 Book authorsubjectname A. Mark Math Applied Math 101 Id "11211" 107 108 110 109 111

13. 13 Theory implementation on simple case study Theory implementation on simple case study Doc_strcutureDoc_id T99 T107A108 >10 Figure 5: Documents table

14. 14 Theory implementation on simple case study Theory implementation on simple case study token_valuetoken_nametoken_iddoc_id Nullbooks9910 Nullbook10010 11210id10110 fictioncategory10210 M. Johnauthor10310 a1id10410 msex10510 Computer Science 101name10610 Nullbook10710 11211id10810 A. Markauthor10910 Applied Math 101name11010 Mathsubject11110 Figure 6: Tokens table

15. 15 EXPERIMENTAL Environment  An Intel Core 2 Duo computer with 2 GHz CPU, 1 GB RAM, 256 MB shared Cache  OS: Windows Vista home edition.  Visual Basic 6 is used as software development kit with Microsoft Access 2003 as relational database target.  Five XML documents with different sizes are used in the experiment.  The data is taken from the XML data repository that is available at the web site of the School of Computer Science and Engineering, University of Washington.  The performance metric is the time spent for mapping XML documents to relational database and the time spent for reconstructing these documents from relational database.  The experiment is repeated five times and the mean value of those times is reported to obtain a realistic and accurate results.

16. 16 EXPERIMENTAL RESULTS 1MB602KB 64 KB 28 KB 4 KB Document size 5.852781363.574335.35514450.149777360.01988238 Mapping time (secs) 32.0625510418.3055441.9268360.449809580.018990234 Reconstructing time (secs) Table 1: The time spent for mapping XML documents to RDBMS, and the time for reconstructing them

17. 17 EXPERIMENTAL RESULTS

18. 18 Conclusion (1) By using this method:  Maintaining document structure at a low cost price and easily,  Building the original document is straight forward,  Performing first level semantic search is also achievable either on a single document or on all documents.

19. 19 Conclusion (2) Method Limitation:  Complex semantic search is not achievable easily in this structure.  Document size is limited to memory size since we use DOM based parsing

20. 20 Future Works  Improving this method to achieve complex semantic search, differentiate between XML data type (i.e., strings, dates, integers), in order to apply less than or greater than queries.  Making an intensive testing and compare our method with other methods in the literature to see its performance.  Using SAX parsing for XML document to solve document size limitation.

21. 21 Thank You for Your Time