Software & Apps > Apps 89 89 people found this article helpful Full Functional Dependency in Database Normalization Protect your data by normalizing it to at least 2NF by Mike Chapple Writer Former Lifewire writer Mike Chapple is an IT professional with more than 10 years' experience cybersecurity and extensive knowledge of SQL and database management. our editorial process Twitter Mike Chapple Updated on July 01, 2021 reviewed by Jessica Kormos Lifewire Technology Review Board Member Jessica Kormos is a writer and editor with 15 years' experience writing articles, copy, and UX content for Tecca.com, Rosenfeld Media, and many others. our review board Article reviewed on Aug 25, 2021 Jessica Kormos Tweet Share Email Apps Best Apps Payment Services A full functional dependency is a state of database normalization that equates to the normalization standard of Second Normal Form (2NF). In brief, this means that it meets the requirements of First Normal Form (1NF), and all non-key attributes are fully functionally dependent on the primary key. 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: Employee Location John Los Angeles Tina Los Angeles, Chicago Allowing this design could negatively impact data updates or entries. To ensure 1NF compliance, rearrange the table so that all attributes (or column cells) hold a single value: Employee Location John Los Angeles Tina Los Angeles Tina Chicago But 1NF is still not enough to avoid problems with the data. How 2NF Works to Ensure Full Dependency To be fully dependent, all non-candidate key attributes must depend on the primary key. A candidate key attribute is any key (for example, a primary or foreign key) used to uniquely identify a database record. 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. EmployeeID EmployeeName DeptID DeptName Emp1 John Dept001 Finance Emp2 Tina Dept003 Sales Emp3 Carlos Dept001 Finance In this case, the table is not fully dependent because, while the EmployeeName depends on the primary key EmployeeID, the DeptName depends instead on the DeptID. This is called partial dependency. 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: EmployeeID EmployeeName DeptID Emp1 John Dept001 Emp2 Tina Dept003 Emp3 Carlos Dept001 We remove the DeptName attribute from the Employees table and create a new table Departments: DeptID DeptName Dept001 Finance Dept002 Human Resources Dept003 Sales Now the relations between the tables are fully dependent, or in 2NF. 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: Employee Location John Los Angeles Tina Los Angeles Tina Chicago Tina has two records. If we update one without realizing that there are two, the result would be inconsistent data. 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). Was this page helpful? Thanks for letting us know! Get the Latest Tech News Delivered Every Day Email Address Sign up There was an error. Please try again. You're in! Thanks for signing up. There was an error. Please try again. Thank you for signing up! Tell us why! Other Not enough details Hard to understand Submit More from Lifewire Putting a Database in Third Normal Form (3NF) Putting a Database in First Normal Form One-to-Many Relationships in a Database Basic Keys That Make Database Management Easy What Is a Database Relationship? Introduction to Database Relationships What Is Transitive Dependency in a Database Database Normalization Basics What Are Database Dependencies? What Is the Definition of a Database Query? Glossary of Common Database Terms Facts Vs. Dimensions Tables in a Database Definition of Database Relation A Database Attribute Defines the Properties of a Table What Is a Primary Key? What is MySQL?