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

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

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

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

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