RDB的规范化理论（函数依赖+范式）

 

一、概念分析

 

1、函数依赖：这个概念术语语义范畴，只能根据语义确定属性间是否存在这种依赖，此外别无原则。就是说，从字面上读起来觉得“A能唯一确定B”这句话是通顺的、不违反你的常规逻辑的，那么B就函数依赖于A，我记作A→B.

    a、区别完全函数依赖和部分函数依赖：

    存在一个关系R（U）（U是一个关系的所有属性），如有X、Y属于U且满足X→Y，且对于任何X的真子集X1 都有Y不函数依赖于X1，则称Y完全函数依赖于X,我暂时记作

X  →(f)  Y。

如果A  →(f)  B，那么(A ,C) →(p)  B  （部分函数依赖）。

 

    

     b、区分直接函数依赖和传递函数依赖：

在R(U)  中，如果X→Y，(Y不属于X)，X不函数依赖与Y，Z函数依赖于Y，则称Z对X传递函数依赖。

 

2、范式：

 

范式和规范化方法，规范化目的是介绍冗余和异常：

 

 

 

第一范式（1NF）：R中每个属性都是不可分的原子值

第二范式（2NF）：R(U)中每个非主属性完全函数依赖与关键字。

第三范式（3NF）：R(U)中每个非主属性都不部分依赖也不传递依赖于关键字，则称R满足第三范式。

BCNF（扩充的第三范式）：如R(U)中X，Y属于U，假定满足R属于1NF，且若Y非平凡函数依赖于X时X必含关键字，则称R满足BCNF。

 

 

 

二、实例说明：

 

这些概念比较抽象，所以我设计了“博客系统”的几个表来应用上面的理论：

 

用户信息表userinfo:

 

 

 

 

 

 

 

 

 

显然，这三个表都满足1NF。

 

接着，因为三个表的primary不是复合主键，所以不存在部分函数依赖的关系。所以，满足2NF。如果user的主键是id+name，因为id→pwd，那么将不满足完全函数依赖的关系。

 

接着，在reviews表中，Id→Buttetin_board_name→Ins_id，并且Buttetin_board_name→id不成立，所以Ins_id间接函数依赖于id，所以不满足3NF。

 

最后，显然不满足BCNF：如userinfo表中的name→pwd，name中不含关键字。