数据仓库概念一览.doc

6:15871/cgi-bin/blockpage.cgi?ws-session=2099161115浅析冰山查询iceberg query在数据仓库领域有一个概念叫Iceberg query，中文一般翻译为“冰山查询”。冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。以销售数据为例，你想产生这样的一个顾客商品对的列表，这些顾客购买商品的数量达到3件或更多。这可以用下面的冰山查询表示：Select P.cust_ID, P.item_ID, SUM(P.qty)From Purchase PGroup by P.cust_ID, P.item_IDHaving SUM(P.qty)=3这种在给出大量输入数据元组的情况下，使用having字句中的阈值来进行过滤的查询方法就叫做冰山查询。输出结果可以看作“冰山顶”，而“冰山”是输入数据。这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据挖掘的购物篮分析中都经常使用。而且，冰山查询也是面试中出现频率非常高的一道题，经常用来检测SQL能力。操作集市oper mart在数据仓库领域有一个概念叫Oper Mart，中文一般翻译为“操作集市”。操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储（ODS）。它是ODS在分析功能上的扩展，使用户可以对操作型数据进行多维分析。一个操作集市应该有如下特征：1操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表。2操作集市中的数据和ODS中的数据同步更新。3操作集市以多维技术进行建模，即星型结构。4操作集市是一个临时的结构，当不在需要时会清掉所有数据，即不保存历史数据。操作集市和数据集市很相似，但是它不能用来取代用于战略性分析的数据集市。由于操作集市的数据来源于ODS，所以它的数据比数据集市的数据要新。但是出于容量的考虑，操作集市中不保存历史数据，是一个临时的结构。操作数据存储operational data storeKimball对操作数据存储的定义是，面向主题的、集成的、经常更新的细节数据存储，用集成的数据来支持事务系统。Kimball也认可Inmon对ODS的分类，但是他认为ODS应该以星型结构来进行建模。虽然Kimball对操作数据存储（ODS）的定义和Inmon基本上一样，但是他对操作数据存储的理解、作用与实现和Inmon有着较大的不同。Kimball认为ODS在两种情况下是需要的：第一种情况是提供操作型报表，这些报表需要提供面向主题的、集成的数据，所以操作型的源系统无法提供；这些报表和数据仓库中的报表也不相同，因为它们可以是一些定制好的，写死在程序中的报表。第二种情况是需要提供实时的信息时，由于数据仓库的更新频率一般都是24小时，而用户会有更急切的需求来了解数据源的信息，这时，建立操作数据存储是很有必要的。对于ODS是保存最细粒度数据的地方的说法，Kimball认为对于最细粒度数据，即原子数据层，应该保存在数据仓库中，而且应该置于维度框架和总线架构中。代理关键字surrogate key在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。代理关键字的称呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synthetic keys等。与之相对的自然关键字的称呼有natural keys，samat keys等。在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字（Smart Keys）。数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。使用代理关键字，有很多优点。1使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说，当数据仓库需要对来在多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。2使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键联接的效率也很高。3使用代理关键字可以建立一些不存在的维度记录，例如“不在促销之列”，“日期待定”，“日期不可用”等维度记录。4使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是使用代理关键字。当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。有关使用代理关键字的维度表和事实表的加载方法在ETL Toolkit中有详细的描述。使用代理关键字是一个从长远考虑的策略。多值维度multivalue dimension在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为“多值维度”。多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。这个与事实表粒度不匹配的诊断维度也称之为多值维度。处理多值维度最好的办法是降低事实表的粒度。如第二种情况中，将健康护理单分列项事实表的粒度降低到具体的诊断粒度上，这样就避免了多值维度的出现。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。这样的处理，需要对事实表的事实进行分摊。但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如第一种情况中，事实表是月帐户快照事实表，这张事实表与顾客维度没有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和顾客维度表之间建立个帐户-顾客桥接表。这个桥接表可以解决掉帐户维度和顾客维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如果多值维度不能避免的话，应该建立桥接表来进行处理。非事实型事实表factless fact table在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。合并事实表consolidated/ merged fact table在数据仓库领域有一个概念叫merged fact table，或者consolidated fact table，中文一般都翻译为“合并事实表”。合并事实表是将不同事实表的事实合并到同一张事实表的建模方法，合并的事实要保证在相同的粒度。这种建模方法通常被用来横跨多个业务主题域来建立数据集市，Kimball将这样的数据集市称为第二级的数据集市。使用合并事实表技术，可以避免性能较差的交叉探察操作。但是，这种合并事实表和使用交叉探察操作还有着细微的不同，在一些基础表中没有记录的时候，合并事实表中可能会存储一条记录，字段值保存为零。合并事实表可以给数据仓库带来很大的性能提升，提供的跨主题的事实数据也给用户带来了很大的方便。但是，合并事实表给ETL工作带来了较大的麻烦。对于合并事实表中涉及到的维度，需要在数据准备区保证它们是一致性维度。缓慢变化维slowly changing dimension维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。处理缓慢变化维的方法通常分为三种方式。第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持方便的分析历史变化情况。即席查询ad hoc queries在数据仓库领域有一个概念叫Ad hoc queries，中文一般翻译为“即席查询”。即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。多维数据库有自己的存储方式，对即席查询和通常查询没有区别。在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的，这也是维度建模的一个优点。交叉探察drill across在维度建模的数据仓库中，有一种操作叫Drill Across ，中文一般翻译为“交叉探查”。鉴于经验的局限，在这里我只能进行一下浅显的分析。在基于总线架构（Bus Architecture）的维度建模中，大部分的维度表是由事实表共有的。比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表，“日期维度”、“产品维度”和“商场维度”。这时，如果有个需求是想按共有维度来对比查看销售和库存的事实，这时就需要发出两个SQL，分别查出按维度统计出的销售数据和库存数据。然后再基于共有的维度进行外连接，将数据合并。这种发出多路SQL再进行合并的操作就是交叉探查。当这种交叉探查的需求很常用时，有一种建模方法可以避免交叉探查，就是合并事实表（Consolidated Fact Table）。合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合的一种建模方法。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合，事实是几个事实表中感兴趣的事实。这个事实表的数据和其他事实表的数据一样来自Staging Area。合并事实表在性能和易用性上都比交叉探查要好，但是被组合的事实表必须处于相同的粒度和维度层次上。角色模仿维度role-playing dimensions在数据仓库领域有一个概念叫Role-playing dimensions，中文一般翻译为“角色模仿维度”。角色模仿维度是为了处理一个维度在一个事实表中同时出现多次而使用的一种技术处理手段。在建立了角色模仿维度以后，在底层只有一个物理表存在，但是针对这个物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个角色是不同的。例如对与累计快照事实表中会出现多个日期字段联接到日期维度。这时就可以针对日期维度建立多个角色模仿维度。角色模仿维度的建立方法通常是使用视图来完成。例如订单日期维度表如下所示：CREATE VIEW order_date(order_date_key, order_day_of_week, order_month, ) AS SELECT data_key, day_of_week, month, FROM DATA使用同样的方式还可以建立多个不同日期的角色模仿维度。需要补充的一点是，目前市场上的大部分展现工具，都提供了对一个表选择多次的功能。也就是说，角色模仿维度的功能展现工具自己就可以实现。这样，就不需要我们在数据库中建立角色模仿维度的视图了，而直接使用展现工具完成即可。聚集事实表aggregated fact table累计快照事实表accumulating snapshot fact table桥接表bridge table切片事实表sliced fact table在数据仓库领域有一个概念叫sliced fact table，中文一般翻译为“切片事实表”。切片事实表中的字段结构和相应的基础表完全相同，差别在于存储的记录的范围。切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的数据，即各个地区都保存自己地区的数据，总部和所有地区的表结构都相同，然后总部将所有地区的数据合并在一起。切片事实表的结构与相对应的基础表相同，数据来源于相对应的基础表。切片事实表由于缩小了表中数据的记录数，所以查询的效率得到了很大的提高。事实表（一） （二）fact table在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表（Transaction Grain Fact Table），周期快照粒度事实表（Periodic Snapshot Grain Fact Table）和累积快照粒度事实表（Accumulating Snapshot Grain Fact Table）。事务粒度事实表中的一条记录代表了业务系统中的一个事件。事务出现以后，就会在事实中出现一条记录。事务粒度事实表也称为原子粒度。典型的例子是销售单分列项事实表。周期快照粒度事实表用来记录有规律的，可预见时间间隔的业务累计数据。通常的时间间隔可以是每天、每周或者每月。典型的例子是库存日快照事实表。累积快照事实表一般用来涵盖一个事务的生命周期内的不确定的时间跨度。典型的例子是KDT#2中描述的具有多个日期字段的发货事实表。通常来说，事务和快照是建模中的两个非常重要的特点，将两者相结合可以使模型建立的更完整。从用途的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。原子事实表（Atom Fact Table）是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。聚集事实表（Aggregated Fact Table）是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需要做相应的刷新。物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，具体功能由DBMS来实现。合并事实表（Consolidated Fact Table）是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合；事实是几个事实表中感兴趣的事实。在Kimball的总线架构中，由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原子粒度也可以是聚集粒度。在做数据迁移时，当相关的原子事实表的数据有改变时，合并事实表的数据需要重新刷新。合并事实表和交叉探察是两个互补的操作。聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。但是它们的差别不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能的。因为一般合并事实表需要按相同的维度合并，所以很可能在做合并的同时需要进行聚集，即粒度变粗。事实维度fact dimension事务事实表transaction fact table审计维度audit dimension数据世系data lineage数据仓库中有一个概念叫做Data Lineage，中文一般翻译为“数据世系”。数据世系描述的是从源系统抽取数据开始，经过数据转换到最终的数据加载的整个过程中各种信息。数据世系信息需要留下详细的文档记载。数据世系包括源系统的数据库中数据定义以及该数据在数据仓库中的最终位置等信息。数据世系是数据仓库的元数据中最重要的一部分。这部分元数据的产生位置是在ETL的处理过程中。如果在ETL的处理过程中使用的ETL工具的话，ETL工具可以记录下元数据的一部分，但是这部分一般都是数据的属性描述，而不是完全的数据世系。换一句说，完全依靠ETL工具来维护元数据是不够的。双桶连接double-barreled joins退化维度degenerate dimension在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。微型维度minidimension维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度（rapidly changing monster dimension）。以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE 1型处理。在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比如，存储￥31257.98这样过于分散的数值就不如存储￥30000￥34999这样的范围。这样可以极大的减少微型维度中的记录数目，也给分析带来方便。蜈蚣事实表centipede fact table在数据仓库领域有一个概念叫Centipede fact table，中文一般翻译为“蜈蚣事实表”。蜈蚣事实表是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。例如，不单将产品主键放入事实表中，对于产品层级结构中的每一层的主键都放入事实表中，这样事实表中与产品相关的就会有产品ID、商标ID、子类ID、类别ID等多个外键。同样，也有建模师将日期相关的日期ID、月ID、年ID都放入事实表中。这些都将产生蜈蚣事实表，使自己落入维度过多的陷阱。蜈蚣事实表虽然使查询效率有所提高，但是伴之而来的是存储空间的大量增长。在维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。一般来说，事实表相关的维度在15个以下为正常，如果维度个数超过25个，就出现了维度过多的蜈蚣事实表。这时，需要做的事情是自己核查，将相关的维度进行合并，减少维度的个数。稀疏事实表sparse facts旋转事实表pivoted fact table在数据仓库领域有一个概念叫pivoted fact table，中文一般翻译为“旋转事实表”。旋转事实表是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在SQL或者查询工具中进行这种转换会非常麻烦，效率也很差。和合并事实表类似，有时当基础表中没有记录时，旋转事实表也要存储一些零值在里面。一致性事实comformed fact维度建模的数据仓库中，有一个概念叫Conformed Fact，中文一般翻译为“一致性事实”。一致性事实是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性维度（Conformed Dimension）。在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。一致性维度comformed dimension维度建模的数据仓库中，有一个概念叫Conformed Dimension，中文一般翻译为“一致性维度”。一致性维度是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。因果维度casual dimension预连接聚集表pre-joined aggregate table在数据仓库领域有一个概念叫pre-joined aggregagte table，中文一般翻译为“预连接聚集表”。预连接聚集表是通过对事实表和维度表的联合查询而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描述信息和事实表的事实值。通过预连接，可以避免在用户查询时RDBMS的连接操作，所以预连接聚集表的查询效率要高很多。典型的预连接聚集表如下例所示的销售事实表，产品名称商标名称年份 2.ETL - 3.数据仓库存储与管理- 4.OLAP - 5.BI工具数据源：是数据仓库系统的数据源泉,通常包括企业各类信息,包括存放于RDBMS中的各种业务处理数据和各类文档数据；各类法律法规、市场信息和竞争对手的信息等等；数据的存储与管理：数据的存储和管理是整个数据仓库的核心，是关键。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。从数据仓库的技术特点着手分析，来决定采用什么产品和技术来建立数据仓库，然后针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。OLAP服务器：对需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：ROLAP（关系型在线分析处理）、MOLAP（多维在线分析处理）和HOLAP（混合型线上分析处理）。ROLAP基本数据和聚合数据均存放在RDBMS之中；MOLAP基本数据和聚合数据均存放于多维数据库中；HOLAP基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。前端工具：主要包括各查询工具、数据分析工具、数据挖掘工具、种报表工具以及各种基于数据仓库或数据集市的应用开发工具。数据分析工具主要针对OLAP服务器。报表工具、数据挖掘工具主要针对数据仓库。数据库和数据仓库有什么区别？1.数据是面向事务处的，数据是由日常的业务产生的，常更新；数据仓库是面向主题的,数据来源于数据库或文件，经过一定的规则转换得到，用来分析的。2.数据库一般是用来存储当前交易数据,数据仓库存储一般存储的是历史数据。3.数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入; .数据仓库的设计一般是星型的，有利于查询。构建企业级数据仓库五步法:一、确定主题 即确定数据分析或前端展现的主题(例:某年某月某地区的啤酒销售情况)。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑.二、确定量度 确定主题后，需要考虑分析的技术指标(例:年销售额等等)。它们一般为数据值型数据，其中有些度量值不可以汇总；些可以汇总起来，以便为分析者提供有用的信息。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性指标(KPI)的设计和计算。三、确定事实数据粒度 确定量度之后，需要考虑该量度的汇总情况和不同维度下量度的聚合情况.例如在业务系统中数据最小记录到秒，而在将来分析需求中，时间只要精确到天就可以了，在ETL处理过程中，按天来汇总数据,些时数据仓库中量度的粒度就是”天”。如果不能确认将来的分析需求中是否要精确的秒，那么，我们要遵循”最小粒度原则”,在数据仓库中的事实表中保留每一秒的数据，从而在后续建立多维分析模型(CUBE)的时候,会对数据提前进行汇总，保障产生分析结果的效率。四、确定维度维度是分析的各个角度.例:我们希望按照时间，或者按照地区，或者按照产品进行分析。那么这里的时间，地区，产品就是相应的维度。基于不同的维度，可以看到各个量度汇总的情况，也可以基于所有的维度进行交叉分析。维度的层次(Hierarchy)和级别(Level)。例:在时间维度上，按照”度-季度-月”形成了一个层次，其中”年” ,”季度” ,”月”成为了这个层次的3个级别。我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。 我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度；我们也可以使用三张表，分别保存产品大类，产品子类，产品三部分数据,比如产品维度。 建立维度表时要充分使用代理键.代理键是数据值型的ID号码(每张表的第一个字段)，它唯一标识了第一维度成员。在聚合时，数值型字段的匹配和比较，join效率高。同时代理键在缓慢变化维中，起到了对新数据与历史数据的标识作用。五、创建事实表 在确定好事实数据和维度后，将考虑加载事实表。业务系统的的一笔笔生产，交易记录就是将要建立的事实表的原始数据. 我们的做法是将原始表与维度表进行关联，生成事实表。关联时有为空的数据时(数据源脏)，需要使用外连接，连接后将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各度量数据，不应该存在描述性信息。 事实表中的记录条数据都比较多，要为其设置复合主键各蛇引，以实现数据的完整性和基于数据仓库的查询性能优化。元数据:描述数据及其环境的数据。两方面用途:首先,元数据能提供基于用户的信息,如记录数据项的业务描述信息的元数据能帮助用户使用数据。其次,元数据能支持系统对数据的管理和维护,如关于数据项存储方法的元数据能支持系统以最有效的方式访问数据。元数据机制主要支持以下五类系统管理功能:（）描述哪些数据在数据仓库中；（）定义要进入数据仓库中的数据和从数据仓库中产生的数据；（）记录根据业务事件发生而随之进行的数据抽取工作时间安排；（）记录并检测系统数据一致性的要求和执行情况；（）衡量数据质量。ODS: Operational Data StoreODS为企业提供即时的，操作型的，集成的数据集合，具有面向主题性，集成性，动态性，即时性，明细性等特点ODS作为数据库到数据仓库的一种过渡形式，与数据仓库在物理结构上不同，能提供高性能的响应时间,ODS设计采用混合设计方式。ODS中的数据是实时值,而数据仓库的数据却是历史值，一般ODS中储存的数据不超过一个月，而数据仓库为10年或更多.Data Mart为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。DDS(decision-support system)决策支持系统：用于支持管理决策的系统。通常，DSS包括以启发的方式对大量的数据单元进行的分析，通常不涉及数据更新。三什么叫OLAP？用途是什么？联机分析处理,On-Line Analysis Processing即从数据仓库中抽取详细数据的一个子集并经过必要的聚集,存储到OLAP存储器中供前端分析工具读取。OLAP系统按照数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。ROLAP将分析要用的多维数据存储在关系数据库中,并根据应用的需要有选择的定义一批实视图也存储在关系数据库中MOLAP将OLAP分析所要用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。HOLAP能把MOLAP和ROLAP两种结构的优点有机的结合起来,能满足用户各种复杂的分析请求。OLTP与OLAP的区别 OLTP OLAP用户 操作人员 决策人员功能 日常操作 分析决策DB设计 面积应用 面向主题数据 当前的，最新的，细节的，二维的 历史的，概括的,多维集成的，统一的存取及规模 读取少 大规模读事实表事实表是包含大量数据值的一种结构。事实数据表可能代表某次银行交易,包含一个顾客的来访次数，并且这些数字信息可以汇总，以提供给有关单位作为历史的数据。每个数据仓库都包含一个或者多个事实数据表。事实数据表只能包含数字度量字段和使事实表与维度表中对应项的相关索引字段.，该索引包含作为外键的所有相关性维度表的主键。事实数据表中的“度量值”有两中：一种是可以累计的度量值，另一种是非累计的度量值。用户可以通过累计度量值获得汇总信息。维度表用来描述事实表的某个重要方面，维度表中包含事实表中事实记录的特性：有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构缓慢变化维:在实际情况下，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。处理方法: 1新信息直接覆盖旧信息，2,保存多条记录，并添加字段加以区分（用y,n;0,1,2或用时间来区别新旧记录）3.保存多条记录，并添加字段加以区分4.另外建表保存历史记录.5混合模式退化维般来说事实表中的外键都对应一个维表，维的信息主要存放在维表中。但是退化维仅仅是事实表中的一列，这个维的相关信息都在这一列中，没有维表与之相关联。比如：发票号，序列号等等。那么退化维有什么作用呢？1、退化维具有普通维的各种操作，比如：上卷，切片，切块等(上卷汇总，下钻明细；切片，切块:对二维数据进行切片，三维数据进行切块,可得到所需要的数据)2、如果存在退化维，那么在ETL的过程将会变得容易。3、它可以让group by等操作变得更快粒度:（granularity）是指数据仓库的数据单位中保存数据的细化或综合程度的级别，细化程度越高，粒度就越小。钻取:首先从某一个汇总数据出发，查看组成该数据的各个成员数据。KPI（Key Performance Indication）关键业绩指标用来衡量业绩好坏比如销售这个主题,销售增长率、销售净利润就是一个KPIE T Lextract/transformation/load寻找数据，整合数据，并将它们装入数据仓库的过程。ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析的依据。工作流 抽取清洗,转换加载 数据流 业务系统ODS数据仓库一.抽取方法有三种:1.利用工具,例如datastage，informatic，OWB，DTS，SISS. 2，利用存储过程. 3,前两种工具结合.抽取前的调研准备工作:1.