Power BI & Power Pivot 如何建立和维护维度表

157_模型_Power BI & Power Pivot 如何建立和维护维度表

一、背景

在做 Power BI 或者 Power Pivot 项目的时候,在模型中有一类维度表。一般情况下我们会把维度粒度拆解到最小,这样才不会形成笛卡尔积造成数据的冗余。在实际的业务中,维度表的拆解倒是没有问题, 但在 Power BI 或者 Power Pivot 表间关系中只能是单一字段之间建立关系,多字段共同组成的主键在 Power BI 或者 Power Pivot 就有一些问题了。

上述的文字看起来比较绕,我们简单举两个例子。

  • 业务人员当月在 A 部门,下月去了 B 部门,业绩归属的问题应该如何建立维度表。
  • 当前业务门店归属 A 区域,由于组织的调整 下月开始归属到 B 区域,A、B 区域业绩计算应该如何建立维度表。

诸如此类,今天我们来看一下这一类的维度表是如何建立和维护。

二、案例解析

1、最终结果

时间维度未切片的结果。

image-20220617175703125

时间维度分别切片 5 月和 6 月的结果对比。

image-20220617163945535

在这里我们主要观察 业务员1 的变化。

  • 5月,业务员1业务量是 1 + 2 = 3,业务员1归属区域A。
  • 6月,业务员1业务量是 3 + 4 = 7,业务员1归属区域B,这种情况就类比人员区域间调动。

2、维度表解析

在上述图片中,可以看到 月度维度 起到的至关重要的作用;我们按照月份建立最小粒度到业务人员的维度表。

人员是流动的,一般企业内部内人员异动要求的是 1 个月来调整,同时方便后端人员薪酬计算、业绩和费用等归属。

从这样的业务场景我们就要总结一个结论维度表还需要带有时间属性;所以在维度表旁边加了一个字段月份,这样一来我们的维度表加上时间的属性后就是拆解到最小粒度了。

但是同时带了一个问题,我们的月度维度表里面的最小粒度业务员和事实表之间的业务员就不能形成一对多的关系,这样不利于我们的模型建立。

其实这里偷换了一个概念,我最小的粒度其实 月份 + 业务员 才对。在 Power BI 或者 Power Pivot 建模中目前是不能使用两个字段作为主键建立关系的,经过我们分析后在事实表和维度表之间我们需要再增加一个 月份 + 业务员 的字段来作为唯一主键,就可以建立一对多的关系了。

3、辅助主键建立

经过上述分析,我们就建立这样的辅助列作为关系的主键。

维度表还好,我们直接拼接就可以了,但是事实表是按天变化的,这时利用 Power Query 把事实表的日期按照天归集到月份上去即可。

image-20220617170245411

image-20220617170409733

具体的 M 代码也比较简单,关键就是两个函数 Date.ToTextDate.StartOfMonth

维度表 M 代码

let
    源 = 数据源,
    月度维度_Table = 源{[Item="月度维度",Kind="Table"]}[Data],
    更改的类型 = Table.TransformColumnTypes(月度维度_Table,{{"月份", type date}, {"业务员", type text}, {"区域", type text}}),
    增加主键 = Table.AddColumn(更改的类型, "主键", each Date.ToText ( [月份] ,"YYYYMMDD" ) & Delimiter0 & [业务员] ,type text)
in
    增加主键

事实表 M 代码

let
    源 = 数据源,
    事实表_Table = 源{[Item="事实表",Kind="Table"]}[Data],
    更改的类型 = Table.TransformColumnTypes(事实表_Table,{{"日期", type date}, {"业务员", type text}, {"业务量", Int64.Type}}),
    增加主键 = Table.AddColumn(更改的类型, "主键", each Date.ToText( Date.StartOfMonth( [日期] ) ,"YYYYMMDD") & Delimiter0 & [业务员] ,type text )
in
    增加主键

4、表间关系

值得注意的是,这里的 月度维度 其实起到了维度和事实表之间的桥梁作用。最终还是需要把维度单独拎出来。

image-20220617172004456

三、总结

1、对于 DAX 模型,要遵从业务的基本逻辑。

2、在学习 DAX 模型的时候,一般情况不会有这么多变化情况,要根据实际的业务逻辑及时调整模型的搭建。

3、本案例还可以衍生出类似部门曾用名,业务曾用名。

4、当然还有维度表也可能随之变化,建立模型的时候要提前规划,消除这些变化对 DAX 模型的影响。

5、以上对 DAX 模型的搭建者要求还是比较高的,必须充分的理解业务同时对 DAX 模型要一定的认识。

6、月度维度表要及时随着业务的变化及时更新。这一点很重要,这些关系维护正确了也就对整个组织的业务逻辑维护清楚了,分析起来也就更加得心应手了。

附件下载

https://jiaopengzi.com/2784.html

by 焦棚子