Die Sichtenwartung bietet eine Möglichkeit Änderungen der intensionalen Datenbank auf eine effiziente Art und Weise zu berechnen. Neben der Verwendung für die Änderungsnotifikation können die Ergebnisse der Sichtenwartung auch innerhalb der Datenbank genutzt werden. So sind Änderungen des Datenbankzustandes auch für die Integritätskontrolle, für die Verwaltung von Inkonsistenzen [Bau96] und die Wartung intern materialisierter Sichten relevant.
Der Notifikationsmechanismus ist nicht auf die Verwendung bei der Sichtenwartung beschränkt. Für die in [Lash96] vorgestellten aktiven Regeln für ConceptBase wäre eine Notifikationsaktion eine interessante Erweiterung. Anwendungsprogramme könnten dadurch nicht nur über Sichtenänderungen benachrichtigt werden, sondern über beliebige Ereignisse.
Des weiteren sind unterschiedliche Wartungsstrategien vorstellbar. Zur Zeit versendet das Datenbanksystem sofort die Änderungsnachrichten an das Anwendungsprogramm. Im Bereich der verteilten Systeme erfolgt eine Abgleichung des Datenbestandes oft nicht immer direkt, sondern verzögert, d.h. die Änderungen werden über einen Zeitraum gesammelt und dann in einem Block an die anderen Systeme weitergeleitet. Außerdem könnten die Sichten analysiert werden, ob für sie überhaupt eine effiziente inkrementelle Sichtenwartung möglich ist. In diesem Zusammenhang sollte vor Beginn der Sichtenwartung auch eine Analyse der Änderungen stattfinden. Bei einen großen Anzahl von Änderungen ist eine Neuberechnung der Sicht gegenüber der inkrementellen Wartung günstiger. Ein Anwendungsprogramm könnte außerdem nicht an den Änderungen der Sicht interessiert sein, weil es nur einen Snapshot der Datenbank betrachten will.
Für den einfachen Entwurf von Sichten wäre ein Programm vorstellbar, daßden Entwickler bei der Definition der Sicht unterstützt. In einem interaktiven Programm mit graphischer Benutzeroberfläche bestimmt der Entwickler die Struktur der Sicht durch die Auswahl von bestimmten Klassen und Attributen. Das Programm API Designer könnte in diese Umgebung integriert werden.
Um nicht eine Vielzahl von Sichten mit gleicher Struktur, die jeweils andere Nebenbedingungen haben, definieren zu müssen, sollte die Selektion von Teilmengen einer Sicht möglich sein. Eine Teilsicht wird durch eine Funktion bestimmt, die die Objekte einer Sicht anhand einer Nebenbedingung auswählt. Diese Funktion würde nur im Anwendungsprogramm ausgewertet und greift nicht auf die Datenbank zu.
In dieser Diplomarbeit wurde C++ als Anwendungsprogrammiersprache ausgewählt. Da sich die Kommunikation zwischen Client und Server auf den Austausch von Termen beschränkt, die als einfache Zeichenketten dargestellt werden, ist eine Übertragung auf andere objekt-orientierte Programmiersprachen, wie z.B. Java oder Smalltalk, leicht möglich. Für die Erzeugung der Datenstrukturen für eine Sicht müssen im Code-Generator lediglich weitere Schablonen erstellt werden. Des weiteren ist auch eine Übertragung der Basisklassen auf die neue Programmiersprache erforderlich.
Ein weiterer Aspekt ist das View-Update-Problem, d.h. die Übertragung der Änderungen in den Sichten auf Basisdatenänderungen. Ein Teil der dabei auftretenden Probleme könnten bereits in der Programmierschnittstelle gelöst werden. Der Programmierer entscheidet, wie eine Änderung an einem Objekt im Anwendungsprogramm auf die Datenbank abgebildet wird. Das Datenbanksystem würde dafür eine ähnliche Unterstützung wie bei der Generierung der C++-Klassen und Änderungsmethoden bereitstellen.
Christoph Quix