导言

在BI系统中，分析语言的核心价值之一，在于赋予分析师自主构建计算逻辑的灵活性，使其无需依赖IT部门进行前置的数据预处理。这一特性体现在两个关键层面：

其一，数据表之间的柔性建模：底层数据关联是分析自由的基石。分析师需要能灵活将底层数据表间进行关联（即数据建模能力），否则就只能依赖IT进行前置的宽表构建。

其二，业务指标的计算逻辑表达：分析师可直接在前端定义维度和度量的计算规则，如"客单价=销售额/订单数"等核心指标，无需等待IT部门进行预聚合计算。

而在实际分析流程中，前者是更基础的工作，即先做好数据建模，在模型基础上再做上层指标定义和可视化。在HENGSHI SENSE中亦是如此，要掌握HQL，先了解数据模型。

本期HQL专题，我们将深入解析衡石数据模型能力及其应用场景，揭示如何通过底层数据建模提升分析效率，并探讨其在复杂业务场景中的落地实践。

逐渐普及的【数据模型】功能

在数据分析领域，数据模型一般是指一组结构化数据表及其关系的系统性描述。而数据建模，就是在若干数据表之间，建立确定的连接关系。

早期BI产品中，仅有少数工具，如PowerBI，具备独立的数据建模模块，其Model-Based架构被视为与Tableau等Report-Based工具的核心差异。但近年来，不少BI厂商纷纷开始“集体补课”，加码建模能力的建设：2020 年 Tableau 上线 Relationship 模块，2023 年国内FineBI推出主题模型，永洪也于 2024 年发布的 10.2 版本新增 “数据模型” 功能。

在上述建模功能上线之前，Tableau、FineBI、永洪等产品也允许通过“关联数据集”等方式将多个表关联为一个宽表视图。对于 BI 新手而言，“关联数据集” 与 “数据模型” 的概念极易混淆。事实上，从广义角度来看，早期众多 BI 产品构建逻辑宽表或关联数据集的功能，本质上也属于数据建模范畴，核心都在于定义表间的关联关系。

那么，各大厂商为何仍然争相推出 “数据模型” 功能？这两个产品概念又存在何种本质差异？答案在于数据模型为建模工作带来了更高的复用性与灵活性，能够显著提升数据处理效率与应用场景适配能力。

衡石早在2019年推出的HENGSHI SENSE 2.4版本中就加入了数据模型功能（比Tableau还要早一年）。接下来，我们将通过具体业务案例，剖析数据模型与关联数据集在实际应用中的差异。

按需关联：建模的可复用性

在实际业务分析中，数据表间的关联关系具备显著稳定性。多数场景下，表与表之间通过特定字段、固定方式建立连接，这种关联关系的稳定性，为数据建模提供了复用基础。复用意味着无需重复构建相同的关联逻辑，大幅提升数据处理效率。

然而，业务分析场景的多样性又对复用提出新要求。不同分析任务往往只需调用数据模型中的部分表，这决定了建模复用必须具备局部性，能够灵活适配差异化的业务需求。

衡石的数据模型通过按需关联功能，精准满足了局部复用需求。该功能允许用户根据实际分析场景，选择性调用模型中的部分表及其关联关系，避免冗余数据处理。这种灵活的局部复用特性，正是数据模型区别于关联数据集的核心优势之一 —— 关联数据集通常基于固定组合，难以实现局部调用与动态调整。以下是一个典型场景。

需求背景：

底层数据库中存在【零售数据】明细事实表，及【商品维度】【店仓维度】【顾客资料】等多个维度表。

需要在某个 dashboard 中新增两个折线图：基于商品维度的【品牌销售额趋势】、基于店仓维度的【店仓销量趋势】。

需求分析：

此为典型的 “单事实表 + 多维度表” 星型模型场景。

若采用关联数据集功能，一般有两种处理方式：

方式一：分别建多个宽表。先关联【零售数据】与【商品维度】生成宽表，用于品牌趋势图；再关联【零售数据】与【店仓维度】生成另一宽表，用于店仓销量趋势图。缺陷：建模工作无法复用，后续新增商品+顾客维度分析时，需重复构建【零售数据】+ 【商品维度】+【顾客资料】宽表，冗余工作量大。

方式二：构建包含事实表与所有维度表的大宽表。缺陷：计算冗余且性能差。即使仅需【零售数据】与【商品维度】的字段，仍需完成所有表的关联计算，显著拖慢查询效率。

数据模型解法：

在衡石数据模型功能中，以【零售数据】为主表，拉入所有相关维表构建星型模型，为每个维表的关联关系设置【生效机制】为 “按需关联”。即可实现 “一模型适配多场景”：

· 生成【品牌销售额趋势】时，仅激活【零售数据】与【商品维度】的子模型关联；

生成【店仓销量趋势】时，仅激活【零售数据】与【店仓维度】的子模型关联。

既避免重复建模工作，又消除冗余计算，提升查询性能。

进一步地，这种局部可复用性，也让建模工作和可视化分析工作得以更好地解耦，更利于分析团队之间的分工与协作：建模人员无需关心上层有哪些分析场景，只需要尽可能全地将所有通用的稳定关系建立起来；分析人员只需要引用一个完整模型即可。

关联基数：关联计算的灵活性

上面的例子，用关联数据集构建大宽表虽然牺牲了性能，但也能勉强实现类似数据模型的效果。而在部分业务场景下，数据表因关联字段重复等问题，必须在关联前进行额外处理，这类场景是关联数据集无法直接应对的。考虑以下案例：

底层数据包含两张表：

【公司信息表】：记录各公司名称及员工数，公司字段无重复；

【签约记录表】：记录各周期内公司签约数，同一公司存在多条记录。

需生成一张报表，关联展示公司人数与签约数，为后续计算人均签约等指标提供基础。

若直接将两表做成关联数据集以构建逻辑宽表，因【签约记录表】存在重复记录，必然导致【公司信息表】记录膨胀。此时在关联数据集上直接汇总 “公司人数”，会因数据冗余产生统计失真。

用关联数据集方式，正确做法需先按公司维度对【签约记录表】去重汇总，再用汇总表与【公司信息表】构建关联数据集，操作明显繁琐。

在衡石数据模型中，可直接建立【公司信息表】与【签约记录表】的连接，仅需将 “关联基数” 设为 1 对多（公司信息表为 1，签约记录表为多），即可避免关联导致的数据膨胀与统计失真，解法简洁高效。

注：模型中的关联基数用于定义两表关联字段的对应关系，直接影响上层统计分析的计算逻辑，常见类型包括一对一（1:1）、一对多（1:N）、多对一（N:1）、多对多（M:N）。

具体而言，两表 A 和 B 在数据模型中的计算逻辑因基数选择不同而有显著差异：

选择一对一基数时，计算方式与关联数据集基本一致，即直接执行表 A 与表 B 的关联（表 A join 表 B）；

选择一对多基数时，会针对不同指标灵活处理：A 表指标在关联前完成统计，B 表指标先做临时关联后统计，最终将两类统计结果再次关联展示，从根源上避免数据膨胀的影响。

环形模型：更复杂灵活地建模能力

当然以上所述的“按需关联”、“关联基数”等功能，应该视为BI产品建模能力的标配。衡石作为国内BI公司中在数据模型方面的先行者，依然在进行快速迭代 —— 最新发布的 6.0 版本支持环形模型便是其中之一（多数 BI 产品仍强制要求建模节点关系不能有环），这一功能将有效解决多事实表、多维度表场景下的建模难题。我们来看以下具体场景：

底层数据包含两张事实表，【零售数据】和【销存数据】，分别记录销售记录和库存记录，同时有多张维度表，其中部分维度表是两个事实表共享的。

如【店仓维度】和【商品维度】

需要构建分析图表，从商品维度展示销售额和库存相关的指标，同时能按按日期、门店进行筛选。

需求分析与解法：

该场景在数据建模时，首先需要将【零售数据】和【销存数据】两个事实表，分别跟【商品维度】建立关系，以便基于商品维度同时展示销售额和库存数据。同时，【零售数据】和【销存数据】还需要分别跟【店仓维度】建立关系，这样门店筛选器才能作用到相应事实表的数据过滤中。此时，整个模型关系必然形成 “环”。

对于不支持环形模型的 BI 产品，这类场景根本无法直接建模，只能依赖底层额外处理构建计算视图，流程冗余且低效。

而在 HENGSHI SENSE 6.0 中，直接拖拽构建环形模型即可满足需求，无需额外数据处理，简洁高效。

在衡石 HQL 体系中，数据模型是根基。它直接赋予用户高效整合、关联数据的核心能力——随时随地将分析所需要的数据串连起来，而没有冗余计算。基于数据模型功能，用户得以灵活地进行跨表的虚拟字段和指标定义，以及可视化创作，为HQL后续的各种应用场景，提供了更加广阔的分析自由度。