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

Schema কেন দরকার?

⏱ ১৫ মিনিট

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

একটা বিশ্ববিদ্যালয়ে রাখতে হয় শিক্ষার্থী, শিক্ষক, কোর্স, বিভাগ, ফলাফল ও ফি — এই সবকিছুর তথ্য।

❓ এই সবকিছু কি একটাই টেবিলে রাখা উচিত?

না, তাহলে সব তথ্য জট পাকিয়ে যাবে।

❓ এই বিশাল তথ্য কীভাবে সাজাবো?

আলাদা আলাদা ভাগে ভাগ করে সাজাতে হবে।

❓ হাজার হাজার কর্মী কীভাবে দ্রুত সঠিক তথ্য খুঁজে পাবে?

একটা স্পষ্ট, সুসংগঠিত কাঠামো থাকলে সহজেই পাওয়া যাবে।

💡 উপমা: একটা স্কুল

একটা স্কুলে যদি সব ক্লাসের সব শিক্ষার্থী একই ঘরে বসতো, পুরো ব্যবস্থা এলোমেলো হয়ে যেত। এজন্যই স্কুলে আলাদা আলাদা শ্রেণিকক্ষ থাকে — প্রতিটার নির্দিষ্ট উদ্দেশ্য ও শিক্ষার্থী। ডেটাবেজেও ঠিক এই একই কারণে তথ্যকে আলাদা আলাদা, সুশৃঙ্খল ভাগে সাজাতে হয়।

একইভাবে, একটা লাইব্রেরিতে সব বই এলোমেলোভাবে না রেখে বিষয়ভিত্তিক সেকশনে (বিজ্ঞান, ইতিহাস, উপন্যাস) সাজানো হয়। একটা শপিং মলে প্রতিটা দোকান নির্দিষ্ট ধরনের পণ্য বিক্রি করে। একটা ফাইলিং ক্যাবিনেটে প্রতিটা ফোল্ডারে লেবেল লাগানো থাকে। এই সবগুলোই "সংগঠন" (organization)-এর উদাহরণ — আর ডেটাবেজেও এই একই ধরনের সংগঠন দরকার হয়।

Unorganized Data
এলোমেলো তথ্যের স্তূপ

→

Organized Database
ভাগে ভাগে সাজানো ডেটা

→

Schema
এই সংগঠনের নকশা/ব্লুপ্রিন্ট

Schema কী?

⏱ ১৫ মিনিট

প্রথমে Database কী তা মনে করি: Database হলো একটা বড় ডিজিটাল গুদাম, যেখানে সব তথ্য জমা থাকে।

🧑‍🏫 উপমা: লাইব্রেরি

একটা লাইব্রেরি (Library) হলো পুরো Database। সেই লাইব্রেরির প্রতিটা বিষয়ভিত্তিক সেকশন (বিজ্ঞান সেকশন, ইতিহাস সেকশন) হলো Schema — যা বলে দেয় কোন ধরনের বই কোথায় থাকবে। আর প্রতিটা সেকশনের ভেতরের বইগুলো হলো Tables, যেখানে প্রকৃত তথ্য থাকে।

Library
(Database)

↓

Book Section
(Schema)

↓

Books
(Tables)

সংজ্ঞা: Schema হলো একটা ডেটাবেজের যৌক্তিক গঠন বা নীল-নকশা (blueprint), যা নির্ধারণ করে ডেটা কীভাবে সংগঠিত থাকবে — কোন টেবিল থাকবে, প্রতিটা টেবিলে কী ধরনের তথ্য থাকবে, এবং টেবিলগুলো একে অপরের সাথে কীভাবে সম্পর্কিত।

🏗️ আরেকটা উপমা: বাড়ির নকশা

একটা বাড়ি তৈরির আগে একজন স্থপতি একটা নকশা (blueprint) আঁকেন — কোথায় কয়টা ঘর, কোথায় রান্নাঘর, কোথায় বাথরুম। Schema অনেকটা সেই নকশার মতো — এটা বাস্তব তথ্য (আসবাবপত্র) নয়, বরং তথ্য কোথায় ও কীভাবে থাকবে তার পরিকল্পনা।

Schema-এর উপাদান

⏱ ২৫ মিনিট

🗄️ Database

সংজ্ঞা: সব তথ্যের বড় ডিজিটাল গুদাম।

উদাহরণ

"UniversityDB" — যেখানে বিশ্ববিদ্যালয়ের সব তথ্য থাকে।

🗂️ Schema

সংজ্ঞা: ডেটাবেজের ভেতরের সংগঠনের নকশা — কোন টেবিল কীভাবে সাজানো থাকবে তার পরিকল্পনা।

উদাহরণ

"academic" নামের একটা schema, যার ভেতরে Students, Teachers, Courses টেবিল থাকতে পারে।

📋 Table (টেবিল)

সংজ্ঞা: একই ধরনের তথ্য সারি-কলাম আকারে রাখার জায়গা।

উদাহরণ

Students টেবিল, যেখানে সব শিক্ষার্থীর তথ্য থাকে।

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

📊 Column (কলাম)

সংজ্ঞা: একটা টেবিলের প্রতিটা "বৈশিষ্ট্য" বা তথ্যের ধরন।

উদাহরণ

Students টেবিলে name, class, phone প্রতিটাই একেকটা কলাম।

📄 Row (সারি)

সংজ্ঞা: একটা নির্দিষ্ট রেকর্ড বা একজন ব্যক্তির সম্পূর্ণ তথ্য।

উদাহরণ

"রিমা, ৮ম শ্রেণি, ফোন নম্বর ..." — এটা একটা সারি, একজন নির্দিষ্ট শিক্ষার্থীর তথ্য।

🔤 Data Type (ডেটা টাইপ)

সংজ্ঞা: একটা কলামে কী ধরনের মান (সংখ্যা, লেখা, তারিখ) থাকবে তা নির্ধারণ করে।

Data Type	কী রাখে	উদাহরণ
INT	পূর্ণসংখ্যা	বয়স, ক্লাস
VARCHAR(n)	লেখা (সর্বোচ্চ n অক্ষর)	নাম, ঠিকানা
DATE	তারিখ	জন্ম তারিখ
DECIMAL	দশমিক সংখ্যা	ফি, বেতন

🔒 Constraint (নিয়ন্ত্রণ শর্ত)

সংজ্ঞা: একটা কলামে কী ধরনের মান গ্রহণযোগ্য তার নিয়ম।

উদাহরণ

NOT NULL মানে এই কলাম কখনো ফাঁকা রাখা যাবে না — যেমন প্রতিটা শিক্ষার্থীর অবশ্যই একটা নাম থাকতে হবে।

🔑 Primary Key (প্রাইমারি কী)

সংজ্ঞা: এমন একটা কলাম যার মান প্রতিটা রেকর্ডে সম্পূর্ণ আলাদা (unique) — যা দিয়ে একটা নির্দিষ্ট রেকর্ড শনাক্ত করা যায়।

💡 উপমা

প্রতিটা শিক্ষার্থীর জাতীয় পরিচয়পত্র নম্বরের মতো — কারো সাথে কারো মিলবে না।

student_id INT PRIMARY KEY

🔗 Foreign Key (ফরেন কী)

সংজ্ঞা: একটা টেবিলের কলাম, যা অন্য একটা টেবিলের Primary Key-কে নির্দেশ করে — এভাবে দুইটা টেবিল একে অপরের সাথে যুক্ত হয়।

💡 উপমা

একটা রেফারেন্স চিঠির মতো — "এই শিক্ষার্থীটা কোন বিভাগের, তা জানতে Departments টেবিলের এই নম্বরটা দেখো।"

department_id INT, FOREIGN KEY (department_id) REFERENCES Departments(department_id)

🔀 Relationship (সম্পর্ক)

সংজ্ঞা: Primary Key ও Foreign Key ব্যবহার করে দুইটা টেবিলের মধ্যে তৈরি হওয়া যোগাযোগ।

উদাহরণ

একজন শিক্ষক একাধিক শিক্ষার্থীকে পড়ান — Teachers ও Students টেবিলের মধ্যে এটা একটা সম্পর্ক।

⚠️ সাধারণ ভুল: শুরুতে অনেকেই Database আর Schema-কে একই জিনিস মনে করেন। মনে রাখো, Database হলো পুরো গুদাম, আর Schema হলো সেই গুদামের ভেতরের সংগঠন-পরিকল্পনা।

একটা Schema ডিজাইন করা

⏱ ২০ মিনিট

📖 গল্প

একটা স্কুল একটা Student Management System বানাতে চায়। আমরা তাদের জন্য একটা schema ডিজাইন করবো।

কোন কোন টেবিল দরকার ও কেন

টেবিল	কেন দরকার	মূল ফিল্ড
Students	শিক্ষার্থীর ব্যক্তিগত তথ্য রাখতে	student_id (PK), name, class
Teachers	শিক্ষকের তথ্য রাখতে	teacher_id (PK), name, subject
Courses	কোর্সের তথ্য রাখতে	course_id (PK), course_name, teacher_id (FK)
Departments	বিভাগের তথ্য রাখতে	department_id (PK), department_name
Enrollments	কোন শিক্ষার্থী কোন কোর্সে ভর্তি তা রাখতে	enrollment_id (PK), student_id (FK), course_id (FK)
Results	ফলাফল রাখতে	result_id (PK), student_id (FK), course_id (FK), marks

ধারণাগত ER ডায়াগ্রাম

Students

student_idPK

name

class

১ শিক্ষার্থী → অনেক Enrollment

Enrollments

enrollment_idPK

student_idFK

course_idFK

অনেক Enrollment ← ১ Course

Courses

course_idPK

course_name

teacher_idFK

লক্ষ্য করো, Enrollments টেবিলটা Students ও Courses-এর মাঝখানে "সেতু" হিসেবে কাজ করছে — কারণ একজন শিক্ষার্থী একাধিক কোর্সে, এবং একটা কোর্সে একাধিক শিক্ষার্থী থাকতে পারে।

✅ কেন Primary/Foreign Key গুরুত্বপূর্ণ

Primary Key নিশ্চিত করে প্রতিটা রেকর্ড অনন্যভাবে শনাক্ত করা যায়। Foreign Key নিশ্চিত করে টেবিলগুলোর মধ্যে তথ্য সঠিকভাবে সংযুক্ত থাকে — যেমন একটা Enrollment রেকর্ড কোনো অস্তিত্বহীন শিক্ষার্থীর সাথে যুক্ত হতে পারবে না।

SQL-এ Schema তৈরি করা

⏱ ২০ মিনিট

ধাপ ১: Database তৈরি করা

SQL কোড

CREATE DATABASE UniversityDB;

আউটপুট

Query OK, 1 row affected.

ব্যাখ্যা: এটা "UniversityDB" নামে একটা নতুন, খালি ডেটাবেজ তৈরি করলো।

ধাপ ২: Database ব্যবহার করা

SQL কোড

USE UniversityDB;

আউটপুট

Database changed

ব্যাখ্যা: এখন থেকে পরবর্তী সব কমান্ড এই "UniversityDB"-এর ভেতরেই কাজ করবে।

ধাপ ৩: একাধিক টেবিল তৈরি করা

SQL কোড

CREATE TABLE Departments ( department_id INT PRIMARY KEY, department_name VARCHAR(50) NOT NULL ); CREATE TABLE Students ( student_id INT PRIMARY KEY, name VARCHAR(50) NOT NULL, class INT, department_id INT, FOREIGN KEY (department_id) REFERENCES Departments(department_id) );

আউটপুট

Query OK, 0 rows affected. (২টা টেবিল সফলভাবে তৈরি হলো)

লাইন-বাই-লাইন ব্যাখ্যা:

CREATE TABLE Departments (...) — Departments নামের একটা টেবিল তৈরি হলো
department_id INT PRIMARY KEY — এই কলাম প্রতিটা বিভাগের জন্য অনন্য পরিচয়
Students টেবিলে department_id কলাম আছে, যা FOREIGN KEY হিসেবে Departments টেবিলের সাথে সংযুক্ত হলো

নামকরণের নিয়ম (Naming Conventions)

ভালো নাম	খারাপ নাম	কেন
student_name	sn / col1	স্পষ্ট ও বোঝার মতো
Students (বহুবচন টেবিল নাম)	student_info_final_v2	সহজ ও সামঞ্জস্যপূর্ণ
department_id	deptID123	ধারাবাহিক ও পঠনযোগ্য

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

Foreign Key যোগ করার আগে যে টেবিলটাকে রেফারেন্স করা হচ্ছে সেটা তৈরি না করা (ভুল ক্রমে টেবিল তৈরি করা)
PRIMARY KEY দিতে ভুলে যাওয়া, যার ফলে ডুপ্লিকেট রেকর্ড তৈরি হতে পারে
ডেটা টাইপ ভুল বেছে নেওয়া (যেমন ফোন নম্বরের জন্য INT ব্যবহার করা, যেখানে শুরুতে ০ থাকলে তা হারিয়ে যেতে পারে)

✅ Best Practice

সবসময় প্রথমে "মূল" টেবিলগুলো (যেমন Departments) তৈরি করো, তারপর যেসব টেবিল সেগুলোকে রেফারেন্স করে (যেমন Students) সেগুলো তৈরি করো।

Schema-এর ভেতরের সম্পর্কের ধরন

⏱ ১৫ মিনিট

1️⃣ One-to-One (এক-থেকে-এক)

একটা রেকর্ড ঠিক আরেকটা রেকর্ডের সাথেই যুক্ত।

Student

student_idPK

১ ↔ ১

ID Card

card_idPK

student_idFK

উদাহরণ

একজন শিক্ষার্থীর ঠিক একটাই আইডি কার্ড থাকে, একটা আইডি কার্ড ঠিক একজন শিক্ষার্থীরই।

2️⃣ One-to-Many (এক-থেকে-বহু)

একটা রেকর্ড একাধিক রেকর্ডের সাথে যুক্ত হতে পারে।

Teacher

teacher_idPK

১ ← বহু

Students

student_idPK

teacher_idFK

উদাহরণ

একজন শিক্ষক একাধিক শিক্ষার্থীকে পড়ান, কিন্তু একজন শিক্ষার্থীর (এই উদাহরণে) নির্দিষ্ট ক্লাস টিচার একজনই।

3️⃣ Many-to-Many (বহু-থেকে-বহু)

দুইদিকের রেকর্ডই একাধিকভাবে একে অপরের সাথে যুক্ত হতে পারে — এক্ষেত্রে মাঝে একটা "সংযোগকারী" টেবিল লাগে।

Students

student_idPK

↔

Enrollments

student_idFK

course_idFK

↔

Courses

course_idPK

উদাহরণ

একজন শিক্ষার্থী একাধিক কোর্সে ভর্তি হতে পারে, আর একটা কোর্সে একাধিক শিক্ষার্থী থাকতে পারে — তাই মাঝে Enrollments টেবিল লাগে।

সম্পর্কের ধরন	সহজ উদাহরণ	মাঝে বাড়তি টেবিল লাগে?
One-to-One	শিক্ষার্থী ↔ আইডি কার্ড	না
One-to-Many	শিক্ষক → শিক্ষার্থীরা	না
Many-to-Many	শিক্ষার্থীরা ↔ কোর্সসমূহ	হ্যাঁ (Enrollments-এর মতো)

ভালো Schema বনাম খারাপ Schema

⏱ ১০ মিনিট

বিষয়	ভালো Schema	খারাপভাবে ডিজাইন করা Schema
সংগঠন	প্রতিটা তথ্য যৌক্তিক টেবিলে ভাগ করা	সব তথ্য একটা মাত্র বিশাল টেবিলে গাদাগাদি
ডেটা পুনরাবৃত্তি	একই তথ্য বার বার লেখা লাগে না	একই তথ্য বার বার কপি হয়ে থাকে
পারফরম্যান্স	দ্রুত খোঁজা ও আপডেট করা যায়	ধীরগতির, বড় টেবিলে খোঁজা কঠিন
রক্ষণাবেক্ষণ	পরিবর্তন করা সহজ	একটা পরিবর্তনে অনেক জায়গায় ভুল হওয়ার ঝুঁকি
স্কেলেবিলিটি	নতুন তথ্য বা টেবিল যোগ করা সহজ	নতুন কিছু যোগ করতে গেলে পুরো কাঠামো ভেঙে যেতে পারে
পঠনযোগ্যতা	নাম ও কাঠামো দেখেই বোঝা যায়	বোঝা কঠিন, অস্পষ্ট নামকরণ

💡 বাস্তব উদাহরণ

যদি একটা স্কুল Students টেবিলেই শিক্ষকের নাম, বিভাগের নাম, কোর্সের নাম সবকিছু বার বার লিখে রাখে (প্রতিটা শিক্ষার্থীর সারিতে), তাহলে কোনো শিক্ষকের নাম পরিবর্তন হলে শত শত সারি খুঁজে খুঁজে পরিবর্তন করতে হবে — এটাই একটা খারাপ Schema-এর ক্লাসিক উদাহরণ।

বাস্তব শিল্প-প্রয়োগ

⏱ ১০ মিনিট

কোম্পানি/খাত	Schema-তে কী কী টেবিল থাকতে পারে
ব্যাংকিং সিস্টেম	Customers, Accounts, Transactions, Loans
হাসপাতাল ম্যানেজমেন্ট	Patients, Doctors, Appointments, Prescriptions
ই-কমার্স	Customers, Products, Orders, Payments
Facebook	Users, Posts, Comments, Friendships
YouTube	Users, Videos, Comments, Subscriptions
Netflix	Users, Movies, WatchHistory, Subscriptions
Uber	Riders, Drivers, Trips, Payments

💡 লক্ষণীয়

প্রতিটা ক্ষেত্রেই মূল ধরনটা একই — সম্পর্কিত তথ্যগুলোকে আলাদা আলাদা টেবিলে ভাগ করে, Primary/Foreign Key দিয়ে সংযুক্ত করা হয়েছে।

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

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

চলো সম্পূর্ণ একটা mini Schema বাস্তবে তৈরি করে দেখি।

ধাপ ১: Database তৈরি ও ব্যবহার

SQL কোড

CREATE DATABASE SchoolDB; USE SchoolDB;

আউটপুট

Database created and selected successfully.

ধাপ ২: একাধিক টেবিল তৈরি ও সংযুক্ত করা

SQL কোড

CREATE TABLE Teachers ( teacher_id INT PRIMARY KEY, name VARCHAR(50) ); CREATE TABLE Students ( student_id INT PRIMARY KEY, name VARCHAR(50), teacher_id INT, FOREIGN KEY (teacher_id) REFERENCES Teachers(teacher_id) );

আউটপুট

Query OK, 0 rows affected. (২টা টেবিল তৈরি ও সংযুক্ত হলো)

ধাপ ৩: Schema-এর গঠন দেখা

SQL কোড

DESCRIBE Students;

আউটপুট

Field	Type	Null	Key
student_id	int	NO	PRI
name	varchar(50)	YES
teacher_id	int	YES	MUL

ব্যাখ্যা: DESCRIBE কমান্ড একটা টেবিলের সম্পূর্ণ কাঠামো (কলাম, ডেটা টাইপ, Key তথ্য) দেখায়।

ধাপ ৪: নমুনা ডেটা যোগ করা

SQL কোড

INSERT INTO Teachers (teacher_id, name) VALUES (1, 'রফিক স্যার'); INSERT INTO Students (student_id, name, teacher_id) VALUES (101, 'নাবিলা', 1);

আউটপুট

2 rows inserted successfully.

ধাপ ৫: সম্পর্ক যাচাই করা (JOIN দিয়ে একসাথে দেখা)

SQL কোড

SELECT Students.name AS student_name, Teachers.name AS teacher_name FROM Students JOIN Teachers ON Students.teacher_id = Teachers.teacher_id;

আউটপুট

student_name	teacher_name
নাবিলা	রফিক স্যার

ব্যাখ্যা: JOIN দুইটা টেবিলকে তাদের Primary/Foreign Key সম্পর্কের ভিত্তিতে একসাথে জোড়া লাগিয়ে দেখায় — এটা আমরা পরের ক্লাসে বিস্তারিত শিখবো, আজ শুধু বুঝলাম Schema-এর সম্পর্কগুলো বাস্তবে এভাবে কাজে লাগে।

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

Foreign Key-এর ডেটা টাইপ মূল Primary Key-এর সাথে না মেলা (যেমন একটাতে INT, আরেকটাতে VARCHAR)
প্রথমে child টেবিল (যেমন Students) তৈরি করে ফেলা, যেখানে এখনো parent টেবিল (Teachers) তৈরিই হয়নি

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

⏱ আলোচনা

❌ Schema আর Database-কে একই ভাবা

✅ সমাধান: Database হলো পুরো গুদাম, Schema হলো তার ভেতরের সংগঠন-পরিকল্পনা।

❌ সবকিছু একটা টেবিলে রাখা

✅ সমাধান: সম্পর্কিত তথ্যগুলোকে যৌক্তিকভাবে আলাদা টেবিলে ভাগ করো।

❌ Primary Key ভুলে যাওয়া

✅ সমাধান: প্রতিটা টেবিলেই একটা Primary Key রাখা অভ্যাস করো।

❌ Foreign Key ভুলে যাওয়া

✅ সমাধান: সম্পর্কিত টেবিলগুলোর মধ্যে Foreign Key দিয়ে সংযোগ নিশ্চিত করো।

❌ দুর্বল টেবিল নামকরণ

✅ সমাধান: স্পষ্ট, অর্থবহ ও সামঞ্জস্যপূর্ণ নাম ব্যবহার করো।

❌ ডুপ্লিকেট কলাম রাখা

✅ সমাধান: একই তথ্য একাধিক টেবিলে বার বার না রেখে Foreign Key দিয়ে রেফার করো।

❌ ভুল ডেটা টাইপ ব্যবহার করা

✅ সমাধান: ফোন নম্বরের জন্য VARCHAR, বয়সের জন্য INT, ফির জন্য DECIMAL ব্যবহার করো।

❌ টেবিলগুলোর মধ্যে কোনো সম্পর্ক না রাখা

✅ সমাধান: শুরুতেই ভাবো কোন টেবিল কোন টেবিলের সাথে কীভাবে সংযুক্ত হবে।

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

⏱ আলোচনা

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

টেবিল ও কলামের নাম স্পষ্ট, ছোট ও অর্থবহ রাখা

🧩 সামঞ্জস্যপূর্ণ ডিজাইন

সব টেবিলে একই ধাঁচের নামকরণ ও কাঠামো অনুসরণ করা

🔁 ডুপ্লিকেট ডেটা এড়ানো

Normalization নামের কৌশল ব্যবহার করে একই তথ্য বার বার না রাখা

📝 ডকুমেন্টেশন

প্রতিটা টেবিল ও কলামের উদ্দেশ্য লিখে রাখা, যাতে অন্যরাও বুঝতে পারে

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

ভবিষ্যতে নতুন তথ্য বা টেবিল সহজে যোগ করার মতো নমনীয় ডিজাইন রাখা

🔐 নিরাপত্তা

সংবেদনশীল তথ্যে (যেমন পাসওয়ার্ড) সীমিত অ্যাক্সেস নিশ্চিত করা

🔄 Version Control (মৌলিক ধারণা)

যেমন প্রোগ্রামাররা কোডের পরিবর্তনের ইতিহাস রাখেন (Git দিয়ে), তেমনি ডেটাবেজ পরিবর্তনগুলোরও (যেমন নতুন কলাম যোগ করা) রেকর্ড রাখা হয়, যাতে প্রয়োজনে আগের অবস্থায় ফেরা যায়। একে বলে Database Migration ট্র্যাকিং।

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

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

অ্যাক্টিভিটি ১ (Entity চেনা): একটা বিজনেস সিনারিও দাও (যেমন "একটা হাসপাতাল") এবং শিক্ষার্থীদের বলতে হবে কী কী টেবিল/Entity দরকার হতে পারে।

অ্যাক্টিভিটি ২ (কাগজে Schema ডিজাইন): ছোট দলে ভাগ হয়ে একটা "Library Management System"-এর জন্য কাগজে টেবিল ও তাদের ফিল্ড ডিজাইন করতে হবে।

অ্যাক্টিভিটি ৩ (ER ডায়াগ্রাম আঁকা): Books ও Members টেবিলের মধ্যে সম্পর্ক (কোন ধরনের — One-to-Many না Many-to-Many) নির্ধারণ করে একটা সহজ ER ডায়াগ্রাম আঁকতে হবে।

অ্যাক্টিভিটি ৪ (ভুল খুঁজে বের করা): একটা ইচ্ছাকৃতভাবে খারাপভাবে ডিজাইন করা Schema (যেমন সব তথ্য একটা টেবিলে) দেখিয়ে সমস্যাগুলো চিহ্নিত করতে বলা।

অ্যাক্টিভিটি ৫ (Key মেলানো): কয়েকটা Primary Key ও Foreign Key তালিকা দিয়ে শিক্ষার্থীদের সঠিকভাবে মেলাতে বলা।

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

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

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

Schema = ডেটাবেজের যৌক্তিক সংগঠন-পরিকল্পনা (blueprint)
Database ⊃ Schema ⊃ Tables ⊃ Columns/Rows
Primary Key = অনন্য শনাক্তকারী, Foreign Key = অন্য টেবিলের সাথে সংযোগ
সম্পর্কের ধরন: One-to-One, One-to-Many, Many-to-Many
ভালো Schema = কম ডুপ্লিকেশন, দ্রুত পারফরম্যান্স, সহজ রক্ষণাবেক্ষণ

🏛️ সম্পূর্ণ ডেটাবেজ আর্কিটেকচার ডায়াগ্রাম

User

→

Application

→

Database

→

Schema

→

Tables

→

Rows

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

একসময় তথ্য রাখা হতো শুধু সাধারণ ফাইলে (Flat File) — যেমন একটা টেক্সট ফাইলে সব তথ্য গাদাগাদি করে। এতে ডুপ্লিকেশন ও ভুলের ঝুঁকি অনেক বেশি ছিলো। ১৯৭০-এর দশকে Relational Database (টেবিল-ভিত্তিক, সম্পর্কযুক্ত) ধারণা আসে, যা থেকে জন্ম নেয় আধুনিক Schema পদ্ধতি। বর্তমানে ক্লাউড ডেটাবেজ (যেমন Amazon RDS, Google Cloud SQL) দিয়ে বিশাল স্কেলে, দূর থেকেও নমনীয়ভাবে Schema পরিচালনা করা যায়।

🏥 এন্ড-টু-এন্ড মিনি প্রজেক্ট: হাসপাতাল ম্যানেজমেন্ট Schema

টেবিল	মূল ফিল্ড
Patients	patient_id (PK), name, age, phone
Doctors	doctor_id (PK), name, specialty
Appointments	appointment_id (PK), patient_id (FK), doctor_id (FK), date
Prescriptions	prescription_id (PK), appointment_id (FK), medicine_name

নমুনা SQL

CREATE TABLE Patients ( patient_id INT PRIMARY KEY, name VARCHAR(50), age INT, phone VARCHAR(15) ); CREATE TABLE Doctors ( doctor_id INT PRIMARY KEY, name VARCHAR(50), specialty VARCHAR(50) ); CREATE TABLE Appointments ( appointment_id INT PRIMARY KEY, patient_id INT, doctor_id INT, appointment_date DATE, FOREIGN KEY (patient_id) REFERENCES Patients(patient_id), FOREIGN KEY (doctor_id) REFERENCES Doctors(doctor_id) );

লক্ষ্য করো, Appointments টেবিলটা Patients ও Doctors-এর মধ্যে সেতু হিসেবে কাজ করছে — ঠিক আমাদের আগের Enrollments উদাহরণের মতোই।

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

Database Administrator
Schema-এর নিরাপত্তা ও পারফরম্যান্স দেখাশোনা

→

Data Engineer
Schema ডিজাইন ও পাইপলাইন তৈরি

→

Data Scientist
Schema থেকে ডেটা এক্সট্র্যাক্ট করে বিশ্লেষণ

একটা কোম্পানিতে সাধারণত DBA (Database Administrator) ও Data Engineer একসাথে Schema ডিজাইন করেন, নিশ্চিত করেন এটা নিরাপদ ও দ্রুত কাজ করে, আর Data Scientist সেই Schema থেকে ডেটা নিয়ে বিশ্লেষণ ও মডেলিং করেন।

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

১. Schema কী?

ডেটাবেজের যৌক্তিক সংগঠন-পরিকল্পনা বা নকশা।

২. Database ও Schema-এর পার্থক্য কী?

Database হলো পুরো গুদাম, Schema তার ভেতরের সংগঠন-পরিকল্পনা।

৩. Primary Key কী?

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

৪. Foreign Key কী কাজ করে?

একটা টেবিলকে আরেকটা টেবিলের সাথে সংযুক্ত করে।

৫. Many-to-Many সম্পর্কে অতিরিক্ত কী দরকার হয়?

একটা সংযোগকারী (junction) টেবিল, যেমন Enrollments।

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

১. SQL Schema কী?

একটা ডেটাবেজের টেবিল, কলাম ও সম্পর্কের যৌক্তিক নকশা।

২. Table কী?

একই ধরনের তথ্য সারি-কলাম আকারে রাখার জায়গা।

৩. Column ও Row-এর পার্থক্য কী?

Column একটা বৈশিষ্ট্য (যেমন নাম), Row একটা সম্পূর্ণ রেকর্ড।

৪. Constraint কী?

একটা কলামে কোন ধরনের মান গ্রহণযোগ্য তার নিয়ম, যেমন NOT NULL।

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

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

৬. One-to-Many সম্পর্কের উদাহরণ দাও।

একজন শিক্ষক একাধিক শিক্ষার্থীকে পড়ান।

৭. Many-to-Many সম্পর্কের উদাহরণ দাও।

শিক্ষার্থীরা একাধিক কোর্সে, কোর্সে একাধিক শিক্ষার্থী।

৮. CREATE DATABASE কমান্ডের কাজ কী?

একটা নতুন, খালি ডেটাবেজ তৈরি করা।

৯. USE কমান্ডের কাজ কী?

পরবর্তী কমান্ডগুলো কোন ডেটাবেজে কাজ করবে তা নির্ধারণ করা।

১০. DESCRIBE কমান্ড কী দেখায়?

একটা টেবিলের সম্পূর্ণ কাঠামো — কলাম, ডেটা টাইপ, Key তথ্য।

১১. একটা খারাপ Schema-এর লক্ষণ কী?

সব তথ্য একটা টেবিলে, ডুপ্লিকেট ডেটা, অস্পষ্ট নামকরণ।

১২. Normalization কী (মৌলিক ধারণা)?

ডুপ্লিকেট ডেটা কমাতে তথ্যকে যৌক্তিকভাবে আলাদা টেবিলে ভাগ করার কৌশল।

১৩. NOT NULL constraint কী করে?

নিশ্চিত করে একটা কলাম কখনো ফাঁকা থাকতে পারবে না।

১৪. একটা টেবিলে একাধিক Foreign Key থাকতে পারে কি?

হ্যাঁ, একটা টেবিল একাধিক অন্য টেবিলকে রেফার করতে পারে।

১৫. VARCHAR ও INT-এর পার্থক্য কী?

VARCHAR লেখা (টেক্সট) রাখে, INT পূর্ণসংখ্যা রাখে।

১৬. একটা junction (সংযোগকারী) টেবিল কেন দরকার হয়?

Many-to-Many সম্পর্ক সঠিকভাবে সংরক্ষণ করতে।

১৭. Schema ডিজাইন করার সময় প্রথমে কী ভাবা উচিত?

কোন কোন Entity (টেবিল) দরকার এবং তাদের মধ্যে সম্পর্ক কেমন হবে।

১৮. Foreign Key ছাড়া টেবিল সংযুক্ত করা সম্ভব কি?

টেকনিক্যালি সম্ভব হলেও এটা ডেটার সঠিকতা নিশ্চিত করে না, তাই সুপারিশ করা হয় না।

১৯. Schema পরিবর্তনের ট্র্যাকিং কেন গুরুত্বপূর্ণ?

পরিবর্তনের ইতিহাস রাখলে সমস্যা হলে আগের অবস্থায় ফেরা যায়।

২০. DBA-এর প্রধান দায়িত্ব কী?

Schema-এর নিরাপত্তা, পারফরম্যান্স ও রক্ষণাবেক্ষণ নিশ্চিত করা।

২১. Data Engineer Schema ডিজাইনে কী ভূমিকা রাখেন?

টেবিল কাঠামো ও ডেটা পাইপলাইন ডিজাইন করেন।

২২. একটা E-commerce Schema-তে কোন কোন টেবিল থাকতে পারে?

Customers, Products, Orders, Payments ইত্যাদি।

২৩. ER Diagram কী?

Entity Relationship Diagram — টেবিল ও তাদের মধ্যেকার সম্পর্ক ভিজ্যুয়ালি দেখানোর ডায়াগ্রাম।

২৪. Flat File আর Relational Database-এর পার্থক্য কী?

Flat File-এ সব তথ্য একসাথে গাদাগাদি থাকে, Relational Database-এ তথ্য টেবিল ও সম্পর্ক দিয়ে সুশৃঙ্খলভাবে থাকে।

২৫. একটা টেবিলে PRIMARY KEY না থাকলে কী সমস্যা হতে পারে?

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

২৬. কেন টেবিলের নাম বহুবচনে (Students, Teachers) রাখার প্রচলন আছে?

কারণ একটা টেবিলে একাধিক রেকর্ড (একাধিক শিক্ষার্থী) থাকে, তাই এটা সামঞ্জস্যপূর্ণ ও স্পষ্ট।

২৭. Schema ডিজাইনে স্কেলেবিলিটি কেন গুরুত্বপূর্ণ?

ভবিষ্যতে ব্যবসা বাড়লে নতুন তথ্য বা টেবিল সহজে যোগ করা যায়।

২৮. একটা Schema-তে ডকুমেন্টেশন কেন প্রয়োজন?

অন্য ডেভেলপার বা টিম সদস্যরা সহজে বুঝতে ও কাজ চালিয়ে যেতে পারে।

২৯. Cloud Database-এর একটা সুবিধা কী?

বিশাল স্কেলে ডেটা সংরক্ষণ ও দূর থেকে টিমওয়ার্ক করা যায়।

৩০. কেন Schema ডিজাইন প্রথমেই ভালোভাবে করা উচিত?

পরবর্তীতে কাঠামো পরিবর্তন করা জটিল ও ঝুঁকিপূর্ণ হতে পারে, তাই শুরুতেই সঠিক পরিকল্পনা গুরুত্বপূর্ণ।

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

১. Schema আসলে কী?
(ক) একটা রেকর্ড (খ) ডেটাবেজের সংগঠন-পরিকল্পনা (গ) একটা কলাম (ঘ) একটা SQL কমান্ড

উত্তর: (খ) ডেটাবেজের সংগঠন-পরিকল্পনা

২. প্রতিটা রেকর্ডকে অনন্যভাবে শনাক্ত করে কোনটা?
(ক) Foreign Key (খ) Column (গ) Primary Key (ঘ) Row

উত্তর: (গ) Primary Key

৩. একজন শিক্ষক একাধিক শিক্ষার্থীকে পড়ালে এটা কোন সম্পর্ক?
(ক) One-to-One (খ) One-to-Many (গ) Many-to-Many (ঘ) কোনোটাই না

উত্তর: (খ) One-to-Many

৪. Many-to-Many সম্পর্কে কী দরকার হয়?
(ক) কিছুই না (খ) শুধু Primary Key (গ) একটা junction টেবিল (ঘ) DROP কমান্ড

উত্তর: (গ) একটা junction টেবিল

৫. নিচের কোনটি ভালো Schema-এর বৈশিষ্ট্য?
(ক) সব তথ্য একটা টেবিলে (খ) ডুপ্লিকেট ডেটা বেশি (গ) সঠিকভাবে ভাগ করা টেবিল (ঘ) কোনো Key ছাড়া টেবিল

উত্তর: (গ) সঠিকভাবে ভাগ করা টেবিল

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

একটা "E-commerce" সিস্টেমের জন্য Schema ডিজাইন করো — কমপক্ষে ৪টা টেবিল (Customers, Products, Orders, Payments) ও তাদের ফিল্ড, Primary Key ও Foreign Key উল্লেখ করে।
Database Architecture ডায়াগ্রাম (User → Application → Database → Schema → Tables → Rows) নিজ হাতে এঁকে আনো।
One-to-One, One-to-Many ও Many-to-Many সম্পর্কের একটা করে নিজের তৈরি বাস্তব উদাহরণ লেখো (আজকের ক্লাসের উদাহরণ ছাড়া অন্য কিছু)।

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

Schema কেন দরকার?

❓ এই সবকিছু কি একটাই টেবিলে রাখা উচিত?

❓ এই বিশাল তথ্য কীভাবে সাজাবো?

❓ হাজার হাজার কর্মী কীভাবে দ্রুত সঠিক তথ্য খুঁজে পাবে?

Schema কী?

Schema-এর উপাদান

🗄️ Database

🗂️ Schema

📋 Table (টেবিল)

📊 Column (কলাম)

📄 Row (সারি)

🔤 Data Type (ডেটা টাইপ)

🔒 Constraint (নিয়ন্ত্রণ শর্ত)

🔑 Primary Key (প্রাইমারি কী)

🔗 Foreign Key (ফরেন কী)

🔀 Relationship (সম্পর্ক)

একটা Schema ডিজাইন করা

কোন কোন টেবিল দরকার ও কেন

ধারণাগত ER ডায়াগ্রাম

SQL-এ Schema তৈরি করা

ধাপ ১: Database তৈরি করা

ধাপ ২: Database ব্যবহার করা

ধাপ ৩: একাধিক টেবিল তৈরি করা

নামকরণের নিয়ম (Naming Conventions)

Schema-এর ভেতরের সম্পর্কের ধরন

1️⃣ One-to-One (এক-থেকে-এক)

2️⃣ One-to-Many (এক-থেকে-বহু)

3️⃣ Many-to-Many (বহু-থেকে-বহু)

ভালো Schema বনাম খারাপ Schema

বাস্তব শিল্প-প্রয়োগ

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

ধাপ ১: Database তৈরি ও ব্যবহার

ধাপ ২: একাধিক টেবিল তৈরি ও সংযুক্ত করা

ধাপ ৩: Schema-এর গঠন দেখা

ধাপ ৪: নমুনা ডেটা যোগ করা

ধাপ ৫: সম্পর্ক যাচাই করা (JOIN দিয়ে একসাথে দেখা)

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

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

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

🧩 সামঞ্জস্যপূর্ণ ডিজাইন

🔁 ডুপ্লিকেট ডেটা এড়ানো

📝 ডকুমেন্টেশন

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

🔐 নিরাপত্তা

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

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

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

🏛️ সম্পূর্ণ ডেটাবেজ আর্কিটেকচার ডায়াগ্রাম

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

🏥 এন্ড-টু-এন্ড মিনি প্রজেক্ট: হাসপাতাল ম্যানেজমেন্ট Schema

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

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

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

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

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