-
Rheinische Friedrich-Wilhelms-Universität Bonn
Diplomarbeit
Inkrementelle Methoden zur Anpassung
materialisierter Sichten in relationalen
Datenbanken
von: Roya Juki
Matrikel-Nr.: 1152042
Adresse: Masurenweg 3
53119 Bonn
Erstgutachter: Prof. Dr. Rainer Manthey
-
Abstract
Materialisierte Sichten spielen eine große Rolle in leistungsstarken Abfrageprozessen. Nach der in-
itialen 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ön-
nen. Da die komplette Neuberechnung bei großen Datenbanken meistens mit hohem Aufwand ver-
bunden 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 Reali-
sierung der inkrementellen Anpassung der materialisierten Sichten entwickelt worden. Alle Verfahren
aktualisieren die relationalen Sichten für die meisten üblichen Operationen. Bei jeder Methode wer-
den 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 Me-
thoden, 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 gemein-
sames 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 hilf-
reichen 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
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
3 Materialisierte Sichten 19
3.1 Auswahl und Anwendung materialisierter Sichten . . . . . . . . . . . . . . . . . . .21
3.1.1 Das allgemeine Problem der Auswahl . . . . . . . . . . . . . . . . . . . . .21
3
-
INHALTSVERZEICHNIS 4
3.1.2 Einsatzgebiete von materialisierten Sichten . . . . . . . . . . . . . . . . . .22
3.2 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
3.3 Inkrementelle Anpassung materialisierter Sichten . . . . . . . . . . . . . . . . . . .26
3.3.1 Klassifikation des Sichtenanpassungproblems anhand von vier Dimensionen27
3.3.2 Inkrementelle Sichtenanpassungsalgorithmen auf Basis der vollständigen In-
formationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
4 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
4.2 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
4.3 Die Magic Updates-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
4.3.1 Ein Beispiel zur Änderungspropagierung . . . . . . . . . . . . . . . . . . .62
4.3.2 Magic Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
5 Vergleich der drei Methoden 71
5.1 Gemeinsames Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
-
INHALTSVERZEICHNIS 5
5.2 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
5.3 Beurteilung der Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
6 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 Datenbankmaterialisiertwerden, d.h., die ableitba-
ren 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 Datenbankkom-
munikation sehr weit verbreitet. Besonders ihre Anwendung inData Warehouse, Data Integrationund
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 ak-
tuellen Zustand der Datenbankrematerialisiertwird. 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 Sichtenanpassungbezeichnet. In den letzten vier Jahrzehnten wurde ein brei-
tes 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 wer-
den, haben zur Arbeit auf diesem Gebiet motiviert. Bei der Implementierung der verschiedenen Ver-
7
-
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 Fixpunkt-
Iteration. 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 Ce-
ri/Widom, die keine Rekursion und Aggregation zulassen.
Das zentrale Ziel dieser Arbeit liegt darin, einige repräsentative Verfahren zur materialisierten Sich-
tenanpassung 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 materialisiertenSichten,
• die Darstellung der Vor- und Nachteile der ausgewählten Methoden,
• ein Vergleich der beschriebenen Strategien anhand von einheitlichen Kriterien als Basis ihrerweiteren 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 vorge-
stellt, 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 Anpas-
sungsproblems, wird inKapitel 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 bildetKapitel 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 Sich-
ten 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 abge-
leitete 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 vorlie-
genden Basisfakten ermittelt.
9
-
2. Grundlagen deduktiver Datenbanken 10
2.1 Deduktionsregeln
Eine deduktive Regel in Datalog ist ein Synonym für eineSichtendefinition in SQL. Sichtdefinitionen
gehören zum DB-Schema; sie werden mittels derData Definition Language(DDL) des jeweiligen
Datenmodells ausgedrückt (z.B. CREATE VIEW Kommando in SQL). Eine deduktive Regel ist prin-
zipiell 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 materia-
lisierter Sichten erweitert worden. Allgemeine Sichten werden nicht materialisiert, sondern als An-
frageergebnis interpretiert, das dynamisch beim Zugriff generiert wird. Eine Sicht entspricht einem
dynamischen Fensterauf die zugrundeliegenden Basisrelationen, und Operationen, die auf Sichten
angewendet werden und durch (interne) Query-Umformulierung auf Basisrelationen abgebildet wer-
den.
-
2. Grundlagen deduktiver Datenbanken 11
Definition: SQL-Sicht
Jeder Ausdruck der Form
V (A1, . . . , An) ASQ
ist eine SQL-Sicht. Hier istS Sichtsymbol undA1, . . . , An Attributsymbole(n ≥ 1). Q ist eineSQL-Anfrage. Die Anzahln der Attribute der Sicht muss identisch sein mit der Anzahl der Terme der
Ergebnisliste der AnfrageQ.
Die Zuordnung zwischen den Termen der Ergebnisliste der SQL-AnfrageQ 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 wer-
den:
CREATE [RECURSIVE] VIEWV (A1, . . . , An) ASQ
Die RECURSIVE-Option muss nur für rekursive Sichten spezifiziert werden. Rekursive Sichten kön-
nen 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 wer-
den. Mengenoperatoren, die nicht der Verankerung dienen, sind nicht zugelassen.
Rekursive Sichten
Spezifikation der transitiven Hüllep einer Relationr:
1. Datalog:
p(X, Y )←− r(X, Y ) -Verankerung
p(X, Y )←− r(X, Z) ∧ p(Z, Y ) -lineare Rekursion
2. SQL mit rekursiver Sichtp
p(a1, a2) AS SELECTtr.a1, tr.a2 FROMr AS tr -Verankerung
UNION SELECTtr.a1, tp.a2 -lineare Rekursion
FROMr AS tr, p AS tp WHEREtp.a2 = tr.a1
-
2. Grundlagen deduktiver Datenbanken 12
3. SQL mit rekursiven Hilfsichten:
p(a1, a2) AS WITH RECURSIVEh(a1, a2) AS
SELECTtr.a1, tr.a2 FROMr AS tr UNION
SELECTtr.a1, th.a2 FROMr AS tr, h AS th WHEREth.a2 = tr.a1SELECTth.a1, th.a2 FROMh AS th
In SQL sind ausschließlich linear rekursive Sichten zugelassen.
Nichtlineare Rekursion in Datalog
p(X, Y ) ←− r(X, Y ) -Verankerungp(X, Y ) ←− p(X, Z) ∧ p(Z, Y )
2.2 Fixpunktsemantik deduktiver Datenbanken
Ableitungsregeln bedeuten nur etwas relativ zu einer gegebenen FaktenmengeF . Als Semantik kann
man dann die Menge aller aus dieser Basismenge mittelsR herleitbaren Fakten ansehen, die alsF ∗
bezeichnet wird. Dabei istF ∗ als der kleinste Fixpunkt einer bestimmten Funktion, die jeder Regel
zugeordnet wird, definierbar. Die Fixpunktiteration ist ein konstruktiver Weg, einModell 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 limi→∞
T ∗[R]i(F )
T ∗[R] wird als kumulative Ableitungsfunktion bezeichnet, die ihre erzielten Zwischenergebnisse auf-
sammelt bzw. kumuliert.T ∗[R] isr erforderlich um mehrstufige Ableitungen zu charakterisieren, denn
die Anzahl der erforderlichenT ∗R-Schritte ist vonR undF abhängig.T∗[Ri] hat eine rein deklarative
Bedeutung, die hier beispielhaft für eine RegelR1: p(X)← s(X, Y ), q(Y ) illustriert werden soll:
T ∗[R1](F ) =def {p(X)σ|σ ist eine konsistente Variablensubstitution, so dasss(X, Y )σ ∈ F undq(Y )σ ∈ F gilt} ∪ F
FürF = {s(1, 2), s(1, 3), s(2, 4), q(3), q(4)} ergibt sichT ∗[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 be-
zü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 Fixpunk-
titeration gewonneneF ∗ von (F ,R) ist der einzige, eindeutige minimale Fixpunkt vonT ∗[R], derF
ganz enthält.
Ein Abhängigkeitsgraph stellt die Beziehungen zwischen den Prädikaten einer deduktiven Daten-
bank dar. Prädikate im Graph stellen die Knoten dar. Eine Kantea→ b wird dann genau eingefügt,wenn eine Regel der Formb : − . . . a . . . existiert. Ist der Graph zyklisch, ist die Datenbank rekursiv.Prädikate, die im Abhängigkeitsgraph selbsterreichbar sind, heißen rekursiv.
EineStratifikation einer RegelmengeR ist eine Unterteilung vonR 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:
• Wennp ∈ RelD positiv vonq ∈ RelD abhängt, dann istλ(p) ≥ λ(q)
• Wennp negativ vonq abhängt, dann istλ(p) > λ(q)
Eine deduktive DatenbankD heißt stratifizierbar, wenn mindestens eine Stratifikation vonRelD exi-
stiert.
Die Stratifikation kann zur Darstellung des Prinzips der iterierten Fixpunktberechnung verwendet
werden. Die Semantik einer stratifizierbaren RegelmengeR bezüglich einer FaktenmengeF kann
nun formal definiert werden:
-
2. Grundlagen deduktiver Datenbanken 14
Der kleinste Fixpunkt einer Funktionf , der das ArgumentM enthält, wird mitlfp(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 lfp(Tneg ∗ [R#i], Fi−1) 1 ≤ i ≤ k
Die BedeutungF ∗ 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 vonTneg ∗ [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 Relati-
on. 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-by-
Klausel gruppiert werden, um darauf Aggregatfunktionen anzuwenden.
Wir wissen, dass eine Sicht für eine Datenbank sinnvoll ist, um logische Unabhängigkeit vom konzep-
tionellen 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 inter-
essanter Anwendungsgebiete für Sichten. Diese sind für konventionelle Datenbanken aus mehreren
Gründen sehr nutzlich.1lfp ist eine Abkürzung fürleast fix point
-
2. Grundlagen deduktiver Datenbanken 15
• Schema-Entwurf durch Sichtenintegration: Eine Möglichkeit das konzeptionelle Schema ei-ner Datenbankbottom upzu 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 wer-
den können.
• Anpassung des Datenmodells: Sichten können genutzt werden, um auf eine Datenbank miteinem anderen Datenmodell zuzugreifen. So können etwa Objekt-Sichten auf relationale Da-
tenbanken (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 Pro-blem auf, wie bei materialisierten Sichten. Ein Visualisierungssystem sollte stets den aktuellen
Datenstand repräsentieren, daher muss es bei Änderungen an den Daten entsprechend aktuali-
siert werden. Dies entspricht dem Sichtenanpassungsproblem.
2.4 Trigger
Für Triggersysteme hat sich bislang kein einheitliches und allgemein anerkanntes Konzept durchge-
setzt. Eine über die Grundlagen hinausgehende ausführliche Beschreibung und Klassifizierung ver-
schiedener aktiver Regel-Systeme sind u.a. in [Gri97], [CW96], [HW93] zu finden. Einsatzmöglich-
keiten 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 Kernfunk-
tionen 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 Be-
standteil des DB-Systems erkennt das Auftreten eines Ereignisses im Sinne des Regelkonzepts (Da-
tenmanipulationen, Zeitpunkte, abstrakte Ereignisse etc.) und ermittelt die von diesem Ereignis be-
troffenen 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 Trig-
ger 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 Änderungsan-
weisung 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än-
derte Fakt, so wird sie als instanzorientiert bezeichnet.
Es gibt zahlreiche Einsatzmöglichkeiten für Trigger. Nachfolgend werden einige der Wichtigsten da-
von 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
{BEFORE | AFTER}{INSERT | DELETE | UPDATE [ OF ]}
ON
[ORDER ]
[REFERENCING ]
[FOR EACH {ROW | STATEMENT}]
[WHEN ()]
-
2. Grundlagen deduktiver Datenbanken 17
::= OLD [AS] |
NEW [AS] |
OLD-TABLE [AS] |
NEW-TABLE [AS]
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 TriggerGehaltstestwird ausgelöst, wenn in der TabellePersÄnderungen in der SpalteGehalt
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 prototypi-
sche Funktionen für SQL-basierte DB-Systeme entwickelt wurden. Eine von IBM entwickelte DBS-
Komponente ist die Triggerkomponente’Starburst Rule System’[CW90], [CW91], [CW94], [Gri97].
In den verschiedenen Publikationen sind aufgabenspezifisch unterschiedliche Varianten des Trigger-
konzepts 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 WHENE1, ..., En
[ IF F ] THEN M1, ...,Mn PRECEDESG1, ..., Gm
wobei G, G1, ..., Gm Triggersymbole sind.Ei (1 ≤ i ≤ n) ist eines der Ereignissymbole INSER-TED INTO B, DELETED FROMB, UPDATEDB.Aj . Aj ist das Attributsymbol eines Attributs der
BasisrelationB. F ist eine SQL-Formel undMk (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 Starburst-
Trigger 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 determi-
nistisch ermittelt (Nettoeffektder 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’ru-
le assertion point’keine Ereignisse vorliegen, für die Trigger aktiviert werden können. Für die Net-
toeffektä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 ma-
nipulierten Fakten einer Relation liegen in systemintern verwalteten∆-Mengen (’transition tables’:
INSERTED / DELETED / OLD UPDATED / NEW UPDATEDB) 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 TriggerG wird vor den TriggernG1,...,Gm ausgeführt. Sind
keine Prioritäten definiert, feuern die Trigger in beliebiger Reihenfolge. Sind alle relevanten Trigger
für ein EreignisEi gefeuert, wählt die Triggerkomponente den TriggerG aus, der über keinen aktivier-
ten Vorgänger verfügt. BevorG ausgeführt wird, wird die BedingungF der IF-Klausel ausgewertet.
Ist F nicht erfüllt, so wirdG 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 Transakti-
on 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üh-
rung 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. Da-
bei 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 Ange-
stelltenrelation 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 In-
formationen 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 ma-
terialisierten 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 schnel-
len 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 wirdMaterialisierunggenannt. Die materialisierte Sicht ist also
eine ArtCachefü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 wiederkehren-
den 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 verursachtwurden
• Anzahl der Anfragen, die in der Vergangenheit mit dieser Sicht hätten beantwortet werden kön-nen 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 materiali-
sierten 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 Ände-
rungen ist zum ersten Mal in [KP81] erschienen. Der Begriffview materializationodermaterialized
view ist in [SI84] eingeführt worden. Laut Jeffrey Ullman1 ist der Ausdruckmaterialized viewein
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 Auswahl und Anwendung materialisierter Sichten
3.1.1 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 tem-
porä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 ge-
ringe 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 sta-
tische 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 Materiali-
sierung erfolgen große Leistungssteigerungen, allerdings entstehen durch ihre alleinige Anwendung
auch Nachteile:1In der Einleitung von [GM99]
-
3. Materialisierte Sichten 22
• Oft werden bestimmte Zusammenhänge gezielt untersucht, so dass zu einem bestimmten Zeit-punkt ä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, waseinen erhöhten Aktualisierungsaufwand zur Folge hat.
• Das Anfragemuster ändert sich beständig, so dass ständig eine Anpassung der materialisiertenSichten stattfinden müsste.
• Aufgrund der zunehmenden Globalisierung, kann es vorkommen, dass aus unterschiedlichenZeitzonen 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ög-
licht.
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 vermin-
dert.
-
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 Ware-
house kopieren zu müssen. Anfragen werden beantwortet, wobei auf den Zugriff auf die Quell-
datenbank verzichtet werden kann, der beschränkt oder sehr teuer sein kann.
Chronicle SystemsBanken, Handels- und Buchhaltungssysteme gehen täglich mit zusammenhän-
genden 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 Datenbankkapa-
zität liegen. Sichtenmaterialisierungen beantworten Anfragen nach den wichtigsten Informatio-
nen 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. Än-
dert 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 an-
gezeigten 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 Ab-
frage 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 Sich-
ten 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 Sichtenmateria-
lisierung verwendet werden.
3.2 Anpassung materialisierter Sichten
Nach der Erzeugung mehrerer materialisierter Sichten stellt sich die Frage, wie diese bei einer Ände-
rung 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 Bedingun-
gen, 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 Zeit-
punkt 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 ko-
stengünstiger ist als die komplette Neuberechnung.
Mit der sogenenntenRe-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 vonautonomer 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 schwieri-
ger 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. Änderungs-
operationen werden demnach wie eine aufeinander folgende Einfüge- und Löschoperation be-
handelt.
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 Ex-
tremfall immer die ganze Datenbank auf einmal aktualisiert werden muss.
5. Der Zeitpunkt der Aktualisierung
Sofortige Aktualisierung Bei einer Änderung der Basisdaten werden gleichzeitig die abgelei-
teten 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 Basis-
daten. 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 wer-
den einige wichtigeFragen, die diese Probleme beschreiben, aufgelistet:
• Sollen die Sichtenmaterialisierungen vor oder nach Abschluss (commit) der Transaktion, diedie 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 erfol-gen?
• Soll die Sichtenpflege automatisch (z.B. regelbasierend) oder benutzergesteuert eingeleitet wer-den?
• Lässt sich ein kostenbasiertes Modell entwickeln, das zwischen verschiedenen Lösungswegenabwä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 Aus-
druck 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 Sichtenan-
passung zu charaktersieren bzw. zu vergleichen. In [GM95] und [GM99]werden einige Ansätze vor-
gestellt, 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
DatenmanipulationsspracheMit welchen Modifikationen kann die Anpassungmethode umgehen
SichtendefinitionsspracheIn 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 Infor-
mationen
Im Falle der vollständigen Informationen stehen vier bekannte Algorithmen zu Verfügung. Die fol-
genden 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 aktua-
lisierten Sichtenmaterialisierungen.
Propagation / Filtration (PF) Algorithmus Der PF-Algorithmus arbeitet analog zu DRed, die Än-
derungen 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 Basis-
relationen 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 ge-
trennt 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 um-
fasst, ist noch ein großes Problem.
Verwendung unvollständiger Informationen kann in verschiedenen Formen auftreten:
Nullinformation Query independent of updatebzw. 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 Da-
tenbanken 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 Delta-
Propagierungsmethode, die Algorithmen zur Aktualisierung der materialisierten Sichten in relationalen-
und deduktiven-Datenbanken präsentiert. Die Implementierung dieses Verfahrens wird alspassivbe-
zeichnet, 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
1auchMagic Updates-Methode genannt
30
-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung 31
Rekursion und allgemeine Rekursion beinhalten. Dieses Verfahren erfordert Zugriff auf alle Basis-
tabellen 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:
Rcompilieren−−−−−−−→ ∆R
Durch Regelcompilierung wird ein spezielles Inferenzverfahren erzielt, derInterpreter. 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 Delta-
Regeln und Fakten (Basisfakten, Deltafakten, materialisierte Fakten) werden abgeleitete Deltafakten
erzeugt.
Die Autoren schlagen zweiinkrementelle Sichtenanpassungsalgorithmenvor:
1. Counting-Algorithmus: Arbeitet mit nichtrekursiven Sichten, die auch Negation und Aggre-
gation 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 nichtrekur-
sive 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 Men-
gen 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 de-
duktiven 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 er-
reicht ist.
Sichere und stratifizierte Negation und Aggregation (z.B. Summierung und Durchschnitt von Attri-
buten) 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 Tupelst in der Sicht und speichert die-
sen Wert zusätzlich in der materialisierten Sicht alscount(t) ab. Counts sind eine Art Iterationszähler
für Deltafakten. Ein Tupelt wird mit der Anzahl seiner Ableitungen in folgender Form geschrieben:
t ∗ i, wobeii 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 Wert0 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 mancount(t)
als die Anzahl des Vorkommens eines Tupelst 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 Mi-
nimum 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 Sin-
ne 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 ermit-
telt. Ist ein später einzufügender Fakt noch nicht vorhanden, so wird der Fakt mitcount = 1 eingefügt.
Bei bereits vorhandenen Fakten wird der Zählerwert nur entsprechend aktualisiert. Physisch gelöscht
wird ein Fakt erst, wenncount = 0 ist.
UNION-Operator⊎
: 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 Mengens1 unds2:
s1 ] s2 (gelesen:s1 unds2) mit Countsc1 undc2, wird der Operator wie folgt definiert:
• Falls ein Tupelt nur in einer der Mengens1 oders2 mit dem Countc auftritt, dann kommt dasTupelt mit Countc in s1 ] s2 vor.
• Falls ein Tupelt in s1 unds2 mit Countsc1 undc2 vorkommt undc1 + c2 6= 0, dann ist Countvons1 ] s2 gleichc1 + c2, sonst (d.h.c1 + c2 = 0) erscheintt nicht ins1 ] s2
Folglich ist P ν = P ] ∆(P ). Dieser Join-Operator ist also eine Neudefinition für Relationen mitCounts: 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 Counting-
Algorithmus garantiert, dass kein Tupel weder inP noch inP ν einen negativen Count hat. Die Tupel
in der Änderungsrelation∆(P ) können negative Counts haben.
Durch Verwendung dieses Operators werden Mehrfachableitungen verhindert.
2Ein 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 Teil-
graph (SCC)4 aufgebaut wird, entsteht ein Schichten-Graph und man redet von derStratum Number
(SN). Knoten des Abhängigkeitsgraphen bezeichnen die Prädikate und die Kanten die Regeln. Wir
betrachten dazu ein Beispiel mit der Basisrelationlink und abgeleitete Relationenhopundtri-hop, die
wie folgt definiert sind: Ein gerichteter Pfeil vom Knotenlink zum Knotenhop (s. Abbildung) sagt
aus, dass das Prädikathopvom Prädikatlink abhängig ist, d.h.link ist ein Bestandteil des Rumpfes
der Regel mit dem Prädikathop 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 RelationP beinhal-
tet, wenn Änderungen in Basisrelationen stattfinden.∆(P ) = {ab ∗ 4,mn ∗ −2} bedeutet z.B., dassfür das Tupelp(a, b) vier Ableitungen eingefügt und zwei Ableitungen des Tupelsp(m,n) gelöscht
werden.
3reduced dependency graph4strongly connected component
-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung 35
P ν verweist auf die RelationP 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 Regelde-
finitionen für das abgeleitetes Prädikatp definieren.
Definition: ∆-Regeln
Für jede Regel der Form
(r) : p : −s1, ..., sn;
werdenn ∆-Regeln∆(r) erstellt, die das Prädikat∆(p) definieren:
(∆(r)) : ∆(p) : −sν1, ..., sνi−1,∆(si), si+1, ..., sn
Dasν steht fürneu, 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üs-
sen 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 al-
ten 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 be-
kommen.
Gegeben ist eine Sichtdefinition für eine abgeleitete Relationp aus Basisrelationstermena undb. Die
Relationp wird wie folgt aus TupelnA undB berechnet:
-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung 36
(v): p(X, Y ) : − a(X, Z), b(Z, Y );
Wenn die Basisrelationena und b geändert werden, müssen die Tupel in der abgeleiteten Relation
p auch geändert werden. Die neuen MengenAν undBν werden alsA + ∆(a) bzw. B + ∆(b) ge-
schrieben.∆(a) und∆(b) können beide eingefügte und gelöschte Tupel mit positiven bzw. negativen
Counts enthalten. Die neue Menge der Fakten fürp wird durch folgendes Programm berechnet:
pν(X, Y ) : − aν(X, Z), bν(Z, Y );
Wenn mana durch (a+∆(a)) undb 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 vonp. 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 Formelaν = 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 Regelnv1 undv2 ergeben sich die Werte
für ∆(p) undpν :
Aus der Regelv1 folgt ∆(p) = {18 ∗ −1}
Aus der Regelv2 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 MengenAν undBν .
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 übertra-
gen 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 RegelnR, 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 RegelnR do
initialisiereP ν durchP
(P : materialisierte Faktenmenge)
Initialisiere ∆(P ) durch leere Menge
while falls keine Regel ausgewertet ist, werden die abgeleiteten Regeln - angefangen
von der untersten Schicht - ausgewertetdo (Die Prädikate sind in einem geschich-
teten RDG konstruiert und die Counts werden während der buttom-up-Propagierung
berechnet)
for für jede abgeleitete Relationdo
berechne die Menge der abgeleiteten Deltafakten∆(P) anhand der oben defi-
nierten Delta-Regel-Definition
(Die Definition wird aus der Regel für abgeleitete Relationen in alten und neu-
en Zuständen und der Formel
P ν = P ]∆(P )
gewonnen ;
P ν bezeichnet die RelationP nach der Anpassung der Änderungen inP )
Bezeichner als ausgewertet
done
done
done
end
Die Regeln sind nach Schichtennummern sortiert, die durch eine topologische Sortierung des Abhän-
gigkeitsgraphen ü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 bot-
tom-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 RelationP ν aus Mengen von Änderungen der RelationP 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 nicht-
rekursive Schicht besteht aus einem einzigen Prädikat, das durch einer oder mehreren Regeln definiert
wird. Jeder Operator wieJoin, Select, Project undUnion 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 Tu-
pels auftreten oder Speicherung eines Counts für jedes Tupel. In beiden Fällen arbeitet der Algorith-
mus ohne zusätzlichen Kosten für Duplikatberechnung. Der⊎
-Operator im Algorithmus funktioneiert
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 Schichti + 1 sind die Counts voni oder von den
unteren Schichten nicht erforderlich. Jedes Tupel hat in der Schichti oder in den unteren Schichten
nur eine Ableitung. Nach der Berechnung der Duplikate in der Schichti + 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 Sichthopberechnet.
-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung 40
Beispiel
Wir betrachten die Relationenhopundhopν nach der Verwendung der beiden Regelnv1 undv2:
∆(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 Tupelhop(ac∗−1) in ∆(hop) nicht auftritt und auch nicht imStufenprozess der Relationtri-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 nega-
tiven Literalen). In dem Verfahren nach [GMS93] wird vonsicherer Negationausgegangen, 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ädikatp negativ von einem anderen Prädikatq abhängt, dann
ist SN(p) < SN(q). Dabei bezeichnetSN 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 Faktp(a, b, ...) TRUE istundcount(p(a, b, ...)) > 0, Eins, wenn der Faktp(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 undfolglich wird ¬p(a, b, ...) den Wert FALSE haben, wennp(a, b, ...) nur einmal abgeleitet wird.
Negation in rekursiven Sichten kann zur Unstratifizierbarkeit führen. Negative Regeln beim Counting-
Algorithmus 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 Regelr, 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 Regelri vorkommen:
Fall 1: sνj = (¬q)ν , j zwischen1 und i − 1: (¬q)ν ≡ ¬(qν), da das Prädikatq in einer niedrigerenSchicht alsp liegt und schon berechnet ist.
Fall 2: sj = ¬q, j zwischeni + 1 undn: Die Relation über dem Prädikat¬q wird alsQ bezeichnet.Q wird aus der RelationQ und aus den positiven Prädikaten in der Regelr, die die Variablen
X undY beinhalten, berechnet. Ein Tupel(a, b) mit dem Count1 ist in der RelationQ, wenn
entweder ein positives Prädikat in der Regelr die Wertea und b zu den VariablenX und Y
zuordnet, oder das Tupelq(a, b) ist False ((a, b) /∈ Q).
Fall 3: ∆(si) = ∆(¬q): ∆(¬q) wird aus Termen von∆(q) und den Originalwerten fürq berechnet.Daq und∆(q) schon berechnet sind, kann∆(¬q) ohne Auswertung der anderen Prädikate inrbestimmt werden.∆(Q) kann wie folgt definiert werden:
Definition: ∆(Q)
AngenommenQ ist die Relation, die über das Prädikatq definiert wird und∆(Q) repräsentiert die
Änderungen inQ. Für ein Tupelt in ∆(Q) gilt:
count(t) =
1 falls t ∈ ∆(Q) undt /∈ Q ]∆(Q)−1 falls t ∈ ∆(Q) undt /∈ QBeispiel:
Gegeben:
p(X) : − s(X, Y ),¬q(Y )
q(X) : − r(X)
s = {ab, ad, dc, bc, ch, fg}
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 istQ = {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 nicht-
rekursiver 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 Tu-
pels 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 einzel-
nen 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 Tupelt in
dieser Menge ist, wenn die Veränderungen der Basisrelationen nur ein einziges Vorkommen
des Tupelst 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 materia-
lisierten 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 Schicht0. Jedes abgeleitete Prädikat in der Schichti ist nur von den
Prädikaten in den unteren Schichten, also1, . . . , i − 1 abhängig. Bei den Änderungen in der Schichti werden nur die Schichten mitSN ≥ i betrachtet. Dieser Transformationsvorgang wird nachfolgendgenauer beschrieben:
• Lösche eine Obermenge der abgeleiteten Tupel, die gelöscht werden müssen. Für jede Regelrder Form
(r) : p : − s1, . . . , si, . . . , sn
erzeugen ∆−-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. Istsischon in einer vorherigen Schicht berechnet worden, so sind inδ−(si) die wirklich gelöschten
Tupel vonsi enthalten, d.h.δ−(si) ist keine Abschätzung. Sonst istδ−(si) die momentane Ab-
schätzung der zu löschenden Tupel, die durch diese Regeln ermittelt wurde. Mitsi 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 Regelr eine∆r-Regel:
(∆r) : δ+(p) : − δ−(p), sνi , . . . , sνn
Dabei istδ−(p) die in Schritt 1 berechnete Menge von Tupeln. Fürsνi ist der jeweils aktuelle
Wert, der in Schritt 1 und 2 bisher berechnet wurde, bzw. der neue gegebene Wert der Basisre-
lation 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ürjede Regelr, n ∆+-Regeln der Form:
(∆+i ) : ∆+(p) : − sν1 , . . . ,∆+(si), . . . , sνn
∆+(si) ist der aktuelle Stand bzw. die Änderungen der Basisrelationen. Dies entspricht dem Er-
gebnis 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 Basisrelationlink und die Sichthop:
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 al-
le abgeleiteten Daten materialisiert sein, also auch die Zwischenergebnisse bei der Berechnung der
Sichten.
-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung 45
4.2 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 sogenannteProduktionsregeln(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 (minuswird hier nicht verwendet) und die Verwendung aller Vergleichsoperato-
ren mitall ist auch nicht erlaubt.
Starburst ist das Basissystem dieser Methode. Starburst ist ein aktives Datenbanksystem, das mit
Produktionsregeln bei bestimmten Ereignissen oder Datenbankzuständen Datenmanipulationsopera-
tionen 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 SichtenTrigger (Starburst-Trigger) generiert, die in-
duzierte Ä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 Metho-
de 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. Da-
bei 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 Ände-
rungen 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/Widom-
Verfahrens. 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, in-
dem 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 umge-
kehrt.
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 speziali-
siert. Ein wesentlicher Punkt ist dabei die Verwendung der Schlüsselattribute. Es werden nur Ände-
rungen 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 Du-
plikattest der während der Transaktion geänderten Fakten beschränkt wird. Die Syntax der Erzeugung
von Produktionsregeln ist wie folgt definiert:
CREATE RULE ON WHEN
INSERTED | DELETED | UPDATED [(Attributname)]
[IF ] THEN
[PROCEDES ]
[FOLLOWS ]
-
4. Ausgewählte Methoden zur inkrementellen Sichtenanpassung 47
Jede Regel hat einen eindeutigen Namen () und ist mit einer spezifischen Relation () assoziiert. Jede Regel überwacht ein oder mehrere Ereignisse (also die triggernden Ope-
rationen der Regel); andererseits kann ein SQL-Ausdruck,