efficient relational storage and retrieval of xml documents jill chen mojdeh makabi cs240b
Post on 19-Dec-2015
218 views
TRANSCRIPT
![Page 1: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/1.jpg)
Efficient Relational Storage and Retrieval of XML Documents
Jill ChenMojdeh Makabi
CS240B
![Page 2: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/2.jpg)
References
Kanda Runapongsa and Jignesh M. Patel. Storing and Querying XML Data in Object-Relational DBMSs. In A.B. Chaudhri al. (Eds): EDBT 2002 Workshops, LNCS 2490, pp.266-285, 2002.
H. Liefke and D. Suciu. XMill: an Efficient Compressor for XML Data. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pp 153-164, Dallas, Texas, May 2000.
C. Kanne and G. Moerkotte. Efficient storage of XML Data. et al. ICDE 2000. available at http://citeseer.nj.nec.com/kanne99efficient.html
Albrecht Schmidt, Martin Kersten, Menzo Windhouwer, and Florian Waas. Efficient Relational Storage and Retrieval of XML Documents. et al. WebDB 2000. available at http://www.research.att.com/conf/webdb2000/program.html
![Page 3: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/3.jpg)
XML XML assumes the role of the standard data
exchange format in Web database environments XML is semi-structured and one consequence of
that is we can expect all instances of one type to share the same structure
Modeling issues arises from the inconsistency between semi-structured data on the one hand side and fully structured database schemas on the other hand
To make XML the language of Web databases, there should be effective tools for the management of the XML documents
![Page 4: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/4.jpg)
Monet XML Model Efficient Relational Storage and Retrieval
of XML Documents The data model is based on the notion of
binary associations It decomposes XML documents into small,
flexible and semantically homogenous units
It is very efficient
![Page 5: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/5.jpg)
<bibliography><article key= “BB88”>
<author>Ben Bit</author><title>How to Hack</title>
</article><article key= “BK99”>
<editor>Ed Itor</editor><author>Bob Byte</author><author>Ken Key</author><title>Hacking & RSI</title>
</article></ bibliography >
XML documents and Syntax Tree
![Page 6: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/6.jpg)
Main Question
The question central to querying XML documents is how to store the syntax tree as database instance that provides efficient retrieval capabilities
![Page 7: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/7.jpg)
Different Approaches Tree could be stored using a single
database table Makes querying expensive
By enforcing scans over large amounts of data in relevant to a query
With few Joins, large data volumes may have to processed
Tree could be stored by storing all associations of the same type in the same binary relation.
Being used in Monet XML Model
![Page 8: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/8.jpg)
Monet XML Model
The basis for the Monet XML Model:PathsAssociations Binary Relations
![Page 9: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/9.jpg)
Path For a node o in the syntax tree, its path is the sequence of labels along
the path (vertex and edge labels) from the root to o Path describe the position of the element in the graph relative to the
root node
For Node with OID O3, its path is : bibliography article author
The Ben Bit has path: bibliography article author cdata string
![Page 10: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/10.jpg)
Associations
A pair (o,.) Є oid x (oid U string) is called an association
The different types of associations describe different parts of the tree Association of type oid x oid
represents edges Association of type oid x
string represents attributes values
![Page 11: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/11.jpg)
Binary Relation
In order to transform XML document to Monet Model, we need to get the set of binary relations that contain all associations between nodes Store all association of the same type in the same binary relation
Example:
For association of bibliography and article: {(O1, O2) , (O1, O7)}
![Page 12: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/12.jpg)
Monet Transformation
bibliography article title cdata string = {(O6, “How to Hack” ) , (O15, “Hacking & RSI”)},
bibliography article = {(O1, O2) , (O1, O7)},
bibliography article author = {(O2, O3) , (O7, O10), (O7, O12)},
bibliography article title = {(O2, O5) , (O7, O14)},
bibliography article author cdata = {(O3, O4) , (O10, O11), (O12, O13)},
bibliography article author cdata string ={(O4, “Ben Bit” ) , (O11, “Bob Byte”), (O13, “Ken Key”)},
bibliography article title cdata = {(O5, O6) , (O14, O15)},
bibliography article editor = {(O7, O8)},
bibliography article editor cdata = {(O8, O9)},
bibliography article editor cdata string = {(O9, “Ed Itor” )},
bibliography article key = {(O2, “BB88” ) , (O7, “BK99”)},
![Page 13: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/13.jpg)
Query
p = {O2, O7},
= {(O2, “Ben Bit” ) , (O7, “Bob Byte”), (O7, “Ken Key”)},assoc(p a)
= {(O2, “How to Hack” ) , (O7, “Hacking & RSI”)},assoc(p t)
SELECT pFROM bibliography article p, p author cdata a, p title cdata tWHERE a=“Ben Bit” and t like “Hack”
Show Ben Bit’s publication whose titles contain the word “Hack”
Specify sets
Specify associations between the first and last element of the path
Obtained by equality joins of binary relations along the path
![Page 14: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/14.jpg)
Single Database Table
Key Author title EditorBB88 Ben Bit How to
HackNULL
BK99 Bob Byte Hacking & RSI
Ed Itor
BK99 Ken Key Hacking & RSI
Ed Itor
….
Disadvantages: Scans over large
amounts of data Large data volumes may
have to be processed by few joins
Add NULL values for irregularities
SELECT *FROM bibliography WHERE Author=“Ben Bit” and t like “Hack”
<bibliography><article key= “BB88”>
<author>Ben Bit</author><title>How to Hack</title>
</article><article key= “BK99”>
<editor>Ed Itor</editor><author>Bob Byte</author><author>Ken Key</author><title>Hacking & RSI</title>
</article></ bibliography >
![Page 15: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/15.jpg)
Monet XML Model Results in higher degree of fragmentation
In our example, we have 11 tables Path is used to group semantically related
associations into the same relation. No need to scan the entire documents There is no need to introduce novel features on
the storage level to cope with irregularities induced by semi-structured nature of XML
The complete decomposition is linear in the size of the documents
Memory requirements is linear in the height of the syntax tree
![Page 16: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/16.jpg)
Quantitative Assessments
Documents Size in XML Size in Monet XML #Tables Loading
ACM Anthology 46.6 MB 44.2 MB 187 30.4s
Shakespeare's Plays
7.9 MB 8.2 MB 95 4.5s
Database Size Resulting size of the decomposition scheme are a
critical issues In the worst case, the size of the path summary
can be linear in the size of the documents – if the documents are completely unstructured
In practical applications, there are generally large structured portions
The Monet XML version of the ACM anthology is of smaller size than the original documents
Reduction is due to the removal of redundancy occurring character data – and removal of tags
![Page 17: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/17.jpg)
Comparison of Response Times Comparing Monet XML against SYU/Postgres SYU store all data on a single table and have to scan
these data repeatedly Monet transform yields smaller data volumes We have a set of 10 queries using Shakespeare's plays The substantial difference in response time shows that
Monet XML outruns the competitor by up to two orders of magnitude
Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10
Monet XML
1.2ms 5.6 6.8 8.0 4.4 4.9 5.0 5.0 8.8 12.7
SYU 150ms 180 160 180 190 340 350 370 1300 1040
![Page 18: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/18.jpg)
Summary
Presented a data model for efficient processing of XML documents
The experiences show that it is worth taking the plunge and fully decompose XML documents into binary associations
This approach combines the elegance of clear semantics with a highly efficient execution model by means of a simple and effective mapping between XML documents and a relational schema
![Page 19: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/19.jpg)
XORator & Object-Relational DBMSs
![Page 20: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/20.jpg)
Two Dominating Approaches
Use a native XML database engine for storing and querying data sets Provide a more natural data model and query
language for XML data – hierarchical or graph representation
Map the XML data and queries to constructs provided by Relational DBMS (RDBMS) XML data is mapped to relations, queries on XML
data are converted into SQL queries
![Page 21: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/21.jpg)
RDBMS
Advantage user is not involved in the complexity of mapping it can be used for querying both XML data and data
that exists in the relational systems Disadvantage
it can lower performance since a mapping from XML data to the relational data may produce a database schema with many relations
queries on XML data when translated to SQL queries may have many joins, making the queries expensive to evaluate
![Page 22: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/22.jpg)
In the Paper
Object-Relational DBMS (ORDBMS) Has all the advantages of an RDBMS More expressive type system than RDBMS Better suited for XML documents that may use a riche
r set of data types XORator Algorithm
Uses Document Type Definitions (DTDs) to map XML documents to tables in ORDBMS
New XML data type: XADT (XML Abstract Data Type)
![Page 23: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/23.jpg)
Storing XML Documents in an ORDBMS – Reducing DTD Complexity
Apply transformations to reduce the number of nested expressions and the number of element items, making the mapping process easier Flattening (to convert a nested definition into a flat rep
resentation): (e1, e2)* → e1*, e2* Simplification (to reduce multiple unary operators into
a single unary operator): e1** → e1* Grouping (to group subelements that have the same n
ame): e0, e1*, e1*, e2 → e0, e1*, e2
e+ → e*
![Page 24: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/24.jpg)
Reducing DTD Complexity (cont.)
![Page 25: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/25.jpg)
Storing XML Documents in an ORDBMS – Building a DTD Graph
![Page 26: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/26.jpg)
Storing XML Documents in an ORDBMS – XORator XML to OR Translator Algorithm builds on Hybrid Algorithm
If a non-leaf node N has exactly one parent, and if there are no links incident on any of the descendants of this node, then node N is assigned to an XADT attribute. (If node N is assigned to a relation, then queries on this node and its parent requires a join.)
![Page 27: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/27.jpg)
XORator (cont.)
If a non-leaf node below a * node is accessed by multiple nodes, then it is assigned to a relation. (For nodes that are mapped to relations, the ancestors of these nodes must also be assigned as relations.) e.g. scene
If a leaf node is below a * node, then it is assigned as an attribute of the XADT. Otherwise, it is assigned as an attribute of string type. e.g. line
![Page 28: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/28.jpg)
XORator (cont.)
![Page 29: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/29.jpg)
Storing XML Documents in an ORDBMS – Defining an XML Data Type
Compressed representation for the XML fragment Element tags are mapped to integer codes, and
element tags are replaced by these integer codes. A small dictionary is stored along with the XML
fragment to record the mapping between the integer codes and the actual element tag names.
Compression is used only if the space efficiency is above a certain threshold value.
![Page 30: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/30.jpg)
Defining an XML Data Type (XADT) (cont.) Methods on the XADT
XADT getElm(XADT inXML, VARCHAR rootElm, VARCHAR searchElm, VARCHAR searchKey, INTEGER level)
INTEGER findKeyInElm(XADT in XML, VARCHAR searchElm, VARCHAR searchKey)
XADT getElmIndex(XADT inXML, VARCHAR parentElm, VARCHAR childElm, INTEGER startPos, INTEGER endPos)
![Page 31: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/31.jpg)
Defining an XML Data Type (XADT) (cont.)
![Page 32: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/32.jpg)
Defining an XML Data Type (XADT) (cont.) Unnest Operator
Required when a query needs to examine individual elements in the set.
E.g. A distinct list of all speakers who speak in at least one play.
Implemented using a table User-Defined Function (UDF).
![Page 33: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/33.jpg)
Defining an XML Data Type (XADT) – Unnest Operator (cont.)
![Page 34: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/34.jpg)
Performance Evaluation
Randomly parse a few sample documents to obtain the storage space sizes in both uncompressed and compressed cases. Compressed format is chosen only if it reduces the storage space by at least 20%
![Page 35: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/35.jpg)
Performance – Shakespeare Plays
XORator algorithm chooses not to use the compressed storage alternative.
The size of the database produced by the XORator algorithm is about 60% of the size of the database produced by the Hybrid algorithm.
![Page 36: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/36.jpg)
Performance – Larger Data Set
Took the original Shakespeare data set and loaded it multiple times, producing data sets that were two, four and eight times the original database size (DSx2, DSx4, and DSx8).
Query sets: QS1: Flattening – list speakers and the lines that they speak QS2: Full path expression – retrieve the lines that have the
keyword “Rising” in the text of the stage direction QS3: Selection QS4: Multiple selections QS5: Twig with selection QS6: Order access
![Page 37: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/37.jpg)
Performance – Larger Data Set
Much less loading times Significantly better execution ti
mes for all queries, except query QS6
All queries requested at least one few join
QS6 is slower because the database needs to scan the XADT attribute to extract elements in the specified order when using the XORator algorithm, while the Hybrid database needs to only extract the value of the element order attribute
![Page 38: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/38.jpg)
Performance – SIGMOD Proceedings Data Set
Deep DTD – representative of the worst-case scenario for the XORator algorithm.
Compressed storage alternative is used – it reduces the database size by about 38%.
The size of the database produced by the XORator algorithm is about 65% of the size of the database produced by the Hybrid algorithm
![Page 39: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/39.jpg)
Performance – Larger Data Set
Took the original SIGMOD Proceedings data set and loaded it multiple times, producing data sets that were two, four and eight times the original database size (DPx2, DPx4, and DPx8).
Query Sets QG1: Selection and extraction – retrieve the authors of the papers with
the keyword “join” in the paper title QG2: Flattening – list all authors and the names of the proceeding
sections in which their papers appear QG3: Flattening with selection QG4: Aggregation QG5: Aggregation with selection QG6: Order access with selection
![Page 40: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/40.jpg)
Performance – Larger Data Set
When the size of data is small (DPx1 and DPx2), the XORator algorithm performs worse than the Hybrid algorithm.
When the size of data becomes large (DPx4 and DPx8), the XORator algorithm outperforms the Hybrid algorithm.
No table joins, but each query has 4 to 8 calls of UDFs to extract subelements or to join elements inside XADT attribute.
![Page 41: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/41.jpg)
Analysis
The cost of invoking UDFs is significant component of the query evaluation of XORator algorithm.
Does UDF incur a higher performance penalty than an equivalent built-in function? Implement two string functions to return length and su
bstring using UDFs and built-in functions, and test the following queries.
QT1: Return the length of string in the SPEAKER attribute.
QT2: Return a substring of string in the SPEAKER attribute from the fifth position to the last position.
![Page 42: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/42.jpg)
Analysis (cont.)
Using UDFs is about 40% more expensive than using built-in functions.
![Page 43: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/43.jpg)
Analysis (cont.)
Invoking UDFs are expensive because:
XADT methods use string compare and copy functions on VARCHAR. This sometimes requires scanning a large amount of data.
Associate metadata with each XADT attribute to quickly access the starting position of each element.
Cost of evaluating UDF is higher compared to equivalent built-in function.
Implement XADT as a native data type
![Page 44: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/44.jpg)
Performance
As the data size increases, the ratios of the response times between two algorithms become more than 1.
Queries using the XORator algorithm have no join and thus the response time grow at O(n) rate (scan cost), n = # of tuples
Queries using the Hybrid algorithm have many joins grow at either O(nlogn) rate (merge sort join cost), or O(n2) rate (nested loop join cost).
![Page 45: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/45.jpg)
Summary
New algorithm: XORator New data type: XADT Outperforms Hybrid algorithm due to less j
oins Future work: Implementation and evaluatio
n of UDF
![Page 46: Efficient Relational Storage and Retrieval of XML Documents Jill Chen Mojdeh Makabi CS240B](https://reader037.vdocuments.site/reader037/viewer/2022110322/56649d375503460f94a10266/html5/thumbnails/46.jpg)
Conclusion
We presented some efficient models for storing and querying XML documentsMonet XML ModelXORator Algorithm
There is still a lot of work that needs to be done in order to bridge the gap between the structured web databases and semi-structured XML documents