数据库三范式

对于软件开发人员来说，平时接触不到数据库设计方面的工作，但适当掌握数据库的一些理论知识，可以帮助我们更好地构建和理解软件项目。

我们以数据库三范式为例。

1NF：每一列都不可分割。

一范式好理解，表里面每一列都不允许是组合项，不然就不满足一范式的要求。

2NF：在1NF基础上，要求主键必须唯一。

二范式也好理解，你设计一个数据库出来，不能用一个主键查出来多条记录，不满就不满足二范式设计。

3NF：在2NF基础上，任何非主属性不依赖于其它非主属性。

三范式有些不好理解了，这基本就是《数据库原理》那类专业书籍里面下的定义。用人话来讲，"一个表中的列没有引用其它表中的非主键列，就是满足三范式的"。还是不好理解？看完下面这个例子，就一目了然。

公司A有两个部门，目前有一个部门信息表和一个员工信息表，主键分别是部门编号和员工编号。

部门编号（主键）	部门名称	部门简介	部门经理
A001	Sales	销售部，负责XXX	David
B001	Develop	开发部门，负责XXX	Jackson
C001	Public Relationship	公关部门，负责XXX	Heidi
D001	Operation	运营部门，负责XXX	Frank

员工编号（主键）	员工姓名	员工性别	员工年龄	等级	联系方式
0001	J1	F	28	10	135XXXXXXXX
0002	J2	M	30	09	158XXXXXXXX
0003	J3	F	34	08	139XXXXXXXX
0004	J4	M	29	10	136XXXXXXXX

这两张表，它们都满足1NF和2NF，目前没有任何关联关系。

现在我们业务需要，在查询员工信息时，找出员工的经理是谁。那我们在设计这种关联关系时，3NF的要求是，部门信息表里已经列出了部门经理信息，那么就不需要在员工表中为每一个员工再添加部门经理这一列，不然就不符合3NF设计。

因为容易造成数据冗余。

不是说不能这么做，但是不建议这么做。

正确的做法是，在员工表中引用部门信息表的主键（部门编号）作为一个外键，这样来查询部门经理是谁。

目前先介绍到3NF，3NF后面还有BCNF和4NF、5NF、6NF等等，当数据库设计得越复杂，相应的范式要求就越高。一个数据库系统庞大起来，表与表之间的关联关系会越来越多，对应的约束要求也就越来越多。这就是后面几个范式发挥作用的地方。