)
1. 数据建模方法
1.1. 数据建模是一种高级概念技术，用于设计数据库
1.2. 涉及识别需要存储的数据，然后创建这些数据及其之间关系的结构化表示，并将其组织成表格和列
1.3. 将这些表格和列视为数据库的逻辑表示，而存储在这些表格和列中的物理数据可以位于关系数据库产品或数据湖中
1.4. 将数据建模应用于任何类型的数据库：关系型、维度型、非关系型等
1.5. 将大量时间花在数据建模上，以确保数据库逻辑性强、高效且易于使用，从而最大限度地提高性能，并使数据的检索和分析变得更加容易
1.6. 没有一种模式可包打天下的。安全性、数据大小和性能等各种因素都可能造成模型的修改
2. 关系建模
2.1. 关系建模是由Edgar F.Codd于1970年开发的一种建模技术，用于设计数据库
2.1.1. 将数据组织成表并定义这些表之间的关系
2.1.2. 每个表由行（也称为记录或元组）和列（也称为字段或属性）组成
2.1.3. 每一行代表数据的一个唯一实例，每一列代表有关数据的一项特定信息
2.2. 键
2.2.1. 在关系建模中，可以使用主键和外键来定义表、行和列之间的关系
2.2.2. 主键是表中每条记录的唯一标识符，主键的值不能重复，即任意两行数据不能具有相同的键值
2.2.3. 外键是表中引用另一表中主键的列
- 2.2.3.1. 用于在两个表之间建立关系，以确保数据的完整性
2.2.4. 自然键是表中已经存在且具有唯一性的字段
- 2.2.4.1. 在关系建模中，自然键通常用作主键
2.3. 实体关系图
2.3.1. 从实体关系(ER)图开始关系建模：这是数据库的高层次视觉结构，表示实体（数据）及它们之间的关系
2.3.2. 实体关系图中使用框表示实体，使用连接线表示关系
2.4. 规范化规则和形式
2.4.1. 应用规范化规则将复杂数据库分解为更小、更简单的表
2.4.2. 可以最大限度地减少冗余和依赖性，提高数据完整性，并使数据库更加高效、更易于维护和管理
2.4.3. 第一范式(1NF)
2.4.3.1. 该表有一个主键
2.4.3.2. 表中每个属性都只包含一个单一值，而不是一个值列表
2.4.3.3. 表中没有重复的列组
2.4.4. 第二范式(2NF)
2.4.4.1. 第一范式(1NF)
2.4.4.2. 数据库记录中的每个细节（非主键属性）都必须完全依赖于其唯一标识符（主键），而不能依赖于任何其他细节
2.4.5. 第三范式(3NF)
2.4.5.1. 第一范式(1NF)
2.4.5.2. 第二范式(2NF)
2.4.5.3. 表中的每个非主键属性都应该直接与主标识符（主键）相关，而不是通过另一个属性间接相关
2.4.5.4. 大多数关系模型，尤其是用于OLTP数据库的模型，都符合第三范式
2.4.6. 使用规范化的数据库模式，数据存储在一个地方，并组织到多个表中，这些表之间有严格定义的关系
2.4.7. 有助于确保数据的完整性，但也可能会增加查询的时间，因为数据库可能需要连接多个表以检索所需数据
2.5. 跟踪变更
2.5.1. 对于关系型建模的数据，追踪其随时间的变化至关重要
2.5.2. 为了保留过去的数据和变更记录，通常会使用历史表
2.5.3. 历史表通常是原始表的副本，并添加了额外的列来追踪变更
2.5.4. 历史表在审计、报告和数据恢复方面非常有用，有助于确保数据的完整性，并更容易理解数据是如何随着时间的推移而变化的
3. 维度建模
3.1. 始于1996年，旨在通过将数据组织为事实和维度来支持高效的查询和分析
3.2. 当基于关系模型的查询和报告变得过于缓慢或复杂时，就需要使用维度模型
3.3. 通常以关系模型作为数据源
3.4. 事实
3.4.1. 在维度建模中，事实是指用于衡量某些事物的数据片段，通常是数值
3.4.2. 出于性能考虑，事实可以被聚合或汇总
3.4.3. 事实表包含度量值
3.5. 维度
3.5.1. 维度描述了数据的特征
3.5.2. 通常表示为层次结构，每个层次都提供了对数据更详细的描述
3.5.3. 维度表包含事实表中度量值的属性
3.6. 维度建模使用代理键，代理键是专门创建（通常是自动生成）的人工值，用作表的主键
- 3.6.1. 当没有自然键或者自然键不适合用作主键时，通常会使用代理键，这种情况在维度建模中非常常见
3.7. 自然键通常比代理键更有意义且更易于理解，因此可以使数据库更易于使用和维护
3.7.1. 与简单的代理键相比，自然键往往更长更复杂，因此在实际应用中会带来更多挑战
3.7.2. 自然键通常包含敏感信息，可能会引发隐私问题
3.7.3. 自然键可能会由于潜在的重复和格式不统一而带来挑战
3.7.4. 在合并或跨系统比较数据时，重复可能会成为问题，而格式不一致则进一步增加了集成过程的复杂性
3.8. 跟踪变更
3.8.1. 使用缓慢变化维(SCD)追踪对表的更改
3.8.2. 类型1
3.8.2.1. SCD会用新数据覆盖现有数据并丢弃旧数据
3.8.2.2. 是最简单、最常见的SCD类型，通常用于数据的更改不太重要或者不再需要旧数据的情况
3.8.3. 类型2
3.8.3.1. SCD会保留数据的多个版本：新数据和旧数据的记录
3.8.3.2. 当需要跟踪数据随时间的变化并保留旧数据记录时，可以使用此类型的SCD
3.8.4. 类型3
3.8.4.1. SCD针对每一次数据变更新增一个字段列，仅保留有限的历史记录
3.8.4.2. 是最复杂但也是最灵活的
3.9. 关系建模中的历史表与缓慢变化维之间的一个关键区别在于它们的详细程度
3.9.1. 历史表在单个记录的层次上跟踪数据变化，而缓慢变化维在维度层次上跟踪变化
3.9.2. 历史表通常用于跟踪任何类型数据的变化，而缓慢变化维专门用于跟踪维度模型中维度表的变化
3.10. 反规范化
3.10.1. 即在多个表中包含数据的冗余副本，这种做法减少了表的数量
3.10.2. 在查询数据库时，系统不需要连接太多表，因此查询速度会快很多
3.10.3. 减少连接也降低了最终用户创建报告的复杂性
3.10.4. 意味着必须确保冗余数据副本的同步以确维护数据的完整性，这需要小心仔细地维护
3.10.5. 冗余数据也会占用更多的存储空间，可能会略微增加成本
3.11. 关系模型中的表越多，维度模型的作用就越明显
- 3.11.1. 关系模型中只有少数几张表，可能就不需要维度模型
3.12. 数据库模式是一个逻辑蓝图，它概述了数据库中数据的结构、关系、约束以及其他元素，说明了数据是如何组织和关联的
3.12.1. 在维度建模中使用了许多类型的模式，例如雪花模式和多事实表的模式
3.12.2. 星型模式是一种维度建模技术，它以一个中心事实表为核心，周围环绕着多个维度表
3.13. 关系模型捕捉的是部分业务运作方式的业务解决方案，而维度模型捕捉的是业务所需的细节，以回答有关业务运作情况的问题
- 3.13.1. 如果源系统已经是关系型的，则关系型模型更容易建立，但对于业务用户来说，维度模型更容易使用，而且通常在分析查询时性能更好
4. 通用数据模型
4.1. 通用数据模型(CDM)是一种标准化的结构，用于存储和组织数据，通常在构建数据仓库解决方案时使用
4.2. 提供了一种一致的方式来表示表内的数据和表间的关系，使系统和应用程序易于理解数据
4.3. 如果你自定义了一个新的模型，就可以节省建模的时间，降低风险，并使组织内的所有应用程序都能使用通用语言访问数据
5. 数据保险库
5.1. 是由Daniel Linstedt于2000年创建的，专门用于数据仓库和商业智能系统
5.2. 主要目标是提供一种灵活、可扩展和标准化的方式来对历史数据进行建模和管理
5.3. 中心表(Hub)
5.3.1. 是模型中的核心业务实体，代表客户或产品等关键业务概念
5.3.2. 该表通常建模为一个表，该表具有唯一标识符（如主键）和一组属性
5.4. 链接表(Link)
5.4.1. 是中心表之间关系的模型，通常作为一个单独的表
5.4.2. 包含了一组外键，引用相关中心的主键
5.5. 附属表(Satellite)
5.5.1. 存储有关中心表或连接表的描述性属性，如数据随时间的变化
5.5.2. 通常被建模为单独的表，并通过外键链接到中心表或链接表
5.6. 基于数据仓库的模型可跟踪数据的流向、审计数据并执行规则和标准
5.7. 通常与其他数据建模技术（如维度建模）结合使用，以提供一个全面、灵活的数据架构，并能与其他系统和应用程序轻松集成
5.8. 数据保险库介于3NF数据和星型模式之间
5.9. 非常适合数据量大、数据关系复杂的组织
5.10. 缺点
5.10.1. 复杂性
5.10.1.1. 数据保险库建模实施和维护可能会很复杂，特别是对于不熟悉该技术的组织
5.10.1.2. 需要大量的资源和专业知识投入，如果没有适当的文档，理解和浏览数据模型会很困难
5.10.2. 数据重复
5.10.2.1. 通常会导致数据重复，因为数据是Db
5.10.2.2. 可能会增加存储成本，并很难保证数据一致性
5.10.3. 性能
5.10.3.1. 可能带来大量表和关系，从而降低查询性能
5.10.3.2. 可能需要使用更复杂的查询和索引策略来实现可接受的性能
5.10.4. 缺乏标准
5.10.4.1. 一种相对较新且使用较少的技术，缺乏标准化的方法
5.10.4.2. 能够构建和维护的工程师很少
