Architecture for Distributed Database

A reference architecture for distributed database is shown in Fig.1. This architecture is

not explicitly implemented in all distributed databases. The levels are conceptually
relevant in order to understand

Global Schema

Site
Fragmentation independent
schema schemes

Allocation
schema

Local Local (other sites)

mapping mapping .
schema 1 schema 2 .
.

DBMS of DBMS of
site 1 site 2

Local Local
database database
at site 1 at site 2

Fig.1. A reference architecture for distributed databases

The global schema defines all the data which are contained in the distributed database
as if the database were not distributed at all. The global schema consists of the definition
of a set of global relations using relational model.

Each global relation can be split into several non overlapping portions which are called
fragments. The mapping between global relations and fragments is defined in the
fragmentation schema. This mapping is one to many i.e. one global relation has many
fragments but one fragment corresponds to one global relation only. For example R i
indicates the ith fragment of global relation R. Fragments are logical portions of global
relations which are physically located at one or several sites of the network.

The allocation schema defines at which site(s) a fragment is located. All the fragments
which correspond to the same global relation R and are located at the same site j
constitute the physical image of global relation R at site j. Here Rj indicates the physical
image of the global relation R at site j.

An example of the relationship between the object types defined above is shown in Fig.
2. A global relation R is split into four fragments R 1, R2, R3, R4. These four fragments are
allocated redundantly at the three sites of a computer network. Consequently three
physical images are made named as R1, R2, and R3. Hence R23 indicates the copy of
fragment R2 which is located at site 3.
 R 11

R R 21
R1

R12

R2

R 22
R3

R4 R 23

R 33

R 43

Global relation Fragments Physical

images

Fig. 2 Fragments and physical images for a

global relation.

Once again referring Fig.1 it can be said that the top three levels are site independent and
hence do not depend on the data model of the local DBMSs. At a lower level, it is
necessary to map the physical images to the objects which are manipulated by the local
DBMSs. This mapping is called a local mapping schema and depends on the type of local
DBMS. So in a heterogeneous system there may be different types of local mappings at
different sites.

This architecture provides a very general conceptual framework for understanding

distributed databases. The three most important objectives which motivate the features of
this architecture are the separation of data fragmentation and allocation, the control of
redundancy and the independence from local DBMSs.
1. Separating the concept of data fragmentation from the concept of data
allocation

This separation allows us to distinguish two different levels of distribution transparency

such as fragmentation transparency and location transparency. Fragmentation
transparency is the highest degree of transparency and consists of the fact that the user or
application programmer works on global relations. Location transparency is a lower
degree of transparency and requires the user or application programmer to work on
fragments instead of global relations but the information about the locations of fragments
will still remain unknown to the user.

2. Explicit control of redundancy

The architecture provides explicit control of redundancy at the fragment level.

3. Independence from local DBMSs

This feature called as local mapping transparency allows us to study several problems
of distributed database management without having to take into account the specific data
models of local DBMSs.

Other than the said transparency there are other transparencies as well. These
transparencies such as replication transparency and location transparency etc. which will
be discussed later.

Rules to be followed when defining fragments

Although the process of fragmentation along with examples will be discussed during
distributed database design, the general guideline is mentioned here as a part of the
reference architecture.

Completeness condition All the data of the global relation must be mapped into the
fragments i.e. it must not happen that a data item which belongs to a global relation does
not belong to any fragment.

Reconstruction condition It must always be possible to reconstruct each global relation

from its fragments. The necessity of this condition is obvious. In fact, only fragments are
stored in the distributed database and global relation has to be built through this
reconstruction operation if necessary.

Disjointness condition It is convenient that fragments be disjoint so that the replication

of data can be controlled explicitly at the allocation level. This condition is useful mainly
with horizontal fragmentation while for vertical fragmentation sometimes this condition
may be violated.
An application :

Let us consider a simple query called SUPENQUIRY. It accepts a supplier number from
a terminal, finds the corresponding supplier name and displays it at the terminal. The
application is written using a PASCAL-like language with embedded SQL statements for
database access.

The way in which the application accesses the database if the DDBMS provides
fragmentation transparency is shown in Fig. 3 a) and code.

SUPPLIER1 Site 1
DDBMS

SUPPLIER2 Site 2

SUPPLIER2 Site 3

Fig. 3 a) Fragmentation Transparency (level 1)

Code : read (terminal, $SNUM);

select NAME into $NAME
from SUPPLIER
where SNUM = $SNUM;
write(terminal, $NAME)
The following Fig. 3 b) shows the same application as above if the DDBMS provides
location transparency but not fragmentation transparency.

SUPPLIER1 Site 1
DDBMS

either SUPPLIER2 Site 2

or
SUPPLIER2 Site 3

Fig. 3 b) Location Transparency (level 2)

Code : read(terminal, $SNUM);

select NAME into $NAME
from SUPPLIER1
where SNUM = $SNUM;
if not #FOUND then
select NAME into $NAME
from SUPPLIER2
where SNUM = $SNUM;
write(terminal, $NAME)
The following Fig. 3 c) shows neither fragmentation transparency nor location
transparency but local mapping transparency i.e. it is not known whether execution at
different sites takes place under CODASYL or IMS etc.

DDBMS Site 1
SUPPLIER1

SUPPLIER2 Site 3

Fig. 3 c) Local Mapping Transparency (level 3)

Code :
read(terminal, $SNUM);
select NAME into $NAME
from SUPPLIER1 at Site 1
where SNUM = $SNUM;
if not #FOUND then
select NAME into $NAME
from SUPPLIER2 at Site 3
where SNUM = $SNUM;
write(terminal, $NAME)