如果用一套固定的套路来使用Power BI,这个套路应该是什么。
这个问题在我一开始接触PowerBI的时候就在思考,进过大量实践,略有所得,分享记录如下。表面上都是PBIX文件,但生产它们的过程却完全不同,有的完全是乱做瞎做的,而有的则是通过标准化的方式逐步推进完成的。
在这个小目标里,最难的个人认为是【1套章法】,并且该章法没有形成。Power Query也好,DAX也好,各种参考书也好,都不是章法,至少不是我要的章法。所谓章法,就像棋谱和套路,它基本是固定的思维模式,而且按照这个固定的思维模式应该可以解出理论可解的任何题目。
这里的 理论可解 是很重要的,就是我们必须事先知道一件事能不能做成,如果能做成,那么确定性的路线是什么;如果不能做成,根本原因是什么。在PowerBI中,也不例外,PowerBI对有些事就是无法做成,而对其可以做成的事,是否存在章法,这是我们进行探索的最大乐趣。
玩转 PowerBI 根本不是一个简单的问题,它涉及多个方面和多种能力,简单体会如下:
必须具备三方面的专家级能力:
通常,这些应该是一个团队,当然如果不是一个团队,就需要个人肩负起所有职责。所以,仅仅学习其中任何一点都无法整体驾驭 敏捷商务智能 体系。当然,如果极度严格要求自己,可以全部学习之。
在这个工作流程中,将PowerBI设计从数据源经过:
为了支持更好的完成这个流程,下面总结一个敏捷商务商务智能框架,来框住这些行为以使得行为更加有效。
该套路受到 敏捷软件开发流程框架 的启发并结合PowerBI的特点构建。
套路中的角色包括了上述能力描述中的三种角色外,再包括最终用户在内。
交付成果,是引导一个复杂知识过程走向确定性结果的重要手段。这里包括:
以上三大交付成果在 动态业务分析建模 过程中完成。
以上三大交付成果在 静态语义数据建模 过程中完成。
另外,套路还包括三大交付成果:
套路中包括两个非常重要的流程:
动态业务分析建模 的目的在于形成最终引导用户如何进行分析是更合理的。 静态语义数据建模 的目的在于形成最终的PBIX文件。
很多问题的产生都是因为 动态业务分析建模 不够充分引起的,在 动态业务分析建模 的每个小的阶段,都可以将其交付成果进一步转化为 静态语义数据建模 中的交付成果:
这两步的区别在于:后者可能包括很多的无实际业务语义的辅助表,但仍然属于表格模型的一部分。
通过数据源与业务指标形成语义模型可以采用 DAX 无侵入式设计(此前文章以及会员订阅已有不完全讨论,后续将系统化进一步展开),来实现如何利用数据源实现表示业务指标逻辑的 度量值。 而通过分析流程与语义模型,形成表格模型。则可以进一步使用 DAX 无侵入式设计 与 分析的动态可变性 通过 辅助表 结合实现。
SQLBI 的大师曾给出过多个 DAX 设计模式。但个人感觉还未抽象到更基础的级别,这里给出三种更抽象级别的设计模式,或者说设计模式的模式,它们是:
可以表示为:
下面尝试将你可能以及知道的各种具体实现划入上述三种模式:
对于上述三种分析类型,DAX基本有极为相似的实现(超过了本文探讨范围)。在SQLBI的诸多模式中,也有大部分可以划归到上述分类中。
本文泛泛地整理并总结了:使用 PowerBI 实现个人到企业敏捷商务智能 的可复用套路。其中包括这些要素: