对“CompanyProject”表执行相同的操作。
使用 Power BI Desktop 中的“获取数据”导入数据。 选择两个表作为数据源，然后选择“加载”。
第一个表“ProjectHours”是记录某位员工在特定项目上工作的小时数的工作单记录。
ProjectHours
请注意，每个表都具有一个项目列。 每个列的命名略有不同，但其值看起来相同。 这个区别很重要，我们很快将回到这一点。
我们向一个模型导入了两个表，接下来创建报表。 首先，我们要获取的是按项目优先级提交的小时数，因此选择“字段”窗格中的“Priority”和“Hours” 。
如果在报表画布中查看表，你会看到每个项目的小时数均为“256”，这也是总数。 显然，此数字不正确。 为什么？ 这是因为如果这两个表之间不存在关系，则不能由一个表中的值（“CompanyProject”表中的“Priority”）切分另一个表中的值（“Project”表中的“Hours”）来计算后者值的总数 。
因此，让我们在这两个表之间创建一个关系。
还记得两个表中具有项目名称但其值看似相似的那些列吗？ 我们将使用这两列来创建表之间的关系。
为什么是这些列？ 嗯，如果查看“ProjectHours”中的“Project”列，可看到蓝色、红色、黄色、橙色等 。 事实上，显示了多个具有相同值的行。 “Project”实际上具有多个颜色值。
如果查看“CompanyProject”表中的“ProjName”列，可看到每个项目名称仅具有一个颜色值 。 这个表中的每个颜色值都是唯一的，这一点很重要，因为我们可在这两个表之间创建关系。 此情况下，可创建多对一的关系。 在多对一的关系中，一个表中至少有一个列必须包含唯一值。 对于一些关系，还有更多选项，我们将在后面讨论。 现在，让我们为两个表各自的“Project”列创建关系。
若要创建新关系
从“建模”选项卡选择“管理关系”。
在“管理关系”中，选择“新建”以打开“创建关系”对话框，可在其中选择表、列以及要用于关系的任何其他设置。
在第一个下拉列表中，选择“ProjectHours”作为第一个表，然后选择“Project”列 。 此方是关系中的
多方
。
在第二个下拉列表中，“CompanyProject”已被预先选择为第二个表。 选择“ProjName”列。 此方是关系中的
单方
。
接受关系选项的默认设置，然后选择“确定”。
在“管理关系”对话框中，选择“关闭” 。
为了完全展示，只需以复杂的方式创建这一关系。 其实选择“管理关系”对话框中的“自动检测”即可。 事实上，如果两个列的名称相同，则在加载数据时，自动检测功能会自动为你创建关系。
现在，我们再来看一下报表画布中的表。
这看起来好得多，不是吗？
按“Priority”汇总小时数时，Power BI Desktop 会查询“CompanyProject”查找表中唯一颜色值的每个实例，然后查询“ProjectHours”表中这些值的每个实例，最后计算每个唯一值的总和 。
借助自动检测功能，可能甚至无需执行此操作。
了解其他选项
使用自动检测功能或手动创建关系时，Power BI Desktop 会基于表中的数据自动配置其他选项。 这些其他关系选项位于“创建关系”和“编辑关系”对话框的底部 。
Power BI 通常自动设置这些选项，你无需调整它们。 但在一些情况下，最好自己配置这些选项。
自动关系更新
可以管理 Power BI 如何处理和自动调整报表和模型中的关系。 若要指定 Power BI 处理关系选项的方式，请在 Power BI Desktop 中选择“文件”>“选项和设置”>“选项”，然后在左侧窗格中选择“数据加载” 。 此时系统会显示“关系”的选项。
可选择和启用三个选项：
在第一次加载时从数据源导入关系
：默认情况下选择此选项。 选中后，Power BI 会检查数据源中定义的关系，例如数据仓库中的外键/主键关系。 如果存在这种关系，那么在最初加载数据时，会将它们镜像复制到 Power BI 数据模型。 利用此选项，可以快速开始使用模型，而无需自行查找或定义这些关系。
在刷新数据时更新或删除关系
：默认情况下不选择此选项。 如果选中，则 Power BI 会在刷新数据集时检查数据源关系中的更改。 如果更改或删除这些关系，Power BI 会在其自己的数据模型中镜像这些更改，进行更新或删除以使其匹配。
如果使用依赖于已定义关系的行级别安全性，我们建议不要选择此选项。 如果删除 RLS 设置所依赖的关系，则模型的安全性可能会降低。
加载数据后自动检测新关系
：
在加载期间自动检测
中介绍了此选项。
将来更新数据需要其他基数
通常，Power BI Desktop 可自动确定用于关系的最佳基数。 如果由于知道数据将在未来更改，而确实需要替代自动设置，则可在“基数”控件中对其进行更改。 我们来看一个需要选择其他基数的示例。
“CompanyProjectPriority”表列出了所有公司项目及其优先级。 而“ProjectBudget”表是一组其预算已获批准的项目。
CompanyProjectPriority
如果我们在“ProjectBudget”表的“Approved Projects”列和“CompanyProjectPriority”表的“ProjectName”列之间创建关系，则 Power BI 会自动将“基数”设置为“一对一(1:1)”，并将“交叉筛选方向”设置为“双向” 。
Power BI 进行这些设置的原因在于，对于 Power BI Desktop 而言，两个表的最佳组合如下所示：
这两个表之间存在一对一的关系，原因是组合表的“ProjName”列中没有重复值。 “ProjName”列是唯一的，因为每个值仅出现一次；因此，这两个表中的行可直接合并而无任何重复项。
但是，假设你知道在下次刷新数据时，此数据会进行更改。 对于蓝色和红色项目，刷新后的“ProjectBudget”表现在具有其他行：
ProjectBudget
已批准的项目
在这一新的组合表中，“ProjName”列具有重复值。 刷新表格后，两个原始表将不再具有一对一的关系。 在此情况下，由于我们知道将来的这些更新将导致“ProjName”列出现重复项，我们想要将“基数”设置为“多对一(*:1)”，其中多方位于“ProjectBudget”上，而单方位于“CompanyProjectPriority”上。
为一组复杂的表和关系调整交叉筛选方向
对于大多数关系，交叉筛选方向设置为“双向”。 但在一些更少见的情况下，可能需要将此选项设置为与默认值不同的值。 举个例子，如果从旧版 Power Pivot 导入模型，其中每个关系都设置为单向。
通过“双向”设置，Power BI Desktop 可将连接表的所有方面均视为如同是一个表。 然而在某些情况下，Power BI Desktop 无法将关系的交叉筛选方向设置为“双向”，同时还会保留一组可用于报表且语义不明的默认值。 如果关系的交叉筛选方向未设置为“双向”，这通常是因为它会造成多义性。 如果默认的交叉筛选设置不适用于你，请尝试将其设置为特定表或“双向”。
单向交叉筛选适用于很多情况。 事实上，如果你在 Excel 2013 或更早版本中导入 Power Pivot 中的模型，则所有关系均将设置为单向。 单向是指连接表中的筛选选项适用于将进行聚合操作的表格。 有时，交叉筛选可能有点难以理解，因此我们来看一个示例。
使用单向交叉筛选时，如果你创建一个可汇总项目小时数的报表，则可选择按“CompanyProject”表及其“Priority”列或“CompanyEmployee”表及其“City”列进行汇总（或筛选） 。 但如果你想计算每个项目的员工数（不太常见的问题），则不适用。 你将获取完全相同的一列值。 在下面的示例中，两个关系的交叉筛选方向均设置为单向：指向“ProjectHours”表。 在“值”Well 中，“Project”字段设置为“Count” ：
筛选器规范将从“CompanyProject”流向“ProjectHours”（如下图所示），但不会抵达“CompanyEmployee” 。
但若将交叉筛选方向设置为“双向”，则会起作用。 “双向”设置使筛选器规范可流到“CompanyEmployee” 。
通过将交叉筛选方向设置为“双向”，报表现可正确显示：
双向交叉筛选非常适合表格关系模式（例如前面显示的模式）。 此架构通常称为星型架构，如下所示：
双向交叉筛选不太适合数据库中常有的更常规模式，比如以下关系图中的模式：
如果你具有与此类似的表格模式，则交叉筛选会创建一组语义不明的关系。 例如，如果你求取 TableX 中某个字段的总和，然后选择按 TableY 中的某个字段进行筛选，则不清楚筛选器应如何流动，是通过顶部表还是底部表进行流动。 这种模式的一个常见示例是 TableX 为具有实际销售额数据的销售表，而 TableY 具有预算数据， 则中间的表格是这两个表所用的查找表，如部门或地区。
和活动/非活动关系一样，如果会导致报表的多义性，则 Power BI Desktop 不允许将关系设置为“双向”。 可通过多种不同方式来处理这种情况。 以下为最常见的两种方式：
删除关系或将其标记为“非活动”，以减少多义性。 然后，可能就能够将关系的交叉筛选设置为“双向”。
导入表格两次（第二次使用其他名称）以消除循环。 这样做会产生类似于星型架构的关系模式。 借助星型架构，所有关系均可设置为“双向”。
错误的活动关系
Power BI Desktop 自动创建关系时，有时会在两个表之间遇到多个关系。 发生此情况时，仅其中一个关系会设置为“活动”。 活动关系用作默认关系，因此在从两个不同的表中选择字段时，Power BI Desktop 可自动为你创建可视化效果。 但在某些情况下，自动选定的关系可能是错误的。 使用“管理关系”对话框将关系设置为“活动”或“非活动”，或者可在“编辑关系”对话框中设置活动关系 。
为了确保存在默认关系，Power BI Desktop 仅允许两个表在给定时间存在单个活动关系。 因此，你必须先将当前关系设置为“非活动”，然后才能将想要的关系设置为“活动”。
我们来看一个示例。 第一个表是“ProjectTickets”，第二个表是“EmployeeRole” 。
ProjectTickets
现在，如果创建一个报表，且该报表在报表画布的表格可视化效果中使用“EmployeeRole”中的“Role”和“Employee”字段，以及“ProjectTickets”中的“Hours”字段，则只会显示项目发起人，因为他们是唯一开具项目单的人员 。
我们可更改活动关系并获取“SubmittedBy”，而不是“OpenedBy” 。 在“管理关系”中，取消勾选“ProjectTickets(OpenedBy)”到“EmployeeRole(Employee)”的关系，然后勾选“EmployeeRole(Employee)”到“Project Tickets(SubmittedBy)”的关系 。
在“关系”视图中查看所有关系
有时，模型具有多个表格，且各表格之间存在复杂关系。 Power BI Desktop 中的“关系”视图可显示模型中的所有关系及其方向和基数，是一种易于理解且可自定义的关系图。
若要了解详细信息，请参阅
使用 Power BI Desktop 中的关系视图
。
本部分提供在 Power BI 中处理关系时的指导和故障排除信息。
无法确定各字段之间的关系
Power BI 尝试通过从正在使用的模型推断关系来在视觉对象中显示相关数据。 有时这类推理并不明显，你可能会意外发现视觉对象中存在指示特定列之间没有关系的错误。
为了说明 Power BI 如何确定字段是否相关，让我们使用一个示例模型来说明下面几节中的几个场景。 下图显示了我们将在示例场景中使用的示例模型。
场景 1：传统的星型架构，不提供度量约束。
参考上图中的示例模型，让我们首先查看该图像的右半部分：“供应商 - 购买 - 产品”表。 此示例是一种传统星型架构，包含事实数据表（“购买”）和两个维度表（“产品”和“供应商”）。 维度表与事实数据表之间的关系是“一对多”（一个产品对应多个购买，一个供应商对应多个购买）。 对于这种类型的架构，我们可以回答如下问题：“产品 X 的销售额是多少？”、“供应商 Y 的销售额是多少？”以及“供应商 Y 销售哪些产品？”
如果想将“产品”和“供应商”相关联，可以通过查看“购买”表来判断是否存在具有相同产品和供应商的条目。 示例查询可能如以下示例所示：
Correlate Product[Color] with Vendor[Name] where CountRows(Purchases)>0
where CountRows(Purchases)>0
是 Power BI 将添加的一个隐式约束，以确保返回相关数据。
通过“购买”表进行此关联，可以返回在事实数据表中至少占一个条目的“产品-供应商”配对，这些配对从数据的角度来看是有意义的。 可以预见，将不会显示任何从未有过销售额（对分析没有用处）的“产品-供应商”的无意义组合。
场景 2：传统的星型架构，提供度量约束。
在场景 1 的前一个示例中，如果用户以汇总列（例如，购买数量的总和/平均数/计数）或模型度量值（VendID 的非重复计数）的形式提供约束，Power BI 可以生成以下示例形式的查询：
Correlate Product[Color] with Vendor[Name] where MeasureConstraint is not blank
在这种情况下，Power BI 会尝试返回对用户提供的约束具有有意义值（非空白）的组合。 Power BI 不需要添加自己的隐式约束“CountRows(Purchases)>0”，如在前面的场景 1 中所做的那样，因为用户提供的约束就足够了。
场景 3：非星型架构，不提供度量约束。
在这个场景中，我们将注意力集中在模型的中心，可以看到“销售额 - 产品 - 购买”表，其中有一个维度表（“产品”）和两个事实数据表（“销售额”和“购买”）。 由于这不是星型架构，因此我们无法回答场景 1 中同样的问题。 假设我们尝试将“购买”与“销售额”相关联；由于“购买”与“产品”为多对一关系，“产品”与“销售额”为一对多关系， 因此“销售”与“购买”间接为多对多关系。 我们可以将一个“产品”链接到多个“购买”，将一个“产品”链接到多个“销售额”，但不能将一个“销售额”链接到多个“购买”，反之亦然。 我们只能将多个“购买”链接到多个“销售额”。
在这种情况下，如果我们尝试在视觉对象中组合 Purchase[VenID] 和 Sales[CustID]，由于这些表之间存在多对多关系，Power BI 没有可以应用的具体约束。 尽管可能存在可应用于各种场景的自定义约束（不一定源自模型中建立的关系），但 Power BI 无法仅根据关系推断默认约束。 如果 Power BI 尝试返回两个表的所有组合，它将创建一个大型交叉联接并返回不相关的数据。 相反，Power BI 会在视觉对象中引发一个错误，如下所示。
场景 4：非星型架构，提供度量约束。
如果我们以场景 3 为例，以汇总列（例如 Count of Product[ProdID]）或模型度量值 (Sales[Total Qty]) 的形式添加用户提供的约束，则 Power BI 可以以 Correlate Purchase[VenID] 和 Sales[CustID] 的形式生成查询，其中 MeasureConstraint 不为空。
在这种情况下，Power BI 将用户的约束视为 Power BI 需要应用的唯一约束，并返回为其生成非空值的组合。 用户已将 Power BI 引导至所需的方案，Power BI 会应用该指南。
场景 5：提供度量约束但与列部分相关时。
在某些情况下，用户提供的度量约束并不完全与视觉对象中的所有列相关。 模型度量值始终将所有内容关联在一起。 Power BI 在尝试查找视觉对象中的列之间的关系时会将此场景视为黑匣子，并假定用户知道他们正在使用它执行哪些操作。 但是，从用户界面中选择的“总和”、“平均值”和类似汇总形式的汇总列可能仅与基于该列所属表的关系的视觉对象中使用的列/表的子集相关。 因此，约束适用于某些列配对，但并非适用于全部。 在这种情况下，Power BI 会尝试查找可以应用于与用户提供的约束无关的列的默认约束（如场景 1）。 如果 Power BI 找不到任何内容，则返回以下错误。
解决关系错误
看到“无法确定各字段之间的关系”错误时，可以执行以下步骤来尝试解决该错误：
检查模型。 是否针对你想通过分析回答的问题的类型进行了适当设置？ 你能否更改表之间的某些关系？ 能否避免创建间接的“多对多”关系？
考虑将反向 V 形架构转换为两个表，并使用它们之间的直接“多对多”关系，如
在 Power BI Desktop 中应用多对多关系
中所述。
以汇总列或模型度量值的形式向视觉对象添加约束。
如果已添加汇总列，但仍出现错误，请考虑使用模型度量值。
有关模型和关系的详细信息，请参阅以下文章：
在 Power BI Desktop 中使用复合模型
Power BI Desktop 中的存储模式
在 Power BI 中使用 DirectQuery
Power BI 数据源
