做数据分析，有两个层面的事情绕不开：数据在哪里，分析在哪里。数据透视表解决的是后一半——把分散的明细汇总成分类、小计、总计，让人一眼看出结构。而前一半，数据从哪里来、以什么形式来，决定了一张数据透视表从搭建到更新要经历多少周折。两个层面的距离越近，分析的整个链条就越顺畅。
SpreadJS 的数据透视表此前已经支持多种取数方式。可以直接在工作表里指定数据区域，也可以引用已经建好的表。这些方式各有适用场景，前提是数据已经以表格的形态落在工作表里。然而现实中的业务数据，并不总是这副模样。数据可能存在于接口后端、存在于结构化数据源里，还没被搬进任何一张工作表的单元格。对这部分数据做透视分析，过去往往要先把它落到表里，再走一遍既有的流程。多出来的这一步，就是分析链条上的一段距离。
分析层与数据层之间
SpreadJS 的 DataManager 提供了一套结构化的数据管理能力，负责处理数据源与表格之间的衔接。它让数据以表的形式被统一组织，并承担与表格的绑定、视图的建立等工作。此前，DataManager 中的数据通常要经由工作表再进入其他分析环节。新版本中，数据透视表与 DataManager 之间的距离被进一步拉近：数据透视表可以直接以 DataManager 中的表或视图作为数据源。数据不必先落入工作表，就能进入透视分析的流程。分析层与数据层之间，多了一条直连的通道。
直接对接之后，取数方式上还有一层细致的区分。分析单个表里的字段时，以 DataManager 的表作为数据源即可，字段与明细都来自这一张表，结构清晰，用起来也最直接。
而当分析需要涉及多张表的关联、需要视图暴露出来的字段——比如投影出的新字段、筛选后的结果、计算字段，或者由关系模型拼装出来的字段——则以 DataManager 的视图作为数据源更为合适。
视图把多张表的关系整理成一个分析可用的整体，数据透视表面对的是一份已经组织好的结果，不必再去拼接散落的几张表。一条多表关联的数据链，过去要靠人工把字段一张张拼进分析，如今视图直接提供了这份拼装，透视分析拿到的字段本身就带着关联的语义。这两种取法在配置上的差别也很直观，一个指定表名，一个指定"表名.视图名"：
// 以数据管理器中的表为数据源
{ source: "TableSales", autoRefresh: true }
// 以数据管理器视图为数据源，写法为 "表名.视图名"
{ source: "Sales.SalesAnalysisView", autoRefresh: true }
快照、缓存与自动刷新
数据透视表与分析源之间，存在一层称为透视缓存（PivotCache）的机制。数据透视表基于数据源建立缓存，建立完成之后，透视分析实际运行在这份缓存之上。数据源的变化能否反映到分析结果里，取决于缓存是否刷新。新版本为数据管理器数据源提供了自动刷新：当源数据发生变化时，缓存可以随之同步更新，分析结果与源数据保持一致。若不需要自动同步，也可以手动触发刷新，何时更新由使用者决定。
缓存机制的引入，让"数据源"这个概念在透视分析里变得更加规整。分析所依据的数据，是一份建立时点明确的快照；需要跟进更新时，再让快照与源数据对齐。这份确定性对于分析场景是必要的——汇总结果的每一步变化都有迹可循，分析依据的是什么时刻的数据，是清清楚楚的。
另一个细节是数据源状态的处理。当数据管理器中的源数据暂时没有记录时，数据透视表依然可以依据数据表的结构定义（字段与类型）建立一张空的分析骨架。字段、布局先立起来，数据一旦填充，分析即可跟进。这在业务系统尚未导入数据、却需要提前搭建分析模板的阶段，省去了等待数据就绪的时间。
几个被拉近的场景
这层能力放到真实工作中，对应的是几类常见却又棘手的场景。
数据不必落表的场景是第一个。一套系统里，明细数据存放在数据管理器中，随时可能有新的记录加入。过去要做透视分析，得先把数据导出、转表，再建数据透视表；数据一变，整套动作还要重来一遍。如今透视表直接吃数据源，新增的记录进入分析，只在一念之间。省掉的不只是导出导入的动作，还有"分析总是滞后于数据"的无奈。
源数据动态变化的场景是第二个。业务数据的更新往往是持续发生的。今天的新订单、今天新增的库存记录，都可能影响汇总结果。开启自动刷新后，透视结果跟随数据源同步变化，看板、报表不必因为数据更新而手工重算。这份"随源而动"的一致性，对依赖实时数据做判断的岗位，价值是实打实的。
多表关联分析的场景是第三个。许多业务分析天然涉及多个表：销售表连着产品表，订单表连着客户表。在视图层面把这些关系组织好，让透视分析直接消费视图暴露的字段，等于把"关联"这件事从分析环节前移到了数据组织环节。分析者面对的是一个语义完整的视图，不用自己动手拼接字段。分析的门槛降低，分析的准确性也因此更有保障。
模板先行、数据后至的场景是第四个。业务系统的开发往往先行于业务数据的成熟。在数据尚未完全就绪时，把数据源的结构定义好，数据透视表先按结构搭好分析布局，等数据一到位，透视结果即刻成形。分析模板与数据结构解耦，系统的上线进度不至于被数据准备的进度拖住。
对以表格为核心界面的业务系统来说，这层对接还带来一个整体性的改善：数据分析的取数路径变得单一而清晰。无论数据起初在接口、在数据源、还是在工作表中，只要进入 DataManager 的管理范围，透视分析就有统一的入口。数据源的种类可以很多，分析的起点保持一致，系统的复杂度因此被收敛在一处。
数据透视表的价值，在于把明细压缩成结构；而它的根基，始终在于数据源的可得性。分析层与数据层离得越近，一张透视表从想法到成型的路径就越短。让数据管理器与数据透视表直接对话，省去的是一次次搬运，缩短的是从数据到判断的距离。数据在哪里，分析就能从哪里开始。数据透视表本身并非新事物，但把它与结构化数据源之间的路铺平，让原本要在表格之外绕行的那一段消失——这样的变化，对每天与数据打交道的分析者来说，往往是更实在的进展。
