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
1
Outline





Introduction
ORA-SS Data Model
Motivating Example
Generation of XQuery View Definitions
Conclusion
2
Part 1. Introduction
3
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
4
Related Works

SilkRoute [14]



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]



Export relational data into XML
Complex – two different languages to define and query XML views over
relational data respectively
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
5
Related works

Major commercial databases

Oracle 9i [22]


Microsoft SQL Server [21]


Export relational data to materialized XML views using
SQLX, XSQL or XML SQL Utility (XSU)
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
6
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
7
Part 2. ORA-SS Data
Model
8
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,.
s upplier
s p , 2, 1:n ,
1 :n
s no s nam e
part
sp
s p j,3,1:n ,1:n
pno pnam e pric e
projec t
s pj
jno jnam e
qty
A O R A -S S s c he ma diag r am
9
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
10
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
11
Part 3. Motivating
Example
12
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>
part
s upplier
s p,
s p, 2 ,
2 , 1 :n , 1 :n
s no
swap
part
pric e
Fig ur e 6 . The O R A -S S S our c e S c he ma
Figure 5. A source XML file
pno
s upplier
sp
pno
1 :n , 1 :n
sp
s no
pric e
Fig ur e 7 . The O R A -S S V ie w S c he ma
applie d with a s wap ope r ator
13
Motivating example (cont.)
s upplier
sup p lie r
sno:
s no:
s 002
s001
part
pno: pric e:
p001 100
swap
part
pno:
p002
part
pric e:
120
pno:
p002
pric e:
40
part
pno:
p003
pric e:
30
Fig ur e 8 . The O R A -S S in s tanc e diag r am for s our c e s c he ma in Fig ur e 6
part
pno:
p001
part
part
pno:
p002
sup p lie r
s no: pric e:
s 001 100
s upplier
s no: pric e:
s 001 120
Instance
diagrams
s upplier
s no:
s 002
pric e:
40
pno:
p003
s no:
s 002
s upplier
pric e:
30
Fig ur e 9 . The O R A -S S ins tanc e diag r am for vie w s c h e ma in Fig ur e 7
•Swap operator will keep the relationship set’s attributes in the current position
•For each part, we retrieve all suppliers that supply this part
14
Motivating example (cont.)

User can write the XQuery expression for the view.
part
s upplier
s p , 2 , 1 :n , 1 :n
s p , 2 , 1 :n , 1 :n
s no
swap
pno
s upplier
part
sp
pno
pric e
Fig ur e 6 . The O R A -S S S our c e S c he ma

sp
s no
pric e
Fig ur e 7 . The O R A -S S V ie w S c he ma
applie d with a s wap ope r ator
User need to know price
is an attribute of
relationship type sp
1. let $pno_set := distinct-values([email protected])
2. let $sno_set := distinct-values([email protected])
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::[email protected]=$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>
Figure 10. XQuery expression for the view
15
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
16
Part 4. Generation of
XQuery View Definitions
Main ideas
 Analyzing vpath
 Generate where conditions

17
Main ideas
Generate query expression of each object
class in an ORA-SS view
1.
•
•
2.
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
18
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.
19
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 vpath of
o may influence the values of o in the view.
20
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.
 Example
Back to Rules for Type I
 Type II: originate from the descendants of o’s ancestors in
the source schema.
 Example
Back 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.
 Example
Back to Rules for Type III
21
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
$in
vo
vo_no
o
s ou rce
o_no
Exam ple s ch e m a
22
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
$in
vo
vo
vo_no
vo_no
o
o
s ou rce
let $ono_set := distinct-values([email protected]_no)
for $o_no in $ono_set
where some $vo1 in $in//vo satisfies (
exists( $vo1[@vo_no=$vo_no]) and
exists($vo1[descendant::[email protected]_no=$o_no]) )
o_no
vie w
o_no
Figu re 12(a). Th e cas e for R u le Type I _A
Figure 12(b). Where condition generated for o in Rule Type I_A
23
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
$in
vo
o
o_no
o
vo
s ou rce
vo_no
let $ono_set := distinct-values([email protected]_no)
for $o_no in $ono_set
where some $vo1 in $in//vo satisfies (
exists( $vo1[@vo_no=$vo_no]) and
exists($vo1[ancestor::[email protected]_no=$o_no]) )
vo_no
vie w
o_no
Figu re 13(a). Th e cas e for R u le Type I _B
Figure 13(b). Where condition generated for o in Rule Type I_B
24
Rules for Type II object class

Rule Type II_A
$in
(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.
LCA
LCA
vo
vo
o
o
s ou rce
vie w
Fig u r e 1 4 (a). Th e c as e for R ule Type II_ A
LCA 2
LCA 1
vo 1
o1
vo 2
o2
LCA 1
LCA 2
vo 1
vo 2
o1
o2
s o urc e ins tanc e
vie w in s tan ce
Fig u r e 1 4 (b). Th e in s tanc e c as e for R u le Type II_ A
25
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.
$in
LCA
vo
vo_no
vo
vo_no
o
s ou rce
o
o_no
vie w
F ig ure 1 5 (a). T he c as e fo r R ule T ype II_ B
let $ono_set := distinct-values([email protected]_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]) )
o_no
Figure 15(b). Where condition generated for o in Rule Type II_B
26
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
$in2
$in1
vo
referenc ed
o
o_no
r_no
referenc ing
referenc ing
vo
vo_no
vo_no
s ou rce
o
r_no
o_no
vie w
F ig ure 1 6 . T he c as e fo r rule type III_ A
27
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
$in1
$in2
vo
o (referen cin g )
referenc ed
vo_no
o_no
r_no
o (referen cin g)
vo
vo_no
let $ono_set := distinct-values([email protected]_no)
for $o_no in $ono_set
where some $referenced in $in1//referenced satisfies (
exists($referenced[@r_no=$o_no]) and
exists($referenced[descendant::[email protected]_no=$vo_no]) )
source
o_no
Figure 18(a). The case for rule type III_B
vie w
Figure 18(b). Where condition generated for o in Rule Type III_B
28
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


$in2
$in1
referenced
o_no vo_no
r_no
referencing
vo
source
vo_no
vo
o
r_no o_no
Figure 17(a). The case for rule type III_C
o
let $ono_set := distinct-values([email protected]_no)
for $o_no in $ono_set
where some $referenced in $in1//referenced satisfies (
exists($referenced[descendant::[email protected]_no=$vo_no]) )
and some $referencing in $in2//referencing satisfies (
exists($referencing[@[email protected]_no]) and
exists($referencing[ancestor::[email protected]_no=$o_no]) )
view
Figure 17(b). Where condition generated for o in Rule Type III_C29
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

$in1
$in2
referencing
referenced
vo
vo_no
vo_no
r_no
r_no
vo
source o_no
o
o
o_no
let $ono_set := distinct-values([email protected]_no)
for $o_no in $ono_set
where some $referenced in $in1//referenced satisfies (
exists($referenced[descendant::[email protected]_no=$vo_no]) )
and some $referencing in $in2//referencing satisfies (
exists($referencing[@[email protected]_no]) and
exists($referencing[descendant::[email protected]_no=$o_no]) )
view
Figure 19(a). The case for Rule Type III_D
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.
30
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
31
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
1.
2
for each object class o in the view{
generate a let clause:
“let $ono_set := distinct-alues([email protected]_no)”
3
}
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: “{“
8 Generate_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
32
Algorithm
Generate_Objectclass_Definition
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 {
16.
generate a where condition for all the operators in
the where clause;
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([email protected])>”
// 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([email protected])}”
22. }
23. if o has 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. }
17.}
33
Figure 21. Algorithm to generate object class definition
Part 5. Conclusion
34
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
35
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
36
References
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
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
37
Example of vpath
So ur c e sc h e m a 1
So ur c e sc h e m a 2
Vp a t h o f O
T ype I
B
A
F
P
B
...
T ype II
C
J
K
L
E
D
K
T y pe III
H
O
...
J
O
G
M
N
...
P
T ype I
Fig u re 1 1 (a ). Two s im plifie d O R A -S S s o u rce s ch e m a
Fig u re 1 1 (b). A n s im plifie d O R A -S S
v ie w s ch e m a
Back
38
FLWOR expression
i.
ii.
iii.
iv.
v.
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
39
Example
part
s upplier
s p , 2, 1:n , 1 :n
s p , 2, 1:n , 1 :n
s no
swap
pno
s upplier
part
sp
pno
sp
s no
pric e
S our c e S c he ma
pric e
V ie w S c he ma
Back
40
Descargar

Automatic Generation of XQuery View Definitions from …