數據庫設計理論及應用（3）——需求分析及數據流圖

http://blog.csdn.net/46539492/article/details/2901707

數據庫設計理論及應用（3）——需求分析及數據流圖

做者：最後一隻恐龍 發表時間：2007-6-26

 

該系列計劃包括5部分：完整性約束理論及應用、範式理論及應用、需求分析、概念結構設計、邏輯結構設計。本文是第三部分，介紹需求分析中如何藉助數據流圖發現存儲對象的方法。

 

1．引言

無論對數據庫設計仍是對系統設計來講，需求分析都是第一步。需求的目的就是搞清楚用戶要作什麼，若是需求作的仔細，能夠在後面的設計和實現中少作不少無用功，其重要性是不言自明的。

需求分析的方法在軟件工程中都有說明，無論哪一種方法，最重要的都是與用戶的溝通和交流，引導用戶正確的確認問題。作需求分析須要有點心理學的知識，這裏我就不囉嗦了。

本文的重點在於如何經過需求分析，找出須要存儲的數據。

2．工具選擇

　　對於與用戶的交流來講，需求分析階段比較直觀的工具是UML中的用例圖。其優勢很是明顯，就是用圖形方式表示功能和角色，需求分析人員和用戶都能很是容易的讀懂並以此交流（固然我說的是草圖設計，不是藍圖設計或基於程序的設計）。

　　那麼咱們看一下UML是否能很好的支持數據庫設計——這點要從UML設計過程分析。有了用例圖，咱們獲得的是系統的功能需求，並且仔細的話，咱們能夠作的很好。那麼下一步，通常是經過時序圖（也有翻譯成順序圖或序列圖的）發現系統中的對象。這種圖向用戶簡單說明也很容易理解和交流。發現了系統中的對象後，就能夠進行類圖的設計了。類圖是系統中對象的抽象，通常能夠與編碼實現的類和對象對應起來。

　　這是一個完美的設計過程，方便交流，還容易轉換爲編碼。可是，咱們從這個過程也能夠看到，UML沒有涉及數據庫的設計過程。那麼是否是能夠把在時序圖中發現的對象轉換爲數據庫實體（表）呢？咱們分析一下這些對象的特色，會發現這些對象對應的是咱們設計的應用程序內存中保存的對象，而內存中的對象，有些能夠簡單的和數據庫表對應，但大部分倒是幾個表的組合——對應的是數據庫中的視圖。

　　對用戶來講，表和視圖是沒必要區分的，用戶只關心看到的數據，這也是UML與用戶容易交流的一個緣由。但對於數據庫設計人員來講，要使數據冗餘儘可能少，使編碼時更新數據儘量侷限在局部範圍內，就必須從新設計對象的存儲方式，把表和視圖區分開來。這一步的工做還包括視圖如何分解爲基本表的過程。這項工做沒有什麼方法值得信賴，只能依靠設計人員的經驗和技巧了。這樣獲得的結果也很難讓人信賴。

經過以上分析，咱們能夠了解，UML支持系統設計是很是好的工具，但在數據庫設計中，其支持明顯不足。

UML爲何難以支持數據庫設計呢？主要緣由在於UML是以功能爲中心的，而不是以數據爲中心的。這樣我們須要找個以數據爲中心的工具，這就是數據流圖法。

數據流圖表達了數據和處理的過程，其繪製老是圍繞數據如何加工以及如何流轉的，所以，它能夠很是好的支持數據庫的設計。

補充一點：有些教科書中把數據流圖的繪製放到概念結構設計中，另外一些則放到需求分析中。我的意見，數據庫中存儲的對象不是設計出來的，而是從用戶那裏得到的，因此我傾向於把數據流圖歸到需求分析過程當中。無論哪一種分法，在作需求時就須要作數據流圖，以便把實體中的屬性（字段）搞清楚。

3．需求分析的方法和過程

　　肯定了工具後，就能夠按照教科書上的方法和過程進行分析了。你們不要對教科書上呆板的敘述嗤之以鼻，那但是無數人經驗和教訓的總結，是有至關高的參考價值的。另外一方面，也不要紙上談兵，要用心去感覺，思考這些方法如何使用。

需求分析的方法通常有跟班做業、開調查會、請專人介紹、詢問、設計調查表請用戶填寫、查閱記錄等。通常須要根據具體狀況選用一種或多種方法，這裏我就不羅嗦了。

需求分析的過程通常是：

（1）       調查組織機構整體狀況；

（2）       熟悉業務活動；

（3）       明確用戶需求；

（4）       肯定系統邊界。

這裏容易忽略的是第一個步驟，主要是由於這個步驟太簡單，看上去彷佛也無關緊要。但在實際需求分析中，這個過程很重要，這點要從組織機構的做用提及。一個單位的部門，不是由於有幾我的，而後把他們組織起來就造成的。而是由於業務緣由，須要有一個部門專門負責某項工做，而後才組織人手造成的部門。所以在實際系統中，部門是完成某項工做的核心，一個部門通常對應一個角色。若是把組織機構搞清楚了，整體業務邏輯基本也就清楚了，這樣作能夠起到事半功倍的效果。

其它幾點的做用就沒必要說明了。

數據流圖能夠用做明確用戶需求和肯定系統邊界兩個步驟中，幫助設計者瞭解數據如何流動，並發現須要存儲的對象。

4．數據流圖圖元

咱們使用Visio 2003做爲繪圖工具。由於咱們使用數據流圖僅作草圖設計，所以選擇「軟件」中的「數據流圖模型」模版進行繪製。

數據流圖語義比較簡單，圖元一共四個，圖4.1爲Visio中的表示法。

 

l        

圖4.1 數據流圖圖元

接口：用直角矩形表示。這裏接口能夠是與其它信息系統的接口，也能夠是角色（人機接口）。

 

l         進程：通常用橢圓表示，但Visio中用圓角矩形表示，多是考慮橢圓中能夠容納的字比較少的緣由。數據流圖中的矩形通常表示一個功能模塊或一個過程，對應一個或一組動做。

l         數據存儲：用右邊開口的矩形表示，表示數據庫中存儲的對象。另外在數據流圖中，若是一個存儲過程在同一個圖中出現屢次（主要是防止畫的線交叉），還常常在在矩形左側向右一點加個豎直線表示，但Visio中沒有作區別。

l         數據流：用帶箭頭的直線表示，表示數據的流動方向。

5．數據流圖舉例

這是教科書上的一個例子（王珊，《數據庫系統概論》），某廠管理信息系統包括三個模塊：銷售管理子系統、勞動人事管理子系統和物資子系統。其中銷售子系統的基本需求是：

（1）       處理顧客和銷售員送來的訂單。

（2）       工廠是根據定貨（訂單）安排生產的。

（3）       交出貨物同時開出發票，並記入應收賬款。

（4）       收到顧客付款後，根據發票存根和信貸狀況進行應收賬款處理。

這個需求太籠統了，咱們逐步細化這個需求，並採用數據流圖做爲輔助分析手段。

5.1 銷售管理子系統第一層數據流圖

 

 

圖5.1 第一層數據流圖

該圖的繪製依據如下需求（能夠將下面的描述與圖形對比以理解圖形）：

 

（1）       不論是顧客仍是銷售員送來的訂單，發起者都是顧客，銷售員只是顧客的一個代理，所以系統都認爲是顧客送來的訂單。

（2）       顧客送來訂單後，訂單數據進入1.0（送進訂單）模塊進行處理。這裏編號爲1.0是爲了後續分析方便，若是這個模塊還能細分處其它子功能，則編號爲1.n。

（3）       主管部門在送進訂單模塊對訂單進行覈對，主要覈對價格是否正確，以及顧客帳目情況（是否拖欠了太多應收賬款），所以要參考產品描述信息和應收賬款信息。這裏咱們就發現了兩個須要存儲的對象。

（4）       主管部門審覈後，告知1.0模塊（通常是點個按鈕），無論批准與否，都要通知顧客。

（5）       已批准訂單送入2.0模塊進行處理。

（6）       2.0模塊首先將訂單信息保存，存入「訂單記錄本」。同時生成生產通知單，發送給生產部門以進行生產。

（7）       生產部門的生產是一個封閉過程，該系統沒法控制。生產完成後，開具發票。

（8）       開發票時，一方面要調整應收賬款（財務術語，只要開了發票，就是應收賬款；付款後衝抵掉應收賬款）；另外一方面，生成包裝通知單（包括髮票、產品說明等、配件說明等）發送給顧客。

（9）       顧客結算數據時，使用支付過帳模塊（4.0），調整應收賬款。

（10）   另外系統須要提供一個應收賬款輔助模塊，用於：爲主管部門生成應收賬款報表；若實際業務往來中出現漏操做的狀況，手工調整未付差額，並將財務變更通知顧客。

圖中兩個「應收賬款」是同一個數據存儲，畫到一塊兒數據線會出現大量交叉的狀況，因此畫了兩個。

下面咱們看一下各個功能模塊是否能夠細分。

5.2 接收訂單

這個對應第一層數據流圖的1.0模塊，對顧客來講，在第一層數據流圖中名爲「送進訂單」，但對於咱們的系統來講，稱爲「接收訂單」更確切一些。

這一步的過程是：主管部門拿着用戶（或銷售員）填寫的訂單，調出價格信息和該顧客帳目信息進行覈對，決定是否批准，而後將訂單的某一聯反饋給顧客（畢竟顧客沒有操做這個系統的權限，只好手工處理了）。對已批准的訂單，送入下一步進行處理（2.0）。

 

（1）      

圖5.2 接收訂單

顧客送進訂單數據後，首先覈對價格，這時要參考「產品描述」裏面存儲的價格信息。

 

（2）       價格覈對後，覈對顧客帳目情況，看一下該顧客是否拖欠了太多款項，這時要參考「應收賬款」信息。

（3）       帳目已覈對的訂單，將價格和帳目的核對狀況，發送給主管部門，由主管部門決定是否批准。

（4）       不論是否批准，都要通知顧客。

（5）       已批准訂單送入2.0（處理訂單）。

5.3 處理訂單

已批准的訂單進行登記，並分配工種（如車工、鉗工、焊工、電工等），生成生產通知單發送給生產部門安排生產。同時生成待完成定貨清單，供生產部門參考。

生產完成後由生產部門將數據送入下一環節：開發票（3.0）。

 

圖5.3 處理訂單

5.4 開發票

 

圖5.4 開發票

生產完成後，開具發票。開發票後合同額即記入應收賬款，同時將發票信息存入發票主清單，並由系統生成包裝通知單信息提供給顧客。

 

開發票後將發票分配一個發票號（固然如今的發票都是全國統一編號，每張發票事先都已經編好號了，呵呵），並記人發票記錄本。

 

5.5 支付過帳

顧客結算時有兩種方式：支付貨款或信貸。

支付貨款後，系統記入貸方餘額，具體操做是調整應收賬款信息。若是信貸，須要根據有個審批環節，若是批准，則記入借方餘額，操做也是調整應收賬款（彷佛這個地方不用調整，由於開發票時已經調整了）。

 

5.6 提供應收賬款

這步不能進一步細化，已經完成。 

5.7 小結

經過以上數據流圖，咱們明確了用戶需求，並發現了幾個要存儲的對象。在下一節，咱們考慮如何用發現的這些數據存儲構造E-R圖