🌟 簡介
在現代軟體工程與商業分析的複雜版圖中,填補技術開發人員與非技術利害關係人之間的溝通落差,始終是一項永恆的挑戰。此時,「數據流程圖 (DFD)」——一種永恆且強大的視覺建模工具,用於描繪數據在系統中的旅程。
與專注於控制流程與邏輯迴圈的流程圖不同,DFD 嚴格聚焦於數據:其來源、轉換方式、儲存位置以及最終去向。無論您正在設計龐大的電子商務平台,或是簡單的內部庫存追蹤系統,DFD 都能提供系統架構的鳥瞰視圖。

在本綜合指南中,我們將探討 DFD 的核心原則、規範它們的嚴格規則、邏輯模型與實體模型之間的差異,以及如何運用Graphviz DOT」程式碼將這些概念具象化。所提供的每個範例均包含一個系統邊界容器,以清楚區分內部系統處理程序與外部實體。
🧐 什麼是數據流程圖 (DFD)?
數據流程圖 (DFD) 以圖形方式呈現數據在商業資訊系統中的流動。它描繪了將數據從輸入來源傳輸至檔案儲存,最終生成報表並傳送至輸出目的地的相關處理程序。
DFD 通常分為兩大類別:
-
邏輯 DFD: 描述商業」數據流程。它專注於系統所執行的功能(商業活動、事件與產生的數據),而不必擔心其技術實現方式。
-
實體 DFD: 描述實作」邏輯流程。它詳細說明系統實際的建構方式,包括特定的硬體、軟體、資料庫檔案以及人工介入操作。
🎯 為何要使用 DFD?
由於其視覺上的簡潔性,DFD 成為使用者與系統設計者之間極佳的溝通工具。它們可用於:
-
描繪系統的邏輯資訊流程。
-
確定實體系統的建構需求。
-
建立人工與自動化系統的需求。
-
提供廣泛的概覽,並可擴展為層級化的詳細圖表。
🧩 數據流圖的四個基本符號
標準的數據流圖依賴於四個基本構建模塊。以下為 Graphviz 表示法,展示這些符號在定義的「系統邊界」內如何互動:系統邊界.

digraph DFD_Symbols {
rankdir=LR;
splines=true;
graph [fontname="Helvetica", fontsize=12];
node [fontname="Helvetica", fontsize=10, penwidth=1.5];
edge [fontname="Helvetica", fontsize=9, color="#555555"];
// --- 系統邊界 ---
subgraph cluster_System {
label="系統邊界(內部處理與儲存)";
style="dashed,rounded";
color="#757575";
bgcolor="#FAFAFA";
node [shape=circle, style="filled", fillcolor="#E8F5E9", color="#388E3C", width=1.2];
Process [label="1.0n處理n數據"];
node [shape=cylinder, style="filled", fillcolor="#FFF9C4", color="#FBC02D"];
DataStore [label="D1n資料庫"];
}
// --- 外部實體 ---
node [shape=box, style="filled", fillcolor="#E1F5FE", color="#0288D1"];
EntityIn [label="外部n來源"];
EntityOut [label="外部n目的地"];
// --- 流程 ---
EntityIn -> Process [label="原始數據輸入"];
Process -> DataStore [label="寫入儲存"];
DataStore -> Process [label="讀取數據"];
Process -> EntityOut [label="格式化報告"];
}
1. 處理
處理接收輸入數據,對其進行操作,並產生內容或形式不同的輸出。
-
符號表示: 圓形(Yourdon-DeMarco)或圓角矩形(Gane-Sarson)。在 Graphviz 中,我們使用
shape=circle. -
命名規則: 動詞後接單數名詞(例如:計算佣金, 驗證訂單).
-
規則: 每個處理必須至少具有一個輸入數據流和一個輸出數據流。
2. 數據流
數據流是數據從一個組件流向另一個組件的管道。它可以代表單一數據元素或複雜的數據結構。
-
符號表示: 帶箭頭的有向線(
->在 Graphviz 中)。 -
規則:所有資料流程必須開始並結束於處理步驟、外部實體或資料儲存庫。資料無法自行轉換。
3. 資料儲存庫(儲存庫)
資料儲存庫代表系統必須保留資料以供後續使用的狀況。
-
符號:開放式矩形或圓柱體。在 Graphviz 中,
shape=cylinder是理想的選擇。 -
規則:資料儲存庫必須連接到處理流程。它至少需要一個輸入流程(寫入)和一個輸出流程(讀取)。
4. 外部實體(終端)
外部實體是指提供資料給系統或接收系統輸出的個人、部門、外部組織或外部系統。它們存在於系統邊界之外。
-
符號:正方形/矩形。在 Graphviz 中,
shape=box. -
規則:它們不處理資料;僅負責產生或消耗資料。
🚫 資料流程規則與常見錯誤
在設計資料流程圖(DFD)時,必須嚴格遵守某些邏輯規則,以確保圖表能代表實際可行的情況。
「資料流程的拇指法則」
資料無法在實體之間、資料儲存庫之間,或從實體直接到資料儲存庫之間直接移動,而必須經過一個處理流程。資料無法自行轉換。
| ❌ 錯誤流程 | ✅ 正確流程 | 描述 |
|---|---|---|
| 實體 ➔ 實體 | 實體 ➔ 處理程序 ➔ 實體 | 實體無法在不經過任何處理的情況下向另一個實體提供資料。 |
| 實體 ➔ 資料儲存區 | 實體 ➔ 處理程序 ➔ 資料儲存區 | 資料無法在不經過處理的情況下直接從實體移動到資料儲存區。 |
| 資料儲存區 ➔ 資料儲存區 | 資料儲存區 ➔ 處理程序 ➔ 資料儲存區 | 資料無法在不經過處理的情況下直接從一個資料儲存區移動到另一個資料儲存區。 |
| 資料儲存區 ➔ 實體 | 資料儲存區 ➔ 處理程序 ➔ 實體 | 資料無法在不經過處理程序進行格式化的情況下,直接從資料庫傳送給實體。 |
邏輯錯誤(處理步驟錯誤)
-
⚫ 黑洞: 處理程序具有輸入流程,但 沒有輸出流程。(資料消失。)
-
✨ 奇蹟: 處理程序具有輸出流程,但 沒有輸入流程。(資料憑空產生。)
-
⚪ 灰洞: 處理程序的輸出大於 其輸入的總和。(例如,僅輸入使用者 ID 時卻輸出完整的使用者個人資料,且未從資料儲存庫讀取資料)。
🏗️ 由上而下的分解(分層)
由上而下的分解,或「分層」,涉及從廣泛的概覽開始,並擴展為詳細圖表的層級結構。在層級之間移動時,「平衡」必須發生:子圖表的輸入與輸出必須與其代表的父流程的輸入與輸出完全一致。
第 0 層:情境圖
情境圖是資料流程圖(DFD)的最高層級。它僅包含「單一流程」,代表整個系統。它定義了系統邊界及其與外部世界的互動方式。它「不包含任何資料儲存庫。

digraph Context_Diagram {
rankdir=LR;
graph [fontname="Helvetica", fontsize=12];
node [fontname="Helvetica", fontsize=11];
edge [fontname="Helvetica", fontsize=9, color="#555555"];
subgraph cluster_Level0 {
label="情境圖:大學註冊系統(第 0 層)";
style="dashed,rounded";
color="#0288D1";
bgcolor="#F0F8FF";
node [shape=circle, style="filled", fillcolor="#E8F5E9", color="#388E3C", width=2.0];
System [label="0.0n大學n註冊n系統"];
}
node [shape=box, style="filled", fillcolor="#E1F5FE", color="#0288D1"];
Student [label="學生"];
Admin [label="管理人員"];
Bank [label="銀行n閘道"];
Student -> System [label="課程選擇 / 身份證號"];
System -> Student [label="課程表 / 收據"];
Admin -> System [label="課程更新 / 名冊"];
System -> Admin [label="註冊報告"];
System -> Bank [label="付款請求"];
Bank -> System [label="交易狀態"];
} 第 1 層資料流程圖
情境圖中的單一流程會被「展開」,以顯示主要的內部流程、資料儲存庫及內部資料流。請注意,外部實體及其輸入/輸出完全保持不變(平衡)。

digraph Level1_DFD {
rankdir=LR;
graph [fontname="Helvetica", fontsize=12];
node [fontname="Helvetica", fontsize=10];
edge [fontname="Helvetica", fontsize=8, color="#555555"];
subgraph cluster_Level1 {
label="第 1 層資料流程圖:大學註冊系統";
style="dashed,rounded";
color="#388E3C";
bgcolor="#F5FFFA";
// 流程
node [shape=circle, style="filled", fillcolor="#E8F5E9", color="#388E3C"];
P1 [label="1.0n驗證n學生"];
P2 [label="2.0n檢查n可用性"];
P3 [label="3.0n註冊n學生"];
P4 [label="4.0n處理n付款"];
// 資料儲存庫
node [shape=cylinder, style="filled", fillcolor="#FFF9C4", color="#FBC02D"];
D1 [label="D1n學生n記錄"];
D2 [label="D2n課程n目錄"];
}
// 外部實體
node [shape=box, style="filled", fillcolor="#E1F5FE", color="#0288D1"];
Student [label="學生"];
Bank [label="銀行n閘道"];
// 資料流
Student -> P1 [label="學生身份證號"];
D1 -> P1 [label="學生狀態"];
P1 -> P2 [label="有效身份證號"];
Student -> P2 [label="課程選擇"];
D2 -> P2 [label="座位可用性"];
P2 -> P3 [label="已確認座位"];
P3 -> D1 [label="更新註冊"];
P3 -> P4 [label="學費"];
Student -> P4 [label="信用卡資訊"];
P4 -> Bank [label="授權請求"];
Bank -> P4 [label="授權核准"];
P4 -> Student [label="收據 / 課程表"];
} 第 2 層資料流程圖
如果來自第一層的流程高度複雜,則將其提取並展開為第二層數據流圖(DFD)。此過程持續進行,直到流程達到「功能原語」階段(即無需進一步分解)。
⚖️ 邏輯式與實體式數據流圖
邏輯式數據流圖著重於「業務」,實體式數據流圖則著重於「技術與執行.
邏輯式數據流圖的優點
-
穩定性:基於業務事件,使其不受技術變革影響。
-
溝通性:非技術專案利害關係人也能輕易理解。
-
維護性:業務功能很少像軟體架構那樣發生劇烈變化。
實體式數據流圖的優點
-
技術清晰度:區分手動人類流程與自動化軟體腳本。
-
執行順序:顯示嚴格的執行順序(例如:「更新資料庫」必須發生在「產生 PDF」之前)。
-
實作細節:指定實際檔案名稱、API 端點、臨時交易資料表及硬體控制。
🛒 案例研究:超市結帳
以下為兩張圖表,代表完全相同的業務事件,分別以邏輯式與實體式建模。
1. 邏輯式數據流圖(業務觀點)
著重於概念:商品加總、處理付款,並提供收據。

digraph Logical_Grocery {
rankdir=LR;
graph [fontname="Helvetica", fontsize=12];
node [fontname="Helvetica", fontsize=10];
edge [fontname="Helvetica", fontsize=9, color="#555555"];
subgraph cluster_LogicalSystem {
label="超市結帳(邏輯模型)";
style="dashed,rounded";
color="#388E3C";
bgcolor="#F5FFFA";
node [shape=circle, style="filled", fillcolor="#E8F5E9", color="#388E3C"];
P1 [label="1.0n計算n總額"];
P2 [label="2.0n處理n付款"];
P3 [label="3.0n生成n收據"];
node [shape=cylinder, style="filled", fillcolor="#FFF9C4", color="#FBC02D"];
D1 [label="D1n每日n銷售"];
}
node [shape=box, style="filled", fillcolor="#E1F5FE", color="#0288D1"];
Customer [label="顧客"];
Customer -> P1 [label="商品與價格"];
P1 -> P2 [label="總金額"];
Customer -> P2 [label="付款"];
P2 -> P3 [label="交易詳情"];
P2 -> D1 [label="更新銷售記錄"];
P3 -> Customer [label="收據"];
}
2. 實體數據流圖(技術視圖)
詳細說明條碼掃描器、UPC 資料庫、臨時會話檔案以及實體熱感印表機。

digraph Physical_Grocery {
rankdir=LR;
graph [fontname="Helvetica", fontsize=12];
node [fontname="Helvetica", fontsize=10];
edge [fontname="Helvetica", fontsize=9, color="#555555"];
subgraph cluster_PhysicalSystem {
label="超市結帳(實體模型)";
style="dashed,rounded";
color="#D32F2F";
bgcolor="#FFF5F5";
node [shape=circle, style="filled", fillcolor="#FFEBEE", color="#D32F2F"];
P1 [label="1.1n掃描n條碼"];
P2 [label="1.2n計算n小計"];
P3 [label="2.1n處理n信用卡"];
P4 [label="3.1n列印n收據"];
node [shape=cylinder, style="filled", fillcolor="#FFF9C4", color="#FBC02D"];
D1 [label="UPCn主資料庫"];
D2 [label="Tempn會話檔案"];
D3 [label="POSnSQL 資料庫"];
}
node [shape=box, style="filled", fillcolor="#E1F5FE", color="#0288D1"];
Customer [label="顧客"];
Stripe [label="Stripe API"];
Printer [label="熱感n印表機"];
Customer -> P1 [label="實體商品"];
P1 -> D1 [label="查詢 UPC 代碼"];
D1 -> P1 [label="價格資料"];
P1 -> P2 [label="商品資料"];
P2 -> D2 [label="儲存小計"];
P2 -> P3 [label="應付總額"];
Customer -> P3 [label="信用卡刷卡"];
P3 -> Stripe [label="授權請求"];
Stripe -> P3 [label="授權回應"];
P3 -> P4 [label="核准交易"];
P3 -> D3 [label="寫入交易"];
P4 -> Printer [label="列印指令"];
Printer -> Customer [label="紙質收據"];
}
📏 開發完美數據流圖的指南
為確保您的圖表保持可讀性與邏輯嚴謹,請遵循以下產業標準指南:
-
情境圖規則: 第 0 層圖表必須能容納於單頁內。單一流程應以整個系統的名稱命名(例如:訂單處理系統).
-
唯一名稱: 在所有層級的每一組符號中,必須使用唯一的名稱。整個數據流圖層級中,只能有一個名為
顧客的實體。 -
禁止線條交叉: 避免數據流線交叉。若圖表過於複雜,請限制流程數量,或使用標註星號 (*) 的重複符號(如重複的外部實體)以保持路由清晰。
-
7 ± 2 法則: 人類心智一次可舒適處理 5 至 9 個項目。單頁數據流圖不應包含超過 7 至 9 個流程符號 的流程符號。若超過此數,請進一步分解。
-
編號慣例:為流程使用層級參考編號。
-
第 0 層:
0 -
第 1 層:
1.0,2.0,3.0 -
第 2 層:
1.1,1.2,2.1,2.2 -
第 3 層:
1.1.1,1.1.2
-
🏁 結論
資料流程圖仍是視覺化系統架構、定義需求以及將業務目標與技術執行對齊的最有效方法之一。透過嚴格遵守資料流程圖規則——避免黑洞、確保分層平衡,以及區分邏輯意圖與實體實現——團隊可在撰寫任何程式碼之前,預防昂貴的架構缺陷。
此外,透過使用宣告式繪圖工具,例如Graphviz DOT工程團隊可將資料流程圖視為程式碼。這使得系統架構能夠進行版本控制、同行評審,並與軟體本身自動生成,確保文件從不與實際系統邊界脫節。無論您是在繪製簡單的超市結帳流程,還是全球電子商務網路,資料流程圖的原則都能提供清晰且無可辯駁的資料旅程地圖。
參考資料
-
Visual Paradigm 的 AI Gane 與 Sarson 資料流程圖產生器:說明 Visual Paradigm 的 AI 工具如何從文字描述產生 Gane-Sarson 資料流程圖。
-
使用 Visual Paradigm 建立資料流程圖的逐步指南:提供使用 Visual Paradigm 線上工具建立資料流程圖 (DFD) 的教學,涵蓋從註冊到分享的完整流程。
-
如何建立資料流程圖 (DFD)?:涵蓋 DFD 的定義、目的以及主要類型(實體與邏輯)的指南。
-
Visual Paradigm Online 初學者指南:SSADM 風格的資料流程圖:使用 Visual Paradigm Online 建立 SSADM 風格資料流程圖的入門指南。
-
資料流程圖 (DFD) 完整指南:揭開資訊流程的神秘面紗:DFD 的概覽,詳細說明其元素,並解釋為何 Visual Paradigm 是建立 DFD 的合適工具。
-
掌握資料流程圖:使用 Visual Paradigm 的逐步指南:一本實用指南,透過範例與範本教導 DFD 建立,並包含如線上購物系統等案例研究。
-
理解邏輯 DFD 與實體 DFD:何時需要以及為何需要:解釋邏輯與實體資料流程圖之間的差異、目的以及適用的使用情境。
-
Visual Paradigm Online 初學者指南:資料流程圖 (DFD):一份對初學者友善的教學,逐步引導使用 Visual Paradigm Online 建立 DFD。
-
DFD 檔案庫 – Visual Paradigm 指南:一組關於 DFD 主題的文章合集,涵蓋 AI 產生器、驗證、平衡與層級等內容。
-
Visual Paradigm Online 資料流程圖 (DFD) 入門指南:詳細說明建立 DFD 的逐步流程,包括其關鍵元件以及如何使用範本。
-
使用最佳 DFD 工具繪製 DFD:探討資料流程的圖形表示,詳細說明邏輯與實體 DFD 的差異,並分析各類型的優勢。
-
Visual Paradigm Online 初學者指南:資料流程圖 (DFD):印尼語初學者指南,介紹 DFD 的元件以及使用 Visual Paradigm Online 建立 DFD 的逐步流程。











