Relational model — relation, tuple, attribute আর domain

১ · Codd-এর ধারণা — ডেটাকে শুধু টেবিল হিসেবে দেখা

আগের পর্বে (পর্ব ০৪) দেখেছেন, ১৯৬০-এর দশকের ডেটাবেসগুলো ছিল hierarchical বা network ধরনের। সেখানে ডেটা খুঁজতে প্রোগ্রামারকে রেকর্ড থেকে রেকর্ডে “হাঁটতে” হতো — আগে এই অফিসের রেকর্ড, তারপর তার নিচের কর্মচারী, তারপর তার বেতনের রেকর্ড। ডেটা কোন পথে সাজানো আছে, সেটা প্রোগ্রামের ভেতরেই লেখা থাকত। সাজানোর পথ বদলালে প্রোগ্রামও নতুন করে লিখতে হতো।

IBM-এর গবেষক Edgar F. Codd (সবাই ডাকতেন Ted) এই সমস্যার একটি সরল আর সাহসী সমাধান দিলেন। তাঁর মূল কথা তিনটি:

1. সব ডেটা একই রূপে রাখুন — টেবিলে। কোনো লুকানো pointer নেই, কোনো “পথ” নেই। দুটি টেবিলের সম্পর্ক বোঝানো হয় শুধু মান দিয়ে — যেমন students-এর dept_id কলামে 1 লেখা মানে CSE বিভাগ।
2. প্রশ্ন করুন “কী চাই” বলে। “২০২১ ব্যাচের CSE শিক্ষার্থীদের নাম চাই” — কীভাবে খুঁজবে, সেই সিদ্ধান্ত DBMS নেবে।
3. ভিত্তি হোক গণিত। Set theory আর logic-এর ওপর দাঁড়ানো বলে প্রতিটি কোয়েরির অর্থ নিখুঁতভাবে বলা যায়, আর একটি কোয়েরিকে অন্য সমান কোয়েরিতে বদলে দ্রুত চালানো যায়।

২ · ছয়টি শব্দ — relation, tuple, attribute, domain, degree, cardinality

Relational model-এর নিজস্ব কিছু শব্দ আছে। বইয়ে, বিশ্ববিদ্যালয়ের প্রশ্নে আর চাকরির পরীক্ষায় এই শব্দগুলোই আসে। অথচ প্রতিটির একটি সহজ, চেনা প্রতিশব্দ আছে:

এই পর্বের বেশিরভাগ উদাহরণ চলবে বিশ্ববিদ্যালয়ের নমুনা ডেটাবেস db-uni-এর students টেবিলে। এর পাঁচটি কলাম: student_id (রোল নম্বরের মতো পরিচয় নম্বর), name (নাম), dept_id (বিভাগের নম্বর — departments টেবিলের দিকে নির্দেশ করে), batch (ভর্তির বছর) আর cgpa. নিচের ডায়াগ্রামে ছয়টি শব্দ একে একে টেবিলের গায়ে বসিয়ে দেখুন:

এবার একই দুটি সংখ্যা SQL দিয়ে বের করি। নিচের এডিটরটি এই পাতাতেই আসল SQLite চালায়। “চালান” চাপুন; চাইলে কোড বদলে আবার চালান।

-- cardinality: কয়টি tuple (সারি)?
SELECT COUNT(*) AS cardinality FROM students;

-- degree: কয়টি attribute (কলাম)? — SQLite-এর catalog থেকে
SELECT COUNT(*) AS degree FROM pragma_table_info('students');

-- attribute-গুলোর নাম আর ঘোষিত টাইপ
SELECT name, type FROM pragma_table_info('students');

PostgreSQL, MySQL বা SQL Server-এ একই কাজ হয় SQL স্ট্যান্ডার্ডের information_schema দিয়ে। এটি এই পাতায় চলবে না, শুধু চিনে রাখুন:

-- degree: students টেবিলের কলাম সংখ্যা
SELECT COUNT(*) AS degree
FROM information_schema.columns
WHERE table_name = 'students';

৩ · Relation schema বনাম relation instance

একটি টেবিলের দুটি দিক আছে — তার কাঠামো আর তার ভেতরের ডেটা। কাঠামোকে বলে relation schema; লেখা হয় relation-এর নাম আর attribute-গুলোর তালিকা দিয়ে:

আরও নিখুঁতভাবে লিখলে প্রতিটি attribute-এর domain-ও বলে দেওয়া হয়: STUDENT(student_id: INTEGER, name: TEXT, dept_id: INTEGER, batch: INTEGER, cgpa: REAL). সাধারণ সংকেতে একটি schema লেখা হয় R(A₁, A₂, …, A_n) — এখানে R নাম, A_i attribute, আর n হলো degree. Primary key-র নিচে সাধারণত দাগ টানা হয় (student_id) — key নিয়ে পরের পর্বে।

আর কোনো এক মুহূর্তে টেবিলে যে tuple-গুলো আছে, তাদের সেটকে বলে relation instance (বা relation state); লেখা হয় r(R). আজ সকালের students টেবিলে আটজন — এটি একটি instance. দুপুরে একজন নতুন শিক্ষার্থী ভর্তি হলে নতুন instance তৈরি হলো, কিন্তু schema একই রইল।

নিজে দেখুন: নতুন একটি tuple ঢোকালে cardinality বদলায়, degree বদলায় না।

-- নতুন শিক্ষার্থী ভর্তি: instance বদলাল
INSERT INTO students VALUES (2401, 'Ishrat Jahan', 1, 2024, 3.65);

SELECT COUNT(*) AS cardinality FROM students;
SELECT COUNT(*) AS degree FROM pragma_table_info('students');

পর্ব ০৩-এর three-schema architecture-এর সঙ্গে এর মিল লক্ষ করুন: schema হলো “intension” (কী রকম ডেটা থাকতে পারে), instance হলো “extension” (এই মুহূর্তে আসলে কী আছে)। পুরোনো বইয়ে এই দুটি শব্দও পাবেন।

৪ · গাণিতিক সংজ্ঞা — Cartesian product-এর একটি subset

“Relation” শব্দটি Codd গণিত থেকে নিয়েছিলেন। স্কুলের গণিতে হয়তো পড়েছেন — দুটি set A আর B-র Cartesian product A × B হলো সব সম্ভাব্য জোড়া (a, b)-এর set, আর A × B-এর যেকোনো subset-ই A থেকে B-তে একটি relation. Codd এই ধারণাকে দুটি থেকে n-টি set-এ বাড়িয়ে দিলেন।

অর্থাৎ Cartesian product হলো “সম্ভাব্য সব কথা”, আর relation হলো তার মধ্যে “যে কথাগুলো এই মুহূর্তে সত্য”। (2101, CSE) মানে “2101 নম্বর শিক্ষার্থী CSE-তে পড়েন” — একটি দাবি। টেবিলে tuple-টি থাকা মানে দাবিটি সত্য। একটি ছোট উদাহরণ ধাপে ধাপে দেখুন:

ধাপ ৫-এর হিসাবটি একটি সাধারণ সত্যের বিশেষ রূপ। প্রমাণটি ছোট:

সংখ্যাটি কত দ্রুত বাড়ে, দেখুন: মাত্র ১০টি id আর ৪টি বিভাগ হলে N = ৪০, আর সম্ভাব্য relation 2⁴⁰ — এক লক্ষ কোটিরও বেশি। ডেটাবেস ডিজাইনের কাজ হলো এই বিশাল সম্ভাবনার মধ্য থেকে শুধু অর্থবহগুলোকে অনুমতি দেওয়া।

SQL-এ Cartesian product বানায় CROSS JOIN (পর্ব ২০-এ বিস্তারিত)। নিচের এডিটরে দুটি ছোট “domain টেবিল” আগে থেকেই বানানো আছে — d_id (কলাম student_id) আর d_dept (কলাম dept).

-- D1 × D2: সম্ভাব্য সব tuple
SELECT student_id, dept
FROM d_id CROSS JOIN d_dept
ORDER BY student_id, dept;

-- একটি relation = এর একটি subset (r1)
SELECT student_id, dept
FROM d_id CROSS JOIN d_dept
WHERE (student_id = 2101 AND dept = 'CSE')
   OR (student_id = 2102 AND dept = 'EEE');

Tuple-কে ক্রমের বদলে নাম দিয়ে দেখা

গণিতের সংজ্ঞায় tuple-এর মানগুলো অবস্থান দিয়ে চেনা হয় — প্রথম মান D₁ থেকে, দ্বিতীয়টি D₂ থেকে। কিন্তু ডেটাবেসে আমরা কলামকে নাম দিয়ে ডাকি। তাই বেশিরভাগ পাঠ্যবই একটি দ্বিতীয় সংজ্ঞাও দেয়: tuple হলো একটি ফাংশন, যা প্রতিটি attribute-নামকে তার domain-এর একটি মানে নিয়ে যায় — t(name) = 'Arif Hossain', t(cgpa) = 3.75. এই দৃষ্টিতে attribute-এর কোনো ক্রম থাকে না; {name ↦ Arif, cgpa ↦ 3.75} আর {cgpa ↦ 3.75, name ↦ Arif} একই tuple. সংকেতে t[cgpa] বা t.cgpa লেখা হয়। পরের অংশের একটি বৈশিষ্ট্য ঠিক এখান থেকেই আসে।

৫ · Relation-এর চারটি বৈশিষ্ট্য

Relation যেহেতু একটি set, তাই set-এর নিয়ম থেকেই কয়েকটি বৈশিষ্ট্য সরাসরি আসে। পরীক্ষায় এগুলো প্রায়ই জিজ্ঞেস করা হয়:

চতুর্থটি অন্য তিনটির মতো set theory থেকে আপনাআপনি আসে না — এটি Codd-এর সচেতন নকশা। ঘরে একাধিক মান রাখলে কোয়েরির ভাষা জটিল হয়ে যায়, তাই তিনি বললেন প্রতিটি মান হবে atomic. এই শর্ত মানা relation-কে বলা হয় first normal form (1NF)-এ আছে। Normalization-এর পুরো গল্প পর্ব ৩৬-এ; এখানে শুধু মূল ছবিটি দেখুন:

৬ · SQL টেবিল কোথায় বিশুদ্ধ relation নয় — bag semantics

এখন একটি গুরুত্বপূর্ণ সত্য, যা অনেক বইয়ে চাপা পড়ে যায়: SQL-এর টেবিল আসলে relation নয়। তিনটি জায়গায় SQL গণিতের নিয়ম থেকে সরে এসেছে:

যে সংগ্রহে একই সদস্য একাধিকবার থাকতে পারে, গণিতে তাকে বলে multiset বা bag. SQL-এর এই আচরণকে তাই বলে bag semantics. প্রথমে কোয়েরির ফলে দেখুন:

-- bag: প্রতিটি শিক্ষার্থীর জন্য একটি করে সারি
SELECT batch FROM students;

-- set: duplicate বাদ
SELECT DISTINCT batch FROM students;

শুধু কোয়েরির ফল নয়, টেবিলেও duplicate জমতে পারে — যদি টেবিলে কোনো key না থাকে। ধরুন হাজিরা রাখার একটি টেবিল attendance; এর দুটি কলাম student_id আর day, কোনো key নেই:

CREATE TABLE attendance (student_id INTEGER, day TEXT);

-- ভুল করে একই হাজিরা দুবার
INSERT INTO attendance VALUES (2101, '2025-10-01');
INSERT INTO attendance VALUES (2101, '2025-10-01');

SELECT * FROM attendance;
SELECT COUNT(*) AS rows_now FROM attendance;

সমাধান হলো টেবিলে একটি key ঘোষণা করা। তাহলে DBMS নিজেই set-এর নিয়ম পাহারা দেয়। নিচের কোডটি ইচ্ছা করে error দেখানোর জন্য:

CREATE TABLE attendance2 (
  student_id INTEGER,
  day        TEXT,
  PRIMARY KEY (student_id, day)
);
INSERT INTO attendance2 VALUES (2101, '2025-10-01');
INSERT INTO attendance2 VALUES (2101, '2025-10-01');  -- দ্বিতীয়বার

তৃতীয় পার্থক্য — কলামের ক্রম। তত্ত্বে কলামের ক্রম নেই, আর কোয়েরিতে আপনি যেকোনো ক্রমে কলাম চাইতে পারেন:

SELECT student_id, name FROM students WHERE batch = 2023;

-- একই তথ্য, অন্য কলাম-ক্রম
SELECT name, student_id FROM students WHERE batch = 2023;

৭ · NULL — “মান নেই”, আর তার তিন অর্থ

db-uni-তে Fahim Karim-এর cgpa ঘরটি খালি, আর Habib Ullah-র dept_id ঘরটি খালি। এই “খালি”-র নাম NULL. NULL কোনো মান নয় — শূন্যও নয়, ফাঁকা লেখা ''-ও নয়। এটি একটি চিহ্ন, যা বলে “এখানে কোনো মান নেই।” কিন্তু কেন নেই, সেটা NULL বলে না। অন্তত তিনটি আলাদা কারণ হতে পারে:

তিনটি অর্থের জন্য একটিই চিহ্ন — এটাই NULL-এর মূল দুর্বলতা। তার চেয়েও বড় ব্যাপার হলো তুলনা। “Fahim-এর CGPA কি 3.5-এর বেশি?” — উত্তর “হ্যাঁ” বা “না” নয়, উত্তর “জানি না”। তাই SQL-এ NULL-এর সঙ্গে যেকোনো তুলনার ফল হয় তৃতীয় একটি মান: UNKNOWN. আর WHERE শুধু সেই সারিগুলো রাখে, যেখানে শর্ত TRUE — UNKNOWN বাদ পড়ে যায়। এবার সেই বিখ্যাত ফাঁদটি দেখুন:

-- ভুল: কিছুই আসে না!
SELECT name FROM students WHERE cgpa = NULL;

-- ঠিক
SELECT name FROM students WHERE cgpa IS NULL;

-- কেন? NULL-এর সঙ্গে তুলনার ফল নিজেই NULL
SELECT NULL = NULL AS eq, NULL <> NULL AS ne, NULL IS NULL AS is_null;

NULL শুধু =-কেই নয়, গোনা আর হিসাবকেও প্রভাবিত করে। আরেকটি চমক দেখুন — একটি শর্ত, যা “সবসময় সত্য” হওয়ার কথা:

SELECT COUNT(*)       AS all_rows,
       COUNT(cgpa)    AS has_cgpa,
       COUNT(dept_id) AS has_dept
FROM students;

-- "৩.৫-এর বেশি অথবা ৩.৫ বা কম" — সবাই তো পড়ার কথা?
SELECT COUNT(*) AS covered FROM students
WHERE cgpa > 3.5 OR cgpa <= 3.5;

SELECT name, dept_id, cgpa FROM students
WHERE cgpa IS NULL OR dept_id IS NULL;

একটি সিস্টেম-ভেদ জেনে রাখুন: Oracle-এ ফাঁকা string ''-কেই NULL ধরা হয়, অথচ PostgreSQL, MySQL, SQLite আর SQL Server-এ '' একটি সাধারণ মান। তাই একটি ডেটাবেস থেকে আরেকটিতে ডেটা সরালে “খালি নাম”-এর সারিগুলোর আচরণ বদলে যেতে পারে।

৮ · Relational database schema — অনেক relation-এর একটি নকশা

একটি টেবিল দিয়ে বিশ্ববিদ্যালয় চলে না। বিভাগ, শিক্ষক, শিক্ষার্থী, কোর্স, ভর্তি — প্রত্যেকটির আলাদা relation লাগে। এই relation schema-গুলোর সেটকে (সঙ্গে তাদের নিয়মগুলো) বলে relational database schema: S = {R₁, R₂, …, R_m}. db-uni-র schema লিখলে:

DEPARTMENTS (dept_id, name, building)
INSTRUCTORS (instructor_id, name, dept_id, salary, mentor_id)
STUDENTS    (student_id, name, dept_id, batch, cgpa)
COURSES     (course_id, title, dept_id, credits, instructor_id)
ENROLLMENTS (student_id, course_id, term, grade)

আর একই schema ছবিতে আঁকলে তাকে বলে schema diagram. প্রতিটি তীর একটি foreign key — “এই কলামের মান ওই টেবিলের key-তে থাকতে হবে”:

খেয়াল করুন, তীরগুলো কোনো pointer নয় — শুধু মান মেলানোর নিয়ম। একটি ভর্তির সারি থেকে মান মিলিয়ে মিলিয়ে কীভাবে পুরো ছবিটি পাওয়া যায়, ধাপে ধাপে দেখুন:

Key-র এক ঝলক

Schema-র ছবিতে দুটি নতুন শব্দ এসেছে। Primary key হলো এমন এক বা একাধিক attribute, যার মান দিয়ে একটি tuple-কে অনন্যভাবে চেনা যায় — দুটি tuple-এর key কখনো এক হয় না। Foreign key হলো এমন attribute, যার মান অন্য (বা একই) relation-এর key-তে থাকতেই হবে। অংশ ৪-এর r2-এর মতো অর্থহীন instance আটকানো, আর অংশ ৬-এর duplicate হাজিরা থামানো — দুটোরই হাতিয়ার এই key. Super key, candidate key, primary key আর foreign key-র নিখুঁত সংজ্ঞা, প্রমাণ আর SQL — সব পরের পর্বে (পর্ব ০৬)।

৯ · Codd-এর ১২ নিয়ম — আসলে ১৩টি, আর কেউ পুরোপুরি মানে না

১৯৮০-এর দশকের শুরুতে relational ধারণা জনপ্রিয় হতেই অনেক কোম্পানি তাদের পুরোনো পণ্যের গায়েও “relational” লেবেল লাগাতে শুরু করে। বিরক্ত হয়ে Codd ১৯৮৫ সালে Computerworld পত্রিকায় দুটি প্রবন্ধ লেখেন, যেখানে একটি DBMS-কে সত্যিকারের relational বলার জন্য নিয়মের একটি তালিকা দেন। নাম “১২ নিয়ম” হলেও নম্বর শুরু হয় ০ থেকে — তাই আসলে নিয়ম ১৩টি। সবগুলো মুখস্থ করার দরকার নেই; গুরুত্বপূর্ণগুলো নিচে:

নিয়ম ৪ এখনই পরখ করা যায়। SQLite তার সব টেবিলের বিবরণ রাখে sqlite_master নামের একটি টেবিলে — আর সেটি সাধারণ SELECT দিয়েই পড়া যায়:

-- catalog-ও একটি টেবিল (Codd-এর নিয়ম ৪)
SELECT type, name
FROM sqlite_master
WHERE type = 'table'
ORDER BY name;

১০ · AI-এর যুগে relational ধারণা কেন জরুরি

আজ ChatGPT বা অন্য যেকোনো AI কয়েক সেকেন্ডে SQL লিখে দেয়। কোয়েরিগুলো সাধারণত চলেও। সমস্যা হলো, এই পর্বের তিনটি বিষয় — duplicate, NULL আর কলামের অর্থ — ঠিক সেখানেই AI সবচেয়ে বেশি ভুল করে, আর ভুলগুলো error দেয় না, শুধু ভুল সংখ্যা দেয়।

AI সাধারণত যেসব ভুল করে

AI-এর লেখা SQL হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি টেবিল আর কলামের নাম আসল schema-র সঙ্গে মিলিয়েছি — একটিও বানানো নাম নেই
• যেসব কলামে NULL থাকতে পারে, সেগুলোর প্রতিটি শর্তে NULL-এর সারিগুলো কোথায় যাচ্ছে, ভেবে দেখেছি
• নমুনা ডেটায় চালিয়ে COUNT(*) আর COUNT(DISTINCT …) মিলিয়ে দেখেছি — duplicate গোনা হচ্ছে না
• অন্তত একটি ফল হাতে হিসাব করে মিলিয়েছি (যেমন ৮ জনের মধ্যে কে কে আসা উচিত)
• ক্রম দরকার হলে ORDER BY আছে; নতুন টেবিলে primary key আছে