Yuan Fa, Yabing Chen, Tok Wang Ling, Ting Chen

1
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)

2
AGENDA

• Background of
• Materialized View Maintenance
• ORA-SS Data Model
• XML View
• Incremental XML View Maintenance
• Related Works
• Conclusion

3

• Background

4
INTRODUCTION TO VIEW

• Views
• Relational View
• XML View
• Materialized Views
• Maintain the Materialized Views
• Re-computation
• Incremental approach

5
OVERVIEW OF ARCHITECTURE
d
Updated Materialized View
Materialized View
f
f
d
Updated Data source
Data source
d changes on the source data f function to
compute the view content from scratch d
changes on the view
6
INCREMENTAL APPROACH

• 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

7
XML VIEW MAINTENANCE

• Whats important for incremental XML view
  maintenance?
• Good XML data model to define flexible views with
  swap, join and aggregations
• Efficient incremental view maintenance method

8
Contributions

• XML view
• Defined view with swap, join and aggregation
  using ORA-SS
• Extend the XML view transformation to support the
  flexible views
• 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

9

• ORA-SS DATA MODEL

10
ORA-SS DATA MODEL

• Object-Relationship-Attribute model for
  Semi-Structured data 4
• Basic concepts
• object classes
• relationship types
• Attributes
• Captures rich semantic information

11
ORA-SS Object Class

• Represented as a labeled rectangle
• Attributes are labeled circles connected to the
  object class by edges

12
ORA-SS Relationship Type

• represented as a labeled edge
• label (name, n, p, c)
• name relationship name
• n degree
• p parent participation constraint
• c child participation constraint

13
ORA-SS Attribute

• represented as a labeled circle
• distinguish object attributes and relationship
  attributes

14
Source XML Document DOC1 - SPJ

• ltdoc1gt
• ltsupplier snos1, snamesn1gt
• ltpart pnop1, pnamepn1gt
• ltproject jnoj1, jnamejn1gt
• ltquantitygt 15 lt/quantitygt
• lt/projectgt
• lt/partgt
• lt/suppliergt
• ltsupplier snos2, snamesn2gt
• ltpart pnop1, pnamepn1gt
• ltproject jnoj1, jnamejn1gt
• ltquantitygt 20 lt/quantitygt
• lt/projectgt
• ltproject jnoj2, jnamejn2gt
• ltquantitygt 10lt/quantitygt
• lt/projectgt
• lt/partgt
• lt/suppliergt
• ltsupplier snos3, snamesn3gt

15
ORA-SS Schema Diagram of DOC1
16
Source XML Document DOC2 - JD

• ltdoc2gt
• ltproject jnoj1, jnamejn1gt
• ltdepartment dnod1, dnamedn1gt
• lt/departmentgt
• lt/projectgt
• ltproject jnoj2, jnamejn2gt
• ltdepartment dnod2, dnamedn2gt
• lt/departmentgt
• lt/projectgt
• ltproject jnoj3, jnamejn3gt
• ltdepartment dnod2, dnamedn2gt
• lt/departmentgt
• lt/projectgt
• lt/doc2gt

17
ORA-SS Schema Diagram of DOC2
18
ORA-SS Summary

• A semantically rich, labeled and directed graph
  schema
• 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

19

• XML VIEW

20
XML VIEW DEFINITION

• View is defined using ORA-SS schema diagram
• Selection
• Projection
• Swap
• Join
• Aggregation

21
XML VIEW EXAMPLE

• The view shows information of project of
  department dn1, part of each project
• Object class supplier is dropped from the source
  schema 1.
• part and project are swapped.
• A new relationship type jp is created between
  project and part.
• 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.

22
XML VIEW EXAMPLE (cont.)
23
XML VIEW MATERIALIZATION

• Materialized view
• View is materialized by using view transformation
  technique
• 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
• 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

24
XML Extended XML View Materialization Outline

• Projection (on object type or relationship type)
• It selects instances of object classes and
  relationship types from the source XML documents
• 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
• Join (different object classes)
• It joins the elements with the same name and key
  attributes together from different source XML
  documents
• Aggregation (on attributes)
• It applies the aggregation function to the values
  of aggregate attribute if there is an aggregation
  function associated with the attribute

25
XML Materialized View EXAMPLE
26

• VIEW MAINTENANCE

27
Incremental Materialized XML View Maintenance
Outline

• Obtain the source update tree according to the
  update specification and the source document and
  source schema
• 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
• Generate the view update tree, which contains the
  update information to the view
• Merge the view update tree into the view to
  produce the completed updated materialized view

28
SOURCE UPDATE TREE EXAMPLE

• Source Update
• Suppose supplier s3 is going to supply part p1 to
  project j1 with a quantity of 10.
• This will insert part p1 with child project j1 as
  the child element of supplier s3 in the source
  XML doc1
• The source update tree in this case is shown in
  next page, which contains the path from supplier
  s3 to project j1

29
SOURCE UPDATE TREE EXAMPLE (cont.)
30
Check Source Update Tree Relevance

• Benefit
• Avoid generating and evaluating unnecessary
  maintenance statements
• 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

31
Check Source Update Tree Relevance (CONT.)

• 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

32
Generate View Update Tree

• 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
• 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)

33
SAMPLE VIEW UPDATE TREE
34
Merge View Update Tree

• After the view update tree is computed, we are
  going to merge the change into the materialized
  view
• We merge each path in the view update tree one by
  one
• Insertion
• Deletion
• Modification
• Handling aggregation

35
Updated Materialized View
36

• RELATED WORKS

37
Related Works

• 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

38
Related Works (cont.)

• 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 semi-structured 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

39
Related Works Comparison

• 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
• Our work addresses the above issues

40

• CONCLUSION

41
CONCLUSION

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

42
FUTURE WORK

• 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
• Implement XML order support
• Storing order information in the source update
  tree

43
REFERENCES

• 1.S. Abiteboul, D. Quass, J. McHugh, J. Widom,
  and J. Wiener. The Lorel Query Language for
  Semistructured Data. Journal of Digital
  Libraries, 1(1), Nov. 1996.
• 2.S. Abiteboul, J. McHugh, 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 9th 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
  TR21/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 11th
  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 227-238, Bombay, India,
  September 1996.
• 7.Y. Zhuge and H. Garcia-Molina. Graph Structured
  Views and Their Incremental Maintenance. In
  Proceedings of the 14th International Conference
  on Data Engineering (DE), 1998.
• 8.World Wide Web Consortium, XQuery A Query
  Language for XML, W3C Working Draft, 2002.
  http//www.w3.org/XML/Query

44
THANKS FOR YOUR ATTENTION