愛華網(wǎng)淺析冰山查詢――iceberg query
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫Iceberg query，中文一般翻譯為“冰山查詢”。冰山查詢?cè)谝粋€(gè)屬性或?qū)傩约嫌?jì)算一個(gè)聚集函數(shù)，以找出大于某個(gè)指定閾值的聚集值。
以銷售數(shù)據(jù)為例，你想產(chǎn)生這樣的一個(gè)顧客－商品對(duì)的列表，這些顧客購買商品的數(shù)量達(dá)到3件或更多。這可以用下面的冰山查詢表示：
SelectP.cust_ID, P.item_ID, SUM(P.qty)
FromPurchase P
Groupby P.cust_ID,P.item_ID
HavingSUM(P.qty)>=3
這種在給出大量輸入數(shù)據(jù)元組的情況下，使用having字句中的閾值來進(jìn)行過濾的查詢方法就叫做冰山查詢。輸出結(jié)果可以看作“冰山頂”，而“冰山”是輸入數(shù)據(jù)。
這種冰山查詢?cè)跀?shù)據(jù)倉庫的數(shù)據(jù)概況分析階段、數(shù)據(jù)質(zhì)量檢查階段和數(shù)據(jù)挖掘的購物籃分析中都經(jīng)常使用。而且，冰山查詢也是面試中出現(xiàn)頻率非常高的一道題，經(jīng)常用來檢測(cè)SQL能力。
操作集市――oper mart
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫Oper Mart，中文一般翻譯為“操作集市”。操作集市是為了企業(yè)戰(zhàn)術(shù)性的分析提供支持，它的數(shù)據(jù)來源是操作數(shù)據(jù)存儲(chǔ)（ODS）。它是ODS在分析功能上的擴(kuò)展，使用戶可以對(duì)操作型數(shù)據(jù)進(jìn)行多維分析。
一個(gè)操作集市應(yīng)該有如下特征：
1．操作集市是ODS的子集，數(shù)據(jù)來源于ODS，用于戰(zhàn)略分析和報(bào)表。
2．操作集市中的數(shù)據(jù)和ODS中的數(shù)據(jù)同步更新。
3．操作集市以多維技術(shù)進(jìn)行建模，即星型結(jié)構(gòu)。
4．操作集市是一個(gè)臨時(shí)的結(jié)構(gòu)，當(dāng)不在需要時(shí)會(huì)清掉所有數(shù)據(jù)，即不保存歷史數(shù)據(jù)。
操作集市和數(shù)據(jù)集市很相似，但是它不能用來取代用于戰(zhàn)略性分析的數(shù)據(jù)集市。由于操作集市的數(shù)據(jù)來源于ODS，所以它的數(shù)據(jù)比數(shù)據(jù)集市的數(shù)據(jù)要新。但是出于容量的考慮，操作集市中不保存歷史數(shù)據(jù)，是一個(gè)臨時(shí)的結(jié)構(gòu)。
操作數(shù)據(jù)存儲(chǔ)――operational data store
Kimball對(duì)操作數(shù)據(jù)存儲(chǔ)的定義是，面向主題的、集成的、經(jīng)常更新的細(xì)節(jié)數(shù)據(jù)存儲(chǔ)，用集成的數(shù)據(jù)來支持事務(wù)系統(tǒng)。Kimball也認(rèn)可Inmon對(duì)ODS的分類，但是他認(rèn)為ODS應(yīng)該以星型結(jié)構(gòu)來進(jìn)行建模。
雖然Kimball對(duì)操作數(shù)據(jù)存儲(chǔ)（ODS）的定義和Inmon基本上一樣，但是他對(duì)操作數(shù)據(jù)存儲(chǔ)的理解、作用與實(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í)的信息時(shí)，由于數(shù)據(jù)倉庫的更新頻率一般都是24小時(shí)，而用戶會(huì)有更急切的需求來了解數(shù)據(jù)源的信息，這時(shí)，建立操作數(shù)據(jù)存儲(chǔ)是很有必要的。
對(duì)于ODS是保存最細(xì)粒度數(shù)據(jù)的地方的說法，Kimball認(rèn)為對(duì)于最細(xì)粒度數(shù)據(jù)，即原子數(shù)據(jù)層，應(yīng)該保存在數(shù)據(jù)倉庫中，而且應(yīng)該置于維度框架和總線架構(gòu)中。
代理關(guān)鍵字－－surrogate key
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫Surrogate key，中文一般翻譯為“代理關(guān)鍵字”。代理關(guān)鍵字一般是指維度表中使用順序分配的整數(shù)值作為主鍵，也稱為“代理鍵”。代理關(guān)鍵字用于維度表和事實(shí)表的連接。
代理關(guān)鍵字的稱呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synthetic keys等。與之相對(duì)的自然關(guān)鍵字的稱呼有natural keys，samat keys等。
在Kimball的維度建模領(lǐng)域里，是強(qiáng)烈推薦使用代理關(guān)鍵字的。在維度表和事實(shí)表的每一個(gè)聯(lián)接中都應(yīng)該使用代理關(guān)鍵字，而不應(yīng)該使用自然關(guān)鍵字或者智能關(guān)鍵字（Smart Keys）。數(shù)據(jù)倉庫中的主鍵不應(yīng)該是智能的，也就是說，要避免通過主鍵的值就可以了解一些業(yè)務(wù)信息。當(dāng)然，退化維度作為事實(shí)表的復(fù)合主鍵之一時(shí)例外。
使用代理關(guān)鍵字，有很多優(yōu)點(diǎn)。
1．使用代理關(guān)鍵字能夠使數(shù)據(jù)倉庫環(huán)境對(duì)操作型環(huán)境的變化進(jìn)行緩沖。也就是說，當(dāng)數(shù)據(jù)倉庫需要對(duì)來在多個(gè)操作型系統(tǒng)的數(shù)據(jù)進(jìn)行整合時(shí)，這些系統(tǒng)中的數(shù)據(jù)有可能缺乏一致的關(guān)鍵字編碼，即有可能出現(xiàn)重復(fù)，這時(shí)代理關(guān)鍵字可以解決這個(gè)問題。
2．使用代理關(guān)鍵字可以帶來性能上的優(yōu)勢(shì)。和自然關(guān)鍵字相比，代理關(guān)鍵字很小，是整型的，可以減小事實(shí)表中記錄的長(zhǎng)度。這樣，同樣的IO就可以讀取更多的事實(shí)表記錄。另外，整型字段作為外鍵聯(lián)接的效率也很高。
3．使用代理關(guān)鍵字可以建立一些不存在的維度記錄，例如“不在促銷之列”，“日期待定”，“日期不可用”等維度記錄。
4．使用代理關(guān)鍵字可以用來處理緩慢變化維。維度表數(shù)據(jù)的歷史變化信息的保存是數(shù)據(jù)倉庫設(shè)計(jì)的實(shí)施中非常重要的一部分。Kimball的緩慢變化維處理策略的核心就是使用代理關(guān)鍵字。
當(dāng)然，使用代理關(guān)鍵字也有它的缺點(diǎn)，代理關(guān)鍵字的使用使數(shù)據(jù)加載變得非常復(fù)雜。有關(guān)使用代理關(guān)鍵字的維度表和事實(shí)表的加載方法在ETL Toolkit中有詳細(xì)的描述。使用代理關(guān)鍵字是一個(gè)從長(zhǎng)遠(yuǎn)考慮的策略。
多值維度――multivalue dimension
在維度建模的數(shù)據(jù)倉庫中，有一種維度表叫multivalue dimension，中文一般翻譯為“多值維度”。
多值維度有兩種情況，第一種情況是指維度表中的某個(gè)屬性字段同時(shí)有多個(gè)值。舉例來說，一個(gè)帳戶維度表中，帳戶持有人姓名，可能會(huì)有多個(gè)顧客。這樣，一個(gè)帳戶對(duì)應(yīng)多個(gè)顧客姓名，一個(gè)顧客也可以有多個(gè)帳戶，它們之間是多對(duì)多的關(guān)系。正因?yàn)橐粋€(gè)帳戶可能會(huì)有多個(gè)對(duì)應(yīng)的顧客，所以不能直接將顧客ID放入帳戶維度表中。而帳戶維度表中的這種情況就叫做多值維度。
多值維度的第二種情況是事實(shí)表在某個(gè)維度表中有多條對(duì)應(yīng)記錄。舉例來說，對(duì)于一個(gè)健康護(hù)理單分列項(xiàng)事實(shí)表來說，它的粒度是一個(gè)健康護(hù)理單，但是該護(hù)理單卻有可能有多次診斷，即該事實(shí)表與診斷維度的是一對(duì)多的關(guān)系。這個(gè)與事實(shí)表粒度不匹配的診斷維度也稱之為多值維度。
處理多值維度最好的辦法是降低事實(shí)表的粒度。如第二種情況中，將健康護(hù)理單分列項(xiàng)事實(shí)表的粒度降低到具體的診斷粒度上，這樣就避免了多值維度的出現(xiàn)。這種處理方式也是維度建模的一個(gè)原則，即事實(shí)表應(yīng)該建立在最細(xì)粒度上。這樣的處理，需要對(duì)事實(shí)表的事實(shí)進(jìn)行分?jǐn)偂?/p>
但是有些時(shí)候，事實(shí)表的粒度是不能降低的，多值維度的出現(xiàn)是無法避免的。如第一種情況中，事實(shí)表是月帳戶快照事實(shí)表，這張事實(shí)表與顧客維度沒有直接的關(guān)系，不能將數(shù)據(jù)粒度進(jìn)行細(xì)分，即使細(xì)分的話帳戶余額也很難分?jǐn)偂＿@時(shí)，可以采用橋接表技術(shù)進(jìn)行處理。在帳戶維度表和顧客維度表之間建立個(gè)帳戶-顧客橋接表。這個(gè)橋接表可以解決掉帳戶維度和顧客維度之間的多對(duì)多關(guān)系，也解決掉的帳戶維度表的多值維度問題。
總之，多值維度是應(yīng)該盡量避免的，它給數(shù)據(jù)處理帶來了很大的麻煩。如果多值維度不能避免的話，應(yīng)該建立橋接表來進(jìn)行處理。
非事實(shí)型事實(shí)表――factless fact table
在維度建模的數(shù)據(jù)倉庫中，有一種事實(shí)表叫Factless FactTable，中文一般翻譯為“非事實(shí)型事實(shí)表”。在事實(shí)表中，通常會(huì)保存十個(gè)左右的維度外鍵和多個(gè)度量事實(shí)，度量事實(shí)是事實(shí)表的關(guān)鍵所在。在非事實(shí)型事實(shí)表中沒有這些度量事實(shí)，只有多個(gè)維度外鍵。非事實(shí)型事實(shí)表通常用來跟蹤一些事件或者說明某些活動(dòng)的范圍。下面舉例來進(jìn)行說明。
第一類非事實(shí)型事實(shí)表是用來跟蹤事件的事實(shí)表。例如：學(xué)生注冊(cè)事件，學(xué)校需要對(duì)學(xué)生按學(xué)期進(jìn)行跟蹤。維度表包括學(xué)期維度、課程維度、系維度、學(xué)生維度、注冊(cè)專業(yè)維度和取得學(xué)分維度，而事實(shí)表是由這些維度的主鍵組成，事實(shí)只有注冊(cè)數(shù)，并且恒為1。這樣的事實(shí)表可以回答大量關(guān)于大學(xué)開課注冊(cè)方面的問題，主要是回答各種情況下的注冊(cè)數(shù)。
第二類非事實(shí)型事實(shí)表是用來說明某些活動(dòng)范圍的事實(shí)表。例如：促銷范圍事實(shí)表。通常銷售事實(shí)表可以回答如促銷商品的銷售情況，但是對(duì)于那些沒有銷售出去的促銷商品沒法回答。這時(shí)，通過建立促銷范圍事實(shí)表，將商場(chǎng)需要促銷的商品單獨(dú)建立事實(shí)表保存。然后，通過這個(gè)促銷范圍事實(shí)表和銷售事實(shí)表即可得出哪些促銷商品沒有銷售出去。這樣的促銷范圍事實(shí)表只是用來說明促銷活動(dòng)的范圍，其中沒有任何事實(shí)度量。
合并事實(shí)表－－consolidated/ merged fact table
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫merged fact table，或者consolidated fact table，中文一般都翻譯為“合并事實(shí)表”。合并事實(shí)表是將不同事實(shí)表的事實(shí)合并到同一張事實(shí)表的建模方法，合并的事實(shí)要保證在相同的粒度。
這種建模方法通常被用來橫跨多個(gè)業(yè)務(wù)主題域來建立數(shù)據(jù)集市，Kimball將這樣的數(shù)據(jù)集市稱為第二級(jí)的數(shù)據(jù)集市。使用合并事實(shí)表技術(shù)，可以避免性能較差的交叉探察操作。
但是，這種合并事實(shí)表和使用交叉探察操作還有著細(xì)微的不同，在一些基礎(chǔ)表中沒有記錄的時(shí)候，合并事實(shí)表中可能會(huì)存儲(chǔ)一條記錄，字段值保存為零。
合并事實(shí)表可以給數(shù)據(jù)倉庫帶來很大的性能提升，提供的跨主題的事實(shí)數(shù)據(jù)也給用戶帶來了很大的方便。但是，合并事實(shí)表給ETL工作帶來了較大的麻煩。對(duì)于合并事實(shí)表中涉及到的維度，需要在數(shù)據(jù)準(zhǔn)備區(qū)保證它們是一致性維度。
緩慢變化維――slowly changing dimension
維度建模的數(shù)據(jù)倉庫中，有一個(gè)概念叫Slowly ChangingDimensions，中文一般翻譯成“緩慢變化維”，經(jīng)常被簡(jiǎn)寫為SCD。緩慢變化維的提出是因?yàn)樵诂F(xiàn)實(shí)世界中，維度的屬性并不是靜態(tài)的，它會(huì)隨著時(shí)間的流失發(fā)生緩慢的變化。這種隨時(shí)間發(fā)生變化的維度我們一般稱之為緩慢變化維，并且把處理維度表的歷史變化信息的問題稱為處理緩慢變化維的問題，有時(shí)也簡(jiǎn)稱為處理SCD的問題。
處理緩慢變化維的方法通常分為三種方式。
第一種方式是直接覆蓋原值。這樣處理，最容易實(shí)現(xiàn)，但是沒有保留歷史數(shù)據(jù)，無法分析歷史變化信息。第一種方式通常簡(jiǎn)稱為“TYPE1”。
第二種方式是添加維度行。這樣處理，需要代理鍵的支持。實(shí)現(xiàn)方式是當(dāng)有維度屬性發(fā)生變化時(shí)，生成一條新的維度記錄，主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關(guān)聯(lián)。第二種方式通常簡(jiǎn)稱為“TYPE2”。
第三種方式是添加屬性列。這種處理的實(shí)現(xiàn)方式是對(duì)于需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本屬性字段使用TYPE1來直接覆蓋。這種方式的優(yōu)點(diǎn)是可以同時(shí)分析當(dāng)前及前一次變化的屬性值，缺點(diǎn)是只保留了最后一次變化信息。第三種方式通常簡(jiǎn)稱為“TYPE3”。
在實(shí)際建模中，我們可以聯(lián)合使用三種方式，也可以對(duì)一個(gè)維度表中的不同屬性使用不同的方式，這些，都需要根據(jù)實(shí)際情況來決定，但目的都是一樣的，就是能夠支持方便的分析歷史變化情況。
即席查詢――ad hoc queries
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫Ad hoc queries，中文一般翻譯為“即席查詢”。即席查詢是指那些用戶在使用系統(tǒng)時(shí)，根據(jù)自己當(dāng)時(shí)的需求定義的查詢。
即席查詢生成的方式很多，最常見的就是使用即席查詢工具。一般的數(shù)據(jù)展現(xiàn)工具都會(huì)提供即席查詢的功能。通常的方式是，將數(shù)據(jù)倉庫中的維度表和事實(shí)表映射到語義層，用戶可以通過語義層選擇表，建立表間的關(guān)聯(lián)，最終生成SQL語句。
即席查詢與通常查詢從SQL語句上來說，并沒有本質(zhì)的差別。它們之間的差別在于，通常的查詢?cè)谙到y(tǒng)設(shè)計(jì)和實(shí)施時(shí)是已知的，所有我們可以在系統(tǒng)實(shí)施時(shí)通過建立索引、分區(qū)等技術(shù)來優(yōu)化這些查詢，使這些查詢的效率很高。而即席查詢是用戶在使用時(shí)臨時(shí)生產(chǎn)的，系統(tǒng)無法預(yù)先優(yōu)化這些查詢，所以即席查詢也是評(píng)估數(shù)據(jù)倉庫的一個(gè)重要指標(biāo)。
即席查詢的位置通常是在關(guān)系型的數(shù)據(jù)倉庫中，即在EDW或者ROLAP中。多維數(shù)據(jù)庫有自己的存儲(chǔ)方式，對(duì)即席查詢和通常查詢沒有區(qū)別。
在一個(gè)數(shù)據(jù)倉庫系統(tǒng)中，即席查詢使用的越多，對(duì)數(shù)據(jù)倉庫的要求就越高，對(duì)數(shù)據(jù)模型的對(duì)稱性的要求也越高。對(duì)稱性的數(shù)據(jù)模型對(duì)所有的查詢都是相同的，這也是維度建模的一個(gè)優(yōu)點(diǎn)。
交叉探察――drill across
在維度建模的數(shù)據(jù)倉庫中，有一種操作叫DrillAcross，中文一般翻譯為“交叉探查”。鑒于經(jīng)驗(yàn)的局限，在這里我只能進(jìn)行一下淺顯的分析。
在基于總線架構(gòu)（BusArchitecture）的維度建模中，大部分的維度表是由事實(shí)表共有的。比如“營(yíng)銷事務(wù)事實(shí)表”和“庫存快照事實(shí)表”就會(huì)有相同的維度表，“日期維度”、“產(chǎn)品維度”和“商場(chǎng)維度”。這時(shí)，如果有個(gè)需求是想按共有維度來對(duì)比查看銷售和庫存的事實(shí)，這時(shí)就需要發(fā)出兩個(gè)SQL，分別查出按維度統(tǒng)計(jì)出的銷售數(shù)據(jù)和庫存數(shù)據(jù)。然后再基于共有的維度進(jìn)行外連接，將數(shù)據(jù)合并。這種發(fā)出多路SQL再進(jìn)行合并的操作就是交叉探查。
當(dāng)這種交叉探查的需求很常用時(shí)，有一種建模方法可以避免交叉探查，就是合并事實(shí)表（Consolidated FactTable）。合并事實(shí)表是指將位于不同事實(shí)表中處于相同粒度的事實(shí)進(jìn)行組合的一種建模方法。即新建立一個(gè)事實(shí)表，它的維度是兩個(gè)或多個(gè)事實(shí)表的相同維度的集合，事實(shí)是幾個(gè)事實(shí)表中感興趣的事實(shí)。這個(gè)事實(shí)表的數(shù)據(jù)和其他事實(shí)表的數(shù)據(jù)一樣來自StagingArea。
合并事實(shí)表在性能和易用性上都比交叉探查要好，但是被組合的事實(shí)表必須處于相同的粒度和維度層次上。
角色模仿維度－－role-playing dimensions
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫Role-playing dimensions，中文一般翻譯為“角色模仿維度”。角色模仿維度是為了處理一個(gè)維度在一個(gè)事實(shí)表中同時(shí)出現(xiàn)多次而使用的一種技術(shù)處理手段。
在建立了角色模仿維度以后，在底層只有一個(gè)物理表存在，但是針對(duì)這個(gè)物理表會(huì)建立多個(gè)角色提供給數(shù)據(jù)訪問工具，而且對(duì)數(shù)據(jù)訪問工具來說這多個(gè)角色是不同的。例如對(duì)與累計(jì)快照事實(shí)表中會(huì)出現(xiàn)多個(gè)日期字段聯(lián)接到日期維度。這時(shí)就可以針對(duì)日期維度建立多個(gè)角色模仿維度。
角色模仿維度的建立方法通常是使用視圖來完成。例如訂單日期維度表如下所示：
CREATE VIEW order_date(order_date_key,order_day_of_week, order_month, … )
AS SELECT data_key, day_of_week, month, … FROMDATA
使用同樣的方式還可以建立多個(gè)不同日期的角色模仿維度。
需要補(bǔ)充的一點(diǎn)是，目前市場(chǎng)上的大部分展現(xiàn)工具，都提供了對(duì)一個(gè)表選擇多次的功能。也就是說，角色模仿維度的功能展現(xiàn)工具自己就可以實(shí)現(xiàn)。這樣，就不需要我們?cè)跀?shù)據(jù)庫中建立角色模仿維度的視圖了，而直接使用展現(xiàn)工具完成即可。
聚集事實(shí)表－－aggregated fact table
累計(jì)快照事實(shí)表－－accumulating snapshot facttable
橋接表－－bridge table
切片事實(shí)表－－sliced fact table
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫sliced fact table，中文一般翻譯為“切片事實(shí)表”。切片事實(shí)表中的字段結(jié)構(gòu)和相應(yīng)的基礎(chǔ)表完全相同，差別在于存儲(chǔ)的記錄的范圍。切片事實(shí)表中保存記錄的是相應(yīng)基礎(chǔ)表中記錄的子集，記錄數(shù)通常與某個(gè)維度記錄數(shù)相同。
這種建模方法一般用來滿足特殊需要，如需要分析某些特殊問題時(shí)，可以將與之相關(guān)的數(shù)據(jù)切片出來。相反，這種方法也常用于合并存儲(chǔ)在不同地區(qū)的數(shù)據(jù)，即各個(gè)地區(qū)都保存自己地區(qū)的數(shù)據(jù)，總部和所有地區(qū)的表結(jié)構(gòu)都相同，然后總部將所有地區(qū)的數(shù)據(jù)合并在一起。
切片事實(shí)表的結(jié)構(gòu)與相對(duì)應(yīng)的基礎(chǔ)表相同，數(shù)據(jù)來源于相對(duì)應(yīng)的基礎(chǔ)表。切片事實(shí)表由于縮小了表中數(shù)據(jù)的記錄數(shù)，所以查詢的效率得到了很大的提高。
事實(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 FactTable），周期快照粒度事實(shí)表（Periodic Snapshot Grain FactTable）和累積快照粒度事實(shí)表（Accumulating Snapshot GrainFact Table）。
事務(wù)粒度事實(shí)表中的一條記錄代表了業(yè)務(wù)系統(tǒng)中的一個(gè)事件。事務(wù)出現(xiàn)以后，就會(huì)在事實(shí)中出現(xiàn)一條記錄。事務(wù)粒度事實(shí)表也稱為原子粒度。典型的例子是銷售單分列項(xiàng)事實(shí)表。
周期快照粒度事實(shí)表用來記錄有規(guī)律的，可預(yù)見時(shí)間間隔的業(yè)務(wù)累計(jì)數(shù)據(jù)。通常的時(shí)間間隔可以是每天、每周或者每月。典型的例子是庫存日快照事實(shí)表。
累積快照事實(shí)表一般用來涵蓋一個(gè)事務(wù)的生命周期內(nèi)的不確定的時(shí)間跨度。典型的例子是KDT#2中描述的具有多個(gè)日期字段的發(fā)貨事實(shí)表。
通常來說，事務(wù)和快照是建模中的兩個(gè)非常重要的特點(diǎn)，將兩者相結(jié)合可以使模型建立的更完整。
從用途的不同來說，事實(shí)表可以分為三類，分別是原子事實(shí)表，聚集事實(shí)表和合并事實(shí)表。
原子事實(shí)表（Atom FactTable）是保存最細(xì)粒度數(shù)據(jù)的事實(shí)表，也是數(shù)據(jù)倉庫中保存原子信息的場(chǎng)所。
聚集事實(shí)表（Aggregated FactTable）是原子事實(shí)表上的匯總數(shù)據(jù)，也稱為匯總事實(shí)表。即新建立一個(gè)事實(shí)表，它的維度表是比原維度表要少，或者某些維度表是原維度表的子集，如用月份維度表代替日期維度表；事實(shí)數(shù)據(jù)是相應(yīng)事實(shí)的匯總，即求和或求平均值等。在做數(shù)據(jù)遷移時(shí)，當(dāng)相關(guān)的維度數(shù)據(jù)和事實(shí)數(shù)據(jù)發(fā)生變化時(shí)，聚集事實(shí)表需要做相應(yīng)的刷新。物化視圖是實(shí)現(xiàn)聚集事實(shí)表的一種有效方式，可以設(shè)定刷新方式，具體功能由DBMS來實(shí)現(xiàn)。
合并事實(shí)表（Consolidated FactTable）是指將位于不同事實(shí)表中處于相同粒度的事實(shí)進(jìn)行組合建模而成的一種事實(shí)表。即新建立一個(gè)事實(shí)表，它的維度是兩個(gè)或多個(gè)事實(shí)表的相同維度的集合；事實(shí)是幾個(gè)事實(shí)表中感興趣的事實(shí)。在Kimball的總線架構(gòu)中，由合并事實(shí)表為主組成的合并數(shù)據(jù)集市稱為二級(jí)數(shù)據(jù)集市。合并事實(shí)表的粒度可以是原子粒度也可以是聚集粒度。在做數(shù)據(jù)遷移時(shí)，當(dāng)相關(guān)的原子事實(shí)表的數(shù)據(jù)有改變時(shí)，合并事實(shí)表的數(shù)據(jù)需要重新刷新。合并事實(shí)表和交叉探察是兩個(gè)互補(bǔ)的操作。
聚集事實(shí)表和合并事實(shí)表的主要差別是合并事實(shí)表一般是從多個(gè)事實(shí)表合并而來。但是它們的差別不是絕對(duì)的，一個(gè)事實(shí)表既是聚集事實(shí)表又是合并事實(shí)表是很有可能的。因?yàn)橐话愫喜⑹聦?shí)表需要按相同的維度合并，所以很可能在做合并的同時(shí)需要進(jìn)行聚集，即粒度變粗。
事實(shí)維度－－fact dimension
事務(wù)事實(shí)表－－transaction fact table
審計(jì)維度－－audit dimension
數(shù)據(jù)世系――data lineage
數(shù)據(jù)倉庫中有一個(gè)概念叫做Data Lineage，中文一般翻譯為“數(shù)據(jù)世系”。數(shù)據(jù)世系描述的是從源系統(tǒng)抽取數(shù)據(jù)開始，經(jīng)過數(shù)據(jù)轉(zhuǎn)換到最終的數(shù)據(jù)加載的整個(gè)過程中各種信息。
數(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的處理過程中。
如果在ETL的處理過程中使用的ETL工具的話，ETL工具可以記錄下元數(shù)據(jù)的一部分，但是這部分一般都是數(shù)據(jù)的屬性描述，而不是完全的數(shù)據(jù)世系。換一句說，完全依靠ETL工具來維護(hù)元數(shù)據(jù)是不夠的。
雙桶連接－－double-barreled joins
退化維度――degenerate dimension
在維度建模的數(shù)據(jù)倉庫中，有一種維度叫DegenerateDimension，中文一般翻譯為“退化維度”。這種退化維度一般都是事務(wù)的編號(hào)，如訂單編號(hào)、發(fā)票編號(hào)等。這類編號(hào)需要保存到事實(shí)表中，但是不需要對(duì)應(yīng)的維度表，所以稱為退化維度。
退化維度是維度建模領(lǐng)域中的一個(gè)非常重要的概念，它對(duì)理解維度建模有著非常重要的作用，尤其是對(duì)維度建模的入門者。
退化維度經(jīng)常會(huì)和其他一些維度一起組合成事實(shí)表的主鍵。在Kimball提出的維度建模中，事實(shí)表應(yīng)該保存最細(xì)粒度的數(shù)據(jù)。所以對(duì)于象銷售單這樣的事實(shí)表來說，需要銷售單編號(hào)和產(chǎn)品來共同作為主鍵，而不能用銷售日期、商場(chǎng)、產(chǎn)品等用來分析的維度共同作為主鍵。
退化維度在分析中可以用來做分組使用。它可以將同一個(gè)事務(wù)中銷售的產(chǎn)品集中在一起。
微型維度――minidimension
維度建模的數(shù)據(jù)倉庫中，有一種維度叫minidimension，中文一般翻譯成“微型維度”。微型維度的提出主要是為了解決快變超大維度（rapidly changingmonster dimension）。
以客戶維度舉例來說，如果維度表中有數(shù)百萬行記錄或者還要多，而且這些記錄中的字段又經(jīng)常變化，這樣的維度表一般稱之為快變超大維度。對(duì)于快變超大維度，設(shè)計(jì)人員一般不會(huì)使用TYPE2的緩慢變化維處理方法，因?yàn)榇蠹叶疾辉敢庀虮緛砭陀袔装偃f行的維度表中添加更多的行。
這時(shí)，有一項(xiàng)技術(shù)可以解決這個(gè)問題。解決的方法是，將分析頻率比較高或者變化頻率比較大的字段提取出來，建立一個(gè)單獨(dú)的維度表。這個(gè)單獨(dú)的維度表就是微型維度表。
微型維度表有自己的關(guān)鍵字，這個(gè)關(guān)鍵字和原客戶維度表的關(guān)鍵字一起進(jìn)入事實(shí)表。有時(shí)為了分析的方便，可以把微型維度的關(guān)鍵字的最新值作為外關(guān)鍵字進(jìn)入客戶維度表。這時(shí)一定要注意，這個(gè)外關(guān)鍵字必須做TYPE1型處理。
在微型維度表中如果有像收入這樣分布范圍較廣的屬性時(shí)，應(yīng)該將它分段處理。比如，存儲(chǔ)￥31257.98這樣過于分散的數(shù)值就不如存儲(chǔ)￥30000－￥34999這樣的范圍。這樣可以極大的減少微型維度中的記錄數(shù)目，也給分析帶來方便。
蜈蚣事實(shí)表――centipede fact table
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫Centipede fact table，中文一般翻譯為“蜈蚣事實(shí)表”。蜈蚣事實(shí)表是指那些一張事實(shí)表中有太多維度的事實(shí)表。連接在事實(shí)表兩邊的維度表過多，看起來就像蜈蚣一樣，所以稱為“蜈蚣事實(shí)表”。
通常來說，蜈蚣事實(shí)表的出現(xiàn)是由于建模師對(duì)事實(shí)表和維度表逆規(guī)范化過了頭。例如，不單將產(chǎn)品主鍵放入事實(shí)表中，對(duì)于產(chǎn)品層級(jí)結(jié)構(gòu)中的每一層的主鍵都放入事實(shí)表中，這樣事實(shí)表中與產(chǎn)品相關(guān)的就會(huì)有產(chǎn)品ID、商標(biāo)ID、子類ID、類別ID等多個(gè)外鍵。同樣，也有建模師將日期相關(guān)的日期ID、月ID、年ID都放入事實(shí)表中。這些都將產(chǎn)生蜈蚣事實(shí)表，使自己落入維度過多的陷阱。
蜈蚣事實(shí)表雖然使查詢效率有所提高，但是伴之而來的是存儲(chǔ)空間的大量增長(zhǎng)。在維度建模的數(shù)據(jù)倉庫中，維度表的字段個(gè)數(shù)可以盡可能的增加，但是事實(shí)表的字段要盡量減少，因?yàn)橄啾榷?，事?shí)表的記錄數(shù)要遠(yuǎn)遠(yuǎn)大于維度表的記錄數(shù)。
一般來說，事實(shí)表相關(guān)的維度在15個(gè)以下為正常，如果維度個(gè)數(shù)超過25個(gè)，就出現(xiàn)了維度過多的蜈蚣事實(shí)表。這時(shí)，需要做的事情是自己核查，將相關(guān)的維度進(jìn)行合并，減少維度的個(gè)數(shù)。
稀疏事實(shí)表－－sparse facts
旋轉(zhuǎn)事實(shí)表－－pivoted fact table
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫pivoted fact table，中文一般翻譯為“旋轉(zhuǎn)事實(shí)表”。旋轉(zhuǎn)事實(shí)表是將一條記錄中的多個(gè)事實(shí)字段轉(zhuǎn)化為多條記錄，其中每條記錄保存一個(gè)事實(shí)字段的一種建模方法。或者反過來，也可以由多條記錄轉(zhuǎn)化為一條記錄。
旋轉(zhuǎn)事實(shí)表建模方法的使用通常是為了簡(jiǎn)化前端數(shù)據(jù)展現(xiàn)的查詢。它通過改變后端的事實(shí)記錄存儲(chǔ)方式，使相應(yīng)的查詢需求的性能得到的極大的提高。如果在SQL或者查詢工具中進(jìn)行這種轉(zhuǎn)換會(huì)非常麻煩，效率也很差。
和合并事實(shí)表類似，有時(shí)當(dāng)基礎(chǔ)表中沒有記錄時(shí)，旋轉(zhuǎn)事實(shí)表也要存儲(chǔ)一些零值在里面。
一致性事實(shí)――comformed fact
維度建模的數(shù)據(jù)倉庫中，有一個(gè)概念叫ConformedFact，中文一般翻譯為“一致性事實(shí)”。一致性事實(shí)是Kimball的多維體系結(jié)構(gòu)（MD）中的三個(gè)關(guān)鍵性概念之一，另兩個(gè)是總線架構(gòu)（BusArchitecture）和一致性維度（ConformedDimension）。
在建立多個(gè)數(shù)據(jù)集市時(shí)，完成一致性維度的工作就已經(jīng)完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事實(shí)。
一致性事實(shí)和一致性維度有些不同，一致性維度是由專人維護(hù)在后臺(tái)（BackRoom），發(fā)生修改時(shí)同步復(fù)制到每個(gè)數(shù)據(jù)集市，而事實(shí)表一般不會(huì)在多個(gè)數(shù)據(jù)集市間復(fù)制。需要查詢多個(gè)數(shù)據(jù)集市中的事實(shí)時(shí)，一般通過交叉探查（drillacross）來實(shí)現(xiàn)。
為了能在多個(gè)數(shù)據(jù)集市間進(jìn)行交叉探查，一致性事實(shí)主要需要保證兩點(diǎn)。第一個(gè)是KPI的定義及計(jì)算方法要一致，第二個(gè)是事實(shí)的單位要一致性。如果業(yè)務(wù)要求或事實(shí)上就不能保持一致的話，建議不同單位的事實(shí)分開建立字段保存。
這樣，一致性維度將多個(gè)數(shù)據(jù)集市結(jié)合在一起，一致性事實(shí)保證不同數(shù)據(jù)集市間的事實(shí)數(shù)據(jù)可以交叉探查，一個(gè)分布式的數(shù)據(jù)倉庫就建成了。
一致性維度――comformed dimension
維度建模的數(shù)據(jù)倉庫中，有一個(gè)概念叫ConformedDimension，中文一般翻譯為“一致性維度”。一致性維度是Kimball的多維體系結(jié)構(gòu)（MD）中的三個(gè)關(guān)鍵性概念之一，另兩個(gè)是總線架構(gòu)（BusArchitecture）和一致性事實(shí)（ConformedFact）。
在多維體系結(jié)構(gòu)中，沒有物理上的數(shù)據(jù)倉庫，由物理上的數(shù)據(jù)集市組合成邏輯上的數(shù)據(jù)倉庫。而且數(shù)據(jù)集市的建立是可以逐步完成的，最終組合在一起，成為一個(gè)數(shù)據(jù)倉庫。如果分步建立數(shù)據(jù)集市的過程出現(xiàn)了問題，數(shù)據(jù)集市就會(huì)變成孤立的集市，不能組合成數(shù)據(jù)倉庫，而一致性維度的提出正式為了解決這個(gè)問題。
一致性維度的范圍是總線架構(gòu)中的維度，即可能會(huì)在多個(gè)數(shù)據(jù)集市中都存在的維度，這個(gè)范圍的選取需要架構(gòu)師來決定。一致性維度的內(nèi)容和普通維度并沒有本質(zhì)上區(qū)別，都是經(jīng)過數(shù)據(jù)清洗和整合后的結(jié)果。
一致性維度建立的地點(diǎn)是多維體系結(jié)構(gòu)的后臺(tái)（BackRoom），即數(shù)據(jù)準(zhǔn)備區(qū)。在多維體系結(jié)構(gòu)的數(shù)據(jù)倉庫項(xiàng)目組內(nèi)需要有專門的維度設(shè)計(jì)師，他的職責(zé)就是建立維度和維護(hù)維度的一致性。在后臺(tái)建立好的維度同步復(fù)制到各個(gè)數(shù)據(jù)集市。這樣所有數(shù)據(jù)集市的這部分維度都是完全相同的。建立新的數(shù)據(jù)集市時(shí)，需要在后臺(tái)進(jìn)行一致性維度處理，根據(jù)情況來決定是否新增和修改一致性維度，然后同步復(fù)制到各個(gè)數(shù)據(jù)集市。這是不同數(shù)據(jù)集市維度保持一致的要點(diǎn)。
在同一個(gè)集市內(nèi)，一致性維度的意思是兩個(gè)維度如果有關(guān)系，要么就是完全一樣的，要么就是一個(gè)維度在數(shù)學(xué)意義上是另一個(gè)維度的子集。例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在后續(xù)鉆取等操作時(shí)可以保持一致。如果維度表中的數(shù)據(jù)量較大，出于效率的考慮，應(yīng)該建立物化視圖或者實(shí)際的物理表。
這樣，維度保持一致后，事實(shí)就可以保存在各個(gè)數(shù)據(jù)集市中。雖然在物理上是獨(dú)立的，但在邏輯上由一致性維度使所有的數(shù)據(jù)集市是聯(lián)系在一起，隨時(shí)可以進(jìn)行交叉探察等操作，也就組成了數(shù)據(jù)倉庫。
因果維度－－casual dimension
預(yù)連接聚集表――pre-joined aggregate table
在數(shù)據(jù)倉庫領(lǐng)域有一個(gè)概念叫pre-joined aggregagte table，中文一般翻譯為“預(yù)連接聚集表”。預(yù)連接聚集表是通過對(duì)事實(shí)表和維度表的聯(lián)合查詢而生成的一類匯總表。在預(yù)連接聚集表中，保存有維度表中的描述信息和事實(shí)表的事實(shí)值。
通過預(yù)連接，可以避免在用戶查詢時(shí)RDBMS的連接操作，所以預(yù)連接聚集表的查詢效率要高很多。
典型的預(yù)連接聚集表如下例所示的銷售事實(shí)表，
產(chǎn)品名稱
商標(biāo)名稱
年份
月份
銷售人員名稱
銷售量
銷售金額
在這個(gè)銷售事實(shí)表，前五個(gè)字段都來自于維度表的描述字段，后兩個(gè)字段來自于事實(shí)表的事實(shí)字段。這樣在用戶提交查詢后，RDBMS就不需要連接維度表和事實(shí)表了，只需直接在該表中查詢即可。
預(yù)連接聚集表有一個(gè)很大的缺點(diǎn)，它需要占用大量的存儲(chǔ)空間。預(yù)連接事實(shí)表的記錄和事實(shí)表一樣多，每條記錄的長(zhǎng)度和維度表一樣長(zhǎng)，所以對(duì)存儲(chǔ)空間的需求是非常大的。除非情況特殊，或者該表是高度匯總的，否則不建議建立預(yù)連接聚集表。在建立預(yù)連接聚集表時(shí)需要平衡效率和存儲(chǔ)空間的矛盾。
預(yù)連接聚集表的生成方式較為簡(jiǎn)單，直接使用SQL查詢即可生成。
如果聚集導(dǎo)航器的功能很強(qiáng)大的話，也可以處理預(yù)連接聚集表。否則，需要用戶理解預(yù)連接聚集表，并在SQL中直接使用該表。
預(yù)連接聚集表在數(shù)據(jù)倉庫領(lǐng)域有著很重要的作用，是匯總表的一種。它的優(yōu)點(diǎn)和缺點(diǎn)都很明顯，在使用時(shí)需要綜合考慮。
原子事實(shí)表－－atom fact table
雜項(xiàng)維度――junk dimension
在維度建模的數(shù)據(jù)倉庫中，有一種維度叫JunkDimension，中文一般翻譯為“雜項(xiàng)維度”。雜項(xiàng)維度是由操作系統(tǒng)中的指示符或者標(biāo)志字段組合而成，一般不在一致性維度之列。
在操作系統(tǒng)中，我們定義好各種維度后，通常還會(huì)剩下一些在小范圍內(nèi)取離散值的指示符或者標(biāo)志字段。例如：支付類型字段，包括現(xiàn)金和信用卡兩種類型，在源系統(tǒng)中它們可能是維護(hù)在類型表中，也可能直接保存在交易表中。
一張事實(shí)表中可能會(huì)存在好幾個(gè)類似的字段，如果作為事實(shí)存放在事實(shí)表中，會(huì)導(dǎo)致事實(shí)表占用空間過大；如果單獨(dú)建立維度表，外鍵關(guān)聯(lián)到事實(shí)表，會(huì)出現(xiàn)維度過多的情況；如果將這些字段刪除，會(huì)有人不同意。
這時(shí)，我們通常的解決方案就是建立雜項(xiàng)維度，將這些字段建立到一個(gè)維度表中，在事實(shí)表中只需保存一個(gè)外鍵。幾個(gè)字段的不同取值組成一條記錄，生成代理鍵，存入維度表，并將該代理鍵保存入相應(yīng)的事實(shí)表字段。建議不要直接使用所有的組合生成完整的雜項(xiàng)維度表，在抽取時(shí)遇到新的組合時(shí)生成相應(yīng)記錄即可。雜項(xiàng)維度的ETL過程比一般的維度略為復(fù)雜。
總線架構(gòu)――bus architecture
維度建模的數(shù)據(jù)倉庫中，有一個(gè)概念叫BusArchitecture，中文一般翻譯為“總線架構(gòu)”。總線架構(gòu)是Kimball的多維體系結(jié)構(gòu)（MD）中的三個(gè)關(guān)鍵性概念之一，另兩個(gè)是一致性維度（ConformedDimension）和一致性事實(shí)（ConformedFact）。
在多維體系結(jié)構(gòu)（MD）的數(shù)據(jù)倉庫架構(gòu)中，主導(dǎo)思想是分步建立數(shù)據(jù)倉庫，由數(shù)據(jù)集市組合成企業(yè)的數(shù)據(jù)倉庫。但是，在建立第一個(gè)數(shù)據(jù)集市前，架構(gòu)師首先要做的就是設(shè)計(jì)出在整個(gè)企業(yè)內(nèi)具有統(tǒng)一解釋的標(biāo)準(zhǔn)化的維度和事實(shí)，即一致性維度和一致性事實(shí)。而開發(fā)團(tuán)隊(duì)必須嚴(yán)格的按照這個(gè)體系結(jié)構(gòu)來進(jìn)行數(shù)據(jù)集市的迭代開發(fā)。
一致性維度就好比企業(yè)范圍內(nèi)的一組總線，不同數(shù)據(jù)集市的事實(shí)的就好比插在這組總線上的元件。這也是稱之為總線架構(gòu)的原因。
實(shí)際設(shè)計(jì)過程中，我們通常把總線架構(gòu)列表成矩陣的形式，其中列為一致性維度，行為不同的業(yè)務(wù)處理過程，即事實(shí)，在交叉點(diǎn)上打上標(biāo)記表示該業(yè)務(wù)處理過程與該維度相關(guān)。這個(gè)矩陣也稱為總線矩陣（BusMatrix）。
總線架構(gòu)和一致性維度、一致性事實(shí)共同組成了Kimball的多維體系結(jié)構(gòu)的基礎(chǔ)，也建立了一套可以逐步建立數(shù)據(jù)倉庫的方法論。由于總線架構(gòu)是多維體系結(jié)構(gòu)的核心，所以我們有時(shí)就把多維體系結(jié)構(gòu)直接稱為總線架構(gòu)。
支架維度－－outrigger dimension
周期快照事實(shí)表－－periodic snapshot fact table
