2.ER图表

实体关系模型

• Entity-Relationship（ER） Model 是一个广泛使用的数据概念模型，特别在数据库应用里
• ER Model 描述了数据库中数据存储的样式以及修改数据库时需要遵循的约束
  • 约束：譬如插入某种数据时必须附上哪些内容
• ER Model 将现实世界描述为一个集合，该集合包含 Entities 和他们之间的 Relationships

提纲

• 实体 Entity
• 关系 Relationship
  • 二元关系
• 弱实体/强实体
• 类层级
• 关系 Relationship
  • 非二元关系

实体

• 一个实体指代现实世界中的一个对象，每个 entity 都是区别于另外一个 entity 的存在
  • 例如，一间教室，一个老师，一所大学
• 用来描述 entity 的是 attributes（属性）。相同类型实体（如雇员）的不同实例（Tony、Ivy等），是依赖于属性的值进行区分
  
• 一个 entity set（实体集）包含了一些相同类型的实体
  
• 一个 entity set 包含的 entities 拥有相同的属性集，但它们的属性指就不完全一致
  

ER Diagram（ER图）

• 用 ER Diagram 表示 ER model
  
• 不同属性的类型
  • 简单属性
    • 包含单个值
    • 
  • 复合属性
    • 该属性又进一步又多个属性组成
    • 
  • 多值属性
    • 对于其他属性，每个 entity 实例都相应只有一个值。相反地，每个 entity 在多值属性可拥有多于一个值。
    • 
  • 继承属性（派生属性）
    • 可根据其他属性计算出来
    • 例如，年龄可以由生日和当前时间计算出来
    • 
• 键（Key）：唯一标识符
  • 用来唯一地指引一个 entity 实例，可以是一个属性，也可以是一个属性的集合
  • 例如身份证号码
  • 
  • 复合键（Composite Key）
    • 当一个key包含多于一个属性的，又可称为复合键
    • 例如，在一家公司中，有重名，但是重名的人不住一起。则 Name 和 Address 可以组成一个复合键
    • 
  • 一个 entity 可以有多个 key 。可以唯一地指代该 entity 的属性{集}均为 key 。
  • 例如： {ID} 和 {Name,Address} 都是雇员的 key
  • 
  • 有些 key 可以包含另外一些 key ，不被包含的 key 才是有意义的
  • 最短的 key 称之为 candidate key（候选键）
  • 例如， {ID} 和 {Name,Address} ，{ID，Name，Address} 都是雇员的 key ，但是只有 {ID} 和 {Name,Address} 是 candidate key
  • 有时候我们可以认为额外的创建 key
  • 例如，如果在一家企业中，身份证信息是不用的，我们可以创建一个属性 EmpID （职工号），该职工号可以用作 primary key
  • 
• 示例：表示顾客的实体
  
  

关系

• 一个关系描述了多个实体之间的联系
• 一个关系的度（degree）描述了该关系连接的实体个数
• 一个二元关系连接了两个实体集合
• 关系也可以连接多于两个的实体类型，不过比较少见

二元关系

• Employees work in Dapartments，员工在部门工作
• work_in 就是一个描述 Employees 和 Departments 两种 entity 间关系的 relationship，如下图
  
• 一个 relationship 本身也是可以伴随有属性的
  

递归关系

• 描述两个相同类型实体的关系。例如，职工A对职工B作报告
• 
  • “Report_to”连接了两个相同类型的 entity ，但是它们在这个 relationship 中扮演了不同的角色
  • 在图中用角色标识（role indicators）进行区分下属和主管

约束

描述了存储数据时，其内容必须服从的规则

二元关系可以分成4种约束类型

基数约束

• “一对多”：B 中的一个实例最多可以与 A 中的一个实例关联
  • 
  • 一个贷款通过 borrow 最多关联到一个客户，一个客户可以关联到多个贷款
  • 
  • 
• “多对一”："一对多"的说法中把两个对象反过来
• “一对一”：B 中的一个实体最多可以与 A 中的一个实体关联，反之亦然
  • 
• “多对多”：A 中的实体与 B 中任意数量的实体关联，反之亦然。
  • 

参与约束

如何描述每个贷款至少关联一个客户？

两种参与约束

• 全部参与：实体集中的每个实体必须至少有一种关联关系，即至少有一条边
  • 
• 部分参与：实体集中每个实体可能（或可能不）存在关联关系，即有些实体可能没有边
  • 
• 贷款（load）对借贷关系（borrower）是全部参与的：双线段表示
• 客户（custom）对借贷关系（borrower）是部分参与的：默认情况，无需特别表示
  

强/弱实体

强实体

• 一个 entity 可以被它的自带属性唯一索引
• 例如：Employee 可以被 EmpID 唯一索引

弱实体

• 一个实体不能被它自带的属性唯一索引。譬如，还没有身份证的小孩，他的索引依赖于户主，以及与户主的亲属关系
• 例子
  • 假设职工可以买保险保障其亲属 dependent
  • 在我们的定义里，亲属的属性只有 pname 和 age
  • pname 和 age 不能唯一确定一个 dependent
  • Dependent 是一个弱实体
  • 亲属的索引依赖于职工。譬如，职工ID + 亲属姓名，职工成为亲属的 Identifying entity set
  • 在这种情况下，亲属姓名称为 partial key
    
  • 如果弱实体W依赖于强实体E，我们称 E owns W.
  • 另外一个例子：不同的贷款可能产生同样的支付流水号“payment number”，则 loan owns payment
  • 

层级

把 entity 分出子类别

• 子类别继承父类的所有属性
• 如何描述子类与父类的关系
  • 重叠约束（Overlap constraints）：employee 实体是否可以同时作为 Hourly_Emps 和 Contract_Emps ?
  • 覆盖约束（Covering constraints）：任意一个 employee 实体是否至少是 Hourly_Emps 和 Contract_Emps 其中的一种？
  • 在 ER 图中的表示：
    • 
• 使用继承的原因：
  • 增加子类特有属性
    • 例如，Hourly_wages 对于 Contract_Emps 实体没有意义
  • 方便找出特定 entity 的子集
    • 例如，我们可能希望与 Contract_Emps 建立一种称为 “Bonus” 的关系

多元关系

以三元关系为例

• 一个雇员在一个具体工作地点为一个部门工作
  
• 然而，任何非二元关系都可以转化为二元关系表示
•