对于一个共性问题的讨论---维度代码多选

wuguo1501

在做项目当中遇到这样一个问题:
比如我做一个描述人的事实表,其中一个维度是外貌
那么在外貌这个维度上,有这样几个值
高个 01
胖子 02
...
那么在事实表中,可能很多人的外貌字段里都是01或者02,但也有人是又高又胖的,那么他这个字段的值就是0102

现在问题来了
在前端展现的时候,如果查询高个一共多少人或者胖子一共多少人,怎么办呢,就没法弄了,因为这个0102不属于高个或者胖子
更进一步,在bi做聚合统计的时候,甚至可能要把高个,胖子,又高又胖的人数分布做个比例图出来...

首先被否决的方案1:把0102也作为一个维度代码放入维表.
这样做就意味着这个人只能被作为又高又胖来查询,而且当维表的值很多的时候,这样一个组合排列绝对无法实现.

其次,被否决的方案2:把外貌字段拆开,分为外貌1,外貌2...把0102拆开分别放入外貌1,外貌2...
但这样做,先不说又高又胖的人数没法查询,就光说查询高个的人数,怎么能肯定01被放入了外貌1还是外貌2字段呢?

再次,比较可行的方案3:放弃次要描述,选择首要描述,就是说选择0102只选择01,02放弃掉,这样做相当无奈...
注:这只是举例说明,维度值绝不止高,胖...描述起来也绝不止又高又胖,可能同时用5,6个代码来描述

希望大家能给出更好的建议,也希望以后遇到这个问题的时候大家有个参考的东西.

wuguo1501

多方寻找...应该是找到解决方案了,不敢独吞,共享之
http://www.chinabi.net/Expert/qihongyin/200704/312.html
这篇文章是指导性的,也提出了多值维度这样的概念,由于不给复制,只好把网址拿来了
通过该文,最终解决方案如下:
建立桥连表,用pk_id跟事实表关联,用code跟维表关联
pk_id   code
1         01
1         02
1         03
以上为结构,pk_id为事实表的主ID,把事实表的code 010203拆开放入这个桥连表,code用来和维表关联..
基本上算比较完整的解决方案了
希望给大家启示

ambious

贴出来放到这了

浅析多值维度

在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为“多值维度”。

多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾客放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。
多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。这个与事实表粒度不匹配的诊断维度也称之为多值维度。
处理多值维度最好的办法是降低事实表的粒度。如第二种情况中，将健康护理单分列项事实表的粒度降低到具体的诊断粒度上，这样就避免了多值维度的出现。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。
但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如第一种情况中，事实表是月帐户快照事实表，这张事实表与顾客维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和顾客维度表之间建立个帐户顾客桥接表。这个桥接表可以解决掉帐户维度和顾客维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。
总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如果多值维度不能避免的话，应该建立桥接表来进行处理。

zhujiweibssnc

精彩，谢谢分享啊