CO1: SHORT ANSWER

QUESTION:
1. Define normalization and normalize a student-course table with repeating
groups.

Normalization is the process of organizing the attributes and relations in a database to minimize
redundancy and dependency. It involves dividing large tables into smaller, manageable ones and
defining relationships between them.

Student-Course Table (Before Normalization):

Student_ Student_Na Course_ Course_Name Instruct

ID me ID or
101 John CS101 Computer Dr. A
Science
101 John MA101 Mathematics Dr. B
102 Mary CS101 Computer Dr. A
Science

This table contains repeating groups because multiple courses are listed for the same student.

Normalized Tables:

 Students Table:

Student_I Student_Name
D
101 John
102 Mary

 Courses Table:

Course_ID Course_Name Instructor

CS101 Computer Science Dr. A
MA101 Mathematics Dr. B

 Enrollment Table:

Student_I Course_ID
 D
101 CS101
101 MA101
102 CS101

2. What keys are used in normalization? Give an example to explain it in better

way.

The keys used in normalization are:

 Primary Key: A unique key that uniquely identifies a record in a table.

 Foreign Key: A key that establishes a relationship between two tables.
 Candidate Key: A set of attributes that can uniquely identify a record but are not
selected as the primary key.
 Composite Key: A primary key that consists of two or more columns.

Example:

 Students Table:

Student_ID (Primary Student_Name

Key)
101 John
102 Mary

 Enrollments Table:

Student_ID (Foreign Course_ID (Composite Key)

Key)
101 CS101
102 MA101

3. State four advantages of normalization with practical relevance.

1. Reduces Data Redundancy: Normalization minimizes data duplication by breaking

tables into smaller, related tables. This saves storage space and avoids unnecessary
repetition.
Practical Example: In a library database, a book title would be stored only once rather
than for each transaction.
2. Improves Data Integrity: Ensures data consistency by enforcing relationships between
tables, which helps in maintaining accurate data.
Practical Example: If a student's address changes, it will only be updated in one place
rather than multiple places in the database.
 3. Easier Maintenance: Changes in the data structure (e.g., adding new courses to a
student's record) are easier to implement in normalized databases.
Practical Example: A new course can be added to the system without altering other
parts of the database.
4. Improved Query Efficiency: Searching and querying normalized data is more efficient
because the data is split into logically structured tables.
Practical Example: A search for students enrolled in a particular course will only
involve the Enrollment table rather than multiple student-course records.

4. What is an atomic value, and how does it relate to 1NF?

An atomic value is a value that cannot be subdivided further. In the context of First Normal
Form (1NF), the requirement is that each column contains only atomic values (no repeating
groups or arrays).

Example:

 Non-Atomic: A column storing multiple phone numbers: “123-456-7890, 987-654-

3210”
 Atomic: Each phone number stored in a separate row or column:

Student_I Phone_Number
D
101 123-456-7890
101 987-654-3210

5. Define 2NF and normalize a table with composite keys showing partial
dependency removal.

Second Normal Form (2NF) is achieved when a table is in 1NF and all non-key attributes are
fully dependent on the primary key (i.e., no partial dependency).

Example:

Before 2NF (Partial Dependency):

Student_I Course_ID Instructor Grade

D
101 CS101 Dr. A A
101 MA101 Dr. B B
102 CS101 Dr. A A
Here, Instructor depends on Course_ID, not on the composite key (Student_ID, Course_ID).
This is a partial dependency.

After 2NF:

 Students Table:

Student_I Student_Name
D
101 John
102 Mary

 Courses Table:

Course_ID Instructor
CS101 Dr. A
MA101 Dr. B

 Enrollments Table:

Student_I Course_I Grade

D D
101 CS101 A
101 MA101 B
102 CS101 A

6. Explain partial dependency and provide its example.

Partial Dependency occurs when a non-key attribute depends on part of a composite primary
key, rather than the whole key.

Example:

For the table below, the composite key is (Student_ID, Course_ID), but Instructor depends only
on Course_ID, not the whole key.

Student_I Course_ID Instructor Grade

D
101 CS101 Dr. A A
101 MA101 Dr. B B
102 CS101 Dr. A A

Here, Instructor has partial dependency on Course_ID.

7. Explain transitive dependency and provide its example.

Transitive Dependency occurs when a non-key attribute depends on another non-key attribute
through an intermediate attribute.

Example:

Student_I Course_ID Instructor Department

D
101 CS101 Dr. A Computer Sci
102 MA101 Dr. B Mathematics

Here, Department depends on Instructor, and Instructor depends on Course_ID. So,

Department is transitively dependent on Course_ID.

8. What is Boyce-Codd Normal Form and when it is applied in database design?

Boyce-Codd Normal Form (BCNF) is a stricter version of 3NF where every determinant is a
candidate key. It is applied when there are anomalies that 3NF does not address, specifically
when a non-prime attribute depends on another non-prime attribute.

When applied: BCNF is used to eliminate any remaining redundancy or anomalies that might
still exist after applying 3NF.

9. What is the purpose of Fourth Normal Form (4NF) and when it is applied in
database design?

Fourth Normal Form (4NF) is applied when a table has multi-valued dependencies, i.e., when
one attribute depends on multiple other attributes but is independent of them.

Purpose: To eliminate multi-valued dependencies where one column depends on multiple other
columns.

When applied: Used when a relation has multi-valued dependencies and needs to be broken into
multiple tables to avoid redundancy.

10. How does normalization help to prevent data anomalies in a database?

Normalization helps in preventing three main types of data anomalies:

 1. Insertion Anomaly: Without normalization, inserting new data might require inserting
redundant information (e.g., adding a new student without repeating course data).
2. Update Anomaly: If data is duplicated across the table, updating one record may lead to
inconsistency (e.g., changing a course name in one record but not others).
3. Deletion Anomaly: Deleting data may cause unintended loss of important data (e.g.,
deleting a course might inadvertently delete student information associated with it).

CO1: -Long Answer:

Que11: Explain the difference between an insert anomaly, update anomaly, and
delete anomaly.
Ans:
In database systems, data anomalies are problems that occur when data is
inserted, updated, or deleted in an unnormalized or poorly structured table. These
anomalies lead to inconsistent, incomplete, or incorrect data. There are three
primary types of data anomalies: insert anomaly, update anomaly, and delete
anomaly. Each type of anomaly occurs due to data redundancy and improper
organization of data in tables.

1. Insert Anomaly
An insert anomaly happens when the database design restricts the addition of
new data unless some other unrelated data is also present. This means that you
cannot insert certain data into the database without having to supply additional
data, which might not always be available or relevant.
Example:
Imagine a table storing information about students and their courses in one single
table:

Student Student_N Cour Instruc

_ID ame se tor
101 Alice Math Mr.
Smith
If a new student wants to register but has not yet chosen a course, the database
design might prevent adding the student’s information because the Course field
cannot be left blank (or the course details are mandatory). Thus, you cannot insert
the student’s record without also specifying a course, which is an insert anomaly.

2. Update Anomaly
An update anomaly occurs when data redundancy leads to inconsistent data after
an update. Since the same data is stored in multiple places, updating a single
instance of that data may leave other instances outdated or incorrect, causing
inconsistency.
Example:
Using the same student-course table, suppose Alice’s instructor for Math changes
from "Mr. Smith" to "Ms. Johnson." If the instructor's name is stored redundantly in
multiple rows for different students or courses, and you update the instructor’s
name in only one row but not the others, the database ends up having conflicting
information about who teaches Math. This inconsistency due to partial updates is an
update anomaly.

3. Delete Anomaly
A delete anomaly happens when deleting some data unintentionally removes
additional, important data that should have been retained. This typically occurs
when multiple types of data are stored in the same table and are not properly
separated.
Example:
In the same table, if Alice is the only student enrolled in the Math course, and you
delete her record because she leaves the institution, you may unintentionally delete
all information about the Math course and its instructor as well. Thus, by deleting
one student's data, important course information is lost, leading to a delete
anomaly.

Aspect Insert Anomaly Update Anomaly Delete Anomaly

Meaning Unable to add new Updating data in Deleting data
data without one place but not in unintentionally
including unrelated all places causes removes other
or unnecessary inconsistency. important data.
data.
Cause Multiple data items Redundant data Multiple types of
 combined in one stored in multiple information stored
table, with rows or columns. together, causing
mandatory fields unintended loss
dependent on each when deleting a
other. record.
Example Cannot add a new Changing an Deleting a student
student unless a instructor’s name in who is the only
course is also one row but enrollee causes loss
specified, even if forgetting to update of course and
the student isn’t other rows where instructor
enrolled. the name appears. information.
Occurs When Inserting new Modifying data that Removing records
records with is duplicated across that contain
missing or multiple rows or multiple pieces of
incomplete data tables. related data.
fields that depend
on other data.
Impact on Data Causes inability to Leads to Leads to accidental
store incomplete or inconsistent or loss of valid data.
partial data. contradictory data
in the database.
Effect on Reduces flexibility Creates data Causes data loss
Database in adding new data inconsistency and and may harm
entries. reliability issues. referential integrity.
Normalization Fix Normalization Normalization Normalization
separates data into eliminates separates data, so
multiple tables so redundancy, so deleting one piece
related data can be updates happen in doesn’t remove
inserted only one place. unrelated data.
independently.
Common in Tables with Tables with Tables where
composite or multi- repeating groups or multiple entities are
valued fields that duplicated columns. stored in one table
aren’t properly without proper
normalized. relationships.

How fourth normal form is different from fifth normal form? Explain both
the forms by giving an example.

Answer:
Fourth Normal Form (4NF) and Fifth Normal Form (5NF) are advanced stages
of database normalization aimed at eliminating specific types of redundancies and
anomalies to ensure data integrity and efficiency in relational database design.
Fourth Normal Form (4NF)
Definition:
A table is in Fourth Normal Form (4NF) if it is already in Boyce-Codd Normal
Form (BCNF) and contains no multi-valued dependencies. A multi-valued
dependency occurs when one attribute in a table uniquely determines multiple
independent values of another attribute, leading to redundant data.
Purpose:
4NF removes redundancy caused by independent multi-valued facts stored in the
same table. It separates these into different tables to avoid duplication and
anomalies.
Example of 4NF Violation:

Student Cour Hobb

_ID se y
101 Math Painti
ng
101 Math Music
101 Physi Painti
cs ng
101 Physi Music
cs
In this table, Student_ID has two independent multi-valued attributes: Course and
Hobby. The combination results in redundant rows.
Normalization to 4NF:
Split into two tables:
1. Student-Course Table

Student Cour
_ID se
101 Math
101 Physi
cs
2. Student-Hobby Table

Student Hobb
_ID y
101 Painti
ng
101 Music

Fifth Normal Form (5NF)

Definition:
A table is in Fifth Normal Form (5NF), also called Project-Join Normal Form
(PJNF), if it is in 4NF and every join dependency is a consequence of the candidate
keys. It addresses cases where information can only be correctly reconstructed by
joining multiple tables, preventing join dependency anomalies.
Purpose:
5NF ensures that complex many-to-many relationships involving three or more
entities are decomposed into smaller tables to avoid redundancy and maintain data
integrity.
Example of 5NF Violation:
Consider a table showing which Supplier supplies which Part to which Project:

Suppl Pa Proje
ier rt ct
S1 P1 J1
S1 P2 J1
S2 P1 J1
S2 P2 J2
This represents a three-way relationship. The table can be decomposed into:
1. Supplier-Part

Suppl Pa
ier rt
S1 P1
S1 P2
S2 P1
S2 P2
2. Supplier-Project

Suppl Proje
ier ct
S1 J1
S2 J1
S2 J2
3. Part-Project

Pa Proje
rt ct
P1 J1
P2 J1
P2 J2
Joining these tables reconstructs the original data without redundancy.

Key Differences Between 4NF and 5NF

Aspect Fourth Normal Form Fifth Normal Form (5NF)

(4NF)
 Focus Eliminates multi-valued Eliminates join
dependencies dependencies

When applied When independent multi- When tables can be

valued attributes exist decomposed without loss
but with join dependencies

Type of dependency Multi-valued dependency Join dependency

Normalization goal Remove redundancy caused Ensure lossless
by multiple independent decomposition and avoid
sets join anomalies
Example problem Student with multiple Complex many-to-many
hobbies and courses stored relationships involving three
together or more entities

Complexity of Typically involves splitting Involves decomposing into

decomposition into two or more tables multiple tables to preserve
based on independent complex relationships and
attributes reconstruct original data

CO3: SHORT ANSWER

QUESTION:
Q21: What are common security threats in a database system and how can each
be mitigated practically?

Common Security Threats and Mitigations:

1. SQL Injection:
o Threat: SQL injection occurs when an attacker inserts malicious SQL statements
into a query, which can lead to unauthorized access to or manipulation of data.
o Mitigation:
 Use parameterized queries or prepared statements, which ensure that
input is treated as data, not executable code.
  Implement input validation to reject unexpected input and employ stored
procedures to minimize SQL injection risks.
2. Privilege Escalation:
o Threat: Privilege escalation allows users to gain access rights beyond their
authorization, potentially leading to data corruption, unauthorized access, or
system compromise.
o Mitigation:
 Implement role-based access control (RBAC) to define and enforce user
roles and permissions.
 Regularly audit user accounts and privileges to ensure that access rights
are in line with job requirements.
3. Data Breaches:
o Threat: A data breach is when unauthorized users gain access to sensitive data,
which can be exploited or stolen.
o Mitigation:
 Use encryption for data at rest and in transit to protect sensitive
information.
 Access controls should be enforced to limit who can view or alter data.
 Implement multi-factor authentication (MFA) for an added layer of
security.
4. Denial of Service (DoS):
o Threat: DoS attacks aim to make a database or service unavailable by
overwhelming it with traffic.
o Mitigation:
 Deploy firewalls and intrusion detection systems (IDS) to filter
malicious traffic.
 Use load balancing and redundancy to distribute traffic and prevent
single points of failure.
 Implement rate-limiting to control how many requests a user can send in
a specific time frame.
5. Insider Threats:
o Threat: Insider threats involve employees or trusted users intentionally or
unintentionally compromising the database's security.
o Mitigation:
 Apply the principle of least privilege (PoLP) to limit access rights based
on the specific tasks users need to perform.
 Monitor and audit database activities, looking for unusual behavior or
access patterns.
 Implement segregation of duties, ensuring no one user can perform
critical actions like modifying both data and the database schema.
6. Unpatched Vulnerabilities:
o Threat: Attackers exploit known vulnerabilities in database software to gain
unauthorized access or execute malicious actions.
o Mitigation:
 Keep the database management system (DBMS) and associated
software up to date by applying patches and updates regularly.
 Use automatic patch management tools to streamline this process and

reduce the risk of overlooking updates.
7. Weak Authentication:
o Threat: Weak passwords or poor authentication mechanisms can allow
unauthorized users to gain access to the database.
o Mitigation:
 Enforce strong password policies (e.g., minimum length, complexity
requirements) and implement multi-factor authentication (MFA).
 Use certificate-based authentication or tokenization for high-security
systems.

Q22: How does authentication differ from authorization in terms of user access
control in databases?

 Authentication is the process of verifying the identity of a user or system, typically

through credentials like usernames and passwords, biometric data, or tokens. The goal of
authentication is to ensure that the user is who they claim to be.
 Authorization, on the other hand, occurs after authentication and determines what
resources a user can access and what actions they can perform. It is the process of
granting or denying access rights based on the user's role, permissions, and access
policies.

In database systems:

 Authentication ensures that the database only allows valid users to connect.
 Authorization governs what actions authenticated users are allowed to perform (e.g.,
read, write, or modify data).

Q23: What is a distributed database and what are its practical advantages and
disadvantages?

A distributed database is a database that is stored across multiple physical locations, either on
different computers or in multiple data centers, yet is treated as a single cohesive system by users
and applications.

Advantages:

1. Scalability: Distributed databases can easily scale horizontally by adding more nodes
(computers) to the system, which allows for handling larger volumes of data.
2. Reliability and Availability: Since the data is spread across multiple locations, the
system can continue functioning even if one or more nodes fail.
3. Performance: Distributing data allows queries to be processed by the nearest node,
reducing latency and improving response time.
Disadvantages:

1. Complexity: Managing a distributed database requires dealing with data distribution,

replication, and synchronization, which adds complexity.
2. Consistency Issues: Maintaining consistency in a distributed environment (especially in
the presence of network failures) can be challenging, often requiring complex
mechanisms like the CAP theorem.
3. Increased Overhead: Data synchronization, communication between nodes, and
replication can introduce significant overhead, impacting performance.

Q24: Compare and contrast replication and fragmentation strategies in

distributed databases.

Replication and fragmentation are two main strategies used in distributed databases for data
distribution.

 Replication: In replication, copies of the same data are stored at multiple locations
(nodes) within the database. This ensures availability and fault tolerance, as the database
can continue to function even if one or more nodes fail.
o Pros: Improved availability, fault tolerance, and read performance since queries
can be served from multiple locations.
o Cons: Increased storage costs and potential issues with data consistency across
replicas.
 Fragmentation: Fragmentation involves dividing the database into smaller pieces
(fragments), each stored at different locations. The database can be horizontally
fragmented (dividing data based on rows) or vertically fragmented (dividing data based
on columns).
o Pros: Efficient use of resources, reduced data redundancy, and improved query
performance by limiting data to only what’s necessary at each node.
o Cons: Data retrieval can be slower if fragments need to be recombined from
multiple locations.

Q25: How does fault tolerance play a role in distributed database systems, and
what techniques are used to achieve it?

Fault tolerance refers to the ability of a distributed database system to continue operating
correctly even in the event of hardware failures, network issues, or other unexpected problems.

Techniques used for fault tolerance:

 1. Replication: By storing copies of data across multiple nodes, a distributed database can
continue functioning if one or more nodes fail. If one replica becomes unavailable, the
system can serve data from another replica.
2. Data Backup: Regular backups of data ensure that in the event of data corruption or loss,
the system can recover to a previous state.
3. Consensus Algorithms: Algorithms like Paxos or Raft help maintain consistency across
distributed nodes, ensuring that even when nodes fail or become disconnected, the system
can still reach a consensus about the state of the database.
4. Error Detection and Recovery: The system must include mechanisms to detect errors
and automatically recover from failures, either by restarting services, reconfiguring
nodes, or recovering from backups.

Q26: Discuss the significance of concurrency control mechanisms in distributed

databases.

Concurrency control is crucial in distributed databases to ensure that multiple users or processes
can access the database simultaneously without causing data inconsistencies or conflicts.

Significance:

1. Data Integrity: Concurrency control prevents conflicting operations (e.g., two users
trying to update the same record simultaneously) that could lead to data corruption.
2. Transaction Isolation: It ensures that transactions are isolated from one another,
meaning the intermediate states of one transaction are not visible to others until it is
committed.
3. Deadlock Prevention: Effective concurrency control helps avoid deadlocks, where two
or more transactions are stuck waiting for each other to release resources.
4. Performance: It allows the system to maximize throughput by enabling multiple
transactions to be processed concurrently while ensuring that they do not interfere with
each other.

Common mechanisms:

 Locking mechanisms (e.g., two-phase locking)

 Timestamp ordering
 Optimistic concurrency control

Q27: Describe the difference between horizontal and vertical partitioning in

distributed databases.

Horizontal Partitioning:
  Definition: Horizontal partitioning divides a database table into rows, distributing the
rows across different nodes. Each partition contains a subset of the total data (e.g., all
customer data from a certain region).
 Use Case: Suitable when a table has large numbers of rows and queries commonly
involve a subset of rows.
 Advantage: Improved query performance by limiting the amount of data each node must
handle.

Vertical Partitioning:

 Definition: Vertical partitioning divides a table into columns, storing each partition on a
different node. Each partition contains a subset of the columns (e.g., storing customer
name and address on one node, and customer transactions on another).
 Use Case: Useful when queries tend to access only a small subset of columns in a table.
 Advantage: More efficient storage and better query performance when accessing specific
columns.

Q28: What is the role of redo and undo operations in database recovery after a
system crash?

 Undo Operations: Undo operations are used to revert changes made by transactions that
were not committed at the time of the crash. These operations ensure that no partial
updates or invalid data are written to the database.
 Redo Operations: Redo operations are used to reapply changes from committed
transactions that may not have been written to the database before the crash. They ensure
that the database reflects the final state after the system recovery.

Both redo and undo operations are essential for achieving atomicity (ensuring transactions are
either fully completed or not at all) and durability (ensuring that committed transactions are
permanent even in the event of a crash).

Q29: What is a checkpoint in recovery management, and how does it help in

reducing recovery time?

A checkpoint is a mechanism in database systems where the current state of the database (i.e.,
all committed transactions and their changes) is saved to persistent storage. This state becomes a
recovery point.

Role in recovery management:

  During a system crash, the database can use the last checkpoint to avoid reapplying all
past transactions from the log. Instead, it can start recovery from the checkpoint and then
replay only the transactions that occurred after the checkpoint.
 Helps in reducing recovery time because the system doesn't need to process the entire
transaction log. It only needs to process transactions that happened since the last
checkpoint.

Q30: Discuss the challenges associated with recovery management in distributed

database systems.

Challenges:

1. Consistency Across Nodes: In distributed databases, it’s challenging to ensure that all
nodes are in a consistent state after a failure, particularly when nodes may have different
data versions.
2. Network Partitioning: During recovery, the database system must handle cases where
nodes cannot communicate with each other due to network issues. This can lead to
problems with data consistency and availability.
3. Transaction Coordination: Coordinating distributed transactions and ensuring that they
are either fully committed or rolled back across all nodes is complex, especially when
network failures or crashes occur during transaction processing.
4. Replication Issues: Maintaining the consistency of replicas during recovery is
challenging, especially when some replicas are not up to date with others due to failures
or lag in synchronization.

Techniques for Overcoming Challenges:

 Use two-phase commit (2PC) or three-phase commit (3PC) protocols to ensure

coordinated transaction commits across nodes.
 Implement logging and checkpointing mechanisms to facilitate recovery from failures.
 Ensure quorum-based replication to handle partition tolerance and ensure consistency
during recovery.

Q43: Describe the different types of fragmentation techniques used in distributed

databases, namely horizontal, vertical, and hybrid fragmentation. Provide
examples of scenarios where each type of fragmentation would be suitable.

Fragmentation Techniques:

1. Horizontal Fragmentation:
o Definition: Horizontal fragmentation divides a database table into smaller subsets
of rows. Each fragment contains a specific subset of the table’s data based on
some criteria, such as geographic location or customer type.
 o Example Scenario: A company operating in multiple countries can use
horizontal fragmentation to store customer data by region (e.g., one fragment for
North America, another for Europe).
o Use Case: Suitable for large tables with a high volume of rows, where data access
is typically based on row-specific criteria.
2. Vertical Fragmentation:
o Definition: Vertical fragmentation divides a table into columns rather than rows.
Each fragment contains a subset of the table’s attributes (columns).
o Example Scenario: A database containing customer information where personal
details (name, address) are stored in one fragment, while transactional data
(purchases, orders) is stored in another.
o Use Case: Ideal when different applications require access to different sets of
columns. For example, analytics applications may only need summary data
(aggregated fields), while transactional applications require detailed records.
3. Hybrid Fragmentation:
o Definition: Hybrid fragmentation combines both horizontal and vertical
fragmentation. This method breaks the data into subsets of rows and columns.
o Example Scenario: A customer database could be fragmented by region
(horizontal) and then by the type of information (vertical), such as having one
fragment with basic personal details and another with transactional history.
o Use Case: Useful in complex systems where both row-based and column-based
access patterns are needed, offering flexibility in data distribution and access.

CO3-LONG ANSWER
QUESTION:
Q44: Explain the concept of data replication in distributed databases. Discuss
the advantages and challenges associated with data replication, and describe
different replication strategies such as full replication, partial replication, and
data partitioning with replication.

Data Replication in Distributed Databases:

 Definition: Data replication involves creating and maintaining copies (replicas) of data
across multiple nodes in a distributed database to ensure high availability, fault tolerance,
and improved query performance.

Advantages of Data Replication:

 1. High Availability: Data is accessible from multiple replicas, ensuring that if one node
fails, the data is still available from other replicas.
2. Improved Read Performance: Queries can be serviced from any replica, reducing
latency and distributing the load among multiple servers.
3. Fault Tolerance: Replication ensures that data can be recovered from any replica in case
of failure or data corruption.

Challenges of Data Replication:

1. Consistency Issues: Keeping all replicas synchronized, especially in systems with high
write operations, can lead to consistency problems.
2. Storage Overhead: Storing multiple copies of the data increases the storage
requirements.
3. Synchronization Overhead: Managing the replication process, especially in large
systems, can introduce overhead in terms of both time and resources.

Replication Strategies:

1. Full Replication:
o Every node in the distributed system holds a full copy of the data.
o Use Case: Suitable for systems with relatively small datasets or when high
availability is a priority, such as in read-heavy applications.
2. Partial Replication:
o Only selected parts of the data are replicated across nodes based on access
patterns or specific requirements.
o Use Case: Ideal for large databases with multiple types of data, where only
certain data subsets are needed on specific nodes.
3. Data Partitioning with Replication:
o Combines both partitioning (splitting the data into fragments) and replication
(keeping copies of data partitions on multiple nodes).
o Use Case: Suitable for large-scale databases where the data needs to be both
partitioned for efficient storage and accessed quickly via replicas.

Q45: Explain the various techniques for the recovery of a database. Take
suitable examples to illustrate your answer.

Database Recovery Techniques:

1. Rollback (Undo) and Rollforward (Redo):

o Rollback (Undo): Involves undoing changes made by uncommitted transactions
in the event of a crash.
o Rollforward (Redo): Involves reapplying changes made by committed
transactions that were not persisted in the database before the crash.
 oExample: If a transaction modifies an order in a shopping cart but fails before
committing, the system will roll back the change. Conversely, if the transaction is
committed but the change is lost due to a failure, it will be rolled forward during
recovery.
2. Checkpointing:
o A checkpoint creates a snapshot of the database at a particular point in time,
marking all transactions that were committed up to that point.
o Example: In the event of a crash, recovery can begin from the last checkpoint,
applying only the transactions that were executed after the checkpoint.
3. Shadow Paging:
o A shadow page technique involves maintaining a backup (shadow) copy of the
database pages being modified. The original pages are updated, and if the system
crashes, the original (shadow) pages are used for recovery.
o Example: If a crash occurs after a page is modified but before the change is
written to disk, the system can use the shadow page to restore the database to its
original state.

Q46: Describe the shadow paging technique for crash recovery in DBMS.
Provide examples to illustrate the use of shadow paging in recovering from
system failures.

Shadow Paging for Crash Recovery:

 Definition: Shadow paging is a recovery technique where changes to database pages are
made in a new copy (shadow page) of the database. If a system failure occurs during a
transaction, the original database pages are not affected, and the system can restore to the
shadow pages.

How Shadow Paging Works:

1. When a database page is modified, the system creates a shadow page (a copy of the
original page).
2. The changes are made to the original page, and if the transaction commits successfully,
the shadow page is discarded, and the original page becomes permanent.
3. If a crash occurs before the commit, the system can simply use the unmodified shadow
page during recovery, ensuring no data loss.

Example:

 If a customer’s details are updated in a banking database, a shadow page is created for
that record. If the system crashes before committing the update, the original page
(shadow copy) is used to recover the database, avoiding inconsistent data.
Q47: Describe the difference between deferred and immediate database
modification techniques in recovery management.

Deferred vs Immediate Database Modification:

1. Deferred Database Modification:

o Definition: Changes made by a transaction are not written to the database until
the transaction commits. If the transaction fails before committing, none of its
changes are saved.
o Advantages:
 Reduces the number of write operations, improving performance.
 Easier to manage and rollback, as uncommitted changes are never applied.
o Example: A user updating their address in an e-commerce platform, but the
changes are only written to the database once the transaction is confirmed
(committed).
2. Immediate Database Modification:
o Definition: Changes made by a transaction are immediately written to the
database as soon as they occur, regardless of whether the transaction commits or
not.
o Advantages:
 Allows for immediate persistence, ensuring data is always up-to-date.
o Challenges: Requires complex mechanisms (e.g., logs) to ensure data consistency
in case of a crash before commit.
o Example: A bank transfer transaction where funds are deducted from one account
and immediately added to another, with changes written to the database during the
transaction.

Q48: Explain the role of recovery management in ensuring fault tolerance and
high availability in DBMS.

Role of Recovery Management in Fault Tolerance and High Availability:

1. Fault Tolerance:
o Recovery management ensures that the database can continue operating correctly
after a failure. Techniques such as logging, checkpointing, and replication allow
the system to recover data to a consistent state after crashes or hardware failures.
o By using these techniques, recovery management ensures that data loss is
minimized, and the database can restore to the last known good state.
2. High Availability:
o Recovery management plays a crucial role in ensuring that the database remains
accessible even in the event of failures. Replication and failover mechanisms
allow applications to access data from available replicas during maintenance or
failure events.
 o Automated failover and data recovery processes ensure that the system
continues to provide service without significant downtime.

Example: In the case of a database crash, recovery mechanisms like replication and data
restoration from logs ensure that the database remains available to users while also providing
data integrity and consistency.

CO2-SHORT ANSWER
QUESTION:
Q14: What is serializability, and why is it important in concurrent transaction
execution?

Serializability refers to the property of a database system in which the results of executing a set
of transactions concurrently are the same as if they had been executed sequentially, one after
another, without overlapping. It ensures that despite the interleaving of operations from multiple
transactions, the final state of the database will be consistent and correct.

Importance in Concurrent Transaction Execution:

 Consistency and Integrity: Serializability ensures that no transaction execution will

result in an inconsistent state of the database. By ensuring a serial order of transactions, it
prevents issues such as lost updates or inconsistent data.
 Correctness: It guarantees that even though multiple transactions may be running
concurrently, the system’s behavior will be equivalent to a non-concurrent system,
ensuring correct results from each transaction.
 Concurrency Management: Serializability is crucial to allow databases to handle
multiple transactions efficiently without sacrificing the correctness of the system.

Q15: Explain conflict operations (read–write, write–read, write–write) with real-

world examples.

Conflict Operations occur when two transactions access the same data item and at least one of
them is a write operation. These conflicts need to be managed to maintain database consistency.

1. Read-Write (RW):
o Definition: One transaction reads a data item, and another transaction writes to
the same data item.
o Example:
 Transaction 1 (T1) reads a bank account balance of $100.
 Transaction 2 (T2) writes a new balance of $150 to the same account.
o If T1 reads before T2 writes, the result could be incorrect if the write happens
after the read, as T1 would operate on stale data.
2. Write-Read (WR):
o Definition: One transaction writes to a data item, and another transaction reads
the same data item.
o Example:
 T1 writes an updated price of $20 for a product.
 T2 reads the price of the same product.
o If T2 reads the old price before T1 writes the new price, it will have outdated
information, leading to inconsistent results.
3. Write-Write (WW):
o Definition: Two transactions write to the same data item.
o Example:
  T1 writes a new address for a customer.
 T2 writes a different address for the same customer.
o This can lead to data loss or inconsistency since both transactions are changing
the data, but only the last write will persist.

Q16: What are the problems arising with locks?

Problems with Locks:

1. Deadlock:
o Deadlock occurs when two or more transactions are waiting for each other to
release locks, causing all involved transactions to be stuck indefinitely.
o Example: T1 locks Resource A and waits for Resource B, while T2 locks
Resource B and waits for Resource A.
2. Starvation:
o Starvation happens when a transaction is perpetually denied access to the data it
needs because other transactions keep acquiring the necessary locks first.
o Example: T1 is constantly waiting for T2 to release a lock, but T2 always gets
priority, preventing T1 from executing.
3. Lock Contention:
o When multiple transactions attempt to acquire the same lock, it can lead to delays
or longer wait times, which negatively impacts performance.
o Example: Multiple users trying to update the same account record may
experience delays due to lock contention.
4. Overhead:
o Locking mechanisms introduce overhead due to the need to maintain and manage
locks on data, potentially reducing system performance.

Q17: What is an inconsistent read problem, and how does it affect transaction
results?

An inconsistent read occurs when a transaction reads a data item that is being modified by
another transaction. The data read might not represent a consistent state, as it could be in the
middle of an update operation or have been partially modified by a transaction.

Effect on Transaction Results:

 This leads to incorrect decisions based on partially updated or inconsistent data.

 Example: A user reads an account balance while another transaction is updating the
balance. The user might see an outdated or partial balance, leading to incorrect
calculations or actions.
Example in Banking:

 Transaction 1 is updating the balance of a bank account.

 Transaction 2 reads the account balance during the update, which may result in reading
incorrect or outdated data.

Q18: Differentiate between starvation and deadlock.

Starvation:

 Definition: Starvation occurs when a transaction is perpetually delayed from executing

because other transactions are continuously given priority, preventing it from obtaining
necessary resources.
 Example: Transaction T1 is continuously delayed because it always has to wait for
transaction T2, even though T1 is ready to proceed.

Deadlock:

 Definition: Deadlock occurs when two or more transactions are in a state of waiting for
each other to release resources (locks), resulting in a cycle where no transaction can
proceed.
 Example: Transaction T1 locks Resource A and waits for Resource B, while Transaction
T2 locks Resource B and waits for Resource A, causing a deadlock.

Key Difference:

 Starvation involves delays without a cycle, and deadlock involves a circular dependency
where all affected transactions are stuck.

Q19: Why is two-phase locking important, and how does it ensure serializability?

Two-Phase Locking (2PL):

 Definition: Two-phase locking is a concurrency control method where each transaction

follows two phases:
1. Growing Phase: The transaction can acquire locks but cannot release any.
2. Shrinking Phase: Once the transaction releases a lock, it cannot acquire any
more locks.

Importance of 2PL:
  Ensures Serializability: By locking data before performing any operations, 2PL
guarantees that the transaction operations follow a serializable order, preventing
anomalies like lost updates, temporary inconsistencies, and other concurrency-related
problems.
 Avoids Conflicts: The restriction of releasing locks after entering the shrinking phase
ensures no conflicts arise from simultaneous transactions modifying the same data.

Q20: What anomaly occurs when a transaction reads the same data twice with
different values?

The anomaly that occurs when a transaction reads the same data twice with different values is
called a non-repeatable read.

 Definition: This happens when a transaction reads a data item, and between the two
reads, another transaction modifies that data item.
 Example:
o Transaction T1 reads the price of a product, which is $100.
o Transaction T2 then updates the price of the product to $120.
o T1 reads the price again and finds it is now $120, resulting in inconsistency in the
transaction's view of the data.

C02-LONG ANSWER
QUESTIONS:
Q37: Explain the transaction states, also associated with its operations.

In a database management system (DBMS), a transaction refers to a sequence of operations

performed as a single unit. The transaction moves through several states during its lifecycle,
depending on its execution and whether it encounters any issues. Here is a detailed description of
each transaction state, along with its associated operations:

1. New (or Created):

 o Definition: This is the initial state of a transaction. At this point, the transaction
has been created but has not yet started executing. The transaction might have
been initiated by a user or automatically by the system.
o Operations: The transaction enters the system, and necessary resources are
allocated, such as memory and a unique transaction ID. It might also be added to
a queue for scheduling its execution.
2. Active:
o Definition: This is the state when the transaction is actively executing its
operations. It is reading data, performing computations, and writing to the
database.
o Operations: In this state, the transaction can perform read and write operations
on database records, modify data, and make decisions based on the results of
those operations. Any changes made during this phase are temporary and not
permanent until the transaction reaches the commit stage.
3. Partially Committed:
o Definition: After a transaction has executed all its operations, it enters the
partially committed state. In this state, the transaction has completed its
operations, but it has not yet been finalized.
o Operations: The system performs a consistency check to verify that the
transaction has not violated any constraints, and all operations have been executed
correctly. This is the point where changes made by the transaction are not yet
permanent but are ready for the final commit.
4. Committed:
o Definition: A transaction enters this state when it has successfully completed, and
all its changes are now permanent in the database. The transaction is considered
finalized, and its results are visible to other transactions.
o Operations: In this state, the transaction’s changes are made durable, meaning
they will persist even if the system crashes. The system writes the changes to
permanent storage (e.g., disk) and updates any relevant indexes or logs to reflect
these changes. Once a transaction is committed, it cannot be rolled back.
5. Failed:
o Definition: This state occurs when a transaction encounters an error during
execution, such as violating a database constraint or failing to meet some
requirement. In this case, the transaction cannot proceed further.
o Operations: The transaction is aborted, and any changes made during its
execution are not saved. The system may log the failure for diagnostic purposes,
but no lasting effect is made to the database.
6. Aborted:
o Definition: After a transaction fails or is explicitly rolled back by the system (due
to a conflict, deadlock, or some other issue), it enters the aborted state.
o Operations: The system undoes any changes made by the transaction to ensure
the database is returned to its state before the transaction started (this is known as
"rollback"). The transaction may be retried or discarded, depending on the
circumstances. It can no longer be recovered, and its effect is completely removed
from the database.
The transaction states are important for ensuring that a database maintains ACID (Atomicity,
Consistency, Isolation, Durability) properties, ensuring that data remains consistent and reliable
even in the presence of failures.

Q38: Classify different types of schedules based on serializability and analyze

whether the following given schedules are serial, conflict-serializable, or view-
serializable using step-by-step conflict checking.

In database management, a schedule refers to the sequence of operations (read/write) from

multiple transactions. The classification of schedules based on serializability is important for
determining whether the concurrent execution of transactions results in a consistent state of the
database.

Types of Schedules Based on Serializability:

1. Serial Schedule:
o Definition: A schedule is serial if the transactions are executed one after the other
without overlapping. In a serial schedule, the operations of one transaction are
completely executed before the operations of the next transaction begin.
o Characteristics: There are no interleaved operations between transactions. It is
the simplest form of transaction scheduling, and the result is always serializable.
o Example: T1 → T2 → T3 (Transaction 1 completes all its operations before
Transaction 2 starts, and Transaction 2 completes before Transaction 3 starts).
2. Conflict-Serializable Schedule:
o Definition: A schedule is conflict-serializable if the transactions in it can be
reordered (by swapping non-conflicting operations) to form a serial schedule
without changing the final result.
o Conflict Operations: Two operations conflict if they access the same data item,
and at least one of them is a write operation. For example, if Transaction T1
writes to data item X, and Transaction T2 reads or writes to X, those operations
are in conflict.
o Steps for Checking Conflict-Serializability:
 Create a precedence graph (a directed graph where each node represents
a transaction, and edges represent conflicts).
 If the graph contains no cycles, the schedule is conflict-serializable.
 If there are cycles, the schedule is not conflict-serializable.
3. View-Serializable Schedule:
o Definition: A schedule is view-serializable if it is possible to transform it into a
serial schedule without altering the final state of the database. This is based on the
idea that the final view (set of data read by each transaction) should be the same
as in some serial execution.
o Characteristics: View serializability is a more relaxed form of serializability than
conflict serializability.
 o Checking Procedure: View-serializability requires comparing the read and write
operations of the transactions to ensure that the same final result is achieved as in
a serial schedule.

Steps for Conflict Checking:

1. Conflict Graph Construction: Construct a conflict graph by drawing nodes for each
transaction and drawing a directed edge between two transactions if they have conflicting
operations.
2. Check for Cycles: If the graph contains a cycle, the schedule is not conflict-
serializable.
3. Check for Serializability: If there is no cycle in the graph, the schedule is conflict-
serializable.

Q39: Describe the Two-Phase Locking Protocol (2PL), explain both its growing
and shrinking phases, and show how it helps maintain serializability using a
multi-transaction example involving resource locking.

Two-Phase Locking Protocol (2PL):

The Two-Phase Locking Protocol (2PL) is a concurrency control protocol used to ensure
serializability in a database system. It ensures that the results of transactions are equivalent to
some serial execution, preserving database consistency.

Phases of 2PL:

1. Growing Phase:
o Definition: During this phase, a transaction can acquire locks on data items, but it
cannot release any locks.
o Goal: The goal is for the transaction to acquire all the locks it needs to perform its
operations before it starts releasing locks.
o Example: Consider two transactions, T1 and T2. T1 begins its growing phase by
acquiring a lock on Resource A, then on Resource B, before performing
operations on them.
2. Shrinking Phase:
o Definition: Once a transaction releases a lock, it enters the shrinking phase. In
this phase, the transaction cannot acquire any new locks; it can only release locks.
o Goal: This phase ensures that no other transaction can access the resources locked
by the current transaction once it has started releasing locks.
o Example: After completing operations on Resource A and B, T1 releases the lock
on Resource A and then on Resource B. At this point, T1 is in its shrinking phase.

How it Ensures Serializability:

  Prevents Conflicts: 2PL prevents conflicting operations by ensuring that a transaction
cannot release locks and then attempt to acquire new ones, which could lead to
interleaved conflicting operations.
 Guarantees Serializability: By adhering to the two-phase structure, 2PL guarantees that
transactions are executed in a serializable order, meaning their results are equivalent to
some serial execution.

Example:

1. Transaction T1: Begins by acquiring locks on Resource A and Resource B.

2. Transaction T2: Waits for T1 to release its lock on Resource A before acquiring it.
3. T1 releases its locks (shrinking phase), allowing T2 to acquire locks and complete its
operations. T2 cannot acquire more locks after it starts releasing them.

By ensuring that transactions either complete fully or are prevented from modifying data after
starting to release locks, the 2PL protocol helps to ensure that the database remains in a
consistent state.

Q40: How can the Lost Update Problem occur in a concurrent system? Describe
this problem with a practical example and suggest how concurrency control
techniques like locking or timestamping can resolve it.

The Lost Update Problem occurs in a concurrent system when two or more transactions
concurrently access the same data and one transaction’s update is overwritten by another
transaction. The update is "lost" because the second transaction does not account for the first
transaction's update.

Example:

1. Transaction T1: Reads a balance of $100.

2. Transaction T2: Reads the same balance of $100.
3. Transaction T1: Updates the balance to $150 and writes it back to the database.
4. Transaction T2: Updates the balance to $120 and writes it back to the database.

In this case, T1's update to $150 is lost because T2 overwrites it with $120. The final state of
the database reflects $120, which is incorrect because T1's update was not taken into account.

Concurrency Control Solutions:

1. Locking: One way to resolve this problem is by using locks. By locking the data before it
is read and modified, you can prevent multiple transactions from updating the same data
simultaneously.
o Example: If T1 locks the balance before reading it, T2 will be forced to wait until
T1 finishes its update and releases the lock.
 2. Timestamping: The system assigns a timestamp to each transaction. If a transaction tries
to update data that has been modified by a transaction with an earlier timestamp, the
system rejects the update to avoid overwriting the previous transaction's change.
o Example: If T2 tries to update the balance after T1’s update, it is rejected because
T1 has a higher timestamp, indicating that T2’s update should be discarded.

By using either of these techniques, the database can ensure that updates are not lost and data
consistency is maintained.

Q41: Explain the rules of Timestamp-based Concurrency Control Algorithm

with an example.

The Timestamp-based Concurrency Control Algorithm is used to ensure that transactions are
executed in a serializable order based on their timestamps. The idea is to assign a unique
timestamp to each transaction, and the order of execution is determined by these timestamps.

Rules of Timestamp-based Concurrency Control:

1. Read Rule: A transaction can read a data item only if its timestamp is earlier than the
timestamp of the transaction that wrote to the data item.
o Example: If Transaction T1 (timestamp 1) writes to data item X, Transaction T2
(timestamp 2) can only read X after T1 commits.
2. Write Rule: A transaction can write to a data item only if its timestamp is earlier than the
timestamps of any transaction that has read or written to the data item.
o Example: If Transaction T1 (timestamp 1) writes to X, and Transaction T2
(timestamp 2) also writes to X, T2 will be rejected because its timestamp is later
than T1’s.

Example:

 Transaction T1 (Timestamp 1): Writes X = 100.

 Transaction T2 (Timestamp 2): Attempts to read X.
o T2 can read X because T1’s write occurred first, and the read rule is satisfied.
 Transaction T3 (Timestamp 3): Attempts to write to X.
o T3 will be rejected because T2 has already read X, and the write rule is violated.

Q42: What is ACID? Explain its properties in transaction management with an

example.

ACID is an acronym for Atomicity, Consistency, Isolation, and Durability, which are the key
properties that ensure the correctness and reliability of transactions in a database management
system.
1. Atomicity:
o Definition: A transaction is an atomic unit of work, meaning it either completes
entirely or not at all. If any part of the transaction fails, the entire transaction is
rolled back.
o Example: In a bank transfer, if $100 is deducted from one account but the credit
operation to another account fails, the entire transaction is rolled back to ensure
no funds are lost.
2. Consistency:
o Definition: A transaction brings the database from one valid state to another valid
state, ensuring that all database rules (e.g., constraints, triggers) are maintained.
o Example: If a transaction violates a database constraint (e.g., a rule that prevents
negative balances), the transaction is aborted, and the database remains consistent.
3. Isolation:
o Definition: The operations of a transaction are isolated from the operations of
other transactions. Even if transactions run concurrently, each transaction operates
as if it were the only one running.
o Example: If two transactions are transferring funds between accounts, they
should not interfere with each other. One transaction's intermediate steps (e.g., an
intermediate balance) should not be visible to others.
4. Durability:
o Definition: Once a transaction is committed, its changes are permanent, even in
the event of a system failure.
o Example: After committing a transaction that updates a bank account balance, the
changes are permanent and will persist even if the system crashes.