Materialized View: Definition, Refresh, Abgrenzung

Ein Materialized View ist eine vorberechnete Ergebnis-Tabelle zu einer Datenbank-Abfrage (Query). Anders als eine klassische View, die nur die Abfrage-Vorschrift speichert und bei jedem Zugriff neu ausführt, legt ein Materialized View das Ergebnis dieser Abfrage einmal als echte Tabelle ab und aktualisiert sie in festen Intervallen oder nur für die geänderten Zeilen (Refresh). Wer den Materialized View abfragt, liest die fertigen Daten direkt aus dieser Tabelle, statt die zugrunde liegende Abfrage jedes Mal neu rechnen zu lassen.

Was ist ein Materialized View?

Ein Materialized View trennt zwei Dinge: die Vorschrift, wie ein Ergebnis berechnet wird, und die Ausführung dieser Berechnung. Die Vorschrift entsteht mit dem SQL-Befehl CREATE MATERIALIZED VIEW mv AS SELECT ... und beschreibt, aus welchen Ausgangstabellen (Basistabellen) das Ergebnis kommt, welche Filter, Verknüpfungen (Joins) und Zusammenfassungen (Aggregationen, z. B. Summen oder Durchschnitte) darauf laufen und welche Spalten am Ende entstehen. Die eigentliche Berechnung passiert beim Refresh: Die Datenbank arbeitet die Vorschrift ab, schreibt das Ergebnis als physische Tabelle und legt sie unter dem Namen des Views ab. Abfragen wie SELECT * FROM mv lesen aus dieser Tabelle. Änderungen an den Basistabellen sind erst sichtbar, wenn der nächste Refresh gelaufen ist.

Zwei Refresh-Modi sind üblich. Ein vollständiger Refresh berechnet den Materialized View komplett neu; das ist einfach, aber teuer bei großen Basistabellen. Ein inkrementeller Refresh verarbeitet nur die seit dem letzten Refresh geänderten Zeilen und wendet sie auf den bestehenden Ergebnisstand an. Auf Databricks übernimmt der Enzyme-Optimizer diese inkrementelle Berechnung für Lakeflow Declarative Pipelines und Databricks SQL, auf Snowflake laufen entsprechende Aktualisierungen automatisch über interne Change-Tracking-Mechanismen. Der Trigger für einen Refresh kann zeitgesteuert sein (ALTER MATERIALIZED VIEW ... SET SCHEDULE), ereignisgesteuert (bei jedem Commit auf die Basistabelle), manuell (REFRESH MATERIALIZED VIEW) oder kontinuierlich in Streaming-nahen Pipelines.

Der Begriff stammt aus dem klassischen Data-Warehouse-Umfeld. Oracle hat Materialized Views in Version 8i (1999) eingeführt, PostgreSQL folgte in Version 9.3 (2013). Im Lakehouse-Kontext sind Materialized Views seit 2023 in Databricks SQL allgemein verfügbar und in Lakeflow Declarative Pipelines als deklariertes Pipeline-Ziel etabliert. Physisch liegt ein Materialized View auf Databricks als Delta Table in Unity Catalog, auf Snowflake als interne verwaltete Table Structure, auf PostgreSQL als eigenständiges Heap-Objekt.

Abgrenzung zu View, Delta Table, Streaming Table und Query-Cache

Die häufigsten Verwechslungen betreffen benachbarte Objekt-Klassen mit ähnlichem Namen oder ähnlicher Wirkung.

Konzept	Abgrenzung zum Materialized View
Klassische SQL-View (Virtual View)	Speichert nur die Query-Definition; die Daten bleiben in den Basistabellen. Jede Abfrage führt die Basisquery erneut aus. Der Materialized View kehrt diese Beziehung um: Die Query läuft einmal beim Refresh, Konsumenten lesen aus einer Tabelle.
Delta Table	Entsteht durch expliziten Write (INSERT, MERGE, Streaming-Schreibvorgang). Ein Materialized View entsteht durch Deklaration einer Query und wird von der Engine refresh-verwaltet. Auf Databricks liegt ein Materialized View physisch als Delta Table in Unity Catalog; konzeptuell ist er das nächsthöhere Objekt mit deklarativer Refresh-Semantik.
Streaming Table (Databricks / DLT)	Verarbeitet kontinuierlich einen Datenstrom im Append-Modus mit eigenem Lesefortschritt und Checkpoint. Streaming Tables sind für unbegrenzte, fortlaufende Datenströme. Materialized Views sind für batchartig refresh-bare Aggregate über bekannten Datenbestand.
Query-Result-Cache / Aggregations-Cache	Speichert das Ergebnis einer konkreten Query-Ausführung transient mit TTL oder automatischer Invalidierung. Für den Nutzer ist ein Cache nicht als Objekt adressierbar. Ein Materialized View ist ein benanntes Datenbank-Objekt mit definiertem Refresh-Vertrag und expliziter Governance im Katalog.
Snapshot-Tabelle / Backup-Kopie	Ein Snapshot friert einen Zeitpunkt-Zustand ein und ist nicht refresh-verwaltet. Ein Materialized View bleibt an seine Basisquery gebunden und wird gegen deren Änderungen aktuell gehalten.

Beispiel: Vorberechnete Tages-Aggregate für ein BI-Dashboard

Ein BI-Dashboard zeigt tägliche Umsätze pro Region über die letzten 24 Monate. Die zugrundeliegende Query joint eine Fact-Tabelle mit 800 Millionen Order-Zeilen mit drei Dimensionstabellen und aggregiert nach Region und Datum. Als klassische View würde jeder Dashboard-Aufruf den vollständigen Join und die Aggregation neu ausführen und mehrere Sekunden Latenz erzeugen. Als Materialized View läuft die Aggregation einmal beim Refresh; das Dashboard liest die Ergebnistabelle in unter 200 Millisekunden.

sql

CREATE MATERIALIZED VIEW analytics.sales_daily_region AS
SELECT
  region,
  order_date,
  COUNT(*)    AS order_count,
  SUM(amount) AS revenue,
  AVG(amount) AS avg_order_value
FROM sales.orders o
JOIN sales.customers c ON o.customer_id = c.customer_id
JOIN sales.regions   r ON c.region_id   = r.region_id
WHERE order_date >= current_date() - INTERVAL 24 MONTH
GROUP BY region, order_date;

-- Databricks: inkrementeller Refresh alle 15 Minuten
ALTER MATERIALIZED VIEW analytics.sales_daily_region
  SET SCHEDULE EVERY 15 MINUTES;

Beim ersten Refresh berechnet die Engine den vollständigen Join und die Aggregation. Ab dem zweiten Refresh verarbeitet der Enzyme-Optimizer nur die seit dem vorigen Refresh geänderten Order-Zeilen und pflegt die Aggregate in analytics.sales_daily_region inkrementell nach. Der Materialized View ist im Unity Catalog als Delta Table registriert; Rechte, Lineage und Data-Quality-Regeln greifen wie bei einer gewöhnlichen Delta Table.