当表之间建立关系时，幕后发生了什么？答案

【问题标题】：What is happening under the hood when a relationship is established between tables?当表之间建立关系时，幕后发生了什么？
【发布时间】：2019-03-22 12:15:36
【问题描述】：

这个问题不限于 Power BI，但它会帮助我解释我的问题。

如果您在 Power BI 中有多个表，则可以通过将列从一个表拖到另一个表来建立它们之间的关系，如下所示：

您可以通过单击出现的行来编辑该关系：

顺便说一下，这是两个表的结构：

# Table1
A,B
1,abc
2,def
3,ghi
4,jkl

# Table2
A,C
1,abc
1,def
2,ghi
3,ghit

这很好用，因为 Table1 中的 A 列包含唯一值并且可以用作主键。现在您可以前往Report tab，设置两个表，然后直接单击表 1 中的 A 下方或引入切片器，按照您的心愿进行切片和切块：

但问题是您可以在不建立表之间关系的情况下做到这一点。删除Relationships下的关系，回到Report，选择Home > Manage Relationships看看我的意思：

正如对话框所说的 'There are no relationships defined yet.' 但是您可以仍然像以前一样通过在另一个表中进行选择来对一个表进行子集化（编辑：该语句已被证明是错误的在 RADO 的回答中）。我确实知道您可以突出显示切片器并选择Format > Edit Interactions 并取消选择与切片器关联的表。但我仍然对整个事情感到困惑。

那么，这里是否发生了一些我不知道的事情？或者表之间的关系真的是由表的内容定义的 - 因为存在潜在主键（无论是自然的还是合成的）跨表的相关值的存在使得可以使用 SQL、dplyr 动词或任何其他形式的查询技术来查询它们。而且您真的不需要明确定义的关系吗？

或者换一种说法，Power BI表关系的建立是否有SQL等价物？或许像the following：

CREATE TABLE Persons (
    ID int NOT NULL,
    LastName varchar(255) NOT NULL,
    FirstName varchar(255),
    Age int,
    PRIMARY KEY (ID)
);

对不起，如果我在这里有点啰嗦，但我只是非常感到困惑。到目前为止，谷歌搜索只会增加混乱。因此，感谢您提供任何见解！

【问题讨论】：

定义外键关系。不过，我不知道 PowerBI 是否真的改变了底层数据模型。
@GordonLinoff 感谢您的反馈！我在这里感到困惑的是defining a foreign key relationship 周围的细节。为了在表之间执行任何类型的查询，您真的需要定义这样的关系吗？例如左连接？关系数据的存在本身还不够吗？
不，我不认为“表之间的关系真正由表的内容定义”。需要像您最初那样建立关系。我不知道 PowerBi，但它甚至可以运行“没有关系”的查询，即所谓的“交叉连接”。这些查询有时会派上用场（虽然对我来说并不经常），而且它们不需要外键。
您不需要指定 table1.col1 是引用 table2.col1 的外键来连接这些列上的两个表，不。外键让数据库强制执行一致性。例如，您不能在table1 中插入一个新行，其中col1 值在table2 的行中也不存在。
好问题，顺便说一句（不是一个愚蠢的问题）。也许有 PowerBi 经验的人可能会给你一个更好的答案。点赞。

标签： sql relational-database powerbi

【解决方案1】：

您的陈述“但是您仍然可以像以前一样通过在另一个表中进行选择来对一个表进行子集化”是不正确的。这是这里的一个关键问题。

关系支持在 Power BI 中传播过滤器上下文。这是一个非常重要的短语，如果您打算使用 Power BI，您将必须了解它的含义。这是要理解的最重要的概念。

要明白我的意思，您需要编写 DAX 度量并尝试使用您的表来操作它们。当您有或没有关系时，您会立即看到差异。

整个系统的工作原理（简化）： PowerBI 包含一种称为“DAX”的语言。您将在 DAX 中创建度量，然后 PowerBI 会将它们翻译成称为 xmSQL 的内部语言，这是一种特殊的 SQL。在 xmSQL 中，常规连接被翻译成 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（以编程方式）模仿相同的行为，但这种“虚拟”关系更复杂，而且速度可能会慢很多。

【讨论】：

顺便说一句，您在问题 cmets 中得到了很多不正确的建议。它们都非常适合关系模型/数据库，但与 PowerBI/维度模型无关。
不，切片器也不起作用...如果您仔细观察，您会发现结果未正确过滤。
做一个快速测试：对于表 2，创建一个度量：Total Count = COUNT(Table2[C])。现在将 Column [A] 从 table1 中删除到数据透视行上，并将度量值放入值中。如果您有适当的关系，您将看到 A 列剖析的计数： 2, 1, 1 。如果没有关系，您将看到所有行的相同数字 (4)。这意味着过滤没有发生。如果从 table1 创建切片器，它将过滤表行，但数量将保持不变 (4)。
部分问题是您使用“SQL”和“关系数据库”标签标记了您的问题，并且它们吸引了 SQL 和数据库方面的专家。相反，您需要的是维度建模、星型模式、幂 Bi、DAX、幂枢轴等方面的专家。这些是非常非常不同的东西。
是的。当您设置连接时，它会告诉 PowerBi 引擎要为您的 DAX 度量生成什么 xmSQL 查询。使用常规连接，它将生成左外连接。如果没有连接，它将简单地增加表（创建 Cortesian 连接）。双向连接应该转化为完全外连接（我认为），你应该避免后两者像瘟疫一样。

【解决方案2】：

在 RM（关系模型）和 ERM（实体关系模型）表中表示关系（船舶）/关联。因此，“RM”中的relational和“ERM”中的relationship。

FK（外键）在伪 ERM 方法中被错误地称为“关系”。 SQL FK 约束表示子行在其他地方显示为 PK（主键）或 UNIQUE。 DBMS 使用它们来禁止无效更新和优化查询。

Power BI“关系”不是 FK。它们是关于如何构建查询的说明。

当有 FK 时，我们确实经常想加入它。因此，当存在 FK 时，我们通常需要 Power BI 关系。

Create and manage relationships in Power BI Desktop
（另请参阅其下载 PDF 链接以供开发人员使用。）

PS 我们不需要约束来保持或声明或知道查询。约束（包括 PK、FK、UNIQUE 和基数）由表含义--（特征）谓词--以及可能出现的业务情况确定。如果约束成立，那么我们有时会得到比其他情况更少的行，并且某些查询对总是返回相同的结果，否则它们不会。

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 中没有条件）的内部联接，句号。是否存在“关系”又名 FK 是无关紧要的。如果条件是 FK=PK 或除 TRUE 以外的任何其他内容，则它不是交叉连接；否则无论表之间是否存在 FK 都是交叉连接。只是我们经常希望 PK=FK 在一个条件中，而工具可以并且确实将 FK 的存在用于默认条件。

CROSS JOIN vs INNER JOIN in SQL Server 2008

【讨论】：

【解决方案3】：

您问“幕后发生了什么？” 简单的答案是“关于关系的声明”。

许多善意的人绘制 ER 图，但似乎忘记或没有意识到他们的 ER 图实际上是“语言陈述的图片”。

问题在于模棱两可。

许多善意的人直接跳到 ER 图，而没有表达他们的 ER 图所基于的逻辑语句。实际上，这意味着绘制 ER 图的人似乎期望 ER 图的“读者”能够重建绘制 ER 图的语句。

这里有一个例子来说明我的意思。我的目的是展示学生和他们的地址之间“幕后”关系的语言基础。

那么，隐藏的就是语言！

一个简单的图表

从中派生出图表的语句。

更复杂的图表

从中派生出图表的语句。

【讨论】：