1. UNIT - 4
Transaction Processing Concept:
By: Ms. SWETA SINGH
Assistant Professor(CSE)

2. Transaction
• The transaction is a set of logically related operation. It contains a group of tasks.
• A transaction is an action or series of actions. It is performed by a single user to perform
operations for accessing the contents of the database.
• Example: Suppose an employee of bank transfers Rs 800 from X's account to Y's account. This small
transaction contains several low-level tasks:
X's Account
Open_Account(X)
Old_Balance = X.balance
New_Balance = Old_Balance - 800
X.balance = New_Balance
Close_Account(X)
Y's Account
Open_Account(Y)
Old_Balance = Y.balance
New_Balance = Old_Balance + 800
Y.balance = New_Balance
Close_Account(Y)

3. Operations of Transaction:
• Following are the main operations of transaction:
• Read(X): Read operation is used to read the value of X from the database and stores it in a buffer in
main memory.
• Write(X): Write operation is used to write the value back to the database from the buffer.
• Let's take an example to debit transaction from an account which consists of following operations:
• 1. R(X);
• 2. X = X - 500;
• 3. W(X);
• Let's assume the value of X before starting of the transaction is 4000.
• The first operation reads X's value from database and stores it in a buffer.
• The second operation will decrease the value of X by 500. So buffer will contain 3500.
• The third operation will write the buffer's value to the database. So X's final value will be 3500.
• But it may be possible that because of the failure of hardware, software or power, etc. that
transaction may fail before finished all the operations in the set.
• For example: If in the above transaction, the debit transaction fails after executing operation 2 then
X's value will remain 4000 in the database which is not acceptable by the bank.
• To solve this problem, we have two important operations:
• Commit: It is used to save the work done permanently.
• Rollback: It is used to undo the work done.

4. Transaction property(ACID)
• The transaction has the four properties. These
are used to maintain consistency in a
database, before and after the transaction.
• Property of Transaction
• Atomicity
• Consistency
• Isolation
• Durability

5. Atomicity
• It states that all operations of the transaction take
place at once if not, the transaction is aborted.
• There is no midway, i.e., the transaction cannot
occur partially. Each transaction is treated as one
unit and either run to completion or is not
executed at all.
• Atomicity involves the following two operations:
• Abort: If a transaction aborts then all the changes
made are not visible.
• Commit: If a transaction commits then all the
changes made are visible.

6. Consistency
• The integrity constraints are maintained so that the database is consistent
before and after the transaction.
• The execution of a transaction will leave a database in either its prior
stable state or a new stable state.
• The consistent property of database states that every transaction sees a
consistent database instance.
• The transaction is used to transform the database from one consistent
state to another consistent state.
• For example: The total amount must be maintained before or after the
transaction.
• Total before T occurs = 600+300=900
• Total after T occurs= 500+400=900
• Therefore, the database is consistent. In the case when T1 is completed
but T2 fails, then inconsistency will occur.

7. Isolation
• It shows that the data which is used at the time
of execution of a transaction cannot be used by
the second transaction until the first one is
completed.
• In isolation, if the transaction T1 is being
executed and using the data item X, then that
data item can't be accessed by any other
transaction T2 until the transaction T1 ends.
• The concurrency control subsystem of the DBMS
enforced the isolation property.

8. Durability
• The durability property is used to indicate the
performance of the database's consistent state. It
states that the transaction made the permanent
changes.
• They cannot be lost by the erroneous operation of a
faulty transaction or by the system failure. When a
transaction is completed, then the database reaches a
state known as the consistent state. That consistent
state cannot be lost, even in the event of a system's
failure.
• The recovery subsystem of the DBMS has the
responsibility of Durability property.

9. States of Transaction
In a database, the transaction can be in one of the following states -

10. Active state
• The active state is the first state of every transaction. In this state, the transaction is being executed.
• For example: Insertion or deletion or updating a record is done here. But all the records are still not saved
to the database.
Partially committed
• In the partially committed state, a transaction executes its final operation, but the data is still not saved to
the database.
• In the total mark calculation example, a final display of the total marks step is executed in this state.
Committed
• A transaction is said to be in a committed state if it executes all its operations successfully. In this state, all
the effects are now permanently saved on the database system.
• Failed state
• If any of the checks made by the database recovery system fails, then the transaction is said to be in the
failed state.
• In the example of total mark calculation, if the database is not able to fire a query to fetch the marks, then
the transaction will fail to execute.
Aborted
• If any of the checks fail and the transaction has reached a failed state then the database recovery system
will make sure that the database is in its previous consistent state. If not then it will abort or roll back the
transaction to bring the database into a consistent state.
• If the transaction fails in the middle of the transaction then before executing the transaction, all the
executed transactions are rolled back to its consistent state.
• After aborting the transaction, the database recovery module will select one of the two operations:
– Re-start the transaction
– Kill the transaction

11. Schedule
• A series of operation from one transaction to
another transaction is known as schedule. It is
used to preserve the order of the operation in
each of the individual transaction.

12. Schedule Types

13. Schedule Types
1. Serial Schedule
• The serial schedule is a type of schedule where one transaction is executed completely before
starting another transaction. In the serial schedule, when the first transaction completes its cycle,
then the next transaction is executed.
• For example: Suppose there are two transactions T1 and T2 which have some operations. If it has
no interleaving of operations, then there are the following two possible outcomes:
• Execute all the operations of T1 which was followed by all the operations of T2.
• Execute all the operations of T1 which was followed by all the operations of T2.
• In the given (a) figure, Schedule A shows the serial schedule where T1 followed by T2.
• In the given (b) figure, Schedule B shows the serial schedule where T2 followed by T1.
2. Non-serial Schedule
• If interleaving of operations is allowed, then there will be non-serial schedule.
• It contains many possible orders in which the system can execute the individual operations of the
transactions.
• In the given figure (c) and (d), Schedule C and Schedule D are the non-serial schedules. It has
interleaving of operations.

14. 3. Serializable schedule
• The serializability of schedules is used to find
non-serial schedules that allow the transaction to
execute concurrently without interfering with one
another.
• It identifies which schedules are correct when
executions of the transaction have interleaving of
their operations.
• A non-serial schedule will be serializable if its
result is equal to the result of its transactions
executed serially.

15. Here,
Schedule A and Schedule B are serial schedule.
Schedule C and Schedule D are Non-serial schedule.

16. Here,
Schedule A and Schedule B are serial schedule.
Schedule C and Schedule D are Non-serial schedule.

17. Serial Schedules Vs Serializable Schedules-
Serial Schedules
• No concurrency is allowed.
• Thus, all the transactions necessarily execute
serially one after the other.
• Serial schedules lead to less resource
utilization and CPU throughput.
• Serial Schedules are less efficient as compared
to serializable schedules.

18. Serializable Schedules
• Concurrency is allowed.
• Thus, multiple transactions can execute
concurrently.
• Serializable schedules improve both resource
utilization and CPU throughput.
• Serializable Schedules are always better than
serial schedules.

19. Testing of Serializability
• Serialization Graph is used to test the Serializability of a schedule.
• Assume a schedule S. For S, we construct a graph known as
precedence graph. This graph has a pair G = (V, E), where V consists
a set of vertices, and E consists a set of edges. The set of vertices is
used to contain all the transactions participating in the schedule.
The set of edges is used to contain all edges Ti ->Tj for which one of
the three conditions holds:
• Create a node Ti → Tj if Ti executes write (Q) before Tj executes
read (Q).
• Create a node Ti → Tj if Ti executes read (Q) before Tj executes
write (Q).
• Create a node Ti → Tj if Ti executes write (Q) before Tj executes
write (Q).

20. •If a precedence graph contains a single edge Ti → Tj, then all the instructions of Ti
are executed before the first instruction of Tj is executed.
•If a precedence graph for schedule S contains a cycle, then S is non-serializable. If
the precedence graph has no cycle, then S is known as serializable.
For example:

22. • Explanation:
• Read(A): In T1, no subsequent writes to A, so no new edges
Read(B): In T2, no subsequent writes to B, so no new edges
Read(C): In T3, no subsequent writes to C, so no new edges
Write(B): B is subsequently read by T3, so add edge T2 →
T3
Write(C): C is subsequently read by T1, so add edge T3 →
T1
Write(A): A is subsequently read by T2, so add edge T1 →
T2
Write(A): In T2, no subsequent reads to A, so no new edges
Write(C): In T1, no subsequent reads to C, so no new edges
Write(B): In T3, no subsequent reads to B, so no new edges

23. CONFLICT SERIALIZABILITY-
If a given non-serial schedule can be converted into a
serial schedule by swapping its non-conflicting
operations, then it is called as a conflict serializable
schedule.
• Conflicting Operations-
• Two operations are called as conflicting operations if
all the following conditions hold true for them-
• Both the operations belong to different transactions
• Both the operations are on the same data item
• At least one of the two operations is a write operation

24. Example-
• Consider the following schedule-
In this schedule,
W1 (A) and R2 (A) are called as conflicting operations.
This is because all the above conditions hold true for them.

25. Checking Whether a Schedule is Conflict Serializable Or
Not-
• Follow the following steps to check whether a given non-serial schedule is conflict serializable or
not-
• Step-01:
• Find and list all the conflicting operations.
• Step-02:
• Start creating a precedence graph by drawing one node for each transaction.
• Step-03:
• Draw an edge for each conflict pair such that if Xi (V) and Yj (V) forms a conflict pair then draw an
edge from Ti to Tj.
• This ensures that Ti gets executed before Tj.
• Step-04:
• Check if there is any cycle formed in the graph.
• If there is no cycle found, then the schedule is conflict serializable otherwise not.
• NOTE-
• By performing the Topological Sort of the Directed Acyclic Graph so obtained, the corresponding
serial schedule(s) can be found.
• Such schedules can be more than 1.
• “If the graph contains no cycle then the schedule S is conflict serializable.”

26. PRACTICE PROBLEMS BASED ON CONFLICT SERIALIZABILITY-
Problem-01:
• Check whether the given schedule S is conflict serializable or not-
• S : R1(A) , R2(A) , R1(B) , R2(B) , R3(B) , W1(A) , W2(B)
Solution-
Step-01:
• List all the conflicting operations and determine the dependency
between the transactions-
• R2(A) , W1(A) (T2 → T1)
• R1(B) , W2(B) (T1 → T2)
• R3(B) , W2(B) (T3 → T2)
Step-02:
• Draw the precedence graph-
•Clearly, there exists a cycle in the precedence graph.
•Therefore, the given schedule S is not conflict serializable.

27. Problem-02:
Check whether the given schedule S is conflict serializable and recoverable or not-
Solution-
Checking Whether S is Conflict Serializable Or Not-
Step-01:
List all the conflicting operations and determine the dependency between the transactions-
•R2(X) , W3(X) (T2 → T3)
•R2(X) , W1(X) (T2 → T1)
•W3(X) , W1(X) (T3 → T1)
•W3(X) , R4(X) (T3 → T4)
•W1(X) , R4(X) (T1 → T4)
•W2(Y) , R4(Y) (T2 → T4)
Step-02:
Draw the precedence graph-

28. Problem-02:
Checking Whether S is Recoverable Or Not-
• Conflict serializable schedules are always
recoverable.
• Therefore, the given schedule S is recoverable.
• Alternatively,
• There exists no dirty read operation.
• This is because all the transactions which update
the values commits immediately.
• Therefore, the given schedule S is recoverable.
• Also, S is a Cascadeless Schedule.

29. View Serializability in DBMS
• If a given schedule is found to be view equivalent to some serial schedule, then it is called as a view
serializable schedule.
• Non serial schedule -> Serial schedule -> 123,132,213,231,312,321 we have to check all sequence
View Equivalent Schedules-
• Consider two schedules S1 and S2 each consisting of two transactions T1 and T2.
• Schedules S1 and S2 are called view equivalent if the following three conditions hold true for them-
Condition-01:
• For each data item X, if transaction Ti reads X from the database initially in schedule S1, then in schedule
S2 also, Ti must perform the initial read of X from the database.
• Thumb Rule “Initial readers must be same for all the data items”.
Condition-02:
• If transaction Ti reads a data item that has been updated by the transaction Tj in schedule S1, then in
schedule S2 also, transaction Ti must read the same data item that has been updated by the transaction Tj.
• Thumb Rule “Write-read sequence must be same.”.
Condition-03:
• For each data item X, if X has been updated at last by transaction Ti in schedule S1, then in schedule S2
also, X must be updated at last by transaction Ti.
• Thumb Rule “Final writers must be same for all the data items”.

30. Checking Whether a Schedule is View Serializable Or Not-
Method-01:
• Check whether the given schedule is conflict serializable or not.
• If the given schedule is conflict serializable, then it is surely view serializable. Stop and report your answer.
• If the given schedule is not conflict serializable, then it may or may not be view serializable. Go and check using
other methods.
• Thumb Rules
• All conflict serializable schedules are view serializable.
• All view serializable schedules may or may not be conflict serializable.
Method-02:
• Check if there exists any blind write operation.
• (Writing without reading is called as a blind write).
• If there does not exist any blind write, then the schedule is surely not view serializable. Stop and report your
answer.
• If there exists any blind write, then the schedule may or may not be view serializable. Go and check using other
methods.
• Thumb Rule No blind write means not a view serializable schedule.
Method-03:
• In this method, try finding a view equivalent serial schedule.
• By using the above three conditions, write all the dependencies.
• Then, draw a graph using those dependencies.
• If there exists no cycle in the graph, then the schedule is view serializable otherwise not.

31. PRACTICE PROBLEMS BASED ON VIEW SERIALIZABILITY-
• Problem-01:
• Check whether the given schedule S is view serializable or not-
Solution-
•We know, if a schedule is conflict serializable, then it is surely view serializable.
•So, let us check whether the given schedule is conflict serializable or not.
Checking Whether S is Conflict Serializable Or Not-
Step-01:
List all the conflicting operations and determine the dependency between the
transactions-
•W1(B) , W2(B) (T1 → T2)
•W1(B) , W3(B) (T1 → T3)
•W1(B) , W4(B) (T1 → T4)
•W2(B) , W3(B) (T2 → T3)
•W2(B) , W4(B) (T2 → T4)
•W3(B) , W4(B) (T3 → T4)
Step-02: Draw the precedence graph-

32. PRACTICE PROBLEMS BASED ON VIEW
SERIALIZABILITY-
•Clearly, there exists no cycle in the precedence graph.
•Therefore, the given schedule S is conflict serializable.
Thus, we conclude that the given schedule is also view serializable.

34. Non-Serializable Schedules-
• A non-serial schedule which is not serializable is called as a non-serializable schedule.
• A non-serializable schedule is not guaranteed to produce the the same effect as produced by some serial schedule
on any consistent database.
•
• Characteristics-
•
• Non-serializable schedules-
• may or may not be consistent
• may or may not be recoverable
•
• Irrecoverable Schedules-
•
• If in a schedule,
• A transaction performs a dirty read operation from an uncommitted transaction
• And commits before the transaction from which it has read the value
• then such a schedule is known as an Irrecoverable Schedule.
•
• Example-
•
• Consider the following schedule-

35. Here,
•T2 performs a dirty read operation.
•T2 commits before T1.
•T1 fails later and roll backs.
•The value that T2 read now stands to be incorrect.
•T2 can not recover since it has already committed.

36. Recoverable Schedules-
• If in a schedule,
• A transaction performs a dirty read operation
from an uncommitted transaction
• And its commit operation is delayed till the
uncommitted transaction either commits or roll
backs then such a schedule is known as
a Recoverable Schedule.
• Here,The commit operation of the transaction
that performs the dirty read is delayed.
• This ensures that it still has a chance to recover if
the uncommitted transaction fails later.

37. • Example 1-
• Consider the following schedule-
Here,
•T2 performs a dirty read operation.
•The commit operation of T2 is delayed
till T1 commits or roll backs.
•T1 commits later.
•T2 is now allowed to commit.
•In case, T1 would have failed, T2 has a
chance to recover by rolling back.

38. Types of Recoverable Schedules-
• A recoverable schedule may be any one of
these kinds-

39. Cascading Schedule-
• If in a schedule, failure of one transaction causes several other
dependent transactions to rollback or abort, then such a
schedule is called as a Cascading Schedule or Cascading
Rollback or Cascading Abort.
• It simply leads to the wastage of CPU time.
Here,
•Transaction T2 depends on transaction T1.
•Transaction T3 depends on transaction T2.
•Transaction T4 depends on transaction T3.
In this schedule,
•The failure of transaction T1 causes the transaction T2
to rollback.
•The rollback of transaction T2 causes the transaction
T3 to rollback.
•The rollback of transaction T3 causes the transaction
T4 to rollback.
Such a rollback is called as a Cascading
Rollback.

40. Cascading Schedule-
• NOTE-
• If the transactions T2, T3 and T4 would have
committed before the failure of transaction
T1, then the schedule would have been
irrecoverable.

41. Cascadeless Schedule-
• If in a schedule, a transaction is not allowed to
read a data item until the last transaction that
has written it is committed or aborted, then such
a schedule is called as a Cascadeless Schedule.
• In other words,Cascadeless schedule allows only
committed read operations.
• Therefore, it avoids cascading roll back and thus
saves CPU time.
• Example-

42. NOTE-
•Cascadeless schedule allows only committed read operations.
•However, it allows uncommitted write operations.
Example-

43. Strict Schedule-
• If in a schedule, a transaction is neither allowed to read nor write a data
item until the last transaction that has written it is committed or aborted,
then such a schedule is called as a Strict Schedule.
• In other words,Strict schedule allows only committed read and write
operations.
• Clearly, strict schedule implements more restrictions than cascadeless
schedule.
• Example-
.
Remember-
•Strict schedules are more strict than
cascadeless schedules.
•All strict schedules are cascadeless
schedules.
•All cascadeless schedules are not
strict schedules

44. Deadlock
• Deadlock is a situation where-
• The execution of two or more processes is blocked because each process
holds some resource and waits for another resource held by some other
process.
• Example-
Here
•Process P1 holds resource R1 and waits for resource R2 which
is held by process P2.
•Process P2 holds resource R2 and waits for resource R1 which
is held by process P1.
•None of the two processes can complete and release their
resource.
•Thus, both the processes keep waiting infinitely.

45. Conditions For Deadlock-
• There are following 4 necessary conditions for the occurrence of
deadlock-
• Mutual Exclusion
• Hold and Wait
• No preemption
• Circular wait
• 1. Mutual Exclusion-
• By this condition,
• There must exist at least one resource in the system which can be
used by only one process at a time.
• If there exists no such resource, then deadlock will never occur.
• Printer is an example of a resource that can be used by only one
process at a time.

46. Conditions For Deadlock-
• 2. Hold and Wait-
• By this condition,
• There must exist a process which holds some resource and waits for
another resource held by some other process.
• 3. No Preemption-
• By this condition,
• Once the resource has been allocated to the process, it can not be
preempted.
• It means resource can not be snatched forcefully from one process and
given to the other process.
• The process must release the resource voluntarily by itself.
• 4. Circular Wait-
• By this condition,
• All the processes must wait for the resource in a cyclic manner where the
last process waits for the resource held by the first process.

47. Conditions For Deadlock-
Here,
•Process P1 waits for a resource held by
process P2.
•Process P2 waits for a resource held by
process P3.
•Process P3 waits for a resource held by
process P4.
•Process P4 waits for a resource held by
process P1.
Important Note-
•All these 4 conditions must hold simultaneously for the occurrence of
deadlock.
•If any of these conditions fail, then the system can be ensured deadlock
free.

48. Deadlock Handling-
• The various strategies for handling deadlock
are-

49. Deadlock Handling-
• Deadlock Prevention-
• This strategy involves designing a system that violates one of the
four necessary conditions required for the occurrence of deadlock.
• This ensures that the system remains free from the deadlock.
• The various conditions of deadlock occurrence may be violated as-
• 1. Mutual Exclusion-
• To violate this condition, all the system resources must be such that
they can be used in a shareable mode.
• In a system, there are always some resources which are mutually
exclusive by nature.
• So, this condition can not be violated.

50. Deadlock Handling-
• 2. Hold and Wait-
• This condition can be violated in the following ways-
• Approach-01:
• In this approach,
• A process has to first request for all the resources it requires for execution.
• Once it has acquired all the resources, only then it can start its execution.
• This approach ensures that the process does not hold some resources and wait for other resources.
• Drawbacks-
• The drawbacks of this approach are-
• It is less efficient.
• It is not implementable since it is not possible to predict in advance which resources will be required
during execution.
• Approach-02:
• In this approach,
• A process is allowed to acquire the resources it desires at the current moment.
• After acquiring the resources, it start its execution.
• Now before making any new request, it has to compulsorily release all the resources that it holds
currently.
• This approach is efficient and implementable.
• Approach-03:
• In this approach,
• A timer is set after the process acquires any resource.
• After the timer expires, a process has to compulsorily release the resource.

51. Deadlock Handling-
• 3. No Preemption-
• This condition can by violated by forceful preemption.
• Consider a process is holding some resources and request other resources that can not be
immediately allocated to it.
• Then, by forcefully preempting the currently held resources, the condition can be violated.
• 4. Circular Wait-
• This condition can be violated by not allowing the processes to wait for resources in a cyclic
manner.To violate this condition, the following approach is followed-
• Approach-
• A natural number is assigned to every resource.
• Each process is allowed to request for the resources either in only increasing or only
decreasing order of the resource number.
• In case increasing order is followed, if a process requires a lesser number resource, then it
must release all the resources having larger number and vice versa.
• This approach is the most practical approach and implementable.
• However, this approach may cause starvation but will never lead to deadlock.

52. Deadlock Handling-
• Deadlock Avoidance-
• This strategy involves maintaining a set of data using which a decision is made whether to entertain the
new request or not.
• If entertaining the new request causes the system to move in an unsafe state, then it is discarded.
• This strategy requires that every process declares its maximum requirement of each resource type in the
beginning.
• The main challenge with this approach is predicting the requirement of the processes before execution.
• Banker’s Algorithm is an example of a deadlock avoidance strategy.
•
• Deadlock Detection and Recovery-
• This strategy involves waiting until a deadlock occurs.
• After deadlock occurs, the system state is recovered.
• The main challenge with this approach is detecting the deadlock.
•
• Deadlock Ignorance-
• This strategy involves ignoring the concept of deadlock and assuming as if it does not exist.
• This strategy helps to avoid the extra overhead of handling deadlock.
• Windows and Linux use this strategy and it is the most widely used method.
• It is also called as Ostrich approach.

53. Log-Based Recovery
• The log is a sequence of records. Log of each transaction is maintained in some stable storage so that if any failure occurs,
then it can be recovered from there.
• If any operation is performed on the database, then it will be recorded in the log.
• But the process of storing the logs should be done before the actual transaction is applied in the database.
• Let's assume there is a transaction to modify the City of a student. The following logs are written for this transaction.
• When the transaction is initiated, then it writes 'start' log.
– <Tn, Start>
• When the transaction modifies the City from 'Noida' to 'Bangalore', then another log is written to the file.
– <Tn, City, 'Noida', 'Bangalore' >
• When the transaction is finished, then it writes another log to indicate the end of the transaction.
– <Tn, Commit>
• There are two approaches to modify the database:
• 1. Deferred database modification:
• The deferred modification technique occurs if the transaction does not modify the database until it has committed.
• In this method, all the logs are created and stored in the stable storage, and the database is updated when a transaction
commits.
• 2. Immediate database modification:
• The Immediate modification technique occurs if database modification occurs while the transaction is still active.
• In this technique, the database is modified immediately after every operation. It follows an actual database modification.
• Recovery using Log records
• When the system is crashed, then the system consults the log to find which transactions need to be undone and which need
to be redone.
• If the log contains the record <Ti, Start> and <Ti, Commit> or <Ti, Commit>, then the Transaction Ti needs to be redone.
• If log contains record<Tn, Start> but does not contain the record either <Ti, commit> or <Ti, abort>, then the Transaction Ti
needs to be undone.

54. What is a Distributed Database System?
• A distributed database (DDB) is a collection of multiple, logically interrelated
databases distributed over a computer network.
• A distributed database management system (D–DBMS) is the software that
manages the DDB and provides an access mechanism that makes this distribution
transparent to the users.
• Distributed database system (DDBS) = DDB + D–DBMS
•The above diagram is a typical example of distributed database
system, in which communication channel is used to communicate
with the different locations and every system has its own memory
and database.

55. Goals of Distributed Database system.
• The concept of distributed database was built with a goal to improve:
Reliability: In distributed database system, if one system fails down or
stops working for some time another system can complete the task.
Availability: In distributed database system reliability can be achieved
even if sever fails down. Another system is available to serve the client
request.
Performance: Performance can be achieved by distributing database over
different locations. So the databases are available to every location which
is easy to maintain.
• 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 sited that don’t share
physical components. This may be required when a particular database
needs to be accessed by various users globally.

56. Types of distributed databases
• 1. Homogeneous distributed databases system:
• Homogeneous distributed database system is a network of two or more databases (With
same type of DBMS software) which can be stored on one or more machines.
• So, in this system data can be accessed and modified simultaneously on several databases in
the network. Homogeneous distributed system are easy to handle.
• Example: Consider that we have three departments using Oracle-9i for DBMS. If some
changes are made in one department then, it would update the other department also.

57. 2. Heterogeneous distributed database system.
• Heterogeneous distributed database system is a network of two or more databases with different types of
DBMS software, which can be stored on one or more machines.
• In this system data can be accessible to several databases in the network with the help of generic
connectivity (ODBC and JDBC).
• Example: In the following diagram, different DBMS software are accessible to each other using ODBC and
JDBC.

58. Architectures of Distributed DBMS
The basic types of distributed DBMS are as
follows:
1. Client-server architecture of Distributed system.
• A client server architecture has a number of clients and a few servers
connected in a network.
• A client sends a query to one of the servers. The earliest available server
solves it and replies.
• A Client-server architecture is simple to implement and execute due to
centralized server system.

59. Architectures of Distributed DBMS
2. Collaborating server architecture.
• Collaborating server architecture is designed to run a single query on multiple servers.
• Servers break single query into multiple small queries and the result is sent to the client.
• Collaborating server architecture has a collection of database servers. Each server is capable
for executing the current transactions across the databases.

60. Architectures of Distributed DBMS
3. Middleware architecture.
• Middleware architectures are designed in such a way that single query is executed
on multiple servers.
• This system needs only one server which is capable of managing queries and
transactions from multiple servers.
• Middleware architecture uses local servers to handle local queries and
transactions.
• The software's are used for execution of queries and transactions across one or
more independent database servers, this type of software is called as middleware.

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

62. Types of data Fragmentation
• There are three types of data fragmentation:
• 1. Horizontal data fragmentation
• Horizontal fragmentation divides a relation(table) horizontally into the group of rows to create subsets of tables.
Example:
Account (Acc_No, Balance, Branch_Name, Type).
In this example if values are inserted in table Branch_Name as Pune, Baroda, Delhi.
The query can be written as:
SELECT*FROM ACCOUNT WHERE Branch_Name= “Baroda”
Types of horizontal data fragmentation are as follows:
1) Primary horizontal fragmentation
Primary horizontal fragmentation is the process of fragmenting a single table, row wise using a set of conditions.
• Acc_No Balance Branch_Name
• A_101 5000 Pune
• A_102 10,000 Baroda
• A_103 25,000 Delhi
• For the above table we can define any simple condition like, Branch_Name= 'Pune', Branch_Name= 'Delhi', Balance < 50,000
Fragmentation1:
SELECT * FROM Account WHERE Branch_Name= 'Pune' AND Balance < 50,000
Fragmentation2:
SELECT * FROM Account WHERE Branch_Name= 'Delhi' AND Balance < 50,000

63. • 2) Derived horizontal fragmentation
Fragmentation derived from the primary relation is called as derived horizontal fragmentation.
Example: Refer the example of primary fragmentation given above.
The following fragmentation are derived from primary fragmentation.
Fragmentation1:
SELECT * FROM Account WHERE Branch_Name= 'Baroda' AND Balance < 50,000
Fragmentation2:
SELECT * FROM Account WHERE Branch_Name= 'Delhi' AND Balance < 50,000
3) Complete horizontal fragmentation
• The complete horizontal fragmentation generates a set of horizontal fragmentation, which includes every table of
original relation.
• Completeness is required for reconstruction of relation so that every table belongs to at least one of the
partitions.
• 4) Disjoint horizontal fragmentation
The disjoint horizontal fragmentation generates a set of horizontal fragmentation in which no two fragments have
common tables. That means every table of relation belongs to only one fragment.
5) Reconstruction of horizontal fragmentation
Reconstruction of horizontal fragmentation can be performed using UNION operation on fragments.

64. • 2. Vertical Fragmentation
• Vertical fragmentation divides a relation(table) vertically into groups of columns to create subsets of
tables.Example:
• Acc_No Balance Branch_Name
• A_101 5000 Pune
• A_102 10,00 Baroda
• A_103 25,000 Delhi
• Fragmentation1:
SELECT * FROM Acc_NO
Fragmentation2:
SELECT * FROM Balance
Complete vertical fragmentation
• The complete vertical fragmentation generates a set of vertical fragments, which can include all the
attributes of original relation.
• Reconstruction of vertical fragmentation is performed by using Full Outer Join operation on fragments.

65. 3) Hybrid Fragmentation
• Hybrid fragmentation can be achieved by performing horizontal and vertical partition
together.
• Mixed fragmentation is group of rows and columns in relation.
Example: Consider the following table which consists of employee information.
• Emp_ID Emp_Name Emp_Address Emp_Age Emp_Salary
• 101 Surendra Baroda 25 15000
• 102 Jaya Pune 37 12000
• 103 Jayesh Pune 47 10000
• Fragmentation1:
SELECT * FROM Emp_Name WHERE Emp_Age < 40
Fragmentation2:
SELECT * FROM Emp_Id WHERE Emp_Address= 'Pune' AND Salary < 14000
Reconstruction of Hybrid Fragmentation
The original relation in hybrid fragmentation is reconstructed by performing UNION and FULL OUTER JOIN

66. •THANK YOU