JPH11213014A - データベースシステム、データベース検索方法及び記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザにＤＢサーバが分散していることを意
識させずに容易に検索を行える仕組みを提供する。 【解決手段】 １つ以上のＤＢ２０に格納されている実
データに関するメタデータをメタＤＢサーバ４０の１箇
所に収集して管理し、このメタＤＢサーバ４０に対して
検索をかけることによって検索要求に合致するメタデー
タを抽出するようにすることにより、ＤＢ２０およびそ
れを管理するＤＢサーバ３０がネットワーク上に複数存
在していても、メタＤＢサーバ４０に対して検索をかけ
れば、どのＤＢ２０に関するメタデータであるかによら
ず、検索要求に合致するメタデータを全て抽出すること
できるようにして、分散しているＤＢ２０やＤＢサーバ
３０がどこにあるか分からなくても、検索要求にマッチ
するデータを全て１箇所から得ることができるようにす
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータベースシステ
ム、データベース検索方法及び記録媒体に関し、特に、
分散化された複数のデータベースから所望のデータを探
し出す検索システムに用いて好適なものである。

【０００２】

【従来の技術】近年におけるコンピュータの高性能化に
伴い、従来は１台のメインフレーム等の大型コンピュー
タで構成されていたものが、近年は複数のワークステー
ションあるいはパーソナルコンピュータなどで構成され
る分散型システムに移行されてきている。分散型にする
ことにより、システムの開発・保守が比較的容易になる
というメリットがある。分散型システムの例としては、
いわゆるインターネットが挙げられる。

【０００３】インターネットでは、複数のコンピュータ
がサーバあるいはクライアントとして世界中に分散さ
れ、それぞれが言うなれば１つの大きなデータベース
（以下、ＤＢと記す）として構成されている。そして、
これらのＤＢに対していくつかのプロトコルによりテキ
スト情報や画像情報などが登録されたり、あるいは読み
出されたりする。また、このようなインターネットに限
らず、莫大な量のデータを扱うシステムでは、ＤＢが分
散化される傾向にある。

【０００４】

【発明が解決しようとする課題】ところで、このように
分散化されたＤＢから所望の情報を読み出そうとした場
合、これらのＤＢを管理する全てのサーバから必要な情
報を検索するのは、非常に多くの時間と多くの労力とを
必要とする。すなわち、ユーザは読み出そうとする情報
が分散化しているＤＢのどこに格納されているか分から
ないので、それぞれのＤＢ毎に対応して設けられたサー
バを順にアクセスし、所望の情報が見つかるまで検索を
繰り返し行わなければならないという問題があった。

【０００５】また、ユーザがＤＢサーバの在り処（イン
ターネットのＵＲＬ（Uniform Resource Locator）等の
ようなアドレス情報）を全て把握していなければ、全て
のサーバから必要な情報を検索することは不可能であ
る。しかしながら、分散化されたＤＢサーバは、絶えず
データの登録や削除を行う可能性があり、また、ＤＢサ
ーバ自体のネットワークへの接続・切断も絶えず行われ
る可能性がある。したがって、これらのことをユーザが
全て把握することは極めて困難であり、正確な情報の検
索を行うことができないという問題もあった。

【０００６】このような不便さを解消するために、例え
ばインターネットでは検索エンジンと呼ばれるアドレス
検索サービスが存在する。検索エンジンは、自動的ある
いは手動でＵＲＬ情報を収集しており、例えばキーワー
ドの入力によって必要なＵＲＬの検索を行うことができ
る。例を挙げると、「特許」というキーワードについて
検索を行うと、特許に関連したサーバのＵＲＬが出力さ
れる。

【０００７】しかしながら、この検索エンジンでは、Ｄ
ＢサーバのＵＲＬ情報を検索するだけで、検索先のサー
バ内に構築されたＲＤＢＭＳ（リレーショナルＤＢ管理
システム）などの検索を行うことはできなかった。その
ため、ＲＤＢＭＳなどを検索する場合は、ユーザはまず
検索エンジンで希望するサーバを検索し、検索の結果を
見て所望のサーバに接続する。次いで、当該サーバに対
応したＤＢの検索方法を用いてそのＤＢ内の情報を検索
することになる。

【０００８】以上のように、従来は所望のデータを入手
する際に、各種データを格納したＤＢが分散化されてい
ると、そのデータの検索作業に多くの時間と労力を必要
としていた。

【０００９】さらに、上記ＲＤＢＭＳでは、１つのテー
ブル中に保持できる最大カラム数に制限があるのが通常
である。したがって、例えば最大カラム数が２５６の制
限を持ったＲＤＢＭＳでは、２５７カラム以上のテーブ
ルを作成する場合には、１テーブルが２５６カラム以下
のテーブル（実テーブル）を複数作成し、それらにリレ
ーションを設定することにより、見た目では１つのテー
ブル（ビュー）としてデータベースを構築している。

【００１０】例えば、図１３に示す１つのビューＸは、
３つの実テーブルＡ，Ｂ，Ｃから構成されており、これ
ら３つの実テーブルＡ，Ｂ，Ｃの間にはリレーションが
設定されている。すなわち、各実テーブルＡ，Ｂ，Ｃの
キーとなるカラムa1,b1,c1に互いに同一のデータを格納
して、これらのカラムa1,b1,c1をジョインキーとしてビ
ューＸのカラムx1を構成することにより、独立した３つ
のテーブル間の整合性をとっている。つまり、ビューＸ
のカラムx1は、上記３つのカラムa1,b1,c1のそれぞれと
共通するものである。

【００１１】また、実テーブルＡのカラムa2,a3,a4はビ
ューＸのカラムx2,x3,x4に、実テーブルＢのカラムb2,b
3,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とで共通のデータを持
っているので、実テーブルＢは使わなくても、カラムx
8,x9 の両方に対応した実テーブルＣだけで実際は検索
を行うことができるものである。また、このビューＸの
カラムx8,x9 は実テーブルＡのどのカラムにも対応して
いないので、実テーブルＡに対する検索も本来は不要で
ある。

【００１５】すなわち、従来のＤＢシステムでは、必要
以上に多くの実テーブルを結合（ジョイン）して広い範
囲を検索していた。このような処理は、ＤＢの検索時間
を長く伸ばすだけでなく、システムを構成するコンピュ
ータのメモリ領域を必要以上に多く使用してしまい、結
果的に検索のパフォーマンスを低下させることになると
いう問題を有する。

【００１６】また、ユーザがＤＢを検索するときは、必
ず全ての実テーブルのジョインが発生するが、ＲＤＢＭ
Ｓの提供するビューではカラム数の制限が実テーブルと
同様に存在するため、物理的な制約を越えて長いビュー
を作ることはできない。したがって、制約を越えた長い
ビューの中身を見るときには各実テーブル毎、もしくは
各実テーブル毎のデータを統合するカスタムメイドのア
プリケーションプログラムをその都度作成し、ユーザに
提示しなければならなかった。

【００１７】本発明は、上述のような問題を解決するた
めに成されたものであり、分散化されたＤＢおよびその
サーバにより構成されるＤＢシステムにおいて、ユーザ
にＤＢサーバが分散していることを意識させずに容易に
検索を行える仕組みを提供することを目的とする。また
本発明は、分散化された各サーバに格納されているＤＢ
に関する情報を常に把握し、検索を行う時点での最新の
情報が結果として得られる仕組みをユーザの負荷を伴わ
ずに提供することも目的とする。

【００１８】また本発明は、リレーショナルデータベー
スシステムで、テーブルの結合を行って検索を行う場合
に、高速に、しかもメモリの占有率を抑えて処理するこ
とができるデータベースシステムを提供することを目的
とする。また、データベースの物理的な制約を越えて長
いビューを作れるようにすることをも目的とする。

【００１９】

【課題を解決するための手段】本発明のデータベース検
索システムは、１つ以上のデータベースと、該データベ
ースに対して実データの検索を行う１つ以上の第１のサ
ーバとがネットワーク上に分散されて構成されたデータ
ベースシステムにおいて、上記１つ以上のデータベース
に格納されている実データに関するメタデータを上記１
つ以上の第１のサーバから収集して管理するメタデータ
管理手段と、上記ネットワーク上に接続されたユーザ端
末からの要求に応じて検索を行い、上記要求に合致する
メタデータを抽出するメタデータ検索手段とを備えたこ
とを特徴とする。ここで、上記メタデータ管理手段およ
び上記メタデータ検索手段は、上記第１のサーバとは異
なる１つ以上の第２のサーバ内に設けても良い。

【００２０】本発明の他の特徴とするところは、上記メ
タデータには、少なくとも上記データベースあるいは上
記第１のサーバの存在場所と上記データベース内の実デ
ータの内容を表す情報とが含まれることを特徴とする。

【００２１】本発明のその他の特徴とするところは、上
記ユーザ端末は、上記メタデータの検索要求を入力する
ための手段と、上記メタデータ検索手段から与えられる
上記メタデータの検索結果を用いて、上記データベース
上で実データの検索を行う際の検索条件を入力するため
の手段と、上記入力された検索条件を上記抽出されたメ
タデータによって示される上記第１のサーバに検索要求
として転送する手段とを備えることを特徴とする。

【００２２】本発明のその他の特徴とするところは、上
記メタデータ検索手段での検索結果によらず共通に使用
可能な上記検索条件を入力するためのフォームを提供す
る手段を備えることを特徴とする。本発明のその他の特
徴とするところは、上記第１のサーバは、上記ユーザ端
末から転送されてきた上記データベースに対する検索要
求を、アクセスするデータベースに合う形式に変換する
変換手段を備えたことを特徴とする。

【００２３】本発明のその他の特徴とするところは、上
記第１のサーバは、自分が管理するデータベースに関す
るメタデータを作成して保管するメタデータ保管手段を
備え、上記第２のサーバは、上記メタデータ保管手段内
の格納データが更新されたときに、対応するメタデータ
を取得する手段を備えたことを特徴とする。また、第２
のサーバは、上記メタデータ保管手段内の格納データを
一定時間間隔毎に取得する手段を備えても良い。

【００２４】また、本発明のデータベース検索方法は、
ネットワーク上に分散して存在する各データベースに格
納されている実データに関するメタデータを、上記ネッ
トワーク上に分散して存在する第１のサーバを介して第
２のサーバで収集して保管する工程と、上記収集された
メタデータに対して検索を行うことによって要求に合致
するメタデータを抽出する工程と、上記メタデータの検
索結果をもとに上記データベースに対する検索条件を入
力する工程と、上記抽出されたメタデータによって示さ
れる第１のサーバに上記実データの検索要求を発する工
程と、上記第１のサーバがこれに対応するデータベース
に対して上記検索要求に従って上記実データの検索を実
行する工程とを有することを特徴とする。

【００２５】また、本発明の記録媒体は、１つ以上のユ
ーザ端末と、１つ以上のデータベースと、該データベー
スに対して実データの検索を行う１つ以上の第１のサー
バと、上記１つ以上のデータベースに格納されている実
データに関するメタデータを上記１つ以上の第１のサー
バから収集して管理する１つ以上の第２のサーバとをネ
ットワーク上に分散して構成したデータベースシステム
において、分散された各データベースのメタデータを上
記第１のサーバを介して上記第２のサーバで収集する機
能と、ユーザからの検索要求があったときに、上記収集
されたメタデータに対して検索を行うことによって要求
に合致するメタデータを抽出する機能と、上記メタデー
タの検索結果をもとに上記ユーザ端末で上記データベー
スに対する検索条件を入力し、上記抽出されたメタデー
タによって示される第１のサーバに上記実データの検索
要求を発する機能と、上記第１のサーバが上記検索要求
に従って上記実データの検索を実行する機能とをコンピ
ュータに実現させるためのプログラムを記録したことを
特徴とする。

【００２６】本発明は上記技術手段より成るので、１つ
以上のデータベースに関するメタデータを収集管理して
いる第２のサーバに対して検索要求を発すると、その要
求に合致するメタデータが全て抽出されてユーザに提示
される。データベースおよびそれを管理する第１のサー
バがネットワーク上に複数存在していても、第２のサー
バに対して検索をかければ、どのデータベースに関する
メタデータであるかによらず、検索要求に合致するメタ
データが全て抽出される。このため、ユーザは分散して
いるデータベースや第１のサーバがどこにあるか分から
なくても、第２のサーバの在り処さえ知っていれば、検
索要求にマッチするデータを全て１ヵ所から得ることが
できる。このように第２のサーバは、メタデータを他の
コンピュータに提供する手段を備え、同時にネットワー
ク上の各データベースを一般化し、全てのデータベース
に対する検索のための同一な入口を提供する。

【００２７】本発明の他の特徴によれば、メタデータに
は少なくともデータベースあるいは第１のサーバの存在
場所と、データベース内の実データの内容を表す情報と
が含まれているので、検索要求に合致する実データが存
在するデータベースあるいはそれを管理する第１のサー
バの在り処は、メタデータの検索によって同時に知るこ
とができる。よって、ユーザは第２のサーバの在り処さ
れ分かっていれば良く、分散しているデータベースおよ
びそれを管理する第１のサーバの在り処を把握する必要
はない。

【００２８】本発明のその他の特徴によれば、ユーザ端
末が、メタデータの検索結果を用いて実データの検索を
行う際の検索条件を入力するための手段と、入力された
検索条件を第１のサーバに検索要求として転送する手段
とを備えたので、メタデータの検索によって所望の実デ
ータが存在するデータベースの在り処を知った後は、検
索条件を入力して実データの検索を実行することができ
る。

【００２９】本発明のその他の特徴によれば、第１のサ
ーバが、ユーザ端末から転送されてきたデータベースに
対する検索要求をアクセスするデータベースに合う形式
に変換する手段を備えたので、ユーザは分散されている
個々のデータベースを意識することなく、標準的なフォ
ーマットに従った検索条件を作成して発行すれば良くな
り、分散している異なる種類のデータベースを抽象化す
ることができる。

【００３０】本発明のその他の特徴によれば、第２のサ
ーバが、第１のサーバでメタデータが更新されたとき、
あるいは一定時間間隔毎にメタデータを取得する機能を
備えたので、第２のサーバに収集されているメタデータ
は、検索を行う時点での最新の情報が結果として常に得
られることとなり、システムの変更等に対して柔軟に対
応することが可能となる。

【００３１】また、本発明によるデータベースシステム
の他の態様では、リレーショナルデータベースで複数の
テーブルを結合して検索を行うデータベースシステムで
あって、上記複数のテーブルの中から検索対象のカラム
を含むテーブルを１つ抽出するテーブル抽出手段と、上
記テーブル抽出手段により抽出されたテーブルのカラム
およびそれと同じデータ内容が入っている他のテーブル
のカラムをその後の処理において抽出の対象から除外す
るようにする処理を行うカラム除外手段とを備え、上記
テーブル抽出手段による処理と上記カラム除外手段によ
る処理とを、上記検索対象のカラムが全て解析されるま
で繰り返し行い、そのとき上記テーブル抽出手段により
順次抽出されたテーブルを結合させるようにしたことを
特徴とする。

【００３２】本発明の他の特徴とするところは、上記テ
ーブル抽出手段は、上記複数のテーブルの中から、検索
対象のカラムを最も多く含むテーブルを１つ抽出するこ
とを特徴とする。

【００３３】本発明のその他の特徴とするところは、複
数のテーブルの結合に関するメタデータを収集して管理
するメタデータ管理手段を更に備え、上記テーブル抽出
手段は上記メタデータ管理手段内のメタデータをもとに
テーブルの抽出処理を行うことを特徴とする。

【００３４】本発明のその他の特徴とするところは、検
索キーに応じて物件を検索する検索手段を更に設け、上
記テーブル抽出手段により抽出され結合されたテーブル
に対して検索処理を行うことを特徴とする。

【００３５】また、本発明のデータベース検索方法の他
の態様では、リレーショナルデータベースで複数のテー
ブルを結合して検索を行う際に、上記複数のテーブルの
中から検索対象のカラムを含むテーブルを１つ抽出し、
抽出したテーブルのカラムと同じデータ内容が入ってい
る他のテーブルのカラムを除外した上で、上記抽出した
テーブルを除いた残りのテーブルを対象としてテーブル
を更に１つ抽出するというように、テーブルを抽出する
処理と同一データのカラムを除外する処理とを上記検索
対象のカラムが全て解析されるまで繰り返し行い、その
とき順次抽出された１つ以上のテーブルを結合させるよ
うにしたことを特徴とする。

【００３６】本発明の他の特徴とするところは、上記複
数のテーブルの中から１つのテーブルを抽出する際に、
上記複数のテーブルの中から、検索対象のカラムを最も
多く含むテーブルを１つ抽出することを特徴とする。本
発明のその他の特徴とするところは、上記結合された１
つ以上のテーブルに対して検索処理を行うことを特徴と
する。

【００３７】また、本発明の記録媒体の他の態様では、
リレーショナルデータベースで複数のテーブルを結合し
て検索を行う際に、上記複数のテーブルの中から検索対
象のカラムが最も多く含まれるテーブルを抽出する手段
と、抽出したテーブルのカラムおよびそれと同じデータ
内容が入っている他のテーブルのカラムをその後の処理
において除外するようにする手段と、上記の各手段の処
理を上記検索対象のカラムが全て解析されるまで繰り返
し行い、そのとき順次抽出された１つ以上のテーブルを
結合させる手段とをコンピュータに実現させるためのプ
ログラムを記録したことを特徴とする。

【００３８】本発明の他の特徴とするところは、上記テ
ーブル抽出手段により抽出され結合されたテーブルに対
して、検索キーに応じて物件を検索する検索手段を更に
設け、各手段をコンピュータに実現させるためのプログ
ラムを記録したことを特徴とする。

【００３９】本発明は上記技術手段より成るので、互い
にデータ内容が同一のカラムが異なるテーブル上に存在
する場合は、そのデータ内容が同一のカラムは、処理の
過程で何れか１つのテーブル（例えば検索対象のカラム
数が最も多いとされたテーブル）に属するものとして扱
われ、同一のカラムを含むテーブルの全てが必ずしも結
合（ジョイン）の対象とはされないようになる。また、
検索対象のカラムが存在しないテーブルは、ジョインの
対象テーブルとしては抽出されないようになる。これに
より、必要以上に多くのテーブルが結合されることがな
くなる。

【００４０】本発明の他の特徴によれば、複数のテーブ
ルが個々に管理されるのではなく、ジョインに関するメ
タデータの収集によって一元的に管理されるので、デー
タベースシステムから見ればジョインされた複数のテー
ブルであるが、ユーザから見れば１つのテーブルという
状況、すなわち、データベースのカラム数等の物理的な
制約を越えて長いビューを作ることが可能となる。

【００４１】

【発明の実施の形態】以下、本発明の一実施形態を図面
に基づいて説明する。 （第１の実施形態）図１は、第１の実施形態によるデー
タベースシステムの概念的な構成を示すブロック図であ
り、図２は、当該データベース検索システムのソフトウ
ェアおよびハードウェアイメージを示すブロック図であ
る。

【００４２】図１において、１０はユーザ端末であり、
ＷＷＷ（world wide web）ブラウザ１１を搭載し、検索
のキーワード入力、検索要求、検索結果の表示等をこの
ＷＷＷブラウザ１１上で行う。後述するメタＤＢに対す
る検索か、実データに対する検索かは、このＷＷＷブラ
ウザ１１上で指定する。このＷＷＷブラウザ１１は、図
２に示すようにＧＵＩ部１１ａと検索要求転送部１１ｂ
とを備え、ＧＵＩ部１１ａによって検索のための種々の
操作を行うとともに、検索要求転送部１１ｂによって検
索要求信号を転送するようになっている。

【００４３】２０はデータベース（ＤＢ）であり、実際
のデータが格納されている。このＤＢ２０は、ネットワ
ーク上に少なくとも１つ以上存在する。このＤＢ２０に
対して検索を行うためのプラットホームやＤＢアプリケ
ーションは問わないが、例えばＳＱＬ（Structured Que
ry Language ：表型のデータ構造を持つリレーショナル
ＤＢ向けのデータベース言語）等の検索手段によりデー
タ検索を行うことができるようになっている。

【００４４】３０はＤＢサーバであり、図２に示すよう
に検索要求受付部３１ａおよびメタデータ提供部３１ｂ
を備えたＨＴＴＰＤ(Hyper Text Transfer Protcol）３
１と、ＤＢネットワーククライアントより成る検索実行
部３２とを搭載している。基本的には、１つのＤＢ２０
に対して１つのＤＢサーバ３０が設けられるが、１つの
ＤＢサーバ３０が複数のＤＢ２０を管理することもあ
る。

【００４５】このＤＢサーバ３０は、ユーザ端末１０か
らの検索要求に応答してＤＢ２０を検索し、ユーザ端末
１０に対して検索結果をＨＴＭＬ（Hyper Text Markup
Language）形式で回答する。その際、ユーザ端末１０か
らの検索要求をＤＢ２０に合う形に翻訳して渡すことに
より、異種ＤＢ間の差異を吸収する役割を持つ。ＤＢサ
ーバ３０はまた、自分が管理しているＤＢ２０に格納さ
れている実データに関するメタデータ３３を作成し、格
納する。

【００４６】ここでメタデータとは、ＤＢ２０に格納さ
れているデータの属性、意味内容、取得先、格納場所な
ど、データを管理するための情報を言う。本実施形態で
は特に、少なくともＤＢ２０がどういうデータを持って
いるのかというデータ内容、および当該ＤＢ２０にアク
セスするためのＵＲＬを含む。ＤＢサーバ３０は、後述
するメタＤＢサーバ４０からの要求に応じてこのメタデ
ータ３３をメタＤＢサーバ４０に提供する。

【００４７】図６に、上記メタデータ３３のディレクト
リ構造の例を示す。この図６は、１つのＤＢサーバ３０
が複数のＤＢ２０（ＤＢ１，ＤＢ２，ＤＢ３，…）を管
理している例について示したものであり、それぞれのＤ
Ｂのディレクトリ内には、そのＤＢに関するメタデータ
ファイル、ＤＢを構成するテーブルに関するメタデータ
ファイル、およびテーブル内の各カラム１〜ｎに関する
メタデータファイルが含まれていることが示されてい
る。

【００４８】図７は、上記ＤＢに関するメタデータファ
イルの具体的内容を代表として示したものである。図７
に示すように、ＤＢのメタデータとしては、DBKEY,DBEX
PL,DBMS,DBLIMIT,SERIAL,CHECK,RETRY,EMAIL,TBLFILE,D
BNAME,SQLURLの各情報が含まれる。以下、これらの各情
報について１つずつ説明していく。

【００４９】DBKEY はＤＢに関するキーワードであり、
ここでは「デモ、社員」というキーワードが記述されて
いる。DBEXPLはＤＢの内容説明であり、ここでは「社員
情報」という説明が記述されている。DBMSはＤＢシステ
ムの名前であり、ここでは「OracleWorkgroupServer-7.
3 」という名前が記述されている。DBLIMIT はＤＢへの
アクセス制限であり、ここでは「allow @foo.co.jp;den
y all 」と記述されている。つまり“@foo.co.jp”のア
ドレスを持つユーザのアクセスは許可するが、それ以外
のユーザのアクセスは拒否することが記述されている。

【００５０】また、SERIALは更新チェックのために使用
するメタデータのシリアル番号であり、ここでは「1997
1225000000」と記述されており、1997年12月25日にメタ
データが更新されたことが示されている。CHECK はメタ
データの更新チェックの時間間隔 [秒] であり、ここで
は「3600秒」という時間が記述されている。RETRY はメ
タデータの更新チェックの失敗時におけるリトライの時
間間隔 [秒] であり、ここでは「600 秒」という時間が
記述されている。

【００５１】また、EMAIL はＤＢの管理者のメールアド
レスであり、ここでは「dbnavi@foo.co.jp」というアド
レスが記述されている。TBLFILE はＤＢのテーブルに関
するメタデータが記述されているファイル名であり、こ
こでは「tables.html 」という名前が記述されている。
DBNAMEはＤＢの登録名であり、ここでは「demo@navi.fo
o.co.jp 」という名前が記述されている。SQLURLはＤＢ
への検索実行要求先のＵＲＬであり、ここでは「http:/
/navi.foo.co.jp:8080/servlet/DBNAVI/service 」とい
うＵＲＬが記述されている。

【００５２】また、図示は省略するが、テーブルのメタ
データファイルやカラムのメタデータファイルに関して
は、図７に示したＤＢのメタデータファイルと書式は同
様であるが、異なる内容のメタデータが複数記述されて
いる。ここで、テーブルのメタデータとしては、COLFIL
E,TBLNAME,DBNAME,TBLOWNER,TBLNAME2,TBLKEY,TBLEXPL,
TBLDATE,TBLMODIFY,NCOLS,NROWS,TBLLIMITの各情報が含
まれる。以下、これらの各情報について１つずつ説明し
ていく。

【００５３】COLFILE はカラムに関するメタデータが記
述されているファイル名、TBLNAMEはテーブル名、DBNAM
EはＤＢ名であり、図７に示したＤＢのメタデータファ
イル中に記述されたものと同じものである。TBLOWNERは
テーブルの所有者名、TBLNAME2は日本語によるテーブル
名、TBLKEYはテーブルに関するキーワード、TBLEXPLは
テーブルの内容説明、TBLDATE はテーブルの作成日時、
TBLMODIFY はテーブルの更新タイミング、NCOLS はテー
ブル内のカラム数、NROWS はテーブル内の行数、TBLLIM
ITはテーブルへのアクセス制限を示す情報である。

【００５４】また、カラムのメタデータとしては、COLN
AME,DBNAME,TBLNAME,TBLOWNER,COLNAME2,CODEFILE,COLK
EY,COLEXPL,COLHANDLER,COLHINFO,COLATTR,COLTYPE,COL
UNIT,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 AreaNe
twork）、あるいはイントラネットなどにも適用するこ
とが可能である。

【００９６】また、以上の実施形態では、ＤＢ２０の一
例としてリレーショナルＤＢを例に挙げたが、本発明で
対象とするＤＢはこれに限られるものではない。また、
ＤＢで扱うデータの内容も、テキストデータ、画像デー
タ、音声データなど様々な形態とすることが可能であ
る。

【００９７】（第２の実施形態）次に、本発明の第２の
実施形態を図面に基づいて説明する。図８は、本実施形
態によるデータベースシステムの一構成例を示すブロッ
ク図である。図８に示す本実施形態のデータベースシス
テムは、これ単独で使用することも可能であるし、図１
に示した第１の実施形態と組み合わせて使用することも
可能である。

【００９８】第１の実施形態と組み合わせて使用する場
合、例えば、図８中に一点鎖線で示したデータベース２
０以外の機能構成を、図１のＤＢサーバ３０が備えるこ
とによって実現できる。また、図８の検索エンジン６０
および結合テーブル生成手段６５のみを図１のＤＢサー
バ３０が備え、図８のメタデータ管理手段６９およびメ
タデータ記憶手段７０は、図１のメタＤＢサーバ４０が
備えるようにしても良い。

【００９９】また、本実施形態のデータベースシステム
を第１の実施形態と組み合わせて適用する場合、使用す
るメタデータとしては、ジョイン保証されている他のＤ
Ｂ名（JOINABLE）がＤＢレイヤのファイル中に追加さ
れ、後述する仮想テーブルで表される複数の実テーブル
とカラムとの対応を記述したマップ情報（JOINMAP ）が
テーブルレイヤのファイル中に追加され、実カラム名
（REALCOL ）がカラムレイヤのファイル中に追加され
る。

【０１００】以下では、図８に示す各機能構成について
説明する。６０は検索エンジンであり、ＳＱＬ文で要求
された検索条件に基づいてデータベース２０内のデータ
を検索する。データベース２０には複数の実テーブル２
１，２２，２３，……が格納されている。これらの実テ
ーブル２１，２２，２３，……は、ＲＤＢＭＳの制約に
合致した形式で格納されており、検索エンジン６０から
は各実テーブルの検索を行うことができるようになって
いる。

【０１０１】６９はメタデータ管理手段であり、上記複
数の実テーブル２１，２２，２３，……に関するメタデ
ータを管理している。ここでメタデータとは、各実テー
ブル２１，２２，２３，……に格納されているデータの
属性、意味内容、取得先、格納場所など、データを管理
するための情報を言い、例えば上記第１の実施形態で述
べたものと同様なものである。このメタデータは、デー
タベース２０から定期的あるいは不定期に取得され、メ
タデータ記憶手段７０に記憶される。メタデータ管理手
段６９は、このメタデータをメタデータ記憶手段７０に
記憶させたり、読み出して使用したりする。

【０１０２】例えば、図８において、データベース２０
には実テーブル２１，２２，２３，……が格納されてい
るので、メタデータ管理手段６９は実テーブル２１，２
２，２３，……のテーブル名および各テーブルを構成し
ているカラムのカラム名を取得し、メタデータ記憶手段
７０に実テーブルメタデータ７１として記憶する。この
ように記憶させる情報は、テキストデータでも簡単に記
載できる形態なので、管理者などが手動で作成し記憶さ
せても良い。

【０１０３】また、複数のテーブルの結合に関する情報
も、このメタデータ管理手段６９により仮想テーブルメ
タデータ７２として管理されている。例えば、２つの実
テーブル２１，２２から作られた仮想テーブルのメタデ
ータであれば、実テーブル２１，２２のテーブル名と、
各テーブルの全てのカラム名とがメタデータとして記憶
されている。同様に、３つの実テーブル２１，２２，２
３から作られた仮想テーブルであれば、３つのテーブル
名と、各テーブルの全てのカラム名とが記憶されてい
る。

【０１０４】６５は結合テーブル生成手段であり、カラ
ム数最大テーブル抽出手段６６、同一データ選択カラム
除外手段６７およびテーブルジョイン手段６８から構成
されている。結合テーブル生成手段６５は、メタデータ
管理手段６９で管理されているメタデータをもとに、複
数の実テーブル２１，２２，２３，……から必要なカラ
ムだけを抽出して仮想的に新たなテーブルを作る機能を
持っている。なお、本実施形態では、従来のビューと同
様に所定カラムを結合する作業を行うが、本実施形態で
結合された仮想テーブルは、従来のビューとは形態が異
なっている。

【０１０５】カラム数最大テーブル抽出手段６６は、上
記メタデータ管理手段６９にて管理されているメタデー
タをもとに、実テーブル２１，２２，２３，……の中か
ら、検索しようとするデータが格納されているカラムの
数が最も多い実テーブルを抽出する。このとき、抽出し
た実テーブルに含まれるカラムと同じデータ内容のカラ
ムが他の実テーブル内にも重複して存在している場合
は、そのカラムは抽出した実テーブル内にのみ属するも
のとして扱うようにする。

【０１０６】また、同一データ選択カラム除外手段６７
は、上記カラム数最大テーブル抽出手段６６により実テ
ーブルが１つ抽出される毎に、残った実テーブルに含ま
れる各カラムのうち、抽出された実テーブルのカラムと
同じデータ内容が入っているカラムを、以降続けて行わ
れるテーブルジョイン処理において除外するための処理
を行う。

【０１０７】カラム数最大テーブル抽出手段６６は、上
記同一データ選択カラム除外手段６７により該当するカ
ラムを除外した状態で、前回までに抽出した実テーブル
を除いた残りの実テーブルを対象としてカラム数最大の
実テーブルを抽出する処理を再び行う。以下同様にし
て、検索対象のカラム数が最も多い実テーブルを抽出す
る処理と、抽出した実テーブルのカラムと同じデータが
入っているカラムを除外する処理とを繰り返し行う。

【０１０８】テーブルジョイン手段６８は、カラム数最
大テーブル抽出手段６６により順次抽出された１つ以上
の実テーブルを結合させることにより、１つ以上の実テ
ーブルから論理的な１つの結合テーブル（仮想テーブ
ル）を作成する。この結合テーブルの情報は、メタデー
タ管理手段６９により結合テーブルメタデータ７３とし
て管理される。

【０１０９】上述したように、本実施形態では、含まれ
ている実テーブルは異なるが格納されるデータ内容が互
いに同一のカラムは、何れか１つの実テーブルに属する
ものとして扱われるので、テーブルジョイン手段６８に
よって必要以上に多くのテーブルが結合されることはな
い。また、検索するデータが存在しない実テーブルは、
ジョインの対象テーブルとしては抽出されない。

【０１１０】これにより、ユーザがデータベースの検索
を行うときに、不要な実テーブルはジョインの対象とし
ないようにすることができ、必要最小限の実テーブルだ
けで１つの結合テーブルを作ることができる。また、複
数の実テーブル２１，２２，２３，……のジョインに関
するメタデータをメタデータ管理手段６９の１ヵ所に収
集して管理することによって、データベースの物理的な
制約を越えて長いビューを作ることができるようにな
る。つまり、データベース管理システム（ＤＢＭＳ：Da
tabase 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,a
4 の２つ、実テーブルＢ上ではカラムb1,b5 の２つ、実
テーブルＣ上ではカラムc1,c2,c3の３つが含まれてお
り、実テーブルＣのリンク数（選択カラム数）が最も多
いので、図１０に示すようにこれを採用する。

【０１１７】そして、この採用した実テーブルＣにひも
付けられているリンク４，６，７を採用するとともに、
実テーブルＣ内のカラムc1,c2,c3と同じデータが入って
いるカラムa1,b1,b5に対応するリンク１，３，５を削除
する。これにより、ビューＸのカラムx1,x8,x9は、実テ
ーブルＣ内にのみ属するものとして扱うようにする。な
お、ここで残ったリンク２は、以降の処理にそのまま繰
り越される。

【０１１８】次に、採用した実テーブルＣを除いた残り
の実テーブルＡ，Ｂを対象として、リンク数（検索対象
の選択カラム数）が最も多い実テーブルを抽出する処理
を再び行う。この場合は、実テーブルＡに対するリンク
数が１個であり、実テーブルＢに対するリンク数が０個
なので、図１１に示すように実テーブルＡを採用すると
ともに、これにひも付けられているリンク２を採用す
る。これにより、未解決のリンク数が０個となるので、
処理を終了する。

【０１１９】以上の処理の結果、図１２に示すように、
３つの実テーブルＡ，Ｂ，Ｃの中から、検索するカラム
x1,x4,x8,x9 が含まれる実テーブルとして実テーブルＡ
と実テーブルＣとを採用する。また、３つの実テーブル
Ａ，Ｂ，Ｃに張られた７個のリンク１〜７の中から４個
のリンク２，４，６，７を採用するとともに、残りのリ
ンク１，３，５を削除する。そして、採用した２つの実
テーブルＡ，Ｃ間にジョイン条件を付加する。こうし
て、実テーブルＡのカラムa4と、実テーブルＣのカラム
c1,c2,c3の４つのカラムから作られた新たなテーブルが
生成される。これが先に述べた結合テーブル（仮想テー
ブル）である。

【０１２０】このように、本実施形態では、いわゆるＤ
ＢＭＳの前段として高度なＳＱＬ解析を行うことによ
り、検索に必要なジョインのみを発生させることがで
き、結合するテーブル数を減らすことができる。これに
より、コンピュータのメモリ領域を必要以上に多く使用
することなく、しかも検索信号（Query ）の発生時間や
検索応答時間を速くすることができるようになる。

【０１２１】なお、ここでは実テーブルが３つの場合に
ついて説明したが、本発明はこの数に限定されるもので
はない。一般に、実テーブルの数が多くなるほどジョイ
ンは複雑になり、コンピュータの負荷が非常に重くなる
が、本実施形態のデータベースシステムはこのように実
テーブルの数が多い場合に特に効果がある。

【０１２２】また、上述した各実施形態は、その機能を
実現するように各種のデバイスを動作させるべく、該各
種デバイスと接続された装置あるいはシステム内のコン
ピュータに対し、上記実施形態の機能を実現するための
ソフトウェアのプログラムコードを供給し、そのシステ
ムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰ
Ｕ）に格納されたプログラムに従って上記各種デバイス
を動作させることによって実施したものであるが、ハー
ドウェア的に構成しても良い。

【０１２３】この場合、上記ソフトウェアのプログラム
コード自体が上述した実施形態の機能を実現することに
なり、そのプログラムコード自体、およびそのプログラ
ムコードをコンピュータに供給するための手段、例えば
かかるプログラムコードを格納した記録媒体は本発明を
構成する。かかるプログラムコードを記憶する記録媒体
としては、例えばフロッピーディスク、ハードディス
ク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気
テープ、不揮発性のメモリカード、ＲＯＭ等を用いるこ
とができる。

【０１２４】また、コンピュータが供給されたプログラ
ムコードを実行することにより、上述の実施形態の機能
が実現されるだけでなく、そのプログラムコードがコン
ピュータにおいて稼働しているＯＳ（オペレーティング
システム）あるいは他のアプリケーションソフト等と共
同して上述の実施形態の機能が実現される場合にもかか
るプログラムコードは本発明の実施形態に含まれること
は言うまでもない。

【０１２５】さらに、供給されたプログラムコードがコ
ンピュータの機能拡張ボードやコンピュータに接続され
た機能拡張ユニットに備わるメモリに格納された後、そ
のプログラムコードの指示に基づいてその機能拡張ボー
ドや機能拡張ユニットに備わるＣＰＵ等が実際の処理の
一部または全部を行い、その処理によって上述した実施
形態の機能が実現される場合にも本発明に含まれること
は言うまでもない。

【０１２６】

【発明の効果】本発明は上述したように、１つ以上のデ
ータベースに格納されている実データに関するメタデー
タを第２のサーバに収集して管理し、この第２のサーバ
に対して検索をかけることによって検索要求に合致する
メタデータを抽出するように構成したので、データベー
スおよびそれを管理する第１のサーバが複数存在してい
ても、第２のサーバに対して検索をかければ、検索要求
に合致するメタデータを全て抽出することできる。この
ためユーザは、データベース（第１のサーバ）が分散し
て存在していることを意識することなく、異なるデータ
ベースの情報を第２のサーバの１箇所から全て得ること
ができ、分散している第１のサーバを全て把握して１つ
１つ順にアクセスしていくという面倒な作業を行うこと
なく、所望の実データが格納されているデータベースを
容易に見つけることができる。

【０１２７】本発明のその他の特徴によれば、第１のサ
ーバが、ユーザ端末から転送されてきたデータベースに
対する検索要求をアクセスするデータベースに合う形式
に変換する手段を備えたので、ユーザは分散されている
個々のデータベースを意識することなく、標準的なフォ
ーマットに従った検索条件を作成して発行すれば良くな
り、分散している異なる種類のデータベースを抽象化し
てユーザの検索作業を簡単化することができる。

【０１２８】本発明のその他の特徴によれば、第２のサ
ーバが、第１のサーバでメタデータが更新されたとき、
あるいは一定時間間隔毎にメタデータを取得する機能を
備えたので、第２のサーバに収集されているメタデータ
は、検索を行う時点での最新の情報が結果として常に得
られることとなり、正確なデータ検索を行うことができ
るようになるとともに、システムの変更にも柔軟に対応
することができるようになる。また、このようなメタデ
ータの更新処理は自動的に行われるので、分散化された
第１のサーバで絶えず行われるデータの登録や削除、お
よび第１のサーバ自体のネットワークへの接続・切断を
ユーザが把握する必要もなく、ユーザの負担を軽減する
ことができる。

【０１２９】本発明のその他の特徴によれば、複数のテ
ーブルの中から検索対象のカラムを含むテーブルを１つ
抽出する処理と、抽出されたテーブルのカラムおよびそ
れと同じデータ内容が入っている他のテーブルのカラム
をその後の処理において抽出の対象から除外するように
する処理とを繰り返し行い、そのとき上記テーブル抽出
手段により順次抽出されたテーブルを結合させるように
したので、存在するテーブルは異なるが互いにデータ内
容が同一のカラムを何れか１つのテーブルに属するもの
として扱い、必要以上に多くのテーブルを結合しないよ
うにすることができる。また、検索対象のカラムが存在
しないテーブルは結合の対象としないようにすることが
でき、その結果、必要最小限のテーブルだけで１つの結
合テーブルを生成することができる。よって、不要なテ
ーブルは除外した比較的狭い範囲で検索を行うことがで
きるようになり、高速に、しかもメモリの占有率を抑え
て処理することができるデータベースシステムを提供す
ることができる。

【０１３０】本発明のその他の特徴によれば、複数のテ
ーブルの結合に関するメタデータを収集して管理し、こ
のメタデータをもとにテーブルの抽出処理を行うように
したので、複数のテーブルをメタデータの収集によって
一元的に管理することができ、データベースのカラム数
等の物理的な制約を越えて長いビューを作ることができ
る。

【図面の簡単な説明】

【図１】第１の実施形態によるデータベースシステムの
概念的な構成を示すブロック図である。

【図２】第１の実施形態によるデータベースシステムの
ソフトウェアおよびハードウェアイメージを示すブロッ
ク図である。

【図３】第１の実施形態によるデータベースシステムの
全体の処理の流れを示すフローチャートである。

【図４】第１の実施形態によるデータベースシステムの
メタＤＢの更新処理の流れを示すフローチャートであ
る。

【図５】第１の実施形態によるデータベースシステムの
一連の検索処理をユーザ端末、ＤＢサーバ、メタＤＢサ
ーバ毎に示したフローチャートである。

【図６】メタデータのディレクトリ構造（レイヤ構造）
の例を示す図である。

【図７】ＤＢに関するメタデータファイルの記述例を示
す図である。

【図８】第２の実施形態によるデータベースシステムの
一構成例を示すブロック図である。

【図９】第２の実施形態によるデータベースシステムの
検索動作（本実施形態によるデータベース検索方法）を
説明するための図である。

【図１０】第２の実施形態によるデータベースシステム
の検索動作（本実施形態によるデータベース検索方法）
を説明するための図である。

【図１１】第２の実施形態によるデータベースシステム
の検索動作（本実施形態によるデータベース検索方法）
を説明するための図である。

【図１２】第２の実施形態によるデータベースシステム
の検索動作（本実施形態によるデータベース検索方法）
を説明するための図である。

【図１３】実テーブルのリレーション関係を説明するた
めの図である。

【符号の説明】

１０ ユーザ端末 １１ ＷＷＷブラウザ １１ａ ＧＵＩ部 １１ｂ 検索要求転送部 ２０ ＤＢ ２１，２２，２３ 実テーブル ３０ ＤＢサーバ ３１ａ 検索要求受付部 ３１ｂ メタデータ提供部 ３２ 検索実行部 ３３ メタデータ ４０ メタＤＢサーバ ４１ メタＤＢ ４２ メタＤＢ管理部 ４３ａ メタＤＢ検索受付部 ４３ｂ 検索要求作成部 ５０ ネットワーク ６０ 検索エンジン ６５ 結合テーブル生成手段 ６６ カラム数最大テーブル抽出手段 ６７ 同一データ選択カラム除外手段 ６８ テーブルジョイン手段 ６９ メタデータ管理手段 ７０ メタデータ記憶手段 ７１ 実テーブルメタデータ ７２ 仮想テーブルメタデータ ７３ 結合テーブルメタデータ ７４ ユーザ用ＳＱＬ ７５ 検索エンジン用ＳＱＬ

Claims (24)

【特許請求の範囲】
1. 【請求項１】 １つ以上のデータベースと、該データベ
   ースに対して実データの検索を行う１つ以上の第１のサ
   ーバとがネットワーク上に分散されて構成されたデータ
   ベースシステムにおいて、 上記１つ以上のデータベースに格納されている実データ
   に関するメタデータを上記１つ以上の第１のサーバから
   収集して管理するメタデータ管理手段と、 上記ネットワーク上に接続されたユーザ端末からの要求
   に応じて検索を行い、上記要求に合致するメタデータを
   抽出するメタデータ検索手段とを備えたことを特徴とす
   るデータベースシステム。
2. 【請求項２】 上記メタデータ管理手段および上記メタ
   データ検索手段は、上記第１のサーバとは異なる１つ以
   上の第２のサーバ内に設けられることを特徴とする請求
   項１に記載のデータベースシステム。
3. 【請求項３】 上記メタデータには、少なくとも上記デ
   ータベースあるいは上記第１のサーバの存在場所と上記
   データベース内の実データの内容を表す情報とが含まれ
   ることを特徴とする請求項１または２に記載のデータベ
   ースシステム。
4. 【請求項４】 上記ユーザ端末は、上記メタデータの検
   索要求を入力するための手段と、 上記メタデータ検索手段から与えられる上記メタデータ
   の検索結果を用いて、上記データベース上で実データの
   検索を行う際の検索条件を入力するための手段と、 上記入力された検索条件を上記抽出されたメタデータに
   よって示される上記第１のサーバに検索要求として転送
   する手段とを備えることを特徴とする請求項１〜３の何
   れか１項に記載のデータベースシステム。
5. 【請求項５】 上記メタデータ検索手段での検索結果に
   よらず共通に使用可能な上記検索条件を入力するための
   フォームを提供する手段を備えることを特徴とする請求
   項４に記載のデータベースシステム。
6. 【請求項６】 上記第１のサーバは、上記ユーザ端末か
   ら転送されてきた上記データベースに対する検索要求
   を、アクセスするデータベースに合う形式に変換する変
   換手段を備えたことを特徴とする請求項４または５に記
   載のデータベースシステム。
7. 【請求項７】 上記第１のサーバは、自分が管理するデ
   ータベースに関するメタデータを作成して保管するメタ
   データ保管手段を備え、 上記第２のサーバは、上記メタデータ保管手段内の格納
   データが更新されたときに、対応するメタデータを取得
   する手段を備えたことを特徴とする請求項２〜６の何れ
   か１項に記載のデータベースシステム。
8. 【請求項８】 上記第１のサーバは、自分が管理するデ
   ータベースに関するメタデータを作成して保管するメタ
   データ保管手段を備え、 上記第２のサーバは、上記メタデータ保管手段内の格納
   データを一定時間間隔毎に取得する手段を備えたことを
   特徴とする請求項２〜６の何れか１項に記載のデータベ
   ースシステム。
9. 【請求項９】 上記データベースはリレーショナルデー
   タベースであり、 上記データベース内の複数のテーブルの中から検索対象
   のカラムを含むテーブルを１つ抽出するテーブル抽出手
   段と、 上記テーブル抽出手段により抽出されたテーブルのカラ
   ムおよびそれと同じデータ内容が入っている他のテーブ
   ルのカラムをその後の処理において抽出の対象から除外
   するようにする処理を行うカラム除外手段と、 上記テーブル抽出手段による処理と上記カラム除外手段
   による処理とを上記検索対象のカラムが全て解析される
   まで繰り返し行ったときに上記テーブル抽出手段により
   順次抽出されたテーブルを結合させるテーブル結合手段
   とを備え、 上記テーブル結合手段により結合されたテーブルに対し
   て上記実データの検索を行うようにしたことを特徴とす
   る請求項１〜８の何れか１項に記載のデータベースシス
   テム。
10. 【請求項１０】 ネットワーク上に分散して存在する各
    データベースに格納されている実データに関するメタデ
    ータを、上記ネットワーク上に分散して存在する第１の
    サーバを介して第２のサーバで収集して保管する工程
    と、 上記収集されたメタデータに対して検索を行うことによ
    って要求に合致するメタデータを抽出する工程と、 上記メタデータの検索結果をもとに上記データベースに
    対する検索条件を入力する工程と、 上記抽出されたメタデータによって示される第１のサー
    バに上記実データの検索要求を発する工程と、 上記第１のサーバがこれに対応するデータベースに対し
    て上記検索要求に従って上記実データの検索を実行する
    工程とを有することを特徴とするデータベース検索方
    法。
11. 【請求項１１】 １つ以上のユーザ端末と、１つ以上の
    データベースと、該データベースに対して実データの検
    索を行う１つ以上の第１のサーバと、上記１つ以上のデ
    ータベースに格納されている実データに関するメタデー
    タを上記１つ以上の第１のサーバから収集して管理する
    １つ以上の第２のサーバとをネットワーク上に分散して
    構成したデータベースシステムにおいて、 分散された各データベースのメタデータを上記第１のサ
    ーバを介して上記第２のサーバで収集する機能と、 ユーザからの検索要求があったときに、上記収集された
    メタデータに対して検索を行うことによって要求に合致
    するメタデータを抽出する機能と、 上記メタデータの検索結果をもとに上記ユーザ端末で上
    記データベースに対する検索条件を入力し、上記抽出さ
    れたメタデータによって示される第１のサーバに上記実
    データの検索要求を発する機能と、 上記第１のサーバが上記検索要求に従って上記実データ
    の検索を実行する機能とをコンピュータに実現させるた
    めのプログラムを記録したことを特徴とするコンピュー
    タ読み取り可能な記録媒体。
12. 【請求項１２】 １つ以上のデータベースと、該データ
    ベースに対して実データの検索を行う１つ以上の第１の
    サーバと、上記第１のサーバと異なる１つ以上の第２の
    サーバとをネットワーク上に分散して構成したデータベ
    ースシステムにおいて、 上記第１のサーバで作成される自分が管理しているデー
    タベースに関するメタデータが更新されたときに、上記
    第２のサーバが対応するメタデータを取得することによ
    り、上記１つ以上の第１のサーバから上記第２のサーバ
    に上記メタデータを収集して管理する機能をコンピュー
    タに実現させるためのプログラムを記録したことを特徴
    とするコンピュータ読み取り可能な記録媒体。
13. 【請求項１３】 １つ以上のデータベースと、該データ
    ベースに対して実データの検索を行う１つ以上の第１の
    サーバと、上記第１のサーバと異なる１つ以上の第２の
    サーバとをネットワーク上に分散して構成したデータベ
    ースシステムにおいて、 上記第１のサーバで作成される自分が管理しているデー
    タベースに関するメタデータを上記第２のサーバが一定
    時間間隔毎に取得することにより、上記１つ以上の第１
    のサーバから上記第２のサーバに上記メタデータを収集
    して管理する機能をコンピュータに実現させるためのプ
    ログラムを記録したことを特徴とするコンピュータ読み
    取り可能な記録媒体。
14. 【請求項１４】 １つ以上のユーザ端末と、１つ以上の
    データベースと、該データベースに対して実データの検
    索を行う１つ以上の第１のサーバと、上記１つ以上のデ
    ータベースに格納されている実データに関するメタデー
    タを上記１つ以上の第１のサーバから収集して管理する
    １つ以上の第２のサーバとをネットワーク上に分散して
    構成したデータベースシステムにおいて、 上記ユーザ端末からの要求に応じて検索を行い、上記要
    求に合致するメタデータを上記第２のサーバから抽出す
    る機能と、 上記メタデータの検索結果を用いて、上記データベース
    上で実データの検索を行う際の検索条件を入力するため
    の機能と、 上記入力した検索条件を上記抽出したメタデータによっ
    て示される上記第１のサーバに検索要求として転送する
    機能とをコンピュータに実現させるためのプログラムを
    記録したことを特徴とするコンピュータ読み取り可能な
    記録媒体。
15. 【請求項１５】 １つ以上のデータベースと、該データ
    ベースに対して実データの検索を行う１つ以上の第１の
    サーバとがネットワーク上に分散されて構成されたデー
    タベースシステムにおいて、 上記第１のサーバにおいて自分が管理するデータベース
    に関するメタデータを作成して保管するとともに、外部
    からの要求に応じてこれを提供する機能と、 上記ネットワーク上に接続されたユーザ端末から送られ
    てくる検索要求をアクセスするデータベースに合う形式
    に変換する機能と、 上記変換された検索要求に応じて上記データベースに対
    して上記実データの検索を実行する機能とをコンピュー
    タに実現させるためのプログラムを記録したことを特徴
    とするコンピュータ読み取り可能な記録媒体。
16. 【請求項１６】 リレーショナルデータベースで複数の
    テーブルを結合して検索を行うデータベースシステムで
    あって、 上記複数のテーブルの中から検索対象のカラムを含むテ
    ーブルを１つ抽出するテーブル抽出手段と、 上記テーブル抽出手段により抽出されたテーブルのカラ
    ムおよびそれと同じデータ内容が入っている他のテーブ
    ルのカラムをその後の処理において抽出の対象から除外
    するようにする処理を行うカラム除外手段とを備え、 上記テーブル抽出手段による処理と上記カラム除外手段
    による処理とを、上記検索対象のカラムが全て解析され
    るまで繰り返し行い、そのとき上記テーブル抽出手段に
    より順次抽出されたテーブルを結合させるようにしたこ
    とを特徴とするデータベースシステム。
17. 【請求項１７】 上記テーブル抽出手段は、上記複数の
    テーブルの中から、検索対象のカラムを最も多く含むテ
    ーブルを１つ抽出することを特徴とする請求項１６に記
    載のデータベースシステム。
18. 【請求項１８】 複数のテーブルの結合に関するメタデ
    ータを収集して管理するメタデータ管理手段を更に備
    え、上記テーブル抽出手段は上記メタデータ管理手段内
    のメタデータをもとにテーブルの抽出処理を行うことを
    特徴とする請求項１６または１７に記載のデータベース
    システム。
19. 【請求項１９】 検索キーに応じて物件を検索する検索
    手段を更に設け、上記テーブル抽出手段により順次抽出
    され結合されたテーブルに対して検索処理を行うことを
    特徴とする請求項１６〜１８の何れか１項に記載のデー
    タベースシステム。
20. 【請求項２０】 リレーショナルデータベースで複数の
    テーブルを結合して検索を行う際に、上記複数のテーブ
    ルの中から検索対象のカラムを含むテーブルを１つ抽出
    し、抽出したテーブルのカラムと同じデータ内容が入っ
    ている他のテーブルのカラムを除外した上で、上記抽出
    したテーブルを除いた残りのテーブルを対象としてテー
    ブルを更に１つ抽出するというように、テーブルを抽出
    する処理と同一データのカラムを除外する処理とを上記
    検索対象のカラムが全て解析されるまで繰り返し行い、
    そのとき順次抽出された１つ以上のテーブルを結合させ
    るようにしたことを特徴とするデータベース検索方法。
21. 【請求項２１】 上記複数のテーブルの中から１つのテ
    ーブルを抽出する際に、上記複数のテーブルの中から、
    検索対象のカラムを最も多く含むテーブルを１つ抽出す
    ることを特徴とする請求項２０に記載のデータベース検
    索方法。
22. 【請求項２２】 上記結合された１つ以上のテーブルに
    対して検索処理を行うことを特徴とする請求項２０また
    は２１に記載のデータベース検索方法。
23. 【請求項２３】 リレーショナルデータベースで複数の
    テーブルを結合して検索を行う際に、上記複数のテーブ
    ルの中から検索対象のカラムが最も多く含まれるテーブ
    ルを抽出する手段と、 抽出したテーブルのカラムおよびそれと同じデータ内容
    が入っている他のテーブルのカラムをその後の処理にお
    いて除外するようにする手段と、 上記の各手段の処理を上記検索対象のカラムが全て解析
    されるまで繰り返し行い、そのとき順次抽出された１つ
    以上のテーブルを結合させる手段としてコンピュータを
    機能させるためのプログラムを記録したことを特徴とす
    るコンピュータ読み取り可能な記録媒体。
24. 【請求項２４】 上記テーブル抽出手段により抽出され
    結合されたテーブルに対して、検索キーに応じて物件を
    検索する検索手段を更に設け、各手段としてコンピュー
    タを機能させるためのプログラムを記録したことを特徴
    とする請求項２３に記載のコンピュータ読み取り可能な
    記録媒体。