数据仓库实践培训PPT课件下载推荐.ppt

数据仓库实践培训PPT课件下载推荐.ppt

《数据仓库实践培训PPT课件下载推荐.ppt》由会员分享，可在线阅读，更多相关《数据仓库实践培训PPT课件下载推荐.ppt（17页珍藏版）》请在冰豆网上搜索。

个别事务能够很快地完成，并且只需访问相对较少的数据。

OLTP系统旨在处理同时输入的成百上千的事务。

OLTP系统中的数据主要被组织为支持一些事务性的数据操作，完成基础业务数据的增、删、改及简单的查询操作，这些操作往往是基于关系数据库的数据操作。

包括的应用系统小型的有如MIS、OA系统、电子商务交易系统、财务系统、eHR等；

大型的如ERP、BOSS等。

这类应用系统对响应时间要求比较高，强调的是密集数据更新处理的性能和系统的可靠性及效率。

定义,特征,应用领域,什么是OLAP（联机分析处理）？

联机分析处理（OLAP）的概念最早是由关系数据库之父E.F.Codd于1993年提出的。

当时，Codd认为联机事务处理（OLTP）已不能满足终端用户对数据库复杂查询分析的需要，SQL对大数据库进行的简单查询也不能满足用户分析的需求。

用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求，因此Codd提出了多维数据库和多维分析的概念即OLAP。

OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，OLAP的技术核心就是“维度”这个概念。

基本多维分析操作有钻取（rollup和drilldown）、切片（slice）和切块（dice）、以及旋转（pivot）、drillacross、drillthrough等。

钻取是改变维的层次，变换分析的粒度。

它包括向上钻取（rollup）和向下钻取（drilldown）。

切片和切块是在一部分维上选定值后，关心度量数据在剩余维上的分布。

旋转是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。

ROLAP表示基于关系数据库的OLAP实现（RelationalOLAP）。

以关系数据库为核心,以关系型结构进行多维数据的表示和存储MOLAP表示基于多维数据结构组织的OLAP实现（MultidimensionalOLAP）MOLAP使用多维数组存储数据。

HOLAP表示基于混合数据组织的OLAP实现（HybridOLAP）。

如低层是关系型的，高层是多维矩阵型的。

这种方式具有更好的灵活性。

定义,OLAP操作,OLAP存储,数据仓库架构,数据仓库（DataWarehouseDW）是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库，它的数据基于OLTP源系统。

数据仓库中的数据是细节的、集成的、面向主题的，以OLAP系统的分析需求为目的。

星型模型与雪花模型,数据仓库的架构模型包括了星型架构与雪花型架构两种模式。

如图所示，星型架构的中间为事实表，四周为维度表，类似星星;

而相比较而言，雪花型架构的中间为事实表，两边的维度表可以再有其关联子表，从而表达了清晰的维度层次关系。

从OLAP系统的分析需求和ETL的处理效率两方面来考虑：

星型结构聚合快，分析效率高;

而雪花型结构明确，便于与OLTP系统交互。

因此，在实际项目中，我们将综合运用星型架构与雪花型架构来设计数据仓库。

数据仓库建立“五步法”,一、确定主题,例如：

我们希望分析某年某月某一地区的啤酒销售情况，这就是一个主题。

主题要体现出某一方面的各分析角度（维度）和统计数值型数据（量度）之间的关系，确定主题时要综合考虑。

我们可以形象的将一个主题想象为一颗星星：

统计数值型数据（量度）存在于星星中间的事实表;

分析角度（维度）是星星的各个角;

我们将通过维度的组合，来考察量度。

那么，“某年某月某一地区的啤酒销售情况”这样一个主题，就要求我们通过时间和地区两个维度的组合，来考察销售情况这个量度。

从而，不同的主题来源于数据仓库中的不同子集，我们可以称之为数据集市。

数据集市体现了数据仓库某一方面的信息，多个数据集市构成了数据仓库。

即确定数据分析或前端展现的主题,度量,维度,维度,维度,维度,维度,分析主题：

事实表,数据仓库建立“五步法”,二、确定度量,它们一般为数值型数据。

我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。

量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的设计和计算。

在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类,数据仓库建立“五步法”,三、确定事实数据粒度,例如：

假设目前的数据最小记录到秒，即数据库中记录了每一秒的交易额。

那么，如果我们可以确认，在将来的分析需求中，时间只需要精确到天就可以的话，我们就可以在ETL处理过程中，按天来汇总数据，此时，数据仓库中量度的粒度就是“天”;

反过来，如果我们不能确认将来的分析需求在时间上是否需要精确到秒，那么，我们就需要遵循“最小粒度原则”，在数据仓库的事实表中保留每一秒的数据，以便日后对“秒”进行分析。

在采用“最小粒度原则”的同时，我们不必担心海量数据所带来的汇总分析效率问题，因为在后续建立多维分析模型（CUBE）的时候，我们会对数据提前进行汇总，从而保障产生分析结果的效率。

关于建立多维分析模型（CUBE）的相关问题，我们将在下期栏目中予以阐述。

在确定了量度之后，我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。

考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。

数据仓库建立“五步法”,四、确定维度,这里我们首先要确定维度的层次（Hierarchy）和级别（Level）（图四：

pic4.bmp）。

如图所示，我们在时间维度上，按照“年-季度-月”形成了一个层次，其中“年”、“季度”、“月”成为了这个层次的3个级别;

同理，当我们建立产品维度时，我们可以将“产品大类-产品子类-产品”划为一个层次，其中包含“产品大类”、“产品子类”、“产品”三个级别。

那么，我们分析中所用到的这些维度，在数据仓库中的存在形式是怎样的呢?

我们可以将3个级别设置成一张数据表中的3个字段，比如时间维度;

我们也可以使用三张表，分别保存产品大类、产品子类、产品三部分数据，比如产品维度。

（图五：

pic5.bmp）另外，值得一提的是，我们在建立维度表时要充分使用代理键。

代理键是数值型的ID号码（例如图六中每张表的第一个字段），它唯一标识了每一维度成员。

更重要的是，在聚合时，数值型字段的匹配和比较，JOIN效率高，便于聚合。

同时，代理键对缓慢变化维度有着重要的意义，在原数据主键相同的情况下，它起到了对新数据与历史数据的标识作用。

维度是指分析的各个角度。

例如我们希望按照时间，或者按照地区，或者按照产品进行分析，那么这里的时间、地区、产品就是相应的维度。

基于不同的维度，我们可以看到各量度的汇总情况，也可以基于所有的维度进行交叉分析。

数据仓库建立“五步法”,四、确定维度,在此，我们不妨谈一谈维度表随时间变化的问题，这是我们经常会遇到的情况，我们称其为缓慢变化维度。

比如我们增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。

这样，我们在ETL的过程中，就要考虑到缓慢变化维度的处理。

对于缓慢变化维度，有三种情况：

1、缓慢变化维度第一种类型：

历史数据需要修改。

这种情况下，我们使用UPDATE方法来修改维度表中的数据。

例如：

产品的ID号码为123，后来发现ID号码错了，需要改写成456，那么，我们就在ETL处理时，直接修改维度表中原来的ID号码为456。

2、缓慢变化维度第二种类型：

历史数据保留，新增数据也要保留。

这时，要将原数据更新，将新数据插入，我们使用UPDATE/INSERT。

比如：

某一员工2005年在A部门，2006年时他调到了B部门。

那么在统计2005年的数据时就应该将该员工定位到A部门;

而在统计2006年数据时就应该定位到B部门，然后再有新的数据插入时，将按照新部门（B部门）进行处理，这样我们的做法是将该维度成员列表加入标识列，将历史的数据标识为“过期”，将目前的数据标识为“当前的”。

另一种方法是将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始表匹配生成事实表时将按照时间段进行关联，这种方法的好处是该维度成员生效时间明确。

3、缓慢变化维度第三种类型：

新增数据维度成员改变了属性。

某一维度成员新加入了一列，该列在历史数据中不能基于它浏览，而在目前数据和将来数据中可以按照它浏览，那么此时我们需要改变维度表属性，即加入新的字段列。

那么，我们将使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看。

数据仓库建立“五步法”,五、创建事实表,在确定好事实数据和维度后，我们将考虑加载事实表。

在公司的大量数据堆积如山时，我们想看看里面究竟是什么，结果发现里面是一笔笔生产记录，一笔笔交易记录那么这些记录是我们将要建立的事实表的原始数据，即关于某一主题的事实记录表。

我们的做法是将原始表与维度表进行关联，生成事实表（图六：

pic6.bmp）。

注意在关联时有为空的数据时（数据源脏），需要使用外连接，连接后我们将各维度的代理键取出放于事实表中，事实表除了各维度代理键外，还有各量度数据，这将来自原始表，事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多（粒度最小），而描述性信息尽量少。

如果考虑到扩展，可以将事实表加一唯一标识列，以为了以后扩展将该事实作为雪花型维度，不过不需要时一般建议不用这样做。

事实数据表是数据仓库的核心，需要精心维护，在JOIN后将得到事实数据表，一般记录条数都比较大，我们需要为其设置复合主键和索引，以实现数据的完整性和基于数据仓库的查询性能优化。

事实数据表与维度表一起放于数据仓库中，如果前端需要连接数据仓库进行查询，我们还需要建立一些相关的中间汇总表或物化视图，以方便查询。

什么是ETL?

在数据仓库的构建中，ETL贯穿于项目始终，它是整个数据仓库的生命线，包括了数据清洗、整合、转换、加载等各个过程。

如果说数据仓库是一座大厦，那么ETL就是大厦的根基。

ETL抽取整合数据的好坏直接影响到最终的结果展现。

所以ETL在整个数据仓库项目中起着十分关键的作用，必须摆到十分重要的位置。

ETL是数据抽取（Extract）、转换（Transform）、加载（Load）的简写，它是指：

将OLTP系统中的数据抽取出来，并将不同数据源的数据进行转换和整合，得出一致性的数据，然后加载到数据仓库中。

下图就向我们展示了ETL的数据转换效果。

（图七：

pic7.bmp）那么，在这一转换过程中，我们就完成了对数据格式的更正、对数据字段的合并、以及新增指标的计算三项操作。

类似地，我们也可以根据其他需求，完善数据仓库中的数据。

简而言之，通过ETL，我们可以基于源系统中的数据来生成数据仓库。

ETL为我们搭建了OLTP系统和OLAP系统之间的桥梁。

项目实践技巧,一、准备区的应用,在构建数据仓库时，如果数据源位于一台服务器上，数据仓库在另一台服务器端，考虑到数据源Server端访问频繁，并且数据量大，需要不断更新，所以可以建立准备区数据库（图八