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

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

⏱ শেখার অংশ

এনালজি ধরো, একটা বাসার ঠিকানা লিখতে গেলে শুধু "বাড়ি নং ৫" লিখলে হবে না — লিখতে হবে "রোড ৫, ব্লক বি, বাড়ি নং ৫"। একাধিক তথ্য একসাথে মিলিয়ে তবেই ঠিকানাটা "ইউনিক" হয়। ডেটাবেসেও ঠিক এই কাজটাই করে Composite Key।

Composite Key হলো একটা টেবিলে দুই বা ততোধিক কলাম একসাথে মিলিয়ে তৈরি করা Primary Key, যেখানে প্রতিটা কলাম আলাদাভাবে ইউনিক না হলেও, কলামগুলোর কম্বিনেশন সবসময় ইউনিক থাকে।

Single Primary Key বনাম Composite Primary Key — পাশাপাশি তুলনা

লক্ষ্য করো — Composite Key-তে Student_ID একা বহুবার রিপিট হতে পারে (একজন ছাত্র অনেক কোর্সে ভর্তি হতে পারে), Course_IDও একা বহুবার রিপিট হতে পারে (একটা কোর্সে অনেক ছাত্র থাকতে পারে) — কিন্তু একই Student_ID + একই Course_ID জোড়া দ্বিতীয়বার আসবে না।

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

Enrollments টেবিলে যদি শুধু Student_ID-কে Primary Key বানাই, সমস্যা কোথায় হবে?
যদি শুধু Course_ID-কে Primary Key বানাই, সমস্যা কোথায় হবে?

Composite Key vs Primary Key vs Unique Key

⏱ শেখার অংশ

বিষয়	Single-column Primary Key	Composite Primary Key	Unique Key
কলাম সংখ্যা	একটি	দুই বা তার বেশি	এক বা একাধিক
ইউনিকনেস	ঐ একটি কলামে	কলামগুলোর কম্বিনেশনে	নির্দিষ্ট কলাম(গুলোতে)
NULL নিয়ম	NULL গ্রহণযোগ্য নয়	কোনো অংশেই NULL গ্রহণযোগ্য নয়	একটি NULL row-তে গ্রহণযোগ্য (DB ভেদে)
টেবিল প্রতি সংখ্যা	একটিই থাকতে পারে	একটিই থাকতে পারে (নিজেই Primary Key)	একাধিক Unique Key থাকতে পারে
উদ্দেশ্য	প্রতিটা row-কে সহজে identify করা	রিলেশনশিপ/জাংশন টেবিলে সঠিক ইউনিকনেস রক্ষা	বাড়তি বিজনেস রুল রক্ষা (যেমন Email ইউনিক)
সাধারণ ব্যবহার	Users, Products, Customers	Enrollments, Order_Items, Bookings	Email, Phone Number, Username

Composite Key vs Unique Key — একটা কমন কনফিউশন

দুটোই একাধিক কলাম নিতে পারে, কিন্তু Composite Key সবসময় Primary Key-এর ভূমিকায় থাকে (এবং Foreign Key দিয়ে অন্য টেবিল থেকে রেফারেন্স করা যায়), অন্যদিকে Unique Key শুধু ডুপ্লিকেট আটকায় — এটা টেবিলের মূল আইডেন্টিটি হিসেবে কাজ করে না।

উদাহরণ দিয়ে বুঝি

Users টেবিলে User_ID Primary Key, কিন্তু Email Unique Key — কেন দুটোই দরকার?
Enrollments টেবিলে কেন Unique Key নয়, বরং সরাসরি Composite Primary Key বেছে নেওয়া হয়?

চারটি ইন্ডাস্ট্রি, চারটি Composite Key

⏱ শেখার অংশ

উদাহরণ ১ — Student Attendance

Composite KeyClass + Roll_Number + Date — কারণ একই ছাত্রের একই দিনে দুইবার Attendance নেওয়া হয় না, কিন্তু প্রতিদিনই একটা নতুন রেকর্ড লাগবে।

উদাহরণ ২ — Order Details (ই-কমার্স)

Composite KeyOrder_ID + Product_ID — একটা অর্ডারে অনেক প্রোডাক্ট থাকতে পারে, একই প্রোডাক্ট অনেক অর্ডারে থাকতে পারে, কিন্তু একই অর্ডারে একই প্রোডাক্ট একবারই (quantity বাড়িয়ে) থাকবে।

Orders ↔ Order_Items ↔ Products — Order_Items হলো "জাংশন টেবিল"

উদাহরণ ৩ — University Enrollment

Composite KeyStudent_ID + Course_ID — Part 6-এ এটা নিয়ে বিস্তারিত কেস স্টাডি করবো।

উদাহরণ ৪ — Movie Ticket Booking

Composite KeyShow_ID + Seat_Number — একই শোতে একই সিট দুইজনকে বিক্রি করা যাবে না, কিন্তু আলাদা শো-তে সেই একই সিট নম্বর আবার বিক্রি হতে পারে।

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

চারটা উদাহরণেই একটা কমন প্যাটার্ন আছে — সেটা কী? (হিন্ট: "কোন প্রসঙ্গে" + "কী")
তোমার চেনা কোনো অ্যাপ (Pathao, Foodpanda, bKash) থেকে একটা Composite Key উদাহরণ বের করতে পারবে?

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

⏱ শেখার অংশ

STEP 1 — দুই কলামের Composite Primary Key

CREATE TABLE Enrollments (
    Student_ID   INT NOT NULL,
    Course_ID    INT NOT NULL,
    Semester     VARCHAR(20),
    Grade        CHAR(2),
    PRIMARY KEY (Student_ID, Course_ID)
);

EXPECTED OUTPUT

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

লাইন বাই লাইন

PRIMARY KEY (Student_ID, Course_ID) — এই একটা লাইনই Student_ID এবং Course_ID দুটো কলামকে একসাথে Primary Key ঘোষণা করছে। প্রতিটা কলাম আলাদাভাবে NOT NULL হতেই হবে — Composite Key-এর কোনো অংশেই NULL চলবে না।

কমন ভুল

ভুলে Student_ID INT PRIMARY KEY, Course_ID INT PRIMARY KEY এভাবে দুইবার আলাদা করে লেখা — এটা Error দেয়, কারণ একটা টেবিলে একটাই Primary Key clause থাকতে পারে।

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

Composite Key-এর কলামগুলো টেবিলের একদম উপরের দিকে রাখো, যাতে টেবিলের গঠন পড়েই বোঝা যায় কীসের ভিত্তিতে ইউনিকনেস তৈরি হচ্ছে।

STEP 2 — তিন কলামের Composite Key

CREATE TABLE Attendance (
    Class          VARCHAR(10) NOT NULL,
    Roll_Number    INT NOT NULL,
    Att_Date       DATE NOT NULL,
    Status         VARCHAR(10),
    PRIMARY KEY (Class, Roll_Number, Att_Date)
);

EXPECTED OUTPUT

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

লাইন বাই লাইন

তিনটা কলাম — Class, Roll_Number, Att_Date — একসাথে একটা row-কে ইউনিক করছে। মনে করো Part 1-এর Attendance গল্পটা — এখানে সেটাই বাস্তবায়ন হচ্ছে।

কমন ভুল

শুধু Class + Roll_Number-কে Key ধরে নেওয়া, Att_Date বাদ দেওয়া — ফলে একজন ছাত্রের প্রতিদিনের Attendance ওভাররাইট হয়ে যাবে।

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

Key ডিজাইন করার আগে নিজেকে জিজ্ঞেস করো — "কোন কলামগুলো ছাড়া রেকর্ডটা বাস্তবেই ডুপ্লিকেট হয়ে যাবে?" সেই কলামগুলোই Key-তে রাখো, বাকিগুলো নয়।

STEP 3 — Composite Foreign Key (কনসেপ্ট)

CREATE TABLE Enrollments (
    Student_ID   INT NOT NULL,
    Course_ID    INT NOT NULL,
    Semester     VARCHAR(20),
    PRIMARY KEY (Student_ID, Course_ID),
    FOREIGN KEY (Student_ID) REFERENCES Students(Student_ID),
    FOREIGN KEY (Course_ID)  REFERENCES Courses(Course_ID)
);

EXPECTED OUTPUT

Query OK, 0 rows affected Table 'Enrollments' created with foreign key constraints.

লাইন বাই লাইন

এখানে Composite Primary Key-এর প্রতিটা অংশ (Student_ID, Course_ID) আলাদা আলাদাভাবে অন্য টেবিলের Primary Key-কে রেফারেন্স করছে Foreign Key দিয়ে। এইভাবেই Composite Key আর Foreign Key একসাথে কাজ করে Relationship তৈরি করে।

কমন ভুল

মনে করা যে Composite Foreign Key মানে দুইটা কলাম একসাথে একটা কম্পোজিট কলাম হিসেবে অন্য টেবিলকে রেফারেন্স করবে — বাস্তবে প্রতিটা কলাম নিজের মতো আলাদা টেবিলকে রেফারেন্স করতে পারে (এখানে যেমন করছে), অথবা দুইটা কলাম একসাথে একটা Composite Primary Key-কে রেফারেন্স করতে পারে (advanced case)।

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

প্রতিটা Foreign Key-এর জন্য parent টেবিলে ইনডেক্স আছে কিনা নিশ্চিত করো — এতে JOIN পারফরম্যান্স ভালো থাকে।

University Management System

⏱ শেখার অংশ

Many-to-Many সম্পর্ক: এক ছাত্র অনেক কোর্সে, এক কোর্সে অনেক ছাত্র — Enrollments এই সম্পর্ককে ভেঙে দুইটা One-to-Many সম্পর্কে রূপান্তর করে

যদি Enrollments টেবিলে শুধু Student_ID-কে Primary Key বানাই, তাহলে একজন ছাত্র একসাথে দুইটা কোর্সে ভর্তি হতে পারবে না — কারণ দ্বিতীয় কোর্সের রেকর্ড দিতে গেলেই "Duplicate Primary Key" এরর আসবে। তাই Student_ID + Course_ID-কে একসাথে Composite Key বানানো ছাড়া উপায় নেই।

সম্পূর্ণ সিস্টেম — তিনটা টেবিল

CREATE TABLE Students (
    Student_ID  INT PRIMARY KEY,
    Name        VARCHAR(100),
    Department  VARCHAR(50)
);

CREATE TABLE Courses (
    Course_ID     INT PRIMARY KEY,
    Title         VARCHAR(100),
    Credit_Hours  INT
);

CREATE TABLE Enrollments (
    Student_ID  INT,
    Course_ID   INT,
    Semester    VARCHAR(20),
    Grade       CHAR(2),
    PRIMARY KEY (Student_ID, Course_ID),
    FOREIGN KEY (Student_ID) REFERENCES Students(Student_ID),
    FOREIGN KEY (Course_ID)  REFERENCES Courses(Course_ID)
);

EXPECTED OUTPUT

Query OK, 0 rows affected (Students) Query OK, 0 rows affected (Courses) Query OK, 0 rows affected (Enrollments)

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

সবসময় parent টেবিল (Students, Courses) আগে তৈরি করো, তারপর child/junction টেবিল (Enrollments) — নাহলে Foreign Key তৈরির সময় এরর আসবে।

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

⏱ শেখার অংশ

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

CREATE DATABASE university_demo;
USE university_demo;

OUTPUT

Query OK, 1 row affected Database changed

ব্যাখ্যা

USE কমান্ড না দিলে পরের কমান্ডগুলো কোন ডেটাবেসে চলবে সেটা MySQL বুঝতে পারবে না।

STEP 2 — তিনটা টেবিল তৈরি (আগের কোড ব্যবহার করো)

-- Part 6-এর তিনটা CREATE TABLE স্টেটমেন্ট এখানে চালাও

কমন ভুল

Enrollments টেবিল Students/Courses তৈরির আগে চালানো — এতে Foreign Key constraint fails এরর আসবে।

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

INSERT INTO Students VALUES (1, 'Rafiq', 'CSE');
INSERT INTO Courses  VALUES (101, 'Database Systems', 3);
INSERT INTO Enrollments VALUES (1, 101, 'Spring-2026', NULL);

OUTPUT

Query OK, 1 row affected ×3

STEP 4 — একই কম্বিনেশন আবার ইনসার্ট করার চেষ্টা (ইচ্ছাকৃত ভুল)

INSERT INTO Enrollments VALUES (1, 101, 'Fall-2026', NULL);

EXPECTED ERROR

ERROR 1062 (23000): Duplicate entry '1-101' for key 'PRIMARY'

কেন এই এরর

Student_ID = 1 এবং Course_ID = 101 — এই জোড়া আগেই Enrollments-এ আছে। Composite Primary Key নিয়ম অনুযায়ী এই জোড়া দ্বিতীয়বার আসতে পারবে না, Semester ভিন্ন হলেও না। (বাস্তব সিস্টেমে Semester-কেও Key-এর অংশ করতে হবে যদি একই কোর্স একাধিক সেমিস্টারে রিপিট করা লাগে — এটাই ক্লাসকে ভাবাও।)

লাইভ ডিসকাশন

এই এরর কেন আসলো, নিজের ভাষায় ব্যাখ্যা করো।
যদি একই ছাত্র একই কোর্স দুইবার (retake) করতে চায়, Key ডিজাইন কীভাবে বদলাতে হবে?

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

⏱ শেখার অংশ

ভুল	কেন সমস্যা	সমাধান
মনে করা প্রতিটা টেবিলেই Composite Key দরকার	অপ্রয়োজনীয় জটিলতা বাড়ে	আগে চেষ্টা করো একটা কলাম (আদর্শভাবে Surrogate ID) দিয়ে সমাধান হয় কিনা
খুব বেশি কলাম Key-তে রাখা	JOIN ও Index ভারী হয়ে যায়	শুধু যেগুলো ছাড়া সত্যিই ডুপ্লিকেট হবে সেগুলোই রাখো
পরিবর্তনশীল ভ্যালু (যেমন Name, Status) Key-তে রাখা	ভ্যালু বদলালে Foreign Key-সহ পুরো রিলেশন ভেঙে যায়	শুধু স্থায়ী/স্ট্যাবল আইডেন্টিফায়ার কলাম Key-তে রাখো
"Composite Key" আর "একাধিক Primary Key" গুলিয়ে ফেলা	টেবিলে একটাই Primary Key clause থাকতে পারে	মনে রাখো: একাধিক কলাম মিলে একটাই Key
একই কলাম-কম্বিনেশন দুইবার ইনসার্ট করার চেষ্টা	Duplicate entry error	ইনসার্টের আগে existing কম্বিনেশন চেক করা অভ্যাস করো
Composite Key কলামে ইনডেক্সিং উপেক্ষা করা	বড় টেবিলে Query স্লো হয়ে যায়	Composite Key-এর কলাম অর্ডার নিয়ে চিন্তা করো — সবচেয়ে বেশি ফিল্টার হওয়া কলাম আগে রাখো

প্রফেশনালরা কীভাবে সিদ্ধান্ত নেয়

⏱ শেখার অংশ

একজন Database Architect তিনটা অপশনের মধ্যে বেছে নেয়: Single-column Primary Key, Composite Key, অথবা Surrogate Key (একটা কৃত্রিম Auto-Increment ID)।

বিবেচনা	Composite Key যখন ভালো	Surrogate Key যখন ভালো
পারফরম্যান্স	ছোট টেবিল, সরল JOIN	বড় টেবিল, বহু জায়গায় রেফারেন্স হয়
সিম্পলিসিটি	Key-ই বিজনেস মিনিং বহন করে (self-descriptive)	কোড এবং Foreign Key সরল থাকে (শুধু এক কলাম)
মেইনটেইনেবিলিটি	বিজনেস রুল স্পষ্ট থাকে টেবিল গঠনেই	বিজনেস রুল বদলালেও Key নিজে অপরিবর্তিত থাকে
স্কেলেবিলিটি	জাংশন টেবিলে (many-to-many) স্বাভাবিক পছন্দ	মাইক্রোসার্ভিস/ডিস্ট্রিবিউটেড সিস্টেমে সহজে রেপ্লিকেট হয়

বাস্তবে অনেক প্রফেশনাল টিম Enrollments-এর মতো জাংশন টেবিলেও একটা Surrogate Enrollment_ID রাখে, আর (Student_ID, Course_ID)-এর উপর আলাদা Unique Key বসিয়ে দেয় — এতে দুই জগতের সুবিধাই পাওয়া যায়। এটাই "কনসেপ্ট" পর্যায়ে জানা থাকলে ভবিষ্যতে ডিজাইন ডিসিশন নিতে সুবিধা হবে।

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

⏱ শেখার অংশ

অ্যাক্টিভিটি ১ — চিহ্নিত করো নিচের কোন পরিস্থিতিতে Composite Key দরকার হবে? (হাত তুলে উত্তর দাও)

একটা Library-তে কোন বই কোন সদস্য ধার নিয়েছে তার রেকর্ড
একটা কোম্পানির Employee লিস্ট (প্রতিটা Employee-এর ইউনিক ID আছে)
একটা হোটেলে কোন রুম কোন তারিখে বুক আছে তার রেকর্ড

অ্যাক্টিভিটি ২ — ডিজাইন করো জোড়ায় জোড়ায় কাজ করো: একটা Cinema Hall Seat Booking System-এর জন্য Composite Key ডিজাইন করো এবং কারণ ব্যাখ্যা করো।

অ্যাক্টিভিটি ৩ — ভুল ধরো

CREATE TABLE Bookings (
    Seat_Number INT PRIMARY KEY,
    Show_ID     INT PRIMARY KEY,
    Customer    VARCHAR(50)
);

এই কোডে কী ভুল আছে? কীভাবে ঠিক করবে?

অ্যাক্টিভিটি ৪ — মিলাও টেবিল আর তার সঠিক Composite Key মিলাও: Flight_Bookings, Match_Scorecards, Attendance — বনাম — Flight_No + Date, Season + Match_No, Class + Roll + Date।

Quick Revision Notes

⏱ শেখার অংশ

একটা কলাম যখন একা ইউনিক নিশ্চিত করতে পারে না, তখন দুই বা তার বেশি কলাম একসাথে ব্যবহার করা হয় — একেই বলে Composite Key।
Composite Key-এর কোনো অংশেই NULL চলবে না।
Composite Key মূলত জাংশন/রিলেশনশিপ টেবিলে (many-to-many) সবচেয়ে বেশি দেখা যায়।
Unique Key ডুপ্লিকেট আটকায়, কিন্তু Primary Key-এর ভূমিকা নেয় না।
Composite Key ডিজাইনের নিয়ম: শুধু সেই কলামগুলো রাখো, যেগুলো ছাড়া রেকর্ড সত্যিই ডুপ্লিকেট হয়ে যাবে।

Viva Questions

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

যখন কোনো একক কলাম একটা row-কে সম্পূর্ণরূপে ইউনিকভাবে চিহ্নিত করতে পারে না, তখন একাধিক কলাম একসাথে ব্যবহার করে ইউনিকনেস নিশ্চিত করা হয়।

২Composite Key-তে NULL রাখা যায় কি?

না, Composite Primary Key-এর কোনো অংশেই NULL রাখা যায় না।

৩Enrollments টেবিলে কেন শুধু Student_ID যথেষ্ট নয়?

কারণ একজন ছাত্র একাধিক কোর্সে ভর্তি হতে পারে — শুধু Student_ID Primary Key হলে দ্বিতীয় কোর্সের রেকর্ড ইনসার্ট করাই যাবে না।

MCQ (উত্তরসহ)

Composite Key তৈরি করতে কমপক্ষে কয়টা কলাম লাগে? ক) এক খ) দুই গ) তিন ঘ) চার

সঠিক উত্তর: খ) দুই

নিচের কোনটা Composite Key-এর উদাহরণ? ক) শুধু Student_ID খ) শুধু Email গ) Order_ID + Product_ID ঘ) শুধু Phone

সঠিক উত্তর: গ) Order_ID + Product_ID

Composite Key-এর কোনো একটা কলামে NULL থাকলে কী হয়?

ক) সমস্যা নেই খ) Error/Constraint Violation গ) স্বয়ংক্রিয়ভাবে 0 বসে ঘ) কোনো প্রভাব নেই

সঠিক উত্তর: খ) Error/Constraint Violation

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

একটা Restaurant Table Reservation System-এর জন্য টেবিল ডিজাইন করো — কোন কলামগুলো Composite Key হবে তা যুক্তিসহ লিখো।

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

একটা Online Exam System ডিজাইন করো যেখানে Students, Exams, এবং Results তিনটা টেবিল থাকবে। Results টেবিলের Composite Key কী হবে, এবং কেন — তা ব্যাখ্যা করে SQL CREATE TABLE স্টেটমেন্ট লিখে জমা দাও।

Composite Key কেন গুরুত্বপূর্ণ হয়ে উঠলো

⏱ শেখার অংশ

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

চারটি গুরুত্বপূর্ণ তুলনা টেবিল

⏱ শেখার অংশ

1. Primary Key vs Composite Key

দিক	Primary Key	Composite Key
সংজ্ঞা	একটা row-কে ইউনিকভাবে চিহ্নিত করার প্রধান কলাম	একাধিক কলাম মিলিয়ে তৈরি Primary Key
কলাম সংখ্যা	এক (সাধারণত)	দুই বা বেশি
সম্পর্ক	Composite Key আসলে Primary Key-এরই একটা রূপ	Primary Key-এর বিশেষ প্রকার

2. Composite Key vs Unique Key

দিক	Composite Key	Unique Key
ভূমিকা	টেবিলের মূল আইডেন্টিটি	বাড়তি বিজনেস কনস্ট্রেইন্ট
সংখ্যা প্রতি টেবিল	একটাই	একাধিক থাকতে পারে
NULL	অনুমোদিত নয়	কিছু DB-তে একটা NULL অনুমোদিত

3. Composite Key vs Surrogate Key (কনসেপ্চুয়াল)

দিক	Composite Key	Surrogate Key
উৎস	বিজনেস ডেটা থেকে তৈরি	সিস্টেম-জেনারেটেড (Auto-Increment/UUID)
অর্থবহতা	নিজেই বিজনেস মিনিং বহন করে	কোনো বিজনেস অর্থ বহন করে না
পরিবর্তনযোগ্যতা	বিজনেস রুল বদলালে সমস্যা হতে পারে	স্থায়ী ও স্থিতিশীল

4. Single-column vs Multi-column Keys

দিক	Single-column Key	Multi-column (Composite) Key
সিম্পলিসিটি	বেশি সরল	তুলনামূলক জটিল
উপযুক্ত ক্ষেত্র	স্বাধীন এনটিটি (Users, Products)	সম্পর্ক প্রকাশকারী টেবিল (Enrollments, Order_Items)

Composite Key ও Foreign Key-এর সম্পর্ক

⏱ শেখার অংশ

প্রতিটা Foreign Key আলাদা Parent টেবিলকে নির্দেশ করে, আর দুইটা মিলে Junction টেবিলের Composite Primary Key গঠন করে

Library Borrowing System

⏱ শেখার অংশ

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

CREATE TABLE Members (
    Member_ID  INT PRIMARY KEY,
    Name       VARCHAR(100)
);

CREATE TABLE Books (
    Book_ID    INT PRIMARY KEY,
    Title      VARCHAR(150)
);

CREATE TABLE Borrow_Records (
    Member_ID    INT,
    Book_ID      INT,
    Borrow_Date  DATE,
    Return_Date  DATE,
    PRIMARY KEY (Member_ID, Book_ID, Borrow_Date),
    FOREIGN KEY (Member_ID) REFERENCES Members(Member_ID),
    FOREIGN KEY (Book_ID)   REFERENCES Books(Book_ID)
);

কেন তিন কলামের Key

একই মেম্বার একই বই ভবিষ্যতে আবার ধার নিতে পারে — তাই শুধু Member_ID + Book_ID যথেষ্ট না। Borrow_Date যোগ করলে প্রতিটা ধার-নেওয়ার ঘটনা আলাদাভাবে রেকর্ড হয়।

চ্যালেঞ্জ: একই লজিক দিয়ে Online Order Management System অথবা University Course Registration System ডিজাইন করে দেখাও।

একজন Database Architect যেভাবে ভাবে

⏱ শেখার অংশ

Entity চিহ্নিত করো — কোনগুলো স্বাধীন এনটিটি (Student, Course), আর কোনগুলো সম্পর্ক (Enrollment)?
ন্যাচারাল Key খোঁজো — বিজনেস ডেটায় কি এমন কোনো কলাম-কম্বিনেশন আছে যা প্রকৃতিগতভাবেই ইউনিক?
স্থিতিশীলতা যাচাই করো — এই কলামগুলোর ভ্যালু কি ভবিষ্যতে বদলাতে পারে? বদলালে Composite Key ঝুঁকিপূর্ণ।
স্কেল বিবেচনা করো — টেবিলে লক্ষ লক্ষ row হলে Composite Key-এর উপর ভিত্তি করে JOIN কতটা দ্রুত হবে?
সিদ্ধান্ত নাও — Composite Key ব্যবহার করবে, নাকি Surrogate ID + Unique Constraint ব্যবহার করবে?

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

⏱ শেখার অংশ

#	প্রশ্ন	সংক্ষিপ্ত উত্তর
01	Composite Key কী?	দুই বা ততোধিক কলাম একসাথে মিলিয়ে তৈরি Primary Key, যা রেকর্ডকে ইউনিক করে।
02	Composite Key কখন দরকার হয়?	যখন একক কলাম যথেষ্ট নয়, বিশেষত many-to-many জাংশন টেবিলে।
03	Composite Key vs Primary Key পার্থক্য কী?	Composite Key হলো Primary Key-এর একটা বিশেষ রূপ যেখানে একাধিক কলাম মিলে Key তৈরি হয়।
04	Composite Key-তে NULL রাখা যায়?	না, কোনো অংশেই না।
05	একটা টেবিলে কয়টা Composite Key থাকতে পারে?	Primary Key হিসেবে একটাই, তবে অতিরিক্ত Composite Unique Key একাধিক থাকতে পারে।
06	Composite Key vs Unique Key?	Composite Key টেবিলের মূল আইডেন্টিটি; Unique Key শুধু ডুপ্লিকেট আটকায়।
07	Composite Foreign Key কী?	একাধিক কলাম মিলে অন্য টেবিলের Composite Primary Key-কে রেফারেন্স করা।
08	SQL-এ Composite Key কীভাবে তৈরি করবে?	`PRIMARY KEY (col1, col2)` CREATE TABLE-এর মধ্যে লিখে।
09	Composite Key-এর উদাহরণ দাও।	Order_ID + Product_ID, Student_ID + Course_ID।
10	Composite Key কেন Junction Table-এ ব্যবহার হয়?	Many-to-many সম্পর্ককে সঠিকভাবে ইউনিক করে রাখার জন্য।
11	Composite Key ডিজাইনে সবচেয়ে সাধারণ ভুল কী?	দরকারের চেয়ে বেশি বা কম কলাম Key-তে রাখা।
12	Composite Key-তে কলামের অর্ডার গুরুত্বপূর্ণ কেন?	Index পারফরম্যান্সে প্রভাব ফেলে — বেশি ব্যবহৃত ফিল্টার কলাম আগে রাখা ভালো।
13	Composite Key vs Surrogate Key — কোনটা ব্যবহার করবে?	ছোট, সরল সম্পর্কে Composite; বড়, জটিল বা বদলযোগ্য ডেটায় Surrogate।
14	Composite Key কি Index হিসেবেও কাজ করে?	হ্যাঁ, Primary Key স্বয়ংক্রিয়ভাবে একটা Index তৈরি করে।
15	Composite Key-তে কলাম বদলানো (Update) সম্ভব?	সম্ভব, কিন্তু ঝুঁকিপূর্ণ — Foreign Key রেফারেন্সগুলোও আপডেট করতে হয় (CASCADE)।
16	Duplicate Composite Key ইনসার্ট করলে কী হয়?	Error 1062 / Constraint Violation।
17	Composite Key কি একই কলাম দুইবার নিতে পারে?	না, প্রতিটা কলাম আলাদা হতে হবে।
18	Attendance সিস্টেমে Composite Key কী হবে?	Class + Roll_Number + Date।
19	Composite Key কি Normalization-এর সাথে সম্পর্কিত?	হ্যাঁ, সঠিক Composite Key ডিজাইন 2NF/3NF নিশ্চিত করতে সাহায্য করে।
20	একটা Composite Key-তে সর্বোচ্চ কয়টা কলাম রাখা যায়?	DB-নির্দিষ্ট সীমা আছে (যেমন MySQL-এ প্রযুক্তিগত সীমা বড়), কিন্তু ব্যবহারিকভাবে ২-৩টার বেশি এড়ানো উচিত।
21	Composite Key কি Auto-Increment হতে পারে?	না, Composite Key-এর কোনো কলামই সরাসরি Auto-Increment হতে পারে না MySQL-এ (নির্দিষ্ট শর্ত ছাড়া)।
22	Flight Booking সিস্টেমে Composite Key কী হবে?	Flight_Number + Date।
23	Composite Key কি JOIN পারফরম্যান্সে প্রভাব ফেলে?	হ্যাঁ, একাধিক কলামে JOIN করতে হয় বলে সিঙ্গেল-কলাম JOIN-এর তুলনায় কিছুটা ভারী হতে পারে।
24	Composite Key vs Candidate Key?	Candidate Key হলো Primary Key হওয়ার যোগ্য সব সম্ভাব্য কলাম/কম্বিনেশন; Composite Key হলো সেগুলোর একটা বিশেষ রূপ যেখানে একাধিক কলাম লাগে।
25	Movie Ticket Booking-এ Composite Key কী?	Show_ID + Seat_Number।
26	Composite Key কি বদলে ফেলা (drop) যায়?	হ্যাঁ, `ALTER TABLE ... DROP PRIMARY KEY` দিয়ে।
27	Composite Key ব্যবহারে বড় ভুল কী হতে পারে ক্যারিয়ারে?	বদলযোগ্য ডেটাকে Key বানিয়ে ফেলা — যেমন Email/Phone-এর মতো কলাম, যা পরে বদলাতে গিয়ে সমস্যা তৈরি করে।
28	Composite Key vs Composite Index?	Composite Key ইউনিকনেস নিশ্চিত করে; Composite Index শুধু Query স্পিড বাড়ায়, ইউনিকনেস বাধ্যতামূলক করে না।
29	একজন প্রফেশনাল কীভাবে Composite Key বনাম Surrogate Key সিদ্ধান্ত নেয়?	স্কেল, পারফরম্যান্স, মেইনটেইনেবিলিটি এবং বিজনেস স্থিতিশীলতা বিবেচনা করে।
30	Composite Key ডিজাইনের সবচেয়ে গুরুত্বপূর্ণ প্রশ্ন কী নিজেকে জিজ্ঞেস করা উচিত?	"কোন কলামগুলো ছাড়া এই রেকর্ড বাস্তবে ডুপ্লিকেট হয়ে যাবে?"

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

"তোমার আগের প্রজেক্টে কোথায় Composite Key ব্যবহার করেছিলে?" — নিজের একটা প্রজেক্ট উদাহরণ প্রস্তুত রাখো।
"কেন Surrogate Key না বেছে Composite Key বেছেছিলে (বা উল্টোটা)?" — ট্রেড-অফ ব্যাখ্যা করতে প্রস্তুত থাকো।
"Composite Key-তে Index কীভাবে কাজ করে?" — Leftmost Prefix Rule নিয়ে সংক্ষেপে পড়ে রাখো।

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

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

Composite Key vs Primary Key vs Unique Key

Composite Key vs Unique Key — একটা কমন কনফিউশন

চারটি ইন্ডাস্ট্রি, চারটি Composite Key

উদাহরণ ১ — Student Attendance

উদাহরণ ২ — Order Details (ই-কমার্স)

উদাহরণ ৩ — University Enrollment

উদাহরণ ৪ — Movie Ticket Booking

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

University Management System

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

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

প্রফেশনালরা কীভাবে সিদ্ধান্ত নেয়

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

Quick Revision Notes

Viva Questions

MCQ (উত্তরসহ)

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

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

Composite Key কেন গুরুত্বপূর্ণ হয়ে উঠলো

চারটি গুরুত্বপূর্ণ তুলনা টেবিল

1. Primary Key vs Composite Key

2. Composite Key vs Unique Key

3. Composite Key vs Surrogate Key (কনসেপ্চুয়াল)

4. Single-column vs Multi-column Keys

Composite Key ও Foreign Key-এর সম্পর্ক

Library Borrowing System

একজন Database Architect যেভাবে ভাবে

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