ডেটাবেস — টেবিল, key, relation আর normalization

১ · খাতা থেকে ডেটাবেস — DBMS কেন দরকার

পর্ব ০১-এ দেখেছেন, ডেটা হলো কাঁচা তথ্য — “১২”, “সুমি”, “৮৮”. আলাদাভাবে এদের তেমন অর্থ নেই। সাজিয়ে প্রক্রিয়া করলে হয় ইনফরমেশন: “রোল ১২-এর সুমি গণিতে ৮৮ পেয়েছে, A+”. একটি স্কুলে প্রতিদিন এমন হাজার হাজার ডেটা জমে — ভর্তি, বেতন, উপস্থিতি, নম্বর। এগুলো রাখার একটি সুশৃঙ্খল ব্যবস্থা দরকার।

ফাইল-ভিত্তিক পদ্ধতি বনাম DBMS

DBMS আসার আগে প্রতিটি বিভাগ বা প্রতিটি প্রোগ্রাম নিজের আলাদা ফাইলে ডেটা রাখত — আজকের দিনে আলাদা আলাদা Excel ফাইলের মতো। এর সমস্যাগুলোর নাম HSC ICT-তে বারবার আসে:

DBMS-এর সুবিধা তাই সংক্ষেপে: redundancy নিয়ন্ত্রণ, তথ্যের সঙ্গতি, সহজে ভাগাভাগি, নিরাপত্তা, শুদ্ধতা, backup ও recovery, একসাথে বহু ব্যবহারকারী আর দ্রুত খোঁজা। অসুবিধাও আছে: সফটওয়্যার, শক্তিশালী কম্পিউটার আর প্রশিক্ষিত লোকের খরচ; নকশা জটিল; খুব ছোট কাজে (দশ জনের ফোন নম্বর) একটু ভারী; আর মূল সার্ভার নষ্ট হলে সবার কাজ একসাথে থামে — তাই backup জরুরি।

পরিচিত কয়েকটি DBMS

২ · টেবিলের ভাষা — entity, field, record, schema আর data type

Relational ডেটাবেসের প্রতিটি টেবিল একটি entity-র কথা বলে — এমন কোনো জিনিস বা ব্যক্তি, যার তথ্য রাখতে চাই: ছাত্র, বিষয়, শিক্ষক, বই। entity-র প্রতিটি বৈশিষ্ট্য (রোল, নাম, জন্মতারিখ) হলো attribute. নিচের ছোট টেবিলটি দেখুন:

Students টেবিল                         ← table / relation
+------+-------+-------+------------+
| Roll | Name  | Class | BirthDate  |  ← field (column / attribute)
+------+-------+-------+------------+
|  11  | Rahim | Ten   | 2010-03-14 |  ← record (row / tuple)
|  12  | Sumi  | Ten   | 2010-07-02 |
|  13  | Joy   | Ten   | 2009-12-25 |
+------+-------+-------+------------+

ডেটার স্তরগুলো ছোট থেকে বড়: বর্ণ (character) → field → record → table/file → ডেটাবেস. কয়েকটি বর্ণ মিলে “Sumi” — একটি field-এর মান; কয়েকটি field মিলে সুমির record; সব ছাত্রের record মিলে Students টেবিল; Students, Subjects, Results মিলে স্কুলের ডেটাবেস। পরীক্ষায় এই ক্রমটি প্রায়ই জিজ্ঞেস করা হয়।

Data type — প্রতিটি field-এর ধরন

স্প্রেডশিটে একটি সেলে যা খুশি লেখা যায়। ডেটাবেসে প্রতিটি field-এর data type আগে থেকে ঠিক করা থাকে — তাই জন্মতারিখের ঘরে “আগামীকাল” লেখা যায় না। Access আর SQL-এ নামগুলো একটু আলাদা:

৩ · Key — প্রতিটি record-কে আলাদা করে চেনা

একই শ্রেণিতে দুজন “Md. Rahim” থাকতেই পারে। তাহলে “রহিমের নম্বর বদলাও” বললে কোন রহিম? ডেটাবেসে প্রতিটি record-কে নিশ্চিতভাবে আলাদা করে চেনার জন্য একটি বা কয়েকটি field বেছে নেওয়া হয় — এর নাম primary key. ট্রেনের টিকিটের PNR নম্বর বা আপনার NID নম্বর যেমন একজনকেই নির্দেশ করে, ঠিক তেমন।

পাঠ্যবইয়ে আরেকটি নাম আছে — super key: যেকোনো field-সমষ্টি, যা অনন্য, বাড়তি field থাকলেও। যেমন (রেজিস্ট্রেশন নম্বর, নাম) অনন্য, কিন্তু নাম বাড়তি — তাই এটি super key, candidate key নয়। মনে রাখার সহজ পথ: super key-র মধ্য থেকে যারা ন্যূনতম, তারা candidate; candidate-দের মধ্যে একজন primary, বাকিরা alternate.

৪ · Relationship, ER diagram আর টেবিল জোড়া

টেবিলগুলো আলাদা থাকলেও তাদের মধ্যে সম্পর্ক আছে — একজন ছাত্র কয়েকটি বিষয় নেয়, একজন শিক্ষক কয়েকটি বিষয় পড়ান। ডেটাবেসে এই সম্পর্কের নাম relationship, আর এর ধরন তিনটি:

M:N সম্পর্ক সরাসরি দুই টেবিলে রাখা যায় না — ছাত্রের সারিতে “বিষয়১, বিষয়২, বিষয়৩” কলাম বানালে কেউ চারটি বিষয় নিলে কী হবে? সমাধান হলো মাঝের টেবিল: Results(Roll, SubCode, Marks). এতে একটি M:N দুটি 1:N হয়ে যায় — এক ছাত্রের অনেক Results সারি, এক বিষয়ের অনেক Results সারি। আর মাঝের টেবিলটি এমন তথ্যও রাখে, যা কোনো একক পাশের নয় — যেমন নম্বর।

ER diagram — নকশার ছবি

টেবিল বানানোর আগে নকশাটা কাগজে আঁকা হয়। ১৯৭৬ সালে Peter Chen যে পদ্ধতি প্রস্তাব করেন, তাকে বলে ER diagram (Entity-Relationship diagram): আয়তক্ষেত্রে entity, ডিম্বাকৃতিতে attribute (primary key-র নিচে দাগ), হীরা আকৃতিতে relationship, আর রেখার পাশে 1, M, N লিখে সম্পর্কের ধরন। একটি স্কুলের ছোট ডেটাবেস:

ছবি থেকে টেবিল বানানোর নিয়ম সহজ: প্রতিটি entity একটি টেবিল; 1:N সম্পর্কে “1” পাশের primary key “N” পাশের টেবিলে foreign key হয়ে বসে (Subject টেবিলে TeacherID); M:N সম্পর্ক নিজেই একটি টেবিল হয়, যার মধ্যে দুই পাশের key আর সম্পর্কের attribute (Results টেবিলে Roll, SubCode, Marks). আর একটি relational ডেটাবেসের শক্তি এই যে, আলাদা টেবিল থেকে মিলিয়ে প্রশ্নের উত্তর বানানো যায় — একে বলে join. দেখুন:

  Roll  Name
  11    Rahim
  12    Sumi
  13    Joy

  Roll  SubCode  Marks
  11    MAT      75
  11    BAN      81
  12    MAT      88
  12    ICT      92
  12    BAN      79
  13    ICT      67

  SubCode  SubName   TeacherID
  MAT      Math      T2
  ICT      ICT       T2
  BAN      Bangla    T1

  Name  SubName  Marks
  Sumi  Math     88
  Sumi  ICT      92
  Sumi  Bangla   79
  (কোনো তথ্য দুবার লেখা নেই — তবু উত্তর পূর্ণ)

এই একই প্রশ্ন পর্ব ৪২-এ শিখবেন এমন SQL ভাষায় লিখলে দেখতে এমন (এখন শুধু চোখ বুলিয়ে নিন):

SELECT s.Name, sub.SubName, r.Marks
FROM Results r
JOIN Students s   ON r.Roll = s.Roll
JOIN Subjects sub ON r.SubCode = sub.SubCode
WHERE r.Roll = 12;

প্রত্যাশিত আউটপুট: তিনটি সারি — Sumi | Math | 88, Sumi | ICT | 92, Sumi | Bangla | 79. ON r.Roll = s.Roll অংশটিই foreign key ধরে জোড়া দেওয়ার নির্দেশ।

নিজে চালিয়ে দেখুন — একটি ছোট্ট relational ডেটাবেস

DBMS ভেতরে কী পাহারা দেয়? নিচের প্রোগ্রামে দুটি অ্যারে দুটি টেবিল। এটি তিনটি কাজ করে: primary key ভাঙে এমন নতুন record আটকায়, এমন ফল খুঁজে বের করে যার রোল Students-এ নেই (foreign key ভাঙা), আর রোল ১২-এর জন্য join করে। “চালান” চাপুন।

const students = [{ roll: 11, sname: "Rahim" }, { roll: 12, sname: "Sumi" }, { roll: 13, sname: "Joy" }];
const results = [
  { roll: 11, sub: "Math", marks: 75 }, { roll: 12, sub: "Math", marks: 88 },
  { roll: 12, sub: "ICT", marks: 92 },  { roll: 12, sub: "Bangla", marks: 79 },
  { roll: 15, sub: "ICT", marks: 60 }   // roll 15 is not in students!
];
function insertStudent(s) {             // primary key: roll must be unique
  if (students.some(x => x.roll === s.roll)) {
    console.log(`REJECTED: roll ${s.roll} already exists (primary key)`); return;
  }
  students.push(s); console.log(`OK: roll ${s.roll} added`);
}
insertStudent({ roll: 14, sname: "Mitu" });
insertStudent({ roll: 12, sname: "Karim" });
const rolls = new Set(students.map(s => s.roll));
for (const r of results)                 // foreign key: roll must exist in students
  if (!rolls.has(r.roll)) console.log(`FK VIOLATION: result for roll ${r.roll} has no student`);
const who = students.find(s => s.roll === 12);   // join on roll
console.log(`Roll 12 (${who.sname}) took:`);
for (const r of results.filter(x => x.roll === 12)) console.log(`  ${r.sub}: ${r.marks}`);

৫ · Redundancy, anomaly আর normalization

অনেক অফিসে ডেটা শুরু হয় একটি বড় স্প্রেডশিট দিয়ে — সব তথ্য এক টেবিলে। দেখতে সুবিধাজনক, কিন্তু একই তথ্য বারবার লেখা হয়। এই redundancy থেকে তিন ধরনের সমস্যা জন্মায়, যাদের একসাথে বলে anomaly:

• Update anomaly: একটি তথ্য বদলাতে অনেক সারি বদলাতে হয়; একটি বাদ পড়লেই অসঙ্গতি।
• Insertion anomaly: নতুন শিক্ষক যোগ দিয়েছেন, কিন্তু এখনো কোনো ছাত্র তাঁর বিষয় নেয়নি — ছাত্র ছাড়া সারিই বানানো যায় না, তাই শিক্ষকের তথ্য রাখার জায়গা নেই।
• Deletion anomaly: জয় স্কুল ছেড়ে গেল, তার সারিগুলো মোছা হলো — আর ICT বিষয়টি একমাত্র সে-ই নিয়ে থাকলে ICT-র শিক্ষকের তথ্যও হারিয়ে গেল।

Update anomaly চোখের সামনে দেখুন। একটি টেবিলে শিক্ষক কামালের ফোন নম্বর চার সারিতে আছে; নম্বরটি বদলেছে:

111 Rahim MAT Kamal 01800-000002211 Rahim BAN Rina  01700-000001312 Sumi  MAT Kamal 01800-000002412 Sumi  ICT Kamal 01800-000002512 Sumi  BAN Rina  01700-000001613 Joy   ICT Kamal 01800-000002

Normalization — ধাপে ধাপে ভাঙা

Normalization হলো টেবিলকে নিয়ম মেনে ছোট ছোট টেবিলে ভাঙার পদ্ধতি, যাতে প্রতিটি তথ্য এক জায়গায় থাকে আর anomaly দূর হয়। প্রতিটি ধাপকে বলে একটি “normal form”; HSC আর চাকরির পরীক্ষায় প্রথম তিনটি আসে। মূল ভাবনা একটিই — প্রতিটি field নির্ভর করবে key-র ওপর, পুরো key-র ওপর, আর key ছাড়া অন্য কিছুর ওপর নয়। নিচে একটি এলোমেলো শিটকে ধাপে ধাপে বদলান:

Roll Name  Subjects               Teachers (Phone)          Marks
11   Rahim MAT, BAN               Kamal (01800..), Rina (01700..) 75, 81
12   Sumi  MAT, ICT, BAN          Kamal, Kamal, Rina ...     88, 92, 79
13   Joy   ICT                    Kamal (01800..)            67

Roll Name  SubCode SubName TeacherID Teacher TPhone       Marks
11   Rahim MAT     Math    T2        Kamal   01800-000002 75
11   Rahim BAN     Bangla  T1        Rina    01700-000001 81
12   Sumi  MAT     Math    T2        Kamal   01800-000002 88
12   Sumi  ICT     ICT     T2        Kamal   01800-000002 92
12   Sumi  BAN     Bangla  T1        Rina    01700-000001 79
13   Joy   ICT     ICT     T2        Kamal   01800-000002 67
Name বারবার, SubName বারবার, Kamal-এর নম্বর ৪ বার

Students(Roll, Name)
  11 Rahim · 12 Sumi · 13 Joy

Subjects(SubCode, SubName, TeacherID, Teacher, TPhone)
  MAT Math   T2 Kamal 01800-000002
  ICT ICT    T2 Kamal 01800-000002   ← এখনো ২ বার
  BAN Bangla T1 Rina  01700-000001

Results(Roll, SubCode, Marks)   ৬টি সারি

Students(Roll, Name)
Results(Roll, SubCode, Marks)
Subjects(SubCode, SubName, TeacherID)
  MAT Math T2 · ICT ICT T2 · BAN Bangla T1
Teachers(TeacherID, Teacher, TPhone)
  T1 Rina  01700-000001
  T2 Kamal 01800-000002   ← একবারই

Results ⋈ Students ⋈ Subjects ⋈ Teachers
  = ঠিক 1NF-এর ৬টি সারি, একটিও কম-বেশি নয়

নতুন শিক্ষক T3?   → Teachers-এ এক সারি   (insertion ✔)
জয় চলে গেল?      → Students + Results থেকে মোছা,
                   Kamal-এর তথ্য অক্ষত    (deletion ✔)
নম্বর বদল?        → এক সারি              (update ✔)

৬ · Sorting, indexing আর query-form-report

Sorting মানে record-গুলোকে কোনো field অনুযায়ী ক্রমে সাজিয়ে দেখানো — নাম বর্ণানুক্রমে, নম্বর বড় থেকে ছোট (ascending/descending). কিন্তু একটি বড় টেবিলে বারবার সাজানো ব্যয়বহুল, আর টেবিলকে একসাথে দুই ক্রমে (রোল আর নাম) সাজিয়ে রাখা যায় না। এর সমাধান index — বইয়ের শেষের নির্ঘণ্টের মতো: মূল পাতাগুলো যেমন আছে তেমনই থাকে, আলাদা একটি সাজানো তালিকা বলে দেয় কোন শব্দ কোন পাতায়।

  #  Roll  Name
  1  17    Nila
  2  05    Tanvir
  3  21    Mim
  4  09    Arif
  5  12    Sumi
  6  30    Rafi
  7  02    Lima
  8  14    Sakib

  17? না → 05? না → 21? না → 09? না → 12? হ্যাঁ
  ৫টি তুলনা। রোল 14 হলে ৮টি।
  না থাকলে (রোল 40)? সব ৮টি পড়ে তবে বোঝা যায়।

  ১০ লাখ সারি → সবচেয়ে খারাপ ক্ষেত্রে ১০ লাখ তুলনা

  Roll → #
  02 → 7    05 → 2    09 → 4    12 → 5
  14 → 8    17 → 1    21 → 3    30 → 6
  মূল টেবিল অপরিবর্তিত; index আলাদা জায়গায়

  মাঝখানে 14 → 12 ছোট, বাঁয়ের অর্ধেক: 02 05 09 12
  মাঝখানে 09 → 12 বড়, বাকি শুধু: 12
  12 = 12 → সারি 5, Sumi
  ৩টি তুলনা; ১০ লাখ সারিতেও মাত্র ২০টির মতো

  + খোঁজা, সাজানো আর join অনেক দ্রুত
  − বাড়তি জায়গা লাগে
  − প্রতিটি INSERT/UPDATE-এ index-ও বদলাতে হয়
  → যে field দিয়ে প্রায়ই খোঁজা হয়, শুধু সেগুলোতে index
  primary key-তে DBMS নিজেই index বানায়

Query, Form আর Report — Access-এর চার স্তম্ভ

MS Access খুললে বাঁ দিকে কয়েক ধরনের object দেখবেন। HSC ICT-তে এদের কাজ জিজ্ঞেস করা হয়:

ওয়েবসাইটেও একই ভাগ: পর্ব ৩৭-এর HTML form হলো Form-এর কাজ, সার্ভারের কোড পাঠায় query, আর ফল দেখানো পাতাটি Report. Access-এ Create → Query Design দিয়ে মাউসে query বানানো যায়; ভেতরে Access আসলে SQL-ই লেখে — View → SQL View দিলে দেখা যায়।

৭ · Data integrity, validation আর ডেটাবেসের নিরাপত্তা

Data integrity মানে ডেটা সঠিক, সম্পূর্ণ আর সঙ্গতিপূর্ণ থাকা। পর্ব ১১-এর data validation স্প্রেডশিটে “পাহারাদার” ছিল — কপি-পেস্টে এড়ানো যেত। ডেটাবেসে নিয়মগুলো DBMS নিজে প্রয়োগ করে, কোনো পথেই এড়ানো যায় না। তিন ধরনের integrity:

• Entity integrity: primary key কখনো ফাঁকা বা দ্বৈত নয়।
• Referential integrity: foreign key-র প্রতিটি মান অন্য টেবিলে সত্যিই আছে — রোল ১৫-র মতো “অনাথ” ফল ঢুকতে পারে না, আর যে ছাত্রের ফল আছে তাকে সরাসরি মোছা যায় না। Access-এ Database Tools → Relationships → দুই টেবিল জুড়ে Enforce Referential Integrity-তে টিক।
• Domain integrity: প্রতিটি field-এ শুধু বৈধ মান — সঠিক data type, আর validation rule. Access-এ field-এর Properties → Validation Rule: Between 0 And 100, আর Validation Text: “নম্বর ০ থেকে ১০০-এর মধ্যে হবে”.

নিরাপত্তার স্তর

বাস্তব আক্রমণের একটি পরিচিত ধরনের নাম জেনে রাখুন — SQL injection. দুর্বলভাবে লেখা ওয়েবসাইট যদি ব্যবহারকারীর লেখা ইনপুটকে সরাসরি query-র লেখার সাথে জুড়ে দেয়, তাহলে চতুর ইনপুট query-র মানেই বদলে দিতে পারে, আর অন্যের ডেটা বেরিয়ে যেতে পারে। প্রতিরোধ সহজ ও প্রমাণিত: ইনপুট কখনো query-র লেখায় জোড়া নয়, সবসময় parameterized query (আলাদা ঘরে মান পাঠানো), সাথে ইনপুট যাচাই আর ন্যূনতম অনুমতি। পর্ব ৪২-এ SQL শেখার সময় এর নিরাপদ রূপটি দেখবেন; সাইবার নিরাপত্তার বড় ছবি পর্ব ৪৩-এ।

৮ · বাংলাদেশের বড় ডেটাবেস, গোপনীয়তা আর NoSQL

আপনি প্রতিদিন না জেনেই বহু ডেটাবেস ব্যবহার করেন:

• NID ডেটাবেস: নির্বাচন কমিশনের কাছে কোটি কোটি নাগরিকের নাম, ঠিকানা, ছবি, আঙুলের ছাপ। ব্যাংক, মোবাইল অপারেটর আর বিভিন্ন সংস্থা অনুমতি নিয়ে এখান থেকে পরিচয় যাচাই করে — SIM কেনার সময় আঙুলের ছাপ মেলানো এর উদাহরণ।
• শিক্ষা বোর্ডের ফল: ফল প্রকাশের দিন লাখ লাখ শিক্ষার্থী একসাথে রোল আর রেজিস্ট্রেশন নম্বর দিয়ে খোঁজে — index ছাড়া এটি অসম্ভব হতো।
• BRTA: গাড়ির নিবন্ধন আর ড্রাইভিং লাইসেন্সের রেকর্ড — গাড়ির নম্বর দিয়ে মালিক, লাইসেন্স নম্বর দিয়ে চালক।
• ব্যাংক আর MFS: প্রতিটি লেনদেন একটি record; টাকা এক হিসাব থেকে কাটা আর অন্যটিতে যোগ — দুটি কাজ হয় একসাথে, নয়তো একটিও নয়। এই “সব বা কিছুই না” নিশ্চয়তার নাম transaction.

যত বড় ডেটাবেস, তত বড় দায়িত্ব। কোটি মানুষের ব্যক্তিগত তথ্য এক জায়গায় থাকলে একটি দুর্বলতাই কোটি মানুষকে ঝুঁকিতে ফেলে — প্রতারণা, ভুয়া SIM, ভুয়া ঋণ। তাই নকশার শুরুতেই প্রশ্ন: এই তথ্য কি আসলেই দরকার? একে বলে data minimization — যে তথ্য রাখেননি, তা কখনো ফাঁস হতে পারে না। ব্যক্তিগত তথ্য, গোপনীয়তা আর এ-সংক্রান্ত আইনের আলোচনা পর্ব ৪৫-এ।

NoSQL — এক লাইনে

সব ডেটা টেবিলে সুন্দর বসে না — সোশ্যাল মিডিয়ার পোস্ট, সেন্সরের অবিরাম মাপজোখ, অ্যাপের ক্যাশ। এদের জন্য NoSQL ডেটাবেস (MongoDB, Redis, Cassandra ইত্যাদি) ডেটা রাখে document, key-value বা অন্য কাঠামোয়, কঠোর schema ছাড়া, বহু সার্ভারে ছড়িয়ে — তবে বেশিরভাগ ব্যবসার মূল হিসাব আজও relational ডেটাবেসেই থাকে।

৯ · AI-এর যুগে — schema বানায় AI, যাচাই করেন আপনি

ChatGPT, Gemini বা Claude-এর মতো চ্যাটবটকে “একটি কোচিং সেন্টারের ডেটাবেসের টেবিল বানিয়ে দাও” বললে কয়েক সেকেন্ডে টেবিল, field, data type আর SQL লিখে দেয়। শুরু হিসেবে চমৎকার। কিন্তু AI-এর নকশায় যে ভুলগুলো প্রায়ই থাকে, তা কোনো ত্রুটি-বার্তা দেয় না — মাস কয়েক পরে anomaly হয়ে দেখা দেয়: মোবাইল নম্বর Number হিসেবে, M:N সম্পর্কে কমা দিয়ে লেখা তালিকা, নামকে primary key, foreign key ঘোষণাই নেই, আর “পরে কাজে লাগতে পারে” ভেবে NID, জন্মতারিখ, বাবা-মায়ের পেশা — সব রাখা।

AI-এর নকশা ব্যবহারের আগে — চেকলিস্ট

• প্রতিটি টেবিলে একটি primary key আছে, যা অনন্য, ফাঁকা নয় আর সময়ের সাথে বদলায় না (নাম বা মোবাইল নম্বর নয়)
• প্রতিটি সম্পর্কে foreign key সত্যিই ঘোষণা করা আছে; M:N সম্পর্ক মাঝের টেবিলে ভাঙা — কোনো ঘরে কমা দিয়ে তালিকা নেই
• নিজে পরীক্ষা করেছি: একটি তথ্য (যেমন শিক্ষকের ফোন) বদলাতে কয়টি সারি বদলাতে হয় — একটির বেশি হলে redundancy আছে
• data type যাচাই করেছি — ফোন, রোল, NID-এর মতো “হিসাব হয় না এমন সংখ্যা” Text; টাকা Currency বা DECIMAL; তারিখ Date
• অপ্রয়োজনীয় ব্যক্তিগত তথ্য বাদ দিয়েছি; আসল ছাত্রদের ডেটা AI টুলে দিইনি — নকশার জন্য বানানো উদাহরণ যথেষ্ট