PDF file - IDB - Universität Bonn

Rheinische Friedrich-Wilhelms-Universität Bonn
Diplomarbeit
Inkrementelle Methoden zur Anpassung
materialisierter Sichten in relationalen
Datenbanken
von:
Matrikel-Nr.:
Adresse:
Roya Juki
1152042
Masurenweg 3
53119 Bonn
Erstgutachter:
Prof. Dr. Rainer Manthey
Abstract
Materialisierte Sichten spielen eine große Rolle in leistungsstarken Abfrageprozessen. Nach der initialen Erzeugung von materialisierten Sichten stellt sich die Frage, wie diese möglichst effizient bei
einer Änderung (Einfüge-, Lösch- oder Update-Operationen) der Basisdaten aktualisiert werden können. Da die komplette Neuberechnung bei großen Datenbanken meistens mit hohem Aufwand verbunden ist, wird eine inkrementelle Sichtenanpassung zur Aktualisierung der materialisierten Sichten
durchgeführt. Dabei sollen nur die Konsequenzen der aktuell geänderten Fakten der Basisrelationen
in den entsprechenden materialisierten Sichten aktualisiert werden. Viele Methoden sind zur Realisierung der inkrementellen Anpassung der materialisierten Sichten entwickelt worden. Alle Verfahren
aktualisieren die relationalen Sichten für die meisten üblichen Operationen. Bei jeder Methode werden bestimmte Sprachen wie z.B. SQL oder Datalog bevorzugt und auch spezielle Einschränkungen
und Erweiterungen der Sprachen vorausgesetzt. Ein Vergleich der verschiedenen Methoden zeigt,
dass Auswahl und Komplexität der materialisierten Sichten und auch die Größe der Datenbank einen
großen Einfluss auf die Effektivität ihrer inkrementellen Anpassung haben.
In dieser Arbeit sind einige Verfahren zur inkrementellen Anpassung von Sichten ausgewählt worden,
die auf den ersten Blick verschiedene Vorgehensweisen vorzeigen. Nach der Beschreibung der Methoden, werden sie unter bestimmten Kriterien verglichen. Es zeigt sich, dass die Verfahren trotz ihrer
unterschiedlichen Ablaufstrategien, auf einer einheitlichen Linie verlaufen und natürlich ein gemeinsames Ziel verfolgen.
1
2
Danksagung
Ein besonderer Dank geht an Herrn Prof. Dr. Manthey für seine unermüdliche, zuverlässige und
freundliche Betreuung. Erst durch sein Vertrauen in meine Person konnte ich diese Arbeit angehen
und zum Abschluss bringen.
Desweiteren möchte ich meiner Korrekturleserin und meinen Korrekturlesern danken für ihre hilfreichen Anmerkungen. Meinem Arbeitsgeber danke ich sehr für die flexiblen Arbeitszeiten während
meines Studiums und besonders während der Diplomarbeitsphase.
Schließlich danke ich meiner Familie herzlich für ihre seelische Unterstützung und ihre Geduld.
Inhaltsverzeichnis
Abstract
1
Danksagung
2
Inhaltsverzeichnis
5
Abbildungsverzeichnis
6
1
Einleitung
7
2
Grundlagen deduktiver Datenbanken
9
3
2.1
Deduktionsregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2
Fixpunktsemantik deduktiver Datenbanken . . . . . . . . . . . . . . . . . . . . . .
12
2.3
Sichtentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.4
Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.4.1
SQL-Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4.2
Starburst-Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Materialisierte Sichten
19
3.1
Auswahl und Anwendung materialisierter Sichten . . . . . . . . . . . . . . . . . . .
21
3.1.1
21
Das allgemeine Problem der Auswahl . . . . . . . . . . . . . . . . . . . . .
3
INHALTSVERZEICHNIS
3.1.2
3.2
3.3
Einsatzgebiete von materialisierten Sichten . . . . . . . . . . . . . . . . . .
22
Anpassung materialisierter Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.1
Techniken der Aktualisierung . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.2
Klassifizierung von Aktualisierungsalgorithmen . . . . . . . . . . . . . . . .
25
3.2.3
Ungeklärte Probleme bei der Sichtenanpassung . . . . . . . . . . . . . . . .
26
Inkrementelle Anpassung materialisierter Sichten . . . . . . . . . . . . . . . . . . .
26
3.3.1
Klassifikation des Sichtenanpassungproblems anhand von vier Dimensionen
27
3.3.2
Inkrementelle Sichtenanpassungsalgorithmen auf Basis der vollständigen Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
27
Ausgewählte Methoden zur inkrementellen Sichtenanpassung
30
4.1
Die GMS-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.1.1
Counting-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.1.2
Delete and Rederive-Algorithmus (DRed) . . . . . . . . . . . . . . . . . . .
42
Die CW-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.2.1
Syntax und Semantik der Produktionsregeln . . . . . . . . . . . . . . . . . .
46
4.2.2
Sicht-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.2.3
Regelgenerierung und Änderungspropagierung . . . . . . . . . . . . . . . .
50
4.2.4
Regelgenerierung in positiv verschachtelten Unterabfragen . . . . . . . . . .
55
Die Magic Updates-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.3.1
Ein Beispiel zur Änderungspropagierung . . . . . . . . . . . . . . . . . . .
62
4.3.2
Magic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.2
4.3
5
4
Vergleich der drei Methoden
71
5.1
71
Gemeinsames Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INHALTSVERZEICHNIS
5.2
5.3
6
5
Systematische Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.2.1
Regelgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.2.2
Änderungspropagierung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.2.3
Rekursion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.2.4
Negation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.2.5
Aggregatfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.2.6
Duplikatbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
5.2.7
Änderungen und Änderungsarten . . . . . . . . . . . . . . . . . . . . . . .
85
Beurteilung der Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
Zusammenfassung und Ausblick
89
Literatur
92
Eidesstattliche Erklärung
93
Abbildungsverzeichnis
3.1
Anwendung materialisierter Sichten in DWH . . . . . . . . . . . . . . . . . . . . .
23
3.2
Problemraum der inkrementellen Sichtenanpassung . . . . . . . . . . . . . . . . . .
27
3.3
Problemraum in 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.1
Struktur der GMS-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.2
Regel-Ableitung-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.3
Propagierungsverfahren bei der CW-Methode . . . . . . . . . . . . . . . . . . . . .
51
4.4
Regel-Compilierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.5
Struktur der Änderungspropagierung in der Magic Updates-Methode . . . . . . . . .
60
4.6
Struktur der Magic Updates-Methode . . . . . . . . . . . . . . . . . . . . . . . . .
67
4.7
Regelgenerierung in der Magic Updates-Methode . . . . . . . . . . . . . . . . . . .
68
5.1
Regelgenerierungen in den drei Methoden . . . . . . . . . . . . . . . . . . . . . . .
77
5.2
Mechanismen zur Faktenerzeugung . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6
Kapitel 1
Einleitung
Eine abgeleitete Relation (Sicht) kann in einer Datenbank materialisiert werden, d.h., die ableitbaren Fakten werden in explizit gespeicherter Form gehalten. Der Zugriff auf eine Sicht wird dadurch
erleichtert, z.B. ihre Verwendung zur Beantwortung einer Abfrage. Die Erzeugung dieser Art von
Sichten ist oft mit hohem Aufwand verbunden, d.h. mit hohen Kosten um Informationen in die Form
gespeicherter Relationen zu bringen. Diese Kosten sind nur einmal aufzubringen und werden sich
dann durch Effizienzgewinn bei jeder Abfrage ausgleichen. Außerdem ist immer eine Aktualisierung
der materialisierten Sichten erforderlich, wenn Änderungen an Basisdaten durchgeführt werden, von
denen die Sichten abgeleitet sind. Die Anwendung materialisierter Sichten ist in der Datenbankkommunikation sehr weit verbreitet. Besonders ihre Anwendung in Data Warehouse, Data Integration und
Replikation.
Eine Aktualisierung einer materialisierten Sicht kann in Form einer Neuberechnung erfolgen, in dem
die materialisierte Sicht bei der Auswertung des Abfrageausdrucks der Sichtendefinition in dem aktuellen Zustand der Datenbank rematerialisiert wird. Eine Neuberechnung ist meistens mit hohen
Kosten verbunden und daher unerwünscht. Also sollten nur die spezifischen Änderungen der Fakten
der Basisrelationen an den abgeleiteten Sichten angewendet werden. Diese Art von Aktualisierung
wird als inkrementelle Sichtenanpassung bezeichnet. In den letzten vier Jahrzehnten wurde ein breites Spektrum an verschiedenen Methoden mit unterschiedlichen Hilfsmitteln zur Aktualisierung von
materialisierten Sichten entwickelt. Ein großer Anteil dieser Verfahren ist für relationale Datenbanken
entwickelt worden (u.a. [CW91], [GMS93], [GL95]). Unabhängig davon, ob sie im Kontext von SQL
oder datalog-basiert entwickelt wurden, haben sie alle ein gemeinsames Ziel:
Die Grundidee dieser Verfahren ist, dass sie sich nur auf aktuell geänderte Fakten beziehen, und diese
inkrementell durch die betroffenen Regeln propagieren. Probleme, die in der Praxis deutlich werden, haben zur Arbeit auf diesem Gebiet motiviert. Bei der Implementierung der verschiedenen Ver7
1. Einleitung
8
fahren sind unterschiedliche Techniken zu Grunde gelegt, wie z.B. Präprozessoren (zur Analyse der
Abhängigkeit zwischen Sichten und Basisrelationen), Trigger, spezielle Algorithmen oder FixpunktIteration. Bei fast allen Verfahren sind bestimmte Einschränkungen, sowohl im Basissystem (z.B.
Starburst: [CW90]), als auch bei der Definition der Sichten vorausgesetzt worden, wie z.B. bei Ceri/Widom, die keine Rekursion und Aggregation zulassen.
Das zentrale Ziel dieser Arbeit liegt darin, einige repräsentative Verfahren zur materialisierten Sichtenanpassung durch gründliches Studieren und Klassifizieren der Methoden und detaillierte Erklärung
der Ansätze miteinander zu vergleichen. Dieser Arbeit liegt zugrunde
• eine ausführliche und klare Beschreibung der Anpassung der relationalen materialisierten
Sichten,
• die Darstellung der Vor- und Nachteile der ausgewählten Methoden,
• ein Vergleich der beschriebenen Strategien anhand von einheitlichen Kriterien als Basis ihrer
weiteren Anwendung wie auch zur Weiterentwicklung sowie als Basis der Implementation von
neuen Methoden zur Anpassung materialisierter Sichten.
In Kapitel 2 werden allgemeine theoretische Grundlagen im Gebiet deduktiver Datenbanken vorgestellt, insofern sie für das Verständnis der verwendeten Methoden erforderlich sind. Ein Überblick
über die Anwendung der materialisierten Sichten und eine erste allgemeine Definition des Anpassungsproblems, wird in Kapitel 3 gegeben.
In Kapitel 4 erfolgt eine Übersicht über die ausgewählten inkrementellen Strategien in relationalen
Datenbanken. Dabei werden diese Methoden nicht in ihrer Gesamtheit dargestellt, vielmehr werden
die zentralen Ideen vorgestellt und eine Interpretation der Methoden in einfacherer Weise, als es in
Literatur üblicherweise zu finden ist, versucht.
Den Kern dieser Arbeit bildet Kapitel 5, wo versucht wird, die vorgestellten Verfahren des vorherigen
Kapitels durch gemeinsame Beispiele in einheitlicher Sprache deutlicher darzustellen. Grundidee des
Kapitels ist es, Beurteilungkriterien zur Bewertung der verschiedenen Methoden bereitzustellen und
die Strategien in den Punkten, in denen gleiche Ergebnisse zu erwarten sind, zu vergleichen. Kapitel
6 gibt eine Zusammenfassung der Arbeit und einen Ausblick auf weitere Anstrengungen auf diesem
Gebiet.
Kapitel 2
Grundlagen deduktiver Datenbanken
Es existiert keine allgemeine, einheitliche Begriffsbestimmung für deduktive Datenbanken. In seiner
Vorlesung "Deduktive Datenbanken" definiert Prof. Manthey diesen Begriff wie folgt:
"Ein DBMS (für ein beliebiges Datenmodell) heißt "deduktiv", wenn es zusätzlich zu den üblichen
Funktionalitäten eines DBMS die Möglichkeit zur Spezifikation, Verwaltung und Anwendung von Sichten und Integritätsbedingungen bietet." [Man94]
In diesem Kapitel werden Grundlagen deduktiver relationaler Datenbanken zusammengestellt, soweit
sie im Kontext der Sichtenanpassung relevant sind.
Datenbankrelationen sind entweder Basisrelationen, die nur durch Fakten erzeugt werden, oder abgeleitete Relationen, die durch Regeln zustande kommen. Im relationalen Modell ist eine Relation eine
Menge gleichstrukturierter Tupel (Fakten). Jedes Tupel einer Relation ist eindeutig identifizierbar. In
SQL hingegen kann eine Relation Duplikate enthalten und stellt somit eine Multimenge dar. Diese
Eigenschaft ist leider ein großer Nachteil von SQL und führt dazu, dass die Ergebnisse von Anfragen
nichtdeterministisch sein können, je nachdem, ob Zwischenergebnisse Duplikate enthalten oder nicht.
Für eine Basisrelation wird in der Datenbank eine Relationsdefinition gespeichert. Dazu gehören u.a.
die Namen der Relation und der Attribute (Spalten). Für eine abgeleitete Relation (SQL: Sicht) wird
zudem die Ableitungsvorschrift (Deduktionsregel) in der Datenbank gespeichert. Die Fakten einer
abgeleiteten Relation werden anhand der Ableitungsvorschrift auf der Grundlage der jeweils vorliegenden Basisfakten ermittelt.
9
2. Grundlagen deduktiver Datenbanken
2.1
10
Deduktionsregeln
Eine deduktive Regel in Datalog ist ein Synonym für eine Sichtendefinition in SQL. Sichtdefinitionen
gehören zum DB-Schema; sie werden mittels der Data Definition Language (DDL) des jeweiligen
Datenmodells ausgedrückt (z.B. CREATE VIEW Kommando in SQL). Eine deduktive Regel ist prinzipiell wie folgt aufgebaut:
Regelkopf ←− Regelrumpf
Dabei ist der Regelkopf ein Muster für eine Informationseinheit einer ableitbaren Datenmenge und
der Regelrumpf eine definierende Anfrage. Deduktive Regeln sind - wie DB-Anfragen - deklarative
Ausdrücke. Im Prinzip kann jedes Datenmodell (auf der Basis der zugehörigen Anfragesprache) um
deduktive Regeln erweitert werden. Die Verwendung deduktiver Regeln hat viele Vorteile, sowohl bei
materialisierter, als auch bei virtueller Datenhaltung:
• deklarativ (selbstdokumentierend)
• flexibel (änderungsfreundlich)
• modulare Wissensdarstellung, inkrementell erstellbar
• einfache, effiziente Darstellung nützlicher Terminologie ohne redundante Datenhaltung
• Geschäftsregeln der Anwendung werden explizit gemacht
Sichten in SQL sind abgeleitete virtuelle Tabellen aus (mehreren) Relationen, die immer wieder neu
abgeleitet werden sollen, was ggf. zu Performanzproblemen führen kann. In manchen Fällen ist eine
direkte Änderung möglich. Eine Sicht kann wie eine Relation behandelt werden (Sichten auf Sichten
sind möglich). Sichten in SQL sind immer virtuell. Der SQL-Standard ist um das Konzept materialisierter Sichten erweitert worden. Allgemeine Sichten werden nicht materialisiert, sondern als Anfrageergebnis interpretiert, das dynamisch beim Zugriff generiert wird. Eine Sicht entspricht einem
dynamischen Fenster auf die zugrundeliegenden Basisrelationen, und Operationen, die auf Sichten
angewendet werden und durch (interne) Query-Umformulierung auf Basisrelationen abgebildet werden.
2. Grundlagen deduktiver Datenbanken
11
Definition: SQL-Sicht
Jeder Ausdruck der Form
V (A1 , . . . , An ) AS Q
ist eine SQL-Sicht. Hier ist S Sichtsymbol und A1 , . . . , An Attributsymbole (n ≥ 1). Q ist eine
SQL-Anfrage. Die Anzahl n der Attribute der Sicht muss identisch sein mit der Anzahl der Terme der
Ergebnisliste der Anfrage Q.
Die Zuordnung zwischen den Termen der Ergebnisliste der SQL-Anfrage Q und den Attributen der
Sicht erfolgt gemäß der in der Sichtdefinition spezifizierten Reihenfolge (positionelle Darstellung).
Parameterlose Sichten sind anders als in Datalog nicht formulierbar. Eine solche Sichtspezifikation
stellt in SQL keinen eigenständigen Befehl dar. Sie kann zur Spezifikation einer Hilfssicht in der
WITH-Klausel eines Anfrageausdrucks verwendet werden. Zudem kann eine virtuelle Sicht mittels
des DDL-Befehls CREATE VIEW als persistentes Schemaobjekt in einem DB-System definiert werden:
CREATE [RECURSIVE] VIEW V (A1 , . . . , An ) AS Q
Die RECURSIVE-Option muss nur für rekursive Sichten spezifiziert werden. Rekursive Sichten können in SQL sowohl als persistente wie auch als Hilfssichten definiert werden. Die Verankerung der
Rekursion muss mittels UNION-Operator in mindestens einer der beteiligten Sichten definiert werden. Mengenoperatoren, die nicht der Verankerung dienen, sind nicht zugelassen.
Rekursive Sichten
Spezifikation der transitiven Hülle p einer Relation r:
1. Datalog:
p(X, Y ) ←− r(X, Y ) -Verankerung
p(X, Y ) ←− r(X, Z) ∧ p(Z, Y ) -lineare Rekursion
2. SQL mit rekursiver Sicht p
p(a1 , a2 ) AS SELECT tr .a1 , tr .a2 FROM r AS tr
UNION SELECT tr .a1 , tp .a2
-lineare Rekursion
FROM r AS tr , p AS tp WHERE tp .a2 = tr .a1
-Verankerung
2. Grundlagen deduktiver Datenbanken
12
3. SQL mit rekursiven Hilfsichten:
p(a1 , a2 ) AS WITH RECURSIVE h(a1 , a2 ) AS
SELECT tr .a1 , tr .a2 FROM r AS tr UNION
SELECT tr .a1 , th .a2 FROM r AS tr , h AS th WHERE th .a2 = tr .a1
SELECT th .a1 , th .a2 FROM h AS th
In SQL sind ausschließlich linear rekursive Sichten zugelassen.
Nichtlineare Rekursion in Datalog
p(X, Y ) ←− r(X, Y ) -Verankerung
p(X, Y ) ←− p(X, Z) ∧ p(Z, Y )
2.2
Fixpunktsemantik deduktiver Datenbanken
Ableitungsregeln bedeuten nur etwas relativ zu einer gegebenen Faktenmenge F . Als Semantik kann
man dann die Menge aller aus dieser Basismenge mittels R herleitbaren Fakten ansehen, die als F ∗
bezeichnet wird. Dabei ist F ∗ als der kleinste Fixpunkt einer bestimmten Funktion, die jeder Regel
zugeordnet wird, definierbar. Die Fixpunktiteration ist ein konstruktiver Weg, ein Modell zu finden.
Das Konzept des Fixpunkts stammt aus der Funktionentheorie und wurde Mitte des 20. Jhs. besonders
von dem russischen Logiker Tarski untersucht.
Fixpunktiteration stellt eine spezielle Form von Grenzwertbildung dar und kann zur konstruktiven
Definition der Semantik einer deduktiven DB genutzt werden:
F ∗ =def lim T ∗ [R]i (F )
i→∞
T ∗ [R] wird als kumulative Ableitungsfunktion bezeichnet, die ihre erzielten Zwischenergebnisse aufsammelt bzw. kumuliert. T ∗ [R] isr erforderlich um mehrstufige Ableitungen zu charakterisieren, denn
die Anzahl der erforderlichen TR∗ -Schritte ist von R und F abhängig. T ∗ [Ri ] hat eine rein deklarative
Bedeutung, die hier beispielhaft für eine Regel R1 : p(X) ← s(X, Y ), q(Y ) illustriert werden soll:
T ∗ [R1 ](F ) =def {p(X)σ|σ ist eine konsistente Variablensubstitution, so dass s(X, Y )σ ∈ F und
q(Y )σ ∈ F gilt} ∪ F
Für F = {s(1, 2), s(1, 3), s(2, 4), q(3), q(4)} ergibt sich T ∗ [R1 ] = {p(1), p(2)} ∪ F .
2. Grundlagen deduktiver Datenbanken
13
Jetzt betrachten wir zwei Regeln, um kumulative Ableitungen zu berechnen:
R : p(X) ← s(X, Y ), r(Y )
r(Y ) ← q(Y )
F = {s(1, 2), s(1, 3), s(2, 3), q(3)}
T ∗ [R]1 (F ) = {s(1, 2), r(3), r(3), s(1, 3), s(2, 3), q(3)}
T ∗ [R]2 (F ) = {s(1, 2), r(3), s(1, 3), s(2, 3), p(1), p(1), p(2), p(2), q(3)}
Es kann verschiedene Fixpunkte geben, u.U. sogar unendlich viele pro Funktion. Ist ein Fixpunkt bezüglich einer bestimmten Ordnung auf den Eingaben minimal, nennt man ihn minimalen Fixpunkt.
Ein Fixpunkt ist minimal, wenn kein anderer Fixpunkt echt in ihm enthalten ist. Das durch Fixpunktiteration gewonnene F ∗ von (F ,R) ist der einzige, eindeutige minimale Fixpunkt von T ∗ [R], der F
ganz enthält.
Ein Abhängigkeitsgraph stellt die Beziehungen zwischen den Prädikaten einer deduktiven Datenbank dar. Prädikate im Graph stellen die Knoten dar. Eine Kante a → b wird dann genau eingefügt,
wenn eine Regel der Form b : − . . . a . . . existiert. Ist der Graph zyklisch, ist die Datenbank rekursiv.
Prädikate, die im Abhängigkeitsgraph selbsterreichbar sind, heißen rekursiv.
Eine Stratifikation einer Regelmenge R ist eine Unterteilung von R in Schichten, so dass Relationen
in derselben Schicht nicht negativ voneinander abhängen. Stratifikation ist eine eindeutige Funktion
der Form:
λ : RelD → N0
Jeder Relationsname (RelD ) wird eine natürliche Zahl zugeordnet, so dass gilt:
• Wenn p ∈ RelD positiv von q ∈ RelD abhängt, dann ist λ(p) ≥ λ(q)
• Wenn p negativ von q abhängt, dann ist λ(p) > λ(q)
Eine deduktive Datenbank D heißt stratifizierbar, wenn mindestens eine Stratifikation von RelD existiert.
Die Stratifikation kann zur Darstellung des Prinzips der iterierten Fixpunktberechnung verwendet
werden. Die Semantik einer stratifizierbaren Regelmenge R bezüglich einer Faktenmenge F kann
nun formal definiert werden:
2. Grundlagen deduktiver Datenbanken
14
Der kleinste Fixpunkt einer Funktion f , der das Argument M enthält, wird mit lfp(f, M )1 bezeichnet.
Die schichtenweise Abarbeitung der Regelmenge durch lokale Fixpunktiterationen lässt sich dann wie
folgt formalisieren:
Sei eine Stratifikation von (R, F ) mit Schichten {R#1, ..., R#k} gegeben.
F0 =def F
Fi =def lf p(Tneg ∗ [R#i], Fi−1 ) 1 ≤ i ≤ k
Die Bedeutung F ∗ von (R, F ) ist dann definiert als das Resultat der lokalen Fixpunktberechnung auf
dem höchsten Stratum:
F ∗ =def Fk
F ∗ wird den iterierten Fixpunkt von Tneg ∗ [R] bzgl. F genannt.
2.3
Sichtentypen
• SP-Sichten (Select-Project, horizontale Sichten):
ermöglichen die Zugriffsbeschränkung eines Benutzers auf ausgewählte Tupel einer Relation.
Eine solche Sicht wird als horizontal bezeichnet, da sie eine Relation horizontal - also zwischen
ihren Tupeln - aufteilt.
• SPJ-Sichten (Select-Project-Join, vertikale Sichten):
ermöglichen die Zugriffsbeschränkung eines Benutzers auf ausgewählte Attribute einer Relation. Eine solche Sicht wird als vertikal bezeichnet, da sie eine Relation vertikal - also entlang
ihrer Attribute - aufteilt.
• Aggregate + Join-Sichten (Gruppen- und Verbundsichten):
Eine komplexere Art von Sichten mit deren Hilfe mehrere Relationen miteinander zu einer
sogenannten Verbundsicht (engl. join) kombiniert werden und in der Tupel mit der group-byKlausel gruppiert werden, um darauf Aggregatfunktionen anzuwenden.
Wir wissen, dass eine Sicht für eine Datenbank sinnvoll ist, um logische Unabhängigkeit vom konzeptionellen Schema zu erhalten und um die Struktur der Datenbank an die individuellen Anforderungen
einzelner Benutzer anpassen zu können. Darüber hinaus gibt es aber eine Vielzahl weiterer interessanter Anwendungsgebiete für Sichten. Diese sind für konventionelle Datenbanken aus mehreren
Gründen sehr nutzlich.
1
lfp ist eine Abkürzung für least fix point
2. Grundlagen deduktiver Datenbanken
15
• Schema-Entwurf durch Sichtenintegration: Eine Möglichkeit das konzeptionelle Schema einer Datenbank bottom up zu entwickeln. Die Anforderungen an die Datenbank werden für alle
Benutzergruppen getrennt als Sichten entwickelt. Durch Zusammenfügen dieser Sichten und
Eliminierung möglicher Konflikte zwischen ihnen kann das Gesamtschema hergeleitet werden.
• Datenbank-Integration: Daten können aus einer Datenbank in eine andere exportiert werden,
indem die unterschiedlichen Schemata der beteiligten Datenbanken mit Hilfe von Sichten auf
ein gemeinsames (Teil-)Schema abgebildet werden, über das dann die Daten ausgetauscht werden können.
• Anpassung des Datenmodells: Sichten können genutzt werden, um auf eine Datenbank mit
einem anderen Datenmodell zuzugreifen. So können etwa Objekt-Sichten auf relationale Datenbanken (was grob gesagt das Prinzip objektrelationaler Datenbanken ist) oder relationale
Sichten auf objektorientierte Datenbanken definiert werden.
• Visualisierungssysteme: Bei der Visualisierung von Daten einer Datenbank tritt dasselbe Problem auf, wie bei materialisierten Sichten. Ein Visualisierungssystem sollte stets den aktuellen
Datenstand repräsentieren, daher muss es bei Änderungen an den Daten entsprechend aktualisiert werden. Dies entspricht dem Sichtenanpassungsproblem.
2.4
Trigger
Für Triggersysteme hat sich bislang kein einheitliches und allgemein anerkanntes Konzept durchgesetzt. Eine über die Grundlagen hinausgehende ausführliche Beschreibung und Klassifizierung verschiedener aktiver Regel-Systeme sind u.a. in [Gri97], [CW96], [HW93] zu finden. Einsatzmöglichkeiten für aktive Regeln werden in [CCW00] gegeben. Als ein klassisches Aufgabengebiet sehen Ceri
et.al. die prototypische Implementierung systemgenerierter Trigger zur Unterstützung von Kernfunktionen des DB-Systems, wie z.B. materialisierten Sichten.
Grundlegende Eigenschaft eines Triggers ist, dass seine Aktionen automatisch ausgeführt werden,
wenn ein bestimmtes Ereignis eintritt (Event/Action-Paradigma). Die Triggerkomponente als Bestandteil des DB-Systems erkennt das Auftreten eines Ereignisses im Sinne des Regelkonzepts (Datenmanipulationen, Zeitpunkte, abstrakte Ereignisse etc.) und ermittelt die von diesem Ereignis betroffenen Trigger. Zu einem bestimmten Zeitpunkt (unmittelbar, verzögert) werden die Aktionen des
Triggers (Anfragen, Änderungsanweisungen, Transaktionssteuerung (COMMIT), Prozeduraufrufe,
Erzeugen abstrakter Ereignisse) ausgeführt.
2. Grundlagen deduktiver Datenbanken
16
Bei Triggerkonzepten, die dem ECA-Paradigma (Event/Condition/Action) genügen, können für Trigger Bedingungen (Condition) definiert werden, die zum Zeitpunkt der Aktivierung bzw. Ausführung
angewendet werden. Ist die Bedingung nicht erfüllt, so wird der Trigger nicht ausgeführt. Eine weitere
sehr wesentliche Eigenschaft ist die Granularität der Regelausführung. Wird für eine Änderungsanweisung unabhängig davon, wie viele Fakten manipuliert werden, ein Trigger nur einmal gefeuert, so
wird die Regelausführung mengenorientiert bezeichnet. Feuert ein Trigger hingegen für jedes geänderte Fakt, so wird sie als instanzorientiert bezeichnet.
Es gibt zahlreiche Einsatzmöglichkeiten für Trigger. Nachfolgend werden einige der Wichtigsten davon aufgelistet:
• Überwachung nahezu aller Integritätsbedingungen, inkl. dynamischer Integritätsbedingungen
• Validierung von Eingabedaten
• Automatische Erzeugung von Werten für einen neu eingefügten Datensatz
• Wartung replizierter Datenbestände
• Protokollieren von Änderungsbefehlen (Audit Trail)
2.4.1
SQL-Trigger
Trigger sind ausführbare, benannte DB-Objekte, die implizit durch bestimmte Ereignisse (triggering
events) aufgerufen werden können. Die Triggerspezifikation besteht aus dem auslösendem Ereignis,
Ausführungszeitpunkt, optionalen Zusatzbedingungen und Aktion(en).
Syntax von SQL-Triggern
CREATE TRIGGER <trigger name>
{BEFORE | AFTER}{INSERT | DELETE | UPDATE [ OF <column> ]}
ON <table name>
[ORDER <order value>]
[REFERENCING <old or new alias list>]
[FOR EACH {ROW | STATEMENT}]
[WHEN (<search condition>)] <triggered SQL statement>
2. Grundlagen deduktiver Datenbanken
17
<old or new alias> ::= OLD [AS] <old values correlation name> |
NEW [AS] <new values correlation name> |
OLD-TABLE [AS] <old values table alias> |
NEW-TABLE [AS] <new values table alias>
Ein Beispiel für SQL-Trigger
CREATE TRIGGER Gehaltstest
AFTER UPDATE OF Gehalt ON Pers
REFERENCING OLD AS AltesGehalt, NEW AS NeuesGehalt
WHEN (NeuesGehalt < AltesGehalt)
ROLLBACK;
Der Trigger Gehaltstest wird ausgelöst, wenn in der Tabelle Pers Änderungen in der Spalte Gehalt
vorkommen, allerdings mit der Bedingung, dass der neue Eintrag kleiner als der alte Eintrag in der
Tabelle ist.
2.4.2
Starburst-Trigger
Starburst war ein Forschungsprojekt am IBM Almaden Research Center, in dessen Rahmen prototypische Funktionen für SQL-basierte DB-Systeme entwickelt wurden. Eine von IBM entwickelte DBSKomponente ist die Triggerkomponente ’Starburst Rule System’ [CW90], [CW91], [CW94], [Gri97].
In den verschiedenen Publikationen sind aufgabenspezifisch unterschiedliche Varianten des Triggerkonzepts definiert. Die Starburst-Trigger werden nur insoweit vorgestellt, wie sie von Ceri/Widom zur
Implementierung inkrementeller Verfahren in [CW91] verwendet werden.
Definition: Starburst-Trigger
Ein Starburst-Trigger ist eine ECA-Regel der Form:
G WHEN E1 , ..., En
[ IF F ] THEN M1 , ..., Mn PRECEDES G1 , ..., Gm
wobei G, G1 , ..., Gm Triggersymbole sind. Ei (1 ≤ i ≤ n) ist eines der Ereignissymbole INSERTED INTO B, DELETED FROM B, UPDATED B.Aj . Aj ist das Attributsymbol eines Attributs der
Basisrelation B. F ist eine SQL-Formel und Mk (1 ≤ k ≤ g) ist eine SQL-Änderungsanweisung.
2. Grundlagen deduktiver Datenbanken
18
Mit einem CREATE RULE-Befehl wird ein Trigger als persistentes Schemaobjekt erzeugt. Ein StarburstTrigger kann für verschiedene Ereignisse feuern und somit für verschiedene Basisrelationen definiert
werden. Um einen Trigger zu aktivieren, ist es ausreichend, wenn eines der Ereignisse aus der Liste
E1 , ..., En eintritt. Als Ereignis wird die Ausführung der Änderungsanweisungen für Einfügungen,
Löschungen und Modifikationen erkannt. Ein Starburst-Trigger wird nicht unmittelbar bei Eintritt des
Ereignisses gefeuert, sondern erst zum ’rule assertion point’, der immer zum Ende einer Transaktion
oder auch vom Anwender während der Transaktion gesetzt wird.
Zum ’rule assertion point’ wird von der Triggerkomponente der Nettoeffekt der Ereignisse deterministisch ermittelt (Nettoeffekt der Basisfaktenänderungen), die seit dem letzten ’rule assertion point’
eingetreten sind. Für z.B. die Einfügung und Löschung des gleichen Fakts bedeutet dies, dass zum ’rule assertion point’ keine Ereignisse vorliegen, für die Trigger aktiviert werden können. Für die Nettoeffektänderungen werden von der Triggerkomponente die Trigger mengenorientiert gefeuert und
ausgeführt. Mengenorientiert heißt in diesem Zusammenhang, dass ein Trigger für die Ausführung
einer Anweisung einmal feuert, unabhängig davon, wie viele Fakten geändert wurden.
Beim Aktivieren eines Triggers werden keine Variablenbindungen für die optionale Bedingung (IF)
und die Aktionen (THEN) des Triggers erzeugt (keine Instanziierung). Innerhalb der Aktionen und der
Bedingung kann auf den neuen DB-Zustand der Relationen zugegriffen werden. Die Menge der manipulierten Fakten einer Relation liegen in systemintern verwalteten ∆-Mengen (’transition tables’:
INSERTED / DELETED / OLD UPDATED / NEW UPDATED B) vor. Auf die Transitionsrelationen
kann im Aktions- und Bedingungsteil des Triggers lesend zugegriffen werden.
Die optionale PRECEDES-Klausel bietet die Möglichkeit, eine partielle Ordnung für eine Menge von
Triggern zu definieren (Prioritäten). Der Trigger G wird vor den Triggern G1 ,...,Gm ausgeführt. Sind
keine Prioritäten definiert, feuern die Trigger in beliebiger Reihenfolge. Sind alle relevanten Trigger
für ein Ereignis Ei gefeuert, wählt die Triggerkomponente den Trigger G aus, der über keinen aktivierten Vorgänger verfügt. Bevor G ausgeführt wird, wird die Bedingung F der IF-Klausel ausgewertet.
Ist F nicht erfüllt, so wird G nicht ausgeführt, und der nächste aktivierte Trigger wird ausgewählt.
Bricht die Ausführung einer triggerausgeführten Aktion fehlerhaft ab, so wird die gesamte Transaktion zurückgerollt.
Kapitel 3
Materialisierte Sichten
Sichten sind aus mehreren Gründen für konventionellen Datenbanken sehr nützlich. Die externe Ebene
der Sichten repräsentiert die Interessen der Datenbankanwender. Sichten können auch zur Durchführung der Datensicherheit gebraucht werden. In großen Unternehmen werden z.B. Namen und Rollen
aller Angestellten in einer Datenbank gespeichert und ihre Zugriffsrechte auf Daten verwaltet. Dabei sollte die persönliche Daten, wie ihre Gehälter, aus Gesichtspunkten des Datenschutzes nicht zu
sehen sein. In solchen Situationen kann eine Sicht definiert werden, die nur die Attribute der Angestelltenrelation selektiert, welche allen Angestellten mitgeteilt werden dürfen. Die Rechte, die Sichten
durch Anfragen nutzen zu können, können allen Angestellten erteilt werden und die vertraulichen Informationen können dabei geschützt sein. Eine andere nützliche Anwendung der Sichten ist es, dass
sie den Anwendern eine Schnittstelle zu Verfügung stellen, welche die Aufnahme und Nutzung der
Datenbanken in der realen Welt wahrnehmbarer macht.
Die Aussage, dass Sichten nur vorteilhaft sind, ist nicht unbestritten, weil sie zu jeder Referenzierung
neu berechnet werden müssen. Inhalte der Sichten können in einer Datenbank materialisiert werden,
dabei werden die Sichten gespeichert und bei der Abfragebeantwortung genutzt. Diese Idee der materialisierten Sichten geht auf [SB75] und [SS82] zurück mit dem primärem Ziel, die Effizinz des
Datenbanksystems zu verbessern. In [SB75] beinhalten die materialisierte Sichten Zeiger, um schnellen Zugriff auf Daten zu implementieren. In [SS82] war die Idee, Joins vorauszuberechnen und ihre
Ergebnisse als materialisierte Sichten zu speichern, um eine bessere Effizienz zu erzielen.
Eine materialisierte Sicht ist eine Sicht, deren Inhalt, wie bei einer Basis-Relation, in der Datenbank
gespeichert wird. Dieser Vorgang wird Materialisierung genannt. Die materialisierte Sicht ist also
eine Art Cache für den Inhalt der Sicht. Anfragen an eine materialisierte Sicht können dann direkt auf
dem Inhalt dieses Caches berechnet werden als wäre die Sicht eine Basisrelation. Da die Sicht nicht
19
3. Materialisierte Sichten
20
jedesmal neu berechnet werden muß und die Anfragen nicht, wie oben beschrieben, zu komplexeren
Anfragen ergänzt werden müssen, ist der Zugriff auf eine materialisierte Sicht dadurch wesentlich
schneller.
Eine materialisierte Sicht wird meistens so lange in der Datenbank gehalten, wie auf sie zugegriffen
wird. Das heißt, dass die gespeicherten Daten einer materialisierten Sicht erst gelöscht werden, wenn
auf die Sicht für einen gewissen Zeitraum nicht zugegriffen wurde. Wie lang dieser Zeitraum sein
sollte, hängt von der Zeit ab, die benötigt wird, um die Sicht neu zu berechnen, und natürlich von dem
zur Verfügung stehenden Speicherplatz. Ein Wert für die Speicherdauer kann etwa vom Administrator
festgelegt oder vom System automatisch abgeschätzt werden.
Des weiteren können in einer Sichtenmaterialisierung Index-Strukturen aufgebaut werden, die den
Zugriff weiter beschleunigen. Materialisierung reduziert den Berechnungsaufwand bei wiederkehrenden Anfrageteilen.
Der Vorteil, der sich aus materialisierten Sichten ergibt, ist die schnellere Antwortzeit, besonders
bei hoher Anfragerate und hoher Komplexität der Anfragen, da das Ergebnis nicht neu berechnet
werden muß, sondern nur die gespeicherten Tupel abgerufen werden. Die Nachteile sind zusätzliche
Kosten für die Speicherung (redundante Struktur) und die Pflege der materialisierten Sichten bei einer
Änderung von Basisrelationen.
Einige Faktoren zur Beurteilung der Nutzung von bereits existierende materialisierten Sichten:
• Zeit des letzten Zugriffs
• Referenzierungshäufigkeit
• Größe der materialisierten Sicht
• Kosten, die durch eine Neuberechnung oder Aktualisierung der materialisierten Sicht verursacht
wurden
• Anzahl der Anfragen, die in der Vergangenheit mit dieser Sicht hätten beantwortet werden können oder beantwortet worden sind
• Anzahl der Anfragen, die prinzipiell mit dieser Sicht beantwortet werden können
Diese Faktoren gehen unterschiedlich gewichtet in die Berechnung des Nutzwertes einer materialisierten Sicht ein. Mit Hilfe des Nutzwertes werden die bereits materialisierten Sichten sortiert und je
nach Bedarf werden die Sichten mit dem geringsten Nutzen verdrängt.
3. Materialisierte Sichten
21
Das Konzept der Materialisierung von abgeleiteten Daten und ihre Anpassung in Rahmen der Änderungen ist zum ersten Mal in [KP81] erschienen. Der Begriff view materialization oder materialized
view ist in [SI84] eingeführt worden. Laut Jeffrey Ullman1 ist der Ausdruck materialized view ein
Widerspruch in sich. Jedoch ist diese Bezeichnung in neuen Datenbanktechnologien weit verbreitet
(wie z.B. in Data Warehouse, Data Interation, Data-Cube Systems, etc.) und ist weitgehend akzeptiert.
3.1
3.1.1
Auswahl und Anwendung materialisierter Sichten
Das allgemeine Problem der Auswahl
In der Literatur werden eine Reihe verschiedenen Algorithmen zur Auswahl der zu materialisierenden
Sichten vorgestellt. Wenn viele Anfragen über Basisrelationen gemacht werden, können einige temporäre Ergebnisse (Sichten) für mehrere Anfragen genutzt werden. Auf den Resultaten werden durch
weitere Operationen die Anfragen beantwortet. Werden alle Sichten materialisiert, entstehen sehr geringe Kosten für den Anfrageprozess. Es werden dann nur die gespeicherten Tupel abgerufen. Jedoch
die Pflege dieser Sichten ist sehr aufwendig. Materialisiert man keine Sichten, so kommen zwar keine
Kosten für die Anpassung zustande, aber der Anfrageprozess ist nur mit sehr hoher Rechenleistung
zu bewältigen. Es muss eine geeignete Auswahl der materialisierten Sichten gefunden werden. Dabei
sollen die Kosten für die Bearbeitung der Anfragen und Anpassung der Sichten minimal sein.
Statische Auswahl materialisierter Sichten
Eine Möglichkeit der Auswahl einer möglichst optimalen Menge an Materialisierungen ist die statische Auswahl. Das heißt, die Auswahl der materialisierenden Sichten findet zu einem bestimmten
Zeitpunkt statt, der von einem Algorithmus oder dem Administrator bestimmt wird. Der Nachteil ist,
dass das aktuelle Anfrageverhalten nicht in die Berechnung einbezogen wird, sondern höchstens nur
die Informationen, welche Anfragen in der Vergangenheit auftraten.
Das statische Auswahlverfahren basiert auf der Annahme, dass die ausgewählten Sichten in einen
gewissen Zeitraum (z.B. Nachts) materialisiert und aktualisiert werden. Durch statische Materialisierung erfolgen große Leistungssteigerungen, allerdings entstehen durch ihre alleinige Anwendung
auch Nachteile:
1
In der Einleitung von [GM99]
3. Materialisierte Sichten
22
• Oft werden bestimmte Zusammenhänge gezielt untersucht, so dass zu einem bestimmten Zeitpunkt ähnliche Anfragen gestellt werden. Die Folge ist, dass das typische Anfragemuster aus
mehreren nicht vorhersehbaren Anfragen besteht.
• Wenn die Daten häufig verändert werden, veralten die materialisierten Sichten schnell, was
einen erhöhten Aktualisierungsaufwand zur Folge hat.
• Das Anfragemuster ändert sich beständig, so dass ständig eine Anpassung der materialisierten
Sichten stattfinden müsste.
• Aufgrund der zunehmenden Globalisierung, kann es vorkommen, dass aus unterschiedlichen
Zeitzonen auf ein Data-Warehouse zugegriffen wird. Dadurch ergibt sich kein Zeitraum mehr,
indem die Sichten materialisiert werden können, ohne das Anfrageverhalten zu beeiträchtigen.
Dynamische Auswahl materialisierte Sichten
Das Problem der statischen Auswahl von materialisierten Sichten, dass nur das Anfrageverhalten aus
der Vergangenheit zur Entscheidung genutzt wird, welche Sichten zu materialisieren sind, macht es
erforderlich Verfahren zur Anpassung der Sichten an das aktuelle Anfrageverhalten zu ergänzen. Das
heißt Ergebnisse aus einer vorangegangenen Anfrage werden als Grundlage bei der nächsten Anfrage
genutzt. Deshalb ist es nötig einen Teil der Anfrageergebnisse in einem reservierten Speicherbereich
zur Wiederverwendung zu materialisieren. Für dieses Verfahren gibt es noch einen weiteren Vorteil.
Oft sind die Ergebnismengen von Anfragen relativ klein, so dass eine Zwischenspeicherung nicht
übermäßig viel Platz benötigt, aber eine deutliche Beschleunigung einer Folge von Anfragen ermöglicht.
3.1.2
Einsatzgebiete von materialisierten Sichten
Materialisierte Sichten finden in vielen Datenbankgebieten Anwendung. Eine komplete Anzahl der
Anwendungen ist in [GM99] gegeben. Dieses Unterkapitel stellt eine Übersicht der Top-Anwendungen
materialisierter Sichten zusammen.
Schnellzugriff Jede Anfrage kann auf einen simplen Zugriff einer Sichtenmaterialisierung reduziert
werden. Hierdurch wird auch die Belastung des Rechenprozessors und der Festplatten vermindert.
3. Materialisierte Sichten
23
Abbildung 3.1: Anwendung materialisierter Sichten in DWH
Data Warehouse Informationen können gesammelt werden ohne jede Datenbank in das Data Warehouse kopieren zu müssen. Anfragen werden beantwortet, wobei auf den Zugriff auf die Quelldatenbank verzichtet werden kann, der beschränkt oder sehr teuer sein kann.
Chronicle Systems Banken, Handels- und Buchhaltungssysteme gehen täglich mit zusammenhängenden Strömen von Transaktionsdaten um. Solche Systeme speichern Reihen von Tupeln in
zeitlicher Ordnung ab. Sie können daher sehr groß werden und jenseits jeder Datenbankkapazität liegen. Sichtenmaterialisierungen beantworten Anfragen nach den wichtigsten Informationen ohne auf das umfangreiche und schnellwachsende Chronicle System zugreifen zu müssen.
Eine Sichtenmaterialisierung könnte z.B. die Kontostände der Kunden liefern.
Datenvisualisierung Visualiserungsanwendungen zeigen Sichten über Daten einer Datenbank. Ändert der Anwender die Sichtendefinition, muss die Anzeige der Daten entsprechend angepasst
werden. Mit steigender Erfahrung des Anwenders wächst auch sein Verständnis für die angezeigten Datensammlungen. Dank der Sichtenmaterialisieurng kann das System auf solche
interaktiven Änderungen dynamisch reagieren.
Mobile Systeme Mobile Anwendungen verfügen meist über eingeschränkte Möglichkeiten zur Abfrage größerer Datenmengen. Die Geräte auf denen sie laufen verändern ihre Position und es
werden abhängig von ihrem Ort und der Umgebung Anfragen generieren. Hier ist es sinnvoll,
die übertragenen Daten minimal zu halten und nur die Veränderungen neuzuberechnen.
3. Materialisierte Sichten
24
Integritätsprüfung Die meisten statischen Integritätsbedingungen können als eine Menge von Sichten so repräsentiert werden, dass eine nicht leere Sicht auf eine verletzte Bedingung hinweist.
Methoden der Sichtenanpassung können dazu verwendet werden, die Konsistenzbedingungen
inkrementell zu überprüfen, wenn Daten einer Datenbank verändert wurden.
Anfrageoptimierung Zur Optimierung beliebiger Anfragen können die Sichten der Sichtenmaterialisierung verwendet werden.
3.2
Anpassung materialisierter Sichten
Nach der Erzeugung mehrerer materialisierter Sichten stellt sich die Frage, wie diese bei einer Änderung der Detaildaten möglichst effizient aktualisiert werden können. Hinzu kommt das Problem, dass
aufgrund von Redundanzen zwischen verschiedenen Sichten meistens mehrere Sichten gleichzeitig
aktualisiert werden müssen. Die Daten der materialisierten Sicht können unter bestimmten Bedingungen, z.B. Änderungen in den zugrunde liegenden Relationen, ungültig werden.
Es existieren oft viele verschiedene Verfahren und Ansätze zur Pflege der materialisierten Sichten.
Alle Verfahren haben ihre Vor- und Nachteile. Die Frage ist, ob ein kostenbasiertes Modell entwickelt
werden kann, das situationsbedingt abschätzen kann, welches Verfahren zu einem bestimmten Zeitpunkt das günstigste ist und dieses anwendet. Die Sichtenanpassung wird durchgeführt, weil es sich
gezeigt hat, dass die Berechnung der Änderungen und ihre Durchführung in den meisten Fällen kostengünstiger ist als die komplette Neuberechnung.
Mit der sogenennten Re-Materialisierung (Neuberechnung) werden die Sichten auf den aktuellen
Zustand der Datenbank gebracht. Obwohl Re-Materialisierung einfach zu implementieren ist, ist sie
meistens kostenintensiv [GM95]. Eine Alternative ist die inkrementelle Sichtenanpassung.
3.2.1
Techniken der Aktualisierung
Rematerialisierung Komplettes Löschen und Neuberechnen der Sicht nach der Änderung.
Inkrementelle Aktualisierung Bei inkrementeller Sichtenanpassung wird durch Algorithmen, die
die zugrunde liegenden Basisrelationen benutzen, versucht, unnötige Neuberechnungen der
kompletten Sicht zu vermeiden und an Stelle dessen nur notwendige Änderungen in der Sicht
durchzuführen.
Autonome Aktualisierbarkeit Wenn eine materialisierte Sicht nur mit Hilfe der Definition der Sicht,
der Änderung der Basisrelation, sowie der bestehenden Instanz der Sicht eine inkrementelle
3. Materialisierte Sichten
25
Aktualisierung beim Einfügen, Löschen oder Änderung der Basisrelation durchführen kann, so
spricht man von autonomer Aktualisierbarkeit.
Selbstpflege (self-maintenance) Neuberechnung ohne Benutzung der Datenquelle.
3.2.2
Klassifizierung von Aktualisierungsalgorithmen
Es gibt verschiedene Algorithmen zu jeder Aktualisierunsmethode. Die Algorithmen unterscheiden
sich am deutlichsten in der Ausdrucksfähigkeit der verwendeten Sprache für die Sicht-Definition
(SPJ-View, SQL, ...), in der Verwendung von Schlüsseln und in der Behandlung von Einfüge- und
Löschoperationen (getrennt oder im gleichen Durchlauf). Die Effizienz der Algorithmen hängt von
verschiedenen Einflussfaktoren ab:
1. Die Menge der zur Verfügung stehenden Informationen hat Einfluss auf die Auswahl eines
Algorithmus. Allerdings muss die Definition einer Sicht und ihre Ausprägung immer bekannt
sein. Auch wichtig ist die Frage, ob ein Zugriff auf die Basisrelationen überhaupt möglich ist,
beziehungsweise wenn nicht, welche Integritätsbedingungen existieren.
2. Je komplexer die möglichen Anfragekonstrukte zur Definition einer Sicht sind, desto schwieriger wird es auch diese Sichten zu aktualisieren.
3. Wichtig ist, welche Modifikationstypen von den Algorithmen verarbeitet werden können. Im
einfachsten Fall sind es nur Einfüge- und Löschoperationen, die verwendet werden. Änderungsoperationen werden demnach wie eine aufeinander folgende Einfüge- und Löschoperation behandelt.
4. Ein entscheidender Parameter ist die Granularität der Aktualisierung, also ob Sichten einzeln
aktualisiert werden können, was eine sehr flexible Aktualisierung ermöglicht oder ob im Extremfall immer die ganze Datenbank auf einmal aktualisiert werden muss.
5. Der Zeitpunkt der Aktualisierung
Sofortige Aktualisierung Bei einer Änderung der Basisdaten werden gleichzeitig die abgeleiteten Daten, wie z.B. im Data-Warehouse-System, aktualisiert. Der Vorteil ist, dass das
Data-Warehouse immer aktuell ist, allerdings entstehen hohe Kosten durch die häufigen
Modifikationen.
Verzögerte Aktualisierung Eine materialisierte Sicht wird erst dann aktualisiert, wenn auf sie
zugegriffen wird. Dadurch werden unnötige Aktualisierungen vermieden, allerdings kann
Wartezeit entstehen, wenn auf mehrere veraltete Sichten zugegriffen wird.
3. Materialisierte Sichten
26
Snapshot Aktualisierung Die Aktualisierung erfolgt asynchron nach Änderungen der Basisdaten. Der Zeitpunkt kann nach anwendungsspezifischen Kriterien ausgewählt werden,
allerdings wird der Zugriff auf veraltete Daten in gewissen Maßen toleriert.
3.2.3
Ungeklärte Probleme bei der Sichtenanpassung
Es gibt eine Reihe allgemein Probleme, die bei der Aktualisierug der Sichten vorkommen. Hier werden einige wichtigeFragen, die diese Probleme beschreiben, aufgelistet:
• Sollen die Sichtenmaterialisierungen vor oder nach Abschluss (commit) der Transaktion, die
die Basisrelation aktualisiert, gepflegt werden?
• Ist die Sichtenpflege als Bestandteil der Transaktion zu sehen?
• Muss die Sichtenpflege nach jeder einzelnen Aktualisierung oder erst nach allen Updates erfolgen?
• Soll die Sichtenpflege automatisch (z.B. regelbasierend) oder benutzergesteuert eingeleitet werden?
• Lässt sich ein kostenbasiertes Modell entwickeln, das zwischen verschiedenen Lösungswegen
abwägt und das günstigste auswählt?
• Bleibt die Frage nach der Komplexität der Sichtenpflege unbeantwortet?
Obengenannte Fragen tauchen oft bei der Implementitierung und Zusammenführung der Sichten in
einem Datenbanksystem auf.
3.3
Inkrementelle Anpassung materialisierter Sichten
Inkrementelle Anpassung verlangt, dass die Änderungen auf den Basisrelationen benutzt werden, um
die Änderungen der Sicht zu berechnen. Deshalb behandeln die meisten Aktualisierungstechniken
die Sichtdefintion als mathematische Formel und führen eine Differentation durch, um einen Ausdruck für die Änderung der Sichten zu erhalten. Die Idee bei der inkrementellen Aktualisierung ist
es, erst festzustellen, welche der Detaildaten sich geändert haben und dann diese Änderungen in den
materialisierten Sichten nachzuvollziehen. Anders ausgedrückt: Berechnung des neuen Zustands der
materialisierten Sichten aus dem alten Zustand dieser Sichten und der durchgeführten Änderung der
Basisrelation. Der ganze Prozess läuft wie folgt ab:
3. Materialisierte Sichten
27
Abbildung 3.2: Problemraum der inkrementellen Sichtenanpassung
• Update der Basisrelation
• Nachricht an die Sicht über das Update
• Anfragen der Sicht an andere Basisrelationen, ob Aktualisierungen notwendig sind
• Aktualisierung der Sicht
3.3.1
Klassifikation des Sichtenanpassungproblems anhand von vier Dimensionen
Es sind detaillierte Kriterien erforderlich, um die existierende Literatur zur inkrementellen Sichtenanpassung zu charaktersieren bzw. zu vergleichen. In [GM95] und [GM99]werden einige Ansätze vorgestellt, um eine Klassifikation des Problems anhand von mehreren Dimensionen zur Verfügung zu
stellen, die in der Abbildung 3.3 gezeigt werden.
Information Die Menge der für die Sichtenanpassung verfügbaren Informationen
Datenmanipulationssprache Mit welchen Modifikationen kann die Anpassungmethode umgehen
Sichtendefinitionssprache In welcher Sprache wird die Sicht ausgedrückt
Instanzen Für welche Instanzen der Datenbank ist der Anpassungsalgorithmus anwendbar
3.3.2
Inkrementelle Sichtenanpassungsalgorithmen auf Basis der vollständigen Informationen
Im Falle der vollständigen Informationen stehen vier bekannte Algorithmen zu Verfügung. Die folgenden Algorithmen sind für rekursive Sichten vorgestellt worden:
3. Materialisierte Sichten
28
Abbildung 3.3: Problemraum in 3D
Deletion and Rederivation (DRed) Algorithmus DRed nimmt eine zu große Schätzung der zu löschenden Tupel vor und korrigiert diese Liste um die Tupel, für die alternative Ableitungen
existieren. Für die Menge der einzufügenden Tupel reicht die Auswertung der teilweise aktualisierten Sichtenmaterialisierungen.
Propagation / Filtration (PF) Algorithmus Der PF-Algorithmus arbeitet analog zu DRed, die Änderungen werden aber für alle Basisrelationen einzeln und schleifenweise berechnet.
Kuchenhoff Algorithmus Hier werden die Unterschiede nachfolgender Datenbankzustände durch
Ableitungen rekursiv neu berechnet. Auch Kuchenhoff arbeitet ähnlich wie DRed, verwirft aber
keine mehrfach vorkommenden Ableitungen, die keine Auswirkungen auf die Sicht haben.
Urpi-Olive Algorithmus Verwendet ein Modell mit Existenzquantoren, um Änderungen der Basisrelationen in geänderte Sichten zu übersetzen.
Alle Algorithmen für rekursive Sichten können auch für nichtrekursive Sichten eingesetzt werden.
Darüber hinaus sind bestimmte Algorithmen extra für nicht rekursive Sichten implementiert worden:
3. Materialisierte Sichten
29
Counting-Algorithmus Pflegt mittels eines Zählers über die Ableitungen jedes Tupels der Sicht
Einfüge- und Löschoperationen ein.
Algebraic Differencing Relationale Ausdrücke berechnen Änderungen der Sicht ohne Redundanz.
Für jede Sicht werden die Änderungen mit je einer Sicht für das Einfügen und für das Löschen
ermittelt.
Ceri-Widom behandelt ausgewählte SQL-Sichten ohne Duplikate, Aggregation oder Negation getrennt von SQL-Sichten, deren Attribute den Schlüssel der Basisrelation durch eine Funktion
bestimmen.
Einen Algorithmus zu finden, der im Falle der unvollständigen Informationen aller Dimensionen umfasst, ist noch ein großes Problem.
Verwendung unvollständiger Informationen kann in verschiedenen Formen auftreten:
Nullinformation Query independent of update bzw. irrelevant update problem
Self-Maintenance Sicht kann bei jeder Modifikation der Basisrelation sich selbst anpassen
Teil-Referenz Materialisierte Sicht und Teile der Basisrelation sind vorhanden
• Chronik: Sicht ist ohne geänderte Relation verfügbar
• Change-Reference-maintainable: Nur die Sicht und die geänderte Relation sind verfügbar
Kapitel 4
Ausgewählte Methoden zur
inkrementellen Sichtenanpassung
In diesem Kapitel werden drei Strategien zur Anpassung materialisierter Sichten in relationalen Datenbanken vorgestellt, die später verglichen werden sollen:
Die Methode von Gupta/Mumick/Subrahmanian Ein deduktiver Implementierungsansatz ([GMS93])
Die Methode von Ceri/Widom Eine triggerbasierte Implementierung ([CW91])
Die Methode von Manthey Ein alternativer deduktiver Implementierungsansatz1 ([Man03])
Im folgenden werden diese drei Methoden kurz als GMS-, CW- bzw. MU-Methode bezeichnet.
4.1
Die GMS-Methode
Dieses Propagierungsverfahren ist für ableitbare Änderungen entwickelt worden. Es ist eine DeltaPropagierungsmethode, die Algorithmen zur Aktualisierung der materialisierten Sichten in relationalenund deduktiven-Datenbanken präsentiert. Die Implementierung dieses Verfahrens wird als passiv bezeichnet, da die induzierten Änderungen durch interne Deduktionsregeln abgeleitet werden.
Sicht-Definitionen (Regeln) können in SQL oder Datalog geschrieben werden, wobei in [GMS93]
Datalog bevorzugt wird. Regeln dürfen auch UNION, stratifizierte Negation, Aggregation, lineare
1
auch Magic Updates-Methode genannt
30
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
31
Rekursion und allgemeine Rekursion beinhalten. Dieses Verfahren erfordert Zugriff auf alle Basistabellen für alle notwendigen Operationen, was höheren Aufwand bedeutet. Dieses Verfahren lässt
auch Duplikate zu, dabei ist die Anzahl der Ableitungen jedes Tupels relevant. Zur Eliminierung der
Duplikate wird hier ein spezieller Unionoperator definiert.
Im Compilierungsteil der Methode, werden Regeln (Sichten) in Delta-Regeln transformiert:
compilieren
R −−−−−−−→ ∆R
Durch Regelcompilierung wird ein spezielles Inferenzverfahren erzielt, der Interpreter. Algorithmen,
die in [GMS93] angewendet werden, entsprechen diesem Interpreter. Dabei sind nur Änderungen
in der Form von Einfügungen und Löschungen als Input den Algorithmen gegeben. Modifikationen
werden hier als Einfügung des neuen und Löschung des alten Fakts durchgeführt. Mit Hilfe von DeltaRegeln und Fakten (Basisfakten, Deltafakten, materialisierte Fakten) werden abgeleitete Deltafakten
erzeugt.
Die Autoren schlagen zwei inkrementelle Sichtenanpassungsalgorithmen vor:
1. Counting-Algorithmus: Arbeitet mit nichtrekursiven Sichten, die auch Negation und Aggregation beinhalten können.
2. Delete and Rederivation-Algorithmus (DRed): Ist für rekursive Sichten entwickelt worden
und lässt auch Negation und Aggregation zu.
Beide Algorithmen benutzen den Sichtinhalt um ∆-Regeln zu produzieren, um die Änderungen der
Basisdaten an die Sichten anzupassen. Die Algorithmen können sowohl rekursive als auch nichtrekursive Sichten bearbeiten. Für rekursive Sichten kann der Counting-Algorithmus nur effektiv arbeiten,
wenn jedes Tupel eine beschränkte Anzahl von Ableitungen hat. Die Operationen, die Basisrelationen
ändern, sind Einfügen und Löschen von Tupeln. In [GMS93] wird die Datalog-Syntax wegen ihrer
Prägnanz bevorzugt. In Abbildung 4.1 wird die Architektur der Methode nach [GMS93] gezeigt. Der
Delta-Fakt-Generator ist ein iterierter Algorithmus mit terminierender Schleife, der endliche Mengen bearbeitet. Die generierten Delta-Regeln werden mit der Menge der Fakten und Basisänderungen
dem Algorithmus übergeben, um induzierte Änderungen zu erzeugen. Die Menge der abgeleiteten
Deltafakten wird vor dem Ablauf des Prozesses geleert. Die Änderungen werden in der untersten
Schicht des Abhängigkeitsgraphen eingesetzt. Während der bottom-up-Propagierung wird die Anzahl
der Ableitungen pro Fakt in jeder Schicht berechnet. Abgeleitete Relationen in den beiden Zuständen
(neu und alt) werden benötigt, um Deltafakten zu produzieren.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
32
Abbildung 4.1: Struktur der GMS-Methode
4.1.1
Counting-Algorithmus
Der Counting-Algorithmus ist zur Aktualisierung der materialisierten Sichten in relationalen und deduktiven Datenbanken entwickelt worden. Er hat eine Multimengensemantik, das heißt nicht, dass
die Relationen eine Menge von Tupeln sind, sondern es können mehrere Ableitungen eines Tupels
vorkommen. Änderungen werden als eine Menge betrachtet (Transaktion), die in der Semantik der
deterministischen Transaktionen alle ausgeführt werden müssen bis ein neuer Datenbankzustand erreicht ist.
Sichere und stratifizierte Negation und Aggregation (z.B. Summierung und Durchschnitt von Attributen) sind in den Sichtendefinition erlaubt. Da es in rekursiven Sichten eine unendliche Anzahl von
verschiedenen Herleitungspfaden geben kann, ist dieser Algorithmus nur auf nichtrekursive Sichten
anwendbar.
Der Algorithmus zählt die unterschiedliche Herleitungen eines Tupels t in der Sicht und speichert diesen Wert zusätzlich in der materialisierten Sicht als count(t) ab. Counts sind eine Art Iterationszähler
für Deltafakten. Ein Tupel t wird mit der Anzahl seiner Ableitungen in folgender Form geschrieben:
t ∗ i, wobei i positiv (bei Einfügungen) oder negativ (bei Löschungen) sein kann.
Bei Änderungen werden diese Werte von den Basisprädikaten ausgehend aktualisiert, d.h. Counts
werden während der bottom-up-Propagierung berechnet. Wenn der Wert 0 ist (d.h. keine Basisrelation
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
33
leitet dieses Tupel ab), wird das zugehörige Tupel gelöscht. Nach [Mum91] bezeichnet man count(t)
als die Anzahl des Vorkommens eines Tupels t in positiven Programmen2 berechnet. Die Kosten zur
Berechnung des Counts können bei nichtbeschränkter Anzahl der Ableitungen eines Tupels erheblich
steigen. Bei nichtrekursiven Sichten kann die Anzahl der Ableitungen für jedes Tupel mit einem Minimum an Kosten oder fast keinen Kosten berechnet werden. Der Algorithmus funktioniert in beiden
Fällen der Duplikat-Präsentation, d.h., wenn es mehrere Ableitungen für jedes Tupel gibt oder wenn
mehrere Kopien eines Tupels existieren. Bei diesem Algorithmus wird kein Effektivitätstest im Sinne der Existenz mehrerer Ableitungen durchgeführt, sondern sie werden wie oben erläutert gezählt.
Zusammengefasst kann man die Vorgehensweise wie folgt darstellen:
Bei der ersten Materialisierung wird die Anzahl der alternativen Ableitungswege für jeden Fakt ermittelt. Ist ein später einzufügender Fakt noch nicht vorhanden, so wird der Fakt mit count = 1 eingefügt.
Bei bereits vorhandenen Fakten wird der Zählerwert nur entsprechend aktualisiert. Physisch gelöscht
wird ein Fakt erst, wenn count = 0 ist.
UNION-Operator
U
: Duplikat-Test
Die Mengenoperation vereinigt zwei Mengen und beachtet dabei auch die Counts der einzelnen Tupel.
Die Delta-Regeln für ein Prädikat werden aus den Original-Regeln durch Ersetzen eines Literals im
Rumpf durch das entsprechende Delta-Literal erzeugt.
Jedes Tupel kommt mit einem Count (Anzahl seiner Ableitungen) vor. Für zwei Mengen s1 und s2 :
s1 ] s2 (gelesen: s1 und s2 ) mit Counts c1 und c2 , wird der Operator wie folgt definiert:
• Falls ein Tupel t nur in einer der Mengen s1 oder s2 mit dem Count c auftritt, dann kommt das
Tupel t mit Count c in s1 ] s2 vor.
• Falls ein Tupel t in s1 und s2 mit Counts c1 und c2 vorkommt und c1 + c2 6= 0, dann ist Count
von s1 ] s2 gleich c1 + c2 , sonst (d.h. c1 + c2 = 0) erscheint t nicht in s1 ] s2
Folglich ist P ν = P ] ∆(P ). Dieser Join-Operator ist also eine Neudefinition für Relationen mit
Counts: Der Count des Ergebnistupels ergibt sich aus dem Produkt der Counts der kombinierten
Tupel, wenn zwei oder mehr Tupel durch Join kombiniert werden. Die Korrektheit des CountingAlgorithmus garantiert, dass kein Tupel weder in P noch in P ν einen negativen Count hat. Die Tupel
in der Änderungsrelation ∆(P ) können negative Counts haben.
Durch Verwendung dieses Operators werden Mehrfachableitungen verhindert.
2
Ein positives Programm besteht aus Regeln und Fakten ohne Negation
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
34
Schichten-Nummer (SN) und Regel-Schicht-Nummer (RSN)
Falls ein reduzierter Abhängigkeitsgraph (RDG)3 auf einem maximal stark zusammenhängenden Teilgraph (SCC)4 aufgebaut wird, entsteht ein Schichten-Graph und man redet von der Stratum Number
(SN). Knoten des Abhängigkeitsgraphen bezeichnen die Prädikate und die Kanten die Regeln. Wir
betrachten dazu ein Beispiel mit der Basisrelation link und abgeleitete Relationen hop und tri-hop, die
wie folgt definiert sind: Ein gerichteter Pfeil vom Knoten link zum Knoten hop (s. Abbildung) sagt
aus, dass das Prädikat hop vom Prädikat link abhängig ist, d.h. link ist ein Bestandteil des Rumpfes
der Regel mit dem Prädikat hop im Kopf. Eine topologische Sortierung, die auf den RDG aufgebaut
ist, sorgt für die SN jedes Knotens.
Die bottum-up-Propagierung fängt bei der untersten Schicht an. In jeder Schicht werden die Duplikate
berechnet, dann erfolgt die Elimination der Duplikate. So wird für jedes Tupel in der Schicht der Count
bestimmt. Bei der Bestimmung des Counts für eine höhere Schicht werden die Counts von der unteren
Schicht nicht mitgerechnet. Dies wird im Paragraph Optimierung näher erläutert.
Definition: ∆(P )
∆(P ) ist ein neu abgeleitetes Prädikat, dass die Änderungen in einer abgeleiteten Relation P beinhaltet, wenn Änderungen in Basisrelationen stattfinden. ∆(P ) = {ab ∗ 4, mn ∗ −2} bedeutet z.B., dass
für das Tupel p(a, b) vier Ableitungen eingefügt und zwei Ableitungen des Tupels p(m, n) gelöscht
werden.
3
4
reduced dependency graph
strongly connected component
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
35
P ν verweist auf die Relation P nach der Änderung (P -Neu, Aktueller Zustand). Dabei gilt folgende
Regel:
P ν = P ] ∆(P )
Die nächste Definition beschreibt Regeln, die dieses neu abgeleitete Prädikat mit gegebenen Regeldefinitionen für das abgeleitetes Prädikat p definieren.
Definition: ∆-Regeln
Für jede Regel der Form
(r) : p : −s1 , ..., sn ;
werden n ∆-Regeln ∆(r) erstellt, die das Prädikat ∆(p) definieren:
(∆(r)) : ∆(p) : −sν 1 , ..., sν i−1 , ∆(si ), si+1 , ..., sn
Das ν steht für neu, d.h. neuer Zustand der Datenbank.
Delta-Regeln werden u.a. als Input im Algorithmus ausgewertet, um abgeleitete Fakten zu erzeugen.
Deltarelationen hängen vom Vorzustand und anderen Deltas ab. Interne Deltarelationen protokollieren
Basisdatenänderungen und induzierte Änderungen. Die Auswertung der Restliterale (Residuen) müssen in bestimmten Zuständen erfolgen. Wenn sie nur im alten Zustand ausgewertet werden, werden
einige Folgen von Löschungen nicht berücksichtigt. In einer Delta-Regel erfolgt die Auswertung der
Restliterale bei Löschungen im neuen Zustand (links vom Delta-Literal), und bei Einfügungen im alten Zustand (rechts vom Delta-Literal). Für Residuenauswertungen und Effektivitätstests in [GMS93]
wird ein pessimistischer Ansatz zugrunde gelegt, bei dem ein neuer Zustand simuliert wird.
Transformation der ∆-Regeln
Wir betrachten ein einfaches Beispiel, um eine Vorstellung von dem Counting-Algorithmus zu bekommen.
Gegeben ist eine Sichtdefinition für eine abgeleitete Relation p aus Basisrelationstermen a und b. Die
Relation p wird wie folgt aus Tupeln A und B berechnet:
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
36
(v): p(X, Y ) : − a(X, Z), b(Z, Y );
Wenn die Basisrelationen a und b geändert werden, müssen die Tupel in der abgeleiteten Relation
p auch geändert werden. Die neuen Mengen Aν und B ν werden als A + ∆(a) bzw. B + ∆(b) geschrieben. ∆(a) und ∆(b) können beide eingefügte und gelöschte Tupel mit positiven bzw. negativen
Counts enthalten. Die neue Menge der Fakten für p wird durch folgendes Programm berechnet:
pν (X, Y ) : − aν (X, Z), bν (Z, Y );
Wenn man a durch (a + ∆(a)) und b durch (b + ∆(b)) ersetzt und dann das Distributivgesetz zwischen
Joins mit Unionoperatoren verwendet, kann die Regel aus folgenden vier Regeln gebildet werden:
1. pν (X, Y ) : − a(X, Z), b(Z, Y )
2. pν (X, Y ) : − ∆(a)(X, Z), b(Z, Y )
3. pν (X, Y ) : − a(X, Z), ∆(b)(Z, Y )
4. pν (X, Y ) : − ∆(a)(X, Z), ∆(b)(Z, Y )
Die erste Regel definiert den alten Wert von p. Die restlichen drei Regeln berechnen ∆(p). Daraus
folgt:
∆(p)(X, Y ) : − ∆(a)(X, Z), b(Z, Y )
∆(p)(X, Y ) : − a(X, Z), ∆(b)(Z, Y )
∆(p)(X, Y ) : − ∆(a)(X, Z), ∆(b)(Z, Y )
Die letzten zwei Regeln können unter Verwendung der Formel aν = a ] ∆(a) kombiniert werden:
(v1):
∆(p)(X, Y ) : − ∆(a)(X, Z), b(Z, Y )
(v2):
∆(p)(X, Y ) : − aν (X, Z), ∆(b)(Z, Y )
Die obigen zwei Regeln werden in folgendem Beispiel verwendet:
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
37
A = {12, 16, 23, 24}
B = {28, 68, 39}
P = {18 ∗ 2, 29}
∆(a) = {16 ∗ −1}
∆(b) = {68 ∗ −1, 49, 47}
Aν = {12, 23, 24}
B ν = {28, 39, 49, 47}
Aus der Substitution der Werte von ∆(a) und ∆(b) in den Regeln v1 und v2 ergeben sich die Werte
für ∆(p) und pν :
Aus der Regel v1 folgt ∆(p) = {18 ∗ −1}
Aus der Regel v2 folgt ∆(p) = {29, 27}
pν = p ] ∆(p) = {18 ∗ 2, 29} ] {18 ∗ −1, 29, 27} = {18, 29 ∗ 2, 27}
Dies ist genau das Ergebnis aus dem Join der Mengen Aν und B ν .
Delta-Regeln können auf mehr Basisrelationen verallgemeinert werden:
∆(p) : − ∆(a), b, c
∆(p) : − aν , ∆(b), c
∆(p) : − aν , bν , ∆(c)
Dieses Beispiel der Regeltransformation kann nicht ohne weiteres auf rekursive Programme übertragen werden.
Pseudo-Version des Counting-Algorithmus
Hier wird eine Basisversion des inkrementellen Sichtenanpassungsalgorithmus für nicht rekursive
Sichten ohne Negation und Aggregation beschrieben. Dieser Algorithmus berechnet Änderungen von
Schicht zur Schicht, wobei immer von der untersten Schicht angefangen wird.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
38
begin
Input: Menge der Regeln R, Menge der Delta-Regeln, Menge der Fakten der materialisierten
Sichten, Menge der Basisfakten, Menge der Delta Basisfakten
(Alle Regeln sind nicht-rekursiv)
Output: Einfügungen/Löschungen der abgeleiteten Deltafakten
for alle abgeleiteten Prädikate in nichtrekursiven Regeln R do
initialisiere P ν durch P
(P : materialisierte Faktenmenge)
Initialisiere ∆(P ) durch leere Menge
while falls keine Regel ausgewertet ist, werden die abgeleiteten Regeln - angefangen
von der untersten Schicht - ausgewertet do (Die Prädikate sind in einem geschichteten RDG konstruiert und die Counts werden während der buttom-up-Propagierung
berechnet)
for für jede abgeleitete Relation do
berechne die Menge der abgeleiteten Deltafakten ∆(P) anhand der oben definierten Delta-Regel-Definition
(Die Definition wird aus der Regel für abgeleitete Relationen in alten und neuen Zuständen und der Formel
P ν = P ] ∆(P )
gewonnen ;
P ν bezeichnet die Relation P nach der Anpassung der Änderungen in P )
Bezeichne r als ausgewertet
done
done
done
end
Die Regeln sind nach Schichtennummern sortiert, die durch eine topologische Sortierung des Abhängigkeitsgraphen über das gegebene Programm im Algorithmus erzeugt werden.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
39
Optimierung
Der Counting-Algorithmus berechnet die Anzahl der Ableitungen für jedes Tupel während der bottom-up-Propagierung in einem Datenbanksystem.
Ein Programm, das im Count-Algorithmus benutzt wird, besteht aus einer Menge von Fakten und
Regeln. Die Propagierung der Änderungen zu den Prädikaten in höheren Schichten läuft optimal,
falls die Relation P ν aus Mengen von Änderungen der Relation P zustande kommt. Das ist gegeben,
wenn folgende Optimierungsformel gilt:
∆(P ) = set(P ν ) − set(P )
Für nichtrekursiven Sichten gibt es normalerweise keine Kosten für Duplikatberechnung. Eine nichtrekursive Schicht besteht aus einem einzigen Prädikat, das durch einer oder mehreren Regeln definiert
wird. Jeder Operator wie Join, Select, Project und Union leitet nur ein Tupel für jede Ableitung ab.
Daher ist die Countb-Berechnung für nichtrekusive Sichten effizienter als bei rekursiven Sichten.
Duplikate können in einer Implementierung entweder durch Speichern mehrerer Kopien eines Tupels auftreten oder Speicherung eines Counts für jedes Tupel. In beiden Fällen arbeitet der AlgorithU
mus ohne zusätzlichen Kosten für Duplikatberechnung. Der -Operator im Algorithmus funktioneiert
U
wie ein normaler union-Operator, wenn die Operanden positive Counts haben. Ansonsten ist der Operator äquivalent zu der Multimengendifferenz.
Duplikat-Elimination ist eine kostenintensive Operation. Die Autoren dieser Methode behaupten, dass
zunehmende Duplikat-Elimination keine steigenden Operationskosten zur Folge hat. Der Count eines
Tupels wird nach der Duplikat-Elimination vergeben, und dies wird folgendermaßen berechnet: In
jeder rekursiven Schicht wird erstmal eine totale Duplikat-Berechnung vollzogen und danach werden
Duplikate eliminiert. Daraufhin wird für jedes Tupel der zugehörige Count berechnet. Während der
Berechnung der Counts in der nächst höheren Schicht i + 1 sind die Counts von i oder von den
unteren Schichten nicht erforderlich. Jedes Tupel hat in der Schicht i oder in den unteren Schichten
nur eine Ableitung. Nach der Berechnung der Duplikate in der Schicht i + 1 wird folglich der Count
für jedes Tupel in Bezug auf die Anzahl seiner Ableitungen vergeben. Dabei haben alle Tupel der
unteren Schichten entweder keine oder nur eine Ableitung.
In folgendem Beispiel wird unter Verwendung der Optimierungsformel
∆(P ) = set(P ν ) − set(P ), die ∆-Relation für die Sicht hop berechnet.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
40
Beispiel
Wir betrachten die Relationen hop und hopν nach der Verwendung der beiden Regeln v1 und v2:
∆(tri − hop)(X, Y ) : − ∆(hop)(X, Z), link(Z, Y )
∆(tri − hop)(X, Y ) : − hopν (X, Z), ∆(link)(Z, Y )
∆(hop) = set(hopν ) − set(hop)
∆(hop) = {ac, af, ag, dg, dh, bh} − {ac, dh, bh}
∆(hop) = {af, ag, dg}
Es muss beachtet werden, dass hier das Tupel hop(ac ∗ −1) in ∆(hop) nicht auftritt und auch nicht im
Stufenprozess der Relation tri-hop. Daher wird das Tupel (ah ∗ −1) für ∆(tri − hop) nicht abgeleitet.
Negation
Der Counting-Algorithmus unterstützt die Anpassung der Sichten mit der Negation (Regeln mit negativen Literalen). In dem Verfahren nach [GMS93] wird von sicherer Negation ausgegangen, d.h. die
Variablen, die in einem negativen Prädikat vorkommen, müssen auch in einem positiven Prädikat in
derselben Regel auftreten. Wenn ein Prädikat p negativ von einem anderen Prädikat q abhängt, dann
ist SN (p) < SN (q). Dabei bezeichnet SN die Schichtennummer des Prädikats.
Ein negatives Literal ¬p(A, Y, ...) in einerm stratifizierten Programm wird wie folgt ausgewertet:
Ein negativer Fakt ¬p(a, b, ...) hat den Count Null oder Eins: Null, wenn der Fakt p(a, b, ...) TRUE ist
und count(p(a, b, ...)) > 0, Eins, wenn der Fakt p(a, b, ...) den Wert FALSE hat. Der Grund dafür ist,
dass ein negativ instanziertes Literal ¬p(a, b, ...) als Auswertungsüberprüfung verwendet wird und
folglich wird ¬p(a, b, ...) den Wert FALSE haben, wenn p(a, b, ...) nur einmal abgeleitet wird.
Negation in rekursiven Sichten kann zur Unstratifizierbarkeit führen. Negative Regeln beim CountingAlgorithmus werden so ausgewertet, dass die invertierten Vorzeichen der negativen Prädikate der
induzierten Änderungen übergeben werden.
Nichtrekursive Sichten, die nur einfache Transitionsregeln verwenden, sind immer stratifiziert. Wir
betrachten ein negatives Prädikat ¬q(X, Y ) in einer Regel r, das eine Sicht definiert.
Wir erinnern uns an die ∆-Regel-Auswertung im Counting-Algorithmus:
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
41
(∆(r)) : ∆(p) : − sν1 , . . . , sνi−1 , ∆(si ), si+1 , . . . , sn
Ein negatives Prädikat kann in einem der drei folgenden Positionen in der Regel ri vorkommen:
Fall 1: sνj = (¬q)ν , j zwischen 1 und i − 1: (¬q)ν ≡ ¬(q ν ), da das Prädikat q in einer niedrigeren
Schicht als p liegt und schon berechnet ist.
Fall 2: sj = ¬q, j zwischen i + 1 und n: Die Relation über dem Prädikat ¬q wird als Q bezeichnet.
Q wird aus der Relation Q und aus den positiven Prädikaten in der Regel r, die die Variablen
X und Y beinhalten, berechnet. Ein Tupel (a, b) mit dem Count 1 ist in der Relation Q, wenn
entweder ein positives Prädikat in der Regel r die Werte a und b zu den Variablen X und Y
zuordnet, oder das Tupel q(a, b) ist F alse ((a, b) ∈
/ Q).
Fall 3: ∆(si ) = ∆(¬q): ∆(¬q) wird aus Termen von ∆(q) und den Originalwerten für q berechnet.
Da q und ∆(q) schon berechnet sind, kann ∆(¬q) ohne Auswertung der anderen Prädikate in r
bestimmt werden. ∆(Q) kann wie folgt definiert werden:
Definition: ∆(Q)
Angenommen Q ist die Relation, die über das Prädikat q definiert wird und ∆(Q) repräsentiert die
Änderungen in Q. Für ein Tupel t in ∆(Q) gilt:

 1 falls t ∈ ∆(Q) und t ∈
/ Q ] ∆(Q)
count(t) =
−1 falls t ∈ ∆(Q) und t ∈
/Q
Beispiel:
Gegeben:
p(X) : − s(X, Y ), ¬q(Y )
q(X) : − r(X)
s = {ab, ad, dc, bc, ch, f g}
Nach dem Counting-Algorithmus bekommen wir folgende Regeln für ∆(p(X)):
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
42
∆(p)(X) : − sν (X, Y ), ∆(¬q(Y ))
∆(p)(X) : − ∆(s)(X, Y ), ¬q(Y )
∆(q)(X) : − ∆(r)(X)
Die Änderung in der Menge s lautet:
∆(s) = {bc ∗ −1}
Nun ist Q = {a, b, c, d, f }.
Nach Verwendung der gegebenen Regeln folgt:
∆(r) = c ∗ −1 =⇒ ∆(q) = c ∗ −1
∆(Q) = {c ∗ −1}
∆(Q) = {c ∗ 1}
Q ] ∆(Q) = {a, b, d, f } =⇒ ∆(p)(X) = {b ∗ 1, cd ∗ 1}
Bei der Propagierung wird das Vorzeichen der Änderung des negativen Prädikats umgekehrt an die
induzierte Änderung (vom abhängigen Prädikat, d.h. Kopf der Regel) weiter gegeben.
4.1.2
Delete and Rederive-Algorithmus (DRed)
In [GMS93] wird ein Algorithmus zur Anpassung rekursiver der materialisierten Sichten vorgestellt.
Dabei können die Sichten Negationen und Aggregationen beinhalten. Der DRed-Algorithmus kann
also auch nichtrekursive Sichten bearbeiten, wobei der Counting-Algorithmus zur Anpassung nichtrekursiver Sichten effizienter ist. Das Problem bei der Anpassung nichtrekursiven Sichten wird beim
Löschen von Tupeln sichtbar, wobei eine semi-naive Methode, wie in [Ull89] beschrieben, nicht mehr
ausreicht. Bei den semi-naiven Methoden werden die alternativen Ableitungen des zu löschenden Tupels nicht beachtet. Die Regelmenge muss für die Auswertung stratifiziert werden, so dass die Regeln
einer Schicht nur von den unteren Schichten abhängig sind. Für jede Schicht müssen dann die einzelnen Schritte des DRed-Algorithmus angewendet werden.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
43
Der Algorithmus besteht aus drei Phasen:
1. Es wird eine obere Abschätzung der zu löschenden Tupeln berechnet, wobei ein Tupel t in
dieser Menge ist, wenn die Veränderungen der Basisrelationen nur ein einziges Vorkommen
des Tupels t ungültig machen.
2. In der oberen Abschätzung werden alle Tupel gelöscht, die ein alternatives Vorkommen in der
neuen Datenbank haben.
3. Alle neuen Tupel, die eingefügt werden müssen, werden mit der zum Teil veränderten materialisierten Sicht berechnet. Danach werden die Veränderungen in die Basisrelationen eingetragen.
Diese drei Schritte sind ausführlich in [GMS92] dargestellt und geprüft. Bei der Stratifikation befinden
sich alle Basis-Tupel in der Schicht 0. Jedes abgeleitete Prädikat in der Schicht i ist nur von den
Prädikaten in den unteren Schichten, also 1, . . . , i − 1 abhängig. Bei den Änderungen in der Schicht
i werden nur die Schichten mit SN ≥ i betrachtet. Dieser Transformationsvorgang wird nachfolgend
genauer beschrieben:
• Lösche eine Obermenge der abgeleiteten Tupel, die gelöscht werden müssen. Für jede Regel r
der Form
(r) : p : − s1 , . . . , si , . . . , sn
erzeuge n ∆− -Regeln der Form
−
−
(∆−
i (r)) : δ (p) : − s1 , . . . , si−1 , δ (si ), si+1 , . . . , sn
Wenn si Basisrelation ist, dann ist δ − (si ) die gegebene Menge zu löschender Tupel. Ist si
schon in einer vorherigen Schicht berechnet worden, so sind in δ − (si ) die wirklich gelöschten
Tupel von si enthalten, d.h. δ − (si ) ist keine Abschätzung. Sonst ist δ − (si ) die momentane Abschätzung der zu löschenden Tupel, die durch diese Regeln ermittelt wurde. Mit si werden die
bisherigen Relationen bezeichnet, ohne die aktuellen Veränderungen zu berücksichtigen. Dies
gilt auch für die Basisrelationen und die in den vorherigen Schichten ausgewerteten Relationen.
Die ∆− -Regeln werden solange angewendet, bis ein Fixpunkt erreicht ist.
• Füge die Tupel mit alternativen Ableitungen wieder ein. Erzeuge für jede Regel r eine ∆r Regel:
(∆r ) : δ + (p) : − δ − (p), sνi , . . . , sνn
Dabei ist δ − (p) die in Schritt 1 berechnete Menge von Tupeln. Für sνi ist der jeweils aktuelle
Wert, der in Schritt 1 und 2 bisher berechnet wurde, bzw. der neue gegebene Wert der Basisrelation einzusetzen. Die ∆r -Regeln sind solange anzuwenden, bis ein Fixpunkt erreicht ist.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
44
• Nur dann anwenden, wenn in den Basisrelationen Tupel eingefügt worden sind. Erzeuge für
jede Regel r, n ∆+ -Regeln der Form:
+
ν
+
ν
(∆+
i ) : ∆ (p) : − s1 , . . . , ∆ (si ), . . . , sn
∆+ (si ) ist der aktuelle Stand bzw. die Änderungen der Basisrelationen. Dies entspricht dem Ergebnis aus Schritt 1 und 2 und den aktuellen Änderungen. Auch diese ∆+
i -Regeln sind solange
anzuwenden, bis ein Fixpunkt erreicht ist.
Beispiel:
Wir betrachten wieder die Basisrelation link und die Sicht hop:
1. Obere Schätzungsmenge = {ae, ac}
2. (ac) wird aus der oberen Schätzung entfernt
3. (df ) wird dem Graphen hizugefügt
4. Entfernung der Knoten aus der Abschätzungsmenge des Graphen
Für eine effiziente Auswertung mit diesem Algorithmus müssen nicht nur die Sichten, sondern alle abgeleiteten Daten materialisiert sein, also auch die Zwischenergebnisse bei der Berechnung der
Sichten.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
4.2
45
Die CW-Methode
Die Methode von Ceri/Widom dokumentiert eine der wenigen Methoden, die sich explizit mit dem
Problem der inkrementellen Sichtenaktualisierung für SQL-basierte Datenbanksysteme beschäftigt.
Dieses Propagierungsverfahren ist für ableitbare Änderungen entwickelt worden. Ceri und Widom
generieren in ihrer Methode aus einer Sicht sogenannte Produktionsregeln (production rules), um die
Anpassung der materialisierten Sichten durchzuführen. Es wird eine Untermenge der SQL-Sprache
mit einigen Einschränkungen als Sichtendefinitionssprache verwendet: Disjunktion der Prädikate ist
nicht zugelassen; Unterabfragen sind auf nur eine Schicht beschränkt; Mengenoperatoren dürfen nicht
kombiniert auftreten (minus wird hier nicht verwendet) und die Verwendung aller Vergleichsoperatoren mit all ist auch nicht erlaubt.
Starburst ist das Basissystem dieser Methode. Starburst ist ein aktives Datenbanksystem, das mit
Produktionsregeln bei bestimmten Ereignissen oder Datenbankzuständen Datenmanipulationsoperationen ausführen kann. Hier werden die aktiven Regeln implementiert, um bei den Einfüge- und Löschoperationen auf den Basisrelationen, die abgeleiteten materialisierten Sichten zu aktualisieren. Vor
der Regelerzeugung werden aus den gegebenen Sichten Trigger (Starburst-Trigger) generiert, die induzierte Änderungen ableiten. Die Trigger übernehmen die Steuerung der Ausführung des iterierten
Fixpunktprozesses für die Änderungspropagierung. In diesem Verfahren sind auch Lösungen für die
Propagierung von Modifikationen entwickelt worden.
Ceri und Widom stützen sich in ihrer Arbeit auf die Schlüsselinformationen der Tabellen, mit deren
Hilfe werden u.a. keine Duplikate in ihrem bottom-up-Propagierungsprozess zugelassen. Die Methode analysiert zunächst die Sichtdefinition 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,
dass eine Anpassung nicht effizient möglich ist, so wird dem Benutzer dies mitgeteilt, und er kann
anschließend die Definition der Sicht 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. Die Abbildung 4.2 zeigt die Struktur des Ceri/WidomVerfahrens. Dieser Ablauf wird beim Compilieren aufgerufen, wenn eine Sicht erzeugt wird. Wenn
Änderungen auftreten, wird die Sicht-Analyse wiederholt.
Sichten, die Duplikate enthalten können, sind ebenfalls nicht erlaubt, da die Delete-Operation in SQL
nicht nur 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
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
46
Abbildung 4.2: Regel-Ableitung-System
vorkommen, so führen Löschungen in den Unteranfragen zu Einfügungen in der Sicht und umgekehrt.
4.2.1
Syntax und Semantik der Produktionsregeln
Die Produktionsregel-Sprache, die hier angewendet wird, basiert auf dem Starburst-Datenbanksystem,
das im Kapitel 2 vorgestellt wurde. Die Sichten werden durch bestimmte Einschränkungen spezialisiert. Ein wesentlicher Punkt ist dabei die Verwendung der Schlüsselattribute. Es werden nur Änderungen von Relationen inkrementell propagiert, deren Schlüsselattribute auch in der Attributsliste der
Sicht auftreten und deren Werte unverändert sind. Daraus folgt, dass der Effektivitätstest auf den Duplikattest der während der Transaktion geänderten Fakten beschränkt wird. Die Syntax der Erzeugung
von Produktionsregeln ist wie folgt definiert:
CREATE RULE <Regelname> ON <Relationname> WHEN
INSERTED | DELETED | UPDATED [(Attributname)]
[IF <SQL-Prädikat>] THEN <SQL-Ausdruck>
[PROCEDES <Regelname>]
[FOLLOWS <Regelname>]
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
47
Jede Regel hat einen eindeutigen Namen (<Regelname>) und ist mit einer spezifischen Relation (<Relationname>) assoziiert. Jede Regel überwacht ein oder mehrere Ereignisse (also die triggernden Operationen der Regel); andererseits kann ein SQL-Ausdruck, z.B. INSERT, auf ein und derselben Relation von mehreren Regeln überwacht werden. Die Ausführungsreihenfolge der Regeln ist hierbei durch
eine partielle Ordnung gegeben: zur Regelerzeugungszeit ist es möglich zu sagen, welche Regeln vor
oder nach einer gegebenen Regel folgen sollen (wenn das entsprechende Ereignis auftritt). Die Beziehung der Rangfolge, die durch die Ausdrücke PRECEDES und FOLLOWS eingeführt wird, muss
aber azyklisch sein.
Regeln in Starburst werden im Zusammenhang mit Transaktionen ausgeführt. Die Regelausführung
wird implizit gestartet, jedoch nur, wenn die Transaktion mit einem COMMIT Befehl endet; dieses
nennt man die Deferred-Ausführung. Falls jedoch die Transaktion mit einem ROLLBACK Befehl
endet, wird die Regelausführung nicht gestartet.
Eine Regel ist entweder getriggert oder ungetriggert (d.h. markiert, um ausgeführt zu werden oder
nicht markiert); sie ist ungetriggert zu Beginn der Transaktion und sie wird getriggert, wenn eines
ihrer triggernden Ereignisse auftritt. Alle von jeweils einer Transaktion getriggerten Regeln bilden
zusammen eine Konfliktmenge.
Algorithmus: Regelausführung
Der Regelausführungsalgorithmus von Starburst besteht aus folgenden Schritten, die iteriert ausgeführt werden:
Solange die Konfliktmenge menge von T nicht leer ist
1. wähle eine Regel R mit höchster Priorität aus der Konfliktmenge von T aus; R’s Zustand wird
als ungetriggert bezeichnet (d.h. R wird aus der Konfliktmenge von T entfernt).
2. werte die Bedingung von R aus
3. wenn R’s Bedingung WAHR ist, dann führe die zugehörige Aktion von R aus (dabei kann R
wieder getriggert werden).
Die Auswahl der Regeln im ersten Schritt des Algorithmus liefert eine der Regeln mit höchster Priorität (d.h. eine Regel der Konfliktmenge, die vor allen anderen Regeln Vorrang hat). Sind die Regeln
partiell vom Benutzer geordnet, so kann es viele Regeln geben, welche die obige Bedingung erfüllen.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
48
Um aber die Wiederholbarkeit der Ausführung garantieren zu können (d.h., das gleiche Systemverhalten auf dem gleichen DB-Zustand bei derselben Transaktion als Eingabe), wird eine totale Ordnung
vom System angegeben, in Erweiterung der vom Benutzer definierten partiellen Ordnung.
Die Ausführung einer Aktion kann zur Auslösung weiterer Regeln führen, einschließlich der Regel,
die gerade ausgeführt wird (d.h. die Regel, die aus der Konfliktmenge entfernt wurde, wird wieder
eingefügt). Somit könnte obiger Algorithmus zu einer unendlichen Ausführung führen, in dem sich
Regeln zyklisch triggern. In diesem Fall spricht man von einer nichtterminierenden Regelausführung.
Die Zusicherung der Terminierung ist das Hauptproblem beim Modellieren aktiver Regeln. Terminiert
hingegen die Regelausführung (d.h. die Konfliktmenge wird leer), so bezeichnet man den zugehörigen
DB-Zustand als den Ruhezustand (engl.: Quiescent State). Werden weitere Regeln bei der Regelausführung getriggert, werden diese der Konfliktmenge hinzugefügt und ihre Abarbeitungsreihenfolge
richtet sich wiederum nach der totalen Ordnung.
Für die exakte Definition, wann eine Regel getriggert ist, benötigen wir die Definition eines Zustandsüberganges; das ist eine Transformation von einem gegebenen DB-Zustand S1 zu einem anderen
Zustand S2 aufgrund der Ausführung von SQL-Operationen durch eine Transaktion5 . Zustandsübergänge sind mittels der Bedeutungen der Mengen inserted, deleted oder updated definiert; diese Mengen beinhalten die Tupel, welche bei der Transformation von Zustand S1 nach S2 jeweils eingefügt,
gelöscht oder geändert wurden. Aus der Menge updated kann man weitere Teilmengen extrahieren,
in denen spezielle Attributwerte geändert wurden.
Regeln betrachten nur die Nettoeffekte der SQL-Operationen zwischen zwei wohldefinierten DBZuständen; den Nettoeffekt erhält man, in dem man verschiedene SQL-Operationen zusammenfasst,
welche das gleiche Tupel betreffen (d.h. im Endeffekt als eine SQL-Operation auffasst). Solch ein
Zusammenfassen wird Nettooperation genannt. Jede nicht leere Nettooperation ist in genau einer der
obigen Mengen inserted, deleted oder updated vermerkt; z.B. ist der Nettoeffekt des Einfügens des
Tupels t gefolgt von seinem Löschen gleich Null (=leere Nettooperation), während das Einfügen eines
Tupels t1 gefolgt von seinem Update von t1 nach t2 , als das Einfügen des Tupels t2 angesehen wird.
Wir sind nun in der Lage zu sagen, ob eine gegebene Regel getriggert wurde: Intuitiv ist eine Regel
getriggert, wenn irgendeine der Mengen (inserted, deleted oder updated), welche zu ihrer triggernden
SQL-Operation korrespondiert, nicht leer ist (relativ zu einem gegebenen Zustandsübergang). Bei
der ersten Betrachtung einer Regel R beobachten wir den Übergang vom Anfangszustand S0 einer
Transaktion zu dem Zustand S1 , welcher existiert, wenn R durch den Regelausführungsalgorithmus
ausgewählt wird. Nach der Betrachtung wird R ungetriggert (gleichgültig, ob die Aktion ausgeführt
wurde oder nicht). Um zu bestimmen, ob R in einem späteren Zustand S2 getriggert ist, betrachten
5
Menge von Änderungen, die alle gemeinsam oder überhaupt nicht durchgeführt werden
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
49
wir den Übergang von S1 nach S2 , usw. bis die Regelausführung in einem Ruhezustand Sf terminiert,
in welchem die Regel R und alle anderen Regeln ungetriggert sind.
In dem Bedingungs- oder Aktionsteil einer Regel kann man auch Referenzen auf vorübergehende
Beziehungen setzen, welche die Instanzen der Tupel speichern, die einen Zustandsübergang charakterisieren. Genauer gesagt sind vier Übergangsrelationen definiert: INSERTED, DELETED, OLDUPDATED und NEW-UPDATED. Die INSERTED und DELETED Übergangsrelationen speichern
die Tupel, die zu den oben definierten Mengen inserted und deleted gehören; OLD-UPDATED speichert die Tupel ab, bevor sie geändert werden (in Zustand S1 ), während NEW-UPDATED die Tupel
abspeichert, nachdem sie geändert werden (in Zustand S2 ). Es ist effizienter sich auf Übergangsrelationen zu beziehen, als auf den aktuellen Inhalt der regulären Relationen, da Übergangsrelationen
gewöhnlich klein sind und im Hauptspeicher gehalten werden können.
4.2.2
Sicht-Analyse
In [CW91] wird ausschließlich mit materialisierten Sichten gearbeitet. Anwender definieren Sichten
und spezifizieren eine Menge von Schlüsseln für die Basistabellen, welche viele wichtige Informationen zur Sichtanalyse zur Verfügung stellen. Während der Sichtanalyse wird jede Tabellenreferenz
anhand der Schlüsselinformationen vom System aufgerufen. Für jede Referezmenge werden vom System die bound columns für jede Referez berechnet. Durch die bound columns kann das System
feststellen, welche Tabellenreferenz sicher (safe) ist.
Definition: Bound Columns
Bound columns werden als B(V ) bezeichnet und werden für eine Sicht V
DEFINE VIEW V (Col-List):
SELECT C1 , ..., Cn FROM T1 , . . . , Tm WHERE P
(T1 , ..., Tm sind die Basisrelationen, C1 , . . . , Cn , ihre Spalten und P ist ein Prädikat.)
wie folgt bestimmt:
1. B(V ) wird mit dem Inhalt der Spalten C1 , . . . , Cn der Sichtdefinition initialisiert.
2. Wenn ein Prädikat P in der Sichtdefinition entweder einen äquivalenten Vergleich zwischen
den Spalten oder eine Konstante beinhaltet, werden alle Spalten T1 , . . . , Tm , der Menge B(V )
hizugefügt.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
50
3. Solange B(V ) unverändert bleibt, werden folgende Schritte wiederholt:
• Wenn ein Prädikat P in der Sichtdefinition einen äquivalenten Vergleich zwischen den
Spalten und eine Spalte der B(V ) beinhaltet, werden alle Spalten T1 , . . . , Tm , der Menge
B(V ) hizugefügt.
• Wenn Projektionsteil der Sichtdefinition (SELECT ...) einen Schlüssel einer Refereztabelle beinhaltet, werden alle anderen Spalten der Tabelle in B(V ) aufgenommen.
Definition: Safe Table
Ti ist sicher in V , falls B(V ) einen Schlüssel für Ti enthält.
Durch diese Eigenschaft können Insert-, Delete- und Update-Operationen, die auf Ti ausgeführt werden, inkrementell der Sicht angepasst werden.
Duplikat-Analyse
Die CW-Methode kann Sichten, die Duplikate beinhalten, nicht effizient anpassen. Falls in einer Sichtdefinition die DISTINCT6 -Anweisung, nicht vorkommt, wird eine Duplikat-Analyse durchgeführt. In
[BLT86] werden zwei Lösungen für das Duplikat-Problem vorgestellt: In der ersten Lösung muss eine
Extraspalte der Sicht eingefügt werden, in der die Anzahl des Vorkommens jedes Tupels gespeichert
wird. Diese Lösung wird aufgrund der Komplexität für die Regelgenerierung in [CW91] nicht verwendet. In der zweiten Lösung wird behauptet: Wenn jede Sicht Schlüsselspalten der Basistabellen
beinhaltet, kommen keine Duplikate mehr vor. In [CW91] wird die zweite Lösung bevorzugt, dabei
benutzt das System bound columns für die Tabellen um festzustellen, ob die Sicht Duplikate enthält.
4.2.3
Regelgenerierung und Änderungspropagierung
Änderungen werden in [CW91] mengenorientiert ausgeführt, d.h. sie werden als Transaktionen durchgeführt. Eine SQL-Transaktion ist eine Sequenz von Basisfaktenänderungen, deren Ausführung eine
Sequenz von Zwischenzuständen erzeugt. In dem Compilierungsteil werden aus Sichten Trigger generiert, die Änderungen absetzen:
compilieren
Sichten −−−−−−−→ Trigger
6
Distinct eliminiert Duplikate in SQL
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
51
Abbildung 4.3: Propagierungsverfahren bei der CW-Methode
Trigger sind interne Systemkomponenten, die durch Ausführung von Änderungen aktiviert werden.
Die Regelaktivierung ist ein iteriertes Verfahren, das immer wieder berechnet wird. Dieser Propagierungsprozess terminiert, wenn mittels Triggern keine neuen Fakten mehr abgeleitet werden können
oder wenn keine neuen Trigger gefeuert werden. In diesem Unterkapitel wird die Regelgenerierung
für die Basistabellenänderungen eingeführt, die in [CW91] vorgestellt wird. Die Regeln werden bei
Einfügung, Löschung und Modifikation getriggert. Im allgemeinen werden Modifikationen jedoch als
Einfügung eines Fakts mit den neuen Werten und als Löschung des Fakts mit den alten Werten behandelt. Bei Ceri/Widom werden sie beim ersten Propagierungsschritt auch in induzierte Einfügungen
und Löschungen aufgespalten.
Die folgenden Produktionsregeln beschreiben die erforderlichen Aktionen, wenn in der Relation Ti
neue Werte eingefügt bzw. gelöscht werden:
CREATE RULE ins-Ti -V
WHEN inserted into Ti
THEN insert INTO V (SELECT C1 , ..., Cn
FROM T1 ,...,inserted Ti ,...,Tm
WHERE P and <C1 , ..., Cn > not in inserted V )
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
52
CREATE RULE del-Ti -V
WHEN deleted FROM Ti
THEN delete FROM V
WHERE <C1 , ..., Cn > in (SELECT C1 , ..., Cn
FROM old T1 ,...,deleted Ti ,...,old Tm
WHERE p-old)
Old-T bezeichnet dabei den Zustand der Relation T vor der Änderung, inserted/deleted-T enthält
nur die eingefügten (gelöschten) Tupel und T steht für die aktuelle Relation, also einschließlich der
Einfügungen und ohne die gelöschten Tupel.
Update-Operationen der Basisrelationen verursachen immer Delete- und/oder Insert-Operationen an
Sichten. Es werden zwei Regeln bei update getriggert, eine, die das Einfügen durchführt, und eine
zweite, die das Löschen von Tupeln vornimmt:
CREATE RULE old-upd-Ti -V
WHEN updated Ti
THEN delete FROM V
WHERE <C1 , ..., Cn > in (SELECT C1 , ..., Cn
FROM old T1 ,...,old updated Ti ,...,old Tm
WHERE p-old)
CREATE RULE old-upd-Ti -V
WHEN updated Ti
THEN delete FROM V
WHERE <C1 , ..., Cn > in (SELECT C1 , ..., Cn
FROM old T1 ,...,old updated Ti ,...,old Tm
WHERE p-old)
Wenn eine Tabelle mehrmals in der Liste der Referenzen vorkommt, werden die Regeln für jede
Referenz generiert. Die Auswertungsreihenfolge der Regeln ist nicht beliebig: zunächst müssen alle
Löschregeln bearbeitet werden und dann alle Einfügeregeln. Allerdings gibt es keine vorgeschriebene
Reihenfolge zwischen den Regeln von verschiedenen Sichten, so dass Sichten nur Basisrelationen
referenzieren können, damit die Auswertung korrekt bleibt.
Bei der Propagierung wird für Residuenauswertungen (T1 , . . . , Ti−1 und Ti+1 , . . . , Tm ) und Effektivitätstests (not in inserted V ) auf unterschiedliche DB-Zustände zugegriffen, so müssen einzufügende
Fakten im neuen Zustand abgeleitet werden und zu löschende im alten ableitbar sein. Die Entscheidung, welcher Zustand simuliert wird, wird durch die beiden Zeitpunkte der Ausführung der Basisfak-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
53
tenänderung und der Propagierung bestimmt. Bei Ceri/Widom wird ein optimistischer Ansatz zugrunde gelegt. Zuerst werden die Basisfaktenänderungen ausgeführt und anschließend die Propagierung.
Dann muss der alte Zustand simuliert werden.
In [CW91] ist keine Rekursion zugelassen und bei Löschungen werden keine Effektivitätstests durchgeführt. Aus diesen Gründen werden bei der Verwendung der Transitionsregeln keine Stratifikationsprobleme vorkommen. Der Duplikattest, der während der Transaktion geänderten Fakten durchgeführt
wird, sorgt dafür, dass nichtrekursive Regeln stratififizierbar sind.
Unsichere Referenztabellen enthalten keine Schlüssel der Tabellen. In diesem Fall ist die inkrementelle Anpassung der Sichten für Einfüge-Operationen stets möglich. Der einzige Unterschied ist, dass für
alle neuen Tupel Duplikattest durchgeführt werden müssen. Für Änderungen, die nicht inkrementell
verarbeitet werden können, werden Rematerialisierungstrigger generiert. Die zugehörige Regel sieht
wie folgt aus:
CREATE RULE rematerialize-V
WHEN deleted FROM Ti , UPDATED Ti
THEN delete FROM V ;
insert into V (SELECT C1 , . . . , Cn
FROM Ti ,. . . ,old Tm WHERE P );
deactivate-rules(V )
Beispiel
Ein Beispiel für eine airline-reservation-Datenbank, die folgende Basistabellen enthält:
flight (FLIGHT-ID, flight-no, date)
res (RES-ID, pagr-id, flight-id, seat)
psgr (PSGR-ID, name, phone, meal, ffn)
ff (FFN, miles)
ff bezeichnet frequent flier, und ffn die frequent flier number. Die Sicht special-meals stellt die SitzNummer und das Menü jedes Passagiers für einen bestimmten Flug zur Verfügung:
DEFINE VIEW special-meals(seat, meal):
SELECT res.seat, psgr.meal
FROM res, psgr
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
54
WHERE res.flight-id = FID and res.psgr-id = psgr.psgr-id
and psgr.meal != null
Die Menge der bound columns, ist
B(V) = {res.seat, psgr.meal, res.flight-id, res.psgr-id,
psgr.PSGR-ID, res.RES-ID},
da B(V ) die Schlüssel der beiden Referenztabellen enthält, wird die Sicht keine Duplikate enthalten
und inkrementelle Anpassungsregeln können für beide Tabellen generiert werden. Die Regeln, die bei
Insert- und Delete-Operation getriggert werden, lauten wie folgt:
CREATE RULE ins-res-special-meals
WHEN inserted INTO res
THEN insert INTO special-meals (SELECT res.seat, psgr.meal
FROM inserted res, psgr
WHERE res.flight-id = FID AND res.psgr-id = psgr.psgr-id
AND psgr.meal != null AND <seat,meal>
NOT IN inserted special-meals)
CREATE RULE del-res-special-meals
WHEN deleted FROM res
THEN delete FROM special-meals
WHERE <seat,meal> IN (SELECT res.seat, psgr.meal
FROM deleted res, old psgr
WHERE res.flight-id = FID AND res.psgr-id = psgr.psgr-id
AND psgr.meal != null)
Die erste Regel beschreibt den Fall für Einfügungen in die Relation res. Die Menge der eingefügten
Reservierungen wird mit der aktuellen Menge der Passagiere per Join verbunden. Die Joinbedingungen sind gegenüber der Sichtendefinition unverändert. Der dritte Teil der WHERE-Klausel stellt
sicher, dass das gefundene Tupel nicht schon durch eine andere Regel in die Sicht eingefügt worden
ist.
Die Löschungen von res werden durch die zweite Regel behandelt. Hier wird der Join zwischen der
Menge der gelöschten Reservierungen und der alten Menge der Passagiere festgesetzt. Die Joinbedingung bleibt auch hier unverändert.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
55
Wie schon erwähnt, wird eine Modifikation eines Tupels als Löschen und Einfügen modelliert. Die
Regeln für ein Update der Relation res entsprechen also im wesentlichen den beiden oberen Regeln:
CREATE RULE old-upd-res-special-meals
WHEN updated res
THEN delete FROM special-meals
WHERE <seat,meal> IN (SELECT res.seat, psgr.meal
FROM old updated res, old psgr
WHERE res.flight-id = FID AND res.psgr-id = psgr.psgr-id
AND psgr.meal != null)
CREATE RULE new-upd-res-special-meals
WHEN updated res
THEN insert INTO special-meals (SELECT res.seat, psgr.meal
FROM new updated res, psgr
WHERE res.flight-id = FID AND res.psgr-id = psgr.psgr-id
AND psgr.meal != null AND <seat,meal>
NOT IN inserted special-meals)
In dem letzten Teil der Bedingung wird der Duplikattest im neuen Zustand der Datenbank durchgeführt, da im neuen Zustand Tupel durch andere Regeln neu eingefügt werden können.
Die Regeln für alle Änderungen bei der Relation psgr sind analog.
4.2.4
Regelgenerierung in positiv verschachtelten Unterabfragen
Ceri/Widom führen einige Einschränkungen in Bezug auf verschachtelte SELECT-Anweisungen ein,
z.B. sind nur einschichtige Unterabfragen erlaubt. Unterabfragen mit exists, in oder Comp any (< any,
<= any, >= any) können verwendet werden.
Eine verschachtelte Sicht kann wie folgt aussehen:
DEFINE VIEW V (Col-List):
SELECT C1 , . . . , Cn FROM T1 , . . . , Tm
WHERE P 0 AND exists (SELECT Cols FROM N1 , . . . , Nl
WHERE P )
Wobei N1 , . . . , Nl die Referenztabellen darstellen.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
56
Correlated bound columns für sichere Sichtenanalyse in positiv verschachtelten Unterabfragen
Correlated bound columns wird als C(V ) bezeichnet und hängt mit der Menge B(V ) der Ti zusammen. Für Sichten mit exists-Unterabfragen wird C(V ) wie folgt berechnet:
1. C(V ) wird mit dem Inhalt der Spalten N1 , . . . , Nl initialisiert, so dass das Prädikat P einen
äquivalenten Vergleich zwischen einer Spalte und einer Spalte in B(V ) enthält.
2. Wenn das Prädikat P einen äquivalenten Vergleich zwischen Spalten oder eine Konstante enthält, werden alle Spalten N1 , . . . , Nl der Menge C(V ) hinzugefügt.
3. Solange C(V ) unverändert bleibt, werden folgende Schritte wiederholt:
• Wenn ein Prädikat P einen äquivalenten Vergleich zwischen einer Spalte und einer Spalte
in C(V ) enthält, werden alle Spalten N1 , . . . , Nl der Menge C(V ) hizugefügt.
• Wenn C(V ) einen Schlüssel für ein Ni enthält, werden alle anderen Spalten der Tabelle
in C(V ) aufgenommen.
Hier gilt auch, dass Referenztabellen Ni sicher sind, wenn C(V ) einen Schlüsseln für Ni enthält.
Nach [BLT86] wird bei dem Duplikattest in verschachtelten Abfragen ein Attribut der Sicht im äußeren Select-Ausdruck genommen und nicht von der Unterabfrage. Um richtige Tupel zum Löschen
zu erkennen, wird bei der Delete-Operation den alten Zustand der Tabelle in der äußeren SelectAnweisung betrachtet, da die Tupel schon modifiziert sein könnten. Regeln, die das Einfügen von
Tupeln generieren, müssen im neuen Zustand der Datenbank ausgeführt werden. Daher werden Ni
durch inserted Ni ersetzt. Beim Löschen von Tupeln wird der alte Wert (old value) der Tabelle genommen. Hier werden Ni durch deleted Ni ersetzt. In beiden Update-Operationen werden auch die
Werte old updated Ni und new updated Ni für Ni benutzt.
Im Fall der unsicheren Relationen wird bei der Insertregel not in V statt not in inserted V bevorzugt.
Hier sind die Trigger-Operationen deleted from Ni und updated Ni in der Rematerialisierungsregel
für V enthalten, da keine Verbindung der Verschachtelungen durch Schlüssel existiert.
Die Sicherheitsanalyse für die anderen Unterabfragen, wie Comp any, funktioniert analog. Dabei
könnte die C(V )-Menge aber größer werden. Hier eine Sichtdefinition für in7 -Unterabfragen:
7
in ist äquivalent zu = any
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
57
DEFINE VIEW V (Col-List):
SELECT C1 , ..., Cn FROM T1 , ..., Tm WHERE P 0
AND <D1 , ..., Dj > in
(SELECT E1 , ..., Ej FROM N1 , ..., Nl WHERE P )
Dabei wird folgender Punkt zur Definition der C(V ) hizugefügt:
• Jede Spalte Ei wird in C(V ) aufgenommen, so dass die korrespondierende Spalte Di in B(V )
existiert, 1 ≤ i ≤ j.
Beispiel
Es werden die Basistabellen des letzten Beispiels betrachtet und eine Sicht definiert, die IDs für alle
Passagiere zur Verfügung stellt, die über 50.000 frequent flyer-Meilen haben:
DEFINE VIEW many-miles(id):
SELECT psgr-id FROM psgr
WHERE psgr.ffn IN (SELECT ffn FROM ff WHERE miles > 50,000)
Da FFN der Primär-Schlüssel der Tabelle ff ist, werden nach Definition für C(V ) alle restlichen
Spalten von psgr-Relation auch in C(V ) aufgenommen, und daher ist ff eine sichere Tabellenreferenz:
C(V) = {ff.FFN, ff.miles, psgr.psgr-ID, psgr.name, psgr.phone,
psgr.meal}
CREATE RULE ins-ff-many-miles
WHEN inserted INTO ff
THEN insert INTO many-miles (SELECT psgr.id FROM psgr
WHERE psgr.ffn IN (SELECT ffn FROM inserted ff
WHERE miles > 50,000 AND psgr-id NOT IN inserted many-miles)
CREATE RULE del-ff-many-miles
WHEN deleted FROM ff
THEN delete FROM many-miles
WHERE psgr-id IN (SELECT psgr-id FROM old psgr
WHERE psgr.ffn IN (SELECT ffn FROM deleted ff
WHERE miles > 50,000))
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
58
Negativ verschachtelte Unterabfragen
Eine negativ verschachtelte Select-Anweisung wird durch die Schlüsselwörter: not exists, not in und
! = any gebildet. Insert-Operationen für verschachtelte Tabellen bei negativen Abfragen entsprechen
den Delete-Operationen in der Sicht. Genauso werden Delete-Operationen in verschachtelten Tabellen
Insert-Operation in der Sicht zur Folge haben. In [CW91] wird eine Sichtdefinition für not exists
betrachtet:
DEFINE VIEW V (Col-List):
SELECT C1 , ..., Cn FROM T1 , ..., Tm WHERE P 0
AND not exists (SELECT COLs FROM N1 , ..., Nl
WHERE P )
Für die negativ verschachtelte Select-Anweisungen werden in [CW91] zwei Arten der Sicherheitsanalyse von not exists für den Insert- und Delete-Update-Fall vorgestellt:
• Insert-Sicherheit (I-Safety): not exists-Unterabfragen sind I-safe in V , falls das Prädikat P sich
nur auf Spalten in Ni , 1 ≤ i ≤ j, Spalten in B(V ) und Konstanten bezieht.
• Delete-Update-Sicherheit (DU-Safety): not exists-Unterabfragen sind DU-safe in V , falls sie
I-safe sind, und C(V ) einen Schlüssel für Ni enthält.
Der Unterschied zwischen beiden Definitionen liegt darin, dass DU-Safety einen Schlüssel der Unterabfrage verlangt. Wenn Ni nicht I-safe wäre, dann sollte der Sicht-Ausdruck neu ausgewertet werden,
um die zu löschenden Tupel festzustellen.
Wir betrachten hier die Regelgenerierung für Delete-Operationen im negativ verschachtelten-Fall:
CREATE RULE del-Ni -V
WHEN deleted FROM Ni THEN insert INTO V
(SELECT C1 , ..., Cn FROM T1 , ..., Tm WHERE P 0
AND exists (SELECT COLs FROM old N1 ,..., deleted Ni ,...,old Nl
WHERE P ) AND <C1 , ..., Cn > NOT IN inserted V )
Der aktuelle Wert der Ni -Referenzen wird aus zwei Gründen genommen, Erstens können diese Nebentabellen auch Sichten sein, die durch Wirkung der Operationen auch geändert werden. Zweitens
kann die Operation Teil einer Transaktion sein, die andere parallellaufende Operationen durchführt.
Diese Operationen können auch die Tabellen N1 , ..., Nl beeinflussen.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
59
Obwohl die Delete-Operation Löschungen von Tupeln vornimmt, wird hier ein Duplikattest durchführt, weil der Aktionsteil der Regel eine Insert-Operation enthält und bei Insert-Operationen, wie wir
gesehen haben, wird immer ein Duplikattest vorgenommen, so kann die inkrementelle Anpassung für
Delete ausgeführt werden. Wie wir sehen, wird not exists in der Delete-Regel in exists umgeschrieben,
dies tritt bei Update-Operationen auch auf. Im unsicheren Fall wird in der oben gezeigten Regel not
in V statt not in inserted V bevorzugt.
In der CW-Methode wird behauptet, dass diese Methode auch materialisierte Sichten, die Mengenoperatoren wie union distinct oder intersect enthalten, inkrementell anpassen kann. Für diese Art
von Sichten werden Sicht-Analyse und Regelgenerierung für jede Komponente der Select-Anweisung
durchgeführt.
4.3
Die Magic Updates-Methode
Das Verfahren von Manthey ist datalogbasiert und verwendet einen iterativen, mengenorientierten Inferenzprozess (Fixpunktiteration) zur inkrementellen Sichtenanpassung. Die Änderungen werden im
Sinne der deterministischen Änderungstransaktionen durchgeführt. Dieses bottom-up-Änderungspropagierungsverfahren ist ein deduktiver Ansatz, der auch wie in [GMS93] Delta-Regeln8 zur Änderungspropagierung verwendet. Änderungspropagierung dient zur Bestimmung relevanter ableitbarer
Fakten (Antworten und Zwischenergebnisse), die Änderungen der Basisrelationen auf Sichten induzieren. Diese sogenannten echten induzierten Änderungen werden mittels der DBS-internen Deduktionskomponente (Deduktionsregel) abgeleitet (passive Implementierung). Die Methode verwendet
einen internen Regel-Compiler, der alle Propagierungsschritte mit Hilfe von Delta-Regeln kodiert.
Diese Regeln werden als Hilfsrelationen verwendet und protokollieren die Basisrelationänderungen
und induzierte Änderungen (Abbildung 4.5).
Änderungen in [Man03] beschränken sich auf Einfügung und Löschung der Fakten. Modifikationen
lassen sich äquivalent durch kombinationen von Einfügung und Löschung ausdrucken. Manthey lässt
auch Rekursion und sichere stratifizierte Negation, sowie Aggregation in seiner Methode zu. Bei der
Ableitung können auch Duplikate auftreten. Genauer gesagt, werden durch Vereinigung der Propagierungsregeln und durch Projektion der Prädikate Mehrfachableitungen eines Fakts produziert.
Änderungspropagierung ist eine spezielle Form des Vorwärtsschließens, die in der Abbildung 4.4
veranschaulicht wird. Gegeben sind Änderungen, die für ein Literal im Regelrumpf unifizierbar sind.
In dem Propagierungsschritt werden drei Phasen durchgeführt:
8
Hier: Propagierungsregel
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
60
Abbildung 4.4: Regel-Compilierung
1. Matching: Änderungsliteral mit passendem Rumpfliteral
2. Residuenauswertung: Auswertung des/der Restliterals/e im Rumpf
3. Propagierung: Weitergabe der Variablenbindungen an den Kopf und Kombinieren des Kopfliterals mit dem Vorzeichen der Änderung
Ein Problem bei der Residuenauswertung sind die Seiteneffekte, d.h. es können Einflüsse der Basisänderung sichtbar werden. Daraus folgt, dass diese Auswertungen auf unterschiedlichen Datenbank-
Abbildung 4.5: Struktur der Änderungspropagierung in der Magic Updates-Methode
Zuständen erfolgen müssen. Änderungsoperationen, die in dieser Methode betrachtet werden, umfassen nur Einfügung und Löschung der Fakten für Basisrelationen.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
61
Die zentrale Idee der Methode ist, dass zwei temporäre, interne Relationen für (induzierte) Einfügungen bzw. Löschungen erzeugt werden. Dabei erfolgen die Änderungen der Basisrelationen als Fakten
und abgeleitete Relationen sind Herleitungsregeln für Änderungen. Weiterhin werden zu jeder Relation p (bzgl. aktueller Änderung) Relationen, die den Zustand von p vor bzw. nach der Änderung
simulieren, erzeugt. Dabei entspricht pnew der Relation p nach den Änderungen, und pold bezeichnet
p vor den Änderungen. Der Zusammenhang wird durch folgende Formel beschrieben:
pnew = (pold − p− ) ∪ p+
Diese Methode basiert auf einem pessimistischen Ansatz, bei dem der Vorzustand erhalten bleibt (old
entfällt) und der Nachzustand simuliert wird. Die Abarbeitung von Änderungen erfolgt dabei in drei
Schritten:
• Vollständige Auswertung des Bedingungsteils über dem aktuellen Zustand resultierend in Faktenmenge δ[U ](F ).
• Eliminierung aller redundanten Änderungen resultierend in reduzierter Faktenmenge ∆[U ](F ).
• Simultane Anwendung aller verbleibenden echten Änderungen auf F old resultierend im neuen
Zustand (Faktenmenge) F new =def τ [U ](F ).
Für U ≡ ±A WHERE B1 , ..., Bn werden die drei Schritte wie folgt definiert:
• Bedingungsauswertung:
δ[U ](F ) =def {Aσ|σ ist eine konsistente Substitution und ∀1 ≤ i ≤ n Bi σ ∈ F ∗ }
• Eliminierung redundanter Änderungen: ∆[U ](F ) =def :
δ[U ](F ) − F, falls U Einfügung ist
δ[U ](F ) ∩ F, falls U Löschung ist
• Simultane Anwendung echter Änderungen: τ [U ](F ) =def :
F ∪ ∆[U ](F ), falls U Einfügung ist
F − ∆[U ](F ), falls U Löschung ist
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
62
Dabei formalisiert die Transition τ den Effekt eines individuellen Zustandsübergangs auf die Basisdaten:
τ
F old = F −
→ F new = τ [U ](F )
4.3.1
Ein Beispiel zur Änderungspropagierung
Gegeben:
R:
• virtuell:
kzyklisch ←− s(X) s(X) ←− p(X, X)
• materialisiert:
p(X, Y ) ←− k(X, Y ) p(X, Y ) ←− k(X, Z), p(Z, Y )
F : {k(1, 2), k(2, 3), k(3, 4)}
F∗ : {p(1, 2), p(2, 3), p(3, 4), p(1, 3), p(2, 4), p(1, 4)}
k: {1, 2, 3, 4}
I: constraint not k− zyklisch
∆ (Menge der positiven Propagierungsregeln):
R+
k− zyklisch+ ←− s+ (X)
s+ (X) ←− p+ (X, X)
p+ (X, Y ) ←− k + (X, Y ), not p(X, Y )
p+ (X, Y ) ←− k + (X, Z), p(Z, Y ), not p(X, Y )
p+ (X, Y ) ←− k(X, Z), p+ (Z, Y ), not p(X, Y )
p+ (X, Y ) ←− k + (X, Z), p+ (Z, Y ), not p(X, Y )
U1 (Menge der Änderungen): {+k(4, 1)}
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
63
Fixpunktiteration:
k + (4, 1)
=⇒ {p+ (4, 1), p+ (4, 2), p+ (4, 3), p+ (4, 4)}
=⇒ {p+ (3, 1), p+ (3, 2), p+ (3, 3), s+ (4)}
=⇒ {p+ (2, 1), p+ (2, 2), s+ (3), k− zyklisch+ }
=⇒ {p+ (1, 1), s+ (2)}
=⇒ s+ (1)
Damit Mehrfachableitungen durch Vereinigung und Projektion (vor der Einfügung) vermieden werden, ist es erforderlich, in die Delta-Regeln noch einen Effektivitätstest (Test auf Ableitbarkeit im
alten Zustand) durchzuführen. Ein solcher Effektivitätstest ist aber nur erforderlich, falls die jeweilige
Relation durch mehrere Regeln definiert ist (Vereinigung) oder wenn ihre definierende Regel lokale
Variablen enthält (Projektion).
Effektivitätstests bei Vereinigungs- bzw. Projektionsregeln müssen auf dem neuen Datenbank-Zustand
durchgeführt werden. Im alten Zustand sind die potenziell gelöschten Fakten schon aufgrund des
Aufbaus der Delta-Regeln erfüllt. Im neuen Zustand können aber alternative Ableitungsmöglichkeiten
entweder überlebt haben oder durch gleichzeitige Einfügungen neu geschaltet worden sein.
Negative Propagierungsregeln sind nicht ganz analog:
∆:
R−
p− (X, Y ) ←− k − (X, Y ), not pnew (X, Y )
p− (X, Y ) ←− k − (X, Z), p(Z, Y ), not pnew (X, Y )
p− (X, Y ) ←− k(X, Z), p− (Z, Y ), not pnew (X, Y )
U2 : {−k(2, 3)}
k − (2, 3)
=⇒ {p− (2, 3), p− (2, 4)}
=⇒ {p− (1, 3), p− (1, 4)}
pnew : {p(1, 2), p(3, 4)}
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
64
Effektivitätstests bei Einfügungen werden auf dem alten Zustand der DB durchgeführt (vor Ausführung der jeweiligen Änderungen). Löschungen werden auf dem neuen Zustand der DB durchgeführt
(nach Änderungen). Werden Einfügungen und Löschungen kombiniert, müssen beide Zustände simultan zur Verfügung stehen. Simulieren bedeutet dann, dass zunächst für jede Basisrelation der neue
Zustand durch eine abgeleitete Transitionsregel definiert wird, deren Definition sich aus der Gleichung F new = (F old − F − ) ∪ F + ergibt. Das heißt, erhalte den alten Zustand und simuliere den
neuen Zustand. Die Menge der Transitions- und Propagierungsregeln wird wie folgt geschrieben:
R0 : p(X, Y ) ←− k(X, Y )
In den Delta- und Transitionsregeln werden für Auswertungen auf dem alten Zustand aus der ursprünglichen Regelmenge R nur noch die p-Regeln benötigt, die als R0 bezeichnet werden:
p(X, Y ) ←− k(X, Z), p(Z, Y )
R∆ :
k− zyklisch+ ←− s+ (X)
s+ (X) ←− p+ (X, X)
p+ (X, Y ) ←− k + (X, Y ), not p(X, Y )
p+ (X, Y ) ←− k + (X, Z), pnew (Z, Y ), not p(X, Y )
p+ (X, Y ) ←− knew (X, Z), p+ (Z, Y ), not p(X, Y )
p− (X, Y ) ←− k − (X, Y ), not pnew (X, Y )
p− (X, Y ) ←− k − (X, Z), p(Z, Y ), not pnew (X, Y )
p− (X, Y ) ←− k(X, Z), p− (Z, Y ), not pnew (X, Y )
Rτ : pnew (X, Y ) ←− k new (X, Y )
pnew (X, Y ) ←− k new (X, Y ), pnew (Z, Y )
k new (X, Y ) ←− k(X, Y ), not k − (X, Y )
k new (X, Y ) ←− k + (X, Y )
U3 : {−k(2, 3), +k(4, 1)}
{k + (4, 1), k − (2, 3)}
=⇒ {p+ (4, 1), p+ (4, 2), p− (2, 3), p− (2, 4)}
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
65
=⇒ {p+ (3, 1), p+ (3, 1), p− (1, 3), p− (1, 4)}
Mit dem Beispiel läßt sich folgendes nachvollziehen:
Die Residuenauswertung in einer Propagierungsregel muss bei Einfügungen im neuen und bei Löschungen im alten Zustand erfolgen. Der Effektivitätstest dagegen erfolgt bei Einfügungen im alten
und bei Löschungen im neuen Zustand.
Die Residuenauswertung fällt weg, wenn die zugrundeliegenden Regeln reine Projektions- oder Vereinigungsregeln sind (denn dann bestehen die Rümpfe nur aus einem Literal). Effektivitätstests entfallen, wenn die jeweilige Relation durch nur eine Regel ohne lokale Variablen definiert ist: Durchschnitt,
Theta-Join, Kreuzprodukt, Differenz. Daraus folgt:
Rupdate = R∆ ∪ Rτ ∪ R0
Negative Änderungspropagierung / Rekursion
In [Man03] wird sichere Negation vorausgesetzt, damit eine sinnvolle Auswertung der Regeln überhaupt mölich ist. Änderungspropagierung durch negative Literale erfolgt im Prinzip genauso wie
durch positive Literale. Einziger Unterschied ist, dass im dritten Schritt der Propagierung das invertierte Vorzeichen an die induzierten Änderungen weitergegeben wird.
p(X) ←− q(X, Y ), not r(Y )
Änderungen : +p(2), −r(3)
F old : {q(1, 2), r(1), q(1, 3), q(2, 3)}
Propagierungsregel (Löschungsregel):
p+ (X) ←− q(X, Y ), r− (Y ), not pnew (X)
Rekursive Regeln müssen immer mit mindestens einer nichtrekursiven Regel für dieselbe Relation
kombiniert werden. Ein Problem kommt in allen geprüften rekursiven Beispielen vor: Delta-Regeln
sind bei Rekursion stets unstratifizierbar, wenn in einem Rekursionszyklus eines Abhängigkeitsgraphen eine negative Abhängigkeit auftaucht. In der Manththey-Methode wird auf die Eigenschaft der
lokalen Stratifizierbarkeit zur Lösung dieses Problem verwiesen. Eine Lösung des Problems wurde
auch in [Gri97] vorgeschlagen: Verwendung naiver statt inkrementeller Definition von new für rekursive Relationen. Die naive Definition von pnew für p(X) ←− q(X, Y ), p(Y ) sieht wie folgt aus:
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
66
pnew (X) ←− q new (X, Y ), pnew (Y )
Die äquivalente inkrementelle Definition:
pnew (X) ←− p(X), ¬p− (X)
pnew (X) ←− p+ (X)
4.3.2
Magic Updates
Zur Vermeidung der Materialisierung irrelevanter Fakten bei der Änderungspropagierung wird in
[Man03] die Kombination mit der Magic Set-Transformation vorgeschlagen. Dabei werden für jede
Auswertung regeldefinierter Literale bei der Änderungspropagierung lokale top-down-Auswertungen
durch Magic Set durchgeführt. Dieses Verfahren kann man also als fixpunktbasierte Implementierung
der Änderungspropagierung ansehen. Diese Methode compiliert Regeln, d.h. Regeln und Anfrage
werden automatisch transformiert. Sie führt indirekte top-down-Auswertung anhand direkter bottomup-Materialisierung transformierter Regeln durch. Mit diesem Ansatz können auch Anfragen durch
Regelcompilierung und Fixpunktiteration beantwortet werden. Fixpunktiteration ist das zugehörige
Regelerzeugungsverfahren.
Um eine zielgerichtete Propagierung zu erreichen, werden alle Propagierungs-, Transitions- und Originalregeln transformiert. Das Regelerzeugungsverfahren bei der Magic Updates-Methode wird als
Magic-Set-Transformation bezeichnet. Bei rekursiven Regeln kann Magic-Set-Transformation zum
Verlust der Stratifizierbarkeit führen. Dabei werden trotzdem keine Paradoxe wie z.B.
p(a) ←− . . . ←− ¬p(a)
vorkommen. Die Compilierungsphase der Magic Updates-Methode besteht aus zwei Teilschritten:
• Zunächst wird aus der gegebenen Regelmenge R eine Menge von internen Änderungsregeln
Rupdate bestimmt.
• Dann wird in die Magic Set-Transformation bzgl. einer Menge Qupdate von query seeds auf
magic
Rupdate angewendet. Die resultierende interne Regelmenge heißt Rupdate
Rupdate besteht aus drei disjunkten Teilmengen, der Menge R∆ von Propagierungsregeln (DeltaRegeln), der Menge Rτ von Transitionsregeln zur Simulation relevanter Teile des neuen DB-Zustands
und der Teilmenge R0 von R zur Berechnung relevanter Teile des alten DB-Zustands.
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
67
Abbildung 4.6: Struktur der Magic Updates-Methode
In der Iterationsphase wird zunächst die gegebene Transaktion U in eine Menge Uupdate von update
magic
mit der IFP-Methode (iterierte
seeds umkodiert. Dann wird je nach Stratifizierbarkeit von Rupdate
magic
, F ∪Qupdate ∪Uupdate ) bestimmt.
Fixpunkmethode) die Semantik der deduktiven Datenbank (Rupdate
Qupdate ist eine Menge von query-Literalen. Für eine materialisierte Sicht p heißen sie: query− p+ und
query− p− .
Die Seed-Fakten für die Magic Set-Transformation ergeben sich durch Kodieren aller Ziele der Propagierung als query-Fakten. Diese query-Seeds werden bei jeder Propagierung als Kodierung der Propagierungsziele verwendet. Dazu kommen pro Propagierung verschiedene update-Seeds, die die jeweils
aktuellen Basisdatenänderungen kodieren. Die Änderungspropagierung der Magic Set-Transformation
kodiert materialisierte Sichten als Anfragen und nur die, die induzierte Änderungen benötigen, um
diese Sichten anzupassen (zielgerichtete Propagierung). Die beim Propagieren entstehenden Unteranfragen über altem und neuem DB-Zustand werden dabei dynamisch generiert (als query-Fakten, die
durch query-Regeln während der FPI entstehen) und zum Ausgrenzen aller für die Propagierung irrelevanten Fakten genutzt. Dabei muss die FPI über den Magic Set-Regeln gleich mit mehreren querySeeds beginnen und query- und update-Seeds, die die Propagierung von oben und von unten gleichzeitig steuern und beschränken, kombiniert werden. Die query- und answer-Regeln werden systemintern
durch Regel-Compiler beim Regelentwurf erzeugt (s. Abbildung 4.7). Bei zu großer Regelzahl können
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
68
Abbildung 4.7: Regelgenerierung in der Magic Updates-Methode
diese auch zur Laufzeit entstehen. Folgendes wird für das obige Beispiel der Änderungspropagierung
durch die Magic Set-Methode gezeigt. Die Regelmengen R0 , R∆ , Rτ sind gegeben.
∆
Rmagic
:
answer− k− zyklisch+ ←− query− k− zyklisch+ , s+ (X)
answer− s+ (X) ←− query− s+ , answer− p+ (X, X)
answer− p+ (X, Y ) ←− query− p+ , k + (X, Y ), not answer− p(X, Y )
answer− p+ (X, Y ) ←− query− p+ , k + (X, Z), answer− pnew (Z, Y ), not answer− p(X, Y )
answer− p+ (X, Y ) ←− query− p+ , k new (X, Z), answer− p+ (Z, Y ), not answer− p(X, Y )
...
Die Menge der query-Regeln lauten wie folgt:
query− s+ ←− query− k− zyklisch+ .
query− p+ .
query− p− .
query− k− zyklisch+ .
query− p12 (X, Y ) ←− query− p+ , k + (X, Y )
query− pnew1 (Z) ←− query− p+ , k + (X, Z)
...
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
69
∆
Rmagic
: ...
answer− p− (X, Y ) ←− query− p− , k + (X, Y ), not answer− pnew (X, Y )
answer− p− (X, Y ) ←− query− p− , k − (X, Z), answer− p(Z, Y ), not answer− pnew (X, Y )
answer− p− (X, Y ) ←− query− p− , k(X, Z), answer− p− (Z, Y ), not answer− pnew (X, Y )
...
query− p12 (X, Y ) ←− query− p− , k − (X, Y )
query− p1 (Z) ←− query− p− , k − (X, Z)
...
τ
0
Die answer- und query-Regeln für Rmagic
und Rmagic
werden nach dem Prinzip von Magic Set ma-
schinell aufgestellt, da solche Transformationen per Hand nicht mehr auszuführen sind. Hier ergeben
sich insgesamt nach der Magic Set-Transformation 18 query-Regeln und 20 answer-Regeln. Dabei
werden zuerst immer relevante Propagierungspfade aufgesucht, bevor answer-Fakten produziert werden. Für unsere vorherige Änderungsmenge (Hier: Update Seeds) {k + (4, 1), k − (2, 3)} sieht das wie
folgt aus:
query− p+ .
query− p− .
query− k− zyklisch+ .
=⇒
query− s+ query− p+1 (3)
query− p12 (4,1) query− p+1 (4)
query− p12 (2,3) query− p1 (3)
query− p+1 (2) query− pnew1 (1)
=⇒...
Zur Optimierung der Propagierungsregeln werden folgende Anweisungen durchgeführt: In allen Propagierungsregeln, die aus Regeln in R entstanden sind, die keine Vereinigungs- oder Projektionsrelationen definieren, kann der Effektivitätstest not Lstate1 entfallen. Dabei ist eine Projektionsrelation
eine Relation, die durch genau eine Regel in R definiert wird, die mindestens eine lokale Variable
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung
70
enthält. Eine Relation heißt Vereinigungsrelation, wenn sie durch mehr als eine Regel in R definiert
wird.
Weiterhin können alle Propagierungsregeln aus R∆ gestrichen werden, die eine Relation definieren,
die nicht in Qupdate vorkommt und von der keine Relation in Qupdate abhängt. Von der Transitionsmenge Rτ können auch alle, die nach der Reduktion von R∆ nicht mehr aus R∆ heraus referenziert
werden, gelöscht werden.
Im Ablauf der Propagierung wird angenommen, dass alle Änderungspropagierungen nur von echten
Änderungen ausgehen, deren Nettoeffekt bereits bestimmt wurde.
Kapitel 5
Vergleich der drei Methoden
In diesem Kapitel wird versucht, zunächst anhand eines Beispiels die Unterschiede der prinzipiellen
Vorgehensweise verschiedener Methoden zu identifizieren. Im zweiten Teil des Kapitels werden die
Hauptbestandteile der drei Verfahren miteinander verglichen. Dadurch werden Kriterien ermittelt, die
Basis einer Beurteilung der Methoden sein können. Manche dieser Kriterien sind in der Vorgehensweise der Methoden zur Sichtenanpassung integriert, die dann für alle drei Methoden erörtert werden
(Regelgenerierung, Propagierung). Andere ausgewählte Kriterien sind teilweise Erweiterungen, die
nicht bei allen Verfahren berücksichtigt werden (Rekursion, Aggregation...). Im dritten Teil des Kapitels werden die Vor- und Nachteile der Ansätze herausgearbeitet und eventuelle Kriterien, die bei
manchen der Methoden nicht direkt hervorgehoben sind, angesprochen.
Obwohl alle vorgestellten Methoden in dieser Arbeit ein gemeinsames Ziel verfolgen, erreichen sie
aufgrund ihrer verschiedenen Basissprachen, Änderungsarten und Informationsgehalte unterschiedliche Effizienzniveaus.
5.1
Gemeinsames Beispiel
Gegeben sind folgende Basistabellen:
emp(emp-no, name, salary, dept-no, workdept)
dept(dept-no, dept-name, mgr-no)
Die Tabelle Emp definiert eine Angestelltentabelle in einer Datenbank eines Unternehmens mit den
Attributen: Angestelltennummer, Angestelltenname, Angestelltengehalt, Abteilungsnummer und Na71
5. Vergleich der drei Methoden
72
me der Arbeitsabteilung. Die Tabelle dept beinhaltet die Informationen über die verschiedenen Abteilungen mit den Attributen: Abteilungsnummer, Abteilungsname und Nummer der Vorgesetzten jeder
Abteilung. Es wird vorausgesetzt, dass Angestellte und Abteilungen eine hierarchische Struktur besitzen und die Nummer eines Angestellten nicht sofort wiederverwendbar ist, d.h. eine einzige Transaktion nicht einen Angestellten löschen und einen neuen mit derselben Nummer einfügen kann.
Die Sicht EmpDept soll die Angestellten mit ihren Abteilungen und deren Vorgesetzten enthalten:
CREATE VIEW EmpDept(name,dept,head) AS
SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM Emp, Dept WHERE Emp.dept-no=Dept.dept-no
CW-Methode
Die folgenden Produktionsregeln beschreiben die erforderlichen Aktionen, wenn in der Relation Emp
neue Werte eingefügt bzw. gelöscht werden. Old Emp bezeichnet dabei den Zustand der Relation Emp
vor der Änderung, inserted (deleted) Emp enthält nur die eingefügten (gelöschten) Tupel und Emp
steht für die aktuelle Relation, also einschließlich der Einfügungen und ohne die gelöschten Tupel.
CREATE RULE ins-Emp-EmpDept WHEN INSERTED INTO Emp
THEN INSERT INTO EmpDept
SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM inserted Emp, Dept
WHERE Emp.dept-no=Dept.dept-no
AND <name,dept,head> NOT IN inserted EmpDept
Die obige Regel beschreibt den Fall für Einfügungen in die Angestelltenrelation. 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 WHEREKlausel stellt sicher, dass das gefundene Tupel nicht schon durch eine andere Regel in die Sicht
eingefügt worden ist.
CREATE RULE del-Emp-EmpDept WHEN DELETED
FROM Emp THEN DELETE FROM EmpDept
WHERE <name,dept,dept> IN
SELECT Emp.name, Emp.dept-no, Dept.mgr-no
5. Vergleich der drei Methoden
73
FROM deleted Emp, old Dept
WHERE Emp.dept-no=Dept.dept-no
Die Löschungen von Emp werden durch die zweite Regel behandelt. Hier wird der Join zwischen der
Menge der gelöschten Angestellten und der alten Menge der Abteilungen angewendet. Die Joinbedingung bleibt auch hier unverändert.
Wie schon im Kapitel 4 erwähnt, wird die Modifikation eines Tupels als Löschen und Einfügen modelliert. Die Regeln für ein Update der Relation Emp entsprechen also im wesentlichen den beiden
oberen Regeln. Die Regeln für Änderungen bei der Relation Dept sind analog.
Magic Updates-Methode
Die Sicht EmpDept entspricht der Menge R0 in der Magic Updates-Methode. Die Transitionsregel Rτ
der Form
EmpDeptnew (name, dept, head) ←− Empnew (name, dept−no), Deptnew (dept−no, mgr −no)
wird als eine abgeleitete Sicht wie folgt dargestellt:
CREATE VIEW EmpDept-new(name,dept,head) AS
SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM new Emp, new Dept WHERE Emp.dept-no=Dept.dept-no
Die Delta-Regeln R∆ werden dann folgendermaßen berechnet:
INSERT INTO EmpDept name,dept,head
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM inserted Emp, new Dept (WHERE Emp.dept-no=Dept.dept-no
AND <name,dept,head> NOT IN EmpDept))
UNION
INSERT INTO EmpDept name,dept,head
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM
new Emp, inserted Dept (WHERE Emp.dept-no=Dept.dept-no
AND <name,dept,head> NOT IN EmpDept))
5. Vergleich der drei Methoden
DELETE name,dept,head FROM EmpDept
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM deleted Emp, Dept (WHERE Emp.dept-no=Dept.dept-no
AND <name,dept,head> NOT IN EmpDept-new))
UNION
DELETE name,dept,head FROM EmpDept
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM Emp, deleted Dept (WHERE Emp.dept-no=Dept.dept-no
AND <name,dept,head> NOT IN EmpDept-new))
Daraus werden die query- und answer-Regeln durch Magic Set-Transformation resultiert:
CREATE VIEW answer − EmpDept+ (name,dept,head) AS
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM inserted query EmpDept,inserted Emp,new answer Dept
(WHERE Emp.dept-no = Dept.dept-no
AND <name,dept,head> NOT IN answer-EmpDept))
CREATE VIEW answer − EmpDept+ (name,dept,head) AS
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM inserted query EmpDept,new Emp,inserted answer Dept
(WHERE Emp.dept-no = Dept.dept-no
AND <name,dept,head> NOT IN answer-EmpDept))
CREATE VIEW query − EmpDept12 (name,dept,head) AS
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM inserted query EmpDept,inserted Emp,new answer Dept
(WHERE Emp.dept-no = Dept.dept-no))
CREATE VIEW query − EmpDept12 (name,dept,head) AS
(SELECT Emp.name, Emp.dept-no, Dept.mgr-no
FROM inserted query EmpDept,new Emp,inserted answer Dept
(WHERE Emp.dept-no = Dept.dept-no))
...
74
5. Vergleich der drei Methoden
75
Es werden viele weitere query- und answer-Regeln erzeugt, die hier nicht alle dargestellt werden
können. Die Indizes wie z.B. 12 kodieren die Parameterpositionen, so dass z.B. die Sicht query −
EmpDept12 mit dem zweitem Attribut dept ausgewertet wird. Die Magic-Sichten geben Namen der
Angestellten mit deren Vorgesetzten und zugehörigen Abteilungen aus, für die die Sichten evaluiert
worden sind.
GMS-Methode
Auch hier wird die Sicht EmpDept verwendet, dabei sind nur Buchstaben als Bezeichnung der Attribute gewählt worden. Der DRed-Algorithmus bei Gupta et al. kann materialisierte Sichten inkrementell
anpassen, wenn regelbasierte abgeleitete Relationen eingefügt oder gelöscht werden. Die Sichten können in SQL geschrieben werden, aber SQL-Sichten mit Duplikaten können mittels dieses Algorithmus
nicht bearbeitet werden. Wir betrachten die einzelnen Schritte im DRed-Algorithmus für das folgende
Beispiel:
1. Löschen einer Obermenge der tatsächlich zu löschenden Tupel:
DELETE e,d,h FROM EmpDept WHERE
(SELECT e,d,h FROM Emp, Dept
WHERE (DELETE e,d FROM Emp AND Emp.d=Dept.d))
UNION
DELETE e,d,h FROM EmpDept WHERE
(SELECT e,d,h FROM Emp, Dept
WHERE (DELETE d,h FROM Dept AND Emp.d=Dept.d))
2. Alternative Herleitungspfade berücksichtigen:
INSERT INTO Empdept (e,d,h)
SELECT e,d,h FROM new Emp, new Dept
WHERE (DELETE e,d FROM EmpDept AND Emp.d=Dept.d)
3. Einfügungen berechnen:
INSERT INTO ∆+ -EmpDept e,d,h
(SELECT e,d,h FROM new Dept, ∆+ -Emp
(WHERE Emp.d=Dept.d))
UNION
INSERT INTO ∆+ -EmpDept e,d,h
5. Vergleich der drei Methoden
76
(SELECT e,d,h FROM new Emp, ∆+ -Dept
(WHERE Emp.d=Dept.d))
Für eine effiziente Auswertung mit diesem Algorithmus müssen nicht nur die Sichten, sondern alle
abgeleiteten Daten materialisiert sein, also auch Zwischenergebnisse bei der Berechnung der Sichten.
5.2
Systematische Diskussion
In diesem Abschnitt werden die drei in Kapitel 4 vorgestellten Verfahren unter Zuhilfenahme von
sieben Kriterien verglichen. Diese Kriterien sind entweder in den Vorgehensweisen der Methoden
realisiert oder sie werden nur als Erweiterungen erwähnt und in den jeweiligen Strategien nicht weiter
bearbeitet.
5.2.1
Regelgenerierung
Die Compilierung der Sichten wird beim Schemaentwurf in jeder Methode durchgeführt. Das RegelAbleitungssystem bei der Ceri/Widom-Methode setzt einen Compilierungsteil voraus, bei dem materialisierte Sichten in Änderungstrigger compiliert werden. In dieser Phase werden aktive Produktionsregeln generiert. 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. Die Sichten, die compiliert werden, dürfen keine Rekursion
beinhalten, aber sichere Negation durch bound columns ist zulässig. Bei der Magic Updates-Methode
werden bei der Compilierung aus einer Basisregelmenge zwei disjunkte Teilmengen (Propagierungsregeln, Transitionsregeln) als interne Änderungsregeln (Rupdate ) erzeugt und dann wird die Magic
Set-Transformation durch query seeds auf Rupdate angewendet. Die resultierende Menge ist die inmagic
terne Menge Rupdate
. Diese müssen durch Fixpunktiteration die induzierten Änderungen (Sichtenan-
passung) erzeugen. Die Basisregelmenge kann Rekursion und auch negative Literale beinhalten. Bei
Gupta et al. und Manthey werden im Gegensatz zum Ceri/Widom-Verfahren passive deduktive Regeln
verwendet. Bei Guptal et al. werden aus der Menge der gegebenen Regeln Delta-Regeln erzeugt, die
Änderungen der abgeleiteten Sichten beinhalten. Falls die gegebenen Regeln rekursiv sind, wird bei
der Propagierung ein bestimmter Algorithmus (DRed) zur inkrementellen Anpassung verwendet.
Die Regelgenerierung der verschiedenen Methoden ist zum anschaulichen Vergleich in Abbildung 5.1
dargestellt.
5. Vergleich der drei Methoden
77
Abbildung 5.1: Regelgenerierungen in den drei Methoden
5.2.2
Änderungspropagierung
Bei der Änderungspropagierung unterscheiden alle drei Methoden zwischen altem und neuem Zustand
der Datenbank. Die GMS- und die Manthey-Methode basieren auf Delta-Mengen, die alle Fakten
enthalten, die in dem ganzen Datenbanksystem geändert werden. Das Ziel dieser beiden Methoden
liegt darin, abgeleitete Deltas zu definieren, von denen die Sichten abhängen. Bei Gupta et al. werden
für jede Regel r der Form: (r) : p : − s1 , ..., sn die Delta-Regel ∆i (r), 1 ≤ i ≤ n generiert, die das
Prädikat ∆(p) für eine Sicht p definiert:
(∆(r)) : ∆(p) : − sν 1 , ..., sν i−1 , ∆(si ), si+1 , ..., sn
Deltarelationen hängen vom Vorzustand und anderen Deltas ab. Die Restliterale werden bei Löschungen im neuen Zustand (links vom Delta-Literal) und bei Einfügungen im alten Zustand (rechts vom
Delta-Literal) ausgewertet. Gupta et al. schlagen zwei Algorithmen vor, die Regeln zur Definition der
Delta-Mengen ableiten.
Bei der Magic Updates-Methode wird in der Propagierungsphase zunächst die gegebene Änderungsmenge in eine Menge Uupdate von update seeds umkodiert und danach wird die IFP-Methode angewendet. Die Delta-Regelerzeugung entsteht wie folgt: Für jede Regel L ←− L! , ..., Ln wird aus R,
2 ∗ n Propagierungsregeln der Form
0
state1
state1
Lsign1 ←− Lisign2 , Lstate1
, ..., Lstate1
, notLstate1
i−1 , Li+1 , ..., Ln
!
mit sign1 ∈ {+, −}, 1 ≤ i ≤ n und
5. Vergleich der drei Methoden
78
Abbildung 5.2: Mechanismen zur Faktenerzeugung
• falls Li ein negatives Literal not L0i ist: sign2 =def inverse(sign1)
• falls Li ein positives Literal ist: sign2 =def (sign1) L0i =def Li
• falls sign1 = + : state1 =def new, state2 =def old
• falls sign1 = - : state1 =def old, state2 =def new
Die Transitionsregeln werden aus der Menge von Basisrelationen und Basisfakten durch folgende
Schritte berechnet:
• Für jede Basisrelation r erzeuge zwei inkrementelle Transitionsregeln der Form:
rnew (X1 , ..., Xn ) ←− r(X1 , ..., Xn ), notr− (X1 , ..., Xn )
rnew (X1 , ..., Xn ) ←− r+ (X1 , ..., Xn )
• Für jede Regel L ←− Li! , ..., Ln ∈ R erzeuge eine Transitionsregel der Form:
Lnew ←− Lnew
, ..., Lnew
n
!
• R0 enthält alle Regeln aus R, die Relationen definieren, die in Delta-Regeln oder Transitionsregeln referenziert werden.
5. Vergleich der drei Methoden
79
In der Methode von Manthey bedeutet Änderungspropagierung die schrittweise Berechnung dieser
Deltamengen durch ein ähnliches Verfahren, das bei der entsprechend abgeleiteten Deltamenge angewendet wird. Beide Verfahren (Manthey, Gupta et al.) basieren auf einem pessimistischen Ansatz, bei
dem während der Propagierung der Vorzustand erhalten bleibt und der Nachzustand simuliert wird.
Hier werden die Deltamengen durch deduktive Regeln (passive Regeln) definiert, die in [GMS93] ∆Regeln, und in [Man03] Propagierungsregeln genannt werden. Beim Verfahren von Gupta et al. werden die Änderungen der Basisrelationen (Delta-Basisfakten) als Input dem Algorithmus (Counting/DRed-Algorithmus) übergegeben. Der Algorithmus erzeugt mit Hilfe von Delta-Regeln und Basisfakten abgeleitete Delta-Fakten, die wiederum als materialisierte Faktenmenge dem Algorithmus zur
Verfügung gestellt werden können. Die iterierten Algorithmen arbeiten mit endlichen Mengen durch
terminierende Schleifen, die eine unendliche Ausführung des Algorithmus verhindern.
Die Änderungspropagierung übernimmt der FPI im Magic Updates-Verfahren. Die Fixpunktiteration
ist ein endlicher Prozess, der deterministische Änderungsmengen abarbeitet und alle abgeleiteten Daten (aus den gegebenen Regel- und Faktenmengen) berechnen kann. Die Änderungen werden durch
Deltafakten protokolliert, die die Fixpunkiteration auslösen. Der FPI-Prozess kann auch abgebrochen
werden, wenn ein Deltafakt auftritt, das eine Integritätsbedingung verletzt. Interne Produktionsregeln (query/answer-Regeln), die beim Regelentwurf durch Compiler erzeugt werden, erzwingen die
Terminierung der FPI durch u.a. Protokollierung aller rekursiven Bindungen in abgeleiteten Regeln
und durch Beschränkung auf Inputparameter. Anders gesagt, die Iteration dauert solange bis sich
die query/answer-Regeln nicht mehr ändern. Durch die Magic Updates-Regeltransformation kann die
Anzahl der materialisierten Fakten auf die relevanten Fakten reduziert werden.
Die andere regelbasierte Methode ist von Ceri/Widom, bei der Regeln aktive Regeln (Trigger) sind.
Trigger führen Berechnungen aus, die vergleichbar mit den Berechnungen sind, die auftreten, wenn
Deltamengen im Sinne der deduktiven Regeln propagiert werden. Die Regelaktivierung bei der Ceri/Widom-Methode ist ein iteriertes Verfahren. Dieser Propagierungsprozess terminiert, wenn mittels
Triggern keine neuen Fakten mehr abgeleitet werden können oder wenn keine neuen Trigger gefeuert werden, d.h. die Konfliktmenge (getriggerte Regeln in einer Transaktion) ist leer, und dabei sind
alle Regeln ungetriggert. In diesem Verfahren werden bei Änderungen (Einfügung, Löschung und
Modifikation) der Basisdaten die Trigger gefeuert, die induzierte Änderungen ableiten. Die Trigger
übernehmen die Steuerung der Ausführung des iterierten Fixpunktprozesses für die Änderungspropagierung. Diese Regelaktivierung entspricht der Fixpunktiteration im Magic Updates-Verfahren bzw.
den Algorithmen in der Gupta et al.-Methode.
Bei der Propagierung wird für Residuenauswertungen und Effektivitätstests auch bei Ceri/Widom auf
unterschiedliche DB-Zustände zugegriffen, so dass einzufügende Fakten im neuen Zustand abgeleitet
5. Vergleich der drei Methoden
80
werden müssen und zu löschende im alten Zustand ableitbar sein. In dieser optimistischen Vorgehensweise werden zunächst die Basisfaktenänderungen ausgeführt und anschließend die Propagierung.
Hier wird der neue Zustand einer geänderten Relation T als T new (Regel der Sichtenanpassung) aus
alten Werten der Relation T (T old) mit Hilfe der Übergangsrelationen (T deleted, T inserted oder T
updated) erzeugt. Für die Sicht V mit der Definition:
DEFINE VIEW V (Col-List):
SELECT C1 , ..., Cn FROM T1 , . . . , Tm WHERE P
werden die erforderlichen Produktionsregeln für die Einfügungen und Löschungen in eine Relation
Ti wie folgt definiert:
CREATE RULE ins-Ti -V
WHEN inserted into Ti
THEN insert INTO V (SELECT C1 , ..., Cn
FROM T1 ,...,inserted Ti ,...,Tm
WHERE P and <C1 , ..., Cn > not in inserted V )
CREATE RULE del-Ti -V
WHEN deleted FROM Ti
THEN delete FROM V
WHERE <C1 , ..., Cn > in (SELECT C1 , ..., Cn
FROM old T1 ,...,deleted Ti ,...,old Tm
WHERE p-old)
Updateoperationen der Basisrelationen verursachen immer Delete- und/oder Insertoperationen an
Sichten.
CREATE RULE old-upd-Ti -V
WHEN updated Ti
THEN delete FROM V
WHERE <C1 , ..., Cn > in (SELECT C1 , ..., Cn
FROM old T1 ,...,old updated Ti ,...,old Tm
WHERE p-old)
CREATE RULE old-upd-Ti -V
WHEN updated Ti
THEN delete FROM V
WHERE <C1 , ..., Cn > in (SELECT C1 , ..., Cn
5. Vergleich der drei Methoden
81
FROM old T1 ,...,old updated Ti ,...,old Tm
WHERE p-old)
5.2.3
Rekursion
Ceri/Widom haben die Rekursion in ihrer Methode zur Anpassung der materialisierten Sichten nicht
berücksichtigt. Hier wird durch die Voraussetzung der bound columns sichergestellt, dass keine unsicheren SQL-Sichten vorkommen, weil sie auch keine gültigen SQL-Ausdrücke sind. Die Bereichsbeschränkung der Abfragen wird dadurch gewährleistet, dass alle in der Sicht verwendeten Attribute im
FROM-Teil an eine Tabelle gebunden sein sollen und, dass in den verwendeten Bedingungen entweder
Konstante oder Terme mit einem gültigen Attribut vorkommen. In SQL wird eine rekursiv abhängige
Sicht in ihrem Anfrageausdruck jeweils nur von höchstens einer anderen Sicht rekursiv abhängen.
Gupta et al. haben einen DRed-Algorthmus zur effizienten inkrementellen Anpassung der rekursiven
Sichten entwickelt. Der Algorithmus arbeitet mengenorientiert und löst das Problem, in dem eine
Obermenge der effektiv zu löschenden Fakten propagiert wird. Dabei müssen alle abgeleiteten Daten
und Sichten materialisiert sein.
In SQL sind ausschließlich linear rekursive Sichten zugelassen. In Datalog sind auch nicht lineare Rekursionen erlaubt. Lineare Rekursion in der Gupta et al.-Methode bedeutet das mehrfache Auftreten
rekursiv abhängiger Regeln im Regelrumpf und ist ein Spezialfall rekursiver Regeln. In datalogbasierten Ansätzen wie bei Manthey und Gupta et al. existiert das Problem der Bereichsbeschränkung
(Sicherheit) von Regeln, welche eine wichtige Voraussetzung dafür ist, dass eine Regel eine sinnvolle Semantik hat und in effizienter Weise ausgewertet werden kann. Im SQL-basierten Ansatz bei
Ceri/Widom ist dieses Problem für Anwender nicht ersichtlich.
Damit bei der Ableitung der durch eine Regelmenge R beschriebenen abgeleiteten Fakten Rekursion
und Negation sinnvoll gehandhabt werden können, wird für R eine Stratifikation erzeugt. Im DRedAlgorithmus muss die Regelmenge für die Auswertung in disjunkte Schichten unterteilt werden, so
dass die Regeln einer Schicht nur von den unteren Schichten abhängig sind. Für jede Schicht müssen
dann die einzelnen Schritte des DRed-Algorithmus angewendet werden. Da es in rekursiven Sichten
eine unendliche Anzahl von verschiedenen Herleitungspfaden geben kann, ist die Anwendung des
Counting-Algorithmus auf nichtrekursive Sichten effizienter.
Im Verfahren von Manthey ist auch die Selbstreferenz der Prädikate in einer Regel zuglassen. Rekursive Regeln müssen immer mit mindestens einer nichtrekursiven Regel (für dieselbe Relation)
kombiniert werden. Der Abhängigkeitsgraph der rekursiven Regeln ist zyklisch und bei stratifizierten
5. Vergleich der drei Methoden
82
Regeln gehören alle rekursiv voneinander abhängigen Relationen in dieselbe Schicht. Im Fall der linearen Rekursion existiert nur ein rekursives Literal in der Regel. Rekursion kann auch hier wie in
[GMS93] indirekt entstehen. Rekursion kann auch mit Negation vorkommen, die Unstratifizierbarkeit
der Regeln zur Folge hat (Dies wird im nächsten Unterkapitel erläutert). Bei Bestimmung von F ∗ in
der Fixpunkt-Iteration bei der Magic Updates-Methode kann diese Kombination zum Reihenfolgeproblem führen.
5.2.4
Negation
Ceri/Widom erlauben negative Unterabfragen (not exists, not in, ! = any) in SELECT-Anweisungen.
Bei dieser Art von Abfragen hat Einfügungsoperation bei Tabellen in verschachtelte Unterabfragen,
Deleteoperation an Sichten zur Folge, und Deleteoperationen führen zu Einfügung in die Sicht. Hier
werden auch wie im positiven Fall bestimmte Definitionen (I-Safe, DU-Safe) zur Bestimmung der
sicheren Referenztabellen der negativen Unterabfragen vorgeführt, die auf Schlüsselattribute der Relationen basieren. Der Unterschied zum positiven Fall kann man u.a. im Duplikattest der Deleteoperation beobachten. not exists-Unterabfragen entsprechen negativen Literalen in einer stratifizierten
Regel. Beim Ceri-Widom-Verfahren wird die Bereichsbeschränktheit der Sichten durch Aufnahme
der Schlüsselattribute in die Sichten garantiert.
Die von Gupta et al. implementierten Algorithmen lassen sichere und stratifizierte Negation und
Aggregation (z.B. Summierung und Durchschnitt von Attributen) in der Sichtendefinition zu. Im
Counting-Algorithmus werden je nachdem, wo sich ein negatives Prädikat in einer Regel befindet,
drei Fälle unterschieden. Das Zusammenspiel zwischen Einfüge- und Löschoperationen bei negativen Abfragen in [CW91] werden beim Verfahren von Gupta et al. im Counting-Algorithmus durch
Vorzeichenänderung der Counts von negativen Prädikaten zu induzierten Änderungen wiedergegeben.
In der Methode von Manthey werden negative Propagierungsregeln wie positive Regeln behandelt. Im
negativen Fall wird im Propagierungsschritt das invertierte Vorzeichen an die induzierten Änderungen
weitergegeben.
Die Verwendung von negativen Literalen kann das Problem der Unstratifizierbarkeit zu Folge haben.
Wenn in einem Rekursionszyklus eines Abhängigkeitsgraphen eine negative Abhängigkeit auftaucht,
kann man nicht mehr stratifizieren.
p(Y ) =⇒ r(Y )
p(X) =⇒ nots(X, Y ), notp(Y )
Um Stratifikationsbedingungen zu erfüllen, müsste p wegen der negativen Abhängigkeit in einem echt
höheren Stratum als p liegen. Eine Idee ist, die nichtrekursive Regel in ein tieferes Stratum zu stecken
5. Vergleich der drei Methoden
83
als die rekursive Regel. Diese Idee funktioniert nicht immer, weil es abhängig von der Faktenmenge
F wieder zu unerwünschten Frühableitungen kommen kann.
Die Probleme, die bei Unstratifizierbarkeit vorkommen können, sind: Wie kann man F* konstruktiv
bestimmen ohne dass negative Literale zu früh ausgewertet werden? Sind negative Selbstreferenzen
einzelner Fakten notwendig? Dabei wird das Problem der Semantik der unstratifizierbaren Regeln
ersichtlich, wenn es irgendwelche Fakten gibt, für die durch Ableitung kein definitiver Wahrheitswert (true/false) bestimmt werden kann. In der Magic Updates-Methode werden einige Lösungsverfahren vorgeschlagen und die Conditional Fixpoint(CFP) - Methode wird bevorzugt und detailliert
dargestellt, weil die CFP-Methode exakt der intuitiv leicht zugänglichen Argumentationsmethode zur
Behandlung unstratifizierbarer Regeln entspricht.
5.2.5
Aggregatfunktionen
Aggregation wird benutzt, um große Datenmengen in verwendbare Form zu bringen. In allen drei Propagierungsmethoden können Aggregatfunktionen wie COUNT, MIN, MAX, SUM, AVG mit einigen
Einschränkungen in den jeweiligen Verfahren auftreten. Für Regeln und Sichten mit Aggregatfunktionen müssen spezielle Delta-Regeln erzeugt werden, die Aggregatwerte ohne Neuberechnung aktualisieren können. Aktualisierung der Regeln mit diesen Funktionen ist komplexer als im Normalfall und
benötigt exaktere Reaktionen auf Änderungen. So können z.B. Aggregatfunktionen in Unteranfragen
nur sehr eingeschränkt geschachtelt werden.
Ceri/Widom beschränken sich in ihrer Methode auf bestimmte Mengenoperatoren (minus ist z.B. nicht
zugelassen). Falls in einer SQL-Anweisung mit GROUP BY- oder HAVING-Klauseln Änderungen
auftreten, so können induzierte Änderungen einer oder mehrerer Gruppen oder auch Einfügungen
oder Löschungen von Gruppen erfolgen. Sichtanalyse und Regelgenerierung müssen dann einzeln für
jede Komponente in den Select-Anweisungen mit Mengenoperatoren durchgeführt werden.
Gupta et al. spezifizieren ihren Counting-Algorithmus im Datalog-Kontext ausschließlich für materialisierte Sichten, die auch Aggregation beinhalten können. Die Aggregationssemantik für ihre Methode ist ausfürlich in [Mum91] erörtert worden. Die Autoren von [GMS93] behaupten, dass diese
Aggregationssemantik auch in anderen existierenden Sichtenanpassungsmethoden verwendet werden
kann. Die zentrale Idee in ihrer Aggregationssemantik ist, die Tatsache zu ergreifen, dass ein Aggregatliteral für jeden Wert der Attributenmenge Y ein Tupel generiert, dabei sind Y die Attribute der
Groupby-Funktion. Wenn ein Tupel t in einem Aggregatprädikat aus einer Relation gelöscht bzw. in
die Relation eingefügt wird, wird das entsprechende Aggregattupel (πY (t)) auch geändert. Häufig
wird das Aggregattupel trotz der Änderungen in der Basisrelation nicht geändert.
5. Vergleich der drei Methoden
84
Je nachdem in welcher Position eine Aggregationsfunktion in einer Regel vorkommt, werden bestimmte Vorgehensweisen oder auch Algorithmen zur Auswertung der Funktionen und Propagierung
der zugehörigen Regeln vorgeschlagen.
Selektions-, Vereinigungs- und Gruppierungsoperatoren sind u.a. auch in der Magic Updates-Methode
zulässig, die durch logisches UND (Konjunktion) zwischen den Prädikaten und ODER zwischen den
Regeln auftreten. Bei Vereinigung wird eine Relation durch mehrere Regeln definiert, dabei können definierte Regeln lokale Variablen enthalten. Vereinigungen und Projektionen können im Magic
Updates-Verfahren Fehler verursachen, die zu Mehrfachableitungen (Duplikate) führen können. Dies
kann durch Effektivitätstest behoben werden.
Die Verwendung der Aggregatfunktionen ist eine Erweiterungsmöglichkeit, die diese Methoden zusätzlich bekommen haben, um ihre Einsetzbarkeit zu steigern.
5.2.6
Duplikatbehandlung
Die Methode von Ceri/Widom kann keine Duplikate bearbeiten. Damit auch keine Duplikate vorkommen, haben sie das Prinzip von bound columns eingeführt. Schlüsselattribute sind der Hauptbestandteil dieser Methodik. Dabei wird in jeder Sicht ein Schlüsselattribut für jede Referenzrelation aufgenommen. Durch die bound columns kann das Verfahren erkennen, ob jede Tabellenreferenz einen
Schlüssel enthält. Diese Einschränkung durch Schlüssel lässt keine Duplikate mehr zu. Bei der Einfügung neuer Tupel wird der Duplikattest in der entsprechenden Regel durch not - <TransitionstabellenBezeichnung> durchgeführt. Das gleiche wird bei der Regelgenerierung für Deleteoperationen in negativ verschachtelten Unterabfragen durchgeführt, da der Aktionsteil der Regel eine Insertoperation
enthält. In kombinierten Änderungen (Insert und Delete) werden die neuen Tupel im neuen Zustand
wie folgt berechnet:
Tnew = (Told − Tdeleted ) ∪ Tinserted
Gupta et al. dagegen erlauben in ihrer Methode zur inkrementellen Sichtenanpassung Duplikate. Wenn
Duplikate zugelassen sind, reicht es aus, nur ableitbare Änderungen zu propagieren.
In diesem Verfahren ist ein Algorithmus (Counting Algorithmus) zur Lösung der Duplikatproblematik
spezifiziert. Die Hauptaufgabe des Algorithmus besteht darin, die Anzahl der alternativen Ableitungswege zu finden. Die Autoren nehmen an, dass jedes Fakt unabhängig von der Anzahl der Duplikate in
den materialisierten Sichten und Basisrelationen nur einmal gespeichert wird. Um die Anzahl (Count)
der alternativen Ableitungen jedes Tupels zu berechnen, wird jeder Relation ein Attribut zugefügt, das
diese Zahl enthält. Wenn das Vorzeichen des Counts eines Tupels positiv ist, handelt es sich um eine
Einfügung. Ein negatives Vorzeichen steht für eine Löschung.
5. Vergleich der drei Methoden
85
In dem Counting-Algorithmus ist ein spezieller Vereinigungsoperator (]) eingeführt worden, der
Mehrfachableitungen verhindert. Mit Hilfe dieses Operators wird ein Duplikattest durchgeführt, so
dass der neue Zustand einer Relation R wie folgt berechnet werden kann:
pneu = pold ] ∆(p)
Bei der Magic Updates-Mehode sind auch Duplikate zugelassen. Duplikate entstehen durch Ableitungen. Durch Vereinigung1 der Propagierungsregeln und durch Projektion2 der Prädikate werden Mehrfachableitungen von einem Fakt produziert. Mehrfachableitungen können zu fehlerhafter Herleitung
der Deltafakten führen. Zur Lösung dieses Problems und Entdeckung der Mehrfachableitungen wird
ein Effektivitätstest durchgeführt. Der Effektivitätstest prüft Delta-Regeln auf Ableitbarkeit im alten
Zustand und auf Effektivität der neuen Deltas.
Bei der Einfügung neuer Werte in positiven Propagierungsregeln wird der Effektivitätstest, ähnlich
wie in der Ceri/Widom-Methode, durch den Zusatz von not vor dem eingeführten Prädikat im Rumpf
der Regel durchgeführt. Damit wird die Einfügung von schon vorhandenen Tupeln verhindert. Zum
Effektivitätstest in negativen Propagierungsregeln ist der neue Zustand der abgefragten Relation erforderlich. Wenn Einfügungen und Löschungen in einer Änderung kombiniert werden, benutzt Manthey
in seiner Methode eine pessimistische Variante zur Erhaltung der beiden Datenbankzustände. Dabei
bleibt der alte Zustand erhalten und der neue Zustand wird simuliert (F new ).
F new = (F old − F − ) ∪ F +
Dies entspricht der Anwendung des ]-Operators im Verfahren von Gupta et al.
Im Allgemeinem wird in der Manthey-Methode der Duplikattest bei Einfügungen im alten Zustand
und bei Löschungen im neuen Zustand erfolgen. In [Man03] wurde bei Änderungen, die zur Einfügung neuer Werte führen, der neue Zustand der Datenbank genommen, da andere parallellaufende
Regeln auch die Werte für die gleichen Tupel einfügen können.
5.2.7
Änderungen und Änderungsarten
Grundsätzlich sind drei Änderungsarten als Basisfaktenänderungen bekannt (Einfügung, Löschung,
Modifikation), bei denen ein konkreter Fakt eingefügt, gelöscht oder modifiziert wird. Bei den Änderungssprachen, die bei Manthey und Gupta et al. verwendet werden, sind nur Einfüge- und Löschanweisungen zulässig. Modifikationen werden bei diesen Methoden als Einfügung des neuen und Löschung des alten Fakts durchgeführt. Nur wenige Sprachen, wie z.B. SQL, verfügen über eine Modifikationsanweisung (update). Die Berücksichtigung von Modifikationen in inkrementellen Verfahren
1
2
Wenn eine Relation durch mehrere Regeln definiert ist
Wenn eine definierende Regel einer Relation lokale Variablen enthält
5. Vergleich der drei Methoden
86
ist ungleich komplexer als bei Einfügungen und Löschungen. Die SQL-basierte Methode von Ceri/Widom lässt Modifikationen zu, jedoch werden sie beim ersten Propagierungsschritt auch in induzierte Einfügungen und Löschungen aufgeteilt.
Unterschiede in den Änderungs- und Transaktionskonzepten in Datalog- und SQL-basierten Methoden können zu enormen Konsequenzen für eine inkrementelle Änderungspropagierung führen.
Für datalogbasierte Methoden kann man das mengenorientierte Transaktionskonzept als simultane
Durchführung mehrerer Änderungen ohne Festlegung der Reihenfolge der Einzelschritte definieren.
Dabei bedeutet die Nettoeffekt-Berechnung, dass wechselseitig kompensierende Änderungen eliminiert werden, bevor die Transaktion wirksam wird. Transaktionen dürfen auch geschachtelt und mit
Bedingungen gekoppelt werden.
Für die induzierten Änderungen in verschiedenen Propagierungsverfahren sind in der Literatur unterschiedliche Änderungsarten entwickelt worden. Bei der Klassifikation der Änderungsarten in [Gri97]
sind die Änderungen bei Ceri/Widom und Gupta et al. als ableitbare Änderungen und bei der MantheyMethode als echte Änderungen bezeichnet worden, d.h. sie führen tatsächlich zu Zustandsunterschieden.
5.3
Beurteilung der Methoden
Alle vorgestellte Verfahren erweitern die DB-Systeme um das Konzept der materialisierten Sichten
und ihre inkrementellen Anpassung. Die Strategien basieren auf verschiedenen Datendefinitionssprachen, wie SQL (Ceri/Widom) oder Datalog (Manthey, Gupta et al.). Die Strategien im Konzept von
Datalog können auch nach SQL übertragen werden, dabei erfüllen die Datalogbasierten Verfahren
einige Anforderungen der SQL-Sprache nicht wie z.B. die SQL-Transaktionen nicht.
Ceri/Widom implementieren ihre Methode mittels Starbursttriggern und haben direkt die Besonderheiten und Einschränkungen des Starburstsystem übernommen. Deshalb kann die Methode nicht zur
Definition spezialisierter Ausdrücke verwendet werden. Die Tranformationen in diesem Verfahren
sind wegen der Verwendung spezialisierter SQL-Sprache nicht unmittelbar mit den Transaktionsstrategien in Datalog vergleichbar. Das Verfahren von Ceri/Widom verwendet aktive Datenbanktechnologie und Schlüsselinformationen für alle referenzierten Tabellen in den Sichten. Der Zugriff auf Basistabellen lässt sich nicht vermeiden. Der große Nachteil der Methode ist, dass Sichten ohne Schlüsselinformation nicht bearbeitet werden können.
Gupta et al. und Manthey fordern in ihren inkrementellen Verfahren Zugriff auf allen Basisrelationen
für alle Aktualisierungsoperationen, welche sehr kostenintensiv werden können.
5. Vergleich der drei Methoden
87
Die verschiedenen Verfahren, die in Kapitel 4 diskutiert wurden, sind alle bottom-up-Propagierungsmethoden, die entweder deduktiv (passiv) im Kontext von Datalog oder aktiv im Starburst implementiert sind. Die passiven Implementierungsstrategien von Manthey und Gupta et al. haben als Hauptidee, die spezialisierten Ableitungswege als Delta-Regeln und als Simulation von Zuständen mittels
Übergangsrelationen zu realisieren. Die Deltarelationen und materialisierten Sichten entsprechen den
Basistabellen und Regeln in SQL-basierten Methoden und die Transitionsregeln den Transitionssichten. Alle Regeln in deduktiven Änderungspropagierungen werden, bezogen auf ihre Abhängigkeiten,
in Stratifikationsebenen ausgewertet. In [CW91] wird auf die Realisierung von Delta-Regeln verzichtet, in dem die existierenden Systemkomponenten als Deltarelation verwendet werden. Bei dieser
aktiven Implementierung müssen die Trigger induzierte Änderungen ableiten und den änderungsgetriebenen Fixpunktprozess steuern. Diese Aufgabe übernehmen die Delta-Regeln in deduktiven Ansätzen.
Der Regelrumpf einer Delta-Regel entspricht der Anfrage an die Faktenmenge im Aktionsteil eines
Triggers und abgeleitete Deltafakten sind äquivalent zu Produktionsregeln. Durch diese Änderungen
werden Trigger für die nächste Stufe gefeuert, womit auch die Steuerung der Propagierung vorgenommen wird.
Die Vorteile der triggerbasierten Ansätze basieren darauf, dass von den Triggerkomponenten sehr
viele Möglichkeiten zur Verfügung gestellt werden, die bei den bottom-up-Propagierungen benötigt
werden, wie z.B. die unmittelbare Ausführung relevanter Trigger zur Durchführung einer Änderungsanweisung. Da die Trigger durch die Ausführung von Änderungen aktiviert werden, stehen in den
Triggern alle relevanten Informationen zur Verfügung, die auch von den Deltafakten bereitgestellt
werden. Ein anderer Vorteil ist die automatische Terminierung eines Propagierungsprozesses, wenn
keine weiteren Trigger gefeuert werden. Ein Nachteil der Verwendung von Triggern ist, dass Triggerausführung die Leistung des Systems reduzieren kann ([CCW00]), weil sie nicht wie interne DBSKomponenten funktionieren.
Bei den Verfahren von Gupta et al. und Manthey sind nur Einfüge- und Löschanweisungen zulässig
und die Methode von Ceri/Widom verfügt über eine Modifikationsanweisung. Die Methoden von
Gupta et al. und Ceri/Widom sind für ableitbare Änderungen implementiert worden, wobei Manthey
seine Methode für echte Änderungen, die tatsächlich zu Zustandsänderungen führen, implementiert
hat. Generierung ableitbarer Folgeänderungen erfordert geringeren Aufwand, dafür wird aber mehr
Aufwand bei der Sichtenanpassung in entsprechenden Strategien benötigt. Alle drei Methoden gehen
vom Nettoeffekt einer Menge von Änderungen aus.
Im Gegensatz zur Transaktionsausführung bei Ceri/Widom sind bei Manthey und Gupta et al. zum
Ende einer Datalog-Transaktion ggf. eine Menge von Änderungen verschiedener Basisrelationen, die
5. Vergleich der drei Methoden
88
propagiert werden. So können bei der Anwendung der Delta-Regeln Änderungen, die durch verschiedene Basisfaktenänderungen induziert werden, wiederholt abgeleitet werden. Dieses Redundanzproblem wird durch effektive Auswertung der Seitenliterale gelöst. Ceri/Widom lassen durch bestimmte
Bedingungen (sichere Tabellen) keine Mehrfachableitungen in ihrem Verfahren zu. Bei der Simulation der Datenbankzustände mit Hilfe der Transitionsregeln für die Residuenauswertung werden unterschiedliche Vorgehenweisen bevorzugt. In [CW91] werden erst die Basistabellenänderungen ausgeführt und anschließend die Propagierung. Dann muss der alte Zustand simuliert werden. Trotz der
Verwendung der Transitionsregeln wird bei der Methode von Ceri/Widom kein Stratifikationsproblem
auftreten, weil Rekursion in der Methode nicht vorkommt. Bearbeitung von nur nichtrekursiven Sichten kann das Einsatzgebiet dieser Strategie von Ceri/Widom evtl. verringern.
Das Stratifikationsproblem, dass bei rekursiven negativen Delta-Regeln für effektive induzierte Löschungen aufgrund des Effektivitätstests negativer rekursiver Abhängigkeiten bei Manthey auftritt,
wird durch Eigenschaft der lokalen Stratifizierbarkeit (nicht nur auf den Eigenschaften der Regelmengen) gelöst. Gupta et al. lösen das Problem der rekursiven Regeln durch den DRed-Algorithmus. Der
Nachteil dieses Algorithmus ist, dass eine Obermenge der effektiv zu löschenden Fakten propagiert
wird. In der Magic Updates-Methode werden Effektivitätstests für die Ableitung effektiver Änderungen nur dann ausgeführt, wenn eine Projektion oder Vereinigung der Regeln durchgeführt wird.
Ceri/Widom verwenden in ihrer Methode zur inkrementellen Sichtenanpassung bestimmte Techniken,
die nicht unmittelbar mit den Dataloginstrumenten vergleichbar sind, wodurch die Vergleichskriterien
zwischen den Leistungsfähigkeiten in SQL und Datalog nur schwer erkennbar werden. So zeigen sie,
wie komplex und nicht intuitiv die Implementierung eines inkrementellen Verfahrens zur Sichtenanpassung ist.
Kapitel 6
Zusammenfassung und Ausblick
In dieser Arbeit werden einige Implementierungen der inkrementellen Propagierungsverfahren zur
Anpassung materialisierten Sichten in relationalen Datenbanken betrachtet.
Nach der Erörtung einige Grundlagen und Definitionen wird zu Beginn im Kapitel 3 das Problem
der Sichtenauswahl zur Materialisierung und Anwendung der materialisierten Sichten in Datenbanksystemen aufgezeigt. Danach wird das Problem der inkrementellen Sichtenanpassung erörtert. Die
wesentliche Ergebnisse dieses Kapitel sind:
• Der Zugriff auf materialisierte Sichten ist wesentlich schneller als auf vituelle Sichten.
• Die relative Leistung der inkrementellen Vefahren variiert mit Komplexität und Auswahl der
materialisierten Sichen.
• Inkrementelle Verfahren aktualisieren die Sichten schneller als durch komplette Neuberechnung.
Auf dem ersten Blick vermitteln die Strategien den Eindruck, dass sie alle ein gemeinsames Ziel verfolgen, jedoch verwenden die Entwickler verschiedene Ausführungsmodelle der Propagierung und
verschiedene Definitionen der Prozesskomponenten. Diese scheinbar unterschiedlichen Vorgehensweisen werden in Kapitel 5 veranschaulicht.
In Kapitel 5 wird versucht, das Vergleichen der Methoden durch Auswahl der wesentlichen Eigenschaften der drei Strategien zur Änderungspropagierung und Bestimmung der Kriterien zur Bewertung dieser Verfahren zu realisieren. Im gemeinsamen Beispiel werden auf einheitlichen Basisdaten
die wichtigsten repräsentativen Aspekte der verschiedenen Methoden dargestellt.
89
6. Zusammenfassung und Ausblick
90
Es lassen sich einige Ergebnisse von Kapitel 5 zusammenfassen:
• Die datalogbasierten Verfahren können ohne wesentliche Einschränkungen in SQL-basierten
Verfahren integriert werden.
• Der Ansatz von Ceri/Widom kann durch weitere Möglichkeiten wie Zulässigkeit von Rekursion, Duplikaten und mehrstufigen Veschachtelung der Select-Anweisungen erweitert werden
und damit ein vergleichbare Semantik zu Datalog aufgestellt werden.
• Die ganzen Steuerungsaufgaben aller Propagierungsprozesse sind die Gleichen, die entweder
durch Trigger oder Deltaregeln übernommen werden.
• Berücksichtigung der verschiedene Zeitpunkte der Sichtenanpassung und inkrementellen Anpassung aller Aggregationsfunktionen ohne Einschränkungen bei verschieden Verfahren kann
ihre Einsetzbarkeit in der Praxis steigern.
Welche der vorgestellten Mehtoden zur inkrementellen Anpassung materialisierter Sichten leistungsfähiger und schneller ist, kann nur durch ihren Einsatz in verschieden Bereichen der Datenbankapplikationen ersichtlich werden.
Die vorgestellten Verfahren in dieser Arbeit benötigen noch genaue und umfangreiche Behandlung,
die im Rahmen anderer Diplomarbeiten realisiert werden könnten.
Die Forschungsarbeit auf dem Gebiet der inkrementellen Sichtenanpassung kann noch lange nicht
als abgeschlossen gelten, so könnten in diesem Bezug weitere Fortschritte erreicht werden. Es ist
eine inkrementelle Anpassungsstrategie vorstellbar, die Vorteile existierender Methoden übernimmt
und gleichzeitig in verschieden Datendefinitions- und Datenmanipulationsprachen einsetzbar ist. Ein
weiterer Aspekt der Erweiterung dabei könnte die top-down-Propagierung, d.h. die inkrementelle
Übertragung der Änderungen in den Sichten auf Basisdaten sein, die neben der bottom-up-Strategie
in einem System möglich wird.
Literaturverzeichnis
[BLT86] Jose A. Blakeley, Per-Ake Larson, and Frank W. Tompa. Efficiently updating materialized
views. Proc. SIGMOD 1986, pages 61–71, May 1986.
[CCW00] Stefano Ceri, Roberta Jo Cochrane, and Jennifer Widom. Practical applications of triggers
and constraints: Successes and lingering issues. Proc. VLDB 2000, pages 254–262, 2000.
[CW90]
Stefano Ceri and Jennifer Widom. Deriving production rules for incremental constraint
maintenance. Proc. VLDB 1990, Brisbane, Australien, pages 566–577, 1990.
[CW91]
Stefano Ceri and Jennifer Widom:. Deriving production rules for incremental view maintenance. Proc. VLDB 1991, pages 577–589, September 1991.
[CW94]
Stefano Ceri and Jennifer Widom. Deriving incremental production rules for deductive
data. Information Systems 19(6), pages 467–490, 1994.
[CW96]
Stefano Ceri and Jennifer Widom. Active Database Systems - Triggers and Rules for Advanced Database Processing. Morgan Kaufmann, San Francisco/CA, USA, 1996.
[GL95]
Timothy Griffin and Leonid Libkin. Incremental maintenance of views with duplicates.
Proc. SIGMOD 1995, San Jose/CA. USA, pages 328–339, 1995.
[GM95]
Ashish Gupta and Inderpal Singh Mumick. Maintenance of materialized views: Problems,
techniques, and applications. IEEE Data Engineering Bulletin, (18 (2)):3–18, June 1995.
[GM99]
Ashish Gupta and Inderpal Singh Mumick. Materialized Views: Techniques, Inplementations and Applications. The MIT Press, 1999.
[GMS92] Ashish Gupta, Inderpal Singh Mumick, and Venkatramanan Siva Subrahmanian. Maintaining views incrementally. Technical Report 921214-19-TM, AT&T Bell Laboratories,
1992.
91
LITERATURVERZEICHNIS
92
[GMS93] Ashish Gupta, Inderpal Singh Mumick, and Venkatramanan Siva Subrahmanian. Maintaining views incrementally. Proc. SIGMOD 1993, pages 157–166, May 1993.
[Gri97]
Ulrike Griefahn. Reactive model computation - a uniform approach to the implementation
of deductive databases. Dissertation, Rheinische Friedrich-Wilhelms-Universität, Bonn,
1997.
[Han87]
Eric N. Hanson. A performance analysis of view materialization strategies. Proc. SIGMOD
1987, pages 440–453, 1987.
[HW93]
Eric N. Hanson and Jennifer Widom. An overview of production rules in database systems.
The Knowledge Engineering Review 8(2), pages 121–143, 1993.
[KP81]
Shaye Koenig and Robert Paige. A transformational framework for the automatic control
of derived data. Proc. VLDB 1981, Cannes, France, pages 306–319, 1981.
[Man94] Rainer Manthey. Reflections on some fundamental issues of rule-based incremental update
propagation. Proc. DAISD 1994, Report de recerca LSI/94-28-R, Universität Barcelona,
pages 255–276, 1994.
[Man03] Rainer Manthey. Vorlesung deduktive Datenbanken. Universität Bonn, Sommersemester
2003.
[Mum91] Inderpal Singh Mumick. Query Optimization in Deductive and Relational Databases. PhD
thesis, Stanford University, 1991.
[SB75]
Hans Albrecht Schmid and Philip A. Bernstein. A multi-level architecture for relational
data base systeme. Proc. VLDB 1975, pages 202–226, 1975.
[SI84]
Oded Shmueli and Alon Itai. Maintenance of views. Proc. SIGMOD 1984, pages 240–255,
1984.
[SS82]
Mario Schkolnick and Paul G. Sorenson. The effects of denormalisation on database performance. Australien Computer Journal 14(1), pages 12–18, 1982.
[Ull89]
Jeffrey D. Ullman. Principles of Database and Knowledge-Base Systems, volume 1, 2.
Computer Science Press, 1989.
LITERATURVERZEICHNIS
93
Eidesstattliche Versicherung
Ich versichere an Eides statt durch meine Unterschrift, dass ich die vorstehende Arbeit selbständig
und ohne fremde Hilfe angefertigt und alle Stellen, die ich wörtlich oder annähernd wörtlich aus
Veröffentlichungen entnommen habe, als solche kenntlich gemacht habe, mich auch keiner anderen
als der angegebenen Literatur oder sonstiger Hilfsmittel bedient habe. Die Arbeit hat in dieser oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen.
Bonn, den 24. November 2004
Roya Juki