View
Eine View ist eine virtuelle Tabelle in einer relationalen Datenbank, die auf einer gespeicherten SQL-Abfrage basiert und ihr Ergebnis dynamisch aus Basistabellen berechnet, ohne eigene Daten zu speichern.
Auf dieser Seite
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 ermöglichen 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 führt die Datenbank die gespeicherte Abfrage aus und liefert aktuelle Daten aus den Basistabellen zurück. Dieser Mechanismus wird als View-Auflösung 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 müssen die zugrundeliegende Tabellenstruktur nicht kennen und können die View wie eine reguläre Tabelle verwenden.
Arten von Views
Je nach Anwendungsfall und Datenbanksystem gibt es verschiedene View-Typen mit unterschiedlichen Eigenschaften:
Standard-Views
Die gängigste 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 können 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 heißen 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 über UNION ALL zu einer logischen Einheit. Sie werden häufig eingesetzt, um horizontal partitionierte Daten (z.B. nach Region oder Zeitraum) als eine zusammenhängende Tabelle darzustellen.
System-Views
Datenbanksysteme stellen System-Views bereit, die Metadaten über 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
- Komplexität verbergen: Views kapseln komplexe JOIN- und Aggregationslogik. Anwender arbeiten mit einfachen Abfragen
- Sicherheit: Durch Views kannst du den Zugriff auf bestimmte Spalten oder Zeilen einschränken, ohne die Basistabellen zu ändern
- Konsistenz: Geschäftslogik wird zentral in der View definiert. Alle Anwendungen nutzen dieselbe Berechnungsgrundlage
- Schema-Abstraktion: Änderungen an Basistabellen können durch Anpassung der Views abgefangen werden, ohne Anwendungscode zu ändern
- Wiederverwendbarkeit: Häufig benötigte Abfragen müssen nur einmal definiert werden
Nachteile und Einschränkungen
- Performance: Komplexe Views mit vielen JOINs können bei jedem Aufruf Rechenzeit kosten
- Verschachtelte Views: Mehrfach verschachtelte Views erschweren die Optimierung durch den Query Optimizer und können zu schlechten Ausführungsplänen führen
- Eingeschränkte Aktualisierbarkeit: Viele Views sind nicht direkt aktualisierbar (INSERT, UPDATE, DELETE). Nur einfache Views auf einzelne Tabellen ohne Aggregationen erlauben direkte Änderungen
- Wartungsaufwand: Bei Schemaänderungen an Basistabellen müssen abhängige Views geprüft und ggf. angepasst werden
Views und Sicherheit
Views sind ein wichtiges Werkzeug für 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 Änderungen über eine View nur Datensätze betreffen können, die auch durch die View sichtbar sind.
Views aktualisieren und löschen
-- View ändern (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 löschen
DROP VIEW aktive_mitarbeiter;
-- View löschen mit Prüfung 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 |
| Datenaktualität | Immer aktuell | Möglicherweise veraltet |
| Leseleistung | Abhängig von Komplexität | Sehr schnell |
| Speicherbedarf | Minimal | Wie normale Tabelle |
| Aktualisierung | Automatisch | Manueller Refresh nötig |
Views vs. CTEs (Common Table Expressions)
CTEs (definiert mit WITH-Klausel) sind temporäre, benannte Abfragen innerhalb eines einzelnen SQL-Statements. Views hingegen sind persistente Datenbankobjekte, die in mehreren Abfragen wiederverwendet werden können. CTEs eignen sich für einmalige komplexe Abfragen, Views für wiederverwendbare Logik.
Views in der IT-Ausbildung
Views gehören zum Grundwissen im Bereich Datenbanken und werden in der IHK-Abschlussprüfung regelmäßig abgefragt. Als Fachinformatiker für Anwendungsentwicklung wirst du Views nutzen, um Anwendungen sauber von der Datenbankstruktur zu entkoppeln. Fachinformatiker für Daten- und Prozessanalyse setzen Views ein, um komplexe Analyseergebnisse für Reporting-Tools bereitzustellen.
Typische Prüfungsfragen 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
- Aussagekräftige Namen: Benenne Views nach ihrem Zweck, z.B.
aktive_kundenstattv_1 - Verschachtelung begrenzen: Vermeide mehr als 2–3 Ebenen verschachtelter Views
- Dokumentation: Kommentiere komplexe View-Logik
- Performance testen: Prüfe Ausführungspläne bei komplexen Views
- Materialized Views bei Bedarf: Nutze Materialized Views für aufwendige Aggregationen, die nicht sekundenaktuell sein müssen
Quellen und weiterführende Links
- W3Schools SQL Views Tutorial - Einführung in SQL Views
- Microsoft Docs: Views - Offizielle SQL Server Dokumentation
- PostgreSQL: Materialized Views - PostgreSQL Dokumentation zu Materialized Views
- Wikipedia: Sicht (Datenbank) - Grundlagen und Geschichte
Prüfungsbezug
Passt zu deiner Prüfungsvorbereitung
Wenn dir dieser Begriff in Aufgaben, Projektdokumentation oder Fachgespräch begegnet, ordne ihn direkt in den Prüfungsstoff ein.