翻译 《Database.System.Concepts》的7.7 Entity-Relationship Design Issues

7.7 E-R设计问题

实体集和关系集的概念是不精确的，而且可能会以许多不同的方式来阐述它们之间一系列的实体和联系。在本节中，我们探讨了E-R数据库模式设计中的基本问题。7.10小节涵盖了更详细的设计过程。

 

7.7.1 实体集与属性的使用

思考带有附加属性phone_number的实体集instructor(图7.17a)。可以说人们很容易认为电话本身就是一个带有属性phone_number和属性location的实体；电话所在的位置可能是办公室或者家里，移动手机（手机）可能代表着值“移动”。 如果我们以这个观点来看，就不能将属性phone_number 添加到实体集instructor。相反地，我们创建：

• 一个实体集phone有属性phone_number和location。

• 一个关系集inst_phone指出讲师和他们的手机之间的联系。

其他的内容在图7.17b中展示。

      那么，讲师的这两种定义的区别是什么呢？将电话作为一个属性来看，phone_number 表明每一个讲师都只有一个电话号码。将电话作为一个实体来看，phone允许讲师有许多(包括0)个与他们相关的电话号码。 但是，我们可以很容易地将phone_number定义为一个多值属性，允许每个教师使用多个电话。

    主要的区别是将电话作为一个实体能更好地建模起一种某个人可能想要保存一个电话的额外信息，例如它的位置，或者它的类型(移动电话、IP电话、或普通电话)，或者都有谁分享过这个电话的情况。因此，与将电话作为一个属性相比，将电话作为一个实体更加常用，并且在一般性可能有用的时候是更为适当的。

     相反的，将（讲师的）的属性name作为一个实体是不合适的；(与电话相比)很难说name本身就是一个实体 。 因此，将name作为实体集instructor的属性才是合适的。

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

    一个常见的问题是使用实体集的一个主键作为作为其他实体集的一个属性，而不是使用关系。例如，即使一个讲师只给一个学生提建议，但是将学生的ID建模成讲师的一个属性是不正确的。关系advisor是在学生和讲师之间建立连接的正确方法，因为它将他们之间的连接声明为显式，而不是通过属性声明为隐式。

    人们有时犯的另一个相关错误是将相关实体集的主键属性指定为关系集的属性。例如，( student的主键属性)ID和( instructor的主键)ID不应该作为关系advisor的属性出现。这是不可以的，因为主键属性已经隐含在关系集中。

 

7.7.2 实体集与关系集的使用

一个对象是否最好由实体集或关系集来表示，我们并不总是很清楚。在图7.15中，我们使用关系集takes来建模一个学生的上（一节）课的情况。另一种方法是假设每个学生上的每一节课都有课程登记记录，然后我们用一个实体集来表示课程登记记录，让我们称这个实体集为registration。每个实体registration都精确地与一个学生、一节课相关，所以我们有两个关系集，一个与学生们的课程登记记录相关，一个与各节课程的课程登记记录相关。在图7.18中，我们通过关系集takes被一个实体集和两个关系集所取代展示了图7.15的实体集section和实体集student：

• registration，代表课程登记记录的实体集。

• section_reg，关于课程登记和课程的关系集。

• student_reg，关于课程登记和学生的关系集。

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

    图7.15和图7.18的方法都准确地表达了大学的信息，但是关系集takes的使用更为简洁，或许会更为可取。然而，如果登记员办公室要将其他信息与课程登记记录联系起来，那最好是使它本身成为一个实体。

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

 

7.7.3二进制与n元关系集

数据库中的关系通常是二元的。一些好像非二元的关系事实上可以被几个二元关系更好地来表示。例如，可以创建一个三元的关系parent，关联一个孩子和他或她的母亲和父亲的关系。然而，这样一个关系也可以被两个二元的关系，mother和 father表示，关联一个孩子分别和他或她的母亲和父亲的两个关系。用两个关系mother和 father为我们提供一个这个孩子的母亲的记录，即使我们不知道父亲的身份；如果三元关系parent被使用，一个空值将是必须的。在这种情况下用二元关系集是更好的。

    事实上，总是可能用许多不同的二元关系集来替换一个非二元(n元，且n>2)关系集。为简单起见，考虑理论上的三元(n=3)关系集R，关联实体集A、B和C。我们用一个实体集Ｅ替代关系集Ｒ，并创建了图7.19所示的三个关系集：

• RA，关联E和A。

• Rb，关联E和B。

• RC，关联E和C。

如果关系集Ｒ有许多属性，这些被分配给实体集E；更多的是，一个特殊的标识符属性为Ｅ而创造（因为必须能够根据它们的属性值来区分一个实体集中的不同实体）。对于关系集Ｒ中的每个关系(ai,bi,ci)，我们在实体集Ｅ中创造一个新的实体ｅｉ。然后，在三个新的关系集中，我们插入一个关系如下：

•(ei,ai)在RA．

•(ei,bi)在RB．

•(ei,ci)在RC．

     我们可以以直截了当的方式归纳这个过程到多元关系集。因此，概念上，我们可以限制Ｅ－Ｒ模型只包括二元关系集。然而，这种限制不是可取的。

•一个标识符属性可能不得不为表示关系集而创建的实体集被创建。这个属性，在其他关系集中是必须的，增加设计的复杂性和(如我们将在第7.6节中所看到的)总的存储需求。

•一个n元的关系集合更清楚地显示出几个实体参与了一个单一的关系。

•这里可能没有办法将三元关系上的约束转换为二元关系上的约束。例如，考虑一个约束，即R是从A、B到C的多对一的约束；也就是说，来自A和B的每一对实体最多与一个Ｃ实体相关联。这种约束不能用关系集RA、RB和RC上的基数约束来表示。

    思考一下7.2.2节中的关系集proj－guide，instructor，student和project。我们不能直接将proj－guide分为在instructor和project，instructor和 student中的二元关系。如果我们这样做，我们将能记录讲师Katz和学生Shankar，Zhang在项目Ａ和Ｂ工作；然而，我们将不能记录讲师Katz 和学生Shankar在项目Ｂ中工作，和学生Zhang在项目Ｂ中工作，但不和学生Zhang在项目Ａ中工作或和学生Shankar在项目Ｂ中。

      关系集proj－guide能被分为二元关系通过创建如上所述的新实体集。然而，这样做是不太自然的。

 

7.7.4 关系属性的放置

关系的基数比率会影响关系属性的放置。因此，一对一或一对多关系集的属性可以与参与的实体集之一相关联，而不是与关系集关联。例如，我们明确指出，advisor是一对多的关系集，因此一位讲师可以建议几名学生，但每位学生只能由一名教师提供建议。在这种情况下，属性date指定当讲师成为一个学生的导师时可以与实体集student相关联，如图7.20所示。(为了保持图的简单性，只显示了两个实体集的一些属性。) 由于每个实体student最多与一个实例instructor有关系，因此，使该属性指定具有将date与关系集advisor放置在一起的相同含义。一对多关系集的属性可以重新定位到仅仅是关系的“多”侧的实体集。另一方面，对于一对一的关系集，关系属性可以与任何一个参与实体相关联。

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

    属性位置的选择对于多对多关系集更为明确。回到我们的例子，让我们具体说明一个可能更实际的情况，advisor是一个多对多关系集，表示一个讲师可以建议一个或多个学生，学生可以由一个或多个讲师建议。如果我们要表示日期，当一个明确的讲师成为一个明确的学生导师的日期，则date一定是关系集advisor的一个属性，而不是任何一个参与实体。如果date是student的一个属性，例如，我们无法确定在那个特定的日子里，哪个讲师成为了导师。当属性是由参与实体集的组合决定的，而不是由任一实体单独组合时，该属性必须与多对多关系集相关联。图7.3将date的放置作为一个关系属性；同样，为了保持图的简单性，只显示了两个实体集的一些属性。

来源：

《Database System Concepts》作者Abraham Silberschatz