第一范式(
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
|----------------------------------------------------------------------------------------|
posted on 2006-06-13 13:54
zhyiwww 阅读(769)
评论(0) 编辑 收藏 所属分类:
database