IHK AP2 Fachinformatiker Daten- und Prozessanalyse

LF 10: Data Warehouse Architekturen & Star-/Snowflake-Schema

Fakten- und Dimensionstabellen, Surrogatschlüssel, Slowly Changing Dimensions (SCD Typ 1-3)

📚 Fachwissen & IHK-Prüfungsrelevanz

Das Data Warehouse (DWH) nach Ralph Kimball oder Bill Inmon ist das analytische Herzstück von Business-Intelligence-Lösungen.

1. 3-Schichten-Architektur

Staging Area: 1:1 Kopie der Quellsysteme, flüchtig oder persistent, keine Transformationen für Endanwender.
Core DWH: Bereinigte, harmonisierte und integrierte Datenbasis. Häufig nach 3NF oder Data Vault 2.0 modelliert.
Data Marts: Abteilungsspezifische Auswertungsbereiche (Vertrieb, Einkauf, Finanzen), optimiert für schnelle Abfragen im Sternschema (Star Schema).

2. Star-Schema vs. Snowflake-Schema

Merkmal	Sternschema (Star Schema)	Schneeflockenschema (Snowflake Schema)
Dimensionstabellen	Denormalisiert (redundant, wenige JOINs)	Normalisiert (in 3NF zerlegt, viele Sub-Tabellen)
Abfragekomplexität	Sehr einfach, minimale JOINs, extrem performant	Komplexer, erfordert Multi-Level-JOINs
Speicherplatz	Höher durch Redundanz (in DWH irrelevant)	Geringer, redundanzfrei
IHK-Empfehlung	Standard für analytische OLAP Data Marts	Selten bevorzugt wegen JOIN-Overhead

3. Slowly Changing Dimensions (SCD)

SCD Typ 1: Überschreiben alter Werte. Keine Historie. (Z.B. Korrektur von Tippfehlern).
SCD Typ 2: Neuer Datensatz pro Änderung mit Gültigkeitszeitraum (valid_from, valid_to, is_current) und neuem Surrogatschlüssel. Volle historische Genauigkeit!
SCD Typ 3: Zusätzliche Spalte previous_value. Nur begrenzte Historie (1 Vorwert).

📝 Original-Prüfungsaufgaben (ZPA Nord-West)

Data Warehouse Star-Schema vs Snowflake-Schema 8 Punkte

Für das Management-Reporting einer Handelskette wird ein multidimensionales Datenmodell entworfen.

Erklären Sie den Aufbau eines Star-Schemas (Faktentabelle und Dimensionstabellen). Grenzen Sie das Star-Schema vom Snowflake-Schema hinsichtlich Normalisierung und Abfrageperformance ab.

💡 Didaktischer Erwartungshorizont & Punkteverteilung (nach KMK-Kriterien)

Data Warehouse: Slowly Changing Dimensions (SCD Typ 1 vs. Typ 2) 10 Punkte

In einem CRM-System ändert ein Großkunde seinen Firmensitz von München nach Frankfurt am Main. Im Data Warehouse sollen historische Umsatzzahlen weiterhin der Region München zugeordnet bleiben, zukünftige Umsätze jedoch Frankfurt.

a) Begründen Sie, warum SCD Typ 1 für diese Anforderung ungeeignet ist. b) Beschreiben Sie den Aufbau und die Funktionsweise einer SCD Typ 2 Implementierung in der Kundendimension (nennen Sie drei typische Metadaten-Spalten). c) Was versteht man unter einem 'Surrogatschlüssel' (Surrogate Key) und warum ist er bei SCD Typ 2 zwingend erforderlich?

💡 Didaktischer Erwartungshorizont & Punkteverteilung (nach KMK-Kriterien)

a) SCD Typ 1 überschreibt den bestehenden Datensatz einfach. Dadurch geht die Historie verloren, und historische Umsätze würden fälschlicherweise nachträglich Frankfurt zugeordnet. b) Bei SCD Typ 2 wird für jede Änderung ein neuer Datensatz in der Dimensionstabelle angelegt. Die Historie wird über Metadatenspalten gesteuert: 1. `gueltig_von` (Valid From / Startdatum), 2. `gueltig_bis` (Valid To / Enddatum, z.B. 9999-12-31), 3. `is_current` (Flag 1/0 für den aktuell gültigen Datensatz). c) Ein Surrogatschlüssel ist ein künstlicher, datenbankinterner Primärschlüssel (z.B. fortlaufende Ganzzahl / Bigint). Da der fachliche Geschäftsschlüssel (Business Key, z.B. Kundennummer) bei SCD Typ 2 mehrfach in der Tabelle vorkommt, garantiert nur der Surrogatschlüssel die Eindeutigkeit jeder historischen Version.