ファジーマッチFAQ

この質問に対する標準的な答えはありません。 フィールドの照合を検討する それはレコード間で異なっているべきであり、示すことができる 一意のレコード。 たとえば、標準の連絡先データベースでは、名前、住所、電話番号 ユニークな人を識別する必要があります。 多くの人々は、同じ都市を持つことができます 状態なので、これらはあまり意味がないだろう。

複数の使用の間の関係を理解することは重要である フィールドとどのくらいの重要性、または重量は、それぞれに与えられることです 一致プロセスで考慮されているフィールド。 たとえば、Name は重要ではないかもしれません。 アドレスと zip としてので、重みの名前はアドレスと zip よりも小さい アドレスと ZIP が正確であるが、名前がより多くの一致をもたらすことができます は完全に一致するよりも少ない得点しています。

パージモード (すべてのレコードを比較) は、各個人内の一致を検索します。 データセットだけでなく、2つのデータセット間の一致も。 パージモードを使用することができます 1つのデータセットで、データベースの重複を削除したり、除外したりします。 これは、2データベースのマージが実行される前の準備段階です。

Merge (別のソースからのレコードのみが比較されます) 2 つの異なるデータのレコードを比較します。 ソース。 マージの選択 間の一致を見つけるだけ 2つのデータセット。

Mergeモードを使用する前にデータベースを重複除外を行う必要があります。

• マージモードでは、同じソース内の重複レコードは検出されません。
• 一致プロセスは、重複レコードなしではより速くなります。
  データセット1には5つの重複があります。 データセット2には10つあります。 これらの重複をパージせずにマージを実行すると、一致が50個の一致ペアをチェックします。 重複がパージされると、マッチは1つの一致ペアをチェックします。

あいまい一致ツールは、識別子 (ID) を使用して一致にラベルを付けるか、 1つのファイルから別のまたは1つの行から別の単一のファイルにします。 このツールは ID を使用して、どの レコードが一致します。

IDは、ツールからの正確な出力を保証するために、異なるデータセットのレコードを含む各レコードごとにユニークである必要があります。 以下のユニークなIDのベストプラクティスを順守してください：

• 必要な開始をよりよく理解するために、データセットのサイズを把握する 各 RecordID 列の値。
• 両方のデータセットストリームにレコードIDツールを追加します。
• 設定は、"開始 "value" は、すべてのレコードに一意の値が割り当てられていることを確認するために、複数の異なるデータセットをストリームします。

  ベストプラクティス

  初期値として1億を割り当てる マスターファイルの RecordID ツールと2億の初期 顧客ファイルの値。 この実習を一貫して使用することにより、 一致レコードのソースを特定します。

パージモードでは、RecordID1 と RecordID2 のデータが行 データセットの識別子。

マージモードでは、RecordID1 と RecordID2 一致した id、各データセットから1つに対応します。 開始時にレコード id を設定する 異なる大きさの値を使用すると、どのデータセットをより簡単に認識できます。 が参照されています。

レコードID1は、2つのIDが英数字でソートされている場合、常に一致するペアの "最初の" 値です。

ファジーマッチの一致ペアIDは、行ごとに英数字でソートされます。 数値レコードIDフィールドはレコードID1をレコードID2にそれぞれ最小から最大にソートしますが、文字列レコードIDは予期しない方法でソートできます。

レコード101はレコード11と一致します。 フィールドが数値として格納されている場合、レコードID1は11に、またレコードID2は101になります。 フィールドが文字列として格納されている場合、レコードID1は101に、またレコードID2は11になります。

数値レコードIDフィールドに切り替えるか、先頭にレコードIDが付いている文字列がレコード間で標準化された形式を持っていることを確認してください。

ほとんどのアドレス一致シナリオでは、アドレスデータベース データが一貫して設定されている場合、市区町村と都道府県のフィールドは一致する必要はありません。 名前、住所、および郵便番号は、より一般的に使用されるスタイルのオプションと一致します。 データを調べて、都市または州のフィールドが適切かどうかを判断します。

次の場合はダブル Metaphone を使用します。

• 都市と州のフィールドは省略形ではありません。
• フィールドにスペルが含まれている エラー。  

フィールド全体またはフィールド全体の大文字小文字を区別しない場合:

• 州のフィールドは省略形であり、完全一致が必要です。

  より粒度が細い一致のプロセスに移行する場合は、通常、完全一致が必要です。

多くのアドレス一致シナリオでは、スイートのフィールドはマッチングでは必要ありません。 名前、住所、および郵便番号は、より一般的に使用されるスタイルのオプションと一致します。 データを調べて、スイートのフィールドが適切かどうかを判断します。

ダブル Metaphone w/数字は、任意のアドレスの優先マッチスタイルです。 アドレスにスイート番号が含まれているかどうかに関係なく、フィールド。 また、プリプロセスの下で、ストリップ句読点を使用し、米国の住所オプションから単位を削除することも検討し ます。

ほとんどの場合、name フィールドを個々のコンポーネントフィールドに解析する必要はありません。 、より良い試合になることはありません。 を使用して生成 name フィールドキーを生成するための Soundex アルゴリズムを使用して、各単語オプションのキー。 これにより、語順 考慮されていないので、両方の "シンディスミス" または "スミス、 シンディは "マッチと見なされます。

名前フィールドの解析は、必要なときに有利です。 それぞれの値に異なる重みを付けることができます。

編集中... >前処理では、ストリップ句読点 & 礼拝を使用して、マッチの実行中にこれらの単語を無視します。