Views und temporäre Tabellen

In Datenbanksystemen unterscheidet man die folgenden drei Ebenen:

1.

In der physischen Ebene ist festgelegt, wie die Daten physisch gespeichert sind und welche Zugriffsrechte bestehen. Dabei spielen der Datentyp und die Länge eines Attributs, der Aufbau der gespeicherten Datensätze, und Indexorganisation eine wichtige Rolle. Die Effizienz der physischen Ebene bestimmt maßgeblich das Leistungsverhalten des DBMS.

2.

In der logischen Ebene wird in einem Datenbankschema festgelegt, welche Daten gespeichert sind. Dadurch werden die Objekt- und Beziehungstypen sowie der Wertevorart beschrieben. Die Daten und Beziehungen werden dabei unabhängig von der tatsächlichen Speicherung betrachtet.

3.

Die Sichten stellen Teilmengen der Informationen bereit. Sie sind auf die Bedürfnisse der jeweiligen Benutzer bzw. Benutzergruppen abgestimmt. Insbesondere soll kein Benutzer Daten sehen, die er nicht sehen will (Übersichtlichkeit) oder nicht sehen darf (Datenschutz). [Skript Kriegel DBS I, Kemper/Eickler Datenbanksysteme]

Auch für die Datenbank der Workflow-Anwendung können verschiedene Benutzer bzw. Benutzergruppen identifiziert werden. Neben den Mitarbeitern des Lehrstuhls sollen auch Studenten und Tutoren auf die Datenbank zugreifen dürfen. Während den Mitarbeitern eine uneingeschränkte Sicht auf die Daten gewährt werden kann, sollen die anderen Benutzergruppen nur eine notwendige Teilmenge der Daten sehen. Für einen Tutor könnte man beispielsweise einen View auf einzelne Datentupel der Relation 'student_erhaelt_punkte' einrichten. Dies sollten nur Datentupel sein, die sich auf eine Aufgabe eines Übungsblatts oder einer Klausur beziehen, die der Tutor zu korrigieren hat. Schlecht wäre es, wenn der Tutor auch auf Klausuraufgaben Zugriff hätte, die er selber geschrieben hat.

Ein View wird in SQL mit Hilfe des Befehls 'CREATE VIEW <viewname> AS' erzeugt. Dabei ist an das Schlüsselwort 'AS' eine SELECT-Anfrage anzuhängen, die die Daten des Views definiert. Neben der Erzeugung des Views muss die Benutzung desselben für einen Benutzer autorisiert werden. Dazu dient das GRANT-Kommando. Mit diesem Kommando wird außerdem festgelegt, welche Zugriffsmöglichkeiten dem Benutzer gewährt werden sollen. Die üblichen Standardprivilegien sind SELECT, INSERT, UPDATE, DELETE und REFERENCES. Mit dem REFERENCES-Privileg erhält man die Möglichkeit Fremdschlüssel zu referenzieren.

Die getesteten DBMS MySQL, PostgreSQL und Interbase unterstützen Views nur teilweise oder gar nicht:

• MySQL kennt das Konzept der Views in der vorliegenden Version nicht. In der Dokumentation zu MySQL wird als gleichwertiges Konzept die Verwendung temporärer Tabellen vorgeschlagen. Im Gegensatz zu Views stellen temporäre Tabellen jedoch keine Sicht auf die DB dar, sondern sind eigenständige Objekte, die zusätzlich zu den Objekten und Beziehungen des eigentlichen Datenbankschemas existieren. Die Daten in den temporären Tabellen sind nur immer so aktuell, wie sie zum Zeitpunkt des Erzeugens der temporären Tabelle oder des letzten Abgleichs waren. Werden Datenmanipulationen vorgenommen, müssen diese manuell mit den übrigen Daten abgeglichen werden. Die Datenbank ist so zwischen zwei Abgleichungen nicht konsistent, unter Umständen können Konflikte entstehen. Außerdem bedeutet das manuelle Abgleichen, dass der damit verbundene Aufwand nicht vom DBMS, sondern von einem externen Skript erbracht werden muss.
• PostgreSQL unterstützt in der betrachteten Version Read-Only-Views. Das heißt, dass mit den Views keine Datenmanipulationen möglich sind. Ein Update hätte beispielsweise keine Auswirkungen auf die hinter dem View stehenden realen Datenbank-Objekte. Allerdings bietet PostgreSQL die Möglichkeit mit Hilfe so genannter ``Rules'' diese Beschränkung zu umgehen. Vom Prinzip sind Rules spezielle Trigger, die bei einer Datenmanipulation auf einem View aktiv werden und die entsprechende Datenmanipulationen auf den realen DB-Objekten durchführen. Diese Rules müssen allerdings vom Anwendungsentwickler einzeln eingerichtet werden.
• Am weitesten geht die Unterstützung von Views bei Interbase. Interbase richtet auch Write-Through-Views ein, sofern u. a. folgende Bedingungen erfüllt sind. Der View stellt eine Teilmenge einer einzigen Relation dar. Nicht eingeschlossene Attribute müssen NULL-Werte zulassen. Werden bei der Definition des Views hingegen Joins, Aggregationen oder Subqueries verwendet kann Interbase auch nur einen Read-Only-View einrichten. Da man in einer einigermaßen gut normalisierten Datenbank ohne Joins fast nicht auskommt, ist folglich die Write-Through-Unterstützung in der Praxis nicht benutzbar. Was bleibt ist wie bei PostgreSQL durch Trigger die Datenmanipulationen auf den realen DB-Objekten nachzuführen. Positiv ist anzumerken, dass Interbase bei Write-Through-Views auch die Option WITH CHECK unterstützt. Dadurch kann folgendes sichergestellt werden: Ein Datentupel kann nicht so abgeändert werden, dass es nicht mehr zur Definition des Views passt. Außerdem kann kein neues Datentupel erzeugt werden, das nicht zum View passt. Negativ ist noch anzumerken, dass Interbase Probleme bekommt, wenn bei der Definition des Views Alias-Namen verwendet werden.

Wir haben versucht mit den Funktionen in der Library 'lib-view-control.inc.php' die beschriebenen Probleme der DBMS mit Views abzumildern. Mit Hilfe der Funktion 'view_create' können Write-Through-Views erzeugt werden. Die Parameter der Funktion sind in Tabelle knapp dargestellt (genaueres und Informationen zu den anderen Funktionen siehe Quelltext). Bei Interbase und PostgreSQL werden dazu automatisch Trigger bzw. Rules generiert, im Falle MySQL wird versucht das View-Konzept mit temporären Tabellen nachzubilden. Bei der Definition des Views können auch Joins verwendet werden. Allerdings wird das Durchschreiben von Datenmanipulationen durch den View hindurch nur auf eine DB-Relation ermöglicht. Der Name dieser Relation muss der Funktion 'view_create' als Argument übergeben werden. Auch in unserem Konzept werden keine Aggregationen bzw. Gruppierungen unterstützt.

 

english Parameter german english Beschreibung german

english id german english String, mandatory. Die Views müssen für jeden Workflow eindeutige IDs erhalten. Die View-Namen selber werden von der Anwendung generiert. german

english query_array german english Array, mandatory. Der Aufbau entspricht der Beschreibung in Abschnitt 4.3.4. german

english tabelle german english String, mandatory. Auf diese Tabelle sollen die Datenmanipulationen durchgeschrieben werden. german

english user german english String. Durch Komma getrennte Liste von Benutzernamen. (Gruppen werden durch das Schlüsselwort GROUP gekennzeichnet.) Für diese Benutzer werden standardmäßig Zugriffsrechte auf den View vergeben german

english rechte german english String oder Array. Durch Komma getrennte Liste der Zugriffsrechte. Bei der Verwendung der Array-Versionen können Benutzernamen als Keys verwendet werden. Die Zugriffsrechte im Value werden dann diesem Benutzer gewährt. Bei der Verwendung der String-Version, werden die Rechte den Benutzern im Parameter 'user' zugewiesen. german

english view_name german english String. Der Viewname wird normalerweise von der Anwendung generiert. Wem dies nicht gefällt kann hier den Viewnamen vorgeben. Dabei ist allerdings darauf zu achten, dass der Name noch nicht vergeben ist. german

english req german english Array. Attribut-Werte-Paare. Key: Attributname, Value: Wert. Diese Werte werden bei der Erzeugung neuer Tupel durch den View grundsätzlich verwendet. german

Die Rules bzw. Trigger, die bei Postgres und Interbase für Datenmanipulationen auf Views notwendig sind, werden in 'lib-view-control.inc.php' automatisch angelegt. Dabei richtet sich die Library nach den Rechten, die für einen View gelten sollen. Wird beispielsweise einem Benutzer das Update-Recht auf einen View erteilt, erzeugt die Library einen geeigneten Update-Trigger. Gleiches gilt für Insert und Delete. Eine wichtige Rolle spielen dabei die Primärschlüssel-Attribute der Relation, auf die die Datenmanipulationen durchgeschrieben werden. Diese können über den View nicht mit einem Update geändert werden, da sonst der Zusammenhang zwischen dieser Relation und dem View nicht mehr einfach herzustellen ist. Bei Insert-Operationen berücksichtigt der entsprechende Trigger außerdem ein Attribut-Werte-Array, das der Funktion 'view_create' übergeben werden kann. Damit können Werte für bestimmte Attribute fest vorgegeben werden, die beim Erzeugen eines neuen Tupels auf jeden Fall verwendet werden.

Da MySQL keine Views kennt, haben wir versucht mit temporären Tabellen ein Ersatz zu schaffen, den wir Pseudoviews genannt haben. Dabei kann die gleiche Schnittstelle für die Pseudoviews verwendet werden, wie bei den echten Views. D. h. die Funktionen 'view_create', 'view_drop' etc. sind auch bei MySQL verwendbar. Wer ganz bewusst Pseudoviews erzeugen will, z. B. auch bei der Verwendung des DBMS PostgreSQL, kann die Funktionen 'pseudoview_create' etc. aufrufen. Der Nachteil der Pseudoviews ist, dass kein automatischer und sofortiger Abgleich mit der Relation stattfindet, auf die die Datenmanipulationen durchgeschrieben werden sollen. Dies muss ``manuell'' mit Hilfe der Funktion 'pseudoview_update' ausgelöst werden. Diese Funktion wird auf jeden Fall vor dem Löschen des Pseudoviews aufgerufen. Existiert ein Pseudoview längere Zeit, ist es unter Umständen sinnvoll, einen Cron-Job einzurichten, der die Updates in bestimmten Zeitintervallen erledigt.

Die Funktion 'pseudoview_update' unterstützt zwei Abgleich-Arten:

1.

Beim normalen Datenabgleich wird zunächst eine zweite temporäre Tabelle entsprechend der View-Definition erzeugt. Durch Vergleich der beiden temporären Tabellen kann dann festgestellt werden, welche Datenmanipulationen auf der ersten durchgeführt wurden. Diese Veränderungen werden dann nachgeführt auf die Relation, die für das Durchschreiben der Datenmanipulationen vorgesehen ist.

2.

Darüber hinaus hat man bei den Pseudoviews die Möglichkeit, bei der Definition des Views die Option WITH CHECK zu verwenden. Dadurch wird sichergestellt, dass alle Datenmanipulationen den Vorgaben der View-Definition genügen. Dazu wird in der ersten Phase zunächst eine Kopie der Relation erzeugt, auf die die Datenmanipulationen durchgeschrieben werden sollen. Der Abgleich findet dann wie beim normalen Abgleich auf dieser Kopie statt. In der zweiten Phase wird auf Basis der Kopie nocheinmal eine temporäre Tabelle erzeugt, die jetzt im Gegensatz zur ursprünglichen Pseudoview-Tabelle nur noch Tupel enthält, die der View-Definition entsprechen. Mit dieser neuen temporären Tabelle wird ein zweiter normaler Datenabgleich vorgenommen, diesmal jedoch auf der originalen Durchschreibe-Tabelle.

Wie bei den echten Views können auch bei den Pseudoviews die Primärschlüssel-Attribute der Durchschreibetabelle nicht geändert werden.