第12章数据仓库与决策支持系统课件

Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,Click to edit Master title style,*,*,第,4,部分 其它高级主题,第,12,章 数据仓库与决策支持系统,高级数据库系统及其应用,第,12,章 数据仓库与决策支持系统,数据仓库技术概述,12.1,OLAP,12.2,OLAP,的实现技术,12.3,视图与决策支持系统,12.4,快速返回部分结果,12.5,2024/10/23,2,12.1,数据仓库技术概述,12.1.1,决策支持查询的新特征,12.1.2,支持决策支持查询的系统类型,12.1.3,数据仓库,2024/10/23,3,12.1.1,决策支持查询的新特征,查询表达的,WHERE,子句通常是包含很多,AND,和,OR,的复杂条件。,传统,RDBMS,针对,OR,的处理能力很弱。,数据分析应用需要广泛使用各种统计函数。,SQL-92,只内置支持的了,min/max/avg/sum/count,五个统计函数，不支持象标准差等一些其它基本统计函数。,完成高级统计需要由嵌入,SQL,的应用代码来完成。,许多查询包括与时间有关的条件，通常需要基于各种典型时间周期进行分析和汇总。,SQL-92,缺乏处理时间序列数据方面的功能支持。,在数据分析应用中，用户可能需要反复提出同一组类似查询。,这不仅枯燥乏味，也使得,DBMS,无法从中识别或发掘查询优化机会。,2024/10/23,4,12.1.2,决策支持查询的系统类型,1,）增强或扩展了,OLAP,特性的,DBMS,OLAP:,OnLine,Analytic Processing,这类系统可高性能支持包含,GROUP-BY,和汇总操作符型式查询，且能对复杂布尔条件、统计函数和时间序列分析提供良好支持。,2,）专用,OLAP,系统,在已有,DBMSs,的基础上，面向决策支持进行优化，以增强支持高效,OLAP,查询的一类专用系统。,随时间推移，专用,OLAP,系统和增强了,OLAP,特性的,RDBMS,系统之间区别可能会越来越小。,3,）数据挖掘,(Data Mining,DM),。,希望从大数据集中探索发现有趣、意外趋势，探索特别数据模式。,2024/10/23,5,12.1.3,数据仓库系统,2024/10/23,6,12.2 OLAP,12.2.1,多维数据模型,12.2.2 OLAP,查询,12.2.3,与,SQL,操作比较,12.2.4,统计数据库,12.2.5 OLAP,设计,2024/10/23,7,12.2.1,多维数据模型,在多维数据模型中，核心数据项是一组事实度量，每个度量依赖于一组维度。,例如，在一个关于销售数据管理的应用中，,sales(,销售数量,),是度量属性。,维度则包括,Product,（产品）、,Location,（地区）和,Time,（时间）。,给定一个产品、一个地区和一个时间点，我们最多只有一个销售值。,图,12.2,一个多维数据集的图形化表示,每个小立方体格点（,cell,）内存储表示一个销售值。,2024/10/23,8,12.2.1,多维数据模型,MOLAP,直接用多维数组来存储多维数据集的,OLAP,专用系统。,MOLAP:multidimensional OLAP,ROLAP,直接关系来存储多维数据集的,OLAP,专用系统。,例如对前述销售管理，可被表示为以下一组关系：,Sales(pid,、,timeid,、,locid,sales),Locations(,locid,:integer,city,:string,state,:string,country,:string);,Products(,pid,:integer,pname,:string,category,:string);,Times(,timeid,:integer,date,:string,week,:integer,month,:integer,quarter,:integer,year,:integer,holiday_flag,:boolean);,2024/10/23,9,12.2.2 OLAP,查询,OLAP,系统的目标是给最终用户提供一个直观且强有力的查询接口，满足一般的面向商务分析任务。,常见的,OLAP,操作是基于多维数据集，在一个或多个维度上的度量值汇总。,一些典型的,OLAP,操作,上卷,(roll up),下钻,(drill-down),绕轴旋转,(pivoting),以下几个查询非常具有典型性，,查销售总额；,查询每个城市的销售总额；,查询每个州的销售总额；,查询销售总额排行前五名的产品类,(,该查询无法,用标准,SQL,语法来表达）。,2024/10/23,10,12.2.3,与,SQL,操作比较,虽然有些,OLAP,查询很难用,SQL,表达，或根本不能用,SQL,表达（如,TOP n,查询）。但大多数的,OLAP,查询都可用,SQL,表达。典型地，它们是一些包含分组和聚合操作的,SQL,语句。,单个,OLAP,操作可能导致几个密切相关的,SQL,查询。例如，对图,12.5,的交叉表，是通过绕轴,(Time,Locatin,),旋转获得。我们也可用下面查询来获得同样的结果：,SELECT,SUM(S.sales),FROM,Sales S,Time T,Locations L,WHERE,S.timeid=T.timeid AND S.locid=L.locid,GROUP BY,T.year,L.state,这个查询产生图,12.5,中灰色背景部分的单元。而该图中最下汇总行和最右汇总列则可分别通过下面两个,SQL,语句获得：,SELECT SUM(S.sales),FROM Sales S,Locations L,WHERE S.locid=L.locid,GROUP BY L.state,SELECT SUM(S.sales),FROM Sales S,Time T,WHERE S.timeid=T.timeid,GROUP BY T.year,2024/10/23,11,12.2.3,与,SQL,操作比较,这个交叉表也可被认为是在,Location,维、时间维、以及同时在,Location,维和时间维上的上卷。每个上卷对应一个带,GROUP BY,的,SQL,查询。,一般来说，给定一个带有,k,个相关维的度量，我们能在任何这,k,个维的子集维上上卷，故我们有总数大约,2k,个这样的,SQL,查询。,一个高层次的操作（象,pivoting,操作），一次可能产生这,2k,个,SQL,查询。分析这些查询的共性，有助于我们更有效地协调计算这组查询集。,一种关于,SQL,的建议扩展称为,CUBE,，它等价于一组,GROUP BY,语句，每个,GROUP BY,语句中包含的相关属性，对应,k,维属性集的一个属性子集。,2024/10/23,12,12.2.3,与,SQL,操作比较,CUBE,使用示例,观察下面这个特殊的扩展查询：,CUBE pid,locid,timeid BY SUM Sales,它将在其所有的八个子集（包括全集,pid,locid,timeid,和空集,）上上卷。,它等价于八个以下形式的操作：,SELECT SUM(S.sales),FROM Sales S,GROUP BY,grouping-list,这些查询只是在,grouping-list,上稍有不同，每个,grouping-list,对应,pid,locid,timeid,的一个子集。我们可将这八个查询想象为被分别对应图,12.6,中的一个栅格节点。每个节点上的结构元组可被进一步聚合来计算它的任何子节点结果。,在一个,CUBE,内，这些查询间的关系可被发掘利用来改善赋值性能。,图,12.6,2024/10/23,13,12.2.4,统计数据库,许多,OLAP,概念已在早期的统计数据库,(statistical databases,SDBs),中得到了体现。,多维数据模型中关于,“,度量关联维度,”,的概念、,“,维值的分类层次结构,”,都早已被用在,SDBs,，上卷和下钻，在,SDBs,中也都有对应的操作。,可能是由于应用领域和使用术语不同，两者的联系并未引起人们足够的注意。,但,OLAP,和,SDB,之间还是有相当程度的区别。例如，,SDBs,主要用在社会经济学领域，对属性概念分类层次和便于针对一些个性问题进行处理非常重要。,SDBs,中分类层次通常比,OLAP,应用中的分类层次更复杂，且受关注的程度更高。,OLAP,则主要面向包含大量数据集的商务应用，比,SDB,更关注高效处理非常大数据集的能力。,2024/10/23,14,12.2.5 OLAP,设计,OLAP,设计一般建议采用以事实表为中心（本例中，事实表为,Sales,），并以事实表主键的各分量属性关联各维表的星型模式。,数据的主体主要存储在事实表中，要求采用无冗余设计，一般要求满足,BCNF,规范。,维表设计不要求满足很高规范（只要求满足,2NF,规范即可）。,降低维表规范虽然可带来一定的冗余，但可显著减少连接操作，有助于提高查询处理的性能。,由于维表中数据量很少，而且变化不大，适度的冗余带来的空间浪费基本上可忽略。,2024/10/23,15,一个典型的星型模式设计示例（图,12.7,）,2024/10/23,16,12.3 OLAP,的实现技术,12.3.1,位图索引,12.3.2,连接索引,12.3.3,文件组织,12.3.4,其它,OLAP,实现问题,2024/10/23,17,12.3.1,位图索引,我们已在,5.5,部分，介绍了位图索引及其相关技术，包括位图压缩技术。,与传统的散列和,B+,树索引相比，位图索引至少有两个重要优势：,1,）允许使用高效的位操作（用位向量的,AND,、,OR,操作）来回答查询；,2,）位图结构比,B+,树结构更紧凑，而且压缩、解压缩操作简单容易。,位图的这些特点和优势，使得它很适合于,OLAP,环境应用，特别是针对那些表结构相对简单、数据量却非常大的事实表建立索引。,2024/10/23,18,12.3.2,连接索引,当关系的数据量很大时，希望用很小的时间计算连接是很难的。处理这个问题的一个方法是，分别为需加快的特定、常用连接查询创建专门索引。,考虑连接查询将事实表,F,与两个维表,D1,、,D2,连接，且表,D1,的,C1,列、表,D2,的,C2,列被包含在选择条件中。,可在连接索引中存储一组形如,元组。这里，,r1,是表,D1,中在,C1,列取值,c1,所对应的那个元组,rid,，,r2,是表,D2,中在,C2,列取值,c2,所对应的那个元组,rid,，,而,r,是事实表,F,中一个元组的,rid,。,r1,r2,和,r,这三个元组被连接在一起。,这种连接索引的主要缺陷是：,索引的大小可能因每个维表有几个列被包含在选择中，而高速增长。,冗余存储代价可能很大。,2024/10/23,19,12.3.3,文件组织,由于许多,OLAP,查询通常只包含一个大数据集关系的几个列，垂直分区因此变得很有吸引力。,然而，分开存储一个关系列值可能降低那些可能包含多个列的查询。,如果在存储整个大关系的同时，也单独存储该大关系的每个列，但这显然会增加存储空间且会带来一致性维护的额外问题。,一种更彻底的文件组织，是将事实表视为一个很大的多维数组，并直接按多维数组进行存储和建立索引。,这个方法已被用在,MOLAP,系统中。,传统,B,+,树索引可用来支持块中元组的快速检索。,2024/10/23,20,12.3.4,其它,OLAP,实现问题,1.,使用压缩已成为面向,OLAP,系统的一个广泛性问题。,2.,决定哪些视图需要进行预计算和存储，使得一些特色查询能得到更快的响应处理也是一个极富有挑战性问题。,汇总查询和操作符丰富的