什么是维度数据建模？示例、流程和优势

企业越来越多地转向 数据仓库 利用他们每天生成的大量数据。 数据仓库 是分析的最佳解决方案。然而，企业并不总是有这种选择。早期的 数据库 主要是为事务处理而设计的，缺乏分析报告所需的效率，这催生了维度建模。

1990 世纪 XNUMX 年代初，拉尔夫·金博尔 (Ralph Kimball) 是一位杰出人物。 数据仓库方法，发展了维度建模的原理。他于 1996 年首次出版的书《数据仓库工具包》概述了维度建模的概念和最佳实践。 Kimball 的方法侧重于以符合业务流程和用户需求的方式对数据进行建模，强调简单性和易用性。

在这篇文章中，我们将深入探讨维度的概念 数据建模 并了解其流程、优点和局限性。

什么是维度数据模型？

维度数据模型是一种在数据库或数据仓库中组织和构建数据的方法，使企业能够更轻松地分析数据并从数据中获得见解。 当处理大量数据以及用户需要从不同角度或维度探索数据时，它们特别有用。

不同的应用需要不同的维度建模技术。主要有两种建模技术：规范化实体关系模型（ER 模型）和维度建模。

另一方面，规范化实体关系模型（ER 模型）旨在消除数据冗余，快速执行插入、更新和删除操作，并获取数据库内的数据。

相比之下，维度模型或 Kimball 维度数据模型是非规范化结构，旨在从数据仓库检索数据。他们使用事实表和维度表来维护数据仓库中的历史数据记录。此外，它们经过优化以执行 选择 操作并用于基本设计框架中，以构建高度优化和功能化的数据仓库。

自动执行手动设计任务并将尺寸模型设计时间缩短 80%

免费14日试用

维度建模涉及的元素

事实表或业务度量

事实表存储有关业务度量的数字信息以及维度表的外键。 业务事实可以是可加的、半可加的或非可加的。 表 1 解释了三种类型的事实表。

表 1：事实表中的事实类型

用维度数据模型解释的事实类型

服装店在销售交易的事实表行中维护以下数据：

表 2：服装店维护的事务表

包含有关业务流程的数字信息的列是我们的业务事实。 在这个例子中， 数量, 单价, 销售额, 库存和 营业税 是事实。 其余实体（日期, 线上商城和 产品类型) 是尺寸。

销售额 可以在所有维度上添加。 因此，它是一个附加事实。 此外，添加 库存 整个信息 线上商城 维度提供有用的业务信息。 然而，由于这只是某个点的商品数量的快照，因此将其添加到 日期 维度没有提供任何有用的业务见解。 自从 库存 在某些维度上是可加的，而在其他维度上是非可加的，这是一个半可加的事实。 现在考虑 营业税。 新增中 营业税 跨越任何维度都会在分析处理过程中带来问题。 营业税 因此，是一个非相加事实。

设计自动化尺寸模型

分步指南

尺寸表

维度表存储有关业务事实的描述性信息，以帮助更好地理解和分析数据。 在表 2 所示的示例中， 日期, 商店位置和 产品类型 是维度实体，提供有关业务事实的更多信息。 销售总额是一个重要的记录指标，但如果没有这些维度，企业就无法评估哪个商店位置或产品类型产生更多销售额。

图 1：带有事实表和维度表的星型模式

首要的关键

主键是维度表中标识唯一记录的列。 代理键将成为缓慢变化的维度的主键。

外键

外键连接两个表（通常是事实表和维度表）。 维度表中的主键是相关事实表中的外键，用于引用该特定维度。

维度数据建模示例

让我们考虑一个零售业务维度建模的现实示例。 想象一下，一家连锁商店想要分析其销售数据以深入了解其绩效。 在这种情况下，维度数据模型可以应用如下：

1. 事实：此场景中的主要事实是销售交易。 这些事实将包括以下数据：

• 销售收入
• 销售产品数量
• 适用折扣
• 利润率

2. 尺寸：各种维度将为销售数据提供上下文：

• 时间维度：此维度可以包括年、季度、月、日、甚至一天中的时间等属性。 例如，它可以帮助回答诸如“去年每个季度我们的销售额是多少？”之类的问题。
• 产品尺寸：它可以描述商店中销售的产品。 它可能包括产品类别、品牌和产品名称等属性。 例如，它可以帮助回答诸如“哪种产品类别产生的收入最多？”之类的问题。
• 店铺规模：这可能包含有关各个商店位置的信息，例如商店名称、城市、州和商店经理。 它可以回答诸如“哪家商店上个月销售额最高？”之类的问题。
• 客户维度：它可以提供对客户人口统计数据的洞察，例如年龄、性别和位置。 它可以帮助回答诸如“每个客户群的平均购买金额是多少？”之类的问题。

3. 事实与维度的关系：包含销售交易的事实表将具有将其链接到维度表的外键。 例如，每个销售交易记录可能具有指向各自维度表中相应时间、产品、商店和客户的外键。
4. 层次结构：维度内的层次结构将帮助用户在不同粒度级别导航和分析数据。 例如，时间维度可能具有从年到季度到月到日的层次结构。
5. 措施：将根据销售事实计算衡量标准，以提供有价值的见解。 例如：

• 总销售金额
• 平均折扣率
• 利润率百分比

有了这个维度数据模型，零售企业就可以用它来回答广泛的问题，例如：

• “上个季度我们每个产品类别的总销售额是多少？”
• “与去年同期相比，哪家商店的销售额增幅最高？”
• “每个产品类别的产品平均利润率是多少？”

设计维度数据模型

为了理解这个过程 设计维度模型，让我们考虑一个服装系列的示例，该服装系列在加利福尼亚州和宾夕法尼亚州的两家商店销售两种风衣 - 尼龙和聚酯纤维。 该示例的样本数据如表 2 所示。

步骤 1：确定业务流程

在对数据进行建模之前，您应该找到适合您的数据模型的维度建模类型。 维度建模过程（或任何数据建模）从识别您想要跟踪的业务流程开始。 在本例中，我们想要跟踪两种类型的风衣的销售情况。

步骤 2：识别维度数据模型中的事实和维度

维度模型中的信息分为两种表类型 - 事实 和 尺寸。 下一步是确定您想要衡量的业务事实及其相关维度。 在我们的示例中，风衣销售是我们想要衡量的事实。 日期、商店位置（加利福尼亚州和宾夕法尼亚州）和产品类型（尼龙风衣和聚酯风衣）是让我们进一步了解销售流程的维度。

步骤 3：确定维度的属性

确定业务流程的维度和事实后，下一步是确定属性并为每个维度创建单独的维度表。 每种数据类型都有不同类型的维表。 维度表中的每条记录都应该有一个唯一的键。 该键将用于标识维度表中的记录，并作为事实表中的外键来引用特定维度并将其与事实表连接。 表 3-5 显示了我们的服装系列示例中数据仓库中不同类型的维度。

表 3：日期的维度表

表4：商店维度表

表5：产品尺寸表

步骤 4：定义业务事实的粒度

粒度是指任何表中存储的信息的级别。 例如，在我们的示例中，每天记录销售额； 因此，在本例中，粒度是每日。 维度模型中的事实表应该与预定义的粒度一致。

第5步：存储历史信息（缓慢变化的维度）

维度模型的一个重要特点是可以在不改变完整交易信息的情况下轻松修改维度属性。 例如，服装系列决定将秋季系列中的尼龙风衣延续到春季系列中，并更新了名称 购物 属性。 在维度表中进行更新很容易，但是更新后我们将丢失以前的数据。 如果数据建模和数据仓库的目标是维护和存储历史记录，这可能是一个问题。 随着时间的推移缓慢变化的维度称为缓慢变化的维度。 此外，数据仓库中的时间维度表是自动生成的，并捕获不同事务发生的时间。 您可以通过跟踪缓慢变化的维度来维护和存储历史数据。

通过我们的分步指南了解有关设计自动尺寸建模的更多信息

什么是数据仓库中的多维数据模型？

多维数据模型是维度数据建模的具体实现，专为更高级的分析和报告需求而定制。 它扩展了常规维度数据建模的概念以提供附加功能。 以下是有关维度数据模型需要注意的一些重要因素：

• 它通过引入数据立方体的概念增加了复杂性。 数据立方体存储预先聚合的数据，这可以为多维分析带来更复杂但更有效的结构。
• 它仍然是用户友好的，但为用户提供了更多使用 OLAP 工具与数据交互的功能。 用户可以同时从多个维度透视、钻取和分析数据。
• 它通常涉及非规范化维度表和数据立方体中的预聚合数据。 虽然这可能会增加聚合数据的存储需求，但它可以减少维度表中的冗余，从而提高存储效率。
• 它非常适合高级分析、复杂报告以及性能至关重要的场景，例如具有大量历史数据的大型数据仓库。

维度建模的好处

由于维度建模所带来的好处，它仍然是设计企业数据仓库时最常用的数据建模技术。 这些包括：

优化查询性能：维度模型专为查询和报告而设计，可提高查询性能，特别是对于复杂的分析查询。

更快的数据检索: 维度数据建模合并模型本身中的表，这使用户能够通过运行联接查询更快地从不同数据源检索数据。 维度模型数据仓库的非规范化模式（而不是雪花模式中的规范化模式）经过优化以运行即席查询。 因此，它极大地补充了组织的商业智能 (BI) 目标。

Fl灵活改变: 维度建模框架使数据仓库过程可扩展。 可以轻松修改设计以纳入新的业务需求或调整中央存储库。 可以将新实体添加到模型中，或者可以更改现有实体的布局以反映修改后的业务流程。

多维分析：维度模型支持多维度分析，因此用户可以同时探索不同维度和层次结构的数据。

减少数据冗余： 维度模型通常涉及非规范化，与高度规范化的模型相比，这减少了数据冗余，从而提高了查询性能。

维度建模的局限性

虽然维度建模是满足分析和报告需求的强大技术，但它也有一些局限性，并且在某些情况下它可能不是最合适的方法。 因此，有必要评估它是否符合您的数据和用例的特征和要求。 以下是维度建模的一些限制以及您可以考虑替代建模技术的情况：

1. 复杂的关系：维度建模假设维度和事实之间的关系相对简单。 如果您的数据涉及高度复杂的关系，无法轻松地用星形或雪花模式表示，则维度建模可能不是最佳选择。
2. 频繁的数据更改：维度模型是为历史分析而设计的，可能无法很好地处理频繁变化或需要实时更新的数据。 在这种情况下，事务或标准化模型可能更合适。
3. 稀疏数据：当您处理许多维度组合没有关联事实（稀疏数据）的数据时，维度模型可能会导致存储和查询性能低下。
4. 大量非结构化数据：如果您的数据包含大量非结构化或半结构化数据（例如文本文档、社交媒体源），仅维度建模可能还不够。 您可能需要结合 NoSQL 数据库或面向文档的数据库等技术。

自动化——维度建模的游戏规则改变者

设计维度模型是构建系统框架的重要步骤 企业数据仓库。 借助强大的数据仓库自动化工具（例如 Astera 数据仓库构建器。

无需任何编码即可构建端到端数据仓库

查看演示

通过 Astera 数据仓库生成器，您可以在可视化的免代码集成开发环境中快速构建维度模型。 可以通过简单的拖放和合并来对实体进行非规范化。 可以批量分配实体角色（事实和维度），从而在处理数百个实体时节省您的宝贵时间。 此外，该产品通过对 SCD 类型 1、2、3 和 6 的内置支持，使您能够管理缓慢变化的尺寸。

Astera DW Builder 是一个端到端数据仓库自动化平台，具有内置的维度数据建模功能，支持广泛的数据库和 CRM 应用程序、自动化数据映射和数据加载功能，以及与商业智能平台（例如Tableau 和 Power BI。

参见 Astera DW Builder 的演示 或注册一个 免费试用 亲身体验数据仓库自动化的力量。

将数据仓库开发时间缩短高达 80%