{"id":643,"date":"2026-02-25T10:21:36","date_gmt":"2026-02-25T10:21:36","guid":{"rendered":"https:\/\/skills.visual-paradigm.com\/pl\/docs\/common-dfd-mistakes-and-how-to-avoid-them\/dfd-notation-mistakes\/illegal-dfd-connections\/"},"modified":"2026-02-25T10:21:36","modified_gmt":"2026-02-25T10:21:36","slug":"illegal-dfd-connections","status":"publish","type":"docs","link":"https:\/\/skills.visual-paradigm.com\/pl\/docs\/common-dfd-mistakes-and-how-to-avoid-them\/dfd-notation-mistakes\/illegal-dfd-connections\/","title":{"rendered":"Illegal or Misleading Connections Between Elements"},"content":{"rendered":"

When I first started mentoring junior analysts, one of the most frequent red flags I\u2019d see wasn\u2019t in the logic of the process, but in the connections themselves. A data store linked directly to another data store? An external entity sending data to another external entity? These aren\u2019t just visual glitches\u2014they\u2019re violations of core DFD principles that break the model\u2019s integrity.<\/p>\n

These illegal DFD connections aren\u2019t random mistakes. They stem from misunderstanding the fundamental role of processes as transformers of data. Every data flow must begin and end at a process, or at a boundary point\u2014external entity or data store. A flow that skips the process is invisible to the system\u2019s logic. It\u2019s like a river flowing without a source, or a pipe with no pump.<\/p>\n

Understanding why these connections are invalid isn\u2019t about memorizing rules\u2014it\u2019s about grasping the purpose of DFDs: to model *what changes*, not just where data lives. You need to see data flow as a story of transformation, not mere movement. When you think this way, the logic becomes intuitive.<\/p>\n

Here, you\u2019ll learn not just what to avoid, but why. We\u2019ll walk through three common illegal DFD connections with real-world examples, corrected versions, and the reasoning behind each fix. By the end, you\u2019ll have the confidence to audit your own models with precision.<\/p>\n

Why Certain Data Flows Break the Rules<\/h2>\n

Classic DFD theory is clear: data flows must originate from or terminate at a process. Data stores and external entities are passive containers. They don\u2019t generate or consume data\u2014they hold it.<\/p>\n

Any flow that goes directly from one data store to another, or from one external entity to another, bypasses this rule. These flows are not just incorrect\u2014they create ambiguity. Who decides when to move data? What triggers the transfer? The model loses its causal logic.<\/p>\n

Even more troubling: such flows often hide assumptions. A data store to data store error might imply a behind-the-scenes job, but that job isn\u2019t modeled. This leads to untraceable data movement, which becomes a major source of bugs and audit failures.<\/p>\n

Rule of Thumb: Every Flow Must Touch a Process<\/h3>\n

Ask yourself: does this flow begin or end at a process? If not, it\u2019s an invalid DFD data flow.<\/p>\n

Even if the flow appears to \u201cmake sense\u201d at first glance\u2014like customer data moving from one database to another\u2014it still violates the principle. The transfer must be triggered by a process. That process could be a batch job, a synchronization routine, or a business rule. But it must exist.<\/p>\n

Common Anti-Patterns and How to Fix Them<\/h2>\n

1. Data Store to Data Store Error<\/h3>\n

Imagine a system where customer data is stored in a „Customer DB” data store, and a backup is kept in a „Legacy Archive” data store. A line connects these two directly. This is a data store to data store error.<\/p>\n

Why it fails: Data stores are not active agents. They don\u2019t initiate transfers. Moving data between them requires a process\u2014like „Sync Customer Data Nightly.”<\/p>\n

Corrected Version:<\/strong><\/p>\n