DAYANANDA SAGAR ACADEMY OF TECHNOLOGY & MANAGEMENT

Department of Computer Science and Design

Scheme and Solution

Internal Assessment- 2

Sub: Database Management System Sub Code:BCG404

Sem: 4 Date: 23-5-2025

Sl. Questions with solutions Marks

No
1 Explain insertion, deletion, and modification anomalies in a relational database and describe
why they are considered undesirable, with examples.
Explanation of 3 Anomalies with examples 9
Reason for they are considered as undesirable 1
1. Insertion Anomaly
An insertion anomaly occurs when we cannot insert data into a table without the presence
of other unrelated data.
Example:
Consider the table:
StudentID StudentName CourseI CourseNam Instructor
D e
101 Alice CS101 DBMS Dr. Rao
Suppose we want to insert a new course (CS102: OS by Dr. Sharma), but no student has
registered for it yet.
Problem:
We cannot insert this course unless we also insert a student record — which doesn’t make
sense and leads to incomplete data handling.

2. Deletion Anomaly
A deletion anomaly happens when deleting a record inadvertently removes useful
information that should have been retained.
Example:
If Alice drops all courses and we delete her record from the table:
StudentID StudentName CourseI CourseNam Instructor
D e
(deleted) (deleted) CS101 DBMS Dr. Rao
Problem:
We also lose information about the course CS101 and its instructor Dr. Rao, even though
the course still exists independently of the student.

3 Modification (Update) Anomaly

A modification anomaly occurs when we have to change the same data in multiple rows,
leading to a risk of inconsistency.
Example:
 If the instructor for CS101 changes from Dr. Rao to Dr. Mehta, we must update all rows
where CS101 appears.
Problem:
If we miss one of the rows, it results in inconsistent data, where CS101 has two different
instructors.
These anomalies are undesirable in a relational database because they violate the basic
principles of data integrity, consistency, and efficient data management.

2 What is the need for normalization in a relational database? Explain First Normal
Form (1NF), Second Normal Form (2NF), and Third Normal Form (3NF) with suitable
examples
Need for Normalization 4
• Eliminates data redundancy.
• Avoids insertion, deletion, and modification anomalies.
• Ensures data consistency and integrity.
• Simplifies database maintenance.
• Improves storage efficiency.
First Normal Form (1NF) 6
• Data must be atomic (no repeating groups or multivalued attributes).
• Each cell should hold a single value.
Second Normal Form (2NF)
• Must be in 1NF.
• No partial dependency (non-key attributes should depend on the whole
primary key).
Third Normal Form (3NF)
• Must be in 2NF.
• No transitive dependency (non-key attribute depending on another non-key
attribute).
3 Apply SQL skills to define and implement triggers and assertions.

TRIGGERS in SQL
A trigger is a stored procedure that is automatically executed in response to certain 5
events on a particular table or view (such as INSERT, UPDATE, or DELETE).
Syntax:
CREATE TRIGGER trigger_name
AFTER INSERT | UPDATE | DELETE
ON table_name
FOR EACH ROW
BEGIN
-- SQL statements
END;
Example: Trigger to log salary changes
Assume two tables:
• Employees(emp_id, name, salary)
• SalaryLog(log_id, emp_id, old_salary, new_salary, change_date)
CREATE TRIGGER log_salary_update
AFTER UPDATE ON Employees
FOR EACH ROW
WHEN (OLD.salary != NEW.salary)
BEGIN
 INSERT INTO SalaryLog(emp_id, old_salary, new_salary, change_date)
VALUES (OLD.emp_id, OLD.salary, NEW.salary, CURRENT_DATE);
END;
This trigger logs any salary changes into the SalaryLog table automatically.
2. ASSERTIONS in SQL
An assertion is a condition that must always be true for the database to remain in a 5
consistent state.
Note: Assertions are supported in standard SQL, but not all RDBMS (like MySQL)
implement them. PostgreSQL and Oracle support alternatives using triggers or
constraints.
Syntax:
CREATE ASSERTION assertion_name
CHECK (condition);
Example: Total salary budget should not exceed 1,000,000
CREATE ASSERTION total_salary_limit
CHECK (
(SELECT SUM(salary) FROM Employees) <= 1000000
);
If total salaries exceed this amount, the database will reject operations that cause
the violation.
4 Apply your SQL knowledge to create and drop views. Construct SQL statements
that define a view and then remove it, providing suitable examples.
A view is a virtual table based on the result of a SQL query. It does not store data
physically but allows you to simplify complex queries, enhance security, and 2
abstract underlying table structures.
Creating a View 4
Syntax:
CREATE VIEW view_name AS
SELECT column1, column2, ...
FROM table_name
WHERE condition;
Example: Create a view of high-salary employees
Assume a table:
Employees(emp_id, name, department, salary)

CREATE VIEW HighSalaryEmployees AS

SELECT emp_id, name, salary
FROM Employees
WHERE salary > 50000;
This creates a view named HighSalaryEmployees that shows only employees
earning more than ₹50,000.
Using the View 2
You can query the view like a regular table:
SELECT * FROM HighSalaryEmployees;
Dropping a View 2
Syntax:
DROP VIEW view_name;
Example:
DROP VIEW HighSalaryEmployees;
This removes the view from the database.
5 Consider the three transactions T1, T2, and T3, and the schedules S1 and S2 given
below. Draw the serializability (precedence) graphs for S1 and S2, and state whether
each schedule is serializable or not. If a schedule is serializable, write down the equivalent
serial schedule(s).
T1: r1 (X); r1 (Z); w1 (X);
T2: r2 (Z); r2 (Y); w2 (Z); w2 (Y);
T3: r3 (X); r3 (Y); w3 (Y);
S1: r1 (X); r2 (Z); r1 (Z); r3 (X); r3 (Y); w1 (X); w3 (Y); r2 (Y); w2 (Z); w2 (Y);
S2: r1 (X); r2 (Z); r3 (X); r1 (Z); r2 (Y); r3 (Y); w1 (X); w2 (Z); w3 (Y); w2 (Y);

S1: r1 (X); r2 (Z); r1 (Z); r3 (X); r3 (Y); w1 (X); w3 (Y); r2 (Y); w2 (Z); w2 (Y); 5
Serial T1 T2 T3
No
1 r1 (X)
2 r2 (Z)
3 r1 (Z)
4 r3 (X)
5 r3 (Y)
6 w1 (X)
7 w3 (Y)
8 r2 (Y)
9 w2 (Z)
10 w2 (Y)
We need to check RW, WR, WW conflicts on same variable, in different
transaction
Conflicts are there
1. r1 (Z)->w2 (Z) T1->T2
2. r3 (X) ->w1 (X) T3->T1
3. r3 (Y)->w2 (Y) T3->T2
4. w3 (Y)-> w2 (Y) T3->T2
This schedule is Serializable and equivalent schedule is T3->T1->T2

S2: r1 (X); r2 (Z); r3 (X); r1 (Z); r2 (Y); r3 (Y); w1 (X); w2 (Z); w3 (Y); w2 (Y);
Serial T1 T2 T3 5
No
1 r1 (X)
2 r2 (Z)
3 r3 (X)
4 r1 (Z)
5 r2 (Y)
6 r3 (Y);
7 w1(X)
8 w2 (Z)
9 W3(Y)
10 w2 (Y)
We need to check RW, WR, WW conflicts on same variable, in different
transaction
Conflicts are there
 1. r3 (X)->w1(X) T3->T1
2. r1 (Z) ->w2 (Z) T1->T2
3. r2(Y)->w3 (Y) T2->T1
4. r3 (Y)-> w2 (Y) T3->T2
5. w3(Y)->w2(Y) T3->T2
This schedule is Not Serializable as we can see cycle is present
6 Analyze the given transaction schedule to classify it as recoverable, non-recoverable, or
cascadeless. Examine the schedule's operations and justify your classification with
detailed reasoning.
A transaction schedule can be classified as recoverable, non-recoverable, or cascadeless 1
based on how transactions read and commit data.
A recoverable schedule ensures that if a transaction T₂ reads data written by T₁, then T₂ 3
must commit only after T₁ has committed. This prevents data inconsistency in case T₁
fails. For example, if T1 writes X, T2 reads X, and both commit in that order (T2 after T1),
the schedule is recoverable.
In contrast, a non-recoverable schedule occurs when T2 commits before T1, even after 3
reading T1’s uncommitted data. If T1 later aborts, T2 will have committed dirty data,
making the database inconsistent. For instance, if T2 reads X from T1 and commits, but
T1 later aborts, this is non-recoverable and unsafe.
A cascadeless schedule goes further by ensuring that a transaction reads data only after 3
the writing transaction has committed. This eliminates the need for cascading rollbacks.
For example, if T1 writes X and commits before T2 reads X, then the schedule is
cascadeless and safe. In summary, cascadeless schedules are the most desirable as they
prevent cascading rollbacks and ensure recoverability, while non-recoverable schedules
must be avoided due to potential data inconsistency.
7 Analyze the working of the Two-Phase Locking (2PL) protocol with the help of a
transaction schedule. How does 2PL ensure conflict serializability, and what are
the possible drawbacks such as deadlock? Provide an example to support your
explanation.
The Two-Phase Locking: 4
The Two-Phase Locking (2PL) protocol is a concurrency control mechanism that ensures
conflict serializability in transaction schedules by requiring all transactions to follow two
distinct phases: the growing phase and the shrinking phase.
In the growing phase, a transaction may acquire locks (shared or exclusive) on data items
but cannot release any locks. Once the transaction releases its first lock, it enters the
shrinking phase, during which it can only release locks and is not allowed to acquire any
new ones. 4
This strict locking protocol:
This strict locking protocol ensures that no two transactions can access the same data item
in conflicting ways (e.g., one writing and the other reading) without proper synchronization,
thus avoiding non-serializable schedules.
For example, consider two transactions: T1: r1(X), w1(X), r1(Y), w1(Y) and T2: r2(Y), w2(Y),
r2(X), w2(X). If both follow 2PL and acquire all required locks before releasing any, their
execution will result in a serializable schedule equivalent to either T1→T2 or T2→T1
depending on lock acquisition order. This guarantees that the final state of the database is
consistent with some serial execution.
However, a major drawback of 2PL is the possibility of a deadlock
Deadlock:
Two or more transactions wait indefinitely for each other’s locks. For instance, if T1 locks X 2
and T2 locks Y, and then T1 waits for Y while T2 waits for X, neither can proceed, causing
 a deadlock. Additionally, 2PL may lead to reduced concurrency, as transactions must hold
locks for a longer duration even when they are no longer needed, impacting system
performance. Despite these drawbacks, 2PL remains one of the most widely used protocols
due to its simplicity and effectiveness in guaranteeing conflict serializability in database
systems.
8 Analyze how the Timestamp Ordering protocol manages conflicting read and write
operations between concurrent transactions. Explain with an example how the protocol
uses transaction timestamps to decide the order of execution and ensures serializability.
The Timestamp Ordering
The Timestamp Ordering (TO) protocol ensures serializability in concurrent transactions 4
by assigning a unique timestamp to each transaction. It maintains two values for each
data item: read_TS(X) and write_TS(X), representing the latest timestamps of successful
read and write operations, respectively. When a transaction wants to read or write a data
item, the protocol checks these timestamps to decide whether the operation can proceed.
If it violates the timestamp order (i.e., appears to read or write outdated data), the
transaction is aborted. This approach avoids conflicts and maintains a serial order based
on timestamps. While effective, the protocol may lead to frequent aborts under contention,
which is its main drawback.
Strict Timestamp Ordering (STO) Protocol
4
• A stricter version of BTO.
• Delays (rather than aborts) a transaction if it violates timestamp ordering.
• Ensures that transactions always read and write only committed values.
• Helps prevent cascading aborts.
Thomas Write Rule (TWR)
2
• A relaxed version of BTO.
• Ignores obsolete writes instead of aborting the transaction.
• If a write operation is too late (i.e., timestamp is less than write_TS(X)), it is simply
ignored.
9 Examine the advantages and challenges of using document-based NoSQL
databases for handling semi-structured data in modern web applications
Introduction:
Document-based NoSQL databases store data in document formats like JSON,
BSON, or XML. Each document is a self-contained unit that holds key-value 2
pairs, lists, and nested structures. Unlike relational databases, they do not
require a fixed schema, making them ideal for semi-structured data and rapidly
changing applications.
Advantages: 4
• Flexible schema allows dynamic and varying structures.
• Suited for handling semi-structured and hierarchical data.
• High performance for read/write operations due to reduced joins.
• Easy mapping with object-oriented programming languages.
• Supports horizontal scaling and distributed architecture.
Disadvantages: 4
• Limited support for complex transactions and joins.
• May lead to data redundancy and inconsistency.
• Query syntax varies between systems; no universal standard.
 • Indexing and performance tuning can be complex.
• Schema flexibility can lead to poor design if not managed properly.
10 Compare the Key-Value store model in NoSQL databases with traditional relational
database systems in terms of data structure, scalability, and query capabilities. Discuss
the scenarios where each system is more suitable.

Introduction to Key-Value Pair (NoSQL): 2

Key-Value databases store data as a collection of key–value pairs, where each key is
unique and maps to a value. The value can be a simple data type or a complex object.
These databases are schema-less and optimized for quick retrieval based on keys.
Examples include Redis and Amazon DynamoDB.
Comparison with Relational Databases:
• Data Structure:
Key-Value: Key and value only, no fixed schema.
RDBMS: Tables with rows and columns; strict schema. 4
• Scalability:
Key-Value: Highly scalable horizontally across nodes.
RDBMS: Mainly vertical scaling; horizontal scaling is harder.
• Query Capability:
Key-Value: Simple lookups by key, no complex queries.
RDBMS: Supports rich SQL queries with joins and filters.
Suitable Scenarios:
4
• Key-Value Stores:
Best for caching, session management, user settings, and scenarios needing
ultra-fast access with minimal structure.
• Relational Databases:
Ideal for applications with complex data relationships, strict consistency, and
detailed querying needs like banking, inventory, and enterprise systems.

Signature of Faculty HOD