维度建模指南.pdf

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