Änderbare Sicht

Mittels der CREATE VIEW-Anweisung werden Sichten angelegt, die unter bestimmten Umständen sogenannte änderbare Sichten sind. Der Name täuscht etwas: gemeint ist hier, dass die Manipulationen der abgeleiteten Sichtdaten automatisch vom DBMS? in Manipulationen der ursprünglichen Tabellendaten transformiert und ausgeführt werden. Das Gegenteil sind dann nicht änderbare Sichten, d.h. Sichten, bei denen die Manipulation der Daten selbstprogrammierten INSTEAD-OF-TRIGGERN übertragen wird.

Grundsätzlich gilt, dass DML-Befehle (INSERT, UPDATE, DELETE?) sowohl auf Tabellen wie auch auf Sichten anwendbar sind. Für Anwender ist es transparent, ob es sich um Sichten oder Tabellen handelt. Bei Sichten stellt sich jedoch sofort die Frage, wie die Daten aus den zugrunde liegenden Tabellen manipuliert werden müssen, damit sie die gewünschten Manipulationen an den Sichtdaten zur Folge haben, was allgemein als das View-Updating-Problem bezeichnet wird. In der wissenschaftlichen Diskussion sind noch nicht für beliebig komplexe Anfragen automatisierte Transformationen entwickelt worden. Oracle bedient sich jedoch nur einer sehr einfachen Lösung. Ähnliches gilt für IBM DBS2 und Microsoft SQL Server.

Für die Durchführung von Sichtmanipulationen ergibt sich nun eine Reihe von notwendigen oder wünschenswerten Kriterien, die im Folgenden kurz dargestellt werden:

  • Effektkonformität: Manipulationen eines Benutzers auf den Daten der Sicht sollen dem Benutzer nach der Manipulation der Daten der zugrunde liegenden Tabellen so dargestellt werden, als wären die Manipulationen auf den Sichtdaten direkt ausgeführt worden.
  • Minimalität: Um einen gewünschten Effekt zu erhalten, sollen die Daten der zugrunde liegenden Tabellen möglichst minimal manipuliert werden.
  • Konsistenzerhaltung: Manipulationen von Daten einer Sicht dürfen nicht zu Integritätsverletzungen der Daten der zugrunde liegenden Tabellen führen.
  • Respektierung der Zugriffskontrolle: Wenn aus Gründen der Zugriffskontrolle eine Sicht erstellt wurde, darf der bewusst ausgeblendete Teil der Basisdatenbank von Änderungen der Sicht nicht beeinflusst werden.

Hier ein paar Beispiele, um die die Problematik etwas zu verdeutlichen:

  • Es können Datensätze so geändert werden, dass sie bei erneuter Anfrage an die Sicht nicht mehr in der Ergebnismenge vertreten sind. Wenn dies irrtümlicherweise geschehen ist, hat der Anwender keine Möglichkeit, seinen Irrtum wieder zu korrigieren.
  • Meist sind die möglichen Reaktionen für das DBMS nicht eindeutig automatisch ableitbar, z.B. wenn beim Erfassen eines Kunden ein Land angegeben wird, welches es bislang nicht gab. Ist das dann ein Fehler oder soll das Land dann gleich mit erfasst werden in der Länder-Tabelle. Solche Entscheidungen lassen sich nur mit dem semantischen Hintergrundwissen der Entwickler im Kontext der Anwendung richtig lösen.

Und nun die Problemfälle änderbarer Sichten analysiert nach verschiedenen Sichttypen

Projektionssichten

In reinen Projektionssichten werden aus nur einer Tabelle einige gewünschte Attribute (Spalten) projiziert. Bei einer Änderung auf den Daten einer solchen Sicht muss berücksichtigt werden, dass diese auch auf die zugrunde liegende Basisrelation transformiert werden müssen. Beim Löschen von einzelnen oder mehreren Tupeln gibt es bei einer Projektionssicht keinerlei Probleme. Wohingegen beim Einfügen von Tupeln darauf geachtet werden muss, dass eine Lösung für die Behandlung der ausgeblendeten Attribute gefunden werden muss. Eine Lösung des Problems ist das Einfügen von NULL-Werten (also undefinierten Attributwerten) an die Stelle des ausgeblendeten Attributs. Gegebenenfalls tritt das Problem der Konsistenzerhaltung auf der Tabelle (Basisrelation) auf. Grundsätzlich ist das Einfügen auf Projektionssichten nur dann erlaubt, wenn keine mit NOT NULL deklarierten Attribute auf NULL gesetzt werden müssten. Ein Einfügen würde dann nur möglich sein, wenn die Attribute den Wert NULL annehmen dürften. Eine Alternative bietet sich für diesen speziellen Weg darin an, wenn statt des Wertes NULL ein Default-Wert eingesetzt würde, der in der Datenbankdefinition spezifiziert wurde. Ein weiteres Problem tritt auf, wenn z.B. eine Änderung in einer Sicht gleich mehrere Tupel in der Basisrelation betreffen würde.

Selektionssichten

In Selektionssichten werden Datensätze (Zeilen) herausgefiltert. Hierbei tritt nun das Problem auf, dass das Ändern der Sicht ein Tupel der Sicht in den nicht selektierten Teil der Sicht verschieben kann. Dieses Problem wird auch als Tupelmigration zwischen verschiedenen Sichten bezeichnet. Die Selektionsbedingung muss also um die Selektion der Sichtdefinition erweitert werden, da anderenfalls bei der Transformation auch ein mögliches anderes Tupel, welches nicht in der Sicht enthalten ist, geändert werden könnte. Ein Test auf Tupelmigration kann im SQL-Standard explizit in der Sicht gefordert werden, indem die Angabe WITH CHECK OPTION angefügt wird.

Verbundsichten

Eine Verbundsicht ist eine Sicht, deren Ableitungsvorschrift eine Join-Verknüpfung zwischen mehreren Tabellen durchführt, das können z.B. Natural-Joins, Outer-Joins, Theta-Joins sein. Änderungsoperationen können in der Regel nicht eindeutig übersetzt werden. Die Mehrdeutigkeit der Umsetzung wird noch deutlicher beim Löschen eines Tupels. Bei Verbundsichten lassen sich Manipulationen im Allgemeinen nicht eindeutig übersetzten. Die Mehrdeutigkeit müsste also in der Sichtdefinition durch explizite Regeln beseitigt werden (SQL-92) oder Änderungen auf Verbundsichten generell verboten werden. SQL:2003 schreibt vor, dass Sichtänderungen bei Verbundsichten auf die Typen von Änderungen und Verbunden beschränkt werden, bei der die eindeutige Zuordnung von Tupeln in den Basisrelationen und der Sicht erreicht wird.

Aggregierungssichten

Eine Sicht, deren Datensätze aus mehreren Datensätzen einer (oder mehrerer) Tabellen (Basisrelationen) durch Gruppierung (GROUP BY-Klausel der SELECT-Ableitungsvorschrift) und Aggregierung (Gruppenfunktionen wie z.B. SUM, MIN, MAX, AVG oder COUNT]) berechnet werden, bezeichnet man als Aggregationssicht. Hierbei tritt nun das Problem auf, dass Änderungen der aggregierten Werte nicht sinnvoll übersetzt werden können, da das System nicht ohne Hintergrundinformationen entscheiden kann, wie sich die Änderungen auf die verschiedenen Datensätze der Tabellen verteilen.

Klassifikation der Problembereiche

Zusammenfassend können mehrere Problembereiche unabhängig vom eingesetzten Datenmodell beschreiben werden:

  1. Verletzung bei Schemadefinition, z.B. bei Einfügen von Nullwerten bei Projektionssichten. Grundsätzlich betrifft dies die Vermeidung von Integritätsverletzungen.
  2. Vermeidung von Seiteneffekten auf den nicht sichtbaren Teil der Datenbank, z.B. Tupelmigration bei Selektionssichten.
  3. Auswahlproblem bei mehreren Transformationsmöglichkeiten.
  4. Keine sinnvolle Transformationsmöglichkeit, z.B. bei Aggregierungssichten.
  5. Die häufige Forderung, dass eine elementare Änderung auf der Sicht ebenfalls genau einer atomaren Änderung auf der Basisrelation entspricht, würde im Relationenmodell eine 1:1-Beziehung zwischen Sichttupeln und Tupeln der Basisrelation erfordern. Dies ist aber z.B. beim Herausprojizieren von Schlüsseln nicht gegeben.


Änderbare Sichten bei Oracle

Änderbare Sichten werden bei Oracle "editioning views" genannt. Die zentrale Einschränkung für eine änderbare Sicht ist, dass diese Sicht auf einer SELECT-Anfrage basiert, die nur Daten aus einer Tabelle selektiert. In diesem sehr einfachen Fall ist das Oracle-DBMS? in der Lage, die Manipulationen an den Daten der Sicht automatisch in Manipulationen an den Daten der zugrunde liegenden Tabelle zu transformieren. Eine solche Sicht kann mit der Klausel EDITIONING vor dem Schlüsselwort VIEW definiert werden. In den Data Dictionary-Tabellen USER/ALL/DBA_EDITIONING_VIEWS bzw. USER/ALL/DBA_EDITIONING_VIEWS_AE sind die definierten änderbaren Sichten zu finden.

Dort, wo das Konzept der änderbaren Sichten bei Oracle an seine Grenzen stößt, definiert man für nicht-Aenderbare-Sicht mit Hilfe von INSTEAD-OF-TRIGGERn.

Quellen:

  • ANSI/ISO/IEC 9075-1:2003. Part 1 "SQL/Framework", ISO International Organization for Standardization / ANSI American National Standards Institute, September 2003
  • ANSI/ISO/IEC 9075-2:2003. Part 2 "SQL/Foundation", ISO International Organization for Standardization / ANSI American National Standards Institute, Dezember 2003
  • Elmasri, Ramez/Navathe, Shamkant B.: "Grundlagen von Datenbanksystemen" , Pearson Studium, München, 2002, ISBN 3-8273-7021-3
  • Faeskorn-Woyke, Heide/Bertelsmeier, Birgit/Riemer, Petra/Bauer, Elena: "Datenbanksysteme - Theorie und Praxis mit SQL2003, Oracle und MySQL", Pearson Education, München, 2007, ISBN 978-3-8273-7266-6
  • Kemper, Alfons/Eickler, André: "Datenbanksysteme", Oldenbourg, München, 2009, 978-3-486-59018-0
  • Melton, Jim/Simon, Alan R.: "SQL: 1999 - Understanding Relational Language Components", Morgan Kaufmann, San Francisco, 2001, ISBN 1558604561
  • Oracle® Database SQL Language Reference 11g Release 2 (11.2), E17118-03, August 2010, http://download.oracle.com/docs/cd/E11882_01/server.112/e17118.pdf
  • Saake, Gunter/Sattler, Kai-Uwe/Heuer, Andreas: "Datenbanken - Konzepte und Sprachen", mitp-Verlag, Redline GmbH, Heidelberg, 2007, ISBN 3-8266-1664-2
  • Vossen, Gottfried: "Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme", Oldenbourg, München, 2008, ISBN 978-3-486-27574-2

Kategorie Aktive Datenbanken, SQL, A