Functional dependencies

Before normal forms there is one idea, and it is the whole subject in a sentence: which columns determine which other columns?

Written A → B: if two rows agree on A, they must agree on B.

roll_no → name: two rows with the same roll number must have the same name. name → roll_no is false: two students can share a name.

Dependencies come from the meaning of the data, not from the rows you happen to have. A table where every student currently has a distinct name does not make name → roll_no true; it makes it not yet violated.

Three kinds matter:

Full. B depends on the whole of a composite key. Partial. B depends on only part of it. Transitive. A determines B and B determines C, so A determines C indirectly.

Consider a badly designed table:

The key is (roll_no, course). Then:

• (roll_no, course) → marks: full, and fine.
• roll_no → dept_id: partial: department depends on half the key.
• dept_id → dept_name: so roll_no → dept_name transitively.

Those last two are why "Computer Science" is written twice, and why renaming the department means finding every row.

Takeaway: find the dependencies first. Every normal form is a rule about which ones are allowed.