开头先啰嗦两句：
有朋友问我：我看你文章中提到了很多的软件，比如飞书多维表格、airtable、智能表格、Notion，多维表格到底是哪个软件？
这里我统一解释一下：我这几篇文章中所提到的多维表格，并不是指单一的软件，而是指具有多维表格底层属性的这一系列软件，比如我文章中所提到的那些：airtable、Notion、飞书多维表格、腾讯智能表格，此外还有WPS、Vika云、wolai、flowus等等。
多维表格的定义比较晦涩：A Relational Database with a Spreadsheet Interface（带有电子表格界面的关系型数据库）。在技术圈，通常称之为 Smart Spreadsheet（智能表格），而在国内，多维表格已经成为一个事实上的术语。
所以我在这里讲到的技巧，理论上在这类软件中都是互通的，更像是一种通用技能，所以我十分推崇对于多维表格的使用。
大家好，我是运哲。
先说一下我自己对于多维表格的定义：可视化关系型数据库。
其中，每一个词都很重要：
- 可视化：同一份数据源可以有多种不同类型的视图来展示（上一篇文章已经详细讲过）；
- 关系型：数据不是孤岛，而是具备关联关系，可以形成数据网络（也是其灵魂所在，本篇详细讲解）；
- 数据库：具备传统数据库的结构化数据、是记录（非行）的属性（下篇预告）；
由可见，在多维表格中，“关联关系”的重要性。
那么，什么是关联关系？这里我依旧不会给大家讲晦涩的概念，我会用一个我工作中具体的示例给大家展开讲一讲。
记得有一次，在公司内部数字化应用的分享会上，有研发部门的朋友问我：
“运哲老师，我们公司采购流程挺复杂的，有设备参数、有供应商对接、还要签合同。用Excel管得我头昏脑涨，多维表格能救我吗？”
我问她：“你最头疼的是什么？”
她说：“最崩溃的是，一个设备的供应商换了销售代表，我得去设备表里改联系人，去合同台账里改备注，还得将这个信息同步给采购部门和工程部，甚至还在ERP系统里改信息。漏改一个，到时候联系不上人，就是我的责任。”
如果你也深有同感，那么你正在遭受Data Redundancy（/ˈdeɪtə rɪˈdʌndənsi/，数据冗余）的折磨。
今天，我想结合“设备采购”这个真实场景，聊聊多维表格真正的“灵魂”功能，也是解决这个问题的终极杀招——Relational Linking（/rɪˈleɪʃənl ˈlɪŋkɪŋ/，关联关系）。
01 三座孤岛：传统的Excel的困局
在采购工作中，我们需要维护三类核心数据：
- 设备清单： 设备名称、型号、供应商。
- 供应商清单： 公司名、销售姓名、电话。
- 合同清单： 合同号、金额、签订日期。
在二维的 Excel 思维里，为了方便看，我们习惯把所有信息塞到一张表里，或者在不同的表里反复复制粘贴。
- 你在【设备清单】里记：液相色谱 | 安捷伦 | 销售小王 | 138xxxx。
- 你在【合同清单】里又记：合同001 | 购买液相色谱 | 安捷伦 | 销售小王 | 138xxxx。
你会发现，“安捷伦”、“小王”和“电话”被重复录入了很多次。
这就埋下了一颗雷。当“小王”离职了，换成了“小李”，你需要把过去几年所有相关的表格全部翻出来，一个个查找替换。
这叫Data Silos（/ˈdeɪtə ˈsaɪloʊz/，数据孤岛）。表格之间老死不相往来，修改变得异常沉重。
2. 建立连接：让数据“流动”起来
多维表格的伟大之处，在于它引入了Database（数据库）的思维。
在这个思维下，我们先把业务拆解成三个干净的实体（Entity）：
- 供应商表（Suppliers）： 只存供应商信息。安捷伦就是安捷伦，电话只记一次。
- 设备表（Equipment）： 只存设备信息。
- 合同表（Contracts）： 只存合同信息。
然后，关键的一步来了：我们要用“关联关系”，把这三张表连起来。
- 第一步：设备关联供应商。 在【设备表】里，我不手打供应商名字，而是创建一个关联字段，直接指向【供应商表】。 我要录入“液相色谱”时，直接在关联了“供应商”的字段下拉框里选“安捷伦”。
- 第二步：合同关联设备。 在【合同表】里，我创建一个关联字段，指向【设备表】。 签合同时，我录入对应的合同信息的同时，在关联了“设备表”字段下选择“液相色谱”。
这就形成了一条清晰的Chain（/tʃeɪn/，链条）：
合同 -> 关联 -> 设备 -> 关联 -> 供应商
这不仅仅是省去了打字的时间。
它的本质是：合同里的“设备”和设备里的“供应商”，都只是原始数据的一个Reference（/ˈrefərəns/，引用/镜像）。
3. 见证奇迹：Lookup 的魔法
这时候，有朋友会问：“运哲，我在【合同表】里只选了设备，但我领导审批合同的时候，需要看到供应商的销售电话，方便核实，怎么办？”
难道要跳回【供应商表】去查吗？
不需要。这时候我们需要用到另一个神技：Lookup（/ˈlʊkʌp/，查找引用）（Notion中叫做Rollup（汇总））。
如果说“关联”是铺设管道，那么“Lookup”就是顺着管道把水抽过来。
我可以在【合同表】里新建一个 Lookup 字段，通过索引，将【销售电话】显示出来，设置逻辑：
通过关联的【设备表】，找到背后的【供应商】，把供应商表里的【销售电话】显示在这里。
因为【合同表】和【供应商表】没有直接的关联关系，因此这时候【设备表】就会作为信息流通的中间表。
具体设置步骤：
- 在【设备表】里面，创建Lookup字段，将【供应商】清单中【销售联系电话】索引出来；
- 在【合同表】里面，创建Lookup字段，将【设备表】清单中【销售联系电话】索引出来（示例我用的是Notion，因为本身软件限制，Notion无法直接索引到关联表格的Lookup字段（Notion中叫做Rollup），所以我索引的是新建的公式字段）；
Bang!（砰！）
当你选定“液相色谱”的那一刻，它背后的供应商“安捷伦”，以及销售“小王”的“电话”，全部自动出现在了合同表里。
同时，如果不想在 【设备表】中显示过多的信息，可以右键对应的属性，选择【隐藏】，隐藏后不会影响到对于字段的索引。
4. 终极价值：Single Source of Truth
回到开头那个让采购经理崩溃的问题。
现在，供应商“安捷伦”的销售代表从“小王”换成了“小李”。
你只需要做一件事：
打开【供应商表】，找到“安捷伦”，把联系人改成“小李”。
Modify once, update everywhere.（一处修改，处处更新。）
你会惊讶地发现：
- 你的【设备表】里，所有安捷伦设备的联系人自动变了；
- 你的【合同表】里，所有涉及安捷伦设备的合同备注，自动变了。
这就是Single Source of Truth（/ˈsɪŋɡl sɔːrs əv truːθ/，单一数据源）的魅力。
5. 总结：从记录员到架构师
为什么我说“关联关系”是多维表格的灵魂？
因为没有它，你做出来的只是电子化的笔记本；有了它，你搭建的是一套Automated System（/ˈɔːtəmeɪtɪd ˈsɪstəm/，自动化系统）。
在“设备采购”这个场景中，多维表格帮你理清了Supplier（供应商）、Product（产品）与Transaction（交易）之间的逻辑。
当你开始思考这三张表如何关联时，恭喜你，你已经跳出了“填表人”的思维，开始具备了Business Architect（/ˈbɪznəs ˈɑːrkɪtekt/，业务架构师）的视野。
这，才是数字化转型的第一步。
