活著繞不過修行，越簡單越複雜，然後有可能是越複雜，越簡單。DBA 做久了，貌似兩個路徑，運維DBA， 開發DBA，實際上還有另一條路，就是將其合二為一，讓你自身昇華一次，成為一個數據庫架構師。那在軟件項目中，除了去給硬件層次，或數據庫層次做一個架構的規劃以外， 從軟件的開發角度，作為DB的層次也可以梳理和參與甚至是貼合軟件來做一些事。
今天就從DFD 切入，兩手都要抓，兩手都能crash點的角度來看看。DFD 是什麼，DFD 是data -flow diagram 數據流圖，在開發軟件的過程中，有需求，需求分析，有各種軟件開發的流程圖，但從DB的點位出發，除了在數據庫選型以及表設計去符合你的軟件項目需求，在軟件的需求階段，你也要根據軟件設計的業務需求，來畫出從DB 觀點出發的 DFD 數據流圖。軟件人員可能會問，這有必要嗎，因為從軟件設計的角度很多企業是沒有這個“項目”的。
用大白話講，DFD是將你軟件項目中的數據從哪裡來，數據到哪裡去，數據在哪個節點有存儲，數據在整體項目的流轉，以數據庫DB的視角來進行一個描繪，很邏輯的事情，好處也是有的，1 避免在設計表的時候，忘記某些數據表的設計之間的關聯性，2 避免設計表時定位不清，造成一個表多個用途或多個表一個用途，最終導致 “一夫多妻“， 或者“一妻多夫”的可能性。
而這個圖應該是在 UML 圖之前要有的，a way of visualizing software systems before UML diagrams. DFD 也是有兩個種風格，
1 Yourdon&Coad 更加貼近系統分析和設計
2 Gane & Sarson 更貼近信息系統的可視化
通過這兩種方式來描述 數據的存儲，數據流， 外部實體。在繪製 DFD的時候會以四種圖形來描述DFD的四個基本概念， 1 外部實體 2 過程 3 數據存儲 4 數據流 來組成DFD，其中是可以用不同的圖形來表達這四種實體的不同。
下面就以一個簡單的訂單系統作為 DFD 的入門
在一個訂單發貨系統裡面，首先我們根據常識性的知識，外部的實體會存在
1 客戶
2 庫存
3 快遞公司
4 管理
以及最後的我們的處理任務的process 訂單發貨處理系統，建模的最簡單的DFD圖，其中包含了系統中必要的實體，和流程，圖看似簡單，但是確定系統邊界的方法。表名系統和上下文之間的關係，也是DFD的上下文數據流程圖。也可以叫 0 LEVEL 圖
在大方向確認的情況線下，就開始規劃 LEVEL 1 的數據流圖了，將LEVEL 0 的圖細化。
從下圖我們可以知道，發貨系統的數據源來自於訂單，實體有客戶，快遞公司，倉庫，審批管理人， 而數據的存儲位置有 庫存，訂單，涉及兩個系統處理過程，訂單發貨處理過程，與訂單出庫單生成過程
其實在整個DFD圖的產生的過程中就梳理了當前系統設計的數據流是否順暢，是否貼近實際業務的信息流轉。
在畫DFD圖的時候，需要注意以下幾點：
1 過程模塊應該使用動作，或動態的名詞來表示--動的一個狀態
2 數據存儲位置至少應該與一個操作或者進程相關聯
3 外部的實體也需要至少一個與操作或進程相關
4 數據存儲不應該與外部實體有關
5 每個圖必然有數據的流入和流出
6 所有的圖必須以一個外部實體開始，以一個外部實體結束
7 外部實體之間不存在數據流轉
實際上DFD圖，是一個簡單到複雜的過程將數據流，數據流轉分層的進行分析繪製，將某個軟件開發中的東西細化的過程。下面就是DFD的分層圖
頂層數據流圖只包含一個過程，表示整個系統
中層數據流圖是對父層數據流中某個過程進行細化
底層是細化的過程，細化到不能在細化
OK 就先寫到這，也編不出什麼來了，如果寫錯了還請軟件方面的大仙們指正，感謝。
閱讀更多 Austin的數據庫 的文章
