《Database.System.Concepts》的7.7 Entity-Relationship Design Issues（P290~295）

7.7实体-联系设计问题

实体集与关系集的概念是不明确的，同时可能有很多种方法来阐释这两者之间的联系。在这一部分中，我们讨论了在设计一个E-R数据库示意图中的基本问题。7.10章节包括了设计过程中更多的细节。

7.7.1选择使用实体集或属性

考虑到具有新增的phone_number属性（图7.17）的实体集。这很容易表明phone是一个具有phone_number和location属性的实体；地点可以是家庭或者办公室，移动电话可以用值“value”来表示。如果我们采纳这样的观点，那么我们可以不把phone_number属性加给instructor，而是可以创建：

 -具有phone_number和location属性的实体集phone.

-表示教师与他们电话之间关系的联系集.

这种选择方法可见与图7.17b

  那么，教师的两个属性的主要区别是什么？把手机号码换成phone_number属性来暗示教师一个教师对应一个号码.把手机号码看成一个实体phone，允许一个教师与多个手机号码有关联。然而我们也可以将phone_number定义为一个拥有多个值的属性，从而允许教师有多个号码。

所以，主要差别就在于，当一个人想要保存更多关于手机号码的信息（手机号码，手机ip，老版手机）或者分享了电话的所有人时，将电话号码看成一个实体比将它看成一个属性更加普用，那么当普用性更需要时，这种方法就更实用了。

相反，将属性名（教师）作为一个实体来对待是不合适的，很难证明name本身就是一个实体。（与电话相反）。因此，更好的方法是将name看做实体集instructor的一个属性。

由此自然地产生了两个问题：什么构成属性，什么构成实体集？不幸的是，这没有简单的答案。这些区别主要取决于真实世界企业的结构模型，以及关于与该属性相关联的语义。

一个常见的错误是将一个实体集的主码用作另一个实体集的属性，而不是联系。例如，如果每个教员只建议一个学生，将学生的ID作为教师的属性进行建模是错误的。用advisor作为学生与教师之间的联系才是正确的，因为这样才能准确地表明两者之间的关系而不是将这种关系隐藏在属性中。

  常犯的另一个错误是将相关的实体集的主码属性作为联系集的属性。例如，student与instructor的主码属性id不应该在advisor联系中作为属性。这样是错误的，因为联系集中已经包含了这些主码属性。

7.7.2用实体集还是用联系集

  一个对象用实体集还是联系集来表达是不容易判断的。如图7-15所示，我们用takes联系集对学生选择课程建模。或者假设每个学生与每门课程都有一个课程-注册记录。那么，可以用一个叫做registration的实体集代表课程-注册记录。那么，我们用一个叫作的实体集代表课程-注册记录。每个实体恰 好与一个学生和一次开课相关联，因此我们有两个联系集，一个将课程-注册记录和学生关联，另一 个将课程-注册记录和课程关联。如图7-18所示，我们将图7-15中section和student实体集之间的 takes联系集用一个实体集和两个联系集替代：

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

-section_reg,关联 registration和course 的联系集。

-student_reg,关联 registration和 student 的联系集。
注意，我们使用双线表示registration实体全部参与。
图7-15和图7-18的方法都准确表达了大学的信息，但是使用takes的方法更紧凑也更可取。然而，如果注册办公室通过课程-注册记录与其他信息相关联，那么最好让它本身为一个实体。
在决定用实体集还是联系集时可采用的一个原则是，当描述发生在实体间的行为时采用联系集。 这一方法在决定是否将某些属性表示为联系可能更适合时也很有用。
  我们以后会看到，当从E-R模式中创建关系模式时，这些属性可能会出现在从联系集创建出的模式中, 但是，它们并不应该出现在联系集中。
7. 7.3二元还是n元联系集
数据库中的联系通常都是二元的。一些看来非二元的联系实际上可以用多个二元联系更好地表示。
例如，可以创建一个三元联系parent，将一个孩子与他/她的母亲和父亲相关联。然而，这一联系也可以用两个二元联系分别来表示，即mother和father，分别将孩子与他/她的母亲和父亲相关联。使用 mother和father两个联系使我们可以记录孩子的母亲，即使我们不知道父亲是谁；而对于这种情况三元 联系parent中必须有一个空值。所以在这个例子中用二元联系更好。
事实上，一个非二元的（n元，n>2）联系集总可以用一组不同的二元联系集来替代。简单起见，考虑一个抽象的三元（n =3）联系集R，它将实体集A，B和C联系起来。用实体集E替代联系集R,并 创建三个联系集，如图7-19所示：

-RA，关联E和A

-RB，关联E和B.

-RC，关联E和C
如果联系集R有属性，那么将这些属性赋给实体集E,进一步，为E创建一个特殊的标识属性（因 为它必须能够通过其属性值来区别实体集中的各个实体）。针对联系集R中的每个联系（ai,bi,ci）， 在实体集E中创建一个新的实体ei。然后，在三个新联系集中，分别插人新联系如下：

在RA中插入（ei,ai）

在RB中插入（ei,bi )

在RC中插入（ei,ci）。

可以将这一过程直接推广到n元联系集的情况。因此，在概念上可以限制E-R模型只包含二元联系集。然而，这种限制并不总是令人满意的。
-对于为表示联系集而创建的实体集，我们可能不得不为其创建一个标识属性。该标识属性和额 外所需的那些联系集增加了设计的复杂程度以及对总的存储空间的需求（我们将在7.6节看到 这一点）。
-n元联系集可以更清晰地表示几个实体集参与单个联系集。
-有可能无法将三元联系上的约束转变为二元联系上的约束。例如，考虑一个约束，表明A是从 A, B到C多对一的；也就是，来自A和B的每一对实体最多与一个C实体关联。这种约束就 不能用联系集札、札和上的基数约束来表示。
考虑7. 2. 2节中的联系集proj_guide,它关联instructor，student和project。不能直接将proj_guide拆分为instructor和project之间的二元联系和student和project之间的二元联系。如果这么做，可以记录教师Katz同学生Shankar和Zhang 一起参与项目A和B;然而无法记录Katz同Shankar —起参与项目B并且同Zhang一起参与项目B，而不是同Zhang 一起参与项目A或者同Shankar —起参与项目B。
联系集pro_guide可以通过创建一个如上所述的新实体集来拆分为二元联系。然而，这么做却不是很自然。
7.7.4联系属性的布局

   一个联系的映射基数比率会影响联系属性的布局。因此，一对一或一对多联系集的属性可以放到 —个参与该联系的实体集中，而不是放到联系集中。例如，我们指明advisor是一个一对多的联系集，也就是一个教师可以指导多个学生，但每个学生只能有一个导师。在这种情况下，表示教师何时成为学生导师的属性date可以与student实体集相关联，如图7-20所示.（为了保持图例简单，只显示了两 个实体集的部分属性.）由于每个student实体最多和一个instructor实例相关联，因此将属性date放在advisor联系集中具有相同的含义。一对多联系集的属性仅可以重置到参与联系的“多”方的实体集中。而对于一对一的联系集，联系的属性可以放到任意一个参与联系的 实体中。

   设计时将描述性属性作为联系集的属性还是实体集的属性这一决定应该反映出被建模企业的特点.设计者可以选择保留date作为advisor的属性，以显式地表明指导关系的日期，而不是学生校内状态的其他一些方面（例如,被大学录取的日期）。

   属性位置的选择在多对多联系集中体现得更清楚。回到刚才的例子，让我们指出可能更符合实际 的情况，定义advisor为一个多对多的联系集，表明一个教师可以指导一个或多个学生，而一个学生可 以被一个或多个教师指导。如果想要表示一个特定的教师成为一个特定学生的导师的日期，date则必须作为联系集advisor的属性，而不是任何一个参与的实体集的属性。例如，如果将date作为student的 属性，则我们无法知道哪个教师在该特定日期成为他的导师。当一个属性是由参与的实体集联合确定 而不是由单独的某个实体集确定时，该属性就必须放到多对多联系集中。图7-3给出了作为联系属性 时date位置。为了图例的简单，只显示了两个实体集的部分属性。