Eine Datenbank kann technisch einwandfrei laufen und trotzdem schlechte Antworten liefern, wenn ihre Struktur unklar ist. Beim Data Modeling wird deshalb sichtbar gemacht, welche Informationen ein System enthält, wie sie zusammenhängen und welche Regeln für ihre Nutzung gelten. Ich zeige, wie aus einer Geschäftsfrage ein belastbares Datenmodell entsteht, wann relationale Tabellen oder ein Sternschema sinnvoll sind und welche Fehler später für falsche Analysen sorgen.
Die wichtigsten Grundlagen auf einen Blick
- Datenmodellierung beschreibt Entitäten, Attribute, Beziehungen und Regeln eines Informationssystems.
- Drei Ebenen führen vom fachlichen Überblick über die logische Struktur bis zur konkreten Datenbank.
- Normalisierung reduziert doppelte Daten und schützt vor widersprüchlichen Änderungen.
- Sternschemas erleichtern Berichte und Analysen mit Fakten- und Dimensionstabellen.
- Gute Modelle beginnen mit Geschäftsfragen, klaren Definitionen und überprüfbaren Datenqualitätsregeln.
Was Datenmodellierung im Alltag wirklich leistet
Ein Datenmodell ist eine visuelle und fachliche Beschreibung eines Informationssystems. Es zeigt zum Beispiel, dass ein Kunde mehrere Bestellungen aufgeben kann, jede Bestellung aus mehreren Positionen besteht und jede Position auf ein bestimmtes Produkt verweist. Damit wird aus einer unübersichtlichen Sammlung von Spalten ein nachvollziehbares Bild der Realität.
Ich sehe den größten Nutzen nicht im Diagramm selbst, sondern in den Entscheidungen, die dadurch früher sichtbar werden. Wer festlegt, was genau als Kunde, Umsatz oder aktive Bestellung gilt, verhindert später widersprüchliche Reports. Das Modell schafft damit eine gemeinsame Sprache für Fachabteilung, Entwicklung, Datenanalyse und Management.
Ohne diese Abstimmung entstehen typische Probleme. Kundendaten werden mehrfach gespeichert, Datumsfelder bedeuten in verschiedenen Tabellen etwas anderes oder ein Umsatzbericht zählt stornierte Bestellungen mit. Ein sauberer Entwurf verbessert deshalb Datenqualität, Wartbarkeit und Analysegeschwindigkeit zugleich.
Die drei Ebenen eines belastbaren Datenmodells
Das konzeptionelle Modell
Auf der konzeptionellen Ebene geht es um die großen fachlichen Begriffe. Man hält fest, dass es Kunden, Produkte, Bestellungen und Zahlungen gibt, ohne sich bereits auf Tabellen, Datentypen oder ein bestimmtes Datenbanksystem festzulegen. Diese Ebene eignet sich besonders gut für Gespräche mit Personen, die nicht täglich SQL schreiben.
Das logische Modell
Das logische Modell wird präziser. Es beschreibt Attribute, Primärschlüssel und Beziehungen zwischen den Entitäten. Ein Primärschlüssel identifiziert einen Datensatz eindeutig, während ein Fremdschlüssel auf einen Datensatz in einer anderen Tabelle verweist. Auch Kardinalitäten werden festgelegt, etwa „ein Kunde hat null bis viele Bestellungen“.
Das physische Modell
Erst hier wird entschieden, wie die Struktur in PostgreSQL, SQL Server, einer Cloud-Datenbank oder einem Dokumentenspeicher umgesetzt wird. Dazu gehören Datentypen, Indizes, Partitionen, Namenskonventionen und Zugriffsrechte. Das physische Modell muss deshalb nicht nur fachlich korrekt, sondern auch auf Speicher, Abfragen und erwartete Datenmengen abgestimmt sein.
| Ebene | Leitfrage | Typisches Ergebnis |
|---|---|---|
| Konzeptionell | Welche Dinge und Vorgänge gibt es? | Entitäten und grobe Beziehungen |
| Logisch | Welche Eigenschaften und Regeln gelten? | Attribute, Schlüssel und Kardinalitäten |
| Physisch | Wie wird die Struktur technisch gespeichert? | Tabellen, Datentypen, Indizes und Partitionen |
Diese Trennung spart Zeit, weil fachliche Entscheidungen nicht sofort von einer bestimmten Technologie abhängig gemacht werden. Gleichzeitig darf man die Ebenen nicht als einmalige Dokumentation betrachten. Ein Modell ist ein lebendes Arbeitsmittel, das sich mit Prozessen, Produkten und gesetzlichen Anforderungen weiterentwickelt.
So entsteht aus einer Geschäftsfrage ein Datenmodell
Der beste Startpunkt ist nicht die Frage „Welche Tabelle soll ich anlegen?“, sondern eine konkrete fachliche Frage. Für einen Onlinehandel könnte sie lauten: „Wie hoch war der Nettoumsatz je Produktgruppe und Monat?“ Diese Formulierung zeigt bereits, welche Daten, Zeitbezüge und Berechnungsregeln benötigt werden.
- Geschäftsprozess abgrenzen: Beschreiben Sie, ob Sie Verkäufe, Lagerbewegungen, Supportfälle oder einen anderen Prozess modellieren.
- Begriffe definieren: Klären Sie, ob Umsatz vor oder nach Rabatten, Steuern und Retouren gemeint ist.
- Entitäten und Ereignisse trennen: Kunde und Produkt sind Stammdaten, eine Bestellung oder Zahlung ist ein Vorgang mit Zeitbezug.
- Beziehungen festlegen: Dokumentieren Sie, welche Datensätze zusammengehören und ob eine Beziehung optional oder verpflichtend ist.
- Regeln prüfen: Testen Sie, ob jeder Datensatz eindeutig identifizierbar ist und ob wichtige Werte fehlen dürfen.
- Mit Beispieldaten testen: Verwenden Sie reale Sonderfälle wie Retouren, Gastbestellungen, zusammengelegte Kundenkonten oder Preisänderungen.
Gerade der letzte Schritt wird häufig unterschätzt. Ein Modell kann auf dem Whiteboard logisch wirken und bei einer Stornierung trotzdem falsche Ergebnisse liefern. Ich teste deshalb früh mit kleinen, absichtlich schwierigen Beispielen, statt erst nach dem Produktivstart auf Datenfehler zu stoßen.
Ein kleines Beispiel aus dem Onlinehandel
Für die Umsatzanalyse könnten die Tabellen Kunde, Bestellung, Bestellposition, Produkt und Produktgruppe benötigt werden. Die Bestellung enthält den Auftrag als Ganzes, während die Bestellposition die einzelnen Produkte, Mengen und Preise zum damaligen Zeitpunkt speichert.
Der damalige Preis gehört bewusst in die Bestellposition. Wird der aktuelle Produktpreis später geändert, darf sich dadurch der historische Umsatz nicht verändern. Dieses Detail wirkt unscheinbar, entscheidet aber darüber, ob eine Analyse belastbar bleibt.
Welche Modellform zu Datenanalyse und Datenbanken passt
Es gibt nicht die eine optimale Struktur für jedes Projekt. Eine operative Anwendung braucht häufig konsistente Transaktionen und möglichst wenig doppelte Daten. Ein Berichtssystem muss dagegen viele Datensätze schnell gruppieren, filtern und vergleichen können.
| Ansatz | Stärken | Geeignet für | Grenzen |
|---|---|---|---|
| Relationales Modell | Klare Regeln, Transaktionen und referenzielle Integrität | Geschäftsanwendungen und ERP-Systeme | Viele Verknüpfungen können Analysen komplizierter machen |
| Sternschema | Einfach verständliche Abfragen und gute BI-Performance | Data Warehouse, Power BI und Managementberichte | Redundanzen in Dimensionen sind möglich |
| Dokumentenmodell | Flexible Strukturen und verschachtelte Datensätze | Variable Inhalte und bestimmte Webanwendungen | Globale Konsistenz und komplexe Beziehungen sind anspruchsvoller |
| Graphmodell | Direkte Analyse komplexer Beziehungen | Netzwerke, Empfehlungen und Abhängigkeiten | Für klassische Summenberichte oft unnötig komplex |
Normalisierung für operative Systeme
Bei der Normalisierung werden Daten so verteilt, dass Informationen möglichst nur an einer passenden Stelle stehen. Die Adresse eines Kunden sollte beispielsweise nicht in jeder Bestellung vollständig wiederholt werden. Das reduziert Widersprüche und erleichtert Änderungen.
Zu starke Normalisierung kann Abfragen allerdings schwer lesbar machen. Für operative Systeme ist sie meist sinnvoll, während analytische Modelle oft gezielt denormalisiert werden. Denormalisierung bedeutet, bestimmte Informationen zu wiederholen, damit Berichte mit weniger Verknüpfungen schneller und verständlicher laufen.
Sternschema für Berichte
Ein Sternschema besitzt eine zentrale Faktentabelle, etwa mit Umsatz, Menge und Rabatt, sowie mehrere Dimensionstabellen für Datum, Produkt, Kunde oder Region. Die Fakten beantworten „wie viel“, die Dimensionen erklären „wann, was, wer und wo“.
Für ein Data Warehouse ist dieser Ansatz oft sehr praktisch, weil Analysewerkzeuge die Struktur leicht verstehen. Er ersetzt aber keine saubere Definition der Kennzahlen. Ein schnelles Modell, das Umsatz und Retouren falsch verrechnet, bleibt fachlich wertlos.
Woran Datenmodelle in der Praxis häufig scheitern
Unklare Begriffe
Wenn „Kunde“ einmal eine registrierte Person und an anderer Stelle ein Unternehmen bezeichnet, entstehen zwangsläufig widersprüchliche Auswertungen. Ein Glossar mit wenigen, verbindlichen Definitionen wirkt oft stärker als ein besonders komplexes Diagramm.
Zu frühe Technikentscheidungen
Wer direkt mit Tabellen, JSON-Feldern oder Cloud-Partitionen beginnt, überspringt die fachliche Klärung. Ich halte es für deutlich effektiver, zuerst Prozesse und Regeln zu beschreiben und erst danach zu entscheiden, welche Technologie sie am besten unterstützt.
Fehlende Zeitdimension
Viele Modelle speichern nur den aktuellen Zustand. Für Analysen braucht man jedoch häufig die Entwicklung über die Zeit, etwa frühere Produktpreise, Kundenadressen oder Organisationszugehörigkeiten. Dafür sind Gültigkeitszeiträume und Änderungsregeln nötig.
Keine Datenqualitätsregeln
Ein Feld kann technisch vorhanden sein und trotzdem unbrauchbar bleiben. Legen Sie deshalb fest, welche Werte Pflicht sind, welche Kombinationen erlaubt sind und wie Dubletten erkannt werden. Für kritische Kennzahlen sollten zusätzlich automatische Prüfungen und Stichproben eingeplant werden.
Lesen Sie auch: Datenmanagement - So werden Ihre Daten wirklich nutzbar
Das Modell wird nicht gepflegt
Ein veraltetes Diagramm ist gefährlicher als kein Diagramm, weil es falsche Sicherheit vermittelt. Verantwortliche sollten Änderungen an Tabellen, Kennzahlen und Geschäftsprozessen dokumentieren. Bei häufigen Änderungen lohnt sich eine versionierte Modellbeschreibung, die gemeinsam mit dem Quellcode gepflegt wird.
Der beste erste Schritt ist eine überprüfbare Fachfrage
Für ein neues Projekt genügt zunächst ein Blatt mit den wichtigsten Geschäftsobjekten, ihren Beziehungen und drei bis fünf konkreten Analysefragen. Erst wenn diese Fragen mit Beispieldaten eindeutig beantwortbar sind, sollte die technische Umsetzung beginnen.
Mein wichtigster Rat lautet, fachliche Klarheit höher zu bewerten als Diagrammkomplexität. Ein einfaches Modell mit eindeutigen Begriffen, korrekten Zeitbezügen und getesteten Regeln ist langfristig wertvoller als eine beeindruckende Darstellung, die niemand im Alltag versteht.
