SQL Foreign Key — সম্পূর্ণ ক্লাস নোট

এবার সংজ্ঞাটা দাঁড় করাই

⏱ শেখার অংশ

এনালজি ধরো, তোমার জাতীয় পরিচয়পত্রের নম্বরটা তোমার ভোটার তালিকা, ব্যাংক অ্যাকাউন্ট, সিম কার্ড রেজিস্ট্রেশন — সব জায়গায় ব্যবহার হয়। প্রতিটা জায়গায় তোমার নাম-ঠিকানা আলাদা করে না লিখে, শুধু NID নম্বরটা রেফারেন্স হিসেবে ব্যবহার করা হয়। ডেটাবেসেও ঠিক এই কাজটাই করে Foreign Key।

Foreign Key হলো একটা টেবিলের এমন একটা কলাম, যেটা অন্য একটা টেবিলের Primary Key-কে রেফারেন্স (নির্দেশ) করে। এর মাধ্যমে দুইটা টেবিলের মধ্যে একটা সম্পর্ক (Relationship) তৈরি হয়, এবং ডেটাবেস নিশ্চিত করে যে এই সম্পর্ক সবসময় বৈধ থাকে — একেই বলে Referential Integrity।

Foreign Key (FK) একটা Child টেবিলের কলাম, যেটা Parent টেবিলের Primary Key (PK)-কে নির্দেশ করে

নিজেকে যাচাই করো

উপরের ডায়াগ্রামে কোনটা Parent Table, কোনটা Child Table?
Orders টেবিলে যদি এমন একটা Customer_ID ঢোকানো হয় যেটা Customers টেবিলে নেই, তাহলে কী হওয়া উচিত?

Primary Key এবং Foreign Key কীভাবে একসাথে কাজ করে

⏱ শেখার অংশ

Primary Key → Foreign Key → Connected Tables

দিক	Primary Key	Foreign Key
উদ্দেশ্য	নিজের টেবিলে প্রতিটা row-কে ইউনিকভাবে চিহ্নিত করা	অন্য টেবিলের একটা row-কে রেফারেন্স করা
অবস্থান	যে টেবিলের নিজস্ব identity, সেখানে (Parent Table)	যে টেবিল সেই identity ব্যবহার করছে, সেখানে (Child Table)
ইউনিকনেস	প্রতিটা ভ্যালু ইউনিক হতে হবে	রিপিট হতে পারে (একই Customer_ID বহু Order-এ থাকতে পারে)
NULL মান	কখনোই NULL নয়	প্রায়ই NULL অনুমোদিত হতে পারে (যদি সম্পর্কটা ঐচ্ছিক হয়)
ডেটাবেস ডিজাইনে ভূমিকা	টেবিলের identity নির্ধারণ করে	টেবিলগুলোর মধ্যে সম্পর্ক (relationship) তৈরি করে

বিজনেস উদাহরণ হাসপাতালে Patients.Patient_ID হলো Primary Key — প্রতিটা রোগীর জন্য একটা ইউনিক নম্বর। আর Appointments.Patient_ID হলো Foreign Key — একজন রোগীর অনেকগুলো অ্যাপয়েন্টমেন্ট থাকতে পারে, প্রতিটাতেই একই Patient_ID রেফারেন্স হিসেবে বসবে।

এক টেবিল অনেকগুলোর সাথে সংযুক্ত

⏱ শেখার অংশ

তিনটা বাস্তব One-to-Many উদাহরণ: একজন থেকে অনেকজনের দিকে সম্পর্ক

প্যাটার্নটা খুঁজে বের করো

প্রতিটা উদাহরণে "১" পক্ষের টেবিলে কী আছে (Primary Key), আর "many" পক্ষের টেবিলে কী আছে (Foreign Key)?
একটা Order কি দুইজন Customer-এর হতে পারে? তাহলে সম্পর্কটা কেন "One-to-Many", "Many-to-Many" নয়?

এবার হাত চালাই — কোড লিখি

⏱ শেখার অংশ

STEP 1 — Parent Table তৈরি

CREATE TABLE Customers (
    Customer_ID   INT PRIMARY KEY,
    Name          VARCHAR(100),
    Phone         VARCHAR(20)
);

EXPECTED OUTPUT

Query OK, 0 rows affected Table 'Customers' created.

লাইন বাই লাইন

Parent Table সবসময় আগে তৈরি করতে হয় — কারণ Child Table এই টেবিলের Primary Key-কে রেফারেন্স করবে, যেটা এখনো তৈরিই হয়নি।

STEP 2 — Child Table তৈরি (Foreign Key সহ)

CREATE TABLE Orders (
    Order_ID      INT PRIMARY KEY,
    Customer_ID   INT,
    Order_Date    DATE,
    FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID)
);

EXPECTED OUTPUT

Query OK, 0 rows affected Table 'Orders' created with foreign key constraint.

লাইন বাই লাইন

FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID) — এই লাইনটা বলছে, Orders টেবিলের Customer_ID কলাম অবশ্যই Customers টেবিলের Customer_ID-এর মধ্যে থেকে একটা বৈধ ভ্যালু হতে হবে।

কমন ভুল

Customers টেবিল তৈরি করার আগেই Orders টেবিল তৈরি করার চেষ্টা করা — এতে Error: Referenced table 'customers' doesn't exist আসবে।

বেস্ট প্র্যাকটিস

Foreign Key কলামের ডেটা টাইপ অবশ্যই Parent টেবিলের Primary Key-এর ডেটা টাইপের সাথে হুবহু মিলতে হবে (যেমন দুটোই INT)।

STEP 3 — ALTER TABLE দিয়ে পরে Foreign Key যোগ করা

ALTER TABLE Orders
ADD CONSTRAINT fk_customer
FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID);

EXPECTED OUTPUT

Query OK, 0 rows affected Records: 0 Duplicates: 0 Warnings: 0

কখন লাগে

যখন টেবিল আগেই তৈরি হয়ে গেছে (Foreign Key ছাড়া), কিন্তু পরে সম্পর্ক যোগ করার দরকার হয় — তখন CREATE-এর বদলে ALTER ব্যবহার করা হয়।

কমন ভুল

টেবিলে আগে থেকেই এমন ডেটা থাকা যেগুলো Foreign Key শর্ত ভঙ্গ করে — তখন ALTER TABLE কমান্ড Error দেবে, যতক্ষণ না সেই ভুল ডেটা ঠিক করা হয়।

বেস্ট প্র্যাকটিস

Constraint-এর একটা নাম দাও (যেমন fk_customer) — পরে সহজে খুঁজে পরিবর্তন বা মুছে ফেলার জন্য।

ডেটাবেস কীভাবে ভুল সম্পর্ক আটকায়

⏱ শেখার অংশ

Referential Integrity: Foreign Key শুধু বৈধ (existing) Primary Key-কেই রেফারেন্স করতে দেয়

প্র্যাকটিক্যাল প্রমাণ — ভুল Customer_ID দিয়ে ইনসার্ট

INSERT INTO Orders VALUES (501, 9999, '2026-07-20');
-- ধরো Customer_ID = 9999 Customers টেবিলে নেই

EXPECTED ERROR

ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`Orders`, CONSTRAINT `fk_customer` FOREIGN KEY (`Customer_ID`) REFERENCES `Customers` (`Customer_ID`))

কেন এই এরর

ডেটাবেস নিজে থেকেই চেক করে দেখেছে Customer_ID = 9999 আসলে Customers টেবিলে নেই — তাই এই "ভুয়া" সম্পর্ক তৈরি হতে দেয়নি। এটাই Referential Integrity-এর আসল কাজ।

প্যারেন্ট রেকর্ড ডিলিট হলে কী হবে?

⏱ শেখার অংশ

প্রশ্ন একজন Customer-কে ডিলিট করলে, তার আগের সব Orders-এর কী হবে? এগুলোও কি ডিলিট হয়ে যাবে? নাকি Customer_ID খালি (NULL) হয়ে যাবে? নাকি ডিলিটই আটকে যাবে?

অপশন	কী ঘটে	বাস্তব উদাহরণ
`CASCADE`	Parent ডিলিট হলে সংশ্লিষ্ট সব Child রেকর্ডও ডিলিট হয়ে যায়	একটা Blog Post ডিলিট হলে তার সব Comment-ও ডিলিট হওয়া
`SET NULL`	Child রেকর্ড থেকে যায়, কিন্তু Foreign Key কলাম NULL হয়ে যায়	একজন Employee চলে গেলে তার পুরনো টাস্কগুলো "Unassigned" হয়ে যাওয়া
`RESTRICT`	Child রেকর্ড থাকলে Parent ডিলিটই করতে দেওয়া হয় না	কোনো Order থাকা অবস্থায় Customer ডিলিট করতে না দেওয়া
`NO ACTION`	RESTRICT-এর মতোই আচরণ (বেশিরভাগ DB-তে)	ডিফল্ট আচরণ যদি কিছু উল্লেখ না করা হয়

উদাহরণ — CASCADE ব্যবহার

FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID)
ON DELETE CASCADE
ON UPDATE CASCADE;

ব্যাখ্যা

এখানে বলা হচ্ছে — Customer ডিলিট হলে তার সব Orders-ও ডিলিট হয়ে যাবে, আর Customer_ID পরিবর্তন হলে Orders-এর Customer_ID-ও স্বয়ংক্রিয়ভাবে আপডেট হবে।

কমন ভুল

না বুঝেই সবক্ষেত্রে CASCADE ব্যবহার করা — এতে ভুলবশত গুরুত্বপূর্ণ ডেটা (যেমন পুরনো Order History) হারিয়ে যেতে পারে।

বেস্ট প্র্যাকটিস

আর্থিক/হিস্টোরিক্যাল ডেটার (Orders, Payments, Invoices) ক্ষেত্রে CASCADE এড়িয়ে RESTRICT বা SET NULL ব্যবহার করাই নিরাপদ।

Online Shopping System

⏱ শেখার অংশ

Customers → Orders → Order_Items ← Products, এবং Orders → Payments — সবকটা Foreign Key দিয়ে সংযুক্ত

একজন কাস্টমারের অর্ডার-যাত্রা

Rafiq সাইন-আপ করে — Customers টেবিলে নতুন row (Customer_ID = 1)।
Rafiq একটা অর্ডার দেয় — Orders টেবিলে নতুন row, যেখানে Customer_ID = 1 (Foreign Key)।
অর্ডারে দুইটা প্রোডাক্ট থাকে — Order_Items-এ দুইটা row, প্রতিটাতে Order_ID ও Product_ID Foreign Key হিসেবে।
Rafiq পেমেন্ট করে — Payments টেবিলে নতুন row, যেখানে Order_ID Foreign Key হিসেবে থাকে।

ক্লাসকে জিজ্ঞেস করো

এই পাঁচটা টেবিলের মধ্যে কোনটা কখনোই Child Table নয় (সবসময় Parent)?
Order_Items টেবিলে কেন দুইটা Foreign Key আছে?

MySQL Workbench / Google Colab-এ ধাপে ধাপে

⏱ শেখার অংশ

STEP 1 — ডেটাবেস তৈরি ও সিলেক্ট

CREATE DATABASE shopping_demo;
USE shopping_demo;

OUTPUT

Query OK, 1 row affected Database changed

STEP 2 — Customers টেবিল তৈরি

CREATE TABLE Customers (
    Customer_ID INT PRIMARY KEY,
    Name        VARCHAR(100),
    Phone       VARCHAR(20)
);

OUTPUT

Query OK, 0 rows affected

STEP 3 — Orders টেবিল তৈরি (Foreign Key সহ)

CREATE TABLE Orders (
    Order_ID    INT PRIMARY KEY,
    Customer_ID INT,
    Order_Date  DATE,
    FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID)
);

OUTPUT

Query OK, 0 rows affected

STEP 4 — Valid রেকর্ড ইনসার্ট

INSERT INTO Customers VALUES (1, 'Rafiq', '01700000000');
INSERT INTO Orders VALUES (101, 1, '2026-07-15');

OUTPUT

Query OK, 1 row affected ×2

STEP 5 — Invalid Foreign Key ইনসার্ট করার চেষ্টা (ইচ্ছাকৃত ভুল)

INSERT INTO Orders VALUES (102, 99, '2026-07-16');
-- Customer_ID = 99 Customers টেবিলে নেই

EXPECTED ERROR

ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails

কেন

Customer_ID = 99 Customers টেবিলে নেই বলে ডেটাবেস এই "ভুয়া সম্পর্ক" তৈরি হতে দেয়নি।

STEP 6 — Parent রেকর্ড ডিলিট করার চেষ্টা (যদি Child থাকে)

DELETE FROM Customers WHERE Customer_ID = 1;
-- এই Customer-এর একটা Order আছে

EXPECTED ERROR (RESTRICT থাকলে)

ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails

কেন

Customer_ID = 1-এর Order আছে বলে ডেটাবেস এই Customer-কে ডিলিট হতে দিচ্ছে না — যদি না আমরা ON DELETE CASCADE বা SET NULL সেট করে থাকি।

লাইভ ডিসকাশন

STEP 5 আর STEP 6-এর এরর দুইটার মধ্যে পার্থক্য কী?
যদি Customers টেবিলে ON DELETE CASCADE সেট করা থাকতো, STEP 6-এ কী হতো?

বিগিনাররা যেখানে আটকায়

⏱ শেখার অংশ

ভুল	কেন সমস্যা	সমাধান
Primary Key ও Foreign Key গুলিয়ে ফেলা	ভুল কলামে কনস্ট্রেইন্ট বসানো হয়	মনে রাখো — PK নিজের identity, FK অন্যের identity-র রেফারেন্স
Parent Table আগে তৈরি না করা	"Referenced table doesn't exist" এরর	সবসময় Parent → Child ক্রমে টেবিল তৈরি করো
ডেটা টাইপ না মেলানো (INT vs VARCHAR)	Foreign Key তৈরিই হবে না	PK ও FK কলামের ডেটা টাইপ হুবহু এক রাখো
Parent-এর আগে Child-এ রেকর্ড ইনসার্ট করা	Foreign Key constraint violation	সবসময় আগে Parent-এ, তারপর Child-এ ডেটা ঢোকাও
না বুঝে Parent রেকর্ড ডিলিট করা	Child রেকর্ড এতিম (orphan) হয়ে যেতে পারে বা ডিলিটই আটকে যায়	ডিলিটের আগে ভাবো — CASCADE, SET NULL নাকি RESTRICT দরকার
ভুল টেবিল সম্পর্ক তৈরি করা	বাস্তব বিজনেস লজিকের সাথে না মেলা	ডিজাইনের আগে কাগজে ER Diagram এঁকে যাচাই করো
Constraint সংজ্ঞায়িত না করা	ভুল ডেটা ঢুকে যাওয়ার ঝুঁকি	প্রতিটা রিলেশনে স্পষ্টভাবে FOREIGN KEY constraint লেখো

প্রফেশনালরা কীভাবে সম্পর্ক ডিজাইন করে

⏱ শেখার অংশ

সঠিক Normalization — ডেটা বারবার না লিখে আলাদা টেবিলে ভাগ করে Foreign Key দিয়ে সংযুক্ত রাখা।
কনসিস্টেন্ট নেমিং — সব জায়গায় Customer_ID লেখা, কোথাও CustID কোথাও cust_id না লেখা।
ডেটা টাইপ মেলানো — PK আর FK-এর টাইপ, সাইজ সব জায়গায় এক রাখা।
Foreign Key-তে Indexing — বড় টেবিলে JOIN দ্রুত করতে FK কলামে ইনডেক্স রাখা।
ডকুমেন্টেশন — ER Diagram এবং Data Dictionary বানিয়ে রাখা, যাতে নতুন টিম মেম্বার সহজে বুঝতে পারে।
স্কেলেবিলিটি — ভবিষ্যতে নতুন সম্পর্ক (যেমন Refunds, Reviews) যোগ করা সহজ হয় এমনভাবে ডিজাইন করা।

এখন সবাই মিলে করি

⏱ শেখার অংশ

অ্যাক্টিভিটি ১ — মিলাও Primary Key আর Foreign Key মিলাও: Students.Student_ID, Results.Student_ID, Departments.Dept_ID, Employees.Dept_ID।

অ্যাক্টিভিটি ২ — ডায়াগ্রাম আঁকো কাগজে Teacher → Students → Grades-এর মধ্যে সম্পর্ক এঁকে দেখাও, কোনটা Parent আর কোনটা Child।

অ্যাক্টিভিটি ৩ — চিহ্নিত করো নিচের প্রতিটা জোড়ায় কোনটা Parent Table, কোনটা Child Table?

Products / Order_Items
Patients / Appointments
Departments / Employees

অ্যাক্টিভিটি ৪ — প্রেডিক্ট করো যদি একজন Customer-কে ডিলিট করা হয় এবং তার ৫টা Order থাকে — ON DELETE RESTRICT, CASCADE এবং SET NULL — প্রতিটার ক্ষেত্রে কী হবে, আলাদা করে লেখো।

অ্যাক্টিভিটি ৫ — ডিজাইন করো একটা Library Management System-এর জন্য টেবিল ও Foreign Key সম্পর্ক ডিজাইন করো (Members, Books, Borrow_Records)।

Quick Revision Notes

⏱ শেখার অংশ

Foreign Key একটা টেবিলের কলাম, যেটা অন্য টেবিলের Primary Key-কে রেফারেন্স করে।
Foreign Key থাকা টেবিলকে বলে Child Table, আর যেটাকে রেফারেন্স করা হয় সেটা Parent Table।
Referential Integrity নিশ্চিত করে যে Foreign Key সবসময় একটা বৈধ (existing) Primary Key-কে নির্দেশ করে।
Parent রেকর্ড ডিলিট/আপডেট হলে কী হবে তা ঠিক করে দেয় ON DELETE / ON UPDATE (CASCADE, SET NULL, RESTRICT, NO ACTION)।
Foreign Key ডিজাইনের মূল নিয়ম: Parent আগে, তারপর Child — টেবিল তৈরিতেও, ডেটা ইনসার্টেও।

Viva Questions

১Foreign Key কেন দরকার হয়?

দুইটা আলাদা টেবিলের মধ্যে একটা বৈধ সম্পর্ক তৈরি ও বজায় রাখার জন্য, যাতে ডেটা রিপিট না হয় এবং সম্পর্ক সবসময় সঠিক থাকে।

২Referential Integrity কী?

এমন একটা নিয়ম, যা নিশ্চিত করে Foreign Key-এর মান সবসময় Parent টেবিলের Primary Key-এর মধ্যে থেকেই আসে — কোনো "ভুয়া" রেফারেন্স তৈরি হতে দেয় না।

৩Parent Table না বানিয়ে Child Table বানানো যায় কি?

না, কারণ Foreign Key একটা এখনো-না-থাকা টেবিলকে রেফারেন্স করতে পারে না — MySQL "Referenced table doesn't exist" এরর দেবে।

MCQ (উত্তরসহ)

Foreign Key কোন টেবিলে থাকে? ক) Parent Table খ) Child Table গ) দুই টেবিলেই ঘ) কোথাও না

সঠিক উত্তর: খ) Child Table

Foreign Key যদি এমন একটা মান রেফারেন্স করে যা Parent টেবিলে নেই, তখন কী হয়? ক) স্বয়ংক্রিয়ভাবে তৈরি হয় খ) Error দেয় গ) NULL বসে ঘ) কিছুই হয় না

সঠিক উত্তর: খ) Error দেয়

Parent রেকর্ড ডিলিট হলে সংশ্লিষ্ট Child রেকর্ডও ডিলিট করতে কোনটা ব্যবহার হয়? ক) RESTRICT খ) SET NULL গ) CASCADE ঘ) NO ACTION

সঠিক উত্তর: গ) CASCADE

ক্লাসরুম এক্সারসাইজ

একটা Restaurant Table Booking System ডিজাইন করো — Customers ও Bookings টেবিলের মধ্যে সম্পর্ক ঠিক করো এবং কারণ ব্যাখ্যা করো।

হোমওয়ার্ক অ্যাসাইনমেন্ট

একটা Hospital Management System ডিজাইন করো যেখানে Patients, Doctors, এবং Appointments তিনটা টেবিল থাকবে। কোন কলামগুলো Foreign Key হবে তা ব্যাখ্যা করে SQL CREATE TABLE স্টেটমেন্ট লিখে জমা দাও, এবং একটা ON DELETE পলিসি বেছে নিয়ে যুক্তি দাও।

কাগজের রেজিস্টার থেকে Foreign Key পর্যন্ত

⏱ শেখার অংশ

এক সময় হাসপাতাল, স্কুল, ব্যাংকের সব তথ্য কাগজের আলাদা আলাদা রেজিস্টারে লেখা থাকতো, এবং একটা রেজিস্টারের তথ্যকে আরেকটার সাথে মেলানো হতো হাতে-কলমে, নম্বর দেখে দেখে। ১৯৭০-এর দশকে যখন Relational Database মডেল (E.F. Codd প্রবর্তিত) আসে, তখন এই "হাতে মেলানো" কাজটাকেই কম্পিউটার নিজে স্বয়ংক্রিয়ভাবে করার উপায় দরকার হয়ে পড়ে। Foreign Key ধারণাটা তৈরি হয় ঠিক এই প্রয়োজন থেকেই — যাতে কম্পিউটার নিজেই নিশ্চিত করতে পারে যে দুইটা টেবিলের মধ্যে সম্পর্ক সবসময় সঠিক ও বৈধ থাকে, মানুষের হাতে-কলমে যাচাই করার দরকার না পড়ে। আজকের প্রতিটা প্রধান RDBMS (MySQL, PostgreSQL, SQL Server, Oracle)-এই এই একই ভিত্তি ব্যবহার হয়।

তিন ধরনের সম্পর্ক — এক নজরে

⏱ শেখার অংশ

One-to-One, One-to-Many, এবং Many-to-Many — তিন ধরনের সম্পর্কের কাঠামোগত পার্থক্য

তুলনা	Primary Key vs Foreign Key
নিজের টেবিলে ইউনিক identity	Primary Key
অন্য টেবিলের রেফারেন্স	Foreign Key

তুলনা	Foreign Key vs সাধারণ কলাম
ডেটাবেস যাচাই করে ভ্যালু বৈধ কিনা	শুধু Foreign Key-তে (সাধারণ কলামে হয় না)
অন্য টেবিলের সাথে সম্পর্ক তৈরি করে	শুধু Foreign Key

CASCADE	RESTRICT	SET NULL	NO ACTION
Child-ও একসাথে ডিলিট/আপডেট হয়	Parent ডিলিট/আপডেট আটকে যায়	Child থেকে যায়, FK কলাম NULL হয়	সাধারণত RESTRICT-এর মতোই আচরণ

তুলনা	Parent Table	Child Table
থাকে	Primary Key	Foreign Key
নির্ভরতা	স্বাধীন	Parent-এর উপর নির্ভরশীল
তৈরির ক্রম	আগে তৈরি হয়	পরে তৈরি হয়

Hospital Management System

⏱ শেখার অংশ

প্রজেক্ট স্ট্রাকচার

CREATE TABLE Patients (
    Patient_ID  INT PRIMARY KEY,
    Name        VARCHAR(100)
);

CREATE TABLE Doctors (
    Doctor_ID   INT PRIMARY KEY,
    Name        VARCHAR(100),
    Specialty   VARCHAR(50)
);

CREATE TABLE Appointments (
    Appointment_ID INT PRIMARY KEY,
    Patient_ID     INT,
    Doctor_ID      INT,
    Appt_Date      DATE,
    FOREIGN KEY (Patient_ID) REFERENCES Patients(Patient_ID),
    FOREIGN KEY (Doctor_ID)  REFERENCES Doctors(Doctor_ID)
);

INSERT INTO Patients  VALUES (1, 'Nadia');
INSERT INTO Doctors   VALUES (1, 'Dr. Karim', 'Cardiology');
INSERT INTO Appointments VALUES (1001, 1, 1, '2026-08-01');

সম্পর্ক

Appointments হলো Child Table, যেটার দুইটা আলাদা Foreign Key আছে — একটা Patients-কে, আরেকটা Doctors-কে নির্দেশ করে। এটাই আসলে একটা বাস্তব One-to-Many-থেকে-One-to-Many সম্পর্কের উদাহরণ।

চ্যালেঞ্জ: একই লজিক দিয়ে E-commerce অথবা Library Management System ডিজাইন করে দেখাও।

DBA, Data Engineer, Analyst, Data Scientist — কে কীভাবে Foreign Key ব্যবহার করে

⏱ শেখার অংশ

ভূমিকা	Foreign Key কীভাবে ব্যবহার করে
Database Administrator (DBA)	ডেটার সঠিকতা (integrity) রক্ষা করে, ভুল রেফারেন্স আটকায়, Backup/Recovery-তে সম্পর্ক অক্ষত রাখে
Data Engineer	Pipeline ডিজাইনের সময় টেবিলের মধ্যে সম্পর্ক বজায় রেখে ETL/ELT প্রসেস তৈরি করে
Data Analyst	একাধিক টেবিলকে JOIN করে রিপোর্ট ও ড্যাশবোর্ড তৈরি করে (যেমন Orders JOIN Customers)
Data Scientist	মডেলিং-এর জন্য ডেটা প্রস্তুত করার সময় সঠিক Foreign Key সম্পর্ক ব্যবহার করে সঠিক ফিচার তৈরি করে

Top 30 SQL Foreign Key ইন্টারভিউ প্রশ্ন

⏱ শেখার অংশ

#	প্রশ্ন	সংক্ষিপ্ত উত্তর
01	Foreign Key কী?	একটা টেবিলের কলাম, যেটা অন্য টেবিলের Primary Key-কে রেফারেন্স করে।
02	Foreign Key কেন দরকার?	দুইটা টেবিলের মধ্যে বৈধ সম্পর্ক তৈরি ও রক্ষা করার জন্য।
03	Primary Key vs Foreign Key পার্থক্য?	PK নিজের টেবিলে ইউনিক identity; FK অন্য টেবিলের identity রেফারেন্স করে, রিপিট হতে পারে।
04	Foreign Key-তে NULL রাখা যায়?	হ্যাঁ, যদি সম্পর্কটা ঐচ্ছিক হয় (উদাহরণ: এখনো কোনো ম্যানেজার এসাইন হয়নি)।
05	Referential Integrity কী?	নিয়ম যা নিশ্চিত করে FK সবসময় একটা বৈধ, বিদ্যমান PK-কে নির্দেশ করে।
06	Parent Table ও Child Table কী?	Parent-এ Primary Key থাকে, Child-এ সেই PK-কে রেফারেন্স করা Foreign Key থাকে।
07	SQL-এ Foreign Key কীভাবে তৈরি করবে?	CREATE TABLE-এর মধ্যে `FOREIGN KEY (col) REFERENCES Parent(col)` লিখে, অথবা পরে ALTER TABLE দিয়ে।
08	Invalid Foreign Key ইনসার্ট করলে কী হয়?	Error 1452 — constraint violation, ইনসার্ট ব্যর্থ হয়।
09	Child রেকর্ড থাকা অবস্থায় Parent ডিলিট করলে কী হয়?	ডিফল্টে Error 1451 (RESTRICT), অথবা CASCADE/SET NULL সেট থাকলে সেই অনুযায়ী আচরণ হয়।
10	ON DELETE CASCADE কী করে?	Parent ডিলিট হলে সংশ্লিষ্ট সব Child রেকর্ডও ডিলিট হয়ে যায়।
11	ON DELETE SET NULL কী করে?	Parent ডিলিট হলে Child রেকর্ড থেকে যায়, শুধু FK কলাম NULL হয়ে যায়।
12	একটা টেবিলে কয়টা Foreign Key থাকতে পারে?	একাধিক থাকতে পারে (যেমন Order_Items-এ Order_ID ও Product_ID)।
13	Foreign Key কি নিজে থেকেই Index তৈরি করে?	DB-ভেদে ভিন্ন — অনেক ক্ষেত্রে ম্যানুয়ালি ইনডেক্স তৈরি করা ভালো অভ্যাস।
14	Self-Referencing Foreign Key কী?	একটা টেবিলের কলাম নিজের টেবিলের Primary Key-কেই রেফারেন্স করে (যেমন Employees.Manager_ID → Employees.Employee_ID)।
15	Foreign Key ছাড়া কি দুইটা টেবিল জোড়া লাগানো (JOIN) যায়?	হ্যাঁ, JOIN করার জন্য টেকনিক্যালি Foreign Key বাধ্যতামূলক নয়, কিন্তু ডেটার সঠিকতা রক্ষার জন্য এটা রাখাই উত্তম চর্চা।
16	Composite Foreign Key কী?	একাধিক কলাম মিলে অন্য টেবিলের Composite Primary Key-কে রেফারেন্স করা।
17	Foreign Key ডিজাইনের সবচেয়ে সাধারণ ভুল কী?	Parent Table আগে তৈরি না করা বা ডেটা টাইপ না মেলানো।
18	Foreign Key কি ডেটা টাইপ মেলাতে বাধ্য করে?	হ্যাঁ, PK ও FK কলামের ডেটা টাইপ হুবহু মিলতে হয়।
19	Foreign Key মুছে ফেলা (drop) যায়?	হ্যাঁ, `ALTER TABLE ... DROP FOREIGN KEY constraint_name` দিয়ে।
20	Foreign Key কি Update করা যায়?	হ্যাঁ, তবে ON UPDATE পলিসি (CASCADE/RESTRICT) অনুযায়ী আচরণ হয়।
21	One-to-Many সম্পর্কে FK কোথায় থাকে?	"Many" পক্ষের টেবিলে (Child Table)।
22	Many-to-Many সম্পর্ক কীভাবে Foreign Key দিয়ে বাস্তবায়ন হয়?	একটা Junction Table তৈরি করে, যেখানে দুইটা আলাদা Foreign Key থাকে।
23	Foreign Key কি পারফরম্যান্সে প্রভাব ফেলে?	হ্যাঁ — প্রতি INSERT/UPDATE/DELETE-এ ডেটাবেস অতিরিক্ত চেক করে, তাই সামান্য ওভারহেড থাকে, কিন্তু ডেটা সঠিকতার জন্য এটা প্রয়োজনীয়।
24	Orphan Record কী?	এমন একটা Child রেকর্ড যার Foreign Key কোনো বৈধ Parent রেকর্ডকে নির্দেশ করে না (সাধারণত ভুল ডিজাইনে ঘটে)।
25	RESTRICT ও NO ACTION-এর পার্থক্য কী?	বেশিরভাগ DB-তে কার্যত একই রকম আচরণ করে — Child থাকলে Parent ডিলিট/আপডেট আটকে দেয়।
26	Foreign Key কেন Normalization-এ গুরুত্বপূর্ণ?	ডেটা রিপিটেশন কমিয়ে আলাদা টেবিলে ভাগ করার পরেও সম্পর্ক ধরে রাখতে সাহায্য করে।
27	Foreign Key ব্যবহার না করলে কী ঝুঁকি থাকে?	ভুল/অস্তিত্বহীন রেফারেন্স ডেটাবেসে ঢুকে যেতে পারে, যা পরবর্তীতে রিপোর্ট ও JOIN-এ ভুল ফলাফল দেয়।
28	বড় স্কেল সিস্টেমে Foreign Key ব্যবহারে কী সতর্কতা দরকার?	Indexing নিশ্চিত করা, এবং CASCADE-এর মতো অপারেশন বড় ডেটাসেটে কতটা খরচ (locking, performance) করবে তা বিবেচনা করা।
29	ইন্টারভিউয়ে "তোমার প্রজেক্টে Foreign Key কোথায় ব্যবহার করেছিলে?" — কীভাবে উত্তর দেবে?	একটা নির্দিষ্ট Parent-Child সম্পর্ক (যেমন Orders-Customers) এবং কেন সেটা বেছে নিয়েছিলে তা ব্যাখ্যা করো।
30	Foreign Key ডিজাইনের সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন কী নিজেকে জিজ্ঞেস করা উচিত?	"এই দুইটা টেবিলের মধ্যে বাস্তব বিজনেসে আসলে কী সম্পর্ক আছে, আর Parent রেকর্ড ডিলিট হলে Child-এর কী হওয়া উচিত?"

কমন ফলো-আপ প্রশ্ন (ইন্টারভিউয়ে আসতে পারে)

"তোমার আগের প্রজেক্টে Foreign Key দিয়ে কোন সমস্যা সমাধান করেছিলে?" — নির্দিষ্ট উদাহরণ প্রস্তুত রাখো।
"CASCADE ব্যবহার করা কি সবসময় নিরাপদ?" — না, কারণ ভুলবশত গুরুত্বপূর্ণ ডেটা হারানোর ঝুঁকি থাকে এই ট্রেড-অফ ব্যাখ্যা করতে প্রস্তুত থাকো।
"Foreign Key ছাড়া কি একটা প্রোডাকশন ডেটাবেস চলতে পারে?" — টেকনিক্যালি সম্ভব, কিন্তু ডেটা সঠিকতার ঝুঁকি ব্যাখ্যা করতে প্রস্তুত থাকো।

📋 বিষয়সূচী (Table of Contents)

এবার সংজ্ঞাটা দাঁড় করাই

Primary Key এবং Foreign Key কীভাবে একসাথে কাজ করে

এক টেবিল অনেকগুলোর সাথে সংযুক্ত

এবার হাত চালাই — কোড লিখি

ডেটাবেস কীভাবে ভুল সম্পর্ক আটকায়

প্যারেন্ট রেকর্ড ডিলিট হলে কী হবে?

Online Shopping System

একজন কাস্টমারের অর্ডার-যাত্রা

MySQL Workbench / Google Colab-এ ধাপে ধাপে

বিগিনাররা যেখানে আটকায়

প্রফেশনালরা কীভাবে সম্পর্ক ডিজাইন করে

এখন সবাই মিলে করি

Quick Revision Notes

Viva Questions

MCQ (উত্তরসহ)

ক্লাসরুম এক্সারসাইজ

হোমওয়ার্ক অ্যাসাইনমেন্ট

কাগজের রেজিস্টার থেকে Foreign Key পর্যন্ত

তিন ধরনের সম্পর্ক — এক নজরে

Hospital Management System

DBA, Data Engineer, Analyst, Data Scientist — কে কীভাবে Foreign Key ব্যবহার করে

Top 30 SQL Foreign Key ইন্টারভিউ প্রশ্ন