DATABASE SYSTEM CONCEPTS

 1实体集合关系及的概念并不精确，这是可能的。以多种不同的方式定义一组实地以多种不同的方式定义一组实体和他们之间的关系和他们之间的关系。在本节中，我们将研究E_R，数据库模式设计中的基本问题，第七第七十节详细介绍了设计过程详细介绍了设计过程。   7.7.1，实体机遇与属性的使用。  考虑使用附加属性，电话号码的实体设计讲师。可以很容易的认为，电话是一个实体，他本身就，电话号码和地址的属性，该地点可能是电话所在的办公室或家庭，手机的价值是"移动"价值是。如果我们采用这个观点，我们就不会向，指导员添加电话号码的属性。相反我们可以创建。      .一个带有属性电话号码和位置的电话实体。      .一种inst_phone的关系。表示指导者和他们拥有电话之间的关系。     如图所示，那么，这两种定义之间的主要区别是什么呢？？把电话当做一个属性的电话号码，意味着教师们每个人都有一个电话号码，把手机当作实体电话来处理，可以让老师有几个电话号码，包括零。但是我们可以轻松的将电话号码，定义为一个多值属性，允许每个教师使用多个电话。主要的区别是，把手机当作一个实体来更好的模拟，一个人可能想要获得关于电话的额外信息的研究。作为她的位置或他的类型（手机，我的电话或者普通的旧电话），或所有能分享的电话。

2因此，将电话作为一个实体来对待，比把它单作一个属性来对待更普通，并且在通常时更有用的时候是合适的。

相反，将属性名（hstruct）视为实体是不合适的；很难说名字是一个实体，与手机形成了鲜明的对比。因此将名字作为指导实集的属性是合适的。

由此产生了两个自然问题；什么构成了属性，以及什么构成了实体集？不幸的是，没有简单的答案。区别主要依赖于建模的真实企业的结构，以及与所讨论的属性相关的语义。

一个常见的错误是使用实体集的主键是不正确的，即使每个指导员只建议一个学生。关系顾问是表示学生和教师之间联系的正确方法，因为它使他们的连接显示，而不是通过属性隐示。

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

3并不总是清楚对象是最好的用实体集还是关系集来表示。在图7.15中，我们使用了采取关系集来建模学生上(某一节)课程的情况。另一种方法是设想每个学生都有一个课程注册记录，然后，我们有一个实体来表示课程注册记录。让我们称之为实体集注册。每个注册实体都与一个学生和一个部分相关，因此我们有两个关系集，一个是将课程 注册记录与学生相关，另一个是将课程注册记录与部分联系起来。在图7.18中，我们展示了实体集部分和图7.15中的学习，将采取关系集替换为一个实体集和两个关系集：

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

·部分注册，与注册和课程相关的关系集。

·学生注册，与注册和学生相关的关系集。

请注意，我们使用双行线来表示注册实体的总参与情况。

 

4。。图7.18，取代注册和两个关系集。 图7.15和7.18，的方法都准确的代表了大学的信息，但是使用的方法更紧凑，可能更可取。然而，如果登记官办公室将其他信息与法庭登记记录联系在一起，最好把它作为一个实体。确定是否使用时，体积或关系及的一个可能的指导原则是，指定一种关系，即来描述实体之间的操作，这种方法也可以用于判断某些属性，是否可以更精确地表示为关系。

5数据库中的关系通常是2进制的，一些看似非二进制的关系实际上可以用一些二进制关系更好的表现出来。例如，一个人可以建立一个三元关系的父母，把一个孩子和他/她的母亲和父亲联系起来。然而，这样的关系也可以用两种二元关系来表示，父母和父亲分别是孩子和母亲的关系。使用父母双方的关系为我们提供了一个孩子母亲的记录，即使我们没有意识到父亲的身份，如果使用三元关系，则需要空值。在这种情况下使用二进制关系集更可取。

实际上，总是可以用许多不同的二进制关系集替换非二进制（n-ary,n-2)关系为ship。为简单起见，考虑抽象三元（n=3)关系集R，关联实体集A、B和C。我们用一个实体集合E替换关系集R，并创建三个关系集，如图7-19所示。

6.。我们可以用简单的方式将这个过程概括为n-ary关系的ship集合。因此，从概念上讲，我们可以将E-R模式限制为只包含二进制关系集。然而，这种限制并不是可取的。   .为创建的实体集必须创建一个标识属性。     表示关系集，增加了设计的复杂性（如我们所见 第7.6节）。 总体储存要求。   .N-ary关系集更清楚地展示了几个实体参与的一般关系。  可能没有办法将三种关系的约束转化为对二元关系的约束。举个例子，假设有一种说法认为R是多对一的，从B到C；也就是说，A和B中的每一种说法最多一个C实体关联。这个约束不能通过使用关系集RA上的基约束来表示。RB,Kc。

7在第7.2节中考虑关系集投影-euide，相关的讲师，学生和项目。我们不能直接把proj-guide瓜分解成教师和项目之间的二元关系，以及教师和学生之间的关系。如果我们这样做，我们可以录下，导师katz与学生shankar和zhang一起工作的项目A和B，但是，我们不能记录下卡齐与学生shankar一起在A项目上工作，和学生张一起工作，但是在项目A和项目B上没有合作。通过创建如上述的新实体集，可以将proj-guide分割为二进制关系。然而，这样做并不十分自然。

8关系的基数比会影响关系属性的放置。因此，一对一或一对多关系集的属性可以被关联到一个参与的实体集，而不是关系。例如，我们指定顾问是一对多的关系，一个教练可能建议几个学生，但可以建议每个学生只有一个老师。在这种情况下，属性日期指定何时讲师成为学生的顾问，可以与学生实体集合相关联，如图7.20所描述的。（为了保持图的简单，只显示了两个实体集的一些属性。）因为每个学生实体参与导师的关系最多一个实例，使这个属性名称有相同的意义与顾问公司将日期设置的关系。一对多关系的属性集只能重新定位，以实体集“许多”的关系。对于一对一，另一方面，关系属性可以与参与实体中的任何一个相关联。

在这种情况下，在何处放置描述性属性的设计决策作为一种关系或实体属性，应该反映出被建模的企业的特征。设计者可以选择保留日期作为顾问的属性，明确表示是指咨询关系，而不是学生大学地位的其他方面（例如，大学录取的日期）

9对于许多关系集来说，属性放置的选择更加明确。回到我们的实例，让我们指定可能更实际的。

如果导师是多对多关系，那么教师可以给一个或多个学生提供建议，而学生可以由一个或多个教师担任顾问。如果我们要表达某以特定教师成为某个学生的顾问的日期，那么日期必须是顾问的一个属性。

关系集，而不是参与其中的一个实体。例如，如果日期是学生的属性，我们无法确定哪位讲师在某一特定日期成为顾问。当一个属性由参与实体集的联合绑定确定，而不是单独的实体集合时，该属性必须与多对多关系集关联。图3.7，描述了日期作为关系属性的放置；同样，为了保持图的简单，只显示了两个实体集的一些属性。

10虽然基本的E-R概念可以建模大多数数据库特性，但是数据库的某些方面可以通过对基本E-R模型的某些扩展来更好地表达。在本节中，我们将讨论专门化 的扩展E-R特性、泛化、高级和低级实体集、属性继承和聚合。为了帮助讨论，我们将为大学使用一个稍微复杂一些的数据库模式。特别是，我们将通过定义一个具有属性ID、名称和地址的实体集Person来建模大学中的各种人。

 

实体集可以包括在某种程度上不同于集合中其他实体的实体的子组。例如，实体集中的实体子集可能具有实体集中的所有实体共享的属性。E-R模型为代表这些独特的实体分组提供了一种手段。例如，实体集Person可进一步归类为下列之一：

·员工

·学生

这些人员类型中的每一种都由一组属性描述，这些属性包括实体集Person的所有属性以及可能的附加属性。对于考试 ，员工实体可以用属性工资来进一步描述，而学生实体可以由属性totcred进一步描述。在实体集中指定子组的过程称为专门化。人员的spe 归一化允许我们根据人的实体是对应于员工还是学生来区分它们：一般来说，一个人可以是雇员，学生，两者都可以，或者两者都不是。

翻译自《DATABASE SYSTEM CONCEPTS》  Abraham Silberschatz   Henry F.Korth   S.Sudarshan