《Database.System.Concepts》【7.7 Entity-Relationship Design Issues】（P290~295）翻
原著链接：[Database.System.Concepts(6th.Edition.2010)].Abraham.Silberschatz.文字版[www.xuexi111.com].pdf
原著作者：Silberschatz, Abraham/ Korth, Henry F./ Sudarshan, S.
实体—关系设计问题
实体关系设计解决了实体集和关系集的概念不精确的问题，并且可以以多种不同的方式定义一组实体及其关系。在这一部分中，我们研究的基本问题，在数据库的 E-R 模型的设计。第 7.10 部分详细介绍了设计过程。7.71 实体集与属性的使用
考虑使用附加属性phone_number的实体集指导员(图-ure7.17a)。可以很容易地认为，电话本身就是一个实体，具有属性phone_n u mber和位置；该位置可能是电话所在的办公室或家，移动(手机)电话可能以“Mobile”值表示。如果我们从这个角度出发，我们不会将属性phone_number添加到讲师。相反，我们创建：
- 具有属性、电话号码和位置的电话实体。
- 一种关系设定为inst_phone，表示教师和他们拥有的电话之间的关联。
图7.17B。因此，这两个定义的主要区别在于，指导者将电话视为属性phone_室长，这意味着教师每个人都有一个电话号码。将电话当作实体电话允许指导员有几个电话号码(包括零)与他们相关联。但是，我们可以轻松地将phone_number定义为多值属性，以便允许每个指导员使用多个电话。
主要区别在于，把手机作为一个实体更好地建模的情况下，一个可能要保留关于手机的额外信息，如它的位置，或它的类型（手机，LP电话，或普通老式电话），或所有谁分享电话。因此，将电话视为一个实体比将其视为一个属性更为普遍，并且在一般性可能有用时也是合适的。
相反，将属性名称(指导员)作为一个实体来处理是不合适的；很难争辩说名称本身就是一个实体(与电话相反)。因此，将name作为指导员实体集的属性是合适的。
因此产生了两个自然问题：什么构成属性？什么构成实体集？不幸的是，没有简单的答案。这些差异主要取决于被建模的现实世界企业的结构，以及与所涉及的属性相关的语义。
一个常见的错误是将实体集的主键用作另一个实体集的属性，而不是使用关系。例如，如果每个教员只建议一个学生，将学生的ID作为教师的属性进行建模是错误的。关系顾问是代表学生和教师之间的联系的正确方式，因为它使他们的关系明确的，而不是通过一个属性的隐式。
人们有时犯的另一个相关错误是将相关实体集的主键属性指定为关系集的属性。例如，ID（学生的关键属性）和身份（教官的主键）不应该出现的adoisor属性关系。这个不应该这样做，因为主键属性已经在关系集中隐含了。
7.72 实体集与关系集的使用
并不总是清楚对象是最好的用实体集还是关系集来表示。在图7.15中，我们使用了Tnodel设置的采取关系，即学生上(某一节)课程的情况。另一种办法是设想每一位学生都有一份课程注册记录。然后，我们设置了一个实体来表示课程注册记录。让我们称之为实体集注册。每个注册实体都与一个学生和一个部分完全相关，因此我们有两个关系集，一个是将课程注册记录与学生联系起来，另一个是将课程注册记录与部门相关联。在图7.18中，我们显示了图7.15中的实体集部分和学生，图7.15中的取舍关系集被一个实体集和两个关系集所取代：
- 注册，表示课程注册记录的实体集。
- 第三节，与注册和课程相关的关系集。
- 学生注册与学生关系集。
请注意，我们使用双线表示注册实体的总体参与情况。图7.15和图7.18的方法都准确地表示了大学的信息，但是使用VISS更简洁，而且可能更好。然而，如果注册机构将其他信息与课程注册记录联系在一起，最好将其作为一个独立的实体。
确定是使用实体集还是关系集的一个可能准则是指定关系集来描述在各实体之间发生的操作。这种方法在决定某些属性是否可以更恰当地表示为关系时也很有用。
7.73 二进制与n元关系集
数据库中的关系通常是二进制的。一些看似非二进制的关系实际上可以更好地由几个二进制关系来表示。例如，我们可以建立一个三元关系的父母，把孩子和他的父母联系起来。然而，这种关系也可以由两种二元关系来代表，即另一种关系和父亲关系，分别将子女与其母亲和父亲联系起来。使用这两种关系，母亲和父亲为我们提供了孩子母亲的记录，即使我们不知道父亲的身份；如果使用三元关系父母，则需要一个空值。在这种情况下，最好使用二进制关系集。
实际上，总是可以用许多不同的二进制关系集来替换非二进制(n-ary，对于n>2)关系集。为简单起见，考虑抽象三元(n=3)关系集R、关联实体集A、B和C。我们用实体集E替换关系集E，并创建三个关系集，如图7.19所示。
- Ra，关联E和A
- RB，关联E和B
- RC，关联E和C
如果关系集 R 具有任何属性, 则将这些属性赋给实体集 E;此外, 为 E 创建了一个特殊的标识属性 (为能够根据属性值对实体集中的不同实体进行区分)。对于关系集 R 中的每个关系 (ai + bi、Ci), 我们创建一个新的实体ei. 然后, 在三新的关系集中, 我们插入一个如下关系:
- (ei,ai)in RA
- (ei,bi) in RB
- (ei,ci) in RC
我们可以直截了当地将这个过程概括为n元关系。因此, 从概念上讲, 我们可以限制 e-R 模型只包含二进制关系集。然而, 这种限制并不总是可取的。
- 可以为创建的实体集创建标识属性, 以便表示关系集。此属性以及额外的关系设置需要, 增加设计的复杂性和 (我们可以在第7.6 节看到) 总体存储要求。
- 多元关系集更清楚地显示了几个实体之间单一的关系。
- 可能没有一种方法来转换对三元关系的约束到二进制关系的约束。例如, 考虑一个约束, R 是多对一从 A, B 到 C;即每对A 和 B 中的实体最多与一个 C 实体关联。此约束不能通过在关系集上使用基数约束来表示RA,RB 和 RC。
请考虑 "关系集" 项目指南在7.2.2, 相关讲师,学生和项目。我们不能直接将项目指南分成二进制关系教师与项目之间以及教师与学生之间的关系。如果我们这样做,我们将能够记录教师 Katz 和学生Shankar和张一起做的工作A和B;然而, 我们将无法记录的 Katz在项目 a 与学生Shankar一起工作以及项目 B 是与学生张一起工作, 但无法和张一起完成工作A或与Shankar一起完成工作B。
关系集项目指南可以通过创建如上文所述的新实体集。然而, 这样做不会很自然。
7.7.4关系属性的设置
关系的基数比可能影响关系的放置属性.因此, 一对一或一对一关系集的属性可以与参与实体集之一关联, 而不是与关系集相关联。例如，让我们指定顾问是一个一对多的关系这样一个教练会建议几个学生，但每一个学生都只有一个教练的建议。在这种情况下，属性中指定的日期，当教师成为学生的顾问，可能与学生实体集，如图7.20示。（未来使图看起来简单，只显示两个实体集的属性。）由于每个学生的实体参与最多的一个实例的教练的关系，使得这属性名称相同的意思会和顾问将日期建立关系，一对多关系集的位置可以改变属性只有实体集的关系的“多”的一面。在一对一关系集，另一方面，关系属性可以为实体的任何一个。
设计决策的地方描述属性，在这种情况下作为一个关系或实体属性应体现的特点企业建模，设计者可以选择保留日期作为一个属性，顾问表达明确的日期是指关系的建议而不是其他方面的学生的大学的地位（例如，大学的录取时间）。
对于多对多关系集, 属性位置的选择更为明确。回到我们的例子, 让我们指定也许更现实的情况下, 顾问是一个多对多关系集表示讲师可能建议一个或多个学生, 和一个学生可能被告知一个或更多的导师。如果我们要表达一个特定讲师的日期成为特定学生的顾问, 日期必须是顾问的属性关系集, 而不是任何一个参与实体。如果日期是学生的属性, 例如, 我们不能确定哪个讲师成为那个特定日期的顾问。当属性由参与实体集的组合 (而不是单独的实体) 确定时, 该属性必须与多对多关系集关联。图7。3将日期的位置描述为关系属性;再次, 保持数字简单, 只显示两个实体集的某些属性。
虽然E-R基本概念模型是大多数数据库的特点，某些方面一个数据库可能更贴切的表达一定的扩展的基础E-R模型。在这一部分中，我们讨论了专业化扩展E-R特征化、一般化，较高和较低级别的实体集，属性继承和聚集。
为了帮助讨论, 我们将使用一个稍微复杂的数据库大学的模式。特别是, 我们将模型的各种人通过定义实体集人, 具有属性 ID、名称和地址。
7.8.1 特别化
实体集可能包括以某种方式不同的实体的 再组来自集合中的其他实体。例如, 实体集内的实体子集
可能具有实体集中的所有实体都不共享的属性。电子R模型提供了表示这些特殊实体分组的方法。
作为一个例子，该实体组可以被进一步分类为如下所示：
员工
学生
这些类型中的每一个都由一组属性描述, 其中包括所有实体集人员的属性加上可能附加的属性。例如, 雇员实体可以由属性工资进一步描述, 而学生实体可以由属性绩点进一步描述。的过程中在实体集中指定再分组称为专门化。人的专业化使我们能够根据他们是否对应于雇员或学生: 一般来说, 一个人可能是一个雇员, 一个学生, 或者两者都不是。