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