订单管理的总线矩阵
按照最简单的形式，想象企业数据仓库的总线矩阵。
如图：日期是订单管理中各个环境都需要记录下来的。
客户，产品，销售代理，交易他们呢关心报价，下订单，运输至客户，开发货运发票，客户退货。
交易关心：报价，下订单，运输至客户，开具货运发票，客户退货。
仓库关心：运输至客户，开具货运发票，客户退货。
运货商关心：运输至客户，开具活跃发票，客户退化。
订单管理总线矩阵
订单事物
根据订单管理总线矩阵我们看看对应的企业仓库是什么样的。
订单事务管理的企业仓库
抵制事实表规范化的冲动
1，一些设计者更希望进一步规范化事实表，保留单一的通用的事实及维度。上图的事实表的最小粒度是每个订单明细一行，不是每个订单明细事件一行。
2，但是这种规范化设计，在事实集合非常巨大的时候，具有意义，但是给定的事实行会呈现出稀疏的状态，且没有事实之间的计算结果。
3，实际我们更应该抵制这种规范化事实表的冲动，每行的事实不应该是稀疏的。如果需要规范化事实表，则需要将事实表中行数量乘以事实类型的数量。例如假设事实表包含1000W行，每行包含6个键和4个事实，如果规范化处理将将包含4000W事实行，7个健和一个事实。此外需要在事实间执行算数函数的时候，比较困难。但是如果在一张表中的时候计算比较容易。
4，如果支持BI的应用是OLAP多维数据库，则更加适合采用规范化数据，多维数据库可以沿着任何维度对多维数据进行切分以执行相关计算，无论是日期，客户，还是度量类型。
维度角色扮演
我们总是希望通过时间来考察性能。在事务事实表中，主要的日期列是事务日期，如：订单日期。但是有时会发现其它日期可能会每个事实关联，例如：请求发货日期。这个就涉及到 维度角色扮演。如下图：
维度角色扮演
从上图中可以看到，每个日期成为事实表中的外健，但是不能简单的将两个外健连接到同一个日期维度表，SQL会将这种双向同时连接解释为需要两个相同的日期。但是我们可以建立并管理单独的物理日期维度表，然后使用视图或者别名建立两个不同日期维度的描述。
注意：当某个单一事实表中同时出现多次时，则会存在维度模型的角色扮演，基本维度可能作为单一的物理表存在，但是每种角色应当被标识为不同的试图展现到BI工具中。
日期维度 角色扮演和总线矩阵
日期维度-角色扮演和总线矩阵
产品维度 的共同特征
产品维度是最常见、最重要的维度表之一，它描述了公司销售产品的完整组合。大多数产品表都具有一下共同特征：
1，大量冗长、描述性的列。维度表属性自然的描述维度行，不会因为其它维度的影响而发生变化，不会随时间发生变化，尽管某些属性可能会随时间缓慢变化
2，一个或者多个属性层次，加上没有层次的属性。在试图展示产品描述的时候，具有按一个属性，然后在另外一个属性进行约束是最近本的要求，所有属性，无论是否适合单一层次，都应该能被方面的进行上卷和下钻。多数产品的维度属性是单独的低粒度属性，不是明确层次结构的一部分。
3，重新建立操作型产品代码到代理键的映射。需要使用无语义的代理主键以避免由重复使用操作型产品代码所带来的严重错误，另外需要集成来自不同操作系统的产品信息。
4，增加描述性属性值以扩大或者替换操作型代码。不要接收类似业务用户熟悉操作型代码这样的借口。业务用户熟悉操作性代码的唯一原因是被迫使用这些代码，因此内容必须具有易读性，模糊神秘的缩略词与纯数字一样不受欢迎，应该将他们替换为便于理解的文本或者进行扩充。
5，检查属性值，确保没有拼写错误，不可能存在的值，多变量等。BI应用和报表依赖于维度属性的准确内容。
6，将属性定义、解释、元数据来源文档化。记住元数据类似DW/BI的百科全书。必须警惕元数据仓库的获取和维护工作。
客户维度的共同特征
客户维度为每个发送产品的不同地址建立一行。
客户维度
从图中我们可以看到，一个客户维度同时支持不同的层次，例如Address，城市，州县，国家等不同层次。层次可以不同级别的数量，在这这些层次的每个层次上进行上卷和下钻是维度模型必须支持的。
客户维度如何处理单一维度表与多维度表
1，一对一关系或者多对多关系如何处理？
如果多对多关系是一种特殊情况，比较少，则应该将多对多的关系合并到客户维度中去，需要知道的是这类少见的多对多关系需要多个代理键。
如果多对多关系常见，则需要为多对多的双方分别建立维度。
2，如果两种维度关系随着时间发生变化，或者两者的维度关系受其它维度的影响，最后分别建立不同的维度。
3，如果某一种维度的数据量已经很巨大了，不建议将两个维度进行融合。
4，例如当业务方认为销售代理和客户应该是不同的事情吗？这种场景强迫将两个不同的维度合并为一个维度没有任何意义。
5，当实体之间存在固定的随着时间变化的强关联的关系时，他们应该被建模到单一维度中。大多数情况下，当实体被划分为两个不同的维度时候，设计将会更简单且方便管理，但是要注意太多维度的一般性准则：如果在您的模式中已经包含有25个维度，则应该考虑尽可能将这些维度合并。
6，若存在两个不同的维度，一些设计者希望建立一张两个维度关键字的小表以展示关联性，而不需要使用事实表。多数情况下没有必要。没有理由避免用事实表来响应这类需求。
应用于客户/代理分配的无事实的事实表
有时候用户希望获得按照时间分析销售代理的复合分配问题，即使订单已经发生了。
应用于客户/代理分配的无事实的事实表
交易维度
该维度有时称为合同。当面对百万级或者亿万级大型事实表时候，希望减少事实表中关键字数量，采用复合健能够将交易属性当成单一维度。
交易维度示例
针对订单号的退化维度
因为处于事实表的订单号没有和维度表连接，所以他是一种退化维度。
1，订单号在订单事实表中的每个包含明细项的行都包括
2，维度模型中订单号通常和订单表头没有关联。可以将订单号分类到不同的维度中去。例如订单日期，客户的“发货到”
3，订单号可以用于连接数据仓库与后端的操作型系统。
5，也可以起到事实表主键的作用，
注意：退化维度通常被保留作为操作型事务的标识符。不能将他们作为一种坚持要在事实表使用神秘模糊代码，而不与维度表连接以获得描述性解码的接口。
杂项维度
1，忽略这些标志和指标。当偶尔需要他们，且这些指标和标志难以理解且不一致，也许真应该去掉他们。
2，保持事实表中行的标志和指标不变。不希望在事实表中存储无法辨认的神秘标示。也不希望存储包含大量的字符描述符，在行中保留一些文本指标令人反感。
3，将把每个标志和指标放入自己的维度中。如果外键的数量处于合理的范围（不超过20个），则在事实表中增加不同的外键是可以接收的。但是若外健列表已经很长，则应该避免将更多的外健加入到事实表中
4，将标志和指标存储到订单表头维度中。
总之：杂项维度就像厨房中的垃圾抽屉，主要用于DW/BI专业人员之间，在于业务进行讨论的时候，我们通常将杂项维度称为事务指示器或者事务概要维度。
应该避免的表头/明细模式
避免模式一：将事务表头当成维度。订单表头维度可能非常庞大。维度表不应该和事实表以同样的速率增长。
避免模式一：将事务表头当成维度
避免模式二：在列表事实中没有继承表头维度。如图中所描述的那样，订单表头不再被当作整体维度，被当作事实，能够准确的表示订单表头与明细项的父/子关系，但是仍然存在问题。当用户希望按照任意表头属性对列表事实分片和分块时候，大型表头事实就需要与更大的列表事实表关联。
避免模式二：列表事实中没有继承表头维度
作者：数据僧
链接：https://www.jianshu.com/p/9b719bd5a42b
随时随地看视频
