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