每個資料流程圖的五個基本組成部分（含範例）

資料流程圖（DFD）是資訊在系統中流動方式的視覺化呈現。它關注的不是系統的外觀，而是資料如何被處理、儲存與傳輸。對於分析師與架構師而言，掌握此種符號表示法，是理解複雜工作流程的基礎，而無需陷入技術實作細節的困擾。

本指南將剖析資料流程圖的結構組成。我們將檢視構成這些圖表的五個核心元素，探討它們之間的互動方式，並提供實用範例。完成後，您將了解建立清晰、可執行系統地圖所需的結構完整性。

🧩 什麼是資料流程圖？

資料流程圖是一種以圖形方式呈現資料在資訊系統中流動的工具。與專注於控制邏輯與決策點的流程圖不同，資料流程圖專注於資料的移動。它抽象了實際的實作細節，以呈現資訊的邏輯流動。

資料流程圖具有層級結構。它從高階視圖開始，逐步深入到具體細節。這種分層方式讓利害關係人能一目了然地理解系統，同時讓開發人員能清楚看見特定的資料需求。

• 視覺清晰度： 將複雜邏輯簡化為簡單的圖形。
• 溝通： 搭建技術團隊與業務利害關係人之間的溝通橋樑。
• 分析： 協助識別瓶頸、重複或遺漏的資料路徑。

🏗️ 每個資料流程圖的五個基本組成部分

要構建一個有效的資料流程圖，必須包含五個特定元素。雖然前四個是圖形符號，但第五個是概念性要求，對於確保準確性至關重要。

1. 處理程序（轉換） 🔄

處理程序代表將輸入資料轉換為輸出資料的功能，是系統的引擎。在資料流程圖中，處理程序通常以圓角矩形或圓形表示，視符號風格而定（Yourdon/DeMarco 與 Gane/Sarson 之差異）。

關鍵特徵：

• 轉換： 處理程序必須改變資料的型態或內容。若資料進入與離開時未改變，則不是處理程序，而是資料流。
• 編號： 處理程序需編號以建立層級結構（例如：1.0、1.1、1.2）。
• 動詞命名： 名稱應以動詞開頭（例如：「計算總額」，而非「總額計算」）。

範例： 考慮一個電子商務系統。一個處理程序可能是「驗證付款」。它接收信用卡資料（輸入），並回傳核准或拒絕代碼（輸出）。

2. 資料儲存（資料倉儲） 🗄️

資料儲存是資訊被保存以供後續使用的場所。它代表資料庫、檔案、紙本檔案櫃，或任何持久化機制。關鍵的是，資料儲存不會處理資料，僅僅是儲存資料。

關鍵特徵：

• 開放式與封閉式： 數據可以流入和流出儲存區。它並非黑洞。
• 命名： 名稱應為表示內容的複數名詞（例如「客戶記錄」，而非「客戶記錄」）。
• 無處理： 不要將資料儲存區與處理過程混淆。若資料正在被修改，則屬於某個處理過程。

範例： 在圖書館系統中，「書籍庫存」 資料儲存區儲存可借閱書籍的詳細資訊。當書籍被借出或歸還時，該儲存區會被更新。

3. 外部實體（互動者） 👥

外部實體是模型系統邊界以外的資料來源或目的地。它們代表與主系統互動但不屬於其內部邏輯的人、組織或其他系統。

關鍵特徵：

• 邊界： 它們定義了系統的範圍。方框以外的任何事物都是外部實體。
• 類型： 可以是人類使用者（例如「客戶」）、其他系統（例如「銀行API」），或政府機構（例如「稅務機關」）。
• 角色： 它們提供輸入或接收輸出。它們不會為系統儲存資料。

範例： 在薪資系統中，「員工」 是一個提供工作時數並接收薪資的外部實體。

4. 資料流動（移動） 🚚

資料流動是連接處理過程、資料儲存區與外部實體的箭頭。它們代表資料的移動。資料流動必須具有描述所傳輸資料內容的名稱。

關鍵特徵：

• 方向： 流動具有單一方向。若資料雙向移動，則需使用兩個箭頭。
• 內容： 標籤必須具體明確（例如「已驗證發票」，而非僅僅「發票」）。
• 保護：資料不會消失。每個輸出都必須有對應的輸入或來源。

範例： 連接「「登入」 流程與「「使用者資料庫」 資料儲存區的箭頭應標示為「驗證請求」.

5. 資料字典（定義） 📚

雖然資料字典本身並未繪製在圖表上，但它是完整資料流程圖規格的第五個必要組成部分。它是一個中央儲存庫，用來定義圖表中使用到的每個資料元素的結構、類型和格式。若無此字典，圖表將變得模糊不清。

關鍵特徵：

• 標準化： 確保一個流程中的「客戶編號」與另一個流程中的「客戶編號」相同。
• 資料內容： 定義資料類型（整數、字串、日期）、長度與允許的值。
• 參考： 將特定的資料流連結至其詳細定義。

範例： 字典可能將「「出生日期」 定義為YYYY-MM-DD 且不得為空值。這可防止流程中出現邏輯錯誤。

📋 元件對照表

在設計階段，可使用此表格快速參考每個元件的特性。

元件	符號形狀	功能	範例標籤	語法規則
處理	圓角矩形 / 圓形	轉換資料	計算稅額	動詞 + 名詞
資料儲存	開放矩形 / 平行線	儲存資料	訂單歷史	名詞（複數）
外部實體	方形 / 矩形	來源/匯流	銀行系統	名詞（單數）
資料流	箭頭	移動資料	付款細節	名詞片語
資料字典	文件 / 清單	定義資料	資料定義	技術架構

📉 DFD細節層級

資料流程圖很少單獨繪製。它們存在於一個層級結構中，允許不同層次的抽象。理解這些層級可確保在每個階段正確應用五個組成部分。

背景圖（第0層）

這是最高層級的視圖。它將整個系統顯示為單一處理過程。它識別外部實體以及進入或離開系統的主要資料流。

• 重點：範圍與邊界。
• 組件： 1 個處理過程，3 個以上的外部實體，多個資料流。
• 細節： 未顯示資料儲存或子處理過程。

第 0 層圖（基本模型）

此圖將上下文圖中的單一處理過程分解為主要的子處理過程。它引入了第一層內部資料儲存與處理過程。

• 重點：主要功能區域。
• 組件： 所有 5 個組件皆在此出現。
• 細節： 展示系統主要部分之間的互動方式。

第 1 層圖（詳細視圖）

此層將第 0 層的處理過程分解為其組成功能。用於詳細設計與開發。

• 重點：特定邏輯與資料處理。
• 組件：細粒度的資料流與特定的資料儲存。
• 細節： 高保真度。開發人員使用。

🛠️ 設計有效圖表

建立資料流程圖（DFD）是一個迭代過程。為確保圖表持續具有用處且準確，請遵守以下結構規則。

1. 平衡性

當您將處理過程分解至較低層級時，輸入與輸出必須保持一致。若父處理過程接收「訂單資料」，子處理過程必須共同處理相同的「訂單資料」。您無法憑空創造資料或摧毀資料。

2. 命名慣例

一致性至關重要。所有組件應使用標準化的命名慣例。除非組織內普遍理解，否則避免使用縮寫。確保一個圖表中標示為「發票」的資料流，在另一個圖表中不可標示為「帳單」。

3. 避免控制流

一個常見的錯誤是將控制邏輯（if/else）混入資料流程圖（DFD）中。DFD 展示的是資料流動，而非決策邏輯。應使用決策表或流程圖來表示控制邏輯。在 DFD 中，決策點由一個根據輸入輸出不同資料流的處理程序來表示。

4. 資料儲存連接性

資料儲存必須同時具有輸入與輸出，除非它是新創建的或為歸檔資料。僅接收資料的儲存是黑洞；僅提供資料的儲存則是奇蹟（從無到有創造資料）。兩者皆違反系統邏輯。

🚧 應避免的常見錯誤

即使經驗豐富的建模者也會犯錯。檢視這些常見陷阱可節省分析階段的時間。

• 幽靈資料流：繪製沒有資料字典定義的箭頭。
• 實體直接連接：外部實體不應直接連接到其他外部實體。所有互動都必須經過系統處理程序。
• 程序間迴圈：避免無限迴圈，即程序 A 提供資料給程序 B，程序 B 再提供資料給程序 A，而中間沒有資料儲存或外部實體介入。
• 過度擁擠：若一個圖形包含超過 7 到 9 個程序，很可能過於複雜。應使用較低層級的圖形來分割視圖。
• 忽略資料字典：在未更新資料字典的情況下建立圖形，將導致後續實作時出現錯誤。

🌐 實際範例：線上訂購系統

讓我們將五個元件應用於實際情境。想像一個簡化的線上訂購系統。

外部實體

• 👤 客戶
• 🏦 支付網關

處理程序

• 1.0 接收訂單
• 2.0 處理付款
• 3.0 更新庫存

資料儲存

• 🗄️ 訂單資料庫
• 📦 庫存紀錄

資料流

• 🚚 訂單詳情（客戶 → 程序 1.0）
• 🚚 付款確認（程序 2.0 → 支付網關）
• 🚚 库存检查（流程 3.0 → 库存记录）

資料字典條目

• 訂單詳情： {訂單編號、日期、客戶名稱、項目清單、總金額}

🔗 與其他模型整合

DFD 不會孤立存在。它們通常會補充其他建模技術。

• 實體關係圖（ERD）： ERD 定義了 DFD 中所顯示的資料儲存結構。
• 狀態轉移圖： 雖然 DFD 展示資料的流動，狀態圖則顯示物件隨時間變化的狀態。
• 用例圖： 用例描述使用者互動，而 DFD 則描述這些互動背後的資料。

🎯 最佳實務總結

為確保您的資料流程圖能提供價值，請牢記以下原則。

1. 從簡單開始： 從上下文圖開始，以建立邊界。
2. 先定義資料： 繪製流程前，先更新資料字典。
3. 檢查一致性： 確保父圖與子圖在資料輸入/輸出上一致。
4. 保持整潔： 避免線條交叉，並使用一致的間距。
5. 與利害關係人共同審查： 確認邏輯流程符合業務期望。

透過嚴格應用這五個組件並遵守結構規則，您將建立一個穩健的系統開發藍圖。這種清晰性可減少模糊性，最小化重做工作，並確保最終實現與預期的資料架構一致。

請記住，DFD 是一份活文件。隨著需求變更，圖表必須演進以反映系統的新現實。定期維護圖表及其附帶的資料字典，是成熟分析過程的標誌。