Cardinality, participation আর weak entity

১ · Cardinality — “একজনের বিপরীতে কতজন?”

পর্ব ৭-এ (ER মডেল — entity, attribute আর relationship) দেখেছেন, ER model-এ বাস্তব জগতের জিনিসগুলো হয় entity — গ্রাহক, অর্ডার, শিক্ষার্থী, কোর্স। একই ধরনের সব entity মিলে একটি entity set, আর তাদের মধ্যের সম্পর্কগুলোর সংগ্রহ একটি relationship set — যেমন “গ্রাহক অর্ডার দেন” (places), “শিক্ষার্থী কোর্সে ভর্তি হন” (enrolls). কিন্তু শুধু “সম্পর্ক আছে” বলা যথেষ্ট নয়। ডিজাইনারকে জানতে হয় সম্পর্কটির আকার: একজন গ্রাহক কয়টি অর্ডার দিতে পারেন? একটি অর্ডার কয়জন গ্রাহকের হতে পারে?

এই প্রশ্নের উত্তরকেই বলে mapping cardinality বা cardinality ratio: একটি entity অন্য entity set-এর সর্বোচ্চ কতগুলো entity-র সাথে এই সম্পর্কে যুক্ত হতে পারে। পর্ব ৫-এ “cardinality” শব্দটি অন্য অর্থে দেখেছিলেন — একটি টেবিলে কয়টি সারি। ER মডেলে একই শব্দের মানে সম্পর্কের অনুপাত; প্রসঙ্গ দেখে অর্থ বুঝে নিতে হয়।

দুটি entity set A আর B-র মধ্যে একটি binary (দুই পক্ষের) relationship-এর জন্য চার রকম অনুপাত সম্ভব:

খেয়াল করুন, 1:N আর N:1 আসলে একই সম্পর্ক — শুধু কোন দিক থেকে বলছেন, তার পার্থক্য। “বিভাগ–শিক্ষার্থী 1:N” আর “শিক্ষার্থী–বিভাগ N:1” একই কথা। আরও খেয়াল করুন, cardinality শুধু সর্বোচ্চ সংখ্যা বলে। “প্রতিটি অর্ডারের কি গ্রাহক থাকতেই হবে?” — এই সর্বনিম্ন-এর প্রশ্নটি আলাদা, তার নাম participation, অংশ ৩-এ।

এই পর্বের লাইভ SQL চলে দুটি নমুনা ডেটাবেসে। db-shop একটি ছোট অনলাইন দোকান: customers (customer_id, name, city, phone, joined_on — ৮ জন গ্রাহক), categories, products (product_id, name, category_id, price, stock — ১০টি পণ্য), orders (order_id, customer_id, order_date, status — ১০টি অর্ডার) আর order_items (order_id, product_id, quantity, unit_price — কোন অর্ডারে কোন পণ্য কতটি)। db-uni একটি বিশ্ববিদ্যালয়: departments (dept_id, name, building — ৪টি বিভাগ), instructors, 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-এ কোন কোর্স নিয়েছেন)। প্রতিটি এডিটরের নিচে “নমুনা ডেটা” বাক্সে পুরো টেবিল দেখতে পাবেন; প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়।

২ · ব্যবসার নিয়ম থেকে cardinality — দুই দিক থেকে প্রশ্ন

Cardinality ঠিক করার একটি নির্ভরযোগ্য কৌশল আছে, যা পরীক্ষার খাতা থেকে অফিসের মিটিং পর্যন্ত সবখানে কাজ করে: সম্পর্কটিকে দুই দিক থেকে প্রশ্ন করুন, প্রতিবার একটি নির্দিষ্ট entity ধরে।

1. “একটি X-এর জন্য সর্বোচ্চ কতটি Y?” — উত্তর “১” না “অনেক”?
2. “একটি Y-এর জন্য সর্বোচ্চ কতটি X?” — আবার “১” না “অনেক”?
3. উত্তর কে দেবেন? যিনি ব্যবসা চালান — দোকানের মালিক, রেজিস্ট্রার অফিস, রেলের টিকিট বিভাগ। ডেটা দেখে নয়।

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

তবু ডেটা কাজে লাগে — নিয়ম ভেঙেছে কি না দেখতে, আর অনুমানটি যাচাই করতে। গ্রাহক–অর্ডার সম্পর্কটি db-shop-এ পরীক্ষা করা যাক। প্রথম কোয়েরি প্রতিটি গ্রাহকের অর্ডার গোনে (COUNT আর GROUP BY, বিস্তারিত পর্ব ১৮-এ); দ্বিতীয়টি খোঁজে এমন অর্ডার, যার গ্রাহক সংখ্যা ১ নয়:

-- “অনেক” দিক: একজন গ্রাহকের কয়টি অর্ডার?
SELECT customer_id, COUNT(*) AS orders_count
FROM orders
GROUP BY customer_id
ORDER BY orders_count DESC, customer_id;

-- “এক” দিক: এমন অর্ডার আছে কি, যার গ্রাহক ১ জন নয়?
SELECT order_id, COUNT(customer_id) AS customers_per_order
FROM orders GROUP BY order_id
HAVING COUNT(customer_id) <> 1;

৩ · Participation — total আর partial

Cardinality বলে সর্বোচ্চ। কিন্তু ডিজাইনে সর্বনিম্নও সমান জরুরি: একটি entity-কে কি সম্পর্কটিতে অংশ নিতেই হবে? এই নিয়মের নাম participation constraint.

একই সম্পর্কের দুই প্রান্তে participation আলাদা হতে পারে, আর সাধারণত হয়ও। places সম্পর্কে orders-এর দিকে total participation, customers-এর দিকে partial participation. বিভাগ–শিক্ষার্থী সম্পর্কে বিশ্ববিদ্যালয় যদি বলে “প্রত্যেক শিক্ষার্থী কোনো না কোনো বিভাগে”, তাহলে শিক্ষার্থীর দিক total; আর নতুন খোলা বিভাগে এখনো কেউ ভর্তি না হলে বিভাগের দিক partial.

ডেটায় partial participation খুঁজতে হলে সেই entity-গুলোকেও দেখতে হবে, যাদের কোনো সম্পর্ক নেই। সাধারণ JOIN শুধু মিল-পাওয়া সারি রাখে, তাই অর্ডারহীন গ্রাহক হারিয়ে যান। LEFT JOIN বাঁ দিকের টেবিলের প্রতিটি সারি রাখে; ডান দিকে মিল না পেলে সেখানে NULL বসায় (পুরো আলোচনা পর্ব ১৯-এ)। তারপর COUNT(o.order_id) শুধু non-NULL মান গোনে, তাই অর্ডারহীন গ্রাহকের জন্য ফল আসে 0:

-- প্রত্যেক গ্রাহক, অর্ডার না থাকলেও
SELECT c.customer_id, c.name, COUNT(o.order_id) AS orders_count
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.customer_id
GROUP BY c.customer_id, c.name
ORDER BY orders_count, c.customer_id;

-- অর্ডারের দিক: গ্রাহক ছাড়া কোনো অর্ডার আছে?
SELECT COUNT(*) AS orders_without_customer
FROM orders WHERE customer_id IS NULL;

একই প্রশ্ন বিশ্ববিদ্যালয়ে। প্রতিটি বিভাগে কতজন শিক্ষার্থী, আর এমন শিক্ষার্থী আছেন কি, যাঁর বিভাগ নেই?

-- বিভাগের দিক: সব বিভাগে কি শিক্ষার্থী আছে?
SELECT d.name, COUNT(s.student_id) AS students
FROM departments d
LEFT JOIN students s ON s.dept_id = d.dept_id
GROUP BY d.dept_id, d.name
ORDER BY d.dept_id;

-- শিক্ষার্থীর দিক: বিভাগহীন কেউ আছেন?
SELECT student_id, name FROM students WHERE dept_id IS NULL;

৪ · (min,max) notation আর crow's foot — তিন ভাষায় একই কথা

এ পর্যন্ত দুটি আলাদা তথ্য পেয়েছেন: সর্বোচ্চ (cardinality) আর সর্বনিম্ন (participation). এ দুটিকে একসাথে একটি সংখ্যা-জোড়ায় লেখার রীতিকে বলে structural constraint বা (min,max) notation. কোনো entity set E আর relationship R-এর রেখার পাশে (min,max) লেখা মানে: E-এর প্রতিটি entity R-এ অন্তত min বার, সর্বোচ্চ max বার অংশ নেয়। min = 0 মানে partial, min ≥ 1 মানে total; max = 1 মানে “এক”, max = N মানে “অনেক”।

গ্রাহক–অর্ডার সম্পর্কের নিয়ম লিখলে: একজন গ্রাহক ০ থেকে অনেক অর্ডার দেন → CUSTOMER-এর পাশে (0,N); প্রতিটি অর্ডার ঠিক একজন গ্রাহকের → ORDER-এর পাশে (1,1). একই নিয়ম অন্য দুটি জনপ্রিয় notation-এ কেমন দেখায়, পাশাপাশি দেখুন। Chen notation-এ entity আয়তক্ষেত্র, relationship রম্বস (diamond); crow's foot notation-এ relationship-এর আলাদা চিহ্ন নেই, শুধু একটি রেখা, যার দুই প্রান্তে ছোট চিহ্ন:

ছবির শেষ লাইনটিই এই অংশের সবচেয়ে বড় ফাঁদ। Chen-এর 1/N আর crow's foot-এর চিহ্ন পড়তে হয় “ওপারে তাকিয়ে” (look-across): ORDER-এর পাশের চিহ্ন বলে একটি CUSTOMER-এর বিপরীতে কতগুলো ORDER. কিন্তু (min,max) পড়তে হয় “নিজের দিকে তাকিয়ে” (look-here): ORDER-এর পাশের জোড়া বলে একটি ORDER নিজে কতবার অংশ নেয়। ফলে একই সম্পর্কে সংখ্যাগুলোর জায়গা উল্টে যায়। ধাপে ধাপে মিলিয়ে দেখুন:

এবার db-shop থেকে গ্রাহকের দিকের (min,max) সরাসরি মেপে দেখা যাক — প্রতিটি গ্রাহকের অর্ডার গুনে তার সর্বনিম্ন আর সর্বোচ্চ। ভেতরের কোয়েরিটি আগের অংশের LEFT JOIN-ই; বাইরেরটি তার ওপর MIN আর MAX নেয় (এমন কোয়েরির ভেতরে কোয়েরি — subquery — পর্ব ২১-এ বিস্তারিত):

-- প্রতিটি গ্রাহক places-এ কতবার? তার min আর max
SELECT MIN(n) AS min_orders, MAX(n) AS max_orders
FROM (SELECT COUNT(o.order_id) AS n
      FROM customers c
      LEFT JOIN orders o ON o.customer_id = c.customer_id
      GROUP BY c.customer_id);

৫ · Weak entity — যাকে একা চেনা যায় না

একটি ক্ষুদ্রঋণ প্রতিষ্ঠানের খাতা ভাবুন। Rokeya ৩০,০০০ টাকা ঋণ নিয়েছেন, ৩টি মাসিক কিস্তিতে শোধ করবেন; Jamal নিয়েছেন ১২,০০০ টাকা, ২টি কিস্তিতে। মাঠকর্মী অফিসে ফোন করে বললেন, “কিস্তি নং 2 জমা হয়েছে।” কার? Rokeya-র কিস্তি 2 আছে, Jamal-এরও আছে। শুধু কিস্তির নম্বর দিয়ে একটি কিস্তিকে চেনা যায় না; চেনা যায় “অমুক ঋণের কিস্তি নং 2” বললে।

এমন entity-কে বলে weak entity: যার নিজের attribute-গুলো দিয়ে একে আলাদা করে চেনা যায় না, চেনার জন্য অন্য একটি entity-র ওপর নির্ভর করতে হয়। যার ওপর নির্ভর করে, সেটি owner entity (বা identifying entity) — এখানে ঋণ। দুটিকে জোড়া সম্পর্কটি identifying relationship. আর weak entity-র যে attribute owner-এর ভেতরে তাকে আলাদা করে (কিস্তি নং), সেটি partial key বা discriminator. নিজের key আছে এমন সাধারণ entity-কে বলে strong entity.

Chen ডায়াগ্রামে weak entity আঁকা হয় দুই-রেখার আয়তক্ষেত্রে, identifying relationship দুই-রেখার রম্বসে, আর partial key-র নিচে ড্যাশ দেওয়া দাগ (সাধারণ key-র নিচে থাকে পূর্ণ দাগ):

আরও দুটি পরিচিত weak entity: অর্ডারের লাইন-আইটেম (অর্ডার 1001-এর লাইন 1, লাইন 2 — অন্য অর্ডারেরও লাইন 1 আছে), আর কর্মীর নির্ভরশীল সদস্য (dependent) — অফিসের স্বাস্থ্যবিমায় কর্মী 507-এর স্ত্রী আর ছেলে; এঁদের চেনা হয় “কর্মী 507-এর dependent, নাম Nila” দিয়ে, আর কর্মী চাকরি ছাড়লে বিমার এই রেকর্ডও যায়। নিচের ডায়াগ্রামে দেখুন কিস্তির key কীভাবে গড়ে ওঠে:

এবার আসল SQLite-এ। এই দুটি এডিটর নিজেদের ছোট schema বানায়: loans (loan_id, borrower, amount) আর installments (loan_id, inst_no, due_date, amount), যেখানে primary key (loan_id, inst_no) আর loan_id REFERENCES loans ON DELETE CASCADE. শুরুর ডেটা উপরের ডায়াগ্রামের পাঁচটি কিস্তি। প্রথমে দেখুন partial key-র অর্থ — নতুন ঋণের কিস্তি নং 1 চলে, কিন্তু একই ঋণে একই নম্বর দুবার চলে না:

-- নতুন ঋণ 3: তার প্রথম কিস্তির নম্বরও 1 — চলবে
INSERT INTO loans VALUES (3, 'Shila', 5000);
INSERT INTO installments VALUES (3, 1, '2025-08-01', 5000);
SELECT * FROM installments WHERE inst_no = 1 ORDER BY loan_id;

-- ঋণ 1-এর কিস্তি 3 আগেই আছে: বাতিল হবে
INSERT INTO installments VALUES (1, 3, '2025-10-01', 10000);

এখন existence dependency — ঋণ 1 মুছলে তার কিস্তির কী হয়:

-- owner (ঋণ 1) মুছলে weak entity-ও যায়
DELETE FROM loans WHERE loan_id = 1;

SELECT * FROM loans;
SELECT loan_id, COUNT(*) AS installments_left
FROM installments GROUP BY loan_id;

কখন weak entity, কখন surrogate key-সহ strong entity?

ER মডেলের তত্ত্বে প্রশ্নটি সহজ: entity-র নিজের কোনো key না থাকলে সেটি weak. কিন্তু টেবিল বানানোর সময় আপনি চাইলে একটি surrogate id দিয়ে যেকোনো weak entity-কে strong বানাতে পারেন। কোনটি বেছে নেবেন?

db-shop-এর order_items আসলে একটি weak-ধাঁচের টেবিল: তার key (order_id, product_id), যেখানে product_id-ই discriminator, আর অর্ডার ছাড়া লাইনের কোনো অর্থ নেই। যদি একই অর্ডারে একই পণ্য দুটি আলাদা দামে দুই লাইনে লেখার নিয়ম থাকত, তখন discriminator হতো একটি line_no.

৬ · Ternary relationship — তিন পক্ষের সম্পর্ক আর তার ফাঁদ

এ পর্যন্ত সব সম্পর্ক ছিল দুই পক্ষের — binary relationship. কিন্তু কিছু তথ্য তিনটি entity একসাথে না ধরলে বলাই যায় না। একটি হাসপাতালের ব্যবস্থাপত্র ভাবুন: “ডাক্তার Karim রোগী Babu-কে Omeprazole লিখেছেন।” এই একটি ঘটনায় তিন পক্ষ — ডাক্তার, রোগী, ওষুধ। এমন সম্পর্ককে বলে ternary relationship (degree ৩)। Chen ডায়াগ্রামে একটি রম্বস থেকে তিনটি রেখা তিনটি entity-তে যায়।

নতুনদের প্রায়ই মনে হয়, এটিকে তিনটি দুই-পক্ষের সম্পর্কে ভাঙলেই চলে: ডাক্তার–রোগী (কে কাকে দেখেছেন), রোগী–ওষুধ (কে কী খাচ্ছেন), ডাক্তার–ওষুধ (কে কী লেখেন)। দেখতে যুক্তিসংগত। কিন্তু এতে তথ্য হারায় — আর হাসপাতালে সেই হারানো তথ্য বিপজ্জনক। নিচের তিনটি ব্যবস্থাপত্র দিয়ে ধাপে ধাপে দেখুন:

একই পরীক্ষা SQLite-এ। এই এডিটরের setup-এ একটি prescribes (doctor, patient, medicine) টেবিল আর উপরের তিনটি সারি। কোডটি তিনটি binary টেবিল বানায় (CREATE TABLE … AS SELECT DISTINCT — একটি কোয়েরির ফল থেকে নতুন টেবিল), তারপর তিনটিকে join করে:

-- ternary থেকে তিনটি binary
CREATE TABLE dp AS SELECT DISTINCT doctor, patient FROM prescribes;
CREATE TABLE pm AS SELECT DISTINCT patient, medicine FROM prescribes;
CREATE TABLE dm AS SELECT DISTINCT doctor, medicine FROM prescribes;

-- তিনটি binary জুড়ে আসলটি ফেরত পাওয়ার চেষ্টা
SELECT dp.doctor, dp.patient, pm.medicine
FROM dp
JOIN pm ON pm.patient = dp.patient
JOIN dm ON dm.doctor = dp.doctor AND dm.medicine = pm.medicine
ORDER BY dp.doctor, dp.patient;

উল্টো দিকটিও সত্য — আর ternary-তে cardinality-র ফাঁদ

তার মানে কি সবসময় ternary-ই ভালো? না। কখনো binary এমন তথ্য রাখে, যা ternary পারে না। “Dr. Sultana Omeprazole লেখার অনুমতিপ্রাপ্ত” — এখনো কোনো রোগীকে লেখেননি — এই তথ্য prescribes-এ রাখা যায় না, কারণ সেখানে প্রতিটি সারিতে একজন রোগী লাগবে। তাই সঠিক ডিজাইনে প্রায়ই দুটোই থাকে: ঘটনার জন্য ternary, আর আলাদা স্বাধীন নিয়মের জন্য binary. আবার কখনো ternary সত্যিই তিনটি binary-তে নিখুঁতভাবে ভাঙা যায় — যদি ব্যবসার একটি বিশেষ নিয়ম থাকে (“কোনো ডাক্তার কোনো রোগীকে দেখেন, রোগী কোনো ওষুধ পান, আর ডাক্তার সেই ওষুধ লেখেন — তাহলে ডাক্তার রোগীকে সেটি লিখেছেনই”)। এই নিয়মকে বলে join dependency, আর এটি পর্ব ৩৭-এর 5NF-এর বিষয়।

Ternary-তে cardinality পড়াও কঠিন। ধরুন C. J. Date-এর পাঠ্যবইয়ের বিখ্যাত supplier–part–project উদাহরণ: “সরবরাহকারী S, প্রকল্প J-কে যন্ত্রাংশ P দেয়।” PART-এর রেখায় “1” লেখা মানে কী? Look-across ধরনে পড়লে এর মানে: প্রতিটি (supplier, project) জোড়ার জন্য সর্বোচ্চ একটি part — অর্থাৎ একটি সরবরাহকারী একটি প্রকল্পকে কেবল একটি যন্ত্রাংশই দিতে পারে। প্রায় কেউ এটা বোঝাতে চান না; তাঁরা সাধারণত ভাবেন “প্রতিটি part একটি supplier-এর”, যা আসলে একটি আলাদা binary নিয়ম। এই বিভ্রান্তি এড়াতে Silberschatz–Korth–Sudarshan-এর পাঠ্যবই পরামর্শ দেয়, একটি ternary বা বড় সম্পর্কে সর্বোচ্চ একটি তীর আঁকতে — একাধিক তীরের অর্থ দুই রকম পড়া যায়। (min,max) notation এখানে বেশি পরিষ্কার, কারণ সেটি শুধু বলে “প্রতিটি part কতবার অংশ নেয়”। আর crow's foot-এ ternary আঁকার সরাসরি উপায় নেই; সেখানে মাঝখানে একটি associative entity (যেমন PRESCRIPTION) বানিয়ে তিনটি 1:N রেখা টানা হয়।

৭ · Cardinality থেকে টেবিল — foreign key কোথায় বসবে

এই পর্বের সব সিদ্ধান্ত শেষ পর্যন্ত টেবিলের নকশায় গিয়ে দাঁড়ায়। পুরো mapping-এর নিয়ম পর্ব ১০-এ (ER থেকে টেবিল — mapping-এর নিয়ম); এখানে শুধু মূল ছবিটি, যাতে বোঝেন cardinality কেন এত গুরুত্বপূর্ণ:

1:N-এ foreign key কেন “অনেক” দিকে? অংশ ২-এর প্রথম এডিটর মনে করুন: orders-এর প্রতিটি সারিতে customer_id-এর একটিই ঘর, তাই “এক” দিকটি আপনাআপনি রক্ষা পায়। উল্টো করে customers-এ order_id রাখলে Rahim-এর তিনটি অর্ডারের জন্য তিনটি ঘর লাগত — কয়টি ঘর রাখবেন? এজন্যই M:N-এ কোনো দিকেই রাখা যায় না, আলাদা টেবিল লাগে। db-shop-এর order_items ঠিক এমন একটি junction table — অর্ডার আর পণ্যের M:N সম্পর্ক:

-- এক দিক: একটি অর্ডারে একাধিক পণ্য
SELECT order_id, COUNT(*) AS products
FROM order_items GROUP BY order_id
HAVING COUNT(*) > 1;

-- অন্য দিক: একটি পণ্য কয়টি অর্ডারে (০ হলেও)
SELECT p.product_id, p.name, COUNT(oi.order_id) AS in_orders
FROM products p
LEFT JOIN order_items oi ON oi.product_id = p.product_id
GROUP BY p.product_id, p.name
ORDER BY in_orders DESC, p.product_id;

বিশ্ববিদ্যালয়ে শিক্ষার্থী–কোর্সের M:N সম্পর্কের junction table হলো enrollments, যার key (student_id, course_id, term). একজন শিক্ষার্থী একই কোর্স দুই term-এ নিতে পারেন, তাই এখানে COUNT(DISTINCT …) দিয়ে আলাদা কোর্স বা শিক্ষার্থী গোনা হয়েছে:

-- একটি কোর্সে কতজন শিক্ষার্থী?
SELECT course_id, COUNT(DISTINCT student_id) AS students
FROM enrollments GROUP BY course_id
ORDER BY students DESC, course_id;

-- একজন শিক্ষার্থী কয়টি কোর্সে?
SELECT student_id, COUNT(DISTINCT course_id) AS courses
FROM enrollments GROUP BY student_id
ORDER BY courses DESC, student_id;

শেষে 1:1 — নাগরিক আর NID কার্ড। এই এডিটরের ছোট schema: citizens (citizen_id, name) আর nid_cards (card_no, citizen_id, issued_on), যেখানে card_no primary key, আর citizen_id NOT NULL UNIQUE REFERENCES citizens. Rokeya আর Jamal-এর কার্ড আছে, Shila-র এখনো নেই:

-- Shila (3) প্রথম কার্ড পেলেন: চলবে
INSERT INTO nid_cards VALUES ('NID-1003', 3, '2024-01-20');
SELECT c.name, n.card_no FROM citizens c
JOIN nid_cards n ON n.citizen_id = c.citizen_id;

-- Rokeya (1)-র জন্য দ্বিতীয় কার্ড: 1:1 ভাঙবে
INSERT INTO nid_cards VALUES ('NID-1004', 1, '2025-05-05');

৮ · ইতিহাস — Chen-এর রম্বস থেকে কাকের পা

৯ · AI-এর যুগে cardinality

AI-কে “একটি স্কুল ম্যানেজমেন্ট সিস্টেমের ER ডায়াগ্রাম দাও” বললে মুহূর্তে সুন্দর তালিকা আসে। কিন্তু AI আপনার ব্যবসার নিয়ম জানে না — সে অনুমান করে, আর অনুমানগুলো প্রায়ই চুপচাপ ভুল। Cardinality-র ভুল টেবিল চালু হওয়ার পরে ধরা পড়লে schema বদলাতে হয়, যা সবচেয়ে ব্যয়বহুল সংশোধন। AI প্রায়ই যা করে:

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

• প্রতিটি সম্পর্কে দুই দিকের প্রশ্নের উত্তর আমি ব্যবসার মানুষের কাছ থেকে নিয়েছি, অনুমান থেকে নয়
• প্রতিটি 1:N-এর foreign key “অনেক” দিকে, আর total হলে NOT NULL
• প্রতিটি M:N-এর জন্য junction table, দুটি foreign key আর composite key আছে
• প্রতিটি 1:1-এর foreign key-তে UNIQUE আছে, আর দ্বিতীয় সারি ঢোকানোর পরীক্ষা ত্রুটি দিয়েছে
• Weak entity-র key-তে owner-এর key আছে (বা surrogate হলে UNIQUE), আর ON DELETE নিয়ম ভেবে বেছেছি
• নমুনা ডেটায় LEFT JOIN + COUNT(column) দিয়ে ০-অংশগ্রহণের entity খুঁজে নিয়মের সাথে মিলিয়েছি