实体-联系模型

实体-联系（Entity-Relationship， E-R）模型(以下简称E-R模型)的提出旨在方便数据库的设计，它是通过允许定义代表数据全局逻辑结构的企业模式实现的。
E-R模型采用三个基本概念：实体集、联系集和属性。

实体集

实体（entity）是现实世界中可区别于所有其他对象的一个“事物”或“对象”。（与面向对象的类含义类似）实体集是相同类型即具有相同性质（或属性）的一个实体集合。在建模汇中，我们通常抽象地使用术语“实体集”，而不是指某个个别实体的特别集合。
实体集不必互不相交。如可以定义大学里所有人的实体集（person）。一个person实体可以是teacher实体，也可以是student实体，可以既是teacher实体又是student实体，也可以都不是。
实体通过一组属性（attribute）来表示。属性是实体集中每个成员所拥有的描述性性质。且每个属性都有一个值。

弱实体集

没有足够的属性以形成主码的实体集称为弱实体集（weak entity set）。有主码的实体集称作强实体集（strong entity set）。弱实体集必须与另一个称作标识（identitying）或属主实体集的实体集关联才能有意义。也就是说，弱实体集的存在依赖于标识实体集。将弱实体集与其标识实体集相连的联系称为标识性联系。
标识性联系是从弱实体集到标识实体集多对一的，并且弱实体集在联系中的参与是全部的。
虽然弱实体集没有主码，但仍需要区分依赖于特定强实体集的弱实体集中实体的方法。弱实体集的分辨符是使得我们进行这种区分的属性集合。弱实体集的分辨符也称为该实体集的部分码。
弱实体的主码由标志实体集的主码加上该弱实体集的分辨符构成。

联系集

联系（relationship）是指多个实体间的相互关联。联系集是相同类型联系的集合。
联系集也可以具有描述性属性（descriptive attribute）。如果teacher实体集与student实体集的联系集advisor。可以将属性date与该联系集联系起来，以表示教师成为学生的老师的日期。
数据库中的大部分联系集都是二元的。然而，有时联系集会涉及多于两个实体集。参与联系集的实体集的数目称为联系集的度（degree）。二元联系集的度为2，三元联系集的度为3，以此类推。

非二元的联系集

对于非二元联系集，为了避免混淆，只允许在一个联系集外有一个箭头。（如果有多个箭头，则无法表明对应的哪个实体）。而函数依赖可以以一种不会混淆的方式描述实体间的联系。

属性

每个属性都有一个可取值的集合，称为该属性的域（domain），或者值集（value set）。 严格来说，实体集的属性是将实体集映射到域的函数。由于一个实体集可能有多个属性，因此每个实体可以用一组（属性，数据值）对来表示，实体集的每个属性对应一个这样的对。
E-R模型中的属性可以按照如下的属性类型来划分：

• 简单（simple）和复合（composite）属性。简单属性不能划分为更小的部分。复合属性可以再划分为更小的部分。 复合属性帮助我们把相关属性聚集起来，使模型更清晰。注意，复合属性可以是有层次的。如address可以包含street、city、state等，而street可以进一步分解为street_number、street_name、apartment_number。
• 单值（single-valued）和多值（multi-valued）属性。一般情况下，一个属性对应一个值，这样的属性称为单值属性。如stuent_ID属性只对应于一个学生ID。而在某些情况下对某个特定实体而言，一个属性可能对应于一组值。以phone_number为例，每个教师可以有零个、一个或多个电话号码。这样的属性称为多值属性。为了表示一个多值属性，用花括号将属性名包住；如{phone_number}。
• 派生（derived属性）。派生属性的值可以从别的相关属性或实体派生（计算）出来。如age属性表示年龄，如果还具有属性date_of_birth，就可以从当前的日期和date_of_birth计算出age。派生属性的值不存储，而是在需要时计算出来。
  当实体在某个属性上没有值时，使用空（null）值。空值可以表示“不适用”，即该实体的这个属性不存在值。空还可以用来表示属性值未知。未知的值可能是缺失的（值不存在），或不知道的（不知道该值是否确实存在）。

删除冗余属性

一个好的实体-联系设计不包含冗余的属性。但是在实际开发中，实现这一点需要极大的代价。

约束

可以定义一些数据库中的数据必须要满足的约束。

映射基数(Mapping Cardinality)

映射基数表示一个实体通过一个联系集能关联的实体的个数。对于实体集A和B之间的二元联系集R来说，映射基数必然是以下情况之一：
一对一（one-to-one）：A中的一个实体至多与B中的一个实体相关联，并且B中的一个实体也至多与A中的一个实体相关联。
一对多（one-to-many）：A中的一个实体可以与B中的任意数目（零个或多个）实体相关联，而B中的一个实体至多与A中的一个实体相关联。
多对一（many-to-one）：A中的一个实体至多与B中的一个实体相关联，而B中的一个实体可以与A中的任意数目（零个或多个）的实体相关联。
多对多（many-to-many)：A中的一个实体可以与B中的任意数目（零个或多个）实体相关联，，并且B中的一个实体也可以与A中的任意数目（零个或多个）的实体相关联。
注意，考虑映射关系时，一定要同时考虑A->B和B->A两个方面，而不能只考虑其中一方面而忽略另一方面，从而导致错误的设计。

参与约束

如果实体集E中的每个实体都参与到联系集R的至少一个联系中，那么实体集E在联系集R中的参与称为全部的。如果实体集E中只有部分参与到联系集R中，那么实体集E在联系集R中的参与称为部分的。如我们期望每个student实体通过advisor联系同至少一名教师相联系，因此student在联系集advisor中的参与是全部的。相反地，一个teacher不是必须要指导一个学生。因此，很可能只有一部分teacher实体通过advisor联系同student相关联，于是teacher在advisor中的参与是部分的。

码

我们必须有一个区分给定实体集中实体的方法。从概念上来说，各个实体是互异的；但从数据库的观点来看，它们的区别必须通过其属性表明。实体的码是一个足以区分每个实体属性集。关系模式中的超码、候选码、主码的概念同样适用于实体集。
码同样可以唯一标识联系，并从而将联系相互区分开来。联系集的主码结构依赖于联系集的映射基数。如果联系集是多对多的，那么联系集的主码由两个实体集的主码的并集构成。如果联系是多对一的，那么多的实体的主码就是联系集的主码。如果联系集是一对一的，那么两个实体的任一主码就是联系集的主码。

E-R数据模式转换为关系模式

E-R模型和关系数据库模型都是现实世界企业抽象的逻辑表示。由于两种模型采用类似的设计原则，因此可将E-R设计转换为关系设计。

具有简单属性的强实体集的表示

设E是只具有简单描述性属性a1，a2，…，an的强实体集。我们用具有n个不同属性的模式E来表示这个实体集。对于从强实体集转换而来的模式，强实体集的主码就是生成的模式的主码。

具有复杂属性的强实体集的表示

当一个强实体集具有非简单属性时，可以通过为每个子属性创建一个单独的属性来处理复合属性，而不为复合属性自身创建一个单独的属性。
多值属性的处理不同于其他属性。对于一个多值属性M，构建关系模式R，该模式包含一个对应于M的属性A，以及对应于M所在的实体集或联系集的主码的属性。另外，在多值属性构建的关系模式上建立外码约束，由实体集的主码所生成的属性去参照实体集所生成的关系。
派生属性并不在关系数据模型中显式地表达出来。

弱实体集的表示

设A是具有属性a1，a2，…，an的弱实体集，设B是A所依赖的强实体集，设B的主码包括b1，b2，…，bn。
对于从弱实体集转换而来的模式，该模式的主码由其所依赖的强实体集的主码与弱实体集的分辨符组合而成。除了创建主码之外，还要在关系A上建立外码约束，该约束指明属性b1，b2，…，bn参照关系B的主码。外码约束保证表示弱实体的每个元组都有一个表示相应强实体的元组与之对应。

联系集的表示

设R是联系集，设a1，a2，…，an表示所有参与R的实体集的主码的并集构成的属性集合，设R的描述性属性（如果有）为b1，b2，…，bn。映射基数不同，主码的选择方式不同：

• 对于多对多的二元联系集，参与实体集的主码属性的并集成为主码。
• 对于一对多的二元联系集，任何一个实体集的主码都可以选作主码。这个选择是任意的。
• 对于多对一或一对多的二元联系集，联系集中多的那一方的实体集的主码构成主码。
• 对于边上没有箭头的n元联系集，所有参与实体集的主码属性的并集构成主码。
• 对于边上有一个箭头的n元联系集，不在"箭头"侧的实体集的主码属性为模式的主码。
  此外，还需在关系模式R上建立外键约束。

模式的冗余

连接弱实体集和相应强实体集的联系集比较特殊。弱实体集的主码包含强实体集的主码。连接弱实体集与其所依赖强实体集的联系集的模式是冗余的，而且在基于E-R图的关系数据库设计不必给出。

模式的合并

在一对一的联系的情况下，联系集的关系模式可以跟参与联系的任何一个实体集的模式进行合并。即使参与是部分的，也可以通过空值来进行模式的合并。
最后，还需考虑表示联系集的模式上本应有的外码约束。参照每一个参与联系集的实体集的外码约束本应存在。我们舍弃了参照联系集模式所合并入的实体集模式的约束，然后将另一个外码约束加到合并的模式中。

实体-联系设计问题

在实体-联系数据库模式中涉及到一些基本问题。

用实体集还是用属性

什么构成属性？什么构成实体集？对这两个问题并不能简单地回答。区分它们主要依赖于被建模的现实世界的企业结构，以及被讨论的属性的相关语义。
一个常见的错误是用一个实体集的主码作为另一个实体集的属性，而不是用联系。例如，即使每名教师指指导一名学生，将student的ID作为teacher的属性也是不正确的。用advisor联系代表学生和教师之间的关联才是正确的方法，因为这样可以明确表示出两者之间的关系而不是将这种关系隐含在属性中。
另一个常见的错误是将相关实体集主码属性为联系集的属性。这种做法是不对的，因为在联系集中已隐含这些主码属性。（这些属性默认已经在联系集中，不应再明确表示出来）

用实体集还是联系集

一个对象最好被表述为实体集还是联系集并不总是显而易见。在决定用实体集还是联系集可采用一个原则是，当描述发生在实体间的行为时采用联系集。这一方法在决定是否将某些属性表示为联系可能更适合时也很有用。

二元还是n元联系集

数据库中的联系通常都是二元的。一些看来非二元的联系实际上可以用多个二元联系更好地表示。事实上，一个非二元的（n元，n>2）联系集总可以用一组不同的二元联系集来替代。可以将这一过程直接推广到n元联系集的情况。因此在概念上可以限制E-R模型只包含二元联系集。然而，这种限制并不总是令人满意的。

• 对于为表示联系集而创建的实体集，可能不得不为其创建一个标识属性。该标识属性和额外所需的那些联系集增加了设计的复杂度以及对总的存储空间的需求。
• n元联系集可以更清晰地表示几个实体集参与单个联系集。
• 有可能无法将三元联系上的约束转变为二元联系上的约束。例如，考虑一个约束，表明R是从A、B到C多对一的；也就是，来自A和B的每一对实体最多与一个C实体关联。这种约束就不能用联系集Ra、Rb和Rc上的基数约束表示。

联系集中属性的布局

一个联系的映射基数比率会影响联系集中属性的布局。因此，一对一或一对多联系集的属性可以放到一个参与该联系的实体集中，而不是放到联系集中。一对多联系集的属性仅可以重置到参与联系的“多”方的实体集中。而对于一对一的联系集，联系的属性可以放到任意一个参与联系的实体中。
设计时将描述性属性作为联系集的属性还是实体集的属性这一决定反映出被建模企业的特点。
属性位置的选择在多对多的联系集中体现得更清楚。同名的属性，放在实体集中还是联系集中其作用不同。

扩展的E-R特性

虽然基本的E-R概念足以对大多数数据库特征建模，但数据库的某些方面可以通过基本E-R模型作某些扩展来更恰当地表达。

特化(Specialization)

在实体集内部进行分组的过程称为特化。一个实体集可以根据多个可区分的特征进行特化。在E-R图中，特化用从特化实体指向另一个实体的空心箭头来表示。所以，这种关系也称为ISA关系。特化关系还可能形成超类-子类(superclass-subclass)联系。

概化(Generalization)

实体的共性可以通过概化来表达，概化是高层实体集与一个或多个低层实体集间的包含关系。对于所有实际应用来说，概化只不过是特化的逆过程。为企业设计E-R模型时，将配合使用这两个过程。

聚集(Aggregation)

聚集是一种抽象，通过这种抽象，联系被视为高层实体。
当把聚集像其他实体集一样看待时，之前用于在联系集上创建主码和外码约束的规则，也同样可以应用于与聚集相关联的联系集。聚集的主码是定义该聚集的联系集的主码。不需要单独的关系来表示聚集；而使用从定义该聚集的联系创建出来的关系即可。

数据库设计的其他方面

数据约束和关系数据库设计

使用SQL可以表达多种数据约束，包括主码约束、外码约束、check约束、断言和触发器。约束有多种目的。最明显的一个目的是自动的一致性保持。通过在SQL数据定义语言中表达约束，设计者能够确保数据库系统自己执行这些约束（显式声明约束）。
显式声明约束的另一个优点是一些约束在数据库模式的设计中特别有用。
数据约束在确定数据的物理结构时同样有用，可以将彼此紧密相关的数据存储在磁盘上邻近的区域，以便在磁盘访问时提高效率。如将索引建立在主码上，索引结构工作得更好。
每次数据库更新时，执行约束会在性能上带来潜在的高代价。对于每次更新，系统都必须检查所有的约束，然后要么拒绝与约束冲突的更新，要么运行相应的触发器。性能损失的严重性，不仅仅取决于更新的频率，而且依赖于数据库的设计方式。

使用需求：查询、性能

数据库系统的性能时绝大多数企业信息系统的一个关键因素。性能不仅与计算能力的有效利用以及所使用的存储硬件有关，而且受到与系统交互的人的效率以及依赖数据库数据的处理的效率的影响。以下是效率的两个主要度量方法：

• 吞吐量（throughput）————每单位时间里能够处理的查询或更新（通常指事务）的平均数量。
• 响应时间(response time)————单个事务从开始到结束所需的平均时间或最长时间。

授权需求

授权约束同样会影响数据库的设计，因为SQL允许在数据库逻辑设计组件的基础上将访问权限授予用户。（现有主流数据库系统均已合理实现授权（基于角色分配））

数据流、工作流

术语工作流表示一个流程中的数据和任务的组合。当工作流在用户间移动以及用户执行他们在工作流中的任务时，工作流会与数据库系统交互。

数据库设计的其他问题

数据库设计通常不是一个一蹴而就的工作。一个组织的需求不断发展，它所需要存储的数据也会相应地发展。但是，对于一个已明确的需求，还是可以给出稳定的设计的。
一个好的设计应该不止考虑当前的规定，还应该避免或者最小化由预计或有可能发生的改变而带来的改动。（需要做向上兼容的思考）
最后，数据库设计在两个意义上是面向人的工作：系统的最终用户是人（使用该程序的用户）；数据库设计者需与应用领域的专家进行广泛交互以理解应用的数据需求。所有涉及数据的人都有需要和偏好，为了数据库设计和部署在企业中获得成功，这些都是需要考虑的。

参考

数据库系统概念(第六版) A. Silberschatz H. F. Korth S. Sudarshan著 杨冬青 等译 第七章