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圖