数据库的三大范式是什么？
在传统的关系型数据库中，数据以表的形式存储在数据库中，对于数据库表的设计原则就称为数据库三大范式，数据库表设计的三大范式详细内容如下：
- 第一范式（1NF）：规范化，数据库中的所有字段必须具有原子性，即不可拆分的最小单元。比如：常见的地址字段，就可以拆分为国家、省份、城市、区县、乡镇、村组等。单个的地址是不遵循第一范式的，但经常会发现这种设计
- 第二范式（2NF）：消除部分依赖，在第一范式的基础上，非主键字段只能依赖主键，而不是主键的一部分。比如：下表设计：
工号 员工姓名 部门编号 部门名称 部门评分 001 张三 B001 部门B A+ 002 李四 A001 部门A A- 003 王妈 C005 部门C B+ - 如果工号是主键，根据工号可以确定一个唯一的员工姓名，但是不能确定一个唯一的部门和部门评分
- 如果部门编号是主键，根据部门编号可以确定一个唯一的部门和评分，但是不能确认员工姓名
- 如果使用工号+部门作为联合主键，可以确定一个唯一的员工姓名，也可以确定一个唯一的部门名称和部门评分，但是这样的设计是不符合第二范式的
如果需要将其修改为符合第二范式的设计，需要将其拆分为以下两张表：
工号 员工姓名 001 张三 002 李四 003 王妈 部门编号 部门名称 部门评分 B001 部门B A+ A001 部门A A- C005 部门C B+ 修改之后，第一张表使用工号可以确认唯一的员工姓名，第二张表也可以使用部门编号确认唯一的部门名称和部门评分，符合第二范式
- 第三范式（3NF）：消除传递依赖，在第二范式的基础上，非主键字段必须直接依赖主键，而不能通过非主键字段间接依赖主键。还是用工号来举例，比如：
工号 员工姓名 部门名称 部门领导 001 张三 部门B 张无 002 李四 部门A 王思 003 王妈 部门C lima - 如果使用工号作为主键，可以确定唯一的其他字段，符合第二范式
- 但是我们发现，通过部门名称也可以确定唯一的部门领导，在这张表中，部门领导通过部门名称，与工号形成了传递依赖，不符合第三范式
如果要符合第三范式，将其修改如下：
工号员工姓名 部门名称 001 张三 部门B 002 李四 部门A 003 王妈 部门C 部门名称 部门领导 部门B 张无 部门A 王思 部门C lima 这样就消除了传递依赖，符合第三范式。
除上述三种范式外，还有一些其他的数据库表设计原则，如第四范式、第五范式、巴斯范式(BCNF)、反范式等，有兴趣可以了解一下。
