使用应用存储或查看数据时，数据结构是设计的重要组成部分。 除其他人如何使用数据以外，您还应考虑如何在一个特定应用或屏幕中使用数据。 引用角色、任务、业务流程和目标将帮助您定义要存储的数据及其结构。

Dataverse 支持三类表：

• 标准 - 可在模型驱动应用中存储数据并添加到导航的表。 您创建的大部分表都是标准表。 从 Dataverse 环境中的 Common Data Model 架构创建若干标准表。
• 活动 - 这些表用于存储电话联络、任务和预约等交互。 Dataverse 数据库中包含一系列活动表。
• 虚拟 - 这些表允许在 Dataverse 中创建表和列，然后使用外部数据源存储数据。 对用户而言，数据像所有其他数据那样显示在应用中。

您必须在创建自定义标准表时指定其所有权：

• 用户/团队 - 默认选项
• 组织 - 用于引用数据

活动表用于存储交互。 活动表与所有为表元数据设置启用活动的表存在关系。 活动表共享相同的列集并共享相同的安全权限。 活动表中的行显示在模型驱动应用窗体的时间线中。 在本示例中，已创建名为“捐赠”的自定义活动表。

使用自定义活动表的优势包括：

• 与其他活动一起显示在列表中。
• 可与其他活动汇总。
• 可在任意支持活动的表中创建捐赠。

使用自定义活动表的劣势包括无法：

• 配置不同于所有其他活动的安全性。
• 控制关联捐赠的表。

您需要明智地选择列的数据类型。 本概念对于数值数据类型尤其正确，因为您无法比较不同类型的数值列并且对计算列和汇总列的数据类型设置限制。 选定类型后无法更改。

视情况选择查找表或选项表。

在以下情况下使用选项表：

• 仅将标签和值存储为键值对。
• 包含内置本地化。
• 视为解决方案组件。
• 无停用值的内置方式。
• 包含适用于约 200 个项目的 UX。
• 可以使用 Javascript 筛选。
• 作为整数存储在行中。

在以下情况下使用查找表：

• 可在行上的列中存储其他数据。
• 要求生成本地化。
• 视为引用数据。
• 支持不活动状态。
• 包含扩展到多个项目的 UX。
• 可按视图和安全性筛选。
• 存储为实体引用。

在查找表中存储其他数据允许您在运行工作流或其他引用数据的自定义时访问。 例如可在检查条件中使用相关属性。

选项表作为解决方案组件，可为值添加发布者前缀来处理合并解决方案。

在选择表中添加值需要管理员/定制员级别访问权限，而通过安全角色授予权限的用户可以更改查找值。

用户体验 (UX) 选项特别适用于较小的数量，但不适用于较大的集合。 查找提供选项上不可用的搜索类型功能。

如有多个相互依赖的选项列，只能通过基于窗体的脚本实现本任务，而查找可在其他查找中使用配置进行筛选。

您可在多个文件和图像存储位置中进行选择：

• Dataverse - 使用文件和图像数据类型存储文件和图像。
• SharePoint - 用于协作，但本选项存在安全问题。 文件的安全性遵循 SharePoint 权限，不与 Dataverse 行权限同步。
• Azure 存储 - 用于存档和外部访问。 本选项具有独立安全性，但可为出于使用目的生成的链接（附属模式）在短时间内授予。 Azure 存储也可以处理大文件。

文件和图像数据类型的特征：

• 适合上传和引用。
• 安全性遵循记录权限。
• 受大小限制。

计算列允许对行中的数据执行简单计算并且：

• 在检索记录时计算。
• 包含只读值。
• 可以包括相同行的列和多对一关系中的列。
• 可在计算中包括汇总列。
• 无法触发工作流、插件或 Power Automate 的事件。
• 它们使用 Fx 公式语言创建。

汇总列允许对一对多关系中的相关行进行聚合并且：

• 按计划计算（至少一小时）并且用户可按需更新。
• 包含只读值。
• 可以汇总计算列。
• 可以使用相关记录的层次结构。
• 可以筛选相关表。
• 无法触发工作流、插件或 Power Automate 的事件。

您可以汇总“简单”计算列，即包含无法汇总的非确定性函数的计算列。

关系定义 Dataverse 中各行彼此的关联方式。 Dataverse 中的每个表都包含主键，为表中的行提供唯一引用。 在 Dataverse 中，主键是创建行时 Dataverse 自动生成的全局唯一标识符 (GUID)。 为主键添加引用创建关系，称为外键。 在 Dataverse 中，使用一个表中的列保存外键值来创建关系。 此外键是指向另一表中主键的指针。

Dataverse 中支持两种类型的关系：

• 一对多 (1:N)
• 多对多 (N:N)

以下支出报表给出一对多 (1:N) 关系示例。

以上屏幕截图展示支出报表的主要部分，其中包含员工姓名和部门详细信息。 主要部分下方是针对每个采购项目的多行说明。 在本示例中，这些说明称为行项。 行项结构不同于支出报表的主要部分。 因此，每个支出报表都包含多个行项。

支出报表与行项之间的关系是一对多 (1:N) 关系示例。 支出报表的主要部分链接多个行项。 您还可以从行项的视角查看关系：每个行项只能链接一个支出报表，即多对一 (N:1) 关系。

多对多数据结构是一种特殊类型，用于多个记录关联多组其他记录的案例。 业务合作伙伴网络是多对多数据结构的好例子。 您有多个业务合作伙伴（客户和供应商）合作，这些业务合作伙伴与您的多位同事合作。

以下部分给出不同类型的多对多数据结构示例。

以下示例展示两组数据：一组代表员工，另一组代表休假请求。 每个员工都会提交多个请求，因此该应用场景中的关系为一对多，其中“一”为员工，“多”为请求。 员工数据和休假请求数据彼此关联，将员工编号作为公共列（也称为键）。

在本示例中，数据结构看起来比较复杂，但与本文开头讨论的支出报表示例相似。 每个供应商都与多个采购订单关联。 每个员工负责多个采购订单。 因此，这两组数据都具有一对多数据结构。

员工可能不总使用相同的供应商，供应商由多名员工使用，每个员工与多个供应商合作。 因此，员工与供应商之间的关系为多对多。

以下示例展示包含支出报告解决方案多个表的实体关系图 (ERD)。

本示例包含两位 VIP：John 和 Mary。 John 选择 WiFi 和洗衣店福利，Mary 选择 WiFi 和小酒吧福利。 您可以通过不同的方式对本应用场景进行建模。 第一种方法是将本应用场景建模为 1:N 关系。

在本配置中：

• 福利记录对联系人唯一。
• 不提供查看所有选择某项福利的联系人的功能。
• 您可以基于联系人的所有者实施福利记录安全功能。
• 您可在联系人特定福利记录中存储更多数据。
• 关系是福利的父级，否则将孤立福利记录。

第二种方法是将本应用场景建模为 N:N 关系。

在本配置中：

• 福利关联记录显示所有选择福利的联系人。
• 所有联系人共享福利安全功能，因此您无法为每个联系人量身定制。
• 所有联系人共享所有福利属性，因此不存在联系人特定数据。
• 您必须使用引用关系，否则将从其他联系人删除福利。

这两种配置都不理想。

下一示例展示创建自定义（插件）表保存 VIP 福利。

本配置：

• 添加在联系人特定福利表中存储更多数据的功能。
• 需要用户通过更多操作连接记录，用户现在需要手动创建相交行。
• 单独保护福利。
• 无法直接访问福利表属性，因此查询更加困难。

以下示例展示使用联系人表中的列。

本配置：

• 特别适用于主要福利和次要福利，但无法扩展跟踪多项福利。
• 简化查询，支持用户更轻松地自助使用 Power BI。
• 与联系人记录遵循相同的安全功能。
• 如果查询所有选择主要福利的用户，要求创建扫描主要福利和次要福利的查询。

必须出于某些合规/统计目的记录福利，但不影响业务或处理时，本配置是很棒的示例。

关系行为控制某些操作向下级联到通过 1:N 关系关联主表的行。 行为保持引用完整性，可以防止留下孤立记录。

在集成中使用替换键减少执行查询查找记录的需要。 您可在不确定 GUID 的情况下使用替换键更新行。

替换键：

• 特别适合在检索和更新中使用。
• 可以包含小数、整数、文本字段、日期和查找字段。
• 每个表最多可以包含五个替换键。
• 在后台创建可为空的唯一索引，强制确保键的唯一性。

创建键后，系统将验证平台支持该键。