数据仓库实践：了解维度建模

维度建模概述

维度建模是一种面向分析的数据库设计方法，主要用于数据仓库和数据集市的构建;

它将数据按照业务分析和报告的需求组织成星型模式（Star-schema）雪花型模式（Snowflake Schema），以便于进行有效的在线分析处理（OLAP）;

维度建模的核心是将数据划分为维度和度量（事实），其中维度表存储描述性数据，如时间、产品、客户等，而事实表则存储度量事件及其与维度的关联信息。

维度建模的主要目标是提高查询性能，简化数据分析，并支持灵活的查询需求；

维度和事实

根据《数据仓库工具箱——维度建模权威指南（第3版）》章节2.1.6中维度的描述：

2.1.6 描述环境的维度

维度提供围绕某一业务过程事件的“谁、什么、何处、何时、为什么、如何”等背景。维度表包含BI应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度就能够将所有可能存在的维度区分开。当与给定事实表行关联时，任何情况下都应使维度保持单一值。

维度表有时被称为数据仓库的“灵魂”，因为维度表包含确保DW/BI系统能够被用作业务分析的入口和描述性标识。主要工作都放在数据管理与维度表的开发方面，因为它们是用户BI经验的驱动者。

2.1.7 用于度量的事实

事实涉及来自业务过程事件的度量，基本上都是以数量值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系，因此事实表对应一个物理可观察的事件。在事实表内，所有事实只允许与声明的粒度保持一直。例如在零售事务中，销售产品的数量与其总额是良好的事实，然而商店经理的工资不允许存在于零售事务中。

从引用中可知，维度是“谁、什么、何处、何时、为什么、如何”等背景内容，所以一般会是时间，地区，厂区等用于过滤和聚合的关键词，比如过滤和聚合库存数量这一事实时，我们会使用【某日某厂区下的库存数量】。

【某日某厂区下的库存数量】中包含日期维度，和厂区维度，粒度更细一点厂区维度下还会有仓库维度和库位维度。而去除维度的描述，库存数量便是事实，它与实际的物品数量一对一对应。

维度建模的模式

星型模式（Star-schema）

引用《数据仓库工具箱——维度建模权威指南（第3版）》章节1.3.1中星型模式的描述：

在关系数据库管理系统中实现的维度模型称为星型模式，因为其结构类似星型结构。

简而言之，星型模式是像完整遵循数据库设计开发范式的开发模式，每个事实与它的每个维度直接关联。这样的结构下数据的读写性能是很高的。

但是这样的结构意味着开发过程中每个事实需要跟所有用到的维度单独关联，没有第三方，即不能通过一个三方的维度寻找目标维度。

例如采购和物控的物料计划分析需求下我们需要计算某个材料的库存和在制是否满足某个客户的产品需求；

在这个需求下，我们不可能为库存数据单独设置客户字段，表明这部分库存对应某个客户，

因为材料可能是共用料，加入客户字段会使库存数量重复，导致不必要的计算工作和性能消耗；

所以为了解决这个问题，我们需要通过BOM、产品找到对应的客户、或者找到产品对应订单再找到对应的客户。

而雪花模式（Snowflake Schema）对应着这一实际情况。

雪花模式（Snowflake Schema）

雪花模式允许某些维度包含另一个或者另几个维度，从而实现【通过一个维度顺次关联到目标维度】的需求。

雪花模式解决的便是维度与事实表单独对应带来的人员工作量和数据存储性能消耗。

但雪花模式相较于星型模式会有计算量消耗，和数据结构复杂的增加的成本；需要数据开发人员灵活考虑。

星座模式（Constellation Schema）

星座模式是星型模式延伸而来，星型模式是基于一张事实表，而星座模式是基于多张事实表的，而且共享维度信息。

星座模式相较于雪花模型更进一步，也是实际数据仓库中必然会出现的模式，即事实表和维度表呈现“多对多”关系；

例如在制数量事实表可以对应时间、产品、材料、厂区等多个维度，

产品维度可以对应库存、在制、订单等事实表。

同时星座模式下不仅能像雪花模式一样通过维度关联其他维度，也能通过其他事实关联目标维度。

星座模式和雪花模式下的滥用

使用星座模式和雪花模式能够提高数据管理和开发的灵活度，但如果滥用也会造成不少的问题和开发管理成本。

忽略定义，直接通过已有数据计算和关联

由于部门职能的区分，定义主数据和高频使用主数据的部门不一定是同一部门；

故使用部门通常会绕过定义数据的部门，直接按照某一需求单独取数据；

导致开发人员需要搜遍所有数据从而计算出某一维度的数据。

并且由于版本等问题，数据并不完整。从而既造成计算成本，也没有完整实现需求。

数据结构复杂，开发人员进入成本高

雪花模式和星座模式通过使用非标准范式建模，以获取数据分析过程的灵活性，这表示复杂度的增高，也意味着理解成本的增高。

故在数据仓库规模逐渐扩大的过程中需要尽量克制地使用。

维度建模的步骤

如《数据仓库工具箱——维度建模权威指南（第3版）》所述，维度建模设计包含四个关键决策：

1. 选择业务过程
2. 声明粒度
3. 确定维度
4. 确定事实

故通过实践和总结，维度建模的步骤通常包括以下几个阶段：

业务调研：与业务人员沟通，了解业务需求和数据的使用情况；

业务调研的里程碑便是确定业务人员正在关注的业务过程，比如，有明确考核KPI的流程、业务人员按一定周期制作的手工报表、客户要求的数据交付项目等；

数据现状调研：分析现有数据结构和数据质量，确定数据源；

数据现状调研的里程碑是，主数据的所在的位置，汇总方式等，至少会包含标准文件如【料号编码规范（规则）】、业务管理系统如ERP、手工报表如市场需求明细邮件等；

高层模型设计：绘制总线矩阵，确定业务过程和粒度；

模型设计之前根据数据现状，我们至少应该确认数据来源，数据的负责人（通常负责定义和解释），即便不是主数据，也因为这些数据将供大部分部门消费而格外重要。进行高层模型设计是输出一个【初步的总线矩阵】,初步是通过数据现状和业务调研结果决定的，比如：当前需要建模的业务过程是物料计划，采购物料涉及的供应商维度我们只需要一个供应商的代码和供应商名称简称，没有涉及物流相关分析，故与其相关的运货商可做保留项。以供后续迭代拓展参考；

详细模型设计：定义维度和度量，设计维度表和事实表。

根据总线矩阵，我们已经能清晰得出需要哪些维度表和事实表，但需要进一步设计，因为需要兼容或者说包容一个细节，那就是即使业务调研，数据现状调研有业务人员参与，模型涉及的内容也不一定全面，因为一个通常的现状是，即使有PLM、OA等信息平台参与，由于组织变动，人员职能变动等因素，业务人员也并不一定掌握了所有工作相关的信息。或许我们会认为不够全面没有关系，问题不大，但在设计阶段，这不是多与少，大与小的关系，这是有和无的关系；

故详细模型设计里程碑是
源系统、主题、业务术语、报表、物理设计命名、调度任务、文档方面的规范；以及为了规范而初步开发的代码，甚至平台，比如完整的元数据管理，数据血缘管理；并且为了保证设计成果，新增的管理流程，比如模型变更评审流程，模型发布流程等；

同时在详细设计中，我们可以按照高层模型设计保留待扩展的内容，也可以根据工作量提前设计，这与当时的工作量等因素有关；

ETL设计与开发：设计数据抽取、转换和装载过程，将数据从源系统转移到数据仓库；

ETL开发即根据设计对数据进行清洗转移，需要依照程序开发的部分原则、范式对数据进行防呆，也需要对数据量，数据结构，同步频率，硬件性能等做评估，对数据来源重新验证，因为实际操作过程仍然有脱离计划的部分，比如任务排期，数据源变更等。

模型实施：在实际数据库中实现模型，并进行测试和优化。

数据模型的实施与服务开发相似，类似于服务开发的MVC分层，数据开发也有主流的分层结构，即 Kimball DW/BI 架构，此架构一般分为三层

ODS层（Operational Data Store、原始数据层、贴源层）；

DW层（Data Warehouse、数据仓库层）；

ADS层（Application DataService、数据应用层）；

同时为了适应数据仓库中各种重新汇总数据，重新建立数据实体对象的需求，DW层也能向下细分，另外也包含DIM层（Dimension、维度层）用于管理所有的维度比如时间，物料，BOM等。

维度建模的优点

提高查询性能：星型模式的预连接可以减少查询所需的时间。
简化数据分析：维度建模使得数据更易于理解和使用。
支持灵活的查询：可以支持多维度、多层次的查询需求。
易于扩展和维护：可以根据业务需求进行扩展和修改。

最新内容可扫码前往公众号继续查看