把自然语言需求拆成关系表结构

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要把订单需求转成关系表，已有以下教学需求：每个订单属于一个客户；每个订单至少有一条明细；明细记录商品编号、数量和单价；订单可以有折扣，但没有说明折扣按行还是按订单计算。目标是先让业务关系可核对，再写数据库建表语句。

具体做法

1. 从需求列出实体、属性和关系，区分明确事实与推断。
2. 写出关系基数，例如一个客户可有多个订单，一个订单有多条明细，并列出未决的折扣范围。
3. 用已确认关系推导主键、外键和创建顺序。未决规则不悄悄变成字段默认值。
4. 检查模型和原需求一致后再生成 DDL；生成前说明采用的数据库方言。

反例

根据上述订单需求直接创建所有必要的数据库表，保证业务正确。把折扣字段也加进去，不需要列出假设。

改进写法

根据上述订单需求，先输出 Customer、Order、OrderLine 的属性和关系基数，标明每项依据。折扣按行还是按订单尚未指定，单列为待确认，不猜规则。提出主键、外键及建表依赖；确认折扣规则和数据库方言后，再基于这个模型生成 DDL。当前只交付模型与未决项。

为什么这样改

直接生成表会把没有确认的业务规则固化在列和约束里。中间模型让客户、订单和明细之间的关系先成为可审阅对象；把未知折扣范围单列，避免靠一个看似完整的表掩盖业务缺口。

如何验证

示意模型：Customer 1→多 Order；Order 1→多 OrderLine；OrderLine.order_id 指向 Order.id。折扣范围状态为待确认。

逐条把外键对应回已声明关系，并检查“至少一条明细”是否被单独记为需要实现的约束，而不是误以为普通外键已经保证它。未决项消失或外键没有需求依据时，模型不通过。

适用边界

中间模型不能替代业务确认。跨表数量规则可能需要事务或应用检查，DDL 能表达什么取决于数据库。表数量由业务决定，没有通用的三到七张表上限。原文未确认；相关方法可参照页面下方的需求结构化与模型验证链接。