上一章引入了模型这一概念——它是一种对现实的选择性简化。就像哈里·贝克为伦敦地铁设计的线路图那样，其他地图形式（如街道图和地形图）也存在，用于描述地理的不同方面。同样的原则也适用于数据库及依赖于数据库开展业务运营和分析的组织。
许多人认为建模只是记录数据库——画图表而已。但建模远远超出了表格和数据库的范畴，不仅帮助开发人员理解业务，还能帮助业务本身更好地理解自己。
从组织结构图到网络图，组织会使用各种模型和建模风格来应对其复杂性。尽管没有一种模型可以提供“完美的地图”，但某些模型可以在特定任务中充当“合适的地图”。本章将探讨各种建模类型，它们在不同的细节层次上用来绘制和导航业务及其数据资产。
虽然每种建模类型都有独立的章节进行详细探讨，但本章的目的是帮助理解每种建模过程的应用场景和原因，然后再进一步深入研究。
本章将涵盖以下主要主题：
- 将建模分解为流程
- 如何使用建模元素找到与业务团队沟通的通用语言
- 通过概念建模将业务模型与数据模型对齐
- 通过逻辑建模扩展超越数据库对象的业务概念
- 将逻辑模型转换为物理模型，创建数据库设计的蓝图
- 使用转换建模创建和管理提取、加载和转换（ELT）管道
设计与流程
多年来，许多关于建模和数据库系统设计的书籍被编写出来。然而，这些书籍往往未能将技术性与实用性结合起来，而这两者是不可分割的。建模书籍通常优先追求完整性（例如描述四种不同符号表达关系的方式），却忽视了可用性（例如，哪种符号对业务用户最友好？）。
数据库系统中最复杂的部分并不是技术，而是业务模型本身——业务内部的交互以及这些交互所遵循的规则。如果业务模型与数据模型不一致，数据库将不得不反复调整，进而丧失组织的信任和资源。
所需的是一种业务可读的语言，开发人员可以使用它来构建和记录数据库环境。
普遍建模
在定义数据结构之前，我们需要先理解生成这些结构的业务模型。这样的模型可以使数据库系统与业务流程保持一致，并能够预见变更的发生。就像从树木中看见森林一样，普遍建模让我们能够从数据中看见业务的整体。
一个业务有许多层次：从定义公司理念的使命声明，到销售交易，再到支持交易的物流，以及数据、元数据、分析等更多层面。然而，当大多数人想到模型时，往往只关注数据层，忽略了数据孤立时仅能讲述部分故事的事实。
实际上，建模过程涉及整个组织的团队，包括管理层、业务部门、数据团队和分析师。无论是否具备技术背景或领域专长，组织中的每个人都以某种形式参与建模（即使只是作为观察者）。建模时，务必要关注团队技能的差异，确保模型尽可能简单，同时包含完成当前任务所需的所有必要信息。
下图展示了在更广泛的业务背景下，人们通常所理解的数据建模：
仅依赖数据的教训：一个警示故事
管理团队要求你构建一个能够处理所有业务数据的模型。他们提供了示例数据 {0, 3, 6, 9}，并表示可以与你协作，确保你理解要构建的内容——你可以随意提问任何“是/否”问题。
问：12 在这个集合中吗？ 是。
问：21 在这个集合中吗？ 是。
太好了，你认为自己理解了这些数字，并构建了一个能够处理 3 的倍数的模型。
第二天，一个 -1 出现了，直接破坏了你的模型，因为实际的业务集合是所有整数的集合。
从 20 世纪 60 年代末开始，建模及其符号经历了多次变迁：从 Peter Chen、Charles Bachman 和 Richard Barker 的最初设计，到国家标准（如 Merise）和行业标准（如 IDEF1X、信息工程 (IE)、统一建模语言 (UML) 等）。众多符号体系，既没有明确的赢家，也没有统一的标准机构来裁决——难怪如此多人对此感到困惑。
以下是一组使用各种标准构建的数据模型拼图：
本书并非一本建模的百科全书，而是一本实用指南，旨在帮助您在 Snowflake 中应用建模概念，以确保效率、一致性和可扩展性。本章及后续章节将使用最易理解且简明的符号体系，使建模对数据工程师、开发人员、分析师以及业务用户都触手可及，同时遵循以下原则：
- 保持简单（KISS 原则） ：在建模（以及生活）中，最简单的方法往往是最好的方法。
- 简明扼要：避免冗长繁杂。
- 明确无歧义：同一约定绝不允许有两个含义。
- 拥抱行业标准：当行业标准有助于理解时，积极采用。
- 突破行业标准：在实用性优先的情况下，保持灵活，避免教条主义。
牢记这些原则，让我们从高层次视角看一下现有的建模类型及其应用场景。以下内容旨在对建模概念及其实施进行介绍，因此无需担心具体细节或术语，这些内容将在后续章节中详细讲解。
概念建模
建模的开始远早于数据库的创建，甚至早于数据的出现——它从业务本身开始。一个概念图应当既能够描述组织的运营模型，又能够为其数据库架构奠定基础。
概念建模是什么
概念建模是一个识别并直观映射业务操作中动态部分（或称实体）的过程。在深入之前，我们需要明确什么是实体：
实体：一个与业务相关的对象，可以是人、物体、地点、事件或概念，组织希望维护其信息。例如，许多公司常见的实体包括员工、客户、销售和商品。实体通常以单数形式表示，代表某一对象的类别或类型（第 10 章《数据库命名和结构》中将进一步讨论单数与复数命名的争论）。实体实例是此类或类型的具体出现：
- 超人（Superman） 是 SUPERHERO（超级英雄） 实体中的一个实例。
概念建模是业务团队与数据团队之间的协作发现过程，其成果是可视化的项目工件。在收集和存储实体相关数据之前，必须首先发现并达成对实体的共识。概念建模的目标是整合业务和技术团队之间的理解，生成的图表只是一个副产品。在概念建模过程中进行的讨论推动了组织的发展，并为后续的设计和分析阶段创造了价值。
由于业务团队可能对模型设计不熟悉，与数据团队的合作可能是他们首次以这种方式思考。这是积极的——当业务流程首次以明确、不含歧义的图表形式呈现时，可以揭示团队成员之间潜在的不一致，促使他们朝共同的理解靠拢。
例如，我们的业务是为餐厅里的顾客提供餐点，还是批量销售食材给餐厅厨房？如果是后者，是通过电话、网站、移动销售团队，还是以上所有方式？仅凭数据团队独立工作，可能无法明确这些问题。
属性和关系的发现
一旦领域专家确定了实体，接下来的分析会扩展到发现它们的属性和关系。
属性（或称特性）：与实体相关的描述性信息：
- SUPERHERO（超级英雄） 实体有一个 Birthplace（出生地） 属性，其值为 Krypton（氪星） ，对应于 Superman（超人） 实例。
例如，一个客户可能有姓名、地址、身高和驾驶证信息——但这些信息中哪些与我们的餐厅业务相关？是否还有其他未包含的相关属性？业务团队需要确认这些信息。
关系：实体之间的交互，通常用动词短语表示，例如 is、has 或 attends。关系的名称在图表中的关系线上标注：
- SUPERHERO has a SUPERHERO_TYPE
- SUPERHERO（超级英雄） 实体和 SUPERHERO_TYPE（超级英雄类型） 实体之间存在“拥有”关系。
业务团队还需确认实体及其关系的粒度：
粒度
-
实体粒度：单个实体实例的表示方式。
- SUPERHERO（超级英雄） 实体的粒度为单个英雄。SUPERHERO 中的一行代表一个独特的英雄及其属性。
- SUPERHERO_POWER（超级英雄能力） 实体的粒度为超级英雄的单项能力。SUPERHERO_POWER 中的一行代表超级英雄的一项能力。
-
关系粒度：实体之间关系的粒度，包括两个部分：基数和可选性。
-
基数（Cardinality） ：两个实体可以共享的最大实例数，可能为“一个”或“多个”：
- 一个 SUPERHERO 只能有一个 SUPERHERO_TYPE。
- 一个 SUPERHERO 可以有多个 SUPERHERO_POWER。
-
可选性（Optionality） ：关系是强制的还是可选的（例如，必须、可以或可能）。在此上下文中，“零”常被用作“可选”的同义词，例如“零到多”表示“可选的多对多”，但不要与基数混淆：
- SUPERHERO 必须有一个 SUPERHERO_TYPE。
- SUPERHERO 可以有，也可以没有 SUPERHERO_POWER。
-
总结粒度
当业务团队确认超级英雄必须归类为四种类型之一，并且可以拥有多个或没有超能力时，我们可以将实体之间的关系描述如下：
- SUPERHERO 必须且仅有一个 SUPERHERO_TYPE。
- SUPERHERO 可以有零个或一个或多个 SUPERHERO_POWER。
即使在这个简单的例子中，描述已经变得难以消化。但如果我们要在 Snowflake 中创建表以准确存储这些信息，我们必须能够系统地捕捉这些细微差别，而图表是实现这一目标的理想方式。
外观示例
定义概念模型时，更容易通过其不需要包含的内容来说明，而不是强调它包含的内容。与必须具备严格数据库特定精确度以实现可部署的物理模型不同，概念模型根据需要可以包含尽可能多或尽可能少的细节，以便从高层次视角查看和理解模型的细节。
概念模型至少需要描绘实体及其关系。除此之外，还可以包括一些细节，如属性、粒度，甚至一些逻辑特性。以下是我们在上一节中讨论的超级英雄模型的两个示例。
即使在抽象程度最高的情况下，概念建模在细节和表达形式上也具有灵活性，可以满足不同用例的需求。下面的模型展示了最低分辨率的情况——可能是在开发过程中发现阶段的样子，仅展示实体及其关系：
相同的设计可以通过添加描述来为不熟悉相关领域的受众提供额外的上下文信息：
在早期阶段，并不需要细节如数据类型或细化的属性。例如，列出一个地址属性即可，稍后再将其分解为街道、城市和邮政编码等组成部分即可满足需求：
新员工可以使用概念模型快速熟悉业务模型。同样，业务用户也可以依赖概念模型的简洁性，探索相关领域并了解其与自己熟悉领域的交互方式。
概念建模还可用于创建规划新设计的原型。类似于白板，概念模型捕捉早期阶段的想法，并随着变化和细节的引入不断发展。不像白板那样临时性强，概念模型如果在线维护在协作建模工具中，则更容易修改并与团队成员共享。
现在我们已经了解了概念模型的用途及其外观，是时候进入建模的下一阶段：逻辑建模。
逻辑建模
在通过概念建模识别出业务模型的构建模块（实体、属性和关系）后，逻辑建模便开始了。然而，逻辑设计和概念设计中使用的元素并没有严格的界限。事实上，许多数据库设计教材并未区分这两者，而是将其合并为一种风格，并在一个步骤中进行处理。
本书采用不同的方法——区分概念建模和逻辑建模，并不是因为它们的元素或符号，而是因为设计过程的自然流程。由于数据库教材通常面向技术读者，许多书籍忽略了数据库建模中非技术参与者的重要性：业务用户。
虽然逻辑模型可以表达概念模型中的所有内容，但它还包括许多技术细节，这可能会让那些缺乏相关基础的团队成员感到困惑。在初期阶段，领域知识比技术细节更为重要，因此根据受众不同，在两种建模风格之间切换可能更为有益。
与纸张或白板不同，建模工具允许您无缝切换不同的建模风格和符号，而不会影响底层对象。这使您可以根据受众选择适当的抽象级别。
让我们尝试理解这在实践中的意义。
逻辑建模是什么
逻辑建模是业务的概念运营模型与数据库物理结构之间的桥梁。它采用符号约定，为数据的性质提供比概念模型或物理模型更丰富的上下文。
逻辑建模通过增加描述关系元数据的符号来扩展概念模型，并结合了物理数据库设计的元素，例如数据类型和键。对于具有编程背景的人来说，逻辑概念如子类型和超类型可能已经很熟悉，但对于业务用户来说可能显得晦涩。
在逻辑建模阶段，还会引入数据库实现所需的技术细节，例如数据类型和键，但形式较为简化。逻辑建模与物理建模的区别在于，其技术细节并不特定于任何特定类型的数据库。
逻辑建模介于物理和概念领域之间，能够桥接两者，并表达纯数据库对象中难以体现的细微差别。
简而言之，逻辑建模帮助团队在与现有（或即将存在的）物理架构非常相似的模型基础上，理解业务的细微差别。
接下来，让我们看看在逻辑建模图中可能出现的一些逻辑专属元素。
外观示例
逻辑建模阶段包括诸如数据类型、唯一标识符和关系等细节，同时还引入子类型和超类型的上下文符号，以及多对多关系的表示。
子类型在逻辑图中用于表示继承。在超级英雄的例子中，SUPERHERO_TYPE（超级英雄类型） 可以基于 SUPERHERO（超级英雄） 的超类型创建子类型表。这样，共同的属性（如 SUPERHERO_NAME）可以被共享，而每个子类型独有的属性（例如外星救世主类型英雄的 IS_HUMANOID（是否类人） 指标）可以保存在各自的子类型表中。
以下是一个子类型关系的示例，其中关系既是完整的（用双平行线表示），又是排他的（用字母 X 表示）：
多对多关系 (M:M) 对逻辑模型来说是一项独特的挑战。在我们的超级英雄示例中，我们已经确定，一个超级英雄可能拥有许多能力（或者像蝙蝠侠一样，没有能力）。同时，一种超级能力（比如飞行）也可以被许多超级英雄共享（或者如果能力是让耳朵隐形，可能没有人拥有）。简而言之，多个超级英雄拥有多种超级能力。
问题在于，在物理数据库中，无法不重复两张表中的数据就存储这种信息：
要在物理数据库中表示多对多 (M:M) 关系，需要一个中间的关联表。尽管在逻辑设计中允许表之间存在 M关系，但它违反了本章前面提到的两个建模原则，因为它用两张表来表达三者之间的关系。
为避免这种混淆，我们借用了 Chen 符号中的菱形，用于标注 M
关系中的关联表：
在这里，观察者可以清楚地看到存在一个多对多 (M:M) 关系，并且需要一个第三张表（包含自己的独立属性）来捕获所需的信息。
一旦逻辑上下文被定义，便可以开始构建物理 Snowflake 模型的工作。
物理建模
第 1 章 《释放建模的力量》 中区分了“模型”一词的多种含义和应用，并指出其如何用于表示数据库表的物理结构及相关的可视化图表。物理模型包含构建和部署设计到特定数据库（例如 Snowflake）所需的全部信息。
这种转换也可以反向进行：许多建模工具和 SQL 集成开发环境（IDEs）可以直接从数据库的数据定义语言 (DDL) 中反向工程生成图表。通过反向工程，用户可以动态生成底层模式的可视化表示，以帮助他们探索关系。
这种转换究竟是如何工作的呢？
物理建模是什么
物理模型是将数据库部署到 Snowflake 的蓝图，也是帮助用户导航数据库的技术和操作链接的地图。
从逻辑模型向物理模型的过渡主要是系统化的（如将关系转化为约束、数据类型转换为数据库等效类型，以及定义数据库属性），但仍可能需要一些设计决策（例如对子类型进行汇总处理，这将在第 11 章 《将物理建模付诸实践》 中讨论）。这些决策通常取决于业务因素和未来的数据消费模式。
一些建模工具将逻辑模型和物理模型分为不同的项目，而其他工具（如 SqlDBM）则保持概念模型、逻辑模型和物理模型同步，让用户可以在无需转换的情况下以任意细节级别查看模型。
逻辑数据类型与 Snowflake 转换
为了方便从其他数据库平台迁移，Snowflake 提供了多种兼容数据类型作为其自有类型的同义词。例如，可以将列定义为 STRING 或 TEXT，但最终都会以 Snowflake 标准 VARCHAR(16777216) 创建。这意味着逻辑模型中常用的通用数据类型（如 STRING 或 INTEGER）可以直接使用，并在部署时自动生成对应的 Snowflake 类型。更多信息可参阅 Snowflake 数据类型文档。
物理建模是 Snowflake 部署之前的最后一步。尽管图表显示了数据类型和约束，更多的细节嵌入在对象中作为此阶段的一部分。例如，设置分区键、表类型和标识属性，并创建和分配支持对象（如序列和文件格式）。这些工作在新开发中完成，但物理建模也适用于现有的模式。
对于缺乏正式模型文档的组织，通过反向工程进行物理建模是创建模型的最直接方式。许多建模工具甚至可以根据命名模式检测，建议模式中尚未定义约束的关系。尽管这样做缺乏逻辑模型的元上下文，但与没有图表相比，已是显著的改进。
视图是什么情况？
到目前为止，我们探讨了与业务模型并行的数据库建模——将业务关键信息以实体、属性和关系的形式捕获和存储。然而，视图不存储任何数据，它们是以数据库对象形式存储的 SELECT 语句。例如，在事务型数据库中，如果没有底层 CUSTOMER 表，就无法通过视图构建 CUSTOMER 实体；但在数据仓库中，视图可以用来逻辑上统一多个 CUSTOMER 数据源到一个维度中。在这种情况下，视图不是 CUSTOMER 模型的一部分吗？当然是，并且应该在物理模型中可见。
不过，这种视图所使用的模型是转换型的，而非物理型的，其内容将在相应章节中探讨。遗憾的是，“逻辑”一词已被用来描述一类建模方式，无法用于表示基于逻辑的转换（如视图和 CREATE TABLE AS SELECT (CTAS) 表）。然而，我们必须遵循明确性的原则，即同一约定绝不允许有两个含义，因此我们只能按此定义处理。
物理模型的外观
物理图表与逻辑图表在外观上非常相似，但包含更多信息。尽管大多数建模工具中的显示选项是可配置的，但必须定义一些基本元素，如完整的列列表、数据类型和约束。然而，物理模型中的细节远超一次性展示的内容。图表中的每个元素（关系、表和列）都包含其自己的物理属性集，可单独编辑。
以下是超级英雄数据库作为物理模型的示例：
因此，物理模型仅向查看者展示可以直接转换为数据库的属性。正如之前讨论的那样，关系既是一种技术资产，也是业务操作性质的线索。即使在数据仓库中，其中大部分内容通过转换建模来定义，关系模型中概述的关系仍能提供关于连接和联接的信息，以确保转换过程的有效性。
转换建模
一切从 SELECT 开始。通过转换逻辑进行建模是一种功能强大且高度灵活的数据建模方法，但它有一个严重的缺点：它需要现有数据供 SELECT 使用。转换建模在事务型数据库中很少使用，因为在这些系统中，数据是通过公司的运营流程（例如购买和资料更新）创建和修改的，而这些关键系统资源不应被昂贵的转换过程占用。然而，在数据仓库中，经过标准化的数据集会被提取和复制，并为每次加载生成新的时间戳，转换建模因此成为一种必要手段。
由于转换建模是从现有的结构化数据中选择数据，因此结果集已经是结构化的。例如，选择 SUPERHERO_NAME 和 HAS_MASK 列并创建一个表，其结构（分别为 VARCHAR 和 BOOLEAN）将被保留。然而，与所有建模一样，转换过程也必须被适当记录，以便数据库用户能够理解由此产生的复杂数据环境。
什么是转换建模
与关系建模不同，转换建模不关注其存储数据的结构，因为它在创建过程中使用的是现有数据。相反，转换建模通过从现有数据源中选择数据来创建新对象。这通常通过视图、CREATE TABLE AS SELECT (CTAS) 命令或其他数据操作语言（DML）语句实现。
但转换建模不仅限于此；它还包括使用 MERGE 和批量 INSERT 操作来保持这些表中的数据更新。对于数据，联机事务处理 (OLTP) 数据库通常只持有一个单一的真实来源（最新的数据）。而联机分析处理 (OLAP) 系统根据其设计，与最新数据断开连接，必须按计划进行加载和同步。转换方法用于显示最新的变化。
OLTP 数据库通常用于操作型用例（如销售、预订或应用程序数据），主要进行对单个记录的创建、读取、更新和删除（CRUD）操作。而数据仓库则依赖转换建模来统一来自不同来源的数据，并根据不同的详细程度和聚合级别创建标准化数据的多个版本。
转换逻辑还被商业智能 (BI) 和仪表盘工具用来在构建可视化和总结信息时使用。这类工具通过在数据被拉取到屏幕（以表格和图表形式显示）时执行所需的联接和聚合，自动化了编写查询的工作。
由于转换以代码形式表示，那么我们可以通过转换建模可视化什么呢？
外观示例
对数据库逻辑复杂性的最佳抽象就是生成它的 SQL。本质上，转换逻辑就是 SQL。它包括用于创建并填充表的 CTAS 语句，也包括可能用于更新数据的 INSERT 或 MERGE 语句，或者这些语句调用的视图。
然而，就像可以通过反向工程从数据定义语言 (DDL) 生成实体关系图 (ERD) 一样，也可以从转换型 SQL 逻辑生成数据血缘图。与关系图不同，血缘图是低分辨率的，展示了 SELECT 语句中从源到目标的数据流。但如果没有配套的 SQL，导致表创建的细节就会丢失：
与其他建模图表不同——例如图片可以比 DDL 更清晰地讲述故事——转换建模在结合血缘图和可见代码时受益最大。这使得用户能够在深入了解逻辑细节之前，从高层次熟悉转换的输入和输出。
在概述、示例和用例中介绍了四种不同的建模风格后，让我们回顾一下学到的内容。
总结
正如本章所展示的，建模是一个用于达成共识、规划和开发数据库设计的过程，同时也是导航和探索数据库以更深入了解其业务背景的一种手段。无论是否被正式承认，每个新项目都必须经历四个建模阶段。即使是对于尚未充分记录的现有数据库，反向工程也是从数据库入手回溯其业务含义的一种有效机制。
设计旅程始于概念建模——这是一个协作的过程，涉及业务团队和数据团队共同努力，理解支撑业务运营的核心元素及其交互方式。概念模型强调简洁胜于细节，使其易于被各类背景的团队成员理解，并有助于引导讨论达成对业务模型的共同理解。
在概念建模之后，数据团队可以通过逻辑建模元素为图表添加更多的业务背景。逻辑模型类似于物理设计，但提供了业务细节，如多对多关系、子类型类和关系名称——这些都无法在数据库中直接表示。这也使得逻辑模型成为过渡到物理建模的理想桥梁。
物理建模 关注数据库特定的细节，以确保业务规则被正确捕捉，并采用适当的参数来保证性能的高效。由于实体、属性和关系已经通过概念和逻辑建模协作完成，物理建模的重点可以转向数据库的物理细节，定义数据库特定的属性。
转换建模 可以从物理模型作为参考地图开始，将数据重塑为最适合回答业务问题和驱动决策的数据格式（或格式）。尽管转换建模纯粹通过 SQL 逻辑完成，但如同所有建模类型一样，配套的可视化图表可以帮助加速复杂逻辑的理解和维护。
现在您已经了解了现有的建模类型及其应用场景，下一步便是学习如何应用它们。不过，在此之前，我们需要确保理解将要作为画布使用的 Snowflake 革命性云架构。在下一章中，我们将熟悉 Snowflake 独特的功能，这些功能使其成为市场上增长最快的云数据库平台，并了解如何利用这些功能优化成本和性能。
进一步阅读
技术团队与业务团队之间的有效沟通一直是公认的难题。在 《The Rosedata Stone》 一书中，Steve Hoberman 提供了一个指南，帮助在项目中创建精确的业务术语图表。业务术语模型是一种简单但强大的沟通工具，有助于弥合技术知识差距，并以业务团队的视角达成共识。
Hoberman, Steve. The Rosedata Stone: Achieving a Common Business Language Using the Business Terms Model. Technics Publications, 2020.
