完整的功能依赖性是数据库规范化的状态,等同于第二范式(2NF)的规范化标准。 简而言之,这意味着它符合第一范式(1NF)的要求,并且所有非关键属性在功能上完全依赖于主关键字。
这听起来并不复杂。 让我们更详细地看看这个。
第一范式的总结
在数据库完全依赖功能之前,它必须首先遵守第一范式 。
所有这一切意味着每个属性必须保持单一的原子值。
例如,下表不符合1NF,因为员工Tina链接到两个位置,两个位置都在一个单元中:
雇员 | 位置 |
---|---|
约翰 | 洛杉矶 |
蒂娜 | 洛杉矶,芝加哥 |
允许此设计可能会对数据更新或条目产生负面影响。 要确保1NF合规性,请重新排列表以便所有属性(或列单元格)具有单个值:
雇员 | 位置 |
---|---|
约翰 | 洛杉矶 |
蒂娜 | 洛杉矶 |
蒂娜 | 芝加哥 |
但是1NF还不足以避免数据问题。
2NF如何确保完全依赖
为了完全依赖,所有非候选键属性必须依赖于主键。 (请记住, 候选键属性是用于唯一标识数据库记录的任何键(例如,主键或外键)。
数据库设计人员使用记号来描述属性之间的依赖关系:
如果属性A确定了B的值,我们写这个A→B - 意味着B在功能上依赖于A.在这个关系中,A决定了B的值,而B取决于A.
例如,在以下Employee Departments表中,EmployeeID和DeptID都是候选键:EmployeeID是表的主键,而DeptID是外键。
任何其他属性(在本例中为EmployeeName和DeptName)必须依赖主键才能获得其值。
员工ID | 员工姓名 | DEPTID | DEPTNAME |
---|---|---|---|
EMP1 | 约翰 | Dept001 | 金融 |
EMP2 | 蒂娜 | Dept003 | 销售 |
EMP3 | 卡洛斯 | Dept001 | 金融 |
在这种情况下,表不完全依赖,因为当EmployeeName取决于主键EmployeeID时,DeptName取决于DeptID。 这被称为部分依赖 。
为了使这个表格符合2NF,我们需要将数据分成两个表格:
员工ID | 员工姓名 | DEPTID |
---|---|---|
EMP1 | 约翰 | Dept001 |
EMP2 | 蒂娜 | Dept003 |
EMP3 | 卡洛斯 | Dept001 |
我们从Employees表中删除DeptName属性并创建一个新表Departments :
DEPTID | DEPTNAME |
---|---|
Dept001 | 金融 |
Dept002 | 人力资源 |
Dept003 | 销售 |
现在表格之间的关系完全依赖,或者在2NF中。
为什么完全依赖是重要的
数据库属性之间的完全依赖有助于确保数据完整性并避免数据异常。
例如,请考虑上面仅符合1NF的表中的表格。 这里又是:
雇员 | 位置 |
---|---|
约翰 | 洛杉矶 |
蒂娜 | 洛杉矶 |
蒂娜 | 芝加哥 |
蒂娜有两个记录。 如果我们更新一个而没有意识到有两个,结果将是不一致的数据。
或者,如果我们想要将一名员工添加到此表中,但我们还不知道该位置? 如果Location属性不允许NULL值,我们可能会被禁止添加新员工。
尽管如此,在标准化方面,完全依赖并不是全貌。 您必须确保您的数据库处于第三范式 (3NF)。