Database Management Systems

CSE-Artificial Intelligence and Machine Learning

V-Semester
AL-502 Database Management Systems

Syllabus
UNIT IV: Transaction Processing Concepts: -Transaction System, Testing of Serializability,
Serializability of schedules, conflict & view serializable schedule, recoverability, Recovery
from transaction failures. Log based recovery. Checkpoints deadlock handling. Concurrency
Control Techniques: Concurrency Control, locking Techniques for concurrency control,
timestamping protocols for concurrency control, validation based protocol, multiple
granularity. Multi version schemes, Recovery with concurrent transaction. Introduction to
Distributed databases, data mining, data warehousing, Object Technology and DBMS,
Comparative study of OODBMS Vs DBMS. Temporal, Deductive, Multimedia, Web &
Mobile database.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
Transaction Processing Concepts:

Transaction

o The transaction is a set of logically related operation. It contains a group of tasks.

o 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

1. Open_Account(X)
2. Old_Balance = X.balance
3. New_Balance = Old_Balance - 800
4. X.balance = New_Balance
5. Close_Account(X)
Y's Account

1. Open_Account(Y)
2. Old_Balance = Y.balance
3. New_Balance = Old_Balance + 800
4. Y.balance = New_Balance
5. Close_Account(Y)
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:

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
1. R(X);
2. X = X - 500;
3. W(X);
Let's assume the value of X before starting of the transaction is 4000.

o The first operation reads X's value from database and stores it in a buffer.
o The second operation will decrease the value of X by 500. So buffer will contain 3500.
o 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.

What is a Transaction Processing System?

A Transaction Processing System (TPS) is a sophisticated information system that enables
firms to manage real-time transactions. It captures, processes, and stores every transaction
within an organization, ensuring data integrity and providing rapid responses. TPS can handle
batch processing or real-time processing, offering reliability, efficiency, and accurate
transaction processing. It is pivotal for managing business transactions securely and
maintaining seamless operations.
Key Takeaways:
 Transaction Processing Systems capture, process, and store transaction data in real-
time.
 TPS can handle batch processing or real-time processing, offering reliability, efficiency,
and accurate transaction processing.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
 Benefits of TPS include increased efficiency, improved accuracy, cost savings, and
scalability.
 Drawbacks of TPS include susceptibility to system failures, limited scalability, security
vulnerabilities, and cost and maintenance challenges.
 Examples of TPS include banking ATMs, stock exchanges, and airline reservation
systems.
Types of Transaction Processing Systems
1. Batch Processing: In batch processing, transactions are gathered and processed
together at scheduled intervals, notably in groups or batches. This method involves
accumulating transactions over some time and then processing them collectively as a single
unit. Due to this accumulation, there's a time delay between when the transaction takes place
and when it's processed. While batch processing is efficient for handling large volumes of
transactions, it tends to have slower response times compared to real-time processing.
2. Real-Time Processing: Real-time processing involves the immediate processing of each
transaction as it happens, without any delay. This means that transactions are processed
instantly, and the results are available immediately. Real-time processing is essential for
applications where immediate feedback is pivotal, such as online banking, e-
commerce platforms, and inventory management systems. Real-time systems prioritize
providing quick responses to each transaction or request, ensuring smooth and timely
operations.
Components of Transaction Processing System
1. Inputs: Inputs to the transaction processing system consist of source documents such
as invoices, customer orders, and purchase orders. These documents serve as the initial data
or instructions that enter the TPS, typically initiated either by a user or an external system.
2. Processing System: The processing unit within the TPS is responsible for interpreting the
input data, ensuring its accuracy, and executing appropriate actions based on the type of
transaction. This involves tasks like calculating order totals, updating inventory levels,
validating customer information, and generating invoices as required.
3. Storage: At the core of the TPS lies the database, which stores all pivotal data about
business transactions. This database contains information on distinct aspects, such as
customers, products, employees, and financial transactions, providing a centralized
repository for crucial data management.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
4. Outputs: Once the input has been processed, the TPS produces an output representing the
outcome of the transaction. These outputs can take various forms, including confirmation
messages, printed receipts, updated customer accounts, or email notifications, depending on
the nature of the transaction and the system's configuration.
Characteristics of Transaction Processing System
1. Rapid Response: In a transaction processing system, it's pivotal to ensure swift
performance and rapid response times. This ensures that input transactions are processed
quickly, limiting delays for customers and maintaining operational efficiency.
2. Reliability: Organizations heavily depend on TPS for smooth business operations. Any
system failure could disrupt these operations significantly. Therefore, TPS must incorporate
robust backup and recovery procedures to ensure quick and accurate recovery in case of
failure, ensuring reliability and continuity.
3. Inflexibility: TPS processes each transaction in a standardized manner, regardless of the
user or timing. This rigidity is pivotal to maintaining consistency and preventing deviations
that could lead to errors or inefficiencies in operations.
4. Controlled Processing: TPS should align with and support the firm's operational
structure, ensuring that transactions are handled in a controlled and structured manner and
maintaining data integrity and operational efficiency.
5. Real-Time Processing: TPS systems are designed to process transactions in real-time or
near real-time, ensuring immediate processing of transactions as they occur. This enables
timely decision-making and responsiveness to customer needs.
6. Concurrency Control: To prevent data inconsistencies, TPS must effectively manage
multiple transactions occurring simultaneously. Concurrency control mechanisms are
implemented to ensure that concurrent transactions are processed correctly and do not
interfere with each other.
7. ACID Properties: TPS adheres to the ACID properties, ensuring that transactions are
treated as atomic units, maintains consistency in the database, operates independently of each
other, and ensures the durability of committed transactions, providing reliability and data
integrity.
8. High Throughput: TPS is designed to handle a large volume of transactions efficiently,
making it suitable for firms with high transaction volumes. This high throughput capability

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
ensures that the system can manage the workload effectively without compromising
performance or response times.
Benefits of Transaction Processing System
1. Increased Efficiency and Productivity: Transaction Processing Systems (TPS) automate
manual tasks, freeing up employees to focus on more critical areas, thus enhancing overall
efficiency. Additionally, they can effortlessly manage increasing transaction volumes,
making them adaptable to accommodate business growth.
2. Improved Accuracy and Reduced Errors: Through automated data capture and
validation, TPS limits human errors, leading to more reliable financial records. They
prioritize data accuracy by implementing validation and processing checks, ensuring the
integrity of transactions.
3. Cost Savings: Automating tasks and streamlining processes with TPS results in significant
cost savings over time. By reducing the time and effort required for transaction processing,
TPS boosts cost efficiency and contributes to overall financial savings.
4. Improved Reliability: TPS maintains data consistency throughout the system, ensuring
that transactions adhere to predefined rules and constraints. Through consistent processing,
they prioritize data reliability, providing firms with trustworthy and dependable information.
5. Real-Time Processing: Operating in real-time, TPS offers instant updates and feedback,
enabling timely decision-making and responsiveness to changing circumstances. This real-
time processing capability enhances operational agility and efficiency.
6. Scalability: TPS can easily scale to handle growing transaction volumes, allowing firms
to manage increased workloads without sacrificing performance. This scalability ensures that
TPS can support business expansion and evolving needs.
7. Audit Trails and Durability: TPS maintains detailed audit trails for transactions, offering
a comprehensive record of transaction history for accountability and analysis purposes.
Additionally, they ensure the durability of processed transactions, meaning that completed
transactions persist even in the event of system failures, providing data resilience and
reliability.
Drawbacks of Transaction Processing System
1. Susceptibility to System Failures: Transaction Processing Systems (TPS) are vulnerable
to system failures and downtime due to their reliance on intricate hardware and software

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
infrastructure. Any malfunction or technical glitch can disrupt the entire transactional
process, potentially resulting in financial losses and operational setbacks.
2. Limited Scalability and Flexibility: Traditional TPS may struggle to adapt to increasing
transaction volume and complexity as businesses grow. Incorporating new transaction types
or modifying existing processes can be challenging and time-consuming, limiting
organizational agility and responsiveness to market changes.
3. Security Vulnerabilities: As TPS handles sensitive data, they are attractive targets for
cyberattacks and data breaches. Despite implementing security measures like encryption and
access controls, TPS remains vulnerable to sophisticated hacking techniques and insider
threats, posing significant risks to data integrity and confidentiality.
4. Cost and Maintenance Challenges: The setup and installation of TPS can be costly, and
maintenance may require specialized personnel. Regular updates and system maintenance
can present challenges, potentially causing disruptions or downtime that affect operational
continuity.
5. Lack of Standardization and Compatibility: TPS may lack standardization and be
affected by hardware and software incompatibility. This can limit the seamless integration of
TPS with existing systems and processes, leading to operational inefficiencies.
6. User Dependency and Training: Effective operation of TPS may necessitate specialized
user training. The system's complexity and user dependency can pose challenges, particularly
for smaller firms that may not have the resources to fully utilize the system.
7. Third-Party Interference and Security Risks: TPS operating in real-time are vulnerable
to third-party interference, such as hackers and identity theft, due to their online nature.
Failure to upgrade firewalls and security measures can erode customer trust and compromise
data security.
Examples of Transaction Processing Systems
1. Banking ATMs: Automated Teller Machines (ATMs) are responsible for handling various
bank transactions, including cash withdrawals and balance inquiries. Utilizing a Transaction
Processing System (TPS), an ATM verifies the user's identity, retrieves account information,
updates the account balance, and dispenses cash, all in real time. This seamless process
ensures efficient and secure banking transactions for customers.
2. Stock Exchanges: Complex Transaction Processing Systems are integral to the
functioning of stock exchanges like the New York Stock Exchange (NYSE). These systems
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
facilitate trades by ensuring order matching between buyers and sellers, updating stock prices
based on transactions, and electronically settling trades in real time. The TPS employed by
stock exchanges plays a crucial role in maintaining the integrity and efficiency of financial
markets.
3. Airline Reservation Systems: The process of booking a flight online relies on a
Transaction Processing System (TPS) within an airline reservation system. This TPS checks
seat availability, verifies payment information, and generates tickets and confirmation emails
in real time. By efficiently managing these tasks, the TPS enables seamless booking
experiences for passengers while ensuring accurate and timely processing of reservations.
ACID Properties in DBMS
A transaction is a single logical unit of work that accesses and possibly modifies the contents
of a database. Transactions access data using read-and-write operations. To maintain
consistency in a database, before and after the transaction, certain properties are followed.
These are called ACID properties.

Atomicity:
By this, we mean that either the entire transaction takes place at once or doesn’t happen at
all. There is no midway i.e. transactions do not occur partially. Each transaction is
considered as one unit and either runs to completion or is not executed at all. It involves the
following two operations.
— Abort : If a transaction aborts, changes made to the database are not visible.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
— Commit : If a transaction commits, changes made are visible.
Atomicity is also known as the ‘All or nothing rule’.
Consider the following transaction T consisting of T1 and T2 : Transfer of 100 from
account X to account Y .

If the transaction fails after completion of T1 but before completion of T2 .( say,

after write(X) but before write(Y) ), then the amount has been deducted from X but not
added to Y . This results in an inconsistent database state. Therefore, the transaction must be
executed in its entirety in order to ensure the correctness of the database state.
Consistency:
This means that integrity constraints must be maintained so that the database is consistent
before and after the transaction. It refers to the correctness of a database. Referring to the
example above,
The total amount before and after the transaction must be maintained.
Total before T occurs = 500 + 200 = 700 .
Total after T occurs = 400 + 300 = 700 .
Therefore, the database is consistent . Inconsistency occurs in case T1 completes
but T2 fails. As a result, T is incomplete.
Isolation:
This property ensures that multiple transactions can occur concurrently without leading to
the inconsistency of the database state. Transactions occur independently without
interference. Changes occurring in a particular transaction will not be visible to any other
transaction until that particular change in that transaction is written to memory or has been
committed. This property ensures that the execution of transactions concurrently will result
in a state that is equivalent to a state achieved these were executed serially in some order.
Let X = 500, Y = 500.
Consider two transactions T and T”.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems

Suppose T has been executed till Read (Y) and then T’’ starts. As a result, interleaving of
operations takes place due to which T’’ reads the correct value of X but the incorrect value
of Y and sum computed by
T’’: (X+Y = 50, 000+500=50, 500)
is thus not consistent with the sum at end of the transaction:
T: (X+Y = 50, 000 + 450 = 50, 450) .
This results in database inconsistency, due to a loss of 50 units. Hence, transactions must
take place in isolation and changes should be visible only after they have been made to the
main memory.
Durability:
This property ensures that once the transaction has completed execution, the updates and
modifications to the database are stored in and written to disk and they persist even if a system
failure occurs. These updates now become permanent and are stored in non-volatile memory.
The effects of the transaction, thus, are never lost.
Some important points:

Property Responsibility for maintaining properties

Atomicity Transaction Manager

Consistency Application programmer

Isolation Concurrency Control Manager

Durability Recovery Manager

The ACID properties, in totality, provide a mechanism to ensure the correctness and
consistency of a database in a way such that each transaction is a group of operations that
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
acts as a single unit, produces consistent results, acts in isolation from other operations, and
updates that it makes are durably stored.
ACID properties are the four key characteristics that define the reliability and consistency of
a transaction in a Database Management System (DBMS). The acronym ACID stands for
Atomicity, Consistency, Isolation, and Durability. Here is a brief description of each of these
properties:
1. Atomicity: Atomicity ensures that a transaction is treated as a single, indivisible unit of
work. Either all the operations within the transaction are completed successfully, or
none of them are. If any part of the transaction fails, the entire transaction is rolled back
to its original state, ensuring data consistency and integrity.
2. Consistency: Consistency ensures that a transaction takes the database from one
consistent state to another consistent state. The database is in a consistent state both
before and after the transaction is executed. Constraints, such as unique keys and
foreign keys, must be maintained to ensure data consistency.
3. Isolation: Isolation ensures that multiple transactions can execute concurrently without
interfering with each other. Each transaction must be isolated from other transactions
until it is completed. This isolation prevents dirty reads, non-repeatable reads, and
phantom reads.
4. Durability: Durability ensures that once a transaction is committed, its changes are
permanent and will survive any subsequent system failures. The transaction’s changes
are saved to the database permanently, and even if the system crashes, the changes
remain intact and can be recovered.
Overall, ACID properties provide a framework for ensuring data consistency, integrity, and
reliability in DBMS. They ensure that transactions are executed in a reliable and consistent
manner, even in the presence of system failures, network issues, or other problems. These
properties make DBMS a reliable and efficient tool for managing data in modern
organizations.
Advantages of ACID Properties in DBMS
1. Data Consistency: ACID properties ensure that the data remains consistent and
accurate after any transaction execution.
2. Data Integrity: ACID properties maintain the integrity of the data by ensuring that any
changes to the database are permanent and cannot be lost.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
3. Concurrency Control: ACID properties help to manage multiple transactions
occurring concurrently by preventing interference between them.
4. Recovery: ACID properties ensure that in case of any failure or crash, the system can
recover the data up to the point of failure or crash.
Disadvantages of ACID Properties in DBMS
1. Performance: The ACID properties can cause a performance overhead in the system,
as they require additional processing to ensure data consistency and integrity.
2. Scalability: The ACID properties may cause scalability issues in large distributed
systems where multiple transactions occur concurrently.
3. Complexity: Implementing the ACID properties can increase the complexity of the
system and require significant expertise and resources.
Overall, the advantages of ACID properties in DBMS outweigh the disadvantages. They
provide a reliable and consistent approach to data management, ensuring data integrity,
accuracy, and reliability. However, in some cases, the overhead of implementing ACID
properties can cause performance and scalability issues. Therefore, it’s important to
balance the benefits of ACID properties against the specific needs and requirements of
the system.
Serializability in DBMS
Serializability is a concept in database management systems (DBMS) that ensures the
correctness of concurrent transactions. A schedule (sequence of operations) is serializable if
its outcome is equivalent to the outcome of some serial execution of the same transactions.
Types of Serializability:
1. Conflict Serializability: Two schedules are conflict equivalent if one can be
transformed into the other by a series of non-conflicting swaps.
2. View Serializability: A schedule is view equivalent to a serial schedule if:
o The initial read of each transaction is the same.
o The final write of each transaction is the same.
o Intermediate operations do not change the output.
Testing Serializability
1. Conflict Serializability Test:
o Construct a precedence graph (or serializability graph):
 Nodes represent transactions.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
 Directed edges Ti→TjT_i \to T_jTi→Tj indicate that TiT_iTi must
precede TjT_jTj due to a conflict.
o If the graph contains no cycles, the schedule is conflict-serializable.
Steps:
o Identify conflicts (read-write, write-read, write-write).
o Draw directed edges for each conflict.
o Check for cycles in the graph.
Example:
T1: R(A), W(A)
T2: R(A), W(B)
T3: R(B), W(A)
Conflicts:
o T1→T2T1 \to T2T1→T2 (Write-Read conflict on AAA).
o T2→T3T2 \to T3T2→T3 (Write-Read conflict on BBB).
o T3→T1T3 \to T1T3→T1 (Write-Write conflict on AAA).
The precedence graph has a cycle, so SSS is not conflict-serializable.
2. View Serializability Test:
o Compare schedules based on the following:
 Same read operations.
 Same write operations for each data item.
 Same final write for each data item.
o More complex than conflict serializability, usually less practical to test.
Key Points:
 Conflict serializability is sufficient for ensuring serializability but not necessary
(some schedules are view-serializable but not conflict-serializable).
 Testing conflict serializability using precedence graphs is efficient and widely used in
practice.
 Ensuring serializability avoids anomalies like dirty reads, lost updates, and
uncommitted dependencies.
Conflict Serializable Schedule
A schedule is conflict serializable if it can be transformed into a serial schedule by swapping
non-conflicting operations.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
Example of a Conflict Serializable Schedule:
Consider two transactions T1T1T1 and T2T2T2:
 T1T1T1: R(A),W(A)R(A), W(A)R(A),W(A)
 T2T2T2: R(A),W(B)R(A), W(B)R(A),W(B)
Schedule S1
R1(A), R2(A), W1(A), W2(B)
Steps to Test Conflict Serializability:
1. Identify Conflicts:
o R1(A)) and W1(A): Same transaction, no conflict.
o R2(A) and W1(A) Read-Write conflict T2→T.
o W1(A) and W2(B)): No conflict (different data items).
2. Precedence Graph:
o Node T1 and T2.
o Directed edge T2→T1.
No cycles → Schedule S1 is conflict serializable.
Equivalent Serial Schedule:
 T2→T1: Execute T2 first, then T1.

View Serializable Schedule

A schedule is view serializable if it produces the same result as a serial schedule by preserving:
1. Initial reads: Every transaction reads the same value in both schedules.
2. Writes: Every transaction writes the same final value in both schedules.
3. Intermediate reads: Every read operation reads the correct value.
Example of a View Serializable but Not Conflict Serializable Schedule:
Schedule S2:
W1(A), W2(A)
1. Conflict Serializability:
o Conflicts: W1(A) and W2(A).
o Precedence Graph: Cycle between T1T1T1 and T2.
o S2S2S2 is not conflict serializable.
2. View Serializability:
o Initial reads: Both W1(A) and W2(A) start with the same initial value.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
o Final write: W2(A)W2(A)W2(A) matches a serial schedule T1→T2
o S2 is view serializable.

Key Differences Between Conflict and View Serializability

Aspect Conflict Serializability View Serializability

Definition Based on conflicts (Read-Write, Write-Write). Based on results equivalence.

Test Method Uses precedence graph (easy to test). Comparatively harder to test.

Less strict (superset of

Strictness More strict (subset of view serializable).
conflict).

Practical Widely used in DBMSs for concurrency

Rarely used due to complexity.
Use control.

Recoverability in DBMS
Recoverability ensures that if a transaction fails, the database can be brought back to a
consistent state. A schedule is recoverable if:
1. A transaction commits only after all transactions whose changes it read have also
committed.
2. There are no cascading rollbacks.
Recovery from Transaction Failures
When a transaction fails, the database uses recovery mechanisms to restore consistency.
Failures can be:
 System Failure: Power loss, crashes, etc.
 Transaction Failure: Logical errors, violations, etc.
 Media Failure: Disk crashes.
Recovery Techniques:
1. Undo: Reverts changes made by uncommitted transactions.
2. Redo: Reapplies changes made by committed transactions.
Log-Based Recovery
Log-based recovery uses a log (or journal) to record all changes made to the database. The log
is stored on stable storage to ensure durability.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
Key Concepts:
1. Write-Ahead Logging (WAL):
o Changes must be logged before being written to the database.
o Ensures durability and atomicity.
2. Log Entries:
o Undo Log: Contains old values (for rollback).
o Redo Log: Contains new values (for replaying committed transactions).
Steps for Log-Based Recovery:
1. During Failure:
o Identify transactions from the log as committed or uncommitted.
2. Recovery Process:
o Undo all operations of uncommitted transactions using the undo log.
o Redo operations of committed transactions using the redo log.
Check pointing
Checkpoints are used to reduce recovery time by saving the database state at intervals.
How It Works:
1. Periodically, the DBMS writes a checkpoint in the log:
o Saves the current state of the database.
o Identifies all active transactions.
2. During recovery:
o Start reading the log from the last checkpoint, ignoring earlier entries.
o Speeds up the recovery process.
Types of Checkpoints:
 Consistent Checkpoints: Ensure all transactions are completed.
 Fuzzy Checkpoints: Allow ongoing transactions but mark their state.
Deadlock Handling
Deadlocks occur when two or more transactions wait indefinitely for resources locked by each
other.
Methods for Deadlock Handling:
1. Prevention:
o Assign resource priorities and allocate them accordingly.
o Use techniques like wait-die or wound-wait to avoid circular waits.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
2. Detection:
o Use a wait-for graph:
 Nodes represent transactions.
 Edges indicate waiting.
o Detect cycles in the graph; cycles indicate deadlocks.
3. Recovery:
o Transaction Rollback:
 Abort one or more transactions involved in the deadlock.
 Choose the transaction with the lowest cost to roll back.
o Release its locks to resolve the deadlock.
4. Summary Table

Aspect Details

Ensures transactions commit only after all dependent transactions have

Recoverability
committed.

Log-Based Uses logs to undo/redo transactions. Includes Write-Ahead Logging

Recovery (WAL) for durability.

Checkpoints Save database state periodically to speed up recovery.

Deadlock Prevent, detect, or resolve deadlocks using strategies like wait-for graphs
Handling or transaction rollbacks.

Concurrency Control in DBMS

Concurrency control ensures the correct execution of concurrent transactions while
maintaining database consistency and isolation. It prevents problems like dirty reads, lost
updates, uncommitted data dependencies, and non-repeatable reads.
Concurrency Control Techniques
1. Locking Techniques
Locks are used to restrict access to data items during transaction execution.
1. Types of Locks:
o Shared Lock (S): Allows multiple transactions to read the data item but not
modify it.
o Exclusive Lock (X): Allows one transaction to read and modify the data item.
2. Two-Phase Locking (2PL):
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
o Growing Phase: A transaction acquires locks but does not release any.
o Shrinking Phase: A transaction releases locks but does not acquire any new
locks.
o Ensures serializability but may lead to deadlocks.
3. Strict 2PL:
o All exclusive locks are held until the transaction commits or aborts.
o Prevents cascading rollbacks.
4. Deadlock Handling in Locking:
o Deadlock Prevention: Enforce ordering of lock acquisition or use timeout
mechanisms.
o Deadlock Detection: Use a wait-for graph to detect cycles and resolve
deadlocks by rolling back transactions.
2. Timestamping Protocols
Timestamp-based protocols order transactions using timestamps to ensure serializability.
1. Key Concepts:
o Each transaction is assigned a timestamp when it starts.
o Timestamps are used to order operations on data items.
2. Rules:
o Read Rule: A transaction Ti_ can read a data item Q if Ti's timestamp is greater
than the write timestamp of QQQ.
o Write Rule: A transaction Ti can write to a data item QQQ if Ti's timestamp is
greater than the read and write timestamps of QQQ.
3. Advantages:
o Ensures no deadlocks (transactions don’t wait for locks).
o Provides serializability.
4. Disadvantages:
o May cause frequent rollbacks if transactions conflict.
3. Validation-Based Protocol
Also called optimistic concurrency control, this technique assumes conflicts are rare and
validates transactions before committing.
1. Phases:
o Read Phase: A transaction reads data items and performs computations.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
o Validation Phase: Before committing, the system checks for conflicts with
other concurrent transactions.
o Write Phase: If validation succeeds, the transaction updates the database.
2. Validation Check:
o A transaction Ti is validated if it does not conflict with other transactions that
have committed during its execution.
3. Advantages:
o No locks needed, reducing overhead.
o Suitable for low-conflict environments.
4. Disadvantages:
o High validation costs in high-contention environments.
o Rollbacks may be frequent if conflicts are common.
4. Multiple Granularity
This technique allows locking at different levels of granularity (e.g., tuples, pages, tables, or
entire database).
1. Hierarchy:
o Locks are organized in a tree structure, from coarse granularity (entire database)
to fine granularity (individual tuples).
2. Intention Locks:
o Intention Shared (IS): Intend to set a shared lock at a finer level.
o Intention Exclusive (IX): Intend to set an exclusive lock at a finer level.
o Shared and Intention Exclusive (SIX): Shared lock at the current level and
intention to set exclusive locks at finer levels.
3. Advantages:
o Reduces locking overhead when accessing large data sets.
o Supports efficient locking and unlocking.
4. Disadvantages:
o Adds complexity to the locking protocol.
5. Comparison of Techniques

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
Technique Advantages Disadvantages Use Case

Ensures serializability, May cause deadlocks, high High-contention

Locking
simple to implement. overhead. environments.

No deadlocks, ensures Frequent rollbacks in high- Read-heavy

Timestamping
serializability. contention environments. workloads.

Validation- No locks, low overhead High validation cost in high Low-contention

Based in low contention. contention. environments.

Multiple Efficient for hierarchical Complexity in lock Transactions on

Granularity access patterns. management. large datasets.

Multi-Version Concurrency Control (MVCC)

Multi-Version Concurrency Control allows multiple versions of a data item to coexist, ensuring
higher concurrency by providing snapshots of the database to different transactions. Instead
of locking data, MVCC maintains multiple versions of each data item, which transactions can
access based on timestamps.
Key Components:
1. Versions of Data Items:
o Each data item has multiple versions, each with a unique timestamp.
2. Timestamps:
o Start Timestamp: When a version becomes visible.
o End Timestamp: When a version is no longer visible.
3. Read and Write Rules:
o Read Rule: A transaction reads the version of the data item with the largest
timestamp less than or equal to the transaction's timestamp.
o Write Rule: A transaction creates a new version with its timestamp.
Advantages:
 No Blocking: Read operations don’t block write operations.
 High Concurrency: Readers access old versions, allowing writers to update the current
version.
Disadvantages:
 Storage Overhead: Multiple versions require additional storage.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
 Garbage Collection: Old, unused versions need to be periodically removed.
Recovery with Concurrent Transactions
Recovery mechanisms ensure the database remains consistent and durable even during system
failures when multiple transactions are running concurrently.
Steps for Recovery with Concurrent Transactions:
1. Log-Based Recovery:
o Use Write-Ahead Logging (WAL) to record changes before applying them to
the database.
o Keep logs for both committed and uncommitted transactions.
o Identify transactions as Committed or Uncommitted using the log during
recovery.
 Undo changes for uncommitted transactions.
 Redo changes for committed transactions.
2. Handling Dependencies:
o Concurrent transactions often have dependencies (e.g., one transaction reading
data written by another).
o Use dependency tracking to ensure recovery respects the order of execution.
Techniques for Recovery:
1. Undo/Redo Logging:
o Undo: Roll back uncommitted transactions to maintain consistency.
o Redo: Reapply changes made by committed transactions to ensure durability.
2. Checkpointing:
o Use checkpoints to limit the recovery scope.
o Transactions active at the checkpoint are rolled back if not committed during
recovery.
3. Shadow Paging:
o Use a copy of the database (shadow page table) for recovery.
o Original pages remain unchanged until the transaction commits, minimizing
rollback needs.
Concurrency Control During Recovery
Concurrency control techniques (like locks or MVCC) need to be integrated with recovery to
avoid conflicts during the recovery process.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
1. Locks in Recovery:
o Lock data items involved in active transactions to prevent new transactions from
accessing them during recovery.
2. MVCC in Recovery:
o Older versions of data items can be used to reconstruct the state of the database
for active transactions.
3. Avoiding Cascading Rollbacks:
o Use techniques like Strict Two-Phase Locking (Strict 2PL) to ensure
transactions release locks only after commit or abort.
4. Summary Table
Technique Advantages Disadvantages

Multi-Version High concurrency, non-blocking Storage overhead, garbage

(MVCC) reads. collection needed.

Log-Based Ensures durability and

Recovery time depends on log size.
Recovery consistency with WAL.

Speeds up recovery by limiting Additional overhead during normal

Checkpointing
log scope. operations.

Shadow Paging Minimizes rollback efforts. High overhead for large updates.

Introduction to Distributed Databases

A distributed database is a collection of data spread across multiple locations or systems,
connected through a network, but appearing as a single unified database to the user.
Key Features:
 Data Distribution: Stored at different physical locations.
 Transparency: Users interact as if it is a single database.
 Scalability: Easily accommodates more nodes or data.
 Reliability: Offers fault tolerance with data replication.
Advantages:
 Increased availability.
 Better performance due to localized data access.
 Scalability for large datasets and users.
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
Challenges:
 Complex data management and consistency.
 Higher maintenance and communication overhead.
Data Mining
Data mining is the process of extracting useful patterns or knowledge from large datasets using
techniques from statistics, machine learning, and databases.
Key Techniques:
 Classification: Predicting categorical labels (e.g., spam email detection).
 Clustering: Grouping similar data points (e.g., customer segmentation).
 Association Rule Mining: Finding relationships between variables (e.g., market basket
analysis).
Applications:
 Fraud detection.
 Customer relationship management.
 Healthcare and diagnosis.
Data Warehousing
A data warehouse is a centralized repository designed for querying and analysis, integrating
data from multiple sources.
Key Features:
 Subject-Oriented: Organized around key business areas.
 Time-Variant: Tracks historical data.
 Non-Volatile: Data is stable and not updated in real-time.
Components:
 ETL (Extract, Transform, Load) process.
 OLAP (Online Analytical Processing) tools for analysis.
Applications:
 Business intelligence.
 Strategic decision-making.
 Financial reporting.
Object Technology and DBMS
Object-oriented technology integrates database capabilities with object-oriented
programming features, forming Object-Oriented DBMS (OODBMS).
Prof. Vineeta Shrivastava
A.P CSE
LNCTE
 Database Management Systems
OODBMS Features:
 Encapsulation: Combines data and methods.
 Inheritance: Reuse of properties and methods.
 Complex Objects: Directly supports complex data structures.
 Comparative Study: OODBMS vs. DBMS

Aspect OODBMS DBMS

Data Model Object-oriented. Relational (tables).

Complex Data Types Supports directly (e.g., multimedia). Requires additional processing.

Query Language Object Query Language (OQL). SQL.

Performance Better for object-heavy applications. Better for structured tabular data.

Applications CAD, multimedia, web apps. OLTP, traditional databases.

Temporal, Deductive, Multimedia, Web & Mobile Databases

1. Temporal Database:
 Purpose: Stores time-based data (past, present, future).
 Features:
o Time-stamping for data (valid time, transaction time).
o Supports temporal queries (e.g., "What was the balance on this date?").
 Applications: Financial systems, historical data tracking.
2. Deductive Database:
 Purpose: Combines logic programming with databases.
 Features:
o Uses rules and facts to infer new knowledge.
o Often uses Prolog-like languages.
 Applications: AI systems, expert systems, natural language processing.
3. Multimedia Database:
 Purpose: Manages multimedia data like images, videos, and audio.
 Features:
o Handles large, unstructured data types.
o Provides metadata support for search and retrieval.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE
 Database Management Systems
 Applications: Digital libraries, media streaming platforms.
4. Web Database:
 Purpose: Serves as the backend for dynamic web applications.
 Features:
o Stores data accessible via web servers.
o Supports web technologies (HTML, XML, JSON).
 Applications: E-commerce sites, content management systems.
5. Mobile Database:
 Purpose: Supports mobile devices with intermittent connectivity.
 Features:
o Lightweight and energy-efficient.
o Synchronization and replication support.
 Applications: Mobile apps, IoT devices, real-time messaging.
Summary Table
Type Purpose Applications

Distributed DB Data distributed across nodes. Cloud systems, large-scale web services.

Data Mining Extracting useful patterns. Fraud detection, healthcare analytics.

Data Warehousing Centralized analytical data. Business intelligence, reporting.

Temporal DB Time-stamped data. Financial systems, auditing.

Deductive DB Rule-based inference. AI, expert systems.

Multimedia DB Handling multimedia files. Media platforms, digital archives.

Web DB Backend for web apps. E-commerce, CMS platforms.

Mobile DB Databases for mobile use. IoT, mobile apps, real-time systems.

Prof. Vineeta Shrivastava

A.P CSE
LNCTE