数据库设计三大范式

为了减少数据冗余，设计数据表时必须遵循一定的规则，在关系型数据库中这种规则就称为范式。
严谨的定义可以参考维基百科第一范式、第二范式、第三范式，互联网上也有很多优秀的技术博客。本文希望以简洁的语句和例子进行描述。

第一范式 - 1NF

下面是一个不符合第一范式的例子：

其中的职务应该再分为部门和职务两个字段，因为业务中可能会经常分别用到这两个属性！

你可能在想地址字段是否应该拆分。甚至姓名也可以拆分成姓和名两个字段：

这个例子比上一个更好吗？哪一种设计更符合第一范式？事实上，两个例子都是符合的，具体的取舍要参考具体的业务。例如姓名、地址在业务中都整体出现，那么第二个例子就是最佳选择。如果业务涉及分别对所属省、市的操作，那么就应该将地址字段拆分为省和市。

第二范式 - 2NF

下面是一个不符合第二范式的例子：

这个例子中，成绩是针对某一学生的某一课程而言的，因此需要学号和课程代码作为联合主键才能确定；然而学生的学生姓名仅由学号就可以唯一确定，这就叫部分依赖于主键，因此不符合第二范式。正确的做法是将学生姓名和成绩分开存放于两张表中：

第三范式 - 3NF

即第三范式要求不存在传递依赖，非主键属性之间应该是独立无关的。

下面是一个不符合第三范式的例子：

这个例子不符合第三范式，因为存在间接的传递决定关系：id → 城市 → 城市人口。城市人口字段直接依赖的是城市字段，而不是主键id。正确的做法是设计两张表：