datenbanksoftware.net

Sicht (Datenbank)

28.06.2010 @ 08:57, Ersatzersatz,

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

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 Abfrage: SELECT verkaeufer FROM SoftwareVerkaeufe wird folglich alle Verkäufer auflisten, die Software verkauft haben.

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

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

Arten von Sichten

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

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

Eine Sicht kann dabei mehreren Klassen gleichzeitig zuzuordnen sein.

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:

1. 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.
2. 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.
3. In einer Verbundsicht ist nicht immer entscheidbar, auf welcher Originalrelation die Operation auszuführen ist.
4. 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.
5. 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 Sichten, 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 in der View)

Die Theorie materialisierter Sichten ist schon seit den 80er Jahren bekannt, wurde aber erst in jüngster Zeit z. B. 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.

Kategorie:Datenbank
Kategorie:Datenbankmodellierung

cs:Pohled (databáze)
View (database)
es:Vista (base de datos)
Vue (base de données)
it:Vista (database)
ja:ビュー (データベース)
no:Visninger (database)
pl:Perspektywa (bazy danych)
pt:Visão (banco de dados)
ru:Представление (базы данных)
sk:Pohľad (databáza)
zh:视图

weiter