1.​ Why Concurrency control is needed in DBMS.

What problem occurs when two transaction

occurs simultaniously
2.​ Transaction state diagram.
3.​ Trigger program.
4.​ ACID Properties.
5.​ Groupby and Having clause in SQL.
6.​ Cursor program and properties.
7.​ Working of Assertion and trigger in SQL.
8.​ Conflict Serialisability.
9.​ Nested Correlated queries.
10.​ Views in SQL. syntax and example
11.​ Buffer replacement policies

1.​ Null and 3 valued logics

In SQL, NULL represents missing or unknown data. It doesn’t mean zero, empty string, or default—it
explicitly means the value is not known, not available, or not applicable. Because of this, SQL uses
Three-Valued Logic (3VL) instead of simple True/False logic.
Three-Valued Logic used in SQL when dealing with NULL values. SQL uses three logical values:
TRUE, FALSE, and UNKNOWN. This is essential because comparisons involving NULL don’t follow
traditional binary logic.

Special NULL Comparisons: IS NULL / IS NOT NULL

Because regular comparison operators don't work with NULL, SQL provides:

●​ IS NULL → returns TRUE if value is NULL

●​ IS NOT NULL → returns TRUE if value is NOT NULL

SELECT * FROM students WHERE phone_number IS NULL;

 2.​ What is a Nested Query?

A nested query (also called a subquery) is a query inside another SQL query.

●​ The inner query runs first and returns a result.

●​ The outer query uses that result to produce the final output.​

🔸 Types of Nested Queries

1. Non-Correlated Subquery

●​ Executes independently of the outer query.

●​ Inner query runs once.
●​ Used with operators like IN, NOT IN, ALL, ANY.​

2. Correlated Subquery

●​ Depends on each row of the outer query.

●​ Executes once per row of the outer query.
●​ Uses values from the outer query inside the inner query.
●​ Used with operators like EXISTS, NOT EXISTS.​
3. What is UNIQUE in SQL (in subqueries)?

●​ The UNIQUE keyword checks whether all rows in a subquery are different (no duplicates).​

●​ It returns:​

○​ TRUE → if all rows are unique (or if subquery returns nothing).

○​ FALSE → if there are duplicate rows.​

Important Notes:

●​ Two rows are considered duplicates only if all values are the same (including NULLs).
●​ If any value is different, the rows are unique.
●​ If NULL is present, SQL treats NULL ≠ NULL → so rows with NULLs are usually not
considered duplicates.​

4. Group by and having

What is GROUP BY?

●​ GROUP BY groups rows with the same value in one or more columns.​

●​ It’s commonly used with aggregate functions like:​

○​ COUNT(), SUM(), AVG(), MAX(), MIN()​

What is HAVING?

●​ HAVING is like a WHERE, but used after grouping.

●​ WHERE filters rows before grouping, HAVING filters groups after aggregation.
 5. Working of Assertion and trigger

An assertion is a constraint that is used to ensure a particular condition holds true across multiple rows or
even multiple tables in a database. It is generally used to enforce business rules or logical conditions that
span across the dataset.

●​ Functionality: An assertion checks if a specific condition is satisfied every time an INSERT or

UPDATE action is performed on the database. If the condition is violated (i.e., if the assertion
fails), the operation is not allowed to proceed.

CREATE ASSERTION c1
CHECK (NOT EXISTS (SELECT * FROM customer WHERE balance < 1000));

●​ In this example, we are ensuring that no customer has a balance less than 1000 in the customer
table.
●​ Condition: If there is any row in the customer table where the balance is less than 1000, the
assertion is violated, and the INSERT or UPDATE operation is stopped.

How it works:

1.​ When a change is made to the database (via INSERT or UPDATE), the system checks the
assertion condition.
2.​ If the query results in violating the assertion (i.e., creating a balance less than 1000 in the
customer table), the operation is aborted.
3.​ The assertion ensures that only valid data is allowed in the database based on the condition
defined.

Working of Trigger:

A trigger is a set of SQL statements that automatically execute (or "fire") when a specific event occurs on
a table, such as an INSERT, UPDATE, or DELETE action.

●​ Trigger Workflow:​
 1.​ Event: The trigger is activated by an event, such as data modification (INSERT,
UPDATE, DELETE).
2.​ Condition: Optionally, a condition is evaluated. If the condition is true, the trigger's
action is executed. If no condition is specified, the action is executed unconditionally.
3.​ Action: The action is the SQL statements or procedure that will be executed
automatically when the event occurs and the condition (if any) is met.

CREATE TRIGGER student_name

AFTER INSERT

ON student

FOR EACH ROW

BEGIN

UPDATE student

SET full_name = first_name || ' ' || last_name

WHERE id = NEW.id;

END;

Event: This trigger is set to fire AFTER an INSERT operation on the student table.

Condition: There’s no condition here, so it will fire every time an insert happens on the student table.

Action: After inserting a new row into the student table, the trigger will automatically concatenate the
first_name and last_name columns to update the full_name column for the newly inserted row.

NEW.id refers to the id of the newly inserted row.

Assertion:

●​ Ensures a condition holds true across the database before modifying data (via INSERT or
UPDATE).
●​ Can span multiple rows or tables.
●​ Checks conditions globally.
●​ Example: Ensuring no customer has a balance below 1000.

Trigger:​
 ●​ Executes a predefined set of SQL statements automatically when a data modification event
occurs.
●​ Can be associated with specific tables.
●​ The action is fired on a row-by-row basis.
●​ Example: Automatically populating a full_name field after inserting a new student record.

6. Views

A view in SQL is a virtual table based on the result of a SQL SELECT query. It doesn't store data
physically; instead, it fetches data from one or more underlying base tables. Views help in simplifying
queries, restricting access to specific data, and providing a level of abstraction.

2. View Creation:

To create a view, use the CREATE VIEW statement. A view can be based on one or multiple tables.

CREATE VIEW view_name AS

SELECT column1, column2, ...

FROM table_name

WHERE condition;

3. View Modification Strategies:

●​ Query Modification: Translates the view query into an equivalent query on base tables each time
it's accessed.​

●​ View Materialization: Physically stores the view's result temporarily and updates it periodically
or on demand.

4. View Updatability Rules:

A view can be updated only if:

●​ It is based on a single base table.​

●​ It does not contain DISTINCT, GROUP BY, ORDER BY, or aggregate functions.​

●​ All NOT NULL columns are present in the view.​

●​ It does not contain joins or nested queries.​

5. WITH CHECK OPTION Clause:

Ensures that any inserted or updated rows remain valid for the view. Prevents inserting data that violates
the view’s condition.

CREATE VIEW view_name AS

SELECT ...

FROM ...

WHERE condition

WITH CHECK OPTION;

6. DROP VIEW:

Removes the view from the database.

Syntax:

DROP VIEW view_name;

 Q.Why is Concurrency Control needed in DBMS? What problems occur when two transactions
execute simultaneously

Concurrency control in DBMS refers to managing simultaneous execution of multiple transactions in a

way that ensures data integrity, consistency, and isolation, even when many users access the database at
the same time.

Why is Concurrency Control Needed?

In a multi-user database system, multiple transactions may access the same data simultaneously.
Without concurrency control, this can lead to:

●​ Inconsistent database state

●​ Data loss or corruption
●​ Violations of database constraints
●​ Incorrect outputs or results

Concurrency control ensures:

●​ Serializability (results are as if transactions executed one after the other)

●​ Isolation (transactions do not interfere with each other)
●​ Atomicity (a transaction completes fully or not at all)​

Problems When Transactions Execute Simultaneously:

Let’s consider a flight reservation system where:

●​ X = 80 reserved seats initially

●​ Transaction T1: transfers 5 seat reservations from flight X to flight Y
●​ Transaction T2: reserves 4 seats on flight X​

Expected result:​
Final value of X = 80 - 5 - 4 = 71​
But due to interleaving, errors may occur as explained below.
 2. Temporary Update (Dirty Read) Problem:

Occurs when a transaction reads data written by another uncommitted transaction. If the writing
transaction fails, the reading one has read invalid (dirty) data.

🧠 Example:
●​ T1 updates balance to ₹5000.
●​ T2 reads the balance = ₹5000.
●​ T1 crashes → the update should not persist.
●​ But T2 has already used the incorrect data.​

3. Incorrect Summary Problem:

Occurs when a transaction is calculating a summary (like SUM) while other transactions are
modifying the data.

🧠 Example:
●​ T1 is computing total reserved seats.
●​ T2 reserves/cancels seats simultaneously.
●​ T1 reads partial old/new data → wrong total.​
 4. Unrepeatable Read Problem:

Occurs when a transaction reads the same data twice but gets different results due to updates from
other transactions in between.

🧠 Example:
●​ T1 reads X = 80.
●​ T2 reserves 5 seats → updates X = 75.
●​ T1 reads X again = 75.

T1 gets different values for the same item during its execution.

Q. Explain Transaction State Diagram in DBMS with all transaction states and operations.

Definition of a Transaction:

A transaction is a sequence of operations performed as a single logical unit of work. It must follow the
ACID properties:

●​ Atomicity
●​ Consistency
●​ Isolation
●​ Durability

A transaction should be executed completely or not at all to maintain database consistency.

✅ Key Transactional Operations:

●​ BEGIN_TRANSACTION: Start of transaction execution.
●​ READ / WRITE: Perform read/write operations on database items.
●​ END_TRANSACTION: Indicates all operations are complete.
●​ COMMIT_TRANSACTION: Finalize all changes permanently.
●​ ROLLBACK: Undo all changes due to failure or abort.

✅ Transaction States in DBMS:

A transaction goes through multiple states during execution:

1. Active State:

●​ The transaction is executing its operations (READ, WRITE).

●​ It is still in progress and not yet completed.​

2. Partially Committed State:

●​ All operations are completed.

●​ The system performs final checks (constraints, integrity, logging).
●​ The transaction is ready to commit if checks pass.

3. Committed State:

●​ The transaction has successfully passed all checks.

●​ All changes are permanently recorded in the database.
●​ The transaction cannot be undone now.

4. Failed State:

●​ The transaction encounters an error or fails a check.

●​ It must be rolled back.
●​ Changes made by the transaction are not saved.

5. Terminated State:

●​ Final state of a transaction.

●​ The transaction leaves the system.
●​ All logs or system references to this transaction are removed.​

Q.ACID Property

The ACID properties ensure that database transactions are reliable, accurate, and recoverable, even in
the presence of failures or concurrent transactions.

ACID stands for:

1. Atomicity:

●​ Definition: A transaction is treated as a single indivisible unit. Either all operations are
performed or none at all.​
 ●​ Example:​
Suppose you transfer ₹500 from Account A to Account B.​

○​ Step 1: Deduct ₹500 from A​

○​ Step 2: Add ₹500 to B​

If the system crashes after Step 1 but before Step 2, ₹500 is lost.​
Atomicity ensures that both steps are completed, or none are applied.​

2. Consistency:

●​ Definition: A transaction must take the database from one valid state to another, maintaining
data integrity and constraints.
●​ Example:​
If the total money in the bank before the transaction is ₹10,000, and we transfer ₹500 from A to
B, the total should still be ₹10,000 after the transaction.​
If integrity rules (e.g., balance ≥ 0) are violated, the transaction is rolled back to maintain
consistency.​

3. Isolation:

●​ Definition: Each transaction should execute independently of other transactions. Intermediate

results are invisible to others.
●​ Example:​
If two users are booking the last seat on a flight at the same time, only one should succeed.​
Isolation prevents interference and ensures correct final results, avoiding problems like lost
updates.​

4. Durability:

●​ Definition: Once a transaction commits, all its changes are permanently saved, even in case of
system failure.
●​ Example:​
After transferring ₹500 from A to B and getting a "Transaction Successful" message, a power
cut occurs.​
When the system restarts, the transaction must still be reflected in the database.
 Q. Conflict Serializability – Explained

Conflict Serializability is a method to check whether a non-serial schedule is equivalent to a serial

schedule by analyzing conflicting operations between transactions.

🔶 1. Why do we need it?

●​ In real-world databases, multiple transactions execute concurrently (interleaved).
●​ Serial schedules are safe but inefficient.
●​ So, we allow non-serial schedules but ensure they behave as if transactions ran serially.
●​ This is achieved through serializability checks.

🔶 2. What is a Conflict?
Two operations conflict if:

●​ They belong to different transactions.

●​ They access the same data item.
●​ At least one of them is a write operation

3. Conflict Serializability

A schedule is conflict serializable if it can be transformed into a serial schedule by swapping

non-conflicting operations without changing the result.

🔶 4. How to Check Conflict Serializability?

✅ Algorithm (Using Precedence Graph / Serialization Graph):
1.​ Create a node for each transaction.
2.​ For every pair of conflicting operations, add a directed edge:
○​ From Ti to Tj if Ti's operation appears before Tj's in the schedule.
3.​ If the graph has no cycles, the schedule is conflict serializable.
4.​ If the graph has a cycle, the schedule is not serializable.

Q.