【Kimball】维度建模基础-不该做的12件事

*内容仅代表Kimball的观点。
以下注意事项按照重要性相反顺序排列，但即便是前面的错误也会导致严重后果。
错误12：将文本属性留在事实表中。
　　创建维度模型实际上是将数值测量和描述性文本属性分别放在事实表和维度表中的过程。针对某个测量操作，首先将数值测量归入事实表中，然后将测量的上下文中的描述性文本属性归入维度表中，最后，要对残留的代码和伪数值项逐一判断，应该属于事实表还是维度表。这个过程中可能会错误地将描述性文本纳入事实表中，尤其可能留在事实表的“备注”之类的字段中，这种情况是应该避免的。

例：针对超市收银的操作，一条记录可能包括：商品名、件数、单价、交易时间、收银台ID、超市等，它们分别应该归纳到事实表还是维度表中呢？

错误11：忽略维度表中的详细描述属性。
　　有些设计者可能为了减小维度表，而牺牲描述上下文。但维度表在几何数量上通常远小于事实表，缩小维度表空间对性能提升有限，而在每个维度上提供详细的描述上下文，确保用可读的描述文本来定义每一个编码，对数据仓库的易用性提升是非常明显的。

错误10：将层次结构划分成多个维度
　　层次结构就是一系列级联的多对一关系，例如许多个产品属于一个品牌，许多品牌属于一个商品类别。此时应该用一个包含“产品名称、品牌、所属商品类别”字段的表作为产品维度表，而不是创建产品维度表、品牌维度表和商品类别维度表这样3个表。
　　理解层次结构应该是前端或者用户的事，数据仓库的任务是以最自然有效的方式来呈现它们，一个层次结构应该属于单一的物理扁平化维度表。
　　总之，大多数情况下，只要确保该维度是在最小可能粒度上定义的，那么在一个维度中包含所有的层次结构就是合理的。例如这个例子中应该定义成“产品维度表”，如果定义在品牌粒度上，那么具体每个产品的信息就丢失了。

错误９：没有正确使用渐变维度（SCD）
　　有很多数据仓库项目会重写重要维度，例如顾客和产品，这些维度都来自基础的数据源。这违背了数据仓库的基本原则：准确表示历史数据。
　　SCD是每一个数据仓库必要的设计元素。
错误８：使用智能键将维度表联结到事实表
　　在设计维度表中连接到事实表外键的主键时，刚入门的数据仓库设计者往往会望文生义，将整套维度属性声明为维度表键，这会导致各种问题。
　　正确处理方法是用一个代理键替换智能物理键，且最好是用１～Ｎ的顺序编号（Ｎ＝维度表中记录数量）的简单整数代理键。
错误７：在确定测量值的粒度确定之前将维度添加到事实表
　　维度设计应该首先识别测量源，然后确定测量的准确粒度和含义，最后用该粒度上的维度来围绕这些测量。
　　忠实于粒度是维度数据模型设计中的关键。
错误６：基于特定的报告来定义维度模型
　　维度模型与预期的报告没有任何关系！
　　维度模型是测量过程的模型，数值测量形成了事实表的基础，适用于指定事实表的维度是描述测量环境的上下文。维度模型牢牢基于测量过程。
　　也就是说如何按照用户要求展现报告，是数据仓库下游和前端要完成的任务，他们将维度模型中的数据按照用户需求转换并加载到前端展现出来，而维度模型本身是根据数值测量过程来定义的，完全独立于业务用户。
错误５：在相同事实表中混合不同粒度的事实
　　维度设计中的严重错误是将“有帮助的”汇总过的事实添加到事实表，如描述扩展的根据时间段或地区汇总的记录。尽管这些特别的事实似乎会让一些特定程序更简单，但这破坏了事实表本身的结构，会造成更多的错误结果。
错误４：不基于最低级别原子数据构建维度模型
　　最低级别数据是最具维度性的，且应该是维度化设计的物理基础。聚合的数据已经失去了一些维度。如果基于聚合的数据构建一个维度模型，那么用户就无法向下钻取到原子数据，也就是说无法查询到最详细的细节数据。
　　应该基于原子的数据来构建所有维度模型，让所有原子数据成为数据仓库展示区域的一部分，这样用户才可以向下钻取到最详细的细节。
错误３：在面对查询性能瓶颈时忽略“聚合事实表并且收缩维度表”的方案；通过添加更多并行处理硬件来解决性能问题
　　聚合（如Oracle的物化视图和DB2的自动汇总表）是提升查询性能的单一的最具成本优势的方式。大多数查询工具都明确支持聚合，并且这些工具都依赖维度建模构造。
　　首先通过构建聚合、选择具有查询效率的DBMS软件、构建大量索引、增加物理内存以及提高CPU速度来提高查询性能，这些方法还是满足不了性能需求，再考虑添加并行处理硬件。
错误2：未能跨独立事实表让事实一致化
　　如果在源自不同基础系统的两个或多个维度模型中有一个相同的数值测量事实（如收益），那么就需要完全明确这些事实的定义以便区分。
错误１：未能跨独立事实表一致化维度
　　这是最大的错误，因为维度建模最重要的设计技术就是一致化维度。如果两个或多个事实表具有相同的维度，那么一定要让这些维度完全相同或者有子集的关系。在跨事实表维度一致化时，将能够横向钻取不同的数据源，因为约束和行标题表示的含义是相同的并且可以在数据层面进行匹配。一致化维度是构建分布式数据仓库的独家秘方，可以为已有的数据仓库增加非预期的新数据源，并且让多种不兼容的技术和谐地共同发挥作用。