1. 程式人生 > >談談如何建立資料模型:

談談如何建立資料模型:

何謂資料模型呢?王珊老師告訴我們:資料模型就是現實世界的模擬.我的理解資料模型設計就是資料庫的設計
那麼優秀的資料模型應該是怎樣的呢?她應該滿足3個要求:
一是能夠比較真實的模擬現實世界
二是容易為人所理解
三是便於在計算機上實現。

資料模型的建立一般分為四步:1 需求分析 2 概念模型設計 3物力模型設計 4實施執行維護

1 需求分析的時候我們用到如下輔助方法:
業務流程圖    建議PD實現
資料詞典    建議PD實現
資料流圖    建議VISIO實現
系統流程圖    建議VISIO實現
組織結構圖    建議VISIO實現
時序圖        建議VISIO實現
狀態圖        建議VISIO實現
功能分解圖    建議VISIO實現

2 概念模型設計的時候我們用到如下輔助方法:
ER圖        建議PowerDesigner的CDM實現
資料詞典    建議PowerDesigner的Report實現
模型優化    正規化求證
設計使用者子模式  符合使用者習慣,也實現安全性

3 物理模型設計
資料庫結構    建議PowerDesigner的PDM實現

綜上所述:作為一個優秀的資料庫設計人員,需要靈活運用下面輔助方法
業務流程圖    (BPM)
資料流圖    (DFD: Data Flow Diagram)
實體關係圖    (ERD)
用例圖:        (use case model)
資料詞典    (DD: Data Dictionary)
時序圖        
狀態圖
系統流程圖
組織結構圖
功能分解圖

一般情況下,面對比較複雜的資料庫建模, 規範的做法是:

第一步: 需求分析,獲得業務流程圖,資料流圖和資料字典
第二步:根據資料流圖和資料字典建立E-R圖
第三步:E-R圖轉換成為物理資料模型
第四部:實施物理資料模型

如果你對於以上幾種圖不太瞭解,建議《資料庫系統原理教程》.不過快的辦法是找到形象的例圖.


參考:
《資料庫系統原理教程》        清華大學出版社   王珊,陳紅 編著
《湖南師範大學管理資訊複習材料》    



相關概念解釋:
------------------------------------------------------------------------------------
資料圖(DFD: Data Flow Diagram)


1.資料流圖
就是組織中資訊運動的抽象,是管理資訊系統模型的主要形式。它與對系統的物理描述無關,只是用一種圖形及與此相關的註釋來表示系統的邏輯功能,即所開發的系統在管理資訊處理方面要做什麼。
2.資料流圖由四種基本成分組成
(1)外部項(外部實體):外部項在資料流圖中表示所描述系統的資料來源和去處的各種實體或工作環節。這些實體或環節向所開發的系統發出或接收資訊。系統開發不能改變這些外部項本身的結構和固有屬性。
(2)加工(資料加工):又稱資料處理邏輯,描述系統對資訊進行處理的邏輯功能。
(3)資料儲存:邏輯意義上的資料儲存環節,即系統資訊處理功能需要的,不考慮儲存物理介質和技術手段的資料儲存環節。
(4)資料流:與所描述系統資訊處理功能有關的各類資訊的載體,是各加工環節進行處理和輸出的資料集合。

常用的三類資料沈圖基本成份的符號。
3.繪製資料流圖的主要原則
(1)明確系統介面,一張資料流圖表示某個子系統或某個系統的邏輯模型。
(2)自頂向下逐層擴充套件。在調查研究的基礎上,明確所描述的系統與各部實體的資訊聯絡。繪出最高層的資料流圖——關聯圖。在關聯圖中,所描述的系統當作一個數據加工項,著重描述系統與外部實體的聯絡。然後確定系統的幾個主要的綜合性的邏輯功能,繪
制頂層資料流圖。其中每個邏輯功能由一個數據加工符號描述。頂圖可進一步分解,其中某些或者所有的資料加工項可分解為數個數據加工項,這樣就形成第一層資料流圖。依次逐層向下擴充套件,直到最底層的資料流圖表示了所有具體的資料加工功能和輸入輸出關係。
(3)合理佈局。資料流圖各種符號買佈局合理,分佈均勻、整齊、清晰,使讀者一目瞭然。
 (4)資料流圖只反映資料流向,資料加工和邏輯意義上的資料儲存。
 (5)資料流圖繪製過程,就是系統的邏輯模型的形成過程,必須始終與使用者密切接觸。
4.繪製資料流圖的主要步驟
(1)確定所開發系統的外部項(外部實體),即系統的資料來源和去處。
(2)確定整個系統的輸出資料流和輸入資料流,把系統作為一個加工環節,畫出關聯圖。一般應把資料來源置於圖的左側,資料去處置於國的右側。
(3)確定系統的主要資訊處理功能,按此將整個系統分解成幾個加工環節(子系統)。
(4)根據自須向下,逐層分解的原則,對上層圖中全部或加工環節進行分解。
(5)重複步驟(4),直到逐層分解結束。分解結束的標誌是:對於每一個最底層的加工,即各層資料流圖中不做進一步分解的加工,其邏輯功能已足夠簡單、明確和具體。
(6)對某圖進行檢查和合理佈局,主要檢查分解是否恰當、徹底,DFD中各成分是否有遺漏、重複、衝突之處,各層DFD及同層DFD之間關係是否正確及命名、編號是否確切、合理等。對錯誤與不當之處進行修改。
(7)和使用者進行交流,在使用者完全理解資料圖內容的基礎上徵求使用者的意見。
(8)用計算機或其它製圖,編輯工具畫出正規的資料流圖。
(9)將正規的資料流圖提交系統分析負責人複審。
5.繪製資料流圖的幾點註釋
(l)關於自須向下,逐層分解。資料流圖的繪製過程,是系統分析過程的重要組成部分,這一過程自頂向下,逐層分解,就是由系統外部至系統內部,由總體到區域性、由抽象到具體的系統邏輯模型建立過程。在資料流圖分解中,要保持各層成分的完整性與一致性。
(2)資料流必須通過加工,即送去加工或從加工環節發出。不通過加工環節的資料流不在資料流圖上表示。
(3)資料儲存環節一般作為兩個加工環節的介面來安排。
(4)命名。資料流圖上的成分一般都要命名,命名的原則為:
①名稱要反映被命名成分的真實和全部的意義;②名稱要意義明確,易理解,無歧義,不會造成錯覺和混亂;③加工的名稱一般以動詞十賓語或名詞性定語十動名詞為宜,以明確反映資訊處理的邏輯功能;④避免使用不反映實際內容的空洞詞彙;⑤進出資料儲存環節的資料流如內容和儲存者的資料相同,可採用同一名稱。
(5)編號。每個資料加工環節和每張資料流圖都要編號。按逐層分解的原則,父圖與子圖的編號要有一致性,一般子圖的圖號是父圖上對應加工的編號。如頂層圖的圖號為0,其中各加工環節按1,2,3編號,順序編號,1號加工環節分解後的子加工技1.l,1.2,1.3……,編號,依次類推。
資料流與資料儲存環節也要進行編號以便於編寫,分析與維護。編號方法原則上與加工環節的編號方法相同。為避免混淆,可在資料流與資料儲存編號的第一位數字前冠以不同的字元以示區別。如資料流符號冠以F,資料儲存符號冠以D。
同樣,下層圖上的資料流或資料儲存是由上層圖的某個成分的分解而得,則父項與子項的編號要體現資料流圖分解的完整性與一致性的原則。
(6)只畫所描述的系統穩定工作情況下的資料流圖。因而資料流圖不描述系統啟動時或結束工作時功能和資料流運動規律處於變動狀態的情況。
(7)資料流圖的侷限性。資料流圖從總體上描述系統的邏輯功能,系統內各部分的資訊聯絡及與系統外各有關事物的聯絡,反映系統中資訊運動的規律,是系統邏輯模型的主要描述形式。資料流圖清晰,明瞭,容易理解,使人對描述系統的邏輯功能和各部分的資料聯絡有一目瞭然的感覺,便於交流。但資料流圖在描述系統邏輯功能和有關資訊內容的細節方面仍存在較大的侷限性。如:①難以在資料流圖上標誌出資料流,資料儲存和加工以及外部項的具體內容;②不能反映系統中的決策與控制過程;③難以對系統中人機互動過程以及資訊的反饋與迴圈處理進行描述。
------------------------------------------------------------------------------------
資料詞典(DD:Data Dictionary)
l.資料詞典的作用
是給資料流圖上每個成分以定義和說明。
2.資料詞典描述的主要內容有:資料結構、資料流、資料元素、資料儲存、加工外部項,其中資料元素組成資料流的基本成分。
3.編寫資料詞典的基本要求
(l)對資料流圖上各種成分的定義必須明確,易理解、唯一。
(2)命令、編號與資料流圖一致,必要時可增加編碼,方便查詢檢索,維護和統計報表。
(3)符合一致性與完整性的要求,對資料流圖上的成分定義與說明無遺漏項。
(4)格式規範,風格統一,文字精煉,數字與符號正確。
注意資料字典中資料結構、資料流、資料儲存可以直接抽象出來話ER圖
------------------------------------------------------------------------------------
實體關係圖(ER圖)
ER圖就是組織中資訊運動的抽象,是管理資訊系統模型的主要形式。它與對系統的物理描述無關,只是用一種圖形及與此相關的註釋來表示系統的邏輯功能,即所開發的系統在管理資訊處理方面要做什麼。
用ERD描述資料模型能夠幫助你預先精確定義資料需求,使你能夠對以後的改動作出有效的規劃
------------------------------------------------------------------------------------
用例圖:(use case model)
use case model說明的是最核心的幾個作業,象登入、許可權管理等並不是特有的核心作業,而是公共的職能,所以不應該在use case model中出現。
再次,採購審批分得太細,一個use case就足夠了。這幾個use case可以作為“採購審批”的幾個活動。一個系統中不應該出現太多太細的use case。
一個系統的use case不應該很多,很容易看出來先後順序。如果多到需要標明先後順序的程度就不好了。
------------------------------------------------------------------------------------
業務流程圖
業務流程圖描述一個組織內部業務處理活動的內容與工作流程,是進行系統調查使用的工具之一。