MATERIALIZED VIEW MAINTENANCE FOR THE XML DOCUMENTS Yuan

MATERIALIZED VIEW MAINTENANCE FOR THE XML DOCUMENTS Yuan Fa, Yabing Chen, Tok Wang Ling, Ting Chen National University of Singapore Presenter: Qing Li (City University of Hong Kong) Kong 1

AGENDA q. Background of Materialized View Maintenance q. ORA-SS Data Model q. XML View q. Incremental XML View Maintenance q. Related Works q. Conclusion 2

Background 3

INTRODUCTION TO VIEW q. Views § Relational View § XML View q. Materialized Views q. Maintain the Materialized Views § Re-computation § Incremental approach 4

OVERVIEW OF ARCHITECTURE Materialized View δ’ f f δ Data source Updated Materialized View Updated Data source δ: changes on the source data f: function to compute the view content from scratch δ’: changes on the view 5

INCREMENTAL APPROACH q. Why choose incremental approach? § Re-computing the materialized view from scratch is usually too costly when only a part of the materialized view needs to be changed § The incremental approach will absorb incoming updates and incrementally modify the materialized views without halting query processing. We prefer the incremental approach 6

XML VIEW MAINTENANCE q. What’s important for incremental XML view maintenance? § Good XML data model to define flexible views with swap, join and aggregations § Efficient incremental view maintenance method 7

Contributions q XML view § Defined view with swap, join and aggregation using ORA-SS § Extend the XML view transformation to support the flexible views q Materialized view maintenance for XML documents § Developed relevance checking process for each source XML update. Those update without affecting the view will be detected § Developed incremental method to maintain the view with swap, join and aggregation 8

ORA-SS DATA MODEL 9

ORA-SS DATA MODEL q. Object-Relationship-Attribute model for Semi. Structured data [4] q. Basic concepts: § § § object classes relationship types Attributes q. Captures rich semantic information 10

ORA-SS : Object Class q. Represented as a labeled rectangle q. Attributes are labeled circles connected to the object class by edges 11

ORA-SS : Relationship Type q represented as a labeled edge q label: (name, n, p, c) § § § name: relationship name n: degree p: parent participation constraint § c: child participation constraint 12

ORA-SS : Attribute qrepresented as a labeled circle qdistinguish object attributes and relationship attributes 13

Source XML Document DOC 1 - SPJ <doc 1> <supplier sno=“s 1”, sname=“sn 1”> <part pno=“p 1”, pname=“pn 1”> <project jno=“j 1”, jname=“jn 1”> <quantity> 15 </quantity> </project> </part> </supplier> <supplier sno=“s 2”, sname=“sn 2”> <part pno=“p 1”, pname=“pn 1”> <project jno=“j 1”, jname=“jn 1”> <quantity> 20 </quantity> </project> <project jno=“j 2”, jname=“jn 2”> <quantity> 10</quantity> </project> </part> </supplier> <supplier sno=“s 3”, sname=“sn 3”> <part pno=“p 2”, pname=“pn 2”> <project jno=“j 1”, jname=“jn 1”> <quantity> 30 </quantity> </project> </part> </supplier> </doc 1> 14

ORA-SS Schema Diagram of DOC 1 15

Source XML Document DOC 2 - JD <doc 2> <project jno=“j 1”, jname=“jn 1”> <department dno=“d 1”, dname=“dn 1”> </department> </project> <project jno=“j 2”, jname=“jn 2”> <department dno=“d 2”, dname=“dn 2”> </department> </project> <project jno=“j 3”, jname=“jn 3”> <department dno=“d 2”, dname=“dn 2”> </department> </project> </doc 2> 16

ORA-SS Schema Diagram of DOC 2 17

ORA-SS : Summary q. A semantically rich, labeled and directed graph schema q. Captures much semantic information § § § distinguish attributes from object classes express the degree of relationship types specify the participation constraints on the object classes in a relationship type § distinguish object attributes and relationship attributes 18

XML VIEW 19

XML VIEW DEFINITION q. View is defined using ORA-SS schema diagram q. Selection q. Projection q. Swap q. Join q. Aggregation 20

XML VIEW EXAMPLE q The view shows information of project of department dn 1, part of each project q Object class supplier is dropped from the source schema 1. q part and project are swapped. q A new relationship type jp is created between project and part. q A new attribute called total_quantity is created for jp, which is the sum of quantity of a specific part that the suppliers are supplying for the project. 21

XML VIEW EXAMPLE (cont. ) 22

XML VIEW MATERIALIZATION q Materialized view § View is materialized by using view transformation technique q Previous Work § Daofeng Luo, Ting Chen, Tok Wang Ling, and Xiaofeng Meng. On View Transformation Support for a Native DBMS. DASFAA 2004, pages 226 -231, Jeju Island, Korea, March 2004 § It can perform accurate and efficient view transformation based on ORA-SS. But the method is only transforming a single source ORA-SS schema to a view schema q Our Extended Work § Here we enrich the method to handle the complex views which can be over multiple source XML schemas, have selection conditions, and have aggregation functions 23

XML Extended XML View Materialization Outline q Projection (on object type or relationship type) § It selects instances of object classes and relationship types from the source XML documents q Selection (on attribute of object class or relationship type) § It prunes the instances retrieved from Projection Procedure by checking the selection conditions in the view schema q Join (different object classes) § It joins the elements with the same name and key attributes together from different source XML documents q Aggregation (on attributes) § It applies the aggregation function to the values of aggregate attribute if there is an aggregation function associated with the attribute 24

XML Materialized View EXAMPLE 25

VIEW MAINTENANCE 26

Incremental Materialized XML View Maintenance Outline q Obtain the source update tree according to the update specification and the source document and source schema q Check the relevance of the source update to see whether the update will affect the view. If the source update is relevant, we proceed to step 3, otherwise we stop here q Generate the view update tree, which contains the update information to the view q Merge the view update tree into the view to produce the completed updated materialized view 27

SOURCE UPDATE TREE EXAMPLE q. Source Update § Suppose supplier s 3 is going to supply part p 1 to project j 1 with a quantity of 10. § This will insert part p 1 with child project j 1 as the child element of supplier s 3 in the source XML doc 1 § The source update tree in this case is shown in next page, which contains the path from supplier s 3 to project j 1 28

SOURCE UPDATE TREE EXAMPLE (cont. ) 29

Check Source Update Tree Relevance q Benefit § Avoid generating and evaluating unnecessary maintenance statements q Insertion/Deletion § [STEP 1] Check whether the object classes or relationship types in the source update tree are in the view schema § Require to query schema only § [STEP 2] Check whether each path in the source update tree satisfies the selection conditions in the view schema § Require to query schema using source update tree § [STEP 3] Check whether each path in the source update tree joins with any source XML documents § Require to query schema, source update tree and source XML documents 30

Check Source Update Tree Relevance (CONT. ) q. Modification § [STEP 1] Check whether the modified attribute appears in the view schema § Require to query schema only § [STEP 2] Check whether the new and old modified values satisfy the selection condition § Require to query schema using source update tree 31

Generate View Update Tree q. Almost same process as view materialization § One exception is the source update tree is used as an input instead of the updated source XML document itself q. General Process: § Projection (on object type or relationship type) § Selection (on attribute of object class or relationship type) § Join (different object classes) § Aggregation (on attributes) 32

SAMPLE VIEW UPDATE TREE 33

Merge View Update Tree q. After the view update tree is computed, we are going to merge the change into the materialized view q. We merge each path in the view update tree one by one § Insertion § Deletion § Modification q. Handling aggregation 34

Updated Materialized View 35

RELATED WORKS 36

Related Works q Abiteboul, et. al. “Incremental Maintenance for Materialized Views over Semistructured Data”, VLDB 98’ § The work supposes that the updates are identified by Object IDs. § Updates are restricted to single element/attribute update § Updates to XML documents may be subtrees and in this case the OIDs are unlikely to be available § The work handles the view which is the portion of the source semi-structured data § The complex views with swap of XML elements in the hierarchy cannot be handled 37

Related Works (cont. ) q Zhuge, et. al. “Graph Structured Views and Their Incremental Maintenance”, ICDE 98’ § The view is to retrieve a set of specific objects with their children from the source semi-structured data § That means the only hierarchical structure in the view is a binary relationship, and the view only have the set of objects and their children which are originally in the source semistructured data and satisfying the view specification § Only the parent-child relationship needs to be checked with the view definition to determine whether the updated element affect the view 38

Related Works Comparison q. Existing Works § Updates are limited to atomic value update § any single insertion/deletion/change of atomic values causes view maintenance process § Views with swap, join and aggregation are not addressed q. Our work addresses the above issues 39

CONCLUSION 40

CONCLUSION q. Extended the XML view transformation to support the flexible views with swap, join, aggregation q. Proposed a new incremental view maintenance method for XML documents § Flexible views with swap, join, aggregation can be handled 41

FUTURE WORK q Transaction Update § To handle transaction, we will enable multiple changes to be specified in one single update tree. Thus, the view update tree can be derived together at one time § All the updates with counter effects need to be removed q Implement XML order support § Storing order information in the source update tree 42

REFERENCES • 1. S. Abiteboul, D. Quass, J. Mc. Hugh, J. Widom, and J. Wiener. The Lorel Query Language for Semistructured Data. Journal of Digital Libraries, 1(1), Nov. 1996. • 2. S. Abiteboul, J. Mc. Hugh, M. Rys, V. Vassalos, and J. Wiener. Incremental Maintenance for Materialized Views over Semistructured Data. In VLDB, pages 38 -49, 1998. • 3. D. Luo, T. Chen, T. W. Ling, and X. Meng. On View Transformation Support for a Native XML DBMS. In 9 th International Conference on Database Systems for Advanced Applications, Korea, March 2004. • 4. G. Dobbie, X. Y. Wu, T. W. Ling, M. L. Lee. ORA-SS: An Object – Relationship - Attribute Model for Semistructured Data. Technical Report TR 21/00, School of Computing, National University of Singapore, 2000. • 5. Y. Papakonstantinou, H. Garcia-Molina, and J. Widom. Object Exchange across Heterogeneous Information Sources. In Proceedings of the 11 th International Conference on Data Engineering, pages 251 -260, Taipei, Taiwan, Mar. 1995. • 6. D. Suciu. Query Decomposition and View Maintenance for Query Language for Unstructured Data. In VLDB, pages 227238, Bombay, India, September 1996. • 7. Y. Zhuge and H. Garcia-Molina. Graph Structured Views and Their Incremental Maintenance. In Proceedings of the 14 th International Conference on Data Engineering (DE), 1998. • 8. World Wide Web Consortium, “XQuery: A Query Language for XML”, W 3 C Working Draft, 2002. http: //www. w 3. org/XML/Query 43

THANKS FOR YOUR ATTENTION 44