inkrementelle methoden zur anpassung materialisierter ...lisierter sichten erweitert worden....

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.


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


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 .


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:


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


• 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.


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 ()]


::= 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.


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.


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]


• 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.


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.


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


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.


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:


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:


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:


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.


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


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


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


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:


(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:


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.


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.


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.


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:


(∆(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)):


∆(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.


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.


• 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.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


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 ]


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,

inkrementelle methoden zur anpassung materialisierter ...lisierter sichten erweitert worden....

Documents