Datenmodell planen: Fachbegriffe vor der Software klären

Im Vertrieb bezeichnet „Kunde“ vielleicht eine Firma. Für die Disposition ist damit ein Einsatzort gemeint, in der Buchhaltung das zahlende Unternehmen. Werden diese Bedeutungen ungeprüft in einer einzigen Liste zusammengeführt, entstehen später widersprüchliche Masken und Auswertungen. Die Programmierung kann diesen Unterschied nicht allein aus einer Spaltenüberschrift erkennen.

Schreiben Sie die wichtigsten Begriffe mit einer kurzen Definition auf. Ergänzen Sie jeweils ein passendes Beispiel und einen Fall, der ausdrücklich nicht dazugehört. „Standort ist ein Ort, an dem ein Auftrag ausgeführt wird; die Rechnungsanschrift kann davon abweichen“ lässt sich leichter beurteilen als ein allgemeines Feld „Adresse“. Die Definition muss mit den Menschen abgestimmt werden, die täglich damit arbeiten.

Microsoft erläutert in seiner Einführung in fachliche Domänenanalyse eine gemeinsam entwickelte Sprache zwischen Fachseite und Entwicklung. Der Gedanke hilft auch bei einer kleinen Anwendung. Daraus folgt ausdrücklich keine Empfehlung, dafür eine Microservices-Architektur einzuführen.

Eine erste Begriffsseite darf einfach sein. Markieren Sie Unklarheiten, statt vorschnell ein perfektes Organigramm zu zeichnen. Wenn zwei Abteilungen denselben Ausdruck unterschiedlich verwenden, kann eine klare Abgrenzung sinnvoller sein als eine erzwungene gemeinsame Bedeutung. Entscheidend ist, dass Übergänge später bewusst übersetzt werden und der Gesprächspartner weiß, welche Bedeutung gerade gilt.

Kann ein Kunde mehrere Standorte haben? Kann eine Person mehrere Standorte betreuen? Darf ein Auftrag mehrere Einsatzorte enthalten oder braucht er pro Ort einen getrennten Vorgang? Diese Fragen bestimmen die Beziehungen im Modell. Eine frühe Antwort verhindert, dass später mehrere widersprüchliche Angaben in ein einziges Textfeld geschrieben werden.

Beschreiben Sie jede wichtige Beziehung in beiden Richtungen. „Ein Standort hat mehrere Aufträge“ und „ein Auftrag gehört zu genau einem Standort“ ist eine mögliche Festlegung. „Eine Kontaktperson betreut mehrere Standorte“ führt dagegen zu einer anderen Verbindung. Ergänzen Sie außerdem, ob die Beziehung zeitlich begrenzt ist, beispielsweise bei einem Ansprechpartnerwechsel.

Im fiktiven Beispiel eines Geräteprüfdienstes kann ein Gerät zwischen Standorten wechseln. Der aktuelle Standort und der Standort zum Zeitpunkt einer vergangenen Prüfung sind dann unterschiedliche Informationen. Wenn jede historische Ansicht nur den heutigen Gerätestandort zeigt, würde der frühere Vorgang nachträglich anders erscheinen. Welche Historie benötigt wird, muss ausdrücklich entschieden werden.

Für die erste Besprechung genügt oft eine Zeichnung aus Begriffen und beschrifteten Verbindungen. Schreiben Sie Zahlen oder klare Wörter an die Verbindungen, statt nur Linien zu ziehen. Lassen Sie eine fachkundige Person einen vollständigen Vorgang darin nacherzählen. Wenn sie dafür zusätzliche Bedeutungen erfinden muss, fehlt dem Modell noch eine wichtige Unterscheidung.

Wenn Kundenname, Adresse und Ansprechpartner in mehreren Anwendungen vorkommen, darf nicht jedes System dieselbe Information beliebig neu definieren. Bestimmen Sie, wo eine Angabe fachlich gepflegt wird und wie andere Anwendungen sie verwenden. Das ist zunächst eine Zuständigkeitsfrage. Erst danach folgt die Entscheidung über den technischen Übertragungsweg.

Das britische Government Data Quality Framework betrachtet Datenqualität im Verhältnis zum Verwendungszweck und entlang des Datenlebenszyklus. Für eine Unternehmensanwendung hilft dieser Blick bei der Frage, welche Fehler die spätere Arbeit tatsächlich beeinträchtigen. Das Behördenframework ist hier eine methodische Quelle, keine deutsche Unternehmenspflicht.

Legen Sie zulässige Werte für häufig ausgewertete Merkmale fest. Freie Schreibweisen wie „in Bearbeitung“, „läuft“ und „offen bei Technik“ sind nicht automatisch dieselbe fachliche Stufe. Eine gemeinsame Liste kann sinnvoll sein, muss aber echte Unterschiede erhalten. Ebenso sollte eine neue Kategorie ergänzt werden können, ohne alte Vorgänge stillschweigend umzudeuten.

Die konkrete Übertragung zwischen vorhandenen Anwendungen behandelt unser Artikel zur API-Planung. Ein Dateiaustausch wird unter CSV-Import und Export vertieft. Diese Wege benötigen die hier geklärte Bedeutung bereits. Eine saubere Feldzuordnung zwischen zwei unklaren Begriffen würde den fachlichen Widerspruch lediglich zuverlässig weiterreichen.

Aus dem fachlichen Modell entstehen technische Strukturen, Eingabemasken und Prüfregeln. Die Reihenfolge verhindert nicht jede spätere Änderung. Sie macht aber sichtbar, welche Annahmen bereits geprüft wurden und welche offen bleiben. Ein kleines gemeinsames Modell lässt sich leichter korrigieren als mehrere fertige Masken mit unterschiedlichen Vorstellungen vom selben Vorgang.

Microsoft beschreibt in seinen Hinweisen zum API-Design Ressourcen anhand fachlicher Objekte. Das zeigt einen späteren Nutzen der Vorarbeit: Verständliche Begriffe können auch Schnittstellen strukturieren. Die Quelle begründet keine Pflicht, für jede kleine Anwendung eine öffentliche API bereitzustellen.

Ruhrstack klärt im Bereich Entwicklung Eingaben, Ergebnisse, beteiligte Systeme und typische Sonderfälle vor der Umsetzung. Ein gemeinsam besprochenes Datenmodell kann diese Klärung unterstützen. Der konkrete Umfang reicht je nach Aufgabe von einer kurzen Begriffsliste bis zu einer ausführlicheren Modellierung; beides wird am Bedarf ausgerichtet.

Für die erste Anfrage genügen die wichtigsten verwalteten Dinge und ein Ablauf, an dem es heute zu Missverständnissen kommt. Eine vollständige Kundendatenbank ist dafür nicht nötig. Bringen Sie besonders die Fälle mit, die nicht in Ihre derzeitige Tabelle passen. Genau dort zeigt sich häufig, welche Beziehung oder Bedeutung vor der Programmierung noch geklärt werden muss.