四巨头第三周作业翻译
7.7 实体-关系设计问题
实体集和关系集的概念不唯一，可以通过多种不同的方式定义一组实体及其之间的关系。在本节中，我们将研究E-R数据库模式设计中的基本问题.。第7.10节进一步详细介绍设计过程。
7.7.1实体集与属性的使用
考虑使用附加属性电话号码的实体集指导员(图7.17a)，可以很简单的说，电话本身就是一个具有属性、电话号码和位置的实体；该位置可能是电话所在的办公室或家庭，移动(手机)电话可能以“Mobile”的值表示。如果我们从这个角度出发，我们不会将电话号码作为属性添加给指导员。相反，我们创建：一个具有属性、电话号码和位置的电话实体。
一种以电话为基础的关系，指的是指导员和他们拥有的电话之间的联系。
此选项如图7.17B所示：
那么，这两种定义的主要区别是什么呢？将电话当作属性电话号码意味着指导员每个人都有一个电话号码。将电话当作实体电话允许指导员有几个电话号码(包括零)与他们相关联。但是，我们可以轻松地将电话号码定义为多值属性，以便允许每个指导员使用多个电话。
因此，两者的主要的区别在于，将手机视为一个实体更好地模拟了这样一种情况，即人们可能希望保存有关电话的额外信息，例如其位置、类型(移动电话、ip电话或普通的旧电话)，或者所有共享电话的人。因此，将电话视为一个实体比将其视为一个属性更为普遍，并且在通用性可能有用时也是合适的。
相反，将属性名称(指导员)作为一个实体来处理是不合适的；很难争辩说名称本身就是一个实体(与电话相反)。因此，将名字作为指导员实体集的属性是合适的。
因此自然产生了两个问题：什么构成属性，什么构成实体集？不幸的是，没有简单的答案，区别主要取决于被建模的现实世界的结构，以及与所讨论的属性相关的语义。
一个常见的错误是使用实体集的主键作为另一个实体集的属性，而不是使用关系。例如，将学生的ID建模作为指导员的属性是不正确的，即使每个讲师只教授一个学生。关系顾问是以正确的方式来表示学生和教师之间的联系，因为它使他们的联系变得明确，而不是通过一个属性暗示。
人们有时犯的另一个相关错误是将相关实体集的主键属性指定为关系集的属性。例如，ID(学生的主键属性)和ID(讲师的主键)不应该显示为关系顾问的属性。不应该这样做，因为主键属性已经隐含在关系集中。
7.7.2实体集与关系集的使用
我们并不总是清楚对象最好用实体集还是关系集来表示。在图7.15中，我们使用了采取关系集来模拟学生上(某一节)课程的情况。另一种方法是设想每个学生都有一门课程注册记录。然后，我们设置一个实体来表示课程注册记录。每个注册实体都与一个学生和一个部分相关，因此我们有两个关系集，一个是将课程注册记录与学生联系起来，另一个是将课程注册记录与部门相关联。在图7.18中，我们显示了图7.15中的实体集部分和图7.15中的学生，用一个实体集和两个关系集替换了取舍关系集：
注册，代表课程注册记录的实体集。
章节注册，代表与注册和课程相关的关系集。
学生注册，代表注册与学生的关系。
请注意，我们使用双行线来表示注册实体的总参与情况。
图7.15和图7.18的方法都精确地表示了大学的信息，但使用的是更紧凑，更优质的一种方式。但是，如果校长办公室将其他信息与A联系在一起，则课程登记记录最好的办法是让它成为一个实体。
确定是否使用实体集或者关系集是指定一个关系集来描述发生的动作或实体之间的关系，这种方法也有助于决定是否确定属性可以更恰当地表示为关系。
7.7.3二元与多元关系集
数据库中的关系通常是双方的。有些关系似乎是多方的，实际上多方可以更好地代表的一些双方的关系。例如，可以创建一个三元关系父类，将子对象与他/她的母亲和父亲相关联。然而，这种关系也可以被两个二元关系所取代，母亲和父亲，把一个孩子和他/她的母亲和父亲分开。利用父母和父亲的两种关系给我们提供了一个孩子的母亲的记录，即使我们不知道父亲的身份；如果使用三元关系父，则需要一个空值。使用二元关系在这种情况下，关系集更可取。
事实上，它始终是可能由许多不同的二元关系集取代二元（n，n＞2）关系。为简单起见，考虑到抽象的三元（n＝3）关系集r，与实体集a、b和C.用实体集e替换关系集r，并创建三个关系集如图7.19所示：
•RA，涉及E和A.
•与E和B.有关的RB
·RC，有关E和C.
如果关系集r具有任何属性，则将这些属性分配给实体集E；此外，为E创建了一个特殊的标识属性（因为它必须是在根据属性值设置的实体中区分不同的实体）。对于关系集r中的每个关系（ai、BI、CI），我们创建一个新实体.在实体集合E中，然后，在三个新的关系集中的每一个中，我们插入一个关系如下：
•（EI，ai）在RA。
•（EI，BI）在RB。
·（EI，CI）在RC中。
我们可以把这个过程归纳为一个简单的方式向多元关系集。因此，从概念上讲，我们可以限制E-R模型只包括二元关系集。然而，这种限制并不总是可取的。
•必须为创建的实体集创建标识属性表示关系集。这个属性，以及额外的关系需要设置，增加了设计的复杂性和（我们将看到）第7.6节）总体存储要求。
•一个n元关系设置显示更加清晰，多个单位参与在单一关系中。
•可能没有办法来解释三元关系的制约因素和对二元关系的约束。例如，考虑一个约束，即R是从A到B的多对一，也就是说，每对a和b的实体最多与一个C实体相关联。这一约束不能用关系集上的基数约束表示RA，RB和RC。
考虑关系定项目指导第7.2.2，有关教师，学生和项目。我们不能直接分裂为二元关系在项目指南教师与项目之间，教师与学生之间。如果我们这样做了我们将能够记录卡茨老师，学生Shankar和张在A和B项目中的工作。然而，我们就无法记录卡茨工程项目的学生Shankar和工程项目B的学生张，且不能和张工作于项目A或和Shankar工作于项目B 。
建立关系和指导可以分为二元关系的建立，如上所述的一个新实体集。然而，这样做并不是很自然。
关系的基数比可以影响关系属性的位置。因此，一对一或一对多关系集的属性可以被关联到一个参与的实体集，而不是关系。例如，我们指定导师是一对多的关系,一个老师可能给几个学生建议，但可以给每个学生建议的只有一个老师。在这种情况下，属性可以与学生实体设置关联，如图7.20所示，它指定了何时成为一个学生的导师。(为了保持图的简单性，只显示了两个实体集的一些属性。)因为每个学生实体参与导师的关系最多一个，使这个属性指定相同的意义将把日期与导师关系确定。一对多关系的属性集只能重新定位，以实体集“许多 ”的关系。另一方面，对于一对一的关系，关系交付可以与任何一个参与实体关联。
在这种情况下，在哪放置描述性属性的设计决策——作为关系或实体属性——应该反映被建模企业的特征。设计人员可以选择保留日期作为顾问的一个属性，明确表示日期指的是咨询关系，而不是学生大学地位的其他方面(例如，上大学的日期)。
对于多对多关系集，属性放置的选择更加明确。回到我们的例子，让我们指定一个可能更现实的例子，假设老师是个多对多关系的集合，表示教师可以建议一个或多个学生，一个学生可以被一个或多个讲师提供建议。如果我们要表达某个特定的教师做某一特定学生的导师的日期，那么日期必须是讲师关系组的一个属性，而不是一个参与实体。例如，如果日期是学生的一个属性，我们就不能确定哪位老师在那个特定的日期成为了顾问。当一个属性由参与实体集的组合而不是单独的实体决定时，该属性必须与多对多关系集相关联。同样，为了保持图的简单性，只显示了两个实体集的一些属性。
