维度数据建模的概念和术语

维度建模关注的焦点是为终端用户展现数据，而通常来说，维度数据模型正是关注于让终端用户理解和访问数据更加简单。这种设计技术的特征就是主动地以更多开发人员的工作量来换取易于最终用户理解和使用的结果。根据维度数据模型，大多数数据集市的设计工作以数据的ETL处理结束。

维度数据模型是实体关系型数据模型的子集，也具有实体、属性和关系等基本组件。实体一般有两种基本类型：事实（fact）——提供度量；维度——提供上下文。在简单维度中的关系被包含并贯穿于事实表中，所有的维度到事实的关系是一对多（1 : M）。

1 事实表

事实表包含重要的业务度量。术语“事实（fact）”承载了多重含义，如“事实表（fact table）”（实体）包含了一个或多个“事实”（代表度量的属性）。事实表的行包含特定的数值型度量，比如数量、数目计数。一些度量是计算的结果，因此正确理解和使用元数据就很重要。事实表占据了数据库中大多数空间（根据经验可合理推断大约为90%），而且倾向于使用有很多列的行来存储数据。

事实表用来表达和解析维度间的多对多关系。访问事实表也一般从维度表开始。

事实表通常有很多控制列，这些列用于表示行被加载的时候，是由哪些程序加载的，或者指示哪些是最新的记录，或者其它一些状态。这些字段有助于程序员、操作员和超级用户浏览和验证数据。

2 维度表

维度表，或缩写为维度，代表业务中的重要对象而且包含相关的文字描述。维度以“根据......查询”（query by）和“根据......报告”（report by）的形式作为限制条件。它们是访问或链接到事实表的入口，而且它们的内容可以作为报表分组和报表标签的依据。维度结构通常是高度去范式化，而且根据经验大约占所有数据的10%。维度详细设计的深度和质量决定了系统的分析用处。

所有的维度设计都可能包含日期维度、组织或当事人维度。其它的维度取决于如何支持对事实表中数据的分析。

典型的维度表只有少量的行数和很多列数。维度表的主要内容是：

• 代理键和非代理键
• 主键用于与数据仓库中其它表关联
• 描述性元素，包括编码、描述、名称、状态等
• 任何层次信息，经常包括多个层次和类型的分解
• 业务键，供业务用户确定特定的行
• 源系统标识字段，用以追溯数据来源
• 维度表的控制列与事实表的控制列类似，但是维度表的控制列主要涉及维度的历史信息如何保存，且往往设计成如下文所描述的类型1、类型2、类型3、类型4和类型6等不同的实现方法

维度必须为每一行设置唯一的识别符，通常通过代理键和自然键两种方法来实现。

2.1 代理键

在Kimball的方法中，每个维度行都会被赋予一个与实际数据毫无关系的数据作为主键。该数字被称为“代理键”或“匿名键”，而且既可以是一个顺序码，也可以是真正的随机码。使用代理键的好处体现在如下一些方面。

• 性能——数据型字段往往比其它类型的字段有更好的搜索性能
• 隔离——它是业务主键变化的缓冲区。代理键可以不受源系统字段数据类型或长度的变化的影响
• 整合——使得来自不同的数据源的数据可以融合。通常不同源系统中的主键往往互不相同
• 优化——诸如“未知”或者“不可用”等这样的取值，可以拥有其自己特有的键值，从而与其它存有有效值的行相区别
• 互操作性——某些数据访问功能和图形用户界面可以更好地处理代理键，因为它们都不需要有所依赖的系统相关的额外知识就能正常工作
• 版本化——同一维度值可以有不同的实例，这对于根据时间跟踪变化是非常有用的
• 诊断——支持加载问题分析，并且具备重新运行的能力

为了实现代理键的这些优点，必须需要有额外的数据ETL处理以将数据主键与源系统主键进行映射，并维护映射表。

2.2 自然键

对于某些系统，可能不希望额外创建主键字段，而是使用已经用于区分唯一数据行的数据。使用自然键的优点包括：

• 较低的代价——键值字段已经存在，无须额外的建模以创建或处理新的键
• 易于变化——在关系型数据库管理系统中，存在域的概念，它易于根据源系统的变化进行全局变化
• 性能提高——使用唯一键给你的值可以完全避免表的关联，从而提高性能
• 数据血缘关系——理容易跨系统跟踪，特别是当数据在两个以上的系统间移动

作为这些优势的代价，使用自然键，在每次联结查询时有可能需要使用多个复杂的非数值字段作为条件。而且在某些关系型数据库管理系统中，在联接查询中使用字符串进行联接查询的效率要低于使用数据字段。

3 维度属性类型

维度属性有3种不同的保留历史副本的类型。这3种类型被创造性地命名为类型1、类型2和类型3.还有另外两种不经常出现的类型，通常被创造性地命名为类型4和类型6。类型1~3能够在同一张表中共存，而如何进行更新则依赖于字段和类型的关系。

3.1 类型1覆盖

类型1维度属性不需保留任何历史记录。它仅仅保留最新取值，因此任何更新都完全覆盖此字段之前的取值。类型1的一个例子是“头发颜色”，更新时无须保留当前值。

3.2 类型2创建新行

类型2维度属性需要保留所有的历史记录。每一次类型2字段变化，就会创建一行存储最新信息的记录，而之前有效的记录将会通过更新有效期字段被标志为过期记录。类型2的例子是账单地址。当账单地址发生变化，保留旧地址的行过期而记录新的账单地址的行会被增加到表中。

需要注意的是，采用类型2要求该表主键能够为相同的自然键保留多个实例，这既可以使用代理键实现，也可以为主键增加索引值，或者增加一个日期值（表示生效、过期、插入等）为这主键。

3.3 类型3创建新列

类型3 维度属性仅需有选择地保留已知的历史记录。在同一行中可能需要有多个字段保留不同的历史版本。当出现更新时，当前有效值将被移动到下一个合适的字段中，新的合适的字段将被用于存储，而最后一个无需保留的值将会被德育。类型3的例子是信用评分，仅需保留开户时的原始评分和最新评分，以及最近一次被更新的评分。更新操作会把当前评分高为上一次评分。

另外一个例子是月度账单总额。可以有12个字段，分别命名为Month01、Month02等，或者“一月”、“二月”等。如果是前者，则当前月度的取值会更新字段Month01的取值，而其它字段都会顺序下移。如果是后者，当相应的月度数据被更新了，用户知道当前月份以后的字段值保留的是去年的数据。

类型3可用于属性值的迁移。例如，一个公司决定重新组织其产品层次，但是希望在本年度同时看旧层次和新层次的销售数据图表，要实现这点要求所有数据都要恰当地记录下来。如果在某一时期，旧新数据都可用，就可进行这种数据转换。

3.4 类型4新表

类型4维度属性将过期的行移到“历史”表中，而“现有”表中的行会被当前信息更新。类型4的例子可以是供应商表，当过期的供应商记录在更新发生后被移至历史表中，则主维度表仅包含当前的供应商记录。后者有时也被称为类型2a维度。

在类型4中，根据时间线来获取数据将会更加复杂，因为现有表和历史表需要被关系起来以便于再和事实表关联。因此，当用户访问主要是现有维度数据，而维护历史表主要是供审计所需，类型将会是一个好的选择。

3.5 类型6（1+2+3）

类型6以类型2的方式处理维度表，当任何值发生任何变化是创建一条新的记录，但是键值（代理键或自然键）不需要改变。实施类型6的一个方法是为每行增加3列——生效日、过期日期以及一个当时有效指示符。如果是查询根据特定时间点查找数据，则检查所需查找的时间是否在生效日期和过期时间之间。如果查询仅仅需要查找当前数据，则可增加过滤器并以现有记录指示符为条件。增加过滤条件的缺点是要求用户具备额外的知识能够通过时间区间或指示符来获取所要的记录。

实施类型6的另外一个方法是增加索引列来取代现有记录指示符，而索引列的当前值为0。所有被更新的行获得索引值为0，而其它行则在其索引列上加1形成序列。则如果查询需要寻找当前取值则应将索引列的过滤条件设为0，而当查询需要寻找之前时间所对应的列则需要用不用生效日期和过期时间。这一技术的主要缺点是所有事实表中的记录都会自动连接到索引为0的维度（当前记录）。关联到事实表的查询不会找到任何此维度之前的取值，除非将维度的生效日期和过期时间包含在查询中。

4 星型模型

星型模型是维度数据模型，事实表位于中间，连接到周围的众多维度表。它也被称为星型关联模式，重点在于中间的事实表通过单一的主键联接到周围的维度表。居中的事实表有着来自于众多维度表的键构成的复合键

 5 雪花模型

雪花模型是将星型模型中平面的单表维度结构进行去范式化，并转换成相应的层次或网络结构。Kimball的设计方法中，因为如下两种原因并不鼓励使用雪花模型：

1. 它对星型模型的简单性和终端用户易于理解的特性造成负责影响
2. 空间的节省有限

6 粒度

Kimball用术语“粒度”（Grain）表示事实表中的一行记录所代表的含义或描述，或者用另外一种方式来表述，粒度表示一笔交易所对应数据的原子级别。在一个事实表中定义精度是Kimball的维度设计方法中的关键步骤。例如，如果事实表中存入某月的所有交易数据，则我们可以推断事实表中数据的粒度或限制不会包括去年的数据（即事实表粒度细到月，则我们可推断出该事实表中不可能包括去年的数据）。

7 一致性维度

一致性维度是在Kimball设计方法中可供多个数据集市使用的公用或共享的维度，更加准确的是，Kimball是对数据元素命名及相应的取值，或包含严格的子集等方面相匹配的维度来定义一致性维度的。实际意义在于是从一致性维度获得的任何结果集中的行头部（Row Header）都必须能完全匹配。

例如，设想一下多个数据集市或事实表，都直接联接到同一维度或该维度表的直接复制副本上，该维度表的更新将自动反映到这些数据集市的所有相关查询中。

在其它星型模型中重用一致性维度使得数据仓库的模块化开发成为可能。即使设计不断膨胀，星型模型也能通过一致性维度粘连在一起。在一个数据仓库中，起源于支付部分的事实，能够与供应部门的供应商绩效事实表通过共享的产品维度粘连起来。最终，对若干主题域的查询将是对企业数据仓库中数据的访问。

8 一致性事实表

一致性事实表使用跨多个数据集市的标准化术语，不同的业务用户可能以不同的方式使用同一术语。“客户加成”与“毛利润加成”，或“调整加成”是否一致？“处理订单”指的是整个订单，还是某条业务线上的产品汇总？

开发者需要敏锐地意识到很多事物称为一样，但是在各个组织中的概念并不相同，或者相反，事物的称为不一样却在各个组织中实际表达的是同一概念。

9 数据仓库总线（DW-Bus）架构和总线矩阵

术语总线（Bus）来自Kimball的电子工程背景，总线是同时为许多电子元件提供电力的组件。以此类推，一致性维度的数据仓库总线架构允许多个数据集市共享，并通过接入总线实现一致性维度的共享。

数据仓库总线的矩阵是以表格的形式展示数据集市/数据处理过程/主题域是否与共享的一致性维度相关。下表正是这样的矩阵实例。一个数据集市在使用多个数据维度时可能会使用一致性维度（如行所示），而数据仓库总线体现在多个数据集市使用同一维度。

数据仓库总线矩阵是非常有效的沟通和计划工具。对于数据仓库和商务智能管理实践而言，统一的概念是Kimball最有价值的贡献之一，也成为数据仓库和商务智能管理中的重要设计文件，需要检查现有的维度表和事实，以及它们的源、更新逻辑、调度计划，从而确定是否可以重用。