(57)【要約】  【課題】作成及びメンテナンスの負担が少なく、検索速度の速いデータベース装置を提供する。  【解決手段】  データベース装置のリレーション構造を作るマップテーブル２０の少なくとも一方側に、ルートテーブル２１と複数のブランチテーブル２２〜２５が設けられる。各ブランチテーブルは、同種のアイテムのデータを含む。ルートテーブル２１は、複数のブランチテーブル２２〜２５により網羅される多数のアイテムを個々に特定可能である。ブランチテーブル２２〜２５の各データは、ルートテーブル２１に一対一で関連付けられる。ルートテーブル２１は、マップテーブル２０により、その反対側のテーブル２６と多対多で関連付けられる。一のマップテーブルと、アイテム種類毎の複数のテーブルとが併存できる。好ましくは、ルートテーブル２１とブランチテーブル２２〜２５の参照量が検索条件に基づき比較され、検索の順序が決定される。【選択図】  図４
2006309798.tif 000002
【特許請求の範囲】
【請求項１】
マップテーブルを用いて、前記マップテーブルの両側のデータを多対多で関連付けるリレーション構造をもつデータベース装置であって、
前記マップテーブルの少なくとも一方側に、
それぞれが同種のアイテムのデータを含む複数のブランチテーブルと、
前記複数のブランチテーブルによって網羅されるアイテムを個々に特定可能なルートテーブルとを有し、
前記複数のブランチテーブルのデータは前記ルートテーブルの対応するデータと一対一で関連付けられ、
前記ルートテーブルのデータが前記マップテーブルによりそのマップテーブルの反対側のデータと関連付けられていることを特徴とするデータベース装置。
【請求項２】
請求項１に記載のデータベース装置であって、
前記ルートテーブルは前記複数のアイテムが共通して持つ共通属性のデータを含み、
更に、検索条件が前記ルートテーブルの属性に対応する条件と前記ブランチテーブルの属性に対応する条件とを含むとき、前記ルートテーブルの参照量と前記ブランチテーブルの参照量とに基づき、前記ルートテーブルと前記ブランチテーブルのいずれのテーブルを参照するかを決定する参照テーブル決定手段とを有し、
前記検索条件に基づく検索は、前記参照テーブル決定手段による決定に基づいて行われることを特徴とするデータベース装置。
【請求項３】
請求項２に記載のデータベース装置であって、
前記ルートテーブル及び前記ブランチテーブルが有する属性項目とそれらのテーブルに含まれるデータの数とが規定されたインデクステーブルをさらに有し、
前記参照テーブル決定手段は、前記インデクステーブルを参照して、前記検索条件に基づいて、前記ルートテーブル及び前記ブランチテーブルのうち参照量が少ない方のテーブルを参照することを決定することを特徴とするデータベース装置。
【請求項４】
請求項２又は３に記載のデータベース装置であって、
前記参照テーブル決定手段により決定されたテーブルを参照して前記検索条件に該当するデータを検索する一次検索手段と、
前記一次検索手段による検索において参照されなかったテーブルから、前記一次検索手段による検索において検索されたデータに対応するデータを抽出する抽出手段と、
前記抽出手段により抽出されたデータを参照して前記検索条件に該当するデータを検索する二次検索手段と、
を有することを特徴とするデータベース装置。
【請求項５】
請求項２乃至４のいずれかに記載のデータベース装置であって、
前記参照テーブル決定手段は、前記ルートテーブルの属性に対応する条件の個数と前記ルートテーブルに含まれるデータの数とに基づくルートテーブルの参照量と、前記ブランチテーブルの属性に対応する条件の個数とそのブランチテーブルのデータの数とに基づくブランチテーブルの参照量とを比較することにより、参照量の少ないテーブルを参照することを決定することを特徴とするデータベース装置。
【請求項６】
請求項１乃至５のいずれかに記載のデータベース装置であって、
前記アイテムは商品であり、前記ブランチテーブルは商品の種類毎に設けられていることを特徴とするデータベース装置。
【請求項７】
マップテーブルを用いて、前記マップテーブルの両側のデータを多対多で関連付けるリレーション構造をもつデータベース装置であって、
前記マップテーブルの少なくとも一方側に、ルートテーブルと該ルートテーブルに対応する複数のブランチテーブルとを有し、
前記複数のブランチテーブルの各データが前記ブランチテーブルのデータと一対一で関連付けられており、
前記ルートテーブルのデータが前記マップテーブルの反対側のデータと多対多で関連付けられていることを特徴とするデータベース装置。
【請求項８】
複数種類の商品のデータを含むデータベース装置であって、
商品の種類ごとに設けられ、その種類に含まれる商品のデータを含む複数の商品別ブランチテーブルと、
前記複数の商品別ブランチテーブルに含まれる商品のデータを含み、商品名や商品ＩＤなどの各商品を個々に特定可能な属性の列を持つルートテーブルと、を有することを特徴とするデータベース装置。
【請求項９】
請求項８に記載のデータベース装置であって、
前記ルートテーブルが、マップテーブルにより、商品取扱者の名称やＩＤなどの取扱者の属性を含むテーブルと関連付けられることにより多対多のリレーション構造が形成されていることを特徴とするデータベース装置。
【請求項１０】
マップテーブルを用いた多対多のリレーション構造を持つデータベースを構築するデータベース構築方法であって、
前記マップテーブルの少なくとも一方側に、複数のブランチテーブルと、前記複数のブランチテーブルに含まれるすべてのデータを個々に特定可能であり、前記複数のブランチテーブルに含まれるデータと一対一に関連付けられ、且つ前記マップテーブルに一対多の関係で関連付けられてリレーション構造をつくるルートテーブルとを設けることを特徴とするデータベース構築方法。
【請求項１１】
ルートテーブルと、前記ルートテーブルに含まれる各データと一対一で関連付けられたデータを含む複数のブランチテーブルとを有するデータベース装置におけるデータ検索方法であって、
検索条件を取得するステップと、
取得した前記検索条件に基づいて、前記ルートテーブル及び前記ブランチテーブルのいずれを参照するかを決定するステップと、
決定されたテーブルを参照して前記検索条件に該当するデータを検索するステップと、
前記検索において参照されなかったテーブルから、前記検索により検索されたデータに対応するデータを抽出するステップと、
抽出されたデータを参照して前記検索条件に該当するデータを検索するステップと、
を有することを特徴とするデータ検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース装置及びデータベース装置を用いたデータ検索方法に関し、特に、マップテーブルを用いた多対多のリレーションを有するデータベースの技術に関する。
【背景技術】
【０００２】
データベースの技術は、多数のデータを管理するために用いられる。通常、各データは複数の属性項目を持っている。データベースの技術を用いると、特定の属性について条件を指定して多数のデータの中から所望のデータを検索することができる。そして、周知のように、複数のテーブルとそれらの関係によって一つのデータベースを構成するリレーショナルデータベースが普及している。
【０００３】
ここで、データベースに含まれる多数のデータがいくつかの種類に分類される場合について考える。図１は、このような場合の従来におけるリレーショナルデータベースを示す図である。図１の例では、アイテムがメモリ製品であり、４つの種類に分類される。メモリ製品にはそれを扱う企業が関係づけられている。
【０００４】
メモリ製品のデータはその種類に応じてＤＲＡＭテーブル７２、ＳＲＡＭテーブル７３、マスクＲＯＭテーブル７４、又はＥＰＲＯＭテーブル７５に含まれている。そして、製品別テーブル７２〜７５のそれぞれを企業テーブル７１と関連付けるために、４つのマップテーブル７６〜７９が設けられている。マップテーブル７６〜７９は、それぞれテーブル７２〜７５のデータと企業テーブル７１のデータとの関係を規定している。このような構成によって、企業テーブル７１と種類毎に設けられた複数の製品別テーブル７２〜７５とが、各製品別テーブルに対応して設けられた製品別マップテーブル７６〜７９により多対多で関連付けられている。
【０００５】
しかしながら、図１のリレーショナルデータベースでは、マップテーブルを製品の種類毎に設けているために、データの数が膨大でアイテムの種類が多い場合には、データベースを構成するのに手間がかかり、また、メンテナンス（データの追加・削除・変更、テーブルの再編成など）も煩雑になる。さらに、検索に要する演算量も多くなる。特に、数十万件のアイテムが数十種類に分類される場合などには、上述の負担は過大になり、実用的ではなくなる。
【０００６】
そこで、そのような場合には、一般的には、図２に示すデータベースが採用される。このデータベースでは、企業とすべての種類の製品との対応関係を一つのマップテーブル８３に規定し、価格や各種仕様などの属性を有する製品テーブルを一つにまとめている（製品テーブル８２）。したがって、図１のように製品の種類毎に複数のマップテーブルを設ける必要がなく、データの数が膨大になったとしても、データベースの構築やメンテナンスの負担が軽減される。
【０００７】
しかしながら、各種類の製品は種類毎にそれぞれ異なる属性を持っている。このため、このようなデータベースでは、ある種類に特有の属性についてはその種類の製品のデータしか与えられない。したがって、製品テーブル８２内に無駄な領域が生じる。すなわち、図２の製品テーブル８２において「＊＊＊」で示される部分は実質的なデータが与えられない無駄な領域となってしまう。
【０００８】
そして、図２の製品テーブル８２からデータを検索しようとする場合には、そのような無駄な領域も含むテーブル全体を参照しなければならない。このため、検索処理に要するデータの参照量が無駄に多くなり、検索に要する時間も長くなってしまう。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述のように、図１に示す従来のデータベースでは、アイテムの種類毎にマップテーブルを設けているために、データベースの作成やメンテナンスの負担が大きいという問題がある。これに対して、図２に示すデータベースを採用すれば、マップテーブルが一つにまとまるので、データベースの構築やメンテナンスにかかる負担は軽減されるものの、アイテムのテーブル内に無駄が生じ、テーブル参照量が増えてしまうという問題がある。
【００１０】
特に、データベースに含まれるアイテムの数、即ちデータ数が数十万件にのぼる場合など、膨大なデータを含むデータベースの場合には上記の問題はより顕著になる。
【００１１】
本発明は上記問題に鑑みてなされたものであり、その目的は、複数の種類に分類される多数のアイテムのデータベースについて、検索時間を短くし、作成及びメンテナンスを容易にすることが可能な技術を提供することである。
【課題を解決するための手段】
【００１２】
本発明では、アイテムの種類に対応した複数のブランチテーブルを設けるとともに、それらの複数のブランチテーブルをまとめるルートテーブルを設けることにより上記の課題を解決する。
【００１３】
本発明のある態様にかかるデータベース装置は、マップテーブルを用いて、そのマップテーブルの両側のデータを多対多で関連付けるリレーション構造をもつ。本発明のデータベース装置は、マップテーブルの少なくとも一方側に、それぞれが同種のアイテムのデータを含む複数のブランチテーブルと、それらの複数のブランチテーブルによって網羅されるアイテムを個々に特定可能なルートテーブルとを有する。そして、複数のブランチテーブルのデータはルートテーブルの対応するデータと一対一で関連付けられており、ルートテーブルのデータはマップテーブルによりそのマップテーブルの反対側のデータと関連付けられている。
【００１４】
本発明によれば、同種のアイテムのデータを含む複数のブランチテーブルを設けたので、複数種類のアイテムのデータを一つのテーブルに納める場合に見られるようなテーブル内の無駄な領域を削減できる。これにより、検索を高速化できる。また、ルートテーブルを設けたことにより、アイテムの種類毎の複数のテーブルを設けたにもかかわらず、それらの複数のテーブルに対応させて複数のマップテーブルを設ける必要がない。これにより、データベースの作成やメンテナンスにかかる負担を軽減することができる。
【００１５】
好ましくは、上記のデータベース装置において、ルートテーブルは複数のアイテムが共通して持つ共通属性のデータを含む。そして、データベース装置は、検索条件がルートテーブルの属性に対応する条件とブランチテーブルの属性に対応する条件とを含むときにルートテーブルの参照量とブランチテーブルの参照量とに基づいてルートテーブルとブランチテーブルのいずれのテーブルを参照するかを決定する参照テーブル決定手段を有する。検索条件に基づく検索は、前記参照テーブル決定手段による決定に基づいて行われる。
【００１６】
好ましくは、上記のデータベース装置は、ルートテーブル及びブランチテーブルが有する属性項目とそれらのテーブルに含まれるデータの数とが規定されたインデクステーブルをさらに有する。そして、参照テーブル決定手段は、そのインデクステーブルを参照して、検索条件に基づいて、ルートテーブル及びブランチテーブルのうち参照量が少ない方のテーブルを参照することを決定する。
【００１７】
好ましくは、上記のデータベース装置は、参照テーブル決定手段により決定されたテーブルを参照して検索条件に該当するデータを検索する一次検索手段と、その一次検索手段による検索において参照されなかったテーブルから一次検索手段による検索において検索されたデータに対応するデータを抽出する抽出手段と、その抽出手段により抽出されたデータを参照して検索条件に該当するデータを検索する二次検索手段とを有する。
【００１８】
好ましくは、上記のデータベース装置において、参照テーブル決定手段は、ルートテーブルの属性に対応する条件の個数とルートテーブルに含まれるデータの数とに基づくルートテーブルの参照量と、ブランチテーブルの属性に対応する条件の個数とそのブランチテーブルのデータの数とに基づくブランチテーブルの参照量とを比較することにより、参照量の少ないテーブルを参照することを決定する。例えば、ルートテーブルの属性に対応する条件の個数がｐ個であり、ルートテーブルに含まれるデータの数がｍであるときは、ルートテーブルの参照量はｐ×ｍで表せる。また、ブランチテーブルの属性に対応する条件の個数がｑ個であり、ブランチテーブルのデータの数がｎであるときは、ブランチテーブルの参照量はｑ×ｎで表せる。そして、ｐ×ｍとｑ×ｎとでいずれが小さいか比較され、少ない方のテーブルを参照することが決定される。
【００１９】
好ましくは、上記のデータベース装置において、アイテムは商品であり、ブランチテーブルは商品の種類毎に設けられている。このデータベース装置は、典型的には、商品供給者と商品需要者によって利用される。
【００２０】
本発明の他の態様にかかるデータベース装置は、マップテーブルを用いて、そのマップテーブルの両側のデータを多対多で関連付けるリレーション構造をもつデータベース装置である。このデータベース装置は、マップテーブルの少なくとも一方側に、ルートテーブルとそのルートテーブルに対応する複数のブランチテーブルとを有する。そして、その複数のブランチテーブルの各データがブランチテーブルのデータと一対一で関連付けられている。また、ルートテーブルのデータがマップテーブルの反対側のデータと多対多で関連付けられている。本発明によれば、複数のブランチテーブルとマップテーブルの間にルートテーブルを介在させた構成を採用したことにより、複数のブランチテーブルに対応させて複数のマップテーブルを設ける必要がなくなる。
【００２１】
本発明の他の態様にかかるデータベース装置は、複数種類の商品のデータを含むデータベース装置である。このデータベース装置は商品別ブランチテーブルとルートテーブルとを有する。ここで、商品別ブランチテーブルは、商品の種類ごとに設けられ、その種類に含まれる商品のデータを含む。またルートテーブルは、複数の商品別ブランチテーブルに含まれる商品のデータを含み、商品名や商品ＩＤなどの各商品を個々に特定可能な属性（特定用属性）の列を持つ。本発明によれば、上述のようなルートテーブルと商品別のブランチテーブルを有する構成により、商品別の複数のテーブルを好適に適用することができ、複数種類のアイテムのデータを一つのテーブルに納める場合に見られるようなテーブル内の無駄な領域を削減できる。
【００２２】
好ましくは、上記のデータベース装置において、ルートテーブルは、マップテーブルにより商品取扱者の名称やＩＤなどの取扱者の属性を含むテーブルと多対多のリレーション構造により関連付けられている。このデータベース装置では、所望の条件に該当する商品を検索した後にその商品の取扱者の情報を得ることができ、また、所望の取扱者を検索した後にその取扱者が取り扱う商品の情報を得ることができる。
【００２３】
本発明にかかるデータベース構築方法は、マップテーブルを用いた多対多のリレーション構造を持つデータベースを構築するデータベース構築方法である。このデータベース構築方法では、マップテーブルの少なくとも一方側に、複数のブランチテーブルを設ける。そして、複数のブランチテーブルに含まれるすべてのデータを個々に特定可能であり、複数のブランチテーブルに含まれるデータと一対一に関連付けられ、且つ前記マップテーブルに一対多の関係で関連付けられてリレーション構造をつくるルートテーブルを設ける。この方法によれば、複数のブランチテーブルのそれぞれに同種のアイテムのデータ含めた場合にテーブル内の無駄な領域を削減できるデータベースを構築することができる。また、この方法によれば、ルートテーブルのデータがマップテーブルのデータと関連付けられてリレーション構造をつくるので、複数のマップテーブルをアイテム種類毎の複数のテーブルに対応させて設けなくても、一つのマップテーブルでそのような複数のテーブルのリレーションを規定することができる。
【００２４】
本発明にかかるデータ検索方法は、ルートテーブルと前記ルートテーブルに含まれる各データと一対一で関連付けられたデータを含む複数のブランチテーブルとを有するデータベース装置におけるデータ検索方法である。この検索方法では、検索条件を取得し、その取得した検索条件に基づいてルートテーブル及び前記ブランチテーブルのいずれを参照するかを決定する。そして、決定されたテーブルを参照して検索条件に該当するデータを検索し、検索において参照されなかったテーブルから、検索により検索されたデータに対応するデータを抽出する。そして、抽出されたデータを参照して検索条件に該当するデータを検索する。この検索方法では、ルートテーブルとブランチテーブルの一方から他方に絞込検索が好適に行われ、検索の高速化が図られる。
【発明の効果】
【００２５】
以上に説明したように、本発明によれば、データベースの作成やメンテナンスにかかる手間が少なく、検索を短時間で行えるデータベースを提供できる。特に、データベースに含まれるデータが数十万に及ぶなど膨大であるほど本発明は顕著にその効果を発揮する。
【発明を実施するための最良の形態】
【００２６】
以下、本発明の好適な実施の形態（以下、実施形態という）を図面を参照して説明する。
図３は、データベースシステムの構成を示す図である。本実施の形態のデータベースシステム１は、インターネットを介してメモリ製品の電子商取引を実行するためのシステムである。データベースシステム１は、データベースサーバとしてのデータベース装置（以下、「ＤＢ装置」と記す。）１００と複数のクライアント端末３００とがインターネット４００を介して通信するネットワークシステムである。このデータベースシステム１において、ＤＢ装置１００は、ＣＧＩ（Common Gateway Interface）を備えたＷＷＷサーバ２００を介してインターネットに接続される。ＷＷＷサーバ２００は、クライアント端末３００からの指示に基づいてＤＢ装置１００に対してＣＧＩを実行し、得られた結果をＨＴＭＬでクライアント端末３００に返す。
【００２７】
ＤＢ装置１００は、コンピュータの一般的な構成としてＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３などの回路と各種プログラムを記憶したハードディスク１４とを備える。また、ＤＢ装置１００は、キーボードやマウスなどの入力機器１５及びモニタなどの出力機器１６を備える。更に、ＤＢ装置１００は、各種のデータを格納するデータベース１８を備えている。データベース１８は、大規模なハードディスク装置を有し、インデクステーブルを記憶するインデクス記憶部１８１と、メモリ製品に関するデータを記憶するメインデータ記憶部１８２とを含む。
【００２８】
図４は、メインデータ記憶部１８２におけるデータベースの構成を示す図である。図４に示すデータベースは、マップテーブル２０を用いて、このマップテーブル２０の一方側のアイテムに関するデータと他方側のアイテムに関するデータとを多対多で関連付けるリレーション構造を実現している。本実施の形態では、一方側のアイテムは商品であり、具体的にはメモリ製品である。また、他方側のアイテムはその商品を取り扱う企業である。
【００２９】
ここで、このデータベースで扱うメモリ製品には、ＤＲＡＭ、ＳＲＡＭ、マスクＲＯＭ、ＥＰＲＯＭの各種類のメモリ製品が含まれる。そして、メモリ製品に関するデータはそれぞれの種類に応じて異なる属性を持っている。例えば、ＤＲＡＭ製品のデータは、「機能」「価格」「納期」「ＲＡＳアクセスタイム」「クロック周波数」「リフレッシュ周波数」「リファレンス電圧」などの属性を持っているのに対して、ＳＲＡＭ製品のデータは、「機能」「価格」「納期」「ファンクションタイプ」「メモリ容量」「スタンバイ電流」などの属性を持っている。マスクＲＯＭ製品のデータやＥＰＲＯＭ製品のデータも同様に他の製品のデータとは異なる属性を持っている。
【００３０】
本実施の形態では、このように互いに種類の異なるアイテムのデータを、その種類に対応して設けられた複数のブランチテーブルと、それらのブランチテーブルをまとめるルートテーブルとに分けて規定している。図４に示すデータベースでは、同種のメモリ製品のデータを含むブランチテーブル２２〜２５と、全種類のメモリ製品のデータを含むルートテーブル２１とが設けられている。そして、メモリ製品のデータはマップテーブル２０によって企業テーブル２６のデータと多対多で関連付けられている。以下、各テーブルについて、テーブル間に設けられたリレーションも含めて説明する。
【００３１】
「製品別ブランチテーブル」
各ブランチテーブル２２〜２５は、それぞれの種類のメモリ製品が有する属性であって、全種類に共通する属性以外の属性の列を含んでいる。つまり、ブランチテーブルには、ＤＲＡＭブランチテーブル２２の「ＲＡＳアクセスタイム」やＳＲＡＭブランチテーブル２３の「ファンクションタイプ」など、他のいずれのメモリ製品にもないその種類に固有の属性や、ＳＲＡＭブランチテーブル２３、マスクＲＯＭブランチテーブル２４及びＥＰＲＯＭブランチテーブル２５の「メモリ容量」のように、全種類のメモリ製品のうちの一部の種類にのみ共通する（すべての種類のメモリ製品に共通するわけではない）属性についての列が含まれている。
【００３２】
「ルートテーブル」
ルートテーブル２１は、製品別ブランチテーブル２２〜２５によって網羅されるメモリ製品に関するデータを含んでいる。したがって、ルートテーブル２１はすべての種類に共通する属性の列を持つ。具体的に、「商品コード」「機能」「価格」「納期」はすべての種類の製品が共通して持つ属性である。ここで、「商品コード」の列の各データは各メモリ製品に固有に与えられたものであり、「商品コード」の列は各メモリ製品を個々に特定可能な特定用属性である。したがって、ルートテーブル２１では、商品コードを指定することによりメモリ製品を唯一に特定することができる。
【００３３】
なお、「機能」「価格」「納期」の列はブランチテーブルに含まれていてもよい。要するに、ルートテーブル２１には、少なくともメモリ製品を個々に特定可能な特定用属性の列を含んでいればよい。この場合には、各ブランチテーブル２２〜２５は、従来のデータベース構成として説明した図１の各製品別テーブル７２〜７５と同様の構成になる。ただし、本実施の形態のように、ルートテーブル２１に「機能」「価格」「納期」などの列が含まれている場合には、後述する絞込検索を有効に行うことができる点で有利である。
【００３４】
ルートテーブル２１に含まれるメモリ製品の各々は、ブランチテーブル２２〜２５の対応するメモリ製品と一対一に関連付けられている。このために、図４のデータベースでは、ルートテーブル２１とブランチテーブル２２〜２５とを一対一で結ぶリレーションが形成されている。このリレーションにより、ルートテーブル２１のすべての行（データ）はブランチテーブル２２〜２５のいずれかの行（データ）と結び付けられ、ブランチテーブル２２〜２５のすべての行（データ）もルートテーブル２１のいずれかの行（データ）と結び付けられている。
【００３５】
このように、本実施の形態では、各メモリ製品に関するデータがブランチテーブル２２〜２５のいずれかとルートテーブル２１とに分かれて記憶されている。したがって、全ブランチテーブル２２〜２５に含まれるデータの総数（行数の合計）はルートテーブル２１のデータ数（行数）と一致し、ルートテーブル２１はブランチテーブル２２〜２５に含まれるデータを網羅する。
【００３６】
なお、このデータベースは数万件から数十万件のアイテムのデータを扱うデータベースである。したがって、図４では説明の便宜のために図示を省略しているが、ルートテーブル２１の行数は数万行から数十万行にも及び、マップテーブル２０の行数はその数倍にも及ぶ。
【００３７】
「企業テーブル」
企業テーブル２６は、メモリ製品を取り扱う企業についてのデータを有する。具体的に、企業テーブル２６は「企業コード」「企業名」「連絡先」「ＵＲＬ」の列を含む。「企業コード」は、各企業に対して唯一に与えられたコードであり、企業テーブル２６に含まれる企業を個々に特定可能な属性である。
【００３８】
「マップテーブル」
マップテーブル２０は、企業を個々に特定可能な「企業コード」とメモリ製品を個々に特定可能な「商品コード」との関係を規定することにより、企業テーブル２６のデータとルートテーブル２１のデータとを多対多で関連付けるリレーション構造を実現している。
【００３９】
このマップテーブル２０自体は、従来のデータベース構成として説明した図２のマップテーブルと同様の構成であり、複数種類のアイテムについての関連付けを全種類まとめて規定している。図４の例では、マップテーブル２０は、企業コードＣ１の企業は商品コードＤ１、Ｄ３、Ｓ２、Ｓ４、Ｍ１、Ｅ２などのメモリ製品を取り扱っていること、また、商品コードＤ１の製品は企業コードＣ１、Ｃ２の企業に取り扱われていることなどを規定している。
【００４０】
図５は、インデクス記憶部１８１に記憶されたインデクステーブルが有する情報を示している。インデクステーブルには、ルートテーブル２１及び各ブランチテーブル２２〜２５について、それらの行（データ）数及び属性項目（属性項目１、属性項目２、属性項目３、・・・）の情報が含まれる。上述したように、ルートテーブルの行数は全ブランチテーブルの行数の総数と一致している。
【００４１】
図６は、データベース１８から所望のデータを検索するのためのＤＢ装置１００の構成を示す機能ブロック図である。ＤＢ装置１００は、ＷＷＷサーバ２００から検索条件を取得する検索条件取得部３０を有する。ここで、ＤＢ装置１００が取得する検索条件には、種類の条件と属性の条件とが含まれる。種類の条件とは、アイテムの種類を指定する条件であり、図４の例では、「ＤＲＡＭ」、「ＳＲＡＭ」などである。また、属性の条件とは具体的数値や範囲等を指定する条件であり、図４のブランチテーブル２２〜２５やルートテーブル２１に示される各属性に対応する。そして、この属性の条件は、更に、ブランチテーブルに含まれる属性（以下、「固有属性」という。）の条件と、ルートテーブルに含まれる属性（以下、「共通属性」という。）の条件とに分けられる。
【００４２】
テーブル特定部３１は、検索条件取得部３０で取得された種類の条件に対応するブランチテーブルを特定する。
【００４３】
参照テーブル決定部３２は、属性の条件に、固有属性の条件と共通属性の条件とが含まれる場合に、参照量の比較を行う。参照量の比較では、ブランチテーブルの固有属性データの参照量とルートテーブルの共通属性データの参照量とが比較される。そして、参照テーブル決定部３２では参照量の比較により、ルートテーブルとブランチテーブルのいずれを参照するかを決定する。この参照テーブル決定部３２によって、検索に要する参照量を少なくすることができる。
【００４４】
ここで、参照テーブル決定部３２は、検索条件取得部３０で取得された属性の条件と、テーブル特定部３１でのブランチテーブルの特定とに基づいて、インデクス記憶部１８１に記憶されたインデクステーブルを利用して、上記の比較を行う。
【００４５】
図７は、参照量比較処理を説明するための図である。いま、ＤＢ装置１００がＤＲＡＭ製品について「価格」「クロック周波数」及び「リフレッシュ周波数」の検索条件を取得したとする。ここで、「価格」の検索条件は共通属性の条件であり、「クロック周波数」及び「リフレッシュ周波数」の検索条件は固有属性の条件である。そして、ルートテーブル２１には、８万件のデータが格納されており、ＤＲＡＭブランチテーブル２２には３万件のデータが格納されているとする。
【００４６】
この場合に、参照テーブル決定部３２は、インデクステーブル記憶部１８１に記憶されたインデクステーブルを用いて、それらの両テーブルの行数及び参照すべき属性の数から、各テーブルの参照量を求める。図７の例では、共通属性即ちルートテーブル２１に含まれる属性は「価格」の１項目だけであるので、ルートテーブル２１のデータ参照量は８万行×１列で８万となる。一方、固有属性即ちＤＲＡＭブランチテーブル２２に含まれる属性は「クロック周波数」及び「リフレッシュ周波数」の２項目であるので、ＤＲＡＭブランチテーブル２２のデータ参照量は３万行×２列で６万となる。したがって、これらを比較すると、参照量はＤＲＡＭブランチテーブル２２の方がルートテーブル２１よりも少ないと判断される。そこで、参照テーブル決定部３２は、ブランチテーブル２２を参照することを決定する。
【００４７】
上述の参照量の比較についてさらに説明すると、ルートテーブル２１と一つのブランチテーブルとでは、ルートテーブルの方が行数が多い。したがって、一見すると、ルートテーブルと特定されたブランチテーブルとでは、ルートテーブルの方が参照量が多いように見える。しかし、検索条件がルートテーブル及びブランチテーブルのいくつの属性に該当するかによって参照量が逆転しうる。具体的には、ブランチテーブルで参照すべき列の数が、ルートテーブルで参照すべき列の数に対して一定倍以上になると、参照量は逆にブランチテーブルの方が多くなる。このような場合にも、本実施の形態によれば、参照量の比較処理を設けたことで、次の検索処理で参照量の少ないテーブルを参照の対象にすることができる。
【００４８】
図６に戻って、一次検索部３３、データ抽出部３４、一時記憶部３５、及び二次検索部３６は、以下のように、検索条件に対応するデータをルートテーブル及びブランチテーブルから検索する検索部３７を構成する。この検索部３７では、参照テーブル決定手段３２の決定に基づいて検索が行われる。
【００４９】
まず、一次検索部３３は、参照テーブル決定部３２の比較にて参照量が少なかった方のテーブルのデータを参照して、検索条件に該当するデータを検索する。
【００５０】
データ抽出部３４は、一次検索部３３で検索されたデータと関連付けられた他方のテーブルのデータを、抽出する。この抽出には、図４を用いて説明したルートテーブル２１とブランチテーブル２２〜２５との間の一対一のリレーションが用いられる。そして、データ抽出部３４は、抽出されたデータを一時記憶部３５に一時的に記憶する。
【００５１】
二次検索部３６は、一時記憶部３５に記憶された抽出データを参照して、検索条件に該当するデータを検索する。
【００５２】
このように、本実施の形態のデータベース装置では、参照テーブル決定部３２で参照量が少ないと判断されたテーブルを参照して一次検索部３３でデータを検索し、データ抽出部３４でデータを抽出して一時記憶部３５に記憶させ、そして、二次検索部３６で一時記憶部３５に記憶されたデータを参照してデータを検索する。この一連の処理によって絞込検索が行われる。この絞込検索では、参照テーブル決定部３２がルートテーブルとブランチテーブルのいずれのテーブルを参照して一次検索を行うかを決定することにより絞込方向が決定されている。
【００５３】
上記の図７の例では、参照テーブル決定部３２は、参照量の比較結果に基づいて、一次検索３６でＤＲＡＭブランチテーブル２２（の「クロック周波数」の列及び「リフレッシュ周波数」の列）を参照することを決定している。したがって、図７の例では、一次検索部３３、データ抽出部３４、一時記憶部３５及び二次検索部３６からなる検索部３７は、絞込検索のために以下のように機能する。
【００５４】
まず、一次検索部３３は、ＤＲＡＭブランチテーブル２２を参照してデータを検索する。ここでは、参照対象がブランチテーブルなので、検索条件のうちの固有属性の条件に該当するデータが検索される。データ抽出部３４は、ルートテーブル２１とＤＲＡＭブランチテーブル２２との間に設けられた一対一のリレーションを用いて、検索されたＤＲＡＭブランチテーブル２２のデータに対応するルートテーブル２１のデータを抽出する。例えば３つのＤＲＡＭ製品がブランチテーブル２２から検索されると、それらのＤＲＡＭ製品のデータがルートテーブル２１から抽出される。一時記憶部３５には、抽出されたルートテーブル２１のデータが記憶される。二次検索部３６は、一時記憶部３５に記憶された抽出データを参照して、データを検索する。ここでは、参照対象がルートテーブル２１なので、検索条件のうちの共通属性の条件に該当するデータが検索される。
【００５５】
なお、上述した一時記憶部３５は、ＤＢ装置１００のＲＡＭ１３により実現される。また、各処理部３０〜３４、３６は、ＤＢ装置１００のＣＰＵ１１が、ハードディスク１４に記憶された所望のプログラム及び／又はＷＷＷサーバ２００のＣＧＩに従い、ＲＡＭ１３を用いることにより実現される。
【００５６】
図８は、上記のＤＢ装置１００を用いてメインデータ記憶部１８２に記憶されたデータを検索する処理のフローチャートである。
【００５７】
データ検索処理においては、まず検索条件取得部３０が検索条件を取得する（ステップＳ１１）。ここで、クライアント端末３００にて検索条件を入力する際には、クライアント端末３００では図９に示す検索画面が表示される。この検索画面は、検索条件を入力するためのフレーム４０と、そのフレーム４０にいずれの種類の製品の検索画面を表示させるかを指定するためのフレーム４１とを含む。
【００５８】
図９を参照すると、ユーザは、まずフレーム４１で所望のメモリ製品を選択し、そのメモリ製品の検索条件を入力するための検索画面をフレーム４０に表示させる。図９の例では、ＤＲＡＭ製品が検索対象として選択されている。フレーム４０中の検索対象表示４２には「ＤＲＡＭ」と表示され、検索画面がＤＲＡＭ製品を検索するための画面であることを表している。
【００５９】
上述のように、ＤＲＡＭ製品の属性には、「商品コード」「機能」などの全種類のメモリ製品について共通の属性と、「ＲＡＳアクセスタイム」「クロック周波数」などのＤＲＡＭ製品に固有の属性とがある。検索画面はこの共通属性を入力する領域４３と固有属性を入力する領域４４とを含む。この検索画面では、ルートテーブルに含まれる属性の条件とブランチテーブルに含まれる属性の条件とを、両者の違いを特に意識することなく同一画面上で入力することができる。
【００６０】
ユーザは、検索画面の所望の欄に所望の検索条件を入力し、それから検索実行ボタン４５を指定する。これにより、クライアント端末３００からＷＷＷサーバ２００に対して検索条件が送信される。この検索条件は、ＷＷＷサーバ２００からＤＢ装置１００に送信される。
【００６１】
次に、テーブル特定部３１が、検索条件のうちの種類の条件（図９では「ＤＲＡＭ」）に従っていずれかのブランチテーブルを特定する（ステップＳ１２）。次に、検索条件のうちの属性の条件中に固有属性の条件と共通属性の条件の両方が含まれるか否かを判断する（ステップＳ１３）。そして、両方が含まれる場合（ステップＳ１３でＹＥＳ）には、参照テーブル決定部３２が、ルートテーブルと特定されたブランチテーブルのいずれの参照量が少ないかを比較する（ステップＳ１４）。この比較により次の一次検索で参照されるべきテーブルが決定される。
【００６２】
なお、上記の例では、ＷＷＷサーバ２００がクライアント端末３００から全検索条件（種類の条件と属性の条件を含む）を取得してこれを転送することにより、ＤＢ装置１００が検索条件を取得したが、本発明は、これに限定されるものではない。例えば、検索条件の一部がＷＷＷサーバ２００で生成されてもよい。一例としては、図６の検索画面をクライアント端末３００に表示させる時点で、ＷＷＷサーバ２００は、製品種類がＤＲＡＭであることを把握しているので、このことに基づき検索条件を生成していもよい。また、例えば、検索条件の一部又は全部がクライアント端末３００からのデータに基づき、ＤＢ装置１００自身の内部で生成され、ＤＢ装置１００の関連機能に取得させてもよい。さらには、すべての検索条件が一度の取得されなくてもよい。即ち複数回に分けて検索条件が取得されてもよい。
【００６３】
次に、ステップＳ１４において参照量が少ないと判断された方のテーブルを参照して、そのテーブルに対応する検索条件に基づいて、一次検索を行う（ステップＳ１５）。次に、ステップＳ１５において検索されたデータに対応する他方のテーブルのデータが抽出されて一時記憶部３５に記憶される（ステップＳ１６）。そして、二次検索部３６が一時記憶部３５に記憶されたデータを参照して、二次検索を行う（ステップＳ１７）。一次検索及び二次検索を通じた絞込みにより、検索条件に該当するメモリ製品が特定される。この特定されたメモリ製品の商品情報が、最終的な検索結果としてＷＷＷサーバ２００に出力される（ステップＳ１８）。この商品情報は、ＷＷＷサーバ２００を介してクライアント端末３００に提示される。
【００６４】
一方、ステップＳ１１で取得した検索条件に固有属性と共通属性のいずれか一方が含まれない場合（ステップＳ１３でＮＯ）には、固有属性のみが含まれているか否かを判断する（ステップＳ１９）。検索条件が固有属性のみである場合（ステップＳ１９でＹＥＳ）、ステップＳ１２で特定されたブランチテーブル参照して検索を行う。一方、検索条件に固有属性が含まれていない、すなわち、共通属性のみが含まれる場合（ステップＳ１９でＮＯ）には、ルートテーブルを参照して検索をする。いずれのテーブルを参照して検索を行った場合も、その検索により特定されたメモリ製品の商品情報が検索結果として出力される（ステップＳ１８）。
【００６５】
なお、WWWサーバ２００は、取得された検索結果に基づいて、クライアント端末３００にその検索結果の情報を含む表示制御データを送る。この表示制御データを受けたクライアント端末３００の表示画面には検索結果が表示される。
【００６６】
以上、本発明の好適な実施の形態を説明したが、上記の実施形態は、本発明の範囲内で変更可能なことはもちろんである。例えば、アイテムは、メモリ製品に限定されない。データベースは、メモリ製品以外の商品のデータベースでもよく、メモリ製品を含む複数種類の商品のデータベースでもよく、さらには、商品以外の何らかの事象（物に限られない）でもよい。なお、上述の実施形態にてメモリ製品がＤＲＡＭ、ＳＲＡＭ等に分けられたように、アイテムが、その属性により複数のグループに分けられる場合には、本発明が特に有効である。
【００６７】
より詳細には、上記の実施形態では、ＤＲＡＭやＳＲＡＭなどの各種のメモリ製品を含む商品がルートテーブル２１にまとめられていたが、例えば、データベースに含まれるアイテムとして、さらにトランジスタ製品やコンデンサ製品などを含む電子パーツ製品など他の商品が含まれていてもよい。この場合には、ＤＲＡＭやＳＲＡＭなどと同様にトランジスタやコンデンサについてもブランチテーブルを設ける。そして、ルートテーブル２１には各種の電子パーツ製品についても「商品コード」「機能」「価格」「納期」のデータを与え、上記と同様にルートテーブル２１と各ブランチテーブルの間に一対一のリレーションを設ける。
【００６８】
また、上記説明から明らかなように、ブランチテーブルの数は、図４で示したように４つには限定されず、５つ以上でもよい。また、ブランチテーブルの数は４つ未満であってもよいし、１つであってもよい。
【００６９】
また、上記の実施形態では、ブランチテーブル２２〜２５のすべてのデータがルートテーブル２１のデータと関連付けられていたが、このブランチテーブル２２〜２５がルートテーブル２１のデータと関連付けられていないデータを一部に含むこともあり得る。さらに、ルートテーブル２１についても同様であり、ルートテーブル２１のデータの一部がブランチテーブルと関連付けられていないこともあり得る。このようなことは、典型的には、一部のアイテムのデータを完全に入手できないときに生じる。このような構成であっても本発明の効果を奏する。
【００７０】
また、図４の例では、マップテーブルの片側にのみ、ブランチテーブルとルートテーブルで構成されるデータベース構造が設けられた。この構造は、マップテーブルの両側に設けられてもよい。すなわち、図４の例では、メモリ製品を取り扱う企業のデータが、ルートテーブルとブランチテーブルとに分けられる。
【００７１】
さらに、上記の実施形態では、マップテーブルの一方側に、ルートテーブルと複数のブランチテーブルとの２段階の構成を設ける例を示したが、３段階以上の段階をもつ構成が採用されてもよい。
【００７２】
図１０は、マップテーブルの一方側が３段階の構成を有するデータベースの例を示す図である。このデータベースに含まれるアイテムは、その属性により、大きく分けて２つのグループに分類される（これをＡグループ及びＢグループとする）。Ａグループは更に３つのサブグループに分けられ、Ｂグループは更に４つのサブグループに分けられる。
【００７３】
この場合に、図１０のデータベースでは、全アイテムのデータを有する第１ルートテーブル５１を設け、更にその第１ルートテーブル５１から枝別れする２つの第２ルートテーブル５２、５３を設ける。そして、それぞれの第２ルートテーブル５２、５３に対応して複数のブランチテーブル５４〜６０を設ける。第２ルートテーブル５２、５３は、それぞれ、上述の大分類によるＡ、Ｂグループに対応する。ブランチテーブル５４〜６０は、上述のサブグループと対応しており、第２ルートテーブル５２（Ａグループ）には、３つのブランチテーブル５４〜５６が対応し、第２ルートテーブル５３（Ｂグループ）には、４つのブランチテーブル５７〜６０が対応する。マップテーブル６１は、第１ルートテーブル５１のデータを用いて他方側のテーブル６２との関係を規定する。各ブランチテーブルは、第２ルートテーブルと一対一のリレーションにより関連付けられる。第２ルートテーブルでは、更に、第１ルートテーブルと一対一のリレーションにより関連付けられる。
【００７４】
この図１０の例においても、データベース検索装置は、検索条件に基づき、第１ルートテーブル、第２ルートテーブル又はブランチテーブルのいずれを最初に参照するかを参照量を基に決定する。参照量が最も少ないテーブルが最初に参照される。そして、３つのテーブルを使って、絞込検索が行われる。
【００７５】
また、上記の実施形態では、インターネットを使った電子商取引システムに使われるデータベースに本発明が適用される例を示した。しかし、本発明は、他の任意の技術に適用可能である。例えば社内ＬＡＮを使ったシステムに本発明が適用されてもよい。また、例えば一つのパーソナルコンピュータで構成されるデータベースに本発明が適用されてもよい。
【００７６】
以上、本発明の好適な実施形態を説明した。本実施形態によれば、データベース装置にルートテーブルとブランチテーブルとが設けられる。本実施形態では、アイテムの種類毎に複数のブランチテーブルを設けたので、アイテムのデータを一つのテーブルに納めた図２のようなデータベースと比較して、テーブル内の無駄な領域を削減できる。これにより、検索が高速化される。
【００７７】
そして、本実施の形態では、ルートテーブルを複数のブランチテーブルとマップテーブルの間に設けることにより、それら複数のブランチテーブルと一つのマップテーブルとが共存できる。したがって、アイテムの種類毎に複数のブランチテーブルを設けたにも関わらず、図１に示したような複数のマップテーブルをアイテムの種類に応じて設ける必要がないので、データベースの作成やメンテナンスにかかる手間を軽減することができる。
【００７８】
このようにして、本実施形態によれば、テーブル内の無駄な領域の削減による検索の高速化の要請と、データベースの作成やメンテナンスにかかる負担軽減の要請とに同時に応えることができる。
【００７９】
また、本実施の形態では、ルートテーブルとブランチテーブルの参照量に基づいた検索を行うので、以下に説明するように、検索時間を短くし、検索を高速化できる。
【００８０】
本実施の形態では、上述したように、ルートテーブルとブランチテーブルのうちの一方をまず検索し、検索結果を使ってもう一方のテーブルを検索するというように、絞込検索が行われる。このとき、前半のテーブルの検索では、テーブルの全行のデータが一通り参照される。この一通りの参照に要する処理量が検索処理量全体の比較的大きなウェイトを占めるので、この部分の参照量を少なくすることが、検索高速化の観点から望ましい。
【００８１】
上述した前半のテーブル検索の参照量は、ルートテーブルを先に検索する場合と、ブランチテーブルを先に検索する場合とでは異なる。そして、どちらの場合の参照量が少ないかは、検索条件によって異なる。より詳細に説明すると、どちらの場合の参照量が少なくなるかは、ルートテーブルとブランチテーブルのそれぞれの行数、及び検索条件に含まれる属性の個数による。ブランチテーブルの行数はルートテーブルの行数より少ないので、検索されるべき列の数が同じなら、当然、ブランチテーブルの参照量が少ない。しかし、検索条件によっては、ブランチテーブルの検索されるべき列の数が多くなり、参照量が逆転することもあり得る。
【００８２】
本実施の形態は、このような点を考慮し、検索条件に基づいて、ルートテーブルとブランチテーブルのうちの参照量が少ないテーブルを判断した上で検索を行うので、さらに検索を高速化できる。
【００８３】
なお、データベースが比較的小型の場合は、上述のような参照量の大小による検索速度の差は、ユーザにとってそれほど強く感じられないこともある。一方、データベースが大型な場合、特に、インターネット等の通信を使って大型データベースにアクセスするような場合には、上述の発明による検索時間の差がより顕著になる。
【図面の簡単な説明】
【００８４】
【図１】従来のリレーショナルデータベースの構成を示す図である。
【図２】従来のリレーショナルデータベースの構成を示す図である。
【図３】本実施形態のデータベースシステムの構成を示す図である。
【図４】図３のデータベースの構成を示す図である。
【図５】インデクステーブルに含まれる情報を示す図である。
【図６】図３のデータベース装置のブロック図である。
【図７】参照量比較処理を説明するための図である。
【図８】図６のデータベース装置による検索処理のフローチャートである。
【図９】クライアント端末に表示される、検索条件入力用の画面を示す図である。
【図１０】データベースの構成の他の例を示す図である。
【符号の説明】
【００８５】
１８  データベース
２０  マップテーブル
２１  ルートテーブル
２２〜２５  ブランチテーブル
３０  検索条件取得部
３１  テーブル特定部
３２  参照テーブル決定部
３３  一次検索部
３４  データ抽出部
３６  二次検索部
１００  データベース装置
【図１】
2006309798.tif 000003
【図２】
2006309798.tif 000004
【図３】
2006309798.tif 000005
【図４】
2006309798.tif 000006
【図５】
2006309798.tif 000007
【図６】
2006309798.tif 000008
【図７】
2006309798.tif 000009
【図８】
2006309798.tif 000010
【図９】
2006309798.tif 000011
【図１０】
2006309798.tif 000012