建立穩健的系統模型，需要對資訊如何被捕捉、移動與保留採取嚴謹的方法。在資料流程圖（DFD）的脈絡中，資料儲存代表系統持久性的核心。若未明確設計資料存放的位置，資訊的流動將仍停留在抽象層面，無法實際實現。本指南探討在DFD中設計資料儲存的核心原則，確保清晰性、準確性，並與系統架構保持一致。
有效的建模不僅僅是畫出圖形之間的連線。它要求對資料完整性、存取模式，以及系統內資訊的生命周期有深入的理解。透過遵循既定的設計原則，分析師能夠產製出可作為開發團隊可靠藍圖的圖表。
🏷️ 定義資料儲存 🏷️
資料儲存是資料流程圖中的一個被動元件。與會轉換資料的處理程序不同，資料儲存用來存放靜態資料。它代表檔案、資料庫、紙本紀錄，或任何用於後續檢索而儲存資訊的儲存庫。
- 被動性： 資料不會從儲存中流出，除非有處理程序明確要求。
- 儲存身份： 它本身不是一個處理程序；它不會改變資料，僅負責保存資料。
- 視覺呈現： 通常以開口矩形或雙條垂直線來表示，視所使用的符號標準而定。
在設計這些元件時，重點應放在邏輯需求，而非實際的實作方式。DFD描述的是什麼資料的需求，而非如何實際上如何在硬碟上索引或儲存。
📝 標籤命名規範以確保清晰 📝
命名是防止混淆的第一道防線。模糊的標籤會導致設計階段產生誤解。一個命名良好的資料儲存能立即提供其所含資訊的上下文。
1. 單數與複數
一致性至關重要。有些團隊偏好使用單數名詞（例如，顧客），而其他團隊則使用複數（例如，顧客們）。關鍵在於整個模型必須使用相同的命名慣例。
- 建議： 對於資料集合，建議使用複數名詞（例如，訂單, 產品）以暗示其為一組資料集合。
- 例外：如果儲存區僅包含一種記錄類型，單數名稱適用於特定實例（例如，設定).
2. 描述的精確性
避免使用像這樣的通用詞彙資料 或 資訊。這些標籤對內容毫無提示作用。
- 不良範例： 系統資料
- 良好範例： 活躍的使用者帳戶
明確的命名有助於利害關係人立即識別儲存區的範圍。這能降低理解圖表所需的認知負荷。
3. 時態與狀態
名稱應反映資料的狀態。如果儲存區包含歷史記錄，名稱應體現這一點。
- 交易記錄 暗示過去事件的記錄。
- 待處理的訂單 暗示等待處理的資料。
🔗 連接規則 🔗
資料進入和離開儲存區的流動受到嚴格的邏輯規則約束。違反這些規則會破壞資料流程圖（DFD）的完整性。
1. 流程連接要求
資料儲存區必須始終與至少一個流程相連。它不能孤立存在。
- 輸入： 流程必須將資料寫入儲存區（例如，儲存新記錄）。
- 輸出： 流程必須從儲存區讀取資料（例如，取得記錄）。
如果儲存區未與任何項目連接，它就是一個無功能的幽靈元素。如果它與多個流程相連，則每個連接的資料流動必須明確界定。
2. 無直接的儲存體至儲存體資料流
資料無法在沒有中間處理程序的情況下，直接從一個資料儲存體移動到另一個資料儲存體。此規則強調資料轉換或驗證必須在儲存之前進行的原則。
- 錯誤： 連接線段 儲存體 A 直接連接到 儲存體 B.
- 正確： 處理程序 X 從 … 讀取 儲存體 A，轉換資料，並寫入到 儲存體 B.
這種分離確保商業邏輯、驗證或格式化在資料持久化前已套用。它可防止模型暗示資料僅是被簡單複製而無監控。
3. 資料流標籤
連接處理程序與資料儲存體的每一條線都必須標示標籤。標籤描述了跨越該邊界移動的特定資料。
- 範例： 從 … 的一條線 訂單處理 到 訂單儲存體 可能標示為 訂單明細.
- 範例： 從 … 的一條線 訂單儲存體 到 報告流程可能被標記為訂單歷史.
標籤為正在傳輸的資料量和類型提供上下文。它們有助於開發人員後續理解資料結構的需求。
🎯 細節程度與範圍 🎯
決定如何將資料分割到儲存區是一個關鍵的設計決策。儲存區太多會導致模型碎片化，而太少則會形成單一的資訊大塊。
1. 基於實體的分組
根據邏輯實體對資料進行分組。如果系統追蹤客戶、產品和發票，這些資料通常應存放在獨立的儲存區中。
- 優勢：簡化維護。客戶資料的變更不會影響發票儲存邏輯。
- 優勢：降低更新期間意外資料損壞的風險。
2. 讀寫分離
考慮儲存區主要是用於讀取還是寫入。高頻率的交易日誌通常需要與參考資料不同的儲存處理方式。
- 參考資料： 儲存區如國家代碼以讀取為主且很少變更。
- 交易資料： 儲存區如銷售日誌以寫入為主且隨時間增長。
即使DFD仍為邏輯模型，區分這些類型也有助於規劃容量和存取模式。
3. 暫時與永久
並非所有資料儲存區都代表永久保留。有些僅是暫時的緩衝區。
- 使用者會話資料：用於登入過程中暫時使用者會話的儲存區。
- 快取儲存區：常用資料的暫時存放區域。
明確標示暫存資料庫可避免對於資料保留政策產生混淆。流程完成後，暫存資料庫應被清空或清除。
🔄 資料流與流程互動 🔄
流程與資料庫之間的關係在許多情況下是雙向的，但並非總是如此。理解方向性對於準確建模至關重要。
1. 僅讀取存取
某些資料庫僅用於讀取。流程可能查詢資料庫以顯示資訊，而不會修改它。
- 範例： 一 顯示個人檔案 流程從 使用者個人檔案資料庫.
- 限制條件：對於同一筆交易，資料流箭頭不應從資料庫指向流程，再從流程返回資料庫，除非表示寫入操作。
2. 僅寫入存取
某些流程在不需要先取得資料的情況下直接寫入資料。
- 範例： 一 事件記錄 流程寫入至 系統稽核資料庫.
- 限制條件： 確保流程具備正確寫入資料所需的必要背景資訊，無需外部輸入。
3. 讀寫存取
大多數業務流程都涉及取得、修改和儲存資料。
- 範例： 更新庫存 讀取現有庫存，計算新數量，並儲存。
- 建模： 使用獨立的讀取與寫入流程，以明確操作順序。
這種區別有助於開發人員理解資料庫交易是否需要立即加鎖或提交。
📊 資料流程圖層級與資料儲存可見性 📊
資料流程圖通常會被分解為不同層級，從上下文圖（第0層）到詳細分解圖（第2層、第3層）。資料儲存於各層級的呈現方式不同。
1. 上下文層級（第0層）
在最高層級，資料儲存通常被省略以保持簡潔。重點在於外部實體與主要系統邊界。
- 原因：過多細節會掩蓋高層級的資料交換。
- 例外：若主要外部資料庫對系統邊界至關重要，則可能予以顯示。
2. 第1層分解
當系統被分解為主要流程時，資料儲存便會變得可見。這正是定義主要儲存架構的階段。
- 重點：識別每個主要功能所需的關鍵儲存庫。
- 細節：確保每個流程都有其輸出資料的目標位置。
3. 第2層及更進一步
進一步分解可能將大型資料儲存拆分為更小、更具體的儲存。
- 範例： 客戶儲存在第1層可能拆分為聯絡資訊儲存與帳單儲存在第2層。
- 一致性：確保低層級的資料與高層級的資料一致。不要引入父圖中未出現的新資料類型。
⚠️ 常見陷阱 ⚠️
即使經驗豐富的分析師在設計資料儲存時也會犯錯。避免這些常見錯誤可確保圖表的準確性。
- 黑洞：一個接收資料但未將其寫入任何位置的流程。這意味著資料遺失。
- 火storm： 一個接收資料輸入但不經由儲存就產生資料輸出的處理程序。這表示資料是從無中產生（奇蹟）。
- 幽靈儲存： 沒有任何連接處理程序的資料儲存。這些都是死路。
- 流量不平衡： 從第1層移動到第2層時，輸入與輸出必須相符。若在第2層新增儲存，必須由父處理程序的輸入/輸出來合理說明。
- 過度設計： 試圖將每個資料庫表格都視為第1層圖中的獨立儲存。應專注於邏輯實體，而非物理表格。
📚 與資料模型對齊 📚
雖然DFD著重於流程，但必須與實體關係圖（ERD）或邏輯資料模型對齊。DFD中的資料儲存應對應到ERD中的實體。
- 一致性檢查： 如果DFD中包含產品儲存，則ERD中應包含產品實體。
- 屬性對應： 處理程序與儲存互動所需的屬性，必須在資料模型中存在。
- 正規化： 雖然DFD不強制正規化，但設計應避免明顯的重複，以免暗示資料庫設計不良。
這種對齊確保邏輯設計（DFD）能轉換為物理實作（資料庫結構）而無需大幅修改。
🔍 設計驗證清單 🔍
在最終確定資料流程圖之前，請使用以下清單來驗證資料儲存設計。
| 原則 | 清單項目 | 狀態 |
|---|---|---|
| 命名 | 所有儲存名稱是否具描述性且一致？ | ☐ |
| 連接性 | 每個儲存區是否都至少連接到一個流程？ | ☐ |
| 流向方向 | 流程與儲存區之間的箭頭指向是否正確？ | ☐ |
| 標籤 | 資料是否沿著標有內容名稱的線路流動？ | ☐ |
| 無直接儲存區連結 | 是否有任何線路直接連接儲存區至儲存區？ | ☐ |
| 一致性 | 低階儲存區是否符合父層級的範圍？ | ☐ |
| 完整性 | 所有流程的資料需求是否都由現有的儲存區滿足？ | ☐ |
🔄 維護與演進 🔄
系統需求會變更。資料儲存區必須能適應這些變更，而不會破壞模型。
- 版本控制： 跟蹤儲存區定義的變更。若儲存區分裂，需記錄遷移路徑。
- 遺留資料： 計畫在儲存區結構變更時，如何處理舊資料。這通常需要一個存檔儲存區。
- 反饋迴圈： 利用開發團隊的反饋來優化儲存區的細緻程度。若開發人員覺得某個儲存區過於廣泛，則予以拆分；若覺得過於零散，則予以合併。
靜態模型是一種負擔。當商業規則變更或引入新的合規要求時，應重新審視資料儲存設計。這可確保資料流程圖始終是一份活文件，準確反映系統的資料需求。
📝 實施總結
在資料流程圖中設計資料儲存區，是系統分析的基礎任務。它彌補了抽象流程與具體資料持久化之間的差距。透過遵循嚴格的命名規範、連接性規則與細緻程度原則，分析師可建立既易讀又可執行的模型。
目標並非完美複製資料庫結構，而是捕捉資料儲存的邏輯必要性。當資料流程圖準確時，轉向開發的過程將更順暢，資料遺失或錯位的風險也大幅降低。專注於清晰性、一致性與資訊的邏輯流動，以產出高品質的系統設計。