《Database.System.Concepts》（P290~295）。

     E-R图的设计问题

    实体集和关系集的概念并不精确，可以通过多种不同的方式定义一组实体和它们之间的关系。在本节中，我们将研究E-R数据库模式设计中的基本问题。第7.10节详细介绍了设计过程。

7.7.1实体集与属性的使用

    考虑使用附加属性电话号码的实体设置指导书(图7.17a)。可以很容易地认为，电话本身就是一个实体，它拥有属性电话号码和位置;地点可能是电话所在的办公室或家，手机可能代表着“移动”的价值如果我们采用这个观点，我们就不会将属性电话号码添加到指导书。”相反,我们创建:

•一个带有属性电话号码和位置的电话实体。

• 一段关系设置为固定手机，表示教师和手机之间的联系。

此选项如图7.17b所示

    那么，教师这两种定义的主要区别是什么呢?把手机当作一个属性电话号码，意味着老师们每个人都有一个电话号码。把手机当作实体电话来处理，可以让老师有几个电话号码(包括零)。但是，我们可以很容易地将电话号码定义为一个多值属性，以允许多个手机使用。

    主要的区别是，把手机当成一个实体更好的模型一个人可能想要保留关于电话的额外信息，比如它的位置，或者它的类型(手机，IP电话，或者普通的老电话)，或者所有的共享电话的人。因此，将电话作为一个实体来处理，比把它当作一个属性来处理更普遍，并且在一般性可能有用的情况下是恰当的。

   与之相反，对一个教员的属性名进行处理是不合适的;很难说名字本身就是一个实体(与电话相比)。因此，将名称作为讲师实体集的属性是合适的。由此产生了两个自然的问题；什么构成一个属性，什么构成一个实体集?不幸的是，没有简单的答案。这些区别主要取决于建模的al-world企业的结构，以及与该属性相关的语义。一个常见的错误是使用实体集的主键作为另一个实体集的属性，而不是使用关系。例如，即使每个教师只建议一个学生，但将学生的ID建模为教师的属性是不正确的。关系倡导是表示学生和教师之间的连接的正确方法，因为它可以显式地连接他们的连接，而不是通过属性。

    人们有时会犯的另一个相关错误是将相关实体集的主键属性指定为关系集的属性。例如，ID (学生的主键属性)和ID(教师的主键)不应该作为关系顾问的属性出现。这是不应该做的，因为主键属性已经隐含在关系中。

7.7.2使用实体集和关系集。

    在图7.15中，我们使用了“建立关系网”来模拟一个学生学习某部分的课程的情况。另一种选择是想象每个学生都有一个课程注册记录。然后，我们有一个实体集来表示课程注册记录。我们称这个实体为集合注册。每个注册实体与一名学生和恰好一节相关，因此我们有两套关系集，一份是学生的课程注册记录，另一份是将课程注册记录与各部分联系起来。然后，我们有一个实体集来表示课程注册记录。我们称这个实体为集合注册。每个注册实体与一名学生和恰好一节相关，因此我们有两套关系集，一份是学生的课程注册记录，另一份是将课程注册记录与各部分联系起来。在图7.18中，我们通过一个实体集和两个关系集来显示实体集部分和图7.15的学生，并将其替换为一个实体集和两个关系集：

•注册，实体设置代表课程注册记录。

•部分注册，与注册和课程相关的关系。

•学生注册，关系设置注册和学生。

    注意，我们使用双行表示注册实体的完全参与。

    图7.15和图7.18的方法都准确地代表了大学的信息，但是使用的方式更紧凑，可能更可取。然而，如果登记官办公室将其他信息与法庭登记记录联系在一起，最好把它作为一个实体。

    确定是否使用实体集或关系集的一个可能的指导原则是设计一种关系集来描述实体之间发生的动作。这种方法还可以用于判断某些属性是否可以更恰当地表示为关系。

7.7.3对n-ary关系集。

    数据库中的关系通常是二进制的。一些看似非二进制的关系实际上可以用几种二进制关系来表示。例如，一个人可以创造一种三元关系的父母，把一个孩子与他/她的父母联系起来。然而，这种关系也可以由两种二元关系来表示，即父母，将一个孩子与他/她的母亲和父亲分开。使用这两种关系，母亲和父亲为我们提供了孩子母亲的记录，即使我们没有意识到父亲的身份;如果使用三元关系的父母，则需要一个空值。在这种情况下，使用二进制关系集更好。事实上，总是可以用一些不同的二进制关系集来替换一个非二进制(n-ary, for n > 2)关系。为简单起见，考虑抽象三元关系集R，关联实体集A、B、和c。我们用一个实体集合E来替换关系集Rby，并创建三个关系集，如图7.19所示:

•RA，有关E和A。

•RB，与E和B有关。

•RC，关于E和C的。

如果关系集R有任何属性，则将它们分配给实体集E;此外，还为E创建了一个特殊的标识属性(因为必须能够在一个实体中根据其属性值区分不同的实体)。对于关系集R中的每一段关系(ai,bi,ci)，我们在实体集合中创建一个新的实体ei，然后，在这三个新的关系集合中，我们插入一段关系如下:

我们可以用简单的方式将这个过程概括为n-ary关系集。因此，从概念上讲，我们可以将E-R模型限制为只包含二进制关系集。然而，这种限制并不总是可取的。

可能必须为创建的实体集创建一个标识属性来表示关系。这个属性，以及所需的额外关系集，增加了设计的复杂性，(正如我们将在第7.6节中看到的)总体存储需求。

n-ary关系集更清楚地显示了几个实体之间的关系。

可能没有办法将三元关系的限制转化为对二元关系的限制。例如，考虑一个限制，该限制说R是多对一，从a, B到C;也就是说，A和B中的每一对实体都与最多一个C实体关联。这个限制不能通过使用关系集RA、RB和RC的基数限制来表示。

请参考7.2.2节中关于指导教师、学生和项目的关系集项目指南。我们不能直接将项目指南分割为教师与项目之间的二元关系，也不能直接将其分割为教师与学生之间的二元关系。

如果我们这样做了，我们就能记录下卡茨在A和B项目上与学生Shankar和Zhang合作的情况;但是，我们不能说Katz和学生Shankar一起在A项目上工作，在B项目上和学生Zhang一起工作，但是他并没有和ZHhang合作项目A，也没有和Shankar合作项目。

通过创建如上所述的新实体集，关系集项目指南可以被分割成二进制关系。然而，这样做不是很自然。

7.7.4关系属性的位置

关系的基数比可以影响关系属性的位置。因此,一对一或一对多关系集的属性可以被关联到一个参与的实体集,而不是关系。例如,我们指定顾问是一对多的关系,一个老师可能对几个学生,但每个学生只对一个老师。在这种情况下，属性date可以与学生实体设置关联，如图7.20所示，它指定了何时成为一个学生的顾问。(为了保持图的简单性，只显示了两个实体集的一些属性。)因为每个学生实体参与导师的关系最多一个实例,使这个属性指定相同的意义将把日期与顾问关系确定。一对多关系的属性集只能重新定位,以实体集“许多”的关系。另一方面，对于一对一的关系，关系交付可以与任何一个参与实体关联。

在这种情况下，何处放置描述性属性的设计决策——作为关系或实体属性——应该反映被建模企业的特征。设计者可以选择保留日期作为顾问的一个属性，明确表示日期指的是咨询关系，而不是学生的大学地位的其他方面(例如，接受大学的日期)。

对于多对多关系集，属性放置的选择更加明确。回到我们的例子，让我们指定一个可能更现实的例子，指导老师是多对多关系的集合，表示教师可以指导一个或多个学生，一个学生可以被一个或多个讲师指导。如果我们要表达某个特定的教师成为某一特定学生的顾问的日期，那么日期必须是顾问关系集合的属性，而不是参与实体中的任何一个。例如，如果日期是学生的一个属性，我们就不能确定哪位老师在那个特定的日期成为了顾问。当一个属性由参与实体集的组合而不是单独的实体决定时，该属性必须与多对多关系集相关联。同样，为了保持图的简单性，只显示了两个实体集的一些属性。

7.8扩展的e - r的特征

尽管基本的E-R概念可以建模大多数数据库特性，但是数据库的某些方面可以通过对基本的E-R模型的某些扩展来更恰当地表达。

在本节中,我们扩展讨论了e - r专业化的特点,概括,高低层实体集,属性继承和聚合。

为了帮助讨论，我们将使用一个稍微复杂的数据库模式为大学。特别是，我们将通过定义一个实体集person来为大学内的各种人员建模，并使用属性ID、名称和地址。

7.8.1专业化

一个实体集可能包含一些实体的子组，这些实体在某些方面与其他实体不同。例如，一个实体集合中的一个实体的子集可能具有实体中所有实体不共享的属性。

作为一个例子，实体集person可以进一步划分为以下内容之一:

员工

学生

每个person类型都由一组属性描述，这些属性包括实体集person的所有属性，以及可能的附加属性。例如，雇员实体可以通过属性工资来进一步描述，而学生实体则可以由属性tot cred进一步描述。在实体集合中指定子组的过程称为专门化。person的专业化允许我们根据员工和学生的不同来区分不同的个体:一般来说，一个人可以是雇员、学生、两者，或者两者都不是。