用订单交付主题理解四个决定
Kimball Group 将维度模型设计概括为业务过程、粒度、维度和事实四项决定。下面是一个用于需求讨论的示例,实际字段与规则需结合企业数据确认。
| 决定 | 订单交付示例 |
|---|---|
| 业务过程 | 分析已接受订单的交付情况 |
| 事实粒度 | 明确按订单行、发货明细还是某日状态记录 |
| 分析维度 | 工厂、客户、物料、承诺日期与实际日期 |
| 事实与度量 | 订单数量、交付数量与延迟天数的计算基础 |
粒度不一致,数字可能被重复计算
一个订单行可能分多次出库,库存又可能按库位与日期记录。把这些明细直接连接,可能使订单数量被重复累计。应先定义分析问题需要的粒度,再选择汇总或关联方式。
每日库存属于时点快照;把一个月每天的库存简单相加,通常不能代表月末库存。每个指标都应明确沿时间和组织等维度如何汇总。
公共维度让多个主题能够比较
采购、生产和销售往往需要共用物料与工厂,但源系统编码可能不同。先建立映射,确认计量单位和组织层级,再决定历史名称或组织变化如何处理。只有名称相同,不足以证明数据可以直接合并。
配置化工具减少重复工作,业务判断仍需确认
PackEDW 产品资料说明了维度、指标、分析模型与取数逻辑的配置能力。模型设计时,业务负责人确认规则,技术人员核对字段、转换和性能,再用源系统记录对账。工具帮助承载这些决定,不能代替决定本身。
第一次建模讨论的输出
- 一个明确业务过程和不含歧义的事实粒度。
- 公共维度及来源编码映射。
- 指标公式、统计范围、责任人和样例结果。
- 源字段、转换规则、刷新时间与异常处理。
常见问题
维度和指标有什么区别?
维度提供观察业务的角度,例如工厂、客户和日期;指标表达要衡量的业务结果,例如交付数量或按约定公式计算的交付率。
建模是否必须从所有业务数据一起开始?
可以先选一个业务主题,用可复核样例完成模型和口径验证,再逐步复用公共维度扩展其他主题。
资料与依据
产品范围以具体版本和项目评估为准。案例说明保留原始资料的范围与状态,方法示例不代表客户实际经营数据。
- Kimball Group:维度模型的四步设计过程
一般建模方法,不作为派可产品功能或项目效果的证明。
- 派可数据:PACK BI 平台能力
公司发布的产品说明;模块与部署范围按具体版本及项目确认。
