WPS表格的关键短板：缺少数据模型功能
Lv.2潜力创作者
一、引言
Microsoft Excel 借助数据模型Data Model功能建立了显著的技术壁垒。WPS 表格已引入超级表、多维表关联字段、内置 SQL 引擎和 WPS Query等能力，但缺少对等的数据模型功能。
二、数据模型的内涵
本文聚焦电子表格工作簿语境，将数据模型界定为嵌入工作簿内部、可持久化的关系型数据存储与关联管理机制，具备三项特征：
（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 列式存储引擎
VertiPaq（也称 xVelocity）是 SSAS Tabular 的底层存储引擎，将每列唯一值构建为哈希字典，配合 Run-Length Encoding 压缩重复序列，内存占用通常降至原始大小的十分之一，查询时仅加载目标列，该引擎可"创建包含数百万行的数据模型"。
3.3 DAX 分析语言
DAX（Data Analysis Expressions）是 SSAS Tabular 专用的公式语言，用于定义度量值、计算列和表级计算。DAX 引入筛选上下文（Filter Context）和行上下文（Row Context）两种计算环境，提供 CALCULATE、FILTER、ALL 等函数在两者之间切换，使分析人员能在不同粒度间灵活定义聚合逻辑。
3.4 Power Pivot 管理界面
Power Pivot 是面向用户的数据模型管理入口，提供数据导入、关系定义和 DAX 编写。用户通过"关系图视图"管理多表关联，支持一对多和通过桥接表实现的多对多关系。Data Model 允许用户在同一工作簿内整合多张数据表，建立表间关系，形成关系型数据源，使工作簿从单表容器升级为轻量级数据库。
3.5 Cube 函数族
Excel 提供 7 个 Cube 函数（CUBEVALUE、CUBEMEMBER、CUBESET、CUBEMEMBERPROPERTY、CUBESETCOUNT、CUBEKPIMEMBER、CUBERANKEDMEMBER），通过 OLAP 连接读取 Data Model 聚合数据。CUBEVALUE 接收 OLAP 连接参数和维度成员表达式，返回指定维度组合下的聚合值。与透视表的拖拽交互不同，Cube 函数提供可编程式的模型读取方式，使工作表能精确访问特定数据切片。
3.6 MDX 查询语言
Cube 函数通过 OLAP 连接访问 Data Model，该连接在底层依赖 MDX（Multidimensional Expressions）查询语言。MDX 是专为 OLAP 系统设计的查询语言，基于 XML for Analysis（XMLA）规范。SQL 面向二维表返回行集，MDX 面向多维空间，在 SELECT 子句中定义多个查询轴返回元组集合。
在 Excel Data Model 中，Cube 函数的调用在底层转化为 MDX 查询发送给 SSAS 引擎执行——例如 CUBEVALUE("连接","[产品].[类别].[电子]","[时间].[年].[2024]") 对应一条从产品和时间维度交叉位置取值的 MDX 查询。另外，外部 OLAP 工具可通过 MDX 连接 Data Model 进行更复杂的多维分析。SSAS Tabular 以 DAX 为原生语言，MDX 通过映射层兼容访问。
四、WPS 表格现有的数据库相关能力
WPS 表格已引入若干数据库能力，在关系模型的各项特征上实现了不同程度的覆盖，但均未构成完整的数据模型。
超级表的底层对象是 ListObject，是电子表格的结构化数据管理基础。其核心能力包括列标题筛选、动态区域自动扩展、汇总行、结构化引用（以表名[列名]引用数据，对标 SQL 的 table.column）。超级表还展现出若干类数据库特性：表结构 Schema 定义与元数据持久化（唯一表名、列名、数据类型持久化到 Open XML）；数据完整性约束涵盖列级数据类型推断校验、数据验证（对应 CHECK 约束）、计算列统一公式，以及通过"删除重复项"和数据验证实现的唯一性约束和非空约束；索引方面为每列构建临时位图索引与值字典；行/列增删以对象为单位执行原子性操作。
超级表与数据模型的核心差距在于：其能力限于单表，不涉及表间关系定义，也不提供外键、级联操作等关系完整性保障；数据仍存储在单元格网格中，没有独立的存储引擎；透视表虽可基于超级表生成聚合报表，但因缺少表间关系，无法实现跨表联合分析。
4.2 多维表关联字段
多维表格（DbSheet）已支持同一文档内不同数据表之间的关联字段，可定义表间引用关系并实现跨表查找。多维表已触及多表关联这一核心能力——用户可以指定两个表之间的关联列，使一张表能引用另一张表的数据，这是向关系模型迈进的重要一步。然而，多维表的关联仅作用于云端多维表格文档，本地工作簿中的超级表尚不支持跨表关系定义，且关联为 UI 层面的查找引用而非数据库级别的级联约束，缺乏参照完整性；多维表的数据仍依托工作表单元格存储，没有独立的持久化存储引擎，其关联字段也无法被透视表等原生组件直接使用。
4.3 内置 SQL 引擎
WPS 表格内置 SQL 引擎支持以 SQL 语句查询工作表数据，可执行 JOIN 等多表查询操作，具备跨表关联查询能力。然而，SQL 引擎未提供多表关系的持久化定义——查询中建立的表间关联是临时的，随查询结束即消散，打开工作簿时无预先定义的关系模型。查询结果不具备主键、外键等约束信息，最终回写为工作表数据。SQL 引擎没有独立的持久化存储载体，无法在工作簿内部维护独立的数据副本。
4.4 WPS Query
WPS Query 提供可视化的数据导入与转换管道，支持从多种数据源导入数据并进行筛选、排序、合并、分组等转换操作，是数据准备阶段的实用工具。然而，WPS Query 未触及多表关系的持久化定义和与原生组件的集成：管道中建立的表间关联随工作簿关闭而丢失，不具备数据库级别的约束信息；产出物为静态工作表数据，无法被透视表等原生组件持续读取并自动应用关系。WPS Query 擅长数据清洗与整合，但在"数据→模型→报表"链路中，缺少向模型层交付持久化关系定义的能力。
五、社区增强方案及其缺陷
WPS.DuckDB：WPS 加载项，将 DuckDB 嵌入式数据库引入表格，支持在单元格内编写 SQL 查询。但模型定义不随工作簿持久化，查询结果为静态值。新版：xlDuckDB需要解除沙箱才能用，直接改成c++版XLL。
SQL Lab：WPS 加载项，基于 DuckDB 提供 SQL 编辑界面，支持合表拆表。同 WPS.DuckDB，模型定义不随工作簿持久化。
xlDuckDB：Excel/WPS 插件，支持 DuckDB SQL 查询。依赖第三方插件，与透视表无集成接口。
ODBC + DuckDB：通过 ODBC 驱动连接 DuckDB，可实现外部数据库级处理。首次使用需配置 ODBC 数据源，数据与工作簿物理分离。
ffi 调用：通过 JSA 的 Foreign Function Interface 直接调用 DuckDB 本地库。复杂度高，无标准化模型接口。
上述方案均无法替代原生数据模型。下文从两个维度分析原因。
5.1 持久化维度：模型定义无法随工作簿保存
数据模型的核心价值在于"一次定义，反复使用"。在 Excel 中，表间关系作为工作簿文件的一部分持久化——打开即加载，关闭即保存，后续分析会话可直接对接。
社区方案在这一维度存在根本性缺陷。以 WPS.DuckDB 为例，查询在内存中执行，工作簿关闭后实例销毁，再次打开需重新加载数据和关系。工作簿文件本身不存储表和关系定义，这些信息仅存在于运行时。ODBC + DuckDB 更为突出：数据存储在外部文件中，与工作簿完全分离。差距的本质在于：数据模型要求工作簿成为模型定义的载体，而社区方案中工作簿仅是查询结果的输出目标，二者在可复用性和可维护性上存在根本区别。
5.2 集成维度：无法与原生组件形成闭环
数据模型的第三项特征是与原生组件无缝集成。在 Excel 中，透视表和 Cube 函数均可直接读取 Data Model 中的表间关系。社区方案存在结构性障碍：WPS.DuckDB 的查询结果回写到单元格，产出物是静态数据值，而非持久驻留在工作簿中、可被透视表持续使用的模型实例。用户无法基于 DuckDB 结果直接创建关联透视表，需先写入工作表再创建，这一过程丢失了关系信息。核心差距在于：数据模型是持久驻留的数据服务层，可被多个原生组件并行读取；社区方案的查询结果是单次产出，不具备持久驻留和持续使用的能力。
六、WPS 补齐数据模型能力的可行路径
以下路径均以开源技术为基础，不依赖 Microsoft 专有生态，具备自主可控性。
6.1 以嵌入式数据库为内核构建持久化数据模型
在工作簿内嵌入轻量级关系型数据库实例（如 SQLite 或 DuckDB），用于持久化保存表和关系定义。SQLite 可承担数据模型的存储和关系管理职责；DuckDB 额外提供列式分析性能，WPS.DuckDB 已验证其在 WPS 环境中的嵌入可行性。需在工作簿文件格式中定义专用存储区域，打开加载、关闭写回。当前 WPS.DuckDB 已具备嵌入能力，需增加序列化层，将内存级表注册改造为文件级持久化操作。
6.2 在超级表基础上扩展持久化关系管理
多维表关联字段已验证用户对表间引用的需求。可将此能力从云端扩展到本地超级表，在对象模型中为超级表增加关系元数据属性（外键列引用、基数类型、级联行为），随文件序列化保存，打开时自动恢复。
6.3 建立统一的模型读取接口
透视表组件需增加连接嵌入式数据模型的入口，用户可在创建向导中增加"连接数据模型"选项，透视表引擎从嵌入式数据库读取表结构和关系元数据，自动生成 JOIN 逻辑。同一模型实例应能被多个透视表并行读取，实现"数据→模型→报表"的完整链路。
七、结语
数据模型的缺失并非 WPS 表格在单项能力上的不足，而是在持久化和集成两个架构维度上的系统性缺口。社区方案增强了查询能力，但由于插件架构无法触及工作簿文件的存储层和原生组件的对象模型，未触及数据模型的核心需求。
WPS 补齐数据模型能力有可行路径：WPS.DuckDB 已验证 DuckDB 在 WPS 环境中的嵌入可行性，多维表关联字段已积累表间关系的 UI 交互经验，WPS Query 已具备数据导入与转换的管道能力。这三项能力恰好对应数据模型所需的存储引擎、关系管理和数据接入三个环节，构成了从"数据处理管道"向"嵌入式数据模型"升级的技术基础。
