Designing Valid XML Views - PowerPoint PPT Presentation

About This Presentation
Title:

Designing Valid XML Views

Description:

For example, the following view joins project and project' together. Join operator ... In the view, the parent object class part and its child object class supplier ... – PowerPoint PPT presentation

Number of Views:69
Avg rating:3.0/5.0
Slides: 36
Provided by: iscp2
Category:
Tags: xml | designing | the | valid | view | views

less

Transcript and Presenter's Notes

Title: Designing Valid XML Views


1
Designing Valid XML Views
  • Ya Bing Chen, Tok Wang Ling, Mong Li Lee
  • Department of Computer Science
  • National University of Singapore

2
Outline
  • Introduction.
  • ORA-SS data model.
  • Designing Valid XML Views.
  • Comparison with Related Work.
  • Conclusion Future Work.

3
Introduction
4
Background
  • Introduction
  • XML views are views in XML form on top of the
    underlying data.
  • XML views enable presentation and exchange of
    data in underlying databases in XML form on the
    Internet.
  • XML views are analogous to Relational views.
  • Logical data independence.
  • Data protection.
  • Flexibility of data presentation.

5
Related Works
  • Introduction
  • ActiveViews System 2
  • Based on XML documents, the system offers a novel
    declarative view specification language to
    describe views that include the relevant data and
    activities of each different actor participating
    in electronic commerce activities.
  • the novelty is in the combination with active
    features.
  • However, the views considered here are much
    simpler than views in databases. Generally, the
    views support simple query operators such as
    selection operator.

2 S. Abiteboul, B. Amann, S. Cluet, A. Eyal, L.
Mignet, and T. Milo. Active views for electronic
commerce. In Int. Conf. on Very Large DataBases
(VLDB), Edinburgh, Scotland, pages 138-149,1999.
6
Related Works (cont.)
  • Introduction
  • Mediation of Information using XML (MIX) 4
  • MIX provides users with an integrated XML view of
    the underlying heterogeneous sources. The sources
    may be relational databases, OO databases or HTML
    files.
  • MIX uses XML DTD as the data model of XML views
    and a declarative query language called XMAS to
    define views.
  • The novelty of MIX is a graphical user interface
    that integrates browsing and querying XML views.
    It can support selection operator.
  • However, DTD is still not enough to to express
    semantics hold in XML data.
  • For example, DTD cannot distinguish whether an
    attribute belongs to an object class or a
    relationship type.

4. C. Baru, A. Gupta, B. Ludaescher, R.
Marciano, Y. Papakonstantinou, and P. Velikhov.
XML-Based Information Mediation with MIX.
ACM-SIGMOD, Philadelphia, PA, pages 597-599,
1999.
7
Our contribution
  • Introduction
  • Problems in the related works.
  • Did not support validation of XML views.
  • That is, designed views may violate implicit
    semantics.
  • Did not support more complex operators, such as
    join, projection and swap.
  • We use a systematic approach to solve the two
    problems above.
  • Transform XML documents into ORA-SS schema
    diagram.
  • Enrich the schema diagram with semantics.
  • Propose a set of rules to guide the design of
    valid XML views.

8
ORA-SS data model
9
Main Concepts
  • ORA-SS data model
  • ORA-SS Object-Relationship-Attribute Semi
    Structured data model.
  • Three main parts object class, relationship type
    and attribute.
  • An object class is similar to an element in XML
    documents.
  • A relationship type describes a relationship
    among object classes.
  • An attribute is a property of an object class or
    a relationship type.

10
An example of ORA-SS schema diagram
  • ORA-SS data model
  • An object class is represented as a labeled
    rectangle.
  • An attribute is represented as a labeled circle.
  • A key attribute is represented as a filled
    circle.
  • Attributes of relationship type have labels on
    their incoming edges, while attributes of object
    class do not have.
  • A relationship type is described by name, n, p,
    c.
  • Name denotes the name of the relationship type.
  • n is the degree of the relationship type.
  • p is the participation constraint of the parent
    object class in the relationship type.
  • c is the participation constraint of the child
    object class in the relationship type.

11
Designing Valid XML Views
12
An introduction
  • Designing valid XML views
  • Before designing valid XML views, we have two
    pre-process steps
  • Transforming XML into ORA-SS
  • Semantic enriching ORA-SS
  • Based on the enriched ORA-SS schema diagram, we
    begin to design XML views.
  • Four operators can be applied to the XML views
    selection, projection, join and swap.
  • The first three operators are similar to
    selection, projection and join in relational
    databases.
  • The fourth operator exchanges the positions of
    parent and child object classes.

13
Selection operator
  • Designing valid XML views
  • A selection operator filters data by using
    predicates.
  • For example, we design a view that depicts
    projects for which there exist suppliers for
    which there exist parts with a price 80.

Selection operator
14
Selection operator (cont.)
  • Designing valid XML views
  • Features of selection operator
  • Selection operator put predicates on the source
    schema to filter data.
  • They do not restructure the source schema.
  • The resulting view schema contains the conditions
    specified in the selection operator.

15
Projection operator
  • Designing valid XML views
  • projection operator selects or drops object
    classes or attributes in the source schema. the
    source semantics may be affected.
  • For example, the following view drops the object
    class supplier and its attributes.

Projection operator
16
Projection operator (cont.)
  • Designing valid XML views
  • Several changes in the view schema.
  • The attribute sno has been dropped with supplier.
  • The relationship types js, spj and sp have been
    dropped.
  • The attribute price has been mapped into an
    aggregate attribute, e. g, avg_price, which
    represents the average price of each part in a
    given project.
  • The attribute qty has been dropped.
  • The example shows flexible views can be designed
    based on ORA-SS with its additional semantics.
  • However, we need to handle the views properly so
    that semantics will not be violated.

17
Projection operator (cont.)
  • Designing valid XML views
  • The rules for applying projection operators.
  • Rule Proj1.
  • If an object class has been dropped, its
    attributes must be dropped too.
  • Rule Proj2.
  • If an object class has been dropped, all
    relationship types containing the object class
    must be dropped too. The attributes of these
    relationship types must be dropped, or mapped
    into attributes with some aggregate function,
    such as avg, max/min or sum, or mapped into
    attributes typed in bag of values if they cannot
    be aggregated.
  • Based on the rules, the views designed are
    guaranteed to be valid when projection operators
    are applied.

18
Join operator
  • Designing valid XML views
  • Join operator joins two object classes and their
    attributes together by key-foreign key reference.
  • For example, the following view joins project and
    project together.

Join operator
19
Join operator (cont.)
  • Designing valid XML views
  • In the view, the attributes jno and jname of
    project are selected and placed below the object
    class project.
  • However, the attribute progress is dropped
    because it belongs to the relationship type mj,
    which does not exist in the view.
  • Actually, the attribute progress can also be
    mapped into an attribute typed in bag of values
    if users want.

20
Join operator (cont.)
  • Designing valid XML views
  • The rules for applying join operators
  • Rule Join1
  • when a join operator is applied to two object
    classes, if there are relationship types below
    the referenced object class that contain object
    classes above the referenced object class, then
    these relationship types must be dropped.
  • The attributes of these relationship types must
    be dropped too, mapped into attributes with some
    aggregate function or mapped into attributes
    typed in bag of values if they cannot be
    aggregated.

21
Join operator (cont.)
  • Designing valid XML views
  • The rules for applying join operators
  • Rule Join2
  • When a join operator is applied to two object
    classes, if there are relationship types below
    the referenced object class that do not contain
    any object classes above the referenced object
    class, then these relationship types can be
    selected or dropped in the view according to the
    users requirement.
  • The attributes of these relationship types can be
    selected or dropped too according to the users
    requirement.

22
Swap operator
  • Designing valid XML views
  • Swap operator exchanges the positions of a
    parent object class and one of its child object
    class.
  • For example, the following view swaps supplier
    and part.

Swap operator
23
Swap operator (cont.)
  • Designing valid XML views
  • In the view, the parent object class part and its
    child object class supplier are swapped, and the
    attribute sno moves with its object class
    supplier.
  • However, the attribute price does not move with
    supplier. Because price is an attribute of the
    relationship type sp, it stays below the new
    lowest object class (part) of sp in the view.
  • Similarly, since the attribute qty belongs to the
    relationship type spj, it also stays below the
    lowest object class (part) of spj.

24
Swap operator (cont.)
  • Designing valid XML views
  • The rules for applying swap operators.
  • Rule Swap1 If two object classes are swapped in
    the view, then the attributes of each of the
    object classes must stay with the object class.
  • Rule Swap2 If two object classes are swapped in
    the view, then the attributes of relationship
    types involving the two object classes must stay
    below the lowest participating object class in
    the relationship types.

25
Views on schema with IDD relationship
  • Designing valid XML views
  • IDentifier Dependency Relationship (IDD)
  • Definition1. An object class A is said to be ID
    Dependent (IDD) on its parent object class B if A
    does not have its own identifier attributes, and
    an A object can only be identified by its
    parents key value (say k1) together with some of
    its own attributes (say k2). That is, the key of
    A is k1, k2. The relationship type between A
    and B is then called IDD relationship type.

26
Views on schema with IDD relationship (cont.)
  • Designing valid XML views
  • If projection, join and swap operators are
    applied on IDD relationship, rules need to be
    modified.
  • For example, we design a view that swaps employee
    and child.
  • In the view, the key attribute of employee eno
    is added under the object class child so that
    eno, cname becomes a composite key for child.

swap operator
27
Views on schema with IDD relationship (cont.)
  • Designing valid XML views
  • The rules for IDD relationship.
  • Rule Proj_IDD. If a parent object class of an IDD
    relationship is dropped in the view, then its key
    attribute must be added to the child object class
    to construct a key for the child.
  • Rule Join_IDD. If an child object class an IDD
    relationship type is referenced by another object
    class in the source schema in the view, then the
    key attribute of the parent object class must be
    added to the child to construct a key for the
    child.
  • Rule Swap_IDD. If two object classes of an IDD
    relationship type are swapped in the view, then
    the key attribute of the parent object class must
    be added to the child object class to construct a
    key for the child.

28
View validation algorithm
  • Designing valid XML views
  • All given rules are integrated into an algorithm
    to validate XML views.
  • The algorithm monitors the process of designing
    view until the view is completely designed.
  • According to different operators, the algorithm
    uses corresponding rules to modify view schema to
    keep it valid.
  • Once an operator is applied to the view, the
    algorithm first checks whether IDD relationship
    type is involved and applies rules for it.
  • Then the algorithm applies the normal rules for
    the operator.

29
Comparison with Related Work
30
Comparison with related work
31
Conclusion Future Work
32
Conclusion
  • We proposed a systematic approach for valid XML
    views design.
  • Transform an XML document into an ORA-SS schema
    diagram.
  • Enrich the ORA-SS schema diagram with additional
    semantics.
  • Develop a set of rules to guide the design of
    valid XML views.
  • The approach guarantees validity of XML views
  • and it supports four operators, i.e., selection,
    projection, join and swap operator.
  • The approach also handles IDD relationships.

33
Future work
  • View definition generation.
  • Generate the view definition in XQuery from the
    graphical view schema that has been designed.
  • Query rewriting.
  • Rewrite queries on views into queries on source
    data.
  • View update.
  • Which views are updateable and which are not.
  • How to update those updateable views.

34
QA
35
References
  • 1. S. Abiteboul. On views and XML. In Proceedings
    of the Eighteenth ACM Symposium on Principles of
    Database Systems, ACM Press, pages 1-9, 1999.
  • 2. S. Abiteboul, B. Amann, S. Cluet, A. Eyal, L.
    Mignet, and T. Milo. Active views for electronic
    commerce. In Int. Conf. on Very Large DataBases
    (VLDB), Edinburgh, Scotland, pages 138-149,1999.
  • 3. S. Abiteboul, D. Quass, J. McHugh, J.Widom,
    and J. L. Wiener. The lorel query language for
    semistructured data. International Journal of
    Digital Libraries, Volume 1, No. 1, pages 68-88,
    1997.
  • 4. C. Baru, A. Gupta, B. Ludaescher, R. Marciano,
    Y. Papakonstantinou, and P. Velikhov. XML-Based
    Information Mediation with MIX. ACM-SIGMOD,
    Philadelphia, PA, pages 597-599, 1999.
  • 5. Gillian Dobbie, Xiaoying Wu, Tok Wang Ling,
    Mong Li Lee. ORA-SS An Object-Relationship-Attrib
    ute Model for Semi-Structured Data. Technical
    Report TR21/00, School of Computing, National
    University of Singapore, 2000.
  • 6. Tok Wang Ling, Mong Li Lee, Gillian Dobbie.
    Application of ORA-SS An Object-Relationship-Attr
    ibute Model for Semi-Structured Data. In
    Proceedings of the Third Interna-tional
    Conference on Information Integration and
    Web-based Applications Services (IIWAS), Linz,
    Austria, 2001.
  • 7. http//www.w3.org/TR/xquery.
  • 8. http//www.w3.org/XML/Schema.
Write a Comment
User Comments (0)
About PowerShow.com