订单表里同时放客户地址和商品名称，查询看起来方便，修改时却会出现多个版本。范式首先解决的是事实重复保存的问题。
本文使用经典算法与关系数据库的纸面例题。复习时把概念放进一个可手算的小问题：先声明假设，再列状态变化，最后检查反例。题目中的边界条件往往比公式本身更容易失分。
1. 从现象推到机制
先确定一行代表什么，再写函数依赖。订单明细的候选键可以是订单号与行号的组合，商品名称依赖商品号，客户当前地址依赖客户号。历史成交价和下单时收货地址属于订单事实，不能因为“去重”而丢掉快照。
图中的四个节点分别表示业务事实、函数依赖、关系拆分、更新验证。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
把商品当前属性与订单历史属性分别列出来，再检查部分依赖和传递依赖。下面展示关系结构，不是直接可执行的建表脚本。
1
2
3
4
5
Customer(customer_id, current_address)
Product(product_id, current_name)
Orders(order_id, customer_id, shipping_snapshot)
OrderLine(order_id, line_no, product_id, sold_price)
key(OrderLine) = (order_id, line_no)
例题中的规模和耗时都是教学输入。先手算一遍，再用短程序核对；记录推导过程，避免只背住选项或最终数字。实际系统的性能不能直接从纸面复杂度推出。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 客户修改当前地址 | 旧订单地址快照保持不变 |
| 同商品出现在多个订单 | 当前名称只维护一处 |
| 一张订单含多行 | 订单号不能单独唯一定位明细 |
对照 1：客户修改当前地址
旧订单地址快照保持不变。观察时记录订单事实与客户主数据的归属。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：同商品出现在多个订单
当前名称只维护一处。观察时记录商品号对应的函数依赖。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：一张订单含多行
订单号不能单独唯一定位明细。观察时记录候选键是否覆盖真实粒度。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
规范化与读性能之间可以有取舍，但冗余字段必须定义同步或快照规则。不能在没有函数依赖分析时，看到重复文字就拆表。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“一张订单含多行”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
