数据库设计三大范式
数据库设计三大范式（1NF、2NF、3NF）是保证数据库规范化、提高数据一致性和完整性、减少数据冗余和操作异常的重要原则。具体来说：
- 第一范式（1NF）要求数据库表中的每个字段都必须是原子性的，不可再分。
- 第二范式（2NF）在第一范式的基础上，要求所有非主键列都必须完全依赖于整个主键，而不是主键的某个部分，消除非主键列对主键的部分函数依赖。
- 第三范式（3NF）在第二范式的基础上，要求所有非主键列之间不能存在传递依赖关系，非主键列应该直接依赖于主键。
第一范式（1NF）：原子性
- 概念：表中的每一个列都必须是不可分割的原子数据项。
- 例子：如果一个地址列可以被拆分为国家、省、市、县等多个部分，那么这个地址列就不满足第一范式，需要进行拆分。
第二范式（2NF）：完全依赖于主键
- 前提：表必须满足第一范式。
- 概念：所有非主键的列都必须完全依赖于整个候选主键（码）。对于联合主键，非主键属性必须依赖于全部主键列。
- 作用：避免了数据冗余，解决了在更新、插入、删除数据时可能出现的异常。
第三范式（3NF）：不存在传递依赖
- 前提：表必须满足第二范式。
- 概念：所有非主键列之间不应存在传递依赖关系。换句话说，非主键列之间不能互相依赖，它们应该直接依赖于主键。
- 作用：进一步减少了数据冗余，提高了数据的一致性。
三大范式为数据库设计者提供了一套标准，以创建高效、稳定、无冗余的关系型数据库，确保数据的完整性和一致性。虽然在实际开发中可能为了性能需要适当打破范式原则，但这通常是第三个境界（经验丰富后）才考虑的问题，不应在入门阶段盲目追求。
什么是范式: 简言之就是, 数据库设计对数据的存储性能, 还有开发人员对数据的操作都有莫大的关系. 所以建立科学的、规范的的数据库是需要满足一些规范的来优化数据数据存储方式. 在关系型数据库中这些规范就可以称为范式.
第一范式: 当关系模式 R 的所有属性都不能在分解为更基本的数据单位时, 称 R 是满足第一范式的, 简记为 1NF.
- 满足第一范式是关系模式规范化的最低要求, 否则, 将有很多基本操作在这样的关系模式中实现不了.
第二范式: 如果关系模式 R 满足第一范式, 并且 R 的所有非主属性都完全依赖于 R 的每一个候选关键属性, 称 R 满足第二范式, 简记为 2NF.
第三范式: 设 R 是一个满足第一范式条件的关系模式, X 是 R 的任意属性集, 如果 X 非传递依赖于 R 的任意一个候选关键字, 称 R 满足第三范式, 简记为 3NF.
注: 关系实质上是一张二维表, 其中每一行是一个元组, 每一列是一个属性.
-
每一列属性都是不可再分的属性值, 确保每一列的原子性.
-
两列的属性相近或相似或一样, 尽量合并属性一样的列, 确保不产生冗余数据.
如果需要知道哪个省哪个市并按其分类, 那么显然第一个表格是不容易满足需求的, 也不符合第一范式.
显然第一个表结构不但不能满足足够多物品的要求, 还会在物品少时产生冗余. 也是不符合第一范式的.
每一行的数据只能与其中一列相关, 即一行数据只做一件事. 只要数据列中出现数据重复, 就要把表拆分开来.
一个人同时订几个房间, 就会出来一个订单号多条数据, 这样子联系人都是重复的, 就会造成数据冗余. 我们应该把他拆开来.
这样便实现了一条数据做一件事, 不掺杂复杂的关系逻辑. 同时对表数据的更新维护也更易操作.
数据不能存在传递关系, 即每个属性都跟主键有直接关系而不是间接关系. 像: a -> b -> c, 属性之间含有这样的关系, 是不符合第三范式的.
比如 Student表 (学号, 姓名, 年龄, 性别, 所在院校, 院校地址, 院校电话)
这样一个表结构, 就存在上述关系: 学号 -> 所在院校 -> (院校地址, 院校电话)
这样的表结构, 我们应该拆开来: (学号, 姓名, 年龄, 性别, 所在院校) – (所在院校, 院校地址, 院校电话)
三大范式只是一般设计数据库的基本理念, 可以建立冗余较小、结构合理的数据库.
如果有特殊情况, 当然要特殊对待, 数据库设计最重要的是看需求跟性能, 需求 > 性能 > 表结构. 所以不能一味的去追求范式建立数据库.