PowerBI DAX 度量值管理 - 基本编写到高级管理
PowerBI DAX 度量值管理 - 基本编写到高级管理
归结起来，我们要解决的问题包括：
- 管理度量值编写的格式
- 管理度量值如何根据功能进行组织
- 管理度量值如何根据可复用架构进行组织
- 管理度量值的依赖关系
- 批量修改度量值
- 多人编写的分工和整合
我们会用几篇文章来描述这些问题如何在当前的 PowerBI 中实现。很多问题的解决并不是能用 PowerBI 内置功能解决，这也算是一个痛点，按照微软的表述，微软会比较接纳社区的第三方插件与 PowerBI 的结合，一方面可以不必重复劳动，一方面很多社区插件已经注入很多心血，值得复用。
如何编写度量值
这是一个老生常谈的问题，也是一个最基本的问题，如果你有了自己的答案，还是建议你继续看。
先来看几个例子：
[案例1]
sales = Sum(Order[Price])
[案例2]
sales1000=SUMX(FILter(Order,[Price]>1000),[Price])
[案例3]
Sales1000 = SUMX( FILTER ( Order , Order[Price] > 1000 ) )
[案例4]
Sales.Over1000.PY =
CALCULATE( SUMX( FILTER ( Order, Order[Price] > 1000 ) , [Price] ),
DATEADD ( Calendar[date] , -1 ,Year )
)以上内容均是用 DAX 定义的度量值，那么那种写法有问题？
既然大家都认同 SQLBI 的大师，来用大师提供的格式化工具进行处理，可以看到：
sales =
SUM ( Order[Price] )
sales1000 =
SUMX ( FILTER ( Order, [Price] > 1000 ), [Price] )
sales1000 =
SUMX ( FILTER ( Order, [Price] > 1000 ), [Price] )
Sales.Over1000.PY =
CALCULATE (
SUMX ( FILTER ( Order, Order[Price] > 1000 ), [Price] ),
DATEADD ( Calendar[date], -1, YEAR )
)如果你仔细对照案例1~4的原始内容和格式化后的内容就会发现每个案例的原始写法都有问题。如果你看不出差异，那就要考验眼神了。
从社区的实际表现来看，99.99% 的人都无法做到专业的格式化。那有必要这么较真吗？答案是：看你自己。
当你可以把格式写得和机器一样，而且是自然的时候，那么，你一定在每个点都顾及到了业务逻辑到公式的转换，从这个意义上来看，脑中流淌业务逻辑，手下就出来公式，大脑大部分资源在思考业务逻辑本身，而手已经被习惯性的框在一个确定的习惯中，这样，DAX 公式就很快写好了，而且出错概率会大大降低。
那么，对于 DAX 的格式，应该有怎样的要求呢？如果按照与 SQLBI 统一的风格，大致如下：
命名与格式化（务必遵守的约定）
- 【必】采用英文命名
- 【必】使用 AaBb 格式进行命名，如： UnitCost
- 【必】缩写词使用 AB 格式进行命名，如： ID，KPI
- 【必】完整语义之间用 . 分隔，如： KPI.PY
- 【必】度量值分类词之间用 . 分隔，如： Customer.Count.New
- 【必】VAR 引导的变量使用 vAaBb 格式进行命名，使用 v 作为前缀，如： vItemsSelected
- 【必】DAX 表达式中的关键字（函数名，符号等）使用大写英文字母，如： SUMX
- 【必】DAX 表达式中的函数与符号之间使用空格进行分隔，如： Sales = SUM( Order[Value] )
- 【必】DAX 表达式中函数的开始括号与函数名称之前不使用空格，如： Sales = SUM( Order[LinePrice] )
- 【必】DAX 表达式采用 TAB 键和换行进行格式化，如：
- 【可选】命名空间，如： Start，并以 : 引导该命名空间下的内容，如： @BI佐罗:Start:KPI.YTD.PY 表示由BI佐罗编写的 Start 包里的度量值 KPI.YTD.PY
当您可以严格遵守这些约定时，写 DAX 的水平会显著提升。
等等，命名空间，是什么鬼？是的，这是本文首次提出，后面介绍。
用表给度量值提供载体
度量值必须需要一个表作为载体，所以，一般为度量值创建一个表来存放。创建表有两种方法：
- DAX 创建
- 输入数据（也就是 PQ 创建）
推荐使用后者，且不要删除务意义的列，仅做隐藏即可。
这样，将度量值放入表，则有：
用文件夹组织度量值
可以在模型视图，给度量值设置文件夹，如下：
只需要在显示文件夹位置填写你希望的文件夹即可。
点标记定语后置命名法
可以留意到这里采用了点标记命名法：
KPI.PY 表示 去年同期 的 KPI
KPI.YTD.PY 表示 去年同期 的 年度至今 的 KPI
这种命名方式有两个特点：
- 英语命名，这样可以充分利用 DAX 的智能提示。
- . 命名法对定语进行后置，符合英语的习惯； 同时，同类的度量值就排列在一起了； 同时，它特别符合 CALCULATE 的运算逻辑习惯。 如：
KPI.YTD.PY =
CALCULATE(
CALCULATE(
[KPI] ,
DATESYTD( Calendar[Date] )
),
DATEADD( Calendar[Date], -1, YEAR )
)我在所有的项目中都采用了：点标记定语后置命名法。
同一个度量值可以在多个文件夹中
可以看到：
在[显示文件夹]里输入的信息可以通过 ; 分隔，那么就可以显示在两个文件夹里了。
通常在处理某个主题的时候，可以做这样的划分，例如：
可以看出：
Start 作为一个整体，其内部采用了 MVC 的架构方式来进行组织。
再往内部看：
这样，这个结构就非常清楚了。
Start - 作为一个包，以 Start 后跟 : 作为度量值的命名空间。
命名空间
命名空间，又称名称空间，是对复杂命名结构的再划分方式。在各种编程领域中，为了更好的组织各种元素，就会有命名空间的概念。这完全是一个逻辑上的概念，在 DAX 的度量值体系中，有个很好玩的现象是，度量值的名称可以支持非常多的字符，而不受限制。
在 DAX 中，什么时候可以使用名称空间呢？
例如，如果某个部分是来自 ZM 设计编写的度量值，可以用 @ZM: 作为前缀，表示有锅找他。
例如，需要一个主题，RFM或ABC或Z曲线模板，可以用 RFM: ABC: 或 Z: 作为前缀，表示这是一套度量值。
如果这么说，大家比较晕的话，来看一个例子吧。
案例：给自己的模型导入 Z 曲线
Z 曲线由 BI 佐罗设计，并非常强大实用地反映和追踪最新进展。一个场景就是：@ZM开发了Z曲线模板，但里面可能用到一些必备的列，现在需要集成这个内容进入，于是有：
（纯原生构建，核心处只有一个图，无拼接叠图）
预览：
目前该版本的 Z 曲线仅适应 PC 端屏幕尺寸。
您可能对 Z 曲线非常感兴趣。那是当然了，全原生实现为最高决策者制作最简单的目标跟踪套件，随后会整合其中的思想，智慧，实现，具体应用形成课程，本模板纯原生构建，蕴含本文所述所有命名规范。稍后发布，即可开放购买。目前可以预定。
这个模板的牛X之处就在于，它不但可以独立实用，而且可以全部植入到任意项目中，如下：
不难看出，这里的构造是这样的：
Z 曲线是一个整体的包，由一个叫 @ZM 的人构建，这样管理的方式，就可以不会和其他 DAX 度量值混淆了。这样，您就可以导入，至少可以导入我构建的所有通用模块。
我们后续发布更多的通用模块，提供给会员伙伴享用。
如果展开看具体的度量值，可以看出：
这样，由于作者重名的可能性很低，将这一批度量值导入到自己的 PowerBI 中，就可以了。这就要归功于命名空间的使用了。
虽然我们首先提出在 PowerBI 中使用 MVC 设计模式，而很明显在这里我们又超越了 MVC 的限制，采用了包的思想，把一套高度相关的特性打包，并在不同的 PowerBI 中重用。
MVC模式以及包模式，都是为了提升可重用度并增加管理效率的，这里并非来说明包的做法比 MVC 模式更优越，我们建议：
- 对于整体工程的构建，仍然要考虑 MVC 设计模式；
- 对于某个特别功能集的引入或导出以为了未来可重用，则可以考虑包的模式。
总之，我们将经典的软件工程中的一些好的做法和思想移入 PowerBI 的建模工作，但不拘泥于任何一个形式，适合的就行，让工作高效且充满乐趣。
依赖注入
进一步的，为了进一步重用，结合命名空间，我们还可以采用依赖注入的思想，例如：
可以看到，上述 Z 曲线模块的案例，有一个文件夹叫：DependOn，这里将 Z 曲线模块所依赖的所有项目统一罗列，在将这个模块移植到 PowerBI 时，可以检查这里，如下：
由于 PowerBI 的 DAX 目前无法实现很多编程类语言的特点，我们只好通过手工的办法做一些记录。
这里在于说明整个模块依赖于这些列引用，原始数据模型必须包括同等语义的列引用。
此时，在定义 @ZM:Z:AC 的时候，就可以依赖注入了，如下：
到底 Z 曲线的 AC 值怎么计算的，我们根本不 Care ，它的计算由另外的逻辑独立给出，但我们只是使用这个逻辑即可。
这里只是首次提出依赖注入在 DAX 模型中的使用可能，后续也会专门再来描述这个事情。
总结
本文描述了从命名度量值到度量值的高级管理的一些思路，实践以及优势分析。一些主题还未谈及或展开，包括：依赖注入，管理度量值的依赖关系，批量修改度量值，多人编写的分工和整合等，这些我们会后续再做说明。
本文并未高深技巧，您只需要注意到管理度量值就像管理自己的文件或公司一样，需要一些好的实践经验，您可以直接尝试这几个小技巧：
- 使用文件夹
- 仅仅使用一个表来管理度量值，通过文件夹来组织
- 使用度量值的标准写法
- 使用点标记定语后置命名法
- 使用命名空间思想
- 用 Sales: 作为命名空间或包主题
- 用 @某人: 作为最父级命名空间以携带编写人信息，以后有问题好找他，哈哈
@某人:某模块:某度量值.定语.定语.定语 其实就是：
@某人 所编写的 某模块 下的 定语的 定语的 定语的 度量值。
是不是很有意思，赶快自己试试看，来优化自己的模块吧。