表里两行讲的是同一条关系，但观察起点不同。上面一行约束每笔 payment 都要找到所属 reservation，下面一行让同一 reservation 接住多笔 payment。max 与 min 混着猜时，常见结果是 N 画对了，mandatory 仍然画错；拆开判断后，每个符号都有一句业务规则可以对应。

min 还要和 FK 的 NULL 规则一起看。比如项目任务创建时允许暂不分配负责人，负责人 FK 可以是 NULL，min 就是 0；系统要求记录插入时绑定负责人，FK 不允许 NULL，min 就是 1。这里改变的是参与下限，max 仍由可关联的数量决定。🪄

🔗 cardinality 站稳后再放 Foreign Key

cardinality 写清以后，再决定两张表怎样引用。Golf Pass 结构中，reservation 是 one 端，payment 是 many 端，因此 payment 表新增 Reservation ID 作为 Foreign Key，指向 reservation 表里的 Primary Key。外键跟着 many 端走，每一笔付款便能自己说明归属。

这一顺序也会直接影响文字解释。只写「新增一个 Reservation ID」只交代了改法，原因仍然悬着；把 cardinality 接在前面，因果就完整了：一个 reservation 对应多笔 payment，每笔 payment 又只属于一个 reservation，于是引用放在 payment。✍️

• reservation 用一条记录保留预订本身；
• 定金和余款在 payment 表里各占一行；
• 两行都写入同一个 Reservation ID，关系就连回原预订。

如果把 Payment ID 塞回 reservation 表，一条 reservation 只能自然指向一笔 payment。为了装下第二笔又继续增加 Payment ID 字段，结构会随着付款次数反复改动，题目要求的一对多关系也没有落稳。🔍

✅ 回读政策，把图逐项验一遍

画完以后，回读政策比只盯着符号更容易发现偏差。放到 Golf Pass 里，可以先假设 payment 表已经有定金、余款两行；两行各自记录 Amount 和 Payment Date，Reservation ID 都指向同一个 reservation。然后按顺序核对：

1. 数量：同一预订可以对应多行 payment；
2. 属性：每笔付款独立保存自己的金额和时间；
3. 链接：每行 payment 都能沿 Reservation ID 找回所属预订。

这其实是在用两行 payment 反推结构。定金行和余款行同时存在时，one-to-many 得到验证；两行共享 Reservation ID 时，归属关系得到验证；各有 Amount 和 Payment Date 时，政策里的两次交易没有被压成同一组字段。三个观察点正好对应前面的数量、外键与属性。

这三项一一成立，业务里的分期付款动作就在结构里有了位置。反过来，如果金额仍挤在 reservation 的固定字段里，或者 payment 没有 Reservation ID，图形即使看起来完整，也接不住原来的政策。🧠

🧪 一张改造后的 ERD，要让每个业务动作落成独立记录，也要让每条记录沿 FK 找回所属对象。

⏱️ 把三步练成一条作答链

往期 Section A 的 small case study 曾把 database structure、ERD、SQL 和 Python 放在同一段。复习 ERD 这一块时，我会连续练同一条依赖链，少把时间拆给孤立的符号记忆。拿到一条新规则，草稿先留下这四个检查点：

练习时不用一口气画出精致 ERD。先写两句数量关系，再标 one、many、optional 和 mandatory，最后补 PK/FK；每完成一个动作，就用一句话解释它从哪条政策而来。这样图和文字互相对照，偏差会更早露出来，复习也会集中在推理链上。

• 业务规则里的数量词已经圈出；
• 两个方向的 (min, max) 已经写明；
• one 端与 many 端已经确定，FK 放在 many 端；
• 新结构已经按原政策回读一遍。

这套顺序的好处很直接：前面的数量判断会继续支撑后面的图、字段和文字解释。🎯 每轮练习只换一条业务规则，再完整走完读政策、定 cardinality、放 Foreign Key 和回读验证，遇到新 case study 时就有一条可以立即落笔的路线。

📚 这份 2026S1 往期资料参考预览只演示往期 ERD 拆题动作，2026S2 本学期的考试安排请以学校正式发布为准。