數(shù)據(jù)倉庫系統(tǒng)的設(shè)計及開發(fā)_第1頁
數(shù)據(jù)倉庫系統(tǒng)的設(shè)計及開發(fā)_第2頁
數(shù)據(jù)倉庫系統(tǒng)的設(shè)計及開發(fā)_第3頁
數(shù)據(jù)倉庫系統(tǒng)的設(shè)計及開發(fā)_第4頁
數(shù)據(jù)倉庫系統(tǒng)的設(shè)計及開發(fā)_第5頁
已閱讀5頁,還剩104頁未讀, 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

2.3.數(shù)據(jù)倉庫設(shè)計—數(shù)據(jù)建模最佳實踐—構(gòu)建高性能的數(shù)據(jù)倉庫數(shù)據(jù)倉庫設(shè)計—ETL設(shè)計數(shù)據(jù)倉庫設(shè)計—建模過程日程安排數(shù)據(jù)倉庫設(shè)計—界面設(shè)計數(shù)據(jù)倉庫的開發(fā)應用過程2023年4月29日1第一頁,共109頁。第一頁,共109頁。3.靈活性能夠很好的分離出底層技術(shù)的實現(xiàn)和上層業(yè)務的展現(xiàn)當上層業(yè)務發(fā)生變化時,通過數(shù)據(jù)模型,底層技術(shù)實現(xiàn)可以較為輕松的完成業(yè)務的變動,從而達到整個數(shù)據(jù)倉庫系統(tǒng)的靈活性1.業(yè)務核理改善業(yè)務流程能夠全面了解業(yè)務系統(tǒng)的業(yè)務架構(gòu)圖和整個業(yè)務運行情況2)能夠?qū)I(yè)務按照特定的規(guī)律進行分門別類和程序化2.解決信息孤島及數(shù)據(jù)差異1)

建立全方法的數(shù)據(jù)視角;2)

保證整個企業(yè)的數(shù)據(jù)的一致性;3)

消除各個部門之間的信息孤島;4.加快數(shù)據(jù)倉庫系統(tǒng)的建設(shè)開發(fā)人員和業(yè)務人員能夠很容易達成系統(tǒng)建設(shè)范圍的邊界的界定能夠使整個項目組明確當前的任務,加快整個系統(tǒng)建設(shè)的速度為什么需要數(shù)據(jù)模型2023年4月29日2第二頁,共109頁。第二頁,共109頁。數(shù)據(jù)倉庫建模人員所需的技能和能力分析能力見樹又見林模擬論證學習能力抽象綜合交流能力組交互演示調(diào)查訪談原型設(shè)計能力企業(yè)體系架構(gòu)2023年4月29日3第三頁,共109頁。第三頁,共109頁。數(shù)據(jù)倉庫設(shè)計建模的要點和原則建模原則選擇創(chuàng)建什么模型對如何動手解決問題和如何解決方案有深遠影響每一種模型可以在不同的精度級別上表示最好的模型是與現(xiàn)實相聯(lián)系單個模型不充分,需要一組模型去處理建模的要點正確認識建模方法論2023年4月29日4第四頁,共109頁。第四頁,共109頁。利用圖形來建立數(shù)據(jù)模型圖形具有直觀性、簡單性以及可理解性等優(yōu)點圖形能自然地表達客觀世界理解圖中路徑探索2023年4月29日5第五頁,共109頁。第五頁,共109頁。什么是數(shù)據(jù)模型業(yè)務建模,生成業(yè)務模型,主要解決業(yè)務層面的分解和程序化。領(lǐng)域建模,生成概念模型,主要是對業(yè)務模型進行抽象處理,生成領(lǐng)域概念模型。邏輯建模,生成邏輯模型,主要是將領(lǐng)域模型的概念實體以及實體之間的關(guān)系進行數(shù)據(jù)庫層次的邏輯化。物理建模,生成物理模型,主要解決,邏輯模型針對不同關(guān)系型數(shù)據(jù)庫的物理化以及性能等一些具體的技術(shù)問題。2023年4月29日6第六頁,共109頁。第六頁,共109頁。思考需求建模與業(yè)務建模需求建模與業(yè)務建模誰先誰后?軟件開發(fā)過程是否應該是:業(yè)務調(diào)研,業(yè)務建模(業(yè)務分析),(業(yè)務模型分析)需求調(diào)研(這時,已經(jīng)有一部分需求可從業(yè)務模型中獲得),需求建模,需求分析……2023年4月29日7第七頁,共109頁。第七頁,共109頁。業(yè)務建?!M織結(jié)構(gòu)分析2023年4月29日8第八頁,共109頁。第八頁,共109頁。組織結(jié)構(gòu),用戶及權(quán)限的分析客戶組織結(jié)構(gòu)的分析公司組織機構(gòu)區(qū)域位置集團/省/地市用戶的分析用戶組角色權(quán)限的分析功能權(quán)限分析數(shù)據(jù)權(quán)限分析2023年4月29日9第九頁,共109頁。第九頁,共109頁。例:三大運營商的組織架構(gòu)調(diào)整29四月202310第十頁,共109頁。第十頁,共109頁。業(yè)務建?!獦I(yè)務流程分析2023年4月29日11第十一頁,共109頁。第十一頁,共109頁。什么是業(yè)務流程2023年4月29日12第十二頁,共109頁。第十二頁,共109頁。業(yè)務流程分析的內(nèi)容(1)原有流程的分析。(2)業(yè)務流程的優(yōu)化。(3)確定新的業(yè)務流程(4)新系統(tǒng)的人機界面。2023年4月29日13第十三頁,共109頁。第十三頁,共109頁。業(yè)務流程分析的步驟1.系統(tǒng)環(huán)境調(diào)查2.組織機構(gòu)和職責的調(diào)查3.功能體系的調(diào)查與分析4.管理業(yè)務流程的調(diào)查與分析

2023年4月29日14第十四頁,共109頁。第十四頁,共109頁。案例學習:

新業(yè)務客戶服務業(yè)務流程—新業(yè)務查詢流程2023年4月29日15第十五頁,共109頁。第十五頁,共109頁。業(yè)務流程可以代替業(yè)務建模嗎在業(yè)務流程的背后,有一個更加根本的因素——商業(yè)需求。商業(yè)需求才是真正的業(yè)務模型,業(yè)務流程只是一種實現(xiàn)手段而已。例:新用戶入網(wǎng)業(yè)務流程:1:首先把SIM卡和號碼在交換網(wǎng)絡上做對應關(guān)系的注冊;2:市場部把SIM卡存入一定的金額,發(fā)給銷售商,收取銷售商的貨款;3:銷售商把卡賣給用戶,用戶填寫入網(wǎng)合同,SIM裝入手機可以立即通話;4:銷售商把入網(wǎng)合同交給市場部,市場部資料錄入人員將用戶的資料錄入系統(tǒng);5:計費系統(tǒng)按照用戶選擇的資費對話單進行計費;6、市場部按照用戶的消費情況給銷售商計算傭金和返利。思考:真正的業(yè)務模型(需求)是什么?2023年4月29日16第十六頁,共109頁。第十六頁,共109頁。從業(yè)務流程中提取概念和邏輯模型心得體會:看到背后的商業(yè)需求,你會發(fā)現(xiàn)模型原來非常穩(wěn)定不需要急于知道所有的細節(jié)性的需求,只要了解比較重要的20%的需求2023年4月29日17第十七頁,共109頁。第十七頁,共109頁。數(shù)據(jù)倉庫數(shù)據(jù)模型-星型模型與雪花模型2023年4月29日18第十八頁,共109頁。第十八頁,共109頁。數(shù)據(jù)倉庫建模的原則兼顧效率與數(shù)據(jù)粒度的需要1支持需求的變化2避免對業(yè)務運營系統(tǒng)造成影響3滿足不同用戶的需要4考慮末來的可擴展性52023年4月29日19第十九頁,共109頁。第十九頁,共109頁。數(shù)據(jù)倉庫建模的三個階段概念模型設(shè)計(ConceptDataModeling):這一階段之前的首要工作是通過需求分析,明確需求所涵蓋的業(yè)務范圍。然后再對需求范圍內(nèi)的業(yè)務及其間關(guān)系進行高度概括性的描述,把密切相關(guān)業(yè)務對象進行歸類,即劃分主題域。概念模型的設(shè)計是為邏輯模型的設(shè)計做準備,它沒有統(tǒng)一的標準,主要根據(jù)設(shè)計者的經(jīng)驗。邏輯模型設(shè)計(LogicalDataModeling):分別對概念模型的各個主題域進行細化,根據(jù)業(yè)務定義、分類和規(guī)則,定義其中的實體并描述實體之間的關(guān)系,并產(chǎn)生實體關(guān)系圖(ERD),然后遵照規(guī)范化思想在實體關(guān)系的基礎(chǔ)上明確各個實體的屬性。實體產(chǎn)生于中國移動開展的業(yè)務、服務及其涉及的對象(如客戶、帳戶、員工、機構(gòu)、資源),實體間的對應、約束關(guān)系則來自于各業(yè)務過程中的規(guī)則??梢哉f,這一階段面對的是業(yè)務。

物理模型設(shè)計(PhysicalDataModeling):物理模型設(shè)計主要依據(jù)邏輯模型針對具體的分析需求和物理平臺采取相應的優(yōu)化策略。此時會在一定程度上增加數(shù)據(jù)冗余或者隱藏實體之間的關(guān)系或者進行實體的合并和拆分,目的是提高數(shù)據(jù)分析的速度,適應具體數(shù)據(jù)庫的容量、性能等限制??梢哉f,這一階段面對的是具體軟硬件平臺和性能要求。一旦邏輯模型到位,物理模型就有了可參照的依據(jù),開發(fā)工作內(nèi)容也同時得到明確。物理模型設(shè)計一般在架構(gòu)設(shè)計階段2023年4月29日20第二十頁,共109頁。第二十頁,共109頁。數(shù)據(jù)倉庫系統(tǒng)所采用的建模流程概念模型為邏輯模型的設(shè)計作準備,沒有統(tǒng)一標準,主要根據(jù)設(shè)計者經(jīng)驗邏輯模型對概念模型的各個主題域進行細化,根據(jù)業(yè)務定義、分類和規(guī)則,定義其中的實體并描述實體之間的關(guān)系,并產(chǎn)生實體關(guān)系圖(ERD)一旦邏輯模型到位,物理模型就有了可參照的依據(jù),開發(fā)工作內(nèi)容也同時得到明確2023年4月29日21第二十一頁,共109頁。第二十一頁,共109頁。數(shù)據(jù)倉庫概念模型

主題域的設(shè)計DW主題的劃分必須是基于需求的主題劃分,而不僅僅是基于已有查詢和報表數(shù)據(jù)的主題劃分DW主題是通過對業(yè)務人員的訪談,充分了解業(yè)務流程和信息使用需求為主要根源的DW主題的設(shè)計必須能夠滿足業(yè)務人員的內(nèi)在的分析需求DW主題設(shè)計的過程中,業(yè)務環(huán)節(jié)點分析是關(guān)鍵DW細化分析主題,解決指標的歧義問題,為模型設(shè)計、數(shù)據(jù)提取、數(shù)據(jù)展現(xiàn)等多個方面奠定基礎(chǔ)2023年4月29日22第二十二頁,共109頁。第二十二頁,共109頁。數(shù)據(jù)倉庫的數(shù)據(jù)模型系統(tǒng)記錄域(SystemofRecord):這部分是主要的數(shù)據(jù)倉庫業(yè)務數(shù)據(jù)存儲區(qū),數(shù)據(jù)模型在這里保證了數(shù)據(jù)的一致性。內(nèi)部管理域(Housekeeping):這部分主要存儲數(shù)據(jù)倉庫用于內(nèi)部管理的元數(shù)據(jù),數(shù)據(jù)模型在這里能夠幫助進行統(tǒng)一的元數(shù)據(jù)的管理。匯總域(SummaryofArea):這部分數(shù)據(jù)來自于系統(tǒng)記錄域的匯總,數(shù)據(jù)模型在這里保證了分析域的主題分析的性能,滿足了部分的報表查詢。分析域(AnalysisArea):這部分數(shù)據(jù)模型主要用于各個業(yè)務部分的具體的主題業(yè)務分析。這部分數(shù)據(jù)模型可以單獨存儲在相應的數(shù)據(jù)集市中。反饋域(FeedbackArea):可選項,這部分數(shù)據(jù)模型主要用于相應前端的反饋數(shù)據(jù),數(shù)據(jù)倉庫可以視業(yè)務的需要設(shè)置這一區(qū)域。2023年4月29日23第二十三頁,共109頁。第二十三頁,共109頁。數(shù)據(jù)模型的技術(shù)功能結(jié)構(gòu)劃分

分段存儲區(qū)(StagingArea)是為了保證數(shù)據(jù)移動的順利進行而開設(shè)的階段性數(shù)據(jù)存儲空間,它是業(yè)務系統(tǒng)原始數(shù)據(jù)進入數(shù)據(jù)倉庫前的緩存區(qū)?;A(chǔ)數(shù)據(jù)倉庫根據(jù)業(yè)務需求的不同,基礎(chǔ)數(shù)據(jù)倉庫的組織形式以三范式模型為主,在有的系統(tǒng)中也可能采用星型或雪花模型。數(shù)據(jù)集市(DataMart)數(shù)據(jù)集市中的數(shù)據(jù)通常由基礎(chǔ)數(shù)據(jù)倉庫的詳細數(shù)據(jù)聚合而來,根據(jù)數(shù)據(jù)聚合程度的不同包含輕度聚合、中度聚合和高度聚合三種不同的層次。匯總的方式將依據(jù)數(shù)據(jù)量的大小和使用頻度綜合考慮2023年4月29日24第二十四頁,共109頁。第二十四頁,共109頁。數(shù)據(jù)倉庫的模型—關(guān)系模型2023年4月29日25第二十五頁,共109頁。第二十五頁,共109頁。數(shù)據(jù)倉庫的模型—星型模型通過數(shù)據(jù)預連接和建立有選擇的數(shù)據(jù)冗余,設(shè)計者為訪問和分析過程大大簡化了數(shù)據(jù)。星型連接應用于設(shè)計數(shù)據(jù)倉庫中很大的實體,而數(shù)據(jù)模型則應用于數(shù)據(jù)倉庫中較小的實體。2023年4月29日26第二十六頁,共109頁。第二十六頁,共109頁。數(shù)據(jù)倉庫的模型—雪花模型許多維度存在著比較復雜的結(jié)構(gòu),它們有的還具有多層的層次結(jié)構(gòu)。因此,很難將這樣的維表只采用一個關(guān)系表的形式表達出來,必須將這些維表規(guī)范成有多個外鍵關(guān)聯(lián)的關(guān)系表2023年4月29日27第二十七頁,共109頁。第二十七頁,共109頁。星型模型VS雪花模型比較項目優(yōu)點缺點星型模式1.查詢效率高,事實表作連接時其速度較快;2.便于用戶理解。比較直觀,通過分析星形模式,很容易組合出各種查詢增加了存儲空間雪花模式1.在一定程度上減少了存儲空間2.規(guī)范化的結(jié)構(gòu)更容易更新和維護1.比較復雜,用戶不容易理解;2.瀏覽內(nèi)容相對困難3.額外的連接將使查詢性能下降2023年4月29日28第二十八頁,共109頁。第二十八頁,共109頁。寬表橫表與縱表處理方便性與業(yè)務支撐靈活性的差異寬表在橫表的基礎(chǔ)上拓展,強化處理方便性開放給業(yè)務人員使用,直接解決業(yè)務問題單條記錄包括用戶基本信息、產(chǎn)品選擇和使用量、費用信息2023年4月29日29第二十九頁,共109頁。第二十九頁,共109頁。數(shù)據(jù)倉庫建模方法—范式建模法優(yōu)點:從關(guān)系型數(shù)據(jù)庫的角度出發(fā),結(jié)合了業(yè)務系統(tǒng)的數(shù)據(jù)模型,能夠比較方便的實現(xiàn)數(shù)據(jù)倉庫的建模缺點:在某些時候反而限制了整個數(shù)據(jù)倉庫模型的靈活性,性能等2023年4月29日30第三十頁,共109頁。第三十頁,共109頁。數(shù)據(jù)倉庫建模方法—維度建模法優(yōu)點:維度建模非常直觀,緊緊圍繞著業(yè)務模型,可以直觀的反映出業(yè)務模型中的業(yè)務問題缺點:如果只是依靠單純的維度建模,不能保證數(shù)據(jù)來源的一致性和準確性2023年4月29日31第三十一頁,共109頁。第三十一頁,共109頁。數(shù)據(jù)倉庫建模方法—實體建模法優(yōu)點:能夠很輕松的實現(xiàn)業(yè)務模型的劃分,因此,在業(yè)務建模階段和領(lǐng)域概念建模階段,實體建模法有著廣泛的應用缺點:不太適用于物理建模2023年4月29日32第三十二頁,共109頁。第三十二頁,共109頁。數(shù)據(jù)倉庫建模的十大戒律1)

必須回答緊迫的問題;2)

必須有正確的事實表;3)

將有正確的維表,描述必須按最終用戶的業(yè)務術(shù)語表達;4)

必須理解數(shù)據(jù)倉庫所影響的公司過程或影響數(shù)據(jù)倉庫的公司過程;5)

對于事實表,應該有正確的“粒度”;6)

根據(jù)需要存儲正確長度的公司歷史數(shù)據(jù);7)

以一種對于公司有意義的方式來集成所有必要的數(shù)據(jù);8)

創(chuàng)建必要的總結(jié)表;9)

創(chuàng)建必要的索引;10)

能夠加載數(shù)據(jù)倉庫數(shù)據(jù)庫并使它以一種適宜的方式可用。2023年4月29日33第三十三頁,共109頁。第三十三頁,共109頁。數(shù)據(jù)倉庫緩慢變化維的一個案例一個案例在一個零售業(yè)數(shù)據(jù)倉庫中,事實表保存著各銷售人員的銷售記錄,某天一個銷售人員從北京分公司調(diào)到上海分公司了,那么如何來保存這個變化呢?也就是說銷售人員維度要怎么恰當?shù)奶幚磉@一變化。如果我們要統(tǒng)計北京地區(qū)或上海地區(qū)的總銷售情況的時候,這個銷售人員的銷售記錄應該算在北京還是算在上海?當然是調(diào)離前的算在北京,調(diào)離后的算在上海,但是如標記這個銷售人員所屬區(qū)域?這里就需要處理一下這個維度的數(shù)據(jù),即我們緩慢變化維需要做的事情。

2023年4月29日34第三十四頁,共109頁。第三十四頁,共109頁。數(shù)據(jù)倉庫緩慢變化維的解決方案新數(shù)據(jù)覆蓋舊數(shù)據(jù)保存多條記錄,并添加字段加以區(qū)分.添加記錄的生效日期和失效日期來標識新舊數(shù)據(jù)

不同字段保存不同值

,這種方法用不同的字段保存變化痕跡.但是這種方法不能象第二種方法一樣保存所有變化記錄,它只能保存兩次變化記錄.適用于變化不超過兩次的維度。另外建表保存歷史記錄,而維度只保存當前數(shù)據(jù)

混合模式2023年4月29日35第三十五頁,共109頁。第三十五頁,共109頁。數(shù)據(jù)倉庫建模_案例2023年4月29日36第三十六頁,共109頁。第三十六頁,共109頁。案例:怎樣構(gòu)建數(shù)據(jù)倉庫模型確定主題域確定主題域及各主題域之間的關(guān)系確定主題域的業(yè)務數(shù)據(jù)確定業(yè)務數(shù)據(jù)中的業(yè)務實體確定業(yè)務實體之間的關(guān)系確定物理模型2023年4月29日37第三十七頁,共109頁。第三十七頁,共109頁。確定主題域及各主題域之間的關(guān)系服務通過網(wǎng)絡實現(xiàn)/網(wǎng)絡支持服務網(wǎng)絡產(chǎn)生事件/事件包括網(wǎng)絡類產(chǎn)品被銷售給客戶/參與人使用和管理產(chǎn)品跟蹤應付&應收/提供成本&收入歷史事件包含財務類參與人產(chǎn)生和經(jīng)歷事件/事件包括參與人的產(chǎn)品/服務產(chǎn)生事件

事件包括產(chǎn)品類營銷產(chǎn)生事件事件實現(xiàn)營銷營銷被鎖定位置/位置定位營銷針對特定產(chǎn)品/產(chǎn)品通過營銷推向市場為參與人建立帳戶、帳單/記錄帳戶、成本和付款服務使用的帳務信息/帳務記錄產(chǎn)品的成本和付款定位網(wǎng)絡/網(wǎng)絡支持的位置營銷的目標針對參與人/參與人是營銷的受眾包括消費者和運營商在內(nèi)/

位置定位FinanceManagement(財務管理)BILLING(帳務)NETWORK(網(wǎng)絡資源)PRODUCT(產(chǎn)品)MARKETING(市場營銷)LOCATION(地域)PARTY(參與人)EVENT(事件)跟蹤總帳/負責2023年4月29日38第三十八頁,共109頁。第三十八頁,共109頁?;窘Y(jié)構(gòu)特征獎勵隱私參與人主題描述了和電信運營商有著業(yè)務聯(lián)系的任何個人、企業(yè)、組織、團體等。

確定主題域的業(yè)務數(shù)據(jù)2023年4月29日39第三十九頁,共109頁。第三十九頁,共109頁。參與人間關(guān)聯(lián)

參與人角色組織層次結(jié)構(gòu)層次結(jié)構(gòu)級別層次結(jié)構(gòu)類型商業(yè)組織內(nèi)部組織標準分類代碼確定基本結(jié)構(gòu)業(yè)務數(shù)據(jù)的業(yè)務實體及關(guān)系參與人:和電信運營商有著業(yè)務聯(lián)系的任何個人、組織機構(gòu)、家庭和虛擬客戶

。例:財務市場營銷網(wǎng)管例:客戶潛在客戶電信運營商代理商供應商管理者雇主職工個人家庭組織參與人2023年4月29日40第四十頁,共109頁。第四十頁,共109頁。特征符合程度特征類別值客戶特征帳戶特征特征類別例:個人喜好信用類信息家庭類信息教育類信息職業(yè)類信息機構(gòu)類信息

例:信用等級職業(yè)狀態(tài)收入子女數(shù)教育程度特征分組完全符合部分符合不符合確定特征業(yè)務數(shù)據(jù)中的業(yè)務實體及關(guān)系2023年4月29日41第四十一頁,共109頁。第四十一頁,共109頁。獎勵計劃管理參與人角色獎勵目標客戶群目標群獎勵等級獎勵類型參與人獎勵歷史記錄獎勵計劃獎勵計劃:記錄電信運營商向客戶提供獎勵和回報的歷史。確定獎勵業(yè)務數(shù)據(jù)中的業(yè)務實體及關(guān)系2023年4月29日42第四十二頁,共109頁。第四十二頁,共109頁。隱私信息類別同意周期組織隱私策略信息參與人帳戶隱私信息帳戶同意等級信息參與人同意等級信息參與人隱私信息隱私信息類別確定隱私業(yè)務數(shù)據(jù)中的業(yè)務實體及關(guān)系2023年4月29日43第四十三頁,共109頁。第四十三頁,共109頁。業(yè)務系統(tǒng)與數(shù)據(jù)倉庫模型的映射2023年4月29日44第四十四頁,共109頁。第四十四頁,共109頁。數(shù)據(jù)倉庫建模_案例實踐2023年4月29日45第四十五頁,共109頁。第四十五頁,共109頁。國內(nèi)社保行業(yè)背景目前我們國家的社保主要分為養(yǎng)老,失業(yè),工傷,生育,醫(yī)療保險和勞動力市場這6大塊主要業(yè)務領(lǐng)域。在這6大業(yè)務領(lǐng)域中,目前的狀況養(yǎng)老和事業(yè)的系統(tǒng)已經(jīng)基本完善,已經(jīng)有一部分數(shù)據(jù)開始聯(lián)網(wǎng)檢測。對于工傷,生育,醫(yī)療和勞動力市場這一塊業(yè)務,有些地方發(fā)展的比較成熟,而有些地方還不夠成熟。請大家思考并簡單描述社保行業(yè)的數(shù)據(jù)倉庫模型:大致的業(yè)務模型大致的概念模型2023年4月29日46第四十六頁,共109頁。第四十六頁,共109頁。社保行業(yè)數(shù)據(jù)倉庫業(yè)務模型2023年4月29日47第四十七頁,共109頁。第四十七頁,共109頁。社保行業(yè)數(shù)據(jù)倉庫領(lǐng)域概念模型2023年4月29日48第四十八頁,共109頁。第四十八頁,共109頁。社保行業(yè)數(shù)據(jù)倉庫邏輯模型通過領(lǐng)域概念模型細化邏輯模型每一個抽象的實體,例如:“人”的屬性包括年齡,性別,受教育程度等等。各個抽象實體間的聯(lián)系。例如:對于養(yǎng)老金征繳這個“事件”的屬性得考慮,對于失業(yè)勞動者培訓這個“事件”的屬性得考慮等等。找出抽象事件的關(guān)系,并對其進行說明。例如:對于“事件”中的地域,事件等因素的考量等等。建議:可以參考3NF的建模方法,表達出實體的屬性,以及實體與實體之間的聯(lián)系。例如:在這個階段,我們可以通過采用ERWIN等建模工具等作出符合3NF的關(guān)系型數(shù)據(jù)模型來。

2023年4月29日49第四十九頁,共109頁。第四十九頁,共109頁。社保行業(yè)數(shù)據(jù)倉庫物理模型完成物理模型生成創(chuàng)建表的腳本。不同的數(shù)據(jù)倉庫平臺可能生成不同的腳本。針對數(shù)據(jù)集市的需要,按照維度建模的方法,生成一些事實表,維表等工作。針對數(shù)據(jù)倉庫的

ETL

車和元數(shù)據(jù)管理的需要,生成一些數(shù)據(jù)倉庫維護的表,例如:日志表等。注:根據(jù)業(yè)務實際的需要和自己對抽象能力的把握來創(chuàng)建適合自己的數(shù)據(jù)模型

2023年4月29日50第五十頁,共109頁。第五十頁,共109頁。總結(jié):

數(shù)據(jù)倉庫建模需注意的幾個問題數(shù)據(jù)粒度和數(shù)據(jù)組織維和度量的唯一性和公用性數(shù)據(jù)粒度一旦變粗,就要考慮多個主題的融合匯總不論如何歸并,需要保持數(shù)據(jù)之間的聯(lián)系對ODS中的各個主題的事實數(shù)據(jù)進行時間上的匯總把包含細節(jié)過多的交易記錄進行拆分匯總、再匯總2023年4月29日51第五十一頁,共109頁。第五十一頁,共109頁。2.3.數(shù)據(jù)倉庫數(shù)據(jù)模型—星形與雪花最佳實踐—構(gòu)建高性能的數(shù)據(jù)倉庫數(shù)據(jù)倉庫設(shè)計—ETL設(shè)計數(shù)據(jù)倉庫設(shè)計—建模過程日程安排數(shù)據(jù)倉庫設(shè)計—界面設(shè)計數(shù)據(jù)倉庫的開發(fā)應用過程2023年4月29日52第五十二頁,共109頁。第五十二頁,共109頁。ETL數(shù)據(jù)轉(zhuǎn)換過程的功能模塊設(shè)計ETL數(shù)據(jù)轉(zhuǎn)換操作大致可以分為6個組或模塊:數(shù)據(jù)的提取、驗證、清理、集成、聚集和裝入。2023年4月29日53第五十三頁,共109頁。第五十三頁,共109頁。ETL的設(shè)計要點(1)ETL的設(shè)計一定是針對具體的應用相關(guān)的,針對不同的業(yè)務和分析模型有不同的抽取要求在設(shè)計過程中需要考慮是否需要預留字段,增加屬性等等數(shù)據(jù)的粒度,在同一CUBE中必須統(tǒng)一數(shù)據(jù)周期的確定,在設(shè)計ETL時需要事先確定抽取的時間抽取的方式盡量采用增量的抽取以減小每次抽取的數(shù)量數(shù)據(jù)流和工作流的考慮2023年4月29日54第五十四頁,共109頁。第五十四頁,共109頁。ETL的設(shè)計要點(2)流程的異常處理ETL的調(diào)整,運行管理以及監(jiān)控針對業(yè)務的需求進行ETL的配置和設(shè)置界面ETL對CUBE的管理ETL裝載數(shù)據(jù)初始化的過程程序具有自修復功能2023年4月29日55第五十五頁,共109頁。第五十五頁,共109頁。確定ETL的抽取及加載策略抽取策略每日增量

每日全量

每月增量

每月全量抽取策略全表覆蓋

歷史加載

直接追加

主表加載初始加載其它加載2023年4月29日56第五十六頁,共109頁。第五十六頁,共109頁。ETLMapping實體映射表2023年4月29日57第五十七頁,共109頁。第五十七頁,共109頁。確定ETL接口需求系統(tǒng)和任何其他外部系統(tǒng)或組件進行交互相關(guān)需求接口一般由系統(tǒng)間的傳輸方式、傳輸協(xié)議、傳輸過程、接口處理模式、抽取周期、編碼原則、命名規(guī)則、驗證方式和數(shù)據(jù)單元等組成2023年4月29日58第五十八頁,共109頁。第五十八頁,共109頁。確定ETL接口的實現(xiàn)方式2023年4月29日59第五十九頁,共109頁。第五十九頁,共109頁。確定ETL接口的數(shù)據(jù)要求及保障2023年4月29日60第六十頁,共109頁。第六十頁,共109頁。確定ETL接口文件的格式2023年4月29日61第六十一頁,共109頁。第六十一頁,共109頁。確定ETL接口文件的內(nèi)容2023年4月29日62第六十二頁,共109頁。第六十二頁,共109頁。確定ETL接口單元2023年4月29日63第六十三頁,共109頁。第六十三頁,共109頁。ETL接口數(shù)據(jù)處理流程2023年4月29日64第六十四頁,共109頁。第六十四頁,共109頁。ETL接口出錯處理接口處理重傳機制1、經(jīng)營分析系統(tǒng)方校驗數(shù)據(jù)源內(nèi)容后把出錯記錄放入“出錯記錄文件存放目錄”2、數(shù)據(jù)源廠商定時查閱此目錄,分析錯誤原因,并采取糾正措施例如:重新傳送此數(shù)據(jù)項文件。具體的實現(xiàn)方式需雙方協(xié)定。大數(shù)據(jù)文件分拆機制只要是增量抽取的,原則上不考慮分拆,對于GSM清單和普通短信清單,數(shù)據(jù)量很大,考慮分拆成12個數(shù)據(jù)文件,每2小時一個。2023年4月29日65第六十五頁,共109頁。第六十五頁,共109頁。案例學習2023年4月29日66第六十六頁,共109頁。第六十六頁,共109頁。2.3.數(shù)據(jù)倉庫數(shù)據(jù)模型—星形與雪花BI項目設(shè)計開發(fā)的最佳實踐數(shù)據(jù)倉庫設(shè)計—ETL設(shè)計數(shù)據(jù)倉庫設(shè)計—建模過程日程安排數(shù)據(jù)倉庫設(shè)計—界面設(shè)計數(shù)據(jù)倉庫的開發(fā)應用過程2023年4月29日67第六十七頁,共109頁。第六十七頁,共109頁。確定界面元素界面主顏色字體顏色及大小界面布局界面交互方式界面功能分布界面輸入輸出模式2023年4月29日68第六十八頁,共109頁。第六十八頁,共109頁。某運營商KPI系統(tǒng)目標以最方便的形式讓各級領(lǐng)導對考核指標完成情況進行瀏覽分析采用良好方式實現(xiàn)常用指標的關(guān)聯(lián)展示,更加符合業(yè)務人員的分析邏輯采用樹型菜單對個體分散指標進行分類展示組織,提高指標分析的操作的便捷性詳細編寫各業(yè)務指標的統(tǒng)計口徑,讓用戶可以方便查詢和檢索2023年4月29日69第六十九頁,共109頁。第六十九頁,共109頁。KPI系統(tǒng)指標體系2023年4月29日70第七十頁,共109頁。第七十頁,共109頁。數(shù)據(jù)準確性刷新/上載數(shù)據(jù)的頻率(定期)數(shù)據(jù)下鉆能力訪問控制KPI系統(tǒng)關(guān)鍵性:低高KPI分層KPI系統(tǒng)主要功能2023年4月29日71第七十一頁,共109頁。第七十一頁,共109頁。1。支持角色,有預定義好的權(quán)限視圖2。分層管理:每個KPI有對應的“保障”KPI的層次定義3。動態(tài)交互式環(huán)境用戶可以設(shè)置KPI分解的百分比支持分解維度(按部門、運營中心如地市等)可調(diào)整的KPI分解規(guī)則4。閥值預警5。內(nèi)部標桿共享KPI系統(tǒng)框架和關(guān)鍵功能2023年4月29日72第七十二頁,共109頁。第七十二頁,共109頁。整體KPI首頁界面分為三個目錄級★KPI考核指標★KPI通報指標★KPI個體指標體現(xiàn)以表格的形式展現(xiàn)數(shù)據(jù),輔助以圖型增加指標之間的關(guān)聯(lián)性,從多角度體現(xiàn)指標的內(nèi)容。增加指標說明的模塊,對用戶使用該指標時容易產(chǎn)生理解誤差的內(nèi)容提供相應解釋。KPI系統(tǒng)首頁界面2023年4月29日73第七十三頁,共109頁。第七十三頁,共109頁。樹狀的目錄力求簡單,清晰,操作方便,減少用戶的點擊切換環(huán)節(jié)過程。KPI系統(tǒng)樹狀目錄結(jié)構(gòu)2023年4月29日74第七十四頁,共109頁。第七十四頁,共109頁。簡單明了的KPI指標往往成為管理者和普通市場人員最關(guān)注的對象領(lǐng)導的聊望臺滾動指標告警指標列表區(qū)首頁或結(jié)果展示區(qū)滾動指標告警區(qū)KPI系統(tǒng)首頁界面2023年4月29日75第七十五頁,共109頁。第七十五頁,共109頁。增強指標之間的關(guān)聯(lián)性,對若干指標的內(nèi)在聯(lián)系,進行歸類對比展示,以多種圖形方式進行多角度地展現(xiàn)。KPI系統(tǒng)界面12023年4月29日76第七十六頁,共109頁。第七十六頁,共109頁。KPI指標主要展現(xiàn)此項指標在時間上的對比,例如,上月當日,歷史同期,環(huán)比等。KPI指標按業(yè)務分析邏輯有機排列,方便業(yè)務人員對比觀看。KPI在表格上增加趨勢的展現(xiàn),分為三種,“平穩(wěn)”,“升高”,“降低”點擊以后將展示最近一周的趨勢KPI系統(tǒng)界面22023年4月29日77第七十七頁,共109頁。第七十七頁,共109頁。2.數(shù)據(jù)倉庫數(shù)據(jù)模型—星形與雪花BI項目設(shè)計開發(fā)的最佳實踐數(shù)據(jù)倉庫設(shè)計—ETL設(shè)計數(shù)據(jù)倉庫設(shè)計—建模過程日程安排數(shù)據(jù)倉庫的開發(fā)應用過程數(shù)據(jù)倉庫設(shè)計—界面設(shè)計2023年4月29日78第七十八頁,共109頁。第七十八頁,共109頁。自頂向下(Top-downApproach)建造企業(yè)數(shù)據(jù)倉庫建設(shè)中心數(shù)據(jù)模型一次性的完成數(shù)據(jù)的重構(gòu)工作最小化數(shù)據(jù)冗余度和不一致性存儲詳細的歷史數(shù)據(jù)從企業(yè)數(shù)據(jù)倉庫中建造數(shù)據(jù)集市得到大部分的集成數(shù)據(jù)直接依賴于數(shù)據(jù)倉庫的可用性對信心的極大考驗:投資大,建設(shè)時間長,階段成果顯現(xiàn)困難!ExternalDataODSCentralDataWarehouseDataMartDataMart2023年4月29日79第七十九頁,共109頁。第七十九頁,共109頁。自底而上(Bottom-upApproach)創(chuàng)建部門的數(shù)據(jù)集市范圍局限于一個主題區(qū)域快速的ROI--局部的商業(yè)需求得到滿足本部門自治--設(shè)計上具有靈活性對其他部門數(shù)據(jù)集市是一個好的指導容易復制到其他部門擴大到企業(yè)數(shù)據(jù)倉庫創(chuàng)建EDW作為一個長期的目標重復投資:每個部門都重復進行數(shù)據(jù)整理!企業(yè)數(shù)據(jù)倉庫建設(shè)困難:數(shù)據(jù)口徑、不一致性問題突出!DataMartDataMartCentralDataWarehouseExternalDataODSpartpartpartpartpartpart2023年4月29日80第八十頁,共109頁。第八十頁,共109頁。數(shù)據(jù)倉庫工程項目的特點數(shù)據(jù)倉庫工程既包括數(shù)據(jù)又包括程序,而且是以數(shù)據(jù)為基礎(chǔ)的系統(tǒng)數(shù)據(jù)倉庫工程中的數(shù)據(jù)倉庫的目標是面向主題數(shù)據(jù)倉庫工程是以處理分析型目標為主而不是事物型目標,它對數(shù)據(jù)內(nèi)容正確性與形式規(guī)范性有嚴格要求數(shù)據(jù)倉庫工程中數(shù)據(jù)來源已有多種信息系統(tǒng),因此對系統(tǒng)的數(shù)據(jù)要有一定的限制制約,也就是有了建立統(tǒng)一數(shù)據(jù)平臺的需求2023年4月29日81第八十一頁,共109頁。第八十一頁,共109頁。數(shù)據(jù)倉庫工程項目的開發(fā)應用過程解決方案啟動(Solutionstartup)業(yè)務發(fā)現(xiàn)(Businessdiscovery)解決方案建議(Solutionproposal)解決方案計劃(Solutionplanning)倉庫概念建模(Warehouseconceptualmodeling)倉庫階段設(shè)計(Warehousephasedesign)解決方案實現(xiàn)周期(Solutionimplementationcycle)解決方案部署(Solutiondeployment)

2023年4月29日82第八十二頁,共109頁。第八十二頁,共109頁。數(shù)據(jù)倉庫業(yè)務發(fā)現(xiàn)過程收集記錄業(yè)務需求理解客戶業(yè)務環(huán)境差異分析,理解客戶的業(yè)務難題及需求,彌補當前業(yè)務狀態(tài)及其業(yè)務需求之間差異2023年4月29日83第八十三頁,共109頁。第八十三頁,共109頁。收集記錄業(yè)務需求確定業(yè)務對象確定數(shù)據(jù)分析場景確定功能需求理解客戶的業(yè)務環(huán)境理解基礎(chǔ)架構(gòu)環(huán)境理解數(shù)據(jù)環(huán)境差異分析需求分析識別業(yè)務主題領(lǐng)域識別數(shù)據(jù)差異識別基礎(chǔ)設(shè)施差異識別資源的差異理解客戶環(huán)境三個任務可以重疊進行

數(shù)據(jù)倉庫的業(yè)務發(fā)現(xiàn)內(nèi)容2023年4月29日84第八十四頁,共109頁。第八十四頁,共109頁。2023年4月29日85第八十五頁,共109頁。第八十五頁,共109頁。數(shù)據(jù)倉庫工程項目的開發(fā)流程圖2023年4月29日86第八十六頁,共109頁。第八十六頁,共109頁。數(shù)據(jù)倉庫的數(shù)據(jù)流程(1):對原始數(shù)據(jù)進行數(shù)據(jù)抽取、清洗、整理后成為數(shù)據(jù)倉庫中的各種綜合度的數(shù)據(jù)表。(2):經(jīng)過維度分析得到維表并定義相應的格式表。(3):從數(shù)據(jù)倉庫中抽取數(shù)據(jù)形成事實表及補充事實表。(4):從數(shù)據(jù)倉庫中抽取信息,整理成數(shù)據(jù)挖掘?qū)挶恚糜跀?shù)據(jù)挖掘。(5):寬表中的數(shù)據(jù)通過數(shù)據(jù)挖掘程序處理后生成的擴展數(shù)據(jù)(挖掘結(jié)果)需要重新回寫進事實表。(6):利用數(shù)據(jù)展現(xiàn)工具展現(xiàn)OLAP和數(shù)據(jù)挖掘的結(jié)果。2023年4月29日87第八十七頁,共109頁。第八十七頁,共109頁。數(shù)據(jù)倉庫需求分析數(shù)據(jù)倉庫的特點是面向主題,按主題組織數(shù)據(jù)。1、主題分析

對于在層次結(jié)構(gòu)中的每個主題,需要進行詳細的調(diào)研,確定要分析的指標,確定用戶從哪些角度來分析數(shù)據(jù)即維度,還要確定用戶分析數(shù)據(jù)的細化或綜合程度即粒度。主題、指標、維度、粒度是是建立數(shù)據(jù)倉庫的基本要素。

2、數(shù)據(jù)分析

(1)數(shù)據(jù)源分析

(2)數(shù)據(jù)數(shù)量分析(3)數(shù)據(jù)質(zhì)量分析3、環(huán)境要求分析

需要對滿足需求的系統(tǒng)平臺與環(huán)境提出要求,包括設(shè)備、網(wǎng)絡、數(shù)據(jù)、接口、軟件等的要求。數(shù)據(jù)源分析主題分析數(shù)據(jù)質(zhì)量分析環(huán)境要求分析2023年4月29日88第八十八頁,共109頁。第八十八頁,共109頁。數(shù)據(jù)倉庫系統(tǒng)總體設(shè)計體系結(jié)構(gòu)設(shè)計接口設(shè)計應用程序模塊設(shè)計①數(shù)據(jù)源層②數(shù)據(jù)后端處理層③數(shù)據(jù)倉庫及其管理層④數(shù)據(jù)集市層⑤數(shù)據(jù)倉庫應用層⑥數(shù)據(jù)展示層①數(shù)據(jù)源與分析模型的接口②分析模型與應用的接口2023年4月29日89第八十九頁,共109頁。第八十九頁,共109頁。分析設(shè)計實施需求分析風險分析方案設(shè)計POC實施UAT發(fā)布環(huán)境準備Scope系統(tǒng)功能目標分析系統(tǒng)性能環(huán)境所帶來的風險分析可以容忍的見險關(guān)鍵流程的定義確定組織架構(gòu)方案設(shè)計(技術(shù)/框架/流程)數(shù)據(jù)備份方案時間窗環(huán)境(DB/TOOL/DATA)源代碼/POC數(shù)據(jù)POC報告CUT計劃測試/用戶測試數(shù)據(jù)備份系統(tǒng)觀察系統(tǒng)發(fā)布BugFixBI項目建設(shè)方法論2023年4月29日90第九十頁,共109頁。第九十頁,共109頁。

BI項目組織圖914/29/2023SteeringCommittee(項目經(jīng)理)(甲方項目經(jīng)理)ProjectManagerETL&DM(SeniorSE)Report(SeniorSE)TestQAKMSoultionArchitect2023年4月29日91第九十一頁,共109頁。第九十一頁,共109頁。BI項目組織說明項目指導委員會(SteeringCommittee):項目指導委員會主要由甲方與HP的資深主管們所組成,負責決定項目的策略方向與目的,并提供項目執(zhí)行所需要的支持與承諾。協(xié)助處理與仲裁項目執(zhí)行過程由項目經(jīng)理所提報(Escalate)所遇到之困難與爭議。協(xié)助處理項目執(zhí)行上所需要之人力資源支持與調(diào)動,如項目團隊之人員指派等。項目經(jīng)理(ProjectManager):在項目經(jīng)理的協(xié)助下,承擔并完成下列工作:規(guī)劃詳細的項目計劃書管理項目中所有的日常事務與工作事項,以期達成項目每的階段性任務及目標核審項目進度與項目里程碑定期與甲方項目經(jīng)理共同執(zhí)行項目的審核并商討項目的計劃定期以書面方式向項目指導委員會報告項目進行的狀況針對項目執(zhí)行上所遭遇的例外事件進行處理,并適當提報給項目指導委員會以尋求支持與協(xié)助與甲方項目經(jīng)理共同擔負起項目建置成功的責任924/29/20232023年4月29日92第九十二頁,共109頁。第九十二頁,共109頁。BI項目組織說明專案架構(gòu)師(SolutionArchitect):負責項目相關(guān)之技術(shù)架構(gòu)與功能設(shè)計等,并領(lǐng)導項目執(zhí)行技術(shù)團隊確認項目技術(shù)架構(gòu)符合甲方之維運要求與質(zhì)量標準。ETL組2人:負責ETL部分的開發(fā)與實施Report組2人:負責BOReport部分的開發(fā)與實施Test組2人:負責項目的系統(tǒng)測試與用戶最終測試其中測試組有1人兼任QA和KM角色。934/29/20232023年4月29日93第九十三頁,共109頁。第九十三頁,共109頁。M0M1M2M3M4M5BI項目里程碑Milestone項目啟動需求階段POC項目實施集成測試ReleaseUATM0.5M1.5M2.5M3.5M4.5RollOut注:在大約項目啟動后2個月,POC階段將完成,也即最初的原型構(gòu)建,用戶可以得到一個階段性的Release,下一步的項目實施及集成測試將以迭代的方式實現(xiàn)。2023年4月29日94第九十四頁,共109頁。第九十四頁,共109頁。BI項目實施階段階段輸入輸出項目啟動-評估SOW/方案建議書/遷移評估問題清單評估計劃,遷移方案,原始系統(tǒng)檢查報告項目啟動-項目計劃項目實施方案,當前環(huán)境和業(yè)務需求,數(shù)據(jù)和屬性,適用的實施工具項目計劃,質(zhì)量計劃,風險管理計劃,配置管理計劃,單元測試案例(持續(xù)更新),集成測試案例(持續(xù)更新)POC源代碼,POC數(shù)據(jù),原始系統(tǒng)檢查報告,實施方案實施模塊,POC測試結(jié)果,POC經(jīng)驗總結(jié),實施方案(更新),模塊實施步驟報告遷移源代碼,POC數(shù)據(jù),原始系統(tǒng)檢查報告,遷移方案實施的ETL腳本,數(shù)據(jù)模型,數(shù)據(jù)代碼,遷移測試腳本,模塊實施步驟報告集成測試測試計劃,測試案例,基準版本,質(zhì)量計劃已測試應用,測試報告,測試案例(更新)發(fā)布已實施應用ReleaseNote用戶驗收測試(UAT)驗收測試計劃驗收測試報告RollOut已遷移應用部署計劃,培訓材料2023年4月29日95第九十五頁,共109頁。第九十五頁,共109頁。優(yōu)化及案例分析-業(yè)務環(huán)境數(shù)據(jù)庫服務器:Windows2000Server+Oracle8i+IIS+PowerPlay

EnterpriseServer

應用服務器:Windows2000Server+Transformer

客戶端:IE5.0以上版本。2023年4月29日96第九十六頁,共109頁。第九十六頁,共109頁。優(yōu)化及案例分析-優(yōu)化內(nèi)容1.RAID

2.索引的建立3.SQL優(yōu)化4.直接裝載、分區(qū)選擇、網(wǎng)絡設(shè)置2023年4月29日97第九十七頁,共109頁。第九十七頁,共109頁。2.數(shù)據(jù)倉庫數(shù)據(jù)模型—星形與雪花BI項目設(shè)計開發(fā)的最佳實踐數(shù)據(jù)倉庫設(shè)計—ETL設(shè)計數(shù)據(jù)倉庫設(shè)計—建模過程日程安排數(shù)據(jù)倉庫的開發(fā)應用過程數(shù)據(jù)倉庫設(shè)計—界面設(shè)計2023年4月29日98第九十八頁,共109頁。第九十八頁,共109頁。影響倉庫性能的關(guān)鍵因素系統(tǒng)硬件磁盤(轉(zhuǎn)速、容量)IO速度(光纖卡、網(wǎng)卡、路由器)CPU(個數(shù)、主頻)主機個數(shù)數(shù)據(jù)模型邏輯模型物理模型應用復雜度及業(yè)務發(fā)展EDWDataWarehousing2023年4月29日99第九十九頁,共109頁。第九十九頁,共109頁。物理模型對性能的影響數(shù)據(jù)倉庫的創(chuàng)建(Build)

初始化每天數(shù)據(jù)載入每月數(shù)據(jù)載入數(shù)據(jù)維護應用查詢,統(tǒng)計的支持(Query)KPI固定報表OLAP數(shù)據(jù)挖掘?qū)n}分析即席查詢經(jīng)營分析報告/策劃查詢性能更應該被優(yōu)先保證!空間換取時間的優(yōu)化思想依然適用!2023年4月29日100第一百頁,共109頁。第一百頁,共109頁。非規(guī)范化優(yōu)化技術(shù)增加冗余列(預連接)避免查詢時進行表連接操作舉例:姓名、聯(lián)系方式、預存款、當前積分增加派生列(預計算)避免查詢時連接和使用聚合函數(shù)累計積分、ARPU、MOU、前3月平均話費、量收比重新組表(應用導向)經(jīng)常使用的查詢內(nèi)容以表的形式存放(物化視圖)分割(水平+垂直)用戶常用屬性與不常用屬性當前資料與歷史資料非規(guī)范化技術(shù)建立在查詢統(tǒng)計分析的基礎(chǔ)上的適合對記錄數(shù)非常多的表進行需要維護數(shù)據(jù)的完整性,加大了建設(shè)、維護的復雜度非規(guī)范化是一項高級設(shè)計技巧!OLTP系統(tǒng)也有,但OLAP需要更多,而且是核心!2023年4月29日101第一百零一頁,共109頁。第一百零一

溫馨提示

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

最新文檔

評論

0/150

提交評論