数据库 - 范式(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-L ∈ 3NF

将一个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}。