数据仓库建模（四）：维度表的设计

一、维度表的整体结构

1.1 维度表的结构设计

① 包含单一的主键

每个维度表都包含单一的主键列。

② 行的描述环境要和事实表行完全对应

维度表的主键可以作为与之关联的任何事实表的外键，维度表行的描述环境需要和事实表行完全对应。

③ 维度表通常比较宽

维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性，维度表的属性是查询及BI应用的约束和分组定义的主要目标。

1.2 维度代理键

维度表中会包含一个列，表示唯一的主键。（维度代理键其实就是维度表的主键）

该主键不是操作系统的自然键，由于需要跟踪变化，因此若采用自然键，将需要多个维度行表示。维度的自然键可能由多个源系统建立，这些自然键将出现兼容性的问题，难以管理。

DW/BI系统需要声明对所有维度的主键管理，因此无法采用单一的自然键或附加日期的自然键，可以为每个维度建立无语义的整型主键。这些维度代理键是按顺序分配的简单整数，以值1开始。每当需要新键时，键值自动加1。

注：日期唯独不需要遵守代理键规则，日期维度是高度可预测的且稳定的维度，可以采用更有意义的主键（见1.10）。

自然键即指有业务意义的唯一ID，例如用户ID、身份证号等。代理键则可以简单理解为该表的自增ID值

1.3 自然键、超久键和超自然键

由操作系统建立的自然键受业务规则影响，无法被 DW/BI 系统控制。

例如，如果雇员辞职，然后重新工作，则雇员的编号(自然键)可能会发生变化。数据仓库希望为该雇员创建单一键，这就需要建立新的持久键以确保在此种情况下，雇员编号保持持久性，不会发生变化。

该示例中的主键有时会被称之为超自然键

最好的持久键其实应该独立于原始的业务过程，并以整数1开始进行分配，多个代理键与某一个雇员关联时，若描述发生变化时，持久键不会发生变化。

题外话：这里的自然键在实际业务中其实使用意义不大，它看起来没有实际的价值，在上面的示例中，我们一般会使用用户的身份证编号来作为他的编码，这样就保证了雇员编号持久性。

1.4 下钻与上卷

维度中有不同的层次，每个层次可以有多个级别，这样就可以根据多个维护层次和级别进行分析，可以灵活获取高级别的汇总信息，获取低级别的明细信息。把获取高级别的汇总信息的过程叫上卷，把获取低级别的明细信息的过程叫下钻

假设时间维度有四个级别，分别是年、月、天、小时，现在我们某个级别分析每天的课程访问量，比如按天分析网页的访问量，此时我们可以按小时下钻分析，得出一天内每小时的网页访问量，也可以按月上卷，得到月度的网页访问量

1.5 维度退化

有时，维度表除了主键外没有其他内容。

例如，当某一发票包含多个数据项时，数据项事实行继承了发票的所有描述性维度外键，发票除了外键外无其他项，但发票数量仍然是此数据项的合法维度键（可以看作数字度量也可以看作维度键，角度不同）。

我们把这种数据退化到维度表中，即表明该字段是维度退化字段，也表明该字段没有对应的维度表。

常见的事实表的主键、日期字段、时间戳等都属于退化维度。