WPS表格的关键短板：缺少数据模型功能

一、引言

电子表格的功能定位已从数值计算工具扩展为数据处理平台。Microsoft Excel 借助数据模型（Data Model）功能建立了显著的技术壁垒。WPS 表格已引入超级表、多维表关联字段、内置 SQL 引擎和 Query 编辑器等能力，但缺少对等的数据模型功能。本文分析在社区已贡献多种数据库增强方案背景下，WPS 表格缺少原生数据模型这一核心缺陷的原因，并探讨补齐方向。

二、数据模型的含义

数据模型在关系型数据库、企业级 BI 等多个领域广泛使用，含义因上下文而异。在关系型数据库领域，数据模型指通过表、列、键等元素对业务实体及其关联关系的形式化描述；在企业级 BI 领域，还涵盖度量值、计算列、层次结构等分析语义。本文聚焦电子表格工作簿语境，将数据模型界定为嵌入工作簿内部、可持久化的关系型数据存储与关联管理机制，具备三项特征：

（1）多表关系定义与持久化存储。 用户可在工作簿内建立多张表之间的一对多关系，关系定义随工作簿保存，打开时自动加载。

（2）独立于工作表的存储引擎。 数据模型维护独立于工作表的数据副本，由专门引擎管理。SQLite 等嵌入式数据库可承担此角色，Excel 则选择 VertiPaq 列式引擎以获得更优分析性能。度量值、计算列、层次结构等分析语义可在数据模型之上进一步构建，但不属于数据模型本体。

（3）与原生组件的无缝集成。 透视表等原生组件可直接消费模型中的表和关系，自动应用关系进行聚合，形成"数据→模型→报表"的闭环。

三、Excel 数据模型的技术实现

Excel 的数据模型是一套由多个组件协同工作的技术栈，下文按从底层到上层的顺序依次介绍。

3.1 OLAP 协议与 SSAS 服务端

Excel Data Model 的技术根基来自 Microsoft OLAP 体系。OLAP 是面向多维数据分析的计算范式，将数据组织为多维数据集（Cube），通过维度实现聚合与切片分析。SQL Server Analysis Services（SSAS）是 Microsoft 实现 OLAP 的服务端平台，支持多维模型和表格模型（Tabular）两种模式。Excel Data Model 本质上是一个嵌入工作簿内部的 SSAS Tabular 实例，能以文件形式随工作簿分发。在 SSAS 的 DirectQuery 模式下，Data Model 可连接外部数据库将查询下推。

3.2 VertiPaq 列式存储引擎

作为 SSAS Tabular 的底层存储，VertiPaq（也称 xVelocity）采用列式架构：将每列唯一值构建为哈希字典，配合 Run-Length Encoding 压缩重复序列，内存占用通常降至原始大小的十分之一，查询时仅加载目标列。Microsoft 文档指出，借助该引擎可"创建包含数百万行的数据模型"。

3.3 DAX 分析语言

DAX（Data Analysis Expressions）是 SSAS Tabular 专用的公式语言，用于定义度量值、计算列和表级计算。与标准 SQL 不同，DAX 引入了筛选上下文（Filter Context）和行上下文（Row Context）两种计算环境，并提供 CALCULATE、FILTER、ALL 等函数在两者之间切换，使分析人员能在不同粒度间灵活定义聚合逻辑。

3.4 Power Pivot 管理界面

Power Pivot 是面向用户的数据模型管理入口，以独立窗口提供数据导入、关系定义和 DAX 编写。用户通过"关系图视图"管理多表关联，支持一对多和通过桥接表实现的多对多关系。根据 Microsoft Learn 文档，Data Model 允许用户"在同一工作簿内整合多张数据表，建立表间关系，形成关系型数据源"，使工作簿从单表容器升级为轻量级数据库。

3.5 Cube 函数族

Excel 提供 7 个 Cube 函数（CUBEVALUE、CUBEMEMBER、CUBESET、CUBEMEMBERPROPERTY、CUBESETCOUNT、CUBEKPIMEMBER、CUBERANKEDMEMBER），通过 OLAP 连接从 Data Model 读取聚合数据。CUBEVALUE 接收一个 OLAP 连接参数和若干维度成员表达式，返回指定维度组合下的聚合值。与透视表的拖拽交互不同，Cube 函数提供可编程式的模型消费方式，使工作表能精确访问特定数据切片。

3.6 MDX 查询语言

3.5 节提到 Cube 函数通过 OLAP 连接访问 Data Model，该连接在底层依赖 MDX（Multidimensional Expressions）查询语言。MDX 是专为 OLAP 系统设计的查询语言，基于 XML for Analysis（XMLA）规范。与 SQL 的核心差异在于：SQL 面向二维表返回行集，MDX 面向多维空间，在 SELECT 子句中定义多个查询轴返回元组集合。

在 Excel Data Model 中，MDX 的角色体现在两方面。第一，Cube 函数的调用在底层转化为 MDX 查询发送给 SSAS 引擎执行——例如 CUBEVALUE("连接","[产品].[类别].[电子]","[时间].[年].[2024]") 对应一条从产品和时间维度交叉位置取值的 MDX 查询。第二，外部 OLAP 工具可通过 MDX 连接 Data Model 进行更复杂的多维分析。SSAS Tabular 以 DAX 为原生分析语言，MDX 通过映射层兼容访问。

四、WPS 表格现有的数据库相关能力

对照第二节定义的三项特征，WPS 表格已引入若干数据库相关能力，但均未完整实现数据模型。

4.1 超级表 ListObject

超级表是 WPS 表格的结构化数据管理基础，支持列标题筛选、动态区域扩展和结构化引用等功能。但超级表的能力范围限于单表：不涉及表间关系定义，数据仍存储在单元格网格中，其存储和消费也完全依托工作表对象。对照三项特征：超级表未触及特征（1）和特征（2）；特征（3）方面，透视表已可消费超级表生成聚合报表，但因缺少表间关系，无法跨表聚合。

4.2 多维表关联字段

多维表格（DbSheet）已支持同一文档内不同数据表之间的关联字段，可定义表间引用关系并实现跨表数据查找。对照三项特征：多维表在特征（1）方面初步实现了多表关系管理，但关联仅作用于云端多维表格文档，本地工作簿中的超级表尚不支持跨表关系，且关联为 UI 层面的查找引用而非数据库级别的级联约束，对象范围和约束完整性均有欠缺。特征（2）和特征（3）方面，多维表的数据仍依托工作表单元格存储，其关联字段也无法被透视表等原生组件引用。

4.3 内置 SQL 引擎与 Query 编辑器

WPS 表格内置的 SQL 引擎支持以 SQL 语句查询工作表数据，Query 编辑器提供可视化的数据导入与转换管道。这些能力为数据接入和查询处理提供了基础。对照三项特征：SQL 引擎和 Query 编辑器不触及特征（1）和特征（3）；特征（2）方面，SQL 引擎可作为未来数据接入层的前端，但查询产出最终回写为工作表数据，缺少独立的模型存储载体，因此亦未实现特征（2）。

五、社区增强方案及其能力边界

上述方案无法替代原生数据模型。下文从两个维度分析原因。

5.1 持久化维度：模型定义无法随工作簿保存

数据模型的核心价值在于"一次定义，反复使用"。在 Excel 中，表间关系作为工作簿文件的一部分持久化——打开即加载，关闭即保存，后续所有报表和分析会话可直接消费。

社区方案在这一维度存在根本性缺陷。以 WPS.DuckDB 为例，查询由 DuckDB 在内存中执行，工作簿关闭后内存实例销毁，再次打开需重新加载数据和定义关系。工作簿文件本身不存储表定义和关系定义，这些信息仅存在于运行时。ODBC + DuckDB 更为突出：数据存储在外部文件中，与工作簿完全分离。差距的本质在于：数据模型要求工作簿成为模型定义的载体，而社区方案中工作簿仅是查询结果的输出目标，二者在可复用性和可维护性上存在根本区别。

5.2 集成维度：无法与原生组件形成闭环

数据模型的第三项核心特征是与原生组件无缝集成。在 Excel 中，透视表和 Cube 函数均可直接消费 Data Model 中的表间关系，形成完整闭环。社区方案存在结构性障碍：WPS.DuckDB 的查询结果回写到单元格，产出物是静态数据值，而非持久驻留在工作簿中、可被透视表持续消费的模型实例。用户无法基于 DuckDB 结果直接创建关联透视表——需先写入工作表再创建，这一过程丢失了模型中的关系信息。社区方案与原生数据模型的集成差距在于：数据模型是持久驻留的数据服务层，可被多个原生组件并行消费；社区方案的查询结果是单次产出，不具备持久驻留和被持续消费的能力。

六、WPS 补齐数据模型能力的可行路径

以下路径均以开源技术为基础，不依赖 Microsoft 专有生态，具备自主可控性。

6.1 以嵌入式数据库为内核构建持久化数据模型

在工作簿文件内嵌入轻量级关系型数据库实例（如 SQLite 或 DuckDB）用于持久化保存表定义和关系定义。SQLite 是行式数据库，完全可以承担数据模型的存储和关系管理职责；DuckDB 额外提供列式分析性能，WPS.DuckDB 加载项已验证了 DuckDB 在 WPS 环境中的嵌入可行性。需在工作簿文件格式中定义专用存储区域，打开时加载、关闭时写回，使表定义和关系定义随工作簿保存。当前 WPS.DuckDB 已具备 DuckDB 嵌入能力，需增加模型定义的序列化层，将内存级表注册改造为文件级持久化操作。

6.2 在超级表基础上扩展持久化关系管理

多维表关联字段已验证用户对表间引用的需求。下一步可将此能力从云端多维表格扩展到本地超级表——在 WPS 表格的对象模型中为超级表增加关系元数据属性（外键列引用、基数类型、级联行为），并随文件序列化保存，打开工作簿时自动恢复多表关联状态。

6.3 建立统一的模型消费接口

透视表组件需增加连接嵌入式数据模型的入口，使其能直接识别表间关系。可在透视表的创建向导中增加"连接数据模型"选项，透视表引擎从嵌入式数据库读取表结构和关系元数据，自动生成 JOIN 逻辑，用户拖拽字段即可完成交叉分析。同一模型实例应能被多个透视表并行消费，实现"数据→模型→报表"的完整链路。

七、结语

前文分析表明，数据模型的缺失并非 WPS 表格在单项能力上的不足，而是在持久化和集成两个架构维度上的系统性缺口。社区增强方案从查询能力层面提供了补充，但由于插件架构无法触及工作簿文件的存储层和原生组件的对象模型，这一缺口无法通过外部方案弥补。

值得关注的是，WPS 补齐数据模型能力具备有利条件。WPS.DuckDB 已验证 DuckDB 在 WPS 环境中的嵌入可行性，多维表关联字段已积累表间关系的 UI 交互经验，Query 编辑器已具备数据导入与转换的管道能力。这三项现有能力恰好分别对应数据模型所需的存储引擎、关系管理和数据接入三个环节，构成了从"数据处理管道"向"嵌入式数据模型"升级的技术基础。