数据库设计范式解释

数据库设计范式解释(转载)

第一范式（ 1NF ）：在关系模式 R 中的每一个具体关系 r 中，如果每个属性值都是不可再分的最小数据单位，则称 R 是属于第一范式的关系。

第二范式（ 2NF ）：如果关系模式 R （ U ， F ）中的所有非主属性都完全依赖于任意一个候选关键字，则称 R 是属于第二范式的。

第三范式（ 3NF ）：如果关系模式 R （ U ， F ）中的所有非主属性对任何候选关键字都不存在传递信赖，则称 R 是属于第三范式的。

第一范式是关系数据库的最小要求

比如

 

姓名                     性别                     身高

Billy                    Male               180CM

这就是第一范式 .

如果改成

                                                        三                                  围     

姓名                     性别                     胸围          臀围          腰围

这个就不是第一范式了 .

 

第二范式说通俗一点就是不存在部分依赖 , 举例如下 :

促销员的销量表 , 字段为促销员 OID, 产品 OID, 产品颜色 , 产品重量

业务上主键应该为 促销员 OID 和产品 OID

但是产品颜色和产品重量显然依赖于产品 OID, 不能因为某个促销员长得漂亮产品颜色就艳丽一些 .

所以产品颜色和产品重量就部分依赖于候选主键促销员 OID 和产品 OID, 这样就满足第二范式 .

 

 

第三范式说通俗一点就是不存在传递依赖 . 举例如下 :

促销员表 , 字段为促销员 OID, 所属销售部 OID, 销售部地址 .

那么促销员 OID 是业务主键 , 由于只有一个字段做主键 , 所以肯定不存在部分依赖

但是这个存在传递依赖

促销员 OID 决定了所属销售部 OID, 而所属销售部又能决定销售部地址 .

所以销售部地址间接依赖于销售部 OID

于是存在传递依赖 .

 

 

由于我们采用 OID 一个字段做表的主键 , 所以肯定满足第二范式 . 至于满不满足第三范式就要分析一下了 .

但是有些情况下是需要保存历史信息的

比如销售部的地址变动了

这些另当别论 , 打破第三范式就好了

另外联合查询的性能损失很大 , 有时候破坏范式来换取报表的运行效率也是值得的 .

 

|----------------------------------------------------------------------------------------|
                           版权声明  版权所有 @zhyiwww
            引用请注明来源 http://www.blogjava.net/zhyiwww   
|----------------------------------------------------------------------------------------|