数据库归一化的全功能依赖性

一个完整的函数依赖关系是数据库规范化这就等于标准化标准第二正常形式（2nf）。简而言之，这意味着它满足第一范式(1NF)的要求，并且所有非键属性在功能上完全依赖于主键。

这并不像听起来那么复杂。让我们更详细地看看这个。

第一范式总结

在数据库可以完全依赖于功能之前，必须首先遵守第一个正常形式。所有这意味着每个属性都必须保持一个原子值。

例如，下表可以不符合1NF，因为员工Tina链接到两个位置，其中两个位置都在一个单元格中：

第一范式不符合

员工	位置
约翰	洛杉矶
蒂娜	洛杉矶、芝加哥

允许这种设计可能会对数据更新或条目产生负面影响。要确保1NF合规性，请重新排列表，以便所有属性（或列单元）保持单个值：

符合第一标准表格规定

员工位置约翰洛杉矶蒂娜洛杉矶蒂娜芝加哥

但是1NF仍然不足以避免数据问题。

2NF如何确保完全依赖

要完全依赖，所有非候选键属性必须依赖于主键。(记住,候选关键字属性是用于唯一标识数据库记录的任何键(例如，主键或外键)。

数据库设计者使用一种符号来描述属性之间的依赖关系:

如果属性A决定了B的值，我们这样写A - B >- 意思是B在功能上取决于A.在这种关系中，确定B的值，而B取决于A.

例如，如下员工的部门表，EmployeeID和DeptID都是候选键:EmployeeID是表的主键，而DeptID是表的外键。任何其他属性——在本例中是EmployeeName和DeptName——必须依赖主键来获取其值。

员工的部门

EmployeeID	EmployeeName	德普蒂	DeptName
Emp1	约翰	Dept001	金融
Emp2	蒂娜	Dept003	销售
Emp3	卡洛斯	Dept001	金融

在本例中，表不是完全依赖的，因为EmployeeName依赖于主键EmployeeID，而DeptName依赖于DeptID。这就是所谓的部分依赖。

为了使这个表符合2NF，我们需要将数据分成两个表:

雇员

EmployeeID	EmployeeName	德普蒂
Emp1	约翰	Dept001
Emp2	蒂娜	Dept003
Emp3	卡洛斯	Dept001

属性中删除DeptName属性雇员表并创建一个新表部门:

部门

德普蒂	DeptName
Dept001	金融
Dept002	人力资源
Dept003	销售

现在表之间的关系完全依赖，或在2NF中完全依赖。

为什么完全依赖很重要

数据库属性之间的完全依赖性有助于确保数据完整性并避免数据异常。

例如，考虑上面的部分中的表，该部分仅遵守1NF。在这里，它再次：

符合第一标准表格规定

员工	位置
约翰	洛杉矶
蒂娜	洛杉矶
蒂娜	芝加哥

蒂娜有两张唱片。如果我们更新一个而没有意识到有两个，结果将是不一致的数据。

或者，如果我们想向这个表添加一个雇员，但我们还不知道Location，该怎么办?如果Location属性不允许NULL值，甚至可能不允许添加新雇员。

然而，当谈到标准化时，完全依赖并不是全部。您必须确保数据库已就绪第三范式(3 nf)。