EER — specialization, generalization আর aggregation

১ · সাধারণ ER কোথায় আটকে যায়

পর্ব ৭-এ আপনি ER model দিয়ে বাস্তব জগৎ আঁকতে শিখেছেন: entity (জিনিস), attribute (গুণ) আর relationship (সম্পর্ক)। পর্ব ৮-এ যোগ হয়েছে cardinality, participation আর weak entity. এগুলো দিয়ে অনেক কিছু আঁকা যায়। কিন্তু একটি খুব সাধারণ পরিস্থিতিতে সাধারণ ER অস্বস্তিতে পড়ে: যখন কয়েক ধরনের জিনিস অনেকটা এক, কিন্তু পুরোপুরি এক নয়।

একটি বিশ্ববিদ্যালয়ের মানুষগুলোর কথা ভাবুন। শিক্ষার্থী, শিক্ষক, অফিসের কর্মচারী — সবার নাম, ফোন নম্বর, ঠিকানা, জন্মতারিখ আছে। সবাই লাইব্রেরি থেকে বই নেন, সবার একটি আইডি কার্ড আছে। কিন্তু শিক্ষার্থীর আছে batch আর CGPA, শিক্ষকের আছে পদবি আর বেতন, কর্মচারীর আছে শাখা আর শিফট। ব্যাংকেও একই ছবি: সঞ্চয়ী (savings) আর চলতি (current) — দুটিই হিসাব, দুটিরই হিসাব নম্বর, শাখা, ব্যালান্স, খোলার তারিখ আছে। কিন্তু সঞ্চয়ী হিসাবে সুদের হার থাকে, আর চলতি হিসাবে ওভারড্রাফটের সীমা।

সাধারণ ER-এ এই পরিস্থিতি আঁকার দুটি রাস্তা আছে, আর দুটিই খারাপ:

• একটি বড় PERSON entity, সব attribute সহ। তখন একজন শিক্ষকের batch আর CGPA-র ঘর চিরকাল খালি, শিক্ষার্থীর বেতনের ঘরও। আরও খারাপ, “শুধু শিক্ষকেরাই কোর্স পড়ান” — এই নিয়মটি ডায়াগ্রাম আর বলতে পারে না, কারণ TEACHES relationship-টি সব PERSON-এর সাথে জোড়া।
• STUDENT, TEACHER, STAFF — তিনটি আলাদা entity. তখন সাধারণ attribute তিনবার আঁকা, আর “যেকোনো মানুষ বই ধার নেন” relationship-টিও তিনবার: STUDENT–BORROWS, TEACHER–BORROWS, STAFF–BORROWS. আর তিনজনই যে আসলে “মানুষ”, সেই সত্যটি ডায়াগ্রামে কোথাও নেই।

এই সমস্যার সমাধান হিসেবে ১৯৭০-এর দশকের শেষ থেকে ER-কে বাড়ানো হয়, যাকে আজ বলা হয় EER (Enhanced বা Extended ER) model. এতে তিনটি নতুন ধারণা আসে: superclass/subclass (সাথে specialization ও generalization), category, আর aggregation. প্রথমে দেখুন, সমস্যাটি ডেটাতেই কেমন দেখায়। নিচের এডিটর চলে বিশ্ববিদ্যালয়ের নমুনা ডেটাবেসে (db-uni). এতে আছে departments (dept_id, name, building), instructors (instructor_id, name, dept_id, salary, mentor_id), students (student_id, name, dept_id, batch, cgpa), courses আর enrollments. খেয়াল করুন, students আর instructors দুটি আলাদা টেবিল, অথচ দুটিতেই name আর dept_id আছে।

-- CSE বিভাগের (dept_id = 1) সব মানুষ: দুই টেবিল জুড়ে খুঁজতে হয়
SELECT 'student' AS role, name, dept_id FROM students WHERE dept_id = 1
UNION ALL
SELECT 'instructor', name, dept_id FROM instructors WHERE dept_id = 1;

২ · Superclass, subclass আর IS-A — attribute-এর উত্তরাধিকার

EER-এর মূল কথা একটি বাক্যে: কিছু entity type আরেকটি entity type-এর উপসেট। প্রতিটি STUDENT একজন PERSON; প্রতিটি TEACHER-ও একজন PERSON. এখানে PERSON হলো superclass (বড়, সাধারণ ধরন), আর STUDENT ও TEACHER হলো তার subclass (ছোট, বিশেষ ধরন)। দুজনের সম্পর্ককে বলে IS-A সম্পর্ক: “STUDENT IS-A PERSON” — একজন শিক্ষার্থী একজন মানুষ।

এই “একই জিনিস” থেকেই আসে EER-এর সবচেয়ে কাজের বৈশিষ্ট্য — attribute inheritance. Subclass-এর প্রতিটি entity superclass-এর সব attribute পায়, আর superclass যে সব relationship-এ অংশ নেয়, সেগুলোতেও অংশ নেয়। STUDENT-এর নিজের attribute মাত্র দুটি (batch, cgpa), কিন্তু প্রতিটি শিক্ষার্থীর person_id, name, phone-ও আছে, কারণ তিনি একজন PERSON. আর PERSON যেহেতু লাইব্রেরি থেকে বই ধার নেন (BORROWS), প্রতিটি STUDENT আর TEACHER-ও নেন — সম্পর্কটি একবারই আঁকা হয়।

Specific relationship-এর উদাহরণটি আলাদা করে খেয়াল করুন। TEACHES (শিক্ষক কোর্স পড়ান) শুধু TEACHER-এর সাথে জোড়া, PERSON-এর সাথে নয়। এভাবে নকশা নিজেই বলে দেয় যে শিক্ষার্থী কোর্স পড়াতে পারেন না। এটিই প্রথম পথের (“সব attribute সহ একটি বড় PERSON”) সমস্যার সমাধান। আর BORROWS একবার PERSON-এ আঁকা — এটি দ্বিতীয় পথের (“তিনটি আলাদা entity”) সমস্যার সমাধান। EER দুই পথের ভালো দিক নেয়, খারাপ দিক ফেলে দেয়।

৩ · Specialization আর generalization — উপর থেকে ভাগ, নিচ থেকে মিল

একটি superclass–subclass hierarchy-তে দুই দিক থেকে পৌঁছানো যায়। দুটি পথের ফল একই ছবি, কিন্তু চিন্তার দিক উল্টো।

• Specialization (top-down, উপর থেকে নিচে): একটি entity type দিয়ে শুরু করে তার ভেতরে বিশেষ উপদল খোঁজা। “PERSON-দের মধ্যে কারা কারা আলাদা বৈশিষ্ট্য রাখেন? শিক্ষার্থী আর শিক্ষক।” তারপর তাদের নিজস্ব attribute নিচে নামিয়ে দেওয়া।
• Generalization (bottom-up, নিচ থেকে উপরে): কয়েকটি আলাদা entity type দিয়ে শুরু করে তাদের মিল খোঁজা। “SAVINGS আর CURRENT দুটিরই হিসাব নম্বর, শাখা, ব্যালান্স আছে — তাহলে এরা দুজনেই ACCOUNT.” তারপর সাধারণ অংশ উপরে তুলে নতুন superclass বানানো।

প্রথমে specialization. নিচের ডায়াগ্রামে একটি PERSON entity থেকে ধাপে ধাপে hierarchy তৈরি হচ্ছে:

এবার উল্টো দিক — generalization. ধরুন একটি ব্যাংকের পুরোনো সিস্টেমে সঞ্চয়ী আর চলতি হিসাব দুটি আলাদা entity হিসেবে আঁকা, আর দুটিই CUSTOMER-এর সাথে HOLDS relationship-এ জোড়া। নিচে দেখুন কীভাবে মিল খুঁজে একটি superclass তৈরি হয়:

Specialization আর generalization-এর ফল একই ছবি, তাই অনেক বইয়ে দুটিকে একসাথে বলা হয় “specialization/generalization hierarchy”. পার্থক্য প্রক্রিয়ায়: নতুন নকশায় সাধারণত উপর থেকে ভাবা সহজ (specialization), আর কয়েকটি পুরোনো সিস্টেম বা বিভাগের খাতা মিলিয়ে একটি ডেটাবেস বানাতে গেলে নিচ থেকে (generalization). কিছু লেখক generalization-এর ক্ষেত্রে ধরে নেন যে সব entity কোনো না কোনো subclass-এ ছিল, তাই generalization সাধারণত total হয় — কারণ superclass-টি তো subclass-গুলো মিলিয়েই বানানো।

Hierarchy কত গভীর হতে পারে

একটি subclass নিজেও আবার specialize হতে পারে। STUDENT থেকে UNDERGRADUATE আর POSTGRADUATE; POSTGRADUATE থেকে MASTERS আর PHD. তখন একজন PHD শিক্ষার্থী উত্তরাধিকারে পান POSTGRADUATE-এর (thesis_title), STUDENT-এর (batch, cgpa) আর PERSON-এর (person_id, name, phone) সব attribute. যখন প্রতিটি subclass-এর ঠিক একটি superclass, তখন কাঠামোটি একটি গাছ — একে বলে specialization hierarchy. একটি subclass-এর একাধিক superclass থাকলে কী হয়, তা অংশ ৪-এর শেষে।

৪ · Constraint — disjoint না overlapping, total না partial

Hierarchy আঁকা হলো। এবার দুটি প্রশ্নের উত্তর না দিলে নকশা অসম্পূর্ণ, কারণ ডেটাবেস কোন ডেটা মেনে নেবে আর কোনটি ফিরিয়ে দেবে, তা এই দুটি উত্তরই ঠিক করে।

দুটি প্রশ্ন একে অপরের থেকে স্বাধীন, তাই চারটি সমন্বয় সম্ভব। পর্ব ৮-এর participation constraint-এর সাথে total/partial-এর মিল লক্ষ করুন: সেখানে প্রশ্ন ছিল “প্রতিটি entity কি relationship-এ থাকতেই হবে?”, এখানে “প্রতিটি superclass entity কি কোনো subclass-এ থাকতেই হবে?” — চিহ্নও একই, দুই দাগ। নিচের ডায়াগ্রামে চারজন মানুষের সদস্যপদ দেখে দুটি প্রশ্নের উত্তর বের করুন:

EER ডায়াগ্রামের চিহ্ন

পাঠ্যবই আর পরীক্ষায় সবচেয়ে প্রচলিত চিহ্নগুলো Elmasri–Navathe ধরনের। Superclass থেকে একটি দাগ একটি ছোট বৃত্তে যায়; বৃত্তের ভেতরে d বা o; বৃত্ত থেকে প্রতিটি subclass-এ একটি করে দাগ, যার মাঝে একটি ছোট ⊂ (subset) চিহ্ন — খোলা দিক superclass-এর দিকে, অর্থাৎ “এই subclass ওই superclass-এর উপসেট”। Superclass-বৃত্তের দাগ দুটি হলে total, একটি হলে partial. Attribute-defined হলে দাগের পাশে defining attribute-এর নাম।

Attribute-defined বনাম user-defined

একটি entity কোন subclass-এ যাবে, তা কে ঠিক করে? দুটি উপায়:

• Attribute-defined (বা predicate-defined): superclass-এর একটি attribute-এর মান দেখে সদস্যপদ ঠিক হয় — acc_type = 'savings' হলে SAVINGS, 'current' হলে CURRENT. একে বলে defining attribute; SQL-এ এটিই type বা discriminator কলাম হয়ে যায়। সুবিধা: DBMS নিজেই নিয়ম রক্ষা করতে পারে, কেউ ভুল subclass-এ ঢুকবে না।
• User-defined: এমন কোনো attribute নেই; ব্যবহারকারী (বা অ্যাপ) প্রতিটি entity-কে হাতে হাতে subclass-এ রাখেন। “কে কোন কোর্সের TA হবেন” বিভাগীয় প্রধানের সিদ্ধান্ত, কোনো attribute-এর ফল নয়।

এই constraint-গুলো থেকে ডেটা বদলানোর কয়েকটি নিয়ম আপনাআপনি আসে: superclass থেকে একটি entity মুছলে সব subclass থেকেও মুছতে হয় (মানুষটিই না থাকলে শিক্ষার্থীও নেই)। Attribute-defined specialization-এ superclass-এ একটি entity ঢুকলে defining attribute-এর মান অনুযায়ী সে নিজে থেকেই সঠিক subclass-এর সদস্য। আর total specialization-এ superclass-এ ঢোকানো entity-কে অন্তত একটি subclass-এ ঢোকাতেই হবে — যা SQL-এ রক্ষা করা সবচেয়ে কঠিন, অংশ ৭-এ দেখবেন।

Shared subclass আর lattice — একাধিক superclass

এ পর্যন্ত প্রতিটি subclass-এর ঠিক একটি superclass. কিন্তু ধরুন বিশ্ববিদ্যালয়ের নকশায় PERSON-এর দুটি subclass: STUDENT আর EMPLOYEE (বেতনভোগী সবাই)। Teaching assistant একজন শিক্ষার্থী এবং একজন বেতনভোগী কর্মী — দুটিই একসাথে। তখন TEACHING_ASSISTANT-কে STUDENT আর EMPLOYEE দুটিরই subclass বানানো যায়। একে বলে shared subclass, আর কাঠামোটি আর গাছ থাকে না, হয়ে যায় একটি specialization lattice.

Shared subclass পায় multiple inheritance: STUDENT-এর batch, cgpa আর EMPLOYEE-এর salary — দুটিই। PERSON-এর attribute দুই পথে আসছে মনে হলেও আসে একবারই, কারণ দুই পথের মাথায় একই PERSON entity, একই মানুষ। প্রোগ্রামিং ভাষায় এই সমস্যার নাম “diamond problem”; EER-এ সমস্যা হয় না, কারণ entity একটিই, শুধু ভূমিকা একাধিক। আর মনে রাখুন শর্তটি: shared subclass-এর প্রতিটি সদস্য সব superclass-এর সদস্য — TA হতে হলে শিক্ষার্থী আর কর্মী দুটোই হতে হবে। অর্থাৎ shared subclass ⊆ STUDENT ∩ EMPLOYEE. পরের অংশের category-তে শর্তটি ঠিক উল্টো।

৫ · Category (union type) আর aggregation

Category — “এদের যেকোনো একজন”

বিআরটিএ-তে একটি গাড়ির রেজিস্ট্রেশনের কথা ভাবুন। গাড়ির মালিক হতে পারেন একজন ব্যক্তি (NID আছে), অথবা একটি কোম্পানি (ট্রেড লাইসেন্স আছে) — যেমন একটি বাস কোম্পানি। “মালিক” তাই একটি ভূমিকা, যা দুই সম্পূর্ণ আলাদা ধরনের entity নিতে পারে। PERSON আর COMPANY-কে কোনো সাধারণ superclass-এ তোলা অর্থহীন — তাদের key আলাদা, attribute আলাদা, জগৎ আলাদা। তবু OWNS relationship-এ আমরা বলতে চাই “একটি গাড়ির একজন OWNER”.

এর জন্য EER-এর হাতিয়ার category বা union type: একটি subclass, যার superclass একাধিক, আর যার প্রতিটি সদস্য সেই superclass-গুলোর অন্তত একটির সদস্য। OWNER ⊆ PERSON ∪ COMPANY. ডায়াগ্রামে superclass-গুলো থেকে দাগ একটি বৃত্তে যায়, বৃত্তে লেখা থাকে ∪ (union), আর বৃত্ত থেকে একটি দাগ category-তে।

শেষ সারির কথাটি টেবিলে আনার সময় গুরুত্বপূর্ণ: PERSON-এর key NID, COMPANY-র key ট্রেড লাইসেন্স নম্বর — VEHICLE-এর foreign key কোনটির দিকে আঙুল তুলবে? প্রচলিত সমাধান হলো OWNER-এর জন্য একটি নতুন surrogate key (owner_id), আর PERSON ও COMPANY দুটি টেবিলেই সেই owner_id foreign key হিসেবে রাখা। নিচের এডিটরে ঠিক এই নকশা: owner (owner_id, otype — 'P' ব্যক্তি, 'C' কোম্পানি), person_owner (owner_id, nid, name), company_owner (owner_id, trade_license, company_name) আর vehicle (reg_no, model, owner_id).

-- প্রতিটি গাড়ির মালিকের নাম: ব্যক্তি হলে name, কোম্পানি হলে company_name
SELECT v.reg_no, v.model, o.otype,
       COALESCE(p.name, c.company_name) AS owner_name
FROM vehicle v
JOIN owner o ON o.owner_id = v.owner_id
LEFT JOIN person_owner  p ON p.owner_id = o.owner_id
LEFT JOIN company_owner c ON c.owner_id = o.owner_id;

Aggregation — relationship-এর সাথে relationship

একটি সফটওয়্যার কোম্পানিতে কর্মীরা প্রজেক্টে কাজ করেন: EMPLOYEE —WORKS_ON— PROJECT, যেখানে WORKS_ON-এর নিজের attribute hours (সপ্তাহে কত ঘণ্টা)। এবার নতুন নিয়ম: প্রতিটি নিয়োগ — “রাকিব P1 প্রজেক্টে” — একজন ম্যানেজার তদারকি (monitor) করেন। তদারকিটি রাকিবের নয় (তিনি অন্য প্রজেক্টে অন্য ম্যানেজারের অধীনে থাকতে পারেন), P1-এরও নয় (P1-এর অন্য কর্মীদের অন্য ম্যানেজার থাকতে পারেন)। তদারকিটি রাকিব–P1 জোড়ার। সাধারণ ER-এ relationship শুধু entity-দের মধ্যে হয়; একটি relationship (WORKS_ON) আরেকটি relationship-এ (MONITORS) অংশ নিতে পারে না।

Aggregation এর সমাধান: WORKS_ON relationship-টিকে তার দুই entity সহ একটি বাক্সে ঘিরে একটি উচ্চতর স্তরের entity হিসেবে ধরা। তারপর সেই বাক্সটি MANAGER-এর সাথে MONITORS relationship-এ অংশ নেয়।

কেন একটি ternary (তিন-পক্ষের) relationship MONITORS(EMPLOYEE, PROJECT, MANAGER) যথেষ্ট নয়? কারণ তাতে দুটি জিনিস হারায়। প্রথমত, এমন সারি ঢোকানো যাবে যেখানে কর্মী ওই প্রজেক্টে কাজই করেন না — তদারকি হবে এমন নিয়োগের, যার অস্তিত্ব নেই। দ্বিতীয়ত, WORKS_ON আর MONITORS-এর তথ্য একসাথে জড়িয়ে যায়: hours কোথায় থাকবে? Aggregation বলে, তদারকির শর্ত হলো নিয়োগটি আগে থাকা। টেবিলে এর মানে: monitors-এর foreign key একটি composite key, যা works_on-এর (emp_id, proj_id)-এর দিকে আঙুল তোলে। এই এডিটরে employee (emp_id, name), project (proj_id, title), works_on (emp_id, proj_id, hours) আর monitors (manager_id, emp_id, proj_id, since):

-- Mitu (3) P2-তে কাজ করেন: এই নিয়োগের তদারকি যোগ করা যায়
INSERT INTO monitors VALUES (1, 3, 'P2', '2025-10-01');

SELECT e.name, w.proj_id, w.hours, m.manager_id
FROM works_on w JOIN employee e ON e.emp_id = w.emp_id
LEFT JOIN monitors m ON m.emp_id = w.emp_id AND m.proj_id = w.proj_id;

-- Rakib (2) P2-তে কাজই করেন না: অস্তিত্বহীন নিয়োগের তদারকি
INSERT INTO monitors VALUES (1, 2, 'P2', '2025-10-05');

৬ · EER থেকে টেবিল — inheritance আনার তিন কৌশল

Relational টেবিলে “subclass” বলে কিছু নেই — আছে শুধু টেবিল, কলাম, key আর constraint. তাই একটি superclass–subclass hierarchy-কে টেবিলে আনতে একটি সিদ্ধান্ত নিতে হয়। তিনটি প্রধান কৌশল আছে; Martin Fowler ২০০২ সালের বই “Patterns of Enterprise Application Architecture”-এ এদের যে নাম দেন, সেগুলোই আজ সবচেয়ে প্রচলিত:

একই চারজন মানুষকে তিন কৌশলে রেখে তুলনা করুন — Arif আর Bristy শিক্ষার্থী, Dr. Anisur শিক্ষক, আর Jamal কোনো subclass-এ নেই (partial):

Elmasri–Navathe-এর বইয়ে এগুলোকে mapping-এর “Step 8”-এর বিকল্প হিসেবে লেখা হয়েছে: 8A (superclass আর subclass সবার আলাদা টেবিল — যেকোনো specialization-এ চলে), 8B (শুধু subclass-এর টেবিল — total হলে), 8C (একটি টেবিল, একটি type attribute — disjoint হলে), আর 8D (একটি টেবিল, প্রতি subclass-এর একটি হ্যাঁ/না type attribute — overlapping-এর জন্য)। পর্ব ১০-এ ER আর EER থেকে টেবিলে যাওয়ার পুরো নিয়ম ধাপে ধাপে দেখবেন; এখানে দেখুন কৌশল ৩ আর ১ আসল SQLite-এ কেমন চলে।

কৌশল ৩ হাতে-কলমে — একটি টেবিল, CHECK দিয়ে পাহারা

এই এডিটরের person টেবিলে সবাই: person_id, name, phone, ptype ('student' বা 'teacher'), আর চারটি nullable কলাম — batch, cgpa (শুধু শিক্ষার্থীর), salary, designation (শুধু শিক্ষকের)। Single table-এ subclass কলামে NOT NULL লেখা যায় না (শিক্ষকের batch তো থাকবেই না), তাই নিয়মটি একটি নাম দেওয়া CHECK-এ: subtype_columns — ptype 'student' হলে batch থাকতেই হবে আর শিক্ষকের কলাম খালি; 'teacher' হলে salary থাকতে হবে আর শিক্ষার্থীর কলাম খালি।

-- একটি টেবিলেই সবাই; ptype বলে কে কোন subclass
SELECT person_id, name, ptype, batch, cgpa, salary, designation
FROM person;

-- একটি subclass চাই? শুধু WHERE — কোনো JOIN নেই
SELECT person_id, name, batch, cgpa
FROM person WHERE ptype = 'student';

-- নতুন শিক্ষক, শিক্ষার্থীর কলাম খালি: চলবে
INSERT INTO person (person_id, name, ptype, salary, designation)
VALUES (5, 'Tasnim Chowdhury', 'teacher', 65000, 'Lecturer');

-- শিক্ষকের সারিতে cgpa: subtype_columns ভাঙবে
INSERT INTO person (person_id, name, ptype, salary, cgpa)
VALUES (6, 'Kamrul Hasan', 'teacher', 90000, 3.2);

কৌশল ১ হাতে-কলমে — তিন টেবিল, একই primary key

এখানে person (person_id, name, phone), student (person_id, batch, cgpa) আর teacher (person_id, salary, designation). student আর teacher-এর person_id একই সাথে primary key আর REFERENCES person(person_id) ON DELETE CASCADE — মানুষটি মুছলে তাঁর “বিশেষ পাতা”-ও যায়, অংশ ৪-এর মোছার নিয়মের মতো। person-এ পাঁচজন: Arif (1), Bristy (2) শিক্ষার্থী; Dr. Anisur (3), Shahana (4) শিক্ষক; আর Jamal Uddin (5) শুধু PERSON.

-- পূর্ণ শিক্ষার্থী-সারি: person-এর সাধারণ অংশ + student-এর বিশেষ অংশ
SELECT p.person_id, p.name, p.phone, s.batch, s.cgpa
FROM person p JOIN student s ON s.person_id = p.person_id;

-- সবাই, সাথে কে কোন subclass-এ (LEFT JOIN: না মিললে NULL)
SELECT p.person_id, p.name,
       CASE WHEN s.person_id IS NOT NULL THEN 'student'
            WHEN t.person_id IS NOT NULL THEN 'teacher'
            ELSE '(none)' END AS role
FROM person p
LEFT JOIN student s ON s.person_id = p.person_id
LEFT JOIN teacher t ON t.person_id = p.person_id;

৭ · Overlap, disjointness আর completeness — SQL দিয়ে পাহারা

কৌশল ১ সবচেয়ে নমনীয়, কিন্তু তার নিজের কোনো মতামত নেই: student আর teacher দুটি স্বাধীন টেবিল, তাই একই person_id দুটিতেই ঢুকতে পারে। নিয়ম overlapping হলে এটিই চাই; disjoint হলে এটিই ঠেকাতে হবে। প্রথমে overlapping দিক। এই এডিটরে person, student আর ta (person_id, course_id, hours — কোন কোর্সে সপ্তাহে কত ঘণ্টা সহায়তা)। person-এ Arif (1), Bristy (2) আর Dr. Anisur (3); student-এ 1 আর 2; ta এখনো খালি:

-- Bristy (2) শিক্ষার্থী, এখন CSE101-এর TA-ও: overlapping-এ বৈধ
INSERT INTO ta VALUES (2, 'CSE101', 10);

-- যাঁরা দুই subclass-এই: দুটি JOIN
SELECT p.person_id, p.name, s.batch, t.course_id, t.hours
FROM person p
JOIN student s ON s.person_id = p.person_id
JOIN ta t      ON t.person_id = p.person_id;

Disjointness ঠেকানো — type কলাম + composite foreign key

এবার উল্টো নিয়ম: একজন হয় শিক্ষার্থী, নয় শিক্ষক, দুটো নয়। সাধারণ CHECK এটি পারে না, কারণ CHECK শুধু একটি সারির ভেতরে দেখে, অন্য টেবিলে নয় (পর্ব ৬)। একটি পরিচিত কৌশল আছে, শুধু UNIQUE, CHECK আর foreign key দিয়ে:

1. person-এ একটি type কলাম রাখুন (ptype: 'S' বা 'T'), আর UNIQUE (person_id, ptype) দিন (UNIQUE constraint) — যাতে এই জোড়াটি foreign key-র লক্ষ্য হতে পারে।
2. প্রতিটি subclass টেবিলেও একটি ptype কলাম রাখুন, যার মান CHECK দিয়ে স্থির: student-এ সবসময় 'S', teacher-এ সবসময় 'T'.
3. Subclass-এর foreign key হবে জোড়ায় (composite): (person_id, ptype) REFERENCES person(person_id, ptype).

ফল: person-এ Arif-এর ptype 'S' হলে teacher টেবিলে তাঁর সারির জোড়া হবে (1, 'T') — যা person-এ নেই। Foreign key-ই disjointness রক্ষা করছে।

-- নতুন শিক্ষার্থী: আগে person-এ 'S', তারপর student-এ — চলবে
INSERT INTO person VALUES (2, 'Bristy Saha', 'S');
INSERT INTO student (person_id, batch) VALUES (2, 2021);

-- Arif (1) 'S' — তাঁকে teacher-এও ঢোকানোর চেষ্টা: বাতিল
INSERT INTO teacher (person_id, salary) VALUES (1, 50000);

Completeness — total সবচেয়ে কঠিন

Total specialization বলে প্রতিটি person-এর অন্তত একটি subclass-সারি থাকবে। কিন্তু কৌশল ১-এ person-এর সারি আগে ঢোকাতেই হয় (subclass-এর foreign key তার দিকে আঙুল তোলে), তাই ঢোকানোর মাঝখানের মুহূর্তে নিয়মটি ভাঙা থাকবেই। এটি ঠেকানোর তিনটি পথ: PostgreSQL-এর মতো সিস্টেমে transaction-এর শেষে যাচাই করা deferred constraint বা trigger (পর্ব ২৯); সব ঢোকানো একটি stored procedure দিয়ে করানো (পর্ব ২৮); বা নিয়মিত একটি anti join কোয়েরি চালিয়ে নিয়মভঙ্গ খোঁজা — উপরের LEFT JOIN কোয়েরির (none) সারিগুলোই সেই নিয়মভঙ্গ। এজন্যই total + disjoint হলে অনেকে কৌশল ৩ বেছে নেন: ptype NOT NULL লিখলেই completeness রক্ষিত।

৮ · PostgreSQL-এর INHERITS আর ORM-এর inheritance

PostgreSQL-এ টেবিলেরই inheritance আছে: CREATE TABLE student (…) INHERITS (person) লিখলে student টেবিল person-এর সব কলাম পায়, আর SELECT * FROM person চালালে student-এর সারিগুলোও আসে। দেখতে ঠিক EER-এর মতো — কিন্তু সাবধান। নিচের ব্লক চালানো যায় না (এই পাতার রানার SQLite):

CREATE TABLE person (
  person_id INTEGER PRIMARY KEY,
  name      TEXT NOT NULL,
  phone     TEXT
);
CREATE TABLE student (
  batch INTEGER NOT NULL,
  cgpa  NUMERIC(3,2)
) INHERITS (person);            -- student-এ person_id, name, phone-ও আছে

INSERT INTO student (person_id, name, batch) VALUES (1, 'Arif Hossain', 2021);
SELECT * FROM person;           -- Arif-ও আসেন (child টেবিলসহ)
SELECT * FROM ONLY person;      -- শুধু person-এর নিজের সারি

INSERT INTO person (person_id, name) VALUES (1, 'Someone Else');  -- আটকায় না!

শেষ লাইনটিই সমস্যা। PostgreSQL-এর নিজের documentation এই সীমাবদ্ধতাগুলো স্পষ্ট লিখে রেখেছে:

• Index, UNIQUE আর PRIMARY KEY শুধু একটি টেবিলে খাটে। person-এর primary key student-এ উত্তরাধিকারে যায় না, আর দুই টেবিল জুড়ে person_id-র অনন্যতা কেউ রক্ষা করে না — তাই উপরে person_id 1 দুবার।
• Foreign key-ও উত্তরাধিকারে যায় না, আর child-এর সারি দেখে না। অন্য কোনো টেবিল REFERENCES person(person_id) লিখলে সেটি student-এর সারি গ্রহণ করবে না — Arif-কে বই ধার দেওয়ার রেকর্ডই রাখা যাবে না।
• যা উত্তরাধিকারে যায়: কলাম, NOT NULL আর CHECK constraint (যদি NO INHERIT না লেখা হয়)।

PostgreSQL 10-এর আগে বড় টেবিলকে ভাগ করার (partitioning) কাজ এই inheritance দিয়েই করা হতো; ২০১৭ সালের PostgreSQL 10-এ আলাদা “declarative partitioning” আসে, আর এখন সেটিই সুপারিশকৃত পথ। EER-এর inheritance-এর জন্য INHERITS সাধারণত বেছে নেওয়া হয় না — অংশ ৬-এর তিন কৌশলই প্রচলিত।

ORM-এ একই তিন কৌশল

Java বা Python-এ ক্লাস হিসেবে Student extends Person লিখলে ORM (যে library object আর টেবিলের মধ্যে অনুবাদ করে) জানতে চায়: কোন কৌশলে টেবিল বানাব? নামগুলো ভিন্ন, কিন্তু ভেতরে সেই তিন কৌশলই:

@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)  // ডিফল্ট
@DiscriminatorColumn(name = "ptype")                   // না দিলে নাম DTYPE
public abstract class Person {
    @Id Long id;
    String name;
}

@Entity
@DiscriminatorValue("student")
public class Student extends Person {
    Integer batch;     // primitive int নয়: শিক্ষকের সারিতে কলামটি NULL
    Double cgpa;
}
// InheritanceType.JOINED          → কৌশল ১ (class table)
// InheritanceType.TABLE_PER_CLASS → কৌশল ২ (concrete table)

from django.db import models

class Person(models.Model):            # নিজের টেবিল আছে
    name = models.CharField(max_length=100)

class Student(Person):                 # multi-table inheritance = কৌশল ১
    batch = models.IntegerField()      # student টেবিলে person_ptr_id → person

class Base(models.Model):              # abstract base class = কৌশল ২
    name = models.CharField(max_length=100)
    class Meta:
        abstract = True                # Base-এর কোনো টেবিল হয় না

JPA (Java Persistence API)-তে ডিফল্ট SINGLE_TABLE; JOINED হলো class table, আর TABLE_PER_CLASS হলো concrete table — শেষেরটির সমর্থন JPA specification-এ ঐচ্ছিক, যদিও Hibernate তা দেয়। Django-তে একটি সাধারণ model থেকে subclass বানালে হয় multi-table inheritance: প্রতিটি Student পড়তে নীরবে person-এর সাথে JOIN হয়, যা অনেক নতুন Django ডেভেলপার জানেন না। abstract = True দিলে concrete table, আর proxy model একই টেবিলে শুধু Python-এর আচরণ বদলায়। Ruby on Rails-এর Active Record একটি type কলাম দেখলেই single table inheritance ধরে নেয়, আর SQLAlchemy তিনটিই সমর্থন করে। ORM-এর সুবিধা-ফাঁদ পর্ব ৫০-এ।

৯ · AI-এর যুগে EER নকশা

AI-কে “একটি হাসপাতালের ডেটাবেস ডিজাইন করে দাও” বললে সে প্রায়ই খুব আত্মবিশ্বাসী inheritance-ভরা নকশা দেয়। কিছু ভুল বারবার দেখা যায়, আর এগুলো চোখে পড়ে না, কারণ টেবিলগুলো তৈরি হয়, ডেটাও ঢোকে:

AI-এর দেওয়া EER নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি subclass-এর অন্তত একটি নিজস্ব attribute বা relationship আছে
• প্রতিটি specialization-এ d/o আর total/partial লেখা, আর প্রতিটির পক্ষে একটি বাস্তব উদাহরণ বলতে পারি
• বেছে নেওয়া টেবিল-কৌশল constraint-এর সাথে মেলে (concrete table শুধু total-এ, single type কলাম শুধু disjoint-এ)
• নমুনা ডেটায় নিয়মভাঙা INSERT চালিয়ে দেখেছি ত্রুটি আসে
• “সব superclass entity” কোয়েরির সারির সংখ্যা superclass টেবিলের COUNT(*)-এর সাথে মিলিয়েছি
• AI যে কলামের নাম ব্যবহার করেছে, সেগুলো আসল schema-তে আছে কি না মিলিয়েছি