综述
假定为一个B2C的电商公司
对于一般的零售或者生产公司来说，订单/采购单收入和成本的最大来源。本章主要讨论如何建立一个通用的销售订单和采购单模型
原文见：数据建模3-订单
逻辑模型
订单相关业务过程如下：
一般情况下，一个B2C的平台的采购->销售流程大致如下
平台提出采购意向
-
对于B2C的电商平台，遇到缺货或者新采购商品的时候，会在内部系统内提出采购意向，系统将多个采购意向合并，向供应商询价，准备采购
平台向供应商询价，供应商给平台报价，双方议价
-
报价不是一次性的，存在询价<->报价的多次反复的过程，并通过谈判最后确定价格
平台向供应商采购
-
价格谈拢后，平台向供应商采购，并记录采购单
配送入库
平台定价
-
平台定价分两种情况
自主定价，这种是平台自己根据业务情况制定商品价格，相对比较复杂，不同的地区、消费者都可能不同，同时还存在各种促销活动、消费券等影响实际定价。
协议定价：这类往往是供应商前期有要求，根据制定的协议进行定价。
消费者向平台下订单
-
如果平台具有自动合单功能，那么会存在父订单子订单的概念。比如在淘宝上在多家店同时下单购买商品，此时系统会生成一笔父订单，同时给每个店铺的订单单独生成一笔子订单，这些子订单挂在父订单下，消费者可以一并支付
平台给消费者配送
-
配送相对比较复杂，分快递配送、前置仓配送和自提，复杂度依次降低
快递配送的话会涉及到集单路由等问题，详细见下一章
消费者客诉单
-
当发生纠纷时候，可能产生客诉单
主要包括退货换货等
客诉单往往会有滞后性，时间从一两天到几个月不等
关系型数据库模型
抽象看模块大致如下：
数据库核心表如下：
采购意向
-
采购意向表
-
主键为采购意向单ID
存储采购意向单的基础信息，负责人，创建时间，件数，预算金额，状态等
状态发生改变的时候更新日志表
采购意向明细表
-
主键为采购意向单ID和明细ID（也可以是SKUID）
一个意向可能有多个明细条目，每个条目记录对应的SKU需要采购的明细信息，数量，要求等等
采购意向日志表
-
主键为伪主键ID
主要记录采购意向的各种变更记录，特别是状态变更记录
采购
-
采购表
-
主键为采购单ID
存储采购单的基础信息，负责人，供应商ID，创建时间，件数，预算金额，状态等
状态发生改变的时候更新日志表
采购明细表
-
主键为采购单ID和明细ID（也可以是SKUID）
一个采购单可能有多个明细条目，每个条目记录对应的SKU采购的明细信息，数量，要求等等
采购日志表
-
主键为伪主键ID
主要记录采购单的各种变更记录，特别是状态变更记录
报价
-
报价表
-
主键为SKUID+供应商ID
存储的是当前每个SKU在不同供应商处给出的价格
历史报价
-
主键为伪主键ID
逻辑主键为时间+SKUID+供应商ID
存储过去供应商的每一次报价记录
订单
-
订单表
-
主键为订单ID
存储订单的基础信息，买家ID，卖家ID，创建时间，件数，预算金额，状态等
状态发生改变的时候更新日志表
订单明细表
-
主键为订单ID和明细ID（也可以是SKUID）
一个订单可能有多个明细条目，每个条目记录对应的SKU订单的明细信息，数量等等
订单日志表
-
主键为伪主键ID
主要记录订单的各种变更记录，特别是状态变更记录
定价
-
定价表
-
主键为SKUID+地区ID
存储的是当前每个SKU在不同地区的定价
定价变动表
-
主键为伪主键ID
逻辑主键为时间+SKUID+地区ID
存储过去SKU的每一次价格变动记录
协议
-
协议表
-
主键为协议ID
存储协议的基础信息，负责人，创建时间等
状态发生改变的时候更新日志表
协议项目
-
主键为协议ID和项目ID
一个协议可能有多个明细条目，每个条目记录对应协议的细项，比如SKU，比如协议定价等
协议变动表
-
主键为伪主键ID
主要记录协议的各种变更记录，特别是状态变更记录
离线数据仓库模型
采购意向
-
采购意向单
-
主键为采购意向单ID
分区字段为DT，增量表
存储采购意向单的基础信息，负责人，创建时间，件数，预算金额，状态等
状态变更的存储有几种方法
-
-
列转行：将不同的状态类型和变更时间转换为字段一一罗列在表中，如果没有进入该状态，则字段为空。表为以创建日期为分区的增量表。
-
-
-
-
优势：结构简单清晰， 使用方便，读写性能较高
劣势：当状态列表产生变更的时候需要变更表结构，变更麻烦
适合于状态清晰稳定的业务
拉链表：对修改时间进行拉链，表结构如下图，使用的时候需要进行解拉链
优势：鲁棒性强，对系统状态类型不稳定，不断变更的情况，兼容成本相对更低，遇到变化只需要刷数据即可，无需改表
劣势：使用不便，由于每个单子在每次状态变更的时候都会复制一份，且会横跨多个日期分区，这种设计的主键需要解拉链后方为采购意向单ID，可以将解拉链逻辑包装为视图，使用起来会相对方便一些。但是读取性能会大幅下降。
快照表：订单类表保存历史信息不建议使用快照模式，空间占用过于离谱
-
-
采购意向明细
-
主键为采购意向单ID+明细ID（或者SKUID）
分区字段为DT，增量表
采购
-
采购单
-
主键为采购单ID
分区字段为DT，增量表
状态变更参考上文的采购意向表
采购单明细
-
主键为采购单ID+明细ID（或者SKUID）
分区字段为DT，增量表
报价
-
报价快照表
-
主键为SKUID+供应商ID
分区为日期，全量快照
由于正常情况下报价记录并不会非常多，一般情况下都是使用快照的方式
一般情况下，报价并不会以天为单位，经常会有一天好几次报价的情况，特别是议价的时候。所以还需要使用报价日志，辅助记录中间的变化。
当然也可以不设计快照表，设计为拉链表，此时拉链的时间字段需要精确到秒级，不能以常用拉链表的天级别时间字段
报价日志
-
逻辑主键为SKUID+供应商ID+报价时间，物理主键为ID
分区为日期，增量表
可以用来还原快照信息，如果想要更精确，快照表可以基于报价日志生成，不在依赖数据库日志，这样可以做到逻辑上的绝对精确
订单
-
订单表
-
主键为订单ID
分区字段为DT，增量表
状态变更参考上文的采购意向表
订单明细表
-
主键为订单ID+明细ID（或者SKUID）
分区字段为DT，增量表
定价
-
定价快照表
-
主键为SKUID+地区ID
分区为日期，全量快照
由于正常情况下定价记录并不会非常多，一般情况下都是使用快照的方式
一般情况下，定价会有一天好几次调整价格，所以还需要使用定价日志，辅助记录中间的变化。
当然也可以不设计快照表，设计为拉链表，此时拉链的时间字段需要精确到秒级，不能以常用拉链表的天级别时间字段
定价日志
-
逻辑主键为SKUID+地区ID+报价时间，物理主键为ID
分区为日期，增量表
基于数据使用的应用层设计
运营&业务
在订单领域中，运营和业务同学往往聚焦在
向老板每天或者每个月汇报
分析各类营销活动、
分析各类商品的销量和用户喜好
基于以上的诉求，我们可以提供的是
根据业务报告需求设计的日周月报表
-
报表格式能够让运营同学快速生成报告
指标口径经过严格管理
各种时间粒度的分析报表，支持自定义分析
-
提供各类维度：组织、城市、区域等等
指标口径经过严格管理
数据科学家/BI
在订单这个领域中，商分
基于汇总或者明细报表进行写SQL或者EXCEL分析业务现状，进行未来预测，提供分析报告，并给老板进行汇报
根据业务和基础数据，制定指标口径，选择能够真实反映业务的指标
设计画像标签，制定关键指标
做复杂逻辑的数仓衍生系统，比如绩效管理
基于以上的诉求，我们可以提供的是
基于维度建模的明细大宽表，方便分析师进行分析
各种时间粒度的分析报表
-
提供各类维度：组织、城市、区域等等
各种标签系统，比如用户画像，商品画像，用于
-
主键是快照日期+产品ID
结构
见前一章节
管理层
对于管理层来说：
接收商分、运营和业务进行的各类定期日周月报和专题分析报表
一个可以上卷下钻分析进行分析的经营大盘
基于以上的诉求，我们可以提供的是
一个具有交互能力且直观清晰的管理大盘，包含管理层关心的所有指标，并有合理的分类
算法
算法在订单领域的诉求往往是各类标签，便于后续分析
描述用户喜好的用户画像，可以用来后期进行推荐
基于历史订单的商品画像，可以用来进行销量预测或者商品推荐
基于以上的诉求，我们可以提供的是
标签系统，类似用户画像
-
结构和设计见上文
小结
对于一个B2C的公司，左手采购单，右手销售订单，组成了这个公司的核心数据。基于这些订单数据，可以分析市场偏好、活动效果等等，也可以用于分析公司的经营情况。因此我们的订单模型，既要能够提现订单中的各种信息，也要提现出订单的变化情况，将其清晰完整的记录下来。