数据建模
在 Microsoft Power Platform 上进行数据建模可考察整体数据体系结构情况，使用连接器以符合逻辑的方式查看来自于 Dataverse、数据湖和外部源的数据。
数据建模的类型和标准有很多，包括统一建模语言 (UML)、IDEF1X 等。 有些数据模型标准超出了本单元的讨论范围，但 Dataverse 数据结构的数据模型一般分为两大类：
- 逻辑数据模型
- 物理数据模型
实体关系图
逻辑数据模型是显示数据在系统中流动方式的高级别图表。 在项目开始时的发现期间以及定义所有列之前，逻辑数据模型经常会放在一起。 通常，逻辑数据模型图表会使用实体的业务名称，而非架构名称。
逻辑数据模型图表只描述数据在解决方案中的流动方式，而不关心其物理实施。
物理数据模型的级别低于逻辑数据模型。 其中通常会包含列级别详细信息，更准确地说是会包含设计关系。 在将高级别逻辑设计转换为物理实体时，便会创建物理数据模型。
物理数据模型图表应显示 Dataverse、Microsoft Azure Data Lake Storage、Analysis Services Connector 或其他数据存储边界。
您还可创建对象图表。 对象图表会显示您想要了解的信息，更重要的是会显示您不希望了解的信息。 对象图表需要在与域专家进行建模会话时完成。
数据建模策略
构建数据模型时，需考虑以下准则：
- 从核心表和关系开始 - 通常，团队会被整个问题牵着鼻子走，然而最简单的办法是先解决挑战中的一小部分问题，稍后在整体看到问题的全貌。
- 过度标准化 - 团队中如果有数据架构背景很强的人员，他们通常会像构建传统 SQL Server 数据库一样构建一个 Dataverse 数据模型。 这种方法可能会导致用户体验不佳，并且需要额外处理。 解决方案架构师需要与能够确定用户体验中因果关系的人员合作，以帮助其了解目标。
- 当前需求 - Dataverse 有一个非常棒的功能，即可通过敏捷流程进行增量生成；不过，了解短期和长期未来情况可帮助奠定一个基础。 您要避免沉迷于尝试确定您能够想到的每一个未来需求。
- 概念验证 - Dataverse 可简化创建环境、试用模型、放弃模型以及重试的过程。 有时，向两支团队发起同一个数据建模挑战可以获得意想不到的结果。
数据模型影响因素
数据模型可能会受到各种因素的影响：
- 安全要求 - 解决方案架构师应始终力求简单，但在力求简单的同时，也要将相关要求贯彻到数据模型中。
- 用户体验 - 人们经常会遗忘的一个概念是，您在添加标准化和关系的时候，还要创建需要用户在应用中适应的新构建。
- 数据位置和保留 - 并非所有数据都要存储。 通常，来自服务的数据不能缓存，并且公司在数据使用的管理方面都有自己的内部政策。 有些数据受到政府法律的保护，或者可能需要满足特定的存储要求，比如身份识别类信息、信用卡卡号等。
- 自助服务报告 - 如果需要数据架构师来导航数据模型，那么 Power BI 中的很多工具以及“导出到 Excel”对于用户来说就没有多大价值了。 Dataverse 的大部分自助服务功能都支持导航一个级别的关系。
- 现有系统 - 如果存在 API，考虑相应系统是否为旧版系统，或者考虑数据是否可访问或可复制。
- 本地化 - 评估相关要求是多区域要求、多语言要求还是多货币要求。