18.11.2012 Aufrufe

Dokument 1 - RWTH Aachen University

Dokument 1 - RWTH Aachen University

Dokument 1 - RWTH Aachen University

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!