第三周翻译

7.7实体-关系设计问题
   实体集和关系集的概念是不精确的，可以用多种不同的方式定义一组实体和它们之间的关系
。本节讨论E-R数据库模式设计中的一些基本问题。在7.10节中进行更详细地设计过程讨论。

    7.7.1用实体集还是用属性

这样就可以很容易地认为，电话号码本身就是一个单独实体具有属性和位置；该位置可能是电话所在的办公室或住所，移动(手机)电话可能以“移动”值表示。如果我们采用这个观点，我们不会将属性电话号码添加到指导员。相反，我们创建：

具有属性、电话号码和位置的电话实体。

一种以电话为基础的关系，指的是电话的主人和他们拥有的电话之间的联系
 这个方法如图7.17b所示

那么关于教师的两个定义主要区别是什么？将电话号码视为具有属性的电话号码意味着电话的主人有且只有一个电话号码将电话号码视为实体电话号码允许电话号码的主人可以拥有好几个电话号码（包括零个），这些电话号码与电话号码的主人相关联。但是我们可以轻松的将电话号码定义为多值属性，这样的话允许每个教师拥多个号码。

那么，主要的区别在于将电话号码视为实体优点更多。或许一个人想保留关于电话号码的额外信息，例如他的位置，他的类型(移动，或者IP电话，或者普通的旧手机等）或共享电话的所有的人，将手机作为一个实体来对待比把它当作一个实体来说更普遍属性，适用于普遍性可能更有用的情况。相比之下，处理属性名称是不合适的，教师）作为一个实体;很难说名称本身就是一个实体（与电话相反）。因此，把电话视为一个实体比把它视为一个属性的方式更具通用性

相反，将（一名教师）姓名的属性作为一个实体就不太合适；它是有困难的把名字本身说成一个实体（区别于手机）。因此，将名称作为教师实体集的属性是合适的。

由此产生了两个自然问题：什么构成属性？什么构成实体集？不幸的是，这并不是两个简单问题。区分它们主要依赖于被建模的现实世界的企业的结构，以及被讨论的的属性的相关语义。

一个常见的错误是将实体集的主键用作另一个实体集的属性，而不是使用关系。例如，如果每个教员只指导一个学生，将学生的ID作为教师的属性进行建模是错误的。关系顾问是表示学生和教师之间联系的正确方式，因为它使他们的关系明确，而不是将这种关系隐含在属性中。

人们有时犯的另一个相关错误是将相关实体集的主键属性指定为关系集的属性。例如，ID（学生的关键属性）和ID（教官的主键）不应该在关系顾问中作为属性出现。这不应该是由于主关键属性已经隐含在关系中设定了。

7.7.2使用实体集和关系集

一个对象是否最好由一个实体集或一个关系集来表示并不总是清楚的。如图7.15所示，我们使用了关系集来模拟学生接受（某一次）课程的情况。另一种方法是想象每个学生都有一个课程-注册记录。然后，我们设置一个实体来表示课程注册记录。每个注册的实体是一个学生和一个部分相关，所以我们有两个关系集，一个涉及课程-注册记录和学生关联，另一个将课程-注册记录和课程相关。如图7.18所示，我们以关系定图7.15中一个实体集和关系集并用它们俩取代实体部分和学生。

登记，代表课程-注册记录的实体集。

部分注册和课程有关的关系集。

学生注册，关系登记和学生的关系。

注意，我们使用双线表示registration实体全部参与。

数据库设计和E-R模型

图7.15和图7.18的方法都准确地代表了大学的信息，但使用的方法更紧凑，也更可取。然而，如果注册办公室通过课程-注册记录与其他信息相关联，那么最好让它本身作为一个实体。

在决定是否使用一个实体集和关系集的一个指导方针时，是用关系来描述实体间的行为。这种方法也有助于决定某些属性是否可以更恰当地表示为关系。

7.73二进制和多进制关系集

 数据库中的关系一般都是二进制。一些看似非二进制的关系实际上可以更好地为代表的一些二进制的关系。例如，你可以创建一个三元关系的父母，把孩子与他/她的母亲和父亲联系起来。然而，像这样的关系也可以通过两个二进制的关系代表，母亲和父亲，将孩子与他/她的母亲和父亲相关联。用两个关系母亲和父亲提供我们一个孩子母亲的记录，即使我们不知道到父亲的身份。如果使用三元关系，则需要空值。在这个例子中使用二进制关系是更加合适的。

  事实上，它始终是可能取代二进制关系有许多不同的二进制关系集。为简单起见，考虑摘要三元（n = 3）关系集R，有关实体集A，B，C。我们用一个实体集e替换关系集r，并创建三个关系集，如图7.19所示。

如果关系集R有属性，则将这些属性分配给实体集E；进一步的，为E创造了一个特殊的识别属性。（因为它必须可能被不同的建立在他们属性值的实体所区分）。对于在关系集R中的每个关系，我们在实体集E中创造一个新的实体。然后，在其他三段新的关系集中，我们插入一个关系如下。

我们可以把这个过程在一个直截了当的方式多元关系集。因此，概念地，我们可以限定E-R模型仅包括一个二进制关系集。然而，这种限制并不总是可取的。

必须为其创建的实体集创建标识属性，以表示关系集。这个属性和这个所需要的多余的系集，增加了设计的复杂性（我们可以在7.6节中看到）和整体的存储要求。

一个n元关系设置显示更加清晰，几个实体参与一个单一的关系。

可能没有一种方式去将三元关系翻译为二元关系，例如，考虑到r是ABC多对一的限制。也就是说，每一对A和B的实体与至多一个C实体相关联。这个限制不能被ABC关系集的限制所表示。

考虑到7.22节中的关系集相关的教师，学生，项目。我们不能直接的将项目指南分离到分离到教和项目还有教师和学生的二进制关系中。如果我们这样做的话，我们将可能会记录到教师katz在项目A和B中和学生shankar和张一起工作。然而，我们不能记录到katz在项目A中和学生shankar一起工作，也不能记录到在项目B中和张学生一起工作。只能记录到在项目A中和张学生一起在项目B中和shankar一起。

项目指南关系集可以将其分为二元关系创造一个新的实体集如上。然而，这样做不会很自然。

7.7.4关系属性的安置

  关系中的基数比可以影响到关系属性的安置。因此一对一或者一对多的关系集属性可以和其中一个实体集所联系，而不是和关系集。举个例子，让我们明确，指导者是一个一对多的关系集比如一个教师可能指导多个学生，但是一个学生只能被一个仅有的教师所指导。在这个例子中，明确了这个教师成为一个学生的指导者特定日期属性可以和学生实体集所联系。（为了保持这张图的简洁，实体集只有一部分属性被展现出来。）因为每个学生实体参与一个至少一个教师实例的关系中，是得这个属性有着和可以把这个特定日期放置在指导者一样的意义。一对多关系集的属性可以可以重新定位到只有实体集的“关系多”的一面。在另一方面，至于一对一关系属性，这个关系属性可以和其他所参与的实体之一所联系。设计决策的地方描述属性，在这种情况下，作为一种关系或实体属性。应该被考虑为企业被塑造的特征。设计者可以选择保留日期作为顾问来表达明确的日期是指通知关系而不是其他学生的大学地位属性。（例如，大学录取日期）

  属性安置的选择对于多对多的关系集是更加明确的。回到我们例子中，让我们明确了更多的真实案例如指导教授是一个多对多的关系集，一个教师可以指导一个或多个学生，并且一个学生可能被一个或多个教师指导。如果我们是要表达一个明确的教师成为了一个明确的学生的指导者的日期，日期一定是这个教师关系集的一个属性，而不是同时存在于所参加的实体中。例如，如果这个日期是学生的一个属性，我们在特定的日期中不能确定哪个教师是指导者。当属性由参与实体集的组合确定时，而不是两个实体分开，那个属性必须域这个多对多关系集联系。图7.3描述了日期作为关系属性的位置。再一次，为了保持这张图的简洁，实体集只有一部分属性被展现出来。

Abraham, Silberschatz. DATABASE SYSTEMCONCEPTS[M]. American: Abraham Silberschatz / Henry F. Korth / S. Sudarshan ,2010. 290-295