題がある。アプリケーション数がnの場合の変換テーブル数(N1)は以下の式で表される。
N1=n(n-1)/2 ------(1)
これに対して、共通番号を介してn個のアプリケーションの個人情報をリンクする場合の変換テーブル数N2は以下のように表される。
N2=n ------(2)
上記の(1)と(2)から、nが4以上になると統一個人コードによる変換テーブル数が少なくなり、統一個人コードの方が適切であることになる。これは、全体で見た場合のテーブル数の比較であるが、個々のアプリケーションにとって見れば、対住民基本台帳コードの変換テーブルを1つ用意すればよいのであり、共通番号によらないで変換をする場合は、n個のテーブルが必要になることになる。以上から、住民基本台帳コードのような共通番号を介して変換テーブルを作成することが適切であることが明らかである。
(2) 変換テーブルの自動作成
住民基本台帳コードのような共通番号を介して変換テーブルを作成する場合、数百万、アプリケーションによっては数千万人の個人コードの対応表を作成しなければならないこととなる。この作業をマニュアルで実行することは膨大な労力を要することとなる。1つのアプリケーションの個人コードと住民基本台帳コードの変換テーブルを作成する現実的な方法として、以下のような手順が考えられる。
?@ 当該アプリケーションと、住民基本台帳の個人情報から共通するデータ項目を摘出する。
?A 共通項目で名寄せを行ない、変換テーブルを自動的に作成するシステムを開発する。例えば、住民基本台帳と年金の場合ならば、氏名、生年月日で名寄せを行ない、合致した者について、両方のコードを変換テーブルに記載する。
?B 上記の名寄せではマッチしなかった者についてのみ、手作業で対応付けを行ない、手入力で変換テーブルに追加する。
以上のような変換テーブルが完成すれば、住民基本台帳ネットワークシステムから、変更データが伝送された場合、住民基本台帳コードとアプリケーションのコードが自動