3

データベース内の重複する人物レコードを照合するための信頼できる方法を見つけようとしています。データにはいくつかの深刻なデータ品質の問題があり、私も修正しようとしていますが、それを実行できるようになるまで、取得したデータでスタックします。

私が利用できるテーブルの列は次のとおりです。

SURNAME       VARCHAR2(43)
FORENAME      VARCHAR2(38)
BIRTH_DATE    DATE
ADDRESS_LINE1 VARCHAR2(60)
ADDRESS_LINE2 VARCHAR2(60)
ADDRESS_LINE3 VARCHAR2(60)
ADDRESS_LINE4 VARCHAR2(60)
ADDRESS_LINE5 VARCHAR2(60)
POSTCODE      VARCHAR2(15)

このSOUNDEX用途では機能が比較的制限されていますが、UTL_MATCHパッケージはJaroWinkerアルゴリズムを使用してより良いレベルのマッチングを提供しているようです。

車輪の再発明ではなく、このタイプのデータを照合するための信頼できる方法を実装した人はいますか？

対処すべきデータ品質の問題：

  1. 郵便番号は必須ですが、必ずしも完全に入力されているとは限りません。
  2. アドレスデータの品質は比較的低く、アドレスは固定形式で入力されていません（つまり、line1が "Flat 1"である場合と、line1が "Flat1、22 Acacia Ave"である場合があります）。
  3. フォアネーム列には、イニシャル、フルフォアネーム、または複数のフォアネームを含めることができます。

たとえば、私は考えていました：

すべてのアドレスフィールドを連結し、Jaro Winklerアルゴリズムを完全なアドレスに適用し、一緒に連結されたフルネームの同様のテストを組み合わせます。

誕生日を直接比較して一致させることもできますが、大量のデータがあるため、これに一致させるだけでは不十分です。

Oracle 10gR2EnterpriseEdition。

役立つ提案があれば歓迎します。

4

1 に答える 1

7

「データベース内の重複する人物レコードを照合するための信頼できる方法を見つけようとしています。」

残念ながら、そのようなことはありません。あなたが望むことができるのは、合理的な疑いの要素を持つシステムです。

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>

SOUNDEXの大きな利点は、文字列をトークン化することです。これは、インデックスを作成できるものを提供することを意味します。これは、大量のデータに関しては非常に価値があります。一方、それは古くて粗雑です。MetaphoneやDoubleMetaphoneなど、新しいアルゴリズムがあります。Googleを介してそれらのPL/SQL実装を見つけることができるはずです。

スコアリングの利点は、ある程度のあいまいさを許容することです。したがって、すべての行を見つけることができますwhere name_score >= 90%。圧倒的な欠点は、スコアが相対的であるため、インデックスを作成できないことです。この種の比較は、大量の場合にあなたを殺します。

これが意味することは：

  1. さまざまな戦略が必要です。単一のアルゴリズムで問題を解決することはできません。
  2. データクレンジングは便利です。MARXとMRXおよびM4RXのスコアを比較します。名前から数字を削除すると、ヒット率が向上します。
  3. その場で大量の名前を獲得することはできません。可能であれば、トークン化と事前スコアリングを使用してください。チャーンがあまりない場合は、キャッシュを使用します。余裕があれば、パーティショニングを使用してください。
  4. Oracle Text（または同様のもの）を使用して、ニックネームとバリアントのシソーラスを作成します。
  5. Oracle 11gは、OracleTextに特定の名前検索機能を導入しました。詳細をご覧ください。
  6. スコアリング用の正規名のテーブルを作成し、実際のデータレコードをそれにリンクします。
  7. 他のデータ値、特に生年月日などのインデックス可能なデータ値を使用して、大量の名前を事前にフィルタリングしたり、提案された一致の信頼性を高めたりします。
  8. 他のデータ値には独自の問題があることに注意してください。誰かが31/01/11に生まれたのは11か月ですか、それとも80歳ですか。
  9. 特にローマ字化された名前を考慮する必要がある場合は、名前に注意が必要です。MoammarKhadaffi（ローマ字）のスペルには400を超える方法があり、Googleでさえどのバリアントが最も標準的であるかについて合意できません。

私の経験では、トークン（名、姓）を連結することは混合された祝福です。特定の問題（道路名が住所1行目または住所2行目に表示されるかどうかなど）を解決しますが、他の問題を引き起こします：OLIVER vs OLIVER、GRAHAM vs GRAHAM、OLIVER vs GRAHAM、GRAHAM vs OLIVERのスコアリングに対して、GRAHAMOLIVERとOLIVERGRAHAMのスコアリングを検討してください。

何をするにしても、誤検知やヒットの失敗に終わります。タイプミスに対する証拠となるアルゴリズムはありません（ただし、Jaro WinklerはMARXとAMRXでかなりうまくいきました）。

于 2011-11-22T17:42:09.963 に答える