2つのテーブルを比較し、%ベースで一致するレコードマッチングソフトウェア[終了]


1

そのため、レコードデータが添付されていない名前、住所、Zipのテーブルがあります。そして、すべて同じテーブルがありますが、より多くの情報があり、100%に一致しない場合にテーブルをマージする方法が必要です。

それらが同一でない場合、どのように一致させますか?私は初心者の@ SQLですが、ほとんどの部分で一致しないことを知っており、この問題を抱えているのは私だけではありません。しかし、これを行うソフトウェアは難しいことが証明されています。

これを行うためのソフトウェアを書くことは、そもそもそれをしなければならないよりも悪いでしょう。

私はこれをExcelでできることを知っています。ちょっとですが、レコードの量が100万を超えるのは難しいことです。


同じ名前、住所など、またはそれらの値のサブセットを持つレコードをカウントしますか?
-soandos

どのフィールドにマッチできますか?SQLのファジーマッチングは優れていません。

はい、基本的には、クライアントから取得した多数のレコードに電話番号を追加します。彼は私にリストを売りに出しましたが、実際にはレコードの半分以上の電話番号を含めませんでした。州には300万の電話番号があります。郵便番号を使用すると精度が自動的に上がり、住所を正規化する(方法が100%わからない)ので、姓と名のあいまい一致がわかります。論理的に私はそれを行う方法を知っています。私は他の誰かが同じ問題があったしなければならないと思うだろう
Crazyd

回答:


5

私は以前、データベースマーケティング会社で働いていました(迷惑メールを送信して申し訳ありません)。「Robert Jones 671 Kimbrough SPFD MO 65802」が「Bobbie Joanes 671 Kimbrough St. Sprinfield MO 65809」と同じかどうかを判断するのが私たちの仕事でした。それは私たちのクライアントが愚かに見えるだけでなく、彼らのお金を無駄にします。

私たちのアプローチは、問題をより小さなドメインに分解し、異なる基準を適用してAである可能性がありますおそらく Bです。マッチングルールが厳しすぎると、重複をキャッチできません。一致する規則が緩すぎると、潜在的な顧客を捨ててしまいます。

エンティティが一致できる3つのドメインがありました:名前、連絡方法、関係。2つのドメインで一致した場合にのみ、一致が許可されました。

連絡方法

連絡方法は、郵便、電子メール、または電話でした。

住所

最初のステップは、提供された住所を標準化することです。最終目標は、入力住所を取得し、USPS標準に修正することです。前の例では、郵便配達人が送信者の意図を理解したという理由だけで、おそらく両方のアドレスにメールが配信されます。実際のアドレスは

671 S KIMBROUGH AVE SPRINGFIELD MO 65806-3342

一貫したアドレスを取得したら、アドレスマッチングを解決するのがはるかに簡単な問題になります。修正不可能なアドレスや、マルチテナントの場所(Suite 200、Apt Bなど)のルールについて心配する必要がありますが、それはビジネスオーナーと連携する必要がある微調整の一部です。ああ、そして+4桁は配送に便利ですが、それらの要素をアドレス照合ロジックに入れないでください。これらは、5桁の郵便番号よりも変更される可能性がはるかに高くなります。

留意すべきもう1つのことは、現在の住所データが重要である場合、過去X時間枠の住所転送情報(NCOA-住所の全国変更)を取得できるように人々が移動することです。移動すると、アドレス転送の書類は一定期間だけ有効であり、そのウィンドウの後にメールを送信したユーザーは、このアドレスのバウンスバックではなく、送信者に戻ります。メールを送信する前にNCOAを実行すると、転送が期限切れになった場合でも、現在のアドレスが確保されます。

私たちのアプローチは、標準化された住所(1行目+郵便番号)からハッシュを作成することで、これを比較キーとして使用します。

電話

電話に関して唯一の注意が必要なことは、電話番号が市外局番に関連付けられているかどうかです。セパレータやフォーマットなしでそれらを保存し、拡張子は個別に保存しました。これは、7桁または10桁の電話番号に要約されました。住所があれば、通常は市外局番を埋め戻すことができるソフトウェアがあります。市外局番が分割されると、通常、2つ(またはそれ以上)の市外局番で場所に対応できる猶予期間があります。

Eメール

一般的に、メールアドレスは一致するか、一致しません。一致させようと必死になったとき、データをクリーンアップしました。これには、ドメインを調べてそれらが存在することを確認し、存在しない場合はトップレベルドメインを追加することが含まれていました。joan @ aolを見た場合、それは@ aol.comを意味する安全な賭けでした googleなどの一部のプロバイダーでは、joan + superuser @ gmail.comをベースアドレスに配信できます。私が登録した特定のサイトにメールアドレスを関連付ける便利な方法だと思います。迷惑メールがそのアカウントに流入し始めたら、誰が噛むことができるかを知っています。ただし、マッチングの目的で、+から@までのコンテンツを破棄できる場合があります

お名前

「名前には何がありますか?他のつづりでジョーンズと呼ぶものは同じ人である可能性があります」

ウィリアム・マッチスピア

Namesを実行するために必要な2つの異なるタイプのマッチングがあることがわかりました。ビジネスまたはエンティティの名前と個人の名前。米国の名前には、接頭辞(Mr、Mrs、Dr、Fr、Sen、Sgtなど)、名、ミドル、2番目のミドルネームまたは父方の姓、姓/母の姓、世代(Jr、Sr、IV )、専門/名誉/学問(MBA、JD、PhD、esqなど)。そんなに面白くないですか?

通常、個々の部分でデータがキャプチャされている限り、それほど悪くはありません。そうでなければ、「de los santos」という姓を持つ私の友人が証明できるように、空白で分割して名前部分を決定できると仮定すると、奇妙な結果を得ることができます。

会社名、まあそれは通常彼らがあなたに与えるものです。知っておくべきことは、DBAを行うビジネスです。「Soulless megacorporation LLC DBA Happy cuddly puppy preserve」「Happy cuddly puppy preserve」や「Soulless Megacorporation」と一致する必要がある場合があります

名前の一致

個人名の一致の最初のパスはsoundexです。これは一般にRDBMSで利用可能であり、入力データに基づいて合格となる場合があります。soundexの問題は、ヨーロッパの名前のサブセットにのみ適していることです。より賢い音声アプローチと私たちが使用した方法は、ダブルメタフォンアルゴリズムでした。これにより、文字列照合の結果が大幅に向上しました。

上記の例では、JonesとJoanesの完全一致は失敗しますが、音声一致はキャッチされます。問題は、ロバートにボビーがいることです。想像力を伸ばすことでこれらの2つの音が同じになることはありませんが、クライアントはマッチが欠けていると主張したため、別のチェックセットを追加してニックネームを完全な値に戻し、比較を再実行しました。

会社名の比較では、「ストップワード」のリストを作成することが有用であることがわかりました。名前には表示されますが、マッチの目的(a、of、the、LLC、corp、univ、University)には無視される意味のないクラフ

その後、「単純な」タイプミス、転置、または文字の省略により、一致しないエンティティが生じるというフィードバックが寄せられました。この回答が長くなるにつれて、「Johns used tire barn」から「Johns mega used tire barn」のようなエンティティで失敗する会社名の一致についてのフィードバックもありました。これらのシナリオに対処するために、N-gram比較とトークン比較アルゴリズムを実装することになりました。それ以来、私は業界の他の人々と話をしてきましたが、彼らは文字列の一致を決定するためにレーベンシュタイン距離を使用することの支持者でした。

関係

関係は基本的に私たちが真実であると知っていた何かです。ある会社では、顧客にビジネス返信カードに記入してもらうことに基づいて営業担当者が気を引き締めるプロモーションを実施しました。「John's used tire barn」という従業員のリストがあり、不完全な名前データをその参照セットに関連付ける必要がありました。完全を期すために、ここでのみ説明します。問題については、名前とMoCの一致を確認します。

すでに完了

実装の詳細は、データの外観と、問題に費やす時間と費用によって異なります。

私の一般的なアプローチは、両方のデータセットをデータベースにインポートすることから始まります。すべての属性を持つデータが参照セットです。データの小さいセットが候補セットです。候補テーブルで、参照セット識別子を含む列を追加します。以下は正規化に欠けていますが、それは意図されています

CREATE TABLE 
    dbo.reference 
(
    reference_id int identity(1,1) NOT NULL PRIMARY KEY
,   name_prfix varchar(50) NULL
,   name_first varchar(50) NOT NULL
,   name_middle varchar(50) NULL
,   name_last varchar(50) NOT NULL
,   name_suffix varchar(20) NULL
,   company_name varchar(100) NULL
,   address_line1 varchar(70) NULL
,   address_line2 varchar(50) NULL
,   address_city varchar(50) NULL
,   address_state varchar(20) NULL
,   address_postalcode varchar(10) NULL
,   address_zip4 char(4) NULL
,   phone_number varchar(10) NULL
)

CREATE TABLE 
    dbo.candidate
(
    candidate_id int identity(1,1) NOT NULL PRIMARY KEY
,   name_prfix varchar(50) NULL
,   name_first varchar(50) NOT NULL
,   name_middle varchar(50) NULL
,   name_last varchar(50) NOT NULL
,   name_suffix varchar(20) NULL
,   company_name varchar(100) NULL
,   address_line1 varchar(70) NULL
,   address_line2 varchar(50) NULL
,   address_city varchar(50) NULL
,   address_state varchar(20) NULL
,   address_postalcode varchar(10) NULL
,   address_zip4 char(4) NULL
,   reference_id int 
)

反復TSQL

ステップ1、直接一致。CandidateとReferenceの間に完全一致が存在する場所はどこでも、Candidate.reference_idに記録し、プロセスから除外されます。

ステップ2、ニックネームの展開および/またはストップワードの置換との直接一致

ステップ3、あいまいな名前の一致と一致するアドレス(二重metaphone + ngram +最小編集距離)

ステップ4、あいまいなニックネームの拡張による住所の一致、および/または単語置換の一致の停止(二重metaphone + ngram +最小編集距離)

ステップ5、手動マッチングのための残りの候補プールを調べる

SSIS

SSISのEnterprise Editionは、ファジーロジック機能を提供します。基本的に、TSQLアプローチでリストされたものとほぼ同じことを行いますが、名前のマッチングなどのために独自のフレームワークをまとめる必要はありません。

SSISの2012リリースでは、住所の整理と名前の部分分けに対処するData Qualityサービスも提供しています。


なんて素晴らしい徹底的な答えであり、あなたが私たちをスパムするためにかなりの時間を費やしたことを私たちに知らせてくれたためです(冗談:))
Dave

1
@DaveRookどういたしまして:D将来の読者がそれを実装できないようにするために、この答えが落とされたことに驚いています。幸いなことに、あなたが動物衛生の専門家、農家、ゴルフ業界の専門家であるか、特定のブランドのタイヤ(タイヤ)を購入していない限り、私はおそらくあなたにスパムを送りませんでした。さらに、あなたは英国にいます。カナダとメキシコの住所を組み込むのに十分な問題がありました。地獄では
決して
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.