Sicht (Datenbank)

Eine Sicht (englisch, SQL: View) ist eine logische Relation (auch virtuelle Relation oder virtuelle Tabelle) in einem Datenbanksystem. Diese logische Relation wird über eine im Datenbankmanagementsystem (DBMS) gespeicherte Abfrage definiert. Der Datenbankbenutzer kann eine Sicht wie eine normale Tabelle abfragen. Wann immer eine Abfrage diese Sicht benutzt, wird diese zuvor durch das Datenbankmanagementsystem berechnet. Eine Sicht stellt im Wesentlichen einen Alias für eine Abfrage dar.

Beispiel in SQL

 SELECT SoftwareVerkaeufe AS
   SELECT v.kaeufer, v.verkaeufer
   FROM   produkte p, verkaeufe v
   WHERE  p.produkt_id = v.produkt_id
      AND p.produkt = "Software"

oder (erzeugt das gleiche Ergebnis):

 CREATE VIEW SoftwareVerkaeufe AS
   SELECT v.kaeufer, v.verkaeufer
   FROM   produkte p, verkaeufe v
   WHERE  p.produkt_id = v.produkt_id 
      AND p.produkt = "Software"

Die Abfragen werden also für alle gespeicherten verkaeufe von produkte(n), die „Software“ sind, den Käufer und den Verkäufer auflisten. Möchte man jede auftretende Kombination „Verkäufer/Käufer“ nur einmal aufführen, so müsste die Abfrage um eine zusätzliche Anweisung ('Aggregation') erweitert werden. Das gilt auch wenn eine bestimmte Sortierfolge gewünscht wäre (ORDER BY).

Eine nachfolgende Abfrage "SELECT verkaeufer FROM SoftwareVerkaeufe" würde sich auf das Ergebnis dieser Sicht beziehen und würde nur die Verkäufer auflisten (die Software verkauft haben), zweckmäßigerweise ebenfalls mit Aggregationsfunktion.

Funktion einer Sicht

Die Aufgabe einer Sicht ist es, den Zugriff auf das Datenbankschema zu vereinfachen. Normalisierte Datenbankschemata verteilen Daten auf zahlreiche Tabellen mit komplexen Abhängigkeiten. Dies führt zu aufwändigen SQL-Abfragen. Außerdem wird ein hohes Maß an Wissen über das Schema vorausgesetzt, um solche Abfragen zu erstellen. Das Bereitstellen geeigneter Sichten erlaubt einen einfachen Zugriff, ohne Kenntnis des darunter liegenden Schemas und ohne Aufweichung der Normalisierung.

Ein weiterer Vorteil von Sichten ist, dass das DBMS keinen zusätzlichen Aufwand zur Vorbereitung der Abfrage benötigt. Die Sicht-Abfrage wurde vom Parser bereits bei der Erstellung syntaktisch zerlegt und vom Anfrageoptimierer vereinfacht.

Ein Nachteil von Sichten kann sein, dass die Komplexität der dahinter liegenden Abfrage unterschätzt wird. Der Aufruf einer Sicht kann zu sehr aufwändigen Abfragen führen und der unbedachte Einsatz solcher dann zu erheblichen Performanceproblemen.

Sichten sind essentiell beim Zusammenführen (Föderieren) von Datenbanken, da es durch sie möglich ist, existierenden Programmen den Zugriff auf die Daten, deren Struktur sich durch die Föderation geändert haben kann, weiterhin zu erlauben.

Sichten können zusätzlich – etwa in Verbindung mit Rollen – als ein Mittel des Datenschutzes verwendet werden.

Arten von Sichten

Sichten können anhand der verwendeten Anweisungen in verschiedene Klassen eingeteilt werden, die unterschiedliche Aufgaben haben.

Eine Selektionssicht filtert aus einer Tabelle bestimmte Zeilen heraus.
Eine Projektionssicht filtert bestimmte Spalten.
Eine Verbundsicht verknüpft mehrere Tabellen.
Eine Aggregationssicht wendet Aggregationsfunktionen (MIN, MAX, COUNT etc.) an.
Eine rekursive Sicht (in SQL nicht möglich) wendet eine Sicht immer wieder auf ihr Ergebnis an.
Eine objektrelationale Sicht basiert auf einem benutzerdefinierten Datentyp und stellt die objektrelationale Sicht auf eine relationale Tabelle dar.

Eine Sicht kann dabei Daten aus mehreren Tabellen gleichzeitig selektieren.

Updates

Updates auf eine Sicht sind im Allgemeinen nicht möglich, da sie zu Anomalien führen können. Auf die Sicht kann dann nur lesend zugegriffen werden. In besonderen Fällen, in denen das DBMS eine eindeutige Zuordnung zwischen den in der Sicht zu ändernden Daten und einer physikalischen Tabelle, zu der sie gehören, herstellen kann, ist ein Update möglich. Beispiel für so eine updatable view wäre folgende triviale Sicht:

 CREATE VIEW ''SoftwareVerkaeufe2'' AS ''SELECT verkaeufe.kaeufer''

Ein Update auf SoftwareVerkaeufe2 kann hier eindeutig select verkaeufe.kaeufer zugeordnet werden.

Im Beispiel unten ist eine eindeutige Zuordnung nicht möglich, da produkt_id in beiden Quellrelationen enthalten ist, …

 CREATE VIEW SoftwareVerkaeufe AS
   SELECT v.kaeufer, v.verkaeufer
     FROM produkte p, verkaeufe v
    WHERE p.produkt_id = v.produkt_id -- ← Achtung!
      AND p.produkt = "Software"

… und z.B. bei einer Löschung wie in …

 DELETE FROM SoftwareVerkaeufe WHERE produkt_id = 123456

… nicht entscheidbar ist, ob Datensätze aus Produkte oder Verkaeufe gelöscht werden sollen.

Eine solche Anomalie entsteht in einer Situation, wo eine Durchführung der Änderung nicht den Erwartungen des Benutzers entspricht oder nicht entscheidbar ist, welche Änderungen genau durchzuführen sind. Man kann sie folgendermaßen einteilen:

In einer Selektionssicht können Datensätze aus dem sichtbaren Bereich verschwinden, wenn ein in der Sicht vorhandener Datensatz so geändert wird, dass er aus der Sicht herausfällt („Tupelmigration“).
In einer Projektionssicht kann eine Einfügeoperation dann problematisch werden, wenn in der Originalrelation Felder vorhanden sind, die belegt sein müssen (NOT NULL), aber nicht in der Sicht vorkommen, oder wenn die Sicht durch die Angabe von DISTINCT gleiche Ergebnistupel zu einem zusammenfasst.
In einer Verbundsicht ist nicht immer entscheidbar, auf welcher Originalrelation die Operation auszuführen ist.
In einer Aggregationssicht kann nicht entschieden werden, wie die Operation umzusetzen ist. Zum Beispiel ist nicht klar, wie eine Halbierung aller Verkaufszahlen auf die Originalrelation umzusetzen ist: Entweder kann die Hälfte der Verkäufe gelöscht oder die einzelnen Verkäufe halbiert werden.
Bei rekursiven Sichten (möglich ab Oracle 10g, DB2 V8), z.B. der Berechnung aller Vorfahren einer Person aus einer Tabelle ELTERN(Eltern, Kind), ist nicht klar, wie eine Einfügeoperation („Vorfahr hinzufügen“) umzusetzen ist.

In SQL-92 ist nur die Änderung reiner Selektionssichten erlaubt. Die Option WITH CHECK OPTION im CREATE VIEW-Statement gibt dann an, ob Änderungen, die zum Verschwinden des Datensatzes aus der Sicht führen würden, verboten sein sollen. In SQL-99 wurde die Menge an änderbaren Sichten deutlich erweitert, bleibt aber immer noch hinter der theoretisch möglichen zurück.

In neueren SQL-Dialekten ist es möglich, Trigger dazu einzusetzen, Updateoperationen auf Sichten von Hand zu implementieren.

Materialized View

Neben den herkömmlichen Sichten gibt es noch so genannte materialisierte Sichten (englisch materialized views), auch Indexed Views (Microsoft) oder Automatic Summary Tables (IBM) genannt. Diese sind in der Datenbank abgelegte Kopien von Sichten (Master Sites) zu einem bestimmten Zeitpunkt. Sie fungieren als Cache, um Zugriffe zu beschleunigen und die Netzwerklast zu verringern. Das wird wegen der großen Datenmengen vor allem bei OLAP ausgenutzt. Mittlerweile spielen diese Views auch in herkömmlichen Datenbanken eine Rolle, da sie bei der Erstellung und Optimierung von QEPs berücksichtigt werden.

Es gibt verschiedene Grundideen, materialisierte Sichten aktuell zu halten:

inkrementelle Updates (logbasiert)
komplette Neuerstellung (einfach aber extrem teuer)

und Zeitpunkte:

transaktionsbasiert bei Update der Basistabellen (damit versteckte Kosten für den Updater)
zeitpunktgebunden (mit zeitweise nichtaktuellen Daten in der View)

Diese Aktualisierungen (refreshes) gehen von einer übergeordneten materialisierten Sicht oder von einer Master Site aus.

Die Theorie materialisierter Sichten ist schon seit den 1980er Jahren bekannt, wurde aber erst seit 1998 z.B. von Oracle (ab Vers. 8i), IBM (DB2, nicht aber Informix) und Microsoft in ihren Produkten umgesetzt. Der nächste Schritt über die Verwendung materialisierter Sichten bei der Erstellung von Auswertungsplänen hinaus ist die automatische Erstellung materialisierter Sichten aus der sinnvollsten Schnittmenge der Anfragen von Nutzern.

Basierend auf einem Artikel in:

Wikipedia.de