关系范式

函数依赖其实就如数学上的函数，Y=X+1，自变量X一定的情况下，因变量Y也确定了，那么就可以说Y的取值就依赖于X的取值。

• 函数依赖：（其实就是一一对应，知道A的值可以确定B的值，A→B，则称B依赖于A)
  两个实例化的属性集X,Y，如果属性集X中的两个元组取值相同，必有对应的另外一个属性集Y中元组取值相同，则称Y函数依赖于X函数。

  注意：如果属性集X中不存在两个取值相同的元组集合，则Y必定依赖于函数X，且函数X的属性集为超键。

• 部分函数依赖：设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

  例如：通过(A, B)→C，如果 A或B→C ，那么说C部分依赖于(A, B)。

• 完全函数依赖：设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

  例如：通过(A, B)→C，但是 A或B单独得不出C ，那么说C完全依赖于(A, B)。

• 传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

  例如：通过A→B，通过B→C，但是C得不到B，B得不到A，那么说C传递依赖于A。

BTW：很多人不理解为什么要反着说，不说X确定Y，而说Y依赖X。

其实很简单，创造者习惯于把主键(X)定下来当一个固定量，用非主键(Y)来跟主键部分比较，看看是否依赖。

规范化的过程可概括如下：

• 取原始的1NF关系投影，消去非主属性对键的部门函数依赖，从而产生一组2NF关系。
• 取2NF关系的投影，消去非主属性对键的传递函数依赖，产生一组3NF关系。
• 取这些3NF的投影，消去决定因素不是键的函数依赖。产生一组BCNF关系。
• 取这些BCNF关系的投影，消去其中不是函数依赖的非平凡多值依赖，产生一组4NF关系。

• 主属性：是在一个关系中构成某一个候选码的属性的其中一个属性。

范式：

• 第一范式：即 表中的每一个属性都是不可再分的。
• 第二范式：符合1NF，且所有的非主属性都完全依赖于主键。（任何非主属性都不能部分依赖任一侯选码（即 必须完全依赖））
• 第三范式：符合2NF，并要求任何非主属性不依赖于其他非主属性。（任何非主属性都不能传递依赖任一侯选码）
• BC范式（BCNF）：符合3NF，并且主属性内部不能有部分或传递依赖。（任何属性都不能传递依赖任一侯选码）
• 第四范式：消除多值依赖
• 第五范式：消除传递依赖

第一范式(1NF)

第一范式：属性（列）不可分割。

第一范式：所谓第一范式，就是数据表的列不可再分。
不过能不能再分并没有绝对的答案，看需求，也就是看你的设计目标而定。

例子：就比如说名字吧，我可以再分成英文名和中文名；电话我也可以分成移动电话和座机。

简单来说，第一范式是关系数据库的基础，但字段是否真的不可拆分，根据你的设计目标而定。

例如：

上面这个表明显是可以再分的，所以它是违反第一范式的。

修改：

第二范式(2NF)

第二范式：在1NF的基础上，任何非主属性都不能部分依赖任一侯选码（即 必须完全依赖） （消除部分依赖）

• 要求：在第一范式的基础上，且每一个非主属性完全函数依赖于候选码。
• 特点：
  • 满足第一范式。
  • 表中的每一个非主属性，必须完全依赖于本表主键。
  • 只有当一个表中，主码由两个或以上的属性组成的时候，才会出现不符合第二范式的情况。

例如：

上表主键为（学号，课程）
（学号，课程）→（成绩，学分），学号和课程可以唯一确定成绩和学分
但是对于学分来说，只需要知道课程就能确定学分了，所以学分部分依赖于（学号，课程），不满足第二范式。

修改：把它拆成两个表

第三范式(3NF)

第三范式：在2NF的基础上，任何非主属性都不能传递依赖任一侯选码，即 非主属性不依赖于其他非主属性。（消除传递依赖）

例如：

上表中，主键为（学号）。
很明显所有非主属性都依赖于主键，不存在部分依赖，满足第二范式。
但是，表中存在一个传递依赖，（学号）→（班级）→（班主任），即 非主属性（班级）依赖于其他非主属性（班主任）。
不满足第三范式。

修改：

BC范式(BCNF)

BC范式：在3NF基础上，任何字段都不能传递依赖任一侯选码。

更高级范式

还有第四范式、第五范式。
太麻烦了，基本不需要，所以这里就不介绍了。