Data Modeling
- ●Data modeling হলো বাস্তব জগতের জিনিস ও তাদের সম্পর্ককে ডাটাবেস structure-এ সাজানো।
- ●Normalization ডুপ্লিকেট কমায়, denormalization read দ্রুত করে—দুটোর মাঝে trade-off।
- ●NoSQL-এ access pattern দেখে model করা হয়, analytics-এ star schema ব্যবহার হয়।
সমস্যাটা কী?
ভাবো তুমি একটা e-commerce অ্যাপ বানাচ্ছ। তোমার দরকার customer, order, product—এসব রাখা। প্রশ্ন হলো, এগুলো ডাটাবেসে কীভাবে সাজাবে? সব এক table-এ ঢালবে? নাকি আলাদা আলাদা table-এ ভাগ করবে? কাস্টমারের নাম কি প্রতিটা order-এ আবার লিখবে, নাকি একবার customer table-এ রেখে শুধু reference দেবে?
ভুল সিদ্ধান্ত নিলে পরে ভয়াবহ সমস্যা হয়—একই data নানা জায়গায় ভিন্ন থাকে, update করতে গিয়ে কিছু জায়গা বাদ পড়ে, query ধীর হয়। ভালো data modeling এই সমস্যাগুলো শুরুতেই ঠেকায়। এটা ডাটাবেস ডিজাইনের ভিত্তি।
মূল ধারণা
Data Modeling হলো বাস্তব জগতের জিনিস (entity), তাদের বৈশিষ্ট্য (attribute) এবং তাদের পারস্পরিক সম্পর্ক (relationship)-কে এমনভাবে ডাটাবেস structure-এ রূপ দেওয়া যাতে data সঠিকভাবে, দক্ষভাবে রাখা ও query করা যায়।
মূল তিনটি উপাদান:
- Entity: একটা স্বতন্ত্র জিনিস—যেমন Customer, Order, Product। সাধারণত একটা table।
- Attribute: entity-র বৈশিষ্ট্য—যেমন Customer-এর name, email। table-এর column।
- Relationship: entity-দের মধ্যে সংযোগ—যেমন একজন Customer-এর অনেক Order (one-to-many)।
কীভাবে কাজ করে
Relationship-এর ধরন
- One-to-One: একজন user-এর একটা profile।
- One-to-Many: একজন customer-এর অনেক order।
- Many-to-Many: একটা order-এ অনেক product, একটা product অনেক order-এ (সাধারণত একটা junction table দিয়ে সমাধান)।
Normalization
Normalization হলো data-কে এমনভাবে আলাদা table-এ ভাগ করা যাতে duplication না থাকে। যেমন—customer-এর নাম প্রতিটা order-এ না লিখে, শুধু customer_id রাখা; নাম থাকে customer table-এ একবার।
| Order-এর ভিতরে duplication (খারাপ) | Normalized (ভালো) |
|---|---|
| order_id, customer_name, customer_phone | order_id, customer_id |
| একই নাম বহুবার | নাম শুধু customer table-এ |
| নাম বদলালে সব order ঠিক করতে হয় | এক জায়গায় বদলালেই হয় |
সুবিধা—data consistent থাকে, update সহজ। অসুবিধা—query করতে অনেক table join করতে হয়, যা ধীর হতে পারে।
Denormalization
Denormalization উল্টোটা—ইচ্ছাকৃতভাবে কিছু data duplicate রাখা যাতে read দ্রুত হয়, join কমে। যেমন—order table-এ customer_name আবার রেখে দেওয়া, যাতে অর্ডার দেখাতে join লাগে না।
সুবিধা—read দ্রুত। অসুবিধা—data দুই জায়গায়, update করলে দুটোই বদলাতে হয় (inconsistency-র ঝুঁকি)।
এক নজরে
ভাবো একটা স্কুলের ছাত্র-হাজিরা খাতা। Normalization হলো—একটা মূল রেজিস্টারে প্রতিটা ছাত্রের পুরো তথ্য (নাম, ঠিকানা, রোল) একবার লেখা; দৈনিক হাজিরা খাতায় শুধু রোল নম্বর। ঠিকানা বদলালে মূল রেজিস্টারে একবার বদলালেই হলো।
Denormalization হলো—দৈনিক হাজিরা খাতাতেও পুরো নাম-ঠিকানা লিখে রাখা, যাতে খাতা দেখেই সব জানা যায় (দ্রুত), কিন্তু কারো ঠিকানা বদলালে সব খাতায় খুঁজে খুঁজে বদলাতে হবে—না হলে এক খাতায় পুরোনো, আরেক খাতায় নতুন (inconsistency)।
কৌশল: কোন context-এ কীভাবে model করবে
Relational (SQL) — normalize first
SQL ডাটাবেসে সাধারণত আগে normalize করা হয়, join-এর উপর ভরসা করে। data integrity সবচেয়ে গুরুত্বপূর্ণ।
NoSQL — access pattern first
NoSQL (যেমন MongoDB, DynamoDB)-এ ভাবনাটা উল্টো। আগে প্রশ্ন করো—"আমি কীভাবে data query করব?" তারপর সেই query যেন এক জায়গা থেকে দ্রুত হয়, সেভাবে data সাজাও—প্রায়ই denormalized করে একসাথে রাখা হয় (যেমন order-এর ভিতরেই product details embed করা)। এখানে join সাধারণত ব্যয়বহুল বা নেই, তাই access pattern-ই king।
Analytics — Star Schema
Data warehouse-এ জনপ্রিয় star schema: মাঝখানে একটা fact table (যেমন প্রতিটা বিক্রির ঘটনা—amount, quantity) আর চারপাশে কয়েকটা dimension table (product, customer, time, location)। দেখতে তারার মতো। এটা analytics query (যেমন "মাসভিত্তিক region-অনুযায়ী বিক্রি") সহজ ও দ্রুত করে।
কখন কোনটা ব্যবহার করবে
- Normalize করো: transactional system (OLTP), যেখানে data integrity ও ঘন ঘন update জরুরি।
- Denormalize করো: read-heavy system, যেখানে দ্রুত query দরকার ও join ব্যয়বহুল।
- Access pattern দিয়ে model করো: NoSQL ব্যবহার করলে।
- Star schema: analytics ও reporting-এর জন্য।
শুরুতেই অতিরিক্ত denormalize করো না "speed-এর জন্য" ভেবে। duplicate data মানে প্রতিটা update-এ সব কপি ঠিক রাখার দায়িত্ব—একটা মিস হলেই data inconsistent, আর এই bug ধরা কঠিন। আগে পরিষ্কার normalized model বানাও; সত্যিই performance সমস্যা দেখা দিলে তারপর মেপে মেপে denormalize করো।
বাস্তব উদাহরণ
একটা food delivery অ্যাপ তাদের core data (user, restaurant, order) PostgreSQL-এ normalized রাখে—কারণ এখানে consistency জরুরি (order status, payment)। কিন্তু restaurant-এর menu, যা প্রায়ই একসাথে পড়া হয় কিন্তু কম বদলায়, তারা MongoDB-তে denormalized document হিসেবে রাখে—একটা request-এই পুরো menu আসে, join লাগে না। আর রাতে এই সব data একটা warehouse-এ গিয়ে star schema-তে সাজানো হয়, যাতে business টিম দ্রুত sales report পায়।
ইন্টারভিউতে "normalize নাকি denormalize?" জিজ্ঞেস করলে trade-off দিয়ে উত্তর দাও: "Normalize মানে consistent data কিন্তু join-এর খরচ; denormalize মানে দ্রুত read কিন্তু update-এর ঝামেলা ও inconsistency ঝুঁকি। সিদ্ধান্ত নির্ভর করে read-heavy না write-heavy তার উপর।" আর NoSQL হলে যোগ করো: "NoSQL-এ আগে access pattern, তারপর model।"
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Normalization-এর মূল উদ্দেশ্য কী?
2. NoSQL-এ data model করার সময় সবচেয়ে আগে কী দেখা হয়?
3. Star schema কোথায় ব্যবহার হয়?