数据库概论.陈立军.02.ER 模型(2)

Posted on Edited on In Views:
扩展 ER 特性（弱实体集、特化、概化、聚集）、ER模型设计要点、概念数据库设计过程、ER模型向关系模式的转换、UML

ER 模型

扩展 ER 特性

弱实体集

还款与贷款的关系建立

  • 还款：还款号，还款日期，金额
  • 贷款：贷款号，金额
  • 贷款对应多个还款
表示 1：把还款作为普通实体

  • 问题：还款的所有属性都不能作为主码
    • 不满足实体的条件
表示 2：把贷款号借给还款实体

  • 问题：贷款号冗余
表示 3：把还款作为贷款的多值属性

  • 问题：还款概念消失了
    • 还款应当会和帐户发生支付联系
表示 4：把还款作为复合属性
  • 图上的还款应该是两个圈（复合属性）

  • 问题：还款作为复合属性，不能和帐户（实体）发生联系
表示 5：还款作为弱实体
  • 下图少了个属性（还款日期）

  • 弱实体的表示
    • 两层矩形框
  • 标识性联系
    • 两层菱形框

弱实体集

  • 弱实体集（Weak Entity Set）
    • 一个实体集的所有属性都不足以形成主码
  • 标识性联系（identifying relationship）
    • 弱实体集与其拥有者之间的联系
    • 弱实体集与强实体集之间是一对多的联系
  • 弱实体集必然存在依赖于强实体集
  • 存在依赖并不总会导致一个弱实体集，从属实体集可以有自己的主码

弱实体集的分辨符

  • 分辨符（Discriminator)
    • 弱实体集中用于区别依赖于某个特定强实体集的属性集合，也称作部分码（partial key)
  • 弱实体集的主码 = 强实体集的主码+ 弱实体集的分辨符
    • “还款” 主码＝贷款号＋还款号

弱实体集在 ER 图中的表示

  • 弱实体集以双边框的矩形表示
  • 标识性联系以双边框的菱形表示
  • 弱实体集的分辨符用下划虚线标明
  • 从联系集用双线（全部参与）连接弱实体集，用箭头（一对多联系）指向强实体集

何时引入弱实体集

  • 作为层次结构的一部分
    • cs.pku.edu.cn
  • 实体集的一些多值、复合属性可以抽取出来作为弱实体集
    • 贷款的还款属性
  • 如果弱实体集不但参与和强实体集之间的标识性联系，而且参与和其它实体集的联系，或者弱实体集本身含有很多属性，则将其表述为弱实体集

特化

  • 实体集中某些子集具有区别于该实体集内其它实体的特性，可以根据这些差异特性对实体集进行分组，这一分组的过程称作特化
    • 类似细分
  • 自顶向下、逐步求精的数据库设计过程
  • 子类＝特例＝更小的实体集＝更多的属性
  • 细化：父类 \(\to\) 子类

特化在 ER 图中的表示

  • 特化用标记为 ISA 的三角形来表示
    • ISA = “ isａ”
    • 表示高层实体和低层实体之间的 “父类－子类” 联系

  • 特化使得联系的对象更精确
    • 可以让一些属性精确定位到子类当中

概化

  • 各个实体集根据共有的性质，合成一个较高层的实体集。概化是一个高层实体集与若干个低层实体集之间的包含关系
  • 自底向上、逐步合成的数据库设计过程
  • 泛化：子类 \(\to\) 父类

概化与特化对比

  • 概化与特化是互逆的，在E-R图中的表示方法相同
  • 特化强调同一实体集内不同实体之间的差异
  • 概化强调不同实体集之间的相似性
  • 反映了数据库设计的不同方法

概化中的属性继承

  • 高层实体集的属性被低层实体集自动继承
  • 低层实体集特有的性质仅适用于某个特定的低层实体集
两种继承结构
  • 层次结构（Hierarchy）
    • 实体集作为低层实体集只能参与到一个 ISA 联系中
  • 格结构（Lattice）
    • 低层实体集可以参与到多个 ISA 联系中
    • 例如下图中的博士参与了两个 ISA 联系

  • “博士” 继承了 “研究生” 与 “职工” 的所有属性
  • 格结构的问题
    • 如果 “研究生” 与 “职工” 有相同名称的属性，如 “姓名”
    • 可以在 “博士” 中用 “研究生.姓名”，“职工.姓名” 区别开来

概化中的成员身份

  • 成员身份：同一个概化中，一个高层实体是否可以属于多个不同低层实体集
两种成员身份
  • 不相交的 (Disjoint)
    • 一个实体至多属于一个低层实体集
      • 如一个学生只能参加一个项目组
  • 有重叠的 (Overlapping)
    • 同一实体可同时属于同一概化的多个低层实体集
      • 如一个老师可以参加多个项目组

概化中的全部性约束

  • 全部性约束：确定高层实体集中的一个实体是否必须属于至少一个低层实体集
两种全部性约束
  • 全部的 (Total)
    • 每个高层实体必须属于一个低层实体集
      • 如学生必须属于本科生或研究生的一种
    • ER 图的设计中，一般用双线连接 ISA
  • 部分的 (Partial)
    • 允许一些高层实体不属于任何低层实体集
      • 如学生可以不属于任何项目组

聚集

  • 如何表达联系之间的联系
  • 某些联系之间存在重叠

实例：职工参加项目，并在此过程中可能使用机器

表示为三元联系

  • 问题
    • 作为三元联系，有些职工并不和机器发生联系
    • 不雅驯的命名对于 ER 是个大问题
表示为二元联系

  • 问题
    • 看不出来职工在项目 A 使用什么机器

聚集

  • 一个看上去的三元联系实则是两个动作序列
  • 实体集 A 与 B 以及它们的联系可被看成实体集，然后与另一实体集 C 发生联系
  • 聚集是一种抽象
    • 通过聚集联系被抽象为高层实体集

ER 模型设计要点

ER 模型设计中的选择问题

  • 实体 / 属性
  • 实体 / 联系
  • 二元 / 多元
  • 聚集 / 三元

如何选择

  • 目标
  • 利弊

实体 / 属性

  • 实体有多方面性质，属性没有
  • 属性通常是原子性的

实体 / 联系

  • 实体与联系：静态与动态
  • 联系的属性一般是动态的，否则可以抽象成一个（弱）实体

二元 / 多元

  • 多元到二元的瓠瓜式通用转换方式
    • 新构建一个标识实体集 \(E\)，构造三个新联系集 \(R_A\)，\(R_B\)，\(B_C\)，对每个 \((a_i,b_i,c_i)\in R\)，在 \(E\) 中创建一个 \(e_i\)，然后在 \(R_A\)，\(R_B\)，\(B_C\) 中分别加入联系 \((e_i,a_i)\)， \((e_i,b_i)\)， \((e_i,c_i)\)
    • 但是这样子没有实际意义，单纯是一个标识

能否用实体之间的二元联系替换三元联系

  • 多出来其他的元素 (4,2,3)
  • 一般情况下很难

聚集 / 三元

实例

  • 一个项目由多个部门资助，一个部门资助多个项目，每个资助协议由一个或多个雇员监督
    • 监督有属性截至时间，资助有属性起始时间
  • 三元联系
    • 不明确，如果资助和监督有自己的属性则不能明确表示属性是属于资助的还是监督的
    • 用词奇怪

  • 聚集

概念数据库设计过程

总体流程

graph LR;
A[需求分析结果];
B[局部 ER 模式设计];
C[全局 ER 模式设计];
D[全局 ER 模式优化];
A--->B--->C--->D;

局部 ER 模式设计

graph LR;
B[确定局部结构范围];
C[实体定义];
D[联系定义];
E[属性分配];
subgraph 局部 ER 模式设计
B--->C--->D--->E;
end

全局 ER 模式设计

graph LR;
B[确定公共实体类型];
C[合并两个局部 ER 模式];
D[检查并消除冲突];
E{是否还有未合并的局部模式};
F[全局 ER 模式优化];
subgraph 全局 ER 模式设计
B--->C--->D--->E;
E--->|有|C;
end
E--->|无|F;

消除冲突

属性冲突
  • 属性域的冲突
  • 属性的类型、取值范围不同
    • 如不同学校的学号编码方式不同
  • 属性取值单位冲突
    • 如重量分别采用磅、千克
命名冲突
  • 同名异义
    • 不同意义的对象具有相同的名字
  • 异名同义
    • 同一意义的对象具有不同的名字
结构冲突
  • 同一对象在不同应用中的抽象不同
    • 职工在某应用中是实体，在另一应用中则抽象为属性
  • 同一实体在不同 ER 图中属性组成不同
    • 有的职工实体有 email，有的职工实体则没有
  • 实体之间的联系在不同 ER 图中呈现不同的类型
    • 联系种类不同
    • 参与联系的实体不同

全局 ER 模式优化

graph LR;
subgraph 全局 ER 模式优化
B[合并实体类型];
C[消除冗余属性];
D[消除冗余联系];
B--->C--->D;
end
E[逻辑数据库设计]
D--->E;

ER 模型向关系模式的转换

  • ER 模型：概念数据模型
  • 关系模式：结构数据模型

实体

  • 每个实体一张表
  • 实体 \(\to\) 关系
  • 属性 \(\to\) 关系的属性

复合属性

  • 将每个组合属性作为复合属性所在实体的属性
    • 复合属性拆解为原子属性
  • 复合属性定义为视图，或由应用定义

多值属性

  • 多值属性 \(\to\) 新的关系 + 所在实体的码
  • 单独放在一个表里，避免出现冗余

联系

一对多联系

  • 将单方参与实体的码作为多方参与实体的属性
实例
  • 教师：教工号、姓名
  • 学生：学生号、姓名
graph RL;
A[教师];
B{导师};
C[学生];
C---B--->A
  • 直接多开一个表存教工和学生之间的联系
    • 有些浪费
  • 简单的关系表

多对多联系

  • 将联系定义为新的关系，属性为参与双方的码
实例
graph LR;
A[学生];
B{选修};
C[课程];
A---B---C;

一对一联系

  • 若联系双方均部分参与，则将联系定义为一个新的关系，属性为参与双方的码
    • 新建一个表
  • 若联系一方全部参与，则将联系另一方的码作为全部参与一方的属性
    • 看成特殊的一对多联系

弱实体

  • 弱实体集所对应的关系的码由弱实体集本身的分辩符再加上所依赖的强实体集的码
  • 弱实体集一个表，同时加上其所依赖的强实体的一个码

例题

  • 关系表有 3 个
    • C（c，f）
    • B（b，c，e）
    • A（a，b，c，d）

概括

  • 概化和特化
  • 高层实体集和低层实体集分别转为表，低层实体集所对应的关系包括高层实体集的码
    • 低层实体集记录自己独有的属性，以及高层实体集的一个码
    • 性能上不利的地方：如果需要查询低层实体的某些属性信息时（这些属性属于高层实体集时），需要和高层实体的表做一个连接操作
  • 如果概括是不相交并且是全部的，则可以不为高层实体集建立关系，低层实体集所对应的关系包括上层实体集的的所有属性
    • 高层实体刚好可以不重不漏的划分为低层实体
    • 获取所有高层实体的信息只需要两个表求并即可（求并很快）

聚集

  • 实体集 A 与 B 及其联系 R 被抽象成实体集 C，C 与另一实体集 D 构成联系 S，则 S 的码由 C 和 D 的码构成
  • 具体 C 的码是什么需要分情况考虑（看 S 怎么表示）
    • 参考上面的不同联系的码（一对一、多对多、一对多）

逆向工程：关系模式向ER的转换

例子

  • 描述
    • 已知有如下关系模式：R1(a1,a2,a3)，R2(a3,a4)，R3(a5,a6)，R4(a3,a5,a7)
    • 其中加粗的属性标识为所在关系模式的主码，试画出合适的 ER 图，使得可以将该 ER 图转换为上述关系模式
  • 关键
    • 重合属性体现了实体之间的联系
  • 答案

ER 模型总结

总结

  • 概念模型：人脑中的信息世界
  • 概念模型需要清晰
  • 数据组织必须契合处理需求
  • 操作型应用：ER 模型
  • 综合分析型应用，ER 模型则不太合适

符号总览

UML

  • UML：Unified Modeling Language
  • UML 图谱系
    • 用例图（use case diagrams）：用户和系统的交互
    • 顺序图（sequence diagram）：用例中活动者与系统其它模块之间交互的时间顺序图
    • 状态图（state diagram）：系统中不同对象的行为
    • 行为图（activity diagram）：说明行为是如何协同的
    • 协作图（collaboration diagram）：描述组成一个复杂系统的不同对象之间的交互（即，消息交换）

从 ER 模型到 UML