টেবিল কেন দরকার?
একটা স্কুলে ৫,০০০ শিক্ষার্থী পড়ে। স্কুলকে রাখতে হয় প্রতিটা শিক্ষার্থীর আইডি, নাম, ক্লাস, সেকশন, ফোন নম্বর, ঠিকানা ও ফলাফল।
❓ আমরা কি সব তথ্য একটা খাতায় এলোমেলোভাবে লিখতে পারি?
পারি, কিন্তু পরে খুঁজে পাওয়া প্রায় অসম্ভব হয়ে যাবে।
❓ একজন নির্দিষ্ট শিক্ষার্থীর তথ্য কীভাবে দ্রুত খুঁজে বের করবো?
তথ্য যদি সুসংগঠিতভাবে সাজানো থাকে তবেই দ্রুত পাওয়া সম্ভব।
❓ হাজার হাজার নতুন শিক্ষার্থী ভর্তি হলে কী হবে?
এলোমেলো খাতায় এটা সামলানো অসম্ভব হয়ে পড়বে।
স্কুলে হাজিরা নেওয়ার সময় শিক্ষক একটা খাতায় সারি করে প্রতিটা শিক্ষার্থীর নাম লেখেন, আর কলাম করে প্রতিদিনের হাজিরা চিহ্ন দেন। এটা এলোমেলো লেখার চেয়ে অনেক দ্রুত পড়া ও বোঝা যায় — কারণ এটা একটা "সারি-কলাম" কাঠামোতে সাজানো।
একইভাবে, একটা এক্সেল স্প্রেডশিট, একটা ক্লাস রেজাল্ট শিট, বা একটা হাসপাতালের রোগী রেজিস্টার — এই সবগুলোই সারি ও কলামে তথ্য সাজানোর উদাহরণ। ডেটাবেজেও ঠিক এই একই ধরনের কাঠামো ব্যবহার হয়, যাকে বলে Table।
এলোমেলো তথ্য
সারি-কলামে সাজানো
ডেটাবেজে সংরক্ষিত কাঠামো
Table কী?
সংজ্ঞা: Table হলো ডেটাবেজের সেই কাঠামো, যেখানে একই ধরনের তথ্য সারি (Row) ও কলামের (Column) মধ্যে সুসংগঠিতভাবে রাখা হয়।
একটা Students টেবিলের গঠন
| student_id | name | class |
|---|---|---|
| 1 | রিমা | ৮ |
| 2 | সাকিব | ৯ |
(Field/Attribute)
(Record)
(একক মান)
| টার্ম | সহজ সংজ্ঞা | উদাহরণ |
|---|---|---|
| Table | একই ধরনের তথ্যের পুরো সংগ্রহ | Students টেবিল |
| Row (Record) | একজন/একটার সম্পূর্ণ তথ্য | "১, রিমা, ৮" — একটা সম্পূর্ণ সারি |
| Column (Field/Attribute) | একটা নির্দিষ্ট বৈশিষ্ট্য | শুধু "name" কলাম |
| Cell | একটা নির্দিষ্ট সারি ও কলামের ছেদবিন্দুতে থাকা একক মান | সাকিবের "class" ঘরে থাকা "৯" |
SQL-এ টেবিল তৈরি করা
লাইন-বাই-লাইন ব্যাখ্যা:
CREATE TABLE Students— "Students" নামে একটা নতুন টেবিলের কাঠামো তৈরি হচ্ছে- প্রতিটা লাইনে একটা করে কলামের নাম ও তার ডেটা টাইপ উল্লেখ করা হয়েছে
টেবিল ও কলামের নামকরণের নিয়ম
| ভালো নাম | খারাপ নাম | কেন |
|---|---|---|
| Students | 1_students | নাম সংখ্যা দিয়ে শুরু করা যায় না |
| student_name | student name | নামে ফাঁকা জায়গা রাখা উচিত না, আন্ডারস্কোর ব্যবহার করা ভালো |
| admission_date | date | "date" এর মতো সংরক্ষিত শব্দ এড়ানো উচিত |
সাধারণ ডেটা টাইপসমূহ
| Data Type | কী রাখে | উদাহরণ |
|---|---|---|
| INT | পূর্ণসংখ্যা | বয়স, ক্লাস, আইডি |
| VARCHAR(n) | লেখা (সর্বোচ্চ n অক্ষর) | নাম, ঠিকানা |
| DATE | তারিখ (YYYY-MM-DD) | জন্মতারিখ, ভর্তির তারিখ |
| FLOAT | দশমিক সংখ্যা | GPA, ওজন |
| BOOLEAN | হ্যাঁ/না (TRUE/FALSE) | সক্রিয় কিনা, পাস/ফেল |
- ফোন নম্বরের জন্য INT ব্যবহার করা — শুরুতে ০ থাকলে তা হারিয়ে যায়, তাই VARCHAR ব্যবহার করা উচিত
- টেবিল নাম সংখ্যা দিয়ে শুরু করা, যা অনেক ডেটাবেজে অনুমোদিত না
- দুইটা কলামের একই নাম রাখা, যা এরর সৃষ্টি করে
সবসময় ছোট হাতের অক্ষর ও আন্ডারস্কোর (_) দিয়ে নাম লেখা, এবং ডেটার প্রকৃতি বুঝে সঠিক ডেটা টাইপ বেছে নেওয়া।
টেবিলের গঠন বোঝা
🔑 Primary Key
উপমা: প্রতিটা শিক্ষার্থীর জাতীয় পরিচয়পত্র নম্বরের মতো — কারো সাথে কারো মিলবে না।
সংজ্ঞা: এমন একটা কলাম, যার মান প্রতিটা রেকর্ডে অনন্য (unique) এবং কখনো ফাঁকা থাকতে পারে না।
SQL উদাহরণপ্রতিটা শিক্ষার্থীকে অনন্যভাবে শনাক্ত করতে, যাতে দুইজন শিক্ষার্থীর তথ্য গুলিয়ে না যায়।
🔗 Foreign Key (প্রাথমিক পরিচিতি)
উপমা: একটা রেফারেন্স চিঠি — "এই শিক্ষার্থী কোন ক্লাসের, তা জানতে Classes টেবিলে দেখো।"
সংজ্ঞা: একটা কলাম, যা অন্য একটা টেবিলের Primary Key-কে নির্দেশ করে দুইটা টেবিলকে সংযুক্ত করে।
SQL উদাহরণ❓ NULL
উপমা: একটা ফর্মে কোনো ঘর ইচ্ছাকৃতভাবে খালি রাখা হলো — সেটা "শূন্য (0)" না, বরং "এখনো কিছু লেখা হয়নি"।
সংজ্ঞা: NULL মানে একটা কলামে কোনো মান নেই, এটা ০ বা খালি লেখা ("") থেকে ভিন্ন।
🚫 NOT NULL
উপমা: একটা ভর্তি ফর্মে "নাম" ঘরটা বাধ্যতামূলক — খালি রাখা যাবে না।
সংজ্ঞা: এই constraint নিশ্চিত করে যে কলামটা কখনো NULL (ফাঁকা) থাকতে পারবে না।
SQL উদাহরণ🎯 DEFAULT
উপমা: একটা নতুন ব্যাংক অ্যাকাউন্ট খোলার সময় স্বয়ংক্রিয়ভাবে ব্যালেন্স "০" বসিয়ে দেওয়া, যদি কেউ না বলে।
সংজ্ঞা: কোনো মান না দিলে স্বয়ংক্রিয়ভাবে যে ডিফল্ট মান বসবে।
SQL উদাহরণ🔢 AUTO_INCREMENT
উপমা: একটা টোকেন কাউন্টার, যেখানে প্রতিটা নতুন কাস্টমারের জন্য স্বয়ংক্রিয়ভাবে ১টা করে বাড়তি নম্বর দেওয়া হয়।
সংজ্ঞা: প্রতিটা নতুন রেকর্ডে স্বয়ংক্রিয়ভাবে ক্রমবর্ধমান একটা সংখ্যা বসিয়ে দেয়, ম্যানুয়ালি লিখতে হয় না।
SQL উদাহরণনতুন শিক্ষার্থী ভর্তির সময় প্রতিবার নিজে থেকে আইডি তৈরি হয়, ভুল করে ডুপ্লিকেট আইডি দেওয়ার ঝুঁকি থাকে না।
টেবিল দেখা ও পরিচালনা
সব টেবিলের তালিকা দেখা
SQL কোড| Tables_in_SchoolDB |
|---|
| Students |
| Courses |
| Results |
ব্যাখ্যা: এই ডেটাবেজে বর্তমানে কী কী টেবিল আছে তা দেখায়।
একটা টেবিলের কাঠামো দেখা
SQL কোড| Field | Type | Null | Key |
|---|---|---|---|
| student_id | int | NO | PRI |
| name | varchar(50) | NO | |
| class | int | YES |
ব্যাখ্যা: প্রতিটা কলামের নাম, ডেটা টাইপ, NULL অনুমোদিত কিনা, এবং Key তথ্য দেখায়।
টেবিল তৈরির সম্পূর্ণ কমান্ড দেখা
SQL কোডব্যাখ্যা: এটা দেখায় ঠিক কোন SQL কোড দিয়ে টেবিলটা তৈরি হয়েছিল — যেন কেউ ভুলে গেলে আবার দেখে নিতে পারে।
টেবিলের নাম পরিবর্তন
SQL কোডটেবিল মুছে ফেলা (ধারণাগত)
| কমান্ড | প্রভাব |
|---|---|
DROP TABLE table_name; | টেবিল ও তার কাঠামো দুটোই স্থায়ীভাবে মুছে যায় |
TRUNCATE TABLE table_name; | শুধু ডেটা খালি হয়, কাঠামো থেকে যায় |
বাস্তব বিজনেস কেস স্টাডি: School Management System
| টেবিল | কেন দরকার | মূল কলাম |
|---|---|---|
| Students | শিক্ষার্থীর তথ্য রাখতে | student_id (PK), name, class, department_id (FK) |
| Teachers | শিক্ষকের তথ্য রাখতে | teacher_id (PK), name, subject |
| Courses | কোর্সের তথ্য রাখতে | course_id (PK), course_name, teacher_id (FK) |
| Departments | বিভাগের তথ্য রাখতে | department_id (PK), department_name |
| Results | ফলাফল রাখতে | result_id (PK), student_id (FK), course_id (FK), marks |
টেবিলগুলোর সম্পর্ক
লক্ষ্য করো, Results টেবিলটা Students ও Courses-এর মাঝে সংযোগকারী হিসেবে কাজ করছে — কারণ একজন শিক্ষার্থীর একাধিক কোর্সের ফলাফল থাকতে পারে।
MySQL Workbench প্র্যাকটিক্যাল সেশন
ধাপ ১: Database তৈরি
ধাপ ২: Students টেবিল তৈরি
ধাপ ৩: Courses টেবিল তৈরি
ধাপ ৪: Results টেবিল তৈরি (দুইটা Foreign Key সহ)
ধাপ ৫: সব টেবিল দেখা
| Tables_in_SchoolDB |
|---|
| Students |
| Courses |
| Results |
ধাপ ৬: প্রতিটা টেবিলের কাঠামো দেখা
| Field | Type | Key |
|---|---|---|
| result_id | int | PRI |
| student_id | int | MUL |
| course_id | int | MUL |
| marks | float |
ধাপ ৭: টেবিলের নাম পরিবর্তন
ধাপ ৮: একটা প্র্যাকটিস টেবিল মুছে ফেলা
- Foreign Key যোগ করার আগে "parent" টেবিল (যেমন Students) তৈরি না করে ফেলা
- ভুল টেবিল DROP করে ফেলা — তাই কমান্ড চালানোর আগে নাম দুইবার যাচাই করা উচিত
সাধারণ শুরুর ভুল
✅ সমাধান: প্রতিটা টেবিলে একটা Primary Key রাখা অভ্যাস করো।
✅ সমাধান: ফোন নম্বরের জন্য VARCHAR, টাকার জন্য DECIMAL/FLOAT ব্যবহার করো।
✅ সমাধান: স্পষ্ট, অর্থবহ ও সামঞ্জস্যপূর্ণ নাম ব্যবহার করো।
✅ সমাধান: একই তথ্যের জন্য একাধিক কলাম না বানিয়ে একটাই কলাম রাখো।
✅ সমাধান: শিক্ষার্থী ও শিক্ষকের তথ্য আলাদা টেবিলে রাখো, একসাথে না।
✅ সমাধান: DROP চালানোর আগে টেবিলের নাম দুইবার যাচাই করো এবং ব্যাকআপ রাখো।
✅ সমাধান: মনে রাখো, NULL মানে "কোনো মান নেই", খালি টেক্সট (" ") একটা ভিন্ন মান।
ইন্ডাস্ট্রি বেস্ট প্র্যাকটিস
🏷️ নামকরণের নিয়ম
ছোট হাতের অক্ষর, আন্ডারস্কোর, বহুবচন টেবিল নাম ব্যবহার করা
🔤 সামঞ্জস্যপূর্ণ ডেটা টাইপ
সব টেবিলে একই ধরনের তথ্যের জন্য একই ডেটা টাইপ ব্যবহার করা
🔁 Normalization (মৌলিক ধারণা)
একই তথ্য বার বার না রেখে যৌক্তিক টেবিলে ভাগ করা কৌশল
📝 ডকুমেন্টেশন
প্রতিটা টেবিল ও কলাম কী উদ্দেশ্যে তৈরি তা লিখে রাখা
📈 স্কেলেবিলিটি
ভবিষ্যতে নতুন তথ্য/কলাম সহজে যোগ করার মতো নমনীয় ডিজাইন রাখা
🛠️ রক্ষণাবেক্ষণযোগ্যতা
টেবিল কাঠামো এমনভাবে রাখা যাতে পরিবর্তন সহজে করা যায়
ক্লাসরুম অ্যাক্টিভিটি
রিভিশন ও প্রশ্নোত্তর
📌 দ্রুত রিভিশন নোট
- Table = সারি-কলামে সাজানো তথ্যের কাঠামো
- Row = একটা রেকর্ড, Column = একটা বৈশিষ্ট্য, Cell = একটা একক মান
- Primary Key = অনন্য শনাক্তকারী, Foreign Key = অন্য টেবিলের সাথে সংযোগ
- NULL ≠ খালি টেক্সট বা ০, NULL মানে "কোনো মান নেই"
- SHOW TABLES, DESCRIBE, SHOW CREATE TABLE — টেবিল দেখা ও যাচাইয়ের কমান্ড
🏛️ সম্পূর্ণ ডেটাবেজ স্ট্রাকচার ডায়াগ্রাম
🕰️ Database Table-এর সংক্ষিপ্ত ইতিহাস
একসময় স্কুল, হাসপাতাল, ব্যাংক সবকিছুর তথ্য কাগজের রেজিস্টারে হাতে লেখা হতো। কম্পিউটার আসার পর, ১৯৭০-এর দশকে Relational Database Model প্রবর্তিত হয়, যেখানে তথ্য টেবিল আকারে (সারি-কলামে) সংরক্ষণের ধারণা আসে — এটাই আজকের SQL টেবিলের ভিত্তি। এখন আধুনিক ক্লাউড ডেটাবেজ ব্যবহার করে কোটি কোটি রেকর্ড নিয়ে টেবিল একসাথে, নিরাপদে ও দ্রুতগতিতে পরিচালনা করা সম্ভব।
🏥 মিনি প্রজেক্ট: হাসপাতাল ম্যানেজমেন্ট টেবিল ডিজাইন
| টেবিল | মূল কলাম |
|---|---|
| Patients | patient_id (PK, AUTO_INCREMENT), name, age, phone |
| Doctors | doctor_id (PK), name, specialty |
| Appointments | appointment_id (PK), patient_id (FK), doctor_id (FK), appointment_date |
👥 প্রফেশনাল ওয়ার্কফ্লো
টেবিলের নিরাপত্তা ও পারফরম্যান্স নিশ্চিত করেন
টেবিল ডিজাইন ও তৈরি করেন
টেবিল থেকে ডেটা বের করে বিশ্লেষণ করেন
❓ ভাইভা প্রশ্ন
💼 ইন্টারভিউ প্রস্তুতি — টপ ৩০টি বিগিনার লেভেল প্রশ্ন
✅ MCQ প্র্যাকটিস
(ক) Column (খ) Row (গ) Cell (ঘ) Key
(ক) Foreign Key (খ) Column (গ) Primary Key (ঘ) NULL
(ক) SELECT (খ) DESCRIBE (গ) DELETE (ঘ) INSERT
(ক) DEFAULT (খ) NOT NULL (গ) AUTO_INCREMENT (ঘ) FOREIGN KEY
(ক) সংখ্যা শূন্য (খ) খালি টেক্সট (গ) কোনো মান নেই (ঘ) নেগেটিভ মান
📝 হোমওয়ার্ক অ্যাসাইনমেন্ট
- একটা "Library Management System"-এর জন্য কমপক্ষে ২টা টেবিল ডিজাইন করো — Books ও Members, প্রতিটার মূল কলাম, Primary Key ও ডেটা টাইপ উল্লেখ করে।
- Database → Tables → Rows → Columns → Cells ডায়াগ্রাম নিজ হাতে এঁকে আনো, এবং প্রতিটার একটা করে নিজের উদাহরণ লেখো।
- Primary Key, Foreign Key, NULL, NOT NULL, DEFAULT ও AUTO_INCREMENT-এর প্রতিটার একটা করে সহজ বাক্যে ব্যাখ্যা লেখো।