In any organized system, rules govern how things relate. In a library, a specific call number leads you to exactly one book. In a company, an employee ID number corresponds to a single person. Relational databases have a similar concept for their data: functional dependencies.

A functional dependency is a rule or constraint between two sets of attributes in a table. If we know the value of one attribute (or a set of attributes), we can uniquely determine the value of another. It's the foundation for designing clean, efficient databases.

Let's look at a simple table of employee information.

In this table, if you know the EmployeeID, you know the EmployeeName. Give me 101, and the name must be Alice Smith. The same is true for HireDate and Department. EmployeeID uniquely determines all the other attributes. We write this using an arrow:

So, for our employee table, the functional dependencies are:

• EmployeeID → EmployeeName
• EmployeeID → HireDate
• EmployeeID → Department

Identifying these dependencies is the first step in normalization. They are the business rules made explicit in your database structure. By understanding them, you can spot potential redundancy and design tables that store information logically and without unnecessary repetition. These rules aren't arbitrary; they reflect the reality of the information you're storing. An employee has one name, one hire date, and works in one department at any given time.

Dependencies aren't always so simple. Sometimes, a combination of attributes is needed to determine another. Consider this table for tracking student course registrations and the professor for each course.

What are the rules here? To find a student's grade, you need to know both the StudentID and the CourseID. Neither one is enough on its own. Student 55 has two different grades, and course CS101 has been assigned two different grades. Together, however, they point to a single grade.

So, one functional dependency is: (StudentID, CourseID) → Grade

But what about the professor? ProfessorName is determined solely by the CourseID. Every time CS101 appears, Dr. Turing is the professor. This gives us another dependency:

CourseID → ProfessorName

This second dependency is a source of redundancy. Dr. Turing's name is stored for every student enrolled in CS101. If Dr. Turing leaves and is replaced, we'd have to update their name in multiple rows. This is precisely the kind of problem normalization solves, and it all starts with spotting these dependencies.

There's another, more subtle type of dependency. A multivalued dependency occurs when one attribute determines a set of values for another attribute, and those values are independent of other attributes in the table.

This sounds complex, but an example makes it clear. Imagine a table for professors that lists the courses they teach and the research interests they have.

Professor P123 teaches two courses (Databases, Compilers) and has two research interests (AI, Data Mining). The key thing is that the courses they teach are independent of their research interests. To represent all the facts, we have to create a row for every possible combination. This causes significant redundancy.

This relationship is a multivalued dependency.

Recognizing multivalued dependencies is important for reaching higher normal forms (like 4NF), which are designed specifically to eliminate this kind of redundancy. The solution is to split the table into two separate tables: one for courses and one for research interests, both linked by ProfessorID.