Im letzten Beitrag Dublettensuche mit Microsoft DQS – Teil 1 bin ich allgemein auf die Erstellung von Matching Regeln innerhalb der DQS eingegangen. In diesem Beitrag soll es nun um die Erstellung von Matching Rules gehen.
“Wann” ist eine Dublette?
Bevor ich näher auf das eigentliche Erstellen der Matching Rules eingehe, möchte ich vorher kurz auf ein wichtige Frage in diesem Zusammenhang eingehen: “Wann” ist eine Dublette?
Zugegeben, grammatikalisch macht die Überschrift keinen Sinn, aber “Was ist eine Dublette?” trifft es nicht ganz. Grundsätzlich bezeichnet man mit einer Dublette einen doppelten Datensatz, da mit den Matching Rules aber eine Fuzzy-Suche stattfindet, sollte man sich hier Gedanken darüber machen wann zwei oder mehr Datensätze wirklich Dubletten zueinander darstellen.
Aus rein technischer Sicht, kann man relativ einfach sagen, wenn Datensätze zu 80%, 85% oder 90% übereinstimmen, wurde eine Dublette gefunden.
Je nach Anwendungsfall ist es aber extrem relevant, welche Domains (um in der Begrifflichkeit der DQS zu bleiben) bei der Suche mit einbezogen werden und für welchen Zweck die Dublettensuche durchgeführt wird. Um dies zu klären, sollte man sich z.B. über folgende Fragen bereits vor dem Aufbau einer Matching Policy Gedanken machen:
- Handelt es sich bei den Adressen um Privatadressen oder um Businessadressen?
- Gibt es Hierarchien wie Konzern, Firmengruppe oder auch Gebäude, Haushalt, Ehepartner usw. in den Datensätzen die relevant sind?
- Sollen die Ergebnisse in einem operative oder einem analytischem System verwendet werden?
- Ist eine hohe Trefferquote eventuell besser, z.B. bei einer Prüfung gegen Sanktionslisten, Anti-Terrorlisten oder der Denied Person List?
- Werden die Ergebnisse automatisiert übernommen oder ist ein manueller Prüfprozess nachgeschaltet?
In einem älteren Beitrag Fuzzy Search Teil 1 – Doppelte Datensätze suchen, finden und nicht finden (wollen) habe ich einige dieser Punkte bereits detaillierter erklärt.
Beispieldaten
Beim Aufbau einer Matching Policy innerhalb der DQS werden zwingend Daten benötigt. Dies sollte man sich zu nutze machen und nicht direkt die Echtdaten eines Projektes laden und einfach irgendwelche Regeln anwenden bei denen es auf den ersten Blick zu richtigen Ergebnissen kommt. Der bessere Weg ist, sich einen Satz von Beispieldaten zu erstellen. Neben den Daten, die als Dubletten erkannt werden sollen, ist es dabei ebenso wichtig, Daten mit aufzunehmen, die nicht als Dubletten erkannt werden sollen.
Für das folgende Beispiel habe ich einige fiktive Privatadressen, mit aus meiner Sicht klassischen Fehlern/Unterschieden, erstellt.
Die Dublettengruppen sind jeweils farblich gekennzeichnet und mit einer Zahl in Spalte “D” versehen. Die grün gekennzeichneten Datensätze sollen später nicht als Dubletten erkannt werden.
Beim Erstellen der Beispieldaten in Excel sollte darauf geachtet werden, dass die Spalten explizit als Text definiert werden. Ansonsten erkennen die DQS die Spalte PLZ als Decimal Wert, wodurch eine Zuordnung zur Domain PLZ, die als String definiert ist, nicht möglich ist.
Die Matching Policy
Zum Erstellen der Matching Policy verwende ich die Domain aus meinem letzten Beitrag.
Die Excel-Datei mit den Beispieldaten wird nach dem Laden den Domains aus der Knowledge Base zugeordnet.
Es ist Vorteilhaft am Anfang eine einfache Domain zu erstellen und diese danach in anderen Rules auf die weiteren Fehler/Unterschiede innerhalb der Daten anzupassen. Die erste Rule enthält somit die Domains Vorname, Nachname, Strasse und Ort mit einer Gewichtung von jeweils 25% und einem minimalen Gesamt-Score von 80%. Angewendet auf die Beispieldaten, wird folgendes Ergebnis erreicht.
Im Ergebnis sieht man, dass die entsprechenden Datensätze einen Score von 89% haben, so dass man ggf. auch den Score für diese Regel hoch auf ca. 85% setzen könnte.
Um die weiteren Datensätze zu finden, werden nun weitere Regeln definiert, die auf die speziellen Unterschiede innerhalb der Datensätze zugeschnitten sind. Auch wenn die Namensgebung für die einzelnen Regeln einem nicht sehr leicht fallen mag, sollten hier schon aussagekräftige verwendet werden. So wird z.B. als nächstes eine Regel “Vorname Schwach” erstellt, mit der unter anderem die Datensätze “Hildegard” und “Hilde” gefunden werden sollen.
Mit den Einstellungen Vorname 10%, Nachname 30%, Strasse 30% und Ort 30% wird das entsprechende Ziel bereits erreicht. Die Ergebnis sehen dann wie folgt aus:
Am schwierigsten als Dubletten zu erkennen, sind die Datensätze “Murtschek” und “Murzcek”, ohne den Datensatz “Müller” mit in die gleichen Gruppe zu setzen. Dies wird zwar mit den Einstellungen PLZ 15%, Ort 15%, Vorname 30%, Nachname 10% und Strasse 30% erreicht, wobei ich hier PLZ und Ort zusätzlich noch als Exact und nicht als Similar definieren.
Bei diesen feineren Einstellungen ist die Detailansicht für die einzelnen Dubletten sehr hilfreich. Hier wird für jede einzelne Domain der entsprechende Score mit der dazugehörigen Gewichtung genau angezeigt.
Die Detailansicht kann über einen Doppelklick auf eine Dublette geöffnet werden. In der Detailansicht lässt sich auch sehr gut erkennen, wie der Score berechnet wird. Die Strasse stimmt hier z.B.nur zu 76% überein. Dieser Wert wird mit der Gewichtung multipliziert und ergibt so zusammen mit den anderen Scores den Gesamtscore von 83%.
Ein wichtiger Hinweis für die Detailansicht: Domains, die mit weniger als 60% übereinstimmen, werden hier nicht angezeigt.
Ergebnis
In den von mir erstellen Beispieldaten konnten alle Datensätze die eine Dublette darstellen gefunden werden. Mit den drei Rules wird also eine sehr gute True Positive Quote erzielt, wobei keine False Postive im Ergebnis enthalten sind. Jedoch sind die von mir erstellten Datensätze für ein reales Projekt definitiv zu gering. Man sollte sich auch darüber im klaren sein, dass die Einstellungsmöglichkeiten immer einen gewissen Anteil an False Positives oder auch False Negatives ergeben. Regeln die nur True Positives und True Negatives erzielen, sind mit realen Datenmengen kaum möglich.
Auf der anderen Seite muss ich auch ganz klar erwähnen, das bei den getroffenen Einstellungen durch geringe Änderungen der Datensätze sehr schnell False Positive Werte erzielt werden können. Dies liegt speziell an der letzten Regel, bei der ein sehr geringer Schwellenwert für den Nachnamen angesetzt wird. Hier ist aus meiner Sicht noch ein Nachteil der DQS zu sehen. Der Name Murczek und Murtschek liegt – zumindest in der deutschen Aussprache – nicht wirklich weit auseinander. Die DQS erkennen dies leider nicht, wodurch die Schwellenwerte sehr niedrig angesetzt werden müssen. Leider lässt sich dies Verhalten durch eine Anpassung der Sprachen in den jeweiligen Domains auch nicht verbessern. Die Sprachen haben lediglich Auswirkungen auf die integrierte Rechtschreibkorrektur.
Schade an dieser Stelle ist, dass die in den MDS integrierte Fuzzy-Suche, die per T-SQL mit
mdq.Similarity(‘Murtschek’, ‘Murczek’, 0, 0.0, 0.0)
aufgerufen werden kann, zwischen diesen beiden Namen eine Ähnlichkeit von ca. 66% ausgibt, was allerdings auch kein “Spitzenwert” für einen Ähnlichkeitsalgorithmus darstellt. Algorithmen, die ich in einigen anderen Projekten einsetze, geben bei diesem Namen einen Ähnlichkeitswert zwischen 95% und 100% aus.
Grundsätzlich liefern die Matching Policy der DQS gute und brauchbare Ergebnisse, jedoch sind an einigen Stellen auch noch ein paar Schwächen zu erkennen. Hier möchte ich aber auch noch einmal darauf hinweisen, dass die Matching Policy als Teil eines Gesamtkonzeptes zu sehen sind, und durch vorherige Bereinigungen der Daten wesentlich bessere Ergebnisse erzielt werden können. Zwar ist es schwer oder auch eigentlich gar nicht möglich Nachnamen über eine Domain zu normieren (Namen existieren in der Regel in verschiedenen Schreibweisen, siehe Maier, Meier, Mayer), aber auch eine Normierung oder Korrektur der Adresselemente kann die Einstellungen der Regeln erheblich verbessern.
Eine vorherige Bereinigung sollte auch nicht unter den Punkt Zusatzaufwand fallen, sondern als integraler Bestandteil eines DQ Prozesses verstanden werden.
