pdf (18647 Kb) - Fachgebiet Datenbanken und Informationssysteme ...

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 5
1.1. Motivation und Schwerpunkte dieser Arbeit . . . . . . . . . . . . . . . . . 5
1.2. Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Grundlagen 7
2.1. Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Mapping und Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Matching-Verfahren 10
3.1. Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Klassifizierung von Matching-Verfahren . . . . . . . . . . . . . . . . . . . 11
3.3. Graph Matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. Besonderheiten des Graph Matchings . . . . . . . . . . . . . . . . 13
3.3.2. Graph Matching bei räumlichen Daten . . . . . . . . . . . . . . . . 14
4. Der Similarity Flooding Algorithmus 15
4.1. Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Vorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. Iteratives Berechnung der Ähnlichkeiten . . . . . . . . . . . . . . . . . . . 22
4.4. Umgang mit den Ergebnissen . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.1. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4.2. Auswahl von 1-zu-1-Mappings . . . . . . . . . . . . . . . . . . . . . 26
4.4.3. Auswahl von n-zu-m-Mappings . . . . . . . . . . . . . . . . . . . . 30
5. Vergleich mit anderen Verfahren 31
5.1. Cupid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Rondo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3. SASMINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6. Implementierung der Testumgebung 37
6.1. Anforderungen an die Testumgebung . . . . . . . . . . . . . . . . . . . . . 37
6.2. Funktionen und Bedienung des Programmes . . . . . . . . . . . . . . . . . 37
6.3. Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4. Umgang mit Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5. Umgang mit Relationalen Datenbankschemata . . . . . . . . . . . . . . . 43
3

7. Empirische Befunde und Experimente zum Similarity Flooding 44
7.1. Befunde in der Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2. Experimente an Graphen . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.2.1. Experimentdurchführung . . . . . . . . . . . . . . . . . . . . . . . 45
7.2.2. Anfangsähnlichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2.3. Verwendung einer anderen Fixpunktformel . . . . . . . . . . . . . 57
7.2.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3. Experimente an Relationalen Datenbankschemata . . . . . . . . . . . . . . 63
7.3.1. Experimentaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.2. Ergebnisse ohne Vorverarbeitung . . . . . . . . . . . . . . . . . . . 67
7.3.3. Ergebnisse unter Ausnutzung von Namensgleichheiten von Relationen
und Attributen . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3.4. Ergebnisse unter Ausnutzung von Namensgleichheiten von Relationen
und Attributen mit manuellen Anpassungen . . . . . . . . . 70
7.3.5. Ergebnisse einer iterierten Anwendung . . . . . . . . . . . . . . . . 72
7.4. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8. Fazit und Ausblick 74
A. Anhang – Für Experimente verwendete Graphen 79
A.1. Graph 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
A.2. Graph 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3. Graph 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.4. Graph 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
A.5. Graph 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
A.6. Graph 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.7. Graph 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
B. Anhang – Für Experimente verwendete Schemata 92
B.1. Musiksammlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
B.2. Bustouren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
B.3. Verlag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
B.4. Filmdatenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
C. Tabellen zu Kapitel 7.3 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. Matching-
Verfahren 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 v 1 , v 2 , . . . , v k mit k ≥ 2, wobei zwei
aufeinanderfolgende Knoten v i , v i+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 G A ein gültiger
Pfad wäre, nicht in G B . (c, d, e, c) stellt einen Zyklus in G A dar, während G B zyklenfrei
(oder azyklisch) ist. Da in G B 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
L A TEX2HTML-Übersetzer entstanden ist, um Daten aus L A TEX 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 L A TEX2HTML-Ü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 Matching-
Verfahren 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 Struktur-
Ebene 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 G 1
und G 2 angewandt werden, bei denen der eine im anderen enthalten ist, und arbeitet in
13

einer Laufzeit von O(n 2 ).
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 – Tran-
Scm 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 BFS-
Matching-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 Schema-
Matching 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, x ′ Knoten in A, y, y ′ Knoten in B.
Ferner sei (x, p, x ′ ) ∈ A eine mit p beschriftete Kante in A, (y, p, y ′ ) ∈ 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, (x ′ , y ′ )) ∈ P CG(A, B) ⇔ (x, p, x ′ ) ∈ A und (y, p, y ′ ) ∈ 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 x ′ in A gibt, die mit einem Label p beschriftet ist, und es eine ebenso beschriftete
Kante zwischen zwei Knoten y und y ′ in B gibt, fügt man die Knoten (bzw. Map Pairs)
(x, y) und (x ′ , y ′ ) – 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
x ′ in A ähnlich sind, wahrscheinlich auch die zwei Knoten y und y ′ in B, die über
eine gleich beschriftete Kante verbunden sind, ähnlich sind. Daraus resultiert die Kante
zwischen den beiden Map Pairs (x, y) und (x ′ , y ′ ) 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 (x ′ , y ′ ) 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 (a 1 , a 2 ) aus A mit Label l a do
for each Kante (b 1 , b 2 ) aus B mit Label l b do
if (l a = l b ) then
if (a 1 , b 1 ) /∈ pcg then
füge (a 1 , b 1 ) zu pcg hinzu;
if (a 2 , b 2 ) /∈ pcg then
füge (a 2 , b 2 ) zu pcg hinzu;
füge Kante ((a 1 , b 1 ), l a , (a 2 , b 2 )) 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 (a 4 , b 2 ) erzeugt, weil sowohl vom Knoten a 4 in A
als auch vom Knoten b 2 in B eine Kante mit dem Label l 2 ausgeht. Der Knoten (a 2 , b 3 )
und die l 2 -Verbindung zwischen (a 4 , b 2 ) und (a 2 , b 3 ) resultiert daraus, dass es in A eine
l 2 -Kante von a 4 nach a 2 und in B eine l 2 -Kante von b 2 nach b 3 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 ((a 1 , a 2 ), p, (b 1 , b 2 )) ∈ pcg do
if Kante ((b 1 , b 2 ), q, (a 1 , a 2 )) /∈ pcg then
füge Kante ((b 1 , b 2 ), null, (a 1 , a 2 )) zu spg hinzu;
for each Kante ((a 1 , a 2 ), p, (b 1 , b 2 )) ∈ spg do
gewichte Kante ((a 1 , a 2 ), p, (b 1 , b 2 )) mit ω((a 1 , a 2 ), (b 1 , b 2 ));
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 (〈x, p, A〉, 〈y, q, B〉)
den Propagation-Koeffizienten der ausgehenden Kante bzw. Kanten des Map Pairs (x, y)
und π r (〈x, p, A〉, 〈y, q, B〉) 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 (〈x, p, A〉, 〈y, q, B〉) 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

Ansatz p = q p ≠ 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
Gesamt-
Inverser
durchschnitt
Inverses
produkt
Gesamt-
2
card {l,r} (x,p)+card {l,r} (y,q)
0
1
card {l,r} (x,p)·card {l,r} (y,q)
0
Kombinierter inverser
Durchschnitt
4
(card {l,r} (p,A)+card {l,r} (q,B))·(card {l,r} (c,p,A)+card {l,r} (y,q,B))
0
1
Stochastisch ∑
∀p ′ (card {l,r} (x,p ′ ,A)·card {l,r} (y,p ′ ,B))
0
Konstant 1.0 0
Tabelle 4.1.: Berechnungsformeln für die Propagation-Koeffizienten
20

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:
⎧
⎨
1
card
π {l,r} (〈x, p, A〉, 〈y, q, B〉) = {l,r} (x,p,A)·card {l,r} (y,q,B) , wenn p = q
⎩0, wenn p ≠ q
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. card l (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 card r (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), wenn π l berechnet wird
card r (x, p, A),
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 ((x 1 , y 1 ), p, (x 2 , y 2 )) wurde hier die inverse Pro-
21

duktformel verwendet. Der Propagation-Koeffizient ω((a 4 , b 2 ), (a 2 , b 3 )) = 0.5 der Kante
zwischen (a 4 , b 2 ) und (a 2 , b 3 ) kommt demnach dadurch zustande, dass es vom Knoten
(a 4 , b 2 ) genau zwei ausgehende l 2 -Kanten gibt, sodass sich der Wert als ω((a 4 , b 2 ), (a 2 , b 3 )) =
1
2
= 0.5 ergibt.
Der Propagation-Koeffizient ω((a 2 , b 2 ), (a 1 , b 1 )) = 1.0 ergibt sich deshalb, weil nur
eine einzige mit l 1 beschriftete Kante aus a 2 b 2 ausgeht bzw. in a 1 b 1 eingeht.
Die zweite hier vorgestellte Möglichkeit für die Berechnung der Propagation-Koeffizienten
ist die Verwendung der inversen Durchschnittsfunktion. Diese berechnet π wie folgt:
⎧
⎨
2
card
π {l,r} (〈x, p, A〉, 〈y, q, B〉) = {l,r} (x,p,A)+card {l,r} (y,q,B) , wenn p = q
⎩0, wenn p ≠ q
Hier wird also statt einer Produktbildung der Kardinalitäten wie in der inversen Produktformel
auf die Durchschnittsbildung zurückgegriffen. Der Propagation-Koeffizient
ω((a 4 , b 2 ), (a 2 , b 3 )) des Graphen aus Abbildung 4.3 würde in diesem Fall den Wert 0.6
ergeben, weil es in Modell A zwei ausgehende l 2 -Kanten von a 4 sowie eine von b 2 gibt,
2
sodass sich der Wert als
2+1 = 2 3
= 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
darstellen, wobei gilt:
ϕ(σ i (x, y)) =
+
σ i+1 (x, y) = σ i (x, y) + ϕ(σ i )(x, y)
∑
(a u,p,x)∈A,(b u,p,y)∈B
∑
(x,p,a v)∈A,(y,p,b v)∈B
σ i (a u , b u ) · ω((a u , b u ), (x, y))
σ i (a v , b b ) · ω((a v , b v ), (x, y))
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(n Knoten ∗ n Kanten ), wobei n Knoten und n Kanten die Anzahl der
Knoten bzw. Kanten im SPG sind.
Pseudocode 4.3: berechneÄhnlichkeiten(SPG spg)
for each Knoten (a 1 , b 1 ) ∈ spg do
σ neu (a 1 , b 1 ) ← σ(a 1 , b 1 )
for each Kante ((a 1 , b 1 ), l, (a 2 , b 2 )) ∈ spg do // ausgehende Kanten
σ neu (a 1 , b 1 ) = σ neu (a 1 , b 1 ) + σ(a 2 , b 2 ) · ω((a 1 , b 1 ), (a 2 , b 2 ));
for each Kante ((a 2 , b 2 ), l, (a 1 , b 1 )) ∈ spg do // eingehende Kanten
σ neu (a 1 , b 1 ) = σ neu (a 1 , b 1 ) + σ(a 2 , b 2 ) · ω((a 2 , b 2 ), (a 1 , b 1 ));
for each Knoten (a 1 , b 1 ) ∈ spg do
σ(a 1 , b 1 ) = normalisieren(σ neu (a 1 , b 1 ))
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 (a 1 , b 3 ) als σ 1 (a 1 , b 3 ) = σ 0 (a 1 , b 3 )+σ 0 (a 1 , b 3 )·ω((a 1 , b 3 ), (a 2 , b 1 )) = 1.0+1.0·1.0 = 2.0,
aufgrund der Normalisierung mit dem maximal erreichten Wert in der Iteration (in diesem
Fall der Wert 3.0) ergibt sich daraus σ 0 (a 1 , b 3 ) = 2 3 = 0.6.
Schon nach den dargestellen fünf Iterationen kann man erkennen, dass der Ähnlichkeitswert
für (a 1 , b 1 ) konstant bei 1.0 bleibt, die Werte für (a 2 , b 2 ) und (a 3 , b 4 ) 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 (a 1 , b 3 ), (a 2 , b 1 ), (a 2 , b 3 ), (a 3 , b 3 ) und (a 4 , b 2 ) tatsächlich
23

Map Pair
σ i
0 1 2 3 4 5
(a 1 , b 1 ) 1.0 1.0 1.0 1.0 1.0 1.0
(a 1 , b 3 ) 1.0 0.6 0.57 0.47 0.39 0.32
(a 2 , b 1 ) 1.0 0.6 0.57 0.47 0.39 0.32
(a 2 , b 2 ) 1.0 0.6 0.71 0.71 0.71 0.71
(a 2 , b 3 ) 1.0 0.5 0.43 0.35 0.29 0.24
(a 3 , b 3 ) 1.0 0.5 0.43 0.35 0.29 0.24
(a 3 , b 4 ) 1.0 0.6 0.71 0.71 0.71 0.71
(a 4 , b 2 ) 1.0 1.0 0.86 0.71 0.59 0.48
Tabelle 4.2.: Ähnlichkeitswerte der Map Pairs über mehrere Iterationen
Bezeichner
Fixpunkt-Formel
Basis σ i+1 = normalize(σ i + ϕ(σ i ))
A σ i+1 = normalize(σ 0 + ϕ(σ i ))
B σ i+1 = normalize(ϕ(σ 0 + σ i ))
C σ 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 △(σ 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 △(σ 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 △(σ 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;
repeat
berechneÄhnlichkeiten(spg);
until Abbruchbedingung erfüllt;
// berechnet die anfänglichen Werte für σ
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 Match-
Kandidaten, 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 2 4 = 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äts-
Constraints.
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 Matching-
Problemen 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 (x ′ , y ′ ) gibt, bei denen x
y ′ gegenüber y und y ′ x gegenüber x ′ 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

m 1 : w 2 (0.8), w 3 (0.7), w 1 (0.3), w 4 (0.1)
m 2 : w 2 (0.9), w 3 (0.3), w 1 (0.2), w 4 (0.2)
m 3 : w 1 (0.7), w 4 (0.6), w 2 (0.1), w 3 (0)
m 4 : w 4 (0.7), w 2 (0.5), w 3 (0.4), w 1 (0.3)
w 1 : m 3 (0.7), m 1 (0.3), m 4 (0.3), m 2 (0.2)
w 2 : m 2 (0.9), m 1 (0.8), m 4 (0.5), m 3 (0.1)
w 3 : m 1 (0.7), m 4 (0.4), m 2 (0.3), m 3 (0)
w 4 : m 4 (0.7), m 3 (0.6), m 2 (0.2), m 1 (0.1)
Schritt 0: free = {m 1 , m 2 , m 3 , m 4 , w 1 , w 2 , w 3 , w 4 }, married = ∅
Schritt 1: free = {m 2 , m 3 , m 4 , w 1 , w 3 , w 4 }, married = {(m 1 , w 2 )}
Schritt 2: free = {m 1 , m 3 , m 4 , w 1 , w 3 , w 4 }, married = {(m 2 , w 2 )}
Schritt 3: free = {m 3 , m 4 , w 1 , w 4 }, married = {(m 2 , w 2 ), (m 1 , w 3 )}
Schritt 4: free = {m 4 , w 4 }, married = {(m 2 , w 2 ), (m 1 , w 3 ), (m 3 , w 1 )}
Schritt 5: free = ∅, married = {(m 2 , w 2 ), (m 1 , w 3 ), (m 3 , w 1 ), (m 4 , w 4 )}
⇒ M 1 = {(m 2 , w 2 ), (m 1 , w 3 ), (m 3 , w 1 ), (m 4 , w 4 )}
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 ∈ free und proposal(m) ≠ ∅
w ← erstes noch nicht betrachtetes Element aus proposal(m);
if w ∈ free
füge (m, w) der Menge married hinzu and entferne m und w aus free;
else if ∃(m ′ , w) ∈ married
if w bevorzugt m gegenüber m ′
füge (m, w) der Menge married hinzu;
entferne (m ′ , w) aus der Menge married;
füge m ′ der Menge free hinzu;
else
(m ′ , w) bleibt in married;
Beispielhaft ist der Ablauf für zwei Mengen M = {m 1 , m 2 , m 3 , m 4 } und W = {w 1 , w 2 ,
w 3 , w 4 } 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 M 1 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 M i in einem gewichteten, bipartiten
Graphen M zu finden, das das totale Gewicht ∑ (x,y)∈M i
σ(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 M 1 , die sich im Beispiel in Abbildung 4.5 ergibt,
ist auch im Sinne des Zuordnungsproblems optimal. Hierbei ist ∑ (x,y)∈M 1
σ(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 M 2 =
{(m 1 , w 1 ), (m 2 , w 2 ), (m 3 , w 3 ), (m 4 , w 4 )} mit ∑ (x,y)∈M 2
σ(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 M 1 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 M 3 = {(m 1 , w 3 ), (m 2 , w 2 ), (m 3 , w 1 )} wäre dagegen weder maximal noch
ein Maximum-Matching oder perfekt, weil es in M 1 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 ∑ Beispiel eine Teilmenge M i aus dem Multimapping gesucht
werden, die die Funktion
‖(x,)‖·‖(,y)‖
maximiert, wobei ‖(x, ) und ‖(, y)‖ die Anzahl
der Partner von einer Frau x und einem Mann y in M i darstellen.
M i
σ(x,y)
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 t abs = 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(m 1 , m 2 ) für alle Elemente m 1 und m 2 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 Tree-
Match-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) =
slink out ∪ slink in
|leaves(s) ∪ leaves(t)|
Dabei gilt slink out = {x|x ∈ leaves(s) ∧ ∃y ∈ leaves(t), stronglink(x, y)} und
slink in = {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 th accept 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) = w struct · ssim(s, t) + (1 − w struct ) · lsim(s, t)
Hierbei ist w struct 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 th high 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 c inc 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 th low , werden die Ähnlichkeitswerte ssim der Blätter aus demselben Grund um einen
Wert c dec 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 w struct 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) = w linguistisch · sm linguistisch (a, b) + w strukturell · sm strukturell (a, b)
35

Dabei ist sm linguistisch (a, b) die linguistische Ähnlichkeit von (a, b), w linguistisch das Gewicht
vom linguistischen Matching, sm strukturell (a, b) die strukturelle Ähnlichkeit von
(a, b) und w strukturell 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-Marriage-
Eigenschaft 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 (a 1 , 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 Matching-
Kandidaten 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 (a i , b i ) 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
Fall
1 2 3 4 5
(a, b) 1 1 0 0 0.224
(a 1 , b) 1 0 1 1 0.066
(a 1 , b 1 ) 1 0 0 1 0.035
(a 1 , b 2 ) 1 0 0 0 0.093
(a 2 , b 1 ) 1 0 0 0 0.984
(a 2 , b 2 ) 1 0 1 1 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 N 1
genannt – beinhaltet eine Anzahl Knoten, deren Ähnlichkeitswerte im Bereich zwischen
einem Wert s min und 1 liegen. s min ist dabei der niedrigste Wert, den die Ähnlichkeiten
der Knoten von N 1 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 s min und dem größten Wert zu beobachten, den die Ähnlichkeiten der Knoten
in N 2 annehmen können. Die zweite Gruppe (N 2 ), in die sich die Knoten im Ergebnis
einteilen lassen, beinhaltet die restlichen Knoten, deren Ähnlichkeitswerte alle zwischen
0 und s min (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 N 1 zugeordnet werden können, durch doppelte Umrandungen hervorgehoben.
Tabelle 7.2 zeigt für die Testgraphen, wie sich die Knoten in die beiden Mengen N 1
und N 2 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 N 1 schon
mehrere Schritte vor Erreichen des Fixpunktes und demnach Abbruch des Algorithmus
nahezu feste Werte angenommen haben. Änderungen der Zahlenwerte sind im Bereich
48

Graph
1 2 3 4 5 6 7
|Knoten| 6 15 8 20 73 60 32
|N 1 | 4 6 3 6 7 16 12
|N 2 | 2 9 5 14 66 44 20
Tabelle 7.2.: Verteilung der Knoten in N 1 und N 2 im Fixpunkt
Knoten
Iteration
1 2 3 10 15 20 30 35 36 37
(a, b) 1 1 1 1 1 1 1 1 1 1
(a 1 , b) 0.667 0.571 0.5 0.191 0.094 0.046 0.011 0.005 0.005 0.004
(a 1 , b 1 ) 0.5 0.429 0.406 0.384 0.383 0.383 0.383 0.383 0.383 0.383
(a 1 , b 2 ) 0.667 0.643 0.656 0.704 0.707 0.707 0.707 0.707 0.707 0.707
(a 2 , b 1 ) 0.833 0.857 0.875 0.921 0.923 0.924 0.924 0.924 0.924 0.924
(a 2 , b 2 ) 0.667 0.571 0.5 0.191 0.094 0.046 0.011 0.005 0.005 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 N 2 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 N 1 im Fixpunkt keinerlei Auswirkungen mehr,
während die Werte der Knoten aus N 2 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 N 1 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 N 1 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 N 2 scheinen also im Laufe der
49

Graph
Fall
1 2 3 4 5
1 37 18 1 50 36
2 109 17 5 164 110
3 32 6 2 39 34
4 130 35 28 209 127
5 308 21 114 586 359
6 37 29 41 61 37
7 424 10 9 752 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 N 1 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 N 1 sind, aber nicht
zu den erwarteten Matching-Kandidaten gehören, herausgefiltert, bei Graph 2 werden
zusätzlich weitere Knoten aus der Menge N 2 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, fj, 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 N 1
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 N 2 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 N 2 -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 Matching-
Kandidaten 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 N 1 -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 N 2 -
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 N 2 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 N 1 zugeordnet werden
können, sowie deren Ähnlichkeitswerte im Fixpunkt nach 18 Iterationen sind auch hier
fett hervorgehoben.
51

Knoten
Iteration
1 2 3 4 5 10 15 16 17 18
(a, b) 1 1 1 1 1 1 1 1 1 1
(a 1 , b) 0 0 0 0 0 0 0 0 0 0
(a 1 , b 1 ) 0.5 0.5 0.5 0.471 0.446 0.392 0.384 0.384 0.383 0.383
(a 1 , b 2 ) 0 0.25 0.375 0.471 0.541 0.682 0.704 0.705 0.706 0.706
(a 2 , b 1 ) 0.5 0.5 0.625 0.706 0.77 0.901 0.921 0.922 0.923 0.923
(a 2 , b 2 ) 0 0 0 0 0 0 0 0 0 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 N 1 waren, auf 1 gesetzt, die der restlichen
Knoten (also der N 1 -Knoten aus Fall 1 und 2) auf 0. Dadurch wird erreicht, dass
in den Graphen die ZHK, denen in den vorherigen Fällen die N 1 -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 N 1 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 N 2 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 N 1 in Fall 3 entspricht hier also genau der Menge N 2 aus Fall 1, die Menge
N 2 der Menge N 1 aus Fall 1. Bei den Graphen 4, 5 und 6 sind nicht alle N 2 -Knoten aus
Fall 1 und 2 in Fall 3 in der Menge N 1 , sondern nur eine Teilmenge davon. Interessant ist
hierbei wieder, dass der Menge N 1 immer alle Knoten von bestimmten ZHK zugeordnet
werden können. Es kommt niemals vor, dass einzelne Knoten einer ZHK der Menge N 1
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 N 2 zugeordnet werden können. Wie auch schon in Fall 1 beobachtet,
52

Knoten Iteration
1
(a, b) 0
(a 1 , b) 1
(a 1 , b 1 ) 0
(a 1 , b 2 ) 0
(a 2 , b 1 ) 0
(a 2 , b 2 ) 1
Tabelle 7.6.: Ähnlichkeitswerte (Graph 1) für Fall 3
stellen sich in Fall 3 für die Knoten aus N 1 schon nach wenigen Iterationen nahezu
konstante Werte ein. In den folgenden Iterationen müssen die Ähnlichkeitswerte der N 2 -
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 N 1 -Knoten in Fall 1 enthalten hat – keine weiteren ZHK mehr gibt, deren
Knoten der Menge N 2 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 N 1 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 N 1 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 (s min ) in der Menge N 1 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 N 1 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 s min wie der Knoten (gk) aufwies, statt der von (gk) auf 1,
stellt sich mit Ausnahme der ZHK {(ei), (fj), (fk), (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 N 1 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 N 1 auf ihren
festen Werten „eingependelt“ haben, und es anschließend wieder eine hohe Anzahl von
Iterationen benötigt, bis die Werte der Knoten aus N 2 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 N 1 und deren Werte im Fixpunkt nach 50 Iterationen fett
hervorgehoben.
54

Knoten
Iteration
1 2 3 10 20 30 40 48 49 50
(a, b) 0.5 0.5 0.5 0.831 1 1 1 1 1 1
(a 1 , b) 1 1 1 1 0.301 0.072 0.017 0.006 0.005 0.004
(a 1 , b 1 ) 0.5 0.375 0.313 0.336 0.383 0.383 0.383 0.383 0.383 0.383
(a 1 , b 2 ) 0 0 0.063 0.539 0.706 0.707 0.707 0.707 0.707 0.707
(a 2 , b 1 ) 0 0.125 0.188 0.723 0.923 0.924 0.924 0.924 0.924 0.924
(a 2 , b 2 ) 1 1 1 1 0.301 0.072 0.017 0.006 0.005 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), (fj), (fk), (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
Iteration
1 2 3 10 15 20 30 34 35 36
(a, b) 1 0.93 0.968 1 1 1 1 1 1 1
(a 1 , b) 0.636 0.547 0.49 0.173 0.085 0.041 0.01 0.006 0.005 0.004
(a 1 , b 1 ) 0.118 0.266 0.319 0.38 0.382 0.383 0.383 0.383 0.383 0.383
(a 1 , b 2 ) 0.867 0.785 0.8 0.714 0.708 0.707 0.707 0.707 0.707 0.707
(a 2 , b 1 ) 0.957 1 1 0.93 0.925 0.924 0.924 0.924 0.924 0.924
(a 2 , b 2 ) 0.636 0.547 0.49 0.173 0.085 0.041 0.01 0.006 0.005 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
Fall
1 2 3 4 5
1 10 44 10 15 14
2 17 72 17 15 21
3 14 79 14 16 17
4 18 75 12 17 21
5 18 69 14 18 15
6 11 20 11 12 13
7 16 35 15 10 10
Tabelle 7.9.: Anzahl der Iterationen bis zum Fixpunkt (Fixpunktformel A)
Knoten
Iteration
1 2 3 4 5 6 7 8 9 10
(a, b) 1 1 1 1 1 1 1 1 1 1
(a 1 , b) 0.67 0.714 0.667 0.674 0.665 0.667 0.665 0.666 0.665 0.666
(a 1 , b 1 ) 0.5 0.643 0.583 0.607 0.596 0.601 0.599 0.6 0.599 0.6
(a 1 , b 2 ) 0.67 0.786 0.75 0.764 0.759 0.761 0.76 0.761 0.76 0.761
(a 2 , b 1 ) 0.83 0.929 0.889 0.91 0.9 0.905 0.902 0.904 0.903 0.903
(a 2 , b 2 ) 0.67 0.714 0.667 0.674 0.665 0.667 0.665 0.666 0.665 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 Basis-
Fixpunktformel 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 Basis-
Fixpunktformel 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 Basis-
Fixpunktformel. 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 Basis-
Fixpunktformel 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
Iteration
1 2 3 10 20 30 40 42 43 44
(a, b) 0.3 0.5 0.8 1 1 1 1 1 1 1
(a 1 , b) 0.2 0.3 0.4 0.257 0.233 0.232 0.232 0.232 0.231 0.232
(a 1 , b 1 ) 0.15 0.25 0.35 0.423 0.421 0.42 0.419 0.419 0.419 0.419
(a 1 , b 2 ) 0.2 0.35 0.55 0.708 0.708 0.707 0.707 0.707 0.707 0.707
(a 2 , b 1 ) 0.25 0.45 0.7 0.921 0.916 0.914 0.914 0.913 0.913 0.913
(a 2 , b 2 ) 0.2 0.3 0.4 0.257 0.233 0.232 0.232 0.232 0.231 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 N 1 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 N 1 und N 2 aufteilen, wobei sich die auf diese Weise
eingeteilten Mengen nicht von denen unterscheiden, die etwa in Fall 2 mit der Basis-
Fixpunktformel 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
Iteration
1 2 3 4 5 6 7 8 9 10
(a, b) 1 1 1 1 1 1 1 1 1 1
(a 1 , b) 0 0 0 0 0 0 0 0 0 0
(a 1 , b 1 ) 0.5 0.643 0.583 0.607 0.596 0.601 0.599 0.6 0.599 0.6
(a 1 , b 2 ) 0.667 0.786 0.75 0.764 0.759 0.761 0.76 0.761 0.76 0.761
(a 2 , b 1 ) 0.833 0.929 0.889 0.91 0.9 0.905 0.902 0.904 0.903 0.903
(a 2 , b 2 ) 0 0 0 0 0 0 0 0 0 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
Iteration
1 2 3 4 5 10 12 13 14 15
(a, b) 0.5 0.25 0.375 0.313 0.359 0.35 0.352 0.353 0.352 0.353
(a 1 , b) 1 1 1 1 1 1 1 1 1 1
(a 1 , b 1 ) 0.5 0.625 0.563 0.594 0.578 0.589 0.588 0.588 0.588 0.588
(a 1 , b 2 ) 0 0 0.063 0.031 0.063 0.057 0.058 0.059 0.058 0.059
(a 2 , b 1 ) 0 0.125 0.063 0.125 0.094 0.118 0.118 0.117 0.118 0.117
(a 2 , b 2 ) 1 1 1 1 1 1 1 1 1 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 Matching-
Kandidaten 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 Teilmengen-
Beziehung 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 AU-
TOR 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 (PRI-
MARY 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 (n i , n j ) nach
folgender Formel festgelegt:
σ 0 (n i , n j ) =
{
α, wenn s(ni , n j ) = 1
0, sonst
s(n i , n j ) überprüft dabei, ob der Name von n i als Teilwort im Namen von n j 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
(Name, V ornamen) und (Nachname, Name) liefert s beispielsweise den Wert 1,
was zu σ 0 (Name, V orname) = σ 0 (Nachname, Name) = α führt. Für den Knoten
(V orname, Nachname) ergibt sich so s(V orname, Nachname) = 0 und entsprechend
σ 0 (V orname, Nachname) = 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 SAMP-
LERSONG (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 REDAKTEUR-
Relation 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 MO-
VIE 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 (IN-
TERPRET.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 Matching-
Kandidaten 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), (BE-
SUCHT.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 Matching-
Kandidat 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, FREI-
ER_MITARBEITER.MName), (VERLAG.Name, REDAKTEUR.Name) und (ZEIT-
SCHRIFT.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 Teilmengen-
Beziehungen. 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 Eingabe-
Schemata 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]
[Dra93]
[Gal06]
[GS62]
[IntDB10]
[Kuh55]
[LN07]
[MBR01]
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.
Drakos, Nikos: Text to Hypertext conversion with L A TEX2HTML. Baskerville,
3(2):12–15, 1993.
Gal, Avigdor: Why is Schema Matching Tough and What Can We Do About
It SIGMOD Record, 35(4):2–5, 2006.
Gale, David und Shapley, Lloyd S.: College admissions and the stability of
marriage. The American Mathematical Monthly, 69(1):9–15, 1962.
Praktische Informatik, FG Datenbanken und Informationssysteme Institut
für: Übungen zu Integration von Datenbanken im WS 10/11. 2010.
Kuhn, Harold W.: The Hungarian method for the assignment problem. Naval
Research Logistics Quarterly, 2(1-2):83–97, 1955.
Leser, Ulf und Naumann, Felix: Informationsintegration - Architekturen
und Methoden zur Integration verteilter und heterogener Datenquellen.
dpunkt.verlag, 2007.
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]
[MZ98]
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.
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]
[RB01]
[Rip04]
[Sch09]
[SE05]
[Tie03]
[UA10]
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.
Rahm, Erhard und Bernstein, Philip A.: A survey of approaches to automatic
schema matching. The VLDB Journal, 10:334–350, Dezember 2001.
Ripperda, Nora: Graphbasiertes Matching in räumlichen Datenbanken. Diplomarbeit,
Institut für Informationssysteme, Leibniz Universität Hannover,
2004.
Schäfers, Michael: Entwicklung eines ähnlichkeitsbasierten Frameworks für
das Matching von Datenbankobjekten. Diplomarbeit, Institut für Informationssysteme,
Leibniz Universität Hannover, 2009.
Shvaiko, Pavel und Euzenat, Jérôme: A Survey of Schema-Based Matching
Approaches. Journal of Data Semantics, 3730(4):146–171, 2005.
Tiedge, Michael: Entwicklung und Implementierung einer topologischen Erweiterung
für objektbasierte räumliche Datenbanken. Diplomarbeit, Institut
für Informationssysteme, Leibniz Universität Hannover, 2003.
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 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
ENTHÄLT SAMPLERSONG 0.223
ENTHÄLT ALBUMSONG 0.191
CD SAMPLER 0.178
CD INTERPRET 0.17
MUSIKSTÜCK SAMPLER 0.163
MUSIKSTÜCK ALBUM 0.158
CD ALBUM 0.156
CD PRODUZENT 0.156
CD TITEL 0.155
MUSIKSTÜCK TITEL 0.148
MUSIKSTÜCK INTERPRET 0.147
INTERPRET SAMPLER 0.143
MUSIKSTÜCK PRODUZENT 0.141
INTERPRET INTERPRET 0.139
ENTHÄLT ALBUM 0.127
INTERPRET ALBUM 0.125
INTERPRET PRODUZENT 0.125
INTERPRET TITEL 0.124
MUSIKSTÜCK ALBUMSONG 0.118
MUSIKSTÜCK SAMPLERSONG 0.103
ENTHÄLT TITEL 0.095
ENTHÄLT SAMPLER 0.094
CD ALBUMSONG 0.092
INTERPRET ALBUMSONG 0.085
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.073
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.073
MUSIKSTÜCK.Interpret ALBUM.Produzent 0.071
MUSIKSTÜCK.Interpret ALBUMSONG.Album 0.071
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.071
MUSIKSTÜCK.Interpret SAMPLER.Produzent 0.071
ENTHÄLT.Jahr TITEL.Künstlername 0.07
ENTHÄLT.Titel TITEL.Künstlername 0.07
... ... ...
Tabelle C.1.: Musiksammlung ohne Vorverarbeitung (0.5)
104

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
INTERPRET INTERPRET 0.478
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.268
INTERPRET.Geburtsdatum INTERPRET.Geburtsdatum 0.261
INTERPRET.Name INTERPRET.Künstlername 0.261
INTERPRET.Name INTERPRET.Realname 0.261
ENTHÄLT.Interpret ALBUMSONG.Albuminterpret 0.26
MUSIKSTÜCK.Interpret SAMPLERSONG.Interpret 0.26
ENTHÄLT.Jahr SAMPLERSONG.SJahr 0.257
ENTHÄLT.Titel SAMPLERSONG.Titel 0.255
INTERPRET.ID PRODUZENT.ID 0.255
ENTHÄLT.Interpret SAMPLERSONG.Interpret 0.254
ENTHÄLT.Titel ALBUMSONG.Titel 0.254
INTERPRET.Name ALBUM.Albumname 0.254
INTERPRET.Name PRODUZENT.Name 0.254
MUSIKSTÜCK.Genre ALBUM.Genre 0.253
CD.Jahr SAMPLER.Jahr 0.252
INTERPRET.Name TITEL.Name 0.252
CD.Jahr SAMPLERSONG.SJahr 0.25
CD.Titel ALBUMSONG.Titel 0.25
CD.Titel SAMPLERSONG.Titel 0.25
ENTHÄLT.Jahr SAMPLER.Jahr 0.25
INTERPRET.Name SAMPLER.Name 0.25
MUSIKSTÜCK.Titel ALBUMSONG.Titel 0.25
MUSIKSTÜCK.Titel SAMPLERSONG.Titel 0.25
ENTHÄLT SAMPLERSONG 0.217
MUSIKSTÜCK ALBUM 0.165
ENTHÄLT ALBUMSONG 0.15
INTERPRET ALBUM 0.142
INTERPRET PRODUZENT 0.142
CD SAMPLER 0.108
INTERPRET TITEL 0.105
MUSIKSTÜCK ALBUMSONG 0.079
MUSIKSTÜCK SAMPLERSONG 0.076
CD TITEL 0.073
INTERPRET SAMPLER 0.071
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.066
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.063
MUSIKSTÜCK TITEL 0.056
MUSIKSTÜCK.Interpret ALBUM.Produzent 0.023
... ... ...
Tabelle C.2.: Musiksammlung mit Vorverarbeitung (1.0)
105

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
INTERPRET INTERPRET 0.373
ENTHÄLT SAMPLERSONG 0.283
MUSIKSTÜCK ALBUM 0.269
ENTHÄLT ALBUMSONG 0.23
INTERPRET PRODUZENT 0.174
INTERPRET ALBUM 0.173
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.156
ENTHÄLT.Interpret ALBUMSONG.Albuminterpret 0.146
MUSIKSTÜCK.Interpret SAMPLERSONG.Interpret 0.136
CD SAMPLER 0.132
ENTHÄLT.Jahr SAMPLERSONG.SJahr 0.129
INTERPRET.Geburtsdatum INTERPRET.Geburtsdatum 0.129
INTERPRET.Name INTERPRET.Künstlername 0.129
INTERPRET.Name INTERPRET.Realname 0.129
ENTHÄLT.Interpret SAMPLERSONG.Interpret 0.126
INTERPRET.ID PRODUZENT.ID 0.126
ENTHÄLT.Titel ALBUMSONG.Titel 0.125
ENTHÄLT.Titel SAMPLERSONG.Titel 0.125
MUSIKSTÜCK.Genre ALBUM.Genre 0.125
INTERPRET.Name ALBUM.Albumname 0.123
INTERPRET.Name PRODUZENT.Name 0.123
MUSIKSTÜCK ALBUMSONG 0.12
INTERPRET TITEL 0.119
INTERPRET.Name TITEL.Name 0.119
CD.Jahr SAMPLER.Jahr 0.118
INTERPRET.Name SAMPLER.Name 0.115
CD.Jahr SAMPLERSONG.SJahr 0.113
CD.Titel ALBUMSONG.Titel 0.113
CD.Titel SAMPLERSONG.Titel 0.113
ENTHÄLT.Jahr SAMPLER.Jahr 0.113
MUSIKSTÜCK TITEL 0.113
MUSIKSTÜCK.Titel ALBUMSONG.Titel 0.113
MUSIKSTÜCK.Titel SAMPLERSONG.Titel 0.113
MUSIKSTÜCK SAMPLERSONG 0.104
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.1
CD TITEL 0.096
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.092
INTERPRET SAMPLER 0.086
MUSIKSTÜCK.Interpret ALBUM.Produzent 0.053
... ... ...
Tabelle C.3.: Musiksammlung mit Vorverarbeitung (0.25)
106

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
INTERPRET INTERPRET 0.396
ENTHÄLT SAMPLERSONG 0.302
MUSIKSTÜCK ALBUM 0.27
ENTHÄLT ALBUMSONG 0.249
ENTHÄLT.Interpret ALBUMSONG.Albuminterpret 0.151
MUSIKSTÜCK.Interpret ALBUMSONG.Albuminterpret 0.143
CD SAMPLER 0.142
MUSIKSTÜCK.Interpret SAMPLERSONG.Interpret 0.141
ENTHÄLT.Jahr SAMPLERSONG.SJahr 0.134
INTERPRET.Geburtsdatum INTERPRET.Geburtsdatum 0.133
INTERPRET.Name INTERPRET.Künstlername 0.133
INTERPRET.Name INTERPRET.Realname 0.133
ENTHÄLT.Interpret SAMPLERSONG.Interpret 0.13
ENTHÄLT.Titel ALBUMSONG.Titel 0.129
ENTHÄLT.Titel SAMPLERSONG.Titel 0.129
INTERPRET TITEL 0.128
MUSIKSTÜCK.Genre ALBUM.Genre 0.128
MUSIKSTÜCK TITEL 0.126
INTERPRET.Name TITEL.Name 0.123
CD.Jahr SAMPLER.Jahr 0.122
INTERPRET.Name SAMPLER.Name 0.118
CD.Jahr SAMPLERSONG.SJahr 0.116
CD.Titel ALBUMSONG.Titel 0.116
CD.Titel SAMPLERSONG.Titel 0.116
ENTHÄLT.Jahr SAMPLER.Jahr 0.116
MUSIKSTÜCK.Titel ALBUMSONG.Titel 0.116
MUSIKSTÜCK.Titel SAMPLERSONG.Titel 0.116
MUSIKSTÜCK SAMPLERSONG 0.114
MUSIKSTÜCK ALBUMSONG 0.11
MUSIKSTÜCK.Interpret ALBUM.Künstlername 0.108
CD TITEL 0.104
MUSIKSTÜCK.Interpret TITEL.Künstlername 0.101
INTERPRET ALBUM 0.1
INTERPRET SAMPLER 0.093
ENTHÄLT.Interpret ALBUMSONG.Album 0.038
ENTHÄLT.Stück ALBUMSONG.Album 0.038
ENTHÄLT.Stück ALBUMSONG.Albuminterpret 0.038
MUSIKSTÜCK.Interpret ALBUMSONG.Album 0.03
MUSIKSTÜCK SAMPLER 0.028
... ... ...
Tabelle C.4.: Musiksammlung mit Vorverarbeitung (0.25) und manuellen Anpassungen
107

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
TAGESTOUR BUS 0.261
TAGESTOUR DATUM 0.226
STADT BUS 0.181
TAGESTOUR FAHRER 0.173
TAGESTOUR STAAT 0.164
BESUCHT ZUGETEILT 0.162
MIT ZUGETEILT 0.161
STADT DATUM 0.16
BUS BUS 0.146
TAGESTOUR TOUR 0.139
BUS DATUM 0.134
STADT FAHRER 0.129
STADT STAAT 0.124
BUS FAHRER 0.111
BUS STAAT 0.107
STADT TOUR 0.107
BESUCHT FÄHRT_DURCH 0.106
BESUCHT GEFAHREN_VON 0.106
MIT FÄHRT_DURCH 0.106
MIT GEFAHREN_VON 0.106
BESUCHT MIT 0.105
MIT MIT 0.105
BESUCHT BUS 0.101
BUS TOUR 0.099
BESUCHT DATUM 0.092
BESUCHT.Name FÄHRT_DURCH.SName 0.086
BESUCHT FAHRER 0.084
BESUCHT STAAT 0.084
MIT.Busnr FÄHRT_DURCH.SName 0.084
BESUCHT.Name GEFAHREN_VON.Busnr 0.082
BESUCHT.Name MIT.Busnr 0.082
BESUCHT.Tournr FÄHRT_DURCH.SName 0.08
MIT.Tournr FÄHRT_DURCH.SName 0.08
MIT.Busnr GEFAHREN_VON.Busnr 0.079
MIT.Busnr MIT.Busnr 0.079
BESUCHT.Name GEFAHREN_VON.FName 0.078
BESUCHT.Tournr GEFAHREN_VON.Busnr 0.078
BESUCHT.Tournr MIT.Busnr 0.078
MIT.Tournr GEFAHREN_VON.Busnr 0.078
... ... ...
Tabelle C.5.: Bustouren ohne Vorverarbeitung (0.5)
108

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
TAGESTOUR TOUR 0.339
MIT MIT 0.268
BUS BUS 0.267
MIT.Busnr MIT.Busnr 0.222
MIT.Busnr GEFAHREN_VON.Busnr 0.212
MIT.Tournr MIT.Tournr 0.208
BESUCHT.Name FÄHRT_DURCH.SName 0.199
BESUCHT.Tournr FÄHRT_DURCH.Tournr 0.199
BESUCHT.Tournr MIT.Tournr 0.198
MIT.Tournr FÄHRT_DURCH.Tournr 0.198
TAGESTOUR.Tournr TOUR.Tournr 0.198
BESUCHT.Tournr ZUGETEILT.Tournr 0.197
MIT.Tournr ZUGETEILT.Tournr 0.196
BESUCHT.Name GEFAHREN_VON.FName 0.194
BESUCHT.Name ZUGETEILT.FName 0.193
BUS.Busnr BUS.Busnr 0.191
STADT.Name FAHRER.FName 0.188
STADT.Name STAAT.SName 0.187
BESUCHT.Name FAHRER.FName 0.185
BESUCHT.Name STAAT.SName 0.185
BESUCHT.Tournr TOUR.Tournr 0.185
BUS.Busnr GEFAHREN_VON.Busnr 0.185
BUS.Busnr MIT.Busnr 0.185
MIT.Busnr BUS.Busnr 0.185
MIT.Tournr TOUR.Tournr 0.185
STADT.Name FÄHRT_DURCH.SName 0.185
STADT.Name GEFAHREN_VON.FName 0.185
STADT.Name ZUGETEILT.FName 0.185
TAGESTOUR.Tournr FÄHRT_DURCH.Tournr 0.185
TAGESTOUR.Tournr MIT.Tournr 0.185
TAGESTOUR.Tournr ZUGETEILT.Tournr 0.185
TAGESTOUR.Plätze BUS.Plätze 0.184
BESUCHT ZUGETEILT 0.076
BESUCHT FÄHRT_DURCH 0.075
STADT FAHRER 0.072
STADT STAAT 0.054
MIT GEFAHREN_VON 0.041
MIT ZUGETEILT 0.04
BESUCHT GEFAHREN_VON 0.038
... ... ...
Tabelle C.6.: Bustouren mit Vorverarbeitung (1.0)
109

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
TAGESTOUR TOUR 0.277
MIT MIT 0.2
BUS BUS 0.194
MIT.Busnr MIT.Busnr 0.143
MIT.Busnr GEFAHREN_VON.Busnr 0.131
MIT.Tournr MIT.Tournr 0.125
BESUCHT.Name FÄHRT_DURCH.SName 0.121
BESUCHT.Tournr FÄHRT_DURCH.Tournr 0.116
BESUCHT.Tournr MIT.Tournr 0.112
MIT.Tournr FÄHRT_DURCH.Tournr 0.112
BESUCHT.Tournr ZUGETEILT.Tournr 0.111
TAGESTOUR.Tournr TOUR.Tournr 0.111
BESUCHT.Name GEFAHREN_VON.FName 0.11
MIT.Tournr ZUGETEILT.Tournr 0.11
BESUCHT.Name ZUGETEILT.FName 0.109
BUS.Busnr BUS.Busnr 0.1
BESUCHT ZUGETEILT 0.098
STADT.Name FAHRER.FName 0.096
STADT.Name STAAT.SName 0.095
BESUCHT FÄHRT_DURCH 0.092
BESUCHT.Name FAHRER.FName 0.091
BESUCHT.Name STAAT.SName 0.091
BESUCHT.Tournr TOUR.Tournr 0.091
BUS.Busnr GEFAHREN_VON.Busnr 0.091
BUS.Busnr MIT.Busnr 0.091
MIT.Busnr BUS.Busnr 0.091
MIT.Tournr TOUR.Tournr 0.091
STADT.Name FÄHRT_DURCH.SName 0.091
STADT.Name GEFAHREN_VON.FName 0.091
STADT.Name ZUGETEILT.FName 0.091
TAGESTOUR.Tournr FÄHRT_DURCH.Tournr 0.091
TAGESTOUR.Tournr MIT.Tournr 0.091
TAGESTOUR.Tournr ZUGETEILT.Tournr 0.091
TAGESTOUR.Plätze BUS.Plätze 0.089
STADT FAHRER 0.081
STADT STAAT 0.062
MIT GEFAHREN_VON 0.057
MIT ZUGETEILT 0.057
BESUCHT GEFAHREN_VON 0.049
... ... ...
Tabelle C.7.: Bustouren mit Vorverarbeitung (0.25)
110

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
TAGESTOUR TOUR 0.304
MIT MIT 0.218
BUS BUS 0.211
MIT.Busnr MIT.Busnr 0.154
MIT.Busnr GEFAHREN_VON.Busnr 0.14
MIT.Tournr MIT.Tournr 0.134
BESUCHT.Name FÄHRT_DURCH.SName 0.13
BESUCHT.Tournr FÄHRT_DURCH.Tournr 0.123
BESUCHT.Tournr MIT.Tournr 0.119
MIT.Tournr FÄHRT_DURCH.Tournr 0.119
BESUCHT.Tournr ZUGETEILT.Tournr 0.118
TAGESTOUR.Tournr TOUR.Tournr 0.118
MIT.Tournr ZUGETEILT.Tournr 0.116
BESUCHT ZUGETEILT 0.105
BUS.Busnr BUS.Busnr 0.105
BESUCHT FÄHRT_DURCH 0.104
BESUCHT.Name ZUGETEILT.FName 0.104
STADT.Name STAAT.SName 0.099
BESUCHT.Name STAAT.SName 0.095
BESUCHT.Tournr TOUR.Tournr 0.095
BUS.Busnr GEFAHREN_VON.Busnr 0.095
BUS.Busnr MIT.Busnr 0.095
MIT.Busnr BUS.Busnr 0.095
MIT.Tournr TOUR.Tournr 0.095
STADT.Name FÄHRT_DURCH.SName 0.095
STADT.Name GEFAHREN_VON.FName 0.095
STADT.Name ZUGETEILT.FName 0.095
TAGESTOUR.Tournr FÄHRT_DURCH.Tournr 0.095
TAGESTOUR.Tournr MIT.Tournr 0.095
TAGESTOUR.Tournr ZUGETEILT.Tournr 0.095
TAGESTOUR.Plätze BUS.Plätze 0.093
STADT STAAT 0.069
MIT GEFAHREN_VON 0.064
MIT ZUGETEILT 0.063
BESUCHT MIT 0.055
MIT FÄHRT_DURCH 0.054
TAGESTOUR BUS 0.054
MIT.Tournr MIT.Busnr 0.028
STADT FAHRER 0.025
... ... ...
Tabelle C.8.: Bustouren mit Vorverarbeitung (0.25) und manuellen Anpassungen
111

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
FOTOGRAF ARTIKEL 0.309
FOTOGRAF FREIER_MITARBEITER 0.308
ZEITSCHRIFT ARTIKEL 0.268
ARTIKEL ARTIKEL 0.267
ARTIKEL FREIER_MITARBEITER 0.267
FOTOGRAF REDAKTEUR 0.266
AUTOR ARTIKEL 0.255
AUTOR FREIER_MITARBEITER 0.254
ARTIKEL REDAKTEUR 0.25
ZEITSCHRIFT FREIER_MITARBEITER 0.25
AUTOR REDAKTEUR 0.225
ZEITSCHRIFT REDAKTEUR 0.216
VERLAG ARTIKEL 0.21
VERLAG FREIER_MITARBEITER 0.21
VERLAG REDAKTEUR 0.182
ZEITSCHRIFT VERDIENT 0.161
LIEFERT_BILDER_FÜR VERDIENT 0.159
SCHREIBT VERDIENT 0.156
ERSCHIENEN_IN.Titel VERDIENT.für 0.153
ERSCHIENEN_IN.Titel VERDIENT.fM 0.15
ERSCHIENEN_IN.Titel ARTIKEL.verantw. 0.146
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.139
LIEFERT_BILDER_FÜR.ID VERDIENT.für 0.139
FOTOGRAF VERDIENT 0.136
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.133
ERSCHIENEN_IN VERDIENT 0.13
SCHREIBT.ID VERDIENT.fM 0.13
SCHREIBT.ID VERDIENT.für 0.13
SCHREIBT.ID ARTIKEL.verantw. 0.126
ARTIKEL VERDIENT 0.123
AUTOR VERDIENT 0.123
ZEITSCHRIFT.hrsg_von VERDIENT.fM 0.12
ZEITSCHRIFT.hrsg_von VERDIENT.für 0.12
LIEFERT_BILDER_FÜR ARTIKEL 0.119
SCHREIBT ARTIKEL 0.118
ZEITSCHRIFT.hrsg_von ARTIKEL.verantw. 0.113
VERLAG VERDIENT 0.11
ERSCHIENEN_IN ARTIKEL 0.104
LIEFERT_BILDER_FÜR.Titel ARTIKEL.verantw. 0.104
... ... ...
Tabelle C.9.: Verlag ohne Vorverarbeitung (0.5)
112

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
ARTIKEL ARTIKEL 0.495
ARTIKEL.Titel ARTIKEL.Titel 0.267
ARTIKEL.Länge ARTIKEL.Länge 0.264
ARTIKEL.Thema ARTIKEL.Thema 0.264
AUTOR.ID FREIER_MITARBEITER.PersonID 0.261
ERSCHIENEN_IN.Titel ARTIKEL.Titel 0.26
FOTOGRAF.ID FREIER_MITARBEITER.PersonID 0.26
VERLAG.Name REDAKTEUR.Name 0.26
AUTOR.Adresse FREIER_MITARBEITER.Adresse 0.258
AUTOR.Name FREIER_MITARBEITER.MName 0.258
ZEITSCHRIFT.Titel ARTIKEL.Titel 0.258
FOTOGRAF.Adresse FREIER_MITARBEITER.Adresse 0.257
FOTOGRAF.Name FREIER_MITARBEITER.MName 0.257
LIEFERT_BILDER_FÜR.ID FREIER_MITARBEITER.PersonID 0.256
LIEFERT_BILDER_FÜR.Titel ARTIKEL.Titel 0.256
SCHREIBT.ID FREIER_MITARBEITER.PersonID 0.256
SCHREIBT.Titel ARTIKEL.Titel 0.256
VERLAG.Name FREIER_MITARBEITER.MName 0.256
AUTOR.Name REDAKTEUR.Name 0.255
FOTOGRAF.Name REDAKTEUR.Name 0.255
AUTOR FREIER_MITARBEITER 0.214
FOTOGRAF FREIER_MITARBEITER 0.214
ZEITSCHRIFT ARTIKEL 0.08
AUTOR REDAKTEUR 0.076
FOTOGRAF REDAKTEUR 0.076
VERLAG REDAKTEUR 0.076
VERLAG FREIER_MITARBEITER 0.074
ERSCHIENEN_IN.Titel VERDIENT.für 0.071
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.059
SCHREIBT.ID VERDIENT.fM 0.059
LIEFERT_BILDER_FÜR.Titel VERDIENT.für 0.047
SCHREIBT.Titel VERDIENT.für 0.047
LIEFERT_BILDER_FÜR VERDIENT 0.03
SCHREIBT VERDIENT 0.03
ERSCHIENEN_IN VERDIENT 0.021
ZEITSCHRIFT.hrsg_von ARTIKEL.verantw. 0.021
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.02
SCHREIBT.ID ARTIKEL.verantw. 0.02
ZEITSCHRIFT.hrsg_von VERDIENT.fM 0.019
... ... ...
Tabelle C.10.: Verlag mit Vorverarbeitung (1.0)
113

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
ARTIKEL ARTIKEL 0.409
AUTOR FREIER_MITARBEITER 0.232
FOTOGRAF FREIER_MITARBEITER 0.232
ERSCHIENEN_IN.Titel VERDIENT.für 0.146
ARTIKEL.Titel ARTIKEL.Titel 0.134
ARTIKEL.Länge ARTIKEL.Länge 0.129
ARTIKEL.Thema ARTIKEL.Thema 0.129
AUTOR.ID FREIER_MITARBEITER.PersonID 0.128
VERLAG.Name REDAKTEUR.Name 0.127
FOTOGRAF.ID FREIER_MITARBEITER.PersonID 0.126
ERSCHIENEN_IN.Titel ARTIKEL.Titel 0.125
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.124
SCHREIBT.ID VERDIENT.fM 0.124
ZEITSCHRIFT.Titel ARTIKEL.Titel 0.123
AUTOR.Adresse FREIER_MITARBEITER.Adresse 0.122
AUTOR.Name FREIER_MITARBEITER.MName 0.122
FOTOGRAF.Adresse FREIER_MITARBEITER.Adresse 0.12
FOTOGRAF.Name FREIER_MITARBEITER.MName 0.12
LIEFERT_BILDER_FÜR.ID FREIER_MITARBEITER.PersonID 0.119
LIEFERT_BILDER_FÜR.Titel ARTIKEL.Titel 0.119
SCHREIBT.ID FREIER_MITARBEITER.PersonID 0.119
SCHREIBT.Titel ARTIKEL.Titel 0.119
AUTOR.Name REDAKTEUR.Name 0.118
VERLAG.Name FREIER_MITARBEITER.MName 0.118
ZEITSCHRIFT ARTIKEL 0.118
FOTOGRAF.Name REDAKTEUR.Name 0.117
LIEFERT_BILDER_FÜR VERDIENT 0.114
SCHREIBT VERDIENT 0.114
AUTOR REDAKTEUR 0.101
FOTOGRAF REDAKTEUR 0.101
VERLAG REDAKTEUR 0.099
VERLAG FREIER_MITARBEITER 0.093
ERSCHIENEN_IN VERDIENT 0.083
LIEFERT_BILDER_FÜR.Titel VERDIENT.für 0.081
SCHREIBT.Titel VERDIENT.für 0.081
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.052
SCHREIBT.ID ARTIKEL.verantw. 0.052
ZEITSCHRIFT.hrsg_von ARTIKEL.verantw. 0.049
ZEITSCHRIFT.hrsg_von VERDIENT.fM 0.045
... ... ...
Tabelle C.11.: Verlag mit Vorverarbeitung (0.25)
114

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
ARTIKEL ARTIKEL 0.463
AUTOR FREIER_MITARBEITER 0.273
FOTOGRAF FREIER_MITARBEITER 0.273
LIEFERT_BILDER_FÜR.ID VERDIENT.fM 0.155
SCHREIBT.ID VERDIENT.fM 0.155
LIEFERT_BILDER_FÜR VERDIENT 0.15
SCHREIBT VERDIENT 0.15
ARTIKEL.Titel ARTIKEL.Titel 0.144
ARTIKEL.Länge ARTIKEL.Länge 0.138
ARTIKEL.Thema ARTIKEL.Thema 0.138
AUTOR.ID FREIER_MITARBEITER.PersonID 0.137
FOTOGRAF.ID FREIER_MITARBEITER.PersonID 0.134
ERSCHIENEN_IN.Titel ARTIKEL.Titel 0.132
AUTOR.Adresse FREIER_MITARBEITER.Adresse 0.13
AUTOR.Name FREIER_MITARBEITER.MName 0.13
FOTOGRAF.Adresse FREIER_MITARBEITER.Adresse 0.128
FOTOGRAF.Name FREIER_MITARBEITER.MName 0.128
AUTOR.Name REDAKTEUR.Name 0.126
LIEFERT_BILDER_FÜR.ID FREIER_MITARBEITER.PersonID 0.126
LIEFERT_BILDER_FÜR.Titel ARTIKEL.Titel 0.126
SCHREIBT.ID FREIER_MITARBEITER.PersonID 0.126
SCHREIBT.Titel ARTIKEL.Titel 0.126
AUTOR REDAKTEUR 0.124
FOTOGRAF REDAKTEUR 0.124
FOTOGRAF.Name REDAKTEUR.Name 0.124
ERSCHIENEN_IN.Titel VERDIENT.für 0.118
LIEFERT_BILDER_FÜR.Titel VERDIENT.für 0.098
SCHREIBT.Titel VERDIENT.für 0.098
ERSCHIENEN_IN VERDIENT 0.075
LIEFERT_BILDER_FÜR.ID ARTIKEL.verantw. 0.069
SCHREIBT.ID ARTIKEL.verantw. 0.069
ERSCHIENEN_IN.Titel VERDIENT.fM 0.04
LIEFERT_BILDER_FÜR ARTIKEL 0.04
SCHREIBT ARTIKEL 0.04
LIEFERT_BILDER_FÜR.ID VERDIENT.für 0.033
SCHREIBT.ID VERDIENT.für 0.033
ARTIKEL REDAKTEUR 0.029
ZEITSCHRIFT ARTIKEL 0.029
ARTIKEL FREIER_MITARBEITER 0.028
... ... ...
Tabelle C.12.: Verlag mit Vorverarbeitung (0.25) und manuellen Anpassungen
115

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
MOVIE PRODUCTION 0.165
PERSON PERSON 0.157
MOVIE PERSON 0.132
PERSON PRODUCTION 0.087
PERSON RELEASE 0.07
PART PERSON 0.066
PERSON SERIES 0.059
PERSON EPISODE 0.058
PERSON QUOTE 0.058
QUOTE PERSON 0.058
MOVIE SERIES 0.053
PART PRODUCTION 0.053
AKA PERSON 0.046
BUDGET PERSON 0.046
LOCATION PERSON 0.046
PERSON AKA 0.046
PERSON BUDGET 0.046
PERSON LOCATION 0.046
PERSON RATING 0.046
PERSON WORKS 0.046
RATING PERSON 0.046
RELEASE PERSON 0.046
MOVIE RELEASE 0.044
MOVIE EPISODE 0.039
MOVIE QUOTE 0.039
PART RELEASE 0.038
PART EPISODE 0.037
QUOTE RELEASE 0.037
QUOTE PRODUCTION 0.036
CHARACTER PERSON 0.035
COUNTRY PERSON 0.035
GENRE PERSON 0.035
KEYWORD PERSON 0.035
LANGUAGE PERSON 0.035
LINK PERSON 0.035
PART QUOTE 0.035
PART SERIES 0.035
PERSON COUNTRY 0.035
PERSON GENRE 0.035
... ... ...
Tabelle C.13.: MovieDB ohne Vorverarbeitung (0.5)
116

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
PERSON PERSON 0.795
QUOTE QUOTE 0.3
AKA AKA 0.264
BUDGET BUDGET 0.264
LOCATION LOCATION 0.264
RATING RATING 0.264
LINK LINK 0.229
COUNTRY COUNTRY 0.228
GENRE GENRE 0.228
KEYWORD KEYWORD 0.228
LANGUAGE LANGUAGE 0.228
MOVIE MOVIE 0.228
RELEASE RELEASE 0.228
PART.person PARENTS.person 0.217
PART.person PLAYS.person 0.217
PART.person WORKS.person 0.216
COUNTRY.country COUNTRY.country 0.207
GENRE.genre GENRE.genre 0.207
KEYWORD.keyword KEYWORD.keyword 0.207
LANGUAGE.language LANGUAGE.language 0.207
AKA.aka AKA.aka 0.196
AKA.country AKA.country 0.196
BUDGET.budget BUDGET.budget 0.196
BUDGET.currency BUDGET.currency 0.196
LOCATION.country LOCATION.country 0.196
LOCATION.location LOCATION.location 0.196
RATING.rating RATING.rating 0.196
RATING.votes RATING.votes 0.196
LINK.link LINK.link 0.195
MOVIE.type MOVIE.type 0.194
QUOTE.dialog QUOTE.dialog 0.192
QUOTE.line QUOTE.line 0.192
QUOTE.quote QUOTE.quote 0.191
RELEASE.country RELEASE.country 0.191
AKA.country COUNTRY.country 0.188
COUNTRY.country AKA.country 0.188
COUNTRY.country LOCATION.country 0.188
LOCATION.country COUNTRY.country 0.188
RELEASE.country COUNTRY.country 0.188
... ... ...
Tabelle C.14.: MovieDB mit Vorverarbeitung (1.0)
117

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
PERSON PERSON 0.787
QUOTE QUOTE 0.207
AKA AKA 0.172
BUDGET BUDGET 0.171
LOCATION LOCATION 0.171
RATING RATING 0.171
PART.person PARENTS.person 0.149
PART.person PLAYS.person 0.146
MOVIE PRODUCTION 0.145
PART.person WORKS.person 0.145
LOCATION PERSON 0.142
PERSON LOCATION 0.142
LINK LINK 0.137
COUNTRY COUNTRY 0.136
GENRE GENRE 0.136
KEYWORD KEYWORD 0.136
LANGUAGE LANGUAGE 0.136
MOVIE MOVIE 0.136
RELEASE RELEASE 0.136
COUNTRY.country COUNTRY.country 0.112
GENRE.genre GENRE.genre 0.112
KEYWORD.keyword KEYWORD.keyword 0.112
LANGUAGE.language LANGUAGE.language 0.112
PART PARENTS 0.102
AKA.aka AKA.aka 0.1
AKA.country AKA.country 0.1
BUDGET.budget BUDGET.budget 0.1
BUDGET.currency BUDGET.currency 0.1
LOCATION.country LOCATION.country 0.1
LOCATION.location LOCATION.location 0.1
RATING.rating RATING.rating 0.1
RATING.votes RATING.votes 0.1
LINK.link LINK.link 0.098
MOVIE.type MOVIE.type 0.098
QUOTE.dialog QUOTE.dialog 0.096
QUOTE.line QUOTE.line 0.096
QUOTE.quote QUOTE.quote 0.095
RELEASE.country RELEASE.country 0.094
AKA.country COUNTRY.country 0.092
... ... ...
Tabelle C.15.: MovieDB mit Vorverarbeitung (0.25)
118

Schema 1 Schema 2 Ähnlichkeitswert
Primary Key Primary Key 1.0
PERSON PERSON 0.599
MOVIE PRODUCTION 0.542
QUOTE QUOTE 0.316
AKA AKA 0.283
BUDGET BUDGET 0.283
LINK LINK 0.283
LOCATION LOCATION 0.283
RATING RATING 0.283
RELEASE RELEASE 0.283
COUNTRY COUNTRY 0.25
GENRE GENRE 0.25
KEYWORD KEYWORD 0.25
LANGUAGE LANGUAGE 0.25
PART.person PARENTS.person 0.202
COUNTRY.country COUNTRY.country 0.201
COUNTRY.movie COUNTRY.production 0.201
GENRE.genre GENRE.genre 0.201
GENRE.movie GENRE.production 0.201
KEYWORD.keyword KEYWORD.keyword 0.201
KEYWORD.movie KEYWORD.production 0.201
LANGUAGE.language LANGUAGE.language 0.201
LANGUAGE.movie LANGUAGE.production 0.201
AKA.movie AKA.production 0.189
BUDGET.movie BUDGET.production 0.189
LINK.movie1 LINK.production1 0.189
LINK.movie2 LINK.production2 0.189
LOCATION.movie LOCATION.production 0.189
RATING.movie RATING.production 0.189
AKA.aka AKA.aka 0.188
AKA.country AKA.country 0.188
BUDGET.budget BUDGET.budget 0.188
BUDGET.currency BUDGET.currency 0.188
LINK.link LINK.link 0.188
LOCATION.country LOCATION.country 0.188
LOCATION.location LOCATION.location 0.188
RATING.rating RATING.rating 0.188
RATING.votes RATING.votes 0.188
CHARACTER WORKS 0.184
QUOTE.dialog QUOTE.dialog 0.184
... ... ...
Tabelle C.16.: MovieDB mit Vorverarbeitung (0.25) nach Wiederholung des Verfahrens
119