Online-Bibliothek

Sicht (Datenbank)

Eine View (deutsch Sicht) 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 View wie eine normale Tabelle abfragen. Wann immer eine Abfrage diese View benutzt, wird diese zuvor durch das Datenbankmanagementsystem berechnet. Eine View stellt im Wesentlichen einen Alias für eine Abfrage dar.

Beispiel in SQL

create view SoftwareVerkäufe as 
  select v.käufer, v.verkäufer 
  from produkte p, verkäufe v 
  where p.produkt_id = v.produkt_id and p.produkt="Software"

Die Abfrage: select verkäufer from SoftwareVerkäufe wird folglich alle Verkäufer auflisten, die Software verkauft haben.

Funktion einer View

Die Aufgabe einer View 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 Views erlaubt einen einfachen Zugriff, ohne Kenntnis des darunter liegenden Schemas und ohne Aufweichung der Normalisierung.

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

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

Views 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.

Ältere Literatur stellt Views außerdem als ein primitives Mittel des Datenschutzes dar. Da moderne DBMS jedoch viel weitergehende Datenschutzmechanismen erlauben und ein Datenschutz mittels Views so nicht gegeben ist, sollten Views nicht dafür verwendet werden.

Arten von Views

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

1. Eine SelektionsView filtert aus einer Tabelle bestimmte Zeilen heraus.
2. Eine ProjektionsView filtert bestimmte Spalten.
3. Eine VerbundView verknüpft mehrere Tabellen.
4. Eine AggregationsView wendet Aggregationsfunktionen (MIN, MAX, COUNT etc.) an.
5. Eine rekursive View (in SQL nicht möglich) wendet eine View immer wieder auf ihr Ergebnis an.

Eine View kann dabei mehreren Klassen gleichzeitig zuzuordnen sein.

Updates

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

create view SoftwareVerkäufe as select v.käufer

Ein Update auf SoftwareVerkäufe kann eindeutig select v.käufer zugeordnet werden. Im Beispiel oben ist eine eindeutige Zuordnung nicht möglich, da produkt_id in beiden Quellrelationen enthalten ist, und z.B. bei einer Löschung wie in

delete from SoftwareVerkäufe where produkt_id=123456

nicht entscheidbar ist, ob Datensätze aus Produkte oder Verkäufe 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:

1. In einer SelektionsView können Datensätze aus dem sichtbaren Bereich verschwinden, wenn ein in der View vorhandener Datensatz so geändert wird, dass er aus der View herausfällt.
2. In einer ProjektionsView 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 View vorkommen, oder wenn die View durch die Angabe von DISTINCT gleiche Ergebnistupel zu einem zusammenfasst.
3. In einer VerbundView ist nicht immer entscheidbar, auf welcher Originalrelation die Operation auszuführen ist.
4. In einer AggregationsView 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.
5. Bei rekursiven Views (in SQL nicht möglich), 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 SelektionsViews erlaubt. Die Option WITH CHECK OPTION im CREATE VIEW-Statement gibt dann an, ob Änderungen, die zum Verschwinden des Datensatzes aus der View führen würden, verboten sein sollen. In SQL-99 wurde die Menge an änderbaren Views 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 Views von Hand zu implementieren.

Materialized View

Neben den herkömmlichen Views gibt es noch so genannte Materialized Views auch Indexed Views (MS), Automatic Summary Tables (IBM) genannt. Diese sind Views, die physikalisch gespeichert werden, um Zugriffe zu beschleunigen. Das findet vor allem bei den großen Datenmengen bei OLAP Anwendung. 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, MVs 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 im View)

Die Theorie materialisierter Sichten ist schon seit den 80er Jahren bekannt, wurde aber erst in jüngster Zeit zB von Oracle, IBM und Microsoft in ihren Produkten umgesetzt.

Der nächste Schritt über die Verwendung materialisierter Sichten bei der Erstellung von QEPs hinaus ist die automatische Erstellung materialisierter Sichten aus der sinnvollsten Schnittmenge der Anfragen von Nutzern.