diff --git a/app/sem4/dbms/content/chapter4.tsx b/app/sem4/dbms/content/chapter4.tsx
new file mode 100644
index 0000000..f73052d
--- /dev/null
+++ b/app/sem4/dbms/content/chapter4.tsx
@@ -0,0 +1,146 @@
+export const Ch4Content = () => {
+ return (
+
+
+ Normalization is the process of
+ organizing a database to reduce redundancy and improve data integrity by
+ breaking large tables into smaller, well-structured ones.
+
+
+
+
+
+
+ Why Normalize?
+
+
+ - Insertion Anomaly: cannot add data without unrelated data. Example: can't add a course unless a student is enrolled.
+ - Deletion Anomaly: deleting one record accidentally removes other useful data.
+ - Update Anomaly: updating one value requires changing it in many places.
+ - Normalization solves all three by removing redundant data dependencies.
+
+
+
+
+
+
+
+ Functional Dependency
+
+
+ - A Functional Dependency (FD) means one attribute determines another. Written as A → B.
+ - Example: StudentID → StudentName (knowing the ID tells you the name).
+ - Partial Dependency: a non-key attribute depends on part of a composite primary key.
+ - Transitive Dependency: a non-key attribute depends on another non-key attribute.
+
+
+
Exam Tip: FDs are the foundation of all normal forms. Master them first.
+
+
+
+
+
+
+ 1NF — First Normal Form
+
+
+ - A table is in 1NF if every column contains atomic (indivisible) values.
+ - No repeating groups or arrays in a single column.
+ - Each row must be unique (has a primary key).
+
+
+
Violation → Fix
+
{`❌ Not 1NF:
+StudentID | Courses
+101 | DBMS, OS, CN
+
+✅ 1NF:
+StudentID | Course
+101 | DBMS
+101 | OS
+101 | CN`}
+
+
+
+
+
+
+ 2NF — Second Normal Form
+
+
+ - Must be in 1NF.
+ - No partial dependencies — every non-key attribute must depend on the entire primary key.
+ - Applies only when the primary key is composite.
+
+
+
Violation → Fix
+
{`❌ Not 2NF (PK = StudentID + CourseID):
+StudentID | CourseID | StudentName | Grade
+101 | CS401 | Zubair | A
+
+StudentName depends only on StudentID (partial dependency).
+
+✅ 2NF: Split into two tables:
+Students(StudentID, StudentName)
+Enrollments(StudentID, CourseID, Grade)`}
+
+
+
+
+
+
+ 3NF — Third Normal Form
+
+
+ - Must be in 2NF.
+ - No transitive dependencies — non-key attributes must not depend on other non-key attributes.
+
+
+
Violation → Fix
+
{`❌ Not 3NF:
+StudentID | DeptID | DeptName
+101 | D01 | CSE
+
+DeptName depends on DeptID (not on StudentID) — transitive.
+
+✅ 3NF: Split:
+Students(StudentID, DeptID)
+Departments(DeptID, DeptName)`}
+
+
+
+
+
+
+ BCNF — Boyce-Codd Normal Form
+
+
+ - A stricter version of 3NF.
+ - For every FD A → B, A must be a superkey.
+ - Handles cases where 3NF still has anomalies due to overlapping candidate keys.
+
+
+
If a table is in BCNF, it is also in 3NF — but not vice versa. BCNF is stronger.
+
+
+
+
+
+
+ Decomposition
+
+
+ - Lossless Join: splitting a table and rejoining gives back the original data exactly.
+ - Dependency Preservation: all original FDs can still be checked in the decomposed tables.
+ - BCNF decomposition always gives lossless joins but may lose dependency preservation.
+ - 3NF decomposition preserves both lossless join and dependency preservation.
+
+
+
+
+ A transaction is a sequence of
+ database operations treated as a single unit. Concurrency control ensures
+ multiple transactions run simultaneously without conflicts.
+
+
+
+
+
+
+ ACID Properties
+
+
+ - Atomicity: all operations succeed, or none do. No partial execution.
+ - Consistency: the database moves from one valid state to another.
+ - Isolation: concurrent transactions do not interfere with each other.
+ - Durability: once committed, changes persist even after a crash.
+
+
+
Exam Tip: ACID is one of the most asked topics. Remember all four with the mnemonic: All Changes Isolated & Durable.
+
+
+
+
+
+
+ Transaction States
+
+
+ - Active: transaction is currently executing.
+ - Partially Committed: last operation executed, not yet written to disk.
+ - Committed: all changes written permanently to the database.
+ - Failed: normal execution cannot continue.
+ - Aborted: transaction rolled back; database restored to previous state.
+
+
+
State Flow
+
{`Active → Partially Committed → Committed
+Active → Failed → Aborted`}
+
+
+
+
+
+
+ Concurrency Problems
+
+
+ - Lost Update: two transactions read and update the same data; one update overwrites the other.
+ - Dirty Read: a transaction reads data written by another transaction that has not committed yet.
+ - Unrepeatable Read: a transaction reads the same row twice and gets different values because another transaction updated it.
+ - Phantom Read: a transaction re-executes a query and finds new rows added by another transaction.
+
+
+
+
+
+
+
+ Locking
+
+
+ - Shared Lock (S): allows reading. Multiple transactions can hold a shared lock simultaneously.
+ - Exclusive Lock (X): allows reading and writing. Only one transaction can hold it; no other locks allowed.
+ - A transaction must acquire the appropriate lock before accessing data.
+
+
+
+
+
+
+
+ Two-Phase Locking (2PL)
+
+
+ - A protocol to ensure serializability (correct concurrent execution).
+ - Growing Phase: locks are acquired; no lock is released.
+ - Shrinking Phase: locks are released; no new lock is acquired.
+ - 2PL guarantees conflict serializability but can cause deadlocks.
+
+
+
Once a transaction releases its first lock, it enters the shrinking phase and cannot acquire new locks.
+
+
+
+
+
+
+ Deadlock
+
+
+ - A deadlock occurs when two or more transactions wait for each other to release locks — forming a cycle.
+ - Detection: use a wait-for graph; a cycle means deadlock.
+ - Prevention: use timestamps (wait-die or wound-wait schemes).
+ - Recovery: abort one transaction (the victim) to break the cycle.
+
+
+
Deadlock Example
+
{`T1 holds Lock(A), waits for Lock(B)
+T2 holds Lock(B), waits for Lock(A)
+→ Deadlock! Neither can proceed.`}
+
+
+
+
+
+
+ Timestamp-Based Concurrency Control
+
+
+ - Each transaction is assigned a unique timestamp when it starts.
+ - Operations are ordered by timestamp to ensure serializability.
+ - Wait-Die: older transaction waits; younger is aborted (dies).
+ - Wound-Wait: older transaction aborts the younger (wounds it); younger waits if it's older.
+
+
+
+
+ Indexing and{" "}
+ Hashing are techniques used to
+ speed up data retrieval in large databases without scanning every row.
+
+
+
+
+
+
+ Why Indexing?
+
+
+ - Without an index, every query scans the entire table — slow for large data.
+ - An index is like a book's table of contents — it points directly to the data.
+ - Indexes speed up SELECT queries but slightly slow down INSERT, UPDATE, DELETE.
+ - Created using:
CREATE INDEX idx_name ON table(column);
+
+
+
+
+
+
+
+ Types of Indexes
+
+
+ - Primary Index: built on the primary key of an ordered file. One entry per data block.
+ - Secondary Index: built on non-primary key fields. Points to exact records.
+ - Clustering Index: records are physically ordered by the indexed field.
+ - Dense Index: one index entry for every record in the file.
+ - Sparse Index: one index entry per block, not per record. Requires ordered data.
+
+
+
Dense index is faster to search but uses more space. Sparse index saves space but requires the file to be sorted.
+
+
+
+
+
+
+ B-Tree and B+ Tree
+
+
+ - Most databases use B+ Trees for indexing.
+ - B-Tree: stores data in both internal nodes and leaf nodes.
+ - B+ Tree: stores data only in leaf nodes; internal nodes store only keys for navigation.
+ - Leaf nodes in B+ Tree are linked — great for range queries.
+ - All operations (search, insert, delete) take O(log n) time.
+
+
+
B+ Tree Structure
+
{`Internal nodes: [10 | 20 | 30]
+ / | | \\
+Leaf nodes: [5,8] [12,15] [22,25] [35,40]
+ ↔ ↔ ↔ ↔ (linked)`}
+
+
+
+
+
+
+ Hashing
+
+
+ - Hashing maps a key value directly to a bucket (storage location) using a hash function.
+ - Best for exact match queries — not range queries.
+ - Static Hashing: fixed number of buckets. Can cause overflow if data grows.
+ - Dynamic Hashing (Extendible Hashing): buckets grow and split as data increases.
+ - Collision: two keys map to the same bucket — handled by chaining or open addressing.
+
+
+
Use indexing (B+ Tree) for range queries. Use hashing for fast exact lookups.
+
+
+
+ Query Processing is how the DBMS
+ takes a SQL query, understands it, and executes it efficiently.{" "}
+ Query Optimization selects the
+ most efficient execution plan.
+
+
+
+
+
+
+ Steps in Query Processing
+
+
+ - Parsing: the SQL query is checked for syntax errors and converted into a parse tree.
+ - Translation: the parse tree is converted into relational algebra expressions.
+ - Optimization: the query optimizer picks the most efficient execution plan.
+ - Execution: the chosen plan is executed and results are returned.
+
+
+
Query Processing Pipeline
+
{`SQL Query
+ ↓ Parser
+Parse Tree
+ ↓ Translator
+Relational Algebra Expression
+ ↓ Optimizer
+Execution Plan
+ ↓ Evaluator
+Query Result`}
+
+
+
+
+
+
+ Query Cost Estimation
+
+
+ - Cost is measured in terms of disk I/O, CPU time, and memory usage.
+ - Disk I/O dominates — the optimizer minimizes the number of disk reads/writes.
+ - The optimizer uses statistics (number of rows, distinct values, index availability) to estimate cost.
+
+
+
+
+
+
+
+ Join Algorithms
+
+
+ - Nested Loop Join: for each tuple in the outer relation, scan all tuples in the inner. Simple but slow for large tables.
+ - Block Nested Loop Join: loads blocks instead of tuples — fewer disk reads.
+ - Merge Join: both relations sorted on the join attribute, then merged. Efficient for sorted data.
+ - Hash Join: hash both relations on the join attribute and match buckets. Very efficient for large unsorted data.
+
+
+
Hash Join is generally the fastest for large datasets. Merge Join is best when data is already sorted.
+
+
+
+
+
+
+ Query Optimization Techniques
+
+
+ - Heuristic Optimization: apply rules to rewrite the query into a more efficient form before execution.
+ - Push selections down: apply WHERE filters as early as possible to reduce rows.
+ - Push projections down: select only needed columns early to reduce data size.
+ - Cost-Based Optimization: enumerate multiple plans, estimate their cost, and pick the cheapest.
+
+
+
Heuristic Example
+
{`-- Before optimization (filter happens after join):
+Students ⋈ Enrollments WHERE Students.dept = 'CSE'
+
+-- After optimization (filter before join):
+σ(dept='CSE')(Students) ⋈ Enrollments`}
+
+
+
+ Recovery restores the database to
+ a consistent state after a failure.{" "}
+ Security ensures only authorized
+ users can access or modify data.
+
+
+
+
+
+
+ Types of Failures
+
+
+ - Transaction Failure: logical error or deadlock causes a transaction to abort.
+ - System Failure: power outage or OS crash — data in memory is lost but disk is safe.
+ - Media Failure: disk crash — data on disk is lost. Requires backups.
+
+
+
+
+
+
+
+ Log-Based Recovery
+
+
+ - The DBMS maintains a log file recording every change before it is applied to the database.
+ - Each log record contains: transaction ID, data item, old value, new value.
+ - Undo: if a transaction fails, old values from the log are restored.
+ - Redo: if a committed transaction's changes weren't written to disk, they are reapplied.
+ - Write-Ahead Logging (WAL): log must be written to disk before the actual data change.
+
+
+
WAL is the golden rule of recovery — always log before you change.
+
+
+
+
+
+
+ Checkpoints
+
+
+ - A checkpoint is a point where the DBMS writes all in-memory changes to disk and records this in the log.
+ - During recovery, only transactions after the last checkpoint need to be redone or undone.
+ - Checkpoints reduce recovery time significantly.
+
+
+
Recovery After Crash
+
{`Checkpoint at T=10
+T1 committed at T=8 → already safe, skip
+T2 committed at T=12 → redo (may not be on disk)
+T3 active at crash → undo (was never committed)`}
+
+
+
+
+
+
+ Shadow Paging
+
+
+ - An alternative to log-based recovery.
+ - Maintains two page tables: current and shadow.
+ - Changes go to the current page table. On commit, current replaces shadow.
+ - On failure, just restore the shadow page table — no undo needed.
+ - Simpler than logging but causes fragmentation and is rarely used in modern systems.
+
+
+
+
+
+
+
+ Database Security
+
+
+ - Authentication: verifying who the user is — username and password.
+ - Authorization: controlling what an authenticated user can do.
+ - GRANT: gives a user permission. Example:
GRANT SELECT ON students TO user1;
+ - REVOKE: removes a permission. Example:
REVOKE SELECT ON students FROM user1;
+ - Views as Security: expose only specific columns or rows to certain users.
+
+
+
+
+
+
+
+ SQL Injection
+
+
+ - A common attack where malicious SQL is inserted into an input field to manipulate the database.
+ - Prevention: use prepared statements and parameterized queries — never concatenate raw user input into SQL.
+
+
+
SQL Injection Example
+
{`-- Vulnerable query:
+"SELECT * FROM users WHERE name = '" + input + "'"
+
+-- Attacker enters: ' OR '1'='1
+-- Resulting query (returns all users!):
+SELECT * FROM users WHERE name = '' OR '1'='1'
+
+-- Safe fix (prepared statement):
+SELECT * FROM users WHERE name = ?`}
+
+