《Database.System.Concepts》的7.7Entity-Relationship Design Issues
7.7实体关系设计问题
实体集和关系集的概念是不明确的，并且定义一组实体用许多不同方式以及在其中的关系是有可能的。在这节中，我们研究E-R数据库模式设计中的基本问题。在7.10节中进一步详细介绍了设计过程。
7.7.1实体集相对属性的使用
考虑使用附加属性电话号码的实体集讲师（图7.17a)它可以很简单被认为一个电话它自己本身是一个实体，具有属性电话号码和位置，这个位置可能在电话安装的办公室或者家里，并且移动电话可能用mobile的值来代表。如果从这个角度出发，我们不会添加属性电话号码到讲师的表，我们创造：
·一个电话实体集带有属性电话号码和位置
·一个学院电话的关系集，和讲师之间关联的电话的表示
这个备选方案将显示在图7.17b.
那么，这两个定义之间的主要不同是什么，把一个手机看作属性电话号码表示讲师有一个明确的电话号码，把一个手机看作一个实体电话允许讲师有与他自己相关的几个电话号码（包括零）但是，我们可以将电话号码看作一个有大量属性以便允许每个讲师使用多个电话。
之后，这主要的区别在于把手机看作一个实体来更好模拟这样的情况，可能有一个人想要保存手机额外信息的地方，例如它的位置，或者它的类型（移动电话，IP电话，或者普通旧电话），或者所有共享的手机的人。因此，把手机看作一个实体是更普遍相比于将它看作一个属性并且这是合适的当这个通用性有用时。
相反，这是不合适的把它的属性姓名（一个讲师的）作为一个实体；这是很难去争议名字本身是一个实体（与手机相反）。因此这是很合适的将名字看作讲师实体集的属性。
两个自然的问题因此提出，什么构成一个属性？和什么构成一个实体集？不幸的是，没有很简单就得到的答案。这些差异主要取决于被建模的现实世界企业的结构，和在问题中提到与属性有关的语义。
一个普遍的错误对于使用，一个实体集的主键作为另一个实体集的属性，取代使用关系，例如，这是不正确的建一个学生ID的模来作为一个讲师的属性，即使每个讲师教导只有一个学生。这个关系建议者是正确的方式代表学生和讲师之间的联系。因此它使他们的联系明确，而不是一个隐式的属性。
另一个相关的错误是人们有时犯得就是将相关实体集的主键属性作为关系集的属性。例如，ID（学生的主键属性）和ID（讲师的主键）不应该显示为关系建议者的属性。这不应该被做因为主键属性已经隐含在关系集中。
7.7.2实体集相对关系集的使用
这不是总是清楚是否一个对象最好是用实体集还是一个关系集来表达。在图7.15，我们使用了采取关系集来建模学生在哪里上课（某一节）的情况。一个办法是想象有一个课程登记记录了每一个同学上的每一门课。之后，我们有一个实体集来代表这个课程登记记录。让我们叫这个伟实体集注册，每个实体注册都与一个实际的学生和一个实际的部分有关，所以我们有两个关系集，一个将课程登记记录与学生相关，一个将课程登记记录与部门有关。在图7.18，我们展示实体集和学生来自图7.15并且将关系集取代为一个实体集和两个关系集：
·注册，实体集代替课程登记记录。
·选节部分，与注册和课程相关的关系集。
·学生部分，与注册和学生相关的关系集。
请注意，我们使用双线来表示注册实体的总参与情况。
图7.15和图7.18的方法都准确的代表了大学的信息，但是take的使用更简洁，可能也更好，但是，如果注册者的办公室将其他的信息与一个课程登记记录结合起来，这可能会是最好的去使一个实体集独立。
指导方针在决定是否去用一个实体集或是一个关系集来指定一个关系集去描述一作用发生在实体之间。这个方法也可以有用的在决定是否某些属性更恰当的表达作为关系来说。
7.7.3二进制的与n元关系集
数据库中的关系集通常是二进制的，一些关系看起来不是二进制的实际上可以更好的用二进制的关系来表示。例如，可以创造一个三元关系的父母，把一个孩子和它的妈妈和爸爸联系起来，但是像这样的一种关系可以爸爸妈妈两种二元关系来表示，把孩子分别交给他的妈妈和爸爸，用爸爸和妈妈两种二元关系来表示。把孩子交给爸爸和妈妈，用这两种关系妈妈和爸爸来提供我们孩子妈妈的记录，即使我们不知道孩子爸爸的身份；一个空值将会被询问如果三元关系父母被使用，用二元关系集是更好的在这个事件中。
实际上，这总是可能的用许多二进制关系集来取代非二进制（n元，n>2）关系集，简单来说，考虑抽象三元（n=3）关系集R，与实体集A、B、和C有关，我们用实体集E代替关系集R并创造三个关系集，在图7.19：
·Ra，E与A相关。
·Rb，E与B相关。
·Rc，E与C相关。
如果关系集R具有任何属性，将被分配至实体集；此外，由于E创造了一个特殊的标识（因为它必须区分实体在根据属性值设置的实体中）在关系集R中的每一种关系，在实体集E中我们创造一个新的实体ei，接着，在这三个新的关系集中，我们插入如下关系：(ei,ai) 在RA内 (ei,bi) 在RB中. • (ei,ci) 在RC中。
我们可以通过一个简单的方式—n元关系集来实现这一过程。因此，概念地说，我们可以限制E-R模型只包括双重的关系集。然而，这种局限并不是经常可取的。
一个实体集必须创建一个象征关系的标识属性。这个属性，和对于关系集额外的要求，增加了设计的复杂性和（如我们将在第76部分看到的）总体的存储要求。
多个元参与单一关系的一个n元关系集将更加清晰。
这可能不是一种将三元关系约束转换为二元关系约束的方法。例如，考虑一个约束称R在A，B到C中是多对一的;就是说，每对来自A和B的实体最多有一个与实体C相连。这一约束不能用关系集上的RA,RB和RC的约束基数表达。
考虑7.22上关系指南上相关的讲师，学生和项目。我们不能很明确的划分讲师与项目和讲师与学生之间的关系。如果我们那样做了，我们能够记录Katz讲师对于学生Shankarh和学生Zhang的工作在A和B表中；然而，我们不能记录Katz对在表A中学生Shankar的工程项目和在表B中学生Zhang的工程项目，但是不在项目A中与Zhang工作或在项目B中与Shankar工作。
建立关系和指导可以分为二元关系创造一个如上的新实体集。然而，这么做不是特别自然。
7.7.4 关系属性的放置
一段关系的基数比的影响可以影响关系属性的放置，因此，一对一或一对多的属性可以是与实体集相关联，而不是与关系集合相关联。例如，我们可以指定一个一对多的关系，这样一个老师可以建议多个学生，但是每个学生仅能被单一的一个老师建议。在这种情况下，当讲师成为建议这是属性日期可以与学生实体集联系，像7.20所描述的一样。（为了使图表简单，只显示了两个实体集的一些属性）因为每个学生的实体最涉及一个讲师的关系，让日期和顾问关系集有相同的属性。一对多的关系集属性只可以在多面关系实体中保存。对于一对一的关系集，在另一方面，这些关系约束可以与其它参与实体结合。
这种情况下作为可以反映企业模式关系或实体属性的设计决策放在哪里。设计者可以选择日期作为一个属性去明确的表达通告关系并且不是其他方面学生的大学状态（例如，大学的录取日期）
这个属性放置对于其他多对多的关系集更为明确。回到我们的例子让我们指出更现实的案，劝告者可能是多对多的关系集去表达一个教师可能建议一个或多个学生，并且一个学生可能被多个教师建议。如果我们要表达一个指定的教师成为指定学生的建议者的日期，日期必须是顾问关系集的一个属性，而不是其他的参与的实体之一。如果日期是一个学生的一个属性，例如，我们不能确定某个讲师成为建议这的特定日期。当一个属性被参加者的关系实体集所确定，而不是被其它实体分开，那个属性一定被多对多的关系集关联。表7.3将描述日期放置位置作为一个关系属性；再次，保存表的简单性，只有一些双关集合的属性被显示出。
E-R图的拓展
虽然基本的数据库观念有大概的模型，但数据库的一些方面通过基本E-R模型的延伸会更加确切的表达。在者部分，我们讨论E-R数据模型专门的拓展，普通化，高水平和低水平的实体集，属性的继承和集结。
为了帮助讨论，我们将会用一种简单的更详尽的大学数据库表说明。另外，我们将会区分多种实体集在大学中通过区别人咋额个实体集，通过属性ID，名字，和地址。
专业化
一个实体集某种程度上可以包含来自集合中的其它实体。例如，一个实体集中的子集可能不共享与所有实体集中集合的属性。E-R模型提供了区分这些实体集组的办法。
举个例子，实体集人可以跟进一步区分为以下：
员工
学生
这些人的类型被一组属性描述，这包含在人这个实体集和可能附加的属性。例如，实体员工可以通过工资属性进一步描述，实体学生可以通过成绩进一步描述。实体集中这些小哦组设计过程称作专业化。这些专业化的人允许我们根据他们是否符合员工或学生去区分：一般来说，一个人可能是一个员工，一个学生，或其它。