《bi维度建模指南》由会员分享，可在线阅读，更多相关《bi维度建模指南（32页珍藏版）》请在金锄头文库上搜索。
1、bi维度建模指南维度建模指南1.基础术语2.维度建模中的三种模型3.维度的类型4.事实的类型5.维度建模的一般过程每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行一般事实表中只存放数字或者一些Flag用来统计(Count)，如收益、数量、支出等销售事实收益数量支出毛利维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。客户维时间维商场维产品维销售事实时间ID客户I
2、D产品ID商场ID收益数量支出毛利粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。设计粒度是设计数据仓库中的一个重要的前提层次指描述明细数据的层次星形模型(Star Schema)雪花模型(Snowflake Schema)多维模型(Multi-dimension Schema)数据或展现的安全性复杂的查询和分析事实被维度所包围，且维度没有被新的表连接客户维时间维商场维产品维销售事实时间ID客户ID产品ID商场ID收益数量支出毛利星形模型是一个比较折中的的建模方式(BI APPS中都是用的是星形的建模方式)事实表被多个维
3、表或一个或多个层次所包围客户维时间维商场维产品维销售事实时间ID客户ID产品ID商场ID收益数量支出毛利联系人维联系人维雪花模型一般在处理大的且相对静态的层次的时候使用层次数据库，只有一个结构(立方体Cube)相当于一个多维数组。它包含了所有数据在各种级别的汇总需要特定的多维数据库或者多维数据库引擎(Essbase)的支持数据存储空间的问题：当新添加一个维度的时候，数据的量便会成指数增长缓慢变化维(Slowly Changing Dimension)快速变化维(Rapidly Changing Dimension)大维(Huge Dimension)和迷你维(Mini-Dimension)退化
4、维(Degenerate Dimension)大多数的维度的内容都会有不同程度的改变。比如： 雇员的升职 客户更改了他的名称或地址我们如何去处理这些维度中的变化呢？下面提供了三个处理缓慢变化维的方式 直接更新到原先记录中 标记记录有效时间的开始日期和结束日期，加入版本控制 在记录中添加一个字段来记录历史客户Simmy将自己的地址由原先的Addr1改为Addr2。这时我们需要将这个记录了客户Simmy的记录中Address从Addr1更新为Addr2，且不记录历史ID:111Name:SimmyAddress:Addr1ID:111Name:SimmyAddress:Addr2OLDNEW记录I
5、D为111的客户Simmy的信息的记录中地址直接更改为Addr2，不保存历史Addr1客户Simmy将自己的地址由原先的Addr1改为Addr2。这时我们需要将这个记录了客户Simmy的记录中的有效截止日期改为现在，并重新添加一条有效截止日期为现在的和一个新的版本号且Address为Addr2的记录ID:111Version:1Name:SimmyAddress:Addr1Effective Start Date:2007-4-21Effective End Date:NowID:111Version:2Name:SimmyAddress:Addr2Effective Start Date:N
6、owEffective End Date:NullID:111Version:1Name:SimmyAddress:Addr1Effective Start Date:2007-4-21Effective End Date:Null更新为添加新的记录客户Simmy将自己的地址由原先的Addr1改为Addr2。这时我们需要将这个记录了客户Simmy的记录中的现在使用的Address变为Addr2，将Addr1放入原始的字段中ID:111Name:SimmyCurrent Address:Addr1Old Address:NullID:111Name:SimmyCurrent Address:Ad
7、dr2Old Address:Addr1当某个维度的变化是非常快的时候，我们认定他为快速变化维(具体要看实际的变化频率)，比如： 产品的价格，地产的价格等对于这种快速变化维的变化捕获应该在实施中进行捕获而不是维度中数据仓库中最有意思的维度是一些非常大的维度，比如客户，产品等等。一个大的企业客户维度往往有上百万记录，每条记录又有上百个字段。而大的个人客户维度则会超过千万条记录，这些个人客户维度有时也会有十多个字段，但大多数时候比较少见的维度也只有不多的几个属性。大维度需要特殊的处理。由于数据量大，很多涉及大维度数据仓库功能可能会很慢，效率很低。你需要采用高效率的设计方法、选择正确的索引、或者采用
8、其它优化技术来处理以下问题，包括： 向大维度表填充数据 非限制维度的浏览性能，尤其是那些属性较少的维度 多限制的维度属性值的浏览时间 涉及大维度表的对事实表查询的低效率问题 为处理第二类修改所需要增加的额外的记录将常用的大维度中的少数字段提取出来，形成一个字段少的维度，在查询的时候便可以使用迷你维中的字段这样的设计明显提高查询效率粒度事实表(Additive Fact)周期快照事实表(Semi-Additive Fact)聚合快照事实表(Non-Additive Fact)非事实事实表(Factless Fact Table)表示的是在特定时间、空间点上的一次瞬间的测量。与粒度同层次的事实表，
9、可以直接将事实字段进行Sum, Count等聚合操作客户维时间维商场维产品维销售事实时间ID客户ID产品ID商场ID价格周期快照事实表表现的是一个时间段，或者规律性的重复。这类表非常适合跟踪长期的过程，例如银行账户和其他形式的财务报表。最常用的财务上的周期快照事实表通常有一个月粒度。在周期快照事实表中的数据必须符合该粒度（就是说，他们必须量测的是同一个时间段中的活动）。对于一个好的周期快照事实表来说就是在粒度上有更多的事实。银行中帐户检查的周期快照代理键代理键(WID)(WID)月(FK)账户(FK)机构(FK)家庭成员(FK)期末余额(Fact)变更余额(Fact)日平均额(Fact)保证金
10、数(Fact)保证金总计(Fact)回收款数(Fact)(Fact)聚合快照事实表用于描述那些有明确开始和结束的过程，例如合同履行，保单受理以及常见的工作流。聚合快照不适合长期连续的处理，如跟踪银行账户或者描述连续的生产制造过程，如造纸。聚合快照事实表的粒度是一个实体从其创建到当前状态的完整的历史。代理键代理键(WID)(WID)请求发货日期(FK)实际发货日期(FK)交付日期(FK)退货日期(FK)结算日期(FK)仓库(FK)客户(FK)产品(FK)固定价格清单(Fact)额外补助(Fact)支付数量(Fact)退还数量(Fact)货物净利数(Fact)标准假设每个事实表的粒度是一个事件量测
11、。用来描述数据或事件。事件可以发生，但是没有具体的测量值。事故事件事故事件(FK)(FK)位置(FK)事故类型(FK)事故当事人组(FK)原告组(FK)证人组(FK)事故当事人组事故当事人组(FK)(FK)事故当事人(FK)事故角色原告组原告组(FK)(FK)原告(FK)原告角色证人组证人组(FK)(FK)证人(FK)证人角色事故当事人事故当事人PK)PK)属性.原告原告PK)PK)属性.证人证人(PK)(PK)属性.1 确定每个事实表的粒度2 确定维度的属性3 确定维度的层次4 确定每个事实所需要关联的维度5 确定事实，包括预先计算的6 确定缓慢变化维确定详细数据的粒度级别此过程必须是在建模
12、之前最需要考虑的问题比较典型的粒度指的是单独的，基于时间的或聚集在一个常用的维度的事务去定是否需要同时存储编号和描述，或者只是编号，或者只是描述的信息确定哪些字段的值需要被筛选掉或者需要存在对于时间维度，我们需要确定的是年，季度，月，周，日等不同的层次对于产品维度，我们需要确定的是产品大类，产品小类，产品等不同的层次需要注意的是比如在销售中，地理位置的层次可能和真正的地理位置的层次会有不同通常的维度包括时间，产品，投保人，代理人，和地理等常见对象请注意，创建的维度需要和与其连接的事实的粒度保持一致需要根据具体业务来确定事实及其量度对于每个聚合事实需要在应用(ETL)过程中进行计算根据需求，对缓慢变化维进行相应的处理比如： 对于一个需求为不保留历史的客户维度，我们使用第一种类型的缓慢变化维来处理 对于一个需求为需要保留历史的产品维度，我们需要使用第二种类型的缓慢变化维来处理 在常规的数据流传递途径上，第三种方式不经常出现，相反,他们经常是一种ETL 团队成员间口头上执行决定
