数据仓库专题(9)-缓慢变化维处理技术

一、案例描述

  在一个零售业数据仓库中,事实表保存着各销售人员的销售记录,某天一个销售人员从北京分公司调到上海分公司了,那么如何来保存这个变化呢?也就是说销售人员维度要怎么恰当的处理这一变化。

  先来回答一个问题,为什么要处理,或保存这一变化?如果我们要统计北京地区或上海地区的总销售情况的时候,这个销售人员的销售记录应该算在北京还是算在上海?当然是调离前的算在北京,调离后的算在上海,但是如标记这个销售人员所属区域?这里就需要处理一下这个维度的数据,即我们缓慢变化维需要做的事情。

二、解决方案

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

2.2 保存多条记录,并添加字段加以区分
这种情况下直接新添一条记录,同时保留原有记录,并用单独的专用的字段保存区别。如:
(以下表格中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
或:

Supplier_key Supplier_Code Supplier_Name Supplier_State Version
001 ABC Phlogistical Supply Company CA 0
002 ABC Phlogistical Supply Company IL 1

以上两种是添加数据版本信息或是否可用来标识新旧数据。
下面一种则是添加记录的生效日期和失效日期来标识新旧数据:

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

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

2.3. 不同字段保存不同值

Supplier_key Supplier_Name Original_Supplier_State Effective_Date Current_Supplier_State
001 Phlogistical Supply Company CA 22-Dec-2004 IL

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

2.4 另外建表保存历史记录

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

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

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

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

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

其中Row_Key和 Current Indicator字段是可有可无的,加上去更方便,毕竟维度表的数据都不大,多点冗余字段不占太大空间但能提高查询效率。
这种设计模式下事实表应以Supplier_key为外键,虽然这个字段不能唯一标识一条维度数据,从而形成了事实表与维表多对多的关系,因此在做事实和维度做关联时应加上时间戳字

时间: 2024-10-13 21:37:17

数据仓库专题(9)-缓慢变化维处理技术的相关文章

数据仓库专题(8)-维度属性选择之维护历史是否应该保留

一.背景 数据仓库建模过程中,针对事务型事实表设计,经常会遇到维度属性选择的问题,比如客户维度,在操作型系统中,为了跟踪客户状态的变化,往往会附加客户记录的四个属性:       1.add time:添加时间: 2.add user:添加用户: 3.mod time:修改时间: 4.mod user:修改用户: 问题在于,当我们进行维度建模的时候,如果以客户作为维度,是否应该考虑以上四个属性? 二.观点 1.应该保留 (1)我觉得 添加时间 可以作为维度属性,以后可能进行相关的统计: 2.不应

数据仓库专题(11)-可以作为维度表使用的事实表

KDT#13 可以作为维度表使用的事实表 事实表从粒度的角度分为三种,分别是交易粒度事实表.周期快照事实表和累计快照事实表. 交易粒度事实表能提供某个确切时刻的描述信息.以银行帐户中保存的客户信息为例来说,代理机构会周期的更新客户的名称.地址.电话号码.客户分类.信用等级.风险等级及其他描述性信息.建立的交易粒度事实表如下所示: 变更日期(FK)帐户号(SK) 代理(FK) 客户信息变更类型(FK) 帐户号(NK) 名称(文本事实) 地址(文本事实) 电话号码(文本事实) 客户分类(文本事实)

数据仓库专题(2)-Kimball维度建模四步骤

一.前言 四步过程维度建模由Kimball提出,可以做为业务梳理.数据梳理后进行多维数据模型设计的指导流程,但是不能作为数据仓库系统建设的指导流程.本文就相关流程及核心问题进行解读. 二.数据仓库建设流程 以下流程是根据业务系统.组织结构.团队结构现状设定的数据仓库系统建设流程,适合系统结构复杂,团队协作复杂,人员结构复杂的情况,并且数据仓库建设团队和业务系统建设团队不同的情况.具体流程如下图所示:   图1 数据仓库系统建设流程   三.四步维度建模 Kimball四步建模流程适合上述数据仓库

移动开发-求教“声维码”技术的原理

问题描述 求教"声维码"技术的原理 老板最近对"声维码"技术特别关注,但国内唯一一家做声维码的公司ZULU资料极少,唯有借此宝地求教各位,望大侠们不吝赐教,小的感激不尽!!!! 我所了解到的声维码是这样: 声维码是从一套声维码库里,抽取一定频率的声音进行编码,生成声维码.声维码是一个触发机制,其对应的信息内容会事先上传到云端的服务器上,当用户通过智能终端(比如安装了ZULU软件的智能手机)接收到声维码后,智能终端会对声维码进行解码,从而获取该声维码对应的存储在云端的

街库网1亿资金注入自主二维码技术点金O2O

街库网与通联支付首发仪式圆满成功 2012年5月22日,"街库网2012年度价值趋势报告发布会暨自主二维码技术与POS终端设备研发成功上市及首轮投资签约仪式"在广州圣丰索菲特酒店成功举办,作为街库发展史上又一里程碑事件,此次发布会标志着街库在O2O领域又取得了突破式进展,其在二维码技术领域所达成的成就奠定了街库在O2O领域的核心优势,这些造诣将助其在本地消费市场开辟出巨大蓝海.街库网CEO潘求辉说:"街库作为中国O2O模式的领军者与践行者,历时六个月,耗资数百万, 终于在20

扫一扫,测真假,阿里与厂商共享二维码技术

阿里巴巴希望与各大厂商共享二维码技术,确保每件商品在生产过程中获得独一的二维码身份证,从生产源头截断造假售假行为. 在货架上拿下一瓶水,打开之前先用手机扫一下瓶盖上的二维码--如果你身边有人这么做,他们很有可能不仅仅是在参与抽奖活动,而且也在查看这瓶水的水质. 最近恒大冰泉出厂的一批产品都覆盖上了自己的身份证明,只要用手机扫描每瓶恒大冰泉瓶盖上的二维码,就可以看到这瓶水的水源地.泉眼以及唯一生产编号.而接下来,恒大市面上的粮油米面等产品也将加入这一计划,每件商品上都会标注一个唯一的二维码,通过手

以色列可视化二维码技术厂商宣布获得阿里巴巴投资

摘要: 21日,以色列可视化二维码技术厂商宣布,获得了中国 阿里巴巴集团 的一笔投资,这是阿里在以色列科技行业的首次投资举动.阿里也将和Visualead公司展开合作,对方的可视化二维码技 21日,以色列"可视化二维码"技术厂商宣布,获得了中国 阿里巴巴集团 的一笔投资,这是阿里在以色列科技行业的首次投资举动.阿里也将和Visualead公司展开合作,对方的可视化二维码技术可能应用到阿里巴巴在国内的电子商务服务中. 据报道,这是Visualead公司的B轮风险投资,目前阿里巴巴投资额度

数据仓库专题(13)-星型模型中事实表作为维表使用面临的问题和解决方法

一.概述       星型模型设计,经常遇到的问题便是,此业务过程之维度,恰恰是另外一个业务过程的事实.最简单的例子如,产品销售业务活动,以订单为事实,以客户.产品.销售人员等为维度:而产品维度,在产品生产业务过程中则作为事实存在.那么问题来了,模型设计时,在逻辑模型层次如何表征这种关系,在物理模型层,又如何实现这种关系.人是活的,技术是死的,条条大道通罗马,没有火车飞机,马可波罗一样来到到了中国.总有解决的办法,但是每种方式都有优劣,在此对比一下吧. 二.可选方案      方案一:构建单独的

数据仓库系列:缓慢渐变维度常见的三种类型及原型设计

在从 OLTP 业务数据库向 DW 数据仓库抽取数据的过程中,特别是第一次导入之后的每一次增量抽取往往会遇到这样的问题:业务数据库中的一些数据发生了更改,到底要不要将这些变化也反映到数据仓库中?在数据仓库中,哪些数据应该随之变化,哪些可以不用变化?考虑到这些变化,在数据仓库中的维度表又应该如何设计以满足这些需要. 很显然在业务数据库中数据的变化是非常自然和正常的,比如顾客的联系方式,手机号码等信息可能随着顾客的所在地的更改发生变化,比如商品的价格在不同时期有上涨和下降的变化.那么在业务数据库中,