一、代理关键字###

在数据仓库领域有一个概念叫Surrogate key（代理关键字）。

• 代理关键字一般是指维度表中使用顺序（序列） 分配的整数值作为主键，也称为“代理键”。

• 代理关键字用于维度表和事实表的连接。在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字（ Smart Keys）。

数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。

使用代理关键字的优点：

1．能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说，当数据仓库需要对来在多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。

2．可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键联接的效率也很高。

3．可以建立一些不存在的维度记录，例如 “日期待定”，“日期不可用”等维度记录。

4．可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。 Kimball的缓慢变化维处理策略的核心就是使用代理关键字。

当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。

二、缓慢变化维###

维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions（“缓慢变化维”），经常被简写为SCD。

缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。

处理缓慢变化维的方法通常有三种方式：

• 直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常简称为“ TYPE 1”。

• 添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为“ TYPE 2”。

• 添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为“ TYPE3”。

在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持方便的分析历史变化情况。

三、退化维度###

在维度建模的数据仓库中，有一种维度叫Degenerate Dimension(“退化维度”)。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。

四、微型维度###

维度建模的数据仓库中，有一种维度叫minidimension，(“微型维度”)。
微型维度的提出主要是为了解决快变超大维度（ rapidly changing monster dimension）。以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。

对于快变超大维度，设计人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。

这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE 1型处理。

在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的范围。 这样可以极大的减少微型维度中的记录数目，也给分析带来方便。

五、一致性维度###

度建模的数据仓库中，有一个概念叫Conformed Dimension，(一致性维度)。
一致性维度是Kimball的多维体系结构（ MD）中的三个关键性概念之一，另两个是总线架构（ BusArchitecture）和一致性事实（ Conformed Fact）。

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。

如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。

一致性维度建立的地点是多维体系结构的后台（ Back Room），即数据准备区。在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。

在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。

在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。

例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

六、杂项维度###

在维度建模的数据仓库中，有一种维度叫Junk Dimension(“杂项维度”)。
杂项维度是由操作系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。

在操作系统中，我们定义好各种维度后，通常还会剩下一些在小范围内取离散值的指示符或者标志字段。例如：支付类型字段，包括现金和信用卡两种类型，在源系统中它们可能是维护在类型表中，也可能直接保存在交易表中。一张事实表中可能会存在好几个类似的字段，如果作为事实存放在事实表中，会导致事实表占用空间过大；如果单独建立维度表，外键关联到事实表，会出现维度过多的情况；如果将这些字段删除，会有人不同意。这时，我们通常的解决方案就是建立杂项维度，将这些字段建立到一个维度表中，在事实表中只需保存一个外键。几个字段的不同取值组成一条记录，生成代理键，存入维度表，并将该代理键保存入相应的事实表字段。

建议不要直接使用所有的组合生成完整的杂项维度表，在抽取时遇到新的组合时生成相应记录即可。杂项维度的ETL过程比一般的维度略为复杂。