一篇搞懂数据库的ER模型设计
一篇搞懂数据库的ER模型设计
ER模型（Entity-Relationship Model）是一种流行的概念数据模型，用于数据库应用程序的设计。它将现实世界视为实体和实体之间关系的集合。本文将详细介绍ER模型中的实体、属性、关系、约束、类继承和聚合等概念，并通过大量示例和E-R图进行说明。
实体（Entity）
实体是现实世界中可与其他对象区分开来的对象，例如雇员、学生、教授、课程。实体集（Entity set）是该类实体的集合。在E-R图中用矩形表示。
雇员作为实体在E-R图中的表示
属性（Attribute）
一组属性可以用来描述一个实体，例如，一个雇员具有工号、姓名、地址、年龄、生日等属性。在E-R图中用椭圆表示，用无向边与其描述的实体集相连。
雇员的年龄属性在E-R中的表示
关键属性在E-R图中的表示（在关键属性下面添加一个下划线）
复合关键属性在E-R图中的表示（复合关键属性中的每一个属性都要标注下划线）
关系
定义：关系是两个或多个实体之间的关联。例如讲师与课程之间的关系就是 "教" 。
我们可以观察到，实体集 "讲师" 中可以有讲师与实体集 "课程" 中课程不产生"教"的关系
多个具有相同属性的实体组成实体集，而一组由实体间产生的关系也可以组成关系集。关系集在E-R图中用菱形表示。
度（degree）
定义：度（degree）描述参与到关系集的实体集个数。关系集包含两个实体集成为二元关系（binary relationship）。关系集包含超过两个实体集的比较少。
二元关系（Binary Relationship）
雇员可以在多个部门工作，反之亦然
关系还可以具有用于描述有关关系的记录信息的属性，而不是每个实体的信息。
关系必须由参与实体唯一标识，而不参考描述性属性
在前面的示例中，每个关系必须由雇员的 EmpID 和部门的 did 来唯一标识。因此，对于每一对 Employees-Departments 关系，我们不能有多个关联的 "Start_date" 值。
递归关系（Recursive Relationship）
关系的实体集可以是相同的。例如雇员中主管（supervisor）与下属（subordinate）的关系，主管与下属同属于雇员实体集，但他们之间又存在着 "汇报" 的关系。
在上述E-R图中，两条无向线标识了实体集中不同实体之间的关系
上述E-R图就不能表示递归关系
约束（Constraints）
E-R模型描述了要存储的数据和对数据的约束（Constraints）。二元关系的关联类型可以分为以下几种情况：
前面的讨论确定了两个方向的每种关系；也就是说，关系是双向的。
- 1-to-Many Relationship
A 中的实体与 B 中的任意数量（零个或多个）实体相关联。但是，B 中的实体最多可以与 A 中的一个实体相关联。
示例：每个孩子最多可以出现在一个母子关系中
一个母亲可以有多个孩子，但是一个孩子只能有一个母亲，类似于函数关系，一个自变量x只能对应一个因变量值y，而一个因变量y值可以由多个自变量x计算得到
孩子在母子关系集中有一个关键约束（key constraint），这个约束可以在E-R图中用箭头表示。
直观地，箭头指出，给定一个子实体，我们可以唯一地确定母体关系
- Many-to-1 Relationship
A 中的一个实体最多与 B 中的一个实体相关联。但是，实体 B 可以与 A 中任意数量（零个或多个）实体相关联。
示例：每个雇员最多可以出现在一个雇佣关系里。
一个雇员只在一个部门里工作，一个部门里可以有多个雇员
- One-to-One Relationship
如果 A 和 B 之间的关系满足从 A 到 B 的一对一映射约束，则A 中的一个实体最多与 B 中的一个实体相关，B 中的一个实体最多与 A 中的一个实体相关。
示例：雇员与部门的管理关系
员工最多通过管理关系与一个部门关联。一个部门最多与一个员工通过管理关系相关联
- Many-to-Many Relationship
A 中的实体与 B 中的任意数量的实体相关联。B 中的实体与 A 中的任意数量的实体相关联。事实上，这个映射没有任何限制。
示例：顾客与贷款的关系
顾客可以通过借款人关联多笔贷款（可能为 0）。贷款可以通过借款人与多个顾客（可能为 0）相关联
关系集的键（Keys for a Relationship set）
键的概念也用于标识关系，如实体。一组属性（参与构成关系的实体集属性）可以唯一标识关系集R。设 R 是涉及实体集 E1、E2、...、En的关系集。设 主键（primary-key）（Ei） 表示构成实体集 Ei 主键的属性集。属性集：
构成了关系集的超键（super key）。
二进制关系集的主键的选择取决于关系集的映射基数，也就是上述提到的关系约束类型。
1-to-Many和Many-to-1的关系， “Many” 一方的主键（primary key）是最小的超键（super key），用作主键。
从键的定义和逻辑关系来看，用键唯一标识一个关系，需要找到不确定中的确定，例如在母子关系中，如果选取母亲的主键作为关系集的主键，则无法确定一组关系，但如果选择 "Many" 一方也就是 "孩子" 方，每个孩子只有一个母亲，通过这个逻辑，可以唯一标识一组关系。
上图，母子关系可以用复合关键属性来标识，但这不是候选键，在这里，唯一标识母子关系集的最小属性集就是cid
在One-to-One关系中，任意一方的主键都可以构成关系集的主键。所以上图雇员与部门管理关系集的主键就是{EmpID}或{did}。
在Many-to-Many关系中，两方的主键的并集是最小的超键，被选为主键。
上图，Many-to-Many关系中，用于唯一标识关系集的最小的属性集是两方主键的并集
（最小的超键就是候选键（candidate key））
参与约束（Participation Constraint）
前面提到的约束（例如，工作地点关系集）告诉我们一个部门有一些员工。一个自然而然的问题是，是否每个部门都至少有一名员工。假设每个部门至少有一名员工。这种约束称为参与约束。
这种参与约束，我们可以分为两类：
Total Participation（完全参与）
顾名思义，实体集中的每个实体都必须与参与关系集的另一个实体集产生至少一个关系。
Partial Participation（部分参与）
实体集中的实体可能参与到关系集中，也可能不会。
判断条件：
实体集中的实体参与联系时是全体参与还是部分参与。
示例：每个员工都必须在部门工作，对于员工实体集来说，这种约束是什么？
Total Participation（完全参与）
如果关系集中的实体集的参与是完全参与，则两者通过粗线（thick line）连接。独立地，箭头的存在表示关键约束
非二元关系（Non-binary relationship）
假设每个部门在多个地点设有办公室，我们希望记录每个员工工作的位置。（since是关系集的属性，标识员工在工作位置开始的时间）
强实体（Strong Entity）/弱实体（Weak Entity）
强实体（Strong Entity）
定义：实体可以通过与该实体相关的某些属性进行唯一标识
例如，员工有一个属性 EmplD（可以用于唯一标识每个员工）
弱实体（Weak Entity）
定义：一个实体不能由与该实体相关的所有属性唯一标识。
弱实体需要借助其他实体集标识自身。
例如，假设员工可以购买保险来覆盖其家属。家属实体集的属性是pname和age。 属性 pname 不能唯一标识家属实体集。 家属实体集是一个弱实体集。家属实体集只能通过结合员工的主键（标识实体集/所有者实体集）考虑其某些属性来识别。对于给定所有者实体唯一标识弱实体的属性集称为鉴别器（discriminator）或部分钥匙（partial key）。 一个所有者实体与弱实体关联的关系集称为识别关系集（identifying relationship set）。
为了强调 Dependent 是一个弱实体，而 Policy 是它的识别关系，我们用粗线画出两者
上图中粗线、箭头都表示什么含义？
首先，用于表示弱实体和识别关系的，粗线画出两者。
其次箭头表示家属与员工关系集存在约束，属于1-to-Many的关系，一个员工可以有多个家属，而一个家属只能对应一个员工。
家属弱实体集到识别关系用粗线连接，表示完全参与（Total Participation），家属弱实体集中不能存在与员工没有关系的实体。
弱实体必须遵守以下限制：
所有者实体集（Owner Entity）和弱实体集（Weak Entity）必须参与在1-to-Many关系集中（一个所有者，许多弱实体）。
弱实体集必须完全参与（Total Participation）其中标识关系集。
类继承（Class Hierarchy）
在一个实体集中，不同的实体之间也有区别，像上述提到的雇员中的 "监管者" 和 "下属" 的区别，不过这种区别是有限的，因为他们的属性是相同的。
而有些实体之间区别过大，可能产生新的属性，就需要用到类继承（Class Hierarchy）。
雇员中也存在小时工（Hourly_Emps）和合同工（Contract_Emps），他们区别于其他的雇员，他们具有不同的属性。同时子类也拥有父类的属性，也就是说小时工（Hourly_Emps）有5个属性，合同工（Contract_Emps）有4个属性
类继承中的约束（Constraints on lSA Hierarchies）
可重叠约束（Overlap Constraints）
父类中的一个实体可以同时属于一个或多个子类实体集。
不相交约束（Disjoint Constraints）
父类中的一个实体只能属于一个子类实体集。
覆盖约束（Covering Constraints）
父类中的一个实体是否必须属于至少一个子类实体集。
完全覆盖（Total covering）
父类中的实体必须属于子类实体集中的一个。
部分覆盖（Partial covering）
父类中的实体不必属于子类实体集之一。
聚合（Aggregation）
关系通常是实体集之间的关联。
有时，我们也需要建模一种关联在实体集与关系之间的关系。聚合（Aggregation）允许我们将关系集视为实体集，以便参与（其他）关系。
示例：考虑一个名为project的实体集。每个 project 实体集被一个或多个departments赞助。那么，project 实体集与 departments实体集之间就产生了资助关系（sponsorship），一个 departments赞助一个 project可能会设立雇员去监管（monitor）赞助关系。直观地，monitors应该作为一种关系设立在雇员实体集与资助关系之间，所以这就需要用到聚合（Aggregation），将 project 实体集与 departments实体集产生的资助关系（sponsorship）的关系集视为实体集，与雇员产生监管关系。
E-R模型的概念设计
在设计一个E-R图之前我们应该考虑以下几点：
- 应该将一个概念建模成一个实体集还是一个属性还是一种关系。
- 什么是关系集及其参与实体集？
- 我们应该使用二元关系还是三元关系？
- 我们应该使用聚合吗？
通俗地讲，就是上述提到的这么多概念，例如实体集、描述实体集和关系集的属性、关系集，我们应该把要求中的概念建模成哪一项，要求中提到的概念与其他概念是什么关系，应该建模成哪一项才能符合要求，例子中提到的实体集的属性不是一成不变的，要根据实际情况，数据大小，数据的重要性和数据与其他概念的关系做出调整。
（声明：图片非原创，源自教授PPT，无情的PPT翻译机器罢了）