database system concept290-295

第七章  数据库设计和E-R模型

当学院计划被融合到教师中时，就添加了教师关系。

7.7 实体关系设计问题

    实体集和关系建立集的概念是不精确的，所以用许多种不同的方法去定义实体集和他们之间的关系是可能的。这一节我们讨论数据库设计中ER图的基本问题。7.10包括了未来设计进程的细节。

7.7.1 实体集属性的使用

作为带有附加属性电话号码的实体型。可以很容易地认为。手机本身就是一个手机号码和位置为属性实体型。位置可能是手机所在的办公室或家庭，手机可能代表了“移动”的价值。如果我们采用了这个观点，我们就不会向教师添加属性电话。相反，我们创建的是：

用属性电话号码和位置设置的电话实体。

一个电话关系集：表示教师之间和他们手机之间的联系。

这个选项如图717b所示

那么，这两个定义有什么主要的区别呢？把电话当做一个属性，就意味着一个教师有准确的电话号码，把电话当做实体，就意味着允许一个教师有多个电话号码。但是，我们可以轻松地将电话号码定义为一个多值属性，以允许每个教师使用多个电话。

主要区别在于，把手机当做一个更好的实体模型，在这种情况下，人们可能想要掌握手机的更多信息，比如它的位置或类型（移动手机，IP电话，或者普通的旧手机），或者所有的手机分享者。因此，将电话作为一个实体来对待，比把他作为一个属性来对待更普遍，并且在有可能通用时更合适。

由此自然产生了两个问题：什么构成了属性？什么构成了实体集？很遗憾，没有简单答案。这主要取决于建模的实际企业的结构，和所讨论的属性相关的语义。

一个常见的错误是将一个实体集的主键作为另一个实体集的属性，而不是使用关系。例如，将学生的ID建模作为教师的属性是不正确的，就算是每个教师只和一个学生有联系。关系是表示学生和教师之间联系的正确方法。因为这样可以使他们的连接显化，而不是通过潜在的属性。

另一个人们可能犯的相关错误是将相关实体集的主键属性指定为关系集的属性。例如，ID（学生的主键属性）和ID（教师的主键属性）不应该作为关系的属性出现。这是不应该做的，因为主键属性已经隐含在关系集中。

7.7.2实体集和关系集的使用

我们有时候不能判断一个对象使用实体集还是使用关系集来表达比较好。在7.15表格中，我们使用takes这个关系集去建立一个学生在哪里上课的情境。有一个可行选项是去想象有一个课程登记表来记录每一个学生所上的课。然后，我们就有一个实体集用于代表课程登记的记录了。那不妨将这个实体集称为“登记”。每个“登记”的子集与一个具体的学生、一个具体的课程相关联，所以我们就有了两个关系集，一个与学生的课程登记记录相关联，另一个与课程的登记记录相关联。在表格7.18表格中我们展示了从被一个实体集和两个关系集替代的take表格中得到的实体集“课程“和“学生“。：

  登记：代表课程登记记录的实体集。

  课程：与登记和课程相关联的实体集。

  学生：与学生登记记录县关联的实体集。

  表格7.15和表格7.18两种方式都精确的代表了大学的信息，但是使用take表格会更加简洁且美观。然而，如果记录者的办公软件将其他信息与课程登记记录联系到一起，这样会是让实体集效益最大化的方式。

  首先决定使用实体集去还是关系集去指明两个实体集集之间的关系是个可行的方向，这个方法同时对于决定属性是否要更多地使用关系集来表示一样可行。

 7.7.3 二进制与n元关系集

关系集在数据中通常是以二进制的形式，但是一些非二元关系集有时会比二元关系集来得更好。打个比方，可以创建一个三元的关系集“父母”，孩子与ta的父母相关联。但是，这么一个关系集也可以用两个二元关系集来表示“父亲”和“母亲”，一个孩子分别与ta的父亲和父亲相关联。使用两个关系集“父亲”和母亲提供给我们孩子母亲的信息，尽管我们不知道孩子父亲的信息，一个无效的值如果在三元关系集“父母”被使用的时候就会被要求取得正确值。使用二元关系集在这种情况下有更简好的效果。

  事实上，通常会讲一个多元关系集（n元，n>=2）替换为一定数量的二元关系集。简单来说，将一个抽象的三元关系集设定为R，与实体集A、B、C相关联。我们用实体集E将关系集R代替，然后创建三个关系集如表格7.19.

 如果关系集R具有某种属性，则将这些属性分配给实体集E;此外，还为E创建一个特殊的标识属性（因为必须能够根据其属性值区分实体集中的不同实体）。对于关系集R中的每个关系（ai，bi，ci），我们在实体集E中创建一个新的实体ei。然后，在这三个新的关系集中，我们插入如下关系:我们可以用直截了当的方法将这个过程推广到n元关系集，因此，在概念上，我们可以将E-R模型限制为只包含二进制关系的集合。然而这种限制并不总是可取。

为了表达这个关系集，我们可能不得不为这个实体集创建标识属性，该属性以及所需的额外关系集增加了设计的复杂性，以及（我们在第7.6节中看到的）总的储存需求。

一个n元关系集合更清楚地表明了，在一种单一的关系中，有多个实体参与。

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

考虑7.2.2节中关于讲师，学生和项目的关系集-指南。我们不能直接将指导分为导师与项目之间的二元关系，教师与学生之间的二元关系。如果我们这样做了，我们就能记录Katz老师与学生Shankar和Zhang一起从事A和B项目的工作;然而，我们不能记录Katz与学生Shankar一起从事A项目以及与学生Zhang一起进行B项目的工作，但却没有与Zhang一起从事A项目或Shankar一起B项目。

关系的基数比可以影响关系属性的放置。因此，一对一或一对多关系集的属性可以与参与实体集中的一个相关联，而不是与关系集相关联。例如，让我们指定顾问是一个一对多的关系集，这样一位教师可以建议几个学生，但每个学生只能由一位教师提供建议。在这种情况下，指定教师何时成为学生顾问的属性日期可以与学生实体集相关联，如图7.20所示。 （为了简化图形，仅显示两个实体集的一些属性。）由于每个学生实体最多只与一个教师实例有关系，因此使此属性指定与将日期与顾问关系集。一对多关系集的属性只能重新定位到关系“多”一侧的实体。另一方面，对于一对一的关系集，关系属性可以与任一参与实体相关联。
在这种情况下将描述性属性置于何处的设计决策（作为关系或实体属性）应反映正在建模的企业的特征。设计师可以选择保留日期作为顾问的属性，以明确表示日期是指建议关系，而不是学生大学地位的其他方面（例如大学录取日期）。

对于多对多关系集来说，属性布局的选择更为明确。回到我们的例子，让我们指定一个更现实的情况，即顾问是一个多对多的关系集，表示教师可以建议一个或多个学生，并且可以由一个或多个导师建议学生。如果我们要表示特定教师成为特定学生的顾问的日期，那么日期必须是顾问关系集的一个属性，而不是任何一个参与实体。例如，如果日期是学生的属性，那么我们就无法确定哪个教师在该特定日期成为顾问。当属性由参与实体集合的组合确定，而不是由任何实体单独确定时，该属性必须与多对多关系集合相关联。图7.3描述了日期作为关系属性的位置;再次，为了简化图形，仅显示两个实体集的一些属性。

 正如上面所描述的，通过创建一个新的实体集，可以将关系本身分割为二进制关系，但是这样并不是很自然 。

翻译自《database system concept》p290-295