数据仓库建设：维度处理

1.代理关键字

• 代理关键字一般是指维度表中使用顺序（序列）分配的整数值作为主键，也称为“代理建”
• 代理关键字用于维度表和事实表的连接。在kimball的维度建模领域里，强烈推荐使用代理关键字的。在维度表和事实表的每一个连接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字（Smart Keys）

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

    使用代理关键字的有点：

• 能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说，当数据仓库需要对来自多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。
• 可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整形的，可以减少事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键连接的效率也很高。
• 可以建立一些不存在的维度记录，例如“日期待定”，“日期不可用”等维度记录。
• 可以用来处理缓慢变化维。维度表数据的历史变化信息的保存时数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是使用代理关键字。

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

2.缓慢变化维

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

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

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

1. 直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常成为Type1。
2. 拉链表的方式。通过添加记录来将每一次变化都记录到SCD中，每条记录都有三个字段（如effective_start、effective_end表明记录的有效时期，设定一个Active标志位字段，当字段为TRUE的时候表明这条记录是最新的状态，为false表明是历史记录，其有效期可以通过effetive_start和effective_end字段查询）。如果事实表非常大，为了高效的查询历史变化统计，还建议为拉链表设置代理键为主键，并且在事实表中设置维表的代理建和代码建混合使用，用以应对不同的查询。这就是Type2
3. 添加属性列，来记录最近变化而非全部变化。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用Type1来直接覆盖。这种方式的优点是可以同时分析当前以及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为Type3。
4. 新建一个表来保存历史纪录。除了一个记录当前信息的维度表（Type1）外，单独建立一个历史信息维表，该维表中需要包含有效期间字段（如Effective_start和Effective_end）,并分配代理建作为主键。这通常成为type4。
5. 混合模式。可以看到对于Type 1/2/3，都是对于SCD中渐变属性的处理方式，而针对一个包含多字段的复杂的SCD，可能需要结合以上三种处理方式，这就是type5。比如对于DimCustomer中的用户联系方式属性email，如果业务上并不重要，那么这个字段可以采取Type 1的方式，即每次只保留最新的联络方式，覆盖原来的；假如业务中需要分析用户所在地Region，那么很可能需要用到Type 2，记录每一个Region的改变；而对于地址信息Address，可能并不需要追溯很久的变化，那么加一个Address_Old字段来记录上一次的住址就够了

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

3.退化维度

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

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

4.微型维度

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

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

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

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

5.一致性维度

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

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

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

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

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

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

6.杂项维度

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

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

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

 

 

 

 参考：http://www.jianshu.com/p/a145e15dedfc