数据库-关系数据理论（依赖与范式）

目录

关系数据理论

问题的提出

规范化

1、函数依赖

2、码     

3、范式

4、1NF

5、2NF

6、3NF

7、BCNF

8、多值依赖

9、4NF

10、规范化小结

数据依赖的公理系统

模式的分解

 

---

关系数据理论

问题的提出

针对一个具体问题，应该如何构造一个适合于它的数据库模式，即应该构造几个关系模式，每个关系由哪些属性组成等，这都是数据库设计的问题，确切地讲是关系数据库逻辑设计的问题。实际上涉及任何一种数据库应用系统，不论是层次的、网状的还是关系的，都会遇到如何构造合适的数据模式即逻辑结构的问题。由于关系模型有严格的数学理论基础，并且可以向别的数据模型转换，因此，人们就以关系模型为背景来讨论这个问题，形成了数据库逻辑设计的一个有力工具——关系数据库的规范化理论。规范化理论虽然是以关系模型为背景，但是它对于一般的数据库逻辑设计同样具有理论上的意义。

回顾下前面的：关系模式是型，关系是值，关系模式是对关系的描述；关系数据库：给定的应用领域中，所有关系的集合构成一个关系数据库（值）；关系数据库模式：描述的是若干域的定义，在这些域上定义的若干关系模式的集合（型）。一个关系模式应当是一个五元组：R(U , D , DOM , F) ，其中关系名 R 是符号化的元组语义，U 为一组属性，D 为属性组 U 中的属性所来自的域，DOM 为属性到域的映射，F 为属性组 U 上的一组数据依赖。

由于 D、DOM 域模式设计关系不大，因此这里就把关系模式看作一个三元组：R ，当且仅当 U 上的一个关系 r 满足 F 时，r 称为关系模式 R 的一个关系。

作为一个二维表，关系要符合一个最基本的条件：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于 第一范式 (1NF) 。

再介绍一下数据依赖的概念：数据依赖是一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值的相等与否体现出来的数据间相关联系。它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖和多值依赖，这具体到后面再讲。

函数依赖极为普遍地存在于现实生活中。比如描述一个学生的关系，可以有学号(Sno)、姓名(Sname) 、系名(Sdept)等几个属性，由于一个学号只对应一个学生，一个学生只在一个系学习，因而当 “学号” 值确定之后，学生的姓名及所在系的值也就被唯一地确定了。属性间的这种依赖关系就类似于数学中的函数 ，自变量 x 确定之后相应的函数值 y 也就唯一确定了。

在模式设计中，假设已知一个模式 SA ，它仅由单个关系模式组成，问题是要设计一个模式 SD ，它与 SA 等价，但在某些指定的方面更好一些。这里通过一个例子来说明一个不好的模式会有些什么问题，分析它们产生的原因，并从中找出设计一个好的关系模式的办法。

建立一个描述学校教务的数据库，该数据库涉及的对象包括学生的学号（Sno）、所在系（Sdept）、系主任姓名（Mname）、课程号（Cno）和成绩（Grade）。假设用一个单一的关系模式 Student 来表示，则该关系模式的属性集合为 U={Sno , Sdept , MName , Cno , Grade } 。现实世界的已知事实（语义）告诉我们：一个系有若干学生，但一个学生只属于一个系；一个系只有一名（正职）负责人；一个学生可以选修多门课程，每门课程有若干学生选修；每个学生学习每一门课程有一个成绩。于是得到属性组 U 上的一组函数依赖 F ：

在此关系模式中填入一部分具体的数据，则可得到 Student 关系模式的实例，即一个教学管理数据库，如下表所示：

但这个关系模式存在以下问题：

1）、数据冗余。比如，每一个系的系主任姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。

2）、更新异常。由于数据冗余，当更新数据库中的数据时，系统要付出很大的代价来维护数据库的完整性，否则会面临数据不一致的危险。比如，某系更换系主任后，必须修改与该系学生有关的每一个元组，稍有不慎就有可能漏改某些记录，这就会造成数据的不一致性，破坏数据的完整性。

3）、插入异常。如果一个系刚，尚无学生，则无法把这个系及其系主任的信息存入数据库，因为在这个关系模式中，(Sno,CName)是主键。根据关系实体完整性约束，主键的值不能为空，而这时没有学生，Sno 和 CName 均无值，因此不能进行插入操作；另外，当某个学生尚未选课，即 CNname 未知，实体完整性约束规定，主键的值不能部分为空，同样不能进行插入操作。

4）、删除异常。不该删除的数据不得不删。如果某个系的学生全部毕业了，则在删除该系学生信息的同时，这个系及其系主任的信息也丢掉了，这个系依然存在，在数据库中却无法找到该系的信息；另外，如果某个学生不再选修 C1 课程，本应该只删去 C1，但 C1 是主键的一部分，为保证实体完整性，必须将整个元组一起删掉，这样有关该学生的其它信息也随之丢失。

鉴于存在以上种种问题，可以得出这样的结论：Student 关系模式不是一个好的模式。一个好的模式应当不会发生插入异常、删除异常和更新异常，数据冗余应尽可能少。原因：由存在于模式中的某些数据依赖引起的。解决方法：通过分解关系模式来消除其中不合适的数据依赖。

把这个单一模式分成3个关系模式：学生关系 S（Sno，Sname，Sdept，Sno → Sdept）; 选课关系SC（Sno，Cname，Grade，（Sno，Cname） → Grade）; 系关系 Dept （Sdept，Mname，Sdept→ Mname）。即：  

                        

 

   与student相比，分解为三个关系模式后，数据的冗余度明显降低。当新插入一个系时，只要在关系 D 中添加一条记录。当某个学生尚未选课，只要在关系S中添加一条学生记录，而与选课关系无关，这就避免了插入异常。当一个系的学生全部毕业时，只需在 S 中删除该系的全部学生记录，而关系 D 中有关该系的信息仍然保留，从而不会引起删除异常。同时，由于数据冗余度的降低，数据没有重复存储，也不会引起更新异常。

一个模式的数据依赖会有哪些不好的性质，而如何改造一个不好的模式，这就是规范化要讨论的内容。

 

规范化

规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。

1、函数依赖

定义： 设 R(U) 是一个属性集 U 上的关系模式，X 和 Y 是 U 的子集。若对于 R(U) 的任意一个可能的关系 r，r 中不可能存在两个元组在 X 上的属性值相等， 而在Y上的属性值不等，则称 “X 函数确定 Y”或“ Y函数依赖于X ”，记作X→Y。我们称 X 为决定因素，Y 为依赖因素，  。

函数依赖和别的数据依赖一样是语义范畴的概念，只能根据语义来确定一个函数依赖，而不能按照其形式化定义来证明一个函数依赖是否成立。例如，姓名->年龄 这个函数依赖只有在该部门没有同名人的条件下成立，如果允许有同名人，则年龄就不再函数依赖于姓名了。当然数据库设计者也可以对现实世界作强制的规定，例如规定不允许同名人出现，因而使函数依赖 “姓名→年龄” 成立。这样当插入某个元组时这个元组上的属性值必须满足规定的函数依赖，若发现有同名人存在，则拒绝插入该元组。 

注意：函数依赖不是指关系模式 R 的某个或某些关系实例满足的约束条件，而是指 R 的所有关系实例均要满足的约束条件。函数依赖是数据依赖的一种，也是特殊的完整性约束。

函数依赖与属性之间的联系类型有关。1)、在一个关系模式中，如果属性 X 与 Y 有 1:1 联系时，则存在函数依赖X→Y，Y→X，即X←→Y，例如，当学生无重名时，SNO ←→ Sname。2)、如果属性 X 与 Y 有 1:m 的联系时，则只存在函数依赖Y→X，例如，Sage、Sdept 与 Sno 之间均为 1:m 联系，所以有 Sno→Sage ，Sno → Sdept 。3)、如果属性 X 与 Y 有 m: n 的联系时，则 X 与 Y 之间不存在任何函数依赖关系，例如，一个学生可以选修多门课程，一门课程又可以为多个学生选修，所以 Sno 与 Cno 之间不存在函数依赖关系。由于函数依赖与属性之间的联系类型有关，所以在不确定属性间的函数依赖关系时，可以从分析属性间的联系类型入手，便可确定属性间的函数依赖。

函数依赖关系的存在与时间无关。当关系中的元组增加、删除或更新后都不能破坏这种函数依赖，所以函数依赖关系的存在与时间无关，而只与数据之间的语义规定有关。

下面介绍一些术语和记号：

在关系模式R(U)中，对于U的子集X和Y，如果 X→Y，但 ，则称X→Y是非平凡的函数依赖；若X→Y，但  ，则称 X→Y 是平凡的函数依赖。例：在关系SC(Sno, Cno, Grade)中，非平凡函数依赖： (Sno, Cno) → Grade ；平凡函数依赖：(Sno, Cno) → Sno ， (Sno, Cno) → Cno 。对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，若不特别声明，总是讨论非平凡的函数依赖。

若 X→Y ，则 X 称为这个函数依赖的决定属性组，也称为决定因素。

下面是完全函数依赖和部分函数依赖的定义：

举个例子：

只有当决定因素是组合属性时，讨论部分函数依赖才有意义；当决定因素是单属性时，只能是完全函数依赖。例：关系模式S（SNO，SName，Sage，Sdept），决定因素为单属性SNO，SNO →（SName，Sage，Sdept ），则不存在部分函数依赖。

传递函数的定义：

例：在关系 Std (Sno, Sdept, MName)中，有Sno → Sdept，Sdept → MName，则MName 传递函数依赖于 Sno，即 Sno →(传递) MName。

综上所述，函数依赖分为完全函数依赖、部分函数依赖和传递函数依赖三类，它们是规范化理论的依据和规范化程度的准则，数据库的规范设计将以这些概念为基础来进行。

 

2、码     

码是关系模式中的一个重要概念，在前面解释了有关码的若干定义，这里用函数依赖的概念来定义码。

注意 U 是完全函数依赖于 K ，而不是部分依赖于 K ，如果 U 部分依赖于 K ，则称 K 为超码。候选码是最小的超码，即 K 的任意一个真子集都不是候选码。若候选码多于一个，则选定其中的一个为主码。

包括在任何一个候选码中的属性称为主属性，不包含在任何候选码中的属性称为非主属性或非码属性。最简单的情况，单个属性是码；最极端的情况，整个属性组是码，称为全码。例：关系模式 S ( Sno , Sdept , Sage) 中，单个属性 Sno 是码，SC（Sno，Cno，Grade）中，（Sno，Cno）是码 。关系模式（T , C , S）中，一个教师（T）可以讲授多门课程（C），一门课程可以为多个教师讲授；同样一个学生（S）可以选听多门课程，一门课程可以为多个学生选听； (T , C , S)三个属性的组合是主码，T、C、S都是主属性，而无非主属性。关系模式R（P，W，A）中 ，P：演奏者，W：作品，A：听众 ：一个演奏者可以演奏多个作品，某一作品可被多个演奏者演奏，听众可以欣赏不同演奏者的不同作品，故其码为 (P，W，A)，即全码。 

外码定义：关系模式 R 中属性或属性组 X  并非 R 的码，但 X 是另一个关系模式的码，则称 X 是R 的外部码，也称外码。例，在SC（Sno，Cno，Grade）中，Sno 不是码，但 Sno 是关系模式 S（Sno，Sdept，Sage）的码，则 Sno 是关系模式 SC 的外部码。

主码与外部码一起提供了表示关系间联系的手段。

 

3、范式

关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称 1NF ；在第一范式中满足进一步要求的为第二范式，其余以此类推。

所谓第几范式原本是表示关系的某一种级别，所以常称某一关系模式 R 为第几范式。现在则把范式这个概念理解成符合某一种级别的关系模式的集合，即 R 为第几范式就可以写成  。

对于各种范式之间的关系有： 成立。

一个低一级范式的关系模式通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化。

 

4、1NF

定义：在一个关系模式 R 的每一个具体关系r中，如果所有属性都是不可分的基本数据项，则称 R 是第一范式的模式，即 R∈1NF。第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。但是满足第一范式的关系模式并不一定是一个好的关系模式。另外，在当前的任何关系数据库管理系统（DBMS）中，也不可能做出不符合第一范式的数据库，因为这些 DBMS 不允许你把数据库表的一列再分成两列或多列，因此在现有的 DBMS 中设计出不符合第一范式的数据库都是不可能的。

举几个不是1NF的例子：在关系模式（导师，专业，研究生）中，（张三，软件工程，张华 赵兴 李梦）；在模式（部门号，部门名，部门经理，部门成员）中，（B01，软件开发部，李四，张兴 赵梦 李华）。

1NF 是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。如下：

可分解为： 

     

 

5、2NF

定义： 若 R∈1NF，且 每一个非主属性完全函数依赖 于码，则 R∈2NF。先举个例子，有关系模式 S-L-C (Sno ,  Sdept ,  Sloc ,  Cno, Grade)，其中 Sloc 为学生的住处，并且每个系的学生住在同一个地方。那么该关系模式中函数依赖有

其函数依赖关系如图：

该关系模式符合第一范式，但不符合第二范式，因为：S-L-C 的码为 (Sno, Cno) ，非主属性 Sdept 和 Sloc 部分函数依赖于码 (Sno, Cno) 。可以将 SLC 分解为两个模式，以消除这些部分函数依赖 ：SC（Sno， Cno， Grade），SL（Sno， Sdept， Sloc），关系模式SC的码为（Sno，Cno），关系模式 SL 的码为Sno，这样非主属性对码都是完全函数依赖。其函数依赖图如下：

一个关系模式不属于 2NF ，就会产生以下几个问题，以上面 SLC 关系模式为例：1）、插入异常。假如要插入一个学生 Sno = S7 ，Sdept = PHY ，Sloc = BLD2 ，但该生还未选课，即这个学生还无 Cno ，这样的元组就插不进 SLC 中，因为插入元组时必须给定码值，而这时码值的一部分为空，因而学生的固有信息无法插入；2）、删除异常、假定某个学生只选一门课，如 S4 就选了一门课 C3 ，现在 C3 这门课他不选了，那么 C3 这个数据项就要删除，而 C3 是主属性，删除了 C3 ，整个元组就必须一起删除，使得 S4 的其他信息也被删除了，从而造成删除异常，即不应删除的信息也删除了；3）、删除复杂。某个学生从数学系（MA）转到计算机科学系（CS），这本来只需修改此学生元组中的 Sdept 分量即可，但因为关系模式 SLC 中还含有系的住处 Sloc 属性，学生转系将同时改变住处，因而还必须修改元组中的 Sloc 分量；4）、数据冗余度大。如果这个学生选修了 K门课，Sdept 、Sloc 重复存储了 K 次，不仅存储冗余度大，而且必须毫无遗漏地修改 K 个元组中全部 Sdept 、Sloc 信息，造成修改的复杂化。

分析上面的例子可以发现问题在于有两类非主属性，一类如 Grade ，它对码是完全函数依赖，另一类如 Sdept 、Sloc ，它们对码不是完全函数依赖。解决方法是用投影分解把关系模式分解为两个关系模式，如 SC 和 SL 。但需要注意的是，采用投影分解法将一个1NF的关系分解为多个2NF的关系，可以在一定程度上减轻原 1NF 关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题，但并不能完全消除关系模式中的各种异常情况和数据冗余。

有如下两个关系，判断是否均满足第二范式：1、部门（部门号，部门名，经理）；2、病房（病房号，床位号，科室名），医院里面有多个病房，每个病房有多个床位，有多个科室，一个病房属于一个科室 。

分析方法：分析主码是什么，看看非主属性是否完全函数依赖于主码。

解：

部门：是2NF。主码是部门号。病房：是1NF，不是2NF；主码是 病房号+床位号；科室名依赖于病房号，即科室名部分函数依赖于主码。

经以上分析，可以得到两个结论：1、从1NF 关系中消除非主属性对码的部分函数依赖，则可得到 2NF 关系；2、如果 R 的码为单属性，或 R 的全体属性均为主属性，则 R 满足第二范式。2NF要求实体的属性完全依赖于主关键字，所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。 

 

6、3NF

定义：

即若R∈3NF，则每一个非主属性既不部分依赖于码也不传递依赖于码。若关系 R 是第一范式，如果关系 R 中不存在非主属性，R一定是 3NF。

解决方法：

   采用投影分解法，把S-L分解为两个关系模式，以消除传递函数依赖：S-D（Sno， Sdept）、D-L（Sdept，Sloc），S-D的码为Sno， D-L的码为Sdept，可看出分解后的关系模式S-D与D-L中不再存在传递依赖，即变为第三范式。。 

将一个2NF关系分解为多个3NF的关系后，仍然不能完全消除关系模式中的各种异常情况和数据冗余。

 

7、BCNF

BCNF 比上述的 3NF 又进了一步，通常认为 BCNF 是修正的第三范式，有时也称为扩充的第三范式。定义：

即在关系模式 R 中，若每一个决定因素都包含码，则该关系模式符合 BCNF 范式 。同时由 BCNF 的定义可以得到结论，一个满足 BCNF 的关系模式有以下特点：1）、所有非主属性对每一个码都是完全函数依赖；2）、所有主属性对每一个不包含它的码也是完全函数依赖；3）、没有任何属性完全函数依赖于非码的任何一组属性。

由于 R 属于 BC范式，按定义排除了任何属性对码的传递依赖与部分依赖，所以 R 也属于第三范式；但若 R 属于第三范式，却未必会属于 BC 范式。例：

关系模式 SJP（S，J，P）中，S表示学生，J表示课程 ， P表示名次 。函数依赖：（S，J）→P，(J，P）→S，（S，J）与（J，P）都可以作为候选码，属性相交，没有非主属性，所以SJP∈3NF，每个主属性对不包含它的码是完全函数依赖的，所以SJP∈BCNF。

在关系模式 STJ（S，T，J）中，S表示学生，T表示教师，J表示课程。每个教师只教一门课，每门课对应多个教师。学生选了某门课，教师就固定了。函数依赖：(S，J)→T，(S，T)→J，T→J，(S，J)和(S，T)都是候选码。STJ∈3NF ，因为没有任何非主属性对码传递依赖或部分依赖 ；但 STJ 不满足 BCNF ，因为T是决定因素，但T不包含码 。

正如前面所说： R 属于 BC范式，那么 R 也属于第三范式 ；若 R 属于第三范式，却未必会属于 BC 范式 。但 如果 R∈3NF，且 R 只有一个候选码，那么前面的说法就是相互性的了，即 R 属于第三范式，也一定属于 BC 范式，因为 BCNF 消除的是 3NF 中所有的主属性对每一个不包含它的码的部分或传递依赖，若只有一个码，就不存在这个问题。

 

8、多值依赖

先举个例子：

学校中某一门课程由多个教师讲授，他们使用相同的一套参考书。每个教员可以讲授多门课程，每种参考书可以供多门课程使用。用一个非规范化的关系来表示教师 T 、课程 C 和参考书 B 之间的关系，见下：

关系模式 Teaching（C, T, B）的码（C，T，B），即 all-key，因此 Teaching ∈ BCNF。但是当某一课程（如物理）增加一名讲课教师（如周英）时，就必须插入多个（这里是三个）元组：（物理，周英，普通物理学），（物理，周英，光学原理），（物理，周英，物理习题集）。同样，某一门课（如数学）要去掉一本参考书（如微分方程），则必须删除多个（这里是两个）元组：（数学，李勇，微分方程），（数学，张平，微分方程），因而对数据的增删改很不方便，数据的冗余也十分明显。而这类关系模式，就是具有一种称之为多值依赖的数据依赖。

定义：

设R(U)是一个属性集 U 上的一个关系模式， X、 Y 和 Z 是 U 的子集，并且 Z＝U－X－Y。关系模式 R(U) 中多值依赖  X→→Y 成立，当且仅当对 R(U) 的任一关系 r，给定的一对（x，z）值，有一组 Y 的值，这组值仅仅决定于 x 值而与 z 值无关。

若 X→→Y  而 Z 为空，则称 X→→Y  为平凡的多值依赖。

多值依赖有以下性质：1）、多值依赖具有对称性。即若 X→→Y ，则 X→→Z ，其中 Z = U - X - Y 。2）、多值依赖具有传递性。即若 X→→Y ，Y→→Z ，则 X→→ Z - Y 。3）、函数依赖可以看做是多值依赖的特殊情况，Z是空，Y是一个，而不是一组。即若 X→Y，则X→→Y ，因为 当 X→Y 时，对 X 的每一个值 x ，Y 都有一个确定的 y 与之对应，所以 X→→Y 。4）、若 X→→Y ，X→→Z ，则 X→→YZ 。5）、若 X→→Y ，X→→Z ，则  。6）、若 X→→Y ，X→→Z ，则 X→→Y-Z ，X→→Z-Y 。

多值依赖与函数依赖相比，具有下面两个基本的区别：1）、多值依赖的有效性与属性集的范围有关。2）、如果在关系模式 R(U) 上存在函数依赖 X→Y，则任何  均有X→Y'成立，而多值依赖 X→→Y 在 R(U) 上成立，但不能断言对于任何  有 X→→ Y' 成立。

具体详细的看看这篇博客： 转：多值依赖 。

 

9、4NF

定义：

关系模式 R  属于第一范式，如果对于 R 的每个非平凡多值依赖 X→→Y （Y 不属于 X ），X 都含有码，则称 关系模式 R 属于第四范式 。

4NF 就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖，因为根据定义，对于每一个非平凡的多值依赖 X→→Y ，X 都含有候选码，于是就有 X→Y ，所以 4NF 所允许的非平凡的多值依赖实际上是函数依赖。显然，如果一个关系模式是 4NF ，则必为 BCNF ，而BCNF消除了多值依赖就是4NF 。

过多的内容我也不清楚，我也没有找到具体详解的，感兴趣的还是自己去查查资料，比如一些专业教材上面或许会有。/原谅

函数依赖和多值依赖是两种最重要的数据依赖，如果只考虑函数依赖，则属于 BCNF 的关系模式规范化程度已经是最高的了；如果考虑多值依赖，则属于 4NF 的关系模式规范化程度是最高的。事实上，数据依赖是多值依赖的一种特殊情况，而多值依赖实际上又是连接依赖的一种特殊情况。但连接依赖不像函数依赖和多值依赖可由语义直接导出，而是在关系的连接运算时才反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题。如果消除了属于 4NF 的关系模式中存在的连接依赖，则可以进一步达到 5NF 的关系模式。我去查了查相关的 5NF ，确实介绍的不多，如：转：六种范式 ，感兴趣的还是去查相关书籍吧。

 

10、规范化小结

在关系数据库中，对关系模式的基本要求是满足第一范式，这样的关系模式就是合法的、允许的。但是，人们发现有些关系模式存在插入、删除异常，以及修改复杂、数据冗余等问题，需要寻求解决这些问题的方法，这就是规范化的目的。

规范化的基本思想是逐步消除数据依赖中不合适的部分，使模式中的各关系模式达到某种程度的 “分离” ，即 “一事一地” 的模式设计原则，让一个关系描述一个概念、一个实体或者实体间的一种联系，若多于一个概念就把它 “分离” 出去，因此所谓规范化实质上是概念的单一化。

需要注意的是：规范化理论为数据库设计提供了理论的指南和工具，但也仅仅是指南和工具，并不能说规范化程度越高的关系模式就越好。在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式。上面的规范化步骤可以在其中任何一步终止，只有能够保证分解后的关系模式与原关系模式等价，分解方法才有意义，无损连接性和保持函数依赖。

关系模式的规范化过程是通过对关系模式的分解来实现的，即把低一级的关系模式分解为若干个高一级的关系模式。这种分解不是唯一的，而这些相关的是下面所要解决的问题。

 

数据依赖的公理系统

这一部分以及下面的模式分解都是进一步去讨论关系数据理论，这两部分内容书上面在介绍前已经声明可作为研究生学习的内容。我在整理到这部分内容的时候，也比较认真的看了看，确实有点迷，也看不进去（说实话，前面的多值依赖和4NF都有点迷），可能是没有遇到和这相关的具体事例，亦或是其他原因，总之这部分我暂时先放弃了。下边是我查阅的另一篇博客。介绍还是挺详细的，但我看着还是头大，放这里了谁想看就看看：转：数据依赖的公理系统 。

 

模式的分解

看看这两个：转：模式分解 、转：模式分解与无损连接 。这两部分暂时就先说这么多了，等以后再用到的时候，对它们更加理解的时候再来更新。