(57)【特許請求の範囲】
【請求項１】
リレーショナルデータベースで複数のテーブルを結合して検索を行うデータベースシステムであって、
上記複数のテーブルの中から検索対象カラムを含むテーブルを１つ抽出するテーブル抽出手段と、
上記テーブル抽出手段により抽出されたテーブルの検索対象カラムと同じデータ内容が入っているまだ抽出されていない他のテーブルの検索対象カラムをその後のテーブル結合処理において結合処理の対象から除外するようにする処理を行うカラム除外手段と、
上記テーブル抽出手段による処理と上記カラム除外手段による処理とを、上記検索対象カラムが全て処理されるまで繰り返し行い、上記テーブル抽出手段により順次抽出され、上記カラム除外手段で除去されなかった検索対象カラムを含むテーブルを結合するテーブル結合手段とを備えたことを特徴とするデータベースシステム。
【請求項２】
上記テーブル抽出手段は、まだ抽出されていない上記複数のテーブルの中から、検索対象カラムを最も多く含むテーブルを１つ抽出することを特徴とする請求項１に記載のデータベースシステム。
【請求項３】
複数のテーブルの結合に関して結合対象の複数のテーブル名と各テーブルのカラム名とを含むメタデータを記憶するメタデータ管理手段を更に備え、
上記テーブル抽出手段は上記メタデータ管理手段に記憶されたメタデータに基づいて、複数のテーブルの中から検索対象カラムを含むテーブルの抽出処理を行うことを特徴とする請求項１または２に記載のデータベースシステム。
【請求項４】
検索キーに応じて物件を検索する検索手段を更に設け、上記テーブル結合手段により結合されたテーブルに対して検索処理を行うことを特徴とする請求項１〜３の何れか１項に記載のデータベースシステム。
【請求項５】
リレーショナルデータベースで複数のテーブルを結合して検索を行う際に、上記複数のテーブルの中から検索対象カラムを含むテーブルをテーブル抽出手段が１つ抽出するテーブル抽出工程と、
抽出したテーブルの検索対象カラムと同じデータ内容が入っているまだ抽出されていない他のテーブルの検索対象カラムをその後のテーブル結合処理工程において結合処理の対象から除外するようにする処理をカラム除外手段が行うカラム除外処理工程と、
上記テーブル抽出工程とカラム除外処理工程とを、上記検索対象カラムが全て処理されるまで繰り返し行い、上記テーブル抽出手段により順次抽出され、上記カラム除外手段で除去されなかった検索対象カラムを含むテーブルをテーブル結合手段で結合するテーブル結合工程を含むことを特徴とするデータベース検索方法。
【請求項６】
上記テーブル抽出工程では、上記複数のテーブルの中から、検索対象カラムを最も多く含むテーブルを１つ抽出することを特徴とする請求項５に記載のデータベース検索方法。
【請求項７】
上記テーブル結合工程で結合されたテーブルに対して検索処理を行う工程を含むことを特徴とする請求項５または６に記載のデータベース検索方法。
【請求項８】
請求項１〜４の何れか１項に記載の各手段としてコンピュータを機能させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項９】
請求項５〜７の何れか１項に記載の各工程をコンピュータに実行させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータベースシステム、データベース検索方法及び記録媒体に関し、特に、分散化された複数のデータベースから所望のデータを探し出す検索システムに用いて好適なものである。
【背景技術】
【０００２】
近年におけるコンピュータの高性能化に伴い、従来は１台のメインフレーム等の大型コンピュータで構成されていたものが、近年は複数のワークステーションあるいはパーソナルコンピュータなどで構成される分散型システムに移行されてきている。分散型にすることにより、システムの開発・保守が比較的容易になるというメリットがある。分散型システムの例としては、いわゆるインターネットが挙げられる。
【０００３】
インターネットでは、複数のコンピュータがサーバあるいはクライアントとして世界中に分散され、それぞれが言うなれば１つの大きなデータベース（以下、ＤＢと記す）として構成されている。そして、これらのＤＢに対していくつかのプロトコルによりテキスト情報や画像情報などが登録されたり、あるいは読み出されたりする。また、このようなインターネットに限らず、莫大な量のデータを扱うシステムでは、ＤＢが分散化される傾向にある。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところで、このように分散化されたＤＢから所望の情報を読み出そうとした場合、これらのＤＢを管理する全てのサーバから必要な情報を検索するのは、非常に多くの時間と多くの労力とを必要とする。すなわち、ユーザは読み出そうとする情報が分散化しているＤＢのどこに格納されているか分からないので、それぞれのＤＢ毎に対応して設けられたサーバを順にアクセスし、所望の情報が見つかるまで検索を繰り返し行わなければならないという問題があった。
【０００５】
また、ユーザがＤＢサーバの在り処（インターネットのＵＲＬ（Uniform Resource Locator）等のようなアドレス情報）を全て把握していなければ、全てのサーバから必要な情報を検索することは不可能である。しかしながら、分散化されたＤＢサーバは、絶えずデータの登録や削除を行う可能性があり、また、ＤＢサーバ自体のネットワークへの接続・切断も絶えず行われる可能性がある。したがって、これらのことをユーザが全て把握することは極めて困難であり、正確な情報の検索を行うことができないという問題もあった。
【０００６】
このような不便さを解消するために、例えばインターネットでは検索エンジンと呼ばれるアドレス検索サービスが存在する。検索エンジンは、自動的あるいは手動でＵＲＬ情報を収集しており、例えばキーワードの入力によって必要なＵＲＬの検索を行うことができる。例を挙げると、「特許」というキーワードについて検索を行うと、特許に関連したサーバのＵＲＬが出力される。
【０００７】
しかしながら、この検索エンジンでは、ＤＢサーバのＵＲＬ情報を検索するだけで、検索先のサーバ内に構築されたＲＤＢＭＳ（リレーショナルＤＢ管理システム）などの検索を行うことはできなかった。そのため、ＲＤＢＭＳなどを検索する場合は、ユーザはまず検索エンジンで希望するサーバを検索し、検索の結果を見て所望のサーバに接続する。次いで、当該サーバに対応したＤＢの検索方法を用いてそのＤＢ内の情報を検索することになる。
【０００８】
以上のように、従来は所望のデータを入手する際に、各種データを格納したＤＢが分散化されていると、そのデータの検索作業に多くの時間と労力を必要としていた。
【０００９】
さらに、上記ＲＤＢＭＳでは、１つのテーブル中に保持できる最大カラム数に制限があるのが通常である。したがって、例えば最大カラム数が２５６の制限を持ったＲＤＢＭＳでは、２５７カラム以上のテーブルを作成する場合には、１テーブルが２５６カラム以下のテーブル（実テーブル）を複数作成し、それらにリレーションを設定することにより、見た目では１つのテーブル（ビュー）としてデータベースを構築している。
【００１０】
例えば、図１３に示す１つのビューＸは、３つの実テーブルＡ，Ｂ，Ｃから構成されており、これら３つの実テーブルＡ，Ｂ，Ｃの間にはリレーションが設定されている。すなわち、各実テーブルＡ，Ｂ，Ｃのキーとなるカラムa1,b1,c1に互いに同一のデータを格納して、これらのカラムa1,b1,c1をジョインキーとしてビューＸのカラムx1を構成することにより、独立した３つのテーブル間の整合性をとっている。つまり、ビューＸのカラムx1は、上記３つのカラムa1,b1,c1のそれぞれと共通するものである。
【００１１】
また、実テーブルＡのカラムa2,a3,a4はビューＸのカラムx2,x3,x4に、実テーブルＢのカラムb2,b3,b4,b5 はビューＸのカラムx5,x6,x7,x8 に、実テーブルＣのカラムc2,c3 はビューＸのカラムx8,x9 にそれぞれ対応している。ここで、ビューＸのカラムx8に注目すると、ここでは実テーブルＢのカラムb5と実テーブルＣのカラムc2との２つがリレーション設定されている。つまり、この実テーブルＢのカラムb5と、実テーブルＣのカラムc2とには互いに同じデータが入っていることになる。
【００１２】
上記３つの実テーブルＡ，Ｂ，Ｃから１つのビューＸを構成するためのプロトコロルを記述すると、例えば次のようになる。
create view viewＸ（x1,x2,x3,x4,x5,x6,x7,x8,x9）
as select a1,a2,a3,a4,b2,b3,b4,b5,c3
from TableＡ,TableＢ,TableＣ
where a1=b1 and a1=c1 and b5=c2 
【００１３】
しかしながら、このような複数の実テーブルＡ，Ｂ，Ｃを有するＤＢに対してある検索を行ったとき、以下のような不都合が生じる。すなわち、従来のＤＢシステムでは、リレーション設定されている実テーブルをすべて呼び出して検索処理を行うので、所望のデータがどの実テーブル上に存在しているかに拘らず、実テーブルＡ，Ｂ，Ｃが全て検索対象となり、ユーザからの検索式に応じて各実テーブルの検索処理が順に実行される。
【００１４】
ところが、検索しようとするデータが、例えばビューＸ上のカラムx8,x9 に関わるものであったとすると、このビューＸのカラムx8は、実テーブルＢのカラムb5と実テーブルＣのカラムc2とで共通のデータを持っているので、実テーブルＢは使わなくても、カラムx8,x9 の両方に対応した実テーブルＣだけで実際は検索を行うことができるものである。また、このビューＸのカラムx8,x9 は実テーブルＡのどのカラムにも対応していないので、実テーブルＡに対する検索も本来は不要である。
【００１５】
すなわち、従来のＤＢシステムでは、必要以上に多くの実テーブルを結合（ジョイン）して広い範囲を検索していた。このような処理は、ＤＢの検索時間を長く伸ばすだけでなく、システムを構成するコンピュータのメモリ領域を必要以上に多く使用してしまい、結果的に検索のパフォーマンスを低下させることになるという問題を有する。
【００１６】
また、ユーザがＤＢを検索するときは、必ず全ての実テーブルのジョインが発生するが、ＲＤＢＭＳの提供するビューではカラム数の制限が実テーブルと同様に存在するため、物理的な制約を越えて長いビューを作ることはできない。したがって、制約を越えた長いビューの中身を見るときには各実テーブル毎、もしくは各実テーブル毎のデータを統合するカスタムメイドのアプリケーションプログラムをその都度作成し、ユーザに提示しなければならなかった。
【００１７】
本発明は、上述のような問題を解決するために成されたものであり、分散化されたＤＢおよびそのサーバにより構成されるＤＢシステムにおいて、ユーザにＤＢサーバが分散していることを意識させずに容易に検索を行える仕組みを提供することを目的とする。
また本発明は、分散化された各サーバに格納されているＤＢに関する情報を常に把握し、検索を行う時点での最新の情報が結果として得られる仕組みをユーザの負荷を伴わずに提供することも目的とする。
【００１８】
また本発明は、リレーショナルデータベースシステムで、テーブルの結合を行って検索を行う場合に、高速に、しかもメモリの占有率を抑えて処理することができるデータベースシステムを提供することを目的とする。
また、データベースの物理的な制約を越えて長いビューを作れるようにすることをも目的とする。
【課題を解決するための手段】
【００１９】
本発明のデータベースシステムは、リレーショナルデータベースで複数のテーブルを結合して検索を行うデータベースシステムであって、上記複数のテーブルの中から検索対象カラムを含むテーブルを１つ抽出するテーブル抽出手段と、上記テーブル抽出手段により抽出されたテーブルの検索対象カラムと同じデータ内容が入っているまだ抽出されていない他のテーブルの検索対象カラムをその後のテーブル結合処理において結合処理の対象から除外するようにする処理を行うカラム除外手段と、記テーブル抽出手段による処理と上記カラム除外手段による処理とを、上記検索対象カラムが全て処理されるまで繰り返し行い、上記テーブル抽出手段により順次抽出され、上記カラム除外手段で除去されなかった検索対象カラムを含むテーブルを結合するテーブル結合手段とを備えたことを特徴とする。
本発明のデータベース検索方法は、リレーショナルデータベースで複数のテーブルを結合して検索を行う際に、上記複数のテーブルの中から検索対象カラムを含むテーブルをテーブル抽出手段が１つ抽出するテーブル抽出工程と、抽出したテーブルの検索対象カラムと同じデータ内容が入っているまだ抽出されていない他のテーブルの検索対象カラムをその後のテーブル結合処理工程において結合処理の対象から除外するようにする処理をカラム除外手段が行うカラム除外処理工程と、上記テーブル抽出工程とカラム除外処理工程とを、上記検索対象カラムが全て処理されるまで繰り返し行い、上記テーブル抽出手段により順次抽出され、上記カラム除外手段で除去されなかった検索対象カラムを含むテーブルをテーブル結合手段で結合するテーブル結合工程を含むことを特徴とする。
【発明の効果】
【００２０】
本発明においては、テーブル抽出手段で一つずつテーブルを抽出し、更にテーブル結合手段は、カラム除去手段で除去されなかった検索対象カラムを含むテーブルだけを結合するようにしている。従って、本発明によれば、必要最小限のテーブルだけで１つの結合テーブルを生成することができる。よって、不要なテーブルは除外した比較的狭い範囲で検索を行うことができるようになり、高速に、しかもメモリの占有率を抑えて処理することができるデータベースシステムを提供することができる。
【００２１】
本発明のその他の特徴によれば、複数のテーブルの結合に関するメタデータを収集して管理し、このメタデータをもとにテーブルの抽出処理を行うようにしたので、複数のテーブルをメタデータの収集によって一元的に管理することができ、データベースのカラム数等の物理的な制約を越えて長いビューを作ることができる。
【発明を実施するための最良の形態】
【００２２】
以下、本発明の一実施形態を図面に基づいて説明する。
（第１の実施形態）
図１は、第１の実施形態によるデータベースシステムの概念的な構成を示すブロック図であり、図２は、当該データベース検索システムのソフトウェアおよびハードウェアイメージを示すブロック図である。
【００２３】
図１において、１０はユーザ端末であり、ＷＷＷ（world wide web）ブラウザ１１を搭載し、検索のキーワード入力、検索要求、検索結果の表示等をこのＷＷＷブラウザ１１上で行う。後述するメタＤＢに対する検索か、実データに対する検索かは、このＷＷＷブラウザ１１上で指定する。このＷＷＷブラウザ１１は、図２に示すようにＧＵＩ部１１ａと検索要求転送部１１ｂとを備え、ＧＵＩ部１１ａによって検索のための種々の操作を行うとともに、検索要求転送部１１ｂによって検索要求信号を転送するようになっている。
【００２４】
２０はデータベース（ＤＢ）であり、実際のデータが格納されている。このＤＢ２０は、ネットワーク上に少なくとも１つ以上存在する。このＤＢ２０に対して検索を行うためのプラットホームやＤＢアプリケーションは問わないが、例えばＳＱＬ（Structured Query Language ：表型のデータ構造を持つリレーショナルＤＢ向けのデータベース言語）等の検索手段によりデータ検索を行うことができるようになっている。
【００２５】
３０はＤＢサーバであり、図２に示すように検索要求受付部３１ａおよびメタデータ提供部３１ｂを備えたＨＴＴＰＤ(Hyper Text Transfer Protcol）３１と、ＤＢネットワーククライアントより成る検索実行部３２とを搭載している。基本的には、１つのＤＢ２０に対して１つのＤＢサーバ３０が設けられるが、１つのＤＢサーバ３０が複数のＤＢ２０を管理することもある。
【００２６】
このＤＢサーバ３０は、ユーザ端末１０からの検索要求に応答してＤＢ２０を検索し、ユーザ端末１０に対して検索結果をＨＴＭＬ（Hyper Text Markup Language）形式で回答する。その際、ユーザ端末１０からの検索要求をＤＢ２０に合う形に翻訳して渡すことにより、異種ＤＢ間の差異を吸収する役割を持つ。ＤＢサーバ３０はまた、自分が管理しているＤＢ２０に格納されている実データに関するメタデータ３３を作成し、格納する。
【００２７】
ここでメタデータとは、ＤＢ２０に格納されているデータの属性、意味内容、取得先、格納場所など、データを管理するための情報を言う。本実施形態では特に、少なくともＤＢ２０がどういうデータを持っているのかというデータ内容、および当該ＤＢ２０にアクセスするためのＵＲＬを含む。ＤＢサーバ３０は、後述するメタＤＢサーバ４０からの要求に応じてこのメタデータ３３をメタＤＢサーバ４０に提供する。
【００２８】
図６に、上記メタデータ３３のディレクトリ構造の例を示す。この図６は、１つのＤＢサーバ３０が複数のＤＢ２０（ＤＢ１，ＤＢ２，ＤＢ３，…）を管理している例について示したものであり、それぞれのＤＢのディレクトリ内には、そのＤＢに関するメタデータファイル、ＤＢを構成するテーブルに関するメタデータファイル、およびテーブル内の各カラム１〜ｎに関するメタデータファイルが含まれていることが示されている。
【００２９】
図７は、上記ＤＢに関するメタデータファイルの具体的内容を代表として示したものである。図７に示すように、ＤＢのメタデータとしては、DBKEY,DBEXPL,DBMS,DBLIMIT,SERIAL,CHECK,RETRY,EMAIL,TBLFILE,DBNAME,SQLURLの各情報が含まれる。以下、これらの各情報について１つずつ説明していく。
【００３０】
DBKEY はＤＢに関するキーワードであり、ここでは「デモ、社員」というキーワードが記述されている。DBEXPLはＤＢの内容説明であり、ここでは「社員情報」という説明が記述されている。DBMSはＤＢシステムの名前であり、ここでは「OracleWorkgroupServer-7.3 」という名前が記述されている。DBLIMIT はＤＢへのアクセス制限であり、ここでは「allow @foo.co.jp;deny all 」と記述されている。つまり“@foo.co.jp”のアドレスを持つユーザのアクセスは許可するが、それ以外のユーザのアクセスは拒否することが記述されている。
【００３１】
また、SERIALは更新チェックのために使用するメタデータのシリアル番号であり、ここでは「19971225000000」と記述されており、1997年12月25日にメタデータが更新されたことが示されている。CHECK はメタデータの更新チェックの時間間隔 [秒] であり、ここでは「3600秒」という時間が記述されている。RETRY はメタデータの更新チェックの失敗時におけるリトライの時間間隔 [秒] であり、ここでは「600 秒」という時間が記述されている。
【００３２】
また、EMAIL はＤＢの管理者のメールアドレスであり、ここでは「dbnavi@foo.co.jp」というアドレスが記述されている。TBLFILE はＤＢのテーブルに関するメタデータが記述されているファイル名であり、ここでは「tables.html 」という名前が記述されている。DBNAMEはＤＢの登録名であり、ここでは「demo@navi.foo.co.jp 」という名前が記述されている。SQLURLはＤＢへの検索実行要求先のＵＲＬであり、ここでは「http://navi.foo.co.jp:8080/servlet/DBNAVI/service 」というＵＲＬが記述されている。
【００３３】
また、図示は省略するが、テーブルのメタデータファイルやカラムのメタデータファイルに関しては、図７に示したＤＢのメタデータファイルと書式は同様であるが、異なる内容のメタデータが複数記述されている。ここで、テーブルのメタデータとしては、COLFILE,TBLNAME,DBNAME,TBLOWNER,TBLNAME2,TBLKEY,TBLEXPL,TBLDATE,TBLMODIFY,NCOLS,NROWS,TBLLIMITの各情報が含まれる。以下、これらの各情報について１つずつ説明していく。
【００３４】
COLFILE はカラムに関するメタデータが記述されているファイル名、TBLNAME はテーブル名、DBNAMEはＤＢ名であり、図７に示したＤＢのメタデータファイル中に記述されたものと同じものである。TBLOWNERはテーブルの所有者名、TBLNAME2は日本語によるテーブル名、TBLKEYはテーブルに関するキーワード、TBLEXPL はテーブルの内容説明、TBLDATE はテーブルの作成日時、TBLMODIFY はテーブルの更新タイミング、NCOLS はテーブル内のカラム数、NROWS はテーブル内の行数、TBLLIMITはテーブルへのアクセス制限を示す情報である。
【００３５】
また、カラムのメタデータとしては、COLNAME,DBNAME,TBLNAME,TBLOWNER,COLNAME2,CODEFILE,COLKEY,COLEXPL,COLHANDLER,COLHINFO,COLATTR,COLTYPE,COLUNIT,COLSIZEの各情報が含まれる。以下、これらの各情報について１つずつ説明していく。
【００３６】
COLNAME はカラム名である。また、DBNAMEはＤＢ名であり、ＤＢのメタデータファイル中と同じものである。TBLNAME はテーブル名、TBLOWNERはテーブルの所有者名であり、それぞれテーブルのメタデータファイル中と同じものである。COLNAME2は日本語によるカラム名、CODEFILEはカラムの内容を示すコードに関するメタデータファイルの格納場所を示す情報である。
【００３７】
また、COLKEYはカラムに関するキーワード、COLEXPL はカラムの内容説明、COLHANDLERはカラムの取扱方法、COLHINFOはカラムの取扱情報、COLATTR はカラムの制約属性、COLTYPE はカラム内に格納されるデータのタイプ、COLUNIT はカラム内に格納されるデータの単位、COLSIZE はカラム内に格納されるデータのサイズを示す情報である。
【００３８】
また、上記コードのメタデータとしては、CODENAME,DBNAME,CODENAME2,CODEKEY,CODEEXPLの各情報が含まれる。ここで、CODENAMEはコード名、DBNAMEはＤＢ名であり、ＤＢのメタデータファイル中と同じものである。CODENAME2 は日本語によるコード名、CODEKEY はコードに関するキーワード、CODEEXPLはコードの内容説明を示す情報である。
【００３９】
図１および図２に戻り、上記メタＤＢサーバ４０は、ネットワーク上に存在する少なくとも１つ以上のＤＢサーバ３０から各ＤＢ２０のメタデータ３３を収集し、メタＤＢ４１を作成する。このメタＤＢ４１の作成および管理は、メタＤＢ管理プログラムより成るメタＤＢ管理部４２によって行う。ＤＢサーバ３０上のメタデータ３３は、メタＤＢ管理部４２からの要求に応じて定期的に、あるいはＤＢサーバ３０またはメタデータ３３の更新時に収集される。
【００４０】
また、メタＤＢサーバ４０は、図２に示すようにメタＤＢ検索受付部４３ａと検索要求作成部４３ｂとを備えたＨＴＴＰＤ４３を搭載している。ユーザ端末１０からメタＤＢ４１への検索要求があると、メタＤＢ検索受付部４３ａがそれを受けて該当するメタデータを検索し、ＨＴＭＬ形式でユーザ端末１０に回答する。検索要求作成部４３ｂは、メタＤＢ４１の検索結果を見て更に応答してきたユーザからの指示に応じて、ＤＢ２０上で実データを検索するためにＤＢサーバ３０に発行する検索条件を作成する。
【００４１】
上記のように構成したユーザ端末１０、ＤＢ２０、ＤＢサーバ３０およびメタＤＢサーバ４０は、実際には図２に示すようにネットワーク５０に接続されている。ここではそれぞれの機器１０〜４０がネットワーク５０に１つずつ接続された構成を示しているが、これらはそれぞれ複数個存在していても構わない。分散ＤＢシステムにおいては、通常は複数個存在している。
【００４２】
すなわち、ユーザ端末１０は、ネットワーク５０上に１つ以上存在する。ユーザ端末１０から見てＤＢサーバ３０は１つ以上、メタＤＢサーバ４０も１つ以上見えるが、ＤＢ２０は見えない。
また、上述したようにＤＢ２０は、ネットワーク５０上に１つ以上存在する。物理的にはＤＢサーバ３０と同一の装置内に実装して構わない。ＤＢ２０から見てＤＢサーバ３０がいくつ存在していても構わない。
【００４３】
また、ＤＢサーバ３０もネットワーク５０上に１つ以上存在する。ＤＢサーバ３０から見てＤＢ２０がいくつ存在していても構わない。なお、従来のＤＢサーバは、メタデータ提供部３１ｂおよびメタデータ３３は備えていない。
また、メタＤＢサーバ４０もネットワーク５０上に１つ以上存在する。メタＤＢサーバ４０から見てユーザ端末１０およびＤＢサーバ３０は複数存在しても構わないが、ＤＢ２０は見えない。
【００４４】
従来は、このようにネットワーク５０上に分散しているＤＢ２０の何れかより所望のデータを取り出す際に、１つ以上のＤＢサーバ３０に順次接続して検索していたが、本実施形態ではまず、新たに設けたメタＤＢサーバ４０に接続してメタデータを検索し、検索しようとする実データが存在するＤＢ２０を知る。その後、そのＤＢ２０に対応するＤＢサーバ３０に発行する検索条件を作成し、検索要求転送部１１ｂからＤＢサーバ３０にその検索条件を発行し、検索結果を得る。
【００４５】
以下に、上述のように構成した本実施形態によるデータベースシステムの動作を説明する。
検索の前の準備として、ＤＢサーバ３０の管理者は、そのサーバが受け持つＤＢ２０のメタデータ３３を作成する。作成されたメタデータ３３は、メタＤＢサーバ４０からの要求に応じてメタＤＢサーバ４０に送られる。メタＤＢサーバ４０は、複数のＤＢサーバ３０からそれぞれのメタデータ３３を収集し、メタＤＢ４１を作成しておく。
【００４６】
次に、実際に検索を行うときは、まず、ユーザが所望のキーワードを入力することにより、メタＤＢサーバ４０のメタＤＢ４１に対してメタデータの検索を実行する。これにより、入力したキーワードに合致する１つ以上のメタデータがメタＤＢ４１より抽出される。メタデータには対応するＤＢ２０あるいはＤＢサーバ３０のＵＲＬが含まれているので、この時点でユーザは、探している実データが存在するＤＢ２０を把握することができ、何れのＤＢ２０に対してアクセスするかを選択することができる。もちろん、検索された全てのＤＢ２０にアクセスすることも可能である。
【００４７】
メタデータの検索結果を得たユーザは、次にＤＢ２０上で実データを検索するためにＤＢサーバ３０に発行する検索条件を作成する。この検索条件を作成するためのＧＵＩ操作画面は、メタＤＢサーバ４０によってメタデータの検索結果等をもとにユーザ端末１０に提供される。検索条件を作成した後、ユーザが検索実行のＧＵＩボタンを押すと、その検索条件を持った検索要求がメタＤＢサーバ４０を経ることなくＤＢサーバ３０に直接転送され、実データの検索が実行される。そして、その検索結果がユーザ端末１０に返送され、表示される。
【００４８】
なお、メタＤＢサーバ４０からユーザ端末１０に提示する検索結果には、複数のＤＢサーバ３０あるいは複数のＤＢ２０が同時に含まれることもある。このような場合も、メタＤＢサーバ４０から提供される検索条件作成用のＧＵＩ操作画面は区別なく所定のフォーマットで表示される。よって、ユーザは、分散した複数のＤＢサーバ３０あるいは複数のＤＢ２０を意識することなく検索条件を作成してそれをメタデータの検索結果中に含まれるＵＲＬに従って所望のＤＢサーバ３０に発行することができる。
【００４９】
以上のように、本実施形態のデータベースシステムによれば、まず最初にメタデータを利用したあいまい検索を行うことにより、入力した適当なキーワードにマッチするものをメタＤＢ４１から複数抽出することができる。ここで抽出されるメタデータは、１つ以上のＤＢ２０の内容等を簡単に表したものである。よって、ユーザは分散しているＤＢ２０（ＤＢサーバ３０）がどこにあるか分からなくても、ユーザが所望するキーワードにマッチするＤＢ２０の情報を全て簡単に得ることができる。
【００５０】
すなわち、ユーザはＤＢ２０（ＤＢサーバ３０）が分散して存在していることを意識することなく、異なるＤＢ２０の情報をメタＤＢサーバ４０の１ヵ所から１度の検索で全て得ることができる。抽出されたＤＢ２０（ＤＢサーバ３０）の在り処（ＵＲＬ）はメタデータ中に含まれており、これがユーザに提示されるので、ユーザはメタＤＢサーバ４０の在り処（ＵＲＬ）さえ分かっていれば良い。よって、分散している全てのＤＢサーバ３０を把握して１つ１つ順にアクセスしていくという面倒な作業を行わなくても済む。
【００５１】
しかも、ネットワーク５０上に存在するＤＢ２０の情報（メタデータ）は、ＤＢサーバ３０とメタＤＢサーバ４０との間の定期的な通信により、常に最新のデータがメタＤＢサーバ４０に送られる。これにより、メタＤＢ４１の内容は、検索を行う時点での最新の情報が結果として得られることとなり、正確なデータ検索を行うことができるようになる。このメタデータの更新検査処理は、ＤＢサーバ３０とメタＤＢサーバ４０との間で自動的に行われる。よってユーザは、ＤＢサーバ３０によって絶えず行われるデータの登録や削除、およびＤＢサーバ３０自体のネットワーク５０への接続・切断などを把握する必要はない。
【００５２】
さらに本実施形態では、ＤＢサーバ３０上でメタデータ３３が更新されたときにそれをＤＢサーバ３０からメタＤＢサーバ４０に能動的に送るのではなく、メタＤＢサーバ４０からの要求に応じて送信するようにしている。このようにすることにより、ＤＢサーバ３０はメタＤＢサーバ４０から完全に独立する。したがって、ＤＢサーバ３０はどのメタＤＢサーバ４０に対してメタデータを提供するのかを知らなくても良い。メタＤＢサーバ４０は、立ち上がっている全てのＤＢサーバ３０からメタＤＢサーバ４０の要求に応じて送られてくるメタデータをもとにメタＤＢ４１を書き換えることができる。
【００５３】
なお、本実施形態ではメタＤＢサーバ４０がネットワーク５０上に１つだけあるという形態について説明しているが、メタＤＢサーバ４０は１つ以上、複数あっても構わない。メタＤＢサーバ４０と同じ内容あるいは違う内容の情報を持つミラーサーバを設けるなどすると、例えばトラフィックが非常に混んでいる場合に、ユーザ端末１０からの要求に対するメタＤＢサーバ４０の反応が遅くなることを防止できる。
【００５４】
次に、上述した本実施形態によるデータベースシステムの動作を、図３〜図５に示すフローチャートを用いてより詳しく説明する。
なお、図３は全体の処理の流れを示すフローチャートであり、図４はメタＤＢの更新処理（メタＤＢ管理プログラムによる処理）の流れを示すフローチャートであり、図５は一連の検索処理をユーザ端末１０、ＤＢサーバ３０、メタＤＢサーバ４０毎に示したフローチャートである。
【００５５】
図３において、まずステップＳ１では、ＤＢサーバ３０の管理者がＤＢ２０に関するメタデータ３３を作成し、登録する。これらのメタデータ３３は、ＤＢサーバ３０上のＨＴＴＰＤ３１を経由し、ネットワーク５０上の他のマシンから参照することができる。本実施形態では、メタＤＢ４１の検索を正確かつ効率的に行えるようにするために、例えば図６に示したようにメタデータ３３を複数のレイヤに分けて作成できるようにしている。
【００５６】
例えば、本実施形態ではＤＢ２０として表型のリレーショナルＤＢを想定し、ＤＢレイヤ、テーブルレイヤ、カラムレイヤ、コードレイヤの４つのレイヤ構成としている。ＤＢレイヤはＤＢ２０全体に関する情報、テーブルレイヤはＤＢ２０内の各テーブル（表）に関する情報、カラムレイヤはテーブル内の各列（各項目）に関する情報、コードレイヤはカラム内の各値に関する情報を記述するものである。各レイヤには各レイヤの内容やキーワードが含まれており、少なくともＤＢレイヤにはＤＢ２０（検索条件の発行先）のＵＲＬが含まれている。
【００５７】
次に、ステップＳ２では、メタＤＢサーバ４０の管理者が、どのＤＢサーバ３０をサポートするかに応じて、ＤＢサーバ３０からメタデータ３３の取得に必要な情報、すなわち、ＤＢサーバ３０が提供する各ＤＢ２０の情報を所定のファイルに登録する。登録に必要な項目は、少なくとも各ＤＢ２０のＤＢレイヤメタデータファイルのＵＲＬである。
【００５８】
サポートする各ＤＢ２０の情報が登録されると、メタＤＢサーバ４０は、ステップＳ３でＤＢサーバ３０から上記登録されたそれぞれのＤＢ２０に関するメタデータ３３を取得し、ステップＳ４でメタＤＢ４１に登録する。すなわち、登録されている複数のＤＢサーバ３０からメタデータ３３を全て収集し、それらをもとに、ユーザに向かってサービスを行いやすくするためにデータを加工することにより、メタＤＢ４１を作成する。
【００５９】
ここで、メタＤＢサーバ４０の管理者は、サポートするＤＢ２０を新たに追加したい場合は、該当するＤＢ２０の情報を上述のファイル中に一文追加するだけで良い。こうすれば、後はメタＤＢサーバ４０がＤＢサーバ３０からメタデータ３３を自動的に読み込んで、メタＤＢ４１を更新する。このように本実施形態では、サポートするＤＢ２０の追加や削除などを極めて簡単に行うことが可能な柔軟なシステムを提供することができる。
【００６０】
以上で検索の前の準備が完了する。その後実際に検索を行うときは、まずステップＳ５で、ユーザがＷＷＷブラウザ１１を使ってメタＤＢサーバ４０に問い合わせをかける。すると、メタＤＢサーバ４０は、ステップＳ６でメタＤＢ４１を使用してユーザの問い合わせに合致するＤＢ２０を検索する。そして、ステップＳ７でその検索結果やメタデータを用いて検索条件作成フォームのページ（ＧＵＩ操作画面）を構成し、ユーザ端末１０に送る。
【００６１】
ユーザは、ステップＳ８でこの検索結果を見て要求を満足させるものであるかどうかを判断し、満足できなければステップＳ５に戻り、前回と異なるキーワードを入力すること等により、検索をやり直す。一方、検索結果に満足できれば、ステップＳ９に進む。ステップＳ９では、ユーザは提示された検索条件作成フォームのページを用いて、抽出されたＤＢ２０上で実データを検索する際に用いる検索条件を作成し、検索要求としてＤＢサーバ３０に発行する。
【００６２】
検索条件としては、例えば上述のリレーショナルＤＢを想定した場合、該当するＤＢ２０内のどのテーブル、どのカラムのどの位置の情報を検索するかといった条件の他、各種の条件を入力することができる。どのような検索条件を入力するかは、アプリケーションによって自由に決めることが可能である。なお、リレーショナルＤＢを扱う場合、ＤＢサーバ３０に対する検索要求は、ＳＱＬの形式に従って作成され、発行される。検索要求の発行先は、メタデータ中にＵＲＬとして提示されており、検索実行のボタン操作によって検索要求が該当する発行先に自動的に発行される。
【００６３】
検索要求を受けたＤＢサーバ３０は、ステップＳ１０で、検索要求をＤＢ２０に合う形に翻訳する。すなわち、ユーザ端末１０とメタＤＢサーバ４０間で検索条件を作成する際には、ネットワーク５０上に分散しているＤＢ２０の種類に関係なくある決まった１つのフォーマットにより作成されている。そこで、実際に個々のＤＢ２０に検索要求を発行する際には、標準的な検索要求を個々のＤＢ２０が理解可能な形に変換するようにしている。
【００６４】
このため、ユーザは分散されている個々のＤＢ２０を意識することなく、メタＤＢサーバ４０より提示される上述の検索条件作成フォームを用いて標準的なフォーマットに従った検索条件を作成して発行すれば良い。つまり、ユーザから見ればネットワーク５０上のどのＤＢ２０も同じに見え、分散している異なる種類のＤＢ２０の抽象化を図ることができる。
【００６５】
上述のように翻訳された検索要求を受けたＤＢサーバ３０は、ステップＳ１１でユーザに代わってＤＢ２０に検索要求（ＳＱＬ）を発行し、実データの検索を実行する。そして、ステップＳ１２でその検索結果をユーザ端末１０に返送して表示し、一連の検索処理を終了する。
【００６６】
次に、メタＤＢサーバ４０によるメタＤＢ４１の更新処理（図３のステップＳ３およびステップＳ４の処理）について、図４を用いて詳しく説明する。
図４において、まずステップＳ２１では、メタＤＢ管理部４２内の設定ファイルから、サポートするＤＢサーバ３０のＵＲＬと検査間隔とを取得する。
【００６７】
検査間隔は、メタＤＢサーバ４０からＤＢサーバ３０にメタデータ３３の収集要求を定期的に発行する際の時間間隔を示すものである。これは、メタＤＢサーバ４０内であらかじめ設定しても良いし、ＤＢサーバ３０の管理者がメタデータ３３を作成するときに、メタデータ３３内に記述してメタＤＢサーバ４０に送信し、上述の設定ファイルに格納するようにしても良い。
【００６８】
ステップＳ２２では、設定された検査間隔をもとに、ＤＢサーバ３０の検査時間になるまで待機し、検査時間になったらステップＳ２３に進み、ＤＢサーバ３０からメタデータ３３のＤＢレイヤの情報を取得する。ＤＢレイヤには、メタデータ３３の内容に変更がある毎にカウントアップされるシリアル番号データが含まれており、ステップＳ２４でこれを検査することにより、メタデータ３３に変更があったかどうかを判断する。
【００６９】
ここで、メタデータ３３に変更がない場合は、次の検査時間になるまで待機すべくステップＳ２２に戻る。一方、変更があった場合は、ステップＳ２５に進んでそのメタデータ３３の情報をＤＢサーバ３０から取得する。ステップＳ２６では、メタデータ３３が更新されていたかどうかを判断し、更新済であればステップＳ２７で新たなメタデータ３３を保存し、その更新時間を記録する。
【００７０】
そして、次のステップＳ２８で、検査中のＤＢ２０に関する全てのメタデータ３３を調査したかどうかを判断し、未調査のメタデータ３３があれば、それを取得するためにステップＳ２５に戻る。全てのメタデータ３３を調査し終わったら、ステップＳ２９で他のＤＢサーバ３０のうち検査時間になったものがあるかどうかを判断し、あればステップＳ２３に戻って同様の処理を行う。
【００７１】
以上のようにして、検査時間になった全てのＤＢサーバ３０から該当するＤＢ２０に関するメタデータ３３を全て取得し終わると、ステップＳ３０でそれらの情報をもとにメタＤＢ４１を更新する。そして、ステップＳ３１で、検査済みのＤＢサーバ３０の次回検査時間を記録して、ステップＳ２２の処理に戻る。
【００７２】
次に、ユーザ端末１０、ＤＢサーバ３０、メタＤＢサーバ４０によって行われる一連の検索処理（図３のステップＳ５〜Ｓ１２の処理）について、図５を用いて詳しく説明する。
図５において、まずステップＳ４１でユーザは、ユーザ端末１０をメタＤＢサーバ４０にネットワークを介して接続する。これを受けてメタＤＢサーバ４０はステップＳ４２で、メタＤＢ４１の検索フォームをＨＴＭＬ書式にてユーザ端末１０に送付する。
【００７３】
次にユーザは、ステップＳ４３で、上述の検索フォームを用いてキーワードを指定し、メタＤＢサーバ４０に検索要求を発行する。これを受けてメタＤＢサーバ４０は、ステップＳ４４で、入力されたキーワードによる全文検索をメタＤＢ４１に対して実行し、ステップＳ４５でその検索結果をユーザ端末１０にＨＴＭＬ書式にて返送する。ユーザは、ステップＳ４６でその検索結果を評価し、満足のいくものであればその旨をメタＤＢサーバ４０に伝える。
【００７４】
メタＤＢサーバ４０は、ステップＳ４７でメタＤＢ４１の検索結果やメタデータを用いて、ＤＢ２０に対する検索条件の作成フォームをＨＴＭＬ書式にて構成し、それをユーザ端末１０に送る。ユーザは、ステップＳ４８で、提示された検索条件作成フォームを用いてＤＢ２０の検索条件を指定し、メタＤＢサーバ４０に通知する。メタＤＢサーバ４０はステップＳ４９で、通知された検索条件文（ＳＱＬ）とこれの送信先であるＤＢ２０に対応するＤＢサーバ３０のＵＲＬとをユーザ端末１０に送る。
【００７５】
これを受けたユーザ端末１０は、ステップＳ５０で、通知されたＵＲＬで示されるＤＢサーバ３０に対して検索条件文（ＳＱＬ）を検索要求として発行する。この検索要求を受けたＤＢサーバ３０は、ステップＳ５１で、その検索要求を該当するＤＢ２０に合う形に変更する。そして、ＤＢサーバ３０は、ステップＳ５２で検索要求（ＳＱＬ）をＤＢ２０に発行して実データの検索を実行し、続くステップＳ５３で、得られた検索結果をユーザ端末１０に送信する。ユーザ端末１０は、ステップＳ５４で検索実行結果を取得し、一連の検索処理を終了する。
【００７６】
なお、以上の実施形態では、ユーザ端末１０、ＤＢ２０、ＤＢサーバ３０およびメタＤＢサーバ４０をインターネットに接続して構成した分散ＤＢシステムについて示したが、接続するネットワークはインターネットには限られない。例えば、インターネット以外のＷＡＮ（Wide Area Network ）やＬＡＮ（Local Area Network）、あるいはイントラネットなどにも適用することが可能である。
【００７７】
また、以上の実施形態では、ＤＢ２０の一例としてリレーショナルＤＢを例に挙げたが、本発明で対象とするＤＢはこれに限られるものではない。また、ＤＢで扱うデータの内容も、テキストデータ、画像データ、音声データなど様々な形態とすることが可能である。
【００７８】
（第２の実施形態）
次に、本発明の第２の実施形態を図面に基づいて説明する。
図８は、本実施形態によるデータベースシステムの一構成例を示すブロック図である。図８に示す本実施形態のデータベースシステムは、これ単独で使用することも可能であるし、図１に示した第１の実施形態と組み合わせて使用することも可能である。
【００７９】
第１の実施形態と組み合わせて使用する場合、例えば、図８中に一点鎖線で示したデータベース２０以外の機能構成を、図１のＤＢサーバ３０が備えることによって実現できる。また、図８の検索エンジン６０および結合テーブル生成手段６５のみを図１のＤＢサーバ３０が備え、図８のメタデータ管理手段６９およびメタデータ記憶手段７０は、図１のメタＤＢサーバ４０が備えるようにしても良い。
【００８０】
また、本実施形態のデータベースシステムを第１の実施形態と組み合わせて適用する場合、使用するメタデータとしては、ジョイン保証されている他のＤＢ名（JOINABLE）がＤＢレイヤのファイル中に追加され、後述する仮想テーブルで表される複数の実テーブルとカラムとの対応を記述したマップ情報（JOINMAP ）がテーブルレイヤのファイル中に追加され、実カラム名（REALCOL ）がカラムレイヤのファイル中に追加される。
【００８１】
以下では、図８に示す各機能構成について説明する。６０は検索エンジンであり、ＳＱＬ文で要求された検索条件に基づいてデータベース２０内のデータを検索する。データベース２０には複数の実テーブル２１，２２，２３，……が格納されている。これらの実テーブル２１，２２，２３，……は、ＲＤＢＭＳの制約に合致した形式で格納されており、検索エンジン６０からは各実テーブルの検索を行うことができるようになっている。
【００８２】
６９はメタデータ管理手段であり、上記複数の実テーブル２１，２２，２３，……に関するメタデータを管理している。ここでメタデータとは、各実テーブル２１，２２，２３，……に格納されているデータの属性、意味内容、取得先、格納場所など、データを管理するための情報を言い、例えば上記第１の実施形態で述べたものと同様なものである。このメタデータは、データベース２０から定期的あるいは不定期に取得され、メタデータ記憶手段７０に記憶される。メタデータ管理手段６９は、このメタデータをメタデータ記憶手段７０に記憶させたり、読み出して使用したりする。
【００８３】
例えば、図８において、データベース２０には実テーブル２１，２２，２３，……が格納されているので、メタデータ管理手段６９は実テーブル２１，２２，２３，……のテーブル名および各テーブルを構成しているカラムのカラム名を取得し、メタデータ記憶手段７０に実テーブルメタデータ７１として記憶する。このように記憶させる情報は、テキストデータでも簡単に記載できる形態なので、管理者などが手動で作成し記憶させても良い。
【００８４】
また、複数のテーブルの結合に関する情報も、このメタデータ管理手段６９により仮想テーブルメタデータ７２として管理されている。例えば、２つの実テーブル２１，２２から作られた仮想テーブルのメタデータであれば、実テーブル２１，２２のテーブル名と、各テーブルの全てのカラム名とがメタデータとして記憶されている。同様に、３つの実テーブル２１，２２，２３から作られた仮想テーブルであれば、３つのテーブル名と、各テーブルの全てのカラム名とが記憶されている。
【００８５】
６５は結合テーブル生成手段であり、カラム数最大テーブル抽出手段６６、同一データ選択カラム除外手段６７およびテーブルジョイン手段６８から構成されている。結合テーブル生成手段６５は、メタデータ管理手段６９で管理されているメタデータをもとに、複数の実テーブル２１，２２，２３，……から必要なカラムだけを抽出して仮想的に新たなテーブルを作る機能を持っている。なお、本実施形態では、従来のビューと同様に所定カラムを結合する作業を行うが、本実施形態で結合された仮想テーブルは、従来のビューとは形態が異なっている。
【００８６】
カラム数最大テーブル抽出手段６６は、上記メタデータ管理手段６９にて管理されているメタデータをもとに、実テーブル２１，２２，２３，……の中から、検索しようとするデータが格納されているカラムの数が最も多い実テーブルを抽出する。このとき、抽出した実テーブルに含まれるカラムと同じデータ内容のカラムが他の実テーブル内にも重複して存在している場合は、そのカラムは抽出した実テーブル内にのみ属するものとして扱うようにする。
【００８７】
また、同一データ選択カラム除外手段６７は、上記カラム数最大テーブル抽出手段６６により実テーブルが１つ抽出される毎に、残った実テーブルに含まれる各カラムのうち、抽出された実テーブルのカラムと同じデータ内容が入っているカラムを、以降続けて行われるテーブルジョイン処理において除外するための処理を行う。
【００８８】
カラム数最大テーブル抽出手段６６は、上記同一データ選択カラム除外手段６７により該当するカラムを除外した状態で、前回までに抽出した実テーブルを除いた残りの実テーブルを対象としてカラム数最大の実テーブルを抽出する処理を再び行う。以下同様にして、検索対象のカラム数が最も多い実テーブルを抽出する処理と、抽出した実テーブルのカラムと同じデータが入っているカラムを除外する処理とを繰り返し行う。
【００８９】
テーブルジョイン手段６８は、カラム数最大テーブル抽出手段６６により順次抽出された１つ以上の実テーブルを結合させることにより、１つ以上の実テーブルから論理的な１つの結合テーブル（仮想テーブル）を作成する。この結合テーブルの情報は、メタデータ管理手段６９により結合テーブルメタデータ７３として管理される。
【００９０】
上述したように、本実施形態では、含まれている実テーブルは異なるが格納されるデータ内容が互いに同一のカラムは、何れか１つの実テーブルに属するものとして扱われるので、テーブルジョイン手段６８によって必要以上に多くのテーブルが結合されることはない。また、検索するデータが存在しない実テーブルは、ジョインの対象テーブルとしては抽出されない。
【００９１】
これにより、ユーザがデータベースの検索を行うときに、不要な実テーブルはジョインの対象としないようにすることができ、必要最小限の実テーブルだけで１つの結合テーブルを作ることができる。また、複数の実テーブル２１，２２，２３，……のジョインに関するメタデータをメタデータ管理手段６９の１ヵ所に収集して管理することによって、データベースの物理的な制約を越えて長いビューを作ることができるようになる。つまり、データベース管理システム（ＤＢＭＳ：Database Management System）から見ればジョインされた複数のテーブル、ユーザから見れば１つのテーブルという状況を作り出している。
【００９２】
図８において、結合テーブル生成手段６５に入力されるＳＱＬ７４は、ユーザが実際に検索しようとして入力するＳＱＬである。このとき、メタデータ管理手段６９で管理されている仮想テーブルに対して検索を行うことができる。すなわち、ユーザはカラム数の制約を意識せずに検索条件を入力することができる。ユーザから入力されたＳＱＬ７４が、ＲＤＢＭＳのカラム数の制約を越えているような範囲まで検索を行いたいという命令であれば、以下、結合テーブル生成手段６５で上述のような処理を行い、検索エンジン用ＳＱＬ７５を排出する。
【００９３】
検索エンジン用ＳＱＬ７５は、検索エンジン６０が検索を行えるような形態で結合テーブル生成手段６５から出力される。検索エンジン用ＳＱＬ７５は、不要な部分を取り除かれ必要最小限のカラムが選択された状態の結合テーブルを検索対象としている。この情報はメタデータ管理手段６９で管理された情報であり、例えば結合テーブルは実テーブルのどのカラムと、他の実テーブルのどのカラムとから構成されているという結合テーブルメタデータ７３であるので、検索エンジン６０はこれをもとに検索を行うことになる。
【００９４】
次に、上記のように構成した本実施形態による結合テーブル作成の動作を、図９〜図１２を用いてより詳しく説明する。ここでは一例として、図１３に示したのと同じデータベースを検索するとき、検索しようとするデータがビューＸ上のカラムx1,x4,x8,x9 に関わるものであったとする。
【００９５】
図９に示すように、ビューＸのカラムx1は実テーブルＡ，Ｂ，Ｃのカラムa1,b1,c1に、ビューＸのカラムx4は実テーブルＡのカラムa4に、ビューＸのカラムx8は実テーブルＢ，Ｃのカラムb5,c2 に、ビューＸのカラムx9は実テーブルＣのカラムc3にそれぞれ対応する。本実施形態の結合処理では、検索時のジョインテーブル数がなるべく少なくなるように、検索対象の４つのカラムx1,x4,x8,x9 それぞれに対して、対応する実カラムを１つずつ選び出す。
【００９６】
すなわち、ビューＸの４つのカラムx1,x4,x8,x9 と関連がある実テーブルＡ，Ｂ，Ｃ上のカラムは、全部で７個（矢印で示すリンク１〜７）であり、これら合計７個のカラム（リンク）の中から以下に述べる処理によって４個のカラム（リンク）を選び出す。
【００９７】
まず、各実テーブルＡ，Ｂ，Ｃの中から、リンク数（検索対象のデータを含むカラムの数）が最も多い実テーブルを抽出する。テーブルジョインを行う前の初期状態においては、実テーブルＡ上ではカラムa1,a4 の２つ、実テーブルＢ上ではカラムb1,b5 の２つ、実テーブルＣ上ではカラムc1,c2,c3の３つが含まれており、実テーブルＣのリンク数（選択カラム数）が最も多いので、図１０に示すようにこれを採用する。
【００９８】
そして、この採用した実テーブルＣにひも付けられているリンク４，６，７を採用するとともに、実テーブルＣ内のカラムc1,c2,c3と同じデータが入っているカラムa1,b1,b5に対応するリンク１，３，５を削除する。これにより、ビューＸのカラムx1,x8,x9は、実テーブルＣ内にのみ属するものとして扱うようにする。なお、ここで残ったリンク２は、以降の処理にそのまま繰り越される。
【００９９】
次に、採用した実テーブルＣを除いた残りの実テーブルＡ，Ｂを対象として、リンク数（検索対象の選択カラム数）が最も多い実テーブルを抽出する処理を再び行う。この場合は、実テーブルＡに対するリンク数が１個であり、実テーブルＢに対するリンク数が０個なので、図１１に示すように実テーブルＡを採用するとともに、これにひも付けられているリンク２を採用する。これにより、未解決のリンク数が０個となるので、処理を終了する。
【０１００】
以上の処理の結果、図１２に示すように、３つの実テーブルＡ，Ｂ，Ｃの中から、検索するカラムx1,x4,x8,x9 が含まれる実テーブルとして実テーブルＡと実テーブルＣとを採用する。また、３つの実テーブルＡ，Ｂ，Ｃに張られた７個のリンク１〜７の中から４個のリンク２，４，６，７を採用するとともに、残りのリンク１，３，５を削除する。そして、採用した２つの実テーブルＡ，Ｃ間にジョイン条件を付加する。こうして、実テーブルＡのカラムa4と、実テーブルＣのカラムc1,c2,c3の４つのカラムから作られた新たなテーブルが生成される。これが先に述べた結合テーブル（仮想テーブル）である。
【０１０１】
このように、本実施形態では、いわゆるＤＢＭＳの前段として高度なＳＱＬ解析を行うことにより、検索に必要なジョインのみを発生させることができ、結合するテーブル数を減らすことができる。これにより、コンピュータのメモリ領域を必要以上に多く使用することなく、しかも検索信号（Query ）の発生時間や検索応答時間を速くすることができるようになる。
【０１０２】
なお、ここでは実テーブルが３つの場合について説明したが、本発明はこの数に限定されるものではない。一般に、実テーブルの数が多くなるほどジョインは複雑になり、コンピュータの負荷が非常に重くなるが、本実施形態のデータベースシステムはこのように実テーブルの数が多い場合に特に効果がある。
【０１０３】
また、上述した各実施形態は、その機能を実現するように各種のデバイスを動作させるべく、該各種デバイスと接続された装置あるいはシステム内のコンピュータに対し、上記実施形態の機能を実現するためのソフトウェアのプログラムコードを供給し、そのシステムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰＵ）に格納されたプログラムに従って上記各種デバイスを動作させることによって実施したものであるが、ハードウェア的に構成しても良い。
【０１０４】
この場合、上記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体、およびそのプログラムコードをコンピュータに供給するための手段、例えばかかるプログラムコードを格納した記録媒体は本発明を構成する。かかるプログラムコードを記憶する記録媒体としては、例えばフロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。
【０１０５】
また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。
【０１０６】
さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。
【０１０７】
上述したように、１つ以上のデータベースに格納されている実データに関するメタデータを第２のサーバに収集して管理し、この第２のサーバに対して検索をかけることによって検索要求に合致するメタデータを抽出するように構成したので、データベースおよびそれを管理する第１のサーバが複数存在していても、第２のサーバに対して検索をかければ、検索要求に合致するメタデータを全て抽出することできる。このためユーザは、データベース（第１のサーバ）が分散して存在していることを意識することなく、異なるデータベースの情報を第２のサーバの１箇所から全て得ることができ、分散している第１のサーバを全て把握して１つ１つ順にアクセスしていくという面倒な作業を行うことなく、所望の実データが格納されているデータベースを容易に見つけることができる。
【０１０８】
また、第１のサーバが、ユーザ端末から転送されてきたデータベースに対する検索要求をアクセスするデータベースに合う形式に変換する手段を備えたので、ユーザは分散されている個々のデータベースを意識することなく、標準的なフォーマットに従った検索条件を作成して発行すれば良くなり、分散している異なる種類のデータベースを抽象化してユーザの検索作業を簡単化することができる。
【０１０９】
また、第２のサーバが、第１のサーバでメタデータが更新されたとき、あるいは一定時間間隔毎にメタデータを取得する機能を備えたので、第２のサーバに収集されているメタデータは、検索を行う時点での最新の情報が結果として常に得られることとなり、正確なデータ検索を行うことができるようになるとともに、システムの変更にも柔軟に対応することができるようになる。また、このようなメタデータの更新処理は自動的に行われるので、分散化された第１のサーバで絶えず行われるデータの登録や削除、および第１のサーバ自体のネットワークへの接続・切断をユーザが把握する必要もなく、ユーザの負担を軽減することができる。
【図面の簡単な説明】
【０１１０】
【図１】第１の実施形態によるデータベースシステムの概念的な構成を示すブロック図である。
【図２】第１の実施形態によるデータベースシステムのソフトウェアおよびハードウェアイメージを示すブロック図である。
【図３】第１の実施形態によるデータベースシステムの全体の処理の流れを示すフローチャートである。
【図４】第１の実施形態によるデータベースシステムのメタＤＢの更新処理の流れを示すフローチャートである。
【図５】第１の実施形態によるデータベースシステムの一連の検索処理をユーザ端末、ＤＢサーバ、メタＤＢサーバ毎に示したフローチャートである。
【図６】メタデータのディレクトリ構造（レイヤ構造）の例を示す図である。
【図７】ＤＢに関するメタデータファイルの記述例を示す図である。
【図８】第２の実施形態によるデータベースシステムの一構成例を示すブロック図である。
【図９】第２の実施形態によるデータベースシステムの検索動作（本実施形態によるデータベース検索方法）を説明するための図である。
【図１０】第２の実施形態によるデータベースシステムの検索動作（本実施形態によるデータベース検索方法）を説明するための図である。
【図１１】第２の実施形態によるデータベースシステムの検索動作（本実施形態によるデータベース検索方法）を説明するための図である。
【図１２】第２の実施形態によるデータベースシステムの検索動作（本実施形態によるデータベース検索方法）を説明するための図である。
【図１３】実テーブルのリレーション関係を説明するための図である。
【符号の説明】
【０１１１】
１０  ユーザ端末
１１  ＷＷＷブラウザ
１１ａ  ＧＵＩ部
１１ｂ  検索要求転送部
２０  ＤＢ
２１，２２，２３  実テーブル
３０  ＤＢサーバ
３１ａ  検索要求受付部
３１ｂ  メタデータ提供部
３２  検索実行部
３３  メタデータ
４０  メタＤＢサーバ
４１  メタＤＢ
４２  メタＤＢ管理部
４３ａ  メタＤＢ検索受付部
４３ｂ  検索要求作成部
５０  ネットワーク
６０  検索エンジン
６５  結合テーブル生成手段
６６  カラム数最大テーブル抽出手段
６７  同一データ選択カラム除外手段
６８  テーブルジョイン手段
６９  メタデータ管理手段
７０  メタデータ記憶手段
７１  実テーブルメタデータ
７２  仮想テーブルメタデータ
７３  結合テーブルメタデータ
７４  ユーザ用ＳＱＬ
７５  検索エンジン用ＳＱＬ
【図１】
0004318741.tif 000002
【図２】
0004318741.tif 000003
【図３】
0004318741.tif 000004
【図４】
0004318741.tif 000005
【図５】
0004318741.tif 000006
【図６】
0004318741.tif 000007
【図７】
0004318741.tif 000008
【図８】
0004318741.tif 000009
【図９】
0004318741.tif 000010
【図１０】
0004318741.tif 000011
【図１１】
0004318741.tif 000012
【図１２】
0004318741.tif 000013
【図１３】
0004318741.tif 000014