WHAT is an anomaly? A situation where the structure of the table forces bad behaviour:
Insert anomaly — you can't record fact A without also knowing unrelated fact B.
Update anomaly — to change one real-world fact you must edit many rows; miss one → inconsistency.
Delete anomaly — deleting one row accidentally destroys an unrelated fact.
WHY do these happen? Because we crammed two independent facts into one row. The fix is always the same recipe: find the dependency that doesn't belong, and split it into its own table. The normal forms just tell you which dependency is the offender.
WHY it only bites composite keys: a partial dependency needs a key with ≥2 columns so a "part" exists. If your key is a single column, you're automatically in 2NF.
WHY stronger than 3NF: 3NF allows a determinant that isn't a superkey as long as the dependent attribute is prime. BCNF removes that loophole.
Recall Feynman: explain to a 12-year-old
Imagine a notebook where, every time a friend visits, you rewrite their full phone number, home address, and birthday on a new line. If your friend moves house, you must hunt down every line and fix the address — miss one and your notebook now disagrees with itself. Normalization says: write each fact in its own little table once. Friends' addresses live in an "Address book", visits live in a "Visit log" that just points to the friend by name. Change an address in one place — done. Each normal form (1, 2, 3, BCNF) is just a stricter rule for "is this fact written in the right book?"
Dekho, normalization ka pura funda ek hi line me hai: har fact database me sirf ek baar store hona chahiye. Jab ek hi fact do jagah likha ho — jaise har enrollment row me student ka naam dobara-dobara — to problem aati hai. Naam change karna ho to saari rows edit karni padti hain (update anomaly), aakhri row delete kar do to naam hi gayab (delete anomaly), aur bina course liye student add hi nahi kar sakte (insert anomaly). Yeh teen anomalies hi sab gadbad ki jadd hain.
Har normal form ek khaas type ki duplication ko maarta hai. 1NF kehta hai cell me ek hi value rakho, list/array nahi. 2NF kehta hai koi non-prime attribute composite key ke part pe depend na kare (partial dependency hatao) — yaad rakho, agar key single column hai to 2NF automatic mil jaata hai. 3NF kehta hai non-prime attribute kisi doosre non-prime attribute pe depend na kare (transitive dependency hatao, jaise EmpID → DeptID → DeptCity). BCNF sabse strict: har determinant ek superkey hona chahiye, koi "prime ho to chhoot" wala loophole nahi.
Yaad rakhne ka simple mantra: "The Key, the Whole Key, and Nothing but the Key." Aur ordering: BCNF ⊂ 3NF ⊂ 2NF ⊂ 1NF — BCNF sabse tight hai. Par ek practical baat: zaroorat se zyada normalize karoge to bahut saare JOIN lagenge aur read slow ho jayega; kabhi-kabhi BCNF dependency-preservation tod deta hai, isliye 3NF aksar real-world ka sweet spot hota hai. Exam me ek classic trap: Teach(Student, Subject, Teacher) with Teacher → Subject — yeh 3NF me hai (kyunki Subject prime hai) par BCNF me nahi (Teacher superkey nahi). Is example ko ratt lo, har jagah poochha jaata hai.
