数据库 - 范式(Normal Form, NF)

K为R<U,F>中的属性或属性组合。若K    U,  则K称为R的侯选码,或候选键(Candidate Key)。
     若候选码多于一个,则选定其中的一个做为主码,或主键(Primary Key)。

主属性与非主属性
包含在任何一个候选码中的属性 ,称为主属性(Prime attribute)
不包含在任何码中的属性称为非主属性(Nonprime attribute)或非码属性(Non-key attribute)
全码
整个属性组是码,称为全码(All-key)

[例2]
    关系模式S(Sno,Sdept,Sage),单个属性Sno是码,
    SC(Sno,Cno,Grade)中,(Sno,Cno)是码
[例3]
       关系模式R(P,W,A)
       P:演奏者     W:作品    A:听众
       一个演奏者可以演奏多个作品
       某一作品可被多个演奏者演奏
       听众可以欣赏不同演奏者的不同作品
       码为(P,W,A),即All-Key  
关系模式 R 中属性或属性组X 并非 R的码,但 X 是另一个关系模式的码,则称 X 是R 的外部码(Foreign key)也称外码
如在SC(Sno,Cno,Grade)中,Sno不是码,但Sno是关系模式S(Sno,Sdept,Sage)的码,则Sno是关系模式SC的外部码 
主码与外部码一起提供了表示关系间联系的手段

范式(Normal Form, NF)

范式是符合某一种级别的关系模式的集合
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式
范式的种类:
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)
各种范式之间存在联系:

某一关系模式R为第n范式,可简记为R∈nNF。
一个低一级范式的关系模式,通过模式分解可以转换为若干个高一级范式的关系模式的集合,这种过程就叫规范化

2NF

1NF的定义
如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF
第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库模式
但是满足第一范式的关系模式并不一定是一个好的关系模式

[例4] 关系模式 S-L-C(Sno, Sdept, Sloc, Cno, Grade)
    Sloc为学生住处,假设每个系的学生住在同一个地方

函数依赖包括:
           (Sno, Cno) F  Grade
           Sno → Sdept
           (Sno, Cno)  P  Sdept
           Sno → Sloc
           (Sno, Cno) P   Sloc
           Sdept → Sloc (语义:每个系的学生住在同一个地方)

S-L-C的码为(Sno, Cno)
S-L-C满足第一范式。
非主属性Sdept和Sloc部分函数依赖于码(Sno, Cno)
(1) 插入异常
(2) 删除异常
(3) 数据冗余度大
(4) 修改复杂
S-L-C不是一个好的关系模式

原因
      Sdept、 Sloc部分函数依赖于码。
解决方法
     S-L-C分解为两个关系模式,以消除这些部分函数依赖 
            SC(Sno, Cno, Grade)
                   S-L(Sno, Sdept, Sloc)
2NF的定义
    定义6.6  若R∈1NF,且每一个非主属性完全函数依赖于码,则R∈2NF。

    例:S-L-C(Sno, Sdept, Sloc, Cno, Grade) ∈1NF
           S-L-C(Sno, Sdept, Sloc, Cno, Grade) ∈2NF     
           SC(Sno, Cno, Grade) ∈ 2NF
            S-L(Sno, Sdept, Sloc) ∈ 2NF

将一个1NF的关系分解为多个2NF的关系,可以在一定程度上减轻原1NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

将一个1NF关系分解为多个2NF的关系,并不能完全消除关系模式中的各种异常情况和数据冗余。
分解成2NF模式集的算法
设关系模式R(U),主键是W,R上还存在FD X→Z,并且Z是非主属性和X?W,那么W→Z就是一个局部依赖。此时应把R分解成两个模式
R1(XZ),主键是X;
R2(Y),其中Y=U-Z,主键仍是W,
外键是X(REFERENCES R1)。
利用外键和主键的连接可以从R1和R2重新得到R。
如果R1和R2还不是2NF,则重复上述过程,一直到数据库模式中每一个关系模式都是2NF为止。
请思考: 一个关系模式为R(A,B,C,D),假定该关系存在着如下函数依赖:A→B,A→C,C→D,则该关系模式属于第几范式?为什么?

该关系模式属于2NF,因为键是A,不存在部分函数依赖。但存在非主属性对键的传递函数依赖,故不属于3NF

3NF

3NF的定义
    定义6.7  关系模式R<U,F> 中若不存在这样的码X、属性组Y及非主属性Z(Z ∈ Y), 使得X→Y,Y→Z成立, 
    Y → X,则称R<U,F> ∈ 3NF。
若R∈3NF,则每一个非主属性既不部分依赖于码也不传递依赖于码。(可以证明)

定理:如果R是3NF模式,那么R也是2NF模式。
证明:只要证明模式中局部依赖的存在蕴涵着传递依赖即可。设A是R的一个非主属性,K是R的一个候选键,且K→A是一个局部依赖。那么R中必存在某个K’?K,有K’→A成立。由于A是非主属性,因此A∩KK’=φ。从K’?K,可知 K’→K,但K→K’成立。因而从K→K’ 和K’→A可知K→A是一个传递依赖。
局部依赖和传递依赖是模式产生冗余和异常的两个重要原因。由于3NF模式中不存在非主属性对候选键的局部依赖和传递依赖,因此消除了很大一部分存储异常,具有较好的性能。

3NF还有下面一个等价的定义,如下所述。
定义6.7.1 设F是关系模式R的FD集,如果对F中每个非平凡的FD X→Y,都有X含有码,或者Y的每个属性都是主属性,那么称R是3NF的模式。
这个定义表明,如果非平凡的FD X→Y中Y是主属性,则X→Y不违反3NF条件;如果Y是非主属性,且X不含有码,则必存在着候选码W有W→X,此时就有W→Y是一个传递依赖,即R不是3NF模式。

例:2NF关系模式S-L(Sno, Sdept, Sloc)中
函数依赖:
          Sno→Sdept
          Sdept → Sno
          Sdept→Sloc
          可得:          
         Sno→Sloc,即S-L中存在非主属性对码的传递函数依
         赖,S-L3NF

将一个2NF的关系分解为多个3NF的关系,可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

将一个2NF关系分解为多个3NF的关系后,仍然不能完全消除关系模式中的各种异常情况和数据冗余。
分解成3NF模式集的算法
设关系模式R(U),主键是W,R上还存在FD X→Z。并且Z是非主属性,Z?X,X不是候选键,这样W→Z就是一个传递依赖。此时应把R分解成两个模式:
R1(XZ),主键是X;
R2(Y),其中Y=U-Z,主键仍是W,
外键是X(REFERENCES R1)。利用外键和主键相匹配机制,R1和R2通过连接可以重新得到R。
如果R1和R2还不是3NF,则重复上述过程,一直到数据库模式中每一个关系模式都是3NF为止。

综合实例

设有关系模式R(职工名,项目名,项目费,部门名,部门经理),如果规定每个职工可以参加多个项目,每参加一个项目,就有一份项目费;每个项目只属于一个部门管理;每个部门只有一个经理。
给出关系模式R的基本函数依赖FD和候选键。
R的基本FD有3个:
(职工名,项目名)→项目费
项目名→部门名
部门名→部门经理
关系模式 R 的候选键为:(职工名,项目名)
R是否为2NF 模式?若不是,把R分解成2NF模式集。
R中有下面两个FD:
(职工名,项目名)→(部门名,部门经理)
项目名→(部门名,部门经理)
因为存在非主属性组(部门名,部门经理)对候选键(职工名,项目名)的局部函数依赖,所以R不是2NF。 R应分解成下列两个模式:
R1(职工名,项目名,项目费) R2(项目名,部门名,部门经理) R1与R2均为2NF。
R1,R2是否为3NF 模式?若不是,将其分解成3NF模式集。
R1已经是3NF。
在R2中存在非主属性‘部门经理’对候选键‘项目名’的传递函数依赖,所以R不是3NF。 R2应进一步分解成下列两个模式:
R21(项目名,部门名) R22(部门名,部门经理)
R21与R22均为3NF。最终,R分解成{R1,R21,R22}。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。