数据仓库概念一览.docx
《数据仓库概念一览.docx》由会员分享，可在线阅读，更多相关《数据仓库概念一览.docx（25页珍藏版）》请在冰豆网上搜索。
数据仓库概念一览
10.171.100.96:
15871/cgi-bin/blockpage.cgi?
ws-session=2099161115
浅析冰山查询――icebergquery
在数据仓库领域有一个概念叫Icebergquery，中文一般翻译为“冰山查询”。
冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。
以销售数据为例，你想产生这样的一个顾客－商品对的列表，这些顾客购买商品的数量达到3件或更多。
这可以用下面的冰山查询表示：
Select P.cust_ID,P.item_ID,SUM（P.qty）
From PurchaseP
Groupby P.cust_ID,P.item_ID
Having SUM（P.qty）>=3
这种在给出大量输入数据元组的情况下，使用having字句中的阈值来进行过滤的查询方法就叫做冰山查询。
输出结果可以看作“冰山顶”，而“冰山”是输入数据。
这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据挖掘的购物篮分析中都经常使用。
而且，冰山查询也是面试中出现频率非常高的一道题，经常用来检测SQL能力。
操作集市――opermart
在数据仓库领域有一个概念叫OperMart，中文一般翻译为“操作集市”。
操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储（ODS）。
它是ODS在分析功能上的扩展，使用户可以对操作型数据进行多维分析。
一个操作集市应该有如下特征：
1．操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表。
2．操作集市中的数据和ODS中的数据同步更新。
3．操作集市以多维技术进行建模，即星型结构。
4．操作集市是一个临时的结构，当不在需要时会清掉所有数据，即不保存历史数据。
操作集市和数据集市很相似，但是它不能用来取代用于战略性分析的数据集市。
由于操作集市的数据来源于ODS，所以它的数据比数据集市的数据要新。
但是出于容量的考虑，操作集市中不保存历史数据，是一个临时的结构。
操作数据存储――operationaldatastore
Kimball对操作数据存储的定义是，面向主题的、集成的、经常更新的细节数据存储，用集成的数据来支持事务系统。
Kimball也认可Inmon对ODS的分类，但是他认为ODS应该以星型结构来进行建模。
虽然Kimball对操作数据存储（ODS）的定义和Inmon基本上一样，但是他对操作数据存储的理解、作用与实现和Inmon有着较大的不同。
Kimball认为ODS在两种情况下是需要的：
第一种情况是提供操作型报表，这些报表需要提供面向主题的、集成的数据，所以操作型的源系统无法提供；这些报表和数据仓库中的报表也不相同，因为它们可以是一些定制好的，写死在程序中的报表。
第二种情况是需要提供实时的信息时，由于数据仓库的更新频率一般都是24小时，而用户会有更急切的需求来了解数据源的信息，这时，建立操作数据存储是很有必要的。
对于ODS是保存最细粒度数据的地方的说法，Kimball认为对于最细粒度数据，即原子数据层，应该保存在数据仓库中，而且应该置于维度框架和总线架构中。
代理关键字－－surrogatekey
在数据仓库领域有一个概念叫Surrogatekey，中文一般翻译为“代理关键字”。
代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。
代理关键字用于维度表和事实表的连接。
代理关键字的称呼有surrogatekeys，meaninglesskeys，integerkeys，nonnaturalkeys，artificialkeys，synthetickeys等。
与之相对的自然关键字的称呼有naturalkeys，samatkeys等。
在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。
在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字（SmartKeys）。
数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信息。
当然，退化维度作为事实表的复合主键之一时例外。
使用代理关键字，有很多优点。
1．使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。
也就是说，当数据仓库需要对来在多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。
2．使用代理关键字可以带来性能上的优势。
和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度。
这样，同样的IO就可以读取更多的事实表记录。
另外，整型字段作为外键联接的效率也很高。
3．使用代理关键字可以建立一些不存在的维度记录，例如“不在促销之列”，“日期待定”，“日期不可用”等维度记录。
4．使用代理关键字可以用来处理缓慢变化维。
维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。
Kimball的缓慢变化维处理策略的核心就是使用代理关键字。
当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。
有关使用代理关键字的维度表和事实表的加载方法在ETLToolkit中有详细的描述。
使用代理关键字是一个从长远考虑的策略。
多值维度――multivaluedimension
在维度建模的数据仓库中，有一种维度表叫multivaluedimension，中文一般翻译为“多值维度”。
多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。
举例来说，一个维度表中，持有人，可能会有多个顾客。
这样，一个对应多个顾客，一个顾客也可以有多个，它们之间是多对多的关系。
正因为一个可能会有多个对应的顾客，所以不能直接将顾客ID放入维度表中。
而维度表中的这种情况就叫做多值维度。
多值维度的第二种情况是事实表在某个维度表中有多条对应记录。
举例来说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。
这个与事实表粒度不匹配的诊断维度也称之为多值维度。
处理多值维度最好的办法是降低事实表的粒度。
如第二种情况中，将健康护理单分列项事实表的粒度降低到具体的诊断粒度上，这样就避免了多值维度的出现。
这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒度上。
这样的处理，需要对事实表的事实进行分摊。
但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。
如第一种情况中，事实表是月快照事实表，这事实表与顾客维度没有直接的关系，不能将数据粒度进行细分，即使细分的话余额也很难分摊。
这时，可以采用桥接表技术进行处理。
在维度表和顾客维度表之间建立个-顾客桥接表。
这个桥接表可以解决掉维度和顾客维度之间的多对多关系，也解决掉的维度表的多值维度问题。
总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。
如果多值维度不能避免的话，应该建立桥接表来进行处理。
非事实型事实表――factlessfacttable
在维度建模的数据仓库中，有一种事实表叫FactlessFactTable，中文一般翻译为“非事实型事实表”。
在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。
在非事实型事实表中没有这些度量事实，只有多个维度外键。
非事实型事实表通常用来跟踪一些事件或者说明某些活动的围。
下面举例来进行说明。
第一类非事实型事实表是用来跟踪事件的事实表。
例如：
学生注册事件，学校需要对学生按学期进行跟踪。
维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。
这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。
第二类非事实型事实表是用来说明某些活动围的事实表。
例如：
促销围事实表。
通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。
这时，通过建立促销围事实表，将商场需要促销的商品单独建立事实表保存。
然后，通过这个促销围事实表和销售事实表即可得出哪些促销商品没有销售出去。
这样的促销围事实表只是用来说明促销活动的围，其中没有任何事实度量。
合并事实表－－consolidated/mergedfacttable
在数据仓库领域有一个概念叫mergedfacttable，或者consolidatedfacttable，中文一般都翻译为“合并事实表”。
合并事实表是将不同事实表的事实合并到同一事实表的建模方法，合并的事实要保证在相同的粒度。
这种建模方法通常被用来横跨多个业务主题域来建立数据集市，Kimball将这样的数据集市称为第二级的数据集市。
使用合并事实表技术，可以避免性能较差的交叉探察操作。
但是，这种合并事实表和使用交叉探察操作还有着细微的不同，在一些基础表中没有记录的时候，合并事实表中可能会存储一条记录，字段值保存为零。
合并事实表可以给数据仓库带来很大的性能提升，提供的跨主题的事实数据也给用户带来了很大的方便。
但是，合并事实表给ETL工作带来了较大的麻烦。
对于合并事实表中涉及到的维度，需要在数据准备区保证它们是一致性维度。
缓慢变化维――slowlychangingdimension
维度建模的数据仓库中，有一个概念叫SlowlyChangingDimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。
缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。
这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。
处理缓慢变化维的方法通常分为三种方式。
第一种方式是直接覆盖原值。
这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。
第一种方式通常简称为“TYPE1”。
第二种方式是添加维度行。
这样处理，需要代理键的支持。
实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。
第二种方式通常简称为“TYPE2”。
第三种方式是添加属性列。
这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE1来直接覆盖。
这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。
第三种方式通常简称为“TYPE3”。
在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持方便的分析历史变化情况。
即席查询――adhocqueries
在数据仓库领域有一个概念叫Adhocqueries，中文一般翻译为“即席查询”。
即席查询是指那些用户在使用系统时，根据自己当时的需求定义的查询。
即席查询生成的方式很多，最常见的就是使用即席查询工具。
一般的数据展现工具都会提供即席查询的功能。
通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。
即席查询与通常查询从SQL语句上来说，并没有本质的差别。
它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。
而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。
即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。
多维数据库有自己的存储方式，对即席查询和通常查询没有区别。
在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。
对称性的数据模型对所有的查询都是相同的，这也是维度建模的一个优点。
交叉探察――drillacross
在维度建模的数据仓库中，有一种操作叫DrillAcross，中文一般翻译为“交叉探查”。
鉴于经验的局限，在这里我只能进行一下浅显的分析。
在基于总线架构（BusArchitecture）的维度建模中，大部分的维度表是由事实表共有的。
比如“营销事务事实表”和“库存快照事实表”就会有相同的维度表，“日期维度”、“产品维度”和“商场维度”。
这时，如果有个需想按共有维度来对比查看销售和库存的事实，这时就需要发出两个SQL，分别查出按维度统计出的销售数据和库存数据。
然后再基于共有的维度进行外连接，将数据合并。
这种发出多路SQL再进行合并的操作就是交叉探查。
当这种交叉探查的需求很常用时，有一种建模方法可以避免交叉探查，就是合并事实表（ConsolidatedFactTable）。
合并事实表是指将位于不同事实表中处于相同粒度的事实进行组合的一种建模方法。
即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合，事实是几个事实表中感兴趣的事实。
这个事实表的数据和其他事实表的数据一样来自StagingArea。
合并事实表在性能和易用性上都比交叉探查要好，但是被组合的事实表必须处于相同的粒度和维度层次上。
角色模仿维度－－role-playingdimensions
在数据仓库领域有一个概念叫Role-playingdimensions，中文一般翻译为“角色模仿维度”。
角色模仿维度是为了处理一个维度在一个事实表中同时出现多次而使用的一种技术处理手段。
在建立了角色模仿维度以后，在底层只有一个物理表存在，但是针对这个物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个角色是不同的。
例如对与累计快照事实表中会出现多个日期字段联接到日期维度。
这时就可以针对日期维度建立多个角色模仿维度。
角色模仿维度的建立方法通常是使用视图来完成。
例如订单日期维度表如下所示：
CREATEVIEWorder_date（order_date_key,order_day_of_week,order_month,…）
ASSELECTdata_key,day_of_week,month,…FROMDATA
使用同样的方式还可以建立多个不同日期的角色模仿维度。
需要补充的一点是，目前市场上的大部分展现工具，都提供了对一个表选择多次的功能。
也就是说，角色模仿维度的功能展现工具自己就可以实现。
这样，就不需要我们在数据库中建立角色模仿维度的视图了，而直接使用展现工具完成即可。
聚集事实表－－aggregatedfacttable
累计快照事实表－－accumulatingsnapshotfacttable
桥接表－－bridgetable
切片事实表－－slicedfacttable
在数据仓库领域有一个概念叫slicedfacttable，中文一般翻译为“切片事实表”。
切片事实表中的字段结构和相应的基础表完全相同，差别在于存储的记录的围。
切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。
这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。
相反，这种方法也常用于合并存储在不同地区的数据，即各个地区都保存自己地区的数据，总部和所有地区的表结构都相同，然后总部将所有地区的数据合并在一起。
切片事实表的结构与相对应的基础表相同，数据来源于相对应的基础表。
切片事实表由于缩小了表中数据的记录数，所以查询的效率得到了很大的提高。
事实表
（一）
（二）――facttable
在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。
事实表中的度量值一般称为事实。
在事实表中最有用的事实就是数字类型的事实和可加类型的事实。
事实表的粒度决定了数据仓库中数据的详细程度。
一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表（TransactionGrainFactTable），周期快照粒度事实表（PeriodicSnapshotGrainFactTable）和累积快照粒度事实表（AccumulatingSnapshotGrainFactTable）。
事务粒度事实表中的一条记录代表了业务系统中的一个事件。
事务出现以后，就会在事实中出现一条记录。
事务粒度事实表也称为原子粒度。
典型的例子是销售单分列项事实表。
周期快照粒度事实表用来记录有规律的，可预见时间间隔的业务累计数据。
通常的时间间隔可以是每天、每周或者每月。
典型的例子是库存日快照事实表。
累积快照事实表一般用来涵盖一个事务的生命周期的不确定的时间跨度。
典型的例子是KDT#2中描述的具有多个日期字段的发货事实表。
通常来说，事务和快照是建模中的两个非常重要的特点，将两者相结合可以使模型建立的更完整。
从用途的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。
原子事实表（AtomFactTable）是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。
聚集事实表（AggregatedFactTable）是原子事实表上的汇总数据，也称为汇总事实表。
即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。
在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需要做相应的刷新。
物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，具体功能由DBMS来实现。
合并事实表（ConsolidatedFactTable）是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表。
即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合；事实是几个事实表中感兴趣的事实。
在Kimball的总线架构中，由合并事实表为主组成的合并数据集市称为二级数据集市。
合并事实表的粒度可以是原子粒度也可以是聚集粒度。
在做数据迁移时，当相关的原子事实表的数据有改变时，合并事实表的数据需要重新刷新。
合并事实表和交叉探察是两个互补的操作。
聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。
但是它们的差别不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能的。
因为一般合并事实表需要按相同的维度合并，所以很可能在做合并的同时需要进行聚集，即粒度变粗。
事实维度－－factdimension
事务事实表－－transactionfacttable
审计维度－－auditdimension
数据世系――datalineage
数据仓库中有一个概念叫做DataLineage，中文一般翻译为“数据世系”。
数据世系描述的是从源系统抽取数据开始，经过数据转换到最终的数据加载的整个过程中各种信息。
数据世系信息需要留下详细的文档记载。
数据世系包括源系统的数据库中数据定义以及该数据在数据仓库中的最终位置等信息。
数据世系是数据仓库的元数据中最重要的一部分。
这部分元数据的产生位置是在ETL的处理过程中。
如果在ETL的处理过程中使用的ETL工具的话，ETL工具可以记录下元数据的一部分，但是这部分一般都是数据的属性描述，而不是完全的数据世系。
换一句说，完全依靠ETL工具来维护元数据是不够的。
双桶连接－－double-barreledjoins
退化维度――degeneratedimension
在维度建模的数据仓库中，有一种维度叫DegenerateDimension，中文一般翻译为“退化维度”。
这种退化维度一般都是事务的编号，如订单编号、发票编号等。
这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。
退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。
退化维度经常会和其他一些维度一起组合成事实表的主键。
在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。
所以对于象销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。
退化维度在分析中可以用来做分组使用。
它可以将同一个事务中销售的产品集中在一起。
微型维度――minidimension
维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维度”。
微型维度的提出主要是为了解决快变超大维度（rapidlychangingmonsterdimension）。
以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。
对于快变超大维度，设计人员一般不会使用TYPE2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。
这时，有一项技术可以解决这个问题。
解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。
这个单独的维度表就是微型维度表。
微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。
有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。
这时一定要注意，这个外关键字必须做TYPE1型处理。
在微型维度表中如果有像收入这样分布围较广的属性时，应该将它分段处理。
比如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的围。
这样可以极大的减少微型维度中的记录数目，也给分析带来方便。
蜈蚣事实表――centipedefacttable
在数据仓库领域有一个概念叫Centipedefacttable，中文一般翻译为“蜈蚣事实表”。
蜈蚣事实表是指那些一事实表中有太多维度的事实表。
连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。
通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规化过了头。
例如，不单将产品主键放入事实表中，对于产品层级结构中的每一层的主键都放入事实表中，这样事实表中与产品相关的就会有产品ID、商标ID、子类ID、类别ID等多个外键。
同样，也有建模师将日期相关的日期ID、月ID、年ID都放入事实表中。
这些都将产生蜈蚣事实表，使自己落入维度过多的陷阱。
蜈蚣事实表虽然使查询效率有所提高，但是伴之而来的是存储空间的大量增长。
在维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。
一般来说，事实表相关的维度在15个以下为正常，如果维度个数超过25个，就出现了维度过多的蜈蚣事实表。
这时，需要做的事情是自己核查，将相关的维度进行合并，减少维度的个数。
稀疏事实表－－sparsefacts
旋转事实表－－pivotedfacttable
在数据仓库领域有一个概念叫pivotedfacttable，中文一般翻译为“旋转事实表”。
旋转事实表是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。
或者反过来，也可以由多条记录转化为一条记录。
旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。
它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。
如果在SQL或者查询工具中进行这种转换会非常麻烦，效率也很差。
和合并事实表类似，有时当基础表中没有记录时，旋转事实表
升级会员 