Nächste Seite: Änderungsnotifikation für Anwendungsprogramme Vorige Seite: 5.2.2 Auswertung der Sichtenwartungsregeln

5.2.3 Besonderheiten der Sichtenwartung in ConceptBase

In Kapitel 5.1 wurde die Übersetzung der Sichtendefinition in Datalog-Regeln und -Algebra beschrieben. Der Sichtenwartungsalgorithmus berechnet die Änderungen mit Hilfe der Datalog-Regeln, der -Ausdruck der Sicht wird dabei nicht berücksichtigt. Die Joinbedingungen zwischen den Teilanfragen müssen bei der Sichtenwartung berücksichtigt werden, wie das nachfolgende Beispiel zeigt.

Die Sicht aus Beispiel 5.1.1 wurde wie folgt in Datalog übersetzt:

EmpDept(_e) :- 
    In(_e,Employee).
EmpDept_dept(_e,_d) :- 
    In(_e,Employee), SV_dept(_d), A(_e,dept,_d).

SV_dept(_d) :- 
    In(_d,Department).
SV_dept_head(_d,_h) :-
    In(_d,Department), In(_h,Manager), A(_d,head,_h).

Wenn eine neue Abteilung D1 eingefügt wird, so folgt daraus eine Einfügung in der Teilanfrage SV_dept. Die Abteilung D1 ist aber nur dann Bestandteil der Sicht, wenn es auch einen Angestellten gibt, der in dieser Abteilung arbeitet. Dies wurde bei der Berechnung der Sicht durch den Join zwischen EmpDept_dept und SV_dept ausgedrückt.

Für eine korrekte Änderungsnotifikation ist also noch eine Filterung von für die komplexe Sicht irrelevanten Änderungen der intensionalen Prädikate notwendig. Die inkrementelle Propagierung der Änderungen in einem komplexen -Term ist nicht möglich, da dort Änderungen nicht eindeutig angegeben werden können. Für die Änderungsnotifikation von Anwendungsprogrammen ist dies auch nicht nötig. Daher beziehen sich die Änderungsnachrichten immer auf genau eine Beziehung, z.B. daßein Objekt in einer Sicht oder Teilanfrage enthalten ist, oder daßein Objekt ein bestimmtes Attribut hat. Aus diesem Grunde können die Joins auf der Ebene der Datalog-Regeln durchgeführt werden. Für die zusätzlichen Regeln müssen auch nach dem obigen Algorithmus Sichtenwartungsregeln generiert werden.

  Für die Sicht EmpDept müssen folgende zusätzliche Regeln generiert werden, die Joins zwischen den einzelnen Teilanfragen beschreiben.

vm_EmpDept(_e) :-
    EmpDept(_e).    
vm_EmpDept_dept(_e,_d) :-
    EmpDept_dept(_e,_d), vm_EmpDept(_e)

vm_SV_dept(_d) :-
    SV_dept(_d), vm_EmpDept_dept(_e,_d).
vm_SV_dept_head(_d,_h) :-
    SV_dept_head(_d,_h), vm_SV_dept(_d).

Bei der ersten Regel beginnt der Join mit der Teilanfrage EmpDept. In den anderen Regeln wird jeweils das Ergebnis des vorgehenden Joins benutzt.

Wird in den Datenbankzustand aus Beispiel 5.1.2 das Fakt A(Mary,dept,Marketing) eingefügt, so ergeben sich folgende Einfügungen für die Sichten:

EmpDept_dept(Mary,Marketing),  vm_EmpDept_dept(Mary,Marketing),
vm_SV_dept(Marketing).

Für die Änderungsnotifikation sind nur die Regeln mit dem Präfix vm interessant, da diese die tatsächlichen Änderungen beschreiben. Als Änderungsnachrichten werden die Terme plus(EmpDept_dept(Mary,MarysDept,Marketing)) und plus(SV_dept( Marketing)) verschickt, d.h. Mary arbeitet in der Abteilung Marketing, und Marke- ting ist ein neues Objekt der Teilanfrage SV_dept. Der Funktor plus bezeichnet bei diesen Änderungstermen Einfügungen in die Sicht, der Funktor minus bezeichnet die Löschungen, analog zu den Bezeichnungen bei den Sichtenwartungsregeln.

Die Propagierung der Änderungen läuft also in mehreren Stufen ab. Zunächst berechnet der Algorithmus aus Abschnitt 5.2 die Änderungen der intensionalen Datenbank. Anschließend werden die für eine Sicht relevanten Änderungen aus diesem Ergebnis herausgefiltert. Schließlich müssen die Änderungen in Terme umgewandelt werden, die die Änderungen eindeutig beschreiben und die das Anwendungsprogramm für die Umsetzung auf seinen Datenstrukturen auswerten kann.

Ein weiteres Problem bei der Realisierung in ConceptBase sind eindeutige Objektnamen für Objekte, die Element einer Teilanfrage mit Parametern sind. Eindeutige Objektnamen sind vor allem für die Darstellung der Sicht im Anwendungsprogramm wichtig. Wenn eine Teilanfrage auch Parameter hat, müssen die Belegungen der Parameter in den Objektnamen enthalten sein. Die Parameter stellen also ein Teil des Objektnamens dar. Dies ist nötig, weil in der Teilanfrage der Parameter referenziert wird und somit eine direkte Beziehung zum Objekt der Teilanfrage hat.

  Dieses Problem wird an der folgenden Sicht deutlich:

View EmpDept_salary isA Employee
  retrieved_attribute,partof,necessary
    dept : Department with
      computed_attribute
        empsal : Integer
      constraint
        c: $ A(this,salary,empsal) $
    end
end

Da this in der Teilanfrage referenziert wird, wird diese Sicht in eine Hauptanfrage und eine Teilanfrage mit Parameter übersetzt. Das Attribut empsal der Teilanfrage hängt direkt von dem Parameter ab. Wenn es zwei Angestellte John und Bill gibt, die beide in der Abteilung Production und 10000 bzw. 15000 verdienen, dann sieht die Antwort für die Sicht wie folgt aus:

John in EmpDept_salary with
  dept
    JohnsDept : Production with
      empsal 
        : 10000
end

Bill in EmpDept_salary with
  dept
    BillsDept : Production with
      empsal 
        : 15000
end

Die Abteilung Production hat also für die beiden Angestellten unterschiedliche Attribute und stellt somit auch zwei verschiedene Objekte dar. Die Objektnamen der Teilanfrage sind Production[John/this_par] und Production[Bill/this_par], wobei this_par der generierte Parameter der Teilanfrage ist. Objektnamen dieser Form werden auch Ableitungsausdrücke genannt.

Da die Parameter im Kopf einer Regel als Variable auftauchen, werden unterschiedliche Belegungen der Parameter auch bei der Sichtenwartung beachtet.