An Improvement of an Approach for Representation of Tree Structures in Relational Tables

Transcription

1 An Improvement of an Approach for Representation of Tree Structures in Relational Tables Ivaylo Atanassov Abstract: The paper introduces an improvement of an approach for tree representation in relational tables. Tree structures are widely used in the area of the computer systems. Often is needed to store trees in relational databases. But the relational model does not supports datatypes for such an objects. The conventional methods to store trees suffer from the limitations of the relational model. The present paper offers some modifications of an existing method path enumeration model. A number of experiments were conducted and the results show improvement in manipulation time of the trees. Key words: Relational Databases, Trees, Relational Tables, Path Enumeration Model, Hierarchies, SQL INTRODUCTION Tree structures are widely used in the area of the computer systems [3, 7]. trees are implemented many system structures, the class hierarchies, the file system and others. Trees are often represented in relational databases. But the relational model does not supports such an objects. Relational tables are set of tuples of attributes of some domain[4, 6]. The representation of objects in relational databases always suffers from the limitations of the model. Several approaches exists to store trees in relational tables[1, 2]. The present paper offers an improvement of an existing approach. One of the existing approaches is the path enumeration model ( PEM ). It is well described in[2]. In brief, it represents the trees in a relation with schema as shown in fig. 1 and table 1. node4 node1 node2 node3 node5 node6 Fig. 1. An example tree Table 1. The path enumeration model ID Text Path A Node1 A B Node2 A.B C Node3 A.C D Node4 A.B.D E Node5 A.B.E F Node6 A.C.F Every node has unique string, distinguishing him from the others. Also, every node has path, consisting of the concatenated unique string of all the parents, until the root. The SQL statements to retrieve subtree of a given node are based on SQL function LIKE[4, 6]. They are quite simple and do not require special techniques[2, 4]. This is the main advantage of the method. But some improvements can be done, according to the structure of the path string. The new approach to the path string is: - the root node is unique string - the character from the path string is removed - an immediate descendant of a given node gets path string using the following formula: path = path(parent) to_char( a +number(node)) Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee ACM ISBN: II.9-1 -

2 where path(parent) is the path string of the parent node, number(node) is the consecutive number of the node being added ( consecutive according to the number of descendants ). In this manner the relational table looks as shown in table 2. Table 2. The new structure of the table Path Text a Node1 a.a Node2 a.b Node3 a.aa Node4 a.ab Node5 a.ba Node6 Every new node is formed as displacement from the character a, concatenated with parent s path string. The main advantage of the PEM still holds easy and fast retrieving of the subtrees. The improvement is that the required space is reduced and as consequence the retrieval time. EXPERIMENTAL RESULTS Experiments are conducted to proof the above statements. The tree structures, stored in relational tables, are as described in table 3. The experiments are conducted on relational database systems InterBase and Oracle. Table 3. Parameters of the used tree Height of the tree 61 Number of characters for root identifier 3 Nodes count 543 The described tree is stored multiple times, differentiating each other by the root identification string. As seen from table 3, the root node consists of 3 symbols. This means that is possible to store 26 3 ( ) different trees. Fig. 2 shows the SQL commands to create the tables. Approach with create table t1 ( idn varchar(10) not null, path varchar(200) not null, constraint pkt1 primary key(idn) ); idn the identification value of the node path the path to the node the attribute idn is primary key Approach without create table t1 ( idn integer not null, path varchar(200) not null, constraint pkt1 primary key(idn) ); idn the identification value of the node path the path to the node the attribute idn is primary key Fig. 2. The SQL commands to create the tables - II.9-2 -

3 For the purposes of the experiment is used the CPU on-chip high performance counter to measure the execution time of the queries[5]. Such a timer is available in Pentium processors. It can be accessed either via assembler instruction RDTSC ( Read Date Time Stamp Counter ) or with Windows API function QueryPerformanceCounter[8]. In the experiment is used the API function. EXPERIMENTAL RESULTS FOR INTERBASE RDBMS Table 4 summarizes the parameters of the experimental configuration. Table 4. The parameters of the experimental setup Processor Intel Celeron 333 MHz Memory 256 MB HDD 20 GB Operating system MS Windows 2000 Database system InterBase Fig. 3 describes the SQL queries to retrieve the subtree of a node For the approach with this is the node with path string a.b.c.h.u.z.ae.au.bd.bj.bk, while for the approach without is a.aadaaaabca. An important role plays the standart SQL function LIKE, well described in the appropriate literature [4, 6]. Approach with select * from t1 where path like 'a.b.c.h.u.z.ae.au.bd.bj.bk%' Approach without select * from t1 where path like 'a.aadaaaabca%' Fig. 3. The SQL queries to retrieve the subtree of a node The first experiment was conducted on the database without indexing. The number of the performed measurements is 50. The number of the trees is 26*26, thus the nodes are 676 ( trees ) * 543 ( nodes each ), plus one tree with root a = nodes total. Table 5 summarizes the results of the experiment. Every row stands for the average value of 5 measurements. The numbers in the table are the, spent for execution of the query. Fig. 4 is the graphical representation of the results. Table 5. The results of the experiment out ,50E+07 9,00E+07 8,50E+07 8,00E+07 7,50E+07 7,00E+07 Fig. 4. The graphical representation - II.9-3 -

4 Average value for the approach with ticks. Average value for the approach without ticks. As conclusion, on tables without indexing, the proposed approach without gives about 19.3 % improvement, compared with the approach with. The next experiment is for database with indexed tables. The index is on attribute pth from fig. 2. The number of the used trees is greater 26*26*10 ( 6760 ) trees, each with 543 nodes, plus one tree with root a, total of nodes. Table 6 summarizes the results of the experiment. Every row stands for the average value of 5 measurements. The numbers are the, spent for execution of the query. Fig. 5 is the graphical representation of the results. Table 6. The results of the experiment out ,00E+06 1,80E+06 1,60E+06 1,40E+06 1,20E+06 1,00E+06 8,00E+05 Fig. 5. The graphical representation Average value for the approach with Average value for the approach without As conclusion, on tables with indexing, the proposed approach without gives about 19.2 % improvement, compared with the approach with. EXPERIMENTAL RESULTS FOR ORACLE RDBMS Table 7 summarizes the parameters of the experimental configuration. Table 7. The parameters of the experimental setup. Processor Intel Celeron 900 MHz Memory 256 MB HDD 20 GB Operating system MS Windows XP Database system Oracle 8i The parameters for the trees are the same as these for the experiment with InterBase. The first experiment is for database without any indexing. Table 8 summarizes the results. Every row stands for the average value of 5 measurements. The numbers are the, spent for execution of the query. Fig. 6 is the graphical representation. - II.9-4 -

5 Table 8. The results of the experiment out ,00E+06 7,00E+06 6,00E+06 5,00E+06 4,00E+06 3,00E+06 2,00E+06 1,00E+06 0,00E+00 Average value for the approach with ticks. Average value for the approach without ticks. Fig. 6. The graphical representation As conclusion, on tables without indexing, the proposed approach without gives about 32.8 % improvement, compared with the approach with. The next experiment is for database with indexing on column path from fig. 2. Table 9 summarizes the results. Every row stands for the average value of 5 measurements. The numbers are the, spent for execution of the query. Fig. 7 is the graphical representation. Table 9. The results of the experiment out ,50E+05 6,00E+05 5,50E+05 5,00E+05 4,50E+05 4,00E+05 Fig. 7. The graphical representation Average value for the approach with ticks. Average value for the approach without ticks. As conclusion, on tables without indexing, the proposed approach without gives about 15.6 % improvement, compared with the approach with. - II.9-5 -

6 CONCLUSIONS AND FUTURE WORK The path enumeration model is a flexible way of representing tree structures in relational databases. Some modifications can be applied on the method, leading to improvement of manipulation time. Removing the character can decrease the length of the path string and as consequence the retrieval time. The experiments show an improvement in manipulation time. The disadvantage of the approach is the limitation for the number of immediate descendants no more than a 52 ( upper + lower case characters ). But in practice more often are encountered deep trees, not a large trees. Thus such a limitation is not crucial and the model can be applied in practice. REFERENCES [1] Brandon, D., Recursive Database Structures, ACM Digital Library, Journal of Computing Sciences in Colleges, 2005, Volume 21 [2] Celko, J., Trees and Hierarchies in SQL for Smarties, Morgan Kaufmann, 2004, ISBN [3] Cormen T., C. E. Leiserson, R. L. Rivest, C. Stein, Introduction to Algorithms, Second Edition, The MIT Press, 2001, ISBN [4] Elmasri, R., S. Navathe, Fundamentals of Database Systems, The Benjamin/Cumming, 1989, ISBN [5] IA-32 Intel Architecture Software Developer s Manual Volume 3: System Programming Guide, 2003, [6] Korth, H. F., A. Silberschatz, Database System Concepts, Second Edition, McGraw-Hill, 1991, ISBN [7] Sedgewick R., Algorithms in Java: Parts 1-4, Third Edition, Addison Wesley, 2002, ISBN [8] Windows NT/2000 Application Programming Inteface, Borland C++ Builder Help ABOUT THE AUTHOR Full-time assist. Ivaylo Atanassov, Department of Computer Systems and Technologies, Technical University Sofia, branch Plovdiv, Phone: , Е- mail: ivo_atan@tu-plovdiv.bg - II.9-6 -