ER মডেল — entity, attribute আর relationship

১ · ডিজাইন আগে, টেবিল পরে — ER মডেল কেন

ধরুন মিরপুরের একটি কোচিং সেন্টারের মালিক আপনাকে ফোন করে বললেন, “ভাই, আমাদের জন্য একটা ডেটাবেস বানিয়ে দেন।” আপনি সোজা ল্যাপটপ খুলে CREATE TABLE students লিখতে শুরু করলেন। দুই সপ্তাহ পরে জানা গেল: একজন শিক্ষার্থী একসাথে তিনটি ব্যাচে পড়েন, প্রত্যেক ব্যাচের ফি আলাদা, অভিভাবকের দুটি ফোন নম্বর রাখতে হয়, আর একজন শিক্ষক বদলি হলে তাঁর ব্যাচ অন্যজনকে দিতে হয়। আপনার টেবিলে এর কোনোটিই ধরে না। এখন টেবিল ভাঙা, ডেটা সরানো, অ্যাপের কোড বদলানো — সব নতুন করে।

হাসপাতালের ক্ষেত্রে ভুলের দাম আরও বেশি। “রোগী” বলতে হাসপাতাল কী বোঝায় — একজন মানুষ, নাকি একবারের ভর্তি? একই রোগী তিনবার ভর্তি হলে কি তিনটি রেকর্ড? একজন রোগীকে কি একাধিক ডাক্তার দেখেন? এই প্রশ্নগুলোর উত্তর না জেনে টেবিল বানালে ভুলটা ধরা পড়ে মাসখানেক পরে, যখন কয়েক হাজার রেকর্ড জমে গেছে।

তাই পেশাদার ডিজাইন সাধারণত তিন ধাপে চলে (পর্ব ৪-এ এই স্তরগুলোর নাম দেখেছেন):

1. Requirements analysis: যাঁরা ডেটা ব্যবহার করবেন (মালিক, অফিস-সহকারী, শিক্ষক) তাঁদের সাথে কথা বলে লিখে নেওয়া — কী রাখতে হবে, কোন প্রশ্নের উত্তর চাই, কোন নিয়ম মানতে হবে।
2. Conceptual model: সেই লেখাকে ER ডায়াগ্রামে আঁকা। এখানে কোনো ডেটা টাইপ নেই, SQL নেই, কোন DBMS তা-ও ঠিক হয়নি — শুধু “কী আছে আর কীভাবে যুক্ত”।
3. Logical ও physical ডিজাইন: ডায়াগ্রাম থেকে নিয়ম মেনে টেবিল, key আর foreign key (পর্ব ১০), তারপর ডেটা টাইপ, index ইত্যাদি।

চাহিদা জানার আলাপে (requirements interview) কিছু প্রশ্ন প্রায় সবসময় কাজে লাগে: “একজন শিক্ষার্থীর কি একাধিক ফোন নম্বর থাকতে পারে?”, “একটি ব্যাচ কি কখনো দুজন শিক্ষক মিলে পড়ান?”, “শিক্ষার্থী চলে গেলে তাঁর পুরোনো ফি-র হিসাব কি রাখতে হবে?”, “মাসে কোন কোন রিপোর্ট দেখতে চান?” প্রতিটি উত্তর ER ডায়াগ্রামে একটি রেখা, একটি চিহ্ন বা একটি নতুন বাক্স হয়ে যায়।

২ · Entity, entity type আর entity set

Entity হলো বাস্তব জগতের এমন একটি জিনিস, যাকে আলাদা করে চেনা যায় আর যার সম্পর্কে তথ্য রাখার দরকার আছে। শিক্ষার্থী Arif Hossain একটি entity, কোর্স CSE301 একটি entity, CSE বিভাগ একটি entity. Entity চোখে দেখা যায় এমন হতে হবে না: একটি ব্যাংক অ্যাকাউন্ট, একটি bKash লেনদেন বা একটি ট্রেনের টিকিট বুকিংও entity — এদের প্রত্যেকটি আলাদা, আর প্রত্যেকটির নিজস্ব তথ্য আছে।

তিনটি শব্দ পরীক্ষায় প্রায়ই গুলিয়ে যায়, তাই আলাদা করে দেখুন:

অনেক বই (যেমন Silberschatz-এর বই) “entity type” আর “entity set” প্রায় একই অর্থে ব্যবহার করে; Elmasri ও Navathe-র বই পার্থক্যটি স্পষ্ট রাখে — type হলো schema (স্থির), set হলো instance (বদলায়)। পর্ব ৩ আর ৫-এ schema আর instance-এর যে পার্থক্য দেখেছেন, এটি ঠিক তাই। ER ডায়াগ্রামে আঁকা হয় entity type, আর সেটি হয় একটি আয়তক্ষেত্র, ভেতরে বড় হাতের অক্ষরে একবচনে নাম: STUDENT, COURSE, DEPARTMENT.

এই পর্বের বেশিরভাগ লাইভ SQL চলবে বিশ্ববিদ্যালয়ের নমুনা ডেটাবেসে (db-uni). এর পাঁচটি টেবিল: departments (dept_id, name, building — ৪টি বিভাগ), instructors (instructor_id, name, dept_id, salary আর mentor_id — একজন শিক্ষকের mentor আরেকজন শিক্ষক; ৬ জন), students (student_id, name, dept_id, batch, cgpa — ৮ জন), courses (course_id, title, dept_id, credits, instructor_id — ৭টি কোর্স) আর enrollments (student_id, course_id, term, grade — কে কোন কোর্সে কোন term-এ ভর্তি, কী গ্রেড)। প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়, তাই নির্ভয়ে বদলে দেখুন। প্রথমে INSTRUCTOR entity set-টি দেখা যাক:

-- INSTRUCTOR entity set: প্রতিটি সারি একটি entity
SELECT instructor_id, name, dept_id FROM instructors;

-- entity set-এ এই মুহূর্তে কয়টি entity?
SELECT COUNT(*) AS entity_count FROM instructors;

৩ · Attribute — ছয় রকম চেহারা

প্রতিটি entity-কে বর্ণনা করে তার attribute: শিক্ষার্থীর নাম, রোল, জন্মতারিখ, ফোন নম্বর। ER ডায়াগ্রামে attribute আঁকা হয় একটি উপবৃত্তে (ellipse), রেখা দিয়ে তার entity-র সাথে যুক্ত। কিন্তু সব attribute এক রকম নয় — তিনটি প্রশ্ন দিয়ে এদের ভাগ করা হয়, আর প্রতিটি ভাগের আলাদা চিহ্ন আছে:

প্রশ্ন ১ — ভাঙা যায় কি? Simple বনাম composite

Simple (atomic) attribute আর ছোট অর্থপূর্ণ অংশে ভাঙা হয় না: roll, dob, cgpa. Composite attribute কয়েকটি অংশ মিলে তৈরি, আর অংশগুলো আলাদাভাবেও কাজে লাগে। নাম ভাঙে first_name আর last_name-এ; বাংলাদেশি ঠিকানা ভাঙে বাড়ি/রাস্তা, এলাকা, থানা বা উপজেলা, জেলা আর বিভাগে। কোনটি composite, তা ঠিক করে ব্যবহার: কোচিং সেন্টার যদি “মিরপুর থানার সব শিক্ষার্থী” খুঁজতে চায়, ঠিকানাকে composite রাখতেই হবে; যদি শুধু চিঠির খামে লেখার জন্য লাগে, এক লাইনের simple attribute-ই যথেষ্ট।

db-uni-তে name একটি ঘরেই রাখা, অর্থাৎ simple হিসেবে। প্রথম নাম আলাদা করতে চাইলে কী ঝামেলা হয়, দেখুন:

-- প্রথম ফাঁকা জায়গার আগে প্রথম নাম, পরে শেষ নাম
SELECT name,
       substr(name, 1, instr(name, ' ') - 1) AS first_name,
       substr(name, instr(name, ' ') + 1)    AS last_name
FROM students WHERE batch = 2022;

-- একই কৌশল শিক্ষকদের নামে
SELECT name, substr(name, 1, instr(name, ' ') - 1) AS first_name
FROM instructors WHERE instructor_id <= 3;

প্রশ্ন ২ — মান কয়টি? Single-valued বনাম multi-valued

Single-valued attribute-এর একটি entity-র জন্য সর্বোচ্চ একটি মান: একজনের জন্মতারিখ একটিই। Multi-valued attribute-এর একাধিক মান হতে পারে: অভিভাবকের দুটি ফোন নম্বর, একজন শিক্ষকের কয়েকটি ডিগ্রি, একটি বইয়ের কয়েকজন লেখক। Chen notation-এ এটি দুই-রেখার ellipse.

Relational টেবিলের প্রতিটি ঘরে একটিমাত্র atomic মান থাকে (পর্ব ৫-এর first normal form). তাই multi-valued attribute কখনো phone1, phone2, phone3 কলাম বা '017…, 018…' লেখা নয় — এটি যায় আলাদা একটি টেবিলে, যার প্রতিটি সারি “একজন শিক্ষার্থী, একটি নম্বর”। নিচের এডিটর db-uni-র সাথে এমন একটি ছোট টেবিল student_phones(student_id, phone) যোগ করে নেয়, যাতে তিনজন শিক্ষার্থীর মোট ৬টি নম্বর আছে:

-- multi-valued attribute: প্রতিটি নম্বর আলাদা সারি
SELECT s.student_id, s.name, p.phone
FROM student_phones AS p
JOIN students AS s ON s.student_id = p.student_id
ORDER BY s.student_id, p.phone;

SELECT student_id, COUNT(*) AS phones
FROM student_phones GROUP BY student_id;

-- নেই এমন শিক্ষার্থীর নম্বর রাখা যাবে না
INSERT INTO student_phones VALUES (9999, '01700000000');

প্রশ্ন ৩ — জমা রাখি, নাকি হিসাব করি? Stored বনাম derived

জন্মতারিখ একটি stored attribute — এটি অন্য কিছু থেকে বের করা যায় না, জমা রাখতেই হয়। বয়স একটি derived attribute: জন্মতারিখ আর আজকের তারিখ থেকে হিসাব করা যায়। Chen notation-এ derived attribute-এর ellipse ভাঙা রেখায় আঁকা হয়। বয়স জমা রাখলে প্রতি জন্মদিনে কাউকে সেটি বদলাতে হবে — ভুলে গেলে ডেটা মিথ্যা বলবে। তাই বয়স চাওয়ার সময় হিসাব করুন। নিচের এডিটর একটি হাসপাতালের ছোট টেবিল patients(patient_id, name, dob) বানায় আর একটি নির্দিষ্ট দিনের (2026-10-25) হিসাবে বয়স বের করে:

-- age = বছরের পার্থক্য, জন্মদিন এখনো না এলে এক বাদ
SELECT name, dob,
       (CAST(strftime('%Y', '2026-10-25') AS INTEGER)
        - CAST(strftime('%Y', dob) AS INTEGER))
       - (strftime('%m-%d', '2026-10-25') < strftime('%m-%d', dob)) AS age
FROM patients;

-- PostgreSQL: age() একটি interval দেয়, তা থেকে বছর
SELECT name, date_part('year', age(DATE '2026-10-25', dob)) AS age FROM patients;

-- MySQL: পূর্ণ বছরের সংখ্যা
SELECT name, TIMESTAMPDIFF(YEAR, dob, '2026-10-25') AS age FROM patients;

Key attribute আর ঐচ্ছিক (NULL) attribute

যে attribute প্রতিটি entity-কে আলাদা করে চেনায় — পর্ব ৬-এর candidate key-র ER রূপ — তাকে বলে key attribute; ER ডায়াগ্রামে তার নামের নিচে দাগ টানা হয় (roll, student_id, course_id). একাধিক attribute মিলে key হলে সবগুলোর নিচে দাগ। আর কিছু attribute ঐচ্ছিক: সব শিক্ষার্থীর email নেই, নতুন ভর্তি হওয়া শিক্ষার্থীর cgpa এখনো হয়নি। এদের মান না থাকলে টেবিলে NULL বসে — db-uni-তে Fahim Karim-এর cgpa NULL. ER-এ ঐচ্ছিকতার আলাদা চিহ্ন নেই; এটি ডায়াগ্রামের পাশে নোট হিসেবে বা পরে টেবিলে NOT NULL না দিয়ে প্রকাশ করা হয়। মনে রাখুন: key attribute কখনো ঐচ্ছিক হতে পারে না।

৪ · Relationship, relationship set আর relationship-এর attribute

Entity একা অর্থহীন; তথ্যের আসল মূল্য তাদের সংযোগে। “Arif Hossain Database Systems কোর্সে ভর্তি হয়েছেন” — এটি একটি relationship: দুটি নির্দিষ্ট entity-র মধ্যে একটি সম্পর্ক। একই ধরনের সব relationship-এর সংগ্রহ হলো relationship set — সব ভর্তি মিলে ENROLLS. ER ডায়াগ্রামে relationship আঁকা হয় হীরক (diamond) আকারে, নাম সাধারণত একটি ক্রিয়া: ENROLLS, TEACHES, WORKS_IN.

সংজ্ঞাটির একটি গুরুত্বপূর্ণ ফল আছে: R একটি সেট, তাই একই (Arif, CSE301) জোড়া R-এ দুবার থাকতে পারে না। অথচ বাস্তবে একজন শিক্ষার্থী ফেল করে পরের term-এ একই কোর্স আবার নিতে পারেন। db-uni-র enrollments টেবিল তাই key-তে term রেখেছে — ER-এ এটি কীভাবে আঁকা উচিত, সেই সূক্ষ্ম প্রশ্নটি ভাবনার প্রশ্ন ৫-এ।

Relationship-এরও attribute থাকে

Arif-এর Database Systems কোর্সের গ্রেড A- — এই “A-” কার attribute? শিক্ষার্থীর নয়, কারণ Arif-এর অনেক কোর্সে অনেক গ্রেড। কোর্সেরও নয়, কারণ একই কোর্সে বিভিন্ন শিক্ষার্থীর বিভিন্ন গ্রেড। গ্রেডটি ঠিক হয় দুজন মিলে — তাই এটি ENROLLS relationship-এর নিজের attribute, একটি relationship attribute. ডায়াগ্রামে এর ellipse হীরকের সাথে যুক্ত থাকে:

টেবিলে এই relationship set-টিই enrollments: প্রতিটি সারি একটি (শিক্ষার্থী, কোর্স) জোড়া — দুটি foreign key দিয়ে — আর তার সাথে term ও grade. দুজন শিক্ষার্থীর সব ভর্তি দেখুন:

-- ENROLLS relationship set: (student, course) জোড়া + তার attribute
SELECT s.name, c.title, e.term, e.grade
FROM enrollments AS e
JOIN students AS s ON s.student_id = e.student_id
JOIN courses  AS c ON c.course_id  = e.course_id
WHERE e.student_id IN (2101, 2201)
ORDER BY e.student_id, e.term, e.course_id;

৫ · Degree — unary, binary আর ternary

একটি relationship-এ কয়টি entity type অংশ নেয়, সেটি তার degree. (পর্ব ৫-এ relation-এর degree মানে ছিল কলামের সংখ্যা — একই শব্দ, আলাদা অর্থ।)

• Binary (degree ২): দুটি entity type. STUDENT ENROLLS COURSE, INSTRUCTOR TEACHES COURSE. বাস্তব ডিজাইনের বেশিরভাগ relationship এমন।
• Unary বা recursive (degree ১): একই entity type দুটি আলাদা ভূমিকায়। একজন শিক্ষক আরেকজন শিক্ষকের mentor; একজন কর্মচারী আরেকজনের supervisor; একটি কোর্স আরেকটি কোর্সের prerequisite.
• Ternary (degree ৩): তিনটি entity type একসাথে। একজন supplier একটি part একটি project-এ সরবরাহ করে।

Recursive relationship আর role name

MENTORS relationship-এর দুই প্রান্তেই INSTRUCTOR. তাহলে কে কাকে mentor করছেন, বোঝা যাবে কীভাবে? এর জন্য প্রতিটি রেখায় একটি role name লেখা হয় — এক দিকে mentor, অন্য দিকে mentee. সাধারণ binary relationship-এ role name ঐচ্ছিক (STUDENT-এর ভূমিকা স্পষ্ট), কিন্তু recursive relationship-এ এটি না লিখলে ডায়াগ্রাম অস্পষ্ট।

টেবিলে recursive relationship সাধারণত একটি self-referencing foreign key হয় (পর্ব ৬): instructors.mentor_id → instructors.instructor_id. আর একে কোয়েরি করতে একই টেবিলকে দুটি আলাদা নাম দিয়ে নিজের সাথে জুড়তে হয় — একটি কপি “mentee” ভূমিকায় (i), আরেকটি “mentor” ভূমিকায় (m). একে বলে self join; বিস্তারিত পর্ব ২০-এ, এখানে শুধু দেখুন role name কীভাবে alias হয়ে যায়:

-- i = mentee ভূমিকায় শিক্ষক, m = mentor ভূমিকায় শিক্ষক
SELECT i.name AS mentee, m.name AS mentor
FROM instructors AS i
LEFT JOIN instructors AS m ON m.instructor_id = i.mentor_id
ORDER BY i.instructor_id;

-- শুধু যাঁদের mentor আছে (MENTORS-এর relationship instance)
SELECT i.name AS mentee, m.name AS mentor
FROM instructors AS i
JOIN instructors AS m ON m.instructor_id = i.mentor_id;

Ternary — যখন তিনজন একসাথে

একটি নির্মাণ প্রতিষ্ঠানের কথা ভাবুন। তারা বিভিন্ন supplier থেকে রড, সিমেন্ট, ইট (part) কেনে, বিভিন্ন project-এর (একটি সেতু, একটি স্কুল ভবন) জন্য। নিয়মটি হলো: “supplier S, part P, project J-এর জন্য কত পরিমাণ দিয়েছে”। এখানে quantity তিনজনের একসাথে — শুধু (S, P) বা শুধু (P, J) জানলে বলা যায় না। এটি একটি ternary relationship SUPPLY:

প্রশ্ন জাগে: তিনটি ছোট binary — SUPPLIES_PART (supplier–part), USES (part–project), WORKS_FOR (supplier–project) — দিয়ে কি একই তথ্য রাখা যায় না? ছোট একটি উদাহরণে ধাপে ধাপে দেখুন:

এবার একই কাজ আসল SQLite-এ। এডিটরটি supply(supplier, part, project, quantity) টেবিলে উপরের তিনটি সারি রাখে; কোড তিনটি জোড়া-টেবিল বানিয়ে আবার জোড়া দেয়:

-- ternary থেকে তিনটি binary (জোড়া)
CREATE TABLE sp AS SELECT DISTINCT supplier, part FROM supply;
CREATE TABLE pj AS SELECT DISTINCT part, project FROM supply;
CREATE TABLE sj AS SELECT DISTINCT supplier, project FROM supply;

-- তিন জোড়া মিলিয়ে ternary ফেরত আনার চেষ্টা
SELECT sp.supplier, sp.part, pj.project
FROM sp
JOIN pj ON pj.part = sp.part
JOIN sj ON sj.supplier = sp.supplier AND sj.project = pj.project
ORDER BY 1, 2, 3;

৬ · চাহিদার বর্ণনা থেকে ER ডায়াগ্রাম — ধাপে ধাপে

এবার অংশ ১-এর কোচিং সেন্টারে ফিরি। মালিকের সাথে আলাপের পর আপনি একটি ছোট অনুচ্ছেদ লিখলেন। এই লেখা থেকে entity, attribute আর relationship খুঁজে বের করার একটি পুরোনো কিন্তু কার্যকর কৌশল আছে: বিশেষ্য (noun) সাধারণত entity বা attribute, ক্রিয়া (verb) সাধারণত relationship. Chen নিজেই ১৯৮৩ সালের একটি প্রবন্ধে ইংরেজি বাক্যের গঠন আর ER ডায়াগ্রামের এই মিল দেখিয়েছিলেন। কৌশলটি নিয়ম নয়, একটি শুরুর বিন্দু — তবে পরীক্ষার হলে আর বাস্তব আলাপে দুই জায়গাতেই কাজ দেয়।

শেষ ধাপটিই আসল শিক্ষা: বর্ণনা থেকে অর্ধেক উত্তর মেলে, বাকি অর্ধেক মেলে প্রশ্ন থেকে। “মাসিক ফি” একটি শব্দ, কিন্তু এটি কোথায় বসবে তা ঠিক করে একটি ব্যবসার নিয়ম, যা লেখায় ছিল না।

৭ · db-uni-র ER ডায়াগ্রাম — আঁকা আর জোরে পড়া

এ পর্যন্ত যে বিশ্ববিদ্যালয়ের ডেটাবেসে SQL চালিয়েছেন, তার পেছনের ER ডায়াগ্রামটি কেমন? উল্টো দিক থেকে আঁকা যাক — টেবিল দেখে ধারণায় ফেরা (একে reverse engineering বলে)। প্রতিটি ধাপে ডানের টেবিলে দেখবেন ছবির অংশটি db-uni-র কোন কলামে আছে। ছোট পর্দায় ছবিটি পরিষ্কার রাখতে প্রতিটি entity-র সব attribute আঁকা হয়নি — key আর কয়েকটি নমুনা।

ER ডায়াগ্রাম জোরে পড়ার নিয়ম

ডায়াগ্রাম আঁকা হয় অ-প্রযুক্তিগত মানুষকে দেখানোর জন্য, তাই প্রতিটি অংশ একটি সাধারণ বাক্যে পড়া যাওয়া চাই। তিনটি ছাঁচ মনে রাখুন:

• Entity + attribute: “প্রতিটি STUDENT-এর একটি student_id (যা দিয়ে তাঁকে চেনা যায়), একটি নাম আর এক বা একাধিক ফোন নম্বর আছে।”
• Relationship: “[entity ১] [relationship-এর ক্রিয়া] [entity ২]” — “STUDENT ENROLLS COURSE”: একজন শিক্ষার্থী একটি কোর্সে ভর্তি হন।
• Relationship attribute: “প্রতিটি ভর্তির একটি grade আছে” — “শিক্ষার্থীর grade আছে” বললে ভুল, কারণ তখন মনে হয় শিক্ষার্থীর একটিই গ্রেড।

পড়তে গিয়ে আটকে গেলে — “একটি DEPARTMENT একটি STUDENT-কে … কী করে?” — সেটিই ডিজাইনের দুর্বল জায়গা। Relationship-এর নাম এমন রাখুন যাতে বাক্য দুই দিক থেকেই পড়া যায়, বা অন্তত তীর-চিহ্ন বা role name দিয়ে দিক বোঝান। কয়টি শিক্ষার্থী কয়টি কোর্সে — এই “কতজন” প্রশ্নের চিহ্ন (cardinality) আর “সবাইকে কি থাকতেই হবে” প্রশ্নের চিহ্ন (participation) পর্ব ৮-এর বিষয়।

৮ · তিন রকম notation — Chen, Crow's foot আর UML

ER মডেল একটি ধারণা; তাকে আঁকার রীতি একাধিক। একই তথ্য — “শিক্ষার্থী কোর্সে ভর্তি হন, প্রতিটি ভর্তির term আর grade আছে” — তিন রীতিতে দেখুন (ট্যাব বদলান):

আজকের টুল

কাগজ-কলম আর হোয়াইটবোর্ড আজও ডিজাইনের প্রথম আলাপের সেরা সঙ্গী। পরিষ্কার ছবির জন্য কয়েকটি প্রচলিত টুল (কোনোটির পক্ষে সুপারিশ নয়; সবই নিজের প্রয়োজন মিলিয়ে বেছে নিন):

• draw.io (diagrams.net): ব্রাউজারে চলে, বিনামূল্যে; Chen, Crow's foot, UML সব চিহ্নের আকার আছে। পরীক্ষার প্রস্তুতির জন্য Chen ডায়াগ্রাম আঁকতে সুবিধাজনক।
• dbdiagram.io: ছবি টেনে নয়, লেখা (DBML নামের একটি ছোট ভাষা) থেকে Crow's foot-ধাঁচের ডায়াগ্রাম বানায়; লেখাটি git-এ রাখা যায়।
• pgAdmin 4-এর ERD Tool আর MySQL Workbench-এর EER Diagram: চালু ডেটাবেসের টেবিল থেকে ডায়াগ্রাম বানাতে পারে (reverse engineering), আবার ডায়াগ্রাম থেকে CREATE TABLE-ও লিখতে পারে (forward engineering).
• Mermaid: Markdown-এর ভেতরে erDiagram লিখলে GitHub-এর মতো জায়গায় ছবি দেখায় — দলের ডকুমেন্টেশনে কাজে লাগে।

Table students {
  student_id integer [pk]
  name       varchar
}
Table courses {
  course_id varchar [pk]
  title     varchar
}
Table enrollments {
  student_id integer [ref: > students.student_id]
  course_id  varchar [ref: > courses.course_id]
  term       varchar
  grade      varchar
}

খেয়াল করুন, এই টুলগুলোর বেশিরভাগ আসলে টেবিল-স্তরের (logical) ছবি আঁকে — attribute-এর ধরন (multi-valued, derived) বা ternary relationship সরাসরি দেখাতে পারে না। ধারণা-স্তরের চিন্তাটি তাই আগে মাথায় বা কাগজে করে নিতে হয়।

৯ · মডেলিংয়ের প্রচলিত ভুল

ভুল ১ — attribute নাকি entity? “শহর”-এর প্রশ্ন

গ্রাহকের city কি একটি attribute, নাকি CITY একটি আলাদা entity? নিয়মটি হলো: যদি জিনিসটির নিজের কোনো তথ্য রাখতে হয়, বা অনেক entity একে ভাগ করে নেয় আর বানান একই রাখা জরুরি, তাহলে সেটি entity. শুধু ঠিকানায় লেখার জন্য হলে attribute-ই যথেষ্ট। কিন্তু দোকান যদি জেলাভিত্তিক ডেলিভারি চার্জ, বিভাগভিত্তিক বিক্রির রিপোর্ট বা “ঢাকার ভেতরে একদিনে ডেলিভারি” চায়, তাহলে CITY বা DISTRICT-এর নিজের attribute (চার্জ, বিভাগ) আছে — সেটি entity. City যখন মুক্ত লেখা, তখন কী হয় দেখুন। এডিটরটি একটি ছোট customers(customer_id, name, city) টেবিল বানায়, যেখানে বিভিন্ন জন বিভিন্নভাবে শহরের নাম লিখেছেন:

-- শহরভিত্তিক গ্রাহক গণনা
SELECT city, COUNT(*) AS n
FROM customers GROUP BY city ORDER BY city;

-- জোড়াতালি: ছোট হাতের অক্ষর আর বাড়তি ফাঁকা ছেঁটে
SELECT lower(trim(city)) AS city_fixed, COUNT(*) AS n
FROM customers GROUP BY lower(trim(city)) ORDER BY 1;

ভুল ২ — relationship নাকি entity?

“ভর্তি” কি শুধু STUDENT আর BATCH-এর relationship, নাকি নিজেই একটি entity? যতক্ষণ এর তথ্য অল্প (তারিখ, ফি), relationship-ই ভালো। কিন্তু ভর্তির নিজের রসিদ নম্বর, প্রতি মাসের কিস্তি, ছাড়ের অনুমোদন — এসব যুক্ত হতে থাকলে, বা অন্য relationship ভর্তির সাথে যুক্ত হতে চাইলে (“প্রতিটি কিস্তি একটি ভর্তির”), ভর্তিকে ENROLLMENT entity বানানোই পরিষ্কার। সাধারণ সংকেত: যে জিনিসের দিকে অন্য সম্পর্ক আঙুল তোলে, বা যার নিজের পরিচয়-নম্বর আছে, সেটি entity. হাসপাতালে “ভর্তি” (admission) প্রায় সবসময় entity — একই রোগী একই ওয়ার্ডে বহুবার ভর্তি হন, আর প্রতিটি ভর্তির বিল, ছাড়পত্র আলাদা।

ভুল ৩ — derived মান জমা রাখা

db-uni-র students টেবিলে cgpa একটি কলাম — অথচ cgpa আসলে enrollments-এর গ্রেড আর courses-এর credits থেকে হিসাব করা যায়, অর্থাৎ derived. জমা রাখা আর হিসাব করা মান মেলে কি না, দেখা যাক। নিচের কোয়েরি বাংলাদেশের বহু বিশ্ববিদ্যালয়ে প্রচলিত গ্রেড-স্কেল (A+ = 4.00, A = 3.75, A- = 3.50 …) দিয়ে প্রতিটি শিক্ষার্থীর credit-ভারিত গড় হিসাব করে:

SELECT s.name, s.cgpa AS stored,
       ROUND(SUM(c.credits * CASE e.grade
             WHEN 'A+' THEN 4.0  WHEN 'A'  THEN 3.75 WHEN 'A-' THEN 3.5
             WHEN 'B+' THEN 3.25 WHEN 'B'  THEN 3.0  WHEN 'B-' THEN 2.75
             WHEN 'C+' THEN 2.5  WHEN 'C'  THEN 2.25 WHEN 'D'  THEN 2.0
             ELSE 0 END) / SUM(c.credits), 2) AS computed
FROM students AS s
JOIN enrollments AS e ON e.student_id = s.student_id
JOIN courses     AS c ON c.course_id  = e.course_id
WHERE e.grade IS NOT NULL
GROUP BY s.student_id
ORDER BY s.student_id;

ভুল ৪ — ternary যেখানে লাগে না, আর লাগে যেখানে

দুই দিকেই ভুল হয়। অংশ ৫-এ দেখেছেন, SUPPLY-কে তিনটি binary-তে ভাঙলে ভুয়া সারি আসে — সেখানে ternary বাধ্যতামূলক। উল্টো ভুলটিও সমান প্রচলিত: STUDENT–COURSE–INSTRUCTOR একটি ternary “TAKES_FROM” বানানো, যখন বিশ্ববিদ্যালয়ের নিয়ম হলো “প্রতিটি কোর্স একজন শিক্ষকই পড়ান”। তখন শিক্ষক কোর্স থেকেই নির্ধারিত, ternary-তে প্রতিটি ভর্তির সাথে শিক্ষকের নাম বারবার লেখা হবে (redundancy), আর শিক্ষক বদলালে শত সারি বদলাতে হবে। db-uni ঠিক কাজটি করেছে: শিক্ষক courses-এ (TEACHES binary), ভর্তি enrollments-এ (ENROLLS binary). পরীক্ষার প্রশ্ন: “কোন একটি জোড়া জানলে তৃতীয়টি নির্ধারিত হয়ে যায়?” — হলে সম্ভবত binary যথেষ্ট; কোনো জোড়াই তৃতীয়টি ঠিক করতে না পারলে, আর তিনজনের একসাথে attribute (quantity) থাকলে, ternary.

আরও কয়েকটি ছোট ভুল

• Foreign key-কে attribute হিসেবে আঁকা: ER-এ STUDENT-এর পাশে “dept_id” ellipse আঁকা ভুল — সম্পর্কটি MAJORS_IN হীরক; foreign key আসবে টেবিলে রূপান্তরের সময় (পর্ব ১০)।
• বহুবচন বা অস্পষ্ট নাম: “STUDENTS”, “DATA”, “INFO” নয় — একবচন, অর্থপূর্ণ: STUDENT, PAYMENT.
• Key ছাড়া entity: যে entity-কে চেনার উপায় নেই, তার নকশা অসম্পূর্ণ (নিজের key না থাকা “দুর্বল” entity-র কথা পর্ব ৮-এ)।
• Multi-valued-কে কলামে ভাগ করা: phone1, phone2 — চতুর্থ নম্বর এলে schema বদলাতে হয়।

১০ · AI-এর যুগে ER ডিজাইন

AI-কে “একটা হাসপাতালের ER diagram বানিয়ে দাও” বললে কয়েক সেকেন্ডে চমৎকার দেখতে একটি ডায়াগ্রাম বা Mermaid কোড চলে আসে। সমস্যাটি এখানেই: AI আপনার ব্যবসার নিয়ম জানে না, তাই সে “সাধারণ” হাসপাতাল ধরে নেয়। AI প্রায়ই যা করে — ধারণার ভুল, কোয়েরির ভুল দুটিই:

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

• প্রতিটি entity, attribute আর relationship চাহিদার কোনো বাক্যে খুঁজে পাচ্ছি; বাড়তি কিছু থাকলে কারণ জানি
• প্রতিটি entity-র key আছে, আর multi-valued attribute আলাদা টেবিলে যাবে
• Derived মান জমা রাখা হলে কেন, আর কীভাবে হালনাগাদ থাকবে — উত্তর আছে
• প্রতিটি relationship attribute সত্যিই “জোড়ার”, কোনো একক entity-র নয়
• পুরো ডায়াগ্রাম বাক্যে জোরে পড়েছি, আর যিনি ডেটা ব্যবহার করবেন তিনি মাথা নেড়েছেন
• নমুনা ডেটায় টেবিল বানিয়ে মূল প্রশ্নগুলোর কোয়েরি চালিয়েছি; সারির সংখ্যা হাতে গোনা উত্তরের সাথে মিলেছে