pdf (18647 Kb) - Fachgebiet Datenbanken und Informationssysteme ...
pdf (18647 Kb) - Fachgebiet Datenbanken und Informationssysteme ...
pdf (18647 Kb) - Fachgebiet Datenbanken und Informationssysteme ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
Leibniz Universität Hannover<br />
Institut für Praktische Informatik<br />
<strong>Fachgebiet</strong> <strong>Datenbanken</strong> <strong>und</strong> <strong>Informationssysteme</strong><br />
Vergleich von Methoden<br />
zum Graph Matching bei der<br />
Integration von <strong>Datenbanken</strong><br />
von<br />
Dennis Jaschniok<br />
Masterarbeit<br />
Erstprüfer: Prof. Dr. Udo Lipeck<br />
Zweitprüfer: Dr. Hans Hermann Brüggemann<br />
Abgabedatum: 30.09.2011
Erklärung der Selbstständigkeit<br />
Hiermit versichere ich, dass ich die vorliegende Masterarbeit selbständig <strong>und</strong> ohne<br />
fremde Hilfe verfasst <strong>und</strong> keine anderen als die in der Arbeit angegebenen Quellen <strong>und</strong><br />
Hilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keinem<br />
anderen Prüfungsamt vorgelegen.<br />
Hannover, den 30. September 2011<br />
Dennis Jaschniok<br />
2
Inhaltsverzeichnis<br />
1. Einleitung 5<br />
1.1. Motivation <strong>und</strong> Schwerpunkte dieser Arbeit . . . . . . . . . . . . . . . . . 5<br />
1.2. Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
2. Gr<strong>und</strong>lagen 7<br />
2.1. Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.2. Mapping <strong>und</strong> Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
3. Matching-Verfahren 10<br />
3.1. Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10<br />
3.2. Klassifizierung von Matching-Verfahren . . . . . . . . . . . . . . . . . . . 11<br />
3.3. Graph Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
3.3.1. Besonderheiten des Graph Matchings . . . . . . . . . . . . . . . . 13<br />
3.3.2. Graph Matching bei räumlichen Daten . . . . . . . . . . . . . . . . 14<br />
4. Der Similarity Flooding Algorithmus 15<br />
4.1. Gr<strong>und</strong>idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
4.2. Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
4.3. Iteratives Berechnung der Ähnlichkeiten . . . . . . . . . . . . . . . . . . . 22<br />
4.4. Umgang mit den Ergebnissen . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
4.4.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26<br />
4.4.2. Auswahl von 1-zu-1-Mappings . . . . . . . . . . . . . . . . . . . . . 26<br />
4.4.3. Auswahl von n-zu-m-Mappings . . . . . . . . . . . . . . . . . . . . 30<br />
5. Vergleich mit anderen Verfahren 31<br />
5.1. Cupid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
5.2. Rondo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
5.3. SASMINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
6. Implementierung der Testumgebung 37<br />
6.1. Anforderungen an die Testumgebung . . . . . . . . . . . . . . . . . . . . . 37<br />
6.2. Funktionen <strong>und</strong> Bedienung des Programmes . . . . . . . . . . . . . . . . . 37<br />
6.3. Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
6.4. Umgang mit Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
6.5. Umgang mit Relationalen Datenbankschemata . . . . . . . . . . . . . . . 43<br />
3
7. Empirische Bef<strong>und</strong>e <strong>und</strong> Experimente zum Similarity Flooding 44<br />
7.1. Bef<strong>und</strong>e in der Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
7.2. Experimente an Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
7.2.1. Experimentdurchführung . . . . . . . . . . . . . . . . . . . . . . . 45<br />
7.2.2. Anfangsähnlichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
7.2.3. Verwendung einer anderen Fixpunktformel . . . . . . . . . . . . . 57<br />
7.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
7.3. Experimente an Relationalen Datenbankschemata . . . . . . . . . . . . . . 63<br />
7.3.1. Experimentaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
7.3.2. Ergebnisse ohne Vorverarbeitung . . . . . . . . . . . . . . . . . . . 67<br />
7.3.3. Ergebnisse unter Ausnutzung von Namensgleichheiten von Relationen<br />
<strong>und</strong> Attributen . . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
7.3.4. Ergebnisse unter Ausnutzung von Namensgleichheiten von Relationen<br />
<strong>und</strong> Attributen mit manuellen Anpassungen . . . . . . . . . 70<br />
7.3.5. Ergebnisse einer iterierten Anwendung . . . . . . . . . . . . . . . . 72<br />
7.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72<br />
8. Fazit <strong>und</strong> Ausblick 74<br />
A. Anhang – Für Experimente verwendete Graphen 79<br />
A.1. Graph 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80<br />
A.2. Graph 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81<br />
A.3. Graph 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83<br />
A.4. Graph 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84<br />
A.5. Graph 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
A.6. Graph 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88<br />
A.7. Graph 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90<br />
B. Anhang – Für Experimente verwendete Schemata 92<br />
B.1. Musiksammlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92<br />
B.2. Bustouren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95<br />
B.3. Verlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98<br />
B.4. Filmdatenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101<br />
C. Tabellen zu Kapitel 7.3 104<br />
4
1. Einleitung<br />
1.1. Motivation <strong>und</strong> Schwerpunkte dieser Arbeit<br />
Die Datenmengen, die heutzutage erhoben, gespeichert <strong>und</strong> verwaltet werden, sind enorm.<br />
In vielen Bereichen sieht man sich dabei mit dem Problem konfrontiert, wie man mit unterschiedlichen<br />
Datenbestände umzugehen hat. Sei es in Data Warehouses, im Gebiet des<br />
Semantic Webs, im E-Commerce oder bei der Integration von Schemata oder Ontologien,<br />
häufig stehen Experten vor der Frage, wie Daten aus mehreren Quellen zusammengefügt<br />
oder gemeinsam verwendet werden können.<br />
Der Begriff der Integration nimmt hier eine große Bedeutung ein. Mit diesem Thema<br />
befassen sich zum Beispiel die Autoren von [LN07]. Sie sprechen sogar davon, dass die<br />
Hälfte aller IT-Kosten auf die Integration bestehender Systeme aufgewendet werden.<br />
In dem Zusammenhang spielt der Begriff des Matchings eine wichtige Rolle. Matching-<br />
Verfahren dienen dazu, Gemeinsamkeiten zwischen den unterschiedlichen Datenbeständen<br />
zu finden <strong>und</strong> dadurch deren Handhabung zu unterstützen. Dieses Thema ist neben<br />
den oben genannten Anwendungsgebieten unter anderem auch in der Biologie, wo man es<br />
mit großen Gen-<strong>Datenbanken</strong> zu tun hat, <strong>und</strong> im Umfeld geographischer Datenbestände<br />
von Bedeutung, wo man zum Beispiel verschiedene Straßenverzeichnisse zusammenfügen<br />
muss.<br />
Die Zahl von Verfahren für solche Matchings ist groß, die Unterschiede in der Funktionsweise<br />
ebenfalls.<br />
Das Graph Matching stellt in diesem Zusammenhang einen Teilbereich des Matchings<br />
dar, der im Rahmen dieser Arbeit näher betrachtet werden soll.<br />
Ziel dieser Arbeit ist es, zunächst einen Überblick über das Graph Matching <strong>und</strong><br />
einige Verfahren zu liefern, bevor anschließend anhand von Experimenten bestimmte<br />
Aspekte eines ausgewählten Verfahrens, des Similarity Flooding, analysiert <strong>und</strong> daraus<br />
Empfehlungen entwickelt werden sollen, wie man es bei der Integration von <strong>Datenbanken</strong><br />
verwenden kann. Außerdem wird ein Programm entwickelt, das als Umgebung für<br />
Experimente im Rahmen dieser Arbeit <strong>und</strong> auch darüber hinaus verwendet werden kann.<br />
Da der Bereich des Matchings sehr weit gefächert ist, soll der Schwerpunkt dieser<br />
Arbeit dabei insbesondere auf dem Schema-Matching liegen.<br />
1.2. Gliederung<br />
Zu Beginn der Arbeit werden in Kapitel 2 gr<strong>und</strong>legende Begriffe erläutert, die für das<br />
Verständnis der späteren Kapitel von Bedeutung sind. Kapitel 3 liefert die geschichtliche<br />
5
Einordnung von Matching-Verfahren, klassifiziert sie nach bestimmten Kriterien <strong>und</strong><br />
geht auf die Besonderheiten des Graph Matchings ein.<br />
Kapitel 4 befasst sich mit dem Similarity Flooding Algorithmus, der den Schwerpunkt<br />
dieser Arbeit darstellt <strong>und</strong> als Gr<strong>und</strong>lage für die späteren Experimente (in Kapitel 7)<br />
dient. Hier wird insbesondere auf die Funktionsweise eingegangen, <strong>und</strong> es werden einige<br />
Aspekte erläutert, die in den Experimenten detaillierter betrachtet <strong>und</strong> analysiert<br />
werden.<br />
Kapitel 5 stellt drei weitere Graph Matching Verfahren vor <strong>und</strong> befasst sich mit<br />
den Unterschieden zwischen ihnen <strong>und</strong> dem Similarity Flooding. In Kapitel 6 wird die<br />
Testumgebung beschrieben, die im Rahmen der Arbeit entwickelt wurde.<br />
Kapitel 7 befasst sich mit Experimenten <strong>und</strong> Bef<strong>und</strong>en, die zum Similarity Flooding<br />
durchgeführt bzw. ermittelt wurden. Dabei wird zunächst auf Ergebnisse aus der Literatur<br />
eingegangen, bevor in eigenen Experimenten bestimmte Aspekte des Algorithmus<br />
überprüft <strong>und</strong> eigene Bef<strong>und</strong>e ermittelt <strong>und</strong> dokumentiert werden.<br />
In Kapitel 8 wird abschließend das Fazit gezogen <strong>und</strong> ein Ausblick auf zukünftige<br />
Entwicklungen geliefert.<br />
Anhang A enthält die in Kapitel 7 verwendeten Graphen. Anhang B zeigt die ebenfalls<br />
in diesem Kapitel verwendeten Schemata, Anhang C die Tabellen mit den Ergebnissen<br />
aus den Experimenten mit den Schemata in Kapitel 7.3.<br />
6
2. Gr<strong>und</strong>lagen<br />
In diesem Kapitel sollen einige Begriffe definiert werden <strong>und</strong> damit Gr<strong>und</strong>lagen für das<br />
Verständnis dieser Arbeit gelegt werden.<br />
2.1. Graphen<br />
In der Graphentheorie unterscheidet man zwischen zwei Arten von Graphen:<br />
Definition 2.1 Ein ungerichteter Graph G = (V, E) ist eine Datenstruktur bestehend<br />
aus einer Menge von KnotenV <strong>und</strong> einer Menge von KantenE, die die Knoten verbinden.<br />
Die Kantenmenge E ist eine Relation über V × V . Jede Kante von einem Knoten a zu<br />
einem Knoten b wird dabei durch ein ungeordnetes Paar (a, b) bzw. eine Menge {a, b}<br />
dargestellt.<br />
In der Darstellung eines ungerichteten Graphen werden Knoten als Kreise mit Bezeichnern<br />
darin dargestellt, Kanten durch einfache Verbindungslinien zwischen den Knoten.<br />
Definition 2.2 Ein gerichteter Graph G = (V, E) unterscheidet sich von einem ungerichteten<br />
dadurch, dass die Kanten durch geordnete Paare repräsentiert werden, also<br />
zwischen (a, b) <strong>und</strong> (b, a) unterschieden wird.<br />
In der Darstellung eines gerichteten Graphen werden Kanten durch Pfeile repräsentiert,<br />
wobei ein Pfeil von einem Knoten a zu einem Knoten b eine gerichtete Kante (a, b)<br />
darstellt.<br />
Beide Definitionen schließen aus, dass es in den Graphen zwei oder mehr Kanten von<br />
einem Knoten a zu einem Knoten b geben kann.<br />
Abbildung 2.1.: Ungerichteter (links) <strong>und</strong> gerichteter Graph (rechts)<br />
7
Sowohl bei gerichteten als auch bei ungerichteten Graphen können in der Darstellung<br />
Markierungen an den Kanten eingetragen werden. In diesem Fall spricht man von<br />
(kanten-) markierten gerichteten bzw. ungerichteten Graphen.<br />
Die folgende Definition fasst einige weitere Begriffe aus der Graphentheorie zusammen:<br />
Definition 2.3<br />
i) Ein Pfad bezeichnet eine Folge von Knoten v 1 , v 2 , . . . , v k mit k ≥ 2, wobei zwei<br />
aufeinanderfolgende Knoten v i , v i+1 durch eine Kante im Graphen verb<strong>und</strong>en sind.<br />
ii) Ein Zyklus ist ein Pfad mit paarweise verschiedenen Knoten; nur der erste Knoten<br />
muss mit dem letzten übereinstimmen. In ungerichteten Graphen wird k ≥ 4 für<br />
Zyklen verlangt.<br />
iii) Ein Teilgraph ist ein Graph, dessen Knoten <strong>und</strong> Kanten eine Teilmenge der ursprünglichen<br />
Knoten- bzw. Kanten-Menge bilden.<br />
iv) Ein ungerichteter Baum ist ein ungerichteter Graph, bei dem alle Knoten durch<br />
Pfade verb<strong>und</strong>en sind <strong>und</strong> keine Zyklen existieren.<br />
v) Ein gerichteter Baum ist ein gerichteter Graph, in dem es ein v ∈ V gibt, sodass<br />
für jedes w ∈ V genau ein Pfad von v nach w existiert. v wird als die Wurzel des<br />
Baumes bezeichnet.<br />
Abbildung 2.1 zeigt beispielhaft einen ungerichteten <strong>und</strong> einen gerichteten Graphen.<br />
In beiden Graphen wäre (a, c, e) ein gültiger Pfad, während (d, c) nur in G A ein gültiger<br />
Pfad wäre, nicht in G B . (c, d, e, c) stellt einen Zyklus in G A dar, während G B zyklenfrei<br />
(oder azyklisch) ist. Da in G B außerdem alle Knoten durch Pfade vom Knoten a erreicht<br />
werden können, handelt es sich dabei um einen Baum mit Wurzel a.<br />
2.2. Mapping <strong>und</strong> Matching<br />
Unter dem Begriff Mapping werden allgemein Korrespondenzen zwischen zwei Elementen<br />
– also zum Beispiel zwei Attributen in einem Relationalen Datenbankschema – verstanden,<br />
die in irgendeiner Weise in Beziehung zueinander stehen. Im Kontext der Integration<br />
von <strong>Datenbanken</strong> sind hier insbesondere semantische Korrespondenzen gemeint,<br />
das heißt Zusammenhänge, die aufgr<strong>und</strong> semantischer Gemeinsamkeiten zwischen den<br />
Elementen der Schemata gef<strong>und</strong>en werden können. Zum Beispiel sind zwei Relationen<br />
semantisch ähnlich, wenn sie Daten über dieselben oder ähnliche Objekte der Realwelt<br />
enthalten.<br />
Aus Mappings können Transformationen bzw. Transformationsanfragen abgeleitet<br />
werden, mit denen sich die Daten eines Quellschemas in ein Zielschema überführen<br />
lassen. Wie genau solche Transformationen aussehen können, wird in [LN07] ausführlich<br />
anhand eines Beispiels erläutert, soll allerdings im Rahmen dieser Arbeit nicht weiter<br />
vertieft werden. Ebenso werden dort ausführlich verschiedene Mapping-Situationen <strong>und</strong><br />
8
Möglichkeiten erläutert, wie Mappings zu interpretieren sind. Auch darauf soll hier nicht<br />
vertiefend eingegangen werden.<br />
Matching bezeichnet den Prozess des Auffindens von semantischen Korrespondenzen<br />
zwischen Elementen, also des Ermittelns von Mappings. Speziell handelt es sich dabei<br />
häufig um eine Operation, die genau zwei Schemata (oder zwei Ontologien) als Eingabe<br />
bekommt <strong>und</strong> ein Mapping zwischen semantisch ähnlichen Elementen zurückliefert. Diese<br />
Operation wird häufig als Match bezeichnet (vgl. [RB01]).<br />
Matchings spielen in einer Vielzahl von Anwendungen eine Rolle, wie etwa bei der<br />
Daten-Migration oder Schema-Integration. Ein Beispiel für eine typische Anwendung ist<br />
die Fusion zweier Unternehmen aus derselben Branche, die beide gewisse Datenmengen<br />
zur Verfügung haben, die allerdings unterschiedlich vollständig <strong>und</strong> auf verschiedene<br />
Weise abgespeichert sind. Um sie in einer Datenbank zusammenzufügen, ist hier ein<br />
Matching notwendig, das Mappings zwischen den Schemata der beiden Datenbestände<br />
ermittelt.<br />
Durch Matching-Verfahren wird heutzutage versucht, den Prozess des Matchings in<br />
Teilen zu automatisieren, um mit großen Datenmengen umgehen zu können. Die Idee<br />
dabei ist es, dass ein Matcher Schemata, Struktur <strong>und</strong> Daten analysiert <strong>und</strong> daraus Vorschläge<br />
für Korrespondenzen liefert, die von Domänenexperten akzeptiert oder abgelehnt<br />
werden können (vgl. [LN07]).<br />
9
3. Matching-Verfahren<br />
3.1. Geschichte<br />
Matching-Verfahren existieren schon seit vielen Jahren. Bereits in den frühen 80er Jahren<br />
befasste man sich mit dem Problem, eine Menge unabhängiger Schemata zu integrieren.<br />
Ziel ist es, Zusammenhänge zwischen den oft sehr unterschiedlichen Schemata zu finden<br />
<strong>und</strong> zu nutzen.<br />
In den frühen 90er Jahren ging es bei solchen Matchings hauptsächlich darum, spezifische<br />
Programme zu entwickeln, um Daten umzuwandeln. Hintergr<strong>und</strong> davon war<br />
die immer stärkere Bedeutung des Web, sodass in diesem Zusammenhang etwa der<br />
L A TEX2HTML-Übersetzer entstanden ist, um Daten aus L A TEX in webkompatibles HTML<br />
umzuwandeln [Dra93]. Außerdem wurde die Integration von Daten in ein Data Warehouse<br />
populär, d.h. man versuchte verstärkt, Methoden zu finden, um Quelldaten in Form<br />
von Relationalen Schemata in ein Format umzuwandeln, in dem es mit dem Format des<br />
Data Warehouse kompatibel war ([RB01]).<br />
Das Ziel von Verfahren wie dem L A TEX2HTML-Übersetzer war es im Wesentlichen,<br />
die zeitaufwändige <strong>und</strong> fehleranfällige manuelle Integrationsarbeit zu automatisieren<br />
([RB01]). Da die Verfahren zunächst sehr spezifisch für eine Aufgabe waren, musste hier<br />
viel Aufwand in die Programmierung investiert werden <strong>und</strong> für jedes Problem umfangreiches<br />
domänenspezifisches Wissen angeeignet werden ([MZ98]). Ab den späten 90er<br />
Jahren ging es deswegen vermehrt darum, generischere Verfahren zu entwickeln, um verschiedene<br />
Arten von Eingabedaten – wie XML-Dateien, Realtionale Schemata o.ä. – mit<br />
weniger Programmieraufwand matchen zu können.<br />
[MZ98] stellt mit TranScm ein solches Verfahren vor, dass gleichzeitig auch eines<br />
der ersten ist, welches Schemata graph-basiert matcht. Die Idee dabei ist, Quelldaten<br />
mit Hilfe eines regel-basierten Systems mit Zieldaten zu matchen, um anschließend die<br />
gematchten Quell- in die Zieldaten transformieren zu können. Dabei werden die Eingabedaten<br />
jeweils als Graphen dargestellt <strong>und</strong> anschließend Matches zwischen den Quell<strong>und</strong><br />
Zieldaten gesucht, was durch eine Menge von Regeln geschieht, die auf die Graphen<br />
angewandt werden.<br />
Um die Jahrtausendwende herum entstanden eine ganze Reihe von Matching-Verfahren<br />
mit teils sehr unterschiedlichen Ansätzen. Beispiel für solche Verfahren sind etwa SKAT,<br />
LSD, ARTEMIS, CUPID <strong>und</strong> Similarity Flooding ([RB01]). Enorm wachsende Datenmengen<br />
im Web <strong>und</strong> im immer bedeutender werdenden E-Commerce-Bereich waren der<br />
Antrieb dafür, dass sich Autoren sehr stark mit der Entwicklung von Matching-Verfahren<br />
auseinandersetzten.<br />
Obwohl auch in den Jahren nach der Jahrtausendwende eine Reihe neuer Verfahren<br />
10
(etwa OLA oder Microsoft BizTalk Mapper) oder Varianten bestehender Verfahren (z.B.<br />
NOM ) entstanden ([SE05]), stellte [Gal06] 2006 fest, dass sich trotz intensiver Forschung<br />
bislang keines der entwickelten Schema-Matching-Verfahren durchgesetzt hat. Stattdessen<br />
würden immer noch ad-hoc-Lösungen eingesetzt, obwohl das Ziel der Matching-<br />
Verfahren eigentlich ja genau die Vermeidung solcher Lösungen sein sollte.<br />
Neben den „klassischen“ Verfahren zum Matching von Schemata wurden vor allem<br />
in den letzten knapp 12 Jahren vermehrt Verfahren zum Matchen von Ontologien verwendet.<br />
[Rah11] nennt hier unter anderem Falcon <strong>und</strong> Rimom aus dem Jahr 2006 <strong>und</strong><br />
Harmony, erstmals vorgestellt 2008.<br />
Trotz vieler Fortschritte, die bei der Entwicklung von Schema-Matching-Verfahren in<br />
den vorangegangenen Jahren gemacht wurden, bescheinigte [Rah11] diesen 2011 immer<br />
noch Schwierigkeiten bei large-scale-Matchings, also Matchings in großem Umfang <strong>und</strong><br />
mit großen Datenmengen. So würden nach wie vor näherungsweise Mappings ermittelt<br />
werden können, Anpassungen durch menschliche Experten wären nach wie vor nötig <strong>und</strong><br />
das Problem, gute Effektivität bei gleichzeitig guter Effizienz zu erreichen, wäre immer<br />
noch nicht gelöst.<br />
3.2. Klassifizierung von Matching-Verfahren<br />
Da die Zahl von Matching-Verfahren stetig wächst, ist es sinnvoll, diese in bestimmte<br />
Kategorien einzuteilen, um den Überblick behalten zu können. In der Literatur wurde<br />
in [RB01] eine solche Klassifizierung vorgenommen, die in [SE05] in Teilen verändert<br />
<strong>und</strong> erweitert wurde. Diese Klassifizierungen sollen in diesem Abschnitt kurz erläutert<br />
werden. Da der Fokus dieser Arbeit auf dem Graph-Matching liegt, soll dabei insbesondere<br />
darauf eingegangen werden, an welcher Stelle sich dieses in den Kontext der<br />
Schema-Matching-Verfahren einordnen lässt.<br />
In [RB01] wird zunächst zwischen individuellen <strong>und</strong> kombinierten Matching-Ansätzen<br />
(auch als Matcher bezeichnet) unterschieden. Individuelle Ansätze verwenden ein einzelnes<br />
Kriterium für das Matching. Sie können entweder ausschließlich schema-basiert<br />
oder instanz-/inhalts-basiert sein. Kombinierte Matcher können entweder mehrere Ansätze<br />
zusammenfassen <strong>und</strong> anhand mehrerer Kriterien ihr Matching durchführen (hybride<br />
Matcher) oder die Ergebnisse mehrerer verschiedener Ansätze zusammenfassen<br />
(Komposition).<br />
Graph-Matching-Verfahren werden dabei den individuellen Matchern <strong>und</strong> dort den<br />
ausschließlich schema-basierten zugeordnet. Im Normalfall werden keinerlei Daten für<br />
das Matching benötigt, sondern lediglich Informationen aus den Schemata. Das Similarity<br />
Flooding, das in dieser Arbeit besonders intensiv betrachtet werden soll, kann<br />
dabei in gewissem Sinne als Ausnahme betrachtet werden, denn dabei wird für das Matching<br />
selbst zwar ausschließlich die Struktur der Schemata herangezogen, in der Vorverarbeitungsphase<br />
sind aber auch weitere Kriterien möglich, die eventuell andere Daten<br />
benötigen (wie zum Beispiel Wörterbücher oder Thesauri).<br />
Auf der nächst-niedrigeren, detaillierteren Ebene unterscheidet man bei den ausschließlich<br />
schema-basierten Matchern zwischen Element-Ebene <strong>und</strong> Struktur-Ebene. Auf<br />
11
Abbildung 3.1.: Klassifizierung von Matching-Verfahren nach [RB01]<br />
der Element-Ebene sind Verfahren zu finden, deren Matching-Kriterien jeweils einzelne<br />
Elemente der Schemata auf der niedrigsten (atomaren) Ebene betrachten, also zum Beispiel<br />
Attribute. Im Gegensatz dazu werden auf der Struktur-Ebene Zusammenhänge<br />
zwischen einzelnen Elementen berücksichtigt. Graph-Matching-Verfahren fallen somit in<br />
letztere Kategorie.<br />
Abbildung 3.1 zeigt die Klassifizierungen, wie sie in [RB01] gemacht werden. Die<br />
Stelle, an der die Graph-Matching-Verfahren eingeordnet werden, ist dabei hervorgehoben.<br />
Unterhalb der letzten Ebene sind noch weitere Kriterien denkbar, nach denen die<br />
Verfahren eingeteilt werden können, auf die allerdings nicht näher eingegangen werden<br />
soll.<br />
Während [RB01] allgemein Matching-Verfahren klassifiziert, beschränkt sich [SE05]<br />
auf schema-basierte Verfahren, betrachtet also nur einen Teilbaum der Klassifizierung in<br />
Abbildung 3.1. Dafür wird hier eine detailliertere Klassifizierung vorgenommen, welche in<br />
zwei Bereiche eingeteilt ist, die jeweils baumartig strukturiert sind (vgl. Abbildung 3.2).<br />
Der obere Bereich klassifiziert nach der Granularität der Matches <strong>und</strong> anschließend<br />
danach, wie die jeweilige Technik Informationen aus der Eingabe interpretiert. Die Einteilung<br />
nach der Granularität wird dabei wie schon in [RB01] nach Element- <strong>und</strong> Struktur-<br />
Ebene vorgenommen. Unterhalb dieser Ebenen wird zwischen syntaktisch (nur die Struktur<br />
ist für die Interpretation der Eingabe relevant), extern (zusätzliche Hilfsinformationen<br />
werden verwendet) <strong>und</strong> semantisch (formale Semantik als Basis für Interpretation)<br />
unterschieden. Nach dieser Klassifizierung befindet sich das Graph-Matching-Verfahren<br />
– wie in Abbildung 3.2 hervorgehoben – unterhalb der Struktur-Ebene <strong>und</strong> bei den<br />
syntaktischen Verfahren.<br />
Die zweite Klassifizierung im unteren Baum geschieht anhand der Art der Eingabe.<br />
Hier wird zunächst zwischen terminologischen, strukturellen <strong>und</strong> semantischen Eingaben<br />
unterschieden. Bei terminologischen handelt es sich um Zeichenketten, die entweder<br />
String-basiert sind, das heißt die Eingabe als Zeichenkette betrachten, oder die Ter-<br />
12
Abbildung 3.2.: Klassifizierung von Matching-Verfahren nach [SE05]<br />
me als linguistische Objekte auffassen, in denen bestimmte Teile wie etwa Wortstämme<br />
identifiziert werden können. Bei strukturellen Verfahren wird weiter nach internen <strong>und</strong><br />
relationalen unterschieden. Interne betrachten die interne Struktur der Elemente, während<br />
relationale die Beziehungen zwischen mehreren Elementen betrachten. Von dieser<br />
Klassifizierung aus gesehen befinden sich Graph-Matching-Verfahren also bei den relationalen<br />
strukturellen Verfahren.<br />
3.3. Graph Matching<br />
Nachdem der vorherige Abschnitt einen Überblick darüber geliefert hat, wo man seine<br />
Verfahren einordnen kann, soll hier speziell auf das Thema Graph Matching <strong>und</strong> seine<br />
Besonderheiten eingegangen werden sowie ein Überblick über Forschungen an der Leibniz<br />
Universität Hannover in Bezug auf Graph Matching von räumlichen Daten geliefert<br />
werden.<br />
3.3.1. Besonderheiten des Graph Matchings<br />
Die Idee, Graphen zu verwenden, um damit Matchings zu ermitteln, ist vermutlich auf<br />
zwei Aspekte zurückzuführen. In der Graphentheorie beschäftigt man sich schon sehr<br />
lange mit der Frage, wie man Ähnlichkeiten zwischen zwei Graphen finden kann. So<br />
wurde zum Beispiel im Jahr 1976 in [Ull76] ein Verfahren vorgestellt, das Isomorphismen<br />
zwischen zwei Graphen ermittelt – Jahre bevor die Suche nach Matching-Verfahren für<br />
Schemata begann. Das Verfahren von Ullman kann ausschließlich auf zwei Graphen G 1<br />
<strong>und</strong> G 2 angewandt werden, bei denen der eine im anderen enthalten ist, <strong>und</strong> arbeitet in<br />
13
einer Laufzeit von O(n 2 ).<br />
Da in der Graphentheorie somit schon eine Reihe von Verfahren <strong>und</strong> Überlegungen<br />
vorhanden waren, lag der Versuch nahe, diese auch auf Schemata bzw. allgemein auf<br />
andere Datenstrukturen zu übertragen.<br />
Hinzu kommt, dass die Verwendung von Graphen in Matching-Verfahren sehr viel<br />
mehr Möglichkeiten von Eingabewerten bietet als andere Verfahren. Theoretisch können<br />
als Eingabe alle Datenstrukturen verwendet werden, die sich in geeigneter Form als<br />
Graphen darstellen lassen. Dadurch sind Graph-Matching-Verfahren weitaus generischer<br />
<strong>und</strong> können in mehr Bereichen eingesetzt werden als Verfahren, die zum Beispiel nur auf<br />
Basis von XML arbeiten <strong>und</strong> deshalb nur XML-Dateien als Eingaben akzeptieren.<br />
Das erste Graph-Matching-Verfahren ist – wie bereits in Kapitel 3.1 erwähnt – Tran-<br />
Scm aus dem Jahr 1998, vorgestellt in [MZ98]. Dabei wurde genau die gr<strong>und</strong>sätzliche<br />
Idee hinter Graph-Matching-Verfahren verfolgt, nämlich ein Verfahren zu entwickeln,<br />
um mit verschiedenen Formaten von Daten umgehen <strong>und</strong> daraus Matchings bestimmen<br />
zu können. Seit diesem ersten Verfahren entstanden noch eine Reihe weiterer, wie zum<br />
Beispiel Cupid, Rondo, SASMINT <strong>und</strong> das Similarity Flooding, von denen im Rahmen<br />
dieser Arbeit besonders das Similarity Flooding aus dem Jahr 2001 im Fokus steht.<br />
3.3.2. Graph Matching bei räumlichen Daten<br />
Ein Forschungsgebiet an der Leibniz Universität Hannover, in dem Graph Matching<br />
Verfahren eine wichtige Bedeutung spielen, ist das Matching von räumlichen Daten.<br />
Ziel dabei ist es, geographische Datenbestände wie etwa Straßenkarten zu matchen,<br />
die verschiedene Detaillierungsgrade aufweisen <strong>und</strong> unterschiedliche Erfassungskriterien<br />
verwenden.<br />
Im Rahmen dieses Themas wurde in [Tie03] zunächst ein Modell entwickelt, das räumliche<br />
<strong>Datenbanken</strong> um topologische Informationen erweitert <strong>und</strong> es ermöglicht, bestimmte<br />
topologische Integritätsbedingungen zu erstellen. Dieses Modell stellt die Gr<strong>und</strong>lage<br />
für eine Reihe weiterer Arbeiten dar. So wird zum Beispiel in [Rip04] mit dem BFS-<br />
Matching-Verfahren ein Graph Matching Verfahren vorgestellt, das auf räumlichen Datenbeständen<br />
arbeiten kann. Ebenso wird der Algorithmus von Ullman (vgl. [Ull76]) in<br />
einer modifizierten Version darauf angewandt. [Sch09] stellt mit dem GeoFoed-Matching<br />
ein Verfahren dar, das an der Leibniz Universität zum Matching geographischer Daten<br />
entwickelt wurde.<br />
Auch wenn also bereits einige Verfahren existieren, um räumliche Daten zu matchen,<br />
ist die Suche nach weiteren <strong>und</strong> eventuell besseren Verfahren noch nicht abgeschlossen.<br />
Obwohl der Schwerpunkt dieser Arbeit wie anfangs erwähnt eher auf dem Schema-<br />
Matching <strong>und</strong> nicht auf dem Matching räumlicher Daten liegt, stellt sich natürlich die<br />
Frage, ob sich Verfahren wie das Similarity Flooding unter Umständen ebenso für ein<br />
solches Matching von räumlichen Datenbeständen eignen.<br />
14
4. Der Similarity Flooding Algorithmus<br />
In diesem Kapitel soll der in [MGMR01] vorgestellte Similarity Flooding Algorithmus<br />
ausgearbeitet werden. Dazu wird zunächst der Gr<strong>und</strong>gedanke vorgestellt, bevor im Verlauf<br />
des Kapitels näher in die Details des eigentlichen Ablaufs des Algorithmus eingegangen<br />
<strong>und</strong> zum Schluss dargestellt wird, wie mit den Ergebnissen aus dem Algorithmus<br />
umzugehen ist.<br />
4.1. Gr<strong>und</strong>idee<br />
Der Similarity Flooding Algorithmus entstand aus der Idee heraus, einen „einfachen<br />
strukturellen Algorithmus“ zu entwickeln, der in der Lage ist, unterschiedliche Datenstrukturen<br />
zu „matchen“ <strong>und</strong> so ein „breites Spektrum verschiedener Szenarien“ abzudecken<br />
(vgl. [MGMR01]). Dabei sollte es nicht das Ziel sein, einen vollautomatischen<br />
Algorithmus zu entwickeln, der komplett ohne manuelle Nachbearbeitung das Matching<br />
durchführt. Vielmehr gibt der Similarity Flooding Algorithmus angewandt auf zwei Datenstrukturen<br />
(im Folgenden auch als Modelle bezeichnet) Vorschläge über potenzielle<br />
Matching-Kandidaten zurück, aus denen anschließend von Menschen die korrekten Kombinationen<br />
von Matches herausgesucht werden müssen.<br />
Der Gr<strong>und</strong>gedanke hinter dem Algorithmus ist es, die zu matchenden Modelle zunächst<br />
in gerichtete, markierte Graphen umzuwandeln, um in diesen Graphen anschließend<br />
iterativ Ähnlichkeiten zwischen Knoten zu berechnen. Auf diese Weise wird es<br />
ermöglicht, dass das Verfahren trotz verschiedenartiger Modelle (z.B. ein XML- <strong>und</strong> ein<br />
relationales Schema) mögliche Matching-Kandidaten findet. Näheres zu den Umwandlungen<br />
der Modelle in Graphen wird in Kapitel 4.2 erläutert.<br />
Die Berechnung der Ähnlichkeiten basiert auf der Idee, dass die Elemente von zwei unterschiedlichen<br />
Modellen genau dann ähnlich sind, wenn angrenzende Elemente ähnlich<br />
sind. Auf Graphen zurückgeführt bedeutet das, dass die Ähnlichkeiten von Knoten abhängig<br />
von den Ähnlichkeiten der angrenzenden Knoten sind, die wiederum ebenfalls von<br />
ihren angrenzenden Knoten abhängig sind <strong>und</strong> so weiter. Auf diese Weise „fließen“ Ähnlichkeiten<br />
durch den Graphen, woraus auch der Name „Similarity Flooding“ entstanden<br />
ist. Kapitel 4.3 stellt die näheren Details des Ablaufs des Algorithmus dar.<br />
Als Ergebnis dieses „Flusses“ erzeugt der Algorithmus eine Menge von Zuordnungen<br />
von Ähnlichkeitswerten zu Paaren von Knoten, die als Mapping bezeichnet wird. Diese<br />
Mappings stellen noch nicht die Ergebnisse dar, die als Ausgabe aus dem Algorithmus<br />
geliefert werden <strong>und</strong> anschließend von Menschen weiter verarbeitet werden sollen. Stattdessen<br />
werden sie intern – <strong>und</strong> je nach Anwendungsgebiet unterschiedlich – gefiltert,<br />
um so eine besser überschaubare Menge an Ergebnissen zu bekommen. Näheres zu den<br />
15
Abbildung 4.1.: Zwei zu matchende Modelle<br />
Filtern <strong>und</strong> dem Umgang mit den Ergebnissen wird in Kapitel 4.4 beschrieben.<br />
4.2. Vorbereitung<br />
Für den Ablauf des Similarity Flooding Algorithmus ist es – wie bereits in Kapitel<br />
4.1 erwähnt – notwendig, die zu matchenden Modelle zunächst in gerichtete, markierte<br />
Graphen zu transformieren. Da es sich bei den Modellen um sehr unterschiedliche Datenstrukturen<br />
handeln kann, soll hier zunächst nicht näher darauf eingegangen werden,<br />
wie für jede einzelne Struktur ein entsprechender Graph erzeugt werden kann. Vielmehr<br />
wird vorausgesetzt, dass es eine entsprechende Prozedur oder Methode gibt, durch die<br />
ein gerichteter, markierter Graph aus einem Modell erzeugt wird. Kapitel 7.3 stellt im<br />
Rahmen der Experimente eine Methode vor, wie man Relationale Datenbankschemata<br />
transformieren kann.<br />
In den durch die Transformation erstellten Graphen für die zu matchenden Modelle<br />
kann jede Kante durch ein Tripel (s, p, o) dargestellt werden. Dabei ist s der Quellknoten,<br />
o der Zielknoten <strong>und</strong> p das Label, das die Kante beschriftet (oder die Markierung).<br />
Aufgr<strong>und</strong> dieser Voraussetzung, dass alle Modelle in Graphen überführt werden können,<br />
wird im Folgenden nicht immer streng zwischen den Begriffen Modell <strong>und</strong> Graph<br />
für ein Modell unterschieden. Der Begriff Knoten wird dabei sowohl für die Elemente<br />
des Graphen als auch für die des Modells verwendet, um unnötige Verdopplungen bei<br />
den Begrifflichkeiten zu vermeiden. Ebenso soll der Begriff der Kante für Modelle <strong>und</strong><br />
Graphen analog verwendet werden, wobei hier stets von gerichteten Kanten die Rede<br />
ist.<br />
Abbildung 4.1 zeigt zwei Modelle A <strong>und</strong> B, an denen beispielhaft der Ablauf des<br />
Similarity Flooding Algorithmus näher erläutert werden soll.<br />
Um die Ähnlichkeiten zwischen den Knoten der Modelle berechnen zu können, werden<br />
die beiden Modelle zunächst in einen Pairwise Connectivity Graph (PCG) <strong>und</strong> anschließend<br />
in einen sogenannten Similarity Propagation Graph (SPG) überführt.<br />
16
Definition 4.1 Seien A <strong>und</strong> B zwei Modelle, x, x ′ Knoten in A, y, y ′ Knoten in B.<br />
Ferner sei (x, p, x ′ ) ∈ A eine mit p beschriftete Kante in A, (y, p, y ′ ) ∈ B eine mit<br />
demselben p beschriftete Kante in B. Dann gilt für alle Kanten des Pairwise Connectivity<br />
Graph (PCG) zu A <strong>und</strong> B:<br />
((x, y), p, (x ′ , y ′ )) ∈ P CG(A, B) ⇔ (x, p, x ′ ) ∈ A <strong>und</strong> (y, p, y ′ ) ∈ B<br />
Ein Knoten (a, b) eines PCG stellt dabei ein Element aus A × B dar <strong>und</strong> wird als Map<br />
Pair bezeichnet.<br />
Definition 4.1 setzt voraus, dass es in den beiden Modellen A <strong>und</strong> B gleich beschriftete<br />
Kanten gibt. Andernfalls würde es im PCG weder Knoten noch Kanten geben <strong>und</strong> der<br />
Algorithmus würde nicht mehr funktionieren.<br />
Um zu gewährleisten, dass der Algorithmus funktioniert, wird – auch wenn es von<br />
den Entwicklern des Algorithmus nicht explizit erwähnt wird – davon ausgegangen, dass<br />
nach der Umwandlung der Modelle in Graphen der Durchschnitt der beiden Markierungsmengen<br />
nichtleer ist, es also mindestens eine gleich beschriftete Kante in beiden<br />
Graphen gibt. Da – unabhängig von der Art der zu matchenden Modelle – immer gewisse<br />
strukturelle Gemeinsamkeiten zwischen zwei Modellen entdeckt werden können,<br />
kann davon ausgegangen werden, dass diese Bedingung für jede Art von betrachteten<br />
Modellen erfüllt werden kann.<br />
Um einen PCG aus den beiden Graphen (bzw. Modellen) für A <strong>und</strong> B zu bekommen,<br />
geht man, der Definition 4.1 folgend, so vor: Wenn es eine Kante zwischen zwei Knoten<br />
x <strong>und</strong> x ′ in A gibt, die mit einem Label p beschriftet ist, <strong>und</strong> es eine ebenso beschriftete<br />
Kante zwischen zwei Knoten y <strong>und</strong> y ′ in B gibt, fügt man die Knoten (bzw. Map Pairs)<br />
(x, y) <strong>und</strong> (x ′ , y ′ ) – sofern sie noch nicht vorhanden sind – sowie eine Kante zwischen<br />
ihnen im PCG ein.<br />
Die Idee hinter dieser Konstruktion ist, dass für den Fall, dass zwei Knoten x <strong>und</strong><br />
x ′ in A ähnlich sind, wahrscheinlich auch die zwei Knoten y <strong>und</strong> y ′ in B, die über<br />
eine gleich beschriftete Kante verb<strong>und</strong>en sind, ähnlich sind. Daraus resultiert die Kante<br />
zwischen den beiden Map Pairs (x, y) <strong>und</strong> (x ′ , y ′ ) im PCG. Das gemeinsame Label p aus<br />
den beiden Modellgraphen wird dabei auch in den PCG übernommen, um Rückschlüsse<br />
darauf liefern zu können, woraus die Map Pairs <strong>und</strong> der PCG entstanden sind. (x, y)<br />
<strong>und</strong> (x ′ , y ′ ) werden auch als Nachbarn bezeichnet.<br />
Die Konstruktion eines Pairwise Connectivity Graph aus zwei Modellen A <strong>und</strong> B<br />
kann durch die Methode erzeugePCG erfolgen, die im Pseudocode 4.1 dargestellt ist. Sei<br />
n die Anzahl der Kanten in Modell A, m die Anzahl der Kanten in Modell B. Dann hat<br />
der Algorithmus zur Konstruktion des PCG eine Komplexität von O(n ∗ m).<br />
17
Abbildung 4.2.: Pairwise Connectivity Graph zu A <strong>und</strong> B<br />
Pseudocode 4.1: erzeugePCG(Modell A, Modell B)<br />
pcg ← 0;<br />
for each Kante (a 1 , a 2 ) aus A mit Label l a do<br />
for each Kante (b 1 , b 2 ) aus B mit Label l b do<br />
if (l a = l b ) then<br />
if (a 1 , b 1 ) /∈ pcg then<br />
füge (a 1 , b 1 ) zu pcg hinzu;<br />
if (a 2 , b 2 ) /∈ pcg then<br />
füge (a 2 , b 2 ) zu pcg hinzu;<br />
füge Kante ((a 1 , b 1 ), l a , (a 2 , b 2 )) zu pcg hinzu;<br />
return pcg;<br />
Abbildung 4.2 zeigt den PCG, der aus den Modellen A <strong>und</strong> B aus Abbildung 4.1<br />
entsteht. Dabei wurde z.B. der Knoten (a 4 , b 2 ) erzeugt, weil sowohl vom Knoten a 4 in A<br />
als auch vom Knoten b 2 in B eine Kante mit dem Label l 2 ausgeht. Der Knoten (a 2 , b 3 )<br />
<strong>und</strong> die l 2 -Verbindung zwischen (a 4 , b 2 ) <strong>und</strong> (a 2 , b 3 ) resultiert daraus, dass es in A eine<br />
l 2 -Kante von a 4 nach a 2 <strong>und</strong> in B eine l 2 -Kante von b 2 nach b 3 gibt.<br />
Definition 4.2 Seien A <strong>und</strong> B zwei Modelle <strong>und</strong> pcg der Pairwise Connectivity Graph<br />
zu A <strong>und</strong> B. Dann kann der zugehörige Similarity Propagation Graph (SPG) spg durch<br />
die folgenden beiden Modifikationen aus pcg erzeugt werden:<br />
1. Füge für jede Kante von pcg eine neue Kante (eine sogenannte Rückkante) in spg<br />
ein (sofern sie nicht bereits existiert), die in die entgegengesetzte Richtung weist<br />
wie die Kante in pcg<br />
2. Gewichte jede Kante von pcg mit einem Wert im Intervall von 0 <strong>und</strong> 1<br />
Die Kantengewichte im SPG werden dabei als Propagation-Koeffizienten bezeichnet.<br />
18
Gemäß der Definition wird also zunächst für jede Kante im PCG eine zweite Kante<br />
eingefügt, die in die entgegengesetzte Richtung führt, es sei denn, diese ist bereits<br />
vorhanden. Zudem werden alle Kanten gewichtet, um auszudrücken, wie gut die Ähnlichkeiten<br />
zwischen zwei Map Pairs an ihre Nachbarn weitergegeben werden können.<br />
Diese Propagation-Koeffizienten werden durch eine Funktion ω((a, b), (x, y)) beschrieben,<br />
welche der Kante zwischen den Map Pairs (a, b) <strong>und</strong> (x, y) im SPG einen Wert aus<br />
[0, 1] zuweist.<br />
Pseudocode 4.2 zeigt die Methode erzeugeSPG, die einen Similarity Propagation<br />
Graph aus einem gegebenen PCG <strong>und</strong> zwei Modellen erzeugt. Die Komplexität dieser<br />
Methode ist dabei linear bezogen auf die Anzahl der Kanten im PCG.<br />
Pseudocode 4.2: erzeugeSPG(PCG pcg)<br />
spg ← 0;<br />
for each Kante ((a 1 , a 2 ), p, (b 1 , b 2 )) ∈ pcg do<br />
if Kante ((b 1 , b 2 ), q, (a 1 , a 2 )) /∈ pcg then<br />
füge Kante ((b 1 , b 2 ), null, (a 1 , a 2 )) zu spg hinzu;<br />
for each Kante ((a 1 , a 2 ), p, (b 1 , b 2 )) ∈ spg do<br />
gewichte Kante ((a 1 , a 2 ), p, (b 1 , b 2 )) mit ω((a 1 , a 2 ), (b 1 , b 2 ));<br />
return spg;<br />
Die Autoren von [MGMR01] stellen für die Berechnung der Propagation-Koeffizienten<br />
sieben verschiedene Formeln vor, deren Qualität sie in Experimenten verglichen haben.<br />
Beispielhaft sollen im Rahmen dieser Arbeit zwei der Formeln vorgestellt werden, von<br />
denen die eine Verwendung in den Beispielen im weiteren Verlauf dieses Kapitels findet,<br />
während die andere sich laut Autoren als die beste der Formeln für das Similarity<br />
Flooding herausgestellt hat.<br />
Der Vollständigkeit halber sind alle sieben Formeln in Tabelle 4.1 aufgeführt. Dort<br />
wird für die Notation der Propagation-Koeffizienten eine etwas andere Schreibweise verwendet,<br />
als es mit der Funktion ω der Fall ist. Während ω das Gewicht zwischen zwei<br />
Map Pairs bezogen auf den PCG angibt, wird in Tabelle 4.1 eine Schreibweise verwendet,<br />
die ausschließlich Bezug auf die Modelle nimmt. Dabei berechnet π l (〈x, p, A〉, 〈y, q, B〉)<br />
den Propagation-Koeffizienten der ausgehenden Kante bzw. Kanten des Map Pairs (x, y)<br />
<strong>und</strong> π r (〈x, p, A〉, 〈y, q, B〉) den der eingehenden Kante bzw. Kanten des Map Pairs (x, y).<br />
Für die Berechnung der Ähnlichkeit eines Map Pairs (a, b) wird also für die eingehenden<br />
Kanten vom Map Pair (x, y) der Wert π l (〈x, p, A〉, 〈y, q, B〉) berechnet, der dem Wert<br />
ω((a, b), (x, y)) entspricht.<br />
Es sei an dieser Stelle darauf hingewiesen, dass die Schreibweise, die in der Tabelle<br />
verwendet wird, lediglich zur Verdeutlichung der Unterschiede der beiden hier vorgestellten<br />
Formeln dienen soll. Darüber hinaus soll sie zeigen, dass die Berechnung der<br />
Propagation-Koeffizienten auch allgemeiner (also ohne den PCG) erfolgen kann. Für die<br />
Beispiele im weiteren Verlauf dieses Kapitels soll dann allerdings wieder die etwas kürzere<br />
<strong>und</strong> anschaulichere Schreibweise mit ω verwendet werden, die die Berechnung der<br />
19
Ansatz p = q p ≠ q<br />
Inverser Durchschnitt<br />
2<br />
card {l,r} (x,p,A)+card {l,r} (y,q,B)<br />
0<br />
Inverses Produkt<br />
1<br />
card {l,r} (x,p,A)·card {l,r} (y,q,B)<br />
0<br />
Gesamt-<br />
Inverser<br />
durchschnitt<br />
Inverses<br />
produkt<br />
Gesamt-<br />
2<br />
card {l,r} (x,p)+card {l,r} (y,q)<br />
0<br />
1<br />
card {l,r} (x,p)·card {l,r} (y,q)<br />
0<br />
Kombinierter inverser<br />
Durchschnitt<br />
4<br />
(card {l,r} (p,A)+card {l,r} (q,B))·(card {l,r} (c,p,A)+card {l,r} (y,q,B))<br />
0<br />
1<br />
Stochastisch ∑<br />
∀p ′ (card {l,r} (x,p ′ ,A)·card {l,r} (y,p ′ ,B))<br />
0<br />
Konstant 1.0 0<br />
Tabelle 4.1.: Berechnungsformeln für die Propagation-Koeffizienten<br />
20
Abbildung 4.3.: Similarity Propagation Graph zu A <strong>und</strong> B<br />
Propagation-Koeffizienten bezogen auf zwei Map Pairs im PCG berechnet.<br />
Die beiden hier vorgestellten Formeln für π berechnen die Propagation-Koeffizienten<br />
in Abhängigkeit der Anzahl eingehender <strong>und</strong> ausgehender Kanten in den Modellen A<br />
<strong>und</strong> B. Die inverse Produktformel berechnet zum Beispiel π dabei wie folgt:<br />
⎧<br />
⎨<br />
1<br />
card<br />
π {l,r} (〈x, p, A〉, 〈y, q, B〉) = {l,r} (x,p,A)·card {l,r} (y,q,B) , wenn p = q<br />
⎩0, wenn p ≠ q<br />
Da die Formel π für die ausgehenden (π l ) <strong>und</strong> eingehenden (π r ) Kanten gleichermaßen<br />
berechnet wird, wird hier abkürzend die Schreibweise π {l,r} verwendet. card l (x, p, M) =<br />
|{(x, p, t)|∃t : (x, p, t) ∈ M}| bezeichnet die Anzahl der ausgehenden Kanten eines Knotens<br />
x mit dem Label p in M <strong>und</strong> card r (x, p, M) = |{(t, p, x)|∃t : (t, p, x) ∈ M}| die<br />
Anzahl der eingehenden, mit p beschrifteten Kanten. card {l,r} ist ebenfalls eine abkürzende<br />
Schreibweise, wobei gilt:<br />
card {l,r} (x, p, A) =<br />
{<br />
cardl (x, p, A), wenn π l berechnet wird<br />
card r (x, p, A),<br />
wenn π r berechnet wird<br />
Um nach der inversen Produktformel zum Beispiel den Propagation-Koeffizienten der<br />
ausgehenden Kanten eines Map Pairs (a, b) für zwei Modelle A <strong>und</strong> B mit a ∈ A <strong>und</strong><br />
b ∈ B zu berechnen, wird die Anzahl der ausgehenden Kanten des Knotens a in Modell<br />
A mit der Anzahl der ausgehenden Kanten des Knotens b in Modell B multipliziert <strong>und</strong><br />
das Ergebnis invertiert. Voraussetzung ist wie bei der Konstruktion des PCG, dass es<br />
überhaupt gleich beschriftete Kanten gibt, die von a <strong>und</strong> b ausgehen. Ansonsten wird<br />
als Wert für den Propagation-Koeffizienten 0 zurückgegeben, der darauf hinweist, dass<br />
es im PCG der Modelle A <strong>und</strong> B keine ausgehende Kante des Map Pairs (a, b) gibt.<br />
Abbildung 4.3 zeigt den zu A <strong>und</strong> B gehörenden SPG. Für die Berechnung des<br />
Propagation-Koeffizienten einer Kante ((x 1 , y 1 ), p, (x 2 , y 2 )) wurde hier die inverse Pro-<br />
21
duktformel verwendet. Der Propagation-Koeffizient ω((a 4 , b 2 ), (a 2 , b 3 )) = 0.5 der Kante<br />
zwischen (a 4 , b 2 ) <strong>und</strong> (a 2 , b 3 ) kommt demnach dadurch zustande, dass es vom Knoten<br />
(a 4 , b 2 ) genau zwei ausgehende l 2 -Kanten gibt, sodass sich der Wert als ω((a 4 , b 2 ), (a 2 , b 3 )) =<br />
1<br />
2<br />
= 0.5 ergibt.<br />
Der Propagation-Koeffizient ω((a 2 , b 2 ), (a 1 , b 1 )) = 1.0 ergibt sich deshalb, weil nur<br />
eine einzige mit l 1 beschriftete Kante aus a 2 b 2 ausgeht bzw. in a 1 b 1 eingeht.<br />
Die zweite hier vorgestellte Möglichkeit für die Berechnung der Propagation-Koeffizienten<br />
ist die Verwendung der inversen Durchschnittsfunktion. Diese berechnet π wie folgt:<br />
⎧<br />
⎨<br />
2<br />
card<br />
π {l,r} (〈x, p, A〉, 〈y, q, B〉) = {l,r} (x,p,A)+card {l,r} (y,q,B) , wenn p = q<br />
⎩0, wenn p ≠ q<br />
Hier wird also statt einer Produktbildung der Kardinalitäten wie in der inversen Produktformel<br />
auf die Durchschnittsbildung zurückgegriffen. Der Propagation-Koeffizient<br />
ω((a 4 , b 2 ), (a 2 , b 3 )) des Graphen aus Abbildung 4.3 würde in diesem Fall den Wert 0.6<br />
ergeben, weil es in Modell A zwei ausgehende l 2 -Kanten von a 4 sowie eine von b 2 gibt,<br />
2<br />
sodass sich der Wert als<br />
2+1 = 2 3<br />
= 0.6 ergibt.<br />
Die Autoren bescheinigen dabei der inversen Durchschnittsfunktion eine bessere Performanz<br />
<strong>und</strong> verweisen diesbezüglich auf von ihnen durchgeführte empirische Studien,<br />
die das belegen.<br />
4.3. Iteratives Berechnung der Ähnlichkeiten<br />
Nachdem die Modelle nun in einen Similarity Propagation Graph überführt vorliegen,<br />
beginnt der eigentliche Ablauf des Algorithmus.<br />
Definition 4.3 Seien A <strong>und</strong> B zwei Modelle. Dann bezeichnet σ(x, y) ≥ 0 die Ähnlichkeit<br />
zweier Knoten x ∈ A <strong>und</strong> y ∈ B, definiert als totale Funktion über A × B.<br />
σ wird dabei als Mapping bezeichnet <strong>und</strong> seine Werte iterativ berechnet. σ i gibt das<br />
Mapping zwischen A <strong>und</strong> B nach der i-ten Iteration an, σ 0 die anfängliche Ähnlichkeit<br />
(oder Anfangsähnlichkeit) zwischen den Knoten von A <strong>und</strong> B. Diese Anfangsähnlichkeit<br />
kann dabei zum Beispiel mit Hilfe von Zeichenketten-Vergleichen der Knoten-Label<br />
berechnet werden.<br />
Ist zu Beginn keine Ähnlichkeit zwischen Knoten verfügbar (wie es im Beispiel in<br />
Kapitel 4.2 der Fall ist), kann hier ein Wert von σ 0 (x, y) = 1.0 für alle (x, y) ∈ A × B<br />
angenommen werden. Wie der Ablauf des Algorithmus durch die Wahl der Anfangsähnlichkeiten<br />
beeinflusst wird, wird in Kapitel 7 genauer untersucht. Zur Veranschaulichung<br />
des Verfahrens soll hier die Vereinfachung mit gleichen Werten 1.0 reichen.<br />
Im i-ten Iterationsschritt des Similarity Flooding wird der Wert von σ i+1 eines Map<br />
Pairs (x, y) aus dem alten Wert σ i von (x, y), den σ-Werten der Nachbarknoten <strong>und</strong> den<br />
Propagation-Koeffizienten der Kanten, die von den Nachbarknoten zu (x, y) bzw. von<br />
(x, y) zu den Nachbarknoten führen, neu berechnet. Formell lässt sich diese Berechnung<br />
22
durch die Formel<br />
darstellen, wobei gilt:<br />
ϕ(σ i (x, y)) =<br />
+<br />
σ i+1 (x, y) = σ i (x, y) + ϕ(σ i )(x, y)<br />
∑<br />
(a u,p,x)∈A,(b u,p,y)∈B<br />
∑<br />
(x,p,a v)∈A,(y,p,b v)∈B<br />
σ i (a u , b u ) · ω((a u , b u ), (x, y))<br />
σ i (a v , b b ) · ω((a v , b v ), (x, y))<br />
Aufgr<strong>und</strong> der Berechnung des neuen σ-Wertes als Summe würden die Ähnlichkeitswerte<br />
im Verlauf der Iterationen monoton wachsen, weshalb eine Normalisierung der<br />
σ-Werte nach jeder Iteration nötig ist. Das bedeutet, dass alle Werte am Ende einer<br />
Iteration durch den maximalen σ-Wert, der in der Iteration berechnet wurde, dividiert<br />
werden. Anschließend hat man somit nur Ähnlichkeitswerte im Bereich von 0 bis 1 für<br />
die nächste Iteration.<br />
Pseudocode 4.3 stellt die Funktion berechneÄhnlichkeiten dar, die die iterativen Berechnungen<br />
der σ-Werte für jeden Knoten eines gegebenen SPG durchführt. Dabei führt<br />
die normalisieren-Funktion die oben genannte Normalisierung durch. Die Komplexität<br />
der Methode ist dabei O(n Knoten ∗ n Kanten ), wobei n Knoten <strong>und</strong> n Kanten die Anzahl der<br />
Knoten bzw. Kanten im SPG sind.<br />
Pseudocode 4.3: berechneÄhnlichkeiten(SPG spg)<br />
for each Knoten (a 1 , b 1 ) ∈ spg do<br />
σ neu (a 1 , b 1 ) ← σ(a 1 , b 1 )<br />
for each Kante ((a 1 , b 1 ), l, (a 2 , b 2 )) ∈ spg do // ausgehende Kanten<br />
σ neu (a 1 , b 1 ) = σ neu (a 1 , b 1 ) + σ(a 2 , b 2 ) · ω((a 1 , b 1 ), (a 2 , b 2 ));<br />
for each Kante ((a 2 , b 2 ), l, (a 1 , b 1 )) ∈ spg do // eingehende Kanten<br />
σ neu (a 1 , b 1 ) = σ neu (a 1 , b 1 ) + σ(a 2 , b 2 ) · ω((a 2 , b 2 ), (a 1 , b 1 ));<br />
for each Knoten (a 1 , b 1 ) ∈ spg do<br />
σ(a 1 , b 1 ) = normalisieren(σ neu (a 1 , b 1 ))<br />
Tabelle 4.2 stellt den Verlauf der normalisierten Ähnlichkeitswerte des SPG aus Abbildung<br />
4.3 über mehrere Iterationen dar. Als Anfangsähnlichkeiten wurde hier σ 0 = 1.0 für<br />
alle Map Pairs angenommen. Gemäß der Formel berechnet sich zum Beispiel der Wert für<br />
σ 1 (a 1 , b 3 ) als σ 1 (a 1 , b 3 ) = σ 0 (a 1 , b 3 )+σ 0 (a 1 , b 3 )·ω((a 1 , b 3 ), (a 2 , b 1 )) = 1.0+1.0·1.0 = 2.0,<br />
aufgr<strong>und</strong> der Normalisierung mit dem maximal erreichten Wert in der Iteration (in diesem<br />
Fall der Wert 3.0) ergibt sich daraus σ 0 (a 1 , b 3 ) = 2 3 = 0.6.<br />
Schon nach den dargestellen fünf Iterationen kann man erkennen, dass der Ähnlichkeitswert<br />
für (a 1 , b 1 ) konstant bei 1.0 bleibt, die Werte für (a 2 , b 2 ) <strong>und</strong> (a 3 , b 4 ) gegen 0.71<br />
konvergieren <strong>und</strong> die Ähnlichkeiten der restlichen Map Pairs immer weiter gegen 0 konvergieren.<br />
Würde man noch weitere Iterationen durchführen, könnte man beobachten,<br />
dass die Ähnlichkeitswerte für (a 1 , b 3 ), (a 2 , b 1 ), (a 2 , b 3 ), (a 3 , b 3 ) <strong>und</strong> (a 4 , b 2 ) tatsächlich<br />
23
Map Pair<br />
σ i<br />
0 1 2 3 4 5<br />
(a 1 , b 1 ) 1.0 1.0 1.0 1.0 1.0 1.0<br />
(a 1 , b 3 ) 1.0 0.6 0.57 0.47 0.39 0.32<br />
(a 2 , b 1 ) 1.0 0.6 0.57 0.47 0.39 0.32<br />
(a 2 , b 2 ) 1.0 0.6 0.71 0.71 0.71 0.71<br />
(a 2 , b 3 ) 1.0 0.5 0.43 0.35 0.29 0.24<br />
(a 3 , b 3 ) 1.0 0.5 0.43 0.35 0.29 0.24<br />
(a 3 , b 4 ) 1.0 0.6 0.71 0.71 0.71 0.71<br />
(a 4 , b 2 ) 1.0 1.0 0.86 0.71 0.59 0.48<br />
Tabelle 4.2.: Ähnlichkeitswerte der Map Pairs über mehrere Iterationen<br />
Bezeichner<br />
Fixpunkt-Formel<br />
Basis σ i+1 = normalize(σ i + ϕ(σ i ))<br />
A σ i+1 = normalize(σ 0 + ϕ(σ i ))<br />
B σ i+1 = normalize(ϕ(σ 0 + σ i ))<br />
C σ i+1 = normalize(σ 0 + σ i + ϕ(σ 0 + σ i ))<br />
Tabelle 4.3.: Verschiedene Berechnungsmöglichkeiten für Fixpunkte mit ϕ wie oben (vgl.<br />
Tabelle 3 in [MGMR01])<br />
immer stärker gegen 0 konvergieren. Was das bezüglich der Aussagekraft der Ergebnisse<br />
des Similarity Flooding Algorithmus zu bedeuten hat, wird im weiteren Verlauf dieser<br />
Arbeit noch näher beleuchtet.<br />
Als Bedingung für das Abbrechen der Iterationen wird die Änderung der Ähnlichkeitswerte<br />
im Interationsschritt n im Verhältnis zum Iterationsschritt n − 1 berechnet.<br />
Dazu kann zum Beispiel die Euklidische Länge des Vektors △(σ n , σ n−1 ) betrachtet werden.<br />
Wird diese kleiner als ein vorgegebener Wert ɛ für ein n > 0, kann der Algorithmus<br />
beendet werden. Man spricht in diesem Fall davon, dass sich ein Fixpunkt eingestellt<br />
hat.<br />
Der Begriff des Fixpunktes wird von den Autoren in [MGMR01] sowie auch im Rahmen<br />
dieser Arbeit immer wieder aufgegriffen. In jedem Schritt des Algorithmus werden<br />
neue Ähnlichkeitswerte σ aus den bisher errechneten Werten berechnet. Anschließend<br />
wird überprüft, ob sich ein Fixpunkt eingestellt hat. Auch wenn die Berechnung der<br />
neuen Werte als solche nicht dasselbe ist wie die Überprüfung eines Fixpunktes, wird<br />
für die Berechnungsformel σ für die Ähnlichkeitswerte der Knoten trotzdem analog der<br />
Begriff Fixpunkt-Formel verwendet.<br />
Formal lässt sich diese Fixpunkt-Formel als σ i+1 = normalize(σ i +ϕ(σ i )) beschreiben,<br />
wobei normalize(x) den Wert von x wie oben beschrieben normalisiert. Ein Fixpunkt<br />
wird dabei erreicht, wenn △(σ i+1 , σ i ) < ɛ gilt.<br />
Neben dieser Berechnungsformel für den Fixpunkt sind noch andere denkbar. Die<br />
Entwickler des Similarity Flooding Algorithmus stellen drei weitere Formeln vor, die in<br />
24
Tabelle 4.3 dargestellt sind. Während die Basis-Formel, die der Formel aus dem vorherigen<br />
Absatz entspricht, lediglich die σ-Werte aus dem vorangegangenen Iterationsschritt<br />
betrachtet, schließen die Formeln A-C auch die Anfangswerte für σ in die Berechnung<br />
mit ein. Die Autoren berichten, dass in empirischen Untersuchungen die Formel C für die<br />
schnellste Konvergenz gesorgt hat. Für die folgenden Beispiele soll stets die Basis-Formel<br />
als Berechnungsgr<strong>und</strong>lage für die Fixpunkte dienen.<br />
Unter Umständen kann es passieren, dass der Algorithmus nicht konvergiert, d.h. die<br />
Bedingung △(σ n , σ n−1 ) < ɛ nicht erfüllt wird. Für diesen Fall wird eine maximale Anzahl<br />
von Iterationen – also ein maximaler Wert für n – festgelegt, nach dem die Berechnungen<br />
mit dem Algorithmus auf jeden Fall abgebrochen werden.<br />
Pseudocode 4.4: Ablauf des Algorithmus für Modelle A <strong>und</strong> B<br />
pcg ← erzeugeP CG(A, B);<br />
spg ← erzeugeSP G(pcg);<br />
berechneAnfangsähnlichkeiten;<br />
repeat<br />
berechneÄhnlichkeiten(spg);<br />
until Abbruchbedingung erfüllt;<br />
// berechnet die anfänglichen Werte für σ<br />
Pseudocode 4.4 zeigt den Gesamtablauf des Algorithmus unter Verwendung der zuvor<br />
vorgestellten Funktionen. Die Anfangsähnlichkeiten für die Knoten werden dabei mit<br />
einer Funktion berechneAnfangsähnlichkeiten berechnet, die unterschiedlichste Kriterien<br />
wie z.B. die erwähnten Zeichenketten-Vergleiche berücksichtigen kann.<br />
4.4. Umgang mit den Ergebnissen<br />
Nach Abschluss der Berechnungen liefert der Similarity Flooding Algorithmus zunächst<br />
das sogenannte Multimapping, d.h. eine Liste von Map Pairs mit den dazugehörigen<br />
Ähnlichkeitswerten. Diese Liste enthält zwar alle vorgeschlagenen potenziellen Match-<br />
Kandidaten, sie kann aber sehr schnell sehr groß werden <strong>und</strong> somit für menschliche<br />
Benutzer sehr schwer zu handhaben sein.<br />
Dieses Problem wird bereits an kleinen Datenmengen deutlich. Hat man etwa vier<br />
verschiedene Map Pairs im Multimapping, können daraus bereits 2 4 = 16 verschiedene<br />
Teilmengen gebildet werden, welche alle potenzielle Ergebnisse darstellen, die dem<br />
Benutzer präsentiert werden könnten.<br />
Die Idee besteht nun darin, durch geeignete Filter die Anzahl der Ergebnisse, die<br />
der Algorithmus zurückliefert, so weit einzuschränken, dass der Benutzer eine für ihn<br />
überschaubare Liste mit Match-Kandidaten geliefert bekommt.<br />
Die Auswahl solcher Filter ist schwierig, da es keine allgemein gültigen Kriterien gibt,<br />
nach denen man bestimmte Ergebnisse unter allen Umständen aus der Ergebnisliste<br />
herausfiltern kann. Für dieses Problem werden in den folgenden Unterkapiteln Vorschläge<br />
für mögliche Filter diskutiert <strong>und</strong> empirische Bef<strong>und</strong>e dazu erläutert.<br />
25
4.4.1. Constraints<br />
Eine häufige Methode, um die Größe eines Multimappings zu reduzieren, ist die Berücksichtigung<br />
von anwendungsspezifischen Constraints. Die Autoren stellen in diesem<br />
Zusammenhang zwei Arten von Constraints vor: Typ-Constraints <strong>und</strong> Kardinalitäts-<br />
Constraints.<br />
Typ-Constraints können dann hilfreich sein, wenn man weiß, welche Typen von Daten<br />
in der Ergebnismenge relevant sind <strong>und</strong> welche nicht. Zum Beispiel könnte man in einem<br />
relationalen Schema, das Tabellen, Spalten, Schlüssel <strong>und</strong> Datentypen enthält, Matches<br />
zwischen Schlüsseln <strong>und</strong> Datentypen ignorieren, wenn man nur an Tabellen <strong>und</strong> Spalten<br />
interessiert ist.<br />
Vieles, was durch Typ-Constraints in der Ergebnismenge erreicht werden kann, kann<br />
auch bereits durch den Aufbau bzw. die Struktur der verwendeten Modelle erreicht<br />
werden. Transformiert man etwa ein relationales Schema in ein Modell, in dem es für<br />
Schlüssel, Datentypen, Tabellen <strong>und</strong> Spalten jeweils Knoten gibt, die durch eindeutig<br />
beschriftete Kanten – das heißt, etwa „has_keyvalue“ zwischen Tabellen <strong>und</strong> Schlüsseln,<br />
„has_datatype“ zwischen Spalten <strong>und</strong> Datentypen – verb<strong>und</strong>en sind, kann es im<br />
Ergebnis keine Vorschläge für Matchings zwischen Schlüsseln <strong>und</strong> Datentypen geben. In<br />
diesem Fall wären Typ-Constraints überflüssig, im Falle anderer Transformationen aber<br />
durchaus nützlich.<br />
Weiß man von vornherein, dass etwa bei zwei Tabellen A <strong>und</strong> B im Ergebnis die<br />
Tabelle A lediglich durch Werte aus der Tabelle B angereichert werden soll, kann man<br />
Kardinalitäts-Constraints verwenden. In dem Fall könnte man etwa festlegen, dass die<br />
Ergebnismenge die Bedingung erfüllen muss, dass jedem Element aus Tabelle A – sofern<br />
überhaupt – nur genau ein Element aus Tabelle B zugeordnet werden darf, während<br />
jedem Element aus Tabelle B beliebig viele Elemente aus Tabelle A zugeordnet werden<br />
können.<br />
Durch Constraints allein kann die Ergebnismenge jedoch in den seltensten Fällen weit<br />
genug eingeschränkt werden, um eindeutige Match-Kandidaten zu bekommen. Selbst bei<br />
sehr strengen Kardinalitäts-Constraint (z.B. einem 1-zu-1-Mapping) werden auf diese<br />
Weise noch mehr als ein Ergebniskandidat geliefert, sodass weitere Methoden benötigt<br />
werden, um aus den verbleibenden Alternativen die „besten“ auszuwählen.<br />
4.4.2. Auswahl von 1-zu-1-Mappings<br />
Um das Problem der geeigneten Auswahl aus einer Menge von Alternativen zu lösen,<br />
macht man sich die enge Verwandtschaft des Problems zu bekannten Matching-<br />
Problemen in bipartiten Graphen zunutze. Ein Matching wird dort als ein Mapping<br />
definiert, bei dem keine zwei Kanten eingehende Kanten desselben Knotens sind (es<br />
handelt sich somit um ein 1-zu-1-Mapping). Ein bipartiter Graph ist eine Einteilung<br />
einer Menge von Knoten in zwei Teilmengen derart, dass es nur Kanten zwischen den<br />
beiden Teilmengen, nicht aber innerhalb der Teilmengen, geben darf. Ein Mapping kann<br />
dann als ein ungerichteter, gewichteter, bipartiter Graph betrachtet werden.<br />
26
Abbildung 4.4.: Bipartiter Graph (links) <strong>und</strong> mögliches Matching (rechts)<br />
Abbildung 4.4 stellt zum einen den bipartiten Graphen zu den Beispielen aus Kapitel<br />
4.2 dar, der sich aus den Knoten des SPG bzw. PCG ergibt. Die eingetragenen Kantengewichte<br />
entsprechen den Gewichten nach der 5. Iteration des Algorithmus, die auch in<br />
Tabelle 4.2 zu finden sind. Daneben ist ein mögliches Matching dargestellt, das man aus<br />
dem Graphen ermitteln könnte.<br />
Im Folgenden werden einige in der Theorie bekannte Matching-Verfahren sowie Auswahlkriterien<br />
vorgestellt, die bei der Filterung der Ergebnisse beim Similarity Flooding<br />
Algorithmus Verwendung finden können.<br />
Das Stable-Marriage-Verfahren<br />
Für die Auswahl aus dem Multimapping kann das Stable-Marriage-Verfahren herangezogen<br />
werden, das in [GS62] beschrieben wird. Dabei geht es darum, zwischen einer Menge<br />
von n Frauen <strong>und</strong> n Männern eine „Stable Marriage“ (also eine stabile Hochzeit) zu<br />
ermöglichen. Dazu hat jede der n Frauen <strong>und</strong> jeder der n Männer eine Liste mit den<br />
Personen des anderen Geschlechts in der Reihenfolge, in der sie von der jeweiligen Person<br />
für eine Hochzeit präferiert werden. Gesucht ist die beste Kombination der Männer <strong>und</strong><br />
Frauen.<br />
Diese Stable Marriage soll ein vollständiges Matching der Männer <strong>und</strong> Frauen (d.h.<br />
jeder Mann <strong>und</strong> jede Frau hat einen Partner des anderen Geschlechts zugewiesen bekommen)<br />
mit der Eigenschaft sein, dass es keine Paare (x, y) <strong>und</strong> (x ′ , y ′ ) gibt, bei denen x<br />
y ′ gegenüber y <strong>und</strong> y ′ x gegenüber x ′ bevorzugt. Eine solche Situation würde als instabil<br />
bezeichnet werden.<br />
Algorithmisch lässt sich das Stable Marriage wie folgt ermitteln: Man bildet zwei<br />
Mengen M (für die Männer) <strong>und</strong> W (für die Frauen) <strong>und</strong> ordnet jedem m ∈ M <strong>und</strong><br />
jedem w ∈ W die Liste mit Präferenzen (proposal) der anderen Menge zu. Der eigentliche<br />
Algorithmus läuft dann wie nachfolgend in Pseudocode 4.5 dargestellt ab.<br />
27
m 1 : w 2 (0.8), w 3 (0.7), w 1 (0.3), w 4 (0.1)<br />
m 2 : w 2 (0.9), w 3 (0.3), w 1 (0.2), w 4 (0.2)<br />
m 3 : w 1 (0.7), w 4 (0.6), w 2 (0.1), w 3 (0)<br />
m 4 : w 4 (0.7), w 2 (0.5), w 3 (0.4), w 1 (0.3)<br />
w 1 : m 3 (0.7), m 1 (0.3), m 4 (0.3), m 2 (0.2)<br />
w 2 : m 2 (0.9), m 1 (0.8), m 4 (0.5), m 3 (0.1)<br />
w 3 : m 1 (0.7), m 4 (0.4), m 2 (0.3), m 3 (0)<br />
w 4 : m 4 (0.7), m 3 (0.6), m 2 (0.2), m 1 (0.1)<br />
Schritt 0: free = {m 1 , m 2 , m 3 , m 4 , w 1 , w 2 , w 3 , w 4 }, married = ∅<br />
Schritt 1: free = {m 2 , m 3 , m 4 , w 1 , w 3 , w 4 }, married = {(m 1 , w 2 )}<br />
Schritt 2: free = {m 1 , m 3 , m 4 , w 1 , w 3 , w 4 }, married = {(m 2 , w 2 )}<br />
Schritt 3: free = {m 3 , m 4 , w 1 , w 4 }, married = {(m 2 , w 2 ), (m 1 , w 3 )}<br />
Schritt 4: free = {m 4 , w 4 }, married = {(m 2 , w 2 ), (m 1 , w 3 ), (m 3 , w 1 )}<br />
Schritt 5: free = ∅, married = {(m 2 , w 2 ), (m 1 , w 3 ), (m 3 , w 1 ), (m 4 , w 4 )}<br />
⇒ M 1 = {(m 2 , w 2 ), (m 1 , w 3 ), (m 3 , w 1 ), (m 4 , w 4 )}<br />
Abbildung 4.5.: Beispielhafter Ablauf des Stable Marriage Algorithmus<br />
Pseudocode 4.5: Ermittlung einer Stable Marriage für M <strong>und</strong> W<br />
Füge alle m ∈ M <strong>und</strong> w ∈ W der Menge free hinzu;<br />
while es gibt ein m ∈ M mit m ∈ free <strong>und</strong> proposal(m) ≠ ∅<br />
w ← erstes noch nicht betrachtetes Element aus proposal(m);<br />
if w ∈ free<br />
füge (m, w) der Menge married hinzu and entferne m <strong>und</strong> w aus free;<br />
else if ∃(m ′ , w) ∈ married<br />
if w bevorzugt m gegenüber m ′<br />
füge (m, w) der Menge married hinzu;<br />
entferne (m ′ , w) aus der Menge married;<br />
füge m ′ der Menge free hinzu;<br />
else<br />
(m ′ , w) bleibt in married;<br />
Beispielhaft ist der Ablauf für zwei Mengen M = {m 1 , m 2 , m 3 , m 4 } <strong>und</strong> W = {w 1 , w 2 ,<br />
w 3 , w 4 } in Abbildung 4.5 dargestellt. Die Listen proposal für die einzelnen Elemente sind<br />
oben dargestellt, wobei die Zahlen in Klammern angeben, wie stark die Präferenz zu dem<br />
jeweiligen Element der anderen Menge ist. Bei gleichen Präferenzen wurden die Elemente<br />
der Liste alphabetisch sortiert.<br />
Betrachtet man die Menge married, stellt man fest, dass die darin enthaltenen Paare<br />
tatsächlich die Bedingungen einer Stable Marriage erfüllen. Das Matching, das auf diese<br />
Weise erreicht wurde, wird im Beispiel <strong>und</strong> im Folgenden mit M 1 bezeichnet. Der Algorithmus<br />
liefert dabei immer nur eine Stable Marriage, auch wenn bei anderen Mengen<br />
durchaus mehrere verschiedene denkbar sind.<br />
Das Stable-Marriage-Problem lässt sich ohne Probleme auf die Multimappings übertragen<br />
(näheres zu Multimappings siehe Kapitel 4.4.3).<br />
28
Das Zuordnungsproblem<br />
Beim Zuordnungsproblem wird versucht, ein Matching M i in einem gewichteten, bipartiten<br />
Graphen M zu finden, das das totale Gewicht ∑ (x,y)∈M i<br />
σ(x, y) maximiert. Verglichen<br />
mit dem Stable-Marriage-Problem bedeutet das, dass beim Zuordnungsproblem<br />
das Matching gesucht wird, bei dem die Gesamtzufriedenheit der Männer <strong>und</strong> Frauen<br />
am größten ist, was nicht heißen muss, dass ein solches Matching stabil im Sinne einer<br />
Stable Marriage wäre.<br />
Das Matching bzw. die Stable Marriage M 1 , die sich im Beispiel in Abbildung 4.5 ergibt,<br />
ist auch im Sinne des Zuordnungsproblems optimal. Hierbei ist ∑ (x,y)∈M 1<br />
σ(x, y) =<br />
0.9 + 0.7 + 0.7 + 0.7 = 3.0, was dem maximalen Wert entspricht, den eine Zuordnung<br />
für die Mengen liefern kann. Zum Vergleich wäre etwa eine Zuordnung M 2 =<br />
{(m 1 , w 1 ), (m 2 , w 2 ), (m 3 , w 3 ), (m 4 , w 4 )} mit ∑ (x,y)∈M 2<br />
σ(x, y) = 0.3 + 0.9 + 0 + 0.7 = 1.9<br />
im Sinne des Zuordnungsproblems nicht optimal.<br />
Ein Algorithmus, der das Zuordnungsproblem löst, ist die Hungarian method, die in<br />
[Kuh55] im Jahr 1955 vorgestellt wurde. Dabei wird eine Matrix erzeugt, in der die<br />
zuzuordnenden Paare mit den jeweiligen Gewichten eingetragen werden. Anschließend<br />
werden in 4 Schritten bestimmte Zeilen- <strong>und</strong> Spaltenoperationen ausgeführt, bis in der<br />
Matrix in jeder Zeile <strong>und</strong> Spalte mindestens eine 0 steht. Daraus lässt sich dann die<br />
optimale Zuordnung ablesen. Bei dem Verfahren wird zwar eigentlich eine minimale<br />
Lösung (also eine Zuordnung, bei der die Summe der Gewichte minimal ist) gesucht,<br />
es lässt sich aber ohne Probleme auch für maximale Lösungen anwenden, sodass das<br />
Ergebnis, das am Beispiel in Abbildung 4.5 errechnet wurde, auch mit der Hungarian<br />
method ermittelt werden könnte.<br />
Maximale, Maximum- <strong>und</strong> perfekte Matchings<br />
Unter einem maximalen Matching versteht man ein Matching, das in keinem anderen<br />
Matching enthalten ist. Ein Maximum-Matching ist ein Matching mit maximaler Kardinalität,<br />
d.h. bezogen auf das Hochzeitsbeispiel mit der größten Anzahl verheirateter<br />
Paare. Ein perfektes (oder vollständiges) Matching ist das Matching, bei dem jeder Mann<br />
<strong>und</strong> jede Frau verheiratet wäre.<br />
Das Matching M 1 aus dem Beispiel in Abbildung 4.5 ist maximal, da es in keinem<br />
anderen möglichen Matching, das sich aus den beiden Mengen bilden lässt, enthalten<br />
sein kann. Es ist ein Maximum-Mapping, da es die maximal mögliche Zahl von 4 Paaren<br />
enthält, <strong>und</strong> perfekt, weil jedes Element aus M <strong>und</strong> jedes Element aus W zugeordnet<br />
wurden.<br />
Ein Matching M 3 = {(m 1 , w 3 ), (m 2 , w 2 ), (m 3 , w 1 )} wäre dagegen weder maximal noch<br />
ein Maximum-Matching oder perfekt, weil es in M 1 enthalten ist, nicht die maximale<br />
Anzahl möglicher Paare enthält <strong>und</strong> nicht alle Elemente der Mengen zuordnet.<br />
29
4.4.3. Auswahl von n-zu-m-Mappings<br />
Polygamie<br />
Bei den bisher vorgestellten Metriken handelt es sich nur um solche, die ein Element<br />
der einen Menge auf maximal ein Element der anderen Menge matchen. Das bezeichnet<br />
man als Monogamie. Nun kann es aber sein, dass auch Mappings erwünscht sind, die<br />
mehrere Elemente der einen Menge auf mehrere der anderen matchen können. In diesem<br />
Fall spricht man von Polygamie.<br />
Die polygame Variante des perfekten Matchings stellt das Outer Match dar. Dabei<br />
handelt es sich um ein minimales Matching, bei dem jedes Element von jedem Modell<br />
mindestens einen Partner hat.<br />
Bei Polygamie könnte zum ∑ Beispiel eine Teilmenge M i aus dem Multimapping gesucht<br />
werden, die die Funktion<br />
‖(x,)‖·‖(,y)‖<br />
maximiert, wobei ‖(x, ) <strong>und</strong> ‖(, y)‖ die Anzahl<br />
der Partner von einer Frau x <strong>und</strong> einem Mann y in M i darstellen.<br />
M i<br />
σ(x,y)<br />
Absolute <strong>und</strong> relative Ähnlichkeiten<br />
Absolute Ähnlichkeit liegt dann vor, wenn für ein Map Pair nur genau ein Ähnlichkeitswert<br />
zurückgegeben wird, wie es im Similarity Flooding Algorithmus der Fall ist. Sie ist<br />
symmetrisch, d.h. x ist genauso ähnlich zu y wie y zu x. Im Falle der Hochzeiten heißt<br />
das, dass Partner sich genau gleich mögen.<br />
Betrachtet man die Möglichkeit, dass die Ähnlichkeiten nicht symmetrisch sein müssen,<br />
es also durchaus vorkommen kann, dass in einem Hochzeitspaar der Mann die Frau<br />
lieber mag als umgekehrt, kommt man zu relativen Ähnlichkeiten. Relative Ähnlichkeiten<br />
sind asymmetrisch <strong>und</strong> werden berechnet, indem man das Verhältnis der absoluten<br />
Ähnlichkeitswerte der besten Match-Kandidaten berechnet.<br />
Verwendet man statt der absoluten Ähnlichkeitswerte relative, lässt sich das Multimapping<br />
als ein gerichteter, gewichteter, bipartiter Graph auffassen.<br />
Edit-Operationen<br />
Für einige Probleme bietet es sich an, die Zahl der Edit-Operationen, mit denen ein Teilgraph<br />
in einen anderen überführt werden kann, in die Auswahl-Metrik mit einzubeziehen.<br />
Edit-Operationen sind elementare Einfüge-, Lösch- oder Ersetzungs-Operationen. Durch<br />
Sequenzen solcher Operationen lassen sich zum Beispiel Wörter oder Graphen ineinander<br />
überführen.<br />
Ähnlichkeits-Thresholds<br />
Zur Auswahl geeigneter Wertpaare aus einer Menge von Ergebnispaaren (Multimapping)<br />
können als weiteres Kriterium Ähnlichkeits-Thresholds (Schwellwerte) verwendet<br />
werden. Legt man etwa einen Threshold von t abs = 0.5 fest, würden aus dem Multimapping<br />
nur noch die Map Pairs herausgefiltert werden, deren Ähnlichkeitswert größer bzw.<br />
größer oder gleich 0.5 ist. Ein solcher Threshold kann sowohl für absolute als auch für<br />
relative Ähnlichkeiten verwendet werden.<br />
30
5. Vergleich mit anderen Verfahren<br />
Nachdem in Kapitel 4 der Similarity Flooding Algorithmus vorgestellt wurde, soll dieses<br />
Kapitel Vergleiche mit <strong>und</strong> zwischen anderen Graph Matching Verfahren anstellen. Dazu<br />
werden hier beispielhaft die drei in der Literatur bekanntesten Verfahren vorgestellt <strong>und</strong><br />
deren Besonderheiten erläutert.<br />
5.1. Cupid<br />
Mit Cupid stellen die Autoren von [MBR01] einen Ansatz vor, in dem eine Reihe anderer<br />
Ansätze mit einfließen. Die Idee dahinter ist, dass nach eigenen Angaben ein einzelner<br />
Ansatz keine ausreichende Lösung für das Problem des Auffinden eines Matchings liefert.<br />
Cupid geht beim Matching dabei in drei Phasen vor. In der ersten Phase erfolgt ein<br />
linguistisches Matching. Hierbei werden mehrere Schritte durchgeführt, um schließlich<br />
Ähnlichkeitswerte lsim(m 1 , m 2 ) für alle Elemente m 1 <strong>und</strong> m 2 der Schemata zu bekommen.<br />
Dazu gehört eine Normalisierung der Namen – durch Tokanization, Erweitern von<br />
Abkürzungen, Elimination von Artikel u.ä. sowie Tagging von Elementen, die zu einem<br />
gemeinsamen Konzept, wie etwa zum Oberbegriff „Geld“, gehören –, Einteilen von<br />
Elementen in Kategorien anhand ihrer Datentypen <strong>und</strong> Tags sowie Berechnung von Namensähnlichkeiten.<br />
In dieser ersten Phase, die im Wesentlichen mit der Vorverarbeitungsphase des Similarity<br />
Flooding verglichen werden kann, zeigen sich erste Unterschiede der beiden<br />
Verfahren. Während beim Similarity Flooding die Anfangsähnlichkeiten aller Map Pairs<br />
berechnet werden, die aus den beiden Eingabemodellen gebildet werden können, berechnet<br />
Cupid nur Ähnlichkeiten zwischen Elementen, die in die gleiche Kategorie fallen.<br />
Elementen aus unterschiedlichen Kategorien wird – unabhängig davon, wie ähnlich die<br />
Namen sind – ein Ähnlichkeitswert von 0 zugewiesen.<br />
In der zweiten Phase von Cupid erfolgt das strukturelle Matching. Hierbei wird zunächst<br />
davon ausgegangen, dass es sich bei den Schemata um hierarchische Schemata<br />
handelt, die sich mithilfe zweier Bäume – einer pro Schema – darstellen lassen. Im Tree-<br />
Match-Algorithmus wird schrittweise die Ähnlichkeit zwischen den Paaren von Elementen,<br />
die aus den beiden Schemata gebildet wurden, berechnet. Dabei gibt es keinerlei Beschränkungen<br />
mehr auf Elemente, die derselben Kategorie angehören. Es werden schlicht<br />
alle Knoten der beiden Bäume paarweise kombiniert <strong>und</strong> die Ähnlichkeiten berechnet.<br />
Die Berechnung selbst läuft dabei folgendermaßen ab: Gegeben seinen zwei Bäume S<br />
<strong>und</strong> T , die hierarchische Schemata repräsentieren. Für alle Knotenpaare (s, t) mit s ∈ S,<br />
t ∈ T <strong>und</strong> s, t Blätter wird basierend auf der Kompatibilität ihrer Datentypen eine<br />
Anfangsähnlichkeit ssim(s, t) als Wert im Intervall [0, 0.5] berechnet, wobei ein Wert<br />
31
von 0.5 eine maximale Kompatibilität ausdrückt. In einer Schleife wird anschließend für<br />
alle Paare von Elementen (s, t) mit s ∈ S, t ∈ T die Ähnlichkeit ssim(s, t) berechnet,<br />
wobei hier zwei Fälle unterschieden werden:<br />
1. Sind s <strong>und</strong> t Blätter, ist der Wert für ssim gleich dem oben berechneten Anfangswert.<br />
2. Ist s oder t kein Blatt, sondern ein interner Knoten, werden für die Berechnung<br />
von ssim die Mengen von Blättern leaves(s) bzw. leaves(t) betrachtet, die zu den<br />
Teilbäumen gehören, deren Wurzel s bzw. t ist. ssim berechnet sich dann wie folgt:<br />
ssim(s, t) =<br />
slink out ∪ slink in<br />
|leaves(s) ∪ leaves(t)|<br />
Dabei gilt slink out = {x|x ∈ leaves(s) ∧ ∃y ∈ leaves(t), stronglink(x, y)} <strong>und</strong><br />
slink in = {x|x ∈ leaves(t) ∧ ∃y ∈ leaves(s), stronglink(y, x)}. stronglink(x, y)<br />
bedeutet, dass die gewichtete Ähnlichkeit von x <strong>und</strong> y wsim(x, y) größer als ein<br />
bestimmter Grenzwert th accept ist.<br />
Bei der Berechnung von ssim im zweiten Schritt muss sichergestellt werden, dass zuvor<br />
die Ähnlichkeitswerte wsim für alle Blätter berechnet wurden. Aus diesem Gr<strong>und</strong> werden<br />
in der Schleife die beiden Bäume in Post-Order durchlaufen, was genau das sicherstellt.<br />
Post-Order bedeutet im Zusammenhang mit Bäumen, dass ausgehend von der Wurzel<br />
zunächst der linke Teilbaum, dann der rechte Teilbaum <strong>und</strong> zuletzt die Wurzel betrachtet<br />
wird.<br />
Nachdem ssim(s, t) für jedes Knotenpaar (s, t) berechnet wurde, wird die gewichtete<br />
Ähnlichkeit wsim(s, t) für dieses Knotenpaar wie folgt berechnet:<br />
wsim(s, t) = w struct · ssim(s, t) + (1 − w struct ) · lsim(s, t)<br />
Hierbei ist w struct eine Konstante im Intervall [0, 1] <strong>und</strong> dient dazu, eine unterschiedliche<br />
Gewichtung von linguistischer <strong>und</strong> struktureller Ähnlichkeit zu ermöglichen.<br />
Nach Berechnung der gewichteten Ähnlichkeit für ein Knotenpaar (s, t) überprüft<br />
TreeMatch, ob der Ähnlichkeitswert von wsim oberhalb eines Grenzwertes th high liegt.<br />
Ist das der Fall, werden die Ähnlichkeitswerte ssim aller Paare von Blättern in den beiden<br />
Teilbäumen zu s <strong>und</strong> t um einen Faktor c inc erhöht, wobei darauf geachtet wird, dass die<br />
maximalen Werte von ssim nie größer als 1 werden. Diese Erhöhung der Werte geschieht<br />
deshalb, weil die Entwickler von Cupid annehmen, dass Blätter, deren Vorfahren sehr<br />
ähnlich sind, ebenfalls eine höhere Ähnlichkeit aufweisen. Ist der Wert für wsim kleiner<br />
als th low , werden die Ähnlichkeitswerte ssim der Blätter aus demselben Gr<strong>und</strong> um einen<br />
Wert c dec verringert.<br />
Diese Veränderung der strukturellen Ähnlichkeiten führt bei Teilbäumen mit einer<br />
sehr unterschiedlichen Anzahl an Knoten dazu, dass es sehr viele Ähnlichkeitswerte gibt,<br />
die unterhalb des Grenzwertes liegen. Um dem entgegenzuwirken schlagen die Entwickler<br />
vor, nur Elemente zu vergleichen, deren Teilbäume eine ähnliche Anzahl an Blättern<br />
32
(vorgeschlagen ist ein Unterschied von maximal Faktor 2) haben. Das führt dazu, dass<br />
der Algorithmus weitaus weniger Paare zum Vergleich hat.<br />
Vergleicht man den Ablauf des strukturellen Matchings von Cupid mit dem Ablauf<br />
des Algorithmus beim Similarity Flooding, können hier wesentliche Unterschiede festgestellt<br />
werden. Zunächst unterscheiden sich die beiden Verfahren darin, dass Cupid in<br />
der vorgestellten Form nur Bäume als graphische Strukturen unterstützt, während beim<br />
Similarity Flooding gerichtete Graphen verwendet werden. Das bedeutet also, dass das<br />
Similarity Flooding hier mehr Varianten von Eingaben unterstützt als nur hierarchische<br />
Schemata. In [MBR01] wird allerdings auch eine Möglichkeit vorgestellt, wie anders<br />
strukturierte Eingabegraphen in Bäume umgewandelt werden können, die dann wiederum<br />
mit Cupid verarbeitet werden können. Die näheren Details dazu sollen hier aufgr<strong>und</strong><br />
des Umfangs nicht weiter betrachtet werden.<br />
Bei der Berechnung der Ähnlichkeitswerte werden in beiden Verfahren sehr unterschiedliche<br />
Ideen zugr<strong>und</strong>e gelegt. Während das Similarity Flooding alle mit einem<br />
Knoten verb<strong>und</strong>enen Knoten in die Berechnung mit einbezieht, werden bei Cupid ausschließlich<br />
die Blätter für die Berechnungen herangezogen. Das bedeutet, dass in einem<br />
Teilbaum mit hoher Tiefe trotzdem nicht die direkten Nachfolgeknoten zur Berechnung<br />
der Ähnlichkeiten verwendet werden, sondern nur die Blätter, die in diesem Fall erst sehr<br />
viel tiefer im Baum stehen. Ein wenig kompensiert wird das zwar dadurch, dass die Ähnlichkeiten<br />
der Blätter aufgr<strong>und</strong> des Post-Order-Durchlaufs bis dahin unter Umständen<br />
schon mehrfach erhöht oder verringert worden sein können, dennoch wird im Similarity<br />
Flooding zumindest die Gesamtheit der Strukturen im Graphen mehr berücksichtigt.<br />
Ein weiterer wesentlicher Unterschied zwischen den beiden Verfahren ist, dass Cupid<br />
bei der Berechnung der Ähnlichkeiten zweier Elemente sehr stark auf die anfänglich berechneten<br />
linguistischen Ähnlichkeiten setzt. Diese fließen in die gewichtete Ähnlichkeit<br />
wsim ein <strong>und</strong> werden während des gesamten Ablaufs des Algorithmus nicht verändert. Je<br />
nachdem, wie die Konstante w struct gewählt ist <strong>und</strong> wie sich die Ähnlichkeitswerte ssim<br />
im Laufe des Algorithmus verändern, könnten diese linguistischen Werte einen starken<br />
Einfluss auf die endgültige Ähnlichkeit zweier Knoten haben. Beim Similarity Flooding<br />
tritt dieses Phänomen weitaus weniger stark auf, da zwar die lingustischen Ähnlichkeiten<br />
als Anfangsähnlichkeiten im ersten Schritt des Algorithmus relevant sind, aufgr<strong>und</strong><br />
des „Flusses“ der Werte aber im weiteren Verlauf immer stärker angeglichen werden,<br />
was laut [MGMR01] letztendlich auch dafür sorgt, dass selbst mit „schlecht“ gewählten<br />
Anfangsähnlichkeiten noch gute Ergebnisse mit dem Similarity Flooding erzielt werden<br />
können. Fraglich ist, ob das in diesem Fall auch bei Cupid möglich ist.<br />
5.2. Rondo<br />
In [MRB03] entwickeln die Autoren ein Verfahren, mit dem generisch Modelle gematcht<br />
werden können, <strong>und</strong> implementieren einen Prototyp mit Namen Rondo. Während es beim<br />
in Kapitel 4 vorgestellten Similarity Flooding im Wesentlichen darum geht, geeignete<br />
Mappings zwischen Elementen herzustellen, gehen die Autoren hier noch einen Schritt<br />
weiter, indem sie auch ein automatisiertes Verfahren einführen, mit dem die Modelle<br />
33
gemerged werden können. Im Rahmen dieser Arbeit soll dieses Merging nicht näher<br />
betrachtet werden, sondern vielmehr die Schritte vorher – nämlich das Auffinden eines<br />
Mappings der Elemente der Modelle – in den Fokus treten.<br />
Wie beim Similarity Flooding werden bei Rondo zunächst intern die Modelle als<br />
Graphen – genauer gesagt gerichtete, azyklische <strong>und</strong> markierte Graphen – gespeichert.<br />
Knoten enthalten dabei die Informationen über die Elemente der Modelle – also etwa<br />
Relationen, Attribute, SQL-Anweisungen etc. – die durch Kanten in Beziehung gesetzt<br />
werden. Im Unterschied zum Similarity Flooding ist es hier zusätzlich möglich, zu den<br />
Kanten eine Sortierung zu speichern, sodass man zum Beispiel bei einer Tabelle mit<br />
zwei Spalten diese Spalten ordnen könnte. Außerdem erhält hier jeder Knoten einen<br />
eindeutigen Identifizierer.<br />
Zur Repräsentation von Mappings innerhalb der Modelle oder zwischen den Modellen<br />
werden Morphismen verwendet, d.h. binäre Relationen zwischen zwei Mengen von<br />
Objekten aus den Modellen. Diese Morphismen können weitere Informationen bekommen,<br />
wenn es etwa um Ähnlichkeitswerte zwischen den Mengen geht, die durch den<br />
Morphismus verb<strong>und</strong>en werden.<br />
Neben den Morphismen stellen die Autoren sogenannte Selector vor, die dazu dienen,<br />
eine Menge von Identifizierern von Knoten darzustellen. Zudem werden eine Reihe Operationen<br />
definiert, um bestimmte Bereiche der Graphen auswählen oder modifizieren zu<br />
können.<br />
Für die Berechnung eines Matchings innerhalb der Methode Match wird in der konkreten<br />
Implementierung das Similarity Flooding ohne wesentliche Änderungen an der in<br />
Kapitel 4 vorgestellten Variante übernommen. Für das abschließende Filtern der Ergebnisse<br />
wird hier der Filter verwendet, der das Stable-Marriage-Verfahren instrumentalisiert.<br />
Zusammenfassend lässt sich festhalten, dass die Autoren mit Rondo ein Verfahren<br />
entwickelt <strong>und</strong> implementiert haben, deren Fokus ganz klar auf der generischen Beschreibung<br />
<strong>und</strong> auf dem automatischen Merging der Eingabemodelle liegt. Da hier das<br />
Similarity Flooding ohne Modifikationen verwendet wird, eignet sich Rondo in dieser<br />
Form nicht für einen Vergleich mit anderen Verfahren, sondern kann eher als ein „Rahmen“<br />
angesehen werden, in dem verschiedene Verfahren implementiert sein könnten.<br />
5.3. SASMINT<br />
Ähnlich wie bei Rondo handelt es sich bei dem Ansatz von Semi Automatic Schema<br />
Matching and INTegration (SASMINT) nicht um ein eigenständiges Verfahren, das sich<br />
ad-hoc mit dem Similarity Flooding vergleichen ließe. Stattdessen stellen die Autoren<br />
von [UA10] mit SASMINT eine Möglichkeit dar, verschiedenste Verfahren <strong>und</strong> Metriken<br />
zu kombinieren, um so bessere Ergebnisse beim Schema-Matching <strong>und</strong> der Integration<br />
erzielen zu können als mit einem einzelnen Verfahren.<br />
Obwohl der Fokus von [UA10] stark auf der Integration <strong>und</strong> weniger auf dem Matching<br />
liegt, soll im Rahmen dieser Arbeit nicht weiter auf das Matching im Sinne von<br />
SASMINT eingegangen werden. Stattdessen sollen die Schritte beschrieben werden, die<br />
34
durchgeführt werden müssen, um ein endgültiges Matching zu erhalten, <strong>und</strong> näher erläutert<br />
werden, an welcher Stelle <strong>und</strong> in welcher Form das Similarity Flooding bei SASMINT<br />
verwendet wird.<br />
Bevor in SASMINT Eingabedaten verarbeitet (also z.B. Schemata geladen) werden,<br />
werden Gewichte für alle Metriken <strong>und</strong> Algorithmen, die verwendet werden sollen, berechnet<br />
<strong>und</strong> entsprechend zugewiesen. Das geschieht standardmäßig durch Berechnung<br />
einer gewichteten Summer aller Metriken <strong>und</strong> Verfahren. Falls Bedarf besteht, kann hier<br />
auch ein Benutzer manuell Gewichte festlegen. Danach werden die Auswahlkriterien für<br />
die Ergebnisse des Matchings festgelegt. Hierbei sind Eingaben der Benutzer nötig, um<br />
Grenzwerte (Thresholds) festzulegen <strong>und</strong> zu bestimmen, ob alle Werte oberhalb dieser<br />
Grenzwerte ausgegeben werden sollen oder nur der jeweils größte.<br />
Nach diesen beiden Schritten werden die Schemata geladen <strong>und</strong> direkt dabei in gerichtete,<br />
azyklische Graphen überführt. In der anschließenden Vorverarbeitungsphase<br />
werden nacheinander die folgenden Operationen durchgeführt, ohne dass hier weiter<br />
darauf eingegangen werden soll:<br />
1. Eliminierung von stop words <strong>und</strong> Sonderzeichen<br />
2. Tokenization <strong>und</strong> Trennung von Wörtern<br />
3. Erweiterung von Abkürzungen<br />
4. Normalisierung von Termen in ihre Gr<strong>und</strong>form mit Lemmatisierung<br />
Nun folgt in SASMINT das eigentliche Matching, das in zwei Schritte eingeteilt ist.<br />
Zuerst werden die Schemata linguistisch verglichen, anschließend strukturell.<br />
Beim linguistischen Vergleich werden die Elemente der Schemata zunächst syntaktisch<br />
vergleichen, wozu verschiedenste Metriken herangezogen werden können (etwa Levenshtein<br />
Distanz, tf-idf-Werte oder Jaccard-Koeffizienten). Anschließend werden semantische<br />
Ähnlichkeiten berechnet, wobei auch hier diverse Methoden vorstellbar sind.<br />
Beim strukturellen Vergleich werden die Ähnlichkeiten der Schemata basierend auf<br />
ihrer Struktur berechnet. Hierbei werden die Ergebnisse des linguistischen Vergleichs<br />
als Eingabewerte verwendet. In dieser Phase findet auch das Similarity Flooding Verwendung,<br />
es sind aber auch weitere Verfahren denkbar. Werden hier mehrere Verfahren<br />
zusammen verwendet, wird als Ergebnis die gewichtete Summe der Ergebnisse aller Verfahren<br />
verwendet.<br />
Obwohl in der Matching-Phase das Similarity Flooding in unveränderter Form verwendet<br />
werden kann <strong>und</strong> auch wird, gibt es einen bedeutsamen Unterschied zwischen<br />
den Ähnlichkeitswerten, die bei SASMINT berechnet werden, <strong>und</strong> denen, die das Similarity<br />
Flooding liefert. Während beim Similarity Flooding linguistische Ähnlichkeiten –<br />
sofern sie überhaupt berechnet werden – lediglich als Anfangsähnlichkeiten in den Algorithmus<br />
einfließen, im Nachhinein aber die Ähnlichkeitswerte nicht weiter beeinflussen,<br />
geht SASMINT eine Stufe weiter. Hier werden die Ähnlichkeitswerte sim(a, b) zweier<br />
Elemente a <strong>und</strong> b in der Matching-Phase durch folgende Formel berechnet:<br />
sim(a, b) = w linguistisch · sm linguistisch (a, b) + w strukturell · sm strukturell (a, b)<br />
35
Dabei ist sm linguistisch (a, b) die linguistische Ähnlichkeit von (a, b), w linguistisch das Gewicht<br />
vom linguistischen Matching, sm strukturell (a, b) die strukturelle Ähnlichkeit von<br />
(a, b) <strong>und</strong> w strukturell das Gewicht des strukturellen Matchings.<br />
Man kann hierbei also, wenn Bedarf besteht, die Ähnlichkeiten, die durch das linguistische<br />
Matching entstanden sind, direkt mit in die endgültige Berechnung der Ähnlichkeiten<br />
einbeziehen, auch wenn sie zusätzlich noch als Eingabewerte für Anfangsähnlichkeiten<br />
in strukturellen Verfahren verwendet werden können. Durch geeignete Wahl der<br />
Gewichtungen für die beiden Matching-Arten können zudem auch je nach Anwendung<br />
Struktur oder linguistische Ähnlichkeiten unterschiedlich stark berücksichtigt werden.<br />
Zusammenfassend kann festgehalten werden, dass SASMINT durch die diversen Variationsmöglichkeiten<br />
bei den Algorithmen, Metriken <strong>und</strong> Gewichtungen eine deutlich<br />
mächtigere Form für das Matching von Schemata darstellt als das Similarity Flooding.<br />
Dass der Similarity Flooding Algorithmus trotzdem als Bestandteil von SASMINT in<br />
[UA10] erwähnt wird, deutet darauf hin, dass die Anzahl der alternativen Verfahren, die<br />
Matchings aufgr<strong>und</strong> von strukturellen Ähnlichkeiten berechnen, auch acht Jahre nach<br />
Entwicklung des Similarity Flooding noch schwindend gering ist.<br />
36
6. Implementierung der Testumgebung<br />
Für die Experimente, die im folgenden Kapitel durchgeführt werden sollen, wurde im<br />
Rahmen dieser Arbeit eine Testumgebung entwickelt, die in diesem Kapitel beschrieben<br />
werden soll. Im Java-Code finden sich ausführliche Kommentare als Javadoc, sodass<br />
hier nur ein Überblick geliefert <strong>und</strong> einige Besonderheiten hervorgehoben werden. Dabei<br />
wird zunächst auf die Anforderungen eingegangen, die an die Testumgebung gestellt<br />
werden, bevor ihre Funktionen, die Bedienung <strong>und</strong> schließlich die wichtigsten Funktionen<br />
detaillierter beschrieben werden.<br />
6.1. Anforderungen an die Testumgebung<br />
Die Testumgebung soll dazu dienen, den Similarity Flooding Algorithmus mit verschiedenen<br />
Eingaben <strong>und</strong> Parametern auszuführen <strong>und</strong> anhand der Ergebnisse Vergleiche<br />
anstellen zu können. Die Experimente sollen dabei sowohl mit Schemata als auch mit<br />
Graphen möglich sein. Für die Schemata soll eine Eingabe-Schnittstelle vorhanden sein,<br />
die relationale Schemata aus einer Textdatei einlesen kann, bei den Graphen soll aus<br />
einer festen Menge gewählt werden können.<br />
Für den Similarity Flooding Algorithmus soll die Möglichkeit bestehen, (teil-)automatisiert<br />
<strong>und</strong> manuell Anfangsähnlichkeiten festlegen zu können. Bei den Ähnlichkeitsberechnungen<br />
in den einzelnen Iterationen des Verfahrens soll im Voraus zwischen mehreren<br />
Fixpunktformeln gewählt werden können, außerdem soll die maximale Anzahl an<br />
Iterationen gewählt werden können, nach der das Verfahren abbricht.<br />
Die Ergebnisse des Similarity Flooding sollen in Tabellenform dargestellt werden, in<br />
der eine Sortierung nach Werten <strong>und</strong> Knotennamen möglich sein soll. Dadurch soll später<br />
eine bessere Vergleichbarkeit der Ergebniswerte erreicht werden können. Die Ergebnisse<br />
sollen gemäß des Stable Marriage Algorithmus gefiltert werden können, außerdem soll<br />
eine Speicherfunktion die Werte in Form einer Textdatei auf der Festplatte sichern.<br />
Um die Bedienung der Testumgebung zu erleichtern, soll eine graphische Oberfläche<br />
zur Verfügung stehen, die alle Funktionen gestattet.<br />
6.2. Funktionen <strong>und</strong> Bedienung des Programmes<br />
Das Hauptprogramm bietet die Möglichkeit, Experimente an Graphen <strong>und</strong> Schemata<br />
unterstützt durch ein graphisches Interface durchzuführen. Bei den Graphen kann als<br />
Eingabe zwischen den sieben verschiedenen Beispielen gewählt werden, die in Kapitel<br />
7.2.1 näher beschrieben werden. Eine Eingabeschnittstelle für weitere Graphen ist hier<br />
nicht vorgesehen.<br />
37
Abbildung 6.1.: Das Hauptmenü der Testumgebung<br />
Abbildung 6.2.: Das Graphen-Menü<br />
Abbildung 6.3.: Das Schema-Menü<br />
38
Abbildung 6.4.: Menü mit den Anfangsähnlichkeiten<br />
Abbildung 6.5.: Fenster für die Vorverarbeitung<br />
Bei den Schemata können über eine Eingabeschnittstelle Relationale Datenbankschemata<br />
in Form von Textdateien eingelesen <strong>und</strong> in ihre graphischen Repräsentationen<br />
umgewandelt werden. Näheres dazu ist in Kapitel 6.5 nachzulesen.<br />
Abbildung 6.1 zeigt das Hauptmenü der Testumgebung. Abbildung 6.2 stellt das<br />
Graphen-Menü dar, Abbildung 6.3 das Schema-Menü.<br />
Unabhängig davon, ob Graphen oder Schemata für die Experimente verwendet werden,<br />
wird nach deren Auswahl das Fenster Anfangsähnlichkeiten (siehe Abbildung 6.4)<br />
angezeigt, dass verschiedene Einstellungen ermöglicht, die für den Ablauf des Similarity<br />
Flooding notwendig sind. Die Eingabe einer Anzahl von Iterationen sorgt dafür, dass das<br />
Verfahren spätestens nach dieser Iteration abbricht, auch wenn sich noch kein Fixpunkt<br />
eingestellt hat. Bei der Fixpunktformel kann zwischen zwei der Formeln gewählt werden,<br />
die in Tabelle 4.3 in Kapitel 4.3 dargestellt sind.<br />
39
Abbildung 6.6.: Fenster mit den Ergebnissen<br />
Die Anfangsähnlichkeiten der Knoten können manuell für jeden Knoten eingegeben<br />
oder geändert – wobei 1.0 als Standardwert für alle Knoten vorgegeben ist –, alle auf<br />
den Wert 0, 1 oder Zufallswerte oder in einer Vorverarbeitung basierend auf gleichen<br />
(Teil-)Namen gesetzt werden. Das Fenster für die Vorverarbeitung ist in Abbildung 6.5<br />
zu sehen.<br />
Nach dem Ausführen des Verfahrens über den entsprechenden Button wird das Fenster<br />
Ergebnisse (siehe Abbildung 6.6) angezeigt, das die berechneten Ähnlichkeitswerte<br />
absteigend sortiert anzeigt. Darunter wird die Anzahl der Iterationen ausgegeben, die<br />
nötig war, bis sich ein Fixpunkt eingestellt hat.<br />
Knoten im Ergebnis, denen zuvor eine Anfangsähnlichkeit ungleich 0 zugewiesen wurde,<br />
werden dabei als ausgewählt markiert, können aber auch manuell abgewählt werden.<br />
Genauso ist die Markierung weiterer Knoten möglich. Gewählten Knoten wird für eine<br />
Wiederholung bzw. Iteration des Verfahrens eine Anfangsähnlichkeit von 1 zugewiesen,<br />
nicht gewählten eine 0. Über das Eingabefeld kann festgelegt werden, dass automatisch<br />
alle Knoten gewählt werden, die gleich diesem Wert sind oder oberhalb davon liegen,<br />
während alle anderen abgewählt werden.<br />
Die Ergebnisse können mit Hilfe einer Stable Marriage gefiltert werden, deren Resultate<br />
in einem neuen Fenster angezeigt werden (siehe Abbildung 6.7). Hier besteht auch<br />
40
Abbildung 6.7.: Filterung der Ergebnisse mit Stable Marriage<br />
die Möglichkeit, die Knoten der Stable Marriage automatisch markieren zu lassen. Außerdem<br />
lassen sich die berechneten Werte über alle Iterationen hinweg in einer Textdatei<br />
speichern.<br />
6.3. Paketstruktur<br />
Die Testumgebung ist in sechs Pakete (packages) unterteilt, deren Inhalt hier kurz vorgestellt<br />
wird. Einige der Klassen werden in den folgenden Abschnitten noch näher erläutert,<br />
alle weiteren Details sind in der Javadoc zu finden.<br />
• similarityflooding.main enthält mit SimilarityFlooding das Hauptprogramm,<br />
das unter anderem die visuelle Darstellung der Menüs erzeugt <strong>und</strong> die anderen<br />
Klassen verknüpft.<br />
• similarityflooding.misc beinhaltet die in den Experimenten verwendeten Beispielgraphen<br />
in ExampleGraph <strong>und</strong> einige Hilfsklassen. MGtoSPGTransformation<br />
dient zum Umwandeln eines Modell-Graphen in einen Similarity Propagation Graph,<br />
ResultTableModel dient zur Darstellung der Ergebnisse des Similarity Flooding,<br />
TextOutput ermöglicht das Speichern der Ergebnisse in einer Textdatei.<br />
• similarityflooding.mgraph stellt mit MGEdge, MGNode <strong>und</strong> ModelGraph Klassen<br />
bereit, um einen Modell-Graphen darzustellen.<br />
41
• similarityflooding.relationalschema enthält in RelationalSchema die Darstellung<br />
eines Relationalen Datenbankschemas, bestehend aus Relationen (RSRelation)<br />
<strong>und</strong> Attributen (RSAttribute). Die Klasse SchemaReader ermöglicht das Einlesen<br />
eines Schemas aus einer Textdatei.<br />
• similarityflooding.resultfilters implementiert die Stable Marriage zum Filtern<br />
der Ergebnisse des Similarity Flooding. SMNode stellt dabei einen Knoten bereit,<br />
zu dem in StableMarriage der entsprechende „Partner“ gesucht wird.<br />
• similarityflooding.spgraph dient zur Darstellung eines Similarity Propagation<br />
Graph (in der Klasse SPGraph), bestehend aus Kanten (SPEdge) <strong>und</strong> Knoten<br />
(SPNode)<br />
6.4. Umgang mit Graphen<br />
Da das Similarity Flooding graph-basiert arbeitet, werden intern Graphen für die Darstellung<br />
der Daten verwendet. Dabei werden hier zwei verschiedene graphische Strukturen<br />
verwendet. Die Klasse ModelGraph dient zur Darstellung eines Modell-Graphen,<br />
also einer graphischen Repräsentation eines Modells. Knoten des Modell-Graphen – dargestellt<br />
in der Klasse MGNode – haben einen Namen, ansonsten keine weiteren Informationen.<br />
Gerichtete Kanten – dargestellt in MGEdge – verbinden jeweils zwei Knoten <strong>und</strong><br />
haben eine Kantenmarkierung in Form eines Strings.<br />
Um zwei Modell-Graphen zusammenzuführen, stellt die Klasse MGtoSPGTranformation<br />
die Methode transform bereit. Diese wandelt zwei Objekte der Klasse ModelGraph in<br />
ein SPGraph-Objekt um.<br />
SPGraph ist die Darstellung eines Similarity Propagation Graph, wie er in Kapitel<br />
4 beschrieben wurde. Jeder Knoten (SPGNode) enthält dabei die zwei Namen der korrespondierenden<br />
Knoten der beiden Modelle, den Ähnlichkeitswert <strong>und</strong> eine einfache<br />
Markierung, die für die Wiederholungen des Verfahrens benötigt wird. Gerichtete Kanten<br />
(SPGEdge) verbinden jeweils zwei Knoten <strong>und</strong> speichern die Kantenmarkierung sowie<br />
den Propagation-Koeffizienten.<br />
In der Methode calculateSimilarity der Klasse SPGraph ist das eigentliche Similarity<br />
Flooding implementiert. Über die zwei Parameter number <strong>und</strong> normalizationFormula<br />
wird die Anzahl der Iterationen, nach der das Verfahren spätestens abbricht, <strong>und</strong> die<br />
verwendete Fixpunktformel festgelegt. Das Verfahren an sich wurde wie in Kapitel 4 beschrieben<br />
umgesetzt. Um zusätzliche Funktionen – wie etwa das Speichern der Ergebnisse<br />
jeder Iteration in einer Textdatei – zu ermöglichen, wurden zwar einige Codezeilen hinzugefügt,<br />
die Berechnungen der Ähnlichkeitswerte mit dem Similarity Flooding werden<br />
dadurch jedoch nicht beeinflusst.<br />
42
AUTOR(Name (PK), Geburtsdatum);<br />
BUCH(ISBN (PK), Autor (FK) -> AUTOR, Titel);<br />
AUTOR(Name, Geburtsdatum)<br />
BUCH(ISBN, Autor → AUTOR, Titel)<br />
Abbildung 6.8.: Beispiel für ein gültiges Schema als Input (oben) <strong>und</strong> äquivalente Darstellung<br />
des Schemas (unten)<br />
6.5. Umgang mit Relationalen Datenbankschemata<br />
Relationale Datenbankschemata können mit Hilfe der Klasse SchemaReader aus Textdateien<br />
eingelesen werden. Damit aus den Texten gültige Dateien erzeugt werden können,<br />
müssen sie folgendermaßen aufgebaut sein:<br />
• Jede Relation hat die Form Relationenname(Attribut1, Attribut2, ...);<br />
• Primärschlüsselattribute sind durch „Attributname (PK)“ zu kennzeichnen<br />
• Fremdschlüssel sind durch „Attributname (FK) -> Relationenname“ zu kennzeichnen<br />
• primäre Fremdschlüssel sind durch „Attributname (FPK) -> Relationenname“ zu<br />
kennzeichnen<br />
• normale Attribute sind durch „Attributname“ zu kennzeichnen<br />
• Primärschlüsselattribute (PK) stehen hinter den primären Fremdschlüsselattribute<br />
(FPK)<br />
Abbildung 6.8 stellt ein einfaches Schema dar, das als gültige Eingabe erkannt <strong>und</strong><br />
eingelesen werden kann. Darunter ist die gewohnte Darstellung des Schemas abgebildet.<br />
Haben sie diese Struktur, erzeugt die Methode read der Klasse SchemaReader daraus<br />
ein RelationalSchema-Objekt mit einer Menge von Relationen (RSRelation) <strong>und</strong> zugehörigen<br />
Attributen (RSAttribute). Im Programm geschieht das Umwandeln automatisch<br />
nach Auswahl gültiger Textdateien mit Schemata im Schema-Menü <strong>und</strong> Drücken des umwandeln-Buttons.<br />
Die Methode transform der Klasse RelationalSchema wandelt das<br />
jeweilige Schema in einen Modell-Graphen um. Dabei sind zwei verschiedene Verfahren<br />
(transform_1 <strong>und</strong> transform_2) implementiert, die zwei unterschiedliche graphische<br />
Darstellungen erzeugen <strong>und</strong> durch Angabe von 1 oder 2 als Parameterwert für method<br />
beim Aufruf von transform ausgewählt werden können. transform_2 erzeugt dabei die<br />
Darstellung, die für die Experimente in Kapitel 7.3 verwendet <strong>und</strong> dort näher beschrieben<br />
wird. transform_1 diente für frühere Experimente, die im Rahmen der Arbeit nicht<br />
weiter beschrieben werden.<br />
43
7. Empirische Bef<strong>und</strong>e <strong>und</strong> Experimente<br />
zum Similarity Flooding<br />
Kapitel 4 befasste sich damit, wie der Similarity Flooding Algorithmus funktioniert <strong>und</strong><br />
wie mit Ergebnissen umgegangen werden kann. Das folgende Kapitel befasst sich nun<br />
mit der Frage, ob bzw. wie gut das Similarity Flooding dafür geeignet ist, Matchings zu<br />
finden, <strong>und</strong> ob bzw. wie man die Qualität der Ergebnisse verbessern kann. Dazu wird im<br />
Folgenden zunächst darauf eingegangen, wie das Thema in der Literatur behandelt wird<br />
<strong>und</strong> welche Ergebnisse es dort gibt, bevor anschließend eine Reihe eigener Experimente<br />
durchgeführt <strong>und</strong> beschrieben werden.<br />
7.1. Bef<strong>und</strong>e in der Literatur<br />
Um die Qualität des Similarity Flooding feststellen zu können, beschäftigen sich die<br />
Autoren von [MGMR01] mit der Frage, ob es überhaupt eine geeignete Metrik gibt, um<br />
diese zu ermitteln. Sie stellen schließlich eine solche Metrik vor, die im Wesentlichen auf<br />
dem Benutzeraufwand basiert, der benötigt wird, um die Ergebnisse, die automatisch von<br />
einem Algorithmus geliefert werden, in die gewünschten Ergebnisse zu transformieren.<br />
Ihre Wahl begründen sie damit, dass in vielen Anwendungsgebieten eines Matchings<br />
dessen Ziel stark von der Intention des Benutzers abhängt <strong>und</strong> man sich aus diesem<br />
Gr<strong>und</strong> nicht einfach einer vorhandenen Metrik bedienen kann.<br />
Die Autoren stellen – basierend auf ihrer Metrik – in Studien mit acht Benutzern,<br />
die mit Hilfe des Verfahrens Schemata matchen sollen, Folgendes fest: Auch wenn der<br />
Algorithmus nicht in jedem Fall sehr gute Ergebnisse liefert, können im Schnitt 52% des<br />
manuellen Aufwands durch ihn eingespart werden. In typischen Anwendungsfällen bescheinigen<br />
sie dem Algorithmus sogar eine noch weitaus größere Aufwandsersparnis. Bezüglich<br />
der Filter der Ergebnisse stellen sie fest, dass solche, welche die Stable-Marriage-<br />
Eigenschaft aufrechterhalten, besser geeignet sind als andere. Als Fixpunktformel empfehlen<br />
sie nach den Ergebnissen ihrer Studien die Formel C (vgl. Tabelle 4.3), welche<br />
am schnellsten konvergiert <strong>und</strong> von der Qualität her annähernd gleiche Ergebnisse liefert<br />
wie die anderen Formeln. Als Formel zur Errechnung der Propagation-Koeffizienten<br />
empfehlen sie – wie in Kapitel 4.2 erwähnt – den inversen Durchschnitt (vgl. Tabelle 4.1).<br />
Außerdem stellen sie fest, dass der Algorithmus „Fehlern“ bei den Anfangsähnlichkeiten<br />
gegenüber relativ tolerant ist, sich die Ergebnisse also kaum bzw. gar nicht ändern, selbst<br />
wenn Anfangsähnlichkeiten „falsch“ bestimmt wurden.<br />
Obwohl das Similarity Flooding in einer Reihe von weiteren Verfahren wie etwa SemInt<br />
verwendet wird, gibt es ansonsten in der Literatur relativ wenige Bef<strong>und</strong>e, die<br />
44
sich allein mit der Qualität des Verfahrens befassen. Hauptsächlich wird das Verfahren<br />
einfach als funktional hingenommen <strong>und</strong> anschließend nur noch die Qualität des neu<br />
vorgestellten Verfahrens bewertet, sodass keinerlei Rückschlüsse auf die Qualität des<br />
Similarity Flooding möglich sind.<br />
In [DMR02] werden einige unterschiedliche Verfahren in Experimenten verglichen,<br />
unter ihnen auch das Similarity Flooding. Die Experimente <strong>und</strong> Ergebnisse bezüglich<br />
des Similarity Floodings sind dabei allerdings keine anderen als in [MGMR01], was<br />
vermutlich daran liegt, dass zwei der drei Autoren in beiden Werken identisch sind.<br />
Auch hier sind also keine neueren Bef<strong>und</strong>e festzuhalten.<br />
7.2. Experimente an Graphen<br />
In den folgenden Abschnitten sollen einige der Ergebnisse, die von den Autoren in<br />
[MGMR01] festgestellt wurden, in eigenen Experimenten überprüft sowie weitere Untersuchungen<br />
zum Similarity Flooding angestellt werden. Da es im Rahmen dieser Arbeit<br />
nicht möglich ist, jedes Detail des Algorithmus <strong>und</strong> jede Beobachtung, die in Experimenten<br />
in der Literatur gemacht wurde, zu überprüfen, werden hier exemplarisch zwei<br />
Aspekte des Similarity Flooding näher beleuchtet.<br />
Zuerst sollen die Auswirkungen der Anfangsähnlichkeiten auf die Ergebnisse betrachtet<br />
werden. Die These der Entwickler des Algorithmus, dass dieser gegenüber Fehlern<br />
bei den Anfangsähnlichkeiten tolerant ist, bedarf einer weiteren Überprüfung. Hier stellt<br />
sich die Frage, ob man sich für den Fall, dass die Beobachtung der Autoren zutrifft, die<br />
Berechnung von Anfangsähnlichkeiten in der Vorverarbeitungsphase nicht vollständig<br />
sparen könnte.<br />
Als zweites soll überprüft werden, wie sich die Verwendung einer anderen Fixpunktformel<br />
auf das Similarity Flooding auswirkt. Die Autoren von [MGMR01] bescheinigen allen<br />
Formeln, dass sie zu sehr ähnlichen Ergebnisse führen. An dieser Stelle ist zu überprüfen,<br />
ob das tatsächlich der Fall ist oder ob durch die Wahl einer anderen Fixpunktformel die<br />
Ergebnisse doch beeinflusst werden können.<br />
7.2.1. Experimentdurchführung<br />
Bevor auf die Ergebnisse der Experimente eingegangen werden kann, soll in diesem Abschnitt<br />
zunächst darauf eingegangen werden, wie die Experimente durchgeführt wurden<br />
<strong>und</strong> was für Graphen als Gr<strong>und</strong>lage für die Tests dienten. Für alle Experimente in diesem<br />
Kapitel wurde das in Kapitel 6 vorgestellte Programm verwendet.<br />
Gr<strong>und</strong>sätzlicher Ablauf der Experimente<br />
Um die späteren Ergebnisse gut auswerten <strong>und</strong> vergleichen zu können, wurden die Experimente<br />
nach einem festen Schema durchgeführt. Für alle Tests wurde der Similarity<br />
Flooding Algorithmus bis zum Erreichen eines Fixpunktes durchgeführt. Dabei wurde<br />
als Abbruchbedingung für die Berechnungen ein konstanter Wert von ɛ = 0.001 verwendet.<br />
Eine Abbruchbedingung nach einer bestimmten Anzahl von Iterationen wurde<br />
45
nicht verwendet, um die Anzahl der Iterationen, die bis zum Fixpunkt bei den einzelnen<br />
Testdurchläufen benötigt wurden, besser vergleichen zu können.<br />
Für die beiden zu überprüfenden Aspekte – die Auswirkung der Anfangsähnlichkeiten<br />
<strong>und</strong> die Verwendung einer anderen Fixpunktformel – wurden verschiedene Einstellungen<br />
(im Folgenden auch als „Fälle“ bezeichnet) festgelegt. Der Similarity Flooding Algorithmus<br />
wurde für jeden Graphen nacheinander mit diesen Fällen durchgeführt, sodass die<br />
Ergebnisse der einzelnen Fälle vergleichbar für mehrere Graphen sind. Eine genaue Beschreibung<br />
der jeweiligen Fälle ist zu Beginn der jeweiligen Kapitel (Kapitel 7.2.2 <strong>und</strong><br />
Kapitel 7.2.3) zu finden.<br />
Zu den jeweiligen Fällen wurde die Anzahl der Iterationen, bis ein Fixpunkt erreicht<br />
wurde, <strong>und</strong> die Ergebnisse der Ähnlichkeitsberechnungen nach jeder Iteration (einschließlich<br />
der Ähnlichkeitswerte im Fixpunkt nach der letzten Iteration) festgehalten. Dadurch<br />
lässt sich die Entwicklung der (normierten) Werte über die Iterationen hinweg analysieren<br />
<strong>und</strong> vergleichen.<br />
Nach Einstellen des Fixpunktes wurde die Ergebnismenge für jeden Fall außerdem<br />
mit Hilfe eines Stable Marriage Algorithmus (vgl. Kapitel 4.4.2) gefiltert. Dadurch ist<br />
insbesondere bei den größeren Graphen eine bessere Vergleichbarkeit der Ergebnisse<br />
gewährleistet <strong>und</strong> es lässt sich leichter ablesen, ob das Filtern der Ergebnisse sinnvolle<br />
Matching-Kandidaten liefert oder nicht.<br />
Verwendete Graphen<br />
Für die Experimente in diesem Kapitel wurden zunächst eine Reihe von Graphen erzeugt,<br />
auf deren strukturelles Aussehen <strong>und</strong> den Hintergr<strong>und</strong>, aus dem sie in den Tests<br />
verwendet werden, hier kurz eingegangen werden soll. Die Graphen bestehen dabei jeweils<br />
aus zwei Modellen, deren Abbildungen in Anhang A zu finden sind. Dort sind auch<br />
die Pairwise Connectivity Graphs (PCG) zu den Modellen abgebildet.<br />
Die Modelle von Graph 1 entsprechen denen, die im Beispiel in [MGMR01] verwendet<br />
wurden. Der PCG ist entsprechend ebenfalls dort zu finden. Für die hier durchgeführten<br />
Experimente wurde der Graph gewählt, um zum einen die in der Literatur ermittelten<br />
Fixpunkt-Werte nachzuvollziehen, <strong>und</strong> zum anderen, weil aufgr<strong>und</strong> der ähnlichen<br />
Strukturen der Modelle bestimmte Matching-Kandidaten wahrscheinlicher erscheinen<br />
als andere (z.B. erscheint (a, b) aufgr<strong>und</strong> der Anzahl ein- <strong>und</strong> ausgehender Kanten in<br />
den Modellen als Kandidat wahrscheinlicher als (a 1 , b)). Hier ist in den Experimenten<br />
insbesondere interessant zu überprüfen, ob trotzdem Fixpunkte mit unterschiedlichen<br />
Top-Kandidaten für Matchings erreicht werden können oder nicht.<br />
Graph 2 wurde ebenfalls aus [MGMR01] entnommen. Beide Modelle stellen dabei<br />
Bäume dar. Modell B ist dabei aus Modell A entstanden, indem die Knoten neu markiert<br />
wurden, zwei Teilbäume kopiert bzw. verschoben <strong>und</strong> ein neuer Knoten (60) eingefügt<br />
wurde. Der Graph ist für die Experimente interessant, weil bekannt ist, welche Knoten<br />
im Modell A welchen Knoten in Modell B entsprechen, sodass auch hier bestimmte Erwartungen<br />
vorhanden sind, welche Matching-Kandidaten der Algorithmus liefern sollte<br />
(z.B. (4, 55)) <strong>und</strong> welche nicht (z.B. (1, 57)). Die erwarteten Matching-Kandidaten sind<br />
im PCG in Anhang A grau markiert.<br />
46
Die Graphen 3, 4 <strong>und</strong> 5 sind jeweils aus Modellen entstanden, die keine eindeutigen<br />
strukturellen Ähnlichkeiten aufweisen. Graph 3 ist dabei mit 4 Knoten pro Modell am<br />
kleinsten, Graph 4 mit 6 Knoten in Modell A <strong>und</strong> 5 Knoten in Modell B ein wenig größer<br />
<strong>und</strong> Graph 5 mit 10 Knoten in Modell A <strong>und</strong> 12 in Modell B der größte der Graphen.<br />
Für die Experimente wurden die drei Graphen gewählt, um zu ermitteln, was für Ergebnisse<br />
der Algorithmus liefert, wenn für einen Betrachter keine eindeutigen Matching-<br />
Kandidaten in den Modellen erkannt werden können, <strong>und</strong> ob sich die Ergebnisse durch<br />
Änderungen von Anfangsähnlichkeiten oder Verwendung einer anderen Fixpunktformel<br />
leichter beeinflussen lassen als etwa bei den Graphen 1 <strong>und</strong> 2. Außerdem kann aufgr<strong>und</strong><br />
der unterschiedlichen Größen der Graphen hier der Frage nachgegangen werden, ob <strong>und</strong><br />
wie Veränderungen am Algorithmus die Anzahl der Iterationen beeinflussen, die bis zum<br />
Erreichen des Fixpunktes benötigt werden.<br />
Graph 6 besteht aus zwei strukturell identischen Modellen. Für die Experimente ist der<br />
Graph deshalb besonders interessant, weil zu erwarten ist, dass der Algorithmus jeweils<br />
die sich in den Modellen entsprechenden Knotenpaare als Matching-Kandidaten zurück<br />
liefert, also Paare (a i , b i ) mit i ∈ {1, . . . , 10}. Diese Paare sind im PCG in Anhang A<br />
grau hervorgehoben. Außerdem stellt sich die Frage, ob hier überhaupt unterschiedliche<br />
Fixpunkte erreicht werden können oder sich nur die – für einen Betrachter der Modelle<br />
eindeutigen – oben genannten Matching-Kandidaten ergeben.<br />
Die Modelle von Graph 7 wurden so konstruiert, dass Modell A aus zwei Zusammenhangskomponenten<br />
besteht, die jeweils strukturell identisch zu Modell B sind. Kantenmarkierungen<br />
wurden in den Modellen dabei weggelassen, was für den Algorithmus<br />
bedeutet, dass für jede Kante dieselbe Markierung angenommen wird. Wie in Graph 6<br />
gibt es hier somit von vornherein Matching-Kandidaten, die vom Algorithmus als Ergebnisse<br />
erwartet werden (im PCG in Anhang A grau hervorgehoben). Dadurch, dass es für<br />
jeden Knoten des Modells B erwartungsgemäß zwei Matching-Kandidaten mit gleichen<br />
Ähnlichkeitswerten – nämlich einen mit einem Knoten aus der einen Zusammenhangskomponente<br />
von Modell A <strong>und</strong> einen aus der anderen – im Ergebnis geben müsste, ist<br />
hier zu prüfen, ob der Algorithmus in den Experimenten so beeinflusst werden kann, dass<br />
er nur noch Matching-Kandidaten aus einer Zusammenhangskomponente von Modell A<br />
vorschlägt oder nicht.<br />
7.2.2. Anfangsähnlichkeiten<br />
Die Anfangsähnlichkeiten σ 0 sind die Ähnlichkeiten zwischen den Knoten a <strong>und</strong> b eines<br />
Map Pairs (a, b), die vor dem ersten Iterationsschritt festgelegt oder ermittelt wurden. In<br />
dem Beispiel des Algorithmus in Kapitel 4 wurde für alle Knoten die Anfangsähnlichkeit<br />
1 angenommen <strong>und</strong> von [MGMR01] behauptet, dass die Änderung der Ähnlichkeiten<br />
wenig bis keinen Einfluss auf die Ergebnisse hat, die der Algorithmus liefert.<br />
Zur Überprüfung der Behauptung wurden die Experimente wie in Kapitel 7.2.1 beschrieben<br />
durchgeführt. Insgesamt wurden hier fünf verschiedene Einstellungen in Form<br />
von fünf Fällen vorgenommen, deren Ergebnisse sowie deren Intention nachfolgend dargestellt<br />
sind. Bei den absoluten Zahlenwerten der Ähnlichkeiten wurde in den dargestellten<br />
Tabellen der Übersichtlichkeit halber auf drei Nachkommastellen ger<strong>und</strong>et.<br />
47
Knoten<br />
Fall<br />
1 2 3 4 5<br />
(a, b) 1 1 0 0 0.224<br />
(a 1 , b) 1 0 1 1 0.066<br />
(a 1 , b 1 ) 1 0 0 1 0.035<br />
(a 1 , b 2 ) 1 0 0 0 0.093<br />
(a 2 , b 1 ) 1 0 0 0 0.984<br />
(a 2 , b 2 ) 1 0 1 1 0.724<br />
Tabelle 7.1.: Anfangsähnlichkeiten für die jeweiligen Fälle (Graph 1)<br />
Im Verlauf dieses Kapitels werden für die jeweiligen Fälle beispielhaft Ähnlichkeitswerte<br />
tabellarisch dargestellt, in denen die an der jeweiligen Stelle erläuterten Beobachtungen<br />
ersichtlich sind. Als Beispielgraph dient hierbei der Graph 1. Die Anfangsähnlichkeiten,<br />
die für die jeweiligen Fälle eingestellt wurden, sind in Tabelle 7.1 dargestellt.<br />
Fall 1 (Referenzfall)<br />
Im 1. Fall wurden die Anfangsähnlichkeiten aller Knoten auf einen Wert von 1 gesetzt <strong>und</strong><br />
das Testprogramm damit für alle Graphen durchlaufen. Aufgr<strong>und</strong> der gleichen Werte war<br />
hier zu erwarten, dass sich jeweils ein Fixpunkt einstellt, in dem die Ähnlichkeitswerte<br />
der Knoten nur von der Struktur der Graphen abhängen. Die Ergebnisse aus diesem Fall<br />
sollen für die weiteren Fälle als Referenzwerte dienen.<br />
Die Experimente zeigen, dass sich wie erwartet bei jedem Beispielgraphen ein Fixpunkt<br />
einstellt. In den Ergebnismengen fällt auf, dass man die Knoten anhand ihrer<br />
Ähnlichkeitswerte in zwei Gruppen einteilen kann: Die eine Gruppe – im Folgenden N 1<br />
genannt – beinhaltet eine Anzahl Knoten, deren Ähnlichkeitswerte im Bereich zwischen<br />
einem Wert s min <strong>und</strong> 1 liegen. s min ist dabei der niedrigste Wert, den die Ähnlichkeiten<br />
der Knoten von N 1 annehmen, <strong>und</strong> liegt um die 0.1, kann bei einzelnen Graphen aber<br />
durchaus nach oben oder unten schwanken. Es ist jedoch immer ein deutlicher Sprung<br />
zwischen s min <strong>und</strong> dem größten Wert zu beobachten, den die Ähnlichkeiten der Knoten<br />
in N 2 annehmen können. Die zweite Gruppe (N 2 ), in die sich die Knoten im Ergebnis<br />
einteilen lassen, beinhaltet die restlichen Knoten, deren Ähnlichkeitswerte alle zwischen<br />
0 <strong>und</strong> s min (exklusiv) liegen, wobei die Mehrzahl der Werte bei oder sehr nah an 0 liegt.<br />
In den Abbildungen der Graphen in Anhang A wurden die Knoten im PCG, die der<br />
Menge N 1 zugeordnet werden können, durch doppelte Umrandungen hervorgehoben.<br />
Tabelle 7.2 zeigt für die Testgraphen, wie sich die Knoten in die beiden Mengen N 1<br />
<strong>und</strong> N 2 aufteilen. Der Übersicht halber ist die Gesamtanzahl der Knoten im Fixpunkt<br />
ebenfalls aufgeführt.<br />
Betrachtet man die Entwicklung der normierten Werte über die einzelnen Iterationen<br />
des Algorithmus, ist zu beobachten, dass die Ähnlichkeitswerte der Knoten aus N 1 schon<br />
mehrere Schritte vor Erreichen des Fixpunktes <strong>und</strong> demnach Abbruch des Algorithmus<br />
nahezu feste Werte angenommen haben. Änderungen der Zahlenwerte sind im Bereich<br />
48
Graph<br />
1 2 3 4 5 6 7<br />
|Knoten| 6 15 8 20 73 60 32<br />
|N 1 | 4 6 3 6 7 16 12<br />
|N 2 | 2 9 5 14 66 44 20<br />
Tabelle 7.2.: Verteilung der Knoten in N 1 <strong>und</strong> N 2 im Fixpunkt<br />
Knoten<br />
Iteration<br />
1 2 3 10 15 20 30 35 36 37<br />
(a, b) 1 1 1 1 1 1 1 1 1 1<br />
(a 1 , b) 0.667 0.571 0.5 0.191 0.094 0.046 0.011 0.005 0.005 0.004<br />
(a 1 , b 1 ) 0.5 0.429 0.406 0.384 0.383 0.383 0.383 0.383 0.383 0.383<br />
(a 1 , b 2 ) 0.667 0.643 0.656 0.704 0.707 0.707 0.707 0.707 0.707 0.707<br />
(a 2 , b 1 ) 0.833 0.857 0.875 0.921 0.923 0.924 0.924 0.924 0.924 0.924<br />
(a 2 , b 2 ) 0.667 0.571 0.5 0.191 0.094 0.046 0.011 0.005 0.005 0.004<br />
Tabelle 7.3.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1) für<br />
Fall 1<br />
von drei Nachkommastellen nicht mehr zu beobachten. Bei den Knoten aus N 2 fällt<br />
auf, dass diese in den ersten Iterationen der Ähnlichkeitsberechnung noch sehr stark<br />
schwankende Werte annehmen, nach einigen Iterationen aber zu beobachten ist, dass die<br />
Ähnlichkeitswerte bis zum Erreichen des Fixpunktes monoton fallen. Verringert man den<br />
Wert ɛ, der das Abbruchkriterium für das Erreichen des Fixpunktes darstellt, hat das<br />
auf die Ähnlichkeitswerte der Knoten aus N 1 im Fixpunkt keinerlei Auswirkungen mehr,<br />
während die Werte der Knoten aus N 2 weiter monoton fallen <strong>und</strong> sich immer mehr der<br />
0 annähern.<br />
Um diese Beobachtungen zu verdeutlichen, sind in Tabelle 7.3 beispielhaft die Ähnlichkeitswerte<br />
der Knoten des Graphen 1 nach mehreren Iterationen dargestellt. Die<br />
Knoten, die im Fixpunkt der Menge N 1 zugeordnet werden können, sind hierbei fett<br />
hervorgehoben, ebenso wie die Ähnlichkeitswerte, die im Fixpunkt, der sich nach 37<br />
Iterationen eingestellt hat, errechnet wurden.<br />
Betrachtet man die zugehörigen PCGs zu den Graphen, fällt auf, dass alle Knoten,<br />
die im Ergebnis der Menge N 1 zugeordnet werden konnten, bei den Graphen 1-6 in einer<br />
Zusammenhangskomponente (ZHK) des PCGs liegen. Nur beim Graphen 7 befinden<br />
sie sich in zwei ZHK, die aber aufgr<strong>und</strong> der strukturell identischen ZHK im Modell A<br />
ebenfalls strukturell identisch sind.<br />
Das Similarity Flooding scheint also aus den Zusammenhangskomponenten, die sich<br />
für den PCG ergeben, jeweils bestimmte auszuwählen, die für die Ergebnismenge relevant<br />
sind. Alle anderen ZHK werden im Laufe der Iterationen immer weniger relevant, was<br />
sich dadurch zeigt, dass die Ähnlichkeitswerte der Knoten daraus immer stärker gegen 0<br />
konvergieren. Die Anfangsähnlichkeiten der Knoten aus N 2 scheinen also im Laufe der<br />
49
Graph<br />
Fall<br />
1 2 3 4 5<br />
1 37 18 1 50 36<br />
2 109 17 5 164 110<br />
3 32 6 2 39 34<br />
4 130 35 28 209 127<br />
5 308 21 114 586 359<br />
6 37 29 41 61 37<br />
7 424 10 9 752 382<br />
Tabelle 7.4.: Anzahl der Iterationen bis zum Fixpunkt (Basis-Fixpunktformel)<br />
Iterationen immer mehr „verloren“ zu gehen, wobei zu vermuten ist, dass sie, lässt man<br />
das Similarity Flooding mit ɛ = 0 laufen, sogar vollständig verloren gehen.<br />
Bezüglich der Qualität der Ergebnisse lässt sich in Fall 1 Folgendes feststellen: Bei<br />
Graph 2 sind genau die Knoten, die als Matching-Kandidaten erwartet wurden, in der<br />
Menge N 1 im Ergebnis zu finden. Ebenso verhält es sich bei den Graphen 6 <strong>und</strong> 7. In der<br />
Stable Marriage zu Graph 2 <strong>und</strong> 6 sind alle erwarteten Matching-Kandidaten wiederzufinden.<br />
Bei Graph 6 werden dabei die 6 Knoten, die in der Menge N 1 sind, aber nicht<br />
zu den erwarteten Matching-Kandidaten gehören, herausgefiltert, bei Graph 2 werden<br />
zusätzlich weitere Knoten aus der Menge N 2 mit in die Stable Marriage aufgenommen,<br />
auch wenn deren Ähnlichkeitswerte nur sehr geringe absolute Werte annehmen.<br />
Bei Graph 7 liefert das Stable Marriage nur die Matching-Kandidaten aus der ZHK<br />
mit den Knoten ai, bj, ck <strong>und</strong> dl zurück. Da die Ähnlichkeitswerte der Knoten in der<br />
zweiten ZHK mit den Knoten ei, fj, gk <strong>und</strong> hl dieselben sind, ist das hier nur auf die<br />
Implementierung des Stable Marriage Algorithmus zurückzuführen.<br />
Bei den Graphen 1, 3, 4 <strong>und</strong> 5 lässt sich an dieser Stelle über die Qualität der Ergebnisse<br />
noch nicht viel aussagen, da erwartete Matching-Kandidaten nicht vorhanden<br />
sind. Die Ergebnisse werden erst in den folgenden Fällen relevant für Vergleiche werden.<br />
Bezüglich der Zahl der Iterationen, die benötigt werden, bis ein Fixpunkt erreicht wird,<br />
kann festgestellt werden, dass diese bei den einzelnen Graphen deutlich schwankt. Die<br />
an dieser Stelle nahe liegende Vermutung, dass die Anzahl der Iterationen von der Größe<br />
der Graphen abhängig ist, also mit zunehmender Knotenzahl auch mehr Iterationen bis<br />
zum Fixpunkt benötigt werden, kann hier widerlegt werden, denn Graph 6 benötigt bis<br />
zum Erreichen genauso wie Graph 1 37 Iterationen, obwohl seine Knotenzahl mit 60 (im<br />
Vergleich zu 6) deutlich größer ist.<br />
Die Anzahl der Iterationen pro Graph bis zum Erreichen des Fixpunktes für die<br />
einzelnen Fälle ist in Tabelle 7.4 dargestellt.<br />
Fall 2<br />
Mit dem 2. Fall soll überprüft werden, ob sich derselbe Fixpunkt wie in Fall 1 auch dann<br />
einstellt, wenn man nur noch einen Knoten mit einer Anfangsähnlichkeit versieht, <strong>und</strong><br />
50
wie sich das allgemein auf das Similarity Flooding auswirkt. Zu diesem Zweck wurde<br />
der Knoten (bzw. die Knoten, wenn es wie im Graphen 7 mehrere solcher Knoten gibt)<br />
mit dem höchsten Ähnlichkeitswert im Fixpunkt in Fall 1 ermittelt <strong>und</strong> dessen Anfangsähnlichkeit<br />
auf 1 gesetzt. Alle anderen Knoten bekamen eine Anfangsähnlichkeit von 0<br />
zugewiesen.<br />
Die mit diesen Einstellungen durchgeführten Experimente zeigen zunächst, dass sich<br />
bei allen Graphen der Fixpunkt nach – in einigen Fällen deutlich – weniger Iterationen<br />
einstellt als in Fall 1 (vgl. Tabelle 7.4). Die Knoten, die in Fall 1 in der Menge N 1<br />
waren, sind auch in Fall 2 in dieser Menge vorhanden. Die absoluten Werte weichen im<br />
Vergleich um maximal 0.003 ab, sodass man davon sprechen kann, dass sich in Fall 2<br />
derselbe Fixpunkt einstellt wie in Fall 1. Für die Knoten in der Menge N 2 fällt auf, dass<br />
im 2. Fall keiner dieser Knoten einen Ähnlichkeitswert ungleich 0 aufweist, während es<br />
in Fall 1 durchaus noch solche Werte gab.<br />
Betrachtet man die Entwicklung der Ähnlichkeitswerte über die Iterationen, ist festzustellen,<br />
dass sich die Ähnlichkeitswerte der N 2 -Knoten während des gesamten Ablaufs<br />
des Algorithmus nicht verändern, sondern konstant bei 0 bleiben.<br />
Zieht man hier die Beobachtung aus Fall 1 hinzu, dass das Similarity Flooding nur<br />
bestimmte Zusammenhangskomponenten auswählt, die im Fixpunkt relevante Matching-<br />
Kandidaten liefern, lassen sich die Ergebnisse wie folgt erklären: Dadurch, dass der einzige<br />
Anfangsähnlichkeitswert (bzw. die beiden Werte bei Graph 7) ungleich 0 in der bzw.<br />
den ZHK liegen, die in Fall 1 für die Ermittlung des Fixpunktes ausgewählt wurden,<br />
fließen in Fall 2 innerhalb dieser ZHK die Ähnlichkeitswerte solange, bis sie sich auf<br />
demselben Fixpunkt einpendeln wie in Fall 1. Da in den anderen ZHK alle Ähnlichkeitswerte<br />
zu Anfang auf 0 gesetzt wurden, können hier keine Ähnlichkeitswerte ungleich 0<br />
berechnet werden, weil keine Verbindung zu der bzw. den ZHK mit der Anfangsähnlichkeit<br />
von 1 existiert.<br />
Dass sich der Fixpunkt in Fall 2 nach weniger Iterationen als in Fall 1 einstellt, kann<br />
unter Berücksichtigung der Beobachtung, dass sich in Fall 1 die Werte der N 1 -Knoten<br />
während der letzten Iterationen vor Erreichen des Fixpunktes nicht bzw. kaum noch<br />
verändert haben, damit erklärt werden, dass durch das Wegfallen der positiven N 2 -<br />
Werte in Fall 2 keine „unnötigen“ Iterationen nötig sind, um diese auf nahezu konstante<br />
Werte zu bekommen. Führt man das auf PCGs zurück, bedeutet das, dass nur noch<br />
die Änderungen der Ähnlichkeitswerte in einer ZHK (bzw. 2 in Graph 7) dafür relevant<br />
sind, wann der Fixpunkt erreicht ist, <strong>und</strong> alle anderen ZHK nicht zu berücksichtigen<br />
sind. Dadurch werden besonders bei den Graphen, die viele Knoten besitzen, die der<br />
Menge N 2 zugeordnet werden, sehr viele Iterationen eingespart.<br />
Tabelle 7.5 stellt die Ähnlichkeitswerte analog zu Tabelle 7.3 für Fall 2 für den Graphen<br />
1 über mehrere Iterationen dar. Die Knoten, die der Menge N 1 zugeordnet werden<br />
können, sowie deren Ähnlichkeitswerte im Fixpunkt nach 18 Iterationen sind auch hier<br />
fett hervorgehoben.<br />
51
Knoten<br />
Iteration<br />
1 2 3 4 5 10 15 16 17 18<br />
(a, b) 1 1 1 1 1 1 1 1 1 1<br />
(a 1 , b) 0 0 0 0 0 0 0 0 0 0<br />
(a 1 , b 1 ) 0.5 0.5 0.5 0.471 0.446 0.392 0.384 0.384 0.383 0.383<br />
(a 1 , b 2 ) 0 0.25 0.375 0.471 0.541 0.682 0.704 0.705 0.706 0.706<br />
(a 2 , b 1 ) 0.5 0.5 0.625 0.706 0.77 0.901 0.921 0.922 0.923 0.923<br />
(a 2 , b 2 ) 0 0 0 0 0 0 0 0 0 0<br />
Tabelle 7.5.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1) für<br />
Fall 2<br />
Fall 3<br />
Im 3. Fall der Experimente zu den Anfangsähnlichkeiten soll die in den bisherigen Fällen<br />
gemachte Beobachtung, dass beim Similarity Flooding bestimmte Zusammenhangskomponenten<br />
der PCGs für die Ähnlichkeitswerte im Fixpunkt relevant sind <strong>und</strong> andere<br />
nicht, genauer überprüft werden. Dazu wurden hierfür die Anfangsähnlichkeiten aller<br />
Knoten, die in Fall 1 <strong>und</strong> 2 nicht in der Menge N 1 waren, auf 1 gesetzt, die der restlichen<br />
Knoten (also der N 1 -Knoten aus Fall 1 <strong>und</strong> 2) auf 0. Dadurch wird erreicht, dass<br />
in den Graphen die ZHK, denen in den vorherigen Fällen die N 1 -Knoten entstammten,<br />
komplett „ausgeblendet“ werden, wodurch zu erwarten ist, dass sich in Fall 3 deutlich<br />
andere Fixpunkte einstellen müssten.<br />
Die Experimente bestätigen diese Vermutung. Es fällt unmittelbar auf, dass wie erwartet<br />
keiner der Knoten, die in Fall 1 <strong>und</strong> 2 in der Menge N 1 waren, in Fall 3 noch<br />
dieser Menge zugeordnet werden können. Die Ähnlichkeitswerte aller dieser Knoten sind<br />
hier im Fixpunkt 0, <strong>und</strong> betrachtet man die Entwicklung der Werte über die Iterationen,<br />
ist festzustellen, dass wie erwartet auch keine anderen Werte als 0 angenommen werden.<br />
Die Knoten, die in Fall 3 im Fixpunkt überhaupt von 0 verschiedene Ähnlichkeitswerte<br />
haben, sind solche, die in Fall 1 <strong>und</strong> 2 in der Menge N 2 vorhanden waren. Betrachtet man<br />
die PCGs zu den Graphen, stellt man fest, dass bei Graph 1, 2, 3 <strong>und</strong> 7 alle Knoten aus<br />
der Ergebnismenge in den ZHK liegen, die in Fall 1 <strong>und</strong> 2 nicht berücksichtigt wurden.<br />
Die Menge N 1 in Fall 3 entspricht hier also genau der Menge N 2 aus Fall 1, die Menge<br />
N 2 der Menge N 1 aus Fall 1. Bei den Graphen 4, 5 <strong>und</strong> 6 sind nicht alle N 2 -Knoten aus<br />
Fall 1 <strong>und</strong> 2 in Fall 3 in der Menge N 1 , sondern nur eine Teilmenge davon. Interessant ist<br />
hierbei wieder, dass der Menge N 1 immer alle Knoten von bestimmten ZHK zugeordnet<br />
werden können. Es kommt niemals vor, dass einzelne Knoten einer ZHK der Menge N 1<br />
zugeordnet werden, andere derselben ZHK dagegen nicht.<br />
Zur Anzahl der Iterationen bis zum Fixpunkt (vgl. Tabelle 7.4) ist festzustellen, dass<br />
der Algorithmus in Fall 3 nur für Graph 5 <strong>und</strong> 6 mehr Iterationen benötigt als in Fall<br />
1, bei allen anderen Graphen weniger. Der Gr<strong>und</strong> dafür ist, dass die Graphen 5 <strong>und</strong> 6<br />
viele ZHK haben, die im Fixpunkt keine relevanten Ergebnisse liefern <strong>und</strong> deren Knoten<br />
somit der Menge N 2 zugeordnet werden können. Wie auch schon in Fall 1 beobachtet,<br />
52
Knoten Iteration<br />
1<br />
(a, b) 0<br />
(a 1 , b) 1<br />
(a 1 , b 1 ) 0<br />
(a 1 , b 2 ) 0<br />
(a 2 , b 1 ) 0<br />
(a 2 , b 2 ) 1<br />
Tabelle 7.6.: Ähnlichkeitswerte (Graph 1) für Fall 3<br />
stellen sich in Fall 3 für die Knoten aus N 1 schon nach wenigen Iterationen nahezu<br />
konstante Werte ein. In den folgenden Iterationen müssen die Ähnlichkeitswerte der N 2 -<br />
Knoten allerdings „neutralisiert“ werden, was die höhere Anzahl Iterationen im Vergleich<br />
zu beispielsweise Graph 1 erklärt, bei dem es neben der gezielt auf 0 gesetzten ZHK –<br />
welche die N 1 -Knoten in Fall 1 enthalten hat – keine weiteren ZHK mehr gibt, deren<br />
Knoten der Menge N 2 zugeordnet werden können <strong>und</strong> die demnach neutralisiert werden<br />
müssen.<br />
Bezüglich der Qualität der Testergebnisse in Fall 3 ist zu sagen, dass die im Fixpunkt<br />
gelieferten Matching-Kandidaten verglichen mit denen aus Fall 1 <strong>und</strong> 2 sehr schlecht sind.<br />
Allein bei Betrachtung des Graphen 6 stellt man fest, dass dort Matching-Kandidaten<br />
vorgeschlagen werden, die in den Modellen des Graphen objektiv gesehen quasi keine<br />
strukturellen Ähnlichkeiten aufweisen. Dieses Resultat ist nicht weiter verw<strong>und</strong>erlich,<br />
denn dadurch, dass für die Experimente in Fall 3 die ZHK „ausgeblendet“ wurden,<br />
welche die „guten“ Matching-Kandidaten enthalten, kann der Algorithmus hier nur vergleichsweise<br />
schlechte Ergebnisse liefern.<br />
Tabelle 7.6 stellt der Vollständigkeit halber die Ähnlichkeitswerte im Fixpunkt für<br />
den Graphen 1 in Fall 3 dar. Da sich der Fixpunkt hier bereits nach der 1. Iteration<br />
einstellt, ist keine Entwicklung der Ähnlichkeitswerte wie in Tabelle 7.3 oder Tabelle 7.5<br />
erkennbar. Analog zu diesen beiden Tabellen sind die Knoten aus der Menge N 1 <strong>und</strong> die<br />
Werte im Fixpunkt auch hier fett hervorgehoben.<br />
Fall 4<br />
In Fall 3 wurde nachgewiesen, dass sich durch gezieltes „Ausblenden“ von ganzen Zusammenhangskomponenten<br />
der PCGs der Graphen andere Fixpunkte erreichen lassen.<br />
Fall 4 stellt eine leichte Variation von Fall 3 dar <strong>und</strong> soll prüfen, ob <strong>und</strong> wie das Similarity<br />
Flooding größere „Störungen“ bei den Anfangsähnlichkeiten kompensieren kann.<br />
Dazu wurden in Fall 4 analog zu Fall 3 die Anfangsähnlichkeiten der Knoten, die in Fall<br />
1 <strong>und</strong> 2 in der Menge N 1 waren, auf 0 gesetzt, alle anderen auf 1. Im Unterschied zu<br />
Fall 3 wurde dann die Anfangsähnlichkeit des Knotens, der in Fall 1 den niedrigsten<br />
Wert (s min ) in der Menge N 1 aufwies, auf 1 gesetzt. Waren mehreren solcher Knoten<br />
vorhanden, wurde der genommen, der lexikographisch an letzter Stelle stand.<br />
53
Durch diese Einstellungen werden nicht wie in Fall 3 alle ZHK „ausgeblendet“, die<br />
in Fall 1 <strong>und</strong> 2 Knoten für N 1 geliefert haben. Da es zumindest in einer dieser ZHK<br />
noch einen Wert ungleich 0 gibt, hat der Similarity Flooding Algorithmus die Möglichkeit,<br />
auch für diese Ähnlichkeitswerte zu berechnen. Dabei stellt sich die Frage, ob sich<br />
derselbe Fixpunkt wie in Fall 1 <strong>und</strong> 2 einstellt, was dafür sprechen würde, dass das Similarity<br />
Flooding robust gegenüber „Störungen“ bei den Anfangsähnlichkeiten ist, oder ob<br />
sich derselbe Fixpunkt wie in Fall 3 einstellt, was für eine Störungsanfälligkeit sprechen<br />
würde.<br />
Die Experimente zeigen, dass sich bei den Graphen 1-6 in Fall 4 derselbe Fixpunkt wie<br />
in Fall 1 einstellt. Die absoluten Ähnlichkeitswerte der Knoten weichen lediglich minimal<br />
(im Bereich von 0.001) von denen in Fall 1 ab.<br />
Bei Graph 7 stellt sich dagegen ein auf den ersten Blick völlig anderer Fixpunkt als<br />
in allen bisherigen Fällen ein. Betrachtet man die Ergebnisse allerdings genauer, stellt<br />
man fest, dass der einzige Unterschied zu dem in Fall 1 erreichten Fixpunkt darin liegt,<br />
dass die Knoten der Zusammenhangskomponente {(ai), (bj), (bk), (cj), (ck), (dl)} in Fall<br />
4 alle Ähnlichkeitswerte von 0 aufweisen. Alle anderen Knoten im Graphen erreichen<br />
dieselben Ähnlichkeitswerte wie in Fall 1.<br />
Die Gründe für diesen Unterschied sind die Einstellungen der Anfangsähnlichkeiten<br />
für Fall 4 in Kombination mit der besonderen Struktur von Graph 7. Da im Vergleich<br />
zu Fall 3 bei Fall 4 nur einem weiteren Knoten ein Wert ungleich 0 zugewiesen wurde<br />
– in diesem Fall dem Knoten (gk) –, es in Graph 7 aber zwei ZHK gibt, die vorher<br />
„ausgeblendet“ wurden, gibt in Fall 4 nach wie vor eine ZHK, die nur Knoten mit<br />
Anfangsähnlichkeiten von 0 aufweist. Diese ZHK ist genau die oben genannte, bei der<br />
alle Knoten im Fixpunkt Ähnlichkeitswerte von 0 aufweisen.<br />
Setzt man in Fall 4 die Anfangsähnlichkeit des Knotens (ck), der in Fall 1 im Fixpunkt<br />
denselben Ähnlichkeitswert s min wie der Knoten (gk) aufwies, statt der von (gk) auf 1,<br />
stellt sich mit Ausnahme der ZHK {(ei), (fj), (fk), (gj), (gk), (hl)} derselbe Fixpunkt<br />
wie in Fall 1 ein. Setzt man die Anfangsähnlichkeiten von (ck) <strong>und</strong> (gk) auf 1, erreicht<br />
man, dass keine der beiden ZHK „ausgeblendet“ wird <strong>und</strong> man erhält exakt denselben<br />
Fixpunkt wie in Fall 1 – wie bei den Graphen 1-6 mit Unterschieden der absoluten Werte<br />
im Bereich von maximal 0.001.<br />
Allgemein lässt sich also feststellen, dass ein einziger positiver Wert in den ZHK, die<br />
in Fall 1 Knoten für N 1 geliefert haben, ausreicht, um in Fall 4 denselben Fixpunkt zu<br />
erreichen wie dort.<br />
Bezüglich der Anzahl der Iterationen (vgl. Tabelle 7.4) stellt man fest, dass das Similarity<br />
Flooding bei jedem getesteten Graphen in Fall 4 mehr Schritte bis zum Erreichen<br />
des Fixpunktes benötigt als in Fall 1. Das kann darauf zurückgeführt werden, dass es<br />
einige Schritte länger dauert, bis sich die Ähnlichkeitswerte der Knoten aus N 1 auf ihren<br />
festen Werten „eingependelt“ haben, <strong>und</strong> es anschließend wieder eine hohe Anzahl von<br />
Iterationen benötigt, bis die Werte der Knoten aus N 2 so weit neutralisiert wurden, dass<br />
gemäß dem Algorithmus das Erreichen eines Fixpunktes festgestellt werden kann.<br />
Tabelle 7.7 stellt die Entwicklung der Ähnlichkeitswerte über mehrere Iterationen<br />
am Beispiel von Graph 1 dar. Analog zu den Tabellen in den vorherigen Abschnitten<br />
sind die Knoten der Menge N 1 <strong>und</strong> deren Werte im Fixpunkt nach 50 Iterationen fett<br />
hervorgehoben.<br />
54
Knoten<br />
Iteration<br />
1 2 3 10 20 30 40 48 49 50<br />
(a, b) 0.5 0.5 0.5 0.831 1 1 1 1 1 1<br />
(a 1 , b) 1 1 1 1 0.301 0.072 0.017 0.006 0.005 0.004<br />
(a 1 , b 1 ) 0.5 0.375 0.313 0.336 0.383 0.383 0.383 0.383 0.383 0.383<br />
(a 1 , b 2 ) 0 0 0.063 0.539 0.706 0.707 0.707 0.707 0.707 0.707<br />
(a 2 , b 1 ) 0 0.125 0.188 0.723 0.923 0.924 0.924 0.924 0.924 0.924<br />
(a 2 , b 2 ) 1 1 1 1 0.301 0.072 0.017 0.006 0.005 0.004<br />
Tabelle 7.7.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1) für<br />
Fall 4<br />
Fall 5<br />
In Fall 5 wurden die Anfangsähnlichkeiten aller Knoten auf zufällige Werte im Intervall<br />
(0, 1] gesetzt. Dabei wurde dieser Fall als einziger mehrfach mit jeweils neuen Zufallswerten<br />
für die Anfangsähnlichkeiten durchgeführt, um allgemein über die Ergebnisse<br />
aussagen zu können.<br />
Nachdem in den bisherigen Fällen festgestellt wurde, dass das Similarity Flooding<br />
sehr robust gegenüber Störungen bei den Anfangsähnlichkeiten ist, ist anzunehmen, dass<br />
sich Zufallswerte nicht wesentlich auf den Fixpunkt auswirken, der erreicht wird. Nur<br />
bei Graph 7 könnte man aufgr<strong>und</strong> der Struktur vermuten, dass es hier zu Änderungen<br />
kommen könnte.<br />
Die Experimente bestätigen die Vermutung, dass bei den Graphen 1 bis 6 trotz Zufallswerten<br />
derselbe Fixpunkt erreicht wird wie in Fall 1. Lediglich die Anzahl der Iterationen<br />
(vgl. Tabelle 7.4) unterscheidet sich, wobei die Unterschiede in Fall 5 verglichen mit Fall<br />
1 wesentlich geringer ausfallen als etwa in Fall 4 verglichen mit Fall 1.<br />
Wie vermutet zeigen die Ergebnisse der Experimente auch, dass Graph 7 eine Ausnahme<br />
darstellt. Hier stellt sich, je nachdem, wie die Zufallswerte ausfallen, entweder<br />
ein Fixpunkt ein, der die Zusammenhangskomponente {(ai), (bj), (bk), (cj), (ck), (dl)}<br />
begünstigt – das heißt deren Knoten höhere absolute Ähnlichkeitswerte ausweisen –<br />
oder einer, der die ZHK {(ei), (fj), (fk), (gj), (gk), (hl)} begünstigt. Die Ähnlichkeitswerte<br />
der Knoten der begünstigten ZHK sind dieselben wie im Fixpunkt von Fall 1, alle<br />
anderen Werte unterscheiden sich von den dort ermittelten.<br />
Tabelle 7.8 stellt der Vollständigkeit halber die Entwicklung der Ähnlichkeitswerte<br />
über mehrere Iterationen am Beispiel von Graph 1 für Fall 5 dar.<br />
Zusammenfassung <strong>und</strong> Zwischenfazit<br />
Die in diesem Abschnitt durchgeführten Experimente haben einige interessante Eigenschaften<br />
des Similarity Flooding gezeigt. Es konnte ein Zusammenhang der Ergebnisse,<br />
die der Algorithmus liefert, mit den Zusammenhangskomponenten der PCGs der Testgraphen<br />
festgestellt werden. Offenbar sind nur bestimmte ZHK für die „relevanten“ Werte<br />
im Fixpunkt verantwortlich, während die Ähnlichkeitswerte der Knoten von allen an-<br />
55
Knoten<br />
Iteration<br />
1 2 3 10 15 20 30 34 35 36<br />
(a, b) 1 0.93 0.968 1 1 1 1 1 1 1<br />
(a 1 , b) 0.636 0.547 0.49 0.173 0.085 0.041 0.01 0.006 0.005 0.004<br />
(a 1 , b 1 ) 0.118 0.266 0.319 0.38 0.382 0.383 0.383 0.383 0.383 0.383<br />
(a 1 , b 2 ) 0.867 0.785 0.8 0.714 0.708 0.707 0.707 0.707 0.707 0.707<br />
(a 2 , b 1 ) 0.957 1 1 0.93 0.925 0.924 0.924 0.924 0.924 0.924<br />
(a 2 , b 2 ) 0.636 0.547 0.49 0.173 0.085 0.041 0.01 0.006 0.005 0.004<br />
Tabelle 7.8.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1) für<br />
Fall 5<br />
deren ZHK über die Iterationen hinweg immer stärker gegen 0 konvergieren <strong>und</strong> im<br />
Fixpunkt wenig aussagekräftige Matching-Kandidaten liefern.<br />
Außerdem konnte festgestellt werden, dass das Similarity Flooding relativ robust gegenüber<br />
veränderten Anfangsähnlichkeiten ist. Nur in Fall 3 konnte durch gezieltes „Ausblenden“<br />
kompletter ZHK des PCGs erreicht werden, dass sich ein anderer Fixpunkt<br />
einstellt. Der Fixpunkt, der sich dort eingestellt hat, liefert jedoch keine zufriedenstellenden<br />
Matching-Kandidaten. Nur in dem speziell konstruierten Beispiel von Graph 7<br />
konnte in Fall 4 <strong>und</strong> Fall 5 das Ergebnis durch die Anfangsähnlichkeiten so beeinflusst<br />
werden, dass von den zwei dort möglichen, gleich „guten“ Zuordnungen eine bevorzugt<br />
wurde.<br />
Abschließend lässt sich bezüglich der Anfangsähnlichkeiten festhalten, dass diese wie<br />
von den Autoren in [MGMR01] dargestellt die Ergebnisse des Similarity Flooding nicht<br />
wesentlich beeinflussen. Egal, ob nun gezielt potentiell gute Matching-Kandidaten mit<br />
hohen Anfangsähnlichkeiten belegt, Zufallswerte verwendet oder nur ein einziger Kandidat<br />
mit einem Wert belegt wurde, hatte auf die Ergebnisse keinerlei Einfluss, sondern<br />
lediglich auf die Anzahl der Iterationen, die bis zum Erreichen dieses Ergebnisses notwendig<br />
waren. Die Beeinflussungen, die in Fall 3 festgestellt werden konnten, können in<br />
realen Anwendungen als irrelevant angesehen werden, denn sie würden bedeuten, dass<br />
in einer Vorverarbeitungsphase des Algorithmus komplett falsche Anfangsähnlichkeiten<br />
(<strong>und</strong> vor allem Werte von 0 für eigentlich gute Matching-Kandidaten) berechnet werden<br />
müssten, was extrem unwahrscheinlich erscheint. Ebenso sind die Beeinflussungen, die<br />
an den Testergebnissen bei Graph 7 festgestellt werden konnten, vermutlich eher theoretisch<br />
relevant als in der Praxis. Dass es dort Fälle gibt, in denen zwei Modelle so gestaltet<br />
sind, dass eines der Modelle mit gleicher Wahrscheinlichkeit zu einem oder dem anderen<br />
Teil des zweiten Modells passt, scheint doch eher unwahrscheinlich.<br />
Bezogen auf die zu Beginn des Kapitels angesprochene Berechnung von Anfangsähnlichkeiten<br />
in der Vorverarbeitungsphase kann man sagen, dass die Ergebnisse der hier<br />
durchgeführten Experimente deren Nutzen in Frage stellen. Ob nun in einer Vorverarbeitungsphase<br />
Ähnlichkeiten berechnet <strong>und</strong> als Anfangsähnlichkeiten in den Algorithmus<br />
einbezogen werden oder ob direkt Zufallswerte oder konstante Werte ungleich 0 für die<br />
Ähnlichkeiten verwendet werden, wirkt sich offenbar nur darauf aus, wie lange der Al-<br />
56
gorithmus arbeiten muss, um zu einem Ergebnis zu kommen. Hier ist es sicherlich abzuwägen,<br />
ob der Aufwand einer Vorverarbeitung notwendig ist, die – mit etwas Glück – zu<br />
einer kürzeren Laufzeit des Algorithmus führt, oder ob gleich darauf verzichtet werden<br />
<strong>und</strong> die längere Laufzeit in Kauf genommen werden sollte. Zu besseren Ergebnisse führt<br />
die Vorverarbeitung – jedenfalls in den hier getesteten Beispielen – nicht.<br />
7.2.3. Verwendung einer anderen Fixpunktformel<br />
Die Fixpunktformel bestimmt, wie in jedem Schritt des Algorithmus die neuen Ähnlichkeitswerte<br />
bestimmt werden. In den Experimenten in Kapitel 7.2.2 wurde die Formel<br />
verwendet, die als Basis-Formel in Tabelle 4.3 in Kapitel 4.3 zu finden ist. Wie dort<br />
erwähnt sind daneben auch weitere Formeln für die Berechnungen der Ähnlichkeitswerte<br />
denkbar. In diesem Abschnitt soll statt der Basis-Formel die Formel A aus Tabelle 4.3<br />
verwendet werden. Danach gilt σ i+1 = normalize(σ 0 + ϕ(σ i )), das heißt im Schritt i+1<br />
berechnet sich die Ähnlichkeit zweier Knoten nicht wie in der Basis-Formel aus den<br />
Ähnlichkeitswerten des vorherigen Durchgangs (σ i ) <strong>und</strong> den neu berechneten Ähnlichkeitswerten<br />
(ϕ(σ i )), sondern aus den Anfangsähnlichkeiten (σ 0 ) <strong>und</strong> den neu berechneten<br />
Ähnlichkeitswerten. Hier soll nun die Frage geklärt werden, ob durch diese Berechnungsformel<br />
andere <strong>und</strong> unter Umständen bessere Ergebnisse erzielt werden können <strong>und</strong> ob<br />
mit der Formel eine gezielte Beeinflussung der Ergebnisse durch Ändern der Anfangsähnlichkeiten<br />
möglich ist, was in den Tests mit der Basis-Formel nicht möglich gewesen<br />
ist.<br />
Wie in Kapitel 7.2.2 wurden für die Experimente auch hier fünf verschiedenen Einstellungen<br />
in Form von fünf Fällen gewählt, deren Ergebnisse <strong>und</strong> Intentionen nachfolgend<br />
dargestellt werden.<br />
Fall 1 (Referenzfall)<br />
In Fall 1 wurden die Anfangsähnlichkeiten aller Knoten auf einen Wert von 1 gesetzt<br />
<strong>und</strong> das Testprogramm für jeden Graphen damit durchlaufen. Analog zu Fall 1 in Kapitel<br />
7.2.2 war hier zu erwarten, dass sich ein Fixpunkt in Abhängigkeit der Struktur der<br />
Graphen einstellt, auch wenn dieser aufgr<strong>und</strong> der anderen verwendeten Fixpunktformel<br />
unter Umständen anders aussieht als in Kapitel 7.2.2. Fall 1 soll auch hier als Referenzfall<br />
für die nachfolgenden Fälle dienen.<br />
Die Experimente zeigen zunächst, dass sich ein Fixpunkt bei allen Graphen schneller<br />
einstellt als mit der Basis-Fixpunktformel. Während zum Beispiel bei Graph 7 mit der<br />
Basis-Fixpunktformel 424 Iterationen benötigt wurden (vgl. Tabelle 7.4), benötigt die<br />
Fixpunktformel A nur 16 Iterationen. Die Anzahl der Iterationen bis zum Fixpunkt ist<br />
für die jeweiligen Fälle, die in diesem Kapitel relevant sind, in Tabelle 7.9 dargestellt.<br />
Bei den Ähnlichkeitswerten im Fixpunkt fällt auf, dass man hier nicht wie bei den<br />
Experimenten mit der Basis-Fixpunktformel Knoten nach ihren Werten in zwei Mengen<br />
einteilen kann. Vielmehr liegen die Werte alle deutlich näher zusammen <strong>und</strong> im Bereich<br />
von 0.3 <strong>und</strong> 1. Zur Verdeutlichung dieser Beobachtung <strong>und</strong> als Vergleich zu den in<br />
57
Graph<br />
Fall<br />
1 2 3 4 5<br />
1 10 44 10 15 14<br />
2 17 72 17 15 21<br />
3 14 79 14 16 17<br />
4 18 75 12 17 21<br />
5 18 69 14 18 15<br />
6 11 20 11 12 13<br />
7 16 35 15 10 10<br />
Tabelle 7.9.: Anzahl der Iterationen bis zum Fixpunkt (Fixpunktformel A)<br />
Knoten<br />
Iteration<br />
1 2 3 4 5 6 7 8 9 10<br />
(a, b) 1 1 1 1 1 1 1 1 1 1<br />
(a 1 , b) 0.67 0.714 0.667 0.674 0.665 0.667 0.665 0.666 0.665 0.666<br />
(a 1 , b 1 ) 0.5 0.643 0.583 0.607 0.596 0.601 0.599 0.6 0.599 0.6<br />
(a 1 , b 2 ) 0.67 0.786 0.75 0.764 0.759 0.761 0.76 0.761 0.76 0.761<br />
(a 2 , b 1 ) 0.83 0.929 0.889 0.91 0.9 0.905 0.902 0.904 0.903 0.903<br />
(a 2 , b 2 ) 0.67 0.714 0.667 0.674 0.665 0.667 0.665 0.666 0.665 0.666<br />
Tabelle 7.10.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1)<br />
für Fall 1<br />
Kapitel 7.2.2 ermittelten Werten sind in Tabelle 7.10 die Ähnlichkeitswerte der Knoten<br />
des Graphen 1 über mehreren Iterationen dargestellt.<br />
Die Ursache dafür, dass die Ähnlichkeitswerte im Fixpunkt sich nicht mehr so stark<br />
voneinander unterscheiden wie mit der Basis-Fixpunktformel, liegt darin, dass die hohe<br />
Anfangsähnlichkeit von 1 bei jeder Neuberechnung der Ähnlichkeitswerte mit einbezogen<br />
wird. Die Werte vor der Normalisierung sind in jeder Iteration aus diesem Gr<strong>und</strong><br />
größer als 1. Da die Maximalwerte der nicht normalisierten Ähnlichkeiten – mit wenigen<br />
Ausnahmen – bei Werten nicht größer als 3 liegen, sind hier nach der Normalisierung<br />
keine so kleinen Werte wie mit der Basis-Fixpunktformel möglich, wodurch auch der<br />
Wertebereich zusammenschrumpft <strong>und</strong> die Ähnlichkeitswerte näher zusammen liegen.<br />
Bezüglich der Qualität der Ergebnisse ist Folgendes festzustellen. Dadurch, dass die<br />
Werte so eng beieinander liegen, ist es besonders bei den größeren Graphen als Betrachter<br />
schwieriger, „gute“ Matching-Kandidaten aus der Ergebnismenge zu ermitteln.<br />
Deshalb ist das Stable Marriage als Filter sehr nützlich, um die Qualität der Ergebnisse<br />
besser analysieren zu können. Es fällt auf, dass sich die Matching-Kandidaten, die das<br />
Stable Marriage hier liefert, teilweise stark von denen unterscheiden, die mit der Basis-<br />
Fixpunktformel in Fall 1 geliefert wurden. So ist zum Beispiel bei Graph 7 im Stable<br />
Marriage mit Fixpunktformel A der Knoten (e, l) vorhanden, der bei Betrachtung der<br />
zugehörigen Modelle eher nicht als Matching-Kandidat zu erwarten gewesen wäre.<br />
58
Die Beobachtung, dass sich die Kandidaten in der Stable Marriage stark voneinander<br />
unterscheiden, kann aber nicht bei allen Graphen gemacht werden. Bei Graph 1<br />
<strong>und</strong> Graph 6 etwa sind die vorgeschlagenen Kandidaten dieselben, bei Graph 2 unterscheiden<br />
sie sich nur dadurch, dass statt der Knoten (7, 61) <strong>und</strong> (8, 62) wie mit der<br />
Basis-Fixpunktformel mit Fixpunktformel A die Knoten (7, 52) <strong>und</strong> (8, 53) im Ergebnis<br />
gewählt werden (vgl. dazu auch Abbildung A.6 in Anhang A). Bei Betrachtung<br />
der Modelle sind das durchaus potenzielle Kandidaten, auch wenn die mit der Basis-<br />
Fixpunktformel gewählten als „besser“ erscheinen.<br />
Fall 2<br />
In Fall 1 wurde festgestellt, dass die Ähnlichkeitswerte durch die hohe Anfangsähnlichkeit<br />
stark beeinflusst wurden. Für den 2. Fall wurden die Anfangsähnlichkeiten aus diesem<br />
Gr<strong>und</strong> zwar auch alle auf denselben Wert gesetzt, allerdings nicht auf 1, sondern auf<br />
0.1. Es ist zu vermuten, dass sich dadurch ein anderer Fixpunkt einstellt, weil die Anfangsähnlichkeiten<br />
die berechneten Ähnlichkeitswerte pro Iteration nicht mehr so stark<br />
beeinflussen wie in Fall 1 <strong>und</strong> somit die Struktur der Graphen <strong>und</strong> die Ähnlichkeiten<br />
der Nachbarknoten wieder mehr an Bedeutung gewinnen. Zu überprüfen ist hier auch,<br />
ob sich durch das Herabsenken der Anfangswerte ein Fixpunkt erreichen lässt, dessen<br />
Stable Marriage dieselben Ergebnisse liefert wie in Fall 1 mit der Basis-Fixpunktformel.<br />
Bei den Ergebnissen dieses Testdurchlaufs ist zunächst zu erkennen, dass die Anzahl<br />
der Iterationen in Fall 2 im Vergleich zu Fall 1 deutlich gestiegen ist (vgl. Tabelle 7.9).<br />
Die Ähnlichkeitswerte im Fixpunkt liegen nicht mehr so nah beieinander wie in Fall 1,<br />
die niedrigsten Werte liegen hier bei Graph 6 sogar unter 0.1.<br />
Zu den Ergebniswerten ist festzustellen, dass sich die Stable Marriages in Fall 2 bei<br />
den Graphen 2, 3, 4, 5 <strong>und</strong> 7 von denen in Fall 1 unterscheiden. Bei den Graphen 1 <strong>und</strong><br />
6 sind sie identisch. Vergleicht man die Kandidaten in den Stable Marriages mit denen,<br />
die in Fall 1 mit der Basis-Fixpunktformel erreicht wurden, erkennt man, dass bis auf in<br />
Graph 5 <strong>und</strong> 7 dieselben Stable Marriages erreicht wurden.<br />
Die gleichen vorgeschlagenen Matching-Kandidaten für die Graphen 1-4 <strong>und</strong> 6 deuten<br />
darauf hin, dass man durch Verringern des Einflusses der Anfangsähnlichkeiten<br />
mit Fixpunktformel A genau dieselben Ergebnisse erhalten kann wie mit der Basis-<br />
Fixpunktformel. Als Gr<strong>und</strong> dafür ist zu vermuten, dass, sobald sich die Anfangsähnlichkeiten<br />
nicht mehr so stark wie in Fall 1 auf die Berechnung der Ähnlichkeitswerte<br />
pro Iteration auswirken, die Struktur der Graphen bzw. die Ähnlichkeitswerte der Nachbarknoten<br />
die Ergebnisse wieder stärker beeinflusst <strong>und</strong> dadurch die Ergebnisse beider<br />
Fixpunktformeln wieder „ähnlicher“ werden.<br />
Diese Vermutung lässt sich erhärten, wenn man bei Graph 7, in dem mit Anfangsähnlichkeiten<br />
von 0.1 noch ein anderes Stable Marriage als in Fall 1 mit der Basis-<br />
Fixpunktformel geliefert wurde, die Werte weiter verringert. Setzt man beispielsweise<br />
die Anfangsähnlichkeiten auf 0.01 statt 0.1, stellt sich mit Fixpunktformel A dieselbe<br />
Stable Marriage wie dort ein. Kleine Anfangsähnlichkeiten scheinen also verglichen mit<br />
der Basis-Fixpunktformel ähnlichere Ergebnisse zu liefern als große.<br />
Bei Graph 5, in dem andere Matching-Kandidaten als mit der Basis-Fixpunktformel<br />
59
Knoten<br />
Iteration<br />
1 2 3 10 20 30 40 42 43 44<br />
(a, b) 0.3 0.5 0.8 1 1 1 1 1 1 1<br />
(a 1 , b) 0.2 0.3 0.4 0.257 0.233 0.232 0.232 0.232 0.231 0.232<br />
(a 1 , b 1 ) 0.15 0.25 0.35 0.423 0.421 0.42 0.419 0.419 0.419 0.419<br />
(a 1 , b 2 ) 0.2 0.35 0.55 0.708 0.708 0.707 0.707 0.707 0.707 0.707<br />
(a 2 , b 1 ) 0.25 0.45 0.7 0.921 0.916 0.914 0.914 0.913 0.913 0.913<br />
(a 2 , b 2 ) 0.2 0.3 0.4 0.257 0.233 0.232 0.232 0.232 0.231 0.232<br />
Tabelle 7.11.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1)<br />
für Fall 2<br />
vorgeschlagen werden, ist der Unterschied darauf zurückzuführen, dass in der Ergebnismenge<br />
dort viele Knoten mit Ähnlichkeitswerten von 0 aufgetreten sind, während mit<br />
Fixpunktformel A in Fall 2 alle Werte größer als 0 waren. Die vielen gleichen Werte<br />
führen zu einer anderen Stable Marriage als die sich unterscheidenden Werte mit Fixpunktformel<br />
A.<br />
Tabelle 7.11 stellt die Ähnlichkeitswerte des Graphen 1 für Fall 2 nach mehrere Iterationen<br />
dar. Hier ist im Vergleich zu Tabelle 7.10 der Unterschied in den Werten im<br />
Fixpunkt erkennbar.<br />
Fall 3<br />
Nachdem für Fall 1 <strong>und</strong> Fall 2 gleiche Anfangsähnlichkeiten verwendet wurden <strong>und</strong> nur<br />
die Auswirkungen unterschiedlicher Beträge untersucht wurde, soll mit Fall 3 geprüft<br />
werden, wie sich unterschiedliche Werte bei den Anfangsähnlichkeiten auf die Ergebnisse<br />
auswirken. Für diesen Fall wurden die Anfangsähnlichkeiten der Knoten, die in Fall 1<br />
mit der Basis-Fixpunktformel in Kapitel 7.2.2 der Menge N 1 zugeordnet werden konnten<br />
– die also dort die höchsten Werte angenommen haben – auf 1 gesetzt, alle anderen auf<br />
0.<br />
Die Idee dahinter ist es, zu versuchen, denselben Fixpunkt wie mit der Basis-Fixpunktformel<br />
zu erreichen. Da sich, wie in Fall 1 <strong>und</strong> 2 festgestellt, die Anfangsähnlichkeiten mit<br />
Fixpunktformel A wesentlich stärker auf die Ergebnisse auswirken, soll durch gezieltes<br />
Setzen von hohen Werten für die erwünschten Matching-Kandidaten erreicht werden,<br />
dass diese vom Algorithmus zurückgeliefert werden.<br />
Die Ergebnisse zeigen, dass die Zahl der Iterationen bis zum Fixpunkt verglichen mit<br />
Fall 2 bei Fall 3 wieder deutlich geringer ist (vgl. Tabelle 7.9). Die Ähnlichkeitswerte der<br />
Knoten im Fixpunkt lassen sich – analog zu den Werten mit der Basis-Fixpunktformel<br />
– anhand ihres Betrages in Mengen N 1 <strong>und</strong> N 2 aufteilen, wobei sich die auf diese Weise<br />
eingeteilten Mengen nicht von denen unterscheiden, die etwa in Fall 2 mit der Basis-<br />
Fixpunktformel erreicht wurden. Wie dort werden mit Fixpunktformel A in Fall 3 einige<br />
hohe Werte erreicht, deren Knoten alle in bestimmten Zusammenhangskomponenten des<br />
PCG liegen, während alle anderen Knoten Werte von 0 aufweisen.<br />
60
Knoten<br />
Iteration<br />
1 2 3 4 5 6 7 8 9 10<br />
(a, b) 1 1 1 1 1 1 1 1 1 1<br />
(a 1 , b) 0 0 0 0 0 0 0 0 0 0<br />
(a 1 , b 1 ) 0.5 0.643 0.583 0.607 0.596 0.601 0.599 0.6 0.599 0.6<br />
(a 1 , b 2 ) 0.667 0.786 0.75 0.764 0.759 0.761 0.76 0.761 0.76 0.761<br />
(a 2 , b 1 ) 0.833 0.929 0.889 0.91 0.9 0.905 0.902 0.904 0.903 0.903<br />
(a 2 , b 2 ) 0 0 0 0 0 0 0 0 0 0<br />
Tabelle 7.12.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1)<br />
für Fall 3<br />
Auch wenn die absoluten Werte der Knoten im Fixpunkt nicht dieselben sind wie<br />
mit der Basis-Fixpunktformel, lässt sich sagen, dass sich durch gezieltes Einstellen von<br />
Anfangsähnlichkeiten mit Fixpunktformel A derselbe Fixpunkt erreichen lässt. Tabelle<br />
7.12 stellt die Entwicklung der Ähnlichkeitswerte für Graph 1 für den Fall 3 bis zum<br />
Erreichen des Fixpunktes nach 10 Iterationen dar.<br />
Fall 4<br />
In Fall 3 wurde gezeigt, dass sich durch Einstellen von unterschiedlichen Anfangsähnlichkeiten<br />
der Fixpunkt aus Fall 1 aus Kapitel 7.2.2 erreichen lässt. In Fall 4 wurden dieselben<br />
Anfangsähnlichkeiten gewählt wie in Fall 4 mit der Basis-Fixpunktformel. Während sich<br />
dort derselbe Fixpunkt wie in Fall 3 einstellte, soll hier überprüft werden, ob das mit<br />
den Einstellungen auch mit Fixpunktformel A der Fall ist.<br />
Die Experimente führen zu dem Ergebnis, dass sich bei allen Graphen ein anderer<br />
Fixpunkt einstellt als in den Fällen 1 bis 3. Die Anzahl der Iterationen liegt dabei<br />
ähnlich wie bei Fall 1 <strong>und</strong> 3 zwischen 10 <strong>und</strong> 20 (vgl. Tabelle 7.9).<br />
Aus diesen Beobachtungen lässt sich folgern, dass der Einfluss der Anfangsähnlichkeiten<br />
auf die Ergebnisse, die das Similarity Flooding liefert, mit Fixpunktformel A deutlich<br />
größer ist als mit der Basis-Fixpunktformel. Während dort die Einstellungen in Fall 4<br />
nur zu demselben Fixpunkt geführt haben wie auch mit identischen Anfangsähnlichkeiten<br />
(wie in Fall 1), berechnet Fixpunktformel A in Fall 4 einen neuen Fixpunkt, der die<br />
Anfangsähnlichkeiten stärker berücksichtigt.<br />
Tabelle 7.13 stellt die Entwicklung der Ähnlichkeitswerte über die Iterationen für<br />
Graph 1 dar.<br />
Fall 5<br />
Im letzten hier durchgeführten Testdurchgang soll überprüft werden, wie sich das Similarity<br />
Flooding mit Fixpunktformel A bei zufälligen Anfangsähnlichkeiten verhält.<br />
Dazu wurden wie in Fall 5 in Kapitel 7.2.2 zufällige Werte im Intervall (0, 1] für die<br />
Anfangsähnlichkeiten festgelegt <strong>und</strong> der Fall mehrfach mit verschiedenen solcher Werte<br />
ausgeführt.<br />
61
Knoten<br />
Iteration<br />
1 2 3 4 5 10 12 13 14 15<br />
(a, b) 0.5 0.25 0.375 0.313 0.359 0.35 0.352 0.353 0.352 0.353<br />
(a 1 , b) 1 1 1 1 1 1 1 1 1 1<br />
(a 1 , b 1 ) 0.5 0.625 0.563 0.594 0.578 0.589 0.588 0.588 0.588 0.588<br />
(a 1 , b 2 ) 0 0 0.063 0.031 0.063 0.057 0.058 0.059 0.058 0.059<br />
(a 2 , b 1 ) 0 0.125 0.063 0.125 0.094 0.118 0.118 0.117 0.118 0.117<br />
(a 2 , b 2 ) 1 1 1 1 1 1 1 1 1 1<br />
Tabelle 7.13.: Entwicklung der Ähnlichkeitswerte über mehrere Iterationen (Graph 1)<br />
für Fall 4<br />
Wie anhand der bisherigen Testfälle zu erwarten war, stellen sich mit zufälligen Anfangsähnlichkeiten<br />
auch jeweils sehr unterschiedliche Fixpunkte ein. An dieser Stelle<br />
zeigt sich erneut, wie stark der Einfluss der Anfangsähnlichkeiten mit Fixpunktformel A<br />
auf die Ergebnisse ist.<br />
Zusammenfassung <strong>und</strong> Zwischenfazit<br />
Durch die in diesem Abschnitt durchgeführten Experimente konnten bedeutende Eigenschaften<br />
der Fixpunktformel A festgestellt werden. Die Anfangsähnlichkeiten haben hier<br />
starke Auswirkungen auf die Ergebnisse <strong>und</strong> sind somit essenziell wichtig für deren Qualität.<br />
Hohe Beträge bei den Anfangsähnlichkeiten lassen das Similarity Flooding schnell<br />
einen Fixpunkt erreichen, niedrige Beträge (wie in Fall 2) führen dazu, dass deutlich<br />
mehr Iterationen benötigt werden.<br />
Abschließend kann bezüglich der Fixpunktformel festgehalten werden, dass die Verwendung<br />
von Fixpunktformel A nur in Kombination mit einer Vorverarbeitung sinnvoll<br />
ist, in der Anfangsähnlichkeiten berechnet werden. Hier trifft die These der Autoren in<br />
[MGMR01], dass Anfangsähnlichkeiten die Ergebnisse wenig beeinflussen, nicht zu.<br />
7.2.4. Zusammenfassung<br />
In diesem Kapitel konnten zwei zentrale Aspekte des Similarity Floodings näher beleuchtet<br />
werden. Abschließend ist festzuhalten, dass die richtige Wahl der Fixpunktformel<br />
entscheidend sein kann, wenn es darum geht, die gewünschten Ergebnisse zu bekommen.<br />
Bei den Experimenten mit der Basis-Fixpunktformel führte alleine die Struktur der<br />
Graphen, die für die Tests verwendet wurden, dazu, dass sich bestimmte Fixpunkte eingestellt<br />
haben. Dabei waren Anfangsähnlichkeiten nahezu irrelevant, weil das Similarity<br />
Flooding diese im Laufe der Iterationen „ausgeglichen“ hat. Im konkreten Anwendungsfall<br />
bedeutet das, dass es mit der Formel wenig Möglichkeiten gibt, um Ähnlichkeiten, die<br />
nicht strukturell bedingt sind, in das Verfahren einfließen zu lassen. Möchte man etwa ein<br />
Knotenpaar, das strukturell sehr ähnlich ist, trotzdem nicht als Matching-Kandidat im<br />
Ergebnis erhalten, lässt sich das unter Verwendung der Basis-Fixpunktformel nicht durch<br />
62
Einstellen niedriger Anfangsähnlichkeiten für dieses Paar erreichen, sondern höchstens<br />
durch anschließendes Filtern der Ergebnisse.<br />
Anders verhält es sich mit Fixpunktformel A. Hier ist der Einfluss der Anfangsähnlichkeiten<br />
deutlich größer, der Einfluss der Struktur auf die Ergebnismenge deutlich<br />
geringer. Während man mit der Basis-Fixpunktformel auf eine Vorverarbeitung gänzlich<br />
verzichten kann, ist sie bei Fixpunktformel A notwendiger <strong>und</strong> nützlicher Bestandteil.<br />
Das eröffnet im Anwendungsfall deutlich mehr Möglichkeiten, denn im Gegensatz zur<br />
Basis-Fixpunktformel lassen sich die Fixpunkte durch die Anfangsähnlichkeiten beeinflussen.<br />
Das Similarity Flooding ist mit Fixpunktformel A somit wesentlich flexibler <strong>und</strong> praktikabler<br />
einsetzbar als mit der Basis-Fixpunktformel. Möchte man bestimmte Knotenpaare<br />
im Ergebnis „begünstigen“, kann man das durch Einstellungen an den Anfangsähnlichkeiten<br />
erreichen. Auch wenn man hier strukturell sehr unähnliche Knotenpaare<br />
durch hohe Anfangswerte begünstigt, schafft es der Algorithmus, einen Fixpunkt zu<br />
erreichen, der in Abhängigkeit davon andere Matching-Kandidaten vorschlägt.<br />
Über die Qualität der Fixpunkte, die sich mit der Fixpunktformel A <strong>und</strong> veränderten<br />
Anfangsähnlichkeiten einstellen, kann anhand der in diesem Kapitel verwendeten<br />
Graphen wenig gesagt werden. Auch wenn es – wie etwa bei Graph 6 – Erwartungen gegeben<br />
hat, welche Knotenpaare bezüglich ihrer Struktur mit hohen Ähnlichkeitswerten<br />
im Ergebnis auftreten müssten, reicht das nicht aus, um allgemein von „schlechten“ Ergebnissen<br />
zu sprechen, wenn durch Ändern der Anfangsähnlichkeiten andere Matching-<br />
Kandidaten vorgeschlagen werden. Schließlich möchte man durch diese Änderung das<br />
Ergebnis beeinflussen, sodass es durchaus denkbar ist, dass die Matching-Kandidaten,<br />
die sich daraus ergeben, im konkreten Anwendungsfall bessere Kandidaten sind als die,<br />
die sich rein von der Struktur ergeben hätte.<br />
Um die Qualität besser beurteilen zu können, sind Tests an konkreten Anwendungsfällen<br />
nötig, wie sie im folgenden Abschnitt durchgeführt werden sollen.<br />
7.3. Experimente an Relationalen Datenbankschemata<br />
Nachdem es in Kapitel 7.2 im Wesentlichen darum ging, die Arbeitsweise des Similarity<br />
Flooding <strong>und</strong> die Auswirkungen, die die Wahl der Fixpunktformel <strong>und</strong> die Festlegung<br />
der Anfangsähnlichkeiten auf das Verfahren haben, näher zu beleuchten, soll in diesem<br />
Kapitel die Qualität der Ergebnisse, die das Similarity Flooding liefert, im Vordergr<strong>und</strong><br />
stehen. Wie bereits angedeutet, lassen sich anhand von Graphen nur bedingt Aussagen<br />
über die Qualität des Verfahrens treffen. Aus diesem Gr<strong>und</strong> soll das Similarity Flooding<br />
in den folgenden Abschnitten auf konkrete Relationale Datenbankschemata angewandt<br />
werden, um dazu Aussagen treffen zu können.<br />
7.3.1. Experimentaufbau<br />
Auch wenn die Experimente in diesem Kapitel ähnlich ablaufen wie in Kapitel 7.2, gibt es<br />
einige wesentliche Unterschiede, auf die in den folgenden Abschnitten näher eingegangen<br />
werden soll.<br />
63
Abbildung 7.1.: 4 Fälle bei der Schema-Transformation<br />
Umwandlung von Schemata in Graphen<br />
Das Programm, mit dem die Tests durchgeführt wurden, entspricht wie in Kapitel 7.2<br />
dem in Kapitel 6 vorgestellten. Da hier statt Graphen Relationale Datenbankschemata<br />
als Eingabe dienen sollen, war es notwendig, eine Methode zu entwickeln, um diese Schemata<br />
in geeignete Graphen-Strukturen zu überführen. Für eine solche Transformation<br />
sind eine Reihe von Möglichkeiten denkbar, sie zu realisieren, die sich dadurch unterscheiden,<br />
welche Informationen der Schemata in welcher Form dargestellt werden.<br />
In [MGMR01] stellen die Autoren eine Methode dar, um eine solche Transformation<br />
durchzuführen, <strong>und</strong> führen sie anhand zweier Beispielschemata durch. Dabei werden<br />
sämtliche Informationen der Schemata in Form eigener Knoten <strong>und</strong> Kanten repräsentiert,<br />
was dazu führt, dass die auf diese Weise erzeugten Graphen vergleichsweise sehr groß<br />
sind. Für das eine der in [MGMR01] im Kapitel 2 verwendeten Beispielschemata mit einer<br />
Relation <strong>und</strong> vier Attributen wurden im Graphen auf diese Weise 31 Knoten benötigt,<br />
um es darzustellen, der Similarity Propagation Graph enthält sogar 211 Knoten.<br />
Im Rahmen dieser Arbeit sollen Experimente an größeren Schemata durchgeführt<br />
werden. Für die Transformation soll aus diesem Gr<strong>und</strong> eine andere Methode zur Transformation<br />
verwendet werden, die im Vergleich kleinere Graphen erzeugt, dabei aber<br />
trotzdem wesentliche Aspekte der Schemata berücksichtigt.<br />
Die Transformation der Schemata in Graphen geschieht dabei folgendermaßen: Für<br />
jede Relation wird ein Knoten mit ihrem Namen erzeugt. Attribute bekommen ebenfalls<br />
Knoten, die der besseren Übersichtlichkeit halber in der Form „Relationsname.Attributname“<br />
benannt werden. Relationsknoten werden durch Kanten mit den Attributknoten<br />
verb<strong>und</strong>en, wobei bei der Kantenmarkierung zwischen Fremdschlüsseln <strong>und</strong> sonstigen<br />
Attributen unterschieden wird. Kanten zu Fremdschlüsseln werden mit „has_foreign-<br />
_key“ markiert, die übrigen mit „has_attribute“. Fremdschlüsselknoten werden ihrerseits<br />
über eine Kante „references“ mit dem Relationsknoten verb<strong>und</strong>en, auf der der<br />
Fremdschlüssel verweist. Alle Attributknoten können außerdem noch Teil des Primärschlüssels<br />
sein, was durch eine Kante zu einem Spezialknoten „Primary Key“ dargestellt<br />
wird, die mit „constraints“ beschriftet ist.<br />
Abbildung 7.1 zeigt beispielhaft die vier möglichen Fälle a) - d) bei der Umwandlung<br />
64
eines Schemas in einen Graphen. Im Quellcode des Testprogramms ist die Transformation<br />
wie in Kapitel 6 angedeutet in der Methoden transform_2 realisiert.<br />
Für die Vorverarbeitung zur Berechnung der Anfangsähnlichkeiten, wie sie in Kapitel<br />
7.3.3 - Kapitel 7.3.4 durchgeführt wird, werden Namensvergleiche von Knoten als<br />
Gr<strong>und</strong>lage verwendet. Für Attribute wird dabei nur der Attributname verglichen, auch<br />
wenn der Knoten mit „Relationsname.Attributname“ benannt ist.<br />
Bei der Transformation in [MGMR01] wurden neben der Art der Attribute auch deren<br />
Datentyp berücksichtigt. Datentypen können beim Matching eine wichtige Rolle spielen,<br />
da sie zusätzliche Informationen liefern können, welche Attribute zweier Relationen zu<br />
matchen sind.<br />
Im Rahmen dieser Arbeit wurde darauf verzichtet, Datentypen bei der Transformation<br />
zu berücksichtigen. Der Gr<strong>und</strong> für diese Entscheidung ist, dass bei den hier verwendeten<br />
Schemata die Datentypen kaum neue Informationen liefern, die beim Matching helfen<br />
könnten. Stattdessen würden dadurch die Graphen nur wieder umfangreicher werden,<br />
worunter die Übersichtlichkeit im Rahmen der Experimente leiden würde.<br />
Was bei den hier verwendeten Beispielen sinnvoller als die Berücksichtigung von Datentypen<br />
ist, ist das Berücksichtigen von Domänenwissen. Damit sind Informationen<br />
gemeint, die in der Domäne, der die zu matchenden Schemata zugeordnet sind, bekannt<br />
sind. Zum Beispiel kann für eine Domäne bekannt sein, dass zwei Begriffe synonym verwendet<br />
werden, wodurch Informationen für das Matching zugänglich werden, die sonst<br />
nicht vorhanden sind. Domänenwissen ist somit noch mächtiger als die Berücksichtigung<br />
von Datentypen, kann allerdings nicht so einfach automatisch mit berücksichtigt werden.<br />
Bei den hier durchgeführten Experimenten wird Domänenwissen in Kapitel 7.3.4 <strong>und</strong> Kapitel<br />
7.3.5 in Form von Korrekturen berücksichtigt, die vor bzw. nach einem Durchlauf<br />
des Algorithmus an den automatisch berechneten Anfangsähnlichkeiten vorgenommen<br />
werden.<br />
Im Rahmen der Experimente wurde neben der hier geschilderten Variante zur Transformation<br />
der Schemata auch noch mit einer weiteren experimentiert. Im Testprogramm<br />
kann diese Variante ausgewählt werden. Die Ergebnisse damit fielen alle schlechter aus<br />
als mit der hier verwendeten Variante, sodass nicht weiter darauf eingegangen werden<br />
soll.<br />
Verwendete Fixpunktformel<br />
In Kapitel 7.2 konnte festgestellt werden, dass sich die Ergebnisse, die das Similarity<br />
Flooding mit der Basis-Fixpunktformel liefert, durch Setzen der Anfangsähnlichkeiten<br />
kaum beeinflussen lässt, dieses aber mit der Fixpunktformel A möglich ist. Deshalb<br />
sollen die Tests in diesem Abschnitt mit Fixpunktformel A durchgeführt werden, um<br />
Hintergr<strong>und</strong>informationen der Schemata in Form von Anfangsähnlichkeiten mit in die<br />
Experimente einfließen lassen zu können.<br />
65
Verwendete Schemata<br />
Für die Experimente in diesem Kapitel wurden acht verschiedene Schemata verwendet,<br />
von denen jeweils zwei zu einem Themenbereich gehören <strong>und</strong> entsprechend gematcht<br />
werden sollen. Diese sollen hier kurz erläutert werden. Die Schemata sowie ihre graphische<br />
Repräsentationen sind in Anhang B zu finden. Wie erwähnt wurden Datentypen<br />
hier weggelassen.<br />
1. Die ersten beiden zu matchenden Schemata sind unterschiedliche Darstellungen<br />
einer Musiksammlung. Schema 1 enthält dabei Informationen über CDs, Musikstücke<br />
<strong>und</strong> Interpreten sowie darüber. Schema 2 enthält zusätzlich Informationen<br />
über Produzenten <strong>und</strong> unterscheidet zwischen Alben <strong>und</strong> Samplern.<br />
Da es bei beiden Schemata um das Speichern einer Musiksammlung geht, gibt<br />
es hier eine Reihe von offensichtlichen Gemeinsamkeiten – etwa die Geburtsdaten<br />
in beiden INTERPRET-Relationen – <strong>und</strong> Unterschieden – etwa die Primärschlüssel<br />
der INTERPRET-Relationen der Schemata. Für die Experimente wesentlich<br />
interessanter sind allerdings die nicht-eindeutigen Punkte. So ließe sich<br />
die ENTHÄLT-Relation aus Schema 1 sowohl der ALBUMSONG- als auch der<br />
SAMPLERSONG-Relation aus Schema 2 sinnvoll zuordnen. Schema 1 ist also in<br />
Teilen eine Generalisierung von Schema 2, woraus sich für die Experimente die Frage<br />
ergibt, ob <strong>und</strong> wie das Similarity Flooding diese Generalisierung durch sinnvolle<br />
Matching-Kandidaten „ausdrücken“ kann.<br />
2. Die nächsten zu matchenden Schemata sind unterschiedliche Möglichkeiten, um Informationen<br />
über Reisen mit Bussen darzustellen. Die Schemata wurden dabei aus<br />
[IntDB10] entnommen. Schema 1 enthält Informationen über Städte, Busse, Tagestouren<br />
<strong>und</strong> darüber, wann welche Tour mit welchem Bus welche Stadt besucht.<br />
Schema 2 enthält zusätzlich weitere Informationen über die Fahrer der Busse, gibt<br />
aber keine Auskünfte darüber, welche Städte befahren werden, sondern nur, welche<br />
Länder.<br />
Schema 1 stellt extensional im Wesentlichen eine Teilmenge von Schema 2 dar,<br />
sodass in den Experimenten zu überprüfen ist, wie das Similarity Flooding damit<br />
umgeht <strong>und</strong> ob Matching-Kandidaten geliefert werden, die diese Teilmengen-<br />
Beziehung sinnvoll zum Ausdruck bringen.<br />
3. Bei den nächsten beiden Schemata handelt es sich um Informationen über Verlage.<br />
Schema 1 enthält Informationen über Autoren, Fotografen, Verlage, Artikel <strong>und</strong><br />
Zeitschriften sowie darüber, welche Artikel von welchem Autoren verfasst werden,<br />
welcher Fotograf Fotos dazu liefert <strong>und</strong> in welcher Zeitschrift welcher Artikel erscheint.<br />
Schema 2 enthält Informationen über Redakteure, freie Mitarbeiter <strong>und</strong><br />
Artikel <strong>und</strong> zusätzlich darüber, welche Gage ein Mitarbeiter für einen Artikel bekommt.<br />
Ähnlich wie bei den Musiksammlungs-Schemata sind hier Strukturen vorhanden,<br />
die bei einer Integration durch Generalisierungen gelöst werden müssten. FREI-<br />
66
ER_MITARBEITER aus Schema 2 kann zum Beispiel als Generalisierung zu AU-<br />
TOR <strong>und</strong> FOTOGRAF aus Schema 1 aufgefasst werden. Auch hier stellt sich<br />
also die Frage, wie das Similarity Flooding das in den Ergebnissen zum Ausdruck<br />
bringt. Zusätzlich gibt es weitere strukturelle Unterschiede – wie etwa die Relation<br />
VERLAG in Schema 1 im Vergleich zum Attribut Verlag in Schema 2 –, die der<br />
Algorithmus sinnvoll lösen sollte.<br />
4. Die letzten beiden Schemata gehören zum Bereich Filmdatenbank. Sie wurden<br />
beide [IntDB10] entnommen <strong>und</strong> stellen zwei Möglichkeiten dar, um Filminformationen<br />
zu speichern.<br />
Beide Schemata sind verglichen mit den anderen Schemata für die Experimente<br />
wesentlich komplexer. Außerdem weisen sie viele gleichartige Strukturen auf, die<br />
durch das Similarity Flooding gef<strong>und</strong>en werden sollten. Besonders hervorzuheben<br />
ist hier die Bedeutung von MOVIE in Schema 1 <strong>und</strong> PRODUCTION in Schema 2.<br />
Während MOVIE in Schema 1 die „zentrale“ Relation darstellt, auf die von nahezu<br />
jeder anderen Relation Fremdschlüssel verweisen, ist das in Schema 2 die Relation<br />
PRODUCTION.<br />
In den Experimenten ist zu erwarten, dass das Similarity Flooding aufgr<strong>und</strong> der<br />
vielen gemeinsamen Strukturen besonders gute Matching-Kandidaten liefert <strong>und</strong><br />
speziell auch die Korrespondenz zwischen MOVIE <strong>und</strong> PRODUCTION korrekt<br />
erkennt. Außerdem ist davon auszugehen, dass eine Filterung mit Hilfe der Stable<br />
Marriage hier als sinnvolle Eingrenzung der Ergebnisse möglich ist.<br />
7.3.2. Ergebnisse ohne Vorverarbeitung<br />
In dieser ersten Testreihe soll überprüft werden, welche Qualität die Ergebnisse des Similarity<br />
Flooding haben, wenn keinerlei Vorverarbeitung durchgeführt wird, sondern<br />
konstant gleiche Ähnlichkeitswerte verwendet werden. Dazu werden alle Anfangsähnlichkeitswerte<br />
auf 0.5 gesetzt. Dieser Wert wurde dabei gewählt, weil er dem mittleren<br />
Wert des möglichen Wertebereichs ist.<br />
Die Tabellen mit den Ergebniswerten zu den einzelnen Schemata sind in Tabelle C.1,<br />
Tabelle C.5, Tabelle C.1 <strong>und</strong> Tabelle C.13 in Anhang C abgedruckt.<br />
Bei den Ergebnissen fällt auf, dass die Ähnlichkeitswerte bis auf den Wert für (PRI-<br />
MARY KEY, PRIMARY KEY) in allen Beispielschemata relativ gering (zwischen 0.309<br />
<strong>und</strong> 0) sind. Qualitativ liefert das Similarity Flooding bei keinem der Schemata zufriedenstellende<br />
Ergebnisse. Zwar steht etwa das Map Pair (MOVIE, PRODUCTION) bei<br />
der Filmdatenbank mit 0.165 an zweiter Stelle bei den nach Ähnlichkeitswerten geordneten<br />
Ergebnissen, die übrigen Map Pairs stellen allerdings kaum sinnvolle Matchings dar.<br />
Das bestätigt die Beobachtung aus Kapitel 7.2.2, dass mit der gewählten Fixpunktformel<br />
nur mit Hilfe einer Vorverarbeitungsphase gute Ergebnisse erzielt werden können.<br />
67
7.3.3. Ergebnisse unter Ausnutzung von Namensgleichheiten von<br />
Relationen <strong>und</strong> Attributen<br />
In diesem Abschnitt soll die Qualität des Similarity Flooding bei Relationalen Datenbankschemata<br />
unter Ausnutzung von Namensgleichheiten in der Vorverarbeitungsphase<br />
ermittelt werden. Dabei wird die Anfangsähnlichkeit σ 0 eines Map Pairs (n i , n j ) nach<br />
folgender Formel festgelegt:<br />
σ 0 (n i , n j ) =<br />
{<br />
α, wenn s(ni , n j ) = 1<br />
0, sonst<br />
s(n i , n j ) überprüft dabei, ob der Name von n i als Teilwort im Namen von n j enthalten<br />
ist oder umgekehrt <strong>und</strong> liefert in diesem Fall den Wert 1 zurück, ansonsten<br />
den Wert 0. Groß- <strong>und</strong> Kleinschreibung wird dabei nicht berücksichtigt. Für die Knoten<br />
(Name, V ornamen) <strong>und</strong> (Nachname, Name) liefert s beispielsweise den Wert 1,<br />
was zu σ 0 (Name, V orname) = σ 0 (Nachname, Name) = α führt. Für den Knoten<br />
(V orname, Nachname) ergibt sich so s(V orname, Nachname) = 0 <strong>und</strong> entsprechend<br />
σ 0 (V orname, Nachname) = 0.<br />
Da die Ermittlung von Namensgleichheiten auch automatisch realisierbar ist, dient<br />
diese erste Testreihe dazu, zu überprüfen, wie ohne menschliches Einwirken die Ergebnisse<br />
bei den verschiedenen Schemata ausfallen. Ausschnitte der Tabellen mit den Ergebniswerten<br />
sind in Anhang C abgedruckt.<br />
Zunächst wird α = 1 gesetzt. Bei den Ergebnisse der Musiksammlungs-Schemata<br />
(vgl. Tabelle C.2) ist zu erkennen, dass das Similarity Flooding zwar einige recht gute,<br />
aber auch sehr viele schlechte Matching-Kandidaten vorschlägt. Die Kandidaten mit den<br />
größten Ähnlichkeitswerten sind ausschließlich die, die in der Vorverarbeitung Anfangsähnlichkeiten<br />
von 1 zugewiesen bekommen haben, was bedeutet, dass die Struktur der<br />
Graphen die Ergebnisse kaum beeinflusst, sondern eher die Anfangsähnlichkeiten. Dadurch<br />
lässt sich erklären, wieso zum Beispiel die ID von INTERPRET in Schema 1 als<br />
Matching-Kandidat mit der ID von PRODUZENT in Schema 2 mit hohem Ähnlichkeitswert<br />
vorgeschlagen wird, obwohl beide Relationen strukturell wenig Gemeinsamkeiten<br />
haben.<br />
Betrachtet man die ENTHÄLT-Relation aus Schema 1, die wie oben angesprochen<br />
bei einer Integration beider Schemata durch eine Generalisierung von ALBUMSONG<br />
<strong>und</strong> SAMPLERSONG aus Schema 2 umgesetzt werden müsste, ist schwer zu beurteilen,<br />
ob das Similarity Flooding hier Hinweise auf eine solche Generalisierung liefert oder<br />
nicht. Zwar werden die Attribute der ENTHÄLT-Relation mit nahezu identischen Ähnlichkeitswerten<br />
sowohl denen von ALBUMSONG als auch denen von SAMPLERSONG<br />
zugeordnet, da die absoluten Werte aber mit Beträgen um die 0.25 nahe bei den Werten<br />
der anderen Matching-Kandidaten liegen, die in der Vorverarbeitung einen Wert von 1<br />
zugewiesen bekommen haben, wird hier vermutlich eher die Vorverarbeitung <strong>und</strong> nicht<br />
die strukturelle Ähnlichkeit der Relationen für die Ergebnisse verantwortlich sein.<br />
Betrachtet man die Ergebnisse der Experimente der anderen Beispielschemata (vgl.<br />
Tabelle C.6, Tabelle C.10 <strong>und</strong> Tabelle C.14), wird schnell klar, dass die Wahl des Wertes<br />
68
1 für α in der Vorverarbeitung dazu führt, dass die Anfangsähnlichkeiten zu stark auf<br />
die Ergebnisse einwirken <strong>und</strong> die strukturellen Ähnlichkeiten nicht mehr ausreichend<br />
berücksichtigt werden können. Qualitativ gute Ergebnisse sind deshalb kaum möglich.<br />
Aus diesem Gr<strong>und</strong> wird im zweiten Teil dieses Abschnitts α = 0.25 gesetzt. Durch<br />
diese Veränderung ist zu erwarten, dass die Ähnlichkeitswerte relativ zu denen mit α = 1<br />
größer werden <strong>und</strong> der zu starke Einfluss der Anfangsähnlichkeiten abgeschwächt wird.<br />
Die Ergebnisse dazu werden in den folgenden Unterabschnitten behandelt, die Tabellen<br />
dazu sind in Anhang C zu finden.<br />
Musiksammlung<br />
Bei den Musiksammlung-Schemata (vgl. Tabelle C.3) zeigt sich, dass das Similarity<br />
Flooding mit α = 0.25 im Vergleich zu α = 1 nun nicht mehr ausschließlich Knoten,<br />
die Namensgleichheiten aufweisen, mit hohen Ähnlichkeitswerten liefert. Dennoch ist<br />
die Qualität der Ergebnisse bei Weitem nicht so gut wie erhofft. Die Zuordnung der<br />
INTERPRET-Relation aus Schema 1 zu der aus Schema 2 mit einem Ähnlichkeitswert<br />
von 0.373 ist zum Beispiel noch sinnvoll, die Zuordnung zu PRODUZENT bzw. ALBUM<br />
aus Schema 2 mit Ähnlichkeitswerten von 0.174 bzw. 0.173 dagegen nicht.<br />
Betrachtet man erneut die ENTHÄLT-Relation aus Schema 1, so wird diese nun immerhin<br />
mit vergleichsweise hohen Ähnlichkeitswerten als Matching-Kandidat für SAMP-<br />
LERSONG (0.283) <strong>und</strong> ALBUMSONG (0.23) vorgeschlagen. Auch wenn das eher als<br />
Hinweis auf eine mögliche Generalisierung bei der Integration der Schemata angesehen<br />
werden kann als mit α = 1, hätte man hier noch deutlichere Ergebnisse erwartet, die<br />
darauf hindeuten.<br />
Bustouren<br />
Das Similarity Flooding liefert auch hier keine qualitativ guten Werte (vgl. Tabelle C.7).<br />
Die höchsten Ähnlichkeitswerte erreichen die Knoten, die Namensgleichheiten aufweisen,<br />
wobei die Werte allgemein recht gering ausfallen. Der erste Ähnlichkeitswert bei einem<br />
Map Pair ohne Namensähnlichkeit fällt mit 0.098 bei BESUCHT <strong>und</strong> ZUGETEILT<br />
sehr niedrig aus, der Knoten ist außerdem kein anhand der Schemata zu erwartender<br />
Matching-Kandidat.<br />
Auf die Teilmengen-Beziehung, die zwischen den beiden Schemata existiert, liefert das<br />
Similarity Flooding keinerlei Hinweise.<br />
Verlag<br />
Bei den Verlag-Schemata (vgl. Tabelle C.11) ist positiv hervorzuheben, dass die AUTOR<strong>und</strong><br />
FOTOGRAF-Relationen aus Schema 1 mit relativ hohen Ähnlichkeitswerten der<br />
FREIER_MITARBEITER-Relation aus Schema 2 zugeordnet werden, obwohl keinerlei<br />
Namensgleichheiten zwischen den Schemata gef<strong>und</strong>en wurden. Aus den Ergebnissen<br />
lassen sich hier also Hinweise auf die Generalisierung erkennen, die bei der Integration<br />
nötig wäre.<br />
69
Ansonsten sind die Ergebnisse, die das Similarity Flooding liefert, zwar besser als in<br />
den anderen bisher getesteten Schemata, aber noch nicht optimal. Zuordnungen wie etwa<br />
vom Attribut Name der VERLAG-Relation aus Schema 1 zu Name der REDAKTEUR-<br />
Relation aus Schema 2 erscheinen mit vergleichsweise hoher Ähnlichkeit, von der Semantik<br />
der Schemata her sind sie jedoch kein sinnvoller Matching-Kandidat. Dagegen<br />
verstärken die gleichen Ähnlichkeiten bei der ID von LIEFERT_BILDER_FÜR <strong>und</strong><br />
SCHREIBT aus Schema 1 zu der ID von VERDIENT aus Schema 2 die Hinweise auf<br />
die Notwendigkeit der Generalisierung bei der Integration.<br />
Filmdatenbank<br />
Schaut man sich die Ergebnisse bei den Filmdatenbank-Schemata (vgl. Tabelle C.14) an,<br />
sind zunächst die sinnvollen Zuordnungen von LOCATION zu LOCATION, PERSON<br />
zu PERSON <strong>und</strong> MOVIE zu PRODUCTION mit hohen Ähnlichkeitswerten auffällig.<br />
Zwar sind auch Zuordnungen wie LOCATION aus Schema 1 zu PERSON aus Schema 2,<br />
PERSON zu LOCATION <strong>und</strong> MOVIE zu MOVIE mit relativ hohen Ähnlichkeitswerten<br />
aufgeführt, alle diese Relationen sind aber vorher schon mit höheren Ähnlichkeitswerten<br />
als Matching-Kandidaten für andere Relationen ausgegeben worden, was die Ergebnisse<br />
relativiert.<br />
Ermittelt man zu den Ähnlichkeitswerten die Stable Marriage, bekommt man relativ<br />
gute Ergebnisse. MOVIE aus Schema 1 wird korrekterweise PRODUCTION aus Schema<br />
2 zugeordnet, die Fremdschlüssel movie aus den Relationen in Schema 1, die auf MO-<br />
VIE verweisen, werden ebenfalls korrekt den entsprechenden production-Fremdschlüssel<br />
zugeordnet. Lediglich den Relationen, die ausschließlich in Schema 1 oder Schema 2 vorhanden<br />
sind, werden hier nicht sinnvolle Matching-Partner zugeordnet, abgesehen vom<br />
Attribut person der PART-Relation aus Schema 1 zu person der PARENTS-Relation<br />
aus Schema 2 sind die Ähnlichkeitswerte dabei allerdings nur sehr gering.<br />
7.3.4. Ergebnisse unter Ausnutzung von Namensgleichheiten von<br />
Relationen <strong>und</strong> Attributen mit manuellen Anpassungen<br />
In diesem Abschnitt soll überprüft werden, ob sich die Ergebnisse aus dem vorherigen<br />
Abschnitt mit α = 0.25 durch manuelle Anpassungen der Anfangsähnlichkeiten verbessern<br />
lassen. Dazu wurde die Testumgebung so entwickelt, dass nach der automatischen<br />
Vorverarbeitung, die identisch zu der in Kapitel 7.3.3 abläuft, der Benutzer die Möglichkeit<br />
hat, die vorberechneten Anfangsähnlichkeiten anzupassen <strong>und</strong> zu verändern.<br />
Da es sich bei den Anpassungen, die der Benutzer an den Berechnungen der Vorverarbeitung<br />
vornehmen wird, je nach Schema um individuelle handelt, wird in den nächsten<br />
Abschnitten auf die jeweils sinnvolle Anpassungen je Themenbereich der Schemata <strong>und</strong><br />
auf die Ergebnisse des Verfahrens mit diesen Anpassungen eingegangen. Gr<strong>und</strong>lage für<br />
die Auswahl der Knoten, deren Anfangsähnlichkeiten nach der Vorverarbeitung geändert<br />
werden, bildet dabei das Domänenwissen, über das ein Benutzer verfügt. Tabellen mit<br />
den Ergebnissen sind in Anhang C zu finden.<br />
70
Musiksammlung<br />
Bei den Musiksammlung-Schemata ist anzunehmen, dass ein Benutzer, auch wenn er<br />
wenig Kenntnisse über die Schemata besitzt, nur anhand der Bezeichner der Relationen<br />
<strong>und</strong> Attribute auf Basis des Wissens, das er über die Domäne besitzt, mehrere<br />
Anfangsähnlichkeiten, die in der Vorverarbeitung berechnet wurden, korrigieren würde.<br />
Für die Experimente wurden deshalb die Anfangsähnlichkeiten der Map Pairs (IN-<br />
TERPRET.ID, PRODUZENT.ID), (INTERPRET.Name, ALBUM.Albumname) sowie<br />
(INTERPRET.Name, PRODUZENT.Name) von 0.25 auf 0 gesetzt, da diese für einen<br />
Benutzer mit entsprechenden Kenntnissen über die Domäne keine geeigneten Matching-<br />
Kandidaten darstellen.<br />
Durch diese Anpassungen verbessert sich die Qualität der Ergebnisse, die das Similarity<br />
Flooding liefert, verglichen zum vorherigen Abschnitt (vgl. Tabelle C.4). So wird<br />
beispielsweise das Map Pair (INTERPRET, PRODUZENT), das offensichtlich kein guter<br />
Matching-Kandidat ist, nicht mehr mit relativ hoher Ähnlichkeit von 0.174 zurückgeliefert,<br />
sondern nur noch mit 0.015.<br />
Bustouren<br />
Bei den Bustouren wurden unter der Annahme, dass ein Benutzer anhand der Namen<br />
der Relationen <strong>und</strong> Attribute Korrekturen auf Basis seines Domänenwissens vornimmt,<br />
die Anfangsähnlichkeiten der Map Pairs (BESUCHT.Name, FAHRER.FName), (BE-<br />
SUCHT.Name, GEFAHREN_VON.FName), <strong>und</strong> (STADT.Name, FAHRER.FName) von<br />
0.25 auf 0 gesetzt. Diese Anpassungen erscheinen auch ohne weitere Kenntnisse der Schemata<br />
plausibel, weil die Relationen, deren Attribute hier als ähnlich erkannt werden,<br />
allein von den Namen her nichts miteinander zu tun zu haben scheinen.<br />
Diese Anpassungen führen dazu, dass die Ergebnisse minimal besser sind als vorher<br />
(vgl. Tabelle C.8). (BESUCHT.Name, FAHRER.FName) ist im Ergebnis beispielsweise<br />
mit einem Ähnlichkeitswert von 0 im Vergleich zu 0.091 nicht mehr als Matching-<br />
Kandidat in Betracht zu ziehen. Allgemein verbessern sich die Ergebnisse aber verglichen<br />
zu denen bei der Musiksammlung wesentlich weniger.<br />
Verlag<br />
Bei den Verlag-Schemata wurden nach demselben Schema wie zuvor drei Änderungen<br />
vorgenommen: Die Anfangsähnlichkeitswerte Map Pairs (VERLAG.Name, FREI-<br />
ER_MITARBEITER.MName), (VERLAG.Name, REDAKTEUR.Name) <strong>und</strong> (ZEIT-<br />
SCHRIFT.Titel, ARTIKEL.Titel) wurden von 0.25 auf 0 gesetzt.<br />
Auch hier führen die Anpassungen dazu, dass sich die Ergebnisse verbessern (vgl. Tabelle<br />
C.12). So wird zum Beispiel dem Map Pair (VERLAG, REDAKTEUR) jetzt nur<br />
noch ein Ähnlichkeitswert von 0 zugeordnet, obwohl er zuvor mit 0.099 noch vergleichsweise<br />
hoch war.<br />
71
Filmdatenbank<br />
Bei den Schemata zur Filmdatenbank lassen sich ohne nähere Kenntnisse über die Domäne<br />
bzw. die Schemata für einen Benutzer keinerlei sinnvolle Anpassungen vornehmen.<br />
Die Namen der Relationen <strong>und</strong> Attribute, die übereinstimmen, sind im Wesentlichen<br />
schon identisch, weitere Veränderungen der vorberechneten Anfangsähnlichkeitswerte<br />
erscheinen daher nicht sinnvoll.<br />
7.3.5. Ergebnisse einer iterierten Anwendung<br />
In diesem Abschnitt sollen die Ergebnisse, die das Similarity Flooding in Kapitel 7.3.4<br />
geliefert hat, als Gr<strong>und</strong>lage für die iterative Wiederholung dienen. Die Testumgebung<br />
bietet die Möglichkeit, nach Berechnung der Ergebnisse das Verfahren erneut zu starten,<br />
wobei vorher Knoten gewählt werden können, deren Anfangsähnlichkeiten für die Wiederholung<br />
gesetzt werden sollen. Dem Benutzer wird es damit ermöglicht, bestimmte<br />
Matching-Vorschläge auszuwählen <strong>und</strong> andere abzuwählen, um im nächsten Durchlauf<br />
des Verfahrens noch bessere Ergebnisse bekommen zu können.<br />
Basierend auf dem Domänenwissen wurden für die Experimente scheinbar geeignete<br />
Knoten für die nächste Iteration gewählt, offensichtlich ungeeignete abgewählt. Bei der<br />
Filmdatenbank wurden so zum Beispiel die Zuordnungen von LOCATION zu PERSON<br />
<strong>und</strong> PERSON zu LOCATION abgewählt.<br />
In allen vier getesteten Schemata ließen sich durch diese Anpassungen in der nächsten<br />
Iteration noch einmal bessere Ergebnisse erzielen als in Kapitel 7.3.4. Die Ähnlichkeitswerte<br />
der gewählten – also in den Augen des Benutzers relevanten – Knoten waren<br />
verglichen zu Kapitel 7.3.4 teilweise wesentlich höher, der Unterschied zwischen deren<br />
Ähnlichkeitswerten <strong>und</strong> denen der nicht gewählten Knoten deutlich ausgeprägter.<br />
Zu erwähnen ist allerdings, dass die Qualität der Ergebnisse für die Iterationen des<br />
Verfahrens hierbei viel stärker von der Auswahl durch den Benutzer <strong>und</strong> somit von<br />
seinem Wissen über die Domäne abhängig ist. Durch schlechte Wahl der Knoten für die<br />
nächste Iteration kann die Qualität hier stark leiden.<br />
Tabelle C.16 in Anhang C stellt beispielhaft die Ergebnisse der Filmdatenbank dar,<br />
wie sie nach der Iteration des Verfahrens aussehen. Die Ergebnisse des ersten Durchgangs<br />
wurden dabei mittels Stable Marriage gefiltert <strong>und</strong> die danach zugeordneten Knoten für<br />
die nächste Iteration als relevant ausgewählt. Manuell wurden zusätzlich die Knoten<br />
(PART, PARENTS) <strong>und</strong> (REMARK, PLAYS) auf Basis des Domänenwissens abgewählt.<br />
7.4. Zusammenfassung<br />
Wie die Experimente in diesem Kapitel gezeigt haben, ist das Similarity Flooding gr<strong>und</strong>sätzlich<br />
in der Lage, Matching-Kandidaten für zwei zu matchende Modelle zu ermitteln.<br />
An den Graphen in Kapitel 7.2 konnte festgestellt werden, dass die Wahl der Fixpunktformel<br />
bereits im Vorfeld den Einfluss der Anfangsähnlichkeiten auf die Ergebnisse mitbestimmt.<br />
Während bei der Basis-Fixpunktformel die Möglichkeit, Ergebnisse gezielt<br />
72
durch Festlegen von Anfangsähnlichkeiten zu beeinflussen, verloren geht, ist das mit der<br />
Fixpunktformel A möglich.<br />
Um die Qualität der Ergebnisse, die das Similarity Flooding liefert, an realen Beispielen<br />
zu überprüfen, wurden in Kapitel 7.3 Relationale Datenbankschemata als Eingabe für<br />
weitere Experimente verwendet. Hier hat sich gezeigt, dass ohne eine Vorverarbeitungsphase<br />
bei Verwendung der Fixpunktformel A keine guten Ergebnisse geliefert werden<br />
(vgl. Kapitel 7.3.2). Durch eine automatisierte Vorverarbeitung konnten in Kapitel 7.3.3<br />
bessere, wenn auch nach wie vor nicht optimale, Ergebnisse erzielt werden. Manuelle<br />
Anpassungen der vorberechneten Anfangsähnlichkeitswerte, wie sie in Kapitel 7.3.4<br />
vorgenommen wurden, konnten die Ergebnisse meist noch weiter verbessern, erfordern<br />
aber Kenntnisse über die Schemata bzw. die Domäne, in der sie angesiedelt sind, die<br />
nicht in jedem Fall wie in den hier verwendeten Beispielen allein anhand der Namen von<br />
Relationen <strong>und</strong> Attributen erkennbar sind.<br />
Die besten Resultate konnten in Kapitel 7.3.5 dadurch erzielt werden, dass aus den<br />
Ergebnissen des Ablauf des Similarity Flooding bestimmte Matching-Kandidaten gewählt<br />
<strong>und</strong> das Verfahren erneut ausgeführt wurde. Die Auswahl der Kandidaten muss<br />
dabei allerdings wie in Kapitel 7.3.4 manuell passieren, was Kenntnisse über die Domäne<br />
voraussetzt.<br />
73
8. Fazit <strong>und</strong> Ausblick<br />
Die Integration von <strong>Datenbanken</strong> <strong>und</strong> damit verb<strong>und</strong>en die Suche nach Matchings <strong>und</strong><br />
Matching-Verfahren sind Themen, die in Zukunft weiter an Bedeutung gewinnen werden.<br />
Graph-Matching-Verfahren haben dabei ein großes Potenzial, weil sie flexible Eingaben<br />
ermöglichen.<br />
Mit dem Similarity Flooding Algorithmus existiert ein interessantes Verfahren zum<br />
Graph Matching. Im Rahmen von Experimenten konnte in dieser Arbeit gezeigt werden,<br />
welche Möglichkeiten er bietet. Sie machen deutlich, dass ein Matching mit dem Similarity<br />
Flooding prinzipiell möglich ist <strong>und</strong> mit geeigneten Konfigurationen auch recht gute<br />
Ergebnisse liefert.<br />
Ebenso wird klar, dass hier noch eine Menge Potenzial für weitere Experimente <strong>und</strong><br />
Untersuchungen vorhanden ist, um das Verfahren zu einem allgemein geeigneten Werkzeug<br />
für Matchings zu machen. Im Folgenden soll ein Ausblick geliefert werden, welche<br />
Aspekte in welcher Form weiter zu untersuchen sind, bevor das abschließende Fazit gezogen<br />
wird.<br />
Ausblick auf zukünftige Untersuchungen<br />
Fixpunktformel<br />
Der erste im Rahmen weiterer Untersuchungen zu überprüfende Aspekt beim Similarity<br />
Flooding ist die Fixpunktformel. In den Experimenten in dieser Arbeit konnten zwei<br />
unterschiedliche Formeln verglichen werden, wie bereits erwähnt sind hier jedoch noch<br />
eine Reihe weiterer denkbar. Hier ist zu überprüfen, ob andere Formeln unter Umständen<br />
zu besseren Ergebnissen – vor allem beim Schema-Matching – führen. Ziel dabei sollte<br />
es sein, die Fixpunktformel zu ermitteln, die allgemein zu den besten Ergebnissen führt,<br />
wenn es eine solche Formel gibt, oder Bedingungen festzuhalten, unter denen eine Formel<br />
bessere Resultate produziert als eine andere.<br />
Vorverarbeitungsphase<br />
Hat man die geeignetste Formel gef<strong>und</strong>en, muss untersucht werden, ob sie die Ergebnisse<br />
durch Abwandlung der Vorverarbeitungsphase verbessern lassen. Hierbei ist – vor allem<br />
wenn man das Ziel einer Anwendung auf großen Datenmengen berücksichtigt – besonders<br />
die Frage nach der Automatisierbarkeit relevant. Wie die Experimente gezeigt haben,<br />
ist eine Automatisierung zumindest teilweise möglich, was dem Benutzer viel Aufwand<br />
ersparen kann. In dem Zusammenhang ist die Frage zu klären, ob sich Domänenwissen,<br />
wie es in der Vorverarbeitung in Kapitel 7.3.5 als manuell eingegebene Information durch<br />
74
den Benutzer berücksichtigt wurde, auch automatisch berücksichtigen lässt. Denkbar<br />
wären hier zum Beispiel eine Vorverarbeitung, die zum Teil auf domänenspezifischen<br />
Lexika <strong>und</strong> Thesauri basiert <strong>und</strong> daraus Anfangsähnlichkeiten ermittelt.<br />
Filterung der Ergebnisse<br />
Anschließend wäre die Filterung der Ergebnismenge näher zu untersuchen. Mit der Stable<br />
Marriage wurde im Rahmen dieser Arbeit ein möglicher Filter betrachtet, der aber nicht<br />
in jedem Fall geeignet ist. Ideal wäre es in diese Zusammenhang, wenn bereits anhand<br />
der Eingabewerte erkannt werden könnte, ob ein Filter geeignet ist oder nicht. Ob das<br />
möglich ist, wäre in Experimenten zu überprüfen.<br />
Ebenso stellt sich die Frage, welche Filter überhaupt geeignet sind, um die Ergebnismengen<br />
zu verkleinern. In Kapitel 4.4 wurden eine Reihe von Filtern vorgestellt. Diese<br />
müssten in weiteren Experimenten auf verschiedene Ergebnismengen des Similarity Flooding<br />
angewandt <strong>und</strong> verglichen werden, damit Aussagen darüber möglich sind, inwiefern<br />
ein Filter besser oder schlechter geeignet ist als ein anderer. Zusätzlich wäre auch hier<br />
interessant zu prüfen, ob bei bestimmten Eingaben bestimmte Filter besser geeignet sind<br />
als andere <strong>und</strong> ob das bereits an den Eingaben erkannt werden kann.<br />
Datenbankschemata als Eingabe<br />
Um das Similarity Flooding für Relationale Datenbankschemata einzusetzen, müssen<br />
auch hier noch einige Aspekte näher betrachtet werden. Zunächst ist die Transformation<br />
der Schemata in Graphen zu untersuchen. Zu überprüfen ist, ob andere Darstellungen<br />
der Schemata als Graphen zu allgemein besseren Ergebnisse führen als mit der im Rahmen<br />
dieser Arbeit verwendeten. Denkbar wäre es zum Beispiel, mehr Knoten für die<br />
Darstellung zu verwenden <strong>und</strong> so weniger Informationen in den Kantenmarkierungen zu<br />
speichern. Hier müssten also verschiedene Darstellungsweisen derselben Schemata experimentell<br />
verglichen werden, um so die optimale Transformation bzw. Darstellung der<br />
Schemata zu finden, sofern es eine solche gibt.<br />
Als nächstes wäre zu untersuchen, ob <strong>und</strong> wie Besonderheiten, die beim Matching der<br />
Schemata <strong>und</strong> deren Integration relevant sind, im Similarity Flooding zum Ausdruck<br />
gebracht werden können. Dazu gehören zum Beispiel Generalisierungen <strong>und</strong> Teilmengen-<br />
Beziehungen. Diese wurden in den Ergebnissen der Experimente bisher lediglich in Form<br />
von hohen Ähnlichkeitswerten erkannt. Hier ist zu überprüfen, ob es Möglichkeiten gibt,<br />
dass das Similarity Flooding solche Besonderheiten erkennt <strong>und</strong> entsprechend im Ergebnis<br />
kenntlich macht. Um das zu prüfen könnten etwa – wie bei der Vorverarbeitungsphase<br />
– domänenspezifische Lexika <strong>und</strong> Thesauri verwendet werden, um Ober- <strong>und</strong> Teilmengen<br />
zu ermitteln. Alternativ wäre zu klären, ob solche Beziehungen schon aus den Eingabe-<br />
Schemata zu erkennen sind.<br />
75
Fazit<br />
Abschließend ist zu sagen, dass sich gezeigt hat, dass Graph-Matching-Verfahren <strong>und</strong><br />
speziell das Similarity Flooding ein sehr komplexes Themengebiet sind, das sich nicht in<br />
allen Details im Rahmen dieser Arbeit thematisieren ließ. Dass das Similarity Flooding<br />
in einer Reihe anderer Verfahren – wie etwa SASMINT <strong>und</strong> COMA – Verwendung<br />
findet, zeigt nicht zuletzt, dass ihm eine gewissen Bedeutung bei der Integration von<br />
<strong>Datenbanken</strong> geschenkt wird. Die hier betrachteten Aspekte sowie die entwickelte Testumgebung<br />
können als Gr<strong>und</strong>lage für weitere Betrachtungen <strong>und</strong> Experimente mit dem<br />
Verfahren bei dem Versuch verstanden werden, es hin zu einem noch universelleren <strong>und</strong><br />
noch besser einsetzbaren Instrument zu entwickeln <strong>und</strong> dadurch Matchings in Zukunft<br />
weiter vereinfachen zu können.<br />
Ob sich das Similarity Flooding für das Matching kartographischer bzw. räumlicher<br />
Daten eignet, wird sich wohl erst in Zukunft zeigen, wenn weitere Untersuchungen dazu<br />
angestellt wurden. Gr<strong>und</strong>sätzlich dürften räumliche Daten als Eingabe zwar kein Problem<br />
darstellen, fraglich ist aber, ob sich Speicherbedarf <strong>und</strong> Laufzeit des Verfahrens bei<br />
großen Datenmengen in den Griff bekommen lassen <strong>und</strong> ob die Qualität der Ergebnisse<br />
zufriedenstellend ausfällt.<br />
76
Literaturverzeichnis<br />
[DMR02]<br />
[Dra93]<br />
[Gal06]<br />
[GS62]<br />
[IntDB10]<br />
[Kuh55]<br />
[LN07]<br />
[MBR01]<br />
Do, Hong hai, Melnik, Sergey <strong>und</strong> Rahm, Erhard: Comparison of Schema<br />
Matching Evaluations. In: In Proceedings of the 2nd Int. Workshop on Web<br />
Databases (German Informatics Society), Seiten 221–237, 2002.<br />
Drakos, Nikos: Text to Hypertext conversion with L A TEX2HTML. Baskerville,<br />
3(2):12–15, 1993.<br />
Gal, Avigdor: Why is Schema Matching Tough and What Can We Do About<br />
It SIGMOD Record, 35(4):2–5, 2006.<br />
Gale, David <strong>und</strong> Shapley, Lloyd S.: College admissions and the stability of<br />
marriage. The American Mathematical Monthly, 69(1):9–15, 1962.<br />
Praktische Informatik, FG <strong>Datenbanken</strong> <strong>und</strong> <strong>Informationssysteme</strong> Institut<br />
für: Übungen zu Integration von <strong>Datenbanken</strong> im WS 10/11. 2010.<br />
Kuhn, Harold W.: The Hungarian method for the assignment problem. Naval<br />
Research Logistics Quarterly, 2(1-2):83–97, 1955.<br />
Leser, Ulf <strong>und</strong> Naumann, Felix: Informationsintegration - Architekturen<br />
<strong>und</strong> Methoden zur Integration verteilter <strong>und</strong> heterogener Datenquellen.<br />
dpunkt.verlag, 2007.<br />
Madhavan, Jayant, Bernstein, Philip A. <strong>und</strong> Rahm, Erhard: Generic Schema<br />
Matching with Cupid. In: Proceedings of the 27th International Conference<br />
on Very Large Data Bases, VLDB ’01, Seiten 49–58, San Francisco,<br />
CA, USA, 2001. Morgan Kaufmann Pulishers Inc.<br />
[MGMR01] Melnik, Sergey, Garcia-Molina, Hector <strong>und</strong> Rahm, Erhard: Similarity Flooding:<br />
A Versatile Graph Matching Algorithm (Extended Technical Report).<br />
Technischer Bericht, Stanford University, 2001.<br />
[MRB03]<br />
[MZ98]<br />
Melnik, Sergey, Rahm, Erhard <strong>und</strong> Bernstein, Philip A.: Rondo: a programming<br />
platform for generic model management. In: Proceedings of the 2003<br />
ACM SIGMOD international conference on Management of data, SIGMOD<br />
’03, Seiten 192–204, New York, NY, USA, 2003. ACM.<br />
Milo, Tova <strong>und</strong> Zohar, Sagit: Using Schema Matching to Simplify Heterogeneous<br />
Data Translation. In: VLDB’98, Proceedings of 24rd International<br />
Conference on Very Large Data Bases, Seiten 122–133, 1998.<br />
77
[Rah11]<br />
[RB01]<br />
[Rip04]<br />
[Sch09]<br />
[SE05]<br />
[Tie03]<br />
[UA10]<br />
Rahm, Erhard: Towards Large-Scale Schema and Ontology Matching. In:<br />
Bellahsene, Zohra, Bonifati, Angela <strong>und</strong> Rahm, Erhard (Herausgeber): Schema<br />
Matching and Mapping, Data-Centric Systems and Applications, Seiten<br />
3–27. Springer Berlin Heidelberg, 2011, ISBN 978-3-642-16518-4.<br />
Rahm, Erhard <strong>und</strong> Bernstein, Philip A.: A survey of approaches to automatic<br />
schema matching. The VLDB Journal, 10:334–350, Dezember 2001.<br />
Ripperda, Nora: Graphbasiertes Matching in räumlichen <strong>Datenbanken</strong>. Diplomarbeit,<br />
Institut für <strong>Informationssysteme</strong>, Leibniz Universität Hannover,<br />
2004.<br />
Schäfers, Michael: Entwicklung eines ähnlichkeitsbasierten Frameworks für<br />
das Matching von Datenbankobjekten. Diplomarbeit, Institut für <strong>Informationssysteme</strong>,<br />
Leibniz Universität Hannover, 2009.<br />
Shvaiko, Pavel <strong>und</strong> Euzenat, Jérôme: A Survey of Schema-Based Matching<br />
Approaches. Journal of Data Semantics, 3730(4):146–171, 2005.<br />
Tiedge, Michael: Entwicklung <strong>und</strong> Implementierung einer topologischen Erweiterung<br />
für objektbasierte räumliche <strong>Datenbanken</strong>. Diplomarbeit, Institut<br />
für <strong>Informationssysteme</strong>, Leibniz Universität Hannover, 2003.<br />
Unal, Ozgul <strong>und</strong> Afsarmanesh, Hamideh: Semi-automated schema integration<br />
with SASMINT. Knowledge and Information Systems, 23:99–128, 2010.<br />
[Ull76] Ullmann, J. R.: An Algorithm for Subgraph Isomorphism. J. ACM, 23:31–42,<br />
January 1976, ISSN 0004-5411.<br />
78
A. Anhang – Für Experimente verwendete<br />
Graphen<br />
Anhang A enthält die in Kapitel 5 für die Experimente verwendeten Graphen. Näheres<br />
zu deren Struktur ist im entsprechenden Kapitel zu finden. Zur Verdeutlichung wurden<br />
bei den Graphen Knoten verschiedenartig dargestellt. Eine Erläuterung der Knotenarten<br />
ist in der folgenden Legende zu finden.<br />
Abbildung A.1.: Die unterschiedlichen Knoten der dargestellten Graphen<br />
79
A.1. Graph 1<br />
Abbildung A.2.: Graph 1: Modelle A (links) <strong>und</strong> B<br />
Abbildung A.3.: Graph 1: Pairwise Connectivity Graph<br />
80
A.2. Graph 2<br />
Abbildung A.4.: Graph 2: Modell A<br />
Abbildung A.5.: Graph 2: Modell B<br />
81
Abbildung A.6.: Graph 2: Pairwise Connectivity Graph<br />
82
A.3. Graph 3<br />
Abbildung A.7.: Graph 3: Modelle A (links) <strong>und</strong> B<br />
Abbildung A.8.: Graph 3: Pairwise Connectivity Graph<br />
83
A.4. Graph 4<br />
Abbildung A.9.: Graph 4: Modelle A (links) <strong>und</strong> B<br />
84
Abbildung A.10.: Graph 4: Pairwise Connectivity Graph<br />
85
A.5. Graph 5<br />
Abbildung A.11.: Graph 5: Modelle A (oben) <strong>und</strong> B<br />
86
Abbildung A.12.: Graph 5: Pairwise Connectivity Graph<br />
87
A.6. Graph 6<br />
Abbildung A.13.: Graph 6: Modelle A (oben) <strong>und</strong> B<br />
88
Abbildung A.14.: Graph 6: Pairwise Connectivity Graph<br />
89
A.7. Graph 7<br />
Abbildung A.15.: Graph 7: Modelle A (oben) <strong>und</strong> B<br />
90
Abbildung A.16.: Graph 7: Pairwise Connectivity Graph<br />
91
B. Anhang – Für Experimente verwendete<br />
Schemata<br />
B.1. Musiksammlung<br />
CD (Titel, Jahr, Länge, Typ)<br />
INTERPRET (ID, Name, Geburtsdatum)<br />
MUSIKSTÜCK (Interpret → INTERPRET, Titel, Genre, Länge)<br />
ENTHÄLT ((Titel, Jahr) → CD, (Interpret, Stück) → MUSIKSTÜCK)<br />
Abbildung B.1.: Schema 1<br />
INTERPRET (Künstlername, Geburtsdatum, Realname)<br />
PRODUZENT (ID, Name)<br />
TITEL (Künstlername → INTERPRET, Name, Sprache)<br />
ALBUM (Künstlername → INTERPRET, Albumname, Produzent → PRODUZENT, Genre)<br />
ALBUMSONG ((Künstlername, Titel) → TITEL, (Albuminterpret, Album) → ALBUM,<br />
TrackNr)<br />
SAMPLER (Name, Jahr, Volume, Produzent → PRODUZENT)<br />
SAMPLERSONG ((SName, SJahr, SVolume) → SAMPLER, (Interpret, Titel) → TITEL)<br />
Abbildung B.2.: Schema 2<br />
92
Abbildung B.3.: Graph zu Schema 1<br />
93
Abbildung B.4.: Graph zu Schema 2<br />
94
B.2. Bustouren<br />
STADT (Name, Highlight, Staat)<br />
TAGESTOUR (Tournr, Plätze, Preis, Datum, Fahrer)<br />
BUS (Busnr, Modell)<br />
BESUCHT (Name → STADT, Tournr → TAGESTOUR, Reihenfolge)<br />
MIT (Tournr → TAGESTOUR, Busnr → BUS)<br />
Abbildung B.5.: Schema 1<br />
STAAT (SName, Einreisedoktyp)<br />
TOUR (Tournr)<br />
BUS (Busnr, Plätze, Hersteller, Serie)<br />
FAHRER (FName, Alter)<br />
DATUM (Tag, Monat, Jahr)<br />
FÄHRT_DURCH (SName → STAAT, Tournr → TOUR)<br />
MIT (Tournr → TOUR, Busnr → BUS)<br />
GEFAHREN_VON (Busnr → BUS, FName → FAHRER)<br />
ZUGETEILT (Tournr → TOUR, FName → FAHRER, (Tag, Monat, Jahr) → DATUM)<br />
Abbildung B.6.: Schema 2<br />
95
Abbildung B.7.: Graph zu Schema 1<br />
96
Abbildung B.8.: Graph zu Schema 2<br />
97
B.3. Verlag<br />
AUTOR (ID, Name, Adresse)<br />
FOTOGRAF (ID, Name, Adresse, Ausrüstung)<br />
VERLAG (Name, Anschrift)<br />
ARTIKEL (Titel, Länge, Thema)<br />
ZEITSCHRIFT (Titel, Auflage, Preis, hrsg_von → VERLAG)<br />
SCHREIBT (ID → AUTOR, Titel → ARTIKEL)<br />
LIEFERT_BILDER_FÜR(ID → FOTOGRAF, Titel → ARTIKEL)<br />
ERSCHIENEN_IN (Titel → Artikel, Titel → ZEITSCHRIFT)<br />
Abbildung B.9.: Schema 1<br />
FREIER_MITARBEITER (PersonID, MName, Adresse, KontoNr)<br />
REDAKTEUR (Name, Verlag, Gehalt)<br />
ARTIKEL (Titel, Zeitschrift, Länge, Thema, verantw. → REDAKTEUR)<br />
VERDIENT (fM → FREIER_MITARBEITER, für → ARTIKEL, Gage)<br />
Abbildung B.10.: Schema 2<br />
98
Abbildung B.11.: Graph zu Schema 1<br />
99
Abbildung B.12.: Graph zu Schema 2<br />
100
B.4. Filmdatenbank<br />
MOVIE (movie, title, type, year, runningtime)<br />
PERSON (person, name, real name, sex, height, birth_date, birth_country, birth_location, death_date,<br />
death_country, death_location)<br />
PART (part, movie → MOVIE, person → PERSON, mentioned, creditpos)<br />
CHARACTER (part → PART, character)<br />
REMARK (part → PART, remark)<br />
LINK (movie1 → MOVIE, movie2 → MOVIE, link)<br />
LANGUAGE (movie → MOVIE, language)<br />
GENRE (movie → MOVIE, genre)<br />
KEYWORD (movie → MOVIE, keyword)<br />
COUNTRY (movie → MOVIE, country)<br />
LOCATION (movie → MOVIE, location, country)<br />
AKA (movie → MOVIE, country, aka)<br />
RELEASE (movie → MOVIE, country, release)<br />
RATING (movie → MOVIE, rating, votes)<br />
BUDGET (movie → MOVIE, budget, currency)<br />
QUOTE (movie → MOVIE, dialog, line, quote)<br />
Abbildung B.13.: MovieDB Schema 1<br />
PRODUCTION (production, title, runtime, year)<br />
MOVIE (production → PRODUCTION, type)<br />
SERIES (series, title, year)<br />
EPISODE (production → PRODUCTION, series → SERIES, season, episode, air_date)<br />
GENRE (production → PRODUCTION, genre)<br />
KEYWORD (production → PRODUCTION, keyword)<br />
COUNTRY (production → PRODUCTION, country)<br />
LOCATION (production → PRODUCTION, location, country)<br />
LANGUAGE (production → PRODUCTION, language)<br />
RELEASE (production → PRODUCTION, country, year, month, day)<br />
AKA (production → PRODUCTION, country, aka)<br />
QUOTE (production → PRODUCTION, dialog, line, quote)<br />
BUDGET (production → PRODUCTION, budget, currency)<br />
RATING (production → PRODUCTION, rating, votes)<br />
LINK (production1 → PRODUCTION, production2 → PRODUCTION, link)<br />
PERSON (person, name, real name, sex, height, birth_date, birth_country, birth_location, death_date,<br />
death_country, death_location)<br />
PARENTS (person → PERSON, mother → PERSON, father → PERSON)<br />
WORKS (person → PERSON, production → PRODUCTION, job, credit_pos)<br />
PLAYS (person → PERSON, production → PRODUCTION, role)<br />
Abbildung B.14.: MovieDB Schema 2<br />
101
Abbildung B.15.: Graph zu MovieDB Schema 1<br />
102
Abbildung B.16.: Graph zur Schema 2<br />
103
C. Tabellen zu Kapitel 7.3<br />
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
ENTHÄLT SAMPLERSONG 0.223<br />
ENTHÄLT ALBUMSONG 0.191<br />
CD SAMPLER 0.178<br />
CD INTERPRET 0.17<br />
MUSIKSTÜCK SAMPLER 0.163<br />
MUSIKSTÜCK ALBUM 0.158<br />
CD ALBUM 0.156<br />
CD PRODUZENT 0.156<br />
CD TITEL 0.155<br />
MUSIKSTÜCK TITEL 0.148<br />
MUSIKSTÜCK INTERPRET 0.147<br />
INTERPRET SAMPLER 0.143<br />
MUSIKSTÜCK PRODUZENT 0.141<br />
INTERPRET INTERPRET 0.139<br />
ENTHÄLT ALBUM 0.127<br />
INTERPRET ALBUM 0.125<br />
INTERPRET PRODUZENT 0.125<br />
INTERPRET TITEL 0.124<br />
MUSIKSTÜCK ALBUMSONG 0.118<br />
MUSIKSTÜCK SAMPLERSONG 0.103<br />
ENTHÄLT TITEL 0.095<br />
ENTHÄLT SAMPLER 0.094<br />
CD ALBUMSONG 0.092<br />
INTERPRET ALBUMSONG 0.085<br />
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.073<br />
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.073<br />
MUSIKSTÜCK.Interpret ALBUM.Produzent 0.071<br />
MUSIKSTÜCK.Interpret ALBUMSONG.Album 0.071<br />
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.071<br />
MUSIKSTÜCK.Interpret SAMPLER.Produzent 0.071<br />
ENTHÄLT.Jahr TITEL.Künstlername 0.07<br />
ENTHÄLT.Titel TITEL.Künstlername 0.07<br />
... ... ...<br />
Tabelle C.1.: Musiksammlung ohne Vorverarbeitung (0.5)<br />
104
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
INTERPRET INTERPRET 0.478<br />
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.268<br />
INTERPRET.Geburtsdatum INTERPRET.Geburtsdatum 0.261<br />
INTERPRET.Name INTERPRET.Künstlername 0.261<br />
INTERPRET.Name INTERPRET.Realname 0.261<br />
ENTHÄLT.Interpret ALBUMSONG.Albuminterpret 0.26<br />
MUSIKSTÜCK.Interpret SAMPLERSONG.Interpret 0.26<br />
ENTHÄLT.Jahr SAMPLERSONG.SJahr 0.257<br />
ENTHÄLT.Titel SAMPLERSONG.Titel 0.255<br />
INTERPRET.ID PRODUZENT.ID 0.255<br />
ENTHÄLT.Interpret SAMPLERSONG.Interpret 0.254<br />
ENTHÄLT.Titel ALBUMSONG.Titel 0.254<br />
INTERPRET.Name ALBUM.Albumname 0.254<br />
INTERPRET.Name PRODUZENT.Name 0.254<br />
MUSIKSTÜCK.Genre ALBUM.Genre 0.253<br />
CD.Jahr SAMPLER.Jahr 0.252<br />
INTERPRET.Name TITEL.Name 0.252<br />
CD.Jahr SAMPLERSONG.SJahr 0.25<br />
CD.Titel ALBUMSONG.Titel 0.25<br />
CD.Titel SAMPLERSONG.Titel 0.25<br />
ENTHÄLT.Jahr SAMPLER.Jahr 0.25<br />
INTERPRET.Name SAMPLER.Name 0.25<br />
MUSIKSTÜCK.Titel ALBUMSONG.Titel 0.25<br />
MUSIKSTÜCK.Titel SAMPLERSONG.Titel 0.25<br />
ENTHÄLT SAMPLERSONG 0.217<br />
MUSIKSTÜCK ALBUM 0.165<br />
ENTHÄLT ALBUMSONG 0.15<br />
INTERPRET ALBUM 0.142<br />
INTERPRET PRODUZENT 0.142<br />
CD SAMPLER 0.108<br />
INTERPRET TITEL 0.105<br />
MUSIKSTÜCK ALBUMSONG 0.079<br />
MUSIKSTÜCK SAMPLERSONG 0.076<br />
CD TITEL 0.073<br />
INTERPRET SAMPLER 0.071<br />
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.066<br />
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.063<br />
MUSIKSTÜCK TITEL 0.056<br />
MUSIKSTÜCK.Interpret ALBUM.Produzent 0.023<br />
... ... ...<br />
Tabelle C.2.: Musiksammlung mit Vorverarbeitung (1.0)<br />
105
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
INTERPRET INTERPRET 0.373<br />
ENTHÄLT SAMPLERSONG 0.283<br />
MUSIKSTÜCK ALBUM 0.269<br />
ENTHÄLT ALBUMSONG 0.23<br />
INTERPRET PRODUZENT 0.174<br />
INTERPRET ALBUM 0.173<br />
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.156<br />
ENTHÄLT.Interpret ALBUMSONG.Albuminterpret 0.146<br />
MUSIKSTÜCK.Interpret SAMPLERSONG.Interpret 0.136<br />
CD SAMPLER 0.132<br />
ENTHÄLT.Jahr SAMPLERSONG.SJahr 0.129<br />
INTERPRET.Geburtsdatum INTERPRET.Geburtsdatum 0.129<br />
INTERPRET.Name INTERPRET.Künstlername 0.129<br />
INTERPRET.Name INTERPRET.Realname 0.129<br />
ENTHÄLT.Interpret SAMPLERSONG.Interpret 0.126<br />
INTERPRET.ID PRODUZENT.ID 0.126<br />
ENTHÄLT.Titel ALBUMSONG.Titel 0.125<br />
ENTHÄLT.Titel SAMPLERSONG.Titel 0.125<br />
MUSIKSTÜCK.Genre ALBUM.Genre 0.125<br />
INTERPRET.Name ALBUM.Albumname 0.123<br />
INTERPRET.Name PRODUZENT.Name 0.123<br />
MUSIKSTÜCK ALBUMSONG 0.12<br />
INTERPRET TITEL 0.119<br />
INTERPRET.Name TITEL.Name 0.119<br />
CD.Jahr SAMPLER.Jahr 0.118<br />
INTERPRET.Name SAMPLER.Name 0.115<br />
CD.Jahr SAMPLERSONG.SJahr 0.113<br />
CD.Titel ALBUMSONG.Titel 0.113<br />
CD.Titel SAMPLERSONG.Titel 0.113<br />
ENTHÄLT.Jahr SAMPLER.Jahr 0.113<br />
MUSIKSTÜCK TITEL 0.113<br />
MUSIKSTÜCK.Titel ALBUMSONG.Titel 0.113<br />
MUSIKSTÜCK.Titel SAMPLERSONG.Titel 0.113<br />
MUSIKSTÜCK SAMPLERSONG 0.104<br />
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.1<br />
CD TITEL 0.096<br />
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.092<br />
INTERPRET SAMPLER 0.086<br />
MUSIKSTÜCK.Interpret ALBUM.Produzent 0.053<br />
... ... ...<br />
Tabelle C.3.: Musiksammlung mit Vorverarbeitung (0.25)<br />
106
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
INTERPRET INTERPRET 0.396<br />
ENTHÄLT SAMPLERSONG 0.302<br />
MUSIKSTÜCK ALBUM 0.27<br />
ENTHÄLT ALBUMSONG 0.249<br />
ENTHÄLT.Interpret ALBUMSONG.Albuminterpret 0.151<br />
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.143<br />
CD SAMPLER 0.142<br />
MUSIKSTÜCK.Interpret SAMPLERSONG.Interpret 0.141<br />
ENTHÄLT.Jahr SAMPLERSONG.SJahr 0.134<br />
INTERPRET.Geburtsdatum INTERPRET.Geburtsdatum 0.133<br />
INTERPRET.Name INTERPRET.Künstlername 0.133<br />
INTERPRET.Name INTERPRET.Realname 0.133<br />
ENTHÄLT.Interpret SAMPLERSONG.Interpret 0.13<br />
ENTHÄLT.Titel ALBUMSONG.Titel 0.129<br />
ENTHÄLT.Titel SAMPLERSONG.Titel 0.129<br />
INTERPRET TITEL 0.128<br />
MUSIKSTÜCK.Genre ALBUM.Genre 0.128<br />
MUSIKSTÜCK TITEL 0.126<br />
INTERPRET.Name TITEL.Name 0.123<br />
CD.Jahr SAMPLER.Jahr 0.122<br />
INTERPRET.Name SAMPLER.Name 0.118<br />
CD.Jahr SAMPLERSONG.SJahr 0.116<br />
CD.Titel ALBUMSONG.Titel 0.116<br />
CD.Titel SAMPLERSONG.Titel 0.116<br />
ENTHÄLT.Jahr SAMPLER.Jahr 0.116<br />
MUSIKSTÜCK.Titel ALBUMSONG.Titel 0.116<br />
MUSIKSTÜCK.Titel SAMPLERSONG.Titel 0.116<br />
MUSIKSTÜCK SAMPLERSONG 0.114<br />
MUSIKSTÜCK ALBUMSONG 0.11<br />
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.108<br />
CD TITEL 0.104<br />
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.101<br />
INTERPRET ALBUM 0.1<br />
INTERPRET SAMPLER 0.093<br />
ENTHÄLT.Interpret ALBUMSONG.Album 0.038<br />
ENTHÄLT.Stück ALBUMSONG.Album 0.038<br />
ENTHÄLT.Stück ALBUMSONG.Albuminterpret 0.038<br />
MUSIKSTÜCK.Interpret ALBUMSONG.Album 0.03<br />
MUSIKSTÜCK SAMPLER 0.028<br />
... ... ...<br />
Tabelle C.4.: Musiksammlung mit Vorverarbeitung (0.25) <strong>und</strong> manuellen Anpassungen<br />
107
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
TAGESTOUR BUS 0.261<br />
TAGESTOUR DATUM 0.226<br />
STADT BUS 0.181<br />
TAGESTOUR FAHRER 0.173<br />
TAGESTOUR STAAT 0.164<br />
BESUCHT ZUGETEILT 0.162<br />
MIT ZUGETEILT 0.161<br />
STADT DATUM 0.16<br />
BUS BUS 0.146<br />
TAGESTOUR TOUR 0.139<br />
BUS DATUM 0.134<br />
STADT FAHRER 0.129<br />
STADT STAAT 0.124<br />
BUS FAHRER 0.111<br />
BUS STAAT 0.107<br />
STADT TOUR 0.107<br />
BESUCHT FÄHRT_DURCH 0.106<br />
BESUCHT GEFAHREN_VON 0.106<br />
MIT FÄHRT_DURCH 0.106<br />
MIT GEFAHREN_VON 0.106<br />
BESUCHT MIT 0.105<br />
MIT MIT 0.105<br />
BESUCHT BUS 0.101<br />
BUS TOUR 0.099<br />
BESUCHT DATUM 0.092<br />
BESUCHT.Name FÄHRT_DURCH.SName 0.086<br />
BESUCHT FAHRER 0.084<br />
BESUCHT STAAT 0.084<br />
MIT.Busnr FÄHRT_DURCH.SName 0.084<br />
BESUCHT.Name GEFAHREN_VON.Busnr 0.082<br />
BESUCHT.Name MIT.Busnr 0.082<br />
BESUCHT.Tournr FÄHRT_DURCH.SName 0.08<br />
MIT.Tournr FÄHRT_DURCH.SName 0.08<br />
MIT.Busnr GEFAHREN_VON.Busnr 0.079<br />
MIT.Busnr MIT.Busnr 0.079<br />
BESUCHT.Name GEFAHREN_VON.FName 0.078<br />
BESUCHT.Tournr GEFAHREN_VON.Busnr 0.078<br />
BESUCHT.Tournr MIT.Busnr 0.078<br />
MIT.Tournr GEFAHREN_VON.Busnr 0.078<br />
... ... ...<br />
Tabelle C.5.: Bustouren ohne Vorverarbeitung (0.5)<br />
108
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
TAGESTOUR TOUR 0.339<br />
MIT MIT 0.268<br />
BUS BUS 0.267<br />
MIT.Busnr MIT.Busnr 0.222<br />
MIT.Busnr GEFAHREN_VON.Busnr 0.212<br />
MIT.Tournr MIT.Tournr 0.208<br />
BESUCHT.Name FÄHRT_DURCH.SName 0.199<br />
BESUCHT.Tournr FÄHRT_DURCH.Tournr 0.199<br />
BESUCHT.Tournr MIT.Tournr 0.198<br />
MIT.Tournr FÄHRT_DURCH.Tournr 0.198<br />
TAGESTOUR.Tournr TOUR.Tournr 0.198<br />
BESUCHT.Tournr ZUGETEILT.Tournr 0.197<br />
MIT.Tournr ZUGETEILT.Tournr 0.196<br />
BESUCHT.Name GEFAHREN_VON.FName 0.194<br />
BESUCHT.Name ZUGETEILT.FName 0.193<br />
BUS.Busnr BUS.Busnr 0.191<br />
STADT.Name FAHRER.FName 0.188<br />
STADT.Name STAAT.SName 0.187<br />
BESUCHT.Name FAHRER.FName 0.185<br />
BESUCHT.Name STAAT.SName 0.185<br />
BESUCHT.Tournr TOUR.Tournr 0.185<br />
BUS.Busnr GEFAHREN_VON.Busnr 0.185<br />
BUS.Busnr MIT.Busnr 0.185<br />
MIT.Busnr BUS.Busnr 0.185<br />
MIT.Tournr TOUR.Tournr 0.185<br />
STADT.Name FÄHRT_DURCH.SName 0.185<br />
STADT.Name GEFAHREN_VON.FName 0.185<br />
STADT.Name ZUGETEILT.FName 0.185<br />
TAGESTOUR.Tournr FÄHRT_DURCH.Tournr 0.185<br />
TAGESTOUR.Tournr MIT.Tournr 0.185<br />
TAGESTOUR.Tournr ZUGETEILT.Tournr 0.185<br />
TAGESTOUR.Plätze BUS.Plätze 0.184<br />
BESUCHT ZUGETEILT 0.076<br />
BESUCHT FÄHRT_DURCH 0.075<br />
STADT FAHRER 0.072<br />
STADT STAAT 0.054<br />
MIT GEFAHREN_VON 0.041<br />
MIT ZUGETEILT 0.04<br />
BESUCHT GEFAHREN_VON 0.038<br />
... ... ...<br />
Tabelle C.6.: Bustouren mit Vorverarbeitung (1.0)<br />
109
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
TAGESTOUR TOUR 0.277<br />
MIT MIT 0.2<br />
BUS BUS 0.194<br />
MIT.Busnr MIT.Busnr 0.143<br />
MIT.Busnr GEFAHREN_VON.Busnr 0.131<br />
MIT.Tournr MIT.Tournr 0.125<br />
BESUCHT.Name FÄHRT_DURCH.SName 0.121<br />
BESUCHT.Tournr FÄHRT_DURCH.Tournr 0.116<br />
BESUCHT.Tournr MIT.Tournr 0.112<br />
MIT.Tournr FÄHRT_DURCH.Tournr 0.112<br />
BESUCHT.Tournr ZUGETEILT.Tournr 0.111<br />
TAGESTOUR.Tournr TOUR.Tournr 0.111<br />
BESUCHT.Name GEFAHREN_VON.FName 0.11<br />
MIT.Tournr ZUGETEILT.Tournr 0.11<br />
BESUCHT.Name ZUGETEILT.FName 0.109<br />
BUS.Busnr BUS.Busnr 0.1<br />
BESUCHT ZUGETEILT 0.098<br />
STADT.Name FAHRER.FName 0.096<br />
STADT.Name STAAT.SName 0.095<br />
BESUCHT FÄHRT_DURCH 0.092<br />
BESUCHT.Name FAHRER.FName 0.091<br />
BESUCHT.Name STAAT.SName 0.091<br />
BESUCHT.Tournr TOUR.Tournr 0.091<br />
BUS.Busnr GEFAHREN_VON.Busnr 0.091<br />
BUS.Busnr MIT.Busnr 0.091<br />
MIT.Busnr BUS.Busnr 0.091<br />
MIT.Tournr TOUR.Tournr 0.091<br />
STADT.Name FÄHRT_DURCH.SName 0.091<br />
STADT.Name GEFAHREN_VON.FName 0.091<br />
STADT.Name ZUGETEILT.FName 0.091<br />
TAGESTOUR.Tournr FÄHRT_DURCH.Tournr 0.091<br />
TAGESTOUR.Tournr MIT.Tournr 0.091<br />
TAGESTOUR.Tournr ZUGETEILT.Tournr 0.091<br />
TAGESTOUR.Plätze BUS.Plätze 0.089<br />
STADT FAHRER 0.081<br />
STADT STAAT 0.062<br />
MIT GEFAHREN_VON 0.057<br />
MIT ZUGETEILT 0.057<br />
BESUCHT GEFAHREN_VON 0.049<br />
... ... ...<br />
Tabelle C.7.: Bustouren mit Vorverarbeitung (0.25)<br />
110
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
TAGESTOUR TOUR 0.304<br />
MIT MIT 0.218<br />
BUS BUS 0.211<br />
MIT.Busnr MIT.Busnr 0.154<br />
MIT.Busnr GEFAHREN_VON.Busnr 0.14<br />
MIT.Tournr MIT.Tournr 0.134<br />
BESUCHT.Name FÄHRT_DURCH.SName 0.13<br />
BESUCHT.Tournr FÄHRT_DURCH.Tournr 0.123<br />
BESUCHT.Tournr MIT.Tournr 0.119<br />
MIT.Tournr FÄHRT_DURCH.Tournr 0.119<br />
BESUCHT.Tournr ZUGETEILT.Tournr 0.118<br />
TAGESTOUR.Tournr TOUR.Tournr 0.118<br />
MIT.Tournr ZUGETEILT.Tournr 0.116<br />
BESUCHT ZUGETEILT 0.105<br />
BUS.Busnr BUS.Busnr 0.105<br />
BESUCHT FÄHRT_DURCH 0.104<br />
BESUCHT.Name ZUGETEILT.FName 0.104<br />
STADT.Name STAAT.SName 0.099<br />
BESUCHT.Name STAAT.SName 0.095<br />
BESUCHT.Tournr TOUR.Tournr 0.095<br />
BUS.Busnr GEFAHREN_VON.Busnr 0.095<br />
BUS.Busnr MIT.Busnr 0.095<br />
MIT.Busnr BUS.Busnr 0.095<br />
MIT.Tournr TOUR.Tournr 0.095<br />
STADT.Name FÄHRT_DURCH.SName 0.095<br />
STADT.Name GEFAHREN_VON.FName 0.095<br />
STADT.Name ZUGETEILT.FName 0.095<br />
TAGESTOUR.Tournr FÄHRT_DURCH.Tournr 0.095<br />
TAGESTOUR.Tournr MIT.Tournr 0.095<br />
TAGESTOUR.Tournr ZUGETEILT.Tournr 0.095<br />
TAGESTOUR.Plätze BUS.Plätze 0.093<br />
STADT STAAT 0.069<br />
MIT GEFAHREN_VON 0.064<br />
MIT ZUGETEILT 0.063<br />
BESUCHT MIT 0.055<br />
MIT FÄHRT_DURCH 0.054<br />
TAGESTOUR BUS 0.054<br />
MIT.Tournr MIT.Busnr 0.028<br />
STADT FAHRER 0.025<br />
... ... ...<br />
Tabelle C.8.: Bustouren mit Vorverarbeitung (0.25) <strong>und</strong> manuellen Anpassungen<br />
111
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
FOTOGRAF ARTIKEL 0.309<br />
FOTOGRAF FREIER_MITARBEITER 0.308<br />
ZEITSCHRIFT ARTIKEL 0.268<br />
ARTIKEL ARTIKEL 0.267<br />
ARTIKEL FREIER_MITARBEITER 0.267<br />
FOTOGRAF REDAKTEUR 0.266<br />
AUTOR ARTIKEL 0.255<br />
AUTOR FREIER_MITARBEITER 0.254<br />
ARTIKEL REDAKTEUR 0.25<br />
ZEITSCHRIFT FREIER_MITARBEITER 0.25<br />
AUTOR REDAKTEUR 0.225<br />
ZEITSCHRIFT REDAKTEUR 0.216<br />
VERLAG ARTIKEL 0.21<br />
VERLAG FREIER_MITARBEITER 0.21<br />
VERLAG REDAKTEUR 0.182<br />
ZEITSCHRIFT VERDIENT 0.161<br />
LIEFERT_BILDER_FÜR VERDIENT 0.159<br />
SCHREIBT VERDIENT 0.156<br />
ERSCHIENEN_IN.Titel VERDIENT.für 0.153<br />
ERSCHIENEN_IN.Titel VERDIENT.fM 0.15<br />
ERSCHIENEN_IN.Titel ARTIKEL.verantw. 0.146<br />
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.139<br />
LIEFERT_BILDER_FÜR.ID VERDIENT.für 0.139<br />
FOTOGRAF VERDIENT 0.136<br />
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.133<br />
ERSCHIENEN_IN VERDIENT 0.13<br />
SCHREIBT.ID VERDIENT.fM 0.13<br />
SCHREIBT.ID VERDIENT.für 0.13<br />
SCHREIBT.ID ARTIKEL.verantw. 0.126<br />
ARTIKEL VERDIENT 0.123<br />
AUTOR VERDIENT 0.123<br />
ZEITSCHRIFT.hrsg_von VERDIENT.fM 0.12<br />
ZEITSCHRIFT.hrsg_von VERDIENT.für 0.12<br />
LIEFERT_BILDER_FÜR ARTIKEL 0.119<br />
SCHREIBT ARTIKEL 0.118<br />
ZEITSCHRIFT.hrsg_von ARTIKEL.verantw. 0.113<br />
VERLAG VERDIENT 0.11<br />
ERSCHIENEN_IN ARTIKEL 0.104<br />
LIEFERT_BILDER_FÜR.Titel ARTIKEL.verantw. 0.104<br />
... ... ...<br />
Tabelle C.9.: Verlag ohne Vorverarbeitung (0.5)<br />
112
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
ARTIKEL ARTIKEL 0.495<br />
ARTIKEL.Titel ARTIKEL.Titel 0.267<br />
ARTIKEL.Länge ARTIKEL.Länge 0.264<br />
ARTIKEL.Thema ARTIKEL.Thema 0.264<br />
AUTOR.ID FREIER_MITARBEITER.PersonID 0.261<br />
ERSCHIENEN_IN.Titel ARTIKEL.Titel 0.26<br />
FOTOGRAF.ID FREIER_MITARBEITER.PersonID 0.26<br />
VERLAG.Name REDAKTEUR.Name 0.26<br />
AUTOR.Adresse FREIER_MITARBEITER.Adresse 0.258<br />
AUTOR.Name FREIER_MITARBEITER.MName 0.258<br />
ZEITSCHRIFT.Titel ARTIKEL.Titel 0.258<br />
FOTOGRAF.Adresse FREIER_MITARBEITER.Adresse 0.257<br />
FOTOGRAF.Name FREIER_MITARBEITER.MName 0.257<br />
LIEFERT_BILDER_FÜR.ID FREIER_MITARBEITER.PersonID 0.256<br />
LIEFERT_BILDER_FÜR.Titel ARTIKEL.Titel 0.256<br />
SCHREIBT.ID FREIER_MITARBEITER.PersonID 0.256<br />
SCHREIBT.Titel ARTIKEL.Titel 0.256<br />
VERLAG.Name FREIER_MITARBEITER.MName 0.256<br />
AUTOR.Name REDAKTEUR.Name 0.255<br />
FOTOGRAF.Name REDAKTEUR.Name 0.255<br />
AUTOR FREIER_MITARBEITER 0.214<br />
FOTOGRAF FREIER_MITARBEITER 0.214<br />
ZEITSCHRIFT ARTIKEL 0.08<br />
AUTOR REDAKTEUR 0.076<br />
FOTOGRAF REDAKTEUR 0.076<br />
VERLAG REDAKTEUR 0.076<br />
VERLAG FREIER_MITARBEITER 0.074<br />
ERSCHIENEN_IN.Titel VERDIENT.für 0.071<br />
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.059<br />
SCHREIBT.ID VERDIENT.fM 0.059<br />
LIEFERT_BILDER_FÜR.Titel VERDIENT.für 0.047<br />
SCHREIBT.Titel VERDIENT.für 0.047<br />
LIEFERT_BILDER_FÜR VERDIENT 0.03<br />
SCHREIBT VERDIENT 0.03<br />
ERSCHIENEN_IN VERDIENT 0.021<br />
ZEITSCHRIFT.hrsg_von ARTIKEL.verantw. 0.021<br />
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.02<br />
SCHREIBT.ID ARTIKEL.verantw. 0.02<br />
ZEITSCHRIFT.hrsg_von VERDIENT.fM 0.019<br />
... ... ...<br />
Tabelle C.10.: Verlag mit Vorverarbeitung (1.0)<br />
113
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
ARTIKEL ARTIKEL 0.409<br />
AUTOR FREIER_MITARBEITER 0.232<br />
FOTOGRAF FREIER_MITARBEITER 0.232<br />
ERSCHIENEN_IN.Titel VERDIENT.für 0.146<br />
ARTIKEL.Titel ARTIKEL.Titel 0.134<br />
ARTIKEL.Länge ARTIKEL.Länge 0.129<br />
ARTIKEL.Thema ARTIKEL.Thema 0.129<br />
AUTOR.ID FREIER_MITARBEITER.PersonID 0.128<br />
VERLAG.Name REDAKTEUR.Name 0.127<br />
FOTOGRAF.ID FREIER_MITARBEITER.PersonID 0.126<br />
ERSCHIENEN_IN.Titel ARTIKEL.Titel 0.125<br />
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.124<br />
SCHREIBT.ID VERDIENT.fM 0.124<br />
ZEITSCHRIFT.Titel ARTIKEL.Titel 0.123<br />
AUTOR.Adresse FREIER_MITARBEITER.Adresse 0.122<br />
AUTOR.Name FREIER_MITARBEITER.MName 0.122<br />
FOTOGRAF.Adresse FREIER_MITARBEITER.Adresse 0.12<br />
FOTOGRAF.Name FREIER_MITARBEITER.MName 0.12<br />
LIEFERT_BILDER_FÜR.ID FREIER_MITARBEITER.PersonID 0.119<br />
LIEFERT_BILDER_FÜR.Titel ARTIKEL.Titel 0.119<br />
SCHREIBT.ID FREIER_MITARBEITER.PersonID 0.119<br />
SCHREIBT.Titel ARTIKEL.Titel 0.119<br />
AUTOR.Name REDAKTEUR.Name 0.118<br />
VERLAG.Name FREIER_MITARBEITER.MName 0.118<br />
ZEITSCHRIFT ARTIKEL 0.118<br />
FOTOGRAF.Name REDAKTEUR.Name 0.117<br />
LIEFERT_BILDER_FÜR VERDIENT 0.114<br />
SCHREIBT VERDIENT 0.114<br />
AUTOR REDAKTEUR 0.101<br />
FOTOGRAF REDAKTEUR 0.101<br />
VERLAG REDAKTEUR 0.099<br />
VERLAG FREIER_MITARBEITER 0.093<br />
ERSCHIENEN_IN VERDIENT 0.083<br />
LIEFERT_BILDER_FÜR.Titel VERDIENT.für 0.081<br />
SCHREIBT.Titel VERDIENT.für 0.081<br />
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.052<br />
SCHREIBT.ID ARTIKEL.verantw. 0.052<br />
ZEITSCHRIFT.hrsg_von ARTIKEL.verantw. 0.049<br />
ZEITSCHRIFT.hrsg_von VERDIENT.fM 0.045<br />
... ... ...<br />
Tabelle C.11.: Verlag mit Vorverarbeitung (0.25)<br />
114
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
ARTIKEL ARTIKEL 0.463<br />
AUTOR FREIER_MITARBEITER 0.273<br />
FOTOGRAF FREIER_MITARBEITER 0.273<br />
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.155<br />
SCHREIBT.ID VERDIENT.fM 0.155<br />
LIEFERT_BILDER_FÜR VERDIENT 0.15<br />
SCHREIBT VERDIENT 0.15<br />
ARTIKEL.Titel ARTIKEL.Titel 0.144<br />
ARTIKEL.Länge ARTIKEL.Länge 0.138<br />
ARTIKEL.Thema ARTIKEL.Thema 0.138<br />
AUTOR.ID FREIER_MITARBEITER.PersonID 0.137<br />
FOTOGRAF.ID FREIER_MITARBEITER.PersonID 0.134<br />
ERSCHIENEN_IN.Titel ARTIKEL.Titel 0.132<br />
AUTOR.Adresse FREIER_MITARBEITER.Adresse 0.13<br />
AUTOR.Name FREIER_MITARBEITER.MName 0.13<br />
FOTOGRAF.Adresse FREIER_MITARBEITER.Adresse 0.128<br />
FOTOGRAF.Name FREIER_MITARBEITER.MName 0.128<br />
AUTOR.Name REDAKTEUR.Name 0.126<br />
LIEFERT_BILDER_FÜR.ID FREIER_MITARBEITER.PersonID 0.126<br />
LIEFERT_BILDER_FÜR.Titel ARTIKEL.Titel 0.126<br />
SCHREIBT.ID FREIER_MITARBEITER.PersonID 0.126<br />
SCHREIBT.Titel ARTIKEL.Titel 0.126<br />
AUTOR REDAKTEUR 0.124<br />
FOTOGRAF REDAKTEUR 0.124<br />
FOTOGRAF.Name REDAKTEUR.Name 0.124<br />
ERSCHIENEN_IN.Titel VERDIENT.für 0.118<br />
LIEFERT_BILDER_FÜR.Titel VERDIENT.für 0.098<br />
SCHREIBT.Titel VERDIENT.für 0.098<br />
ERSCHIENEN_IN VERDIENT 0.075<br />
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.069<br />
SCHREIBT.ID ARTIKEL.verantw. 0.069<br />
ERSCHIENEN_IN.Titel VERDIENT.fM 0.04<br />
LIEFERT_BILDER_FÜR ARTIKEL 0.04<br />
SCHREIBT ARTIKEL 0.04<br />
LIEFERT_BILDER_FÜR.ID VERDIENT.für 0.033<br />
SCHREIBT.ID VERDIENT.für 0.033<br />
ARTIKEL REDAKTEUR 0.029<br />
ZEITSCHRIFT ARTIKEL 0.029<br />
ARTIKEL FREIER_MITARBEITER 0.028<br />
... ... ...<br />
Tabelle C.12.: Verlag mit Vorverarbeitung (0.25) <strong>und</strong> manuellen Anpassungen<br />
115
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
MOVIE PRODUCTION 0.165<br />
PERSON PERSON 0.157<br />
MOVIE PERSON 0.132<br />
PERSON PRODUCTION 0.087<br />
PERSON RELEASE 0.07<br />
PART PERSON 0.066<br />
PERSON SERIES 0.059<br />
PERSON EPISODE 0.058<br />
PERSON QUOTE 0.058<br />
QUOTE PERSON 0.058<br />
MOVIE SERIES 0.053<br />
PART PRODUCTION 0.053<br />
AKA PERSON 0.046<br />
BUDGET PERSON 0.046<br />
LOCATION PERSON 0.046<br />
PERSON AKA 0.046<br />
PERSON BUDGET 0.046<br />
PERSON LOCATION 0.046<br />
PERSON RATING 0.046<br />
PERSON WORKS 0.046<br />
RATING PERSON 0.046<br />
RELEASE PERSON 0.046<br />
MOVIE RELEASE 0.044<br />
MOVIE EPISODE 0.039<br />
MOVIE QUOTE 0.039<br />
PART RELEASE 0.038<br />
PART EPISODE 0.037<br />
QUOTE RELEASE 0.037<br />
QUOTE PRODUCTION 0.036<br />
CHARACTER PERSON 0.035<br />
COUNTRY PERSON 0.035<br />
GENRE PERSON 0.035<br />
KEYWORD PERSON 0.035<br />
LANGUAGE PERSON 0.035<br />
LINK PERSON 0.035<br />
PART QUOTE 0.035<br />
PART SERIES 0.035<br />
PERSON COUNTRY 0.035<br />
PERSON GENRE 0.035<br />
... ... ...<br />
Tabelle C.13.: MovieDB ohne Vorverarbeitung (0.5)<br />
116
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
PERSON PERSON 0.795<br />
QUOTE QUOTE 0.3<br />
AKA AKA 0.264<br />
BUDGET BUDGET 0.264<br />
LOCATION LOCATION 0.264<br />
RATING RATING 0.264<br />
LINK LINK 0.229<br />
COUNTRY COUNTRY 0.228<br />
GENRE GENRE 0.228<br />
KEYWORD KEYWORD 0.228<br />
LANGUAGE LANGUAGE 0.228<br />
MOVIE MOVIE 0.228<br />
RELEASE RELEASE 0.228<br />
PART.person PARENTS.person 0.217<br />
PART.person PLAYS.person 0.217<br />
PART.person WORKS.person 0.216<br />
COUNTRY.country COUNTRY.country 0.207<br />
GENRE.genre GENRE.genre 0.207<br />
KEYWORD.keyword KEYWORD.keyword 0.207<br />
LANGUAGE.language LANGUAGE.language 0.207<br />
AKA.aka AKA.aka 0.196<br />
AKA.country AKA.country 0.196<br />
BUDGET.budget BUDGET.budget 0.196<br />
BUDGET.currency BUDGET.currency 0.196<br />
LOCATION.country LOCATION.country 0.196<br />
LOCATION.location LOCATION.location 0.196<br />
RATING.rating RATING.rating 0.196<br />
RATING.votes RATING.votes 0.196<br />
LINK.link LINK.link 0.195<br />
MOVIE.type MOVIE.type 0.194<br />
QUOTE.dialog QUOTE.dialog 0.192<br />
QUOTE.line QUOTE.line 0.192<br />
QUOTE.quote QUOTE.quote 0.191<br />
RELEASE.country RELEASE.country 0.191<br />
AKA.country COUNTRY.country 0.188<br />
COUNTRY.country AKA.country 0.188<br />
COUNTRY.country LOCATION.country 0.188<br />
LOCATION.country COUNTRY.country 0.188<br />
RELEASE.country COUNTRY.country 0.188<br />
... ... ...<br />
Tabelle C.14.: MovieDB mit Vorverarbeitung (1.0)<br />
117
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
PERSON PERSON 0.787<br />
QUOTE QUOTE 0.207<br />
AKA AKA 0.172<br />
BUDGET BUDGET 0.171<br />
LOCATION LOCATION 0.171<br />
RATING RATING 0.171<br />
PART.person PARENTS.person 0.149<br />
PART.person PLAYS.person 0.146<br />
MOVIE PRODUCTION 0.145<br />
PART.person WORKS.person 0.145<br />
LOCATION PERSON 0.142<br />
PERSON LOCATION 0.142<br />
LINK LINK 0.137<br />
COUNTRY COUNTRY 0.136<br />
GENRE GENRE 0.136<br />
KEYWORD KEYWORD 0.136<br />
LANGUAGE LANGUAGE 0.136<br />
MOVIE MOVIE 0.136<br />
RELEASE RELEASE 0.136<br />
COUNTRY.country COUNTRY.country 0.112<br />
GENRE.genre GENRE.genre 0.112<br />
KEYWORD.keyword KEYWORD.keyword 0.112<br />
LANGUAGE.language LANGUAGE.language 0.112<br />
PART PARENTS 0.102<br />
AKA.aka AKA.aka 0.1<br />
AKA.country AKA.country 0.1<br />
BUDGET.budget BUDGET.budget 0.1<br />
BUDGET.currency BUDGET.currency 0.1<br />
LOCATION.country LOCATION.country 0.1<br />
LOCATION.location LOCATION.location 0.1<br />
RATING.rating RATING.rating 0.1<br />
RATING.votes RATING.votes 0.1<br />
LINK.link LINK.link 0.098<br />
MOVIE.type MOVIE.type 0.098<br />
QUOTE.dialog QUOTE.dialog 0.096<br />
QUOTE.line QUOTE.line 0.096<br />
QUOTE.quote QUOTE.quote 0.095<br />
RELEASE.country RELEASE.country 0.094<br />
AKA.country COUNTRY.country 0.092<br />
... ... ...<br />
Tabelle C.15.: MovieDB mit Vorverarbeitung (0.25)<br />
118
Schema 1 Schema 2 Ähnlichkeitswert<br />
Primary Key Primary Key 1.0<br />
PERSON PERSON 0.599<br />
MOVIE PRODUCTION 0.542<br />
QUOTE QUOTE 0.316<br />
AKA AKA 0.283<br />
BUDGET BUDGET 0.283<br />
LINK LINK 0.283<br />
LOCATION LOCATION 0.283<br />
RATING RATING 0.283<br />
RELEASE RELEASE 0.283<br />
COUNTRY COUNTRY 0.25<br />
GENRE GENRE 0.25<br />
KEYWORD KEYWORD 0.25<br />
LANGUAGE LANGUAGE 0.25<br />
PART.person PARENTS.person 0.202<br />
COUNTRY.country COUNTRY.country 0.201<br />
COUNTRY.movie COUNTRY.production 0.201<br />
GENRE.genre GENRE.genre 0.201<br />
GENRE.movie GENRE.production 0.201<br />
KEYWORD.keyword KEYWORD.keyword 0.201<br />
KEYWORD.movie KEYWORD.production 0.201<br />
LANGUAGE.language LANGUAGE.language 0.201<br />
LANGUAGE.movie LANGUAGE.production 0.201<br />
AKA.movie AKA.production 0.189<br />
BUDGET.movie BUDGET.production 0.189<br />
LINK.movie1 LINK.production1 0.189<br />
LINK.movie2 LINK.production2 0.189<br />
LOCATION.movie LOCATION.production 0.189<br />
RATING.movie RATING.production 0.189<br />
AKA.aka AKA.aka 0.188<br />
AKA.country AKA.country 0.188<br />
BUDGET.budget BUDGET.budget 0.188<br />
BUDGET.currency BUDGET.currency 0.188<br />
LINK.link LINK.link 0.188<br />
LOCATION.country LOCATION.country 0.188<br />
LOCATION.location LOCATION.location 0.188<br />
RATING.rating RATING.rating 0.188<br />
RATING.votes RATING.votes 0.188<br />
CHARACTER WORKS 0.184<br />
QUOTE.dialog QUOTE.dialog 0.184<br />
... ... ...<br />
Tabelle C.16.: MovieDB mit Vorverarbeitung (0.25) nach Wiederholung des Verfahrens<br />
119