Katalog
method#Daten#Architektur#Governance#Softwaretechnik

Data Modeling

Systematische Methode zur Definition und Strukturierung von Daten über konzeptionelle, logische und physische Ebenen hinweg.

Data Modeling ist eine strukturierte Methode zur Definition, Organisation und Dokumentation von Datenstrukturen über konzeptionelle, logische und physische Ebenen.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Datenkataloge und MetadatensystemeETL/ELT-Pipelines und OrchestrierungstoolsCI/CD für Datenmodell- und Schemaänderungen

Prinzipien & Ziele

Trenne konzeptionelles vom physischen ModellDefiniere eindeutige Entitäten und EigentumsverantwortungDokumentiere Semantik und Business-Regeln neben Struktur
Erkundung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Falsche Semantik führt zu inkonsistenten Integrationen
  • Unklare Ownership verhindert effektive Pflege
  • Zu starke Normalisierung kann Performance verschlechtern
  • Iterativ vorgehen: klein anfangen und verifizieren
  • Modell, Metadaten und Regeln gemeinsam pflegen
  • Automatisierte Tests und Validierungen einführen

I/O & Ressourcen

  • Geschäftsanforderungen, Prozesse, Glossar
  • Bestehende Schemata und Beispieldaten
  • Performance- und Compliance-Anforderungen
  • Konzeptuelles, logisches und physisches Datenmodell
  • Mapping- und Migrationsdokumentation
  • Metadaten und Glossar für Governance

Beschreibung

Data Modeling ist eine strukturierte Methode zur Definition, Organisation und Dokumentation von Datenstrukturen über konzeptionelle, logische und physische Ebenen. Sie unterstützt Konsistenz, Interoperabilität und Performance-Optimierung durch klare Entitäten, Attribute und Beziehungen sowie Normalisierungs- und Dekompositionsentscheidungen. Anwendungsbereiche reichen von Analytik über Integration bis hin zu operativen Datenbanken.

  • Verbesserte Datenqualität und Konsistenz
  • Erleichterte Integration und Wiederverwendung
  • Bessere Performance durch geeignetes physisches Design

  • Kann initialen Aufwand und Verzögerungen verursachen
  • Nicht alle Anforderungen lassen sich vollständig vorab modellieren
  • Übermodellierung führt zu Komplexität und Wartungsaufwand

  • Datenredundanz-Score

    Messung der mehrfach vorhandenen Informationen über Entitäten hinweg.

  • Query-Latenz

    Durchschnittliche Antwortzeit typischer datenbankbezogener Abfragen.

  • Schema-Konvergenz

    Grad der Übereinstimmung zwischen Quell- und Zielmodell nach Harmonisierung.

Unternehmensweites Referenzdatenmodell

Aufbau eines zentralen Datenmodells zur Harmonisierung von Kunden- und Produktstammdaten über mehrere Systeme.

Migrationsprojekt auf Microservices

Aufteilung eines monolithischen Schemas in dienstspezifische Modelle mit klaren Schnittstellen und Ownership.

Dimensionales Reportingmodell

Design eines Data-Warehouse-Modells zur Beschleunigung von BI-Abfragen und vereinfachten Dashboards.

1

Stakeholder-Workshops zur Begriffsdefinition

2

Erstellung konzeptioneller Modelle und Review-Runden

3

Ableitung logischer/physischer Schemata und Testmigration

⚠️ Technische Schulden & Engpässe

  • Ad-hoc-Schemata ohne Dokumentation
  • Temporäre Denormalisierung, die nie bereinigt wurde
  • Fehlende Migrationspfade für Schemaänderungen
Fehlende DomänenexpertiseInkompatible QuellschemataLeistungsprobleme bei komplexen Joins
  • Übertriebene Generalisierung führt zu schwer verständlichen Modellen
  • Ignorieren von Abfrageprofilen bei physischem Design
  • Fehlende Synchronisation zwischen Modell und Implementierung
  • Zu viel Detail im konzeptionellen Modell
  • Unklare Namenskonventionen führen zu Verwirrung
  • Nicht berücksichtigte Datenschutzanforderungen
Datenmodellierung (ER, dimensional)SQL und DatenbankperformanceDomänenverständnis und Stakeholder-Interviews
Skalierbarkeit der DatenzugriffeInteroperabilität zwischen SystemenDatenqualität und Governance-Anforderungen
  • Technische Limits der Ziel-Datenbank
  • Regulatorische Anforderungen an Metadaten
  • Vorhandene Altsysteme und Konvertierungsaufwand