Part 2 · ডেটাবেস 📖 ১৩ মিনিট পড়া 📝 ২০টি কুইজ

Normalization ও Denormalization

Data redundancy কমানো বনাম read performance বাড়ানো।

📝 কুইজে যান

আপনার বাড়ির ফোনবুকে যদি প্রতিটি বন্ধুর সাথে তার ঠিকানা, পরিবার, অফিস সব পাশে লেখা থাকে — পরিবার পরিবর্তন হলে সব entry আপডেট করতে হবে। ভুলে গেলে inconsistency। Database-এ এই সমস্যাকে বলে data redundancy। সমাধান — Normalization।

Normalization কী?

Database Normalization = একটি টেবিলকে এমনভাবে সাজানো যাতে data redundancy কমে এবং dependencies সঠিক থাকে। এটি ১৯৭০-এর দশকে E.F. Codd-এর প্রস্তাব।

কেন Normalize করব?

  • Data redundancy কম: একই data বারবার নয়।
  • Update anomaly নেই: এক জায়গায় পরিবর্তন = সর্বত্র সঠিক।
  • Insert anomaly নেই: Sub-data ছাড়া new entry করা যায়।
  • Delete anomaly নেই: এক row delete-এ বেশি data হারায় না।
  • Storage saving: Duplicate data নেই।
  • Data integrity: Foreign key এ enforce করা যায়।

Anomalies — Normalization-এর প্রয়োজনীয়তা

একটি বাজে design:

student_courses: +----+--------+--------+----------+----------+ | id | name | course | teacher | tea_phone| +----+--------+--------+----------+----------+ | 1 | Mahfuz | Math | Sir Karim| 0171... | | 2 | Sumi | Math | Sir Karim| 0171... | | 3 | Mahfuz | Physics| Sir Aziz | 0181... | +----+--------+--------+----------+----------+
  • Update anomaly: Sir Karim-এর ফোন পরিবর্তন → ২ row update।
  • Insert anomaly: নতুন course-এ student না থাকলে যোগ করা যায় না।
  • Delete anomaly: Mahfuz delete করলে Sir Aziz-এর তথ্যও হারাবে।

Normal Forms

১. First Normal Form (1NF)

প্রতিটি column-এ atomic value (একক মান) — list/array না।

❌ Not 1NF: | id | name | phones | | 1 | Mahfuz | 0171, 0172, 0173 | ✓ 1NF: | id | name | phone | | 1 | Mahfuz | 0171 | | 1 | Mahfuz | 0172 |

২. Second Normal Form (2NF)

1NF + সব non-key column পুরো primary key-এর উপর depend করতে হবে (partial dependency নেই)।

উপরের student_courses table-এ name (id-র উপর depend), teacher (course-এর উপর depend) — partial dependency। ভাঙতে হবে:

students: | id | name | courses: | course | teacher | tea_phone | enrollments: | student_id | course |

৩. Third Normal Form (3NF)

2NF + non-key column-গুলো একে অপরের উপর depend না (transitive dependency নেই)।

courses table-এ teacher → tea_phone — transitive। ভাঙি:

courses: | course | teacher_id | teachers: | teacher_id | name | phone |

৪. BCNF (Boyce-Codd Normal Form)

3NF-এর strict version — প্রতিটি functional dependency-র left side super key হতে হবে। কম এজ-কেস ছাড়া 3NF-এর সমান।

৫. 4NF, 5NF, 6NF

Multi-valued dependency, join dependency-র জন্য — academically guruttapurno কিন্তু practical use case কম।

💡 Industry rule of thumb: 3NF পর্যন্ত normalize করুন। OLTP system-এ এটাই সঠিক balance।

Denormalization কী?

Denormalization = পরিকল্পিতভাবে কিছু data duplicate করে normalized form ভাঙা — read performance বাড়াতে।

আগের তিনটি table দিয়ে student-course-teacher info পেতে JOIN লাগে। Read-heavy app-এ slow। তাই কিছু field copy করি:

enrollments: | student_id | student_name | course | teacher_name |

এখন এক query-তে সব। কিন্তু teacher-name পরিবর্তন হলে অনেক জায়গায় update লাগবে।

কখন Denormalize করবেন?

  • Read-heavy workload (১:১০০+ ratio)।
  • JOIN performance নিয়ে সমস্যা।
  • Reporting/analytics — historical accuracy যেহেতু লাগে না।
  • NoSQL DB — যেখানে JOIN nei বা expensive।
  • Pre-computed aggregate (counts, totals)।

Trade-off

Normalized

  • Storage কম
  • Update simple
  • Data integrity strong
  • Read = JOIN, slower
  • OLTP-এর জন্য আদর্শ

Denormalized

  • Read fast (single table)
  • Storage বেশি
  • Update complex
  • Inconsistency risk
  • Analytics, NoSQL-এর জন্য

বাস্তব উদাহরণ

  • Banking: Highly normalized — accuracy critical।
  • Twitter timeline: Denormalized — pre-computed, fast read।
  • Data warehouse (Snowflake, BigQuery): Heavily denormalized (star/snowflake schema)।
  • MongoDB: সাধারণত denormalized (embed sub-doc)।

সাধারণ ভুল ধারণা

  1. "যত normalized তত ভালো": না — ৪NF/৫NF সাধারণত overkill।
  2. "Denormalization manei wrong": না — read-heavy app-এ স্বাভাবিক optimization।
  3. "NoSQL-এ normalization লাগে না": Implicit থাকে — schema design-এ।

Best Practices

  • 3NF থেকে শুরু করুন — performance সমস্যা না হলে সেখানেই থাকুন।
  • Denormalize পরিকল্পিতভাবে — measure first।
  • Foreign key constraint enable — referential integrity।
  • Read replica + cache দিয়ে read scale — denormalization-এর আগে চেষ্টা করুন।
  • Denormalization-এ stale data update process স্পষ্ট রাখুন।

📌 চ্যাপ্টার সারমর্ম

  • Normalization = redundancy কমানো (1NF, 2NF, 3NF, BCNF)।
  • Update/Insert/Delete anomaly থেকে রক্ষা করে।
  • Denormalization = read fast করতে সচেতনভাবে duplicate।
  • OLTP → normalized; OLAP/NoSQL → denormalized।
  • Trade-off: storage/integrity vs read speed।