Datenmodell
Wer Daten speichert, braucht eine Beschreibung dessen, was gespeichert wird, wie die Teile zusammenhängen und welche Regeln gelten. Diese Beschreibung heißt Datenmodell. Sie ist die Grundlage für jede Datenbank, jede Schnittstelle und jedes System, das strukturiert mit Informationen arbeitet.
Was ein Datenmodell beschreibt
Ein Datenmodell legt fest, welche Gegenstände (Entitäten) in einem System existieren, welche Eigenschaften (Attribute) sie tragen und welche Beziehungen (Relationen) zwischen ihnen bestehen. Es definiert außerdem Regeln: Pflichtfelder, eindeutige Schlüssel, gültige Wertebereiche.
Beispiel: Ein Online-Shop modelliert die Entitäten "Kunde", "Bestellung" und "Produkt". Das Attribut "E-Mail" gehört zum Kunden. Die Beziehung "enthält" verbindet Bestellung und Produkt. Eine Regel besagt: Jede Bestellung gehört zu genau einem Kunden.
Beispiel: Ein Content-Management-System beschreibt "Seite", "Kategorie" und "Autor". Die Seite hat Attribute wie Titel, Slug und Veröffentlichungsdatum. Die Beziehung zwischen Seite und Kategorie ist n:m, weil eine Seite in mehreren Kategorien erscheinen kann.
Das Datenmodell trennt die fachliche Struktur von der technischen Umsetzung. Es beschreibt das "Was", nicht das "Wie". Die gleiche Modellierung kann in einer relationalen Tabelle, einem Dokumentenspeicher oder einem Graphen realisiert werden.
Drei Abstraktionsebenen der Modellierung
Die Modellierung verläuft in drei Stufen. Jede Stufe fügt technische Details hinzu und entfernt fachliche Mehrdeutigkeiten.
Konzeptionelles Modell
Die erste Stufe beschreibt die Domäne in der Sprache der Fachleute. Es entstehen Entitäten mit Namen und Beziehungen, aber keine Datentypen oder Schlüssel. Das bekannteste Format ist das Entity-Relationship-Diagramm (ER-Diagramm), eingeführt 1976 von Peter Chen.
Beispiel: In einem Krankenhaus-Informationssystem identifiziert das konzeptionelle Modell die Entitäten "Patient", "Arzt", "Behandlung" und "Station". Die Beziehung "wird behandelt von" verbindet Patient und Arzt. Datentypen oder Indexe existieren auf dieser Ebene nicht.
Logisches Modell
Die zweite Stufe übersetzt das konzeptionelle Modell in eine formale Struktur. Hier entstehen Tabellen, Spalten, Primärschlüssel und Fremdschlüssel. Normalisierung entfernt Redundanzen. Das logische Modell ist unabhängig von einem bestimmten Datenbanksystem.
Beispiel: Die Entität "Bestellung" wird zur Tabelle orders mit den Spalten order_id (Primärschlüssel), customer_id (Fremdschlüssel), order_date und total_amount. Die n:m-Beziehung zwischen Bestellung und Produkt erfordert eine Zwischentabelle order_items.
Physisches Modell
Die dritte Stufe beschreibt die konkrete Implementierung: Speicher-Engine, Partitionierung, Index-Strategie, Datentypen mit Längenangaben. Das physische Modell ist an ein bestimmtes Datenbanksystem gebunden.
Beispiel: Die Spalte order_date wird als DATETIME in MySQL oder als TIMESTAMPTZ in PostgreSQL implementiert. Ein zusammengesetzter Index auf (customer_id, order_date) beschleunigt Abfragen nach Bestellungen eines Kunden in einem Zeitraum.
Fachliche Einordnung: Die Dreiteilung geht auf das ANSI/SPARC-Modell (1975) zurück. In der Praxis verschwimmen die Grenzen: Agile Teams modellieren oft logisch und physisch gleichzeitig. Die konzeptionelle Ebene bleibt trotzdem relevant, weil sie die Kommunikation zwischen Fachbereich und Technik ermöglicht.
Modellierungsparadigmen im Vergleich
Die Wahl des Paradigmas bestimmt, wie Entitäten und Beziehungen repräsentiert werden. Jedes Paradigma hat Vorteile bei bestimmten Abfragemustern und Nachteile bei anderen.
Relationales Modell
Daten werden in Tabellen (Relationen) organisiert. Jede Zeile ist ein Datensatz, jede Spalte ein Attribut. Beziehungen entstehen durch Fremdschlüssel. SQL ist die Abfragesprache. Normalisierung reduziert Redundanz auf Kosten zusätzlicher Joins.
Beispiel: Eine Kundentabelle mit 500.000 Einträgen enthält keine Adressdaten direkt. Stattdessen verweist ein Fremdschlüssel address_id auf eine separate Adresstabelle. Das vermeidet doppelte Adressen, erfordert aber einen Join bei jeder Kundenabfrage mit Adresse.
Dokumentenmodell
Daten werden als hierarchische Dokumente gespeichert, oft im Format JSON oder BSON. Jedes Dokument kann eine andere Struktur haben (Schema-on-Read). Beziehungen werden durch Verschachtelung oder Referenzen abgebildet.
Beispiel: Ein Produktkatalog speichert jedes Produkt als Dokument mit verschachtelten Bewertungen: {"name": "Laptop", "reviews": [{"user": "A", "score": 4}, {"user": "B", "score": 5}]}. Die Abfrage "alle Bewertungen eines Produkts" erfordert keinen Join.
Graphmodell
Knoten repräsentieren Entitäten, Kanten repräsentieren Beziehungen. Jede Kante hat einen Typ und kann eigene Attribute tragen. Graphdatenbanken sind optimiert für Traversierungen: "Finde alle Personen, die mit Kunden X über maximal drei Zwischenschritte verbunden sind."
Beispiel: Ein Betrugserkennung-System modelliert Konten und Transaktionen als Graph. Eine Cypher-Abfrage findet Ringe von Konten, die innerhalb von 24 Stunden gegenseitig Geld überweisen: MATCH (a)-[:TRANSFER]->(b)-[:TRANSFER]->(c)-[:TRANSFER]->(a) WHERE ...
Datenmodelle in KI-Systemen
KI-Systeme arbeiten mit anderen Datenstrukturen als klassische Geschäftsanwendungen. Die Modellierung muss Trainingskorpora, Vektorrepräsentationen und Inferenzpipelines abbilden.
Für Trainingsdaten beschreibt das Datenmodell die Struktur jedes Datensatzes: Eingabetext, Label, Quelle, Zeitstempel, Qualitätsstufe. Bei überwachtem Lernen enthält jeder Datensatz ein Eingabe-Ausgabe-Paar. Bei Sprachmodellen besteht der Datensatz aus Textsequenzen mit Metadaten zu Herkunft und Lizenz.
Beispiel: Ein Sentiment-Analyse-Modell definiert Trainingsdaten als Tupel (text, label, source, confidence). Das Label ist eine Ganzzahl (0=negativ, 1=neutral, 2=positiv). Die Spalte confidence speichert die Übereinstimmung zwischen mehreren Annotatoren als Dezimalwert zwischen 0 und 1.
Vektordatenbanken erfordern ein eigenes Modellierungsparadigma. Jeder Eintrag besteht aus einem Identifikator, einem Vektor fester Dimensionalität und optionalen Metadaten. Das Embedding-Verfahren bestimmt die Dimensionszahl. Metadaten ermöglichen hybride Abfragen, die Vektornähe und Filterkriterien kombinieren.
Beispiel: Eine Wissensbasis für RAG speichert Chunks als Einträge. Jeder Eintrag enthält: id, vector (768 Dimensionen aus einem Sentence-Transformer), text, source_url, created_at. Die Abfrage sucht die 10 nächsten Vektoren zu einem Query-Embedding und filtert auf created_at > 2025-01-01.
Normalisierung und Denormalisierung
Normalisierung zerlegt Tabellen so, dass jede Information nur einmal gespeichert wird. Die Normalformen (1NF bis 5NF) definieren zunehmend strenge Kriterien. In der Praxis reicht die dritte Normalform (3NF) für die meisten Anwendungen.
Beispiel: Eine Tabelle orders speichert Kundennamen und Kundenadresse in jeder Zeile. Bei 10.000 Bestellungen von 500 Kunden wird jede Adresse im Durchschnitt 20-mal gespeichert. Normalisierung lagert die Adresse in eine eigene Tabelle aus und ersetzt sie durch einen Fremdschlüssel.
Denormalisierung geht den umgekehrten Weg: Sie fügt absichtlich Redundanz hinzu, um Joins zu vermeiden. Das ist sinnvoll bei leselastigen Systemen, die Antwortzeiten im niedrigen Millisekundenbereich erfordern.
Beispiel: Ein Dashboard-System für Echtzeitanalysen speichert den Produktnamen direkt in der Bestelltabelle, obwohl er bereits in der Produkttabelle steht. Die Abfrage "Top-10-Produkte der letzten Stunde" benötigt dadurch keinen Join und läuft in unter 5 Millisekunden.
Fachliche Einordnung: Die Normalformen basieren auf der Theorie funktionaler Abhängigkeiten (Codd, 1970). Die Boyce-Codd-Normalform (BCNF) ist strenger als 3NF und schließt bestimmte Anomalien aus, die 3NF noch zulässt. In der Praxis stoppen die meisten Teams bei 3NF, weil höhere Normalformen selten zusätzlichen Nutzen bringen und die Komplexität der Abfragen erhöhen.
Schema-Evolution und Versionierung
Ein Datenmodell ist kein statisches Artefakt. Anforderungen ändern sich, neue Felder kommen hinzu, alte Felder werden obsolet. Schema-Evolution beschreibt den kontrollierten Umbau eines Modells im laufenden Betrieb.
Relationale Datenbanken verwenden Migrationen: SQL-Skripte, die Spalten hinzufügen, ändern oder entfernen. Jede Migration hat eine Versionsnummer. Das System führt beim Deployment alle ausstehenden Migrationen in der richtigen Reihenfolge aus.
Beispiel: Ein ETL-System verarbeitet Daten mit Schema-Version 3. Ein neues Feld language_code wird als Migration V4 hinzugefügt. Alte Datensätze erhalten den Standardwert "de". Die Pipeline erkennt die Schemaversion jedes Datensatzes und wendet die passende Transformation an.
Dokumentendatenbanken haben einen Vorteil bei der Schema-Evolution: Weil kein festes Schema erzwungen wird, können alte und neue Dokumentformate koexistieren. Der Nachteil ist, dass die Validierung in die Anwendungslogik wandert.
Beispiel: Ein Benutzerprofil in einer Dokumentendatenbank enthält ab Version 2 ein Feld preferences. Profile aus Version 1 haben dieses Feld nicht. Die Anwendung prüft bei jedem Zugriff, ob das Feld existiert, und setzt bei Bedarf Standardwerte.
Datenqualität und Modellvalidierung
Ein Datenmodell legt fest, welche Daten gültig sind. Die Validierung geschieht auf mehreren Ebenen: Datenbankebene (Constraints), Anwendungsebene (Validierungsregeln) und Prozessebene (Monitoring).
Constraints auf Datenbankebene sind die zuverlässigste Form der Validierung, weil sie unabhängig von der Anwendungslogik greifen. Dazu gehören NOT NULL, UNIQUE, CHECK, Fremdschlüssel und Trigger.
Beispiel: Eine Tabelle measurements speichert Sensordaten mit einem CHECK-Constraint: temperature BETWEEN -50 AND 80. Ein fehlerhafter Sensor sendet den Wert 9999. Die Datenbank lehnt den Eintrag ab, bevor er gespeichert wird. Die Anwendung protokolliert die Ablehnung und benachrichtigt das Monitoring.
Bei KI-Systemen kommt eine weitere Validierungsebene hinzu: Die Konsistenz zwischen Modell-Erwartung und tatsächlichen Daten. Wenn ein Machine-Learning-Modell mit 768-dimensionalen Vektoren trainiert wurde, muss die Pipeline zur Inferenzzeit ebenfalls 768 Dimensionen liefern.
Beispiel: Ein Empfehlungssystem erwartet Nutzervektoren mit 256 Dimensionen. Nach einem Update des Embedding-Modells liefert die Pipeline 384 Dimensionen. Ohne Schema-Validierung im Datenmodell produziert das System fehlerhafte Empfehlungen, ohne einen Fehler zu melden.
Grenzen und häufige Fehleinschätzungen
Datenmodelle bilden die Realität nie vollständig ab. Jedes Modell ist eine Vereinfachung, und jede Vereinfachung verliert Information.
Die häufigste Fehleinschätzung: Ein perfektes Datenmodell lässt sich im Voraus entwerfen. In der Praxis entsteht das richtige Modell iterativ. Erst der Betrieb zeigt, welche Abfragemuster tatsächlich auftreten und wo Optimierungsbedarf besteht.
Beispiel: Ein Team modelliert eine E-Commerce-Datenbank mit strenger Normalisierung. Drei Monate nach dem Start zeigt das Monitoring, dass 80 Prozent der Abfragen einen bestimmten Drei-Tabellen-Join auslösen. Die nachträgliche Denormalisierung dieser Tabellen reduziert die Latenz von 120 auf 15 Millisekunden.
Eine weitere Grenze betrifft polyglotte Persistenz: Wenn ein System gleichzeitig relationale Daten, Dokumente und Vektoren speichert, existieren mehrere Datenmodelle parallel. Die Konsistenz zwischen diesen Modellen ist nicht durch eine einzelne Datenbank garantiert, sondern muss auf Anwendungsebene sichergestellt werden.
Fachliche Einordnung: Das CAP-Theorem (Brewer, 2000) zeigt eine fundamentale Grenze verteilter Datenmodelle: Konsistenz, Verfügbarkeit und Partitionstoleranz sind nicht gleichzeitig in vollem Umfang erreichbar. Die Wahl des Datenmodells und der Datenbank bestimmt, welche Eigenschaft bei Netzwerkpartitionen geopfert wird.