Distributed Databases

A distributed database is a collection of multiple interconnected databases, which are

spread physically across various locations that communicate via a computer network.

Features
 Databases in the collection are logically interrelated with each other. Often they
represent a single logical database.

 Data is physically stored across multiple sites. Data in each site can be managed by a
DBMS independent of the other sites.

 The processors in the sites are connected via a network. They do not have any
multiprocessor configuration.

 A distributed database is not a loosely connected file system.

 A distributed database incorporates transaction processing, but it is not synonymous

with a transaction processing system.

Distributed Database Management System

A distributed database management system (DDBMS) is a centralized software system that
manages a distributed database in a manner as if it were all stored in a single location.

Features
 It is used to create, retrieve, update and delete distributed databases.

 It synchronizes the database periodically and provides access mechanisms by the

virtue of which the distribution becomes transparent to the users.

 It ensures that the data modified at any site is universally updated.

 It is used in application areas where large volumes of data are processed and accessed
by numerous users simultaneously.

 It is designed for heterogeneous database platforms.

 It maintains confidentiality and data integrity of the databases.

Factors Encouraging DDBMS

The following factors encourage moving over to DDBMS −

 Distributed Nature of Organizational Units − Most organizations in the current

times are subdivided into multiple units that are physically distributed over the globe.
Each unit requires its own set of local data. Thus, the overall database of the
organization becomes distributed.
  Need for Sharing of Data − The multiple organizational units often need to
communicate with each other and share their data and resources. This demands
common databases or replicated databases that should be used in a synchronized
manner.

 Support for Both OLTP and OLAP − Online Transaction Processing (OLTP) and
Online Analytical Processing (OLAP) work upon diversified systems which may have
common data. Distributed database systems aid both these processing by providing
synchronized data.

 Database Recovery − One of the common techniques used in DDBMS is replication

of data across different sites. Replication of data automatically helps in data recovery
if database in any site is damaged. Users can access data from other sites while the
damaged site is being reconstructed. Thus, database failure may become almost
inconspicuous to users.

 Support for Multiple Application Software − Most organizations use a variety of

application software each with its specific database support. DDBMS provides a uniform
functionality for using the same data among different platforms.

Advantages of Distributed Databases

Following are the advantages of distributed databases over centralized databases.

Modular Development − If the system needs to be expanded to new locations or new units,
in centralized database systems, the action requires substantial efforts and disruption in the
existing functioning. However, in distributed databases, the work simply requires adding new
computers and local data to the new site and finally connecting them to the distributed
system, with no interruption in current functions.

More Reliable − In case of database failures, the total system of centralized databases
comes to a halt. However, in distributed systems, when a component fails, the functioning of
the system continues may be at a reduced performance. Hence DDBMS is more reliable.

Better Response − If data is distributed in an efficient manner, then user requests can be
met from local data itself, thus providing faster response. On the other hand, in centralized
systems, all queries have to pass through the central computer for processing, which
increases the response time.

Lower Communication Cost − In distributed database systems, if data is located locally

where it is mostly used, then the communication costs for data manipulation can be
minimized. This is not feasible in centralized systems.

Adversities of Distributed Databases

Following are some of the adversities associated with distributed databases.

 Need for complex and expensive software − DDBMS demands complex and often
expensive software to provide data transparency and co-ordination across the several
sites.

 Processing overhead − Even simple operations may require a large number of

communications and additional calculations to provide uniformity in data across the
sites.

 Data integrity − The need for updating data in multiple sites pose problems of data
integrity.

 Overheads for improper data distribution − Responsiveness of queries is largely

dependent upon proper data distribution. Improper data distribution often leads to very
slow response to user requests.

Types of Distributed Databases

Distributed databases can be broadly classified into homogeneous and heterogeneous
distributed database environments, each with further sub-divisions, as shown in the following
illustration.

Homogeneous Distributed Databases

In a homogeneous distributed database, all the sites use identical DBMS and operating
systems. Its properties are −

 The sites use very similar software.

 The sites use identical DBMS or DBMS from the same vendor.
  Each site is aware of all other sites and cooperates with other sites to process user
requests.

 The database is accessed through a single interface as if it is a single database.

Types of Homogeneous Distributed Database

There are two types of homogeneous distributed database −

 Autonomous − Each database is independent that functions on its own. They are
integrated by a controlling application and use message passing to share data updates.

 Non-autonomous − Data is distributed across the homogeneous nodes and a central

or master DBMS co-ordinates data updates across the sites.

Heterogeneous Distributed Databases

In a heterogeneous distributed database, different sites have different operating systems,
DBMS products and data models. Its properties are −

 Different sites use dissimilar schemas and software.

 The system may be composed of a variety of DBMSs like relational, network,

hierarchical or object oriented.

 Query processing is complex due to dissimilar schemas.

 Transaction processing is complex due to dissimilar software.

 A site may not be aware of other sites and so there is limited co-operation in processing
user requests.

Types of Heterogeneous Distributed Databases

 Federated − The heterogeneous database systems are independent in nature and
integrated together so that they function as a single database system.

 Un-federated − The database systems employ a central coordinating module through

which the databases are accessed.

Distributed DBMS Architectures

DDBMS architectures are generally developed depending on three parameters −

 Distribution − It states the physical distribution of data across the different sites.

 Autonomy − It indicates the distribution of control of the database system and the
degree to which each constituent DBMS can operate independently.

 Heterogeneity − It refers to the uniformity or dissimilarity of the data models, system

components and databases.
 Architectural Models
Some of the common architectural models are −

 Client - Server Architecture for DDBMS

 Peer - to - Peer Architecture for DDBMS

 Multi - DBMS Architecture

Client - Server Architecture for DDBMS
This is a two-level architecture where the functionality is divided into servers and clients. The
server functions primarily encompass data management, query processing, optimization and
transaction management. Client functions include mainly user interface. However, they have
some functions like consistency checking and transaction management.

The two different client - server architecture are −

 Single Server Multiple Client

 Multiple Server Multiple Client (shown in the following diagram)

Peer- to-Peer Architecture for DDBMS

In these systems, each peer acts both as a client and a server for imparting database services.
The peers share their resource with other peers and co-ordinate their activities.

This architecture generally has four levels of schemas −

  Global Conceptual Schema − Depicts the global logical view of data.

 Local Conceptual Schema − Depicts logical data organization at each site.

 Local Internal Schema − Depicts physical data organization at each site.

 External Schema − Depicts user view of data.

Multi - DBMS Architectures

This is an integrated database system formed by a collection of two or more autonomous
database systems.

Multi-DBMS can be expressed through six levels of schemas −

 Multi-database View Level − Depicts multiple user views comprising of subsets of

the integrated distributed database.

 Multi-database Conceptual Level − Depicts integrated multi-database that

comprises of global logical multi-database structure definitions.

 Multi-database Internal Level − Depicts the data distribution across different sites
and multi-database to local data mapping.

 Local database View Level − Depicts public view of local data.

 Local database Conceptual Level − Depicts local data organization at each site.

 Local database Internal Level − Depicts physical data organization at each site.
There are two design alternatives for multi-DBMS −

 Model with multi-database conceptual level.

 Model without multi-database conceptual level.

Data Replication
Data replication is the process of storing separate copies of the database at two or more sites.
It is a popular fault tolerance technique of distributed databases.

Advantages of Data Replication

 Reliability − In case of failure of any site, the database system continues to work
since a copy is available at another site(s).
  Reduction in Network Load − Since local copies of data are available, query
processing can be done with reduced network usage, particularly during prime hours.
Data updating can be done at non-prime hours.

 Quicker Response − Availability of local copies of data ensures quick query

processing and consequently quick response time.

 Simpler Transactions − Transactions require less number of joins of tables located

at different sites and minimal coordination across the network. Thus, they become
simpler in nature.

Disadvantages of Data Replication

 Increased Storage Requirements − Maintaining multiple copies of data is
associated with increased storage costs. The storage space required is in multiples of
the storage required for a centralized system.

 Increased Cost and Complexity of Data Updating − Each time a data item is
updated, the update needs to be reflected in all the copies of the data at the different
sites. This requires complex synchronization techniques and protocols.

 Undesirable Application – Database coupling − If complex update mechanisms

are not used, removing data inconsistency requires complex co-ordination at
application level. This results in undesirable application – database coupling.

Some commonly used replication techniques are −

 Snapshot replication

 Near-real-time replication

 Pull replication

Fragmentation
Fragmentation is the task of dividing a table into a set of smaller tables. The subsets of the
table are called fragments. Fragmentation can be of three types: horizontal, vertical, and
hybrid (combination of horizontal and vertical). Horizontal fragmentation can further be
classified into two techniques: primary horizontal fragmentation and derived horizontal
fragmentation.

Fragmentation should be done in a way so that the original table can be reconstructed from
the fragments. This is needed so that the original table can be reconstructed from the
fragments whenever required. This requirement is called “reconstructiveness.”

Advantages of Fragmentation
  Since data is stored close to the site of usage, efficiency of the database system is
increased.

 Local query optimization techniques are sufficient for most queries since data is locally
available.

 Since irrelevant data is not available at the sites, security and privacy of the database
system can be maintained.

Disadvantages of Fragmentation
 When data from different fragments are required, the access speeds may be very high.

 In case of recursive fragmentations, the job of reconstruction will need expensive

techniques.

 Lack of back-up copies of data in different sites may render the database ineffective in
case of failure of a site.

Vertical Fragmentation
In vertical fragmentation, the fields or columns of a table are grouped into fragments. In order
to maintain reconstructiveness, each fragment should contain the primary key field(s) of the
table. Vertical fragmentation can be used to enforce privacy of data.

For example, let us consider that a University database keeps records of all registered
students in a Student table having the following schema.

STUDENT

Regd_No Name Course Address Semester Fees Marks

Now, the fees details are maintained in the accounts section. In this case, the designer will
fragment the database as follows −

CREATE TABLE STD_FEES AS

SELECT Regd_No, Fees

FROM STUDENT;

Horizontal Fragmentation
Horizontal fragmentation groups the tuples of a table in accordance to values of one or more
fields. Horizontal fragmentation should also confirm to the rule of reconstructiveness. Each
horizontal fragment must have all columns of the original base table.
For example, in the student schema, if the details of all students of Computer Science Course
needs to be maintained at the School of Computer Science, then the designer will horizontally
fragment the database as follows −

CREATE COMP_STD AS

SELECT * FROM STUDENT

WHERE COURSE = "Computer Science";

Hybrid Fragmentation
In hybrid fragmentation, a combination of horizontal and vertical fragmentation techniques
are used. This is the most flexible fragmentation technique since it generates fragments with
minimal extraneous information. However, reconstruction of the original table is often an
expensive task.

Hybrid fragmentation can be done in two alternative ways −

 At first, generate a set of horizontal fragments; then generate vertical fragments from
one or more of the horizontal fragments.

 At first, generate a set of vertical fragments; then generate horizontal fragments from
one or more of the vertical fragments.
 Design Alternatives
The distribution design alternatives for the tables in a DDBMS are as follows −

 Non-replicated and non-fragmented

 Fully replicated

 Partially replicated

 Fragmented

 Mixed
Non-replicated & Non-fragmented
In this design alternative, different tables are placed at different sites. Data is placed so that
it is at a close proximity to the site where it is used most. It is most suitable for database
systems where the percentage of queries needed to join information in tables placed at
different sites is low. If an appropriate distribution strategy is adopted, then this design
alternative helps to reduce the communication cost during data processing.

Fully Replicated
In this design alternative, at each site, one copy of all the database tables is stored. Since,
each site has its own copy of the entire database, queries are very fast requiring negligible
communication cost. On the contrary, the massive redundancy in data requires huge cost
during update operations. Hence, this is suitable for systems where a large number of queries
is required to be handled whereas the number of database updates is low.

Partially Replicated
Copies of tables or portions of tables are stored at different sites. The distribution of the tables
is done in accordance to the frequency of access. This takes into consideration the fact that
the frequency of accessing the tables vary considerably from site to site. The number of copies
of the tables (or portions) depends on how frequently the access queries execute and the site
which generate the access queries.

Fragmented
In this design, a table is divided into two or more pieces referred to as fragments or partitions,
and each fragment can be stored at different sites. This considers the fact that it seldom
happens that all data stored in a table is required at a given site. Moreover, fragmentation
increases parallelism and provides better disaster recovery. Here, there is only one copy of
each fragment in the system, i.e. no redundant data.

The three fragmentation techniques are −

 Vertical fragmentation
  Horizontal fragmentation

 Hybrid fragmentation
Mixed Distribution
This is a combination of fragmentation and partial replications. Here, the tables are
initially fragmented in any form (horizontal or vertical), and then these fragments
are partially replicated across the frequency of accessing the fragments.

Distributed DBMS - Replication Control

In order to maintain mutually consistent data in all sites, replication control techniques need
to be adopted. There are two approaches for replication control, namely −

 Synchronous Replication Control

 Asynchronous Replication Control

Synchronous Replication Control

In synchronous replication approach, the database is synchronized so that all the replications
always have the same value. A transaction requesting a data item will have access to the
same value in all the sites. To ensure this uniformity, a transaction that updates a data item
is expanded so that it makes the update in all the copies of the data item. Generally, two-
phase commit protocol is used for the purpose.

For example, let us consider a data table PROJECT(PId, PName, PLocation). We need to run
a transaction T1 that updates PLocation to ‘Mumbai’, if PLocation is ‘Bombay’. If no replications
are there, the operations in transaction T1 will be −

Begin T1:

Update PROJECT Set PLocation = 'Mumbai'

Where PLocation = 'Bombay';

End T1;

If the data table has two replicas in Site A and Site B, T1 needs to spawn two children T1A
and T1B corresponding to the two sites. The expanded transaction T1 will be −

Begin T1:

Begin T1A :

Update PROJECT Set PLocation = 'Mumbai'

Where PLocation = 'Bombay';

End T1A;
 Begin T2A :

Update PROJECT Set PLocation = 'Mumbai'

Where PLocation = 'Bombay';

End T2A;

End T1;

Asynchronous Replication Control

In asynchronous replication approach, the replicas do not always maintain the same value.
One or more replicas may store an outdated value, and a transaction can see the different
values. The process of bringing all the replicas to the current value is called synchronization.

A popular method of synchronization is store and forward method. In this method, one site is
designated as the primary site and the other sites are secondary sites. The primary site always
contains updated values. All the transactions first enter the primary site. These transactions
are then queued for application in the secondary sites. The secondary sites are updated using
rollout method only when a transaction is scheduled to execute on it.

Replication Control Algorithms

Some of the replication control algorithms are −

 Master-slave replication control algorithm.

 Distributed voting algorithm.

 Majority consensus algorithm.

 Circulating token algorithm.

Master-Slave Replication Control Algorithm
There is one master site and ‘N’ slave sites. A master algorithm runs at the master site to
detect conflicts. A copy of slave algorithm runs at each slave site. The overall algorithm
executes in the following two phases −

 Transaction acceptance/rejection phase − When a transaction enters the

transaction monitor of a slave site, the slave site sends a request to the master site.
The master site checks for conflicts. If there aren’t any conflicts, the master sends an
“ACK+” message to the slave site which then starts the transaction application phase.
Otherwise, the master sends an “ACK-” message to the slave which then rejects the
transaction.
  Transaction application phase − Upon entering this phase, the slave site where
transaction has entered broadcasts a request to all slaves for executing the transaction.
On receiving the requests, the peer slaves execute the transaction and send an “ACK”
to the requesting slave on completion. After the requesting slave has received “ACK”
messages from all its peers, it sends a “DONE” message to the master site. The master
understands that the transaction has been completed and removes it from the pending
queue.

Distributed Voting Algorithm

This comprises of ‘N’ peer sites, all of whom must “OK” a transaction before it starts executing.
Following are the two phases of this algorithm −

 Distributed transaction acceptance phase − When a transaction enters the

transaction manager of a site, it sends a transaction request to all other sites. On
receiving a request, a peer site resolves conflicts using priority based voting rules. If
all the peer sites are “OK” with the transaction, the requesting site starts application
phase. If any of the peer sites does not “OK” a transaction, the requesting site rejects
the transaction.

 Distributed transaction application phase − Upon entering this phase, the site
where the transaction has entered, broadcasts a request to all slaves for executing the
transaction. On receiving the requests, the peer slaves execute the transaction and
send an “ACK” message to the requesting slave on completion. After the requesting
slave has received “ACK” messages from all its peers, it lets the transaction manager
know that the transaction has been completed.

Majority Consensus Algorithm

This is a variation from the distributed voting algorithm, where a transaction is allowed to
execute when a majority of the peers “OK” a transaction. This is divided into three phases −

 Voting phase − When a transaction enters the transaction manager of a site, it sends
a transaction request to all other sites. On receiving a request, a peer site tests for
conflicts using voting rules and keeps the conflicting transactions, if any, in pending
queue. Then, it sends either an “OK” or a “NOT OK” message.

 Transaction acceptance/rejection phase − If the requesting site receives a

majority “OK” on the transaction, it accepts the transaction and broadcasts “ACCEPT”
to all the sites. Otherwise, it broadcasts “REJECT” to all the sites and rejects the
transaction.

 Transaction application phase − When a peer site receives a “REJECT” message, it

removes this transaction from its pending list and reconsiders all deferred transactions.
 When a peer site receives an “ACCEPT” message, it applies the transaction and rejects
all the deferred transactions in the pending queue which are in conflict with this
transaction. It sends an “ACK” to the requesting slave on completion.

Circulating Token Algorithm

In this approach the transactions in the system are serialized using a circulating token and
executed accordingly against every replica of the database. Thus, all the transactions are
accepted, i.e. none is rejected. This has two phases −

 Transaction serialization phase − In this phase, all transactions are scheduled to

run in a serialization order. Each transaction in each site is assigned a unique ticket
from a sequential series, indicating the order of transaction. Once a transaction has
been assigned a ticket, it is broadcasted to all the sites.

 Transaction application phase − When a site receives a transaction along with its
ticket, it places the transaction for execution according to its ticket. After the
transaction has finished execution, this site broadcasts an appropriate message. A
transaction ends when it has completed execution in all the sites.

Distribution Transparency
Distribution transparency is the property of distributed databases by the virtue of which the
internal details of the distribution are hidden from the users. The DDBMS designer may choose
to fragment tables, replicate the fragments and store them at different sites. However, since
users are oblivious of these details, they find the distributed database easy to use like any
centralized database.

The three dimensions of distribution transparency are −

 Location transparency

 Fragmentation transparency

 Replication transparency

Location Transparency
Location transparency ensures that the user can query on any table(s) or fragment(s) of a
table as if they were stored locally in the user’s site. The fact that the table or its fragments
are stored at remote site in the distributed database system, should be completely oblivious
to the end user. The address of the remote site(s) and the access mechanisms are completely
hidden.
In order to incorporate location transparency, DDBMS should have access to updated and
accurate data dictionary and DDBMS directory which contains the details of locations of data.

Fragmentation Transparency
Fragmentation transparency enables users to query upon any table as if it were
unfragmented. Thus, it hides the fact that the table the user is querying on is actually a
fragment or union of some fragments. It also conceals the fact that the fragments are located
at diverse sites.

This is somewhat similar to users of SQL views, where the user may not know that they are
using a view of a table instead of the table itself.

Replication Transparency
Replication transparency ensures that replication of databases are hidden from the users. It
enables users to query upon a table as if only a single copy of the table exists.

Replication transparency is associated with concurrency transparency and failure

transparency. Whenever a user updates a data item, the update is reflected in all the copies
of the table. However, this operation should not be known to the user. This is concurrency
transparency. Also, in case of failure of a site, the user can still proceed with his queries using
replicated copies without any knowledge of failure. This is failure transparency.

Combination of Transparencies
In any distributed database system, the designer should ensure that all the stated
transparencies are maintained to a considerable extent. The designer may choose to fragment
tables, replicate them and store them at different sites; all oblivious to the end user. However,
complete distribution transparency is a tough task and requires considerable design efforts.

Transaction Processing Systems

Transactions
A transaction is a program including a collection of database operations, executed as a logical
unit of data processing. The operations performed in a transaction include one or more of
database operations like insert, delete, update or retrieve data. It is an atomic process that
is either performed into completion entirely or is not performed at all. A transaction involving
only data retrieval without any data update is called read-only transaction.

Each high level operation can be divided into a number of low level tasks or operations. For
example, a data update operation can be divided into three tasks −

 read_item() − reads data item from storage to main memory.

  modify_item() − change value of item in the main memory.

 write_item() − write the modified value from main memory to storage.

Database access is restricted to read_item() and write_item() operations. Likewise, for all
transactions, read and write forms the basic database operations.

Transaction Operations
The low level operations performed in a transaction are −

 begin_transaction − A marker that specifies start of transaction execution.

 read_item or write_item − Database operations that may be interleaved with main

memory operations as a part of transaction.

 end_transaction − A marker that specifies end of transaction.

 commit − A signal to specify that the transaction has been successfully completed in
its entirety and will not be undone.

 rollback − A signal to specify that the transaction has been unsuccessful and so all
temporary changes in the database are undone. A committed transaction cannot be
rolled back.

Transaction States
A transaction may go through a subset of five states, active, partially committed, committed,
failed and aborted.

 Active − The initial state where the transaction enters is the active state. The
transaction remains in this state while it is executing read, write or other operations.

 Partially Committed − The transaction enters this state after the last statement of
the transaction has been executed.

 Committed − The transaction enters this state after successful completion of the
transaction and system checks have issued commit signal.

 Failed − The transaction goes from partially committed state or active state to failed
state when it is discovered that normal execution can no longer proceed or system
checks fail.

 Aborted − This is the state after the transaction has been rolled back after failure and
the database has been restored to its state that was before the transaction began.

The following state transition diagram depicts the states in the transaction and the low level
transaction operations that causes change in states.
 Desirable Properties of Transactions
Any transaction must maintain the ACID properties, viz. Atomicity, Consistency, Isolation,
and Durability.

 Atomicity − This property states that a transaction is an atomic unit of processing,

that is, either it is performed in its entirety or not performed at all. No partial update
should exist.

 Consistency − A transaction should take the database from one consistent state to
another consistent state. It should not adversely affect any data item in the database.

 Isolation − A transaction should be executed as if it is the only one in the system.

There should not be any interference from the other concurrent transactions that are
simultaneously running.

 Durability − If a committed transaction brings about a change, that change should be

durable in the database and not lost in case of any failure.

Schedules and Conflicts

In a system with a number of simultaneous transactions, a schedule is the total order of
execution of operations. Given a schedule S comprising of n transactions, say T1, T2,
T3………..Tn; for any transaction Ti, the operations in Ti must execute as laid down in the
schedule S.

Types of Schedules
There are two types of schedules −
  Serial Schedules − In a serial schedule, at any point of time, only one transaction is
active, i.e. there is no overlapping of transactions. This is depicted in the following
graph −

 Parallel Schedules − In parallel schedules, more than one transactions are active
simultaneously, i.e. the transactions contain operations that overlap at time. This is
depicted in the following graph −

Conflicts in Schedules
In a schedule comprising of multiple transactions, a conflict occurs when two active
transactions perform non-compatible operations. Two operations are said to be in conflict,
when all of the following three conditions exists simultaneously −

 The two operations are parts of different transactions.

 Both the operations access the same data item.

 At least one of the operations is a write_item() operation, i.e. it tries to modify the
data item.

Serializability
A serializable schedule of ‘n’ transactions is a parallel schedule which is equivalent to a
serial schedule comprising of the same ‘n’ transactions. A serializable schedule contains the
correctness of serial schedule while ascertaining better CPU utilization of parallel schedule.

Equivalence of Schedules
Equivalence of two schedules can be of the following types −

 Result equivalence − Two schedules producing identical results are said to be result
equivalent.

 View equivalence − Two schedules that perform similar action in a similar manner
are said to be view equivalent.

 Conflict equivalence − Two schedules are said to be conflict equivalent if both contain
the same set of transactions and has the same order of conflicting pairs of operations.

Controlling Concurrency
Concurrency controlling techniques ensure that multiple transactions are executed
simultaneously while maintaining the ACID properties of the transactions and serializability in
the schedules.

In this chapter, we will study the various approaches for concurrency control.

Locking Based Concurrency Control Protocols

Locking-based concurrency control protocols use the concept of locking data items. A lock is
a variable associated with a data item that determines whether read/write operations can be
performed on that data item. Generally, a lock compatibility matrix is used which states
whether a data item can be locked by two transactions at the same time.

Locking-based concurrency control systems can use either one-phase or two-phase locking
protocols.

One-phase Locking Protocol

In this method, each transaction locks an item before use and releases the lock as soon as it
has finished using it. This locking method provides for maximum concurrency but does not
always enforce serializability.

Two-phase Locking Protocol

In this method, all locking operations precede the first lock-release or unlock operation. The
transaction comprise of two phases. In the first phase, a transaction only acquires all the
locks it needs and do not release any lock. This is called the expanding or the growing phase.
In the second phase, the transaction releases the locks and cannot request any new locks.
This is called the shrinking phase.

Every transaction that follows two-phase locking protocol is guaranteed to be serializable.

However, this approach provides low parallelism between two conflicting transactions.

Timestamp Concurrency Control Algorithms

Timestamp-based concurrency control algorithms use a transaction’s timestamp to coordinate
concurrent access to a data item to ensure serializability. A timestamp is a unique identifier
given by DBMS to a transaction that represents the transaction’s start time.

These algorithms ensure that transactions commit in the order dictated by their timestamps.
An older transaction should commit before a younger transaction, since the older transaction
enters the system before the younger one.

Timestamp-based concurrency control techniques generate serializable schedules such that

the equivalent serial schedule is arranged in order of the age of the participating transactions.

Some of timestamp based concurrency control algorithms are −

 Basic timestamp ordering algorithm.

 Conservative timestamp ordering algorithm.

 Multiversion algorithm based upon timestamp ordering.

Timestamp based ordering follow three rules to enforce serializability −

 Access Rule − When two transactions try to access the same data item
simultaneously, for conflicting operations, priority is given to the older transaction. This
causes the younger transaction to wait for the older transaction to commit first.

 Late Transaction Rule − If a younger transaction has written a data item, then an
older transaction is not allowed to read or write that data item. This rule prevents the
older transaction from committing after the younger transaction has already
committed.

 Younger Transaction Rule − A younger transaction can read or write a data item
that has already been written by an older transaction.

Optimistic Concurrency Control Algorithm

In systems with low conflict rates, the task of validating every transaction for serializability
may lower performance. In these cases, the test for serializability is postponed to just before
commit. Since the conflict rate is low, the probability of aborting transactions which are not
serializable is also low. This approach is called optimistic concurrency control technique.

In this approach, a transaction’s life cycle is divided into the following three phases −

 Execution Phase − A transaction fetches data items to memory and performs

operations upon them.

 Validation Phase − A transaction performs checks to ensure that committing its

changes to the database passes serializability test.
  Commit Phase − A transaction writes back modified data item in memory to the disk.

This algorithm uses three rules to enforce serializability in validation phase −

Rule 1 − Given two transactions Ti and Tj, if Ti is reading the data item which Tj is writing,
then Ti’s execution phase cannot overlap with Tj’s commit phase. Tj can commit only after Ti
has finished execution.

Rule 2 − Given two transactions Ti and Tj, if Ti is writing the data item that Tj is reading, then
Ti’s commit phase cannot overlap with Tj’s execution phase. Tj can start executing only after
Ti has already committed.

Rule 3 − Given two transactions Ti and Tj, if Ti is writing the data item which Tj is also writing,
then Ti’s commit phase cannot overlap with Tj’s commit phase. Tj can start to commit only
after Ti has already committed.

Concurrency Control in Distributed Systems

In this section, we will see how the above techniques are implemented in a distributed
database system.

Distributed Two-phase Locking Algorithm

The basic principle of distributed two-phase locking is same as the basic two-phase locking
protocol. However, in a distributed system there are sites designated as lock managers. A
lock manager controls lock acquisition requests from transaction monitors. In order to enforce
co-ordination between the lock managers in various sites, at least one site is given the
authority to see all transactions and detect lock conflicts.

Depending upon the number of sites who can detect lock conflicts, distributed two-phase
locking approaches can be of three types −

 Centralized two-phase locking − In this approach, one site is designated as the

central lock manager. All the sites in the environment know the location of the central
lock manager and obtain lock from it during transactions.

 Primary copy two-phase locking − In this approach, a number of sites are

designated as lock control centers. Each of these sites has the responsibility of
managing a defined set of locks. All the sites know which lock control center is
responsible for managing lock of which data table/fragment item.

 Distributed two-phase locking − In this approach, there are a number of lock

managers, where each lock manager controls locks of data items stored at its local
site. The location of the lock manager is based upon data distribution and replication.

Distributed Timestamp Concurrency Control

In a centralized system, timestamp of any transaction is determined by the physical clock
reading. But, in a distributed system, any site’s local physical/logical clock readings cannot
be used as global timestamps, since they are not globally unique. So, a timestamp comprises
of a combination of site ID and that site’s clock reading.

For implementing timestamp ordering algorithms, each site has a scheduler that maintains a
separate queue for each transaction manager. During transaction, a transaction manager
sends a lock request to the site’s scheduler. The scheduler puts the request to the
corresponding queue in increasing timestamp order. Requests are processed from the front
of the queues in the order of their timestamps, i.e. the oldest first.

Conflict Graphs
Another method is to create conflict graphs. For this transaction classes are defined. A
transaction class contains two set of data items called read set and write set. A transaction
belongs to a particular class if the transaction’s read set is a subset of the class’ read set and
the transaction’s write set is a subset of the class’ write set. In the read phase, each
transaction issues its read requests for the data items in its read set. In the write phase, each
transaction issues its write requests.

A conflict graph is created for the classes to which active transactions belong. This contains a
set of vertical, horizontal, and diagonal edges. A vertical edge connects two nodes within a
class and denotes conflicts within the class. A horizontal edge connects two nodes across two
classes and denotes a write-write conflict among different classes. A diagonal edge connects
two nodes across two classes and denotes a write-read or a read-write conflict among two
classes.

The conflict graphs are analyzed to ascertain whether two transactions within the same class
or across two different classes can be run in parallel.

Distributed Optimistic Concurrency Control Algorithm

Distributed optimistic concurrency control algorithm extends optimistic concurrency control
algorithm. For this extension, two rules are applied −

Rule 1 − According to this rule, a transaction must be validated locally at all sites when it
executes. If a transaction is found to be invalid at any site, it is aborted. Local validation
guarantees that

the transaction maintains serializability at the sites where it has been executed. After a
transaction passes local validation test, it is globally validated.

Rule 2 − According to this rule, after a transaction passes local validation test, it should be
globally validated. Global validation ensures that if two conflicting transactions run together
at more than one site, they should commit in the same relative order at all the sites they run
together. This may require a transaction to wait for the other conflicting transaction, after
validation before commit. This requirement makes the algorithm less optimistic since a
transaction may not be able to commit as soon as it is validated at a site.

Commit Protocols
In a local database system, for committing a transaction, the transaction manager has to only
convey the decision to commit to the recovery manager. However, in a distributed system,
the transaction manager should convey the decision to commit to all the servers in the various
sites where the transaction is being executed and uniformly enforce the decision. When
processing is complete at each site, it reaches the partially committed transaction state and
waits for all other transactions to reach their partially committed states. When it receives the
message that all the sites are ready to commit, it starts to commit. In a distributed system,
either all sites commit or none of them does.

The different distributed commit protocols are −

 One-phase commit

 Two-phase commit

 Three-phase commit

Distributed One-phase Commit

Distributed one-phase commit is the simplest commit protocol. Let us consider that there is
a controlling site and a number of slave sites where the transaction is being executed. The
steps in distributed commit are −

 After each slave has locally completed its transaction, it sends a “DONE” message to
the controlling site.

 The slaves wait for “Commit” or “Abort” message from the controlling site. This waiting
time is called window of vulnerability.

 When the controlling site receives “DONE” message from each slave, it makes a
decision to commit or abort. This is called the commit point. Then, it sends this
message to all the slaves.

 On receiving this message, a slave either commits or aborts and then sends an
acknowledgement message to the controlling site.

Distributed Two-phase Commit

Distributed two-phase commit reduces the vulnerability of one-phase commit protocols. The
steps performed in the two phases are as follows −
Phase 1: Prepare Phase

 After each slave has locally completed its transaction, it sends a “DONE” message to
the controlling site. When the controlling site has received “DONE” message from all
slaves, it sends a “Prepare” message to the slaves.

 The slaves vote on whether they still want to commit or not. If a slave wants to commit,
it sends a “Ready” message.

 A slave that does not want to commit sends a “Not Ready” message. This may happen
when the slave has conflicting concurrent transactions or there is a timeout.

Phase 2: Commit/Abort Phase

 After the controlling site has received “Ready” message from all the slaves −

o The controlling site sends a “Global Commit” message to the slaves.

o The slaves apply the transaction and send a “Commit ACK” message to the
controlling site.

o When the controlling site receives “Commit ACK” message from all the slaves,
it considers the transaction as committed.

 After the controlling site has received the first “Not Ready” message from any slave −

o The controlling site sends a “Global Abort” message to the slaves.

o The slaves abort the transaction and send a “Abort ACK” message to the
controlling site.

o When the controlling site receives “Abort ACK” message from all the slaves, it
considers the transaction as aborted.

Distributed Three-phase Commit

The steps in distributed three-phase commit are as follows −

Phase 1: Prepare Phase

The steps are same as in distributed two-phase commit.

Phase 2: Prepare to Commit Phase

 The controlling site issues an “Enter Prepared State” broadcast message.

 The slave sites vote “OK” in response.

Phase 3: Commit / Abort Phase

The steps are same as two-phase commit except that “Commit ACK”/”Abort ACK” message is
not required.

What are distributed databases?

 Distributed database is a system in which storage devices are not connected to a
common processing unit.
 Database is controlled by Distributed Database Management System and data may be
stored at the same location or spread over the interconnected network. It is a loosely
coupled system.
 Shared nothing architecture is used in distributed databases.

 The above diagram is a typical example of distributed database system, in which

communication channel is used to communicate with the different locations and every
system has its own memory and database.

Goals of Distributed Database system.

The concept of distributed database was built with a goal to improve:

Reliability: In distributed database system, if one system fails down or stops working for
some time another system can complete the task.
Availability: In distributed database system reliability can be achieved even if sever fails
down. Another system is available to serve the client request.
Performance: Performance can be achieved by distributing database over different locations.
So the databases are available to every location which is easy to maintain.
Types of distributed databases.
The two types of distributed systems are as follows:

1. Homogeneous distributed databases system:

 Homogeneous distributed database system is a network of two or more databases

(With same type of DBMS software) which can be stored on one or more machines.
 So, in this system data can be accessed and modified simultaneously on several
databases in the network. Homogeneous distributed system are easy to handle.

Example: Consider that we have three departments using Oracle-9i for DBMS. If some
changes are made in one department then, it would update the other department also.

2. Heterogeneous distributed database system.

 Heterogeneous distributed database system is a network of two or more databases

with different types of DBMS software, which can be stored on one or more
machines.
 In this system data can be accessible to several databases in the network with the help
of generic connectivity (ODBC and JDBC).

Example: In the following diagram, different DBMS software are accessible to each
other using ODBC and JDBC.
 The basic types of distributed DBMS are as follows:

1. Client-server architecture of Distributed system.

 A client server architecture has a number of clients and a few servers

connected in a network.
 A client sends a query to one of the servers. The earliest available server
solves it and replies.
 A Client-server architecture is simple to implement and execute due to
centralized server system.

2. Collaborating server architecture.

 Collaborating server architecture is designed to run a single query on

multiple servers.
 Servers break single query into multiple small queries and the result is sent
to the client.
 Collaborating server architecture has a collection of database servers. Each
server is capable for executing the current transactions across the
databases.

3. Middleware architecture.

 Middleware architectures are designed in such a way that single query is

executed on multiple servers.
 This system needs only one server which is capable of managing queries
and transactions from multiple servers.
 Middleware architecture uses local servers to handle local queries and
transactions.
 The softwares are used for execution of queries and transactions across one
or more independent database servers, this type of software is called as
middleware.

What is fragmentation?

 The process of dividing the database into a smaller multiple parts is called
as fragmentation.
 These fragments may be stored at different locations.
 The data fragmentation process should be carrried out in such a way that
the reconstruction of original database from the fragments is possible.
Types of data Fragmentation

There are three types of data fragmentation:

1. Horizontal data fragmentation

Horizontal fragmentation divides a relation(table) horizontally into the group

of rows to create subsets of tables.

Example:
Account (Acc_No, Balance, Branch_Name, Type).
In this example if values are inserted in table Branch_Name as Pune, Baroda,
Delhi.

The query can be written as:

SELECT*FROM ACCOUNT WHERE Branch_Name= “Baroda”

Types of horizontal data fragmentation are as follows:

1) Primary horizontal fragmentation

Primary horizontal fragmentation is the process of fragmenting a single table,
row wise using a set of conditions.

Example:

Acc_No Balance Branch_Name

A_101 5000 Pune

A_102 10,000 Baroda

A_103 25,000 Delhi

For the above table we can define any simple condition like, Branch_Name=
'Pune', Branch_Name= 'Delhi', Balance < 50,000

Fragmentation1:
SELECT * FROM Account WHERE Branch_Name= 'Pune' AND Balance <
 50,000

Fragmentation2:
SELECT * FROM Account WHERE Branch_Name= 'Delhi' AND Balance <
50,000

2) Derived horizontal fragmentation

Fragmentation derived from the primary relation is called as derived
horizontal fragmentation.

Example: Refer the example of primary fragmentation given above.

The following fragmentation are derived from primary fragmentation.

Fragmentation1:
SELECT * FROM Account WHERE Branch_Name= 'Baroda' AND Balance <
50,000

Fragmentation2:
SELECT * FROM Account WHERE Branch_Name= 'Delhi' AND Balance <
50,000

3) Complete horizontal fragmentation

 The complete horizontal fragmentation generates a set of horizontal
fragmentation, which includes every table of original relation.
 Completeness is required for reconstruction of relation so that every table
belongs to at least one of the partitions.
4) Disjoint horizontal fragmentation
The disjoint horizontal fragmentation generates a set of horizontal
fragmentation in which no two fragments have common tables. That means
every table of relation belongs to only one fragment.

5) Reconstruction of horizontal fragmentation

Reconstruction of horizontal fragmentation can be performed using UNION
operation on fragments.
 2. Vertical Fragmentation

Vertical fragmentation divides a relation(table) vertically into groups of

columns to create subsets of tables.

Example:

Acc_No Balance Branch_Name

A_101 5000 Pune

A_102 10,000 Baroda

A_103 25,000 Delhi

Fragmentation1:
SELECT * FROM Acc_NO

Fragmentation2:
SELECT * FROM Balance

Complete vertical fragmentation

 The complete vertical fragmentation generates a set of vertical fragments,
which can include all the attributes of original relation.
 Reconstruction of vertical fragmentation is performed by using Full Outer
Join operation on fragments.

3) Hybrid Fragmentation

 Hybrid fragmentation can be achieved by performing horizontal and vertical

partition together.
 Mixed fragmentation is group of rows and columns in relation.

Example: Consider the following table which consists of employee

information.

Emp_ID Emp_Name Emp_Address Emp_Age Emp_Salary

101 Surendra Baroda 25 15000

 102 Jaya Pune 37 12000

103 Jayesh Pune 47 10000

Fragmentation1:
SELECT * FROM Emp_Name WHERE Emp_Age < 40

Fragmentation2:
SELECT * FROM Emp_Id WHERE Emp_Address= 'Pune' AND Salary <
14000

Reconstruction of Hybrid Fragmentation

The original relation in hybrid fragmentation is reconstructed by performing
UNION and FULL OUTER JOIN.

What is data replication?

Data replication is the process in which the data is copied at multiple

locations (Different computers or servers) to improve the availability of data.

Goals of data replication

Data replication is done with an aim to:

 Increase the availability of data.
 Speed up the query evaluation.

Types of data replication

There are two types of data replication:

1. Synchronous Replication:
In synchronous replication, the replica will be modified immediately after
some changes are made in the relation table. So there is no difference
between original data and replica.

2. Asynchronous replication:
 In asynchronous replication, the replica will be modified after commit is fired
on to the database.

Replication Schemes

The three replication schemes are as follows:

1. Full Replication

In full replication scheme, the database is available to almost every location

or user in communication network.

Advantages of full replication

 High availability of data, as database is available to almost every location.
 Faster execution of queries.
Disadvantages of full replication
 Concurrency control is difficult to achieve in full replication.
 Update operation is slower.

2. No Replication

No replication means, each fragment is stored exactly at one location.

 Advantages of no replication
 Concurrency can be minimized.
 Easy recovery of data.
Disadvantages of no replication
 Poor availability of data.
 Slows down the query execution process, as multiple clients are accessing
the same server.

3. Partial replication

Partial replication means only some fragments are replicated from the
database.
 Advantages of partial replication
The number of replicas created for fragments depend upon the importance of
data in that fragment.

Distributed databases - Query processing and Optimization

DDBMS processes and optimizes a query in terms of communication cost of

processing a distributed query and other parameters.

Various factors which are considered while processing a query are as

follows:

Costs of Data transfer

 This is a very important factor while processing queries. The intermediate

data is transferred to other location for data processing and the final result
will be sent to the location where the actual query is processing.
 The cost of data increases if the locations are connected via high
performance communicating channel.
 The DDBMS query optimization algorithms are used to minimize the cost of
data transfer.

Semi-join based query optimization

 Semi-join is used to reduce the number of relations in a table before

transferring it to another location.
 Only joining columns are transferred in this method.
 This method reduces the cost of data transfer.

Cost based query optimization

 Query optimization involves many operations like, selection, projection,

aggregation.
 Cost of communication is considered in query optimization.
 In centralized database system, the information of relations at remote
location is obtained from the server system catalogs.
 The data (query) which is manipulated at local location is considered as a
sub query to other global locations. This process estimates the total cost
which is needed to compute the intermediate relations.

Distributed Transactions

 A Distributed Databases Management System should be able to survive in a

system failure without losing any data in the database.
 This property is provided in transaction processing.
 The local transaction works only on own location(Local Location) where it is
considered as a global transaction for other locations.
 Transactions are assigned to transaction monitor which works as a
supervisor.
 A distributed transaction process is designed to distribute data over many
locations and transactions are carried out successfully or terminated
successfully.
 Transaction Processing is very useful for concurrent execution and recovery
of data.

What is recovery in distributed databases?

Recovery is the most complicated process in distributed databases. Recovery

of a failed system in the communication network is very difficult.

For example:
Consider that, location A sends message to location B and expects response
from B but B is unable to receive it. There are several problems for this
situation which are as follows.
 Message was failed due to failure in the network.
 Location B sent message but not delivered to location A.
 Location B crashed down.
 So it is actually very difficult to find the cause of failure in a large
communication network.
 Distributed commit in the network is also a serious problem which can affect
the recovery in a distributed databases.
 Two-phase commit protocol in Distributed databases

 Two-phase protocol is a type of atomic commitment protocol. This is a

distributed algorithm which can coordinate all the processes that participate
in the database and decide to commit or terminate the transactions. The
protocol is based on commit and terminate action.
 The two-phase protocol ensures that all participant which are accessing the
database server can receive and implement the same action (Commit or
terminate), in case of local network failure.
 Two-phase commit protocol provides automatic recovery mechanism in case
of a system failure.
 The location at which original transaction takes place is called as coordinator
and where the sub process takes place is called as Cohort.

Commit request:
In commit phase the coordinator attempts to prepare all cohorts and take
necessary steps to commit or terminate the transactions.

Commit phase:
The commit phase is based on voting of cohorts and the coordinator decides
to commit or terminate the transaction.

Concurrency problems in distributed databases.

Some problems which occur while accessing the database are as

follows:

1. Failure at local locations

When system recovers from failure the database is out dated compared to
other locations. So it is necessary to update the database.

2. Failure at communication location

System should have a ability to manage temporary failure in a
communicating network in distributed databases. In this case, partition
occurs which can limit the communication between two locations.
3. Dealing with multiple copies of data
It is very important to maintain multiple copies of distributed data at
different locations.

4. Distributed commit
While committing a transaction which is accessing databases stored on
multiple locations, if failure occurs on some location during the commit
process then this problem is called as distributed commit.

5. Distributed deadlock
Deadlock can occur at several locations due to recovery problem and
concurrency problem (multiple locations are accessing same system in the
communication network).

Concurrency Controls in distributed databases

There are three different ways of making distinguish copy of data by

applying:

1) Lock based protocol

A lock is applied to avoid concurrency problem between two transaction in
such a way that the lock is applied on one transaction and other transaction
can access it only when the lock is released. The lock is applied on write or
read operations. It is an important method to avoid deadlock.

2) Shared lock system (Read lock)

The transaction can activate shared lock on data to read its content. The lock
is shared in such a way that any other transaction can activate the shared
lock on the same data for reading purpose.

3) Exclusive lock
The transaction can activate exclusive lock on a data to read and write
operation. In this system, no other transaction can activate any kind of lock
on that same data.