0Pricing
SQL Academy · Lektion

Fakten- und Dimensionstabellen

Die Bausteine eines Data-Warehouse

Fakten- und Dimensionstabellen ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was ist ein Data Warehouse?

Ein Data Warehouse ist ein zentrales Repository für Berichte und analytische Abfragen. Im Gegensatz zu einer Transaktionsdatenbank, die auf schnelle Schreibvorgänge optimiert ist, ist ein Data Warehouse auf schnelle Lesevorgänge über große Mengen historischer Daten ausgelegt.

Die gängigste Methode, ein Data Warehouse zu organisieren, ist ein Star-Schema, das Daten in zwei Tabellentypen aufteilt: Faktentabellen und Dimensionstabellen.

Faktentabellen im Detail

Eine Faktentabelle speichert messbare, quantitative Ereignisse – die Dinge, die Sie analysieren möchten. Jede Zeile stellt das Auftreten eines Geschäftsvorfalls dar, etwa einen Verkauf, den Aufruf einer Webseite oder ein Support-Ticket.

Faktentabellen sind typischerweise umfangreich (viele Zeilen) und schmal (wenige Spalten). Die meisten Spalten sind entweder Fremdschlüssel zu Dimensionstabellen oder numerische Kennzahlen wie quantity oder revenue.

CREATE TABLE fact_sales (
  sale_id      SERIAL PRIMARY KEY,
  date_key     INT NOT NULL,
  product_key  INT NOT NULL,
  customer_key INT NOT NULL,
  store_key    INT NOT NULL,
  quantity     INT NOT NULL,
  unit_price   NUMERIC(10, 2) NOT NULL,
  total_amount NUMERIC(12, 2) NOT NULL
);

Dimensionstabellen im Detail

Eine Dimensionstabelle speichert beschreibende Attribute, die jeder Tatsache Kontext geben. Beispiele sind eine Produkt-Dimension (Name, Kategorie, Marke) oder eine Datums-Dimension (Tag, Monat, Quartal, Jahr).

Dimensionstabellen sind normalerweise klein (weniger Zeilen), aber breit (viele beschreibende Spalten). Sie werden mithilfe ganzzahliger Surrogatschlüssel mit der Faktentabelle verknüpft.

CREATE TABLE dim_product (
  product_key  SERIAL PRIMARY KEY,
  product_name VARCHAR(200) NOT NULL,
  category     VARCHAR(100),
  brand        VARCHAR(100),
  unit_cost    NUMERIC(10, 2)
);

CREATE TABLE dim_customer (
  customer_key SERIAL PRIMARY KEY,
  full_name    VARCHAR(200) NOT NULL,
  email        VARCHAR(200),
  country      VARCHAR(100),
  segment      VARCHAR(50)
);

Die Datumsdimension

Die Datumsdimension ist die häufigste Dimension in jedem Data Warehouse. Anstatt einen rohen TIMESTAMP in der Faktentabelle zu speichern, speichern Sie einen Ganzzahlschlüssel, der auf eine vorab erstellte Kalendertabelle verweist.

So können Abfragen nach Geschäftsquartal, Wochentag, Feiertagskennzeichen und anderen Kalenderattributen filtern oder gruppieren, ohne zur Abfragezeit Datumsberechnungen durchführen zu müssen.

CREATE TABLE dim_date (
  date_key       INT PRIMARY KEY,  -- e.g. 20240315
  full_date      DATE NOT NULL,
  day_of_week    VARCHAR(10),
  day_of_month   INT,
  month_num      INT,
  month_name     VARCHAR(20),
  quarter        INT,
  year           INT,
  is_holiday     BOOLEAN DEFAULT FALSE,
  fiscal_quarter INT
);

-- Sample row
INSERT INTO dim_date VALUES
  (20240315, '2024-03-15', 'Friday', 15, 3, 'March', 1, 2024, FALSE, 2);

Das Star-Schema-Muster

Wenn Sie ein Diagramm mit einer zentralen Faktentabelle und nach außen ausstrahlenden Dimensionstabellen zeichnen, sieht es wie ein Stern aus – daher der Name Star-Schema.

Die Fremdschlüssel in der Faktentabelle verweisen auf die Primärschlüssel der einzelnen Dimensionen. Abfragen verknüpfen die Faktentabelle typischerweise mit einer oder mehreren Dimensionen, um den Rohdaten zusätzlichen beschreibenden Kontext zu geben.

-- Join fact to two dimensions to enrich a sales report
SELECT
  dp.product_name,
  dp.category,
  SUM(fs.quantity)     AS total_units_sold,
  SUM(fs.total_amount) AS total_revenue
FROM fact_sales fs
JOIN dim_product  dp ON dp.product_key  = fs.product_key
JOIN dim_date     dd ON dd.date_key     = fs.date_key
WHERE dd.year = 2024
GROUP BY dp.product_name, dp.category
ORDER BY total_revenue DESC;

Surrogatschlüssel vs. natürliche Schlüssel

Dimensionstabellen verwenden Surrogatschlüssel – synthetische Ganzzahlen, die von der Datenbank unabhängig von jeder geschäftlichen Bedeutung generiert werden. Natürliche Schlüssel (etwa eine Produkt-SKU oder eine Kunden-E-Mail-Adresse) können sich im Laufe der Zeit ändern, Surrogatschlüssel hingegen nie.

Surrogatschlüssel schützen die Faktentabelle vor Änderungen in vorgelagerten Systemen und machen Joins schneller, da Ganzzahlvergleiche günstiger sind als Zeichenfolgenvergleiche.

-- Surrogate key approach: integer join is fast
SELECT fs.sale_id, dc.full_name, fs.total_amount
FROM fact_sales fs
JOIN dim_customer dc ON dc.customer_key = fs.customer_key
WHERE dc.country = 'Germany'
LIMIT 10;

-- Natural key approach (avoid in warehouses): slower string join
-- JOIN dim_customer dc ON dc.email = fs.customer_email

Granularität: Detailebene in einer Faktentabelle

Die Granularität einer Faktentabelle beschreibt genau, was eine Zeile darstellt. Bevor Sie ein Data Warehouse erstellen, müssen Sie die Granularität festlegen – zum Beispiel eine Zeile pro einzelner Produktposition in einem Kundenauftrag.

Eine klar definierte Granularität verhindert mehrdeutige Aggregationen. Wenn verschiedene Zeilen unterschiedliche Ereignisse darstellen, sind Ihre SUM- und COUNT-Ergebnisse bedeutungslos.

-- Grain: one row per product per order line
-- Each row = one line item sold in one transaction
SELECT
  sale_id,
  date_key,
  product_key,
  quantity,
  unit_price,
  total_amount
FROM fact_sales
WHERE date_key = 20240315
ORDER BY sale_id;

Additive, semiaddivie und nicht additive Kennzahlen

Fakten gibt es je nach ihrer Aggregierbarkeit in drei Ausprägungen:

  • Additiv – kann über alle Dimensionen summiert werden (z. B. revenue, quantity).
  • Semiaddiv – kann über einige Dimensionen, aber nicht über alle summiert werden (z. B. kann balance eines Kontos über Kunden, aber nicht über die Zeit summiert werden).
  • Nicht additiv – kann nicht sinnvoll summiert werden (z. B. unit_price, ratio). Verwenden Sie stattdessen AVG oder andere Aggregationen.
SELECT
  dd.month_name,
  SUM(fs.total_amount)         AS total_revenue,   -- additive
  AVG(fs.unit_price)           AS avg_unit_price,   -- non-additive: use AVG
  SUM(fs.quantity)             AS total_units       -- additive
FROM fact_sales fs
JOIN dim_date dd ON dd.date_key = fs.date_key
WHERE dd.year = 2024
GROUP BY dd.month_name, dd.month_num
ORDER BY dd.month_num;

Slowly Changing Dimensions (SCD Typ 1 und 2)

Dimensionsattribute ändern sich im Laufe der Zeit – ein Kunde wechselt das Land, ein Produkt die Kategorie. Slowly Changing Dimensions (SCD) bilden diese Änderungen ab:

  • Typ 1 – Den alten Wert überschreiben. Einfach, aber die Historie geht verloren.
  • Typ 2 – Eine neue Zeile mit einem neuen Surrogatschlüssel und Gültigkeitsdaten hinzufügen. Bewahrt die vollständige Historie, sodass historische Fakten weiterhin auf die korrekte Version der Dimension verweisen.
-- SCD Type 2: add a new version of the row
ALTER TABLE dim_customer ADD COLUMN valid_from DATE;
ALTER TABLE dim_customer ADD COLUMN valid_to   DATE;
ALTER TABLE dim_customer ADD COLUMN is_current BOOLEAN DEFAULT TRUE;

-- Expire the old row
UPDATE dim_customer
SET is_current = FALSE,
    valid_to   = CURRENT_DATE - INTERVAL '1 day'
WHERE email = 'anna@example.com' AND is_current = TRUE;

-- Insert the updated version
INSERT INTO dim_customer (full_name, email, country, segment, valid_from, valid_to, is_current)
VALUES ('Anna Muller', 'anna@example.com', 'Austria', 'Premium', CURRENT_DATE, '9999-12-31', TRUE);

Degenerierte Dimensionen

Manchmal benötigt ein Dimensionsattribut keine eigene Tabelle. Eine degenerierte Dimension ist ein Dimensionsschlüssel, der direkt in der Faktentabelle gespeichert wird und dem keine entsprechende Dimensionstabelle zugeordnet ist.

Klassische Beispiele sind Bestellnummern, Rechnungsnummern oder Ticket-IDs. Sie liefern Kontext für Drill-downs, haben aber keine weiteren beschreibenden Spalten, deren Speicherung in einer eigenen Tabelle sich lohnen würde.

-- order_number is a degenerate dimension:
-- it lives in the fact table, no dim_order table needed
CREATE TABLE fact_order_lines (
  line_id      SERIAL PRIMARY KEY,
  order_number VARCHAR(20) NOT NULL,  -- degenerate dimension
  date_key     INT NOT NULL,
  product_key  INT NOT NULL,
  customer_key INT NOT NULL,
  quantity     INT NOT NULL,
  line_total   NUMERIC(12, 2) NOT NULL
);

SELECT order_number, SUM(line_total) AS order_total
FROM fact_order_lines
GROUP BY order_number
ORDER BY order_total DESC
LIMIT 5;

Abfrage des vollständigen Star-Schemas

Alles zusammengeführt: Eine typische Data-Warehouse-Abfrage verknüpft die Faktentabelle mit mehreren Dimensionen, wendet Filter auf Dimensionsattribute an und aggregiert Kennzahlen aus der Faktentabelle.

Der Optimierer kann diese Joins mit mehreren Tabellen effizient verarbeiten, da die Fremdschlüssel der Faktentabelle indiziert sind und die Dimensionstabellen relativ klein sind.

SELECT
  dd.year,
  dd.quarter,
  dp.category,
  dc.country,
  SUM(fs.quantity)     AS units_sold,
  SUM(fs.total_amount) AS revenue
FROM fact_sales fs
JOIN dim_date     dd ON dd.date_key     = fs.date_key
JOIN dim_product  dp ON dp.product_key  = fs.product_key
JOIN dim_customer dc ON dc.customer_key = fs.customer_key
WHERE dd.year IN (2023, 2024)
  AND dp.category = 'Electronics'
GROUP BY dd.year, dd.quarter, dp.category, dc.country
ORDER BY dd.year, dd.quarter, revenue DESC;

Kurztest: Faktentabelle vs. Dimensionstabelle

Testen Sie Ihr Verständnis der Unterschiede zwischen Fakten- und Dimensionstabellen in einem Star-Schema.

Zusammenfassung der Lektion

In dieser Lektion haben Sie die grundlegenden Bausteine eines Star-Schemas für Data Warehouses kennengelernt:

  • Faktentabellen enthalten messbare Ereignisse (Verkäufe, Klicks, Transaktionen) mit numerischen Kennzahlen und Fremdschlüsseln.
  • Dimensionstabellen liefern beschreibenden Kontext (wer, was, wo, wann) mithilfe von Surrogatschlüsseln.
  • Die Granularität legt genau fest, was eine Faktzeile darstellt – definieren Sie sie, bevor Sie das Data Warehouse erstellen.
  • Kennzahlen sind additiv, semiaddiv oder nicht additiv. Das bestimmt, wie Sie sie aggregieren.
  • SCD Typ 2 bewahrt historische Dimensionswerte, indem neue Zeilen mit Gültigkeitsdaten hinzugefügt werden.
  • Degenerierte Dimensionen befinden sich in der Faktentabelle, wenn sie keine zusätzlichen beschreibenden Attribute haben.

Das Verständnis von Fakten- und Dimensionstabellen bildet die Grundlage für schnelle, skalierbare und analytisch leistungsfähige Data Warehouses.

Häufig gestellte Fragen

Ist die Lektion „Fakten- und Dimensionstabellen“ kostenlos?

Ja — der vollständige Text von „Fakten- und Dimensionstabellen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Fakten- und Dimensionstabellen“?

Die Bausteine eines Data-Warehouse Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um SQL Academy zu starten?

Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Fakten- und Dimensionstabellen“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?

Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. OLTP vs. OLAP
  2. Fakten- und Dimensionstabellen
  3. Stern- und Schneeflockenschemata
  4. Analytische Abfragen schreiben
← Zurück zu SQL Academy