JP2005157773A - データベース検索装置、データベース検索方法、プログラム及び記録媒体 - Google Patents

Abstract

【課題】 スキーマの最適化を図る上で同一のデータテーブルを複数作成する必要がなくなり、記憶容量の使用量を抑えることを可能とする。
【解決手段】 データベース検索サーバ２００は、クライアントＰＣ１００から受信した検索条件に応じて、異なる複数のデータテーブルから一又は複数のデータテーブルを選択し、選択したデータテーブルから成るスキーマを決定する。そして、データベース検索サーバ２００は、決定したスキーマのデータベースを対象に、当該検索条件によるデータ検索を行う。
【選択図】 図１

Description

本発明は、複数のデータテーブルを有するデータベースに対する検索を行うデータベース検索に関し、特に、複数のスキーマを有するデータベースに対するデータ検索を行うためのデータベース検索装置、データベース検索方法、プログラム及び記録媒体に関する。

データウェアハウスとして用いられる、複数のデータテーブルから構成されるデータベースに対するデータベース検索システムにおいては、データベースの管理者等が定義するスキーマによりデータベースが構築されている。そして、ユーザがデータベースに対する検索を行う場合には、データベース自由検索ツールがユーザの入力する検索及び出力の条件からデータベースのスキーマに合わせたクエリを生成してデータベースへの検索を行ってデータ出力をするものである。

従来のデータベース検索システムにおいては、入力される検索に係わる条件の全てを満たすことが可能な画一的なスキーマを定義し、そのためのファクトテーブルを1つ用意しているために簡単な検索を行うだけでもクエリ実行時間の最適化を図ることができなかった。

そこで、例えば特許文献１においてはユーザ利用方法にスキーマが合わない課題を解決するために、ユーザ利用状況情報としてＳＱＬ（Structured Query Language）を保存し、ユーザのスキーマ利用パターンを導き出し、設定されているチューニング目標（スループット、記憶容量等）に合わせて最適なスキーマパターンを生成して用いるものである。

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

しかしながら、特許文献１に記載のデータベースシステムにおいては、スキーマパターンを最適化して用いることは可能であるが、最適化の仕組みをデータベースのＲＤＢＭＳの機能として持つためには非常に高価なデータベースの導入が必要となる。これらの高価なデータベースにおいてはキューブ等の名称で呼ばれるデータベースを構築しなくてはならないが、その場合同一のデータテーブルを複数作成する必要があり、無駄な記憶容量を必要とする。

また、更には、特許文献１ではスキーマは最適化することが可能となるが、クエリの生成は最適化されないので簡単な検索を最適化されたスキーマを用いて行う場合でも画一的なクエリ生成を行うので、クエリ生成において無駄な処理を行うという欠点もあった。

本発明は、上記問題点に鑑みてなされたものであり、データベース構成（スキーマ）の最適化を図る上で同一のデータテーブルを複数作成する必要がなくなり、記憶容量の使用量を抑えることを可能とするデータベース検索装置、データベース検索方法、プログラム及び記録媒体を提供することを目的とする。

また、本発明は、更にデータ検索要求情報（クエリ）の生成処理を最適化することが可能なデータベース検索装置、データベース検索方法、プログラム及び記録媒体を提供することを目的とする。

斯かる目的を達成するために、本発明のデータベース検索装置は、データの検索条件を入力する検索条件入力手段と、前記検索条件入力手段により入力された前記検索条件に応じて、異なる複数のデータテーブルから一又は複数のデータテーブルを選択し、選択した前記一又は複数のデータテーブルから成るデータベース構成を決定するデータベース構成決定手段と、前記データベース構成決定手段により決定された前記データベース構成を対象に、前記検索条件によるデータ検索を行うデータ検索手段とを有することを特徴とする。

本発明のデータベース検索方法は、データベース検索装置によるデータベース検索方法であって、データの検索条件を入力する検索条件入力ステップと、前記検索条件入力ステップにより入力された前記検索条件に応じて、異なる複数のデータテーブルから一又は複数のデータテーブルを選択し、選択した前記一又は複数のデータテーブルから成るデータベース構成を決定するデータベース構成決定ステップと、前記データベース構成決定ステップにより決定された前記データベース構成を対象に、前記検索条件によるデータ検索を行うデータ検索ステップとを含むことを特徴とする。

本発明のプログラムは、前記データベース検索方法をコンピュータに実行させることを特徴とする。また、本発明のコンピュータ読み取り可能な記録媒体は、前記プログラムを記録したことを特徴とする。

本発明によれば、検索条件に応じて、異なる複数のデータテーブルから一又は複数のデータテーブルを選択し、選択したデータテーブルから成るデータベース構成を決定するように構成したので、データベース構成の最適化を図る上で同一のデータテーブルを複数作成する必要がなくなり、記憶容量の使用量を抑えることが可能となる。

また、本発明によれば、最適化されたデータベース構成に応じたデータ検索要求情報を生成するように構成したので、最適化され、例えば、少ないデータテーブルで構成されるデータベース構成が検索対象となった場合、それに応じてデータ検索要求情報も余計な情報が省かれ、データ検索要求情報の生成処理も最適化することが可能となる。

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

図１は、本発明の一実施形態に係るデータベース検索システムの構成を模式的に示した図である。
１００は、ユーザが操作するクライアントＰＣであり、Ｗｅｂブラウザを用いて後述のデータベース検索サーバ２００から送信されるＷｅｂページを画面上で表示する。２００は、自由検索アプリケーション２１及び各種データを記録した自由検索ＤＢ（自由検索データベース）２２を備えたデータベース検索サーバであり、自由検索アプリケーション２１によりクライアントＰＣ１００の要求に応じたデータを自由検索ＤＢ２２から検索し、その結果をＷｅｂページで各クライアントＰＣ１００に送信する。３００は、システムＤＢサーバであり、自由検索ＤＢ２２に格納すべきデータを逐次或いはバッチ処理によりデータベース検索サーバ２００に対して送信する。

データベース検索サーバ２００に接続される各クライアント１００は、所望の出力データ項目を指定する出力条件及びその検索条件を画面上で入力し、その入力内容をデータベース検索サーバ２００に対して送信する。当該入力内容を受けたデータベース検索サーバ２００は、出力条件に挙げられたデータのうち検索条件に合致するデータを自由検索ＤＢ２２から取得する。なお、出力条件もデータを検索するための条件であるので、出力条件の概念に含まれる。従って、以下の説明では、出力条件も含む意味で検索条件という用語を用いるものとする。

次に、データベース検索サーバ２００は、取得したデータを例えばＣＳＶ（Comma Separated Value）データとしてクライアントＰＣ１００に返信し、当該クライアントＰＣ１００では検索結果を画面上で確認することが可能となる。

図２は、データベース検索サーバ２００のハードウェア構成を示す図である。
ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ(Basic Input / Output System)やオペレーティングシステムプログラム（以下、ＯＳ）や、データベース検索サーバ２００の実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものであり、本発明には直接関係があるものではない。メモリコントローラ（ＭＣ）２０７は、ブートプログラム、ブラウザソフトウェア、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、各種データ等を記憶するハードディスク（ＨＤ）やフレキシブルディスク（ＦＤ）或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（Ｒ）メモリ等の外部メモリ２１１へのアクセスを制御する。

通信Ｉ／Ｆコントローラ（通信Ｉ／ＦＣ）２０８は、ネットワークを介して、外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いたインターネット通信等が可能である。なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

クライアントＰＣ１００のハードウェア構成もデータベース検索サーバ２００と同様であり、外部メモリ２１１に格納されているプログラム等が異なるものである。

次に、本実施形態において用いられるデータテーブルについて説明する。
本実施形態では、図３に示すように、２つのマスタテーブルと３つのトランザクションテーブルを夫々、検索対象となるデータベースの一構成として用いる。マスタテーブルには、得意先マスタテーブルと商品マスタテーブルがあり、トランザクションテーブルには、実績トランザクションテーブル、得意先集計トランザクションテーブル及び商品集計トランザクションテーブルがある。得意先集計トランザクション及び商品集計トランザクションテーブルは、得意先毎又は商品毎のデータ検索速度を向上させるために、夜間バッチ処理等でＤＢサーバ３００内において実績トランザクションテーブルに基づいて作成されるデータテーブルであり、トランザクションテーブルの年月レコードを得意先、商品毎の上期、下期レコードに集計する。

得意先マスタテーブルは、得意先コードを記録した得意先ＣＤ項目及び得意先名を記録した得意先名項目によって構成される。商品マスタテーブルは、商品コードを記録した商品ＣＤ項目及び商品名を記録した商品名項目によって構成される。

実績トランザクションテーブルは、販売を行った年月を記録した年月項目、得意先コードを記録した得意先ＣＤ項目、商品コードを記録した商品ＣＤ項目、販売数を記録した販売数項目及び販売金額を記録した販売金額項目によって構成される。

得意先集計トランザクションテーブルは、得意先コードを記録した得意先ＣＤ項目、上期販売数を記録した上期販売数項目、上期販売金額を記録した上期販売金額項目、下期販売数を記録した下期販売数項目及び下期販売金額を記録した下期販売金額項目によって構成される。

商品集計トランザクションテーブルは、商品コードを記録した商品ＣＤ項目、上期販売数を記録した上期販売数項目、上期販売金額を記録した上期販売金額項目、下期販売数を記録した下期販売数項目及び下期販売金額を記録した下期販売金額項目によって構成される。

図４は、本実施形態において検索対象となる３つのスキーマ構造体のデータベースを示した図である。
図４に示すように、スキーマＩＤが"０"（以下、スキーマ０と略す。スキーマＩＤ"１"、"２"についても同様）のデータベースの構成は、スタースキーマ構造体である。スキーマ０は実績トランザクションテーブルをファクトテーブルとしており、得意先ＣＤ項目をキーにして、実績トランザクションテーブルと得意先マスタテーブル及び得意先集計トランザクションテーブルとが関連付けられ、商品ＣＤ項目をキーにして、実績トランザクションテーブルと商品マスタテーブル及び商品集計トランザクションテーブルとが関連付けられている。スキーマ０のデータベースは全てのデータテーブルを含む構成を有するため、全項目を検索の対象とすることができる。

スキーマ１のデータベースは、得意先マスタテーブル及び得意先集計トランザクションテーブルによって構成されており、本データベースを検索対象とした場合、得意先マスタテーブルと得意先集計トランザクションテーブルに含まれる項目のみを検索することができる。本データベース構造においては、得意先集計トランザクションテーブルをファクトテーブルとしており、得意先マスタテーブルと得意先集計トランザクションテーブルとは得意先ＣＤ項目をキーにして関連付けられている。

スキーマ２のデータベースは、商品マスタテーブル及び商品集計トランザクションテーブルによって構成されており、本データベースを検索対象とした場合、商品マスタテーブルと商品集計トランザクションテーブルに含まれる項目のみを検索することができる。本データベース構造においては、商品集計トランザクションテーブルをファクトテーブルとしており、商品マスタテーブルと商品集計トランザクションテーブルとは商品ＣＤ項目をキーにして関連付けられている。

図５（ａ）は、スキーマ構造体を定義したデータテーブル（以下、スキーマ定義テーブルと称す）を示している。
このスキーマ定義テーブルによってスキーマ０〜２のデータベース構成が定義されている。即ち、本スキーマ定義テーブルでは、スキーマ０については、ファクトテーブルである実績トランザクションテーブルに対して、４つのディメンジョンテーブル、得意先マスタテーブル、商品マスタテーブル、得意先集計トランザクションテーブル及び商品集計トランザクションテーブルが対応付けられており、スキーマ１については、ファクトテーブルである得意先集計トランザクションテーブルに対し、１つのディメンジョンテーブル、得意先マスタテーブルが対応付けられており、スキーマ２については、ファクトテーブルである商品集計トランザクションテーブルに対し、１つのディメンジョンテーブル、商品マスタテーブルが対応付けられている。

図５（ｂ）は、ファクトテーブルを定義したデータテーブル（以下、ファクトテーブル定義テーブルと称す）を示している。
ファクトテーブル定義テーブルによってスキーマ０〜２のデータベース構造におけるファクトテーブルが定義される。即ち、本ファクトテーブル定義テーブルにおいては、スキーマ０の場合は実績トランザクションテーブル、スキーマ１の場合は得意先集計トランザクションテーブル、スキーマ２の場合は商品集計トランザクションテーブルが夫々ファクトテーブルとなることを示している。尚、得意先マスタテーブル及び商品マスタテーブルについてはスキーマＩＤが"null"が対応付けられているが、これはマスタテーブルがファクトテーブルには成り得ないためである。また、スキーマ定義テーブル及びファクトテーブル定義テーブルは、例えばＲＡＭ２０３内に記録される。

尚、図５（ｂ）では、スキーマ０〜スキーマ２の３つのデータベース構成についてのみ例示した。上記５つ以外にもデータテーブルが増えた際には、データテーブルを組み合わせによる更に多様なデータベース構成を検索対象とすることができ、例えば、スキーマ３〜９のファクトテーブルについても（スキーマＩＤ＝１〜９：機能限定スキーマのファクトテーブル）定義し、同時に図５（ａ）のスキーマ定義テーブルへの登録を行うことでバリエーションを増やすことが可能であることは言うまでもない。

次に、データベース検索サーバ２００によるデータ検索動作について、図６−１及び図６−２を参照しながら説明する。図６−１及び図６−２は、本実施形態に係るデータベース検索サーバ２００の動作を示すフローチャートである。
本データベース検索動作において、ユーザの検索条件指定としては、例えば本願出願人による特願２００２−３８２４７０号に記載されるように複数のデータテーブルで構成されるデータベースに対し、１以上のデータテーブルで１以上の項目名を指定して検索指定条件を入力し、同様に１以上のデータテーブルで１以上の項目名を指定して表示指定条件（検索出力条件）として検索を行う仕組みを適用することが可能である。

−処理例１−
先ず、データベース検索サーバ２００による処理例１を説明する。ここでは、検索条件として「得意先コード（得意先CD='1001'）を指定して、得意先名を検索する」をクライアントＰＣ１００から受けた場合について説明する。

本処理例では、得意先コード及び得意先名を指定した検索条件をクライアントＰＣ１００から受けた場合を想定しているため、図７（ａ）に示すように、検索処理において利用される項目（以下、利用項目と称す）は、得意先コード項目及び得意先名項目となり、検索に利用されるテーブル（以下、利用テーブルと称す）は、得意先マスタテーブルとなる。ユーザは、クライアントＰＣ１００の画面上において表示される項目から所望の項目を選択する。選択された項目情報は検索条件としてクライアントＰＣ１００からデータベース検索サーバ２００に対して送信され、データベース検索サーバ２００は項目情報を含む検索条件を受信することによって利用項目とともに利用テーブルも同時に決定する。

ＣＰＵ２０１は、クライアントＰＣ１００からの上記検索条件を受けて、ユーザの指定項目（得意先コード、得意先名）から利用テーブルを決定し（ステップＳ６０１）、得意先マスタテーブルを利用テーブル情報としてＲＡＭ２０３に記録する。利用テーブルの決定としては、どのテーブルの項目情報を指定したかが分かれば決定できるので、この場合は得意先マスタテーブルの項目を見ながら全ての条件を指定したケースが当てはまる。同様の項目を指定した場合でも他のテーブル、例えば得意先集計トランザクションテーブルの得意先ＣＤを指定した場合には得意先集計トランザクションテーブルが利用テーブルに追加されることになる。同一のテーブルが複数回指定される場合には、重複しないように１つにしてしまう為に、利用テーブルの書き込み時同一テーブルは上書き等の処理を行う。ここでは得意先マスタテーブルのみが指定されたとして説明を続ける。

続いて、ＣＰＵ２０１は、利用テーブル情報に含まれる全利用テーブルのＲＡＭ２０３からの読み込みが完了したか否かを判断する（ステップＳ６０２）。現時点では、未だ利用テーブルの読み込みが完了していないため、処理はステップＳ６０３に移行する。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から１件の利用テーブルを読み込み、当該利用テーブルのテーブルＩＤを図８に示す利用テーブルＩＤテーブルから参照し、テーブル変数［Ａ］にセットする（ステップＳ６０３）。ここで読み込まれる利用テーブルは得意先マスタテーブルであるため、ＲＡＭ２０３内においてテーブル変数［Ａ］は"０"にセットされる。尚、利用テーブルＩＤテーブルは、例えばＲＡＭ２０３に記録されている。

続いて、ＣＰＵ２０１は、テーブル変数［Ａ］にセットされているテーブルＩＤ"０"のテーブル、即ち得意先マスタテーブルのスキーマＩＤをファクトテーブル定義テーブルから参照し、ＲＡＭ２０３内においてそのスキーマＩＤをスキーマＩＤ変数［Ｂ］にセットする（ステップＳ６０４）。ここでは、ファクトテーブル定義テーブルにおいて、得意先マスタテーブルをファクトテーブルとした場合のスキーマＩＤは"null"と定義されているため、スキーマＩＤ変数［Ｂ］は"null"にセットされる。尚、ファクトテーブル定義テーブルは、例えばＲＡＭ２０３に記録されている。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"０"であるか否かを判断する（ステップＳ６０５）。ここでは、スキーマＩＤ変数［Ｂ］は"null"にセットされているため、処理はステップＳ６０６に移行する。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"null"であるか否かを判断する（ステップＳ６０６）。スキーマＩＤ変数［Ｂ］は"null"であるため、処理はステップＳ６０７に移行する。

続いて、ＣＰＵ２０１は、利用テーブル定義変数［Ｃ］にテーブル変数［Ａ］を追加設定する。いま、利用テーブル定義変数［Ｃ］には何も設定されていない状態であるので、ＲＡＭ２０３内において利用テーブル定義変数［Ｃ］は"０"にセットされる。また、ＣＰＵ２０１は、利用テーブル定義変数［Ｃ］をセットするとともに、スキーマ判断定義変数［Ｄ］とスキーマ判断定義変数［Ｅ］をセットする。即ち、ＲＡＭ２０３内において、スキーマ判断定義変数［Ｄ］にはテーブル変数［Ａ］"０"がセットされ、スキーマ判断定義変数［Ｅ］には"null"がセットされる（ステップＳ６０７）。

ＣＰＵ２０１の処理はステップＳ６０２に戻り、再び全利用テーブルの読み込みが終了したか否かが判断される。いま、ＣＰＵ２０１によって全利用テーブルがＲＡＭ２０３から読み出された状態にあるので、処理は図６−２のステップＳ６１１に移行する。

ＣＰＵ２０１は、スキーマ判断定義変数［Ｄ］とスキーマ判断定義変数［Ｅ］をＲＡＭ２０３から読み込み（ステップＳ６１１）、スキーマ判断定義変数［Ｅ］にセットされている内容が"null"、"０"及び"１以上"の何れであるかを判断する（ステップＳ６１２）。いま、スキーマ判断定義変数［Ｅ］には"null"がセットされているので、処理はステップＳ６１３に移行する。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から利用テーブル情報を読み込み、当該利用テーブル情報に含まれる利用テーブルの数をカウント変数［Ｆ］にＲＡＭ２０３内でセットし（ステップＳ６１３）、セットしたカウント変数［Ｆ］の値が"１"であるか否かを判断する（ステップＳ６１４）。いま、カウント変数［Ｆ］の値は"１"にセットされているため、検索条件にて指定されるマスタテーブル、即ち得意先マスタテーブルのみを対象とした検索処理が決定される（ステップＳ６１５）。

一方、カウント変数［Ｆ］の値が"１"ではない場合、検索対象となるデータベース構造はスキーマ０と決定される。これは、カウント変数［Ｆ］の値が"１"ではない場合は、利用テーブルに複数のマスタテーブルが設定されている可能性があり、データ量の多いトランザクションテーブルをファクトテーブルとしたスキーマのデータベースでしか検索することができないので、検索処理時のスキーマを決定することに時間をかけるより、スキーマ０を決定して即検索処理に移行した方が効率的だからである。

続いて、ＣＰＵ２０１は検索クエリを生成する。ここで、ステップＳ６１５において得意先マスタテーブルのみが検索対象と決定されているので、次のような検索クエリが生成される。尚、SELECT文では検索する項目名及びその項目が属するテーブル名が指定され、FROM文では検索先となるテーブル名が指定され、WHERE文には検索条件が指定される。
＜検索クエリ＞
SELECT 得意先M.得意先名
FROM 得意先M
WHERE 得意先M.得意先CD='1001'

−処理例２−
次に、データベース検索サーバ２００による処理例２を説明する。ここでは、検索条件として「実績年月、得意先コード、商品コードを指定して、得意先名、商品名、販売数を検索する」をクライアントＰＣ１００から受けた場合について説明する。

本処理例では、実績年月、得意先コード、商品コード、得意先名、商品名及び販売数を指定した検索条件をクライアントＰＣ１００から受けた場合を想定しているため、図８に示すように、利用項目は、年月項目、得意先ＣＤ項目、商品ＣＤ項目、得意先名、商品名及び販売数となり、利用テーブルは、実績トランザクションテーブル、得意先マスタテーブル及び商品マスタテーブルとなる。

ＣＰＵ２０１は、クライアントＰＣからの上記検索条件を受けて、ユーザの指定項目（実績年月、得意先コード、商品コード、得意先名、商品名及び販売数）から利用テーブルを決定し（ステップＳ６０１）、実績トランザクションテーブル、得意先マスタテーブル及び商品マスタテーブルを利用テーブル情報としてＲＡＭ２０３に記録する。

続いて、ＣＰＵ２０１は、利用テーブル情報に含まれる全利用テーブルのＲＡＭ２０３からの読み込みが完了したか否かを判断する（ステップＳ６０２）。現時点では、未だ利用テーブルの読み込みが完了していないため、処理はステップＳ６０３に移行する。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から１件の利用テーブルを読み込み、当該利用テーブルのテーブルＩＤを図８に示す利用テーブルＩＤテーブルから参照し、テーブル変数［Ａ］にセットする（ステップＳ６０３）。ここで読み込まれる利用テーブルは実績トランザクションテーブルであることを想定すると、ＲＡＭ２０３内においてテーブル変数［Ａ］を"２"にセットする。

続いて、ＣＰＵ２０１は、変数［Ａ］にセットされているテーブルＩＤ"２"のテーブル、即ち実績トランザクションテーブルのスキーマＩＤをファクトテーブル定義テーブルから参照し、ＲＡＭ２０３内においてそのスキーマＩＤをスキーマＩＤ変数［Ｂ］にセットする（ステップＳ６０４）。ここでは、ファクトテーブル定義テーブルにおいて、実績トランザクションをファクトテーブルとした場合のスキーマＩＤは"０"と定義されているため、スキーマＩＤ変数［Ｂ］は"０"にセットされる。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"０"であるか否かを判断する（ステップＳ６０５）。ここでは、スキーマＩＤ変数［Ｂ］は"０"にセットされているため、処理はステップＳ６１０に移行する。

続いて、ＣＰＵ２０１は、スキーマ判断定義変数［Ｄ］とスキーマ判断定義変数［Ｅ］をセットする（ステップＳ６１０）。スキーマ判断定義変数［Ｄ］にはテーブル変数［Ａ］、即ち実績トランザクションテーブルのテーブルＩＤ"２"がセットされ、スキーマ判断定義変数［Ｅ］には"０"がセットされる。

ＣＰＵ２０１は、スキーマ判断定義変数［Ｄ］とスキーマ判断定義変数［Ｅ］をＲＡＭ２０３から読み込み（ステップＳ６１１）、スキーマ判断定義変数［Ｅ］にセットされている内容が"null"、"０"及び"１以上"の何れかであるかを判断する（ステップＳ６１２）。いま、スキーマ判断定義変数［Ｅ］には"０"がセットされているので、処理はステップＳ６１６に移行する。

続いて、ＣＰＵ２０１は、検索対象となるデータベースの構成をスキーマ０と決定する（ステップＳ６１６）。次に、ＣＰＵ２０１は検索クエリを生成する。ここで、ステップＳ６１６においてスキーマ０が検索対象として決定されているので、次のような検索クエリが生成される。
＜検索クエリ＞
SELECT 得意先M.得意先名,商品M.商品名,実績TRN.販売数
FROM 得意先M,商品M,実績TRN
WHERE 得意先M.得意先CD='1001' AND 商品M.商品CD='A001'
AND (得意先M.得意先CD=実績TRN.得意先CD)
AND (商品M.商品CD=実績TRN.商品CD)

−処理例３−
次に、データベース検索サーバ２００による処理例３を説明する。ここでは、検索条件として「得意先コード（得意先CD='1001'）を指定して、得意先名、得意先上期販売数を検索する」をクライアントＰＣ１００から受けた場合について説明する。

本処理例では、得意先コード、得意先名及び上期販売数を指定した検索条件をクライアントＰＣ１００から受けた場合を想定しているため、図７（ｃ）に示すように、利用項目は得意先ＣＤ項目、得意先名項目及び上期販売数項目となり、利用テーブルは得意先マスタテーブル及び得意先集計トランザクションテーブルとなる。

ＣＰＵ２０１は、クライアントＰＣからの上記検索条件を受けて、ユーザの指定項目（得意先ＣＤ、得意先名、上期販売数）から利用テーブルを決定し（ステップＳ６０１）、利用テーブルが得意先マスタテーブル及び得意先集計トランザクションテーブルであることを利用テーブル情報としてＲＡＭ２０３に記録する。

続いて、ＣＰＵ２０１は、利用テーブル情報に含まれる全利用テーブルのＲＡＭ２０３からの読み込みが完了したか否かを判断する（ステップＳ６０２）。現時点では、未だ利用テーブル情報の読み込みが完了していないため、処理はステップＳ６０３に移行する。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から１件の利用テーブルを読み込み、当該利用テーブルのテーブルＩＤを図８に示す利用テーブルＩＤテーブルから参照し、テーブル変数［Ａ］にセットする（ステップＳ６０３）。ここで読み込まれる利用テーブルは得意先マスタテーブルであることを想定すると、ＲＡＭ２０３内においてテーブル変数［Ａ］は"０"にセットされる。

続いて、ＣＰＵ２０１は、テーブル変数［Ａ］にセットされているテーブルＩＤ"０"のテーブル、即ち得意先マスタテーブルのスキーマＩＤをファクト定義テーブルから参照し、ＲＡＭ２０３内においてそのスキーマＩＤをスキーマＩＤ変数［Ｂ］にセットする（ステップＳ６０４）。ここでは、ファクトテーブル定義テーブルにおいて、得意先マスタテーブルをファクトテーブルとした場合のスキーマＩＤは"null"と定義されているため、スキーマＩＤ変数［Ｂ］は"null"にセットされる。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"０"であるか否かを判断する（ステップＳ６０５）。ここでは、スキーマＩＤ変数［Ｂ］は"null"にセットされているため、処理はステップＳ６０６に移行する。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"null"であるか否かを判断する（ステップＳ６０６）。スキーマＩＤ変数［Ｂ］は"null"であるため、処理はステップＳ６０７に移行する。

続いて、ＣＰＵ２０１は、利用テーブル定義変数［Ｃ］にテーブル変数［Ａ］を追加設定する。いま、利用テーブル定義変数［Ｃ］には何も設定されていない状態であるので、ＲＡＭ２０３内において利用テーブル定義変数［Ｃ］は"０"にセットされる。また、ＣＰＵ２０１は、利用テーブル定義変数［Ｃ］をセットするとともに、スキーマ判断定義変数［Ｄ］とスキーマ判断定義変数［Ｅ］をセットする。即ち、ＲＡＭ２０３内において、スキーマ判断定義変数［Ｄ］にはテーブル変数［Ａ］"０"がセットされ、スキーマ判断定義変数［Ｅ］には"null"がセットされる（ステップＳ６０７）。

ＣＰＵ２０１の処理はステップＳ６０２に戻り、再び全利用テーブルの読み込みが終了したか否かが判断される。未だ、ＲＡＭ２０３には得意先集計トランザクションテーブルが利用テーブルとして残されているので、処理はステップＳ６０３に移行する。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から１件の利用テーブル（得意先集計トランザクションテーブル）を読み込み、当該利用テーブルのテーブルＩＤを図８に示す利用テーブルＩＤテーブルから参照し、テーブル変数［Ａ］を更新する（ステップＳ６０３）。ここで読み込まれる利用テーブルは得意先集計トランザクションテーブルであるため、ＲＡＭ２０３内においてテーブル変数［Ａ］は"３"に更新される。

続いて、ＣＰＵ２０１は、変数［Ａ］にセットされているテーブルＩＤ"３"のテーブル、即ち得意先集計トランザクションテーブルのスキーマＩＤをファクトテーブル定義テーブルから参照し、ＲＡＭ２０３内においてスキーマＩＤ変数［Ｂ］をそのスキーマＩＤに更新する（ステップＳ６０４）。得意先集計トランザクションテーブルをファクトテーブルとした場合のスキーマＩＤは、ファクトテーブル定義テーブルにおいて"１"と定義されているため、スキーマＩＤ変数［Ｂ］は"１"に更新される。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"０"であるか否かを判断する（ステップＳ６０５）。ここでは、スキーマＩＤ変数［Ｂ］は"１"にセットされているため、処理はステップＳ６０６に移行する。

続いて、ＣＰＵ２０１は、セットされているスキーマＩＤ変数［Ｂ］は"null"であるか否かを判断する（ステップＳ６０６）。スキーマＩＤ変数［Ｂ］は"１"にセットされているため、処理はステップＳ６０８に移行する。

続いて、ＣＰＵ２０１は、変数［Ｅ］がスキーマＩＤ変数［Ｂ］より大きい値をとるか、或いは変数［Ｅ］には"null"がセットされているかを判断する（ステップＳ６０８）。いま、変数［Ｅ］には"null"がセットされているため、処理はステップＳ６０９に移行する。ここで、本実施形態では、スキーマＩＤの値が０から９に向かってより容易なスキーマ構造となるように定義付けられている。これを受けて、スキーマＩＤ変数［Ｂ］が既にセットされている変数［Ｅ］の値より小さい値であれば、ステップＳ６０９に移行し、当該スキーマＩＤ変数［Ｂ］の値で変数［Ｅ］の値に更新しており、小さい値のスキーマＩＤ、即ち複雑なスキーマの指定が変数［Ｅ］に残るようにされている。

続いて、ＣＰＵ２０１は、利用テーブル定義変数［Ｃ］、スキーマ判断定義変数［Ｄ］及びスキーマ判断定義変数［Ｅ］をセットする（ステップＳ６０９）。利用テーブル定義変数［Ｃ］は、現在のテーブル変数［Ａ］が追加設定され、"０，３"と更新される。スキーマ判断定義変数［Ｄ］は現在のテーブル変数［Ａ］"３"に更新され、スキーマ判断定義変数［Ｅ］はスキーマＩＤ変数［Ｂ］"１"に更新される。

続いて、ＣＰＵ２０１の処理はステップＳ６０２に戻り、再び利用テーブル情報に含まれる全利用テーブルのＲＡＭ２０３からの読み込みが完了したか否かが判断される。いま、ＣＰＵ２０１によって全利用テーブルがＲＡＭ２０３から読み出された状態にあるので、処理は図６−２のステップＳ６１１に移行する。

ＣＰＵ２０１は、スキーマ判断定義変数［Ｄ］とスキーマ判断定義変数［Ｅ］をＲＡＭ２０３から読み込み（ステップＳ６１１）、スキーマ判断定義変数［Ｅ］にセットされている内容が"null"、"０"及び"１以上"の何れであるかを判断する（ステップＳ６１２）。いま、スキーマ判断定義変数［Ｅ］には"１"がセットされているので、処理はステップＳ６１７に移行する。

続いて、ＣＰＵ２０１は、利用テーブル定義変数［Ｃ］にセットされているテーブルＩＤの１つをＲＡＭ２０３から読み込み、ＲＡＭ２０３内においてテーブル変数［Ｇ］にセットする（ステップＳ６１７）。ここでは、テーブル変数［Ｇ］に得意先マスタテーブルのテーブルＩＤ"０"がセットされたものとする。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から利用テーブル定義変数［Ｃ］にセットされている全テーブルＩＤを読み込んだか否かを判断する（ステップＳ６１８）。現時点では、得意先集計トランザクションテーブルのテーブルＩＤ"３"が未だ読み込まれていないため、処理はステップＳ６１９に移行する。

続いて、ＣＰＵ２０１は、スキーマ判断定義変数［Ｄ］にセットされている得意先集計トランザクションテーブルのテーブルＩＤ"３"、テーブル変数［Ｇ］にセットされている得意先マスタテーブルのテーブルＩＤ"０"をキーにして、ファクトテーブル項目に「得意先集計トランザクションテーブル」、ディメンジョンテーブル項目に「得意先マスタテーブル」が登録されているレコードを図５（ａ）のスキーマ定義テーブルから検索する。

続いて、ＣＰＵ２０１は、ステップＳ６１９の検索処理の結果、該当するレコードがスキーマ定義テーブルから検索されたか否かを判断する（ステップＳ６２０）。図５（ａ）のスキーマ定義テーブルには該当するレコードが存在するので、処理はステップＳ６１７に移行する。

ＣＰＵ２０１は、再び利用テーブル変数［Ｃ］にセットされているテーブルＩＤの１つをＲＡＭ２０３から読み込み、ＲＡＭ２０３内においてテーブル変数［Ｇ］にセットする（ステップＳ６１７）。ここでは、テーブル変数［Ｇ］が得意先集計トランザクションテーブルのテーブルＩＤ"３"に更新される。

続いて、ＣＰＵ２０１は、ＲＡＭ２０３から利用テーブル定義変数［Ｃ］にセットされている全テーブルＩＤを読み込んだか否かを判断する（ステップＳ６１８）。いま、得意先集計トランザクションテーブルのテーブルＩＤが読み込まれたことで全テーブルＩＤの読み込みが終了したので、処理はステップＳ６２１に移行する。

続いて、ＣＰＵ２０１は、スキーマ判断定義変数［Ｄ］にセットされている内容に基づいて、検索対象とするデータベースのスキーマを決定する（ステップＳ６２１）。いま、スキーマ判断定義変数［Ｄ］には得意先集計トランザクションテーブルのテーブルＩＤ"３"がセットされているため、ＣＰＵ２０１は、得意先集計トランザクションテーブルをファクトテーブルとした場合のスキーマＩＤ"１"をファクトテーブル定義テーブルから参照し、検索対象とするデータベースのスキーマとして決定する。

尚、ステップＳ６２０の判断において、該当するレコードがスキーマ定義テーブルに存在しないと判断された場合、検索対象とするデータベース構造はスキーマ０と決定される。本実施形態では、検索条件から利用テーブルを決定すると各利用テーブルを繋ぐ最も簡単に検索できそうなスキーマは何であるかを調べるが、スキーマ定義テーブルにおいて定義されたスキーマが直ぐに見つからず、この処理に長時間を要する虞がある場合には、スキーマ０のデータベース構造を検索対象として決定して即検索処理に移り、検索処理全体の最適化を図っている。

次に、ＣＰＵ２０１は検索クエリを生成する。ここで、ステップＳ６２１においてスキーマ１が検索対象として決定されているので、次のような検索クエリが生成される。そして、ＣＰＵ２０１は、当該検索クエリに基づいてデータ検索を実行する。
＜検索クエリ＞
SELECT 得意先M.得意先名，得意先集計TRN.上期販売数
FROM 得意先M,得意先集計TRN
WHERE 得意先M.得意先CD='1001'
AND (得意先M.得意先CD=得意先集計TRN.得意先CD)

本実施形態では、上記のように、検索条件に応じて検索対象となるデータベースのスキーマを決定することにより、検索クエリの生成や実行処理に要する時間の短縮化を図っているが、本実施形態のようにスキーマの決定を行わない場合、画一的なスキーマのデータベースが検索の対象となるので生成される検索クエリは次のように複雑なものとなり、検索クエリの処理を最適化することができない。
＜検索クエリ＞
SELECT 得意先M.得意先名,得意先集計TRN.上期販売数
FROM 得意先M,得意先集計TRN,実績TRN
WHERE 得意先M.得意先CD='1001'
AND (得意先.得意先CD = 実績TRN.得意先CD)
AND (実績TRN.得意先CD = 得意先集計TRN.得意先CD)

以上のように、本実施形態によれば、検索条件に応じて、異なる複数のデータテーブル（得意先マスタテーブル、商品マスタテーブル、実績トランザクションテーブル、得意先集計トランザクションテーブル及び商品集計トランザクションテーブル）からデータテーブルを選択し、選択したデータテーブルから成るスキーマパターンを決定している。従って、従来のようにスキーマパターンの最適化を図る上で同一のデータテーブルを複数作成する必要がなくなり、記憶容量の使用量を抑えることが可能となる。

また、本発明によれば、最適化されたスキーマパターンに応じた検索クエリを生成して実行しているので、スキーマパターンが最適化され、その結果、少ないデータテーブルで構成されるスキーマパターンのデータベースが検索対象となった場合、それに応じて検索クエリも余計な情報が省かれ、検索クエリの生成処理や実行処理も最適化することが可能となる。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ(基本システム或いはオペレーティングシステム)などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明の一実施形態に係るデータベース検索システムの構成を模式的に示した図である。 データベース検索サーバのハードウェア構成を示した図である。 検索対象となるデータベースの一構成であるデータテーブルを示した図である。 検索対象となる３つのスキーマ構成体のデータベースを示した図である。 スキーマ定義テーブル及びファクト定義テーブルの構成を示した図である。 データベース検索サーバによるデータ検索動作を示すフローチャートである。 データベース検索サーバによるデータ検索動作を示すフローチャートである。 検索処理における利用項目と利用テーブルを説明するための図である。 利用テーブルＩＤテーブルの構成を示した図である。

符号の説明

１００ クライアントＰＣ
２００ データベース検索サーバ
３００ ＤＢサーバ
２１ 自由検索アプリケーション
２２ 自由検索ＤＢ
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ ビデオコントローラ
２０７ メモリコントローラ
２０８ 通信Ｉ／Ｆコントローラ
２０９ キーボード
２１０ ＣＲＴディスプレイ
２１１ 外部メモリ

Claims (7)

1. データの検索条件を入力する検索条件入力手段と、
   前記検索条件入力手段により入力された前記検索条件に応じて、異なる複数のデータテーブルから一又は複数のデータテーブルを選択し、選択した前記一又は複数のデータテーブルから成るデータベース構成を決定するデータベース構成決定手段と、
   前記データベース構成決定手段により決定された前記データベース構成を対象に、前記検索条件によるデータ検索を行うデータ検索手段とを有することを特徴とするデータベース検索装置。
2. 前記データベース構成に応じたデータ検索要求情報を生成するデータ検索要求情報生成手段を更に有し、
   前記データ検索手段は、前記データ検索要求情報生成手段により生成された前記データ検索要求情報に基づき、前記検索条件によるデータ検索を行うことを特徴とする請求項１に記載のデータベース検索装置。
3. 複数のデータベース構成を定義したデータベース定義テーブルを更に有し、
   前記データベース構成決定手段は、前記データベース定義テーブルにおいて定義されるデータベース構成から前記検索条件に応じた前記データベース構成を決定することを特徴とする請求項１又は２に記載のデータベース検索装置。
4. 前記一又は複数のデータテーブルは、前記検索条件で指定される項目を含むデータテーブルであることを特徴とする請求項１乃至３の何れか１項に記載のデータベース検索装置。
5. データベース検索装置によるデータベース検索方法であって、
   データの検索条件を入力する検索条件入力ステップと、
   前記検索条件入力ステップにより入力された前記検索条件に応じて、異なる複数のデータテーブルから一又は複数のデータテーブルを選択し、選択した前記一又は複数のデータテーブルから成るデータベース構成を決定するデータベース構成決定ステップと、
   前記データベース構成決定ステップにより決定された前記データベース構成を対象に、前記検索条件によるデータ検索を行うデータ検索ステップとを含むことを特徴とするデータベース検索方法。
6. 請求項５に記載のデータベース検索方法をコンピュータに実行させるためのプログラム。
7. 請求項６に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images