订单管理

天之衡

1.订单管理总体矩阵

2.订单事务

事实表规范化

一些设计者更希望进一步规范化事实表,保留单一的、通用的事实数量以及维度,用于区分度量类型。在此场景中,事实表粒度是每个度量每订单明细一行,而不是更自然的每个订单明细事件一行。度量类型维度指明事实是总的订单数量、订单折扣数量,还是其他度量。在事实集合非常巨大时,该技术具有意义,但是给定事实行呈现出稀疏的状态,且没有事实之间的计算结果。可以使用该技术处理制造质量测试数据,其事实变化依赖实验。(什么意思没明白??我理解为为了计算的简易型和通用性来建表而不是业务本身,这个操作会造成数据的稀疏性??怎么造成的?可能作者的意思是指标之类的)
维度角色扮演

现在有两种唯一逻辑日期维度可使用,好像它们独立于完全不相关的约束。这种情况被称为角色扮演,因为日期维度同时被当成单一事实表中的不同角色。(又没懂???,作者可能是说如果这张日期维度表被其他两张维度表都关联了,且日期表在这两张维度连接的逻辑的不同,那么为了避免混淆应该给日期维度表取一个别名)

重新审视产品维度

产品维度表的特征
大量冗长的、描述性的列
一个或多个属性层次,加上没有层次的属性
重新建立操作型产品代码到代理键的映射
增加描述性属性以扩大或替换操作型代码
检查属性值,确保没有拼写错误、不可能存在的值、多变量等
将属性定义、解释、元数据来源文档化
客户维度

处理长尾可变递归关系
当实体之间存在固定的、不随时间变化的、强关联的关系时,它们应该被建摸到单一维度中。大多数情况下,当实体被划分为两个不同的维度时(记住关于太多维度的一般性准则),设计将会更简单且方便管理。如果在您的模式中已经包含有25个维度,则应该考虑尽可能合并这些维度
单事实表和多事实表

应用于客户/代理分配的无事实的事实表

交易维度

针对订单号的退化维度

虽然订单事务明细项可能没有参与分析的目的,但它可作为另一种可能在主键中具有潜在作用的退化维度包含在事实表中,包含与操作型系统记录连接的主键。在此情况下,明细项粒度事实表的主键可能是订单号和列表号。有时数据元素属于订单本身并且不能自然地划分到其他维度表中。面临这样的情况时,订单号不再是一种退化维度,而是一种具有自己的代理键和属性的标准维度。
杂项维度

杂项维度是对低粒度标志和指标的分组。通过建立杂项维度,将标志和指标从事实表中移出,并将它们放入到有用的多维框架中。

应该避免的表头/明细模式

不同粒度的事务事实表

另外一种需要避免的表头/明细模式

3.发票事务

作为事实、维度或两者兼顾的服务级性能

除了定量服务度量,也可以通过增加新维度或在杂项维度上增加更多列来包含对性能的定性评价
利润和损益事实

(作者说非常牛逼,我感觉就是大学初会的内容......)

• 发货数量:特定明细项的产品数量。使用多种带有不同度量单位的相等数量的方法
  
• 扩展总金额:也称为扩展列表价格,因为它是用发货数量乘以列表单位价格得到的。这些以及随后的美元值是扩展的金额,换句话说,就是单位价格乘以发货数量。这种有关可加值的坚持简化了大多数查询及报表应用。相对来说,商业用户很少要求在单一事实表行中包括单位价格。当用户希望得到多行平均价格时,扩展价格首先相加,然后用相加获得的结果除以总的数量。
  
• 扩展津贴额:从发票列表总额减去与某个交易有关的所有津贴的数量。该津贴在相邻交易维度中描述。津贴额通常被称为发票之外的津贴。对给定明细项来说,·实际发票可能包含几种津贴。津贴合并到一起成为一种简化版本。如果需要根据津贴的不同来源分别跟踪,并且在给定明细项中潜在包括多种同时津贴,那么津贴细节事实表会扩展发票列表事实表,实现在发票列表事实表中下钻津贴细节
  
• 扩展折扣额:从总量减去支付项折扣。折扣描述符建立在交易维度中。如前有关,交易维度的讨论,同时描述津贴和折扣类型的决策是设计者的权利。如果津贴和折扣是相关的,并且商业用户希望在浏览交易维度以研究津贴与折扣之间的关系时,这样做是有意义的
  
• 扩展净额度:客户期望在完税前支付该明细项的数额。它等于净发票额减去津贴和折扣。
  
• 扩展固定制造成本:制造与订单列表的固定制造产品成本的比例值。
  
• 扩展可变制造成本:将制造作为发票列表产品的可变制造成本的数值。该值多多少少是基于活动的,反映了运输到客户的产品生产制造的实际位置和时间。相反,该值可能是由行业制订的标准值。如果制造开销或所有其他存储和分销开销是平均值的均值,则详细的损益表可能会变得没有意义。DWBI系统可以协调这一问题并加快采纳基于活动的成本方法
  
• 扩展存储成本:在发送给客户前,存储发票明细项收取的费用。
  
• 扩展分销成本:发票的明细项从制造场所到发送场所收取的费用。该费用不是基于活动的。如果公司支付运费或运费可以被表示为损益表中的不同明细项,则分销成本可能包括给客户的货物
  
• 出资额(贡献额):扩展发票净值减去以上讨论的所有成本。该值并不是整个公司的最终结果,因为总体费用和管理成本以及相关财务调整尚未计算。但该值仍然非常重要。该列有时用其他列表示,例如,利润,选用哪个值表示与公司的规定有关。
  

审计维度

4.用于订单整个流水线的累积快照

累积快照事实表通常包含多个日期,表示过程中的主要里程碑。但是,仅仅因为事实,表具有多个日期并不能表明它就是一个累积快照。累积快照主要的区别是在活动发生时重.新访问事实表行。
延迟计算

日期列的长列表获取订单通过整个流水线处理过程的时间范围。这些日期中的任意两个日期的数字差别是一个可用来对整个维度执行平均计算的数字。这些日期延迟计算表示总体效率的基本度量。可以基于该事实表建立一个视图,用于计算大量的日期差异并展现它们,好像它们已经存在于基础表中一样。这些视图列可能包含诸如制造完成延迟、制造完成到成品滞后、订单发送滞后等订单度量,通过被组织监视的日期范围获得。
多种度量单位

有时,业务中的不同功能组织希望查看一些以不同度量单位表示的性能度量。例如,制造经理可能希望按照托盘或装运箱查看产品流。另一方面,销售和市场经理可能希望按照零售示例、扫描单位(销售包)或等价的消费单位(例如,单罐苏打水)查看零售数量。
可以采用度量转换因子来实现,与其采用在维度表中设置转换因子,承担错误地计算等价数量的风险,不如将它们存在事实表中

将所有事实和转换规则包装到同一事实表行中,为正确地使用相关因子提供了最安全的保障。转换的事实以视图的方式展现给用户
最后,在事实表中存储这些因子的另外一个好处是减少了产品维度表建立新产品行以反映转换因子的修改的压力。这些因子,特别是如果它们经常随时间改变,那么其表现更像事实而不是维度属性
超越后视镜

由关注分析产品历史变化性能的有效方法。转向过去的性能无法保证得到未来的结果。分析影响订单建立的关键驱动因素。

用于订单管理过程的总线矩阵片段
订单事务模式
事实表规范化的思考
维度扮演的角色
发货/发票客户维度的考虑
确定是单维度还是多维度的因素
用于多方面标识以及指标的杂项维度及其他设计
有关退化维度更多的考虑
多种货币单位的度量
处理包含不同粒度的事实
避免表头及明细项事务的模式
包含利润和损失事实的发票事务模式
审计维度
服务级性能的定量测量与定性描述
作为累计快照模式的订单实现流水线
滞后计算

来源：https://www.jianshu.com/p/f86f2e8db341
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！