如何理解数据仓库中的碎片维度(JUNK DIMENSION)?

0
我理解的Oracle对于碎片维度的解释:

Junk Dimensions 碎片维度
Junk dimensions are abstract dimension tables used to hold text lookup values for flags and codes in fact tables. These dimensions are referred to as junk, not because they have low value, but because they hold an assortment of columns for convenience, analogous to the idea of a "junk drawer" in your home. The number of distinct values (cardinality) of each column in a junk dimension table is typically small.
碎片维度是抽象出来的维度表,用来存储事实表中用到的标志位和编码的文本查找值。这些维度称之为碎片,不是因为它们低价值,而是因为它们为方便存储了不同的列,好比你家里的杂物抽屉一样。碎片维度表中的每个列所含不同值的数量(基数)通常是很小的。
 我理解碎片维度是可以不同事实表共用的,有点类似数据字典表。
但是《Star Schema The Complete Reference》中的碎片维度的说明却是具体到一个事实表的,如下图:

junk_dimension.png
如果一个事实表抽象出一个碎片维表,这样既没有节省磁盘空间,还增加了表连接,有啥好处啊?
已邀请:
1

BAO胖子 - 15年BI经验,涉足电力,快消品,医药,信息服务等行业的BI老兵。 2017-07-06 回答

Junk Dimension几乎都是每个事实表一个,很少公用。
我的理解是Ralph Kimball的Table Structure看起来那么的清爽,你弄一大堆乱七八糟的,而且很多为空的字段在事实表里是怎么个意思?不要把这玩意想得太高大上了,就是有一堆Column,食之无味弃之可惜,“万一”以后分析用呢?不是说好了保持原子数据一万年不变吗?怎么随便就扔了呢?不扔?每个字段,什么各种状态,各种标志,各种没几个人写comment的comment字段,每个都弄一个dimension吗?那就更疯了,所以产生了junk dimension这种不伦不类的东西。
好处还是有的,一个column作为联合主键的一部分,解决了一大堆稀疏column拼凑在一起的尴尬,多多少少能减少点数据占据的空间,但基本上可以无视。索引不用建那么多了,毕竟就一个column在事实表里。未来事实表的源表里面又加了几个不疼不痒的column,你说你在仓库里的事实表是加还是不加?是不是有个junk dimension,这种事就都解决了?
 
最后,纯个人认为,最重要的功能,就是事实表看着清爽了。Kimball老师是完美主义者,太多零碎在事实表里看着闹心。

要回复问题请先登录注册