请使用支持现代 CSS 与 JavaScript 的浏览器播放课件
DBPA · 7.2

概念结构设计与 E-R 模型

根据用户需求建立可讨论、可集成的业务结构

VER. 2608.2 Built with impress.js
DBPA | CH07 | 7.2

学习目标

概念结构设计把用户需求组织成可讨论、可转换的业务模型

  1. 01区分概念模型与逻辑模型，解释概念模型的四个质量要求
  2. 02根据业务语义识别实体、属性和码，并判断何时建为实体型
  3. 03判断二元、递归或多元联系的类型、基数和参与约束
  4. 04为联系放置联系属性
  5. 05根据图例解释 ISA、弱实体、Part-of 和 UML 的对应语义
  6. 06集成局部 E-R 图，判断可推导冗余及保留后的维护规则
2/15
LEARNING OBJECTIVES
DBPA | CH07 | 7.2 | 7.3

概念模型连接需求与数据模型

概念模型独立于具体 DBMS，却要能表达真实业务

真实且充分

概念模型真实、充分地反映对象、联系、约束和处理要求

易懂

概念模型能和用户共同讨论

易改

概念模型能随应用变化扩充

可转换

概念模型能转换为关系等数据模型

3/15
CONCEPTUAL MODEL
DBPA | CH07 | 7.2 | 7.3

一个业务对象何时应该建为实体型

判断对象是否有自己的性质、联系和生命周期

业务对象可作为属性的情形应作为实体的情形
专业学生只有一个专业标签支持主修、辅修和专业属性；专业有自己的码
职称只显示教师的文字标签需要描述工资和福利规则
教学班课程只有一个班时可作选课联系属性多班、排课和独立容量形成实体
先修课每门课至多一门直接先修课多门直接先修课形成课程—课程递归 m:n
Takeaway

在当前建模范围内，作为属性的对象不再单独描述自身性质，也不作为独立对象与其他实体发生联系

4/15
ENTITY OR ATTRIBUTE
DBPA | CH07 | 7.2 | 7.3

用业务语义确定联系基数

判断联系基数时，分别询问每一端实体最少和最多对应多少另一端实体

联系语义判定教务例子
1:1每一端的一个实体至多对应另一端一个实体学院与教师的“担任院长”
1:n一端的一个实体可对应多个，另一端每个实体至多对应一个学院与系
m:n两端的每个实体都可以对应多个学生与课程
联系结构二元、递归或多元，描述参与实体的结构课程与先修课程是递归联系
5/15
CARDINALITY
DBPA | CH07 | 7.2 | 7.3

E-R 图把语义放进三类元素

图形只是载体，码、联系属性和约束才是可执行的设计信息

学生、课程、选课和联系属性组成的 E-R 语义示例

实体型 Entity type

矩形表示一类可区分的对象

属性 Attribute

椭圆表示对象的描述项

联系 Relationship

菱形表示实体之间的业务事实

Takeaway

本图只展示学生—课程的二元 m:n 简化示例；矩形内属性是紧凑记法，学生码为学号、课程码为课程号，完整的 min..max 参与约束还需另行标注

6/15
E-R NOTATION
DBPA | CH07 | 7.2 | 7.3

联系属性描述的是一次关系事实

联系属性描述一个联系实例，而不是任一端实体的固有属性；多元联系不能任意拆成二元联系

联系联系属性为什么放在联系上
选课成绩、选课时间描述同一学生和课程组合的选课结果
讲授是否主讲描述教师与教学班之间的讲授角色
排课上课时间、教室由教室、教学班和时间片共同确定的多元事实
供应供应量描述某供应商为某项目提供某零件的数量
评价评价内容、教师反馈由学生、教师和教学班共同确定的三元事实
7/15
RELATION ATTRIBUTES
DBPA | CH07 | 7.2 | 7.3

基数与参与约束区分“可以”和“必须”

最少值到最多值同时说明参与次数的下限和上限

记法含义教务例子
1..1必须且只能参与一次系必须归属一个学院
0..N可以不参与，也可参与多次新学院暂时没有系
20..30参与数量被业务范围限制学生选修课程数
读法min=0 可不参与；min=1 必须参与，max 表示最多次数每个教学班 1..1 必须有课程
8/15
CONSTRAINTS
DBPA | CH07 | 7.2 | 7.3

按业务需要扩展 E-R 语义

扩展 E-R 语义只在业务确实需要时加入额外约束

父类—子类 ISA

本科生 ISA 学生；子类继承父类属性，也可以增加自己的属性。ISA 还要说明不相交/可重叠、完全/部分特化

弱实体型 Weak entity

教学班号只有在课程范围内才有意义；教学班依赖课程存在，课程号是所有者码，教学班号只是部分码

部分—整体 Part-of

汽车与车轮构成部分—整体关系；独占部分不能脱离整体，非独占部分可以独立存在

Takeaway

分类属性、不相交约束和完全特化进一步限制 ISA 的含义

UML 类图可以表达相近语义：类≈实体型、类属性≈属性、关联≈联系、PK≈码、multiplicity≈min..max、继承≈ISA；这些对应关系只用于语义转换，不决定 UML 的完整建模方法

9/15
EXTENDED E-R
DBPA | CH07 | 7.2 | 7.3

局部 E-R 图集成为全局模型

分图让不同业务小组能够在自己的语境中表达需求

  1. 01各局部分图按子系统识别实体、联系和属性
  2. 02合并局部图，消解命名、域和结构冲突，形成初步全局图
  3. 03修改并重构全局图，去掉不必要的冗余数据与联系，形成基本 E-R 图
10/15
LOCAL VIEWS
DBPA | CH07 | 7.2 | 7.3

局部视图不能直接拼接

冲突需要回到共同业务语义和用户协商

选课管理与教师教学局部 E-R 图经过冲突消解形成简化全局选课子图示意
冲突典型表现处理方向
属性冲突教学班号类型不同、出生日期精度不同统一类型、编码和单位
命名冲突同名异义或“项目／课题”异名同义约定全局名称
结构冲突职称是属性还是实体、属性集合不同、二元或三元联系回到业务语义重判抽象与联系
Takeaway

该图只展开全局模型中的选课子图；教师—讲授等其他非冗余联系未在图中展开，不表示它们被删除

11/15
INTEGRATION CONFLICTS
DBPA | CH07 | 7.2 | 7.3

基本 E-R 图保留事实，不重复推导事实

冗余分析依据数据字典、流程与依赖；函数依赖和最小覆盖只是辅助

设计判断教务例子处理
可消除已修可由合格选课和开课对应课程推出删除冗余联系
可保留已修课程学分支持高频统计保留派生属性并维护同步规则
Takeaway

保留冗余前要评估查询收益和维护成本；一旦保留，就必须承担一致性维护责任

12/15
REDUNDANCY
DBPA | CH07 | 7.2

用 E-R 语义组织概念模型

概念结构设计把业务事实组织成可讨论、可集成、可转换的模型

概念模型

概念模型作为共同语言，并满足四个质量要求

边界

划分实体、属性、码和联系属性

约束与扩展

表达基数、参与、递归、ISA、弱实体、Part-of 与 UML 语义

集成与维护

消解冲突，判断冗余并记录维护责任

Takeaway

基本 E-R 图为逻辑模式转换提供输入，并保留后续设计需要的码和约束

13/15
RECAP
DBPA | CH07 | 7.2

本节知识地图

14/15
KNOWLEDGE MAP
DBPA | CH07 | 7.2

本节问题

  1. 01在学生模型中，“一个主修”与“主修＋多个辅修”分别应建为属性还是实体？实体方案中“专业”的码是什么？
  2. 02学院—系、学生—教学班、课程—先修的最大基数和 min..max 分别是什么？
  3. 03成绩、是否主讲、排课时间各属于哪个联系？三元联系为何不能任意拆分？
  4. 04本科生／研究生、教学班／课程、汽车／车轮各适合 ISA、弱实体还是 Part-of？UML 如何表示？
  5. 05两个局部 E-R 图如何识别属性、命名和结构冲突，并按什么步骤合并？
  6. 06“已修”是否冗余？若保留“已修课程学分”，怎样维护一致性？
15/15
CHECK YOUR UNDERSTANDING