概念数据库建模是一种高层次的数据库设计方法，着重于捕捉业务实体及其相互关系。这种方法能帮助设计者更深入地理解数据，更容易识别设计中的潜在问题或不一致之处；同时也使数据库在未来变更中更具灵活性与可适应性，并让不熟悉数据库的人更容易理解与使用。归根结底，概念数据库建模有助于让数据库更高效地支撑组织的业务需求。
本章将采用 Kimball 的维度建模（DM） 技术，从零开始生成一个概念模型。该方法把数据团队与业务专家拉到一张桌上，从一开始就让数据库设计贴合业务流程的现实，从而避免后期代价高昂的返工。
不过，概念模型并不只用于新设计的起步——对既有物理模式，它同样具备上述所有优势。本章还将介绍一种简单方法：如何把物理设计改编为概念模型，并生成易读的图表，供业务与技术团队共同使用。
本章将涵盖以下主题：
- 认识 维度建模（DM） 及其应用
- 按 Kimball 的四步法构建 bus 矩阵
- 使用 bus 矩阵创建概念模型
- 从物理模式反向工程出概念模型
开始概念设计（Embarking on conceptual design）
在所有建模类型中，概念建模捕捉与展示的细节最少。这使其非常适合在宏观层面熟悉一套数据库版图，也适合从零进行设计。数据建模是经多轮迭代打磨的艺术——但如果你刚入门，该从哪里开始？
维度建模（Dimensional modeling）
2000 年代初，Ralph Kimball 与 Margy Ross 出版了划时代的《The Data Warehouse Toolkit》，几十年来始终是构建数据库设计的权威蓝本。本书后续章节中的许多术语、概念与技术都可溯源至这本“维度建模的权威指南”。
需要说明的是，Kimball 的方法并非创建概念模型的唯一途径。基于敏捷的 BEAM（Business Event Analysis and Modeling） 等方法（见本章末“延伸阅读”）也值得探索。不过，Kimball 方法广泛使用且被普遍认可，非常适合我们作为建模旅程的起跳板。
理解维度建模
DM 是一种由来已久的技术，其核心是让数据库对齐业务流程，以保持简单——这一定律你现在应已熟悉。尽管“简单”二字听上去朴素，DM 涵盖的话题很广：从业务需求研讨会，到事实表/维度表的类型，再到各行业的建模最佳实践。
本章聚焦 DM 的早期阶段：数据团队如何与业务专家协作，识别支撑概念模型的维度与业务流程。但在深入之前，需要先澄清一些观点。
为维度建模正名（Setting the record straight）
- 质疑 1：Snowflake 等平台计算便宜又易扩展，DM 的严谨性已“过时”。
回应：无稽之谈。像 Snowflake 这样的按量计费平台若不加控制，成本会迅速膨胀。把设计建立在久经考验的框架上，反而有助于控成本。 - **质疑 2：**dbt 等分析工程工具让开发加速到“边建边修”比 DM 更快。
回应：工具确实加速交付，但没有牢固基础只会更快地犯错。例如 dbt 的快照用到 Kimball 的 SCD Type 2，有效使用仍需理解其原理。 - 质疑 3：Kimball 已过时，Data Vault 等更易扩展。
回应：诸如 Data Vault 2.0（本书第 17 章）确实高可扩展且有效，但并非万能，而且依然要理解并落实 DM 概念（例如卫星表本质上也是 SCD Type 2）。
最后需要强调：本书并非主张 DM 必须作为数据库/数仓设计的唯一主框架。而是因为 DM 的对象与语言已渗透到数据库设计之中，了解其规则与基础、并知道何时/何处偏离它，非常重要。
基于此，我们来看看如何用 DM 原则来启动概念模型，或用同样的方法验证现有的物理设计。
四步开启概念模型（Starting a conceptual model in four easy steps）
本节回顾 Kimball 的四步法：通过识别业务流程与维度来创建概念模型。请牢记：概念/数据库建模的目标，是尽可能贴合业务运行的现实。因此，这个阶段需要业务团队高度参与，共同确定未来技术实现的概念基石。
为演示实际过程，我们将使用 SNOWFLAKE_SAMPLE_DATA.TPCH_SF1 模式中的表来代表一个真实的零售组织。为便于理解目标形态，你可以在 Snowflake UI 中浏览这些样表，或参考本练习最终得到的物理示意图（图 7.1）。
图 7.1 —— Snowflake 示例 TPC-H 模式的物理模型
在逐一展开前，先列出 Kimball 在概念层启动 DM 的四步：
- 定义业务流程（Define the business process）
- 声明粒度（Declare the grain）
- 识别维度（Identify the dimensions）
- 识别事实（Identify the facts）
建模从与业务域专家和部门干系人组织工作坊开始，以回答上述四点。在这里，业务现实被讨论、正式定义并达成共识，以便其相关数据得以建模与采集。务必让所有人明白：尽管讨论处于高层语义，这些结论随后将直接决定数据库细节、业务规则与治理逻辑——这些内容在后期往往极难改动。
研讨中形成的结论与决策应被视为业务与技术团队的“契约” ，后续将据此推进实现。
在进入 ER 图 之前，调研会中采集的信息会被整理到 Kimball 所谓的 “bus 矩阵” 中：每一行代表一个业务流程/主题域，每一列代表一个维度或事实表；它们的交叉构成组织内的关系/交易。
接下来，我们将按这四步推进，看看 bus 矩阵如何逐步展开并指引模型发展。第一步：与领域专家一道，识别 TPC-H 组织中存在的业务流程。
定义业务流程（Define the business process）
正如电影《上班一条虫（Office Space）》里那句名台词问的： “你觉得你在这儿是干啥的？” 对某个组织而言，答案或许听起来很简单，比如卖商品、接预订。但一旦把采购、库存、促销、取消等活动也纳入考量，现实通常要复杂得多。
回忆建模的首要目标：捕捉我们要跟踪、度量与分析的相关指标与属性。可以把业务流程理解为企业运作中天然发生的交易（transactions） 。在维度建模（DM）里，交易称为事实（facts） ，而记录这些交易并（几乎总会）配对指标的表叫作事实表（fact tables） （稍后详述）。
以公司的主要职能（如销售、注册、制造）为起点，将讨论扩展到支撑性职能（如补货进货、仓储备货、供应商合同）——直到每个部门都发声，其相关的运营流程都被编目为止。
这些会议产出的清单将构成 bus 矩阵的左侧。在 TPC-H 的示例里，这份清单可能如下所示：
图 7.2 —— 之后将构成 bus 矩阵的业务流程
当业务流程识别完毕，接下来要更进一步，确定它们可分析的最低粒度。
确定粒度（Determine the grain）
上一步我们罗列了构成业务流程的运营交易。这些交易将在待设计的数据库中变成事实表。但每一行究竟代表什么？例如，公司的核心职能也许是销售零件，那我们记录/分析该交易的粒度是按零件还是按客户？或者取决于业务单元，有时是其一，有时是其二？
要回答这个问题，我们需要确定粒度（grain） ——对每个业务流程而言，实现有意义分析所需的最低明细层级。通常推荐选择业务流程本身采集到的最低层级，即原子粒度（atomic grain） 。让设计立足于原子粒度，意味着它可承载后续任何向上汇总与聚合。如此一来，业务需求的变化也不必改变模型，因为模型已包含业务流程记录的最大细致度。
选择粒度时，还必须确保不同粒度不会混装在同一张事实表里。比如，以“每日交易”为粒度维护的销售事实表，不应包含“月度/年度总计”。否则每记录一笔交易，就会导致对整表进行代价高、低效的更新。
关于粒度的讨论会自然引出参与运营的实体：客户、供应商、零件等。这些信息将帮助我们确定 bus 矩阵的另一半。
确定维度（Determine the dimensions）
围绕业务流程的讨论中浮现出来的实体，为业务的性质提供语境。实体帮助回答谁、什么、在哪里等问题，并常包含进一步描述性的属性。
在我们的例子中，讨论可能从销售开始，顺理成章地涉及被售出的零件、提供该零件的供应商、存放现货的仓库，直到所有相关实体都被识别出来。这些实体（在口语中常对应单数名词），将在我们构建的数据库中成为维度表，并承载需要定义与建模的属性。
识别出若干关键维度（如客户、订单、零件）后，我们可以绘制 bus 矩阵的另一条轴。下图展示将业务流程与其组成维度并列后的网格：
图 7.3 —— 含业务流程与维度的 bus 矩阵
注意，日期维度通常是首先命名的。诸如销售、数据流、登录等事实至少关联一个需要记录的时间维度（也存在无度量事实表的情况，后续章节会介绍）。
当所有维度识别完成，就到敲定事实、完成 bus 矩阵的阶段了。
确定事实（Identify the facts）
在 DM 中，事实被定义为：在业务维度之间发生的交易，配以相关度量（metrics）的表。度量记录与事实表粒度相匹配的信息，而事实表的粒度由其相关维度共同决定。在 bus 矩阵里，可以直接在“业务流程 × 所需维度”的交叉点打 X，来映射这种关系。
在我们的例子中，完成的 bus 矩阵可能如下所示：
图 7.4 —— 将业务流程映射到参与维度的 bus 矩阵
借助该矩阵，我们可以回到先前关于销售粒度的问题，检查答案是否合理。问题看似技术性的，答案却始终由业务驱动。也许销售的原子粒度包含：发生的日期时间、被购买的客户与产品明细，以及围绕交易的价格、数量、折扣等指标。业务团队或许希望在客户层级跟踪总销售与取消，在零件层级审视利润率与折扣。只要我们在设计中按原子粒度捕捉这些要素，就能按需构建相应的表来满足业务诉求。
在后续的建模阶段，出于性能与维护考虑，原子事实之上可能会派生出多个汇总表；但在概念层的分析已经足以容纳此类决策。
打好了事实与维度的基础之后，接下来把 bus 矩阵以概念模型的方式可视化起来。
从 Bus 矩阵到概念模型（From bus matrix to a conceptual model）
既然我们已与业务团队一道完成并达成一致的 bus 矩阵，现在就可以把这些细节迁移到概念图上。流程的第一步是：把各维度作为实体创建出来。通常，在业务研讨中也会识别出最相关的属性，它们也可以纳入模型。但为使练习步骤更清晰，我们将把这部分放到下一章（逻辑建模）再展开。
仅包含维度时，图示大致如下：
图 7.5 —— 仅展示维度的概念模型
在实体就位后，我们就能创建事实表，并按研讨中确定的关系与业务规则将其连接起来。此时，模型已经包含 bus 矩阵中列出的全部事实与维度，如下图所示：
图 7.6 —— 由 bus 矩阵生成的概念图
请注意：虽然矩阵里列了五个业务流程，但图中仅建模了两个事实表。这很常见——同一张事实表往往细节足够覆盖多个业务流程；例如客户销售与退货，因为它们发生在相同的粒度上。
通过提出若干业务导向的问题，我们已经学会如何确定公司各项运营的粒度，并识别相关的事实与维度，最终汇总进 bus 矩阵。基于矩阵中的信息，可以轻松生成概念图，并把它作为后续建模步骤的基础。同样地，概念模型不仅可用于发起数据库设计、形式化既有业务流程，也可以反向用于校验现有的物理设计。
反向建模（Modeling in reverse）
现实中的企业级业务系统与数据仓库可能极其复杂，尤其在经历多年演化、吸收了无数值得商榷的设计决策之后。即便是资深数据团队成员也未必能解释每个细节，更别说新入职的同事或业务分析师了。好在，概念建模既能帮助我们从零开始设计，也能同样快速地简化并可视化现有的数据库版图。
数据库建模工具通常支持将模式定义（DDL）导入并生成相应图表，这一过程称为逆向工程（reverse engineering） 。由于表结构与约束已在数据库中定义，生成 ER 图并呈现数据库版图只需数秒。因为逆向工程基于 Snowflake 对象的 DDL，它产出的是物理模型。物理模型在各类模型中细节最丰富，因此很容易抽象成概念模型。大多数从物理到概念的步骤可以由建模工具自动完成；即便手工完成，只要倒着遵循“四步法”，也并不费力。
我们要做的是：从“现状”走向“应然” 。后者无法从数据库本身得出，必须通过与业务团队的研讨与讨论来验证。本练习的目标，是基于“现状”推导出一个最佳猜测的概念模型，以便促进这些讨论。先从给现有表贴标签开始。
识别事实与维度（Identify the facts and dimensions）
从现有物理模式中的表入手，按前文的经验法则把它们归类为事实与维度。维度表通常以单数名词命名，包含描述性属性，而非数量度量；事实表往往以及物动词命名，包含度量以量化每笔交易。
在我们的示例中，这一步的结果大致如下图所示：
图 7.7 —— 从物理模型中识别出的事实与维度
实体映射完成后，下一步是识别它们的关系。
建立关系（Establish the relationships）
能否快速识别表间关系，取决于物理模式是否遵循了标准与最佳实践。例如，若已声明主键与外键（FK） ，建模工具就能自动据此建立并可视化所有关系。
如果没有这些约束，就需要依赖列命名约定来推断关系。先从维度表着手，查找类似表名且暗示其为主键的列（如包含 id、key、code 等）。例如，NATION 维度中的 N_NATIONKEY 很可能就是主键。可用 GROUP BY ... HAVING 检验：若它是 PK 且数据干净，则不应出现计数大于 1 的结果：
SELECT N_NATIONKEY, COUNT(*) AS CNT
FROM NATION
GROUP BY 1
HAVING CNT > 1;
请记住：即便数据也无法最终证明哪一列应该是 PK，它只能指向高概率候选。只有业务方才能最终确认业务维度的粒度。
为各维度提出 PK 候选后，继续在事实表与其他维度表中寻找这些 PK 列的出现位置。在 DM 中，跨多张表结构与含义一致的列称为一致维（conformed dimensions） 。例如，若 CUSTOMER 表中的 ID 与 SALES 表中的 CUSTOMER_ID 数据类型与取值一致，则它们构成一致维。当维度内的单个属性在多表间保持一致时，则称为一致属性（conformed attributes） ；例如，STAR_RATING 可能同时出现在 PRODUCT 和 SUPPORT_SURVEY 中。一致的列命名对这类分析极为有利，建模工具也依赖一致属性的命名来自动建议 FK。
识别出关系后，尝试确定它们的基数（cardinality）与可选性（optionality） 。表约束能给出一些线索，但只有业务团队能确认业务现实（数据可用作参考指标）。下图展示了：同一物理约束在概念层面可能存在多种解释：
图 7.8 —— 一个物理关系的多种概念表示
当我们识别出全部实体与关系，并对其基数作出有根据的判断后，就完成了概念模型草案，其外观大致如下：
图 7.9 —— 由物理模式抽象出的概念模型
借助该概念模型（对既有数据库设计的清晰可视化），我们就能与各业务域团队（对其业务流程与维度负责）展开对话，验证已构建的内容。
提出并验证业务流程（Propose and validate the business processes）
即使模式相对较小，给表与关系归类与识别也并不轻松。我们已用概念图简化地展现了业务模型的愿景，接下来必须与业务团队与产品负责人共同验证。回忆：同一张事实表可能覆盖多个业务流程，而识别这些流程离不开业务输入。
在业务负责人与领域专家的反馈基础上，可调整与细化概念模型，使之真实反映业务运行。若业务与数据库模型随时间出现偏离，概念评审甚至可能反向推动物理模型的修改。
无论哪种情形，现在我们都拥有一个清晰且准确、与所支持业务完全对齐的概念数据库模型。它能帮助分析师与新同事快速熟悉业务。在完成验证之后，应按本章描述的流程持续维护该概念模型。
至此，我们既看到了如何用 Kimball 方法正向生成概念模型，也看到了如何从物理数据库出发逆向推导。下面对所学内容作一番回顾。
小结（Summary）
本章展示了概念模型及其配套图表如何让组织的业务模型一目了然，并便于与领域专家对照预期的业务运营进行验证。
为开启概念建模，我们采用了沿用数十年的 Kimball 维度建模（DM） 方法来指导数据库与数据仓库架构设计。Kimball 的四步法促成数据团队与业务团队、领域专家之间的讨论，从而识别组织所从事的业务流程。
在识别业务流程后，我们进一步确定其粒度，即与业务相关的最低明细层级。明确粒度也有助于我们发现业务的核心维度。将维度与业务流程绘制到称为 bus 矩阵 的图表上，可以得到业务的一个优雅切面，并将其细节便捷地迁移到概念图中。
受益者不只是新设计。概念模型同样可用于可视化并验证一套物理数据库。建模工具可通过逆向工程，从现有 DDL 自动生成物理图；或者，建模者也可以反向应用 Kimball 四步法，从物理数据库出发推导出概念模型。
由于初始设计或长期演变，物理数据库可能偏离组织的实际业务模型。概念图为与业务团队对齐物理与业务模型提供了重要工具：它为非技术用户提供了一种直观理解既有建设成果的方式，从而推动沟通。
当然，数据团队与业务团队的协作不止步于概念模型。在下一章中，我们将在此基础上补充功能性细节，并为模型的物理落地做好准备。
