数据库规范化中的全功能依赖

完整的功能依赖性是数据库规范化的状态,等同于第二范式(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)。