Functional Dependencies & Anomalies

Functional Dependency ও Anomaly — normalization-এর গাণিতিক ভিত্তি

Read: ~40 min Advanced 14 practice problems Theory + practice

1. Why "FDs" Before "Normalization"?

The next two modules teach normalization — a procedure for reshaping a sloppy schema into a clean one. But normalization is just cookbook unless you understand the functional dependency: the rule that quietly governs which schemas are clean and which are broken.

Normalization = পরিচ্ছন্ন schema বানানোর recipe। আর সেই recipe-র পেছনের তত্ত্ব = functional dependency (FD)। FD ভালোভাবে বুঝলে normalization-এর প্রতিটি ধাপ আর "মুখস্থ" মনে হবে না — যান্ত্রিকভাবে অনুসরণ করা যাবে।

By the end of this module you will be able to prove why a particular table needs to be split, and you will recognize the three classic update anomalies on sight.

2. What Is a Functional Dependency?

For attribute sets X and Y in a relation R, we say X → Y ("X functionally determines Y") if and only if: any two tuples that agree on every attribute in X must also agree on every attribute in Y.

Read it as: "Knowing X is enough to pin down Y."

Functional dependency বুঝতে একটি বাক্য মনে রাখুন — "X জানলে Y আপনি জানেন"। যেমন, roll_no → name মানে যেকোনো দুই row-এর roll_no এক হলে তাদের name-ও অবশ্যই এক হবে।

Concrete examples (university schema)

  • roll_no → name, dept, cgpa — roll number identifies a unique student.
  • course_id → course_title, credits — course IDs are unique titles.
  • (roll_no, course_id) → grade — a (student, course) pair determines exactly one grade.
  • dept_code → dept_name, dept_head — knowing the dept code tells you the rest.
  • cgpa → name — NOT a functional dependency. Two students can share a CGPA.
FDs are properties of the schema, not the data An FD must hold for every possible instance of the relation, not just today's data. If today no two students happen to share a CGPA, that does not make cgpa → name an FD — tomorrow a duplicate could appear.

3. Trivial & Non-Trivial FDs

  • Trivial FD — when Y ⊆ X. e.g. {name, dept} → name. Always true; tells us nothing useful.
  • Non-trivial FD — when at least one attribute of Y is not in X. The interesting kind.
  • Completely non-trivial FD — when X and Y are disjoint.
Trivial FD সবসময় সত্য (কারণ X-এর ভেতরে Y-ও আছে), তাই এদের থেকে কিছু শেখার নেই। গুরুত্বপূর্ণ কেবল non-trivial FD।

4. The Three Classic Update Anomalies

Consider a single fat table that mixes information about courses, instructors and the students taking them:

enrollments_bad.sql
CREATE TABLE enrollment(
    student_roll   INTEGER,
    student_name   TEXT,
    student_dept   TEXT,
    course_id      TEXT,
    course_title   TEXT,
    instructor     TEXT,
    instructor_email TEXT,
    grade          TEXT,
    PRIMARY KEY(student_roll, course_id)
);

INSERT INTO enrollment VALUES
 (101,'Arif',  'CSE','CSE331','Database Systems','Dr Karim','karim@univ.bd','A'),
 (101,'Arif',  'CSE','CSE221','Algorithms',     'Dr Hasan','hasan@univ.bd','A-'),
 (102,'Mim',   'CSE','CSE331','Database Systems','Dr Karim','karim@univ.bd','B+'),
 (103,'Tanvir','EEE','CSE331','Database Systems','Dr Karim','karim@univ.bd','B');

SELECT * FROM enrollment;

This table has three FDs that are not implied by its primary key:

  1. student_roll → student_name, student_dept
  2. course_id → course_title, instructor, instructor_email
  3. instructor → instructor_email

And those "extra" FDs cause three classic anomalies:

1. Insertion anomaly

Want to record a brand-new course "CSE401" before any student enrolls? You can't — the primary key forces a student_roll, but no one has enrolled yet.

কোনো student না থাকলে নতুন course-ই insert করা যাচ্ছে না।

2. Update anomaly

Dr Karim changes email. The new email must be updated in every row where he appears (3 rows here, possibly thousands in production). Miss one row → inconsistent data.

একটি email পরিবর্তনের জন্য বহু row update করতে হচ্ছে।

3. Deletion anomaly

If the only student enrolled in CSE221 drops it, deleting that row also deletes the only record of the CSE221 course's title and instructor — silently.

শেষ student বাদ পড়লে course-এর তথ্যই হারিয়ে যাচ্ছে।

5. Closure of an FD Set — X⁺

Given a set of FDs F, the closure of X under F — written X⁺ — is the set of all attributes Y such that X → Y can be derived from F. Closure is the single most important computation in normalization theory.

Algorithm to compute X⁺:
  1. Start with result = X.
  2. Repeat: for every FD A → B in F, if A ⊆ result, add B to result.
  3. Stop when one full pass adds nothing new.

Worked example

Schema R(A, B, C, D, E) with FDs F = { A → B, B → C, CD → E, E → A }. Compute {A, D}⁺:

StepApplyResult
0start{A, D}
1A → B{A, B, D}
2B → C{A, B, C, D}
3CD → E{A, B, C, D, E}
4nothing new{A, B, C, D, E} — closed.

Since {A, D}⁺ equals every attribute of R, {A, D} is a superkey. Closures are how we mechanically derive keys.

যদি কোনো attribute set-এর closure পুরো relation-কে cover করে, তাহলে সেটি একটি superkey। এ থেকেই candidate key খুঁজে বের করা যায়।

6. Armstrong's Axioms — The Three Sound & Complete Rules

William W. Armstrong (1974) proved that three simple rules are enough to derive every FD implied by a set F. Sound (no false derivation) and complete (every implied FD is derivable).

AxiomStatementPlain English
ReflexivityIf Y ⊆ X then X → Y.Trivial FDs always hold.
AugmentationIf X → Y then XZ → YZ for any Z.You may add the same attributes to both sides.
TransitivityIf X → Y and Y → Z then X → Z.Chains of "determines" compose.

Three useful theorems follow (called Armstrong's secondary rules):

  • Union — If X → Y and X → Z then X → YZ.
  • Decomposition — If X → YZ then X → Y and X → Z.
  • Pseudotransitivity — If X → Y and WY → Z then WX → Z.
Why we care Armstrong's axioms are the algebra under closures. The closure algorithm in §5 is just an efficient way to apply these axioms repeatedly until nothing new can be derived.

7. Finding Keys from FDs

An attribute set K is a candidate key of relation R iff:

  1. K⁺ covers every attribute of R (it's a superkey), and
  2. no proper subset of K already covers every attribute (it's minimal).

Example. Schema R(A, B, C, D) with FDs AB → C, C → D.

  • {A, B}⁺ = {A, B, C, D} — covers all → superkey.
  • {A}⁺ = {A} — does not cover → not a superkey.
  • {B}⁺ = {B} — does not cover → not a superkey.
  • So {A, B} is a candidate key. The only one in this case.
Closure ব্যবহার করে candidate key বের করা একটি যান্ত্রিক প্রক্রিয়া — মুখস্থ করার দরকার নেই, শুধু algorithm অনুসরণ করুন।

8. Glossary (শব্দকোষ)

TermMeaningবাংলায়
Functional dependencyX → Y: same X always implies same Y across the whole schema.X জানলে Y নিশ্চিতভাবে জানা যাবে।
Trivial FDFD where Y ⊆ X. Always true, no information.সবসময় সত্য, তাই গুরুত্বহীন FD।
Closure (X⁺)All attributes derivable from X under the FD set.X থেকে যে যে attribute derive করা যায় তাদের সেট।
Armstrong's axiomsReflexivity, augmentation, transitivity.FD derive করার মৌলিক তিনটি নিয়ম।
Insertion anomalyCannot record a fact without inventing unrelated data.অপ্রাসঙ্গিক data ছাড়া insert করা যায় না।
Update anomalyOne change requires updating many rows; miss one → inconsistent.একই value-এর জন্য বহু row update করতে হয়।
Deletion anomalyRemoving one fact accidentally removes another.একটি data মুছলে আরেকটি অপ্রাসঙ্গিক data-ও হারিয়ে যায়।

9. Practice Problems

Most problems here are pen-and-paper. Two also include runnable SQL to demonstrate the anomaly.

  1. Given R(A, B, C, D) with FDs A → B, B → C, compute A⁺.
    A⁺ বের করুন।
    ✨ Show Answer

    Answer: Start {A}. Apply A → B → {A, B}. Apply B → C → {A, B, C}. Nothing new can be derived → A⁺ = {A, B, C}. Note that D is not in the closure, so A alone is not a superkey.

  2. Same schema. Is {A, D} a superkey? Is it a candidate key?
    {A, D} কি superkey? Candidate key?
    ✨ Show Answer

    Answer: {A, D}⁺ = {A, B, C, D} = all of R, so yes — superkey. Removing D leaves A⁺ = {A, B, C} ≠ R, and removing A leaves D⁺ = {D} ≠ R. Neither subset is a superkey, so {A, D} is minimal → candidate key.

  3. Run the bad enrollment table from §4. Then add a new student to CSE331. Notice that you are forced to repeat all course/instructor information. Show the resulting table.
    নতুন একজন student insert করে দেখুন কতগুলো column আবার repeat হচ্ছে।
    ✨ Show Answer
    ans3.sql
    INSERT INTO enrollment VALUES
     (104, 'Nadia', 'BBA',
      'CSE331', 'Database Systems', 'Dr Karim', 'karim@univ.bd', 'A-');
    
    SELECT student_roll, course_id, course_title, instructor
    FROM enrollment;

    Notice: the same course_title and instructor are stored multiple times — pure redundancy, the seed of the update anomaly.

  4. Demonstrate the update anomaly: change Dr Karim's email and verify that several rows must change. What if you forget one?
    Update anomaly demo।
    ✨ Show Answer
    ans4.sql
    -- Forget the WHERE? You wipe a column. Forget a row? Inconsistent state.
    UPDATE enrollment
    SET    instructor_email = 'mkarim@univ.bd'
    WHERE  instructor = 'Dr Karim';
    
    SELECT DISTINCT instructor, instructor_email FROM enrollment;
  5. In the enrollment table, identify all non-trivial FDs that involve only a strict subset of the primary key on the left.
    Primary key-এর subset ব্যবহার করে যেসব non-trivial FD আছে — সেগুলো লিখুন।
    ✨ Show Answer

    Answer:

    • student_roll → student_name, student_dept (uses only part of the PK).
    • course_id → course_title, instructor, instructor_email (uses only part of the PK).
    • instructor → instructor_email (uses no part of the PK — even worse).

    Together these three are exactly the FDs that 2NF (next module) and 3NF will eliminate.

  6. Apply Armstrong's axioms: from A → B and A → C, derive A → BC. Which axiom or theorem did you use?
    Armstrong-এর কোন নিয়মে?
    ✨ Show Answer

    Answer: The union rule (a derived theorem). One way to derive it from the three primitive axioms: A → B ⇒ A → AB by augmentation. A → C ⇒ AB → BC by augmentation. Then transitivity: A → AB and AB → BC ⇒ A → BC. ∎

  7. In one sentence, explain why FDs are properties of the schema, not of today's data.
    FD শুধু আজকের data-এর বৈশিষ্ট্য নয় কেন?
    ✨ Show Answer

    Answer: An FD must hold for every conceivable instance the schema is allowed to take. Today's data may "look like" an FD purely by coincidence — but a single legal future row that breaks the pattern would prove it was never a real FD.

Summary — Module 25

A functional dependency X → Y says "same X forces same Y in every legal instance". FDs that are not implied by a key cause insertion, update and deletion anomalies — the symptoms that scream "this schema needs to be split." Closure (X⁺) is the mechanical way to derive keys, and Armstrong's three axioms are the algebra behind closure. Master FDs and the next two modules — 1NF/2NF/3NF and BCNF/4NF/5NF — become straightforward.

FD = "X জানলে Y জানি"। Key দ্বারা implied নয় এমন FD-ই anomaly-এর জন্ম দেয়। Closure আর Armstrong-এর axiom — এই দুটো বুঝলে normalization প্রায় যান্ত্রিক হয়ে যায়।

Next Module → Normalization — 1NF, 2NF, 3NF — fix the broken schema step by step.