数据库范式详解

1NF:要有主键，列不可分

2NF:非候选码属性（也称非主属性）不部分依赖于候选码。

例如：教学表：有学号，学生名字，教工号，教师名字4个属性，这样的表示不符合2NF的，因为如果这样的表存在，主键必然是学号+教工号，这样的话学生姓名就部分依赖于主键，教师名字也部分依赖于主键。这张表应该分为3张表，学生信息表：学号，学生名字；教工信息表：教工号，教师名字；教学关系表：学号，教工号。

3NF:满足2NF且非候选码属性不能传递依赖于候选码。

例如：员工表：id 姓名 所属部门id ，主键为id后面不能再跟部门名字，部门简介等，这样的话部门名字和部门简介就传递依赖于id了。解决方法：再建立一个部门表:部门id   部门名字   部门简介。

BCNF:每个属性（包括候选码属性）不能部分依赖于候选码，也不能传递依赖于候选码。

用函数依赖描述部分范式：

BCNF:函数依赖集F的闭包F+中所有的a->b，满足下面至少一项，则为bc范式：

         1,a->b是一个平凡的函数依赖；

         2,a是模式R的一个超码。

3NF：函数依赖集F的闭包F+中所有的a->b，满足下面至少一项，则为第三范式：

         1,a->b是一个平凡的函数依赖；

         2,a是模式R的一个超码；

         3,b-a中的每个属性A都包含于R的一个候选码中。

4NF:函数依赖和多值依赖集D的闭包D+中所有的a->->b，满足下面至少一项，则为第四范式：

         1，a->->b是一个平凡的多值依赖。（b包含于a，或者b并a等于R，则a->->b是平凡的）

         2，a是R的一个超码。

 

a->->b：a多值决定b，a和b的关系独立于a和R-b之间的联系。

 

4NF一定是BCNF，BCNF不一定是4NF；3NF不一定是BCNF，BCNF一定是3NF。（3NF<-BCNF<-4NF）

 

4NF分解：根据非平凡且a不为超码的多值依赖分解，无损，但不一定能保持依赖。

BCNF分解：根据非平凡且a不为超码的依赖来分解，无损，但不一定保持依赖。

3NF分解：根据正则覆盖来分解，无损且保持依赖。

 

创建E-R设计的过程倾向于产生4NF设计。（一个多对多的联系集，实体集的一个多值属性）

 

数据库的设计目标：BCNF；无损；保持依赖。在不能保持依赖的BCNF分解情况下，我们也倾向于选择BCNF，因为虽然不能保持依赖，但是可以保证函数依赖约束中a为超码，在实际数据库中更容易表达。