Matchende Oracle duplikatkolonneværdier ved hjælp af Soundex, Jaro Winkler og Edit Distance (UTL_MATCH)

"Jeg forsøger at finde en pålidelig metode til at matche duplikerede personposter i databasen."

Desværre er der ikke sådan noget. Det mest, du kan håbe på, er et system med et rimeligt element af tvivl.

SQL> select n1
       , n2
       , soundex(n1) as sdx_n1
       , soundex(n2) as sdx_n2
       , utl_match.edit_distance_similarity(n1, n2) as ed
       , utl_match.jaro_winkler_similarity(n1, n2) as jw   
from t94
order by n1, n2
/


  2    3    4    5    6    7    8    9  
N1                   N2                   SDX_ SDX_         ED         JW
-------------------- -------------------- ---- ---- ---------- ----------
MARK                 MARKIE               M620 M620         67         93
MARK                 MARKS                M620 M620         80         96
MARK                 MARKUS               M620 M622         67         93
MARKY                MARKIE               M620 M620         67         89
MARSK                MARKS                M620 M620         60         95
MARX                 AMRX                 M620 A562         50         91
MARX                 M4RX                 M620 M620         75         85
MARX                 MARKS                M620 M620         60         84
MARX                 MARSK                M620 M620         60         84
MARX                 MAX                  M620 M200         75         93
MARX                 MRX                  M620 M620         75         92

11 rows selected.

SQL> SQL> SQL> 

Den store fordel ved SOUNDEX er, at den tokeniserer strengen. Det betyder, at det giver dig noget som kan indekseres :dette er utroligt værdifuldt, når det kommer til store mængder data. På den anden side er den gammel og rå. Der findes nyere algoritmer, såsom Metaphone og Double Metaphone. Du burde være i stand til at finde PL/SQL-implementeringer af dem via Google.

Fordelen ved scoring er, at de giver mulighed for en vis grad af uklarhed; så du kan finde alle rækker where name_score >= 90% . Den knusende ulempe er, at scorerne er relative, og du kan derfor ikke indeksere dem. Denne form for sammenligning dræber dig med store mængder.

Hvad dette betyder er:

1. Du har brug for en blanding af strategier. Ingen enkelt algoritme vil løse dit problem.
2. Datarensning er nyttig. Sammenlign resultaterne for MARX vs. MRX og M4RX:Fjernelse af tal fra navne forbedrer hitfrekvensen.
3. Du kan ikke score store mængder af navne på farten. Brug tokenizing og pre-scoring, hvis du kan. Brug caching, hvis du ikke har meget churn. Brug partitionering, hvis du har råd.
4. Brug en Oracle-tekst (eller lignende) til at bygge en synonymordbog af kaldenavne og varianter.
5. Oracle 11g introducerede specifik navnesøgningsfunktionalitet til Oracle Text. Få mere at vide.
6. Byg en tabel med kanoniske navne til scoring og link faktiske dataposter til det.
7. Brug andre dataværdier, især indekserbare værdier som fødselsdato, til at forhåndsfiltrere store mængder af navne eller for at øge tilliden til foreslåede matches.
8. Vær opmærksom på, at andre dataværdier kommer med deres egne problemer:Er nogen født den 31/01/11 elleve måneder gammel eller firs år gammel?
9. Husk, at navne er vanskelige, især når du skal overveje navne, der er blevet romaniseret:der er over fire hundrede forskellige måder at stave Moammar Khadaffi på (i det romerske alfabet) - og ikke engang Google kan blive enige om, hvilken variant der er mest kanoniske.

Efter min erfaring er det en blandet velsignelse at sammenkæde tokens (fornavn, efternavn). Det løser visse problemer (såsom om vejnavnet vises i adresselinje 1 eller adresselinje 2), men forårsager andre problemer:Overvej at score GRAHAM OLIVER vs OLIVER GRAHAM mod scoring OLIVER vs OLIVER, GRAHAM vs GRAHAM, OLIVER vs GRAHAM og GRAHAM vs OLIVER .

Uanset hvad du gør, vil du stadig ende med falske positiver og mistede hits. Ingen algoritme er bevis mod slåfejl (selvom Jaro Winkler klarede sig ret godt med MARX vs AMRX).