數(shù)據(jù)倉庫與決策支持系統(tǒng)

數(shù)據(jù)倉庫與決策支持系統(tǒng)第一頁，共三十一頁，編輯于2023年，星期三第12章數(shù)據(jù)倉庫與決策支持系統(tǒng)數(shù)據(jù)倉庫技術(shù)概述12.1OLAP12.2OLAP的實現(xiàn)技術(shù)12.3視圖與決策支持系統(tǒng)12.4快速返回部分結(jié)果12.52023/6/102第二頁，共三十一頁，編輯于2023年，星期三12.1數(shù)據(jù)倉庫技術(shù)概述12.1.1決策支持查詢的新特征12.1.2支持決策支持查詢的系統(tǒng)類型12.1.3數(shù)據(jù)倉庫2023/6/103第三頁，共三十一頁，編輯于2023年，星期三12.1.1決策支持查詢的新特征查詢表達的WHERE子句通常是包含很多AND和OR的復(fù)雜條件。傳統(tǒng)RDBMS針對OR的處理能力很弱。數(shù)據(jù)分析應(yīng)用需要廣泛使用各種統(tǒng)計函數(shù)。SQL-92只內(nèi)置支持的了min/max/avg/sum/count五個統(tǒng)計函數(shù)，不支持象標(biāo)準(zhǔn)差等一些其它基本統(tǒng)計函數(shù)。完成高級統(tǒng)計需要由嵌入SQL的應(yīng)用代碼來完成。許多查詢包括與時間有關(guān)的條件，通常需要基于各種典型時間周期進行分析和匯總。SQL-92缺乏處理時間序列數(shù)據(jù)方面的功能支持。在數(shù)據(jù)分析應(yīng)用中，用戶可能需要反復(fù)提出同一組類似查詢。這不僅枯燥乏味，也使得DBMS無法從中識別或發(fā)掘查詢優(yōu)化機會。2023/6/104第四頁，共三十一頁，編輯于2023年，星期三12.1.2決策支持查詢的系統(tǒng)類型1）增強或擴展了OLAP特性的DBMSOLAP:OnLineAnalyticProcessing這類系統(tǒng)可高性能支持包含GROUP-BY和匯總操作符型式查詢，且能對復(fù)雜布爾條件、統(tǒng)計函數(shù)和時間序列分析提供良好支持。2）專用OLAP系統(tǒng)在已有DBMSs的基礎(chǔ)上，面向決策支持進行優(yōu)化，以增強支持高效OLAP查詢的一類專用系統(tǒng)。隨時間推移，專用OLAP系統(tǒng)和增強了OLAP特性的RDBMS系統(tǒng)之間區(qū)別可能會越來越小。3）數(shù)據(jù)挖掘(DataMining,DM)。希望從大數(shù)據(jù)集中探索發(fā)現(xiàn)有趣、意外趨勢，探索特別數(shù)據(jù)模式。2023/6/105第五頁，共三十一頁，編輯于2023年，星期三12.1.3數(shù)據(jù)倉庫系統(tǒng)2023/6/106第六頁，共三十一頁，編輯于2023年，星期三12.2OLAP12.2.1多維數(shù)據(jù)模型12.2.2OLAP查詢12.2.3與SQL操作比較12.2.4統(tǒng)計數(shù)據(jù)庫12.2.5OLAP設(shè)計2023/6/107第七頁，共三十一頁，編輯于2023年，星期三12.2.1多維數(shù)據(jù)模型在多維數(shù)據(jù)模型中，核心數(shù)據(jù)項是一組事實度量，每個度量依賴于一組維度。例如，在一個關(guān)于銷售數(shù)據(jù)管理的應(yīng)用中，sales(銷售數(shù)量)是度量屬性。維度則包括Product（產(chǎn)品）、Location（地區(qū)）和Time（時間）。給定一個產(chǎn)品、一個地區(qū)和一個時間點，我們最多只有一個銷售值。圖12.2一個多維數(shù)據(jù)集的圖形化表示

每個小立方體格點（cell）內(nèi)存儲表示一個銷售值。

2023/6/108第八頁，共三十一頁，編輯于2023年，星期三12.2.1多維數(shù)據(jù)模型MOLAP直接用多維數(shù)組來存儲多維數(shù)據(jù)集的OLAP專用系統(tǒng)。MOLAP:multidimensionalOLAPROLAP直接關(guān)系來存儲多維數(shù)據(jù)集的OLAP專用系統(tǒng)。例如對前述銷售管理，可被表示為以下一組關(guān)系：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);2023/6/109第九頁，共三十一頁，編輯于2023年，星期三12.2.2OLAP查詢OLAP系統(tǒng)的目標(biāo)是給最終用戶提供一個直觀且強有力的查詢接口，滿足一般的面向商務(wù)分析任務(wù)。常見的OLAP操作是基于多維數(shù)據(jù)集，在一個或多個維度上的度量值匯總。一些典型的OLAP操作上卷(rollup)下鉆(drill-down)繞軸旋轉(zhuǎn)(pivoting)…以下幾個查詢非常具有典型性，查銷售總額；查詢每個城市的銷售總額；查詢每個州的銷售總額；查詢銷售總額排行前五名的產(chǎn)品類(該查詢無法用標(biāo)準(zhǔn)SQL語法來表達）。2023/6/1010第十頁，共三十一頁，編輯于2023年，星期三12.2.3與SQL操作比較雖然有些OLAP查詢很難用SQL表達，或根本不能用SQL表達（如TOPn查詢）。但大多數(shù)的OLAP查詢都可用SQL表達。典型地，它們是一些包含分組和聚合操作的SQL語句。單個OLAP操作可能導(dǎo)致幾個密切相關(guān)的SQL查詢。例如，對圖12.5的交叉表，是通過繞軸(Time,Locatin)旋轉(zhuǎn)獲得。我們也可用下面查詢來獲得同樣的結(jié)果：SELECTSUM(S.sales)FROMSalesS,TimeT,LocationsLWHERES.timeid=T.timeidANDS.locid=L.locidGROUPBYT.year,L.state這個查詢產(chǎn)生圖12.5中灰色背景部分的單元。而該圖中最下匯總行和最右匯總列則可分別通過下面兩個SQL語句獲得：SELECTSUM(S.sales)FROMSalesS,LocationsLWHERES.locid=L.locidGROUPBYL.stateSELECTSUM(S.sales)FROMSalesS,TimeTWHERES.timeid=T.timeidGROUPBYT.year2023/6/1011第十一頁，共三十一頁，編輯于2023年，星期三12.2.3與SQL操作比較這個交叉表也可被認(rèn)為是在Location維、時間維、以及同時在Location維和時間維上的上卷。每個上卷對應(yīng)一個帶GROUPBY的SQL查詢。一般來說，給定一個帶有k個相關(guān)維的度量，我們能在任何這k個維的子集維上上卷，故我們有總數(shù)大約2k個這樣的SQL查詢。一個高層次的操作（象pivoting操作），一次可能產(chǎn)生這2k個SQL查詢。分析這些查詢的共性，有助于我們更有效地協(xié)調(diào)計算這組查詢集。一種關(guān)于SQL的建議擴展稱為CUBE，它等價于一組GROUPBY語句，每個GROUPBY語句中包含的相關(guān)屬性，對應(yīng)k維屬性集的一個屬性子集。2023/6/1012第十二頁，共三十一頁，編輯于2023年，星期三12.2.3與SQL操作比較CUBE使用示例觀察下面這個特殊的擴展查詢：CUBEpid,locid,timeidBYSUMSales它將在其所有的八個子集（包括全集{pid,locid,timeid}和空集{}）上上卷。它等價于八個以下形式的操作：SELECTSUM(S.sales)FROMSalesSGROUPBYgrouping-list這些查詢只是在grouping-list上稍有不同，每個grouping-list對應(yīng){pid,locid,timeid}的一個子集。我們可將這八個查詢想象為被分別對應(yīng)圖12.6中的一個柵格節(jié)點。每個節(jié)點上的結(jié)構(gòu)元組可被進一步聚合來計算它的任何子節(jié)點結(jié)果。在一個CUBE內(nèi)，這些查詢間的關(guān)系可被發(fā)掘利用來改善賦值性能。圖12.6

2023/6/1013第十三頁，共三十一頁，編輯于2023年，星期三12.2.4統(tǒng)計數(shù)據(jù)庫許多OLAP概念已在早期的統(tǒng)計數(shù)據(jù)庫(statisticaldatabases,SDBs)中得到了體現(xiàn)。多維數(shù)據(jù)模型中關(guān)于“度量關(guān)聯(lián)維度”的概念、“維值的分類層次結(jié)構(gòu)”都早已被用在SDBs，上卷和下鉆，在SDBs中也都有對應(yīng)的操作。可能是由于應(yīng)用領(lǐng)域和使用術(shù)語不同，兩者的聯(lián)系并未引起人們足夠的注意。但OLAP和SDB之間還是有相當(dāng)程度的區(qū)別。例如，SDBs主要用在社會經(jīng)濟學(xué)領(lǐng)域，對屬性概念分類層次和便于針對一些個性問題進行處理非常重要。SDBs中分類層次通常比OLAP應(yīng)用中的分類層次更復(fù)雜，且受關(guān)注的程度更高。OLAP則主要面向包含大量數(shù)據(jù)集的商務(wù)應(yīng)用，比SDB更關(guān)注高效處理非常大數(shù)據(jù)集的能力。2023/6/1014第十四頁，共三十一頁，編輯于2023年，星期三12.2.5OLAP設(shè)計OLAP設(shè)計一般建議采用以事實表為中心（本例中，事實表為Sales），并以事實表主鍵的各分量屬性關(guān)聯(lián)各維表的星型模式。數(shù)據(jù)的主體主要存儲在事實表中，要求采用無冗余設(shè)計，一般要求滿足BCNF規(guī)范。維表設(shè)計不要求滿足很高規(guī)范（只要求滿足2NF規(guī)范即可）。降低維表規(guī)范雖然可帶來一定的冗余，但可顯著減少連接操作，有助于提高查詢處理的性能。由于維表中數(shù)據(jù)量很少，而且變化不大，適度的冗余帶來的空間浪費基本上可忽略。2023/6/1015第十五頁，共三十一頁，編輯于2023年，星期三一個典型的星型模式設(shè)計示例（圖12.7）2023/6/1016第十六頁，共三十一頁，編輯于2023年，星期三12.3OLAP的實現(xiàn)技術(shù)12.3.1位圖索引12.3.2連接索引12.3.3文件組織12.3.4其它OLAP實現(xiàn)問題2023/6/1017第十七頁，共三十一頁，編輯于2023年，星期三12.3.1位圖索引我們已在5.5部分，介紹了位圖索引及其相關(guān)技術(shù)，包括位圖壓縮技術(shù)。與傳統(tǒng)的散列和B+樹索引相比，位圖索引至少有兩個重要優(yōu)勢：1）允許使用高效的位操作（用位向量的AND、OR操作）來回答查詢；2）位圖結(jié)構(gòu)比B+樹結(jié)構(gòu)更緊湊，而且壓縮、解壓縮操作簡單容易。位圖的這些特點和優(yōu)勢，使得它很適合于OLAP環(huán)境應(yīng)用，特別是針對那些表結(jié)構(gòu)相對簡單、數(shù)據(jù)量卻非常大的事實表建立索引。2023/6/1018第十八頁，共三十一頁，編輯于2023年，星期三12.3.2連接索引當(dāng)關(guān)系的數(shù)據(jù)量很大時，希望用很小的時間計算連接是很難的。處理這個問題的一個方法是，分別為需加快的特定、常用連接查詢創(chuàng)建專門索引?？紤]連接查詢將事實表F與兩個維表D1、D2連接，且表D1的C1列、表D2的C2列被包含在選擇條件中?？稍谶B接索引中存儲一組形如<r1,r2,r>元組。這里，r1是表D1中在C1列取值c1所對應(yīng)的那個元組rid，r2是表D2中在C2列取值c2所對應(yīng)的那個元組rid，而r是事實表F中一個元組的rid。r1,r2和r這三個元組被連接在一起。這種連接索引的主要缺陷是：索引的大小可能因每個維表有幾個列被包含在選擇中，而高速增長。冗余存儲代價可能很大。2023/6/1019第十九頁，共三十一頁，編輯于2023年，星期三12.3.3文件組織由于許多OLAP查詢通常只包含一個大數(shù)據(jù)集關(guān)系的幾個列，垂直分區(qū)因此變得很有吸引力。然而，分開存儲一個關(guān)系列值可能降低那些可能包含多個列的查詢。如果在存儲整個大關(guān)系的同時，也單獨存儲該大關(guān)系的每個列，但這顯然會增加存儲空間且會帶來一致性維護的額外問題。一種更徹底的文件組織，是將事實表視為一個很大的多維數(shù)組，并直接按多維數(shù)組進行存儲和建立索引。這個方法已被用在MOLAP系統(tǒng)中。傳統(tǒng)B+樹索引可用來支持塊中元組的快速檢索。2023/6/1020第二十頁，共三十一頁，編輯于2023年，星期三12.3.4其它OLAP實現(xiàn)問題1.使用壓縮已成為面向OLAP系統(tǒng)的一個廣泛性問題。2.決定哪些視圖需要進行預(yù)計算和存儲，使得一些特色查詢能得到更快的響應(yīng)處理也是一個極富有挑戰(zhàn)性問題。匯總查詢和操作符豐富的CUBE結(jié)構(gòu)，為智能選擇視圖預(yù)計算和存儲提供了更多的機會。自動或智能化選擇預(yù)計算視圖的相關(guān)探索，仍是當(dāng)前的一項熱點研究課題。3.許多OLAP系統(tǒng)都以新穎的方式，增強了查詢表達和優(yōu)化特性。4.一些傳統(tǒng)SQL系統(tǒng)已逐漸演變?yōu)槟苡行еС諳LAP風(fēng)格的查詢，更強調(diào)對復(fù)雜查詢的賦值處理，并逐漸移植了OLAP系統(tǒng)需要的那些特別技術(shù)。2023/6/1021第二十一頁，共三十一頁，編輯于2023年，星期三12.4視圖與決策支持系統(tǒng)12.4.1視圖、OLAP與DW12.4.2改寫基于視圖的查詢12.4.3視圖物化12.4.4視圖物化相關(guān)問題2023/6/1022第二十二頁，共三十一頁，編輯于2023年，星期三12.4.1視圖、OLAP與DW視圖與OLAP的關(guān)系OLAP查詢，典型地，是一些匯總查詢。分析者通常希望這些查詢能獲得快速的響應(yīng)，即便是面對非常大的數(shù)據(jù)集。我們很自然會想到利用預(yù)計算視圖。CUBE操作非常有利于發(fā)現(xiàn)更有效的預(yù)計算賦值策略。視圖與DW的關(guān)系本質(zhì)上，DW只不過是一組異步復(fù)制表和一組需周期性維護的物化視圖。DW維護的基本內(nèi)容是：異步維護復(fù)制表和異步維護物化視圖。2023/6/1023第二十三頁，共三十一頁，編輯于2023年，星期三12.4.2改寫基于視圖的查詢考慮如下的區(qū)域銷售視圖定義：CREATEVIEWRegionalSales(category,state,sales)ASSELECTP.category,L.state,S.salesFROMProductsP,SalesS,LocationsLWHEREP.pid=S.pidANDS.locid=L.locid可基于視圖RegionalSales，計算每類產(chǎn)品在各州的銷售匯總：SELECTR.category,R.state,SUM(R.sales)FROMRegionalSalesRGROUPBYR.category,R.state對于基于視圖的查詢賦值。通常做法是將查詢表達中的視圖名用視圖定義替換，將查詢改寫為不含視圖的一般查詢。這種方法的思想雖然簡單、清晰，但改寫后表達含復(fù)雜的嵌入子查詢，賦值性能一般很低。2023/6/1024第二十四頁，共三十一頁，編輯于2023年，星期三12.4.3視圖物化視圖物化指事先賦值視圖定義并存儲賦值結(jié)果，然后直接在預(yù)計算結(jié)果上執(zhí)行基于視圖的查詢。優(yōu)缺點：優(yōu)點：該方法通常比簡單查詢改寫方法快得多，因為執(zhí)行查詢時不必再去賦值復(fù)雜的視圖。缺點：需要維持預(yù)物化視圖與基表的一致性。一旦基表中數(shù)據(jù)有更新，須及時重新計算視圖。如何選擇物化視圖系統(tǒng)預(yù)期的查詢工作負荷，對如何選擇要進行物化的視圖和如何創(chuàng)建索引有重要影響。2023/6/1025第二十五頁，共三十一頁，編輯于2023年，星期三12.4.4視圖物化相關(guān)問題對于視圖物化，至少有三個需要考慮的重要問題：哪些視圖需要物化？在視圖上需要建哪些索引？給定一個基于視圖的查詢和一組物化視圖，我們能利用物化視圖來回答查詢嗎？為保持物化視圖與基表的一致性，我們應(yīng)何時和如何刷新物化視圖？幾種延遲視圖維護方案：懶惰(lazy)法。周期法(periodic)。強制法(forced)。2023/6/1026第二十六頁，共三十一頁，編輯于2023年，星期三12.5快速返回部分查詢結(jié)果12.5.1TOPN查詢12.5.2在線匯總2023/6/1027第二十七頁，共三十一頁，編輯于2023年，星期三12.5.1TOPN查詢（1）用戶可能希望從大量產(chǎn)品中了解銷售最好的幾種產(chǎn)品。常規(guī)實現(xiàn)方法：執(zhí)行SQL查詢，并按銷售額排序結(jié)果。但如果有上億個產(chǎn)品，而用戶感興趣的只是前幾項產(chǎn)品，那么這種直接的賦值方法顯然很浪費，且還需用戶自己從列表中截留前幾個結(jié)果。實際上，這種特殊的查詢需求為DBMS提供了優(yōu)化機會。觀察下面這個有點特別的查詢表達：SELECTP.pid,P.name,S.salesFROMSalesS,ProductsPWHERES.pid=P.pidANDS.locid=1ANDS.timeid=3ORDERBYS.salesDESCOPTIMIZEFOR10ROWS2023/6/1028第二十八頁，共三十一頁，編輯于2023年，星期三12.5.1TOPN查詢（2）DBMS應(yīng)如何利用OPTIMIZEFOR提示來更高效回答查詢？關(guān)鍵點在于如何限制只計算銷售值可能落在前十的那些產(chǎn)品所對應(yīng)元組。我們可以采用如下查詢來獲得：SELECTP.pid,P.name,S.sal