关系数据库设计规范化

基础知识

关系数据库设计的目标是生成一组合适的、性能良好的关系模式，以減少系统中信息存储的冗余度，但又可方便地获取信息。

数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，是现实世界属性间联系和约束的抽象，是数据内在的性质，是语义的体现。函数依赖则是一种最重要、最基本的数据依赖。

函数依赖：设R(U)是属性集U上的关系模式，X和Y是U的子集。若R(U)的任何一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的值不等，则称X函数决定Y或Y函数依赖于X，记作X->Y。

• 如果X->Y，但$Y⊊X$，则称X->Y是非平凡的函数依赖。如(Sno,Cno)->Sno。
• 如果X->Y，但$Y\subseteq X$，则称X->Y是平凡的函数依赖。如(Sno,Cno)->Grade。

任何可能的关系：若X->Y，则X叫做决定因子；若X->Y，Y->X，则记做X<–>Y；若Y函数不依赖于X，则记作$X\ne >Y$。

常见的函数依赖：

• 完全函数依赖：在R(U)中，设X->Y，且对于X的任何一个真子集$X^{{}^{\prime }}$，都有$X^{{}^{\prime }}$不能决定Y，则称Y对X完全函数依赖。如(Sno,Cno)->Grade，但$Sno\ne >Grade$。
• 部分函数依赖：在R(U)中，设X->Y，但Y不完全依赖于X，则称Y对X部分函数依赖。
• 传递函数依赖：在R(U,F)中，如果X->Y，$Y⊊X，Y\ne >X$，Y->Z，则称Z对X传递函数依赖。如Sno->Sdept、Sdept->Mname，则Sno->Mname。

多值函数依赖：在R(U,F)中，其属性集为U。X、Y、Z是U的子集，并且Z=U-X-Y。当且仅当对R(U)的任何一个关系r，给定一对(x,z)的值，这组值仅仅决定于x值而与z值无关，则称“Y多值依赖于X”或“X多值决定Y”，记X->->Y。

多值依赖具有6种性质：

• 具有对称性。若X->->Y，则X->->Z，其中Z=U-X-Y。
• 传递性。若X->->Y，Y->->Z，则X->->Z-Y。
• 函数依赖可以看成是多值依赖的特殊情况。
• 若X->->Y，Y->->Z，则X->->YZ。
• 若X->->Y，Y->->Z，则X->->$Y\cap Z$。
• 若X->->Y，Y->->Z，则X->->Z-Y。

Armstrong 公理系统：设关系模式R(U,F)，其中U为属性集，F是U上的一组函数依赖，那么有一下推理规则：

• 自反律：若$Y\subseteq X\subseteq Z$，则X->Y为F所逻辑蕴含。
• 增广率：若X->Y为F所逻辑蕴含，且$Z\subseteq U$,则XZ->YZ为F所逻辑蕴含。
• 传递率：若X->Y和Y-Z为F所逻辑蕴含，则X->Z为F所逻辑蕴含。
• 合并规则：若X->Y，X->Z，则X->YZ为F所蕴含。
• 传递递率：若X->Y，WY->Z，则XW->Z为F所蕴含。
• 分解规则：若X->Y，$Z\subseteq Y$，则X->Z为F所蕴含。

最小函数依赖集：如果函数依赖集F满足下列条件，则称F为一个最小函数依赖集，或极小哈书依赖集或最小覆盖。

• F种任一函数依赖的右部仅有一个属性，即无多余的属性。
• F种不存在这样的函数依赖X->A，使得F与 F − { X − A } F-\{X-A\} F−{X−A}等价，即无多余的函数依赖。
• F种不存在这样的函数依赖X->A，X有真子集Z使得F与 F − { X − > A } ∪ { Z − > A } F-\{X->A\}\cup \{Z->A\} F−{X−>A}∪{Z−>A}，即去掉各函数依赖左边的多余属性。即不存在部分函数依赖。

函数闭包：在关系模式R(U,F)中被F逻辑蕴含的函数依赖的全体构成的集合称F闭包，记作$F^{+}$。

求候选码：用图解法确定候选码：

1. 将关系的函数依赖关系，用“有向图”的方式表示。
2. 找出入度为0的属性，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键。
3. 若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点（既有入度，也有出度的结点）并入入度为0的属性集中，直至该集合能遍历所有结点，集合为候选键。

示例1：给定关系R(A1,A2,A3,A4)上的函数依赖集F={A1->A2,A2->A3,A3->A2,A2->A4}，R的候选关键字为A1。

示例2：关系R(A,B,C)满足下列函数依赖：F{B->C,B->A,A->BC}，关系R的候选键为A和B。

规范化

示例：First(Sno,Sname,Status,City,Pno,Qty)，F={Sno->Sname,Sno->Status,Status->City,(Sno,Pno)->Qty}

1NF（第一范式）

若关系模式R中，每个数据项都是不可再分的，则称R属于第一范式，简称1NF，记作$R\in 1NF$。

1NF存在4个问题：

• 冗余度大。部分列可进行再分，部分列代表的信息量大。
• 引起修改操作的不一致性。由于部分列数据行数相同，进行更新会引起不一致。
• 插入异常。主码不能取空值或部分为空值，当插入时会异常。
• 删除异常。如果某个产品不销售了，删除后无法再找回该产品，但是该产品客观存在。

2NF（第二范式）

若关系模式$R\in 1NF$，并且每一个非主属性都完全依赖于R的码，则称R属于第二范式，简称2NF，记作$R\in 2NF$。也就是说，1NF基础上消除了非主属性对码的部分函数依赖。主要进行分解关系模式。如First关系分解为First1(Sno,Sname,Status,City)和First2(Sno,Pno,Qty)。

3NF（第三范式）

若关系模式R(U,F)中不存在这样的码X，属性组Y及非属性Z($Z⊊Y$)使得X->Y，（YKaTeX parse error: Undefined control sequence: \eq at position 1: \̲e̲q̲>X)Y->Z，则关系模式$R\in 3NF$。2NF基础上消除了非主属性对码的传递函数依赖，则称3NF。由于First1中有Sno->Status,Status->City存在传递，First1分解为First11(Sno,Sname,Status)和First12(Status,City)。

产生冗余和异常的两个重要原因是部分依赖和传递依赖。因为3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖，所以具有较好的性能。

BCNF（Boyce Codd Normal Form，巴克斯范式）

关系模式$R\in 1NF$，若X->Y且$Y⊊X$时，X必含有码，则关系模式$R\in BCNF$。也就是说，当3NF消除了主属性对码的部分函数依赖和传递函数依赖，则称为BCNF。

性质如下：

• 所有非主属性对每个码都是完全函数依赖。
• 所有主属性对每一个不包含它的码，也是完全函数依赖。
• 没有任何属性完全函数依赖于非码的任何一组属性。

示例：设R(Pno,Pname,Mname)的属性分别表示零件号、零件名和厂商名，如果约定，每种零件号只有一个零件名，但不同的零件号可以有相同的零件名；每种零件可以有多个厂商生产，但每家厂商生产的零件应有不同的零件名。这样我们可以得到如下一组函数依赖：Pno->Pname,(Pname,Mname)->Pno。

该关系模式R的候选码为(Pname,Mname)或(Pno,Mname)，属性都是主属性，不存在非主席对码的传递依赖，是3NF，但主属性传递依赖于码(Pname,Mname)，不是BCNF，可以分解成R1(Pno,Pname)和R2(Mname)。

4NF（第四范式）

关系模式$R\in 1NF$，若对于R的每个非平凡多值依赖X->->Y且$Y⊊X$时，X必含有码（不为空），则关系模式$R(U,F)\in 4NF$。4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。如x、y、z，x–> y，z 为空集，则为平凡多值依赖，反之为非平凡多值依赖。

模式分解

分解：关系模式R(U,F)的一个分解 ρ = { R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , . . . , R n ( U n , F n ) } \rho=\{R_1(U_1,F_1),R_2(U_2,F_2),...,R_n(U_n,F_n)\} ρ={R1​(U1​,F1​),R2​(U2​,F2​),...,Rn​(Un​,Fn​)}，其中，$U=\bigcup _{i=1}^n{U}_i$，并且没有$U_i\subseteq U_j(1\le i,j\le n)$，$F_i$是F在$U_i$上的投影， F i = { X − > Y ∈ F + ∧ X Y ⊆ U i F_i=\{X->Y\in F_{+} \wedge XY \subseteq U_i Fi​={X−>Y∈F+​∧XY⊆Ui​。

分解成n个关系，分解的属性都要在子表中，并且子表没有交叉关系，

对一个给定的模式进行分解，使得分解后的模式是否与原来的模式等价有三种情况：

• 分解具有无损连接性。
• 分解要保持函数依赖。
• 分解既要无损连接性，又要保持函数依赖。

示例：关系模式Std(Sno,Sdept,Mname)，其属性组上的函数依赖集是F={Sno->Sdept,Sdept->Mname}
a) R11(Sno,Mname)和R12(Sdept,Mname)
b) R21(Sno,Sdept)和R22(Sno,Mname)
c) R31(Sno,Sdept)和R32(Sdept,Mname)
d) R41(Sno)、R42(Sdept)和R43(Mname)

无损连接：关系模式R(U,F)分解为关系模式 ρ = { R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , . . . , R n ( U n , F n ) } \rho=\{R_1(U_1,F_1),R_2(U_2,F_2),...,R_n(U_n,F_n)\} ρ={R1​(U1​,F1​),R2​(U2​,F2​),...,Rn​(Un​,Fn​)}，如果对于R的每一个满足F的具体关系r，都有$r={\pi }_{R_1}(r)\times {\pi }_{R_2}(r)\times ...\times {\pi }_{R_n}(r)$，即r在$R_1,R_2,...R_n$上投影的自然连接等于r，则称分解$\rho$具有无损连接。分解后的每个表合并后记录数和列不变，具有无损连接的充分必要条件是$$U_1\cap U_2->U_1-U_2\in F^{+}或U_1\cap U_2->U_2-U_1\in F^{+}$$

保持函数依赖：关系模式R(U,F)分解为关系模式 ρ = { R 1 ( U 1 , F 1 ) , R 2 ( U 2 , F 2 ) , . . . , R n ( U n , F n ) } \rho=\{R_1(U_1,F_1),R_2(U_2,F_2),...,R_n(U_n,F_n)\} ρ={R1​(U1​,F1​),R2​(U2​,F2​),...,Rn​(Un​,Fn​)}，如果$F^{+}=(F_1\bigcup F_2\bigcup ...\bigcup F_n{)}^{+}$，即F所逻辑蕴含的函数依赖一定也由分解得到的某个关系模式中的函数依赖$F_i$逻辑蕴含，则称分解$\rho$是保持函数依赖。

分解具有无损连接性和分解具有保持函数依赖是两个相互独立的标准。具有无损连接性的分解不一定保持函数依赖。保持函数依赖的分解也不一定具有无损连接性。

示例1：关系模式Std(Sno,Sdept,Mname)，其属性组上的函数依赖集是F={Sno->Sdept,Sdept->Mname}

• a) R11(Sno,Mname)和R12(Sdept,Mname)。 F 1 ⋃ F 2 = { S n o − > M n a m e , S d e p t − > M n a m e } F_1\bigcup F_2=\{Sno->Mname,Sdept->Mname\} F1​⋃F2​={Sno−>Mname,Sdept−>Mname}，无Sno->Mname，不保持函数依赖。
• b) R21(Sno,Sdept)和R22(Sno,Mname) 。分析：$U_1\cap U_2=Sno\to U_1-U_2=Sdept$，具有无损连接性。
• c) R31(Sno,Sdept)和R32(Sdept,Mname)。分析：$U_1\cap U_2=Sdept\to U_2-U_1=Mname，U_1-U_2=Sno$，具有无损连接性。 F 1 ⋃ F 2 = { S n o − > M n a m e , S d e p t − > M n a m e } F_1\bigcup F_2=\{Sno->Mname,Sdept->Mname\} F1​⋃F2​={Sno−>Mname,Sdept−>Mname}，都有，则保持函数依赖。
• d) R41(Sno)、R42(Sdept)和R43(Mname)。

示例2：设关系模式R(U,F)，其中U={A,B,C,D,E}，F={A->BC,C->D,BC->E,E->A}，则分解成$\rho =${R1(ABCE),R2(CD)}满足具有无损连接和保持函数依赖。

分析：$U_1\cap U_2=C\to U_1-U_2=ABEor{U}_2-U_1=D$，具有无损连接性。F中的决定在分解的子表都存在。

总结

关系数据库设计的规范化是构建高效、可靠数据库系统的基础。它要求设计师深入理解并应用第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Boyd-Codd范式（BCNF）以及第四范式（4NF）。这些范式旨在引导设计师逐步消除数据中的冗余和更新异常，从而确保数据的原子性、独立性和稳定性。

在规范化的过程中，模式或表的分解是一个核心环节。设计师需要通过模式分解来保持函数依赖和无损连接，这意味着在分解过程中既要确保数据不丢失，又要维持数据间的内在联系。这种精细的操作不仅有助于提高数据的访问效率，还能保证数据在不同表之间的一致性和完整性。

除了遵循规范化原则，数据库设计还需考虑性能优化和可扩展性。设计师应通过合理的索引策略、查询优化和适当的硬件配置来提升数据库的性能。同时，设计应具备灵活性，以便在未来能够适应业务需求的变化和技术的更新。