1. OrientX: an Integrated, Schema-Based Native XML Database System
Meng Xiaofeng, Wang Xiaofeng, Xie Min, Zhang Xin, Zhou Junfeng
School of information, Renmin University of China
WISA2006

2. Introduction OrientX means: Original RUC IDKE Native XML Database
RUC: Renmin University of China
IDKE: Institute of Data and Knowledge
Engineering
Native XML DataBase: Exposing a logical model
of storing and retrieving XML documents.
(non Native XML DataBase: for example, based on relation database)

3. Outline Architecture and Features Storage and data management
Indexing Schema
Query processing
Conclusion and Future Work

4. Architecture This picture is the architecture of our system,
Index manager model: construct index and access index.
Execute engine are take charge of importing and exporting xml document, executing xquery and Xpath.
Xml Schema describe the xml document, also put some restrict on xml documents.

5. Features Full support to XML Schema
Supporting XQuery1.0 and XPath2.0 Data Model
Various native storage techniques
Path index and value index
Multi-Query Processing strategies based on native storage.
System can get full information from xml schema, and it can used to index, validation of XQuery and so on.
Four storage strategies in our system, cluster or non cluster.
Two different index.
One is navigation and another is based on xml algebra.

6. Outline Architecture and Features Storage and data management
Indexing Schema
Query processing
Conclusion and Future Work

7. Different storage granularities
Document:
do not decompose the document, build index on it to direct the structure.
Query complexity and efficiency are restricted by the power of index.
Sub tree:
decompose the document into sub trees according to storage space partition.
Persistent the structure in the tree.
save space
Node:
decompose the document into nodes sequence , each node corresponding to a type (element, attribute, …).
May use too many links to persistent relation between nodes
Document: for example: store xml document on relation database as a type blob.
Sub tree: the size of sub tree often as close to physics page size as possible..
Node : one node is a record.

8. Storage Techniques in OrientX
Element-based
SubTree-based
Document-based
Depth-first
DEB
DSB DB
Broad-first
BEB
BSB
Clustered
CEB
CSB
Horizontal is the granularity
Vertical is the methods of traverse xml tree.
Like DEB, but each record
is a sub-tree. The size of sub
tree is close to physical
page size
One node is a record,
through preorder traversing
tree
One element is a record, but
all node with the same tag
name will be clustered-stored.
Akin to DSB, each record is
a sub tree. But all sub trees
with the same structure are
clustered store.
Implemented techniques are marked in red

9. Example-- Element based
DEB
CEB r t1 a1 a2 r t1 l1 f1 a1 l2 f2 a2 l1 f1 l2 f2
DEB: preorder traverse tree and stored it when element end.
CEB: like DEB, but all element with the same tag name clustered store.
Source doc r t1 l1 l2 f1 f2 a1 a2

10. Example-- Subtree based
Proxy node (virtual node) t1 a1 a2 f2 l1 f1 l2
Also have Proxy node
DOC r r t1 a1 a2 t1 a1 a2
left picture: preorder traverse tree, and if the sub-tree size near physics page size, then generate a record to store this sub-tree.
right picture: base on schema will divide document tree to many sub-tree. and the sub-tree with the same structure clustered store.
Left picture: suppose every physical page’s capacity is 5 nodes, In a depth-first traversal, (t1, l1, f1, a1) are the first four encountered nodes, generate a sub-tree containing them with a virtual root (grey) as they are not in the same sub-tree. And then, the left four nodes (l2, f2, a2, r) form another sub-tree without virtual root as they are in the same tree rooted at (r).
Right picture: in this XML tree, node of type [a] can occur multi-times under node (r), and a has descendants, so sub-tree rooted at node of type [a] are treated as storage sub-tree element, and document root (r) is another sub-tree root. Notice that nodes (a1, a2) occurred twice in CSB. l1 f1 l2 f2 l1 f1 l2 f2
DSB(Depth-first sub-tree based)
CSB (clustered sub-tree based)

11. Outline Architecture and Features Storage and data management
Indexing Schema
Query processing
Conclusion and Future Work

12. SUPEX: Index
Architecture
Path index

13. Features of SUPEX Constructed based on DTD,Schema
Integrating path index with value indexes
Supporting Twig query efficiently
Supporting label path expressions
( bib//author)
Supporting the evaluation of value-based condition predicates (//author[firstname = “jone”])

14. Outline Architecture and Features Storage and data management
Indexing Schema
Query processing
Conclusion and Future Work

15. Query processing Navigation strategy Supporting XPath2.0 and XQuery1.0
Combine continuous steps in one XPath into a single path.
Reform syntax tree into reduced execution plan.
Introducing the pipeline operator to XQuery
process.
There are two different implementation of XQuery executer. One is based on Navigation , in OrientX version 2.0
And another is based on algebra .

16. Operators in Navigation
Currently, Navigation Containing 13 operators:
Step
CondTreeNode
Path
ForVarBind
LetVarBind
FLWR
EleConstructor
AttrConstructor
BuiltInFun
IfThenElse
Quanlify
SetOpt
SortBy

17. General Steps to process XQuery
XQuery Query
Parser and Translator
Initial Query plan
optimizer
This flowchart is the procedure of our XQuery process.
optimized Query plan
Evaluator Engine

18. The query plan
With the above XQuery example, the corresponding Query plan is the tree on right .
It a tree structure translated from the Query diriectly.

19. Outline Architecture and Features Storage and data management
Indexing Schema
Query processing
Conclusion and Future Work

20. Conclusion and Future Work
OrientX is an integrated, schema-based native XML database system.
It implements storing and querying xml data.
Future work:
XQuery optimization.
Xml Update and Other XQuery processing engine.

21. Q&A Thanks Welcome to our website http://idke.ruc.edu.cn
to obtain more information about OrientX