尧图网页设计 
Power BI 数据建模专家模式全解基于 awesome-copilot 的星型模型、关系设计与性能优化实战指南【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文基于开源仓库 awesome-copilot 中社区贡献的 Power BI 数据建模专家 Agentagents/power-bi-data-modeling-expert.agent.md整理而成。该文件本质上是一套沉淀了微软官方建模推荐的可执行知识体系从星型模式Star Schema的事实表/维度表设计、表关系与基数管理到 Import / DirectQuery / Composite 存储模式选型、热冷分区、增量刷新、数据精简、性能优化、行级安全RLS与常见建模场景SCD、角色扮演维度、多对多桥接直至模型验证测试与交付流程。读完本文你将掌握一套可落地到真实 Power BI 语义模型中的完整建模方法并理解该 Agent 与仓库内配套的最佳实践指令、建模技能及 Power BI 开发插件如何协同构成专家级建模能力。一、这组专家模式在解决什么问题Power BI 报表卡顿、度量值算错、数据模型越做越慢绝大多数根因都不在可视化或 DAX 语法而在语义模型semantic model的底层设计表被揉成一团、关系基数错误、双向筛选泛滥、日期表缺失、存储模式选错。awesome-copilot 仓库中的Power BI Data Modeling Expert Mode正是针对这些问题设计的 GitHub Copilot 自定义 Agent它通过.agent.md文件把微软官方的建模推荐固化为模型可执行的指令让 Copilot 在接到建模类请求时始终先查微软文档再做推荐。1. 该 Agent 的定位与运行约束从文件的 frontmatter 可以看出它的定义方式name: Power BI Data Modeling Expert Mode在 VS Code Chat / Copilot Coding Agent 中作为可切换的专家模式使用激活方式与仓库 docs/README.agents.md 中描述一致安装*.agent.md后在 Chat 界面中选择。tools中显式声明了microsoft.docs.mcp并要求在给出任何推荐前必须先用微软文档工具检索最新建模指导再核对具体的关系类型、基数与优化技术确保建议与微软当前指引对齐。职责范围被严格限定在六大建模主题见下表摘自原文件 Core Responsibilities专业领域核心内容星型模式设计Star Schema Design落实规范的维度建模模式关系管理Relationship Management设计高效的表关系与基数存储模式优化Storage Mode Optimization在 Import、DirectQuery 与 Composite 间选择性能优化Performance Optimization缩减模型体积、提升查询性能数据精简技术Data Reduction Techniques在保留功能的同时最小化存储需求安全实现Security Implementation行级安全与数据保护策略2. Agent 的标准响应流程对每一个建模请求Agent 被要求按固定 7 步产出Response Structure文档检索用microsoft.docs.mcp检索当前建模最佳实践需求分析理解业务与技术需求模式设计推荐合适的星型结构关系策略定义最优关系模式性能优化识别优化机会实现指导给出逐步实现建议验证方案给出测试与校验方法。这与仓库配套技能 skills/powerbi-modeling/SKILL.md 的先连接、再评估、后指导三步工作流列出连接 → 评估模型健康度 → 给出针对性指导理念一致共同构成先体检、再开方的建模协作范式。二、星型模式Star Schema设计原则星型模式是 Power BI 语义模型的推荐结构其目标是把数据组织成两种职责截然不同的表。1. 事实表与维度表的职责边界事实表Fact Tables存放可度量、可聚合的数值数据交易、事件、观测包含指向维度表的外键行数通常庞大且随时间增长且必须保持一致的粒度consistent grain——每一行代表同一种业务事件例如订单行级、日聚合级严禁在同一张表内混合不同粒度。维度表Dimension Tables存放用于筛选与分组的描述性属性产品、客户、地理、时间、员工以唯一键标识一实体一行行数相对较小用于过滤、分组与下钻。两条铁律原文档及 STAR-SCHEMA 参考 反复强调清晰分离绝不要把事实与维度的特征混在同一张表里。反例是一张揉进客户详情的超宽Sales表正例是Sales事实表 Customer维度表。一致粒度事实表每一行必须代表同一层级的事实否则会导致聚合错误。原文档给出的两类表结构基线Dimension Table Structure: - Unique key column (surrogate key preferred) - Descriptive attributes for filtering/grouping - Hierarchical attributes for drill-down scenarios - Relatively small number of rows Fact Table Structure: - Foreign keys to dimension tables - Numeric measures for aggregation - Date/time columns for temporal analysis - Large number of rows (typically growing over time)仓库最佳实践指令补充了更完整的示例结构instructions/power-bi-data-modeling-best-practices.instructions.md 中以FactSales为核心、DimProduct/DimCustomer/DimDate环绕的示意直观展示了维度表含主键 ProductKey/CustomerKey/DateKey 与描述属性与事实表SalesKey 主键 各外键 SalesAmount/Quantity/DiscountAmount 度量列的典型形态。2. 表结构设计规范维度表做什么、不做什么✅ 应该❌ 不应该用代理键自增整数作主键在大模型中用自然业务键作主键保留业务键用于集成把事实与维度特征混在同一张表构造层级属性如 品类 子品类 产品建过宽、属性堆砌的维度表为缺失维度数据准备 Unknown 记录缺失值不做任何处理使用描述性名称与合适数据类型——事实表做什么、不做什么✅ 应该❌ 不应该按业务所需最细粒度存储混入描述性文本列它们属于维度外键与维度表键精确匹配在同一张事实表混合不同粒度只保留数值、可度量列存储可在查询期现算的派生值全部行保持统一粒度能用代理键却用复合键补充如果源数据缺乏唯一标识可用 Power Query 添加索引列生成代理键来自 STAR-SCHEMA.md Table.AddIndexColumn(Source, CustomerKey, 1, 1)3. 命名与分类约定STAR-SCHEMA 参考与 SKILL 的质量清单skills/powerbi-modeling/SKILL.md给出可供团队直接采用的约定维度表用单数业务名词命名Customer、Product、Date事实表用业务流程名词命名Sales、Orders、WebVisits表/列/度量应可读用Customer Name而非CUST_NM技术性键列ID 等应从报表视图隐藏。三、关系设计模式关系是把星型结构串起来的引擎也是查询性能和计算结果正确性的双重变量。1. 关系类型与使用场景关系类型使用说明一对多One-to-Many标准模式维度一指向事实多单方向筛选多对多Many-to-Many慎用仅在业务上确属多对多且无法桥接时使用配合桥接表一对一One-to-One罕见通常用于扩展维度属性、隔离 PII 数据、退化维度场景自引用Self-referencing用于父子层级如员工-经理仓库最佳实践指令补充了更细的一对一适用场景扩展维度附加属性、分离 PII 与运营数据并提示若可能应优先合并为单表。2. 关系配置检查清单原文档给出直接可用的配置规范Best Practices: ✅ Set proper cardinality based on actual data ✅ Use bi-directional filtering only when necessary ✅ Enable referential integrity for performance ✅ Hide foreign key columns from report view ❌ Avoid circular relationships ❌ Dont create unnecessary many-to-many relationships其下层的工程含义是可结合最佳实践指令中的关系配置指南一起看筛选方向单方向筛选是默认最优解双方向Both Directions只在业务逻辑确实需要交叉筛选时开启应始终避免环形关系路径。引用完整性Assume Referential IntegrityDirectQuery 场景下只要数据质量有保证开启它可让引擎使用 INNER JOIN显著提升查询性能若源存在孤儿记录则不要开启否则会产生错误结果。外键列隐藏把作为连接键的 ID 列从报表视图中隐藏减少视觉噪音与元数据膨胀。3. 关系故障排查原文档总结了四类高频故障与对策现象排查/对策缺失关系检查是否存在孤儿记录非活动关系在 DAX 中用USERELATIONSHIP函数临时激活交叉筛选异常检查筛选方向设置性能问题最小化双向关系数量四、存储模式选型Import / DirectQuery / Composite / DualPower BI 语义模型支持四种存储形态选择错误往往是慢的直接来源。1. 何时使用哪种模式Import导入模式适用场景数据量在容量限额内、需要复杂计算、历史数据稳定、追求最优查询性能。优化手段包括删列删行、数据瘦身、预聚合、大数据集增量刷新、优化 Power Query 转换。DirectQuery 模式适用场景数据超过导入容量、需要实时数据、安全/合规要求数据留在源端、需要与运营系统集成。它的优化重心前移到源数据库——建索引、用物化视图、尽量精简 DAX、限制每页视觉对象数量。Composite复合模式适用场景原文档明确列出的四个理由When to Use Composite Models: ✅ Combine real-time and historical data ✅ Extend existing models with additional data ✅ Balance performance with data freshness ✅ Integrate multiple DirectQuery sources Implementation Patterns: - Use Dual storage mode for dimension tables - Import aggregated data, DirectQuery detail - Careful relationship design across storage modes - Monitor cross-source group relationships2. Dual双存储模式的战术价值Composite 模式中最关键的设计是Dual 存储把既要参与 Import 事实、又要参与 DirectQuery 事实的维度表设为 Dual 模式见最佳实践指令Storage Mode Selection一节。Dual 表的优势在于 Power BI 会自动为查询选择最优路径、只维护一份维度数据副本、并能支撑高效的跨源关系。适合的候选小型慢变参照表、查找表。四类存储模式一句话速记摘自指令文件Import小型维度表、历史聚合事实DirectQuery大型事实表、实时运营数据Dual需要同时服务 Import 与 DirectQuery 事实的维度表Hybrid事实表本身历史走 Import 近期走 DirectQuery的组合。五、复合模型实战热冷分区、跨源关系与增量刷新这一节是原文档技术含量最高的部分它展示的是如何用一个模型同时吃掉历史与实时数据。1. 热冷数据分区的 TMSL/分区定义原文档以FactInternetSales为例给出典型冷热分层分区 JSON早于 2020-01-01 的订单走directQuery分区或反过来按业务需要2020 之后走import分区并用dataCoverageDefinition声明各自覆盖的数据范围// Example: Hot and Cold Data Partitioning partitions: [ { name: FactInternetSales-DQ-Partition, mode: directQuery, dataView: full, source: { type: m, expression: [ let, Source Sql.Database(\demo.database.windows.net\, \AdventureWorksDW\),, dbo_FactInternetSales Source{[Schema\dbo\,Item\FactInternetSales\]}[Data],, #\Filtered Rows\ Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] 20200101), in, #\Filtered Rows\ ] }, dataCoverageDefinition: { description: DQ partition with all sales from 2017, 2018, and 2019., expression: RELATED(DimDate[CalendarYear]) IN {2017,2018,2019} } }, { name: FactInternetSales-Import-Partition, mode: import, source: { type: m, expression: [ let, Source Sql.Database(\demo.database.windows.net\, \AdventureWorksDW\),, dbo_FactInternetSales Source{[Schema\dbo\,Item\FactInternetSales\]}[Data],, #\Filtered Rows\ Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] 20200101), in, #\Filtered Rows\ ] } } ]要点dataCoverageDefinition用 DAX 布尔表达式如基于RELATED(DimDate[CalendarYear])声明该分区覆盖哪些数据这是 Power BI 能安全地把来自不同存储模式的同表分区拼接起来的前提。仓库指令文件还提供了按单年分区的简化版本Sales2019分区按OrderDateKey界 2019 全年可作参考见 instructions/power-bi-data-modeling-best-practices.instructions.md Advanced Partition Strategies 一节。2. 跨源关系的 DAX 用法当复合模型把多张 DirectQuery 源与导入数据合并时跨源的关系需要用度量与USERELATIONSHIP显式驱动。原文档给出的示例是区域维度既想按默认关系聚合、又想临时切到另一条关系// Cross-source relationships in composite models TotalSales SUM(Sales[Sales]) RegionalSales CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID])) RegionalSalesDirect CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID])) // Model relationship information query // Remove EVALUATE when using this DAX function in a calculated table EVALUATE INFO.VIEW.RELATIONSHIPS()其中INFO.VIEW.RELATIONSHIPS()是用于检视模型关系元数据的视图函数在报表度量里使用时需去掉EVALUATE若要落成计算表则可保留。3. 增量刷新的两种写法增量刷新是大数据量 Import 模式的标配。原文档给出两种 Power Query 写法并明确注明各自特性写法一参数化筛选 查询折叠推荐——利用RangeStart/RangeEnd参数把谓词下推到 SQL Server// Optimized incremental refresh with query folding let Source Sql.Database(dwdev02,AdventureWorksDW2017), Data Source{[Schemadbo,ItemFactInternetSales]}[Data], #Filtered Rows Table.SelectRows(Data, each [OrderDateKey] Int32.From(DateTime.ToText(RangeStart,[FormatyyyyMMdd]))), #Filtered Rows1 Table.SelectRows(#Filtered Rows, each [OrderDateKey] Int32.From(DateTime.ToText(RangeEnd,[FormatyyyyMMdd]))) in #Filtered Rows1写法二原生 SQL 拼接会禁用查询折叠——当需要完全掌控 SQL 时使用注意[EnableFoldingfalse]会让增量刷新失去分区级裁剪能力成本更高// Alternative: Native SQL approach (disables query folding) let Query select * from dbo.FactInternetSales where OrderDateKey Text.From(Int32.From( DateTime.ToText(RangeStart,yyyyMMdd) )) and OrderDateKey Text.From(Int32.From( DateTime.ToText(RangeEnd,yyyyMMdd) )) , Source Sql.Database(dwdev02,AdventureWorksDW2017), Data Value.NativeQuery(Source, Query, null, [EnableFoldingfalse]) in Data仓库最佳实践指令对折叠版增量刷新有几乎一致的模板实现instructions/power-bi-data-modeling-best-practices.instructions.md Incremental Refresh with Query Folding 一节两者可互相印证核心都是把OrderDateKey的上下界与RangeStart/RangeEnd绑定并保证转换可折叠从而让刷新按分区增量执行。六、数据精简技术把模型瘦身而不失能模型体积直接决定刷新时间、内存占用与查询延迟。原文档把精简归纳为三个层面。1. 列优化垂直方向只保留报表或关系实际使用的列能在 DAX 计算的列不要物化为计算列删除仅在 Power Query 中间步骤使用、最终不外泄的列用最小合适的数据类型文本代码尽量转整数、仅日期时用Date而非DateTime、整数值用整数、精度匹配业务需求。2. 行过滤水平方向时间过滤只加载必要的历史区间如近 3 年实体过滤只保留相关业务单元/区域的记录增量刷新应对持续增长的数据集删除测试、无效、已取消的交易记录做好归档策略。3. 预聚合模式在合适的粒度层预先聚合而不是让每次报表查询都全表扫描// Pre-aggregate at appropriate grain level Monthly Sales Summary SUMMARIZECOLUMNS( Date[Year Month], Product[Category], Geography[Country], Total Sales, SUM(Sales[Amount]), Transaction Count, COUNTROWS(Sales) )SUMMARIZECOLUMNS按Year Month/Category/Country三个维度输出月度聚合返回的既有求和度量也有计数度量可作为聚合表aggregation table的候选输入服务于高频的汇总型报表。更进一步高级别汇总可使用 Premium 的自动聚合能力automatic aggregations见最佳实践指令中的 Aggregation Strategies 清单。七、性能优化指引从模型形态到查询模式1. 模型体积优化垂直过滤删除未使用的列水平过滤删除不必要行数据类型最小化用最小的合适类型关闭自动日期/时间用自定义日期表替代Power BI 的 Auto Date/Time 会为每个日期列生成隐藏日期表显著膨胀模型且粒度不可控。2. 关系性能最小化交叉筛选默认单方向连接列优先整数键而非文本键优先代理键而非自然键隐藏未用列DirectQuery 下启用引用完整性Referential Integrity高基数文本列可转整数 查表关联见指令中的列优化建议。3. 查询性能的正反模式清单原文档给出的高效模型画像与反模式自查表可直接作为模型评审的评分卡Efficient Model Patterns: ✅ Star schema with clear fact/dimension separation ✅ Proper date table with continuous date range ✅ Optimized relationships with correct cardinality ✅ Minimal calculated columns ✅ Appropriate aggregation levels Performance Anti-Patterns: ❌ Snowflake schemas (except when necessary) ❌ Many-to-many relationships without bridging ❌ Complex calculated columns in large tables ❌ Bidirectional relationships everywhere ❌ Missing or incorrect date tables配套指令进一步给出了应避免的架构级反模式及更优替代可归纳为对照表反模式问题解法雪片模式过度规范化的维度关系链长、查询慢、对业务用户复杂尽量压平为星型单一超大宽表事实与维度混杂、难维护、分析查询慢拆为星型多事实表直连事实间多对多、筛选传播复杂通过共享维度连接事实表混合粒度聚合错误按粒度分表无理由的双向关系、多对多、环形关系性能与语义双重风险回归标准星型缺失/错误日期表时间智能计算错误建连续日期表并标记八、安全与治理RLS 与数据保护1. 行级安全RLS示例原文档给出区域级访问控制的 RLS 筛选器写法——依据当前登录用户USERPRINCIPALNAME()从用户-区域映射表反查其所属区域再与地理维度比对// Example RLS filter for regional access Regional Filter Geography[Region] LOOKUPVALUE( User Region[Region], User Region[Email], USERPRINCIPALNAME() )仓库最佳实践指令在此基础上补充了三种可落地的 RLS 形态Security and Governance / Row-Level Security一节可以一起纳入安全设计工具箱// 基于角色的安全先从映射表取角色再按角色放行 VAR UserRole LOOKUPVALUE( UserRoles[Role], UserRoles[Email], USERPRINCIPALNAME() ) RETURN Customers[Region] UserRole // 动态安全等价于把映射表的区域与事实维度做等值连接 LOOKUPVALUE( UserRegions[Region], UserRegions[Email], USERPRINCIPALNAME() ) Customers[Region]RLS 落地注意事项综合原文档与指令文件尽量用安全角色而非针对单用户的过滤器用不同账号实测安全效果保持安全逻辑简单高效——因为复杂 RLS 会注入每一条查询直接影响性能。2. 数据保护策略原文档列出的其余安全层列级安全Column-Level Security敏感列的处理动态安全Dynamic Security上下文感知过滤基于角色的访问Role-Based Access层级化安全模型审计与合规Audit and Compliance数据血缘追踪。治理侧指令文件补充还应覆盖所有度量的业务定义、数据血缘与源系统映射、刷新计划与依赖、访问控制文档、变更管理流程以及源版本控制为 .pbix 提供版本管理、环境晋升与备份恢复。九、常见建模场景SCD、角色扮演维度、多对多1. 缓慢变化维度SCD原文档区分了两种基本形态Type 1直接覆盖历史值丢失历史语境实现简单适合非关键属性Type 2保留完整历史版本需要代理键唯一标识、生效日期区间effective date ranges、当前记录标志与历史保留策略。指令文件给出了 Type 2 的示例数据形态示意CustomerKey (Surrogate): 1, 2, 3, 4 CustomerID (Business): 101, 101, 102, 103 CustomerName: John Doe, John Smith, Jane Doe, Bob Johnson EffectiveDate: 2023-01-01, 2024-01-01, 2023-01-01, 2023-01-01 ExpirationDate: 2023-12-31, 9999-12-31, 9999-12-31, 9999-12-31 IsCurrent: FALSE, TRUE, TRUE, TRUE若要在 Power Query 侧实现 Type 1 变更检测指令文件给出对业务属性字段做哈希 左外连接已有维度记录 仅保留无匹配的新记录的实现详见 instructions/power-bi-data-modeling-best-practices.instructions.md Slowly Changing Dimensions Implementation其核心逻辑是先对各属性列拼接哈希得到Hash键再与ExistingDimRecords按Hash左连接过滤掉已存在记录[Count] null即得到新增/变更行。这种基于哈希的写法可显著减少对源表的全量比对开销。2. 角色扮演维度同一张日期表被订单日期、发货日期、交货日期多次引用时就是典型的角色扮演维度。原文档给出两种实现方式一推荐单日期表建立多条关系——订单日期为活动关系发货/交货日期为非活动关系度量中用USERELATIONSHIP切换方式二复制为多张独立日期表OrderDate / ShipDate / DeliveryDate更直观但模型体积更大。指令文件补充了对应 DAXSales by Order Date [Total Sales] // 走活动关系 Sales by Ship Date CALCULATE([Total Sales], USERELATIONSHIP(FactSales[ShipDate], DimDate[Date])) Sales by Delivery Date CALCULATE([Total Sales], USERELATIONSHIP(FactSales[DeliveryDate], DimDate[Date]))3. 多对多与桥接表多对多不应直接用模糊关系解决而应显式引入桥接表。原文档给出经典模式Bridge Table Pattern: Customer -- Customer Product Bridge -- Product Benefits: - Clear relationship semantics - Proper filtering behavior - Maintained referential integrity - Scalable design pattern指令文件补充了桥接表落地的具体规则以学生-课程为例桥接表应包含代理主键StudentCourseKey、两枚外键及附加上下文列EnrollmentDate、Grade、Status两侧各建一对多关系其中一侧设置为双向筛选以让筛选得以穿透并把桥接表从报表视图隐藏。十、日期表的必要设计性能反模式清单里明确警告缺失或不正确的日期表说明日期表是模型健康的基本盘。综合原文档与指令文件一张合格日期表应满足连续日期范围无缺口并在 Power BI 中标记为日期表具备标准层级年 季 月 日可按需扩展业务列财年、工作日标记、节假日日期列使用 Date 类型。STAR-SCHEMA 参考提供了可直接创建日期表的 DAXskills/powerbi-modeling/references/STAR-SCHEMA.mdDate ADDCOLUMNS( CALENDAR(DATE(2020,1,1), DATE(2030,12,31)), Year, YEAR([Date]), Month, FORMAT([Date], MMMM), MonthNum, MONTH([Date]), Quarter, Q FORMAT([Date], Q), WeekDay, FORMAT([Date], dddd) )若业务需要整数形式的时间键指令文件建议形如20240315YYYYMMDD的DateKey以及IsWorkingDay、FiscalYear、FiscalQuarter等业务列。十一、模型验证与测试框架1. 数据质量检查引用完整性核验所有外键都有对应匹配数据完整性检查关键列的缺失值业务规则验证确保计算与业务逻辑一致对比源系统合计性能测试验证查询响应时间。2. 关系与行为验证筛选传播测试交叉筛选行为是否符合预期度量准确性跨关系核验计算安全测试用不同角色验证 RLS用户验收与业务用户共同验收。指令文件把测试面扩展成可勾选的矩阵见其 Model Testing Checklist功能测试关系、度量、筛选、安全、刷新、性能测试加载时间、查询 SLA、交互响应、内存、并发负载、数据质量测试无缺失外键、合计对账、日期连续、安全过滤正确、业务规则正确。STAR-SCHEMA 参考还提供了结构级验证清单每张表明确是维度还是事实、事实表外键齐备、维度键唯一、日期表已建已标记、无环形关系、命名一致——可将其作为建模收尾的自检卡。十二、配套工具与仓库生态这组专家模式并非孤立文件。该 Agent 隶属于仓库内的 Power BI 开发插件插件通过插件清单 plugins/power-bi-development/plugin.json 把四个 Agentdata-modeling / dax / performance / visualization与对应技能打包可用copilot plugin install power-bi-developmentawesome-copilot安装。建模专家模式与以下资源互补使用效果最佳Power BI 数据建模最佳实践指令规则更细的建模执行规范applyTo声明了对.pbix/.md/.json/.txt生效powerbi-modeling 建模技能面向 Power BI Modeling MCP Server 的可执行技能支持连接活动模型、评估健康度、增删关系/度量等操作STAR-SCHEMA 星型模式参考星型模式速查手册同族的 DAX 专家模式 与 性能专家模式分别接管度量公式优化与性能诊断形成建模 → 度量 → 性能分工链。一个典型的协作路径是先用建模专家模式定架构与关系再用 DAX 专家模式打磨度量最后用性能专家模式/DAX Studio、Power BI Performance Analyzer 压测验证。这正是仓库把这些 Agent 组织成插件、而非散落单文件的初衷。十三、总结建模自检清单把全文收敛成一份可复制的交付前检查单每张表都明确是维度还是事实未混用职责与粒度事实表对相关维度均有外键粒度一致关系基数符合实际数据默认单方向筛选双向是例外外键/技术列已隐藏且为直接查询开启了引用完整性数据质量允许时存在连续、已标记的日期表替代自动日期/时间存储模式选择有据体积与实时性约束下合理使用 Import / DirectQuery / Dual / Hybrid大表采用增量刷新 可折叠查询必要时按热冷分区落地复合模型列、行、聚合三层做了数据精简避开全部性能反模式雪片、宽表、无桥多对多、双向泛滥、缺日期表RLS 用角色而非个人过滤并完成多账号实测用功能/性能/数据质量三份清单完成模型验证再用业务用户做验收。需要提醒的是本文所有规则以 awesome-copilot 仓库当前收录的 Agent 文档为准微软官方指引随版本演进会持续更新——这也是该 Agent 被设计为先检索microsoft.docs.mcp、再给结论的原因。在真实项目中建议把本文的清单当作初始骨架同时结合你的 Power BI 版本、容量规格与数据量级做最终取舍。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Power BI 数据建模专家模式全解：基于 awesome-copilot 的星型模型、关系设计与性能优化实战指南
Power BI 数据建模专家模式全解基于 awesome-copilot 的星型模型、关系设计与性能优化实战指南【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本文基于开源仓库 awesome-copilot 中社区贡献的 Power BI 数据建模专家 Agentagents/power-bi-data-modeling-expert.agent.md整理而成。该文件本质上是一套沉淀了微软官方建模推荐的可执行知识体系从星型模式Star Schema的事实表/维度表设计、表关系与基数管理到 Import / DirectQuery / Composite 存储模式选型、热冷分区、增量刷新、数据精简、性能优化、行级安全RLS与常见建模场景SCD、角色扮演维度、多对多桥接直至模型验证测试与交付流程。读完本文你将掌握一套可落地到真实 Power BI 语义模型中的完整建模方法并理解该 Agent 与仓库内配套的最佳实践指令、建模技能及 Power BI 开发插件如何协同构成专家级建模能力。一、这组专家模式在解决什么问题Power BI 报表卡顿、度量值算错、数据模型越做越慢绝大多数根因都不在可视化或 DAX 语法而在语义模型semantic model的底层设计表被揉成一团、关系基数错误、双向筛选泛滥、日期表缺失、存储模式选错。awesome-copilot 仓库中的Power BI Data Modeling Expert Mode正是针对这些问题设计的 GitHub Copilot 自定义 Agent它通过.agent.md文件把微软官方的建模推荐固化为模型可执行的指令让 Copilot 在接到建模类请求时始终先查微软文档再做推荐。1. 该 Agent 的定位与运行约束从文件的 frontmatter 可以看出它的定义方式name: Power BI Data Modeling Expert Mode在 VS Code Chat / Copilot Coding Agent 中作为可切换的专家模式使用激活方式与仓库 docs/README.agents.md 中描述一致安装*.agent.md后在 Chat 界面中选择。tools中显式声明了microsoft.docs.mcp并要求在给出任何推荐前必须先用微软文档工具检索最新建模指导再核对具体的关系类型、基数与优化技术确保建议与微软当前指引对齐。职责范围被严格限定在六大建模主题见下表摘自原文件 Core Responsibilities专业领域核心内容星型模式设计Star Schema Design落实规范的维度建模模式关系管理Relationship Management设计高效的表关系与基数存储模式优化Storage Mode Optimization在 Import、DirectQuery 与 Composite 间选择性能优化Performance Optimization缩减模型体积、提升查询性能数据精简技术Data Reduction Techniques在保留功能的同时最小化存储需求安全实现Security Implementation行级安全与数据保护策略2. Agent 的标准响应流程对每一个建模请求Agent 被要求按固定 7 步产出Response Structure文档检索用microsoft.docs.mcp检索当前建模最佳实践需求分析理解业务与技术需求模式设计推荐合适的星型结构关系策略定义最优关系模式性能优化识别优化机会实现指导给出逐步实现建议验证方案给出测试与校验方法。这与仓库配套技能 skills/powerbi-modeling/SKILL.md 的先连接、再评估、后指导三步工作流列出连接 → 评估模型健康度 → 给出针对性指导理念一致共同构成先体检、再开方的建模协作范式。二、星型模式Star Schema设计原则星型模式是 Power BI 语义模型的推荐结构其目标是把数据组织成两种职责截然不同的表。1. 事实表与维度表的职责边界事实表Fact Tables存放可度量、可聚合的数值数据交易、事件、观测包含指向维度表的外键行数通常庞大且随时间增长且必须保持一致的粒度consistent grain——每一行代表同一种业务事件例如订单行级、日聚合级严禁在同一张表内混合不同粒度。维度表Dimension Tables存放用于筛选与分组的描述性属性产品、客户、地理、时间、员工以唯一键标识一实体一行行数相对较小用于过滤、分组与下钻。两条铁律原文档及 STAR-SCHEMA 参考 反复强调清晰分离绝不要把事实与维度的特征混在同一张表里。反例是一张揉进客户详情的超宽Sales表正例是Sales事实表 Customer维度表。一致粒度事实表每一行必须代表同一层级的事实否则会导致聚合错误。原文档给出的两类表结构基线Dimension Table Structure: - Unique key column (surrogate key preferred) - Descriptive attributes for filtering/grouping - Hierarchical attributes for drill-down scenarios - Relatively small number of rows Fact Table Structure: - Foreign keys to dimension tables - Numeric measures for aggregation - Date/time columns for temporal analysis - Large number of rows (typically growing over time)仓库最佳实践指令补充了更完整的示例结构instructions/power-bi-data-modeling-best-practices.instructions.md 中以FactSales为核心、DimProduct/DimCustomer/DimDate环绕的示意直观展示了维度表含主键 ProductKey/CustomerKey/DateKey 与描述属性与事实表SalesKey 主键 各外键 SalesAmount/Quantity/DiscountAmount 度量列的典型形态。2. 表结构设计规范维度表做什么、不做什么✅ 应该❌ 不应该用代理键自增整数作主键在大模型中用自然业务键作主键保留业务键用于集成把事实与维度特征混在同一张表构造层级属性如 品类 子品类 产品建过宽、属性堆砌的维度表为缺失维度数据准备 Unknown 记录缺失值不做任何处理使用描述性名称与合适数据类型——事实表做什么、不做什么✅ 应该❌ 不应该按业务所需最细粒度存储混入描述性文本列它们属于维度外键与维度表键精确匹配在同一张事实表混合不同粒度只保留数值、可度量列存储可在查询期现算的派生值全部行保持统一粒度能用代理键却用复合键补充如果源数据缺乏唯一标识可用 Power Query 添加索引列生成代理键来自 STAR-SCHEMA.md Table.AddIndexColumn(Source, CustomerKey, 1, 1)3. 命名与分类约定STAR-SCHEMA 参考与 SKILL 的质量清单skills/powerbi-modeling/SKILL.md给出可供团队直接采用的约定维度表用单数业务名词命名Customer、Product、Date事实表用业务流程名词命名Sales、Orders、WebVisits表/列/度量应可读用Customer Name而非CUST_NM技术性键列ID 等应从报表视图隐藏。三、关系设计模式关系是把星型结构串起来的引擎也是查询性能和计算结果正确性的双重变量。1. 关系类型与使用场景关系类型使用说明一对多One-to-Many标准模式维度一指向事实多单方向筛选多对多Many-to-Many慎用仅在业务上确属多对多且无法桥接时使用配合桥接表一对一One-to-One罕见通常用于扩展维度属性、隔离 PII 数据、退化维度场景自引用Self-referencing用于父子层级如员工-经理仓库最佳实践指令补充了更细的一对一适用场景扩展维度附加属性、分离 PII 与运营数据并提示若可能应优先合并为单表。2. 关系配置检查清单原文档给出直接可用的配置规范Best Practices: ✅ Set proper cardinality based on actual data ✅ Use bi-directional filtering only when necessary ✅ Enable referential integrity for performance ✅ Hide foreign key columns from report view ❌ Avoid circular relationships ❌ Dont create unnecessary many-to-many relationships其下层的工程含义是可结合最佳实践指令中的关系配置指南一起看筛选方向单方向筛选是默认最优解双方向Both Directions只在业务逻辑确实需要交叉筛选时开启应始终避免环形关系路径。引用完整性Assume Referential IntegrityDirectQuery 场景下只要数据质量有保证开启它可让引擎使用 INNER JOIN显著提升查询性能若源存在孤儿记录则不要开启否则会产生错误结果。外键列隐藏把作为连接键的 ID 列从报表视图中隐藏减少视觉噪音与元数据膨胀。3. 关系故障排查原文档总结了四类高频故障与对策现象排查/对策缺失关系检查是否存在孤儿记录非活动关系在 DAX 中用USERELATIONSHIP函数临时激活交叉筛选异常检查筛选方向设置性能问题最小化双向关系数量四、存储模式选型Import / DirectQuery / Composite / DualPower BI 语义模型支持四种存储形态选择错误往往是慢的直接来源。1. 何时使用哪种模式Import导入模式适用场景数据量在容量限额内、需要复杂计算、历史数据稳定、追求最优查询性能。优化手段包括删列删行、数据瘦身、预聚合、大数据集增量刷新、优化 Power Query 转换。DirectQuery 模式适用场景数据超过导入容量、需要实时数据、安全/合规要求数据留在源端、需要与运营系统集成。它的优化重心前移到源数据库——建索引、用物化视图、尽量精简 DAX、限制每页视觉对象数量。Composite复合模式适用场景原文档明确列出的四个理由When to Use Composite Models: ✅ Combine real-time and historical data ✅ Extend existing models with additional data ✅ Balance performance with data freshness ✅ Integrate multiple DirectQuery sources Implementation Patterns: - Use Dual storage mode for dimension tables - Import aggregated data, DirectQuery detail - Careful relationship design across storage modes - Monitor cross-source group relationships2. Dual双存储模式的战术价值Composite 模式中最关键的设计是Dual 存储把既要参与 Import 事实、又要参与 DirectQuery 事实的维度表设为 Dual 模式见最佳实践指令Storage Mode Selection一节。Dual 表的优势在于 Power BI 会自动为查询选择最优路径、只维护一份维度数据副本、并能支撑高效的跨源关系。适合的候选小型慢变参照表、查找表。四类存储模式一句话速记摘自指令文件Import小型维度表、历史聚合事实DirectQuery大型事实表、实时运营数据Dual需要同时服务 Import 与 DirectQuery 事实的维度表Hybrid事实表本身历史走 Import 近期走 DirectQuery的组合。五、复合模型实战热冷分区、跨源关系与增量刷新这一节是原文档技术含量最高的部分它展示的是如何用一个模型同时吃掉历史与实时数据。1. 热冷数据分区的 TMSL/分区定义原文档以FactInternetSales为例给出典型冷热分层分区 JSON早于 2020-01-01 的订单走directQuery分区或反过来按业务需要2020 之后走import分区并用dataCoverageDefinition声明各自覆盖的数据范围// Example: Hot and Cold Data Partitioning partitions: [ { name: FactInternetSales-DQ-Partition, mode: directQuery, dataView: full, source: { type: m, expression: [ let, Source Sql.Database(\demo.database.windows.net\, \AdventureWorksDW\),, dbo_FactInternetSales Source{[Schema\dbo\,Item\FactInternetSales\]}[Data],, #\Filtered Rows\ Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] 20200101), in, #\Filtered Rows\ ] }, dataCoverageDefinition: { description: DQ partition with all sales from 2017, 2018, and 2019., expression: RELATED(DimDate[CalendarYear]) IN {2017,2018,2019} } }, { name: FactInternetSales-Import-Partition, mode: import, source: { type: m, expression: [ let, Source Sql.Database(\demo.database.windows.net\, \AdventureWorksDW\),, dbo_FactInternetSales Source{[Schema\dbo\,Item\FactInternetSales\]}[Data],, #\Filtered Rows\ Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] 20200101), in, #\Filtered Rows\ ] } } ]要点dataCoverageDefinition用 DAX 布尔表达式如基于RELATED(DimDate[CalendarYear])声明该分区覆盖哪些数据这是 Power BI 能安全地把来自不同存储模式的同表分区拼接起来的前提。仓库指令文件还提供了按单年分区的简化版本Sales2019分区按OrderDateKey界 2019 全年可作参考见 instructions/power-bi-data-modeling-best-practices.instructions.md Advanced Partition Strategies 一节。2. 跨源关系的 DAX 用法当复合模型把多张 DirectQuery 源与导入数据合并时跨源的关系需要用度量与USERELATIONSHIP显式驱动。原文档给出的示例是区域维度既想按默认关系聚合、又想临时切到另一条关系// Cross-source relationships in composite models TotalSales SUM(Sales[Sales]) RegionalSales CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID], Sales[RegionID])) RegionalSalesDirect CALCULATE(SUM(Sales[Sales]), USERELATIONSHIP(Region[RegionID], Sales[RegionID])) // Model relationship information query // Remove EVALUATE when using this DAX function in a calculated table EVALUATE INFO.VIEW.RELATIONSHIPS()其中INFO.VIEW.RELATIONSHIPS()是用于检视模型关系元数据的视图函数在报表度量里使用时需去掉EVALUATE若要落成计算表则可保留。3. 增量刷新的两种写法增量刷新是大数据量 Import 模式的标配。原文档给出两种 Power Query 写法并明确注明各自特性写法一参数化筛选 查询折叠推荐——利用RangeStart/RangeEnd参数把谓词下推到 SQL Server// Optimized incremental refresh with query folding let Source Sql.Database(dwdev02,AdventureWorksDW2017), Data Source{[Schemadbo,ItemFactInternetSales]}[Data], #Filtered Rows Table.SelectRows(Data, each [OrderDateKey] Int32.From(DateTime.ToText(RangeStart,[FormatyyyyMMdd]))), #Filtered Rows1 Table.SelectRows(#Filtered Rows, each [OrderDateKey] Int32.From(DateTime.ToText(RangeEnd,[FormatyyyyMMdd]))) in #Filtered Rows1写法二原生 SQL 拼接会禁用查询折叠——当需要完全掌控 SQL 时使用注意[EnableFoldingfalse]会让增量刷新失去分区级裁剪能力成本更高// Alternative: Native SQL approach (disables query folding) let Query select * from dbo.FactInternetSales where OrderDateKey Text.From(Int32.From( DateTime.ToText(RangeStart,yyyyMMdd) )) and OrderDateKey Text.From(Int32.From( DateTime.ToText(RangeEnd,yyyyMMdd) )) , Source Sql.Database(dwdev02,AdventureWorksDW2017), Data Value.NativeQuery(Source, Query, null, [EnableFoldingfalse]) in Data仓库最佳实践指令对折叠版增量刷新有几乎一致的模板实现instructions/power-bi-data-modeling-best-practices.instructions.md Incremental Refresh with Query Folding 一节两者可互相印证核心都是把OrderDateKey的上下界与RangeStart/RangeEnd绑定并保证转换可折叠从而让刷新按分区增量执行。六、数据精简技术把模型瘦身而不失能模型体积直接决定刷新时间、内存占用与查询延迟。原文档把精简归纳为三个层面。1. 列优化垂直方向只保留报表或关系实际使用的列能在 DAX 计算的列不要物化为计算列删除仅在 Power Query 中间步骤使用、最终不外泄的列用最小合适的数据类型文本代码尽量转整数、仅日期时用Date而非DateTime、整数值用整数、精度匹配业务需求。2. 行过滤水平方向时间过滤只加载必要的历史区间如近 3 年实体过滤只保留相关业务单元/区域的记录增量刷新应对持续增长的数据集删除测试、无效、已取消的交易记录做好归档策略。3. 预聚合模式在合适的粒度层预先聚合而不是让每次报表查询都全表扫描// Pre-aggregate at appropriate grain level Monthly Sales Summary SUMMARIZECOLUMNS( Date[Year Month], Product[Category], Geography[Country], Total Sales, SUM(Sales[Amount]), Transaction Count, COUNTROWS(Sales) )SUMMARIZECOLUMNS按Year Month/Category/Country三个维度输出月度聚合返回的既有求和度量也有计数度量可作为聚合表aggregation table的候选输入服务于高频的汇总型报表。更进一步高级别汇总可使用 Premium 的自动聚合能力automatic aggregations见最佳实践指令中的 Aggregation Strategies 清单。七、性能优化指引从模型形态到查询模式1. 模型体积优化垂直过滤删除未使用的列水平过滤删除不必要行数据类型最小化用最小的合适类型关闭自动日期/时间用自定义日期表替代Power BI 的 Auto Date/Time 会为每个日期列生成隐藏日期表显著膨胀模型且粒度不可控。2. 关系性能最小化交叉筛选默认单方向连接列优先整数键而非文本键优先代理键而非自然键隐藏未用列DirectQuery 下启用引用完整性Referential Integrity高基数文本列可转整数 查表关联见指令中的列优化建议。3. 查询性能的正反模式清单原文档给出的高效模型画像与反模式自查表可直接作为模型评审的评分卡Efficient Model Patterns: ✅ Star schema with clear fact/dimension separation ✅ Proper date table with continuous date range ✅ Optimized relationships with correct cardinality ✅ Minimal calculated columns ✅ Appropriate aggregation levels Performance Anti-Patterns: ❌ Snowflake schemas (except when necessary) ❌ Many-to-many relationships without bridging ❌ Complex calculated columns in large tables ❌ Bidirectional relationships everywhere ❌ Missing or incorrect date tables配套指令进一步给出了应避免的架构级反模式及更优替代可归纳为对照表反模式问题解法雪片模式过度规范化的维度关系链长、查询慢、对业务用户复杂尽量压平为星型单一超大宽表事实与维度混杂、难维护、分析查询慢拆为星型多事实表直连事实间多对多、筛选传播复杂通过共享维度连接事实表混合粒度聚合错误按粒度分表无理由的双向关系、多对多、环形关系性能与语义双重风险回归标准星型缺失/错误日期表时间智能计算错误建连续日期表并标记八、安全与治理RLS 与数据保护1. 行级安全RLS示例原文档给出区域级访问控制的 RLS 筛选器写法——依据当前登录用户USERPRINCIPALNAME()从用户-区域映射表反查其所属区域再与地理维度比对// Example RLS filter for regional access Regional Filter Geography[Region] LOOKUPVALUE( User Region[Region], User Region[Email], USERPRINCIPALNAME() )仓库最佳实践指令在此基础上补充了三种可落地的 RLS 形态Security and Governance / Row-Level Security一节可以一起纳入安全设计工具箱// 基于角色的安全先从映射表取角色再按角色放行 VAR UserRole LOOKUPVALUE( UserRoles[Role], UserRoles[Email], USERPRINCIPALNAME() ) RETURN Customers[Region] UserRole // 动态安全等价于把映射表的区域与事实维度做等值连接 LOOKUPVALUE( UserRegions[Region], UserRegions[Email], USERPRINCIPALNAME() ) Customers[Region]RLS 落地注意事项综合原文档与指令文件尽量用安全角色而非针对单用户的过滤器用不同账号实测安全效果保持安全逻辑简单高效——因为复杂 RLS 会注入每一条查询直接影响性能。2. 数据保护策略原文档列出的其余安全层列级安全Column-Level Security敏感列的处理动态安全Dynamic Security上下文感知过滤基于角色的访问Role-Based Access层级化安全模型审计与合规Audit and Compliance数据血缘追踪。治理侧指令文件补充还应覆盖所有度量的业务定义、数据血缘与源系统映射、刷新计划与依赖、访问控制文档、变更管理流程以及源版本控制为 .pbix 提供版本管理、环境晋升与备份恢复。九、常见建模场景SCD、角色扮演维度、多对多1. 缓慢变化维度SCD原文档区分了两种基本形态Type 1直接覆盖历史值丢失历史语境实现简单适合非关键属性Type 2保留完整历史版本需要代理键唯一标识、生效日期区间effective date ranges、当前记录标志与历史保留策略。指令文件给出了 Type 2 的示例数据形态示意CustomerKey (Surrogate): 1, 2, 3, 4 CustomerID (Business): 101, 101, 102, 103 CustomerName: John Doe, John Smith, Jane Doe, Bob Johnson EffectiveDate: 2023-01-01, 2024-01-01, 2023-01-01, 2023-01-01 ExpirationDate: 2023-12-31, 9999-12-31, 9999-12-31, 9999-12-31 IsCurrent: FALSE, TRUE, TRUE, TRUE若要在 Power Query 侧实现 Type 1 变更检测指令文件给出对业务属性字段做哈希 左外连接已有维度记录 仅保留无匹配的新记录的实现详见 instructions/power-bi-data-modeling-best-practices.instructions.md Slowly Changing Dimensions Implementation其核心逻辑是先对各属性列拼接哈希得到Hash键再与ExistingDimRecords按Hash左连接过滤掉已存在记录[Count] null即得到新增/变更行。这种基于哈希的写法可显著减少对源表的全量比对开销。2. 角色扮演维度同一张日期表被订单日期、发货日期、交货日期多次引用时就是典型的角色扮演维度。原文档给出两种实现方式一推荐单日期表建立多条关系——订单日期为活动关系发货/交货日期为非活动关系度量中用USERELATIONSHIP切换方式二复制为多张独立日期表OrderDate / ShipDate / DeliveryDate更直观但模型体积更大。指令文件补充了对应 DAXSales by Order Date [Total Sales] // 走活动关系 Sales by Ship Date CALCULATE([Total Sales], USERELATIONSHIP(FactSales[ShipDate], DimDate[Date])) Sales by Delivery Date CALCULATE([Total Sales], USERELATIONSHIP(FactSales[DeliveryDate], DimDate[Date]))3. 多对多与桥接表多对多不应直接用模糊关系解决而应显式引入桥接表。原文档给出经典模式Bridge Table Pattern: Customer -- Customer Product Bridge -- Product Benefits: - Clear relationship semantics - Proper filtering behavior - Maintained referential integrity - Scalable design pattern指令文件补充了桥接表落地的具体规则以学生-课程为例桥接表应包含代理主键StudentCourseKey、两枚外键及附加上下文列EnrollmentDate、Grade、Status两侧各建一对多关系其中一侧设置为双向筛选以让筛选得以穿透并把桥接表从报表视图隐藏。十、日期表的必要设计性能反模式清单里明确警告缺失或不正确的日期表说明日期表是模型健康的基本盘。综合原文档与指令文件一张合格日期表应满足连续日期范围无缺口并在 Power BI 中标记为日期表具备标准层级年 季 月 日可按需扩展业务列财年、工作日标记、节假日日期列使用 Date 类型。STAR-SCHEMA 参考提供了可直接创建日期表的 DAXskills/powerbi-modeling/references/STAR-SCHEMA.mdDate ADDCOLUMNS( CALENDAR(DATE(2020,1,1), DATE(2030,12,31)), Year, YEAR([Date]), Month, FORMAT([Date], MMMM), MonthNum, MONTH([Date]), Quarter, Q FORMAT([Date], Q), WeekDay, FORMAT([Date], dddd) )若业务需要整数形式的时间键指令文件建议形如20240315YYYYMMDD的DateKey以及IsWorkingDay、FiscalYear、FiscalQuarter等业务列。十一、模型验证与测试框架1. 数据质量检查引用完整性核验所有外键都有对应匹配数据完整性检查关键列的缺失值业务规则验证确保计算与业务逻辑一致对比源系统合计性能测试验证查询响应时间。2. 关系与行为验证筛选传播测试交叉筛选行为是否符合预期度量准确性跨关系核验计算安全测试用不同角色验证 RLS用户验收与业务用户共同验收。指令文件把测试面扩展成可勾选的矩阵见其 Model Testing Checklist功能测试关系、度量、筛选、安全、刷新、性能测试加载时间、查询 SLA、交互响应、内存、并发负载、数据质量测试无缺失外键、合计对账、日期连续、安全过滤正确、业务规则正确。STAR-SCHEMA 参考还提供了结构级验证清单每张表明确是维度还是事实、事实表外键齐备、维度键唯一、日期表已建已标记、无环形关系、命名一致——可将其作为建模收尾的自检卡。十二、配套工具与仓库生态这组专家模式并非孤立文件。该 Agent 隶属于仓库内的 Power BI 开发插件插件通过插件清单 plugins/power-bi-development/plugin.json 把四个 Agentdata-modeling / dax / performance / visualization与对应技能打包可用copilot plugin install power-bi-developmentawesome-copilot安装。建模专家模式与以下资源互补使用效果最佳Power BI 数据建模最佳实践指令规则更细的建模执行规范applyTo声明了对.pbix/.md/.json/.txt生效powerbi-modeling 建模技能面向 Power BI Modeling MCP Server 的可执行技能支持连接活动模型、评估健康度、增删关系/度量等操作STAR-SCHEMA 星型模式参考星型模式速查手册同族的 DAX 专家模式 与 性能专家模式分别接管度量公式优化与性能诊断形成建模 → 度量 → 性能分工链。一个典型的协作路径是先用建模专家模式定架构与关系再用 DAX 专家模式打磨度量最后用性能专家模式/DAX Studio、Power BI Performance Analyzer 压测验证。这正是仓库把这些 Agent 组织成插件、而非散落单文件的初衷。十三、总结建模自检清单把全文收敛成一份可复制的交付前检查单每张表都明确是维度还是事实未混用职责与粒度事实表对相关维度均有外键粒度一致关系基数符合实际数据默认单方向筛选双向是例外外键/技术列已隐藏且为直接查询开启了引用完整性数据质量允许时存在连续、已标记的日期表替代自动日期/时间存储模式选择有据体积与实时性约束下合理使用 Import / DirectQuery / Dual / Hybrid大表采用增量刷新 可折叠查询必要时按热冷分区落地复合模型列、行、聚合三层做了数据精简避开全部性能反模式雪片、宽表、无桥多对多、双向泛滥、缺日期表RLS 用角色而非个人过滤并完成多账号实测用功能/性能/数据质量三份清单完成模型验证再用业务用户做验收。需要提醒的是本文所有规则以 awesome-copilot 仓库当前收录的 Agent 文档为准微软官方指引随版本演进会持续更新——这也是该 Agent 被设计为先检索microsoft.docs.mcp、再给结论的原因。在真实项目中建议把本文的清单当作初始骨架同时结合你的 Power BI 版本、容量规格与数据量级做最终取舍。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考