Nächste Seite: 4.2 Sichtenwartung in deduktiven Vorige Seite: 4.1.1 Sichtenwartung mit der

4.1.2 Sichtenwartung in Starburst

 

[CW91] generieren aus einer Sicht sogenannte Produktionsregeln (production rules) um Änderungen an einer materialisierten Sicht zu bearbeiten. Starburst ist ein aktives Datenbanksystem (vgl. Kapitel 3.3.2), das mit Produktionsregeln bei bestimmten Ereignissen oder Datenbankzuständen Datenmanipulationsoperationen ausführen kann. Hier werden die aktiven Regeln benutzt, um bei Einfüge- und Löschoperationen auf den Basisrelationen die materialisierten Sichten zu warten. Das Verfahren benutzt eine Teilmenge von SQL als Sichtendefinitionssprache. So sind zum Beispiel nur einfache Verschachtelungen von SELECT-Ausdrücken erlaubt. Die verschachtelten Anfragen können auch negiert werden.

Die Methode analysiert zunächst die Sichtendefinition und stellt fest, ob für diese Sicht eine effiziente Wartung für alle Änderungen an den Basisrelationen möglich ist und ob die Sicht Duplikate enthalten kann. Dabei werden auch die Schlüsselinformationen der Basisrelationen benötigt. Sollte die Analyse ergeben, daß Wartung nicht effizient möglich ist, so wird dem Benutzer das mitgeteilt und er kann anschließend die Definition der Sicht noch verfeinern. Falls es dann noch Basisrelationen gibt, deren Änderungen nicht inkrementell an die Sicht weitergegeben werden können, wird die Sicht bei Änderungen an diesen Relationen komplett neu berechnet.

Sichten, die Duplikate enthalten können, sind ebenfalls nicht erlaubt, da die delete-Operation in SQL nicht einen Teil der Duplikate löschen kann. Dieses Problem kann man dadurch umgehen, indem man für jede Basisrelation ein Schlüsselattribut in die Sicht mit aufnimmt. Die Änderungen der materialisierten Sicht werden analog zu [Han87] berechnet. Wenn verschachtelte Anfragen negiert vorkommen, so führen Löschungen in den Unteranfragen zu Einfügungen in der Sicht und umgekehrt.

Die Sicht EmpDept soll die Angestellten mit ihren Abteilungen und deren Vorgesetzten enthalten.

define view EmpDept(name,dept,head):
    select Employee.name, Employee.dept, Department.head
    from Employee, Department
    where Employee.dept = Department.name

Die folgenden Produktionsregeln beschreiben die erforderlichen Aktionen, wenn in der Relation Employee neuer Werte eingefügt bzw. gelöscht werden. old Employee bezeichnet dabei den Zustand der Relation Employee vor der Änderung, inserted (deleted) Employee enthält nur die eingefügten (gelöschten) Tupel und Employee steht für die aktuelle Relation, also einschließlich der Einfügungen und ohne die gelöschten Tupel.

create rule ins-Employee-EmpDept
when inserted into Employee
then insert into EmpDept
    select Employee.name, Employee.dept, Department.head
    from inserted Employee, Department
    where Employee.dept = Department.name
          and <name,dept,head> not in inserted EmpDept

create rule del-Employee-EmpDept
when deleted from Employee 
then delete from EmpDept
    where <name,dept,dept> in 
    select Employee.name, Employee.dept, Department.head
    from deleted Employee, old Department
    where Employee.dept = Department.name

Die erste Regel beschreibt den Fall für Einfügungen in die Relation Employee. Die Menge der eingefügten Angestellten wird mit der aktuellen Menge der Abteilungen per Join verbunden. Die Joinbedingungen sind gegenüber der Sichtendefinition unverändert. Der zweite Teil der WHERE-Klausel stellt sicher, daßdas gefundene Tupel nicht schon durch eine andere Regel in die Sicht eingefügt worden ist.

Die Löschungen von Employee werden durch die zweite Regel behandelt. Hier wird der Join zwischen der Menge der gelöschten Angestellten und der alten Menge der Abteilungen. Die Joinbedingung bleibt auch hier unverändert.

Wie schon erwähnt, wird eine Modifikation eines Tupels als Löschen und Einfügen modelliert. Die Regeln für ein Update der Relation Employee entsprechen also im wesentlichen den beiden oberen Regeln. Die Regeln für Änderungen bei der Relation Department sind analog.

Die Auswertungsreihenfolge der Regeln ist nicht beliebig: zunächst müssen alle Lösch-Regeln bearbeitet werden und dann alle Einfüge-Regeln. Allerdings gibt es keine vorgeschriebene Reihenfolge zwischen den Regeln von verschiedenen Sichten, so daß Sichten nur Basisrelationen referenzieren können, damit die Auswertung korrekt bleibt.