在本书中，我们始终借助关系图来支撑示例、阐释那些单靠文字难以说明的思想。虽然前文介绍过多种建模风格与标记，但对可视化语义、各元素及其属性的系统性综述尚未展开。
本章将跑通一套完整的可视化工具箱：既能帮助用户加速物理 Snowflake 数据库的设计与理解，又能通过概念层的约定为其增添功能语境。我们采用简化且务实的方法，让任何背景的读者都能按照最契合自身需求的细节层级来观察与探索数据库模式。
本章将重点讨论以下主题：
- 回顾建模风格与标记法的历史
- 理解关系模型与其可视化表达之间的联系
- 学会如何表示不同类型的实体
- 探索如何在物理与概念层面表示关系
- 了解如何加入功能语境，从而超越“仅有物理表”的表达
- 探索如何简化多样的建模约定，形成同步一致的建模实践
- 以同时适用于技术与业务读者的方式完成上述一切
关系建模简史（A history of relational modeling）
本书中的图与示例依赖关系建模来阐明数据库概念与构造。学会阅读与交流关系图，对数据库使用者有双重收益：既能快速可视化并“赋形”复杂的数据版图，又能借助视觉认知工具从零设计它们。尽管如此，许多用户仍把建模视为与现代数仓无关的“秘术”，把它误认为麻烦事，而非真正能节省时间的利器。
数据建模实践及其相关标记历经多轮变迁与分化，始终未形成终极标准，这也阻碍了普遍采纳。概念数据模型可追溯至 1960 年代：Charles Bachman 首次用矩形表示记录类型、用箭头表示它们之间的关系。十年末，Edgar F. Codd 形式化了关系模型（RM） ，奠定了我们今天所知的关系数据库。Codd 将与一阶谓词逻辑结构与语言一致的数学理论引入数据库系统。可惜他对模型的可视化关注不多，未给出制图规范。
1970 年代，Peter Chen、Richard Barker 等计算机科学家扩展了 Bachman 的简约约定，为底层实体与关系引入更多语境信息。
然而，这些设计都不足以促成广泛统一。某些元素（如用乌鸦脚表示基数关系）虽被普遍采用，但整套图法往往在可读性与技术细节之间难以平衡，过于限定，难以通行。某些方案（包括 Chen 的原始 ER 格式）甚至被认为两头都没兼顾好。
下图展示了一个用 Chen 标记试图描述由四个实体及其属性构成的简单 RM 的示意；但由于视觉元素过多，反而难以有效表达。
图 6.1 —— 使用 Chen 标记的 ER 图
要高效使用可视化图表，关键在于将模型（结构）与呈现（图）分离。数据模型的可视化表达可随抽象层级而变，但它所代表的元素对应的是现实世界的业务实体，这点不可随意被“再解释”。
关系模型 vs. 实体—关系图（RM versus entity-relationship diagram）
回顾：关系模型（RM）可从与业务相关的概念出发，映射为包含属性、标识符与关系的数据库模式。ERD（实体—关系图）则是用简洁、易懂的语义把 RM 可视化渲染出来。
下面我们重温第 1 章“释放建模力量”中的一组关系实体。在 RM 中，这三个实体各自对应一张由主键标识、并通过外键相互关联的表。仅凭表名甚至少量数据预览，很难看出这些关系，如下所示的 RM 所示：
SUPERHERO
---------
SUPERHERO_NAME|BIRTHPLACE |SUPERHERO_TYPE|HAS_MASK|
--------------+-------------+--------------+--------+
Ratman |Gotham Gutter|Accident |true |
Razor Tooth |Amazonia |Accident |false |
Galactoid |Krab Nebula |Alien |true |
SUPERHERO_TYPE
--------------
SUPERHERO_TYPE|
--------------+
Accident |
Tech Soldier |
Vigilante |
Alien |
COMIC_BOOK
----------
COMIC_BOOK_NAME |ISSUE_DATE|
------------------------------+----------+
BC Comics v4 |1978-04-03|
Tales from the Underground v3 |1985-12-23|
Tales from the Underground v24|1995-07-15|
BC Comics v103 |2015-06-19|
APPEARED_IN
-----------
COMIC_BOOK_NAME |SUPERHERO_NAME|
------------------------------+--------------+
BC Comics v4 |Razor Tooth |
Tales from the Underground v3 |Ratman |
Tales from the Underground v24|Ratman |
Tales from the Underground v24|Razor Tooth |
BC Comics v103 |Galactoid |
然而，ERD 能迅速将表背后的关联语境凸显出来，突出正在呈现的数据所对应的实体与关系。
图 6.2 —— 使用乌鸦脚表示关系的物理模型
得益于图 6.2 的视觉线索，诸如 COMIC_BOOK 与 SUPERHERO 之间的多对多（M:M）关系会一目了然——前提是读者熟悉该 ERD 所采用的可视化语义。接下来，我们将详解这些元素，展示如何仅凭少量可视化约定，就能表示广泛的技术与概念建模规范。
可视化建模约定（Visual modeling conventions）
本章将梳理本书余下部分会用到的全部语义元素。如前所述，绘制建模图并不存在一个固定且普遍规定的标准。这里采用的约定及其配套的视觉语义，旨在把广泛的建模概念与标记简化为一组核心元素，并用最常用的符号来表示它们。本文的视觉语义不完全遵循某一单一的建模标记，而是兼收并蓄多种业内主流标准。目标是在足够精确反映技术数据库细节的同时，也足够简明，让业务用户能理解技术规范背后的业务语境。
不同于把概念/逻辑/物理模型割裂开的教材、强迫用户在三者之间来回转换，本书采用的约定使你在建模过程中三者保持同步。这种做法能在开发推进时减少维护成本，并在不同抽象层次上提供一致视图。
基于上述理念，先从数据模型的核心元素——实体——的表示法开始。
表示实体（Depicting entities）
自早期建模以来，实体一律用矩形表示。无论是在概念图上仅展示实体名，还是在物理图上列出属性、数据类型与其他信息——实体始终画成矩形。
不过，建模语义会区分强实体与弱实体。我们谈到“实体”时，通常指由主键标识的强实体；而弱实体无法独立存在，需要依赖另一张表的属性来帮助识别自身。弱实体的主键中必须包含外键，因为其信息脱离上下文就不成立。这种关系可在图 6.3 的弱实体表 SIDEKICK 中看到：它只能依附强实体 SUPERHERO 而存在。
下图展示了强实体 SUPERHERO 与弱实体 APPEARED_IN：
图 6.3 —— 图中强/弱实体类型
在图上，实体用矩形表示，矩形的角体现其强弱：强实体用直角，弱实体用圆角。
接下来放大实体内部的细节。在逻辑/物理建模中，实体包含关于属性、约束、数据类型等信息。下图解释了实体内部各元素所代表的含义：
图 6.4 —— 实体内部细节示意
了解了如何绘制实体，下面学习如何表示实体之间的关系。
表示关系（Depicting relationships）
实体间的关系用连线表示。但一条实线难以承载全部语境：关系线还可以传达基数（cardinality）与可选性（optionality）等信息。其中一些细节可以直接映射到物理数据库，另一些则更偏概念/指引。本书按场景使用两种关系标记：先介绍更常见的乌鸦脚（crow’s foot） ，看它如何表达粒度。
乌鸦脚（Crow’s foot）
“乌鸦脚”得名于表示“多”的三叉符号。连接器两侧分别标明关系的基数（一/多）与可选性（必需/可选）。两种基数 × 两种可选性，共有四种组合，如下图所示：
图 6.5 —— 乌鸦脚关系类型
在逻辑/概念建模中，还可为关系指定关系名/角色名以增加语境。指定基数时，请记住它适用于关系的两端——关系可双向解读，如下例所示：
图 6.6 —— 读取乌鸦脚关系
读图顺序为：实体 → 关系/角色名 → 另一端连接器 → 另一实体。例如：
- 一个超级英雄拥有且仅拥有一个超级英雄类型；
- 一个超级英雄类型可被一个或多个超级英雄拥有。
乌鸦脚能刻画实体关系的最小/最大粒度等功能细节。但其基数并非总能一一对应到物理设计。当需要更高技术精度描述物理模型时，更适合使用 IDEF1X。
IDEF1X
IDEF1X（念作 eye-def-one-ex，常简作 eye-dee-fix）源于 1970 年代的美国空军。其优势在于与物理数据库结构高度贴合：用 IDEF1X 定义的实体与关系可无歧义地转换为 SQL，反之亦然。
说明
IDEF1X 标准包含一套专门的连接语法（如 P、Z、n、n-m），但可读性不佳、应用不广。
IDEF1X 不强调乌鸦脚的“基数”，而聚焦于关系的强/弱性质：
- 非标识（non-identifying）关系（指向强实体）用虚线；
- 标识（identifying）关系（连接到弱实体）用实线，因为弱实体需要引用强实体的主键来标识唯一实例。
同时，由于 IDEF1X 与物理属性绑定，其可选性仅限数据库直接支持的情形：当非标识 FK 在子实体中允许为空时，连接器的父端用菱形而非圆形表示。
下图中，弱实体 APPEARED_IN（以圆角表示）通过实线连接到强实体。为演示效果，将 SUPERHERO 表中的 SUPERHERO_TYPE 外键设置为可空，因此其指向 SUPERHERO_TYPE 的父端连接器显示为菱形。
图 6.7 —— 使用 IDEF1X 的物理模型
实体与关系介绍完毕，接下来扩展图上可呈现的更多语境信息，例如 多对多（M:M）关系与子类型等。
以概念语境补强 Snowflake 架构（Adding conceptual context to Snowflake architecture）
在第 2 章《四类建模类型概述》的逻辑建模回顾中，我们见到了 多对多（M:M）关系与子类型（subtypes）等概念。M:M 关系的特殊之处在于：如果没有中介的关联表（associative table），就无法在物理数据库中创建。子类型也不只是普通的子表——它们体现了实体类的继承原则。为避免这些语境在物理数据库中丢失，逻辑建模提供了相应的表示约定。
下面扩展这些概念，并了解用于展示它们的可选做法；先从 M:M 关系开始。
多对多（Many-to-many）
虽然乌鸦脚标记在理论上允许画出 M:M 关系，但在实践中存在一个重大限制：它会让建模者难以保持概念/逻辑模型与物理模型的一致。
回忆下图所示关系：若不使用关联系统的中介表，在物理数据库中是无法实现的。
图 6.8 —— 两张表之间的 M:M 关系
不过，如果借用 Chen 标记中的菱形“关系”来代表关联表，我们就能在保留必要语境的同时，让物理与概念模型保持同步。
下图展示了同一 M:M 关系在物理模型与逻辑模型中的同步表现：
图 6.9 —— 物理与逻辑模型中同步的 M:M 关系
理解了如何在逻辑/物理层面同时保留 M:M 的语境后，接下来分解子类型的表示法。
表示子类型与父类型（Representing subtypes and supertypes）
在第 2 章中我们看到，子类型常用于逻辑图中表示继承。回忆下图示例：SUPERHERO 实体可以拥有四种子类型。
图 6.10 —— 通过“判别符”符号展示的四个超级英雄子类型
该图不仅标识了四张表皆为 SUPERHERO 的子类型，还提供了子类型的语义属性：它既是完备（complete）的（底部双横线），又是**互斥（exclusive）**的（中央的字母 X）。下面理解这些属性及其标识方式。
子类型关系有两组二元属性：
- 完备 / 不完备（Complete / Incomplete） ：所有子类型是否都已确定，或未来是否还会新增。上图为完备关系，因为四种英雄类型都已出现。
- 包含 / 互斥（Inclusive / Exclusive） ：父类型实例是否可以同时属于多个子类型。由于一个超级英雄只能属于四者之一，因此该关系为互斥。
这些属性可混用 IE 与 IDEF1X 的标记来展示。中央的判别符（discriminator）图标可以画成圆形或将字母 D 逆时针旋转 90° 的形状。关键元素是：
- 中间的 X 表示互斥；
- 底部单/双线分别表示不完备/完备。
四种配置见下图：
图 6.11 —— 判别符符号的四种可能配置
我们已经说明了如何在图上描绘物理数据库，并如何将可视语境扩展到超出物理数据库可存储范围的部分。接下来，回到本章开头提出的核心挑战：如何让模型保持同步，并思考可利用的策略。
同步建模的收益（The benefit of synchronized modeling）
本章中，我们多次看到：图表可以描述数据模型，并捕捉那些在 SQL 中未必有严格对应的细节。将建模简化到核心组成（其中许多即便没有数据库设计背景的人也能理解），可以确保建模工作不被局限在数据库团队手中。请记住：模型描述的不仅是数据库，也描述业务本身。
让物理模型与概念模型保持同步，还有一大好处：由于底层的物理要素一致，模型可随时以不同抽象层级查看。需要细节时看物理层；需要宏观时切换到概念层。
为说明这一点，图 6.12 将多幅图并列展示，演示如何在分析时按需混搭物理与概念要素。
图 6.12 —— 并列展示概念、逻辑与物理模型中的要素
在不同模型之间保持实体一致，还带来额外收益：无需额外维护来保持同步。仅仅改变展示的细节层级，就不必为在不同风格之间转换或返工。
既然我们已经了解了建模标记的演进，以及如何以易读、易用的风格利用其中最相关、最有价值的元素，接下来回顾本章的实践要点。
小结（Summary）
本章回顾了关系建模的历史，以及用于可视化设计的多种标记风格。聚焦这些风格中最直接、最实用的语义，我们提出了一种务实方法：既能保持技术精度，又足够简单，便于无数据库设计背景的读者理解。本文倡导的建模技术让概念、逻辑、物理三层中的实体数量保持同步，从而节省人工并确保任意细节层级的读者看到的是同一个模型。
依托一份整合后的建模约定清单，我们展示了如何以尽可能简洁的方式在关系图上表现实体；随后介绍了关系标记，以及如何借助两种数据库建模中最常见的约定——乌鸦脚（crow’s foot）与 IDEF1X——在一条连接线之外传达更多语境：前者适合表达实体间的粒度信息，后者以简化风格实现与物理模型的一一对应。
我们还学会了如何超越物理模型的显示能力，通过概念/逻辑建模约定（如子类型与 M:M 关系）为图表加入功能语境。
在掌握了建模工具箱中的语义元素，并于前几章熟悉了 Snowflake 架构与对象之后，我们已准备好正式开启建模之旅，从概念建模开始。下一章将把概念建模流程拆解为简明、可复用的步骤，帮助业务与技术团队高效沟通，将业务流程准确映射为数据库设计。
