什么叫数据库范式

数据库范式（Database Normalization Forms）是为了建立冗余较小、结构合理的数据库而制定的规范标准。满足这些规范的数据库设计可以减少数据冗余、避免数据不一致性问题，提高数据的存储效率和可维护性。常见的数据库范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯 - 科德范式（BCNF）、第四范式（4NF）和第五范式（5NF），下面为你详细介绍：

第一范式（1NF）

• 定义：数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之，每个字段具有原子性。
• 示例：
  • 不满足 1NF 的表：存在一个 “学生” 表，其中 “联系方式” 字段同时存储了手机号码和电子邮箱，中间用逗号分隔，这就不满足第一范式，因为 “联系方式” 可再分割。
  • 满足 1NF 的表：将 “联系方式” 拆分为 “手机号码” 和 “电子邮箱” 两个字段，这样每个字段都不可再分。

第二范式（2NF）

• 定义：在满足第一范式的基础上，非主属性完全依赖于主键，而不能只依赖于主键的一部分。也就是说，不能存在部分依赖。
• 示例：
  • 不满足 2NF 的表：有一个 “订单详情” 表，主键是（订单编号，商品编号），非主属性 “订单日期” 只依赖于 “订单编号”，这就存在部分依赖，不满足第二范式。
  • 满足 2NF 的表：将 “订单日期” 字段移到 “订单” 表中，让 “订单详情” 表中的非主属性完全依赖于（订单编号，商品编号）这个复合主键。

第三范式（3NF）

• 定义：在满足第二范式的基础上，非主属性之间不能存在传递依赖。即非主属性不能依赖于其他非主属性。
• 示例：
  • 不满足 3NF 的表：“员工” 表中，主键是 “员工编号”，非主属性有 “部门编号” 和 “部门名称”，“部门名称” 通过 “部门编号” 间接依赖于 “员工编号”，存在传递依赖，不满足第三范式。
  • 满足 3NF 的表：将 “部门编号” 和 “部门名称” 提取出来创建一个 “部门” 表，“员工” 表只保留 “部门编号” 并作为外键关联到 “部门” 表。

巴斯 - 科德范式（BCNF）

• 定义：它是第三范式的改进形式，在满足第三范式的基础上，要求每一个决定因素都包含码（候选键）。也就是说，每个非平凡的函数依赖的左边必须是候选键。
• 示例：
  • 不满足 BCNF 的表：有一个 “仓库管理” 表，属性为（仓库编号，管理员编号，物品编号，数量），存在函数依赖（仓库编号，物品编号）→ 数量，（管理员编号，物品编号）→ 数量，且仓库编号 → 管理员编号，这里 “仓库编号” 不是候选键，不满足 BCNF。
  • 满足 BCNF 的表：可以拆分为 “仓库 - 管理员” 表（仓库编号，管理员编号）和 “仓库 - 物品” 表（仓库编号，物品编号，数量）。

第四范式（4NF）

• 定义：在满足 BCNF 的基础上，消除非平凡且非函数依赖的多值依赖。简单来说，就是表中不能存在多值依赖关系，一个表中对于一个键值的组合，其他属性不能有多个值与之对应。
• 示例：
  • 不满足 4NF 的表：“课程” 表中有（课程编号，教师姓名，参考书），一门课程可能有多位教师和多本参考书，存在多值依赖，不满足第四范式。
  • 满足 4NF 的表：拆分为 “课程 - 教师” 表（课程编号，教师姓名）和 “课程 - 参考书” 表（课程编号，参考书）。

第五范式（5NF）

• 定义：也叫投影 - 连接范式（PJNF），它是在满足第四范式的基础上，消除不是由候选键所蕴含的连接依赖。当一个关系可以无损分解为多个子关系时，且这些子关系的连接不会产生额外的数据，就满足第五范式。第五范式是数据库范式的最高级别，在实际应用中较少使用。

在实际的数据库设计中，并不一定需要严格遵循所有的范式，需要根据具体的业务需求和性能要求进行权衡。有时为了提高查询性能，可能会适当保留一些数据冗余。

 

分享

 

 

如何在 EF Core 中实现第三范式？

解释一下数据库范式在实际项目中的应用

提供一些使用 EF Core 连接 MySQL 数据库的代码示例