第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、商品维度
描述每个门店。
