What is Functional Dependency?

What is Functional Dependency?

A functional dependency (FD) is a rule that connects two sets of columns in a table: if you know the value of one column, you can always find the value of the other.

It's written as A → B, which means: knowing A tells you B.

🎓 Example Table: Student

Functional dependencies here:

• RollNo → Name — each roll number points to exactly one name.

• RollNo → Department — each roll number points to exactly one department.

• RollNo → Name, Department — one roll number pins down both at once.

Not a functional dependency: Department → Name — CS has both Alice and Charlie, so knowing the department alone doesn't tell you the name.

Also not one: Name → RollNo — two different students could share a name, so a name doesn't reliably point back to one roll number.

Types of Functional Dependencies — Explained Slowly

🔹 Trivial FD

The idea: if the answer is already sitting inside the question, it's trivial — true, but useless.

Take a table with columns RollNo and Name. Ask: "If I know {RollNo, Name}, do I know Name?" Obviously yes — Name was already part of what you were given. That's a trivial dependency: {RollNo, Name} → Name.

Rule of thumb: if everything on the right side already appears on the left side, it's trivial.

Nobody writes these down in real database design — they're always true for any table, and they don't teach you anything about how the data actually behaves.

🔹 Non-Trivial FD

The idea: the right side gives you new information — something not already handed to you on the left side.

Using the Student table:

RollNo → Name is non-trivial because Name is not part of RollNo — you're learning something you didn't already have. This is the kind of dependency that actually matters when designing a database, because it tells you what's connected to what.

🔹 Fully Functional Dependency — walked through step by step

This one only makes sense when your key is made of more than one column (a composite key).

Table: Student_Course

The key here is {StudentID, CourseID} together — you need both to identify one row.

Now ask: does StudentID alone tell you the Grade? Look at S1 — S1 has grade A in row 1, and grade B in row 2. Same StudentID, two different grades. So StudentID alone is not enough.

Does {StudentID, CourseID} together tell you the Grade? Yes — S1+C1 always means grade A, no ambiguity.

So Grade genuinely needs both columns of the key — nothing less will do. That's what "fully functional" means: the right side depends on the entire key, not a piece of it.

{StudentID, CourseID} → Grade   ✅ fully functional

🔹 Partial Functional Dependency — the problem case

This is the opposite situation: the right side only needs part of the composite key, not all of it.

Table: Student_Course_Details

The key is still {StudentID, CourseID}. But look at StudentName:

• Every row where StudentID = S1 has StudentName = Alice, regardless of which course.

• StudentID alone is enough to know the name — CourseID adds nothing.

So:

StudentID → StudentName   ⚠️ partial dependency

This is partial because StudentName only relies on half of the key (StudentID), while the full key is {StudentID, CourseID}.

Why this is a problem: Alice's name gets repeated in every row she appears in. If Alice changes her name, you'd need to update it in multiple places — that's a maintenance headache, and it's exactly what 2NF (Second Normal Form) is designed to catch and fix, usually by splitting StudentName into its own Student table keyed just on StudentID.

🔹 Transitive Functional Dependency — the chain problem

This happens when column A determines column B, and column B (separately) determines column C — so A ends up determining C too, but only through the middle step.

Table: Employee

Walk through the chain:

• EmpID → DeptID (each employee belongs to one department)

• DeptID → DeptName (each department ID has one name)

Since EmpID leads to DeptID, and DeptID leads to DeptName, it follows that:

EmpID → DeptName   (transitively, via DeptID)

But notice: EmpID doesn't determine DeptName directly — it only does so because DeptID sits in between. That middle step is the giveaway that it's transitive.

Why this is a problem: DeptName doesn't really belong in the Employee table at all — it belongs with DeptID in a separate Department table. Storing it here means "Sales" gets repeated for every employee in that department, and if the department is renamed, every row needs updating. This is exactly what 3NF (Third Normal Form) removes, by moving DeptName into its own table keyed on DeptID.

🔹 Multivalued Dependency — a different kind of problem

This isn't a functional dependency at all (functional dependencies always point to a single value) — it shows up when one column is linked to several independent values of another column, with no functional relationship at all.

Table: Employee_Skills_Languages

Here, EmpID E1 has skills {Java, Python} and speaks languages {English, French} — and every skill is paired with every language, whether or not that pairing means anything. Skills and Languages have nothing to do with each other; they just both happen to belong to the same employee. That's written as:

EmpID ↠ Skill
EmpID ↠ Language

This is what 4NF (Fourth Normal Form) deals with — the fix is to split Skill and Language into two separate tables, each just linked to EmpID.

📊 Side-by-Side Comparison