Sicht (Datenbank)

Grundidee und Nutzen

Eine Sicht (englisch und in SQL: View) ist eine logische Relation in einem Datenbanksystem. Sie wird auch virtuelle Relation oder virtuelle Tabelle genannt. Technisch ist sie eine im Datenbankmanagementsystem (DBMS) gespeicherte Abfrage. Benutzer können eine Sicht wie eine normale Tabelle abfragen. Wenn eine Abfrage die Sicht verwendet, berechnet das DBMS die Sicht vorher beziehungsweise bezieht ihre gespeicherte Abfrage in die Auswertung ein. Im Kern ist eine Sicht also ein Alias für eine Abfrage.

Sichten sind wichtig, weil sie den Zugriff auf ein Datenbankschema vereinfachen. In normalisierten Datenbankschemas sind Daten oft auf viele Tabellen mit komplexen Abhängigkeiten verteilt. Ohne Sicht müssten Benutzer dafür häufig aufwändige SQL-Abfragen schreiben und das zugrunde liegende Schema gut kennen. Geeignete Sichten ermöglichen einfachen Zugriff, ohne die Normalisierung aufzugeben.

Sichten können außerdem beim Zusammenführen, also Föderieren, von Datenbanken helfen. Wenn sich durch die Föderation die Struktur der Daten ändert, können vorhandene Programme über Sichten weiterhin auf die Daten zugreifen. Zusätzlich können Sichten, etwa zusammen mit Rollen, als Mittel des Datenschutzes verwendet werden.

SQL-Beispiel

Das Artikelbeispiel definiert eine Sicht namens SoftwareVerkaeufe. Sie listet aus den Tabellen produkte und verkaeufe Käufer und Verkäufer für alle Verkäufe auf, bei denen das Produkt „Software“ ist:

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 Bedingung p.produkt_id = v.produkt_id verbindet die beiden Tabellen über die Produkt-ID. Die Bedingung p.produkt = "Software" filtert nur Software-Produkte heraus. Eine spätere Abfrage wie SELECT verkaeufer FROM SoftwareVerkaeufe bezieht sich dann auf das Ergebnis dieser Sicht und listet nur Verkäufer auf, die Software verkauft haben.

Wenn jede Kombination „Verkäufer/Käufer“ nur einmal erscheinen soll, muss die Abfrage um eine zusätzliche Anweisung zur Aggregation erweitert werden. Auch eine bestimmte Sortierfolge müsste ausdrücklich angegeben werden, zum Beispiel mit ORDER BY.

Leistung und Optimierung

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

Ein Nachteil kann sein, dass Benutzer die Komplexität der hinter einer Sicht liegenden Abfrage unterschätzen. Der Aufruf einer Sicht kann zu sehr aufwändigen Abfragen führen und dadurch Performanceprobleme verursachen. Wie groß der Mehraufwand ist, hängt stark von der Güte des Anfrageoptimierers ab.

Bei einer naiven Ausführung würde das DBMS zuerst die gespeicherte Sicht-Abfrage ausführen und danach die eigentliche Abfrage Q auf deren Ergebnis-Relation anwenden. Hochleistungs-DBMS wie Oracle und DB2 behandeln dies anders: Sie interpretieren Sicht-Abfrage und äußere Abfrage Q als geschachtelten Abfrageausdruck und optimieren ihn als eine einzige Abfrage. Dabei können etwa überflüssige Teilausdrücke entfernt oder Operationen zusammengefasst werden. In günstigen Fällen entsteht daraus eine einfache Abfrage, die direkt auf den gespeicherten Relationen ausgeführt wird und vorhandene Indexe nutzen kann.

Arten von Sichten

Sichten lassen sich nach den verwendeten Anweisungen in verschiedene Klassen einteilen. Eine Selektionssicht filtert aus einer Tabelle bestimmte Zeilen heraus. Eine Projektionssicht filtert bestimmte Spalten. Eine Verbundsicht verknüpft mehrere Tabellen. Eine Aggregationssicht wendet Aggregationsfunktionen wie MIN, MAX oder COUNT an.

Eine rekursive Sicht wendet eine Sicht immer wieder auf ihr eigenes Ergebnis an; der Artikel merkt an, dass dies in SQL nicht möglich sei, nennt später aber rekursive Sichten als möglich ab Oracle 10g und DB2 V8. Eine objektrelationale Sicht basiert auf einem benutzerdefinierten Datentyp und stellt eine objektrelationale Sicht auf eine relationale Tabelle dar.

Eine Sicht kann Daten aus mehreren Tabellen gleichzeitig selektieren. Die Einteilung beschreibt also typische Aufgaben, schließt Kombinationen aber nicht aus.

Änderungen über Sichten

Updates auf eine Sicht sind im Allgemeinen nicht möglich, weil sie zu Anomalien führen können. Dann kann auf die Sicht nur lesend zugegriffen werden. Ein Update ist nur in besonderen Fällen möglich, wenn das DBMS eindeutig zuordnen kann, welche Daten in welcher physischen Tabelle geändert werden müssen. Eine solche änderbare Sicht heißt updatable view.

Problematisch wird es zum Beispiel bei einer Verbundsicht, wenn nicht entscheidbar ist, ob eine Löschung Daten aus der Tabelle Produkte oder aus der Tabelle Verkaeufe entfernen soll. Allgemein entsteht eine Anomalie, wenn die Durchführung einer Änderung nicht den Erwartungen des Benutzers entspricht oder nicht entscheidbar ist, welche Änderungen genau auszuführen sind.

Bei Selektionssichten können Datensätze aus dem sichtbaren Bereich verschwinden, wenn eine Änderung dazu führt, dass sie die Auswahlbedingung nicht mehr erfüllen; dies heißt Tupelmigration. Bei Projektionssichten können Einfügungen problematisch sein, wenn in der Originalrelation Pflichtfelder mit NOT NULL existieren, die in der Sicht nicht vorkommen, oder wenn DISTINCT gleiche Ergebnistupel zusammenfasst. Bei Verbundsichten ist oft unklar, auf welcher Originalrelation eine Operation auszuführen ist. Bei Aggregationssichten ist unklar, wie eine Änderung auf die Originaldaten übertragen werden soll, etwa ob bei einer Halbierung aller Verkaufszahlen Verkäufe gelöscht oder einzelne Verkäufe halbiert werden sollen. Bei rekursiven Sichten ist beispielsweise bei „Vorfahr hinzufügen“ nicht klar, welche Einfügung in der Ausgangstabelle ELTERN(Eltern, Kind) gemeint ist.

In SQL-92 ist nur die Änderung reiner Selektionssichten erlaubt. Die Option WITH CHECK OPTION im CREATE VIEW-Statement gibt an, ob Änderungen verboten sein sollen, die dazu führen würden, dass ein Datensatz aus der Sicht verschwindet. In SQL-99 wurde die Menge der änderbaren Sichten deutlich erweitert, bleibt aber hinter dem theoretisch Möglichen zurück. In neueren SQL-Dialekten können Trigger verwendet werden, um Updateoperationen auf Sichten von Hand zu implementieren.

Materialisierte Sichten

Neben herkömmlichen Sichten gibt es materialisierte Sichten, englisch materialized views. Bei Microsoft heißen sie Indexed Views, bei IBM Automatic Summary Tables. Materialisierte Sichten sind in der Datenbank abgelegte Kopien von Sichten zu einem bestimmten Zeitpunkt. Sie dienen als Cache, um Zugriffe zu beschleunigen und die Netzwerklast zu verringern.

Diese Technik wird wegen großer Datenmengen besonders bei OLAP genutzt. Materialisierte Sichten spielen aber auch in herkömmlichen Datenbanken eine Rolle, weil sie bei der Erstellung und Optimierung von QEPs berücksichtigt werden.

Es gibt verschiedene Grundideen, materialisierte Sichten aktuell zu halten: inkrementelle Updates, die logbasiert arbeiten, oder eine komplette Neuerstellung, die einfach, aber extrem teuer ist. Außerdem gibt es verschiedene Zeitpunkte für Aktualisierungen: transaktionsbasiert beim Update der Basistabellen, wodurch versteckte Kosten für den Updater entstehen, oder zeitpunktgebunden, wobei die Daten in der View zeitweise nicht aktuell sind. Solche Aktualisierungen, sogenannte refreshes, gehen von einer übergeordneten materialisierten Sicht oder von einer Master Site aus.

Die Theorie materialisierter Sichten ist seit den 1980er Jahren bekannt. In Produkten wurde sie laut Artikel erst seit 1998 umgesetzt, zum Beispiel von Oracle ab Version 8i, IBM mit DB2, aber nicht Informix, und Microsoft. Als nächster Schritt wird die automatische Erstellung materialisierter Sichten aus der sinnvollsten Schnittmenge der Nutzeranfragen genannt.