第二次读书报告.docx
《第二次读书报告.docx》由会员分享，可在线阅读，更多相关《第二次读书报告.docx（17页珍藏版）》请在冰豆网上搜索。
第二次读书报告
硕士研究生读书报告
题目缓慢变化维解决方法研究
作者姓名
作者学号
指导教师贝毅君
学科专业大数据1502
所在学院软件学院
提交日期二○一五年十二月
TheResearchOnTheSolutionstoSlowlyChangingDimensions
ADissertationSubmittedto
ZhejiangUniversity
inpartialfulfillmentoftherequirementsfor
thedegreeof
MasterofEngineering
MajorSubject:
SoftwareEngineering
Advisor:
BeiYijun
By
ZhejiangUniversity,P.R.China
2015
摘要
本文主要是对数据仓库中的缓慢变化维问题的解决方法进行研究。
通过查阅资料发现，缓慢变化维问题的主要解决方法总共有六种类型处理方法，它们分别是：
改写属性值；添加维度行；添加维度列；添加历史表；混合模式之可预见的多重变化与不可预见的单重变化；非常规混合模型。
这六种变化类型用于解决不同的缓慢变化维问题，其中变化类型一、二、三这三种是最基本的、最常用的解决缓慢变化维问题的方法；而变化类型四是将历史数据抽取出来单独建立表；变化类型五、六则是通过变化类型一、二、三的不同组合产生的新的方法。
本文通过不同的例子来对缓慢变化维问题的解决方法进行详细的解释。
关键词：
数据仓库，缓慢变化维，变化类型
Abstract
Thisarticleaimstostudyhowtosolvetheslowlychangingdimensionsindatawarehouse.Throughlookingupinformation,themainsolutionstotheproblemsofslowlychangingdimensionshavesixtypes,theyarerewritethepropertyvalue,addthedimensionline,addadimensioncolumns,addshistorytable,amixedmodeofmultiplechangesforeseenorunforeseenchangessinglet,unconventionalhybridmodel.Thesesixtypesofchangeareusedtosolvetheproblemofdifferentslowlychangingdimensions.Themostbasicandmostcommonlyusedmethodstosolvetheproblemofslowlychangingdimensionshavethree.Theyarethetypeofone,thetypeoftwoandthetypeofthree.Thetypeoffouristoseparatehistoricaldatatoestablishasingletable.Thetypeoffiveandsixarenewmethods,theyaremadeofdifferentcombinationsofthetypeofone,thetypeoftwo,thetypeofthree.Inthispaper,foradetailedexplanationofthesolutionstoslowlychangingdimensionsthroughdifferentexamples.
Keywords：
datawarehouse,slowlychangingdimensions,typesofchange
1引言
随着社会的发展，每时每刻产生的数据正在爆炸式的增长着，这就造成了很多信息数据的浪费，数据仓库就在这样的环境下诞生了。
而伴随着数据仓库的产生，在实际应用中，由现实环境引起的数据仓库的问题也露出水面，这就促使人们去寻找解决这些问题的方案。
而缓慢变化维的问题就是因为数据仓库中的数据会随着时间的推移缓慢变化所产生的问题，为了解决这一问题，人们想到了几种变化类型方式来处理这些问题，虽然有些解决方法并不是很好，但是从解决问题的角度来说，它们确实将这些产生的缓慢变化维的问题给解决了。
2维度简单概述以及缓慢变化维含义
维度是与时间有关的，虽然维度表在一段时间中几乎不会变化，但是并不代表着它永远固定不变。
维度表的变化是非常缓慢的，因此，维度设计人员必须富有成效地吸纳业务方面的代表来帮助确定用于变化处理的合适策略，绝不能仅仅因为业务代表不在需求调研区间提到变化处理内容，就简单地得出业务上并不关注维度变化这样的结论。
虽然对精确的变化进行跟踪被认为是不必要的，但是业务用户还是认定数据仓库可以使他们看到每个维度变化所带来的影响[1]。
当需要跟踪变化时，将每件事放在事实表中或者使每个维度都与时间相关，从而处理这些变化的做法是不能让人接受的，这种方式会对数据的可理解性和数据库的查询性能造成严重损失[2]。
我们应该对随时间基本保持不变的有利情况加以充分利用，利用较少的调整就能做到在对变化做出反应的情况下，保持相对独立的维度形式。
缓慢变化维就是这些基本保持不变的维度的称呼，它是RalphKimball首先在1994年提出的概念，简称SCDs。
3缓慢变化维的处理方法
我们必须为维度表的每一个属性指定处理变化的策略，也即是说，如果属性值在操作领域发生了变化，则维度模型将如何对变化做出响应？
下面我们就来讨论三种处理属性变化的基本技术以及它们的混合应用方式。
这样的话就可以对需要在单个维度表范围内混合应用这些技术的情形做出决定。
类型1：
改写属性值
当一个维度值的源发生变化，并且不需要在星型模式中保留变化历史时，通常采用新数据来覆盖旧数据，这个方法有个前提，那就是用户不关心这个数据的变化或者这个数据是错误数据。
这样的处理使属性所反映的总是最新的赋值。
举个例子来说：
下表中的用户出生日期本来应该是1992年3月8日，但是输入时出现错误，这就要对数据进行修改，需要使用类型1响应方法——直接修改数据，用新数据覆盖旧数据，而不是使用别的变化类型来解决下表发生的错误。
该类型变化有很多缺陷，比如：
该方法产生的信息与先前存在的信息不一样，在开发报表的时候如果没有注明执行日期可能会出现混乱；该方法存在不能跟踪维度历史的问题。
用户ID
用户名字
出生日期
住址
修改前
114
李克西
8/9/1998
浙大软院
用户ID
用户名字
出生日期
住址
修改后
114
李克西
8/3/1992
浙大软院
类型1这种响应方法只是处理维度属性变化的最简单方法，快速与方便是它的优势。
在维度表中，仅仅用当前的给定值去改写现有值就可以了。
类型1处理形式的问题在于所有的属性变化历史都会丢失。
改写方法将历史属性值全部抹去了，而只留下当前存在的属性值。
显然，类型1对于起更正作用的属性修改应用是很适合的。
同样，它也适合于没有旧描述值可供保存的场合。
旧属性保留值的确定需要由业务输入来给出，而不应该仅仅根据自己对IT的凭空想象来确定。
项目团队如果以类型1为处理缓慢变化维的默认方式，那么就会丢失历史数据，使得系统不能够存储历史信息。
类型1的响应方式容易实现，但是不能对旧属性值的任何历史数据进行维护。
类型2：
添加维度行
数据仓库的基本目标之一就是要正确地表示过去的历史数据，而类型2响应方式正好就为缓慢变化维提供了这类需求。
绝大多数的操作系统的变化采用的是保留事实的历史环境，并插入新的维度行。
这样用户就能查询到历史情况，便于用户对比数据，从而发现问题。
举个例子来说：
下表中用户搬了家，从浙大软院搬去了上海静安区，那么就不能向上面那样在原来的数据上进行修改了，而是要再增加一行记录来存储信息变化。
虽然多数操作系统都采用这种变化类型，但是它可能会给用户带来一些困惑，比如说：
维度表中包含重复的信息怎么解决，可以通过在select语句中包含distinct来处理；给定的某一自然键在维度表中有多条记录，但不知道何时采用哪一种表示是正确的，这时候就可以引入时间戳来解决问题。
用户ID
用户名字
出生日期
住址
修改前
114
李克西
8/3/1992
浙大软院
编号
用户ID
用户名字
出生日期
住址
修改后
115849
114
李克西
8/3/1992
浙大软院
116748
114
李克西
8/3/1992
上海静安区
在上面的例子中我们不以用户ID来作为主键主要是因为相关记录需要关联，同一个用户的记录，用户ID应该是一样的，它们用同一个用户ID来关联到同一个用户下，用编号来作为主键，这样即使增加一条最新记录，也能够关联到相关用户以及区分历史数据和最新数据。
这里新建的编号是另外一种允许用户迅速将查询约束到当前概况的有效维度属性。
类型2响应方法是准确跟踪缓慢变化维属性的主要方法，这种方法由于新维度行能自动区分事实表的历史而显得特别有效。
类型2形式的响应方法是支持进行准确的历史属性分析的主导技术。
这种方法之所以能够极好地对事实表的历史数据进行区分，原因在于修改前的事实行使用的是修改前的代理关键字。
类型2方法的另一个优势是，可以根据需要便捷地跟踪许多方面的维度变化。
与类型1方法不同，使用类型2响应方法用不着重新访问已有的聚集表。
类型2方法有其缺点，那就是加速了维度表的膨胀。
因此这种方法对于一个已经超过百万行的维度表来说是不合适的。
类型3：
添加维度列
类型2虽然可以区分历史，但是不能将新属性值与旧事实历史联系起来。
然而有时候用户更需要对实际数据方面的变化是否永远不会出现的情形做出了解的功能。
用户可能使用新地区或者新方法来匹配旧数据，这样的话类型2响应方式就不能实现了，需要类型3响应方法来提供支援。
类型3响应方法就是用不同的字段来保存不同的值，实际上就是在后面添加一个字段，这个字段用来保存变化后的属性值，而原来的值则被称为变化前的值。
总的来说这种方法通过添加字段来保存变化后的痕迹，但是这种方法不能像第二种方式一样保存所有的变化记录，它只能保存不超过两次的维度。
在我看来，这个变化类型就是类型2响应方法的衍生产物，实用性比类型2响应方法差多了，除了节约存储空间和将新属性值与旧事实历史相关联外，并没有别的用处，而且对历史的保存还有条件限制，虽然不推荐这个变化类型，但是还是举个通俗易懂的例子来解释下：
就拿上面的例子来说，用户的住址变成上海静安区后，就在原来的记录末尾添加一个字段说明更新后的地址已经变成上海静安区就行了。
编号
用户ID
用户名字
出生日期
住址
修改前
115849
114
李克西
8/3/1992
浙大软院
编号
用户ID
用户名字
出生日期
原住址
现住址
修改后
115849
114
李克西
8/3/1992
浙大软院
上海静安区
类型3响应方法适合于同时强烈需要为两个方面的视图提供支持的应用情形。
有些设计人员将这种情形称做交变体。
在变化或者重定义比较灵活，或者属性是一个人为标记而不是一个物理特征的情况下，会经常遇到这种交变体。
虽然已经出现了变化，但是在逻辑上却仍然可以按没发生变化一样进行处理。
类型3响应方法区别于类型2响应方法的地方在于，当前与以前的描述内容在同一时间都可以看做是成立的。
类型3响应方法用得相当少。
不要错误地认为，类型3响应方法与取值大的类型编号联系在一起就表明它是优先考虑的方法。
这些技术手段不存在以好、较好到最好这种顺序进行排列的情况。
每种响应方法都有自己最适合的时机与场合。
类型3缓慢退化维处理方法可用于任意通过新的或者以前的属性值，了解新的以及历史的实际数据。
类型3响应方法不适合于跟踪大量的中间属性值带来的影响。
显然，因为对于创建反映领域内前次减1、前次减2以及前次减3等时间点所对应状态的属性，存在严重的实施与使用方面的限制，因此索性在应用上放弃分析这些中间值的能力。
如果需要跟踪无穷无尽的不可预见的变化，那么在大多数情况下更应该选用类型2响应方法。
类型4：
添加历史表
类型4响应方法是另外建一个表来保存历史记录，这种方式就是将历史数据与当前数据完全分开来，在维度中只保存当前的数据。
从实用性角度以及数据仓库设计初衷来看，这一变化类型有点偏离了设计初衷，也没有什么实用性。
由于它还是属于缓慢变化维的解决方案的，所以也举个例子来说明一下：
用户搬家去上海静安区了，那么他之前的那个数据记录放到另外一个历史数据库中，而将现今的这条记录放在维度表中。
这种方法只记录了历史的变化痕迹，对于统计运算一点帮助也没有。
编号
用户ID
用户名字
出生日期
住址
维度表
115849
114
李克西
8/3/1992
浙大软院
编号
用户ID
用户名字
出生日期
住址
历史表
115849
114
李克西
8/3/1992
上海静安区
类型5：
混合模式之可预见的多重变化
混合模式顾名思义，就是将基本的缓慢变化维处理技术混合起来使用的方法。
许多IT专业人员对这些技术非常倾心，因为它们看上去好像为各行各业提供了最好的处理手段。
不过，更大的灵活性经常是用更大的复杂性作为代价的。
虽然一些IT专业人员容易被良好的灵活性所打动，但是业务用户却最容易因为复杂性而泄气。
除非业务上需要给出这些需求，否则不应该去追逐这些选项。
混合模式之可预见的多重变化最经常用于处理营销机构重组，与上面几种相比较，这种混合模式更加全面，更能应对错综复杂而且容易变化的用户需求，它是较为常用的一种处理缓慢变化维的方法。
举个例子来说：
将现今搬家的那条记录用时间戳和标记来做记号，并且对是否是最新的信息也进行判断，这样就从多个角度对信息进行说明了。
这种方法的优点是：
一、能用简单的过滤条件选出维度当前的值；二、能较容易的关联出历史任意一时刻事实数据的值；三、如果事实表中有时间字段，那么就能容易的选择哪一条维度数据来进行关联分析了。
但是这种方式也有其弊端存在，那就是事实表与维表之间不是多对一关系，而是多对多关系，这种关系不能在建模的时候解决，只能在报表层面进行解决，需要在报表运行时解决，并且在BI语意层建模时添加时间过滤条件，这样操作比较繁琐。
标识
编号
用户ID
用户名
住址
开始时间
结束时间
是否最新
1
115849
114
李克西
浙大软院
1/9/2015
23/4/2016
否
2
152342
114
李克西
上海静安区
26/4/2016
9/9/9999
是
类型5响应方式常用于地区划分的销售地统计以及人口统计或者别的需要通过不同形式对地区进行不同划分的需求。
举个比较符合情况的例子：
营销机构按年度重新审视其销售地域分布的情形进行研究。
假设5年的时间内，营销机构进行了5次重组。
表面看来，类型2响应方式似乎是处理这种情形的有效方式，但是通过对业务用户的走访发现，他们有一组更为复杂的功能需求，比如：
按当年的区域划分报告每年的销售情况；按任意不同的一年的区域划分报告每年的销售情况等。
这样看来，标准的类型2响应方法因为对历史进行了分隔，因而并不能满足这组功能需求。
一年的实际数据仅仅可以通过采用在一个时间点上给定了区域划分的类型2响应方法而报告出来。
由于用户想同时支持两个以上的划分，标准的类型3响应方法也满足不了这些功能的需要。
根据上面的需求，我们可以这样设计销售地区表。
销售地区统计表
营销代表关键字
营销代表姓名
营销代表地址……
当前地区
2014年地区
2013年地区
……及其他
这种方式就满足了业务用户的需求了，可以查询任意年份的地区销售统计。
它包括了所有以前的区域分配方面的内容。
这里销售人员如果在2014年被解雇，那么2014年以前的该维度属性将含有“不可用”之类的值，对应数据存在，但是销售人员已被解雇，数据没什么意义了。
在这样的表中，设计方式是最新的分配标注为“当前区域”。
这个维度属性将用的最多，同时，用不着为适应下一年的变化而修改现有的查询与报告。
当再度重新划分区域范围时，则需要对表进行修改而增加一个2015年的区域属性。
接下来，用当前区域值对该列进行填充，然后，将2016年的区域分配改写为当前属性。
类型6：
混合模式之不可预见的单重变化
类型6响应方法是通过类型2、类型3以及类型1响应方法组合而成。
它通过类型2来不断增加新的信息，捕获变化内容，然后根据之前的历史信息，再通过类型3响应方法将当前值与历史值加入表中，跟踪当前分配情形，形成历史与当前信息相关联，而后续的变化情况则按照类型1响应方法做出处理。
举个例子来说，如果用户先搬家去了上海静安区，然后又搬了一次家去了成都金牛区，如果用单独的类型1、类型2或者类型3响应方式都不能够实现，所以用组合类型来完成。
首先需要添加新行来记录第一次变化信息，同时将原住址和现住址都改写掉，然后再添加一条记录来保存第二次变化信息，与之前一样，通过修改来改变原住址和现住址的值。
标识
编号
用户ID
用户名
原住址
现住址
1
111
114
李克西
浙大软院
成都金牛区
2
444
114
李克西
上海静安区
成都金牛区
3
888
114
李克西
成都金牛区
成都金牛区
这种响应方式可以非常清晰的显示出变化情况，同时对于历史信息和当前信息的联系也很紧密，非常适合处理那些多次变化历史数据以及跟踪当前分配情况的，虽然比起基本类型复杂了很多，但是还是会经常用到的。
当然，不管怎么样，都应该先从用户的角度考虑问题，从灵活性与复杂性方面找到一种适合的平衡，不然的话，开发人员设计的数据仓库就没有意义了。
类型7：
非常规混合模型
类型7响应方法就是给出一个版本号来标识数据是否为当前存储值，如果是，那么版本号为0；如果不是，那么版本号为非0。
当插入数据的时候就会对之前的数据版本号进行修改，每插入一次，对应的历史记录的版本号就会增加一，这样用户就可以通过版本号来查询指定历史数据。
举个例子来说：
用户之前是住在浙大软院的，现在他去了上海静安区，这时候，浙大软院的记录就是历史数据了，它的版本号会被改写成1，改写后插入新的记录上海静安区，这样就保证了每次插入新的记录的版本号都是0，历史数据的版本号会跟着插入记录的对应条数而增加，方便了对历史数据的管理。
要注意的是，在事实表中插入的数据的版本号全都是0，因为它都是当前进行的统计，用户版本会随着用户信息维度表中的版本号进行改变。
这样就实现了事实表与维度表之间多对多关系了，同时它还有一个优点就是能保证事实表与维表之间的参照完整性，只需要将版本号和用户编号作为复合主键在两实体之间建立连接就可以了。
用户信息维度表
版本
编号
用户ID
用户名
住址
开始时间
结束时间
1
115849
114
李克西
浙大软院
1/9/2015
23/4/2016
0
152342
114
李克西
上海静安区
26/4/2016
9/9/9999
购物事实表
标识
用户外键
用户版本
物品名
个数
购买时间
1
152342
0
书包
1个
26/4/2016
2
152342
0
旺仔牛奶
1箱
26/4/2016
这种方式是通过版本来控制的，方便了用户查询当前数据和历史版本数据的情况，给用户提供了另外一种查询方式，同时查询效率也有所提高，但是这是建立在版本号被知晓的情况下，如果不知道版本号，就需要遍历查询，然后查找信息了。
之前在说到类型2响应方式时，提到过类型2响应方法对于一个已经超过百万行的维度表来说是不合适的。
下面我们通过客户维度表来对数百万行的维度表的变化处理进行分析。
数百万行的客户维度提出了两个需要专门对待的独特挑战。
即使已经实现了一个优美的平面型维度表，一般也会因为在这样的大型表内需要花费太长的时间，而不可以围绕客户关系进行约束或者浏览操作。
此外，使用在以上的几种类型响应方式来跟踪这些大型维度的变化是非常困难的。
设计人员可能不愿使用类型2缓慢变化维方法，向本来就有数百万行的客户维度中添加更多的行。
遗憾的是，巨型客户维度比适度大小的维度更有可能发生变化。
有时，这种情形被称作快变超大维度。
业务用户经常想跟踪无数的客户属性变化。
在有些业务中，跟踪变化并不仅仅是一种可有可无的分析能力。
例如，保险公司必须更新关于它们的客户与特定的投保汽车或者住宅方面的信息，因为在批准一项政策或者做出一个声明时，能够具有关于这些维度的准确描述显得极为关键。
很幸运，有一项技术手段能够在同时应付浏览操作性能与变化跟踪挑战方面提供支援。
解决方法是，将分析频率高或者变化频率大的属性拆成称为微型维度的独立维度。
例如，可以为诸如年龄、性别、子女个数与收入水平这样的一撮人口属性，建立一个单独的微型维度，如果这些列用得很广的话。
该微型维度为数据中遇到的每个由年龄、性别、子女个数与收入水平构成的唯一组合给出一行，而不是为每个客户给出一行。
这些列对应于那些用于进行分析处理以便从客户基数中挑选出一个令人感兴趣的属性子集。
此外，用户还想跟踪在这些属性方面发生的变化。
应该将那些比较恒定的或者查询频率不高的属性遗留在原来的巨型客户表中。
在创建微型维度时，诸如收入与购买总额这样的不断变化的属性，应该被转换成呈波段分部的范围。
换言之，要强迫微型维度中的属性，只能在数目相当小的离散值中取值。
尽管这会将应用限制在一组预定的波段，但它极大地减少了微型维度中的组合值数目。
如果在与其它人口属性进行组合时，将收入以很细的美元与美分值在微型维度中存储起来，那么最后微型维度中将存在与主客户维度本身一样多的行波段范围的采用或许是与微型维度技术手段相联系的最重大的折中，因为一旦将取值波段选定下来，以后再改为一组不同的波段，将显得非常不切实际。
如果用户坚持要存储诸如每月更新一次的商业诚信所打出的分值之类的特定原始数据值，那么除了在人口微型维度中作为取值波段进行表示之外，还应该将它包括在事实表中。
人口微型维度的样本行
1
20-24
男
小于$20,000
2
20-24
男
$20,000-$24,999
3
20-24
男
$25,000-$29,999
18
25-29
男
$20,000-$24,999
19
25-29
男
$25,000-$29,999
每次建立事实表行时，都要包括与客户相关的两个外关键字：
普通客户维度关键字与微型维度人口统计关键字。
如图1所示，为了通过人口统计属性提供对事实表的高效率的存取，人口统计关键字应该是事实表外关键字集合的一部分。
这种设计结构通过提供一个较小的事实表入口，而赢得了浏览与约束操作方面的性能优势。
查询完全能够避开巨型客户维度表，只要不在该表的属性上给出约束条件就可以做到。
当人口
升级会员 