数据库系统概念 | 第七章：使用E-R模型的数据库设计 | ER图设计| ER图转化为关系模型 | 强实体和弱实体

本篇的实例分析多选自于大学机构E-R图

设计过程概览

实体-联系模型

世界是由一组称作实体的基本对象和这些对象之间的联系构成的

E-R数据模型

实体集

• 实体

  • 定义：客观存在并可相互区分的事物叫实体
  • 示例：instructor和student是两个不同的实体，ID和name是属性
    

• 属性

  • 实体通过一组属性来表示，属性值唯一地表示出一个实体
  • 实体名和属性名组成实体型，对比关系模型而言类似于关系与属性
  • 主码属性唯一地标识出一个实体型
  • 示例：学生(学号，姓名，性别，年龄，系别，入学时间)，是学生实体型； (98080221，王平，女，19，计算机，1998)是一个实体

• 实体集

  • 共享相同性质或属性的、具有相同类型的实体的集合

• 外延

  • 定义：属于实体集的实体的实际集合
  • 实体集与实体集的外延，对比关系模型而言类似于关系和关系实例的区别
  • 实体集内部的不同外延可相交

• E-R模型实体集对比关系模型关系

  E-R模型实体集	关系模型
  实体	表中一个元组
  属性	表中一个字段
  实体集	一个表

示例说明

• 将一所给定大学的所有教师的集合定义为instructor实体集，那么大学中教师的实际集合构成了instructor实体集的外延
• 同理，将该大学的所有学生的集合定义为student实体集，那么大学中学生的实际集合构成了student实体集的外延
• 再定义大学中所有人员组成的person实体集，那么大学中的人员（子集）、大学中的老师（真子集）、大学中的学生（真子集）都可以叫做person实体集的外延
• 同时，我们称一个person实体可以是instructor实体，也可以是student实体，也可以既是instructor实体又是student实体，也可以都不是。

联系集

• 联系

  • 多个实体间的相互关联
  • 示例：教师ID为45565的instructor实体Katz和一个学生ID为12345的student实体Shankar参与到advisor的一个联系实例中。表示教师Katz指导学生Shankar

• 联系集

  • 是相同类型联系的集合，是n ≥2个（可能相同的）实体集上的数学关系。

  (e1, e2, …, en) 是一个联系实例（联系实例：表示所建模的现实世界中实体间的一个关联）

  • 联系集的度：即参与联系集的实体集的数目

  • 参与：联系集之间的关联称为参与，即实体集E1，E2，…,En参与联系集R

• 角色

  • 定义：实体在联系中扮演的功能称为实体的角色
  • 作用：同样的实体集以不同角色参与一个联系，需用角色名
  • 示例：
    • 考虑记录大学中所开设的所有课程的信息的course实体集，我们用course实体的有序对来建模联系集 prereg以描述一门课程。
    • （C2）是另一门课程（C1）的先修课，每对课程中的第一门课程扮演C1课程的角色，而第二门课程扮演C2先修课的角色。
    • 按照这种方式，所有的prereq联系通过（C1,C2）对来表示，排除了（C2,C1）对。
    • 在E-R图中，我们通过在菱形和矩形之间的连线上进行标注来表示角色。如图给出了course实体集和prereq联系集之间的角色标识course_id和prereq_id

• 描述性属性

  • 一个联系集可以具有多个描述性属性
  • 联系集的描述性属性在E-R图中通过未分割的矩形来表示，用虚线将此矩形与表示该联系集的菱形相连接。
  • 示例：
    • 考虑与student和section实体集相关联的takes联系集，我们可能希望存储联系的描述性属性grade，以记录学生在开设的课程中获得的成绩。
    • 如图我们将描述性属性grade 附加到takes联系集上；我们还可以在takes联系集上存储描述性属性for_credit，以记录学生选这门课是为了修学分，或是旁听这门课程等

属性

• 域

  • 表示属性的取值范围
  • 域对应数据类型
  • 域可取缺省定义，也可以用语句显式定义，如create domain age_domain smallint

• 属性分类
  

  • 空值属性：null表示“不适用”“不存在值”“缺失的”或“不知道的”
  • 派生属性：从其他相关的属性或实体派生出来的属性值，在E-R图中用虚线椭圆表示
    • 如：出生日期、成绩称为基属性或存储属性，派生属性的值不存储，需要时计算出来
  • 一个复杂属性的示例
    

E-R图

• 通过图形的方式表示数据库的总体逻辑结构
  

映射基数

映射基数（基数比率）：表示一个实体通过一个联系集能关联的实体的个数

二元联系集⭐️

一对一

实体集A中的一个实体至多与实体集B中一个实体相关联（可以没有），实体集B中的一个实体至多与实体集A中一个实体相关联（可以没有）

一对多

实体集A中一个实体可以与实体集B中的任意数目实体(n≥0)相关联（可以没有），而B中的一个实体至多与A中的一个实体相关联（可以没有）

多对一

实体集A中的一个实体至多与实体集B中的一个实体相关联（可以没有），而B中一个实体可以与A中任意数目(n≥0)个实体相关联（可以没有）

多对多

实体集A中的一个实体可以与实体集B中任意数目(m≥0)个实体相关联（可以没有），而实体集B的一个实体也可以与实体集A中任意数目(n≥0)个实体相关联（可以没有）

联系集展示

注意有向线段的表示

多元联系集

多个实体集间之间m： n：p联系

实体集内联系

同一实体集内各实体间的联系也呈现一对一，一对多，多对多的形式

一个复杂的映射基数描述

实体集与联系集的一条边上可以有一个关联的最小和最大的映射基数l…h，如图所示示例：

• 最小值1，表示这个实体集在该联系中全部参与，即实体集中的每个实体在联系中的至少一个联系中出现
• 最大值1，表示这个实体集参与至多一个联系
• 最大值*，代表没有限制

参与约束

参与约束

• 联系的参与度：每个实体有一个参与联系的次数，取最小、最大的参与次数min和max，定义实体集的参与度。
  • min = 0，称联系为部分参与
  • min＞0，称联系为全参与
  • Max限制每个实体的参与次数
• 实体集到联系集的参与
  • 如果实体集E中每个实体都参与到联系集R的至少一个联系中，那么实体集E到联系集R的参与称为全部参与
  • 如果E中只有部分实体参与到R的联系中，实体E到联系集R的参与称为部分参与
• 参与约束在E-R图中的表示示例

第一个例子学习参与约束的格式，结合映射基数查看第二个例子

存在依赖

• 如果实体x的存在依赖于实体y的存在，则称x存在依赖于y
  • y称作支配实体
  • x称作从属实体
  • 如果y被删除，则x也要被删除
• 示例：考虑分期付款的例子，对每一个“贷款”实体，有若干个“还款”实体与之关联，“还款”实体存在依赖于“贷款”实体

全部参与与存在依赖

主码⭐️

实体集中的码

• 主码能唯一标识实体的属性或最小属性集，也称为实体键
  • 具有唯一性的特点，即给出码属性的一个值，到实体集中或只找出一个实体或一个也找不到
  • 任一表都有码，实体集属性中作为主码的属性用下划线来标明
• 侯选码：如果有多个码，每个码都称为侯选码，从中指定一个作为主码
  • 例如职工实体集中，职工号为候选码，若姓名不重，也是候选码
• 超码：候选码的超集，比候选码有多余的属性，也能唯一标识一个实体

---

超码、候选码和主码总结❓

共同点：惟一标识一个实体集
区别：超码中可能有无关的属性，而主码和候选码中属性都是必要的属性；
主码是候选码中的一个”人选之子“（数据库设计者所选）

---

联系集中的码

• 设R是一个涉及实体集E1，E2，…,En 的联系集。设primary-key(E1)表示构成实体集E1的主码属性集合

  • 属性集合：primary-key(E1) ∪ primary-key(E2) ∪ …∪ primary-key(En) 构成了联系集R的一个超码

• 联系集的主码结构依赖于联系集的映射基数（见上文映射基数）

  • 如果联系集是多对多的，则联系集的主码由参与的实体集的主码并集组成
  • 如果联系集是一对多或多对一的，则联系集的主码由多方的实体集的主码组成
  • 如果联系集是一对一的，则联系集的主码由可选任意一个参与实体集的主码组成

  • 边上没有箭头的n元联系，所有参与实体集的主码并集
  • 边上有一个箭头的n元联系，不在“箭头”侧的实体集主码并集

• 名称问题

  • 如果实体集间主码的属性名称有相同的，重命名主码
  • 如果一个实体集不止一次参与某个联系集，则使用角色名

弱实体集

没有足够的属性以形成主码的实体集称为弱实体集

弱实体集的特点

• 弱实体集存在依赖于另一个实体集，该实体集被称为标识性实体集（属主的拥有者）
• 弱实体集与其标识实体集之间的联系称作标识性联系
• 标识性联系是从弱实体集到标识性实体集多对一的，且弱实体集在联系中是全部参与

弱实体集的主码

• 弱实体集的主码由该弱实体集的标识实体集的主码和该弱实体集的分辨符组成
• 分辨符
  • 弱实体集中用于区别依赖于某个特定强实体集的属性集合，也称作部分码

弱实体集的好处

• 避免数据冗余（强实体集码重复），以及因此带来的数据的不一致性
• 弱实体集反映了一个实体对其它实体依赖的逻辑结构
• 弱实体集可以随它们的强实体集的删除而自动删除
• 弱实体集可以物理地随它们的强实体集存储

弱实体集的E-R图表示

• 弱实体集的分辨符以虚下划线表明
• 关联弱实体集和标识实体集的标识性联系以双菱形表示
• 从弱实体集到标识实体集多对一的，且弱实体集在联系中的参与是全部的

示例

• 示例一：贷款（贷款号，金额），还款（还款号，还款日期，金额）。显然两个实体集具有存在依赖。每个“贷款”的各个“还款”不同，但不同“贷款”之间的“还款”信息却可能相同 (还款无法标识自己还的是哪一笔贷款） ，因此“还款”是一个弱实体集
• 示例二：如图，section的标识性实体集是course，将section实体和它们对应的course实体关联在一起的sec_course联系是标识性联系。
  • section的主码由标识性实体集（即course)的主码加上弱实体集（即section)的分辨符构成。
  • 因此，主码就是｛course_id,sec_id,year,semester} 。
    

强实体集

有主码的实体集称为强实体集

---

对强实体与弱实体的总结❓

• 区别弱实体与强实体的关键在于主键，“依赖”的实质是主键之间的关系。所以归根到底，判断强实体集和弱实体集就是判断主键之间是否有关系、主键是否是组合主键。
• 弱实体与强实体可以相互转换，没有绝对意义上的强与弱。既然区别弱实体与强实体的关键在于主键，那么一个同样意义的表，当我给它一个编号作为主键，那么它就不是弱实体，而如果我令它的主键是组合主键，它就是弱实体。
  • 如果我们说排课表的主键是组合主键（课程编号+排课编号，如CS163、1），那它是弱实体
  • 如果我们定义排课编号是“CS16301”，而不再是“1”，那么它的主键（排课编号）就不再需要课程编号，它就成为了强实体。
• 弱实体也可以依赖于弱实体。
• 弱实体与它所依赖的实体之间的关系只能是1：1或n：1。
  • 也就是说，一个弱实体实例不可能依赖于同一实体的多个实例。
  • 因为如果弱实体实例A依赖于实例B，那么A的主键要包括B的主键，所以A当然不可以依赖于很多个B。

---

从实体集中删除冗余属性

使用E-R模型设计数据库时，一旦选择好实体和相应的属性，不同实体间的联系集就建立起来了。这些联系集有可能会导致不同实体集中的属性冗余，需要将其从原始实体集中删除。

• 特征往往是，一个实体集的主码是另一个实体集的候选码，则另一个实体集中的候选码为冗余的，应删去
• 示例
  

将E-R图转换为关系模式⭐️

实体集的表示

强实体集的表示

• 简单属性
  

• 复杂属性

  • 派生属性 -->不出现
    

  • 复合属性 --> 由子属性代替
    

  • 多值属性 --> 新的关系 + 所在实体的码；建外码约束

    对于一个多值属性M,构建关系模式R，该模式包含一个对应于M的属性A,以及对应于M所在的实体集或联系集的主码的属性。R的主码由R的所有属性构成。

  

  • 一个实体集只有两个属性(主码B和多值属性M)，只转换为一个关系模式

碎碎念

• 按定义，主码是从候选码里头挑了一个“人选之子”，那应该是唯一的一个主码。但弱实体集还有联系集都有主码不止一个的情况，那咋理解❓
• 因为强实体集里的主码是人为规定的，选了一个，但弱实体集和联系集里，主码可以说是挑出来的，而是按照一定规则选的别人的主码的并集。

弱实体集的表示

• 所对应的关系的码由弱实体集本身的分辩符再加上所依赖的强实体集的主码（建外码约束：指明弱实体集中的属性引用强实体集关系的主码）
• 弱实体集与强实体集之间的联系已经在弱实体集所对应的关系中表示出来了
  

联系集的表示

• 设R是联系集，a1,a2,…am表示所有参与R的实体集的主码的并集，设R的描述性属性(如果有)为b1,b2,…bn，则R的关系模式的属性为：{a1,a2,…am} ∪ {b1,b2,…bn}

  • R的主码选择
    

  • 示例：（属性名称相同时进行了重命名）
    

模式的冗余

对应情况：连接弱实体集与相应强实体集的联系集可能存在冗余

示例：

• 如图，section弱实体集通过sec_course联系集依赖于course强实体集。section的主码｛course_id,sec_id,semester,year}，并且course的主码是course_id.。
• 由于sec_course没有描述性属性，因此sec_course模式具有属性course_id、sec_id、semester以及year.。表示section实体集的模式包含 course_id、sec_id、semester以及year属性。
• sec_course关系中的每个（course_id,sec_id,semester,year)组合也将出现在section模式上的关系中。反之亦然。因此，sec_course模式是冗余的。
  

模式的合并

• 概念
  • 从实体集A到实体集B的一个多对一的联系集AB，生成三个模式A、B和AB。设A在联系中是全员参与，那么可以将A与AB模式合并成包含两个模式所有属性并集的模式
• 内容拓展
  • 一对一的联系集关系模式，可以与参与联系的任一实体集模式进行合并
  • 若A在联系中是部分参与，可以合并后在未联系到的属性上置空值来完成模式合并
  • 联系集关系模式合并后，舍弃了参照所合并入实体集模式的外码约束，将另一个外码约束加入合并的模式中，此约束不必写出，已经被隐式强制执行
    • 如：inst_dept( ID, dept_name)合并如instructor后，舍去原ID到instructor的外码依赖；将dept_name参照department关系的外码约束加入instructor后，外码约束被隐式执行
• 示例
  • inst_dept可以和instructor合并，结果形成 instructor(ID,name,dept_name, salary)

扩展的E-R特性(了解）

特化

• 定义
  • 实体集中某些子集具有区别于该实体集内其它实体的特性，可以根据这些差异特性对实体集进行分组。在实体集内部进行分组的过程称作特化
• 特点
  • 自顶向下、逐步求精
  • 子类＝特例＝更小的实体集
  • 子类可以附加更多的具有区分性的属性
• 分类
  • 重叠特化：一个实体集可能属于多个特化实体集
  • 不相交特化：一个实体集必须属于至多一个特化实体集
  • 超类-子类联系：高层和低层实体集按照普通实体集表示（即包含实体集名称的矩形）
• 表示
  • 特化用标记为ISA的三角形来表示
  • 示例：实体集人员(ID,name,address) 可进一步划分为老师、学生，实体student可以特化为本科生、研究生，本科生和研究生具有更多的属性

概化

• 定义
  • 各个实体集根据共有的性质，合成一个较高层的实体集。概化是一个高层实体集与若干个低层实体集之间的包含关系
• 特点
  • 自底向上、逐步合成

---

⭐️概化与特化是个互逆的过程，在E-R图中的表示方法是相同的
⭐️特化强调同一实体集内不同实体之间的差异
⭐️概化强调不同实体集之间的相似性

---

属性继承

• 属性继承
  • 高层实体集的属性被低层实体集自动继承
  • 低层实体集特有的性质仅适用于某个特定的低层实体集
  • 子类同时继承地参与超类所参与的联系集
• 层次结构
  • 低层实体集只参与到一个ISA联系中，单继承
  • 如图所示为单继承
    
• 格结构
  • 低层实体集可以参与到多个ISA联系中，多继承
  • 如“博士”算参加工作，会继承“职工”实体集的一些属性，如图所示为多继承
• 重命名
  • 示例：“博士”继承了“研究生”与“职工”的所有属性。如果“研究生”与“职工”有相同名称的属性，如“姓名”，则在“博士”中用“研究生.姓名”，“职工.姓名”区别开来

设计约束

• 成员资格约束

  确定哪些实体能成为给定低层实体集的成员

  • 条件定义的：一个实体成员资格的确定基于该实体是否满足一个显式的条件或谓词（系统可以自动检查条件定义的约束）
    • 示例：假定student实体集具有属性student_type，则所有的学生实体根据student_type进行成员资格认定，如一个学生的student_type =“本科生”，则他就可以归入低层本科生实体集中
  • 用户定义的：由数据库用户来指定一个实体归入哪个低层实体集
    • 示例：一个学生被老师分配到某个项目组

• 成员身份约束

  同一个概化中，一个实体是否可以属于多个不同低层实体集

  • 不相交的：一个实体至多属于一个低层实体集
    • 示例：一个学生只能参加一个项目组
  • 有重叠的：同一实体可以同时属于同一概化的多个低层实体集
    • 示例：一个老师可以参加多个项目组

• 完全性约束

  确定高层实体集中的一个实体是否必须至少属于一个低层实体集

  • 全部的：每个高层实体必须属于一个低层实体集
    • 示例：学生必须属于“本科生”或“研究生”的一种
  • 部分的：允许一些高层实体不属于任何低层实体集
    • 示例：允许学生可以不属于任何项目组。

  部分特化是默认的

聚集

• 定义
  • 聚集是一种抽象，一个联系可以通过聚集成为一个高层实体集
  • 示例：实体集A与B以及它们的联系可被看成另一实体集C
    
• 特点
  • 将联系作为抽象实体
  • 允许联系之间存在联系
  • 将联系抽象进新的实体中
  • 联系之间存在重叠时使用聚集
• 示例
  • 图一为存在重叠的联系，图二为使用聚集优化后的联系
    

扩展的E-R特性转换为关系模式

概化的表示

• 为高层和低层实体集创建模式
  • 低层实体集关系建立外码依赖，参照高层关系主码
  • 示例：person集可以特化为employee集和student集，其关系模式为
• 如果概化是不相交且完全的（完整性约束）
  • 只需要为每个低层实体集创建模式
  • 属性包括高层实体集和低层实体集的每一个属性
  • 示例：person集的每个实体person(ID,name,street,city)全部属于特化的employee集和student集，那么其关系模式为

聚集的表示

• 聚集与实体的联系集
  • 这个联系集的模式包含实体集主码属性及聚集联系集的主码属性，再加上联系集自身的描述性属性
• 在聚集的实体集中转换联系集和实体集
  • 不需要单独关系表示聚集，用定义该聚集的联系创建关系

实体-联系设计问题

用实体集还是用属性❓

• 按数据粒度确定实体与属性，能形成元组的设计成实体，只是单一数据项的设计成属性
  • 城市为属性，只一个；城市更适合作为实体，可以拥有多个属性
• 设计E-R图时考虑将来转化成关系模式表的多少，查找数据的方便
  • 示例：电话若只是一个数据项则作为员工的属性，电话若需多个属性描述设计成实体，设计为属性查找数据快捷，设计为实体需要两个表查找不便但冗余小
• 实体中，多值属性还有其它若干属性，则将该多值属性定义为另一实体
  • 示例：供应商可以供应多种不同的零件，零件是多值属性

用实体集还是用联系集❓

• 当描述发生在实体间的行为时，采用联系集
• 示例：
  • 一个老师对应一个课的时候，是实体之间的行为，对“开课”没有要求（限于本例）；
  • 若多个老师开同一门课，则每个老师与该课程的“开课”联系都需重复记录很多相同的信息（时间、地点、班级等），这时候就可以将“开课”联系改为实体集。
  • 开课改为实体，与课程是1：N，与教师是N：M的比例关系。
    

二元还是n元联系集❓

• 对于非二元的的联系集总可以用一组不同的二元联系集来替代
• n元联系集可以更清晰地表示几个实体参与到单个联系中
• 有可能无法将三元联系上的约束转换为多个二元联系上的约束

联系属性的布局❓

• 一对多联系集的属性仅可以重置到参与联系的“多”方的实体集中

• 一对一的联系集属性可以放到任意一个参与实体集中；

• 多对多的联系集，描述属性必须作为联系集的属性

可选表示法（速查）

E-R图表示法的符号集

可选的E-R符号表示法

统一建模语言UML

• 类图：和E-R图等价且类似的UML表示法
• 用况图：展示了用户和系统之间的交互，特别是用户所执行的任务的步骤（如取钱或登记课程）
• 活动图：说明了系统各个部分之间的任务流
• 实现图：在软件构建层和硬件构建层展示了系统的组成部分以及它们之间的联系

E-R图和等价的UML表示法

一道综合例题（应试版）

E-R图

关系模式

主码外码

---

参考博客
搞懂 超码、候选码、主码、函数依赖！
强实体与弱实体
ER图转换为关系模式