এই পর্বে যা শিখবেন
- এই কোর্স কার জন্য, আর ৬৭টি পর্ব ১০টি মডিউলে কীভাবে সাজানো
- ডেটা, তথ্য আর জ্ঞানের পার্থক্য — একটি মুদি দোকানের খাতা দিয়ে
- ডেটাবেস, DBMS আর database system — তিনটি আলাদা জিনিস, আর DBMS-এর পাঁচটি মূল কাজ
- কারা ডেটাবেস নিয়ে কাজ করেন — end user, developer, DBA, analyst ও data engineer
- পাতায় বসেই প্রথম তিনটি SQL কোয়েরি, আর কখন Excel যথেষ্ট নয়
- জনপ্রিয় DBMS-গুলো কীসের জন্য পরিচিত, আর Codd থেকে NoSQL পর্যন্ত সংক্ষিপ্ত ইতিহাস
১ · স্বাগতম — এই কোর্স কার জন্য, কীভাবে সাজানো
ধরুন সকালে আপনি মোবাইল ওয়ালেটে মাকে টাকা পাঠালেন, দুপুরে অনলাইনে একটি বই অর্ডার করলেন, আর রাতে ট্রেনের টিকিট কাটলেন। তিনটি কাজ, তিনটি আলাদা অ্যাপ। কিন্তু তিনটির পেছনেই একই ধরনের একটি জিনিস চুপচাপ কাজ করছে — একটি ডেটাবেস. টাকা কার অ্যাকাউন্ট থেকে কাটা হলো, বইটি স্টকে আছে কি না, সিটটি অন্য কেউ আগেই নিয়ে ফেলেছেন কি না — প্রতিটি প্রশ্নের উত্তর আসে ডেটাবেস থেকে, এক সেকেন্ডেরও কম সময়ে।
এই কোর্সে আমরা সেই নীরব কর্মীটিকে খুলে দেখব: নকশা, SQL দিয়ে প্রশ্ন, দুজন একসাথে শেষ সিট কিনতে চাইলে কী ঘটে, আর বিদ্যুৎ গেলে ডেটা কেন হারায় না।
এই কোর্স কার জন্য
একেবারে নতুন
দোকান বা অফিসের হিসাব রাখেন, Excel-এ আটকে যাচ্ছেন — প্রোগ্রামিং না জানলেও চলবে।
মডিউল ১–৩ দিয়ে শুরুবিশ্ববিদ্যালয়ের শিক্ষার্থী
Database Systems বিষয়ের পুরো সিলেবাস — ER মডেল, relational algebra, normalization-এর প্রমাণ, transaction, recovery, indexing.
তত্ত্ব + প্রমাণচাকরি আর ইন্টারভিউর প্রস্তুতি
IT অফিসার, ব্যাংকের IT পদ, লিখিত পরীক্ষার DBMS অংশ, software engineer ও data analyst ইন্টারভিউ।
মডিউল ১০কর্মরত developer ও analyst
ORM-এর আড়ালে কী ঘটে, কোয়েরি কেন ধীর, কোন isolation level — “আরও গভীরে” বাক্সগুলো আপনার জন্য।
PostgreSQL, MySQL, SQLite-এর আসল আচরণপ্রতিটি পর্বে আগে পরিচিত উদাহরণ, তারপর সঠিক সংজ্ঞা আর SQL, তারপর ঐচ্ছিক “আরও গভীরে”; শেষে ভাবনার প্রশ্ন, অনুশীলন আর কুইজ। পুরো কোর্সের পথ নিচের রোডম্যাপে “পরে” চেপে দেখুন:
- ভিত্তি ও নকশা
M1–M2পর্ব ১–১১ - SQL
M3–M4পর্ব ১২–৩১ - তত্ত্ব
M5পর্ব ৩২–৩৮ - ভেতরের যন্ত্র
M6–M7পর্ব ৩৯–৪৮ - বাস্তব জগৎ ও পরীক্ষা
M8–M10পর্ব ৪৯–৬৭
মডিউল ১ · ডেটাবেসের ভিত্তি পর্ব ১–৬
ডেটাবেস কেন, ফাইল সিস্টেমের সমস্যা, DBMS-এর গঠন,
ডেটা মডেল, relational model, key ও integrity
মডিউল ২ · ডেটাবেস ডিজাইন পর্ব ৭–১১
ER ও EER মডেল, cardinality, ER থেকে টেবিল,
দুটি পূর্ণ ডিজাইন কেস স্টাডি
মডিউল ৩ · SQL-এর ভিত্তি পর্ব ১২–২৩ সেটআপ, CREATE TABLE, INSERT/UPDATE/DELETE, SELECT, NULL, ফাংশন, GROUP BY, JOIN, subquery, UNION মডিউল ৪ · উন্নত SQL পর্ব ২৪–৩১ view, CTE, window function, প্রচলিত প্যাটার্ন, stored procedure, trigger, JSON, SQL-এর উপভাষা
মডিউল ৫ · তত্ত্ব পর্ব ৩২–৩৮
relational algebra ও calculus,
functional dependency, closure, canonical cover,
1NF → 2NF → 3NF → BCNF → 4NF → 5NF,
lossless join, denormalization — প্রমাণসহ
মডিউল ৬ · স্টোরেজ, ইনডেক্স, কোয়েরি প্রসেসিং পর্ব ৩৯–৪৩ page ও buffer pool, B+ tree, EXPLAIN, join অ্যালগরিদম, optimizer কীভাবে plan বাছে মডিউল ৭ · ট্রানজ্যাকশন ও কনকারেন্সি পর্ব ৪৪–৪৮ ACID, serializability, lock ও 2PL, MVCC, isolation level, WAL, ARIES recovery
মডিউল ৮ · অ্যাপ, নিরাপত্তা ও পরিচালনা পর্ব ৪৯–৫৩ driver, ORM, SQL injection প্রতিরোধ, backup, tuning মডিউল ৯ · বড় মাপের ডেটা ও NoSQL পর্ব ৫৪–৬২ sharding, CAP, warehouse, MongoDB, Redis, vector database, cloud, ক্যাপস্টোন মডিউল ১০ · পরীক্ষা ও ইন্টারভিউ প্রস্তুতি পর্ব ৬৩–৬৭ output prediction, MCQ, লিখিত-ভাইভা, ইন্টারভিউ
- ভিত্তি ও নকশা (পর্ব ১–১১). ডেটাবেস কেন লাগে, DBMS ভেতরে কীভাবে স্তরে স্তরে সাজানো, আর relational model-এর মূল ভাষা — টেবিল, সারি, key. তারপর কোড লেখার আগেই কাগজে ডেটাবেসের নকশা (ER diagram) আঁকা।
- SQL (পর্ব ১২–৩১). কোর্সের সবচেয়ে বড় অংশ। পর্ব ১২-এ নিজের কম্পিউটারে SQLite, MySQL বা PostgreSQL বসাবেন; প্রতিটি পর্বে পাতাতেই আসল SQL চালাবেন। শেষে window function আর ইন্টারভিউর প্রিয় প্যাটার্নগুলো।
- তত্ত্ব (পর্ব ৩২–৩৮). SQL-এর পেছনের গণিত: relational algebra আর functional dependency. এখানেই normalization — কোন টেবিল কেন ভাঙতে হয়, আর ভাঙলে তথ্য হারায় না, তার প্রমাণ।
- ভেতরের যন্ত্র (পর্ব ৩৯–৪৮). ডিস্কে ডেটা কীভাবে থাকে, index কেন কোয়েরিকে বহু গুণ দ্রুত করে, optimizer কীভাবে সিদ্ধান্ত নেয়, আর হাজারো লেনদেন একসাথে চললেও হিসাব কেন মেলে।
- বাস্তব জগৎ ও পরীক্ষা (পর্ব ৪৯–৬৭). অ্যাপ থেকে নিরাপদে ডেটাবেসে কথা বলা, backup, distributed ব্যবস্থা, NoSQL আর vector database. পর্ব ৬২-এর ক্যাপস্টোনে নিজে একটি পূর্ণ ডেটাবেস বানাবেন; শেষ পাঁচটি পর্ব পরীক্ষা ও ইন্টারভিউর প্রস্তুতি।
শুধু কাজের SQL চাইলে মডিউল ১, ৩ আর ৪ আগে পড়ুন; বিশ্ববিদ্যালয়ের পরীক্ষার জন্য মডিউল ২, ৫ আর ৭ বিশেষ জরুরি।
২ · ডেটা, তথ্য আর জ্ঞান — মুদি দোকানের খাতা থেকে
মোড়ের মুদি দোকানের করিম চাচার কথা ভাবুন। প্রতিদিন বিক্রির পর তিনি একটি লাল খাতায় লিখে রাখেন — কবে, কী, কত টাকা। বছরের পর বছর এভাবে লেখা চলছে। এই খাতার প্রতিটি লাইন হলো ডেটা — কাঁচা, আলাদা আলাদা তথ্যের টুকরো। একা একটি লাইন “চাল ৫ কেজি ৪২০” দেখে আপনি তেমন কিছুই বুঝবেন না: ভালো বিক্রি, না খারাপ? এটা কি নিয়মিত, না হঠাৎ?
কিন্তু খাতাটি গুছিয়ে হিসাব করলেই প্রশ্নের উত্তর বেরিয়ে আসে। নিচের ডায়াগ্রামে দেখুন, একই খাতা চার ধাপে কীভাবে কাঁচা ডেটা থেকে একটি ব্যবসায়িক সিদ্ধান্তে পৌঁছায়:
- কাঁচা লেখা
খাতাএলোমেলো - সাজানো ডেটা
টেবিলসারি আর কলাম - তথ্য
মাসিক হিসাবপ্রশ্নের উত্তর - জ্ঞান
সিদ্ধান্তকী করা উচিত
২ তারিখ — চাল ৫ কেজি ৪২০, তেল ১ লি. ২৬০
৫ — চাল ৫ কেজি, ৪২০ টাকা (বাকি)
১১ তারিখ ডাল এক কেজি ১৪০
১৮/৯ — তেল ২৬০
২৫ — চাল ৫ কেজি ৪২০ … নগদ না বাকি লেখা নেই
date │ item │ qty │ amount 2025-09-02 │ চাল │ 5 kg │ 420 2025-09-02 │ তেল │ 1 L │ 260 2025-09-05 │ চাল │ 5 kg │ 420 2025-09-11 │ ডাল │ 1 kg │ 140 2025-09-18 │ তেল │ 1 L │ 260 2025-09-25 │ চাল │ 5 kg │ 420
item │ বিক্রি │ মোট টাকা চাল │ 3 বার │ 1260 তেল │ 2 বার │ 520 ডাল │ 1 বার │ 140 ─────┼────────┼───────── মোট │ 6 বার │ 1920
চাল = 1260 / 1920 ≈ 66% বিক্রি
চালের ৩টি বিক্রির ২টি মাসের প্রথম সপ্তাহে
→ মাসের শুরুতে চালের মজুত বাড়ান
→ তেল-ডালের সাথে চালের ছোট প্যাকেজ ভাবুন
- কাঁচা লেখা — ডেটা, কিন্তু এলোমেলো। তারিখ কখনো “২ তারিখ”, কখনো “১৮/৯”; পরিমাণ কখনো “৫ কেজি”, কখনো লেখাই নেই। একটি লাইনে দুটি বিক্রি, আরেকটিতে “বাকি” আছে কি নেই বোঝা যায় না। এমন খাতা থেকে “এ মাসে মোট কত বিক্রি” বের করতে করিম চাচাকে পুরো খাতা হাতে যোগ করতে হবে।
- সাজানো ডেটা — টেবিল। এবার প্রতিটি বিক্রি একটি সারি, আর প্রতিটি ধরনের তথ্য একটি নির্দিষ্ট কলাম: তারিখ সবসময় একই ছাঁচে (
2025-09-02), পরিমাণ আলাদা কলামে, টাকা আলাদা কলামে। প্রথম লাইনের দুটি বিক্রি এখন দুটি আলাদা সারি। এখনো এটি ডেটাই, কিন্তু এমন ডেটা যা দিয়ে কম্পিউটার হিসাব করতে পারে। - তথ্য — একটি প্রশ্নের উত্তর। প্রশ্ন: “সেপ্টেম্বরে কোন পণ্য থেকে কত এলো?” পণ্য অনুযায়ী দল করে যোগ করলেই উত্তর: চাল ৩ বারে ১,২৬০ টাকা, তেল ২ বারে ৫২০, ডাল ১ বারে ১৪০ — মোট ৬টি বিক্রিতে ১,৯২০ টাকা। প্রসঙ্গসহ, হিসাব করা এই ফলটিই তথ্য. SQL-এ ঠিক এই কাজের নাম
GROUP BY— পর্ব ১৮-এ শিখবেন। - জ্ঞান — কী করা উচিত। তথ্য বলছে বিক্রির প্রায় দুই-তৃতীয়াংশ (১,২৬০ ÷ ১,৯২০ ≈ ৬৬%) চাল থেকে, আর চালের তিনটি বিক্রির দুটি মাসের প্রথম সপ্তাহে (২ ও ৫ তারিখ)। এর সাথে করিম চাচার অভিজ্ঞতা — “মাসের শুরুতে বেতন হয়” — মেলালে একটি সিদ্ধান্ত দাঁড়ায়: মাসের শুরুতে চালের মজুত বাড়ান। একেই বলে জ্ঞান. মাত্র ছয়টি লাইন থেকে বড় সিদ্ধান্ত নেওয়া ঝুঁকি; কয়েক মাসের ডেটা দেখে নিশ্চিত হওয়া ভালো।
ডেটা হলো কাঁচা তথ্যের টুকরো (৪২০, চাল, ২ সেপ্টেম্বর)। তথ্য (information) হলো প্রসঙ্গসহ সাজানো ও হিসাব করা ডেটা, যা একটি প্রশ্নের উত্তর দেয় (সেপ্টেম্বরে চাল বিক্রি ১,২৬০ টাকা)। জ্ঞান (knowledge) হলো তথ্য থেকে পাওয়া বোঝাপড়া, যার ভিত্তিতে কাজ করা যায় (মাসের শুরুতে মজুত বাড়ান)। ব্যবস্থাপনা-বিজ্ঞানে এই সিঁড়িকে প্রায়ই DIKW পিরামিড বলা হয় — Data, Information, Knowledge, Wisdom.
একটি সূক্ষ্ম কথা: কোনটা ডেটা আর কোনটা তথ্য, তা নির্ভর করে প্রশ্নের ওপর। “সেপ্টেম্বরে মোট বিক্রি ১,৯২০ টাকা” করিম চাচার কাছে তথ্য; কিন্তু ৫০০ দোকানের বিক্রি জড়ো করা একটি পাইকারি কোম্পানির কাছে এটি কাঁচা ডেটা।
আর দ্বিতীয় ধাপের টেবিলের ওপরের লাইন date │ item │ qty │ amount কোনো বিক্রি নয়; এটি বলছে ডেটা কেমন দেখতে। ডেটা সম্পর্কে এই ডেটাকে বলে metadata, আর পুরো নকশাটিকে বলে schema. খাতায় schema থাকে করিম চাচার মাথায়; ডেটাবেসে সেটি লিখিত, আর DBMS তা মানতে বাধ্য করে।
৩ · ডেটাবেস আর DBMS — সংজ্ঞা আর পাঁচটি কাজ
এবার তিনটি শব্দ আলাদা করে বুঝে নিই, কারণ পরীক্ষায় আর ইন্টারভিউতে এগুলো প্রায়ই গুলিয়ে যায়।
ডেটাবেস (database) হলো পরস্পর সম্পর্কিত ডেটার একটি সুসংগঠিত সংগ্রহ, যা একটি নির্দিষ্ট উদ্দেশ্যে রাখা হয় এবং অনেক ব্যবহারকারী ও প্রোগ্রাম ভাগ করে ব্যবহার করে। DBMS (Database Management System) হলো সেই সফটওয়্যার, যা ডেটাবেস তৈরি করা, সংরক্ষণ করা, খোঁজা, বদলানো আর রক্ষা করার কাজ করে। আর database system হলো পুরো ব্যবস্থাটি — ডেটা, DBMS, তার ওপর চলা অ্যাপ্লিকেশন আর ব্যবহারকারী মিলিয়ে।
একটি বিশ্ববিদ্যালয়ের লাইব্রেরির কথা ভাবুন। তাকে সাজানো হাজার হাজার বই হলো ডেটাবেস। লাইব্রেরিয়ান আর তাঁর ব্যবস্থাটি — কোন বই কোন তাকে, কে কোন বই নিয়েছেন, কাকে ঢুকতে দেওয়া হবে, আগুন লাগলে ক্যাটালগের কপি কোথায় — হলো DBMS. আপনি সরাসরি তাকে হাত দেন না; লাইব্রেরিয়ানকে বলেন “Codd-এর লেখা বইটা দিন”, আর তিনি ঠিক করেন কোথা থেকে কীভাবে আনবেন। পুরো লাইব্রেরি — বই, লাইব্রেরিয়ান, ইস্যু-কাউন্টার আর পাঠকেরা মিলে — হলো database system.
DBMS-এর পাঁচটি মূল কাজ
একটি ফাইলে ডেটা লিখে রাখা তো যেকোনো প্রোগ্রামই পারে। তাহলে আলাদা একটি DBMS-এর দরকার কেন? কারণ ডেটা রাখা সহজ; কঠিন হলো একসাথে অনেক মানুষের জন্য, নিরাপদে, নির্ভুলভাবে, দ্রুত আর দুর্ঘটনার পরেও ঠিকঠাক রাখা। এই কঠিন কাজগুলো DBMS প্রতিটি অ্যাপের হয়ে একবারে করে দেয়:
১. সংরক্ষণ (storage)
ডেটা ডিস্কে কীভাবে, কোন ক্রমে, কোন ফাইলে থাকবে — সব DBMS সামলায়। অ্যাপকে শুধু টেবিল আর কলামের নাম জানতে হয়; ডিস্কের খুঁটিনাটি লুকানো থাকে। একে বলে data independence (পর্ব ৩).
page, file, index২. প্রশ্নের উত্তর (query)
আপনি SQL-এ বলেন কী চান; DBMS-এর query optimizer নিজে ঠিক করে কীভাবে সবচেয়ে কম খরচে খুঁজবে — পুরো টেবিল পড়বে, না index দিয়ে সরাসরি যাবে।
SQL, optimizer৩. একসাথে অনেকে (concurrency)
ঈদের আগে একই ট্রেনের শেষ সিটে একই মুহূর্তে দুজন ক্লিক করলেন। Concurrency control নিশ্চিত করে সিটটি ঠিক একজনই পাবেন — দুজন নয়, আবার কেউ না পেয়েও নয়।
lock, MVCC৪. নিরাপত্তা (security)
হাসপাতালের রিসেপশনিস্ট রোগীর নাম-ঠিকানা দেখবেন, কিন্তু রিপোর্ট দেখবেন শুধু ডাক্তার। Access control দিয়ে DBMS ঠিক করে কে কোন টেবিল, এমনকি কোন কলাম দেখতে বা বদলাতে পারবেন।
user, GRANT, REVOKE৫. পুনরুদ্ধার (recovery)
টাকা কাটা হলো, কিন্তু জমা হওয়ার আগেই লোডশেডিং! চালু হওয়ার পর recovery ব্যবস্থা log দেখে হয় পুরো লেনদেনটি শেষ করে, নয়তো পুরোটা বাতিল করে — অর্ধেক কখনো নয়।
log, backupএর সাথে জড়িয়ে আছে নিয়ম রক্ষা (integrity): নমুনা দোকানের ডেটাবেসে পণ্যের দাম শূন্যের বেশি হতেই হবে — অ্যাপের কোডে ভুল থাকলেও DBMS −৫০ টাকা দাম লেখার চেষ্টা বাতিল করে দেবে (পর্ব ৬).
একটি লেনদেন DBMS-এর ভেতর দিয়ে
পাঁচটি কাজ কীভাবে একসাথে খাটে, একটি উদাহরণে দেখি। রহিম মোবাইল ওয়ালেটে করিমকে ১,০০০ টাকা পাঠাচ্ছেন। অ্যাপটি DBMS-কে দুটি পরিবর্তন একটি transaction-এর ভেতরে পাঠায় — রহিমের ব্যালান্স থেকে কাটা আর করিমের ব্যালান্সে যোগ করা। (এটি শেখানোর জন্য সরল করা একটি মডেল; আসল ওয়ালেট কোম্পানির ব্যবস্থা অনেক বেশি স্তরে সাজানো।)
- অ্যাপ
BEGIN … COMMITঅনুরোধ পাঠায় - নিরাপত্তা
privilegeঅনুমতি আছে? - Query processor
parse + planকীভাবে খুঁজবে - Concurrency
lockঅন্যরা অপেক্ষা করুক - Log ও storage
WAL → diskহারাবে না
BEGIN; UPDATE accounts SET balance = balance - 1000 WHERE owner = 'Rahim'; UPDATE accounts SET balance = balance + 1000 WHERE owner = 'Karim'; COMMIT;
| রহিমের balance | |
| করিমের balance | |
| দুজনের মোট | |
| log-এ লেখা |
- অ্যাপ অনুরোধ পাঠাল। অ্যাপ নিজে ডিস্কে কিছু লেখে না; সে DBMS-কে SQL পাঠায়।
BEGINআরCOMMIT-এর মাঝের দুটিUPDATEমিলে একটি transaction — হয় দুটোই হবে, নয় কোনোটাই নয়। এখনো কিছু বদলায়নি: রহিম ৫,০০০, করিম ২,০০০. - নিরাপত্তা যাচাই। যে database user হিসেবে অ্যাপটি যুক্ত হয়েছে, তার কি
accountsটেবিলেUPDATEকরার অনুমতি আছে? থাকলে এগোবে, না থাকলে এখানেই ত্রুটি। ভালো ব্যবস্থায় অ্যাপের user-কে ঠিক যতটুকু দরকার ততটুকুই অনুমতি দেওয়া হয় (পর্ব ৫১). - Query processor পরিকল্পনা করল। DBMS SQL-এর ব্যাকরণ যাচাই করল (parse), তারপর optimizer ঠিক করল দুটি সারি কীভাবে খুঁজবে —
ownerকলামে index থাকলে লাখো সারি একে একে না পড়ে সরাসরি (পর্ব ৪০–৪৩). - Concurrency control দুটি সারি আটকে দিল। এই মুহূর্তে রহিমের আরেকটি পেমেন্ট এলে সে অপেক্ষা করবে, যাতে দুটি লেনদেন একই পুরোনো ব্যালান্স পড়ে ভুল হিসাব না করে। মান এখনো বদলায়নি (পর্ব ৪৬–৪৭).
- আগে log, তারপর COMMIT. DBMS প্রথমে পরিবর্তনের বিবরণ log ফাইলে লিখে ডিস্কে নিশ্চিত করে — একে বলে write-ahead log. তারপর
COMMIT: রহিম ৪,০০০, করিম ৩,০০০. প্রতিটি ধাপে দুজনের মোট ৭,০০০ — টাকা তৈরিও হয়নি, হারায়ওনি। এখন বিদ্যুৎ গেলেও recovery log পড়ে লেনদেনটি ফিরিয়ে আনবে (পর্ব ৪৪, ৪৮).
এই উদাহরণে যে চারটি গ্যারান্টি পেলাম — পুরোটা বা কিছুই না, নিয়ম না ভাঙা, একে অপরকে বিরক্ত না করা, আর COMMIT হলে না হারানো — একসাথে এদের নাম ACID. মডিউল ৭ পুরোটাই এর গল্প।
এবার পুরো database system-টি এক ছবিতে দেখি:
Database system-এর চার অংশ
Users → Applications → DBMS → Data
- ব্যবহারকারী
usersগ্রাহক, কর্মী, analyst, DBA - অ্যাপ্লিকেশন
app, websiteফর্ম, বোতাম, রিপোর্ট - DBMS
PostgreSQL, MySQL…পাঁচটি মূল কাজ - ডেটা
tables + metadataডিস্কে সংরক্ষিত
আরও গভীরে: সব DBMS একইভাবে “চলে” না। PostgreSQL, MySQL, Oracle বা SQL Server হলো client-server ব্যবস্থা — একটি আলাদা সার্ভার প্রোগ্রাম সারাক্ষণ চলে, আর অ্যাপগুলো network দিয়ে তার সাথে যুক্ত হয় (PostgreSQL প্রতিটি সংযোগের জন্য আলাদা একটি OS process চালায়, MySQL চালায় thread). অন্যদিকে SQLite একটি embedded library: অ্যাপের ভেতরেই চলে, কোনো সার্ভার নেই, আর পুরো ডেটাবেস থাকে একটিমাত্র ফাইলে। তবু দুই ধরনের ভেতরেই উপরের পাঁচটি কাজ আছে — SQLite-ও transaction, lock আর journal/WAL দিয়ে crash-এর পর ডেটা রক্ষা করে।
৪ · দৈনন্দিন জীবনে লুকানো ডেটাবেস
ডেটাবেস চোখে দেখা যায় না, কিন্তু আপনার দিনের প্রায় প্রতিটি ডিজিটাল কাজ এর ওপর দাঁড়িয়ে। নিচের উদাহরণগুলো সাধারণভাবে বলা — কোন প্রতিষ্ঠান ঠিক কোন সফটওয়্যার ব্যবহার করে, তা সাধারণত প্রকাশ্য নয়, আর এখানে তা দাবিও করা হচ্ছে না। কিন্তু প্রতিটি ক্ষেত্রে কী ধরনের ডেটা থাকে আর DBMS-এর কোন কাজটি সবচেয়ে জরুরি, সেটি ভাবা যায়:
| যেখানে | কী ধরনের ডেটা থাকে | DBMS-এর সবচেয়ে জরুরি কাজ |
|---|---|---|
| জাতীয় পরিচয়পত্র (NID) যাচাই | নাম, জন্মতারিখ, ঠিকানা, ছবি; সিম নিবন্ধন বা ব্যাংক অ্যাকাউন্ট খোলার সময় যাচাই | নিরাপত্তা — খুব সংবেদনশীল ব্যক্তিগত তথ্য; কোন প্রতিষ্ঠান কতটুকু দেখবে তার কড়া নিয়ন্ত্রণ |
| মোবাইল ওয়ালেট (bKash, Nagad ইত্যাদি) | অ্যাকাউন্ট, ব্যালান্স, প্রতিটি লেনদেনের রেকর্ড | Transaction আর recovery — এক টাকাও যেন তৈরি না হয় বা না হারায় |
| ট্রেনের অনলাইন টিকিট | ট্রেন, তারিখ, বগি, সিট, যাত্রী, পেমেন্ট | Concurrency — উৎসবের আগে একই সিটে একসাথে অনেকের চেষ্টা |
| হাসপাতালের রেকর্ড | রোগী, ডাক্তার, ভর্তি, পরীক্ষার রিপোর্ট, ওষুধ | নিরাপত্তা ও নির্ভুলতা — ভুল রোগীর রিপোর্ট মানে বিপদ |
| সোশ্যাল মিডিয়া (Facebook ইত্যাদি) | ব্যবহারকারী, বন্ধুত্ব, পোস্ট, লাইক, মন্তব্য | বিশাল মাপ — বহু দেশে ছড়ানো অনেক সার্ভারে ডেটা ভাগ করা (পর্ব ৫৪) |
| অনলাইন দোকান | গ্রাহক, পণ্য, স্টক, অর্ডার, ডেলিভারি | সবকিছু একসাথে — স্টক ভুল হলে নেই এমন পণ্য বিক্রি হয়ে যায় |
| আপনার নিজের ফোন | কনট্যাক্ট, মেসেজ, অ্যাপের সেটিং | ছোট, দ্রুত, সার্ভার ছাড়া — Android ও iOS-এ এ কাজে SQLite বহুল ব্যবহৃত |
শেষ সারিটি খেয়াল করুন: ডেটাবেস শুধু বড় কোম্পানির সার্ভারে থাকে না — আপনার পকেটের ফোনেই সম্ভবত অনেকগুলো ছোট ডেটাবেস ফাইল আছে।
বিশ্ববিদ্যালয়ের পুরোনো রেজিস্টার খাতার কথা ভাবুন — একটি খাতায় শিক্ষার্থীর নাম, আরেকটিতে কোর্সের ফল, আরেকটিতে বেতনের হিসাব, তিনটি আলাদা অফিসে। ঠিকানা বদলালে তিন জায়গায় বদলাতে হয়; একজন ভুলে গেলে তিন খাতায় তিন রকম ঠিকানা। এই redundancy আর inconsistency দূর করতেই DBMS এসেছিল — পর্ব ২-এর গল্প।
৫ · কারা ডেটাবেস নিয়ে কাজ করেন
একটি অনলাইন দোকানের ডেটাবেসকে ঘিরে কয়েক ধরনের মানুষ কাজ করেন। প্রত্যেকে ডেটাবেসকে আলাদা চোখে দেখেন, আর প্রত্যেকের কাজ এই কোর্সের আলাদা অংশে বেশি কাজে লাগে:
| ভূমিকা | কী করেন | SQL কতটা জানতে হয় | কোর্সের কোন অংশ |
|---|---|---|---|
| End user | অ্যাপে পণ্য খোঁজেন, অর্ডার দেন। দোকানের কর্মী ফর্ম পূরণ করেন। | একদম না — অ্যাপ তাঁদের হয়ে SQL পাঠায় | — |
| Application developer | অ্যাপ আর ওয়েবসাইট বানান; ডেটাবেস থেকে পড়া-লেখার কোড লেখেন, টেবিলের নকশা করেন | ভালোভাবে — JOIN, transaction, index, নিরাপদ কোয়েরি | মডিউল ২–৪, ৬–৮ |
| DBA (Database Administrator) | ডেটাবেস চালু রাখেন: backup, user ও অনুমতি, পারফরম্যান্স, আপগ্রেড, দুর্ঘটনার পর পুনরুদ্ধার | খুব গভীরে — DBMS-এর ভেতরের আচরণসহ | মডিউল ৬–৮ |
| Data analyst | ডেটা থেকে প্রশ্নের উত্তর আর রিপোর্ট বের করেন: “কোন জেলায় বিক্রি কমছে?” | খুব ভালো — GROUP BY, JOIN, window function | মডিউল ৩–৪, ৯ |
| Data engineer | নানা উৎস থেকে ডেটা এনে পরিষ্কার করে এক জায়গায় জড়ো করার পাইপলাইন বানান | খুব ভালো — সাথে warehouse, distributed system | মডিউল ৪, ৬, ৯ |
ছোট প্রতিষ্ঠানে প্রায়ই একজনই তিন-চারটি ভূমিকা পালন করেন — developer-ই DBA, রিপোর্টও তিনিই বানান। বড় প্রতিষ্ঠানে প্রতিটি আলাদা দল। এর বাইরে আছেন database designer (যিনি শুরুতে schema-র নকশা করেন) আর যাঁরা DBMS সফটওয়্যারটিই বানান, সেই DBMS developer-রা।
ভূমিকা যা-ই হোক, একটি দক্ষতা সবার লাগে: সঠিক প্রশ্ন করা, আর উত্তরটি সত্যিই ঠিক কি না যাচাই করা। ভুল JOIN-এর জন্য রিপোর্টে বিক্রি দ্বিগুণ দেখালে কোড চলেছে বলে কেউ টেরও পায় না।
৬ · SQL-এর প্রথম স্বাদ — পাতায় বসেই
অনেক কথা হলো, এবার হাতে-কলমে। এই কোর্সের প্রতিটি পর্বে একটি নমুনা দোকানের ডেটাবেস (db-shop) থাকবে — একটি ছোট ই-কমার্স ব্যবসা, ৮ জন গ্রাহক, ১০টি পণ্য আর ১০টি অর্ডার নিয়ে। আজ আমরা শুধু এর একটি টেবিল ব্যবহার করব: customers (গ্রাহক)। এর কলামগুলো:
customer_id— প্রতিটি গ্রাহকের আলাদা নম্বর (১ থেকে ৮)। দুজনের একই নম্বর হতে পারে না; এমন কলামকে বলে primary key (পর্ব ৬).name— গ্রাহকের নাম;city— শহর;phone— মোবাইল নম্বর।joined_on— কবে যোগ দিয়েছেন,YYYY-MM-DDছাঁচে।
নিচের প্রতিটি বাক্সে আসল SQL লেখা। “চালান” চাপলে আপনার ব্রাউজারের ভেতরেই একটি আসল SQLite ডেটাবেস তৈরি হবে, নমুনা ডেটা ঢুকবে, আর কোয়েরির ফল টেবিল হয়ে দেখাবে। কোড বদলে আবার চালাতে পারেন — কিছুই নষ্ট হবে না, কারণ প্রতিবার ডেটাবেস নতুন করে তৈরি হয়। “আগের কোড” চাপলে মূল কোড ফিরে আসবে।
প্রথম কোয়েরি — পুরো টেবিল দেখুন
-- customers টেবিলের সব কলাম, সব সারি
SELECT * FROM customers;ফলে আসে ৮টি সারি আর ৫টি কলাম — customer_id ১ (Rahim Uddin, Dhaka) থেকে ৮ (Mitu Rani, Dhaka) পর্যন্ত। SELECT মানে “দেখাও”, * মানে “সব কলাম”, FROM customers মানে “customers টেবিল থেকে”। শেষের ; বলে নির্দেশটি এখানে শেষ। -- দিয়ে শুরু লাইনটি মন্তব্য; DBMS সেটি উপেক্ষা করে। দুটি ঘর খেয়াল করুন: Tanvir Ahmed-এর phone আর Imran Hossain-এর city-তে লেখা NULL. এর মানে “মান জানা নেই” — শূন্য বা ফাঁকা লেখা নয়। NULL পরের দুটি কোয়েরিতেই চমক দেখাবে। চেষ্টা করুন: *-এর জায়গায় name, phone লিখে চালান — এবার শুধু দুটি কলাম আসবে।
দ্বিতীয় কোয়েরি — শর্ত দিয়ে ছাঁকুন
এবার একটি আসল প্রশ্ন: “ঢাকার গ্রাহক কারা?” এর জন্য লাগে WHERE — শর্ত মেলে এমন সারিই শুধু থাকবে।
-- শুধু ঢাকার গ্রাহকদের নাম আর শহর
SELECT name, city
FROM customers
WHERE city = 'Dhaka';ফল ৩টি সারি: Rahim Uddin, Sabbir Hasan আর Mitu Rani — তিনজনেরই city Dhaka. লেখা (text) মান সবসময় একক উদ্ধৃতিচিহ্নে লিখতে হয়: 'Dhaka'. তিন লাইনে ভাঙা শুধু পড়ার সুবিধার জন্য। চেষ্টা করুন: 'Dhaka'-এর জায়গায় 'dhaka' (ছোট হাতের d) লিখে চালান — SQLite-এ কোনো সারি আসবে না, কারণ = দিয়ে লেখার তুলনা এখানে বড়-ছোট হাতের অক্ষর আলাদা ধরে। (MySQL-এর প্রচলিত সেটিংয়ে আবার এই তুলনায় বড়-ছোট হাতের পার্থক্য ধরা হয় না — এমন পার্থক্য পর্ব ৩১-এ দেখবেন।)
আপনি লিখলেন কোন সারি আর কোন কলাম চান — কিন্তু DBMS ভেতরে আসলে কোন ক্রমে কাজটি করল? SQL-এ লেখার ক্রম SELECT → FROM → WHERE, কিন্তু যুক্তির দিক থেকে কাজ হয় উল্টো দিক থেকে। ধাপে ধাপে দেখুন:
| চলমান ধাপ | |
| সারির সংখ্যা | |
| কলামের সংখ্যা |
- FROM — কোন টেবিল। প্রথমে DBMS ঠিক করে কোথা থেকে পড়বে:
customers-এর ৮টি সারি, ৫টি কলামসহ (জায়গা বাঁচাতে এখানে তিনটি কলাম দেখানো হয়েছে)। এখনো কিছু বাদ পড়েনি। - WHERE — কোন সারি। প্রতিটি সারিতে শর্ত
city = 'Dhaka'যাচাই হয়। ১, ৩ আর ৮ নম্বরে সত্য — এরা টিকে থাকে। ২, ৪, ৫, ৬-এ মিথ্যা। আর ৭ নম্বর Imran Hossain-এর city NULL — “অজানা শহর কি ঢাকা?” এর উত্তর সত্যও নয়, মিথ্যাও নয়, বরং অজানা. WHERE শুধু সত্য সারি রাখে, তাই এটিও বাদ। ৮টি থেকে রইল ৩টি সারি। - SELECT — কোন কলাম। টিকে থাকা ৩টি সারি থেকে শুধু
nameআরcityনেওয়া হলো; বাকি তিনটি কলাম বাদ। এটিই আপনার স্ক্রিনের ফল। এই যুক্তির ক্রম — FROM, তারপর WHERE, তারপর SELECT — পর্ব ১৫-এ আরও বড় হবে (GROUP BY, HAVING, ORDER BY, LIMIT যোগ হবে)। আর বাস্তবে DBMS index ব্যবহার করে সরাসরি ঢাকার সারিগুলোতে চলে যেতে পারে; ফল একই থাকে, শুধু পথ বদলায়।
তৃতীয় কোয়েরি — গুনে দেখুন
শেষ প্রশ্ন: “মোট কতজন গ্রাহক, আর কতজনের ফোন নম্বর জানা আছে?” তালিকা নয়, শুধু সংখ্যা চাই। এর জন্য আছে COUNT — একটি aggregate function, যা অনেকগুলো সারি থেকে একটি মান বানায়।
-- মোট গ্রাহক, আর কতজনের ফোন নম্বর আছে
SELECT COUNT(*) AS total_customers,
COUNT(phone) AS with_phone
FROM customers;ফল একটিমাত্র সারি: total_customers = 8, with_phone = 7. দুটি সংখ্যা আলাদা কেন? COUNT(*) গোনে সারি — যা-ই থাকুক, প্রতিটি সারি এক। কিন্তু COUNT(phone) গোনে শুধু সেই সারি, যেখানে phone NULL নয়; Tanvir Ahmed-এর ফোন নম্বর অজানা, তাই তিনি বাদ। AS দিয়ে ফলের কলামের একটি পড়ার মতো নাম দেওয়া হয়েছে। এই ছোট পার্থক্যটি বাস্তবে বড় ভুলের উৎস: “কতজন গ্রাহককে SMS পাঠানো যাবে?” — উত্তর ৮ নয়, ৭. চেষ্টা করুন: COUNT(city) যোগ করে দেখুন — সেটিও ৭ আসবে, কারণ Imran Hossain-এর শহর অজানা। NULL-এর পুরো যুক্তি পর্ব ১৬-এ।
SQL একটি declarative ভাষা — আপনি বলেন কী চান (“ঢাকার গ্রাহকদের নাম”), কীভাবে খুঁজতে হবে তা নয়। কোনো লুপ নেই, “প্রথম সারি থেকে শেষ সারি পর্যন্ত একে একে দেখা”-র নির্দেশও নেই। কীভাবে খুঁজবে, সেই সিদ্ধান্ত DBMS-এর। এই কারণেই বহু বছর আগে লেখা একটি SQL কোয়েরি বদলানো ছাড়াই নতুন সংস্করণের DBMS-এ সাধারণত চলে, আর optimizer বা index উন্নত হলে প্রায়ই আরও দ্রুত চলে।
৭ · Spreadsheet, relational আর NoSQL — কখন কোনটি
“এসব তো Excel-এই করা যায়!” — কথাটি অর্ধেক সত্য। করিম চাচার দোকানের হিসাব, একটি ক্লাসের নম্বরের তালিকা বা মাসিক বাজেটের জন্য spreadsheet চমৎকার টুল: দ্রুত, চোখের সামনে, সূত্র দিয়ে হিসাব, চার্ট। সমস্যা শুরু হয় যখন ডেটা বড় হয়, ব্যবহারকারী বাড়ে, আর ভুলের দাম বাড়ে।
কখন Excel আর যথেষ্ট নয় — পাঁচটি লক্ষণ
এর একটিতেও টিক পড়লে ডেটাবেসের কথা ভাবার সময় হয়েছে। এখন প্রশ্ন — কোন ধরনের ডেটাবেস? মোটা দাগে দুটি পরিবার:
| দিক | Spreadsheet | Relational (SQL) | NoSQL |
|---|---|---|---|
| ডেটা কীভাবে থাকে | ঘর-ভিত্তিক শিট | নির্দিষ্ট কলামের টেবিল, key দিয়ে যুক্ত | ধরন অনুযায়ী: key-value, document (JSON-এর মতো), wide-column, graph |
| নকশা (schema) | নেই বললেই চলে | আগে থেকে ঠিক করা, DBMS মানতে বাধ্য করে | সাধারণত নমনীয় — একেক রেকর্ডে একেক রকম ঘর থাকতে পারে |
| একসাথে অনেক ব্যবহারকারী | সীমিত | শক্তিশালী — transaction ও ACID | পণ্যভেদে ভিন্ন; অনেকে বড় মাপ ও গতির জন্য কিছু গ্যারান্টি শিথিল করে |
| প্রশ্ন করার ভাষা | সূত্র, filter | SQL — মানক ভাষা | প্রতিটি পণ্যের নিজস্ব API বা ভাষা |
| যেখানে সবচেয়ে ভালো | ছোট ডেটা, একজনের বিশ্লেষণ | লেনদেন, হিসাব, পরস্পর-সম্পর্কিত ডেটা — ব্যাংক, দোকান, বিশ্ববিদ্যালয় | বিশাল মাপ, দ্রুত বদলানো গঠন, cache, সোশ্যাল গ্রাফ |
| উদাহরণ | Excel, Google Sheets | PostgreSQL, MySQL, SQLite, Oracle, SQL Server | MongoDB, Redis, Cassandra, Neo4j |
এই কোর্সের বেশিরভাগ অংশ relational database নিয়ে, কারণ ব্যবসা আর লেনদেনের ডেটার বিশাল অংশ আজও এতেই চলে। NoSQL-এর জন্য আলাদা পর্ব আছে (পর্ব ৫৬–৫৯)। বাস্তবের বড় ব্যবস্থায় প্রায়ই দুটোই পাশাপাশি থাকে — অর্ডার আর পেমেন্ট PostgreSQL-এ, আর ঘনঘন দেখা পণ্যের তালিকার একটি কপি Redis-এ।
“NoSQL মানে নতুন, তাই ভালো” — ভুল ধারণা। NoSQL উন্নত সংস্করণ নয়, ভিন্ন সমস্যার ভিন্ন হাতিয়ার। টাকা বা স্টকের মতো যেখানে প্রতিটি সংখ্যা মিলতে হবে, সেখানে transaction-এর শক্ত গ্যারান্টি ছাড়া কিছু বাছতে খুব ভালো কারণ লাগে।
৮ · জনপ্রিয় DBMS — কোনটি কীসের জন্য পরিচিত
DBMS বাজারে অনেক পণ্য, কিন্তু কয়েকটি নাম বারবার আসবে — চাকরির বিজ্ঞাপনে, ইন্টারভিউতে, এই কোর্সে। প্রতিটির একটি “চরিত্র” আছে:
🐘 PostgreSQL
Open source relational DBMS, SQL মানকের প্রতি নিষ্ঠার জন্য সুপরিচিত। শক্তিশালী extension ব্যবস্থা — ভৌগোলিক ডেটার জন্য PostGIS, JSON-এর জন্য JSONB, এমনকি vector খোঁজার extension. নতুন প্রজেক্টে খুব জনপ্রিয় পছন্দ।
client-server · open source🐬 MySQL / MariaDB
ওয়েবের পুরোনো ঘোড়া — WordPress-সহ অসংখ্য ওয়েবসাইট আর shared hosting-এ সাধারণত এটিই থাকে। এখন Oracle-এর মালিকানায় (open source সংস্করণসহ)। MariaDB হলো MySQL-এর মূল নির্মাতাদের একজনের শুরু করা open source শাখা (fork).
client-server · ওয়েব🪶 SQLite
সার্ভার ছাড়া, অ্যাপের ভেতরে চলা ছোট্ট DBMS; পুরো ডেটাবেস একটি ফাইলে। ফোন, ব্রাউজার, ডেস্কটপ অ্যাপে সর্বত্র। Public domain — যে কেউ যেকোনো কাজে ব্যবহার করতে পারেন। এই পাতার লাইভ এডিটরও SQLite.
embedded · public domain🏛️ Oracle Database
বাণিজ্যিক DBMS-এর দীর্ঘদিনের প্রধান নাম — বড় ব্যাংক, টেলিকম আর সরকারি প্রতিষ্ঠানে প্রচলিত। নিজস্ব procedural ভাষা PL/SQL, আর বড় মাপের high availability ব্যবস্থার জন্য পরিচিত। লাইসেন্স ব্যয়বহুল।
বাণিজ্যিক · enterprise🪟 Microsoft SQL Server
Microsoft-এর relational DBMS; Windows আর .NET জগতে স্বাভাবিক সঙ্গী, ২০১৭ সাল থেকে Linux-এও চলে। নিজস্ব SQL উপভাষা T-SQL. শেখা ও ছোট কাজের জন্য বিনা মূল্যের Express ও Developer সংস্করণ আছে।
বাণিজ্যিক · T-SQL🍃 MongoDB
সবচেয়ে পরিচিত document ডেটাবেস — ডেটা থাকে JSON-এর মতো document-এ, একেক document-এর গঠন একেক রকম হতে পারে। দ্রুত বদলানো অ্যাপে জনপ্রিয়। SQL নয়, নিজস্ব query ভাষা (পর্ব ৫৭).
NoSQL · document⚡ Redis
মেমরিতে (RAM) চলা key-value ভাণ্ডার — অসম্ভব দ্রুত। cache, লগইন session, লিডারবোর্ড, queue-তে বহুল ব্যবহৃত। ২০২৪ সালে লাইসেন্স বদলানোর পর Linux Foundation-এর অধীনে Valkey নামে একটি open source শাখা তৈরি হয় (পর্ব ৫৮).
NoSQL · in-memoryসুখবর হলো, relational DBMS-গুলোর মূল SQL প্রায় একই; পার্থক্য খুঁটিনাটিতে। যেমন “সবচেয়ে দামি ৩টি পণ্য” বের করতে SQLite, MySQL আর PostgreSQL-এ কোয়েরির শেষে LIMIT 3 লেখা হয়। কিন্তু SQL Server-এ লিখতে হয় এভাবে (এটি এই পাতায় চালানো যাবে না):
-- SQL Server: LIMIT নেই, TOP আছে
SELECT TOP 3 name, price
FROM products
ORDER BY price DESC;
-- SQL মানকের রূপ (PostgreSQL, Oracle 12c+, SQL Server-এ OFFSET সহ):
-- ... ORDER BY price DESC FETCH FIRST 3 ROWS ONLY;আমাদের নমুনা ডেটায় দুটির ফলই একই — Mobile Phone (15000), Saree (4500) আর Smart Watch (3500). এমন উপভাষার পার্থক্য পুরো একটি পর্বে (পর্ব ৩১) গুছিয়ে দেখবেন; এই কোর্সে যেখানেই পার্থক্য আসবে, আলাদা লেবেল দিয়ে দেখানো হবে।
৯ · সংক্ষিপ্ত ইতিহাস — Codd থেকে NoSQL
আজ যা স্বাভাবিক মনে হয় — “টেবিলে ডেটা রাখা, SQL দিয়ে প্রশ্ন করা” — তা একসময় একটি বৈপ্লবিক ধারণা ছিল। ১৯৬০-এর দশকে ডেটাবেস মানে ছিল IBM-এর IMS-এর মতো hierarchical ব্যবস্থা, বা Charles Bachman-এর IDS আর CODASYL-এর network মডেল। সেখানে প্রোগ্রামারকে জানতে হতো ডেটা কোন রেকর্ড থেকে কোন pointer ধরে কোথায় আছে, আর সেই পথ ধরে হাতে হাতে “হেঁটে” যেতে হতো। ডেটার গঠন বদলালে প্রোগ্রামও নতুন করে লিখতে হতো।
১৯৭০ সালে IBM-এর গবেষক Edgar F. Codd Communications of the ACM সাময়িকীতে প্রকাশ করেন “A Relational Model of Data for Large Shared Data Banks”. তাঁর প্রস্তাব: সব ডেটাকে গাণিতিক relation বা টেবিল হিসেবে দেখা হবে, আর প্রোগ্রাম শুধু বলবে কোন ডেটা চাই — কোথায় আছে বা কীভাবে পৌঁছাবে নয়। এই ধারণার জন্য তিনি ১৯৮১ সালে Turing Award পান।
এরপর কী হলো, নিচের টাইমলাইনে ধাপে ধাপে দেখুন:
- ১৯৭০ — ধারণার জন্ম। Codd-এর প্রবন্ধ। তখন এটি শুধু কাগজে একটি গাণিতিক মডেল; অনেকে সন্দেহ করেছিলেন, টেবিল আর declarative প্রশ্নের এই ব্যবস্থা কখনো pointer-ভিত্তিক ব্যবস্থার মতো দ্রুত হবে কি না।
- ১৯৭০-এর দশক — প্রমাণ। IBM-এর System R প্রকল্পে Donald Chamberlin আর Raymond Boyce তৈরি করেন SEQUEL ভাষা — পরে নাম হয় SQL (এজন্যই অনেকে আজও “সিকুয়েল” বলেন)। Berkeley-তে Michael Stonebraker আর Eugene Wong গড়েন Ingres, যার ভাষা QUEL. দুটিই দেখায় relational DBMS সত্যিই বানানো ও দ্রুত চালানো যায়; System R থেকেই আসে cost-based optimizer-এর ভিত্তি (পর্ব ৪৩)।
- ১৯৭৯–১৯৮৭ — বাজার ও মানক। Larry Ellison-দের ছোট কোম্পানি Relational Software (পরে নাম Oracle) ১৯৭৯ সালে Oracle V2 প্রকাশ করে — সাধারণত একে প্রথম বাণিজ্যিক SQL-ভিত্তিক relational DBMS বলা হয় (“V1” নামে কোনো সংস্করণ বাজারে আসেনি)। ১৯৮৬ সালে ANSI আর ১৯৮৭ সালে ISO SQL-কে মানক ঘোষণা করে। ১৯৮৬ সালেই Stonebraker Ingres-এর উত্তরসূরি Post-Ingres, অর্থাৎ Postgres প্রকল্প শুরু করেন।
- ১৯৯৫–২০০০ — open source আর ছোট্ট DBMS. ১৯৯৫ সালে সুইডেনের MySQL AB প্রকাশ করে MySQL, যা ইন্টারনেটের প্রথম যুগের ওয়েবসাইটগুলোর প্রধান ডেটাবেস হয়ে ওঠে। Postgres-এ SQL যুক্ত হওয়ার পর ১৯৯৬ সালে নাম হয় PostgreSQL. আর ২০০০ সালে D. Richard Hipp প্রকাশ করেন SQLite — সার্ভার ছাড়া, একটি ফাইলে পুরো ডেটাবেস।
- ২০০০-এর দশকের শেষ — NoSQL ঢেউ. Google-এর Bigtable (২০০৬) আর Amazon-এর Dynamo (২০০৭) প্রবন্ধ দেখায়, বিশাল মাপের ওয়েব কোম্পানিগুলো নিজেদের প্রয়োজনে ভিন্ন ধরনের ডেটাবেস বানাচ্ছে। এরপর আসে Cassandra (Facebook-এ তৈরি, ২০০৮ সালে open source), আর ২০০৯ সালে MongoDB ও Redis. ২০০৯ সালেই “NoSQL” শব্দটি এই ঢেউয়ের নাম হয়ে দাঁড়ায়। পরের গল্প ভাবনার প্রশ্ন ৩-এ।
পরীক্ষা ও ইন্টারভিউতে — বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর পরীক্ষায় এ ধরনের প্রশ্ন প্রায়ই আসে:
- ডেটা আর তথ্যের পার্থক্য কী? — ডেটা কাঁচা তথ্যের টুকরো; তথ্য হলো প্রসঙ্গসহ সাজানো ও প্রক্রিয়াজাত ডেটা, যা কোনো প্রশ্নের উত্তর দেয়।
- DBMS কী, আর এর কয়েকটি সুবিধা লিখুন। — ডেটাবেস তৈরি ও পরিচালনার সফটওয়্যার; সুবিধা: redundancy কমানো, integrity, একসাথে অনেক ব্যবহারকারী (concurrency), নিরাপত্তা, backup ও recovery, data independence.
- Database system-এর উপাদানগুলো কী কী? — ডেটা, DBMS সফটওয়্যার, অ্যাপ্লিকেশন প্রোগ্রাম আর ব্যবহারকারী (অনেক বইয়ে হার্ডওয়্যার ও পদ্ধতিও যোগ করা হয়)।
- DBA-র দায়িত্ব কী? — schema ও স্টোরেজ পরিচালনা, user ও অনুমতি দেওয়া, backup ও recovery, পারফরম্যান্স পর্যবেক্ষণ ও টিউনিং, আপগ্রেড।
- SQL-এর পূর্ণরূপ কী, আর relational model কে প্রস্তাব করেন? — Structured Query Language; E. F. Codd, ১৯৭০ সালে।
১০ · AI-এর যুগে DBMS কেন শিখবেন, আর কীভাবে অনুশীলন করবেন
আজ যেকোনো AI-কে বাংলায় বললেই সে SQL লিখে দেয়: “গত মাসে ঢাকার কোন গ্রাহক সবচেয়ে বেশি কিনেছেন?” কয়েক সেকেন্ডে কোয়েরি তৈরি। তাহলে DBMS শেখার দরকার কী? উত্তর তিনটি।
প্রথমত, AI-এর SQL প্রায়ই চলে, কিন্তু ভুল উত্তর দেয়। ভুল JOIN-এ একই অর্ডার দুবার গোনা হয়, NULL বাদ পড়ে, বাতিল অর্ডারও বিক্রিতে ঢুকে যায় — কোনো error ছাড়াই। দ্বিতীয়ত, AI আপনার ডেটাবেস দেখতে পায় না। সে কলামের নাম আন্দাজ করে (customer_name, অথচ আসলে name), আর জানে না কোন টেবিলে কোটি সারি আছে। তৃতীয়ত, AI নিজেই ডেটার ওপর দাঁড়িয়ে। তাকে কাজে লাগাতে দরকার পরিষ্কার, নির্ভরযোগ্য ডেটা আর vector database-এর মতো নতুন ডেটাবেস (পর্ব ৬০)।
ফলটি সঠিক কি না — সেই দায় আপনার।
AI সাধারণত যেসব SQL-ভুল করে
| AI-এর ভুল | যা ঘটে | কীভাবে ধরবেন |
|---|---|---|
| নেই এমন কলাম বা টেবিলের নাম | Error: no such column | AI-কে schema দিন; ফল চালিয়ে দেখুন |
NULL ভুলে যাওয়া (COUNT(phone) বনাম COUNT(*)) | সংখ্যা চুপচাপ কম বা বেশি | NULL আছে এমন সারি দিয়ে পরীক্ষা |
| ভুল JOIN-এ সারি দ্বিগুণ হওয়া | বিক্রির যোগফল ফুলে যায় | JOIN-এর আগে-পরে সারি গুনে তুলনা |
| শর্ত বাদ (যেমন বাতিল অর্ডার) | রিপোর্ট বাস্তবের চেয়ে ভালো দেখায় | প্রশ্নের প্রতিটি শব্দ কোয়েরিতে খুঁজুন |
| transaction ছাড়া টাকা সরানো | crash হলে অর্ধেক কাজ | একাধিক পরিবর্তন হলে BEGIN … COMMIT আছে কি না দেখুন |
| index আর ডেটার মাপ না ভাবা | ছোট ডেটায় দ্রুত, আসল ডেটায় অনেক ধীর | EXPLAIN দিয়ে plan দেখুন (পর্ব ৪১) |
AI-কে SQL লিখতে বলার সময় সবচেয়ে বড় ভুল হলো schema না দেওয়া। টেবিল আর কলামের নাম, NULL থাকতে পারে কি না, আর কী ফল আশা করছেন — এগুলো বলে দিন, আর AI-কে নিজের যাচাইয়ের পথও বলতে বলুন:
AI-এর লেখা SQL হাতে পেলে — যাচাইয়ের চেকলিস্ট
কীভাবে অনুশীলন করবেন
এই কোর্সের প্রতিটি পর্বেই উপরের মতো লাইভ এডিটর থাকবে — কিছু ইনস্টল না করেই, মোবাইল থেকেও SQL চালাতে পারবেন। সবচেয়ে ভালো অভ্যাস: প্রতিটি কোয়েরি চালানোর আগে ফলটি অনুমান করুন — কয়টি সারি আসবে, কোন কোন নাম। তারপর চালিয়ে মেলান। না মিললে সেখানেই আসল শেখা। এরপর কোড বদলান — শর্ত পাল্টান, কলাম যোগ করুন, ইচ্ছা করে ভুল লিখে error-টি পড়ুন।
পর্ব ১২-এ নিজের কম্পিউটারে SQLite আর PostgreSQL (চাইলে MySQL-ও) বসাবেন, আর terminal বা একটি GUI টুল থেকে আসল ডেটাবেসে কাজ করবেন। আপাতত এই পাতাগুলোই আপনার ল্যাবরেটরি।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিয়ে নিজে কিছুক্ষণ ভাবুন — তারপর “→ উত্তর” চাপুন। এগুলোই আপনাকে কোয়েরি-লেখক থেকে ডেটা-চিন্তক বানাবে।
প্র ০১একটি ছোট ব্যবসা Excel-এ দিব্যি চলছে। ঠিক কোন মুহূর্তে তাদের ডেটাবেসে যাওয়া উচিত — আর না গেলে কী ঝুঁকি?
সিদ্ধান্তটি ডেটার আকার দিয়ে নয়, বরং ঝুঁকির ধরন দিয়ে নেওয়া উচিত। কয়েক হাজার সারির একটি ফাইলও ডেটাবেসে যাওয়ার যোগ্য হতে পারে, যদি একসাথে অনেকে লেখেন বা প্রতিটি সংখ্যা টাকার হিসাব হয়।
- একসাথে লেখা: দুই শাখার দুই কর্মী একই পণ্যের শেষ পিস বিক্রি করলেন, দুজনেই নিজের কপিতে স্টক ১ থেকে ০ করলেন। ফাইল মেলানোর সময় দেখা গেল একটি পণ্য দুবার বিক্রি হয়েছে। DBMS-এ দ্বিতীয় বিক্রিটি প্রথমটির শেষ হওয়ার অপেক্ষা করত, আর দেখত স্টক শূন্য।
- নিয়ম না থাকা: spreadsheet-এ দামের ঘরে লেখা ঢুকে যায়, তারিখ তিন রকম ছাঁচে লেখা হয়, একই গ্রাহক তিন বানানে থাকেন। ভুলগুলো জমে, আর বছর শেষে হিসাব মেলে না।
- ফাইল-ফরম্যাটের সীমা: ২০২০ সালের অক্টোবরে ইংল্যান্ডে Public Health England-এর COVID-19 পরীক্ষার ফল জমা করার একটি ধাপে পুরোনো
.xlsফরম্যাট ব্যবহার করা হচ্ছিল, যার এক শিটে সর্বোচ্চ ৬৫,৫৩৬টি সারি ধরে। সীমা ছাড়ানো সারিগুলো চুপচাপ বাদ পড়ে, ফলে প্রায় ১৬ হাজার পজিটিভ ফল কয়েক দিন দৈনিক হিসাবে আসেনি, আর contact tracing দেরিতে শুরু হয়। কোনো error দেখা যায়নি — ডেটা শুধু নিঃশব্দে হারিয়েছিল।
তাহলে নিয়মটি কী? একটি কার্যকর প্রশ্ন: “এই ফাইলের একটি সংখ্যা ভুল হলে কী ক্ষতি, আর কে টের পাবে?” যদি উত্তর হয় “টাকা হারাবে” বা “কেউ টের পাবে না”, তাহলে নিয়ম মানতে বাধ্য করে এমন, transaction-সহ, backup-সহ একটি DBMS দরকার। আর ডেটাবেসে গেলেও Excel ফেলে দিতে হয় না — বিশ্লেষণের জন্য ডেটাবেস থেকে ডেটা নিয়ে Excel-এ চার্ট বানানো খুব প্রচলিত ব্যবস্থা।
মূল উপলব্ধি: spreadsheet হলো হিসাবের খাতা, ডেটাবেস হলো হিসাব রক্ষার ব্যবস্থা। প্রথমটি ব্যক্তির সুবিধার জন্য, দ্বিতীয়টি প্রতিষ্ঠানের নির্ভরযোগ্যতার জন্য।
প্র ০২Codd-এর relational model এত বৈপ্লবিক কেন ছিল? তখনকার ব্যবস্থা তো কাজ করছিল।
১৯৬০-এর দশকের ডেটাবেস — IBM-এর IMS (hierarchical) বা CODASYL-এর network মডেল — সত্যিই কাজ করত; বড় বড় ব্যাংক আর বিমান সংস্থা এগুলোতে চলত। সমস্যা ছিল কে পথ জানে, সেখানে। প্রোগ্রামারকে জানতে হতো ডেটা কোন রেকর্ড থেকে কোন pointer ধরে কোথায় আছে, আর প্রোগ্রামে সেই পথ ধরে এক রেকর্ড থেকে আরেক রেকর্ডে “হাঁটতে” হতো। ১৯৭৩ সালে Turing Award ভাষণে Charles Bachman এই ভূমিকাকে বলেছিলেন “The Programmer as Navigator” — প্রোগ্রামার যেন ডেটার সমুদ্রে জাহাজের নাবিক।
এর দাম ছিল ভারী। ডেটার গঠন বদলালে — যেমন নতুন একটি সম্পর্ক যোগ করলে — যে প্রোগ্রামগুলো পুরোনো পথ ধরে হাঁটত, সেগুলো ভেঙে যেত। আর নতুন ধরনের প্রশ্ন (“এমন সব কর্মী যাঁরা দুটি প্রকল্পে আছেন”) করতে হলে প্রোগ্রামারকে নতুন করে পথ লিখতে হতো।
Codd-এর প্রস্তাব ছিল দুটি আলাদা জিনিসকে আলাদা করা: ডেটা যৌক্তিকভাবে কী (টেবিল, যার সারির কোনো নির্দিষ্ট ক্রম বা pointer নেই) আর ডিস্কে কীভাবে রাখা. প্রোগ্রাম শুধু প্রথমটি দেখবে; দ্বিতীয়টি DBMS-এর ব্যাপার। একে বলে data independence. তিনি একটি গাণিতিক ভিত্তিও দিলেন — set theory আর predicate logic — যাতে প্রশ্নের অর্থ নিখুঁতভাবে সংজ্ঞায়িত হয়, আর DBMS নিজে প্রমাণযোগ্যভাবে সমতুল্য দ্রুততর পথ খুঁজতে পারে।
সমালোচনাও ছিল তীব্র: “এটি কখনো দ্রুত চলবে না।” ১৯৭৪ সালে একটি সম্মেলনে Codd আর Bachman-এর মধ্যে একটি বিখ্যাত বিতর্ক হয়, যা “Great Debate” নামে পরিচিত। শেষ পর্যন্ত System R আর Ingres প্রমাণ করে দেয় যে ভালো optimizer থাকলে relational ব্যবস্থাও যথেষ্ট দ্রুত হতে পারে। মজার ব্যাপার, IBM নিজের সফল IMS ব্যবসা রক্ষায় বাণিজ্যিক relational পণ্য আনতে দেরি করে, আর সেই ফাঁকে Oracle বাজারে আগে পৌঁছে যায়।
মূল উপলব্ধি: সেরা প্রকৌশল-ধারণাগুলো প্রায়ই একটি আড়াল তৈরি করে — “কী” আর “কীভাবে”-কে আলাদা করে। SQL-এর declarative স্বভাব, data independence আর optimizer — তিনটিই সেই এক ধারণার ফল।
প্র ০৩NoSQL আসার পর কি SQL আর relational ডেটাবেসের দিন শেষ? তাহলে এত বছর পরেও সবাই SQL শিখছে কেন?
২০০০-এর দশকের শেষে মনে হচ্ছিল তাই হবে। Google, Amazon, Facebook-এর মতো কোম্পানির ডেটা এত বড় হয়ে গিয়েছিল যে একটি সার্ভারের relational DBMS আর সামলাতে পারছিল না। তারা নিজেরাই বানাল Bigtable, Dynamo, Cassandra — যেগুলো ডেটা শত শত সার্ভারে ভাগ করে রাখে, আর গতি ও সবসময় চালু থাকার জন্য কিছু গ্যারান্টি (যেমন সব জায়গায় সাথে সাথে একই মান) শিথিল করে। “NoSQL” শব্দটি তখন অনেকের কাছে প্রায় একটি আন্দোলনের স্লোগান।
এর আগেই, ২০০৫ সালে, Michael Stonebraker আর Uğur Çetintemel একটি প্রবন্ধে বলেছিলেন “One Size Fits All” — অর্থাৎ এক ধরনের ডেটাবেস সব কাজের জন্য সেরা — এই যুগ শেষ। সেই ভবিষ্যদ্বাণী সত্য হয়েছে, কিন্তু উল্টো দিক থেকেও: relational মরেনি, বরং পাশে নতুন ধরন যোগ হয়েছে।
তারপর যা ঘটল তা আরও মজার। NoSQL ব্যবস্থাগুলো ধীরে ধীরে SQL-এর দিকে ফিরে এল:
- Cassandra-র প্রধান ভাষা হলো CQL — দেখতে প্রায় SQL-এর মতো।
- MongoDB ২০১৮ সালে (সংস্করণ 4.0) একাধিক document জুড়ে ACID transaction যোগ করে — কারণ ব্যবহারকারীরা টাকা-পয়সার কাজে সেটি চাইছিলেন।
- Google নিজেই ২০১২ সালে Spanner নিয়ে প্রবন্ধ প্রকাশ করে — পৃথিবীজুড়ে ছড়ানো একটি ডেটাবেস, যা transaction দেয় এবং পরে SQL ভাষাও যোগ করে। এই ধরনের ব্যবস্থাকে অনেকে “NewSQL” বলেন।
অন্যদিকে relational DBMS-গুলো NoSQL-এর ভালো দিক নিয়ে নিয়েছে — PostgreSQL-এ JSONB দিয়ে document রাখা যায়, প্রায় সব বড় relational DBMS-এ JSON কলাম আছে।
SQL কেন টিকে আছে? কারণ এটি একটি মানক, declarative ভাষা, যা ৫০ বছর ধরে লাখো মানুষ শিখেছেন, অসংখ্য টুল যাকে বোঝে, আর যার পেছনে একটি শক্ত গাণিতিক ভিত্তি আছে। Data analyst থেকে backend developer — প্রায় সব ডেটা-সংক্রান্ত চাকরির বিজ্ঞাপনে SQL একটি সাধারণ চাহিদা।
মূল উপলব্ধি: “কোনটা জিতবে” প্রশ্নটি ভুল। প্রতিটি ডেটাবেস কিছু গ্যারান্টির বিনিময়ে কিছু সুবিধা কেনে। যিনি এই trade-off বোঝেন, তিনি কাজ অনুযায়ী বেছে নেন — প্রায়ই একাধিক।
প্র ০৪DBMS-এর পাঁচটি কাজের মধ্যে কোনটি সবচেয়ে কঠিন? “লোডশেডিংয়ে টাকা হারাবে না” — এই প্রতিশ্রুতি আসলে কীভাবে রাখা হয়?
অনেক ডেটাবেস-গবেষকের মতে সবচেয়ে কঠিন হলো concurrency আর recovery একসাথে — অর্থাৎ হাজারো লেনদেন একই সময়ে চলছে, আর যেকোনো মুহূর্তে বিদ্যুৎ চলে যেতে পারে, তবু হিসাব একটুও ভুল হবে না।
সমস্যাটি কেন কঠিন বুঝতে উপরের উদাহরণটি ভাবুন। রহিমের ব্যালান্স থেকে ১,০০০ টাকা কাটা ডিস্কে লেখা হয়ে গেছে, কিন্তু করিমের ব্যালান্সে যোগ হওয়ার আগেই বিদ্যুৎ চলে গেল। চালু হওয়ার পর ডেটাবেসে ১,০০০ টাকা “হাওয়া”। আবার উল্টোটাও হতে পারে: DBMS “COMMIT হয়েছে” বলে দিল, কিন্তু পরিবর্তনটি তখনো শুধু মেমরিতে ছিল, ডিস্কে পৌঁছায়নি — বিদ্যুৎ গেলে লেনদেনটিই নেই, যদিও অ্যাপ গ্রাহককে “সফল” দেখিয়েছে।
সমাধানের মূলে একটি সরল কিন্তু শক্তিশালী নিয়ম — write-ahead logging: কোনো পরিবর্তন মূল ডেটায় পৌঁছানোর আগে তার বিবরণ (কী ছিল, কী হলো) একটি log ফাইলে লিখে ডিস্কে নিশ্চিত করতে হবে, আর COMMIT-এর রেকর্ড log-এ ডিস্কে পৌঁছানোর পরেই “সফল” বলা যাবে। crash-এর পর DBMS log পড়ে: যে লেনদেনের COMMIT log-এ আছে, তার কাজ আবার করে (redo); যেটির নেই, তার আধা-কাজ মুছে দেয় (undo). ১৯৯০-এর দশকের শুরুতে IBM-এর C. Mohan ও সহকর্মীরা ARIES নামে এই পদ্ধতির একটি পূর্ণাঙ্গ রূপ প্রকাশ করেন, যার ধারণা আজ বহু DBMS-এ দেখা যায় (পর্ব ৪৮)।
Transaction-এর তত্ত্বকে যিনি সবচেয়ে বেশি গুছিয়েছেন, সেই Jim Gray এই কাজের জন্য ১৯৯৮ সালে Turing Award পান। ACID শব্দটি অবশ্য Theo Härder আর Andreas Reuter-এর ১৯৮৩ সালের একটি প্রবন্ধ থেকে জনপ্রিয় হয়।
আর concurrency? দুটি লেনদেন একই সারি পড়ছে-লিখছে — কাকে আগে দেবে, কাকে অপেক্ষা করাবে, দুজনেই একে অপরের জন্য অপেক্ষা করলে (deadlock) কী হবে? এর উত্তর lock, two-phase locking আর MVCC (পর্ব ৪৫–৪৭)। একটি DBMS-এর সবচেয়ে সূক্ষ্ম বাগগুলো সাধারণত এই দুই জগতের মিলনস্থলেই লুকিয়ে থাকে।
মূল উপলব্ধি: আপনার অ্যাপ যখন “পেমেন্ট সফল” দেখায়, তার পেছনে কয়েক দশকের গবেষণা দাঁড়িয়ে আছে। নিজে ফাইলে ডেটা রেখে এই গ্যারান্টি দেওয়া অসম্ভব না হলেও খুবই কঠিন — DBMS ব্যবহারের সবচেয়ে বড় কারণ এটাই।
প্র ০৫SQLite-এ কোনো সার্ভারই নেই, তবু এটি পৃথিবীর সবচেয়ে বেশি ব্যবহৃত DBMS-গুলোর একটি। Embedded আর client-server — কোনটি কখন?
D. Richard Hipp ২০০০ সালে SQLite বানানো শুরু করেন একটি বাস্তব সমস্যা থেকে: তিনি এমন একটি সফটওয়্যারে কাজ করছিলেন যেখানে আলাদা একটি ডেটাবেস সার্ভার চালু রাখা, পরিচালনা করা আর সার্ভার বন্ধ থাকলে কাজ আটকে যাওয়ার ঝামেলা তিনি এড়াতে চাইছিলেন। সমাধান: DBMS-টিকেই একটি library বানিয়ে প্রোগ্রামের ভেতরে ঢুকিয়ে দেওয়া, আর পুরো ডেটাবেস একটি সাধারণ ফাইলে রাখা।
ফল হলো একটি অদ্ভুত সফলতা। Android আর iOS-এ অ্যাপের ডেটা রাখতে, ওয়েব ব্রাউজারের ইতিহাস আর বুকমার্ক রাখতে, বহু ডেস্কটপ অ্যাপে — SQLite প্রায় সর্বত্র। SQLite-এর নিজস্ব ওয়েবসাইট দাবি করে এটি সম্ভবত পৃথিবীর সবচেয়ে বেশি স্থাপিত ডেটাবেস ইঞ্জিন। এটি public domain, অর্থাৎ কোনো লাইসেন্সের শর্তই নেই।
Embedded (SQLite)-এর শক্তি: কোনো সেটআপ নেই, network নেই, ডেটাবেস কপি মানে একটি ফাইল কপি; ছোট আর মাঝারি ডেটায় খুব দ্রুত, কারণ প্রতিটি কোয়েরি network পার না হয়ে সরাসরি function call. সীমা: একই সময়ে লেখার কাজ মূলত একজনই করতে পারে (WAL mode-এ পড়া আর লেখা একসাথে চলে, কিন্তু লেখক তবু একজন); অনেক কম্পিউটার থেকে network দিয়ে একই ডেটাবেসে একসাথে লেখার জন্য এটি বানানো নয়।
Client-server (PostgreSQL, MySQL)-এর শক্তি: শত শত অ্যাপ-সার্ভার থেকে একসাথে হাজারো সংযোগ, প্রতিটি সারি-পর্যায়ে সূক্ষ্ম lock, ব্যবহারকারী অনুযায়ী বিস্তারিত অনুমতি, replication দিয়ে একাধিক কপি। দাম: সার্ভার চালু রাখা, পর্যবেক্ষণ আর পরিচালনার খরচ — একজন DBA-র কাজ।
SQLite-এর নিজের ডকুমেন্টেশন একটি সুন্দর তুলনা দেয়: SQLite client-server ডেটাবেসের প্রতিযোগী নয়, এর প্রতিযোগী হলো fopen() — অর্থাৎ অ্যাপের নিজের বানানো ফাইল-ফরম্যাট। একটি মোবাইল অ্যাপের নিজস্ব ডেটা ফোনে SQLite-এ, আর সব ব্যবহারকারীর ভাগাভাগি ডেটা কোম্পানির সার্ভারে PostgreSQL-এ — বাস্তবে প্রায়ই দুটোই একসাথে থাকে।
মূল উপলব্ধি: “কোন DBMS সেরা” নয়, প্রশ্ন হলো “কতজন, কোথা থেকে, একসাথে লিখবে?” একজন লেখক আর এক যন্ত্র হলে embedded; অনেক লেখক আর network হলে client-server.
অনুশীলন
উপরের যেকোনো লাইভ এডিটরে কোড মুছে নিজের কোয়েরি লিখে চালাতে পারেন — সব এডিটরে পুরো দোকানের ডেটাবেস আছে।
-
কোয়েরি লিখুন: নমুনা দোকানের
productsটেবিলে কলামগুলো হলোproduct_id,name,category_id,price(টাকা) আরstock. যেসব পণ্যের দাম ১,০০০ টাকার কম, তাদের নাম আর দাম দেখানোর কোয়েরি লিখুন। কয়টি সারি আসবে বলে মনে হয়? তারপর চালিয়ে মেলান।SELECT name, price FROM products WHERE price < 1000;ফল ৪টি সারি: DSA Book (650), SQL Book (550), Rice 5kg (420) আর Mustard Oil 1L (260). Headphone-এর দাম 1200, তাই বাদ। “১,০০০ বা তার কম” চাইলে
<=লিখতেন — এই ডেটায় ফল একই। সংখ্যা উদ্ধৃতিচিহ্ন আর কমা ছাড়া লেখা হয়। -
ফল অনুমান করুন:
customersটেবিলে ৮ জন গ্রাহক — ৩ জন Dhaka, ১ জন করে Chattogram, Rajshahi, Khulna ও Sylhet, আর একজনের (Imran Hossain) city NULL. চালানোর আগে হাতে বলুনSELECT name, city FROM customers WHERE city <> 'Dhaka';কয়টি সারি দেবে, কারা আসবেন। (<>মানে “সমান নয়”)অনেকে বলবেন ৫ (৮ − ৩). আসল ফল ৪টি সারি: Karima Begum (Chattogram), Nusrat Jahan (Rajshahi), Tanvir Ahmed (Khulna) আর Farhana Akter (Sylhet). Imran Hossain আসেননি, কারণ “অজানা শহর কি ঢাকা নয়?” এর উত্তরও অজানা — সত্য নয়। WHERE শুধু সত্য সারি রাখে। তাই
city = 'Dhaka'(৩) আরcity <> 'Dhaka'(৪) মিলে ৮ হয় না, ৭ হয়। NULL-ওয়ালা সারি চাইলে আলাদা করেOR city IS NULLলিখতে হয় (পর্ব ১৬)। এডিটরে চালিয়ে নিজে মিলিয়ে নিন। -
ডেটা, তথ্য না জ্ঞান? একটি মোবাইল ওয়ালেটের মাসিক স্টেটমেন্ট থেকে নিচের চারটি জিনিস আলাদা করুন: (ক) “১২ অক্টোবর, ক্যাশ আউট, ২,০০০ টাকা” (খ) “অক্টোবরে মোট ক্যাশ আউট ৯,৫০০ টাকা, ৭ বারে” (গ) “প্রতিটি ক্যাশ আউটে চার্জ লাগে, তাই বারবার ছোট অঙ্কে না তুলে কম বারে তোলা ভালো” (ঘ) স্টেটমেন্টের ওপরে লেখা “তারিখ · ধরন · পরিমাণ · চার্জ”
(ক) ডেটা — একটি একক, কাঁচা লেনদেনের রেকর্ড; একা কোনো প্রশ্নের উত্তর দেয় না।
(খ) তথ্য — অনেকগুলো রেকর্ড যোগ করে পাওয়া একটি প্রশ্নের উত্তর (“এ মাসে কত তুললাম?”)।
(গ) জ্ঞান — তথ্য আর চার্জের নিয়ম মিলিয়ে একটি সিদ্ধান্ত বা নিয়ম। (চার্জ ঠিক কীভাবে হিসাব হয় তা প্রতিষ্ঠানভেদে ভিন্ন, তাই সিদ্ধান্তের আগে নিজের ওয়ালেটের আসল নিয়ম দেখে নিন — জ্ঞান সবসময় তথ্যের মতোই ভালো।)
(ঘ) Metadata — ডেটা সম্পর্কে ডেটা: কোন কলামে কী থাকে। ডেটাবেসে এটিই schema-র অংশ।
-
আপনার দিনের ডেটাবেস: গতকাল ব্যবহার করা তিনটি অ্যাপ বা সেবা বেছে নিন। প্রতিটির জন্য লিখুন — (১) সেখানে অন্তত তিনটি টেবিলের নাম কী হতে পারে, (২) DBMS-এর পাঁচটি কাজের কোনটি সেখানে সবচেয়ে জরুরি, আর কেন।
একটি নমুনা উত্তর (আপনারটি আলাদা হতেই পারে):
- রাইড-শেয়ারিং অ্যাপ:
riders,drivers,trips,payments. সবচেয়ে জরুরি concurrency — একজন চালককে একই সময়ে দুজন যাত্রীর কাছে পাঠানো যাবে না। - বিশ্ববিদ্যালয়ের ফল প্রকাশের পোর্টাল:
students,courses,enrollments,grades. সবচেয়ে জরুরি নিরাপত্তা — শিক্ষার্থী শুধু নিজের ফল দেখবেন, বদলাতে পারবেন শুধু অনুমতিপ্রাপ্ত শিক্ষক। - ফোনের কনট্যাক্ট অ্যাপ:
contacts,phone_numbers,groups. সবচেয়ে জরুরি নির্ভরযোগ্য সংরক্ষণ আর recovery — ফোন হঠাৎ বন্ধ হলেও কনট্যাক্ট যেন নষ্ট না হয়; সাধারণত এটি একটি embedded ডেটাবেসে থাকে।
phone_numbersআলাদা টেবিল, কারণ একজনের একাধিক নম্বর থাকতে পারে — এমন নকশার সিদ্ধান্তই মডিউল ২-এর বিষয়। - রাইড-শেয়ারিং অ্যাপ:
নিজেকে যাচাই করুন
ভুল হলে কারণসহ ব্যাখ্যা পাবেন, আবার চেষ্টাও করতে পারবেন।
ক্রমঘটনাগুলো সময়ের সঠিক ক্রমে সাজান (▲▼ চেপে সরান)
- 📄 Codd-এর relational model প্রবন্ধ প্রকাশ
- 🔬 IBM System R-এ SEQUEL ভাষার জন্ম
- 🏛️ Oracle V2 — বাণিজ্যিক SQL DBMS বাজারে
- 📏 ANSI SQL-কে মানক ঘোষণা করে
- 🐬 MySQL-এর প্রথম প্রকাশ
- 🪶 SQLite-এর প্রকাশ
একটি দোকানের হিসাব থেকে নিচের কোনটি “তথ্য” (information), কাঁচা ডেটা নয়?
- “৩ সেপ্টেম্বর, চাল ৫ কেজি, ৪২০ টাকা”
- “সেপ্টেম্বরে চাল থেকে মোট বিক্রি ১,২৬০ টাকা”
- “৪২০”
- “date, item, qty, amount”
নিচের কোনটি একটি DBMS-এর মূল কাজের মধ্যে পড়ে না?
- একই সময়ে অনেক ব্যবহারকারীর পরিবর্তন সামলানো
- বিদ্যুৎ চলে যাওয়ার পর ডেটা সঠিক অবস্থায় ফিরিয়ে আনা
- কোন ব্যবহারকারী কোন টেবিল দেখতে পারবেন তা নিয়ন্ত্রণ
- অ্যাপের পর্দায় ফলাফল কোন রঙে দেখাবে তা ঠিক করা
customers টেবিলে ৮টি সারি আছে; তার মধ্যে ঠিক একটি সারিতে phone কলামের মান NULL. SELECT COUNT(*), COUNT(phone) FROM customers; চালালে ফল কী?
- 8 আর 8
- 7 আর 7
- 8 আর 7
- Error, কারণ একটি মান NULL
১৯৭০ সালে E. F. Codd-এর প্রবন্ধ “A Relational Model of Data for Large Shared Data Banks”-এর মূল প্রস্তাব কী ছিল?
- ডেটাকে টেবিল (relation) হিসেবে দেখা, আর প্রোগ্রামকে ডেটা কোথায় রাখা আছে তা জানতে না দেওয়া
- প্রতিটি রেকর্ডকে pointer দিয়ে পরের রেকর্ডের সাথে যুক্ত করা
- ডেটা JSON document-এ রাখা, যাতে schema না লাগে
- SQL ভাষার ANSI মানক
তিনটি শাখার কর্মীরা একটি শেয়ার করা spreadsheet-এ একই পণ্যের স্টক কমাচ্ছেন, আর মাঝে মাঝে একটি পণ্য দুবার বিক্রি হয়ে যাচ্ছে। DBMS-এর কোন ক্ষমতা এই সমস্যার সরাসরি সমাধান?
- নিয়মিত backup নেওয়া
- Concurrency control — একসাথে আসা পরিবর্তনকে ক্রমে সাজানো
- ঘরে রং দিয়ে শর্তসাপেক্ষ ফরম্যাট
- ফাইলটিকে কয়েকটি ছোট ফাইলে ভাগ করা
একটি প্রতিষ্ঠানে কে সাধারণত ডেটাবেসের backup, ব্যবহারকারীর অনুমতি আর পারফরম্যান্স টিউনিংয়ের দায়িত্বে থাকেন?
- End user
- Data analyst
- DBA (Database Administrator)
- অ্যাপের গ্রাফিক ডিজাইনার
শব্দকোষ
লেখার মধ্যে ডটেড দাগ দেওয়া শব্দে মাউস রাখুন বা চাপুন — অর্থ দেখাবে। এই পর্বের সব নতুন শব্দ এখানে একসাথে:
মনে রাখুন
- ডেটা কাঁচা টুকরো, তথ্য প্রশ্নের উত্তর, জ্ঞান সিদ্ধান্তের ভিত্তি — আর একজনের তথ্য আরেকজনের ডেটা হতে পারে।
- ডেটাবেস = সুসংগঠিত, ভাগাভাগি করা ডেটা; DBMS = তা পরিচালনার সফটওয়্যার; database system = ডেটা + DBMS + অ্যাপ + ব্যবহারকারী।
- DBMS-এর পাঁচ কাজ: সংরক্ষণ, প্রশ্নের উত্তর, concurrency, নিরাপত্তা, recovery — সাথে নিয়ম রক্ষা (integrity).
- SQL declarative:
SELECT … FROM … WHERE …— আপনি বলেন কী চান;COUNT(*)সারি গোনে,COUNT(col)NULL বাদ দেয়। - Spreadsheet ব্যক্তির হিসাবের জন্য, relational ডেটাবেস প্রতিষ্ঠানের নির্ভরযোগ্যতার জন্য, NoSQL বিশেষ কাজের জন্য; ইতিহাস: Codd ১৯৭০ → System R ও Ingres → Oracle ১৯৭৯ → SQL মানক ১৯৮৬/৮৭ → NoSQL ঢেউ.
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পর্ব ০২ · ফাইল সিস্টেম বনাম DBMS — ইতিহাস আর সমস্যাপরবর্তী পর্বফাইলে ডেটা রাখার সমস্যাগুলো, আর DBMS কেন এলো।
- ডেটাবেস (DBMS) ও SQL · কোর্স হোম৬৭টি পর্ব১০টি মডিউলের পুরো রোডম্যাপ — কোন পর্ব কখন।
- Computer Fundamentals · ডেটাবেসের মৌলিক ধারণাসহজ শুরুICT-র দৃষ্টিতে ডেটাবেস — একেবারে নতুনদের জন্য।
- Python · SQLite দিয়ে ডেটাবেসপাশের ট্র্যাকPython প্রোগ্রাম থেকে SQLite-এ পড়া-লেখা।
- DSA · B-treeগভীরে যানযে ডেটা-স্ট্রাকচার প্রায় প্রতিটি DBMS-এর index-এর ভিত্তি।