Data Fragmentation, Replication and Allocation
Data Fragmentation
In a DDB, decisions must be made regarding which site should be used to store which portions of the database. For now, we will assume that there is no replication; that is, each relation- or portion of relation- is to be stored at only one site. We will discuss replication and its effects later in this section. We also use the terminology of relational databases - similar concepts apply to other data models. We assume that we are starting with a relational database scheme and must decide how to distribute the relations over various sites.
Before we decide on how to distribute the data, we must determine the logical units of the database that are to be distributed. The simplest logical units are the relations themselves; that is, each whole relation is to be stored at a particular site. In our example, we must decide on a site to store each of the relations EMPLOYEE, DEPARTMENT, PROJECTS, WORKS ON and DEPENDENT. In many cases, however, a relation can be divided into smaller logical units for distribution. For example, consider the company database shown in the company. We may want to store the database information relating to each department at the computer site for that department. A technique called horizontal fragmentation can be used to partition each relation by department.
Horizontal Fragmentation
A horizontal fragment of a relation is a subset of the tuples in that relation. The tuples that belong to the horizontal fragment are specified by a condition on one or more attributes of the relation. Often, only a single attribute is involved. For example, we may define three horizontal fragments on the EMPLOYEE relation with the following conditions (DNO=5),(DNO=4), and (DNO=1), each fragment contains the EMPLOYEE tuples working for a particular department. Similarly, we may define three horizontal fragments for the PROJECT relation, with the conditions (DNUM=5),(DMUN=4), and(DMUN=1), each fragment contains the PROJECT tuples controlled by a particular Department. Horizontal fragmentation divides a relation horizontally by grouping rows to create subsets of tuples, where each subset has a certain logical meaning. These fragments can then be assigned to different sites in the distributed system. Derived horizontal fragmentation applies the partitioning of a primary relation (DEPARTMENT in our example) to other secondary relations (EMPLOYEE and PROJECT in our example), which are related to the primary via a foreign key. This way, related data between the primary and the secondary relations gets fragmented in the same way.
Vertical Fragmentation
Each site may not need all the attributes of a relation, which would indicate the need for a different type of fragmentation. Vertical fragmentation divides a relation “vertically” by columns. A vertical fragment of a relation keeps only certain attributes of the relation. For example, we may want to fragment the EMPLOYEE relation into two vertical fragments. The first fragment includes personal information-NAME, DATE, ADDRESS, and SEX- and the second includes work-related information-SSN, SALARY, SUPERSSN, DNO. This vertical fragmentation is not quite proper because, if the two fragments are stored separately, we cannot put the original employee tuples back together, since there is no common attribute between the two fragments. It is necessary to include the primary key or some candid key attribute in every vertical fragment so that the full relation can be reconstructed from the fragments. Hence, we must add the SSN attribute to the personal information fragment.
Notice that each horizontal fragment on a relation R can be specified by a sCi (R) operation in the relational algebra. A set of horizontal fragments whose conditions C1, C2, …, Cn include all the tuples in R —that is, every tuple in R satisfies (C1 OR C2 OR … OR Cn)—is called a complete horizontal fragmentation of R. In many cases a complete horizontal fragmentation is also disjoint: that is, no tuple in R satisfies (Ci and Cj) for any i ¹ j. Our two earlier examples of horizontal fragmentation for the EMPLOYEE and PROJECT relations were both complete and disjoint. To reconstruct the relation R from a complete horizontal fragmentation, we need to apply the UNION operation to the fragment.
A vertical fragment on a relation R can be specified by a pLi (R) operation in the relational algebra. A set of vertical fragments whose projection lists L1, L2, …, Ln include all the attributes in R but share only the primary key attribute of R is called a complete vertical fragmentation of R. In this case the projection lists satisfy the following two conditions.
L1 L2 … Ln = ATTRS(R)
Li Lj = PK(R) for any i ¹ j, where ATTRS(R) is the set of attributes of R and PK(R) is the primary key of R.
To reconstruct the relation R from a complete vertical fragmentation, we apply the OUTER UNION operation to the vertical fragments (assuming no horizontal fragmentation is used). Notice that we could also apply a FULL OUTER JOIN operation and get the same result for a complete vertical fragmentation, even when some horizontal fragmentation may also have been applied. The two vertical fragments of the EMPLOYEE relation with projection lists L1 = (SSN, NAME, BDATE, ADDRESS, SEX) AND L2 = (SSN, SALARY, SUPERSSN, DNO) constitute a complete vertical fragmentation of EMPLOYEE.
Two horizontal fragments that are neither complete nor disjoint are those defined on the EMPLOYEE relation by the conditions (SALARY > 50000) and (DNO = 4); they may not include all EMPLOYEE tuples, but may include common tuples. Two vertical fragments that are not complete are those defined by the attribute lists L1 = (NAME, ADDRESS} and L2 = {SSN, NAME, SALARY}; these lists violate both conditions of a complete vertical fragmentation. Mixed (Hybrid) Fragmentation. We can intermix the two types of fragmentation, yielding a mixed fragmentation. For example, we may combine the horizontal and vertical fragmentations of the EMPLOYEE relation given earlier into a mixed fragmentation that includes six fragments. In this case the original relation can be reconstructed by applying UNION and OUTER UNION (or OUTER JOIN) operations in the appropriate order. In general, a fragment of a relation R can be specified by a SELECT-PROJECT combination of operations pL (sC (R). If C = TRUE (that is, all tuples are selected) and L ¹ ATTRS(R), we get a vertical fragment, and if C ¹ TRUE and L = ATTRS(R), we get a mixed fragment. Notice that a relation can itself be considered a fragment with C = TRUE and L = ATTRS(R). In the following discussion, the term fragment is used to refer to a relation or to any of the preceding type of fragments.
A fragmentation schema of a database is a definition of a set of fragments that includes all attributes and tuples in the database and satisfies the condition that the whole database can be reconstructed from the fragments by applying some sequence of OUTER UNION ( or OUTER JOIN) and UNION operations. It is also sometimes useful—although not necessary—to have all the fragments to be disjoint except for the repetition of primary keys among vertical (or mixed) fragments. In the latter case, all replication and distribution of fragments is clearly specified at a subsequent stage, separately from fragmentation.
An allocation schema describes the allocation of fragments to sites of the DDBS; hence, it is a mapping that specifies for each fragment the site(s) at which it is store. If a fragment is stored at more than one site, it is said to be replicated.
Data Replication and Allocation
Replication is useful in improving the availability of data. The most extreme case is Replication of the whole database at every site in the distributed system, thus creating a fully replicated distributed database. This can improve availability remarkably because the system can continue to operate as long as at least one site is up. It also improves performance of retrieval for global queries, because the result of such a query can be obtained locally from any one site; hence, a retrieval query can be processed at the local site where it is submitted, if that site includes a server module. The disadvantage of full Replication is that it can slow down update operations drastically, since a single logical update must be performed on every copy of the database to keep the copies consistent. This is especially true if many copies of the database exist. Full Replication make the concurrency control and recovery techniques more expensive than they would be if there were no replication.
The other extreme from full replication involves having no replication— that is, each fragment is stored at exactly one site. In this case all fragments must be disjoint, except for the repetition of primary keys among vertical (or mixed) fragments. This is also called non-redundant allocation.
Between these two extremes, we have a wide spectrum of partial replication of the data—that is, some fragments of the database may be replicated whereas others may not. The number of copies of each fragment can range from one up to the total number of sites in the distributed system. A special case of partial replication is occurring heavily in applications where mobile workers—such as the sales force, financial planners, and claims adjustors—carry partially replicated databases with them on laptops and personal digital assistants and synchronize them periodically with the server database. A description of the replication of fragments is sometimes called a replication schema.
Each fragment—or each copy of a fragment—must be assigned to a particular site in the distributed system. This process is called data distribution (or data allocation). The choice of sites and the degree of replication depend on the performance and availability goals of the system and on the types and frequencies of transactions submitted at each site and if most transactions are retrieval only, a fully replicated database is a good choice. However, if certain transactions that access particular parts of the database are mostly submitted at a particular site, the corresponding set of fragments can be allocated at that site only. Data that is accessed at multiple sites can be replicated at those sites. If many updates are performed, it may be useful to limit replication. Finding an optimal or even a good solution to distributed data allocation is a complex optimization problem.
Like it on Facebook, Tweet it or share this article on other bookmarking websites.