数据库设计的范式(Normal Forms)是一些规范化的规则,用于组织数据库中的数据,以减少冗余、消除异常、提高数据一致性。下面是几大常见的数据库范式:
第一范式 (1NF: First Normal Form)
要求:
- 所有表中的字段必须是原子性的,即每个字段只能包含一个值,而不能包含一组值或列表。
 - 表中每一列必须是单值属性,不可再分。
 
| 举例: 假设有一个客户表:  | 
CustomerID | CustomerName | PhoneNumbers | 
|---|---|---|---|
| 1 | Alice | 123-4567, 234-5678 | 
这里 PhoneNumbers 列违反了第一范式,因为它包含多个值。将其规范化为第一范式: | 
CustomerID | CustomerName | PhoneNumber | 
|---|---|---|---|
| 1 | Alice | 123-4567 | |
| 1 | Alice | 234-5678 | 
第二范式 (2NF: Second Normal Form)
要求:
- 满足第一范式。
 - 表中的每个非主键列都必须完全依赖于主键(即不能有部分依赖)。
 
| 举例: 假设有一个订单表:  | 
OrderID | ProductID | ProductName | Quantity | 
|---|---|---|---|---|
| 1 | 101 | Widget | 10 | |
| 2 | 102 | Gadget | 5 | 
这里 ProductName 依赖于 ProductID,而不是 OrderID。将其规范化为第二范式:订单表:  | 
OrderID | ProductID | Quantity | 
|---|---|---|---|
| 1 | 101 | 10 | |
| 2 | 102 | 5 | 
| 产品表: | ProductID | ProductName | 
|---|---|---|
| 101 | Widget | |
| 102 | Gadget | 
第三范式 (3NF: Third Normal Form)
要求:
- 满足第二范式。
 - 表中的每个非主键列必须直接依赖于主键,而不能依赖于其他非主键列(即不能有传递依赖)。
 
| 举例: 假设有一个学生表:  | 
StudentID | StudentName | DepartmentID | DepartmentName | 
|---|---|---|---|---|
| 1 | Alice | 10 | Computer Science | |
| 2 | Bob | 20 | Mathematics | 
这里 DepartmentName 依赖于 DepartmentID,而 DepartmentID 又依赖于 StudentID。将其规范化为第三范式:学生表:  | 
StudentID | StudentName | DepartmentID | 
|---|---|---|---|
| 1 | Alice | 10 | |
| 2 | Bob | 20 | 
| 部门表: | DepartmentID | DepartmentName | 
|---|---|---|
| 10 | Computer Science | |
| 20 | Mathematics | 
BCNF (Boyce-Codd Normal Form)
要求:
- 满足第三范式。
 - 对于每个非平凡的函数依赖 X -> Y,X 必须是超键(superkey)。
 
| 举例: 假设有一个课程表:  | 
CourseID | Instructor | Classroom | 
|---|---|---|---|
| 1 | Prof. A | Room 101 | |
| 2 | Prof. B | Room 102 | 
如果一个教室只能由一个教授教授,并且一个教授只能在一个教室授课,这里存在一个依赖关系 Classroom -> Instructor。将其规范化为 BCNF:课程表:  | 
CourseID | Instructor | 
|---|---|---|
| 1 | Prof. A | |
| 2 | Prof. B | 
| 教室表: | Classroom | Instructor | 
|---|---|---|
| Room 101 | Prof. A | |
| Room 102 | Prof. B | 
第四范式 (4NF: Fourth Normal Form)
要求:
- 满足 BCNF。
 - 不包含多值依赖(一个属性依赖于另一个属性的多个值)。
 
| 举例: 假设有一个项目表:  | 
ProjectID | EmployeeID | SkillID | 
|---|---|---|---|
| 1 | 101 | A | |
| 1 | 101 | B | |
| 2 | 102 | A | 
| 这里一个项目可以涉及多个员工,一个员工可以拥有多项技能,存在多值依赖。将其规范化为第四范式: 项目-员工表:  | 
ProjectID | EmployeeID | 
|---|---|---|
| 1 | 101 | |
| 2 | 102 | 
| 员工-技能表: | EmployeeID | SkillID | 
|---|---|---|
| 101 | A | |
| 101 | B | |
| 102 | A | 
第五范式 (5NF: Fifth Normal Form)
要求:
- 满足第四范式。
 - 消除所有的连接依赖(Join Dependency)。
 
| 举例: 假设有一个供应商-零件-项目表:  | 
SupplierID | PartID | ProjectID | 
|---|---|---|---|
| 1 | A | X | |
| 1 | B | X | |
| 2 | A | Y | |
| 2 | B | Y | 
| 将其规范化为第五范式: 供应商-零件表:  | 
SupplierID | PartID | 
|---|---|---|
| 1 | A | |
| 1 | B | |
| 2 | A | |
| 2 | B | 
| 零件-项目表: | PartID | ProjectID | 
|---|---|---|
| A | X | |
| B | X | |
| A | Y | |
| B | Y | 
| 供应商-项目表: | SupplierID | ProjectID | 
|---|---|---|
| 1 | X | |
| 2 | Y | 
通过遵循这些范式规则,可以设计出更加健壮、减少冗余且易于维护的数据库模型。每个范式都有其应用场景和限制,实际中需要根据具体需求来平衡规范化与性能之间的关系。