实战开发O2O在线交易系统—系统E-R图设计（共4节课）

这门课的主题很明确：围绕一个 O2O 在线交易系统，把 E-R 图从需求描述推到可用的数据库设计。全课只有 4 节，不铺垫编程语言基础，也不讲框架搭建，重点落在实体识别、联系刻画、主外键落位和范式取舍这几件事上。对于正在做软考（尤其是数据库系统工程师方向）或者手头有一个交易类项目要设计库表的开发者，它更像一份可以对照着画的练习册。

课程切入的技术点

O2O 交易系统的数据模型有几个天然难点，这门课基本都碰到了：用户与商户是两类主体，订单既要挂到用户又要挂到商户，商品与门店存在归属关系，支付、退款、优惠券又会派生出一批弱实体和联系实体。E-R 图设计要处理的就是这些多对多、一对多以及带属性的联系。课程围绕这些场景展开，会涉及实体集与属性集的区分、联系的多重性标注、弱实体与依赖联系的画法，以及后续向关系模式转换时的主键与外键推导。

资料里提到 Oracle，可以理解为课程在示例中会落到具体的关系数据库语境，而不是停留在纯理论符号。E-R 图最终要能映射成建表语句，这一点对做工程的人比背概念更重要。

项目结构上的可复用部分

虽然只有 4 节，但它的组织方式是可以拆开复用的。第一层是需求到实体的抽取，即从一段业务描述里圈出名词性概念并判断哪些该建模成实体、哪些只是属性；第二层是联系设计，处理交易系统里最典型的用户—订单—商品—门店链路；第三层是图形规范与转换，把画好的图落到关系模式；第四层是复核，检查是否存在冗余联系、是否满足业务约束。

• 实体抽取的判定标准，可以直接套用到其他电商或本地生活类项目；
• 联系多重性的标注方法，是软考案例题和下午题的高频考点；
• E-R 图到关系模式的转换规则，属于可迁移的通用技能，换项目仍适用；
• 约束与范式检查的思路，能帮你避免后期改表。

如果你正在自己设计一套订单或交易相关的库表，可以拿这门课的推导顺序当检查清单，把自己画的图逐条过一遍。

与软考的关系

软考数据库方向对 E-R 图的考查集中在两块：一是给出业务描述要求画出 E-R 图并标注联系类型，二是把 E-R 图转换成关系模式并指出主外键。这门课用 O2O 交易系统做载体，正好覆盖这两类题型。相比纯刷题，带着一个完整业务场景去画，更容易记住多对多联系为什么必须拆成独立关系、弱实体的主键为什么依赖强实体。建议每节课后先自己画一遍，再对照讲解修正，比直接看答案有效。

建议的学习方式

4 节课容量不大，不建议连着看完就放下。可行的做法是：第一节看完先自己列一遍系统里可能出现的实体；第二节动手标联系和多重性；第三节尝试独立完成到关系模式的转换，写出主键外键；第四节用来做交叉核对和查漏。全程准备一张纸或一个建模工具，边看边画。

学完后最好把这份 E-R 图和转换结果整理成一份技术笔记，注明每个设计选择的理由，比如某个联系为什么设成弱实体、某个属性为什么单独建表。这类记录在面试或软考复习时比视频本身更有用，因为它记录的是你的判断过程。对于要动手建库的人，这份推导结果可以直接作为建表前的设计草稿。