DBMS
Relational databases, SQL, normalization
Database Management Systems (DBMS) is software that enables users to create, manage, and manipulate databases. It provides an interface between users/applications and the database, ensuring data integrity, security, and efficient retrieval through structured query languages like SQL. Understanding DBMS fundamentals is essential for technical interviews and software development roles.
Key formulas and rules
Key concepts
Data Models and Database Architecture
The three-schema architecture consists of: (1) External Level - user views and how data appears to specific users; (2) Conceptual Level - logical structure of the entire database including entities, relationships, and constraints; (3) Internal Level - physical storage structure and access methods. Common data models include: Hierarchical (tree structure), Network (graph structure), Relational (tables with rows and columns), and Object-Oriented. The Relational Model uses tables (relations) where rows are tuples and columns are attributes, with keys (Primary, Foreign, Candidate, Super) defining relationships.
SQL Operations and Query Processing
SQL commands are categorized as: DDL (Data Definition Language) - CREATE, ALTER, DROP, TRUNCATE for schema modification; DML (Data Manipulation Language) - SELECT, INSERT, UPDATE, DELETE for data operations; DCL (Data Control Language) - GRANT, REVOKE for permissions; TCL (Transaction Control Language) - COMMIT, ROLLBACK, SAVEPOINT. Important SQL operations include: JOINs (INNER, LEFT, RIGHT, FULL OUTER, CROSS, SELF), subqueries (correlated and non-correlated), aggregate functions (COUNT, SUM, AVG, MAX, MIN), GROUP BY with HAVING clause, and set operations (UNION, INTERSECT, EXCEPT). Query optimization involves indexes, query rewriting, and understanding execution plans.
Normalization and Functional Dependencies
Normalization is the process of organizing data to reduce redundancy and improve integrity. Functional Dependency (FD): X -> Y means X uniquely determines Y. Closure of attributes (F ) finds all attributes functionally determined by a set. Normal Forms in order: 1NF eliminates repeating groups; 2NF eliminates partial dependencies (non-prime attributes must depend on entire candidate key); 3NF eliminates transitive dependencies; BCNF requires every determinant to be a superkey. Higher forms (4NF, 5NF) handle multi-valued and join dependencies. Decomposition must be lossless (natural join recovers original) and dependency-preserving (all FDs are preserved in decomposed relations).
Transaction Management and Concurrency Control
A transaction is a logical unit of work with ACID properties: Atomicity (all-or-nothing execution), Consistency (valid state transitions), Isolation (concurrent transactions don't interfere), Durability (committed changes persist). Concurrency issues include: Lost Update, Dirty Read, Non-Repeatable Read, Phantom Read. Locking mechanisms: Binary Locks (S/X), Shared/Exclusive Locks, Two-Phase Locking (2PL - growing then shrinking phase ensures serializability). Deadlock handling: Prevention (wait-die, wound-wait), Avoidance (Banker's algorithm), Detection (wait-for graph), Recovery. Timestamp ordering assigns unique timestamps to transactions. Recovery techniques: Deferred Update (redo only), Immediate Update (undo-redo), Shadow Paging, Checkpoints.
Worked examples
Example 1
Given relation R(A, B, C, D) with functional dependencies: A -> B, B -> C, C -> D. Is R in 3NF? If not, decompose to 3NF.
Step 1: Find candidate key.
A = {A, B, C, D} (since A->B, B->C, C->D)
So A is the only candidate key.
Step 2: Check for partial dependencies (2NF).
Since the key is single attribute A, there are no partial dependencies. R is in 2NF.
Step 3: Check for transitive dependencies (3NF).
A -> B and B -> C: This is a transitive dependency (non-prime B determines non-prime C).
B -> C and C -> D: This is another transitive dependency.
So R is NOT in 3NF.
Step 4: Decompose to 3NF using synthesis algorithm.
From A -> B: Create R1(A, B) with key A
From B -> C: Create R2(B, C) with key B
From C -> D: Create R3(C, D) with key C
Step 5: Check if original key is preserved.
Yes, A is in R1.
Final decomposition: R1(A, B), R2(B, C), R3(C, D)
All are in 3NF and dependency-preserving.
Example 2
Two transactions: T1 reads A, writes A; T2 reads A, writes A. Show a schedule that results in Lost Update and explain how 2PL prevents it.
Step 1: Lost Update Example (non-serializable schedule):
Time 1: T1: Read(A) -> A = 100
Time 2: T2: Read(A) -> A = 100
Time 3: T1: A = A + 10, Write(A) -> A = 110
Time 4: T2: A = A + 20, Write(A) -> A = 120
Result: T1's update is lost! Correct should be 130 (100+10+20).
Step 2: How 2PL Prevents This:
In Two-Phase Locking:
- Growing phase: Acquire locks
- Shrinking phase: Release locks (no new locks after first release)
Step 3: 2PL Schedule:
Time 1: T1: Lock-S(A) -> Read(A)
Time 2: T1: Upgrade to Lock-X(A) -> T1 holds exclusive lock
Time 3: T2: Lock-S(A) -> BLOCKED (T1 has X lock)
Time 4: T1: Write(A), Unlock(A)
Time 5: T2: Lock-S(A) granted -> Read(A) gets 110
Time 6: T2: Upgrade to Lock-X(A) -> Write(A) = 130
Result: 2PL ensures serializability. Final value is correct: 130.
Example 3
Given Employee(EID, Name, DeptID, Salary, ManagerID) and Department(DeptID, DName, Location). Write SQL to find employees who earn more than their department's average salary, and explain if an index would help.
Step 1: SQL Query:
SELECT e.EID, e.Name, e.Salary, d.DName
FROM Employee e
JOIN Department d ON e.DeptID = d.DeptID
WHERE e.Salary > (
SELECT AVG(e2.Salary)
FROM Employee e2
WHERE e2.DeptID = e.DeptID
);
Step 2: Alternative with JOIN:
SELECT e.EID, e.Name, e.Salary, d.DName, avg_sal.avg_salary
FROM Employee e
JOIN Department d ON e.DeptID = d.DeptID
JOIN (
SELECT DeptID, AVG(Salary) as avg_salary
FROM Employee
GROUP BY DeptID
) avg_sal ON e.DeptID = avg_sal.DeptID
WHERE e.Salary > avg_sal.avg_salary;
Step 3: Index Analysis:
- Index on Employee(DeptID): Helps join and group by operations, significantly improves correlated subquery
- Index on Employee(Salary): Less helpful here (range comparison after join)
- Composite index on Employee(DeptID, Salary): Most effective - supports both grouping and salary comparison
- Index on Department(DeptID): Helps join (usually primary key, already indexed)
Step 4: Query Plan Considerations:
With proper indexing, optimizer can use index seek for department grouping, avoiding full table scan. The correlated subquery version may be rewritten as join by optimizer.
Representative solved questions
See the kind of question in this topic before opening the full practice set.
Question 1
What does SQL stand for?
Structured Query Language
Simple Query Language
System Query Language
Standard Query Language
Answer: A. Structured Query Language
ExplanationStep 1: SQL is the standard language for relational database management systems.
Step 2: The acronym stands for Structured Query Language.
Step 3: It was originally developed at IBM in the 1970s.
Answer: Structured Query Language
Sources and review notes
This is an AISEA-authored practice question.
Review status: accepted · Reviewed 2026-08-13 · structure and answer-key checks, editorial quality checks, duplicate screening
Question 2
Which SQL statement is used to extract data from a database?
EXTRACT
SELECT
GET
PULL
Answer: B. SELECT
ExplanationStep 1: SQL uses SELECT to query data from tables.
Step 2: The syntax is: SELECT column_name FROM table_name.
Step 3: SELECT * retrieves all columns from the table.
Answer: SELECT
Sources and review notes
This is an AISEA-authored practice question.
Review status: accepted · Reviewed 2026-08-13 · structure and answer-key checks, editorial quality checks, duplicate screening
Question 3
Which SQL clause is used to filter records?
FILTER
WHERE
IF
CONDITION
Answer: B. WHERE
ExplanationStep 1: The WHERE clause filters records based on specified conditions.
Step 2: Syntax: SELECT * FROM table WHERE condition.
Step 3: It is applied after the FROM clause but before GROUP BY.
Answer: WHERE
Sources and review notes
This is an AISEA-authored practice question.
Review status: accepted · Reviewed 2026-08-13 · structure and answer-key checks, editorial quality checks, duplicate screening
Common mistakes and useful habits
- Always identify candidate keys first when analyzing normal forms - every normal form check depends on knowing what the keys are
- For SQL queries involving multiple tables, draw the join diagram mentally: INNER JOIN returns matching rows only, LEFT JOIN returns all from left with NULLs for non-matches
- In transaction questions, check for serializability using precedence graph (conflict serializability) or view equivalence (view serializability)
- Remember: BCNF is stricter than 3NF. A relation in BCNF is automatically in 3NF, but not vice versa. Decomposition to BCNF may lose some functional dependencies
- When calculating index selectivity: High cardinality columns (many unique values) benefit more from B+ tree indexes; low cardinality may favor bitmap indexes
- For ER-to-Relational conversion: 1:N relationships place the '1' side key on the 'N' side; M:N relationships always become a separate table with both keys
Ready to test your understanding?
Work through 194 questions with explanations after each answer.