一、杂项维度
在维度建模的数据仓库中,有一种维度叫Junk Dimension,中文一般翻译为“杂项维度”。杂项维度是由操作系统中的指示符或者标志字段组合而成,一般不在一致性维度之列。
在操作系统中,我们定义好各种维度后,通常还会剩下一些在小范围内取离散值的指示符或者标志字段。例如:支付类型字段,包括现金和信用卡两种类型,在源系统中它们可能是维护在类型表中,也可能直接保存在交易表中。
一张事实表中可能会存在好几个类似的字段,如果作为事实存放在事实表中,会导致事实表占用空间过大;如果单独建立维度表,外键关联到事实表,会出现维度过多的情况;如果将这些字段删除,会有人不同意。
这 时,我们通常的解决方案就是建立杂项维度,将这些字段建立到一个维度表中,在事实表中只需保存一个外键。几个字段的不同取值组成一条记录,生成代理键,存 入维度表,并将该代理键保存入相应的事实表字段。建议不要直接使用所有的组合生成完整的杂项维度表,在抽取时遇到新的组合时生成相应记录即可。杂项维度的ETL过程比一般的维度略为复杂。
二、文本事实
在维度建模中,我们经常会遇到一些文本型的事实,它们通常是一些标识信息、属性或者描述信息。这些字段看似属于事实表中的事实,但是它们又不是键、度量事实或者退化维度。
通常,不太建议将这些文本事实字段建立到事实表中,而应该在维度表中给它们找到适当的位置。
当遇到文本型的事实时,我们首先要考虑的应该是这个事实是否属于某个维度表。例如,客户类型标识出每个客户的一个值,应该属于客户维度表。
如果事实不属于已存在的任何一个维度表,我们可以为它们建立单独的维度表或者整合成杂项维度表(Junk Dimension)。建立单独的小维度表是比较容易的方式,但是为增加事实表中的外键个数。这样的维度比较多时,我们可以建立杂项维度表。下面列举了不同情况的一些说明。
1.如果事实表中的维度外键已经很多,如20个左右,那么最好建立杂项维度表。
2.理想情况下,杂项维度的记录数不要超过10万条。如果建立了杂项维度记录过多,可以考虑拆分成独立的维度或者其他杂项维度。
3.从业务规则角度讲,杂项维度中的不同属性应该是不相关的,以免引起误解。如果相关的话,最好不要建立成杂项维度。
另外,如果这个文本是详细的、自由格式的描述信息,并且较少访问的话,把它们建立成事实维度是一个很好的选择。
作者:张子良
出处:http://www.cnblogs.com/hadoopdev
本文版权归作者所有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。