Data Warehouse, ETL und Sternschema: Daten für Auswertungen aufbereiten
https://bildung.social/@oerinformatik/
https://oer-informatik.de/data-warehouse-etl
Data Warehouse, Data Mart, Data Lake, ETL, ELT, OLAP, Sternschema, Faktentabelle, Dimensionstabelle, Surrogatschlüssel, Business Key, Schneeflockenschema
tl/dr; (ca. 19 min Lesezeit): Warum laufen Auswertungen nicht direkt auf der Datenbank des Onlineshops? Der Artikel erklärt den Unterschied zwischen operativen und analytischen Systemen, grenzt Data Warehouse, Data Mart und Data Lake voneinander ab und wägt zentrale und dezentrale Datenhaltung ab. Er zeigt, was im ETL-Prozess mit den Daten passiert (mit typischen Transformationen und passenden Datentypen) und wie ein Sternschema aus Fakten- und Dimensionstabellen aufgebaut, mit SQL angelegt und abgefragt wird. Zum Schluss geht es um Surrogat- und Business-Schlüssel und das Schneeflockenschema [AI-Assisted]. (Zuletzt geändert am 27.10.2026)
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Als Grundlagen zu Data Warehouses kann ich nach Durchlesen des Artikels…
… begründen, warum Auswertungen in einem eigenen System statt in der operativen Datenbank laufen (OLTP und OLAP).
… die Begriffe Data Warehouse, Data Mart und Data Lake beschreiben und voneinander abgrenzen.
… die drei Schritte des ETL-Prozesses beschreiben, auch anhand eines englischen Fachtextes.
… Vor- und Nachteile einer zentralen und einer dezentralen Datenhaltung beschreiben.
… Fakten- und Dimensionstabellen eines Sternschemas unterscheiden und beschreiben, wie sie miteinander verbunden sind.
Darüber hinaus kann ich als Expertenwissen zu Data Warehouses…
… für einen konkreten Datenbestand Attribute nennen, die im ETL-Prozess angepasst oder hinzugefügt werden, und dabei Zweck und Datentyp angeben.
… aus einem flachen Datensatz ein Sternschema mit Dimensionstabellen entwickeln und Primär- und Fremdschlüssel kennzeichnen.
… eine Faktentabelle mit SQL anlegen und eine Auswertung über das Sternschema formulieren.
… den Vorteil von Surrogatschlüsseln gegenüber Business-Schlüsseln erläutern und angeben, wo der Business-Schlüssel gespeichert wird.
… Stern- und Schneeflockenschema unterscheiden und ETL von ELT abgrenzen.
Die Geschäftsführung eines Onlineshops möchte wissen, welche Warengruppe in welchem Monat am meisten Umsatz gebracht hat, ob Händler anders kaufen als Privatkundschaft und wie sich das gegenüber dem Vorjahr verändert hat. Die Daten dafür sind vorhanden, aber verteilt: Bestellungen in der Shop-Datenbank, Zahlungen in der Buchhaltung, Rücksendungen in einer Tabellenkalkulation. Ein Data Warehouse führt solche Daten für Auswertungen zusammen. Dieser Artikel baut auf der Kann-Liste des Artikels Relationales Datenmodell auf; Primär- und Fremdschlüssel sowie Kardinalitäten werden vorausgesetzt.
Operative Systeme und Auswertungen: OLTP und OLAP
Die Datenbank eines Shops, eines ERP-Systems oder einer App ist ein operatives System. Sie verarbeitet viele kleine, gleichzeitige Vorgänge: Bestellung anlegen, Lagerbestand ändern, Adresse korrigieren. Man spricht von OLTP (Online Transaction Processing). Auswertungen haben ganz andere Anforderungen; sie heißen OLAP (Online Analytical Processing).
| Merkmal | OLTP (operatives System) | OLAP (Auswertungssystem) |
|---|---|---|
| Zweck | Tagesgeschäft abwickeln | Entscheidungen vorbereiten |
| Zugriffe | viele kurze Lese- und Schreibzugriffe | wenige, lange Lesezugriffe über viele Datensätze |
| Daten | aktueller Stand, Änderungen überschreiben | Historie über Jahre, wird nur ergänzt |
| Datenmodell | normalisiert (wenig Redundanz) | für Abfragen optimiert, bewusst denormalisiert (Sternschema) |
| Nutzende | Kundschaft, Sachbearbeitung, Programme | Controlling, Management, Data Analysts |
Laufen große Auswertungen direkt auf der Shop-Datenbank, bremsen sie den laufenden Betrieb. Außerdem fehlen dort oft die historischen Stände (ein geänderter Preis oder eine umgezogene Kundin überschreibt den alten Wert), und Daten aus anderen Quellen lassen sich nicht einfach verbinden. Deshalb kopiert man die Daten regelmäßig in ein eigenes System für Auswertungen.
Data Warehouse, Data Mart und Data Lake
Ein Data Warehouse (DWH, „Datenlager“) ist eine zentrale Datenbank, in der Daten aus verschiedenen Quellsystemen bereinigt, vereinheitlicht und in einer festen Struktur für Auswertungen gespeichert werden. Nach Bill Inmon ist es themenorientiert (nach Geschäftsthemen wie Verkauf statt nach Anwendungen), integriert (einheitliche Formate und Schlüssel), zeitbezogen (Historie) und nicht flüchtig (Daten werden geladen und gelesen, aber nicht mehr geändert). Die Struktur (das Schema) wird vor dem Laden festgelegt (schema on write), die Daten gelangen über einen ETL-Prozess hinein.
Ein Data Mart ist ein Ausschnitt des Data Warehouses für einen bestimmten Anwendungszweck, eine Abteilung oder Nutzergruppe, z. B. ein Data Mart „Vertrieb“ nur mit Verkaufsdaten. Er ist kleiner und schneller abzufragen, und Zugriffsrechte lassen sich leichter vergeben.
Ein Data Lake ist ein Speicher, in dem große Mengen Rohdaten aller Art aus verschiedenen Quellen im Originalformat abgelegt werden: Tabellen, JSON- und Logdateien, aber auch Bilder, Texte oder Sensordaten. Die Daten sind meist nicht normalisiert und nicht bereinigt; eine Struktur wird erst beim Auslesen angewandt (schema on read). Data Lakes eignen sich für Data Science und maschinelles Lernen, ohne Pflege drohen sie aber zum unübersichtlichen „Datensumpf“ zu werden.
Neuere Plattformen verbinden beides als Lakehouse: Rohdaten im Data Lake, darüber eine Schicht mit Tabellen und Schemata wie im Data Warehouse.
Zentral oder dezentral speichern?
Nicht nur beim Data Warehouse stellt sich die Frage, ob Daten an einer zentralen Stelle (Rechenzentrum, Cloud) oder dezentral an vielen Stellen (Standorte, Filialen, Geräte wie Kassen, Zutrittsleser oder Terminals) gespeichert werden. Ein Data Warehouse ist ausdrücklich zentral; die Quellsysteme, die es beliefern, sind es häufig nicht.
| Vorteile | Nachteile | |
|---|---|---|
| zentral | eine Datenquelle („single point of truth“), Änderungen sofort überall wirksam; einfache Datensicherung, Rechteverwaltung und Auswertung | Ausfall von Netz oder Server legt alle Standorte lahm (Single Point of Failure); Latenz bei jedem Zugriff; lohnendes Angriffsziel mit allen Daten |
| dezentral | funktioniert auch bei Netzausfall weiter; schneller Zugriff vor Ort; ein Angriff auf ein Gerät betrifft nur dessen Daten | Änderungen (z. B. neue Berechtigung, ausgeschiedene Person) müssen an alle Stellen verteilt werden und sind dort verzögert; Datensicherung, Updates und Schutz vieler Speicherorte aufwendig; Daten können auseinanderlaufen (inkonsistent) |
In der Praxis wird oft gemischt: Die Stammdaten werden zentral gepflegt und regelmäßig an die Geräte verteilt, damit diese bei einem Ausfall weiterarbeiten; die Ereignisse vor Ort werden zwischengespeichert und nachgeliefert.
Der ETL-Prozess
Daten gelangen in drei Schritten aus den Quellsystemen ins Data Warehouse. Die Grundlagen zur Datenqualität und zum Import beschreibt der Artikel Datenqualität und Datenimport.
Extract (extrahieren): Die relevanten Daten werden aus den verschiedenen Quellen gelesen, z. B. per SQL aus der Shop-Datenbank, als CSV-Export aus der Buchhaltung oder als JSON über eine Web-API. Häufig landen sie zunächst unverändert im Staging-Bereich, einem Zwischenspeicher.
Transform (umwandeln): Die Daten werden in das Zielformat gebracht: bereinigt, vereinheitlicht, umgerechnet, zusammengeführt und um abgeleitete Werte ergänzt.
Load (laden): Die umgewandelten Daten werden in die Zieldatenbank, also das Data Warehouse, geschrieben, meist regelmäßig (z. B. nachts) und nur die neuen oder geänderten Datensätze (Delta-Load).
In englischen Texten heißt es entsprechend: extract the relevant data from (several) sources, transform it into the target format, load it into the target database or data warehouse.
Typische Transformationen
Im Transform-Schritt werden Attribute angepasst, hinzugefügt oder entfernt. Für jedes Attribut lohnt sich die Frage, welchem Zweck es in der Auswertung dient und welcher Datentyp dafür passt.
| Transformation | Beispiel | Datentyp im Ziel | Zweck |
|---|---|---|---|
| Datum zusammensetzen | Tag, Monat, Jahr in drei Textfeldern → ein Datum | DATE |
Datumsfunktionen, Sortieren, Zeiträume vergleichen |
| Dauer berechnen | Beginn und Ende → Dauer in Minuten | INT bzw. SMALLINT |
rechnen, summieren, Durchschnitt bilden |
| Kennzahl ableiten | Menge × Einzelpreis × (1 − Rabatt) → Umsatz | DECIMAL(10,2) |
Kennzahl muss nicht bei jeder Abfrage neu berechnet werden; exakt rechnen (kein FLOAT bei Geld) |
| Schlüssel einführen | Gebäude „Werk 2“ als Text → gebaeude_key |
INT |
schnelle Verknüpfungen, unabhängig von Schreibweisen |
| Werte vereinheitlichen | „Rechnung“, „RE“, „auf Rechnung“ → „Rechnung“; °F → °C | VARCHAR bzw. DECIMAL |
gleiche Dinge werden gleich gezählt |
| Klassen bilden | Alter → Altersgruppe; Uhrzeit → Tageszeit | VARCHAR oder TINYINT |
gruppierte Auswertung |
| Attribute entfernen | laufende Exportnummer, Freitextfeld ohne Bedeutung | – | weniger Ballast, Datenminimierung |
| pseudonymisieren | Name, Personalnummer → Pseudonym | CHAR(64) (Hashwert mit geheimem Schlüssel, z. B. HMAC) bzw. INT (Zufallswert aus einer getrennt gespeicherten Zuordnungstabelle) |
personenbezogene Auswertung vermeiden (DSGVO); ein einfacher Hash kleiner Nummern ließe sich durch Durchprobieren zurückrechnen |
ETL oder ELT?
Bei ELT (Extract, Load, Transform) werden die Rohdaten zuerst unverändert geladen, meist in einen Data Lake oder eine leistungsfähige Cloud-Datenbank, und erst dort bei Bedarf umgewandelt. Vorteil: Es geht nichts verloren, und neue Fragestellungen lassen sich auch später noch an den Rohdaten beantworten. Nachteil: Die Rohdaten brauchen viel Speicher, enthalten unbereinigte und oft personenbezogene Daten, und jede Auswertung muss die Umwandlung erneut leisten. ETL liefert dagegen geprüfte, einheitliche Daten und speichert nur, was für die geplanten Auswertungen nötig ist.
Das Sternschema
Für das Data Warehouse wird ein dimensionales Datenmodell entworfen. Am verbreitetsten ist das Sternschema (engl. Star Schema): In der Mitte steht eine Faktentabelle, um sie herum sternförmig mehrere Dimensionstabellen.
Die Faktentabelle enthält die messbaren Kennzahlen (Fakten) eines Geschäftsvorfalls, z. B. Anzahl verkaufter Tickets und Umsatz, sowie je einen Fremdschlüssel auf jede Dimension. Sie hat sehr viele Zeilen und wächst ständig.
Die Dimensionstabellen beschreiben die Fakten: wann (Datum), was (Film, Artikel), wo (Saal, Filiale), wer (Kunde) und wie (Tarif, Zahlungsart). Sie enthalten beschreibende Attribute, nach denen gefiltert und gruppiert wird, und sind vergleichsweise klein.
Die Beziehungen sind fast immer 1:n: Eine Zeile einer Dimensionstabelle (ein Film) gehört zu vielen Zeilen der Faktentabelle (vielen Verkäufen), jede Faktenzeile verweist auf genau eine Zeile jeder Dimension. Umgesetzt wird das wie im relationalen Modell: Der Primärschlüssel der Dimension steht als Fremdschlüssel in der Faktentabelle.
Wichtig ist die Granularität (Körnigkeit): Was genau beschreibt eine Zeile der Faktentabelle? Ein einzelnes Ticket, eine Bestellposition oder die Tagessumme je Saal? Je feiner die Granularität, desto mehr Auswertungen sind möglich und desto größer wird die Tabelle. Im Kino-Beispiel beschreibt eine Zeile einen Verkaufsvorgang für eine Vorstellung (Datum, Film, Saal) in einem Tarif: Kauft eine Familie zwei Erwachsenen- und zwei Kindertickets, entstehen zwei Zeilen mit anzahl_tickets = 2.
Die Dimensionstabellen sind bewusst denormalisiert: In dim_film steht das Genre direkt als Text, obwohl es sich in einer normalisierten Datenbank in einer eigenen Tabelle befände. Das spart bei Abfragen JOINs. Die Redundanz ist hier unproblematisch, weil die Daten nur geladen und gelesen, aber nicht im Tagesgeschäft geändert werden.
Vom flachen Datensatz zum Sternschema
Oft liegt ein Export als eine breite Tabelle vor, in der jede Zeile einen Vorgang mit allen Angaben enthält. So entwickelst Du daraus ein Sternschema:
Geschäftsvorfall und Granularität festlegen: Was wird gezählt oder gemessen? Eine Zeile je Ticket, je Bestellposition, je Zutritt?
Kennzahlen bestimmen: numerische Werte, die summiert oder gemittelt werden (Menge, Umsatz, Dauer). Sie kommen in die Faktentabelle.
Dimensionen bilden: Beschreibende Attribute, die zusammengehören, kommen in eine gemeinsame Dimensionstabelle (alle Angaben zum Film in
dim_film). Das Datum wird meist als eigene Datumsdimension mit Tag, Monat, Quartal, Jahr, Wochentag und Feiertag modelliert, damit danach gruppiert werden kann; wird die Uhrzeit gebraucht, kommt sie in eine eigene Uhrzeitdimension.Schlüssel vergeben: Jede Dimension erhält einen Primärschlüssel, die Faktentabelle je einen Fremdschlüssel darauf und einen eigenen Primärschlüssel.
Kennzeichnen und verbinden: PK und FK markieren, die 1:n-Beziehungen eintragen.
Attribute, die nur den Vorgang selbst identifizieren (z. B. Bestellnummer und Positionsnummer), können ohne eigene Tabelle in der Faktentabelle bleiben; man nennt sie degenerierte Dimension.
Das Sternschema mit SQL anlegen
Ein Sternschema wird wie jedes relationale Modell mit CREATE TABLE angelegt, zuerst die Dimensionen, dann die Faktentabelle mit ihren Fremdschlüsseln. Für Geldbeträge wird DECIMAL mit Nachkommastellen verwendet: DECIMAL(8,2) bedeutet acht Stellen insgesamt, davon zwei nach dem Komma.
CREATE TABLE dim_film (
film_key INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
film_nr VARCHAR(12) NOT NULL, -- Business Key aus dem Kassensystem
titel VARCHAR(150) NOT NULL,
genre VARCHAR(30) NOT NULL,
fsk TINYINT UNSIGNED NOT NULL
) ENGINE=InnoDB;
-- dim_datum, dim_saal und dim_tarif werden ebenso angelegt (hier ausgelassen)
CREATE TABLE fakt_ticketverkauf (
verkauf_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
datum_key INT UNSIGNED NOT NULL, -- z. B. 20261024
film_key INT UNSIGNED NOT NULL,
saal_key INT UNSIGNED NOT NULL,
tarif_key INT UNSIGNED NOT NULL,
anzahl_tickets SMALLINT UNSIGNED NOT NULL,
umsatz_brutto DECIMAL(8,2) NOT NULL,
CONSTRAINT fk_tv_datum FOREIGN KEY (datum_key) REFERENCES dim_datum (datum_key),
CONSTRAINT fk_tv_film FOREIGN KEY (film_key) REFERENCES dim_film (film_key),
CONSTRAINT fk_tv_saal FOREIGN KEY (saal_key) REFERENCES dim_saal (saal_key),
CONSTRAINT fk_tv_tarif FOREIGN KEY (tarif_key) REFERENCES dim_tarif (tarif_key)
) ENGINE=InnoDB;Der Schlüssel der Datumsdimension ist hier ausnahmsweise „sprechend“ (20261024 für den 24.10.2026). Das ist bei Datumsdimensionen üblich, weil sich das Datum nie ändert und sich Zeiträume so leicht eingrenzen lassen.
Auswertungen über das Sternschema
Eine Auswertung verbindet die Faktentabelle mit den benötigten Dimensionen (Star Join), filtert über Dimensionsattribute und fasst die Kennzahlen mit Aggregatfunktionen zusammen:
SELECT f.genre, d.monat, SUM(t.anzahl_tickets) AS tickets, SUM(t.umsatz_brutto) AS umsatz
FROM fakt_ticketverkauf t
JOIN dim_film f ON t.film_key = f.film_key
JOIN dim_datum d ON t.datum_key = d.datum_key
WHERE d.jahr = 2026
GROUP BY f.genre, d.monat
ORDER BY d.monat, umsatz DESC;Die Abfrage braucht nur zwei JOINs, unabhängig davon, wie viele Merkmale die Dimensionen haben. Typische OLAP-Operationen sind das Verdichten (Roll-up, z. B. von Monat auf Quartal), das Verfeinern (Drill-down) und das Herausschneiden einer Teilmenge (Slice, z. B. nur 2026).
Surrogatschlüssel und Business-Schlüssel
In den Quellsystemen haben Datensätze bereits Schlüssel mit fachlicher Bedeutung: Artikelnummer, Personalnummer, Kundennummer. Sie heißen Business-Schlüssel (engl. Business Key oder Natural Key). Im Data Warehouse verwendet man trotzdem eigene, bedeutungslose Ganzzahlen als Primärschlüssel der Dimensionen, die Surrogatschlüssel (engl. Surrogate Key, „Ersatzschlüssel“, hier mit dem Suffix _key).
Gründe für Surrogatschlüssel:
Unabhängigkeit von den Quellsystemen: Business-Schlüssel hängen an fachlichen Regeln. Ändern sich diese (neues Nummernsystem, Firmenübernahme, neue gesetzliche Vorgabe), müssten alle Tabellen angepasst werden, die den Schlüssel verwenden, im Data Warehouse also auch die riesige Faktentabelle mit allen historischen Daten. Mit Surrogatschlüsseln ändert sich nur eine Zeile in der kleinen Dimensionstabelle. Der Surrogatschlüssel wirkt wie ein Puffer zwischen operativen Systemen und Data Warehouse.
Mehrere Quellen: Zwei Filialen können dieselbe Kundennummer für verschiedene Personen vergeben haben. Ein Surrogatschlüssel macht beide eindeutig.
Historie: Zieht eine Kundin um, kann die Dimension eine zweite Zeile mit neuem Surrogatschlüssel und neuer Adresse bekommen; alte Verkäufe bleiben der alten Adresse zugeordnet (Slowly Changing Dimension, Typ 2, mit „gültig von/bis“). Beim Typ 1 wird der alte Wert einfach überschrieben.
Leistung: Ganzzahlen sind kompakt und schnell zu verknüpfen; die Faktentabelle mit Millionen Zeilen wird kleiner.
Der Business-Schlüssel wird nur in der Dimensionstabelle als normales Attribut gespeichert, nicht in der Faktentabelle (Ausnahme: Vorgangsnummern wie die Bestellnummer, die als degenerierte Dimension in der Faktentabelle bleiben). So bleibt die Verbindung zum Quellsystem erhalten: Beim Laden neuer Fakten sucht der ETL-Prozess über den Business-Schlüssel den passenden Surrogatschlüssel heraus (Key Lookup).
Schneeflockenschema
Werden die Dimensionstabellen normalisiert, entstehen weitere Tabellen am Rand des Sterns, etwa dim_film → dim_genre oder dim_artikel → dim_kategorie → dim_oberkategorie. Das ist das Schneeflockenschema (engl. Snowflake Schema).
| Sternschema | Schneeflockenschema | |
|---|---|---|
| Dimensionen | denormalisiert, je Dimension eine Tabelle | normalisiert, Hierarchien in eigenen Tabellen |
| Abfragen | einfach, wenige JOINs, schnell |
mehr JOINs, komplexer |
| Speicher und Pflege | redundante Texte in den Dimensionen | weniger Redundanz, Änderung an einer Stelle |
Weil Speicher günstig ist und Dimensionen klein sind, wird für Auswertungen meist das Sternschema bevorzugt.
Datenschutz im Data Warehouse
Ein Data Warehouse hält Daten lange vor und verknüpft Quellen, die vorher getrennt waren. Bei personenbezogenen Daten (dazu zählen nach DSGVO auch Personalnummern, Kundennummern oder Chip-IDs, über die sich Personen identifizieren lassen) gelten Zweckbindung, Datenminimierung und Speicherbegrenzung. Typische Maßnahmen: nur benötigte Attribute übernehmen, pseudonymisieren oder auf Gruppen aggregieren, Zugriffe über Rollen und Data Marts beschränken, Löschfristen automatisiert umsetzen und die Datenbank verschlüsseln. Auswertungen über das Verhalten von Beschäftigten (z. B. Bewegungsprofile) sind nur in engen Grenzen erlaubt, nach den Regeln zum Beschäftigtendatenschutz (Art. 88 DSGVO und BDSG), etwa bei einem konkreten, dokumentierten Verdacht einer Straftat oder auf Grundlage einer Betriebsvereinbarung; der Betriebsrat hat bei technischen Überwachungseinrichtungen ein Mitbestimmungsrecht (§ 87 Abs. 1 Nr. 6 BetrVG).
Typische Fehler in Aufgaben
Data Lake als „großes Data Warehouse“ beschrieben: Entscheidend ist, dass ein Data Lake Rohdaten in beliebigen Formaten ohne vorgegebenes Schema speichert.
ETL-Schritte nur übersetzt: Beschreibe, was in jedem Schritt mit den Daten passiert (aus welchen Quellen, welche Umwandlungen, wohin geladen).
Transformationen ohne Datentyp und Zweck: Nenne das Attribut, den Zieldatentyp und wofür es in der Auswertung gebraucht wird.
Kennzahlen in die Dimension gelegt: Umsatz und Menge gehören in die Faktentabelle, beschreibende Texte in die Dimensionen.
Fremdschlüssel in der Dimension: Im Sternschema zeigen die Fremdschlüssel von der Faktentabelle auf die Dimensionen, nicht umgekehrt.
Geldbeträge als
FLOAToderDECIMAL(2):DECIMAL(2)hat zwei Stellen insgesamt und keine Nachkommastellen; für Beträge passt z. B.DECIMAL(10,2).Business-Schlüssel in der Faktentabelle: Er steht nur in der Dimensionstabelle (Ausnahme: Vorgangsnummern als degenerierte Dimension).
Leitfragen
- Warum laufen Auswertungen meist nicht direkt auf der operativen Datenbank?
Große Auswertungen bremsen den laufenden Betrieb (OLTP), historische Stände werden dort überschrieben, und Daten aus anderen Quellen lassen sich nicht einfach verbinden. Ein eigenes Auswertungssystem (OLAP) behebt das.
- Wie unterscheiden sich Data Warehouse, Data Mart und Data Lake?
Ein Data Warehouse speichert bereinigte, integrierte Daten aus mehreren Quellen in einem festen Schema. Ein Data Mart ist ein Ausschnitt davon für einen Zweck oder eine Abteilung. Ein Data Lake speichert Rohdaten aller Art im Originalformat, das Schema wird erst beim Lesen angewandt.
- Was passiert in den drei Schritten des ETL-Prozesses?
Extract: relevante Daten aus den Quellen lesen. Transform: bereinigen, vereinheitlichen, umrechnen, zusammenführen, ergänzen. Load: in das Data Warehouse schreiben, siehe Abschnitt „Der ETL-Prozess“.
- Welche Vor- und Nachteile hat eine dezentrale Datenhaltung?
Vorteile: arbeitet bei Netzausfall weiter, schneller Zugriff vor Ort, ein Angriff trifft nur einen Teil der Daten. Nachteile: Änderungen müssen an alle Stellen verteilt werden, Datensicherung und Schutz vieler Speicherorte sind aufwendig, Daten können inkonsistent werden.
- Was steht in einer Faktentabelle, was in einer Dimensionstabelle?
Faktentabelle: Kennzahlen eines Vorgangs und je ein Fremdschlüssel auf jede Dimension. Dimensionstabelle: beschreibende Attribute (wann, was, wo, wer, wie) mit eigenem Primärschlüssel. Verbunden sind sie in 1:n-Beziehungen.
- Wie gehst Du vor, um aus einem flachen Datensatz ein Sternschema zu entwickeln?
Granularität festlegen, Kennzahlen bestimmen, zusammengehörige beschreibende Attribute zu Dimensionen bündeln, Schlüssel vergeben, PK/FK kennzeichnen und 1:n-Beziehungen eintragen, siehe Abschnitt „Vom flachen Datensatz zum Sternschema“.
- Warum verwendet man im Data Warehouse Surrogatschlüssel, und wo bleibt der Business-Schlüssel?
Surrogatschlüssel machen das Data Warehouse unabhängig von Änderungen der Business-Schlüssel in den Quellsystemen (sonst müssten auch alle historischen Fakten angepasst werden), erlauben mehrere Quellen und Historisierung und sind schnell. Der Business-Schlüssel steht nur in der Dimensionstabelle.
- Worin unterscheiden sich Stern- und Schneeflockenschema?
Im Sternschema sind die Dimensionen denormalisiert (eine Tabelle je Dimension, schnelle Abfragen), im Schneeflockenschema normalisiert (Hierarchien in eigenen Tabellen, weniger Redundanz, mehr JOINs).
Links und weitere Informationen
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Data Warehouse, ETL und Sternschema: Daten für Auswertungen aufbereiten” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/data-warehouse-etl veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/daten-ki/datenanalyse-ki. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 27.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
