sql >> Database >  >> RDS >> Oracle

Overeenkomende Oracle dubbele kolomwaarden met Soundex, Jaro Winkler en Edit Distance (UTL_MATCH)

"Ik probeer een betrouwbare methode te vinden om dubbele persoonsrecords in de database te matchen."

Helaas is er niet zoiets. Het hoogste waarop u kunt hopen, is een systeem met een redelijke mate van twijfel.

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> 

Het grote voordeel van SOUNDEX is dat het de string tokeniseert. Dit betekent dat het je iets geeft dat geïndexeerd kan worden :dit is ongelooflijk waardevol als het gaat om grote hoeveelheden data. Aan de andere kant is het oud en ruw. Er zijn nieuwere algoritmen, zoals Metaphone en Double Metaphone. Je zou PL/SQL-implementaties ervan moeten kunnen vinden via Google.

Het voordeel van scoren is dat ze een zekere mate van vaagheid mogelijk maken; zodat je alle rijen kunt vinden where name_score >= 90% . Het verpletterende nadeel is dat de scores relatief zijn en je ze dus niet kunt indexeren. Van dit soort vergelijking ga je dood met grote volumes.

Wat dit betekent is:

  1. Je hebt een mix van strategieën nodig. Geen enkel algoritme zal uw probleem oplossen.
  2. Gegevens opschonen is handig. Vergelijk de scores voor MARX versus MRX en M4RX:het strippen van nummers uit namen verbetert de hitrate.
  3. Je kunt niet meteen grote hoeveelheden namen scoren. Gebruik tokenizing en pre-scoring als je kunt. Gebruik caching als je niet veel churn hebt. Gebruik partitionering als u het zich kunt veroorloven.
  4. Gebruik een Oracle-tekst (of vergelijkbaar) om een ​​thesaurus van bijnamen en varianten te maken.
  5. Oracle 11g heeft een specifieke zoekfunctie voor namen geïntroduceerd in Oracle Text. Meer informatie.
  6. Bouw een tabel met canonieke namen om te scoren en koppel daar daadwerkelijke gegevensrecords aan.
  7. Gebruik andere gegevenswaarden, vooral indexeerbare waarden zoals geboortedatum, om grote hoeveelheden namen vooraf te filteren of om het vertrouwen in voorgestelde overeenkomsten te vergroten.
  8. Houd er rekening mee dat andere gegevenswaarden hun eigen problemen hebben:is iemand geboren op 31/01/11 elf maanden oud of tachtig jaar oud?
  9. Vergeet niet dat namen lastig zijn, vooral als je namen moet beschouwen die zijn geromaniseerd:er zijn meer dan vierhonderd verschillende manieren om Moammar Khadaffi (in het Romeinse alfabet) te spellen - en zelfs Google kan het niet eens worden over welke variant de meest canoniek.

In mijn ervaring is het aaneenschakelen van de tokens (voornaam, achternaam) een gemengde zegen. Het lost bepaalde problemen op (zoals of de straatnaam voorkomt in adresregel 1 of adresregel 2) maar veroorzaakt andere problemen:overweeg om GRAHAM OLIVER vs OLIVER GRAHAM te scoren tegen OLIVER vs OLIVER, GRAHAM vs GRAHAM, OLIVER vs GRAHAM en GRAHAM vs OLIVER .

Wat je ook doet, je krijgt nog steeds false positives en gemiste hits. Geen enkel algoritme is bestand tegen typefouten (hoewel Jaro Winkler het redelijk goed deed met MARX versus AMRX).




  1. 7 manieren om alle tabellen met externe sleutels in SQL Server te retourneren

  2. Verschil tussen SET autocommit=1 en START TRANSACTION in mysql (Heb ik iets gemist?)

  3. Deel 2 – Een groot databasediagram organiseren?

  4. Een kruistabelquery terug converteren naar een normale query in Access