关系型数据库的功能依赖和规范化的基础知识

简介

功能依赖和规范化是关系型数据库设计中的重要概念。当一个属性的值决定了另一个属性的值时，就会出现功能依赖性。规范化是以一种减少冗余和依赖的方式组织数据库的过程。它是设计一个高效和有效的数据库结构的关键步骤。

什么是功能依赖

功能依赖性是数据库中属性之间的关系。它们描述了一个属性是如何依赖于另一个属性的。例如，考虑一个雇员记录的数据库。雇员的ID号可能在功能上依赖于他们的名字，因为名字决定了ID号。在这种情况下，我们会说ID号在功能上依赖于名字。

功能依赖性可以用来设计一个数据库，以消除冗余并确保数据的完整性。例如，考虑一个存储员工记录和他们工作的部门的数据库。如果我们为每个员工存储部门名称，我们最终可能会有几个相同部门名称的副本。

这将是多余的，并且会在数据库中占用不必要的空间。相反，我们可以使用功能依赖，只存储一次部门名称，并使用员工的ID号来确定他们在哪个部门工作。这就减少了冗余，使数据库更有效率。

为什么规范化很重要

规范化是组织数据库的过程，以减少冗余和依赖性。它很重要，因为它有助于消除数据的不一致性，并确保数据以一种逻辑和有组织的方式存储。

例如，考虑一个存储客户信息和他们购买的产品的数据库。如果我们将产品名称与每个客户记录一起存储，我们最终可能会有几个相同产品名称的副本。这将是多余的，并且会在数据库中占用不必要的空间。相反，我们可以使用规范化来为产品创建一个单独的表，并且只存储一次产品名称。这就减少了冗余，使数据库更有效率。

有几种正常的形式可以用来规范化数据库。最常见的正常形式是第一、第二和第三正常形式。

第一范式（1NF）

第一正常形式（1NF）是规范化的一个基本级别。

它必须只包含原子值。原子值是一个不能进一步分解的单一值。例如，名字是一个原子值，但地址不是，因为它可以被分解成街道、城市、州和邮政编码的单独值。

它必须不包含重复组。重复组是一组在一条记录中重复出现的值。例如，如果一个表包含一个电话号码的字段，它不应该在同一个字段中包含多个电话号码。相反，每个电话号码应该有单独的字段。

第二范式（2NF）

第二正常形式（2NF）是一个更高层次的规范化。

它必须是在1NF中。
它不能有任何部分依赖性。当一个非键属性只依赖于主键的一部分时，就会出现部分依赖关系。例如，考虑一个有以下属性的表。EmployeeID（主键），EmployeeName，和DepartmentID。如果DepartmentID依赖于EmployeeID，但不依赖于EmployeeName，那么就存在一个部分依赖关系。为了消除这种依赖关系，我们将为部门创建一个单独的表，并在该表中存储DepartmentID和DepartmentName。

第三范式（3NF）

第三种正常形式（3NF）是一种更高层次的正常化。

它必须是在2NF中。
它不能有任何交叉性的依赖关系。当一个属性依赖于另一个不是主键的属性时，就会出现横向依赖关系。例如，考虑一个有以下属性的表。EmployeeID（主键），EmployeeName，和ManagerID。如果ManagerID依赖于EmployeeID，而EmployeeID是主键，那么就不存在过渡性依赖关系。但是，如果ManagerID依赖于EmployeeName，而EmployeeName不是主键，那么就存在着一种横向的依赖关系。为了消除这种依赖关系，我们将为经理创建一个单独的表，并在该表中存储ManagerID和ManagerName。

现实生活中的例子

为了更好地理解这些概念，让我们看一下功能依赖和规范化的一些现实生活中的例子。

示例 1

考虑一个网上商店的客户订单数据库。下面的表格存储了每个订单的信息 –

OrderID	CustomerID	ProductID	Quantity
1	1	10	2
2	1	11	1
3	2	10	3

在这个表中，订单ID是主键，客户ID和产品ID是外键。数量属性依赖于订单ID，因为它决定了订单中每个产品的数量。

这个表是在1NF中，因为它只包含原子值，没有任何重复的组。然而，它不在2NF中，因为数量属性依赖于订单ID，而订单ID只是主键（OrderID, ProductID）的一部分。为了消除这种部分依赖性，我们可以为订单细节创建一个单独的表，并在该表中存储订单ID、产品ID和数量。

OrderID	ProductID	Quantity
1	10	2
1	11	1
3	10	3

示例 2

考虑一个公司的雇员记录数据库。

EmployeeID	EmployeeName	ManagerID	DepartmentID
1	John Smith	3	1
2	Jane Doe	3	1
3	Bob Johnson	4	2
4	Mary Williams	NULL	2

在这个表中，EmployeeID是主键，ManagerID和DepartmentID是外键。ManagerID依赖于EmployeeID，因为它决定了该雇员的经理。DepartmentID依附于ManagerID，因为它决定了雇员所在的部门。

这个表在2NF中，因为它在1NF中并且没有任何部分依赖。然而，它不在3NF中，因为DepartmentID依赖于ManagerID，而后者不是主键。为了消除这种横向依赖，我们可以为部门创建一个单独的表，并在该表中存储DepartmentID和DepartmentName。然后我们可以更新雇员表，将DepartmentID作为外键存储。