实体集与属性

实体关系设计问题

实体集和关系集的概念并不精确，并且可以用许多不同的方式定义一组实体和它们之间的关系。在本节中，我们将研究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使我们能够根据人与员工或学生的关系来区分人的实体，一般来说，一个人可以是雇员，一个学生，两者都是或者两者都不是。