第五章 订单管理

订单管理由几个关键性业务处理组成，其中包括订单、货运与发票处理等。这些处理蕴含着诸如销售量与票据收入之类的重要来务度量值

1.         订单管理

多个源系统的存在通常在一定程度上剧了对数据仓库中相差悬殊的结果进行集成的压力。

自然的粒度是为订单的每个分列项给出一个记录行。与该处理联系在一起的事实一般包括订购量、订单增值总额、订单贴金额与订单增值余额

1.1.        事实的规划化

一般情况下并不赞同对事实表进行进一步的规范化处理。

1.2.        维度的角色模仿

每个事实表中都有日期维度，这是由于总需要通过时间来查看性能的原因。每个日期都应该是事实表的一个外关键字。不过并不能简单地将这两种外关键字连接同一个日期维度表上。SQL 会将这两路同时加入的连接解释成要求两个时间是相同的，而实际上这不大可能。

不能按字面意思连接到单个日期维度表上，但可以在后台创建和管理单个日期维度，原因是可以通过使用视图来创建两个独立日期表的映像。称为角色模仿“role-playin”

1.3.        产品维度

         大量冗长的描述列

         在许多非体系属性之外，存在一个或者多个属性体系结构。认为产品属于单一体系结构怎么也说不过去（比如，产品，分为消费人群、原料分类等）。产品一般都是按照多个定义的体系结构图而堆积成的。所有的体系内的数据都应该在单个平面型退化产品维度表中展示出来。我们不提倡为产品维度创建经过规范化处理的雪花状子表。较为复杂的展示与较慢的维度浏览性能所付出的代价，要比节省一点点存储空间而带来的好处大得多。认为在小型维度进行浏览可以使所有关系便于想像或者显得直观的想法是错误的。

         注意：

n         装操作型产品关键字重新映射为代理关键字

n         所有文字串都应该经过通认，以保证不会存在拼写错误，不可能的值或同一值属性的不同包装版本。

n         装产品属性定义、解释与来源等整理成数据仓库的元数据材料

1.4.        收货顾客维度

虽然收货地址只是空间的一个点，但是围绕这一点，可以通过嵌套比较大的地理实体而定义任意数目的地理体系，美国，通常的地理体系由市、县、州组成，美国的ZIP编码还另外确定了一套地理细目分类。ZIP 编码第一个数字标识美国的地区，而ZIP编码前三位数字标识一个区域中收。

       一个维度同时支持多个不相关的体系，是非常自然而常见的事，特别对面向顾客的维度来说更是如此。这些体系可能具有不同数目的层次，每个数据仓库提供在每个层次范围内进行的上下探查操作

注意：

       如果营销代表与收货顾客独立地参与了其他业务处理事实表。那么应该分开地保存这些个息。

       当实体之间存在固定的、不随时间变化的、强烈相关的关系时，显然应该将它们当做一个单一维度进行建模。

       事实表是为了表示维度这间的相关性而专门创建的

1.5.        交易维度

交易维度（deal dimension）描述已经提供给顾客，并且在理论上能够理影响他们购买产品愿望的激励因素。这种维度也做契约（contract）,交易维度对适合于特定订购分列项的期限、打折、奖励的全部组合。

在零销促销维度中遇到的同样问题也在这种交易维度中出现了。如果打折、奖励、期限之间存在有用的相关性，那么将它们封装到单个交易维度中就显得很有意义。

1.6.        订单编号退化维度

退化维度一般是为了操作型事务标识而保留的，这不能成为要在事实表中用意义模糊的编码，而不连接维度表的描述性解释内容的借口。

1.7.        杂项维度

杂项维度是对典型的低基数标志与指示符进行分组的简便方法。通过创建一个抽象的维度，可以将标志从事实表中删除掉，并同时放到一个有用的维度框架中去。

1.8.        多种流通货币

将订购事务同时用当地货币与诸如本例中的美元之类的标准通用货币表示出来，为满足这种需要，应该将每个基本订单事实用两个事实来代替，其中一个用于本地货币，另一个用于等值的标准通用货币

由于货币和国家不是一对一的关系，因此，访事实表的维度表示货币而不是国家，通常采用专门的货币兑换表。

在事实表中就存储这两个货币兑换运算过后的度量值

1.9.        粒度不同的标题分列项事实

设计人员首先做出的反应是力图强制所有事实都处于最低层次上。要尽力对“父－子”关系进行拓展，以使处于子层的所有行将在较高的父层上获取的事实包括进来。这个过称被广泛地做分配处理“allocating”。

假如需要通过包括产品在内的所有维度，对全部订单事实进行分割与堆积处理能力，那么将父订单事实分配到子分列项层，是具有决定性的意义的。

也就是说把主表的时间、店铺、等信息分配到各产品销售情况的明细表中。

              不应在单个事实内混用事实粒度（订单与订单分列事实）相反，要么将更高层次上的事实分配到一个更具有细节性的层次上，要么创建两个单独的事实表来处理不同粒度的事实。

1.10.     发票事务

发票具有多个分列项，每个分列项对应于一项具体装载的产品。各分列行标有不同价格、贴现与打折等内容，同时，发票上还给出了分列项的增值总额。

       对于任何为顾客装货或者给顾客开服务报销单的公司而言，从发票开始实施数据仓库一般都是最理想的，通常将票据处理得到的数据看做是最有效能的数据库，其原因在于它将公司的顾客、产品、利润要素组合在一起了。

       可以选取单项发票分列项作为发票事实表的粒度

       只要单个订单编号与每个发票分列项相关，就可以得到一个退化订单编号，以及一个发票编号退化维度。

1           订单任务流水线累积快照

累计快照增补了另外一种流水线的情景。如果对平解诸如订购、生产与装运数量这样的经过流水线的产品数量感兴趣，那么就需要依赖每个流程进行监控的事务结构方案了。

累计快照有助于更好理解订单的当前状况及产品移动速度，从而确定流水线的瓶颈和无效之外。

累计快照与其他事实表之间的基本不同表现在，当更多的信息变得可用时，重新存取与更新现有事实表的行方面，累积快照料的粒度是进入流水线时获取的每个最低细节层次给出一个记录行。

累积快照在事实表中一般都具有多个表示主要处理环节的日期。不过，仅仅因为事实表具有几个日期尚不足以确定它就是一个累积快照

累积快照有助于用户理解生产能力与产量。如果累积快照的粒度是针对序列号或者批号给出的，那么取散值的产品通过生产与检测流水线时，其分布情况也就显示出来，累积快照最适合于进行具有明确起止时间的短期处理应用，而诸如银行账户这样的长期处理应用采用周期快照事实表进行建模会更好些

2                  多个计量单位

有时，业务范围内的不同职能机构想看到不同计量单位表示的相同性指标。由于转换因子随时间的可能发生变化，使应用情形进一步复杂化，因此，用户还需要在给定时间点确定一个因子是否变化。

转换因子放在维度表中要担当对等值数量的不当计算方面的风险，所以应该将存放在事实表中；

将所有事实与转换因子放在一个事实表行，为这些因子的正确使用提供了最安安全的保证。被转换的事实在视图中展示给用户。

3           事实表比较

数据仓库方面存在三种基本类型的事实表：事务、周期性快照与累积快照

特征	事务粒度	周期性快照	累积快照粒度
代表的时间段	时间点	规律性可预见间隔	不确定时间跨度、一般是短期
粒度	每个事务事件一行	每段一行	每个生命周期一行
事实表加载	插入	插入	插入、更新
事实行更新	不重新存取	不重新存取	行为发生任何时候都要看重新存取
日期维度	事务日期	时间段终止日期	标准关键环节的多个日期
事实	事务活动	预定时间间隔的性能	给定生命期的性能

3.1          事务事实表

事务数据通常很容易构成一个维度框架。最底层的数据由于不支持在汇总性数据之上进行的分析而成为最自然的维度数据。事务层数据使用户可以对事务行为进行特别详细的分析。一旦事务被提交，一般就不能再重新对它进行存取了。

3.2          周期快照事实表

与针对每个出现的事件要加载一行的事务事实表不一样，利用周期快照可以在每天、每周或者每月结束时，为当时的行为进行拍照（这就是快照术语的由来）然后在下一个周期折另一张照片。周期快照被连续地堆积在事实表中，周期快照事实表经常是容易地检索关键业务性能指标的、可预见的、有规律的趋势视图的惟一地方。

3.3          累积快照事实表

累积快照几乎总是具有多个代表出现在一个生命周期区间内的，可预见主要事件或者环节的日期标记。

事务与快照就是维度数据仓库的阴与阳。事实伴随快照事实表一起使用，就能提供业务方面的完整视图。