Database System Architectures
 Transaction Server System
A typical transaction-server system today consists of multiple processes accessing data in shared memory.
Server processes: These are processes that receive user queries (transactions), execute them, and send the results
back.
Lock manager process: This process implements lock manager functionality, which includes lock grant, lock release,
and deadlock detection.
Database writer process: There are one or more processes that output modified buffer blocks back to disk on a
continuous basis.
Log writer process: This process outputs log records from the log record buffer to stable storage.
Checkpoint process: This process performs periodic checkpoints. It consults log to determine those transactions
that need to redone or undone.
Process monitor process: This process monitors other processes, and if any of them fails, it takes recovery actions
for the process.
 What is a Distributed Database System?
We define a distributed database as a collection of multiple, logically interrelated databases distributed over
a computer network. A distributed database management system (distributed DBMS) is then defined as the
software system that permits the management of the distributed database and makes the distribution
transparent to the users.
 Peer-to-Peer Distributed Systems

 Promises of DDBSs
 Transparent management of distributed and replicated data.
 Reliable access to data through distributed transactions
 Improved performance and
 Easier system expansion.
 Transparent Management of Distributed and Replicated Data
 Reliability through Distributed Transactions
 Improved Performance
 Easier System Expansion
 Complications Introduced by DDBS
1. Data may be replicated in a distributed environment. A distributed database can be designed so
that the entire database, or portions of it, reside at different sites of a computer network.
2. If some sites fail or if some communication links fail while an update is being executed, the system
must make sure that the effects will be reflected on the data residing at the failing or unreachable
sites as soon as the system can recover from the failure.
3. The exchange of messages and the additional computation required to achieve inter-site
coordination are a form of overhead that does not arise in centralized systems.
4. As data in a distributed DBMS are located at multiple sites, the probability of security lapses
increases. Further, all communications between different sites in a distributed DBMS are conveyed
through the network, so the underlying network has to be made secure to maintain system security.
5. Since each site cannot have instantaneous information on the actions currently being carried out at
the other sites, the synchronization of transactions on multiple sites is considerably harder than for
a centralized system.
 Correctness Rules for Data Fragmentation
To ensure no loss of information and no redundancy of data, there are three different rules that must be considered
during fragmentation.
Completeness
If a relation instance R is decomposed into fragments R1, R2, . . . .Rn, each data item in R must appear in at least one
of the fragments. It is necessary in fragmentation to ensure that there is no loss of data during data fragmentation.

Reconstruction
If relation R is decomposed into fragments R1, R2, . . . .Rn, it must be possible to define a relational operation that
will reconstruct the relation R from fragments R1, R2, . . . .Rn. This rule ensures that constrains defined on the data
are preserved during data fragmentation.
To ensure no loss of information and no redundancy of data, there are three different rules that must be considered
during fragmentation.
Disjointness
If a relation R is decomposed into fragments R1, R2, . . . .Rn and if a data item is found in the fragment Ri, then it must
not appear in any other fragments. This rule ensures minimal data redundancy.
In case of vertical fragmentation, primary key attribute must be repeated to allow reconstruction. Therefore, in case
of vertical fragmentation, disjointness is defined only on non-primary key attributes of a relation.
Example (Horizontal Fragmentation)
P1: σ
project-type = “inside”
(Project)
P2: σ
project-type = “abroad
 Example (Horizontal Fragmentation)
These horizontal fragments satisfy all the correctness rules of fragmentation as shown below.
Completeness: Each tuple in the relation Project appears either in fragment P1 or P2. Thus, it satisfies completeness
rule for fragmentation.
Reconstruction: The Project relation can be reconstructed from the horizontal fragments P1 and P2 by using the
union operation of relational algebra, which ensures the reconstruction rule.
Thus, P1 P2 = Project.
Disjointness: The fragments P1 and P2 are disjoint, since there can be no such project whose project type is both
“inside” and “abroad”.
Example (Vertical Fragmentation)

 Example (Vertical Fragmentation)
These vertical fragments also ensure the correctness rules of fragmentation as shown below.
Completeness: Each tuple in the relation Project appears either in fragment V1 or V2 which satisfies completeness
rule for fragmentation.
Reconstruction: The Project relation can be reconstructed from the vertical fragments V1 and V2 by using the
natural join operation of relational algebra, which ensures the reconstruction rule.
Thus, V1 ⋈ V2 = Project.
Disjointness: The fragments V1 and V2 are disjoint, except for the primary key project-id, which is repeated in both
fragments and is necessary for reconstruction.
 Distributed Database System Design Issues
 Distributed Database Design
 Distributed Directory Management
 Distributed Query Processing
 Distributed Concurrency Control
 Distributed Deadlock Management
 Reliability of Distributed DBMS
 Replication
 Relationship among Problems

 Components of a Distributed DBMS
Major two components:
 User Processor: Handles the interaction with users and
 Data Processor: Deals with the storage.
 Multidatabase System (MDBS) Architecture
Multidatabase systems (MDBS) represent the case where individual DBMSs (whether distributed or not) are fully
autonomous and have no concept of cooperation;
They may not even “know” of each other’s existence or how to talk to each other.
MDBS Architecture
Fig.: MDBS Architecture with a GCS
LIS
1
LIS
n. . . .
LCS
1
LCS
n
. . . .
LES
11
LES
12
LES
13
LES
n1
LES
n2
LES
n3
GES
1
GES
2
GES
3
GCS

MDBS Architecture
1. Users of a local DBMS define their own views on the local database and do not need to change their
applications if they do not want to access data from another database. This is again an issue of
autonomy.
2. Designing the global conceptual schema in multidatabase systems involves the integration of either
the local conceptual schemas or the local external schemas.
3. Once the GCS has been designed, views over the global schema can be defined for users who require
global access. It is not necessary for the GES and GCS to be defined using the same data model and
language; whether they do or not determines whether the system is homogeneous or heterogeneous.
 Functional Aspects Provided by Parallel Database Systems
Ideally, a parallel database system should have the following functional aspects.
High-performance: This can be obtained through several complementary solutions: database-oriented operating
system support, parallelism, optimization, and load balancing.
High-availability: Because a parallel database system consists of many similar components, it can exploit data
replication to increase database availability.
Extensibility: It is the ability of smooth expansion of the system by adding processing and storage power to the
system. Ideally, the parallel database system should provide two extensibility advantages:
 Linear Speedup and
 Linear Scaleup.
Linear Speedup refers to a linear increase in performance for a constant database size and linear increase in
processing and storage power.
Linear Scaleup refers to a sustained performance for a linear increase in both database size and processing and
storage power.
 Parallel Architectures
There are three basic parallel computer architectures depending on how main memory or disk is shared:
I. Shared-memory,
II. Shared-disk and
III. Shared-nothing.
Shared-Memory
In the shared-memory approach any processor has access to any memory module or disk unit through a fast
interconnect (e.g. a high-speed bus). All the processors are under the control of a single operating system.
Shared-Memory

Advantages: simplicity and load balancing
Problems: high cost, limited extensibility and low availability.
Example: XPRS, DBS3, and Volcano.
Components of Parallel DBM Architecture
It has three major components or subsystems.
Session Manager: It performs the connections and disconnections between the client processes and the two other
subsystems.
Transaction Manager: It receives client transactions related to query compilation and execution. It can access the
database directory that holds all meta-information about data and programs. Depending on the transaction, it
activates the various compilation phases, triggers query execution, and returns the results as well as error codes to
the client application.
Components of Parallel DBM Architecture
Data Manager: It provides all the low-level functions needed to run compiled queries in parallel.
Data Partitioning Techniques
There are three basic strategies for data partitioning:
• Round-robin,
• Hash and
• Range partitioning.

 Data Partitioning Techniques
Round-robin partitioning is the simplest strategy. It ensures uniform data distribution. With n partitions, the ith
tuple in insertion order is assigned to partition (i mod n).
Hash partitioning applies a hash function to some attribute that yields the partition number. This strategy allows
exact-match queries on the selection attribute to be processed by exactly one node and all other queries to be
processed by all the nodes in parallel.
Range partitioning distributes tuples based on the value intervals of some attribute. It is well-suited for range
queries. However, range partitioning can result in high variation in partition size.
Indexing and Hashing

 Hash File Organization
 In a hash file organization, we obtain the address of the disk block, also called the bucket containing
a desired record directly by computing a function on the search-key value of the record.
 Let K denote the set of all search-key values, and let B denote the set of all bucket addresses. A hash
function h is a function from K to B. Let h denote a hash function.
 To insert a record with search key Ki, we compute h(Ki), which gives the address of the bucket for
that record. Assume for now that there is space in the bucket to store the record. Then, the record
is stored in that bucket.
Hash File Organization: An Example
 Let us choose a hash function for the account file using the search key branch_name.
 Suppose we have 26 buckets and we define a hash function that maps names beginning with the
ith letter of the alphabet to the ith bucket.
 This hash function has the virtue of simplicity, but it fails to provide a uniform distribution, since we
expect more branch names to begin with such letters as B and R than Q and X.
 Hash Indices
 Hashing can be used not only for file organization, but also for index-structure creation. We
construct a hash index as follows. We apply a hash function on a search key to identify a bucket,
and store the key and its associated pointers in the bucket.Hash Indices

DDBMS
 Transparency
– It refers to the separation of the high-level semantics of a system from lower-level implementation
issues. In a distributed system, it hides the implementation details from users of the system.
– The user believes that he/she is working with a centralized database system and that all the
complexities of a distributed database system are either hidden or transparent to the user.
– Four main categories of transparencies:
• Distribution transparency
• Transaction transparency
• Performance transparency
• DBMS transparency
 A Model for Transaction Management in DDBMS
– Access to the various data items in a distributed system is usually accomplished through
transactions which must preserve the ACID properties. There are two types of transaction that we
need to consider.
• The local transactions are those that access and update data in only local database.
• The global transactions are those that access and update data in several local databases.
Ensuring the ACID properties of local transactions can be done easily. However, for global transactions, this task is
much more complicated, since several sites are participating in execution. A model for transaction management at
each site of a distributed system is shown below.
Fig. A Model for Transaction Management at each site in a DDBMS
– It consists of two sub-modules:
• Transaction Manager (TM) and
• Transaction Coordinator (TC)

 Concurrency Control Anomalies
Different anomalies can arise due to concurrent access of data:
– Lost update anomaly – This occurs when a successful completed update operation made by one
transaction is overridden by another transaction.
– Uncommitted dependency – This problem occurs when one transaction allows other transactions
to read its data before it has committed and then decides to abort.
– Inconsistent analysis anomaly – The problem occurs when a transaction reads several values from
the database but a second transaction updates some of them during the execution of the first.
– Phantom read anomaly – This anomaly occurs when a transaction performs some operation on the
database based on a selection predicate, another transaction inserts new tuples satisfying that
predicate into the same database. This is known as phantom read.
– Multiple-copy consistency problem – This occurs when data items are replicated and stored at
different sites. To maintain the consistency, when a replicated data item is updated at one site, all
other copies must be updated. Otherwise, the database becomes inconsistent.
 Two-Phase Locking (2PL) Protocol
The 2PL protocol states that no transaction should acquire a lock after it releases one of its lock.
According to this protocol, the life time of each transaction is divided into two phases:
 Growing phase and
 Shrinking phase.
In growing phase, a transaction can obtain locks on data items and can access data items, but it can not release any
locks.
In shrinking phase, a transaction can release locks but cannot acquire any new locks after that. Thus, the ending of
growing phase of a transaction determines the beginning of the shrinking phase of that transaction. It is not
necessary for each transaction to acquire all locks simultaneously and then start processing. Normally, each
transaction obtains some locks initially, does some processing and then requests for new additional locks that are
required. However, it never releases any lock until it has reached a stage where no more locks are required. If up-
gradation and down-gradation are allowed, then up-gradation of locks can take place in the growing phase, whereas
down-gradation of locks can occur in the shrinking phase.
 Distributed Deadlock Prevention Method
Wait-die is a non-preemptive deadlock prevention technique based on timestamp values of transactions:
In this technique, when one transaction is about to block and is waiting for a lock on a data item that is
already locked by another transaction, timestamp values of both the transactions are checked to give priority to the
older transaction. If a younger transaction is holding the lock on data item then the older transaction is allowed to
wait, but if an older transaction is holding the lock, the younger transaction is aborted and restarted with the same
timestamp value. This forces the wait-for graph to be directed from the older to the younger transactions, making
cyclic restarts impossible. For example, if the transaction Ti requests a lock on a data item that is already locked by
the transaction Tj, then Ti is permitted to wait only if Ti has a lower timestamp value than Tj. On the other hand, if Ti
is younger than Tj, then Ti is aborted and restarted with the same timestamp value.
Wound-Wait is an alternative preemptive deadlock prevention technique by which cyclic restarts can be avoided.

In this method, if a younger transaction requests for a lock on a data item that is already held by an older
transaction, the younger transaction is allowed to wait until the older transaction releases the corresponding lock.
In this case, the wait-for graph flows from the younger to the older transactions, and cyclic restart is again avoided.
For instance, if the transaction Ti requests a lock on a data item that is already locked by the transaction Tj, then Ti
is permitted to wait only if Ti has a higher timestamp value than Tj, otherwise, the transaction Tj is aborted and the
lock is granted to the transaction Ti.
 Centralized Deadlock detection
In Centralized Deadlock detection method, a single site is chosen as Deadlock Detection Coordinator (DDC)
for the entire distributed system. The DDC is responsible for constructing the GWFG for system. Each lock manager
in the distributed database transmits its LWFG to the DDC periodically. The DDC constructs the GWFG from these
LWFGs and checks for cycles in it. The occurrence of a global deadlock situation is detected if there are one or more
cycles in the GWFG. The DDC must break each cycle in the GWFG by selecting the transactions to be rolled back and
restarted to recover from a deadlock situation. The information regarding the transactions that are to be rolled back
and restarted must be transmitted to the corresponding lock managers by the deadlock detection coordinator.
Centralized Deadlock detection
– The centralized deadlock detection approach is very simple, but it has several drawbacks.
– This method is less reliable, as the failure of the central site makes the deadlock detection
impossible.
– The communication cost is very high in the case, as other sites in the distributed system send their
LWFGs to the central site.
– Another disadvantage of centralized deadlock detection technique is that false detection of
deadlocks can occur, for which the deadlock recovery procedure may be initiated, although no
deadlock has occurred. In this method, unnecessary rollbacks and restarts of transactions may also
result owing to phantom deadlocks.