建模笔记（一）

订单管理-----对于历史变化的观察方法

事实表规范化问题

事实表规范化指，如一个事实表有5个维度，7个事实，那么规范化之后变成了7行，每行5个维度和1个事实，即把7个事实分为7行。

应该避免这种规范化，如在不同事实间计算时，SQL计算不如同一行简单。

维度角色扮演

概念：当某个维度在一个事实表出现多次，则将外健对应的表做不同的视图得以区分，这就是维度模型的不同角色扮演。如日期，在数仓模型内部会存在一个日期的维表（物理表），角色扮演就是针对不同的关联需求拿到不同范围的日期角色视图。为了防止出现太多角色导致管理混乱，一般直接使用物理表做关联。

使用单一表的注意点：维表记录最细粒度则可能会因为记录太详细的数据而导致表极度膨胀；如果不是精确到最细粒度，则只能服务于部分事实表而不是全部相关属性的表。

客户维度

存在多个有关联的主体时，如果事实表存储了主体的ID关系，那么没有必要建立桥接表，可以直接放在事实表。因为事实表专门用于表示维度之间的关联关系和多对多关系，可以考虑直接使用。

客户-销售代理这两个主体的维度表设计引申出多个有关联主体的维度表设计point

1.多对多关系/一对多关系

多对多关系一般建立两个维度表+一个桥接表，这里桥接表可以包含生失效时间，这样也涵盖了关系会随时间变化的场景

2.某个维度表特别大

建立两个维度表，如果放在一起则会影响某个主体维度的统计

3.实体之间存在固定不变的关系

建议合并到一个维度表，但是如果一个表里维度太多可以考虑合并

4.事实表太大

减少需要关联的外键，合并不同的外键为单一维度

退化维度和杂项维度

退化维度：没有维度表可以用来关联的属性，退化到事实表

杂项维度：将多种维度合并为一个杂项维度表，针对五花八门的指标和标志，从事实表中分离

使用场景1:多个维度的枚举笛卡尔积不大，大的话建议分成不同的维度表

使用场景2:维度多为文本，则可以建立杂项维度表

多币种设计

事实表存储标准货币金额（美元）、本地货币金额（RMB/日元等，最常用的货币币种）和本地货币币种，再加一个汇率表，汇率表包含日期dt、转换的两方币种、2个方向相互转换的汇率。

针对时间的分析

针对累积快照事实表，在其基础上增加一个视图计算不同时间之间的差异来做一些分析，更细的可以把周末延迟去掉等，用于监视流程