Normalization ও Denormalization

আপনার বাড়ির ফোনবুকে যদি প্রতিটি বন্ধুর সাথে তার ঠিকানা, পরিবার, অফিস সব পাশে লেখা থাকে - পরিবার পরিবর্তন হলে সব 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:

• 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 না।

২. 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 কম।

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

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

• 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 স্পষ্ট রাখুন।