数据库

实体集和关系集的概念并不精确，而且是可能的定义一组实体以及它们之间的关系不同的方式。在本节中，我们将研究E-R设计中的基本问题数据库模式。第7节将详细介绍设计过程。
7.7.1使用实体集与属性
考虑使用附加属性电话号码（图7.17 a）的实体集教员。可以很容易地认为，手机本身就是一个实体
属性电话号码和位置;地点可能是办公室或家里
手机定位于手机（手机），手机可能以价值为代表。
“移动。"如果我们采用这种观点，我们不会添加属性电话号码
老师。相反,我们创建:
•一个电话实体，设置了属性电话号码和位置。
•一段关系设置在电话中，表示教师之间的联系还有他们拥有的手机。
该选项如图7 17 b所示。
那么，这两个定义之间的主要区别是什么呢？把电话当作一个属性电话号码就意味着老师有
准确地说，每一个电话号码。把电话当作实体电话的许可
教师有几个电话号码（包括零）与他们有关。
然而，我们可以轻松地将电话号码定义为一个多值属性允许每位教练使用多个电话。
主要的区别在于，把手机当作一个实体更好的模型。在这种情况下，人们可能想要保留关于电话的额外信息，比如它的位置，或它的类型（移动电话，IP电话，或普通的旧手机），或所有共享的电话。因此，把手机当作一个实体来对待，要比把它当作一个实体来对待，当一般性可能有用时，属性是适当的。
相比之下，对属性名进行处理是不合适的（
教练)作为一个整体;很难说这个名字本身就是一个实体（与电话相比）。因此，将名称作为属性的一个属性是适当的教师实体集。
由此产生了两个自然问题：什么构成了属性，以及什么构成一个实体集呢?不幸的是，没有简单的答案。distinc的设计主要依赖于被建模的真实世界企业的结构，以及与所讨论的属性相关的语义。
一个常见的错误是使用实体集的主键作为属性
另一个实体集合，而不是使用关系。例如，它是不正确的。将学生的ID建模为教师的属性，即使是每一位指导员建议只有一个学生。关系顾问是正确的表达方式，学生和老师之间的联系，因为他们之间的联系显式的，而不是通过属性隐式的。人们有时会犯的另一个错误是指定关联实体的主键属性设置为关系的属性设置。例如，ID（学生的主键属性）和ID（主键）教师的关键字）不应该作为关系顾问的属性出现。这不应该这样做，因为主键属性已经隐含在关系set.8
7.7.2实体集与关系集的使用
一个对象是否最好由实体集或a表示，并不总是很清楚关系设置。在图7。15中，我们使用了关系集来模拟一名学生（a）课程的情况。另一种选择是想象每门课程都有相应的课程注册记录。然后，我们有一个实体来表示法庭注册记录。让我们调用实体组登记。每个注册实体都与一个学生相关在这一节中，我们有两个关系集，一个是将课程注册记录与学生联系起来另一个是将课程注册记录联系起来
部分。在图7.18中，我们展示了实体集部分和图7。15中的学生用一个实体集和两个关系集取代了关系集：
•注册，实体集代表了法庭注册记录。
•片段reg，关系设定了注册和课程。
•学生reg，关系设置了有关注册和学生的关系。
注意，我们使用双行表示注册实体的完全参与。
图7。15和图7。18的方法都准确地表示了
大学的信息，但是使用的方法更紧凑，可能
更可取的。但是，如果注册处的办公室将其他信息与在法庭注册记录中，最好将它作为一个独立的实体。
确定是否使用实体集或a的一个可能的指导原则关系集是指定一个关系集来描述发生的动作
实体之间的关系。这种方法也可以用于确定是否确定属性可以更恰当地表示为关系。
7.7.3二进制与n-ary关系集
数据库中的关系通常是二进制的。有些关系似乎是非二进制可以用几种二进制关系更好地表示。例如，我们可以创建三元关系的父系，将子与子联系起来他/她的母亲和父亲。然而，这样的关系也可以被表示由父母双方的两种二元关系，将孩子与母亲的关系单独和父亲。利用父母双方的关系为我们提供了一个孩子母亲的记录，即使我们没有意识到父亲的身份;一个空
如果使用三元关系，则需要值。使用二进制在这种情况下，关系集更可取。
事实上，总是可以用许多不同的二进制关系集替换非二进制（n-ary，n>2）关系ship。为简单起见,考虑抽象三元（n=3）关系集R，关联实体集A、B和c。用一个实体集合E代替关系集R，并创建三个关系集
如图7.19所示：
•RA，关于E和a的关系。
•RB，与E和b有关。
•RC，与E和c有关。

如果关系集R有任何属性，那么这些属性被赋给实体集合E;
此外，为E创建了一个特殊的标识属性（因为它必须是可能的
在一个实体中根据属性值来区分不同的实体）。
对于关系集R中的每一个关系（ai，bi，ci），我们创建一个新实体
在实体集合e中，然后，在这三个新的关系集合中，我们插入一个
关系如下:


• (ei, ai) in RA.
• (ei, bi) in RB.
• (ei, ci) in RC.

我们可以用一种直接的方式将这个过程推广到n-ary关系的ship集合。因此，从概念上讲，我们可以限制E-R模型只包含二进制
集的关系。然而，这种限制并不总是可取的。


•需要为创建的实体创建一个标识属性
表示关系集。这个属性，以及额外的关系
所需的集合，增加了设计的复杂性（我们将在其中看到
第七十六条）总体存储要求。

•一个n-ary关系集更清楚地显示出有几个实体参与
在一个关系
•可能没有办法将限制因素转化为三元关系
对二进制关系的约束。例如，考虑一个关于R是从A到B到C的多对一的欺骗;也就是每一对
来自A和B的实体最多与一个C实体关联。这个约束
不能用关系集上的基数约束来表示
RA、RB和RC。
考虑一下在第7。2节中关系设置proj指南，相关的讲师，
学生,和项目。我们不能直接将proj指南拆分为二进制关系
教师与项目之间，教师与学生之间。如果我们这样做,
我们可以记录下导师Katz在A和B项目上的工作
学生Shankar和张;但是，我们无法记录Katz
和学生一起在A项目工作，和学生一起在项目B上工作
张，但与张或在项目B项目上没有合作。
关系集proj向导可以通过创建来分割成二进制关系
如上所述的新实体。然而，这样做并不十分自然。

关系的基数比会影响关系的位置
属性。因此，一对一或一对多关系集的属性可以是
与参与的实体集相关联，而不是与关系ship集合相关联。例如，让我们指定advisor是一对多关系集
这样一个老师可以给几个学生提供建议，但是每个学生都可以
仅由一名教师担任顾问。在本例中，属性日期指定了
当讲师成为学生的导师时，可以和
学生实体设置，如图7 20所描述。（为了使数字保持简单
显示了这两个实体集的一些属性。）由于每个学生的实体
参与一段与大多数教师的关系，使之成为一种
属性指定与将日期与顾问放在一起具有相同的含义
关系集。一对多关系集的属性可以重新定位
只对关系中“许多”方面的实体进行设置。对于一对一的关系集，另一方面，关系属性可以与之关联
任何一个参与的实体。
在这种情况下，在何处放置描述性属性的设计决策
作为一种关系或实体属性，应该反映出
企业建模。设计者可以选择保留日期作为属性
明确表示日期是指咨询关系的顾问
而不是学生的大学地位的其他方面（例如，
接受大学)。
对于多对多rela tionship集来说，属性放置的选择更加明确。回到我们的例子，让我们指定可能更现实的
这个顾问是多对多关系的集合表示一个讲师
可以建议一个或多个学生，一个学生可以被一个学生建议
或更多的教师。如果我们要表达一个具体的老师的日期
成为特定学生的顾问，日期必须是顾问的属性
关系集，而不是参与其中的一个实体。如果日期是一个
例如，学生的属性，我们无法确定是哪位老师
那个特定日期的顾问。当一个属性由参与实体集的com绑定决定时，而不是单独的一个实体，
属性必须与多对多关系设置关联。
将日期的放置描述为关系属性;同样，为了保持形象
很简单，只显示了两个实体集的一些属性。