深入探讨数据仓库缓慢变化维的解决方案

简介: 深入探讨数据仓库缓慢变化维的解决方案

缓慢变化维定义 Wikipedia中的定义:

Dimension is a term in data management and data warehousing that refers to logical groupings of data such as geographical location, customer information, or product information.Slowly Changing Dimensions (SCD) are dimensions that have data that slowly changes.

大意是说数据会发生缓慢变化的维度就叫”缓慢变化维”。

举个例子就清楚了:

在一个零售业数据仓库中,事实表保存着各销售人员的销售记录,某天一个销售人员从北京分公司调到上海分公司了,那么如何来保存这个变化呢?也就是说销售人员维度要怎么恰当的处理这一变化。先来回答一个问题,为什么要处理,或保存这一变化?如果我们要统计北京地区或上海地区的总销售情况的时候,这个销售人员的销售记录应该算在北京还是算在上海?当然是调离前的算在北京,调离后的算在上海,但是如标记这个销售人员所属区域?这里就需要处理一下这个维度的数据,即我们缓慢变化维需要做的事情。

处理缓慢变化维一般按不同情况有以下几种解决方案:

一、新数据覆盖旧数据

此方法必须有前提条件,即你不关心这个数剧的变化。例如,某个销售人员的英文名改了,如果你不关心员工的英文名有什么变化则可直接覆盖(修改)数据仓库中的数据。

二、保存多条记录,并添加字段加以区分

这种情况下直接新添一条记录,同时保留原有记录,并用单独的专用的字段保存区别。如:

(以下表格中Supplier_State表示上面例子中所属区域,为描述清晰,不用代理键表示)

复制

Supplier_key Supplier_Code Supplier_Name Supplier_State Disable
001 ABC Phlogistical Supply Company CA Y
002 ABC Phlogistical Supply Company IL N
• 1.
• 2.
• 3.
• 4.
• 5.

或:

复制

Supplier_key Supplier_Code Supplier_Name Supplier_State Version
001 ABC Phlogistical Supply Company CA 0
002 ABC Phlogistical Supply Company IL 1
• 1.
• 2.
• 3.
• 4.
• 5.

以上两种是添加数据版本信息或是否可用来标识新旧数据。

下面一种则是添加记录的生效日期和失效日期来标识新旧数据:

复制

Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
001 ABC Phlogistical Supply Company CA 01-Jan-2000 21-Dec-2004
002 ABC Phlogistical Supply Company IL 22-Dec-2004
• 1.
• 2.
• 3.
• 4.
• 5.

空的End_Date表示当前版本数据,或者你也可一用一个默认的大时间 (如: 12/31/9999)来代替空值, 这样数据还能被索引识别到.

三、不同字段保存不同值

复制

Supplier_key Supplier_Name Original_Supplier_State Effective_Date Current_Supplier_State
001 Phlogistical Supply Company CA 22-Dec-2004 IL
• 1.
• 2.
• 3.

这种方法用不同的字段保存变化痕迹.但是这种方法不能象第二种方法一样保存所有变化记录,它只能保存两次变化记录.适用于变化不超过两次的维度。

四、另外建表保存历史记录

即另外建一个历史表来表存变化的历史记录,而维度只保存当前数据。

复制

Supplier:
Supplier_key Supplier_Name Supplier_State
001 Phlogistical Supply Company IL
Supplier_History:
Supplier_key Supplier_Name Supplier_State Create_Date
001 Phlogistical Supply Company CA 22-Dec-2004
• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.
• 8.
• 9.
• 10.
• 11.

这种方法仅仅记录一下变化历史痕迹,其实做起统计运算来还是不方便的。

五、混合模式

这种模式是以上几种模式的混合体,相对而言此种方法更全面,更能应对错综复杂且易变化的用户需求,也是较为常用的。

复制

Row_Key Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date 
Current Indicator
1 001 ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007 N
2 001 ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099 Y
• 1.
• 2.
• 3.
• 4.
• 5.
• 6.

此中方法有以下几条优点:

1. 能用简单的过滤条件选出维度当前的值。

2. 能较容易的关联出历史任意一时刻事实数据的值。

3. 如果事实表中有一些时间字段(如:Order Date, Shipping Date, Confirmation Date),那么我们很容易选择哪一条维度数据进行关联分析。

其中Row_Key和 Current Indicator字段是可有可无的,加上去更方便,毕竟维度表的数据都不大,多点冗余字段不占太大空间但能提高查询效率。

这种设计模式下事实表应以Supplier_key为外键,虽然这个字段不能***标识一条维度数据,从而形成了事实表与维表多对多的关系,因此在做事实和维度做关联时应加上时间戳字段(或Indicator字段)。

六、非常规混合模式

上面说到第五种实现方式有点弊端,那就是事实表和维表不是多对一关系,而是多对多关系,这种关系不能在建模时解决只能在报表层面,在报表运行时解决,且在BI语意层建模时需要添加时间过滤条件,比较繁琐。

下面这种解决方案可以解决此多对多关系,但是得修改一下事实表:

复制

Supplier Dimension:
Version_Number Supplier_key Supplier_Code Supplier_Name Supplier_State Start_Date End_Date
1 001 ABC001 Phlogistical Supply Company CA 22-Dec-2004 15-Jan-2007
0 001 ABC001 Phlogistical Supply Company IL 15-Jan-2007 1-Jan-2099
• 1.
• 2.
• 3.
• 4.
• 5.
• 6.
• 7.

Fact Delivery: (为描述清晰,同样不使用代理键标识维度)

复制

Delivery_Key Supplier_key Supplier_version_number Quantity Product Delivery_Date Order_Date
1 001 0 132 Bags 22-Dec-2006 15-Oct-2006
2 001 0 324 Chairs 15-Jan-2007 1-Jan-2007
• 1.
• 2.
• 3.
• 4.
• 5.

此方案中向维表中的当前数据版本号始终为0,即插入维度数据时先将老版本的数据的version_number改成1(递增),然后再插入当前数据,此时才能保持当前数据版本号始终为0。

事实表中插入数据时所有的维度数据版本号始终全部为0。

因此此方案完全可解决事实表和维表多对多关系问题,另外还有个优点是能保证事实表和维表的参照完整性,而且我们在用ERwin,PowerDesigner等建模工具建模时,Version_Number和Supplier_key可作为复合主键在两实体间建立链接。

相关文章
|
1月前
|
存储 大数据 数据管理
数据仓库(09)数仓缓慢变化维度数据的处理
数据仓库的重要特点之一是反映历史变化,所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化,与数据增长较为快速的事实表相比,维度变化相对缓慢。阴齿这个就叫做缓慢变化维。
218 2
数据仓库(09)数仓缓慢变化维度数据的处理
|
存储 数据处理
|
SQL 运维 数据库
课时10: 1月28日-06-数据库生态工具&阿里云数据仓库解决方案及案例
课时10: 1月28日-06-数据库生态工具&阿里云数据仓库解决方案及案例
250 0
课时10: 1月28日-06-数据库生态工具&阿里云数据仓库解决方案及案例
|
SQL 监控 Cloud Native
前沿分享|阿里云数据库解决方案架构师 王宏宇:云原生数据仓库AnalyticDB在零售行业的深度应用和业务价值
本篇内容为2021云栖大会-云原生数据仓库AnalyticDB技术与实践峰会分论坛中,阿里云数据库解决方案架构师 王宏宇关于“云原生数据仓库AnalyticDB在零售行业的深度应用和业务价值”的分享。
291 0
前沿分享|阿里云数据库解决方案架构师 王宏宇:云原生数据仓库AnalyticDB在零售行业的深度应用和业务价值
|
敏捷开发 监控 Cloud Native
重磅|阿里云发布“一站式敏捷数据仓库解决方案” 实现库仓一体数据分析能力(内含干货PPT下载)
阿里云重磅发布一站式敏捷数据仓库解决方案。该方案结合一站式数据管理平台DMS及云原生数据仓库AnalyticDB(以下简称ADB),真正实现了库仓一体的技术架构,提供在线数据实时入仓、T+1周期性快照、按需建仓等能力,数据延时低至秒级,持续赋能业务在线化,令企业在线数据释放最大价值。通过低代码操作,阿里云一站式敏捷数据仓库解决方案大幅降低了实时数仓的构建难度和数据加工门槛,同时可支撑企业各类高频、动态化的实时分析场景和需求,帮助用户破解实时数仓建设难题,加速企业数字化转型。
722 0
重磅|阿里云发布“一站式敏捷数据仓库解决方案” 实现库仓一体数据分析能力(内含干货PPT下载)
|
SQL 分布式计算 前端开发
数据仓库解决方案——ODPS组件化改造之路
ODPS简介:ODPS(Open Data Processing Service),是阿里巴巴通用计算平台提供的一种快速、完全托管的 GB/TB/PB 级数据仓库解决方案,现在已更名为MaxCompute,MaxCompute 向用户提供了完善的数据导入方案以及多种经典的分布式计算模型,能够更快速的解决用户海量数据计算问题,有效降低企业成本,并保障数据安全。
数据仓库解决方案——ODPS组件化改造之路
|
SQL 存储 分布式计算
HBase助力点触科技构建实时计算和数据仓库解决方案
点触科技选择阿里云HBase SQL服务(Phoenix)+ Spark服务构建实时计算和数据仓库解决方案。
1255 0
HBase助力点触科技构建实时计算和数据仓库解决方案