申明：本博主所有文章均属自用，不做任何商用。觉得写得好免费赠送，觉得不好请出门右转，拒绝任何恶意评论。

参考《试题》P32试题5

一、什么是实体、什么是联系

实体：供应商、项目、零件、员工

联系：供应



二、实体联系→关系模式

1：1联系
在两个实体任选一个添加另一个实体的主键；

每个实体的码均是该联系的候选键；

1：n联系
1:N 遇到 1:N 关系的话在N端添加另一端的主键，假如有学生和班级两个实体，一个班级可以容纳多个学生，但是一个学生只能选择一个班级， 因此班级和学生是1:N的关系，现在要转换为关系模型， 我们只需在学生的这端加上班级的唯一标识即可，这样做的原因是，因为一个学生只能有一个班级，班级是相对学生唯一的。

该联系的码为n端实体的码，关系的外键是1端的码；

n：m联系
需要将联系转换为实体，然后在该实体上加上另外两个实体的主键，作为联系实体的主键，然后再加上该联系自身带的属性即可。例如有学生和老师两个实体， 一个学生可以由多名老师来授课，一名老师也可以授课多名学生，它们是M:N关系的，假如联系为授课，该联系上有成绩属性，因此当我们把它转换为关系模型时，我们把联系转换为联系实体，并添加学生实体的主键（学号）和教师实体的主键（教师编号）作为自己的主键，值得注意的是，授课实体的外键分别是学号和教师编号，但是它的主键是（学号，教师编号），另外它还拥有自己的一个属性成绩。

1:1:N
这是三元联系的对应关系，但是当转换为关系模型时，和1:N的情况是差不多的。我们只需将N端添加另外两端的主键即可。

M:N:P
这种三元联系的三种多对应关系，看上去很复杂，其实转换起来并不是那么复杂了，我们要做的仅仅是将其中的联系转换为联系实体，然后在联系实体上添加M端N端P端的主键，然后加上联系实体自身的属性，就行了。



三、例子

说了这么多看个小例子。

这是一份关于商店商品仓库的ER图。

先看仓库和商品之间是M:N的关系，于是我们首先想到的应该是把联系 库存转换为库存实体。 

库存 （仓库号，商品号，日期，库存量） 

然后是商品实体和仓库实体 

商品（商品号，商品名，单价） 

仓库（仓库号，仓库名，地址）

除此之外仓库和商品还有一个供应关系，同样是M:N关系： 

供应 （仓库号，商品号 ，月份，月供应量）

在上图的商店和仓库之间的关系可能写漏了，但是它们应该也是M:N的关系，一个商店可以被多个仓库供应，一个仓库也可以供应多个商店。上面已经创建了供应实体，现在只需在供应实体中假如商店号即可，也就是商店实体的主键。

供应（仓库号，商品号，商店号 ，月份，月供应量） 

商店（商店号，商店名，地址）

总结

至此，转换关系模型也完成了，当然这只是个例子，实际的开发中，我们可能会遇到各式各样奇怪的需求，这就更要求我们做好概念设计的环节，对后来的数据库设计和维护都有好处。ER图的好坏，始终是数据库设计的重要一节。







================================================================================================

另一篇文章

================================================================================================

前言

       做了几套软考题之后发现下午题的题型很固定，第一题是数据流图，第二个是关系模式，第三个是用例图，第四个是算法，第五个是设计模式。既然题型这么固定，那么我们就好好的对每个知识点进行深入的研究，然后拿下它！

       So ,今天我们来看一下E-R 图关系模式的转换。

       建立数据库的时候我们首先要画E-R图，E-R图是由实体、属性和联系三要素组成的，每个实体之间会有联系，当我们转换成关系模式的时候，就会出现一对一、一对多和多对多的情况。那么对于实体和联系具体怎么进行转换呢，听我细细道来……

  一、一对一



        1、  将联系转换成一个独立的关系模式，关系模式的名称为联系的名称。关系模式的属性包括该联系所关联的两个实体的码及联系的属性，关系的码取自任一方实体的名称。

       2、  将联系归并到关联的两个实体的任一方，给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可，归并后的实体码保持不变。

  实例

       一个公司有一个经理，一个经理也只能在一个公司进行任职，所以公司和经理之间是一对一的关系。公司（公司编号，公司名，地址，电话），经理（职工编号，姓名，性别，电话）。经理任职会产生任职日期属性。



 转换为关系模式：

       1、  公司（公司编号，公司名，地址，电话）              主键为公司编号

               经理（职工编号，姓名，性别，电话）                 主键为职工编号

               任职（公司编号，职工编号，任职日期）             主键为公司编号或者是职工编号



      2、  （1）公司（公司编号，公司名，地址，电话，职工编号，任职日期） 主键为公司编号，外键为职工编号

                       经理（职工编号，姓名，性别，电话）    主键为职工编号

              （2）公司（公司编号，公司名，地址，电话）   主键为公司编号

                       经理（职工编号，姓名，性别，电话，公司编号，任职日期）    主键为职工编号，外键为公司编号。



二、一对多

         1、  将联系转换成一个独立的关系模式，名称为联系的名称，关系模式的属性取该联系所关联的两个实体的码及联系的属性，关系的码是多方实体的码。

         2、  将利息归并到关联的两个实体的多方，给待归并的多方实体属性集中增加一方实体的码和该联系的属性，归并后的多方实体码保持不变。

     

实例

        一个部门中有多个员工，但是每个员工只能属于一个部门，所以部门和员工之间的关系就是一对多。部门（部门号，部门名称，电话），员工（员工号，姓名，电话）。

    

                    

      

 转换为关系模式：

      1、  部门（部门号，部门名称，电话）   主键是部门号

             员工（员工号，姓名，电话）        主键是员工号

             隶属（部门号，员工号）            主键是部门号和员工号

      2、  部门（部门号，部门名称，电话）    主键是部门号

             员工（员工号，姓名，电话，部门号） 主键为员工号，外键为部门号



三、多对多

           多对多的联系只能转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性取该联系所关联的两个多方实体的码及联系的属性，关系的码是多方实体的码构成的属性组。



 实例

      在选课系统中，一个学生可以选修多门课程，一个课程也可以被多个学生选，每门课程最后都要有成绩，所以学生和课程之间是多对多的关系。

学生（学号，姓名，性别），课程（课程号，课程名称，授课老师）。

      

转换成关系模式： 

       学生（学号，姓名，性别）                主键为学号

       课程（课程号，课程名称，授课老师）      主键为课程

       选课（学号，课程号，成绩）              主键为学号和课程号的组合，外键为课程号，学号 

      

实践

       知道了以上的理论知识，我们还要进行实践工作。下面来分析一道真题：









答案：





分析：



 1、想必有好多人在第一题中没有将采购那个联系合并吧。

       通过“一个采购订单可以包含多类服装。采购订单上主要由……和对应的供应商”这句话，大家很容易把采购订单与服装的联系和采购订单和供应商的联系画出来，但是我们仔细想想，采购订单上应该把每类服装或者是不同数量的同类的服装对应的供应商表现出来，意思就是在采购订单上，服装和供应商之间也是有联系的。所以我们将这两个联系合并成一个，表示三者之间都互相有联系，并不是只有采购订单和服装，采购订单和供应商有联系。

2、因为仓库和库管员之间的关系是一对多。所以在填仓库信息这个关系模式时，应该将库管员编码写进去。

      供应情况表示的是供应商和服装之间的联系。因为供应商和服装之间是多对多的关系，所以供应情况中应该包括供应商的码和服装的码。所以将供应商编码和服装编码填进去。

      采购订单是一个实体，需要有的属性根据说明中可知为订单编码，订货日期和应到货日期。

      采购订单明细为采购订单、服装和供应商之间的联系，因为三者是多对多的关系，所以采购订单明细中应包括三者的码。再加上说明中的属性，所以应为订单编码，服装编码，供应商编码，数量和采购价格。

3、因为题中要求为库管员定期轮流对所有仓库进行抽查，所以库管员和仓库之间的关系应为多对多。

总结

       每次遇到不会的知识都会有一种得过且过的感觉，总觉得是会，就是没有掌握好而已，然后说自己没有时间总结。这其实就是我们常说的，总是低头走路，却不抬头看路。其实总结如果花费一个小时的时间比做题花费的两个小时的时间更加珍贵，更有收获！每次总结后都深深的体会到总结的好处……相信小伙伴也早就有感触了吧，那就赶紧行动吧！最后提醒大家，不要顺手就用* 或者是n表示对比关系，首先看一下题目要求，如果没有要求，那就看一下给的实体联系图中有没有标出来，如果人家给的*或n，跟人家保持一致，如果都没有的话，那就可以按照自己习惯了……相信这个题，大家看完我的博客之后就应该会了吧！加油！！！

 

本来是为了复习数据库期末考试，结果找了一圈都没有发现比较好的解释，通过查阅资料和总结，为大家提供通俗易懂的解法，一听就会！并且配有速记口诀！介是你没有玩过的船新版本包含最小依赖集求法候选码求法

在模式分解之前，首先对于1NF,2NF,3NF,BCNF做一个简明扼要的介绍。

1NF是指数据库表的每一列都是不可分割的基本数据项，即实体中的某个属性不能有多个值或者不能有重复的属性。

2NF要求属性完全依赖于主键，不能存在仅依赖主关键字一部分的属性。

3NF要求每一个非主属性既不部分依赖于码也不传递依赖于码。

BCNF消除了主属性对候选码的部分和传递函数依赖。

注：1.相对于BCNF，3NF允许存在主属性对候选码的传递依赖和部分依赖。

2.BCNF比较抽象，略作解释：在学生信息表里，学号是一个候选码，学号可确定学生姓名；(班级,学生姓名）也是一组候选码，有(班级,学生姓名）->学号，因此在主属性间形成了传递依赖。

3.若对概念不清晰，关于码、候选码、主属性、非主属性的解释可参看：

https://blog.csdn.net/sumaliqinghua/article/details/85872446#commentBox

我们的重点是讲解范式分解：

一、3NF分解

分为保持依赖和无损连接

为了说明求解保持依赖，我们先要会求最小依赖集

（1）最小依赖集求法：

口诀：右侧先拆单，依赖依次删。

           还原即可删，再拆左非单。

通过求下面的最小依赖集对口诀进行解释，





（2）3NF分解：

口诀：

保函依赖分解题，先求最小依赖集。

依赖两侧未出现，分成子集放一边，剩余依赖变子集。

若要连接成无损，再添候选做子集。

下面通过几道例题讲解口诀：

例1.已知R(ABCDE), F={A ->D,E->D,D->B,BC->D,DC->A}求保持函数依赖的3NF分解，和具有无损连接性及保持函数依赖的3NF分解

第一步：保函依赖分解题，先求最小依赖集。先求出R的最小依赖集，可得F={A ->D,E->D,D->B,BC->D,DC->A}

第二步：依赖两侧未出现，分成子集放一边。首先可以发现没有不出现在两侧的元素不用单独分出一个子集，“剩余依赖变子集”然后我们将各依赖分别划分为子集得到：{AD} {ED} {DB} {BCD} {DCA}，即为所求保持函数依赖的3NF分解

第三步：若要连接成无损，再添候选做子集。

(1)候选码的求解：所谓候选码即能决定整个关系的，我们通过找未出现在依赖右边的和两侧均未出现的元素即可求得，

(2)可以发现C E未出现在右边，因此候选码为{CE}。故所求具有无损连接性及保持函数依赖的3NF分解为{AD} {ED} {DB} {BCD} {DCA} {CE}

 

例2.关系模式R,有U={A,B,C,D,E,G},F={B->G,CE->B,C->A,CE->G,B->D,C->D}，将关系模式分解为3NF且保持函数依赖

将关系模式分解为3NF且保持函数依赖：

第一步：保函依赖分解题，先求最小依赖集。先求出R的最小依赖集，

假设B->G冗余，则(B)+=BD,没有G故不冗余。

假设CE->B冗余，则（CE）+=CEGDA,没有B故不冗余。

假设C->A冗余，则（C）+=CD,故不冗余。

一次可以得到最小函数依赖集Fm={B->G,CE->B,C->A,B->D,C->D}

第二步：依赖两侧未出现，分成子集放一边，剩余依赖变子集。首先可以发现没有不出现在两侧的元素，然后我们将各依赖分别划分为子集得{BG} {CEB} {CA} {BD} {CD}，即为所求保持函数依赖的3NF分解

第三步：若要连接成无损，再添候选做子集。找到R的一个候选码为{CE}。故所求具有无损连接性及保持函数依赖的3NF分解为{BG} {CEB} {CA} {BD} {CD} {CE} (注：范式分解并不唯一，正确即可)

 

二、BCNF分解：

将关系模式R<U,F>分解为一个BCNF的基本步骤是

1）先求最小依赖集，候码非码成子集

3）余下左侧全候码，完成BCNF题。

例.关系模式R,有U={A,B,C,D,E,G},F={B->G,CE->B,C->A,CE->G,B->D,C->D}，将关系模式分解为3NF且保持函数依赖

将关系模式分解为3NF且保持函数依赖：

第一步：先求最小依赖集。可以发现CE->G多余，因此最小依赖集为F={B->G,CE->B,C->A,B->D,C->D}。

第二步：候码非码成子集。由于候选码为(CE)因此将CE->B划分出子集（BCE），而B->G，B->D左侧均不含主属性(C、E)中的任何一个故划分出(BG),(BD）

第三步：此时剩余依赖F={C->A,C->D}剩余元素{A,C,D}检查发现函数依赖左侧都是候选码即完成BCNF分解，如果不满足则继续分解余下的。

于是BCNF分解的最后结果为{（BG）,(BD),(ACD),(BCE)}。

如有疑问请在评论区留言，如有帮助麻烦右上角点个赞~~蟹蟹

三、总结

1.闭包

2.候选码

3.最小依赖集

4.3NF分解

5.BCNF分解

实体关系设计问题
实体集和关系集的概念并不精确，并且可以用许多不同的方式定义一组实体和它们之间的关系。在本节中，我们将研究E-R数据库模式设计中的基本问题。第7节将详细介绍设计过程。
7.71使用实体集与属性
考虑使用附加属性电话号码的实体设置指导（图7.17 a）可以很容易地认为，手机是一个独立的实体，带有属性的电话号码和位置;位置可能是手机所在的办公室或家庭，移动电话（手机）可能会被“移动”的价值所抑制。“如果我们采用这种观点，我们不会将属性电话号码添加到教师中。相反,我们创建:
一个带有属性电话号码和位置的电话实体
一种关系设置在手机上，表示教师和他们拥有的手机之间的联系。
该选项如图7 17 b所示。那么，教师的这两个定义之间的主要区别是什么呢？把电话当作一个属性电话号码，就意味着老师们每个人都有一个电话号码。把电话当作实体电话，可以让教师有几个电话号码（包括零）。然而，我们可以轻松地定义电话号码为一个多值的属性，允许多个电话进行指导。主要的区别在于，把手机当作一个实体来更好地模拟一个人可能想要保留关于手机的额外信息的情况，比如它的位置，或者它的类型（移动电话，IP电话，或普通的老式电话），或者所有的共享信息
图7.17可以将电话添加到教师实体集
电话。因此，将电话作为一个实体来对待，比把它当作一个属性来对待更普遍，并且当它是有用的时候是合适的。
相比之下，将属性名（讲师）视为实体是不合适的;很难说名称本身就是一个实体（与电话相反）。因此，将名称作为指导实体集的属性是合适的。
由此产生了两个自然问题：什么构成了属性，以及什么构成了实体集？不幸的是，没有简单的答案。这些区别主要取决于现实世界中模型的结构，以及与所讨论的属性相关的语义。
一个常见的错误是使用实体集的主键作为另一个实体集的属性，而不是使用关系。例如，将学生的ID建模为教师的属性是不正确的，即使每个指导员只建议一个学生。关系顾问是表示学生和教师之间联系的正确方式，因为它使他们之间的联系更加明确，而不是通过一个属性来暗示。
人们有时会犯的另一个相关错误是将相关实体集的主键属性指定为关系集的属性。例如，ID（学生的主键属性）和ID（教师的主键）不应该作为关系顾问的属性出现。这是不应该做的，因为在关系集中已经隐含了主键属性。
7.72实体集与关系集的使用
在图7.15中，我们使用“带关系”来模拟一个学生接受一个（sectiona）课程的情况。另一种方法是想象每个学生的每门课程都有相应的课程注册记录。然后，我们有一个实体来表示法庭注册记录。让我们称这个实体为注册。每个注册实体与一个学生和一个部分中,我们有两个关系集,联系课程登记记录,一个学生和一个相关课程报名表在Figure7.18记录部分,我们从Figure7.15显示实体集部分和学生的关系集取而代之的是一个实体集和两套关系:
注册，实体设置代表的登记记录。
•片段reg，关系设定了注册和课程。
•学生reg，关系是有关注册和学生的关系。
注意，我们使用双行表示注册实体的完全参与
当我们从E-Rschema创建一个关系模式时，属性可能会出现在由advisor关系集创建的模式中，稍后我们将会看到;但是，它们不应该出现在advisor关系集中。
数据7.18通过注册和两个关系集替换
图7.15和图7.18的方法都准确地代表了大学的信息，但是使用的方法更紧凑，可能更可取。然而，如果注册处的办公室将其他信息与法庭注册记录联系在一起，那么最好是将其作为一个实体。决定是否使用实体集或关系集的一个可能的指导原则是指定一个关系集，以描述实体之间发生的行为。这种方法也可以用于确定某些属性是否更适合表达关系。
7.7.3二进制与n-ary关系集   
数据库中的关系通常是二进制的。一些看似非二进制的关系实际上可以通过一些二进制关系更好地表现出来。例如，你可以创建一个三元关系的父母，把孩子和他/她的母亲和父亲联系起来。然而，这样的关系也可能是由父母双方的两个二元关系所呈现的，他们分别把孩子和他的母亲和父亲联系在一起。使用父母双方的关系为我们提供了一个孩子母亲的记录，即使我们没有意识到父亲的身份;如果使用三元关系，则需要null值。在这种情况下使用二进制关系集更可取。事实上，总是可以用许多不同的二进制关系集来替换那些非二进制（n-2）关系。为简单起见，考虑抽象三元（n=3）关系集R，关联实体集A、B和c。我们用一个实体集合E替换关系集R，并创建三个关系集，如图7 19所示：
Ra,  E与A相连
Rb,  E与B相连
Rc,  E与C相连
7.7 实体关系设计问题
图7 19三元关系与三种二进制关系。
如果关系集R有任何属性，那么这些属性被赋给实体集合E;此外，为E（因为必须能够根据其属性值来区分实体中不同的实体），为E提供了一个鉴定属性。对于关系集合R中的每一个关系（ai，bi，ci），我们在实体集合e中创建一个新的实体ei，然后，在这三个新的关系集合中，我们插入一个关系如下：
• (ei,ai) inRA.
 • (ei,bi) inRB.
 • (ei,ci) inRC
我们可以用一种直接的方式来概括这个过程。因此，从概念上讲，我们可以限制E-R模型只包含二进制关系集。然而，这种限制并不总是可取的
必须为创建的实体集创建一个标识属性，以表示关系集。该属性以及所需的额外关系集，增加了设计的复杂性，（如我们将在第7节中看到的）总体存储需求。•一个n-ary的关系集更清楚地显示了几个实体参与了一段关系。
可能没有一种方法可以把三元关系中的约束转换成二进制关系的约束。例如，考虑一个约束条件，就是说R是从A到B，从B到C;也就是说，从a到B的每一对都与最多一个C的实体存在关联。这种约束不能通过在关系集RA、RB和RC上使用基数约束来表示。
请考虑第7.2节中的关系集proj-guide，相关的讲师、学生和项目。我们不能直接将proj-guide-导向转换为教师与项目之间的二元关系，以及教师与学生之间的关系。如果我们这样做,
我们能够记录指导员Katz和学生Shankar和Zhang在项目A和B上工作；但是，我们不能记录Katz和学生Shankar在项目A工作和Katz和学生Zhang在项目B上工作，但不能与Zhang一起从事项目A或者和Shankar一起从事B。
这个关系可以通过建立新的实体来划分双重的关系。但是，这样做也不是很自然。
7.74关系属性的排列关系的基数比会影响关系属性的放置。因此，一对一或一对多关系集的属性可以与参与的实体集关联，而不是与关系集关联。例如，让我们具体说明顾问是一对多的关系，这样一个导师可以建议几个学生，但每个学生只能由一名教师提供建议。在这种情况下，属性日期，当指导员成为学生的建议者时，可以与学生实体集关联，如图7.20所示。(为了保持图的简单性，只显示了两个实体集的一些属性。)。由于每个学生实体参与最多一个导师的关系，实例，使得该属性的命名具有相同的含义：“放置与导师有关系的日期”，其中设置了关系集。一对多关系集的属性可以重新定位到关系的“many”侧的实体集。另一方面，对于一对关系集，关系属性可以与任一参与实体一起使用。
在这种转换中放置描述性属性的设计决策--作为关系或实体属性--应该反映被建模企业的特性。设计师可以选择保留日期，以明确表示日期指的是建议，而不是学生大学地位的其他方面(例如，大学生的日期)。
   属性位置的选择对于多到多关联更加明确。回到我们的例子，让我们具体说明一个也许更现实的案例：建议者是一个多到多的关系集合，表示一个讲师可以建议一个或多个学生，而学生可能由一个或多个导师提供建议。如果我们要表达某位讲师成为某一特定学生的导师的日期，则是建议者关系集的属性，而不是任何一个参与的实体。日期是学生的一个属性，例如，我们无法确定哪一位导师在那个特定的日期成为导师。当一个属性由参与实体集的比较确定时，宁愿单独地将该属性与多对多关系集关联。图7.3的位置描述为关系属性；同样，为了保持图形简单，只显示两个实体集的一些属性。
扩展的E-R特性虽然基本的E-R概念可以建模大多数数据库特性，但是数据库的某些方面可以通过对基本E-R 模型的某些扩展来更好地表达。在这部分，我们将讨论专门化、普通化、高抗低层实体集、属性继承和扩展E-R特性。
通过相互帮助和讨论，我们将轻微的使用一个稍微复杂一些的数据库模式：在局部中，我们将移动一个大学模型中的各种人，有人群集合，属性ID，名字，和地址。
一套实体可以包括在某种程度上有别于“原则和规则”中其他实体的实体的子组。例如，实体集中的实体子集可能具有实体集中的所有实体共享的属性。E-R模型为表示这些独特的实体分组提供了一种方法。
例如，实体集Person将来被归类为下列之一，
雇员
学生
这些Person模型中的每一种都由一组属性描述，这些属性包括实体集Person的所有属性以及可能的附加属性。对于考试，员工实体可以通过属性工资来进一步描述，而学习实体则可以由属性tot_cred描述。在一个实体集中指定子组的过程称为专门化.这个专门化的person使我们能够根据人与员工或学生的关系来区分人的实体，一般来说，一个人可以是雇员，一个学生，两者都是或者两者都不是。
 
 
 

转换一般遵循如下原则：


1．一个实体型转换为一个关系模式。实体的属性就是关系的属性。实

体的码就是关系的码。

例如在我们的例子中，学生实体可以转换为如下关系模式，其中学号

为学生关系的码：

学生（学号，姓名，出生日期，所在系，年级，平均成绩） 同样，性

别、宿舍、班级、档案材料、教师、课程、教室、教科书都分别转换

为一个关系模式。


2.一个联系转化为一个关系模式，与该联系相连的各实体的码以及联系

的属性转化为关系的属性，该关系的码则有三种情况：

若联系为1：1，则每个实体的码均是该关系的后选码。

若联系为1：n，则关系的码为n端实体的码。

若联系为m：n，则关系的码为诸实体码的组合。


2.1 联系为1：1

一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对

应的关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及

联系本身的属性均转换为关系的属性，l 每个实体的码均是

该关系的候选码。

如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加

入另一个关系模式的码和联系本身的属性。

例如在我们的例子中，"管理"联系为1:1联系，我们可以将其转换为

一个独立的关系模式：

管理（职工号，班级号）或 管理（职工号，班级号）

管理"联系也可以与班级或教师关系模式合并。如果与班级关系模式合

并，则只需在班级关系中加入教师关系的码，即职工号：

班级：｛班级号，学生人数，职工号｝

同样，如果与教师关系模式合并，则只需在教师关系中加入班级关系

的码，即班级号：

教师：｛职工号，姓名，性别，职称，班级号，是否为优秀班主任｝


2.2 联系为1：n

一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的

关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及

联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

如果与n端对应的关系模式合并，则在n端实体对应模式中加入1端

实体所对应关系模式的码，以及联系本身的属性。而关系的码为n端

实体的码。

例如在我们的例子中，"组成"联系为1:n联系，将其转换为关系模式。

一种方法是使其成为一个独立的关系模式：

组成（学号，班级号）

其中学号为"组成"关系的码。

另一种方法是将其学生关系模式合并，这时学生关系模式为：

学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）

后一种方法可以减少系统中的关系个数，一般情况下更倾向于采用这

种方法。


2.3 联系为m：n

一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及

联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。

例如在我们的例子中，"选修"联系是一个m:n联系，可以将它转换为如

下关系模式，其中学号与课程号为关系的组合码：

选修（学号，课程号，成绩）

三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多

元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

例如在我们的例子中，"选修"联系是一个m:n联系，可以将它转换为如

下关系模式，其中学号与课程号为关系的组合码：

选修（学号，课程号，成绩）

三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多

元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

而关系的码为各实体码的组合。

例如在我们的例子中，"讲授"联系是一个三元联系，可以将它转换为

如下

关系模式，其中课程号、教师号和书号为关系的组合码：  

讲授（课程号，教师号，书号）


3．同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和

m:n三种情况分别处理。

例如，如果教师实体集内部存在领导与被领导的1:n自联系，我们可

以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不

同，可用不同的属性名加以区分，比如在合并后的关系模式中，主码

仍为职工号，再增设一个"系主任"属性，存放相应系主任的职工号。


4．具有相同码的关系模式可合并。

为了减少系统中的关系个数，如果两个关系模式具有相同的主码，可

以考虑将他们合并为一个关系模式。合并方法是将其中一个关系模式

的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可

能同名也可能不同名），并适当调整属性的次序。

例如我们有一个"拥有"关系模式：拥有（学号，性别）

有一个学生关系模式： 学生（学号，姓名，出生日期，所在系，年级，

班级号，平均成绩）

这两个关系模式都以学号为码，我们可以将它们合并为一个关系模式，

假设合并后的关系模式仍叫学生：

学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均

成绩）

按照上述4条原则，学生管理子系统中的18个实体和联系可以转换为

下列关系模型：

学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均

成绩，档案号）

性别（性别，宿舍楼）

宿舍（宿舍编号，地址，性别，人数）

班级（班级号，学生人数）

教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任）

教学（职工号，学号）

课程（课程号，课程名，学分，教室号）

选修（学号，课程号，成绩）

教科书（书号，书名，价钱）

教室（教室编号，地址，容量）

讲授（课程号，教师号，书号）

档案材料（档案号，......）

该关系模型由12个关系模式组成。其中学生关系模式包含了"拥有"联

系、"组成"联系、"归档"联系所对应的关系模式；教师关系模式包含

了"管理"联系所对应的关系模式；宿舍关系模式包含了"住宿"联系所

对应的关系模式；课程关系模式包含了"开设"联系所对应的关系模式。