Zuletzt aktualisiert am 16.12.2025 6 Minuten Lesezeit

View

Eine View (deutsch: Sicht) ist eine virtuelle Tabelle in einer relationalen Datenbank, die auf einer gespeicherten SQL-Abfrage basiert. Anders als physische Tabellen speichert eine View keine eigenen Daten, sondern berechnet ihr Ergebnis bei jedem Zugriff dynamisch aus den zugrundeliegenden Basistabellen. Views ermoeglichen es dir, komplexe Abfragen zu kapseln, Zugriffsrechte fein zu steuern und eine logische Abstraktionsschicht zwischen Anwendungen und dem physischen Datenbankschema zu schaffen.

Wie funktioniert eine View?

Wenn du eine View erstellst, speichert das Datenbanksystem lediglich die SQL-Abfrage (die sogenannte View-Definition), nicht aber das Ergebnis. Bei jedem Zugriff auf die View fuehrt die Datenbank die gespeicherte Abfrage aus und liefert aktuelle Daten aus den Basistabellen zurueck. Dieser Mechanismus wird als View-Aufloeosung oder Query Unfolding bezeichnet.

-- View erstellen
CREATE VIEW aktive_mitarbeiter AS
SELECT 
    m.mitarbeiter_id,
    m.vorname,
    m.nachname,
    a.abteilungsname
FROM mitarbeiter m
INNER JOIN abteilungen a ON m.abteilung_id = a.abteilung_id
WHERE m.status = 'aktiv';

-- View abfragen (wie eine normale Tabelle)
SELECT * FROM aktive_mitarbeiter
WHERE abteilungsname = 'Entwicklung';

In diesem Beispiel kombiniert die View aktive_mitarbeiter Daten aus zwei Tabellen und filtert nur aktive Mitarbeiter. Nutzer der View muessen die zugrundeliegende Tabellenstruktur nicht kennen und koennen die View wie eine regulaere Tabelle verwenden.

Arten von Views

Je nach Anwendungsfall und Datenbanksystem gibt es verschiedene View-Typen mit unterschiedlichen Eigenschaften:

Standard-Views

Die gaengigste Form einer View. Sie speichert nur die Abfragedefinition und berechnet das Ergebnis bei jedem Zugriff neu. Standard-Views liefern immer aktuelle Daten, verursachen aber bei komplexen Abfragen Rechenaufwand.

Materialized Views

Materialized Views (materialisierte Sichten) speichern das Abfrageergebnis physisch als Tabelle. Dadurch sind Lesezugriffe deutlich schneller, allerdings koennen die Daten veraltet sein. Ein Refresh-Mechanismus aktualisiert die gespeicherten Daten periodisch oder bei Bedarf.

-- Materialized View in PostgreSQL
CREATE MATERIALIZED VIEW umsatz_pro_monat AS
SELECT 
    DATE_TRUNC('month', bestelldatum) AS monat,
    SUM(betrag) AS gesamtumsatz
FROM bestellungen
GROUP BY DATE_TRUNC('month', bestelldatum);

-- Materialized View aktualisieren
REFRESH MATERIALIZED VIEW umsatz_pro_monat;

Indexed Views (SQL Server)

In Microsoft SQL Server heissen materialisierte Views Indexed Views. Sie erfordern einen eindeutigen Clustered Index und die Option WITH SCHEMABINDING, die eine feste Bindung an das Schema der Basistabellen herstellt.

Partitioned Views

Partitioned Views kombinieren mehrere Tabellen ueber UNION ALL zu einer logischen Einheit. Sie werden haeufig eingesetzt, um horizontal partitionierte Daten (z.B. nach Region oder Zeitraum) als eine zusammenhaengende Tabelle darzustellen.

System-Views

Datenbanksysteme stellen System-Views bereit, die Metadaten ueber die Datenbankstruktur liefern. In SQL Server findest du diese im sys-Schema (z.B. sys.tables, sys.columns), in MySQL im information_schema.

Vorteile von Views

  • Komplexitaet verbergen: Views kapseln komplexe JOIN- und Aggregationslogik. Anwender arbeiten mit einfachen Abfragen
  • Sicherheit: Durch Views kannst du den Zugriff auf bestimmte Spalten oder Zeilen einschraenken, ohne die Basistabellen zu aendern
  • Konsistenz: Geschaeftslogik wird zentral in der View definiert. Alle Anwendungen nutzen dieselbe Berechnungsgrundlage
  • Schema-Abstraktion: Aenderungen an Basistabellen koennen durch Anpassung der Views abgefangen werden, ohne Anwendungscode zu aendern
  • Wiederverwendbarkeit: Haeufig benoetigte Abfragen muessen nur einmal definiert werden

Nachteile und Einschraenkungen

  • Performance: Komplexe Views mit vielen JOINs koennen bei jedem Aufruf Rechenzeit kosten
  • Verschachtelte Views: Mehrfach verschachtelte Views erschweren die Optimierung durch den Query Optimizer und koennen zu schlechten Ausfuehrungsplaenen fuehren
  • Eingeschraenkte Aktualisierbarkeit: Viele Views sind nicht direkt aktualisierbar (INSERT, UPDATE, DELETE). Nur einfache Views auf einzelne Tabellen ohne Aggregationen erlauben direkte Aenderungen
  • Wartungsaufwand: Bei Schemaanderungen an Basistabellen muessen abhaengige Views geprueft und ggf. angepasst werden

Views und Sicherheit

Views sind ein wichtiges Werkzeug fuer die Datensicherheit in Datenbanken. Du kannst damit vertikale Sicherheit (Spaltenfilterung) und horizontale Sicherheit (Zeilenfilterung) implementieren:

-- Vertikale Sicherheit: Sensible Spalten ausblenden
CREATE VIEW mitarbeiter_oeffentlich AS
SELECT 
    mitarbeiter_id,
    vorname,
    nachname,
    abteilung
    -- Gehalt und Personalnummer werden ausgeblendet
FROM mitarbeiter;

-- Horizontale Sicherheit: Nur eigene Abteilung sichtbar
CREATE VIEW meine_abteilung AS
SELECT *
FROM mitarbeiter
WHERE abteilung_id = CURRENT_USER_ABTEILUNG();

Mit der Option WITH CHECK OPTION stellst du sicher, dass Aenderungen ueber eine View nur Datensaetze betreffen koennen, die auch durch die View sichtbar sind.

Views aktualisieren und loeschen

-- View aendern (SQL Server, PostgreSQL)
CREATE OR REPLACE VIEW aktive_mitarbeiter AS
SELECT 
    m.mitarbeiter_id,
    m.vorname,
    m.nachname,
    m.email,  -- Neue Spalte hinzugefuegt
    a.abteilungsname
FROM mitarbeiter m
INNER JOIN abteilungen a ON m.abteilung_id = a.abteilung_id
WHERE m.status = 'aktiv';

-- View loeschen
DROP VIEW aktive_mitarbeiter;

-- View loeschen mit Pruefung auf Existenz
DROP VIEW IF EXISTS aktive_mitarbeiter;

Views vs. andere Konzepte

Views vs. Materialized Views

Eigenschaft Standard-View Materialized View
Datenspeicherung Keine (nur Abfrage) Physisch gespeichert
Datenaktualitaet Immer aktuell Moeglicherweise veraltet
Leseleistung Abhaengig von Komplexitaet Sehr schnell
Speicherbedarf Minimal Wie normale Tabelle
Aktualisierung Automatisch Manueller Refresh noetig

Views vs. CTEs (Common Table Expressions)

CTEs (definiert mit WITH-Klausel) sind temporaere, benannte Abfragen innerhalb eines einzelnen SQL-Statements. Views hingegen sind persistente Datenbankobjekte, die in mehreren Abfragen wiederverwendet werden koennen. CTEs eignen sich fuer einmalige komplexe Abfragen, Views fuer wiederverwendbare Logik.

Views in der IT-Ausbildung

Views gehoeren zum Grundwissen im Bereich Datenbanken und werden in der IHK-Abschlussprüfung regelmaessig abgefragt. Als Fachinformatiker fuer Anwendungsentwicklung wirst du Views nutzen, um Anwendungen sauber von der Datenbankstruktur zu entkoppeln. Fachinformatiker fuer Daten- und Prozessanalyse setzen Views ein, um komplexe Analyseergebnisse fuer Reporting-Tools bereitzustellen.

Typische Pruefungsfragen zu Views behandeln:

  • Unterschied zwischen View und Tabelle
  • Wann sind Views aktualisierbar?
  • Vor- und Nachteile von Views
  • SQL-Syntax zur Erstellung und Verwendung von Views
  • Sicherheitsaspekte und Zugriffssteuerung

Best Practices

  • Aussagekraeftige Namen: Benenne Views nach ihrem Zweck, z.B. aktive_kunden statt v_1
  • Verschachtelung begrenzen: Vermeide mehr als 2-3 Ebenen verschachtelter Views
  • Dokumentation: Kommentiere komplexe View-Logik
  • Performance testen: Pruefe Ausfuehrungsplaene bei komplexen Views
  • Materialized Views bei Bedarf: Nutze Materialized Views fuer aufwaendige Aggregationen, die nicht sekundenaktuell sein muessen

Quellen und weiterfuehrende Links