Automatic Generation of XQuery View Definitions from ORA-SS Views

1. Automatic Generation of XQuery View Definitions from ORA-SS Views Ya Bing Chen Tok Wang Ling Mong Li Lee School of Computing National University of Singapore

2. Outline • Introduction • ORA-SS Data Model • Motivating Example • Generation of XQuery View Definitions • Conclusion

3. Part 1. Introduction

4. Introduction to XML • XML • Publish data on the Web • Exchange data for Internet-based business applications • XML Views • Secure the source data • Provide application-specific views of the source data

5. Related Works • SilkRoute [14] • Export relational data into XML • Complex – two different languages to define and query XML views over relational data respectively • XPERANTO [6] • Export relational data into XML and evaluate XML queries over XML views of relational data • Ignore semantics in defining XML views • Xyleme [11] • Define XML views over XML data based on DTD with selection and join operators, etc,. • Do not support complex XML views such as involving swap operators • ActiveView [3] • Define views with active features (method calls & triggers) over XML repository • Do not support semantics checking

6. Related works • Major commercial databases • Oracle 9i [22] • Export relational data to materialized XML views using SQLX, XSQL or XML SQL Utility (XSU) • Microsoft SQL Server [21] • Create XML view of existing relational data using XML Schema • IBM DB2 [23] (XTABLE – derived from XPERANTO [6]) • Define XML views of relational tables with XQuery • Difficult to write view definitions

7. Motivation • In related works • Ignore semantics in source data • Useful for validate XML views • Difficult to use languages to define XML views • Long and complex • Hard to understand • A novel approach proposed in this paper • Adopt a semantically-rich data model – ORA-SS • Automatically generate view definitions in query expression from ORA-SS views

8. Part 2. ORA-SS Data Model

9. Concepts • Object class • An entity type in Entity-Relationship • An element in XML documents • Relationship type • Relationship among object classes • Attribute • Property of object class or relationship type • Key attribute, single-value attribute, multi-value attribute, etc,.

10. Features of ORA-SS • Distinguish between object class, attribute and relationship type • Differentiate attributes of object class and relationship type • Enable us to design valid XML views • That is, the views do not violate semantics in source data (Example) • Other data model such as OEM, Dataguide cannot support all the semantics above

11. Our previous works • Extract ORA-SS schema from XML data • Enrich ORA-SS schema with necessary semantics • Design valid XML views based on ORA-SS • Selection, drop, join & swap operators

12. Part 3. Motivating Example

13. Motivating example • Use XQuery to express XML views • Long and complex • Hard to understand • The following example illustrates this <db> <supplier sno=”s001” > <part pno=”p001”> <price>100</price> </part> <part pno=”p002”> <price>120</price> </part> </supplier> <supplier sno=”s002”> <part pno=”p002”> <price>40</price> </part> <part pno=”p003”> <price>30</price> </part> </db> swap Figure 5. A source XML file

14. Motivating example (cont.) Instance diagrams swap • Swap operator will keep the relationship set’s attributes in the current position • For each part, we retrieve all suppliers that supply this part

15. Motivating example (cont.) • User can write the XQuery expression for the view. 1. let $pno_set := distinct-values($in//part/@pno) 2. let $sno_set := distinct-values($in//supplier/@sno) 3. return <db> 4.for $p_no in $pno_set 5. let $p := $in//part[@pno=$p_no] 6. return <part pno=”{$p_no}”> 7. {for $s_no in $sno_set 8. where some $p1 in $in//part 9. satisfies ( exists($p1[@pno=$p_no]) and 10. exists($p1[ancestor::supplier/@sno=$s_no]) ) 11. let $s :=$in//supplier[@sno=$s_no] 12. return <supplier sno=”{$s_no}”> 13. {$s/part[@pno=$p_no]/price} 14. </supplier> 15. } 16.</part> 17. </db> swap • User need to know price is an attribute of relationship type sp Figure 10. XQuery expression for the view

16. Motivating example (cont.) • XQuery expression for ORA-SS view • Complex and hard to understand • Prone to making error • User need to know where to put the related relationship attribute in the correct position in the view! • Solution: • Design views using view operators based on ORA-SS • Guarantee the designed view is valid in terms of semantics • Automatically generate XQuery expression for ORA-SS view

17. Part 4. Generation of XQuery View Definitions Main ideas Analyzing vpath Generate where conditions

18. Main ideas • Generate query expression of each object class in an ORA-SS view • A FLWOR expression: For, Let, Where, Order by and Return clauses • Often used for restructuring data • Combine query expressions of all object classes together according to the tree structure of the view

19. Main ideas (cont.) • It is straightforward to automatically generate For/Let and Return clauses for an object class in the view • However, it is not a trivial task to generate the condition constrains in Where clause for an object class in the view • Many different object classes in source schema may determine the values of a given object class in the view. • Therefore, it is important to know all the relevant object classes in source schema for a given object class in the view.

20. Main ideas (cont.) • Intuitively, the values of an object class in a view can only be determined by the values of object classes in the path from the root to the object class in the view. • Definition 1. • For any object class o in an ORA-SS view, the path from the root of the view to o is called the vpath (viewpath) of o. • The object classes that occur in the vpathof o may influence the values of o in the view.

21. Analyzing vpath • Three types of object classes in the vpath of an object class o in an ORA-SS view • Type I: originate from the ancestors or descendants of o in the source schema. • ExampleBack to Rules for Type I • Type II: originate from the descendants of o’s ancestors in the source schema. • ExampleBack to Rules for Type II • Type III: originate from the object classes in another source schema, whose ancestor or descendant has a key-foreign key reference with o’s ancestor or descendant. • ExampleBack to Rules for Type III

22. Generate condition constraints in where clause • For each type of object class in vpath of o • Present a set of rules to generate where conditions for o • In the following rules • vo refers to an arbitrary object class in o’s vpath • o_no and vo_no refer to the key attribute of o and vo • vo is processed before o, we can employ vo_no when generating where conditions for o • $in represent the source document

23. Rules for Type I object class • Rule Type I_A(Definition for Type I) • If vo is an ancestor of o in source schema, then the following condition constraints (red color) are generated in the Where clause let $ono_set := distinct-values($in//o/@o_no) for $o_no in $ono_set wheresome $vo1 in $in//vo satisfies ( exists( $vo1[@vo_no=$vo_no]) and exists($vo1[descendant::o/@o_no=$o_no]) ) Figure 12(b). Where condition generated for o in Rule Type I_A

24. Rules for Type I object class (cont.) • Rule Type I_B • If vo is a descendant of o in source schema, then the following condition constraints (red color) are generated in the Where clause let $ono_set := distinct-values($in//o/@o_no) for $o_no in $ono_set where some $vo1 in $in//vo satisfies ( exists( $vo1[@vo_no=$vo_no]) and exists($vo1[ancestor::o/@o_no=$o_no]) ) Figure 13(b). Where condition generated for o in Rule Type I_B

25. Rules for Type II object class • Rule Type II_A (Definition for Type II) • Case (A): LCA is in the vpath of o • If vo is a Type II object class in o’s vpath and the Lowest Common Ancestor of vo and o in source schema, say LCA,is in the vpath of o in the view, then there is no need to generate a condition constraint in the Where clause for the restriction of vo on o.

26. Rules for Type II object class (cont.) • Rule Type II_B • Case (B): LCA is not in the vpath of o • If vo is a Type II object class in o’s vpath and the Lowest Common Ancestor of vo and o, say LCA,is not in the vpath of o in the view, then the following condition constraints (red color) are generated in the Where clause. let $ono_set := distinct-values($in//o/@o_no) for $o_no in $ono_set where some $LCA in $in//LCA satisfies ( exists($LCA//o[@o_no=$o_no]) and exists($LCA//vo[@vo_no=$vo_no]) ) Figure 15(b). Where condition generated for o in Rule Type II_B

27. Rules for Type III object class • Rule Type III_A(Definition for Type III) • Case (A): referenced object class is in o’s vpath • If vo is a descendant of the referenced object class in source schema and the referencing object class is in o’s vpath in the view, then there is no need to generate a condition constraints for the restriction of vo on o

28. Rules for Type III object class (cont.) • Rule Type III_B • Case (B): o is the referencing object class itself • If vo is a descendant of the referenced object class and o is the referencing object class itself in source schema, then the following condition constraints are generated let $ono_set := distinct-values($in//o/@o_no) for $o_no in $ono_set where some $referenced in $in1//referenced satisfies ( exists($referenced[@r_no=$o_no]) and exists($referenced[descendant::vo/@vo_no=$vo_no]) ) Figure 18(b). Where condition generated for o in Rule Type III_B

29. Rules for Type III object class (cont.) • Rule Type III_C • Case (C): referenced object class is not in o’s vpath and o is an ancestor of referencing object class • If vo is a descendant of the referenced object class and o is an ancestor of the referencing object class in the source, and the referencing object class is not in o’s vpath, then the following condition constraints (red color) are generated in the Where clause let $ono_set := distinct-values($in//o/@o_no) for $o_no in $ono_set where some $referenced in $in1//referenced satisfies ( exists($referenced[descendant::vo/@vo_no=$vo_no]) ) and some $referencing in $in2//referencing satisfies ( exists($referencing[@r_no=$referenced/@r_no]) and exists($referencing[ancestor::o/@o_no=$o_no]) ) Figure 17(b). Where condition generated for o in Rule Type III_C

30. Rules for Type III object class (cont.) • Rule Type III_D • Case (D): referencing object class is not in o’s vpath and o is a descendant of referencing object class • If vo is a descendant of the referenced object class and o is a descendant of the referencing object class in the source, and the referencing object class is not in o’s vpath, then the following condition constraints are generated let $ono_set := distinct-values($in2//o/@o_no) for $o_no in $ono_set where some $referenced in $in1//referenced satisfies ( exists($referenced[descendant::vo/@vo_no=$vo_no]) ) and some $referencing in $in2//referencing satisfies ( exists($referencing[@r_no=$referenced/@r_no]) and exists($referencing[descendant::o/@o_no=$o_no]) ) Figure 19(b). Where condition generated for o in Rule Type III_D In the cases where vo is an ancestor of the referenced object class in source schema, similar rules can be easily derived.

31. Summary for all the rules • Rule Type I & Type II • Consider all different cases where vo is in the same source schema as o • Rule Type III • Consider cases where vo is in another source schema different from o’s source schema • In summary, all the rules above consider all possible cases in designing XML views using our query operators

32. Algorithm Generate_View_Definition • The ORA-SS view input in the algorithm is valid • First generate a set of let clauses for all object classes in the view in pre order • Generate root element for the view • Process each child of the root from left to right • Algorithm Generate_View_Definition • Input: view schema v; source schema s • Output: view definition of v • for each object class o in the view{ • generate a let clause: • “let $ono_set := distinct-alues($in//o/@o_no)” • } 4 generate the start tag for root of the view: 5 “return <root>” 6 for each child o of the root of v { 7 generate a start bracket: “{“ 8Generate_Objectclass_Definition(o, v); 9 generate a end bracket: “}” 10 } 11 generate the end tag for root of the view: “</root>” Figure 20. Algorithm to generate view definition

33. Algorithm Generate_Objectclass_Definition 18. generate a let clause: “let $o := $in//o[@o_no = $o_no]” 19. generate a return clause: “return <o o_no=”{$o_no}” distinct($o/@attributes)>” // construct o and those attributes shown as attributes of o in the source file 20. for each attribute of o shown as a sub element of o in the source file { 21. generate it as a sub element of o: “{distinct($o/@attribute)}” 22. } 23. if ohas no child { 24. generate an end tag for o: “</o>” 25. return the generated definition; 26. } 27. else { 28. for each child object class co of o{ 29. generate a start bracket: “{“ 30. Generate_Objectclass_Definition(co, v, s); 31. generate an end bracket: “}“ 32. } 33. generate an end tag for o: “</o>” 34. return the generated definition; 35. } • Algorithm Generate_ObjectClass_Definition • Input: object class o; view schema v source schema s • Output: view definition of o and its descendants • 1. generate a for clause • “for $o_no in $ono_set” • 2. generate an empty where clause for o; • 3. for each object class vo in the vpath of o{ // top down • 4. if vo belongs to type I { • 5. ProcessTypeI(vo, o); • //generate a where condition based on rules for Type I • 6. } • 7. if vo belongs to type II { • 8. ProcessTypeII(vo, o); • //generate a where condition based on rules for Type II • 9. } • 10. if vo belongs to type III { • 11. ProcessTypeIII(vo, o); • //generate a where condition based on rules for Type III • 12. } • 13. append the generated condition in the where clause; • 14.} • 15. if there is any selection operator applied to o { • generate a where condition for all the operators in the where clause; • 17.} Figure 21. Algorithm to generate object class definition

34. Part 5. Conclusion

35. Conclusion • Our motivation • Complexity of defining and querying XML views using XQuery • Propose a novel approach • Automatically generate XQuery view definitions from views defined based on ORA-SS • Application of our approach • Materialized XML views • Map queries on XML views into the equivalent queries on source XML data

36. Conclusion (cont.) • Advantages of our work • The first work to employ a semantic data model for the design and query of XML views • Provides a facility to design valid XML views • Provides a fast and user-friendly approach to retrieve XML data via views • Ongoing work • XML views in the case where XML data are stored in traditional databases

37. References • S. Abiteboul, D. Quass, J. McHugh, et. al., “The lorel query language for semistructured data”, International Journal of Digital Libraries, Volume 1, No. 1, pp. 68-88, 1997. • S. Abiteboul. On views and XML. 18th ACM Symposium on Principles of Database Systems, pp. 1-9, 1999. • S. Abiteboul, S. Cluet, L. Mignet, et. al., “Active views for electronic commerce”, VLDB, pp.138-149, 1999. • S. Abiteboul, V, Aguilear, S, Ailleret, et. al., “XML repository and Active Views Demonstration”, VLDB Demo, pp.742-745, 1999. • C. Baru, A. Gupta, B. Ludaescher, et. al., “XML-Based Information Mediation with MIX”, ACM SIGMOD Demo, 1999. • M. Carey, J. Kiernan, J. hanmugasundaram, et. al., “XPERANTO: A Middleware for Publishing Object-Relational Data as XML Documents”, VLDB, pp. 646-648, 2000. • M. Carey, D. Florescu, Z. Ives, et. al., “XPERANTO: Publishing Object-Relational Data as XML”, WebDB Workshop, 2000. • Y.B. Chen, T.W. Ling, M.L. Lee, “A Case Tool for Designing XML Views”, DIWeb Workshop, 2002. • Y.B. Chen, T.W. Ling, M.L. Lee, “Designing Valid XML Views”, ER Conference, 2002 • V. Christophides, S. Cluet, J. Simeon,“On Wrapping Query Languages and Efficient XML Integration”, SIGMOD, pp. 141-152, 2000. • S. Cluet, P. Veltri, D. Vodislav, “Views in a large scale xml repository”, VLDB, pp. 271-280, 2001. • G. Dobbie, X.Y Wu, T.W Ling, M.L Lee, “ORA-SS: An Object-Relationship-Attribute Model for SemiStructured Data”, Technical Report TR21/00, School of Computing, National University of Singapore, 2000. • C. Fan, J. Funderburk, H. Lam, Et. al., “XTABLES: Bridging Relational Technology and XML”, IBM Research Report,2002. http://www7b.boulder.ibm.com/dmdd/library/techarticle/0203shekita/0203shekita.pdf • M. Fernandez, W. Tan, D. Suciu, “Efficient Evaluation of XML Middleware Queries”, ACM SIGMOD, pp. 103-114, 2001. • M. Fernandez, W. Tan, D. Suciu, “SilkRoute: Trading Between Relations and XML”, World Wide Web Conference, 1999. • J. Shanmugasundaram, E. Shekita, R. Barr, et. al., “Efficiently Publishing Relational Data as XML Documents”, VLDB, pp. 65-76, 2000. • J. Shanmugasundaram, J. Kiernan, E. Shekita, et. al., “Querying XML Views of Relational Data”, VLDB, pp. 261-270, 2001. • “XML Schema”, W3C Recommendation, 2001. http://www.w3.org/XML/Schema • “XQuery: A Query Language for XML”, W3C Working Draft, 2002. http://www.w3.org/XML/Query • “XML Path Language”, W3C Recommendation, 1999. http://www.w3.org/TR/xpath • Microsoft Corp. http://www.microsoft.com/XML. • Oracle Corp. http://www.oracle.com/XML. • IBM Corp. http://www.ibm.com/XML. • [24] I. Manolescu, D. Florescu, D. Kossmann, “Answering XML Queries over Heterogeneous Data Sources”, VLDB Conf, 2001, pp.241-25 • [25] S. Ceri, S. Comai, E. Damiani, et. al., “XML-GL: a graphical language of querying and restructuring XML documents”, WWW Conf, pp. 151-165, 1999

38. Example of vpath Back

39. FLWOR expression • For clause evaluates the expression and iterates over the items in the resulting sequence, binding the variable to each item in turn. • Let clause binds a variable to the result of its associated expression (a set of values) without iteration. • Where clause serves as a filter for the tuples of variable bindings generated by the For and Let clauses • Order by clause determine the order of the tuple stream • Return clause is evaluated once for each tuple in the tuple stream and construct the instances of the XML data. Back

40. Example swap Back