Horizontal Fragmentation in Object DBMS: New Issues and Performance Evaluation'

Transcription

1 Horizontal Fragmentation in Object DBMS: New Issues and Performance Evaluation' Fernanda BaiSio 293 Marta Mattoso Gerson Zaverucha 'v3 2 Department of Computer Science - COPPE/UFRJ Federal University of Rio de Janeiro - Brazil Department of Computer Science, University of Wisconsin - Madison Abstract Horizontal fragmentation may improve the pe$ormance of database systems. Defining primary and derived horizontal fragmentation along the classes in a database schema is an important and complex issue, yet not discussed in the literature, which must be considered when horizontally fragmenting a database. In this paper, we focus on an analysis to help the designer upon the decision for primary or derived horizontal fragmentation. This analysis considers performance results of distributed databases using horizontal fragmentation to evaluate the potential benefits and drawbacks of primary and derived techniques. Therefore, this work presents a horizontal fragmentation algorithm that chooses the most adequate strategy (primary or derived) based on class relationships, single class access and query access frequencies 1 Introduction Horizontal fragmentation is often used as a means to achieve better performance of database systems by reducing the disk access required to execute an application by minimizing the number of irrelevant objects accessed and reducing the data transfer among sites [9]. In the object-oriented (00) and relational-object (RO) models, applications may involve both set operations (search over class extensions) and navigation (traversal through a class path). For this reason, horizontal fragmentation is usually subdivided in primary and derived fragmentation. Primary fragmentation basically optimizes set operations over a class extension, firstly by reducing the amount of irrelevant data accessed and, secondly, by permitting applications to be executed concurrently, thus achieving a high degree of parallelism. On the other hand, derived fragmentation can be viewed as an approach of clustering objects of distinct classes in the disk [8], therefore clearly addressing the relationships ' The authors are partially supported by CNPq between classes and improving performance of applications with navigational accesses. Defining primary and derived horizontal fragmentation along the classes in a database schema is an important and complex issue, which must be considered when fragmenting a database. Our previous work [l] proposed a complete fragmentation methodology for object Database Management Systems to assist distribution designers in combining the horizontal and vertical fragmentation techniques. The emphasis in our previous methodology relies on an Analysis Phase, which helps the designer to decide whether a class should be horizontally fragmented, vertically fragmented, or both. In this paper, we focus on an analysis along our horizontal fragmentation algorithm to help the designer upon the decision for primary or derived horizontal fragmentation. This analysis considers performance results of distributed databases using horizontal fragmentation to evaluate the potential benefits and drawbacks of primary and derived techniques. We define the (owner, member) relation that will drive the horizontal fragmentation process, by selecting classes from the database schema to be primary or derived horizontally fragmented, taking both qualitative and quantitative information into account. The (owner, member) relation reflects the structure of the navigation paths accessed by the most frequent operations. Therefore, by taking the (owner, member) relation into consideration when designing a fragmentation schema, the execution of those operations is likely to be optimized, thus improving the overall system performance. This work is organized as follows. Section 2 presents a definition of the main concepts involved in horizontal fragmentation task. Section 3 discusses related works in this area and presents a summary table comparing relevant characteristics of them. We present a horizontal fragmentation approach discussing issues related to primary and derived fragmentation in Section 4. Performance results are presented in Section 5. Finally, Section 6 concludes this paper $ IEEE 108

2 2 The distribution design of databases The distribution design task involves making decisions on the fragmentation and placement of data across the sites of a computer network. In a top down approach, the distribution design has two phases: fragmentation and allocation. The fragmentation phase is the process of clustering in fragments the information accessed simultaneously by applications, while the allocation phase is the process of distributing the generated fragments over the database system sites. To fragment a class, it is possible to use two basic techniques: vertical fragmentation and horizontal fragmentation. It is also possible to perform mixed (or hybrid) fragmentation on a class, combining both techniques. The importance of mixed fragmentation was already detected in Navathe et al. [13], Ozsu and Valduriez [ 141, and was addressed in Baiao et al. [ 11. In the object model, vertical fragmentation breaks the class logical structure (its attributes and methods) and distributes them across the fragments, which will logically contain the same objects, but with different structures. On the other hand, horizontal fragmentation distributes class instances across the fragments, which will have exactly the same structure but different contents. Thus, a horizontal fragment of a class contains a subset of the whole class extension. Horizontal fragmentation is usually subdivided in primary and derived fragmentation to address the relationship between classes, thus benefiting navigational access from applications. The primary horizontal fragmentation is applied on owner classes while the derived fragmentation is applied on member classes according to the owner fragmentation. Defining owner and member classes in a database schema is an important and complex issue, yet not discussed in the literature for the object model, which must be considered when horizontally fragmenting a database. The definition of owner and member classes is presented in Section 4.1. In the horizontal fragmentation approach, there is also the "path partitioning" technique [ 141, which we understand to be a special situation in the database schema (the "part-of' relationship) in which derived horizontal fragmentation must be performed. Therefore, we consider the path partitioning technique as a special case of the derived horizontal fragmentation, rather than an alternative approach in the distribution design. The design of distributed object databases is a complex task. First, because the semantic differences between relational and object models inhibit a straightforward migration from existing relational distribution design algorithms to the object model. Second, because it has to consider the existence of class methods and complex relationships (such as the "is-a" and "part-of' relationships), in addition to address application access to complex objects and multiple relationships between classes. Third, because of operations access patterns: while relational operations are only set oriented, object operations are pointer based, and therefore may have a dual nature involving both set operations (search over class extensions) and navigation (traversals). 3 Comparing related work in the area Many researchers addressed the distribution design in the relational model, including Ceri and Navathe [6], Navathe and Ra [12], Ozsu and Valduriez [14], Molina and Hsu [ll] and Navathe et al. [13]. In the object context, there are also many works evidencing the importance of the distribution design to improve performance of applications manipulating large volumes of data in object DBMS. Karlapalem et al. [9] describe different aspects of a distributed object DBMS that are critical to the distribution design process, which are the data model, method invocation, types of location transparency, and transaction management. The authors develop some preliminary ideas for designing fragmentation algorithms in the object context. There are some works in the literature focusing on the horizontal fragmentation in object DBMS. Savonnet et al. [15] propose a methodology for the horizontal fragmentation of all classes in a database schema. The choice between primary and derived horizontal fragmentation on each class considers its relationships, which are defined by analyzing only the method calls between classes in the schema. The work does not present an algorithm to support the methodology. Bellatreche et al. [3] present a horizontal fragmentation method and an analytical cost model to evaluate query execution time in horizontally fragmented databases, The fragmentation schema with the best performance according to the cost model is achieved through a hill-climbing algorithm, by selecting a subset of classes for primary horizontal fragmentation. The work from Ezeife and Barker [7] presents a set of algorithms to the horizontal fragmentation of all classes in a database schema. It takes relationships between classes into account to propose primary and derived horizontal fragmentation. However, this approach works at the instance level, where the class instances already exist in the database to proceed with the fragmentation process. It also assumes a storage structure for the objects in the database class hierarchy in which an instance of a subclass physically contains a pointer to the instance of its superclass that is logically part of it. This assumption leads to considering inheritance links in the horizontal fragmentation process. 109

3 Table 1: Related works on the distribution design of object databases Baiao et al. [l] propose a complete fragmentation methodology for object DBMS, which is divided in three phases. First, there is an Analysis Phase to assist distribution designers in defining the most adequate fragmentation technique (horizontal, vertical, or both) to be applied in each class of the database schema. The Analysis Phase also considers the case in which no fragmentation of a class is the best alternative. Second, they present an algorithm to perform Vertical Fragmentation in a class. Finally, the authors present an algorithm to perform Horizontal Fragmentation on the whole class or on a vertical fragment of a class, which may result in mixed fragmentation. The main characteristics of all mentioned fragmentation works are summarized in the comparative table 1. For more details on the allocation phase, the reader may refer to [2]. 4 A horizontal fragmentation approach to object DBMS Traditionally, most works in the literature base the choice between primary and derived horizontal fragmentation on the owner and member classification. This turns this classification to be one of the crucial aspects to be considered while designing a distributed database. The owner-member classification was firstly defined for the relational model in [14]. However, when we change to the object model, the owner and member classification is not as simple as it was in its relational counterpart, yet as important as it used to be. There are many issues in the object model that must be taken into account in this classification, such as the existence of complex objects, part-of relationships between classes, method calls, classes with no instances (pseudo-classes) and n x m relationships that may lead to object sharing. Also, important information such as the application access frequency to each relationship of a class must be considered. This Section discusses the definition of owner and member classes in a database schema taking both qualitative and quantitative information into account. Although this is a relevant issue in designing a distributed database in the horizontal fragmentation approach, it is not considered at this detail level in any of the works from the literature. 4.1 The (owner, member) relation For the definition of owner and member classes, we first define the (owner, member) relation. The (owner, member) relation is a set of pairs of the form (X, Y) where X and Y must be classes in the database schema. Each pair (X, Y) in the relation is called an instance of it. An instance (X, Y) denotes that class Y will be selected for derived horizontal fragmentation according to class X (class X is called the owner of Y). If, at the end of the definition of the (owner, member) relation, there is no other instance (A, X) in it (that is, if class X does not plays the member role in any of the relation instances), then class X will be selected for primary horizontal fragmentation. It is also possible to define an instance of the form (X, null), denoting class X will be selected for primary horizontal fragmentation, even though there may not be any other class selected for derived fragmentation according to X. Some restrictions apply on the (owner, member) relation definition: it is not possible to have an instance (X, X), since it is useless to define derived horizontal fragmentation on a class according to itself; it is not possible to have a pair of instances (X, A), (Y. A), since it is not possible to define derived horizontal fragmentation on a class A according to more than one primary class (X and Y); it is not possible to have a pair of instances (X, A), (A, X), since it is not possible to define both primary and derived horizontal fragmentation on a pair of classes according to each other; 110

4 The 007 Benchmark data model [4] illustrated in Figure 1 will be used to exemplify the following discussion. The 007 Benchmark has been applied to many object DBMS in order to evaluate their performance. In Section 5, we show some performance results on an alternative fragmentation schema supporting our proposed horizontal I Figure 1: The 007 benchmark database schema Given a database schema to be horizontally fragmented and a set of operations (queries and transactions) on it, the (owner, member) relation can be defined. Operations are then sorted in a descending way according to their execution frequency (thus priority is given to the most frequent operations), and are then analyzed one at a time with regard to its accessed classes. When analyzing an operation Oi, one of the two following situations may occur: i. Oi accesses only one class extension, named X: in this case, an instance (X, null) is included in the (owner, member) relation. This is a very frequent situation in real applications, for example when performing a selection over a class extension or scanning a whole class extension without navigating to other classes: E.g.1: E.g.2: select x from x in Atomicpart where x.builddate 4 10/11/96 (owner, der) = (Atomicpart, null) select x.type, x.builddate from x in Compositepart (owner, der) = (Compositepart, null) ii. Oi navigates through a class path, named X,->X2->... ->X,,: in this case, for each pair of classes (Xi, Xi+l) in the class path, 1 I i I n-i, an instance (Xi, Xi+l) is included in the (owner, member) relation if at least one of the following conditions occurs: ii.a. Existence of "1 x 1" or "n x 1" relationship: if Oi navigates from Xi to Xi+l by the way of a pointer representing a "1 x 1" or a "n x 1" relationship. In these cases, the relationship will be translated into a complex attribute of class Xi (named the composite class) with its domain on I class Xi+l (named the containing class). The relationships documentation (from CompositePart to Document) and to (from AtomicPart to Connection) are examples of "1 x 1" and "n x 1" relationships, respectively. Those cases are likely to occur in real applications that navigate through the database schema, according to the defined relationships between classes. E.g.3:select c.builddate from c in CompositePart where c->documentation.title = "Algorithm" (owner, member) = (CompositePart, Document) E.g.4:select a->to from a in AtomicPart where a.builddate < 10/11/96 (owner, "bar) = (Atomicpart, Connection) An important thing to notice is that the member class is always defined at the "1" side of the relationship. If necessary in "n x 1" relationships, we replace the instance (Xi, Xi+l) with the instance (Xi+l, Xi) in the (owner, member) relation to make sure that the member class is at the "1" side. This prevents a member object from having more than one owner (a connection is related to one and only one atomic part), thus there will be no object sharing in the member class and this eliminates the overhead of replicating member objects in many owner fragments. For the same reason, we do not create an instance in the (owner, member) relation in the case of "n x m" relationships. We believe that derived horizontal fragmentation does not contribute to performance improvement of an application when there is object sharing in both classes involved in the relationship; ii.b. Existence of a "part-of" relationship: This may be considered as a special case of the above situation (since "part-of' relationships have typically a "n x 1" cardinality). However, the semantic of this type of relationship makes it a strong candidate for defining derived fragmentation of the "part" class according to the "whole" class. Therefore, it is important to stress that the instance (Xi, Xi+l) must be included in the (owner, member) relation if there is a "part-of' relationship from Xi (the "whole" class) to Xi+l (the "part" class). This may be illustrated in the relationship parts from CompositePart to AtomicPart in figure 1. E.g.5:select c->parts from c in CompositePart (owner, d er) = (CompositePart, Atomicpart) ii.c. Existence of a method invocation sequence: if Oi navigates from Xi to Xi+l by the way of a method call. In this case, class Xi has a complex method, that is, a method accessing objects from class Xi+l. Those cases are likely to occur in real applications that navigate through the database schema 111

5 according to the relationships between classes defined in the method body. For example, we may define a method length() in class AtomicPart as the sum of the attribute length of all its to Connections. E.g.6:select x from x in AtomicPart where x.lengtho> 10 (owner, "ber) = (Atomicpart, Connection) Differently from [7], we do not take inheritance relationships (such as the ISA relationship) into account when defining member classes on the database schema. Most object DBMS products do not implement a storage structure for the objects in the database class hierarchy in which an instance of a subclass physically contains a pointer to the instance of its superclass that is logically part of it. Therefore, considering inheritance links to drive the derived horizontal fragmentation process would generate a useless overhead to the fragmentation algorithm and lead to an unnecessary derived fragmentation of a superclass according to its subclass, since the inheritance links will not exist. This would surely impact on the distributed database performance. The algorithm defining the (owner, member) relation is illustrated in figure 2. function Build&nerMemberRelation (0: set of owrationsl retums (own, man) : set of pairs (owner, member) of classes begin sort 0 in descending order according to the operation frequency for each Oi that is in 0 do if Oi accesses only 1 class C then (own, man) += (C. null); else if Oi navigates through a class path Cl->C2->-->cn then for each pair of classes (X,Y) that is in the path do set card = cardinality of the relationship between X and Y if (card = "1:l.) or (card = "N:l') then if Y is not a member in (own, rmn) then (own, mem) += (X, Y); else if card =.l:n' then if X is not a member in lown, man) then (own. m) += W. XI; retum (0wn.m) end Figure 2: Defining the (owner, member) relation 4.2 Fragmenting the database Once all the database operations are analyzed, the (owner, member) relation is completely instantiated. Classes from the database schema may then proceed to the fragmentation phase. Owner classes that do not play the member role in any of the (owner, member) relation instances are selected for primary horizontal fragmentation, while member classes are selected for derived horizontal fragmentation according to its owner. In the case that a class X appears in the (owner, member) relation in both (X, null) and (Y, X) forms, we must choose the fragmentation technique to be applied on class X - primary according to instance (X, null) or derived according to instance (X, Y). This choice is made considering the operations that were responsible for creating each instance. The instance created by the operation with lower frequency is eliminated from the (owner, member) relation. Note that this may break the class path that is accessed by a navigation application (N), thus reducing its performance, however this will only occur in the case that there is a more frequent operation (E) accessing the extension of a class in the middle of the N path. Selecting this class for primary fragmentation (instead of derived) will improve E performance, thus benefiting the most frequent operation. This situation is clearly shown in the example in Section 5. The algorithm in figure 2 prevents this situation from happening, by inserting an instance (X, null) in the relation only if X is not already a member. Primary horizontal fragmentation. The algorithm used for the primary horizontal fragmentation is an extension of the one in [13]. The algorithm takes input information on the applications accessing the class to be primary fragmented, such as their predicates and execution frequencies, in order to identify groups of objects with similar characteristics that are likely to be accessed simultaneously by applications. These groups of objects will represent the class fragments. The fragmentation process is performed in a two-step process: first, it builds a predicate affinity matrix between the simple predicates used in the applications, and then it builds a predicate affinity graph with cycles representing class fragments. To build the predicate affinity matrix, predicates are extracted from the applications and represent the matrix dimensions (lines and columns). Each value (pi, pj) in the predicate affinity matrix represents the sum of the frequencies of applications that accesses predicates pi and pj simultaneously. Logical relationships between predicates (such as the logical implication) are also maintained in the predicate affinity matrix in order to reduce the number of class fragments defined. To build the predicate affinity graph, a graphical based algorithm is performed in order to group predicates into sets of predicates. Each predicate represents a graph node, and graph links between the nodes are inserted one at a time by selecting the highest value in the predicate affinity matrix that was not considered yet. Eventually, the inclusion of a graph link may form a cycle in the graph. After building a connected graph with all the predicates, each graph cycle will represent a class fragment. A class fragment is defined by a boolean combination of predicates in the cycle using the logical connectives A and v. An additional ELSE fragment is defined, which is the negation of the conjunction of all predicate definitions, to gather objects of the class that do not fall in any of the previously defined fragments. Also, the result of predicate partitioning is adjusted, if necessary, in order to generate non-overlapping fragments only.

6 Derived horizontal fragmentation. The definition of derived horizontal fragments is straightforward, since it considers the (owner, member) relation defined previously as a guideline. In order to group in one horizontal fragment objects from different classes referenced by the same navigation operation, the distribution designer must define derived horizontal fragments of each member class (i.e., the class playing the member role) in the (owner, member) relation according to its owner. 5 Experimental results To analyze the behavior of horizontal fragmentation, we present some experimental results involving the 007 benchmark. Experiments were made with the ParGoa system [lo], a parallel object server. ParGoa is ODMG compliant [5] having ODL and OQL as interface languages. The ParGoa server is responsible for parallel processing of object-oriented queries. The parallel processing relies on data fragmentation, thus distribution design plays an important role, particularly in distributed memory environments. The ParGoa tests were performed on a cluster of IBM RS/6000(PowerPC) stations connected by Ethernet. Each workstation had 32MB of main memory. The IBM Stations in the cluster were not isolated and the PVM software was used to interconnect ParGoa modules. We present performance results derived from [ 101. While in that work the experimental study aimed at presenting results of performance speed up, here we focus on analyzing the performance results obtained with two different horizontal fragmentation designs. The main objective of this analysis is to evaluate the performance impact of two distribution design decisions involving the (owner, member) relation. Particularly, we show distributed query results involving classes that can play the role of owner or member. This is a situation discussed in Section 4, where most algorithms leave this choice to the designer. Thus, the following results have helped the design of our algorithm. For the medium sized 007 database, the four chosen classes (from figure l), Document, CompositePart, AtomicPart and Connection (DC, CP, AP and CN) had their extensions fragmented according to two horizontal design strategies hereinafter called Strategy 1 and Strategy 2. Strategy 1 privileges derived fragmentation by applying derived fragmentation on class Atomicpart according to CompositePart. Strategy 2 puts more emphasis in primary fragmentation, since it applies primary fragmentation on class AtomicPart on the builddate attribute. The resulting fragmentation present the following (owner, member) relations: Strategy 1: { (CP, null), (CP, DC), (CP,AP), (AP, CN) 1 Strategy 2: { (CP,null),(CP,DC),(AP,null),(AP,CN)) Since all these relationships are either 1 x 1 or 1 x n, in Strategy 1 related objects are kept in the same site while in Strategy 2 the links between CP and AP objects may cause cross boundaries between the nodes. In both strategies, six fragments were generated for each of the four classes so that we would have the same number for fragments and nodes. For each strategy, the following 3 queries were executed. Query 1:select x from x in AtomicPart where x.builddate < 10/11/96 (owner, member) = (AP, null) Query 2:select a->to from a in AtomicPart where a.builddate < 10/11/96 (owner, der) = (AP, CN) Query 3:select c->parts from c in CompositePart where c->documentation.title = DBMS (owner, der) = { (CP, AP), (CP, DC) 1 Each of these 3 queries was evaluated for the centralized database and for the two fragmented (Strategy 1 and Strategy 2) databases. The results in figure 3 correspond to the elapsed processing time in seconds, considering the time interval between the query reception from master node and the delivery of results from all six nodes. The results show the performance for situations (cold) where the cache was empty and remote access was required. Hot results are not shown here since the memory cache masks the communication and transfer time. To reduce the interference effects due to not having isolated workstations, we re-ran each query 20 times Querv 1 Querv 2 Querv 3 Figure 3: Performance results All distributed query executions show performance improvements when compared to the sequential and centralized database. Queries 1 and 2 contain the same predicate that was used in Strategy 2 for the primary fragmentation of Atomicpart. Thus, in Strategy 1 all Atomicpart fragments have to be scanned in these queries, whereas in Strategy 2 the execution can be directed to one specific node. Therefore, the results of Strategy 2 are at least two times faster than in Strategy 1. Particularly in 113

7 Query 2, Strategy 2 performed five times faster than the centralized execution. This is a very significant result since this query is the most time consuming between the three queries. On the other hand, Query 3 has a class path involving the relationship link between Compositepart and Atomicpart, which caused Strategy 1 to outperform Strategy 2. This can be explained by the adequacy of Strategy 1 for this kind of query. This query execution in Strategy 2 hardly improved the centralized performance. This execution forced many remote accesses to follow the relationship links. This was not the case in any of the Strategy 2 executions. Therefore these results in figure 3 show that there is a tradeoff between the fragmentation strategy to be chosen. Most algorithms would direct the fragmentation of the Atomicpart class to be derived, as in Strategy 1. However the improvements obtained with the primary fragmentation of AtomicPart in Strategy 2 were quite significant. Therefore we believe that this choice will rely on the access frequencies of the queries. We can also see that derived fragmentation is a good idea, as it was in the relational model. However maintaining long chains of derivation may incur in data skew. This was not the case in the 007 database, where the parallel processing in Strategy 1 was quite uniform. 6 Conclusions This work shows performance improvements obtained by applying distribution design and parallel processing on top of an object-oriented DBMS. Performance of distributed object DBMS can be improved by minimizing the number of irrelevant objects accessed by the applications, as it happens with primary horizontal fragmentation. It can also be improved reducing the data transfer among sites, as it happens with derived horizontal fragmentation. Therefore, the combination of these two objectives depends on the decision upon which classes will be primary or derived fragmented. Our performance results present improvements for both primary and derived fragmentation, and evidences a conflicting situation for classes that may be owner (primary) or member (derived). Previous distribution design algorithms usually ignore this issue, where the choice between owner and member seems to be trivial. Therefore, we present the definition for owner and member classes and an algorithm that carefully examines the role of each class to be fragmented, considering its relationships, cardinalities and the access frequencies of the queries. An important characteristic of the presented definition for owner and member classes is that it reflects the structure of the navigation paths accessed by the most frequent applications. In applications navigating through a class path, most algorithms would suggest a fully derived fragmentation. However, our experimental results show that when there is a frequent query accessing a member class individually, primary fragmentation of this class should be considered, despite of breaking the relationship link in the class path. References Baiao, F., Mattoso, M., Zaverucha, G., Towards an Inductive Design of Distributed Object Oriented Databases, Proc Third IFCIS Conf on Cooperative Information Systems (CoopISP8), IEEE CS Press, New York, Aug 1998, pp Bellatreche, L., Karlapalem, K, Qing, L., Complex Methods and Class Allocation in Distributed Object- Oriented Databases. Proc 51h Int l Conf on Object Oriented Information Systems, Paris, Sept 1998, pp Bellatreche, L., Karlapalem, K., Basak, G., Query-Driven Horizontal Class Partitioning in Object-Oriented Databases. Proc 9th Int l Conf on Databases and Expert Systems (DEXAP8), Lecture Notes in Computer Science no 1460, Vienna, Austria, Aug 1998, pp Carey, M., DeWitt, D., Naughton, J., The 007 Benchmark. Proc 1993 ACM SIGMOD 22(2), Washington DC, Jun 1993 pp Cattel, R., The Object Database Standard: ODMG-93 Release 1.1, Morgan Kaufman Publishers, 1993 Ceri, S., Navathe, S., A comprehensive approach to fragmentation and allocation of data in distributed databases. Proc IEEE COMPCON Conference, 1983 Ezeife, C., Barker, K., A Comprehensive Approach to Horizontal Class Fragmentation in a Distributed Object Based System, Int l Joumal of Distributed and Parallel Databases 2(3), 1995, pp Gardarin, G., Gruser, J., Tang, Z., A Cost Model for Clustered Object-Oriented Databases, Proc 2lSt VLDB Conference, Switzerland, 1995, pp Karlapalem, K., Navathe, S., Morsi, M., Issues in Distribution Design of Object-Oriented Databases. In: Ozsu, M., Dayal, U., Valduriez, P. (eds), Distributed Object Management, Morgan Kaufman Publishers, Meyer, L., Mattoso, M., Parallel query processing in a shared-nothing object database server, Proc 3rd Int l Meeting on Vector and Parallel Processing (VECPARPQ, Porto, Jun 1998, Molina, H., Hsu, M., Distributed Databases. In: Kim, W. (ed), Modem Database Systems, ACM Press, 1995, pp [El Navathe, S., Ra, M., Vertical Partitioning for Database Design: A Graphical Algorithm, Proc 1989 ACM SIGMOD, 1989, pp ] Navathe, S., Karlapalem, K., Ra, M., A Mixed Fragmentation Methodology for Initial Distributed Database Design, Joumal of Computer and Software Eng. 3(4), 1995 [lq Ozsu, M., Valduriez, P., Principles of Distributed Database Systems, New Jersey, Prentice-Hall, 1991, 2nd ed [151 Savonnet, M., Terrasse, M., Yttongnon, K., Fragtique: A Methodology for Distributing Object Oriented Databases. Proc Int l Conf on Computing and Information (ICCI 98), Winnipeg, Jun 1998, pp