Katalog
concept#Daten#Analytics#Architektur#Plattform

Sternschema

Dimensionales Datenmodell für analytische Systeme, das eine Faktentabelle mit mehreren Dimensionstabellen verbindet und Abfragen für Reporting und OLAP optimiert.

Das Sternschema ist ein dimensionales Modell für Data-Warehouses, das eine zentrale Faktentabelle mit mehreren Dimensionstabellen verbindet und Abfragen für analytische Reports optimiert.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

ETL/ELT-Tools (z. B. Apache Airflow, Informatica)Datenbanken und Data-Warehouse-Plattformen (z. B. Snowflake, Redshift)BI-Tools (z. B. Power BI, Tableau)

Prinzipien & Ziele

Klare Trennung von Fakten und DimensionenEindeutige Grain-Definition der FaktentabellenVerwendung von Surrogatschlüsseln für Konsistenz
Umsetzung
Domäne, Unternehmen

Use Cases & Szenarien

Kompromisse

  • Dateninkonsistenzen bei unzureichender ETL-Logik
  • Performance-Probleme bei sehr großen Dimensionen
  • Versteckte Komplexität durch historische Dimensionen
  • Grain früh festlegen und dokumentieren
  • Surrogatschlüssel statt natürlichen Schlüsseln verwenden
  • SCD-Strategien klar pro Dimension bestimmen

I/O & Ressourcen

  • Operative Quellsysteme (Transaktionen, Logs)
  • Stammdaten (Produkte, Kunden, Zeit)
  • ETL-Werkzeuge und Scheduling
  • Fakten- und Dimensionsdaten zur Analyse
  • Dashboards und Standardreports
  • Aggregierte Kennzahlen für BI-User

Beschreibung

Das Sternschema ist ein dimensionales Modell für Data-Warehouses, das eine zentrale Faktentabelle mit mehreren Dimensionstabellen verbindet und Abfragen für analytische Reports optimiert. Durch Denormalisierung und einfache Joins verbessert es Performance, hat aber Auswirkungen auf Speicherbedarf und Änderungsflexibilität. Einsatzfelder sind BI, Reporting und OLAP-Workloads.

✔

  • Verbesserte Abfrageperformance durch einfache Joins
  • Einfachere Verständlichkeit für Business-Analysten
  • Gute Eignung für Aggregation und OLAP

✖

  • Erhöhter Speicherverbrauch durch Denormalisierung
  • Weniger flexibel bei häufigen Strukturänderungen
  • Nicht ideal für hochtransaktionale Systeme

  • Abfrage-Latenz (p50/p95)

    Mittlere und obere Latenzwerte für typische Reporting-Abfragen.

  • Speicherbedarf

    Gesamtspeicher für Fakt- und Dimensionstabellen inkl. Indexe.

  • ETL-Dauer

    Zeitdauer für Datenladeprozesse und Historisierungen.

Einzelhandel: Sales-Data-Mart

Kundendaten, Produktkatalog und Bestellungen modelliert in Sternschema zur schnellen Report-Auswertung.

Finanzen: Monatsabschlüsse

Fakten zu Buchungen kombiniert mit Konten- und Zeitdimensionen zur Monatsabschlussanalyse.

E-Commerce: Marketing-Attribution

Klick- und Conversion-Daten als Faktentabellen, Dimensionen für Kampagnen, Kanal und Kunde.

1

Geschäftsprozesse analysieren und Grain definieren.

2

Fakt- und Dimensionstabellen entwerfen und Schlüssel festlegen.

3

ETL/ELT-Pipelines implementieren, SCDs behandeln und Tests ausführen.

⚠️ Technische Schulden & Engpässe

  • Unzureichende Dokumentation der Grain- und Mapping-Regeln
  • Ad-hoc-Transformationen im Data Mart statt zentraler Pipeline
  • Veraltete Dimensionstabellen ohne Pflege der Historie
Join-KardinalitätDimension-GrößeETL-Latenz
  • Sternschema als Ersatz für OLTP in Echtzeitsystemen
  • Ignorieren von Historisierung und Überschreiben historischer Dimensionen
  • Keine Surrogatschlüssel einsetzen und natürliche Schlüssel duplizieren
  • Unbeachtete Kardinalität großer Dimensionen beeinflusst Joins stark
  • Fehlende Indizes auf Fakt- und Dimensionsschlüsseln
  • Komplexe SCD-Logik ohne Tests führt zu inkonsistenten Reports
Datenmodellierung (dimensionales Modellieren)SQL- und ETL-EntwicklungVerständnis für Geschäftskennzahlen
Abfrageperformance für BIDatenkonsistenz und ReproduzierbarkeitSkalierbarkeit bei großen Faktentabellen
  • • Begrenzte Flexibilität bei Schema-Änderungen
  • • Abhängigkeit von stabilen Quellsystemen
  • • Notwendigkeit von ETL-Kapazitäten und Scheduling