Vergleich von Methoden zum Graph Matching bei der Integration

Vergleich von Methoden zum Graph Matching bei der Integration

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