2022計算機等考三級數(shù)據(jù)庫基礎(chǔ)創(chuàng)新性應(yīng)用數(shù)據(jù)建模經(jīng)驗談

本文格式為Word版，下載可任意編輯——2022計算機等考三級數(shù)據(jù)庫基礎(chǔ)創(chuàng)新性應(yīng)用數(shù)據(jù)建模經(jīng)驗談計算機等級網(wǎng)權(quán)威發(fā)布2022計算機等考三級數(shù)據(jù)庫根基：創(chuàng)新性應(yīng)用數(shù)據(jù)建模閱歷談，更多2022計算機等考三級數(shù)據(jù)庫根基相關(guān)信息請訪問計算機等級考試網(wǎng)。筆者從98年進入數(shù)據(jù)庫及數(shù)據(jù)倉庫領(lǐng)域工作至今已經(jīng)有近八年的時間，對數(shù)據(jù)建模工作接觸的對比多，創(chuàng)新性不敢談，本文只是將工作中的閱歷總結(jié)出來，供大家一同探討和指正。提起數(shù)據(jù)建模來，有一點是首先要強調(diào)的，數(shù)據(jù)建模師和DBA有著較大的不同，對數(shù)據(jù)建模師來說，對業(yè)務(wù)的深刻理解是第一位的，不同的建模方法和技巧是為業(yè)務(wù)需求來服務(wù)的。而本文那么暫時拋開業(yè)務(wù)不談，主要關(guān)注于建模方法和技巧的閱歷總結(jié)。從目前的數(shù)據(jù)庫及數(shù)據(jù)倉庫建模方法來說，主要分為四類。第一類是大家最為熟諳的關(guān)系數(shù)據(jù)庫的三范式建模，通常我們將三范式建模方法用于建立各種操作型數(shù)據(jù)庫系統(tǒng)。其次類是Inmon提倡的三范式數(shù)據(jù)倉庫建模，它和操作型數(shù)據(jù)庫系統(tǒng)的三范式建模在側(cè)重點上有些不同。Inmon的數(shù)據(jù)倉庫建模方法分為三層，第一層是實體關(guān)系層，也即企業(yè)的業(yè)務(wù)數(shù)據(jù)模型層，在這一層上和企業(yè)的操作型數(shù)據(jù)庫系統(tǒng)建模方法是一致的；其次層是數(shù)據(jù)項集層，在這一層的建模方法根據(jù)數(shù)據(jù)的產(chǎn)生頻率及訪問頻率等因素與企業(yè)的操作型數(shù)據(jù)庫系統(tǒng)的建模方法產(chǎn)生了不同；第三層物理層是其次層的概括實現(xiàn)。第三類是Kimball提倡的數(shù)據(jù)倉庫的維度建模，我們一般也稱之為星型布局建模，有時也參與一些雪花模型在里面。維度建模是一種面向用戶需求的、輕易理解的、訪問效率高的建模方法，也是筆者對比熱愛的一種建模方式。第四類是更為生動的一種建模方式，通常用于后臺的數(shù)據(jù)打定區(qū)，建模的方式不拘一格，以能得志需要為目的，建好的表不對用戶供給接口，多為臨時表。下面簡樸談?wù)劦谒念惤７椒ǖ囊恍┑拈啔v。數(shù)據(jù)打定區(qū)有一個最大的特點，就是不會直接面對用戶，所以對數(shù)據(jù)打定區(qū)中的表舉行操作的人只有ETL工程師。ETL工程師可以自己來抉擇表中數(shù)據(jù)的范圍和數(shù)據(jù)的生命周期。下面舉兩個例子：1）數(shù)據(jù)范圍小的臨時表當(dāng)需要整合或清洗的數(shù)據(jù)量過大時，我們可以建立同樣布局的臨時表，在臨時表中只留存我們需要處理的片面數(shù)據(jù)。這樣，不管是更新還是對表中某些項的計算都會效率提高好多。處理好的數(shù)據(jù)發(fā)送入打定加載到數(shù)據(jù)倉庫中的表中，結(jié)果一次性加載入數(shù)據(jù)倉庫。2）帶有冗余字段的臨時表由于數(shù)據(jù)打定區(qū)中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承受風(fēng)險。舉例來說，筆者在工程中曾遇到這樣的需求，客戶表{客戶ID，客戶凈扣值}，債項表{債項ID，客戶ID，債項余額，債項凈扣值}，即客戶和債項是一對多的關(guān)系。其中，客戶凈扣值和債項余額已知，需要計算債項凈扣值。計算的規(guī)矩是按債項余額的比例調(diào)配客戶的凈扣值。這時，我們可以給兩個表增加幾個冗余字段，如客戶表{客戶ID，客戶凈扣值，客戶余額}，債項表{債項ID，客戶ID，債項余額，債項凈扣值，客戶余額，客戶凈扣值}。這樣通過三條SQL就可以直接完成整個計算過程。將債項余額匯總到客戶余額，將客戶余額和客戶凈扣值冗余到債項表中，在債項表中通過（債項余額×客戶凈扣值/客戶余額）公式即可直接計算處債項凈扣值。另外還有好多大家可以發(fā)揮的建表方式，如不需要主鍵的臨時表等等?？偨Y(jié)來說，正由于數(shù)據(jù)打定區(qū)是不對用戶供給接口的，所以我們確定要利用好這一點，以給我們的數(shù)據(jù)處理工作帶來最大的便利為目的來舉行數(shù)據(jù)打定區(qū)的表設(shè)計。行業(yè)借鑒閱歷：數(shù)據(jù)倉庫架構(gòu)閱歷談對于數(shù)據(jù)倉庫的架構(gòu)方法，不同的架構(gòu)師有不同的原那么和方法，筆者在這里來總結(jié)一下當(dāng)前常采用的架構(gòu)方式及其優(yōu)缺點。這些架構(gòu)方式不限于某個行業(yè)，可以供各個行業(yè)借鑒使用。首先需要說明的一點是，目前在數(shù)據(jù)倉庫領(lǐng)域?qū)Ρ纫恢碌挠^法是在數(shù)據(jù)倉庫中需要留存企業(yè)范圍內(nèi)一致的原子層數(shù)據(jù)。而獨立的數(shù)據(jù)集市架構(gòu)（Independentdatamarts）沒有企業(yè)范圍內(nèi)一致的數(shù)據(jù)，很可能會導(dǎo)致信息孤島的產(chǎn)生，除非在很小的企業(yè)內(nèi)或只針對固定主題，否那么不建議建立這樣的架構(gòu)方式。聯(lián)邦式的數(shù)據(jù)倉庫架構(gòu)（FederatedDataWarehouseArchitecture）不管是在地域上的聯(lián)邦還是功能上的聯(lián)邦都需要先在不同平臺上建立各自的數(shù)據(jù)倉庫，再通過參考（reference）數(shù)據(jù)來實現(xiàn)整合，而這樣很輕易造成整合的不徹底，除非聯(lián)邦式的數(shù)據(jù)倉庫架構(gòu)也采用Kimball的總線架構(gòu)（BusArchitecture）中類似的功能，即在數(shù)據(jù)打定區(qū)留存一致性維度（ConformedTable）并不斷更新它。所以，這兩種架構(gòu)方式不在議論范圍之內(nèi)。下面主要議論剩下的三種架構(gòu)方式。1）三范式（3NF）的原子層＋數(shù)據(jù)集市這樣的數(shù)據(jù)倉庫架構(gòu)最大的倡導(dǎo)者就是數(shù)據(jù)倉庫之父Inmon，而他的企業(yè)信息工廠（CorporateInformationSystem）就是典型的代表。這樣的架構(gòu)也稱之為企業(yè)數(shù)據(jù)倉庫（EnterpriseDataWarehouse，EDW）。企業(yè)信息工廠的實現(xiàn)方式是，首先舉行全企業(yè)的數(shù)據(jù)整合，建立企業(yè)信息模型，即EDW。對于各種分析需求再建立相應(yīng)的數(shù)據(jù)集市或者探索倉庫，其數(shù)據(jù)來源于EDW。三范式的原子層給建立OLAP帶來確定的繁雜性，但是對于建立更繁雜的應(yīng)用，如挖掘倉庫、探索倉庫供給了更好的支持。這類架構(gòu)的創(chuàng)辦周期對比長，相應(yīng)的本金也對比高。2）星型布局（StarSchema）的原子層＋HOLAP星型布局最大的倡導(dǎo)者是Kimall，他的總線架構(gòu)是該類架構(gòu)的典型代表?？偩€架構(gòu)實現(xiàn)方式是，首先在數(shù)據(jù)打定區(qū)中建立一致性維度、建立一致性事實的計算方法；其次在一致性維度、一致性事實的根基上逐步建立數(shù)據(jù)集市。每次增加數(shù)據(jù)集市，都會在數(shù)據(jù)打定區(qū)整合一致性維度，并將整合好的一致性維度同步更新到全體的數(shù)據(jù)集市。這樣，建立的全體數(shù)據(jù)集市合在一起就是一個整合好的數(shù)據(jù)倉庫。正是由于總線架構(gòu)這個可以逐步建立的特點，它的開發(fā)周期比其他架構(gòu)方式的開發(fā)周期要短，相應(yīng)的本金也要低。在星型布局的原子層上可以直接建立聚集，也可以建立HOLAP。筆者對比傾向于Kimball的星型布局的原子層架構(gòu)，在這種架構(gòu)中的閱歷也對比多。3）三范式（3NF）的原子層＋ROLAP這樣的數(shù)據(jù)倉庫架構(gòu)也稱為集中式架構(gòu)（CentralizedArchitecture），思路是在三范式的原子層上直接建立ROLAP，做的對比卓越的就是MicroStrategy。在三范式的原子層上定義ROLAP比在星型布局的原子層上定義ROLAP要繁雜好多。采用這種架構(gòu)需要在定義ROLAP是多下些功夫，而且ROLAP的元數(shù)據(jù)不確定是通用的格式，所以對ROLAP做呈現(xiàn)很可能會受到工具的局限。這類架構(gòu)和第一類很好像，只是少了原子層上的數(shù)據(jù)集市。總結(jié)來說，這三種數(shù)據(jù)倉庫的架構(gòu)方式都是不錯的選擇。對于需要見效快、本金低的工程可以考慮采用其次種總線架構(gòu)，對于資金充沛并有成熟業(yè)務(wù)數(shù)據(jù)模型的企業(yè)可以考慮采用第一種架構(gòu)或第三種架構(gòu)。應(yīng)用難點技巧：變化數(shù)據(jù)捕獲閱歷談在數(shù)據(jù)倉庫系統(tǒng)中，一個很重要的目的就是留存數(shù)據(jù)的歷史變化信息。而變化數(shù)據(jù)捕獲（ChangeDataCapture，CDC）就是為這個目的而產(chǎn)生的一項技術(shù)。變化數(shù)據(jù)捕獲常用的方法有：1）文件或者表的全掃描比較，2）DBMS日志獲取，3）在源系統(tǒng)中增加觸發(fā)器獲取，4）基于源系統(tǒng)的時間戳獲取，5）基于復(fù)制技術(shù)的獲取，6）DBMS供給的變化數(shù)據(jù)捕獲方法等。其中，由DBMS供給變化數(shù)據(jù)捕獲的方法是大勢所趨，即概括的捕獲過程由DBMS來完成。像銀行、電信等好多行業(yè)的操作記錄生成后就不會變更，只有像客戶、產(chǎn)品等信息會隨時間發(fā)生緩慢的變化，所以通常的變化數(shù)據(jù)捕獲是針對維度表而言的。Kimball對緩慢變化維的分析及應(yīng)對策略根本上可以處理維度表的各種變化。而對于一些零售行業(yè)，像合同表中的合同金額類似的數(shù)值在錄入后是有可能會發(fā)生變更的，也就是說事實表的數(shù)據(jù)也有可能發(fā)生變化。通常對于事實表數(shù)據(jù)的修改屬于校正的范疇，可以采用類似緩慢變化維TYPE1的處理方式直接更新事實表。筆者不太贊同對事實表的變化采用快照的方式插入一條新的事實校正記錄，這樣會給后續(xù)的呈現(xiàn)、分析程序帶來太多的麻煩。接下來要議論的是筆者曾經(jīng)遇到的一個頗為難辦的事實表數(shù)據(jù)變更的問題，該事實表的主鍵隨表中某些數(shù)據(jù)的變化發(fā)生變更。以其中的一個合同表為例，該合同表的主鍵是由“供貨單位編號”＋“合同號”生成的智能主鍵，當(dāng)其中的“供貨單位編號”和“合同號”中任何一個發(fā)生變化時，該合同表的主鍵都會發(fā)生變化，給變化數(shù)據(jù)捕獲帶來了很大的麻煩。工程中，筆者的處理方式是采用觸發(fā)器的手段來實現(xiàn)變化數(shù)據(jù)捕獲。概括的實現(xiàn)方式是：1）建立一個新表作為保存捕獲的數(shù)據(jù)表使用，其中字段有“原主鍵”、“修改后主鍵”、及其他需要的字段，稱為“合同捕獲表”。2）在原合同表Delete和Update時分別建立觸發(fā)器，當(dāng)刪除操作發(fā)生時，建在Delete上的觸發(fā)器會插入一條記錄到“合同捕獲表”，其中“修改后主鍵”字段為空，表示該記錄是刪除的記錄；當(dāng)發(fā)生更新時，將“原主鍵”、“修改后主鍵”及其他需要記錄的字段都保存入“合同捕獲表”中，表示該記錄被修更正，假設(shè)“原主鍵”和“修改后主鍵”不同，那么表示主鍵被修改，假設(shè)一致，那么表示主鍵沒有被修改。3）由于操作系統(tǒng)中的主鍵通常會成為數(shù)據(jù)倉庫中事實表的退化維度，可能仍會起主鍵的作用。所以在數(shù)據(jù)加載時，需要分處境判斷“合同捕獲表”的數(shù)據(jù)來抉擇是否更新事實表中的退化維度?？梢哉f，這樣的基于觸發(fā)器的變化數(shù)據(jù)捕獲方法并不是一個很好的選擇。首先這需要對源系統(tǒng)有較大的權(quán)限；其次，觸發(fā)器會給源系統(tǒng)的性能帶來很大的影響。所以除非是沒有別的選擇，否那么不建議采用這種方法。而對于這樣的處境，我們在建立操作型數(shù)據(jù)庫系統(tǒng)時完全可以制止。下面是對操作型數(shù)據(jù)庫系統(tǒng)建立者的幾點建議：1）操作型系統(tǒng)的主鍵不要建立成智能型的，至少不要