数据库设计之范式

数据库设计总共分为6个阶段，如下图所示，而数据库的逻辑结构设计需要用到范式，下面就一起来了解下什么是范式。

 

范式解决的问题：

1、数据冗余

2、插入异常

3、删除异常

4、更新异常  

数据库表如果设计不当，一来可能会占用过多的空间，影响查询的效率，二来也会为后面的编程带来不必要的麻烦，三来还会影响数据库的完整性。因此，有必要对数据库表进行范式的优化。

下面介绍范式的定义，以及定义的部分解释。

• 第一范式（1NF）：符合1NF的关系中的每个属性都不可再分。
• 第二范式（2NF）：消除了非主属性对于码的部分函数依赖。

“函数依赖”：在属性（或属性组）X确定的情况下，必定能确定属性Y的值，即Y依赖于X，记作X -> Y。举个栗子，函数f(X) = Y，X通过函数f()映射到Y，Y函数依赖于X。或者如下图，知道城市就能知道省份，所以省份函数依赖于城市。

“完全函数依赖”：若X -> Y，且对于X的任何一个真子集X’，X’ -> Y 不成立，则Y对于X完全函数依赖。

“部分函数依赖”：若X -> Y，但Y并不完全依赖于X，则称Y部分依赖于X。举个栗子，完全函数依赖：{学号,课程号}-->成绩，学号和课程号可以决定成绩，但是单独的学号或者单独的课程号不能决定成绩；部分函数依赖：{学号,课号}-->姓名，只有学号能决定姓名。

“码”：设K为某表中的一个属性或属性组，若除K之外的所有属性都完全函数依赖于K，那么称K为候选码，简称码。

“主属性”：包含在任何一个码中的属性称为主属性。

• 第三范式（3NF）：消除了非主属性对于码的传递函数依赖。

至少要有三个属性才可能存在传递的函数依赖关系

• BCNF（Boycee Codd Normal Form）范式：所有非主属性对每一个候选键都是完全函数依赖；所有的主属性对每一个不包含它的候选键，也是完全函数依赖；没有任何属性完全依赖于非候选键的任何一组属性。

候选键（candidate key）：是某个关系变量的一组属性所组成的集合，它需要同时满足下面两个条件：
1、这个属性集合始终能够确保在关系中能唯一标识元组。
2、在这个属性集合中找不出合适的真子集能够满足条件。
满足第一个条件的属性集合称为超键，因此我们也可以把候选键定义为"最小超键"，即不含有多余属性的超键。

 

总结：
1NF： 字段是最小的的单元不可再分
2NF：满足1NF,表中的字段必须完全依赖于全部主键而非部分主键 (一般我们都会做到)
3NF：满足2NF,非主键外的所有字段必须互不依赖
4NF：满足3NF,消除表中的多值依赖

后续：   
主键：唯一表示表中的某一行的属性或属性组，一个表只能有一个主键，但是可以有多个候选索引  
主码：当有多个候选码时，可以选定一个作为主码，选定的候选码称为主键，主码可以有多个  
码：唯一标识实体的属性，它是整个实体集的性质。包括超码，候选码，主码。
超码：如果K是一个超码，那么K的任意超集也是超码，即如果K是超码，那么包含K的集合也是超码。
候选码：最小超码，包含K的集合都不能是候选码