DISTRIBUTED DATABASE TRANSPARENCY FEATURES

A distributed database system requires functional characteristics that can be grouped and
described as transparency features. DDBMS transparency features have the common property
of allowing the end user to feel like the database’s only user. In other words, the user believes
that (s)he is working with a centralized DBMS; all complexities of a distributed database are
hidden, or transparent, to the user.
The DDBMS transparency features are:
Distribution transparency, which allows a distributed database to be treated as a single
logical database. If a DDBMS exhibits distribution transparency, the user does not need to
know:
 That the data are partitioned—meaning the table’s rows and columns are split
vertically or horizontally and stored among multiple sites.
 That the data can be replicated at several sites.
 The data location.
Transaction transparency, which allows a transaction to update data at more than one
network site. Transaction transparency ensures that the transaction will be either entirely
completed or aborted, thus maintaining database integrity.
Failure transparency, which ensures that the system will continue to operate in the event of
a node failure. Functions that were lost because of the failure will be picked up by another
network node.
Performance transparency, which allows the system to perform as if it were a centralized
DBMS. The system will not suffer any performance degradation due to its use on a network
or due to the network’s platform differences. Performance transparency also ensures that the
system will find the most cost-effective path to access remote data.
Heterogeneity transparency, which allows the integration of several different local DBMSs
(relational, network, and hierarchical) under a common, or global, schema. The DDBMS is
responsible for translating the data requests from the global schema to the local DBMS
schema.

DISTRIBUTION TRANSPARENCY
Distribution transparency allows a physically dispersed database to be managed as though it
were a centralized database. The level of transparency supported by the DDBMS varies from
system to system. Three levels of distribution transparency are recognized:
Fragmentation transparency is the highest level of transparency. The end user or
programmer does not need to know that a database is partitioned. Therefore, neither fragment
names nor fragment locations are specified prior to data access.
Location transparency exists when the end user or programmer must specify the database
fragment names but does not need to specify where those fragments are located.
Local mapping transparency exists when the end user or programmer must specify both the
fragment names and their locations.
To illustrate the use of various transparency levels, suppose you have an EMPLOYEE table
containing the attributes EMP_NAME, EMP_DOB, EMP_ADDRESS,
EMP_DEPARTMENT, and EMP_SALARY. The EMPLOYEE data are distributed over
three different locations: New York, Atlanta, and Miami. The table is divided by location; that
is, New York employee data are stored in fragment E1, Atlanta employee data are stored in
fragment E2, and Miami employee data are stored in fragment E3.

Case 1: The Database Supports Fragmentation Transparency

The query conforms to a nondistributed database query format; that is, it does not specify
fragment names or locations.
The query reads:
SELECT *
FROM EMPLOYEE
WHERE EMP_DOB < '01-JAN-196';

Case 2: The Database Supports Location Transparency

Fragment names must be specified in the query, but the fragment’s location is not specified.
The query reads:
SELECT *
FROM E1
WHERE EMP_DOB < '01-JAN-1960';
UNION
SELECT *
FROM E2
WHERE EMP_DOB < '01-JAN-1960';
UNION
SELECT *
FROM E 3
WHERE EMP_DOB < '01-JAN-1960';
Case 3: The Database Supports Local Mapping Transparency
Both the fragment name and its location must be specified in the query. Using pseudo-SQL:
SELECT *
FROM El NODE NY
WHERE EMP_DOB < '01-JAN-1960';
UNION
SELECT *
FROM E2 NODE ATL
WHERE EMP_DOB < '01-JAN-1960';
UNION
SELECT *
FROM E3 NODE MIA
WHERE EMP_DOB < '01-JAN-1960';

DISTRIBUTED DATABASE DESIGN

Whether the database is centralized or distributed, the design principles and concepts are still
applicable. However, the design of a distributed database introduces three new issues:
 How to partition the database into fragments.
 Which fragments to replicate.
 Where to locate those fragments and replicas.
Data fragmentation and data replication deal with the first two issues, and data allocation
deals with the third issue.

Data Fragmentation
Data fragmentation allows you to break a single object into two or more segments, or
fragments. The object might be a user’s database, a system database, or a table. Each fragment
can be stored at any site over a computer network.
Information about data fragmentation is stored in the distributed data catalog (DDC), from
which it is accessed by the TP to process user requests.
Data fragmentation strategies, as discussed here, are based at the table level and consist of
dividing a table into logical fragments. You will explore three types of data fragmentation
strategies: horizontal, vertical, and mixed. (Keep in mind that a fragmented table can always
be re-created from its fragmented parts by a combination of unions and joins.)
Horizontal fragmentation refers to the division of a relation into subsets (fragments) of
tuples (rows). Each fragment is stored at a different node, and each fragment has unique rows.
However, the unique rows all have the same attributes (columns). In short, each fragment
represents the equivalent of a SELECT statement, with the WHERE clause on a single
attribute.
Vertical fragmentation refers to the division of a relation into attribute (column) subsets.
Each subset (fragment) is stored at a different node, and each fragment has unique columns—
with the exception of the key column, which is common to all fragments. This is the
equivalent of the PROJECT statement in SQL.
Mixed fragmentation refers to a combination of horizontal and vertical strategies. In other
words, a table may be divided into several horizontal subsets (rows), each one having a subset
of the attributes (columns).
Horizontal Fragmentation
Suppose that XYZ Company’s corporate management requires information about its
customers in all three states, but company locations in each state (TN, FL, and GA) require
data regarding local customers only. Based on such requirements, you decide to distribute the
data by state. Therefore, you define the horizontal fragments to conform to
the structure shown in Table 12.5.

Each horizontal fragment may have a different number of rows, but each fragment must have
the same attributes. The resulting fragments yield the three tables depicted in Figure 12.16.

Vertical Fragmentation
You may also divide the CUSTOMER relation into vertical fragments that are composed of a
collection of attributes.
For example, suppose that the company is divided into two departments: the service
department and the collections department. Each department is located in a separate building,
and each has an interest in only a few of the CUSTOMER table’s attributes. In this case, the
fragments are defined as shown in Table 12.6.

Each vertical fragment must have the same number of rows, but the inclusion of the different
attributes depends on the key column. The vertical fragmentation results are displayed in
Figure 12.17. Note that the key attribute
(CUS_NUM) is common to both fragments CUST_V1 and CUST_V2.

Mixed Fragmentation
The XYZ Company’s structure requires that the CUSTOMER data be fragmented
horizontally to accommodate the various company locations; within the locations, the data
must be fragmented vertically to accommodate the two departments (service and collection).
In short, the CUSTOMER table requires mixed fragmentation.
Mixed fragmentation requires a two-step procedure. First, horizontal fragmentation is
introduced for each site based on the location within a state (CUS_STATE). The horizontal
fragmentation yields the subsets of customer tuples (horizontal fragments) that are located at
each site. Because the departments are located in different buildings, vertical
fragmentation is used within each horizontal fragment to divide the attributes, thus meeting
each department’s information needs at each subsite. Mixed fragmentation yields the results
displayed in Table 12.7.