ファジーマッチFAQ

この質問に対する標準的な答えはありません。レコード間で異なる必要があり、そのレコードがユニークである可能性があることを示すマッチングフィールドを考慮します。例えば、標準の連絡先データベースでは、名前、アドレス、電話番号でユニークな人物を識別する必要があります。多くの人が同じ都市と州を持つことができるので、これらが持つ意味は小さくなります。

複数のフィールドを使用することと、マッチングプロセスで考慮する各フィールドにどれだけの重要度や重みを与えるかの関係を理解することは重要です。例えば、名前はアドレスやZIPほど重要でないかもしれないので、名前にアドレスとZIPより小さい重みを付けると、アドレスとZIPが正確である場合により多くの一致が得られる可能性がありますが、名前は正確な一致よりも低くスコアリングされています。

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

[ マージする値を検索] では、 2 つの異なるデータソース ( ソース ID が異なる行 ) の行を比較します。マージを選択すると、2つのデータセット間の一致のみが検出されます。

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

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

ファジーマッチツールは、識別子（ID）を使用して、1つのファイルから別のファイルに、または1つのファイル内の1つの行から別の行に一致をラベル付けします。ツールはIDを使用して、どのレコードが一致するかを報告します。

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

• 各レコードID列の必要な開始値をよりよく理解するために、データセットのサイズを把握します。
• 両方のデータセットストリームにレコードIDツールを追加します。
• 異なるデータセットストリームの "開始値" を互いにいくつか大きさを変えて設定して、すべてのレコードにユニークな値が割り当てられていることを確認します。

  例

  マスターファイルのレコードIDツールの初期値として100000000を、顧客ファイルの初期値として200000000を割り当てます。このプラクティスを一貫して使用すると、一致レコードのソースを簡単に特定できます。

パージモードでは、レコードID1とレコードID2のデータは、データセットの行識別子です。

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

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

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

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

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

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

以下の場合、ダブルメタフォンを使用します：

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

以下の場合、フィールド全体またはフィールド全体 - 大文字と小文字を区別しない を使用します：

• 州のフィールドは省略形であり、完全一致が必要です。より粒度が細い一致のプロセスに移行する場合は、通常、完全一致が必要です。

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

数字付きダブルメタフォンは、アドレスにスイート番号が含まれているかどうかに関わらず、任意のアドレスフィールドの好ましい一致スタイルです。また、前処理の下の句読点を取り除き、米国のアドレスからユニットを削除するオプションの使用も考慮してください。

ほとんどの場合、名前フィールドを個々のコンポーネントフィールドに解析する必要はないので、より良い一致が得られることはありません。各単語のキーを生成するオプションをSoundexアルゴリズムとともに使用して、名前フィールドキーを生成します。これは、単語の順序が考慮されないので "Cindy Smith" または "Smith, Cindy" の両方が一致と見なされることを確実にします。

名前フィールドを解析すると、各値に異なる重みを付けるときに便利です。Rosey SmithがR Smithと一致するために、ラストネームは80％で重み付けされ、ファーストネームは20％で重み付けされます。

> 前処理の下で、 句読点と挨拶を取り除くを使用して、一致を実行している間はこれらの単語を無視します。

Designer Cloud では、ワークフローの XML でカスタム一致スタイルを選択すると、そのスタイルが自動的に適用されます。デスクトップの Designer とは異なり、 [ 保存] を選択する必要はありません。