试象一下，你是一家繁忙餐厅的分析工程师。每天，顾客都会预订、下订单并完成付款。所有这些数据都会流入餐厅的交易数据库，记录每次互动的详细信息。
但是，事务型数据库虽然非常适合日常运营，但并不适合分析数据以发现有助于业务增长的趋势和见解。这就是数据仓库的作用所在。数据仓库是一个单独的数据库，经过优化，可用于存储大量历史数据以及快速查询和分析。
挑战在于如何构建仓库中的数据，以便进行高效分析，同时保持足够的灵活性以应对不断变化的业务需求。数据仓库中的数据建模有几种常见和不太常见的方法。在本文中，我们将介绍七种关键的建模技术，权衡它们的优缺点，并帮助您为数据仓库选择正确的方法。
一、事务数据库示例
在深入研究数据仓库建模之前，让我们简单看一下餐厅的典型事务数据库可能包含哪些内容：
- 包含姓名、电子邮件、电话号码等详细信息的客户表
- 预订表，包括预订日期、时间、团体规模等
- 带有描述的产品表，链接到产品价格和产品组表
- 订单表将顾客与他们所选的菜单项联系起来
- 订单明细表，其中包含每个订单的每个菜单项的数量
- 包含总额、付款方式等的付款表。
交易数据库使用针对处理交易进行优化的规范化结构。但这种结构使分析和报告更加困难。数据仓库建模方法对数据进行非规范化和重组，以优化整合层中的分析，同时仍便于快速写入加工层。
二、数据仓库建模方法
1.第三范式（3NF）
第三范式 (3NF) 是一种经典的关系数据库建模方法，可最大限度地减少数据冗余。在 3NF 中，每个非键列仅依赖于表的主键。
将 3NF 应用于我们的餐厅数据仓库，我们将进一步分离表格，这样各个表格结构中就不会有层次结构，而是作为表格链接的层次结构。订单和付款等交易表将引用元数据表的主键，而元数据表又将引用更高级别的元数据表。
本质上，我们要做的改变是确定客户表包含地址详细信息，这是自然层次结构。然后，我们会将它们拆分为组件表。通常，您不会将此方法用于整合层，但它可能适用于加工层。如果您正在提取可能以不同粒度级别本机构建的多个源，则尤其如此。
3NF 实体关系数据库
优点：
- 减少数据冗余，节省存储空间
- 通过主键关系保证数据完整性
- 提供灵活性以适应未来的变化
缺点：
- 可能需要进行许多表连接进行分析，从而影响查询性能
- 对于业务用户来说，理解和操作起来可能很复杂
2.Kimball 星型模式
Kimball 星型模式是数据仓库中的一个关键概念，由数据仓库和商业智能领域的杰出人物 Ralph Kimball 提出。它旨在简化数据存储并提高查询性能，使复杂的数据结构更易于管理并更易于进行业务分析。
关键部件
- 事实表：事实表是星型模式的核心，包含定量数据，例如销售额、交易次数和其他可衡量指标。事实表中的每条记录都对应一个特定事件或交易，并包含链接到维度表的外键。由于它保存的交易数据量很大，因此该表通常很大。通常，它包括销售额、销售量和成本等数值度量，以及引用维度表的键。
- 维度表：维度表是为事实表中的数据提供上下文的外围表。它们包含与业务维度相关的描述性属性，例如时间段、地理位置、产品、客户和员工。与事实表相比，维度表通常更小且更静态。它们以非规范化形式存储数据以简化查询，使其更易于理解和导航。
结构和设计
星型模式因其布局类似星星而得名。事实表位于中心，周围是维度表，每个维度表都通过外键连接到事实表。这种设计非常直观，允许用户在事实表和维度表之间执行直接连接。
在我们的餐厅示例中，我们将有一个中央订单事实表，其中包含客户、日期、产品等维度表的外键。维度表包含冗余、非规范化的数据，以避免进一步连接。这是仓库中整合层或表示层的一种相当标准的方法。
订单数据的星型模式 ERD
优点：
- 通过最小化连接来优化快速查询
- 对于熟悉业务流程的业务用户来说很直观
- 聚合计算简单
缺点：
- 非规范化增加了数据冗余
- 处理缓慢变化的维度可能很棘手
- 适应未来变化的灵活性较差
3.雪花模式
雪花模式是数据仓库中星型模式的一种变体，旨在处理复杂且高度规范化的数据结构。该模式因其复杂的雪花状形状而得名，它将数据组织到多个相关表中，从而增强了数据完整性并减少了冗余。然而，这会增加查询编写的复杂性并可能影响性能。它几乎可以看作是星型模式和 3NF 的混合体。
关键部件
- 事实表：事实表仍然是雪花模式中的中心表，包含定量数据，例如销售额、收入或其他业务指标。它包含维度表的外键，为事实提供背景信息。事实表中的每条记录代表一个可测量的事件，并包括数值度量和链接到相关维度的外键。
- 维度表：与星型模式不同，雪花模式进一步规范化了维度表。每个维度表都可以分解为多个相关表，从而创建更规范的结构。例如，我们的客户维度将地址拆分为邮政编码、城市和州表，每个表都通过外键链接。这种规范化减少了数据冗余，但增加了查询所需的连接数。
结构和设计
雪花模式由于其多级结构而类似于雪花。维度表被规范化为多个相关表，分散成复杂的网状结构。这种设计旨在通过消除冗余来节省存储空间并提高数据完整性。
订单数据的雪花模式
优点：
- 与星型模式相比，减少了数据冗余
- 通过规范化确保数据完整性
- 使维度表更易于维护
缺点：
- 与星型模式相比，可能需要更多连接，从而影响查询性能
- 商业用户更难理解和驾驭
4.宽表 (OBT)
One-Big-Table (OBT) 设计，也称为平面表或宽表，是一种数据仓库方法，其中所有数据都合并到单个非规范化表中。这种方法与星型和雪花型等规范化模式形成鲜明对比，它提供了更简单的结构，但代价是冗余度增加，并且在处理非常大的数据集时可能会出现性能问题。
关键部件
- 单表：OBT 设计的核心特征是所有相关数据都存储在一个综合表中。该表包含大量列，可捕获分析所需的所有属性和度量。该表可能包含数千列，每行代表一条包含多个维度和指标的唯一记录。
- 属性和指标：在 OBT 设计中，属性（通常在其他模式的维度表中找到）和指标（通常在事实表中找到）被组合到单个表中。例如，客户详细信息、产品信息和销售数据都将存储在同一张表中，每条记录都提供交易或事件的完整快照。
结构和设计
OBT 设计的结构非常简单，只包含一个表，其中每行包含所有必要的数据点。这种扁平结构无需连接，用户无需了解复杂的表关系即可轻松查询和检索数据。
对于我们的餐厅，我们将为三个关键事件（预订、订单和付款）分别设置一个大表。我看到过一些关于 OBT 还是星型模式是更好的方法的相当激烈的争论。答案是“视情况而定”。如果您将数据拉入 Power BI，它将需要星型模式样式的数据集。但是，如果您将数据拉入 Tableau，您可能更喜欢 OBT 方法。但应该注意的是，如果您确实选择 OBT，则应将任何可重复使用的逻辑保留在可以反复引用的支持表中。
OBT 示例
优点：
- 极快的查询性能，无需连接
- 所有数据都集中在一处，简单易懂
- 适合数据科学消费
缺点：
- 数据冗余度高，需要大量存储空间
- 如果不改变整个表结构，就很难做出改变
- 包含许多列的查询可能难以编写和维护
5.数据仓库 2.0
Data Vault 2.0 是一种现代数据仓库方法，旨在提供可扩展、灵活且可审计的数据模型。它由 Dan Linstedt 开发，以原始 Data Vault 方法为基础，对其进行了增强，以更好地支持当今复杂的数据环境。Data Vault 2.0 满足了处理大数据、非结构化数据和各种数据源的需求，同时保持了数据完整性和历史准确性。与 3NF 一样，这将位于您的银层。这不是您指向 BI 工具的东西。
关键部件
- 枢纽：枢纽存储具有唯一代理键和元数据（如加载日期和源信息）的唯一业务键。每个枢纽代表一个核心业务概念，例如客户、产品或订单。枢纽高度稳定且很少发生变化，为数据仓库提供一致的参考点。
- 链接：链接捕获存储在中心中的业务键之间的关系。每个链接表包含相关中心的外键以及元数据。链接表示实体之间的事务、关联或层次结构。它们用于对多对多关系以及关系随时间的变化进行建模。
- 卫星：卫星存储中心中业务键或链接中关系的描述性属性和上下文。它们包括用于跟踪随时间变化的元数据，例如加载日期和来源。卫星可以在不影响核心业务键和关系的情况下发展，从而可以灵活地适应新的业务需求。
结构和设计
Data Vault 2.0 采用模块化架构设计，将数据存储分为这三种类型的表，从而提高可扩展性和灵活性。集线器、链路和卫星被设计为增量和并行加载，从而可以高效处理大量数据和随时间变化的数据。
数据仓库 ERD 示例
优点：
- 旨在应对业务需求随时间的变化
- 将结构变化与信息变化分开
- 提供可追溯性并保存历史记录
缺点：
- 设计和实施起来可能很复杂
- 需要许多表格和连接来汇总数据进行分析
- 查询可能难以编写和理解
6.活动模式
活动模式是 Ahmed Elsamadisi 设计的一种数据仓库方法，用于以结构化和高效的方式捕获业务活动或事件的详细记录。此模式侧重于记录企业内部执行的操作或交易，因此对于事件驱动数据和详细交易日志记录特别有用。它已用于需要跟踪大量细粒度事件的系统，例如电子商务网站、金融系统或物联网应用程序。
关键部件
- 活动表：活动模式中的中心表是活动表，它记录每个业务活动或事件。活动表中的每一行代表单个事件或交易，捕获有关发生了什么、何时发生以及其他相关背景的详细信息。此表属性已定义为标准的一部分，因此易于实现。
- 维度表：活动表附带一个可选维度表，该维度表为活动表中记录的事件提供额外的背景信息。维度可能包括有关客户、产品、位置、时间和其他相关实体的详细信息，具体取决于它所涉及的活动流。
在我们的餐厅示例中，我们可能有一个带有相关客户维度的客户活动表。活动表将跟踪客户的活动，例如他们的预订、订单和付款。这些活动的详细信息保存在列中feature_json，并有一个可选列用于存储相关的收入影响。
活动架构示例
优点：
- 设计简单直观，表格数量极少
- 无需更改架构即可捕获实体的其他活动
- 仅当需要跟踪新实体时才需要新表
缺点：
- 相对较新的方法，尚未被广泛采用
- 可能不适合所有业务领域和分析需求
7.以实体为中心的建模
以实体为中心的建模是一种灵活的方法，由 Maxime Beauchemin 提出，专注于围绕客户和产品等实体进行建模。每个实体都有自己的表，使用 JSON 来跟踪包括聚合在内的各种指标。这种方法不需要额外的维度表，因为实体表位于实体的最低粒度，并且可以直接在表中包含其属性。
在餐厅环境中，我们会有一个客户表，其中包含客户属性列，加上一个 json 列来保存时间绑定指标，例如visit.7d，，visit.14d。sale.30d
以实体为中心的建模
优点：
- 灵活适应不断变化的业务需求
- 只需少量表格即可轻松理解
- 在指标栏内有效捕捉历史记录
缺点：
- 查询可能很复杂，通常需要解除半结构化数据的嵌套
- 实体具有重叠属性或行为类型时的挑战
- 与星型模式相比，更难实施完整性约束
三、选择正确的建模方法
考虑到这七种常见的数据仓库建模方法，如何为您的数据仓库选择正确的方法？请考虑以下因素：
- 分析要求：您需要回答哪些类型的问题？选择针对这些查询模式进行优化的模型。
- 数据量和可扩展性：考虑您现在拥有的数据量以及未来预期的数据量。有些方法的可扩展性优于其他方法。
- 易用性：考虑谁将查询数据仓库。有些模型对于非技术用户来说更直观。
- 灵活性：您的业务可能会不断发展。选择能够适应不断变化的需求的模型。
- 性能：考虑查询速度和数据冗余之间的权衡。非规范化模型通常速度更快，但需要更多存储空间。
最后，“正确”的数据仓库建模方法取决于您独特的业务需求和优先事项。通过了解每种建模技术的优势和劣势，您可以设计一个数据仓库，提供快速、灵活且富有洞察力的分析，以推动公司发展。
