ブログ

公開日：2022/12/28

前回、検出した重複データにグループコードを振る方法について書きましたが、最後は仕上げの名寄せのお話で締めたいと思います。データ統合のルールや仕様については運用によって様々ですのでここでは深入りしませんが、必要な情報を余すことなく網羅できるようにまとめるのところまでは名寄せの仕事となります。

前回の例としてあげたサンプルにグループコードとステータス（前回参照）を振ると下のようになります。

A1　鈴木一郎　A県B市C町1-1-1-101　033-3333-3333　A1　st1
A2　鈴木一郎　A県B市C町1-1-1-101　090-4444-4444　A1　st1
B3　鈴木一郎　A県B市C町1-1-1　　　033-3333-3333　A1　st3
C4　鈴木一郎　D県E市F町2-2-2　　　090-4444-4444　A1　st4

結論としてこれら4レコードは同じグループコード「A1」としてリンクキーが振られました。前回グループコードを「A1」としたのは、単に昇順先頭というだけのことで、A1のレコードが最も正しい情報、という意味ではありません。住所はA1とA2が正しそうですが、A1・A2にはなくてB3やC4にだけ存在する情報があるかもしれません。
データテーブルA・B・Cはそれぞれ違う成り立ちで出来上がったデータであり、仮にテーブルCは総じて古くC4の登録日もかなり昔のものでA2の登録日が一番最近であったとします。連絡先としてはA2の情報が参照されるべき候補となりますが、C4にはファーストコンタクトの履歴が情報が残されています。
何を正とするかについては情報の性質にもよります。時間軸によって変わるものと不変のものがあります。例えば住所情報は時間軸に左右されますが、生年月日は決して変わることはありません。このように時間によって変わる可能性のある情報は登録日などのタイムスタンプを優先順位（降順）とし、不変のものについては情報が存在するものを正とするのことで情報を網羅することができます。ただし、もしB3の登録日が最新だった場合、情報量の少ない（号室がない）住所情報を正とするのか、という悩ましい問題もあります。号室の有無についての比較・判定はやや複雑になりますが、表記から判断できる住所情報の正確さに予め順位（ステータスなど）をつけておいて高い方を優先とする考え方を組み合わせる手もあります。
今回は生年月日をマッチング条件に入れませんでしたが、個人を判定する重要な付帯情報ですので、例えばA1とC4に違う生年月日が入っていた場合、C4を同じグループとして扱う場合には更に下位のステータスを付け（もしくはグループから外す）、情報をすくい上げるレコードとしては扱わない方がいいかもしれません。
電話番号については、マッチングのために固定・携帯を混在させていますが、固定と携帯は別々の項目に分けてそれぞれをカバーし合うのがよいかもしれません。ただし、固定電話は居住地の局番に紐づいていますので、更新にあたっては注意する必要があります。

話が分散気味になってしましました。名寄せは目的によって条件が変わってしまうため一つの正解というのはありません。情報の渦に飲み込まれないためには、まずは目的を明確にしておき、あまり欲張らずに情報を整理する必要があります。可能であれば軸となるテーブルが設定できると分かりやすくなります。軸となる情報があると優先順位がつけやすく、多少条件が複雑化しても原点に帰ることができます。

最後に名寄せにおいて人間の判断とプログラムに任せる部分の分かれ目について触れておきます。確実に人間の判断と確認が必要なのは、目的とルールの設定です。そのためにある程度データを整理し、その傾向を知っておく必要があります。傾向を探るためのマッチング用のデータクレンジングはプログラムが得意とするところです。弊社の製品だと住所はAddress-Catch、氏名や電話番号の文字整理についてはName-Catch（の一部機能）で対応可能です。重複データの検出もName-Catchが利用できますが、ここから先は名寄せの目的によって条件が様々となるため、データベースに取り込み直して決めて行かなければなりません。その作業工程を考え決断するのは人間の仕事です。
ある程度最後の工程まで面倒を見てくれる名寄せプログラムはあり、その中で大変優秀なソフトウェアも存在します。ただ、弊社では名寄せとはこれまでご説明してきたとおり、データベースの数だけ正解があると考えており、また、どうしてもアイチェックが欠かせない領域もあり、その判断基準については利用目的による、としか言えません。そのために長々と回りくどい文を書き連ねてきましたが、ご理解いただいた上でご相談をいただけますと幸いです。

（終）