Key আর integrity constraint — super, candidate, primary আর foreign

১ · Key কেন লাগে — ঠিক একজনকে চেনা

ধরুন একটি মুদি দোকানের বাকির খাতা। দোকানদার লিখে রাখেন: “রহিম — ৫৬০ টাকা”। কিছুদিন পর দেখা গেল পাড়ায় রহিম নামে তিনজন। কোন রহিমের কাছে টাকা পাওনা? খাতা আর বলতে পারছে না। দোকানদার তখন নামের পাশে লিখতে শুরু করলেন “রহিম (মসজিদের পাশের বাসা)”। এটিই key-এর আদি রূপ — এমন একটি তথ্য, যা দিয়ে একজন মানুষকে ঠিক একজন হিসেবে চেনা যায়।

আমাদের চারপাশে এমন “চেনার নম্বর” অনেক। জাতীয় পরিচয়পত্রের NID নম্বর একজন নাগরিককে চেনায়। বিশ্ববিদ্যালয়ের রোল বা student ID একজন শিক্ষার্থীকে চেনায়। bKash-এ টাকা পাঠাতে আপনি নাম লেখেন না, লেখেন মোবাইল নম্বর — কারণ নম্বরটি একটি নির্দিষ্ট অ্যাকাউন্টকেই বোঝায়। ট্রেনের টিকিটে থাকে PNR বা টিকিট নম্বর, আর লাইব্রেরির বইয়ে থাকে accession নম্বর।

পর্ব ৫-এ দেখেছেন, relational model-এ ডেটা থাকে relation বা টেবিলে, প্রতিটি সারি একটি tuple, আর প্রতিটি কলাম একটি attribute. Relation গণিতের অর্থে একটি সেট, তাই তাত্ত্বিকভাবে দুটি হুবহু একই সারি থাকতে পারে না। কিন্তু শুধু “হুবহু একই নয়” যথেষ্ট নয়। আমাদের দরকার এমন একটি ছোট অংশ, যার মান দেখেই বলা যায় কোন সারির কথা হচ্ছে। সেই অংশটিই key.

Key না থাকলে কী কী গোলমাল হয়, তা তালিকা করে দেখা যাক:

• Update কাকে ছোঁবে, জানা যায় না। “রহিমের ঠিকানা বদলান” বললে তিন রহিমেরই ঠিকানা বদলে যেতে পারে।
• একই মানুষ দুবার ঢুকে পড়ে। একজন গ্রাহক দুবার নিবন্ধন করলে দুটি অ্যাকাউন্ট, দুটি বাকির হিসাব — কোনটি সঠিক, কেউ জানে না।
• অন্য টেবিল থেকে আঙুল তোলা যায় না। একটি অর্ডার “কার”, সেটি লিখতে হলে গ্রাহককে নিশ্চিতভাবে চেনাতে হবে। এই আঙুল তোলাই foreign key, যা অংশ ৫-এ দেখবেন।

এই পর্বের সব লাইভ 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 — কোন অর্ডারে কোন পণ্য কতটি)। প্রতিটি এডিটর নিচের “নমুনা ডেটা” বাক্সে পুরো টেবিলগুলো দেখায়। প্রতিবার চালালে ডেটাবেস নতুন করে তৈরি হয়, তাই নির্ভয়ে ভাঙচুর করুন।

২ · Superkey আর candidate key — কোন কলামগুলো সারি চেনায়

এবার সংজ্ঞাগুলো নির্দিষ্ট করি। ধরুন একটি relation schema R, যার attribute-গুলোর সেট হলো {A₁, A₂, …, Aₙ}. R-এর যেকোনো বৈধ অবস্থায় (অর্থাৎ ব্যবসার নিয়ম মেনে যত রকম ডেটা আসতে পারে, তার প্রতিটিতে) কোনো দুটি আলাদা সারির মান যদি একটি attribute-সেট K-তে কখনো হুবহু না মেলে, তাহলে K একটি superkey.

দুটি শব্দ খেয়াল করুন। প্রথমত “যেকোনো বৈধ instance” — key হলো schema-র ধর্ম, আজকের ডেটার নয়। দ্বিতীয়ত “minimal” মানে সবচেয়ে কম সংখ্যক attribute নয়, বরং “এর থেকে কিছু বাদ দেওয়া যায় না”। একটি টেবিলের একটি candidate key-তে ১টি attribute আর অন্যটিতে ৩টি থাকতে পারে, দুটিই minimal. নিচের ডায়াগ্রামে একটি ছোট টেবিলে একটির পর একটি attribute-সেট যাচাই করে দেখুন:

দুটি সহজ কিন্তু জরুরি সত্য

সত্য ১ — superkey-র যেকোনো বড় সেটও superkey. K superkey হলে আর K ⊆ K′ হলে, দুটি সারি K′-তে মিলতে হলে আগে K-তে মিলতে হবে — যা অসম্ভব। তাই K′-ও superkey. এজন্যই {roll} superkey হওয়ায় {roll, name}, {roll, dept}, {roll, name, phone, dept} সবই superkey.

সত্য ২ — প্রতিটি relation-এর অন্তত একটি candidate key আছে. প্রমাণ: relation একটি সেট, তাই দুটি সারি সব attribute-এ মিলতে পারে না — অর্থাৎ সব attribute-এর সেট R নিজেই একটি superkey. এখন R থেকে একটি একটি করে attribute বাদ দিতে থাকুন, যতক্ষণ বাকি অংশ superkey থাকে। Attribute সংখ্যা সসীম, তাই এই প্রক্রিয়া কোথাও থামবেই, আর যেখানে থামে সেখানে আর কিছু বাদ দেওয়া যায় না — সেটিই একটি minimal superkey, অর্থাৎ candidate key. ∎

এই দুই সত্য থেকে superkey গোনার একটি সুন্দর কৌশল আসে। ধরুন R-এর ৪টি attribute A, B, C, D আর একমাত্র candidate key {A}. তাহলে superkey হলো ঠিক সেই সেটগুলো যাতে A আছে। বাকি তিনটির প্রতিটি থাকতেও পারে, না-ও পারে — তাই 2³ = ৮টি superkey. সাধারণভাবে n টি attribute আর একটিমাত্র একক-attribute candidate key থাকলে superkey 2ⁿ⁻¹টি। একাধিক candidate key থাকলে inclusion–exclusion লাগে — অনুশীলন ১-এ করবেন।

SQL দিয়ে duplicate খোঁজা — candidate key-র প্রাথমিক পরীক্ষা

তবু বাস্তবে একটি পুরোনো টেবিল হাতে পেলে প্রথম কাজ হলো দেখা, কোন কলাম বা কলামের জোড়ায় duplicate আছে। এর জন্য GROUP BY দিয়ে একই মানের সারিগুলো এক দলে আনুন, তারপর HAVING COUNT(*) > 1 দিয়ে শুধু সেই দলগুলো রাখুন যেখানে একাধিক সারি। (GROUP BY আর HAVING বিস্তারিত পর্ব ১৮-এ; এখানে শুধু এই একটি ব্যবহার দেখুন।) কোনো সারি না এলে এই ডেটায় duplicate নেই।

-- কোন কলাম (বা কলামের জোড়া) এই ডেটায় duplicate-মুক্ত?
SELECT city, COUNT(*) AS n
FROM customers GROUP BY city HAVING COUNT(*) > 1;

SELECT name, COUNT(*) AS n
FROM customers GROUP BY name HAVING COUNT(*) > 1;

SELECT order_id, COUNT(*) AS n
FROM order_items GROUP BY order_id HAVING COUNT(*) > 1;

SELECT order_id, product_id, COUNT(*) AS n
FROM order_items GROUP BY order_id, product_id HAVING COUNT(*) > 1;

৩ · Primary key, alternate key আর composite key

একটি টেবিলে একাধিক candidate key থাকতে পারে — students-এর {roll} আর {phone}, বা customers-এর {customer_id} আর {phone}. ডিজাইনার এদের মধ্যে একটিকে বেছে নেন primary key হিসেবে: এটিই হবে সারির “অফিসিয়াল ঠিকানা”, অন্য টেবিল এটি দিয়েই এই সারির দিকে আঙুল তুলবে। বাকি candidate key-গুলো হয় alternate key (বা secondary key); SQL-এ এদের ওপর UNIQUE (আর সাধারণত NOT NULL) বসিয়ে অনন্যতা রক্ষা করা হয়।

ভালো primary key-র তিন গুণ

এই তিন গুণে customers-এর customer_id জেতে: পূর্ণসংখ্যা, দোকান নিজে দেয়, কখনো বদলায় না, প্রত্যেক গ্রাহকের প্রথম দিন থেকেই থাকে। phone হারে — Tanvir Ahmed-এর ফোন নম্বর এখনো জানা নেই (NULL), আর নম্বর বদলাতেও পারে। তবু phone-এ UNIQUE আছে, কারণ দুজন গ্রাহকের একই নম্বর থাকা উচিত নয়। এখন দেখুন DBMS কীভাবে primary key রক্ষা করে — customer_id 3 আগেই Sabbir Hasan-এর:

-- নতুন গ্রাহক, নতুন id: ঢুকবে
INSERT INTO customers VALUES (9, 'Sadia Islam', 'Barishal', '01711000009', '2025-10-20');

-- id 3 আগেই Sabbir Hasan-এর: বাতিল হবে
INSERT INTO customers VALUES (3, 'Rakib Hasan', 'Cumilla', '01711000010', '2025-10-21');

Alternate key-ও একইভাবে রক্ষা পায়, তবে একটি পার্থক্য আছে: UNIQUE কলামে NULL থাকতে পারে, আর বেশিরভাগ DBMS-এ একাধিক NULL একে অপরের “সমান” ধরা হয় না। নিচে Sadia-র ফোন নম্বর জানা নেই, Tanvir-এরও নেই — দুটি NULL পাশাপাশি থাকতে পারে কি না, আর Rahim Uddin-এর নম্বর দিয়ে নতুন গ্রাহক খোলা যায় কি না, দেখুন:

-- ফোন নম্বর অজানা (NULL): UNIQUE কলামে আরেকটি NULL চলে
INSERT INTO customers VALUES (9, 'Sadia Islam', 'Barishal', NULL, '2025-10-20');
SELECT customer_id, name, phone FROM customers WHERE phone IS NULL;

-- কিন্তু 01711000001 আগেই Rahim Uddin-এর
INSERT INTO customers VALUES (10, 'Rakib Hasan', 'Cumilla', '01711000001', '2025-10-21');

Composite key — যখন একটি কলামে হয় না

কখনো কোনো একক কলামই সারি চেনাতে পারে না। order_items-এ order_id একা পারে না (একটি অর্ডারে অনেক পণ্য), product_id একা পারে না (একটি পণ্য অনেক অর্ডারে)। কিন্তু (order_id, product_id) জোড়া পারে: “অর্ডার 1001-এর Headphone লাইন” একটিই। একাধিক attribute মিলে তৈরি key-কে বলে composite key. SQL-এ এটি কলামের পাশে নয়, টেবিলের শেষে আলাদা করে লিখতে হয়: PRIMARY KEY (order_id, product_id).

বিশ্ববিদ্যালয়ের ডেটাবেসে (db-uni, পরের পর্বগুলোতে ব্যবহার হবে) enrollments টেবিলের key আরও বড়: (student_id, course_id, term). শুধু (student_id, course_id) হলে একজন শিক্ষার্থী F পেয়ে পরের term-এ একই কোর্স আবার নিতে পারতেন না — অথচ নিয়ম তা অনুমতি দেয়। এখানে ব্যবসার নিয়মই key-র আকার ঠিক করে দিচ্ছে।

-- অর্ডার 1006-এ এখন শুধু Smart Watch (110) আছে
-- একই অর্ডার, নতুন পণ্য: জোড়া (1006, 102) নতুন — ঢুকবে
INSERT INTO order_items VALUES (1006, 102, 1, 1200);

-- একই অর্ডার, একই পণ্য: জোড়া (1006, 110) আগেই আছে — বাতিল
INSERT INTO order_items VALUES (1006, 110, 2, 3500);

৪ · Natural key বনাম surrogate key — NID, ফোন নম্বর নাকি স্বয়ংক্রিয় id

Primary key বাছাইয়ের সবচেয়ে পুরোনো বিতর্ক এটি। Natural key হলো বাস্তব জগতে আগে থেকেই থাকা একটি পরিচয় — NID নম্বর, ফোন নম্বর, বইয়ের ISBN, গাড়ির রেজিস্ট্রেশন নম্বর। Surrogate key হলো ডেটাবেস নিজে যে নম্বর বানায়, যার বাস্তব কোনো অর্থ নেই — 1, 2, 3… বা একটি এলোমেলো UUID. আমাদের customers.customer_id একটি surrogate key; দোকানের বাইরে এর কোনো মানে নেই।

ফোন নম্বর কেন খারাপ primary key

bKash বা Nagad অ্যাকাউন্টের কথা ভাবলে মনে হয় ফোন নম্বরই তো পরিচয়। কিন্তু ডেটাবেসের ভেতরে নম্বরটিকে primary key বানালে তিনটি সমস্যা আসে:

• মানুষ নম্বর বদলান। হারানো সিম, নতুন চাকরির অফিস-নম্বর, বিদেশ যাওয়া। নম্বর primary key হলে অর্ডার, পেমেন্ট, রিভিউ — যত টেবিলে সেটি foreign key হিসেবে কপি হয়েছে, সবখানে বদলাতে হবে।
• নম্বর হাতবদল হয়। মোবাইল অপারেটর দীর্ঘদিন বন্ধ থাকা নম্বর একসময় নতুন গ্রাহককে দিতে পারে। তখন পুরোনো মালিকের ইতিহাস নতুন মালিকের ঘাড়ে চাপার ঝুঁকি।
• নম্বরের “অর্থ” বদলায়। বাংলাদেশে ২০১৮ সাল থেকে নম্বর অক্ষুণ্ণ রেখে অপারেটর বদলানো যায় (MNP). ফলে 017 মানেই একটি নির্দিষ্ট অপারেটর — এই পুরোনো ধারণার ওপর ভিত্তি করে লেখা কোড ভুল হয়ে যায়।

NID-ও পুরোপুরি নিরাপদ নয়: পুরোনো আর নতুন (স্মার্ট) কার্ডে নম্বরের দৈর্ঘ্য আলাদা হতে পারে, শিশুদের NID নেই, বিদেশি গ্রাহকের নেই, আর NID নম্বর URL-এ ঘুরে বেড়ানো গোপনীয়তার জন্য বিপজ্জনক। বইয়ের ISBN একটি ভালো শিক্ষা: ২০০৭ সালের ১ জানুয়ারি থেকে ISBN ১০ অঙ্ক থেকে ১৩ অঙ্কে বদলে যায়। যেসব লাইব্রেরি-সফটওয়্যারে ISBN ছিল primary key আর কলামটি ছিল ১০ অক্ষরের, তাদের সবাইকে schema বদলাতে হয়েছিল।

এভাবে দুই দিকের সুবিধাই মেলে: ভেতরের সম্পর্কগুলো স্থির, ছোট id দিয়ে জোড়া, আর বাইরের পরিচয়ের duplicate ঠেকায় UNIQUE. ফোন নম্বর বদলালে শুধু customers-এর একটি ঘর বদলায়। তবে মনে রাখুন, surrogate key একা duplicate ঠেকায় না — UNIQUE না দিলে একই মানুষ দুটি id-তে দুবার ঢুকে পড়বেন, আর DBMS কিছুই বলবে না।

স্বয়ংক্রিয় id — বিভিন্ন DBMS-এ

Surrogate key সাধারণত DBMS নিজেই দেয়, কিন্তু লেখার ধরন একেক সিস্টেমে একেক রকম। SQLite-এ INTEGER PRIMARY KEY কলামে মান না দিলে (বা NULL দিলে) সে নিজেই পরের নম্বর বসায়। নিচের ব্লকগুলো চালানো যায় না — শুধু তুলনার জন্য:

CREATE TABLE customers (
  customer_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,  -- SQL standard (PostgreSQL 10+)
  -- পুরোনো লেখা: customer_id SERIAL PRIMARY KEY
  name  TEXT NOT NULL,
  phone TEXT UNIQUE
);

CREATE TABLE customers (
  customer_id BIGINT AUTO_INCREMENT PRIMARY KEY,
  name  VARCHAR(100) NOT NULL,
  phone VARCHAR(15) UNIQUE
) ENGINE = InnoDB;

SQL Server-এ লেখা হয় IDENTITY(1,1), Oracle 12c থেকে GENERATED AS IDENTITY (তার আগে sequence আর trigger). একাধিক সার্ভারে আলাদাভাবে id বানাতে হলে, বা id অনুমান করা ঠেকাতে চাইলে, অনেকে UUID ব্যবহার করেন — ১২৮ বিটের এলোমেলো মান। এর দাম: ১৬ বাইট, আর পুরোপুরি এলোমেলো UUID নতুন সারিকে index-এর যেখানে-সেখানে ঢোকায়, যা B+ tree-র জন্য ব্যয়বহুল (পর্ব ৪০)। সময়-ক্রমিক UUIDv7 এই সমস্যা অনেকটা কমায়।

৫ · Foreign key আর referential integrity — টেবিল জোড়ার চুক্তি

orders টেবিলে গ্রাহকের নাম-ঠিকানা আবার লেখা হয় না, লেখা হয় শুধু customer_id. এই কলামটি customers-এর primary key-র দিকে আঙুল তুলে বলে, “এই অর্ডার ওই গ্রাহকের”। এমন কলামকে বলে foreign key: একটি টেবিলের attribute (বা attribute-সেট), যার প্রতিটি মান অন্য (বা একই) টেবিলের একটি candidate key-তে — প্রায় সবসময় primary key-তে — থাকতেই হবে। যে টেবিল আঙুল তোলে সেটি child বা referencing টেবিল (orders), যার দিকে তোলা হয় সেটি parent বা referenced টেবিল (customers).

নিচের ডায়াগ্রামে দেখুন, একটি নতুন অর্ডার ঢোকার সময় DBMS ধাপে ধাপে কী যাচাই করে:

এবার নিজে চালিয়ে দেখুন। প্রথমটি বৈধ গ্রাহকের (Sabbir Hasan, id 3) অর্ডার, দ্বিতীয়টি এমন গ্রাহকের, যিনি নেই:

-- গ্রাহক 3 আছেন: অর্ডার ঢুকবে
INSERT INTO orders VALUES (1011, 3, '2025-10-20', 'pending');

-- গ্রাহক 99 নেই: foreign key ভাঙবে
INSERT INTO orders VALUES (1012, 99, '2025-10-20', 'pending');

-- Tanvir Ahmed (5)-এর কোনো অর্ডার নেই: মোছা যাবে
DELETE FROM customers WHERE customer_id = 5;

-- Rahim Uddin (1)-এর তিনটি অর্ডার আছে: মোছা যাবে না
DELETE FROM customers WHERE customer_id = 1;

Foreign key-র আরও কয়েকটি বৈশিষ্ট্য

• NULL হতে পারে, যদি নিষেধ না থাকে। products.category_id-এ NOT NULL নেই, তাই শ্রেণিহীন পণ্য রাখা যায়। orders.customer_id-এ NOT NULL আছে — গ্রাহক ছাড়া অর্ডার অর্থহীন। NULL foreign key কোনো কিছুর দিকে আঙুল তোলে না, তাই যাচাইও হয় না।
• একই টেবিলের দিকেও আঙুল তোলা যায়। db-uni-র instructors টেবিলে mentor_id → instructors(instructor_id): একজন শিক্ষকের mentor আরেকজন শিক্ষক। একে self-referencing foreign key বলে; সবচেয়ে সিনিয়রের mentor_id NULL.
• Composite-ও হতে পারে। parent-এর key composite হলে foreign key-ও সেই কয়টি কলাম মিলে হয়, একই ক্রমে।
• নাম আর টাইপ মিলতে হবে না, অর্থ মিলতে হবে। কলামের নাম আলাদা হতে পারে (mentor_id → instructor_id), কিন্তু domain একই হওয়া চাই।

৬ · Integrity constraint-এর পুরো পরিবার

Key আর foreign key হলো integrity constraint-এর দুটি সদস্য মাত্র। Integrity constraint মানে ডেটার ওপর এমন একটি শর্ত, যা প্রতিটি বৈধ অবস্থায় সত্য থাকতে হবে; DBMS প্রতিটি INSERT, UPDATE আর DELETE-এর সময় শর্তগুলো যাচাই করে। কাজটি অ্যাপের কোডে না রেখে ডেটাবেসে রাখার সুবিধা: ওয়েবসাইট, মোবাইল অ্যাপ, অফিসের Excel-আমদানি স্ক্রিপ্ট — যে পথেই ডেটা আসুক, পাহারাদার একজনই।

Entity integrity আর NOT NULL

Entity integrity-র যুক্তি সরল: primary key দিয়েই একটি সারিকে চেনা হয়। key-র কোনো অংশ NULL হলে সারিটি “অচেনা”, আর দুটি NULL-key সারি একই বস্তু কি না বলাই যায় না। তাই primary key-র প্রতিটি কলাম অবশ্যই মানসহ। অন্য কলামে NULL চলবে কি না, তা ঠিক করে NOT NULL. customers-এ name NOT NULL — নামহীন গ্রাহক চলবে না; কিন্তু phone আর city NULL হতে পারে।

-- phone না দিলে NULL বসে: phone-এ NOT NULL নেই, তাই চলবে
INSERT INTO customers (customer_id, name, city, joined_on)
VALUES (9, 'Sadia Islam', 'Barishal', '2025-10-20');

-- name NOT NULL: নাম ছাড়া গ্রাহক চলবে না
INSERT INTO customers (customer_id, name, city, joined_on)
VALUES (10, NULL, 'Dhaka', '2025-10-21');

Domain আর CHECK

Domain constraint বলে প্রতিটি মান তার কলামের অনুমোদিত সেট থেকে আসবে। সবচেয়ে মোটা দাগের domain হলো ডেটা টাইপ — INTEGER কলামে “আটশো” লেখা চলবে না (SQLite-এ এখানে একটু শিথিলতা আছে, পর্ব ১৩-এ দেখবেন)। সূক্ষ্ম domain লেখা হয় CHECK দিয়ে: দাম ধনাত্মক, স্টক ঋণাত্মক নয়, অর্ডারের status চারটি শব্দের একটি, CGPA ০ থেকে ৪-এর মধ্যে। CHECK-এর শর্ত মিথ্যা হলে সারিটি বাতিল; শর্ত সত্য বা UNKNOWN (কোনো মান NULL হলে) হলে সারিটি ঢোকে — এই সূক্ষ্মতা পর্ব ১৬-এ।

-- Headphone (102)-এর স্টক 40: দুটি বিক্রি, থাকে 38
UPDATE products SET stock = stock - 2 WHERE product_id = 102;

-- Power Bank (103)-এর স্টক 0: একটি বিক্রি করলে -1 হবে
UPDATE products SET stock = stock - 1 WHERE product_id = 103;

যা CHECK পারে না — ব্যবসার নিয়ম

CHECK শুধু একটি সারির ভেতরের কলাম দেখতে পারে। কিন্তু অনেক নিয়ম একাধিক সারি বা টেবিল জুড়ে:

• “একটি অর্ডারের পণ্যের quantity সেই পণ্যের stock-এর বেশি হবে না” — order_items আর products দুটি টেবিল লাগে।
• “একজন গ্রাহকের একসাথে ৫টির বেশি pending অর্ডার থাকবে না” — একই টেবিলের অনেক সারি গুনতে হয়।
• “একজন শিক্ষকের বেতন তাঁর mentor-এর বেতনের বেশি হবে না” — একই টেবিলের দুটি আলাদা সারি তুলনা।
• “bKash-এ দিনে নির্দিষ্ট অঙ্কের বেশি পাঠানো যাবে না” — দিনের সব লেনদেন যোগ করতে হয়।

SQL standard এমন নিয়মের জন্য CREATE ASSERTION নামে একটি ব্যবস্থা রেখেছে, কিন্তু প্রধান DBMS-গুলোর কোনোটিই এটি বাস্তবায়ন করেনি — প্রতিটি পরিবর্তনে পুরো ডেটাবেস জুড়ে শর্ত যাচাই অত্যন্ত ব্যয়বহুল। বাস্তবে এগুলো রক্ষা হয় তিনভাবে: trigger (পরিবর্তনের মুহূর্তে DBMS নিজে একটি কোড চালায় — পর্ব ২৯), transaction-এর ভেতরে যাচাই করে তারপর লেখা (পর্ব ৪৪), আর অ্যাপের কোড। শেষেরটি সবচেয়ে দুর্বল, কারণ অন্য পথে আসা ডেটা পাহারা পায় না, আর একসাথে দুটি অনুরোধ এলে দুজনই “স্টক আছে” দেখে ফেলতে পারে।

৭ · নিয়ম ভাঙলে কী হয় — reject আর referential action

এ পর্যন্ত সব লঙ্ঘনে একই ঘটনা ঘটেছে: DBMS পুরো স্টেটমেন্টটি বাতিল (reject) করে, ডেটাবেস আগের অবস্থায় থাকে, আর অ্যাপ একটি ত্রুটি পায়। একটি UPDATE যদি ১০০টি সারি বদলাতে গিয়ে ৫০তম সারিতে CHECK ভাঙে, আগের ৪৯টির পরিবর্তনও ফিরিয়ে নেওয়া হয় — স্টেটমেন্ট হয় পুরোপুরি হবে, নয়তো একটুও নয়। অ্যাপের কাজ তখন ত্রুটি ধরে ব্যবহারকারীকে বোধগম্য বার্তা দেখানো: “এই ফোন নম্বরে আগেই অ্যাকাউন্ট আছে”।

Foreign key-র parent দিকে কিন্তু “না” ছাড়াও অন্য উত্তর দেওয়া যায়। Parent সারি মুছলে বা তার key বদলালে child সারিগুলোর কী হবে, তা foreign key ঘোষণার সময় বলে দেওয়া যায় — এগুলোকে বলে referential action:

RESTRICT আর NO ACTION-এর সূক্ষ্ম পার্থক্য: দুটিই child থাকলে আটকায়। RESTRICT যাচাই করে সঙ্গে সঙ্গে; NO ACTION যাচাই করে স্টেটমেন্ট শেষে — আর constraint-টি DEFERRABLE হলে transaction-এর শেষে (commit-এর সময়)। তাই NO ACTION-এ একই transaction-এ আগে parent মুছে পরে নতুন parent ঢুকিয়ে দিলে চলে, RESTRICT-এ চলে না। MySQL-এ দুটি একই আচরণ করে; PostgreSQL আর SQLite-এ পার্থক্যটি আছে। Oracle-এ ON UPDATE নিয়মই নেই, আর ON DELETE-এ শুধু CASCADE ও SET NULL.

এবার একই ছোট উদাহরণটি আসল SQLite-এ চালান। এই এডিটর db-shop নয়, নিজের একটি ছোট schema বানিয়ে নেয় — customers(id, name), orders(id, customer_id) আর order_items(order_id, product), দুটি foreign key-ই ON DELETE CASCADE. শুরুর ডেটা ঠিক উপরের ডায়াগ্রামের মতো; “নমুনা ডেটা” বাক্সে schema দেখতে পাবেন।

-- Rahim (1)-কে মুছলে তাঁর অর্ডার আর অর্ডার-লাইনও যাবে
DELETE FROM customers WHERE id = 1;

SELECT * FROM customers;
SELECT * FROM orders;
SELECT * FROM order_items;

এখন SET NULL আর ON UPDATE CASCADE. এই এডিটরের ছোট schema: departments(dept_id, name) আর students(student_id, name, dept_id), যেখানে students.dept_id-এ লেখা ON DELETE SET NULL ON UPDATE CASCADE. CSE বিভাগের কোড 1 থেকে 10 করা হবে, আর English বিভাগ (4) বন্ধ হবে:

-- CSE-র কোড 1 থেকে 10: শিক্ষার্থীর dept_id-ও বদলাবে
UPDATE departments SET dept_id = 10 WHERE dept_id = 1;

-- English (4) বন্ধ: Jui থাকবেন, কিন্তু বিভাগ NULL
DELETE FROM departments WHERE dept_id = 4;

SELECT * FROM students;

৮ · ইতিহাস — Codd-এর integrity নিয়ম থেকে আজকের SQL

৯ · AI-এর যুগে key আর constraint

AI-কে “একটা ই-কমার্স ডেটাবেসের schema বানিয়ে দাও” বললে কয়েক সেকেন্ডে সুন্দর CREATE TABLE চলে আসে। সমস্যা হলো, constraint-এর ভুল চোখে পড়ে না — schema চলে, ডেটা ঢোকে, ভুলটা ধরা পড়ে মাস ছয়েক পরে, যখন অনাথ অর্ডার আর duplicate গ্রাহক জমে গেছে। AI প্রায়ই যা করে:

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

• প্রতিটি টেবিলে primary key আছে, আর সেটি স্থির, ছোট ও কখনো NULL নয়
• প্রতিটি natural key (phone, email, NID) surrogate key-র পাশে UNIQUE দিয়ে রক্ষিত
• প্রতিটি সম্পর্কের কলামে সত্যিই REFERENCES আছে, আর SQLite হলে PRAGMA foreign_keys = ON
• প্রতিটি ON DELETE নিয়মের পক্ষে এক লাইনের ব্যবসায়িক যুক্তি বলতে পারি
• প্রতিটি constraint ভাঙার একটি পরীক্ষা চালিয়েছি — ত্রুটি না এলে constraint কাজ করছে না
• পুরোনো ডেটা আমদানির আগে GROUP BY … HAVING COUNT(*) > 1 দিয়ে duplicate খুঁজেছি