PowerBI中的模型关系相信小伙伴们都不会感觉到陌生，因为一份优秀的报表无法离开数据模型的支撑。 对比其它BI类工具而言，白茶认为其建模功能才是最为突出的功能点。 模型关系类型 PowerBI中我们常用的模型关系一共包含5类： 一对一关系(1:1) 一对多关系(1:*) 多对多关系(*:*) 虚线关系(1:N) 无关系 多对一关系在白茶看来与一对多其实没有太大区别，这里就不单独罗列了。 一对一 一对一关系通常表示维度表中的所有维度与事实表中都是一一对应的。 假设Dim表中只有3行数据，那么与之对应的Fact表也是只有3行数据，这种场景在实际应用中并不多见。 一对一...

场景介绍： PowerBI在使用计算组进行数据格式转化的时候，有时候逻辑明明是正确的，但是呈现的结果却差强人意。 那么这个问题是如何产生的呢？又该如何规避么？ 案例 场景1：占比错误 可以看到数据是非常简单的。 我们打开Tabular Editor添加如下计算组： SELECTEDMEASURE() 将该计算组数据格式设置如下： [计算组格式] & "("     & FORMAT ( [占比], "0%" ) & ")" 到这里...

问题描述： PowerBI在实际使用中，针对于某些数据，需要呈现文本类型的标签，一般这类需求，都是通过计算组来解决的。 但计算组在使用中，也会存在一些问题，就是一旦点击交互，就会影响到其它度量值。 案例 案例数据非常的简单，我们继续添加如下度量值。 计算组格式 = SUM ( [计算组值] ) 其他度量值 = SUM ( '案例数据'[其他值] ) 将其拖拽到可视化中呈现如下： 打开Tabular，添加计算组 也可以直接在PowerBI中添加，看个人操作习惯。 SELECTEDMEASURE() ...

需求描述： 某些特殊的场景下，针对某页看板，需要进行数据权限卡控，但是又不能对全部的数据进行RLS处理，这种情况下可以利用计算组来解决这个需求。 实际场景 事实表包含产品维度和销售维度 两个维度属于同一公司下面的不同架构体系 要求用户在查看不同页面的时候，根据不同的体系进行控权 案例数据 数据比较简单，分别是销售维度、产品维度、事实表以及权限表。 模型关系如下图： 构建基础度量值： Amt =  SUM ( 'Fact'[销售金额] ) Qty =  SUM ( 'Fact'...

应用背景 数据的本质是为了业务服务，从而达到更高效的工作方式，实现数据对业务的赋能和推动作用。 因此在构建报表时，需要开发者有设计思维，能够考虑多种应用场景，帮助业务解决实际应用中的问题。 例如，在实际业务场景中，管理层用户习惯向下管理的方式，那么在查看报表时，能否也保留这种方式呢？ 规则描述 组织架构分为多级，1级、2级、3级，数字越小，级别越高 上级用户有权限查看下属子部门数据 各级用户在查看报表时，默认展开下级部门，例如1级部门用户，则展示下属所有2级部门，以此类推 当用户分管多个平级部门时，则展示自身所在层级，不进行展开 案例数据 图1和图2两张事实表分别存...

白茶在上一篇文章PowerBI迁移到SSAS向小伙伴们介绍了如何将已经开发好的PowerBI模型迁移到SSAS整个操作过程，与此同时也带来了新的问题，那就是SSAS的模型该如何刷新呢？ 配套工具 SSMS Visual Studio SSIS SSIS[1]的全称是SQL Server Integration Services，是微软传统BI的组件之一。基于Visual Studio开发工程文件包，部署到Microsoft SQL Server运行，是一种ETL处理工具，与SSAS、SSRS并称为微软传统BI三件套。 实现SSAS模型的方式有2种，一种是基于SQL Serve...

业务场景： 企业初期在进行 BI 可视化路线的时候，往往不会选择方案较为完整的SSAS，而是会选择轻量的 PowerBI 方案，究其根本还是软件成本的问题。 但是随着模型越来越臃肿，维护成本越来越高，有很多模型需要进行增量更新，这种情况下，服务器吃不消，需要 SSAS 进行负载分摊，那么如何将 PoweBI 已经搭建好的模型转移到SSAS中呢？ 配套工具 SQL Server SSMS Visual Studio PowerBI DAX Sudio 或 Tabular Editor 注意，如果想将 PowerBI 的模型完整迁移到 SSAS 中，我们需要获取到Mod...

PowerBI报表在开发的过程中，经常会遇到数据量非常庞大的情况，在这种情况下，本机连接数据源如果不进行特殊处理的话，那么刷新数据的时候可能会发生数据刷新时间过长、数据加载内存错误、开发过程中构建DAX卡顿等情况。 那么在实际开发中，我们应该如何处理呢？其实，在PowerQuery页面，我们可以对查询进行过滤处理的。 在PowerQuery中进行过滤处理，我们需要区分两种情况，一种是可以在连接数据源时构建SQL语句的，一种是不可以的，感兴趣的小伙伴可以翻阅官方文档关于查询折叠[1]的相关内容，这里就不赘述了。 案例：可构建SQL语句 白茶在本机搭建了一个临时的SQL Server数据库，我们...

小A：白茶，救命啊~~~ 白茶：什么情况？ 小A：是这样的，最近不是临近项目上线嘛，有一大波度量值需要进行类似的调整，一个两个倒没啥，600多个，兄弟，救命啊~~~ 白茶（假装沉思）：兄弟，你这个事不好搞啊！ 小A（眼神暗示）：放心 ，规矩我懂！ 白茶：开搞开搞！ 在实际业务场景中，上述情况产生的频率是非常高的，究其根本，其实有三种原因： 业务逻辑在频繁的改动，牵一发而动全身 数据来源驳杂而不唯一 KPI指标过多，观察口径统一 举个例子 假设现在存在以下度量值： Amt = SUMX ( 'Fact_Sales', 'Fact_Sales'[Quantity] * RELA...

小A：白茶，救命啊~~~白茶：什么情况？小A：是这样的，最近不是临近项目上线嘛，有一大波度量值需要进行类似的调整，一个两个倒没啥，600多个，兄弟，救命啊~~~白茶（假装沉思）：兄弟，你这个事不好搞啊！小A（眼神暗示）：放心 ，规矩我懂！白茶：开搞开搞！在实际业务场景中，上述情况产生的频率是非常高的，究其根本，其实有三种原因：业务逻辑在频繁的改动，牵一发而动全身数据来源驳杂而不唯一KPI指标过多，观察口径统一举个例子假设现在存在以下度量值： Amt = SUMX ( 'Fact_Sales', 'Fact_Sales'[Quantity] * RELATED ( Dim_Product[Pr...

当选择Power BI作为业务报表平台时，如何判断许可证的选择是否符合业务需求，价格占了主导因素。 Power BI的定价是基于SKU和服务器内核决定的，但是很多IT的负责人都不确定自己公司业务具体需要多少。 不幸的是，Power BI的容量和预期使用量的比率很难进行量化的评估。 注：本文非原创，是搬运过来的，原文链接[1]在文章末尾。 例如： 一家公司可能有一个非常大的数据模型，需要占用大量的内存和CPU来进行长时间的刷新，高峰期有20个用户，每小时刷新一次，查询都非常简单，并且允许查询折叠。 另一家企业可能有6个较小的数据模型，高峰期有950个用户，每天刷新，数据模型的查询都非常非常复杂...

BOSS：那个，那个谁，最近用户反映了，说是你们做的报表不太行啊？！ 白茶：（？？？）老板，怎么说？ BOSS：就是能不能让**用户在报表上自己调整某个可视化？**比如柱形图调整为环形图或者明细表啥的？（苍蝇搓手！） 白茶：（假装沉思...）老板，这个有点难啊.... BOSS：放心，规矩我懂！（胸脯拍得啪啪作响） 白茶：稍等，我研究研究。 在报表使用过程中，用户经常会想着能不能自己动手，在当前报表的基础上，自己有一些个性化的DIY操作，来满足自助化分析的需求，毕竟报表开发者，有时候并不能百分百的Get到业务的痛点。 其实Power BI中是有这个功能的。 案例 案例数据比较简单，将其导...

PowerBI自带的数据钻取功能，在实际应用中是用户使用度较高的功能之一，特别是需要实际操作的业务用户，往往需要根据汇总的结果定位到相关的明细数据，以便进行下一步的流程操作，这种场景下钻取功能显得尤为便利。 关于钻取功能，白茶之前也介绍过，包括云端的跨页钻取，本期是结合特定的场景进行实际应用的介绍，偏向于业务会多一些。 先来看看本期的案例数据： 数据较为简单，一张事实表。将其导入到PowerBI里面。 案例数据与以往的不同，偏向于商机类型的数据，一般数据来源于SalesForce结构会与此类似，SAP系统中关于销售订单类型的数据，也符合本期的应用场景。 商机数据的划分，前几个阶段都属于未关...

白茶在之前的文章中，给大家介绍过Rank函数的应用场景，其实与Rank函数同时推出的还有RowNumber函数，二者之间有一些差异，但是总体应用的场景基本类似。 RowNumber函数基本语法 ROWNUMBER ( [<relation>][, <orderBy>][, <blanks>][, <partitionBy>][, <matchBy>] ) 参数介绍： relation：可选项，排名依据的表或表表达式。 orderBy：可选项，排序依据，如果省略，第2参数需绑定。 blanks：可选项，处理空值排名位置使用。 part...