Skip to main content

Functional Dependencies

A Functional Dependency (FD) describes the relationship between attributes within a single table. It conceptually defines how one or more fields mathematically determine another field.

If attribute A uniquely determines the value of attribute B, we write it as: A → B (B is functionally dependent on A).

Example: In an Employee table: SSN → EmployeeName
(Since a Social Security Number uniquely ties to exactly one employee name).

Types of Functional Dependency​

There are three main types of functional dependencies, which are critical concepts to understand when moving towards database Normalization:

1. Transitive Dependency​

If A → B and B → C, then C is transitively dependent on A via B.

  • Wait, why is this an issue? Because it creates redundancy. If C depends strictly on B, it belongs in a different table alongside B rather than being redundantly duplicated inside table A.
  • Example: Staff_No → Branch_No and Branch_No → Branch_Address. Thus Staff_No → Branch_Address is a transitive dependency.

2. Full Dependency​

An attribute B is fully functionally dependent on a composite key A if removing any attribute from A destroys the dependency.

3. Partial Dependency​

Occurs when an attribute depends on only a portion of a composite Primary Key, rather than the entire Key.

  • Example: If the Primary Key is (StudentID, CourseID) and the table has an attribute StudentName. The StudentName only depends on StudentID (a part of the key), thus forming a partial dependency.