在本书中，关系图被用来支持示例并以文字无法表达的方式阐明思想。尽管介绍了各种建模风格和符号，但我们尚未全面概述建模的视觉语义、各种元素及其属性。
在本章中，我们将完整讲解可视化工具包，帮助用户加速物理Snowflake数据库的设计与理解，并通过概念约定添加功能性上下文。通过简化且实用的方法，任何背景的用户都可以在最适合自己需求的细节层次上查看和探索数据库架构。
在本章中，我们将涵盖以下主要主题：
- 回顾建模风格和符号的历史
- 理解关系模型与其视觉表现之间的联系
- 学习如何描述不同类型的实体
- 探索如何在物理和概念层面表示关系
- 理解如何为物理表添加功能性上下文
- 发现如何简化各种建模约定，形成同步的建模实践
- 以适合技术和业务用户的方式进行操作
关系建模的历史
本书中的图表和示例依赖于关系建模来阐述数据库概念和构造。学习如何解析和通过关系图进行沟通，可以为数据库用户提供双重好处：让他们快速可视化并形象化复杂的数据库架构，同时使用可视化的认知辅助工具从头开始设计它们。然而，尽管有这些好处，许多数据库用户认为建模是一种晦涩的实践，在现代数据仓库中没有太大意义，并且将其误认为是一项繁琐的任务，而非真正节省时间的利器。
数据建模及其相关符号的实践经历了许多变化和发展趋势，但始终没有出现最终的标准，限制了它的普及。概念数据模型可以追溯到1960年代，当时Charles Bachman首次使用矩形表示记录类型，并用箭头表示它们之间的关系。到了该十年的末期，Edgar F. Codd正式化了关系模型（RM），并促成了我们今天所知的关系数据库的出现。通过使用关系模型，Codd成功地将与一阶谓词逻辑结构和语言一致的数学理论与数据库系统结合起来。不幸的是，Codd并不关注模型的视觉部分，也没有提供任何图表指导。
在70年代，计算机科学家如Peter Chen和Richard Barker扩展了Bachman的简单建模约定，增加了更多关于基础实体和关系的上下文。然而，这些设计并不足以推动广泛采用。尽管这些设计的单一元素获得了广泛应用——例如使用乌鸦脚符号描述基数——但任何一种图表风格的全面遵循都被证明过于限制，未能在可读性和技术细节之间取得平衡，导致其未能广泛采用。有些设计，包括Chen的原始ER格式，甚至可以说未能实现任何平衡。
以下使用Chen符号的图表试图描述一个由四个实体及其属性组成的简单关系模型（RM）。然而，由于视觉元素过多，它未能有效地传达这些内容。
为了有效地使用可视化图表，必须将模型（结构）与其呈现方式（图表）区分开来。数据模型的视觉表示可能会根据抽象层次的不同而有所变化，但它所表示的元素对应于真实世界中的业务实体，这些实体不应被重新解释。
关系模型（RM）与实体关系图（ERD）
回想一下，关系模型（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中的ERD的视觉线索，数据背后的上下文，例如COMIC_BOOK和SUPERHERO之间的多对多（M
）关系，瞬间显现出来——前提是观察者熟悉ERD使用的视觉语义。因此，让我们详细回顾这些元素，并演示如何使用一些视觉约定来表示各种技术和概念建模惯例。
可视化建模惯例
本章将重点介绍将在本书其余部分中使用的所有语义元素。如前所述，目前并没有一个固定的、普遍规定的标准来绘制建模图表。本书中使用的惯例及其伴随的视觉语义是作者尝试将广泛的建模概念和符号简化为一套核心元素，使用最广泛的符号来表示它们。书中的视觉语义并不遵循任何单一建模符号，而是自由借鉴了多个领先的行业标准。其目标是提供一种建模语言，既足够精确，能准确反映技术数据库细节，又足够简单，使业务用户能够理解超越技术规范的业务上下文。
与那些将概念、逻辑和物理模型分开，并迫使用户将一个模型转化为另一个模型的教科书不同，本书将使用一种使三者在整个建模过程中保持同步的惯例。这种方法最大限度地减少了在开发过程中维护模型一致性的工作量，并在不同的抽象层次提供了一致的视图。
考虑到这一点，让我们从描述数据模型核心元素——实体的符号开始。
描述实体
自建模早期以来，实体一直使用矩形表示。无论是在概念图上仅显示实体名称而不包含其他细节，还是在物理图表中列出属性、数据类型及其他信息，实体始终表示为矩形。
然而，建模语义确实区分了强实体和弱实体。当我们想到一个实体时，通常是指强实体——由其主键标识。然而，弱实体不能独立存在，它们依赖于另一个表中的属性来帮助标识它们。弱实体必须使用外键作为其主键的一部分，因为它们所包含的信息在孤立时没有意义。这种动态可以在图6.3中的SIDEKICK弱实体表中观察到，它只能与强实体SUPERHERO相关联才能存在。
以下图示展示了强实体SUPERHERO与弱实体APPEARED_IN的关系：
在图表中，实体被表示为矩形，其角落显示其强弱特性。强实体的角落为直角，而弱实体则使用圆角。
现在，让我们聚焦于实体内部的细节。在逻辑和物理建模中，实体包括关于其属性、约束和数据类型的详细信息。下图解释了实体内部的细节代表了什么。
现在我们知道如何绘制实体，让我们学习如何表示它们之间的关系。
描述关系
实体之间的关系用连接线表示。然而，关系传递的信息往往比一条简单的实线能够表达的更多。关系线还可以传达关于关联实体之间的基数和依赖关系的信息。这些细节中的一些完美地映射到物理数据库中，而其他则是概念性的和指示性的。本书根据上下文使用两种符号来表示关系。为了理解这些符号，让我们从常见的“乌鸦脚”符号开始，了解它如何表示粒度。
乌鸦脚符号
“乌鸦脚”符号得名于其三叉形状，类似于乌鸦的脚。每个“乌鸦脚”连接器的每一侧显示了关系的基数和可选性信息。
有两种基数选项（一对一或一对多），以及两种可选性指示符（必填或可选）。这给我们带来了四种可能的组合，如下图所示：
在逻辑/概念建模中，可以指定关系名称（也称为角色名称）以添加上下文。在指定基数时，请记住，它适用于关系的两端——这意味着关系可以从任一方向进行读取，如下例所示：
在逻辑/概念建模中，关系名称（也称为角色名称）可以用来添加上下文。在指定基数时，请记住，它适用于关系的两端——也就是说，关系可以从任一方向进行读取，如以下示例所示：
- 一个超级英雄有且仅有一个超级英雄类型
- 一个超级英雄类型可以对应一个或多个超级英雄
使用乌鸦脚符号，数据库建模人员可以捕捉实体关系中的最小和最大粒度的功能细节。然而，乌鸦脚基数并不能完全一一映射到物理设计中。当需要技术精确性时，物理模型更倾向于使用IDEF1X符号。
IDEF1X符号
IDEF1X（正确发音为 "eye-def-one-ex"，但通常缩写为 "eye-dee-fix"）符号是由美国空军在1970年代发明的。IDEF1X的吸引力在于它与物理数据库结构的映射非常紧密。使用IDEF1X符号定义的实体和关系可以清晰地转换为SQL，反之亦然。
注意
尽管IDEF1X标准确实包含特定的连接关系语法（例如，P、Z、n、n-m），但这种语法不易读取，且并未广泛使用。
与基数不同，IDEF1X符号关注的是关系的强实体或弱实体特性。强实体关系通过虚线表示，称为非标识性关系；而与弱实体的关系使用实线表示，称为标识性关系，因为它们需要来自强实体的主键来标识唯一实例。
由于IDEF1X符号与物理数据库属性紧密相关，它仅限于数据库直接支持的可选性选项。当子实体中的非标识外键可以为null时，连接器的父边会显示为菱形，而不是圆形。
在以下图示中，弱实体APPEARED_IN（用相应的圆角表示）通过实线连接到强实体。为了演示，SUPERHERO中的SUPERHERO_TYPE外键已更改为接受空值，因此导致SUPERHERO_TYPE边缘显示为菱形符号。
在第二章《四种建模类型简介》中，我们介绍了逻辑建模的概念，如多对多（M
）关系和子类型。M关系是特殊的，因为它们不能在物理数据库中直接创建，必须通过一个中介关联表来实现。子类型也有特殊的意义，它们不仅仅是子表，它们体现了实体类中的继承原则。为了确保这些上下文在物理数据库中不丢失，存在逻辑建模惯例来描述这些关系。
让我们扩展这些概念，理解如何在图表中显示它们，首先从M
关系开始。
多对多（M）
尽管乌鸦脚符号理论上允许表示M
关系，但在实际应用中，这种方法存在一个显著的限制：它阻止建模人员将他们的概念/逻辑模型与物理模型保持同步。
回顾一下，以下关系如果不使用关联表，在物理数据库中是无法创建的：
然而，通过借用Chen符号中的关系菱形来表示关联表，我们可以保持物理模型和概念模型的同步，同时保持模型中的必要上下文。
以下图示展示了在物理模型和逻辑模型中相同的M
关系。
现在我们知道如何保持M
关系的上下文，并确保逻辑模型和物理模型之间的一致性，接下来让我们分析子类型的符号表示。
表示子类型和超类型
在第二章《四种建模类型简介》中，我们看到子类型是如何在逻辑图中用于表示继承的。回顾一下以下图示，展示了一个SUPERHERO实体如何拥有四个子类型。
该图不仅将四个表识别为SUPERHERO的子类型，还为我们提供了关于子类型性质的上下文——即它是完整的（双平行线）且是排他性的（中央字母X）。让我们理解这些属性以及如何表示它们。
子类型关系具有两个二元属性来描述其性质：
- 完整/不完整：表示所有子类型是否已知，或者未来是否可以添加更多的子类型。前面的图示是一个完整关系的示例，因为所有四种超级英雄类型都已列出。
- 包容/排他：表示超类型是否可以作为多个子类型存在。由于一个超级英雄只能属于四种子类型之一，因此该关系是排他的。
这些属性可以通过混合使用IE和IDEF1X符号来显示。中央的判别符号可以显示为一个圆圈，或者字母D逆时针旋转90度。定义元素包括通过中间的字母X来表示排他关系，以及底部的单条或双条线来分别描述完整和不完整。以下图示展示了这四种配置：
现在我们已经介绍了如何在图表中描绘物理数据库，并将视觉上下文扩展到物理数据库能够存储的内容之外，让我们考虑如何利用我们在本章开始时提出的主要挑战：保持模型同步。
同步建模的好处
在本章中，我们看到了描述数据模型的图表示例，并捕捉了可能在SQL中没有严格对应的细节。通过将建模简化为其核心组件——其中许多组件甚至没有数据库设计正式背景的人也能理解——我们确保建模不仅仅局限于数据库团队。如你所记得，一个模型不仅描述了数据库本身，还描述了业务本身。
保持物理模型和概念模型的同步提供了另一个好处：模型可以在任何时候以不同的抽象层次查看，因为底层的物理元素保持不变。当需要更多细节时，用户可以以物理层次查看模型，如果他们希望以更抽象的方式查看模型，可以切换到概念视图。
为了说明这一点，图6.2中的各种图表并排显示，展示了如何根据需要将物理和概念元素混合搭配，以便进行分析。
总结
在本章中，我们回顾了关系建模的历史以及用于帮助可视化设计的各种符号风格。通过聚焦于这些建模风格最直接和最实用的语义，我们能够确定一种务实的方法，既保持技术精确性，又足够简单，使没有正式数据库设计背景的人也能理解。本书提出的建模技术保持了概念、逻辑和物理模型之间的实体数量同步，从而节省了手动工作量，并确保任何层次的用户都能查看相同的模型。
使用统一的建模约定列表，我们展示了如何以最简单的方式在关系图中显示实体。接着，我们介绍了关系符号，并展示了如何通过使用两种最流行的数据库建模符号——乌鸦脚符号和IDEF1X——传递更多的上下文信息，而不仅仅是简单的连接线。前者非常适合传达实体之间的粒度细节，而后者则使用简化风格，精确映射到物理模型。
我们还学习了如何超越物理模型能够显示的内容，并通过概念/逻辑建模约定（如子类型和M关系）为模型添加功能性上下文。
在之前章节中学习了如何使用建模工具包中的语义元素并掌握Snowflake架构和对象后，我们已经准备好开始正式的建模之旅，从概念建模开始。下一章将把概念建模过程拆解为简单、可重复的步骤，架起功能团队和技术团队之间的桥梁，使他们能够有效沟通，将业务流程转化为数据库设计。
