kimball维度建模技术概述 --《数据仓库工具箱》
1.基本概念
1.1 收集业务需求及数据实现
开始维度建模工作前，项目组需要立即业务需求，以及作为基础的源数据的实际情况，通过与业务代表交流来发现需求，用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、自持分析需求的目标。同时，数据实际情况可以通过与源系统专家交流，构建高层次数据分析访问数据可行性来揭示。
1.2 协作维度建模研讨
维度建模应该有主题专家与企业数据管理代表合作设计而成。工作由数据建模者负责，但模型应该通过与业务代表开展一些列高级别交互讨论获得。这些讨论组也为丰富业务需求提供了一种机会。维度建模不应该由那些不懂业务需求的人来设计，协作是成功的关键
1.3 4步维度设计过程
维度模型设计期间主要设计4个主要的决策：
1. 选择业务过程
2. 声明粒度
3. 确认维度
4. 确认事实
1.4 业务过程
业务过程是组织完成的操作型活动，例如，活动的订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件简历或获取性能度量，并转换成事实表中的事实。多数事实表关注某一些业务过程的结果。过程的选择是非常重要的，因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行
1.5 粒度
声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。粒度声明式设计必须履行的合同。在选择维度或事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在从给定的业务过程获取数据时，原子粒度是最低级别的粒度。我们强烈建议从关注原子级别粒度数据开始设计，因为原子粒度数据能够承受无法预测的用户查询。上卷汇总粒度对性能调整来说非常重要，但这样的粒度往往要猜测业务公共问题。针对不同的事实表粒度，要建立不同的物理表，在同一事实表中不要混用多种不同的粒度。
1.6 描述环境的维度
维度提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何”等背景，维度表包含BI应用所需要的用于过滤机分类实时的描述性属性。牢牢掌握事实表的粒度，就能够将所有可能的维度区分开。当与给定事实表行关联时，任何情况下都应使维度保持单一值。
维度表优势被称为数据仓库的“灵魂”，因为维度表包含确保DW/BI系统能够被用作业务分析的入口和描述性标识，主要的工作都放在数据管理与维度表的开发方面，因为他们是用户BI经验的驱动者。
1.7 用于度量的事实
事实设计来自业务过程事件的度量，基本上都是以数量值表示。一个事实表行与按照事实粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件，在事实表内，所有事实只允许与声明的粒度保持一致。例如，在零售事务中，销售产品的数量与其总额是良好的事实，然而商店经理的工资不允许存在于零售事务中
1.8 方便地拓展到维度模型
维度模型对数据关系发生变化具有灵活的适应性，当发生以下所列举的变化时，不需要改变现存的BI查询或应用，就可以方便地适应，且查询结果不会有任何改变。
- 当事实与存在的事实表粒度一致时，可以创建新列
- 通过建立新的外键列，可以将维度关联到已经存在的事实表上，前提是维度列与事实表粒度保持一致
- 可以在维度表上通过建立新列添加属性
- 可以使事实表的粒度更原子化，方法是在维度表上增加属性，然后以更细的粒度重置事实表，小新保存事实表及维度表的列名
2. 事实表技术基础
2.1 事实表结构
发生在现实世界中的操作型事件，其所产生的可度量数值，存在在事实表中，从最低的粒度级别来看，事实表行对应一个度量时间。反之亦然，因此，事实表的设计完全依赖于物理活动，不受可能产生的最终报表的影响。除了数字度量外，事实表总是包含外键，用于关联与之对应的维度，也包含可选的退化维度建和日期/时间戳。查询请求的主要目标是基于事实表开展计算和聚集操作。
2.2 可加、半可加、不可加事实
事实表中的数字度量可划分为三类：最灵活、最有用的事实是完全可加，可加性度量可以按照与事实表关联的任意维度汇总。半可加度量可以对某些维度汇总，但不能对所有维度汇总。差额是常见的半可加事实，除了时间维度外，他们可以跨所有维度进行加法操作。另外，一些度量是完全不可加的，例如，比率，对非可加事实，一种好的方法是，尽可能存储非可加度量的完全可加的分量，并在计算出最终的非可加事实前，将这些分量汇总到最终的结果集中。最终计算通常发生在BI层或OLAP多维数据库层。
2.3 事实表中的空值
事实表中可以存在空值度量，但是在事实表的外键中不能存在空值，否则会导致违反参照完整性的情况发生。关联的维度表必须用默认行（代理键）而不是空值外键表示未知的或无法应用的条件
2.4 一致性事实
如果某些度量出现在不同的事实表中，需要注意，如果需要比较或计算不同事实表中的事实，应保证针对事实的技术定义是相同的，如果不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名，如果他们不兼容，则应该有不同的命名用于告诫业务用户和BI应用
2.5 事务事实表
事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表，这类健壮的维度确保对事务数据的最大化分片和分块。事务事实表可以是稠密的，也可以是稀疏的，疑问仅当存在度量时才会建立行，这些事实表总是包含一个与维度表关联的外键，也可能包含精确的时间戳和退化维度减，度量数字事实必须与事务粒度保持一致。
2.6 周期快照事实表
周期快照事实表中的每行汇总了发生在某一标准周期，如某一天，某周，某月的多个度量事件，粒度是周期性的，而不是个体的事务。周期快照事实表通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。这些事实表其外键的密度是均匀的，因为即使周期内没有活动发生，也会在事实表中为每个事实插入包含0或空值的行。
2.7 累积快照事实表
累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量时间。管道或工作流过程（例如，履行订单或索赔过程）具有定义的开始点，标准中间过程，定义的结束点，他们再此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含日期外键。累积快照事实表中的一行，对应某一具体的订单，当订单产生时会插入一行。当管道过程发生时，累积事实表行被访问并修改，这种对累积快照事实表行的一致性修改在三种类型事实表中具有特性，除了日期外键与每个关键过程步骤关联外，累积快照事实表包含其他维度和可选退化维度的外键。通常包含数字化的与粒度保持一致的，符合里程碑完成计数的滞后性度量。
2.8 无事实的事实表
例如，在给定的某一天中发生的学生参加课程的事件，可能没有可记录的数字化事实，但该事实行带有一个包含日历天，学生、教师、地点、课程等定义良好的外键。同样，客户交际也是一种事件，但没有相关的度量。利用无事实的事实表也可以分析发生了什么，这类查询总是包含两个部分：包含素有可能事件的无事实覆盖表，包含实际发生的事件的活动表。当活动从覆盖表中减除时，其结果是尚未发生的事件。
3. 维度表技术基础
3.1 维度表结构
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。
3.2 维度代理键
维度表中会包含一个列，表示唯一主键。该主键不是操作型系统的自然键，由于需要跟踪变化，因此若采用自然键，将需要多个维度行表示。另外，维度的自然键可以由多个源系统建立，这些自然键将出现兼容性问题，难以管理。
3.3 自然键、持久键和超自然键
由操作型系统建立的自然键受业务规则影响，无法被DW/BI系统控制。例如，如果雇员辞职，然后重新工作，则雇员号码（自然键）可能会发生变化。数据仓库希望为该雇员创建单一键，这就需要建立新的持久键以确保在此种情况下，雇员号保持持久性不会发生变化。该键有时被称为持久性超自然键。最好的持久键其格式应该独立于原始的业务过程
3.4 下钻
3.5 退化维度
有时，维度除了主键外没有其他内容，例如，但某一发票包含多个数据项时，数据项事实行继承了发票的所有描述性维度外键，发票除了外键外无其他项。但发票数量仍然是在此数据项级别的合法维度键。退化维度常见于交易和累积快照事实表中
3.6 非规范化扁平维度
3.7 多层次维度
例如，日历日期维度可以按照财务周期层次从天到周进行划分，也可能存在从天到月再到年的层次。
3.8 维度表中的空值属性
当给定维度行没有被全部填充时，或者当存在属性没有被应用到所有维度行时，将产生空值维度属性。上述两种情况，推荐采用描述性字符串替代空值。例如，使用Unknown或Not Applicable替换空值。应该避免在维度属性中使用空值，因为不同的数据库系统在处理分组和约束时，针对空值的处理方法不一致
3.9 日历日期维度
3.10 扮演角色的维度
单个物理维度可以被事实表多次引用，每个引用连接逻辑上存在差异的角色维度。例如，事实表可以有多个日期，每个日期通过外键表示不同的日期维度，原则上每个外键表示不同的日期维度视图，这样引用具有不同的含义。这些不通过的维度视图（唯一的属性列名）被称为角色。
3.11 杂项维度
事务性商业过程通常产生一系列混杂的，低粒度的标识和指示器，与其为每个标识或属性定义不同的维度，不如建立单独的将不同维度合并到一起的杂项维度。这些维度，通常在一个模式中标记为事务性概要维度，不需要所有属性可能值的笛卡尔积，但应该只包含实际发生在源数据中的合并值
3.12 雪花维度
3.13 支架维度
维度可包含对其他维度的引用。例如，银行账户维度可以引用表示开户日期的维度。这些被引用的辅助维度被称为支架维度。支架维度可以使用，但应该尽量少用，多数情况下，维度之间的关联应该由事实表来实现。在事实表中通过两个维度的不同外键相关联
4.使用一致性维度集成
4.1 一致性维度
当不同维度表的属性具有相同列名和领域内容时，称维度表具有一致性。
4.2 缩减维度
缩减维度是一种一致性维度，由基本维度的列与（或）行的子集构成。当构建聚集事实表时需要缩减上卷维度。当商业过程自然地获取粒度级别较高的数据时，也需要缩减维度，例如，某个按月和品牌进行的预测（不需要与销售数据关联的更原子级别的数据和产品）。另外一种情况下，也就是当两个维度具有同样粒度级别的细节数据，但其中一个仅表示行的部分子集时，也需要一致性维度子集
4.3 跨表钻取
跨表钻取的意思是当每个查询的行头包含相同的一致性属性时，使不同的查询能够针对两个或更多的事实表进行查询
4.4 价值链
价值链用于区分组织中主要业务的自然流程。例如，销售商的价值链可能包括购买、库存、零售额等。
4.5 企业数据仓库总线结构
企业数据仓库总线架构提供了一种建立日期DW/BI系统 的增量式方法。这一架构通过关注业务过程将DW/BI规划过程分解为可管理的模块。通过重用跨不同过程的标准化一致性维度发布实现集成。
4.6 企业数据仓库总线矩阵
企业数据仓库总线矩阵适用于设计并与企业数据仓库总线架构交互的基本工具。矩阵的行表示业务过程，列表示维度，矩阵中的点表示维度与给定的业务过程是否存在关联关系。
4.7 总线矩阵实现细节
总线矩阵实现细节是一个更加粒度化的总线矩阵，其中拓展每个业务过程行以展示特定事实表或OLAP多维数据库。在此细节粒度上，可以文档化精确的粒度描述以及事实列表
4.8 机会/利益相关方矩阵
在确定了企业数据仓库总线矩阵行之后，可以通过替换包含业务功能（例如，市场、销售、财务等）的维度列规划不同的矩阵。通过确定矩阵点以表示哪些业务功能与哪些业务过程行相关。
5.处理缓慢变化维度（SCD）属性
5.1 类型0：原样保留
5.2 类型1：重写
维度行中原来的属性被新值覆盖，只保留最新的情况。该方法易于实现且不需要建立额外的维度行，但是受此影响的聚集事实表和OLAP多维数据库将会重复计算
5.3 类型2：增加新行
最小需要在维度行中增加三个额外列：
- 行有效的日期/时间戳列
- 行截止日期/时间戳列
- 当前行标识
5.4 类型3：增加新属性
不太常用
5.5 类型4：增加微型维度
对类型4，当维度中的一组属性快速变化并划分为微型维度时采用。此种情况下的维度通常被称为快速班花魔鬼维度。通常在包含几百万行的维度表中使用的属性是微型维度设计的候选，及时他们并不经常变化。变化类型4微型维度需要自己的唯一主键，基维度和微型维度主键从相关的事实表中获取。
5.6 类型5：增加微型维度及类型1支架
5.7 类型6：增加类型1属性到类型2维度
5.8 类型7：双类型1和类型2维度
6.处理维度层次关系
6.1 固定深度位置的层次
固定深度层次是多对一关系的一种，例如，从产品到品牌，再到分类，到部分。
6.2 轻微参差不齐/可变深度层次
轻微参差不急层次没有固定的层次深度，但层次深度有限。地理层次深度通常包含3到6层。
6.3 具有层次桥接表的参差不齐/可变深度层次
在关系数据库中，深度不确定的可变深度层次非常难以建模。这个问题可以通过在关系型数据库中采用构建桥接表方式建模参差不齐层次来解决。这样的桥接表对每个可能的路径保留一行，确保能够遍历所有层次的形式。
6.4 具有路径字符属性的可变深度层次
可以在维度中采用路径字符属性，以避免使用桥接表表示可变深度层次。对维度中的每行，路径字符属性包含特定的嵌入文本字符，包含从层次最高节点到特定维度行所描述节点的完整路径描述。
7.高级事实表技术
7.1 事实表代理键
代理键可用作所有维度表的主键。此外，可使用单列代理事实键，尽管不太需要。不与任何维度关联的事实表代理键，是在ETL加载过程中顺次分配，可用于
1. 作为事实表的唯一主键列
2. 在ETL中，用作事实表行的直接标识符，不必查询多个维度
3. 允许将事实表更新操作分解为风险更小的插入和删除操作
7.2 蜈蚣事实表
一些设计者为多对一层次的每层建立不同的规范化维度，例如，日期维度、月份维度、季度维度和年维度等，并将所有外键包含在一个事实表中。
7.3 属性或事实的数字值
设计者有时会遇到一些数字值，难以确定将这些数字值分类到维度表或是事实表的情况。典型的实例是产品的标准价格。如果该数字值主要用于计算目的，则可能属于事实表。如果该数字值主要用于确定分组或过滤，则应将其定义为维度属性，离散数字值用值范围属性进行补充。在某些情况下，将数字值既建模为维度又建模为属性是非常有意的，例如，定量准时交货度量以及定性文本描述符。
7.4 日志/持续时间事实
7.5 头/行事实表
7.6 分配的事实
7.7 利用分配建立利润与损失事实表
7.8 多种货币事实
7.9 多种度量事实单位
某些业务过程需要事实同时以多种度量单位表示。例如，按照业务用户的观点，供应链可能需要对相同事实以平台、船运、零售以及单个扫描单元构建报表。如果事实表包含大量事实，而每个事实都必须以所有度量单位表示，此时较好的方式是将事实以公认的标准度量单位存储，同时存储标准度量与其他度量的转换系数。这种事实表可按照不同用户的观点部署，使用适当选择的转化系数。转换系数必须存储在事实表行中以确保计算简单正确，并尽量降低查询复杂性。
7.10 年-日事实
7.11 多变SQL以避免事实表间的连接
7.12 针对事实表的时间跟踪
存在三种基本事实表粒度：事务级别、周期快照和累积快照。个别情况下，在事实表中增加行有效时期、行截止日期和当前行表示是非常有用的，与采用类型2缓慢变化维度，在事实行有效时获取时间的方式类似。
7.13 迟到的事实
8.高级维度技术
8.1 维度表连接
8.2 多值维度与桥接表
经典的维度模式中，每个与事实表关联的维度都有一个与事实表粒度一致的单一值。但是在某些情况下，维度存在合理的多值。例如，某个病人接收了一次健康体检，可能同时出现多个诊断。在此情况下，多值维度必须通过一组维度键通过桥接表使一组中的每个诊断与事实表一行关联。
8.3 随时间变化的多值桥接表
8.4 标签的时间序列行为
数据仓库中几乎所有的文本都是维度表中的描述性文本。数据挖掘客户聚类分析通常产生文本化的行为标签，通常可以用作区分周期，在此情况下，跨时间范围的客户行为度量称为由这些行为标签构成的一种的序列，该事件序列应该以位置属性被存储在客户维度中，包含可选文本串，构成完整的序列标签。行为标签在位置设计时建立，因为行为标签是复杂并发查询并不是数字计算的目标。
8.5 行为研究分组
8.6 聚集事实作为维度属性
商业用户通常对基于聚集性能度量的客户维度感兴趣。例如，过滤去年或整个阶段所有花费超过一定数额的客户。选择聚集事实可以放入作为约束和作为行标识报表的目标维度。度量通常表示为度量表中的带状范围。维度属性表述聚集性能度量将增加ETL处理的负担，但是可以方便BI应用层的分析功能
