Datenmodell
Das Datenmodell legt fest, welche Begriffe eines Fachgebiets in einer Software eigenständige Objekte mit Regeln und Beziehungen werden und welche nur Merkmale anderer Objekte. Diese Festlegung fällt früh im Projekt und lässt sich später nur mit hohem Aufwand ändern.
Das Datenmodell ist das Fundament jeder Geschäftsanwendung – ob [[individualsoftware|Eigenentwicklung]], [[erp|Warenwirtschaft]] oder [[pim|Produktdaten-System]]: Auswertungen, Regeln und Automatisierung reichen nie tiefer als die Objekte, auf denen sie aufbauen.
In einfachen Worten
Jede Geschäftssoftware bildet die Welt ihres Einsatzgebiets in Datenobjekten ab: Kunde, Auftrag, Artikel. Die Modellierungsfrage lautet bei jedem Fachbegriff gleich – wird daraus ein eigenes Objekt mit Feldern, Regeln und Beziehungen, oder genügt ein Merkmal an einem bestehenden Objekt? Ob eine Produktveredelung als eigenes Objekt mit Verträglichkeitsregeln geführt wird oder als Textzeile am Artikel, entscheidet darüber, was die Software später kann: Nur ein echtes Objekt lässt sich prüfen, auswerten, bepreisen und in Automatisierung einbinden. Solche Festlegungen fallen in den ersten Projektwochen, oft unscheinbar, und tragen das gesamte System – bei angepasster Standardsoftware ebenso wie bei einer Individualsoftware. Eine spätere Korrektur betrifft sämtliche Altdaten, Schnittstellen und Auswertungen – deshalb gehört die Fachabteilung in genau diese frühe Phase des Projekts.
Wozu brauche ich das?
Bei jeder Systemauswahl und jedem Entwicklungsprojekt lohnt der Blick unter die Oberfläche: Welche Begriffe des eigenen Geschäfts führt das System als Objekte, welche nur als Felder? Ein Anbieter, der diese Frage präzise beantwortet, hat die Branche verstanden. Für das eigene Lastenheft gilt die Faustregel: Alles, was geprüft, ausgewertet oder automatisiert werden soll, braucht ein eigenes Objekt – ein Freitextfeld leistet nichts davon. Dieselbe Regel entlarvt gewachsene Behelfe, etwa Zusatzfeld-Sammlungen, die in Wahrheit ein fehlendes Objekt ersetzen.
Beispiel aus der Praxis
Ein Betrieb für Metallverarbeitung dokumentiert Werkstoff-Chargen zunächst in einem Bemerkungsfeld seiner Warenwirtschaft. Im Alltag fällt das lange nicht auf. Dann verlangt ein Kunde den Nachweis, welche Aufträge Material einer bestimmten Charge enthielten – die Suche durch Freitexte dauert Tage, mit unsicherem Ergebnis. Als Konsequenz wird die Charge zum eigenen Datenobjekt mit Beziehungen zu Wareneingang, Auftrag und Lieferung. Derselbe Nachweis ist danach eine Auswertung von Minuten, und Sperrungen lassen sich auf die tatsächlich betroffenen Aufträge eingrenzen. Der Umbau selbst war aufwendig, weil Jahre an Altdaten nachgetragen werden mussten – im ursprünglichen Modell angelegt, wäre dieselbe Struktur ein Anfangsaufwand von Tagen gewesen.
Wirtschaftlicher Nutzen
Datenmodell-Entscheidungen haben das ungünstigste Kosten-Profil eines Software-Projekts: Zu Beginn kosten sie wenig mehr als Nachdenken, im laufenden Betrieb kostet ihre Korrektur ein Vielfaches – wegen Altdaten, Schnittstellen und angeschlossener Auswertungen. Umgekehrt zahlt sich ein fachgerechtes Modell dauerhaft aus: Prüfungen greifen vor der Bestellung, Auswertungen beantworten echte Geschäftsfragen, und Automatisierung wird überhaupt erst möglich. Der Wert einer Software entsteht in dieser Schicht; die Oberfläche macht ihn im Alltag zugänglich.
Typische Fehler
- Das Datenmodell als technisches Detail an das Entwicklungsteam delegiert – die folgenreichsten fachlichen Entscheidungen fallen dann ohne die Fachabteilung.
- Fachbegriffe als Freitext geführt – was nur als Text existiert, lässt sich weder prüfen noch auswerten noch automatisieren.
- Beziehungen zwischen Objekten weggelassen – ob ein Fahrzeuglager, eine Charge oder ein Wiederholauftrag verknüpft ist, entscheidet über die Aussagekraft des Systems.
- Das Modell an der Oberfläche beurteilt – ansprechende Masken sagen nichts darüber, welche Objekte und Regeln darunter liegen.
- Korrekturen aufgeschoben, weil das System läuft – mit jedem Monat wachsen die Altdaten, die eine spätere Umstellung nachziehen muss.
Worauf achten?
- Früh im Projekt gemeinsam mit der Fachabteilung festlegen, welche Begriffe eigene Objekte werden – mit fachlicher Begründung je Entscheidung.
- Die Faustregel anwenden: Was geprüft, ausgewertet oder automatisiert werden soll, braucht ein eigenes Objekt.
- Anbieter das Datenmodell erklären lassen – wer es als internes Detail behandelt, hat die Fachlichkeit womöglich nicht abgebildet.
- Sonderfälle gegen das Modell testen: Lässt sich eine Teillieferung, ein Storno nach Freigabe, eine geteilte Charge abbilden?
- Zusatzfeld-Sammlungen regelmäßig sichten – wachsende Freifeld-Gruppen zeigen ein fehlendes Objekt an.
Häufig gestellte Fragen
Was ist ein Datenmodell?
Die Festlegung, welche Begriffe eines Einsatzgebiets in einer Software als eigenständige Objekte mit Feldern, Regeln und Beziehungen geführt werden und welche als bloße Merkmale. Sie bestimmt, was das System prüfen, auswerten und automatisieren kann.
Warum ist das Datenmodell so schwer zu ändern?
Weil im laufenden Betrieb alle vorhandenen Daten im alten Modell gespeichert sind und Schnittstellen wie Auswertungen darauf aufbauen. Eine Änderung verlangt die Migration der Altdaten und die Anpassung aller angeschlossenen Stellen – ein Aufwand, der mit jedem Betriebsjahr wächst.
Wer sollte am Datenmodell mitarbeiten?
Fachabteilung und Entwicklung gemeinsam. Die fachliche Frage, welche Begriffe eigene Objekte verdienen, kann nur beantworten, wer die Branche kennt; die technische Umsetzung der Objekte und Beziehungen liegt bei der Entwicklung.
Woran erkenne ich ein schwaches Datenmodell im Alltag?
An Freitextfeldern für Dinge, die eigentlich Regeln haben, an wachsenden Zusatzfeld-Sammlungen, an Auswertungen, die niemand erstellen kann, und an Arbeit, die in Nebenlisten außerhalb des Systems stattfindet.