JP6664201B2 - 突合処理装置及び突合処理方法並びに突合処理プログラム - Google Patents

Description

本発明は、複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理装置及び突合処理方法並びに突合処理プログラムに関する。

従来、複数のデータベース（例えば、データベースＡ及びデータベースＢ）のそれぞれに含まれている複数のレコードを突合した場合、突合状態を区分するコードを各レコードへ付与することによって突合結果を得ている。なお、本明細書におけるレコードとは、データベース内に格納されているデータのかたまりであって、例えば住所情報などのような固有の情報を示すデータのかたまりを指している。また、本明細書における突合とは、複数のデータベースのそれぞれのレコードに含まれているデータの一部又は全部が一致するか否かを調べるために、データベース同士（あるいは、データベースの各レコード同士）を照合することである。

従来の突合処理では、例えば、データベースＡ内のレコードとデータベースＢ内のレコードが一致した場合や何らかの関連付けが得られた場合には、そのレコードに対して一致したレコードであることを示すコード『１』を付与し、レコードが不一致となった場合には不一致のレコードであることを示すコード『−１』を付与するなど、単純なコードによってレコードの一致／不一致の識別を行っている。

また、従来技術として、下記の特許文献１〜３に開示されている技術が存在する。特許文献１には、文字列階層データ（住所名など）や符号文字列データ（郵便番号など）が記憶された複数のデータベースを合成して、ツリー構造を持つ合成データベースを作成する技術が開示されている。特許文献１の開示技術によれば、文字列階層データは住所名などの階層構造を持つデータであり、文字列階層データを階層単位（ノード単位）で比較することで一致／不一致を判定する。

また、特許文献２には、住所コードデータベース（数字の配列で表される住所情報を含む）と、住所データベース（地名情報を含む）とをマージ（統合）して、マージデータベースを作成する技術が開示されている。特許文献２の開示技術によれば、データベースのマージを行う際、住所（町村名の部分）を右端から１文字ずつ削除して検索し、ヒットした箇所の文字列までコード化されていると判断して記憶する。この際、コード化されている箇所を識別するために、例えば記号『／』を挿入する。

また、特許文献３には、ユーザにより入力された検索住所文字列に基づいて、住所データベースの中から該当する住所データを検索する技術が開示されている。特許文献３の開示技術によれば、ユーザの入力した検索住所文字列に該当する住所が存在しない場合は、１つ以上の住所がヒットするまで、検索住所文字列を後方から所定量（例えば、住所表記単位）ずつ削除して検索を繰り返す。

特開２０１０−１３４８２８号公報（要約書、段落［０１１６］、図１、図３０、図３１、図３４） 特開２００３−１６７９１２号公報（要約書、段落［００２８］、図６） 特開２００３−１８６８８０号公報（要約書）

従来技術では、各レコードにおける一致／不一致の状況の識別（例えば、上述したコード『１』、『−１』の付与）や、不一致となった各レコードについて修正すべき箇所の特定及び修正（例えば、上述した特許文献１、２の開示技術）を試みている。しかしながら、各レコードについて修正すべき箇所が特定されたとしても、適切な修正値を見つけ出すことは容易ではない。また、不一致となったレコードが特定されたとしても、不一致となった要因がどこにあり、データベース内のレコード全体において同様の理由で不一致となったレコードがどのくらい生じているのかなどを把握できなければ、不一致となったレコードを効率良くかつ適切に修正することは困難である。

また、特許文献１〜３の開示技術では、主に、住所情報などの文字列情報を前方から検索する前方検索手法、又は、後方から検索する後方検索手法が用いられている。しかしながら、このような前方検索手法又は後方検索手法は、例えば比較すべきデータベースの各レコード間に複数の差異（複数の不一致となる箇所）が存在する場合、これらの差異が生じている複数の箇所を効率的かつ正確に検出できない可能性がある。

上記の問題点を考慮して、本発明は、複数のデータベースのそれぞれに含まれている複数のレコードを突合し、相互のレコードにおいて一致／不一致が生じている箇所を含む突合結果を出力することで、データベース同士の各レコードの一致／不一致の状況を明確に示すことができる突合処理装置及び突合処理方法並びに突合処理プログラムを提供することを目的とする。

上記の目的を達成するため、本発明の突合処理装置は、文字列情報を含む複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理装置であって、
前記文字列情報について所定の規則に従って複数の分節を設定する分節設定部と、
前記複数のデータベースのうちの第１データベース内のレコードに含まれる文字列情報と、前記複数のデータベースのうちの第２データベース内のレコードに含まれる文字列情報とを比較して、相互に対応する分節内の文字列情報の一致又は不一致を検出するレコード比較部と、
比較したすべての分節において共通の文字列情報を含むレコードが前記第１及び第２データベースの両方に存在する場合には、前記比較したすべての分節において共通の文字列情報を含むことを示す情報を、前記比較したすべての分節において共通の文字列情報を含む前記第１及び第２データベース内のレコードのそれぞれに関連付ける突合結果生成部とを、
有する。

また、上記の目的を達成するため、本発明の突合処理方法は、文字列情報を含む複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理装置であって、
前記文字列情報について所定の規則に従って複数の分節を設定する分節設定ステップと、
前記複数のデータベースのうちの第１データベース内のレコードに含まれる文字列情報と、前記複数のデータベースのうちの第２データベース内のレコードに含まれる文字列情報とを比較して、相互に対応する分節内の文字列情報の一致又は不一致を検出するレコード比較ステップと、
比較したすべての分節において共通の文字列情報を含むレコードが前記第１及び第２データベースの両方に存在する場合には、前記比較したすべての分節において共通の文字列情報を含むことを示す情報を、前記比較したすべての分節において共通の文字列情報を含む前記第１及び第２データベース内のレコードのそれぞれに関連付ける突合結果生成ステップとを、
有する。

また、上記の目的を達成するため、本発明の突合処理プログラムは、文字列情報を含む複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理方法をコンピュータにより実行させるための突合処理プログラムであって、
前記文字列情報について所定の規則に従って複数の分節を設定する分節設定ステップと、
前記複数のデータベースのうちの第１データベース内のレコードに含まれる文字列情報と、前記複数のデータベースのうちの第２データベース内のレコードに含まれる文字列情報とを比較して、相互に対応する分節内の文字列情報の一致又は不一致を検出するレコード比較ステップと、
比較したすべての分節において共通の文字列情報を含むレコードが前記第１及び第２データベースの両方に存在する場合には、前記比較したすべての分節において共通の文字列情報を含むことを示す情報を、前記比較したすべての分節において共通の文字列情報を含む前記第１及び第２データベース内のレコードのそれぞれに関連付ける突合結果生成ステップとを、
有する突合処理方法をコンピュータにより実行させるための突合処理プログラムである。

本発明は、上記の構成又は処理を有しており、複数のデータベースのそれぞれに含まれている複数のレコードを突合し、相互のレコードにおいて一致／不一致が生じている箇所を含む突合結果を出力することで、データベース同士の各レコードの一致／不一致の状況を明確に示すことができるという効果を有する。また、本発明は、データベース同士の各レコードの一致／不一致の状況を定量的に示すことで、この一致／不一致の状況の内訳を確認できるようにするという効果を有する。さらに、本発明は、不一致となったレコードについて、データベース間の不整合を解決するための作業を迅速に進めることができるようにするという効果を有する。

また、本発明は、特に、住所情報を含む台帳データベースと、地図などを表す画像情報に関連付けられて同じく住所情報を含む地図データベースとの突合処理に適用された場合において著しい効果を有する。住所情報を含む複数のデータベースにおいては、特に、国土における地番などに不整合が生じているという課題があり、こうした不整合の解決作業を的確かつ迅速に行うことが、行政や土地開発上の課題となっていた。本発明は、土地台帳と住所の突合検討において、本発明の実施の形態において説明するような一致／不一致の状況を明確に示すコード体系を用いて、適切なキー項目の値を迅速に見つけ出すことを可能とし、不突合となった要因を知ることができるという効果を有する。

本発明の実施の形態に共通する突合処理装置の構成の一例を示すブロック図である。 本発明の実施の形態に共通する突合処理の概要を示すフローチャートである。 本発明の実施の形態に共通する突合処理における事前設定処理の一例を示すフローチャートである。 本発明の実施の形態に共通する突合処理における突合コード設定処理の一例を示すフローチャートである。 本発明の実施の形態における突合処理を説明するために用いられるデータベースＡ及びＢの一例を示す図である。 本発明の実施の形態における突合処理の処理過程におけるデータベースＡ及びＢの第１の状態の一例を示す図である。 本発明の実施の形態において、文字列情報に対して３つの分節が設定された場合のフィルタの一例、及び、フィルタに対応して設定されている突合コードの一例を模式的に示す図である。 本発明の実施の形態において、文字列情報に対して４つの分節が設定された場合のフィルタの一例、及び、フィルタに対応して設定されている突合コードの一例を模式的に示す図である。 本発明の実施の形態において、文字列情報に対して５つの分節が設定された場合のフィルタの一例、及び、フィルタに対応して設定されている突合コードの一例を模式的に示す図である。 本発明の実施の形態における突合処理の処理過程におけるデータベースＡ及びＢの第２の状態の一例を示す図である。 本発明の実施の形態における突合処理の処理過程におけるデータベースＡ及びＢの第３の状態の一例を示す図である。 本発明の実施の形態における突合処理において得られる最終的な突合結果を含むデータベースＡ及びＢの状態の一例を示す図である。 図８に示す状態において、突合コードが、レコード数を示す情報を有するようさらに拡張された場合の一例を示す図である。 本発明の実施の形態において、最終的な突合結果から特定の突合コード『１１＿』が設定されたレコードのみを抽出した状態の一例を示す図である。 本発明の実施の形態に係る実施例において、最終的な突合結果から特定の突合コード『１１＿１１』が設定されたレコードのみを抽出した状態の一例を示す図である。 本発明の実施の形態に係る実施例において、最終的な突合結果から特定の突合コード『１１＿１＿』が設定されたレコードのみを抽出した状態の一例を示す図である。 本発明の実施の形態に係る実施例において、最終的な突合結果から特定の突合コード『１１１＿１』が設定されたレコードのみを抽出した状態の一例を示す図である。 図１１のテーブルの４番目のレコードに係る住所情報を、地図データベースに基づく地図上に重ね合わせて表示画面上に表示した状態の一例を示す図である。 本発明の実施の形態に係る実施例において、最終的な突合結果から特定の突合コード『１１１１１：１１』が設定されたレコードのみを抽出した状態であり、さらに「面積」フィールドが表示された状態の一例を示す図である。 本発明に係る突合処理によって２つのデータベース（台帳データベース及び地図データベース）で１対１に対応していると判断されたレコードについて、当該対応していると判断された各レコードの共通の項目（「面積」フィールド）の値を用いて作成された散布図の一例を示す図である。

以下、図面を参照しながら、本発明の実施の形態について説明する。

図１は、本発明の実施の形態に共通する突合処理装置の構成の一例を示すブロック図である。図１に図示されている突合処理装置１０は、データベース読み取り部１１、突合処理部１２を有している。また、突合処理装置１０には、複数のデータベースが記憶された記憶媒体２０、操作入力部３０、表示部４０が接続されている。

データベース読み取り部１１は、記憶媒体２０に記憶されている複数のデータベース（図１のデータベースＡ及びＢ）を読み取る機能を有している。突合処理装置１０によって読み取られたデータベースは、突合処理部１２が処理を行うために、例えば突合処理装置１０内の主記憶装置（メインメモリ、図１には不図示）などに一時的に記憶される。

突合処理部１２は、データベース読み取り部１１によって読み取られた複数のデータベース（図１のデータベースＡ及びＢ）内の各レコードの突合処理を行う機能を有しており、レコード比較部１３、突合結果生成部１４、突合結果出力部１５を備えている。

レコード比較部１３は、複数のデータベース（図１のデータベースＡ及びＢ）のそれぞれの各レコードに含まれる文字列情報を相互に比較して、文字列情報の一致又は不一致を検出する突合処理を行う機能を有している。また、レコード比較部１３は分節設定部１６を有している。分節設定部１６は、所定の分節構造に係る規則に従って各レコードに含まれる文字列情報を分節化し、文字列情報に対して複数の分節を設定する機能を有している。なお、文字列情報の分節化とは、文字列情報を区分けして複数の部分（各部分は少なくとも１文字以上を含む）に分けることであり、本明細書では、区分けされた部分を分節と呼ぶ。文字列情報の分節化によって、文字列情報に対して、例えば後述する図４に示されているように複数の分節が設定される。

突合結果生成部１４は、レコード比較部１３による比較結果に基づいて、複数のデータベース（図１のデータベースＡ及びＢ）のそれぞれの各レコードに関する突合結果を生成する機能を有している。突合結果生成部１４は、複数のデータベース（図１のデータベースＡ及びＢ）のそれぞれの各レコードの突合結果を、例えば後述する突合コード（突合結果を統合したコード情報）として生成することが可能である。突合結果出力部１５は、突合結果生成部１４によって生成された突合結果を出力して、データベース内のデータとして記録させたり表示部４０に表示させたりする機能を有している。

また、記憶媒体２０は、データベースを記憶する機能を有しており、例えば、ハードディスク、光記録媒体、磁気記録媒体、不揮発性メモリなどにより実現可能である。なお、記憶媒体２０は、ネットワークなどを介して突合処理装置１０がアクセス可能な場所に配置されていてもよい。なお、図１には複数のデータベースとして２つのデータベース（データベースＡ及びＢ）が同一の記憶媒体２０に記憶されている状態が図示されているが、複数のデータベースはそれぞれ異なる記憶媒体２０に記憶されていてもよい。以下では、２つのデータベースにおける突合処理が行われる場合について主に説明するが、３つ以上のデータベースにおける突合処理が行われてもよい。

記憶媒体２０に記憶されているデータベースはデータの集合体であり、文字列情報を含む複数のデータを有している。データベースに含まれているデータは、例えば、所定の格納形式（例えば、表形式）に基づいて、レコード単位でデータベースに格納されている。なお、各レコードに含まれる文字列情報は任意の種類の情報であり、例えば市町村、大字、小字、地番、枝番などの階層構造を有する住所情報などが含まれ得る。また、複数のデータベースに含まれるレコード数は同一であってもよく、あるいは異なっていてもよい。

また、操作入力部３０は、突合処理装置１０におけるユーザ操作を可能とする機能を有しており、例えばマウスやキーボードなどの入力インタフェースにより実現可能である。操作入力部３０を用いることで、ユーザは、突合処理装置１０に読み取らせるデータベースの指定、突合処理における設定、突合処理の開始指示、表示部４０における情報の表示指示などを始めとした様々な設定及び指示を突合処理装置１０に入力することが可能である。

また、表示部４０は、複数のデータベースのそれぞれに格納されているデータや突合処理部１２によって生成された突合結果などを、ユーザが視認可能な情報として提供する機能を有しており、例えばモニタ又はディスプレイなどによって実現可能である。また、操作入力部３０及び表示部４０は、操作入力機能と表示機能が一体化されたタッチパネルなどによって実現されてもよい。

なお、図１では、突合処理装置１０の各機能がブロックによって模式的に図示されているが、これらのブロックで表されている各機能は、例えば、ハードウェア又はＣＰＵ（Central Processing Unit：中央処理装置）がソフトウェア（プログラム）を実行することによって実現可能である。突合処理装置１０は、例えば汎用ＰＣ（Personal Computer：パーソナルコンピュータ）によって実現可能であり、突合処理装置１０における各処理は、本発明の実施の形態における各処理（例えば、後述の図２Ａ〜２Ｃに示すフローチャートに含まれる各処理）の実行命令が記述されたプログラムをＣＰＵが実行することで実現可能である。

また、図１には不図示であるが、汎用ＰＣで実現される突合処理装置１０は、データやプログラムなどを一時的に記憶する主記憶装置（メインメモリ）を備えており、例えば、データベース読み込み部１１によって読み込まれたデータベース内のデータ、処理中に変更又は生成されたデータ、ＣＰＵで実行すべきプログラムなどを主記憶装置に一時的に記憶しながら、本発明の実施の形態における処理を行うことが可能である。

次に、図２Ａ〜２Ｃを参照しながら、本発明の実施の形態における突合処理について説明する。図２Ａは本発明の実施の形態に共通する突合処理の概要を示すフローチャート、図２Ｂは本発明の実施の形態に共通する突合処理における事前設定処理（図２Ａに示すステップＳ１００の事前設定処理）の一例を示すフローチャート、図２Ｃは本発明の実施の形態に共通する突合処理における突合コード設定処理（図２Ａに示すステップＳ２００の突合コード設定処理）の一例を示すフローチャートである。なお、図２Ａ〜２Ｃに示すフローチャートの各処理は、図１に図示されている突合処理装置１０により実行される。以下では、本発明に対する理解が容易となるよう、突合処理を行う対象とする２つのデータベースＡ及びＢの各レコードに、図３に示す文字列情報が含まれている場合を一例に挙げながら説明する

図２Ａに示すように、本発明の実施の形態における突合処理は、事前設定処理（ステップＳ１００）と、突合コード設定処理（ステップＳ２００）とに大別される。ステップＳ１００の事前設定処理では、後続の突合コード設定処理において使用されるパラメータなどの設定が行われる。また、ステップＳ２００の突合コード設定処理では、実際に突合処理の対象となる複数のデータベース（例えば、データベースＡ及びＢ）内のレコードを比較し、各レコードに対して突合結果を示す情報（例えば、突合コード）を付与する処理が行われる。

事前設定処理では、図２Ｂに示すように、突合処理装置１０は、記憶媒体２０に記憶されている２つのデータベースＡ及びＢを読み出し、これらのデータベースＡ及びＢに含まれている各レコードの突合コード欄を初期化するとともに（例えば、初期値として『０』を設定）、各レコードに対して共通の分節構造を設定し、さらに、その分節構造に応じたフィルタを設定する（ステップＳ１０１）。なお、設定された分節構造及びフィルタに関する情報は、後続の処理で用いるために突合処理装置１０によって保持される。

ステップＳ１０１で設定される分節構造は、各レコードに含まれる文字列情報を所定の文字数ごとに分節化した構造であり、文字列情報に対して分節構造を設定することで、文字列情報が複数の分節によって構成されているとみなすことができるようになる。例えば、図４に示すように、データベースＡ及びＢの各レコード（１０桁の文字列情報を含む）に対して、上位４桁（左から１桁目〜４桁目）の文字列を含む分節Ｓ１、中位３桁（左から５桁目〜７桁目）の文字列を含む分節Ｓ２、下位３桁（左から８桁目〜１０桁目）の文字列を含む分節Ｓ３の３つの分節を設定することが可能である。

なお、ステップＳ１０１では、データベースＡ及びＢの各レコードに含まれる文字列情報の長さ（文字数）や、後続の突合コード設定処理において比較する文字列情報の位置などに応じて、任意の分節構造を設定することが可能である。例えば、図４の例では、文字列情報に対して３つの分節を設定するとともに、各分節の長さを左から順に４桁、３桁、３桁となるよう設定しているが、分節の個数及び長さは任意に設定可能である。また、図４の例では、文字列情報全体を包含するように（すなわち、各分節の長さの総和が文字列情報全体の長さと等しくなるように）分節を設定しているが、文字列情報の一部（端部又は途中を除いた一部）のみに対して分節を設定してもよい。また、ステップＳ１０１において設定される分節構造として、文字列情報に対してあらかじめ設定されている分節構造を利用してもよい。例えば、文字列情報として住所情報が含まれている場合には、市町村、大字、小字、地番、枝番などの階層を各分節として設定することが可能である。

また、ステップＳ１０１において設定されるフィルタは、設定された分節構造に含まれる各分節のうち、後続の突合コード設定処理においてどの分節の組み合わせを比較対象とするかを設定するためのものである。例えば、図４の例のように文字列情報に対して３つの分節が設定された場合、その分節構造に対応するフィルタとして、３つの分節の組み合わせを比較対象とするよう設定することが可能である。

図５Ａは、図４の例のように文字列情報に対して３つの分節が設定された場合のフィルタの一例、及び、フィルタに対応して設定されている突合コードの一例を模式的に示す図である。図５Ａの縦方向の配列（行）は各フィルタの識別情報（ＬＶＬ＝１〜７）を表し、図５Ａの横方向の配列（列）は各フィルタが用いられた場合に比較対象とする分節（Ｓ１〜Ｓ３）を表している。

図５Ａに模式的に示されているフィルタは、後続の突合コード設定処理においてレコードの検索が行われる際（後述する図２ＣのステップＳ２０７の処理）に用いられる。各フィルタ内の『比較』と記載されている分節は、データベースＡ及びＢの各レコードに関して共通の文字列情報が存在するかどうかの判断が行われることを表す。一方、ハッチングが施された分節は、共通の文字列情報に関する判断が行われないことを表す。具体的には、例えばＬＶＬ＝１のフィルタは、すべての分節Ｓ１〜Ｓ３において『比較』と記載されている。したがって、ＬＶＬ＝１のフィルタを用いた場合には、すべての分節Ｓ１〜Ｓ３（この例では１０桁の文字列情報全体）において共通の文字列情報が存在するかどうかの判断が行われる。また、例えばＬＶＬ＝２のフィルタは、分節Ｓ３にはハッチングが施されており、分節Ｓ１及びＳ２において『比較』と記載されている。したがって、ＬＶＬ＝２のフィルタを用いた場合には、分節Ｓ１及びＳ２の両方において共通の文字列情報が存在するかどうかの判断が行われる一方、分節Ｓ３については判断が行われない。

また、図５Ａには、各フィルタを用いて共通の文字列情報を検出した場合に、レコードに設定される突合コードが示されている。この突合コードは分節の個数に等しい桁数を有しており、突合コードの各桁と各分節の位置とが対応している。例えば、図５Ａに示す例では、文字列情報は３つの分節に区切られており、各分節に対応して突合コードも３桁に設定されている。

突合コードは、各フィルタに固有のコードである。突合コードの各桁は分節Ｓ１〜Ｓ３のそれぞれに対応しており、共通の文字列情報が存在するかどうかの判断が行われる分節（図５Ａの『比較』と記載されている分節）に対応する桁には、値『１』が設定されている。また、共通の文字列情報が存在するかどうかの判断が行われない分節（図５Ａのハッチングが施された分節）に対応する桁には、『＿』（アンダーバー）が設定されている。

また、突合コードは、対応するフィルタを用いて共通の文字列情報が存在するかどうかの判断が行われた結果、フィルタに設定されているすべての分節で共通の文字列情報を持つレコードがデータベースＡ及びＢの両方に存在している場合、これらのレコードに対して設定される。例えば突合コード『１１１』が設定されたレコードは、分節Ｓ１〜Ｓ３のすべてで共通の文字列情報を持つレコードがデータベースＡ及びＢの両方に存在していると判断されたものであることを表している。また、例えば突合コード『＿１１』が設定されたレコードは、分節Ｓ２及びＳ３で共通の文字列情報を持つレコードがデータベースＡ及びＢの両方に存在していると判断されたものであることを表している。したがって、あるレコードに設定されている突合コードを参照すれば、そのレコードが、データベースＡ及びＢの両方に共通のレコードであって、当該共通のレコードがどの分節で共通の文字列情報を持っているかを把握することが可能となる。

また、図５Ｂ及び図５Ｃは、文字列情報に対して４つの分節及び５つの分節がそれぞれ設定された場合のフィルタの一例、及び、一致した場合に設定される突合コードの一例を模式的に示す図である。フィルタの個数（すなわち、ＬＶＬの数に相当）は、分節構造の分節の個数をＮとした場合、最大２^Ｎ−１個（Ｎ＝３の場合は最大７個、Ｎ＝４の場合は最大１５個、Ｎ＝５の場合は最大３１個）となる。ただし、必ずしもすべてのフィルタを用いる必要はない。また、後述する突合コード設定処理では、最初にＬＶＬ＝１のフィルタを使用し、続いてＬＶＬの値をインクリメントしながら、ＬＶＬ＝２のフィルタ、ＬＶＬ＝３のフィルタ、・・・を順次使用する。どのような分節の組み合わせを有するフィルタをどのＬＶＬに設定するかは任意に変更可能であるが、比較対象とする分節の個数がより多いフィルタ（すなわち、図５Ａ〜図５Ｃにおいて『比較』と記載された箇所がより多いフィルタ）を用いた突合コード設定処理が優先的に実行されるようにすることが望ましい。

なお、上述した図５Ａ〜図５Ｃは、本発明に係るフィルタのセットの概念を説明するために模式的に示されたものであり、当業者であれば、このようなフィルタのセットを実体的なデータとして準備する必要はなく、文字列情報に含まれる適切な分節を比較対象としたり、比較対象から除外したりするなどの処理を適宜実行することによって実現可能であることは明らかである。

さらに事前準備処理において、突合処理装置１０は、後続の突合コード設定処理において最初に用いるフィルタ（初期フィルタ）を変数ＬＶＬとして設定する（ステップＳ１０３）。ステップＳ１０３では任意のフィルタの設定が可能であるが、例えば、図５Ａのフィルタのセットにおいて比較対象とする分節の個数が最も多いＬＶＬ＝１のフィルタを初期フィルタとして設定することが望ましい。また、初期フィルタの設定と共に、突合コード設定処理において用いるフィルタや、最後の処理に用いる最終フィルタなどをユーザが設定できるようにしてもよい。なお、ユーザが明示的に最終フィルタを設定せず、自動的に、すべてのフィルタを用いた処理（すなわち、すべての分節の組み合わせを比較する処理）が行われるように設定されてもよい。

上述の事前設定処理においてパラメータなどの設定が完了した後、突合コード設定処理では、図２Ｃに示すように、突合処理装置１０は、データベースＡ及びＢのそれぞれにおいて、現在設定されているフィルタ（ここでは初期フィルタ）によって規定されている分節内の各レコードの文字列情報を参照して、同一の文字列情報を含むレコード数を算出し、そのレコード数の最大値を抽出する（ステップＳ２０１）。例えば、初期フィルタとして図５ＡのＬＶＬ＝１のフィルタ（分節Ｓ１〜Ｓ３を含むフィルタ）が設定されている場合、図４に示すデータベースＡの例では、分節Ｓ１〜Ｓ３において同一の文字列情報を含むレコードはレコードＮｏ．５、６のレコード（同一のレコード数＝２）であり、すなわち、レコード数の最大値は２となる。また同様に、図４に示すデータベースＢの例では、分節Ｓ１〜Ｓ３において同一の文字列情報を含むレコードはレコードＮｏ．４〜６のレコード（同一のレコード数＝３）であり、レコード数の最大値は３となる。データベースＡのレコード数の最大値は値ｖＡＭＡＸに設定され、データベースＢのレコード数の最大値は値ｖＢＭＡＸに設定される。これらの値ｖＡＭＡＸ及びｖＢＭＡＸは、後述するループ処理のループ回数として利用される。なお、後述するループ処理においては、そのループ回数をそれぞれのデータベースＡ及びＢのレコードの総数とした場合であっても適切に処理が行われるが、事前に、レコード数の最大値である値ｖＡＭＡＸ及びｖＢＭＡＸをループ回数として設定することで、ループ処理に要する処理時間を低減させることが可能となる。

以上のように、初期フィルタ及び最終フィルタ、データベースＡ及びＢのそれぞれのレコード数の最大値（ループ回数の値ｖＡＭＡＸ及びｖＢＭＡＸ）の設定が完了すると、突合処理装置１０は、データベースＡ及びＢの各レコードの突合処理を行うことが可能となる。突合処理装置１０は、例えば、まずデータベースＡ内の同一レコード数（変数Ａ１）を１に設定するとともに（ステップＳ２０３）、データベースＢ内の同一レコード数（変数Ｂ１）を１に設定して（ステップＳ２０５）、これらの条件に合ったレコードをデータベースＡ及びＢのそれぞれから抽出し、共通するレコード（すなわち、同一の文字列情報によって構成されているレコード）を検索する（ステップＳ２０７）。なお、ステップＳ２０７において、共通の文字列情報を持つ共通のレコードが検出されなかった場合には、突合コードを設定すべきレコードは存在しないと判断し（ステップＳ２０９）、ステップＳ２１１及びＳ２１３の処理は実行されない。

図４に示すデータベースＡ及びＢの例を参照すると、データベースＡ内に含まれている同一レコード数が１のレコードはレコードＮｏ．１〜４、７、８のレコードであり、データベースＢ内に含まれている同一レコード数が１のレコードはレコードＮｏ．１〜３、７、８のレコードである。これらのレコードを比較することで、突合処理装置１０は、データベースＡ内のレコードＮｏ．２のレコードとデータベースＢ内のレコードＮｏ．２のレコードとが、分節Ｓ１〜Ｓ３において共通の文字列情報『１２３５７９２３８４』を持つ共通のレコードであることを検出する。

そして、突合処理装置１０は、データベースＡ及びＢで共通するこれらのレコードに対し、現在設定されているフィルタ（ここでは初期フィルタ）に対応する突合コードを設定する（ステップＳ２１１）。突合コードは、例えば図５Ａに示す突合コードのように、比較対象とした分節の位置（すなわち、共通の文字列情報が検出された分節の位置）を示す突合コードを用いることが望ましいが、他の様々な方法によって表現することが可能である。このようにして得られた突合コードは、対応するレコードの突合コード欄に書き込まれ（ステップＳ２１３）、その結果、例えば図５Ａに示す突合コードを用いた場合、データベースＡ内のレコードＮｏ．２のレコードとデータベースＢ内のレコードＮｏ．２のレコードに対しては、突合コード『１１１』が設定される。

突合処理装置１０は、変数Ａ１＝１、変数Ｂ１＝１の検索を終了すると、続いて変数Ｂ１が値ｖＢＭＡＸに等しいか否かを判断し（ステップＳ２１５）、変数Ｂ１が値ｖＢＭＡＸに達していない場合には、変数Ｂ１を１だけ増加（インクリメント）して（ステップＳ２１７）、ステップＳ２０７以降の処理を再び行う。また、ステップＳ２１５で変数Ｂ１が値ｖＢＭＡＸに達したと判断した場合には、変数Ａ１が値ｖＡＭＡＸに等しいか否かを判断し（ステップＳ２１９）、変数Ａ１が値ｖＡＭＡＸに達していない場合には、変数Ａ１をインクリメントして（ステップＳ２２１）、ステップＳ２０５以降の処理を再び行う。このように、ステップＳ２０３〜Ｓ２２１の処理により、設定されているフィルタ（ここでは、初期フィルタとして設定されているＬＶＬ＝１のフィルタ）に対して、１からｖＡＭＡＸまでの範囲にある変数Ａ１と、１からｖＢＭＡＸまでの範囲に存在する変数Ｂ１との各組み合わせにおいて、データベースＡとデータベースＢとの間に共通するレコードが存在するか否かが検索され、共通するレコードに対しては、そのレコードの突合コード欄に突合コードが設定される。

この一連の処理によって、図４のデータベースＡ及びＢの例では、データベースＡ内のレコードＮｏ．２のレコードとデータベースＢ内のレコードＮｏ．２のレコードにおける突合コードの設定に加え、データベースＡ内のレコードＮｏ．５、６のレコードとデータベースＢ内のレコードＮｏ．４〜６のレコードに対して突合コード『１１１』が設定される（変数Ａ１＝２、変数Ｂ１＝３の条件で得られる）。この結果、例えばデータベースＡ及びＢは、図６に示す状態となる。

変数Ａ１がｖＡＭＡＸに達し変数Ｂ１がｖＢＭＡＸに達して、すべての同一レコード数についての処理が終了すると、突合処理装置１０は、フィルタの識別情報（変数ＬＶＬ）が最終フィルタに等しいか否かを判断し（ステップＳ２２３）、変数ＬＶＬが最終フィルタに達していない場合には、フィルタを変更（例えば、変数ＬＶＬをインクリメント）して（ステップＳ２２５）、ステップＳ２０１以降の処理を再び行う。例えば、ＬＶＬ＝１をインクリメントしてＬＶＬ＝２とした場合、図５Ａに示すフィルタのセットの例では、突合コード『１１＿』に対応するＬＶＬ＝２のフィルタを用いて、ステップＳ２０１以降の処理が再び行われることになる。

変数ＬＶＬをインクリメントしてレベル２（変数ＬＶＬ＝２）とした場合に実行されるステップＳ２０１以降の処理、さらに変数ＬＶＬを上げた状態で実行されるステップＳ２０１以降の処理では、既に突合コード欄に突合コードが設定されているレコードについては、ステップＳ２０７における検索処理において検索対象から除外する。すなわち、処理の過程でレコードに突合コードがいったん設定された場合、そのレコードの突合コードは変更されないよう制御される。

このようにフィルタを変更しながら突合コードの設定を行うことで、ＬＶＬ＝１のフィルタを用いて得られた突合コードが設定された状態（図６のデータベースＡ及びＢに示す状態）から、さらにＬＶＬ＝２のフィルタを用いた際に、データベースＡ内のレコードＮｏ．７のレコードとデータベースＢ内のレコードＮｏ．７、８のレコードに対して突合コード『１１＿』が設定され（変数ＬＶＬ＝２、変数Ａ１＝１、変数Ｂ１＝２の条件で得られる）、ＬＶＬ＝３のフィルタを用いた際に、データベースＡ内のレコードＮｏ．４のレコードとデータベースＢ内のレコードＮｏ．３のレコードに対して突合コード『１＿１』が設定され（変数ＬＶＬ＝３、変数Ａ１＝１、変数Ｂ１＝１の条件で得られる）、ＬＶＬ＝５のフィルタを用いた際に、データベースＡ内のレコードＮｏ．１のレコードとデータベースＢ内のレコードＮｏ．１のレコードに対して突合コード『１＿＿』が設定され（変数ＬＶＬ＝５、変数Ａ１＝１、変数Ｂ１＝１の条件で得られる）、ＬＶＬ＝６のフィルタを用いた際に、データベースＡ内のレコードＮｏ．３のレコードとデータベースＢ内のレコードＮｏ．９のレコードに対して突合コード『＿１＿』が設定される（変数ＬＶＬ＝６、変数Ａ１＝１、変数Ｂ１＝１の条件で得られる）。この結果、例えばデータベースＡ及びＢは、図７に示す状態となる。

そして、初期フィルタ（例えば図５ＡのＬＶＬ＝１のフィルタ）から最終フィルタ（例えば図５Ａのレベル７のフィルタ）までの突合処理が終了すると、突合処理装置１０は、突合コード欄が初期値『０』のまま残っているレコードについて、どのレベルにおいても一致する文字列情報が検索されなかったことを示す突合コード（完全不一致コードと呼ぶ）を設定する（ステップＳ２２７）。完全不一致コードは、例えば『９９９』などのようにすることが可能であるが、その他の任意の文字列又は記号としてもよく、あるいは初期値『０』をそのまま残しておいてもよい（この場合、完全不一致コードは『０』）。この結果、例えばデータベースＡ及びＢは図８に示す状態となり、これによって突合処理は完了する。

なお、データベースＡ及びＢの各レコードへの突合コードは、最初に読み出された元のデータベースＡ及びＢ内に設定されてもよく、あるいは、元のデータベースＡ及びＢを複製した新たなデータベース内に設定されてもよい。さらに、元のデータベースＡ及びＢを複製して新たなデータベースを作成する場合、これらのデータベースＡ及びＢの内容を統合した１つの統合データベースを作成し、その中の各レコードに突合コードが設定されてもよい。

図８に示すようにデータベースＡ及びＢの各レコードに設定された突合コードは、データベースＡ及びＢ内のそれぞれに含まれる文字列情報に関して、どの分節において共通する文字列情報が存在しているのか（突合コードの値『１』の位置）を表しており、突合コードから一致／不一致の状況を容易に読み取ることができるようになっている。

また、さらに突合コードを拡張して、データベースＡ内に共通の文字列情報を有するレコード数が何個存在しており、データベースＢ内に共通の文字列情報を有するレコード数が何個存在しているのかを把握できるようにしてもよい。例えば、上述の例において、データベースＡ内の２個のレコードＮｏ．５、６と、データベースＢ内の３個のレコードＮｏ．４〜６は、突合コード『１１１』で表されているように分節Ｓ１〜Ｓ３において共通の文字列情報を有している。この突合コード『１１１』に対して、データベースＡ及びＢ内のそれぞれにおける個数が分かるように付加し（例えば、データベースＡのレコード数、データベース内のレコード数の順に並べる）、突合コードを『１１１：２３』などのように表してもよい。また、このように拡張された突合コードによって、ユーザは、データベースＡ及びＢ内の共通する文字列情報を持つレコード数を容易に把握できるようになる。

また、データベース内に共通の文字列情報を有する複数のレコード（２個以上のレコード）が存在している場合、上述のようにレコード数を示すのではなく、単に複数存在していることを示すだけでもよい。例えば、データベース内に共通の文字列情報を有するレコード数が１個のみ存在しているレコードについては値『１』で表し、レコード数が２個以上存在しているレコードについては、たとえ３個以上のレコードが存在する場合であっても値『２』で表すようにしてもよい。これによって、２つのデータベースに存在するレコード数の関係が１対１の場合には『１１』、１対多の場合には『１２』又は『２１』、多対多の場合には『２２』などのように表すことが可能となる。２つのデータベースに存在するレコード数の関係が１対１、１対多、多対多のいずれであるかを把握できるようにするだけでも十分に有用である。

例えば、上述の例における突合コード『１１１：２３』は、『１１１：２２』（末尾の『２２』は、データベースＡ内に２個以上のレコード、データベースＢ内に２個以上のレコードが存在していることを示す）と表される。上記のように、データベース内に共通の文字列情報を有するレコード数が２個以上存在しているレコードについて、値『２』で表す突合コードを設定した一例を図９に示す。なお、図９では、桁数を合わせるために完全不一致コードは『９９９：９９』と設定されている。

また、突合処理装置１０は、各レコードに突合データが設定されたデータベースＡ及びＢの中から、特定の突合コードが設定されているレコードのみを抽出して、そのレコードのみを表示画面上に表示したり、そのレコードのみを含むデータベースを新たに作成及び保存したりしてもよい。例えば図９に示すように単数又は複数のレコード数の識別情報が付加された突合コードが設定されたデータベースＡ及びＢの例において、突合処理装置１０がユーザ入力や他の装置又はプログラムから特定の突合コード『１１＿』の出力指示を受けた場合には、図１０に示すように、データベースＡ内のレコードＮｏ．７のレコードとデータベースＢ内のレコードＮｏ．７、８のレコードとを抽出し、それぞれのレコードが存在するデータベースの識別子を付与した状態で表示してもよい。異なるデータベースＡ及びＢにおいて同一の突合コードが設定されたレコードは相互に関連している可能性が高く、このように１つの表示画面にまとめて表示することで、ユーザがレコードの一致／不一致の状況を容易に把握できるようになり、不一致となったレコードの修正を行う際の作業効率を向上させることが可能となる。

なお、図２Ａ〜２Ｃに示すフローチャートを拡張することで、３つ以上のデータベースにおける突合処理を行う場合にも対応可能であることは明らかである。例えばデータベースＡ及びＢに加えて、さらにデータベースＣを含む３つのデータベースにおける突合処理を行う場合には、ステップＳ２０１においてデータベースＣのレコードの最大値ｖＣＭＡＸを抽出し、データベースＣ内のレコード数の変数Ｃ１を１からｖＣＭＡＸまでインクリメントしながら、ステップＳ２０７においてデータベースＡ、Ｂ及びＣで共通するレコードを検索できるようなループ処理を実行することによって、各データベース内のレコード同士の組み合わせを漏れなく比較できるようにすることが望ましい。なお、３つ以上のデータベースにおける突合処理を行った場合も上記の突合コードをそのまま使用することができる。また、レコード数を示す情報を突合コードに付加する場合には、データベース数に応じて桁数を増やせばよく、例えば、突合コード『１１１：１２１』（末尾の３桁は３つのデータベースのそれぞれに存在するレコード数に対応）などのようにすればよい。

＜実施例＞
本発明に係る突合処理装置１０は、２つのデータベース間の差異を発見することができる。こうした差異は、例えば、本来は同一の情報を持つべき２つのデータベースの一方に含まれているタイプミスやＯＣＲ（Optical Character Recognition：光学文字認識）による読み取りのミスや、データベース管理者やデータ更新時期の違いによって生じたものである。

また、本発明に係る突合処理装置１０が処理対象とするデータベースの各レコードに含まれている文字列情報は、例えば、数字のみによって構成されていてもよく、あるいは、漢字、仮名、アルファベット、記号などによって構成されていてもよい。さらに、本発明では、文字列情報に対して分節構造を設定することを前提としているが、この分節構造の設定においては、住所情報などのように元から階層的に設定されている階層構造を利用してもよく、あるいは、突合処理装置１０のユーザが独自の方法で文字列情報を分節化してもよい。

また、本発明に係る突合処理装置１０が処理対象とするデータベースの種類は特に限定されるものではない。例えば、住所情報を含むデータベース、ネットワークアドレス情報やドメイン情報を含むデータベース、マイナンバーなどの個人情報を含むデータベース、顧客管理情報を含むデータベース、財務会計情報を含むデータベース、商品の在庫情報を含むデータベースなどを始めとした様々な種類のデータベースを処理対象とすることが可能である。

以下では、住所情報を含む台帳データベースと、地図などを表す画像情報に関連付けられて同じく住所情報を含む地図データベースを用意し、本発明の実施の形態における突合処理装置１０によって実際に突合処理を行った実施例について説明する。

この実施例において用意された台帳データベース及び地図データベースには、同一地域の住所情報が同一の格納形式で格納されている。ただし、それぞれのデータベースの管理者及び更新時期などが異なっており、相互のデータベースにおける各レコードは完全には一致していない。また、それぞれのデータベースにおいてレコードの追加や削除が行われた結果、レコード数が異なっていることも考えられる。

各レコードには、階層構造を有する住所情報が文字列情報として格納されている。なお、文字列情報は２３桁の数字の配列であり、最初の３桁は市町村、次の８桁は大字、次の４桁は小字、次の５桁は地番、最後の３桁は枝番にそれぞれ対応している。例えば、文字列情報『３２２０００００００４００５８０００８４００５』は、最初の『３２２』が市町村、次の『０００００００４』が大字、次の『００５８』が小字、次の『０００８４』が地番、最後の『００５』が枝番を表している。本実施例における突合処理では、この住所情報が持つ階層構造に基づいて、市町村、大字、小字、地番、枝番の５つの分節を設定し、図５Ｃに模式的に示されているフィルタのセットを用いている。

本発明の実施の形態における突合処理装置１０により、上記の条件下で実際に突合処理を行った結果を図１１〜図１３に示す。図１１〜図１３には、ユーザによって指定された突合コードが設定されているレコードのみを台帳データベース及び地図データベースのそれぞれから抽出し、表形式で表示画面上に表示した状態が示されている。これらの表示状態は、上述した図１０の表示状態に相当するものである。

図１１〜図１３のフィールド『種別』の値『１』は台帳データベース内のレコードであることを表し、値『２』は地図データベース内のレコードであることを表している。また、図１１〜図１３のフィールド『市町村』、『大字』、『小字』、『地番』、『枝番』は各レコードの文字列情報に設定された各分節（住所情報の各階層）を含み、フィールド『ＣＯＤＥ』は突合コードを含んでいる。なお、文字列情報である住所情報は５つの分節が設定されており、突合コードも各分節に対応した５桁の数字（さらに、台帳データベースのレコード数と地図データベースのレコード数も付加されている）を含んでいる。

図１１には、突合コード『１１＿１１』が設定されているレコードを抽出して表示画面上に表示した状態が図示されている。例えば、図１１のテーブルの１番目及び２番目のレコードは、それぞれ台帳データベース及び地図データベース内のレコードであり、これらのレコードは対応関係を有している。図１１のテーブルの１番目及び２番目のレコードは、突合コード『１１＿１１』が示すとおり、「市町村」、「大字」、「地番」、「枝番」に共通した文字列情報が含まれている一方、「小字」は異なっている。また、突合コードの末尾に付加された『１１』が示すとおり、図１１のテーブルの１番目及び２番目のレコードは、台帳データベース及び地図データベースにおいて１対１に対応している。

また、図１２には、突合コード『１１＿１＿』が設定されているレコードを抽出して表示画面上に表示した状態が図示されている。例えば、図１２のテーブルの１番目及び２番目のレコードは、それぞれ地図データベース及び台帳データベース内のレコードであり、これらのレコードは対応関係を有している。図１２のテーブルの１番目及び２番目のレコードは、突合コード『１１＿１＿』が示すとおり、「市町村」、「大字」、「地番」に共通した文字列情報が含まれている一方、「小字」、「枝番」は異なっている。また、突合コードの末尾に付加された『１１』が示すとおり、図１１のテーブルの１番目及び２番目のレコードは、台帳データベース及び地図データベースにおいて１対１に対応している。

また、図１３には、突合コード『１１１＿１』が設定されているレコードを抽出して表示画面上に表示した状態が図示されている。例えば、図１３のテーブルの１番目及び３番目のレコードは、それぞれ地図データベース及び台帳データベース内のレコードであり、これらのレコードは対応関係を有している。図１３のテーブルの１番目及び３番目のレコードは、突合コード『１１１＿１』が示すとおり、「市町村」、「大字」、「小字」、「枝番」に共通した文字列情報が含まれている一方、「地番」は異なっている。また、突合コードの末尾に付加された『１１』が示すとおり、図１３のテーブルの１番目及び３番目のレコードは、台帳データベース及び地図データベースにおいて１対１に対応している。

なお、地図データベース内の住所情報が地図を表示するための画像情報と関連付けられていることを利用して、地図データベース内に格納されている情報に基づいて作成及び表示された地図を参照することで、本発明に係る突合結果の確認及び修正を行ってもよい。

例えば、図１１のテーブルの３番目及び４番目のレコードは、それぞれ地図データベース及び台帳データベース内のレコードであり、これらのレコードは対応関係を有している。具体的には、図１１のテーブルの３番目及び４番目のレコードは突合コード『１１＿１１：１１』が示すとおり、１対１に対応するレコードであり、「市町村」、「大字」、「地番」、「枝番」に共通した文字列情報が含まれている一方、「小字」のみ異なっている。より詳細には、図１１のテーブルの３番目のレコード（地図データベース内のレコード）は「小字」の値が『０１７０』であるのに対し、４番目のレコード（台帳データベース内のレコード）は「小字」の値が『０１７２』である点でのみ異なっている。上記の突合結果から、図１１のテーブルの３番目及び４番目のレコードのどちらか一方において、「小字」の値に誤りがあることが推測できるが、『０１７０』及び『０１７２』のどちらの値が誤っているかを特定することは容易ではない。

このような場合、地図データベース内の情報を用いて、突合結果の確認対象となる位置を含む地図を表示部４０の表示画面に表示することで、この地図を参照したユーザは、台帳データベース又は地図データベースのどちらのレコードの値が誤っているかを容易に推測することが可能となる。

図１４には、地図データベース内に格納されている情報に基づいて、図１１のテーブルの３番目のレコード（地図データベース内のレコード）に係る住所周辺の地図を表示画面上に表示した状態が図示されている。地図データベース内の各レコード（住所情報を含む）は、地図上の特定の住所を含む区画を表しており、図１４では、各区画を示す画像と共に、対応する住所（文字列）が表示されている。例えば、図１１のテーブルの３番目のレコードは、図１４の地図内の区画Ａに対応しており、当該３番目のレコードに含まれる住所を表す文字列『０１７２ ０００３２−０００』がこの区画Ａ上に重畳表示されている。

また、図１４の地図では、「小字」の値が『０１７０』の区画と『０１７２』の区画の双方が表示されており、『０１７０』の区画が視覚的に強調されるよう着色表示されている。なお、図１４の例では、『０１７０』の区画にハッチングが施されているが、このハッチングが特定色の着色を表している。なお、『０１７２』の区画についても同様に、着色表示が行われてもよい（ただし、『０１７０』の区画とは異なる色であることが望ましい）。

この地図を参照したユーザは、その周辺の区画との着色の違いから、「小字」が『０１７２』の領域内に、「小字」が『０１７０』に設定された区画Ａが孤立しており、飛び地の状態になっていることを視覚的に把握することができる。その結果、ユーザは、区画Ａに設定されている「小字」の値『０１７０』（地図データベース内のレコードの値）は誤りであり、突合処理で得られた１対１に対応する台帳データベース内のレコードに含まれる「小字」の値『０１７２』が正しい値である可能性が高いと推測でき、図１１のテーブルの３番目のレコードの「小字」の値を『０１７０』から『０１７２』に変更すべきであると判断することができる。

なお、ここでは、突合処理の結果を参照して地図データベースと台帳データベースとの間で不整合が生じているレコードを得た後に、地図データベース内の情報に基づいて表示される地図を用いて当該不整合の確認を行う態様を示したが、異なる態様として、地図データベース内の情報に基づいて表示される地図を参照して視覚的に違和感を覚える区画（例えば、飛び地など）を特定した後に、突合処理の結果を参照して、当該区画に対応する台帳データベースのレコードの確認を行うようにしてもよい。また、地図データベース内の情報に基づいて表示される地図上に、突合処理によって得られた情報（例えば、突合コードや、１対１に対応する台帳データベースのレコードに含まれる文字列情報など）を重ね合わせて表示してもよい。

また、図１１〜図１３に示すテーブルには、突合処理によって得られた突合結果を表示する際に、ユーザによるレコードの比較を容易とする特徴が含まれている。以下、突合処理を行った結果を表示するテーブルにおいて、ユーザの視認性及び利便性を向上させるための特徴について説明する。

図１１〜図１３のテーブルは、例えば『市町村』、『大字』、『小字』フィールドなどを基準としたソート表示を行うという特徴を有している。この特徴により、共通の文字列情報を持つレコードが隣接した行に表示され、共通の文字列情報を持つレコード同士を比較する際におけるユーザの視認性を向上させることが可能となる。なお、異なるデータベース内のレコードが隣接した行に表示されるため、テーブル全体では、台帳データベース内のレコード（『種別』＝『１』）と、地図データベース内のレコード（『種別』＝『２』）が入れ子になって表示されるという特徴がある。

また、図１１〜図１３のテーブルは、比較した２つのデータベース（台帳データベース及び地図データベース）のそれぞれのレコード内の文字列情報を異なるフィールドに表示するという特徴を有する。具体的には、各レコードの地番及び枝番が、そのレコードが台帳データベース内のレコードである場合には、台帳データベースの『地番』及び『枝番』フィールドに表示され、地図データベース内のレコードである場合には、地図データベースの『地番』及び『枝番』フィールドに表示されるようにする。このように、台帳データベースのレコードに含まれる文字列情報を表示するフィールドと、地図データベースのレコードに含まれる文字列情報を表示するフィールドとをそれぞれ分けることによって、ユーザは、各レコードが台帳データベース及び地図データベースのどちらに含まれているものであるかを即座に判断できるようになる。

また、本発明に係る突合処理の結果として、データベースＡとデータベースＢとにおいて完全に一致し、かつ、１対１に対応しているレコード（すなわち、上述の例において、突合コード『１１１：１１』や『１１１１１：１１』が設定されるレコード）が得られた場合であっても、その突合結果が必ずしも正しいと言えないこともある。そこで、このように１対１に対応していると判断されたレコードに関して、さらに、この突合結果が正しいかどうかを定量的に検証できるようにしてもよい。

１対１に対応していると判断されたレコードに関する突合結果を確認する場合、例えば、比較した２つのデータベース（台帳データベース及び地図データベース）のそれぞれのレコード内に含まれている共通の項目を利用することが可能である。以下、図１５及び図１６を参照しながら説明する。

図１５には、突合コード『１１１１１：１１』が設定されている６個のレコード（（以下、上から順に第１〜第６レコードと呼ぶ））を抽出して表示画面上に表示した状態が図示されている。ただし、図１５のテーブルには、各レコードに含まれている『面積』フィールドが設定されている。この『面積』フィールドは、台帳データベース及び地図データベース内のそれぞれのレコードに設定されており、『面積』フィールドには、各レコードに格納された住所情報に関連する土地の面積（地図面積）が格納されている。台帳データベース及び地図データベースにおいて１対１に対応しているレコードであるならば、共通の項目である『面積』フィールドの数値（土地面積）も等しいはずである。この関係を利用して、台帳データベース及び地図データベースにおいて１対１に対応していると判断されたレコードについて、さらに『面積』フィールド内の数値を比較し、両者が一致している場合には１対１の突合結果は正しいと判断することによって、突合結果の検証を行うことが可能である。

なお、共通の項目に含まれる情報が等しいか否かを判断する際、例えば数値の差が所定の範囲（例えば、数パーセント）内に収まる場合には、共通の項目に含まれる情報は実質的に等しい（すなわち、１対１の突合結果は正しい）と判断してもよい。この所定の範囲は、ユーザが自由に設定することが可能である。

図１５に図示されている第１〜第６レコードのうち、第１及び第２レコードは『市町村』、『大字』、『小字』、『地番』、『枝番』のすべてにおいて共通の文字列情報『２０６０００２１００００００３５６００１』を含み、第３及び第４レコードは『市町村』、『大字』、『小字』、『地番』、『枝番』のすべてにおいて共通の文字列情報『２０６０００２１００００００３５６００２』を含み、第５及び第６レコードは『市町村』、『大字』、『小字』、『地番』、『枝番』のすべてにおいて共通の文字列情報『２０６０００２１００００００３５６００３』を含む。また、第１、第３及び第６レコードは台帳データベース内のレコードであり、第２、第４及び第５レコードは地図データベース内のレコードである。また、図１５のテーブルでは、『市町村』、『大字』、『小字』、『地番』、『枝番』のすべてにおいて共通の文字列情報を持つレコードが隣接した行に表示されている。

上述のように、図１５のテーブルには、各レコードの『面積』フィールドが表示されている。例えば、第１及び第２レコードは突合処理において１対１に対応していると判断されたレコードであるが、第１レコードの『面積』フィールド及び第２レコードの『面積』フィールドの数値は共に『９４６』で等しいことから、第１及び第２レコードが１対１に対応しているという突合結果は正しいと判断することができる。また、第３レコードの『面積』フィールドの数値は『１４７０』、第４レコードの「面積」フィールドの数値は『１４５２』であり、両方の数値はほぼ等しいことから、第３及び第４レコードが１対１に対応しているという突合結果は正しいと判断することができる。また、第５レコードの『面積』フィールドの数値は『１６０３』、第６レコードの『面積』フィールドの数値は『８１０』であり、両方の数値は大きく異なることから、第５及び第６レコードが１対１に対応しているという突合結果は誤りであると判断することができる。

なお、上記では、例えば第３レコードの『面積』フィールドの数値『１４７０』と、第４レコードの「面積」フィールドの数値『１４５２』とがほぼ等しいと判断しているが、この判断は、ユーザが自由に設定可能な判断基準に依存する。例えば、両方の数値の差（ここでは『１８』）がどちらか一方の数値又は両方の数値の平均値の５パーセント以内であれば、両方の数値は実質的に等しいと判断する場合には、第３及び第４レコードが１対１に対応しているという突合結果は正しいと判断される。一方、例えば、両方の数値の差（ここでは『１８』）がどちらか一方の数値又は両方の数値の平均値の１パーセント以内であれば、両方の数値は実質的に等しいと判断する場合には、第３及び第４レコードが１対１に対応しているという突合結果は誤りであると判断される。

なお、１対１に対応していると判断されたレコードに対して上記の検証を行い、その検証結果を各レコードに設定してもよい。例えば、１対１に対応しているという突合結果が誤りであると判断されたレコードにフラグを設定したり、テーブルで表示する際にレコードの色を変えて強調表示したりすることが可能である。

また、図１６に示すように、『面積』フィールドの数値をプロットした散布図を作成し、突合結果が正しいかどうかをユーザが視覚的に判別できるようにしてもよい。図１６には、１対１に対応していると判断された２つのレコードの『面積』フィールドの数値をＸ座標（横軸）及びＹ座標（縦軸）とした点が多数プロットされている。１対１に対応していると判断された２つのレコードの『面積』フィールドの数値がほぼ等しい場合には、プロットされた点は、Ｙ＝Ｘの直線上又はこの直線に近い位置に配置される。したがって、Ｙ＝Ｘの直線から大きく離れた位置にプロットされた点は、誤った突合結果を表しているとみなすことができる。

なお、図１６に示すような散布図において、例えば、ユーザが設定した判断基準を示す直線を表示してもよく、当該判断基準を超えて突合結果が誤りであると判断される点の色を変えて強調表示してもよい。

なお、上述の例では、台帳データベース内のレコードと地図データベース内のレコードに共通の項目として『面積』フィールドを利用する場合について説明したが、比較する複数のデータベース内のレコードに設定されている共通の項目であれば、その他の項目を用いてもよい。台帳データベース及び地図データベースの例では、土地の面積のほかに、例えば、その土地で栽培されている作物、その土地の用途を表す地目、その土地の周囲長、などを始めとして、様々な項目を利用することが可能である。また、ここでは台帳データベース及び地図データベースの例を挙げて説明しているが、他の任意の種類のデータデータベースにおいても同様に、比較するデータベース内のレコードに設定されている共通の項目を適宜選択することが可能である。

本発明は、複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う技術に適用可能である。また、本発明は、任意の種類のデータが格納されたデータベースを処理対象とすることが可能であり、データベース管理技術全般に適用可能である。

１０ 突合処理装置
１１ データベース読み取り部
１２ 突合処理部
１３ レコード比較部
１４ 突合結果生成部
１５ 突合結果出力部
１６ 分節設定部
２０ 記憶媒体
３０ 操作入力部
４０ 表示部

Claims (10)

1. 文字列情報を含む複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理装置であって、
   前記文字列情報について所定の規則に従って複数の分節を設定する分節設定部と、
   前記複数のデータベースのうちの第１データベース内のレコードに含まれる文字列情報と、前記複数のデータベースのうちの第２データベース内のレコードに含まれる文字列情報とを比較して、相互に対応する分節内の文字列情報の一致又は不一致を検出するレコード比較部と、
   比較したすべての分節において共通の文字列情報を含むレコードが前記第１及び第２データベースの両方に存在する場合には、前記比較したすべての分節において共通の文字列情報を含むことを示す情報を、前記比較したすべての分節において共通の文字列情報を含む前記第１及び第２データベース内のレコードのそれぞれに関連付ける突合結果生成部とを、
   有する突合処理装置。
2. 前記レコード比較部は、前記複数の分節の中から、前記文字列情報の一致又は不一致の比較対象とする１つ又は複数の分節を選択するよう構成されている請求項１に記載の突合処理装置。
3. 前記レコード比較部は、最初に所定数の複数の分節を選択して、前記所定数の複数の分節内の文字列情報の一致又は不一致の検出を行い、その後、前記文字列情報の一致又は不一致の比較対象とする分節の個数を前記所定数から段階的に少なくしながら前記文字列情報の一致又は不一致の検出を行うよう構成されている請求項２に記載の突合処理装置。
4. 前記レコード比較部は、前記第１及び第２データベース内のレコードのうち、前記相互に対応する分節内の文字列情報の一致が既に検出されているレコードを比較対象から除外するよう構成されている請求項２又は３に記載の突合処理装置。
5. 前記突合結果生成部は、前記複数の分節のうちのどの分節が前記共通の文字列情報を含む前記比較したすべての分節に対応するかを示すコード情報を生成するよう構成されている請求項１から４のいずれか１つに記載の突合処理装置。
6. 前記コード情報が、前記比較したすべての分節において共通の文字列情報を含む前記第１データベース内のレコード数に基づく情報と、前記比較したすべての分節において共通の文字列情報を含む前記第２データベース内のレコード数に基づく情報とをさらに含む請求項５に記載の突合処理装置。
7. 前記第１及び第２データベース内のレコード数に基づく情報が、前記第１及び第２データベース内のレコード数自体であるか、あるいは、前記第１及び第２データベース内のレコード数が単数か複数かを示す情報である請求項１から６のいずれか１つに記載の突合処理装置。
8. 前記文字列情報が住所情報であり、前記分節設定部は、前記住所情報にあらかじめ規定されている階層構造に基づいて前記複数の分節を設定するよう構成されている請求項１から７のいずれか１つに記載の突合処理装置。
9. 文字列情報を含む複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理方法であって、
   前記文字列情報について所定の規則に従って複数の分節を設定する分節設定ステップと、
   前記複数のデータベースのうちの第１データベース内のレコードに含まれる文字列情報と、前記複数のデータベースのうちの第２データベース内のレコードに含まれる文字列情報とを比較して、相互に対応する分節内の文字列情報の一致又は不一致を検出するレコード比較ステップと、
   比較したすべての分節において共通の文字列情報を含むレコードが前記第１及び第２データベースの両方に存在する場合には、前記比較したすべての分節において共通の文字列情報を含むことを示す情報を、前記比較したすべての分節において共通の文字列情報を含む前記第１及び第２データベース内のレコードのそれぞれに関連付ける突合結果生成ステップとを、
   有する突合処理方法。
10. 文字列情報を含む複数のレコードがそれぞれ格納された複数のデータベースの突合処理を行う突合処理方法をコンピュータにより実行させるための突合処理プログラムであって、
    前記文字列情報について所定の規則に従って複数の分節を設定する分節設定ステップと、
    前記複数のデータベースのうちの第１データベース内のレコードに含まれる文字列情報と、前記複数のデータベースのうちの第２データベース内のレコードに含まれる文字列情報とを比較して、相互に対応する分節内の文字列情報の一致又は不一致を検出するレコード比較ステップと、
    比較したすべての分節において共通の文字列情報を含むレコードが前記第１及び第２データベースの両方に存在する場合には、前記比較したすべての分節において共通の文字列情報を含むことを示す情報を、前記比較したすべての分節において共通の文字列情報を含む前記第１及び第２データベース内のレコードのそれぞれに関連付ける突合結果生成ステップとを、
    有する突合処理方法をコンピュータにより実行させるための突合処理プログラム。