喜乐君·数据分析夏令营 第 7 期:数据模型——从单表到多表 · 课堂回顾

把数据模型讲成一根轴——物理合并是分析前预先合并,逻辑合并是分析时按需处理;逻辑又分持久的关系与按需的混合。本期用三段递进:Facebook 拆开物理 vs 逻辑、Bookshop 演示双层结构、Library 引入混合,最后落到第二版书的 unit × join 位置四格框架。

📌 要点:数据模型 = 数据合并 = 计算的高级形式——物理合并是分析之前做好恒定且真的合并了,逻辑合并是分析过程中按需处理;逻辑又分两种:持久的关系(Relationship)与按需的混合(Blend)。从视图的角度看都是「合成一个」,只是合并发生的位置不同。本期用三段递进把这条轴讲完:Facebook 拆开物理 vs 逻辑 → Bookshop 演示双层结构 → Library 引入混合(Blend)。 正式课 · 2026-09-05 直播配套文字版 · 视频回放:B 站「Tableau 喜乐君」《直播第七次 · 数据模型:从单表到多表》(约 50 分钟) · 来源书稿:《数据可视化分析》第 4 章

喜乐君(XILEJUN):Tableau Visionary 名人堂成员,著有《数据可视化分析》《业务可视化分析》等。slogan:「唯有知识让我们免于平庸」。

这一期把「数据模型」讲成一根轴——物理 vs 逻辑。前六期都在单表内,本期第一次打开多表世界。课上分三段推进:

  • 第一段用 Facebook 扩张学校数据 做最简单的引子,让观众看见「物理 vs 逻辑」的分叉;
  • 第二段切到 Tableau 官方 Bookshop 样例,演示「双层结构」——预先合并的物理层 + 按需关联的逻辑层;
  • 第三段临时引入 Library + Catalog,补齐「混合(Blend)」这一类。最后落到第二版书的「unit × join 位置」四格框架——把全部讲过的合并方式收拢到一张二维图。

课程要点(时间轴)

  • 课堂三段 —— 开场 Facebook 拆开物理 vs 逻辑 → 主体 Bookshop 演示双层结构 → 收束 Library 引入混合(Blend)
  • 主线贯穿 —— 物理 = 预先合并 / 逻辑 = 按需合并;一根轴讲完全部合并方式
  • 模型是什么 —— 分析前的预处理 / 预计算;弥补表中已有字段的不足;当前表算不出的,才去别处拿
  • 逻辑模型(关系) —— 一根线、两边圆圈;按需合并、性能高又灵活;不用的字段连提取都不提取
  • 物理模型(Join) —— 双圆圈;分析前预先合并;Excel VLOOKUP 是真的合在一起;要预先预估要的所有东西
  • Bookshop 双层结构 —— 物理层 Book⋈Info 用 BookID=[BookID1]+[BookID2] 预合并;逻辑层 Author/Edition/Sales/Award/Series 关系连接;六个表不会预先合并到一起
  • 三个关键开关 —— 基数(Cardinality)、性能选项(Referential Integrity)、关系筛选
  • 混合(Blend) —— 在右侧(视图之后 / 分组聚合之后);临时的握手;关系是持久的,混合是按需的;混合灵活到大部分人难以驾驭
  • unit × join 位置四格 —— 一个维度是合并方式(上下追加 vs 左右相连),另一个维度是合并位置(物理 vs 逻辑)
第7期信息图:数据模型的两条路与合并的两种形式
图 1 · 第7期信息图全景:出发点 / 两条路 / 分类矩阵 / Join·Relationship·Blend / SQL·PowerBI / 七期闭环
  • 七期闭环 —— 模型 = 计算的高级形式 = SQL 的 JOIN,只是换了一种方式表达

一、整体节奏:三段递进、一条主线

课堂用三段递进 + 一根主轴组织全部内容。

  • 第一段 · 开场(00:00–15:40):用 Facebook 扩张学校数据 做最简单的引子——两份表,一份是扩张批次事实表,一份是学校信息表。先做一道「各年月扩展学校数量」(单表能搞定),再加一道「各年月覆盖学生数量」(必须引入第二表)。这一步把观众引到分叉口:在引入第二张表时,关系和 Join 是两种不同路径。
  • 第二段 · 主体(15:40–39:17):切到 Tableau 官方 Bookshop 样例。

Bookshop 是 2020.2 同步推出的官方数据源,官方已经做好了模型——既有物理预合并(Book⋈Info 用计算字段 BookID=[BookID1]+[BookID2] 合并),又有逻辑关系层(Author / Edition / Sales / Award / Series 关系连接)。这一段落到三个关键开关——基数、性能选项、关系筛选——并明确「六个表不会预先合并到一起」。

  • 第三段 · 收束(39:47–47:49):临时引入 Library + Catalog。

这是一份只在视图层面用一次的数据,没必要放进模型——于是引入「混合(Blend)」,强调「混合是在右侧」(做完可视化、分组聚合之后再临时接入另一张表)。

  • 点睛(47:49–49:53):第二版书的分类框架——「unit × join 位置」——把全部合并方式收拢到一张二维图,并预告 Tableau 2026.2 的 composable data source(不在本期展开)。
课堂三段递进脉络
图 2 · 课堂三段递进:Facebook 开场 → Bookshop 主体 → Library 收束

二、第一段:Facebook 入场——「物理 vs 逻辑」

1. 问题驱动的引入

第一个题最简单:各年月 Facebook 扩展学校数量。单表里有 unit_id(学校唯一编码),countd([unit_id]) 即可解决——单表能搞定。

第二个题加一个度量:各年月覆盖学生数量。单表里没有 students 字段,必须引入「学校信息表」。

这一步的关键判断是课堂上反复强调的——

  • 「回到数据源,回到分析的前一个环节,用数据模型的方式弥补表的不足」:把"数据模型"翻译成"分析前的预处理 / 预计算"。
  • 「计算就是弥补你表中已有字段的不足」:当前表能算的,是计算;当前表算不出的,才去别处拿。

2. 逻辑模型(关系模型)登场

用关系(Relationship)引入第二张表——一根线、两边圆圈,是 Tableau 2020.2 起的标志性符号。演示两条题:

  • 选 students → 算覆盖学生数量;
  • 选 female / male → 做男女堆叠图(提示:堆叠易被覆盖,要用粗细 / 明暗分开)。

当场给出三条关键判断:

  • 「逻辑模型是按需合并,性能高又灵活」;
  • 「Excel 的 VLOOKUP 是真的合在一起,而我们这里是按需合并」;
  • 「不用的字段甚至可以连提取都不提取」——这是逻辑模型相对物理的最大性能优势。

3. 物理模型(Join)登场

复制一份数据,演示双圆圈 / Join;默认内连接改成左连接(外连接)的现场操作。

课堂上的关键警告:内连接会丢行——「如果选内连接,左边有右边没有的就被排除了,所以后面我们的数据中没有的那部分就没有了」。

由此给出一条金线:物理连接要预先预估你后面要的所有东西。又用 Facebook 数据跑了一次相同题目,把两次结果并列——肉眼可见的「合并 vs 按需」差异。

三、第二段:Bookshop 主体——「双层结构」

1. 为什么选 Bookshop

「Tableau 2020 年出关系模型的时候,同步出了一个非常好的数据集——图书商店(Bookshop),官方已经做好了模型」。Bookshop 既包含预先合并的物理层,又包含关系层,是双层结构最自然的演示样本。

2. 双层结构的具体形态

  • 物理层:Book 与 Info 用 BookID 预合并;Info 内部两个字段 BookID1 + BookID2 先用计算字段合起来。建议左连接(Outer / Left)——「书在 Info 中不一定有完整属性,但分析时要保留所有书」。
  • 逻辑层:关系覆盖 Author / Edition / Sales / Award / Series 等表。「123456 六个表,但是它并不会预先的合并到一起」——这是关系模型的关键论断:逻辑模型在物理上独立,在分析时按需联合。
  • 实测两题切换:
    • 「作者图书数量」→ 只用 Book + Author 两个表字段;
    • 「获奖图书数量」→ 自动切换到 Award 字段,「它在查询的时候,就只查询奖项字段和 Book Info 字段,其他表不查」——按需特性体现得淋漓尽致。

3. 三个关键开关

  • 基数(Cardinality):默认多对多;通过 COUNT([title]) 等字段实测,确认 Book→title 是唯一的,改成「一对一 / 一对多」关系。
  • 性能选项(Referential Integrity):「某些记录匹配」是默认值;改为「全部记录匹配」可让 Tableau 查询时假定两边都存在——但前提是业务上确实没有缺失(例如「获奖书必然在 Book 中有记录」)。
  • 关系筛选:关系模型保留全部数据,先在视图中用度量筛选或在关系上挂筛选器;课堂示例:「没获奖的排除空值」——直接挂筛选器即可。

Excel 完全没有这种多层关系能力,所以 Excel 是低阶的。

4. 一句话概括 Bookshop

「Bookshop 兼容了逻辑表和物理表」——一句话把整段教学立住。

例子嵌套:Check out 数量 → 通过 Book 关联 Award,Book 表只作为关联条件不出现在最终视图,但不影响分析结果。

Bookshop 双层结构
图 3 · Bookshop 双层结构:左侧暖色物理层(Book⋈Info)+ 右侧冷色逻辑层(关系连接)

四、第三段:Library 引入——把「混合(Blend)」补齐

1. 为什么需要混合

课堂原话:「混合重要在它是完成临时分析的神器」。

  • 「数据就做那么一两次用,你为了这一两次的分析需求做一个模型,反而显得太笨重」;
  • 「临时用,放到模型里第一数据泄露别人都知道了」——这是数据治理角度的反对。

2. Library + Catalog 数据演示

新数据 Catalog 字段:isbn / library_id / number_of_copies(某书在某图书馆的副本数)。

题目:获奖图书的 check-out 总数 + 图书馆在册数量。

操作流程:

  • 主模型保持不变;
  • 视图里临时拖入 Catalog,表上出现橙色标记表示来源外部;
  • 维度上挂 Catalog 字段,关系符号自动激活——「临时的握手」。

操作细节(演示细节):

  • 默认关联符号未激活,是因为视图字段还没拖进来;先拖字段、再点关联,是 Blend 的标准动作。
  • Excel 完全做不了:Excel 没有逻辑层,不能「先做透视、再连第二张表」。

3. 混合的关键特征

  • 「混合是在右侧」——左是视图(可视化侧),右是数据加工(分组聚合侧)。
  • 课堂定调:
    • 「关系是持久的,混合是按需的」;
    • 「关系稳定(字段谁和谁连必须事先确定),混合灵活(要什么连什么)」;
    • 「混合灵活到大部分人难以驾驭」——不推荐初学者作为首选。
  • 混合可叠加多张表(再建 Library Profiles 也是混合之一),但要混合到同一个主表。
  • 引出 2026.2 新功能 composable data source——发布后再做跨数据源关系——「今天太难了不讲」,给后续埋点。

五、收束:unit × join 位置

第二版书的核心思路——「unit × join 位置」:一个维度是合并方式(上下追加 vs 左右相连),另一个维度是合并位置(物理 / 预先 vs 逻辑 / 按需)。落到四格:

unit × join 位置 四格框架
图 4 · unit × join 位置四格框架:合并方式 × 合并位置 = 全部合并方式
  • unit × 物理:Excel 多表追加、Tableau 的并集(Union);物理操作,分析前已合并为单表。
  • unit × 逻辑:按需追加同结构表;Tableau Union(自动并集)。
  • join × 物理:Excel VLOOKUP / XLOOKUP、Tableau Join(内 / 左 / 外)、SQL JOIN——分析前真合并;要预先预估要的所有东西。
  • join × 逻辑:Tableau Relationship(持久 / 字段谁和谁连已定)+ Tableau Blend(按需 / 想要什么连什么)。

一句话收束:「从视图的角度讲都是合成一个,只是合并发生的位置不同」。

六、三句话带走

  • 「物理合并是分析之前做好恒定,而且真的合并了;逻辑合并是分析过程中按需处理」。
  • 「逻辑又分两种:持久的关系、按需的混合」。
  • 「Power BI 中按需的混合是用 RELATED / TREATAS 类函数实现的,所以更简单一点」——一个跨工具的小伏笔。

最后落到七期闭环:「模型 = 计算的高级形式 = SQL 的 JOIN,只是换了一种方式表达」——把"模型"接回到第6期"计算的类型",形成七期闭环。

结语:数据模型的体系与学习建议

  • 三段对应三种合并:Facebook 引出概念、Bookshop 演示结构、Library 演示混合——三段不可少,否则学生无法建立「位置」维度。
  • 关键词密度:逻辑 / 物理 / 按需 / 持久 / 关系 / 混合 / 基数 / 性能选项 / 多对多——九词反复出现,建议信息图与文字稿统一保留。
  • 学习建议:
    • 建议以 SQL 同步学习 Tableau 的关系模型(JOIN 对应 Join,子查询 / 视图对应 Relationship)。
    • 不建议同时学习 Power BI——Power BI 模型逻辑与此有差异,双修易顾此失彼。
    • 学习需投入时间——无论是付费课程还是个人时间,都需舍得投入方能获得真正的知识。
  • 配套书稿:《数据可视化分析》(第二版)第 4 章。

资源

作者:xilejun · v1.0 · 2026-09-05

No comments yet