聊聊建模的那些事儿。

我们往往花了大量的时间学习DAX，花了大量的精力试图理解行上下文这些抽象的概念。甚至花更多心思绞尽脑汁的研究M语言。但实际上，往往忽略了一个非常重要的切入点，那就是建模。

很多时候，我们拿着若干数据表，着急进行数据清洗，然后简单的找几个表建立几个关系后，就开始上DAX分析了。各种函数运用，各种高技术难度的分析一大顿之后，发现达不到想要的分析效果。或者用DAX时，感觉无从下手。其实大概率是忽视了建模，这个从战略上宏观上把控、规划、构思整个数据分析体系的过程。建模搞好了，很大程度上用不了多么花里胡哨的DAX就能解决战斗。

讲DAX的资源若干，讲各种花里胡哨的可视化控件配置技巧的资源也不少。但能真正关注建模的少之又少。我想可能因为建模，大部分其实需要的是软技术。好像除了说说所谓的星型模型外就没啥好讲的了。但其实这里面有很多需要提前注意的细节。

我在学习powerbi初期的时候，在某网上买了一个从财务角度讲powerbi的，看完一遍后，我觉得能学到东西，但是很多概念依然模糊，一看就会，然后自己就是不会。所以转向在udemy上听英文的课程，明显感觉思路要比上一位大拿的更加清晰、系统。这个过程中模糊的概念逐渐明白了。其中一个最重要的点，就是永远先搞明白我们用powerbi搞分析报告是给谁看的，这一客户或者叫用户导向。

有给客户看的，有给领导老板看的，有给不同业务部门的同事看的，有给自己用的，甚至还有一些纯粹就是秀肌肉的，等等。不同的用户画像，意味着报告需要展示的角度有区别；意味着分析的维度、切入点是不尽相同的。所以，我在每次开发报告之前，一定要问自己：这个报告是给谁看的？要解决什么问题？必须清楚的回答这个问题，然后才开始下一步。这里我们往往就能找到并明确分析报告的目的，分析维度，需要的数据。这些事情，一定是建模开始的大前提。

罗里吧嗦一大顿，来看下建模到底是要做什么的吧。

两件事：

第一件事：

确定表

两类表，一类是维度（筛选）表，另一类是事实（数据）表。

我们需要明确报告中要用到哪些表？哪些是维度表（筛选表）？需要哪些事实表（数据表）？

每个表里面需要哪些列（字段）？数据表的量级？（多少列？多少行？）对于不需要的字段、表，要有所取舍。

我们先看事实表（数据表）。因为大概率，我们要整报告了，一定是手头已经有了不少表、数据了。这些表里面，大概率是事实表。

事实表实际就是业务运行的流水记录表，是用来跟踪实际数据的。是记录明细数据的表，是分析的数据来源。比如：进销存流水、payroll、KPI目标清单、交易记录。。。

需要了解数据表有多大？多少行？几百行？几千行？几百万行？

我们写度量值，比如进行聚合运算时，通常是针对数据表的。

再来看维度表（筛选表）

按照分析的维度，建立适当的足够的维度表。维度表实际上也就是业务属性表的集合。

比如：想要按照日期来分析，那就要有日期表；想要按照时间来分析，那就建立时间表；想要按照客户分析，那就要有客户表；想要按照产品分析，那就要建立产品表；想要看人力资源的情况，那就要有无姓名重复的花名册表；

维度表中将来要用作建立关系用的字段（主键），要确保唯一，无重复。

维度表有时候可以通过处理事实表来获得：比如复制事实表，保留必要的列，并且对剩余列去除重复。

第二件事：确定它们之间的关系

在两个表中各选择一个字段，建立关联关系

推荐1对多，有些情况下会出现1对1。而且是从维度表指向事实表的1对多的关系，是单向的

不要用多对多，不要用多对多，不要用多对多。重要的事情讲三遍。

一般不要在事实表之间建立关系

星型的关系为首选，实际上，最好只用这种关系模型，并且后面的扩展和延升都是基于这种模型。

事实表在中心，维度表在外围，筛选方向从维度表指向事实表，建立1对多的关系。

星型的拓展：瀑布，或者雪花状的。这里其实就是对星型的向外扩展和延伸。这种延申扩展，实际上也仅仅是对维度表的，也就是出现了维度表的层级关系。这种关系也通过1对多或者1对1的关系，建立从高一级的维度表到低一级的维度表间的关系。而对于数据表之间，依然是不推荐建立任何关系的。尤其是多对多的关系。

星型建模的好处：

执行效率高，速度快

刷新速度快

逻辑清晰

好的建模应该是：

尽量用多表，也就是将数据按能细分为大类的形式，分到更多的表格中。并建立关系。减少并控制每个表中的列数，也就是字段数。列太多的时候，当数据行逐步增加时，会占用更大的内存，影响数据分析效率，更重要的是后续报告的可扩展性会比较差。

要保持维度表的唯一性。

控制减少冗余和前后矛盾的数据。不要搞太大的事实表。

保持数据的完成性。

优化存储空间。

提高数据加载刷新速度。