Dokument 1 - RWTH Aachen University
Dokument 1 - RWTH Aachen University
Dokument 1 - RWTH Aachen University
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
6.3 Anfrageumschreibung zur Datenintegration 159<br />
6.3.3 Phase 3: Annotation der Anfragen mit Mediatoroperationen<br />
In der letzten Phase der Anfrageumschreibung müssen die Bezüge zum konzeptuellen Modell<br />
durch entsprechende relationale Konstrukte ersetzt werden. In Abschnitt 6.2.2 wurde dazu ein<br />
Mediator definiert, der neben den Relationen der Datenquellen auch die Mediatoroperationen<br />
zum Zusammenführen der Daten beinhaltet. Im Gegensatz zum Vorgehen in [Calvanese et al.,<br />
2001] müssen hier die möglichen Operationen nicht vor der Anfrageumschreibung spezifiziert<br />
werden. In diesem Ansatz werden die Operationen in den Mediator eingefügt ohne zu wissen, ob<br />
die Operationen überhaupt durchführbar sind. Der wichtigste Grund für dieses Vorgehen ist, dass<br />
die Vorabdefinition der Operationen zu aufwendig ist. Jedoch werden dadurch einige Umschreibungen<br />
der Anfrage erzeugt, die nicht umgesetzt werden können, weil eine Implementierung der<br />
vorgesehenen Mediatoroperationen nicht möglich ist. Da das Ziel des Ansatzes in dieser Arbeit<br />
aber darin besteht, eine Umschreibung der Anfrage mit möglichst hoher Datenqualität zu finden,<br />
habe ich mich dafür entschieden, möglichst viele Umschreibungen zu betrachten. Die möglicherweise<br />
zu erwartende gute Qualität einer Umschreibung rechtfertig die Implementierung von<br />
aufwendigeren Mediatoroperationen, die bei einer Vorabdefinition evtl. nicht in Betracht gezogen<br />
worden wären.<br />
Die notwendigen Mediatoroperationen können direkt aus den in Phase 2 bestimmten Beschreibungen<br />
für die Umschreibungen generiert werden. Der entsprechende Algorithmus zur Konstruktion<br />
des Mediators ist in Abbildung 6.10 dargestellt. Für das Einfügen der Mediatoroperationen<br />
muss man vier Fälle unterscheiden:<br />
1. Zwei Variablen A, B aus zwei Datenquellen, die Konzepte repräsentieren, werden auf die<br />
gleiche Variable der DW-Relation abgebildet. Dann muss ein Verbund zwischen den beiden<br />
Datenquellen hergestellt werden. Die Bedingung der Verbundoperation wird dann durch<br />
die match-Operation überprüft, die die relationalen Variablen −→ X , −→ Y als Argument haben,<br />
die die Variablen A, B identifizieren.<br />
2. Zwei Variablen A, B aus zwei Datenquellen, die Attributwerte repräsentieren, werden auf<br />
die gleiche Variable C der DW-Relation abgebildet. Dann müssen die Attributwerte zusammengeführt<br />
werden (z.B. durch Mittelwertbildung oder Präferenz für Attributwerte<br />
aus einer Datenquelle). Diese Operation wird durch die merge-Funktion repräsentiert, die<br />
wie die match-Operation vorher, die entsprechenden relationalen Variablen als Argument<br />
hat.<br />
3. Alle Variablen A, die auf eine Variable B der DW-Relation abgebildet werden, müssen der<br />
Variablen der DW-Relation „zugewiesen“ werden. Wenn die Domänen der zugehörigen<br />
relationalen Variablen gleich sind, dann kann dies durch die assign-Operation geschehen.<br />
4. Falls die relationalen Variablen unterschiedliche Domänen haben, so müssen sie durch die<br />
convert-Operation konvertiert werden.<br />
Eine konjunktive Anfrage setzt sich dann zusammen aus den Regelköpfen der Spezifikationen<br />
der Datenquellen und den zusätzlich notwendigen Vergleichsprädikaten. Dabei müssen bei den