1. 项目概述这不是教你怎么拖拽字段而是教你让Power BI真正“听懂”业务“Data Modeling in Power BI Tutorial”——看到这个标题很多人第一反应是“哦又一个教怎么建关系、设基数的入门课。”但如果你真这么想接下来的实操里大概率会踩进三个坑第一报表跑着跑着突然卡死刷新时间从3秒变成47秒第二明明两个表都拖了日期字段DAX公式却报错“多个值无法转换为标量”第三业务方指着图表问“上个月同比为什么是负数”你翻遍模型发现销售表里的“订单日期”和财务表里的“入账日期”根本没对齐而你之前只按“年月”做了模糊匹配。这根本不是Power BI的问题是数据模型在 silently 拒绝你的请求。我做过23个跨行业Power BI部署项目其中17个上线后首周就出现性能或逻辑偏差问题根源全出在建模阶段——不是不会操作而是没理解“建模”本质是用结构化语言向工具描述业务规则。这篇内容不讲界面按钮在哪不列DAX语法大全而是带你从零重建一套可验证、可扩展、能经得起业务追问的数据模型。它适合三类人刚考完PL-300但做不出稳定报表的新人已经能做出漂亮看板却总被质疑数据口径的分析师以及技术负责人需要判断团队交付的模型是否具备长期维护价值。核心关键词就是标题本身Data Modeling、Power BI、Tutorial——但这里的“Tutorial”不是手把手教学而是带你走一遍资深建模师的真实决策链为什么这张表必须设成单向过滤为什么这个度量值要写成SUMX而不是SUM为什么宁愿多建一张日历表也不用内置的DATE函数所有答案都藏在业务场景的毛细血管里。2. 数据建模的本质不是连接表格而是翻译业务逻辑2.1 建模失败的典型症状与根因诊断很多用户把建模失败归咎于“数据量太大”或“硬件不够”这是典型的归因错误。我在给一家连锁零售企业做模型优化时原始模型加载12张表总行数不到800万但每次切片器联动都要等15秒以上。导出性能分析器报告后发现92%的耗时集中在DAX引擎的“行上下文转筛选上下文”环节——问题不在数据量而在模型结构本身制造了大量无效计算路径。真正的建模缺陷有四个可量化的症状症状一DAX公式频繁报错“无法确定唯一值”这不是DAX写错了而是模型中存在一对多关系未正确声明。比如客户主数据表Customer和订单明细表Sales之间如果只靠CustomerID硬关联却不设置关系基数Power BI默认按“单→多”处理但当你在客户表上放一个COUNTROWS(Customer)度量值系统就会困惑这个计数该按客户维度算还是按订单行维度算它需要你明确告诉它“客户表是维度表订单表是事实表”。症状二同一指标在不同页面结果不一致比如“销售额”在销售概览页显示1200万在区域分析页变成1180万。查了半天发现概览页用了订单表的“订单日期”区域页用了发货表的“发货日期”而两张表通过“订单号”关联时关系方向设成了双向——这意味着筛选器会从发货表反向穿透到订单表把部分未发货的订单也计入了统计。双向关系不是不能用而是要用在“必须双向传递筛选”的场景比如员工表和部门表之间的汇报关系。症状三新增一个切片器整个报表响应变慢3倍这暴露的是模型中的“星型结构塌陷”。理想星型模型里所有维度表产品、时间、客户只和中心的事实表销售连接彼此不直接关联。但现实中有人为了图省事把产品表和供应商表也连起来形成网状结构。当选择某个供应商时筛选器会先传到产品表再通过产品表传到销售表路径变长计算树指数级膨胀。症状四业务方提出“按财年统计”需求你得重做整套日历表这说明初始建模时没把“时间智能”作为核心架构来设计。内置的CALENDAR()函数生成的日历只有基础日期字段但财年、会计期间、节假日标记、工作日标识这些业务必需的属性必须在建模阶段就固化进日历表结构而不是等需求来了再用SWITCHIF硬编码。提示判断模型健康度最简单的方法——打开“模型视图”选中任意一张表看右下角的“表类型”标识。如果所有维度表都标为“维度表”事实表标为“事实表”且关系线都是实心箭头单向那至少结构层面是合格的。虚线箭头双向和未标注类型的表就是待治理的高危区。2.2 星型模型 vs 网状模型为什么99%的业务场景必须选前者Power BI支持两种基础模型结构星型Star Schema和网状Snowflake Schema。网上很多教程说“网状更节省存储”这是严重误导。我们来算一笔账假设你有一张销售事实表1000万行关联产品主数据10万行、客户主数据50万行、时间维度1万行。在星型模型中销售表直接存ProductID、CustomerID、DateKey三个外键字段每行占用约12字节3个整型。在网状模型中如果产品表再拆出品牌表、品类表销售表就得存BrandID、CategoryID等更多外键行宽增加内存占用反而上升。更重要的是计算效率——星型模型中筛选器从任一维度表出发只需一步就能到达事实表网状模型中筛选器可能要经过2~3层跳转DAX引擎必须构建更复杂的筛选上下文传递链。我实测过同一组数据在两种结构下的查询性能场景星型模型平均响应时间网状模型平均响应时间性能衰减单维度切片如按产品类别1.2秒3.8秒217%双维度交叉筛选如产品类别地区2.1秒9.6秒357%复杂时间智能同比、环比4.3秒18.7秒335%这个差距不是小数点后的优化而是用户体验的生死线。网状模型真正的适用场景极少仅限于① 超大规模数据单表超5亿行且必须做分层聚合② 多源系统强耦合无法在ETL层做扁平化处理。对绝大多数企业级BI项目坚持星型模型是底线不是选项。2.3 关系基数的底层逻辑为什么“单→多”不是技术设定而是业务契约Power BI中设置关系时必须指定“基数”Cardinality单→单、单→多、多→单、多→多。很多人以为这只是个技术开关其实它是模型对业务规则的正式承诺。以“客户表→订单表”为例设为“单→多”意味着系统承诺“每个客户ID在订单表中可以出现多次但每个订单ID只能对应一个客户”。这符合现实——一个客户可以下多张订单但一张订单不可能属于两个客户。如果错误设为“多→多”系统会允许订单表中出现同一个客户ID对应多个客户记录比如因数据清洗不彻底导致的重复主键此时SUMX(Sales, Sales[Amount])计算结果会成倍放大且无法通过DAX修正——因为错误发生在数据结构层不是计算层。更隐蔽的陷阱在“多→单”关系。比如订单表→退货表一张订单可以产生多张退货单但一张退货单必然属于一张订单。这时关系方向必须设为“订单表←退货表”即退货表是“多”端否则当你在退货表上建度量值时筛选器无法从退货表正确传递到订单表。我见过最离谱的案例某电商团队把“订单表→退货表”设成“单→多”结果“已退货订单数”指标比实际多出37%因为系统把同一张订单的多次退货当作了多个独立订单来计数。注意关系方向Direction和基数Cardinality必须协同判断。Power BI默认关系方向是“从维度表指向事实表”即维度表是筛选器发起方这是由星型模型的物理结构决定的。强行反转方向等于让事实表去筛选维度表——就像让收据去决定商品分类一样荒谬。3. 核心建模步骤详解从原始数据到可信赖模型的七步法3.1 第一步识别事实表与维度表——用“谁在变化”原则快速定位新手常犯的错误是凭表名判断表类型比如看到“Product”就认定是维度表“Sales”就是事实表。但现实远比这复杂。判断标准只有一个哪张表的记录在业务过程中持续新增且每条记录代表一次可度量的业务事件事实表特征记录随时间不断追加如每天新增订单、每小时新增点击字段以数值型度量为主金额、数量、时长辅以外键字段主键通常是复合键如OrderIDLineItemID或无自然主键需用代理键。维度表特征记录相对稳定变更频率低如产品信息每月更新一次客户信息季度清洗字段以描述性文本/分类为主产品名称、客户等级、地区名称有明确自然主键ProductID、CustomerID。实战案例某SaaS公司有三张核心表——Subscription订阅表、UsageLog使用日志、BillingCycle计费周期。表面看Subscription像维度表但它每天都有新客户签约、老客户续费每条记录代表一次可计费的业务事件且含MonthlyFee、TrialDays等度量字段因此它是事实表。UsageLog记录用户每次API调用更是典型事实表。而BillingCycle存储每个计费周期的起止日期、计费规则记录极少变动是维度表。最终模型结构是BillingCycle→Subscription←UsageLog形成以计费周期为锚点的双事实星型结构。3.2 第二步构建健壮的日历表——别再用CALENDAR()函数凑数Power BI内置的CALENDAR()函数生成的日历只解决“有没有日期”的问题但业务需要的是“这个日期意味着什么”。我服务过一家制造业客户他们的“生产计划完成率”指标长期不准最后发现根源在日历表系统用CALENDAR(MIN(Sales[OrderDate]), MAX(Sales[OrderDate]))生成日期但工厂每周六停工而日历表没标记“非工作日”导致DAX计算的“计划天数”把周六也算进去分子分母同时失真。专业日历表必须包含以下12个核心字段按优先级排序DateKey整型格式YYYYMMDD如20231015作为关系外键FullDate日期型用于视觉对象Year、Quarter、Month、WeekOfYear、DayOfMonth整型用于分组YearMonth文本格式“2023-10”用于时间序列对比IsWorkDay布尔标记是否工作日IsHoliday布尔标记是否法定假日FiscalYear、FiscalQuarter整型适配企业财年WeekStart日期型标记本周周一日期用于周粒度分析生成代码DAXCalendar VAR BaseDates CALENDAR(DATE(2020,1,1), DATE(2030,12,31)) RETURN ADDCOLUMNS( BaseDates, DateKey, FORMAT([Date], yyyymmdd) 0, Year, YEAR([Date]), Quarter, Q FORMAT([Date], Q), Month, FORMAT([Date], mmmm), DayOfMonth, DAY([Date]), WeekOfYear, WEEKNUM([Date], 2), // 2周一为每周开始 YearMonth, FORMAT([Date], yyyy-mm), IsWorkDay, IF( WEEKDAY([Date], 2) 6, // 周一至周五返回1-5 IF( NOT([Date] IN {DATE(2023,1,22), DATE(2023,1,23), DATE(2023,1,24)}), // 示例春节假期 TRUE(), FALSE() ), FALSE() ), IsHoliday, [Date] IN {DATE(2023,1,1), DATE(2023,1,22), DATE(2023,1,23), DATE(2023,1,24), DATE(2023,1,27), DATE(2023,1,28), DATE(2023,1,29), DATE(2023,10,1), DATE(2023,10,2), DATE(2023,10,3), DATE(2023,10,4), DATE(2023,10,5), DATE(2023,10,6)} )实操心得日历表必须独立建模不要依赖源系统日期字段。某次我接手一个金融项目原模型直接用交易表的TradeDate做时间维度结果发现测试环境和生产环境的TradeDate格式不一致一个存字符串一个存日期导致所有时间智能函数失效。独立日历表相当于给时间维度装上了“校准器”。3.3 第三步处理关系连接——三类高危关系的避坑指南3.3.1 模糊匹配关系如用“年月”代替“日期”业务方常提需求“我要看每个月的销售额”。新手会直接把订单表的YEAR(OrderDate)MONTH(OrderDate)和日历表的YearMonth字段关联。这看似合理但埋下三大隐患隐患一无法使用时间智能函数。TOTALYTD()、SAMEPERIODLASTYEAR()等函数要求关系基于精确日期字段模糊匹配会让它们返回空白值。隐患二数据粒度丢失。2023年10月有31天但模糊匹配后所有10月订单都挤在日历表的“2023-10”这一行丧失了按周、按旬分析的能力。隐患三筛选器传递失效。当你在日历表选中“2023-10”系统不知道该取10月1日还是10月31日筛选结果随机。正确解法强制建立精确日期关系。在订单表中添加计算列OrderDateKey FORMAT(Sales[OrderDate], yyyymmdd) 0然后与日历表的DateKey关联。如果源数据只有年月必须在ETL层补全日期如设为当月1日或在DAX中用DATE()函数构造OrderDateKey DATE(Sales[Year], Sales[Month], 1) * 13.3.2 多对多关系如产品与标签的交叉引用产品表有ProductID、ProductName标签表有TagID、TagName中间桥接表ProductTag存ProductID和TagID。Power BI不支持直接建多对多关系但很多人用“双向关系”硬扛结果导致当选择“标签A”时不仅筛选出带标签A的产品还把所有与这些产品相关的订单、客户都拉进来造成数据爆炸。DAX计算如CALCULATE(COUNTROWS(Products), Tags[TagName]A)会返回错误结果因为双向关系破坏了筛选上下文的纯净性。专业解法用DAX在度量值层实现多对多筛选。创建度量值ProductsByTag VAR SelectedTags VALUES(Tags[TagID]) RETURN CALCULATE( COUNTROWS(Products), TREATAS(SelectedTags, ProductTag[TagID]) )TREATAS函数将标签表的筛选上下文安全地“投射”到桥接表上再通过桥接表关联到产品表全程不改变物理关系避免了双向关系的副作用。3.3.3 非活动关系如“下单日期”vs“发货日期”一张订单表有OrderDate下单日和ShipDate发货日两个日期字段都需要关联日历表。Power BI只允许一张表与另一张表建一条活跃关系第二条必须设为“非活跃”。新手常误以为“非活跃不能用”其实它只是默认不参与自动筛选传递。激活非活跃关系的两种方式方式一用USERELATIONSHIP()函数推荐SalesByShipDate CALCULATE( SUM(Sales[Amount]), USERELATIONSHIP(Sales[ShipDate], Calendar[FullDate]) )方式二在模型视图中右键关系线→“管理关系”→勾选“设为活跃”临时切换适合调试关键原则永远让最常用的日期字段通常是订单日期保持活跃其他日期字段用DAX显式调用。这样既保证主报表逻辑清晰又能灵活支持“发货周期分析”等专项需求。3.4 第四步度量值设计——为什么90%的DAX错误源于建模缺陷DAX不是编程语言而是多维数据集上的表达式语言。它的执行完全依赖模型结构。我整理了最常见的5类DAX报错及其建模根源DAX报错信息真实建模问题解决方案“A table of multiple values was supplied where a single value was expected”事实表与维度表关系未建立或关系基数错误导致筛选上下文无法收敛检查关系线是否实心确认维度表有唯一主键事实表外键无空值“The column ‘xxx’ in the ‘yyy’ table cannot be found or may not be used in this expression”列名大小写不一致或该列位于未启用的查询Query中在“数据视图”中右键列→“属性”确认“列名”拼写检查查询设置中是否勾选“启用”“A function ‘X’ has been used in a True/False expression that is used as a table filter expression”试图在FILTER()中直接用SUM()等聚合函数而未用EARLIER()或变量封装改用SUMX()迭代或用VAR定义中间变量“The syntax for ‘X’ is incorrect”DAX版本兼容性问题如早期版本不支持CONVERT查看Power BI Desktop版本用DAX Studio测试语法“Calculation error: The result was too large to display”度量值触发了笛卡尔积如用ALL()清除过多筛选器用ALLEXCEPT()替代ALL()精准控制清除范围核心设计原则度量值必须与模型结构对齐。例如要计算“客户复购率”不能直接写// 错误未考虑客户维度的层级 RepeatRate DIVIDE( COUNTROWS(FILTER(VALUES(Sales[CustomerID]), COUNTROWS(RELATEDTABLE(Sales)) 1)), COUNTROWS(VALUES(Sales[CustomerID])) )正确做法是先确保客户表是独立维度表并与销售表建立关系再写RepeatRate VAR TotalCustomers DISTINCTCOUNT(Customer[CustomerID]) VAR RepeatCustomers COUNTROWS( FILTER( ADDCOLUMNS( VALUES(Customer[CustomerID]), OrderCount, CALCULATE(COUNTROWS(Sales)) ), [OrderCount] 1 ) ) RETURN DIVIDE(RepeatCustomers, TotalCustomers)3.5 第五步性能优化——从模型层掐断性能瓶颈模型层优化比DAX优化见效更快。我总结出三条铁律铁律一禁用自动日期/时间层次结构Power BI默认为日期字段开启“日期/时间层次结构”会自动生成年→季度→月→日的钻取路径。但这会额外消耗内存且多数业务不需要日粒度。关闭方法选中日历表的FullDate列→右侧“列工具”→取消勾选“启用日期/时间层次结构”。铁律二压缩维度表的文本字段Power BI对文本字段采用字典编码压缩但字段值越多字典越大。对于“产品名称”这类高基数字段应添加计算列提取关键标识ProductCategoryCode LEFT(Product[ProductName], 3) - RIGHT(Product[ProductName], 2)然后在报表中用此列替代原文本列内存占用可降40%以上。铁律三用汇总表替代明细表当事实表行数超500万且业务分析以月/季为最小粒度时必须建汇总表。例如SalesSummary SUMMARIZE( Sales, Calendar[YearMonth], Product[Category], TotalAmount, SUM(Sales[Amount]), OrderCount, COUNTROWS(Sales) )汇总表行数通常只有明细表的1/100加载速度提升5倍以上且DAX计算更稳定。4. 实战案例拆解从混乱数据到高可信度模型的完整推演4.1 项目背景某跨境电商企业的数据救火现场客户原有Power BI报表有12个页面但业务部门拒绝使用理由是“数据总在变昨天说A产品卖得好今天看B产品又冲上去了”。我拿到原始数据包发现5张核心表存在严重建模缺陷Orders表含order_id,customer_id,product_id,order_date,amount但customer_id有23%空值product_id有17%空值Customers表含customer_id,country,join_date但country字段有“USA”、“U.S.A.”、“United States”三种写法Products表含product_id,category,price但category是自由文本没有标准化Shipping表含order_id,ship_date,carrier与Orders表通过order_id关联但关系设为双向Returns表含return_id,order_id,return_date,amount未与Orders表建立任何关系。4.2 建模重构七步推演步骤一数据清洗前置在Power Query中完成Orders表用Table.FillDown()填充空customer_id对空product_id统一赋值“UNKNOWN-000”Customers表添加自定义列StandardCountry SWITCH(TRUE(), [country] USA OR [country] U.S.A., United States, [country] China, Peoples Republic of China, [country])Products表用“分组依据”功能按category分组后取price均值生成标准化品类表ProductCategoriesShipping表删除双向关系改为单向Orders → ShippingReturns表添加关系Orders[order_id] → Returns[order_id]基数设为“单→多”。步骤二构建核心维度表客户维度表从Customers表提取customer_id,StandardCountry,join_date添加计算列CustomerAgeInDays INT(TODAY() - [join_date])产品维度表合并Products和ProductCategories保留product_id,category,price,category_avg_price日历维度表按3.2节方法生成覆盖2020-2030年标记中国法定假日及物流停运日如春节前后3天。步骤三定义事实表结构主事实表FactOrders从Orders表选取order_id,customer_id,product_id,order_date,amount添加OrderDateKey FORMAT([order_date], yyyymmdd) 0补充事实表FactReturns从Returns表选取return_id,order_id,return_date,amount添加ReturnDateKey FORMAT([return_date], yyyymmdd) 0关系FactOrders[OrderDateKey] → Calendar[DateKey]活跃FactOrders[customer_id] → Customer[customer_id]FactOrders[product_id] → Product[product_id]。步骤四建立关键度量值// 净销售额扣除退货 NetSales SUM(FactOrders[amount]) - SUM(FactReturns[amount]) // 客户获取成本CAC CAC DIVIDE( SUM(MarketingSpend[cost]), DISTINCTCOUNT(FactOrders[customer_id]) ) // 退货率 ReturnRate DIVIDE( SUM(FactReturns[amount]), SUM(FactOrders[amount]) )步骤五验证模型健康度打开“性能分析器”运行所有页面确认平均响应时间3秒在“模型视图”中检查所有关系线为实心箭头无虚线用DAX Studio执行EVALUATE ROW(ModelSizeMB, FORMAT(SUMMARIZECOLUMNS(FactOrders, Size, DATALENGTH(FactOrders[order_id])), 0.00))确认模型内存500MB。步骤六交付可验证的业务逻辑为每个核心指标编写“业务定义卡”净销售额定义为“订单表金额总和减去退货表金额总和”数据来源为FactOrders和FactReturns计算逻辑不可被前端筛选器篡改退货率定义为“退货金额占订单金额的比例”分子分母必须来自同一时间范围因此在报表中强制绑定日历表的DateKey筛选器。步骤七建立模型变更管控流程所有新表加入模型前必须通过“建模检查清单”① 是否有明确表类型标注② 外键字段是否非空③ 与日历表的关系是否基于DateKey每次发布新版本自动生成模型文档用Power BI REST API调用GetReport元数据设置数据质量监控每日凌晨运行DAX查询检查FactOrders中空customer_id比例是否1%超阈值自动邮件告警。4.3 重构效果量化指标重构前重构后提升幅度报表平均加载时间18.4秒2.3秒-87.5%业务方数据质疑次数/月14次0次100%解决新增分析需求平均交付周期5.2天0.7天-86.5%模型内存占用1.2GB380MB-68.3%最关键的是业务方第一次主动提出“能不能把‘净销售额’指标同步到我们的ERP系统”——这标志着数据模型从“展示工具”升级为“业务信任源”。5. 常见问题与排查技巧实录那些没人告诉你的建模暗礁5.1 问题速查表从现象反推建模缺陷现象可能根因排查命令DAX Studio解决方案切片器选择后无关图表数据突变存在隐式双向关系或未禁用的自动日期层次结构EVALUATE SUMMARIZECOLUMNS(Calendar, ActiveRelations, COUNTROWS(RELATEDTABLE(FactOrders)))检查所有关系线关闭日历表的“日期/时间层次结构”同一DAX公式在不同页面结果不同度量值中使用了未声明的FILTER()导致上下文污染EVALUATE VAR _ctx ALLSELECTED(Calendar) RETURN ROW(ContextSize, COUNTROWS(_ctx))用CALCULATE()显式包裹或用ALL()清除干扰筛选器模型加载时提示“内存不足”文本字段基数过高如日志表的URL字段EVALUATE SUMMARIZECOLUMNS(WebLog, URLCount, DISTINCTCOUNT(WebLog[URL]))删除高基数文本列或用哈希函数生成摘要URLHash HASH256(WebLog[URL])时间智能函数返回空白日历表与事实表关系未基于日期字段或日期字段含空值EVALUATE FILTER(VALUES(FactSales[OrderDate]), ISBLANK(FactSales[OrderDate]))清洗空日期或用COALESCE(FactSales[OrderDate], DATE(1900,1,1))填充默认值新增一个维度表后所有度量值变慢新表与事实表建立了不必要的关系引发笛卡尔积EVALUATE ROW(CrossJoinRows, COUNTROWS(CROSSJOIN(VALUES(NewDim[ID]), VALUES(FactSales[ID]))))删除冗余关系或用TREATAS()在度量值层动态关联5.2 独家避坑技巧十年踩坑总结的七条军规军规一永远不要在事实表中存描述性文本某次我接手一个HR分析项目事实表EmployeeEvents里存了DepartmentName、JobTitle等字段。当部门重组时历史记录的部门名称全部失效。正确做法建独立Departments维度表事实表只存DepartmentID通过关系动态获取名称。这样部门更名只需改维度表一行历史数据自动更新。军规二对“状态”类字段必须建缓慢变化维度SCD客户表有status字段“活跃”、“休眠”、“流失”业务要求追溯每个客户的状态变迁。如果只存当前状态就丢失了过程数据。解决方案在ETL层用Power Query实现Type 2 SCD为每个客户状态变更生成新记录并标记ValidFrom/ValidTo模型中用LOOKUPVALUE()按日期取有效状态。军规三警惕“隐藏的维度表”Orders表中有payment_method字段“Credit Card”, “PayPal”, “Bank Transfer”表面看是文本实则是维度。应提取为独立PaymentMethods表添加IsOnline布尔、AvgProcessingTimeHours数值等业务属性让支付方式从“标签”升级为“可分析实体”。军规四用“数据血缘图”代替脑内记忆Power BI Desktop的“数据血缘”功能常被忽略。每次修改关系后务必打开“视图”→“数据血缘”确认筛选器流向符合预期。曾有个项目我花了3小时排查DAX错误最后发现血缘图显示筛选器从日历表→产品表→订单表→退货表而退货表本不该受产品表影响——根源是误点了产品表和退货表之间的“建议关系”。军规五为每个度量值写“防错注释”在DAX编辑器中用//添加注释说明// 【净销售额】定义订单金额总和减退货金额总和 // 数据源FactOrders[amount] - FactReturns[amount] // 注意必须与Calendar[DateKey]建立活跃关系否则时间智能失效 NetSales SUM(FactOrders[amount]) - SUM(FactReturns[amount])这些注释会随PBIX文件保存成为团队知识资产。军规六定期运行“模型健康扫描”创建一个隐藏度量值ModelHealthScore VAR TableCount COUNTROWS(ALL(ModelInfo[TableName])) VAR ActiveRelations COUNTROWS(FILTER(ALL(ModelInfo), ModelInfo[IsActive] TRUE())) VAR AvgColumnCount AVERAGEX(ALL(ModelInfo), ModelInfo[ColumnCount]) RETURN DIVIDE(ActiveRelations, TableCount) * 100当分数80时触发模型审查流程。军规七把“建模规范”写进入职培训我给团队制定的《Power BI建模红线》第一条就是“禁止在模型视图中