【０００１】
【発明の属する技術分野】
本発明は、データベース統合装置に関し、特に、住所等の個人情報が登録される複数のデータベースを統合するためのデータベース統合装置に関する。
【０００２】
【従来の技術】
一般に、行政機関や企業等では、住民や顧客等の個人情報をデータベースを用いて管理し、業務に利用している。例えば、行政機関は、データベースに登録された個人情報を利用して、住民に告知書などを送付している。データベースには、個人情報として、例えば、名前、住所、電話番号や、その他の情報が、個人ごとに登録される。この場合、同じデータベースに、同じ人についての個人情報が重複して登録されると、行政機関から、その人に同じ告知書が２通届くなどの無駄が生じることになる。
【０００３】
上記したような無駄を防止するには、同一人の個人情報をまとめ、重複する個人情報の名寄せをするとよい。名寄せに関する技術としては、特開平１１−１９１１２４号公報に記載された技術がある。この技術では、データベースに登録された顧客の個人情報を含む契約マスタから、個人名について名寄せした個人名寄せ情報ファイルを作成する。この技術において、個人名寄せ情報ファイルの作成では、住所の表記によって、本来同じ住所を意味する、例えば「○○町１丁目１番１号」と「○○町１−１−１」とが異なる住所として認識されないように、住所の一部について文字列の変換を行い、個人名及び変換後の住所が一致する個人情報を、重複する個人情報と認識している。
【０００４】
【特許文献１】
特開平１１−１９１１２４号公報
【０００５】
【発明が解決しようとする課題】
ところで、例えば同じ行政機関内では、データの不整合を防ぐという観点からも、同じような個人情報を扱う各部署において、同じデータベースシステムを使用し、個人情報等を一元管理することが望ましい。しかし、実際には、システムの構築時期が異なる、或いは、ベンダが異なるといった諸事情により、各部署において、異なるデータベースシステムが使用されており、個人情報等が一元管理されていないことが多い。
【０００６】
行政機関等において、住所などは、修正される機会が多いが、個人情報が一元管理されていないときには、住所の修正をシステムごとに行う必要があり、修正漏れ等によって、データに不整合が生じる。住所などは、告知書の送付などにおいては非常に重要なデータであり、これらのデータに不整合が生じた場合には、その影響も大きい。しかし、従来、異なるシステムで運用される複数のデータベースを統合し、異なるデータベースに登録された個人情報を一元管理するための装置は、知られていなかった。
【０００７】
本発明は、異なるシステムで使用される複数のデータベースを再構築して、１つのデータベースに統合できるデータベース統合装置を提供することを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、本発明のデータベース統合装置は、名称及び住所情報を少なくとも含む個人情報が登録された複数の個別データベースのそれぞれを、前記個人情報が統一した表記方法で記述されたデータファイルに変換するデータ変換手段と、複数の前記データファイルに含まれる個人情報を相互に照合し、該複数のデータファイル間で重複した個人情報を１つの個人情報にまとめて１つの統合データベースとして出力するデータベース構築手段とを備えることを特徴とする。
【０００９】
本発明のデータベース統合装置は、例えば異なるシステムで使用された複数の個別データベースを、１つの統合データベースに統合し、その統合データベースを利用してデータベースシステムを運用できるため、システム間で個人情報が一致しない事態を回避することができる。
【００１０】
本発明のデータベース統合装置では、前記統合データベースは、前記住所情報を３つの区分情報に分割して登録することが好ましい。
統合データベースは、統合元の個別データベースが住所情報を３つの区分情報に分割して登録していないときには、住所情報を３つの区分情報に分割して登録し、３つの区分情報に分割して登録しているときには、その３つの区分情報を、そのまま登録することができる。住所情報の３つの区分情報は、例えば、「都道府県名」「市区町村名」「都道府県名及び市区町村名を除く地番以下」の３項目とすることができる。
【００１１】
本発明のデータベース統合装置では、前記統合データベースは、前記住所情報を地域ＪＩＳコードに変換して、又は、地域ＪＩＳコードと共に登録する。この場合、統合データベースのメンテナンス性が向上する。
【００１２】
本発明のデータベース統合装置では、前記データベース構築手段は、少なくとも名称及び住所情報が相互に一致した２つの個人情報を重複した個人情報と判断する構成を採用することができる。
【００１３】
本発明のデータベース統合装置では、前記個人情報が更に電話番号情報を含むときには、上記に代えて、前記データベース構築手段は、少なくとも名称及び電話番号情報が相互に一致した２つの個人情報を重複した個人情報と判断する構成を採用することもできる。
【００１４】
【発明の実施の形態】
以下、図面を参照し、本発明の実施形態例に基づいて、本発明を更に詳細に説明する。図１は、本発明の一実施形態例のデータベース統合装置の構成を示している。このデータベース統合装置１００は、名寄せ処理部１１０と、名寄せ編集ファイル統合部１２０と、地域ＪＩＳコード変換部１３０とを備える。データベース統合装置１００は、個人情報を管理するための複数のデータベース２００（１）〜（ｍ）（ｍは２以上の整数）を、複数のシステムで使用可能となるように、住所が地域ＪＩＳコードにより管理される１つの統合データベース２０４に統合する。
【００１５】
データベース２００（１）〜（ｍ）には、個人名、住所、電話番号、及び、その他の情報が含まれる個人情報が登録されている。名寄せ処理部１１０は、構築元となる各データベース２００の登録データが、個人名及び住所について、統一的な表現で表された個別名寄せ編集ファイル２０１（１）〜（ｍ）を生成する。名寄せ編集ファイル統合部１２０は、個別名寄せ編集ファイル２０１（１）〜（ｍ）から統合名寄せ編集ファイル２０２を作成する。地域ＪＩＳコード変換部１３０は、地域ＪＩＳコード管理ファイル２０３を参照して、統合名寄せ編集ファイル２０２内の住所の都道府県及び市区町村を地域ＪＩＳコードに変換し、統合データベース２０４を生成する。
【００１６】
名寄せ処理部１１０は、データ変換手段であり、個人名変換部１１１と、住所変換部１１２とを備える。個人名変換部１１１は、各データベース２００に個人名のデータとして登録されている文字列を所定の規則で変換し、変換後の文字列を、個別名寄せ編集ファイル２０１に個人名のデータとして登録する。住所変換部１１２は、各データベース２００に住所のデータとして登録されている文字列を所定の規則で変換し、変換後の文字列を、「都道府県」、「市区町村」、及び、「地番以下」の３項目に区分して、個別名寄せ編集ファイル２０１に住所のデータとして登録する。
【００１７】
図２は、個人名変換部１１１における文字列の変換規則の一例を示している。個人名変換部１１１は、各データベース２００において、個人名として登録されている文字列に、図２に示す表の「変換対象」の文字列が含まれるときには、その変換対象の文字列を、対応する「変換後」の文字列で置換する。個人名変換部１１１は、例えば、個人名として登録されている文字列が、「（株）Ａ商事」又は「株式会社 Ａ商事」を含むときには、その文字列を「Ａ商事」に変換し、個人名として登録されている文字列が、「代表取締役 Ｂ山 Ｃ雄」や「Ｂ山 Ｃ雄」を含むときには、その文字列を「Ｂ山Ｃ雄」に変換する。このようにして変換された文字列は、個別名寄せ編集ファイル２０１において、個人名のデータとして登録される。
【００１８】
図３は、住所変換部１１２における文字列の変換規則の一例を示している。住所変換部１１２は、各データベース２００において、住所として登録されている文字列に、図３に示す表の「変換対象」の文字列が含まれるときには、その変換対象の文字列を、対応する「変換後」の文字列で置換する。住所変換部１１２は、例えば、住所として登録されている文字列が、「丸の内 １丁目１番１号」又は「丸ノ内 １丁目１の１」を含むときには、その文字列を、「丸ノ内１−１−１」に置換する。ただし、例外として、例えば住所として登録される文字列に「ｎ番」（ｎは任意の自然数）が含まれる場合であっても、その文字列が「ｎ番館」等であれば、文字列の置換は行わない。変換された文字列は、個別名寄せ編集ファイル２０１において、住所のデータとして登録される。
【００１９】
名寄せ編集ファイル結合部１２０と地域ＪＩＳコード変換部１３０とはデータベース構築手段を構成する。名寄せ編集ファイル統合部１２０は、レコード結合部１２１と、重複削除部１２２とを備える。レコード結合部１２１は、個別名寄せ編集ファイル２０１（１）〜（ｍ）をマージした統合名寄せ編集ファイル２０２を作成する。統合名寄せ編集ファイル２０２では、個別名寄せ編集ファイル２０１（１）〜（ｍ）の各レコードが、個人名に対応する項目のデータをキーにしてソートされる。重複削除部１２２は、統合名寄せ編集ファイル２０２内に、同じ人についての個人情報が重複登録されていないかを調べ、重複している個人情報を削除する。重複削除部１２２は、統合名寄せ編集ファイル２０２のあるレコードと別のレコードとにおいて、例えば、項目「個人名」のデータと項目「電話番号」のデータとの双方が一致すると、それらは同一人物の個人情報であるとみなし、そのうちの一方のレコードを重複レコードとして削除する。
【００２０】
地域ＪＩＳコード変換部１３０は、コード変換部１３１と、識別コード付番部１３２とを備える。コード変換部１３１は、地域ＪＩＳコード管理ファイル２０３を参照して、統合名寄せ編集ファイル２０２内の住所データを、地域ＪＩＳコードに変換する。地域ＪＩＳコード管理ファイル２０３には、５桁からなる地域ＪＩＳコードと、都道府県及び市区町村との対応関係が記憶されている。なお、地域ＪＩＳコードでは、都道府県に対応して２桁のコードが割り振られ、市区町村に対応して３桁のコードが割り当てられている。
【００２１】
図４は、統合名寄せ編集ファイル２０２と、統合データベース２０４との対応関係を示している。上述のように、統合名寄せ編集ファイル２０２では、住所が、「都道府県」、「市区町村」、及び、「地番以下」の３項目に分割して登録されている。コード変換部１３１は、統合名寄せ編集ファイル２０２から、住所に関する情報のうち、「都道府県」及び「市区町村」の項目のデータを読み込み、それらのデータを対応する地域ＪＩＳコードに変換して、その地域ＪＩＳコードを統合データベース２０４に登録する。
【００２２】
統合名寄せ編集ファイル２０２に登録される個人情報が、図４（ａ）に示す情報で構成されているとき、その個人情報は、統合データベース２０４では、同図（ｂ）に示すように、都道府県名、及び、市区町村名が地域ＪＩＳコードに変換されて登録される。識別コード付番部１３２は、同図（ｂ）に示すように、統合データベース２０４に登録される個人情報に、識別コードを付与する。
【００２３】
図５は、名寄せ処理部１１０における個別名寄せ編集ファイル２０１の生成手順の一例を示し、図６は、名寄せ編集ファイル統合部１２０における統合名寄せ編集ファイル２０２の生成手順の一例を示し、図７は、地域ＪＩＳコード変換部１３０における統合データベース２０４の生成手順の一例を示している。以下、図５〜図７を参照して、データベース統合装置１００によるデータベース２００（１）〜（ｍ）の統合処理について、詳細に説明する。
【００２４】
名寄せ処理部１１０は、各データベース２００から個々の個人情報を読み込む（図５のステップＳ５１）。個人名変換部１１１は、各データベース２００から読み込んだ個人情報の個人名に対応する項目の文字列を抽出して、その文字列を、個人名の表現形式が統一化されるように、上述の規則（図２）に従って変換する（ステップＳ５２）。住所変換部１１２は、各データベース２００から読み込んだ個人情報の住所に対応する項目のデータを抽出し、そのデータが、「都道府県」、「市区町村」、及び、「地番以下」の３項目に区分されているか否かを判断する（ステップ５３）。住所に対応するデータが上記した３項目に区分されているときにはステップＳ５５へ進み、住所変換部１１２は、それぞれの項目のデータについて、文字列の変換処理を行う。
【００２５】
住所に対応するデータが上記した３項目に区分されていないときには、住所変換部１１２は、住所を構成する文字列から、都道府県名、及び、市区町村名を切り出し、住所データを、「都道府県」、「市区町村」、及び、「地番以下」の３項目に分割する（ステップＳ５４）。この３項目への分割では、住所変換部１１２は、まず、先頭から、「都」「道」「府」又は「県」の文字が現れるまでの文字列を都道府県名として切り出し、その文字列を項目「都道府県」のデータとする。ついで、住所を構成する文字列から都道府県名を除いた残りの文字列から市区町村名を切り出して、その文字列を項目「市区町村」のデータとし、住所を構成する文字列から都道府県名及び市区町村名を除いた残りの文字列を、項目「地番以下」のデータとする。
【００２６】
ここで、市区町村名の切り出しにおいて、都道府県名の切り出しと同様に、「市」「区」「群」「町」又は「村」が現れるまでの文字列を市区町村名を切り出すと、例えば、市区町村の名称自体にそれらに文字を含む、「八日市場市」や「羽村市」といった市区町村名がうまく切り出せない。また、政令指定都市では、例えば、都道府県名を除いた文字列に「横浜市港北区」が含まれるときであれば、「横浜市」ではなく、「横浜市港北区」までを市区町村名として切り出したい。そこで、特定の市区町村名については、例外として例外住所管理ファイルに登録しておく。住所変換部１１２は、その例外住所管理ファイルを参照し、都道府県名を除いた文字列に例外住所ファイルに登録されている特定の市区町村名が含まれているか否かを判断する。
【００２７】
図８は、例外住所管理ファイルに登録される市区町村名の一部を示している。例外住所管理ファイルには、東京２３区の名称、横浜市港北区や札幌市中央区といった政令指定都市の区の名称、及び、図８の表に示すような市区町村の名称自体に「市」「区」「群」「町」又は「村」の文字を含む市区町村の名称が登録される。住所変換部１１２は、都道府県名を除いた文字列に、例外住所管理ファイルに登録される市区町村名が含まれるときには、その市区町村名を、項目「市区町村」として認識し、残りの文字列を、項目「地番以下」として認識する。
【００２８】
住所変換部１１２は、都道府県名を除いた文字列に例外住所管理ファイルに登録される市区町村名が含まれないときには、「市」が現れるまでの文字列、又は、「群」が現れてから更に「町」若しくは「村」が現れるまでの文字列を、項目「市区町村」のデータとして認識し、残りの文字列を、項目「地番以下」のデータとして認識する。住所変換部１１２は、住所を構成するデータから、都道府県名及び市区町村名を切り出せなかったものについては、あらかじめ用意された住所変換不能ファイルに、切り出し不能であった住所データを書き込む。
【００２９】
住所変換部１１２は、住所を構成する３項目のデータそれぞれを、住所の表現形式が統一化されるように、上述の規則（図３）に従って変換する（ステップＳ５５）。名寄せ処理部１１０は、生成する各個別名寄せ編集ファイル２０１において、ステップＳ５２で変換された個人名を構成する文字列を、個人名のデータとして登録し、ステップＳ５５で変換された住所を構成する文字列を、上記した３項目に分割された住所のデータとして登録する（ステップＳ５６）。
【００３０】
名寄せ編集ファイル統合部１２０は、名寄せ処理部１１０によって生成された個別名寄せ編集ファイル２０１を全て読み込み（図６のステップＳ６１）、レコード結合部１２１によって、各個別名寄せ編集ファイル２０１の登録内容をマージした統合名寄せ編集ファイル２０２を生成する（ステップＳ６２）。レコード結合部１２１は、統合名寄せ編集ファイル２０２に登録された個人名のデータをキーにして、登録データを名前順にソートする（ステップＳ６３）。
【００３１】
重複削除部１２２は、個人名順にソートされた統合名寄せ編集ファイル２０２から１レコードずつ登録データを読み込み（ステップＳ６４）、今回読み込んだ登録データと、読み込み済みの登録データとを比較して、同じ人についてのデータが重複登録されているか否かをチェックする（ステップＳ６５）。重複削除部１２２は、例えば今回読み込んだ登録データの「個人名」及び「電話番号」と、読み込み済みの各登録データの「個人名」及び「電話番号」とを比較し、データが一致するものがあるときには、同じ人についてのデータが重複登録されていると判断する。重複削除部１２２は、項目「電話番号」にデータが登録されていない場合には、電話番号に代えて、住所のデータを使用して、データが重複登録されているか否かを判断してもよい。
【００３２】
重複削除部１２２は、データが重複登録されていると判断すると、重複レコードの一方を削除する（ステップＳ６６）。または、これに代えて、重複データを、あらかじめ用意しておいた別のファイルに待避する。重複削除部１２２は、ステップＳ６４〜ステップＳ６６を、統合名寄せ編集ファイル内の全てのレコードについて行い（ステップＳ６７）、統合名寄せ編集ファイル２０２内で重複するデータを削除する。
【００３３】
地域ＪＩＳコード変換部１３０は、重複データが削除された統合名寄せ編集ファイル２０２を読み込む（図７のステップＳ７１）。コード変換部１３１は、レコードごとに、都道府県名及び市区町村名を取得する（ステップＳ７２）。コード変換部１３１は、地域ＪＩＳコード管理ファイルを参照して（ステップＳ７３）、ステップＳ７２で取得した都道府県名を２桁のコードに変換し、市区町村名を３桁のコードに変換する（ステップＳ７４）。
【００３４】
コード変換部１３１は、ステップＳ７２〜ステップＳ７４を、統合名寄せ編集ファイル内の全てのレコードについて行い（ステップＳ７５）、住所データの都道府県名及び市区町村名を地域ＪＩＳコードに変換する。識別コード付番部１３２は、各レコードに識別番号を付与する。以上のような手順により、複数のデータベース２００（１）〜（ｍ）から、個人情報が一元管理され、住所が地域ＪＩＳコードで管理される統合データベース２０４が得られる。
【００３５】
図９は、データベース統合前のデータベースシステムの運用例を示している。この運用例では、個人情報が、システムごとのデータベース２００によって管理されている。例えば、ある人についての個人情報が、システムＡで使用されるデータベース２００（１）、システムＢで使用されるデータベース２００（２）の双方に登録されているとき、その個人情報の住所を更新する際には、データベース２００（１）での更新と、データベース２００（２）での更新とを独立に行う必要がある。この場合、一方のデータベース２００では住所が更新されたが、他方のデータベース２００では住所が更新されていないと、同じ人についての個人情報に不整合が生じることになる。
【００３６】
図１０は、データベース統合後のデータベースステムの運用例を示している。図９に示すように運用されていた複数のデータベース２００を、本実施形態例のデータベース統合装置１００を用いて統合データベース２０４に統合し、これをシステム間で共有して利用すると、図１０に示すように、異なるシステム間で個人情報を一元管理できる。この場合には、個人情報の更新が頻繁に行われる場合であっても、例えば、システムＡでの利用される個人情報と、システムＢで使用される個人情報とで、データの不整合が生じなくなって、個人情報の信頼性が向上する。また、統合データベース２０４では、住所が、地域ＪＩＳコードを用いて管理されるため、住所データ更新作業時のオペレータの負担を軽減でき、データベースのメンテナンス性が向上する。
【００３７】
図９に示す例では、システムＡ及びシステムＢのデータベース２００（１）、（２）に登録される個人情報では、住所が、都道府県名、市区町村名、及び、地番以下の３項目に分かれて登録されているが、システムＣのデータベース２００（３）に登録される個人情報では、住所が、特に分割されることなく登録されている。データベース統合装置１００は、住所が、上記３項目に分割されていないデータベース２００については、住所データを構成する文字列から、前述の規則により、上記３項目に対応するデータを切り出し、住所データを上記３項目に分割して、統合データベース２０４に登録する。このようにして、住所データを統合データベース２０４に登録することにより、統合元のデータベース２００に、住所データの登録形式が異なるものが含まれる場合であっても、地域ＪＩＳコード変換部１３０は、住所データを地域ＪＩＳコードへ正しく変換できる。
【００３８】
なお、上記実施形態例では、個人名及び住所を、統一的な表現形式に文字列変換して個別名寄せ編集ファイル２０１に登録する例について説明したが、これに代えて、個人名及び住所の項目の文字列をそのまま個別名寄せ編集ファイル２０１に登録し、個別名寄せ編集ファイル２０１に項目を新たに追加して、その追加した項目に変換後の文字列を登録するようにしてもよい。この場合、統合データベース２０４には、例えば、データベース２００に登録された個人名「代表取締役 Ｂ山 Ｃ雄」と、これを変換した「Ｂ山Ｃ雄」との双方が登録される。また、住所については、地域ＪＩＳコードと、「都道府県名」及び「市区町村名」との双方を、統合データベース２０４に登録してもよい。
【００３９】
以上、本発明をその好適な実施形態例に基づいて説明したが、本発明のデータベース統合装置は、上記実施形態例にのみ限定されるものではなく、上記実施形態例の構成から種々の修正及び変更を施したものも、本発明の範囲に含まれる。
【００４０】
【発明の効果】
以上説明したように、本発明のデータベース統合装置は、例えば異なるシステムで使用された複数の個別データベースに登録される個人情報を、データ変換手段で統一した表記形式に変換し、かつ、重複する個人情報をまとめて、１つの統合データベースに統合でき、このような統合データベースを利用してデータベースシステムを運用することで、異なるシステム間での個人情報の不整合を防止できる。
【図面の簡単な説明】
【図１】本発明の一実施形態例のデータベース統合装置の構成を示すブロック図。
【図２】個人名変換部１１１における文字列の変換規則の一例を示す表。
【図３】住所変換部１１２における文字列の変換規則の一例を示す表。
【図４】統合名寄せ編集ファイル２０２と、統合データベース２０４との対応関係を示すブロック図。
【図５】名寄せ処理部１１０における個別名寄せ編集ファイル２０１の生成手順の一例を示すフローチャート。
【図６】名寄せ編集ファイル統合部１２０における統合名寄せ編集ファイル２０２の生成手順の一例を示すフローチャート。
【図７】地域ＪＩＳコード変換部１３０における統合データベース２０４の生成手順の一例を示すフローチャート。
【図８】例外住所管理ファイルに登録される市区町村名の一部を示す表。
【図９】データベース統合前のデータベースシステムの運用例を示すブロック図。
【図１０】データベース統合後のデータベースステムの運用例を示すブロック図。
【符号の説明】
１００：データベース統合装置
１１０：名寄せ処理部
１１１：個人名変換部
１１２：住所変換部
１２０：名寄せ編集ファイル統合部
１２１：レコード結合部
１２２：重複削除部
１３０：地域ＪＩＳコード変換部
１３１：コード変換部
１３２：識別コード付番部
２００：データベース
２０１：個別名寄せ編集ファイル
２０２：統合名寄せ編集ファイル
２０３：地域ＪＩＳコード管理ファイル
２０４：統合データベース[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a database integration device, and more particularly to a database integration device for integrating a plurality of databases in which personal information such as addresses is registered.
[0002]
[Prior art]
In general, administrative organizations and companies manage personal information such as residents and customers using a database and use them for business. For example, an administrative institution uses a personal information registered in a database to send a notice or the like to residents. In the database, as personal information, for example, name, address, telephone number, and other information are registered for each individual. In this case, if personal information about the same person is registered in the same database, there will be a waste such as two identical notices delivered to the person from the administrative agency.
[0003]
In order to prevent waste as described above, it is preferable to collect the personal information of the same person and collect names of overlapping personal information. As a technique related to name identification, there is a technique described in Japanese Patent Application Laid-Open No. 11-191124. In this technique, a personal name identification information file in which personal names are identified is created from a contract master including personal information of customers registered in a database. In this technology, when creating a personal name collation information file, the same address is originally meant depending on the notation of the address, for example “XX town 1-1-1” and “XX town 1-1-1” differ. A character string is converted for a part of the address so that it is not recognized as an address, and personal information whose personal name matches the converted address is recognized as overlapping personal information.
[0004]
[Patent Document 1]
Japanese Patent Laid-Open No. 11-191124
[Problems to be solved by the invention]
By the way, for example, from the viewpoint of preventing data inconsistency in the same administrative organization, it is desirable to use the same database system and centrally manage personal information and the like in each department that handles similar personal information. However, in reality, different database systems are used in each department due to various circumstances such as different system construction times or different vendors, and personal information is often not centrally managed.
[0006]
In administrative agencies, etc., there are many opportunities to correct addresses, etc., but when personal information is not centrally managed, it is necessary to correct addresses for each system, resulting in inconsistencies in data due to omission of correction etc. . Addresses are very important data for sending notices, etc., and if these data are inconsistent, the influence is also great. However, conventionally, an apparatus for integrating a plurality of databases operated in different systems and managing personal information registered in different databases has not been known.
[0007]
It is an object of the present invention to provide a database integration apparatus that can reconstruct a plurality of databases used in different systems and integrate them into one database.
[0008]
[Means for Solving the Problems]
In order to achieve the above object, the database integration apparatus according to the present invention provides data in which a plurality of individual databases in which personal information including at least name and address information is registered are described in a notation method in which the personal information is unified. Data conversion means for converting to a file and personal information contained in a plurality of the data files are collated with each other, and the personal information duplicated between the data files is combined into one personal information and output as one integrated database And a database construction means.
[0009]
In the database integration apparatus of the present invention, for example, a plurality of individual databases used in different systems can be integrated into one integrated database, and the database system can be operated using the integrated database. You can avoid the situation.
[0010]
In the database integration apparatus of the present invention, it is preferable that the integrated database registers the address information by dividing it into three pieces of division information.
In the integrated database, when the individual database of the integration source does not register address information divided into three division information, the address information is divided into three division information and registered, and divided into three division information and registered. The three classification information can be registered as they are. The three pieces of classification information of the address information can be, for example, three items of “prefecture name”, “city name”, and “under the lot number excluding the prefecture name and city name”.
[0011]
In the database integration apparatus of the present invention, the integrated database converts the address information into a regional JIS code or registers it together with the regional JIS code. In this case, the maintainability of the integrated database is improved.
[0012]
In the database integration apparatus of the present invention, the database construction means can adopt a configuration in which at least two pieces of personal information whose name and address information match each other are determined as overlapping personal information.
[0013]
In the database integration apparatus according to the present invention, when the personal information further includes telephone number information, instead of the above, the database construction means is configured so that at least two personal information whose name and telephone number information match each other are duplicated. It is also possible to adopt a configuration for determining information.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, with reference to the drawings, the present invention will be described in more detail based on exemplary embodiments of the present invention. FIG. 1 shows the configuration of a database integration apparatus according to an embodiment of the present invention. The database integration apparatus 100 includes a name identification processing unit 110, a name identification editing file integration unit 120, and a regional JIS code conversion unit 130. The database integration apparatus 100 uses a plurality of databases 200 (1) to (m) (m is an integer of 2 or more) for managing personal information so that addresses can be used in a plurality of systems. Are integrated into one integrated database 204 managed by.
[0015]
In the databases 200 (1) to (m), personal information including personal names, addresses, telephone numbers, and other information is registered. The name identification processing unit 110 generates individual name identification editing files 201 (1) to 201 (m) in which the registration data of each database 200 as a construction source is expressed in a unified expression with respect to an individual name and an address. The name identification edit file integration unit 120 creates an integrated name identification edit file 202 from the individual name identification edit files 201 (1) to 201 (m). The regional JIS code conversion unit 130 refers to the regional JIS code management file 203 to convert the prefecture and city of the address in the integrated name identification edit file 202 into a regional JIS code, and generates an integrated database 204.
[0016]
The name identification processing unit 110 is a data conversion unit, and includes a personal name conversion unit 111 and an address conversion unit 112. The personal name conversion unit 111 converts a character string registered as personal name data in each database 200 according to a predetermined rule, and registers the converted character string as personal name data in the individual name identification edit file 201. . The address conversion unit 112 converts a character string registered as address data in each database 200 according to a predetermined rule, and converts the converted character string into “prefecture”, “city”, and “location number”. It is divided into the following three items, and is registered as address data in the individual name identification edit file 201.
[0017]
FIG. 2 shows an example of a character string conversion rule in the personal name conversion unit 111. When the character string registered as the personal name in each database 200 includes the character string “conversion object” in the table shown in FIG. 2, the personal name conversion unit 111 corresponds to the character string to be converted. Replace with the “after conversion” string. For example, when the character string registered as the personal name includes “(A) Trading Co.” or “A Trading Co., Ltd.”, the personal name conversion unit 111 converts the character string to “A Trading”, When the character string registered as the personal name includes “representative director B mountain C male” or “B mountain C male”, the character string is converted to “B mountain C male”. The character string converted in this way is registered as personal name data in the individual name identification edit file 201.
[0018]
FIG. 3 shows an example of a character string conversion rule in the address conversion unit 112. When the character string registered as an address in each database 200 includes the character string “conversion object” in the table shown in FIG. 3, the address conversion unit 112 corresponds to the character string to be converted. Replace with the string after conversion. For example, when the character string registered as the address includes “Marunouchi 1-1 Chome 1-1” or “Marunouchi 1-1 Chome 1”, the address conversion unit 112 converts the character string into “Marunouchi 1-1 -1 ". However, as an exception, for example, even if a character string registered as an address includes “n-th” (n is an arbitrary natural number), if the character string is “n-th hall” or the like, No replacement is performed. The converted character string is registered as address data in the individual name identification edit file 201.
[0019]
The name identification edit file combination unit 120 and the regional JIS code conversion unit 130 constitute a database construction unit. The name identification edit file integration unit 120 includes a record combination unit 121 and a duplication deletion unit 122. The record combining unit 121 creates an integrated name identification edit file 202 by merging the individual name identification edit files 201 (1) to (m). In the integrated name identification editing file 202, each record of the individual name identification editing files 201 (1) to 201 (m) is sorted using data of items corresponding to personal names as keys. The duplicate deletion unit 122 checks whether or not personal information about the same person is registered in the integrated name identification editing file 202, and deletes the duplicate personal information. For example, if the data of the item “personal name” and the data of the item “phone number” match in a record in the integrated name collation editing file 202 and another record, the duplicate deletion unit 122 identifies the same person. It is considered as personal information, and one of the records is deleted as a duplicate record.
[0020]
The regional JIS code conversion unit 130 includes a code conversion unit 131 and an identification code numbering unit 132. The code conversion unit 131 refers to the regional JIS code management file 203 and converts the address data in the integrated name identification edit file 202 into a regional JIS code. The regional JIS code management file 203 stores the correspondence between a 5-digit regional JIS code and prefectures and municipalities. In the regional JIS code, a 2-digit code is assigned corresponding to the prefecture, and a 3-digit code is assigned corresponding to the municipality.
[0021]
FIG. 4 shows the correspondence between the integrated name identification editing file 202 and the integrated database 204. As described above, in the integrated name collation editing file 202, the address is divided and registered into three items of “prefecture”, “city”, and “under the lot number”. The code conversion unit 131 reads the data of the items of “prefecture” and “city” from the integrated name collation editing file 202, converts the data into corresponding JIS codes, The area JIS code is registered in the integrated database 204.
[0022]
When the personal information registered in the integrated name identification edit file 202 is composed of the information shown in FIG. 4A, the personal information is stored in the integrated database 204 as shown in FIG. 4B. The name and city name are converted into a regional JIS code and registered. The identification code numbering unit 132 assigns an identification code to the personal information registered in the integrated database 204 as shown in FIG.
[0023]
FIG. 5 shows an example of the procedure for generating the individual name identification edit file 201 in the name identification processing unit 110, FIG. 6 shows an example of the procedure for generating the integrated name identification edit file 202 in the name identification edit file integration unit 120, and FIG. An example of a procedure for generating the integrated database 204 in the regional JIS code conversion unit 130 is shown. Hereinafter, the integration processing of the databases 200 (1) to (m) by the database integration device 100 will be described in detail with reference to FIGS. 5 to 7.
[0024]
The name identification processing unit 110 reads individual personal information from each database 200 (step S51 in FIG. 5). The personal name conversion unit 111 extracts the character string of the item corresponding to the personal name of the personal information read from each database 200, and converts the character string into the above-described personal name expression format so as to be unified. Conversion is performed according to the rules (FIG. 2) (step S52). The address conversion unit 112 extracts data of items corresponding to the address of the personal information read from each database 200, and the data includes three items of “prefecture”, “city”, and “under the lot number”. It is determined whether or not it is classified into (step 53). When the data corresponding to the address is divided into the above three items, the process proceeds to step S55, and the address conversion unit 112 performs character string conversion processing on the data of each item.
[0025]
When the data corresponding to the address is not classified into the above three items, the address conversion unit 112 cuts out the prefecture name and city name from the character string constituting the address, and converts the address data to “city” It is divided into three items, “Prefecture”, “City”, and “Lot number” (step S54). In the division into these three items, the address conversion unit 112 first cuts out a character string from the beginning until the character of “Me”, “Road”, “Prefecture”, or “Prefecture” appears as a prefectural name, Is the data of the item “prefecture”. Next, the name of the city is extracted from the remaining character string obtained by removing the prefecture name from the character string constituting the address, and the character string is used as the data for the item “city”. The remaining character string excluding the prefecture name and city name is used as the data for the item “Lot Number”.
[0026]
Here, in the extraction of the city name, if the character string is extracted from the character string until “city”, “city”, “group”, “town”, or “village” appears in the same way as the extraction of the prefecture name, For example, a city name such as “Yokaichi City” or “Hamura City”, which includes characters in the city name itself, cannot be cut out well. Also, in a city designated by government ordinance, for example, if “Yokohama City Kohoku Ward” is included in the character string excluding the prefecture name, not “Yokohama City” but “Yokohama City Kohoku Ward” is not included in the municipality. I want to cut it out as a name. Therefore, specific city names are registered in the exception address management file as exceptions. The address conversion unit 112 refers to the exception address management file and determines whether or not the character string excluding the prefecture name includes a specific city name registered in the exception address file.
[0027]
FIG. 8 shows a part of a city name registered in the exception address management file. The exception address management file includes the name of the 23 wards of Tokyo, the name of the decree-designated city such as Kohoku Ward in Yokohama City and Chuo Ward in Sapporo City, and the name of the city itself as shown in the table of FIG. The name of the municipality including the characters "", "ku", "group", "town" or "village" is registered. When the character string excluding the prefecture name includes the city name registered in the exception address management file, the address conversion unit 112 recognizes the city name as the item “city”. Recognize the remaining character string as the item “Lot Number”.
[0028]
When the character string excluding the prefecture name does not include the city name registered in the exception address management file, the address conversion unit 112 displays the character string or “group” until “city” appears. After that, the character string from when the “town” or “village” appears is recognized as the data for the item “city”, and the remaining character string is recognized as the data for the item “Lot Number”. The address conversion unit 112 writes the address data that cannot be cut out into the address conversion impossible file prepared in advance for those for which the prefecture name and city name cannot be cut out from the data constituting the address.
[0029]
The address conversion unit 112 converts each of the three items of data constituting the address according to the above-described rules (FIG. 3) so that the expression format of the address is unified (step S55). In each individual name identification edit file 201 to be generated, the name identification processing unit 110 registers the character string constituting the personal name converted in step S52 as personal name data, and the characters constituting the address converted in step S55. The column is registered as address data divided into the above three items (step S56).
[0030]
The name identification edit file integration unit 120 reads all the individual name identification edit files 201 generated by the name identification processing unit 110 (step S61 in FIG. 6), and the record combination unit 121 merges the registration contents of the individual name identification edit files 201. The integrated name identification edit file 202 is generated (step S62). The record combining unit 121 sorts the registered data in the order of the names using the personal name data registered in the integrated name identification edit file 202 as a key (step S63).
[0031]
The duplicate deletion unit 122 reads registration data one record at a time from the integrated name identification editing file 202 sorted in the order of individual names (step S64), compares the registration data read this time with the registered data already read, and the same person It is checked whether or not the data for is registered in duplicate (step S65). The duplicate deletion unit 122 compares, for example, the “personal name” and “telephone number” of the registered data read this time with the “personal name” and “phone number” of each registered data that has been read. When there is, it is determined that the data about the same person is registered twice. If the data is not registered in the item “telephone number”, the duplicate deletion unit 122 uses the address data instead of the telephone number to determine whether or not the data is registered in duplicate. Good.
[0032]
If the duplicate deletion unit 122 determines that the data is registered in duplicate, it deletes one of the duplicate records (step S66). Alternatively, the duplicate data is saved in another file prepared in advance. The duplicate deletion unit 122 performs steps S64 to S66 for all records in the integrated name identification edit file (step S67), and deletes duplicate data in the integrated name identification edit file 202.
[0033]
The regional JIS code conversion unit 130 reads the integrated name identification edit file 202 from which duplicate data has been deleted (step S71 in FIG. 7). The code conversion unit 131 acquires a prefecture name and a city name for each record (step S72). The code conversion unit 131 refers to the regional JIS code management file (step S73), converts the prefecture name acquired in step S72 into a two-digit code, and converts the city name into a three-digit code ( Step S74).
[0034]
The code conversion unit 131 performs steps S72 to S74 for all the records in the integrated name identification edit file (step S75), and converts the prefecture name and city name of the address data into a regional JIS code. The identification code numbering unit 132 assigns an identification number to each record. Through the procedure described above, an integrated database 204 in which personal information is centrally managed and addresses are managed by regional JIS codes is obtained from the plurality of databases 200 (1) to (m).
[0035]
FIG. 9 shows an operation example of the database system before database integration. In this operation example, personal information is managed by the database 200 for each system. For example, when personal information about a person is registered in both the database 200 (1) used in the system A and the database 200 (2) used in the system B, the address of the personal information is updated. In this case, it is necessary to independently perform the update in the database 200 (1) and the update in the database 200 (2). In this case, if the address is updated in one database 200, but the address is not updated in the other database 200, the personal information about the same person is inconsistent.
[0036]
FIG. 10 shows an operation example of the database stem after database integration. When a plurality of databases 200 operated as shown in FIG. 9 are integrated into the integrated database 204 using the database integration apparatus 100 of the present embodiment, and this is shared and used between systems, it is shown in FIG. In this way, personal information can be centrally managed between different systems. In this case, even if the personal information is frequently updated, for example, data mismatch occurs between the personal information used in the system A and the personal information used in the system B. The reliability of personal information is improved. Further, in the integrated database 204, the address is managed using the regional JIS code, so that the burden on the operator when updating the address data can be reduced, and the maintainability of the database is improved.
[0037]
In the example shown in FIG. 9, in the personal information registered in the databases 200 (1) and (2) of the system A and the system B, the address is divided into three items including a prefecture name, a city name, and a lot number. Although registered separately, in the personal information registered in the database 200 (3) of the system C, the address is registered without being divided. For the database 200 in which the address is not divided into the above three items, the database integration device 100 cuts out the data corresponding to the above three items from the character string constituting the address data according to the rules described above, It is divided into three items and registered in the integrated database 204. In this way, by registering the address data in the integrated database 204, even if the integration source database 200 includes a different address data registration format, the regional JIS code conversion unit 130 can Data can be correctly converted into regional JIS codes.
[0038]
In the above embodiment, the example in which the personal name and address are converted into a unified expression format and registered in the individual name collation editing file 201 has been described. May be registered in the individual name identification edit file 201 as is, an item may be newly added to the individual name identification edit file 201, and the converted character string may be registered in the added item. In this case, in the integrated database 204, for example, both the personal name “representative director B mountain C male” registered in the database 200 and “B mountain C male” converted from this are registered. As for the address, both the regional JIS code and the “prefecture name” and “city name” may be registered in the integrated database 204.
[0039]
As mentioned above, although this invention was demonstrated based on the suitable embodiment example, the database integration apparatus of this invention is not limited only to the said embodiment example, Various correction and the structure of the said embodiment example are carried out. Changes are also included in the scope of the present invention.
[0040]
【The invention's effect】
As described above, the database integration apparatus of the present invention converts, for example, personal information registered in a plurality of individual databases used in different systems into a notation format unified by the data conversion means, and duplicate individuals. Information can be integrated and integrated into one integrated database, and by operating a database system using such an integrated database, inconsistencies in personal information between different systems can be prevented.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration of a database integration apparatus according to an embodiment of the present invention.
FIG. 2 is a table showing an example of a character string conversion rule in the personal name conversion unit 111;
FIG. 3 is a table showing an example of a character string conversion rule in the address conversion unit 112;
FIG. 4 is a block diagram showing a correspondence relationship between an integrated name identification edit file 202 and an integrated database 204.
FIG. 5 is a flowchart illustrating an example of a procedure for generating an individual name identification edit file 201 in the name identification processing unit 110;
FIG. 6 is a flowchart showing an example of a procedure for generating an integrated name identification edit file 202 in the name identification edit file integration unit 120;
FIG. 7 is a flowchart showing an example of a procedure for generating an integrated database 204 in a regional JIS code conversion unit 130;
FIG. 8 is a table showing a part of city names registered in the exception address management file.
FIG. 9 is a block diagram showing an operation example of a database system before database integration.
FIG. 10 is a block diagram showing an operation example of a database stem after database integration.
[Explanation of symbols]
100: Database integration device 110: Name identification processing unit 111: Personal name conversion unit 112: Address conversion unit 120: Name identification edit file integration unit 121: Record combination unit 122: Duplicate deletion unit 130: Area JIS code conversion unit 131: Code conversion unit 132: Identification code numbering part 200: Database 201: Individual name identification edit file 202: Integrated name identification edit file 203: Regional JIS code management file 204: Integrated database
