🛒 ডেটাবেস নর্মালাইজেশন

১. 1NF (এক ঘরে একজন)

সমস্যা: এক সেলের ভেতর কমা দিয়ে অনেকগুলো নাম লেখা (যেমন: SQL, Java, PHP)।

সমাধান: প্রতিটা ঘরে মাত্র একটা ডেটা থাকবে। একের অধিক সাবজেক্ট থাকলে আলাদা রো (Row) বানান।

মূল কথা: এক রুমে একজনই থাকবে, জগাখিচুড়ি করা যাবে না।

২. 2NF (অর্ধেক ভালোবাসা চলবে না)

এটা তখনই চেক করবেন যখন আপনার Primary Key দুইটা কলাম মিলে হয় (যেমন: Student_ID + Course_ID)।

সমস্যা: যদি এমন কোনো কলাম থাকে যা শুধু Course_ID-র ওপর নির্ভর করে, কিন্তু Student_ID-র সাথে তার কোনো সম্পর্ক নেই।

সমাধান: ওই কলামটাকে লাথি দিয়ে বের করে আলাদা টেবিল বানিয়ে দিন।

মূল কথা: যদি জোড়া (Composite) চাবি থাকে, তবে বাকি সব কলামকে ওই দুই চাবির ওপরই নির্ভর করতে হবে। একজনের ওপর নির্ভর করলে হবে না।

৩. 3NF (বন্ধুত্বে দালালি চলবে না)

সমস্যা: ধরুন, ID চেনে Name-কে, আর Name চেনে Address-কে। এখন Address কিন্তু ID-র ওপর সরাসরি নির্ভর না করে Name-এর ওপর দালালি করছে।

সমাধান: এই দালালি বন্ধ করতে Name আর Address-কে আলাদা টেবিলে পাঠিয়ে দিন।

মূল কথা: Non-key কলাম যেন অন্য কোনো Non-key কলামের ওপর নির্ভর না করে। সবাই শুধু “Primary Key”-র গোলাম হবে।

৪. BCNF (বস ইজ অলওয়েজ রাইট)

এটা 3NF-এর বড় ভাই। শর্ত: একটি ফাংশনাল ডিপেন্ডেন্সি $X \rightarrow Y$ হলে, $X$-কে অবশ্যই একটি Super Key হতে হবে।

সমস্যা: ধরুন, টেবিলে এমন একটা কলাম আছে যা প্রাইমারি কি না, কিন্তু সে অন্য কাউকে কন্ট্রোল (Determine) করছে।

সমাধান: যে কন্ট্রোল করবে, তাকে অবশ্যই “বস” (Primary Key/Super Key) হতে হবে। যদি সে বস না হয়, তাকে আলাদা টেবিল দিয়ে বস বানিয়ে দিন।

মূল কথা: টেবিলে যদি কেউ কাউকে চেনে, তবে বাম পাশের মানুষটাকে (Determinant) অবশ্যই টেবিলের বস (Key) হতে হবে।

এক নজরে মনে রাখার ট্রিক:

1. 1NF: সিঙ্গেল ভ্যালু।
2. 2NF: পার্শিয়াল (আংশিক) নির্ভরতা বাদ।
3. 3NF: ভায়া বা দালালি বাদ।
4. BCNF: যে কন্ট্রোল করবে সে-ই বস (Key)।

🚀 N+1 Query Problem

🧐 N+1 সমস্যাটা আসলে কী?

ধরুন, আপনার কাছে ২টা টেবিল আছে: ১. Author (লেখক) २. Books (বই)

আপনি চাইলেন: “সব লেখকের নাম এবং তাদের লেখা বইগুলোর টাইটেল দেখাবেন।”

ভুল উপায় (যেভাবে N+1 তৈরি হয়):

১. প্রথমে আপনি একটা কুয়েরি করলেন সব লেখককে আনতে: SELECT * FROM authors; (এটা হলো 1 নম্বর কুয়েরি)

২. এখন আপনার কাছে ১০ জন লেখক আছে। আপনি একটা লুপ চালালেন তাদের বইগুলো বের করতে:

• লেখক ১ এর জন্য: SELECT * FROM books WHERE author_id = 1;
• লেখক ২ এর জন্য: SELECT * FROM books WHERE author_id = 2;
• … এভাবে ১০ জনের জন্য ১০ বার। (এগুলো হলো N সংখ্যক কুয়েরি)

ফলাফল: ১টা কুয়েরি প্লাস ১০টা কুয়েরি = ১১টা কুয়েরি। এটাই N + 1 সমস্যা। লেখকের সংখ্যা ১০০০ হলে আপনার ডেটাবেসে ১০০১ বার কুয়েরি হবে, যা আপনার ওয়েবসাইটকে স্লো করে দিবে।

❌ কেন এটা খারাপ?

• ডেটাবেসে যত বেশিবার যাতায়াত করবেন, সময় তত বেশি লাগবে।
• সার্ভারের ওপর অনেক চাপ পড়ে।
• অ্যাপ্লিকেশনের পারফরম্যান্স একদম কমে যায়।

✅ সমাধান কী? (Eager Loading)

সমাধান হলো আলাদা আলাদা কুয়েরি না করে JOIN ব্যবহার করা অথবা সব ডেটা একবারে নিয়ে আসা।

১. SQL Join ব্যবহার করে:

SELECT authors.name, books.title FROM authors JOIN books ON authors.id = books.author_id; (এখানে মাত্র ১টা কুয়েরিতেই সব ডেটা চলে আসবে!)

২. ORM (যেমন: Eloquent বা TypeORM) ব্যবহার করলে:

লুপের ভেতর কুয়েরি না করে শুরুতেই with বা include ব্যবহার করা।

• খারাপ: $authors = Author::all(); (পরে লুপে বই খুঁজলে N+1 হবে)
• ভালো: $authors = Author::with('books')->get(); (একবারে সব বইসহ নিয়ে আসবে)

💡 মনে রাখার সহজ বুদ্ধি

• N+1: মার্কেটে গিয়ে ১০টা আইটেম কেনার জন্য ১০ বার বাসায় আসা আর দোকানে যাওয়া। (বোকামি!)
• Solution: একবারে লিস্ট নিয়ে গিয়ে সব আইটেম এক ব্যাগে করে নিয়ে আসা। (বুদ্ধিমান!)

🔗 Database Relationships

রিলেশন বের করার সময় সবসময় উভয় দিক (Both Sides) থেকে চিন্তা করবেন।

১. One-to-One (১ : ১)

সূত্র: একজনের জন্য একটাই।

• উদাহরণ: User এবং User_Profile (অথবা NID)।
• টেস্ট: - একজন ইউজারের কয়টা প্রোফাইল থাকে? -> ১টা।
  • একটা প্রোফাইল কয়জন ইউজারের হয়? -> ১টা।
• টেবিল চেনার উপায়: সাধারণত Profile টেবিলে user_id থাকে এবং সেটা Unique হয়।

২. One-to-Many (১ : M) — সবচাইতে কমন!

সূত্র: একজনের অনেকগুলো, কিন্তু ওই অনেকগুলোর মালিক একজনই।

• উদাহরণ: Customer এবং Orders।
• টেস্ট: - একজন কাস্টমার কয়টা অর্ডার করতে পারে? -> অনেকগুলো (Many)।
  • একটা নির্দিষ্ট অর্ডারের (ID: 501) মালিক কয়জন? -> মাত্র ১ জন (One)।
• টেবিল চেনার উপায়: “Many” এর দিকে (Orders টেবিল) customer_id বা Foreign Key থাকবে।

৩. Many-to-Many (M : M)

সূত্র: উভয় দিকেই “অনেকগুলো” হওয়ার সুযোগ আছে।

• উদাহরণ: Student এবং Course।
• টেস্ট: - একজন স্টুডেন্ট কয়টা কোর্স নিতে পারে? -> অনেকগুলো।
  • একটা কোর্সে (যেমন: SQL) কয়জন স্টুডেন্ট থাকতে পারে? -> অনেকজন।
• টেবিল চেনার উপায়: এখানে ৩টা টেবিল লাগে। মাঝখানে একটা “Bridge Table” বা “Pivot Table” থাকে (যেমন: enrollments) যেখানে দুই টেবিলের ID থাকে।

💡 ইন্টারভিউতে টেবিল দিলে যা করবেন (Action Plan)

যদি ইন্টারভিউয়ার ৫টা টেবিল দেয় (যেমন: Users, Posts, Comments, Categories, Tags):

1. Users <-> Posts: একজন ইউজার অনেক পোস্ট দেয়, কিন্তু একটা পোস্টের লেখক একজন। (One-to-Many)
2. Posts <-> Comments: একটা পোস্টে অনেক কমেন্ট থাকে, একটা কমেন্ট একটা নির্দিষ্ট পোস্টেই হয়। (One-to-Many)
3. Posts <-> Categories: একটা পোস্ট একটা ক্যাটাগরিতে থাকে, এক ক্যাটাগরিতে অনেক পোস্ট থাকে। (One-to-Many)
4. Posts <-> Tags: একটা পোস্টে অনেক ট্যাগ থাকে, আবার একটা ট্যাগ (যেমন: #Tech) অনেক পোস্টে থাকে। (Many-to-Many) -> এখানে একটা মাঝখানের টেবিল লাগবে।

🔥 প্রো-টিপ: Foreign Key কোথায় বসবে?

• One-to-Many: সবসময় “Many” এর ঘরে Foreign Key বসবে। (যেমন: Orders টেবিলে Customer_ID)।
• Many-to-Many: আলাদা নতুন টেবিলে দুইজনের ID বসবে।

🗑️ SQL Delete Rules (Referential Actions)

যখন একটা প্রাইমারি কী ডিলিট করা হয়, তখন তার সাথে যুক্ত ফরেন কীগুলোর ওপর কী প্রভাব পড়বে, তা এই রুলসগুলো ঠিক করে।

১. ON DELETE CASCADE (সাথেই মরব)

লজিক: যদি Parent টেবিলের কোনো রো ডিলিট হয়, তবে তার সাথে যুক্ত Child টেবিলের সব রো অটোমেটিক ডিলিট হয়ে যাবে।

• উদাহরণ: একজন কাস্টমার তার অ্যাকাউন্ট ডিলিট করলে, তার করা সব অর্ডারের ডেটাও ডিলিট হয়ে যাবে।
• ব্যবহার: যখন Child ডেটার কোনো আলাদা অস্তিত্ব থাকার দরকার নেই।

২. ON DELETE SET NULL (এতিম হয়ে যাওয়া)

লজিক: যদি Parent টেবিলের রো ডিলিট হয়, তবে Child টেবিলের ফরেন কী কলামটি NULL হয়ে যাবে। (তবে কলামটি NULL এলাউ করতে হবে)।

• উদাহরণ: আপনার কোম্পানিতে একজন ম্যানেজার ছিল, সে চাকরি ছেড়ে দিয়েছে। এখন ওই প্রজেক্টের ‘Manager_ID’ কলামটি খালি (NULL) হয়ে যাবে, কিন্তু প্রজেক্টের ডেটা ডিলিট হবে না।
• ব্যবহার: যখন ডেটা ডিলিট না করে শুধু সম্পর্কটা বিচ্ছিন্ন করতে চান।

৩. ON DELETE RESTRICT / NO ACTION (বাধা দেওয়া)

লজিক: যতক্ষণ Child টেবিলে কোনো ডেটা থাকবে, ততক্ষণ আপনি Parent টেবিলের ওই রো-টি ডিলিট করতে পারবেন না। ডেটাবেস আপনাকে Error দেখাবে।

• উদাহরণ: আপনি একটি ক্যাটাগরি ডিলিট করতে চাইলেন, কিন্তু ওই ক্যাটাগরির আন্ডারে এখনো ১০টা প্রোডাক্ট আছে। ডেটাবেস আপনাকে বলবে— “আগে প্রোডাক্টগুলো সরান, তারপর ক্যাটাগরি ডিলিট করেন।”
• ব্যবহার: ভুলবশত ইম্পর্ট্যান্ট ডেটা ডিলিট হওয়া থেকে বাঁচতে।

৪. ON DELETE SET DEFAULT (ডিফল্ট ভরসা)

লজিক: Parent রো ডিলিট হলে Child টেবিলের ফরেন কী কলামটি একটি ‘Default Value’ তে সেট হয়ে যাবে।

• উদাহরণ: কোনো একজন টিচার চলে গেলে ওই ক্লাসের ‘Teacher_ID’ অটোমেটিক ‘Admin’ বা ‘TBA’ (To Be Announced) আইডিতে সেট হয়ে যাবে।

💡 এক নজরে সামারি

কোড উদাহরণ (SQL):

CREATE TABLE Orders (
    OrderID int PRIMARY KEY,
    CustomerID int,
    FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
    ON DELETE CASCADE -- এখানে আপনি রুল সেট করেন
);

⚖️ WHERE vs HAVING (পার্থক্য)

📊 GROUP BY এর কাজ কী?

সংজ্ঞা: একই ধরণের ভ্যালু আছে এমন রো গুলোকে একত্রিত করে একটি সামারি (Summary) রেজাল্ট তৈরি করা।

সাধারণত এই ফাংশনগুলোর সাথে এটি ব্যবহার হয়:

• COUNT() : কতগুলো আছে?
• SUM() : মোট কত?
• AVG() : গড় কত?
• MAX() / MIN() : সবচেয়ে বড় বা ছোট কত?

🛠️ কাজের ধাপ:

• ১. SELECT: কোন কলাম অনুযায়ী গ্রুপ করবেন এবং কী হিসাব করবেন তা লিখুন।
• ২. FROM: টেবিলের নাম।
• ৩. WHERE: (অপশনাল) গ্রুপ করার আগে কোনো ডেটা বাদ দিতে চাইলে।
• ৪. GROUP BY: যে কলামের ভিত্তিতে দল বানাবেন।