This is not as complicated as it may sound. Let’s look at this in more detail.
Summary of First Normal Form
Before a database can be fully functionally dependent, it must first comply with First Normal Form. All this means that each attribute must hold a single atomic value. For example, the following table does not comply with 1NF because the employee Tina is linked to two locations, both of them in a single cell:
How 2NF Works to Ensure Full Dependency
To be fully dependent, all non-candidate key attributes must depend on the primary key. Database designers use a notation to describe the dependent relationships between attributes: If attribute A determines the value of B, we write this A -> B, meaning that B is functionally dependent on A. In this relationship, A determines the value of B, while B depends on A. For example, in the following Employee Departments table, EmployeeID and DeptID are both candidate keys: EmployeeID is the table’s primary key while DeptID is a foreign key. Any other attributes—in this case, EmployeeName and DeptName—must depend on the primary key to obtain its value. To make this table conform to 2NF, we need to separate the data into two tables: an Employees table and a Departments table. Here’s the Employees table:
Why Full Dependency Is Important
Full dependency between database attributes helps ensure data integrity and avoid data anomalies. For example, consider the table in the section above that adheres only to 1NF. Here it is, again: Or, what if we want to add an employee to this table, but we don’t yet know the location? We might be disallowed to even add a new employee if the Location attribute does not allow NULL values. Full dependency is not the whole picture, though, when it comes to normalization. You must make sure that your database is in Third Normal Form (3NF).
