A practical dependency in a database enforces a set of constraints in between qualities. This occurs when one characteristic in a relation uniquely figures out another characteristic. This can be composed
In this relationship, A determines the value of B, while B depends on A.
Why Functional Dependency Is Important in Database Design
The attribute SSN will determine the value of name, date of birth, address and perhaps other values, because a social security number is unique, while a name, date of birth or address might not be. We can compose it like this:
SSN -> name, date of birth, address
Put another, more concrete way, if we know the value of the SSN characteristic, we can find the value of name, date of birth and address. If we rather understand the value of only the name quality, we can not identify the SSN.
The left side of a functional dependency can include more than one attribute. Let’s say we have a business with numerous places. We might have a table Employee with qualities employee, title, department, place and supervisor.
The staff member identifies the location he’s working, so there’s a dependence:
worker -> location
However the place might have more than one supervisor, so staff member and department together figure out the manager:
employee, department -> manager
Practical Dependency and Normalization
Practical dependence contributes to what is called database normalization, which ensures data integrity and minimizes data redundancies. Without normalization, there is no assurance that the data in a database is accurate and reputable.
