数据仓库工具箱第三版——读书笔记（未完）

第3章 零售业务

3.1、维度模型设计4部过程与案例研究

1️⃣、选择业务过程

决定对哪种业务过程开展建模工作

2️⃣、声明粒度

每行数据表示什么。原子数据能够与多维方法能够实现最佳匹配。粒度较高的模型无法实现用户下钻细节的需求（明细数据能够计算出更多的指标）

DW/BI系统几乎总是要求数据尽可能最细粒度展示，是因为查询需要以非常精确的方式对细节进行拆分

3️⃣、确定维度

详细的粒度说明确定了事实表的束腰维度，可以将更多维度增加到事实表上，如果附加的维度会产生与粒度不符的 其他事实行,则取消该维度或重新考虑粒度声明。

4️⃣、确定事实

确认应该将那些事实放到事实表中。

3.4.1、可计算获得的事实：例如收入字段，收入=原价格-优惠券优惠的价格。能够通过原有度量计算出的新的度量完全可以加到事实表中。但例如百分比或比率，则必须有BI工具计算。 

3.4.2、不可加事实：百分比与比率。例如最细粒度事实表计算出值，下游汇总后就会出现问题

3.4.3、事务事实表：设计之前先要与源系统确认数据增长量

  原子事务事实表的粒度可在事务环境下被简洁地描述,例如,每个事务一行或 个事务线一行。

  由于这些事实表记录的是一个事务事件,所以它们通常是比较稀疏的。

  即使事务事实表无法预测,分布稀疏,它们仍然可能非常庞大。数据仓库中多数 包含数十亿、数万亿行的表往往都是事务事实表。

  事务事实表趋向成为多维化。

  事务事件返回的度量通常是可加的,只要它们通过数量来扩展,而不是获取单位 度量。

3.3、维度表设计细节

3.3.1、日期维表

业务需要按照非标准的日期属性对日期进行分片，需要建立一个详尽的日期维度表，而不是由应用代码解决，注意在跨年之前要检查和维护日期维度表。

3.3.2、产品维度

变化的度量应该被存储在事实表中。能预先定义稳定的数字值，用于过滤和分组，则应该被当成产品维度属性看待。

设计计算的数据应该放入事实表中，涉及约束、分组和标记的数据应该放入维度表中。

为了上下钻所以要把维度表属性尽量健壮，增加一些可分析的属性。

3.3.3、商品维度

描述每个门店。