沃卡惠移动端logo

沃卡惠  行业资讯

资讯详情

数据仓库中的七种建模方法及示例

2024-06-17 09:52:074636

试象一下,你是一家繁忙餐厅的分析工程师。每天,顾客都会预订、下订单并完成付款。所有这些数据都会流入餐厅的交易数据库,记录每次互动的详细信息。

但是,事务型数据库虽然非常适合日常运营,但并不适合分析数据以发现有助于业务增长的趋势和见解。这就是数据仓库的作用所在。数据仓库是一个单独的数据库,经过优化,可用于存储大量历史数据以及快速查询和分析。

挑战在于如何构建仓库中的数据,以便进行高效分析,同时保持足够的灵活性以应对不断变化的业务需求。数据仓库中的数据建模有几种常见和不太常见的方法。在本文中,我们将介绍七种关键的建模技术,权衡它们的优缺点,并帮助您为数据仓库选择正确的方法。

数据仓库

一、事务数据库示例

在深入研究数据仓库建模之前,让我们简单看一下餐厅的典型事务数据库可能包含哪些内容:

包含姓名、电子邮件、电话号码等详细信息的客户表

预订表,包括预订日期、时间、团体规模等

带有描述的产品表,链接到产品价格和产品组表

订单表将顾客与他们所选的菜单项联系起来

订单明细表,其中包含每个订单的每个菜单项的数量

包含总额、付款方式等的付款表。

交易数据库使用针对处理交易进行优化的规范化结构。但这种结构使分析和报告更加困难。数据仓库建模方法对数据进行非规范化和重组,以优化整合层中的分析,同时仍便于快速写入加工层。

二、数据仓库建模方法

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

以实体为中心的建模

优点:

灵活适应不断变化的业务需求

只需少量表格即可轻松理解

在指标栏内有效捕捉历史记录

缺点:

查询可能很复杂,通常需要解除半结构化数据的嵌套

实体具有重叠属性或行为类型时的挑战

与星型模式相比,更难实施完整性约束

三、选择正确的建模方法

考虑到这七种常见的数据仓库建模方法,如何为您的数据仓库选择正确的方法?请考虑以下因素:

分析要求:您需要回答哪些类型的问题?选择针对这些查询模式进行优化的模型。

数据量和可扩展性:考虑您现在拥有的数据量以及未来预期的数据量。有些方法的可扩展性优于其他方法。

易用性:考虑谁将查询数据仓库。有些模型对于非技术用户来说更直观。

灵活性:您的业务可能会不断发展。选择能够适应不断变化的需求的模型。

性能:考虑查询速度和数据冗余之间的权衡。非规范化模型通常速度更快,但需要更多存储空间。

最后,“正确”的数据仓库建模方法取决于您独特的业务需求和优先事项。通过了解每种建模技术的优势和劣势,您可以设计一个数据仓库,提供快速、灵活且富有洞察力的分析,以推动公司发展。