Module 4: Database Management Systems - Subjective

Pattern Exam Notes

Based on BCS403 - 2024-25 - Module 4

Chapter 1: SQL Advanced Queries

This chapter covers more complex SQL retrieval queries and methods for specifying
constraints and triggers.

More Complex SQL Retrieval Queries

Comparisons Involving NULL and Three-Valued Logic
●​ Meanings of NULL:
1.​ Unknown value (e.g., date of birth not known).
2.​ Unavailable or withheld value (e.g., phone number not listed).
3.​ Not applicable attribute (e.g., LastCollegeDegree for someone with no
degree).
●​ Each individual NULL is distinct from other NULLs.
●​ Comparisons involving NULL result in UNKNOWN.
●​ SQL uses three-valued logic: TRUE, FALSE, UNKNOWN.
●​ The WHERE clause selects tuples where the condition evaluates to TRUE. FALSE
and UNKNOWN are not selected.
●​ Checking for NULL: Use IS NULL or IS NOT NULL.
○​ Syntax:​
SELECT column_name(s)​
FROM table_name​
WHERE column_name IS NULL;​
​
SELECT column_name(s)​
FROM table_name​
WHERE column_name IS NOT NULL;​

○​ Example (Q18):​
SELECT Fname, Lname​
FROM EMPLOYEE​
WHERE Super_ssn IS NULL;​

●​ Equality comparison (=) is not appropriate for NULLs.

●​ Tuples with NULLs for join attributes are not included in join results by default.
Nested Queries, Tuples, and Set/Multiset Comparisons
●​ Nested Queries: Complete SELECT-FROM-WHERE blocks within an outer query.
Can appear in WHERE, FROM, SELECT, etc.
●​ Set Membership: Use IN.
○​ Syntax:​
SELECT column_name(s)​
FROM table_name​
WHERE column_name IN (SELECT column_name FROM another_table WHERE
condition);​

○​ Example (Q4A - simplified):​

SELECT DISTINCT Pnumber​
FROM PROJECT​
WHERE Pnumber IN (SELECT Pno FROM WORKS_ON WHERE Essn =
'Smith_Ssn');​

●​ Use = instead of IN if the nested query returns a single value.

●​ Tuple Comparisons: Compare tuples of values enclosed in parentheses.
○​ Syntax:​
SELECT column_name(s)​
FROM table_name​
WHERE (column1, column2) IN (SELECT column1, column2 FROM
another_table WHERE condition);​

○​ Example:​
SELECT DISTINCT Essn​
FROM WORKS_ON​
WHERE (Pno, Hours) IN (SELECT Pno, Hours FROM WORKS_ON WHERE Essn =
'123456789');​

●​ Set/Multiset Comparison Operators: = ANY, = SOME, >, >=, <, <=, <> combined
with ANY or SOME, and ALL.
○​ Syntax:​
SELECT column_name(s)​
FROM table_name​
WHERE value comparison_operator ANY (SELECT column_name FROM
another_table WHERE condition);​
​
 SELECT column_name(s)​
FROM table_name​
WHERE value comparison_operator ALL (SELECT column_name FROM
another_table WHERE condition);​

○​ Example:​
SELECT Lname, Fname​
FROM EMPLOYEE​
WHERE Salary > ALL (SELECT Salary FROM EMPLOYEE WHERE Dno = 5);​

●​ Attribute Name Ambiguity: An unqualified attribute reference refers to the

relation in the innermost nested query.
Correlated Nested Queries
●​ A nested query is correlated if its WHERE clause references an attribute from the
outer query.
●​ Execution Flow:
○​ Nested Query: Inner query runs first, once. Outer query uses the result.
○​ Correlated Query: Outer query executes first. Inner query runs for each row
of the outer query, using values from that row.
●​ Example (Q16 - correlated check):​
SELECT E.Fname, E.Lname​
FROM EMPLOYEE AS E​
WHERE E.Ssn IN (SELECT D.Essn FROM DEPENDENT AS D WHERE E.Fname =
D.Dependent_name AND E.Sex = D.Sex);​
​
(This query is correlated because the inner query's WHERE clause references
E.Fname and E.Sex from the outer query's EMPLOYEE AS E table.)
The EXISTS and UNIQUE Functions in SQL
●​ Boolean functions used in WHERE clause.
●​ EXISTS: Returns TRUE if a nested query result contains at least one tuple, FALSE
if empty.
○​ Syntax:​
SELECT column_name(s)​
FROM table_name​
WHERE EXISTS (SELECT * FROM another_table WHERE condition);​
​
SELECT column_name(s)​
 FROM table_name​
WHERE NOT EXISTS (SELECT * FROM another_table WHERE condition);​

○​ Examples from document (Q7):​

SELECT Fname, Lname​
FROM EMPLOYEE​
WHERE EXISTS (SELECT * FROM DEPENDENT WHERE Ssn = Essn)​
AND EXISTS (SELECT * FROM DEPARTMENT WHERE Ssn = Mgr_ssn);​

●​ Typically used with correlated nested queries.

●​ UNIQUE checks if tuples in a nested query result are unique (less common).

Explicit Sets and Renaming in SQL

●​ Explicit Sets: Use a list of values in parentheses with IN.
○​ Syntax:​
SELECT column_name(s)​
FROM table_name​
WHERE column_name IN (value1, value2, value3, ...);​

○​ Example from document (Q17):​

SELECT DISTINCT Essn​
FROM WORKS_ON​
WHERE Pno IN (1, 2, 3);​

●​ Renaming (Aliasing): Use AS for attributes or relations.

○​ Syntax:​
SELECT column_name AS new_column_name, table_name AS
new_table_name​
FROM table_name AS table_alias;​

○​ Example from document:​

SELECT E.Lname AS Employee_name, S.Lname AS Supervisor_name​
FROM EMPLOYEE AS E, EMPLOYEE AS S​
WHERE E.Super_ssn = S.Ssn;​

Joined Tables in SQL and Outer Joins

●​ Specify join operations in the FROM clause.
●​ Syntax:​
 SELECT column_name(s)​
FROM table1 JOIN table2 ON table1.column = table2.column;​
​
SELECT column_name(s)​
FROM table1 NATURAL JOIN table2;​
​
SELECT column_name(s)​
FROM table1 LEFT OUTER JOIN table2 ON table1.column = table2.column;​
​
SELECT column_name(s)​
FROM table1 RIGHT OUTER JOIN table2 ON table1.column = table2.column;​
​
SELECT column_name(s)​
FROM table1 CROSS JOIN table2;​

●​ Inner Join (Default): Only matching tuples included.

●​ Outer Join: Includes non-matching rows from one or both tables (padded with
NULLs).
●​ NATURAL JOIN: Implicit EQUIJOIN on attributes with the same name. Can be
combined with OUTER JOIN.
●​ CROSS JOIN: Cartesian product (all possible tuple combinations).
●​ Multiway Join: Nesting join specifications to join three or more tables.
○​ Examples from document:​
SELECT Fname, Lname, Address​
FROM (EMPLOYEE JOIN DEPARTMENT ON Dno = Dnumber)​
WHERE Dname = 'Research';​
​
SELECT Pnumber, Dnum, Lname, Address, Bdate​
FROM ((PROJECT JOIN DEPARTMENT ON Dnum = Dnumber) JOIN EMPLOYEE
ON Mgr_ssn = Ssn)​
WHERE Plocation = 'Stafford';​

Aggregate Functions in SQL

●​ Summarize information from multiple tuples.
●​ Functions: COUNT, SUM, MAX, MIN, AVG.
●​ Syntax:​
COUNT(*), COUNT(column_name), COUNT(DISTINCT column_name)​
SUM(column_name)​
 AVG(column_name)​
MAX(column_name)​
MIN(column_name)​

●​ Can be used in SELECT or HAVING clauses.

●​ MAX and MIN can apply to nonnumeric ordered domains.
●​ NULL values are discarded by aggregate functions (except COUNT(*)).
●​ Can use correlated nested queries with aggregate functions in WHERE.
○​ Example from document (Q19):​
SELECT SUM (Salary), MAX (Salary), MIN (Salary), AVG (Salary)​
FROM EMPLOYEE;​

Grouping: The GROUP BY and HAVING Clauses

●​ Apply aggregate functions to subgroups of tuples based on grouping attributes.
●​ GROUP BY: Specifies grouping attributes.
○​ Syntax:​
SELECT column1, aggregate_function(column2)​
FROM table_name​
GROUP BY column1;​

○​ Example from document (Q24):​

SELECT Dno, COUNT (*), AVG (Salary)​
FROM EMPLOYEE​
GROUP BY Dno;​

●​ Grouping attributes should appear in the SELECT clause.

●​ A separate group is created for NULL values in grouping attributes.
●​ Can use join conditions with GROUP BY.
●​ HAVING: Provides conditions on the summary information for groups. Only
groups satisfying the condition are retrieved.
○​ Syntax:​
SELECT column1, aggregate_function(column2)​
FROM table_name​
GROUP BY column1​
HAVING aggregate_function(column2) condition;​

○​ Example from document (Q26):​

SELECT Pnumber, Pname, COUNT (*)​
 FROM PROJECT, WORKS_ON​
WHERE Pnumber = Pno​
GROUP BY Pnumber, Pname​
HAVING COUNT (*) > 2;​

●​ WHERE filters individual tuples before grouping; HAVING filters groups after
grouping and aggregation.
Other SQL Constructs: WITH and CASE
●​ WITH Clause (Common Table Expressions - CTEs): Defines temporary, named
result sets usable within a single query.
○​ Syntax:​
WITH temporary_table_name (column1, column2, ...) AS (​
SELECT ...​
FROM ...​
WHERE ...​
GROUP BY ...​
HAVING ...​
)​
SELECT ...​
FROM temporary_table_name, another_table​
WHERE ...;​

○​ Example from document (structure):​

WITH BIGDEPTS (Dno) AS (​
SELECT Dno​
FROM EMPLOYEE​
GROUP BY Dno​
HAVING COUNT (*) > 5​
)​
SELECT Dno, COUNT (*)​
FROM EMPLOYEE​
WHERE Salary > 40000 AND Dno IN BIGDEPTS​
GROUP BY Dno;​

●​ CASE Statement: Allows conditional logic to return different values based on

conditions. Can be used in SELECT, WHERE, SET (for UPDATE), etc.
○​ Syntax:​
CASE​
 WHEN condition1 THEN result1​
WHEN condition2 THEN result2​
...​
ELSE resultN -- Optional​
END​

○​ Example from document (in an UPDATE statement):​

UPDATE EMPLOYEE​
SET Salary = CASE​
WHEN Dno = 5 THEN Salary + 2000​
WHEN Dno = 4 THEN Salary + 1500​
WHEN Dno = 1 THEN Salary + 3000​
ELSE Salary + 0​
END;​

Recursive Queries in SQL

●​ Used for hierarchical or graph-like data (e.g., employee-supervisor).
●​ Uses a recursive CTE defined with the WITH RECURSIVE clause.
●​ Consists of a base query (non-recursive part) and a recursive query (references
the CTE itself).
●​ The recursive query is repeatedly executed and UNIONed with previous results
until a fixed point is reached (no new rows are added).
○​ Syntax:​
WITH RECURSIVE recursive_table_name (column1, column2, ...) AS (​
-- Base query (non-recursive part)​
SELECT ...​
FROM ...​
WHERE ...​
​
UNION [ALL]​
​
-- Recursive query (references recursive_table_name)​
SELECT ...​
FROM recursive_table_name, another_table​
WHERE recursive_condition​
)​
SELECT ...​
FROM recursive_table_name;​
 ○​ Example from document:​
WITH RECURSIVE SUP_EMP (SupSsn, EmpSsn) AS​
(SELECT SupervisorSsn, Ssn FROM EMPLOYEE​
UNION​
SELECT E.Ssn, S.SupSsn​
FROM EMPLOYEE AS E, SUP_EMP AS S​
WHERE E.SupervisorSsn = S.EmpSsn)​
SELECT * FROM SUP_EMP;​

Specifying Constraints as Assertions and Actions as Triggers

Specifying General Constraints as Assertions in SQL
●​ Define general constraints that cannot be specified using basic relational model
constraints.
●​ CREATE ASSERTION:
○​ Syntax:​
CREATE ASSERTION constraint_name CHECK (condition);​

○​ Example from document:​

CREATE ASSERTION SALARY_CONSTRAINT​
CHECK (NOT EXISTS (SELECT * FROM EMPLOYEE E, EMPLOYEE M,
DEPARTMENT D​
WHERE E.Salary > M.Salary AND E.Dno = D.Dnumber AND
D.Mgr_ssn = M.Ssn));​

●​ Assertions are given a name and a CHECK condition (similar to a WHERE clause).
●​ The DBMS is responsible for enforcing the assertion.
●​ Often written using EXISTS and NOT EXISTS to check for violating tuples.
●​ Constraints can also be specified using CHECK on attributes, domains, and tuples
(best for constraints violated only by insertion/update).
Introduction to Triggers in SQL
●​ Specify actions to be taken automatically when specific events occur and
conditions are met.
●​ ECA Rule: Event, Condition, Action.
○​ Event: Database update operations (INSERT, UPDATE, DELETE).
○​ Condition: Optional; evaluated after the event. Action runs only if true.
○​ Action: Sequence of SQL statements, transaction, or external program.
●​ CREATE TRIGGER:
○​ Syntax:​
CREATE TRIGGER trigger_name​
[BEFORE | AFTER] {INSERT | UPDATE [OF column1, column2, ...] | DELETE}​
ON table_name​
[FOR EACH ROW | FOR EACH STATEMENT] -- FOR EACH ROW is more
common​
[WHEN (condition)] -- Optional condition​
trigger_body; -- (Can be a single statement or a block using BEGIN...END)​

●​ BEFORE or AFTER specifies when the trigger fires relative to the event.
●​ FOR EACH ROW fires for each row affected by the event; FOR EACH STATEMENT
fires once per statement.
●​ OLD and NEW keywords (within FOR EACH ROW triggers) refer to the row's state
before (OLD) and after (NEW) the modification.
○​ Example structures from document:​
-- After Insert Trigger (MySQL syntax using DELIMITER)​
DELIMITER //​
CREATE TRIGGER after_insert_salary_difference​
AFTER INSERT ON CUSTOMERS​
FOR EACH ROW​
BEGIN​
SET @my_sal_diff = CONCAT ('salary inserted is ', NEW.SALARY);​
END;//​
DELIMITER ;​
​
-- After Update Trigger (MySQL syntax using DELIMITER)​
DELIMITER //​
CREATE TRIGGER after_update_salary_difference​
AFTER UPDATE ON CUSTOMERS​
FOR EACH ROW​
BEGIN​
DECLARE old_salary DECIMAL (10, 2);​
DECLARE new_salary DECIMAL (10, 2);​
SET old_salary = OLD.SALARY;​
SET new_salary = NEW.SALARY;​
SET @my_sal_diff = CONCAT ('salary difference after update is ',
NEW.SALARY - OLD.SALARY);​
END;//​
 DELIMITER ;​

Chapter 2: Transaction Processing

This chapter introduces the fundamental concepts of transaction processing,
concurrency control, and recovery.

Introduction to Transaction Processing

●​ Single-User vs. Multiuser Systems: Multiuser systems allow concurrent access.
●​ Concurrency: Achieved through interleaved (multiprogramming) or parallel
execution.
●​ Transaction: A logical unit of database processing, consisting of one or more
database access operations.
●​ Transaction Boundaries: Specified by BEGIN TRANSACTION and END
TRANSACTION.
●​ Read-only vs. Read-write Transactions: Read-only only retrieve data;
read-write modify data.
●​ Database Items: Named data units (record, attribute, block, etc.). Granularity is
the size.
●​ Basic Operations:
○​ read_item(X): Reads item X into a program variable.
○​ write_item(X): Writes program variable X into database item X.
●​ Involves database cache (main memory buffers) and disk blocks.
●​ Read-set: Set of items a transaction reads.
●​ Write-set: Set of items a transaction writes.
●​ Why Concurrency Control is Needed: To prevent problems from uncontrolled
concurrent execution.
●​ Concurrency Problems:
○​ Lost Update Problem: One transaction's update is overwritten by another.
○​ Temporary Update (Dirty Read) Problem: A transaction reads a value
written by an uncommitted transaction that later fails.
○​ Incorrect Summary Problem: Aggregate function calculation is affected by
concurrent updates.
○​ Unrepeatable Read Problem: A transaction reads the same item twice and
gets different values because another transaction modified it between the
reads.
●​ Why Recovery is Needed: To ensure atomicity (all or nothing) and durability
(changes persist) in case of failures.
●​ Types of Failures:
 1.​ Computer failure (system crash)
2.​ Transaction or system error (overflow, programming error, user interrupt)
3.​ Local errors or exception conditions (data not found)
4.​ Concurrency control enforcement (aborting for serializability violation or
deadlock)
5.​ Disk failure (data loss on disk)
6.​ Physical problems and catastrophes (power failure, fire, etc.)

Transaction and System Concepts

●​ Transaction States:
○​ Active: Initial state, executing operations.
○​ Partially Committed: End of execution, checks may be performed.
○​ Committed: Successfully completed, changes permanently recorded.
○​ Failed: Error occurred.
○​ Terminated: Leaves the system (committed or aborted).
●​ Transaction Operations:
○​ BEGIN_TRANSACTION: Marks the start.
○​ READ or WRITE: Database access.
○​ END_TRANSACTION: End of operations.
○​ COMMIT_TRANSACTION: Signals success, changes are permanent.
○​ ROLLBACK (or ABORT): Signals failure, undoes changes.
●​ The System Log: Maintains a record of transaction operations affecting
database items for recovery. Stored on disk.
●​ Log Entries (Log Records):
○​ [start_transaction, T]
○​ [write_item, T, X, old_value, new_value]
○​ [read_item, T, X]
○​ [commit, T]
○​ [abort, T]
●​ Used for Undo (resetting to old_value) and Redo (applying changes from log).
●​ Commit Point: When all operations are successful and log entries are recorded.
●​ Force-writing: Writing log buffers to disk before committing a transaction to
ensure durability.
●​ DBMS-Specific Buffer Replacement Policies: Strategies for managing main
memory buffers in the database cache (e.g., LRU, Domain Separation, Hot Set,
DBMIN).
Desirable Properties of Transactions (ACID)
●​ Properties that concurrent transactions should possess, enforced by DBMS.
●​ Atomicity: All operations are performed entirely, or none are. (Recovery
subsystem)
●​ Consistency Preservation: Transaction takes the database from one consistent
state to another. (Programmers, integrity constraint enforcement)
●​ Isolation: Transaction appears to execute alone, unaffected by others.
(Concurrency control subsystem)
●​ Durability (Permanency): Changes of committed transactions persist despite
failures. (Recovery subsystem)
Characterizing Schedules Based on Recoverability
●​ Schedule (History): An ordering of operations from concurrent transactions.
●​ Conflicting Operations: Two operations conflict if they are from different
transactions, access the same item, and at least one is a write_item. Changing
their order changes the outcome (read-write conflict, write-write conflict).
●​ Complete Schedule: Includes all operations, maintains transaction order, and
orders all conflicting operations.
●​ Recoverable Schedule: No transaction T commits until all transactions T' that T
read from have committed. Ensures committed transactions don't need rollback.
○​ "T reads from T'" means T' writes an item X, and T later reads X, with no
intervening writes to X.
●​ Cascading Rollback (Cascading Abort): An uncommitted transaction must be
rolled back because it read from a transaction that failed (can occur in some
recoverable schedules).
●​ Cascadeless Schedule: Every transaction reads only items written by committed
transactions. Prevents cascading rollback.
●​ Strict Schedule: Transactions can neither read nor write an item X until the last
transaction that wrote X has committed (or aborted). Simplifies undo process.
Characterizing Schedules Based on Serializability
●​ Serial Schedule: Operations of each transaction are executed consecutively.
●​ Serializable Schedule: Equivalent to some serial schedule of the same
transactions. Ensures correctness (database remains consistent).
●​ Result Equivalent: Two schedules produce the same final database state.
●​ Conflict Equivalent: The order of any two conflicting operations is the same in
both schedules.
●​ Conflict Serializable: Conflict equivalent to some serial schedule.
●​ Conflict serializability is a sufficient condition for serializability.
●​ Testing for Conflict Serializability:
○​ Construct a Precedence Graph (Serialization Graph):
 ■​ Nodes represent transactions.
■​ A directed edge from Ti to Tj exists if an operation in Ti appears before a
conflicting operation in Tj.
○​ A schedule is conflict serializable if and only if its precedence graph has no
cycles.
●​ View Equivalence: A less restrictive definition of equivalence.
●​ View Serializable: View equivalent to a serial schedule.
●​ Conditions for View Equivalence:
1.​ Same transactions and operations.
2.​ Each read operation reads the result of the same write operation (or original
value) in both schedules.
3.​ The last write operation for each item is the same in both schedules.
●​ Conflict serializability implies view serializability, but not vice versa (especially
with blind writes).
Transaction Support in SQL
●​ A single SQL statement is atomic.
●​ SET TRANSACTION: Specifies transaction characteristics.
○​ Syntax:​
SET TRANSACTION​
[READ ONLY | READ WRITE] -- Access mode​
[DIAGNOSTIC SIZE n] -- Number of conditions in diagnostic area​
[ISOLATION LEVEL {READ UNCOMMITTED | READ COMMITTED | REPEATABLE
READ | SERIALIZABLE}]; -- Isolation level​

●​ Access Mode: READ ONLY (retrieval) or READ WRITE (retrieval and modification).
Default is READ WRITE (unless READ UNCOMMITTED is set, then READ ONLY is
assumed).
●​ Diagnostic Area Size: Number of conditions (errors/exceptions) stored.
●​ Isolation Level: Controls the degree to which a transaction is isolated from
others. Higher levels prevent more concurrency problems but may reduce
performance.
○​ READ UNCOMMITTED: Lowest isolation. Allows dirty reads, nonrepeatable
reads, phantoms.
○​ READ COMMITTED: Prevents dirty reads. Allows nonrepeatable reads,
phantoms.
○​ REPEATABLE READ: Prevents dirty reads and nonrepeatable reads. Allows
phantoms.
○​ SERIALIZABLE: Highest isolation. Prevents dirty reads, nonrepeatable reads,
 and phantoms. Equivalent to serial execution. (Often the default, but some
systems use READ COMMITTED).
●​ Concurrency Problems Allowed at Lower Isolation Levels:
○​ Dirty Read: Reading data written by an uncommitted transaction.
○​ Nonrepeatable Read: Reading the same data item multiple times within a
transaction and getting different values.
○​ Phantoms: A transaction reads a set of rows, and another transaction inserts
new rows that match the read condition, which the first transaction might
then see (or not see consistently). Solution: Table locks or predicate locking.