- Fachgebiet Datenbanken und Informationssysteme

Transcription

Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Datenbanken und Informationssysteme
String-basiertes Matching von
Datenbank-Objekten
Masterarbeit
im Studiengang Informatik
Andreas Prante
Matrikelnummer: 2296160
Prüfer: Prof. Dr. Udo Lipeck
Zweitprüfer: Dr. Hans Hermann Brüggemann
Betreuer: M. Sc. Hendrik Warneke
3. Mai 2012
Inhaltsverzeichnis
1 Einleitung
3
2 Algorithmen
5
2.1
Edit-Distance / Levenshtein-Distance . . . . . . . . . . . . . . . . . . . .
5
2.2
Damerau-Levenshtein . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3
Soundex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4
Kölner Phonetik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.5
Jaro-Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.6
Field Similarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.7
Q-Grams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.8
N-Gramme
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.9
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3 Kombination von Algorithmen für die Duplikaterkennung
23
3.1
Hintereinander-Ausführung von Algorithmen . . . . . . . . . . . . . . . .
23
3.2
Parallele-Ausführung von Algorithmen . . . . . . . . . . . . . . . . . . .
24
3.3
Kombination über die Länge von Vektoren . . . . . . . . . . . . . . . . .
25
3.4
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4 Sorted Neighborhood Methode(SNM)
29
5 Experimente
33
5.1
Bewertungskriterien der Algorithmen . . . . . . . . . . . . . . . . . . . .
33
5.2
Experimente: Analyse der Brute Force Strategie . . . . . . . . . . . . . .
35
5.3
Experimente: Analyse der Sorted Neighborhood Methode . . . . . . . . .
39
1
5.4
Experimente: Analyse der vorhandenen Datenquellen . . . . . . . . . . .
6 Implementierung
50
55
6.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.2
Programmaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.3
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.4
Benutzeroberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
6.5
Installation und Deinstallation . . . . . . . . . . . . . . . . . . . . . . . .
77
6.6
Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
7 Erweiterung auf Datenbankobjekte
83
7.1
Ähnlichkeit von Datenbankobjekten . . . . . . . . . . . . . . . . . . . . .
83
7.2
Fortgeschrittene Experimente . . . . . . . . . . . . . . . . . . . . . . . .
84
7.3
Erweiterung der Implementation . . . . . . . . . . . . . . . . . . . . . . .
85
8 Ausblick
87
8.1
Ähnlichkeitsmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
8.2
Anzahl der Vergleiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
8.3
Anwendungsgebiete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
A SQL und PL/SQL
91
B XSLT
93
C Experimente
95
2
Kapitel 1
Einleitung
Heutzutage gibt es immer mehr Datenbanken, die auf der Dateneingabe von vielen Nutzern basieren. Hieraus ergibt sich das Problem, dass häufig für ein Objekt in der realen
Welt mehrere Beschreibungen in der Datenbank vorhanden sind. Diese entstehen durch
Tippfehler oder auch durch die Verwendung anderer Schreibweisen. So werden z.B. manche Begriffe durch Leerzeichen oder auch durch Bindestriche getrennt, obwohl in beiden
Fällen das selbe Objekt in der realen Welt dargestellt wird. Unterschiede entstehen aber
auch durch die Verwendung von unterschiedlichen Sprachen. Weiterhin zu erwähnen ist
die Disziplin der Nutzer, denn gerade in von Nutzern gefüllten Datenbeständen ist es sehr
wichtig, dass sich ein Nutzer sehr diszipliniert z.B. an Vorgaben für die Bezeichnung von
Objekten hält. Durch diese Probleme wird es sehr schwierig und problematisch, z.B. eine
Suche über solche Datenbestände durchzuführen. Um diese Daten nutzen zu können, ist
es notwendig, dass diese Synonyme erkannt werden und möglichst nur eine Repräsentation eines Objektes der realen Welt in der Datenbank verbleibt. Hieraus ergibt sich die
Aufgabenstellung dieser Arbeit.
Diese Arbeit soll das Matching von Datenbank-Objekten betrachten. Basieren soll dieses
Matching auf dem Matching von Strings. Hierzu sollen zunächst verschiedene Algorithmen zur Bestimmung der Ähnlichkeit von zwei Strings betrachtet und danach anhand
der Betrachtung von praktischen Beispielen analysiert sowie bewertet werden. Danach
soll eine Kombination der betrachteten Algorithmen gewählt werden, die aus der Datenquelle die entsprechenden Matchingpartner berechnen. Diese Kombination soll ebenfalls
genutzt werden, um den Vergleich der Strings auf den Vergleich von Datenbank-Objekten
zu erweitern. Zusätzlich sollen in der Arbeit die Möglichkeiten des Einsatzes von Methoden des Data Mining, die beim Matching der Datenbank-Objekte eingesetzt werden
könnten, um z.B. eine geeignete Vorauswahl der betrachteten Daten zu treffen, betrachtet
werden. Für die spätere Implementation soll analysiert werden, inwieweit ein Anwender
über Vorwissen über die verwendete Datenbank verfügen muss, um die Analyse der Daten durchzuführen, oder ob diese ohne bzw. mit minimalem Vorwissen erfolgen kann.
3
Die Arbeit ist wie folgt aufgebaut: Nach diesem Kapitel als Einleitung der Arbeit, wird
im Kapitel Algorithmen(Kap. 2) eine Auswahl von Algorithmen zur Berechnung der
Ähnlichkeit von Strings vorgestellt. Der Aufbau, die Funktionsweise sowie weitere wichtige Eigenschaften der Algorithmen werden genannt und beschrieben. Im nachfolgenden
Kapitel Kombination von Algorithmen für die Duplikaterkennung(Kap. 3) werden die
grundlegenden Ideen zur Kombination bzw. zur effizienten Berechnung der Ähnlichkeitsmaße für komplette Datensätze dargestellt und erläutert. Im Kapitel 4 wird die Sorted
Neighborhood Methode(SNM) vorgestellt und analysiert. Im Kapitel Experimente(Kap.
5) werden die vorgestellten Ansätze und Algorithmen praktisch ausgeführt und die daraus resultierenden Ergebnisse ausgewertet. Daraus sollen evtl. notwendige Eigenschaften
für die spätere Implementierung erfasst werden. Zudem werden in diesem Kapitel die verwendeten Datenquellen vorgestellt. Die endgültige Implementierung wird anschließend
im Kapitel Implementierung(Kap. 6) betrachtet. Im Kapitel 7 wird die Erweiterung auf
Datenbankobjekte betrachten. Zum Schluss der Arbeit folgt ein Ausblick(Kap. 8) auf
weiterführende Aspekte der betrachteten Problematik.
4
Kapitel 2
Algorithmen
Im diesem Kapitel werden mögliche Algorithmen vorgestellt, die später zur Berechnung
eines Ähnlichkeitsmaßes verwendet werden. Es wird jeweils kurz der Ablauf des Algorithmus beschrieben, das im Algorithmus verwendete Ähnlichkeitsmaß erläutert sowie Vorund Nachteile der einzelnen Algorithmen aufgelistet. Anschließend folgen kurze Beispiele
zur Verdeutlichung der Funktionsweise. Die vorgestellten Algorithmen werden nach den
im Kapitel 3 dargestellten Ideen kombiniert und anschließend getestet. Die Ergebnisse
der Tests werden im Kapitel 5 dargestellt.
2.1
Edit-Distance / Levenshtein-Distance
Beim Verfahren der Edit-Distance[LN2007], auch bekannt als Levenshtein-Distance, betrachtet man die Differenzen zweier Strings, in dem die notwendigen Änderung berechnet
werden, um den einen String in den anderen String zu überführen. Zur Berechnung der
Überführung des einen Strings in den anderen stehen vier Operationen zur Verfügung:
• I: Einfügen
• D: Löschen
• R: Ersetzen
• M : Match
Mit Hilfe dieser Operation lassen sich sog. Editskripte definieren. Ein Editskript e für
zwei Strings A, B ist eine Sequenz der o.g. Operationen, so dass
e(A) = B.
5
(2.1)
Die Länge eines Editskripts ist die Anzahl der Operationen in einem Editskript, allerdings wird matchen“ nicht gezählt. Die Edit-Distance zweier Strings ist die Länge des
”
kürzestes Editskripts.
Zur Bestimmung des Ähnlichkeitsmaßes gilt es zunächst die Edit-Distance zweier Strings
zu bestimmen. Leser/Naumann[LN2007] führen die Berechnung der Edit-Distance zweier Strings auf die Berechnung der Distance der einzelnen Präfixe zurück. Hierbei gilt:
seien A, B zwei Strings mit |A| = n und |B| = m. d(i, j) ist definiert als Edit-Distance
des Präfixes der Länge i von A und des Präfixes der Länge j von B. Daraus folgt
d(n, m) = dist(A, B)
(2.2)
mit dist(A, B) berechne den Editabstand der Strings A und B. dist(A, B) wird rekursiv
mit Hilfe von d(i, j) berechnet. Als Struktur zur Speicherung der einzelnen d(i, j) wird
eine n × m − M atrix verwendet. Für die einzelnen d(i, j) gilt:


 d(i − 1, j) + 1

d(i, j) = min d(i, j − 1) + 1
(2.3)


d(i − 1, j − 1) + t(i, j)
mit d(i, 0) = i, d(0, j) = j und
{
t(i, j) =
1, wenn A[i] ̸= B[j]
0, sonst
}
(2.4)
Der Aufbau der Matrix wird durch das folgende Beispiel, der Berechnung der EditDistance der Strings Ostlandstraße“ und Otslandstraße“, verdeutlicht. Seien A und B
”
”
zwei Strings, für die gilt:
A = Ostlandstraße
B = Otslandstraße
Aus der Berechnung der einzelnen d(i, j) folgt die Matrix, die in Tabelle 2.1 dargestellt
wird. Wie in Tabelle 2.1 zu erkennen ist, gilt im genannten Beispiel
d(n, m) = 2.
(2.5)
Somit haben die Strings A und B eine Edit-Distance von 2.
Das Ähnlichkeitsmaß wird mit folgender Formel berechnet:
simedit−dist (A, B) := 1 −
dist(A, B)
max(|A|, |B|)
(2.6)
Für das oben genannte Beispiel ergibt sich mit der Formel für die Berechnung des Ähnlichkeitsmaßes folgendes:
2
max(13, 13)
simedit−dist (A, B) = 0.8462
simedit−dist (A, B) = 1 −
6
0 1 2 3 4
1 0 1 2 3
2 1 1 1 2
3 2 1 2 2
4 3 2 2 2
5 4 3 3 3
6 5 4 4 4
7 6 5 5 5
8 7 6 5 6
9 8 7 6 6
10 9 8 7 7
11 10 9 8 8
12 11 10 9 9
13 12 11 10 10
5
4
3
3
3
2
3
4
5
6
7
7
8
9
6
5
4
4
4
3
2
3
4
5
6
7
8
9
7
6
5
5
5
4
3
2
3
4
5
6
7
8
8
7
6
6
6
5
4
3
2
3
4
5
6
7
9 10 11 12 13
8 9 10 11 12
7 8 9 10 11
6 7 8 9 10
7 7 8 9 10
6 7 7 8 9
5 6 7 8 9
4 5 6 7 8
3 4 5 6 7
2 3 4 5 6
3 2 3 4 5
4 3 2 3 4
5 4 3 2 3
6 5 4 3 2
Tabelle 2.1: Matrix für das o.g. Edit-Distance-Beispiel
Der folgende Algorithmus in Pseudo-Code berechnet die Ähnlichkeit von zwei Strings.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
editdistance(String A, String B) {
for (i = 0 ; i < A.length() ; i++) {
d(i,0) = i;
}
for (j = 0 ; j < B.length() ; j++) {
d(0,j) = j;
}
for (i = 1 ; i < A.length() ; i++) {
for (j = 1 ; j < B.length() ; j++) {
if (A.charAt(i).equals(B.charAt(j))) {
t = 0;
}
else {
t = 1;
}
d(i,j) = min(d(i-1,j)+1,d(i,j-1)+1,d(i-1,j-1)+t);
}
}
return d(n,m);
}
Algorithmus 2.1: Algorithmus zur Bestimmung der Edit-Distance
7
Die Laufzeit des angegebenen Algorithmus ergibt sich aus der Berechnung der Matrix
d. Die Matrix hat eine Größe von n × m für zwei Strings A und B mit |A| = n und
|B| = m. Da alle Zellen der Matrix d berechnet werden müssen und für die Berechnung
einer Zelle eine konstante Anzahl von Rechenoperationen notwendig ist, ergibt sich eine
Laufzeit von
O(n ∗ m).
(2.7)
Vorteil der Edit-Distance ist, dass dieses Maß unabhängig von der zu erkennenden Sprache ist. Somit kann das Maß auch bei Datenquellen zur Anwendung kommen, die Elemente aus verschiedenen Sprachen enthalten. Nachteil der Edit-Distance ist, dass die
Eingabestrings nur in der Reihenfolge ihrer Eingabe betrachtet werden. Daraus folgt,
dass z. B. die Strings “Hans Peter” und “Peter Hans” als nicht sehr ähnlich angesehen
werden.
2.2
Damerau-Levenshtein
Beim Damerau-Levenshtein-Verfahren[Le0809] erfolgt die Berechnung analog zum EditDistance-Verfahren. Die Damerau-Levenshtein-Distance unterscheidet sich von der EditDistance lediglich in der Berechnung der einzelnen d(i, j) und der Gewichte t(i, j). Beim
Damerau-Levenshtein-Verfahren werden die einzelnen Distanzen d(i, j) in folgender Form
berechnet:


d(i − 1, j) + 1






d(i, j − 1) + 1
(2.8)
d(i, j) = min
d(i − 1, j − 1) + t(i, j)






d(i − 2, j − 2) + t(i − 1, j) + t(i, j − 1)
mit d(i, 0) = i, d(0, j) = j. Die Kosten t(i, j) für eine Replace-Operation werden in
Abhängigkeit vom Abstand der einzelnen Buchstaben auf der Tastatur berechnet. Der
Abstand der einzelnen Buchstaben wird wie folgt bestimmt: es werden die Tasten gezählt, die man auf dem kürzesten Weg zwischen zwei Tasten besucht. Liegen zwei Tasten
in verschiedenen Reihen der Tastatur, erfolgt ein Sprung in eine andere Reihe über eine
anliegende Taste der entsprechenden Ebene und wird das ebenfalls mit 1 bewertet. Abbildung 2.1 macht dies deutlich. Die Kosten t(i, j) für eine Replace-Operation berechnen
sich nach folgendem Ansatz: sei n(i, j) der Abstand zwischen der Taste i und der Taste
j auf der Tastatur. Die einzelnen Kosten werden dann mit der Formel
t(i, j) =
n(i, j)
10
(2.9)
berechnet. Mit Hilfe dieser Formel lassen sich die in der Tabelle 2.2 dargestellten Werte
berechnen. Die Tabelle kann einmalig berechnet werden, da sie sich nicht ändert, sondern konstant ist. Einzige Ausnahme wäre die Verwendung einer englischen Tastatur
8
Abbildung 2.1: Abstand der Tasten R und B auf einer Tastatur
und der damit verbundenen Vertauschung der Tasten y“ und z“. Da das Verfahren
”
”
eine Weiterentwicklung der Edit-Distance ist, besitzt das Verfahren die selben Vor- und
Nachteile. Allerdings hat das Verfahren weitere Vorteile. Durch die Unterscheidung bei
der Berechnung der Kosten für eine Replace-Operation werden Tipp-Fehler ausgeglichen,
da Buchstaben, die auf der Tastatur nahe beieinander liegen, mit einem geringeren Gewicht bewertet werden. Der Algorithmus des Verfahrens ist analog zum Algorithmus der
Edit-Distance. Somit ergibt sich auch die selbe Laufzeit für dieses Verfahren von
O(n ∗ m).
(2.10)
Die Funktionsweise des Verfahrens soll durch die folgenden Beispiele kurz dargestellt
werden. Bestimmung der Ähnlichkeit für die Strings Ostlandstraße“ und Otslandstra”
”
ße“, seien A und B zwei Strings, für die gilt:
A = Ostlandstraße
B = Otslandstraße
Aus dem Algorithmus folgt Tabelle 2.3 und eine Damerau-Levenshtein-Distance von 0.6.
dist(A, B)
max(|A|, |B|)
0.60
simdamerau−levenshtein−dist (A, B) = 1 −
max(13, 13)
simdamerau−levenshtein−dist (A, B) = 0.9538
simdamerau−levenshtein−dist (A, B) = 1 −
9
10
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
a
0
0.5
0.3
0.2
0.2
0.3
0.4
0.5
0.7
0.6
0.7
0.8
0.6
0.7
0.8
0.9
0.1
0.3
0.1
0.4
0.6
0.4
0.1
0.2
0.1
0.5
b
0.5
0
0.2
0.3
0.4
0.2
0.1
0.1
0.3
0.2
0.3
0.4
0.2
0.1
0.4
0.5
0.6
0.3
0.4
0.2
0.2
0.1
0.5
0.2
0.3
0.2
c
0.3
1
0
0.1
0.2
0.1
0.2
0.3
0.5
0.4
0.5
0.6
0.4
0.3
0.6
0.7
0.4
0.2
0.2
0.2
0.4
0.1
0.3
0.1
0.2
0.3
d
0.2
0.3
0.1
0
0.1
0.1
0.2
0.3
0.5
0.4
0.5
0.6
0.5
0.4
0.6
0.7
0.3
0.1
0.1
0.2
0.4
0.2
0.2
0.1
0.2
0.3
f
0.3
0.2
0.1
0.1
0.2
0
0.1
0.2
0.4
0.3
0.4
0.5
0.4
0.3
0.5
0.6
0.4
0.1
0.2
0.1
0.3
0.1
0.3
0.2
0.3
0.2
g
0.4
0.1
0.2
0.2
0.3
0.1
0
0.1
0.3
0.2
0.3
0.4
0.3
0.2
0.4
0.5
0.5
0.2
0.3
0.1
0.2
0.1
0.4
0.3
0.4
0.1
h
0.5
0.1
0.3
0.3
0.4
0.2
0.1
0
0.2
0.1
0.2
0.3
0.2
0.1
0.3
0.4
0.6
0.3
0.4
0.2
0.1
0.2
0.5
0.4
0.5
0.1
i
0.7
0.3
0.5
0.5
0.5
0.4
0.3
0.2
0
0.1
0.1
0.2
0.2
0.2
0.1
0.2
0.7
0.4
0.6
0.3
0.1
0.4
0.6
0.6
0.7
0.2
j
0.6
0.2
0.4
0.4
0.5
0.3
0.2
0.1
0.1
0
0.1
0.2
0.1
0.1
0.2
0.3
0.7
0.4
0.5
0.3
0.1
0.3
0.6
0.5
0.6
0.2
k
0.7
0.3
0.5
0.5
0.6
0.4
0.3
0.2
0.1
0.1
0
0.1
0.1
0.2
0.1
0.2
0.8
0.5
0.6
0.4
0.2
0.4
0.7
0.6
0.7
0.3
l
0.8
0.4
0.6
0.6
0.7
0.5
0.4
0.3
0.2
0.2
0.1
0
0.2
0.3
0.1
0.1
0.9
0.6
0.7
0.5
0.3
0.5
0.8
0.7
0.8
0.4
m
0.7
0.2
0.4
0.5
0.6
0.4
0.3
0.2
0.2
0.1
0.1
0.2
0
0.1
0.2
0.3
0.8
0.5
0.6
0.4
0.2
0.3
0.7
0.5
0.6
0.3
n
0.6
0.1
0.3
0.4
0.5
0.3
0.2
0.1
0.2
0.1
0.2
0.3
0.1
0
0.3
0.4
0.7
0.4
0.5
0.3
0.2
0.2
0.6
0.4
0.5
0.2
o
0.8
0.4
0.6
0.6
0.6
0.5
0.4
0.3
0.1
0.2
0.1
0.1
0.2
0.3
0
0.1
0.8
0.5
0.7
0.4
0.2
0.5
0.7
0.7
0.8
0.3
p
0.9
0.5
0.7
0.7
0.7
0.6
0.5
0.4
0.2
0.3
0.2
0.1
0.3
0.4
0.1
0
0.9
0.6
0.8
0.5
0.3
0.6
0.8
0.8
0.9
0.4
q
0.1
0.6
0.4
0.3
0.2
0.4
0.5
0.6
0.7
0.7
0.8
0.9
0.8
0.7
0.8
0.9
0
0.3
0.2
0.4
0.6
0.5
0.1
0.3
0.2
0.5
r
0.3
0.3
0.2
0.1
0.1
0.1
0.2
0.3
0.4
0.4
0.5
0.6
0.5
0.4
0.5
0.6
0.3
0
0.2
0.1
0.3
0.2
0.2
0.2
0.3
0.3
s
0.1
0.4
0.2
0.1
0.2
0.2
0.3
0.4
0.6
0.5
0.6
0.7
0.6
0.5
0.7
0.8
0.2
0.2
0
0.3
0.5
0.3
0.1
0.1
0.1
0.4
t
0.4
0.2
0.2
0.2
0.2
0.1
0.1
0.2
0.3
0.3
0.4
0.5
0.4
0.3
0.4
0.5
0.4
0.1
0.3
0
0.2
0.2
0.3
0.3
0.4
0.1
u
0.6
0.2
0.4
0.4
0.4
0.3
0.2
0.1
0.1
0.1
0.2
0.3
0.2
0.2
0.2
0.3
0.6
0.3
0.5
0.2
0
0.3
0.5
0.5
0.6
0.1
Tabelle 2.2: Gewichte t(i, j) für das Maß des Abstandes auf der Tastatur
e
0.2
0.4
0.2
0.1
0
0.2
0.3
0.4
0.5
0.5
0.6
0.7
0.6
0.5
0.6
0.7
0.2
0.1
0.2
0.2
0.4
0.3
0.1
0.2
0.2
0.3
v
0.4
0.1
0.1
0.2
0.3
0.1
0.1
0.2
0.4
0.3
0.4
0.5
0.3
0.2
0.5
0.6
0.5
0.2
0.3
0.2
0.3
0
0.4
0.2
0.3
0.2
w
0.1
0.5
0.3
0.2
0.1
0.3
0.4
0.5
0.6
0.6
0.7
0.8
0.7
0.6
0.7
0.8
0.1
0.2
0.1
0.3
0.5
0.4
0
0.2
0.2
0.4
x
0.2
0.2
0.1
0.1
0.2
0.2
0.3
0.4
0.6
0.5
0.6
0.7
0.5
0.4
0.7
0.8
0.3
0.2
0.1
0.3
0.5
0.2
0.2
0
0.1
0.4
y
0.1
0.3
0.2
0.2
0.2
0.3
0.4
0.5
0.7
0.6
0.7
0.8
0.6
0.5
0.8
0.9
0.2
0.3
0.1
0.4
0.6
0.3
0.2
0.1
0
0.5
z
0.5
0.2
0.3
0.3
0.3
0.2
0.1
0.1
0.2
0.2
0.3
0.4
0.3
0.2
0.3
0.4
0.5
0.3
0.4
0.1
0.1
0.2
0.4
0.4
0.5
0
0,0
1,0
2,0
3,0
4,0
5,0
6,0
7,0
8,0
9,0
10,0
11,0
12,0
13,0
1,0
0,0
1,0
2,0
3,0
4,0
5,0
6,0
7,0
8,0
9,0
10,0
11,0
12,0
2,0
1,0
0,3
1,0
2,0
3,0
4,0
5,0
6,0
7,0
8,0
9,0
10,0
11,0
3,0
2,0
1,0
0,6
1,6
2,1
3,1
4,1
5,0
6,0
7,0
8,0
9,0
10,0
4,0
3,0
2,0
1,5
0,6
1,6
2,4
3,4
4,4
5,4
6,4
7,4
8,4
9,4
5,0
4,0
3,0
2,4
1,6
0,6
1,6
2,6
3,5
4,5
5,5
6,4
7,4
8,4
6,0
5,0
4,0
3,3
2,6
1,6
0,6
1,6
2,6
3,6
4,6
5,6
6,6
7,6
7,0
6,0
5,0
4,2
3,6
2,6
1,6
0,6
1,6
2,6
3,6
4,6
5,6
6,6
8,0
7,0
6,0
5,2
4,6
3,6
2,6
1,6
0,6
1,6
2,6
3,6
4,6
5,6
9,0
8,0
7,0
6,0
5,6
4,6
3,6
2,6
1,6
0,6
1,6
2,6
3,6
4,6
10,0
9,0
8,0
7,0
6,6
5,6
4,6
3,6
2,6
1,6
0,6
1,6
2,6
3,6
11,0
10,0
9,0
8,0
7,6
6,6
5,6
4,6
3,6
2,6
1,6
0,6
1,6
2,6
12,0
11,0
10,0
9,0
8,6
7,6
6,6
5,6
4,6
3,6
2,6
1,6
0,6
1,6
13,0
12,0
11,0
10,0
9,6
8,6
7,6
6,6
5,6
4,6
3,6
2,6
1,6
0,6
Tabelle 2.3: Damerau-Levenshtein-Distance-Beispiel
2.3
Soundex
Beim Soundex-Verfahren[EIV2007] werden Elemente anhand ihres Klanges verglichen.
Dabei ist das Ziel, dass gleichklingende Wörter mit der selben Kodierung repräsentiert
werden. Das Verfahren orientiert sich am Klang der Wörter in der englischen Sprache.
Die Kodierung erfolgt nach folgenden Regeln:
1. Der Soundex-Code eines Wortes besteht aus dem ersten Zeichen des Wortes, gefolgt
von drei Ziffern für die gilt 1 ≤ Ziffer ≤ 6.
2. Vokale werden, außer beim Vorkommen als erstes Zeichen, ignoriert.
3. Die Konsonanten H“, W“ und Y“ werden, außer beim Vorkommen als erstes
”
”
”
Zeichen, ignoriert.
4. Entstehen bei der Codierung der Zeichen zweimal dieselbe Ziffer, wird diese nur
einmal in den Code übernommen und die Codeerzeugung fortgesetzt.
5. Die Berechnung wird nach der dritten erzeugten Ziffer abgebrochen.
6. Enthält ein erzeugter Soundex-Code weniger als drei Ziffern, wird dieser mit Nullen
aufgefüllt, bis der Code drei Ziffern enthält.
7. Die Kodierung der Buchstaben erfolgt nach Tabelle 2.4.
Die Berechnung des Ähnlichkeitsmaßes basiert auf der Berechnung der SOUNDEXCodes für die beiden Eingabestrings. Seien i und j die zu vergleichenden Eingabestrings,
11
Ziffer Repräsentierte Buchstaben
1
B, F, P, V
2
C, G, J, K, Q, S, X, Z
3
D, T
4
L
5
M, N
6
R
H, W, Y
A, E, I, O, U
Tabelle 2.4: Kodierung Soundex
dann ist das Ähnlichkeitsmaß definiert als
{
1, wenn SOU N DEX(i) = SOU N DEX(j)
simsoundex =
.
0, wenn SOU N DEX(i) ̸= SOU N DEX(j)
(2.11)
Der Algorithmus zur Berechnung des Ähnlichkeitsmaßes ist nach folgendem Code-Beispiel
in Pseudo-Code aufgebaut.
1 soundex(String A, String B) {
2 codeMap //Hashmap, die die Tabelle der Kodierung des Soundex
abbildet.
3
4 if ((a != null)&&(b != null)) {
5
if (getCode(a).equals(getCode(b))) return 1.0;
6
else return 0.0;
7
}
8
else return 0.0;
9 }
10
11 public String getCode(String string) {
12
String code = string.substring(0, 1).toUpperCase();
13
String lastCode = code;
14
for (int i = 1; i < string.length(); i++) {
15
if (code.length() == 4) {
16
return code;
17
}
18
else {
19
String aktCode = codeMap.get(string.substring(i, i+1));
20
if (!(aktCode.equals(lastCode)))
21
code = code + aktCode;
22
lastCode = aktCode;
23
}
24
}
12
25
26
27
28
29
30
31
32
33
34
35 }
if (code.length() == 1 ) {
code = code + "000";
}
else if (code.length() == 2 ) {
code = code + "00";
}
else if (code.length() == 3 ) {
code = code + "0";
}
return code;
Algorithmus 2.2: Algorithmus zur Bestimmung des Soundex
Zur Bestimmung der Laufzeit des Algorithmus seien A und B zwei Strings, für die gilt
n = |A| und m = |B|. O.b.d.A. sei m ≤ n. Zur Bestimmung des Soundex-Codes muss im
schlechtesten Fall einer der beiden Strings einmal vollständig durchlaufen werden. Somit
ergibt sich eine Laufzeit von
O(n).
(2.12)
Vorteil des Soundex-Verfahren ist, dass das Verfahren auf der Aussprache von Wörtern beruht. Somit werden Hör- und Aussprachefehler korrigiert. Nachteil des SoundexVerfahrens ist, dass der Algorithmus für die englische Sprache bzw. Aussprache entwickelt wurde und somit andere Sprachen nur bedingt unterstützt werden. Deutlich wird
dies durch den Vergleich der Soundex-Codes für die Wörter Hannover“, Hamburg“ und
”
”
Homburg“:
”
• Hannover → H516
• Hamburg → H516
• Homburg → H516
Ein weiterer Nachteil ist, dass vor allem bei längeren Wörtern der hintere Teil komplett
ignoriert und nicht betrachtet wird. Hinzu kommt, dass Informationen durch das Verfahren verloren gehen, da alle Vokale, wenn sie nicht als erstes Zeichen vorkommen, nicht
betrachtet werden. Das folgende Beispiel zeigt die Bestimmung des Ähnlichkeitsmaßes
für die Strings Ostlandstraße“ und Otslandstraße“.
”
”
A = Ostlandstraße
B = Otslandstraße
SOU N DEX(A) = O234
SOU N DEX(B) = O324
simsoundex (A, B) = 0.0
13
2.4
Kölner Phonetik
Die Kölner Phonetik ist eine Weiterentwicklung des Soundex-Algorithmus, um den Algorithmus besser für die deutsche Sprache nutzen zu können. Entwickelte wurde das
Modell der Kölner Phonetik von Hans Joachim Postel. Bei diesem Algorithmus wird
jedem Zeichen eines Wortes eine Ziffer von 0 bis 8 zugeordnet. Bei der Bestimmung der
entsprechenden Ziffer wird zusätzlich der folgende und der vorherige Buchstabe betrachtet. Im Gegensatz zum Soundex-Verfahren ist die Länge eines Codes nicht begrenzt;
somit wird ein weiterer Nachteil des Soundex-Verfahrens ausgeglichen. Die Kodierung
der Buchstaben erfolgt nach Tabelle 2.5. Das Ähnlichkeitsmaß ist analog zum SoundexBuchstaben
A, E, I, J, O, U, Y
H
B
P
D, T
F, V, W
P
G, K, Q
C
C
X
L
M, N
R
S, Z
C
C
C
D, T
X
Kontext
nicht vor H
nicht vor C, S, Z
vor H
im Anlaut vor A, H, K, L, O, Q, R, U, X
vor A, H, K, O, Q, U, X außer nach S, Z
nicht nach C, K, Q
nach S, Z
im Anlaut außer vor A, H, K, L, O, Q, R, U, X
nicht vor A, H, K, O, Q, U, X
vor C, S, Z
nach C, K, Q
Code
0
1
1
2
3
3
4
4
4
48
5
6
7
8
8
8
8
8
8
Tabelle 2.5: Kodierung Kölner Phonetik
Verfahren definiert als
{
1, wenn SOU N DEX KOELN (i) = SOU N DEX KOELN (j)
.
0, wenn SOU N DEX KOELN (i) ̸= SOU N DEX KOELN (j)
(2.13)
Der Algorithmus ist, bis auf die Längenbeschränkung der erzeugten Codes, analog zum
Algorithmus des Soundex-Verfahren. Somit beträgt die Laufzeit mit den Bedingungen
simsoundex koeln =
14
analog zum Soundex-Verfahren
O(n)
(2.14)
Am folgenden Beispiel lässt sich erkennen, dass einige Nachteile des Soundex-Verfahrens
ausgeglichen worden sind. Vergleich der Codes für die Wörter Hannover“, Hamburg“
”
”
und Homburg“ mit der Kölner Phonetik:
”
• Hannover → 060307
• Hamburg → 061074
• Homburg → 061074
Der Nachteil, dass das Verfahren nicht unabhängig von der Sprache ist, bleibt allerdings
auch bei diesem Verfahren erhalten.
Bestimmung der Ähnlichkeit für die Strings Ostlandstraße“ und Otslandstraße“.
”
”
A = Ostlandstraße
B = Otslandstraße
SOU N DEX(A) = 0825068270
SOU N DEX(B) = 085068270
simsoundex (A, B) = 0.0
2.5
Jaro-Distance
Die Jaro-Distance[EIV2007] diente im ursprünglichen Sinn zum Vergleichen von Namen.
Die Bestimmung des Ähnlichkeitsmaßes erfolgt nach folgendem Ansatz: seien A und B
zwei Strings, bestimmt man die gemeinsamen Zeichen c mit
A[i] = B[j] und |i − j| ≤
1
min(|A|, |B|)
2
(2.15)
Zusätzlich bestimmt man die Anzahl t der Transpositionen . Hierzu vergleicht man die
Zeichen beider Strings an der i-ten Stelle. Unterscheiden sich die beiden Zeichen, wird
die Transposition um 1 erhöht. Daraus ergibt sich folgendes Ähnlichkeitsmaß:
(
)
c − 2t
c
c
1
+
+
(2.16)
simjaro (A, B) :=
3 |A| |B|
c
Der folgende Codeausschnitt in Pseudo-Code zeigt eine Implementierungsidee des Algorithmus zur Bestimmung eines Ähnlichkeitsmaßes mit Hilfe der Jaro-Distance.
15
1 jarodistance(String A, String B) {
2
for (i = 0 ; i <= A.length() ; i++ ) {
3
for (j = 0 ; j <= B.length() ; j++) {
4
if (A[i].equals(B[j])&&Math.abs(i - j) <= 0.5 * Math.min(A.
length(), B.length())) {
5
c = c + 1;
6
}
7
if (i == j) {
8
if (A[i].equals(B[j])) {
9
t = t + 1;
10
}
11
}
12
}
13
}
14
return (1/3)*((c/A.length())+(c/B.length())+((c-(t/2))/c));
15 }
Algorithmus 2.3: Algorithmus zur Bestimmung der Jaro-Distance
Seien A und B zwei Strings, für die gilt n = |A|, m = |B| sowie o.B.d.A. n <= m, dann
folgt aus dem Algorithmus eine Laufzeit von
O(n ∗ m)
(2.17)
für die Bestimmung der gemeinsamen Zeichen c und der Transpositionen.
Vorteil des Jaro-Distance-Verfahren ist, dass sowohl die Reihenfolge der verwendeten
Zeichen als auch der verwendete Zeichenvorrat eine Rolle spielt. Da das Verfahren nur
die einzelnen Zeichen betrachtet, ist das Verfahren unabhängig von der verwendeten
Sprache. Das folgende Beispiel zeigt die Anwendung der Jaro-Distance zur Bestimmung
der Ähnlichkeit für die Strings Ostlandstraße“ und Otslandstraße“. Sei C die Menge
”
”
der gemeinsamen Zeichen und sei T die Menge der Stellen, an denen sich die Strings
unterscheiden.
A = Ostlandstraße
B = Otslandstraße
C = {O, s, t, l, a, n, d, s, t, r, a, ß, e}
c = 13
T = {2, 3}
t=2
simjaro (A, B) = 0.9744
16
2.6
Field Similarity
Beim Verfahren der Field Similarity[ZLBL2004] wird die Ähnlichkeit zweier Strings auf
folgende Art und Weise bestimmt. Zuerst wird der Eingabestring in einzelne Zeichen
zerlegt. Die einzelnen Zeichen werden anschließend mit der Häufigkeit, mit der das entsprechende Zeichen im String vorkommt, gekennzeichnet. Dies wird durch das folgende
Beispiel zur Bestimmung der Ähnlichkeit für die Strings Ostlandstraße“ und Otsland”
”
straße“ verdeutlicht.
A = Ostlandstraße
B = Otslandstraße
TA = {O1, s1, t1, l1, a1, n1, d1, s2, t2, r1, a2, ß1, e1}
TB = {O1, t1, s1, l1, a1, n1, d1, s2, t2, r1, a2, ß1, e1}
Um das Ähnlichkeitsmaß zu bestimmen, bestimmt man zunächst den Schnitt der Mengen, die aus den einzelnen Zeichen bestehen. Hierfür seien A und B zwei Strings und
seien TA und TB die Mengen der einzelnen Zeichen der beiden Strings. Daraus folgt:
(
)
|TA ∩ TB | |TA ∩ TB |
simF ieldSimilarity (A, B) := min
,
(2.18)
|TA |
|TB |
Für das o. g. Beispiel ergibt sich:
TA ∩ TB = {O1, s1, t1, l1, a1, n1, d1, s2, t2, r1, a2, ß1, e1}
simF ieldSimilarity (A, B) = 1.0
Der Algorithmus zur Bestimmung des Ähnlichkeitsmaß für zwei Strings ist in folgendem
Code-Ausschnitt dargestellt.
1 fieldsimilaritydistance(String A, String B) {
2 public static int subStringLengthConst = 1;
3
4 public static HashMap<String, Integer> map = new HashMap<String,
Integer>();
5
6 public static double similarity(String a, String b) {
7
8
HashSet<String> tokenA = getToken(a);
9
HashSet<String> tokenB = getToken(b);
10
tokenA.retainAll(tokenB);
11
double n1 = tokenA.size();
12
if ((a != null)&&(b != null)) {
13
return (double) Math.min(n1 / a.length(), n1 / b.length());
14
} else {
17
15
return 0.0;
16
}
17 }
18 public static HashSet<String> getToken(String eingabe) {
19
HashSet<String> token = new HashSet<String>();
20
HashMap<String, Integer> count = new HashMap<String, Integer>();
21
for (int i = 0; i < eingabe.length() - subStringLengthConst + 1;
i = i + subStringLengthConst) {
22
if (token.add(eingabe.substring(i, i + subStringLengthConst)+"1
")){
23
count.put(eingabe.substring(i, i + subStringLengthConst), 1)
;
24
System.out.println(eingabe.substring(i, i +
subStringLengthConst)+"1");
25
}
26
else {
27
int aktCount = count.get(eingabe.substring(i, i +
subStringLengthConst)) + 1;
28
count.remove(eingabe.substring(i, i + subStringLengthConst))
;
29
token.add(eingabe.substring(i, i + subStringLengthConst) +
aktCount);
30
count.put(eingabe.substring(i, i + subStringLengthConst),
aktCount);
31
System.out.println(eingabe.substring(i, i +
subStringLengthConst)+ aktCount);
32
}
33
}
34
return token;
35 }
36 }
Algorithmus 2.4: Algorithmus zur Bestimmung der Field-Similarity-Distance
Zur Bestimmung der Laufzeit sei |A| = n und |B| = m. Damit dauert die Erzeugung
der Token
O(n) bzw. O(m).
(2.19)
Die beiden verschachtelten FOR-Schleifen zur Berechnung des Schnittes der Tokenmengen führen zu einer Laufzeit von
O(n ∗ m).
(2.20)
Somit ergibt sich eine Gesamtlaufzeit von
O(n + m + n ∗ m).
18
(2.21)
Vorteil des Verfahrens ist, das es unabhängig von der verwendeten Sprache ist. Ein weiterer Vorteil ist, dass das Verfahren unabhängig von der Eingabereihenfolge der Zeichen
ist. Dadurch werden z.B. Buchstabendreher, wie im o.g. Beispiel, erkannt. Hierdurch
entsteht aber ein Nachteil des Verfahrens, wenn nämlich zwei Strings aus demselben
Zeichenvorrat, wie z. B. rosenbusch“ und buschrosen“, bestehen.
”
”
2.7
Q-Grams
Beim Q-Grams-Verfahren wird der Eingabe-String in Teilstrings der Länge q zerlegt.
Anfangs- und Endzeichen werden durch ein Zeichen, das außerhalb des verwendeten
Alphabets liegt, besonders gekennzeichnet. Häufig verwendet werden die Zeichen $“
”
und #“. Die Markierung der Anfangs- und Endzeichen sollen an einem kurzen Bei”
spiel für 2-Grams deutlich gemacht werden. Sei A ein String der Länge n und A =
Programmiersprache. Beim Q-Gram-Verfahren wird der Eingabestring am Anfang und
am Ende um das Zeichen zur Kennzeichnung des Anfangs- bzw. des Endzeichens erweitert. Daraus ergibt sich A′ = $Programmiersprache$. Über diesen String werden nun die
Teilstrings der Länge q gebildet und mit der Anzahl, wie oft ein Teilstring in der Menge
der Teilstrings vorkommt, gekennzeichnet. Sei TA die Menge der Teilstrings, die aus A′
gebildet werden.
TA = {$P 1, P r1, ro1, og1, gr1, ra1, am1, mm1, mi1, ie1, er1, rs1, sp1, pr1,
ra2, ac1, ch1, he1, e$1}
Das Ähnlichkeitsmaß wird auf folgende Art und Weise berechnet. Seien A und B zwei
Strings und TA und TB die Mengen der Teilstrings von A bzw. B. Das Ähnlichkeitsmaß
wird dann mit Hilfe des Jaccard-Koeffizienten1 berechnet. Daraus ergibt sich:
simQ−Grams (A, B) :=
|TA ∩ TB |
|TA ∪ TB |
(2.22)
Der Algorithmus zur Bestimmung des Ähnlichkeitsmaß für zwei Strings ist analog zum
Algorithmus des Field-Similarity-Verfahrens.
Da der Algortihmus analog zum Field-Similarity-Verfahren aufgebaut ist, ergibt sich
ebenfalls eine Laufzeit von
O(a + a ∗ b).
(2.23)
Vorteil des Verfahrens ist, dass Strings der Art Hans Peter“ und Peter Hans“ als ähn”
”
lich angesehen werden. Trotzdem wird die Reihenfolge der Zeichen im Eingabestring
berücksichtigt, allerdings nur im Kontext der umliegenden Zeichen. Ein weiterer Vorteil
1
Der Jaccard-Koeffizient bestimmt die Ähnlichkeit von zwei Mengen. Er geht auf den Schweizer
Botaniker Paul Jaccard zurück.
19
ist, dass das Verfahren unabhängig von einer Sprache ist, da nur die Zeichen und nicht
Aussprache und Klang betrachtet werden.
Die folgenden Beispiele stellen die Funktionsweise des Q-Grams-Verfahren dar:
2-Grams
”
”
A = Ostlandstraße
B = Otslandstraße
TA = {$O1, Os1, st1, tl1, la1, an1, nd1, ds1, st2, tr1, ra1, aß1, ße1, e$1}
TB = {$O1, Ot1, ts1, sl1, la1, an1, nd1, ds1, st1, tr1, ra1, aß1, ße1, e$1}
TA ∩ TB = {$O1, la1, an1, nd1, ds1, st1, tr1, ra1, aß1, ße1, e$1}
TA ∪ TB = {$O1, Ot1, ts1, sl1, Os1, st1, tl1, la1, an1, nd1, ds1, st2, tr1, ra1, aß1, ße1, e$1}
simQ−Grams (A, B) = 0.6875
3-Grams
”
”
A = Ostlandstraße
B = Otslandstraße
TA = {$Os1, Ost1, stl1, tla1, lan1, and1, nds1, dst1, str1, tra1, raß1, aße1, ße$1}
TB = {$Ot1, Ots1, tsl1, sla1, lan1, and1, nds1, dst1, str1, tra1, raß1, aße1, ße$1}
TA ∩ TB = {lan1, and1, nds1, dst1, str1, tra1, raß1, aße1, ße$1}
TA ∪ TB = {$Os1, Ost1, stl1, tla1, lan1, and1, nds1, dst1, str1, tra1, raß1, aße1, ße$1,
$Ot1, Ots1, tsl1, sla1}
2.8
N-Gramme
Die N-Gramme-Verfahren[LN2007] ähneln sich in seiner Struktur dem Q-Grams-Verfahren.
Auch beim N-Gramme-Verfahren werden Anfangs- und Endzeichen besonders gekennzeichent. Im Gegensatz zum Q-Grams-Verfahren werden beim N-Gramme-Verfahren sogenannte Rand-N-Gramme[LN2007] gebildet. Die Rand-N-Gramme sind die Teilstrings
des Eingabestrings, die das Zeichen zum Kennzeichnen von Anfangs- und Endzeichen
enthalten. Dazu wird der Eingabestring am Anfang und am Ende um (n − 1)-mal $“2
”
2
Sei $ das verwendete Zeichen, um Anfangs- und Endzeichen zu kennzeichnen.
20
erweitert. Somit ergibt sich aus dem Eingabestring A zu A′′ = $$Ostlandstraße$$. Anschließend werden die Teilstrings der Länge n gebildet. So ergibt sich:
TA = {$$O, $Os, Ost, stl, tla, lan, and, nds, dst, str, tra, raß, aße, ße$, e$$}
Das Ähnlichkeitsmaß wird auf die folgende Art und Weise berechnet: seien A und B zwei
Strings und TA und TB die Mengen der Teilstrings von A bzw. B. Das Ähnlichkeitsmaß
wird dann mit Hilfe des Jaccard-Koeffizienten3 berechnet. Daraus ergibt sich:
simN −Gramme (A, B) :=
|TA ∩ TB |
|TA ∪ TB |
(2.24)
Der Algorithmus zur Bestimmung des Ähnlichkeitsmaß für zwei Strings ist analog zum
Algorithmus des Field-Similarity-Verfahrens.
Da der Algortihmus analog zum Field-Similarity-Verfahren aufgebaut ist, ergibt sich
ebenfalls eine Laufzeit von
O(a + a ∗ b).
(2.25)
Vorteil beider Verfahren ist, dass Strings der Art Hans Peter“ und Peter Hans“ als
”
”
ähnlich angesehen werden. Trotzdem wird die Reihenfolge der Zeichen im Eingabestring
berücksichtigt, allerdings nur im Kontext der umliegenden Zeichen. Ein weiterer Vorteil
ist, dass das Verfahren unabhängig von einer Sprache ist, da nur die Zeichen und nicht
Aussprache und Klang betrachtet werden.
Die folgenden Beispiele stellen die Funktionsweise des N-Gramme-Verfahren dar.
2-Gramme(N-Gramme)
”
”
A = Ostlandstraße
B = Otslandstraße
TA = {$O, Os, st, tl, la, an, nd, ds, st, tr, ra, aß, ße, e$}
TB = {$O, Ot, ts, sl, la, an, nd, ds, st, tr, ra, aß, ße, e$}
TA ∩ TB = {$O, la, an, nd, ds, st, tr, ra, aß, ße, e$}
TA ∪ TB = {$O, Os, st, tl, la, an, nd, ds, st, tr, ra, aß, ße, e$,
Ot, ts, sl}
3
Der Jaccard-Koeffizient bestimmt die Ähnlichkeit von zwei Mengen. Er geht auf den Schweizer
Botaniker Paul Jaccard zurück.
21
3-Gramme(N-Gramme)
”
”
A = Ostlandstraße
B = Otslandstraße
TA = {$$O, $Os, Ost, stl, tla, lan, and, nds, dst, str, tra, raß, aße, ße$, e$$}
TB = {$$O, $Ot, Ots, tsl, sla, lan, and, nds, dst, str, tra, raß, aße, ße$, e$$}
TA ∩ TB = {$$O, lan, and, nds, dst, str, tra, raß, aße, ße$, e$$}
TA ∪ TB = {$$O, $Os, Ost, stl, tla, lan, and, nds, dst, str, tra, raß, aße, ße$, e$$,
$Ot, Ots, tsl, sla}
2.9
Fazit
Im zurückliegenden Kapitel wurden acht Ähnlichkeitsmaße vorgestellt und analysiert.
Die Verfahren Soundex und Kölner Phonetik eignen sich nur bedingt nur Berechnung
von Matchings, da bei diesen Verfahren als Ähnlichkeitswerte nur 1.0 und 0.0 zurückgegeben werden. Dies geschieht auch nur, wenn der erzeugte Code für beide Eingabestrings identisch ist. Aufgrund der vorgestellten Eigenschaften ist das Soundex-Verfahren
großzügiger, was die Auswahl an ähnlichen Strings angeht. Die weiteren, vorgestellten
Verfahren eignen sich, um Matchings zu bestimmen. Aufgrund der vorgestellten Eigenschaften der Verfahren ist es von Vorteil, wenn mehrere Verfahren zum Einsatz kommen,
da so die Nachteile eines Verfahrens durch ein anderes Verfahren ausgeglichen werden
können. An dieser Stelle gilt es, geeignete Kombinationsverfahren für Ähnlichkeitsmaße
zu betrachten und zu analysieren.
22
Kapitel 3
Kombination von Algorithmen für
die Duplikaterkennung
Dieses Kapitel stellt Ideen zur Kombination von Algorithmen vor. Dies ist notwendig, da
alle Algorithmen Vor- und Nachteile aufweisen und diese durch eine geschickte Kombination der verschiedenen Algorithmen ausgeglichen werden können. Im folgenden werden
drei Ansätze vorgestellt. Die drei Ansätze unterscheiden sich grundsätzlich in der Kombination der verschiedenen Algorithmen. Deshalb ist zuerst eine grundsätzliche Entscheidung zu treffen, in welcher Art und Weise die Algorithmen kombiniert werden. Das Ziel
der Ansätze ist für alle dasselbe: es sollen möglichst alle Paare von Matchings gefunden
werden, die in der realen Welt dasselbe Objekt beschreiben.
3.1
Hintereinander-Ausführung von Algorithmen
Abbildung 3.1 zeigt eine Kombination von Algorithmen, bei der zuerst ein Algorithmus auf der Grundmenge ausgeführt wird. Die daraus resultierenden Ergebnisse werden dann mit mindestens einem weiteren Algorithmus verifiziert. Der erste Algorithmus
dient hierbei zur Grobsortierung. Daher ist ein Algorithmus zu wählen, bei dem mögliche
Kandidaten erhalten bleiben und Elemente, die für eine Auswahl auf jeden Fall nicht
in Betracht kommen, eliminiert werden. Der zweite bzw. alle weiteren Algorithmen dienen zur Verfeinerung der Ergebnisse und kontrollieren gleichzeitig die Ergebnisse des
vorherigen Algorithmus. Die Implementation dieses Ansatzes ist relativ einfach, da die
Struktur der Eingabe und Ausgabe für alle Algorithmen identisch ist. Zu beachten ist
hier, dass für jeden Algorithmus ein geeigneter Schwellenwert für das zu bestimmende
Ähnlichkeitsmaß gewählt werden muss. Die Algorithmen können in beliebiger Reihenfolge kombiniert werden und die Kombination hängt nur vor den Eigenschaften des von
den Algorithmen berechnetem Ähnlichkeitsmaß ab. Nachteil dieses Ansatz ist, dass Ele-
23
mente, die von einem Algorithmus entfernt werden, nicht für eine weitere Analyse in
Betracht kommen. Dies wird dann zum Nachteil, wenn sog. false-negatives“ von einem
”
Algorithmus erkannt werden.Aus dem Aspekt, dass ein vorheriger Algorithmus bereits
Daten entfernt hat, folgt ebenfalls, dass nicht das komplette Wissen aller Algorithmen
genutzt werden kann.
Start
Tabelle 1
Ähnlichkeitsmaß 1
Tabelle 2
Maß > x1
Ähnlichkeitsmaß 2
Maß > x2
Mögliche Synonyme
Abbildung 3.1: Kombination von Ähnlichkeitsmaßen - nacheinander
3.2
Parallele-Ausführung von Algorithmen
Abbildung 3.2 zeigt eine Kombination von Algorithmen, bei der die Algorithmen parallel ausgeführt werden. Ausgehend von derselben Datenquelle, berechnet zunächst jeder
24
Algorithmus seine“ Ergebnisse. Dabei wird das Wissen aller verwendeten Algorithmen
”
genutzt. Nach der Berechnung der Ergebnisse der einzelnen Algorithmen werden diese
Ergebnisse ausgewertet und die entsprechenden Datensätze ausgewählt. Hierfür gilt es,
für jeden Algorithmus ein geeigenten Schwellenwert für das jeweilige Ähnlichkeitsmaß
zu bestimmen. Durch die parallele Berechnung der einzelnen Algorithmen können alle
Algorithmen verwendet werden bzw. kombiniert werden. Daraus folgt, dass die Nachteile
und die Fehler der einzelnen Algorithmen durch die anderen Algorithmen ausgeglichen
werden und zusätzlich ein breit gefächertes Maß zur Anwendung kommt. Im Gegensatz
zum Ansatz aus Kap. 3.1 steht das Ergebnis nicht nach den Berechnung der einzelnen
Algorithmen fest, sondern die berechneten Ergebnisse der einzelnen Algorithmen müssen
zu einen Gesamtergebnis zusammengeführt werden. Hierfür gilt es eine geeignete Heuristik zu entwickeln, die in Abhängigkeit der verwendeten Algorithmen und berechneten
Ergebnissen das Gesamtergebnis berechnet.
Start
Tabelle 1
Tabelle 2
Ähnlichkeitsmaß 1
Ähnlichkeitsmaß 2
Maß > x1
Maß > x2
Mögliche Synonyme
Abbildung 3.2: Kombination von Ähnlichkeitsmaßen - parallel
3.3
Kombination über die Länge von Vektoren
Bei diesem Verfahren wird die Kombination der Ähnlichkeitsmaße über die Länge eines
Vektors bestimmt. Bei der Verwendung von n Ähnlichkeitsmaßen erfolgt die Betrach-
25
tung im n-dimensionalen Raum. Somit steht jede Dimension für ein Ähnlichkeitsmaß.
Für ein Stringpaar wird zunächst unabhängig voneinander der Ähnlichkeitswert für jedes
der verwendeten Ähnlichkeitsmaße berechnet. Diese Ähnlichkeitswerte repräsentieren die
einzelnen Komponenten des Vektors. Abbildung 3.3 zeigt die generelle Vorgehensweise
des Verfahrens. Die Länge des Vektor wird folgendermaßen bestimmt: sei xi der Ähn-
Ähnlichkeitsmaß 2
1
Ähnlichkeitsmaß 1
1
Abbildung 3.3: Kombination über die Länge von Vektoren
lichkeitswert für ein Stringpaar A und B, der mit dem i-ten Ähnlichkeitsmaß berechnet
wurde und n die Anzahl der verwendeten Ähnlichkeitsmaße. Die Länge der Vektoren wird
auf die Länge des Einheitsvektors der entsprechenden Dimension normiert. Abbildung
3.4 stellt beispielhaft die Anwendung von zwei Ähnlichkeitsmaßen dar.
√∑n
x2
√i=1 i
simV ektor (A, B) :=
(3.1)
n
3.4
Fazit
Abschließend ist als Erstes auszuführen, dass alle drei Ansätze Ergebnisse liefern und
diese auch verwendet werden können. Allerdings unterscheidet sich die Struktur der Ergebnisse bei der Verwendung derselben Ähnlichkeitsmaße und Grenzwerte doch stark.
26
Start
Tabelle 1
Ähnlichkeitsmaß 1
Tabelle 2
Ähnlichkeitsmaß 2
Berechnung
Vektorlänge
Maß > x
Mögliche Synonyme
Abbildung 3.4: Kombination über die Länge von Vektoren
Beim Ansatz im Kapitel 3.1 sind die Ergebnisse sehr stark von der Reihenfolge, in der
die Ähnlichkeitsmaße kombiniert werden, geprägt. Das im Kapitel 3.2 beschriebene Verfahren führt in der Regel zu zuvielen Ergebnisse, es sei denn, bei den nicht so restritiven
Ähnlichkeitsmaßen wird ein geeigneter Grenzwert festgelegt. Die im letzten Abschnitt
vorgestellte Technik ist die über alle Algortihmen gesehen fairste“ Variante, da alle
”
verwendeten Maße gleichermaße in das Maß eingehen.
27
Kapitel 4
Sorted Neighborhood
Methode(SNM)
Nachdem die Algorithmen zum Berechnen eines Ähnlichkeitsmaßes und zur Kombination dieser Algorithmen vorgestellt wurden, wird in diesem Kapitel ein Verfahren zur
schnelleren Berechnung von Matchings über eine Datenquelle beschrieben. Der einfachste Ansatz wäre die Brute-Force-Strategie. Allerdings ist diese Strategie sehr langsam,
da jedes Element mit jedem Element verglichen wird. Daraus definiert sich das Verfahren
der Sorted Neighborhood Methode.
Das Verfahren der Sorted Neighborhood Methode[LN2007] ist ein Ansatz, um die Berechnung von ähnlichen Datensätzen bei einem bestimmten Schwellenwert zu beschleunigen.
Dies bedeutet, dass auf geeignete Art und Weise die Anzahl der Vergleiche, die durchgeführt werden, reduziert wird. Hierzu gilt es eine Vorauswahl zu treffen, mit der die
Tupel bestimmt werden, die noch verglichen werden. Ausgangspunkt für diese Reduzierung ist die Brute-Force-Strategie, also der Vergleich jedes Tupels mit jedem Tupel. Wie
der Name des Verfahrens schon aussagt, betrachtet man die Tupel, die in der Nachbarschaft liegen und nutzt diese dann als Quelle für die Vergleiche. Hierzu gliedert sich das
Verfahren in drei Phasen:
1. Schlüsselbildung
2. Sortierung
3. Vergleiche
Im Folgenden werden die Phasen einzeln vorgestellt. In der Phase der Schlüsselbildung gilt es, zunächst einen geeigneten Schlüssel zu wählen. Dieser Schlüssel ist als
Sequenz der relevanten Attribute definiert und verweist auf den ursprünglichen Datensatz. Die Wahl des Schlüssels sollte durch einen Experten erfolgen. In der zweiten Phase,
29
der Sortierung, werden die Schlüssel alphabetisch sortiert, so dass ähnliche Datensätze
nahe beieinander liegen. Hierfür ist eine geeignete Schlüsselwahl von entscheidender Bedeutung. Der Schlüssel ist so zu wählen, dass nach der Sortierung ähnliche Datensätze
möglichst nahe zusammenliegen und nicht ähnliche Datensatz möglichst weitauseinander
liegen. Dabei ist zu beachten, dass, wenn Elemente aus dem Schlüssel der Tabelle für den
Schlüssel der Sorted-Neighborhood-Methode gewählt werden, die Sortierung sehr stark
von diesem Element geprägt ist. Ebenso ist zu beachten, dass die Anzahl der Elemente,
die von einem Schlüssel repräsentiert werden, maximal gleich der in der dritten Phase
gewählten Fenstergröße ist. In der letzten Phase Vergleiche werden die geeigneten Datensätze ausgewählt. Dazu wird ein Fenster der Größe m mit (2 ≤ m ≤ n) über die
Datensätze(Anzahl Datensätze = n) geschoben. Alle Datensätze, die sich innerhalb des
Fensters befinden, werden paarweise verglichen. Die Grafik 4.1 verdeutlicht das Vorgehen. Der rote Bereich stellt das Fenster in der Ausgangssituation dar. Der blaue und der
grüne Bereich zeigen das Fenster im zweiten bzw. dritten Schritt des Algorithmus. Hierzu
0
…
…
…
1
…
…
…
2
…
…
…
3
…
…
…
4
…
…
…
5
…
…
…
6
…
…
…
7
…
…
…
8
…
…
…
9
…
…
…
10
…
…
…
11
…
…
…
12
…
…
…
13
…
…
…
14
…
…
…
Abbildung 4.1: Sorted Neighborhood Methode - Verschieben des Fensters
wird ein geeignetes Ähnlichkeitsmaß gewählt, mit dem die entsprechenden Datensätze
30
verglichen werden. Anschließend wird das Fenster um einen Datensatz weiter geschoben.
Dies wird solange wiederholt bis die obere Grenze des Fensters den letzten Datensatz
erreicht. Der Ablauf des Ansatzes der dritten Phase des Sorted-Neighborhood-Methode
lässt sich durch folgenden Codeausschnitt in Pseudo-Code darstellen.
1 vergleiche() {
2
double grenzwert = 0.9;
3
List ergebnis;
4
List tupel \\ Datenbanktabelle
5
for (i = 0 ; i < fensterbreite ; i++) {
6
for (j = i + 1 ; j < fensterbreite ; j++) {
7
if (similarity(tupel.get(i),tupel.get(j)) >= grenzwert) {
8
ergebnis.add(tupel.get(i), tupel.get(j), similarity(tupel
.get(i),tupel.get(j)));
9
}
10
}
11
}
12
for (i = fensterbreite ; i < AnzahlDatensätze ; i++) {
13
for (j = i - fensterbreite ; j < i ; j++) {
14
if (similarity(tupel.get(i),tupel.get(j)) >= grenzwert) {
15
ergebnis.add(tupel.get(i), tupel.get(j), similarity(tupel
.get(i),tupel.get(j)));
16
}
17
}
18
}
19 }
Algorithmus 4.1: Algorithmus der Sorted-Neighborhood-Methode
Die Laufzeit des Algorithmus setzt sich aus der Laufzeit der drei Phasen zusammen. In
der ersten Phase werden alle Datensätze einmal durchlaufen und in jedem Schritt der
entsprechende Schlüssel berechnet. Somit ergibt sich für die erste Phase eine Laufzeit
von
O(n).
(4.1)
Die alphabetische Sortierung lässt sich mit Algorithmen, wie z. B. Quicksort, in einer
Laufzeit von
O(n log n)
(4.2)
realisieren. In der letzten Phase Vergleiche“ müssen zunächst die ersten m Datensätze
”
paarweise verglichen werden. Anschließend wird das Fenster jeweils einen Datensatz
weiter geschoben. Somit fällt genau ein Datensatz aus dem Fenster heraus und es wird
ein Datensatz neu aufgenommen. Dieser neue Datensatz muss mit den verbliebenen m−1
Datensätzen verglichen werden. Daraus folgt eine Laufzeit von:
O(m2 + (n − m) ∗ m) = O(m ∗ n).
31
(4.3)
Die Laufzeit des gesamten Algorithmus beträgt
O(n + n ∗ log n + m ∗ n).
(4.4)
Vorteil der Sorted-Neighborhood-Methode ist, dass die Vergleiche der Datensätze in
linearer Zeit zu berechnen sind. Nachteil der Sorted-Neighborhood-Methode ist, dass
die Qualität der Ergebnisse stark von der Wahl des Schlüssels abhängig ist. Erhalten
z. B. zwei eigentlich ähnliche Datensätze einen Schlüssel, bei dem sie nach der Sortierung weit auseinanderliegen, werden sie für einen möglichen Vergleich gar nicht erst
in Betracht gezogen. Weitere Vor- und Nachteile ergeben sich aus dem verwendeten
Ähnlichkeitsmaß zur Berechnung der Vergleiche.
32
Kapitel 5
Experimente
Im diesem Kapitel werden die Algorithmen und möglichen Kombinationen der Algorithmen anhand der verschiedenen Datenquellen getestet und bewertet. Anschließend soll
dadurch eine Auswahl der möglichen Strategie für die spätere Implementierung getroffen
werden. Im ersten Teil des Kapitels werden Bewertungskriterien für die verschiedenen
Experimente vorgestellt und erläutert. Danach folgen die Experimente, ihre Ergebnisse
und eine Bewertung der Ergebnisse.
5.1
Bewertungskriterien der Algorithmen
Im nachfolgenden Teil werden verschiedene Ansätze für eine mögliche, spätere Implementierung getestet. Um die Ansätze bewerten zu können, werden zwei Kriterien[LN2007]
eingeführt, die maßgebend für die Qualität der Ergebnisse seien sollen. Es handelt sich
hierbei um die Effektivität und um die Effizienz. Beide Kriterien werden im folgenden
dargestellt.
Für die Betrachtung der Effektivität werden zwei Maße eingeführt. Es handelt sich
hierbei um Precision“ und um Recall“. Abschließend wird noch eine Kombinations”
”
möglichkeit der beiden Maße vorgestellt.
Die Algorithmen liefern als Ergebnisse Paare von möglichen Matchings, die aufgrund
ihrer Ähnlichkeit zueinander erkannt worden sind. Jedes Paar lässt sich in eine der
folgenden vier Kategorien einteilen.
1. True-Positives: Paare, die korrekt als Matching erkannt werden.
2. True-Negatives: Paare, die korrekt als Nicht-Matching erkannt werden.
33
3. False-Positives: Paare, die fälschlicherweise als Matching erkannt werden.
4. False-Negatives: Paare, die fälschlicherweise als Nicht-Matching erkannt werden.
Der Zusammenhang der verschiedenen Kategorien wird durch die Abbildung 5.1 verdeutlicht. Das erste Maß Precision“ misst den Anteil der vom Algorithmus als Matching
”
Algorithmus
Matching
kein Matching
Realität
Matching
kein Matching
true-positive
false-positive
false-negative
true-negativ
Tabelle 5.1: Klassen von Paare
erkannten Paare. Daraus folgt, dass, je höher der Precision-Wert ist, desto mehr können
die vom Algorithmus als Matching erkannte Paare auch als solche angenommen werden.
Das Maß ist nach folgender Formel definiert.
precision =
|true-positives|
|true-positives| + |f alse-positives|
(5.1)
Das zweite Maß Recall“ misst, wie viele Matchings vom Algorithmus erkannt werden, die
”
auch in der realen Welt als Matchings definiert sind. Aus der Definition der Formel folgt,
dass je höher der Recall-Wert ist, desto mehr tatsächliche Matchings werden erkannt und
desto mehr Nicht-Matchings werden erkannt.
recall =
|true-positives|
|true-positives| + |f alse-negatives|
(5.2)
Ziel ist es, für beide Maße einen möglichst hohen Wert zu erzielen. Dabei ist allerdings
zu beachten, dass für beide Maße gilt, dass eine Verbesserung des einen Maßes immer
auf Kosten einer Verschlechterung des anderen Maßen erfolgt. Daraus folgt, dass um die
Güte des verwendeten Algorithmus zu bestimmen, in der Regel eine Kombination der
beiden Maße verwendet wird. Es handelt sich hierbei um das harmonische Mittel des
Precision- und des Recall-Wertes. Sie ist auf folgende Art und Weise definiert:
f -measure =
2 ∗ recall ∗ precision
recall + precision
(5.3)
Die Effizienz der Algorithmen wird in Abhängigkeit der Laufzeit der Algorithmen sowie in Abhängigkeit der daraus resultierenden Tupel betrachtet. Bei den verwendeten
Algorithmen ist vor allem die Anzahl der verwendeten Vergleiche maßgebend. Die Effizienz wird zunächst als erstes Kriterium genommen, da eine viel zu lange Laufzeit für die
Implementation nicht zur Anwendung kommen darf. Für Algorithmen, die mit einer hinreichenden Verringerung der Laufzeit arbeiten, wird anschließend auch die Effektivität
betrachtet.
34
5.2
Experimente: Analyse der Brute Force Strategie
In diesem Abschnitt des Kapitels werden Algorithmen, bzw. Ansätze zur Verwendung
dieser Algorithmen bzgl. ihrer Effizienz und ihrer Effektivität getestet und analysiert. Als
Erstes soll versucht werden, das Ergebnis mit Hilfe eines Brute-Force-Ansatzes zu berechnen. Hierzu ist erforderlich, dass jedes Tupel mit jedem Tupel anhand eines Ähnlichkeitsmaßes verglichen wird und anschließend die gefundenen Paare anhand eines Grenzwertes
ausgewählt werden. Als Datenquelle dient die Tabelle PI.Schlagwort“. Die Datenquelle
”
ist nach folgendem relationalem Modell aufgebaut:
(
SCHRIF T schrif t, autornull , titel, schrif ttyp, schrif ttyp erg null ,
(5.4)
datumnull , abteilung null , anm1null , anm2null , url1null , url2null ,
)
doknrnull , erf datumnull
(
)
SCHLAGW ORT schrif t → SCHRIF T, schlagwort, personnull , prioritaetnull
Als erstes stellt sich die Frage, wie viele Tupel enthält die Tabelle bzw. wie viele einzelne Schlagworte sind zu betrachten? Die Durchführung der SQL-Anfrage 5.1 liefert als
Ergebnis, dass die Tabelle 11769 verschiedene Schlagwörter enthält.
1 SELECT count(distinct schlagwort)
2 FROM PI.schlagwort
Algorithmus 5.1: Test: Analyse Schlagwort-Tabelle
Somit würden sich für einen Brute-Force-Ansatz 138.509.361 Join-Paare ergeben. Für
diese Paare müssten anschließend jeweils ein Ähnlichkeitsmaß berechnet werden und
abschließend die Ergebnisse nach einem bestimmten Grenzwert gefiltert werden.
Zur Analyse der Laufzeit des Brute-Force-Ansatzes wird ein Ausschnitt aus der Schlagworttabelle verwendet. Es handelt sich um 200 Tupel(ca. 1,7 % der Gesamtdaten), die
aus der Tabelle ausgewählt worden sind. Somit ergeben sich 40000(ca. 0,03 % der Gesamtdaten) Join-Paare. Anschließend sollen die Ergebnisse auf die gesamte Tabelle hochgerechnet werden. Der Ausschnitt ist nach folgendem relationalem Modell aufgebaut:
SM ALLT ABLE (source, key)
(5.5)
1 SELECT max(ed)
2 FROM (SELECT t1.source, t2.source, GETEDITDISTANCE(t1.source, t2.
source) as ed
3
FROM SMALLTABLE t1, SMALLTABLE t2)
Algorithmus 5.2: Test: Analyse Brute-Force-Ansatz - 200 Tupel - 1 Ähnlichkeitsmaß
35
Ähnlichkeitsmaß
Edit-Distance
Damerau-Levenshtein-Distance
N-Gramme
Q-Gramme
Field Similarity
Laufzeit
8,500 sec
21,885 sec
4,906 sec
3,44 sec
6,066 sec
Hochrechnung
29433 sec ≈ 490 min.
75782 sec ≈ 1263 min.
16988 sec ≈ 283 min.
11912 sec ≈ 199 min.
21005 sec ≈ 350 min.
Tabelle 5.2: Ergebnis: Wie lange dauert die Berechnung des Brute-Force-Ansatzes mit
200 Tupeln für ein Ähnlichkeitsmaß?
Die Ausführung des Algorithmus 5.2 liefert für die verschiedenen Ähnlichkeitsmaße die
Ergebnisse, die in Tabelle 5.2 dargestellt sind.
Da die Berechnung der 40000 Tupel 8,500 sec dauert, ergibt sich als Hochrechnung für die
gesamte Tabelle eine Laufzeit von mind. 29433 sec (≈ 490 min.). Diese Laufzeit genügt
nicht den Ansprüchen an eine effiziente Berechnung der Ergebnisse. Für die Berechnung
mit mehreren Ähnlichkeitsmaßen(Algorithmus 5.3) ist ebenfalls eine mindestens genauso
lange, eher längere Laufzeit zu erwarten.
1 SELECT min(ed)
2 FROM (SELECT t1.source, t2.source, sqrt(power(GETEDITDISTANCE(t1.
source, t2.source),2) + power(GETNGRAMME(t1.source, t2.source),2)
) / sqrt(2) as ed
3
FROM SMALLTABLE t1, SMALLTABLE t2)
Algorithmus 5.3: Test: Analyse Brute-Force-Ansatz - 200 Tupel - 2 Ähnlichkeitsmaße
Ähnlichkeitsmaß
Edit-Distance + N-Gramme
Edit-Distance + Q-Gramme
Edit-Distance + Field Similarity
Laufzeit
12,897 sec
12,537 sec
14,784 sec
Hochrechnung
44659 sec ≈ 744 min.
43412 sec ≈ 723 min.
51193 sec ≈ 853 min.
Tabelle 5.3: Ergebnis: Wie lange dauert die Berechnung des Brute-Force-Ansatzes mit
200 Tupeln mit zwei Ähnlichkeitsmaßen?
Wie in Tabelle 5.3 erkennbar, steigt die Laufzeit der Algorithmen erwartungsgemäß. Für
die Verwendung der verschiedenen Ähnlichkeitsmaße ergibt sich, dass sich die Laufzeit
eines Algorithmus mit mehr als einem Ähnlichkeitsmaß aus der Addition der Laufzeit
der Algorithmen mit der Verwendung von einem Ähnlichkeitsmaß ergibt.
Aus beiden Experimenten folgt, dass die Brute-Force-Strategie nicht effizient genug ist.
Ist gilt daher, die Anzahl der Vergleiche zu reduzieren, um die Laufzeit der Algorithmen
zu minimieren. Die Anzahl der Vergleiche lässt sich reduzieren, in dem man die zu vergleichenden Tupel vor dem eigentlich Vergleich nach bestimmten Kriterien sortiert. Die
folgenden Experimente zeigen die Anwendung von verschiedenen Kriterien. Als Ähnlichkeitsmaß kommt bei allen Experimenten die Edit-Distance zur Anwendung, da bei
36
der Verwendung der Edit-Distance die kürzestes Laufzeit aller Ähnlichkeitsmaße erzielt
wird. Als Datenquelle wird auch bei diesen Experimenten ein kleinerer Ausschnitt aus
der Tabelle PI.SCHLAGWORT verwendet.
1. Es werden nur Strings mit gleichem Anfangsbuchstaben verglichen.
2. Es werden nur Strings verglichen, bei denen die ersten zwei Buchstaben identisch
sind.
3. Es werden nur Strings mit der selben Länge verglichen.
4. Es werden nur Strings verglichen, deren Länge sich um +/- 1 unterscheiden.
5. Es werden nur Strings verglichen, die durch den selben Soundex repräsentiert werden.
Die folgenden Experimente zeigen die Anwendung der oben erwähnten Strategien.
1 select max(ed)
2 from (
3 select t1.source, t2.source, GETEDITDISTANCE(t1.source, t2.source)
as ed
4 from SMALLTABLE t1, SMALLTABLE t2
5 where substr(t1.source,1,1) = substr(t2.source,1,1))
Algorithmus 5.4: Es werden nur Strings mit gleichem Anfangsbuchstaben verglichen.
1 select max(ed)
2 from (
as ed
5 where substr(t1.source,1,2) = substr(t2.source,1,2))
Algorithmus 5.5: Es werden nur Strings verglichen, bei denen die ersten zwei Buchstaben
identisch ist.
1 select max(ed)
2 from (
as ed
5 where length(t1.source) = length(t2.source))
Algorithmus 5.6: Es werden nur Strings mit derselben Länge verglichen.
37
1 select max(ed)
2 from (
as ed
5 where (length(t1.source) - 1 = length(t2.source) or length(t1.source
) + 1= length(t2.source) or length(t1.source) = length(t2.source)
or length(t1.source) = length(t2.source) - 1 or length(t1.source
) = length(t2.source) + 1)
Algorithmus 5.7: Es werden nur Strings verglichen, deren Länge sich um +/- 1
unterscheidet.
1 select max(ed)
2 from (
as ed
5 where soundex(t1.source) = soundex(t2.source))
Algorithmus 5.8: Es werden nur Strings verglichen, die durch denselben Soundex
repräsentiert werden.
Bei allen diesen Ansätzen ist, unabhängig von der Effizienz, auch die Effektivität zu betrachten, denn bei den Kriterien findet auf der einen Seite eine sehr strikte Trennung von
Strings statt und auf der anderen Seite werden weiterhin Strings miteinander verglichen,
die höchstwahrscheinlich nie als Matching angesehen werden. Beim Vergleich über den
Anfangsbuchstaben(bzw. die ersten 2 Anfangsbuchstaben) werden Strings miteinander
verglichen, die, außer dem ersten Zeichen, nichts gemeinsam haben. Ähnliches gilt für
Vergleiche über die Länge(bzw. Länge +/- 1), da auch hier Strings verglichen werden, die
zwar dieselbe Länge , aber z. B. kein gemeinsames Zeichen haben. Analog verhält sich
der Vergleich mit dem Soundex als Kriterium. Dazu kommt, dass aufgrund der restriktiven Auswahl ähnliche Strings aufgrund eines Fehlers/Unterschiedes nicht verglichen
werden. Dieser Nachteil gilt ebenfalls für alle genannten Kriterien.
38
5.3
Experimente: Analyse der Sorted Neighborhood
Methode
Als Datenquelle für die Analyse der Sorted Neighborhood Methode wird ebenfalls die
Tabelle PI.SCHLAGWORTE verwendet. Auch hier wird nur ein Ausschnitt dieser Quelle
analysiert. Die Sorted Neighborhood Methode besteht aus drei Phasen: Schlüsselerzeugung, Sortierung und Vergleich. Die zweite Phase, die Sortierung, wird in den Testfällen
nicht betrachtet, da hier Algorithmen bzw. Implementationen vorhanden sind, die die
Sortierung in ausreichender Zeit erledigen. Betrachtet man die erste Phase, so ist für die
Bildung eines guten“ Schlüssels entscheidend, dass ähnliche Tupel nach der Sortierung
”
nach den Schlüsseln möglichst nahe zusammenliegen und unähnliche Tupel möglichst
weit auseinanderliegen. Die Tabelle PI.SCHLAGWORTE enthält 11769 verschiedene
Schlagworte. Die Tabelle 5.4 zeigt, wie viele verschiedene Schlüssel aus den Daten der
Tabelle PI.SCHLAGWORTE erzeugt werden. Tabelle 5.4 zeigt, dass es starke UnterArt der Schlüsselerzeugung
Anzahl verschiedener Schlüssel
Soundex
2240
Kölner Phonetik
10834
Anfangsbuchstaben(die Ersten vier)
2750
Endbuchstaben(die Letzten vier)
????
Tabelle 5.4: Wie viele verschiedene Schlüssel entstehen bei der Schlüsselerzeugung aus
der Tabelle PI.SCHLAGWORTE?
schiede bei der Anzahl der erzeugten Schlüssel gibt. Der Vorteil von vielen Schlüsseln
ist, dass eine Sortierung besser ist, da so eine feine Sortierung erfolgen kann. Durch eine
größere Anzahl an Schlüsseln lässt sich die Mindestgröße des Fenster für die Vergleichsphase verringern. Die Mindestfenstergröße wird mit der im Algorithmus 5.9 dargestellten SQL-Anfrage bestimmt. Dabei enthält die Tabelle ALGORITHMSOURCETABLE“
”
die zu untersuchenden Daten und die Spalte KEY COLUMN“ enthält den erzeugten
”
Schlüssel für das entsprechende Tupel.
1 select max(count(KEY_COLUMN)) from ALGORITHMSOURCETABLE group by
KEY_COLUMN
Algorithmus 5.9: Bestimmung des minimalen Fensterns
So liefert zum Beispiel das Verfahren der Kölner Phonetik eine Mindestfenstergröße von
16, wohin gegen das Soundex-Verfahren eine Größe von 324 und das Verfahren mit den
ersten vier Buchstaben als Schlüssel eine Größe von 298. Die Mindestfenstergröße besagt,
dass mindestens alle Elemente, die von einem Schlüssel repräsentiert werden, innerhalb
eines Fenster liegen müssen. Andererseits beeinflusst die Fenstergröße die Laufzeit der
Sorted Neighbothood Methode massiv, da die Laufzeit nur von der Fenstergröße und
39
Tupelanzahl der Quelldaten abhängt. Ein zwanzigmal größeres Fenster führt zu einer
zwanzigmal längeren Laufzeit.
In der zweiten Phase der Sorted Neighborhood Methode bedarf die Implementierung der
Sortierung keiner weiteren Analyse, da diese fest in die verwendete Oracle Datenbank
integriert ist. Es kommt hier die alphabetische Sortierung zur Anwendung. Zu betrachten
ist hier die Güte der erzeugten Schlüssel, also liegen ähnliche Begriffe wirklich nahe
beieinander und unähnliche Begriffe weit auseinander. Für alle genannten Verfahren zur
Schlüsselbildung gilt, dass die Verfahren sehr anfällig für Fehler am Anfang bzw. im
ersten Teil des Strings sind. Für das Verfahren der Endbuchstaben gilt dies analog für
das Ende der Zeichenkette. Daraus ergibt sich ebenfalls, dass die Verfahren anfälliger für
kurze Zeichenketten(3-5 Zeichen) als für längere sind. Allerdings trifft dieser Nachteil
nicht auf alle Zeichen zu, denn sollten zwei Zeichen durch das selbe Codesymbol codiert
werden, liegen die dazugehörigen Zeichenketten trotzdem nebeneinander. Als Beispiel
gelten hier die Zeichenketten agent“ und agents“. Beim Verfahren der Kölner Phonetik
”
”
liegen zwischen diesen beiden offensichtlich sehr ähnlichen Zeichenketten dreizehn weitere
Zeichenketten.
Bei der Analyse der dritten Phase, Vergleiche, der Sorted Neighborhood Methode werden die Aspekte Effektivität und Effizienz betrachtet. Zunächst lässt sich bzgl. der Effizienz bei konstanter Datenquelle folgende Gesetzmäßigkeit formulieren:
Je größer das Fenster ist,
desto größer ist die Anzahl der Vergleiche
und desto länger ist die Laufzeit
(5.6)
Dies folgt direkt aus der Definition und der Analyse der Sorted Neighborhood Methode.
Bei der Sorted Neighborhooh Methode wird im Vergleich zur Brute-Force-Strategie die
Anzahl der Vergleiche massiv reduziert. Wie in Tabelle 5.5 erkennbar ist, kann die Anzahl
der Vergleiche für eine Fenstergröße kleiner als 120 auf unter 1 % gesenkt werden. Dies
führt zu einer ebenfalls massiven Senkung der Laufzeit. Im nächsten Abschnitt soll dies
Effektivität der Sorted Neighborhood Methode betrachtet werden. Hierzu wird zunächst
ein Ausschnitt aus der Tabelle PI.Schlagwort gewählt. Der Ausschnitt umfasst 200 Tupel,
die nach der zweiten Phase nebeneinander sind. Die Schlüssel wurden mit Hilfe des
Verfahrens der Kölner Phonetik konstruiert. Die Tupel werden zufällig ausgewählt. Die
Analyse wird für eine feste Fenstergröße von 16 durchgeführt. Hierbei handelt es sich um
die Mindestfenstergröße des Verfahrens. Zur besseren Übersicht der Abbildungen werden
folgenden Abkürzungen eingeführt.
ed = Edit-Distance
ng = N-Gramme
qg = Q-Grams
dk = Damerau-Levenshtein-Distance
f s = Field Similarity
40
(5.7)
Fenstergröße
Anzahl Vergleiche
5
58845
10
117690
20
235380
30
353070
40
470760
50
588450
60
706140
70
823830
80
941520
90
1059210
100
1176900
110
1294590
120
1412280
11769(Brute-Force-Strategie)
138.509.361
Prozent
0,0425%
0,0850%
0,1699%
0,2549%
0,3399%
0,4248%
0,5098%
0,5948%
0,6798%
0,7647%
0,8497%
0,9347%
1,0196%
100%
Tabelle 5.5: Vergleich der Anzahl der Vergleiche
Die Berechnung des Ähnlichkeitsmaßes erfolgt nach den Ansätzen in Kap. 3.3. Bei der
Verwendung von mehr als einem Ähnlichkeitsmaß steht z. B. die Abkürzung edng“ für
”
die Kombination des Verfahrens der Edit-Distance und des Verfahrens der N-Gramme.
Analog erfolgt die Bildung der Abkürzungen für weitere Kombinationen.
Die Abbildungen 5.1 bis 5.6 zeigen die Ergebnisse, die im einzelnen betrachtet werden.
Abbildung 5.1 zeigt den Vergleich, inwieweit sich die Anzahl der Ergebnistupel im Bezug
auf einen bestimmten Grenzwert ändert. Die erste Beobachtung zeigt, dass erwartungsgemäß die Anzahl der Tupel mit steigendem Grenzwert sinkt. Auffällig ist jedoch, dass
das Verfahren der Damerau-Levenshtein-Distance für einen Grenzwert im Bereich von
0.7 bis 0.85 bis zu sechsmal soviele Tupel liefert, wie die Edit-Distance. Ebenfalls erwähnenswert ist hierbei, dass beim Verfahren der Damerau-Levenshtein-Distance und einem
Grenzwert von 0.7 ca. 1200 Tupel gefunden werden. Dies ist erstaunlich, da das Verfahren
3760 Vergleiche durchführt und somit ≈ 30 % der Vergleiche zu einem positiven Ergebnis
führen. Dies unterstreicht die Effizienz und damit auch die Güte der Schlüsselbildung,
da somit eher ähnliche Tupel nahe beieinander liegen als weniger ähnliche. In Abbildung
5.2 wird die benötigte Laufzeit des Programms betrachtet. Die Betrachtung findet, wie
bereits im vorherigen Experiment, in Abhängigkeit eines bestimmten Grenzwertes für
verschiedene Ähnlichkeitsmaße statt. Auffällig ist hier, dass die Laufzeit nahezu konstant
für alle Grenzwerte ist. Dies führt zu der Erkenntnis, dass das Einfügen der Ergebnisse
in die Ergebnistabelle der Datenbank keinen entscheidenden Faktor an der Laufzeit aufweist. Somit ist für die Laufzeit lediglich die Anzahl der Vergleiche maßgebend, die für
alle Durchläufe, unabhängig vom gewählten Grenzwert, konstant ist. Der Unterschied
in der Laufzeit der einzelnen Verfahren wird erst für größere Datenmengen von Bedeutung. Die Differenz in der Laufzeit liegt im Bereich von 0.1 sec bis 0.4 sec für 55225
41
1400
1200
ed
ng
dk
fs
qg
Anzahl Tupel
1000
800
600
400
200
0
0.7 0.71 0.72 0.73 0.74 0.75 0.76 0.77 0.78 0.79 0.8 0.81 0.82 0.83 0.84 0.85 0.86 0.87 0.88 0.89 0.9 0.91 0.92 0.93 0.94 0.95 0.96 0.97 0.98 0.99 1.0
Grenzw ert
Abbildung 5.1: Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 1 Ähnlichkeitsmaß - Tupel
Vergleiche. Bei den folgenden Experimenten soll die Erweiterung der Berechnung des
2,5
2
Laufzeit
1,5
1
0,5
ed
ng
qg
dk
fs
0
0,7 0,71 0,72 0,73 0,74 0,75 0,76 0,77 0,78 0,79 0,8 0,81 0,82 0,83 0,84 0,85 0,86 0,87 0,88 0,89 0,9 0,91 0,92 0,93 0,94 0,95 0,96 0,97 0,98 0,99
1
Grenzw ert
Abbildung 5.2: Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 1 Ähnlichkeitsmaß - Zeit
Ähnlichkeitsmaß auf die Anwendung von mehreren Ähnlichkeitsmaßen als Kombination
betrachtet werden. In Abbildung 5.3 werden die Ergebnisse aus der Kombination von jeweils zwei Ähnlichkeitsmaßen dargestellt. Die Kombination der Ähnlichkeitsmaße erfolgt
mit dem Verfahren der Vektorlänge. Es handelt sich hierbei um die Analyse der Frage,
wie viele Tupel von den verschiedenen Kombinationen in Abhängigkeit eines bestimm-
42
ten Grenzwerts berechnet werden. Erwartungsgemäß liegt die Anzahl an Ergebnistupel
im Bereich zwischen den beiden verwendeten Ähnlichkeitsmaßen. Dies soll am Beispiel
der Edit- und der Damerau-Levenshtein-Distance erläutert werden. Die Kombination
der beiden Ähnlichkeitsmaße liegt daher oberhalb der Edit-Distance und Unterhalb der
Damerau-Levenshtein-Distance. Die Abbildung 5.4 zeigt die Resultate bzgl. der Analyse
450
400
350
Anzahl Tupel
300
250
edfs
edng
eddk
edqg
200
150
100
50
0
0.7
0.72
0.74
0.76
0.78
0.8
0.82
0.84
0.86
0.88
0.9
0.92
0.94
0.96
0.98
1.0
Grenzwert
Abbildung 5.3: Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für die Kombination von 2 Ähnlichkeitsmaßen - Tupel
der Laufzeit. Angegeben ist die Laufzeit in Abhängigkeit der Kombination von zwei Ähnlichkeitsmaßen sowie einem bestimmten Grenzwert. Die Ergebnisse zeigen, dass sich die
Laufzeit der Algorithmen erwartungsgemäß aus der Laufzeit der einzelnen Algorithmen
addiert. Die in Abbildung 5.5 und in Abbildung 5.6 dargestellten Messwerte bestätigen
die Ergebnisse aus den vorherigen Experimenten. Somit lässt sich sagen, dass die Sorted
Neighborhood Methode Ergebnisse in einer angemessen Zeit berechnen kann. An dieser
Stelle gilt es nun zu betrachten, inwieweit die berechneten Ergebnisse den Anforderungen genügen. Also handelt es sich bei den gefunden Stringpaaren tatsächlich um echte
Matchings. Hier wird im folgenden Abschnitt die Güte der Ergebnisse betrachtet. Hierzu
werden Ergebnisse nach den Kriterien aus Kap. 5.1 analysiert und bewertet.
43
2,75
2,65
2,55
2,45
edfs
edng
eddk
edqg
Laufzeit
2,35
2,25
2,15
2,05
1,95
1,85
1,75
0,7 0,71 0,72 0,73 0,74 0,75 0,76 0,77 0,78 0,79 0,8 0,81 0,82 0,83 0,84 0,85 0,86 0,87 0,88 0,89 0,9 0,91 0,92 0,93 0,94 0,95 0,96 0,97 0,98 0,99
1
Grenzw ert
Abbildung 5.4: Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 2 Ähnlichkeitsmaße - Zeit
450
400
350
edngfs
edqgfs
edfsdk
ngqgfs
Anzahl Tupel
300
250
200
150
100
50
0
0.7 0.71 0.72 0.73 0.74 0.75 0.76 0.77 0.78 0.79 0.8 0.81 0.82 0.83 0.84 0.85 0.86 0.87 0.88 0.89 0.9 0.91 0.92 0.93 0.94 0.95 0.96 0.97 0.98 0.99 1.0
Grenzw ert
Abbildung 5.5: Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für die Kombination von 3 Ähnlichkeitsmaßen - Tupel
44
4,5
4,3
4,1
3,9
Laufzeit
3,7
edngfs
edqgfs
edfsdk
ngqgfs
3,5
3,3
3,1
2,9
2,7
2,5
0,7 0,71 0,72 0,73 0,74 0,75 0,76 0,77 0,78 0,79 0,8 0,81 0,82 0,83 0,84 0,85 0,86 0,87 0,88 0,89 0,9 0,91 0,92 0,93 0,94 0,95 0,96 0,97 0,98 0,99
1
Grenzw ert
Abbildung 5.6: Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 3 Ähnlichkeitsmaße - Zeit
45
Zur Bewertung der Ergebnisse gilt es, zunächst per Hand Matchings aus der Datenquelle zu bestimmen. In den 235 Tupel der Datenquelle befinden sich 45 Tupelpaare, die
auf jeden Fall als Matching erkannt werden müssen. Beide Tabellen sind im Anhang
zu finden. Nun wurde die Sorted Neighborhood Methode für verschiedene Kombinationen von Ähnlichkeitsmaßen und verschiedene Grenzwerte durchgeführt. Anschließend
werden die Ergebnisse des Algorithmus mit den per Hand bestimmten Tupelpaaren verglichen. In Abbildung 5.7 wird gezeigt wie viele True-Positives durch die Algorithmen
gefunden werden. Hierbei fällt sofort auf, dass keiner der genannten Algorithmen alle
45 gewählten Matchings findet. Die Abbildung 5.8 und die Abbildung 5.9 zeigen analog
zur Abbildung 5.7 wie viele Matchings von den Algorithmen erkannt werden, die als
False-Negatives bzw. False-Positives zu kategorisieren sind. Aus der Definition der Kriterien(Kap. 5.1) folgt, dass die Anzahl der True-Positives möglichst groß sein soll, sowie,
dass die Anzahl der False-Negatives und False-Positives möglichst gering seien soll. Nicht
näher betrachtet werden True-Negatives, da die Algorithmen im Hinblick auf die Erkennung von Matchings betrachtet werden und nicht auf das Finden von Nicht-Matchings.
40
38
36
34
32
30
28
26
22
20
18
16
14
12
10
8
6
4
2
Abbildung 5.7: True-Positives
46
90
88
K
K
ED
FS
D
86
K
ED
FS
D
84
K
FS
D
ED
80
FS
D
ED
78
G
ED
G
ED
Ähnlichkeitsm aß + Grenzw ert
Q
FS
87
Q
FS
85
ED
FS
83
FS
ED
89
87
91
FS
ED
FS
FS
85
FS
94
K
FS
92
D
74
K
D
72
G
Q
Q
G
70
79
G
G
N
Q
89
87
85
77
G
N
ED
ED
ED
83
0
ED
Anzahl
24
47
Abbildung 5.9: False-Positives
ED
ED
ED
FS
D
FS
D
K
K
K
K
90
88
86
84
80
78
87
85
83
91
89
87
85
94
92
74
72
Q
FS
FS
D
79
77
89
87
85
83
70
Q
FS
FS
D
G
G
ED
ED
ED
FS
ED
FS
ED
FS
ED
FS
FS
FS
FS
K
D
K
G
G
G
D
Q
Q
Q
G
N
G
N
ED
ED
ED
ED
Anzahl
ED
ED
ED
K
K
FS
FS
FS
FS
FS
FS
FS
D
D
Q
G
Q
G
85
83
91
89
87
85
94
92
74
72
70
79
77
89
87
85
83
ED
87
G
Q
FS
78
G
Q
F
ED S 8
0
FS
D
ED K 8
4
FS
D
ED K 8
6
FS
D
ED K 8
8
FS
D
K
90
ED
G
G
Q
G
N
N
ED
ED
ED
ED
Anazhl
28
26
24
22
20
18
16
14
12
10
8
6
4
2
0
Ähnlichkeitsmaß + Grenzwert
Abbildung 5.8: False-Negatives
30
28
26
24
22
20
18
16
14
12
10
8
6
4
2
0
Um die Ergebnisse der Algorithmen nun zu bewerten, werden die Maße Precision“ und
”
Recall“ berechnet. Man strebt hier einen möglichst hohen Wert für beide Maße an. In
”
1,000
0,900
Precision
0,800
0,700
0,600
0,500
0,400
90
88
K
ED
FS
D
86
K
ED
FS
D
84
K
ED
FS
D
80
K
ED
FS
D
78
G
ED
G
ED
Q
FS
87
Q
FS
85
FS
ED
83
FS
ED
ED
91
FS
89
FS
87
FS
94
85
FS
FS
92
K
D
74
K
D
72
G
Q
Q
G
70
79
G
Q
N
G
77
89
G
N
87
ED
85
ED
ED
ED
83
0,300
Abbildung 5.10: Precision
1,000
0,900
0,800
Recall
0,700
0,600
0,500
0,400
90
88
K
ED
FS
D
86
K
ED
FS
D
84
K
ED
FS
D
80
K
FS
D
ED
78
G
ED
G
ED
Q
FS
87
Q
FS
85
FS
ED
83
FS
ED
ED
FS
91
FS
89
FS
87
94
85
FS
FS
92
K
D
74
K
D
72
G
Q
Q
G
70
79
G
Q
G
N
N
G
77
89
ED
87
ED
85
ED
ED
83
0,300
Abbildung 5.11: Recall
Abbildung 5.12 ist die Kombination der beiden Maße dargestellt. Die beste Kombination
der Maße Precision“ und Recall“ ergibt sich bei den ausgewählten Kombinationen
”
”
aus der Anwendung der Kombination der Ähnlichkeitsmaße Edit-Distance, Q-Grams
und Field-Similarity mit einem Grenzwert von 0,7. Hier ergibt sich ein f-measure von
0,86. Zum Schluss der Analyse der Sorted Neighborhood Methode lässt sich sagen, dass
48
0,900
0,800
F-Measure
0,700
0,600
0,500
0,400
87
G
Q
FS
78
G
Q
F
ED S 8
0
FS
D
ED K 8
4
FS
D
ED K 8
6
FS
D
ED K 8
8
FS
D
K
90
85
ED
FS
ED
ED
83
FS
ED
91
FS
89
87
ED
FS
FS
94
85
FS
FS
D
K
92
74
K
D
72
Q
G
70
Q
G
79
Q
G
77
G
N
87
85
89
G
N
ED
ED
ED
ED
83
0,300
Ähnlichkeitsmaß + Grenzwert
Abbildung 5.12: F-Measure
diese Methode geeignet ist, um hinreichend gute Matchings aus einer Datenquelle zu
berechnen. Zu beachten sind die Einschränkungen, die in den Experimenten analysiert
und ausgewertet wurden. Die Sorted Neighborhood Methode spielt ihre Vorteile vor
allem bei großen Datenquellen aus, da sie die Laufzeit massiv senkt.
49
5.4
Experimente: Analyse der vorhandenen Datenquellen
In diesem Abschnitt werden die vorhanden Datenquellen mit den in der Implementierung
vorkommenden Algorithmen analysiert. Hierzu wird jeweils die verwendete Datenquelle
bzgl. des Schemas, nach dem sie aufgebaut ist, vorgestellt. Zur Anwendung kommen
die folgenden Datenquellen. In der Datenbank PI ist die Datenbank der Bibliothek des
Fachgebiet Datenbanken und Informationssysteme hinterlegt. Bei der Datenquelle Openstreetmap handelt es sich um Karten Daten, die unter freier Lizenz zur Verfügung stehen.
Bei den Quellen ATKIS und KVD handelt es sich um amtliche Straßendaten. Die Quelle
MovieDB enthält eine Filmdatenbank. Bei der Analyse kommt jeweils nur ein Ausschnitt
der Datenquellen zur Anwendung.
Die folgenden Experimente sollen zeigen, wie viele Objekte innerhalb der Datenquelle als
Matching erkannt werden. Hierzu wird der folgende Ansatz aus den vorhandenen Algorithmen ausgeführt: zur Anwendung kommt die Sorted Neighborhood Methode und als
Ähnlichkeitsmaße kommen die Edit-Distance, Filed Similarity, N-Gramme, DamerauLevenshtein sowie Q-Grams zum Einsatz, die mit Hilfe des Vektormodells kombiniert
werden. Der Grenzwert ist auf 0.8 festgelegt worden. Für die vorhandenen Datenquellen
wird dann jeweils ein Experiment mit diesen Rahmenbedingungen durchgeführt. Im ersten Experiment kommt die Datenquelle PI zur Anwendung. Der verwendete Ausschnitt
ist nach folgendem relationalem Schema aufgebaut:
(
SCHRIFT schrif t, autornull , titel, schrif ttyp, schrif ttyp erg null ,
(5.8)
datumnull , abteilung null , anm1null , anm2null , url1null , url2null ,
)
doknrnull , erf datumnull
)
(
SCHLAGWORT schrif t → SCHRIF T, schlagwort, personnull , prioritaetnull
(
FLIT schrif t → SCHRIF T, literaturkuerzel, isbn, verlag, instorg, ort,
auf lage, sprache, hrsg, vzweck, deskriptoren, cr, standort, anzahlnull , siganatur,
zeitschreihe, ausgabennr, band, seite, vorversion, ref erenz, erscheinungsjahr)
Die Ergebnisse bzgl. dieser Datenquelle werden in der Tabelle 5.6 dargestellt. Betrachtet
wird dabei die Laufzeit, die Anzahl der Elemente, die ein Matching mit mindestens einem
anderen Element bilden, sowie die Anzahl der vollständigen bzw. nicht vollständigen
Matchings.
Nun soll die Datenquelle MovieDB analysiert werden. Die Quelle ist nach dem relatio-
50
Ähnlichkeitsmaß
ed
ng
qg
dk
fs
edng
edqg
eddk
edfs
ngqg
ngdk
ngfs
qgdk
qgfs
dkfs
qgdkfs
eddkng
eddkqg
eddkfs
Laufzeit
in sec
246
90
89
230
130
223
163
272
189
148
205
162
252
164
297
330
268
266
367
Anzahl ähnliche
Elemente
2979
37
17
1549
466
1406
189
1245
371
3
0
0
1175
310
1789
1549
146
12
1086
vollständige
Matchings
1005
18
9
600
219
583
89
604
188
2
0
0
521
148
763
655
66
7
521
nicht vollständige
Matchings
189
8
3
144
78
62
12
64
25
1
0
0
34
12
71
55
15
0
50
Tabelle 5.6: Analyse der Datenquelle PI.Schlagwort
Ähnlichkeitsmaß
ed
ng
qg
fs
edng
edqg
edfs
qgng
fsng
fsqg
Laufzeit
in sec
26
070
60
90
11
1
12
90
1
1
Anzahl ähnliche
Elemente
379
8
0
22
0
0
0
0
0
0
vollständige
Matchings
126
5
0
15
0
0
0
0
0
0
Matchings
18
0
0
0
0
0
0
0
0
0
Tabelle 5.7: Analyse der Datenquelle PI.Flit
nalen Modell, das in den Formeln 5.9 und 5.10 dargestellt ist, strukturiert:
(
)
MOVIE movie, title, type, yearnull , runningtimenull
(
PERSON person, name, realnamenull , sexnull , heightnull ,
birth datenull , birth country null , birth locationnull ,
(5.9)
)
death datenull , death country null , death locationnull
)
(
PART part, movie → M OV IE, person → P ERSON, mentioned, creditposnull
(
)
CHARACTER part → P ART, character
(
)
51
REMARK part → P ART, remark
LINK (movie1 → M OV IE, movie2 → M OV IE, link)
LANGUAGE (movie → M OV IE, language)
GENRE (movie → M OV IE, genre)
KEYWORD (movie → M OV IE, keyword)
COUNTRY (movie → M OV IE, country)
(
)
LOCATION movie → M OV IE, country null , location
AKA (movie → M OV IE, country, aka)
RELEASE (movie → M OV IE, country, release)
RATING (movie → M OV IE, rating, votes)
BUDGET (movie → M OV IE, budget, currency)
QUOTE (movie → M OV IE, dialog, line, quote)
(5.10)
Die Datenquelle MovieDB soll bzgl. Namensvettern untersucht werden. Aufgrund der
hohen Zahl an Tupeln in der Tabelle Person“, wird dei Analyse nur für einen kleinen
”
Ausschnit durchgeführt. Die gesamte Tabelle enthält ca. 550000 Datensätze und der verwendete Ausschnitt besteht aus ca. 8000 Tupeln. Die Ergebnisse bzgl Laufzeit, gefundene
Elemente, volsständige sowie nicht vollständige Matchings sind in Tabelle 5.8 dargestellt.
Als nächstes kommt die Datenquelle Openstreetmap zur Anwendung. Die Datenquelle
Ähnlichkeitsmaß
ed
ng
qg
fs
edng
edqg
edfs
qgng
fsng
fsqg
Laufzeit
in sec
173
43
41
8
67
67
78
64
67
67
Anzahl ähnliche
Elemente
2446
9
1
512
0
0
0
0
0
0
vollständige
Matchings
345
4
1
156
0
0
0
0
0
0
Matchings
205
4
0
156
0
0
0
0
0
0
Tabelle 5.8: Analyse der Datenquelle MovieDB.Person
ist nach dem relationalen Modell, das in Formel 5.11 dargestellt ist, aufgebaut.
NODE (id, lat, lon)
(5.11)
WAY (id, isArea)
RELATION (id)
(
)
WAY REF way id → W AY, node id → N ODE, ordernull
RELATION REF (relation id → RELAT ION, object id → OBJECT 1 ,
)
type, ref, role, ordernull
(
)
TAG NODE id → N ODE, key, value
(
)
TAG WAY id → W AY, key, value
(
)
TAG RELATION id → RELAT ION, key, value
52
Aufgrund der sehr hohen Anzahl an Informationen, die in dieser Datenquellen enthalten sind, findet eine Vorauswahl der Quelldaten statt. Aus den Quelldaten wird ein
Ausschnitt ausgewählt, der Namen von Straßen enthält. Zudem wird nicht die OSMWeltdatenbank verwendet, sondern nur alle Daten für Niedersachsen. Die Vorauswahl
wird über das Tag highway“ getroffen, da es sich dann um ein Element handelt, das
”
eine Straße repräsentiert. Der als Quelle für das Experiment verwendete Ausschnitt enthält 911 Tupel. Die für das Experiment benötigte Rechenzeit beträgt 70 sec. Durch das
Programm wurden 25 Klassen erkannt, die sich in 24 vollständige Matchings und in 1
einfaches Matching aufteilen. Mit Hilfe der Datenquelle OSM wären noch weitere Analysen, zum Beispiel bzgl. Ortsnamen, möglich. Da es sich bei den Quellen ATKIS und KVD
um amtliche Daten handelt, ist davon auszugehen, dass sich innerhalb der Quellen keine
Matchings finden lassen. Somit kommt hier nur der Vergleich mit anderen Datenquellen
in Betracht. Zunächst soll kurz der Aufbau der beiden Quellen betrachtet werden. Dazu
wird für beide Quellen das relationale Modell aufgestellt. Es ist in den Formeln 5.12 und
5.13 verdeutlicht.
(
)
HAN25 OBJEKTGEOMETRIEN objektid, objektart, objektgeometrie
(5.12)
(
)
HAN25 OBJEKTE objektinr, objektart, objektgeometrie
(
HAN25 OBJEKTATTRIBUTE objektid → HAN 25 OBJEKT GEOM ET RIEN,
)
typ, wert
(
)
HAN25 OBJEKTNAMEN objektnr → HAN 25 OBJEKT E, typ, name
BESTEHT AUS (objektid → HAN 25 OBJEKT GEOM ET RIEN,
objektnr → HAN 25 OBJEKT E)
(
)
HANNOVER KVD g id, g group, g key, geometry, text, g prio
(5.13)
Da sich in beiden Quellen Straßendaten befinden, bietet sich hier jeweils ein Vergleich
mit der Datenquelle Openstreetmap an. Mit dieser Analyse ließen sich die in OSM vorliegenden Daten verifizieren und somit die Eingaben der Anwender bestätigen. Die Analyse
ergab das Ergebnis, das in Tabelle 5.9 dargestellt ist.
Ähnlichkeitsmaß
ed
fs
edfs
Laufzeit
in sec
279
112
15
Anzahl ähnliche
Elemente
3915
300
0
vollständige
Matchings
1187
136
0
Matchings
347
60
0
Tabelle 5.9: Analyse der Datenquellen KVD und OSM
1
Dieses Objekt repräsentiert die Relationen NODE, WAY und RELATION. Durch das Attribut type
wird festgelegt, um welche Relation es sich handelt.
53
Kapitel 6
Implementierung
In diesem Kapitel wird die Implementierung dargestellt. Die in den vorherigen Kapiteln
genannten Ansätze werden in einem Java-Programm implementiert. Im 1. Teil (Anforderungen) werden die Anforderungen an das Programms beschrieben. Es wird an dieser
Stelle festgelegt, was das Programm als Ergebnis liefern soll und auf welchem Weg dies
erfolgen soll. Im nächsten Abschnitt wird der generelle Aufbau(Kap. 6.2) dargestellt.
Anschließend folgt die Beschreibung der Architektur der Implementierung im Kapitel
6.3. Im Kapitel Benutzeroberfläche werden die Eigenschaften sowie das Aussehen der
Benutzeroberfläche vorgestellt. Ebenfalls vorgestellt wird der Programmablauf, den ein
Anwender bei der Ausführung des Programms antrifft. Im vorletzten Abschnitt, Installation und Deinstallation, werden Installation und Deinstallation präsentiert und erläutert.
Zuletzt wird die Art und Weise in der die Ergebnisse berechnet und abgelegt werden.
Dies geschieht im Abschnitt Installation und Deinstallation.
6.1
Anforderungen
Ziel dieser Arbeit ist die Berechnung eines Matchings von Datenbankobjekten, d.h. es soll
als Ergebnis eine Tabelle vorliegen, in deren Spalten Klassen von Matchings enthalten
sind. Als ein Matching wird ein Paar von Strings angesehen, bei denen das verwendete
Ähnlichkeitsmaß einen Wert größer oder gleich eines bestimmten Grenzwertes berechnet.
Anschließend sollen diesen Paaren Klassen zugeordnet werden. Diese Klassen enthalten
alle Matchings, für die gilt, dass alle in der Klasse enthaltenen Strings das selbe Objekt
in der realen Welt repräsentieren. Es wird kein Repräsentant einer Klasse bestimmt, daher sind alle Strings in einer Klasse gleichbedeutend. Die Auswahl eines Repräsentanten
ist Aufgabe des Anwenders und somit nicht mehr Ziel dieser Arbeit. Es soll aber überprüft werden, ob es sich bei den Objekten innerhalb einer Klasse um ein vollständiges
Matching, also ob es ein Matching von jedem zu jedem Objekt innerhalb einer Klasse
55
gibt, handelt.
6.2
Programmaufbau
In der Implementation sind mehrere Ansätze zur Berechnung von Matchings realisiert
worden. Zunächst ist der Ablauf für alle Ansätze gleich. Nach der Anmeldung bei einer Oracle Datenbank, wählt der Anwender die zu betrachtenden Tabellen und Spalten
aus. Die Suche kann hier sowohl innerhalb einer Tabelle als auch über mehrere Tabellen(maximal zwei) erfolgen. Dem Anwender stehen dabei alle Daten zur Verfügung, auf
die er mit seinen Zugangsrechten seines Datenbankzugangs zugreifen darf. Nach dieser
Auswahl folgt die grundsätzliche Entscheidung, mit welcher Strategie der Anwender arbeiten möchte. Hier stehen die Brute-Force“-Strategie sowie die Sorted Neighborhood
”
”
Methode(SNM)“(Kap. 4)zur Verfügung. Bei der Sorted Neighborhood Methode werden
zunächst zwei Schritte ausgeführt, die in der Brute-Force-Strategie nicht vorkommen.
Zunächst muss der Anwender das Verfahren zur Generierung der Schlüssel festlegen.
Hierzu stehen die im Kapitel 4 vorgestellten Verfahren zur Verfügung. Nächster Schritt
ist die Auswahl der Fenstergröße. Der Algorithmus berechnet eine Mindestfenstergröße,
die dann wiederum vom Anwender vergrößert werden kann. Der nächsten Schritten laufen in beiden Verfahren analog ab. Daher gilt für beide Verfahren, dass der Anwender
die verwendeten Ähnlichkeitsmaße selbst auswählen kann. Es wurden die in Kapitel 2
vorgestellten Algorithmen implementiert. Anschließend entscheidet der Anwender über
die Kombination der Ähnlichkeitsmaße, also wie der Ähnlichkeitswert für die einzelnen
Strings gebildet wird. Letzter Schritt ist die Festlegung eines Grenzwertes(im Intervall
von 0.0 bis 1.0), ab dem ein Paar als gefundenes Matching erkannt wird.
6.3
Architektur
Das Programm ist in fünf Packages gegliedert. Die eigentliche Anwendung ist im Package
model, im Package view sowie im Package controller implementiert. Diese Packages sind
nach dem MVC-Pattern1 aufgebaut und angeordnet. Den allgemeinen Aufbau zeigt die
Grafik 6.1. Der Aufbau nach dem MVC-Pattern bewirkt eine Trennung der Repräsentation der Daten, dem Zugriff auf die Datenquellen sowie der Programmablaufkontrolle.
Im Package dbfunctions sind die Elemente angeordnet, die in der zu nutzenden Oracle
Datenbank abgelegt werden. Im folgenden werden die einzelnen Packages vorgestellt und
die Funktionsweise der wichtigsten Klassen erläutert.
Das Package model beinhaltet den Datenbankzugriff sowie nahezu alle lokal ausgeführten Berechnungen. Es besteht aus den Packages dbaccess“, bruteforce“, displaytable“,
”
”
”
1
Model-View-Controller-Pattern
56
Abbildung 6.1: Programmaufbau
represent“ und snm“. Die Grafik 6.2 zeigt das Klassendiagramm2 der in den Packages
”
”
enthaltenen Klassen.
Abbildung 6.2: Packageübersicht des Package model
2
Klassendiagramm gemäß UML-Definition
57
Im Package dbaccess“ ist der Datenbankzugriff implementiert und wird die vorhandene
”
Verbindung zur Oracle Datenbank dem gesamten Programm zur Verfügung gestellt. Alle
anderen Objekte nutzen diese Verbindung, um SQL-Statements abzuschicken bzw. zu
verarbeiten. Im Package bruteforce“ liegen alle Klassen zur Ausführung der Brute Force
”
Strategie. Entsprechend sind im Package snm“ die Klassen zur Ausführung der Sorted
”
Neighborhood Methode angeordnet. Im Package represent“ wird für alle Strategien die
”
abschließend Berechnung der Ergebnisse implementiert. Das displaytable“ enthält die
”
Elemente zur Anzeige einer Tabelle. Die Klassendiagramme sind in den Grafiken 6.3 bis
dargestellt 6.7.
Abbildung 6.3: Packageübersicht des Package model.bruteforce
58
Abbildung 6.4: Packageübersicht des Package model.dbfunctions
Abbildung 6.5: Packageübersicht des Package model.displaytable
59
Abbildung 6.6: Packageübersicht des Package model.represent
60
Abbildung 6.7: Packageübersicht des Package model.snm
61
Das Package view enthält alle Elemente, die zur Erzeugung der GUI erforderlich sind.
Das Anmeldefenster ist in der Klasse Start“ implementiert. In der Klasse MainApp”
”
let“ ist das Hauptfenster implementiert. Die Klasse LoadTables“ erzeugt das Fenster
”
zum Auswählen der Quelltabellen. Die Klasse StartSNM“ modelliert das Fenster zur
”
Steuerung der Sorted Neighborhood Methode, sowie die Klasse StartBruteForce“ er”
zeugt das Fenster zur Steuerung der Brute-Force-Strategie. Die Klasse DisplayTable“
”
dient zum Anzeigen einer Tabelle aus der verwendeten Datenbank. Die Grafik 6.7 zeigt
das Klassendiagramm des Packages.
Abbildung 6.8: Packageübersicht des Package view
62
Das Package controller enthält die Objekte zur Steuerung des Programmablaufs. Die
Klasse Controller “ erzeugt die Instanzen des Models und der View. In den Packages
”
loadtables“, mainapplet“, bruteforce“, displatable“, start“ und snm“ sind die Beob”
”
”
”
”
”
achter der verschiedenen Schalter und Elemente der Fenster implementiert. Im Package
loadtables“ liegen die Klasse für die Elemente des Fenster zum Laden der Datenquel”
len, im Package mainapplet“ die für das Hauptfenster und im Package snm“ die für
”
”
das Fenster zur Kontrolle des Sorted Neighborhood Algorithmus. Die Klassendiagramme
sind in den Grafiken 6.9 bis dargestellt 6.15.
Abbildung 6.9: Packageübersicht des Package controller
63
Abbildung 6.10: Packageübersicht des Package controller.bruteforce
64
Abbildung 6.11: Packageübersicht des Package controller.loadtables
65
Abbildung 6.12: Packageübersicht des Package controller.displaytable
Abbildung 6.13: Packageübersicht des Package model.represent
66
Abbildung 6.14: Packageübersicht des Package controller.snm
Abbildung 6.15: Packageübersicht des Package controller.start
67
Das Package dbfunctions enthält Elemente, die als Java-Objekte in der Datenbank
abgelegt sind. Die von den verschiedenen Klassen implementierte Funktionalität wird
mit Hilfe von PL/SQL-Prozeduren aufgerufen. Das Package similarity“ enthält die Im”
plementation der verschiedenen Algorithmen zur Berechnung der Ähnlichkeitsmaße. Im
Package snm“ liegt die Implementierung des Sorted Neighborhood Algorithmus. Er wird
”
durch die Klasse Phase3DB“ realisiert. Es handelt sich hierbei um die dritte Phase des
”
Sorted Neighborhood Algorithmus. Dies gilt analog für die Brute-Force-Strategie. Ebenfalls enthalten sind die Klassen DeleteTables“ und ReverseLastLetters“. Mit Hilfe der
”
”
Klasse DeleteTables“ lassen sich die vom Programm angelegten Tabellen wieder aus der
”
Datenbank entfernen. Die Klasse ReverseLastLetters“ dient zur Berechnung der i letz”
ten Buchstaben eines Eingabestrings. Das fünfte und letzte Package main“ enthält die
”
Abbildung 6.16: Packageübersicht des Package dbfunctions
Main-Methode des gesamten Programms und dient somit zum Aufruf des Programms.
6.4
Benutzeroberfläche
Nach dem Start des Programms erscheint das in Abbildung 6.21 dargestellt Fenster.
Der Anwender muss hier zuerst mit seinen Zugangsdaten anmelden. Hierzu erforderlich
sind die URL der Datenbank, sein Benutzername und sein Passwort. Die Anmeldung
an der Datenbank wird durch einen Klick auf die Schaltfläche Verbinden“ ausgelöst. Ist
”
die Anmeldung erfolgreich, überprüft das Programm sofort, ob alle für das Programm
notwendigen Datenbank Elemente erzeugt und vorhanden sind. Ist dies auch der Fall,
erscheint eine Hinweis im Mitteilungsfeld und der Hintergrund des Feldes färbt sich grün.
68
Abbildung 6.17: Packageübersicht des Package dbfunctions.snm
Abbildung 6.18: Packageübersicht des Package dbfunctiions.similarity
Stellt das Programm bei ordnungsgemäßer Anmeldung fest, dass nicht alle Elemente
in der Datenbank vorhanden sind, wird im selben Fensterein Hinweis angezeigt, dass
die Installation ausgeführt werden muss. Näheres hierzu siehe Kap. 6.3. Ist die Anmeldung nicht erfolgreich, wird der Anwender darauf hingewiesen und muss die Anmeldung
noch einmal probieren. Sind Anmeldung und falls notwendig Architektur erfolgreich ab-
69
Abbildung 6.19: Packageübersicht des Package dbfunctions.bruteforce
Abbildung 6.20: Packageübersicht des Package main
Abbildung 6.21: Anmeldefenster
geschlossen, wird die weiter“-Schaltfläche benutzbar. Ein Klick schließt das aktuelle
”
Fenster und öffnet das in Abbildung 6.22 dargestellte Fenster. Dieses Fenster besteht
aus zwei Teilen. Im oberen befindet sich die Auswahl der Datenquellen und im unteren
die Auswahl des zu verwendenden Algorithmus. Dies Auswahl des Algorithmus ist nach
Auswahl der Datenquellen möglich. Als nächstes muss der Anwender auf die Tabellen
”
auswählen“-Schaltfläche klicken und es öffnet sich das in Abbildung 6.23 dargestellte
Fenster. In diesem Fenster wählt der Anwender die Datenquellen, die er verwenden
möchte. Dazu wählt der Anwender die enstprechenden Tabelle mit Hilfe der angzeigten Dropdown-Listen. Die Auswahl der Tabellen muss in folgender Reihenfolge erfolgen:
zuerst muss der Benutzer“, dann die entsprechende Tabelle“ und zum Schluß die zu”
”
verwendenden Spalten“ festgelegt werden. Der Inhalt der Listen für die Tabellen und
”
Spalten errechnet sich jeweils aus der Auswahl der vorherigen Liste. Sind beide Quellen
ausgewählt, ist die Ok“-Schaltfläche benutzbar und mit einem Klick darauf, werden die
”
Quellen festgelegt. Mit dem Zurück“-Button gelangt der Anwender zurück zum vorheri”
70
Abbildung 6.22: Hauptfenster vor der Tabellenauswahl
Abbildung 6.23: Tabellenauswahl
gen Fenster. Hierbei wird keine der bisherigen getroffenen Auswahlen übernommen. Mit
Hilfe der Zurücksetzen“-Schaltfläche kann der Anwender die aktuelle Auswahl wieder
”
71
zurücksetzen und die Auswahl von neuem beginnen. Wurden die Datenquellen erfolgreich
Abbildung 6.24: Hauptfenster nach der Tabellenauswahl
gesetzt, ist der Anwender wieder beim vorherigen Fenster(Abbildung 6.24). Allerdings
werden nun die ausgewählten Tabellen grün hinterlegt angezeigt. Die hinter diesen Anzeigefeldern liegenden Schaltflächen sind nun aktiv und der Anwender kann hierüber
die ausgewählten Tabellen betrachten. Ebenfalls aktiv sind die sich im unteren Bereich
befindenden Schaltflächen zur Wahl des verwendeten Algorithmus. Ab diesem Punkt variiert der Programmablauf in Abhängigkeit der gewählten Strategie. Mit einem Klick auf
die Schaltfläche SNM“ wählt der Anwender die Sorted Neighborhood Methode als Stra”
tegie aus und das Fenster(siehe Abbilding 6.25) zur Steuerung der Sorted Neighborhood
Methode öffnet sich. Das Fenster(siehe Abbilding 6.25) gliedert sich im oberen Bereich
in fünf Spalten. Diese Spalten sind vom Anwender jeweils und nacheinander zu durchlaufen, um alle notwendigen Parameter zum Start der Sorted Neighborhood Methode
zu übergeben. Zuerst gilt das zu verwendende Verfahren zur Erzeugung der Schlüssel
zu bestimmen. Der Anwender muss genau eins der angegebenen Verfahren auswählen.
Anschließend muss der Anwender die Schaltfläche Schlüssel setzen“ betätigen, um somit
”
das Verfahren zur Schlüsselerzeugung festzulegen. Hat der Anwender mehr oder weniger
als ein Verfahren gewählt, erscheint eine Fehlermeldung und der Anwender muss seine
Wahl korrigieren. Nachdem das Verfahren erfolgreich bestimmt wurde, berechnet das
Programm die Mindestfenstergröße und zeigt diese, wie Abbildung 6.26 verdeutlicht, im
oberen Textfeld der zweiten Spalten an. Der Anwender kann nun wählen, ob er die Mindestgröße beibehalten möchte oder ein größeres Fenster wählen möchte. Zum Beibehalten der Mindestfenstergröße genügt ein Klick auf die Schaltfläche Fenstergröße setzen“.
”
Möchte der Anwender den vorgegebenen Wert ändert, so muss er auf die Schaltfläche
Fenstergröße selber bestimmen“ klicken, anschließend einen Wert größer oder gleich dem
”
bisherigen Wert eingeben und abschließend auf die Schaltfläche Fenstergröße selber be”
stimmen“ klicken. Der Anwender ist nun in der dritten Spalte angelangt(siehe Abbilding
72
Abbildung 6.25: Sorted Neighborhood Methode - Wahl des Verfahrens zur Schlüsselgenerierung
Abbildung 6.26: Sorted Neighborhood Methode - Wahl der Fenstergröße
6.27). Hier gilt es mindestens ein Ähnlichkeitsmaß auszuwählen. Es können beliebig viele
Maße aus den vorgegebenen Verfahren ausgewählt werden. Die ausgewählten Verfahren
werden mit einem Klick auf die Schaltfläche Ähnlichkeitsmaß setzen“ bestätigt und der
”
Anwender gelangt in die nächste Spalte. Wählt der Anwender keine Spalte, erscheint
eine Fehlermeldung. In der vierten Spalte(siehe Abbilding 6.28) wählt der Anwender,
wie die von ihm gewählten Ähnlichkeitsmaße kombiniert werden. Auch hier gilt, dass
genau ein Verfahren ausgewählt werden muss, da sonst eine Fehlermeldung erscheint.
Durch einen Klick auf die Schaltfläche Kombination setzen“ erfolgt die Bestätigung
”
durch den Anwender und er gelangt in die letzte Spalte. In der letzten bestimmt der
73
Abbildung 6.27: Sorted Neighborhood Methode - Wahl des/der Ähnlichkeitsmaß/es
Abbildung 6.28: Sorted Neighborhood Methode - Wahl der Kombination der Ähnlichkeitsmaße
Anwender den bzw. die zu verwendenden Grenzwert/e in Abhängigkeit der Wahl der
Kombination der Ähnlichkeitsmaße. Die Abbildung 6.29 zeigt die Situation, in der die
Vektorlänge zur Kombination der Ähnlichkeitsmaße gewählt wurde. Hier gilt es für den
Anwender, den einen notwendigen Grenzwert zu bestimmen. Wurde dagegen eins der
beiden anderen Verfahren gewählt, sieht das Fenster wie Abbildung 6.30 aus. Hier muss
der Anwender für jedes der Ähnlichkeitsmaße einen Grenzwert angeben. Beim Klicken
auf die Schaltfläche Grenzwert setzen“ werden die benötigen Vorgaben überprüft und
”
falls sie vorhanden sind, wird die Schaltfläche zum Starten der Sorted Neighborhood
Methode aktiviert. Diese Situation ist in Abbildung 6.31 dargestellt. Mit einem letz-
74
Abbildung 6.29: Sorted Neighborhood Methode - Wahl des Grenzwertes - Kombination
über die Vektorlänge
Abbildung 6.30: Sorted Neighborhood Methode - Wahl des Grenzwertes
ten Klick auf die Schaltfläche SNM starten“ startet die Sorted Neighborhood Methode.
”
Nach Abschluss des Algorithmus öffnet sich ein neues Fenster und die Ergebnisse können
betrachtet werden.
Als nächstes wird die Wahl der zweiten Strategie, die Brute-Force-Strategie, vorgestellt.
Das Programm befindet sich aktuell im Zustand, der in der Abbildung 6.24 dargestellt
ist. Um die Brute-Force-Strategie zu wählen, klickt der Anwender auf die entsprechende
Schaltfläche. Es öffnet sich darauf das in Abbildung 6.32 aufgezeigte Fenster. Analog zur
Sorted Neighborhood Methode wählt der Anwender die zu benutzenden Ähnlichkeits-
75
Abbildung 6.31: Sorted Neighborhood Methode - Start
Abbildung 6.32: Brute-Force-Strategie - Wahl des/der Ähnlichkeitsmaß/es
maße aus. Anschließend folgt die Wahl der Kombination der Ähnlichkeitsmaße und das
Festlegen der entsprechenden Grenzwerte. Diese Schritte verlaufen ebenfalls analog zur
Sorted Neighborhood Methode und sind in den Abbildungen 6.33 , 6.34 und 6.35 dargestellt. Abschließend erfolgt der Start über die Schaltfläche Start BFS“. Nach Abschluss
”
des Algorithmus öffnet sich ein neues Fenster und die Ergebnisse können betrachtet
werden.
Für beide Strategien gilt, dass der Anwender über die Schaltfläche zurück“ zurück zum
”
Hauptfenster gelangt. Mit Hilfe der Schaltfläche Ende“ lässt sich der Ablauf des Pro”
gramms beenden.
76
Abbildung 6.33: Brute-Force-Strategie - Wahl der Kombination der Ähnlichkeitsmaße
Abbildung 6.34: Brute-Force-Strategie - Wahl des Grenzwertes - Kombination über die
Vektorlänge
6.5
Installation und Deinstallation
Damit das Programm lauffähig ist, werden einige Elemente benötigt, die nicht zum Standardfunktionsumfang einer Oracle Datenbank gehören. Alle diese Elemente befinden sich
in Package dbfunctions. Wie bereits im Kapitel Programmaufbau erläutert, überprüft das
Programm nach erfolgreicher Anmeldung an der Oracle Datenbank, ob alle notwendigen
Elemente, die zusätzlich erforderliche sind, bereits installiert sind. Hierzu gehören die
einzelnen Klassen, die die Berechnung des Ähnlichkeitsmaß für zwei Strings implemen-
77
Abbildung 6.35: Brute-Force-Strategie - Wahl des Grenzwertes
Abbildung 6.36: Ergebnisfenster
tieren, die für die Schlüsselerzeugung notwendigen Klassen zur Bestimmung der letzten
i“ Buchstaben und zur Erzeugung von Codes nach dem Ansatz der Kölner Phonetik,
”
sowie die Implementierung der dritten Phase der Sorted Neighborhood Methode und der
78
Brute-Force-Strategie.
Die Installation gliedert sich dabei in drei Phasen. In der ersten Phase werden die entsprechen Java Klassen in die Datenbank geladen. In der zweiten Phase werden die Klassen innerhalb der Datenbank compiliert und in der dritten Phase wird eine PL/SQLFunktion bzw. PL/SQL-Prozedur als sog. Java Stored Procedures erzeugt. Mit Hilfe
dieser Funktionen und Prozeduren werden dann die Inhalt der Java Klassen aufgerufen.
Selbstverständlich ist, dass für Ausführung der Deinstallation eine Verbindung zur Datenbank bestehen muss. Nach dem Aufruf läuft die Deinstallation selbstständig ab und
bedarf keines weiteren Interaktion mit dem Anwender. Während der Deinstallation werden alle Elemente, die vom Programm in der Datenbank installiert wurden, wieder entfernt. Hier zu gehören alle Java Klassen, die innerhalb des Package dbfunctions und
die dazu gehörigen Classfiles, die aus den entsprechenden Klassen innerhalb der Datenbank erzeut wurden. Weiterhin werden die nach dem Prinzip der Java Stored Procedure
aufgebauten Funktionen und Prozeduren wieder entfernt. Letzter Abeschnitt der Deinstallation sind die vom Programm angelegten Tabellen innerhalb der Schemata des
Anwenders.
Um die Installation, wie auch die Deinstallation, auszuführen, ist es nötig eine SQL-Datei
im SQL-Developer zu öffnen und mit Hilfe des Befehls Skript ausführen“ zu starten.
”
Nach Abschluss des Skriptes sind Installation bzw. Deinstallation abgeschlossen. Die
Skriptdateien sind folgendermaßen benannt:
• Installation: installation.sql
• Deinstallation: deinstallation.sql
6.6
Ergebnisse
Wie in den Anforderungen beschrieben, soll das Programm Matchings berechnen und
diese entsprechende Klassen zu ordnen. Die Matchingpaare werden entweder durch die
Sorted Neighborhood Methode oder durch die Brute-Force-Strategie ermittelt und liegen in Tabellen(Beispiel: siehe Tabelle 6.1) vor. Die Tabellen bestehen dabei aus drei
Spalten. Hierbei handelt es sich um die beiden als Matching identifizierten String in
jeweils einer Spalte und den errechneten Ähnlichkeitswert in einer weiteren Spalte. Um
nun die verschieden Matchings in Klassen einzuordnen, wird aus der Ergebnistabelle eine
Graphstruktur berechnet. Dies ist vor allem von Nutzen, da so nach der Einteilung in
Klassen, es auch möglich ist, zu verifizieren, ob es sich bei den in einer Klassen vorhandenen Objekten um ein vollständiges Matching handelt. Dies bedeutet, liegt in ein Objekt
innerhalb einer Klasse, so gibt es Matchings mit diesem Objekt zu allen anderen Objekten der selben Klasse. Es handelt bei dem verwendeten Graphen um einen ungerichteten
79
Objekt 1
A
A
C
E
D
G
Objekt 2
B
C
B
D
F
H
Grenzwert
0.9
0.8
0.96
0.86
0.89
0.82
Tabelle 6.1: Beispiel einer Ergebnistabelle
Graphen ohne Mehrfachkanten. Die Struktur des Graphen ist folgendermaßen aufgebaut.
Jedes Objekt wird durch einen Knoten dargestellt. Kommt eine Objekt mehrmals vor, so
wird es immer nur durch denselben Knoten repräsentiert. Zwischen zwei Knoten existiert
eine Kante genau dann, wenn es zwischen den Objekten, die durch diese beiden Knoten
repräsentiert werden, ein Matching gibt. In der Implementierung wird der Graph durch
Adjazenzliste repräsentiert. Der in Abbildung 6.37 dargestellte Graph resultiert aus den
Abbildung 6.37: Beispielgraph für die in Tabelle 6.1 dargestellten Matchings
Daten in Tabelle 6.1. Hierbei bilden die Knoten A, B, und C, D, E und F sowie G und H
jeweils eine Klasse. Die Klassen mit den Knoten A, B, und C sowie den Knoten G und
H bilden ein vollständiges Matching, da sie vollständig zusammenhängen. Die Knoten
D, E und F bilden kein vollständiges Matching, trotzdem ähneln sich die in dieser Klasse liegenden Objekte, so dass dieser zumindest einer Betrachtung durch den Anwender
bedürfen. Das endgültige Ergebnis ist dann in einer zweispaltigen Tabelle abgelegt. In
der ersten Spalte ist vermerkt, ob es sich um eine vollständiges Matching handelt oder
nicht und in der zweiten sind die einzelnen Klassen aufgelistet. Für das aktuelle Beispiel
zeigt die Tabelle 6.2 wie ein mögliches Ergebnis aussehen würde. Der Aufbau der ErgebMatching
full
path
full
Klasse
A, B, C
D, E, F
G, H
Tabelle 6.2: Ergebnistabelle
nisse ist unabhängig von der verwendeten Struktur im Programmablauf. Dies bedeutet
80
natürlich nur, dass das Schema der Tabelle für alle Varianten gleich ist, wohingegen sich
die Inhalte wesentlich unterscheiden können.
81
Kapitel 7
Erweiterung auf Datenbankobjekte
In der bisherigen Arbeit wurden immer nur Teile, ein Attribut einer Tabelle, eines Datenbankobjektes verwendet. Dies soll nun geändert werden und es sollen nun ganze“
”
Datenbankobjekte betrachtet werden. Hierzu soll in diesem Kapitel der bisherige Stand
der Arbeit auf Datenbankobjekte erweitert werden. Zu Beginn des Kapitels wird beschrieben, inwieweit zwei Datenbankobjekte als ähnlich angesehen werden. Im nächsten
sollen erste Experimente die Anwendung dieser Überlegeungen darstellen. Zum Schluss
folgt die Vorstellung der Erweiterung der Implementation.
7.1
Ähnlichkeit von Datenbankobjekten
Zunächst gilt es festzulegen, wann zwei Datenbankobjekte als ähnlich angesehen werden. Bisher fand die Betrachtung nur für ein Attribut statt und zwei Attributwerte
wurden als ähnlich angesehen, wenn die Berechnung des Ähnlichkeitsmaßes einen bestimmten Grenzwert überschreitet. Da es sich bei den Datenbankobjekten in der Regel
um mehr als ein Attribut handelt, gilt es zu bestimmen, wie diese Attribute betrachtet
und bewertet werden. Bei der Bewertung der Attribute stehen mehrere Möglichkeiten
zur Verfügung. Als Erstes soll die Möglichkeit betrachtet werden, dass die Werte jedes
Attributes tupelweise zu einem String zusammengefasst werden. Zu beachten ist, dass
die Kombination für alle Tupel in derselben Reihenfolge erfolgen muss. Dies gilt bei der
Analyse innerhalb einer Datenquelle sowie bei der Verwendung von zwei Datenquellen.
Bei der Verwendung von zwei Datenquellen muss der Anwender die Attribute in der
Reihenfolge angeben, in der sie miteinander verglichen werden sollen. Damit bei einer
späteren Analyse wieder Rückschlüsse auf die Ausgangsdaten gezogen werden können,
werden die einzelnen Attributwerte durch ein bestimmtes Zeichen oder eine bestimmte
Zeichenkombination getrennt. Anschließend lässt sich die Ähnlichkeit, wie bei der Betrachtung für einzelne Attribute, berechnen, also als einfacher Vergleich zweier Strings.
83
Das Einfügen der Zeichen zur Trennung der Attribute beeinflusst die Berechnung der
Ähnlichkeitsmaße nur im geringen Maße. Es folgt daraus, dass bei zwei identischen Datenbankobjekten die Ähnlichkeitsmaße einen Wert von 1.0 liefern. Bei unterschiedlichen
Datenbankobjekten, die aber dasselbe Objekt in der realen Welt beschreiben, führen
die länger werdenden Strings dazu, dass der berechnete Ähnlichkeitswert im Vergleich
zur Kombinationen der Attributwerte größer wird. Allerdings gilt dies konstant für alle
Verfahren und Kombinationen.
Eine weitere Möglichkeit wäre, dass die einzelnen Attribute separat betrachtet werden.
Es würde also für jedes Attribut analysiert werden, ob es sich um ähnliche Tupel handelt. Anschließend ist festzulegen, wie viele Ausprägungen von Attributen als ähnlich
angesehen werden müssen, damit zwei Datenbankobjekte als ähnlich angesehen werden.
In der Regel werden dies alle vom Anwender zur Betrachtung gewählten Attribute sein.
Analog gelten hier dieselben Einschränkungen, wie bei der Wahl der Spalten, wie sie im
ersten Ansatz bereits erläutert wurden.
An dieser Stelle sollen die Schwächen beider Ansätze betrachtet werden. Beide Ansätze
sind sehr anfällig gegenüber Nullwerten. Enthält ein Attribut Nullwerte, so führt dies
dazu, dass beim Ansatz der zusammengesetzten Strings die Datenbankobjekte aufgrund
der daraus resultierenden großen Unterschiede als unähnlich angesehen werden. Beim
Ansatz der Betrachtung der einzelnen Attribute führt der Vergleich eines Tupels mit
Nullwert und eines Tupels mit irgendeinem Nicht-Nullwert immer zu einem Ähnlichkeitswert von 0.0 und somit zu einem unähnlich Datenbankobjekt.
Bei der Auswahl der einzelnen Spalten ist zu beachten, dass keine Schlüsselspalten oder
Spalten, in denen mit Hilfe von Integritätsbedingungen keine Duplikate vorliegen, ausgewählt werden, da sonst eine Bestimmung der Matchings nicht möglich ist, da diese
Spalten, je nach ihrer Länge, für einen wesentlich niedrigeren Ähnlichkeitswert sorgen.
Dies gilt ins Besondere für Elemente, die bei einer Sortierung nach dem Schlüssel weit
auseinander liegen.
7.2
Fortgeschrittene Experimente
In diesem Kapitel sollen Experimente betrachtet werden, bei denen Datenbankobjekte
verwendet werden. Es sollen also mehrere Attrribute der Datenquelle ausgewählt werden
und so die Kombination dieser Attribute als ein Datenbankobjekt angesehen werden. Zur
Anwendung kommt hier die Tabelle PI.Schrift und es werden die Attribute Titel“ und
”
Schrifttyp“ betrachtet. Die Ergebnisse sind in der Tabelle 7.1 dargestellt.
”
84
Ähnlichkeitsmaß
ed
ng
qg
fs
edng
edqg
edfs
qgng
fsng
fsqg
Laufzeit
in sec
625
195
195
315
618
614
664
327
382
376
Anzahl ähnliche
Elemente
2785
19
0
1017
0
0
0
0
0
0
vollständige
Matchings
1092
9
0
478
0
0
0
0
0
0
Matchings
72
2
0
46
0
0
0
0
0
0
Tabelle 7.1: Analyse der Datenquelle PI.Schrift bzgl. Matchings von Datenbankobjekten
7.3
Erweiterung der Implementation
Die bisherige Implementation können nur Werte innerhalb eines Attributes verwendet
werden. Um nun auch komplette Datenbankobjekte vergleichen zu können, wird die
Implementation um den Ansatz der Kombination der einzelnen Strings zu einem String
erweitert. Dies ist relativ einfach möglich, da so nur vor der Ausführung der Sorted
Neighborhood Methode sowie auch der Brute Force Strategie die Attribute zu einem
String zusammengesetzt werden müssen und anschließend der bisherige Programmablauf
ausführbar ist. Abschließend muss noch eine Erweiterung folgen, die nach Abschluss der
Berechnung der Matchings, die einzelnen Attribute wieder trennt. Dies erfolgt anhand
eines fest definierten Trennzeichenstrings. Aufgrund der Verwendung der Verfahren der
bisherigen Implementation, verfügt auch das Verfahren nach der Erweiterung über die
Vor- und Nachteile des bisherigen Verfahrens. Zu beachten ist, dass gerade bei der Sorted
Neighborhood Methode die Phase der Sortierung stark abhängig von den ersten Zeichen
der Strings ist. Dies kommt natürlich auch bei der Erweiterung der Implementation zum
Tragen. Hierbei gilt, dass die Sortierung von der gewählten Reihenfolgen, in der die
Attribute zu einem String zusammengefasst werden, anhängig ist. Allerdings bleibt dies
im selben Umfang wie es in der bisherigen Implementierung zum Tragen kommt.
Aufgrund der Erweiterung auf Datenbankobjekten ist es nötig, dass die Struktur der
Ergebnisausgabe geändert werden muss. In der bisherigen Implementation werden die
einzelnen Strings einer Klasse zu einem String zusammengefasst, so wie es in Tabelle
6.2 dargestellt ist. Dies soll nun erweitert werden, so dass die Struktur der Datenbankobjekte erhalten bleibt. Daraus ergibt sich, dass die Ergebnistabelle alle Attribute der
Quelldaten enthält. Hierbei handelt es sich um dieselbe Anzahl an Attributen, da dies
als Voraussetzung für die Ausführung des Algorithmus notwendig ist. Hinzu kommt eine
Spalte, die die Klassenzuordnung beschreibt. Die Klassen werden durchnummeriert und
Tupel einer Klasse mit der selben Zahl gekennzeichnet. Die zweite zusätzliche Spalte be-
85
Klasse Matching
1
full
1
full
1
full
2
path
2
path
2
path
3
full
3
full
Attribut 1 Attribut 2 ... Attribut N
A1
A2
...
AN
B1
B2
...
BN
C1
C2
...
CN
D1
D2
...
DN
E1
E2
...
EN
F1
F2
...
FN
G1
G2
...
GN
H1
H2
...
HN
Tabelle 7.2: Ergebnistabelle Datenbankobjekte
schreibt, ob es sich bei der Klasse, in der das Tupel liegt, um ein vollständiges Matching
handelt. In der Tabelle 7.2 wird die Vorgehensweise verdeutlicht. Die Tupel A, B, C, D,
E, F, G und sind die Tupel, die vom Algorithmus in Klassen von Matchings zusammen
gefasst worden sind. A1 bezeichnet den Wert des ersten Attributes vom Tupel A.
86
Kapitel 8
Ausblick
In diesem Kapitel sollen Erweiterungsmöglichkeiten der Implementierung sowie Anwendungsgebiete beschrieben werden. Das Kapitel gliedert sich in drei Abschnitt. Im ersten
Abschnitt wird auf die Erweiterungsmöglichkeiten der Ähnlichkeitsmaße im Vergleich
zum Stand der Implementierung eingegangen. Im mittleren Abschnitt werden weitere
Verfahren zur Reduzierung der Anzahl von Vergleichen vorgestellt. Im letzten Abschnitt
erfolgt die Beschreibung von Anwendungsmöglichkeiten, für die in der Implementierung
verwendeten Algorithmen.
8.1
Ähnlichkeitsmaße
Bzgl. der Ähnlichkeitsmaße ist zu sagen, dass in der bisherigen Implementierung die
zu vergleichenden Strings, nicht aufgrund von ähnlich Strukturen verglichen werden,
sondern nur auf Basis ihrer Aussprache oder auf Basis ihres Zeichenvorrates, also das z.B.
ein ß“ und ein ss“ als unähnlich angesehen werden. Wie man unschwer erkennen kann,
”
”
handelt es sich hierbei um eine sprachspezifische Eigenschaft. Allein für die Deutsche
Sprache sind hier noch weitere Beispiele denkbar, wie zum Beispiel die Erkennung von
Umlauten, wie ä, ö und ü. Ebenfalls möglich ist eine Erweiterung zur Erkennung von
Objekten, die in verschiedenen Sprache definiert sind. Voraussetzung hierfür ist, dass es
ein Wörterbuch mit einer genauen Zuordnung von einem Wort der einen Sprachen zu
einem Wort der anderen Sprache gibt. Gesucht würde dann nach Wörter, die jeweils als
ähnlich der beiden Repräsentanten angesehen werden.
Eine weitere Möglichkeit der Erweiterung wäre die Betrachtung von domänenspezifischen Abkürzungen. Als Beispiel hierfür fungiert das Abkürzen von Straße“ zu Str.“.
”
”
Allerdings ist diese Variante sehr schwer zu realisieren, da so sehr viele Spezialfälle
implementiert werden müssten, da es für jede Abkürzung mindestens eine Regel zur
87
Erkennung eines Matchings geben muss. Zudem ist hierfür das Wissen eines Experten
der entsprechenden Domäne erforderlich, da nicht jeder, die in dieser Domäne üblichen
Abkürzungen kennen kann. Allerdings muss diese Aufgabe nur einmal erfüllt werden,
denn danach ist das Wissen für weiteren Anwendungen in der Domäne verfügbar.
8.2
Anzahl der Vergleiche
In der bisherigen Implementierung wird die Anzahl der Vergleiche bei der Verwendung
der Sorted Neighborhood Methode stark reduziert. Allerdings wird dabei nur auf die
Schreibweise der Repräsentanten der Objekte eingegangen. Hier wäre es möglich, die
Anzahl der Vergleiche über in der Datenbank vorhanden Information bereits im voraus
zu reduzieren. Beispielweise, wenn alle Objekte über Geometrische-Informationen verfügen, ließe sich die Anzahl der Vergleiche reduzieren, in dem nur Objekte miteinander
verglichen werden, die auch bzgl. ihrer geometrischen Positionierung nahe beieinander
liegen. Allerdings muss hier nicht nur die Bestimmung über Koordinaten zur Anwendung kommen, sondern die Positionierung kann ebenfalls über amtliche Informationen
wie Staaten, Bundesländer, Kreise, Gemeinden, Städte oder Postleitzahlen erfolgen.
Allerdings verlangen auch diese Ansätze zusätzliches Wissen über die vorhandene Datenbank, um sicherzustellen, dass sich die Daten auf dasselbe System beziehen. Zu beachten
ist hier, dass Koordinaten in verschiedenen Formen angegeben werden können und sich
zusätzlich auf verschiedene Koordinatensysteme beziehen können. Bei den amtlichen
Daten ist zu beachten, dass sich die Daten häufig nur auf einen bestimmten Bereich beziehen; zum Beispiel sind Postleitzahlen immer nur innerhalb eines Staates vergleichbar.
8.3
Anwendungsgebiete
Hauptanwendungsgebiet des in der Implementation dargestellten Programms ist die Integration von Datenbanken. Nachdem die einzelnen Schemta integriert worden sind, ist
festgelegt, welche Daten wo zu finden sind. An dieser Stelle kann das Programm zur Anwendung gebracht werden und die Integration der Daten durchgeführt werden. Hierfür
ist erforderlich, dass die Daten nach der Schemaintegration in Tabellenform vorliegen.
Es werden dann Matchings berechnet, die für eine mögliche Fusion in Frage kommen.
Konkret wird hier also die Frage beantwortet, ob es Elemente in beiden Datenquellen
gibt, die dasselbe Element in der realen Welt beschreiben.
Ein weiteres Anwendungsgebiet ist der Bereich der Ähnlichkeitsanfragen. Hier gilt es,
für einen gesuchten Begriff geeignete Matchingpartner zu finden. An dieser Stelle lassen
sich die Eigenschaften der Sorted Neighborhood Methode ausnutzen, um eine sehr effektive Suche zu implementieren. In der Datenquelle, in der nach passenden Matchings
88
gesucht werden soll, liegen bereits für alle Elemente die erzeugten Schlüssel vor. Für das
zu suchende Elemente wird zunächst sein Schlüssel erzeugt. Anschließend erfolgt die Suche nur in den für diesen Schlüssel umliegenden Bereichen(Fenstern). Daraus folgt, dass
das Element nicht mit jedem anderen verglichen werden muss, sondern nur mit einer
kleinen Auswahl. Ein weiterer Vorteil entsteht durch die Verwendung der Ähnlichkeitsmaße, da so auch Elemente erkannt werden, die nicht vollständig mit dem Suchbegriff
übereinstimmen, aber vielleicht durch den Anwender gemeint waren und dieser sich bei
der Eingabe nur vertippt hat.
89
Anhang A
SQL und PL/SQL
Algorithmus A.1: PL/SQL-Blöcke zur Verwendung einer Java-Klasse in einer Oracle-DB
1 create or replace java source named ’’Soundex’’ as
2
3 public class <<classname>> {
4 ...
5 }
6 /
1 alter java source ’’Soundex’’ compile;
1 create or replace function get_soundex_sim( a_string in varchar2,
b_string in varchar2 )
2 return number is language java name ‘SoundexDB.soundex_sim(java.lang
.String, java.lang.String) return double’;
1 SELECT a.title, b.title, get_soundex_sim(a.title, b.title) FROM
MOVIEDB.production a, MOVIEDB.production b;
91
Anhang B
XSLT
1
2
3
4
5
6
7
8
9
10
11
12
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="osm">
<xsl:result-document href="NODE.txt">
<xsl:for-each select="node">
"<xsl:value-of select="@id" />","<xsl:value-of select="@lat" />","
<xsl:value-of select="@lon" />",</xsl:for-each>
</xsl:result-document>
<xsl:result-document href="WAY.txt">
<xsl:for-each select="way"><xsl:if test="nd[position()=1]/@ref=nd[
position()=last()]/@ref">"<xsl:value-of select="@id" />","true"</
xsl:if><xsl:if test="nd[position()=1]/@ref!=nd[position()=last()
]/@ref">"<xsl:value-of select="@id" />","false"</xsl:if>,</
xsl:for-each>
13 </xsl:result-document>
14
15 <xsl:result-document href="RELATION.txt">
16
<xsl:for-each select="relation">"<xsl:value-of select="@id" />",<
/xsl:for-each>
18
19 <xsl:result-document href="REF.txt">
20
<xsl:for-each select="way"><xsl:variable name="wayid" select="@id
"/><xsl:for-each select="nd">"<xsl:value-of select="$wayid" />
","<xsl:value-of select="@ref" />","<xsl:value-of select="
position()" />",</xsl:for-each></xsl:for-each>
93
22
23
24 <xsl:result-document href="TAG.txt">
25
<xsl:for-each select="node()"><xsl:variable name="nodeName"
select="name()"/>
26
<xsl:variable name="ids" select="@id"/><xsl:for-each select="tag"
>" <xsl:value-of select="$ids" />","<xsl:value-of select="$
nodeName" />","<xsl:value-of select="@k" />","<xsl:value-of
select="@v" />",</xsl:for- each></xsl:for-each>
28
29 <xsl:result-document href="MEMBER.txt">
30
<xsl:for-each select="relation"><xsl:variable name="relationid"
select="@id"/><xsl:for-each select="member">"<xsl:value-of
select="$relationid"/>","<xsl:value-of select="@type" />","<
xsl:value-of select="@ref" />","<xsl:choose><xsl:when test="
string-length(@role)=0">null</xsl:when><xsl:otherwise><
xsl:value-of select="@role"/></xsl:otherwise></xsl:choose>","<
xsl:value-of select="position()" />",</xsl:for-each></
xsl:for-each>
32 </xsl:template>
33
34 </xsl:stylesheet>
Algorithmus B.1: XSLT-Transformation der Datenquelle Openstreetmap
94
Anhang C
Experimente
Bei der Tabelle C.1 handelt es sich um einen Ausschnitt aus der Tabelle PI.Schlagworte,
der bei der Analyse der Sorted Neighborhood Methode zur Anwendung kommt. Die
Tabelle enthält eine Spalte, die zur besseren Übersicht nebeneinander dargestellt ist.
SOURCE
object-oriented methods
object-oriented multimedia
object oriented software development
object-oriented software development
object-oriented software design
object oriented software design
object-oriented software specification
object-oriented systems
object-oriented specification
object hierarchy
object hierarchy diagram
object design
object as unit of design
object as unit of structure and behaviour
object association
object aspect
object as process
object history queries
95
SOURCE
object history constraints
object histories
object occurrence state
object description
object descriptions as units of design
object descriptor
object bahaviour
object behaviour
object behavior
Object/Behavior Diagrams
object-behaviour model (OBM)
object paradigm
object base
object-based, OO paradigm
object based databases
object-based data models
object-based programming
object-based programming environment
SOURCE
object based view
object-based language
object-based models
object-based specification language
object base environment for simulation
object base instance
object-bases
object base scheme
objectbase schema
Object-Pascal
object property
object preservation
object preserving operation
object-preserving operation
object preserving operator semantics
object preserving join
object preserving query
object DBS
object-feature logic
object view
object view hierarchy
object views
object filter
object variable
object version
object versioning
object visualization
object vs. value
object-generating operation
object generating query
object query language
object query language (OQL)
object graph
object ggregation
object cooperation
object collaborations
object calculus
object community
object communities
object communication
object communication model
Object Communication Diagram
object composition
SOURCE
object context
object concept
object constraint
object constraint language (OCL)
object life cycle
object lifecycle
object life-cycles
object life cycles
object logic
object logics
object logic (OBLOG)
object model
object-module design
object modelling
object modeling
object modeling technique
Object Modeling Technique (OMT)
object-model-diagrams
object model for spatial objects
object models
object metamodel for object diagram
object metamodel for relational databases
object metamodel for state diagram
object methods
object-migration
object migration
object migration and classification
object migration inventory
object migration pattern
object machine
object management
object management system
object manager architecture
object naming
object morphism
object merging
object normalforms
object refinement
object request broker
object-relation model
object relation network
object relationa concepts
object-relational
96
SOURCE
object relational
object-relational database
object-relational databases
object-relational databases (ORDBS)
object-relational database system
object-relational database systems
object-relational database schema
objectrelational data model
object-relational data model
object-relational DB design
object-relational DBMS
object-relational DBMS (ORDBMS)
object-relational DBMS architecture
objectrelational DBS
object-relational DBS
object-relational DBS (ORDBS)
objectrelational DBS (ORDBS)
object-relational DB schema design
object-relational query optimization
objectrelational MMDBS
object relational sql
object relationship
object-relationship model
object-relationship model (ORM)
object relationships
object-role model
object-role modelling
object role models
object-role models
object roles
object transformation
Object Transformer Generator
object reorganization
Object-Z
object Z
object subclass hierarchy (OSH)
object signature
object semantics
object-centric system
object sharing
object servers
object society
object societies
SOURCE
object society specification
object specification
object specification and verification
object specification library
object specification logic
object specification logic (OSL)
object specification language
object specification language (OSL)
object specifications
object specialization
object specialization vs. type specialization
object splitting
object state
object state event
object storage
object storage structures
object structure
object structure model
object structure server
Object SQL
Object SQL (OSQL)
object clipping
object class
object classification
object class interface
object classes
object clustering
object creation
object creation and destruction
object creating join
HiPAC features
objects vs. processes
objects vs. the target system
objects vs. values
ObjectSQL objectsql
HiPAC knowledge model
objectchart
objectcharts
ObjectScript
AP5 (dependend language etc.)
OBD (object-behaviour diagrams)
update
update-operation
97
SOURCE
update operation
updatable record field
update propagation
Update propagation
update propagation algorithm
update problem
update program
update dependencies
updated constraint
update transactions
update translation
update equivalence
update control in logic programs
update constraints
update expansion
update logic
update language
update languages
update modification
update-in-place
update-independent triggers
update independence
updating tables
updating views
updating / recording / correcting information
update reversibilty
update related problems
update rules
Tabelle C.1: Ausschnitt aus der Tabelle PI.Schlagwort
98
SOURCE1
SOURCE2
object oriented software development object-oriented software development
object-oriented software design
object oriented software design
object description
object descriptor
object bahaviour
object behaviour
object bahaviour
object behavior
object behaviour
object behavior
object base
object-bases
object base scheme
objectbase schema
object preserving operation
object-preserving operation
object view
object views
object version
object versioning
object query language
object query language (OQL)
object community
object communities
object life cycle
object lifecycle
object life cycle
object life-cycles
object life cycle
object life cycles
object lifecycle
object life-cycles
object lifecycle
object life cycles
object life-cycles
object life cycles
object logic
object logics
object model
object models
object modelling
object modeling
object modeling technique
Object Modeling Technique (OMT)
object-migration
object migration
object-relational
object relational
Tabelle C.2: Händisch ausgewällte Matchings - Teil 1
Die Tabelle C.2 zeigt die für die Analyse der Sorted Neighborhood Methode notwendigen
per Hand bestimmten Matchings.
99
SOURCE1
SOURCE2
object-relational databases
object-relational databases (ORDBS)
object-relational database system
object-relational database systems
objectrelational data model
object-relational data mode
object-relational DBMS
object-relational DBMS (ORDBMS)
object relationship
object relationships
object-role model
object role models
object-role model
object-role models
object role models
object-role models
Object-Z
object Z
object society
object societies
object specification logic
object specification logic (OSL)
object specification language
object specification language (OSL)
Object SQL
Object SQL (OSQL)
object specification
object specifications
object class
object classes
objectchart
objectcharts
update-operation
update operation
update propagation
Update propagation
update language
update languages
Tabelle C.3: Händisch ausgewällte Matchings - Teil 2
100
Abbildungsverzeichnis
2.1
Abstand der Tasten R und B auf einer Tastatur . . . . . . . . . . . . . .
9
3.1
Kombination von Ähnlichkeitsmaßen - nacheinander . . . . . . . . . . . .
24
3.2
Kombination von Ähnlichkeitsmaßen - parallel . . . . . . . . . . . . . . .
25
3.3
26
3.4
27
4.1
Sorted Neighborhood Methode - Verschieben des Fensters . . . . . . . . .
30
5.1
Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 1 Ähnlichkeitsmaß - Tupel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 1 Ähnlichkeitsmaß - Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für die Kombination von 2 Ähnlichkeitsmaßen - Tupel . . . . . . . . . . . . . . . . . .
43
Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 2 Ähnlichkeitsmaße - Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für die Kombination von 3 Ähnlichkeitsmaßen - Tupel . . . . . . . . . . . . . . . . . .
44
Sorted Neighborhood Methode - Grenzwert 0.70 bis 0.99 für 3 Ähnlichkeitsmaße - Zeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.7
True-Positives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.8
False-Negatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.9
False-Positives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.10 Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.11 Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.12 F-Measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.2
5.3
5.4
5.5
5.6
101
6.1
Programmaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
6.2
Packageübersicht des Package model . . . . . . . . . . . . . . . . . . . .
57
6.3
Packageübersicht des Package model.bruteforce . . . . . . . . . . . . . .
58
6.4
Packageübersicht des Package model.dbfunctions . . . . . . . . . . . . . .
59
6.5
Packageübersicht des Package model.displaytable . . . . . . . . . . . . .
59
6.6
Packageübersicht des Package model.represent . . . . . . . . . . . . . . .
60
6.7
Packageübersicht des Package model.snm . . . . . . . . . . . . . . . . . .
61
6.8
Packageübersicht des Package view . . . . . . . . . . . . . . . . . . . . .
62
6.9
Packageübersicht des Package controller
. . . . . . . . . . . . . . . . . .
63
6.10 Packageübersicht des Package controller.bruteforce . . . . . . . . . . . . .
64
6.11 Packageübersicht des Package controller.loadtables . . . . . . . . . . . . .
65
6.12 Packageübersicht des Package controller.displaytable . . . . . . . . . . . .
66
6.13 Packageübersicht des Package model.represent . . . . . . . . . . . . . . .
66
6.14 Packageübersicht des Package controller.snm . . . . . . . . . . . . . . . .
67
6.15 Packageübersicht des Package controller.start . . . . . . . . . . . . . . . .
67
6.16 Packageübersicht des Package dbfunctions . . . . . . . . . . . . . . . . .
68
6.17 Packageübersicht des Package dbfunctions.snm . . . . . . . . . . . . . . .
69
6.18 Packageübersicht des Package dbfunctiions.similarity . . . . . . . . . . .
69
6.19 Packageübersicht des Package dbfunctions.bruteforce . . . . . . . . . . .
70
6.20 Packageübersicht des Package main . . . . . . . . . . . . . . . . . . . . .
70
6.21 Anmeldefenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
6.22 Hauptfenster
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6.23 Tabellenauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6.24 Hauptfenster
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
6.25 Sorted Neighborhood Methode - Wahl des Verfahrens zur Schlüsselgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.26 Sorted Neighborhood Methode - Wahl der Fenstergröße . . . . . . . . . .
73
6.27 Sorted Neighborhood Methode - Wahl des/der Ähnlichkeitsmaß/es . . . .
74
6.28 Sorted Neighborhood Methode - Wahl der Kombination der Ähnlichkeitsmaße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
6.29 Sorted Neighborhood Methode - Wahl des Grenzwertes - Kombination
über die Vektorlänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
102
6.30 Sorted Neighborhood Methode - Wahl des Grenzwertes . . . . . . . . . .
75
6.31 Sorted Neighborhood Methode - Start . . . . . . . . . . . . . . . . . . . .
76
6.32 Brute-Force-Strategie - Wahl des/der Ähnlichkeitsmaß/es . . . . . . . . .
76
6.33 Brute-Force-Strategie - Wahl der Kombination der Ähnlichkeitsmaße . .
77
6.34 Brute-Force-Strategie - Wahl des Grenzwertes - Kombination über die
Vektorlänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.35 Brute-Force-Strategie - Wahl des Grenzwertes . . . . . . . . . . . . . . .
78
6.36 Ergebnisfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6.37 Beispielgraph für die in Tabelle 6.1 dargestellten Matchings . . . . . . . .
80
103
Tabellenverzeichnis
2.1
Matrix für das o.g. Edit-Distance-Beispiel . . . . . . . . . . . . . . . . .
7
2.2
Gewichte t(i, j) für das Maß des Abstandes auf der Tastatur . . . . . . .
10
2.3
Damerau-Levenshtein-Distance-Beispiel . . . . . . . . . . . . . . . . . . .
11
2.4
Kodierung Soundex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.5
Kodierung Kölner Phonetik . . . . . . . . . . . . . . . . . . . . . . . . .
14
5.1
Klassen von Paare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.2
Ergebnis: Wie lange dauert die Berechnung des Brute-Force-Ansatzes mit
200 Tupeln für ein Ähnlichkeitsmaß? . . . . . . . . . . . . . . . . . . . .
36
Ergebnis: Wie lange dauert die Berechnung des Brute-Force-Ansatzes mit
200 Tupeln mit zwei Ähnlichkeitsmaßen? . . . . . . . . . . . . . . . . . .
36
Wie viele verschiedene Schlüssel entstehen bei der Schlüsselerzeugung aus
der Tabelle PI.SCHLAGWORTE? . . . . . . . . . . . . . . . . . . . . . .
39
5.5
Vergleich der Anzahl der Vergleiche . . . . . . . . . . . . . . . . . . . . .
41
5.6
Analyse der Datenquelle PI.Schlagwort . . . . . . . . . . . . . . . . . . .
51
5.7
Analyse der Datenquelle PI.Flit . . . . . . . . . . . . . . . . . . . . . . .
51
5.8
Analyse der Datenquelle MovieDB.Person . . . . . . . . . . . . . . . . .
52
5.9
Analyse der Datenquellen KVD und OSM . . . . . . . . . . . . . . . . .
53
6.1
Beispiel einer Ergebnistabelle . . . . . . . . . . . . . . . . . . . . . . . .
80
6.2
Ergebnistabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
7.1
Analyse der Datenquelle PI.Schrift bzgl. Matchings von Datenbankobjekten 85
7.2
Ergebnistabelle Datenbankobjekte . . . . . . . . . . . . . . . . . . . . . .
86
C.1 Ausschnitt aus der Tabelle PI.Schlagwort . . . . . . . . . . . . . . . . . .
98
C.2 Händisch ausgewällte Matchings - Teil 1 . . . . . . . . . . . . . . . . . .
99
5.3
5.4
105
C.3 Händisch ausgewällte Matchings - Teil 2 . . . . . . . . . . . . . . . . . . 100
106
Algorithmus
2.1
Algorithmus zur Bestimmung der Edit-Distance . . . . . . . . . . . . . .
7
2.2
Algorithmus zur Bestimmung des Soundex . . . . . . . . . . . . . . . . .
12
2.3
Algorithmus zur Bestimmung der Jaro-Distance . . . . . . . . . . . . . .
16
2.4
Algorithmus zur Bestimmung der Field-Similarity-Distance . . . . . . . .
17
4.1
Algorithmus der Sorted-Neighborhood-Methode . . . . . . . . . . . . . .
31
5.1
Test: Analyse Schlagwort-Tabelle . . . . . . . . . . . . . . . . . . . . . .
35
5.2
Test: Analyse Brute-Force-Ansatz - 200 Tupel - 1 Ähnlichkeitsmaß . . . .
35
5.3
Test: Analyse Brute-Force-Ansatz - 200 Tupel - 2 Ähnlichkeitsmaße . . .
36
5.4
Es werden nur Strings mit gleichem Anfangsbuchstaben verglichen. . . .
37
5.5
Es werden nur Strings verglichen, bei denen die ersten zwei Buchstaben
identisch ist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.6
Es werden nur Strings mit derselben Länge verglichen. . . . . . . . . . .
37
5.7
Es werden nur Strings verglichen, deren Länge sich um +/- 1 unterscheidet. 38
5.8
Es werden nur Strings verglichen, die durch denselben Soundex repräsentiert werden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
Bestimmung des minimalen Fensterns . . . . . . . . . . . . . . . . . . . .
39
A.1 PL/SQL-Blöcke zur Verwendung einer Java-Klasse in einer Oracle-DB . .
91
B.1 XSLT-Transformation der Datenquelle Openstreetmap . . . . . . . . . .
93
5.9
107
Literaturverzeichnis
[LN2007]
U. Leser, F. Naumann: Informationsintegration, dpunkt.verlag, 1. Auflage,
Heidelberg, 2007.
[KS2005]
N. Koudas, D. Srivastava: Approximate Joins: Concepts and Techniques,
in: Proceedings of the International Conference on Very Large Databases
(VLDB), S. 1363, 2005.
[EIV2007]
A. K. Elmagarmid, P. G. Ipeirotis, V. S. Verykios: Duplicate Record Detection: A Survey, in: IEEE Transactions on Knowledge and Data Engineering,
Vol. 19, No. 1, Januar 2007.
[ZLBL2004] J. Zhang, T. W. Ling, R. M. Bruckner, H. Liu: PC-Filter: A Robust Filtering Technique for Duplicate Record Detection in Large Databases, In F.
Galindo, M. Takizawa, R. Traunmüller (eds.), Database and Expert Systems
Applications 15th International Conference, DEXA 2004, Zaragoza, Spain,
August 30 September 3, 2004, LNCS, Springer-Verlag, Berlin, 2004
[SLP2002] S. Y. Sung, Z. Li, S. Peng: A fast ltering scheme for large database cleansing,
In K. Kalpakis (ed.), Proceedings of the Eleventh International Conference
on Information and Knowledge Management, CIKM 2002 : November 4 - 9,
2002, McLean, Virginia, USA, ACM Press, New York, NY, 2002
[ME1996]
E. Monge, C. Elkan: The Field Matching Problem: Algorithms and Applications, In E. Simoudis, J. Han, U. M. Fayyad (eds.), Proceedings of the
Second International Conference on Knowledge Discovery and Data Mining,
AAAI Press, Menlo Park, Calif., 1996
[BRA2007] M. Bramer: Principles of Data Mining Springer-Verlag, London, 2007
[HS1995]
M. A. Hernández, S. J. Stolfo: The Merge/Purge Problem for Large Databases, In M. Carey, D. Schneider (eds.), Proceedings of the 1995 ACM
SIGMOD International Conference on Management of Data, San Jose, May
22-25, 1995, SIGMOD Record 2, ACM Press, New York, 1995
[HS1998]
M. A. Hernández, S. J. Stolfo: Real-world Data is Dirty: Data Cleansing
and The Merge/Purge Problem, Data Mining and Knowledge Discovery 2:1
(1998), 9-37.
109
[MB2006]
A. Mazeika, M. H. Böhlen: Cleansing Databases of Misspelled Proper Nouns,
In Proceedings of the First Int. VLDB Workshop on Clean Databases, CleanDB 2006, September 11, 2006, Seoul, Korea, 2006.
[Le0809]
U. Leser: Vorlesung Informationsintegration, Humboldt Universität, Wintersemester 2008/2009, Kap. 24 Duplikaterkennung.
[Wo2009]
P. Wolski: Entwicklung von Werkzeugen zur Datenbereinigung in relationalen Datenbanken, Bachelorarbeit, Leibniz Universität Hannover, 2009.
[Pa2010]
R. Parchmann: Skript zur Vorlesung Zeichenkettensuche, Leibniz Universität Hannover, Sommersemester 2010.
110
Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehörige Implementierung selbststandig verfasst und dabei nur die angegebenen Quellen und Hilfsmittel
verwendet habe.
Hannover, 03. Mai 2012
Andreas Prante
111

- Fachgebiet Datenbanken und Informationssysteme

Transcription

Similar documents

Duplikaterkennung

Document 5811490

Inhaltsbasierte¨Ahnlichkeitsmetriken zur Navigation in

Wie lehrt man IT-Sicherheit am besten? ¨Uberblick, Klassifikation