DFD 與 ERD：在系統設計中何時使用每一種

設計一個複雜的軟體系統需要明確的資料流動與儲存位置地圖。若無結構化的方法，系統架構可能變得脆弱、難以維護，且容易產生邏輯錯誤。系統工程中最基礎的兩種建模技術分別是資料流程圖（DFD）與實體關係圖（ERD）。雖然兩者都具有可視化的關鍵功能，但各自關注系統中根本不同的面向。

理解這兩種模型之間的差異不僅僅是學術上的練習；對系統架構師、業務分析師與開發人員而言，這是一項實際上的必要條件。在開發的錯誤階段使用錯誤的模型，可能導致溝通誤解、資料庫效率低下，或業務邏輯崩潰。本指南探討了每種圖表類型的細微差別、其特定組成元件，以及何種策略性情境下其中一種會優先於另一種。

理解資料流程圖（DFD） 🔄

資料流程圖專注於資料在系統中的流動。它可視化資訊如何被處理、轉換與儲存。DFD 不關注物理實作細節或流程的時間順序，而是提供資訊邏輯流動的高階視圖。

DFD 的核心元件

• 外部實體： 這些代表系統邊界以外的資料來源或目的地。它們可能是使用者、其他系統或組織。它們會啟動或接收資料，但在本模型的脈絡中不會處理資料。
• 流程： 以圓角矩形表示，這些是將輸入資料轉換為輸出資料的活動。流程會改變通過其的資訊狀態或形式。每個流程都必須至少有一個輸入與一個輸出，這一點至關重要。
• 資料儲存： 這些是資料被儲存以供後續使用的儲存庫。在 DFD 中，它們代表檔案、資料庫或歸檔。它們並不代表特定技術，僅表示持久性儲存的存在。
• 資料流： 以箭頭表示，這些顯示資料移動的方向。每一個資料流都應標示出所傳輸資料封包的名稱。資料流連結實體、流程與儲存。

抽象層級

DFD 通常以層級方式建立，以管理複雜度：

• 上下文圖（第 0 層）： 這是最高階的視圖。它將整個系統視為單一流程，並識別所有與其互動的外部實體。它明確定義了系統的邊界。
• 第 1 層圖： 它將上下文圖中的單一流程分解為主要的子流程。它提供了系統內部如何處理資料的更多細節，而不會陷入邏輯細節中。
• 第 2 層及更高層： 這些圖表將第 1 層中的特定流程進一步細分。此層級通常用於複雜模組，其中需要嚴謹定義特定的資料轉換。

何時應用 DFD

DFD 在需求收集與功能設計階段最為有效。它幫助利害關係人理解系統行為，而不會被技術限制所干擾。它特別適用於：

• 識別遺漏的資料需求。
• 向非技術利害關係人傳達業務流程。
• 定義專案範圍。
• 透過識別敏感資料進入與離開的位置，分析資訊安全。

理解實體關係圖（ERD） 🔗

雖然 DFD 追蹤資料的移動，但實體關係圖則專注於結構。ERD 是一種概念模型，用於定義資料庫內的資料需求與關係。它描述資料的靜態特性，確保資料完整性與規範化。

ERD 的核心組件

• 實體：以矩形表示，這些是現實世界中的物件或概念，資料會儲存在其中。範例包括「客戶」、「訂單」或「產品」。實體是資料結構的構建模塊。
• 屬性：這些是實體的屬性或特徵。通常列在實體框內或與其相連。屬性定義了具體的資料點，例如「客戶編號」或「訂單日期」。某些屬性作為主鍵，唯一識別一筆記錄。
• 關係：以菱形或線條表示，這些定義了實體之間的互動方式。關係表示一個實體中的記錄與另一個實體中的記錄相關聯。
• 基數：這定義了實體之間的數量關係。常見的基數包括一對一（1:1）、一對多（1:N）和多對多（M:N）。理解基數對於防止資料重複至關重要。

規範化與資料完整性

ERD 通常是規範化的起點。規範化是組織資料以減少重複並提升完整性的過程。ERD 可幫助在建立實際資料表之前，視覺化邏輯結構。它確保：

• 資料不會無謂地重複。
• 參考完整性得以維持（例如，訂單無法在沒有客戶的情況下存在）。
• 如唯一性與必填欄位等約束條件清晰明確。

何時應用 ERD

ERD 在資料庫設計階段至關重要。它們彌補了業務需求與技術實現之間的差距。它們最適合在以下情況使用：

• 設計關係型資料庫的結構。
• 定義資料約束與驗證規則。
• 確保應用程式中資料的一致性。
• 規劃資料檢索效率與索引策略。

關鍵差異一目了然 🆚

將這兩個模型並列比較，能突顯它們截然不同的目的。儘管它們在視覺複雜度上可能看似相似，但其設計意圖卻有顯著差異。

何時應優先考慮資料流程建模 📉

在某些特定情境下，資料流程圖（DFD）會成為系統設計的主要工具。當業務邏輯是系統中最複雜的部分時，優先選擇DFD通常是正確的途徑。

• 工作流程自動化： 如果系統涉及複雜的核准鏈、狀態變更或多重步驟的交易，資料流程圖（DFD）能明確釐清操作順序，並協助識別流程中的瓶頸。
• 外部整合： 當系統與許多外部API或舊有系統互動時，資料流程圖（DFD）能幫助標示資料的進入與離開點，避免系統間交接時發生資料遺失。
• 安全審計： 安全團隊經常使用資料流程圖（DFD）追蹤敏感資料在應用程式中的流動路徑，並識別需要加密或強制執行存取控制的節點。
• 業務流程再造： 在優化現有工作流程時，資料流程圖（DFD）可作為基準。您可將「現狀」流程與「未來目標」流程進行比較，以衡量改善程度。

在這些情況下，過早著重於實體關係圖（ERD）可能會掩蓋系統的邏輯。資料庫即使設計得完美無缺，若流程邏輯有誤，應用程式仍無法滿足使用者需求。

何時應優先考慮資料結構建模 🏗️

相反地，有些情境下資料的完整性與結構是成功關鍵。當資料量、關係與約束是主要推動力時，實體關係圖（ERD）應優先考量。

• 資料密集型應用： 在分析平台或資料倉儲等系統中，資料的結構至關重要。ERD 確保資料結構能支援複雜的查詢與聚合。
• 舊系統遷移： 在將資料從舊系統遷移到新系統時，理解現有的關係至關重要。ERD 有助於將舊的資料表映射到新的結構，確保資料不會遺失或損壞。
• 合規與治理： 金融與醫療等產業需要嚴格的資料治理。ERD 記錄資料存放的位置、擁有者以及與其他資料點的關聯方式，有助於合規報告。
• 高效能需求： 若系統需要快速的讀寫操作，ERD 可引導索引策略與資料分割。理解資料之間的關係有助於高效設計連接操作。

在這些情境下跳過 ERD 可能導致出現「義大利麵式資料庫」，其中資料表重複、關係模糊，且效能會隨時間逐漸下降。

兩者整合以建立穩健的架構 🤝

雖然區分 DFD 與 ERD 有其用處，但最成功的系統通常會同時使用兩者。它們是互補的，而非互斥的。穩健的系統設計流程通常是由流程走向結構。

依序進行的方法

1. 使用 DFD 定義範圍： 從上下文圖開始，以理解系統的邊界。識別所有輸入與輸出。
2. 分解流程： 將流程拆解，以理解所需的特定資料轉換。
3. 識別資料實體： 在分析資料流程時，識別正在移動的持久性物件。這些將成為 ERD 的候選實體。
4. 設計 ERD： 建立實體關係圖，以定義這些實體如何儲存與連結。
5. 驗證流程： 將資料流程對應回資料庫資料表。確保 DFD 中的每個流程在 ERD 中都有對應的儲存操作。

資料儲存的對應

在 DFD 中，資料儲存是一個通用的佔位符。在 ERD 中，同一個資料儲存會轉換為詳細的資料表定義。對應過程包括：

• 將 DFD 的資料儲存轉換為 ERD 的實體。
• 確保 DFD 流程中的所有屬性都在 ERD 屬性中有所對應。
• 檢查 ERD 中的基數是否支援 DFD 流程中的多重性。

例如，若 DFD 显示「客戶」發送多筆「訂單」，ERD 必須反映客戶與訂單實體之間的「一對多」關係。若 DFD 暗示複雜的多對多關係（例如「學生」與「課程」），ERD 必須引入關聯實體來解決此問題。

常見陷阱需避免 ⚠️

混用或誤用這些模型可能導致嚴重的技術負債。以下是一些需留意的常見錯誤。

1. 混淆邏輯與儲存

不要在ERD中包含處理邏輯。ERD應定義結構，而非行為。如果你發現自己在ERD中繪製代表「處理」的箭頭，你很可能是在描述DFD。

2. DFD過度建模

DFD不應是程式碼的流程圖。它不應詳細描述每一條條件分支或錯誤處理流程。應將DFD保持在邏輯層級。如果你詳細列出每一條「if-else」語句，圖表將變得難以閱讀，並喪失其高階概觀價值。

3. 忽略ERD中的基數

在未定義基數的情況下於實體之間繪製線條是一種常見錯誤。單純的線條無法說明一位客戶可以有零筆訂單或一百萬筆訂單。務必明確標示1:1、1:N或M:N，以避免歧義。

4. 忽略資料屬性

當資料屬性模糊時，兩種圖表都會受損。在DFD中，資料流應使用描述性名稱（例如「已驗證的付款資訊」而非「資料」）。在ERD中，屬性應盡可能定義資料類型與約束條件。

5. 創建孤兒流程

在DFD中，流程無法在沒有資料流入或流出的情況下存在。確保每個流程框至少有一個流入和一個流出的資料流。孤兒流程表示存在無效邏輯或遺漏的資料需求。

文檔編寫的最佳實務 📝

為維持清晰度與實用性，請遵循這些文檔標準。

• 命名一致性：在兩個圖表中使用相同的術語。如果DFD稱其為「客戶」，ERD也應稱為「客戶」，而非「使用者」。一致性可降低團隊的認知負荷。
• 版本控制：將圖表視為程式碼。維護版本歷史。隨著系統演進，圖表必須更新以反映當前狀態。
• 上下文註解：為複雜區域添加註解。如果關係非標準，請說明原因。如果資料流代表背景作業，請註明其為非同步。
• 審查循環：與業務利益相關者（針對DFD）及技術負責人（針對ERD）進行正式審查。業務分析師可能發現DFD中的邏輯錯誤，而開發者可能忽略，反之亦然。

模型選擇的最終思考 🧠

在資料流程圖與實體關係圖之間進行選擇，並非要在二者之間做取捨，而是要為設計生命週期的特定階段選擇合適的工具。DFD揭示資料的流向，確保系統按預期運作。ERD則穩固資料，確保其可靠且高效地儲存。

透過掌握這兩種模型的獨特用途，架構師能夠建立邏輯嚴謹且結構穩固的系統。目標並非產出完美的圖表，而是建立對系統的清晰理解。當團隊能透過DFD看到流程，透過ERD看到資料時，成功專案的基礎便已奠定。

請記住，這些模型是溝通工具。它們的價值在於為團隊成員創造共識。無論你是在繪製複雜交易流程，還是定義使用者檔案，都應聚焦於清晰性、準確性以及與業務目標的一致性。透過流程與結構的恰當結合，系統設計便成為一門有紀律的藝術，而非憑空猜測。