数据库三大范式的理解

数据库三大范式的理解

数据库三大范式是关系数据库设计中的一组规范，旨在提高数据结构的合理性、减少数据冗余和提高数据操作的效率。它们分别是：

• 第一范式（1NF）：确保每个数据列都是不可再分的原子值，即每个单元格中只包含一个值。这可以通过将表拆分为更小的表来实现，每个表都包含一个实体的属性。

  （1）不满足第一范式的情况

  学生ID	学生姓名	选修课程
  1	小明	数学, 英语, 物理
  2	小红	化学, 历史
  3	小李	数学, 生物, 地理, 英语

  上面表格中的选修课程可以进一步拆分，不满足1NF

  （2）调整后的设计

  学生ID	学生姓名
  1	小明
  2	小红
  3	小李

  学生ID	课程
  1	数学
  1	英语
  1	物理
  2	化学
  2	历史
  3	数学
  3	生物
  3	地理
  3	英语

  这样的设计就满足每个单元格不可拆分，符合第一范式的标准

• 第二范式（2NF）：建立在第一范式的基础上，要求表中的每个非主键列完全依赖于主键列，而不是依赖于其他非主键列。换句话说，每个表应该只描述一个实体的信息。如果有部分信息依赖于表中的一部分主键，那么需要将这些信息拆分到另一个表中。

第二范式的案例

员工ID	员工名称	部门ID	部门名称
1	小明	A1	人事部
2	小红	A2	技术部
3	小李	A1	人事部

（1）不满足。如果该表格中的主键为（员工ID、部门ID），此设计就不满足2NF，因为部门名称其实只依赖于部门ID，员工名称只依赖于员工ID，非主键列并非完全依赖于主键，因此不满足2NF。

（2）满足。如果主键为（员工ID）那么就满足2NF。因为主键只有一个列，因此就不存在不满足2NF的情况。

也就是说，主键如果非复合主键，且满足1NF的情况下，就肯定满足2NF。

• 第三范式（3NF）：在第二范式的基础上，要求表中的每个非主键列之间不应该存在传递依赖关系。也就是说，非主键列之间不应该相互依赖，而是直接依赖于主键列。如果存在传递依赖，需要将其转化为直接依赖关系。

员工ID（P）	员工名称	部门ID	部门名称
1	小明	A1	人事部
2	小红	A2	技术部
3	小李	A1	人事部

该表格主键为（员工ID），虽然满足2NF，但是不满足3NF，因为非主键列存在依赖关系，部门ID和部门名称存在依赖关系。

部门ID（P）部门明
A1	人事部
A2	技术部

这么拆分之后，表的设计就满足3NF了，因为非主键之间不再存在传递依赖关系。

这三个范式是逐步规范化设计数据库的步骤，目的是提高数据的一致性、完整性和减少冗余，从而提高数据库的性能和可维护性。但要注意，范式化设计并不是一成不变的，根据具体的业务需求和应用场景，有时也需要对范式进行适度的调整和冗余处理。