7.1 业务过程与记录：从业务交易到数据表

在数据分析的世界里，没有“记录”就没有分析。

7.1.1 “事实表”的业务由来和结构

数据世界的“事实”（Fact）并非抽象概念，正如“事实”词意一样真实、实在——英文中常说“it’s a fact”，中文常说“事实如此”。通俗的说，“事实”指一个已经发生的、可被计量、可被追溯的业务行为，例如顾客的一次购买、旅客的一次值机活动、工厂设备完成一笔工单。

运营型数据库和分析型数据库都以各类事实表为中心，完成业务过程、业务对象的数字化。

1）“事实”和“交易”：聚焦“计量型属性”

为了理解“事实”，就要从数字化早期实现银行“交易”（transaction）说起。

在上世纪七八十年代，计算机系统开始从军事领域逐渐应用到银行、证券等金融行业，典型应用是支持 ATM 机自动化存取款交易。

在银行业务中，“交易”（transaction）指用户存款、取款、查询余额的一系列过程，后来也指计算机系统中数据库的数据变更、数据一致性检验、提交执行等一系列计算的处理过程。中文世界把这类数据库处理过程翻译为“事务”和“联机在线事务处理”（OLTP），从而把真实的交易、抽象的事务分离开来，有助于理解、避免混淆。

概念说明：OLTP，OnLine-Transaction-Process

在数据库中，事务是需要同一个处理单元中执行的一系列更新处理的集合。

后来，随着咨询公司和软件公司把银行交易系统的事务处理方法推广到各行各业，交易、事务概念（transaction）逐渐代指一切有明确主题、明确处理过程的现实或计算机处理过程。在数据仓库中，最常见的一类事实表就是“事务性粒度事实表”（《数据仓库工具箱》英文 P12）,常见的销售交易过程也常称之为“销售事务”（sales transaction）。

Transaction grain fact tables are the most common. (P12)

让我们想象一个简单的销售场景：

2025/7/4上午10点，张三在华为某线下门店，经服务员李经理介绍，购买了一台售价5999元的华为手机（产品ID: P001），对应购物小票中，标记订单号#1001，折扣500元。

不管现实的交易是否耗费了营业员若干小时，经过了多少论讨价还价，在数据世界中，上述的交易过程会记录为结构化的“一行数据”。为了业务记录方便，数据库中还会为客户、营业员、商品都标记为代码，于是就有如表7-1所示的数据明细表：

表7-1 销售事实表示例

“张三买手机”这一业务事件，就“蚀刻”为了一条独一无二的记录，不管风吹雨打再也不会改变；假设事后退货，则会对应退货过程的“退货事实表”新行，历史交易无需改变、更不能被删除。可见，事实表并非凭空设计，它的结构就是交易过程的数字化反映。

如今，诸如零售销售、航空出行、酒店入住等交易类、事务处理的业务，都会被记录为“交易明细表”“事务明细表”存储于数据库之中。这个过程，就如同旅游途中拍照记下来了的美丽瞬间，时光已逝、彼刻长存，照片反映了当时的现实。只是业务世界的“反映”追求高度结构化，几乎所有的“事实表”都是关系型数据表样式，以图片存储客户购买过程难以量化和分析。

从业务的角度看，“数据已经吃掉了世界”。高级的分析师应该以这种“抽象之眼”看世界。

在数据库中，广义的“事实”（fact）对应交易、事务，泛指一切有明确行为和所指的现实活动；狭义的“事实”则特指交易过程中用于精确计量业务过程表现（performance measurement）的数字型属性（measure attribute），比如数量、单价、折扣等。如图7-1所示。

图7-1 交易、事务、事实和事实表的关系

正因为此，数据分析常以“事实表”（fact table）泛指一切详细记录业务过程的结构化明细表；事实表必须包含对应业务过程的、数字型属性值，否则就是后续要讲解的“维度表”。

The term fact represents a business measure. （P10）
（关键词“事实”代表一个业务的计量）

2） 事实表的关系型范式：强调业务完整性

数据世界中，数据库（databases）用来存储数据，但存储数据的方式却并非只有一种，早期的网状数据库、文件数据库，后来的列式数据库、分布式数据库等都各领风骚若干年；而今主流的数据库类型是“关系型数据库”，多维数据库、分布式数据库、NoSQL 数据库都未撼动它的地位。

在“关系型数据库”（relational databases）中，一次业务事件对应着数据表一行（row），也称一条记录；而事件的每一个核心要素，则分别存储在不同的列（Column）。

从业务的角度看，数据表的行对应业务过程（business process），而列对应业务对象（business objects），二者交叉构成了整个业务交易的事实。

从技术的角度看，关系型数据样式由字段、记录，或者说行、列交叉组成**，**如图7-2所示。

图7-2 一个典型的数据表的样式

其实，表、行、列这些耳熟能详的概念更像是Excel 场景下的通俗概念，在关系型数据库中，更严谨的技术概念是关系、记录（也叫元组）、字段（也叫属性），就像“爹娘”和“爸妈”之于父母。笔者在书中常常使用“记录行”“字段列”，只是为了帮助新读者建立概念之间的联系，从语言的角度看其实是过度定义（类似于“动物人”）。对应关系如表7-2所示。

表7-2 概念的对应关系（中英文）

从业务的角度看，事实表的设计出发点，首先追求准确、完整、及时地“记录”业务行为的本来面貌；一次事实上的确定性交易，必然对应数据表的准确记录。记录业务的运营过程是事实表的主要功能之一，所以事实表也常常通俗的称之为“记录明细表”。相比“事实”，“记录”（record）是更被普遍使用的词，以至于不得不注意使用场景避免滥用（就像度量一词） 。

对于一个给定的数据表而言，记录对应的业务过程是确定不变的，分析师的重点是成百上千的“字段列”，它们对应业务世界的人、地点、产品等各类业务对象。核心字段可用于描述业务过程，特别是表示5W2H 的少数核心字段。

• Who：事实交易的主体，比如收银员、营业员、销售员等
• When：事实交易的时间节点，比如订单时间、支付时间、登机时间等
• Where：事实交易的地点，比如出发地、出发港口、门店编号等
• Whom：事实交易的客体人物，比如客户、第三方等
• What：事实交易的客体对象，比如产品、服务等
• How ：事实交易的方式，比如借贷、销售/退货等，通常转化为状态字段
• How much：事实交易的准确记录，比如数量、单价、折扣、积分金额等

比如，一家超市的“销售明细表”描述的业务过程是“谁（Who）、在何时（When）、于何地（Where）、给谁（Whom）、以何种方式（How）、提供了什么（What）、交易计量多少（How much）”。这里的5W2H在数据世界中对应数据表记录的业务字段，其他字段是它们的属性或延伸。

理解了“记录行”和“字段列”，何为“关系”（relation）？

在数学上，关系就是业务过程中各个业务对象的任意组合。“苏超”13支球队互为主客场，共计13*12种组合；5个客户、10个产品、12个门店，理论上就有5*10*12种交易组合（姑且假设一个客户一次只买一件产品的简单场景），所有可能性构成的数据表就是完整的“关系”。

事实上，没有一家企业的业务能穷尽所有业务对象的组合，现实世界中的“事实表”都是业务对象之“关系”的实例；正是建立在严谨的数学理论基础上，才确保了“关系性数据库”成为最流行的数据库类型，关系型事实表成为业务的基础。

虽然数据库是软件工程师精心设计的，实现了现实世界到数字世界的创造性转换，但这里更推荐读者把这个过程视为“投影”或者“反映” （representation），数据并非人为杜撰的表格，而是业务行为被系统忠实记录下来的痕迹——正如柏拉图在“洞穴隐喻”中描述的那样。

正如Engles所说，真实世界、所知世界、符号世界是层层递进的，后者是前者的投影和抽象（见本章参考资料[1]）[^1]，计算机不过是用硅基芯片和电子运动代替了光与影，投影出的数据世界更加清晰、逼真而已，但依然是“影子”而不是现实。

从这个角度看，事实表“只记录、不创造”。“事实表”的职责在于详细地记录业务事实，而不会创造现实中没有的业务对象（比如人均单笔存款金额，或者利润率）。

图7-3 从真实世界到符号世界的投影过程简图

和“只记录、不创造”相对于的是分析世界的各种“分组聚合表”，以聚合为代表的计算实现了业务世界从有到无的生的抽象升华，创造了“利润率”“应收帐款周转天数”等现实世界中本来不存在的“管理对象”，帮助业务领导把握业务运行规律。

一些大型企业会把部分高度聚合的结果表物化存储与“分析型数据库”中，比如“各年度、各分公司的销售额总和、同比增长和利润率”，物化的聚合表就会退化为特定意义的“事实表”，笔者更倾向于称之为“管理型事实表”，以便于上述的“交易型事实表”相区别。7.4 小节会介绍。

7.1.2 记录方式的对比：“关系表”与Excel

本书第6章 6.1.2 小节曾从概念层批评过 Excel：“透视”一词的滥用遮挡了分析的本质。本小节则要往下追一层——不是概念的问题，而是结构的问题。

对于大部分分析师而言，对Excel的熟悉程度远超“关系型数据表”，这并非是好消息。在通往专业分析的路上，很多人被Exce习惯和理解束缚了手脚，笔者把这称之为“Excel Wall”。

严格地说，Excel中的数据表只是“电子表格”（spreadsheet）或者“工作表”（worksheet），而不能称之为“关系型数据表”，因为不具备后者的几个关键特征：

• “关系型数据表”的行、列没有先后次序，因此也没有额外编码的必要。

在 Excel 中，所有人首先看到的是左侧1、2、3等“行号”和上方 A、B、C “列号”，这是易用性的前提，但缺并非关系型数据表的必备，因为数据表的“逻辑”分离架构，确保了分析师完全无需关心存储层面的次序问题。

• “关系型数据表”追求严格约束，比如行不能重复、列不同重名、没有空白行和空白列，更不能在同一列中插入不同格式的数据值。

相比之下，Excel 中数据行重复的情况比比皆是，甚至常常有意设置空白行和空白列，可见 Excel 表格不追求形式上的完整性，也不对用户设置过多约束。

• “关系型数据表”建立在严格的数学“集合论”理论之上，没有可视化界面也不影响其运行；而Excel电子表格以“可视化网格”为起点，不追求结构性规范，而追求易用、灵活的“所见即所得”

如表7-3所示，介绍了二者最重要的一些差别。

表7-3 【待补表注】

由于上述的关键差异，Excel“电子表格”往往聚焦于“单元格”（Cell），所以“表哥表姐”思考和操作的基本单位是单元格。然而，在关系型数据表的世界里，这一套直觉是完全不适用的。“关系型数据表”没有“单元格”可言，其不可再分的最小操作单位是“记录”。增删改查以 “记录”为对象，比如追加一笔订单信息、修改旅客值机后的登机口/座位号信息，等等。

我们无法像在Excel中那样，对数据库说“请给我第3行第5列的那个值”；只能通过查询条件来描述我们想要的记录，例如“请在订单号为#1001的记录中，返回‘数量’这个字段的值”。 即便最终查询是一个值，依然要视为单行单列的“数据表”。 如图7-4所示。

图7-4 PostgreSQL数据表和Excel电子表格示例

在笔者看来，“Excel Wall”最大的毒药是“单元格思维”，阻碍了深度理解分析过程。

Excel的诸多特征看似易用，但同时意味着缺乏深度。小数据时代的“美酒”，恰恰成了大数据时代的“毒药”，锁定了Excel和“表哥表姐”的能力上限；Excel电子表格则像是越来越臃肿的“小学生”，不得不在专业场景中让位于PowerPivot和BI等后起之秀，如Tableau、PowerBI。与此同时，“关系型数据库”几乎成为大数据时代的数据底座。

“单元格思维”的长远影响之一，是影响了分析师建立基于“集合”和基于详细级别、基于粒度的思考方式，前者是关系模型的基础，后者是多维分析的基础。在笔者学习Tableau的多年时间中，最重要的顿悟应该是从Tableau的“LOD详细级别表达式”到三个详细级别的场景：数据表详细级别（Row LOD或Table LOD）、视图详细级别（Viz LOD）和指定的详细级别（Fixed LOD）。至此，深度分析的世界才算完全打开，而这是Excel世界不可能触达的领域。

因此，本小节特别强调 Excel 电子表格和关系型数据表的一点逻辑差异，帮助后来者从“单元格思维”中跳脱出来。这不仅是理解后续SQL查询和数据建模的基础，更是分析师从传统的数据处理，迈向现代化、规模化数据分析所必须跨越的第一道门槛。