Technical Report CS-02-21
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Technical Report CS-02-21
Der BACKCHASE zur Unterstützung von Data
Provenance und Schema-Evolution
Florian Rose und Andreas Heuer
Universität Rostock
Fakultät für Informatik und Elektrotechnik
Institut für Informatik
Lehrstuhl für Datenbank- und Informationssysteme
Long version of a 6-page paper for
32nd GI-Workshop on Foundations of Databases 2021,
erhältlich unter:
https://dbis.informatik.uni-rostock.deDer BACKCHASE zur Unterstützung von Data Provenance
und Schema-Evolution
Florian Rose Andreas Heuer
Lehrstuhl für Datenbank- und Lehrstuhl für Datenbank- und
Informationssysteme Informationssysteme
Institut für Informatik Institut für Informatik
Universität Rostock Universität Rostock
Florian.Rose@uni-rostock.de Andreas.Heuer@uni-rostock.de
ABSTRACT gesamten Datenbestandes anzulegen, ist es wünschenswert,
Der CHASE-Algorithmus ist ein Multifunktionswerkzeug der nur genau diejenigen Tupel in der aktuellen Schemaversi-
Datenbankforschung. Ursprünglich für die Optimierung des on aufzuheben, welche an einer Anfrage beteiligt waren, de-
Datenbankentwurfs genutzt, wird er heutzutage auch für ren Reproduzierbarkeit vorausgesetzt wird. Weiter soll dies
den Datenaustausch und Data Cleaning verwendet und kann auch nur passieren, falls die Schema-Evolution dafür sorgt,
ebenfalls genutzt werden, um Anfragen zu optimieren. Für dass das entsprechende Tupel in der nächsten Version hierfür
einige Anwendungen reicht eine CHASE-Phase alleine je- nicht ausreichend abgebildet wird.
doch nicht aus. Teilweise wird eine Nachbearbeitung, eine so- Der CHASE-Algorithmus (siehe Abschnitt 2.1) bietet sich
genannte BACKCHASE-Phase, benötigt. Dies ist beispiels- hier an. Der CHASE arbeitet Parameter, etwa Abhängigkei-
weise der Fall, wenn Auswertungen zum Zweck der Rück- ten (also spezielle Integritätsbedingungen) oder Anfragen,
verfolgbarkeit (Provenance) invertiert werden sollen. in ein Datenbankobjekt, etwa Anfragen oder Datenbankin-
In dieser Arbeit fassen wir zusammen, wie der Ansatz des stanzen, ein. Er kann daher sowohl zur Transformation von
CHASE und BACKCHASE verwendet werden kann, um die Datenbanken mit Hilfe von Anfragen als auch zur Transfor-
Why-Provenance von Anfragen unter Schema-Evolution zu mation von Anfragen unter Abhängigkeiten eingesetzt wer-
gewährleisten. den. Da er direkt zur Bildung der Anfrageergebnisse und
einer neuen Schemaversion genutzt werden kann [1], kön-
nen andere CHASE-Schritte zur Berechnung der aufzuhe-
Keywords benden Tupel direkt dort ansetzen können. Darüber hinaus
CHASE, BACKCHASE, Data Provenance, Schema-Evolution sind Evolutionsschritte und Anfragen für den CHASE vom
gleichen Parametertyp, sodass algorithmisch nicht zwischen
1. MOTIVATION ihnen unterschieden werden muss.
Wir werden im folgenden Abschnitt 2 den Stand der For-
Die Rückverfolgbarkeit von Daten bei wissenschaftlichen
schung in den Bereichen CHASE, BACKCHASE, Data Pro-
Auswertungen bietet die Grundlage der Nachvollziehbarkeit
venance und Schema-Evolution zusammenfassen. Danach
von veröffentlichten Statistiken, ein wichtiges Qualitätsmerk-
werden wir in Abschnitt 3 die Nutzung des BACKCHASE
mal der wissenschaftlichen Praxis. Für das Forschungsdaten-
für die Data Provenance, speziell die Why-Provenance, und
management ist die Provenance der Auswertungsdaten da-
der Schema-Evolutionen vorstellen. In Abschnitt 4 werden
her von großem Interesse. Allerdings unterliegen die Struk-
wir die den vorgestellten Ansatz hinsichtlich der Terminie-
turen solcher Datenbanken ebenfalls Schema-Evolution [4].
rung und der Erweiterung des Standard-CHASE untersu-
Dies kann die Reproduzierbarkeit von Auswertungen, die
chen, bevor wir in Abschnitt 5 abschließend offene Frage-
unter der letzten Schemaversion durchgeführt wurden, be-
stellungen skizzieren.
einträchtigen, z. B. falls ein Attribut entfernt wird, welches
Teil der Ergebnisrelation für diese Auswertung war. Offen-
sichtlich ist es ohne dieses Attribut nicht möglich, das voran- 2. STAND DER FORSCHUNG
gegangene Anfrageergebnis mit den zugrundeliegenden Da- Wir stellen nun den CHASE-Prozess vor, motivieren eine
ten zu reproduzieren. Folglich muss vor der Überführung in zweite CHASE-Phase, die BACKCHASE genannt wird, und
die nächste Schemaversion sichergestellt werden, dass die an stellen den Stand der Forschung in beiden Gebieten sowie
der Anfrage beteiligten Tupel in der aktuellen Schemaversi- in unseren grundlegenden Fragestellungen why-Provenance
on ”eingefroren” werden. Statt hierfür jedoch eine Kopie des und Schema-Evolution vor.
2.1 CHASE & BACKCHASE
Der CHASE-Algorithmus ging aus der Datenbankfor-
schung als Werkzeug zum Schlussfolgern mit Integritätsbe-
dingungen hervor. Dabei wird eine Menge von Abhängig-
keiten Γ, der CHASE-Parameter, auf ein CHASE-Objekt
d angewandt und erweitert dies durch Forward-Chaining
32nd GI-Workshop on Foundations of Databases (Grundlagen von Daten-
banken), 25.05.2021 - 28.05.2021, Grimma, Germany. so, dass d dem CHASE-Parameter Γ genügt [5]. Grundle-
Copyright is held by the author/owner(s). gend werden zwei Arten von Abhängigkeiten, die equality-generating dependencies (EGDs) und tuple-generating de- • (4) Anfragen semantisch optimieren, indem man Inte-
pendencies (TGDs), unterschieden [13]. Eine EGD stellt die gritätsbedingungen als CHASE-Parameter in die An-
Gleichheit bestimmter Werte sicher und ist eine Formel der frage einarbeitet [15].
Form
Die Anwendungsfälle (1) und (2) wenden also Datentrans-
∀~ x) → x1 = x2 .
x : F (~ formationen (s-t-TGDs) oder Abhängigkeiten (EGDs, TGDs)
Hierbei ist ~x ein Variablenvektor mit x1 , ..., xn als Kompo- auf Datenbankinstanzen an. Der CHASE realisiert hierbei
nenten. F ist eine Konjunktion von Prädikaten der Form nun diese Aufgabe vollständig. Wir werden später sehen,
Ri (~x), wobei Ri Relationenschemata des Datenbankschemas dass in unserem Fall der Bestimmung der why-Provenance
sind. TGDs hingegen rufen die Generierung neuer Tupel her- für eine Anfrage der CHASE diese Anfrage ausdrücken kann,
vor und sind Formeln der Form für die Bestimmung der why-Provenance aber eine BACK-
CHASE-Phase angeschlossen werden muss, die die Invertie-
∀~x : F1 (~
x) → ∃~
y : F2 (~
x, ~
y ). rung der Anfrage umsetzt.
Hierbei muss in F1 jede Komponente aus ~ x mindestens ein- Auch für die Anwendungsfälle (3) und (4) reicht eine ein-
mal vorkommen. Eine besondere Form von TGDs sind source- zelne CHASE-Phase nicht aus. Die CHASE-Phase berechnet
to-target-TGDs (s-t-TGDs). Bei ihnen ist der Rumpf (linke hier ein Zwischenergebnis, welches für die BACKCHASE-
Seite der Abhängigkeit) über einem Quellschema S und der Phase, in diesem Fall eine zweite Anwendung des CHASE
Kopf (rechte Seite) über einem Zielschema S 0 definiert. Ei- mit modifizierten Abhängigkeiten, verwendet wird [9].
ne s-t-TGD kann somit als Datenbanktransformation oder
• Im Anwendungsfall (3) werden Sichten, etwa darge-
(falls das target aus nur einer Relation besteht) als Anfra-
stellt durch s-t-TGDs, in Anfragen eingearbeitet. Da-
ge an eine Datenbank verstanden werden. Durch die Be-
durch wird die Originalanfrage um nutzbare Sichten
schränkung auf Konjunktionen von Prädikaten, betrachten
erweitert. Da die Originalanfrage aber nun durch eine
wir im Folgenden nur Anfragen und Evolutionsoperationen,
äquivalente Anfrage, die ausschließlich Sichten nutzt,
die ausschließlich als Konjunktionen darstellbar sind. Dis-
ersetzt werden soll, muss diese Art der Minimierung
junktionen lassen sich spätestens in der BACKCHASE-Phase
der erweiterten Anfrage in der BACKCHASE-Phase
nach der Invertierung nicht ohne Zusatzinformationen (Zeu-
realisiert werden.
genbasis einzelner Tupel) verarbeiten.
Bei der Anwendung des CHASE wird dann im CHASE-
• Im Anwendungsfall (4) werden Integritätsbedingungen
Objekt nach Mustern des Rumpfes jeder Abhängigkeit ge-
durch den CHASE in eine Anfrage eingearbeitet. Die
sucht. Ein solcher Trigger ist aktiv, falls der Kopf seiner
Formalisierung der Integritätsbedingungen ist somit in
entsprechenden Abhängigkeit noch nicht im CHASE-Objekt
der Anfrage bekannt“ und kann dort genutzt wer-
erfüllt ist. ”
den. Um diese Kenntnis aber für die semantische An-
frageoptimierung ausnutzen zu können, muss in einer
Algorithm 1: Standard-CHASE auf CHASE-Objekt d BACKCHASE-Phase die Anfrage minimiert werden,
forall Trigger τ für Abhängigkeit γ ∈ Γ do indem aufgrund der Integritätsbedingungen überflüs-
if τ ist aktiv then sig gewordene Anfrageoperatoren entfernt werden.
if τ hat Form ∀~ x) → ∃~
x : F1 (~ y : F2 (~
x, ~
y ) then
Nimm Kopf von τ in d auf Im Anwendungsfall (3) wird die BACKCHASE-Phase wie-
else if τ hat Form ∀~ x) → x1 = x2 then
x : F (~ der mit dem CHASE realisiert. Die BACKCHASE-Phase
if x1 , x2 sind Konstanten und x1 6= x2 then muss aber nicht zwingend eine zweite CHASE-Phase sein
CHASE schlägt fehl [16]. Je nach Anwendungsfall können auch hier verschiedene
else if x2 ist Konstante then Techniken Ansatz finden. Etwa werden im Anwendungsfall
x1 ← x2 (4) verschiedene Techniken zur semantischen Optimierung
else eingesetzt.
x2 ← x1
Die BACKCHASE-Phase
In Abbildung 1 zeigen wir schematisch den Einsatz des
BACKCHASE für die Anwendungsfälle (3) und (4): Im An-
Anwendungen des CHASE wendungsfall (3) wird eine Anfrage Q an Basisrelationen ei-
ner Datenbanken um Zugriffe auf verwendbare Sichten an-
Da sich diverse Bedingungen als EGDs bzw. TGDs formulie-
gereichert, die CHASE-Parameter enthalten dann die Sicht-
ren lassen und die Berechnung deren Implikation auf Instan-
definitionen. Die BACKCHASE-Phase minimiert nun die-
zen oder Anfragen verschiedene Ziele erfüllen kann, ist der
se erweiterte Anfrage und schränkt sie (falls möglich) aus-
CHASE vielseitig einsetzbar. So lassen sich unter anderem
schließlich auf Zugriffe über die Sichtrelationen ein (Anfrage
• (1) Datenmigrationen als s-t-TGDs für den CHASE Q0 ). In der BACKCHASE-Phase wird der CHASE mit in-
auf einer Datenbankinstanz formulieren [10], versen Sichtdefinitionen angewendet [9]. Im Anwendungsfall
4 werden Integritätsbedingungen als CHASE-Parameter in
• (2) Data-Cleaning-Probleme durch Anwendung des
die Anfrage Q eingearbeitet. Die BACKCHASE-Phase mini-
CHASE auf einer Datenbankinstanz mit bestimmten
miert dann diese Anfrage, indem sie überflüssige Operatio-
EGDs zur Bereinigung lösen [12],
nen (etwa Verbunde) eliminiert. In diesem Anwendungsfall
• (3) Anfragen durch Sichten beantworten, indem man ist die BACKCHASE-Phase ein durch homomorphe Abbil-
den CHASE mit den Sichtdefinitionen auf der Anfrage dungen der Anfrage gesteuerter, äquivalenzerhaltender Re-
als CHASE-Objekt ausführt [9], sowie duktionsprozess [15].neue Anforderungen an die Anwendung [17]. Deshalb rei-
chen die möglichen Operationen während einer Evolution
vom simplen Hinzufügen eines neuen Attributs bis hin zu
komplexen Berechnungen neuer Werte. Auch Evolutions-
operationen lassen sich als s-t-TGDs und EGDs darstel-
len. Hierbei ist das Quellschema die aktuelle Schemaversi-
on und das Zielschema die Folgeversion. Sowohl Anfragen
als auch Schema-Evolution liegen die Basisoperationen Se-
lektion (Attribut gleich Attribut und Attribut gleich Kon-
stante), Projektion, Verbund und die Umbenennung von Re-
lationen und Attributen zugrunde. In beiden Fällen inter-
Figure 1: CHASE und BACKCHASE essieren uns die CHASE-Inversen [11]. Diese drücken den
Grad des Informationsverlustes aus, wenn wir versuchen,
die Originalinstanz aus dem CHASE-Ergebnis durch Inver-
Die BACKCHASE-Phase für die why-Provenance tierung der Abhängigkeiten zu rekonstruieren. Dies ist für
Die BACKCHASE-Phase wurde für die Anwendungsfälle (1) unseren Anwendungsfall von großer Relevanz, da die Be-
und (2) bisher nicht benötigt. Wir werden sie in Abschnitt rechnung der an der Anfrage beteiligten Tupel und ihrer
3 aber einführen. Hier wollen wir das Anfrageergebnis ei- Attribute Grundlage des in Abschnitt 3 vorgestellten An-
ner Anfrage, verstanden als Datenbanktransformation wie satzes ist. Dafür rekonstruieren wir die Teilinstanz unserer
in (1), mit Hilfe der Why-Provenance auf die minimale Zeu- Originaldatenbank, müssen dabei aber darauf achten, dass
genbasis, also die relevanten Originaltupel aus der Daten- keines der für die Anfrage bzw. Evolution relevanten Tupel
bank, zurückführen. Der Schritt der Why-Provenance wird bei der Rekonstruktion verloren geht. Daher benötigen wir
durch eine erweiterte inverse Anfrage dargestellt, die wir bezüglich der an einer Anfrage bzw. Evolution beteiligten
als BACKCHASE-Phase verstehen. Analog werden wir ei- Tupel eine tupelerhaltend-relaxierte Inverse, d. h., dass die
ne Schema-Evolution als eine Datenbanktransformation wie durch den BACKCHASE gewonnene Datenbankinstanz auf
in (1) verstehen. Um die neue Datenbank nach der Evo- die Originalinstanz abbildbar ist und die gleiche Tupelzahl
lution in die alte Darstellung vor der Evolution rückrech- besitzt [2].
nen zu können, müssen wir auch hier die Evolution in einer
BACKCHASE-Phase invertieren. 3. NUTZUNG DES BACKCHASE
Zunächst zeigen wir in Unterabschnitt 3.1, wie die oben
2.2 Data Provenance genannten Basisoperatoren und komplexere Operationen für
Die Provenance beschäftigt sich mit der Frage nach dem Anfragen und Evolutionen als Abhängigkeiten (s-t-TGDs),
Ursprung von Daten. Insbesondere ist dies für die Nach- und somit als Parameter für den CHASE-Algorithmus, for-
vollziehbarkeit von wissenschaftlichen Auswertungen inter- muliert werden können. Wir verwenden hierbei eine Kurz-
essant. Hauptsächlich unterscheidet man drei Abstraktions- schreibweise, bei der nur existenzquantifizierte Variablen ex-
stufen der Provenance, Where-, Why- und How-Provenance. plizit als solche angegeben werden. Die Namen der Variablen
Diese beschreiben in unterschiedlichem Detailgrad, woher entsprechen den Namen der Attribute.
die Ergebnisdaten stammen. Dies reicht von der Benennung Danach werden wir in Unterabschnitt 3.2 dann die Basis
der Datenquellen (Where), also den Relationen und Daten- für den BACKCHASE-Prozess legen, indem wir die Pro-
bankschemata [7], über die Angabe der beteiligten Tupel venance- und Evolutionsschritte über mehrere Stufen hin
(Why), einer sogenannten Zeugenbasis [6], bis zu Provenance- invertieren und komponieren. Hierbei müssen wir insbeson-
Polynomen (How) [14], welche aussagen, wie die beteiligten dere berücksichtigen, dass wir bei der Komposition verschie-
Tupel kombiniert wurden. dener Schritte wertvolle Zwischeninformationen nicht verlie-
Der CHASE kann genutzt werden, um ein Anfrageergeb- ren. Die s-t-TGDs werden hier als Transformationssprache
nis zu berechnen. Hierzu formuliert man die Anfrage als nicht mehr ausreichen, wir müssen auf Konstrukte der Prädi-
s-t-TGD und wendet sie mittels des CHASE auf die ent- katenlogik zweiter Ordnung (so-TGDs, second-order TGDs)
sprechende Datenbankinstanz an. Aus dem Anfrageergebnis ausweichen [11].
lassen sich die beteiligten Tupel errechnen, indem man die
Inverse der Auswertung bildet. Hierzu führt man den CHA- 3.1 Anfragen und Schema-Evolution als s-t-
SE auf der Ergebnisrelation mit der invertierten s-t-TGD TGDs
der Anfrage aus. Je nach Art der Anfrage können sich un- Wir werden nun die von uns verwendeten Operatoren der
terschiedliche Arten von Inversen ergeben, welche mittels zu- Relationenalgebra als s-t-TGDs darstellen.
sätzlicher Provenance-Annotationen noch verbessert werden
können [2, 11]. Ziel ist es, eine möglichst genaue CHASE- Selektion.
Inverse zu erhalten, auch wenn Anfragen in der Regel ver- Die Selektion auf Konstanten A = c lässt sich als s-t-
lustbehaftet sind und sich somit nicht jede Information re- TGD formulieren, indem die Konstante an die entsprechende
konstruieren lässt. Stelle im relationalen Atom gesetzt wird.
2.3 Schema-Evolution R(A1 , ..., An−1 , c) → R0 (A1 , ..., An−1 , c)
Die Evolution eines Datenbankschemas ist der Übergang Die Inverse kann hier gebildet werden, indem Kopf und
von einer Schemaversion in eine neue. Diese sind durch Än- Rumpf der Abhängigkeit vertauscht werden.
derungen im Anwendungsgebiet begründet, z. B. neue rele-
vante Informationen, die zuvor nicht erhoben wurden, oder R0 (A1 , ..., An , c) → R(A1 , ..., An , c)Bezüglich der Originalinstanz liegt hier eine tupelerhaltend- Dabei gilt, dass der weniger genaue Inversentyp dominiert
relaxierte Inverse vor [2]. Bezüglich der an der Anfrage bzw. [2, 11]. Hierbei muss jedoch in einem Fall besonders auf die
Evolution beteiligten Tupel liegt jedoch eine exakte Inverse Projektion geachtet werden. Für die Auswertung relevante
vor [18]. Die Selektion Ai = Aj lässt sich analog umsetzen, Attribute, die nicht im Kopf der TGD vorkommen, müssen
indem Ai bzw. Aj an den entsprechenden Stellen in den besonders markiert werden. Darauf gehen wir später in die-
relationalen Atomen gleichgesetzt wird. sem Abschnitt genauer ein. Es können aber auch komplexe-
re Auswertungen vorkommen, die z. B. Aggregate berechnen
Projektion. oder völlig neue Werte generieren. In diesen Fällen ist der
Die Projektion lässt sich als s-t-TGD formulieren, indem Standard-CHASE nicht ausreichend, um die CHASE- oder
nur die Attribute, auf welche projiziert werden soll, im Kopf BACKCHASE-Phase abzuschließen. Solche Auswertungen,
der Abhängigkeit vorkommen, z. B. lassen sich jedoch mit Hilfe von second-order-Abhängigkeiten
umsetzen [11]. Hier können Funktionen definiert werden,
R(A1 , A2 , A3 , ..., An ) → R0 (A1 , A2 ). welche die Generierung neuer Konstanten erlauben. Sind
Da der Standard-CHASE jedoch nur für aktive Trigger den diese selbst nicht invertierbar, werden an den entsprechen-
Kopf der Abhängigkeit in das Ergebnis der Anfrage bzw. den Stellen in der BACKCHASE-Phase Nullwerte generiert.
Evolution aufnimmt, wird hier eine Duplikateliminierung vor-
genommen, die nur eine relaxierte CHASE-Inverse bedeutet 3.2 Komposition von Provenance- und Evolu-
[2]. In Bezug auf die an der Anfrage beteiligten Tupel ge- tionsschritten
nügt dies jedoch einer tupel-erhaltend relaxierten Inverse, Im Folgenden stellen wir einen Ansatz vor, welcher die Be-
da Tupel, für die kein aktiver Trigger existiert, auch nicht rechnung derjenigen Tupel erlaubt, welche nach einer Evolu-
im Anfrageergebnis vorkommen. Die Inverse der obigen s-t- tion nicht mehr ausreichend in der nächsten Schemaversion
TGD lautet dann abgebildet werden, um bestimmte Anfragen zu reproduzie-
R0 (A1 , A2 ) → ∃A3 , ...An : R(A1 , A2 , A3 , ..., An ) ren. Hierzu setzen wir voraus, dass alle Tupel eine eindeutig
ID (TID) besitzen und die Evolutionsschritte und Anfragen,
Im Gegensatz zu Anfragen kann bei der Evolution jedoch die reproduzierbar bleiben sollen, gespeichert werden. Beim
noch ein Spezialfall auftreten. Da bei einer Schema-Evolution Übergang wird die Menge der Tupel berechnet, die nach der
auch neue Attribute hinzukommen können, kann dort auch Evolution nicht mehr für die Beantwortung der ausgewähl-
auf Attribute projiziert werden, die nicht im ursprünglichen ten Anfragen ausreichen. Diese Menge nennen wir im Folgen-
Schema vorkommen, z. B. den IP rov . Diese Tupel müssen nach der Schema-Evolution
R(A1 , ..., An ) → ∃An+1 : R0 (A1 , ..., An , An+1 ). zusätzlich aufbewahrt werden.
Dieser Prozess läuft in drei Teilschritten ab. Zunächst be-
Für die Invertierung sind solche neu hinzugefügten Attribute
rechnen wir mittels des CHASE und BACKCHASE für jede
jedoch unproblematisch, da sie keinen Einfluss auf die aus
Anfrage, jeweils durch eine s-t-TGD abgebildet, ihr Ergeb-
der Ursprungsrelation stammenden Informationen haben.
nis und die Menge der Tupel (und Attribute), die tatsäch-
lich an der Auswertung beteiligt waren. Diese Mengen nen-
Verbund. nen wir I 0 (S). Anschließend berechnen wir analog die Da-
Der Verbund funktioniert grundlegend wie ein Attribut- tenbank in der nächsten Schemaversion (I(S 0 )), basierend
vergleich. Hier sind lediglich die zu vergleichenden Attribute auf den Evolutionsoperationen, die ebenfalls als s-t-TGDs
in unterschiedlichen Relationen. Ein Verbund R.A1 = S.B1 dargestellt werden, sowie die Menge der Tupel (und Attri-
einer Anfrage oder Evolution kann als s-t-TGD bute) J, die nach der Evolution durch Invertierung abbild-
R(A1 , ..., An ) ∧ S(A1 , ..., Bn ) → RS(A1 , ...Bn ) baren abbildbar sind. Zuletzt suchen wir im finalen Teil-
schritt Abbildungen von Tupeln aus I 0 (S) in J. Diejenigen
dargestellt werden. Der Inversentyp bezüglich der beteiligten Tupel, für welche solche Abbildungen existieren, sind durch
Tupel ist demnach wie auch bei der Selektion exakt [18]. Tupel der nachfolgenden Schemaversion ausreichend abge-
bildet, um für die betrachteten Anfragen verwendet zu wer-
Umbenennung. den. Existiert für ein Tupel keine solche Abbildung, muss es
Die Umbenennung von Attributen oder Relationen wird für die Auswertung der Anfragen aufbewahrt werden und ist
über Schemainformationen gelöst. In den Abhängigkeiten somit Element von IP rov .
spiegelt sich dies nur bei umbenannten Relationen wieder,
z. B. Provenance der Anfragen.
R(A1 , ..., An ) → R0 (A1 , ..., An ). In [1] wurde vorgestellt, wie eine Anfrage Q0 auf der nächs-
ten Schemaversion S 0 nach der Evolution E aussehen muss,
Die Inverse ist somit aber immer exakt, da Abhängigkeiten um das Ergebnis der ursprünglichen Anfrage Q auf der alten
hier vollständig alle Informationen in die nächste Schema- Schemaversion S zu produzieren. Hierzu muss Q0 der Aus-
version übertragen [2], und entspricht führung von Q auf dem alten Datenbestand entsprechen. Es
R0 (A1 , ..., An ) → R(A1 , ..., An ). gilt also
Q0 (S 0 ) = Q(E −1 (S 0 )).
Komplexe Auswertungen.
Die obigen, grundlegenden Operatoren werden in Anfra- Da CHASEE −1 (S 0 ) jedoch nicht zwangsläufig alle Tupel
gen und Evolutionsoperationen häufig verknüpft und bie- ausreichend wiederherstellt, um die Anfrage Q zu beant-
ten somit die Grundlage der meisten bekannten Operatio- worten, müssen dem Ergebnis noch die eingefrorenen Tupel
nen zur Schema-Modifikation, die in [8] vorgestellt wurden. IP rov hinzugefügt werden. So ergibt sich für den allgemeinenFall tens von Tupeln kann dies direkt über second-order-TGDs
0 0 −1 0 passieren, die statt Nullwerten über eine Funktion neue, ein-
Q (S ) = Q(E (S ) ∪ IP rov ).
deutige IDs berechnen, z. B. UUIDs. Fallen jedoch auch Tu-
Die erste Phase der Berechnung von IP rov identifiziert die pel zusammen, z. B. weil ein Attribut durch die Evolution
beteiligten Tupel (und Attribute) entfernt wird, funktioniert dies nicht. Hier könnten redun-
n dante Tupel mit unterschiedlichen IDs entstehen. Betrach-
ten wir hierzu folgendes Beispiel der Relation R2 und der
[
I 0 (S) = CHASEQ−1 (CHASEQi (I))
i=1
i Evolution E2 .
für alle ausgewählten Anfragen Qi . Da bei Anfragen oder TID X Y
Evolutionsschritten Attribute, die für die Berechnung die- 1 1 1
ser relevant sind, herausprojiziert werden können, muss ab- 2 1 2
gesichert werden, dass diese Attribute später erkannt wer-
den können. Da Konstanten bei der Invertierung einer s-t- Table 2: Relation R2
TGD weiter erhalten bleiben, ist die Selektion A = c hierbei
unproblematisch. Verbundattribute bzw. Attributvergleiche
Ai = Aj , bei denen diese Attribute jedoch nicht im Anfrage-
E2 : R2 (tid, x, y) → ∃T id2 , T id3 : Rx (T id2 , x) ∧ Ry (T id3 , y)
bzw. Evolutionsergebnis auftauchen, beeinflussen die Aus-
wertung, werden aber nach dem BACKCHASE mit Null- Berechnet man nun CHASEE (I), ergeben sich die in Ta-
werten in den entsprechenden Tupeln besetzt. Um diese von belle 3 dargestellten Relationen Rx und Ry in der nächsten
Attributen abzuheben, die nicht für die Auswertung relevant Schemaversion. Hier können nicht direkt neue TIDs durch
sind, markieren wir Variablen, die im Kopf der invertierten s- die s-t-TGD der Evolution vergeben werden, da sonst ein
t-TGD mehrfach vorkommen aber existenzquantifiziert sind, zusätzliches Tupel in Rx generiert wird, welches jedoch den
als besondere Variablen APi
rov
. Diese generieren beim CHA- gleichen X-Wert trägt. Solche Redundanzen sind hier nicht
SE spezielle Nullwerte (Provenance-Nullwerte) ηjP rov . erwünscht, sodass in einem Zwischenschritt die Nullwerte
durch entsprechende Konstanten ersetzt werden müssen. Des
Provenance der Schema-Evolution. weiteren muss diese Vergabe neuer Konstanten invertier-
Anschließend führen wir die gleiche Berechnung für die bar sein, damit bei der Invertierung der Evolution auch
Evolution E statt für die Anfragen Qi durch, um herauszu- alte TIDs errechnet werden können. Daher bietet es sich
finden, welche Tupel und Attribute sich nach der Evolution an, ein Verzeichnis über die Provenance der TIDs zu füh-
rekonstruieren lassen. ren, aus dem abgelesen werden kann, aus welchen Tupeln
(TIDs) der vorherigen Schemaversion die Tupel der neuen
J = CHASEE −1 (CHASEE (I)) = CHASEE −1 (I(S 0 ))
Schemaversion gebildet wurden. Dies kann über eine Hilf-
Hierbei müssen wir nicht gesondert darauf achten, dass po- stabelle T ID(tidS , tidS 0 ) realisiert werden, um welche die
tenziell für die Evolution relevante Attribute herausproji- Abhängigkeiten für die Evolution erweitert werden müssen.
ziert werden, da wir uns nur dafür interessieren, welche In- Erweitern wir E2 um die Nutzung dieser Hilfsrelation, ergibt
formationen des alten Schemas im neuen erhalten bleiben. sich folgende s-t-TGD, deren Invertierung auch die Wieder-
Da hier die Evolution berechnet werden soll, bedeutet dies herstellung der ursprünglichen TIDs erlaubt.
allerdings auch die Berechnung neuer TIDs, falls Tupel nach
der Evolution zusammenfallen oder aufgesplittet werden. Im E3 : R2 (tid, x, y) → ∃T id2 , T id3 : Rx (T id2 , x) ∧ Ry (T id3 , y)
allgemeinen Fall reicht der Standard-CHASE hier nicht aus. ∧T ID(tid, T id2 ) ∧ T ID(tid, T id3 )
Betrachten wir zur Veranschaulichung folgende Beispiele.
Das Attribut Z der Relation R auf der Datenbankinstanz Bevor die Invertierung des Evolutionsschrittes stattfindet,
I(S) soll nach der Evolution E ebenfalls durch das Attri- muss nun noch die Cleaning-EGD angewandt werden. Hier-
but Y abgedeckt werden. In diesem Fall werden Tupel aus für verwenden wir second-order-EGDs der Form
R aufgesplittet, sodass potenziell neue TIDs nötig werden. T ID(tid, tid2 ) → tid2 = f (tid2 ).
Berechnet man nun CHASEE (I), ergibt sich die folgende
Relation R auf der Datenbankinstanz I(S 0 ). Dabei ist f eine Funktion, die bei Eingabe eines Nullwertes
eine neue TID (z. B. eine UUID), bei Eingabe einer Konstan-
E : R(tid, x, y, z) → ∃T id2 , T id3 : R(T id2 , x, y)
te jedoch diese selbst zurückgibt. Dies muss für alle TIDs
∧R(T id3 , x, z) durchgeführt werden. Besonders muss dabei darauf geachtet
werden, dass die nummerierten Nullwerte global durch die
TID X Y Konstanten überschrieben werden.
TID X Y Z η1 1 1
1 1 1 11 η2 1 11 Berechnung der zu speichernden Tupel.
2 1 2 12 η3 1 2
η4 1 12
(a) Relation R auf I(S) TID Y
(b) Relation R auf I(S 0 ) TID X
η2 1
η1 1
η3 2
Table 1: Relation R vor und nach Anwendung des CHASE (a) Relation Rx
(b) Relation Ry
Diese Nullwerte müssen nun durch entsprechende Kon-
stanten für neue TIDs ersetzt werden. Im Falle des Aufsplit- Table 3: Relationen nach Anwendung des CHASEIm finalen Schritt berechnen wir nun IP rov . Hierzu su- Vorname Name Alter Anschrift
chen wir die Menge derjenigen Tupel aus I 0 (S), die sich Max Mustermann 30 Parkstraße 3
auf Tupel in J abbilden lassen. Diese Menge nennen wir Erika Musterfrau 18 Schlossallee 7
JM . Das Suchen solcher Abbildungen wird uns durch die Paul Müller 18 Hafenstraße 12
TIDs erleichtert, da nur Tupel mit gleichen IDs für Abbil- Lisa Schmidt 25 Hauptstraße 1
dungen in Frage kommen. Ein normaler Nullwert in einem
Tupel in I 0 (S) bedeutet, dass die Auswertung, aus deren Table 4: Person (I(S))
BACKCHASE-Phase dieses Tupel stammt, jenes Attribut
nicht benötigt. Diese Nullwerte können daher beliebig auf
Konstanten oder Nullwerte in J abgebildet werden. Anders Namen und Anschriften der Personen liefert, die 18 Jahre
verhält sich dies jedoch bei den Provenance-Nullwerten. Da alt sind (Tabelle 5).
sie durchaus an der Auswertung beteiligt sind und sie, z. B.
als Verbundattribut die Gleichheit der Werte auch in der Name Anschrift
nächsten Schemaversion voraussetzen, dürfen diese nur auf Musterfrau Schlossallee 7
Konstanten abgebildet werden. Sonst kommt es dazu, dass Müller Hafenstraße 12
solche Verbundkriterien verlorengehen und bei erneuter Aus-
führung einer Anfrage Qi Kreuzprodukte gebildet werden. Table 5: Anfrageergebnis Q
IP rov ergibt sich dann aus denjenigen Tupeln, die an der
Anfrage beteiligt waren, aber nicht in JM sind. Diese Tu- Anschließend führen wir den CHASE mit der invertierten
pel können dann in extra Tabellen ”eingefroren” werden, so- Anfrage
dass sie für die entsprechenden Anfragen genutzt werden
Q(na, an) → ∃V o : P erson(V o, na, 18, an)
können. Weiter muss dazu natürlich bekannt sein, welche
Anfragen auf welcher Schemaversion gestellt wurden, damit auf dem Anfrageergebnis aus und erhalten somit die Menge
man weiß, auf welche Schemaversion zurückgerechnet wer- derjenigen Tupel, die an der Anfrage beteiligt waren (abge-
den muss. Zudem müssen auch die Evolutionsschritte, also bildet in Tabelle 6).
die entsprechenden s-t-TGDs und EGDs, die Schema S zu
S 0 transformieren, aufbewahrt werden, damit das Zurück- Vorname Nachname Alter Anschrift
rechnen auf alte Versionen gelingt. Es ist auch möglich, die η1 Musterfrau 18 Schlossallee 7
Evolutionsschritte zu komponieren und statt mehrerer Evo- η2 Müller 18 Hafenstraße 12
lutionen nur die Kompositionen dieser zu speichern [11]. Dies
verhindert jedoch das Berechnen der zwischenzeitigen Sche- Table 6: Durch BACKCHASE generierte Personentabelle
maversionen. Im allgemeinen Fall kann auf jeder Schemaver-
sion Si mindestens eine Anfrage gestellt werden, für welche Danach berechnen wir I(S 0 ). Hierfür führen wir zunächst
wir die Reproduzierbarkeit voraussetzen wollen. Speichert den CHASE auf I(S) mit der Evolution aus. Anschließend
man lediglich die Komposition von Ei , welche die Evolution benutzen wir analog zur Anfrage den BACKCHASE auf
von Si−1 nach Si beschreibt, und Ei+1 , so ist es nicht mehr I(S 0 ) mit der inversen Evolution, um zu berechnen, welche
möglich Si selbst zu berechnen. Damit kann die Reprodu- Tupel und Informationen nach der Evolution rekonstruier-
zierbarkeit der Anfrage auf ihrer ursprünglichen Schemaver- bar sind. Da die Zuweisung eines Alters zu einem Bereich
sion nicht mehr gewährleistet werden. Kommen jedoch Fälle durch f nicht invertierbar ist, lautet die Inverse der Evolu-
vor, bei denen zwischen zwei Schema-Evolution keine der- tionsoperation
artigen Auswertungen stattfanden, kann die Komposition
der Evolutionsoperationen eingesetzt werden, um Zwischen- P ersonAnon(vo, na, ab, an) → ∃Al : P erson(vo, na, Al, an).
schritte bei zukünftigen Berechnungen einzusparen. Der BACKCHASE liefert uns damit folgende Menge der re-
konstruierbaren Tupel J, nachvollziehbar in Tabelle 7.
Beispiel.
Betrachten wir zur Veranschaulichung folgendes Anwen- Vorname Name Alter Anschrift
dungsbeispiel. Gegeben sei die folgende Relation in Tabelle Max Mustermann η1 Parkstraße 3
4, sowie die Anfrage Erika Musterfrau η2 Schlossallee 7
P erson(vo, na, 18, an) → Q(na, an). Paul Müller η3 Hafenstraße 12
Lisa Schmidt η4 Hauptstraße 1
Zum Zweck der Anonymisierung soll das Alter in der nächs-
ten Schemaversion in Altersbereiche eingeteilt werden. Dies Table 7: Person (J)
geschehe durch folgende Evolutionsoperation
P erson(vo, na, al, an) → P ersonAnon(vo, na, f (al), an). Nun suchen wir Abbildungen aus I 0 (S) in J. Diese Menge
JM ist in diesem Fall jedoch leer, da die Konstanten (Al-
Zusätzlich wird das Attribut ”Alter” in ”Altersbereich” um- ter) der Tupel aus I 0 (S) nicht auf die Nullwerte in J abge-
benannt. Der Altersbereich wird durch eine Funktion f be- bildet werden können. Daher bilden in diesem Fall alle an
stimmt, welche das Alter in den entsprechenden Bereich der Anfrage beteiligten Tupel IP rov und müssen aufbewahrt
(0 − 5, 6 − 10, ...) einteilt. werden. Hier sind das (Erika, Musterfrau, 18, Schlossallee 7)
Wir vernachlässigen hier die TIDs, da keine der s-t-TGDs und (Paul, Müller, 18, Hafenstraße 12). Das bedeutet, dass
zu einem Zusammenfallen oder Aufsplitten von Tupel führt nach der Berechnung der nachfolgenden Schemaversion da-
und diese somit nie verändert werden. Zunächst berechnen für gesorgt werden muss, dass diese Tupel im alten Schema
wir durch den CHASE das Anfrageergebnis Q, welches uns beibehalten werden. Alle anderen werden ausreichend fürdie Anfrage abgebildet, und müssen nicht in der aktuellen Kompositionen über alle Schemaversionen und das Überprü-
Version aufgehoben werden. fen für jede gewählte Anfrage vorheriger Schemaversionen
ein großer Aufwand, welcher bei jeder Evolution betrieben
werden muss. Wünschenswert ist eine Variante, welcher das
4. EVALUATION aktuelle Schema genügt, um diese Überprüfung der nächs-
Der hier vorgestellte Ansatz verwendet den CHASE-Algo- ten Evolution durchzuführen, z. B. durch Annotation ent-
rithmus zur Sicherstellung der Reproduzierbarkeit von An- sprechender Tupel und Attribute.
fragen unter Schema-Evolution. Bekannterweise terminiert Eine weitergehende Fragestellung ist, wie wir den hier für
der CHASE-Algorithmus im allgemeinem Fall nicht zwin- einen Anwendungsfall vorgestellten BACKCHASE-Prozess
gend, wird aber an zwei stellen der Berechnung eingesetzt. für verschiedene Anwendungsfälle (in Abschnitt 2 Anwen-
Im hier gezeigten Anwendungsfall ist die Terminierung aller- dungsfälle 1 bis 4) vereinheitlichen können, da wir alle An-
dings garantiert. Grund dafür ist, dass die erste Phase zur wendungen mit einem einheitlichen CHASE&BACKCHASE-
Berechnung der beteiligten Tupel strikt in zwei Schritten Tool (ChaTEAU, [3]) unterstützen wollen.
abläuft, bei denen jeweils nur mit einer einzigen Abhängig-
keit gechaset wird. Dadurch ergeben sich niemals Zyklen, die
zu einer unendlichen Generierung neuer Werte führen kön-
6. REFERENCES
nen. Die zweite Phase, in der die nachfolgende Schemaver- [1] T. Auge and A. Heuer. Combining Provenance
sion berechnet wird, erzeugt hingegen potenziell neue Wer- Management and Schema Evolution. In IPAW, volume
te, die aber ebenso niemals während der gleichen CHASE- 11017 of Lecture Notes in Computer Science, pages
Anwendung gelesen werden können, da das Quell- und Ziel- 222–225. Springer, 2018.
schema streng getrennt sind. [2] T. Auge and A. Heuer. The Theory behind
Die Berechnung der nachfolgenden Schemaversion schließt Minimizing Research Data: Result equivalent
die Berechnung neuer TIDs ein. Da diese stets eindeutig CHASE-inverse Mappings. In LWDA, volume 2191 of
sein müssen, und nachfolgend bei der Rückrechnung in alte CEUR Workshop Proceedings, pages 1–12.
Schemaversionen rekonstruiert werden müssen, wurde hier CEUR-WS.org, 2018.
vorgeschlagen dies über eine s-o-Abhängigkeit zu lösen, die [3] T. Auge and A. Heuer. ProSA - using the CHASE for
neue eindeutige Werte (z. B. in Form von UUIDs) liefert. provenance management. In ADBIS, volume 11695 of
Diese wiederum werden in einer Hilfstabelle abgelegt, um Lecture Notes in Computer Science, pages 357–372.
die Invertierung von Abhängigkeiten zu unterstützen. Dies Springer, 2019.
stellt eine Erweiterung des Standard-CHASE da, welche es [4] T. Auge, E. Manthey, S. Jürgensmann, S. Feistel, and
erlaubt zur Laufzeit neue Konstanten zu generieren. In un- A. Heuer. Schema evolution and reproducibility of
serem Fall ist dies vergleichbar mit einer EGD, deren Kopf long-term hydrographic data sets at the IOW. In
neben einer Variable auch eine Konstante enthält. Diese wird LWDA, volume 2738 of CEUR Workshop Proceedings,
durch eine gesonderte Methode im Programm, welches den pages 258–269. CEUR-WS.org, 2020.
CHASE implementiert, berechnet und überprüft die Einga- [5] M. Benedikt, G. Konstantinidis, G. Mecca, B. Motik,
be auf ihren Typ bezüglich des CHASE. Handelt es sich um P. Papotti, D. Santoro, and E. Tsamoura.
eine Konstante, soll diese selbst zurückgegeben werden, da Benchmarking the Chase. In PODS, pages 37–52.
bereits eine neue ID für den ehemaligen Nullwert generiert ACM, 2017.
wurde. Wird jedoch ein Nullwert übergeben, wird eine neue [6] P. Buneman, S. Khanna, and W. C. Tan. Why and
TID zurückgegeben, welche fortan in allen Tupeln den ent- Where: A Characterization of Data Provenance. In
sprechenden Nullwert ersetzt. ICDT, volume 1973 of Lecture Notes in Computer
Science, pages 316–330. Springer, 2001.
5. AUSBLICK [7] J. Cheney, L. Chiticariu, and W. C. Tan. Provenance
in Databases: Why, How, and Where. Found. Trends
In diesem Beitrag haben wir einen Ansatz vorgestellt, um
Databases, 1(4):379–474, 2009.
mit Hilfe des CHASE Daten zu identifizieren, die durch ei-
ne Schema-Evolution nicht ausreichend abgebildet werden, [8] C. Curino, H. J. Moon, and C. Zaniolo. Graceful
um bestimmte Anfragen zu reproduzieren. Die hier gezeig- database schema evolution: the PRISM workbench.
te Vorgehensweise ließe sich in den Evolutionsprozess ein- Proc. VLDB Endow., 1(1):761–772, 2008.
binden, um nur diejenigen Daten aufzubewahren, welche für [9] A. Deutsch and R. Hull. Provenance-Directed
die Reproduzierbarkeit ausgewählter Anfragen relevant sind. Chase&Backchase. In In Search of Elegance in the
Hierbei haben wir jedoch nur die Schema- und keine Datene- Theory and Practice of Computation, volume 8000 of
volution betrachtet, sodass der hier vorgestellte Ansatz Än- Lecture Notes in Computer Science, pages 227–236.
derungen der Daten außerhalb von Schema-Evolution nicht Springer, 2013.
berücksichtigt. [10] R. Fagin, P. G. Kolaitis, R. J. Miller, and L. Popa.
Eine offene Frage ist weiter, wie mit mehreren Schema- Data exchange: semantics and query answering.
Evolution umgegangen werden kann. Tupel der Schemaver- Theor. Comput. Sci., 336(1):89–124, 2005.
sion Si+1 , die für eine ausgewählte Anfrage Q des Schemas [11] R. Fagin, P. G. Kolaitis, L. Popa, and W. C. Tan.
Si relevant sind, müssen auch beim Übergang in die Schema- Schema Mapping Evolution Through Composition and
version Si+2 ausreichend abgebildet werden, sodass Q immer Inversion. In Schema Matching and Mapping,
noch reproduzierbar ist. Der hier vorgestellte Algorithmus Data-Centric Systems and Applications, pages
bietet dafür keine Überprüfung. Die Komposition der Evo- 191–222. Springer, 2011.
lutionsoperationen von Schema Si zu Si+2 kann genutzt wer- [12] F. Geerts, G. Mecca, P. Papotti, and D. Santoro.
den, um dies zu erreichen. Allerdings ist die Berechnung der Mapping and cleaning. In ICDE, pages 232–243. IEEEComputer Society, 2014.
[13] S. Greco, C. Molinaro, and F. Spezzano. Incomplete
Data and Data Dependencies in Relational Databases.
Synthesis Lectures on Data Management. Morgan &
Claypool Publishers, 2012.
[14] T. J. Green, G. Karvounarakis, and V. Tannen.
Provenance semirings. In PODS, pages 31–40. ACM,
2007.
[15] A. Heuer, G. Saake, and K. Sattler. Datenbanken -
Implementierungstechniken, 4. Auflage. MITP, 2019.
[16] M. Meier. The backchase revisited. VLDB J.,
23(3):495–516, 2014.
[17] M. L. Möller, S. Scherzinger, M. Klettke, and U. Störl.
Why It Is Time for Yet Another Schema Evolution
Benchmark - Visionary Paper. In CAiSE Forum,
volume 386 of Lecture Notes in Business Information
Processing, pages 113–125. Springer, 2020.
[18] F. Rose. Erweiterung des CHASE-Werkzeugs
ChaTEAU um eine BACKCHASE-Phase.
Masterarbeit, Universität Rostock, DBIS, 2020.Sie können auch lesen
