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

1、第4部分 其它高级主题第12章 数据仓库与决策支持系统高级数据库系统及其应用第1页，共31页。第12章 数据仓库与决策支持系统数据仓库技术概述12.1OLAP12.2OLAP的实现技术12.3视图与决策支持系统12.4快速返回部分结果12.52022/7/292第2页，共31页。12.1 数据仓库技术概述12.1.1 决策支持查询的新特征 12.1.2 支持决策支持查询的系统类型 12.1.3 数据仓库2022/7/293第3页，共31页。12.1.1 决策支持查询的新特征查询表达的WHERE子句通常是包含很多AND和OR的复杂条件。传统RDBMS针对OR的处理能力很弱。数据分析应用需要广泛使

2、用各种统计函数。SQL-92只内置支持的了min/max/avg/sum/count五个统计函数，不支持象标准差等一些其它基本统计函数。完成高级统计需要由嵌入SQL的应用代码来完成。许多查询包括与时间有关的条件，通常需要基于各种典型时间周期进行分析和汇总。SQL-92缺乏处理时间序列数据方面的功能支持。在数据分析应用中，用户可能需要反复提出同一组类似查询。这不仅枯燥乏味，也使得DBMS无法从中识别或发掘查询优化机会。 2022/7/294第4页，共31页。12.1.2 决策支持查询的系统类型1）增强或扩展了OLAP特性的DBMSOLAP: OnLine Analytic Processing这

3、类系统可高性能支持包含GROUP-BY和汇总操作符型式查询，且能对复杂布尔条件、统计函数和时间序列分析提供良好支持。2）专用OLAP系统在已有DBMSs的基础上，面向决策支持进行优化，以增强支持高效OLAP查询的一类专用系统。随时间推移，专用OLAP系统和增强了OLAP特性的RDBMS系统之间区别可能会越来越小。3）数据挖掘(Data Mining, DM)。希望从大数据集中探索发现有趣、意外趋势，探索特别数据模式。 2022/7/295第5页，共31页。12.1.3 数据仓库系统2022/7/296第6页，共31页。12.2 OLAP12.2.1 多维数据模型 12.2.2 OLAP查询12

4、.2.3 与SQL操作比较12.2.4 统计数据库 12.2.5 OLAP设计2022/7/297第7页，共31页。12.2.1 多维数据模型 在多维数据模型中，核心数据项是一组事实度量，每个度量依赖于一组维度。例如，在一个关于销售数据管理的应用中， sales (销售数量)是度量属性。维度则包括Product（产品）、Location（地区）和Time（时间）。给定一个产品、一个地区和一个时间点，我们最多只有一个销售值。 图12.2 一个多维数据集的图形化表示 每个小立方体格点（cell）内存储表示一个销售值。 2022/7/298第8页，共31页。12.2.1 多维数据模型MOLAP直接用

5、多维数组来存储多维数据集的OLAP专用系统。MOLAP: multidimensional OLAPROLAP直接关系来存储多维数据集的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

6、: string , week : integer , month : integer, quarter : integer, year : integer, holiday_flag : boolean);2022/7/299第9页，共31页。12.2.2 OLAP查询OLAP系统的目标是给最终用户提供一个直观且强有力的查询接口，满足一般的面向商务分析任务。 常见的OLAP操作是基于多维数据集，在一个或多个维度上的度量值汇总。一些典型的OLAP操作上卷(roll up)下钻(drill-down)绕轴旋转(pivoting) 以下几个查询非常具有典型性，查销售总额；查询每个城市的销售总额；查

7、询每个州的销售总额；查询销售总额排行前五名的产品类 (该查询无法用标准SQL语法来表达）。 2022/7/2910第10页，共31页。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, Locatio

8、ns 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 LWHERE S.locid=L.locidGROUP BY L.stateSELECT SUM (S.sales)FROM Sales S, Time TWHERE S.timeid=T.timeidGROUP BY T.year2022/7/2911

9、第11页，共31页。12.2.3 与SQL操作比较这个交叉表也可被认为是在Location维、时间维、以及同时在Location维和时间维上的上卷。每个上卷对应一个带GROUP BY的SQL查询。一般来说，给定一个带有k个相关维的度量，我们能在任何这k个维的子集维上上卷，故我们有总数大约2k个这样的SQL查询。一个高层次的操作（象pivoting操作），一次可能产生这2k个SQL查询。分析这些查询的共性，有助于我们更有效地协调计算这组查询集。一种关于SQL的建议扩展称为CUBE，它等价于一组GROUP BY语句，每个GROUP BY语句中包含的相关属性，对应k维属性集的一个属性子集。2022/

10、7/2912第12页，共31页。12.2.3 与SQL操作比较CUBE使用示例观察下面这个特殊的扩展查询：CUBE pid, locid, timeid BY SUM Sales它将在其所有的八个子集（包括全集pid,locid,timeid和空集）上上卷。它等价于八个以下形式的操作：SELECT SUM (S.sales)FROM Sales SGROUP BY grouping-list这些查询只是在grouping-list上稍有不同，每个grouping-list对应pid,locid,timeid的一个子集。我们可将这八个查询想象为被分别对应图12.6中的一个栅格节点。每个节点上的结

11、构元组可被进一步聚合来计算它的任何子节点结果。在一个CUBE内，这些查询间的关系可被发掘利用来改善赋值性能。图12.6 2022/7/2913第13页，共31页。12.2.4 统计数据库许多OLAP概念已在早期的统计数据库(statistical databases, SDBs)中得到了体现。多维数据模型中关于“度量关联维度”的概念、“维值的分类层次结构”都早已被用在SDBs，上卷和下钻，在SDBs中也都有对应的操作。可能是由于应用领域和使用术语不同，两者的联系并未引起人们足够的注意。但OLAP和SDB之间还是有相当程度的区别。例如，SDBs主要用在社会经济学领域，对属性概念分类层次和便于针对

12、一些个性问题进行处理非常重要。SDBs中分类层次通常比OLAP应用中的分类层次更复杂，且受关注的程度更高。OLAP则主要面向包含大量数据集的商务应用，比SDB更关注高效处理非常大数据集的能力。 2022/7/2914第14页，共31页。12.2.5 OLAP设计OLAP设计一般建议采用以事实表为中心（本例中，事实表为Sales），并以事实表主键的各分量属性关联各维表的星型模式。数据的主体主要存储在事实表中，要求采用无冗余设计，一般要求满足BCNF规范。维表设计不要求满足很高规范（只要求满足2NF规范即可）。降低维表规范虽然可带来一定的冗余，但可显著减少连接操作，有助于提高查询处理的性能。由于维

13、表中数据量很少，而且变化不大，适度的冗余带来的空间浪费基本上可忽略。2022/7/2915第15页，共31页。一个典型的星型模式设计示例（图12.7 ） 2022/7/2916第16页，共31页。12.3 OLAP的实现技术12.3.1 位图索引 12.3.2 连接索引12.3.3 文件组织12.3.4 其它OLAP实现问题 2022/7/2917第17页，共31页。12.3.1 位图索引我们已在5.5部分，介绍了位图索引及其相关技术，包括位图压缩技术。与传统的散列和B+树索引相比，位图索引至少有两个重要优势：1）允许使用高效的位操作（用位向量的AND、OR操作）来回答查询；2）位图结构比B+

14、树结构更紧凑，而且压缩、解压缩操作简单容易。位图的这些特点和优势，使得它很适合于OLAP环境应用，特别是针对那些表结构相对简单、数据量却非常大的事实表建立索引。 2022/7/2918第18页，共31页。12.3.2 连接索引当关系的数据量很大时，希望用很小的时间计算连接是很难的。处理这个问题的一个方法是，分别为需加快的特定、常用连接查询创建专门索引。考虑连接查询将事实表F与两个维表D1、D2连接，且表D1的C1列、表D2的C2列被包含在选择条件中。可在连接索引中存储一组形如元组。这里，r1是表D1中在C1列取值c1所对应的那个元组rid，r2是表D2中在C2列取值c2所对应的那个元组rid，

15、而r是事实表F中一个元组的rid。r1,r2和r这三个元组被连接在一起。这种连接索引的主要缺陷是：索引的大小可能因每个维表有几个列被包含在选择中，而高速增长。冗余存储代价可能很大。2022/7/2919第19页，共31页。12.3.3 文件组织由于许多OLAP查询通常只包含一个大数据集关系的几个列，垂直分区因此变得很有吸引力。然而，分开存储一个关系列值可能降低那些可能包含多个列的查询。如果在存储整个大关系的同时，也单独存储该大关系的每个列，但这显然会增加存储空间且会带来一致性维护的额外问题。一种更彻底的文件组织，是将事实表视为一个很大的多维数组，并直接按多维数组进行存储和建立索引。这个方法已被

16、用在MOLAP系统中。传统B+树索引可用来支持块中元组的快速检索。 2022/7/2920第20页，共31页。12.3.4 其它OLAP实现问题1. 使用压缩已成为面向OLAP系统的一个广泛性问题。2. 决定哪些视图需要进行预计算和存储，使得一些特色查询能得到更快的响应处理也是一个极富有挑战性问题。汇总查询和操作符丰富的CUBE结构，为智能选择视图预计算和存储提供了更多的机会。自动或智能化选择预计算视图的相关探索，仍是当前的一项热点研究课题。 3. 许多OLAP系统都以新颖的方式，增强了查询表达和优化特性。4. 一些传统SQL系统已逐渐演变为能有效支持OLAP风格的查询，更强调对复杂查询的赋值

17、处理，并逐渐移植了OLAP系统需要的那些特别技术。2022/7/2921第21页，共31页。12.4 视图与决策支持系统12.4.1 视图、OLAP与DW 12.4.2 改写基于视图的查询12.4.3 视图物化12.4.4 视图物化相关问题 2022/7/2922第22页，共31页。12.4.1 视图、OLAP与DW视图与OLAP的关系OLAP查询，典型地，是一些汇总查询。分析者通常希望这些查询能获得快速的响应，即便是面对非常大的数据集。我们很自然会想到利用预计算视图。CUBE操作非常有利于发现更有效的预计算赋值策略。视图与DW的关系本质上，DW只不过是一组异步复制表和一组需周期性维护的物化视

18、图。DW维护的基本内容是：异步维护复制表和异步维护物化视图。 2022/7/2923第23页，共31页。12.4.2 改写基于视图的查询考虑如下的区域销售视图定义：CREATE VIEW RegionalSales (category, state, sales) AS SELECT P.category, L.state, S.sales FROM Products P, Sales S, Locations L WHERE P.pid=S.pid AND S.locid=L.locid可基于视图RegionalSales，计算每类产品在各州的销售汇总： SELECT R.category,

19、 R.state, SUM(R.sales) FROM RegionalSales R GROUP BY R.category, R.state对于基于视图的查询赋值。通常做法是将查询表达中的视图名用视图定义替换，将查询改写为不含视图的一般查询。这种方法的思想虽然简单、清晰，但改写后表达含复杂的嵌入子查询，赋值性能一般很低。2022/7/2924第24页，共31页。12.4.3 视图物化视图物化指事先赋值视图定义并存储赋值结果，然后直接在预计算结果上执行基于视图的查询。优缺点：优点：该方法通常比简单查询改写方法快得多，因为执行查询时不必再去赋值复杂的视图。缺点：需要维持预物化视图与基表的一致性

20、。一旦基表中数据有更新，须及时重新计算视图。 如何选择物化视图系统预期的查询工作负荷，对如何选择要进行物化的视图和如何创建索引有重要影响。 2022/7/2925第25页，共31页。12.4.4 视图物化相关问题对于视图物化，至少有三个需要考虑的重要问题：哪些视图需要物化？在视图上需要建哪些索引？给定一个基于视图的查询和一组物化视图，我们能利用物化视图来回答查询吗？为保持物化视图与基表的一致性，我们应何时和如何刷新物化视图？几种延迟视图维护方案：懒惰(lazy)法。周期法(periodic) 。强制法(forced) 。2022/7/2926第26页，共31页。12.5 快速返回部分查询结果1

21、2.5.1 TOP N查询 12.5.2 在线汇总2022/7/2927第27页，共31页。12.5.1 TOP N查询（1）用户可能希望从大量产品中了解销售最好的几种产品。常规实现方法：执行SQL查询，并按销售额排序结果。但如果有上亿个产品，而用户感兴趣的只是前几项产品，那么这种直接的赋值方法显然很浪费，且还需用户自己从列表中截留前几个结果。实际上，这种特殊的查询需求为DBMS提供了优化机会。观察下面这个有点特别的查询表达：SELECT P.pid, P.name, S.sales FROM Sales S, Products P WHERE S.pid=P.pid AND S.locid=1 AND S.timeid=3 ORDER BY S.sales DESC OPTIMIZE FOR 10 ROWS2022/7/2928第28页，共31页。12.5.1 TOP N查询（2）DBMS应如何利用OPTIMIZE FOR提示来更高效回答查询？关键点在于如何限制只计算销售值可能落在前十的那些产品所对应元组。我们可以采用如下查询来获得：SELECT P.pid,