企业官网建设流程全解析

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 数据建模专家 Agent（agents/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）：

2. Agent 的标准响应流程

对每一个建模请求，Agent 被要求按固定 7 步产出（Response Structure）：

1. 文档检索：用microsoft.docs.mcp检索当前建模最佳实践；
2. 需求分析：理解业务与技术需求；
3. 模式设计：推荐合适的星型结构；
4. 关系策略：定义最优关系模式；
5. 性能优化：识别优化机会；
6. 实现指导：给出逐步实现建议；
7. 验证方案：给出测试与校验方法。

这与仓库配套技能 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. 表结构设计规范

维度表：做什么、不做什么

事实表：做什么、不做什么

补充：如果源数据缺乏唯一标识，可用 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. 关系类型与使用场景

仓库最佳实践指令补充了更细的一对一适用场景：扩展维度附加属性、分离 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 ❌ Don't create unnecessary many-to-many relationships

其下层的工程含义是（可结合最佳实践指令中的"关系配置指南"一起看）：

• 筛选方向：单方向筛选是默认最优解；双方向（Both Directions）只在业务逻辑确实需要交叉筛选时开启；应始终避免环形关系路径。
• 引用完整性（Assume Referential Integrity）：DirectQuery 场景下，只要数据质量有保证，开启它可让引擎使用 INNER JOIN，显著提升查询性能；若源存在孤儿记录则不要开启，否则会产生错误结果。
• 外键列隐藏：把作为连接键的 ID 列从报表视图中隐藏，减少视觉噪音与元数据膨胀。

3. 关系故障排查

原文档总结了四类高频故障与对策：

四、存储模式选型：Import / DirectQuery / Composite / Dual

Power 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 relationships

2. 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{[Schema="dbo",Item="FactInternetSales"]}[Data], #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))), #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"]))) in #"Filtered Rows1"

写法二：原生 SQL 拼接（会禁用查询折叠）——当需要完全掌控 SQL 时使用，注意[EnableFolding=false]会让增量刷新失去分区级裁剪能力，成本更高：

// 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, [EnableFolding=false]) 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），更直观但模型体积更大。

指令文件补充了对应 DAX：

Sales 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 参考提供了可直接创建日期表的 DAX（skills/powerbi-modeling/references/STAR-SCHEMA.md）：

Date = 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") )

若业务需要整数形式的时间键，指令文件建议形如20240315（YYYYMMDD）的DateKey，以及IsWorkingDay、FiscalYear、FiscalQuarter等业务列。

十一、模型验证与测试框架

1. 数据质量检查

• 引用完整性：核验所有外键都有对应匹配；
• 数据完整性：检查关键列的缺失值；
• 业务规则验证：确保计算与业务逻辑一致（对比源系统合计）；
• 性能测试：验证查询响应时间。

2. 关系与行为验证

• 筛选传播：测试交叉筛选行为是否符合预期；
• 度量准确性：跨关系核验计算；
• 安全测试：用不同角色验证 RLS；
• 用户验收：与业务用户共同验收。

指令文件把测试面扩展成可勾选的矩阵（见其 "Model Testing Checklist"）：功能测试（关系、度量、筛选、安全、刷新）、性能测试（加载时间、查询 SLA、交互响应、内存、并发负载）、数据质量测试（无缺失外键、合计对账、日期连续、安全过滤正确、业务规则正确）。STAR-SCHEMA 参考还提供了结构级验证清单：每张表明确是维度还是事实、事实表外键齐备、维度键唯一、日期表已建已标记、无环形关系、命名一致——可将其作为建模收尾的自检卡。

十二、配套工具与仓库生态

这组专家模式并非孤立文件。该 Agent 隶属于仓库内的 Power BI 开发插件，插件通过插件清单 plugins/power-bi-development/plugin.json 把四个 Agent（data-modeling / dax / performance / visualization）与对应技能打包，可用copilot plugin install power-bi-development@awesome-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 组织成插件、而非散落单文件的初衷。

十三、总结：建模自检清单

把全文收敛成一份可复制的交付前检查单：

1. 每张表都明确是维度还是事实，未混用职责与粒度；
2. 事实表对相关维度均有外键，粒度一致；
3. 关系基数符合实际数据，默认单方向筛选，双向是例外；
4. 外键/技术列已隐藏，且为直接查询开启了引用完整性（数据质量允许时）；
5. 存在连续、已标记的日期表，替代自动日期/时间；
6. 存储模式选择有据：体积与实时性约束下合理使用 Import / DirectQuery / Dual / Hybrid；
7. 大表采用增量刷新 + 可折叠查询，必要时按热冷分区落地复合模型；
8. 列、行、聚合三层做了数据精简；
9. 避开全部性能反模式（雪片、宽表、无桥多对多、双向泛滥、缺日期表）；
10. RLS 用角色而非个人过滤，并完成多账号实测；
11. 用功能/性能/数据质量三份清单完成模型验证，再用业务用户做验收。

需要提醒的是：本文所有规则以 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