Ein Datenflussplan, häufig auch als Datenflussdiagramm (DFD) bezeichnet, dient der klaren, normierten Visualisierung, wie Informationen in einem System bereitgestellt, verarbeitet, gespeichert und wieder ausgegeben werden. Er zeigt Datenquellen, Datensenken, Prozesse und Datenspeicher sowie die Beziehungen dazwischen. Durch seine einheitliche Symbolik ist die Modellierung leicht nachvollziehbar – vom Kontextdiagramm bis zur detaillierten Zerlegung in Teilprozesse. Wichtig: Ein Datenflussplan ist kein Programmablaufplan; er bildet keine Kontrolllogik wie Verzweigungen oder Schleifen ab, sondern ausschließlich den Datenstrom und die Schnittstellen.

Im praktischen Einsatz unterstützt ein Datenflussplan die Anforderungsanalyse, die Schnittstellendefinition zwischen Komponenten, die Qualitätssicherung und die Dokumentation über den gesamten Lebenszyklus einer Anwendung. Typisch ist die hierarchische Darstellung: vom Level-0-Kontextdiagramm (System im Überblick mit externen Entitäten) über Level-1/Level-2-Diagramme bis zur Feinmodellierung einzelner Prozesse. So bleiben Komplexität beherrschbar, Redundanzen werden erkannt und fachliche wie technische Teams erhalten ein gemeinsames Verständnis.

Funktionen eines Datenflussplans

Hilfreich für die Erstellung von Datenbankanwendungen ist ein Datenflussplan. Hierbei kann er den Datenfluss eines bestimmten Prozesses bildlich wiedergeben. Im Gegensatz zu einem Programmablaufplan hat ein Datenflussplan keine Kontrollmechanismen. Von daher gibt es hier keine Programmschleifen oder Entscheidungsregeln. Es wird lediglich der Datenfluss dargestellt. So wird beispielsweise der Datenstrom bildlich als Input aus einer Datenbank dem Rechnersystem zur weiteren Verarbeitung zugeführt. Nach der Verarbeitung durch ein Computerprogramm werden die Daten als Output ausgegeben.

Ein moderner Datenflussplan unterstützt zudem die klare Abgrenzung der Systemgrenzen, die Definition von Input-/Output-Schnittstellen und die Dokumentation von Regeln für Datenflüsse (z. B. Formate, Aggregationen, Validierungen). Er hilft, Inkonsistenzen zwischen Fachkonzept und Implementierung frühzeitig zu erkennen.

• Anforderungsaufnahme: Gemeinsame Sprache zwischen Fachbereich und Entwicklung durch eindeutige Visualisierung.
• Prozessverständnis: Welche Informationen werden woher bezogen, wie transformiert und wohin weitergegeben?
• Schnittstellenklärung: Eindeutige Beschreibung von Datenquellen/-senken sowie Übergabepunkten.
• Datenqualität: Sichtbar machen von Validierungsschritten, Plausibilitätsprüfungen und Bereinigungen.
• Compliance und Nachvollziehbarkeit: Rückverfolgbarkeit von Datenpfaden, z. B. für Protokollierung oder Audit.
• Wartung und Erweiterbarkeit: Strukturierte Zerlegung in Subprozesse ermöglicht zielgerichtete Anpassungen.

Hierarchie und Verfeinerung: DFDs werden typischerweise schrittweise verfeinert. Das Kontextdiagramm (Level 0) zeigt das Gesamtsystem mit externen Entitäten und den wichtigsten Flüssen. In Level 1 und tiefer werden Prozesse aufgeschlüsselt (Decomposition), wobei die Summe der ein- und ausgehenden Flüsse zwischen den Ebenen konsistent bleiben muss (Balancing).

Generell ist ein Datenflussplan in vier Elementtypen aufgeteilt. Der eigentliche Datenspeicher wird durch zwei parallele Linien dargestellt. Zwischen den beiden Linien steht der Speichername. In der Unified Modeling Language, einer vereinheitlichten Modellierungssprache, auch UML abgekürzt, wird dies als sogenannter Pufferknoten dargestellt. UML als grafische Modellierungssprache dient zur Konstruktion und Spezifikation von bestimmten Softwareteilen. Der Pufferknoten selbst stellt ein Modellelement hieraus dar.

Benennungs- und Modellierungsregeln unterstützen die Lesbarkeit:

• Prozesse werden aktiv benannt (z. B. „Validieren Kundendaten“, „Aggregieren Umsätze“); optional mit Nummerierung (P1, P1.1 …).
• Datenflüsse tragen präzise, fachliche Bezeichnungen (z. B. „Bestellkopf“, „Positionsliste“, „Fehlerprotokoll“).
• Datenspeicher werden semantisch eindeutig bezeichnet (z. B. „Kundenstamm“, „Transaktionsarchiv“).
• Vermeiden: direkter Fluss Datenspeicher → Datenspeicher oder externe Entität → externe Entität ohne Prozess dazwischen.
• Jeder Prozess hat mindestens einen eingehenden und einen ausgehenden Fluss (keine „Black Holes/Miracles/Grey Holes“).

Der zweite Elementtyp ist der Datenfluss. Er wird gewöhnlich mit einem Pfeil dargestellt auf den ein Name, zum Beispiel Input oder Output auf die Funktion hinweist. Sollte eine Funktion sowohl lesend als auch schreibend auf einen Datenspeicher zugreifen, wird dies entweder mit zwei getrennten, entgegengesetzten Pfeilen symbolisiert oder durch einen Doppelpfeil, der in beide Richtungen verweist.

Das dritte Element bezeichnet den eigentlichen Prozess oder die Funktion. Sie wird durch einen Kreis mit einer Bezeichnung darin dargestellt. Der vierte und letzte Schritt wird als Schnittstelle zur Umwelt bezeichnet. Es handelt sich hierbei um ein Rechteck, welches mit dem Schnittstellennamen versehen ist. Zu unterscheiden sind Schnittstellen, die gewisse Daten in ein Computersystem einfließen lassen. Sie werden als Datenquellen bezeichnet und stehen beispielsweise für eine Datenbank. Werden Daten dagegen von einem Computersystem ausgegeben, so nennt man diese Datensenken.

Typische Fehlerbilder und wie man sie vermeidet:

• Black Hole: Prozess hat Input, aber keinen Output → fehlende Ausgabeströme definieren.
• Miracle: Prozess hat Output ohne Input → Herkunft der Daten klären.
• Grey Hole: Unplausibles Verhältnis zwischen Input und Output → Transformation schärfen.
• Missing Balancing: Flüsse zwischen Ebenen inkonsistent → Level-übergreifend prüfen und harmonisieren.

Verschiedene Notationen bei der Darstellung von Datenflussplänen

Im Rahmen der strukturierten Analyse wurde 1979 von Tom DeMarco die oben genannte Darstellungsform beschrieben. Dabei wurden die Symbole für die Darstellung aus der DIN 66001 abgeleitet. Generell muss bei einem Datenflussplan wenigstens einer der bezeichneten Endpunkte einen Prozess bilden. Mit Endpunkten wird die Quelle oder das Ziel beschrieben. Der besseren Übersichtlichkeit gibt es auch eine verfeinerte Prozessdarstellung, in dem ein weiteres Datenflussdiagramm verwendet wird. Auf diese Weise spricht man von der Aufteilung in Subprozesse.

Historische und aktuelle Notationen:

• DeMarco/Yourdon und Gane/Sarson: klassische DFD-Stile mit leicht abweichender Symbolik, häufig in der strukturierten Analyse genutzt.
• DIN 66001: Ursprung vieler Zeichensymbole; historisch relevant und in Bestandsdokumentationen weiterhin anzutreffen.
• UML-Aktivitätsdiagramm: In der Unified Modeling Language übernehmen Aktivitätsdiagramme die Modellierung dynamischer Abläufe; aktuell gängige Versionen sind UML 2.x (z. B. 2.6.x).
• BPMN 2.0.x: Für prozessorientierte Modellierung mit klaren Ereignis- und Gateway-Konzepten; in der Praxis oft ergänzend zum DFD eingesetzt.
• Stellenorientierter Datenflussplan („wer/was“-Diagramm): Zuordnung von Tätigkeiten in vertikalen Swimlanes zu Beteiligten/Rollen; nahe an swimlane-basierten Aktivitätsdiagrammen.

In der Praxis werden DFDs häufig mit einem Datenlexikon (Data Dictionary) kombiniert, das alle Datenobjekte, Strukturen und Formate beschreibt. Ergänzend unterstützen CRUD-Matrizen (Create/Read/Update/Delete) die Übersicht, welche Prozesse auf welche Datenspeicher zugreifen. Moderne Werkzeuge erlauben die konsistente Pflege dieser Artefakte, inklusive Versionierung und Review-Workflows.

Best Practices für belastbare Datenflusspläne:

1. Scope definieren: Systemgrenzen, externe Entitäten und Ziele festlegen.
2. Kontextdiagramm erstellen: Zentrale Flüsse mit Quellen/Senken skizzieren.
3. Top-down verfeinern: Prozesse schrittweise in Subprozesse zerlegen; Balancing sicherstellen.
4. Benennungen schärfen: Konsistente, fachlich präzise Namen für Flüsse und Speicher verwenden.
5. Validieren: Fachliche Reviews durchführen; typische DFD-Regeln prüfen.
6. Dokumentation ergänzen: Datenlexikon, Annahmen, Formate und Prüfregeln erfassen.

Häufige Fragen und Antworten