DBMS – UNIT 2
MOST DETAILED • CLEAR • EXAM-READY NOTES
Topics covered: 3NF & BCNF • Decomposition using Functional Dependencies • B+ Tree Indexes • Triggers •
Stored Procedures • Recursive Queries • Hashing
1. 3NF AND BCNF WITH ALGORITHMS AND SUITABLE
EXAMPLES
1.1 Normalization – Introduction
Normalization is a systematic technique used to organize the attributes and relations of a database. Its main
purpose is to reduce unnecessary duplication of data and prevent anomalies that occur when data is inserted,
updated or deleted.
Why normalization is needed
Consider a table that stores Student_ID, Student_Name, Dept_ID, Dept_Name and Dept_HOD for every
student. If 500 students belong to the same department, the department name and HOD may be repeated 500
times. This causes redundancy and can create inconsistencies.
Anomaly
Meaning
Insertion anomaly
Cannot insert some information without unrelated
Cannot
information
store a new department until a student exists
Example
Update anomaly
Same fact must be changed in many rows Changing a department HOD in many student rows
Deletion anomaly
Deleting one fact accidentally removes another
Deleting the last student may remove department information
Goal: Decompose relations so that redundancy is reduced while important dependencies and information are
preserved.
1.2 Functional Dependency
A functional dependency is a constraint between two sets of attributes. X → Y means that the value of X uniquely
determines the value of Y.
Example: Student_ID → Student_Name. If Student_ID is 101, there can be only one corresponding
Student_Name for that student.
Terms: X is the determinant; Y is the dependent attribute.
Trivial FD: X → Y is trivial when Y is a subset of X. Example: {Student_ID, Name} → Name.
Non-trivial FD: X → Y is non-trivial when Y is not a subset of X. Example: Student_ID → Name.
1.3 THIRD NORMAL FORM (3NF)
Formal definition: A relation R is in Third Normal Form if, for every non-trivial functional dependency X → A, at
least one of the following is true:
• X is a super key.
• A is a prime attribute, meaning A is part of at least one candidate key.
Easy interpretation: In 3NF, a non-key attribute should not depend on another non-key attribute in a way that
creates a transitive dependency.
DBMS Unit 2 – Detailed Notes | Page 1
3NF – Detailed Example
Consider:
STUDENT(Student_ID, Student_Name, Dept_ID, Dept_Name)
Functional dependencies:
1. Student_ID → Student_Name, Dept_ID
2. Dept_ID → Dept_Name
Step 1 – Find the candidate key: Student_ID determines Student_Name and Dept_ID. Dept_ID determines
Dept_Name. Therefore Student_ID determines every attribute, so Student_ID is a candidate key.
Step 2 – Identify transitive dependency: Student_ID → Dept_ID and Dept_ID → Dept_Name. Therefore
Student_ID indirectly determines Dept_Name through Dept_ID. This is a transitive dependency.
Step 3 – Decompose:
STUDENT(Student_ID, Student_Name, Dept_ID)
DEPARTMENT(Dept_ID, Dept_Name)
Step 4 – Check: Student_ID is the key of STUDENT. Dept_ID is the key of DEPARTMENT. The department
name is now stored only once.
Result: The decomposition removes the transitive dependency and gives a better normalized design.
1.4 3NF SYNTHESIS ALGORITHM
Purpose: The synthesis algorithm constructs a dependency-preserving 3NF decomposition from a set of
functional dependencies.
Step 1: Find a minimal/canonical cover F of the given functional dependencies.
Step 2: For every FD X → A in F, create a relation schema containing X ∪ {A}. If several dependencies have the
same left side, they can be grouped.
Step 3: Check whether one of the created relations contains a candidate key of the original relation. If not, create
an additional relation containing a candidate key.
Step 4: Remove redundant relations whose attributes are completely contained in another relation.
Important property: The standard 3NF synthesis algorithm is designed to provide a lossless-join and
dependency-preserving decomposition.
1.5 BOYCE-CODD NORMAL FORM (BCNF)
Definition: A relation R is in BCNF if, for every non-trivial functional dependency X → Y that holds in R, X is a
super key of R.
Key idea: Every determinant must be a candidate key or a super key.
BCNF is stricter than 3NF. Therefore every BCNF relation is in 3NF, but a 3NF relation may not be in BCNF.
BCNF – Detailed Example
Consider:
TEACH(Student, Course, Instructor)
Assume the following FDs:
1. Course → Instructor
2. Instructor → Course
Step 1 – Find candidate keys: Student is needed because neither Course nor Instructor determines Student.
Therefore (Student, Course) and (Student, Instructor) can be candidate keys.
Step 2 – Check Course → Instructor: Course alone is not a super key because it does not determine Student.
Therefore this FD violates BCNF.
DBMS Unit 2 – Detailed Notes | Page 2
Step 3 – Decompose:
R1(Course, Instructor)
R2(Student, Course)
Step 4 – Check R1: Course → Instructor and Course is a key of R1. Hence R1 is in BCNF.
Step 5 – Check R2: There is no non-trivial violating FD, so R2 is in BCNF.
1.6 BCNF DECOMPOSITION ALGORITHM
Step 1: Start with relation R and its set of FDs F.
Step 2: Check whether every non-trivial FD X → Y has X as a super key.
Step 3: If yes, R is in BCNF and stop.
Step 4: If an FD X → Y violates BCNF, decompose R into:
R1 = X ∪ Y
R2 = R − (Y − X)
Step 5: Apply the same test recursively to R1 and R2.
Step 6: Stop when every resulting relation is in BCNF.
1.7 3NF VS BCNF
Feature
3NF
BCNF
Main condition
For X → A, X is super key OR A is prime
For X → Y, X must be a super key
Strictness
Less strict
More strict
Redundancy
Reduced
Usually reduced further
Dependency preservation
3NF synthesis preserves dependencies
BCNF decomposition may lose dependency preservation
Relationship
A BCNF relation is always 3NF
A 3NF relation may not be BCNF
Exam conclusion: 3NF provides a practical balance between normalization and dependency preservation.
BCNF removes more redundancy but may sacrifice dependency preservation in some cases.
DBMS Unit 2 – Detailed Notes | Page 3
2. DECOMPOSITION USING FUNCTIONAL DEPENDENCIES
2.1 Definition
Decomposition is the process of splitting a large relation into smaller relations based on functional
dependencies. The aim is to reduce redundancy and anomalies without losing information.
Why decomposition is performed: to achieve higher normal forms, reduce repeated data, improve consistency
and simplify maintenance.
2.2 Important Properties
A. Lossless-Join Decomposition
A decomposition is lossless if joining the decomposed relations gives exactly the original relation. It must not
lose valid information and must not create spurious tuples.
For a binary decomposition R → R1 and R2, a common test is: if (R1 ∩ R2) functionally determines all attributes
of R1 or all attributes of R2 under F+, the decomposition is lossless.
B. Dependency Preservation
A decomposition is dependency preserving if the original functional dependencies can be enforced by checking
the decomposed relations individually, without performing joins.
2.3 Worked Example – Decomposition
Original relation:
EMPLOYEE(Emp_ID, Emp_Name, Dept_ID, Dept_Name, Dept_Location)
FDs:
Emp_ID → Emp_Name, Dept_ID
Dept_ID → Dept_Name, Dept_Location
Step 1: Emp_ID is a key because it determines the employee details and Dept_ID.
Step 2: Dept_ID determines Dept_Name and Dept_Location. Therefore these attributes depend on Dept_ID
rather than directly on the employee.
Step 3: This creates a transitive dependency from Emp_ID through Dept_ID.
Step 4 – Decompose:
EMPLOYEE(Emp_ID, Emp_Name, Dept_ID)
DEPARTMENT(Dept_ID, Dept_Name, Dept_Location)
Step 5 – Check common attribute: Dept_ID occurs in both relations. It is the primary key of DEPARTMENT
and the foreign key in EMPLOYEE.
Step 6 – Result: Department details are stored once and can be joined whenever required.
2.4 General Decomposition Procedure
1. Write the original relation and all FDs.
2. Determine candidate keys.
3. Identify dependencies that violate the desired normal form.
4. Choose a violating FD X → Y.
5. Create one relation containing X ∪ Y.
6. Put the remaining attributes together with X in another relation.
7. Check whether the decomposition is lossless.
8. Check whether dependencies are preserved.
9. Continue decomposing if any relation still violates the required normal form.
DBMS Unit 2 – Detailed Notes | Page 4
2.5 Small Numerical-Style Example
Let R(A, B, C) have FD B → C. Suppose B is not a key of R.
Because B → C violates BCNF, create:
R1(B, C)
R2(A, B)
R1 stores the dependency B → C. R2 retains the remaining attribute A and the common attribute B.
Important exam terms: lossless join, dependency preservation, functional dependency, candidate key, super
key and spurious tuple.
DBMS Unit 2 – Detailed Notes | Page 5
3. B+ TREE INDEX – INSERTION AND DELETION
3.1 Definition
A B+ tree is a height-balanced tree-based index used by database systems to locate records efficiently. It is
especially useful for disk-based storage because one node can contain many keys, reducing the number of
levels and disk accesses.
Why B+ trees are used in DBMS: They support fast equality searches, efficient ordered traversal and very
efficient range queries.
3.2 Structure and Properties
• Internal nodes contain separator/search keys and pointers to child nodes.
• Leaf nodes contain search keys and record pointers (or actual data entries depending on implementation).
• All leaf nodes are at the same depth.
• Leaf nodes are connected using sibling pointers.
• The tree remains balanced after insertion and deletion.
General diagram:
ROOT [ 30 | 60 ] / | \ / | \ [10|20] -> [30|40|50] -> [60|70|80] LEAF LEAF LEAF
Leaf links make a range query such as 30 ≤ key ≤ 70 efficient because the DBMS can move through the linked
leaves sequentially.
3.3 Search Operation
To search for a key, start at the root, compare the key with separator values, follow the correct child pointer, and
continue until the required leaf is reached. Then search the leaf for the key.
3.4 Insertion – Step-by-Step Example
For illustration, assume each leaf can hold a maximum of two keys. Insert: 10, 20, 30, 40, 50.
Step 1: Insert 10
[10]
Step 2: Insert 20
[10 | 20]
Step 3: Insert 30
The leaf becomes [10 | 20 | 30], which exceeds the maximum. Split the leaf into two leaves. Copy the first key of
the right leaf to the parent as the separator.
[20] / \ [10] [20|30]
Step 4: Insert 40
[20] / \ [10] [20|30|40]
The right leaf now overflows, so split it.
Step 5: Insert 50 and split
[20 | 40] / | \ [10] [20|30] [40|50]
Final tree: The root has separator keys 20 and 40, and three linked leaf nodes hold the actual entries.
3.5 Insertion Algorithm
1. Search for the correct leaf node.
2. Insert the key in sorted order.
3. If the leaf does not overflow, stop.
DBMS Unit 2 – Detailed Notes | Page 6
4. If it overflows, split the leaf into two nodes.
5. Copy a separator key to the parent.
6. If the parent overflows, split the parent too.
7. If the root splits, create a new root.
3.6 Deletion – Step-by-Step
Consider:
[20 | 40] / | \ [10] [20|30] [40|50]
Delete 50:
[20 | 40] / | \ [10] [20|30] [40]
If [40] now has fewer than the minimum required entries, first check a neighboring leaf. If a sibling has an extra
entry, redistribute it and update the parent separator.
If redistribution is impossible: Merge the underfull leaf with a sibling and remove/update the corresponding
separator in the parent.
Deletion algorithm: 1. Locate the key. 2. Delete it from the leaf. 3. Check minimum occupancy. 4. Redistribute
from a sibling if possible. 5. Otherwise merge. 6. Update the parent. 7. If the root becomes unnecessary, reduce
the tree height.
3.7 Advantages of B+ Tree
• Balanced search structure.
• Fast search, insertion and deletion.
• Excellent range-query performance because leaves are linked.
• Large branching factor reduces tree height.
• Suitable for secondary indexes and disk-based databases.
DBMS Unit 2 – Detailed Notes | Page 7
4. TRIGGERS, STORED PROCEDURES AND RECURSIVE
QUERIES
4.1 TRIGGERS
Definition: A trigger is a stored database program that automatically executes when a specified event occurs on
a table or view.
Common triggering events: INSERT, UPDATE and DELETE.
Timing: BEFORE or AFTER the event. Some DBMSs also support INSTEAD OF triggers, especially for views.
Example scenario: Whenever an employee's salary changes, automatically insert an entry into Salary_Audit.
Illustrative SQL:
CREATE TRIGGER salary_audit
AFTER UPDATE ON Employee
FOR EACH ROW
INSERT INTO Salary_Audit VALUES (...);
Uses: auditing, enforcing automatic rules, maintaining history, validating changes and recording important
events.
Advantages: automatic execution, centralized enforcement and useful for auditing.
Disadvantages: hidden side effects can make debugging harder; excessive triggers can complicate database
maintenance.
4.2 STORED PROCEDURES
Definition: A stored procedure is a named collection of SQL statements stored inside the database and
executed explicitly when called.
Illustrative SQL:
CREATE PROCEDURE GetStudent(IN sid INT)
BEGIN
SELECT *
FROM Student
WHERE Student_ID = sid;
END;
The procedure accepts Student_ID as input and returns the corresponding student record.
Advantages: reusable, reduces repeated SQL code, centralizes business logic, supports parameters and can
reduce repeated network communication.
4.3 TRIGGER VS STORED PROCEDURE
Feature
Trigger
Stored Procedure
Execution
Automatic
Explicitly called
Starts because of
INSERT/UPDATE/DELETE or supported event
Application/user calls it
Typical use
Audit and automatic rules
Parameters
Usually not called with parameters like a procedure
Can accept input/output parameters
Business operations and reusable SQL
4.4 RECURSIVE QUERIES
Definition: A recursive query is a query that refers to its own previous result to process hierarchical or graph-like
data.
DBMS Unit 2 – Detailed Notes | Page 8
Applications: employee-manager hierarchy, organizational charts, folder/subfolder structures, category trees
and bill-of-materials structures.
Recursive CTE structure:
WITH RECURSIVE name AS (
-- anchor member
SELECT ...
UNION ALL
-- recursive member
SELECT ... FROM name ...
)
SELECT * FROM name;
Example table:
Emp_ID
Name
Manager_ID
1
Director
NULL
2
Manager A
1
3
Manager B
1
4
Employee X
2
5
Employee Y
2
Goal: Display the complete hierarchy beginning with the Director.
Illustrative recursive query:
WITH RECURSIVE EmployeeTree AS (
SELECT Emp_ID, Name, Manager_ID
FROM Employee
WHERE Manager_ID IS NULL
UNION ALL
SELECT e.Emp_ID, e.Name, e.Manager_ID
FROM Employee e
JOIN EmployeeTree t
ON e.Manager_ID = t.Emp_ID
)
SELECT * FROM EmployeeTree;
How it works: The anchor query selects Director. The recursive query finds employees whose Manager_ID
equals the ID of a previously found employee. It continues level by level until no new employees are found.
Important: Exact recursive SQL syntax varies between database systems; the concept is the same.
DBMS Unit 2 – Detailed Notes | Page 9
5. HASHING
5.1 Definition
Hashing is an indexing technique in which a search-key value is transformed by a hash function into a bucket
number. The bucket tells the DBMS where to look for the record.
Basic formula:
bucket = h(key)
Example: Let h(k) = k MOD 10. Then:
23 → 23 MOD 10 = 3
53 → 53 MOD 10 = 3
Both keys go to bucket 3, so a collision occurs.
5.2 Hash Table Example
Bucket
Keys / Records
0
20, 40
1
31
2
12
3
23, 53
4
14
5
35
The table above demonstrates that multiple keys may be mapped to the same bucket.
5.3 Collision
Definition: A collision occurs when two or more different search keys produce the same hash value.
Example: h(23)=3 and h(53)=3. Therefore 23 and 53 collide.
5.4 Collision Resolution
A. Separate Chaining
Each bucket points to a chain/list containing all records assigned to that bucket.
Bucket 3 ---> [23] ---> [53] ---> NULL
B. Open Addressing
All records are stored in the hash table itself. If the calculated slot is occupied, another slot is searched using a
probing method.
Common probing methods: linear probing, quadratic probing and double hashing.
Linear probing example: If bucket 3 is occupied, check bucket 4, then bucket 5, and so on until an empty slot is
found.
5.5 Static and Dynamic Hashing
Type
Explanation
Static hashing
Number of buckets is fixed. Performance may degrade as data grows.
Dynamic hashing
Number of buckets can change as the database grows.
DBMS Unit 2 – Detailed Notes | Page 10
Type
Explanation
Extendible hashing
Uses a directory and bucket splitting; directory depth may increase.
Linear hashing
Splits buckets gradually instead of doubling the entire structure at once.
5.6 Extendible Hashing – Basic Idea
Extendible hashing uses a directory whose entries point to buckets. When a bucket overflows, it may be split. If
necessary, the directory is expanded. This allows the hash structure to grow dynamically.
5.7 Hashing vs B+ Tree
Feature
Hashing
B+ Tree
Exact-match search
Very fast
Very fast
Range search
Generally poor
Excellent
Ordering
Not maintained
Keys are ordered
Structure
Buckets
Balanced tree
Typical use
Equality-based lookup
Indexes and range queries
Exam conclusion: Hashing is ideal when queries mainly use equality conditions such as WHERE Student_ID =
101. B+ trees are preferable when ordered and range queries are important.
DBMS Unit 2 – Detailed Notes | Page 11
UNIT 2 – COMPLETE QUICK REVISION
Topic
Core point
Key exam words
Normalization
Reduces redundancy and anomalies
1NF, 2NF, 3NF, BCNF
3NF
X is super key OR RHS is prime
Transitive dependency
BCNF
Every determinant is a super key
Stricter than 3NF
Decomposition
Split relations carefully
Lossless join, dependency preservation
B+ Tree
Balanced multi-level index
Leaves linked, split, merge
Trigger
Automatic database action
INSERT, UPDATE, DELETE
Procedure
Named stored program
CALL / parameters
Recursive Query
Processes hierarchy repeatedly
Anchor + recursive member
Hashing
Key mapped to bucket
Hash function, collision
How to write an 8–10 mark answer: Start with the definition → explain the concept → draw the relevant
diagram/table → give a suitable example → show the algorithm/steps → mention advantages or properties →
finish with a short conclusion.
END OF UNIT 2
DBMS Unit 2 – Detailed Notes | Page 12