Dokument 1 - RWTH Aachen University

6.3 Anfrageumschreibung zur Datenintegration 161
Vergleichsprädikaten noch die konzeptuellen Variablen durch die relationalen Variablen ersetzt
werden, was mit Hilfe der Annotationen der Datenquellen und der DW-Relation und der Abbildung
ψ und eq in der Funktion replaceVars vorgenommen werden kann.
Schließlich werden der Annotation einer konjunktiven Anfrage noch die Domäneninformationen
für die relationalen Variablen hinzugefügt, die in dieser Anfrage vorkommen (also alle relationalen
Variablen der Datenquellen). Die globale Annotation mit den Domänen der Ergebnisvariablen
wird am Schluss der Funktion hinzugefügt.
Beispiel 6.8 (Fortsetzung von Beispiel 6.7):
Die in Phase 2 bestimmten möglichen Kombinationen von MiniCon-Beschreibungen können
nun zu konjunktiven Anfragen mit einer Annotation umgewandelt werden. Dabei beschränke ich
die Darstellung hier wieder auf die drei Möglichkeiten, die in Tabelle 6.2 dargestellt sind. Aus
Gründen der Übersichtlichkeit stelle ich hier die domain-Ausdrücke in der Annotation nicht dar.
Die erste Möglichkeit ist ein Verbund der Datenquellen Marketing, Customer und BasicCharge.
Dabei wird der Verbund über das Konzept Customer bzw. PrivateCustomer hergestellt. Da in der
Relation Marketing die Kunden über den Namen und das Geburtsdatum identifiziert werden, ist
eine komplexere match-Operation mit den anderen beiden Relationen notwendig.
Customer(ID1, Name1, Street1, City1, Country1), Marketing(Name2, DOB2),
BasicCharge(ID5, Code5, T ype5, Amount5), EQ(Country1, “Germany”), LE(DOB2, 1950)
| match([Name2, DOB2], [ID1]), match([Name2, DOB2], [ID5]), match([ID1], [ID5]),
assign([ID], [ID1]), assign([Name], [Name1]),
assign([Code], [Code5]), assign([T ype], [T ype5])
Bei der zweiten Möglichkeit kommt zusätzlich noch die Relation GermanCitizen hinzu. Da dadurch
garantiert wird, dass es sich um deutsche Kunden handelt, muss die Einschränkung für das
Attribut Country nicht mehr geprüft werden. Insgesamt werden hier sechs match-Operationen
generiert, das entspricht allen Möglichkeiten bei vier Datenquellen. Um sicher zu stellen, dass
aus den vier Datenquellen jeweils der gleiche Kunde betrachtet wird, reichen jedoch drei match-
Operationen aus.
Customer(ID1, Name1, Street1, City1, Country1), Marketing(Name2, DOB2),
GermanCitizen(Name3, DOB3, City3), BasicCharge(ID5, Code5, T ype5, Amount5),
LE(DOB2, 1950)
| match([Name2, DOB2], [ID1]), match([Name2, DOB2], [ID5]), match([ID1], [ID5]),
match([Name2, DOB2], [Name3, DOB3]), match([Name3, DOB3], [ID1]),
match([Name3, DOB3], [ID5]), assign([ID], [ID1]), assign([Name], [Name1]),
assign([Code], [Code5]), assign([T ype], [T ype5])
Die letzte Möglichkeit stellt den Verbund zwischen allen fünf Relationen her. Um die unterschiedlichen
Repräsentationen von Kunden in den Datenquellen miteinander abzugleichen, sind
insgesamt zehn match-Operationen möglich. Die angegebenen vier match-Operationen reichen