Datenmodellierung, die Bestand hat

Wenn man ein langlebiges System aufmerksam betrachtet, fällt eine Ordnung der Beständigkeit auf. Das Äußerste — die Oberfläche — ändert sich am häufigsten. Darunter liegt das Framework, das man über die Jahre aktualisiert oder tauscht. Noch tiefer die Datenbank, die man mit Mühe ersetzen kann. Und ganz unten, am beständigsten von allem, liegt die Form der Daten selbst: welche Dinge es gibt, wie sie zusammenhängen, wodurch sie sich unterscheiden. Diese Form überdauert alles darüber — und deshalb entscheidet sie über die Langlebigkeit mehr als jede andere Wahl.

Dieses Dokument behandelt das Datenmodell als das, was es ist: das Fundament, auf dem ein System steht. Es ist bewusst datenbank- und framework-neutral gehalten, weil es von der Struktur der Daten handelt, nicht von der Technik, die sie speichert. Andere Texte dieser Sammlung verweisen immer wieder auf das Datenmodell als die eigentlich entscheidende Schicht; dieser Text ist der, der sie ausführt. Genannt werden keine Zahlen.

1. Warum das Datenmodell alles überdauert

Ein Datenmodell überdauert die Technik um es herum, weil es nicht die Technik abbildet, sondern die Wirklichkeit, die das System verwaltet. Ein Kunde, eine Bestellung, ein Vertrag, ein Vorgang — diese Dinge und ihre Beziehungen ändern sich weit langsamer als die Frameworks, mit denen man sie verarbeitet. Man kann die Oberfläche neu bauen, das Framework wechseln, sogar die Datenbank migrieren, ohne dass sich ändert, was ein Kunde ist und wie er zu einer Bestellung steht. Genau darin liegt die Beständigkeit des Modells: Es ist der Technik gegenüber gleichgültig.

Daraus folgt die Rangordnung der Sorgfalt. Weil das Datenmodell am längsten lebt und alles über ihm trägt, verdient es die meiste Aufmerksamkeit beim Entwurf — mehr als die Wahl des Frameworks, mehr als die der Datenbank, mehr als die Gestaltung der Oberfläche. Ein Fehler in der Oberfläche kostet einen Umbau; ein Fehler im Datenmodell kostet einen Umbau von allem, was darauf steht. Wer die Reihenfolge der Sorgfalt umkehrt und lange über das Framework streitet, während das Modell nebenbei entsteht, hat die Kräfte falsch verteilt.

Schema: Je tiefer die Schicht, desto länger lebt sie. Das Datenmodell ganz unten überdauert Oberfläche, Framework und Datenbank — und trägt sie alle.

Trade-off. Dem Datenmodell die meiste Sorgfalt zu geben bedeutet, mehr Zeit in etwas zu investieren, das im ersten Eindruck unsichtbar bleibt — man sieht die Oberfläche, nicht das Modell darunter.

Kosten. Ein durchdachtes Modell entsteht langsamer als eine schnell hingeworfene Tabellenstruktur und verlangt Erfahrung, die man nicht überspringen kann.

Wann wir anders entscheiden. Für einen Wegwerf-Prototyp, dessen Daten nie in ein langlebiges System übernommen werden, ist die volle Sorgfalt überzogen — dort zählt Geschwindigkeit, und das Modell darf grob bleiben.

2. Die Domäne modellieren, nicht die Oberfläche

Der häufigste und folgenreichste Fehler ist, die Daten nach dem zu formen, was gerade auf dem Bildschirm oder in der Schnittstelle gebraucht wird. Ein Formular hat bestimmte Felder, also legt man eine Tabelle mit genau diesen Feldern an; eine Ansicht zeigt eine bestimmte Zusammenstellung, also speichert man die Daten in dieser Zusammenstellung. Das ist verlockend, weil es kurzfristig am wenigsten Arbeit macht — und langfristig teuer, weil Oberflächen sich ändern und das Modell dann nicht mehr passt.

Das Datenmodell soll die Domäne abbilden, nicht die Oberfläche: die Dinge, wie sie in der Wirklichkeit sind und zusammenhängen, unabhängig davon, wie sie heute angezeigt oder abgefragt werden. Ein Modell, das die Domäne trifft, überlebt jede Neugestaltung der Oberfläche, weil die Domäne stabil ist, während die Ansicht wechselt. Ein Modell, das die Oberfläche spiegelt, muss mit jeder Änderung der Oberfläche mitwandern — und wird bei der ersten größeren Umgestaltung zum Hindernis. Die Frage ist nicht „welche Felder zeigt der Bildschirm?", sondern „was ist dieses Ding wirklich, und wozu steht es in Beziehung?".

Trade-off. Die Domäne zu modellieren statt der Oberfläche kostet anfangs mehr Nachdenken — man muss verstehen, was ein Ding wirklich ist, statt nur abzuschreiben, was das Formular zeigt.

Kosten. Ein domänennahes Modell verlangt manchmal eine Übersetzung zwischen der Form der Daten und der Form der Anzeige, die man sonst gespart hätte.

Wann wir anders entscheiden. Wo eine Anzeige und die Domäne wirklich deckungsgleich sind und es dauerhaft bleiben, ist die Trennung überkonstruiert; man modelliert dann einfach, was ohnehin beides zugleich ist.

3. Modellieren für Veränderung

Ein Datenmodell, das ein Jahrzehnt tragen soll, muss sich ändern lassen, denn die Domäne wächst und verschiebt sich mit der Zeit. Wie bei jeder langlebigen Struktur ist die Kunst nicht, die Zukunft vorherzusagen, sondern das Modell so anzulegen, dass Veränderung billig bleibt. Das heißt vor allem: additiv wachsen können. Ein neues Merkmal kommt als neues Feld oder als neue, verbundene Sache hinzu, ohne die Bedeutung des Bestehenden zu verschieben. Ein Modell, das nur durch Umbau des Vorhandenen wachsen kann, wird mit jeder Änderung riskanter.

Dazu gehört, nicht mehr festzulegen, als man weiß. Ein Modell, das früh jede denkbare Eigenschaft in eine feste Struktur presst, ist gegen die eine Eigenschaft spröde, die man nicht bedacht hat. Zurückhaltung im Modell — nur festschreiben, was die Domäne wirklich verlangt, und Raum lassen für das, was noch nicht klar ist — ist dieselbe Haltung wie die Reversibilität in der Architektur: das Umkehrbare billig halten, das Unumkehrbare spät und bewusst festlegen. Denn eine Änderung am Datenmodell eines laufenden Systems gehört zu den unumkehrbarsten Eingriffen überhaupt — sie berührt jeden bestehenden Datensatz.

Trade-off. Für Veränderung zu modellieren bedeutet, weniger festzuschreiben und allgemeiner zu bleiben — das Modell ist anfangs weniger eng auf den heutigen Fall zugeschnitten.

Kosten. Ein änderbares Modell verlangt Disziplin bei jeder Erweiterung, damit das additive Wachstum nicht in Wildwuchs kippt, und die Bereitschaft, Struktur erst dann festzulegen, wenn sie klar ist.

Wann wir anders entscheiden. Wo eine Struktur durch Gesetz oder einen unveränderlichen äußeren Vertrag feststeht, legt man sie fest und ausführlich fest; Offenheit gegen etwas Unveränderliches wäre verschwendet.

4. Identität und Beziehungen

Zwei Entscheidungen im Datenmodell sind dauerhafter als alle anderen: wodurch ein Ding eindeutig ist, und wie Dinge zueinander stehen. Die Identität — was einen Datensatz zu genau diesem macht und von allen anderen unterscheidet — ist die Grundlage, auf der jede Beziehung, jede Referenz, jede Zusammenführung ruht. Eine schlecht gewählte Identität — eine, die sich ändern kann, die nicht wirklich eindeutig ist, die etwas Fachliches mit etwas Technischem vermischt — vergiftet das ganze Modell, weil alles auf ihr aufsetzt. Identität ist die Entscheidung, die man am schwersten zurücknimmt.

Schema: Die Identität macht jedes Ding unterscheidbar; die Beziehungen sagen, wie die Domäne funktioniert. Beides hält am längsten und ist am teuersten zu ändern.

Die Beziehungen sind die zweite dauerhafte Schicht: welche Dinge zu welchen gehören, ob eines zu vielen steht oder viele zu vielen, ob eine Verbindung Pflicht ist oder möglich. Diese Struktur bildet die eigentliche Aussage des Modells darüber, wie die Domäne funktioniert — und sie zu ändern heißt fast immer, bestehende Daten umzustellen, nicht nur neuen Code zu schreiben. Deshalb verdienen Identität und Beziehungen die größte Sorgfalt im ganzen Entwurf: Sie sind das, was am längsten hält und am teuersten zu korrigieren ist. Wer sie richtig trifft, hat das Modell im Kern richtig; wer sie verfehlt, trägt den Fehler durch die ganze Lebensdauer.

Trade-off. Identität und Beziehungen sorgfältig zu wählen kostet die meiste Denkzeit im Entwurf — gegen den Gewinn, dass der beständigste Teil des Modells von Anfang an trägt.

Kosten. Diese Sorgfalt verlangt, die Domäne wirklich zu verstehen, bevor man festlegt — eine Arbeit, die man nicht abkürzen kann, ohne sie später teuer nachzuholen.

Wann wir anders entscheiden. Wo ein Ding offensichtlich und stabil identifiziert ist und seine Beziehungen eindeutig sind, entscheidet man zügig; die volle Sorgfalt gilt den Fällen, in denen Identität oder Beziehung nicht auf den ersten Blick klar sind.

5. Normalisierung und ihr pragmatisches Maß

Die klassische Disziplin der Datenmodellierung ist die Normalisierung: jede Tatsache genau einmal speichern, an einem maßgeblichen Ort, sodass es keine widersprüchlichen Kopien geben kann. Das ist dieselbe Idee wie „eine Wissenseinheit, eine Darstellung" — angewandt auf Daten. Ein normalisiertes Modell ist wahrheitsgemäß: Es kann sich nicht selbst widersprechen, weil jede Tatsache nur einen Ort hat. Für die Korrektheit über Jahre ist das ein hoher Wert, denn widersprüchliche Daten sind eine der zähesten Fehlerquellen überhaupt.

Wie jedes Prinzip hat auch dieses sein Maß. Strikte Normalisierung kann Abfragen umständlich und teuer machen, und es gibt Fälle, in denen eine bewusste, kontrollierte Redundanz die bessere Wahl ist — solange man weiß, dass man sie eingeht, und dafür sorgt, dass die Kopien stimmig bleiben. Die Kunst ist nicht, dogmatisch zu normalisieren oder dogmatisch zu vereinfachen, sondern die Frage zu stellen: Ist diese Tatsache hier maßgeblich oder nur eine Kopie? Und wenn eine Kopie: Wer hält sie stimmig? Ein Modell, das diese Fragen bewusst beantwortet, ist beständig; eines, das Redundanz unbemerkt anhäuft, driftet mit der Zeit in Widersprüche.

Trade-off. Strenge Normalisierung kauft Widerspruchsfreiheit mit umständlicheren Abfragen; bewusste Redundanz kauft Einfachheit mit der Pflicht, Kopien stimmig zu halten.

Kosten. Beide bewussten Wege verlangen, die Entscheidung zu treffen und zu dokumentieren; der teure Fall ist die dritte, unbewusste Variante, in der Redundanz unbemerkt aufläuft.

Wann wir anders entscheiden. Wo Korrektheit über allem steht — Geld, Recht, Bestand —, normalisiert man streng; wo eine gemessene Leselast die Zusammenführung zu teuer macht, geht man kontrollierte Redundanz ein und benennt, wer sie stimmig hält.

6. Die Kosten eines falschen Modells

Ein falsches Datenmodell ist der teuerste Fehler, den ein System tragen kann, weil alles auf ihm aufsetzt. Ein Fehler in der Oberfläche ist lokal; ein Fehler in der Geschäftslogik ist begrenzt; ein Fehler im Datenmodell ist überall, denn jede Zeile Code, die mit den Daten arbeitet, hat die falsche Struktur angenommen. Und schlimmer noch: Das falsche Modell füllt sich mit Daten. Mit jedem Tag, an dem ein System läuft, wächst der Bestand, der in der falschen Form vorliegt — und den man bei einer Korrektur nicht wegwerfen, sondern überführen muss.

Das erklärt, warum ein Datenmodell so viel Sorgfalt im Voraus verdient: Seine Korrektur ist nicht nur eine Codeänderung, sondern eine Migration jedes bestehenden Datensatzes, oft bei laufendem Betrieb — eine der anspruchsvollsten und riskantesten Operationen überhaupt. Ein früh richtig getroffenes Modell erspart diese Operation; ein früh falsch getroffenes erzwingt sie irgendwann, zu einem Zeitpunkt, an dem der Bestand groß und das System kritisch ist. Die Sorgfalt, die man am Anfang investiert, ist die Versicherung gegen die teuerste Reparatur, die ein System kennt.

Trade-off. Die hohen Kosten eines falschen Modells ernst zu nehmen bedeutet, am Anfang langsamer zu sein — gegen die Gewissheit, die ungleich teurere Korrektur später zu vermeiden.

Kosten. Die anfängliche Sorgfalt konkurriert mit dem Druck, schnell etwas Sichtbares zu liefern, und zahlt sich erst über die Jahre aus.

Wann wir anders entscheiden. Bei einem absehbar kurzlebigen System, dessen Daten nie überführt werden müssen, ist die volle Vorsicht überzogen; ihr Wert steigt mit der erwarteten Lebensdauer und der Kritikalität des Bestands.

7. Das Modell weiterentwickeln

So beständig ein Datenmodell ist — unveränderlich ist es nicht, und die Fähigkeit, es sicher weiterzuentwickeln, ist Teil seiner Langlebigkeit. Die Disziplin dafür ist dieselbe, die auch die riskanteste Änderung beherrschbar macht: in kleinen, umkehrbaren Schritten, additiv statt im Bestand umbauend, das Alte und das Neue eine Zeit lang nebeneinander. Man fügt die neue Form hinzu, überführt den Bestand geprüft, stellt den Code um und entfernt die alte Form erst, wenn nichts mehr auf ihr steht. So bleibt eine Modelländerung ein geordneter Vorgang statt eines Sprungs ins Ungewisse — ausgeführt bei laufendem Betrieb, ohne Stillstand.

Diese Weiterentwicklung ist so wichtig, dass sie den Entwurf beeinflussen sollte: Ein Modell, das man leicht additiv erweitern kann, ist einem überlegen, das jede Änderung zum Umbau macht — selbst wenn beide heute dasselbe leisten. Änderbarkeit ist auch beim Datenmodell das eigentliche Maß, nicht die momentane Eleganz. Die konkrete Mechanik dieser geprüften, umkehrbaren Überführung behandelt ein eigener Text ausführlich; für den Entwurf zählt, das Modell von Anfang an so anzulegen, dass diese Mechanik überhaupt greifen kann.

Trade-off. Für die Weiterentwicklung zu entwerfen bedeutet, additiv erweiterbare Strukturen zu bevorzugen, die nicht immer die kompakteste Lösung für heute sind.

Kosten. Eine Modelländerung bleibt auch bei bester Vorbereitung Arbeit — Überführung, Prüfung, Parallelbetrieb —, die man einplant, statt sie zu unterschätzen.

Wann wir anders entscheiden. Wo ein Modell mit hoher Sicherheit nie erweitert wird, darf es kompakter und enger sein; die Vorsorge für Änderung lohnt dort, wo die Domäne absehbar wächst.

8. Wo Modell und Code auseinanderlaufen

Ein Datenmodell lebt an zwei Orten zugleich: als Struktur in der Datenbank und als Abbildung im Code, der mit ihr arbeitet. Diese beiden müssen dasselbe über dieselbe Sache aussagen — und weil sie unabhängig geändert werden können, ist ihr Auseinanderlaufen eine wiederkehrende, tückische Fehlerquelle. Ändert sich die eine Seite, ohne dass die andere folgt, entstehen Fehler, deren Wirkung sich weit von ihrer Ursache zeigt und die deshalb schwer zu finden sind. Das beständige Datenmodell nützt wenig, wenn seine Abbildung im Code still von ihm abweicht.

Die Konsequenz für den Entwurf ist, diese Kopplung sichtbar und prüfbar zu halten, statt auf die Aufmerksamkeit Einzelner zu bauen: Eine Abweichung zwischen der Struktur und ihrer Abbildung sollte früh und laut auffallen, nicht spät als rätselhaftes Symptom. Das Datenmodell ist damit nicht nur eine Frage des Entwurfs, sondern auch der Disziplin im Betrieb — die beiden Darstellungen desselben Modells zusammenzuhalten. Wer diese stille Kopplung ernst nimmt, erspart sich eine ganze Klasse zäher Fehler.

Trade-off. Die Kopplung sichtbar zu machen kostet eine zusätzliche Absicherung, die gepflegt werden will — gegen den Gewinn, dass ein Auseinanderlaufen früh und nahe an der Ursache auffällt.

Kosten. Jede Prüfung ist Aufwand, und den Moment einer Änderung an Struktur oder Abbildung macht sie etwas schwerfälliger, weil nun beides zusammenpassen muss.

Wann wir anders entscheiden. In einem sehr kleinen System, dessen Modell ein Einzelner mühelos im Blick behält, genügt die Aufmerksamkeit; die Absicherung lohnt sich, sobald viele Hände am selben Modell arbeiten.

9. Typische Fehler

Die wiederkehrenden Muster, an denen Datenmodelle scheitern — fast alle sind Varianten davon, das Beständige wie etwas Beiläufiges zu behandeln:

• Das Modell nach der Oberfläche formen statt nach der Domäne — und bei der ersten Neugestaltung feststellen, dass es nicht mehr passt.
• Dem Framework und der Datenbank mehr Sorgfalt geben als dem Modell, das beide überdauert.
• Identität schlecht wählen — veränderlich, nicht wirklich eindeutig, Fachliches mit Technischem vermischt — und den Fehler durch das ganze Modell tragen.
• Beziehungen ungenau festlegen und ihre spätere Korrektur mit der teuren Umstellung des Bestands bezahlen.
• Redundanz unbemerkt anhäufen, bis das Modell in Widersprüche driftet.
• Früh zu viel festschreiben und gegen die eine Anforderung spröde sein, die man nicht bedacht hat.
• Das Modell so anlegen, dass jede Änderung ein Umbau ist, statt additiv erweitern zu können.
• Struktur und Abbildung im Code auseinanderlaufen lassen, weil niemand die stille Kopplung sichtbar gemacht hat.
• Die Kosten eines falschen Modells unterschätzen und die Sorgfalt am Anfang sparen, wo sie am wertvollsten wäre.

10. Entscheidungs-Checkliste

Vor und während des Entwurfs eines Datenmodells der Reihe nach zu klären:

• Domäne oder Oberfläche? Bildet das Modell ab, was die Dinge wirklich sind — oder nur, was ein Bildschirm gerade zeigt?
• Sorgfalt richtig verteilt? Bekommt das Modell mehr Aufmerksamkeit als Framework und Datenbank, die es überdauern wird?
• Identität tragfähig? Ist jede Sache durch etwas Stabiles, wirklich Eindeutiges identifiziert, das Fachliches nicht mit Technischem vermischt?
• Beziehungen klar? Ist festgelegt, welche Dinge wie zueinander stehen — und ist das der Domäne treu, nicht der momentanen Ansicht?
• Additiv erweiterbar? Kann das Modell wachsen, ohne die Bedeutung des Bestehenden zu verschieben?
• Redundanz bewusst? Ist jede Kopie einer Tatsache gewollt und hat einen benannten Ort, der sie stimmig hält?
• Weiterentwicklung bedacht? Lässt sich das Modell in kleinen, umkehrbaren Schritten ändern, bei laufendem Betrieb?
• Kopplung sichtbar? Fällt ein Auseinanderlaufen von Struktur und Abbildung im Code früh und nahe an der Ursache auf?

Wer diese Fragen beantworten kann, hat ein Modell entworfen, das trägt — nicht eines, das bei der ersten Änderung nachgibt.

FAQ

Warum ist das Datenmodell wichtiger als die Wahl der Datenbank oder des Frameworks? Weil es beide überdauert. Man kann das Framework aktualisieren, die Oberfläche neu bauen, sogar die Datenbank migrieren, ohne dass sich ändert, was ein Kunde ist und wie er zu einer Bestellung steht. Die Form der Daten bleibt und trägt alles darüber — deshalb entscheidet sie über die Langlebigkeit mehr als jede Technikwahl.

Was heißt „die Domäne modellieren statt der Oberfläche"? Die Daten nach dem zu formen, was die Dinge wirklich sind und wie sie zusammenhängen, nicht nach dem, was ein Formular oder eine Ansicht gerade zeigt. Ein domänennahes Modell überlebt jede Neugestaltung der Oberfläche, weil die Domäne stabil ist; ein oberflächennahes Modell muss mit jeder Anzeigenänderung mitwandern und wird bald zum Hindernis.

Warum sind Identität und Beziehungen so entscheidend? Weil auf ihnen alles aufsetzt und sie am teuersten zu korrigieren sind. Eine schlecht gewählte Identität — veränderlich oder nicht wirklich eindeutig — vergiftet jede Referenz, die auf ihr ruht. Eine falsche Beziehung zu ändern heißt fast immer, bestehende Daten umzustellen. Diese Entscheidungen halten am längsten und verzeihen am wenigsten.

Sollte man immer streng normalisieren? Als Grundhaltung ja, weil ein normalisiertes Modell sich nicht selbst widersprechen kann. Aber es hat sein Maß: Wo eine gemessene Leselast die Zusammenführung zu teuer macht, ist bewusste, kontrollierte Redundanz vertretbar — solange man weiß, dass man sie eingeht, und benennt, wer die Kopien stimmig hält. Der teure Fall ist die unbewusste Redundanz, die in Widersprüche driftet.

Was macht ein falsches Datenmodell so teuer? Dass alles auf ihm aufsetzt und dass es sich mit Daten füllt. Ein Modellfehler betrifft jede Zeile Code, die mit den Daten arbeitet, und jede Korrektur ist nicht nur eine Codeänderung, sondern die Überführung jedes bestehenden Datensatzes — oft bei laufendem Betrieb. Es ist die teuerste Reparatur, die ein System kennt, und die anfängliche Sorgfalt ist die Versicherung dagegen.

Wie ändert man ein Datenmodell sicher? In kleinen, umkehrbaren Schritten: die neue Form additiv hinzufügen, den Bestand geprüft überführen, den Code umstellen, die alte Form erst entfernen, wenn nichts mehr auf ihr steht — bei laufendem Betrieb, ohne Stillstand. Dieselbe Disziplin, die Datenbankmigrationen beherrschbar macht, gilt für jede Änderung am Modell.

Weiterführend

• Software, die in zehn Jahren noch läuft — warum Langlebigkeit die Grundfrage ist, deren tiefste Schicht das Datenmodell bildet.
• PostgreSQL oder MySQL für langlebige Systeme — warum das Modell mehr entscheidet als die Wahl der Datenbank.
• Zero-Downtime-Datenbankmigrationen — die Mechanik, ein Modell bei laufendem Betrieb umkehrbar weiterzuentwickeln.
• Als Schema und Modell auseinanderliefen — was geschieht, wenn Struktur und Abbildung still voneinander abweichen.

Grundlage ist die Batunet Engineering Method: die Domäne modellieren, für Veränderung bauen, dem Beständigsten die meiste Sorgfalt geben.

Abschließendes Engineering-Prinzip

Wer ein System für ein Jahrzehnt baut, baut zuerst sein Datenmodell — denn das ist das Einzige, das mit ziemlicher Sicherheit ein Jahrzehnt bleibt. Alles darüber wird man ersetzen: die Oberfläche mehrmals, das Framework vielleicht, die Datenbank womöglich. Die Form der Daten überlebt sie alle, weil sie nicht die Technik abbildet, sondern die Wirklichkeit, die das System verwaltet. Deshalb ist die Datenmodellierung nicht ein Schritt unter vielen, sondern die Entscheidung, die am tiefsten trägt und am längsten hält. Man erkennt gute Ingenieure oft nicht an der Oberfläche, die sie bauen, sondern an dem Modell darunter, das noch trägt, wenn die Oberfläche längst dreimal ersetzt wurde.

Die Oberfläche ist das, was man sieht; das Datenmodell ist das, was bleibt. Man baut ein langlebiges System von unten nach oben — und ganz unten liegt die Form der Daten.