数据仓库中的七种建模方法及示例
试象一下，你是一家繁忙餐厅的分析工程师。每天，顾客都会预订、下订单并完成付款。所有这些数据都会流入餐厅的交易数据库，记录每次互动的详细信息。
但是，事务型数据库虽然非常适合日常运营，但并不适合分析数据以发现有助于业务增长的趋势和见解。这就是数据仓库的作用所在。数据仓库是一个单独的数据库，经过优化，可用于存储大量历史数据以及快速查询和分析。
挑战在于如何构建仓库中的数据，以便进行高效分析，同时保持足够的灵活性以应对不断变化的业务需求。数据仓库中的数据建模有几种常见和不太常见的方法。在本文中，我们将介绍七种关键的建模技术，权衡它们的优缺点，并帮助您为数据仓库选择正确的方法。
一、事务数据库示例
在深入研究数据仓库建模之前，让我们简单看一下餐厅的典型事务数据库可能包含哪些内容：
包含姓名、电子邮件、电话号码等详细信息的客户表
预订表，包括预订日期、时间、团体规模等
带有描述的产品表，链接到产品价格和产品组表
订单表将顾客与他们所选的菜单项联系起来
订单明细表，其中包含每个订单的每个菜单项的数量
包含总额、付款方式等的付款表。
交易数据库使用针对处理交易进行优化的规范化结构。但这种结构使分析和报告更加困难。数据仓库建模方法对数据进行非规范化和重组，以优化整合层中的分析，同时仍便于快速写入加工层。
二、数据仓库建模方法
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
以实体为中心的建模
优点：
灵活适应不断变化的业务需求
只需少量表格即可轻松理解
在指标栏内有效捕捉历史记录
缺点：
查询可能很复杂，通常需要解除半结构化数据的嵌套
实体具有重叠属性或行为类型时的挑战
与星型模式相比，更难实施完整性约束
三、选择正确的建模方法
考虑到这七种常见的数据仓库建模方法，如何为您的数据仓库选择正确的方法?请考虑以下因素：
分析要求：您需要回答哪些类型的问题?选择针对这些查询模式进行优化的模型。
数据量和可扩展性：考虑您现在拥有的数据量以及未来预期的数据量。有些方法的可扩展性优于其他方法。
易用性：考虑谁将查询数据仓库。有些模型对于非技术用户来说更直观。
灵活性：您的业务可能会不断发展。选择能够适应不断变化的需求的模型。
性能：考虑查询速度和数据冗余之间的权衡。非规范化模型通常速度更快，但需要更多存储空间。
最后，“正确”的数据仓库建模方法取决于您独特的业务需求和优先事项。通过了解每种建模技术的优势和劣势，您可以设计一个数据仓库，提供快速、灵活且富有洞察力的分析，以推动公司发展。
