- 前面已经讲述了关系数据库、关系模型的基本概念以及关系数据库的标准语言。如何使用关系模型设计关系数据库，也就是面对一个现实问题，如何选择一个比较好的关系模式的集合，每个关系又应该由哪些属性组成，这属于数据库设计的问题，确切地讲是数据库逻辑设计的问题。有关数据库设计的全过程将在第6章详细讨论，本章讲述关系数据库规范化理论，这是数据库逻辑设计的理论依据。学习本章后，读者应掌握规范化理论的研究动机及其在数据库设计中的作用，掌握函数依赖的有关概念。第一范式、第二范式、第三范式和BC范式的定义，重点掌握关系模式规范化的方法和关系模式分解的方法，这也是本章的难点。
规范化问题的提出
1.1 规范化理论的主要内容
- 关系数据库的规范化理论最早是由关系数据库的创始人E.F.Codd提出的，后经许多专家学者对关系数据库理论作了深入的研究和发展，形成了一整套有关关系数据库设计的理论。在该理论出现以前，层次和网状数据库的设计只是遵循其模型本身固有的原则，而无具体的理论依据可言，因而带有盲目性，可能在以后的运行和使用中出现许多预想不到的问题。
- 在关系数据库系统中，关系模型包括一组关系模式，并且各个关系不是完全孤立的。如何设计一个合适的关系数据库，关键是关系数据库模式的设计，一个好的关系数据库模式应该包括多少关系模式，而每一个关系模式又应该包括哪些属性，又如何将这些相互关联的关系模式组建成一个合适的关系模型，这些工作决定了整个系统运行的效率，也是系统成败的关键所在，所以必须在关系数据库的规范化理论的指导下逐步完成。
- 关系数据库的规范化理论主要包括三个方面的内容：函数依赖、范式和模式设计。其中函数依赖起着核心的作用，是模式分解和模式设计的基础，范式是模式分解的标准。
1.2 不合理的关系模式存在的存储异常问题
- 数据库的逻辑设计为什么要遵循一定的规范化理论？什么是好的关系模式？某些不好的关系模式可能导致哪些问题 ？下面通过例子对这些问题进行分析。
- 要求设计教学管理数据库，其关系模式SCD如下：
- SCD(SNo,SN,Age,Dept,MN,CNo,Score)
- 其中，SNo表示学生学号，SN表示学生姓名，Age表示学生年龄，Dept表示学生所在的系别，MN表示系主任姓名，CNo表示课程号，Score表示成绩。
- 根据实际情况，这些数据有如下语义规定。
- （1）一个系有若干个学生，但一个学生属于一个系
- （2）一个系只有一名系主任，但一个系主任可以同时兼几个系的系主任；
- （3）一个学生可以选修多门功课，每门课程可被若干学生选修；
- （4）每个学生学习的课程有一个成绩。
- 在此关系模式中填入一部分具体的数据，则可得到SCD关系模式的实例，即一个教学管理数据库。
| SNo | SN | Age | Dept | MN | CNo | Score |
|---|---|---|---|---|---|---|
| S1 | 赵亦 | 17 | 计算机 | 刘伟 | C1 | 90 |
| S1 | 赵亦 | 17 | 计算机 | 刘伟 | C2 | 85 |
| S2 | 钱尔 | 18 | 信息 | 王平 | C5 | 57 |
| S2 | 钱尔 | 18 | 信息 | 王平 | C6 | 80 |
| S2 | 钱尔 | 18 | 信息 | 王平 | C7 | |
| S2 | 钱尔 | 18 | 信息 | 王平 | C4 | 70 |
| S3 | 孙珊 | 20 | 信息 | 王平 | C1 | 75 |
| S3 | 孙珊 | 20 | 信息 | 王平 | C2 | 70 |
| S3 | 孙珊 | 20 | 信息 | 王平 | C4 | 85 |
| S4 | 李思 | 21 | 自动化 | 刘伟 | C1 | 93 |
-
根据上述的语义规定并分析以上关系的数据，可以看出，（SNo, CNo）属性的组合能唯一标识一个元组，所以（SNo，CNo）是该关系模式的主关系键。但在进行数据库的操作时，会出现以下几方面的问题。
-
（1）数据冗余。每个系名和系主任的名字存储的次数等于该系学生的人数乘以每个学生选修的课程门数，同时 学生的姓名、年龄也都要重复存储次数。数据的冗余度很大，浪费了存储空间。
-
（2）插入异常。如果某个新系没有招生，尚无学生时，则系名和系主任的信息无法插入到数据库中。因为在这个关系模式中，（SNo，CNo）是主关系键。根据关系的实体完整性约束，主关系键的值不能为空，而这时没有学生，SNo和CNo均无值，因此不能进行插入操作。另外，当某个学生尚未选课，即CNo未知，实体完整性约束还规定，主关系键的值不能部分为空，同样也不能进行插入操作。
-
（3）删除异常。当某系学生全部毕业而没有招生时，要删除全部学生的记录，这时系名、系主任也随之删除，而现实中这个系依然存在，但在数据库中却无法找到该系的信息。另外，如果某个学生不再选修C1课程，本应该只删去C1，但C1是主关系键的一部分，为保证实体完整性，必须将整个元组一起删掉，这样，有关该学生的其他信息也随之丢失。
-
（4）更新异常。如果某学生改名，则该学生的所有记录都要逐一修改SN的值；又如某系更换系主任，则属于该 系的学生记录都要修改MN的内容，稍有不慎，就有可能漏改某些记录，这就会造成数据的不一致性，破坏了数据的完整性。
-
由于存在以上问题，可以说，SCD是一个不好的关系模式。产生上述问题的原因，直观地说，是因为关系中“包罗万象”，内容太复杂了。通过进一步分析可见，产生上述问题的根本原因是属性间存在着数据依赖关系。
-
我们把原来的关系模式SCD一般称为泛模式，泛模式用一个大表存放所有的数据。对某些查询可以直接从大表中 找到结果，这是泛模式好的地方；但是它把各种数据混在一起，数据间相互牵连，数据结构本身蕴含着许多致命的弊病。
-
那么，怎样才能得到一个好的关系模式呢？我们把关系模式SCD分解为学生关系S（SNo，SN，Age，Dept）、选课关系SC（SNo，CNo，Score）和系关系D（Dept，MN）三个结构简单的关系模式。
S表
| SNo | SN | Age | Dept |
|---|---|---|---|
| S1 | 赵亦 | 17 | 计算机 |
| S2 | 钱尔 | 18 | 信息 |
| S3 | 孙珊 | 20 | 信息 |
| S4 | 李思 | 21 | 自动化 |
D表
| Dept | MN |
|---|---|
| 计算机 | 刘伟 |
| 信息 | 王平 |
| 自动化 | 刘伟 |
SC
| SNo | CNo | Score |
|---|---|---|
| S1 | C1 | 90 |
| S1 | C2 | 85 |
| S2 | C5 | 57 |
| S2 | C6 | 80 |
| S2 | C7 | |
| S2 | C4 | 70 |
| S3 | C1 | 75 |
| S3 | C2 | 70 |
| S3 | C4 | 85 |
| S4 | C1 | 93 |
-
在以上三个关系模式中，实现了信息的某种程度的分离，S中存储学生基本信息，与所选课程及系主任无关；D中存储系的有关信息，与学生无关；SC中存储选手选课的信息，而与学生及系的有关信息无关。与SCD相比，分解为三个关系模式后，数据的冗余度明显降低。当新插入一个系时，只要在关系D中添加一条记录即可。当某个学生尚未选课时，只要在关系S中添加一条学生记录即可，而与选课无关，这就避免了插入异常。当一个系的学生全部毕业时，只需在S中删除该系的全部学生记录，而关系D中有关系系的信息仍然保留，从而不会引起删除异常。同时，由于数据冗余度的降低，数据没有重复存储，也不会引起更新异常。
-
经上述分析，我们说分解后的关系模式是一个好的关系数据库模式。从而得出结论，一个好的关系模式应该具 备以下四个条件。
- （1）尽可能少的数据冗余。
- （2）没有插入异常
- （3）没有删除异常
- （4）没有更新异常
-
把泛模式合理地分解为若干个模式后可使每个模式概念单一，有效地杜绝数据分不清、扯不开的状况。
-
但要注意，一个好的关系模式并不是在任何情况下都是最优的，例如查询某个学生选修课程名及所在系的系主 任时，要通过连接，而连接所需要的系统开销非常大，因此，要从实际设计的目标出发进行设计。
-
按照一定的规范设计关系模式，将结构复杂的关系分解成结构简单的关系，从而不好的关系数据库模式转变为 好的关系数据库模式，这就是关系的规范化。规范化又可以根据不同的要求而分成若干级别。我们要设计的关系模式中的各属性是相互依赖、相互制约的，这样才构成了一个结构严谨的整体。因此，在设计关系模式时，必须从语义上分析这些依赖关系。数据库模式的好坏和关系中各属性间的依赖关系有关，因此，下面先讨论属性间的依赖关系，然后再讨论关系规范化理论。