为你的产品或项目规划语义模型
要设计、构建并交付能够创造业务价值的 BI 解决方案所需的数据，关键在于先明确正确的需求。 如果你针对错误的问题设计了错误的东西（甚至根本没识别出问题），你的解决方案注定会失败……即使它用上了最新的功能或技术，并遵循了所有最佳实践。 但该如何着手为语义模型收集需求？ 需要重点考虑哪些方面？又有哪些工具或方法能帮到你？
在本系列中，我们会分享如何高效构建语义模型的实用建议。 在上一篇文章中，我们定义了什么是语义模型、一个好的语义模型应具备什么，以及构建语义模型的典型步骤。
本文将介绍为设计和构建语义模型收集需求时需要关注的关键点。 我们还会介绍如何使用 Tabular Editor 创建模型线框图，以及如何在原型中使用这些线框图，或在后续阶段借助它们加快语义模型的开发。
注意我们也建议你阅读 Microsoft 就该主题发布的官方指南。 来自 Power BI 和 Fabric 指导文档的相关文章对这些主题有详细讨论：
作者还写过一些相关主题的文章，你可能也会觉得有帮助： |
需求收集流程
一般来说，在开始构建语义模型之前，你应该先进行 BI 解决方案规划 (Microsoft 文章——Power BI 实施规划)。 解决方案规划的第一步，就是收集正确的需求。 这是确保你为正确的受众设计并落地正确模型、解决正确业务问题的关键一步。 需求收集流程的目标，是确保你能充分定义并理解语义模型需要解决的正确的业务问题或疑问：
- 为需求收集做准备： 进行务实的规划，召集需求收集流程所需的人员与资源。
- 收集业务需求： 明确模型范围，并在条件允许时收集相同范围内的现有数据与 BI 解决方案。 然后，通过互动式研讨会让相关方参与进来，以理解业务问题。 协作描述将如何解决该问题，例如通过 Report 样稿、用户流程，或一份简短的书面方案。
- 收集技术需求： 将第 2 步识别出的业务需求转化为技术规格说明。 这通常是你基于对用户期望最终成品的理解来设计语义模型的阶段。
- 规划部署： 进行务实的规划，筹备启动开发所需的资源。
注意 |
在需求收集过程中，你要确保自己能回答关于语义模型的关键问题。 这些问题的答案将决定你在模型设计中采用的思路。
回答关键问题
下文各节列出了你需要针对语义模型回答的一些重要问题。 这些只是示例，并不一定是覆盖所有场景的完整清单。
注意 |
关于模型将如何被使用的问题
- 你需要创建多少个模型？
你需要一个模型，还是多个模型？ 范围是否与业务目前使用的现有模型有重叠？还是需要让多个模型彼此“对话”？- 在选择一个更大的模型还是多个更小的模型时，需要考虑很多因素。 一般来说，应优先让模型聚焦于具体的业务问题/痛点，而不是把它变成“业务可能需要的所有数据”的大杂烩。
- 模型是只服务于集中式 Report，还是自助式用户也会查询它？
模型是只服务于集中式 Report，还是具备构建权限的内容消费者也能连接并查询语义模型？- 自助式模型需要你投入额外精力来整理并记录模型，例如添加显示文件夹和对象说明。
- 自助式模型可能还需要额外投入，以确保 DAX 能够对用户可能发起的查询保持足够灵活，并具备良好性能。
- 哪些下游工作负载和 Fabric 数据项会使用这个模型？
模型是仅供 Power BI 报表项（如 Report 或分页报表）使用，还是也会被其他 Fabric 工作负载使用（例如 notebooks 或 reflex）？- 你可以组织模型，让它们在这些工作负载中更容易被找到和使用，但有些项（例如 复合模型）有诸多特殊注意事项/限制，你应该在实现和使用之前就先了解清楚。
- 某些下游工作负载可能需要额外的治理考量（例如确保数据不会在冗余的、叠床架屋式 Report 中被重复复制）。
- 哪些客户端工具（如 Power BI Desktop 或 Excel）会连接并使用该模型？
模型是仅从 Power BI Desktop 使用，还是也会被 Excel（在 Excel 中分析或实时连接表）或 Tableau Desktop 等其他工具使用？- 某些功能（例如 字段参数与度量值的动态格式字符串）无法在所有客户端工具中工作，因为它们依赖于为 Power BI Desktop 设计的属性。
- 某些客户端工具可能允许用户查看隐藏对象（例如 Power BI Desktop），这意味着你需要特别注意，避免暴露无关或敏感对象。
- 你可能需要哪些用于 Report 的小众功能（如翻译或透视）？
你是否需要为模型对象实现不同的区域设置以支持翻译？ Report 用户在使用 personalize visuals 或选择透视来制作 复合模型 时，是否有这样的预期？- 创建并维护翻译或透视，可能会带来显著的额外工作量（也就是会额外占用你的时间）。
- 人们拿到数据后，实际会用它做什么？
是否预期用户会导出数据（99.9% 的情况下……会）？ 如果会，数据导出后他们会怎么用？ 他们会根据所使用的 Report 或执行的查询做出哪些决策，或采取哪些行动？- 理解这一点，有助于指导你的语义模型设计，从而在支持用户目标的同时降低风险。
关于底层数据的问题
- 是否有需要特别考虑的安全或合规要求？
你是否需要遵循特殊规则或法规，以满足涉密信息的合规要求，例如数据安全(行级安全性或对象级安全性)，或 数据丢失防护(例如敏感度标签或 DLP 策略)。- 数据安全会对模型的设计与实现产生重大影响。
- 敏感度标签会限制某些功能，例如 Fabric Git 集成，并且有多种注意事项和限制，例如下游标签继承。
警告 |
- 你需要连接并使用哪些数据源？
会使用哪些数据源？ 你是否需要 本地数据 Gateway 或 VNet Gateway？ 这些数据源将使用哪种存储模式？- 某些数据源可能需要你在连接器、Gateway、安全性、性能或存储模式方面特别关注。
- 每种存储模式（Import、DirectQuery 和 Direct Lake）各有利弊，本文不展开讨论。
- 是否有你需要遵循的特定命名规范？
是否有特定或非典型的命名规范需要遵循？ 如果没有，你会怎么统一给字段命名，让大家更方便找到需要的内容（也知道它具体是什么）？- 数据源中的字段名，可能与业务中的叫法不同。
- 现有工具和 Report 可能已经采用了用户熟悉的命名规范。
- 用户需要怎样的数据新鲜度？
业务是否需要“实时”数据(他们真的需要吗)？ 如果不是，模型应该多久刷新一次？ 上游数据更新的频率是多少？- 对数据新鲜度的不同要求可能会推动关键决策，例如存储模式。
- 导入模式模型可能需要不同类型的刷新策略（增量刷新）。
- 在 Power Query（或更上游）是否需要进行数据转换？ 具体有哪些？
如果所有转换都在上游完成，数据是否已“业务就绪”，可直接用于业务？ 你是否需要在 Power Query 中进行转换？如果需要，这些转换的范围有多大？- 你可能无法使用上游的工具或系统来转换数据。
- Power Query 转换需要额外投入，以确保模型刷新性能。
警告 |
|
|
关于模型生命周期的问题
- 模型部署到生产环境后，谁来支持它？
一旦它部署到生产环境（业务在用），你会负责支持它吗？ 如果不是你，那谁来负责？- 支持人员需要了解这个模型，最好在开发早期就参与进来。
- 及早明确并引入支持人员，可以减少交接时间，并降低生产环境部署后出现的困惑或中断。
- 在模型开发期间你会与他人协作吗？
你是否会与他人共同处理同一个模型，从而需要更成熟、更稳健的流程？ 是否会由其他人制作下游产物，或维护上游数据库？- 协作往往需要源代码管理，例如使用 Fabric Git 集成（配合 .pbip 文件）或 Azure Pipelines（配合模型元数据文件）。
- 与在语义模型上游/下游工作的团队和个人进行高效协同，对提升生产力并确保成功至关重要。
- 你将如何管理 Report 对象？
你是否需要 报表对象 来支持 Power BI 视觉对象的特定功能？- Report 对象应与模型的其他部分分开组织，并且最好隐藏起来（例如放在它们自己的 度量值表 中），因为它们通常只为单一、特定的上下文创建，对通用场景并不实用。
- 你将在哪里以及如何为模型编写文档？
你会在 wiki、Word 文档，还是用其他方式为模型编写文档？ 你打算给 Power Query (M) 代码、DAX 代码加注释，或者给对象添加描述吗？ 你是否已将“把这件事做好”所需的时间纳入项目排期？- 完善的文档需要时间，而在项目规划阶段往往很少被提前考虑。
- 尽早决定一种精简且可持续的方式来记录模型，可以在后期省下很多麻烦；尤其是在需要与规划流程（例如 DevOps）集成时。
- 你是否预期模型未来会有变更或新增？又该如何处理？
模型的范围会随着时间变化吗？或者它的使用范围会扩大到更多人吗？ 这些变更将如何处理？- 提前规划并预判变化，能确保模型具备可扩展性与灵活性。
- 尽早决定一种精简且可持续的方式来记录模型，可以在后期省下很多麻烦；尤其是在需要与规划流程（例如 DevOps）集成时。
设计模型：在 Tabular Editor 中制作线框
到这里，你应该已经对这个语义模型需要回答的业务问题与要解决的业务痛点有了足够的理解。 通过回答前面章节中描述的这类问题，你也已经对语义模型的技术需求有了足够的理解。 接下来，你需要设计你的模型。
在设计模型时，创建一个线框会很有帮助。 线框是一个不包含任何数据的模型；本质上，你只是创建模型的图形抽象……也就是它的设计。
图 2： 模型关系图，展示了在 Tabular Editor 中制作的 Power BI 语义模型 线框。
由于 Tabular Editor 以断开连接模式工作（即不需要数据，也不需要与数据库保持持续的活动连接），你可以通过模型元数据创建模型线框。 这有几个好处：
- 验证假设：在开发前验证你对业务或技术需求的假设，能在后续节省时间。
- 更准确的估算：更好地评估开发模型所需的工作量与时间，尤其是当你已经对线框做了整理时。
- 确立“北极星”：用实际的语义模型设计来体现技术需求，让所有人都清楚最终要达成的结果。
- 从线框到原型再到语义模型：由于你是在 Tabular Editor 中工作，线框可以很容易调整成一个可用的模型。 例如，你可以用静态表的样例数据添加分区，以创建一个原型。 之后，当你准备开始开发时，也可以直接连接到你的数据源(s)，并复用你在线框中完成的一切。
在 Tabular Editor 中创建线框很简单。 你只需要创建一个新模型，然后在没有任何数据源的情况下开始添加对象。
如何在 Tabular Editor 中创建语义模型线框
- 在 Tabular Editor 中新建一个模型并保存元数据。
- 创建表对象，或从现有的类似模型中 复制 它们。
- 添加你可能需要的共享表达式（例如用于连接字符串参数）。 别忘了把“Type”设置为“M”。
- 创建你预计每张表会包含的列。 确保你为以下属性做好设置：
- 数据类型：列的数据类型（例如 Integer）。
- 按列排序：如果你预计需要非典型排序（例如“星期名称”按“星期序号”排序）。
- 源列：该列在数据源中的列名（例如通常与列名相同）。
- 创建模型关系图，并通过拖放字段来创建关系。
- 针对日期表或字段参数等特定场景，创建计算表格。
- 针对时间智能或度量值替换等特定场景，创建计算组。
- 创建 DAX 度量值，用于对列进行显式汇总，或用于业务需求中被识别为具有战略意义的字段/KPI。
- 创建预计需要的数据安全角色，以及表和对象权限（如果已明确）。
- 你也可以设置关键属性（例如刷新策略），或对模型进行整理（放到显示文件夹或表格组里）。
- 保存模型和关系图，并截取关系图作为线框的可视化表示。
你也可以在后续开发中使用这个线框：
- 原型：要把线框转换为原型，你只需要在表分区中输入相应的 Power Query (M) 语法，用模拟数据来填充分区。 这些可以是简单的 5-25 行静态表，用于演示功能并验证 DAX。
- 开发模型：要把线框转换为可用的功能模型，你只需要将分区替换为用于连接到数据源的分区。 如果你使用显式的数据源对象（例如用于 AAS / SSAS），也需要把该对象一并添加进去。 确保你的表架构与数据库中的表一致。
结语
在任何数据与 BI 项目中，收集正确的需求都至关重要，能确保你最终得到期望的结果。 在构建语义模型时，这意味着要清晰定义所要解决的业务问题/业务疑问，并把收集到的业务需求有效地转化为技术需求。
一个有效的方法是：先回答一组关于模型的关键问题，然后创建一个模型线框来呈现你的预期设计。 Tabular Editor 是创建模型线框的一个好工具；如果后续你需要原型或概念验证 PoC，这部分工作也能直接复用。 此外，你还可以用几个简单步骤把这个线框转换成一个完全可用的模型。
关于“为语义模型收集需求”的 3 条评论
-
Pingback: 语义模型中的 DAX 基础 – Tabular Editor Blog
-
Pingback: 验证语义模型关系 – Tabular Editor Blog
-
Pingback: 为语义模型准备数据 – Tabular Editor Blog
