Questions

[Link]
[Link]
Unit -1
1. What is data fragmentation? Explain allocation techniques for DDBMS
2. Explain methods used for designing and implementing DDBMS
3. What is mixed fragmentation? Explain with an example
4. Explain different types of fragmentation indicating their advantages and
disadvantages?
5. Describe the reference architecture of Distributed Database Management System
with proper diagram?
6. Describe federated DDBMS architecture
7. Describe parallel databases architecture
8. Describe client server architecture

Unit - 2
1. Explain localization of distributed data in semantics data control
2. Explain Query processing and different layers of query processing. Objectives of query
processing.
3. Write about Distributed design issues?
4. Explain Characterization of query processors
5. Discuss Semantic Integrity Control QUERY PROCESSING ISSUES
6. Explain about Localization of distributed data
Unit - 3
1. Explain concurrency control in centralized database systems
2. How deadlock management is done in distributed systems
3. How deadlock management is made possible
4. How does a distributed transaction differ from a centralized transaction?
5. Explain the distributed deadlock detection algorithm in detail.
6. What are the challenges in designing distributed concurrency control algorithms?
7. Define query optimization in centralized and distributed systems
8. How ordering of fragment queries done?
9. List and explain Distributed query optimization algorithms
10. Define transaction management. Goals and characteristics of transaction
management. Define transaction models
11. Explain concurrency control in distributed database systems
12. List and explain distributed concurrency control algorithms
Unit - 4
 1. Differentiate between spatial database and web database
2. Explain different reliability techniques
3. What are the challenges in designing reliable distributed database systems?
4. What is Byzantine fault tolerance, and how is it used to improve reliability in
distributed database systems?
5. What is the meaning of consistency in distributed database systems, and how is it
related to reliability?
6. What is reliability in the context of distributed database systems, and why is it
important?
7. Explain reliability issues in DDBMS
8. Explain types of failures
9. Explain commit protocols and recovery protocols
Unit - 5
1. How spatial database and web databases are used in parallel database systems
2. How is distributed object management done in parallel database systems
3. What is a parallel database system, and how does it differ from a traditional database
system?
4. What is load balancing, and how is it used in parallel database systems?
5. What are the different techniques used for fault tolerance in parallel database
systems?
6. What is query parallelism, and how is it used in parallel database systems?
7. Explain Parallel architectures
8. Explain parallel query processing and optimization
9. Explain load balancing in parallel database system
10. Define Mobile databases and Multi-databases

One mark Question

1. What is data fragmentation
2. Define Replication?
3. What do you mean by data allocation?
4. Define Data security
5. Abbreviate ACID properties?
6. Define Deadlock?
7. Write the use of Commit protocols
8. Write the use of Recovery protocols
9. Define Distributed Object Management?
[Link] Mobile Databases?
[Link] out different layers of query processing
[Link] distributed systems
 [Link] out methods used for designing and implementing DDBMS
[Link] out concurrency control in centralized database systems
[Link] deadlock management
[Link] concurrency control
[Link] designing in DDBMS
[Link] centralized database systems
[Link] is a Federated Database Management System?
[Link] semantics data control
[Link] about centralized database systems
[Link] DDBS
[Link] Spatial Database
[Link] Web Database
[Link] is distributed object
[Link] parallel database systems
[Link] reliability techniques used in DDBS
[Link] 2 differences between spatial database and web database
[Link] 2 differences between centralized database systems and DDBS

***************************************
What is data fragmentation? Explain allocation techniques for DDBMS
Fragmentation in Distributed DBMS
Fragmentation is a process of dividing the whole or full database into various subtables or
sub relations so that data can be stored in different systems. The small pieces or sub
relations or subtables are called fragments. These fragments are called logical data units
and are stored at various sites. It must be made sure that the fragments are such that
they can be used to reconstruct the original relation (i.e, there isn’t any loss of data).
In the fragmentation process, let’s say, If a table T is fragmented and is divided into a
number of fragments say T1, T2, T3….TN. The fragments contain sufficient information to
allow the restoration of the original table T. This restoration can be done by the use of
UNION or JOIN operation on various fragments. This process is called data fragmentation.
All of these fragments are independent which means these fragments cannot be derived
from others. The users needn’t be logically concerned about fragmentation which means
they should not concerned that the data is fragmented and this is called fragmentation
Independence or we can say fragmentation transparency.
Advantages :
 As the data is stored close to the usage site, the efficiency of the database
system will increase
 Local query optimization methods are sufficient for some queries as the data is
available locally
 In order to maintain the security and privacy of the database system,
fragmentation is advantageous
Disadvantages :
 Access speeds may be very high if data from different fragments are needed
 If we are using recursive fragmentation, then it will be very expensive
We have three methods for data fragmenting of a table:
 Horizontal fragmentation
 Vertical fragmentation
 Mixed or Hybrid fragmentation
Let’s discuss them one by one.
Horizontal fragmentation –
Horizontal fragmentation refers to the process of dividing a table horizontally by assigning
each row (or a group of rows) of relation to one or more fragments. These fragments can
then be assigned to different sites in the distributed system. Some of the rows or tuples of
the table are placed in one system and the rest are placed in other systems. The rows that
belong to the horizontal fragments are specified by a condition on one or more attributes
of the relation. In relational algebra horizontal fragmentation on table T, can be
represented as follows:
σp(T)
where, σ is relational algebra operator for selection
p is the condition satisfied by a horizontal fragment
Note that a union operation can be performed on the fragments to construct table T. Such
a fragment containing all the rows of table T is called a complete horizontal fragment.
For example, consider an EMPLOYEE table (T) :
Eno Ename Desig Salar Dep
n y
101 A abc 3000 1
102 B abc 4000 1
103 C abc 5500 2
104 D abc 5000 2
105 E abc 2000 2
This EMPLOYEE table can be divided into different fragments like:
EMP 1 = σDep = 1 EMPLOYEE
EMP 2 = σDep = 2 EMPLOYEE
These two fragments are: T1 fragment of Dep = 1
Eno Enam Design Salary Dep
e
101 A abc 3000 1
102 B abc 4000 1
Similarly, the T2 fragment on the basis of Dep = 2 will be :
 Eno Enam Design Salary Dep
e
103 C abc 5500 2
104 D abc 5000 2

Now, here it is possible to get back T as T = T1 ∪ T2 ∪ …. ∪ TN

105 E abc 2000 2

Vertical Fragmentation
Vertical fragmentation refers to the process of decomposing a table vertically by
attributes or columns. In this fragmentation, some of the attributes are stored in one
system and the rest are stored in other systems. This is because each site may not need
all columns of a table. In order to take care of restoration, each fragment must contain
the primary key field(s) in a table. The fragmentation should be in such a manner that we
can rebuild a table from the fragment by taking the natural JOIN operation and to make it
possible we need to include a special attribute called Tuple-id to the schema. For this
purpose, a user can use any super key. And by this, the tuples or rows can be linked
together. The projection is as follows:
πa1, a2,…, an (T)
where, π is relational algebra operator
a1…., an are the attributes of T
T is the table (relation)
For example, for the EMPLOYEE table we have T1 as :
Eno Ename Desig Tuple_i
n d
101 A abc 1
102 B abc 2
103 C abc 3
104 D abc 4
105 E abc 5
For the second. sub table of relation after vertical fragmentation is given as follows :
Salar Dep Tuple_i
y d
3000 1 1
4000 2 2
5500 3 3
5000 1 4
2000 4 5

as πEMPLOYEE (T1 ⋈ T2)

This is T2 and to get back to the original T, we join these two fragments T1 and T2

Mixed Fragmentation
The combination of vertical fragmentation of a table followed by further horizontal
fragmentation of some fragments is called mixed or hybrid fragmentation. For defining
this type of fragmentation we use the SELECT and the PROJECT operations of relational
algebra. In some situations, the horizontal and the vertical fragmentation isn’t enough to
distribute data for some applications and in that conditions, we need a fragmentation
called a mixed fragmentation.
Mixed fragmentation can be done in two different ways:
1. The first method is to first create a set or group of horizontal fragments and then
create vertical fragments from one or more of the horizontal fragments.
2. The second method is to first create a set or group of vertical fragments and then
create horizontal fragments from one or more of the vertical fragments.
The original relation can be obtained by the combination of JOIN and UNION
operations which is given as follows:
σP(πa1, a2..,an(T))
πa1,a2….,an (σp(T))
For example, for our EMPLOYEE table, below is the implementation of mixed
fragmentation is πEname, Design (σEno < 104(EMPLOYEE))
The result of this fragmentation is:
Enam Design
e
A abc
B abc
C abc

Data Allocation Techniques

It is the process to decide where exactly you want to store the data in the database. Also
involves the decision as to which data type of data has to be stored at what particular
location. Three main types of data allocation are centralized, partitioned, and replicated.

Centralises: Entire database is stored at a single site. No data distribution occurs

Partitioned: The database gets divided into different fragments which are stored at several
sites.
Replicated: Copies of the database are stored at different locations to access the data.

Explain methods used for designing and implementing DDBMS

A distributed database is basically a database that is not limited to one system, it is spread
over different sites, i.e, on multiple computers or over a network of computers. A
distributed database system is located on various sites that don’t share physical
components. This may be required when a particular database needs to be accessed by
various users globally. It needs to be managed such that for the users it looks like one
single database.
Types:
1. Homogeneous Database:
In a homogeneous database, all different sites store database identically. The operating
system, database management system, and the data structures used – all are the same at
all sites. Hence, they’re easy to manage.
2. Heterogeneous Database:
In a heterogeneous distributed database, different sites can use different schema and
software that can lead to problems in query processing and transactions. Also, a particular
site might be completely unaware of the other sites. Different computers may use a
different operating system, different database application. They may even use different
data models for the database. Hence, translations are required for different sites to
communicate.

Distributed Data Storage :

There are 2 ways in which data can be stored on different sites. These are:
1. Replication –
In this approach, the entire relationship is stored redundantly at 2 or more sites. If the
entire database is available at all sites, it is a fully redundant database. Hence, in
replication, systems maintain copies of data.
This is advantageous as it increases the availability of data at different sites. Also, now
query requests can be processed in parallel.
However, it has certain disadvantages as well. Data needs to be constantly updated. Any
change made at one site needs to be recorded at every site that relation is stored or else
it may lead to inconsistency. This is a lot of overhead. Also, concurrency control becomes
way more complex as concurrent access now needs to be checked over a number of sites.
2. Fragmentation –
In this approach, the relations are fragmented (i.e., they’re divided into smaller parts) and
each of the fragments is stored in different sites where they’re required. It must be made
sure that the fragments are such that they can be used to reconstruct the original relation
(i.e, there isn’t any loss of data).
Fragmentation is advantageous as it doesn’t create copies of data, consistency is not a
problem.

Fragmentation of relations can be done in two ways:

 Horizontal fragmentation – Splitting by rows –
The relation is fragmented into groups of tuples so that each tuple is assigned to
at least one fragment.
 Vertical fragmentation – Splitting by columns –
The schema of the relation is divided into smaller schemas. Each fragment must
contain a common candidate key so as to ensure a lossless join.
In certain cases, an approach that is hybrid of fragmentation and replication is used.
Applications of Distributed Database:
 It is used in Corporate Management Information System.
 It is used in multimedia applications.
 Used in Military’s control system, Hotel chains etc.
 It is also used in manufacturing control system.
 A distributed database system is a type of database management system that stores data
across multiple computers or sites that are connected by a network. In a distributed
database system, each site has its own database, and the databases are connected to
each other to form a single, integrated system.
The main advantage of a distributed database system is that it can provide higher
availability and reliability than a centralized database system. Because the data is stored
across multiple sites, the system can continue to function even if one or more sites fail. In
addition, a distributed database system can provide better performance by distributing
the data and processing load across multiple sites.
There are several different architectures for distributed database systems, including:
Client-server architecture: In this architecture, clients connect to a central server, which
manages the distributed database system. The server is responsible for coordinating
transactions, managing data storage, and providing access control.
Peer-to-peer architecture: In this architecture, each site in the distributed database
system is connected to all other sites. Each site is responsible for managing its own data
and coordinating transactions with other sites.
Federated architecture: In this architecture, each site in the distributed database system
maintains its own independent database, but the databases are integrated through a
middleware layer that provides a common interface for accessing and querying the data.
Distributed database systems can be used in a variety of applications, including e-
commerce, financial services, and telecommunications. However, designing and managing
a distributed database system can be complex and requires careful consideration of
factors such as data distribution, replication, and consistency.
Advantages of Distributed Database System :
1) There is fast data processing as several sites participate in request processing.
2) Reliability and availability of this system is high.
3) It possess reduced operating cost.
4) It is easier to expand the system by adding more sites.
5) It has improved sharing ability and local autonomy.
Disadvantages of Distributed Database System :
1) The system becomes complex to manage and control.
2) The security issues must be carefully managed.
3) The system require deadlock handling during the transaction processing otherwise the
entire system may be in inconsistent state.
4) There is need of some standardization for processing of distributed database system.
Distributed DBMS - Design Strategies

In the last chapter, we had introduced different design alternatives. In this chapter, we will
study the strategies that aid in adopting the designs. The strategies can be broadly divided
into replication and fragmentation. However, in most cases, a combination of the two is
used.

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
low.
 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.
Explain localization of distributed data in semantics data control
Explain different layers of query processing
Separate pdf is there

Layers of Query Processing

 Query Decomposition
 Data Localization
 Global Query Optimization
 Local Query Optimization
Write about Distributed design issues?
Distributed System is a collection of autonomous computer systems that are physically
separated but are connected by a centralized computer network that is equipped with
distributed system software. These are used in numerous applications, such as online
gaming, web applications, and cloud computing. However, creating a distributed system is
not simple, and there are a number of design considerations to take into account. The
following are some of the major design issues of distributed systems:
Design issues of the distributed system –
1. Heterogeneity: Heterogeneity is applied to the network, computer hardware,
operating system, and implementation of different developers. A key component
of the heterogeneous distributed system client-server environment is
middleware. Middleware is a set of services that enables applications and end-
user to interact with each other across a heterogeneous distributed system.
2. Openness: The openness of the distributed system is determined primarily by
the degree to which new resource-sharing services can be made available to the
users. Open systems are characterized by the fact that their key interfaces are
published. It is based on a uniform communication mechanism and published
interface for access to shared resources. It can be constructed from
heterogeneous hardware and software.
3. Scalability: The scalability of the system should remain efficient even with a
significant increase in the number of users and resources connected. It shouldn’t
matter if a program has 10 or 100 nodes; performance shouldn’t vary. A
distributed system’s scaling requires consideration of a number of elements,
including size, geography, and management.
4. Security: The security of an information system has three components
Confidentially, integrity, and availability. Encryption protects shared resources
and keeps sensitive information secrets when transmitted.
5. Failure Handling: When some faults occur in hardware and the software
program, it may produce incorrect results or they may stop before they have
completed the intended computation so corrective measures should to
implemented to handle this case. Failure handling is difficult in distributed
systems because the failure is partial i, e, some components fail while others
continue to function.
6. Concurrency: There is a possibility that several clients will attempt to access a
shared resource at the same time. Multiple users make requests on the same
resources, i.e. read, write, and update. Each resource must be safe in a
concurrent environment. Any object that represents a shared resource in a
distributed system must ensure that it operates correctly in a concurrent
environment.
7. Transparency: Transparency ensures that the distributed system should be
perceived as a single entity by the users or the application programmers rather
than a collection of autonomous systems, which is cooperating. The user should
be unaware of where the services are located and the transfer from a local
machine to a remote one should be transparent.
Explain Characterization of query processors
Discuss Semantic Integrity Control QUERY PROCESSING
ISSUES
Semantic Integrity Control

Semantic integrity control defines and enforces the integrity constraints of

the database system.

The integrity constraints are as follows −

 Data type integrity constraint

 Entity integrity constraint
 Referential integrity constraint
Data Type Integrity Constraint

A data type constraint restricts the range of values and the type of
operations that can be applied to the field with the specified data type.

For example, let us consider that a table "HOSTEL" has three fields - the
hostel number, hostel name and capacity. The hostel number should start
with capital letter "H" and cannot be NULL, and the capacity should not be
more than 150. The following SQL command can be used for data definition
−

CREATE TABLE HOSTEL (

H_NO VARCHAR2(5) NOT NULL,
H_NAME VARCHAR2(15),
CAPACITY INTEGER,
CHECK ( H_NO LIKE 'H%'),
CHECK ( CAPACITY <= 150)
);
Entity Integrity Control

Entity integrity control enforces the rules so that each tuple can be uniquely
identified from other tuples. For this a primary key is defined. A primary key
is a set of minimal fields that can uniquely identify a tuple. Entity integrity
constraint states that no two tuples in a table can have identical values for
primary keys and that no field which is a part of the primary key can have
NULL value.

For example, in the above hostel table, the hostel number can be assigned
as the primary key through the following SQL statement (ignoring the
checks) −

CREATE TABLE HOSTEL (

H_NO VARCHAR2(5) PRIMARY KEY,
H_NAME VARCHAR2(15),
CAPACITY INTEGER
);
Referential Integrity Constraint

Referential integrity constraint lays down the rules of foreign keys. A foreign
key is a field in a data table that is the primary key of a related table. The
referential integrity constraint lays down the rule that the value of the
foreign key field should either be among the values of the primary key of the
referenced table or be entirely NULL.

For example, let us consider a student table where a student may opt to live
in a hostel. To include this, the primary key of hostel table should be
included as a foreign key in the student table. The following SQL statement
incorporates this −

CREATE TABLE STUDENT (

S_ROLL INTEGER PRIMARY KEY,
S_NAME VARCHAR2(25) NOT NULL,
S_COURSE VARCHAR2(10),
S_HOSTEL VARCHAR2(5) REFERENCES HOSTEL
);

Explain about Localization of distributed data

Localization of Distributed Data
The general techniques for decomposing and restructuring queries are expressed in
relational calculus. The general techniques apply to both centralized and distributed DBMSs
and do no take into account the distribution of data. This is the role of the localization layer,
which translates an algebraic query on global relations into an algebraic query expressed on
physical fragments. Localization uses information stored in the fragment schema.
1Fragmentation is defined through fragmentation rules, which can be expressed as
relational queries. A naive way to localize a distributed query is to generate a query where
each global relation is substituted by its localization program.
 Reduction for Primary Horizontal Fragmentation
The horizontal fragmentation function distributes a relation based on selection
predicates. The reduction of queries on horizontally fragmented relations consist
primarily of determining, after restructuring the subtrees, those that will produce
empty relations, and removing them. Horizontal fragmentation can be exploited to
simplify both selection and join operations.
 Reduction for Vertical Fragmentation
The vertical fragmentation function distributes a relation based on projection
attributes. Since the reconstruction operator for vertical fragmentation is the join, the
localization program for a vertically fragmented relation consist of the join of the
 fragments on the common attribute. Similar to horizontal fragmentation, queries on
vertical fragments can be reduced by determining the useless intermediate relations
and removing the subtrees that produce them.

 Reduction for Derived Fragmentation

The join operation is probably the most important operation because it is both
frequent and expensive, can be optimized by using primary horizontal fragmentation
when the joined relations a re fragmented according to the joins attributes. In this
case the join of two relations is implemented as a union of partial joins. However, this
method precludes one of the relations from being fragmented on a different attribute
used for selection. Derived horizontal fragmentation is another way of distributing
two relations so that the joint processing of select and join is improved.

 Reduction for Hybrid Fragmentation

Hybrid fragmentation is obtained by combining the fragmentation functions
discussed above. The goal of hybrid fragmentation is to support, efficiently queries
involving projection, selection, and join. Note that the optimization of an operation or
of a combination of operations is always done at the expense of other operations.

Explain concurrency control in centralized database systems

Concurrency Control in DBMS
Concurrently control is a very important concept of DBMS which ensures the
simultaneous execution or manipulation of data by several processes or user without
resulting in data inconsistency. Concurrency Control deals with interleaved execution of
more than one transaction.
A set of logically related operations is known as a transaction. The main operations of a
transaction are:
 Read(A): Read operations Read(A) or R(A) reads the value of A from the database
and stores it in a buffer in the main memory.
 Write (A): Write operation Write(A) or W(A) writes the value back to the
database from the buffer.
(Note: It doesn’t always need to write it to a database back it just writes the changes to
buffer this is the reason where dirty read comes into the picture)
Let us take a debit transaction from an account that consists of the following operations:
1. R(A);
2. A=A-1000;
3. W(A);
Assume A’s value before starting the transaction is 5000.
 The first operation reads the value of A from the database and stores it in a
buffer.
  the Second operation will decrease its value by 1000. So buffer will contain 4000.
 the Third operation will write the value from the buffer to the database. So A’s
final value will be 4000.
But it may also be possible that the transaction may fail after executing some of its
operations. The failure can be because of hardware, software or power, etc. For
example, if the debit transaction discussed above fails after executing operation 2, the
value of A will remain 5000 in the database which is not acceptable by the bank. To avoid
this, Database has two important operations:
 Commit: After all instructions of a transaction are successfully executed, the
changes made by a transaction are made permanent in the database.
 Rollback: If a transaction is not able to execute all operations successfully, all the
changes made by a transaction are undone.
For more details please refer Transaction Control in DBMS article.
Properties of a Transaction
Atomicity: As a transaction is a set of logically related operations, either all of them
should be executed or none. A debit transaction discussed above should either execute
all three operations or none. If the debit transaction fails after executing operations 1 and
2 then its new value of 4000 will not be updated in the database which leads to
inconsistency.
Consistency: If operations of debit and credit transactions on the same account are
executed concurrently, it may leave the database in an inconsistent state.
 For Example, with T1 (debit of Rs. 1000 from A) and T2 (credit of 500 to A)
executing concurrently, the database reaches an inconsistent state.
 Let us assume the Account balance of A is Rs. 5000. T1 reads A(5000) and stores
the value in its local buffer space. Then T2 reads A(5000) and also stores the
value in its local buffer space.
 T1 performs A=A-1000 (5000-1000=4000) and 4000 is stored in T1 buffer space.
Then T2 performs A=A+500 (5000+500=5500) and 5500 is stored in the T2 buffer
space. T1 writes the value from its buffer back to the database.
 A’s value is updated to 4000 in the database and then T2 writes the value from
its buffer back to the database. A’s value is updated to 5500 which shows that
the effect of the debit transaction is lost and the database has become
inconsistent.
 To maintain consistency of the database, we need concurrency control
protocols which will be discussed in the next article. The operations of T1 and T2
with their buffers and database have been shown in Table 1.
T1 T1’s buffer space T2 T2’s Buffer Database
Space
A=5000
R(A); A=5000 A=5000
A=5000 R(A); A=5000 A=5000
A=A- A=4000 A=5000 A=5000
1000;
A=4000 A=A+500; A=5500
 W(A); A=5500 A=4000
W(A); A=5500
Isolation: The result of a transaction should not be visible to others before the transaction
is committed. For example, let us assume that A’s balance is Rs. 5000 and T1 debits Rs.
1000 from A. A’s new balance will be 4000. If T2 credits Rs. 500 to A’s new balance, A will
become 4500, and after this T1 fails. Then we have to roll back T2 as well because it is
using the value produced by T1. So transaction results are not made visible to other
transactions before it commits.
Durable: Once the database has committed a transaction, the changes made by the
transaction should be permanent. e.g.; If a person has credited $500000 to his account,
the bank can’t say that the update has been lost. To avoid this problem, multiple copies of
the database are stored at different locations.
What is a Schedule?
A schedule is a series of operations from one or more transactions. A schedule can be of
two types:
Serial Schedule: When one transaction completely executes before starting another
transaction, the schedule is called a serial schedule. A serial schedule is always consistent.
e.g.; If a schedule S has debit transaction T1 and credit transaction T2, possible serial
schedules are T1 followed by T2 (T1->T2) or T2 followed by T1 ((T2->T1). A serial schedule
has low throughput and less resource utilization.
Concurrent Schedule: When operations of a transaction are interleaved with operations
of other transactions of a schedule, the schedule is called a Concurrent schedule. e.g.; the
Schedule of debit and credit transactions shown in Table 1 is concurrent. But concurrency
can lead to inconsistency in the database. The above example of a concurrent schedule is
also inconsistent.
Difference between Serial Schedule and Serializable Schedule
Serial Schedule Serializable Schedule
In Serial schedule, transactions will be In Serializable schedule transaction are
executed one after other. executed concurrently.
Serial schedule are less efficient. Serializable schedule are more efficient.
In serial schedule only one transaction In Serializable schedule multiple transactions
executed at a time. can be executed at a time.
Serial schedule takes more time for In Serializable schedule execution is fast.
execution.
Concurrency Control in DBMS
 Executing a single transaction at a time will increase the waiting time of the
other transactions which may result in delay in the overall execution. Hence for
increasing the overall throughput and efficiency of the system, several
transactions are executed.
 Concurrently control is a very important concept of DBMS which ensures the
simultaneous execution or manipulation of data by several processes or user
without resulting in data inconsistency.
  Concurrency control provides a procedure that is able to control concurrent
execution of the operations in the database.

Concurrency Control Problems

There are several problems that arise when numerous transactions are executed
simultaneously in a random manner. The database transaction consist of two major
operations “Read” and “Write”. It is very important to manage these operations in the
concurrent execution of the transactions in order to maintain the consistency of the data.
Dirty Read Problem(Write-Read conflict)
Dirty read problem occurs when one transaction updates an item but due to some
unconditional events that transaction fails but before the transaction performs rollback,
some other transaction reads the updated value. Thus creates an inconsistency in the
database. Dirty read problem comes under the scenario of Write-Read conflict between
the transactions in the database
1. The lost update problem can be illustrated with the below scenario between two
transactions T1 and T2.
2. Transaction T1 modifies a database record without committing the changes.
3. T2 reads the uncommitted data changed by T1
4. T1 performs rollback
5. T2 has already read the uncommitted data of T1 which is no longer valid, thus
creating inconsistency in the database.
Lost Update Problem
Lost update problem occurs when two or more transactions modify the same data,
resulting in the update being overwritten or lost by another transaction. The lost update
problem can be illustrated with the below scenario between two transactions T1 and T2.
1. T1 reads the value of an item from the database.
2. T2 starts and reads the same database item.
3. T1 updates the value of that data and performs a commit.
4. T2 updates the same data item based on its initial read and performs commit.
5. This results in the modification of T1 gets lost by the T2’s write which causes a
lost update problem in the database.
Concurrency Control Protocols
Concurrency control protocols are the set of rules which are maintained in order to solve
the concurrency control problems in the database. It ensures that the concurrent
transactions can execute properly while maintaining the database consistency. The
concurrent execution of a transaction is provided with atomicity, consistency, isolation,
durability, and serializability via the concurrency control protocols.
 Locked based concurrency control protocol
 Timestamp based concurrency control protocol
Locked based Protocol
In locked based protocol , each transaction needs to acquire locks before they start
accessing or modifying the data items. There are two types of locks used in databases.
  Shared Lock : Shared lock is also known as read lock which allows multiple
transactions to read the data simultaneously. The transaction which is holding a
shared lock can only read the data item but it can not modify the data item.
 Exclusive Lock : Exclusive lock is also known as the write lock. Exclusive lock
allows a transaction to update a data item. Only one transaction can hold the
exclusive lock on a data item at a time. While a transaction is holding an
exclusive lock on a data item, no other transaction is allowed to acquire a
shared/exclusive lock on the same data item.
There are two kind of lock based protocol mostly used in database:
 Two Phase Locking Protocol : Two phase locking is a widely used technique
which ensures strict ordering of lock acquisition and release. Two phase locking
protocol works in two phases.
 Growing Phase : In this phase, the transaction starts acquiring locks
before performing any modification on the data items. Once a
transaction acquires a lock, that lock can not be released until the
transaction reaches the end of the execution.
 Shrinking Phase : In this phase, the transaction releases all the acquired
locks once it performs all the modifications on the data item. Once the
transaction starts releasing the locks, it can not acquire any locks
further.
 Strict Two Phase Locking Protocol : It is almost similar to the two phase locking
protocol the only difference is that in two phase locking the transaction can
release its locks before it commits, but in case of strict two phase locking the
transactions are only allowed to release the locks only when they performs
commits.
Timestamp based Protocol
 In this protocol each transaction has a timestamp attached to it. Timestamp is
nothing but the time in which a transaction enters into the system.
 The conflicting pairs of operations can be resolved by the timestamp ordering
protocol through the utilization of the timestamp values of the transactions.
Therefore, guaranteeing that the transactions take place in the correct order.
Advantages of Concurrency
In general, concurrency means, that more than one transaction can work on a system. The
advantages of a concurrent system are:
 Waiting Time: It means if a process is in a ready state but still the process does
not get the system to get execute is called waiting time. So, concurrency leads to
less waiting time.
 Response Time: The time wasted in getting the response from the cpu for the
first time, is called response time. So, concurrency leads to less Response Time.
 Resource Utilization: The amount of Resource utilization in a particular system is
called Resource Utilization. Multiple transactions can run parallel in a system. So,
concurrency leads to more Resource Utilization.
  Efficiency: The amount of output produced in comparison to given input is called
efficiency. So, Concurrency leads to more Efficiency.
Disadvantages of Concurrency
 Overhead: Implementing concurrency control requires additional overhead, such
as acquiring and releasing locks on database objects. This overhead can lead to
slower performance and increased resource consumption, particularly in systems
with high levels of concurrency.
 Deadlocks: Deadlocks can occur when two or more transactions are waiting for
each other to release resources, causing a circular dependency that can prevent
any of the transactions from completing. Deadlocks can be difficult to detect and
resolve, and can result in reduced throughput and increased latency.
 Reduced concurrency: Concurrency control can limit the number of users or
applications that can access the database simultaneously. This can lead to
reduced concurrency and slower performance in systems with high levels of
concurrency.
 Complexity: Implementing concurrency control can be complex, particularly in
distributed systems or in systems with complex transactional logic. This
complexity can lead to increased development and maintenance costs.
 Inconsistency: In some cases, concurrency control can lead to inconsistencies in
the database. For example, a transaction that is rolled back may leave the
database in an inconsistent state, or a long-running transaction may cause other
transactions to wait for extended periods, leading to data staleness and reduced
accuracy.

Explain regarding concurrency control in centralized database systems

Concurrency Control in DBMS
 Executing a single transaction at a time will increase the waiting time of the
other transactions which may result in delay in the overall execution. Hence for
increasing the overall throughput and efficiency of the system, several
transactions are executed.
 Concurrently control is a very important concept of DBMS which ensures the
simultaneous execution or manipulation of data by several processes or user
without resulting in data inconsistency.
 Concurrency control provides a procedure that is able to control concurrent
execution of the operations in the database.
 The fundamental goal of database concurrency control is to ensure that
concurrent execution of transactions does not result in a loss of database
consistency. The concept of serializability can be used to achieve this goal, since
all serializable schedules preserve consistency of the database. However, not all
schedules that preserve consistency of the database are serializable.
 In general it is not possible to perform an automatic analysis of low-level
operations by transactions and check their effect on database consistency
constraints. However, there are simpler techniques. One is to use the database
 consistency constraints as the basis for a split of the database into subdatabases
on which concurrency can be managed separately.
 Another is to treat some operations besides read and write as fundamental low-
level operations and to extend concurrency control to deal with them.
Concurrency Control Problems
There are several problems that arise when numerous transactions are executed
simultaneously in a random manner. The database transaction consist of two major
operations “Read” and “Write”. It is very important to manage these operations in the
concurrent execution of the transactions in order to maintain the consistency of the data.
Dirty Read Problem(Write-Read conflict)
Dirty read problem occurs when one transaction updates an item but due to some
unconditional events that transaction fails but before the transaction performs rollback,
some other transaction reads the updated value. Thus creates an inconsistency in the
database. Dirty read problem comes under the scenario of Write-Read conflict between
the transactions in the database
1. The lost update problem can be illustrated with the below scenario between two
transactions T1 and T2.
2. Transaction T1 modifies a database record without committing the changes.
3. T2 reads the uncommitted data changed by T1
4. T1 performs rollback
5. T2 has already read the uncommitted data of T1 which is no longer valid, thus
creating inconsistency in the database.
Lost Update Problem
Lost update problem occurs when two or more transactions modify the same data,
resulting in the update being overwritten or lost by another transaction. The lost update
problem can be illustrated with the below scenario between two transactions T1 and T2.
1. T1 reads the value of an item from the database.
2. T2 starts and reads the same database item.
3. T1 updates the value of that data and performs a commit.
4. T2 updates the same data item based on its initial read and performs commit.
5. This results in the modification of T1 gets lost by the T2’s write which causes a
lost update problem in the database.
Concurrency Control Protocols
Concurrency control protocols are the set of rules which are maintained in order to solve
the concurrency control problems in the database. It ensures that the concurrent
transactions can execute properly while maintaining the database consistency. The
concurrent execution of a transaction is provided with atomicity, consistency, isolation,
durability, and serializability via the concurrency control protocols.
 Locked based concurrency control protocol
 Timestamp based concurrency control protocol
Locked based Protocol
In locked based protocol , each transaction needs to acquire locks before they start
accessing or modifying the data items. There are two types of locks used in databases.
  Shared Lock : Shared lock is also known as read lock which allows multiple
transactions to read the data simultaneously. The transaction which is holding a
shared lock can only read the data item but it can not modify the data item.
 Exclusive Lock : Exclusive lock is also known as the write lock. Exclusive lock
allows a transaction to update a data item. Only one transaction can hold the
exclusive lock on a data item at a time. While a transaction is holding an
exclusive lock on a data item, no other transaction is allowed to acquire a
shared/exclusive lock on the same data item.
There are two kind of lock based protocol mostly used in database:
 Two Phase Locking Protocol : Two phase locking is a widely used technique
which ensures strict ordering of lock acquisition and release. Two phase locking
protocol works in two phases.
 Growing Phase : In this phase, the transaction starts acquiring locks
before performing any modification on the data items. Once a
transaction acquires a lock, that lock can not be released until the
transaction reaches the end of the execution.
 Shrinking Phase : In this phase, the transaction releases all the
acquired locks once it performs all the modifications on the data item.
Once the transaction starts releasing the locks, it can not acquire any
locks further.
 Strict Two Phase Locking Protocol : It is almost similar to the two phase locking
protocol the only difference is that in two phase locking the transaction can
release its locks before it commits, but in case of strict two phase locking the
transactions are only allowed to release the locks only when they performs
commits.
Timestamp based Protocol
 In this protocol each transaction has a timestamp attached to it. Timestamp is
nothing but the time in which a transaction enters into the system.
 The conflicting pairs of operations can be resolved by the timestamp ordering
protocol through the utilization of the timestamp values of the transactions.
Therefore, guaranteeing that the transactions take place in the correct order.
Advantages of Concurrency
In general, concurrency means, that more than one transaction can work on a system. The
advantages of a concurrent system are:
 Waiting Time: It means if a process is in a ready state but still the process does
not get the system to get execute is called waiting time. So, concurrency leads to
less waiting time.
 Response Time: The time wasted in getting the response from the cpu for the
first time, is called response time. So, concurrency leads to less Response Time.
 Resource Utilization: The amount of Resource utilization in a particular system is
called Resource Utilization. Multiple transactions can run parallel in a system. So,
concurrency leads to more Resource Utilization.
 Efficiency: The amount of output produced in comparison to given input is called
efficiency. So, Concurrency leads to more Efficiency.
Disadvantages of Concurrency
 Overhead: Implementing concurrency control requires additional overhead, such
as acquiring and releasing locks on database objects. This overhead can lead to
slower performance and increased resource consumption, particularly in
systems with high levels of concurrency.
 Deadlocks: Deadlocks can occur when two or more transactions are waiting for
each other to release resources, causing a circular dependency that can prevent
any of the transactions from completing. Deadlocks can be difficult to detect and
resolve, and can result in reduced throughput and increased latency.
 Reduced concurrency: Concurrency control can limit the number of users or
applications that can access the database simultaneously. This can lead to
reduced concurrency and slower performance in systems with high levels of
concurrency.
 Complexity: Implementing concurrency control can be complex, particularly in
distributed systems or in systems with complex transactional logic. This
complexity can lead to increased development and maintenance costs.
 Inconsistency: In some cases, concurrency control can lead to inconsistencies in
the database. For example, a transaction that is rolled back may leave the
database in an inconsistent state, or a long-running transaction may cause other
transactions to wait for extended periods, leading to data staleness and reduced
accuracy.

How deadlock management is made possible

What are Deadlocks?

Deadlock is a state of a database system having two or more transactions, when each
transaction is waiting for a data item that is being locked by some other transaction. A
deadlock can be indicated by a cycle in the wait-for-graph. This is a directed graph in which
the vertices denote transactions and the edges denote waits for data items.

For example, in the following wait-for-graph, transaction T1 is waiting for data item X which
is locked by T3. T3 is waiting for Y which is locked by T2 and T2 is waiting for Z which is
locked by T1. Hence, a waiting cycle is formed, and none of the transactions can proceed
executing.
Deadlock Handling in Centralized Systems

There are three classical approaches for deadlock handling, namely −

 Deadlock prevention.
 Deadlock avoidance.
 Deadlock detection and removal.

All of the three approaches can be incorporated in both a centralized and a distributed
database system.

Deadlock Prevention

The deadlock prevention approach does not allow any transaction to acquire locks that will
lead to deadlocks. The convention is that when more than one transactions request for
locking the same data item, only one of them is granted the lock.

One of the most popular deadlock prevention methods is pre-acquisition of all the locks. In
this method, a transaction acquires all the locks before starting to execute and retains the
locks for the entire duration of transaction. If another transaction needs any of the already
acquired locks, it has to wait until all the locks it needs are available. Using this approach,
the system is prevented from being deadlocked since none of the waiting transactions are
holding any lock.

Deadlock Avoidance

The deadlock avoidance approach handles deadlocks before they occur. It analyzes the
transactions and the locks to determine whether or not waiting leads to a deadlock.

The method can be briefly stated as follows. Transactions start executing and request data
items that they need to lock. The lock manager checks whether the lock is available. If it is
available, the lock manager allocates the data item and the transaction acquires the lock.
However, if the item is locked by some other transaction in incompatible mode, the lock
manager runs an algorithm to test whether keeping the transaction in waiting state will
cause a deadlock or not. Accordingly, the algorithm decides whether the transaction can
wait or one of the transactions should be aborted.

There are two algorithms for this purpose, namely wait-die and wound-wait. Let us assume
that there are two transactions, T1 and T2, where T1 tries to lock a data item which is
already locked by T2. The algorithms are as follows −

 Wait-Die − If T1 is older than T2, T1 is allowed to wait. Otherwise, if T1 is younger

than T2, T1 is aborted and later restarted.
 Wound-Wait − If T1 is older than T2, T2 is aborted and later restarted. Otherwise, if
T1 is younger than T2, T1 is allowed to wait.
Deadlock Detection and Removal

The deadlock detection and removal approach runs a deadlock detection algorithm
periodically and removes deadlock in case there is one. It does not check for deadlock when
a transaction places a request for a lock. When a transaction requests a lock, the lock
manager checks whether it is available. If it is available, the transaction is allowed to lock
the data item; otherwise the transaction is allowed to wait.

Since there are no precautions while granting lock requests, some of the transactions may
be deadlocked. To detect deadlocks, the lock manager periodically checks if the wait-
forgraph has cycles. If the system is deadlocked, the lock manager chooses a victim
transaction from each cycle. The victim is aborted and rolled back; and then restarted later.
Some of the methods used for victim selection are −

 Choose the youngest transaction.

 Choose the transaction with fewest data items.
 Choose the transaction that has performed least number of updates.
 Choose the transaction having least restart overhead.
 Choose the transaction which is common to two or more cycles.

This approach is primarily suited for systems having transactions low and where fast
response to lock requests is needed.

Deadlock Handling in Distributed Systems

Transaction processing in a distributed database system is also distributed, i.e. the same
transaction may be processing at more than one site. The two main deadlock handling
concerns in a distributed database system that are not present in a centralized system
are transaction location and transaction control. Once these concerns are addressed,
deadlocks are handled through any of deadlock prevention, deadlock avoidance or
deadlock detection and removal.

Transaction Location

Transactions in a distributed database system are processed in multiple sites and use data
items in multiple sites. The amount of data processing is not uniformly distributed among
these sites. The time period of processing also varies. Thus the same transaction may be
active at some sites and inactive at others. When two conflicting transactions are located in
a site, it may happen that one of them is in inactive state. This condition does not arise in a
centralized system. This concern is called transaction location issue.

This concern may be addressed by Daisy Chain model. In this model, a transaction carries
certain details when it moves from one site to another. Some of the details are the list of
tables required, the list of sites required, the list of visited tables and sites, the list of tables
and sites that are yet to be visited and the list of acquired locks with types. After a
transaction terminates by either commit or abort, the information should be sent to all the
concerned sites.

Transaction Control

Transaction control is concerned with designating and controlling the sites required for
processing a transaction in a distributed database system. There are many options
regarding the choice of where to process the transaction and how to designate the center
of control, like −

 One server may be selected as the center of control.

 The center of control may travel from one server to another.
 The responsibility of controlling may be shared by a number of servers.
Distributed Deadlock Prevention

Just like in centralized deadlock prevention, in distributed deadlock prevention approach, a

transaction should acquire all the locks before starting to execute. This prevents deadlocks.

The site where the transaction enters is designated as the controlling site. The controlling
site sends messages to the sites where the data items are located to lock the items. Then it
waits for confirmation. When all the sites have confirmed that they have locked the data
items, transaction starts. If any site or communication link fails, the transaction has to wait
until they have been repaired.

Though the implementation is simple, this approach has some drawbacks −

 Pre-acquisition of locks requires a long time for communication delays. This increases
the time required for transaction.
 In case of site or link failure, a transaction has to wait for a long time so that the sites
recover. Meanwhile, in the running sites, the items are locked. This may prevent
other transactions from executing.
 If the controlling site fails, it cannot communicate with the other sites. These sites
continue to keep the locked data items in their locked state, thus resulting in
blocking.
Distributed Deadlock Avoidance

As in centralized system, distributed deadlock avoidance handles deadlock prior to

occurrence. Additionally, in distributed systems, transaction location and transaction
control issues needs to be addressed. Due to the distributed nature of the transaction, the
following conflicts may occur −

 Conflict between two transactions in the same site.

 Conflict between two transactions in different sites.

In case of conflict, one of the transactions may be aborted or allowed to wait as per
distributed wait-die or distributed wound-wait algorithms.
Let us assume that there are two transactions, T1 and T2. T1 arrives at Site P and tries to
lock a data item which is already locked by T2 at that site. Hence, there is a conflict at Site
P. The algorithms are as follows −

 Distributed Wound-Die
o If T1 is older than T2, T1 is allowed to wait. T1 can resume execution after Site
P receives a message that T2 has either committed or aborted successfully at
all sites.
o If T1 is younger than T2, T1 is aborted. The concurrency control at Site P sends
a message to all sites where T1 has visited to abort T1. The controlling site
notifies the user when T1 has been successfully aborted in all the sites.
 Distributed Wait-Wait
o If T1 is older than T2, T2 needs to be aborted. If T2 is active at Site P, Site P
aborts and rolls back T2 and then broadcasts this message to other relevant
sites. If T2 has left Site P but is active at Site Q, Site P broadcasts that T2 has
been aborted; Site L then aborts and rolls back T2 and sends this message to all
sites.
o If T1 is younger than T1, T1 is allowed to wait. T1 can resume execution after
Site P receives a message that T2 has completed processing.
Distributed Deadlock Detection

Just like centralized deadlock detection approach, deadlocks are allowed to occur and are
removed if detected. The system does not perform any checks when a transaction places a
lock request. For implementation, global wait-for-graphs are created. Existence of a cycle in
the global wait-for-graph indicates deadlocks. However, it is difficult to spot deadlocks since
transaction waits for resources across the network.

Alternatively, deadlock detection algorithms can use timers. Each transaction is associated
with a timer which is set to a time period in which a transaction is expected to finish. If a
transaction does not finish within this time period, the timer goes off, indicating a possible
deadlock.

Another tool used for deadlock handling is a deadlock detector. In a centralized system,
there is one deadlock detector. In a distributed system, there can be more than one
deadlock detectors. A deadlock detector can find deadlocks for the sites under its control.
There are three alternatives for deadlock detection in a distributed system, namely.

 Centralized Deadlock Detector − One site is designated as the central deadlock

detector.
 Hierarchical Deadlock Detector − A number of deadlock detectors are arranged in
hierarchy.
 Distributed Deadlock Detector − All the sites participate in detecting deadlocks and
removing them.

How does a distributed transaction differ from a centralized transaction?

Explain the distributed deadlock detection algorithm in detail.

What are the challenges in designing distributed concurrency control algorithms?

Define query optimization in centralized and distributed systems

How ordering of fragment queries done?

List and explain Distributed query optimization algorithms

Define transaction management. Goals and characteristics of transaction management.

Define transaction models

Transaction Models of DDBMS
What are Transactions?
A transaction symbolizes a unit of work performed within a database management system
(or similar system) against a database and treated in a coherent and reliable way
independent of other transactions. A transaction generally represents any change in a
database. Transactions in a database environment have two main purposes:
1. To provide reliable units of work that allow correct recovery from failures and
keep a database consistent even in cases of system failure. For example, when
execution prematurely and unexpectedly stops (completely or partially), many
operations upon a database remain uncompleted, with unclear status.
2. To provide isolation between programs accessing a database concurrently. If this
isolation is not provided, the programs’ outcomes are possibly erroneous.
When breaking apart our databases, we’ve already touched on some of the problems that
can result. Maintaining referential integrity becomes problematic, latency can increase, and
we can make activities like reporting more complex. We’ve looked at various coping
patterns for some of these challenges, but one big one remains: what about transactions?
Making changes to our database in a transaction can make our systems much easier to
reason about, and therefore easier to develop and maintain. We rely on our database to
ensure the safety and consistency of our data, leaving us to worry about other things. But
when we split data across databases, we lose the benefit of using a database transaction to
apply changes in state in an atomic fashion. Before we explore how to tackle this issue, let’s
look briefly at what a normal database transaction gives us.
ACID Transactions
Typically, when we talk about database transactions, we are talking about ACID transactions.
ACID is an acronym outlining the key properties of database transactions that lead to a
system we can rely on to ensure the durability and consistency of our data storage. and here
is what these properties give us:
 Atomicity: Ensures that all operations completed within the transaction either all
complete or all fail. If any of the changes we’re trying to make fail for some
reason, then the whole operation is aborted, and it’s as though no changes were
ever made.
 Consistency: When changes are made to our database, we ensure it is left in a
valid, consistent state.
 Isolation: Allows multiple transactions to operate at the same time without
interfering.
This is achieved by ensuring that any interim state changes made during one
transaction are invisible to other transactions.
 Durability: Makes sure that once a transaction has been completed, we are
confident the data won’t get lost in the event of some system failure.
I want to be clear that we can still use ACID-style transactions when we split databases
apart, but the scope of these transactions is reduced, as is their usefulness. With a single
database, this is done in the scope of a single ACID database transaction either the new rows
are written, or neither is written, We could exactly do the same thing in a distributed
database, but now each change is made in a different database. This means there are two
transactions to consider, each of which could work or fail independently of the other
This lack of atomicity can start to cause significant problems, especially if we are migrating
systems that previously relied on this property. It’s at this point that people start to look for
other solutions to give them some ability to reason about changes being made to multiple
services at once. Normally, the first option that people start considering is distributed
transactions. Let’s look at one of the most common algorithms for implementing distributed
transactions, the two-phase commit, as a way of exploring the challenges associated with
distributed transactions as a whole.
Two-Phase Commits

The two-phase commit algorithm (sometimes shortened to 2PC) is frequently used to

attempt to give us the ability to make transactional changes in a distributed system, where
multiple separate processes may need to be updated as part of the overall operation. I want
to let you know upfront that 2PCs have limitations, which we’ll cover, but they’re worth
knowing about. Distributed transactions, and two-phased commits more specifically, are
frequently raised by teams moving to microservice architectures
as a way of solving challenges they face. But as we’ll see, they may not solve your problems
and may bring even more confusion to your system.
The algorithm is broken into two phases (hence the name two-phase commit): a voting
phase and a commit phase. During the voting phase, a central coordinator contacts all the
workers who are going to be part of the transaction, and asks for confirmation as to whether
or not some state change can be made.
When two-phase commits work, at their heart they are very often just coordinating
distributed locks. The workers need to lock local resources to ensure that the commit can
take place during the second phase. Managing locks, and avoiding deadlocks in a single-
process system, isn’t fun. Now imagine the challenges of coordinating locks among multiple
participants. It’s not pretty. There are a host of failure modes associated with two-phase
commits that we don’t have time to explore. Consider the problem of a worker voting to
proceed with the transaction, but then not responding when asked to commit. What should
we do then? Some of these failure modes can be handled automatically, but some can leave
the system in such a state that things need to be manually unpicked. The more participants
you have, and the more latency you have in the system, the more issues a two-phase
commit will have. They can be a quick way to inject huge amounts of latency into your
system, especially if the scope of locking is large, or the duration of the transaction is large.
It’s for this reason two-phase commits are typically used only for very short-lived operations.
The longer the operation takes, the longer you’ve got resources locked for!

Why using Distributed Transactions is not a good decision?

For all these reasons outlined so far, I strongly suggest you avoid the use of distributed
transactions like the two-phase commit to coordinate changes in the state across your
Distributed system. So what else can you do?
Well, the first option could be to just not split the data apart in the first place. If you have
pieces of state that you want to manage in a truly atomic and consistent way, and you
cannot work out how to sensibly get these characteristics without an ACID-style transaction,
then leave that state in a single database, and leave the functionality that
manages that state in a single service (or in your monolith). If you’re in the process of
working out where to split your monolith and working out what decompositions might be
easy (or hard), then you could well decide that splitting apart data that is currently managed
in a transaction is just too hard to handle right now. Work on some other area of the system,
and come back to this later. But what happens if you really do need to break this data apart,
but you don’t want all the pain of managing distributed transactions? How can we carry out
operations in multiple services but avoid locking? What if the operation is going to take
minutes, days, or perhaps even months? In cases like this, we can consider an alternative
approach: sagas.
Sagas

Unlike a two-phase commit, a saga is by design an algorithm that can coordinate multiple
changes in state, but avoids the need for locking resources for long periods of time. We do
this by modeling the steps involved as discrete activities that can be executed
independently. It comes with the added benefit of forcing us to explicitly model our business
processes, which can have significant benefits. The core idea, first outlined by Hector Garcia-
Molina and Kenneth Salem, 10 reflected on the challenges of how best to handle operations
of what they referred to as long-lived transactions (LLT). These transactions might take a
long time (minutes, hours, or perhaps even days), and as part of that process require
changes to be made to a database.
If you directly mapped an LLT to a normal database transaction, a single database
transaction would span its entire life cycle of it. This could result in multiple rows or even full
tables being locked for long periods of time while the LLT is taking place, causing significant
issues if other processes are trying to read or modify these locked resources. Instead, the
authors of the paper suggest we should break down these LLTs into a sequence of
transactions, each of which can be handled independently. The idea is that the duration of
each of these “sub” transactions will be shorter-lived, and will modify only part of the data
affected by the entire LLT. As a result, there will be far less contention in the underlying
database as the scope and duration of locks is
greatly reduced. While sagas were originally envisaged as a mechanism to help with LLTs
acting against a single database, the model works just as well for coordinating change across
multiple services. We can break a single business process into a set of calls that will be made
to collaborating services as part of a single saga.

Saga Failure Modes

With a saga being broken into individual transactions, we need to consider how to handle
failure, more specifically, how to recover when a failure happens. The original saga paper
describes two types of recovery: backward recovery and forward recovery. Backward
recovery involves reverting the failure and cleaning up afterward a rollback. For this to work,
we need to define compensating actions that allow us to undo previously committed
transactions. Forward recovery allows us to pick up from the point where the failure
occurred, and keep processing. For that to work, we need to be able to retry transactions,
which in turn implies that our system is persisting enough information to allow this retry to
take place. Depending on the nature of the business process being modeled, you may
consider that any failure mode triggers a backward recovery, a forward recovery, or perhaps
a mix of the two.
Implementing Sagas
So far, we’ve looked at the logical model for how sagas work, but we need to go a bit deeper
to examine ways of implementing the saga itself. We can look at two styles of saga
implementation. Orchestrated sagas more closely follow the original solution space and rely
primarily on centralized coordination and tracking. These can be compared to
choreographed sagas, which avoid the need for centralized coordination in favor of a more
loosely coupled model, but which can make tracking the progress of a saga more
complicated.
Orchestrated sagas
Orchestration is a way to centralize the workflow of logic for a business process. It
coordinates the workflow by sending commands to the appropriate service and consuming
the resulting events. In contrast to choreography, Orchestration tells other services what
action/command to perform rather than those services being reactive to other events in the
system.
Taking the order fulfillment process shown in the image blow , let’s see how this central
coordination process would work as a set of collaborating services, Here, our central Order
Processor, playing the role of the orchestrator, coordinates our fulfillment process. It knows
what services are needed to carry out the operation, and it decides when to make calls to
those services. If the calls fail, it can decide what to do as a result. These orchestrated
processors tend to make heavy use of request/ response calls between services: the Order
Processor sends a request to services (such as a Payment Gateway), and expects a response
letting it know if the request was successful and providing the results of the request. Having
our business process explicitly modeled inside the Order Processor is extremely beneficial. It
allows us to look at one place in our system and understand how this process is supposed to
work. That can make the onboarding of new people easier, and help impart a better
understanding of the core parts of the system.
Benefits & drawbacks of Orchestration
 Centralized logic: this can be good and bad
 Easier to understand the workflow since its defined in a central location
 Full control over the workflow steps via commands
 Point of failure
 Easier to debug and test
Choreographed sagas
Choreographed sagas aim to distribute responsibility for the operation of the saga among
multiple collaborating services. If orchestration is command-and-control, choreographed
sagas represent a trust-but-verify architecture. As we’ll see in our example in the image,
choreographed sagas will often make heavy use of events for collaboration between
services.
There’s quite a bit going on here, so it’s worth exploring in more detail. First, these services
are reacting to events being received. Conceptually, events are broadcast in the system, and
interested parties are able to receive them. You don’t send events to a service; you just fire
them out, and the services that are interested in these events are able to receive them and
act accordingly. In our example, when the Warehouse service receives that first Order
Placed event, it knows its job to reserve the appropriate stock and fire an event once that is
done. If the stock couldn’t be received, the Warehouse would need to raise an appropriate
event (an Insufficient Stock event perhaps), which might lead to the order being aborted

Benefits & drawbacks of Choreography

 No centralized logic: this can be good and bad
 Useful for small/simple workflows
 Difficult to conceptualize if a lot of services are involved.
 Hader to debug & test if a lot of services are involved
Choreography or Orchestration?
Implementing choreographed sagas can bring with it ideas that may be unfamiliar to you
and your team. They typically assume heavy use of event-driven collaboration, which isn’t
widely understood. However, in my experience, the extra complexity associated with
tracking the progress of a saga is almost always outweighed by the benefits associated with
having a more loosely coupled architecture. Stepping aside from my own personal tastes,
though, the general advice I give regarding orchestration versus choreography is that I am
very relaxed in the use of orchestrated sagas when one team owns the implementation of
the entire saga. In such a situation, the more inherently coupled architecture is much easier
to manage within the team boundary. If you have multiple teams involved, I greatly prefer
the more decomposed choreographed saga as it is easier to distribute responsibility for
implementing the saga to the teams, with the more loosely coupled architecture allowing
these teams to work more in isolation.
Sagas Versus Distributed Transactions
As I hope I have broken down by now, distributed transactions come with some significant
challenges, and outside of some very specific situations are something I tend to avoid. Pat
Helland, a pioneer in distributed systems, distills the fundamental challenges of
implementing distributed transactions for the kinds of applications we build today. explicitly
modeling business processes as a saga avoids many of the challenges of distributed
transactions, while at the same time has the added benefit of making what might otherwise
be implicitly modeled processes much more explicit and obvious to your developers. Making
the core business processes of your system a first-class concept will have a host of benefits.
A fuller discussion of implementing orchestration and choreography, along with the various
implementation details.

Explain concurrency control in distributed database systems

Concurrency Control in Distributed Transactions

Concurrency control mechanisms provide us with various concepts & implementations to
ensure the execution of any transaction across any node doesn’t violate ACID or BASE
(depending on database) Properties causing inconstancy & mixup of data in the distributed
systems. Transactions in the distributed system are executed in “sets“, every set consists of
various sub-transactions. These sub-transactions across every node must be executed
serially to maintain data integrity & the concurrency control mechanisms do this serial
execution.
Types of Concurrency Control Mechanisms
There are 2 types of concurrency control mechanisms as shown below diagram:

Types of Concurrency Control Mechanism

Pessimistic Concurrency Control (PCC)

The Pessimistic Concurrency Control Mechanisms proceeds on assumption that, most of
the transactions will try to access the same resource simultaneously. It’s basically used to
prevent concurrent access to a shared resource and provide a system of acquiring a Lock on
the data item before performing any operation.
Optimistic Concurrency Control (OCC)
The problem with pessimistic concurrency control systems is that, if a transaction acquires
a lock on a resource so that no other transactions can access it. This will result in reducing
concurrency of the overall system.
The Optimistic Concurrency control techniques proceeds on the basis of assumption that, 0
or very less transactions will try to access a certain resource simultaneously. We can
describe a system as FULLY OPTIMISTIC, if it uses NO-Locks at all & checks for conflicts at
commit time. It has following 4-phases of operation:
 Read Phase: When a transaction begins, it read the data while also logging the
time-stamp at which data is read to verify for conflicts during the validation phase.
  Execution Phase: In this phase, the transaction executes all its operation like
create, read, update or delete etc.
 Validation Phase: Before committing a transaction, a validation check is
performed to ensure consistency by checking the last_updated timestamp with
the one recorded at read_phase. If the timestamp matches, then the transaction
will be allowed to be committed and hence proceeds with commit phase.
 Commit phase: During this phase, the transactions will either be committed
or aborted, depending on the validation check performed during previous phase.
If the timestamp matches, then transactions are committed else they’re aborted.

Pessimistic Concurrency Control Methods

Following are the four Pessimistic Concurrency Control Methods:
Isolation Level
The isolation levels are defined as a degree to which the data residing in Database must be
isolated by transactions for modification. Because, if some transactions are operating on
some data let’s say transaction – T1 & there comes another transaction – T2 and modifies it
further while it was under operation by transaction T1 this will cause unwanted
inconsistency problems. Methods provided in this are: Read-Uncomitted, Read-
Comitted, Repeatable Read & Serializable.
Two-Phase Locking Protocol
The two-phase locking protocol is a concurrency technique used to manage locks on data
items in database. This technique consists of 2 phases:
Growing Phase: The transaction acquires all the locks on the data items that’ll be
required to execute the transaction successfully. No locks will be realease in this phase.
Shrinking Phase: All the locks acquired in previous phase will be released one by one
and No New locks will be acquired in this phase.
Distributed Lock Manager
A distributed lock a critical component in the distributed transaction system, which co-
ordinates the lock acquiring, and releasing operations in the transactions. It helps in
synchronizing the transaction and their operation so that data integrity is maintained.
 Distributed Lock Manager (DLM)

Multiple Granularity Lock

A lock can be acquired at various granular level like: table level, row/record level, page level
or any other resource’s level. In transaction system a transaction can lock a whole table, or
a specific row while performing some changes on it. This lock acquiring when done by
various transactions simultaneously, this phenomena is called as multiple granularity
locking.

Optimistic Concurrency Control Methods

Below are four Optimistic Concurrency Control Methods:
Timestamp Based (OCC)
In a timestamp based concurrency technique, each transaction in the system is assigned a
unique timestamp which is taken as soon as the transaction begins, and its verified again
during the commit phase. If there’s new updated timestamp from a different transaction
then based on some policy defined by the System the transaction will either be restarted or
aborted. But if the times stamp is same & never modified by any other transaction then it
will be committed.
Example: Let’s say we have two transaction T1 and T2, they operate on data item – A. The
Timestamp concurrency technique will keep track of the timestamp when the data was
accessed by transaction T1 first time.
Transaction Data item and Most_recent_Timestam Initial_timestamp
operation p of data item (A)
T1 Read(A) 12:00PM 12:00PM
T2 Write(A) 12:15PM 12:00PM
T1 Write(A) 12:30PM 12:00PM
Now, let’s say this transaction T1 is about to commit, before committing, it will check the
initial timestamp with the most recent timestamp. In our case, the transaction T1 won’t be
committed because a write operations by transaction T2 was performed.
if(Initial_timestamp == Most_recent_timestamp)
then ‘Commit’
else
‘Abort’
In our case, transaction will be aborted because T2 modified the same data item at
12:15PM.
Multi-Version Concurrency Control (MVCC)
In MVCC, every data item has multiple versions of itself. When a transaction starts, it reads
the version that is valid at the start of the transaction. And when the transaction writes, it
creates a new version of that specific data item. That way, every transaction can
concurrently perform their operations.
Example: In a banking system two or more user can transfer money without blocking each
other simultaneously.
A similar technique to this is : Immutable Data Structures. Every time a transaction
performs a new operation, new data item will be created so that way transactions do not
have to worry about consistency issues.
Snapshot Isolation
Snapshot isolation is basically a snapshot stored in an isolated manner when our database
system was purely consistent. And this snapshot is read by the transactions at the
beginning. Transaction ensures that the data item is not changed while it was executing
operations on it. Snapshot isolation is achieved through OCC & MVCC techniques.
Conflict Free Replicated Data Types (CRDTs)
CRDTs is a data structure technique which allows a transaction to perform all its operation
and replicate the data to some other node or current node. After all the operations are
performed, this technique offers us with merging methods that allows us to merge the data
across distributed nodes (conflict-free) and eventually achieving consistent state
(eventually consistent property).

List and explain distributed concurrency control

algorithms
There are two approaches used in algorithms to deals with the problems of concurrency
control. These are:
• Pessimistic Approach
• Optimistic Approach
Pessimistic Approach: This approach causes transaction to be delayed in case they conflict
with each other at the some time in the future.
Pessimistic Execution: The validate operation is performed first, if there is a validation
according to compatibility of lock then only read, compute and write operations are
performed
There are two commonly used algorithms, which are based on Pessimistic Approach .
• Two phase locking protocol
• Time stamp ordering protocol
Optimistic Approach: The optimistic method of concurrency control is based on the
assumption that conflicts of database operations are rare and that it is better to let
transactions run to completion and only check for conflicts before they commit. An
optimistic concurrency control method is also known as validation or certification
methods. No checking is done while the transaction is executing. The optimistic method
does not require locking or time stamping techniques. Instead, a transaction is executed
without restrictions until it is committed.
It allows transactions to proceed unsynchronized and only check conflicts at the end. This
approach is based on the premise that conflicts are rare
Optimistic Execution: It perform read and compute operation without validation and
perform validation just before write operation.
Advantages of Optimistic Methods for Concurrency Control
The optimistic concurrency control has the following advantages:
• This technique is very efficient when conflicts are rare. The occasional conflicts result in
the transaction roll back.
• The rollback involves only the local copy of data, the database is not involved and thus
there will not be any cascading rollbacks.
Problems of Optimistic Methods for Concurrency Control
The optimistic concurrency control suffers from the following problems:
• Conflicts are expensive to deal with, since the conflicting transaction must be rolled back.
• Longer transactions are more likely to have conflicts and may be repeatedly rolled back
because of conflicts with short transactions.
Applications of Optimistic Methods for Concurrency Control
• Only suitable for environments where there are few conflicts and no long transactions.
• Acceptable for mostly Read or Query database systems that requires very few update
transactions.
Two phase locking protocol (Pessimistic Approach)
A transaction follows the two phase locking protocol, if all locking operations precede the
first unlock operation in the transaction. There are two phases in the Schedule. These are:
• Growing Phase: During which all locks are requested.
• Shrinking Phase: During which all locks are released.
Initially, a transaction is in the growing phase. The transaction acquires locks as needed.
Once the transaction releases a lock, it enters the shrinking phase and it can issue no more
lock requests.

Transaction T3 and T4 are two phase. On the other hand transaction Tl and T2 are not two
phase as shown below.
Note that the unlock instructions do not need to appear at the end of the transaction. For
example, in the case of transaction T3, we could move the unlock(B) instruction to just
after the lock-X(A) instruction and still retain the two-phase locking property: The point in
the schedule where the transaction has obtained its final lock the end of its growing phase
is called the lock point of the transaction.
Now, transactions can be ordered according to their lock points.
Problems with two-phase locking protocols
There are two problems with two-phase locking protocols. These are:
1. Deadlock
2. Cascading roll-back
Deadlock: As discussed above, two-phase locking does not ensure freedom from deadlock.
As shown in transaction T3 and T4 are in two phase, but still there is problem of deadlock.
Cascading roll-back: As shown in partial schedule shown on next page each transaction
observers two-phase locking protocol.
Let us consider, if transaction T5 fails after the read (A,a) operation of transaction ofT7.
Then, T5 must be rollback, which also results into rollback of T6 and T7. Because,
transaction T6 and T7 reads the value of A modified by transaction T5… Since transaction
T5 fails and rollback, it means that transaction T5 obtain the original value of A and
cancels’ the modified value of A, but the other transactions T6 and T7 process the modified
value of A and into inconsistent state of database. In order to obtain the consistent state
of database transactions T6 and T7, must also rollback and has to start again. It is case of
dirty read.
Thus we can say that rollback of T5 results in to rollback T6 and T7 also. This problem is
called as cascading of rollback.
Solutions to avoid cascading of rollbacks
There are two solutions to avoid cascading of rollback. These are:
• Strict two phase locking protocol
• Rigorous two phase locking protocol
Strict two-phase locking protocol: The strict two-phase locking protocol, requires, that in
addition to locking being two-phase, all exclusive-mode locks taken by a transaction must
beheld until that transaction commits. This requirement ensures that any data written by
an uncommitted transaction are locked in exclusive mode until the transaction commits,
preventing any other transaction from reading the data.
Rigorous two-phase locking protocol: It requires all locks to be held until the transaction
commits. It can be easily verified that, with rigorous two-phase locking transactions can be
serialized in the order in which they commit. Most database systems implement either
strict or rigorous two-phase locking.
Differentiate between spatial database and web database
Difference between Spatial and Temporal Data Mining

Spatial data mining refers to the process of extraction of knowledge, spatial relationships
and interesting patterns that are not specifically stored in a spatial database; on the other
hand, temporal data mining refers to the process of extraction of knowledge about the
occurrence of an event whether they follow, random, cyclic, seasonal variation, etc. Spatial
means space, whereas temporal means time. In this article, we will learn Spatial and
temporal data mining separately; after that, we will discuss the difference between them.

What is Spatial Data Mining?

The emergence of spatial data and extensive usage of spatial databases has led to spatial
knowledge discovery. Spatial data mining can be understood as a process that determines
some exciting and hypothetically valuable patterns from spatial databases.

Several tools are there that assist in extracting information from geospatial data. These
tools play a vital role for organizations like NASA, the National Imagery and Mapping
Agency (NIMA), the National Cancer Institute (NCI), and the United States Department of
Transportation (USDOT) which tends to make big decisions based on large spatial datasets.

Besides, the general-purpose tools were preferably used to analyze scientific and
engineering data, astronomical data, multimedia data, genomic data, and web data.

These are the given specific features of geographical data that prevent the use of general-
purpose data mining algorithms are:

1. spatial relationships among the variables,

2. spatial structure of errors
3. observations that are not independent
4. spatial autocorrelation among the features
5. non-linear interaction in feature space.

Spatial data must have latitude or longitude, UTM easting or northing, or some other
coordinates denoting a point's location in space. Beyond that, spatial data can contain any
number of attributes pertaining to a place. You can choose the types of attributes you want
to describe a place. Government websites provide a resource by offering spatial data, but
you need not be limited to what they have produced. You can produce your own.

Say, for example, you wanted to log information about every location you've visited in the
past week. This might be useful to provide insight into your daily habits. You could capture
your destination's coordinates and list a number of attributes such as place name, the
purpose of visit, duration of visit, and more. You can then create a shapefile in Quantum
GIS or similar software with this information and use the software to query and visualize
the data. For example, you could generate a heatmap of the most visited places or select all
places you've visited within a radius of 8 miles from home.

Any data can be made spatial if it can be linked to a location, and one can even have
spatiotemporal data linked to locations in both space and time. For example, when
geolocating tweets from Twitter in the aftermath of a disaster, an animation might be
generated that shows the spread of tweets from the epicentre of the event.

Spatial data mining tasks

These are the primary tasks of spatial data mining.

Classification:

Classification determines a set of rules which find the class of the specified object as per its
attributes.

Association rules:

Association rules determine rules from the data sets, and it describes patterns that are
usually in the database.

Characteristic rules:

Characteristic rules describe some parts of the data set.

Discriminate rules:

As the name suggests, discriminate rules describe the differences between two parts of the
database, such as calculating the difference between two cities as per employment rate.

What is temporal data mining?

Temporal data mining refers to the process of extraction of non-trivial, implicit, and
potentially important data from huge sets of temporal data. Temporal data are sequences
of a primary data type, usually numerical values, and it deals with gathering useful
knowledge from temporal data.
With the increase of stored data, the interest in finding hidden data has shattered in the
last decade. The finding of hidden data has primarily been focused on classifying data,
finding relationships, and data clustering. The major drawback that comes during the
discovery process is treating data with temporal dependencies. The attributes related to
the temporal data present in this type of dataset must be treated differently from other
types of attributes. Therefore, most data mining techniques treat temporal data as an
unordered collection of events, ignoring its temporal data.

Temporal data mining tasks

o Data characterization and comparison
o Cluster Analysis
o Classification
o Association rules
o Prediction and trend analysis
o Pattern Analysis

Difference between spatial and Temporal data mining

Spatial Data Mining Temporal Data Mining
Spatial data mining refers to the temporal data mining refers to the process of
extraction of knowledge, spatial extraction of knowledge about the occurrence of
relationships and interesting patterns an event whether they follow, random, cyclic,
that are not specifically stored in a seasonal variation, etc
spatial database.
It needs space. It needs time.
Primarily, it deals with spatial data Primarily, it deals with implicit and explicit
such as location, geo-referenced. temporal content, form a huge set of data.
It involves characteristic rules, It targets mining new patterns and unknown
discriminant rules, evaluation rules, knowledge, which takes the temporal aspects of
and association rules. data.
Examples: Finding hotspots, unusual Examples: An association rules which seems -
locations. "Any person who buys motorcycle also buys
helmet". By temporal aspect, this rule would be -
"Any person who buys a motorcycle also buy a
helmet after that."

Explain different reliability techniques

Fundamental Definitions
• Reliability
➡ A measure of success with which a system conforms to some authoritative specification of its
behavior
• Availability
➡ The fraction of the time that a system meets its specification
• Failure
➡ The deviation of a system from the behavior that is described in its specification

Types of Failures
• Transaction failures
➡ Transaction aborts (unilaterally or due to deadlock)
• System (site) failures
➡ Failure of processor, main memory, power supply, …
➡ Main memory contents are lost, but secondary storage contents are safe
➡ Partial (some sites) vs. total (all sites) failure
• Media failures
➡ Failure of secondary storage devices such that the stored data is lost
➡ Head crash/controller failure (?) Distributed DBMS © M. T. Özsu & P. Valduriez Ch.12/6
➡ Permanent data loss (secondary, resilient, stable memory – hard disk)
• Communication failures
➡ Lost/undeliverable messages
➡ Network partitioning
What are the challenges in designing reliable distributed database systems?

What is Byzantine fault tolerance, and how is it used to improve reliability in distributed
database systems?

What is the meaning of consistency in distributed database systems, and how is it related to
reliability?

What is reliability in the context of distributed database systems, and why is it important?

Explain reliability issues in DDBMS

Explain types of failures
Failures in Distributed System
DSM implements distributed systems shared memory model in an
exceedingly distributed system, that hasn’t any physically shared memory.
The shared model provides a virtual address space shared between any
numbers of nodes. The DSM system hides the remote communication
mechanism from the appliance author, protecting the programming ease and
quality typical of shared-memory systems.

These are explained as following below.

1. Method failure :
In this type of failure, the distributed system is generally halted and unable to
perform the execution. Sometimes it leads to ending up the execution
resulting in an associate incorrect outcome. Method failure causes the system
state to deviate from specifications, and also method might fail to progress.
 Behavior –
It may be understood as if incorrect computation like Protection
violation, deadlocks, timeout, user input, etc is performed then the
method stops its execution.
 Recovery –
Method failure can be prevented by aborting the method or restarting
it from its prior state.
2. System failure :
In system failure, the processor associated with the distributed system fails to
perform the execution. This is caused by computer code errors and hardware
issues. Hardware issues may involve CPU/memory/bus failure. This is assumed
that whenever the system stops its execution due to some fault then the
interior state is lost.
 Behavior –
It is concerned with physical and logical units of the processor. The
system may freeze, reboot and also it does not perform any
functioning leading it to go in an idle state.
 Recovery –
This can be cured by rebooting the system as soon as possible and
configuring the failure point and wrong state.
3. Secondary storage device failure :
A storage device failure is claimed to have occurred once the keep
information can’t be accessed. This failure is sometimes caused by parity
error, head crash, or dirt particles settled on the medium.
 Behavior –
Stored information can’t be accessed.
  Errors inflicting failure –
Parity error, head crash, etc.
 Recovery/Design strategies –
Reconstruct content from the archive and the log of activities and
style reflected disk system. A system failure will additionally be
classified as follows.
 Associate cognitive state failure
 A partial cognitive state failure
 a disruption failure
 A halting failure
4. Communication medium failure :
A communication medium failure happens once a web site cannot
communicate with another operational site within the network. it’s typically
caused by the failure of the shift nodes and/or the links of the human activity
system.
 Behavior –
A web site cannot communicate with another operational site.
 Errors/Faults –
Failure of shift nodes or communication links.
 Recovery/Design strategies –
Reroute, error-resistant communication protocols.
Failure Models:
1. Timing failure:
Timing failure occurs when a node in a system correctly sends a response, but
the response arrives earlier or later than anticipated. Timing failures, also
known as performance failures, occur when a node delivers a response
that is either earlier or later than anticipated.
2. Response failure:
When a server’s response is flawed, a response failure occurs. The response’s
value could be off or transmitted using the inappropriate control flow.
3. Omission failure:
A timing issue known as an “infinite late” or omission failure occurs when the
node’s answer never appears to have been sent.
4. Crash failure:
If a node encounters an omission failure once and then totally stops
responding and goes unresponsive, this is known as a crash failure.
5. Arbitrary failure :
A server may produce arbitrary response at arbitrary times.

Explain commit protocols and recovery protocols

Distributed DBMS - 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.

Distributed DBMS - Database Recovery

In order to recuperate from database failure, database management

systems resort to a number of recovery management techniques. In this
chapter, we will study the different approaches for database recovery.

The typical strategies for database recovery are −

 In case of soft failures that result in inconsistency of database,

recovery strategy includes transaction undo or rollback. However,
sometimes, transaction redo may also be adopted to recover to a
consistent state of the transaction.
 In case of hard failures resulting in extensive damage to database,
recovery strategies encompass restoring a past copy of the database
from archival backup. A more current state of the database is obtained
through redoing operations of committed transactions from transaction
log.
Recovery from Power Failure

Power failure causes loss of information in the non-persistent memory. When

power is restored, the operating system and the database management
system restart. Recovery manager initiates recovery from the transaction
logs.
In case of immediate update mode, the recovery manager takes the
following actions −

 Transactions which are in active list and failed list are undone and
written on the abort list.
 Transactions which are in before-commit list are redone.
 No action is taken for transactions in commit or abort lists.

In case of deferred update mode, the recovery manager takes the following
actions −

 Transactions which are in the active list and failed list are written onto
the abort list. No undo operations are required since the changes have
not been written to the disk yet.
 Transactions which are in before-commit list are redone.
 No action is taken for transactions in commit or abort lists.
Recovery from Disk Failure

A disk failure or hard crash causes a total database loss. To recover from
this hard crash, a new disk is prepared, then the operating system is
restored, and finally the database is recovered using the database backup
and transaction log. The recovery method is same for both immediate and
deferred update modes.

The recovery manager takes the following actions −

 The transactions in the commit list and before-commit list are redone
and written onto the commit list in the transaction log.
 The transactions in the active list and failed list are undone and written
onto the abort list in the transaction log.
Checkpointing
Checkpoint is a point of time at which a record is written onto the database
from the buffers. As a consequence, in case of a system crash, the recovery
manager does not have to redo the transactions that have been committed
before checkpoint. Periodical checkpointing shortens the recovery process.

The two types of checkpointing techniques are −

 Consistent checkpointing
 Fuzzy checkpointing
Consistent Checkpointing

Consistent checkpointing creates a consistent image of the database at

checkpoint. During recovery, only those transactions which are on the right
side of the last checkpoint are undone or redone. The transactions to the left
side of the last consistent checkpoint are already committed and needn’t be
processed again. The actions taken for checkpointing are −

 The active transactions are suspended temporarily.

  All changes in main-memory buffers are written onto the disk.
 A “checkpoint” record is written in the transaction log.
 The transaction log is written to the disk.
 The suspended transactions are resumed.

If in step 4, the transaction log is archived as well, then this checkpointing

aids in recovery from disk failures and power failures, otherwise it aids
recovery from only power failures.

Fuzzy Checkpointing

In fuzzy checkpointing, at the time of checkpoint, all the active transactions

are written in the log. In case of power failure, the recovery manager
processes only those transactions that were active during checkpoint and
later. The transactions that have been committed before checkpoint are
written to the disk and hence need not be redone.

Example of Checkpointing
Let us consider that in system the time of checkpointing is tcheck and the
time of system crash is tfail. Let there be four transactions T a, Tb, Tc and
Td such that −
 Ta commits before checkpoint.
 Tb starts before checkpoint and commits before system crash.
 Tc starts after checkpoint and commits before system crash.
 Td starts after checkpoint and was active at the time of system crash.

The situation is depicted in the following diagram −

The actions that are taken by the recovery manager are −

 Nothing is done with Ta.

 Transaction redo is performed for Tb and Tc.
 Transaction undo is performed for Td.
Transaction Recovery Using UNDO / REDO

Transaction recovery is done to eliminate the adverse effects of faulty

transactions rather than to recover from a failure. Faulty transactions
include all transactions that have changed the database into undesired state
and the transactions that have used values written by the faulty
transactions.

Transaction recovery in these cases is a two-step process −

 UNDO all faulty transactions and transactions that may be affected by

the faulty transactions.
 REDO all transactions that are not faulty but have been undone due to
the faulty transactions.

Steps for the UNDO operation are −

 If the faulty transaction has done INSERT, the recovery manager

deletes the data item(s) inserted.
 If the faulty transaction has done DELETE, the recovery manager
inserts the deleted data item(s) from the log.
 If the faulty transaction has done UPDATE, the recovery manager
eliminates the value by writing the before-update value from the log.

Steps for the REDO operation are −

 If the transaction has done INSERT, the recovery manager generates

an insert from the log.
 If the transaction has done DELETE, the recovery manager generates a
delete from the log.
 If the transaction has done UPDATE, the recovery manager generates
an update from the log.

How spatial database and web databases are used in parallel

database systems
How is distributed object management done in parallel database
systems
Parallel DBMS is a Database Management System that runs through multiple processors
and disks. They combine two or more processors also disk storage that helps make
operations and executions easier and faster. They are designed to execute concurrent
operations. They exist, happen, or done at the same time even if the data processed are not
from one source or one processing unit.

The main architecture for parallel DBMS is:

1. Shared Memory System
A Shared Memory System is an architecture of Database Management System, where every
computer processor is able to access and process data from multiple memory modules or
unit through intercommunication channel. This architecture is also commonly known as
SMP or Symmetric Multi-processing. A Shared Memory System contains large amounts of
cache memories at each processor, so referencing of the shared memory is avoided.

Advantages of Shared Memory:

 Data is easily accessed from various processors.
 A single processor can send messages to other processors efficiently.
Disadvantage of Shared Memory:
 Waiting time for every single processor increases when all of them are uses.
 Bandwidth is also a problem.
2. Shared Disk System
A Shared Disk System is an architecture of Database Management System where every
computer processors can access multiple disk through intercommunication network. It can
also access and utilize every local memory. Each of the processors have own memory
system, so the shared data are more efficient.

Advantages of Shared Disk System:

 The fault tolerance can be achieved using this system.
Disadvantages of Shared Disk System:
 The addition of processors can slow down existing processors.
 Shared Disk System have a limited scalability meaning it is sometimes fixed.
3. Shared Nothing System
A Shared Nothing System is an architecture of Database Management System where every
processor has their own disk and memory for the objective of efficient workflows. The
processors can communicate with other processors using intercommunication network.
Each of the processors act like servers to store data on the disk. So there can be an efficient
and effective workflows.

Advantage of Shared Nothing System

 This system has more scalability.
  Number of processors and disk can be connected as per the requirement in share
nothing disk system.
Disadvantage of Shared Nothing system
 Must require the partitioning of data.
 Cost that need for this system is higher.
a. Advantages of parallel DBMS :
 Speed
The first advantage of parallel DBMS is speed. The servers from parallel DBMS are
able to break up user database request into parts and it dispatches each of the
parts to separate computers. They work on these “work parts” simultaneously
and they merge the results, passing them back to the user. This speeds up most
of the data requests, allowing faster access to very large databases.
 Reliability
The second advantage is reliability. A parallel database when properly
configured, can continue to work despite the failure of any computer in the
cluster. The database server can sense that a specific computer is not responding,
and it can reroute its work to the remaining computers.
 Capacity
The third advantage is capacity. As more and more users request access to the
database, the computer administrators add more computers to the parallel
server, boosting its overall capacity to the max, databases are more likely to slow
down and have slower system. A parallel database, for example, allows a large
online retailer to have thousands of requests of users accessing information at
the same time. This level of processing performance is not possible with single
server systems.
b. Disadvantage of Parallel DBMS :
 Cost
The first disadvantage of parallel DBMS is cost. As the need of quicker processing
and efficient searches increase, there need to be more and more disks and
processors that simultaneously work together to achieve the best and quickest
results. To do that, Parallel DBMS needs lots of processors and disks in the first
place. At the end, it is never cheap to implement parallel DBMSs.
 Resources
The second disadvantage of parallel DBMS is the huge amount of resources. It is
not and will never be easy to keep up with modern, cheap, and efficient
resources. Implementing DBMS requires the users or the company to have
renewal of resources, changing or maintaining resources, or even replacement of
resources.
 Difficulty of Managing Systems
The third disadvantage of parallel DBMS is the difficulty in systems managing.
When having lots of systems, lots of resources, and lots of systems running it is
never easy to manage them. When there needs to be a software update, a
replacement, or maintenance that all of the system needs to do, it will be time
consuming and resource consuming.
MindMap Parallel DBMS

What is a parallel database system, and how does it differ from a traditional database
system?

What is load balancing, and how is it used in parallel database systems?

What are the different techniques used for fault tolerance in parallel database systems?

What is query parallelism, and how is it used in parallel database systems?

Explain Parallel architectures

Explain parallel query processing and optimization

Explain load balancing in parallel database system

Define Mobile databases and Multi-databases

A Mobile database is a database that can be connected to a mobile computing device over
a mobile network (or wireless network). Here the client and the server have wireless
connections. In today’s world, mobile computing is growing very rapidly, and it is huge
potential in the field of the database. It will be applicable on different-different devices
like android based mobile databases, iOS based mobile databases, etc. Common examples
of databases are Couch base Lite, Object Box, etc.

Features of Mobile database :

Here, we will discuss the features of the mobile database as follows.
 A cache is maintained to hold frequent and transactions so that they are not lost
due to connection failure.
 As the use of laptops, mobile and PDAs is increasing to reside in the mobile
system.
 Mobile databases are physically separate from the central database server.
 Mobile databases resided on mobile devices.
 Mobile databases are capable of communicating with a central database server
or other mobile clients from remote sites.
 With the help of a mobile database, mobile users must be able to work without a
wireless connection due to poor or even non-existent connections
(disconnected).
 A mobile database is used to analyze and manipulate data on mobile devices.
Mobile Database typically involves three parties :
1. Fixed Hosts –
It performs the transactions and data management functions with the help of
database servers.

2. Mobiles Units –
These are portable computers that move around a geographical region that
includes the cellular network that these units use to communicate to base
 stations.

3. Base Stations –
These are two-way radios installation in fixed locations, that pass
communication with the mobile units to and from the fixed hosts.
Limitations :
Here, we will discuss the limitation of mobile databases as follows.
 It has Limited wireless bandwidth.
 In the mobile database, Wireless communication speed.
 It required Unlimited battery power to access.
 It is Less secured.
 It is Hard to make theft-proof.

Multi-database Systems

A multi-model database is a management system that combines multiple database

types with a single backend. Most database management systems support only a single
database model. On the other hand, multi-model databases store, query, and index data
from different models.

Multi-model databases provide the modeling advantages of polyglot persistence without

having to find ways to combine different models. The flexible approach allows storing data
in different ways. The result is:

 Agile and flexible programming.

 Reduced data redundancy.

Storing and Managing Multiple Data Sources

A typical IT system uses various data sources. The stored information is not always in the
same format or database. Multiple formats create a complex system, making it hard to
maintain and search through data.

Storing data in a multi-model database makes administration easier. Everything is in one

database, which reduces the time needed to store and manage data from different sources.

Extending Model Features

Multi-model databases provide extensions between models. Features from some models
help supplement the shortcomings of other models.

For example, querying data in JSON format using SQL queries is simple. There is no need to
adjust the original data source. Extensibility reduces data processing time and eliminates
the need for extract, transform and load (ETL) systems.
Hybrid Data Environments

A typical data environment keeps operational data separate from analytical. The data for
analysis must be transformed and stored in a different place from the operational data.

The information duplicates, decreasing data quality. Likewise, the separated space creates
maintenance overhead. Both databases need policy administration as well as backup
management.

A multi-model database provides a hybrid approach to data storage. A unified data hub for
storing transactional and extracting analytical data is simpler to maintain.

Data Centralization

Data within an organization has barriers. While restrictions must exist, this approach
prevents utilizing information within a company.

Multi-model databases store data as-is without the need for transformations. Data
centralization provides valuable insight into existing data, as well as the opportunity for
creating new use-cases.

Searching Big Data

Hadoop is exceptional at processing large amounts of diverse data across different models.
The main reason is the speed of receiving, processing, and storing various data. However,
the one thing Hadoop lacks is an efficient search mechanism.

Taking advantage of the Hadoop processing power and combining it with the strength of
multi-model database searches produces a robust system. The process of working with data
becomes scalable and sturdy for big data tasks.

Multi-Model Database Advantages and Disadvantages

Multi-model databases come with benefits and drawbacks. The table provides the
summary:

Pros Cons
Data consistent Complex
Agile Developing
ACID compliant Lacks modeling techniques
Suitable for complex projects Not suitable for simple projects

The database model primarily works in corporate settings where a lot of data is present.
Different sectors use the data for various tasks. However, an already established and
specialized polyglot persistence structure will notice the lack of features in multi-model
databases.
Note: Consider using DBaaS for simplified database management. Learn about DBaaS in our
blog article: What is Database-as-a-Service (DBaaS)?
Advantages

The advantages of using multi-model databases are:

 Inter-model data consistency due to a single backend.

 Different data types on one platform provides an agile environment.
 Fault-tolerant due to ACID compliance.
 Suitable for complex projects which require multiple views of data.

Disadvantages

Some disadvantages of using multi-model databases are:

 Multi-model database systems are challenging to work with and complicated.

 The database model is still developing and has not matured properly.
 There is limited availability of different modeling techniques.
 Not suitable for simpler systems or projects.

****************************************
***
What is data fragmentation
Data fragmentation is a process of dividing large data sets into smaller and more
manageable parts. Each smaller piece of data is known as a fragment or shard, and these
smaller parts allow for efficient storage and retrieval of large amounts of data.

List out different layers of query processing

1. Query Decomposition
2. Data Localization
3. Global Query Optimization
4. Local Query Optimization

Define Replication?
What do you mean by data allocation?

Define Data security

Abbreviate ACID properties?

Define Deadlock?

Write the use of Commit protocols

Write the use of Recovery protocols

Define Distributed Object Management?

Define Mobile Databases?

Define distributed systems

Distributed System is a collection of autonomous computer systems that are physically
separated but are connected by a centralized computer network that is equipped with
distributed system software. The autonomous computers will communicate among each
system by sharing resources and files and performing the tasks assigned to them.
Types of Distributed Systems:
There are many models and architectures of distributed systems in use today.
 Client-server systems, the most traditional and simple type of distributed system,
involve a multitude of networked computers that interact with a central server for
data storage, processing or other common goal.
  Peer-to-peer networks distribute workloads among hundreds or thousands of
computers all running the same software.
 Cell phone networks are an advanced distributed system, sharing workloads among
handsets, switching systems and internet-based devices.

List out methods used for designing and implementing DDBMS

When designing and managing a distributed database system, there are various approaches
and techniques to consider, depending on the specific characteristics and needs of your
application.
Horizontal partitioning can improve scalability, performance, and availability, but also
increase complexity of data processing.
Vertical partitioning can reduce storage space and network traffic, but require more joins
and data transfers.
Fragmentation and allocation combines horizontal and vertical partitioning to optimize data
distribution and access, while increasing data management overhead.
Replication creates copies of data stored in different nodes or databases, but can create
consistency and concurrency issues.

List out concurrency control in centralized database systems

Various concurrency control techniques are:
1. Two-phase locking Protocol
2. Time stamp ordering Protocol
3. Multi version concurrency control
4. Validation concurrency control

Define deadlock management

Deadlock is a state of a database system having two or more transactions, when each
transaction is waiting for a data item that is being locked by some other transaction. A
deadlock can be indicated by a cycle in the wait-for-graph. This is a directed graph in which
the vertices denote transactions and the edges denote waits for data items.

There are three classical approaches for deadlock handling, namely −

 Deadlock prevention.
 Deadlock avoidance.
 Deadlock detection and removal.
Define concurrency control
Concurrency Control is a crucial Database Management System (DBMS) component. It
manages simultaneous operations without them conflicting with each other. The primary
aim is maintaining consistency, integrity, and isolation when multiple users or applications
access the database simultaneously.
In a multi-user database environment, it’s common for numerous users to want to access
and modify the database simultaneously. This is what we call concurrent execution.
Imagine a busy library where multiple librarians are updating book records simultaneously.
Just as multiple librarians shouldn’t try to update the same record simultaneously, database
users shouldn’t interfere with each other’s operations.
Executing transactions concurrently offers many benefits, like improved system resource
utilization and increased throughput. However, these simultaneous transactions mustn’t
interfere with each other. The ultimate goal is to ensure the database remains consistent
and correct. For instance, if two people try to book the last seat on a flight at the exact
moment, the system must ensure that only one person gets the seat.
But concurrent execution can lead to various challenges:
 Lost Updates: Consider two users trying to update the same data. If one user reads a
data item and then another user reads the same item and updates it, the first user’s
updates could be lost if they weren’t aware of the second user’s actions.
 Uncommitted Data: If one user accesses data that another user has updated but not
yet committed (finalized), and then the second user decides to abort (cancel) their
transaction, the first user has invalid data.
 Inconsistent Retrievals: A transaction reads several values from the database, but
another transaction modifies some of those values in the middle of its operation.

Define designing in DDBMS

Database Design can be defined as a set of procedures or collection of tasks involving
various steps taken to implement a database. Following are some critical points to keep in
mind to achieve a good database design:
1. Data consistency and integrity must be maintained.
2. Low Redundancy
3. Faster searching through indices
4. Security measures should be taken by enforcing various integrity constraints.
5. Data should be stored in fragmented bits of information in the most atomic format
possible.

Define centralized database systems

Centralized database management system is the system in which all the data is stored and
managed in a single unit. This is also known as central computer database system. This
system is mostly used in an organization, in any Business Company or in institution to
centralize the tasks. Data can be accessed through a network Local Area Network (LAN) or
Wide Area Network (WAN). Mainframe computer is the example of centralized database
management system.

What is a Federated Database Management System?

A Federated Database Management System (FDBMS) is a type of distributed database
management system that allows users to access and manipulate data stored in multiple
databases. It is a system that integrates data from different sources, providing a single
view of the data to users. This type of system is useful in situations where data is
distributed across multiple autonomous databases, and there is a need to access and
analyze the data in a unified way. A system in which each server is an autonomous and
centralized DBMS that has its own local users. The term Federated Database system or in
short FDS is basically used when there is some global view or schema of the Federation of
the database which is basically shared by the applications. These systems are a hybrid
between distributed and centralized systems.

Define semantics data control

Semantic integrity control defines and enforces the integrity constraints of the database
system.

The integrity constraints are as follows −

 Data type integrity constraint
 Entity integrity constraint
 Referential integrity constraint

Discuss about centralized database systems

A centralized database is basically a type of database that is stored, located as well as
maintained at a single location only. This type of database is modified and managed from
that location itself. This location is thus mainly any database system or a centralized
computer system. The centralized location is accessed via an internet connection (LAN,
WAN, etc). This centralized database is mainly used by institutions or organizations.
Define DDBS
A distributed database is basically a database that is not limited to one system, it is spread
over different sites, i.e, on multiple computers or over a network of computers. A
distributed database system is located on various sites that don’t share physical
components. This may be required when a particular database needs to be accessed by
various users globally. It needs to be managed such that for the users it looks like one
single database.
Types:
1. Homogeneous Database:

2. Heterogeneous Database:

Define Spatial Database

Spatial data is associated with geographic locations such as cities,towns etc. A spatial
database is optimized to store and query data representing objects. These are the objects
which are defined in a geometric space.
Characteristics of Spatial Database
A spatial database system has the following characteristics
 It is a database system
 It offers spatial data types (SDTs) in its data model and query language.
 It supports spatial data types in its implementation, providing at least spatial indexing
and efficient algorithms for spatial join.

Define Web Database

A web database is essentially a database that can be accessed from a local network or the
internet instead of one that has its data stored on a desktop or its attached storage. Used
for both professional and personal use, they are hosted on websites and are software as
service (SaaS) products, which means that access is provided via a web browser.

What is distributed object

A distributed object is an object that can be accessed remotely. This means that a
distributed object can be used like a regular object, but from anywhere on the network. An
object is typically considered to encapsulate data and behavior. The location of the
distributed object is not critical to the user of the object. A distributed object might provide
its user with a set of related capabilities. The application that provides a set of capabilities is
often referred to as a service. A Business Object might be a local object or a distributed
object. The term business object refers to an object that performs a set of tasks associated
with a particular business process.
Explain parallel database systems
A parallel database system seeks to improve performance through parallelization of various
operations, such as loading data, building indexes and evaluating queries. Although data
may be stored in a distributed fashion, the distribution is governed solely by performance
considerations. Parallel databases improve processing and input/output speeds by using
multiple CPUs and disks in parallel.

List reliability techniques used in DDBS

 Reliability techniques consist of commit, termination, and recovery protocols
 Commit and recover commands executed differently in a distributed DBMS than centralized
 Termination protocols are unique to distributed systems
 Termination vs. recovery protocols
o Opposite faces of recovery problem
o Given a site failure, termination protocols address how the operational sites deal with the
failure
o Recovery protocols address procedure the process at the failed site must go through to
recover its state
 Commit protocols must maintain atomicity of distributed transactions
 Ideally recovery protocols are independent – no need to consult other sites to terminate transaction

Mention 2 differences between spatial database and web database

Mention 2 differences between centralized database systems and

DDBS
Difference between Centralized database and Distributed database:

[Link] Basis of Centralized database Distributed database

. Comparison
1. Definition It is a database that is stored, It is a database that consists of multiple
located as well as maintained at a databases which are connected with each
single location only. other and are spread across different
physical locations.
2. Access time The data access time in the case of The data access time in the case of
multiple users is more in a multiple users is less in a distributed
centralized database. database.
3. Management The management, modification, The management, modification, and
of data and backup of this database are backup of this database are very difficult
easier as the entire data is present as it is spread across different physical
at the same location. locations.
4. View This database provides a uniform Since it is spread across different
and complete view to the user. locations thus it is difficult to provide a
 uniform view to the user.
5. Data This database has more data This database may have some data
Consistency consistency in comparison to replications thus data consistency is less.
distributed database.
6. Failure The users cannot access the In a distributed database, if one database
database in case of database failure fails users have access to other databases.
occurs.
7. Cost A centralized database is less costly. This database is very expensive.
8. Maintenance Ease of maintenance because the It is difficult to maintain because of the
whole of the data and information distribution of data and information at
is available at a single location and varied places. So, there is a need to check
thus, easy to reach and access. for data redundancy issues and how to
maintain data consistency.
9. Efficient A centralized database is less A distributed database is more efficient
efficient as data finding becomes than a centralized database because of
quite complex because of the the splitting up of data at several places
storing of data and information at a which makes data finding simple and less
particular place. time-consuming.
10. Response The response speed is more in The response speed is less in comparison
Speed comparison to a distributed to a centralized database.
database.
11. Advantages  Integrity of data  High performance because of the
 Security division of workload.
 Easy access to all  High availability because of the
information readiness of available nodes to do
 Data is easily portable work.
 Independent nodes and better
control over resources
12. Disadvantages  Data searching takes time  It is quite large and complex so
 In case of failure of a difficult to use and maintain.
centralized server, the  Difficult to provide security
whole database will be lost.  Issue of data integrity
 If multiple users try to  Increase in storage and
access the data at the same infrastructure requirements
time then it may create  Handling failures is a quite difficult
issues. task
13. Examples  A desktop or server CPU  Apache Ignite
 A mainframe computer.  Apache Cassandra
 Apache HBase
 Amazon SimpleDB
 Clusterpoint
 FoundationDB.