Data Modeling: Definition, Ebenen, Modelle im Überblick

Data Modeling (Datenmodellierung) beschreibt, wie Daten in einem System aufgebaut sind: welche Objekte es gibt (z. B. Kunde, Vertrag), welche Merkmale sie haben (z. B. Name, Laufzeit) und wie sie zusammenhängen. Die Disziplin arbeitet auf drei Ebenen (Fachlogik, Struktur, technische Umsetzung) und liefert den Bauplan für Datenbanken, Data Warehouses (zentrale Auswertungs-Speicher) und Data Lakehouses (moderne Kombination aus Datensee und Warehouse).

Was ist Data Modeling?

Data Modeling ist die Disziplin, mit der fachliche Sachverhalte in eine geordnete Datenstruktur übersetzt werden. Ein Datenmodell hält fest, welche Objekte (z. B. Kunde, Vertrag, Rechnung) in einem Ausschnitt der Realität existieren, welche Merkmale sie tragen (z. B. Kundennummer, Vertragsbeginn) und wie sie zusammenhängen (z. B. „ein Kunde hat mehrere Verträge"). Es dient gleichzeitig als gemeinsame Sprache zwischen Fachbereich und IT und als Bau-Anleitung für die Datenbank, das Data Warehouse oder das Data Lakehouse. Im internationalen Standardwerk [DAMA-DMBOK v2](https://www.dama.org/) ist Data Modeling & Design eines der elf kanonischen Wissensgebiete des [Data Managements](/insights/glossar/data-management/) (Dach-Disziplin für den Umgang mit Daten im Unternehmen).

Die kanonische Gliederung folgt der ANSI/SPARC-Drei-Schichten-Architektur (1975) und unterscheidet drei Abstraktions-Ebenen. Die konzeptionelle Ebene beschreibt die Fachdomäne in Entitäten und Beziehungen, unabhängig von Technologie; typische Notation ist das Entity-Relationship-Diagramm nach Peter Chen (1976) oder ein UML-Klassendiagramm. Die logische Ebene verfeinert diese Struktur mit vollständigen Attributen, Primär- und Fremdschlüsseln sowie Kardinalitäten; hier fallen die Entscheidungen zwischen Normalisierung (Codd, 1970, 1NF bis 5NF) und dimensionaler Modellierung (Kimball, 1996). Die physische Ebene setzt das logische Modell in einer konkreten Ziel-Technologie um: Tabellen, Datentypen, Indizes, Partitionierung und Cluster-Keys. Auf einem Lakehouse fließen an dieser Stelle Delta- und Iceberg-spezifische Physik-Entscheidungen ein (Liquid Clustering, Column Mapping, Deletion Vectors).

Für den analytischen Bereich haben sich mehrere dominante Modellierungs-Muster etabliert. Dimensionale Modellierung nach Kimball organisiert die Daten als Star-Schema oder Snowflake-Schema mit einer Fakten-Tabelle im Zentrum und umliegenden Dimensions-Tabellen, ergänzt um Slowly Changing Dimensions und Conformed Dimensions. Die relationale Normalisierung nach Inmon setzt auf ein Enterprise-Data-Warehouse in 3NF als Single Source, aus der Data Marts abgeleitet werden. Data Vault 2.0 (Linstedt, 2013) trennt Business-Keys (Hub), Beziehungen (Link) und historisierte Attribute (Satellite) für auditierbare Rohdaten-Speicherung. Denormalisierte Wide-Tables oder One Big Table (OBT) bündeln alle relevanten Attribute in einer breiten Tabelle, was für Column-Store-Engines und BI-Semantik-Layer wirtschaftlich sein kann. Semi-strukturierte Modellierung mit STRUCT, ARRAY und MAP deckt Event- und Log-Daten ab.

Historisch verläuft die Entwicklung von Bachmans Netzwerkmodell (1969) über Codds relationales Modell (1970), Chens ER-Modell (1976), die ANSI/SPARC-Architektur (1975), Inmons Enterprise Data Warehouse (1992) und Kimballs dimensionale Modellierung (1996) bis zu Data Vault 2.0 (Linstedt, 2013). Aktuelle Lakehouse-Physik (Delta, Iceberg) und semantische Layer (dbt-Semantic, Cube, Databricks Genie Ontology) verlagern Teile der Modellierungs-Praxis in nachgelagerte Schichten, ändern aber nichts am Kern der drei Ebenen.

Abgrenzung zu Data Architecture, Semantic Layer und Modell-Mustern

Data Modeling wird häufig mit benachbarten Disziplinen vermischt oder mit einem einzelnen Modellierungs-Muster gleichgesetzt. Die folgende Tabelle sortiert die Begriffe.

Begriff	Verhältnis zu Data Modeling	Kernunterschied
[Data Architecture](/insights/glossar/data-architecture/)	Übergeordnete Struktur-Disziplin	Beschreibt die Gesamtstruktur der Datenlandschaft (Systeme, Schichten, Datenflüsse, Muster). Data Modeling liefert die Modelle einzelner Datenbestände als Bestandteil dieser Architektur.
Semantic Layer	Konsum-Schicht darüber	Beschreibt Kennzahlen und Business-Metriken als BI-Objekte (Measures, Dimensions) auf einem bereits modellierten Datenbestand. Data Modeling liefert die Tabellen-Struktur, der Semantic Layer die Business-Sprache über ihr.
Star-Schema, Snowflake, OBT	Konkrete Modell-Muster	Ausprägungen der dimensionalen bzw. denormalisierten Modellierung im analytischen Gold-Layer. Data Modeling ist der Oberbegriff, das Star-Schema eines seiner Muster.
Data Vault	Auditierbares Modell-Muster	Hub/Link/Satellite für historisierte Rohdaten-Speicherung, meist im Silver-Layer. Alternative zu 3NF und dimensionaler Modellierung, also ein Muster innerhalb der Disziplin.
Datenbank-Schema	Ergebnis der physischen Ebene	Konkrete DDL (Tabellen, Spalten, Constraints) in einer Ziel-Datenbank. Data Modeling ist die Disziplin, das Datenbank-Schema ein Artefakt daraus.

Zwei Trennlinien sind für die Einordnung besonders relevant. Erstens die Trennung zwischen Data Modeling und Data Architecture: Werden beide Begriffe synonym verwendet, geht der Unterschied zwischen Landschafts-Blick (welche Systeme spielen wie zusammen) und Objekt-Blick (wie ein einzelner Datenbestand strukturiert ist) verloren. Zweitens die Gleichsetzung mit einem Muster: Aussagen wie „Modellierung im Star-Schema" oder „Data-Vault-Ansatz" bezeichnen eine Muster-Wahl auf der logischen Ebene und decken die Disziplin als Ganzes nur ausschnitthaft ab. Data Modeling umfasst die Muster und die drei Ebenen darüber, auf denen ein Muster ausgewählt und verfeinert wird.

Beispiel: Vertrags-Domäne bei einem Versicherer

Ein DACH-Versicherer modelliert die Domäne „Vertrag" für ein neues Analytics-Lakehouse. Data Modeling manifestiert sich auf allen drei Ebenen und in einer expliziten Muster-Wahl je Schicht.

Auf der konzeptionellen Ebene entsteht mit dem Fachbereich ein ER-Diagramm mit den Entitäten Vertragsnehmer, Vertrag, Deckung, Schaden und Zahlung. Die Beziehungen und Kardinalitäten werden fixiert (ein Vertragsnehmer hält 1..n Verträge, ein Vertrag umfasst 1..n Deckungen, eine Deckung erzeugt 0..n Schäden) und gegen die Fachdefinitionen im Business-Glossar abgeglichen. Auf der logischen Ebene folgt die Entscheidung für ein zweistufiges Modell: Der Silver-Layer wird als Data Vault ausgeführt (Hubs Vertrag, Kunde, Deckung; Links; Satellites für Zeitscheiben), der Gold-Layer als Star-Schema mit einer Fakten-Tabelle Schadenfall und den Dimensionen Vertrag, Kunde, Deckung, Zeit und Region. Vollständige Attribute, Primär- und Fremdschlüssel sowie Historisierungs-Regeln sind auf dieser Ebene definiert.

Auf der physischen Ebene wird das Modell in Delta-Tabellen im [Data Lakehouse](/insights/glossar/data-lakehouse/) umgesetzt. Die Fakten-Tabelle trägt Liquid Clustering auf Vertrags-ID und Schadenmonat, die Dimensionen sind als SCD Type 2 mit Effective- und End-Date implementiert, und der Unity Catalog trägt informative Primär- und Fremdschlüssel als Metadaten für Query-Optimizer und Semantik-Layer. Deletion Vectors ermöglichen DSGVO-konforme Löschungen einzelner Datensätze. Parallel wird eine denormalisierte OBT-Sicht als Materialized View für den Power-BI-Import gepflegt.

Das Modell bleibt über die drei Ebenen konsistent: Der Fachbegriff „Deckung" aus dem ER-Diagramm erscheint im Silver-Vault als HUB_DECKUNG und im Gold-Star als DIM_DECKUNG. Muster-Wahl (Data Vault plus Star-Schema plus OBT-Materialisierung) und Lakehouse-Physik greifen ineinander, ohne die logische Fachlogik zu verändern.