数据仓库--维度建模

Kimball小组为采用维度方式建模数据定义了完整的技术集合；Kimball技术已经被业界所接受，成为最佳实践。

一、维度建模设计过程

维度建模应该是有主题专家与企业数据管理代表合作设计完成，工作有数据建模这负责，但是模型应该通过与业务代表开展一系列高级别讨论获得。
维度建模需要考虑业务需求以及协作建模阶段设计的底层数据源；按照业务过程、粒度、维度、事实声明的流程，设计组确定表名和列名、示例领域值以及业务规则，而业务数据管理代表必须参加详细的设计活动，以确保涵盖正确的业务。

1，选择业务过程

业务过程是组织完成的操作型活动，例如，获得订单、处理保险索赔、学生课程注册活每个月每个账单的快照等。业务过程事件简历或获取性能度量，并转换为事实表中的事实。
多数事实表比较关注业务过程的结果。
过程的选择很重要，因为过程定义了特定的设计目标以及对粒度、维度、事实的定义，每个业务过程对应企业数据仓库总线矩阵的一行。

2，声明粒度

粒度用于确定某一事实表中的行所表示的含义，每个候选维度或事实必须与定义的粒度保持一致，在所有的维度设计中强制实行一致性是保证BI应用性能和易用性的关键。
原子粒度是最低级别的粒度，一般需要从原子粒度开始设计，因为原子粒度数据能够承受无法预期的用户查询；针对不同的事实表粒度，要建立不同的物理表，在同一事实表中不建议混用多种粒度。

3，确认维度

维度表是数据仓库的灵魂，因为维度表包含确保DW/BI系统能够呗用作业务分析的入口和描述性表示，主要的工作是数据管理与维度表的开发。
维度表包含BI应该所用于过滤与分类事实的描述性属性，当与给定事实表进行关联时，任何情况下都应该使维度保持单一值。
维度提供围绕某一业务过程事件所涉及的“谁”、“什么”、“何处”、“何时”、“为什么”、“如何做”的内容。

4，确认事实

事实是来自业务过程事件的度量，基本上都是以数量值表示。
一个事实表行与按照事实表粒度描述的度量事件存在一对一的关系，因此事实表对应一个物理可观察的事件。
所有事实只允许与声明的粒度保持一致。

二、事实表

1，表结构

（1）从最低粒度级别来看，事实表的行对应一个度量事件；
（2）事实表的设计完全依赖于物理活动，不受可能产生的最终报表的影响。
（3）事实表包含外键，用于关联与之相关的维度。
（4）事实表包含可选的退化维度键和日期/时间戳。
（5）事实表的查询请求的主要目标是基于事实表开展计算和聚集操作的。

2，数字度量的分类与应用

（1）可加：最灵活、最有用的事实，可以按照与事实表关联的任意维度汇总。
（2）半可加：可以对某些维度汇总，但不能对所有的维度汇总；差额是最常见的半可加事实。
（3）不可加：尽可能存储不可加度量的完全可加的分量，并在计算出最终的不可加事实前，将这些分量汇总到最终的结果集合中。例如：比率。

3，空值处理

（1）事实表中可以存在空值度量。
（2）事实表的外键中不能存在空值。
（3）所有聚合函数都可以对空值事实进行计算。
（4）关联的维度表必须用默认行（代理键）不能用空值外键表示位置的或者无法应用的条件。

4，一致性事实

（1）比较或者计算不同事实表中的事实，应针对事实的技术定义是相同的。
（2）如果不同的事实表定义是一致的，则这些一致性事实应该具有相同的命名。
（3）如果不同的事实表定义是不一致的，则应该有不同的命名用于告诫业务用户和BI应用。

5，事务事实

（1）事务事实表的一行对应空间或时间上某点的度量事件。
（2）原子事务粒度事实表是维度化及可表达的事实表；这类维度可以对事务数据的最大化分片和分块。
（3）事务事实表可以是稠密的，也可以是稀疏的。
（4）事务事实表总是包含一个维度表关联的外键，也可能包含精确的时间戳和退化维度键。
（5）度量数字事实必须与事务粒度保持一致。

6，周期快照事实

（1）周期快照事实表中的每行汇总了发生在某一标准周期的多个度量时间。
（2）周期快照事实表的粒度是周期性的，不是个体的事务。
（3）周期快照事实表通常包含多个事实，因为任何与事实表粒度一致的度量事件都是被允许存在的。
（4）周期快照事实表的外键密度是均匀的，因为即使周期内没有任何活动发生，也会在事实表中卫每个事实插入包含0或者空值的行。

7，聚集事实表或OLAP多维数据库

（1）聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作，目的是为了提高查询性能。
（2）聚集导航的过程是开发的，以便报表制作者、查询工具、BI应用都能够获得同样的性能优势。
（3）聚集事实表包含外键以缩小一致性维度，聚集事实的构建是通过对来自多个原子事实表的度量的汇总获得的。
（4）使用汇总而度量聚集OLAP多维数据库一般与关系类型的聚集方法类似，但是OLAP多维数据库可以被商业用户直接访问。

8，合并事实表

（1）来自多个过程，以相同力度表示的事实合并为一个单一的合并事实表。
（2）合并事实表会增加ETL处理过程的负担，但是降低了BI应用的分析代价。
（3）合并事实表适合经常需要共同分析的多过程度量。

三、维度表

1，表结构

（1）每个维度表都包含单一的主键列。
（2）维度表的主键可以作为与之关联的任何事实表的外键。
（3）维度表行的描述环境与事实表行完全对应。
（4）维度表通常比较宽，是扁平型非规范表，包含大量的低粒度文本属性。
（5）维度表属性是查询及BI应用的约束和分组定义的主要目标。
（6）报表的描述性标识通常是维度表属性领域值。

2，维度代理键

（1）维度表中包含一个列，表示唯一主键，这个主键不是操作性系统的自然键，由于需要跟踪变化，因此若采用自然键，将需要多个维度行表示。
（2）DW/BI系统需要声明对所有维度的主键的控制，无法采用单一的自然键或者附加日期的自然键，可以作为每个维度简历无语义的整型主键，维度代理键是按顺序分配的简单整数，以1开始，递增。
（3）日期维度不需要遵守代理键规则，因为高度可预测且稳定。
（4）维度代理键可以采用比较有意义的主键。

3，自然键、持久键和超自然键

（1）操作性系统建立的自然键受业务影响，无法被DW/BI系统控制。
（2）最好的持久键格式应该独立于原始的业务过程，并以整数1开始进行分配，多个代理键发生关联操作时，若藐视发生变化，持久键也不会发生变化。
（3）如果员工辞职，重新工作，则雇员号码会发生变化，数据仓库希望为员工建立单一键，这就需要建立新的持久键一确保在此种情况下，雇员号码保持持久性不会发生变化，此类键有时候被称为持久性超自然键。

4，下钻

（1）商业用户分析数据的最基本方法。
（2）仅需要在查询上增加一个行头指针，新行的头指针是一个维度属性，附加了SQL语言的GROUP BY表达式。
（3）属性可以来自任何与查询使用的事实表关联的维度。
（4）下钻不需要预先存在层次的定义。

5，非规范化扁平维度

非规范化扁平维度能够实现维度建模的双重目标：简化和速度。

6，多层次维度

（1）表示包含不止一个自然层次。
（2）同一维度中可以存在不同的层次。

7，文档属性的标识与指示器

（1）缩写、真假标识以及业务指标可以作为维度表中文本字词含义的补充解释。
（2）操作代码值所包含的意义应分解成不同的表示不同描述性维度属性的部分。

8，空值属性

（1）给定维度行没有被全部填充或者当存在属性没有被应用到所有的维度行时，会阐释空值维度属性。
（2）空值维度属性推荐采用描述性字符串替代空值。
（3）避免在维度属性中使用空值，因为不同的数据库系统在处理分组和约束是，对控制的处理方式存在不一致。

9，日历日期维度

（1）连接到实际事实表的日历日期维度，使能够对事实表，按照熟悉的日期、月份、财务周期与日历上的特殊日期进行导航。
（2）日历日期维度通常包括日期、月份、财务周期、国家假日等属性。
（3）如果需要更详细的精确度，可以在事实表中增加不同的日期时间戳。
（4）日期时间戳并不是维度表的外键，以单独列的形式存在。

10，扮演角色维度

（1）不同的维度视图（唯一的属性列名）被称为角色。
（2）单个物理维度可以被事实表多次引用，每个引用连接逻辑上存在差异的角色维度。

11，杂项维度

（1）事务性商业过程通常产生一系列混杂的、地力度的标识和指示器，与其为每个标识或属性定义不同的维度，不如简历单独的将不同维度合并在一起的杂项维度。
（2）杂项维度通常在一个模式中标记为事务性概要维度，不需要所有的属性值的笛卡尔积，但是应该包含实际发生在源数据的合并值。

12，雪花维度

（1）当维度表中的层次关系是规范的时，低粒度属性作为辅助表通过属性键连接到基本维度表，当这一个过程中包含多重维度层次时，建立的多级层级结构被称为雪花模式。
（2）雪花模式可以精确表示层次化的数据，但是会影响查询性能，应该避免使用雪花模式。
（3）扁平化的，非规范的维度表可以替代雪花模式精确的表示层次化的数据。