1.

a)Explain in brief about ACID properties of transactions

Atomicity: Atomicity ensures that a transaction is treated as a single unit of operation. Either
all the operations within the transaction are successfully completed, or none of them are.
There's no partial execution. If any part of the transaction fails, the entire transaction is
rolled back to its original state.
Ex: Imagine a customer wants to transfer $100 from account A to account B. The transaction
involves two steps: deducting $100 from account A and adding $100 to account B. If the
system fails after deducting from account A but before adding to account B, it should
rollback the deduction from account A to maintain atomicity.
Consistency: Consistency ensures that the database remains in a consistent state before and
after the transaction. This means that the data must satisfy all the integrity constraints, such
as foreign key constraints, uniqueness constraints, etc. So, a transaction should not leave the
database in an inconsistent state.
Ex: Before the transaction, the total balance of all accounts in the system is consistent. After
the transaction, the total balance should remain the same. For example, if the total balance
before the transaction is $1000, with $600 in account A and $400 in account B, after the
transaction, the total balance should still be $1000.
Isolation: Isolation ensures that the execution of transactions concurrently does not result in
any unexpected outcomes. Each transaction should operate independently of other
transactions. Even if multiple transactions are executed simultaneously, the result should be
the same as if they were executed sequentially. Isolation prevents interference between
transactions.
Ex: Consider two customers, A and B, conducting transactions simultaneously. Customer A
transfers $50 from account X to account Y, and at the same time, customer B transfers $30
from account X to account Z. Even if these transactions occur concurrently, the system
ensures that they do not interfere with each other. So, the final balances should be
consistent, regardless of the order in which transactions are executed.
Durability: This property ensures that once a transaction is committed, the changes made by
the transaction are permanently saved and cannot be lost, even in the event of a system
failure. The changes are recorded in non-volatile storage (such as disk) and are guaranteed
to persist, providing reliability and recoverability.
Ex: After a successful transaction to update a customer's address in a database, the
durability property ensures that even if the system crashes immediately after the transaction
commits, the updated address remains intact. The changes made by the transaction are
permanently stored on disk and will be recovered upon system restart, ensuring that the
database remains in a consistent state despite the failure.
b) Discuss in detail about the significance of Check pointing in Database Systems.

1. Ensuring Safety Nets: Just like saving your game progress, checkpointing regularly
saves the state of the database onto a secure storage area. This means that if
 something goes wrong—like a power outage or system crash—the database can be
restored to its last saved point. Without checkpoints, a crash could lead to losing
important data changes.
2. Keeping Data Consistent: Imagine playing a game and suddenly losing all your recent
achievements because you didn't save your progress. Similarly, in databases,
checkpointing ensures that all the changes made to the data are saved together. This
prevents a situation where some changes are saved while others are lost, keeping the
data consistent.
3. Recovering Quickly: Just like loading a saved game, checkpointing helps databases
recover quickly after a crash. When the system restarts, it knows the last safe point
(checkpoint) and can quickly get back to where it left off, minimizing downtime.
Without checkpoints, the recovery process would take longer, causing more
disruption.
4. Reducing Risk: Checkpointing reduces the risk of data loss. By regularly saving the
database state, even if something unexpected happens, only the changes since the
last checkpoint need to be replayed or undone during recovery. This means less
chance of losing important data and less stress for the database administrator.
5. Improving Performance: Think of checkpointing as optimizing your gameplay by
saving progress at strategic points. Similarly, in databases, regular checkpoints spread
out the work needed for recovery over time. This improves the overall performance
because the system doesn't have to do all the work at once during a recovery process
2 a) Differentiate between Serial and Serializable Schedules.
b)Write a short note on Log-based recovery mechanism

1. Keeping a Log: Whenever a change is made to the database, like adding new data or
updating existing records, a log entry is created. This log contains details about the
change, like what was modified and when.
2. Recovery Point: Imagine you're playing a game and want to make sure you can go
back to a specific point if something goes wrong. Similarly, in databases, a recovery
point is established. This is typically done by periodically saving the current state of
the database, including all the changes logged up to that point.
3. Undo and Redo: If there's a problem and you need to recover your database, the log
comes to the rescue. It has a record of all the changes made, so the recovery process
can undo any incomplete transactions (like transactions that were started but not
finished) and redo any committed transactions (transactions that were successfully
completed).
4. Restoring the Database: Once the undo and redo operations are complete, the
database is restored to a consistent state. It's like rewinding a movie to a specific
scene to fix a mistake or skipping forward to replay something you missed.
5. Ensuring Data Durability: The log-based recovery mechanism ensures that your data
is durable, meaning it's resilient to failures or crashes. Even if the system
unexpectedly shuts down, the log can be used to bring the database back to a
consistent state, preserving your valuable data.
3 a) a) Explain the concept of Conflict Serializable Schedule with suitable example
Conflict serializable schedules ensure that concurrent transactions, when executed together,
produce the same result as if they were executed one after the other in some order. In
simpler terms, it ensures that the final outcome of concurrent transactions is consistent and
equivalent to some sequential execution order.
To determine whether a schedule is conflict serializable, we look for conflicts between the
operations of different transactions on the same data items. There are two types of conflicts:
1. Read-Write Conflict: This occurs when one transaction reads a data item that
another transaction writes to. In such cases, the read operation of the first
transaction might produce an incorrect result if it reads the data item before the
write operation of the second transaction completes.
2. Write-Write Conflict: This occurs when two transactions write to the same data item.
If the second transaction writes to the data item after the first transaction has
already written to it but before the first transaction commits, the final value of the
data item may depend on the order of execution of the transactions.
Let's break down this concept with an example:
Suppose we have two transactions, T1 and T2, that need to perform operations on two
bank accounts: Account A and Account B.
• Transaction T1: Transfer $100 from Account A to Account B.
• Transaction T2: Transfer $50 from Account B to Account A.
Now, let's consider two different schedules:
1. Schedule 1:
• T1 starts, transfers $100 from Account A to Account B.
• T2 starts, tries to transfer $50 from Account B to Account A, but it's blocked
until T1 completes.
• T1 completes.
• T2 resumes and transfers $50 from Account B to Account A.
2. Schedule 2:
• T2 starts, transfers $50 from Account B to Account A.
• T1 starts, transfers $100 from Account A to Account B.
• T1 completes.
• T2 completes.
Let's analyze whether these schedules are conflict serializable:
• In Schedule 1, T1 writes to Account B before T2 reads from it, so there's no conflict.
• In Schedule 2, T2 writes to Account A before T1 reads from it, so there's no conflict.
Both schedules are conflict serializable because they could be transformed into
sequential executions where transactions do not interfere with each other.
However, if we have a different schedule where T1 reads from Account B before T2
writes to it and vice versa, then it would not be conflict serializable, as there would be a
conflict between the transactions.
In essence, conflict serializability ensures that concurrent transactions can be executed in
any order as long as there are no conflicts between their operations on the same data
items.
b) Discuss about Write Ahead Log (WAL) protocol.
1. What Is WAL?
o WAL stands for Write-Ahead Logging.
o It’s a technique used in database systems to
ensure atomicity and durability (two of the ACID properties).
o Imagine it as a system that keeps track of all changes before they’re officially
applied to the database.
2. How Does It Work?
o When you make changes to the database (like inserting, updating, or deleting
data), WAL records these changes in a special log file.
 o The log file is like a diary where every operation is noted down.
o Before the changes are actually written to the database, they must be logged.
o This ensures that even if something goes wrong (like a sudden power loss or
system crash), we can recover from the log.
3. Why Is It Useful?
o Imagine you’re cooking a complex dish, and suddenly the power goes out.
o With WAL, you can check the log (your recipe) to see what steps you
completed before the outage.
o You can then decide whether to undo, complete, or keep things as they
are based on the log.
4. Benefits of WAL:
o Durability: Changes are recorded before they’re applied, so even if the system
crashes, we have a record.
o Efficiency: Updates can happen in-place, reducing the need to modify indexes
and block lists.
o Redo and Undo: Both types of information (redo and undo) are stored in the
log.

4 a) Differentiate between Strict 2PL and Conservative 2PL.

 5 b) Explain read-only, write-only & read before write protocols in serializability.
1. Read-Only Protocol:
o In a read-only protocol, transactions are restricted to reading data from
the database without performing any modifications.
o Characteristics:
▪ Transactions can only execute read
operations (e.g., SELECT queries).
▪ No write or update operations are allowed.
▪ Useful for scenarios where data consistency is not a concern
(e.g., reporting queries).
2. Write-Only Protocol:
o In a write-only protocol, transactions are limited to writing or modifying
data in the database without reading any existing values.
o Characteristics:
▪ Transactions can only execute write
operations (e.g., INSERT, UPDATE, or DELETE statements).
▪ No read operations are permitted.
▪ Rarely used in practice due to limited applicability.
3. Read-Before-Write Protocol:
o The read-before-write protocol ensures that transactions read data
from the database before writing or modifying it.
o Characteristics:
▪ Transactions first perform a read operation to retrieve the
current value of a data item.
▪ After reading, they proceed with the write operation to modify
the data.
▪ Ensures that transactions access the correct data and avoids
conflicts.
▪ Commonly used to maintain data consistency.

Example: Consider a banking scenario with two transactions:

• T1: Transfer $100 from Account A to Account B.

• T2: Withdraw $50 from Account B.

In a read-before-write protocol, both transactions would follow this sequence:

1. T1 reads the balance of Account A.

2. T1 writes the updated balance of Account A.
3. T2 reads the balance of Account B.
4. T2 writes the updated balance of Account B.

By ensuring that reads occur before writes, the protocol maintains consistency and
prevents conflicting updates.
6.Define the terms
(i) Serial schedule (ii) Serializable schedule (iii)Recoverable schedule
(iv) Strict schedule (v) Cascadeless schedule (vi) Complete schedule
(vii) Conflict serializable schedule (viii) View serializable schedule
(i) Serial Schedule:
• A serial schedule is a sequential arrangement of transactions where each transaction
is executed one after the other, without any interleaving.
• In a serial schedule, transactions are executed in their entirety, and no two
transactions run concurrently.
• Example: If we have transactions T1 and T2, a serial schedule could be T1 followed by
T2, where T2 starts only after T1 completes.
(ii) Serializable Schedule:
• A serializable schedule is a concurrent arrangement of transactions that yields a
result equivalent to some serial execution of those transactions.
• In a serializable schedule, transactions may execute concurrently, but the final
outcome is consistent with some sequential order of execution.
• Example: If we have transactions T1 and T2, a serializable schedule could be T1
followed by T2 or T2 followed by T1, as long as the final result is the same as if they
were executed serially.
(iii) Recoverable Schedule:
• A recoverable schedule is a schedule in which, if a transaction reads a data item
previously written by another transaction, the writing transaction commits before
the reading transaction commits.
• This ensures that if a transaction reads data that is later modified by another
transaction, the changes are still visible to the reading transaction even if the writing
transaction is rolled back.
• Example: If transaction T2 reads a value written by transaction T1, T1 must commit
before T2 commits for the schedule to be recoverable.
(iv) Strict Schedule:
• A strict schedule is a schedule in which every read operation by a transaction must
be followed by a write operation by that same transaction before any other
transaction is allowed to access the data item.
• This ensures that the data read by a transaction is always the most up-to-date
version of that data item.
 • Example: If transaction T1 reads a data item, it must write to that data item before
any other transaction can read or write to it.
(v) Cascadeless Schedule:
• A cascadeless schedule is a schedule in which a transaction T2 never reads a data
item that has been written by a transaction T1 unless T1 has committed.
• This prevents cascading rollbacks, where the rollback of one transaction forces the
rollback of subsequent transactions.
• Example: If transaction T2 reads a data item written by transaction T1, T1 must
commit before T2 starts.
(vi) Complete Schedule:
• A complete schedule is a schedule in which every transaction commits or aborts.
• This ensures that all transactions in the schedule reach a final outcome, either
committing their changes or rolling back.
• Example: In a complete schedule, every transaction T1, T2, ..., Tn either commits or
aborts, ensuring that all changes are finalized.
(vii) Conflict Serializable Schedule:
• A conflict serializable schedule is a schedule in which the equivalent serial execution
of transactions preserves the order of conflicting operations (i.e., read-write and
write-write conflicts).
• This ensures that the final outcome of the schedule is consistent with some serial
order of execution.
• Example: A schedule is conflict serializable if the order of read and write operations
maintains consistency with some sequential order of execution.
(viii) View Serializable Schedule:
• A view serializable schedule is a schedule in which the result of each transaction is
the same as if the transactions were executed in some serial order that is consistent
with their read and write operations.
• This ensures that each transaction sees a consistent snapshot of the database, even
though they may execute concurrently.
• Example: A schedule is view serializable if the final result of each transaction is
consistent with a serial execution of the transactions that respects their read and
write dependencies.
7. Explain how a recovery management algorithm works (ARIES Algorithm)
1 Logging Changes:
• ARIES starts by logging all changes made to the database in a sequential log
file. This log contains records of all updates, inserts, and deletes performed by
transactions.
• Think of it as keeping a journal of all the changes made to the database, like
writing down every edit or update you make in a notebook.
2 Transaction Logging:
• ARIES also logs information about the start and end of each transaction. This
helps track which transactions are active and which have completed.
• It's like marking the beginning and end of each task in your notebook to keep
track of what's happening.
3 Checkpointing:
• Periodically, ARIES takes a snapshot of the database called a checkpoint and
records it in the log.
• This checkpoint serves as a reference point, allowing the system to quickly
recover to a consistent state in case of failure.
• Imagine taking a snapshot of your progress in a game so that if you lose, you
can restart from that point without losing all your progress.
4 Undo and Redo Recovery:
• When a failure occurs, ARIES uses a combination of undo and redo operations
to recover the database to a consistent state.
• Undo means reversing the changes made by incomplete transactions,
bringing the database back to its state before the failure.
• Redo involves reapplying the changes that were made by transactions that
committed but might not have been recorded in the database before the
failure.
• Together, undo and redo operations ensure that the database is restored to a
consistent state even after a crash.
• It's like rewinding and replaying your game from the last checkpoint to get
back to where you were before the crash.
5 Transaction Undo During Redo:
• ARIES ensures that while redoing committed transactions, it also performs
undo operations for any incomplete transactions that were active at the time
of the failure.
 • This prevents incomplete transactions from leaving inconsistent changes in
the database during recovery.
• Think of it as fixing any mistakes made by unfinished tasks while replaying
completed tasks.
8. Explain Wait/Die and Wound/Wait Schemes in transaction management.
1. Wait/Die Scheme:
• In the Wait/Die scheme, when a transaction requests a resource that is currently held
by another transaction, it either waits (if it's older) or dies (if it's younger).
• If a younger transaction requests a resource held by an older transaction, it waits for
the older transaction to release the resource. This ensures that older transactions are
given priority and younger ones wait for their turn.
• However, if an older transaction requests a resource held by a younger transaction,
the younger transaction is forced to abort or rollback to allow the older transaction to
proceed. This prevents deadlock and ensures progress.
• Example: Suppose Transaction A is older and holds a lock on a resource. If
Transaction B, which is younger, requests the same resource, it will wait until A
releases it. However, if Transaction A requests the resource held by Transaction B, B
will be aborted to allow A to continue.
2. Wound/Wait Scheme:
• In the Wound/Wait scheme, when a transaction requests a resource held by another
transaction, it wounds (forces abort) the other transaction and then waits for the
resource.
• If a transaction T1 requests a resource held by another transaction T2, and T1 is older,
T2 is aborted, allowing T1 to proceed immediately without waiting. This ensures that
older transactions are prioritized over younger ones.
• However, if a younger transaction requests a resource held by an older transaction, it
waits for the older transaction to release the resource.
• Example: If Transaction B (older) requests a resource held by Transaction A
(younger), A will be aborted, allowing B to proceed immediately. But if Transaction A
requests a resource held by Transaction B, A will wait for B to release the resource.
•
8 . Explain the concept of surrogate key
A key is a column, or group of columns, in a database management system (DBMS) that uniquely
identifies every row in a table. Natural keys and surrogate keys are the two categories of keys.
• Natural Key: A column, or group of columns, that is generated from the table’s data is
known as a natural key. For instance, since it uniquely identifies every client in the table, the
customer ID column in a customer table serves as a natural key.
• Surrogate key: A column that is not generated from the data in the database is known as a
surrogate key. Rather, the DBMS generates a unique identifier for you. In database tables,
surrogate keys are frequently utilized as primary keys.
Surrogate Key
A surrogate key also called a synthetic primary key, is generated when a new record is inserted into a
table automatically by a database that can be declared as the primary key of that table. It is the
sequential number outside of the database that is made available to the user and the application or it
acts as an object that is present in the database but is not visible to the user or application.
We can say that, in case we do not have a natural primary key in a table, then we need to artificially
create one in order to uniquely identify a row in the table, this key is called the surrogate key or
synthetic primary key of the table. However, the surrogate key is not always the primary key. Suppose
we have multiple objects in a database that are connected to the surrogate key, then we will have a
many-to-one association between the primary keys and the surrogate key and the surrogate key cannot
be used as the primary key.
Features of the Surrogate Key
• It is automatically generated by the system.
• It holds an anonymous integer.
• It contains a unique value for all records of the table.
• The value can never be modified by the user or application.
• The surrogate key is called the factless key as it is added just for our ease of identification of
unique values and contains no relevant fact(or information) that is useful for the table.
Consider an example:
Suppose we have two tables of two different schools having the same column registration_no, name,
and percentage, each table having its own natural primary key, that is registration_no.
Table of school A:

registration_no name percentage

210101 Harry 90

210102 Maxwell 65
registration_no name percentage

210103 Lee 87

210104 Chris 76

Table of school B:

registration_no name percentage

CS107 Taylor 49

CS108 Simon 86

CS109 Sam 96

CS110 Andy 58

Now, suppose we want to merge the details of both the schools in a single table.
Resulting table will be:

surr_no registration_no name percentage

1 210101 Harry 90

2 210102 Maxwell 65

3 210103 Lee 87

4 210104 Chris 76

5 CS107 Taylor 49

6 CS108 Simon 86
 surr_no registration_no name percentage

7 CS109 Sam 96

8 CS110 Andy 58

As we can observe the above table and see that registration_no cannot be the primary key of the table
as it does not match with all the records of the table though it is holding all unique values of the table .
Now , in this case, we have to artificially create one primary key for this table. We can do this by
adding a column surr_no in the table that contains anonymous integers and has no direct relation with
other columns . This additional column of surr_no is the surrogate key of the table.
Why use Surrogate Key in DBMS?
There are several reasons to use surrogate keys in database tables:
1. Uniqueness: Data integrity is improved by the guaranteed uniqueness of surrogate keys.
2. Stability: Since surrogate keys do not depend on any business rules or data value, they have a
lower chance of changing over time.
3. Efficiency: Compared to natural keys, surrogate keys are frequently smaller and process more
quickly.
4. Flexibility: In the event that the natural key changes, rows can still be uniquely identified
using surrogate keys.
Advantages of the Surrogate Key
• As there is no direct information related with the table, so the changes are only based on the
requirements of the application.
• Performance is enhanced as the value of the key is relatively smaller.
• The key value is guaranteed to contain unique information .
• As it holds smaller constant values , this makes integration of the table easy .
• Enables us to run fast queries (as compared to the natural primary key)
Disadvantages of the Surrogate Key
• The surrogate key value can never be used as a search key.
• As the key value has no relation to the data of the table, so third normal form is violated.
• The extra column for surrogate key will require extra disk space.
• We will need extra IO when we have to insert or update data of the table.
10. What is the need of Lock? Explain shared lock and exclusive lock with the help of example
Need for Locks:
• In a multi-user database environment, multiple transactions may try to access or modify the
same data simultaneously.
• Without proper synchronization mechanisms, concurrent access can lead to data
inconsistency, lost updates, or other anomalies.
• Locks provide a way to control access to shared resources, ensuring that only one transaction
can modify a resource at a time while others wait or access it in a controlled manner.
Shared Lock:
• A shared lock allows multiple transactions to read a resource simultaneously, but it prevents
any transaction from modifying the resource while it's locked.
• Think of it like a library book: multiple people can read the book at the same time (shared
access), but only one person can borrow it and make changes (exclusive access).
• Example: Consider a database table containing employee records. Multiple transactions may
need to read these records simultaneously to generate reports or perform analyses. In this
case, each transaction acquires a shared lock on the table while reading the records. This
allows multiple transactions to access the records concurrently for reading purposes, ensuring
data consistency and preventing conflicts.
Exclusive Lock:
• An exclusive lock grants exclusive access to a resource, allowing a single transaction to
modify the resource while preventing other transactions from reading or modifying it
concurrently.
• Continuing with the library analogy, obtaining an exclusive lock is like borrowing a book:
only one person can borrow the book at a time, and others must wait until it's returned.
• Example: Suppose a transaction needs to update an employee's salary in the database. To
ensure data integrity and prevent conflicting updates, the transaction acquires an exclusive
lock on the corresponding record before making the change. While the lock is held, no other
transactions can read or modify the record, ensuring that the update is performed atomically
and consistently.