JP2006092409A - 複合データベース検索システムおよび複合データベース検索方法ならびにそのためのプログラム - Google Patents

Abstract

【課題】 検索結果格納領域が少なく効率的に検索可能な複合データベース検索技術の提供。
【解決手段】 複数のデータベースの列情報を格納したキャッシュファイル４ｂを作成し（キャッシュファイル作成部３ａ）、キャッシュファイルのデータを顧客識別子を用いてマージ・ソートした仮想識別子キャッシュファイル４ｄを作成し（仮想識別子キャッシュファイル作成部３ｂ）、検索条件でキャッシュファイルを検索し、検索条件に一致したレコード位置のビットを“１”で表し、一致しないレコード位置のビットを“０”で表したビット配列テーブル５ｄを作成し（顧客情報抽出部３ｃ）、ビット配列テーブルからビットが“１”の位置を取得し、仮想識別子キャッシュファイルから前記ビットが“１”の位置に対応するデータを取得する（顧客識別子取得部３ｄ）。
【選択図】 図１

Description

本発明は、ネットワーク上に分散している複数のデータベースに対して、指定された条件式に合致するデータ（例えば、顧客情報など）を検索抽出する複合データベース検索技術に係り、特に対象レコード数が大量で、抽出されるデータが大量であってもメモリの消費を節約しつつ検索時間を短くすることが可能な複合データベース検索システムおよび方法ならびにそのためのプログラムに関する。

従来、複数の既存のデータベースに格納されている顧客情報を利用して、顧客管理を行うことはよく行われている。既存の複数のデータベースは、通常、それぞれシステムの目的が異なっているためその目的に合わせて個別に開発されて、ネットワーク上に分散されて設けられる。データベースを用いた顧客管理の機能のうち、最も重要なものは、与えられた条件式を満たす顧客情報を検索する機能（顧客情報抽出機能）である。

それぞれに顧客情報が記録されている複数の分散したデータベースに対して、あたかも１つのデータベースに対するように１つの条件式で検索する、所謂、複合データファイルの検索方式に関する従来技術としては、例えば、特開平１１−２１２９９４号公報「複合データファイルの検索方式とその方法および検索プログラムを記録した記録媒体」（特許文献１）に記載された検索方式がある。

特許文献１に係る検索方式は、入力された検索条件を複合ファイルの構成に合わせて分割する検索分割手段と、分割された検索条件の各部分をもとに複合ファイルを各々検索し、各々の複合ファイルにおける検索されたデータを結合して統合ファイルを生成し、該統合ファイルを用いて検索結果を出力する検索手段を備えたものである。このように、特許文献１では、分割した検索条件で各々のデータを抽出した上でデータ結合を行うことで一時ファイルの容量を少なくし、かつ高速で効率的な検索を行うようにしている。

また、検索で抽出されるデータが大量であっても、検索結果を格納する検索結果格納領域が膨大にならずに記憶領域を効率よく利用できる検索処理方式として、特開平０５−３２４７３１号公報「データの検索処理方式」（特許文献２）に記載された技術がある。

特許文献２に記載された方式は、検索処理を行った結果、検索条件に一致したレコード全てを検索対象データとは別の記憶領域に書き出すのではなく、検索結果の１レコードを不一致か一致かの識別記号（つまり０又は１の１ビット情報）で格納領域に格納するようにしている。

また、特開２０００−２２２２７２号公報「データベース検索システム」（特許文献３）には、ネットワーク環境において、高速キャッシュを実現するデータベース検索システムについて記載されている。

特許文献３に記載されたデータベース検索システムでは、検索対象のデータベースから検索されたデータを格納するデータキャッシュと、データベースに保有されているデータとデータキャッシュに格納されたデータとの相関をとるオブジェクトリファレンスを設けている。オブジェクトリファレンスは、データベースに格納されているデータのインデックスと、データを格納しているデータキャッシュのアドレスと、ＷＥＢサーバのネットワーク上のＩＰアドレスとにより、データの相関をとることが説明されている。

特開平１１−２１２９９４号公報 特開平０５−３２４７３１号公報 特開２０００−２２２２７２号公報

従来、データベースに格納されているレコード数が大量であって、かつ条件検索による抽出レコード件数も大量になると、その検索結果データを一括して取り出すと記憶領域（メモリ）不足に陥るという問題があった。

この問題を解決する従来技術として、例えば、特許文献２に示す検索結果情報をビット化する方法、または、特許文献３に示す検索データをキャッシュとして格納する方法などが知られていた。

しかし、これら特許文献２および特許文献３に記載された技術は、何れも検索対象のデータベースが１つのデータベースを対象とするものであり、検索対象のデータベースが複数となる場合には、特許文献２および３に記載の技術をそのまま適用することはできない。

例えば、顧客の属性情報を記録した顧客属性データベースと、顧客の注文情報を記録した注文情報データベースとが、ネットワーク上にそれぞれ別々のデータベースとして存在し、検索サーバから、これら２つのデータベースを検索対象データベースとして、「年齢が３０歳以上の男性で、かつ２０００円以上の商品を購入（注文）した顧客」という検索条件で、その条件に一致する顧客識別子を抽出するという場合、特許文献１に記載された複合データファイル検索方式を適用することは可能である。

ところが、特許文献１記載の方式では、分割検索された検索結果、および各々の検索結果からデータ結合を行って最終検索結果を求めるまで、検索結果データそのものを一時ファイルに記憶する方式となっているため、検索結果記憶領域の使用量が大きくなる。しかし、検索結果データをデータそのもので記憶せずに、特許文献２に示されたビット情報で保持すれば、より一層、検索結果記憶領域の使用量を少なくすることができると考えられる。

ところが、特許文献２に記載の検索処理方式は、検索結果を条件が一致したレコード位置とビット位置とを対応させているため、データベース１（顧客属性データベース）の検索結果ビット情報とデータベース２（注文情報データベース）の検索結果ビット情報とを、そのままデータ結合することはできないという問題がある。

また、同様に、特許文献３に示される検索結果データをキャッシュとして格納する方式を、複合検索処理としてのキャッシュ方法を新たに構築すれば、より効率的な複合検索が可能となる。

そこで、本発明は、上記課題を解決し、検索結果格納領域がより少ない領域で可能とし、かつ効率的に検索可能な複合データベース検索システムを提供することを目的としている。

本発明は、上記目的を達成するために、ネットワーク上に分散している複数のデータベースを連携して検索条件に合致するデータを検索する場合、複数のデータベースの列情報を格納したキャッシュファイル（４ｂ）を作成し（キャッシュファイル作成部３ａ）、キャッシュファイルのデータをマージ・ソートした仮想識別子キャッシュファイル（４ｄ）を作成し（仮想識別子キャッシュファイル作成部３ｂ）、指定された検索条件にしたがってキャッシュファイルを検索するとともに、レコード位置を１ビットに対応させ、検索した結果、検索条件に一致したレコード位置のビットを“１”で表し、一致しないレコード位置のビットを“０”で表したビット配列テーブルを作成し（顧客情報抽出部３ｃ）、ビット配列テーブル（５ｄ）からビットが“１”の位置を取得し、仮想識別子キャッシュファイル（４ｄ）から前記ビットが“１”の位置に対応するデータを取得する（顧客識別子取得部３ｄ）ようにしたことを特徴としている。

本発明では、後述する実施例に記載のように、検索途中結果および検索結果をビット配列でメモリ内に管理する。キャッシュファイルに格納されているデータを配列形式と見て、検索に合致したレコードは、インデックス位置（レコードの位置）に対応するビットをＯＮにする。

また検索対象の顧客識別子は各々のデータベースに存在しているが、配列としての格納位置が異なっている。このため複数のデータベースに関し検索結果を求めた後、集合演算を行う場合にビット配列を使うのは都合が悪い。したがって各々のデータベースにある顧客識別子をすべて保持する顧客識別子データベース表が存在するものと仮定して（１つのデータベース表としては、実在しない）、そのキャッシュファイル（仮想顧客識別子キャッシュファイル）のみを検索サーバの外部記憶装置に設ける（実在させる）ようにする。

そして顧客情報抽出時、各々のデータベースから検索結果を求めるときに、上記仮想顧客識別子キャッシュファイルのインデックス位置のビット配列を求めて、それらの集合演算を行うようにする。

検索結果は、上記の仮想顧客識別子キャッシュファイルに関するビット配列で保持する。

検索結果からデータを取り出す場合は、ビット配列のビットがＯＮになっている位置に相当する顧客識別子を、仮想顧客識別子キャッシュファイルを見て取り出すようにする。

上位モジュールは顧客データを取り出す場合、一括して取り出すことは避け、必要な件数だけを分割して取り出すことにより、メモリ不足になることを回避することが可能となる。

本発明によれば、分割検索処理途中の分割検索結果情報、および最終検索結果情報をビット配列で管理するため、消費メモリを節約し、効率的な検索が可能となる。

以下、本発明の一実施形態に係る顧客情報抽出システムを、図面を参照して詳細に説明する。

図１は本実施形態による顧客情報抽出システムの全体構成を示す図、図２は本実施形態におけるキャッシュファイル作成部の動作フローチャート図、図３は仮想顧客識別子キャッシュファイル作成部の動作フローチャート図、図４は本実施形態における顧客情報抽出部の動作フローチャート図、図５は本実施形態における顧客識別子取得部の動作フローチャート図である。

本実施形態による大量データ顧客情報抽出システムは、図１に示す如く、ＣＲＴ（Cathode Ray Tube）等からなるディスプレイ（表示装置）１と、ポインティングデバイス（入力装置）としてのキーボードマウス２と、ＣＰＵ（Central Processing Unit）を具備して蓄積プログラム方式による処理を行う制御部３と、ＨＤＤ（Hard Disk Driver）等からなる外部記憶装置４と、メインメモリからなるメモリ５とを有する。

本実施形態による大量データ顧客情報抽出システムは、さらに、コンピュータ・ネットワークを介して、顧客の属性情報が格納された顧客属性ＤＢ６ｂと、顧客の注文履歴情報が格納された注文情報ＤＢ６ｃと、それらのＤＢの格納位置やアクセス方法を記載したリポジトリＤＢ６ａを有する。

図１３はリポジトリＤＢ６ａの一例を示す図であり、この例では、情報ソース名，データベース名，ユーザＩＤ，パスワード，ＤＳＮ，ＤＢＭＳ，ＯＳ，ドライブタイプなどのデータを有している。

図１４は顧客属性ＤＢ６ｂの一例を示す図であり、この例では、顧客識別子（ＣｕｓｔＩＤ），氏名，住所，年齢，性別などのデータを有している。

図１５は注文情報ＤＢ６ｃの一例を示す図であり、この例では、注文識別子（OrderID），顧客識別子（CustID），注文日，商品ＩＤ，商品名，価格，個数のデータを有している。

制御部３は、キャッシュファイル作成部３ａと、仮想顧客識別子キャッシュファイル作成部３ｂと、顧客情報抽出部３ｃと、顧客識別子取得部３ｄを有する。これら各部は、対応するプログラムを、ＣＰＵで実行することにより所望の機能を実現する。これらのプログラムは、ＣＤ−ＲＯＭ，ＤＶＤ，ＦＤなどの記録媒体あるいはインターネットなどのネットワークを介して外部記憶装置４に一旦保存され、制御部３に取り込まれて実行される。

外部記憶装置４は、パラメータファイル４ａ（詳細は図６を用いて後述する）と、キャッシュファイル４ｂ（詳細は図７を用いて後述する）と、リンクインデックスファイル４ｃと、仮想顧客識別子キャッシュファイル４ｄ（詳細は図８を用いて後述する）とを保持する。

パラメータファイル４ａは、リポジトリＤＢ６ａ（図１３参照）にアクセスするために必要なパラメータと、キャッシュするデータベース列の情報を持つ。パラメータファイル４ａは事前に作成しておき、キャッシュファイル作成時と顧客情報抽出時には、参照のみ行う。

キャッシュファイル４ｂは、顧客属性ＤＢ６ｂ、注文情報ＤＢ６ｃに格納されているデータを保持する。キャッシュファイル４ｂは、キャッシュファイル作成時に作成され、顧客情報抽出時に参照される。

リンクインデックスファイル４ｃは、リレーショナルデータベースの外部参照に基づき、ある表のある位置のデータが別の表のどの位置に対応するかという対応付けの情報をキャッシュファイルにしたファイルである。このファイルは、あるキャッシュでの検索結果を、別の表の検索結果に変換するときに使用する。

リンクインデックスファイル４ｃは、キャッシュファイル作成時に作成され、顧客情報抽出時に参照される。仮想顧客識別子キャッシュファイル４ｄは、顧客属性ＤＢ６ｂ、および注文情報ＤＢ６ｃに記録されている全ての顧客識別子（CustID）の値に対応するキャッシュファイルである。顧客属性ＤＢ６ｂ、注文情報ＤＢ６ｃにおける顧客識別子（CustID）の値は、必ずこの仮想顧客識別子キャッシュファイル内にある。

仮想顧客識別子キャッシュファイル４ｄも、顧客属性ＤＢ６ｂ（図１４参照）、注文情報ＤＢ６ｃ（図１５参照）における顧客識別子（CustID）からみれば、リレーショナルデータベースの関連付けができるので、顧客属性ＤＢ６ｂ、注文情報ＤＢ６ｃにおける顧客識別子（CustID）についてリンクインデックスファイルを作成することができる。仮想顧客識別子キャッシュファイル４ｄは、キャッシュファイル作成時に作成し、顧客情報抽出時に参照する。

メモリ５は、キャッシュ情報管理テーブル５ａと、条件式内部形式５ｂと実行スタック５ｃと、ビット配列テーブル５ｄと、その他のシステムが実行する各種処理に必要なデータを格納するためのデータ格納領域（図示せず）を有する。

キャッシュ情報管理テーブル５ａは、現在キャッシュされているデータベースのアクセス情報とキャッシュする列とキャッシュファイル名の情報が格納されている。詳細は図９を用いて後述する。本テーブルは、キャッシュファイル作成時と顧客情報抽出時ともに初期処理で作成され、以降、このテーブルを参照して処理を進めていく。

条件式内部形式５ｂは、顧客情報抽出時にユーザが指定した検索条件式の文字列を解釈した結果を格納しておくテーブルである。詳細は図１１を用いて後述する。

実行スタック５ｃは、条件式内部形式５ｂを１行ずつ実行した検索結果のビット配列をスタック形式で一時的に格納しておくテーブルである。詳細は図１２を用いて後述する。

ビット配列テーブル５ｄは、検索結果の情報を保持しておくテーブルである。ビット配列の他にどの表に関する検索結果かを表す対象表の情報を保持する。詳細は図１２を用いて後述する。

本システムでは、ユーザは、まずキャッシュしたいデータベース列、つまり検索条件の対象となるデータ項目の列をパラメータファイルに記述し、キーボードマウス２からキャッシュファイル作成の要求を出す。

キャッシュファイルが作成された後で、検索条件式文字列を指定して顧客情報抽出要求を行う。顧客情報抽出が終了したら、検索された顧客識別子をメモリ不足にならない程度に何回かに分けて取得する。

図６は、図１のパラメータファイル４ａの内容の一例を示す図である。
図６において、１行目はキャッシュファイルを作成する先のディレクトリパスを示す。本例では、本システムを実行するパソコンの「ｄドライブのCacheDirディレクトリ」の下にキャッシュファイルを作成することを示している。

２行目以降は、各々、キャッシュするデータベース表と、データベースの情報ソース名、キャッシュする列名、キャッシュするレコードを制限するための条件式を指定する。ここで、情報ソース名は、データベースの格納先のサーバやＤＢへのアクセス方法を定義した名前を表す。

図６の３行目を例にとって具体的に説明すると、「注文テーブル」がデータベース表名、「注文マスタ」が情報ソース名、「注文ID（OrderID）/顧客ID（CustID）/注文日」が列名、「注文日 <= '2003/01/01' and 注文日 >= '2003/12/31'」がキャッシュの際に必要なレコードをキャッシュする条件式を表す。

図７は、キャッシュファイルのデータ構造の一例を示す図である。
キャッシュファイルは、パラメータファイルで指定された１つのデータベース表の１つの列に関するデータが格納されたファイルであり、その列が固定長ならインデックスファイルとデータファイルの２ファイル、可変長ならインデックスファイルとデータファイルとオフセットファイルの３ファイルが作成される。

ここで、固定長とは、データの長さがデータの内容に関係なく一定のデータを表す。例えば整数型のデータは4バイトで固定なので固定長である。可変長とはデータの長さがデータ毎に異なるデータを表す。例えば文字列型のデータは可変長にあたる。

データファイルとインデックスファイルとオフセットファイルの各々について説明する。

データファイルには、データが昇順に並べかえられて格納されている。並べかえはデータ抽出の際バイナリサーチが行えるようにするためである。

インデックスファイルは、キャッシュ上のデータが元々ＤＢ表の何番目のレコードにあるかを格納したファイルである。インデックスファイルの内容は、何番目にあるかの位置の情報が格納され、データベース表のレコード件数分存在し、１件あたり４バイト使用する。また先頭は０番目で始まるものとして説明する。

オフセットファイルは、データファイルの指定位置が先頭から何バイト目にあるかを表すファイルである。これは可変長データがデータファイルに格納されている場合、格納位置を突き止めるのに使用する。オフセットファイルの内容は、指定データの先頭オフセットが格納され、データベース表のレコード件数分＋１件存在し、１件あたり４バイト使用する。またデータの長さは直後のオフセットから自分のオフセットを差し引いた値で求める。

図７を例にして具体的に説明すると、キャッシュ上で３番目のレコードが検索された場合、その値とＤＢ表でのレコード位置を求めるのは次のようにする。オフセットファイルの３番目と４番目を見ると、「１２」と「１８」が格納されているので、オフセットは１２バイト、長さは１８−１２＝６バイトになる。

そこで、データファイルの１２バイト目から６バイトを参照すると「北海道」を取り出すことができる。またインデックスファイルの３番目を参照すると「０」が格納されているのでＤＢ表の先頭レコードであることが分かる。

なお、固定長データの場合は、データ長がわかっているので、そこからデータファイルの格納位置を突き止めることができるため、オフセットファイルは不要である。

図８は、仮想顧客識別子キャッシュファイルを説明するための図である。
複数のデータベースに対して連携して検索処理をする場合、各々のデータベース毎に顧客識別子が記録管理されている。したがって、各々のデータベースからそれぞれの顧客識別子をキャッシュするだけでは顧客識別子の一元管理ができないので、各々のデータベースにある顧客識別子をすべて保持する顧客識別子データベース表が存在するものと仮定して、その仮想顧客識別子データベース表のキャッシュファイルを作成する。

この仮想顧客識別子データベース表は、顧客識別子列からのみ構成され、このキャッシュファイルを仮想識別子キャッシュファイルと呼ぶことにする。

各々のデータベースシステムにおける顧客識別子を含む表は、前記の仮想顧客識別子データベース表と仮想的な参照関係があると考え、リンクインデックスファイルを作成する。仮想顧客識別子キャッシュファイルは、データファイルとオフセットファイルを作成する。仮想顧客識別子キャッシュファイルのデータファイルの並びはソート済みであるとするので、インデックスファイルは不要である。

図８において、データベースシステム２の３番目の顧客識別子「ID7」が検索でヒットした場合、それが仮想顧客識別子データベース表の何番目に当たるかを説明する。データベースシステム２のリンク先インデックスファイルの６番目と７番目に「4」と「4」が格納されている。したがって、仮想顧客識別子データベース表のデータファイルの４番目から４番目を参照すると、「ID７」が格納されていることが分かる。したがって仮想顧客識別子データベース表の4番目に当たることが分かる。

図９は、キャッシュ情報管理テーブルの階層構造を示す図である。
図９において、全体管理には、キャッシュ全体に関する情報を持っている。パラメータファイルパス、キャッシュファイルパス、情報ソースの一覧、仮想情報ソース、仮想データベース表、仮想顧客識別子の情報を格納する。

情報ソースには、情報ソースに関する情報を持っている。情報ソース名、データベース表の一覧の情報を格納する。

データベース表には、キャッシュするデータベースの情報を持っている。データベース名、列の一覧、リンク先のデータベース表、キャッシュするときの条件式、キャッシュされたレコード数の情報を格納する。

列には、データベース列の情報を持っている。列名、データ型、リンク先列、顧客識別子かどうかの情報、キャッシュされたnullレコードの件数、各種キャッシュファイル名の情報を格納する。

図１０は、顧客情報抽出時にユーザが指定する条件式の一例を示す図である。
同図において、情報ソースとは、キャッシュにする前のデータベースの情報を表す。図１０の例では、顧客マスタ，注文マスタが該当する。

条件式は、指定情報ソースに格納されているデータベース列の条件式を表す。条件式は左辺／比較演算子／右辺からなり、左辺にデータベース列、右辺に定数を指定する。条件は複数指定可能であり、複数の条件を条件結合でつなぐ。

図１０では、条件式の内容は「30才以上の男で2000円以上の商品を買った人を検索する」になる。

図１１は、条件式内部形式のデータ構造の一例を示す図である。
同図において、条件式内部形式とは、ユーザから指定された顧客情報抽出条件式を構文解釈したデータである。条件式内部形式は、種別、条件式、情報ソース、グルーピングから構成される。

種別にはその行が式なのか条件結合なのかを表す値が格納されている。
条件式には、種別が式なら条件式、種別が条件結合なら条件結合の内容が格納される。情報ソースには種別が条件式の場合にその情報ソースが格納される。

グルーピングには、キャッシュの検索を実施する順序が格納される。グルーピングが同じ番号が連続する単位で検索が実施される。グルーピングが-1なら、実行スタックに積まれた検索結果を結合する処理を行う。条件式内部形式は後置記法で表現される。

図１１の例は、顧客マスタから持ってきたキャッシュファイルを使って30才以上の男を検索し、注文マスタからもってきたキャッシュファイルを使って2000円以上の商品を買ったことのある人を検索し、両者の共通顧客を求める、という意味になる。

図１２は、実行スタックおよびビット配列テーブルのデータ構造を示す図である。
同図において、実行スタックは、検索処理を別々に行った結果を一時的に格納する領域である。条件式内部形式を実行の際、グルーピングの値が同じものが連続する単位でキャッシュ検索し、その結果を実行スタックに積む。もしグルーピングの値が-1なら実行スタックから上位２つの検索結果を取り出し、条件式欄に格納されている条件結合で検索結果の結合処理を行い、その結果を新たな検索結果として実行スタックに戻す。

同図において、ビット配列テーブルは、検索結果を１レコード１ビットで表現したテーブルである。検索でヒットしたレコードの対応するビットを“１”、そうでないなら“０”にする。

以下、制御部３の各処理部の処理、すなわち、キャッシュファイル作成部３ａの処理、仮想顧客識別子キャッシュファイル作成部３ｂの処理、顧客情報抽出部３ｃの処理、顧客識別子取得部３ｄの処理を、それぞれ図２〜図５のフローチャートを用いて詳細に説明する。

図２は、キャッシュファイル作成部３ａの処理フローチャートである。キャッシュファイルの作成は顧客情報抽出の前に予め行っておく。本処理は、ユーザがキーボードマウス２でキャッシュファイル作成を要求したときに呼び出される。

図２では、まず、パラメータファイル４ａ（図６参照）の内容を参照し、リポジトリＤＢ６ａ（図１３参照）にアクセスするのに必要な情報を入手し、リポジトリＤＢ６ａにアクセスする。そして顧客属性ＤＢ６ｂ（図１４参照）と注文情報ＤＢ６ｃ（図１５参照）にアクセスするための情報を入手する（ステップＳ２０１）。

次に、キャッシュ情報管理テーブル５ａ（図９参照）を作成する。キャッシュ情報管理テーブル５ａには、ステップＳ２０１で取得したデータベースのアクセス情報を格納し、またパラメータファイル４ａ（図６参照）にはキャッシュするデータベース列も指定されているのでその情報も格納する。また、データベース名と列名の情報からキャッシュファイルの一意な名前を作成し、これもキャッシュ情報管理テーブルに格納する（ステップＳ２０２）。

次に、キャッシュ情報管理テーブル５ａ（図９参照）を見て、顧客属性ＤＢ６ｂ（図１４参照）と注文情報ＤＢ６ｃ（図１５参照）にアクセスし、キャッシュするデータを取得し、キャッシュファイル４ｂ（図７参照）に出力する（ステップＳ２０３）。キャッシュファイル４ｂは、キャッシュするデータベース列単位に別々に作成する。

次に、作成したキャッシュファイルについて、バイナリサーチが行えるように昇順ソートを行う（ステップＳ２０４）。

図３は、仮想顧客識別子キャッシュファイル作成部３ｂの処理フローチャートである。本処理はキャッシュファイル作成部３ａの上記処理が終了すると呼び出される。

図３では、まず、キャッシュ情報管理テーブル５ａを見て、顧客識別子をデータとして持っているキャッシュファイル名を取得する（ステップＳ３０１）。顧客識別子をデータとして持っているキャッシュファイルは、１データベースで１個なので、本実施例の場合なら、顧客属性ＤＢ６ｂのキャッシュで１個、注文情報ＤＢ６ｃのキャッシュで１個、都合２個見つかる。

続いて、見つけたキャッシュファイルに格納されているデータをマージし、その結果を仮想顧客識別子キャッシュファイル４ｄ（図８参照）に出力する（ステップＳ３０２）。マージする際に重複する顧客識別子は排除する。

最後に、顧客識別子の各キャッシュについてリンクインデックスファイルを作成する（ステップＳ３０３）。このファイルは、顧客情報抽出時に顧客識別子の各キャッシュの検索結果を、仮想顧客識別子キャッシュファイルの検索結果に変換する場合に参照される。

図４は、顧客情報抽出部３ｃの処理フローチャートである。本処理は、ユーザがキーボードマウス２で抽出条件式文字列を渡して顧客情報抽出要求を行ったときに呼び出される。

図４では、まず、パラメータファイル（図６参照）を参照しリポジトリＤＢ（図１３参照）から読み込む（ステップＳ４０１）。次に、キャッシュ情報管理テーブルを作成する（ステップＳ４０２）。ステップＳ４０１とステップＳ４０２は、キャッシュファイル作成処理３ａのステップＳ２０１とステップＳ２０２と同じである。

次に、指定された抽出条件文字列を解釈し、内部形式に変換し、変換結果を条件式内部形式５ｂ（図１１参照）に格納する（ステップＳ４０３）。内部形式は後置記法で表現することで括弧を排除し、条件式と条件結合（ＡＮＤ、ＯＲなど）を積み上げた配列形式で管理する。

次に、内部形式を１件ずつ取り出して評価する（ステップＳ４０４）。もし取り出したものが条件式なら、その条件式で対応するキャッシュファイルを検索する（ステップＳ４０６）。検索結果は、キャッシュファイルのデータのソート前でのレコード位置をビット配列５ｄの対応するビット位置を“１”（ＯＮ）にすることで情報を保持する。

次に、ビット配列テーブル５ｄ（図１２参照）を実行スタック５ｃに積む（ステップＳ４０７）。その場合、そのビット配列がどのデータベース表に属していたかの情報もスタックに格納しておく。

内部形式を取り出したとき、それが条件結合の場合、実行スタック５ｃに格納されているビット配列２個を取り出す（ステップＳ４０８）。次に、それらのビット配列の対象のデータベース表が同じかどうかをチェックして、もし異なるなら同じ表になるまでビット配列の変換処理を行う（ステップＳ４０９）。ビット配列の変換処理ではリンクインデックスファイル４ｃを参照する。

対象のデータベース表が同じになったら、双方のビット配列に対して条件結合を適用する。そして結合結果のビット配列を新たな検索結果として実行スタック５ｃに積む。このような処理を内部形式の末尾まで繰り返す（ステップＳ４１１）。

内部形式の末尾まで達すると、実行スタックには１個だけビット配列が格納されているのでこれを取り出す（ステップＳ４１２）。取り出したビット配列の対象のデータベース列が仮想顧客識別子かどうかをチェックし、もし仮想顧客識別子でないならリンクインデックスファイル４ｃを使って、検索結果のビット配列の変換処理を仮想顧客識別子になるまで繰り返す（ステップＳ４１３）。
このようにしてできたビット配列が検索結果になる。

ここで、上記のステップＳ４０９、ステップＳ４１３のビット配列の変換処理について詳しく説明する。

説明のための前提として、データベースシステム１が顧客テーブル（図１４参照）、データベースシステム２が注文テーブル（図１５参照）に対応しているとする。以下、図８を参照しながら説明する。

顧客テーブル（データベースシステム１）に３レコード格納されていて、その中の顧客ID列値がID1,ID2,ID3とし、注文テーブル（データベースシステム２）に４レコード格納されていて、その中の顧客ID列値がID2,ID3,ID5,ID7とする。仮想データデース表の顧客識別子キャッシュは、上記がマージされソートされるので、ID1,ID2,ID3,ID5,ID7となる。

リンク先インデックスファイルは、以下の２ファイルが作られる。これらのファイルは、仮想顧客識別子データデース表に対する仮想顧客識別子キャッシュ作成時に作成される。
（イ）顧客テーブルの顧客IDから仮想データデース表の顧客識別子
（ロ）注文テーブルの顧客IDから仮想データデース表の顧客識別子

顧客テーブルを例に取ると、ID1は顧客識別子キャッシュの0番目にあり、ID2、ID3は各々１番目、２番目にあるので、[0,0,1,1,2,2]が格納される。格納情報は、(開始位置、終了位置)を１組として格納するので、３レコードの倍の６個格納することになる。

検索時に「３０才以上の男」を検索したとして、顧客テーブルの１番目と２番目がヒットしたとすると、ビット配列は[011]となる。

「２０００円以上の商品を買った人」を検索したとして、注文テーブルの１番目と２番目がヒットしたとするとビット配列は、[0110]となる。この値を使ってステップＳ４０９を説明する。

ステップＳ４０９のビット配列の変換処理は、以下のとおり。
（ａ）[011]の変換後のビット配列のメモリ領域を用意し、０クリアする。仮想顧客識別子データベース表は、５レコードあるので[00000]となる。

（ｂ）[011]を左から順に見てビットがＯＮの位置を探す。１番目のビットがＯＮなので、リンク先インデックスファイルの1×2=２番目、1×2+1=３番目のフィールドを見ると、1と1が格納されているので、変換後のビット配列の1番目をＯＮにする。変換後のビット配列は、[01000]となる。

（ｃ）[011]の次のビットＯＮ位置を探して、上記（ｂ）の処理を繰り返す。
最終的に変換後のビット配列は[01100]となる。

（ｄ）注文テーブル（データベースシステム２）についても、変換後のビット配列のメモリ領域を別途用意し、上記（ａ）（ｂ）（ｃ）の処理を行う。変換後のビット配列は、[00110]となる。
上記（ａ）〜（ｄ）がビット変換処理（ステップＳ４０９）の説明である。

ステップＳ４１３は、例えば条件式が１個しかなかった場合には、検索結果のビット配列が、仮想顧客識別子データベース表に対応するビット配列なっていないので、仮想顧客識別子データベース表に対応させるための処理があり、変換処理の方法は、上記（ａ）（ｂ）（ｃ）の処理と同じである。

図５は、顧客識別子取得部３ｄの処理フローチャートである。本処理は、顧客情報抽出部３ｃの上記処理が終了したあと、顧客識別子をユーザが取得したいときに呼び出される。呼び出しでは、全件取得によるメモリ不足を避けるため、ユーザから必要な件数が指定される。

図５では、まず、ビット配列のうちビットＯＮになっている位置を探し見つかったらその位置を取得する（ステップＳ５０１）。次に、仮想顧客識別子キャッシュファイルの指定位置にあるデータを取り出して（ステップＳ５０２）、上位モジュールに返却する。

このようにして、メモリ上には検索結果のビット配列と必要件数だけの顧客識別子のエリアが存在することになり、極力消費メモリを節約できる。

本実施形態では、分散しているデータベースは顧客属性ＤＢ６ｂ、注文情報ＤＢ６ｃと２個の場合で説明したが、それ以上の個数の場合であっても同様に実施できる。

なお、上記実施形態における制御部３の各処理部の処理、すなわち、キャッシュファイル作成部３ａ（キャッシュファイル作成手段）の処理（図２参照）、仮想顧客識別子キャッシュファイル作成部３ｂ（仮想顧客識別子キャッシュファイル作成手段）の処理（図３参照）、顧客情報抽出部３ｃ（情報抽出手段）の処理（図４参照）、顧客識別子取得部３ｄ（データ取得手段）の処理（図５参照）は、対応するプログラムをＣＰＵで実行することにより行われる。このプログラムは、それぞれ図２、図３、図４、図５のフローチャートに示す処理をプログラムコード化したものであり、ＣＤ−ＲＯＭ、ＤＶＤ、ＦＤなどの記録媒体に格納して配布したり、インターネットなどのネットワークを介してユーザに配布することにより普及することができる。

本発明は、複数のデータベースが分散している環境で、顧客情報を抽出するシステムに適用できる。

本発明の一実施形態による大量データ顧客情報抽出システムの全体構成を示す図である。 本実施形態におけるキャッシュファイル作成部の動作フローチャート図である。 本実施形態における仮想顧客識別子キャッシュファイル作成部の動作フローチャート図である。 本実施形態における顧客情報抽出部の動作フローチャート図である。 本実施形態における顧客識別子取得部の動作フローチャート図である。 パラメータファイルの内容の一例を示す図である。 キャッシュファイルの内容の一例を示す図である。 仮想顧客識別子キャッシュファイルの内容の一例を示す図である。 キャッシュ情報管理テーブルの内容の一例を示す図である。 顧客情報抽出条件式の内容の一例を示す図である。 条件式内部形式の内容の一例を示す図である。 実行スタックおよびビット配列テーブルの内容の一例を示す図である。 リポジトリデータベース（ＤＢ）の内容の一例を示す図である。 顧客属性データベース（ＤＢ）の内容の一例を示す図である。 注文情報データベース（ＤＢ）の内容の一例を示す図である。

符号の説明

１：表示部、２：入力部、３：制御部、３ａ：キャッシュファイル作成部、３ｂ：仮想顧客識別子キャッシュファイル作成部、３ｃ：顧客情報抽出部、３ｄ：顧客識別子取得部、４：外部記憶装置、４ａ：パラメータファイル、４ｂ：キャッシュファイル、４ｃ：リンクインデックスファイル、４ｄ：仮想顧客識別子キャッシュファイル、５：メモリ、５ａ：キャッシュ情報管理テーブル、５ｂ：条件式内部形式、５ｃ：実行スタック、５ｄ：ビット配列テーブル、６ａ：リポジトリＤＢ、６ｂ：顧客属性ＤＢ、６ｃ：注文情報ＤＢ

Claims (5)

1. ネットワーク上に分散している複数のデータベースを連携して検索条件に合致するデータを検索する複合データベース検索システムであって、
   前記複数のデータベースの列情報を格納したキャッシュファイルを作成するキャッシュファイル作成手段と、
   前記キャッシュファイルのデータをマージ・ソートした仮想識別子キャッシュファイルを作成する仮想識別子キャッシュファイル作成手段と、
   指定された検索条件にしたがって前記キャッシュファイルを検索するとともに、レコード位置を１ビットに対応させ、前記検索ステップで検索した結果、前記検索条件に一致したレコード位置のビットを“１”で表し、一致しないレコード位置のビットを“０”で表したビット配列テーブルを作成する情報抽出手段と、
   前記ビット配列テーブルからビットが“１”の位置を取得し、前記仮想識別子キャッシュファイルから前記ビットが“１”の位置に対応するデータを取得するデータ取得手段と
   を有することを特徴とする複合データベース検索システム。
2. 前記複数のデータベースは、顧客識別子と氏名と住所と年齢と性別を含む顧客属性データベース、および、顧客識別子と注文日と商品識別子と価格を含む注文情報データベースであり、前記マージ・ソートは、顧客識別子を用いて重複を排除して実行されることを特徴とする請求項１記載の複合データベース検索システム。
3. ネットワーク上に分散している複数のデータベースを連携して検索条件に合致するデータを検索する複合データベース検索方法であって、
   前記複数のデータベースの列情報を格納したキャッシュファイルを作成するキャッシュファイル作成ステップと、
   前記キャッシュファイルのデータをマージ・ソートした仮想識別子キャッシュファイルを作成する仮想識別子キャッシュファイル作成ステップと、
   指定された検索条件にしたがって前記キャッシュファイルを検索するとともに、レコード位置を１ビットに対応させ、前記検索ステップで検索した結果、前記検索条件に一致したレコード位置のビットを“１”で表し、一致しないレコード位置のビットを“０”で表したビット配列テーブルを作成する情報抽出ステップと、
   前記ビット配列テーブルからビットが“１”の位置を取得し、前記仮想識別子キャッシュファイルから前記ビットが“１”の位置に対応するデータを取得する情報取得ステップと
   を有することを特徴とする複合データベース検索方法。
4. 前記複数のデータベースは、顧客識別子と氏名と住所と年齢と性別を含む顧客属性データベース、および、顧客識別子と注文日と商品識別子と価格を含む注文情報データベースであり、前記マージ・ソートは、顧客識別子を用いて重複を排除して実行されることを特徴とする請求項３記載の複合データベース検索方法。
5. ネットワーク上に分散している複数のデータベースを連携して検索条件に合致するデータを検索する複合データベース検索用プログラムであって、
   コンピュータを、前記複数のデータベースの列情報を格納したキャッシュファイルを作成するキャッシュファイル作成手段と、前記キャッシュファイルのデータをマージ・ソートした仮想識別子キャッシュファイルを作成する仮想識別子キャッシュファイル作成手段と、指定された検索条件にしたがって前記キャッシュファイルを検索するとともに、レコード位置を１ビットに対応させ、前記検索ステップで検索した結果、前記検索条件に一致したレコード位置のビットを“１”で表し、一致しないレコード位置のビットを“０”で表したビット配列テーブルを作成する情報抽出手段と、前記ビット配列テーブルからビットが“１”の位置を取得し、前記仮想識別子キャッシュファイルから前記ビットが“１”の位置に対応するデータを取得するデータ取得手段として機能させるための複合データベース検索用プログラム。

Images