數(shù)據(jù)倉庫概念一覽_第1頁
數(shù)據(jù)倉庫概念一覽_第2頁
數(shù)據(jù)倉庫概念一覽_第3頁
數(shù)據(jù)倉庫概念一覽_第4頁
數(shù)據(jù)倉庫概念一覽_第5頁
已閱讀5頁,還剩27頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

數(shù)據(jù)倉庫概念一覽數(shù)據(jù)倉庫概念一覽數(shù)據(jù)倉庫概念一覽xxx公司數(shù)據(jù)倉庫概念一覽文件編號:文件日期:修訂次數(shù):第1.0次更改批準(zhǔn)審核制定方案設(shè)計,管理制度淺析冰山查詢――icebergquery在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Icebergquery,中文一般翻譯為“冰山查詢”。冰山查詢在一個屬性或?qū)傩约嫌嬎阋粋€聚集函數(shù),以找出大于某個指定閾值的聚集值。以銷售數(shù)據(jù)為例,你想產(chǎn)生這樣的一個顧客-商品對的列表,這些顧客購買商品的數(shù)量達到3件或更多。這可以用下面的冰山查詢表示:Select

,,SUMFrom

PurchasePGroupby

,Having

SUM>=3這種在給出大量輸入數(shù)據(jù)元組的情況下,使用having字句中的閾值來進行過濾的查詢方法就叫做冰山查詢。輸出結(jié)果可以看作“冰山頂”,而“冰山”是輸入數(shù)據(jù)。這種冰山查詢在數(shù)據(jù)倉庫的數(shù)據(jù)概況分析階段、數(shù)據(jù)質(zhì)量檢查階段和數(shù)據(jù)挖掘的購物籃分析中都經(jīng)常使用。而且,冰山查詢也是面試中出現(xiàn)頻率非常高的一道題,經(jīng)常用來檢測SQL能力。操作集市――opermart在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫OperMart,中文一般翻譯為“操作集市”。操作集市是為了企業(yè)戰(zhàn)術(shù)性的分析提供支持,它的數(shù)據(jù)來源是操作數(shù)據(jù)存儲(ODS)。它是ODS在分析功能上的擴展,使用戶可以對操作型數(shù)據(jù)進行多維分析。一個操作集市應(yīng)該有如下特征:1.操作集市是ODS的子集,數(shù)據(jù)來源于ODS,用于戰(zhàn)略分析和報表。2.操作集市中的數(shù)據(jù)和ODS中的數(shù)據(jù)同步更新。3.操作集市以多維技術(shù)進行建模,即星型結(jié)構(gòu)。4.操作集市是一個臨時的結(jié)構(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ù),是一個臨時的結(jié)構(gòu)。操作數(shù)據(jù)存儲――operationaldatastoreKimball對操作數(shù)據(jù)存儲的定義是,面向主題的、集成的、經(jīng)常更新的細節(jié)數(shù)據(jù)存儲,用集成的數(shù)據(jù)來支持事務(wù)系統(tǒng)。Kimball也認可Inmon對ODS的分類,但是他認為ODS應(yīng)該以星型結(jié)構(gòu)來進行建模。雖然Kimball對操作數(shù)據(jù)存儲(ODS)的定義和Inmon基本上一樣,但是他對操作數(shù)據(jù)存儲的理解、作用與實現(xiàn)和Inmon有著較大的不同。Kimball認為ODS在兩種情況下是需要的:第一種情況是提供操作型報表,這些報表需要提供面向主題的、集成的數(shù)據(jù),所以操作型的源系統(tǒng)無法提供;這些報表和數(shù)據(jù)倉庫中的報表也不相同,因為它們可以是一些定制好的,寫死在程序中的報表。第二種情況是需要提供實時的信息時,由于數(shù)據(jù)倉庫的更新頻率一般都是24小時,而用戶會有更急切的需求來了解數(shù)據(jù)源的信息,這時,建立操作數(shù)據(jù)存儲是很有必要的。對于ODS是保存最細粒度數(shù)據(jù)的地方的說法,Kimball認為對于最細粒度數(shù)據(jù),即原子數(shù)據(jù)層,應(yīng)該保存在數(shù)據(jù)倉庫中,而且應(yīng)該置于維度框架和總線架構(gòu)中。代理關(guān)鍵字--surrogatekey在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Surrogatekey,中文一般翻譯為“代理關(guān)鍵字”。代理關(guān)鍵字一般是指維度表中使用順序分配的整數(shù)值作為主鍵,也稱為“代理鍵”。代理關(guān)鍵字用于維度表和事實表的連接。代理關(guān)鍵字的稱呼有surrogatekeys,meaninglesskeys,integerkeys,nonnaturalkeys,artificialkeys,synthetickeys等。與之相對的自然關(guān)鍵字的稱呼有naturalkeys,samatkeys等。在Kimball的維度建模領(lǐng)域里,是強烈推薦使用代理關(guān)鍵字的。在維度表和事實表的每一個聯(lián)接中都應(yīng)該使用代理關(guān)鍵字,而不應(yīng)該使用自然關(guān)鍵字或者智能關(guān)鍵字(SmartKeys)。數(shù)據(jù)倉庫中的主鍵不應(yīng)該是智能的,也就是說,要避免通過主鍵的值就可以了解一些業(yè)務(wù)信息。當(dāng)然,退化維度作為事實表的復(fù)合主鍵之一時例外。使用代理關(guān)鍵字,有很多優(yōu)點。1.使用代理關(guān)鍵字能夠使數(shù)據(jù)倉庫環(huán)境對操作型環(huán)境的變化進行緩沖。也就是說,當(dāng)數(shù)據(jù)倉庫需要對來在多個操作型系統(tǒng)的數(shù)據(jù)進行整合時,這些系統(tǒng)中的數(shù)據(jù)有可能缺乏一致的關(guān)鍵字編碼,即有可能出現(xiàn)重復(fù),這時代理關(guān)鍵字可以解決這個問題。2.使用代理關(guān)鍵字可以帶來性能上的優(yōu)勢。和自然關(guān)鍵字相比,代理關(guān)鍵字很小,是整型的,可以減小事實表中記錄的長度。這樣,同樣的IO就可以讀取更多的事實表記錄。另外,整型字段作為外鍵聯(lián)接的效率也很高。3.使用代理關(guān)鍵字可以建立一些不存在的維度記錄,例如“不在促銷之列”,“日期待定”,“日期不可用”等維度記錄。4.使用代理關(guān)鍵字可以用來處理緩慢變化維。維度表數(shù)據(jù)的歷史變化信息的保存是數(shù)據(jù)倉庫設(shè)計的實施中非常重要的一部分。Kimball的緩慢變化維處理策略的核心就是使用代理關(guān)鍵字。當(dāng)然,使用代理關(guān)鍵字也有它的缺點,代理關(guān)鍵字的使用使數(shù)據(jù)加載變得非常復(fù)雜。有關(guān)使用代理關(guān)鍵字的維度表和事實表的加載方法在ETLToolkit中有詳細的描述。使用代理關(guān)鍵字是一個從長遠考慮的策略。多值維度――multivaluedimension在維度建模的數(shù)據(jù)倉庫中,有一種維度表叫multivaluedimension,中文一般翻譯為“多值維度”。多值維度有兩種情況,第一種情況是指維度表中的某個屬性字段同時有多個值。舉例來說,一個帳戶維度表中,帳戶持有人姓名,可能會有多個顧客。這樣,一個帳戶對應(yīng)多個顧客姓名,一個顧客也可以有多個帳戶,它們之間是多對多的關(guān)系。正因為一個帳戶可能會有多個對應(yīng)的顧客,所以不能直接將顧客ID放入帳戶維度表中。而帳戶維度表中的這種情況就叫做多值維度。多值維度的第二種情況是事實表在某個維度表中有多條對應(yīng)記錄。舉例來說,對于一個健康護理單分列項事實表來說,它的粒度是一個健康護理單,但是該護理單卻有可能有多次診斷,即該事實表與診斷維度的是一對多的關(guān)系。這個與事實表粒度不匹配的診斷維度也稱之為多值維度。處理多值維度最好的辦法是降低事實表的粒度。如第二種情況中,將健康護理單分列項事實表的粒度降低到具體的診斷粒度上,這樣就避免了多值維度的出現(xiàn)。這種處理方式也是維度建模的一個原則,即事實表應(yīng)該建立在最細粒度上。這樣的處理,需要對事實表的事實進行分攤。但是有些時候,事實表的粒度是不能降低的,多值維度的出現(xiàn)是無法避免的。如第一種情況中,事實表是月帳戶快照事實表,這張事實表與顧客維度沒有直接的關(guān)系,不能將數(shù)據(jù)粒度進行細分,即使細分的話帳戶余額也很難分攤。這時,可以采用橋接表技術(shù)進行處理。在帳戶維度表和顧客維度表之間建立個帳戶-顧客橋接表。這個橋接表可以解決掉帳戶維度和顧客維度之間的多對多關(guān)系,也解決掉的帳戶維度表的多值維度問題。總之,多值維度是應(yīng)該盡量避免的,它給數(shù)據(jù)處理帶來了很大的麻煩。如果多值維度不能避免的話,應(yīng)該建立橋接表來進行處理。非事實型事實表――factlessfacttable在維度建模的數(shù)據(jù)倉庫中,有一種事實表叫FactlessFactTable,中文一般翻譯為“非事實型事實表”。在事實表中,通常會保存十個左右的維度外鍵和多個度量事實,度量事實是事實表的關(guān)鍵所在。在非事實型事實表中沒有這些度量事實,只有多個維度外鍵。非事實型事實表通常用來跟蹤一些事件或者說明某些活動的范圍。下面舉例來進行說明。第一類非事實型事實表是用來跟蹤事件的事實表。例如:學(xué)生注冊事件,學(xué)校需要對學(xué)生按學(xué)期進行跟蹤。維度表包括學(xué)期維度、課程維度、系維度、學(xué)生維度、注冊專業(yè)維度和取得學(xué)分維度,而事實表是由這些維度的主鍵組成,事實只有注冊數(shù),并且恒為1。這樣的事實表可以回答大量關(guān)于大學(xué)開課注冊方面的問題,主要是回答各種情況下的注冊數(shù)。第二類非事實型事實表是用來說明某些活動范圍的事實表。例如:促銷范圍事實表。通常銷售事實表可以回答如促銷商品的銷售情況,但是對于那些沒有銷售出去的促銷商品沒法回答。這時,通過建立促銷范圍事實表,將商場需要促銷的商品單獨建立事實表保存。然后,通過這個促銷范圍事實表和銷售事實表即可得出哪些促銷商品沒有銷售出去。這樣的促銷范圍事實表只是用來說明促銷活動的范圍,其中沒有任何事實度量。合并事實表--consolidated/mergedfacttable在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫mergedfacttable,或者consolidatedfacttable,中文一般都翻譯為“合并事實表”。合并事實表是將不同事實表的事實合并到同一張事實表的建模方法,合并的事實要保證在相同的粒度。這種建模方法通常被用來橫跨多個業(yè)務(wù)主題域來建立數(shù)據(jù)集市,Kimball將這樣的數(shù)據(jù)集市稱為第二級的數(shù)據(jù)集市。使用合并事實表技術(shù),可以避免性能較差的交叉探察操作。但是,這種合并事實表和使用交叉探察操作還有著細微的不同,在一些基礎(chǔ)表中沒有記錄的時候,合并事實表中可能會存儲一條記錄,字段值保存為零。合并事實表可以給數(shù)據(jù)倉庫帶來很大的性能提升,提供的跨主題的事實數(shù)據(jù)也給用戶帶來了很大的方便。但是,合并事實表給ETL工作帶來了較大的麻煩。對于合并事實表中涉及到的維度,需要在數(shù)據(jù)準(zhǔn)備區(qū)保證它們是一致性維度。緩慢變化維――slowlychangingdimension維度建模的數(shù)據(jù)倉庫中,有一個概念叫SlowlyChangingDimensions,中文一般翻譯成“緩慢變化維”,經(jīng)常被簡寫為SCD。緩慢變化維的提出是因為在現(xiàn)實世界中,維度的屬性并不是靜態(tài)的,它會隨著時間的流失發(fā)生緩慢的變化。這種隨時間發(fā)生變化的維度我們一般稱之為緩慢變化維,并且把處理維度表的歷史變化信息的問題稱為處理緩慢變化維的問題,有時也簡稱為處理SCD的問題。處理緩慢變化維的方法通常分為三種方式。第一種方式是直接覆蓋原值。這樣處理,最容易實現(xiàn),但是沒有保留歷史數(shù)據(jù),無法分析歷史變化信息。第一種方式通常簡稱為“TYPE1”。第二種方式是添加維度行。這樣處理,需要代理鍵的支持。實現(xiàn)方式是當(dāng)有維度屬性發(fā)生變化時,生成一條新的維度記錄,主鍵是新分配的代理鍵,通過自然鍵可以和原維度記錄保持關(guān)聯(lián)。第二種方式通常簡稱為“TYPE2”。第三種方式是添加屬性列。這種處理的實現(xiàn)方式是對于需要分析歷史信息的屬性添加一列,來記錄該屬性變化前的值,而本屬性字段使用TYPE1來直接覆蓋。這種方式的優(yōu)點是可以同時分析當(dāng)前及前一次變化的屬性值,缺點是只保留了最后一次變化信息。第三種方式通常簡稱為“TYPE3”。在實際建模中,我們可以聯(lián)合使用三種方式,也可以對一個維度表中的不同屬性使用不同的方式,這些,都需要根據(jù)實際情況來決定,但目的都是一樣的,就是能夠支持方便的分析歷史變化情況。即席查詢――adhocqueries在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Adhocqueries,中文一般翻譯為“即席查詢”。即席查詢是指那些用戶在使用系統(tǒng)時,根據(jù)自己當(dāng)時的需求定義的查詢。即席查詢生成的方式很多,最常見的就是使用即席查詢工具。一般的數(shù)據(jù)展現(xiàn)工具都會提供即席查詢的功能。通常的方式是,將數(shù)據(jù)倉庫中的維度表和事實表映射到語義層,用戶可以通過語義層選擇表,建立表間的關(guān)聯(lián),最終生成SQL語句。即席查詢與通常查詢從SQL語句上來說,并沒有本質(zhì)的差別。它們之間的差別在于,通常的查詢在系統(tǒng)設(shè)計和實施時是已知的,所有我們可以在系統(tǒng)實施時通過建立索引、分區(qū)等技術(shù)來優(yōu)化這些查詢,使這些查詢的效率很高。而即席查詢是用戶在使用時臨時生產(chǎn)的,系統(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)點。交叉探察――drillacross在維度建模的數(shù)據(jù)倉庫中,有一種操作叫DrillAcross,中文一般翻譯為“交叉探查”。鑒于經(jīng)驗的局限,在這里我只能進行一下淺顯的分析。在基于總線架構(gòu)(BusArchitecture)的維度建模中,大部分的維度表是由事實表共有的。比如“營銷事務(wù)事實表”和“庫存快照事實表”就會有相同的維度表,“日期維度”、“產(chǎn)品維度”和“商場維度”。這時,如果有個需求是想按共有維度來對比查看銷售和庫存的事實,這時就需要發(fā)出兩個SQL,分別查出按維度統(tǒng)計出的銷售數(shù)據(jù)和庫存數(shù)據(jù)。然后再基于共有的維度進行外連接,將數(shù)據(jù)合并。這種發(fā)出多路SQL再進行合并的操作就是交叉探查。當(dāng)這種交叉探查的需求很常用時,有一種建模方法可以避免交叉探查,就是合并事實表(ConsolidatedFactTable)。合并事實表是指將位于不同事實表中處于相同粒度的事實進行組合的一種建模方法。即新建立一個事實表,它的維度是兩個或多個事實表的相同維度的集合,事實是幾個事實表中感興趣的事實。這個事實表的數(shù)據(jù)和其他事實表的數(shù)據(jù)一樣來自StagingArea。合并事實表在性能和易用性上都比交叉探查要好,但是被組合的事實表必須處于相同的粒度和維度層次上。角色模仿維度--role-playingdimensions在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Role-playingdimensions,中文一般翻譯為“角色模仿維度”。角色模仿維度是為了處理一個維度在一個事實表中同時出現(xiàn)多次而使用的一種技術(shù)處理手段。在建立了角色模仿維度以后,在底層只有一個物理表存在,但是針對這個物理表會建立多個角色提供給數(shù)據(jù)訪問工具,而且對數(shù)據(jù)訪問工具來說這多個角色是不同的。例如對與累計快照事實表中會出現(xiàn)多個日期字段聯(lián)接到日期維度。這時就可以針對日期維度建立多個角色模仿維度。角色模仿維度的建立方法通常是使用視圖來完成。例如訂單日期維度表如下所示:CREATEVIEWorder_date(order_date_key,order_day_of_week,order_month,…)ASSELECTdata_key,day_of_week,month,…FROMDATA使用同樣的方式還可以建立多個不同日期的角色模仿維度。需要補充的一點是,目前市場上的大部分展現(xiàn)工具,都提供了對一個表選擇多次的功能。也就是說,角色模仿維度的功能展現(xiàn)工具自己就可以實現(xiàn)。這樣,就不需要我們在數(shù)據(jù)庫中建立角色模仿維度的視圖了,而直接使用展現(xiàn)工具完成即可。聚集事實表--aggregatedfacttable

累計快照事實表--accumulatingsnapshotfacttable

橋接表--bridgetable

切片事實表--slicedfacttable在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫slicedfacttable,中文一般翻譯為“切片事實表”。切片事實表中的字段結(jié)構(gòu)和相應(yīng)的基礎(chǔ)表完全相同,差別在于存儲的記錄的范圍。切片事實表中保存記錄的是相應(yīng)基礎(chǔ)表中記錄的子集,記錄數(shù)通常與某個維度記錄數(shù)相同。這種建模方法一般用來滿足特殊需要,如需要分析某些特殊問題時,可以將與之相關(guān)的數(shù)據(jù)切片出來。相反,這種方法也常用于合并存儲在不同地區(qū)的數(shù)據(jù),即各個地區(qū)都保存自己地區(qū)的數(shù)據(jù),總部和所有地區(qū)的表結(jié)構(gòu)都相同,然后總部將所有地區(qū)的數(shù)據(jù)合并在一起。切片事實表的結(jié)構(gòu)與相對應(yīng)的基礎(chǔ)表相同,數(shù)據(jù)來源于相對應(yīng)的基礎(chǔ)表。切片事實表由于縮小了表中數(shù)據(jù)的記錄數(shù),所以查詢的效率得到了很大的提高。事實表(一)(二)――facttable在維度建模的數(shù)據(jù)倉庫中,事實表是指其中保存了大量業(yè)務(wù)度量數(shù)據(jù)的表。事實表中的度量值一般稱為事實。在事實表中最有用的事實就是數(shù)字類型的事實和可加類型的事實。事實表的粒度決定了數(shù)據(jù)倉庫中數(shù)據(jù)的詳細程度。一般來說,以粒度作為化分依據(jù),主要有三種事實表,分別是事務(wù)粒度事實表(TransactionGrainFactTable),周期快照粒度事實表(PeriodicSnapshotGrainFactTable)和累積快照粒度事實表(AccumulatingSnapshotGrainFactTable)。事務(wù)粒度事實表中的一條記錄代表了業(yè)務(wù)系統(tǒng)中的一個事件。事務(wù)出現(xiàn)以后,就會在事實中出現(xiàn)一條記錄。事務(wù)粒度事實表也稱為原子粒度。典型的例子是銷售單分列項事實表。周期快照粒度事實表用來記錄有規(guī)律的,可預(yù)見時間間隔的業(yè)務(wù)累計數(shù)據(jù)。通常的時間間隔可以是每天、每周或者每月。典型的例子是庫存日快照事實表。累積快照事實表一般用來涵蓋一個事務(wù)的生命周期內(nèi)的不確定的時間跨度。典型的例子是KDT#2中描述的具有多個日期字段的發(fā)貨事實表。通常來說,事務(wù)和快照是建模中的兩個非常重要的特點,將兩者相結(jié)合可以使模型建立的更完整。從用途的不同來說,事實表可以分為三類,分別是原子事實表,聚集事實表和合并事實表。原子事實表(AtomFactTable)是保存最細粒度數(shù)據(jù)的事實表,也是數(shù)據(jù)倉庫中保存原子信息的場所。聚集事實表(AggregatedFactTable)是原子事實表上的匯總數(shù)據(jù),也稱為匯總事實表。即新建立一個事實表,它的維度表是比原維度表要少,或者某些維度表是原維度表的子集,如用月份維度表代替日期維度表;事實數(shù)據(jù)是相應(yīng)事實的匯總,即求和或求平均值等。在做數(shù)據(jù)遷移時,當(dāng)相關(guān)的維度數(shù)據(jù)和事實數(shù)據(jù)發(fā)生變化時,聚集事實表需要做相應(yīng)的刷新。物化視圖是實現(xiàn)聚集事實表的一種有效方式,可以設(shè)定刷新方式,具體功能由DBMS來實現(xiàn)。合并事實表(ConsolidatedFactTable)是指將位于不同事實表中處于相同粒度的事實進行組合建模而成的一種事實表。即新建立一個事實表,它的維度是兩個或多個事實表的相同維度的集合;事實是幾個事實表中感興趣的事實。在Kimball的總線架構(gòu)中,由合并事實表為主組成的合并數(shù)據(jù)集市稱為二級數(shù)據(jù)集市。合并事實表的粒度可以是原子粒度也可以是聚集粒度。在做數(shù)據(jù)遷移時,當(dāng)相關(guān)的原子事實表的數(shù)據(jù)有改變時,合并事實表的數(shù)據(jù)需要重新刷新。合并事實表和交叉探察是兩個互補的操作。聚集事實表和合并事實表的主要差別是合并事實表一般是從多個事實表合并而來。但是它們的差別不是絕對的,一個事實表既是聚集事實表又是合并事實表是很有可能的。因為一般合并事實表需要按相同的維度合并,所以很可能在做合并的同時需要進行聚集,即粒度變粗。事實維度--factdimension

事務(wù)事實表--transactionfacttable

審計維度--auditdimension

數(shù)據(jù)世系――datalineage數(shù)據(jù)倉庫中有一個概念叫做DataLineage,中文一般翻譯為“數(shù)據(jù)世系”。數(shù)據(jù)世系描述的是從源系統(tǒng)抽取數(shù)據(jù)開始,經(jīng)過數(shù)據(jù)轉(zhuǎn)換到最終的數(shù)據(jù)加載的整個過程中各種信息。數(shù)據(jù)世系信息需要留下詳細的文檔記載。數(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工具來維護元數(shù)據(jù)是不夠的。雙桶連接--double-barreledjoins

退化維度――degeneratedimension在維度建模的數(shù)據(jù)倉庫中,有一種維度叫DegenerateDimension,中文一般翻譯為“退化維度”。這種退化維度一般都是事務(wù)的編號,如訂單編號、發(fā)票編號等。這類編號需要保存到事實表中,但是不需要對應(yīng)的維度表,所以稱為退化維度。退化維度是維度建模領(lǐng)域中的一個非常重要的概念,它對理解維度建模有著非常重要的作用,尤其是對維度建模的入門者。退化維度經(jīng)常會和其他一些維度一起組合成事實表的主鍵。在Kimball提出的維度建模中,事實表應(yīng)該保存最細粒度的數(shù)據(jù)。所以對于象銷售單這樣的事實表來說,需要銷售單編號和產(chǎn)品來共同作為主鍵,而不能用銷售日期、商場、產(chǎn)品等用來分析的維度共同作為主鍵。退化維度在分析中可以用來做分組使用。它可以將同一個事務(wù)中銷售的產(chǎn)品集中在一起。微型維度――minidimension維度建模的數(shù)據(jù)倉庫中,有一種維度叫minidimension,中文一般翻譯成“微型維度”。微型維度的提出主要是為了解決快變超大維度(rapidlychangingmonsterdimension)。以客戶維度舉例來說,如果維度表中有數(shù)百萬行記錄或者還要多,而且這些記錄中的字段又經(jīng)常變化,這樣的維度表一般稱之為快變超大維度。對于快變超大維度,設(shè)計人員一般不會使用TYPE2的緩慢變化維處理方法,因為大家都不愿意向本來就有幾百萬行的維度表中添加更多的行。這時,有一項技術(shù)可以解決這個問題。解決的方法是,將分析頻率比較高或者變化頻率比較大的字段提取出來,建立一個單獨的維度表。這個單獨的維度表就是微型維度表。微型維度表有自己的關(guān)鍵字,這個關(guān)鍵字和原客戶維度表的關(guān)鍵字一起進入事實表。有時為了分析的方便,可以把微型維度的關(guān)鍵字的最新值作為外關(guān)鍵字進入客戶維度表。這時一定要注意,這個外關(guān)鍵字必須做TYPE1型處理。在微型維度表中如果有像收入這樣分布范圍較廣的屬性時,應(yīng)該將它分段處理。比如,存儲¥這樣過于分散的數(shù)值就不如存儲¥30000-¥34999這樣的范圍。這樣可以極大的減少微型維度中的記錄數(shù)目,也給分析帶來方便。蜈蚣事實表――centipedefacttable在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫Centipedefacttable,中文一般翻譯為“蜈蚣事實表”。蜈蚣事實表是指那些一張事實表中有太多維度的事實表。連接在事實表兩邊的維度表過多,看起來就像蜈蚣一樣,所以稱為“蜈蚣事實表”。通常來說,蜈蚣事實表的出現(xiàn)是由于建模師對事實表和維度表逆規(guī)范化過了頭。例如,不單將產(chǎn)品主鍵放入事實表中,對于產(chǎn)品層級結(jié)構(gòu)中的每一層的主鍵都放入事實表中,這樣事實表中與產(chǎn)品相關(guān)的就會有產(chǎn)品ID、商標(biāo)ID、子類ID、類別ID等多個外鍵。同樣,也有建模師將日期相關(guān)的日期ID、月ID、年ID都放入事實表中。這些都將產(chǎn)生蜈蚣事實表,使自己落入維度過多的陷阱。蜈蚣事實表雖然使查詢效率有所提高,但是伴之而來的是存儲空間的大量增長。在維度建模的數(shù)據(jù)倉庫中,維度表的字段個數(shù)可以盡可能的增加,但是事實表的字段要盡量減少,因為相比而言,事實表的記錄數(shù)要遠遠大于維度表的記錄數(shù)。一般來說,事實表相關(guān)的維度在15個以下為正常,如果維度個數(shù)超過25個,就出現(xiàn)了維度過多的蜈蚣事實表。這時,需要做的事情是自己核查,將相關(guān)的維度進行合并,減少維度的個數(shù)。稀疏事實表--sparsefacts

旋轉(zhuǎn)事實表--pivotedfacttable在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫pivotedfacttable,中文一般翻譯為“旋轉(zhuǎn)事實表”。旋轉(zhuǎn)事實表是將一條記錄中的多個事實字段轉(zhuǎn)化為多條記錄,其中每條記錄保存一個事實字段的一種建模方法?;蛘叻催^來,也可以由多條記錄轉(zhuǎn)化為一條記錄。旋轉(zhuǎn)事實表建模方法的使用通常是為了簡化前端數(shù)據(jù)展現(xiàn)的查詢。它通過改變后端的事實記錄存儲方式,使相應(yīng)的查詢需求的性能得到的極大的提高。如果在SQL或者查詢工具中進行這種轉(zhuǎn)換會非常麻煩,效率也很差。和合并事實表類似,有時當(dāng)基礎(chǔ)表中沒有記錄時,旋轉(zhuǎn)事實表也要存儲一些零值在里面。一致性事實――comformedfact維度建模的數(shù)據(jù)倉庫中,有一個概念叫ConformedFact,中文一般翻譯為“一致性事實”。一致性事實是Kimball的多維體系結(jié)構(gòu)(MD)中的三個關(guān)鍵性概念之一,另兩個是總線架構(gòu)(BusArchitecture)和一致性維度(ConformedDimension)。在建立多個數(shù)據(jù)集市時,完成一致性維度的工作就已經(jīng)完成了一致性的80%-90%的工作量。余下的工作就是建立一致性事實。一致性事實和一致性維度有些不同,一致性維度是由專人維護在后臺(BackRoom),發(fā)生修改時同步復(fù)制到每個數(shù)據(jù)集市,而事實表一般不會在多個數(shù)據(jù)集市間復(fù)制。需要查詢多個數(shù)據(jù)集市中的事實時,一般通過交叉探查(drillacross)來實現(xiàn)。為了能在多個數(shù)據(jù)集市間進行交叉探查,一致性事實主要需要保證兩點。第一個是KPI的定義及計算方法要一致,第二個是事實的單位要一致性。如果業(yè)務(wù)要求或事實上就不能保持一致的話,建議不同單位的事實分開建立字段保存。這樣,一致性維度將多個數(shù)據(jù)集市結(jié)合在一起,一致性事實保證不同數(shù)據(jù)集市間的事實數(shù)據(jù)可以交叉探查,一個分布式的數(shù)據(jù)倉庫就建成了。一致性維度――comformeddimension維度建模的數(shù)據(jù)倉庫中,有一個概念叫ConformedDimension,中文一般翻譯為“一致性維度”。一致性維度是Kimball的多維體系結(jié)構(gòu)(MD)中的三個關(guān)鍵性概念之一,另兩個是總線架構(gòu)(BusArchitecture)和一致性事實(ConformedFact)。在多維體系結(jié)構(gòu)中,沒有物理上的數(shù)據(jù)倉庫,由物理上的數(shù)據(jù)集市組合成邏輯上的數(shù)據(jù)倉庫。而且數(shù)據(jù)集市的建立是可以逐步完成的,最終組合在一起,成為一個數(shù)據(jù)倉庫。如果分步建立數(shù)據(jù)集市的過程出現(xiàn)了問題,數(shù)據(jù)集市就會變成孤立的集市,不能組合成數(shù)據(jù)倉庫,而一致性維度的提出正式為了解決這個問題。一致性維度的范圍是總線架構(gòu)中的維度,即可能會在多個數(shù)據(jù)集市中都存在的維度,這個范圍的選取需要架構(gòu)師來決定。一致性維度的內(nèi)容和普通維度并沒有本質(zhì)上區(qū)別,都是經(jīng)過數(shù)據(jù)清洗和整合后的結(jié)果。一致性維度建立的地點是多維體系結(jié)構(gòu)的后臺(BackRoom),即數(shù)據(jù)準(zhǔn)備區(qū)。在多維體系結(jié)構(gòu)的數(shù)據(jù)倉庫項目組內(nèi)需要有專門的維度設(shè)計師,他的職責(zé)就是建立維度和維護維度的一致性。在后臺建立好的維度同步復(fù)制到各個數(shù)據(jù)集市。這樣所有數(shù)據(jù)集市的這部分維度都是完全相同的。建立新的數(shù)據(jù)集市時,需要在后臺進行一致性維度處理,根據(jù)情況來決定是否新增和修改一致性維度,然后同步復(fù)制到各個數(shù)據(jù)集市。這是不同數(shù)據(jù)集市維度保持一致的要點。在同一個集市內(nèi),一致性維度的意思是兩個維度如果有關(guān)系,要么就是完全一樣的,要么就是一個維度在數(shù)學(xué)意義上是另一個維度的子集。例如,如果建立月維度話,月維度的各種描述必須與日期維度中的完全一致,最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集,在后續(xù)鉆取等操作時可以保持一致。如果維度表中的數(shù)據(jù)量較大,出于效率的考慮,應(yīng)該建立物化視圖或者實際的物理表。這樣,維度保持一致后,事實就可以保存在各個數(shù)據(jù)集市中。雖然在物理上是獨立的,但在邏輯上由一致性維度使所有的數(shù)據(jù)集市是聯(lián)系在一起,隨時可以進行交叉探察等操作,也就組成了數(shù)據(jù)倉庫。因果維度--casualdimension

預(yù)連接聚集表――pre-joinedaggregatetable在數(shù)據(jù)倉庫領(lǐng)域有一個概念叫pre-joinedaggregagtetable,中文一般翻譯為“預(yù)連接聚集表”。預(yù)連接聚集表是通過對事實表和維度表的聯(lián)合查詢而生成的一類匯總表。在預(yù)連接聚集表中,保存有維度表中的描述信息和事實表的事實值。通過預(yù)連接,可以避免在用戶查詢時RDBMS的連接操作,所以預(yù)連接聚集表的查詢效率要高很多。典型的預(yù)連接聚集表如下例所示的銷售事實表,產(chǎn)品名稱商標(biāo)名稱年份<FONTfa這是兩年前在找工作時自己總結(jié)的一些數(shù)據(jù)倉庫的基本概念什么叫數(shù)據(jù)倉庫?數(shù)據(jù)倉庫是一個面向主題的(SubjectOriented)、集成的(Integrate)、相對穩(wěn)定的(Non-Volatile)、反映歷史變化(TimeVariant)的數(shù)據(jù)集合,它用于支持企業(yè)或組織的決策分析處理。數(shù)據(jù)倉庫是為了便于多維分析和多角度展現(xiàn)而將數(shù)據(jù)按特定的模式進行存儲所建立起來的關(guān)系型數(shù)據(jù)庫,它的數(shù)據(jù)基于OLTP源系統(tǒng)。首先,用于支持決策,面向分析型數(shù)據(jù)處理,它不同于企業(yè)現(xiàn)有的操作型數(shù)據(jù)庫;其次,對多個異構(gòu)的數(shù)據(jù)源有效集成,集成后按照主題進行了重組,并包含歷史數(shù)據(jù),而且存放在數(shù)據(jù)倉庫中的數(shù)據(jù)一般不再修改

數(shù)據(jù)倉庫的基本架構(gòu)是什么?(數(shù)據(jù)源,ETL,datastage,ODS,datawarehouse,datamart,OLAP等等)數(shù)據(jù)倉庫系統(tǒng)體系結(jié)構(gòu)1.數(shù)據(jù)源->->3.數(shù)據(jù)倉庫存儲與管理->->工具

數(shù)據(jù)源:是數(shù)據(jù)倉庫系統(tǒng)的數(shù)據(jù)源泉,通常包括企業(yè)各類信息,包括存放于RDBMS中的各種業(yè)務(wù)處理數(shù)據(jù)和各類文檔數(shù)據(jù);各類法律法規(guī)、市場信息和競爭對手的信息等等;

數(shù)據(jù)的存儲與管理:數(shù)據(jù)的存儲和管理是整個數(shù)據(jù)倉庫的核心,是關(guān)鍵。數(shù)據(jù)倉庫的組織管理方式?jīng)Q定了它有別于傳統(tǒng)數(shù)據(jù)庫,同時也決定了其對外部數(shù)據(jù)的表現(xiàn)形式。從數(shù)據(jù)倉庫的技術(shù)特點著手分析,來決定采用什么產(chǎn)品和技術(shù)來建立數(shù)據(jù)倉庫,然后針對現(xiàn)有各業(yè)務(wù)系統(tǒng)的數(shù)據(jù),進行抽取、清理,并有效集成,按照主題進行組織。數(shù)據(jù)倉庫按照數(shù)據(jù)的覆蓋范圍可以分為企業(yè)級數(shù)據(jù)倉庫和部門級數(shù)據(jù)倉庫(通常稱為數(shù)據(jù)集市)。

OLAP服務(wù)器:對需要的數(shù)據(jù)進行有效集成,按多維模型予以組織,以便進行多角度、多層次的分析,并發(fā)現(xiàn)趨勢。其具體實現(xiàn)可以分為:ROLAP(關(guān)系型在線分析處理)、MOLAP(多維在線分析處理)和HOLAP(混合型線上分析處理)。ROLAP基本數(shù)據(jù)和聚合數(shù)據(jù)均存放在RDBMS之中;MOLAP基本數(shù)據(jù)和聚合數(shù)據(jù)均存放于多維數(shù)據(jù)庫中;HOLAP基本數(shù)據(jù)存放于RDBMS之中,聚合數(shù)據(jù)存放于多維數(shù)據(jù)庫中。

前端工具:主要包括各查詢工具、數(shù)據(jù)分析工具、數(shù)據(jù)挖掘工具、種報表工具以及各種基于數(shù)據(jù)倉庫或數(shù)據(jù)集市的應(yīng)用開發(fā)工具。數(shù)據(jù)分析工具主要針對OLAP服務(wù)器。報表工具、數(shù)據(jù)挖掘工具主要針對數(shù)據(jù)倉庫。

數(shù)據(jù)庫和數(shù)據(jù)倉庫有什么區(qū)別?1.數(shù)據(jù)是面向事務(wù)處的,數(shù)據(jù)是由日常的業(yè)務(wù)產(chǎn)生的,常更新;數(shù)據(jù)倉庫是面向主題的,數(shù)據(jù)來源于數(shù)據(jù)庫或文件,經(jīng)過一定的規(guī)則轉(zhuǎn)換得到,用來分析的。2.數(shù)據(jù)庫一般是用來存儲當(dāng)前交易數(shù)據(jù),數(shù)據(jù)倉庫存儲一般存儲的是歷史數(shù)據(jù)。3.數(shù)據(jù)庫的設(shè)計一般是符合三范式的,有最大的精確度和最小的冗余度,有利于數(shù)據(jù)的插入;.數(shù)據(jù)倉庫的設(shè)計一般是星型的,有利于查詢。<!--[if!supportLineBreakNewLine]--><!--[endif]-->

構(gòu)建企業(yè)級數(shù)據(jù)倉庫五步法:<!--[if!supportLists]-->一、<!--[endif]-->確定主題即確定數(shù)據(jù)分析或前端展現(xiàn)的主題(例:某年某月某地區(qū)的啤酒銷售情況)。主題要體現(xiàn)出某一方面的各分析角度(維度)和統(tǒng)計數(shù)值型數(shù)據(jù)(量度)之間的關(guān)系,確定主題時要綜合考慮.<!--[if!supportLists]-->二、<!--[endif]-->確定量度確定主題后,需要考慮分析的技術(shù)指標(biāo)(例:年銷售額等等)。它們一般為數(shù)據(jù)值型數(shù)據(jù),其中有些度量值不可以匯總;些可以匯總起來,以便為分析者提供有用的信息。量度是要統(tǒng)計的指標(biāo),必須事先選擇恰當(dāng),基于不同的量度可以進行復(fù)雜關(guān)鍵性指標(biāo)(KPI)的設(shè)計和計算。<!--[if!supportLists]-->三、<!--[endif]-->確定事實數(shù)據(jù)粒度確定量度之后,需要考慮該量度的匯總情況和不同維度下量度的聚合情況.例如在業(yè)務(wù)系統(tǒng)中數(shù)據(jù)最小記錄到秒,而在將來分析需求中,時間只要精確到天就可以了,在ETL處理過程中,按天來匯總數(shù)據(jù),些時數(shù)據(jù)倉庫中量度的粒度就是”天”。如果不能確認將來的分析需求中是否要精確的秒,那么,我們要遵循”最小粒度原則”,在數(shù)據(jù)倉庫中的事實表中保留每一秒的數(shù)據(jù),從而在后續(xù)建立多維分析模型(CUBE)的時候,會對數(shù)據(jù)提前進行匯總,保障產(chǎn)生分析結(jié)果的效率。<!--[if!supportLists]-->四、<!--[endif]-->確定維度維度是分析的各個角度.例:我們希望按照時間,或者按照地區(qū),或者按照產(chǎn)品進行分析。那么這里的時間,地區(qū),產(chǎn)品就是相應(yīng)的維度。基于不同的維度,可以看到各個量度匯總的情況,也可以基于所有的維度進行交叉分析。維度的層次(Hierarchy)和級別(Level)。例:在時間維度上,按照”度-季度-月”形成了一個層次,其中”年”,”季度”,”月”成為了這個層次的3個級別。我們可以將“產(chǎn)品大類-產(chǎn)品子類-產(chǎn)品”劃為一個層次,其中包含“產(chǎn)品大類”、“產(chǎn)品子類”、“產(chǎn)品”三個級別。我們可以將3個級別設(shè)置成一張數(shù)據(jù)表中的3個字段,比如時間維度;我們也可以使用三張表,分別保存產(chǎn)品大類,產(chǎn)品子類,產(chǎn)品三部分數(shù)據(jù),比如產(chǎn)品維度。建立維度表時要充分使用代理鍵.代理鍵是數(shù)據(jù)值型的ID號碼(每張表的第一個字段),它唯一標(biāo)識了第一維度成員。在聚合時,數(shù)值型字段的匹配和比較,join效率高。同時代理鍵在緩慢變化維中,起到了對新數(shù)據(jù)與歷史數(shù)據(jù)的標(biāo)識作用。<!--[if!supportLists]-->五、<!--[endif]-->創(chuàng)建事實表在確定好事實數(shù)據(jù)和維度后,將考慮加載事實表。業(yè)務(wù)系統(tǒng)的的一筆筆生產(chǎn),交易記錄就是將要建立的事實表的原始數(shù)據(jù).我們的做法是將原始表與維度表進行關(guān)聯(lián),生成事實表。關(guān)聯(lián)時有為空的數(shù)據(jù)時(數(shù)據(jù)源臟),需要使用外連接,連接后將各維度的代理鍵取出放于事實表中,事實表除了各維度代理鍵外,還有各度量數(shù)據(jù),不應(yīng)該存在描述性信息。事實表中的記錄條數(shù)據(jù)都比較多,要為其設(shè)置復(fù)合主鍵各蛇引,以實現(xiàn)數(shù)據(jù)的完整性和基于數(shù)據(jù)倉庫的查詢性能優(yōu)化。 元數(shù)據(jù):描述數(shù)據(jù)及其環(huán)境的數(shù)據(jù)。兩方面用途:首先,元數(shù)據(jù)能提供基于用戶的信息,如記錄數(shù)據(jù)項的業(yè)務(wù)描述信息的元數(shù)據(jù)能幫助用戶使用數(shù)據(jù)。其次,元數(shù)據(jù)能支持系統(tǒng)對數(shù)據(jù)的管理和維護,如關(guān)于數(shù)據(jù)項存儲方法的元數(shù)據(jù)能支持系統(tǒng)以最有效的方式訪問數(shù)據(jù)。元數(shù)據(jù)機制主要支持以下五類系統(tǒng)管理功能:(1)描述哪些數(shù)據(jù)在數(shù)據(jù)倉庫中;(2)定義要進入數(shù)據(jù)倉庫中的數(shù)據(jù)和從數(shù)據(jù)倉庫中產(chǎn)生的數(shù)據(jù);(3)記錄根據(jù)業(yè)務(wù)事件發(fā)生而隨之進行的數(shù)據(jù)抽取工作時間安排;(4)記錄并檢測系統(tǒng)數(shù)據(jù)一致性的要求和執(zhí)行情況;(5)衡量數(shù)據(jù)質(zhì)量。

ODS:OperationalDataStoreODS為企業(yè)提供即時的,操作型的,集成的數(shù)據(jù)集合,具有面向主題性,集成性,動態(tài)性,即時性,明細性等特點ODS作為數(shù)據(jù)庫到數(shù)據(jù)倉庫的一種過渡形式,與數(shù)據(jù)倉庫在物理結(jié)構(gòu)上不同,能提供高性能的響應(yīng)時間,ODS設(shè)計采用混合設(shè)計方式。ODS中的數(shù)據(jù)是"實時值",而數(shù)據(jù)倉庫的數(shù)據(jù)卻是"歷史值",一般ODS中儲存的數(shù)據(jù)不超過一個月,而數(shù)據(jù)倉庫為10年或更多.

DataMart為了特定的應(yīng)用目的或應(yīng)用范圍,而從數(shù)據(jù)倉庫中獨立出來的一部分數(shù)據(jù),也可稱為部門數(shù)據(jù)或主題數(shù)據(jù)(subjectarea)。在數(shù)據(jù)倉庫的實施過程中往往可以從一個部門的數(shù)據(jù)集市著手,以后再用幾個數(shù)據(jù)集市組成一個完整的數(shù)據(jù)倉庫。需要注意的就是在實施不同的數(shù)據(jù)集市時,同一含義的字段定義一定要相容,這樣再以后實施數(shù)據(jù)倉庫時才不會造成大麻煩。

DDS(decision-supportsystem)決策支持系統(tǒng):用于支持管理決策的系統(tǒng)。通常,DSS包括以啟發(fā)的方式對大量的數(shù)據(jù)單元進行的分析,通常不涉及數(shù)據(jù)更新。

三.什么叫OLAP用途是什么聯(lián)機分析處理,On-LineAnalysisProcessing即從數(shù)據(jù)倉庫中抽取詳細數(shù)據(jù)的一個子集并經(jīng)過必要的聚集,存儲到OLAP存儲器中供前端分析工具讀取。OLAP系統(tǒng)按照數(shù)據(jù)存儲格式可以分為關(guān)系OLAP(RelationalOLAP,簡稱ROLAP)、多維OLAP(MultidimensionalOLAP,簡稱MOLAP)和混合型OLAP(HybridOLAP,簡稱HOLAP)三種類型。ROLAP將分析要用的多維數(shù)據(jù)存儲在關(guān)系數(shù)據(jù)庫中,并根據(jù)應(yīng)用的需要有選擇的定義一批實視圖也存儲在關(guān)系數(shù)據(jù)庫中MOLAP將OLAP分析所要用到的多維數(shù)據(jù)物理上存儲為多維數(shù)組的形式,形成“立方體”的結(jié)構(gòu)。HOLAP能把MOLAP和ROLAP兩種結(jié)構(gòu)的優(yōu)點有機的結(jié)合起來,能滿足用戶各種復(fù)雜的分析請求。

OLTP與OLAP的區(qū)別OLTPOLAP用戶操作人員決策人員功能日常操作分析決策DB設(shè)計面積應(yīng)用面向主題數(shù)據(jù)當(dāng)前的,最新的,細節(jié)的,二維的歷史的,概括的,多維集成的,統(tǒng)一的存取及規(guī)模讀取少大規(guī)模讀

事實表事實表是包含大量數(shù)據(jù)值的一種結(jié)構(gòu)。事實數(shù)據(jù)表可能代表某次銀行交易,包含一個顧客的來訪次數(shù),并且這些數(shù)字信息可以匯總,以提供給有關(guān)單位作為歷史的數(shù)據(jù)。每個數(shù)據(jù)倉庫都包含一個或者多個事實數(shù)據(jù)表。事實數(shù)據(jù)表只能包含數(shù)字度量字段和使事實表與維度表中對應(yīng)項的相關(guān)索引字段.,該索引包含作為外鍵的所有相關(guān)性維度表的主鍵。事實數(shù)據(jù)表中的“度量值”有兩中:一種是可以累計的度量值,另一種是非累計的度量值。用戶可以通過累計度量值獲得匯總信息。

維度表用來描述事實表的某個重要方面,維度表中包含事實表中事實記錄的特性:有些特性提供描述性信息,有些特性指定如何匯總事實數(shù)據(jù)表數(shù)據(jù),以便為分析者提供有用的信息,維度表包含幫助匯總數(shù)據(jù)的特性的層次結(jié)構(gòu)

緩慢變化維:在實際情況下,維度的屬性并不是靜態(tài)的,它會隨著時間的流失發(fā)生緩慢的變化。處理方法:1新信息直接覆蓋舊信息,2,保存多條記錄,并添加字段加以區(qū)分(用y,n;0,1,2或用時間來區(qū)別新舊記錄)3.保存多條記錄,并添加字段加以區(qū)分4.另外建表保存歷史記錄.5混合模式

退化維般來說事實表中的外鍵都對應(yīng)一個維表,維的信息主要存放在維表中。但是退化維僅僅是事實表中的一列,這個維的相關(guān)信息都在這一列中,沒有維表與之相關(guān)聯(lián)。比如:發(fā)票號,序列號等等。

那么退化維有什么作用呢?

1、退化維具有普通維的各種操作,比如:上卷,切片,切塊等(上卷匯總,下鉆明細;切片,切塊:對二維數(shù)據(jù)進行切片,三維數(shù)據(jù)進行切塊,,可得到所需要的數(shù)據(jù))

2、如果存在退化維,那么在ETL的過程將會變得容易。

3、它可以讓groupby等操作變得更快粒度:(granularity)是指數(shù)據(jù)倉庫的數(shù)據(jù)單位中保存數(shù)據(jù)的細化或綜合程度的級別,細化程度越高,粒度就越小。

鉆取:首先從某一個匯總數(shù)據(jù)出發(fā),查看組成該數(shù)據(jù)的各個成員數(shù)據(jù)。

KPI(KeyPerformanceIndication)關(guān)鍵業(yè)績指標(biāo)用來衡量業(yè)績好壞比如銷售這個主題,銷售增長率、銷售凈利潤就是一個KPI

ETLextract/transformation/load尋找數(shù)據(jù),整合數(shù)據(jù),并將它們裝入數(shù)據(jù)倉庫的過程。ETL是將業(yè)務(wù)系統(tǒng)的數(shù)據(jù)經(jīng)過抽取、清洗轉(zhuǎn)換之后加載到數(shù)據(jù)倉庫的過程,目的是將企業(yè)中的分散、零亂、標(biāo)準(zhǔn)不統(tǒng)一的數(shù)據(jù)整合到一起,為企業(yè)的決策提供分析的依據(jù)。工作流抽取清洗,轉(zhuǎn)換加載數(shù)據(jù)流業(yè)務(wù)系統(tǒng)ODS數(shù)據(jù)倉庫一.抽取方法有三種:1.利用工具,例如datastage,informatic,OWB,DTS,SISS.2,利用存儲過程.3,前兩種工具結(jié)合.抽取前的調(diào)研準(zhǔn)備工作:1.弄清數(shù)據(jù)是從哪幾個

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論