《數(shù)據(jù)倉庫概念一覽》word版

1、.數(shù)據(jù)倉庫概念一覽淺析冰山查詢 iceberg query在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Iceberg query，中文一般翻譯為"冰山查詢"。冰山查詢在一個屬性或?qū)傩约嫌?jì)算一個聚集函數(shù)，以找出大于某個指定閾值的聚集值。以銷售數(shù)據(jù)為例，你想產(chǎn)生這樣的一個顧客-商品對的列表，這些顧客購置商品的數(shù)量到達(dá)3件或更多。這可以用下面的冰山查詢表示：Select P.cust_ID,P.item_ID,SUMP.qtyFrom Purchase PGroup by P.cust_ID,P.item_ID Having SUMP.qty=3這種在給出大量輸入數(shù)據(jù)元組的情況下，使用havin

2、g字句中的閾值來進(jìn)展過濾的查詢方法就叫做冰山查詢。輸出結(jié)果可以看作"冰山頂"，而"冰山"是輸入數(shù)據(jù)。這種冰山查詢在數(shù)據(jù)倉庫的數(shù)據(jù)概況分析階段、數(shù)據(jù)質(zhì)量檢查階段和數(shù)據(jù)挖掘的購物籃分析中都經(jīng)常使用。而且，冰山查詢也是面試中出現(xiàn)頻率非常高的一道題，經(jīng)常用來檢測SQL才能。操作集市 oper mart在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Oper Mart，中文一般翻譯為"操作集市"。操作集市是為了企業(yè)戰(zhàn)術(shù)性的分析提供支持，它的數(shù)據(jù)來源是操作數(shù)據(jù)存儲ODS。它是ODS在分析功能上的擴(kuò)展，使用戶可以對操作型數(shù)據(jù)進(jìn)展多維分析。一個操作集市應(yīng)該有如下特征：1.

3、操作集市是ODS的子集，數(shù)據(jù)來源于ODS，用于戰(zhàn)略分析和報(bào)表。2.操作集市中的數(shù)據(jù)和ODS中的數(shù)據(jù)同步更新。3.操作集市以多維技術(shù)進(jìn)展建模，即星型構(gòu)造。4.操作集市是一個臨時的構(gòu)造，當(dāng)不在需要時會清掉所有數(shù)據(jù)，即不保存歷史數(shù)據(jù)。操作集市和數(shù)據(jù)集市很相似，但是它不能用來取代用于戰(zhàn)略性分析的數(shù)據(jù)集市。由于操作集市的數(shù)據(jù)來源于ODS，所以它的數(shù)據(jù)比數(shù)據(jù)集市的數(shù)據(jù)要新。但是出于容量的考慮，操作集市中不保存歷史數(shù)據(jù)，是一個臨時的構(gòu)造。操作數(shù)據(jù)存儲 operational data store Kimball對操作數(shù)據(jù)存儲的定義是，面向主題的、集成的、經(jīng)常更新的細(xì)節(jié)數(shù)據(jù)存儲，用集成的數(shù)據(jù)來支持事務(wù)系統(tǒng)。K

4、imball也認(rèn)可Inmon對ODS的分類，但是他認(rèn)為ODS應(yīng)該以星型構(gòu)造來進(jìn)展建模。雖然Kimball對操作數(shù)據(jù)存儲ODS的定義和Inmon根本上一樣，但是他對操作數(shù)據(jù)存儲的理解、作用與實(shí)現(xiàn)和Inmon有著較大的不同。Kimball認(rèn)為ODS在兩種情況下是需要的：第一種情況是提供操作型報(bào)表，這些報(bào)表需要提供面向主題的、集成的數(shù)據(jù)，所以操作型的源系統(tǒng)無法提供；這些報(bào)表和數(shù)據(jù)倉庫中的報(bào)表也不一樣，因?yàn)樗鼈兛梢允且恍┒ㄖ坪玫?，寫死在程序中的?bào)表。第二種情況是需要提供實(shí)時的信息時，由于數(shù)據(jù)倉庫的更新頻率一般都是24小時，而用戶會有更急迫的需求來理解數(shù)據(jù)源的信息，這時，建立操作數(shù)據(jù)存儲是很有必要的。對

5、于ODS是保存最細(xì)粒度數(shù)據(jù)的地方的說法，Kimball認(rèn)為對于最細(xì)粒度數(shù)據(jù)，即原子數(shù)據(jù)層，應(yīng)該保存在數(shù)據(jù)倉庫中，而且應(yīng)該置于維度框架和總線架構(gòu)中。代理關(guān)鍵字-surrogate key在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Surrogate key，中文一般翻譯為"代理關(guān)鍵字"。代理關(guān)鍵字一般是指維度表中使用順序分配的整數(shù)值作為主鍵，也稱為"代理鍵"。代理關(guān)鍵字用于維度表和事實(shí)表的連接。代理關(guān)鍵字的稱呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synth

6、etic keys等。與之相對的自然關(guān)鍵字的稱呼有natural keys，samat keys等。在Kimball的維度建模領(lǐng)域里，是強(qiáng)烈推薦使用代理關(guān)鍵字的。在維度表和事實(shí)表的每一個聯(lián)接中都應(yīng)該使用代理關(guān)鍵字，而不應(yīng)該使用自然關(guān)鍵字或者智能關(guān)鍵字Smart Keys。數(shù)據(jù)倉庫中的主鍵不應(yīng)該是智能的，也就是說，要防止通過主鍵的值就可以理解一些業(yè)務(wù)信息。當(dāng)然，退化維度作為事實(shí)表的復(fù)合主鍵之一時例外。使用代理關(guān)鍵字，有很多優(yōu)點(diǎn)。1.使用代理關(guān)鍵字可以使數(shù)據(jù)倉庫環(huán)境對操作型環(huán)境的變化進(jìn)展緩沖。也就是說，當(dāng)數(shù)據(jù)倉庫需要對來在多個操作型系統(tǒng)的數(shù)據(jù)進(jìn)展整合時，這些系統(tǒng)中的數(shù)據(jù)有可能缺乏一致的關(guān)鍵字編碼，

7、即有可能出現(xiàn)重復(fù)，這時代理關(guān)鍵字可以解決這個問題。2.使用代理關(guān)鍵字可以帶來性能上的優(yōu)勢。和自然關(guān)鍵字相比，代理關(guān)鍵字很小，是整型的，可以減小事實(shí)表中記錄的長度。這樣，同樣的IO就可以讀取更多的事實(shí)表記錄。另外，整型字段作為外鍵聯(lián)接的效率也很高。3.使用代理關(guān)鍵字可以建立一些不存在的維度記錄，例如"不在促銷之列"，"日期待定"，"日期不可用"等維度記錄。4.使用代理關(guān)鍵字可以用來處理緩慢變化維。維度表數(shù)據(jù)的歷史變化信息的保存是數(shù)據(jù)倉庫設(shè)計(jì)的施行中非常重要的一部分。Kimball的緩慢變化維處理策略的核心就是使用代理關(guān)鍵字。當(dāng)然，使用代

8、理關(guān)鍵字也有它的缺點(diǎn)，代理關(guān)鍵字的使用使數(shù)據(jù)加載變得非常復(fù)雜。有關(guān)使用代理關(guān)鍵字的維度表和事實(shí)表的加載方法在ETL Toolkit中有詳細(xì)的描繪。使用代理關(guān)鍵字是一個從長遠(yuǎn)考慮的策略。多值維度 multivalue dimension在維度建模的數(shù)據(jù)倉庫中，有一種維度表叫multivalue dimension，中文一般翻譯為"多值維度"。多值維度有兩種情況，第一種情況是指維度表中的某個屬性字段同時有多個值。舉例來說，一個帳戶維度表中，帳戶持有人姓名，可能會有多個顧客。這樣，一個帳戶對應(yīng)多個顧客姓名，一個顧客也可以有多個帳戶，它們之間是多對多的關(guān)系。正因?yàn)橐粋€帳戶可能會有多

9、個對應(yīng)的顧客，所以不能直接將顧客ID放入帳戶維度表中。而帳戶維度表中的這種情況就叫做多值維度。多值維度的第二種情況是事實(shí)表在某個維度表中有多條對應(yīng)記錄。舉例來說，對于一個安康護(hù)理單分列項(xiàng)事實(shí)表來說，它的粒度是一個安康護(hù)理單，但是該護(hù)理單卻有可能有屢次診斷，即該事實(shí)表與診斷維度的是一對多的關(guān)系。這個與事實(shí)表粒度不匹配的診斷維度也稱之為多值維度。處理多值維度最好的方法是降低事實(shí)表的粒度。如第二種情況中，將安康護(hù)理單分列項(xiàng)事實(shí)表的粒度降低到詳細(xì)的診斷粒度上，這樣就防止了多值維度的出現(xiàn)。這種處理方式也是維度建模的一個原那么，即事實(shí)表應(yīng)該建立在最細(xì)粒度上。這樣的處理，需要對事實(shí)表的事實(shí)進(jìn)展分?jǐn)?。但是有?/p>

10、時候，事實(shí)表的粒度是不能降低的，多值維度的出現(xiàn)是無法防止的。如第一種情況中，事實(shí)表是月帳戶快照事實(shí)表，這張事實(shí)表與顧客維度沒有直接的關(guān)系，不能將數(shù)據(jù)粒度進(jìn)展細(xì)分，即使細(xì)分的話帳戶余額也很難分?jǐn)?。這時，可以采用橋接表技術(shù)進(jìn)展處理。在帳戶維度表和顧客維度表之間建立個帳戶-顧客橋接表。這個橋接表可以解決掉帳戶維度和顧客維度之間的多對多關(guān)系，也解決掉的帳戶維度表的多值維度問題?？傊嘀稻S度是應(yīng)該盡量防止的，它給數(shù)據(jù)處理帶來了很大的費(fèi)事。假設(shè)多值維度不能防止的話，應(yīng)該建立橋接表來進(jìn)展處理。非事實(shí)型事實(shí)表 factless fact table在維度建模的數(shù)據(jù)倉庫中，有一種事實(shí)表叫Factless Fa

11、ct Table，中文一般翻譯為"非事實(shí)型事實(shí)表"。在事實(shí)表中，通常會保存十個左右的維度外鍵和多個度量事實(shí)，度量事實(shí)是事實(shí)表的關(guān)鍵所在。在非事實(shí)型事實(shí)表中沒有這些度量事實(shí)，只有多個維度外鍵。非事實(shí)型事實(shí)表通常用來跟蹤一些事件或者說明某些活動的范圍。下面舉例來進(jìn)展說明。第一類非事實(shí)型事實(shí)表是用來跟蹤事件的事實(shí)表。例如：學(xué)生注冊事件，學(xué)校需要對學(xué)生按學(xué)期進(jìn)展跟蹤。維度表包括學(xué)期維度、課程維度、系維度、學(xué)生維度、注冊專業(yè)維度和獲得學(xué)分維度，而事實(shí)表是由這些維度的主鍵組成，事實(shí)只有注冊數(shù)，并且恒為1。這樣的事實(shí)表可以答復(fù)大量關(guān)于大學(xué)開課注冊方面的問題，主要是答復(fù)各種情況下的注冊數(shù)。

12、第二類非事實(shí)型事實(shí)表是用來說明某些活動范圍的事實(shí)表。例如：促銷范圍事實(shí)表。通常銷售事實(shí)表可以答復(fù)如促銷商品的銷售情況，但是對于那些沒有銷售出去的促銷商品沒法答復(fù)。這時，通過建立促銷范圍事實(shí)表，將商場需要促銷的商品單獨(dú)建立事實(shí)表保存。然后，通過這個促銷范圍事實(shí)表和銷售事實(shí)表即可得出哪些促銷商品沒有銷售出去。這樣的促銷范圍事實(shí)表只是用來說明促銷活動的范圍，其中沒有任何事實(shí)度量。合并事實(shí)表-consolidated/merged fact table在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫merged fact table，或者consolidated fact table，中文一般都翻譯為"合并事實(shí)表

13、"。合并事實(shí)表是將不同事實(shí)表的事實(shí)合并到同一張事實(shí)表的建模方法，合并的事實(shí)要保證在一樣的粒度。這種建模方法通常被用來橫跨多個業(yè)務(wù)主題域來建立數(shù)據(jù)集市，Kimball將這樣的數(shù)據(jù)集市稱為第二級的數(shù)據(jù)集市。使用合并事實(shí)表技術(shù)，可以防止性能較差的穿插探察操作。但是，這種合并事實(shí)表和使用穿插探察操作還有著細(xì)微的不同，在一些根底表中沒有記錄的時候，合并事實(shí)表中可能會存儲一條記錄，字段值保存為零。合并事實(shí)表可以給數(shù)據(jù)倉庫帶來很大的性能提升，提供的跨主題的事實(shí)數(shù)據(jù)也給用戶帶來了很大的方便。但是，合并事實(shí)表給ETL工作帶來了較大的費(fèi)事。對于合并事實(shí)表中涉及到的維度，需要在數(shù)據(jù)準(zhǔn)備區(qū)保證它們是一致性維

14、度。緩慢變化維 slowly changing dimension維度建模的數(shù)據(jù)倉庫中，有一個概念叫Slowly Changing Dimensions，中文一般翻譯成"緩慢變化維"，經(jīng)常被簡寫為SCD。緩慢變化維的提出是因?yàn)樵诂F(xiàn)實(shí)世界中，維度的屬性并不是靜態(tài)的，它會隨著時間的流失發(fā)生緩慢的變化。這種隨時間發(fā)生變化的維度我們一般稱之為緩慢變化維，并且把處理維度表的歷史變化信息的問題稱為處理緩慢變化維的問題，有時也簡稱為處理SCD的問題。處理緩慢變化維的方法通常分為三種方式。第一種方式是直接覆蓋原值。這樣處理，最容易實(shí)現(xiàn)，但是沒有保存歷史數(shù)據(jù)，無法分析歷史變化信息。第一種方式

15、通常簡稱為"TYPE 1"。第二種方式是添加維度行。這樣處理，需要代理鍵的支持。實(shí)現(xiàn)方式是當(dāng)有維度屬性發(fā)生變化時，生成一條新的維度記錄，主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關(guān)聯(lián)。第二種方式通常簡稱為"TYPE 2"。第三種方式是添加屬性列。這種處理的實(shí)現(xiàn)方式是對于需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本屬性字段使用TYPE 1來直接覆蓋。這種方式的優(yōu)點(diǎn)是可以同時分析當(dāng)前及前一次變化的屬性值，缺點(diǎn)是只保存了最后一次變化信息。第三種方式通常簡稱為"TYPE 3"。在實(shí)際建模中，我們可以結(jié)合使用三種方式，

16、也可以對一個維度表中的不同屬性使用不同的方式，這些，都需要根據(jù)實(shí)際情況來決定，但目的都是一樣的，就是可以支持方便的分析歷史變化情況。即席查詢 ad hoc queries在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Ad hoc queries，中文一般翻譯為"即席查詢"。即席查詢是指那些用戶在使用系統(tǒng)時，根據(jù)自己當(dāng)時的需求定義的查詢。即席查詢生成的方式很多，最常見的就是使用即席查詢工具。一般的數(shù)據(jù)展現(xiàn)工具都會提供即席查詢的功能。通常的方式是，將數(shù)據(jù)倉庫中的維度表和事實(shí)表映射到語義層，用戶可以通過語義層選擇表，建立表間的關(guān)聯(lián)，最終生成SQL語句。即席查詢與通常查詢從SQL語句上來說，并沒有本質(zhì)

17、的差異。它們之間的差異在于，通常的查詢在系統(tǒng)設(shè)計(jì)和施行時是的，所有我們可以在系統(tǒng)施行時通過建立索引、分區(qū)等技術(shù)來優(yōu)化這些查詢，使這些查詢的效率很高。而即席查詢是用戶在使用時臨時消費(fèi)的，系統(tǒng)無法預(yù)先優(yōu)化這些查詢，所以即席查詢也是評估數(shù)據(jù)倉庫的一個重要指標(biāo)。即席查詢的位置通常是在關(guān)系型的數(shù)據(jù)倉庫中，即在EDW或者ROLAP中。多維數(shù)據(jù)庫有自己的存儲方式，對即席查詢和通常查詢沒有區(qū)別。在一個數(shù)據(jù)倉庫系統(tǒng)中，即席查詢使用的越多，對數(shù)據(jù)倉庫的要求就越高，對數(shù)據(jù)模型的對稱性的要求也越高。對稱性的數(shù)據(jù)模型對所有的查詢都是一樣的，這也是維度建模的一個優(yōu)點(diǎn)。穿插探察 drill across在維度建模的數(shù)據(jù)倉庫

18、中，有一種操作叫Drill Across，中文一般翻譯為"穿插探查"。鑒于經(jīng)歷的局限，在這里我只能進(jìn)展一下粗淺的分析。在基于總線架構(gòu)Bus Architecture的維度建模中，大部分的維度表是由事實(shí)表共有的。比方"營銷事務(wù)事實(shí)表"和"庫存快照事實(shí)表"就會有一樣的維度表，"日期維度"、"產(chǎn)品維度"和"商場維度"。這時，假設(shè)有個需求是想按共有維度來比照查看銷售和庫存的事實(shí)，這時就需要發(fā)出兩個SQL，分別查出按維度統(tǒng)計(jì)出的銷售數(shù)據(jù)和庫存數(shù)據(jù)。然后再基于共有的維度進(jìn)展外連接，將數(shù)據(jù)

19、合并。這種發(fā)出多路SQL再進(jìn)展合并的操作就是穿插探查。當(dāng)這種穿插探查的需求很常用時，有一種建模方法可以防止穿插探查，就是合并事實(shí)表Consolidated Fact Table。合并事實(shí)表是指將位于不同事實(shí)表中處于一樣粒度的事實(shí)進(jìn)展組合的一種建模方法。即新建立一個事實(shí)表，它的維度是兩個或多個事實(shí)表的一樣維度的集合，事實(shí)是幾個事實(shí)表中感興趣的事實(shí)。這個事實(shí)表的數(shù)據(jù)和其他事實(shí)表的數(shù)據(jù)一樣來自Staging Area。合并事實(shí)表在性能和易用性上都比穿插探查要好，但是被組合的事實(shí)表必須處于一樣的粒度和維度層次上。角色模擬維度-role-playing dimensions在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Ro

20、le-playing dimensions，中文一般翻譯為"角色模擬維度"。角色模擬維度是為了處理一個維度在一個事實(shí)表中同時出現(xiàn)屢次而使用的一種技術(shù)處理手段。在建立了角色模擬維度以后，在底層只有一個物理表存在，但是針對這個物理表會建立多個角色提供給數(shù)據(jù)訪問工具，而且對數(shù)據(jù)訪問工具來說這多個角色是不同的。例如對與累計(jì)快照事實(shí)表中會出現(xiàn)多個日期字段聯(lián)接到日期維度。這時就可以針對日期維度建立多個角色模擬維度。角色模擬維度的建立方法通常是使用視圖來完成。例如訂單日期維度表如下所示：CREATE VIEW order_dateorder_date_key,order_day_of_w

21、eek,order_month,AS SELECT data_key,day_of_week,month,FROM DATA使用同樣的方式還可以建立多個不同日期的角色模擬維度。需要補(bǔ)充的一點(diǎn)是，目前市場上的大部分展現(xiàn)工具，都提供了對一個表選擇屢次的功能。也就是說，角色模擬維度的功能展現(xiàn)工具自己就可以實(shí)現(xiàn)。這樣，就不需要我們在數(shù)據(jù)庫中建立角色模擬維度的視圖了，而直接使用展現(xiàn)工具完成即可。聚集事實(shí)表-aggregated fact table累計(jì)快照事實(shí)表-accumulating snapshot fact table橋接表-bridge table切片事實(shí)表-sliced fact table

22、在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫sliced fact table，中文一般翻譯為"切片事實(shí)表"。切片事實(shí)表中的字段構(gòu)造和相應(yīng)的根底表完全一樣，差異在于存儲的記錄的范圍。切片事實(shí)表中保存記錄的是相應(yīng)根底表中記錄的子集，記錄數(shù)通常與某個維度記錄數(shù)一樣。這種建模方法一般用來滿足特殊需要，如需要分析某些特殊問題時，可以將與之相關(guān)的數(shù)據(jù)切片出來。相反，這種方法也常用于合并存儲在不同地區(qū)的數(shù)據(jù)，即各個地區(qū)都保存自己地區(qū)的數(shù)據(jù)，總部和所有地區(qū)的表構(gòu)造都一樣，然后總部將所有地區(qū)的數(shù)據(jù)合并在一起。切片事實(shí)表的構(gòu)造與相對應(yīng)的根底表一樣，數(shù)據(jù)來源于相對應(yīng)的根底表。切片事實(shí)表由于縮小了表中數(shù)據(jù)的記錄數(shù)

23、，所以查詢的效率得到了很大的進(jìn)步。事實(shí)表一二 fact table在維度建模的數(shù)據(jù)倉庫中，事實(shí)表是指其中保存了大量業(yè)務(wù)度量數(shù)據(jù)的表。事實(shí)表中的度量值一般稱為事實(shí)。在事實(shí)表中最有用的事實(shí)就是數(shù)字類型的事實(shí)和可加類型的事實(shí)。事實(shí)表的粒度決定了數(shù)據(jù)倉庫中數(shù)據(jù)的詳細(xì)程度。一般來說，以粒度作為化分根據(jù)，主要有三種事實(shí)表，分別是事務(wù)粒度事實(shí)表Transaction Grain Fact Table，周期快照粒度事實(shí)表Periodic Snapshot Grain Fact Table和累積快照粒度事實(shí)表Accumulating Snapshot Grain Fact Table。事務(wù)粒度事實(shí)表中的一條記錄

24、代表了業(yè)務(wù)系統(tǒng)中的一個事件。事務(wù)出現(xiàn)以后，就會在事實(shí)中出現(xiàn)一條記錄。事務(wù)粒度事實(shí)表也稱為原子粒度。典型的例子是銷售單分列項(xiàng)事實(shí)表。周期快照粒度事實(shí)表用來記錄有規(guī)律的，可預(yù)見時間間隔的業(yè)務(wù)累計(jì)數(shù)據(jù)。通常的時間間隔可以是每天、每周或者每月。典型的例子是庫存日快照事實(shí)表。累積快照事實(shí)表一般用來涵蓋一個事務(wù)的生命周期內(nèi)的不確定的時間跨度。典型的例子是KDT#2中描繪的具有多個日期字段的發(fā)貨事實(shí)表。通常來說，事務(wù)和快照是建模中的兩個非常重要的特點(diǎn)，將兩者相結(jié)合可以使模型建立的更完好。從用處的不同來說，事實(shí)表可以分為三類，分別是原子事實(shí)表，聚集事實(shí)表和合并事實(shí)表。原子事實(shí)表Atom Fact Table是

25、保存最細(xì)粒度數(shù)據(jù)的事實(shí)表，也是數(shù)據(jù)倉庫中保存原子信息的場所。聚集事實(shí)表Aggregated Fact Table是原子事實(shí)表上的匯總數(shù)據(jù)，也稱為匯總事實(shí)表。即新建立一個事實(shí)表，它的維度表是比原維度表要少，或者某些維度表是原維度表的子集，如用月份維度表代替日期維度表；事實(shí)數(shù)據(jù)是相應(yīng)事實(shí)的匯總，即求和或求平均值等。在做數(shù)據(jù)遷移時，當(dāng)相關(guān)的維度數(shù)據(jù)和事實(shí)數(shù)據(jù)發(fā)生變化時，聚集事實(shí)表需要做相應(yīng)的刷新。物化視圖是實(shí)現(xiàn)聚集事實(shí)表的一種有效方式，可以設(shè)定刷新方式，詳細(xì)功能由DBMS來實(shí)現(xiàn)。合并事實(shí)表Consolidated Fact Table是指將位于不同事實(shí)表中處于一樣粒度的事實(shí)進(jìn)展組合建模而成的一種事實(shí)

26、表。即新建立一個事實(shí)表，它的維度是兩個或多個事實(shí)表的一樣維度的集合；事實(shí)是幾個事實(shí)表中感興趣的事實(shí)。在Kimball的總線架構(gòu)中，由合并事實(shí)表為主組成的合并數(shù)據(jù)集市稱為二級數(shù)據(jù)集市。合并事實(shí)表的粒度可以是原子粒度也可以是聚集粒度。在做數(shù)據(jù)遷移時，當(dāng)相關(guān)的原子事實(shí)表的數(shù)據(jù)有改變時，合并事實(shí)表的數(shù)據(jù)需要重新刷新。合并事實(shí)表和穿插探察是兩個互補(bǔ)的操作。聚集事實(shí)表和合并事實(shí)表的主要差異是合并事實(shí)表一般是從多個事實(shí)表合并而來。但是它們的差異不是絕對的，一個事實(shí)表既是聚集事實(shí)表又是合并事實(shí)表是很有可能的。因?yàn)橐话愫喜⑹聦?shí)表需要按一樣的維度合并，所以很可能在做合并的同時需要進(jìn)展聚集，即粒度變粗。事實(shí)維度-f

27、act dimension事務(wù)事實(shí)表-transaction fact table審計(jì)維度-audit dimension數(shù)據(jù)世系 data lineage數(shù)據(jù)倉庫中有一個概念叫做Data Lineage，中文一般翻譯為"數(shù)據(jù)世系"。數(shù)據(jù)世系描繪的是從源系統(tǒng)抽取數(shù)據(jù)開場，經(jīng)過數(shù)據(jù)轉(zhuǎn)換到最終的數(shù)據(jù)加載的整個過程中各種信息。數(shù)據(jù)世系信息需要留下詳細(xì)的文檔記載。數(shù)據(jù)世系包括源系統(tǒng)的數(shù)據(jù)庫中數(shù)據(jù)定義以及該數(shù)據(jù)在數(shù)據(jù)倉庫中的最終位置等信息。數(shù)據(jù)世系是數(shù)據(jù)倉庫的元數(shù)據(jù)中最重要的一部分。這部分元數(shù)據(jù)的產(chǎn)生位置是在ETL的處理過程中。假設(shè)在ETL的處理過程中使用的ETL工具的話，ETL工具

28、可以記錄下元數(shù)據(jù)的一部分，但是這部分一般都是數(shù)據(jù)的屬性描繪，而不是完全的數(shù)據(jù)世系。換一句說，完全依靠ETL工具來維護(hù)元數(shù)據(jù)是不夠的。雙桶連接-double-barreled joins退化維度 degenerate dimension在維度建模的數(shù)據(jù)倉庫中，有一種維度叫Degenerate Dimension，中文一般翻譯為"退化維度"。這種退化維度一般都是事務(wù)的編號，如訂單編號、發(fā)票編號等。這類編號需要保存到事實(shí)表中，但是不需要對應(yīng)的維度表，所以稱為退化維度。退化維度是維度建模領(lǐng)域中的一個非常重要的概念，它對理解維度建模有著非常重要的作用，尤其是對維度建模的入門者。退化維

29、度經(jīng)常會和其他一些維度一起組合成事實(shí)表的主鍵。在Kimball提出的維度建模中，事實(shí)表應(yīng)該保存最細(xì)粒度的數(shù)據(jù)。所以對于象銷售單這樣的事實(shí)表來說，需要銷售單編號和產(chǎn)品來共同作為主鍵，而不能用銷售日期、商場、產(chǎn)品等用來分析的維度共同作為主鍵。退化維度在分析中可以用來做分組使用。它可以將同一個事務(wù)中銷售的產(chǎn)品集中在一起。微型維度 minidimension維度建模的數(shù)據(jù)倉庫中，有一種維度叫minidimension，中文一般翻譯成"微型維度"。微型維度的提出主要是為理解決快變超大維度rapidly changing monster dimension。以客戶維度舉例來說，假設(shè)維度

30、表中有數(shù)百萬行記錄或者還要多，而且這些記錄中的字段又經(jīng)常變化，這樣的維度表一般稱之為快變超大維度。對于快變超大維度，設(shè)計(jì)人員一般不會使用TYPE 2的緩慢變化維處理方法，因?yàn)榇蠹叶疾辉敢庀虮緛砭陀袔装偃f行的維度表中添加更多的行。這時，有一項(xiàng)技術(shù)可以解決這個問題。解決的方法是，將分析頻率比較高或者變化頻率比較大的字段提取出來，建立一個單獨(dú)的維度表。這個單獨(dú)的維度表就是微型維度表。微型維度表有自己的關(guān)鍵字，這個關(guān)鍵字和原客戶維度表的關(guān)鍵字一起進(jìn)入事實(shí)表。有時為了分析的方便，可以把微型維度的關(guān)鍵字的最新值作為外關(guān)鍵字進(jìn)入客戶維度表。這時一定要注意，這個外關(guān)鍵字必須做TYPE 1型處理。在微型維度表中

31、假設(shè)有像收入這樣分布范圍較廣的屬性時，應(yīng)該將它分段處理。比方，存儲￥31257.98這樣過于分散的數(shù)值就不如存儲￥30000-￥34999這樣的范圍。這樣可以極大的減少微型維度中的記錄數(shù)目，也給分析帶來方便。蜈蚣事實(shí)表 centipede fact table在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Centipede fact table，中文一般翻譯為"蜈蚣事實(shí)表"。蜈蚣事實(shí)表是指那些一張事實(shí)表中有太多維度的事實(shí)表。連接在事實(shí)表兩邊的維度表過多，看起來就像蜈蚣一樣，所以稱為"蜈蚣事實(shí)表"。通常來說，蜈蚣事實(shí)表的出現(xiàn)是由于建模師對事實(shí)表和維度表逆標(biāo)準(zhǔn)化過了頭。例如，不

32、單將產(chǎn)品主鍵放入事實(shí)表中，對于產(chǎn)品層級構(gòu)造中的每一層的主鍵都放入事實(shí)表中，這樣事實(shí)表中與產(chǎn)品相關(guān)的就會有產(chǎn)品ID、商標(biāo)ID、子類ID、類別ID等多個外鍵。同樣，也有建模師將日期相關(guān)的日期ID、月ID、年ID都放入事實(shí)表中。這些都將產(chǎn)生蜈蚣事實(shí)表，使自己落入維度過多的陷阱。蜈蚣事實(shí)表雖然使查詢效率有所進(jìn)步，但是伴之而來的是存儲空間的大量增長。在維度建模的數(shù)據(jù)倉庫中，維度表的字段個數(shù)可以盡可能的增加，但是事實(shí)表的字段要盡量減少，因?yàn)橄啾榷裕聦?shí)表的記錄數(shù)要遠(yuǎn)遠(yuǎn)大于維度表的記錄數(shù)。一般來說，事實(shí)表相關(guān)的維度在15個以下為正常，假設(shè)維度個數(shù)超過25個，就出現(xiàn)了維度過多的蜈蚣事實(shí)表。這時，需要做的事情

33、是自己核查，將相關(guān)的維度進(jìn)展合并，減少維度的個數(shù)。稀疏事實(shí)表-sparse facts旋轉(zhuǎn)事實(shí)表-pivoted fact table在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫pivoted fact table，中文一般翻譯為"旋轉(zhuǎn)事實(shí)表"。旋轉(zhuǎn)事實(shí)表是將一條記錄中的多個事實(shí)字段轉(zhuǎn)化為多條記錄，其中每條記錄保存一個事實(shí)字段的一種建模方法。或者反過來，也可以由多條記錄轉(zhuǎn)化為一條記錄。旋轉(zhuǎn)事實(shí)表建模方法的使用通常是為了簡化前端數(shù)據(jù)展現(xiàn)的查詢。它通過改變后端的事實(shí)記錄存儲方式，使相應(yīng)的查詢需求的性能得到的極大的進(jìn)步。假設(shè)在SQL或者查詢工具中進(jìn)展這種轉(zhuǎn)換會非常費(fèi)事，效率也很差。和合并事實(shí)表類似

34、，有時當(dāng)根底表中沒有記錄時，旋轉(zhuǎn)事實(shí)表也要存儲一些零值在里面。一致性事實(shí) comformed fact維度建模的數(shù)據(jù)倉庫中，有一個概念叫Conformed Fact，中文一般翻譯為"一致性事實(shí)"。一致性事實(shí)是Kimball的多維體系構(gòu)造MD中的三個關(guān)鍵性概念之一，另兩個是總線架構(gòu)Bus Architecture和一致性維度Conformed Dimension。在建立多個數(shù)據(jù)集市時，完成一致性維度的工作就已經(jīng)完成了一致性的80%-90%的工作量。余下的工作就是建立一致性事實(shí)。一致性事實(shí)和一致性維度有些不同，一致性維度是由專人維護(hù)在后臺Back Room，發(fā)生修改時同步復(fù)制到

35、每個數(shù)據(jù)集市，而事實(shí)表一般不會在多個數(shù)據(jù)集市間復(fù)制。需要查詢多個數(shù)據(jù)集市中的事實(shí)時，一般通過穿插探查drill across來實(shí)現(xiàn)。為了能在多個數(shù)據(jù)集市間進(jìn)展穿插探查，一致性事實(shí)主要需要保證兩點(diǎn)。第一個是KPI的定義及計(jì)算方法要一致，第二個是事實(shí)的單位要一致性。假設(shè)業(yè)務(wù)要求或事實(shí)上就不能保持一致的話，建議不同單位的事實(shí)分開建立字段保存。這樣，一致性維度將多個數(shù)據(jù)集市結(jié)合在一起，一致性事實(shí)保證不同數(shù)據(jù)集市間的事實(shí)數(shù)據(jù)可以穿插探查，一個分布式的數(shù)據(jù)倉庫就建成了。一致性維度 comformed dimension維度建模的數(shù)據(jù)倉庫中，有一個概念叫Conformed Dimension，中文一般翻譯為

36、"一致性維度"。一致性維度是Kimball的多維體系構(gòu)造MD中的三個關(guān)鍵性概念之一，另兩個是總線架構(gòu)Bus Architecture和一致性事實(shí)Conformed Fact。在多維體系構(gòu)造中，沒有物理上的數(shù)據(jù)倉庫，由物理上的數(shù)據(jù)集市組合成邏輯上的數(shù)據(jù)倉庫。而且數(shù)據(jù)集市的建立是可以逐步完成的，最終組合在一起，成為一個數(shù)據(jù)倉庫。假設(shè)分步建立數(shù)據(jù)集市的過程出現(xiàn)了問題，數(shù)據(jù)集市就會變成孤立的集市，不能組合成數(shù)據(jù)倉庫，而一致性維度的提出正式為理解決這個問題。一致性維度的范圍是總線架構(gòu)中的維度，即可能會在多個數(shù)據(jù)集市中都存在的維度，這個范圍的選取需要架構(gòu)師來決定。一致性維度的內(nèi)容和普通

37、維度并沒有本質(zhì)上區(qū)別，都是經(jīng)過數(shù)據(jù)清洗和整合后的結(jié)果。一致性維度建立的地點(diǎn)是多維體系構(gòu)造的后臺Back Room，即數(shù)據(jù)準(zhǔn)備區(qū)。在多維體系構(gòu)造的數(shù)據(jù)倉庫工程組內(nèi)需要有專門的維度設(shè)計(jì)師，他的職責(zé)就是建立維度和維護(hù)維度的一致性。在后臺建立好的維度同步復(fù)制到各個數(shù)據(jù)集市。這樣所有數(shù)據(jù)集市的這部分維度都是完全一樣的。建立新的數(shù)據(jù)集市時，需要在后臺進(jìn)展一致性維度處理，根據(jù)情況來決定是否新增和修改一致性維度，然后同步復(fù)制到各個數(shù)據(jù)集市。這是不同數(shù)據(jù)集市維度保持一致的要點(diǎn)。在同一個集市內(nèi)，一致性維度的意思是兩個維度假設(shè)有關(guān)系，要么就是完全一樣的，要么就是一個維度在數(shù)學(xué)意義上是另一個維度的子集。例如，假設(shè)建立

38、月維度話，月維度的各種描繪必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在后續(xù)鉆取等操作時可以保持一致。假設(shè)維度表中的數(shù)據(jù)量較大，出于效率的考慮，應(yīng)該建立物化視圖或者實(shí)際的物理表。這樣，維度保持一致后，事實(shí)就可以保存在各個數(shù)據(jù)集市中。雖然在物理上是獨(dú)立的，但在邏輯上由一致性維度使所有的數(shù)據(jù)集市是聯(lián)絡(luò)在一起，隨時可以進(jìn)展穿插探察等操作，也就組成了數(shù)據(jù)倉庫。因果維度-casual dimension預(yù)連接聚集表 pre-joined aggregate table在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫pre-joined aggregagte t

39、able，中文一般翻譯為"預(yù)連接聚集表"。預(yù)連接聚集表是通過對事實(shí)表和維度表的結(jié)合查詢而生成的一類匯總表。在預(yù)連接聚集表中，保存有維度表中的描繪信息和事實(shí)表的事實(shí)值。通過預(yù)連接，可以防止在用戶查詢時RDBMS的連接操作，所以預(yù)連接聚集表的查詢效率要高很多。典型的預(yù)連接聚集表如下例所示的銷售事實(shí)表，產(chǎn)品名稱商標(biāo)名稱年份月份銷售人員名稱銷售量銷售金額在這個銷售事實(shí)表，前五個字段都來自于維度表的描繪字段，后兩個字段來自于事實(shí)表的事實(shí)字段。這樣在用戶提交查詢后，RDBMS就不需要連接維度表和事實(shí)表了，只需直接在該表中查詢即可。預(yù)連接聚集表有一個很大的缺點(diǎn)，它需要占用大量的存儲空間。預(yù)連接事實(shí)表的記錄和事實(shí)表一樣多，每條記錄的長度和維度表一樣長，所以對存儲空間的需求是非常大的。除非情況特殊，或者該表是高度匯總的，否那么不建議建立預(yù)連接聚集表。在建立預(yù)連接聚集表時需要平衡效率和存儲空間的矛盾。預(yù)