Normalization — 1NF, 2NF আর 3NF

১ · Normalization কী, আর কেন — কোচিং সেন্টারের একটি খাতা

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

সমস্যা শুরু হয় প্রশ্ন করলে। “Math কোর্সে কে কে আছেন?” “প্রত্যেকের মোট মাসিক ফি কত?” “Kamal স্যারের নতুন ফোন নম্বর সবখানে বসান।” নিচের এডিটরে এই খাতাটিই একটি টেবিল coaching_center_records: কলামগুলো student_id, student_name, area, phones, courses, teachers, teacher_phones, fees আর enrolled_on; শেষের পাঁচটিতে কমা দিয়ে লেখা তালিকা। চারজন শিক্ষার্থী: Rafi (Math, Physics), Mim (Higher Math, Physics), Tonmoy (Math, Higher Math) আর Sumaiya (English).

-- Math কোর্সে কে কে? (তালিকার ভেতরে খোঁজা)
SELECT student_name, courses
FROM coaching_center_records
WHERE courses LIKE '%Math%';

-- প্রত্যেকের মোট ফি? (লেখাকে সংখ্যা বানানোর চেষ্টা)
SELECT student_name, fees, fees + 0 AS naive_total
FROM coaching_center_records;

এই খাতার রোগ একটিই: একই তথ্য বহু জায়গায়, আর একাধিক তথ্য এক জায়গায়। Kamal Hossain-এর ফোন নম্বর তিনটি সারিতে চারবার লেখা। এটিই data redundancy, আর এর ফল অমিল (data inconsistency). Normalization হলো functional dependency (FD) দেখে টেবিলকে নিয়মমাফিক ভেঙে সাজানোর পদ্ধতি, যাতে প্রতিটি তথ্য ঠিক এক জায়গায় থাকে। FD, closure আর canonical cover পর্ব ৩৫-এ (Functional dependency) পড়েছেন; এখানে সেগুলোই কাজে লাগবে।

Normal form — মানের সিঁড়ি

একটি normal form হলো একটি relation schema-র মানের স্তর, যা কিছু শর্ত দিয়ে সংজ্ঞায়িত। প্রতিটি উঁচু ধাপ নিচের সব ধাপের শর্ত মানে, আর আরও এক ধরনের redundancy সরায়:

William Kent ১৯৮৩ সালে 3NF পর্যন্ত পুরো ধারণাটিকে একটি বাক্যে বেঁধেছিলেন, যা আজও পাঠ্যবইয়ে উদ্ধৃত হয়: প্রতিটি non-key attribute তথ্য দেবে key সম্পর্কে (1NF), পুরো key সম্পর্কে (2NF), আর key ছাড়া অন্য কিছু সম্পর্কে নয় (3NF).

২ · তিন রকম anomaly — চালিয়ে দেখুন

স্প্রেডশিটটিকে সামান্য গুছিয়ে প্রতিটি (শিক্ষার্থী, কোর্স) জোড়ার জন্য একটি সারি করা যাক (কীভাবে, তা অংশ ৩-এ ধাপে ধাপে দেখবেন)। টেবিল coaching_records: student_id, student_name, area, course_code, course_title, teacher_id, teacher_name, teacher_phone, fee, enrolled_on — ৭টি সারি, primary key (student_id, course_code). প্রতিটি ঘরে এখন একটি মান, তবু redundancy রয়ে গেছে। এর তিনটি পরিণতিকে বলে তিন anomaly.

প্রথমে update anomaly. Kamal Hossain (T1) নতুন সিম নিয়েছেন। অফিস সহকারী সামনে থাকা একটি সারিই বদলালেন:

-- Kamal Hossain (T1)-এর নতুন নম্বর: শুধু একটি সারি বদলানো হলো
UPDATE coaching_records SET teacher_phone = '01700000099'
WHERE student_id = 'S1' AND course_code = 'MATH';

-- এখন একজন শিক্ষকের কয়টি নম্বর?
SELECT DISTINCT teacher_id, teacher_name, teacher_phone
FROM coaching_records ORDER BY teacher_id, teacher_phone;

-- ঠিকভাবে করতে হলে কয়টি সারি বদলাতে হতো?
SELECT COUNT(*) AS rows_for_T1 FROM coaching_records WHERE teacher_id = 'T1';

এবার Sumaiya Khan কোচিং ছেড়ে দিলেন, আর ঠিক পরেই সেন্টার একটি নতুন Biology কোর্স খুলতে চায়, শিক্ষক Sadia Rahman (T4), কিন্তু এখনো কোনো শিক্ষার্থী ভর্তি হননি:

-- Sumaiya (S4) কোচিং ছাড়লেন: তাঁর একমাত্র সারি মুছল
DELETE FROM coaching_records WHERE student_id = 'S4';

-- কোন কোন শিক্ষকের তথ্য এখনো আছে?
SELECT DISTINCT teacher_id, teacher_name, teacher_phone
FROM coaching_records ORDER BY teacher_id;

-- শিক্ষার্থী ছাড়া নতুন কোর্স Biology ঢোকানোর চেষ্টা
INSERT INTO coaching_records (student_id, course_code, course_title,
  teacher_id, teacher_name, teacher_phone, fee)
VALUES (NULL, 'BIO', 'Biology', 'T4', 'Sadia Rahman', '01700000004', 3000);

তিনটি anomaly-র মূল কারণ এক: একটি টেবিলে কয়েকটি আলাদা “বিষয়” (শিক্ষার্থী, কোর্স, শিক্ষক, ভর্তি) একসাথে গাদা করা। প্রতিটি বিষয়ের নিজের key আছে, আর সেই key-র ওপর নির্ভর করা তথ্য তার নিজের টেবিলে থাকা উচিত। Normal form-গুলো ঠিক এই “নির্ভরতা”-কে FD-র ভাষায় মাপে।

৩ · 1NF — প্রতিটি ঘরে একটি মান

Codd-এর relational model-এ relation সংজ্ঞাগতভাবেই 1NF-এ (পর্ব ৫)। তাই 1NF আসলে “টেবিলকে আসল relation বানানো”-র ধাপ। নিচের ডায়াগ্রামে খাতাটিকে 1NF-এ আনুন:

“Atomic” মানে কী — ব্যবহারই ঠিক করে

একটি তারিখ 2026-01-05-এর ভেতরে বছর, মাস আর দিন আছে। তাহলে কি এটি atomic নয়? আবার একটি নাম “Rafi Islam”-এ দুটি অংশ। উত্তর: atomic মানে পদার্থবিদ্যার “অবিভাজ্য” নয়, মানে ডেটাবেস যেভাবে ব্যবহার করে, তাতে মানটি একক। তারিখকে আমরা প্রায় সবসময় একটি একক হিসেবে তুলনা, সাজানো আর বিয়োগ করি; DBMS-এর date ফাংশন ভেতরের অংশ বের করে দিতে পারে, তাই এটি atomic ধরা হয়। কিন্তু phones-এর তালিকা থেকে আমরা আলাদা আলাদা নম্বর খুঁজি, যাচাই করি, একটি বাদ দিই — সেখানে প্রতিটি নম্বরই আলাদা তথ্য, তাই তালিকাটি atomic নয়।

একই যুক্তিতে “Rafi Islam” একটি দোকানের জন্য atomic হতে পারে, কিন্তু যে ব্যাংক পদবি ধরে চিঠি সাজায়, তার জন্য first_name আর last_name আলাদা রাখাই ভালো। একটি পরীক্ষা কাজে দেয়: যদি কখনো ঘরের একটি অংশ ধরে খুঁজতে, বদলাতে, গুনতে বা foreign key দিয়ে জুড়তে হয়, তাহলে সেটি atomic নয়।

Array আর JSON কলাম — 1NF কি ভাঙে?

আধুনিক DBMS একটি ঘরেই তালিকা রাখতে দেয়। SQL:1999 standard-এ ARRAY টাইপ আসে, আর PostgreSQL-এ array ও jsonb কলাম জনপ্রিয় (পর্ব ৩০)। নিচের ব্লকটি চালানো যায় না, শুধু PostgreSQL-এর ধরন দেখানোর জন্য:

CREATE TABLE students (
  student_id TEXT PRIMARY KEY,
  name       TEXT NOT NULL,
  phones     TEXT[]          -- একটি ঘরে নম্বরের তালিকা
);
-- তালিকার ভেতরে খোঁজা যায়; @> (contains) লিখলে GIN index দিয়ে দ্রুতও করা যায়
SELECT name FROM students WHERE phones @> ARRAY['01511000103'];

তাত্ত্বিকদের মধ্যে এ নিয়ে বিতর্ক আছে। C. J. Date-এর মতো লেখকেরা যুক্তি দিয়েছেন, domain-এর একটি মান নিজেই একটি তালিকা বা relation হতে পারে, আর তাতে relation 1NF-এর বাইরে যায় না — সমস্যা হলো সেই মানের ভেতরে ঢুকে প্রশ্ন করা। ব্যবহারিক নিয়মটি তাই সহজ: যদি তালিকাটি সবসময় একসাথে পড়া-লেখা হয় (একটি পোস্টের ট্যাগ দেখানো, একটি API-র সম্পূর্ণ উত্তর জমা রাখা), array বা JSON ঠিক আছে। কিন্তু যদি ভেতরের মান ধরে JOIN, foreign key, UNIQUE বা গণনা লাগে — “এই নম্বর আর কারও নামে আছে কি?” — তাহলে আলাদা টেবিলই সঠিক, কারণ তালিকার ভেতরের মানে foreign key বা UNIQUE বসানো যায় না।

৪ · 2NF — পুরো key-র ওপর নির্ভরতা

2NF আর 3NF বুঝতে দুটি শব্দ লাগে। যে attribute কোনো একটি candidate key-র অংশ, সেটি prime attribute; বাকিরা non-prime attribute. coaching_records-এর একমাত্র candidate key {student_id, course_code}, তাই prime শুধু এই দুটি, বাকি আটটি non-prime.

এবার এই টেবিলের FD-গুলো লিখি — ব্যবসার নিয়ম থেকে, ডেটা থেকে নয় (প্রতিটি কোর্সের একজন শিক্ষক আর একটি নির্দিষ্ট ফি; প্রতিটি শিক্ষকের একটি নাম আর একটি অফিসিয়াল ফোন):

একটি সরাসরি ফল: যে relation-এর প্রতিটি candidate key একটিমাত্র attribute, সেটি 1NF-এ থাকলেই 2NF-এ, কারণ একটি attribute-এর প্রকৃত উপসেট শুধু খালি সেট। 2NF-এর প্রশ্ন ওঠে কেবল composite key-তে। নিচের ডায়াগ্রামে coaching_records-কে 2NF, তারপর 3NF-এ আনুন:

৫ · 3NF — transitive dependency আর Zaniolo-র সংজ্ঞা

3NF-এর দুটি প্রচলিত সংজ্ঞা আছে। পরীক্ষায় দুটিই আসে, তাই দুটিই জানুন।

দ্বিতীয়টি যাচাইয়ে অনেক সহজ: প্রতিটি FD দেখুন, বামপাশ superkey কি না দেখুন, না হলে ডানপাশ prime কি না দেখুন। কিন্তু দুটি কি একই কথা বলে? চলুন উভয় দিক দেখি।

Zaniolo ভাঙলে Codd-ও ভাঙে। ধরুন X → A এমন যে X superkey নয় আর A non-prime. যেকোনো candidate key K নিন। K সব কিছু নির্ধারণ করে, তাই K → X. X superkey নয়, তাই X ↛ K. A non-prime বলে A ∉ K, আর X → A nontrivial বলে A ∉ X. তাহলে K → X → A একটি transitive dependency — Codd-এর শর্ত ভাঙল। (বিশেষ ঘটনা: X যদি K-র প্রকৃত উপসেট হয়, এটি আসলে partial dependency — তাই Zaniolo-র একটি শর্তই 2NF আর 3NF দুটিকে একসাথে ধরে।)

Codd ভাঙলে Zaniolo-ও ভাঙে। Partial dependency Y → A (Y ⊂ K, A non-prime) থাকলে Y superkey হতে পারে না — তাহলে K minimal হতো না — তাই Y → A Zaniolo ভাঙে। আর transitive K → X → A (X ↛ K) থাকলে X superkey নয়, A non-prime, তাই X → A Zaniolo ভাঙে। দুই দিকেই মিলল, অতএব সংজ্ঞা দুটি সমতুল্য। ∎

শর্ত (খ)-টি কেন রাখা হলো? কারণ এটি না থাকলে কিছু relation ভাঙার পর কোনো একটি FD আর কোনো একক টেবিলের ভেতরে যাচাই করা যায় না। শর্তটি তুলে দিলে যে কড়া রূপ পাওয়া যায়, সেটিই BCNF: প্রতিটি nontrivial X → A-তে X superkey. পর্ব ৩৭-এ দেখবেন, BCNF সবসময় dependency রক্ষা করে পাওয়া যায় না, কিন্তু 3NF যায় — এজন্যই 3NF বাস্তবের সাধারণ লক্ষ্য।

৬ · ভাঙার পরে — anomaly নেই, তথ্যও হারায়নি

এবার 3NF-এ ভাঙা পাঁচটি টেবিল আসল SQLite-এ। একই ডেটা: students (student_id, name, area — ৪ জন), student_phones (student_id, phone — ৬টি), teachers (teacher_id, name, phone — ৩ জন), courses (course_code, title, teacher_id, fee — ৪টি) আর enrollments (student_id, course_code, enrolled_on — ৭টি)। অংশ ২-এর তিনটি কাজ আবার করুন:

-- update: Kamal-এর নতুন নম্বর, এক জায়গায়
UPDATE teachers SET phone = '01700000099' WHERE teacher_id = 'T1';
-- delete: Sumaiya-র ভর্তি বাতিল
DELETE FROM enrollments WHERE student_id = 'S4';
-- insert: শিক্ষার্থী ছাড়াই নতুন শিক্ষক আর কোর্স
INSERT INTO teachers VALUES ('T4', 'Sadia Rahman', '01700000004');
INSERT INTO courses VALUES ('BIO', 'Biology', 'T4', 3000);

SELECT c.course_code, c.title, t.name, t.phone
FROM courses c JOIN teachers t ON t.teacher_id = c.teacher_id
ORDER BY c.course_code;

JOIN করে মূল টেবিল ফেরত — কোনো তথ্য হারায়নি তো?

ভাঙন তখনই নিরাপদ, যখন ভাঙা টেবিলগুলো আবার জুড়ে হুবহু মূল টেবিলটি পাওয়া যায় — একটি সারিও কম নয়, একটিও বেশি নয়। নিচের এডিটরে মূল coaching_records আর ভাঙা টেবিল দুটোই আছে। JOIN দিয়ে একটি view বানিয়ে দুই দিকে EXCEPT চালানো হলো:

CREATE VIEW rebuilt AS
SELECT e.student_id, s.name AS student_name, s.area, e.course_code,
       c.title AS course_title, c.teacher_id, t.name AS teacher_name,
       t.phone AS teacher_phone, c.fee, e.enrolled_on
FROM enrollments e
JOIN students s ON s.student_id = e.student_id
JOIN courses  c ON c.course_code = e.course_code
JOIN teachers t ON t.teacher_id = c.teacher_id;

SELECT * FROM rebuilt ORDER BY student_id, course_code;

SELECT
  (SELECT COUNT(*) FROM (SELECT * FROM coaching_records EXCEPT SELECT * FROM rebuilt)) AS missing,
  (SELECT COUNT(*) FROM (SELECT * FROM rebuilt EXCEPT SELECT * FROM coaching_records)) AS extra;

যে প্রশ্নগুলো এখন সহজ

অংশ ১-এর যে প্রশ্নে LIKE ভুল উত্তর দিয়েছিল আর ফি যোগ করা যায়নি, সেগুলো এখন সাধারণ JOIN আর GROUP BY:

-- 1. কোন কোর্সে কতজন
SELECT c.title, COUNT(*) AS students
FROM enrollments e JOIN courses c ON c.course_code = e.course_code
GROUP BY c.course_code ORDER BY students DESC, c.title;
-- 2. শুধু Math-এর শিক্ষার্থী (Higher Math নয়)
SELECT s.name FROM students s
JOIN enrollments e ON e.student_id = s.student_id WHERE e.course_code = 'MATH';
-- 3. প্রত্যেকের মোট মাসিক ফি
SELECT s.name, SUM(c.fee) AS total_fee
FROM students s JOIN enrollments e ON e.student_id = s.student_id
JOIN courses c ON c.course_code = e.course_code
GROUP BY s.student_id ORDER BY s.student_id;
-- 4. ফোন নম্বর থেকে শিক্ষার্থী
SELECT s.name FROM student_phones p
JOIN students s ON s.student_id = p.student_id WHERE p.phone = '01511000103';

ভুল ভাঙন — ভুয়া সারি (lossless পরীক্ষার পূর্বাভাস)

সব ভাঙন নিরাপদ নয়। ধরুন কেউ ভর্তির তথ্যকে (student_id, teacher_id) আর (teacher_id, course_code) — দুটি টেবিলে ভাঙলেন, ভাবলেন teacher_id দিয়ে আবার জোড়া যাবে:

CREATE TABLE st AS SELECT DISTINCT student_id, teacher_id FROM coaching_records;
CREATE TABLE tc AS SELECT DISTINCT teacher_id, course_code FROM coaching_records;

SELECT COUNT(*) AS original FROM coaching_records;
SELECT COUNT(*) AS rejoined FROM st JOIN tc ON tc.teacher_id = st.teacher_id;

-- যে সারিগুলো আসলে কখনো ছিল না
SELECT st.student_id, tc.course_code
FROM st JOIN tc ON tc.teacher_id = st.teacher_id
EXCEPT SELECT student_id, course_code FROM coaching_records;

এখান থেকেই lossless ভাঙনের পরীক্ষা: R-কে R₁ আর R₂-তে ভাঙন lossless, যদি এবং কেবল যদি F⁺-এ R₁ ∩ R₂ → R₁ অথবা R₁ ∩ R₂ → R₂ থাকে — অর্থাৎ সাধারণ attribute-গুলো অন্তত একটি টেবিলের superkey. students আর enrollments-এর মিল student_id, যা students-এর key — তাই lossless. উপরের st আর tc-র মিল teacher_id, যা কোনো দিকের key নয় — তাই lossy. প্রমাণ, দুইয়ের বেশি টেবিলের ভাঙন আর dependency preservation পর্ব ৩৭-এ।

৭ · নিয়মমাফিক যাচাই আর 3NF synthesis algorithm

কোচিং সেন্টারের উদাহরণে অনুমান দিয়ে চলেছি। পরীক্ষায় আর বড় ডিজাইনে লাগে একটি যান্ত্রিক পদ্ধতি — R আর F দেওয়া থাকলে প্রতিটি ধাপ নিশ্চিতভাবে করা যায় এমন:

ধাপ ৫-এ শুধু দেওয়া F দেখলেই চলে, পুরো F⁺ লাগে না — মূল relation R-এর জন্য এটি প্রমাণিত সত্য। কিন্তু ভাঙার পরের ছোট টেবিল যাচাইয়ের সময় সেই টেবিলে প্রক্ষিপ্ত FD-গুলো (F⁺ থেকে যেগুলোর সব attribute টেবিলটির ভেতরে) দেখতে হয়। একটি উদাহরণে পুরো পদ্ধতি চালান:

এই relation-এর canonical cover: A → BC-তে C বাড়তি (A → B আর B → C থেকেই আসে), আর AB → D-তে B বাড়তি (A⁺-এ D আছে)। তাই F_c = {A → BD, B → C, D → E}, আর 3NF ভাঙন (A, B, D), (B, C), (D, E) — প্রথমটিতে key A আছে। কাজটি যে পদ্ধতিতে হলো, সেটিই এবার আনুষ্ঠানিকভাবে।

3NF synthesis algorithm

3NF-SYNTHESIS(R, F):
  Fc ← canonical cover of F        -- পর্ব ৩৫
  S  ← { }
  for each X → Y in Fc:
      S ← S ∪ { X ∪ Y }            -- প্রতিটি FD থেকে একটি schema
  remove every schema in S that is a subset of another schema in S
  if no schema in S contains a candidate key of R:
      S ← S ∪ { any one candidate key of R }
  return S

এখানে canonical cover হলো F-এর সমতুল্য এমন একটি ছোট সেট, যার কোনো FD বাড়তি নয়, কোনো বামপাশে বাড়তি attribute নেই, আর একই বামপাশের FD-গুলো একসাথে লেখা। একটি বড় উদাহরণে প্রতিটি ধাপ দেখুন — এখানে সব ধাপই কাজে লাগে:

কেন algorithm-টি কাজ করে — তিনটি নিশ্চয়তা

• Dependency-preserving: F_c-এর প্রতিটি FD X → Y কোনো একটি schema-র (X ∪ Y বা তার বড় কোনোটির) ভেতরে। তাই প্রতিটি FD একটি টেবিলের UNIQUE/PRIMARY KEY দিয়েই রক্ষা করা যায়, JOIN ছাড়া। আর F_c ≡ F, তাই পুরো F রক্ষা পায়।
• Lossless: ধরুন R_k একটি candidate key K ধারণ করে। K⁺ = R, আর K⁺ বের করার প্রতিটি ধাপে একটি FD X → Y ব্যবহার হয়, যার X আগেই পাওয়া attribute-এর মধ্যে। R_k-এর একটি সারির সাথে X ∪ Y schema-র টেবিল X দিয়ে জুড়লে X → Y-এর কারণে ঠিক একটি মিল পাওয়া যায় — নতুন কোনো সারি তৈরি হয় না। এভাবে ধাপে ধাপে পুরো R জোড়া লাগে কোনো ভুয়া সারি ছাড়া। (এটি chase নামের আনুষ্ঠানিক প্রমাণের সারাংশ।)
• প্রতিটি schema 3NF: X ∪ Y schema-তে X একটি key (F_c-এ X-এর কোনো বাড়তি attribute নেই)। কোনো B → A যদি এখানে 3NF ভাঙত (B superkey নয়, A non-prime), তাহলে A ∈ Y, আর X → Y থেকে A-কে বাদ দিলেও A অন্য পথে আসত — অর্থাৎ F_c-এ বাড়তি কিছু ছিল, যা canonical cover-এর সংজ্ঞার বিরোধী। Key-ধারী schema-টিও 3NF-এ থাকে।

Data থেকে একটি FD প্রমাণ করা যায় না, কিন্তু খণ্ডন করা যায় — পর্ব ৬-এ key-র বেলায় যা দেখেছিলেন। coaching_records-এ কোন FD ডেটায় ভাঙে, দেখুন:

-- course_code → teacher_id: কোনো কোর্সের একাধিক শিক্ষক?
SELECT course_code, COUNT(DISTINCT teacher_id) AS n FROM coaching_records
GROUP BY course_code HAVING COUNT(DISTINCT teacher_id) > 1;

-- teacher_id → course_code: কোনো শিক্ষকের একাধিক কোর্স?
SELECT teacher_id, COUNT(DISTINCT course_code) AS n FROM coaching_records
GROUP BY teacher_id HAVING COUNT(DISTINCT course_code) > 1;

-- area → student_name: এক এলাকায় একাধিক নাম?
SELECT area, COUNT(DISTINCT student_name) AS n FROM coaching_records
GROUP BY area HAVING COUNT(DISTINCT student_name) > 1;

৮ · db-shop কি 3NF-এ? আর প্রচলিত ভুল ধারণা

এই কোর্সের দোকানের ডেটাবেস (db-shop) পরীক্ষা করা যাক। পাঁচটি টেবিল: customers (customer_id, name, city, phone, joined_on), categories (category_id, name), 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).

প্রতিটি টেবিলে প্রতিটি nontrivial FD-র বামপাশ superkey — তাই সবকটি 3NF-এ, এমনকি BCNF-এ। এটি কাকতালীয় নয়: পর্ব ১০-এর ER থেকে টেবিল বানানোর নিয়ম মানলে প্রতিটি entity নিজের টেবিলে যায়, আর ফল সাধারণত সরাসরি 3NF হয়। Normalization তখন ডিজাইনের যাচাই-এর কাজ করে।

order_items.unit_price কি 3NF ভাঙে?

প্রথম দেখায় মনে হয়, দাম তো products.price-এ আছে, order_items-এ আবার কেন? এটি কি product_id → unit_price ধরনের transitive বা partial dependency? ডেটা দেখুন:

-- কোন অর্ডার-লাইনের দাম আজকের দামের সাথে মেলে না?
SELECT oi.order_id, p.name, p.price AS price_now, oi.unit_price
FROM order_items oi JOIN products p ON p.product_id = oi.product_id
WHERE oi.unit_price <> p.price;

-- product_id → unit_price কি সত্য? একই পণ্যের একাধিক দাম?
SELECT product_id, COUNT(DISTINCT unit_price) AS prices
FROM order_items GROUP BY product_id HAVING COUNT(DISTINCT unit_price) > 1;

প্রচলিত ভুল ধারণা

• “বেশি টেবিল মানেই ভালো ডিজাইন।” না। students-কে (student_id, name) আর (student_id, area)-তে ভাঙা lossless, কিন্তু কোনো redundancy সরায় না — শুধু JOIN বাড়ায়। Normal form-এর শর্ত পূরণ হলে থামুন।
• “3NF মানে কোনো redundancy নেই।” প্রায়, কিন্তু পুরো নয়। 3NF-এ থেকেও কিছু redundancy থাকে (যেমন R1(A, B, C)-এ C → B), আর দুটি স্বাধীন তালিকা এক টেবিলে মেশালে 4NF লাগে — পর্ব ৩৭।
• “Normal form ডেটা দেখে ঠিক হয়।” না, FD দেখে, আর FD আসে নিয়ম থেকে। ডেটা শুধু একটি FD খণ্ডন করতে পারে।
• “Normalization ধীর করে, তাই বাদ দিন।” প্রথমে normalize করুন, তারপর মেপে দেখুন কোথায় সত্যিই ধীর; প্রয়োজনে সচেতনভাবে denormalization — পর্ব ৩৮-এর বিষয়।
• “কপি থাকলেই normalization ভাঙা।” ঐতিহাসিক মান (unit_price, চালানের ঠিকানা) কপি নয়, আলাদা তথ্য।

৯ · পরীক্ষার ধাঁচের সমস্যা — সম্পূর্ণ সমাধান

বিশ্ববিদ্যালয়, চাকরি বা ইন্টারভিউর লিখিত পরীক্ষায় প্রশ্নটি প্রায় একই রূপে আসে: “R আর F দেওয়া আছে। candidate key বের করুন, সর্বোচ্চ normal form বলুন, প্রয়োজনে 3NF-এ ভাঙুন।” তিনটি ধরন দেখুন।

সমস্যা ১. R(A, B, C, D), F = {AB → C, B → D}.

• Key: A আর B কোনো ডানপাশে নেই, তাই দুটিই প্রতিটি key-তে। (AB)⁺ = {A, B, C, D} = R. candidate key: {A, B}. prime: A, B.
• Normal form: B → D-তে B একটি key-র প্রকৃত অংশ, D non-prime — partial dependency. তাই 2NF নয়; সর্বোচ্চ 1NF.
• 3NF ভাঙন: F-এ কোনো বাড়তি কিছু নেই (AB → C-তে A⁺ = {A}, B⁺ = {B, D} — C নেই), তাই F_c = F. schema: (A, B, C) আর (B, D). প্রথমটিতে key AB আছে, আর কেউ কারও উপসেট নয় — ফল R1(A, B, C), R2(B, D).

সমস্যা ২. R(A, B, C), F = {AB → C, C → A}.

• Key: B কোনো ডানপাশে নেই। B⁺ = {B}. (AB)⁺ = {A, B, C}, (BC)⁺ = {B, C, A}. candidate key: {A, B} আর {B, C}. prime: A, B, C — সব!
• Normal form: সব attribute prime হলে Zaniolo-র শর্ত (খ) সবসময় সত্য, তাই R 3NF-এ — ভাঙার দরকার নেই। তবে C → A-তে C superkey নয়, তাই BCNF নয়। এটিই পর্ব ৩৭-এর বিখ্যাত উদাহরণের কাঠামো।

সমস্যা ৩. R(emp_id, dept_id, dept_name, project_id, hours), F = {emp_id → dept_id, dept_id → dept_name, (emp_id, project_id) → hours}.

• Key: emp_id আর project_id কোনো ডানপাশে নেই; (emp_id, project_id)⁺ = সব। candidate key: {emp_id, project_id}.
• Normal form: emp_id → dept_id partial (dept_id non-prime), তাই সর্বোচ্চ 1NF. (dept_id → dept_name একটি transitive dependency-ও।)
• 3NF ভাঙন: F_c = F. schema: (emp_id, dept_id), (dept_id, dept_name), (emp_id, project_id, hours) — শেষটিতে key আছে। ফল: কর্মী-বিভাগ, বিভাগ, আর কর্মী-প্রকল্পের ঘণ্টা — তিনটি টেবিল।

১০ · AI-এর যুগে normalization

AI-কে “এই স্প্রেডশিট normalize করে দাও” বললে সুন্দর কয়েকটি CREATE TABLE আসে। কিন্তু AI আপনার ব্যবসার নিয়ম জানে না, তাই FD অনুমান করে — আর অনুমানই ভুলের উৎস। প্রায়ই দেখা যায়: কলামের নাম দেখে FD ধরে নেওয়া (“city → zip” সব দেশে সত্য ভাবা), ঐতিহাসিক দাম বা ঠিকানাকে redundancy ভেবে মুছে ফেলা, প্রয়োজনের চেয়ে বেশি টেবিল, অস্তিত্বহীন কলামের নাম দিয়ে কোয়েরি, আর নতুন টেবিলে foreign key বা UNIQUE ভুলে যাওয়া। ভাঙার পর JOIN কোয়েরি চলে, কিন্তু সারির সংখ্যা ভুল — duplicate বা ভুয়া সারি চোখে পড়ে না।

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

• প্রতিটি FD আমার ব্যবসার নিয়ম থেকে এসেছে, AI-এর অনুমান থেকে নয়
• সব candidate key পাওয়া গেছে, আর closure হাতে মিলিয়ে দেখেছি
• প্রতিটি নতুন টেবিলে primary key, foreign key আর দরকারি UNIQUE আছে
• নমুনা ডেটায় JOIN করে মূল টেবিল ফেরত এনেছি; দুই দিকের EXCEPT-এ ০ সারি, সারির সংখ্যা মিলেছে
• ঐতিহাসিক মান (বিক্রির দাম, চালানের ঠিকানা) ভুল করে মুছে ফেলা হয়নি
• প্রয়োজনের বেশি টেবিল নেই; প্রতিটি ভাঙনের পেছনে একটি লঙ্ঘনকারী FD দেখাতে পারি