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

Primary Key কেন দরকার?

⏱ ১৫ মিনিট

🧑‍🏫 কল্পনা করো

একটা স্কুলে ১০,০০০ শিক্ষার্থী পড়ে। এর মধ্যে অনেকের নাম, বয়স, ক্লাস, রক্তের গ্রুপ একই হতে পারে — ধরো দুইজন শিক্ষার্থীর নামই "রাকিব আহমেদ"।

❓ স্কুল কীভাবে একজন নির্দিষ্ট শিক্ষার্থীকে আলাদা করে চিনবে?

❓ আমরা কি শুধু নাম দিয়ে শনাক্ত করতে পারি?

না, দুইজনের নাম একই হলে গুলিয়ে যাবে।

❓ দুইজন শিক্ষার্থীর নাম একই হলে কী সমস্যা হবে?

ভুল শিক্ষার্থীর রেজাল্ট বা তথ্য অন্যজনের সাথে গুলিয়ে যেতে পারে।

💡 বাস্তব জগতে আমরা এই সমস্যা কীভাবে সমাধান করি

এজন্যই প্রতিটা মানুষের একটা জাতীয় পরিচয়পত্র নম্বর থাকে, প্রতিটা পাসপোর্টের নিজস্ব নম্বর থাকে, প্রতিটা শিক্ষার্থীর রোল নম্বর থাকে, প্রতিটা কর্মচারীর আইডি থাকে। এগুলোর প্রতিটাই অনন্য (unique) — কারো সাথে কারো মিলবে না।

🪪

জাতীয় পরিচয়পত্র

📘

পাসপোর্ট নম্বর

🎓

রোল নম্বর

💼

কর্মচারী আইডি

📱

সিম নম্বর

ডেটাবেজেও ঠিক এই একই সমস্যা হয় — অনেক রেকর্ডের অনেক তথ্য একই রকম হতে পারে। এই সমস্যার সমাধান হলো Primary Key — এমন একটা কলাম, যা প্রতিটা রেকর্ডকে অনন্যভাবে শনাক্ত করে।

Students
(অনেকের নাম একই হতে পারে)

→

Unique Student ID
(Primary Key)

→

Correct Student Record
(সঠিক রেকর্ড শনাক্ত)

Primary Key কী?

⏱ ১৫ মিনিট

সংজ্ঞা: Primary Key হলো একটা টেবিলের এমন একটা কলাম (বা কলামের সমষ্টি), যার মান প্রতিটা রেকর্ডে অনন্য এবং কখনো ফাঁকা (NULL) থাকতে পারে না — এটা দিয়ে টেবিলের যেকোনো নির্দিষ্ট রেকর্ড সরাসরি শনাক্ত করা যায়।

Primary Key-এর নিয়মসমূহ

নিয়ম	ব্যাখ্যা
অবশ্যই Unique হতে হবে	দুইটা রেকর্ডে একই মান থাকতে পারবে না
NULL হতে পারবে না	প্রতিটা রেকর্ডে অবশ্যই একটা মান থাকতে হবে
প্রতি টেবিলে একটাই Primary Key	একটা টেবিলে একাধিক Primary Key রাখা যায় না
একাধিক কলাম নিয়েও হতে পারে	একে বলে Composite Primary Key — একসাথে একাধিক কলাম মিলিয়ে অনন্যতা তৈরি হয়

💡 Composite Primary Key উদাহরণ

একটা Enrollments টেবিলে যদি একা student_id বা একা course_id অনন্য না হয়, কিন্তু (student_id, course_id) একসাথে সবসময় অনন্য থাকে — তখন এই দুইটা কলাম একসাথে মিলে একটা Composite Primary Key হতে পারে।

student_id	name	class
1	রাকিব আহমেদ	৮
2	রাকিব আহমেদ	৯

লক্ষ্য করো, দুইজনের নাম একই "রাকিব আহমেদ" হলেও, তাদের student_id (হাইলাইট করা) আলাদা — তাই সহজেই আলাদা করে চেনা যাচ্ছে।

ইন্টারঅ্যাক্টিভ ল্যাব

PK Picker — কোন কলাম Primary Key হতে পারে?

Unique + NOT NULL + স্থিতিশীল কিনা বিচার করে বেছে নাও।

ইন্টারঅ্যাক্টিভ ল্যাব

Composite Key Checker — (student_id, course_id)

একই জোড়া আবার INSERT করলে এরর; আলাদা জোড়া OK।

student_id course_id

Primary Key তৈরি করা

⏱ ২০ মিনিট

টেবিল তৈরির সময় Primary Key নির্ধারণ

SQL কোড

CREATE TABLE Students ( student_id INT PRIMARY KEY, name VARCHAR(50), class INT );

আউটপুট

Query OK, 0 rows affected. (টেবিল তৈরি হয়েছে, student_id এখন Primary Key)

ব্যাখ্যা: student_id INT PRIMARY KEY বলছে এই কলামটাই টেবিলের অনন্য শনাক্তকারী হবে।

বিদ্যমান টেবিলে Primary Key যোগ করা

SQL কোড

ALTER TABLE Students ADD PRIMARY KEY (student_id);

আউটপুট

Query OK, 0 rows affected. (Primary Key যোগ হলো)

ব্যাখ্যা: যদি টেবিল আগে থেকেই তৈরি থাকে কিন্তু Primary Key না থাকে, ALTER TABLE দিয়ে পরে যোগ করা যায়।

AUTO_INCREMENT-সহ Primary Key

SQL কোড

CREATE TABLE Students ( student_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) );

আউটপুট

Query OK, 0 rows affected. (student_id স্বয়ংক্রিয়ভাবে বাড়তে থাকবে)

⚠️ সাধারণ শুরুর ভুল:

একটা টেবিলে একাধিক কলামে আলাদা আলাদাভাবে PRIMARY KEY লেখার চেষ্টা করা (একটা টেবিলে মাত্র একটাই Primary Key থাকতে পারে, তবে তা একাধিক কলাম নিয়ে গঠিত হতে পারে)
ইতিমধ্যে ডুপ্লিকেট মান থাকা কলামকে সরাসরি Primary Key বানানোর চেষ্টা করা, যা এরর দেয়

✅ Best Practice

টেবিল তৈরির সময়ই Primary Key নির্ধারণ করা ভালো অভ্যাস, পরে যোগ করার চেয়ে শুরুতেই পরিকল্পনা করা সহজ ও নিরাপদ।

ইন্টারঅ্যাক্টিভ ল্যাব

Insert Simulator — Duplicate / NULL PK

Students টেবিলে INSERT চেষ্টা করো। ডুপ্লিকেট বা NULL PK হলে এরর দেখাবে।

student_id (PK) name

AUTO_INCREMENT বোঝা

⏱ ১৫ মিনিট

🧑‍🏫 কল্পনা করো

প্রতিদিন নতুন নতুন শিক্ষার্থী ভর্তি হচ্ছে। প্রতিবার তুমি যদি নিজে হাতে ভাবতে হয় "এবার কোন নম্বরটা দেবো?", ভুল হওয়ার সম্ভাবনা অনেক বেশি — হয়তো দুইজনকে একই নম্বর দিয়ে ফেলবে, বা কোনো নম্বর বাদ যাবে।

Student 1

→

Student 2

→

Student 3

↓

AUTO_INCREMENT

↓

১, ২, ৩ ... স্বয়ংক্রিয়ভাবে তৈরি

সংজ্ঞা: AUTO_INCREMENT একটা বৈশিষ্ট্য, যা প্রতিটা নতুন রেকর্ডের জন্য স্বয়ংক্রিয়ভাবে আগের চেয়ে ১ বেশি একটা সংখ্যা বসিয়ে দেয় — কাউকে হাতে নম্বর ঠিক করতে হয় না।

SQL কোড

INSERT INTO Students (name) VALUES ('রিমা'); INSERT INTO Students (name) VALUES ('সাকিব');

ফলাফল

student_id	name
1	রিমা
2	সাকিব

ব্যাখ্যা: লক্ষ্য করো, আমরা student_id-এর মান নিজে দিইনি, সেটা নিজে থেকেই ১ ও ২ হয়ে গেছে।

💡 বাস্তব ব্যবহার

ব্যাংক অ্যাকাউন্ট নম্বর, অর্ডার আইডি, ইনভয়েস নম্বর — এসবের অনেকগুলোই AUTO_INCREMENT দিয়ে স্বয়ংক্রিয়ভাবে তৈরি হয়, যাতে মানুষের ভুলের সুযোগ কমে যায়।

Primary Key বনাম অন্যান্য কলাম

⏱ ১৫ মিনিট

প্রশ্ন হলো — Students টেবিলে কোন কলামটা Primary Key হওয়া উচিত?

কলাম	Primary Key হতে পারে?	কারণ
Student ID	✅ হ্যাঁ	প্রতিটা শিক্ষার্থীর জন্য অনন্য ও কখনো পরিবর্তিত হয় না
Name	❌ না	একাধিক শিক্ষার্থীর নাম একই হতে পারে
Phone Number	⚠️ ঝুঁকিপূর্ণ	ফোন নম্বর পরিবর্তন হতে পারে, এবং কিছু ক্ষেত্রে শেয়ার্ড হতে পারে
Email	⚠️ সম্ভব কিন্তু কম প্রচলিত	অনন্য হতে পারে, কিন্তু পরিবর্তনযোগ্য বলে সরাসরি Primary Key হিসেবে কম ব্যবহৃত হয়
National ID	⚠️ সম্ভব	প্রকৃতপক্ষে অনন্য, কিন্তু সংবেদনশীল তথ্য হওয়ায় সরাসরি Key হিসেবে ব্যবহারে সতর্কতা প্রয়োজন

🔑 মূল নীতি

একটা ভালো Primary Key হবে এমন একটা মান, যা কখনো বদলায় না, সবসময় অনন্য থাকে, এবং কখনো ফাঁকা থাকে না। এই কারণেই বেশিরভাগ ক্ষেত্রে সিস্টেম নিজে তৈরি করা একটা সাধারণ ID (যেমন AUTO_INCREMENT সহ INT) সবচেয়ে নিরাপদ পছন্দ।

Primary Key বনাম Unique Key

⏱ ১৫ মিনিট

🧑‍🏫 কল্পনা করো

একজন শিক্ষার্থীর একটাই Student ID থাকে (Primary Key), কিন্তু তার ইমেইলও অনন্য হতে হবে (Unique Key) — যদিও ইমেইল দিয়ে তাকে "প্রধান পরিচয়" হিসেবে ব্যবহার করা হচ্ছে না।

বিষয়	PRIMARY KEY	UNIQUE KEY
NULL মান	অনুমোদিত না	একটা NULL মান অনুমোদিত (ডেটাবেজভেদে ভিন্ন হতে পারে)
প্রতি টেবিলে সংখ্যা	মাত্র ১টা	একাধিক থাকতে পারে
অনন্যতা (Uniqueness)	বাধ্যতামূলক	বাধ্যতামূলক
উদ্দেশ্য	রেকর্ডের প্রধান শনাক্তকারী	অতিরিক্ত কলামে ডুপ্লিকেট আটকানো
বাস্তব উদাহরণ	student_id	email, national_id

SQL উদাহরণ

CREATE TABLE Students ( student_id INT PRIMARY KEY, email VARCHAR(100) UNIQUE, name VARCHAR(50) );

ব্যাখ্যা: এখানে student_id হলো Primary Key (প্রধান শনাক্তকারী), আর email-এ UNIQUE বসিয়ে নিশ্চিত করা হলো দুইজন শিক্ষার্থীর ইমেইল একই হতে পারবে না, যদিও এটা প্রধান শনাক্তকারী নয়।

বিজনেস কেস স্টাডি: হাসপাতাল ম্যানেজমেন্ট সিস্টেম

⏱ ২০ মিনিট

টেবিল	Primary Key	কেন এটাই যুক্তিসঙ্গত
Patients	patient_id	রোগীর নাম বা ফোন নম্বর ডুপ্লিকেট হতে পারে, কিন্তু patient_id সবসময় অনন্য
Doctors	doctor_id	দুইজন ডাক্তারের নাম একই হতে পারে
Appointments	appointment_id	একজন রোগীর একাধিক অ্যাপয়েন্টমেন্ট থাকতে পারে, তাই আলাদা অনন্য আইডি দরকার
Medicines	medicine_id	একই নামের ওষুধ ভিন্ন ব্যাচে থাকতে পারে, তাই আলাদা আইডি প্রয়োজন

টেবিলগুলোর সম্পর্ক (Primary/Foreign Key)

Patients

patient_idPK

১ → বহু

Appointments

appointment_idPK

patient_idFK

doctor_idFK

বহু ← ১

Doctors

doctor_idPK

লক্ষ্য করো, Appointments টেবিলের নিজস্ব Primary Key (appointment_id) আছে, এবং একইসাথে সে Patients ও Doctors-এর Primary Key-কে Foreign Key হিসেবে ব্যবহার করে সংযুক্ত হয়েছে।

MySQL Workbench প্র্যাকটিক্যাল সেশন

⏱ প্র্যাকটিক্যাল

ধাপ ১: Database ও টেবিল তৈরি

CREATE DATABASE SchoolDB; USE SchoolDB; CREATE TABLE Students ( student_id INT PRIMARY KEY, name VARCHAR(50) );

আউটপুট

Query OK, 0 rows affected.

ধাপ ২: রেকর্ড যোগ করা

INSERT INTO Students VALUES (1, 'রিমা'); INSERT INTO Students VALUES (2, 'সাকিব');

আউটপুট

2 rows inserted successfully.

ধাপ ৩: ডুপ্লিকেট Primary Key দেওয়ার চেষ্টা করা

SQL কোড

INSERT INTO Students VALUES (1, 'তানভীর');

এরর মেসেজ

🚨 ডেটাবেজ এরর

Error: Duplicate entry '1' for key 'PRIMARY'

ব্যাখ্যা: student_id=1 ইতিমধ্যে "রিমা"-র জন্য ব্যবহৃত হয়েছে। যেহেতু Primary Key-এর মান কখনো ডুপ্লিকেট হতে পারে না, ডেটাবেজ এই ইনসার্ট প্রত্যাখ্যান করে দিলো — এটাই Primary Key-এর সবচেয়ে গুরুত্বপূর্ণ সুরক্ষা।

ধাপ ৪: NULL মান দেওয়ার চেষ্টা করা

SQL কোড

INSERT INTO Students (name) VALUES ('করিম');

এরর মেসেজ (যদি student_id-এ AUTO_INCREMENT না থাকে)

🚨 ডেটাবেজ এরর

Error: Field 'student_id' doesn't have a default value

ব্যাখ্যা: Primary Key কখনো ফাঁকা (NULL) থাকতে পারে না, তাই student_id না দিলে (এবং AUTO_INCREMENT না থাকলে) এরর আসবে।

ধাপ ৫: AUTO_INCREMENT দেখে নেওয়া

SQL কোড

CREATE TABLE Teachers ( teacher_id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) ); INSERT INTO Teachers (name) VALUES ('রফিক স্যার'); SELECT * FROM Teachers;

আউটপুট

teacher_id	name
1	রফিক স্যার

ব্যাখ্যা: এবার আমরা teacher_id নিজে দিইনি, AUTO_INCREMENT থাকায় এটা নিজে থেকেই ১ হয়ে গেছে।

⚠️ সাধারণ শুরুর ভুল:

একই Primary Key মান বারবার ব্যবহার করার চেষ্টা করা
AUTO_INCREMENT না থাকা অবস্থায় Primary Key কলামের মান বাদ দিয়ে ইনসার্ট করা

সাধারণ শুরুর ভুল

⏱ আলোচনা

❌ Primary Key ঠিক করতেই ভুলে যাওয়া

✅ সমাধান: প্রতিটা টেবিল ডিজাইন করার সময় প্রথমেই ভাবো — "কোন কলাম দিয়ে প্রতিটা রেকর্ড অনন্যভাবে চেনা যাবে?"

❌ Name-কে Primary Key বানানো

✅ সমাধান: নাম কখনো Primary Key হওয়া উচিত না, কারণ একাধিক মানুষের নাম একই হতে পারে।

❌ ডুপ্লিকেট মান ঢোকানোর চেষ্টা করা

✅ সমাধান: ইনসার্ট করার আগে নিশ্চিত হও যে মানটা ইতিমধ্যে টেবিলে নেই।

❌ Primary Key কলামে NULL দেওয়ার চেষ্টা করা

✅ সমাধান: মনে রাখো Primary Key কখনো ফাঁকা থাকতে পারে না।

❌ Primary Key ও Foreign Key গুলিয়ে ফেলা

✅ সমাধান: Primary Key নিজের টেবিলে অনন্য পরিচয় দেয়, Foreign Key অন্য টেবিলকে রেফার করে।

❌ প্রয়োজন থাকলেও AUTO_INCREMENT ব্যবহার না করা

✅ সমাধান: যেখানে সিস্টেম নিজে ID তৈরি করলেই চলবে, সেখানে AUTO_INCREMENT ব্যবহার করে মানুষের ভুলের ঝুঁকি কমাও।

❌ Primary Key-এর মান বার বার পরিবর্তন করা

✅ সমাধান: Primary Key-এর মান যতটা সম্ভব স্থিতিশীল (stable) রাখা উচিত, কারণ অন্য টেবিল এটাকে Foreign Key হিসেবে ব্যবহার করতে পারে।

ইন্ডাস্ট্রি বেস্ট প্র্যাকটিস

⏱ আলোচনা

Surrogate Key বনাম Natural Key (প্রাথমিক ধারণা)

বিষয়	Surrogate Key	Natural Key
উৎস	সিস্টেম নিজে তৈরি করে (যেমন AUTO_INCREMENT)	বাস্তব জগতের ডেটা থেকে আসে (যেমন National ID, Email)
অর্থপূর্ণতা	নিজে থেকে কোনো অর্থ বহন করে না, শুধু শনাক্তকরণের জন্য	বাস্তব জগতে একটা অর্থ বহন করে
পরিবর্তনের ঝুঁকি	কম, কারণ ব্যবসার নিয়মের সাথে সম্পর্কহীন	বেশি, কারণ বাস্তব ডেটা মাঝে মাঝে পরিবর্তিত হতে পারে
উদাহরণ	student_id (AUTO_INCREMENT)	national_id

💡 কেন Surrogate Key বেশি ব্যবহৃত হয়

Natural Key (যেমন Email) কোনো কারণে বদলে যেতে পারে (কেউ ইমেইল পরিবর্তন করলে), যা ডেটাবেজে জটিলতা তৈরি করে। কিন্তু একটা সিস্টেম-তৈরি Surrogate Key কখনো বদলায় না, তাই এটা বেশি স্থিতিশীল ও নিরাপদ পছন্দ।

Integer বনাম UUID (ধারণাগত)

বিষয়	Integer (যেমন AUTO_INCREMENT)	UUID
আকার	ছোট, জায়গা কম নেয়	বড়, বেশি জায়গা নেয়
অনুমানযোগ্যতা	ক্রমিক, সহজে অনুমান করা যায়	এলোমেলো, অনুমান করা কঠিন
ব্যবহার	একক সার্ভার সিস্টেমে বেশি প্রচলিত	একাধিক সার্ভার/ডিস্ট্রিবিউটেড সিস্টেমে বেশি উপযোগী

🏷️ নামকরণের নিয়ম

Primary Key কলামের নাম সাধারণত tablename_id প্যাটার্নে রাখা (যেমন student_id)

⚡ পারফরম্যান্স বিবেচনা

ছোট, সংখ্যাভিত্তিক Primary Key সাধারণত দ্রুত খোঁজা ও যুক্ত করা যায়

📈 স্কেলেবিলিটি

ভবিষ্যতে ডেটা অনেক বাড়লেও Primary Key যেন যথেষ্ট বড় রেঞ্জ ধারণ করতে পারে তা বিবেচনা করা

🔒 স্থিতিশীল শনাক্তকারী

Primary Key এমন হওয়া উচিত যা ব্যবসার নিয়ম পরিবর্তনের সাথে বদলায় না

ক্লাসরুম অ্যাক্টিভিটি

⏱ ইন্টারেক্টিভ

অ্যাক্টিভিটি ১ (সঠিক Primary Key বাছাই): কয়েকটা বিজনেস সিনারিও দাও ("একটা লাইব্রেরি সিস্টেম", "একটা হোটেল বুকিং সিস্টেম") এবং শিক্ষার্থীদের সঠিক Primary Key বাছতে বলা।

অ্যাক্টিভিটি ২ (অবৈধ Primary Key খুঁজে বের করা): কিছু কলাম নাম (Name, Phone, National ID, Auto ID) দিয়ে কোনটা Primary Key হিসেবে অনুপযুক্ত তা চিহ্নিত করতে বলা।

অ্যাক্টিভিটি ৩ (টেবিল ডিজাইন): একটা "Gym Membership System"-এর জন্য উপযুক্ত Primary Key সহ একটা টেবিল ডিজাইন করতে বলা।

অ্যাক্টিভিটি ৪ (ফলাফল অনুমান): ডুপ্লিকেট Primary Key মান দিয়ে ইনসার্ট করলে কী হবে তা অনুমান করতে বলা।

অ্যাক্টিভিটি ৫ (মেলানো): কিছু বিজনেস Entity (Student, Product, Order) ও সম্ভাব্য Primary Key মেলাতে বলা।

রিভিশন ও প্রশ্নোত্তর

⏱ শেষ পর্যালোচনা

📌 দ্রুত রিভিশন নোট

Primary Key = অনন্য, NULL-হীন শনাক্তকারী, প্রতি টেবিলে একটাই
AUTO_INCREMENT স্বয়ংক্রিয়ভাবে ক্রমবর্ধমান ID তৈরি করে
Name/Phone সাধারণত Primary Key হিসেবে অনুপযুক্ত (ডুপ্লিকেট/পরিবর্তনযোগ্য হতে পারে)
Primary Key vs Unique Key: Primary Key ১টা মাত্র ও NULL-হীন, Unique Key একাধিক থাকতে পারে
Surrogate Key (সিস্টেম-তৈরি) সাধারণত Natural Key-এর চেয়ে বেশি স্থিতিশীল

🗺️ সম্পূর্ণ Primary Key ভিজ্যুয়ালাইজেশন

Database

→

Table

→

Primary Key

→

Rows
(প্রতিটা অনন্যভাবে শনাক্তযোগ্য)

Primary Key ডুপ্লিকেট রেকর্ড আটকে দেয় — এই একটামাত্র নিয়মই ডেটাবেজের নির্ভরযোগ্যতার ভিত্তি তৈরি করে।

🕰️ Primary Key-এর সংক্ষিপ্ত ইতিহাস

আগে কাগজের রেজিস্টারে মানুষ হাতে হাতে ক্রমিক নম্বর দিতো, যা ভুলের ঝুঁকিতে পূর্ণ ছিলো। ১৯৭০-এর দশকে Relational Database Model আসার সাথে সাথে "প্রতিটা রেকর্ডের একটা অনন্য শনাক্তকারী থাকতে হবে" — এই ধারণা প্রথমবারের মতো আনুষ্ঠানিকভাবে প্রতিষ্ঠিত হয়। আজকের আধুনিক ডিস্ট্রিবিউটেড সিস্টেমে (যেখানে একাধিক সার্ভার একসাথে কাজ করে), এই ধারণা আরও বিস্তৃত হয়ে UUID-এর মতো নতুন ধরনের অনন্য শনাক্তকারীর জন্ম দিয়েছে।

📊 তুলনামূলক টেবিলসমূহ

বিষয়	PRIMARY KEY	FOREIGN KEY
উদ্দেশ্য	নিজের টেবিলে অনন্য পরিচয় দেয়	অন্য টেবিলকে রেফার করে সংযুক্ত করে
NULL অনুমোদিত?	না	হ্যাঁ (সাধারণত)
ডুপ্লিকেট?	না	হ্যাঁ, একই মান একাধিকবার থাকতে পারে

বিষয়	AUTO_INCREMENT	Manual ID
ID তৈরি	স্বয়ংক্রিয়	ম্যানুয়ালি লিখতে হয়
ভুলের ঝুঁকি	কম	বেশি (ডুপ্লিকেট হতে পারে)
ব্যবহার	সাধারণ, বেশিরভাগ ক্ষেত্রে সুপারিশকৃত	বিশেষ প্রয়োজনে (যেমন নির্দিষ্ট ফরম্যাটের কোড)

👥 প্রফেশনাল ওয়ার্কফ্লো

Database Administrator
Primary Key-এর মাধ্যমে ডেটার সঠিকতা নিশ্চিত করেন

→

Data Engineer
Primary/Foreign Key দিয়ে টেবিল সংযুক্ত করেন

→

Data Scientist
Primary Key ব্যবহার করে বিভিন্ন ডেটাসেট মিলিয়ে বিশ্লেষণ করেন

❓ ভাইভা প্রশ্ন

১. Primary Key কী?

এমন একটা কলাম যার মান প্রতিটা রেকর্ডে অনন্য ও কখনো NULL হতে পারে না।

২. একটা টেবিলে কয়টা Primary Key থাকতে পারে?

একটাই, তবে সেটা একাধিক কলাম নিয়ে গঠিত (Composite) হতে পারে।

৩. Name-কে কেন Primary Key বানানো উচিত না?

একাধিক মানুষের নাম একই হতে পারে।

৪. AUTO_INCREMENT কী করে?

প্রতিটা নতুন রেকর্ডে স্বয়ংক্রিয়ভাবে ক্রমবর্ধমান একটা সংখ্যা বসায়।

৫. Primary Key ও Unique Key-এর মূল পার্থক্য কী?

Primary Key ১টা মাত্র ও NULL-হীন, Unique Key একাধিক থাকতে পারে ও কিছু ক্ষেত্রে একটা NULL অনুমোদিত।

💼 ইন্টারভিউ প্রস্তুতি — টপ ৩০টি বিগিনার লেভেল প্রশ্ন

১. Primary Key কী?

একটা টেবিলের কলাম যা প্রতিটা রেকর্ডকে অনন্যভাবে শনাক্ত করে।

২. Primary Key-এর প্রধান দুইটা নিয়ম কী কী?

অবশ্যই Unique হতে হবে এবং NULL হতে পারবে না।

৩. Composite Primary Key কী?

একাধিক কলাম মিলিয়ে তৈরি একটা Primary Key, যেখানে একসাথে সবসময় অনন্য থাকে।

৪. AUTO_INCREMENT ব্যবহারের সুবিধা কী?

ম্যানুয়ালি ID লেখার ভুল ও ডুপ্লিকেটের ঝুঁকি কমে।

৫. Duplicate Primary Key মান ঢোকানোর চেষ্টা করলে কী হয়?

ডেটাবেজ এরর দেয় এবং ইনসার্ট প্রত্যাখ্যান করে।

৬. Primary Key কলামে NULL ঢোকানোর চেষ্টা করলে কী হয়?

ডেটাবেজ এরর দেয়, কারণ Primary Key কখনো ফাঁকা থাকতে পারে না।

৭. Primary Key ও Foreign Key-এর পার্থক্য কী?

Primary Key নিজের টেবিলে অনন্য পরিচয় দেয়, Foreign Key অন্য টেবিলকে রেফার করে।

৮. Primary Key ও Unique Key-এর একটা পার্থক্য বলো।

একটা টেবিলে মাত্র একটা Primary Key থাকতে পারে, কিন্তু একাধিক Unique Key থাকতে পারে।

৯. Surrogate Key কী?

সিস্টেম নিজে তৈরি করা একটা কৃত্রিম শনাক্তকারী, যেমন AUTO_INCREMENT ID।

১০. Natural Key কী?

বাস্তব জগতের ডেটা থেকে আসা শনাক্তকারী, যেমন National ID বা Email।

১১. Surrogate Key কেন Natural Key-এর চেয়ে বেশি জনপ্রিয়?

এটা কখনো বদলায় না, তাই বেশি স্থিতিশীল ও নিরাপদ।

১২. একটা Order টেবিলের জন্য কোন কলাম Primary Key হওয়া উচিত?

order_id, কারণ এটা প্রতিটা অর্ডারের জন্য অনন্য।

১৩. Email কি সবসময় Primary Key হতে পারে?

টেকনিক্যালি সম্ভব হলেও, ইমেইল পরিবর্তনযোগ্য হওয়ায় এটা সাধারণত সুপারিশ করা হয় না।

১৪. ALTER TABLE দিয়ে Primary Key যোগ করার সিনট্যাক্স কী?

ALTER TABLE table_name ADD PRIMARY KEY (column_name);

১৫. UUID কী?

একটা দীর্ঘ, এলোমেলো অনন্য শনাক্তকারী, যা ডিস্ট্রিবিউটেড সিস্টেমে জনপ্রিয়।

১৬. Integer Primary Key-এর একটা সুবিধা কী?

ছোট, দ্রুত খোঁজা ও কম জায়গা নেয়।

১৭. একটা Enrollments টেবিলে Composite Primary Key কেন দরকার হতে পারে?

কারণ একা student_id বা course_id অনন্য না হলেও, দুইটা একসাথে অনন্য হতে পারে।

১৮. Primary Key পরিবর্তনযোগ্য হওয়া কেন ঝুঁকিপূর্ণ?

অন্য টেবিল এটাকে Foreign Key হিসেবে রেফার করতে পারে, পরিবর্তন হলে সংযোগ ভেঙে যেতে পারে।

১৯. Primary Key ছাড়া একটা টেবিল কি চলতে পারে?

টেকনিক্যালি সম্ভব, কিন্তু সেক্ষেত্রে ডুপ্লিকেট রেকর্ড আটকানো এবং সঠিক রেকর্ড শনাক্ত করা কঠিন হয়ে যায়।

২০. একটা ভালো Primary Key-এর বৈশিষ্ট্য কী কী?

অনন্য, স্থিতিশীল (বদলায় না), ও কখনো ফাঁকা না।

২১. Database Administrator Primary Key নিয়ে কী দায়িত্ব পালন করেন?

নিশ্চিত করেন প্রতিটা টেবিলে সঠিক Primary Key আছে এবং ডেটার সঠিকতা বজায় আছে।

২২. Data Engineer Primary/Foreign Key নিয়ে কী কাজ করেন?

টেবিলগুলোর মধ্যে সঠিক সম্পর্ক ও সংযোগ তৈরি করেন।

২৩. Data Scientist কীভাবে Primary Key ব্যবহার করেন?

বিভিন্ন টেবিলের ডেটা Primary/Foreign Key দিয়ে মিলিয়ে (join করে) বিশ্লেষণ করেন।

২৪. Primary Key তৈরি না করলে বাস্তবে কী সমস্যা হতে পারে?

ডুপ্লিকেট রেকর্ড তৈরি হতে পারে এবং নির্দিষ্ট রেকর্ড শনাক্ত করা কঠিন হয়ে যায়।

২৫. Primary Key নামকরণে সাধারণ প্রচলিত নিয়ম কী?

সাধারণত tablename_id ফরম্যাটে রাখা হয় (যেমন student_id)।

২৬. একটা টেবিলে PRIMARY KEY সংজ্ঞায়িত না থাকলে ডুপ্লিকেট এন্ট্রি কি সম্ভব?

হ্যাঁ, PRIMARY KEY বা UNIQUE constraint ছাড়া ডুপ্লিকেট এন্ট্রি সহজেই ঢুকে যেতে পারে।

২৭. National ID-কে Primary Key হিসেবে ব্যবহার করার একটা ঝুঁকি কী?

এটা সংবেদনশীল ব্যক্তিগত তথ্য, তাই সরাসরি প্রকাশ বা ব্যবহারে নিরাপত্তা ঝুঁকি থাকতে পারে।

২৮. একটা Hospital System-এ Patients টেবিলের Primary Key কী হতে পারে?

patient_id।

২৯. Primary Key কি একটা টেবিলে একাধিকবার পরিবর্তন করা উচিত?

না, এটা যতটা সম্ভব স্থিতিশীল রাখা উচিত।

৩০. কেন Primary Key-কে বলা হয় ডেটাবেজের "ভিত্তি"?

কারণ এটা ডেটার সঠিকতা, ডুপ্লিকেট প্রতিরোধ, এবং টেবিলগুলোর মধ্যে সংযোগের ভিত্তি তৈরি করে।

✅ MCQ প্র্যাকটিস

১. Primary Key কলামে কোন মান অনুমোদিত না?
(ক) সংখ্যা (খ) NULL (গ) লেখা (ঘ) তারিখ

উত্তর: (খ) NULL

২. একটা টেবিলে সর্বোচ্চ কয়টা Primary Key থাকতে পারে?
(ক) ১ (খ) ২ (গ) ৩ (ঘ) যতগুলো ইচ্ছা

উত্তর: (ক) ১

৩. AUTO_INCREMENT কী কাজ করে?
(ক) মান মুছে ফেলে (খ) স্বয়ংক্রিয়ভাবে ক্রমবর্ধমান মান তৈরি করে (গ) ডেটা সাজায় (ঘ) টেবিল মুছে ফেলে

উত্তর: (খ) স্বয়ংক্রিয়ভাবে ক্রমবর্ধমান মান তৈরি করে

৪. দুইটা রেকর্ডে একই Primary Key মান দেওয়ার চেষ্টা করলে কী হয়?
(ক) স্বাভাবিকভাবে ঢুকে যায় (খ) ডেটাবেজ এরর দেয় (গ) দ্বিতীয় রেকর্ডটা মুছে যায় (ঘ) কিছুই হয় না

উত্তর: (খ) ডেটাবেজ এরর দেয়

৫. নিচের কোনটি সাধারণত ভালো Primary Key নয়?
(ক) student_id (AUTO_INCREMENT) (খ) name (গ) order_id (ঘ) patient_id

উত্তর: (খ) name

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

একটা "Hospital Management System"-এর জন্য Patients, Doctors, Appointments, Medicines — প্রতিটা টেবিলের জন্য উপযুক্ত Primary Key নির্ধারণ করে সেই সাথে SQL কোড লেখো।
একটা কল্পিত টেবিল ডিজাইন করো যেখানে ভুল করে Name-কে Primary Key বানানো হয়েছে, এবং লেখো কেন এটা সমস্যা তৈরি করবে (কমপক্ষে ২টা বাস্তব উদাহরণ দিয়ে)।
Primary Key vs Unique Key এবং Surrogate Key vs Natural Key — এই দুইটা পার্থক্য নিজের ভাষায় মোট ৫টা বাক্যে লেখো।

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

Primary Key কেন দরকার?

❓ স্কুল কীভাবে একজন নির্দিষ্ট শিক্ষার্থীকে আলাদা করে চিনবে?

❓ আমরা কি শুধু নাম দিয়ে শনাক্ত করতে পারি?

❓ দুইজন শিক্ষার্থীর নাম একই হলে কী সমস্যা হবে?

Primary Key কী?

Primary Key-এর নিয়মসমূহ

PK Picker — কোন কলাম Primary Key হতে পারে?

Composite Key Checker — (student_id, course_id)

Primary Key তৈরি করা

টেবিল তৈরির সময় Primary Key নির্ধারণ

বিদ্যমান টেবিলে Primary Key যোগ করা

AUTO_INCREMENT-সহ Primary Key

Insert Simulator — Duplicate / NULL PK

AUTO_INCREMENT বোঝা

Primary Key বনাম অন্যান্য কলাম

Primary Key বনাম Unique Key

বিজনেস কেস স্টাডি: হাসপাতাল ম্যানেজমেন্ট সিস্টেম

টেবিলগুলোর সম্পর্ক (Primary/Foreign Key)

MySQL Workbench প্র্যাকটিক্যাল সেশন

ধাপ ১: Database ও টেবিল তৈরি

ধাপ ২: রেকর্ড যোগ করা

ধাপ ৩: ডুপ্লিকেট Primary Key দেওয়ার চেষ্টা করা

ধাপ ৪: NULL মান দেওয়ার চেষ্টা করা

ধাপ ৫: AUTO_INCREMENT দেখে নেওয়া

সাধারণ শুরুর ভুল

ইন্ডাস্ট্রি বেস্ট প্র্যাকটিস

Surrogate Key বনাম Natural Key (প্রাথমিক ধারণা)

Integer বনাম UUID (ধারণাগত)

🏷️ নামকরণের নিয়ম

⚡ পারফরম্যান্স বিবেচনা

📈 স্কেলেবিলিটি

🔒 স্থিতিশীল শনাক্তকারী

ক্লাসরুম অ্যাক্টিভিটি

রিভিশন ও প্রশ্নোত্তর

📌 দ্রুত রিভিশন নোট

🗺️ সম্পূর্ণ Primary Key ভিজ্যুয়ালাইজেশন

🕰️ Primary Key-এর সংক্ষিপ্ত ইতিহাস

📊 তুলনামূলক টেবিলসমূহ

👥 প্রফেশনাল ওয়ার্কফ্লো

❓ ভাইভা প্রশ্ন

💼 ইন্টারভিউ প্রস্তুতি — টপ ৩০টি বিগিনার লেভেল প্রশ্ন

✅ MCQ প্র্যাকটিস

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