当表之间建立关系时，幕后发生了什么？
What is happening under the hood when a relationship is established between tables?
这个问题不限于Power BI，但它会帮助我解释我的问题。
如果您在 Power BI 中有多个 table，您可以通过将一列从一个 table 拖动到另一个来建立它们之间的关系，如下所示：
您可以通过单击出现的行来编辑该关系：
顺便说一下，这是两个 table 的结构：
# Table1
A,B
1,abc
2,def
3,ghi
4,jkl
# Table2
A,C
1,abc
1,def
2,ghi
3,ghit
这很好用，因为表 1 中的 A 列包含唯一值并且可以用作主键。现在您可以转到 Report tab，设置两个 table，然后通过直接单击表 1 中的 A 下方，或通过引入切片器来根据您的心意进行切片和切块：
但问题是您可以在 没有 在 table 之间建立关系的情况下做到这一点。删除Relationships下的关系，回到Report和selectHome > Manage Relationships看看我的意思：
正如对话框所说'There are no relationships defined yet.'但是你可以仍然子集一个table通过在另一个中制造select离子就像以前一样（编辑： 这个说法在 RADO 的回答中被证明是错误的）。我 do 知道您可以突出显示切片器和 select Format > Edit Interactions 并删除 select 与切片器关联的 table。但是我还是对整个事情感到困惑。
所以这里是不是发生了一些我不知道的事情？或者 tables really 之间的关系是由 tables 的内容定义的 - 因为相关值的存在跨越 tables 具有潜在的主键（无论是自然的还是合成的）使得可以使用 SQL、dplyr 动词或任何其他形式的查询技术来查询它们。而且您真的不需要明确定义的关系？
或者换句话说，Power BI table 关系的建立是否具有 SQL 等价关系？也许像 the following:
CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
PRIMARY KEY (ID)
);
对不起，如果我在这里有点乱，但我只是 非常 困惑。到目前为止，谷歌搜索只会增加混乱。所以感谢您的任何见解！
您的陈述 "But you can still subset one table by making selections in the other just like before" 不 正确。这是这里的一个关键问题。
关系支持在 Power BI 中传播过滤器上下文。这是一个非常沉重的短语，如果您打算使用 Power BI，则必须了解它的含义。这是要理解的最重要的概念。
要理解我的意思，您需要编写 DAX 度量并尝试使用您的表来操作它们。当你有或没有关系时，你会立即看到差异。
整个系统的工作原理（简化）：
PowerBI 包含一种名为 "DAX" 的语言。您将在 DAX 中创建度量值，然后 PowerBI 会将它们翻译成名为 xmSQL 的内部语言，这是 SQL 的一种特殊风格。在xmSQL中，regular connection被翻译成LEFT OUTER JOIN，像这样：
SELECT SUM(Sales.Amount)
FROM Sales
LEFT OUTER JOIN Customer
ON Sales.Customer_Key = Customer.Customer_Key
双向关系有点复杂，但在概念上是相似的。
总的来说，当您在表之间创建关系时，您是在告诉 PowerBI 引擎如何连接表。然后引擎还添加了一些优化来加速查询。
每次执行 DAX 度量、单击切片器或视觉对象时，PowerBI 都会在后台生成多个 xmSQL 语句，执行它们，然后将它们的结果呈现为视觉对象。您可以使用 DAX Studio 等工具查看这些 SQL 查询。
请注意，在 PowerBI 中建立表之间的关系并不是绝对必要的。您可以使用 DAX（以编程方式）模仿相同的行为，但这样的 "virtual" 关系更加复杂并且速度可能会大大降低。
在 RM（关系模型）和 ERM（实体关系模型）中，tables 表示关系（ship）s/association。因此，"RM"中的关系和"ERM"中的关系。
FK（外键）在伪 ERM 方法中被错误地调用 "relationships"。 SQL FK 约束表示子行在别处显示为 PK（主键）或 UNIQUE。 DBMS 使用它们来禁止无效更新和优化查询。
Power BI "relationships" 不是 FK。它们是有关如何构建查询的说明。
当有 FK 时，我们确实经常想加入它。所以我们经常想要有FK的Power BI关系。
Create and manage relationships in Power BI Desktop
（另请参阅其为开发人员下载 PDF link。）
PS 我们不需要约束来持有或声明或已知查询。约束（包括 PK、FK、UNIQUE 和基数）由 table 含义--（特征）谓词--以及可能出现的业务情况决定。如果约束成立，那么我们有时会得到比其他情况下更少的行，并且一些查询对总是 return 相同的结果，否则它们不会。
Foreign keys are not needed to join tables!
Is there any rule of thumb to construct SQL query from a human-readable description?
PS 交叉连接是具有 TRUE 条件（或在某些 DBMS 中没有条件）的内部连接，句号。是否有 "relationship" aka FK 无关紧要。如果条件是 FK=PK 或除 TRUE 之外的任何其他条件，则它不是交叉连接；否则无论 table 之间是否存在 FK 都是交叉连接。只是我们经常希望 PK=FK 在一个条件下，工具可以并且确实将 FK 的存在用于默认条件。
CROSS JOIN vs INNER JOIN in SQL Server 2008
你问了"What is happening under the hood?"
简单的答案是“关于关系的陈述。”
许多善意的人绘制 ER 图，但似乎忘记或没有意识到他们的 ER 图实际上是 "pictures of statements in language."
问题是歧义。
许多善意的人直接跳到 ER 图，而没有表达他们的 ER 图所基于的逻辑语句。实际上，这意味着绘制 ER 图的人似乎期望 ER 图的 "reader" 能够重建绘制 ER 图的语句。
这里有一个例子来说明我的意思。我的目的是展示学生与其地址之间 "under the covers" 关系的语言基础。
所以，隐藏在背后的是语言！
一个简单的图表
导出图表的语句。
更复杂的图表
导出图表的语句。
这个问题不限于Power BI，但它会帮助我解释我的问题。
如果您在 Power BI 中有多个 table，您可以通过将一列从一个 table 拖动到另一个来建立它们之间的关系，如下所示：
您可以通过单击出现的行来编辑该关系：
顺便说一下，这是两个 table 的结构：
# Table1
A,B
1,abc
2,def
3,ghi
4,jkl
# Table2
A,C
1,abc
1,def
2,ghi
3,ghit
这很好用，因为表 1 中的 A 列包含唯一值并且可以用作主键。现在您可以转到 Report tab，设置两个 table，然后通过直接单击表 1 中的 A 下方，或通过引入切片器来根据您的心意进行切片和切块：
但问题是您可以在 没有 在 table 之间建立关系的情况下做到这一点。删除Relationships下的关系，回到Report和selectHome > Manage Relationships看看我的意思：
正如对话框所说'There are no relationships defined yet.'但是你可以仍然子集一个table通过在另一个中制造select离子就像以前一样（编辑： 这个说法在 RADO 的回答中被证明是错误的）。我 do 知道您可以突出显示切片器和 select Format > Edit Interactions 并删除 select 与切片器关联的 table。但是我还是对整个事情感到困惑。
所以这里是不是发生了一些我不知道的事情？或者 tables really 之间的关系是由 tables 的内容定义的 - 因为相关值的存在跨越 tables 具有潜在的主键（无论是自然的还是合成的）使得可以使用 SQL、dplyr 动词或任何其他形式的查询技术来查询它们。而且您真的不需要明确定义的关系？
或者换句话说，Power BI table 关系的建立是否具有 SQL 等价关系？也许像 the following:
CREATE TABLE Persons (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
PRIMARY KEY (ID)
);
对不起，如果我在这里有点乱，但我只是 非常 困惑。到目前为止，谷歌搜索只会增加混乱。所以感谢您的任何见解！
您的陈述 "But you can still subset one table by making selections in the other just like before" 不 正确。这是这里的一个关键问题。
关系支持在 Power BI 中传播过滤器上下文。这是一个非常沉重的短语，如果您打算使用 Power BI，则必须了解它的含义。这是要理解的最重要的概念。
要理解我的意思，您需要编写 DAX 度量并尝试使用您的表来操作它们。当你有或没有关系时，你会立即看到差异。
整个系统的工作原理（简化）： PowerBI 包含一种名为 "DAX" 的语言。您将在 DAX 中创建度量值，然后 PowerBI 会将它们翻译成名为 xmSQL 的内部语言，这是 SQL 的一种特殊风格。在xmSQL中，regular connection被翻译成LEFT OUTER JOIN，像这样：
SELECT SUM(Sales.Amount)
FROM Sales
LEFT OUTER JOIN Customer
ON Sales.Customer_Key = Customer.Customer_Key
双向关系有点复杂，但在概念上是相似的。
总的来说，当您在表之间创建关系时，您是在告诉 PowerBI 引擎如何连接表。然后引擎还添加了一些优化来加速查询。 每次执行 DAX 度量、单击切片器或视觉对象时，PowerBI 都会在后台生成多个 xmSQL 语句，执行它们，然后将它们的结果呈现为视觉对象。您可以使用 DAX Studio 等工具查看这些 SQL 查询。
请注意，在 PowerBI 中建立表之间的关系并不是绝对必要的。您可以使用 DAX（以编程方式）模仿相同的行为，但这样的 "virtual" 关系更加复杂并且速度可能会大大降低。
在 RM（关系模型）和 ERM（实体关系模型）中，tables 表示关系（ship）s/association。因此，"RM"中的关系和"ERM"中的关系。
FK（外键）在伪 ERM 方法中被错误地调用 "relationships"。 SQL FK 约束表示子行在别处显示为 PK（主键）或 UNIQUE。 DBMS 使用它们来禁止无效更新和优化查询。
Power BI "relationships" 不是 FK。它们是有关如何构建查询的说明。
当有 FK 时，我们确实经常想加入它。所以我们经常想要有FK的Power BI关系。
Create and manage relationships in Power BI Desktop
（另请参阅其为开发人员下载 PDF link。）
PS 我们不需要约束来持有或声明或已知查询。约束（包括 PK、FK、UNIQUE 和基数）由 table 含义--（特征）谓词--以及可能出现的业务情况决定。如果约束成立，那么我们有时会得到比其他情况下更少的行，并且一些查询对总是 return 相同的结果，否则它们不会。
Foreign keys are not needed to join tables!
Is there any rule of thumb to construct SQL query from a human-readable description?
PS 交叉连接是具有 TRUE 条件（或在某些 DBMS 中没有条件）的内部连接，句号。是否有 "relationship" aka FK 无关紧要。如果条件是 FK=PK 或除 TRUE 之外的任何其他条件，则它不是交叉连接；否则无论 table 之间是否存在 FK 都是交叉连接。只是我们经常希望 PK=FK 在一个条件下，工具可以并且确实将 FK 的存在用于默认条件。
CROSS JOIN vs INNER JOIN in SQL Server 2008
你问了"What is happening under the hood?" 简单的答案是“关于关系的陈述。”
许多善意的人绘制 ER 图，但似乎忘记或没有意识到他们的 ER 图实际上是 "pictures of statements in language."
问题是歧义。
许多善意的人直接跳到 ER 图，而没有表达他们的 ER 图所基于的逻辑语句。实际上，这意味着绘制 ER 图的人似乎期望 ER 图的 "reader" 能够重建绘制 ER 图的语句。
这里有一个例子来说明我的意思。我的目的是展示学生与其地址之间 "under the covers" 关系的语言基础。
所以，隐藏在背后的是语言！
一个简单的图表
导出图表的语句。
更复杂的图表
导出图表的语句。