Tree Awareness for Relational DBMS Kernels: Staircase Join

Transcription

1 Tree Awareness for Relational DBMS Kernels: Stairase Join Torsten Grust 1 and Maurie van Keulen 2 1 Department of Computer and Information Siene, University of Konstanz, P.O. Box D188, Konstanz, Germany, Torsten.Grust@uni-konstanz.de 2 Faulty of EEMCS, University of Twente, P.O. Box 217, 7500 AE Enshede, The Netherlands, m.vankeulen@utwente.nl 1 Introdution Relational database management systems (RDBMSs) derive muh of their effiieny from the versatility of their ore data struture: tables of tuples. Suh tables are simple enough to allow for an effiient representation on all levels of the memory hierarhy, yet suffiiently generi to host a wide range of data types. If one an devise mappings from a data type τ to tables and from operations on τ to relational queries, an RDBMS may be a premier implementation alternative. Temporal intervals, omplex nested objets, and spatial data are sample instanes for suh types τ. The key to effiieny of the relational approah is that the RDBMS is made aware of the speifi properties of τ. Typially, suh awareness an be implemented in the form of index strutures (e.g., R-trees [7] effiiently enode the inlusion and overlap of spatial objets) or query operators (e.g., the multi-prediate merge join [11] exploits knowledge about ontainment of nested intervals). This hapter applies this priniple to the tree data type with the goal to turn RDBMSs into effiient XML and XPath proessors [1]. The database system is supplied with a relational [8] XML doument enoding, the XPath aelerator [5]. Enoded douments (1) are represented in relational tables, (2) an be effiiently indexed using index strutures native to the RDBMS, namely B-trees, and (3) XPath queries may be mapped to SQL queries over these tables. The resulting purely relational XPath proessor is effiient [5] and omplete (supports all 13 XPath axes). We will show that an enhaned level of tree awareness, however, an lead to a query speed-up by an order of magnitude. Tree awareness is injeted into the database kernel in terms of the stairase join operator, whih is tuned to exploit the knowledge that the RDBMS operates over tables enoding treeshaped data. This is a loal hange to the database kernel: standard B-trees

2 2 Torsten Grust and Maurie van Keulen suffie to support the evaluation of stairase join and the query optimizer may treat stairase join muh like other native join operators. 2 Purely Relational XPath Proessing We will work with a relational XML enoding that is not inspired by the doument tree struture per se like, e.g., the edge mapping [4] but by our primary goal to support XPath effiiently. The enoding of doument trees is faithful nevertheless: properties like doument order, tag names, node types, text ontents, et., are fully preserved suh that the original XML doument may be serialized from the relational tables alone. Observe that for any element node of a given XML instane, the four XPath axes preeding, desendant, anestor, and following partition the doument into four regions. In Fig. 1, these regions are depited for ontext node f: the XPath expression f/following::node() 3 evaluates to the node sequene (i, j), for example. Note that all 10 doument nodes are overed by the four disjoint axis regions (plus the ontext node): {a... j} = {f} f/α. (1) α {preeding,desendant, anestor,following} The XPath aelerator doument enoding [5] preserves this region notion. The key idea is to design the enoding suh that the nodes ontained in an axis region an be retrieved by a relational query simple enough to be effiiently supported by relational index tehnology (in our ase B-trees). Equation (1) guarantees that all doument nodes are indeed represented in suh an enoding. a b e d f i g h j a b e d f i g h j a b d f e i g h j a b e d f i g h j (a) (b) () (d) Fig. 1. XPath axes indue doument regions: shaded nodes are reahable from ontext node f via a step along the (a) preeding, (b) desendant, () anestor, (d) following axes. Leaf nodes denote either empty XML elements, attributes, text, omment, or proessing instrution nodes; inner nodes represent non-empty elements The atual enoding maps eah node v to its preorder and order traversal ranks in the doument tree: v pre(v), (v). In a preorder traversal, a node v is visited and assigned its preorder rank pre(v) before its hildren are 3 In the sequel, we will abbreviate suh XPath step expressions as f/following.

3 Tree Awareness for Relational DBMS Kernels 3 reursively traversed from left to right. Postorder traversal is defined dually: node v is assigned its order rank (v) after all its hildren have been traversed. For the XML doument tree of Fig. 1, a preorder traversal enumerates the nodes in doument order (a,..., j) while a order traversal enumerates (, b, d, g, h, f, j, i, e, a), so that we get pre(e), (e) = 4, 8, for instane. Figure 2 depits the two-dimensional pre/ plane that results from enoding the XML instane of Fig. 1. Context ontext node doument node a node f, enoded as pre(f), (f) = e 5, 5, indues four retangular regions i j in the pre/ plane, e.g., in the 5 lower-left partition we find the nodes f g h f/preeding = (b,, d). This haraterization of the XPath axes is muh 1 b d 0, pre more aessible for an RDBMS: an axis 1 5 step an be evaluated in terms of a retangular region query on the pre/ Fig. 2. Pre/ plane for the XML plane. Suh queries are effiiently supported by onatenated (pre, ) B- lines indiate the doument regions as doument of Fig. 1. Dashed and dotted trees (or R-trees [5]). seen from ontext nodes f ( ) and The further XPath axes, like, e.g., g ( ), respetively following-sibling or anestor-orself, determine speifi supersets or subsets of the node sets omputed by the four partitioning axes. These are easily haraterized if we additionally maintain parent node information for eah node, i.e., use v pre(v), (v), pre(parent(v)) as the enoding for node v. We will fous on the four partitioning axes in the following. Note that all nodes are alike in the XPath aelerator enoding: given an arbitrary ontext node v, e.g., omputed by a prior XPath axis step or XQuery expression, we retrieve pre(v), (v) and then aess the nodes in the orresponding axis region. Unlike related approahes [2], the XPath aelerator has no bias towards the doument root element. Please refer to [5, 6] for an in-depth explanation of the XPath aelerator. 2.1 SQL-based XPath Evaluation Inside the relational database system, the enoded XML doument tree, i.e., the pre/ plane, is represented as a table do with shema pre type. Eah tuple enodes a single node (with field type disriminating element, attribute, text, omment, proessing instrution node types). Sine pre is unique and thus may serve as node identity as required by the W3C XQuery and XPath data model [3] additional node information is assumed to be hosted in

4 4 Torsten Grust and Maurie van Keulen separate tables using pre as a foreign key. 4 A SAX-based doument loader [9] an populate the do table using a single sequential san over the XML input [5]. The evaluation of an XPath path expression p = s 1 /s 2 / /s n leads to a series of n region queries where the node sequene output by step s i is the ontext node sequene for the subsequent step s i+1. The ontext node sequene for step s 1 is held in table ontext (if p is an absolute path, i.e., p = /s 1 /, ontext holds a single tuple: the enoding of the doument root node). XPath requires the resulting node sequene to be dupliate free as well as being sorted in doument order [1]. These inherently set-oriented, or rather sequene-oriented, XPath semantis are implementable in plain SQL (Fig. 3). 1 SELECT DISTINCT v n.* 2 FROM ontext,do v 1,...,do v n 3 WHERE axis(s 1,, v 1) AND axis(s 2, v 1, v 2) AND AND axis(s n, v n 1, v n) 4 ORDER BY v n.pre ASC axis(preeding, v, v ) v.pre < v.pre AND v. < v. axis(desendant, v, v ) v.pre > v.pre AND v. < v. axis(anestor, v, v ) v.pre < v.pre AND v. > v. axis(following, v, v ) v.pre > v.pre AND v. > v. Fig. 3. Translating the XPath path expression s 1/s 2/ /s n (with ontext ontext) into an SQL query over the doument enoding table do Note that we fous on the XPath ore, namely loation steps, here. Funtion axis( ), however, is easily adapted to implement further XPath onepts, like node tests, e.g., with XPath axis α and node kind κ {text(), omment(),... }: axis(α::κ, v, v ) axis(α, v, v ) AND v.type = κ. Finally, the existential semantis of XPath prediates are naturally expressed by a simple exhange of orrelation variables in the translation sheme of Fig. 3. The XPath expression s 1 [s 2 ]/s 3 is evaluated by the RDBMS via the SQL query shown in Fig SELECT DISTINCT v 3.* 2 FROM ontext,do v 1,do v 2,do v 3 3 WHERE axis(s 1,, v 1) AND axis(s 2, v 1, v 2) AND axis(s 3, v 1, v 3) 4 ORDER BY v 3.pre ASC. Fig. 4. SQL equivalent for the XPath expression s 1[s 2]/s 3 (note the exhange of v 1 for v 2 in axis(s 3, v 1, v 3), line 3). 4 In this hapter, we will not disuss the many possible table layout variations (in-line tag names or CDATA ontents, partition by tag name, et.) for do.

5 Tree Awareness for Relational DBMS Kernels Lak of Tree Awareness in Relational DBMS The struture of the generated SQL queries a flat self-join of the do table using a onjuntive join prediate is simple. An analysis of the atual query plans hosen by the optimizer of IBM DB2 V7.1 shows that the system an ope quite well with this type of query. Figure 5 depits the situation for a two-step query s 1 /s 2 originating in ontext sequene ontext. sort pre ontext unique pre ixsan pre/ do v 1 ixsan pre/ do v 2 Fig. 5. Query plan The RDBMS maintains a B-tree over onatenated (pre, ) keys. The index is used to san the inner (right) do table join inputs in pre-sorted order. The ontext is, if neessary, sorted by the preorder rank pre as well. Both joins may thus be implemented by merge joins. The atual region query evaluation happens in the two inner join inputs: the prediates on pre at as index range san delimiters while the onditions on are fully sargable [10] and thus evaluated during the B-tree index san as well. The joins are atually right semijoins, produing their output in pre-sorted order (whih mathes the request for a result sequene sorted in doument order in line 4 of the SQL query). As reasonable as this query plan might appear, the RDBMS treats table do (and ontext) like any other relational table and remains ignorant of treespeifi relationships between pre(v) and (v) other than that both ranks are paired in a tuple in table do. The system thus gives away signifiant optimization opportunities. To some extent, however, we are able to make up for this lak of tree awareness at the SQL level. As an example, assume that we are to take a desendant step from ontext node v (Fig. 6). It is suffiient to san the (pre, ) B-tree in the range from pre(v) to pre(v ) sine v is the rightmost leaf in the subtree below v and thus has maximum preorder rank. Sine the pre-range pre(v) pre(v ) ontains exatly the nodes in the desendant axis of v, we have 5 t v v v Fig. 6. Nodes with minimum (v ) and maximum pre (v ) ranks in the subtree below v pre(v ) = pre(v) + v/desendant. (2) Additionally, for any node v in a tree t we have that v/desendant = (v) pre(v) + level(v) }{{} h where level(v) denotes the length of the path from t s root to v whih is obviously bound by h, the overall height of t. 6 Equations (2) and (3) provide 5 We use s to denote the ardinality of set s. 6 The system an ompute h at doument loading time. For typial real-world XML instanes, we have h 10. (3)

6 6 Torsten Grust and Maurie van Keulen us with a haraterization of pre(v ) expressed exlusively in terms of the urrent ontext node v: pre(v ) (v) + h. (4) A dual argument applies to leaf v, the node with minimum order rank below ontext node v (Fig. 6). Taken together, we an use these observations to further delimit the B-tree index range sans to evaluate desendant axis steps: axis(desendant, v, v ) v.pre > v.pre AND v.pre v. + h AND v. v.pre + h AND v. < v.. pre = +h v pre(v)+h pre 0,0 (v)+h Fig. 7. Original (dark) and shrunk (light) pre and san ranges for a desendant step to be taken from v Note that the index range san is now delimited by the atual size of the ontext nodes subtrees modulo a small misestimation of maximally h whih is insignifiant in multi-million node douments and independent of the doument size. The benefit of using these shrunk desendant axis regions is substantial, as Fig. 7 illustrates for a small XML instane. In [5], a speed-up of up to three orders of magnitude has been observed for 100 MB XML doument trees. Nevertheless, as we will see in the upoming setion, the index sans and joins in the query plan of Fig. 5 still perform a signifiant amount of wasted work, espeially for large ontext sequenes. Being uninformed about the fat that the do tables enodes tree-shaped data, the index sans repeatedly re-read regions of the pre/ plane only to generate dupliate nodes. This, in turn, violates XPath semantis suh that a rather ostly dupliate elimination phase (the unique operator in Fig. 5) at the top of the plan is required. Real tree awareness, however, would enable the RDBMS to improve XPath proessing in important ways: (1) sine the node distribution in the pre/ plane is not arbitrary, the ixsans ould atually skip large portions of the B-tree sans, and (2) the ontext sequene indues a partitioning of the plane that the system an use to fully avoid dupliates. The neessary tree knowledge is present in the pre/ plane and atually available at the ost of simple integer operations like +, < as we will now see but remains inaessible for the RDBMS unless it an be made expliit at the SQL level (like the desendant window optimization above).

7 Tree Awareness for Relational DBMS Kernels 7 3 Enapsulating Tree Awareness in the Stairase Join To make the notion of tree awareness more expliit, we first analyze some properties of trees and how these are refleted in the pre/-plane enoding. We introdue three tehniques, pruning, partitioning, and skipping, that exploit these properties. The setion onludes with the algorithm for the stairase join, a new join operator that inorporates the three tehniques. 3.1 Pruning In XPath, an axis step is generally evaluated on an entire sequene of ontext nodes [1]. This leads to dupliation of work if the pre/ plane regions assoiated with the step are independently evaluated for eah ontext node. a b e d f i g h j (a) a b e d f i g h j (b) Fig. 8. (a) Intersetion and inlusion of the anestor-or-self paths of a ontext node sequene. (b) The pruned ontext node sequene overs the same anestor-or-self region and produes less dupliates (3 rather than 11) Figure 8 (a) depits the situation if we are about to evaluate an anestoror-self step for ontext sequene (d, e, f, h, i, j). The darker the path s shade, the more often are its nodes produed in the resulting node sequene whih ultimately leads to the need for a ostly dupliate elimination phase. Obviously, we ould remove nodes e, f, i whih are loated along a path from some other ontext node up to the root from the ontext node sequene without any effet on the final result (a, d, e, f, h, i, j) (Fig. 8 (b)). Suh opportunities for the simplifiation of the ontext node sequene arise for all axes. Figure 9 depits the senario in the pre/ plane as this is the RDBMS s view of the problem (these planes show the enoding of a slightly larger XML doument instane). For eah axis, the ontext nodes establish a different boundary enlosing a different area. Result nodes an be found in the shaded areas. In general, regions determined by ontext nodes an inlude one another or partially overlap (dark areas). Nodes in these areas generate dupliates. The removal of nodes e, f, i earlier is a ase of inlusion. Inlusion an be dealt with by removing the overed nodes from the ontext: for example, 2, 4 for (a) desendant and 3, 4 for () following axis. The proess of identifying the ontext nodes at the over s boundary is referred to as pruning and is easily implemented involving a simple order rank omparison (Fig. 14).

8 8 Torsten Grust and Maurie van Keulen doument node ontext node pre pre pre (a) desendant axis (b) anestor axis () following axis Fig. 9. Overlapping regions (ontext nodes i) After pruning for the desendant or anestor axis, all remaining ontext nodes relate to eah other on the preeding/following axis as illustrated for desendant in Fig. 10. The ontext establishes a boundary in the pre/ plane that resembles a stairase. doument node ontext node 3 1 0,0 2 pre Fig. 10. Context pruning produes proper stairases Observe in Fig. 10 that the three darker subregions do not ontain any nodes. This is no oinidene. Any two nodes a, b partition the pre/ plane into nine regions R through Z (see Fig. 11). There are two ases to be distinguished regarding how both nodes relate to eah other: (a) on anestor/desendant axis or (b) on preeding/following axis. In (a), regions S, U are neessarily empty beause an anestor of b annot preede (region U) or follow a (region S) if b is a desendant of a. Similarly, region Z in (b) is empty, beause a, b annot have ommon desendants if b follows a. The empty regions in Fig. 10 orrespond to suh Z regions. A similar empty region analysis an be done for all XPath axes. The onsequenes for the preeding and following axes are more profound. After pruning for, e.g., the following axis, the remaining ontext nodes relate to eah other on the anestor/desendant axis. In Fig. 11 (a), we see that for any two remaining ontext nodes a and b, (a, b)/following = S T W. Sine region S is empty, (a, b)/following = T W = (b)/following. Consequently, we an prune a from the ontext (a, b) without affeting the result. If this reasoning is followed through, it turns out that all ontext nodes an be pruned exept the one with the maximum preorder rank in ase of preeding and the minimum order rank in ase of following. For these two axes, the ontext is redued to a singleton sequene suh that the axis step

9 Tree Awareness for Relational DBMS Kernels 9 R U X S a V Y T W b Z pre R U X S V a Y T b W Z pre (a) Nodes a and b relate to eah other on the anestor/ desendant axis (b) Nodes a and b relate to eah other on the preeding/ following axis Fig. 11. Empty regions in the pre/ plane a b e d f i g h j p 1 p 2 p 3 p 0 (a) a e i j f g h d b p 0 p 1 p 2 p 3 (b) pre Fig. 12. The partitions p 0 p 1, p 1 p 2, p 2 p 3 of the anestor stairase separate the anestor-or-self paths in the doument tree evaluation degenerates to a single region query. We will therefore fous on the anestor and desendant axes in the following. 3.2 Partitioning While pruning leads to a signifiant redution of dupliate work, Fig. 8 (b) exemplifies that dupliates still remain due to interseting anestor-or-self paths originating in different ontext nodes. A muh better approah results if we separate the paths in the doument tree and evaluate the axis step for eah ontext node in its own partition (Fig. 12 (a)). Suh a separation of the doument tree is easily derived from the stairase indued by the ontext node sequene in the pre/ plane (Fig. 12 (b)): eah of the partitions p 0 p 1, p 1 p 2, and p 2 p 3 define a region of the plane ontaining all nodes needed to ompute the axis step result for ontext nodes d, h, and

10 10 Torsten Grust and Maurie van Keulen j, respetively. Note that pruning redues the number of these partitions. (Although a review of the details is outside the sope of this text, it should be obvious that the partitioned pre/ plane naturally leads to a parallel XPath exeution strategy.) 3.3 Skipping doument node ontext node 2 v 1 0,0 san skip san pre Fig. 13. Skipping tehnique for desendant axis The empty region analysis explained in Set. 3.1 offers another kind of optimization, whih we refer to as skipping. Figure 13 illustrates this for the XPath axis step ( 1, 2 )/desendant. An axis step an be evaluated by sanning the pre/ plane from left to right and partition by partition starting from ontext node 1. During the san of 1 s partition, v is the first node enountered outside the desendant boundary and thus not part of the result. Note that no node beyond v in the urrent partition ontributes to the result (the light grey area is empty). This is, again, a onsequene of the fat that we san the enoding of a tree data struture: node v is following 1 in doument order so that both annot have ommon desendants, i.e., the empty region in Fig. 13 is a region of type Z in Fig. 11 (b). This observation an be used to terminate the san early whih effetively means that the portion of the san between pre(v) and the suessive ontext node pre( 2 ) is skipped. The effetiveness of skipping is high. For eah node in the ontext, we either (1) hit a node to be opied into the result, or (2) enounter a node of type v whih leads to a skip. To produe the result, we thus never touh more than result + ontext nodes in the pre/ plane, a number independent of the doument size. A similar, although slightly less effetive skipping tehnique an be applied to the anestor axis: if, inside the partition of ontext node, we enounter a node v outside the anestor boundary, we know that v as well as all desendants of v are in the preeding axis of and thus an be skipped. In suh a ase, Equation (3) provides us with a good estimate whih is maximally off by the doument height h of how many nodes we may skip during the sequential san, namely (v) pre(v). 3.4 Stairase Join Algorithm The tehniques of pruning, partitioning, and skipping are unavailable to an RDBMS that is not tree aware. Making the query optimizer of an RDBMS more tree aware would allow it to improve its query plans onerning XPath

11 Tree Awareness for Relational DBMS Kernels 11 evaluation. However, inorporating knowledge of the pre/ plane should, ideally, not lutter the entire query optimizer with XML-speifi adaptations. As explained in the introdution, we propose a speial join operator, the stairase join, that exploits and enapsulates all tree knowledge of pruning, partitioning, and skipping present in the pre/ plane. On the outside, it behaves to the query optimizer in many ways as an ordinary join, for example, by admitting seletion pushdown. The approah to evaluating a stairase join between a doument and a ontext node sequene is to sequentially san the pre/ plane one from left to right seleting those nodes in the urrent partition that lie within the boundary established by the ontext node sequene (see Fig. 14). Along the way, enountered ontext nodes are pruned when possible. Furthermore, portions of a partition that are guaranteed not to ontain any result nodes are skipped. Sine the XPath aelerator maintains the nodes of the pre/ plane in the pre-sorted table do, stairase join effetively visits the tree in doument order. The nodes of the final result are, onsequently, enountered and written in doument order, too. stairasejoin des (do : table (pre,), ontext : table (pre,)) result new table (pre, ); /* partition from... to */ from first node in ontext; while ( to next node in ontext) do if to. < from. then /* prune */ else sanpartition des ( from.pre + 1, to.pre 1, from.); from to; n last node in do; sanpartition des ( from.pre + 1, n.pre, from.); return result; sanpartition des (pre from, pre to, ) for i from pre from to pre to do if do[i]. < then append do[i] to result; else break; /* skip */ Fig. 14. Stairase join algorithm (desendant axis, anestor analogous) This algorithm has several important harateristis: (1) it sans the do and ontext tables sequentially, (2) it sans both tables only one for an entire ontext sequene, (3) it sans a fration of table do with a size smaller than result + ontext, (4) it never delivers dupliate nodes, and

12 12 Torsten Grust and Maurie van Keulen (5) result nodes are produed in doument order, so no -proessing is needed to omply with the XPath semantis. 4 Query Planning with Stairase Join ontext σ ::text() des σ ::n an do do Fig. 15. Plan for twostep path query The evaluation of an XPath path expression p = s 1 /s 2 / /s n leads to a series of n region queries where the node sequene output by step s i is the ontext node sequene for the subsequent step s i+1 (see Set. 2.1). One axis step s i enompasses a loation step and possibly a node test. The orresponding query plan, hene, onsists of a stairase join for the loation step and a subsequent seletion for the node test. Figure 15 shows a possible query plan for the example query ontext/desendant::text()/anestor::n ( des and an the stairase join, respetively). ontext des an σ ::n σ ::text() do do Fig. 16. Query plan with node test pushed down depit the desendant and anestor variants of There are, however, alternative query plans. Stairase join, like ordinary joins, allows for seletion pushdown, or rather node test pushdown: for any loation step α and node test κ σ ::κ (ontext α do) = ontext α (σ ::κ (do)). Figure 16 shows a query plan for the example query where both node tests have been pushed down. Observe that in the seond query plan, the node test is performed on the entire doument instead of just the result of the loation step. An RDBMS already keeps statistis about table sizes, seletivity, and so on. These an be used by the query optimizer in the ordinary way to deide whether or not the node test pushdown makes sense. Physial database design does not require exeptional treatment either. For example, in a setting where appliations mainly perform qualified name tests (i.e., few ::* name tests), it is benefiial to fragment table do by tag name. A pushed down name test σ ::n (do) an then be evaluated by taking the appropriate fragment without the need for any data proessing. The addition of stairase join to an existing RDBMS kernel and its query optimizer is, by design, a loal hange to the database system. A standard B-tree index suffies to realize the tree knowledge enapsulated in stairase join. Skipping, as introdued in Set. 3.3, is effiiently implemented by following the pre-ordered hain of linked B-tree leaves, for example. We have found stairase join to also operate effiiently on higher levels of the memory hierarhy, i.e., in a main-memory database system. For queries like the above example, the stairase join enhaned system proessed 1 GB

13 Tree Awareness for Relational DBMS Kernels 13 XML douments in less than 1 /2 seond on a standard single proessor host [6]. 5 Conlusions The approah toward effiient XPath evaluation desribed in this paper is based on a relational doument enoding, the XPath aelerator. A preorder plus order node ranking sheme is used to enode the tree struture of an XML doument. In this sheme, XPath axis steps are evaluated via joins over simple integer range prediates expressible in SQL. In this way, the XPath aelerator naturally exploits standard RDBMS query proessing and indexing tehnology. We have shown that an enhaned level of tree awareness an lead to a signifiant speed-up. This an be obtained with only a loal hange to the RDBMS kernel: the addition of the stairase join operator. This operator enapsulates XML doument tree knowledge by means of inorporating the desribed tehniques of pruning, partitioning, and skipping in its underlying algorithm. The new join operator requires no exeptional treatment: stairase join affets physial database design and query optimization muh like traditional relational join operators.

14

15 Referenes 1. Anders Berglund, Sott Boag, Don Chamberlin, Mary F. Fernandez, Mihael Kay, Jonathan Robie, and Jérôme Siméon. XML Path Language (XPath) 2.0. Tehnial Report W3C Working Draft, Version 2.0, World Wide Web Consortium, November Brain F. Cooper, Neal Sample, Mihael J. Franklin, Gisli R. Hjaltason, and Moshe Shadmon. A Fast Index for Semistrutured Data. In Pro. of the 27th Int l Conferene on Very Large Data Bases (VLDB), pages , Rome, Italy, September Mary Fernandez, Ashok Malhotra, Jonathan Marsh, Marton Nagy, and Norman Walsh. XML Query Data Model. Tehnial Report W3C Working Draft, World Wide Web Consortium, November TR/query-datamodel. 4. Daniela Floresu and Donald Kossmann. A Performane Evaluation of Alternative Mapping Shemes for Storing XML Data in a Relational Database. Tehnial Report 3680, INRIA, Roquenourt, Frane, May Torsten Grust. Aelerating XPath Loation Steps. In Pro. of the 21st Int l ACM SIGMOD Conferene on Management of Data, pages , Madison, Wisonsin, USA, June Torsten Grust, Maurie van Keulen, and Jens Teubner. Stairase Join: Teah a Relational DBMS to Wath its (Axis) Steps. In Pro. of the 29th Int l Conferene on Very Large Data Bases (VLDB), Berlin, Germany, September Antonin Guttman. R-Trees: A Dynami Index Struture for Spatial Searhing. In SIGMOD 1984, Pro. of Annual Meeting, pages 47 57, Boston, Massahusetts, June ACM Press. 8. Hans-Peter Kriegel, Maro Pötke, and Thomas Seidl. Managing Intervals Effiiently in Objet-Relational Databases. In Pro. of the 26th Int l Conferene on Very Large Databases (VLDB), pages , Cairo, Egypt, September SAX (Simple API for XML) Patriia G. Selinger, Morton M. Astrahan, Donald M. Chamberlin, Raymond A. Lorie, and Thomas G. Prie. Aess Path Seletion in a Relational Database Management System. In Pro. of the ACM SIGMOD Int l Conferene on Management of Data, pages 23 34, Boston, Massahusetts, USA, Chun Zhang, Jeffrey Naughton, David DeWitt, Qiong Luo, and Guy Lohman. On Supporting Containment Queries in Relational Database Management Sys-

16 16 Torsten Grust and Maurie van Keulen tems. In Pro. of the ACM SIGMOD Int l Conferene on Management of Data, pages , Santa Barbara, California, May ACM Press.