数据库设计范式解释

数据库设计范式解释

关键字: 数据库 范式

第一范式（ 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 一个字段做表的主键 , 所以肯定满足第二范式 . 至于满不满足第三范式就要分析一下了 .

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

比如销售部的地址变动了

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

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

目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。