From 84f765d699856abf51ab5052caf6ce15b2f251d2 Mon Sep 17 00:00:00 2001 From: MD JUBER QURAISHI Date: Sat, 16 May 2026 07:45:55 +0530 Subject: [PATCH] docs: add DBMS chapter 4 - normalization and chapter 5 - transactions --- app/sem4/dbms/content/chapter4.tsx | 146 +++++++++++++++++++++++++++++ app/sem4/dbms/content/chapter5.tsx | 126 +++++++++++++++++++++++++ 2 files changed, 272 insertions(+) create mode 100644 app/sem4/dbms/content/chapter4.tsx create mode 100644 app/sem4/dbms/content/chapter5.tsx 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.
    • +
+
+
+ ); +}; \ No newline at end of file diff --git a/app/sem4/dbms/content/chapter5.tsx b/app/sem4/dbms/content/chapter5.tsx new file mode 100644 index 0000000..aa54577 --- /dev/null +++ b/app/sem4/dbms/content/chapter5.tsx @@ -0,0 +1,126 @@ +export const Ch5Content = () => { + return ( +
+

+ 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.
    • +
+
+
+ ); +}; \ No newline at end of file