多维分析 - 宽表的利与弊

上篇《多维分析 - 宽表的概念及应用》讲了什么是宽表,,很多厂商都选择了宽表来解决多源关联分析问题,说明宽表肯定有其独到之处,优势有如下这些:

1、提前处理好多表间的关联,用户无需关心底层的表间关联就可以实现数据分析。

2、宽表中包含了业务人员所需的大部分字段,业务人员看起来更加直观。

3、宽表相当于单表操作,避免了多表间的取数关联,效率更高。

但是它有没有缺点,劣势呢?也有:

1、可能出现导致错误的冗余数据。多表关联生成宽表时,有可能 join 时存在一对多的关系,比如:

imagepng

主表订单表中有个销售金额字段,订单明细表中有单价和数量字段,两表通过 id 关联时是一对多的关系,那么在宽表中金额资源就会出现重复,如果通过这个字段汇总数据就会出错。

2、结构维护麻烦

实际使用时业务需求很难固化,宽表中字段可能会出现增减情况,随着数据量的增多,字段的增减会带来极大的性能损耗,尤其增加字段时还要考虑历史数据的处理,这样就要求建立宽表时尽量将字段添加完全,大而全的宽表对资源占用也会相应比较高。

3、有些数据结构难以生成宽表,甚至不能生成,比如下面的机构表:

imagepng

机构表中以层级方式存储公司机构信息,父节点指向上级机构编码,这是一个比较典型的表内自关联模式,转换成宽表时一个层级就是一个字段,如:省、市、县……等,这种自关联模式层级不固定导致生成的字段个数也就无法确定(实际中一些公司可能会有十几个层级),宽表结构无法固定。

即使根据业务人员需求,按照固定层级生成的宽表,可能也无法满足实际业务的需要,比如有销售事实表,结构如下:

imagepng

由于公司发展历程不同,有的省份机构扩展到了乡镇一级,有的省份销售机构还在省级,此时销售表和机构表通过机构 ID 关联生成宽表时,就会生成如下格式:

imagepng
机构层级变的混乱,这种结构也就无法满足业务人员的需要了(应该可以通过复杂 sql 处理,但随着层级的增加难度可想而知)。

再看下另外一种情况,数据结构如下:

imagepng

三张表通过关联字段关联,当要分析销售数据时把部门经理的信息也纳入进来,这样员工表通过部门编号关联到部门表后,部门表中又通过部门经理编号再关联回员工表(因为经理也是一种员工),我们称这种关联方式为互关联,如果要按照经理性别来统计数据的话,那么生成的宽表结构为:

imagepng

可以看到,生成宽表时每发生一次互关联就要多增加一次和源表关联,并且字段个数也随之增加,还要重命名字段,否则业务人员无法分清字段含义(数据库中也不允许重复字段名),宽表的结构同样很难固定。实际业务中,表间的自关联、互关联(或者更复杂的关联)时有发生,理论上可能会产生无穷多的字段,如果业务不固定,那么单个宽表就无法描述所有关联,只能跟随业务需求,有针对的生成相关的宽表,如果这个过程继续依赖于技术人员,就会导致在线分析无法“在线”。

本文简要的列出了宽表在多维分析中利与弊,实际项目中可以根据自身需求以及数据结构来决定是否使用宽表。

以下是广告时间

对润乾产品感兴趣的小伙伴,一定要知道软件还能这样卖哟性价比还不过瘾? 欢迎加入好多乾计划。
这里可以低价购买软件产品,让已经亲民的价格更加便宜!
这里可以销售产品获取佣金,赚满钱包成为土豪不再是梦!
这里还可以推荐分享抢红包,每次都是好几块钱的巨款哟!
来吧,现在就加入,拿起手机扫码,开始乾包之旅



嗯,还不太了解好多乾?
猛戳这里
玩转好多乾