从需求走到全局 E-R 图

需求分析的产物进来，全局 E-R 图出去，中间五步。

试一试一步步往下走

往下走 下一步 重来

1. 需求分析，交出数据流图和数据字典
2. 数据抽象，分出局部视图
3. 一个视图画一张局部 E-R 图
4. 视图集成，把局部图合起来
5. 消冲突消冗余，得到全局 E-R 图
6. 交给逻辑结构设计

重　点

先各画各的局部图，再合起来，从来不是一口气画一张大图。

想一想

为什么不干脆一次画完？

按业务线、按使用部门、按人的角色，三种切法挑一种。

重　点

切的标准只有一条：切出来的每一块，一个人管得过来。

分清楚三种切法

按什么	举例
关键业务	采购、销售
使用部门	采购部、销售部
使用角色	顾客、管理员

知道更多

案例走的是第二种，采购部一张图，销售部一张图。

两条判据：有没有更细的描述，要不要跟别人连线。

试一试点一行判一判

点一行，看这个东西该画成什么

需求里是这么说的	画成

重　点

只要它自己带着描述信息，或者要跟别的实体连线，就得是实体。

上机做

上机二第 1 题　当属性会怎样

想一想

系别在教务系统里该画成哪个？

一次全合，还是两张两张地合，看局部图有几张。

重　点

图少就一次全合，图多就两张两张来，合完的当成新的一张接着合。

打个比方

十个人的账要对，可以围一桌一起对，也可以两两对完再往上并。

知道更多

二元集成法每一轮只面对两张图，冲突少，实际项目里用得更多。

合起来只是第一步，后面三步都是在擦屁股。

试一试三种冲突挨个看

哪种冲突 属性冲突 命名冲突 结构冲突 合完的样子

采购部和销售部各画各的，同一批商品两个说法

采购业务局部图	销售业务局部图

重　点

属性冲突改类型，命名冲突改名字，结构冲突取并集。

上机做

上机二第 5 题　消命名冲突

记牢它四步

1. 先合起来
2. 消三种冲突
3. 消冗余
4. 验一遍范式