临时关系匹配在 BI 分析中的作用及工具实现

XILEJUN

喜乐君 Tableau Visionary ✦ 5

📊 业务数据分析「专家」· 敏捷 BI 布道师

📚 《数据可视化分析》《业务可视化分析》多本书作者

🎓 中国地质大学（武汉）经管学院 MBA 校外导师

🤝 以 Tableau 会友，致力于构建业务分析通识框架

🌐 XILEJUN.com 全球 🌐 VIZWISE.cn 国内

2025-07-24

在商业智能（BI）分析中，临时关系匹配（Temporary Relationship Matching）允许分析师根据可视化需求动态关联数据源，而无需修改底层数据模型。本文以一个销售分析场景为例，系统探讨临时关系匹配的作用，并比较 Tableau、Power BI 和 SQL 的实现方式。样例数据包括两个表：

• 销售明细表（Sales_Details）：字段包括 Category（类别）、Segment（细分）、Order_Date（订单日期）、Order_ID（订单 ID）、Product_ID（商品 ID）、Sales_Quantity（销售数量）、Unit_Price（单价）。
• 销售目标表（Sales_Targets）：字段包括 Category（类别）、Segment（细分）、Order_Date（订单日期）、Sales_Target（销售目标值）。

目标：分析实际销售额与目标值的对比，基于 Category、Segment 和 Order_Date 进行关联。

1. 临时关系匹配的核心作用

临时关系匹配通过动态关联数据源支持灵活的分析需求。以下是其关键作用及案例说明：

• 支持快速探索性分析：无需预定义数据模型，快速验证假设。
• 适配多源数据：桥接异构数据源（如 Excel 和数据库），减少 ETL 工作量。
• 降低技术门槛：自动匹配字段（如名称和类型相同的字段），便于非技术用户操作。
• 保持数据模型简洁：避免为临时需求修改主模型。
• 提升分析灵活性：支持动态调整关系以适配不同场景。

如果用 Excel 场景来理解，就是领导临时要求做两个“透视表”（分组聚合），而后把它们用 vlookup 关联起来再计算比率！熟悉 Excel 的表哥表姐都知道，Excel 不支持把两个透视表高效地关联起来，因为每个透视表都是随时变化的逻辑表，这里需要3个匹配条件，如图4-6所示。

图4-6  使用Excel数据透视表理解数据混合的逻辑

为了构建表4-1所示的虚拟中间表，表哥表姐只能转向更高级的工具——要么在 SQL 或Power Query 中预先聚合，将逻辑透视表转化为物理表，要么在 PowerBI 中构建关系模型。

表4-1  两个透视表左右连接后的虚拟中间表（省略）

这就是Excel自身的局限性。在小数据时代，它优秀到几十年不倒，至今仍广泛被世人使用；在大数据面前，它开始显示了老态龙钟的脆弱模样。因此，Power Query、Power Pivot等工具快速成长起来，并最终成为Power BI的一部分，它们逐渐抛弃面向“单元格”的编辑，转向关系型数据结构和模型、聚合分析。Excel透视表的本质是“聚合表”。基于聚合表的合并，以及建立在合并之后的敏捷业务分析，是大数据分析工具的基本功能。

2. 主流工具的实现方式

2.1 Tableau：Data Blending

Tableau 的 Data Blending 允许在可视化层动态关联数据源，类似 SQL 的 Natural Join。

• 工作机制：
  • 自动基于同名字段（如 Category、Segment、Order_Date）匹配。
  • 用户可手动编辑关系，指定连接类型（如左连接）。
  • 主数据源（Sales_Details）驱动查询，次数据源（Sales_Targets）动态聚合。
• 优势：
  • 简单易用，适合非技术用户。
  • 支持跨源混合（如数据库和 Excel）。
  • 动态调整关系无需修改模型。
• 局限性：
  • 性能受数据源聚合能力限制。
  • 不支持复杂非等值连接。
• 适用场景：快速跨源数据探索。

案例：在 Tableau 中，将销售明细表设为主数据源，销售目标表为次数据源，基于 Category 和 Order_Date 混合，生成柱状图对比实际销售额和目标值。

附图：

3.2 Power BI：USERELATIONSHIP

Power BI 的 USERELATIONSHIP 函数允许在 DAX 计算中动态激活非默认关系。

• 工作机制：
  • 在数据模型中预定义关系（如 Category 和 Order_Date 的关联）。
  • 使用 USERELATIONSHIP 在度量值中指定临时关系。
  • 常用于动态切换关系逻辑。

在 PowerBI 中，两个表之间的关系可以设置多个匹配条件，其中只有一个是“默认生效关系”（ active relationship），由于用实线表示因此也简称“实线关系”，除此之外可以有多个“默认不生效关系”（inactive relationship）,简称“虚线关系”。

如图9- 所示，数据表 Flight 和 Airport 预设了两个关系，其中“默认生效关系”是Sales.Date = Date.Date，预先匹配而“默认不生效关系”是Sales.ShipDate = Date.Date。在视图中，度量值的聚合以默认生效的条件完成数据合并，而使用 USERELATIONSHIP 函数的度量值则以临时指定的方式完成数据表合并，然后完成分组聚合。

• 优势：
  • 支持复杂关系逻辑。
  • 与 DAX 计算能力结合，适合高级分析。
• 局限性：
  • 需了解 DAX，技术门槛较高。
  • 依赖预定义关系。
• 适用场景：复杂模型分析。

虽然上述的“虚线关系”在PowerBI 数据模型阶段构建，但是它的生效依赖于视图阶段USERELATIONSHIP 函数的指定，所以说虚线关系依然属于临时关系。这就好比此前的“视图 View”，虽然它可以在数据仓库中预先构建且不运行，但是对于分析而言，它事实上的性质依然等同于已经物化的物理表——区别仅在于物化的时间而已。

为了帮助大家理解，笔者把 USERELATIONSHIP 称之为“临时关系表达式”。

与 USERELATIONSHIP 临时关系表达式相对应的是 RELATED 表达式，它的语法如下所示：

--  RELATED is needed to access columns of the expanded table
DEFINE

    MEASURE Sales[Sales Amount] =

        SUMX ( Sales, Sales[Quantity] * Sales[Net Price] )

    MEASURE Sales[Sales at List Price] =

        SUMX ( Sales, Sales[Quantity] * RELATED ( 'Product'[List Price] ) )

EVALUATE

SUMMARIZECOLUMNS (

    'Date'[Calendar Year],

    "Sales Amount", [Sales Amount],

    "Sales at List Price", [Sales at List Price]
)

有人误以为RELATED 也是“虚拟关系”，其实是是对关系模型的误解。

RELATED 基于预先设定好的关系模型，其查询的匹配条件是确定的、与问题无关的、客观的，因此是更应该视为“物理关系”的引用。相比之下，USERELATIONSHIP 表达式根据问题分析的需要临时选择匹配条件，才是真正的“逻辑关系。

3.3 SQL：Natural Join 与动态查询

SQL 通过 NATURAL JOIN 或动态查询实现临时关系匹配。

• 【SQL】数据混合的灵感来源：SQL NATURAL JOIN 详解 2025/7

• 工作机制：
  • NATURAL JOIN 基于同名字段（如 Category、Segment、 jusOrder_Date）自动匹配。
  • 动态 SQL 或临时视图支持运行时关系构建。
  • 数据库引擎优化查询执行。
• 优势：
  • 支持复杂连接，性能优异。
  • 适合大规模数据处理。
• 局限性：
  • 需编写 SQL 代码，技术门槛高。
  • 不适合快速可视化。

案例：使用 SQL 查询销售明细表和销售目标表，基于 Category 和 Order_Date 关联，计算销售额与目标的差距。

实现方法：

SELECT 
    d.Category,
    d.Order_Date,
    SUM(d.Sales_Quantity * d.Unit_Price) AS Actual_Sales,
    t.Sales_Target,
    SUM(d.Sales_Quantity * d.Unit_Price) - t.Sales_Target AS Sales_Gap
FROM Sales_Details d
NATURAL LEFT JOIN Sales_Targets t
GROUP BY d.Category, d.Order_Date, t.Sales_Target;

附图：

4. 工具对比与选择建议

选择建议：

• 快速探索：Tableau 的 Data Blending 适合快速可视化。
• 复杂分析：Power BI 的 USERELATIONSHIP 适合需要深度计算的场景。
• 高性能定制：SQL 适合大规模数据处理。

案例：对于销售数据，若需快速生成仪表板，Tableau 是首选；若需复杂计算（如动态切换关系），Power BI 更适合；若需批量处理，SQL 是最佳选择。

结论

临时关系匹配通过动态关联数据源提升 BI 分析的灵活性和效率。在销售分析场景中，Tableau 的 Data Blending 适合快速可视化，Power BI 的 USERELATIONSHIP 适合复杂计算，SQL 适合高性能处理。结合具体案例和最佳实践，分析师可根据需求选择合适的工具，高效实现数据洞察。