在資訊系統的架構中，清晰度即是資本。兩種基礎工具主導了系統分析與資料庫設計的領域：資料流程圖（DFD）與實體關係圖（ERD）。儘管兩者皆用於視覺化複雜系統，但它們在根本上處於不同的抽象層次。一個著重於資料的移動與轉換；另一個則著重於結構與儲存。混淆兩者可能導致架構失敗、資料不一致與流程瓶頸。本指南深入探討這些模型技術的運作機制、應用場景與差異。
理解資料流程圖 🔄
資料流程圖用以描繪資訊在系統中的流動。它是一種以流程為導向的模型。此處的主要關注點並非資料存放的位置，而是資料如何移動、變更與互動。此類圖表對於理解商業流程或軟體應用的邏輯至關重要。
DFD的核心元件
要建立有效的DFD，必須理解用來表示系統元件的四種標準符號：
- 處理程序：以圓形或圓角矩形表示。處理程序將輸入資料轉換為輸出資料。它不儲存資訊，僅對其進行操作。範例包括「計算稅額」或「驗證登入」。
- 資料儲存：以開口矩形或平行線表示。這表示資料靜止存放的位置。它是系統的記憶體，例如檔案、資料庫表格或實體檔案庫。
- 外部實體：以方形表示。這些是系統邊界以外的資料來源或目的地。它們可以是使用者、其他系統或硬體裝置。它們啟動或接收資料，但不會在內部處理資料。
- 資料流：以箭頭表示。這些顯示資料在處理程序、儲存與實體之間移動的方向。每一筆資料流都必須有明確的名稱，用以描述內容，例如「發票」或「使用者請求」。
DFD的細節層級
DFD具有層級結構。它們很少以單一視圖繪製，而是被分解為不同細節層級：
- 上下文圖（第0層）：最高層級的視圖。它將整個系統視為一個與外部實體互動的單一處理程序。用以定義系統邊界。
- 第1層圖：將主要處理程序分解為主要的子處理程序。引入第一層的資料儲存與資料流。
- 第2層及更進一步：將特定子處理程序進一步細分為更細微的動作。此層級用於詳細規格說明。
理解實體關係圖 🗃️
實體關係圖專注於資料的靜態結構。它是一種概念模型，主要用於資料庫設計階段。其目標是確保資料完整性、減少冗餘，並定義不同資訊片段之間的關係。
ERD的核心元件
ERD依賴特定符號來定義資料實體之間的關係：
- 實體：以矩形表示。實體是資料所儲存的現實世界物件或概念。範例包括「顧客」、「產品」或「訂單」。
- 屬性：以橢圓形表示，或列於實體矩形內。這些用來描述實體的特性。例如「顧客」實體的屬性可能包括「姓名」、「地址」和「電話號碼」。
- 關係：以菱形或連接實體的線條表示。這定義了實體之間的互動方式。例如，顧客「下訂單」。
- 基數：定義關係的數量。是一對一？一對多？還是多對多？這決定了資料庫的結構限制。
ERD設計中的正規化
雖然資料流程圖通常不會處理正規化，但實體關係圖與正規化密切相關。設計過程包括組織資料以減少重複。實體關係圖必須反映第一正規化形式、第二正規化形式等規則。這確保了最終資料庫的效率與可擴展性。未能正規化資料結構通常會導致更新異常，即更改單一資訊項目需要在多個地方進行編輯。
結構比較：資料流程圖 vs. 實體關係圖 📊
為了釐清兩者的差異，我們從多個維度對兩種模型進行比較。此表格突顯了流程與資料結構之間的功能差異。
| 功能 | 資料流程圖（DFD） | 實體關係圖（ERD） |
|---|---|---|
| 主要關注點 | 流程與移動 | 結構與儲存 |
| 時間維度 | 動態（事件序列） | 靜態（資料快照） |
| 關鍵問題 | 資料如何變更？ | 有哪些資料存在？ |
| 目標受眾 | 業務分析師、使用者 | 資料庫管理員、開發人員 |
| 儲存處理 | 通用資料儲存 | 特定的資料表與金鑰 |
| 邏輯表示 | 轉換與邏輯 | 約束與規則 |
何時部署每種圖表 📅
選擇正確的工具取決於專案生命週期的階段。使用ERD向利益相關者解釋業務流程會讓他們感到困惑。使用DFD向開發人員解釋表格關係會讓他們感到挫折。以下是最佳使用情境的分解。
當需要時使用DFD：
- 定義系統範圍： 您需要展示系統內部與外部的區別。
- 分析業務邏輯： 您需要追蹤請求如何從使用者輸入移動到儲存的記錄。
- 識別瓶頸： 您需要查看資料累積的位置，或流程停滯的位置。
- 與利益相關者溝通： 非技術使用者更能理解流程，而非表格。
當需要時使用ERD：
- 設計資料庫： 您正在建立實體或邏輯儲存層。
- 確保資料完整性： 您需要定義主鍵、外鍵和約束條件。
- 規劃可擴展性： 您需要確保資料模型能支援未來成長，且不會產生冗餘。
- API文件： 您需要定義將對外部使用者公開的結構。
從零開始建立資料流程圖 🛠️
建立穩健的DFD需要有條不紊的方法。如果目標是準確性，這個過程沒有捷徑。遵循以下步驟來建立可靠的模型。
步驟1：識別邊界
首先定義系統邊界。什麼在範圍內？什麼是外部的？在系統周圍畫一個框。所有在框內的都是系統的一部分；所有在框外的都是外部實體。
步驟2：繪製外部實體
列出所有與您的專案互動的人、部門或系統。將它們繪製在邊界外，並清楚標示。
步驟3：定義主要流程
識別系統的主要功能。這些將成為圖表中的圓圈。例如，若建立圖書館系統，流程可能包括「借書」和「還書」。
步驟4：以資料流連接
繪製箭頭，將實體連接到流程，並將流程連接到資料儲存。確保每個箭頭都有標籤。沒有名稱的資料流毫無意義。確保資料不會直接從一個實體流到另一個實體，而必須經過流程。
步驟5：驗證守恆
檢查資料守恆。如果一個流程輸出資料，這些資料必須來自某處。如果一個流程接收輸入，它必須有去處。資料不應憑空消失或出現。
從零開始建立實體關係圖 🏗️
ERD 需要對關係和金鑰有精確的定義。結構決定了應用程式的效能與可靠性。
步驟 1：識別實體
掃描需求中的名詞。這些是潛在的實體。過濾掉模糊的名詞，僅保留代表具體價值物件的名詞。例如，在醫院系統中，“病患”和“醫生”都是實體。“治療”可能是實體或關係，取決於複雜程度。
步驟 2：定義屬性
列出每個實體的具體細節。確定哪些屬性是唯一識別符（主鍵）。對於「病患」實體，「病患編號」是關鍵。「姓名」是屬性。確保屬性為原子性；若需按城市查詢，則不應將「地址」儲存在單一欄位中。
步驟 3：建立關係
確定實體之間如何連結。病患由醫生治療。這是一種關係。確定基數。一位醫生是否治療多位病患？是的。是否為多對多？是的。一位病患是否有多位醫生？是的。
步驟 4：解決多對多關係
資料庫無法原生儲存多對多關係。如果一位學生可以選修多門課程，而一門課程也有許多學生，則必須建立一個關聯實體（通常稱為聯結表）。這會將關係拆分成兩個一對多關係。
步驟 5：檢視範式
應用規範化規則。確保非鍵屬性僅依賴於主鍵。如果屬性依賴於鍵的一部分，則應將其移至新實體。此步驟可防止資料異常。
常見陷阱，應避免 ⚠️
即使經驗豐富的架構師在建模時也會犯錯。了解常見錯誤有助於維持設計的完整性。
DFD 陷阱
- 實體之間的資料流：資料必須始終經過流程。外部實體之間的直接連線表示系統控制不足。
- 黑洞：有輸入但無輸出的流程。在正常運作的系統中，這在邏輯上是不可能的。
- 灰洞：有輸入但完全無輸出，或輸出不符合輸入需求的流程。
- 未標示的流程：沒有標示名稱的箭頭無法提供傳輸內容的資訊。
ERD 陷阱
- 遺漏基數：未明確定義關係是一對一還是一對多，會導致程式碼實作時產生歧義。
- 重複的實體：建立與其他實體本質上重複的實體，導致資料不一致。
- 忽略空值： 未能決定屬性是否可以為空。這會影響資料庫的約束條件和應用程式邏輯。
- 過度規範化： 將資料拆分成太多表格會使查詢變慢且複雜。平衡才是關鍵。
在系統架構中整合兩者 🏗️
雖然DFD與ERD是不同的，但它們並非互斥的。成熟的系統設計會同時運用兩者。DFD描述資料的旅程，而ERD則描述資料的終點與儲存方式。
整合流程
在需求階段，應從上下文圖開始。這為後續奠定基礎。隨著系統的分解，你將識別出資料儲存位置。這些資料儲存最終會成為ERD中的實體。DFD中的資料流會轉化為ERD中的外鍵與關係。
例如，若DFD顯示「更新個人資料」的流程將資料移動至「使用者資訊」儲存區，則ERD必須定義一個「使用者」實體，其屬性需與該儲存區相符。DFD中流程與儲存區之間的關係，將決定ERD中的讀取/寫入權限與交易邏輯。
文件一致性
維持兩張圖表之間的一致性至關重要。若DFD變更以新增資料來源，ERD必須更新以反映新的資料表或欄位。若ERD變更資料表的結構，DFD必須顯示新的資料流名稱或目的地。這裡的差異將導致整合錯誤與資料遺失。
現代系統的進階考量 🚀
雖然這些圖表源自大型主機時代，但其原則在現代微服務與雲端架構中依然適用。
雲端與DFD
在雲端環境中，資料流經常跨越不同的區域或服務。DFD必須明確顯示這些邊界。這有助於理解延遲與資料主權的要求。例如，若資料從歐洲使用者流至美國伺服器，可能需遵守合規法規。
NoSQL與ERD
傳統的ERD假設為關聯式結構。NoSQL資料庫通常使用文件或圖形模型。雖然實體與關係的核心概念仍存在，但實作方式有所不同。在文件儲存中，「實體」本身即是文件。關係可能以嵌入方式或透過ID連結，而非嚴格的外鍵。ERD仍作為藍圖使用，但符號可能需適應技術無結構的特性。
差異總結
這兩種圖表的差異在於其目的。DFD是動態的圖譜，回答的是：「資料發生了什麼？」ERD是結構的圖譜，回答的是：「資料是什麼？」兩者對於完整呈現軟體系統皆不可或缺。僅依賴其中之一會造成理解上的缺口，可能危及專案。
透過掌握兩種模型的建構與應用，可確保系統不僅在運作上具備功能性，更在資料管理上具備穩健性。這種雙重方法涵蓋了資訊架構的動態與靜態面向，為開發與分析提供了全面的基礎。
常見問題
我能否用一張圖表達兩種用途？
不行。DFD無法有效顯示資料表鍵或規範化規則。ERD無法有效顯示流程邏輯或資料轉換步驟。它們服務於不同的利害關係人與階段。
我應該先建立哪一個？
通常應先從DFD開始。在知道需要儲存哪些資料之前，必須先理解流程。一旦在DFD中識別出資料儲存位置，便可將其擴展為完整的ERD。
這些圖表是否適用於敏捷方法論？
是的。在敏捷開發中，這些圖表通常針對特定使用者故事即時建立，而非作為龐大的前期文件。它們作為持續演進的活文件，隨著產品發展而更新。