【数据库学习笔记】Day06 – 关系数据库规范化理论

目录

一、关系数据库中存在的数据冗余问题
二、函数依赖
三、关系规范化

一、关系数据库中存在的数据冗余问题：

以学生信息表为例：

该关系模式存在诸多问题，最显著的问题就是数据冗余。
数据冗余是指同一信息在数据库中存储了多个副本，他可能引起下列问题：

• 冗余存储：信息被重复存储，导致浪费大量存储空间。
  （上表中学生的基本信息和宿舍楼被重复存储多次）
• 更新异常：当重复信息的一个副本被修改，所有副本都必须进行同样的修改。因此当更新数据时，系统要付出很大的代价来维护数据库的完整性，否则会面临数据不一致的危险。
  （上表中当修改某学生的系名时，还要修改宿舍楼信息）
• 插入异常：只有当一些信息事先已经存放在数据库中时，另外一些信息才能存入数据库中。
  (上表的主码为Sno和Cno，但如果一个学生没有选任何课程，或者一个课程未被任何学生选修，那该学生的信息将不能存入数据库，或该课程的信息无法存入数据库，因为主码值不能为空）
• 删除异常：删除某些信息时可能丢失其他信息。
  （当一学生的选修课程信息都被删除时，则该学生的信息可能会丢失）

综上所述，此关系模式不是一个好的模式。原因就在于模式中的某些数据依赖引起。解决方法就是通过分解关系模式来消除其中不合适的数据依赖。

二、函数依赖：

    数据的语义不仅表现为完整性约束，对关系模式的设计也提出了一定的要求。关系数据库的逻辑设计问题，一般为：应构造几个关系模式，每个关系模式由哪些属性组成等。

2.1 函数依赖的基本概念：

    函数依赖是指，只要给出一个具体的X函数值，就会有唯一一个Y值和它对应。记为X → Y。意思是X函数决定Y，或Y函数依赖于X。

2.1.1 完全函数依赖：
如果X → Y，并且对于X的一个任意真子集X’都有X’ !→ Y，则称Y完全函数依赖于X。
2.1.2 部分函数依赖：
如果X → Y成立，并且对于X的某个真子集X‘有X’→Y成立，则称Y部分函数依赖于于X。
2.1.3 传递函数依赖：
如果X → Y（非平凡函数依赖，且 Y !→ X），Y → Z，则称Z传递函数依赖于X。

如：关系模式SC (Sno,Sname,Cno,Grade)，主码为(Sno,Cno)，则函数依赖关系有：
Sno → Sname 姓名函数依赖于学号。
(Sno,Cno) → Sname 姓名部分函数依赖于学号和课程号。
(Sno,Cno) → Grade 成绩完全函数依赖于学号和课程号。

关系模式S （Sno,Sname,Dept,Dept_master ），主码为Sno。
Sno → Sname 姓名完全函数依赖于学号。
Sno → Dept 所在系完全函数依赖于学号。
Dept → Dept_master 系主任完全函数依赖于所在系。
所以有：Sno → Dept_master 系主任传递函数依赖于学号。

三、关系规范化：

    关系规范化是指将有“不良”函数依赖的关系模式转换为良好的关系模式的理论。这里涉及到范式的概念，不同的范式表示关系模式遵守的不同的规则。
    关系模式由五部分组成，是一个五元组：R（U，D，DOM，F）。

• R：关系名
• U：组成该关系的属性名集合
• D：属性组U中属性所来自的域
• DOM：属性向域的映像集合
• F：属性间数据的依赖关系集合

我们要做的是将R（U，D，DOM，F）简化为一个三元组R（U，F）。当且仅当U上的一个关系r满足F时，r称为关系模式R（U，F）的一个关系。

3.1 关系模式中的码：

3.1.1 候选码：
设K为R（U，F）中的属性或属性组，若K完全决定U，则K为R的候选码（候选码可以为一个属性，也可以为多个属性的组合）。
3.1.2 主码：
关系R（U，F）中可能有多个候选码，则选其中一个作为主码。
3.1.3 全码：
若一个关系的候选码为整个属性组，则称其为全码。
3.1.4 主属性：
包含在任一候选码中的属性称为主属性。
3.1.5 非主属性：
不包含在任一候选码中的属性称为非主属性。



3.1.6 外码：
关系之间建立关联的属性（组）。关系模式R中属性（组）X是另一个关系模式S的候选码（通常为主码），则称X为R的外码（Foreign Key）。

3.2 范式：

    关系数据库中的关系要满足一定的要求，满足不同程度要求的为不同的范式。
范式的种类：

• 第一范式（1NF）
• 第二范式（2NF）
• 第三范式（3NF）
• 扩展的第三范式（BCNF）
  
  一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化。

3.2.1 第一范式：
如果一个关系模式R的所有属性都是不可分的基本数据项，则R属于第一范式。第一范式是对关系模式最起码的要求，不满足第一范式的数据库模式不能称为关系数据库。但是满足第一范式的关系模式并不一定是一个好的关系模式。
3.2.2 第二范式：
如果R属于第一范式，而且R中的每一个非主属性都完全函数依赖于主码，则R属于第二范式。
若某个1NF的关系的主码只由一个码组成，那么这个关系就是2NF关系，但如果主码是由多个属性共同构成的复合主码，并且存在非主属性对主码的部分函数依赖，则这个关系就不是2NF。

第二范式目标是：将只部份依赖于主码（即依赖于主码的部分属性）的数据移到其他表中。
分解方法：

• 首先，对于组成主码的属性集合的每一个子集（递归列举所有子集），用它作为主码构成一个表。
• 然后，将依赖于这些主码的属性放置到相应的表中。
• 最后，去掉只由主码的子集构成的表。

例：分解S-L-C表（Sno,Sdept,SLOC,Cno,Grade）。

• 首先分解为如下形式的三张表：
  S-L（Sno，…）
  C（Cno，…）
  S-C（Sno，Cno，…）
• 然后将依赖于这些主码的属性放置到相应的表中，形成如下三张表：
  S-L(Sno,Sdept,SLOC)
  C(Cno)
  S-C(Sno,Cno,Grade)
• 最后，去掉只由主码的子集构成的表。

S-L-C关系模式最终分解的形式为：
S-L(Sno,Sdept,SLOC)
S-C(Sno,Cno,Grade）

分解后的关系模式的函数依赖关系：
S-L(Sno,Sdept,SLOC)
Sno → Sdept，Sno → SLOC 是2NF。
S-C(Sno,Cno,Grade)
(Sno,Cno) → Grade 是2NF。

但当前S-L表仍存在问题：
数据冗余：有多少个学生就有多少个重复的Sdept和SLOC。
插入异常：当新建一个系时，若还没有招收学生，则无法插入。

3.2.3 第三范式：
如果R属于2NF，并且所有非主属性都不传递依赖于码，则R属于3NF。
第三范式的目标是：去掉表中不依赖于主码的数据。
也就是说，在满足第二范式的实体中，非主属性不能依赖于另一个非主属性，即所有的非主属性应该直接依赖于全部的主属性，并且彼此之间无相互依赖关系，不存在传递函数依赖。
例：S-L(Sno,Sdept,SLOC）
分解方法：
（1）对于不是候选码的每个决定因子，从表中删去依赖于它的所有属性。
（2）新建一个表，新表中包含在原表中所有依赖于该决定因子的属性。
（3）将决定因子作为新表的主码。

• 对于：S-L(Sno,Sdept,SLOC)，由于：
  Sno → Sdept，Sdept → SLOC，存在传递依赖，则拆分成：
  S-D（Sno，Sdept）
  S-L（Sdept，SLOC)
• S-L-C关系模式最终分解的形式为：
  S-D（Sno,Sdept）
  S-L（Sdept，SLOC）
  S-C（Sno,Cno,Grade），Sno为引用S-D关系模式的外码。
  此时该关系模式属于第三范式。

    由1NF到2NF，消除了非主属性对主属性的部分函数依赖； 由2NF到3NF，消除了非主属性对主属性的传递函数依赖； 由3NF到BCNF，消除了主属性对码的部分函数依赖和传递函数依赖，此时没有 任何属性 对码是部分函数依赖或传递函数依赖。
    不能说规范化程度越高的关系模式就越好，在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式。