《数据仓库概念一览》word版

1、.数据仓库概念一览浅析冰山查询 iceberg query在数据仓库领域有一个概念叫Iceberg query，中文一般翻译为"冰山查询"。冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。以销售数据为例，你想产生这样的一个顾客-商品对的列表，这些顾客购置商品的数量到达3件或更多。这可以用下面的冰山查询表示：Select P.cust_ID,P.item_ID,SUMP.qtyFrom Purchase PGroup by P.cust_ID,P.item_ID Having SUMP.qty=3这种在给出大量输入数据元组的情况下，使用havin

2、g字句中的阈值来进展过滤的查询方法就叫做冰山查询。输出结果可以看作"冰山顶"，而"冰山"是输入数据。这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据挖掘的购物篮分析中都经常使用。而且，冰山查询也是面试中出现频率非常高的一道题，经常用来检测SQL才能。操作集市 oper mart在数据仓库领域有一个概念叫Oper Mart，中文一般翻译为"操作集市"。操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储ODS。它是ODS在分析功能上的扩展，使用户可以对操作型数据进展多维分析。一个操作集市应该有如下特征：1.

3、操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表。2.操作集市中的数据和ODS中的数据同步更新。3.操作集市以多维技术进展建模，即星型构造。4.操作集市是一个临时的构造，当不在需要时会清掉所有数据，即不保存历史数据。操作集市和数据集市很相似，但是它不能用来取代用于战略性分析的数据集市。由于操作集市的数据来源于ODS，所以它的数据比数据集市的数据要新。但是出于容量的考虑，操作集市中不保存历史数据，是一个临时的构造。操作数据存储 operational data store Kimball对操作数据存储的定义是，面向主题的、集成的、经常更新的细节数据存储，用集成的数据来支持事务系统。K

4、imball也认可Inmon对ODS的分类，但是他认为ODS应该以星型构造来进展建模。虽然Kimball对操作数据存储ODS的定义和Inmon根本上一样，但是他对操作数据存储的理解、作用与实现和Inmon有着较大的不同。Kimball认为ODS在两种情况下是需要的：第一种情况是提供操作型报表，这些报表需要提供面向主题的、集成的数据，所以操作型的源系统无法提供；这些报表和数据仓库中的报表也不一样，因为它们可以是一些定制好的，写死在程序中的报表。第二种情况是需要提供实时的信息时，由于数据仓库的更新频率一般都是24小时，而用户会有更急迫的需求来理解数据源的信息，这时，建立操作数据存储是很有必要的。对

5、于ODS是保存最细粒度数据的地方的说法，Kimball认为对于最细粒度数据，即原子数据层，应该保存在数据仓库中，而且应该置于维度框架和总线架构中。代理关键字-surrogate key在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为"代理关键字"。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为"代理键"。代理关键字用于维度表和事实表的连接。代理关键字的称呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synth

6、etic keys等。与之相对的自然关键字的称呼有natural keys，samat keys等。在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字Smart Keys。数据仓库中的主键不应该是智能的，也就是说，要防止通过主键的值就可以理解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。使用代理关键字，有很多优点。1.使用代理关键字可以使数据仓库环境对操作型环境的变化进展缓冲。也就是说，当数据仓库需要对来在多个操作型系统的数据进展整合时，这些系统中的数据有可能缺乏一致的关键字编码，

7、即有可能出现重复，这时代理关键字可以解决这个问题。2.使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键联接的效率也很高。3.使用代理关键字可以建立一些不存在的维度记录，例如"不在促销之列"，"日期待定"，"日期不可用"等维度记录。4.使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的施行中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是使用代理关键字。当然，使用代

8、理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。有关使用代理关键字的维度表和事实表的加载方法在ETL Toolkit中有详细的描绘。使用代理关键字是一个从长远考虑的策略。多值维度 multivalue dimension在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为"多值维度"。多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多

9、个对应的顾客，所以不能直接将顾客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于一个安康护理单分列项事实表来说，它的粒度是一个安康护理单，但是该护理单却有可能有屡次诊断，即该事实表与诊断维度的是一对多的关系。这个与事实表粒度不匹配的诊断维度也称之为多值维度。处理多值维度最好的方法是降低事实表的粒度。如第二种情况中，将安康护理单分列项事实表的粒度降低到详细的诊断粒度上，这样就防止了多值维度的出现。这种处理方式也是维度建模的一个原那么，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进展分摊。但是有些

10、时候，事实表的粒度是不能降低的，多值维度的出现是无法防止的。如第一种情况中，事实表是月帐户快照事实表，这张事实表与顾客维度没有直接的关系，不能将数据粒度进展细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进展处理。在帐户维度表和顾客维度表之间建立个帐户-顾客桥接表。这个桥接表可以解决掉帐户维度和顾客维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。总之，多值维度是应该尽量防止的，它给数据处理带来了很大的费事。假设多值维度不能防止的话，应该建立桥接表来进展处理。非事实型事实表 factless fact table在维度建模的数据仓库中，有一种事实表叫Factless Fa

11、ct Table，中文一般翻译为"非事实型事实表"。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进展说明。第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进展跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和获得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以答复大量关于大学开课注册方面的问题，主要是答复各种情况下的注册数。

12、第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以答复如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法答复。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。合并事实表-consolidated/merged fact table在数据仓库领域有一个概念叫merged fact table，或者consolidated fact table，中文一般都翻译为"合并事实表

13、"。合并事实表是将不同事实表的事实合并到同一张事实表的建模方法，合并的事实要保证在一样的粒度。这种建模方法通常被用来横跨多个业务主题域来建立数据集市，Kimball将这样的数据集市称为第二级的数据集市。使用合并事实表技术，可以防止性能较差的穿插探察操作。但是，这种合并事实表和使用穿插探察操作还有着细微的不同，在一些根底表中没有记录的时候，合并事实表中可能会存储一条记录，字段值保存为零。合并事实表可以给数据仓库带来很大的性能提升，提供的跨主题的事实数据也给用户带来了很大的方便。但是，合并事实表给ETL工作带来了较大的费事。对于合并事实表中涉及到的维度，需要在数据准备区保证它们是一致性维

14、度。缓慢变化维 slowly changing dimension维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成"缓慢变化维"，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。处理缓慢变化维的方法通常分为三种方式。第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保存历史数据，无法分析历史变化信息。第一种方式

15、通常简称为"TYPE 1"。第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为"TYPE 2"。第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保存了最后一次变化信息。第三种方式通常简称为"TYPE 3"。在实际建模中，我们可以结合使用三种方式，

16、也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是可以支持方便的分析历史变化情况。即席查询 ad hoc queries在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为"即席查询"。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常查询从SQL语句上来说，并没有本质

17、的差异。它们之间的差异在于，通常的查询在系统设计和施行时是的，所有我们可以在系统施行时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时消费的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。多维数据库有自己的存储方式，对即席查询和通常查询没有区别。在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是一样的，这也是维度建模的一个优点。穿插探察 drill across在维度建模的数据仓库

18、中，有一种操作叫Drill Across，中文一般翻译为"穿插探查"。鉴于经历的局限，在这里我只能进展一下粗浅的分析。在基于总线架构Bus Architecture的维度建模中，大部分的维度表是由事实表共有的。比方"营销事务事实表"和"库存快照事实表"就会有一样的维度表，"日期维度"、"产品维度"和"商场维度"。这时，假设有个需求是想按共有维度来比照查看销售和库存的事实，这时就需要发出两个SQL，分别查出按维度统计出的销售数据和库存数据。然后再基于共有的维度进展外连接，将数据

19、合并。这种发出多路SQL再进展合并的操作就是穿插探查。当这种穿插探查的需求很常用时，有一种建模方法可以防止穿插探查，就是合并事实表Consolidated Fact Table。合并事实表是指将位于不同事实表中处于一样粒度的事实进展组合的一种建模方法。即新建立一个事实表，它的维度是两个或多个事实表的一样维度的集合，事实是几个事实表中感兴趣的事实。这个事实表的数据和其他事实表的数据一样来自Staging Area。合并事实表在性能和易用性上都比穿插探查要好，但是被组合的事实表必须处于一样的粒度和维度层次上。角色模拟维度-role-playing dimensions在数据仓库领域有一个概念叫Ro

20、le-playing dimensions，中文一般翻译为"角色模拟维度"。角色模拟维度是为了处理一个维度在一个事实表中同时出现屡次而使用的一种技术处理手段。在建立了角色模拟维度以后，在底层只有一个物理表存在，但是针对这个物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个角色是不同的。例如对与累计快照事实表中会出现多个日期字段联接到日期维度。这时就可以针对日期维度建立多个角色模拟维度。角色模拟维度的建立方法通常是使用视图来完成。例如订单日期维度表如下所示：CREATE VIEW order_dateorder_date_key,order_day_of_w

21、eek,order_month,AS SELECT data_key,day_of_week,month,FROM DATA使用同样的方式还可以建立多个不同日期的角色模拟维度。需要补充的一点是，目前市场上的大部分展现工具，都提供了对一个表选择屡次的功能。也就是说，角色模拟维度的功能展现工具自己就可以实现。这样，就不需要我们在数据库中建立角色模拟维度的视图了，而直接使用展现工具完成即可。聚集事实表-aggregated fact table累计快照事实表-accumulating snapshot fact table桥接表-bridge table切片事实表-sliced fact table

22、在数据仓库领域有一个概念叫sliced fact table，中文一般翻译为"切片事实表"。切片事实表中的字段构造和相应的根底表完全一样，差异在于存储的记录的范围。切片事实表中保存记录的是相应根底表中记录的子集，记录数通常与某个维度记录数一样。这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的数据，即各个地区都保存自己地区的数据，总部和所有地区的表构造都一样，然后总部将所有地区的数据合并在一起。切片事实表的构造与相对应的根底表一样，数据来源于相对应的根底表。切片事实表由于缩小了表中数据的记录数

23、，所以查询的效率得到了很大的进步。事实表一二 fact table在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。一般来说，以粒度作为化分根据，主要有三种事实表，分别是事务粒度事实表Transaction Grain Fact Table，周期快照粒度事实表Periodic Snapshot Grain Fact Table和累积快照粒度事实表Accumulating Snapshot Grain Fact Table。事务粒度事实表中的一条记录

24、代表了业务系统中的一个事件。事务出现以后，就会在事实中出现一条记录。事务粒度事实表也称为原子粒度。典型的例子是销售单分列项事实表。周期快照粒度事实表用来记录有规律的，可预见时间间隔的业务累计数据。通常的时间间隔可以是每天、每周或者每月。典型的例子是库存日快照事实表。累积快照事实表一般用来涵盖一个事务的生命周期内的不确定的时间跨度。典型的例子是KDT#2中描绘的具有多个日期字段的发货事实表。通常来说，事务和快照是建模中的两个非常重要的特点，将两者相结合可以使模型建立的更完好。从用处的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。原子事实表Atom Fact Table是

25、保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。聚集事实表Aggregated Fact Table是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需要做相应的刷新。物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，详细功能由DBMS来实现。合并事实表Consolidated Fact Table是指将位于不同事实表中处于一样粒度的事实进展组合建模而成的一种事实

26、表。即新建立一个事实表，它的维度是两个或多个事实表的一样维度的集合；事实是几个事实表中感兴趣的事实。在Kimball的总线架构中，由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原子粒度也可以是聚集粒度。在做数据迁移时，当相关的原子事实表的数据有改变时，合并事实表的数据需要重新刷新。合并事实表和穿插探察是两个互补的操作。聚集事实表和合并事实表的主要差异是合并事实表一般是从多个事实表合并而来。但是它们的差异不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能的。因为一般合并事实表需要按一样的维度合并，所以很可能在做合并的同时需要进展聚集，即粒度变粗。事实维度-f

27、act dimension事务事实表-transaction fact table审计维度-audit dimension数据世系 data lineage数据仓库中有一个概念叫做Data Lineage，中文一般翻译为"数据世系"。数据世系描绘的是从源系统抽取数据开场，经过数据转换到最终的数据加载的整个过程中各种信息。数据世系信息需要留下详细的文档记载。数据世系包括源系统的数据库中数据定义以及该数据在数据仓库中的最终位置等信息。数据世系是数据仓库的元数据中最重要的一部分。这部分元数据的产生位置是在ETL的处理过程中。假设在ETL的处理过程中使用的ETL工具的话，ETL工具

28、可以记录下元数据的一部分，但是这部分一般都是数据的属性描绘，而不是完全的数据世系。换一句说，完全依靠ETL工具来维护元数据是不够的。双桶连接-double-barreled joins退化维度 degenerate dimension在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为"退化维度"。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。退化维

29、度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。微型维度 minidimension维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成"微型维度"。微型维度的提出主要是为理解决快变超大维度rapidly changing monster dimension。以客户维度举例来说，假设维度

30、表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE 1型处理。在微型维度表中

31、假设有像收入这样分布范围较广的属性时，应该将它分段处理。比方，存储￥31257.98这样过于分散的数值就不如存储￥30000-￥34999这样的范围。这样可以极大的减少微型维度中的记录数目，也给分析带来方便。蜈蚣事实表 centipede fact table在数据仓库领域有一个概念叫Centipede fact table，中文一般翻译为"蜈蚣事实表"。蜈蚣事实表是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为"蜈蚣事实表"。通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆标准化过了头。例如，不

32、单将产品主键放入事实表中，对于产品层级构造中的每一层的主键都放入事实表中，这样事实表中与产品相关的就会有产品ID、商标ID、子类ID、类别ID等多个外键。同样，也有建模师将日期相关的日期ID、月ID、年ID都放入事实表中。这些都将产生蜈蚣事实表，使自己落入维度过多的陷阱。蜈蚣事实表虽然使查询效率有所进步，但是伴之而来的是存储空间的大量增长。在维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。一般来说，事实表相关的维度在15个以下为正常，假设维度个数超过25个，就出现了维度过多的蜈蚣事实表。这时，需要做的事情

33、是自己核查，将相关的维度进展合并，减少维度的个数。稀疏事实表-sparse facts旋转事实表-pivoted fact table在数据仓库领域有一个概念叫pivoted fact table，中文一般翻译为"旋转事实表"。旋转事实表是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的进步。假设在SQL或者查询工具中进展这种转换会非常费事，效率也很差。和合并事实表类似

34、，有时当根底表中没有记录时，旋转事实表也要存储一些零值在里面。一致性事实 comformed fact维度建模的数据仓库中，有一个概念叫Conformed Fact，中文一般翻译为"一致性事实"。一致性事实是Kimball的多维体系构造MD中的三个关键性概念之一，另两个是总线架构Bus Architecture和一致性维度Conformed Dimension。在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%-90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台Back Room，发生修改时同步复制到

35、每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过穿插探查drill across来实现。为了能在多个数据集市间进展穿插探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。假设业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以穿插探查，一个分布式的数据仓库就建成了。一致性维度 comformed dimension维度建模的数据仓库中，有一个概念叫Conformed Dimension，中文一般翻译为

36、"一致性维度"。一致性维度是Kimball的多维体系构造MD中的三个关键性概念之一，另两个是总线架构Bus Architecture和一致性事实Conformed Fact。在多维体系构造中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。假设分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为理解决这个问题。一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通

37、维度并没有本质上区别，都是经过数据清洗和整合后的结果。一致性维度建立的地点是多维体系构造的后台Back Room，即数据准备区。在多维体系构造的数据仓库工程组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全一样的。建立新的数据集市时，需要在后台进展一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。在同一个集市内，一致性维度的意思是两个维度假设有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，假设建立

38、月维度话，月维度的各种描绘必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。假设维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联络在一起，随时可以进展穿插探察等操作，也就组成了数据仓库。因果维度-casual dimension预连接聚集表 pre-joined aggregate table在数据仓库领域有一个概念叫pre-joined aggregagte t

39、able，中文一般翻译为"预连接聚集表"。预连接聚集表是通过对事实表和维度表的结合查询而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描绘信息和事实表的事实值。通过预连接，可以防止在用户查询时RDBMS的连接操作，所以预连接聚集表的查询效率要高很多。典型的预连接聚集表如下例所示的销售事实表，产品名称商标名称年份月份销售人员名称销售量销售金额在这个销售事实表，前五个字段都来自于维度表的描绘字段，后两个字段来自于事实表的事实字段。这样在用户提交查询后，RDBMS就不需要连接维度表和事实表了，只需直接在该表中查询即可。预连接聚集表有一个很大的缺点，它需要占用大量的存储空间。预连接事实表的记录和事实表一样多，每条记录的长度和维度表一样长，所以对存储空间的需求是非常大的。除非情况特殊，或者该表是高度汇总的，否那么不建议建立预连接聚集表。在建立预连接聚集表时需要平衡效率和存储空间的矛盾。预