维表和事实表介绍

1、事实表是数据库中最大的表，是星形模型结构的核心。事实表包含了基本商业事务的详 细信息，是对商务活动进行客户关系、销售趋势和产品趋势等分析的素材。事实表的设计包括对事实的选择、量度的构造、粒度的设计和聚合的设计等。3.5.1事实、度量和事实表事实是各个维度的交点， 是对某个特定事件的度量。 维度中的属性描述的是维本身的属 性，比如客户的性别、年龄、姓名和地址，这些都是客户的固有属性。度量是客户发生事件或动作的事实记录，比如客户打电话，可能选择的度量有通话时长、通话次数和通话费用等；客户购买商品，可能选择的度量有购买的次数、购买商品的金额和购买商品的数量等。 度量变量的取值可以是离散的数值，也可以

2、是连续的数值。比如，客户通话次数是离散的数值，而客户购买商品的金额是连续的数值。度量变量也可以在某个元素集合内取值。比如客户对公司服务质量的评定可以是很好（Excelle nt）、好（Good）、一般（Fair）和差（Poor）中的一个。事实表则是位于星形架构或雪花形架构中间，用来记录商务事实和相应统计指标的表。同维表相比，事实表具有如下的特征。记录数量很多。事实表中除了度量变量外，其他字段都是同维表或者中间表（对于雪花形模型）的关键字。如果事实相关的维度很多，则事实表的字段数也会比较多。从事实表记录数多的特征中， 我们可以得到事实表设计的一个感性认识，即事实表应当尽量减小一条记录的长度， 只

3、有这样才能避免事实表过大而难于管理。 相对维表来说，事实 表是 细长”的结构，如图3-35所示。错误！图3-35事实表的特征3.5.2事实表的设计由以上分析可知，事实表中一般要包含 2部分：一是由主键和外键所组成的键部分，另一部分是用户希望在数据仓库中所了解的数值指标，这些指标是为每个派生出来的键而定义和计算的，称为事实或指标。由于事实是一种度量，所以事实表中的这种指标往往需要具有 数值化和可加性的特征。但是在事实表中，只有那些具有完全可加性的事实才能根据所有的 维度进行累加而具有意义。而事实表有一些事实表示的是某种强度，这类事实就不具有完全加法性，而是一种半加法性。例如，账目余款反映的是某个

4、时间点的数据，它可以按照地点和商品等大多数维度进行累加，但是对于时间维度则例外，将一年中每个月的账目余款进行 累加是毫无意义的，而决策者则可能需要了解所有地区和所有商品账目余款的累加值。在事实表中还有一些事实是非加法性的，即这些事实具有对事实的描述特性，在这种情况下一般要将这些非加法性事实转移到维度表中。以事实表中度量的可加性情况，可以把事实表及其包含的事实分为4种样式。1事务事实事务事实以企业事件的单一情况为基础，因此通常只包含事实的次数这一种度量条件，应该尽可能以最低级别来表示。比如银行的ATM提款机的提款次数，使用某种服务的次数等。2. 快照事实快照事实以企业在某一特定时间的特殊状态为基

5、础。也就是只有在某一段时间内才出现的结果。它们也许没有包含所有维的条件，比如不是所有的产品每天都有销售量。3. 线性项目事实这类事实通常用来储存关于企业经营项目的详细信息。包括表现与企业相关的个别线性项目的所有度量条件，比如销售数量、销售金额、成本和运费等数值数据， 也就是关键性能指标。此类事实运用范围很广，比如采购、销售和库存等。4. 事件（状态事实）这是类特殊的事实，通常只表示事件发生与否和一些非事实本身具备的细节。它所表现的是一个事件发生后的结果变化，并且没有度量数值表示。 如哪些产品在促销期间内没有卖出，有还是没有，就是事件或状态事实所表现的结果。在事实表模型的设计中还需要注意到派生事

6、实。派生事实主要有2种，一种是可以用同一事实表中的其他事实计算得到，例如销售行为中的商品单价可以用商品的销售总金额和销售数量计算得到，对于这些派生事实一般不保留在事实表中；另一种是非加法性事实， 例如各种商品的利润率等各种比率。在事实表模型的设计中必须要考虑到事实表中的这些事实特性，通过多次反复来确定。首先，通过调查确定所有可能的基本事实和派生事实；然后，对所有的事实按照功能或某种方式进行排序，以删除重复的事实； 接着，确认那些基于不同准则但是有相同性质的派生事 实，例如公司门市销售总额与地区销售总额虽由于维度的不同而被定义为不同的事实，但实际计算方法是一样的； 最后，再一次确定事实表模型，

7、在确认中要检查所有的计算派生事实 的基本事实是否已经包含在模型中，并且与用户取得一致。在设计事实表时，一定要注意使事实表尽可能地小，因为过于庞大的事实表在表的处理、备份和恢复及用户的查询等方面需要较长的时间。在实际设计时，可以利用减少列的数量、降低每一列的大小和把历史数据归档到单独的事实表中等多种方法来降低事实表的大小。另外，在事实表中还要解决好数据的精度和粒度的问题，下面将阐释粒度的设计方法。3.5.3粒度的设计在数据仓库中的数据分为 4个级别：早期细节级、当前细节级、轻度综合级和高度综合 级。如图3-36所示，源数据经过综合后，首先进入当前细节级，并根据具体需要进行进一 步综合，从而进入轻

8、度综合级乃至高度综合级，老化的数据将进入早期细节级。从中可以看出，数据仓库中存在着不同的综合级别，这就是粒度”的直观表现。错误!图3-36数据仓库中的数据细节级别粒度模型是数据仓库设计中需要解决的十分重要的问题之一。所谓粒度是指数据仓库中数据单元的详细程度和级别。数据越详细，粒度就越小，级别也就越低；数据综合度越高， 粒度就越大，级别也就越高。1粒度对数据分析的影响1）影响逻辑结构的设计先举一个粒度设计的例子，Adventure Works Cycles公司的管理者想按照国家、区域、分区域和分区域内的销售员这样的层次关系来查看公司的销售情况，按照此需求可以得到如图3-37所示的设计结果。它是通

9、过将地理层次国家、区域和分区域嵌入到销售员维度得到 的。图3-37细化到销售员层次的设计结果如果公司的决策者认为不需要了解具体到某个销售人员的情况，而只需要了解各个地理区域的销售情况，则没有必要把销售员维作为一个维度，把地域相关的表综合成为地理维度就可以了，设计结构如图 3-38所示。由以上实例可知，对事实粒度需求的不同，会直接导致数据仓库逻辑设计的差异。错误！ProiictlDConmtiylD «/RigianlDGwID.iFroductlDKTinuelD.TiswID.*L 伽rCcfuntj-iDMonthRflicrLlD图3-38细化到分区域层次的设计结果2）影响数据

10、的存储粒度对数据仓库最直接的影响就是存储容量。如图3-39所示的例子，按照每 月”统计的客户购买数据和按照每次消费记载的客户购买数据，两者的数据量相差极大。不妨假定每个字段为8个字节，每个客户一天有5次消费，则1个客户1个月的消费细节数据的数据量 为86X30X5= 7200字节，而1个客户1个月的消费汇总数据的数据量为8X4= 32字节。错误！图3-39不同粒度的储存容量示例3）影响分析效果不同的粒度设计对应不同的分析需求，若分析需求和粒度设计不匹配，则会直接影响分析效果。因为数据的综合使得细节信息丢失，所以若分析需求的粒度小于设计的粒度，则需求不可能得到满足；反之，若分析需求的粒度大于设计

11、的粒度，则查询会在更小的粒度上进行统计运算后才能回答，这将增加用户的等待时间。例如在图3-40中，要回答 张某在2007年1月29号是否在北京买了一辆山地车 ”这样 非常细致的问题，细节数据非常合适，而综合数据不可能回答。如果要回答王某在2006年1月到2006年12月自行车配件的总消费是多少”这样综合程度较高的问题时，使用综合数据则可以迅速地回答这个问题。如图3-40综合数据和细节数据的用途和查询代价所示,很好地说明了这一点。错误！ *m-l细节敌君能翦回售的H题， 张握定血丁琳1月游兮是香崔北京 买T-辐山电出T侏合敷据維解回茜的西集血年度丧自祈车上共涓费T器少T .11 ri ixpmA

12、细节融掘回礬合日廳首輕访H大 量的记弟*谡存尢量的计.聲會数据回瞽综悅宦逸.貝盼谕H很专图3-40综合数据和细节数据的用途和查询代价由于数据仓库的主要作用是决策分析，因而大多数查询都基于一定程度的综合数据之 上，而只有少数查询涉及到细节。因此在数据仓库中，设计多重粒度是必不可少的。下面具 体讲解粒度的设计问题。2 粒度的设计技巧由以上的分析可知，数据仓库的性能和存储空间是一对矛盾。如果粒度设计得很小，则事实表将不得不记录所有的细节，储存数据所需要的空间将会急剧的膨胀；若设计的粒度很大，虽然由于事实表体积大而带来的诸多问题能够得到一定程度的缓解，但决策者不能观察细节数据。粒度的设计成了事实表设计

13、中的重要一环。1）设计步骤（1）粗略估算确定合适的粒度级的起点， 可以粗略估算数据仓库中将来的数据行数和所需的直接存取 存储空间，粗略估算可以按照以下步骤完成。 确定数据仓库中将要创建的所有表，然后估计每张表中行的大小（确切大小可能难 以知道，估计一个下界和一个上界就可以了）。 估计一年内表中的最少行数和最多行数。这是设计者所要解决的最大问题。比方说一个顾客表，就应该估计在一定的商业环境和该公司的商业计划影响下的当前的顾客数；如果当前没有业务，就估计为总的市场业务量乘以市场份额； 如果市场份额不可知的话， 就用 竞争对手的业务量来估计。 总之，要从一方或多方收集顾客的合理估算信息开始。 如果数

14、据仓库是用来存放业务活动的话，就要估计顾客数量，以及估计每个时间单位内业务活动量。 同样，可用相同的方法分析当前的业务量、竞争对手的业务量和经济学家的预测报告，等等。一旦估计完一年内数据仓库中数据单位的数量（用上下限推测的方法），就用同样的方法对5年内的数据进行估计。 粗略数据估计完后，就要计算一下索引数据所占的空间。 对每 张表（对表中的每个键码）确定键码的长度和原始表中每条数据是否存在键码。 将各表中行数可能的最大值和最小值分别乘以数据的最大长度和最小长度。另外，还要将索引项的数目与键码的长度的乘积累加到总的数据量中去。（2）确定双重或单一的粒度一旦估计完成后，下一步就要将数据仓库环境中总

15、的行数和表3-8中所示的表格进行比较。根据数据仓库环境中将具有的总的行数的大小，设计和开发必须采取不同的方法。以1年期为例，如果总的行数小于10 000行，那么任何的设计和实现实际上都是可以的。如果1年期总行数是100 000行或更少，那么设计时就需小心谨慎。如果在头一年内总行数超过1000 000行，那么就要请求采取双重粒度级。如果在数据仓库环境中总行数超过10 000 000行的话，必须强制采取双重粒度级，并且在设计和实现中应该小心谨慎。对于5年期数据，行的总数大致依据数量级改变，参见表3-8。表3-8存储空间与粒度设计层次的考虑1年数据5年数据数据量（行数）粒度划分策略数据量（行数）粒度

16、划分策略10 000 000双重粒度并仔细设 计20 000 000双重粒度并仔细设计1 000 000双重粒度10 000 000双重粒度100 000仔细设计1 000 000仔细设计10 000不考虑100 000不考虑（3 ）确定粒度的级别在数据仓库中确定粒度的级别时，需要考虑这样一些因素： 要接受的分析类型、 可接受的数据最低粒度和能存储的数据量。计划在数据仓库中进行的分析类型将直接影响到数据仓库的粒度划分。将粒度的层次定义得越高，就越不能在该仓库中进行更细致的分析。例如，将粒度的层次定义为月份时，就 不可能利用数据仓库进行按日汇总的信息分析。数据仓库通常在同一模式中使用多重粒度。数

17、据仓库中，可以有今年创建的数据粒度和以前创建的数据粒度。 这是以数据仓库中所需的最低粒度级别为基础设置的。例如，可以用低粒度数据保存近期的财务数据和汇总数据，对时间较远的财务数据只保留粒度较大的汇总数据。这样既可以对财务近况进行细节分析，又可以利用汇总数据对财务趋势进行分析，这里的数据粒度划分策略就需要采用多重数据粒度。定义数据仓库粒度的另外一个要素是数据仓库可以使用多种存储介质的空间量。如果存储资源有一定的限制，就只能采用较高粒度的数据粒度划分策略。这种粒度划分策略必须依据用户对数据需求的了解和信息占用数据仓库空间的大小来确定。选择一个合适的粒度是数据仓库设计过程中所要解决的一个复杂的问题，

18、因为粒度的确定实质上是业务决策分析、硬件、软件和数据仓库使用方法的一个折中。在确定数据仓库的粒度时，可以采用多种方法来达到既能满足用户决策分析的需要，又能减少数据仓库的数据量。如果主题分析的时间范围较小，可以保持较少时间的细节数据。例如，在分析销售趋势的主题中，分析人员只利用一年的数据进行比较，那么保存销售主题的数据只需要15个月的就足够解决问题了，不必保存大量的数据和时间过长的数据。还有一种可以大幅降低数据仓库容量的方法.就是只采用概括数据。这样处理后，确实可以降低数据仓库的存储空间，但是有可能达不到用户管理决策分析中对数据粒度的要求。因此，数据粒度的划分策略一定要保证数据的粒度确实能够满足

19、用户的决策分析需要，这是数据粒度划分策略中最重要的 一个准则。2）设计实例下面以类似Adventure Works Cycles公司的生产部门数据仓库设计为例，如图3-41所示。由于对不同的生产业务查询需求的差异，这里采用多重粒度来设计。左边是操作型数据， 记录的是完成若干给定部件的生产线运转情况，每一天都会积累许多记录，是生产业务的详细数据，最近30天的活动数据都存储在操作型的联机环境中。操作型数据的右边是轻度汇总级的数据， 轻度汇总级包括两个表，一个汇总某一部件在 3个月中的生产情况，另一个汇总部件的组装情况，汇总周期为1年。真实档案级的数据包括每个生产活动的详细记录。错误！士产IT草按时

20、否帝任工隹舗褂号哀曲强 便申总量 完威祉辰.1毎的紋馥记逢組還ID 舗禅号 目駆强具缶档克壊郛件号 肋At上产订龍. 擾詁塞 按时否图3-41生产环境的多重粒度3）设计原则粒度在数据仓库生命周期中是重要的考虑因素。它由业务问题所驱动，受技术的制约。 如果粒度太大，就会丢失个别细节， 就要花更多的处理时间来解开聚合；而若粒度太小，就 会由于一叶障目而不见森林，许多宝贵的处理时间都浪费在建立聚合上。因此粒度设计主要是权衡粒度级别，对于业务量大，分析要求比较高的情况下，最佳解决办法则是采用多重粒度的形式。而针对具体的某个事实的粒度而言，应当采用最小粒度原则”即将量度的粒度设置到最小。假设目前的数据最

21、小记录到秒，即数据库中记录了每秒的交易额。那么，如果可以确认，在将来的分析需求中，时间只需要精确到天就可以的话，就可以在ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是天”；反过来，如果不能确认将来的分析需求在时间上是否需要精确到秒，那么，就需要遵循最小粒度原则”精确到 秒”以满足查询的可能需求。3.5.4聚合的设计在事实表中存放的度量变量，根据其实际意义可分成可加性度量变量和非可加性度量 变。可加性度量变量是指将变量相加后得到的结果仍然具有实际意义，可以把此结果计算后放在事实表中，以便在以后的查询中直接使用，这个相加的结果就是聚合。比如每个月的销售金额，通过将3个月的销售金额

22、相加， 就可以得到1个季度的销售金额； 通过将12个月 的销售金额相加，可以得到全年的销售总金额。确定了数据仓库的粒度模型以后，为提高数据仓库的使用性能，还需要根据用户的要求设计聚合。数据仓库中各种各样的聚合数据主要是为了使用户获得更好的查询性能，因此聚合模型的好坏将在很大程度上影响到数据仓库的最终使用效果。在设计聚合模型时，首先需要考虑用户的使用要求，其次要考虑数据仓库的粒度模型和 数据的统计分布情况。数据仓库的一般用户在其日常工作中己经有了按照地理位置、产品类型和时间范围的报告。在数据仓库的聚合设计中，应该对每个维进行审查，以确定哪些属性经常用于分组，这些属性的组合有多少。 例如，如果考虑

23、某一主题有 4个维度，每个维度有3个可以作为聚合 的属性，那么最多可以创建 256个不同的聚合。当然.在实际工作中是没有必要创建这么多 聚合的，只需考虑在数据仓库中经常使用的聚合。此时，可以审查数据仓库的需求分析文档，了解用户的需求情况。 然后确定哪些内容会对聚合有影响，并通过对数据的审核获取每个维度中不同聚合的统计数据。数据仓库的聚合模型的设计与数据仓库的粒度模型紧密相关，如果数据仓库的粒度模型只考虑了细节数据，那么就可能需要多设计一些聚合，如果粒度模型为多层数据则在聚合模型设计中可以少考虑一些聚合。在建立聚合模型时还需要考虑作为聚合属性的数量因素。例如，在数据仓库中有1 000000个值用

24、于描述商品信息的最底层信息，如果用户在使用数据仓库时用500 000个值描述商品最底层的上一层次的信息，此时进行聚合处理并不能明显提高数据仓库的使用性能。但是如果商品上一层次的信息用75 000个值描述，那么就应该使用聚合表提高数据仓库的使用性能。3.5.5数据分割如果粒度和分割都做得很好的话，则数据仓库设计和实现的几乎所有其他问题都容易解 决。但是，假如粒度处理不当并且分割也没有认真地设计与实现，这将使其他方面的设计难以真正实现。数据分割是指把数据分散到各自的物理单元中去，使它们能独立地处理。分割是数据仓库中继粒度问题之后的第2个主要的设计问题。为什么分割如此重要呢？因为小的物理单元能为操作

25、者和设计者在管理数据时提供比对大的物理单元更大的灵活性。数据仓库的本质之一就是灵活地访问数据。如果是大块的数据，就达不到这一要求。因而，对所有当前细节的数据仓库数据都要进行分割。分割的原理类似如图3-42所示，由于全部销售记录过于庞大，可以按照不同的年度把它分为5个小的物理单元。错误！图3-42数据分割处理例如，在第2章用到的foodmart 2000.mdb中，由于设计该数据库的时候考虑到了它将要作为数据仓库使用，因此，对于销售事实按照年份分割成了sales_fact_1997、sales_fact_1998和 sales_fact_dec_1998 3 个表，对库存事实则分割成了inven

26、tory_fact_1997 和inventory_fact_1998 两个表，如图 3-43 所示。rsales_fact_1997 sales fact dec 1998safes fact 1998productjd timejd customer Jd promotion stored store_sales stores ost unit_salesproductjd timejd customend promotion stcre_id store_sales store_cost unit_salesproductjd timed customerjd promotionU st

27、orejd store_sales sto re_cost unit_salesinventory_fact_1998 productjd timejd warehousejd store units_ordered units_shipped wa rehouse_sales warehou$e_co5t supplyjtime storejnvoiceinventory_fact_1997productjdwarehousejd store_id unrts_ardered units_shipped warehouse_sales wa rehouse_co5t supply_time

28、store invoicexoinlx图3-43 Foodmart数据库中的数据分割在工程实践中，除了时间以外，还可以有多种数据分割的标准。例如商务业务、地理位 置和组织单位或者各种标准的综合。3.6规划分析的视角：维度对客户、产品、服务、提供商、地点、渠道和事件发生的时间及对企业来说很重要的其他实体的观察是商业智能的基本驱动力。当它们在一个关系数据库中表示和抽象出来的时 候，它们便叫做维。维是人们观察客观世界的角度，是一种高层次的类型划分。例如如果希 望按照时间，或者按照地区或产品进行分析，那么这里的时间、地区和产品就是相应的维度。 基于不同的维度，可以看到各量度的汇总情况，也可以基于所有的

29、维度进行交叉分析。3.6.1维度的构成在图3-10的星形架构图中可以看到，处于星形结构中央的事实表不仅包含度量，而且也包含维表的外键和事实表的主键。维度表除了代表维之外，还具有字段，例如客户维度表包含一个主键“ CustomerKey和用来向客户提供信息的其他字段。维度由主键和维属性构成。维属性是维表里的列。维元素定义维表中的层次关系，属性则以用户熟悉的术语描述维元素。图3-44显示了维元素和相关属性的关系。图3-44维元素和相关属性的关系在设计过程中，来自数据源的数值数据字段到底是一个已度量的事实还是一个维度的属 性是比较容易混淆的一个问题。一般情况下，在每次抽样时，如果数值数据字段的度量都

30、改 变，那么它就是事实，如果它是某种东西的离散值描述，并几乎保持为常数，那么它就是维属性。3.6.2维度的特性所有的维度都有一些共同特性，它们包括以下几个方面。（1）维存在于关系式的表中，包含了键值和支持的属性，而且属性与所陈述的事实高度相关。对于属性一般使用简单易用的文字信息，不应该有代码或缩写， 没有空值或NULL ,没有无用或过时的数值。（2）维度使用解析过的时间、名字或地址元素，这样可以使你的查询更灵活。比如时 间可分为年、季度、月、周和日等；个人的名字可以分为姓氏和称谓（如先生或小姐）；组 织名可以用部门来区分；地址则可以用地理区域来区分（如国家、州省和、城市）。（3） 不要使用业务

31、数据库的键值，对每个维表另外增加一个额外的惟一值字段作为主键来识别维表实体，通常最常使用的字段类型是Identity类型或者16位格式的全局唯一标识符（Global Unique Identity，GUID ）。这样，就不需要改变 OLTP系统可能会发生的重复 情形，也使得 OLTP系统可以重复使用键值。这个在维表中新设定的键也叫代理键。（4）维表至少包含一个决策因子，每个决策因子字段可以通过使用相关的主键，并结 合事实表的KPI数据来响应用户的查询。(5) 维度表应该包含有随时间变化的数据记录字段，当数据集市或数据仓库的数据随 时间变化而有额外增加或改变时，维表的数据行应该随着维属性的变化而

32、变化。363维度的分类维度主要有4种类型，包括结构维、信息维、分区维和分类维。结构维最为普通，它包含具有层次结构的成员；信息维包含需要计算的属性；分区维用于信息的比较，如计划销售 情况和实际销售情况；分类维用于根据维的属性来分组。此外，还有一些结构上比较特殊的维，如退化维和垃圾维等。1结构维结构维表示在层次结构组成中的信息量度。因此，年、月和日可以组成一个结构维。一个部门将总销售量用作一个度量，便是如何应用结构维的一个例子。 与这个度量相关的是包含涉及产品的所有属性的产品信息表。可以通过产品信息表生成的维可能是“ 、"“ product_brand、“ pro

33、duct_category、 ""product_department和 ”“ product_family。”在此会发现，这个产品维可以组成一个层次结构。增加一个时间信息表，就可以通过由年、月和日组成的时间信息对象建立一个时间维。通过这个度量和2个结构维，可以用SSAS确定一种特殊产品在某一特定时期的销售总量。下面是一些普通的结构维：客户地理位置维这个维可提供一个根据客户所在地进行归类的层次结构。客户维的典型例子是 “ customer_city、” “ customer_state和“ custmer_country。这个维通常用于查看不同的地 理位置在销售、利润和其他

34、客户度量方面的不同。时间维可表明事件发生的时间。典型的时间维应该是年、月和日。销售人员地理位置维这个维可提供一个根据销售人员所在地域进行归类的层次结构。这个维通常用来查看工作在不同地域的销售人员的销售情况和利润等。产品维出售的产品。这个层次结构可能包括“ product_name、 “ product_bra nd、”“ product_category和""product_department。这个维用来查看不同类别的产品的销售利润和其 他指标。所有这些结构维都包含他们所在层次结构的属性。在结构维中层次是非常重要的，所以2.信息维信息维是计算字段建立的。 用户也许想通过销

35、售利润了解所有产品的销售总额。也许希望通过增加销售来获得丰厚的利润。 然而，如果某一款商品降价销售，可能会发现销售量虽 然很大，而利润却很小或几乎没有利润。从另一方面看，用户可能希望通过提高某种产品的价格获得较大利润。 这种产品可能具有较高的利润空间，但销量却可能很低。因此，就利润建立一个维，就销售总量建立一个度量可以提供有用的产品信息。用户可以对利润进行 2种计算。第1种是计算每种商品的平均利润，这一方法很简单， 即用销售价格减去销售人员的开销。知道了每种商品的平均利润之后，还可以用它乘以每一天的销售量从而得到每种商品每一天的总利润。真实世界在实际应用中， 也许需要进行很多项这样的计算，因为

36、每一天的销售价格和开销都有很大差异。因此，需要一个包含每天的销售价格和每天开销情况的表。在用户查看的时间段上，每一天的销售价格和每天的开销情况都是有区别的，需要进行合计并求平均。 某一天每种商品的利润乘以这一天的销售量等于当天的总利润，选定时间段的利润总和为各天的利润之和。创建了一个包括每种商品利润和全部利润的维，就有了一个信息维。3.分区维生成信息表以同一结构生成两个或多个维时，要用到分区维。例如，用户可能要创建用于预测销售额和实际销售额的两个维。这两个维的结构相同，只是数值不同。另一个例子是时间维，每一年有相同的季度，相同的月和相同的天（除了闰年以外，而它不影响维）。在OLAP Servi

37、ces 中，将频繁使用时间分区维来分割数据仓库中的数据。例如：为下列结构生成两个同样的维。the_daythe_ mon ththe_year一个时间维中的数据是针对1998年的，而另一个时间维中的数据针对1999年的。建立事实表时，可以把度量分割为1998年的数据和1999年的数据，这将带来许多益处。4分类维分类维是通过对一个维的属性值分组而创建的。如果客户表中有家庭收入属性，那么， 可能希望查看客户根据收入的购物方式。为此，可以生成一个含有家庭收入的分类维。例如：如果有以下家庭每年收入的数据分组：020 000元、2000140 000元、40 00160 000元、60 001100 0

38、00元和大于100 001元。现在就可以考虑如何度量，例如，从 这些分类中的每一个所购买产品的数量上来看他们的收入水平怎样和购买量怎样。另外一个可能的分类是家庭成员的性别和数量。5.特殊维类型特殊的维主要是在结构上区别于常见的维度，主要有退化维、垃圾维和一致维3类。(1) 当维表中的主键在事实表中没有与外键关联时，这样的维称为退化维。退化维与事实表并无关系，但对于一般在企业事件中跨越维之间数据时，所用到的约束，也就是查询限制条件(比如订单号码、出货单编号等)，这时就常用退化维。以销售分析而言，通常是 把出货日期作为事实的时间，而把订单日期或需求日期等作为查询条件，这里，订单日期或需求日期就是退

39、化维。(2) 垃圾维。针对某企业事件，通常提供了必要的查询值，但是却没有直接映射信息对象产生的维表，这样的字段就是垃圾维。一般来说，如果OLAP系统包含杂乱的标识和文字属性，而且与时间维以外的维表没有关系，就可以使用垃圾维。唯一要注意的是，垃圾维必须是对企业决策潜在限制值非常重要的属性，通常会创建一个维表来存储这些属性。(3) 致维。当有好几个数据集市要合并成一个企业级的数据仓库时，可以使用一致维来集成数据集市以便确定所有的数据集市可以使用每个数据集市的事实。所以，一致维常用于属于企业级的综合性数据仓库，使得数据可以跨越不同的模式来查询。3.6.4维度的层次和级别维”一般包含着层次关系，这种层

40、次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维(dimension )，使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。这里首先要确定维度的层次和级别。如图3-45所示，在时间维度上，按照 年季度月”形成了一个层次，其中年”、季度”和月”成为这个层次的3个级别。同理，当建立产品维度时，可以将 产品大类一产品子类一产品”划为一个层次，其中包含产品大类”、产品子类”和产品”3个级别错误!磁Yrz玄障一月匚图3-45维度的层次和级别分析中所用到的这些具有层次的维度，在数据仓库中的存在形式， 一般说来，有合并维分层结构和雪花分层结构 2种方式。1合并维

41、分层结构合并维分层结构的最显著的特点是将不同分层结构的信息对象完全合并到同一个维中。如产品维表可能就包含产品总类、产品类别、产品详细类别及产品名称等，如图3-46所示。合并维分层结构是星形模式的标准分类法，它有2个特点。(1)查询简单：由于所有的分层结构都合并在同一维表中，因此不需要知道每个分层 结构的表名称，也不需要额外的表连接。(2)需要较多的硬盘存储空间：因为没有做过正规化，所以存在数据重复。图3-46合并维分层结构图3-47时间维合并维分层结构2雪花分层结构这种分层结构类似正规化，所有类别用独立的表来存储数据。也就是将产品详细类别、 产品类别及产品总类这 3个分层结构分别独立成一个表，

42、再用主键与外部键来维持彼此的关 系。如图3-48所示。雪花分层结构把星形模式进行正规化，也因此产生了两种OLAP标准模型，星形模式与雪花模式，它的特点是：节省硬盘空间：因为做过正规化，所以没有冗余数据。查询较复杂：由于所有的分层结构都在不同的表中，因此除了需要进行表连接以外，还需要知道每个分层结构所属的表名。图3-48是产品维度分别保存产品大类、产品子类和产品3部分数据形成的雪花分层结 构。图3-48产品维在数据仓库中的储存形式3.6.5维度的缓慢变化特性及其处理维度可以根据变化剧烈程度主要分为无变化维度、缓慢变化维度和剧烈变化维度。例如一个人的相关信息，身份证号、姓名和性别等信息数据属于不变

43、的部分，政治面貌和婚姻状态属于缓慢变化部分，而工作经历、工作单位和培训经历等在某种程度上属于急剧变化字段。对于剧烈变化维度，通常情况下都是一分为二进行处理的，把其中不常变动的部分单独抽出来作为一个维表，按照缓慢变化维方式进行处理；另外一部分也单独抽取出来，通常作 为维度的属性进行处理。大多数维度表随时间的迁移是缓慢变化的。比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，在设计维度和使用维度的过程中，就要考虑到缓慢变化维度的处理。维度的缓慢变化有 3种不同情况，其对应的处理方法也有所不同。1历史数据需要修改这种情况主要是发生在业务数据库中的数据出现错误，在分析过程中需要修改。处理办法是用直接覆盖法，即使用 UPDATE方法来修改维度表中的数据。例如商店维 度中商店经理是张三，后来错了，需要改写成李四，那么，我们就在ETL处理时，直接修改维度表中原来的商店经理为李四，如图3-49所示。错误!100no