自 Tableau 2024.2 发布已过去近两周时间了，相信大多数小伙伴已经升级到最新版本，并探索过 Viz Extensions 等诸多新功能的奥妙。

但对于没有数据建模基础的用户来说，怎么理解和使用“多事实关系”（也称为共享维度）功能，依然是一项颇有难度的挑战。

其实，早在 TC24 大会的主题分享中，Kirk Munroe 与 Thomas Nhan（Tableau 众多数据模型功能的首席产品经理）就已围绕“新的 Tableau 数据模型和多事实分析”进行了介绍和演示。

图示：Kirk Munroe 是编写了工具书《Data Modeling with Tableau》的作者，书中详细描述了 Tableau Prep Builder 和 Tableau Desktop 在数据建模中各自扮演的角色，同时也探讨了 Tableau Server 和 Cloud 中如何通过其组件让数据建模更加稳健、安全和高效。

今天，就让我们跟随 Kirk 看看 Tableau 数据模型功能的变迁史，以及如何从底层逻辑上深入理解“多事实关系”的运作方式和使用场景吧~

图片

回顾 Tableau 数据模型的发展历程

Kirk 认为对于 Tableau 乃至是整个 BI 行业来说：“多事实关系”可能是自 2005 年 Tableau 首次面世以来最重大的 BI 功能之一，多事实分析只是这项功能所支持的一种用例而已。

事实上，“多事实关系” 这个说法还不足以概括这项功能的强大之处，更准确的描述应该是“共享多个逻辑表之间的关系”，但这个说法听起来有些拗口。所以，我们可以简单地将这个新功能视为“关系的 2.0 版本”。

值得一提的是，TC24 大会上产品团队还宣布了计划在今年晚点推出“可组合的数据源”功能。这项功能将首次支持用户从自己的数据表创建与已发布数据源的关系。所以 Kirk 认为这可称作是“关系的 2.1 版本”，因为它需要多事实关系作为先决条件。

在深入探讨“多事实关系”之前，让我们快速回顾一下 Tableau 的数据建模历程。

在 Tableau 2020.2 版本发布之前，用户在 Tableau Desktop 中进行数据建模的唯一选择是：连接到单个表或通过物理表连接来创建数据模型。

Tableau 自带的 “Superstore” 示例数据源最初就是一个简单的逻辑表，直到最近才添加了退货表和人员表相关的关系。

在现实世界中，数据工程团队可能会创建大型的单个表或视图，以便在 Tableau 中进行分析。如果没有数据工程团队参与，数据模型很可能会像下图这样：

这类独立数据表形式的建模方式非常受限。它既会使数据变得“冗余”，又会限制你能从数据中获取洞察力。

01、数据冗余（Explodes the Data）

Kirk 所说的“数据冗余”是什么意思？首先，衡量 Tableau 可以处理的数据量并不是单纯的认为：Tableau 能处理多少行数据？它实际上是行数和列数（以及这些列的大小）的函数。

为了方便理解，我们假设所有列的长度都相同，并将数据表想象成一个大型的电子表格，然后计算单元格的总数。来看一个示例，其中包含了 5 张独立的表：

当我们使用（内部）联接这些表时，单元格数量可以通过将所有表的列数相加，然后乘以最长表格的行数来计算。在本例中，我们得到 27 列 * 9,994 行 = 269,838 个单元格。

试想一下，如果订单表和订单明细表来自像亚马逊或 Shopify 这样的企业，这意味着他们每天需要处理数百万或数十亿的交易！

需要注意的是，并不是所有情况下数据都会变得冗余。例如，在某些实时连接以及使用“物理表”设置的提取数据中，数据就不会出现冗余。无论如何，查询结果都会表现得像来自单个表一样，因此即使从磁盘空间的角度来看并非完全如此，但这种思考方式仍然适用。

02、限制范围（Limited Questions）

除了数据冗余之外，这种独立数据表形式的建模方式还会限制用户所能提出的分析问题。内部联接会将没有匹配项的数据进行过滤，因此像“有哪些产品没有卖出？”这样的相关问题就无法得到解答，因为这些产品已经被过滤出数据之外了。

我们可以通过将所有联接都改成“完全外部联接”来解决这个问题，但这会导致更大的问题。数据量可能会介于列数相加与行数相乘之和，以及内部联接后的数值之间。

在本例中，这表示最终的单元格数量会在 269,838 和 494,424 之间，具体取决于匹配情况。更重要的是，你的数据中会出现大量空值（NULL），这可能会导致性能问题，并有可能在分析过程中让报表用户得出错误的结论。

然而，Tableau 的“关系”功能彻底改变了这一局面：

使用“关系”功能后，每个表都独立存储，Tableau 会在运行时根据每个工作表动态地组合查询。这意味着 Tableau 可以保持每个表的原始状态，且由于联接不是提前创建的，因此可以回答任何问题！

这样一来，我们只需要处理 114,512 个单元格，并能获得所有想要的答案！

“多事实关系”能够解决哪些问题？

了解完数据建模的历史后，我们再来探讨为什么新推出的“多事实关系”功能可能会成为近 20 年来分析和商业智能领域最重要的功能之一。

需要说明的是，Tableau 的“关系”功能虽然能防止数据冗余，并回答来自同一业务领域的各种问题，但它无法解决跨不同领域的数据分析问题。

示例：探索客户支持工单和订单的关系

接下来，还是以“Superstore”数据源为例。假设我们想要了解工单和订单之间的关系。工单表可能如下图所示：

那么，如何将这个表添加到数据模型中呢？我们可以创建工单表与客户表之间的关系，但按产品来分析工单呢？如何比较订单日期和工单记录日期？

实际上，我们真正想做的是在工单、客户、产品和日期表之间创建关系。想象一下，如果能够展示工单与销售额如何随时间变化，以及按客户和产品分类的关系，这将能为企业带来多大的价值！

为了在当今环境下提供不同业务领域的的信息，企业需要使用不同的数据源，并从以下几种方法中选择解决方案：

在可视化上进行对比

通过筛选操作从一个工作簿钻取到另一个工作簿

使用数据混合技术进行分析，但只能在单个聚合级别进行

Kirk 的观点是，仪表板之所以没有被充分利用，原因有二。一是因为它们回答了大家已经知道的问题；二是提供跨不同业务领域的的信息，但这些信息之间没有任何关联（例如，那些包含大量 KPI 指标和迷你图的传统仪表板）。

那么，“多事实关系”与之前的功能有何不同，它如何支持跨领域分析？

多事实关系功能引入了“基础表”的概念，这意味着我们可以将工单表与订单表放在同一个层级。然后，无论这张表是否跟其他表关联过，都可以创建与其他逻辑非基表的关系！

同时，你可能会注意到不必将每个基础表都与下游相同的表进行联接。这使得我们能够创建与单个表、多个表或所有表的关联关系。并且，当悬停在任意表上时，它会高亮显示与其关联的表，未关联的表则会变成灰色。

因此，我们可以回答一些更深层次的问题，并识别以前无法发现的相关性。比如回答“在每款产品中，接到最多客户咨询电话的产品销售额占产品总销售额的百分比是多少？”，然后得到了后续问题“如何通过情绪和态度来分类查看客户咨询工单及相关产品的销售额？”

现在，我们可以基于”多事实关系”联接后的所有表数据来回答这些问题。比如，可以从“订单明细”表获取订单量，从“工单”表获取 case 数量，然后在计算中将它们连接起来：

通过将数据进行可视化并按子类别进行细分，我们就可以看到哪些产品产生的支持工单最多 （按销售额加权计算）。由于这两个表都与“产品”表相关，因此 Tableau 可以实时生成查询。

我们还可以更进一步，将通话的情绪信息添加到视图中（以颜色分类），即便这些信息本身并不直接与产品相关。

加入共享的日期维度

如果我们继续扩展数据模型，添加额外的基础表，创建与维度表之间的关系，并将所有基础表连接到一个共享的日期维度，那么就能回答更加深入的问题。

现在，由于所有数据都与单个日期字段对齐，我们还可以对所有包含日期维度的表中的数据进行趋势分析，并根据任何共享表中的维度进行细分。

在这个示例中，假设我们想要按月查看库存与销售额之间的对比，并将表与所有其他类别进行比较。首先，可以看到库存数据并非每天都存在记录，而销售交易则可能一天发生多次。

如果按照日期表中的共同日期对它们进行排序，那么就可以在月度级别比较库存和销售额。

我们还可以继续添加其他的指标（例如工单和退货），然后根据任何其他相关表中的维度进一步细分数据。

多事实关系功能带来的另一种可能性是引入与日期无关的指标。比如，大家有时候会突发奇想：天气是否会影响销售额呢？要解答这个问题，现在就变得轻而易举了。如果我们引入一个天气表，就能了解它是否会对其他指标产生影响。说不定，下雨天客户咨询电话也会增加呢~

结语：多事实关系助力企业全局洞察

如上所述，多事实关系功能从根本上改变我们思考 Tableau 数据源的方式，并且大大加快了分析速度。

一般来说，数据工程团队需要将众多表组合成更少的表（或大宽表）并通过“非规范化的过程”让数据能够被用于分析。这是一个非常费时费力的过程，且必须在分析师或业务用户开始使用 Tableau 之前完成。

但如今，只要你拥有干净的数据，就可在 Tableau 中直接从不同的存储位置获取各种业务数据表的快照，并保留数据表的“原样”进行建模和分析，非常给力！