2023年数据库-关系模式的设计-规范化-关系模式规范化设计的基本思想.docx

《2023年数据库-关系模式的设计-规范化-关系模式规范化设计的基本思想.docx》由会员分享，可在线阅读，更多相关《2023年数据库-关系模式的设计-规范化-关系模式规范化设计的基本思想.docx（40页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、2023年数据库-关系模式的设计-规范化:关系模式规范化设计的基本思想 关系数据库设计 书目 第1章 简介 . 1 第2章 函数依靠 . 1 2.1 函数依靠的定义 . 1 2.2 关系的键码 . 2 2.3 超键码 . 3 2.4 函数依靠规则 . 3 2.4.1 分解/合并规则 . 3 2.4.2 平凡依靠规则 . 3 2.4.3 传递规则 . 4 第3章 模式设计 . 4 3.1 问题的提出 . 4 3.2 问题的根源 . 5 3.2.1 完全依靠和部分依靠 . 5 3.2.2 传递依靠 . 6 3.3 解决的途径 . 7 3.3.1 第1范式（1NF ） . 7 3.3.2 第2范式（

2、2NF ） . 7 3.3.3 第3范式（3NF ） . 8 3.3.4 BC范式（BCNF ） . 8 3.4 分解的原则 . 9 3.5 分解的方法 . 12 3.5.1 模式分解的两个原则 . 12 3.5.2 模式分解的3种方法 . 13 3.5.3 把关系模式分解成BC 范式的方法总结 . . 14 3.6 关系模式规范化小结 . 15 第4章 多值依靠 . 16 4.1 属性独立性带来的冗余 . 16 4.2 多值依靠的定义 . 17 4.3 第4范式 . 18 4.4 分解成第4范式 . 18 第5章 总结 . 19 第1章 简介 关系数据库是由一组关系组成，所以关系数据库的设计

3、归根究竟是如何构造关系，即如何把详细的客观事物划分为几个关系，而每个关系又有哪些属性组成。在我们构造关系时，常常会发觉数据冗余和更新异样等现象，这是由于关系中个属性之间的相互依靠性和独立性造成的。 关系模型有严格的数学理论基础，并形成了关系数据库的规范化理论，这为我们设计出合理的数据库供应了有利的工具。 第2章 函数依靠 2.1 函数依靠的定义 为了便于了解函数依靠（functional dependency）的概念，先看一个详细的关系实例。 例：考虑学生关系Student ，该关系中涉及的属性包括学生的学号（Sno ）、姓名（Sname ）、所在系（Sdept ）、系主任姓名（Mname ）

4、、课程名（Cname ）和成果（Grade ）。学生关系Student 的实例如表1所示。 表 1 学生关系Student 实例 在这个实例中，我们可以看到属性之间存在某些内在的联系： 由于一个学号值对应一个学生，一个学生只在一个系，因而当“学号”确定之后，姓名及所在系也就唯一确定了。属性中的这种依靠关系类似于数学中的函数。因此说Sno 函数确定Sname 和Sdept ，或者说Sname 和Sdept 函数依靠于Sno ，记作Sno Sname ，Sno Sdept 。 下面给出函数依靠的严格定义：假如关系R 的两个元组在属性A 1，A 2，A n 上一样（也就是，两个元组在这些属性所对应的

5、各个重量具有相同的值），则它们在另一个属性B 上也一样。那么，我们就说在关系R 中属性B 函数依靠于属性A 1A 2A n 。这种 依靠正式记作A 1A 2A n B ，也就是说“A 1，A 2，A n 函数确定B ”。其中，A 1A 2A n 称为确定因素。 假如一组属性A 1，A 2，A n 函数确定多个属性，比如说： A 1A 2A n B 1 A 1A 2A n B 2 A 1A 2A n B m 则可以把这一组依靠关系简记为： A 1A 2A n B 1B 2B m 例：在上例中，我们可以列举关于Student 关系的以下四个函数依靠： Sno Sname Sno Sdept Sde

6、pt Mname Sno CnameGrade 由于前面的两个依靠的左边完全相同，都是Sno ，用简写的形式可以把它们汇总在一行中： Sno Sname Sdept 依据函数依靠的传递规则，从Sno Sdept 和Sdept Mname 可以导出Sno Mname 。这一点我们从感性相识上也很简单理解，一个学号对应唯一的学生，而一个学生只能有唯一的系主任。 另一方面，Sno Cname 就是错误的，它不是函数依靠，缘由自不待言，如第1元组和第2元组，它们的Sno 重量相同，但Cname 重量却不同。 2.2 关系的键码 我们已经了解了键码的概念，下面从函数依靠角度给出定义。 假如一个或多个属性

7、的集合A1，A 2，A n 满意如下条件，则称该集合为关系R 的键码（key ）： （1）这些属性函数确定该关系的全部其他属性。也就是说，R 中不行能有两个不同的元组，它们在A1，A2，An 上的取值是相同的。 （2）A1，A 2，A n 的任何真子集都不能函数确定R 的全部其他属性，也就说，键码必需是最小的。 例：在学生的关系中，属性集Sno，Cname构成Student 关系的键码。 有时一个关系有多个键码。 例：在Student 关系中我们可以加上属性身份证号（Idno ），则关系中存在两个键码Sno，Cname和Idno，Cname。 2.3 超键码 包含键码的属性集称为“超键码”（s

8、uperkey ），是“键码的超集”的简称。因此，每个键码都是超键码。但是，某些超键码不是键码。 例：在学生关系中有很多超键码，不仅键码Sno，Cname本身是超键码，而且该属性集的任何超集，如Sno，Cname ，Grade，Sno，Sname ，Cname都是超键码。 2.4 函数依靠规则 假设已知某关系所满意的函数依靠集，在不知道该关系的详细元组的状况下，通常可以推断出该关系必定满意的其他某些函数依靠。 例：假如已知关系R 拥有属性A ，B 和C ，它满意如下函数依靠：A B 和B C ，则断定R 也满意依靠A C 。 下面介绍3个函数依靠规则。 2.4.1 分解/合并规则 （1）我们可

9、以把一个函数依靠A 1A 2A n B 1B 2B m 用一组函数依靠A 1A 2A n B i （i=1,2,m ）来替代。这种转换成为“分解规则”（splitting rule）。 （2）我们也可以把一组函数依靠A 1A 2A n B i （i=1,2,m ）用一个依靠A 1A 2A n B 1B 2B m 来替代。这种转换称为“合并规则”（combining rule）。 2.4.2 平凡依靠规则 对于函数依靠A 1A 2A n B 1B 2B m ， （1）假如B 是A 的子集，则称该依靠为平凡依靠。 （2）假如B 中至少有一个属性不在A 中，则称该依靠为非平凡的。 （3）假如B 中没

10、有一个属性在A 中，则称该依靠为完全非平凡的。 平凡依靠规则： 函数依靠A 1A 2A n B 1B 2B m 等价于A 1A 2A n C 1C 2C k ，其中C 是B 的子集，但C 不在A 中出现。我们称这个规则为“平凡依靠规则”（trivial dependency rule）。 若函数依靠满意平凡依靠规则，则该依靠为完全非平凡依靠。 2.4.3 传递规则 传递规则使我们把两个函数依靠级联成一个新的函数依靠。 假如A 1A 2A n B 1B 2B m 和B 1B 2B m C 1C 2C k 在关系R 中成立，则A 1A 2A n C 1C 2C k 在R 中也成立。这个规则就称为传

11、递规则（transitive rule）。 第3章 模式设计 关系数据库设计理论主要用于知道数据库的逻辑设计，确定关系模式的划分，每个关系模式所包含的属性从而使得由一组关系模式组成的关系模式作为一个整体，既能客观描述各种实体，又能精确反映各种实体之间的联系，还能实地体现出实体内部属性之间的相互依存与制约。 3.1 问题的提出 在设计数据库模式的时，特殊是从面对对象的ODL 设计或从E-R 设计干脆向关系数据库转换时，很简单出项的问题是冗余性，即一个事实在多个元组中重复。而且，我们发觉造成这种冗余的最常见的缘由是，企图把一个对象的单指和多值特性包含在一个关系中。 例：在2.1节，当我们把学生的单

12、指信息（如所在系）和多值特性（如课程集）存储子啊一起的时候，就导致了信息的冗余。 表 2 学生关系Student 实例 当我们企图把太多的信息存放在一个关系中时，就会出现数据冗余和更新异样等问题。主要表现如下： （1）数据冗余。信息可能在多个元组中不必要的重复。如学生所在的系和系主任。 （2）修改异样。我们可能修改了一个元组的信息，但另一个元组的相同信息却没有修改。比如，计算机系的主任换了一个人，可能由于马虎，只修改了第1元组，而没有修改第2和第3元组。于是出现数据不一样。然而重新设计关系Student 从而出现这 种错误是完全可能的。 （3）删除异样。假如一组属性的值变为空，带来的副作用可能

13、是丢失一些信息。比如，假如我们从学生晓雪的课程集中删除了自动化设计，那么数据库里就没有这个学生的课程信息了。由于课程名和学号共同组成该关系的键码，而建立数据库时，键码属性不能为空，于是，关系Student 中的晓雪的元组就会消逝，同时消逝的还有与晓雪有关的其他属性信息。 （4）插入异样。刚开学，学生尚未选课，使得键码属性值缺少课程名，结果导致学生的基本状况（学号、姓名、所在系）甚至系主任姓名都不能插入。这明显不符合道理。 3.2 问题的根源 关系的键码函数确定该关系的全部其他属性，由于键码能唯一的确定一个元组，所以，也可以说关系的键码函数确定该关系的全部属性。换句话说，一个关系中的全部属性都函

14、数依靠于该关系的键码。 当我们进一步分析时，就会发觉不同的属性在关系模式中所处的地位和扮演的角色是不同的。 再深化分析，又会发觉不同的属性对键码函数依靠的性质和程度是有区分的。有的属于干脆依靠，有的属于间接依靠（通常称为传递依靠）。当键码由多个属性组成时，有的属性函数依靠于整个键码属性集，而有的属性只函数依靠于键码属性集中的一部分属性。 3.2.1 完全依靠和部分依靠 对于函数依靠W A ，假如存在V W （V 是W 的真子集）而函数依靠V A 成立，则称A 部分依靠（partial dependency）于W ，否则，若不存在这种V ，则称A 完全依靠（full dependency）于W

15、。 从上述定义中可以得出一个结论：若W 为单属性，则不存在真子集V ，所以A 必定完全依靠于W 。 例：我们结合学生关系的例子详细说明完全依靠和部分依靠对冗余或异样有没有影响。关系模式Student （Sno ，Sname ，Sdept ，Mname ，Cname ，Grade ）中（Sno ，Cname ）为键码，函数依靠集如下： Sno Sname ，Sdept Sdept Mname Sno Mname P Sno ，Cname Sname ，Sdept ，Mname F Sno ，Cname Grade 可以看出属性Sname ，Sdept 和Mname 都函数依靠于Sno ，而部分依

16、靠于键码，上面用P 标记。属性Grade 则完全依靠于键码，上面用F 标记。 视察表2关系Student 的实例，就会留意到： 对键码完全依靠的属性Grade 没有任何的冗余，每个学生的每门课程都有特定的成果（当然，两门课程的成果完全相同是有可能的，但这并不意味着冗余）。 对键码部分依靠的属性Sname ，Sdept 和Mname 由于只函数依靠于Sno ，因此，当一个学生选修几门课时，这些数据就会多次重复出现，造成大量数据冗余；另一方面，当对一个学生的基本状况（学号、姓名、所在系）进行更新时，又会出现前面探讨过的异样。 从这个例子可以看出，在一个关系模式中，当存在非主属性对键码的部分依靠时，

17、就会产生数据冗余和更新异样。若非主属性对键码完全函数依靠，则不会出现类似问题。 3.2.2 传递依靠 对于函数依靠X Y ，假如Y X （X 不函数依靠于Y ）而函数依靠Y Z 成立，则称Z 对X 传递依靠（transitive dependency）。 说明：假如X Y ，且Y X ，则X ，Y 相互依靠，这时Z 与X 之间就不是传递依靠，而是干脆依靠了。事实上，我们以前所探讨的函数依靠大多数是干脆依靠。 例：假如学生中没有重名现象，则学号与姓名之间就属于相互依靠，即 Sno Sname Sname Sno Sno Sname 例：我们还是以学生关系为例，先看如下的函数依靠： Sno Sde

18、pt Sdept Mname Sno Mname 由于一个系有许多学生，所以Sdept Sno 。依据传递依靠的定义可知，Mname 传递依靠于Sno 。 从上面的例子中可以看出，关系模式中非主属性对键码的部分传递依靠和传递依靠是产生数据冗余和更新异样的主要根源。在有的关系模式中，还存在主属性对键码的部分依靠或传递依靠，这是产生冗余和更新异样的根源。 然而，从另一个角度又会发觉，关系模式中存在所谓多值依靠则是产生冗余和异样的另一个重要根源。 3.3 解决的途径 当我们对产生数据冗余和更新异样的根源进行深化分析以后，就会发觉部分依靠和传递依靠有一个共同之处，这就是，二者都不是基本的函数依靠，而都

19、是导出的函数依靠；部分依靠是以对键码的某个真子集的依靠为基础；而传递依靠的基础则是通过中间属性联系在一起的两个函数依靠。 导出的函数依靠在描述属性之间的联系方面并没有比基本的函数依靠供应更多的信息。从这个意义上看，在一个函数依靠集中，导出的依靠相对于基本的依靠而言，虽然形式上多一种描述方式，但本质上完全是冗余的。正是由于关系模式中存在对键码的这种冗余的依靠导致数据库中的数据冗余和更新异样。 找到了问题的所在，也就有了解决的途径消退关系模式中各属性对键码冗余的依靠。 由于冗余的依靠有部分依靠与传递依靠之分，而属性又有主属性与非主属性之别，于是，从不同的分析与解决问题的角度动身，导致解决问题的深度

20、和效果会有不同，因此，把解决的途径分为几个不同的级别，以属于第几范式来区分。 所谓范式就是符合某一种级别的关系模式的集合。关系数据库中的关系模式必需满意肯定的要求，满意不同程度要求的模式属于不同范式。目前主要有6中范式：第1范式、第2范式、第3范式、BC 范式、第4范式、第5范式。第1范式需满意的要求最低，在第1范式基础上满意进一步要求的为第2范式、，其余以此类推。 各级范式之间存在如下联系： 1NF 2NF 3NF BCNF 4NF 5NF 通过分解把属于低级范式的关系转换为几个属于高级范式的关系模式的集合，这一过程称为范式化（normalization ）。 3.3.1 第1范式（1NF

21、） 假如一个关系模式R 的全部属性都是不行分的基本数据项，则这个关系属于第1范式。 在任何一个关系数据库系统中，第1范式是对关系模式的一个最至少的要求。不满意第1范式的数据库模式就不能称之为关系数据库。 3.3.2 第2范式（2NF ） 如关系模式R 属于第1范式，且每个非主属性都完全依靠于键码，则R 属于第2范式。 第2范式不允许关系模式中的非主属性部分依靠于键码。 3.3.3 第3范式（3NF ） 若关系模式R 属于第1范式，且每个非主属性都不传递依靠于键码，则R 属于第3范式。 说明：属于第3范式的关系模式必定属于第2范式。因为可以证明部分依靠蕴含着传递依靠。 设A 是关系模式R 的一个

22、非主属性，K 是R 的键码，且K A 是部分依靠，则A 必定函数依靠于K 的某个真子集K ，即K A 。因为K K, 所以K K （平凡依靠）但K K 。从K K 和K A 可知K A 是传递依靠。因此，可把部分依靠看作是传递依靠的特例。按这样的理解学生关系模式的函数依靠集又可以写成如下形式： Sno ，Cname Sno Sno Sname ，Sdept ，Mname Sdept Mname Sno ，Cname Grade 当按第3范式的要求把全部传递依靠都消退时，也应当把部分依靠消退。换句话说，若关系模式R 属于第3范式，则每个非主属性对于键码既不存在部分依靠，也不存在传递依靠。 例：关

23、系模式STC （Sname ，Tname ，Cname ，Grade ），其中4个属性分别为学生姓名、老师姓名、课程名和成果。每个学生可选几门课。每个老师只教一门课，但一门课可有几个老师开设。当某个学生选定某门课后，其上课老师就固定了。我们可由上面的语义得到如下的函数依靠： Sname ，Cname Tname Sname ，Tname Cname Tname Cname 该关系有两组属性为键码，Sname，Cname和Sname，Tname。该关系只有一个非主属性Grade ，又只函数依靠于键码，因此，关系模式STC 属于第3范式。 把关系分解到第3范式，可以在相当程度上减轻原关系中的异样和

24、信息冗余，但也不能保证完全消退关系模式中的各种异样和信息冗余。要想使性能得到进一步改善，就要吧关系模式进一步规范化。 3.3.4 BC 范式（BCNF ） 若关系模式R 属于第1范式，且每个属性都不传递依靠于键码，则R 属于BC 范式。 从定义可以看出，BC 范式既检查主属性又检查非主属性，明显比第3范式限制更 Sname ，Cname Grade Sname ，Tname Grade 严。当只检查非主属性而不检查主属性时，就成了第3范式。因为可以说任何满意BC 范式的关系都必定满意第3范式。 例：下面有3个关系模式，判别一下它们是否满意BC 范式。 Student （Sno ，Sname ，

25、Ssex ，Sage ，Sdept ） Course （Cno ，Cname ，Ccredit ） SC （Sno ，Cno ，Grade ） 第1个关系模式是关于学生学号、姓名、性别、年龄和所在系等信息；第2个关系模式是关于课程的课程号、课程名和学分等信息；第3个关系模式是关于学生选课的信息，包括学号、课程号和该课的成果。 第1个关系模式中，由于学生有可能重名，因此它只有一个键码Sno ，且只有一个函数依靠Sno Sname Ssex Sage Sdept，符合BC 范式的条件，所以关系Student 满意BC 范式。 第2个关系模式中，假设课程名具有唯一性，因此该关系中有两个键码分别为Cn

26、o 和Cname ，而且函数依靠集为Cno Cname ，Cno Ccredit ，Cname Ccredit ，不难验证，关系Course 满意BC 范式。 第3个关系模式中，键码为Sno，Cno，函数依靠集为Sno Cno Grade ，因此关系SC 也满意BC 范式。 3.4 分解的原则 对关系模式进行分解的目的是使模式更加规范化，从而削减以至消退数据冗余和更新异样。但是在关系模式中的诸多属性进行分解的时候，应当留意什么，如何判别不同分解的优劣？ 例：我们先举一个模式分解的例子，首先分析上面介绍的关系模式STC （Sname ，Tname ，Cname ，Grade ），其函数依靠集为：

27、 Sname ，Cname Tname ，Grade Sname ，Tname Cname ，Grade Tname Cname 键码为Sname，Cname和Sname，Tname。因为Cname 为主属性，且函数依靠Tname Cname 的确定因素Tname 只是键码的一部分而不包含键码，所以该模式不属于BC 模式。 我们可以把关系模式STC 分解成SC （Sname ，Cname ，Grade ）和ST （Sname ，Tname ）。 分解后，SC 中的函数依靠为： Sname ，Cname Grade 键码为Sname，Cname。对于ST 来说，由于一个学生可选多门课，从而面对多

28、位老师，而一个老师明显要教多个学生，因此学生与老师之间的联系为多对多的，不存在函数依靠。于是ST 中的两个属性共同构成键码。 从上面的分析可知，SC 和ST 都属于BC 范式。至此，好像已经万事大吉。然而，这样的结论能否经得起检验呢？我们不妨通过实例细致分析一下。关系模式STC 的实例如下： 表 3 关系模式STC 分解后关系模式ST 的实例如下： 表 4 关系模式ST 分解后关系模式SC 的实例如下： 表 5 关系模式SC 当我们要查询某位老师上什么课时，就要对ST 和SC 两个关系以Sname 为公共属性进行自然连接，这时得到的实例如下：（仅列出了前4个元组） 表 6 ST、SC 自然连接

29、后得到的关系 我们竟然发觉“白捡了”很多元组。然而，这不值得庆幸。因为稍加分析，就会意识到，这些“白捡”的元组都是假冒伪劣的，之所以如此是由于丢失了函数依靠Tname Cname 。按现在的实例，一个老师可能开了几门课。而这是与原来的语义相违反的。原来，在模式分解时把相关的两个属性分开了，即使以后连在一起，有些内在的联系已不能再现了。 从上面的例子可以看出，对模式的分解明显不是随意的。主要涉及两个原则： 1. 无损连接 当关系模式R 进行分解时，R 的元组将分解在相应属性集进行投影而产生新的关系。假如对新的关系进行自然连接得到的元组的集合与原关系完全一样，则称为无损连接（lossless jo

30、in）。 上面对关系模式STC 进行的分解通过自然连接产生了大量的“伪”元组，形式上元组增多了，但失去了真实性，丢失了信息，属于有损连接。像这样的模式分解明显是不妥的。 无损连接反映了模式分解的数据等价原则。 2. 保持依靠 当对关系R 进行分解时，R 的函数依靠集也将按相应的模式进行分解。假如分解后总的函数依靠集与原函数依靠集保持一样，则则称为保持依靠（preserve dependency ）。 上面对关系模式STC 所进行的分解，由于把函数依靠Tname Cname 所涉及的两个属性分别放在SC 和ST 两个模式中，从而使该依靠丢失了。 保持依靠反映了模式分解的依靠等价原则。依靠等价保证

31、了分解后的模式与原有的模式在数据语义上的一样性。比如，刚才对模式STC 所做的分解，由于丢失了函数依靠Tname Cname ，就不能再体现一个老师只开一门课的语义了。 数据等价和依靠等价是模式分解的两个最基本的原则。对关系模式进行分解，使之属于第2、3范式，只要采纳规范的方法，既能实现无损连接，又能实现保持依靠。然而，要使分解后的模式属于BC 范式，即使采纳规范的方法，也只能保持无损连接，而不能肯定的保持依靠。 事实上，在模式分解时，除考虑数据等价和依靠等价之外，还要考虑效率。当我们对数据库的操作主要是查询而更新较少时，为了提高效率，可能宁愿保留适当的数据冗余，让模式中的属性多些，而不愿把模

32、式分解的太小，否则为了查询一些数据，经常要做大量的连接运算，把多个关系连在一起才能从中找到相关的数据，把关系一再连接，花费大量时间，或许得不偿失。因此，保留适当冗余，达到以空间换时间的目的，这也是模式分解的一个重要原则。 所以在实际应用中，对模式分解的要求并不肯定要达到BC 范式，有时达到第3范式就足够了。 3.5 分解的方法 关系模式分解的基础是键码和函数依靠。当我们对关系模式中属性之间的内在联系做了深化、精确地分析，确定了键码和函数依靠之后，模式分解因有章（规则）可循，有法（方法）可依而显得简洁明白。 3.5.1 模式分解的两个原则 1. 公共属性共享 要把分解后的模式连接起来，公共属性是

33、基础若分解时模式之间未保留公共属性，则只能通过笛卡尔积相连，导致元组膨胀，真实信息丢失，结果失去价值。保留公共属性，进行自然连接是分解后的模式实现无损连接的必要条件。 若存在对键码的部分依靠，则作为确定因素的键码的真子集就应当作为公共属性，用来把分别存在部分依靠（指在原来关系）和完全依靠的两个模式自然连接在一起。 若存在对键码的传递依靠，则传递依靠的中间属性就应作为公共属性，用来把构成传递的两个基本链所组成的模式自然连接在一起。 2. 相关属性合一 把以函数依靠的形式联系在一起的相关属性放在一个模式中，从而使原有的函数依靠得以保持。这是分解后的模式实现保持依靠的充分条件。然而，对于存在部分依靠

34、或传递依靠的相关属性则不应当放在一个模式中，因为这正是导致数据冗余和更新异样的根源，从而也正是模式分解所要解决的问题。 假如关系模式中属性之间的联系错综困难、交织在一起，难分难舍，顾此失彼，也难免会出现分解后函数依靠丢失的现象，这时也只能权衡主次，确定取舍。 分解后的两个模式R1和R2能实现无损连接的充要条件是： (R 1R 2)(R 1-R 2)或(R 1R 2)(R 2-R 1) 上式表明：若分解后的两个模式的交集函数确定两个模式的差集之一，则必定实现无损连接。当我们按上述两个规则对模式进行分解时，两个模式的交集则为公共属性，而两个模式的差集之一为某个函数依靠的右边，因此必定函数依靠于公共属性，从而满意无损连接的充分必要条件。 3.5.2 模式分解的3种方法 1. 部分依靠归子集；完全依靠随键码 要使不属于第2范式的关系模式“升级”，就要消退非主属性对键码的部分依靠。解决的方法就是对原有模式进行分解。分解的关键在于：找出对键码部分依靠的非主属性所依靠的键码的真子集，然后把这个真子集与全部相应的非主属性