JP2006120056A - データベースシステムおよびその方法 - Google Patents

Abstract

【課題】 ＤＢシステムにおいて、各ＤＢ装置の負荷分散を行い、性能を保証する。
【解決手段】 ＤＢ装置６は、各エントリに対するアクセスの頻度およびアクセスに用いられた検索条件を、ＤＢ管理装置５に通知する。ＤＢ管理装置５は、各エントリに対するアクセスの頻度および検索条件を集計し、あるＤＢ装置６のサブツリーに対するアクセスが大きい場合などに、ＤＢ装置６を制御して、サブツリーの新設を行い、この新設に合わせて、ディレクトリツリーを示す情報を変更する。ＤＢ管理装置５は、内容が変更された検索条件の変換に用いられる情報を、検索装置４０に対して提供し、検索装置４０は、検索者の検索操作に従って、ＤＢ管理装置５から提供された情報を用いた変換を行い、ＤＢ装置６に対する検索を行う。
【選択図】図２４

Description

本発明は、データを記憶する方法及び記憶するデータ構造に関する。
より詳細には、相互に関連性を持った一連のデータを記憶する方法及び記憶するデータ構造に関する。

関連するデータを記憶し、記憶されたこのようなデータを検索するために、リレーショナル・データベースと呼ばれる装置が用いられている。
また、例えば、非特許文献１および特許文献１，２は、関連するデータを記憶する方法、および、記憶されたこのようなデータを検索する方法を開示する。
しかしながら、リレーショナル・データベースにおいて、完成されたデータベースの構造（スキーマ）を変更することは、容易ではない。
また、これらの文献に開示されている方法では、データの記述内容が複雑になり、また、データの表記・格納方法が一意的ではない。
また、これらの文献に開示されている方法では、データベースが複数のサーバを用いて実現されているときに、これら複数のサーバ間における負荷分散が容易ではない。
The Associative Model of Data White Paper (Lazy Software, September 2000) 特開２００１−２０９６４７号公報 国際公開公報ＷＯ ００／２９９８０

本発明は、上述のような背景からなされたものであり、データベースの構造を変更することなく、様々な種類の情報の追加が容易なデータベースシステムおよびその方法を提供することを目的とする。
また、本発明は、情報の記述が簡単で、情報の表記および格納方法が一意的なデータベースシステムおよびその方法を提供することを目的とする。
また、本発明は、データベースが複数の装置に分散されているときに、これら複数の装置間における負荷分散が容易なデータベースシステムおよびその方法を提供することを目的とする。
また、本発明は、このように登録された情報を検索するために適したデータベースシステムおよびその方法を提供することを目的とする。

上記目的を達成するために、本発明にかかるデータベースシステムは、１つ以上の関連ノードと、１つ以上の見出ノードとを関連付けてディレクトリツリーの形式のデータベースとするデータベースシステムであって、前記関連ノードそれぞれは、１つ以上の前記見出ノードと関連付けられ、前記見出ノードそれぞれには１つ以上の情報が属し、前記関連付けられた前記関連ノードと前記見出ノードとの間それぞれに対しては、これらの間の関連を示す関連属性が定義され、前記関連ノードそれぞれの関連ノードエントリと、前記関連属性それぞれの関連属性エントリとを作成し、これらのエントリを、前記関連ノードと前記関連属性との関連に従って対応付けて、ディレクトリツリーを作成するディレクトリツリー作成手段と、前記見出ノードそれぞれに対応する情報を、前記作成された関連属性エントリに、前記見出ノードと前記関連属性との関連に従って対応付ける情報対応付手段とを有する。

好適には、前記関連属性は、前記関連ノードと前記見出ノードとの間に定義される役割を示す。

好適には、前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、前記ディレクトリツリーおよびサブツリーにおいて、前記関連ノードおよび前記見出ノードは、階層的に対応付けられる。

好適には、前記サブツリーそれぞれの最上位のエントリそれぞれと、これら最上位のエントリが参照する前記ディレクトリツリーまたは他の前記サブツリーに含まれるエントリとを対応付ける最上位エントリ対応付手段をさらに有する。

好適には、前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とをそれぞれ記憶する１つ以上の第１のデータベース装置を有する。

好適には、ある第１のデータベース装置に記憶された情報を、他の第１のデータベース装置に転送して記憶させる情報転送手段をさらに有する。

好適には、前記情報転送手段は、前記第１のデータベース装置の動作状態に基づいて、ある第１のデータベース装置から、他の第１のデータベース装置に転送する情報を決める。

好適には、前記情報転送手段は、前記ディレクトリツリーまたは前記サブツリーに対するアクセス状態に基づいて、ある第１のデータベース装置から、他の第１のデータベース装置に転送する情報を決める。

好適には、前記第１のデータベース装置の１つ以上に記憶された情報の複製を記憶する第２のデータベース装置をさらに有し、前記最上位エントリ対応付手段は、前記第１のデータベース装置の最上位エントリと、前記第１のデータベース装置に記憶された情報の複製を記憶する前記第２のデータベース装置とをさらに対応付ける。

好適には、前記ディレクトリツリーおよび前記サブツリーそれぞれには、さらに１つ以上の前記サブツリーが含まれることがあり、前記ディレクトリツリーおよび前記サブツリーそれぞれから、さらに前記サブツリーを作成するサブツリー作成手段をさらに有する。

好適には、前記ディレクトリツリーおよび前記サブツリーそれぞれには、前記関連ノードおよび見出しノードの分類に用いられる分類情報が定義され、前記前記ディレクトリツリーおよび前記サブツリーそれぞれと、これらのディレクトリツリーそれぞれに定義された分類情報とを対応付ける分類情報対応付手段をさらに有する。

好適には、前記記憶された見出ノードに対応する情報を検索する検索装置をさらに有する。

好適には、前記検索装置は、検索条件を受け入れる検索条件受入手段と、前記受け入れられた検索条件に対応する前記分類情報と対応付けられた前記ディレクトリツリーまたは前記サブツリーを検索するディレクトリツリー検索手段と、前記検索の結果として得られたディレクトリツリーに含まれる見出ノードに対応する情報を検索する情報検索手段とを有する。

また、本発明にかかる情報管理方法は、１つ以上の関連ノードと、１つ以上の見出ノードとを関連付けてディレクトリツリーのデータベースにおける情報管理方法であって、前記関連ノードそれぞれは、１つ以上の前記見出ノードと関連付けられ、前記見出ノードそれぞれには１つ以上の情報が属し、前記関連付けられた前記関連ノードと前記見出ノードとの間それぞれに対しては、これらの間の関連を示す関連属性が定義され、前記関連ノードそれぞれの関連ノードエントリと、前記関連属性それぞれの関連属性エントリとを作成し、これらのエントリを、前記関連ノードと前記関連属性との関連に従って対応付けて、ディレクトリツリーを作成し、前記見出ノードそれぞれに対応する情報を、前記作成された関連属性エントリに、前記見出ノードと前記関連属性との関連に従って対応付ける。

好適には、前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、前記ディレクトリツリーおよび前記サブツリーそれぞれには、さらに１つ以上の前記サブツリーが含まれることがあり、前記ディレクトリツリーおよび前記サブツリーそれぞれから、さらに前記サブツリーを作成する。

好適には、前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とをそれぞれ記憶し、前記記憶された見出ノードに対応する情報を検索する。

好適には、検索条件を受け入れ、前記受け入れられた検索条件に対応する前記分類情報と対応付けられた前記ディレクトリツリーまたは前記サブツリーを検索し、前記検索の結果として得られたディレクトリツリーに含まれる見出ノードに対応する情報を検索する。

好適には、前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とを、複数の第１のデータベース装置に記憶し、ある第１のデータベース装置に記憶された情報を、他の第１のデータベース装置に転送して記憶させる。

また、本発明にかかるプログラムは、コンピュータを含み、１つ以上の関連ノードと、１つ以上の見出ノードとを関連付けてディレクトリツリーのデータベースとするデータベースシステムのプログラムであって、前記関連ノードそれぞれは、１つ以上の前記見出ノードと関連付けられ、前記見出ノードそれぞれには１つ以上の情報が属し、前記関連付けられた前記関連ノードと前記見出ノードとの間それぞれに対しては、これらの間の関連を示す関連属性が定義され、前記関連ノードそれぞれの関連ノードエントリと、前記関連属性それぞれの関連属性エントリとを作成し、これらのエントリを、前記関連ノードと前記関連属性との関連に従って対応付けて、ディレクトリツリーを作成するステップと、前記見出ノードそれぞれに対応する情報を、前記作成された関連属性エントリに、前記見出ノードと前記関連属性との関連に従って対応付けるステップとをコンピュータに実行させる。

本発明によれば、データベースの構造を変更することなく、様々な種類の情報の追加が容易なデータベースシステムおよびその方法を提供することができる。
また、本発明によれば、情報の記述が簡単で、情報の表記および格納方法が一意的なデータベースシステムおよびその方法を提供することができる。
また、本発明によれば、データベースが複数の装置に分散されているときに、これら複数の装置間における負荷分散が容易なデータベースシステムおよびその方法を提供することができる。
また、本発明によれば、このように登録された情報を検索するために適したデータベースシステムおよびその方法を提供することができる。

［本発明がなされるに至った経緯］
本発明の理解を助けるために、まず、本発明がなされるに至った経緯を説明する。
様々な要素を含むデータを、効率的に収集し、それらのデータを記憶することが行われている。
記憶されたデータから、必要に応じてデータを読み出しこれらのデータを正確に再現することが望まれている。
一般に、直積集合Ａ×Ｂの部分集合Ｒ⊆Ａ×Ｂにおいて、順序対（ａ，ｂ）∈Ｒに対して、ａＲｂと表記すると、これは「ａはｂと関係Ｒを有する」ことを意味する。
簡単なデータの一例として、「作家シェークスピアは戯曲ハムレットを書いた。」を例にとる。

これらのデータは２項関係にあるので、「作家シェークスピア」＝ａ、Ｒ＝作者−作品、ｂ＝「戯曲ハムレット」と置くことにより、「作家シェークスピアは戯曲ハムレットを書いた。」なるデータが、「ａＲｂ」と表記される。
これらのデータは、データベースに記憶する際に、「ａ」、「Ｒ」及び「ｂ」として記憶され、データを読み出す場合にも一意に再現できる。
しかし、データの構成要素数が増えた場合は、すなわち２項関係ではなくｎ項関係になる場合には、これら関連性をもつ一連のデータはハイパーグラフ構造として表現され、処理は簡単ではない。
このため、一般にはｎ項関係を２項関係に分割して、それらの組合せとして表現し、データベースに記憶する手法がとられる。

第１の例として「作家シェークスピアは戯曲ハムレットを英国で1600年頃書いた。」を例にとって説明する。
この例は４項関係を表したものであるが、２項関係に展開すると、4Ｃ2＝６であるので表１に示すように６つの２項関係の組合せとして表現される。

すなわち、ｎが大きくなると、ｎ項関係を表現するためにnＣ2なる数の２項関係の表現が必要となってしまう。

さらに、第２の例として「作家シェークスピアは戯曲十二夜を1600年頃書いた。」を例として取り２項関係の組合せで表現すると、３項関係すなわちｎ＝３であるので、3Ｃ2＝３となり、表２に示すようになる。

ここで、第１の例の情報と第２の例の情報とが同じデータベースに記憶されている場合、「作家シェークスピア」−「作者−創作年代」−「1600年頃」からなる同一の２項関係が記憶されるという問題が起こる。
また、上記第１及び第２の例として示された２項関係のうち、どれを組み合わせて元の情報を再現すればよいか判断できないという問題も生じる。
これらは２項関係毎に識別子を付ければ解消される問題であるが、データ構造や処理が煩雑になるという欠点がある。

２項以上のデータ構成要素を有するデータを記憶する方法としては、リレーショナル・データベースによる記憶方法が知られている。
これは、データ項目名（データ属性）が列に割り当てられたテーブルを定義・作成し、具体的なデータをテーブルの行に順次入力していくものである。

「作家シェークスピアは戯曲ハムレットを英国で1600年頃書いた。」を例にとって説明する。
データ項目名としては、（１）「誰が」、（２）「何を」、（３）「何時」、（４）「どこで」、（５）「何故」、（６）「どのように」を指定することができる。
そしてこれらのデータ項目に対応して、（１）「作家シェークスピア」、（２）「戯曲ハムレット」、（３）「1600年頃」、（４）「英国」、（５）「（ブランク）」、（６）「書いた」のデータを記憶することができる。

しかしながら、この方法では、次のような問題が生じる。
（１）データ項目名を、取得したデータに合わせて、後から追加することが簡単にはできない。定型の構成要素からなるデータの場合には、問題にはならないが、様々な構成要素を含むデータを入力する場合には、構成要素が増加するたびに、データ項目名を追加するためのスキーマの変更が必要となる。スキーマの変更はオンラインでデータの入力時には一般に困難である。
（２）後から追加することが簡単にはできないために、最初のデータベース構築時に、最大限のデータ項目数を挙げて、スキーマを構築することが考えられる。しかし入力する可能性の低いデータに対しても、データ項目としてスキーマを構築することは、メモリの使用効率が低くならざるを得ない。

このような問題を解決するために、従来の関係データモデルに代わるモデルとして、英国「Lazy Software」社による「Associative Model of Data（データ関連モデル）」法によるデータ記憶方法が提案されている。
このデータモデルでは情報を事物と事物間の関連性と見なし、この関連性を「Source-Verb-Target」構文で表現している。
これによれば、上記のリレーショナル・データベースによる記憶方法で生じる問題の幾つかは解消される。
しかし、複雑なデータ関係を取扱う場合には、データ間の関係の表現方法が、複雑となり直感的でないこと、及び２分木的な形式を用いてｎ項関係を表現するため表現が一意に定まらず、データベースにデータを記憶する際に、作業者の任意にデータの構造を変えることができるために、データをデータベースから読取り再現する場合に、正確に入力情報を再現できない場合が発生するという問題がある。

上記のように、従来、相互に関係のある複数のデータを記憶する方法としては、リレーショナル・データベースが知られていた。
これは、記憶しようとするデータ項目を予め定めておき、データ項目に該当するデータを記憶するものである。
データの関係が見易いという利点はあるもの、一旦構成されたデータベースのデータ項目を追加すること、すなわち、一旦構成されたデータベースの構造（スキーマ）を変更することは簡単ではない。
また後から追加したデータ項目に対応するデータは、従前から記憶されているデータに対して、空白エリアが生じメモリの使用効率が悪くなるという問題が生じている。
これに対して、Lazy Software社が提唱しているデータ関連モデルでは、データ項目数を追加する場合の困難さ、及びメモリの使用効率の低下といった問題は解決されるものの、データの記述内容が複雑になりデータ構造を見ても直感的ではなく、データの表記・記憶方法が一意的でないといった別の問題が生じる。

本発明では、見出ノード群と各ノード間の関連性を示すエッジ群から構成される関連性ネットワーク型データに対して、関連性（エッジ）を新たに関連ノード（以下、本願明細書では「Ａノード」と呼ぶ。）とし、当該Ａノードと関連性のある見出ノード（以下、本願明細書では「Ｔノード」と呼ぶ。）がその関連において果たす役割（以下、本願明細書では「関連性役割」と呼ぶ。）を属性とするエッジから成るデータモデルを定義する（図１）。
このモデルに従って変換されたデータ構造から、１つのＡノードとＴノード、及びその間の関連性役割を基本構成要素として抽出し、これらを表３に示すようにリレーショナル・データベースにおいて定義される関連性役割テーブル（以下、本願明細書では「ＡＲテーブル」と呼ぶ。）の行（レコード）に対応付け、リレーショナル・データベース管理システムにより記憶・管理する方法を実現する。

これにより、あるデータ（見出ノード）に関する新たな属性情報を別の関連性データとして定義し、それに対応するＡノード、Ｔノード及びノード間のエッジの組合せ（すなわち、本発明のデータモデルにおける基本構成要素）を用いてＡＲテーブルの行に対応付けられるデータとして表現すれば、既存のテーブル構造（データベース・スキーマ）を変更することなく新たな属性情報の追加が可能となる。
さらに、Ａノード及びＴノードにそれぞれ一意に同定できる識別子を付与し、各識別子に対して、ノードの属性型を表わすノードタイプと、属性値すなわちノードの具体的な内容を表わすノード名を有する識別子テーブル（以下、本願明細書では「ＩＤテーブル」と呼ぶ。）を定義する（表５）。

これらのデータを、上記ＡＲテーブルと同様に、リレーショナル・データベース管理システムにより記憶・管理する。
また、あるＡノードにより示される関連性のもつ意味を具体的に記述するデータとして１つのＴノードを新しく設け、これら２つのノードを「具象化」という予め定義された関連性役割で関連付ける。
当該Ｔノードと、別のＡノードに関して同様に新しく設けられたＴノードとの間での関連性を定義・記述することにより、元の２つのＡノードにより示される関連性の間に存在する関係を表現することができる。

Ａノードのもつ意味を記述するために特に導入された関連性役割「具象化」により関連付けられるＴノードは、上記のＡＲテーブルにより記憶・管理できる。
これらＩＤテーブル及びＡＲテーブルを用いて各ノードを管理することにより、ＡノードとＴノードの関連性だけでなく、ＡノードとＡノードの関連性についても表記可能となるデータの表現方法を実現する。

一般に、一つの共通の関連性を有するｎ個のデータからなるデータ集合について、２項関係で表現すると、nＣ2個のデータの組が必要となるが、本願発明によれば、ｎ個のデータの組でよい。
言い換えると一つの共通の関連性を有するｎ個の要素を持つデータ集合について（図２、（ａ））、これらのデータをデータベースに記憶する場合に、当該データ集合に共通するノード（Ａノード）を新たに１つ設け、次に各要素毎にその関連性役割を定義する（図２、（ｂ））。
これにより、「Ａノード」、「Ｔノード」及び「関連性役割」を一組のデータとして定義すれば、本願発明のデータ構造は構築できる（表４）。

図２（ｂ）及び表４で使用されている「Ａ１」はＡノードに付与された識別子であり、別の識別子「Ｔ１」〜「Ｔｎ」が付与された一群のデータ（Ｔノード）が何等かの共通の関連性を有していることを示すものである。
Ａノードに付与された識別子が異なれば、それらの一連のデータは別の意味で何等かの共通の関連性を有していることになる。
さらに、識別子が付与されたＡノード及びＴノードに対して、表５に示すようにノードタイプとノード名をデータ属性としてもつＩＤテーブルを作成する。

また、ＴノードＴ１とＴ２がＡノードＡ１により関連付けられ、ＴノードＴ１とＴ３がＡノードＡ２により関連付けられる関連性ネットワーク型データに対し（図３、（ａ））、ＡノードＡ１が示す関連性の意味を具体的に記述するＴノード（識別子Ｔ１１）を新たに設け、「具象化」という予め定義された関連性役割でＡ１と関連付ける。
同様に、ＡノードＡ２と新たなＴノードＴ１２を関連性役割「具象化」で関連付け、これら２つのＴノードＴ１１とＴ１２との間にある関連性を、ＡノードＡ１１を用いて定義する（図３、（ｂ））。
これにより、元の２つのＡノードＡ１とＡ２の間の関係が、表６に示すようなＡＲテーブルを使って表現できる。

［データ記憶方法・データ構造］
以下、本発明におけるデータ記憶方法およびデータ構造を説明する。
具体例として、「作家シェークスピアは戯曲ハムレットを英国で1600年頃書いた。」を第１のデータとして説明する。
これらの情報は、（１）「作家シェークスピア」、（２）「戯曲ハムレット」、（３）「1600年頃」、（４）「英国」の要素をもつ４項関係を表したものである。
２項関係に分割してデータの関係を表現すると、4Ｃ2＝６であるので以下の表７に示す様に６個の組合せとして表現される。

本願発明に従って、これらの情報を変換する。先ず第１番目のデータについて変換する。
見出ノード１にある「作家シェークスピア」は、この情報において「作者」であることを示しているので、「作家」と「シェークスピア」とに分けて、「シェークスピア」をＴノード、「作者」を関連性役割とする。また、後述するように、「作家」をＴノードのノードタイプとする。
また関連性を示すエッジ「作者−作品」については、上記の一連の情報が同じグループであることを示すために「ハムレット著作について」としてＡノードを設ける。
「ハムレット著作について」のデータは、一連の情報が同じグループであることを示すために用いるので、他のグループの情報との識別ができるものであれば、他の表現でもかまわない。

「Ａノード」−「Ｔノード」−「関連性役割」の構造で記述すると、表８に示すようになる。

同様に見出ノード２にある「戯曲ハムレット」は、この情報において「作品」であることから、変換すると表９のようになる。
また、「戯曲」をＴノードのノードタイプとする。

次に、第２番目のデータについて同様に変換すると、表１０のようになる。

ここで、「ハムレット著作について」「シェークスピア」「作者」の情報は、冗長なデータなので省略することができる。以下同様に全てのデータについて変換し、冗長なデータを削除すると表１１のようになる。

従って、一つの共通の関連性を有する４個のデータからなるデータ集合について、２項関係で表現すると、4Ｃ2＝６であるので６個のデータの組が必要となるが、本願発明によれば、４個のデータ組でよいことが分かる。
言い換えると、４個の要素を持つデータ集合について、これらのデータをデータベースに記憶する場合に、当該データ集合に共通するノード（Ａノード）を新たに１つ設け、次に要素毎にその関連性役割を定義し、「Ａノード」、「Ｔノード」及び「関連性役割」を一組のデータとして定義すれば、本願発明のデータ構造は構築できる。
ここで、Ａノード「ハムレット著作について」に識別子「Ａ１」を付与する。ノード識別子「Ａ１」を共通にもつこれらのデータは、一つのグループに属することが分かる。
さらに、４つのＴノード「シェークスピア」、「ハムレット」、「1600年頃」、「英国」に対して識別子「Ｔ１１」〜「Ｔ１４」をそれぞれ付与する。
これにより、第１の例から作成されるＡＲテーブルは表１２のようになる。

また、「ハムレット著作について」を示すＡノード（識別子Ａ１）のノードタイプを「著作関連情報」とし、識別子Ｔ１１〜Ｔ１４が付与されたＴノードのノードタイプをそれぞれ「作家」、「戯曲」、「年代」、「国」とすることにより、表１３に示すようなＩＤテーブルが作成される。

さらに、第２のデータとして「戯曲ハムレットを原作とする日本語翻訳版が2003年２月に○○出版社から出版された。」の情報を例にとる。
これらの情報を本願発明に従ってデータを構成すると次のようになる。ここで一連の情報要素に共通するＡノードは「ハムレット日本語訳について」とし、識別子「Ａ２」を付与すると表１４のようになる。

原作であるハムレットには既に識別子「Ｔ１２」が付けられているので、翻訳版ハムレットに「Ｔ２２」、出版日及び出版社に対してそれぞれ識別子「Ｔ２３」、「Ｔ２４」を付与すると、第２のデータに対するＡＲテーブルは表１５のようになる。

また、表１６に示すＩＤテーブルが作成される。

これら第１及び第２のデータ、さらに同様のデータ変換処理が施された他のデータも同じデータベースに記憶されるので、最終的に表１７及び表１８に示すようなＡＲテーブル及びＩＤテーブルが得られる。

さらに、図４に示すように、識別子がＡ１及びＡ２であるＡノードにより示される関連性のもつ意味を具体的に記述するためのＴノードを設け、それぞれに識別子「Ｔ３１」及び「Ｔ３２」を付与し、ノードＡ１及びノードＡ２と関連性役割「具象化」で関連付ける。
これら２つの新たなＴノードのノードタイプを「著作情報」とし、ノード名としてはそれぞれ「ハムレット著作について」及び「ハムレット日本語訳について」とする。
ノードＴ３１とノードＴ３２との関連性を示すＡノードを、識別子Ａ３としてさらに新しく設け、ノードタイプを「原作−翻訳情報」とする。
また、ここでの関連においてノードＴ３１及びノードＴ３２が果たす役割をそれぞれ「原作情報」、「翻訳情報」とする。以上の処理から、表１９に示したＡＲテーブル及び表２０に示したＩＤテーブルが追加される。

上記の第１及び第２のデータを、リレーショナル・データベースに直接記憶するためには、データ項目名として、新たに翻訳版としての「ハムレット」あるいは「○○出版社」などに対応する項目（データ属性）を追加する必要がある。これはデータベースのテーブル構造を変更することになるので簡単ではない。
本発明では、例に示した様に既存のＡＲテーブルに対し行を追加することにより、異なるデータ属性を有する情報を複数の組として記憶することが可能である。
また、第１及び第２のデータを、Ａノード、Ｔノード及び各ノード間の関連を示すエッジを用いて表現すると図４のようになる。
本発明では、こうした複雑な構造をもつデータを容易に表現するための方法とリレーショナル・データベースへの記憶・管理方法を提供している。

次に本願発明のデータベースから所望のデータを検索する場合について説明する。
以下に、ユーザが「作家シェークスピアの書いた戯曲ハムレットの日本語訳の出版社を知りたい」場合を例にとって説明する。
図５にそのフローチャートを示す。以下に図５のフローチャートの説明をする。

１１０：ユーザは検索条件を「作家」である「シェークスピア」の「戯曲」として入力する。
１２０：検索条件に合致する複数組のデータを収集する。
１３０：複数組検出された情報の中から、「戯曲」に対応する情報を順次表示する。
１４０：ユーザはこれらの中から所望の戯曲名、すなわち「ハムレット」を選択する。
１５０：「ハムレット」及び「翻訳版」を新たな条件として、データを検索する。
１６０：検索条件に合致する複数組データを収集する。
１７０：検出された複数組の中から「出版社」及び「出版日」に関するデータを順次表示する。
１８０：ユーザは所望の出版社を選択する。

以下、詳細に説明する。
ユーザは検索条件として、Ｔノードのノード名が「シェークスピア」であり、関連性役割が「作家」であることを入力し情報を検索する。
データベースの中でＡＲテーブルを参照し、関連性役割が「作家」であるＴノードの識別子を検出し、続いて、ＩＤテーブルに記憶されているノード名属性を参照し、「シェークスピア」をノード名とするＴノードに対応するＡノード識別子が複数組検出される。
複数組検出されたＡノード識別子をもつ情報の中から、別の検索条件、つまり関連性役割が「戯曲」となっているＴノード識別子がＡＲテーブルより選出される。
この識別子に基づいて、ＩＤテーブルから対応する戯曲に関する情報が順次表示される。

すなわち「ハムレット」、「じゃじゃ馬ならし」、「ベニスの商人」、「真夏の夜の夢」、「リア王」などの戯曲名が順次表示される。ユーザはこれらの中から所望の戯曲名、すなわち「ハムレット」を選択する。
引き続き、選択された「ハムレット」の識別子「Ｔ１２」をキーとして、ＴノードＩＤに「ハムレット」の識別子を含み、かつ、関連性役割が「翻訳版」であるＡノード識別子をＡＲテーブルから検索する。
これにより、検索条件を満足するＡノード識別子により関連付けられた複数組の情報が検出される。
検出された複数組の情報から、関連性役割として「出版社」及び「出版日」をもつＴノードのノード名を、順次、ＩＤテーブルを参照しながら表示する。
ユーザはその中から所望の出版社、すなわち最近「2003年２月」に戯曲ハムレットの翻訳版を出版した「○○出版社」を選択することができる。

以上、図５に示した例は、検索例の一例として説明したものである。
つまり検索条件が多くなると、データベースの検索は、図５に示されているように２回に限定されるものではなく、所望の条件に応じて任意回数繰り返し行われることは言うまでもない。
また、ここで示した具体例においては、関連性役割として単一の属性が割り当てられているが、これに限定されるものではない。
すなわち、関連性役割に複数の属性をもたせることも可能である。上記の例では、関連性役割「戯曲」に対して「悲劇」、「喜劇」、「ロマンス劇」、「史劇」等のジャンルを追加して指定することにより、さらに詳細な関連性役割を定義することができる。

［本発明にかかるデータ記憶方法・データ構造の特徴］
以上説明したように、本発明にかかるデータ記憶方法およびデータ構造によると、現在、広く一般に用いられているリレーショナル・データベースのテーブル形式を用いて、３項以上の関係、一般にｎ項の相互に関連性をもった一連のデータの関係を表すハイパーグラフの構造を保持したまま、データを記憶及び管理することができる。
また、関連性ネットワーク型データをリレーショナル・データベースのテーブルに直接マッピングする方法では、３項以上の関係、一般にｎ項関係を表すデータを効率よく記憶・管理できないという問題が解決される。

また、既にデータベースに記憶されているデータに対して、属性情報を追加するなどの変更を行うにはリレーショナル・データベースのテーブル設計の変更が必要となり、柔軟性に欠けるとともに膨大な労力がかかるという問題が解決される。
さらに、同一のデータベース・スキーマの枠組みで、データに付与された識別子と関連性役割を用いて一連の関連性のもつ意味を記述することができる。

［第１のデータベース装置１］
以下、本発明にかかる第１のデータベースを説明する。
図６は、本発明にかかる第１のデータベースシステム（ＤＢシステム）１の構成を例示する図である。
図６に示すように、本発明にかかる第１のＤＢシステム１は、データベース装置（ＤＢ装置）１２が、必要に応じて、ＬＡＮ、ＷＡＮおよびインターネットなどのネットワーク１００を介して、データ入力および検索のためなどに用いられるコンピュータ（ＰＣ）１０２と接続されて構成される。
なお、以下の説明においては、図４，図５および表７〜表２０を参照して上述した本発明にかかるデータ記憶方法およびデータ構造の説明においてと、一部、用語が異なることがあるが、これらの説明の間で対応する用語は、実質的に同じである。
また、ＤＢシステム１の説明については、以下の用語が、上述した本発明にかかるデータ記憶方法およびデータ構造の説明における用語よりも優先される。
また、以下の各図において、同様な構成部分には同じ符号が付される。

［ハードウエア構成］
図７は、図６に示したＤＢ装置１２およびＰＣ１０２のハードウエア構成を例示する図である。
図７に示すように、ＤＢ装置１２およびＰＣ１０２は、ＣＰＵ１２２、メモリ１２４およびこれらの周辺回路などを含む本体１２０、表示装置およびキーボードなどを含む入出力装置１２６、ＣＤ装置およびＨＤＤ装置などの記録装置１２８から構成される。
また、さらに、ＤＢ装置１２およびＰＣ１０２（以下、通信を行う構成部分を通信ノードと総称することがある）が、ネットワーク１００に接続されるときには、ネットワーク１００を介した他の通信ノードとの間の通信を行う通信装置１３２が付加されることがある。
つまり、ＤＢ装置１２およびＰＣ１０２は、他の通信ノードとの間で通信を行う機能を有しうるコンピュータとしての構成部分を含む。

［データ構造］
ＤＢ装置１２においては、上述した本発明にかかるデータ記憶方法およびデータ構造（図４，図５および表７〜表２０）を応用したデータの記憶および記憶されたデータの検索が行われる。
まず、本発明にかかるＤＢ装置１２の詳細を説明する前に、その理解を助けるために、ＤＢ装置１２におけるデータ構造およびデータ検索について説明する。

図８は、図３（ａ）に例示したデータの関連を書き換えて示す図である。
図８に示すように、ＤＢ装置１２においては、上述の本発明にかかるデータ記憶方法およびデータ構造においてと同様に、見出ノード(Topic Node；以下、Ｔノードと記す)が、１つ以上の関連ノード（Association Node；以下、Ａノードと記す）と関連付けられ、関連付けられたＴノードとＡノードとの間には、関連属性Ｒが定義される。
なお、関連属性Ｒは、ＴノードとＡノードとの関連について定義されうるどのような属性でもよいが、以下、説明の具体化および明確化のために、上述の本発明にかかるデータ記憶方法およびデータ構造の説明においてと同様に、関連属性Ｒが、関連性役割Ｒである場合を具体例とする。

図３（ａ）に示したデータの関係は、書き換えにより、図８に示すように表される。
図８に示すＡノードＡ１〜Ａｎ（以下、ｎは１以上の整数を示す。但し、全てのｎが同じ数を示すとは限らない。）の内、ＡノードＡ１と、ＡノードＡ１に関連するＴノードＴ１−１〜Ｔ１−３，Ｔ２−１とは、エッジで結ばれている。
同様に、ＡノードＡ２に関連するＴノードＴ２−１，Ｔ２−２，Ｔｎ−１と、ＡノードＡ２とはエッジで結ばれている。
また、ＡノードＡｎについても同様であって、ＡノードＡｎに関連するＴノードＴｎ−１〜Ｔｎ−４とＡノードＡｎとはエッジで結ばれている。
つまり、図８には、ＴノードＴ２−１が、ＡノードＡ１，Ａ２の両方に関連性を有し、ＴノードＴｎ−１は、ＡノードＡ２，Ａｎの両方に関連性を有することが示されている。

図９は、図８に示したデータ構造を一般化して示す図である。
図８において、ＴノードＴ１−１から、ＡノードＡ１、ＴノードＴ２−１、ＡノードＡ２およびＴノードＴｎ−１を経て、ＡノードＡｎに至るようにエッジをたどると、図９において、上から下の方向に伸びるパスが得られる。

なお、図９には、
（１）ＴノードＴ１−１〜Ｔ１−ｍ１，Ｔ２−１が、ＡノードＡ１に関連付けられ、ＴノードＴ１−１〜Ｔ１−ｍ１，Ｔ２−１とＡノードＡ１との間の関連（エッジ）には、関連性役割Ｒ１−１〜Ｒ１−ｍ１，Ｒ１−０が定義され、
（２）ＴノードＴ２−１〜Ｔ２−ｍ２および図９において省略されたＴノードが、ＡノードＡ２に関連付けられ、ＴノードＴ２−１〜Ｔ２−ｍ２とＡノードＡ２との間の関連には、関連性役割Ｒ２−１〜Ｒ２−ｍ２が定義され、
（３）以下、同様に、図９において省略されているＴノードとＡノードとが関連付けられ、これらの間に関連性役割Ｒが定義され、
（４）ＴノードＴｎ−１〜Ｔｎ−ｍｎおよび図９において省略されたＴノードが、Ａノー ドＡｎに関連付けられ、ＴノードＴｎ−１〜Ｔｎ−ｍｎとＡノードＡｎとの間の関連には、関連性役割Ｒｎ−１〜Ｒｎ−ｍｎ（ｍ１〜ｍｎ，ｎは整数）が定義され
ている場合が具体例として示されている。

つまり、ＤＢ装置１２においては、Ｔノードそれぞれが、１つ以上のＡノードと関連付けられ、また、Ａノードそれぞれが、１つ以上のＴノードと関連付けられることにより、Ａノードを介して複数のＴノードが関連付けられ、また、Ｔノードを介して複数のＡノードが関連付けられうる。
ＤＢ装置１２においては、図９に示すように関連付けられたＡノードとＴノードのとの組み合わせが、複数、記憶されうる。

図１０は、図３（ｂ），図４に示したデータの関係を、一般化して示す図である。
図３（ｂ），図４に示したデータの関係は、図１０に示すように一般化して表されうる。
図１０において、ＡノードＡ１に関連するＴノードＴ１−１〜Ｔ１−３（，Ｔ３−１）とＡノードＡ１とはエッジで結ばれ、ＡノードＡ２に関連するＴノードＴ２−１〜Ｔ２−３（，Ｔ３−２）とＡノードＡ２とはエッジで結ばれ、ＡノードＡｎとＴノードＴｎ−１〜Ｔｎ−３，Ｔ２−３（，Ｔ３−ｎ）とはエッジで結ばれている。
ＴノードＴ２−３は、ＡノードＡ２，Ａｎの両方とエッジで結ばれており、このことは、ＴノードＴ２−３が、ＡノードＡ２，Ａｎの両方に関連することを示している。
ここで、ＡノードＡ１，Ａ２，Ａｎにより関連付けられる一連の情報が、共通の関連性を有するときには、新たな関連ノードＡ３が定義されうる。
例えば、ＡノードＡ１が、ハムレットの原作に関する情報であり、ＡノードＡ２が、ハムレットの翻訳に関する情報であり、ＡノードＡｎが、ハムレットの公演に関する情報であるときには、これらのＡノードＡ１，Ａ２，Ａｎにより示される関連情報は、ハムレットに関する情報としての共通性を有する。

そこで、ＡノードＡ１，Ａ２，Ａｎにより関連付けられる情報が、共通性を有することを示すために、新たな関連ノードＡ３が定義され、データベースに格納される。
また、図１０中に破線で囲って示すように、ＡノードＡ１およびＴノードＴ１−１〜Ｔ１−３により示される一連の情報を具体的に記述するために、新たなＴノードＴ３−１が定義され、データベースに格納される。
さらに、同様に、ＡノードＡ２，Ａｎの関連を具体的に記述する新たなＴノードＴ３−２，Ｔ３−ｎが定義され、データベースに格納される。
例えば、ＴノードＴ３−１には、見出しの内容として「ハムレット著作について」、ＴノードＴ３−２には、見出しの内容として「ハムレット日本語訳について」、ＴノードＴ３−ｎには、見出し内容として「ハムレット公演について」などのデータが定義され、データベースに格納される。

さらに、新たなＡノードＡ３と、Ｔノード３−１〜Ｔ３−ｎそれぞれとの間に、関連性役割Ｒが定義され、データベースに格納される。
例えば、新たなＡノードＡ３とＴノードＴ３−１との間に、関連性役割Ｒとして「原作情報」が定義され、新たなＡノードＡ３とＴノードＴ３−２との間に、関連性役割Ｒとして「翻訳情報」が定義され、新たなＡノードＡ３とＴノードＴ３−ｎとの間に、関連性役割Ｒとして「公演情報」などのデータが定義され、データベースに格納される。
同様に、例えば、ＡノードＡ１，Ａ２，ＡｎとＴノードＴ３−１，Ｔ３−２，Ｔ３−ｎとの間には、「具象化」という予めシステムにより定義された関連性役割Ｒが定義される。

図１１は、図９に示した構造を採るデータを記憶するために用いられる関連性役割（ＡＲ(Association Role)）テーブルを示す図である。
図１２は、図９に示した構造を採るデータを記憶するために用いられるＴノード用識別子（ＩＤ(Identifier)）テーブルを示す図である。
図１３は、図９に示した構造を採るデータを記憶するために用いられるＡノード用識別子（ＩＤ）テーブルを示す図である。
ＤＢ装置１２において、図９に示した構造により関連付けられたＡノードおよびＴノードと、Ｔノードのデータは、図１１に示すＡＲテーブル、および、図１２に示すＩＤテーブルを用いて記憶される。

図１１に示すＡＲテーブルのエントリそれぞれは、ある１つのＡノードと、このＡノードに関連付けられた１つのＴノードと、これら関連付けられたＡノードとＴノードとの間に定義される関連性役割（Ｒ）を示し、あるＡノードの識別子（ＩＤ）と、このＡノードに関連付けられたＴノードの識別子と、これら関連付けられたＡノードとＴノードとの間に定義された関連性役割（Ｒ）を含む。
つまり、ＡＲテーブルのエントリそれぞれは、図９に示したいずれかのエッジの一端にあるＡノードの識別子と、このエッジの他端にあるＴノードの識別子と、このエッジに対して定義される関連性役割とを含む。

このようなエントリを、図９に示した全てのエッジ（Ｔ１−１〜Ａ１の間のエッジ〜Ｔｎ−ｍｎ〜Ａｎ間のエッジ）について作成し、ＡＲテーブルに記憶することにより、図９に示したＡノードとＴノードとの関連は、図１１に示すＡＲテーブルに記憶される。
また、Ｔノードそれぞれは、内容（Ｔノードの名称、Ｔノード自体のデータおよびＴノードにより参照されるデータなど）を有し、さらに、Ｔノードそれぞれには、ＡＲテーブルの各エントリに記憶される識別子（ＩＤ）の他に、このＴノードの属性（ノードタイプ（ＮＴ）；見出属性）が定義される（以下、Ｔノードが、その内容として、その名称（ノード名（Ｎ））のみを有する場合を具体例とする。）。

図１２に示すＴノード用のＩＤテーブルのエントリそれぞれは、図９に示したいずれかのＴノードの識別子（ＩＤ）と、このＴノードに対して定義された属性（ノードタイプ（ＮＴ））と、このＴノードの名称（ノード名（Ｎ））とを含む。
このようなエントリを、図９に示した全てのＴノードＴ１−１〜Ｔｎ−ｍｎについて作成し、Ｔノード用のＩＤテーブルに記憶することにより、図９に示した全てのＴノードについてのデータが記憶される。
図１３に示すＡノード用のＩＤテーブルのエントリそれぞれは、図９に示したいずれかのＡノードの識別子（ＩＤ）と、このＡノードに対して定義された属性（ノードタイプ（ＮＴ’））と、このＡノードの名称（ノード名（Ｎ’））とを含む。
このようなエントリを、図９に示した全てのＡノードＡ１〜Ａｎについて作成し、Ａノード用のＩＤテーブルに記憶することにより、図９に示した全てのＡノードについてのデータが記憶される。

なお、図９に示したＡノードとＴノードとの関連、ＡノードのデータおよびＴノードのデータを記憶するためには、テーブル形式以外に、同様な形式が採られうるが、以下の説明においては、ＡＲテーブルおよびＩＤテーブルを用いる場合が具体例とされる。
なお、ＤＢ装置１２の用途、構成あるいは処理内容によっては、図１１に示すように、ＡＲテーブルにおいて、各エントリは、Ｔノードの識別子（ＩＤ）の代わりに、Ｔノードの内容（ノード名（Ｎ））を含んでもよい。
また、同様に、ＡＲテーブルにおいて、各エントリは、Ｔノードの内容を、さらに含んでもよい。

［データ検索］
図１４は、図６，図７に示したＤＢ装置１２におけるデータ検索方法を例示する図である。
ここでは、図１４に示すように、あるＡノードに、ＴノードＴ１〜Ｔｎおよび検索結果（出力）とされるべきＴノードＴｒｅｔ(T return)が関連付けられ、ＡノードとＴノードＴ１〜Ｔｎ，Ｔｒｅｔとの間に、関連性役割Ｒ１〜Ｒｎ，Ｒｒｅｔが定義され、ＴノードＴ１〜Ｔｎ，Ｔｒｅｔが、ノード名Ｎ１〜Ｎｎ，Ｎｒｅｔを有する場合を具体例とする。

ＤＢ装置１２においては、検索結果として得たいＴノードに対して定義される関連性役割Ｒｒｅｔと、検索のために用いられ得るＡノードの属性（ノードタイプＮＴ；図１４においてＡＮＴ１，ＡＮＴ２）と、検索のために用いられ得るＴノードの関連性役割Ｒとノード名Ｎの１つ以上の組み合わせとが検索条件として用いられる。
この検索条件は、図１４に示すように、例えば、（Ｒｒｅｔ，（ＡＮＴ１，ＡＮＴ２，．．．），Ｆｉｌｔｅｒ），Ｆｉｌｔｅｒ＝（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ））と表記される。
なお、この検索条件は、後述するように、さらにＴノードの属性ＮＴ（第３の条件データ）を含みうる。
上記検索条件の内、Ｆｉｌｔｅｒに含まれるＴノードの関連性役割Ｒとノード名Ｎの１つ以上の組み合わせ（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ）それぞれは、検索のためのフィルタとして用いられるので、以下、検索フィルタとも記載される。

また、上記検索条件の内、Ａノードの属性（ＡＮＴ１，ＡＮＴ２，．．．）は、省略されうる。
図１５は、図６，図７に示したＤＢ装置１２における検索の全体的な処理（Ｓ２０）を示す第１のフローチャートである。
図１５に示すように、ステップ２００（Ｓ２００）において、ＤＢ装置１２は、例えば、ＰＣ１０２（図６）あるいはＤＢ装置１２の入出力装置１２６に対する検索者の操作に応じて、図１４に例示した検索条件を受け入れる。

ステップ２２（Ｓ２２）において、図１６を参照して後述する検索フィルタに基づく関連ノードの選択を行う。
ステップ２４（Ｓ２４）において、図１７を参照して後述するノードＩＤおよびノード名の取得を行う。

ステップ２０２（Ｓ２０２）において、ＤＢ装置１２は、Ｓ２４の処理により検索結果として得られたＴノードＴｒｅｔの識別子（ノードＩＤ）およびノード名（Ｎｒｅｔ）から、検索者に対して返す応答を作成する。
この応答としては、ノード名Ｎｒｅｔのみ、ノードＴｒｅｔにより参照される様々なデータ、あるいは、ノードＴｒｅｔ自体を示すデータなど、様々なデータを例示されうる。

ステップ２０４（Ｓ２０４）において、ＤＢ装置１２は、検索者による問い合わせが終了したか否かを判断する。
ＤＢ装置１２は、検索者による問い合わせが終了した場合には処理を終了し、これ以外のときにはＳ２００の処理に戻る。

図１６は、図１５に示した検索フィルタに基づく関連ノードの選択処理（Ｓ２２）を示すフローチャートである。
図１６に示すように、図１５に示したＳ２００の処理において、ＤＢ装置１２は、検索条件（Ｒｒｅｔ，（ＡＮＴ１，ＡＮＴ２，．．．），Ｆｉｌｔｅｒ），Ｆｉｌｔｅｒ＝（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ））を受け入れると、ステップ２２０（Ｓ２２０）において、処理のために用いられる関連ノードリストを初期化する。

この関連ノードリストには、ＡＲテーブル（図１１）から得られたＡノードのうち、検索条件中のＡノードの属性（ノードタイプ；ＡＮＴ１，ＡＮＴ２，．．．）のいずれかを、その属性（ノードタイプＮＴ）として含むＡノードの識別子が記憶される。
なお、検索条件において、Ａノードの属性が省略された（（ＡＮＴ１，ＡＮＴ２，．．．）＝ｎｕｌｌ）ときには、Ｓ２２０の処理において、ＡＲテーブル（図１１）から得られたＡノードの全ての識別子が記憶される。
ステップ２２２（Ｓ２２２）において、ＤＢ装置１２は、全ての検索フィルタ（Ｒｉ，Ｎｉ）について処理を行ったか否かを判断する。

ＤＢ装置１２は、全ての処理について処理を行ったときにはＳ２４（図１５，図１７）の処理に進み、これ以外のときには、まだ処理の対象とされていないいずれかの検索フィルタ（Ｒｉ，Ｎｉ）を、次の処理対象としてＳ２２４の処理に進む。
ステップ２２４（Ｓ２２４）において、ＤＢ装置１２は、Ｔノード用のＩＤテーブル（図１２）を検索し、検索フィルタ（Ｒｉ，Ｎｉ）のノード名Ｎｉを含むエントリの全てを探し出し、探し出されたエントリに含まれるＴノードの識別子の集合（ノードＩＤ集合Ｔ）を作成する（Ｔ＝｛Ｔｉ｜ノード名＝Ｎｉ ｉｎ ＩＤテーブル｝）。
なお、検索条件にＴノードの属性（ノードタイプ；ＮＴ）が含まれ、検索フィルタが（Ｒｉ，Ｎｉ，ＮＴｉ）と表されるときには、ＤＢ装置１２は、Ｓ２２４の処理において、ＩＤテーブルから、検索フィルタ（Ｒｉ，Ｎｉ，ＮＴｉ）のノード名ＮｉおよびノードタイプＮＴｉを含むエントリを探し出し、探し出されたエントリに含まれるＴノードの識別子の集合をノードＩＤ集合Ｔとすればよい。

ステップ２２６（Ｓ２２６）において、ＤＢ装置１２は、Ｓ２２４の処理により得られたノードＩＤ集合Ｔが空集合であるか否かを判断する。
ＤＢ装置１２は、ノードＩＤ集合Ｔが空集合であるときには検索処理を終了するための処理（検索が失敗した旨を検索者に表示するなど）を行い、検索処理を終了し、これ以外のときにはＳ２２８の処理に進む。
ステップ２２８（Ｓ２２８）において、ＤＢ装置１２は、ＡＲテーブル（図１１）を検索し、関連ノードリストＡを更新する。
つまり、ＤＢ装置１２は、ＡＲテーブルから、検索フィルタ（Ｒｉ，Ｎｉ）の関連性役割Ｒｉと、Ｓ２２４の処理により得られたノードＩＤ集合Ｔに含まれるいずれかのＴノードの識別子を含むエントリの全てを探し出し、探し出されたエントリに含まれるＡノードの識別子を、関連ノードリストＡに格納する（Ａ＝｛Ａｊ｜役割Ｒｉ，Ｔノードの識別子Ｔｉ（ａｌｌ ｉ），Ａノード識別子∈Ａ ｉｎ ＡＲテーブル｝）。

ステップ２３０（Ｓ２３０）において、ＤＢ装置１２は、Ｓ２２８の処理により得られた関連ノードリストＡが空集合であるか否かを判断する。
ＤＢ装置１２は、関連ノードリストＡが空集合であるときには検索処理を終了するための処理を行い、検索処理を終了し、これ以外のときにはＳ２３２の処理に進む。
ステップ２３２（Ｓ２３２）において、ＤＢ装置１２は、検索条件に含まれる処理されていない検索フィルタを読み込み、Ｓ２２２の処理に戻る。

図１７は、図１５，図１６に示したノードＩＤおよびノード名取得処理（Ｓ２４）を示すフローチャートである。
図１７に示すように、検索フィルタに基づく関連ノードの選択処理（Ｓ２２）が終了すると、ステップ２４０（Ｓ２４０）において、ＤＢ装置１２は、ＡＲテーブル（図１１）を検索し、Ｔノード識別子集合Ｔを作成する。
つまり、ＤＢ装置１２は、ＡＲテーブルから、検索条件に含まれる関連性役割Ｒｒｅｔと、Ｓ２２（Ｓ２２８）の処理により得られた関連ノードリストＡに含まれるいずれかのＡノードの識別子とを含むエントリの全てを探し出し、探し出されたエントリに含まれるＴノードの識別子の集合（Ｔノード識別子集合Ｔ）を作成する（Ｔ＝｛Ｔｍ｜役割＝Ｒｒｅｔ，Ａノードの識別子∈Ａ ｉｎ ＡＲテーブル｝）。

ステップ２４２（Ｓ２４２）において、ＤＢ装置１２は、Ｓ２４０の処理により得られたＴノード識別子集合Ｔが空集合であるか否かを判断する。
ＤＢ装置１２は、Ｔノード識別子集合Ｔが空集合であるときには終了処理を行って検索処理を終了し、これ以外のときにはＳ２４４の処理に進む。
ステップ２４４（Ｓ２４４）において、ＤＢ装置１２は、Ｔノード用のＩＤテーブル（図１２）を検索し、ノードＩＤとノード名の組の集合Ｐを作成する。
つまり、ＤＢ装置１２は、ＩＤテーブルから、Ｓ２４０の処理により作成されたＴノード識別子集合Ｔに含まれるＴノードの識別子Ｔｍのいずれかを含むエントリの全てを探し出し、このエントリに含まれるノード名Ｎｍと、Ｔノードの識別子Ｔｍとの組の集合Ｐを作成する（Ｐ＝｛（Ｔｍ，Ｎｍ）｜Ｔノードの識別子＝Ｔｍ（ａｌｌ ｍ） ｉｎ ＩＤテーブル｝）。

ステップ２４６（Ｓ２４６）において、ＤＢ装置１２は、Ｓ２４４の処理により得られたＴノード識別子とＴノード名との組の集合Ｐが空集合であるか否かを判断する。
ＤＢ装置１２は、Ｔノード識別子とＴノード名との組の集合Ｐが空集合であるときには終了処理を行って検索処理を終了し、これ以外のときにはＳ２０２の処理に進む。
この集合Ｐは、図１５に示したＳ２０２の処理において、検索者への応答を作成するために用いられる。

［ＤＢプログラム２］
図１８は、図６，図７に示したＤＢ装置１２において実行されるＤＢプログラム２の構成を示す図である。
なお、図１８においては、図示の明確化のために、データの流れを示す線は、適宜、省略されている。
図１８に示すように、ＤＢプログラム２は、ＤＢ管理部２０、ＤＢ部２４およびＤＢ検索部２６から構成される。

ＤＢ管理部２０は、管理操作受入部２００、ＡＲエントリ作成部２０２、ＩＤエントリ作成部２０４、ＡＲデータベース管理部（ＡＲＤＢ管理部）２０６およびＩＤデータベース管理部（ＩＤＤＢ管理部）２０８から構成される。
ＤＢ部２４は、ＡＲデータベース（ＡＲＤＢ）２４０、Ｔノード用のＩＤデータベース（ＩＤＤＢ）２４２およびＡノード用のＩＤＤＢ２４４から構成される。
ＤＢ検索部２６は、検索操作受入部２６０、検索条件作成部２６２、検索制御部２６４、ＡＲデータベース検索部（ＡＲＤＢ検索部）２６６およびＩＤデータベース検索部（ＩＤＤＢ検索部）２６８から構成される。

ＤＢプログラム２は、例えば、記録媒体１３０（図７）を介してＤＢ装置１２に供給され、メモリ１２４にロードされ、ＤＢ装置１２で実行されるＯＳ上で、ＤＢ装置１２のハードウエアを具体的に利用して実行される（以下の各プログラムについて同様）。
ＤＢプログラム２は、これらの構成部分により、図９〜図１７を参照して説明したＡＲデータベース（図１１）およびＩＤデータベース（図１２，図１３）の作成、および、これらのデータベースを用いたデータの検索（図１４〜図１７）を行う。

ＤＢ部２４において、ＡＲＤＢ２４０は、図１１に示したＡＲテーブルを記憶する。
ＩＤＤＢ２４２は、図１２に示したＴノード用のＩＤテーブルを記憶する。
ＩＤＤＢ２４４は、図１３に示したＡノード用のＩＤテーブルを記憶する。
また、図１８には、図１２，図１３に示したＴノード用のＩＤテーブルおよびＡノード用のＩＤテーブルが、それぞれＩＤＤＢ２４２，２４４に記憶される場合が具体例とされているが、Ｔノード用のＩＤテーブルと、Ａノード用のＩＤテーブルとは、同じデータベースに記憶されてもよい。
また、Ｔノード用のＩＤテーブルと、Ａノード用のＩＤテーブルとは、必ずしも分けて作成されなくともよく、１つのデータベース内に一体に作成されてもよい。

ＤＢ管理部２０において、管理操作受入部２００は、ＡＲテーブルおよびＩＤテーブルに記憶されたデータを管理し、あるいは、変更するための操作を、入出力装置１２６（図７）から、あるいは、ネットワーク１００を介してＰＣ１０２（図６）から受け入れ、ＡＲＤＢ管理部２０６およびＩＤＤＢ管理部２０８に対して出力する。
また、管理操作受入部２００は、ＡノードおよびＴノード、ＡノードとＴノードとの関連付け、ＡノードとＴノードとの間（エッジ）に定義される関連性役割Ｒ、ＡノードおよびＴノードに付される識別子（ＩＤ）、Ｔノードに付されるノード名（Ｎ）、および、Ｔノードに定義される属性（図９）を指定するユーザの操作を受け入れ、ＡＲエントリ作成部２０２およびＩＤエントリ作成部２０４に対して出力する。
例えば、管理操作受入部２００は、Ａノード、Ｔノードおよびこれらの間の関係などを、図１４に示したように表示するユーザインターフェース（ＵＩ）画像を、入出力装置１２６に表示し、このＵＩ画像に対するユーザの操作を受け入れて、これらの指定を受け入れる。

ＡＲエントリ作成部２０２は、管理操作受入部２００から入力されるユーザの指定に従って、図１１に示したＡＲテーブルのエントリを作成し、ＡＲＤＢ管理部２０６に対して出力する。
ＡＲＤＢ管理部２０６は、ＡＲエントリ作成部２０２から入力されるＡＲテーブルのエントリを、ＡＲＤＢ２４０に記憶されているＡＲテーブルに追加する。
また、ＡＲＤＢ管理部２０６は、管理操作受入部２００から入力されるユーザの操作に従って、ＡＲＤＢ２４０に記憶されているＡＲテーブルの内容を変更する。

また、ＡＲＤＢ管理部２０６は、ＡＲＤＢ検索部２６６の検索に応じて、ＡＲＤＢ２４０に記憶されたＡＲテーブルのエントリを探しだし、ＡＲＤＢ検索部２６６に対して出力する。
ＩＤエントリ作成部２０４は、管理操作受入部２００から入力される検索者の指定に従って、図１２，図１３に示したＴノード用およびＡノード用のＩＤテーブルのエントリを作成し、ＩＤＤＢ管理部２０８に対して出力する。

ＩＤＤＢ管理部２０８は、ＩＤエントリ作成部２０４から入力されるＴノード用のＩＤテーブルのエントリを、ＩＤＤＢ２４２に記憶されているＴノード用のＩＤテーブルに追加する。
また、ＩＤＤＢ管理部２０８は、ＩＤエントリ作成部２０４から入力されるＡノード用のＩＤテーブルのエントリを、ＩＤＤＢ２４４に記憶されているＡノード用のＩＤテーブルに追加する。
また、ＩＤＤＢ管理部２０８は、管理操作受入部２００から入力されるユーザの操作に従って、ＩＤＤＢ２４２，２４４に記憶されているＩＤテーブルの内容を変更する。
また、ＩＤＤＢ管理部２０８は、ＩＤＤＢ検索部２６８の検索に応じて、ＩＤＤＢ２４２，２４４に記憶されたＩＤテーブルのエントリを探し出し、ＩＤＤＢ検索部２６８に対して出力する。

ＤＢ検索部２６において、検索操作受入部２６０は、図１４〜図１７に示した検索処理に用いられる検索条件（図１４、さらに任意のＴノードの属性（ノードタイプ（ＮＴ））が含まれることがある）を指定するための検索者の操作を、入出力装置１２６（図７）から、あるいは、ネットワーク１００を介してＰＣ１０２（図６）から受け入れる。
検索操作受入部２６０は、受け入れた操作を、検索条件作成部２６２に対して出力する。

検索条件作成部２６２は、例えば、検索操作受入部２６０が、自然言語による質問文の形式で検索条件を受け入れるときには、この質問文を構文解析して単語を取り出す。
次に、検索条件作成部２６２は、ＡＲＤＢ検索部２６６、ＩＤＤＢ検索部２６８、ＡＲＤＢ管理部２０６およびＩＤＤＢ管理部２０８を介してＡＲＤＢ２４０およびＩＤＤＢ２４２，２４４に記憶されたＡＲテーブルおよびＩＤテーブルを検索して、検索条件として用いられ得る単語を抽出する。
さらに、検索条件作成部２６２は、抽出された単語を、質問文の構造に沿って組み合わせ、図１４に示した形式の検索条件（Ｒｒｅｔ，（ＡＮＴ１，ＡＮＴ２，．．．），（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ）））を導出し、検索制御部２６４に対して出力する。

なお、検索者が、図１４に示した形式（Ｒｒｅｔ，（ＡＮＴ１，ＡＮＴ２，．．．），（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ）））で検索条件を、直接、指定するときには、検索条件作成部２６２は省略され得る。
また、検索条件作成部２６２は、検索者による検索条件（Ｒｒｅｔ，（ＡＮＴ１，ＡＮＴ２，．．．），（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ）））の導出を補助するためのツールであってもよい。

検索制御部２６４は、検索条件作成部２６２（検索操作受入部２６０）から入力される検索条件（Ｒｒｅｔ，（ＡＮＴ１，ＡＮＴ２，．．．），（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２），．．．，（Ｒｎ，Ｎｎ）））に従って、ＡＲＤＢ検索部２６６およびＩＤＤＢ検索部２６８を制御し、図１５〜図１７に示したように、ＡＲＤＢ管理部２０６およびＩＤＤＢ管理部２０８を介したＡＲＤＢ２４０（ＡＲテーブル；図１１）およびＩＤＤＢ２４２，２４４（ＩＤテーブル；図１２，図１３）の検索を行わせる。
また、検索制御部２６４は、検索条件に従った検索により検索結果（集合Ｐ；図１７）が得られたときには、この検索結果に基づいて応答を作成し、入出力装置１２６（図７）に表示し、あるいは、ネットワーク１００（図６）を介してＰＣ１０２の入出力装置１２６に表示し、検索者に示す。

ＡＲＤＢ検索部２６６は、検索制御部２６４の制御に従って、ＡＲＤＢ管理部２０６を介してＡＲＤＢ２４０（ＡＲテーブル；図１１）を検索し、検索結果を検索制御部２６４に返す。
ＩＤＤＢ検索部２６８は、検索制御部２６４の制御に従って、ＩＤＤＢ管理部２０８を介してＩＤＤＢ２４２，２４４（ＩＤテーブル；図１２，図１３）を検索し、検索結果を検索制御部２６４に返す。

［全体動作］
以下、図６，図７に示したＤＢ装置１２（ＤＢプログラム２；図１８）の全体的な動作を、具体例を挙げて説明する。

［ＡＲテーブルおよびＩＤテーブルの作成］
まず、ＤＢプログラム２のＤＢ管理部２０によるＡＲテーブルおよびＩＤテーブルの作成処理を説明する。
図１９は、図６，図７に示したＤＢ装置１２（ＤＢプログラム２；図１８）に対して入力されるデータと、これに含まれるデータの検索に含まれる検索条件とを例示する図である。
例えば、ＤＢプログラム２の管理操作受入部２００に対して、図１９に示すように関連付けられたデータが入力される。
図１９に示すデータには、以下のように関連付けられたＡノードとＴノードとが含まれ、Ｔノードにはそれぞれノード名が付されている（ただし、Ａノードの属性（ノードタイプ（ＮＴ））およびノード名、Ｔノードの属性（ノードタイプ（ＮＴ））は、以下の（１）〜（８）および図１９において省略）。

（１）「ＡノードＡ１」と「ＴノードＴ１１」とが関連付けられ、これらの間に「作者」という関連性役割Ｒが定義され、「ＴノードＴ１１」には、「シェークスピア（同名の別人）」というノード名が付されている。
（２）「ＡノードＡ９」と「ＴノードＴ９２，Ｔ４１」とが関連付けられ、これらの間に「作品」および「作者」という関連性役割Ｒが定義され、「ＴノードＴ９２，Ｔ４２」には、「ベニスの商人」および「シェークスピア」というノード名が付されている。
（３）「ＡノードＡ４」と「Ｔノード４１，Ｔ４２」とが関連付けられ、これらの間に「作者」および「作品」という関連性役割Ｒが定義され、「ＴノードＴ４２」には、「ハムレット」というノード名が付されている。
（４）「ＡノードＡ１３」と「ＴノードＴ４２」とが関連付けられ、これらの間に「脚本」という関連性役割Ｒが定義されている。
（５）「ＡノードＡ１９」と「ＴノードＴ４２」とが関連付けられ、これらの間に「原作」という関連性役割Ｒが定義されている。
（６）「ＡノードＡ１０」と「ＴノードＴ４２」とが関連付けられ、これらの間に「原作」という関連性役割Ｒが定義されている。
（７）「ＡノードＡ１０」と「ＴノードＴ１０３，Ｔ１０１」とが関連付けられ、これらの間に「出版」および「翻訳版」という関連性役割Ｒが定義され、「ＴノードＴ１０３」には、「○○出版」というノード名が付されている。
（８）「ＡノードＡ１９」と「ＴノードＴ１９１」とが関連付けられ、これらの間に「翻訳版」という関連性役割Ｒが定義されている。

管理操作受入部２００は、入力されたデータを受け入れ、ＡＲエントリ作成部２０２およびＩＤエントリ作成部２０４に対して出力する。
ＡＲエントリ作成部２０２は、図１９に示したデータから、ＡＲテーブルの各エントリを作成し、ＡＲＤＢ管理部２０６に対して出力する。

図２０は、ＡＲエントリ作成部２０２（図１８）およびＡＲＤＢ管理部２０６により作成され、ＡＲＤＢ２４０に記憶されるＡＲテーブルを例示する図である。
なお、以下の図において、ｎｕｌｌは、属性（ノードタイプ）・名称（ノード名）がないことを示す。
ＡＲＤＢ管理部２０６は、ＡＲエントリ作成部２０２から入力されたＡＲテーブルのエントリを、ＡＲＤＢ２４０に記憶されているＡＲテーブルに、順次、追加する。
ＡＲエントリ作成部２０２およびＡＲＤＢ管理部２０６による処理の結果、図１９に示したデータから、図２０に示すようなＡＲテーブルが作成され、ＡＲＤＢ２４０に記憶される。

図２１は、ＩＤエントリ作成部２０４（図１８）およびＩＤＤＢ管理部２０８により作成され、ＩＤＤＢ２４２に記憶されるＴノード用のＩＤテーブルを例示する図である。
ＩＤエントリ作成部２０４は、図１９に示したデータから、Ｔノード用のＩＤテーブルの各エントリを作成し、ＩＤＤＢ管理部２０８に対して出力する。
ＩＤＤＢ管理部２０８は、ＩＤエントリ作成部２０４から入力されたＴノード用のＩＤテーブルのエントリを、ＩＤＤＢ２４２に記憶されているＩＤテーブルに、順次、追加する。
ＩＤエントリ作成部２０４およびＩＤＤＢ管理部２０８による処理の結果、図１９に示したデータから、図２１に示すようなＴノード用のＩＤテーブルが作成され、ＩＤＤＢ２４２に記憶される。

図２２は、ＩＤエントリ作成部２０４（図１８）およびＩＤＤＢ管理部２０８により作成されるＡノードについてのＩＤテーブルを例示する図である。
また、ＩＤエントリ作成部２０４は、図１９に示したデータから、Ａノード用のＩＤテーブルの各エントリを作成し、ＩＤＤＢ管理部２０８に対して出力する。
ＩＤＤＢ管理部２０８は、ＩＤエントリ作成部２０４から入力されたＩＤテーブルのエントリを、ＩＤＤＢ２４４に記憶されているＡノード用のＩＤテーブルに、順次、追加する。
ＩＤエントリ作成部２０４およびＩＤＤＢ管理部２０８による処理の結果、図１９に示したデータから、図２２に示すようなＡノード用のＩＤテーブルが作成され、ＩＤＤＢ２４４に記憶される。

［データの検索］
例えば、検索者が、ＤＢ装置１２の入出力装置１２６（図７）に対して、「作家シェークスピアを作者とする作品のうち、戯曲ハムレットを原作とする翻訳版を出版している出版社名は？」と、検索条件を質問文の形式で入力すると、検索条件作成部２６２は、この質問文を分析し、図１９に示すように、この質問文を、前半部分と後半部分の２つに分割する。
検索条件作成部２６２は、質問文の前半部分「作家シェークスピアを作者とする作品のうち、」について、「作品」に関するデータを探すということから、検索結果とされるべきＴノードＴｒｅｔの関連性役割Ｒｒｅｔを「作品」とする。
また、検索条件作成部２６２は、前半部分の「シェークスピアを作者とする」の部分から、検索フィルタ（Ｒ１＝「作者」，Ｎ１＝「シェークスピア」）を作成する。
さらに、検索条件作成部２６２は、ＴノードＴｒｅｔの関連性役割（Ｒｒｅｔ＝「作品」）と、検索フィルタ（Ｒ１＝「作者」，Ｎ１＝「シェークスピア」）とから、質問文の前半に対応する検索条件（Ｒｒｅｔ，（ＡＮＴ１），（（Ｒ１，Ｎ１）））＝（作品，（ｎｕｌｌ），（（作者，シェークスピア）））を作成する。

また、検索条件作成部２６２は、後半部分「戯曲ハムレットを原作とする翻訳版を出版している出版社名は？」について、「出版している出版社」に関する情報を検索することから、検索結果とされるべきＴノードＴｒｅｔの関連性役割Ｒｒｅｔを「出版」とする。
また、検索条件作成部２６２は、後半部分に含まれる「ハムレット」を「原作」とするという条件から、第１の検索フィルタ（Ｒ１＝「原作」，Ｎ１＝「ハムレット」）を作成し、さらに、後半部分に含まれる「翻訳版」から、第２の検索フィルタ（Ｒ２＝「翻訳版」，Ｎ２＝「ｎｕｌｌ（指定なし）」）を作成する。
さらに、検索条件作成部２６２は、関連性役割（Ｒｒｅｔ＝「出版」）と、第１の検索フィルタ（Ｒ１＝「原作」，Ｎ１＝「ハムレット」）および第２の検索フィルタ（Ｒ２＝「翻訳版」，Ｎ２＝「ｎｕｌｌ」）とから、質問文の後半に対応する検索条件（Ｒｒｅｔ，（ＡＮＴ１），（（Ｒ１，Ｎ１），（Ｒ２，Ｎ２）））＝（出版，（ｎｕｌｌ），（（原作，ハムレット），（翻訳版，ｎｕｌｌ）））を作成する。

検索制御部２６４は、検索条件作成部２６２が作成した検索条件に基づいて、以下に示すように、ＡＲＤＢ検索部２６６およびＩＤＤＢ検索部２６８を介してＡＲＤＢ２４０（ＡＲテーブル；図２０）およびＩＤＤＢ２４２（Ｔノード用ＩＤテーブル；図２１）を検索し、検索結果を得る。
まず、質問文の前半部分から得られた検索条件から、
（１）検索制御部２６４は、ＩＤＤＢ２４２（図１８）に記憶されたＴノードのＩＤテーブルを参照し、ノード名が「シェークスピア」であるＴノードの識別子（ＩＤ）を全て探し出し、この処理の結果として、Ｔ１１，Ｔ３１，Ｔ４１，Ｔ５１，Ｔ８１（図２１）を得る。
（２）検索制御部２６４は、ＡＲＤＢ２４０に記憶されたＡＲテーブル（図２０）を参照し、役割が「作者」であり、Ｔノード識別子が（１）の処理により得られたＴノードの識別子と一致するＡノード識別子を全て探し出し、この処理の結果として、Ａ１，Ａ４，Ａ９を得る。
（３）検索制御部２６４は、ＡＲテーブルを参照し、（２）の処理により得られたＡノード識別子のうち、関連性役割Ｒが「作品」であるＡノードに対応するＴノードの識別子（ＩＤ；一般には複数個）を探し出し、この処理の結果として、Ｔ４２，Ｔ９２を得る。
（４）検索制御部２６４は、ＩＤテーブルを参照し、識別子が（３）の処理により得られたＴノード識別子に対応するノード名を、そのＴノードの識別子（ＩＤ）とともに、検索結果とする。
つまり、検索制御部２６４は、（１）〜（４）の処理により、質問文の前半部分から得られた検索条件（作品，（ｎｕｌｌ），（（作者, シェークスピア）））に基づく検索を行い、検索結果（Ｔ４２，ハムレット）,（Ｔ９２，ベニスの商人）を得る。
次に、質問文の後半部分から得られた検索条件、および、前半部分に対応する検索結果から、
（５）検索制御部２６４は、質問文の前半部分に対応する検索結果（Ｔ４２，ハムレット）,（Ｔ９２，ベニスの商人）の内、ノード名が、第１の検索フィルタ（原作，ハムレット）と対応する（Ｔ４２，ハムレット）を選択し、そのノード識別子（ＩＤ）Ｔ４２を得る
（６）検索制御部２６４は、ＡＲテーブルを参照し、役割が「原作」であり、Ｔノード識別子が、（５）の処理により得られたノード識別子（ＩＤ）と一致するＡノードの識別子を全て探し出し、この結果としてＡ１０，Ａ１９を得る。
（７）検索制御部２６４は、ＡＲテーブルを参照し、（６）の処理により得られたＡノード識別子のうち、役割が「翻訳版」であるものを全て探し出し、この結果として、Ａ１０，Ａ１９を得る。
（８）検索制御部２６４は、ＡＲテーブルを参照し、（７）の処理により得られたＡノード識別子のうち、役割が「出版」であるＡノードに対応するＴノード識別子を探し出し、この結果としてＴ１０３を得る（複数の出版社から翻訳版が出されている場合には、複数のＴノード識別子が得られる）。
（９）検索制御部２６４は、ＩＤテーブルを参照し、ノードＩＤが（８）で得られたＴノード識別子に対応するノード名を、そのノード識別子とともに、検索結果（Ｔ１０３，○○出版）とする。

つまり、検索制御部２６４は、（５）〜（９）の処理により、質問文の後半部分から得られた検索条件（出版，（ｎｕｌｌ），（（原作，ハムレット），（翻訳版，ｎｕｌｌ）））に基づく検索を行い、検索結果（Ｔ０１３，○○出版）を得る。
（１０）検索制御部２６４は、検索結果を、入出力装置１２６（図７）などに表示し、検索者に示す。

図２３は、第２のＤＢシステム３の構成を例示する図である。
図２３に示すように、第２のＤＢシステム３は、ＤＢ装置１２と、ＤＢ装置１２と同様なハードウエア（図７）上で、ＤＢプログラム２のＤＢ管理部２０およびＤＢ部２４を実行するＤＢ装置３０と、ＤＢ装置１２と同様なハードウエア上で、ＤＢプログラム２のＤＢ検索部２６を実行する検索装置３２とが、ネットワーク１００を介して接続されて構成される。
このように、ＤＢプログラム２は、必ずしも１つのコンピュータ上で実行されなくともよく、ネットワークを介して接続された複数のコンピュータに分散され、実行されてもよい。

［第３のＤＢシステム４］
以下、ディレクトリ構造により関連情報を記憶し、検索の対象とするように構成された本発明にかかる第３のＤＢシステム４を説明する。
図２４は、本発明にかかる第３のＤＢシステム４の構成を例示する図である。
図２４に示すように、ＤＢシステム４は、ＰＣ１０２、検索装置４０、ＤＢ管理装置５およびｎ台のＤＢ装置６−１〜６−ｎが、ネットワーク１００を介して接続されて構成される。

なお、以下、ＤＢ装置６−１〜６−ｎなど、複数ある構成部分のいずれかを特定せずに記載するときには、単にＤＢ装置６と記載することがある。
また、検索装置４０、ＤＢ管理装置５およびＤＢ装置６のハードウエアは、図７に示したような構成を採る。
また、図６に示した第１のＤＢシステム１におけるＤＢ装置１２（図６）およびそのＤＢプログラム２（図１８）のように、ＤＢ装置６が検索機能を含むときには、検索装置４０は不要とされることがある。
また、ＤＢシステム４においては、ＤＢ装置６それぞれに対する複製装置（ミラーサーバ；ＤＢ装置６’）が設けられることがある。
また、以下、ＤＢ装置６−１〜６−ｎを、それぞれＤＢ装置Ａ〜Ｎと記すことがある。

次に、図２４に示したＤＢシステム４における情報の表現を説明する。
図２５は、図２４に示したＤＢシステム４に記憶される情報のグラフ形式の表現を例示する図である。
図２６は、図２５に示した情報のディレクトリ情報ツリー形式の表現を例示する図である。
図８を参照して既に説明したように、ＡノードおよびＴノードそれぞれに対してノード名（Ａノードのノード名などが「関連ノードに対応する情報」であり、Ｔノードのノード名などが「見出ノードに対応する情報」である）などが定義され、ＡノードとＴノードとの間に関連性役割が定義されると、これらのノードにより関連付けられる関連情報は、グラフ形式で、図２５に例示するように表現されうる。

なお、図２５には、ＴノードおよびＡノードのノードタイプ（クラス）を定義するノード（Ｔ１，Ｔ３−１，Ｔ３−２）それぞれに、ノード名として「ロケーション情報」・「店」・「エリア」が定義され、Ｔノード（Ｔ２−１，Ｔ２−２）それぞれに、ノード名として「店１」・「エリア３」が定義され、Ａノード（Ａ１）に、ノード名として「ロケーション」が定義され、ＴノードとＡノートとの間それぞれに、関連性役割として、「建物」・「地域」が定義された場合が示されている。
また、ＡノードＡ２−１，Ａ２−２は、ノードタイプ(クラス)を定義するノードと、そのインスタンス（実体に対応するノード）であるノードとの関連を示すので、これらのノードＡ２−１，Ａ２−２は、利用者が目的に応じて独自に定義した役割ではなく、システムにより事前に定義された「クラス」、「インスタンス」という２つの役割によりＴノードを関連付けるという意味で、特別なノードである。

図２５に示したようにグラフ形式で表現された関連情報は、図２６に示すように、ＬＤＡＰ(Lightweight Directory Access Protocol)の情報モデルであるＤＩＴ(Directory Information Tree；ディレクトリ情報ツリー)形式によって表現されうる。
つまり、図２５に示した関連情報は、ＤＩＴ形式に従って、図２６に点線で示すように、ＤＢ装置６それぞれの最上位のエントリとして仮想的に設けられる仮想ルートエントリ、および、第１，第２・・・の関係（関係＃１，＃２・・・）を示すエントリの下に設けられ、図２６に実線で示すように、Ａノードに対応するエントリ、および関連性役割に対応し、Ｔノードの情報を属性としてもつエントリにより表現されうる。
つまり、図２６に例示した場合においは、ノードタイプ（assocType）が「ロケーション情報」である関連情報を示すエントリ「ロケーション」の直下に、２つの役割（role）「建物」と「地域」に対応するエントリが設けられ、それぞれの役割を果たすメンバ（member）「店１」と「エリア３」は対応するエントリの属性となっている。
図２５に示したようにグラフ形式で表現された関連情報は、図２６に示すように、ＬＤＡＰ(Lightweight Directory Access Protocol)の情報モデルであるＤＩＴ(Directory Information Tree；ディレクトリ情報ツリー)形式によって表現されうる。

なお、図２６に示したＤＩＴ形式において、『ディレクトリ』は、実世界の様々な事物に関する情報を、できる限り実世界での関係に即したわかりやすい形で構成し、また、情報の在り処を持っていて、それらの情報の検索や更新の手段を提供するものとして定義される。
また、『エントリ』は、実世界のオブジェクトに関する情報を、オブジェクトクラスに従って整理・分類し、ディレクトリ情報として表現したものとして定義され、あるいは、ディレクトリに格納したデータと定義される。
また、『ディレクトリ情報ツリー』は、エントリ（ディレクトリ情報）を、階層的に管理する際、その階層関係をツリー構造に表現したものとして定義される。
つまり、図２６の各四角はエントリに対応し、これらの階層関係をツリー構造に表現したものがディレクトリ情報ツリー（ＤＩＴ）である。

なお、上述したように、エントリはオブジェクトに関する情報の集まりであって、このオブジェクトに関する情報は『属性』と呼ばれる。
この属性は『属性型』と、１つ以上の値、『属性値（群）』からなり、図２６においては、各エントリの構造が、『属性型：属性値』の形式で、下表２１〜表２３に示すように、ＬＤＡＰにおける各エントリの構造表現として例示されている。
例えば、「ｏｕ＝関係＃１」直下のエントリでは、属性型ｏｂｊｅｃｔｃｌａｓｓ（オブジェクトクラス）の属性値が 関連ノード、属性型ｃｎ（一般名）の属性値がロケーション、・・・というように、エントリの各属性が定義される。

図２７は、ディレクトリ構造で表現された関連情報の分割方法を例示する図である。
図２８は、図２７に示したＤＢ装置６−１（Ａ）のエントリｄｎ＿Ａ２と、ＤＢ装置６−ｎ（Ｎ）のエントリｄｎ＿Ｎとの参照関係を示す図である。
図２７に示すように、ＤＩＴ形式により表現された関連情報は、ディレクトリ構造に従って分割されうる。

図２７に示す場合においては、関連情報は、エントリｄｎ＿Ａおよびその下位のエントリｄｎ＿Ａ１，ｄｎ＿Ａ２を含むディレクトリ構造により表現されており、さらに、エントリｄｎ＿Ａ１以下のディレクトリに対応する関連情報は、エントリｄｎ＿Ｂ〜ｄｎ＿（Ｎ−１）に対応して分割され、エントリｄｎ＿Ａ２以下のディレクトリに対応する関連情報は、エントリｄｎ＿Ｎ以下のディレクトリ構造に対応付けられている（なお、図２７に示した例においては、エントリｄｎ＿Ｂ〜ｄｎ＿Ｎを最上位エントリとするディレクトリ構造がサブツリーであり、これらのサブツリー全てを含み、エントリｄｎ＿Ａを最上位エントリとするディレクトリ構造がディレクトリツリーである）。
例えば、図２８に示すように、図２７に示したＤＢ装置６−ｎ（Ｎ）の最上位エントリｄｎ＿Ｎは、ＤＢ装置６−１（Ａ）のエントリｄｎ＿Ａ２の下位にあって、これを参照する。
このように、ディレクトリ構造に従って分割された関連情報は、図２７に示すように、ＤＢ装置６−１〜６−ｎに、分割されて記憶されうる。

図２９は、図２７に示したようにＤＢ装置６−１〜６−ｎ（ＤＢ装置Ａ〜Ｎ）に分割されて記憶された関連情報を管理するために用いられるディレクトリツリーテーブルを例示する図である。
図２７，図２８に示したように分割されてＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）に記憶された関連情報を管理するためには、図２９に示すようなディレクトリツリーテーブルが用いられる。
図２９に示すように、ディレクトリツリーテーブルには、ＤＢ装置６−１〜６−ｎそれぞれの装置名（Ａ〜Ｎ）と、これらのＤＢ装置６それぞれにおける最上位エントリ（ｄｎ＿Ａ〜ｄｎ＿Ｎ；仮想ルートエントリ（図２６）に同じ）と、ＤＢ装置６それぞれの最上位エントリが参照するエントリ（上位参照エントリ）と、各ＤＢ装置６に複製装置（ミラーサーバ（第２のデータベース装置））があるときのその装置名（Ａ'，Ｃ'など）とが、対応付けられて含まれる。

図３０は、図２７，図２８に示したＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）に記憶されているディレクトリツリー（またはサブツリー）それぞれの最上位エントリｄｎ＿Ａ〜ｄｎ＿Ｎと、ディレクトリツリー（またはサブツリー）それぞれに記憶されている関連情報の分類に用いられる分類型・分類値（分類情報）とを対応付ける情報テーブルを例示する図である。
図２５，図２６に示したように、ＤＩＴ形式のディレクトリ構造で表現され、このディレクトリ構造に従って分割され、ＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）それぞれに記憶された関連情報それぞれは、ＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）それぞれにおいて関連性を有する情報の集合としてとらえられる。

従って、図２７，図２８に示したＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）に記憶されているディレクトリツリー（またはサブツリー）それぞれに対して、そこに記憶されている関連情報の分類に用いるための属性などを示す分類型および分類値を定義することができる。
ＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）それぞれに記憶された関連情報の管理のためには、図３０に示すように、図２７，図２８に示したＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）の最上位エントリｄｎ＿Ａ〜ｄｎ＿Ｎの下のサブツリーａ〜ｎそれぞれと、最上位エントリ（ｄｎ＿Ａ〜ｄｎ＿Ｎ）それぞれと、これらの最上位エントリ以下のサブツリーに対して定義される分類型および分類値それぞれとが対応付けて含まれる情報テーブルが用いられる。

なお、図３０に示した「分類型」は、関連タイプ（Ａノードのノードタイプ（図２２）；属性）に対応する。
また、「分類値」は、ＬＤＡＰ情報モデルにおけるインスタンスに対応する。
図２７〜図３０に示した最上位エントリとなり得るエントリとして、
（１）ある分類型（関連タイプ；Ａノードのノードタイプ）の特定の分類値（インスタンス）を含むサブツリーのルートエントリ、および、
（２）ある特定の分類値（インスタンス）が含まれる関連情報を含むサブツリーのルートエントリ
などを、具体例として挙げることができる。

ただし、ここには、「分類型」が関連タイプに対応し、「分類値」がそのインスタンスに対応する場合が例示されているが、これは、図３０を図２７，図２８に対応付けた一例であって、「分類型」は、関連タイプに対応しないことがあり、また、「分類値」は、そのインスタンスに対応しないことがある。
例えば、図３０に示されたサブツリーａには、「分類型：カテゴリ、分類値：提携会社情報」の関連情報が含まれ、これらは、「分類型」が関連タイプに対応せず、「分類値」がそのインスタンスに対応しない例である。

また、例えば、図３０に示した情報テーブル中の最上位エントリｄｎ＿Ｂを含むエントリの分類型として示された「位置情報」は、上記（１）「ある分類型（関連タイプ；Ａノードのノードタイプ）の特定の分類値（インスタンス）を含むサブツリーのルートエントリ」の分類型の一例であり、その分類値の１つとして分類値「ロケーション(located-in)」を含む。
このエントリは、分類値として「ロケーション(located-in)」を有する全ての関連情報が、ＤＢ装置６−２（Ｂ）に記憶されることを示している。
分類型「位置情報」の分類値のその他の例として、分類値「隣接(next-to)」などを挙げることができる。

あるいは、図３０に示した最上位エントリｄｎ＿（Ｎ−１）を含むエントリの分類型として示された「建物」は、上記（２）「ある特定の分類値（インスタンス）が含まれる関連情報を含むサブツリーのルートエントリ」の分類型の一例であり、その分類値の１つとして分類値「店１」を含む。
このエントリは、分類値として「店１(Store_1)」を有する全ての関連情報が、ＤＢ装置６−（ｎ−１）（Ｎ−１）に記憶されることを示している。

［関連情報の作成および検索］
以下、図２５〜図３０を参照して説明したＤＩＴ形式のディレクトリ構造により表現された関連情報の作成、および、作成された関連情報に対する検索を説明する。

［第１のＤＢ管理プログラム５０］
図３１は、図２４に示したＤＢ管理装置５において動作する第１のＤＢ管理プログラム５０の構成を示す図である。
図３１に示すように、ＤＢ管理プログラム５０は、ユーザインターフェース（ＵＩ）部５００、情報登録部５０２、情報送信部５０４、関連情報作成・管理部５１０（ディレクトリツリー作成手段および情報対応付手段）、ツリー情報提供部５１２、ディレクトリツリーテーブル作成部５２２（最上位エントリ対応付手段）、ディレクトリツリーテーブル管理部５２４、ディレクトリツリーテーブルＤＢ５２６、情報テーブル作成部５３２（分類情報対応付手段）、情報テーブル管理部５３４および情報テーブルＤＢ５３６から構成される。

ＤＢ管理プログラム５０は、これらの構成部分により、図２５〜図２６に示したように、ＤＩＴ形式のディレクトリ構造で表現された関連情報を作成する。
また、ＤＢ管理プログラム５０は、図２７，図２８に示したように、作成した関連情報を分割してＤＢ装置６−１〜６−ｎに記憶させ、図２９，図３０に示したディレクトリツリーテーブルおよび情報テーブルを用いて関連情報を管理する。
また、ＤＢ管理プログラム５０は、検索装置４０（図２４）に対して、ディレクトリツリーテーブルおよび情報テーブルの情報に含まれ、検索のために必要とされる情報（ツリー情報）を、適宜、提供する。

図３２は、図３１に示したＤＢ管理プログラム５０が、ＤＢ管理装置５の入出力装置１２６（図７）に表示するＧＵＩ画像を例示する図である。
ＤＢ管理プログラム５０において、ＵＩ部５００は、ＤＢ管理装置５あるいはＰＣ１０２のユーザのためにＧＵＩ環境を提供し、入出力装置１２６（図７）などに対して、図３２に示すようなＧＵＩ画像を表示する。
さらに、ＵＩ部５００は、表示されたＧＵＩ画像に対してユーザが行った関連情報の登録、管理および変更のための操作を受け入れ、情報登録部５０２および関連情報作成・管理部５１０など、ＤＢ管理プログラム５０の各構成部分に対して出力し、これらの動作を制御する。
また、ＵＩ部５００は、ＤＢ管理プログラム５０の各構成部分が作成した情報を、入出力装置１２６に対して表示・出力する。
なお、ＵＩ部５００は、ＤＢ管理装置５におかれても、ＰＣ１０２におかれてもよく、ＰＣ１０２において、上記機能をユーザに対して提供してもよい。

関連情報作成・管理部５１０は、ディレクトリツリーテーブル作成部５２２および情報テーブル作成部５３２などの動作を制御して、ＵＩ部５００から入力されるＴノード、Ａノードおよび関連属性を示す情報から、図２６に示したように、ＤＩＴ形式のディレクトリ構成により表現される関連情報を作成し、作成した関連情報を、図２９，図３０に示したディレクトリツリーテーブルおよび情報テーブルを用いて管理する。
また、関連情報作成・管理部５１０は、要求に応じて、ディレクトリツリーテーブルおよび情報テーブルに含まれ、検索装置４０による検索のために用いられる情報（ツリー情報）を、ツリー情報提供部５１２に対して出力する。
また、関連情報作成・管理部５１０は、ユーザの操作などに従って、図２７，図２８に示したように、ＤＩＴ形式のディレクトリ構造に表現された関連情報を分割し、情報登録部５０２に対して出力する。

情報登録部５０２は、関連情報作成・管理部５１０から入力される関連情報を、情報送信部５０４を介して、ＤＢ装置６−１〜６−ｎそれぞれに対して送信し、登録を要求する。
ツリー情報提供部５１２は、検索装置４０からの要求に応じて、関連情報作成・管理部５１０から入力されるツリー情報を提供する。

ディレクトリツリーテーブル作成部５２２は、関連情報作成・管理部５１０の制御に従って、図２９に示したディレクトリツリーテーブルを作成し、ディレクトリツリーテーブル管理部５２４に対して出力する。
ディレクトリツリーテーブル管理部５２４は、ディレクトリツリーテーブル作成部５２２から入力されたディレクトリツリーテーブルを、ディレクトリツリーテーブルＤＢ５２６に記憶させる。
また、ディレクトリツリーテーブルＤＢ５２６は、要求に応じて、ディレクトリツリーテーブルＤＢ５２６に記憶させたディレクトリツリーテーブルを、関連情報作成・管理部５１０に対して出力する。
なお、図１８に示したＤＢプログラム２においては、ＤＢ管理部２０が、関連情報からＡＲテーブルおよびＩＤテーブルを作成する処理を行うのに対し、図３１に示したＤＢ管理プログラム５０においては、関連情報作成・管理部５１０が、ディレクトリ構造の関連情報（図２１，図２２）を作成し、ＤＢ装置６が、関連情報作成・管理部５１０および情報送信部５０４を介して、作成されたディレクトリ構造の関連情報を受け取り、記憶・管理する。

情報テーブル作成部５３２は、関連情報作成・管理部５１０の制御に従って、図３０に示した情報テーブルを作成し、情報テーブル管理部５３４に対して出力する。
情報テーブル管理部５３４は、情報テーブル作成部５３２から入力された情報テーブルを、情報テーブルＤＢ５３６に記憶させる。
また、情報テーブル管理部５３４は、要求に応じて、情報テーブルＤＢ５３６に記憶させた情報テーブルを、関連情報作成・管理部５１０に対して出力する。

以下、ＤＢ管理プログラム５０の全体的な処理を説明する。
図３３は、図３１に示したＤＢ管理プログラム５０による関連情報の登録処理（Ｓ３０）を示すフローチャートである。
図３３に示すように、ステップ３００（Ｓ３００）において、ＤＢ管理プログラム５またはＰＣ１０２のＵＩ部５００は、入出力装置１２６に、図３２に例示したＧＵＩ画像を表示する。
ユーザは、表示されたＧＵＩ画像に対して操作を行い、新たに追加する関連情報に関する情報（データ）を各フィールドに入力する。

ステップ３０２（Ｓ３０２）において、関連情報作成・管理部５１０は、Ｓ３００の処理において入力した関連情報に基づき、関連性（テーマ；例えば「シェークスピア作品」など）を同定する。
ステップ３０４（Ｓ３０４）において、関連情報作成・管理部５１０は、関連情報のノードタイプ（分類型；例えば「著作情報」）を同定し、これをエントリの属性として設定する。
ステップ３０６（Ｓ３０６）において、関連情報作成・管理部５１０は、情報テーブル管理部５３４を介して、情報テーブルを参照し、設定されたテーマおよびノードタイプにより、作成されるエントリが、いずれのサブツリーに分類されるかを特定する。

ステップ３１０（Ｓ３１０）において、関連情報作成・管理部５１０は、ディレクトリツリーテーブル管理部５２４を介して、ディレクトリツリーテーブルを参照し、Ｓ３０６の処理により求められたサブツリーが、いずれのＤＢ装置６に記憶されているかを特定する。
ステップ３１２（Ｓ３１２）において、関連情報作成・管理部５１０は、ＵＩ部５００を介して入力された関連情報に関するデータに基づき、それに対応するエントリを作成する。

ステップ３１４（Ｓ３１４）において、関連情報作成・管理部５１０は、情報登録部５０２および情報送信部５０４を介して、Ｓ３１０の処理により特定されたＤＢ装置６に、追加された関連情報のエントリを送信する。ＤＢ装置６は、受信した関連情報のエントリが既に記憶されているか否かを判断する。
なお、関連情報作成・管理部５１０は、ＤＢ装置６に記憶する際の前処理として、ＤＢ装置６内の情報を利用する。
この情報には、各エントリｄｎ（distinguished name：識別名）が割り当てられており、この識別名により、ＤＩＴ内の全てのエントリが一意に識別され得るので、同一のエントリの存在の有無が判断されうる。
ＤＢ管理プログラム５０は、追加された関連情報のエントリが既に存在するとの結果をＤＢ装置６から受信したときには処理を終了し、これ以外のときにはＳ３１６の処理に進む。
ステップ３１６（Ｓ３１６）において、関連情報作成・管理部５１０は、追加された関連情報のエントリを、特定されたＤＢ装置６に対して登録する。

図３４は、図３１に示したＤＢ管理プログラム５０による情報テーブル（図３０）の変更処理（Ｓ３４）を示すフローチャートである。
ステップ３４０（Ｓ３４０）において、ユーザは、ＤＢ管理装置５（図２４）またはＰＣ１０２に対して、変更しようとするサブツリーを指定する操作を行い、さらに、指定したサブツリーの分類型・分類値を設定する操作を行う。
関連情報作成・管理部５１０は、ＵＩ部５００を介してこれらの操作を受け入れる。
ステップ３４２（Ｓ３４２）において、ユーザは、ＤＢ管理装置５（図２４）またはＰＣ１０２に対して、指定したサブツリーの最上位エントリを設定する操作を行う。
関連情報作成・管理部５１０は、ＵＩ部５００を介して、この操作を受け入れる。

ステップ３４４（Ｓ３４４）において、関連情報作成・管理部５１０は、Ｓ３４０，Ｓ３４２の処理により受け入れた操作が示す分類型、分類値および最上位エントリの全てが、指定されたサブツリーに対して設定されているか否かを判断する。
関連情報作成・管理部５１０は、情報テーブル管理部５３４を介して情報テーブルを読み出し、これらの全てが指定されたサブツリーに対して設定されているときには処理を終了し、これ以外のときにはＳ３４６の処理に進む。

ステップ３４６（Ｓ３４６）において、関連情報作成・管理部５１０は、受け入れた設定値（指定されたサブツリー、分類型、分類値および最上位エントリ）を、情報テーブル管理部５３４に対して出力する。
情報テーブル管理部５３４は、関連情報作成・管理部５１０から入力された設定値を、情報テーブルに設定し、情報テーブルＤＢ５３６に記憶する。

図３５は、図３１に示したＤＢ管理プログラム５０によるディレクトリツリーテーブルの変更処理（Ｓ３６）を示すフローチャートである。
図３５に示すように、ステップ３６０（Ｓ３６０）において、ＵＩ部５００は、ＤＢ管理装置５から、ユーザによるディレクトリ情報ツリー分割のための操作を受ける。
ステップ３６２（Ｓ３６２）において、関連情報作成・管理部５１０は、ディレクトリツリーテーブル管理部５２４からディレクトリツリーテーブル（図２９）を得て、ＤＢ装置６の配置およびそのディレクトリ構造を示す情報を取得し、ユーザに対して表示する。

ステップ３６４（Ｓ３６４）において、ＵＩ部５００は、表示したディレクトリ構造に対するユーザの操作に応じて、分割後のサブツリーの最上位エントリおよびその上位参照エントリの設定を受ける。
ステップ３６６（Ｓ３６６）において、関連情報作成・管理部５１０は、ユーザによるディレクトリ情報ツリー分割のための操作に基づき、分割されたサブツリーが記憶されるＤＢ装置６に、複製装置を設定するか否かを判断する。
ＤＢ管理プログラム５０は、複製装置を設定するときにはＳ３６８の処理に進み、これ以外のときにはＳ３７０の処理に進む。

ステップ３６８（Ｓ３６８）において、関連情報作成・管理部５１０は、Ｓ３６６の処理において複製装置を設定すると判断されたとき、その複製装置を特定する。
ステップ３７０（Ｓ３７０）において、関連情報作成・管理部５１０は、分割後のサブツリーの最上位エントリとその上位参照エントリおよび複製装置を設定するときにはその複製装置名を、ディレクトリツリーテーブル管理部５２４に対して出力する。
ディレクトリツリーテーブル管理部５２４は、関連情報作成・管理部５１０から入力されたこれらの情報を、ディレクトリツリーテーブルＤＢ５２６の所定の部分に書き込みに反映させる。

ステップ３７２（Ｓ３７２）において、関連情報作成・管理部５１０は、全てのＤＢ装置６についてのディレクトリツリーテーブルの変更処理が終了したか否かを判断する。
ＤＢ管理プログラム５０は、全てのＤＢ装置６についての変更処理が終了していないときにはＳ３６４の処理に戻る。

次に、ＤＢ管理装置５の全体的な処理を説明する。
図３６は、図３１に示したＤＢ管理プログラム５０の全体的な動作（Ｓ４０）を示すシーケンス図である。
図３６に示すように、ステップ４００（Ｓ４００）ユーザは、ＤＢ管理プログラム５０のＵＩ部５００に対して、関連情報を入力する。
ステップ４０２（Ｓ４０２）において、ＵＩ部５００は、入力された関連情報に関する情報（データ）を、関連情報作成・管理部５１０に対して出力する。
関連情報作成・管理部５１０は、これらの情報を受け入れる。

ステップ４０４（Ｓ４０４）において、関連情報作成・管理部５１０は、受け入れた関連情報に関する情報のうち、テーマおよびノードタイプなど関連情報の分類に用いられる分類情報（分類型・分類値）を、情報テーブル管理部５３４に対して出力する。
ステップ４０６（Ｓ４０６）において、情報テーブル管理部５３４は、関連情報作成・管理部５１０からの関連情報の分類に用いられる情報を受け入れ、これらに対応するサブツリーの最上位エントリを、関連情報作成・管理部５１０に返す。
関連情報作成・管理部５１０は、このサブツリー最上位エントリを受け入れる。
なお、これらに対応するサブツリーがない場合には、対応するサブツリー最上位エントリの代わりに、ＤＢ装置６−１の最上位エントリ（すなわち、ルートエントリ）を関連情報作成・管理部５１０に返す。

Ｓ４０６の処理においては、情報テーブル（図３０）に格納されている分類型・分類値に対応する情報が用いられ、図３２に示したＧＵＩ画像を介して入力される関連情報に関するデータは、全て、関連情報作成・管理部５１０で利用可能である。
つまり、関連情報作成・管理部５１０が、ノードタイプと特定のインスタンスとを組にして情報テーブル管理部５３４に対して与えることにより、情報テーブル管理部５３４は、関連情報の分類に用いられる情報に対応するサブツリーの最上位エントリを得ることができ、他には、例えば、「カテゴリ」が分類型として、「シェークスピア作品」が分類値として、情報テーブル管理部５３４に与えられ得る。

ステップ４０８（Ｓ４０８）において、関連情報作成・管理部５１０は、ディレクトリツリーテーブル管理部５２４に対して、Ｓ４０６の処理により得られたサブツリー最上位エントリを出力する。
ディレクトリツリーテーブル管理部５２４は、このサブツリー最上位エントリを受け入れる。
ステップ４１０（Ｓ４１０）において、ディレクトリツリーテーブル管理部５２４は、受け入れたサブツリー最上位エントリを用いてディレクトリツリーテーブルＤＢ５２６を検索し、このサブツリーを記憶するＤＢ装置６を特定する。特定されたＤＢ装置６を示す情報を、関連情報作成・管理部５１０に返す。

ステップ４１２（Ｓ４１２）において、関連情報作成・管理部５１０は、ＤＩＴ形式とした関連情報と、特定されたＤＢ装置６を示す情報とを情報登録部５０２に対して出力する。
情報登録部５０２は、入力された関連情報を、特定されたＤＢ装置６に対して転送し、登録する。
ステップ４１６〜４２２（Ｓ４１６〜Ｓ４２２）において、情報登録部５０２からＵＩ部５００に対して、登録の結果（正常終了または異常終了）が通知され、ユーザに対して表示される。

［第２のＤＢプログラム６０］
図３７は、図２４に示したＤＢ装置６それぞれにおいて動作する第２のＤＢプログラム６０を示す図である。
図３７に示すように、ＤＢプログラム６０は、情報管理部６００、情報ＤＢ６０２、情報通信部６０４および検索実行部６０６から構成される。
ＤＢプログラム６０は、これらの構成部分により、ＤＢ管理装置５（ＤＢ管理プログラム５０；図３１）から、ＤＩＴ形式のディレクトリ構造で表現され、適宜、分割された関連情報の登録を受け、記憶する。
また、ＤＢプログラム６０は、検索装置４０からの検索に応じて、登録された関連情報を提供する。
また、ＤＢプログラム６０は、ＤＢ管理装置５からの制御に従って、登録された関連情報の変更を行う。

ＤＢプログラム６０において、情報通信部６０４は、ＤＢ管理装置５による関連情報およびその登録要求、および、関連情報の変更要求を受け入れ、情報管理部６００に対して出力する。
検索実行部６０６は、検索装置４０からの検索条件（図３８に示して後述する検索プログラム４２の検索条件作成部４２０により作成されるＬＤＡＰ操作、および、図５０に示すＬＤＡＰ操作）に従って、情報管理部６００に対して、関連情報の検索を行う。
また、検索実行部６０６は、検索の結果として情報管理部６００から入力される関連情報を、検索を要求した検索装置４０に対して返す。

情報管理部６００は、ＤＢ管理装置５からの登録要求および変更要求に従って、ＤＢ管理装置５または他のＤＢ装置６から送られてきた関連情報（図２６〜図２８）を、情報ＤＢ６０２に記憶させる。
また、情報管理部６００は、検索装置４０による検索に応じて、情報ＤＢ６０２から関連情報を読み出して、検索実行部６０６に対して出力する。

［第１の検索プログラム４２］
図３８は、図２４に示した検索装置４０において動作する検索プログラム４２を示す図である。
図３８に示すように、検索プログラム４２は、図１８に示したＤＢ検索部２６に、検索条件作成部４２０および検索結果出力部４２２を付加した構成をとる。
検索プログラム４２は、これらの構成部分により、検索者（ユーザ）の検索操作に従って、ＤＢ装置６に対する検索処理を行い、検索の結果として得られた関連情報を検索者に示す。

検索プログラム４２において、検索操作受入部２６０は、検索装置４０の入出力装置１２６（図７）などに対して、検索者が入力した検索操作を受け入れ、検索条件作成部４２０に対して出力する。
検索条件作成部４２０（ディレクトリツリー検索手段）は、検索操作受入部２６０から入力された検索操作の内容を解析し、さらに、この検索操作の内容に適合したツリー情報（ディレクトリツリーテーブルおよび情報テーブル（図２９，図３０）の内、検索に必要とされる情報）を、ＤＢ管理装置５から得て、検索操作およびツリー情報に適合した検索条件を作成し、検索制御部２６４に対して出力する。

具体的には、検索条件作成部４２０は、検索操作の内容を解析して得られる、関連情報の分類型および分類値に従って、ＤＢ管理装置５からの情報テーブル（図３０）を受けてその内容を検索し、検索操作の内容に適合した関連情報の最上位エントリを求める（但し、このような最上位エントリがない場合には、検索条件作成部４２０は、ＤＢ装置６−１の最上位エントリｄｎ＿Ａを、検索操作の内容に適合した関連情報の最上位エントリとする）。
さらに、検索条件作成部４２０は、ＤＢ管理装置５から受けたディレクトリツリーテーブル（図２９）の内容を検索し、情報テーブルの検索により求められた最上位エントリを記憶するＤＢ装置６を特定する。
さらに、検索条件作成部４２０は、検索操作の内容、および、情報テーブルから得られる関連情報の分類に用いる属性（分類型・分類値）を用いて、ＤＢ装置６に実行させるべきＬＤＡＰ操作のコマンドおよびパラメータを作成し、検索条件として、検索制御部２６４に対して出力する。

検索制御部２６４（情報検索手段）は、検索条件作成部４２０から入力される検索条件をＤＢ装置６に対して出力し、関連情報の検索の制御を行う。
検索結果出力部４２２は、検索の結果としてＤＢ装置６から返された関連情報を、検索装置４０の入出力装置１２６（図７）などに対して表示・出力し、検索者に示す。

以下、検索プログラム４２の全体的な処理を説明する。
図３９は、図３８に示した検索プログラム４２による検索処理（Ｓ４４）を示すフローチャートである。
図３９に示すように、ステップ４４０（Ｓ４４０）において、検索操作受入部２６０は、ユーザによる検索条件を受け入れる。

ステップ４４２（Ｓ４４２）において、検索操作受入部２６０は、検索要求メッセージ（図５０を参照して後述）を作成し、検索条件作成部４２０に対して出力する。
ステップ４４４（Ｓ４４４）において、検索条件作成部４２０は、検索要求メッセージ中に、分類型および分類値の指定があるか否かを判断する。
検索条件作成部４２０は、分類型および分類値の指定があるときにはＳ４４６の処理に進み、これ以外のときにはＳ４５４の処理に進む。

ステップ４４６（Ｓ４４６）において、検索条件作成部４２０は、ＤＢ管理装置５に対して分類型および分類値を送り、これらに対応するサブツリーの最上位エントリを特定する。
ステップ４４８（Ｓ４４８）において、検索条件作成部４２０は、Ｓ４４６の処理により、サブツリーが特定されたか否かを判断する。
検索プログラム４２は、サブツリーが特定されたときにはＳ４５０の処理に進み、これ以外のときにはＳ４５４の処理に進む。

ステップ４５０（Ｓ４５０）において、検索条件作成部４２０は、ＤＢ管理装置５に対して特定された最上位エントリを送り、この最上位エントリに対応するサブツリーを記憶するＤＢ装置６を特定する。
ステップ４５２（Ｓ４５２）において、検索条件作成部４２０は、特定されたサブツリーの最上位エントリを、検索を開始するエントリ（検索ベース）とする。
ステップ４５４（Ｓ４５４）において、検索条件作成部４２０は、ＤＢ管理装置５からディレクトリツリーテーブルを受け、受けたディレクトリツリーテーブルを参照し、全てのＤＢ装置６に記憶されているサブツリーを通して、最も上位のエントリ（ルートエントリ）を検索ベースとし、このエントリを記憶するＤＢ装置６を特定する。

ステップ４５６（Ｓ４５６）において、検索制御部２６４は、検索条件作成部４２０から、検索要求および検索ベースなどの情報を得て、特定されたＤＢ装置６に対するＬＤＡＰ操作コマンドを作成する。
ステップ４５８（Ｓ４５８）において、検索制御部２６４は、作成したＬＤＡＰ操作コマンドを用いて、ＤＢ装置６に対する検索を実行し、その結果を受けて出力する。

以下、さらに、検索プログラム４２の処理を、ＤＢ管理プログラム５０の処理と関連付けて、全体的に説明する。
図４０は、図３１に示したＤＢ管理プログラム５０および図３８に示した検索プログラム４２の全体的な処理（Ｓ５２）を示すシーケンス図である。
図４０に示すように、ステップ５２０（Ｓ５２０）において、検索プログラム４２の検索操作受入部２６０は、ユーザの問い合わせ操作を受け入れる。
ステップ５２２（Ｓ５２２）において、検索操作受入部２６０は、検索条件作成部４２０に対して、検索要求メッセージを送信する。

ステップ５２６（Ｓ５２６）において、検索条件作成部４２０は、ＤＢ管理プログラム５０の関連情報作成・管理部５１０に対して、検索要求メッセージに含まれる分類型および分類値を送信する。
なお、Ｓ５２６の処理は、Ｓ４４６において、検索条件作成部４２０からＤＢ管理装置５に対して分類型・分類値を送信する処理に対応する。
ステップ５２８（Ｓ５２８）において、関連情報作成・管理部５１０は、検索条件作成部４２０から受けた分類型・分類値を情報テーブル管理部５３４に対して出力する。

ステップ５３０（Ｓ５３０）において、情報テーブル管理部５３４は、関連情報作成・管理部５１０から入力された分類型・分類値を用いて情報テーブルを参照し、入力された分類型・分類値に対応する最上位エントリを得る。
情報テーブル管理部５３４は、得られた最上位エントリを、関連情報作成・管理部５１０に返す。

ステップ５３２（Ｓ５３２）において、関連情報作成・管理部５１０は、Ｓ５３０の処理により得られた最上位エントリをディレクトリツリーテーブル管理部５２４に対して出力する。
ステップ５３４，５３６（Ｓ５３４，Ｓ５３６）において、ディレクトリツリーテーブル管理部５２４は、入力された最上位エントリに対応するＤＢ装置６を、関連情報作成・管理部５１０を介して検索条件作成部４２０に返す。

ステップ５３８（Ｓ５３８）において、検索条件作成部４２０は、検索条件を作成し、特定されたＤＢ装置６の名前などとともに、検索制御部２６４に対して出力する。
ステップ５４０（Ｓ５４０）において、検索制御部２６４は、ＬＤＡＰコマンドを作成し、特定されたＤＢ装置６にアクセスして検索を行う。
ステップ５４２〜５４６（Ｓ５４２〜Ｓ５４６）において、ＤＢ装置６から検索結果が返され、ユーザに対して表示される。

［ＤＢシステム４における関連情報およびその検索の例（１）］
以下、ＤＢシステム４においてどのように関連情報が登録され、登録された関連情報が検索されるかについて、具体例を挙げて説明する。
図４１は、図２４に示したＤＢシステム４においてＤＢ装置６に登録されるディレクトリ構造の関連情報を例示する第１の図であって、フラットなディレクトリ構造を示す。
図４１に示されたディレクトリ構造においては、図２６に点線で示されたエントリ（ｏｕ＝関係＃１〜＃ｎ）がなく、ルートエントリの直下に全ての関連情報がある。
このようなディレクトリ構造を、「フラットな構造のディレクトリ構造」と呼ぶ。

ユーザが、ＤＢ管理装置５（図２４）あるいはＰＣ１０２の入出力装置１２６（図７）に表示されたＧＵＩ画像（図３２）に対して、順次、関連情報を登録するための操作を行う。
この操作により、（関連名称，関連型，名称，役割）の形式で、ＤＢ管理装置５に対して、以下に示すような、
（ハムレット・著作について、著作情報、シェークスピア、作者），
（ハムレット・著作について、著作情報、ハムレット、作品），
（ベニスの商人・著作について、著作情報、シェークスピア、作者），
（ベニスの商人・著作について、著作情報、ベニスの商人、作品），
（ハムレット・日本語訳について、翻訳情報、ハムレット、原作），
（ハムレット・日本語訳について、翻訳情報、ハムレット日本語訳、翻訳版），
（ハムレット・日本語訳について、翻訳情報、出版、ＯＯ出版），・・・
などの情報が入力される。

ユーザによる登録操作の結果として、図４１に示すようなＤＩＴ形式のディレクトリ構造により関連情報が作成される。
なお、図４１に例示するフラットな構造のディレクトリ構造においては、ディレクトリ情報ツリーをサブツリーに分割することは考慮されておらず、分類型および分類値は、ディレクトリ情報ツリー全体に対して定義されるが、必要に応じて、フラットな構造のディレクトリ構造を、サブツリーに分割することも可能である。
このディレクトリ構造においては、仮想ルートエントリの下に、５つのＡノード（「ハムレット・著作について」，「ベニスの商人・著作について」，「ハムレット・日本語訳について」，「ハムレット・中国語訳について」，「ハムレット・上演について」；Ａ４，Ａ９，Ａ１０，Ａ１９，Ａ１３（図１９などを参照））に対応するエントリが設けられる。仮想ルートエントリに対しては、分類型および分類値が定義され、定義された分類型および分類値は、ＤＢ管理装置５において、図３０に示した情報テーブルにより管理される。

また、このディレクトリ構造においては、これらＡノードに対応するエントリそれぞれに、Ａノードそれぞれがもつ関連性役割に対応する下位エントリが設けられ、それぞれの役割を果たすＴノード（Ｔ４１，Ｔ４２，Ｔ９２，Ｔ１０１，Ｔ１０３，Ｔ１９１；図１９を参照）に関する情報をエントリの属性とする。
図４１に示した関連情報は、全て１つのＤＢ装置６−１（図２４）に記憶され、あるいは、最上位エントリごとに分割されて、５つのＤＢ装置６−１〜６−５に記憶され、検索プログラム４２による検索の対象とされる。

図４２，図４３は、図４１に示したディレクトリ構造の関連情報を例示する第２，第３の図である。
なお、図４２には、シェークスピアによる作品という一つの関連性（テーマ）に着目し、それに対応する「シェークスピア作品」エントリをルートエントリ下に新たに設け、その配下に関連情報を置くことにより、テーマに基づく階層化を実現する場合が例示されており、「シェークスピア作品」というエントリは、図２６に点線で示されたエントリ（ｏｕ＝関係＃１〜＃ｎ）に対応する。

さらに、図４３には、「著作」・「翻訳」・「上演」という異なる分類型（関連タイプ；Ａノードのノードタイプ）を表現するエントリが定義され、「シェークスピア作品」エントリ下に新たに設けられる場合が例示されている。
このように、関連情報を、それぞれの関連タイプ（ノードタイプ）に応じたエントリの配下に登録することにより、関連タイプ（ノードタイプ）に基づく階層化が行われる。

図４２に示すように、図４１に示した関連情報は、さらに階層化されうる。
つまり、図４１に示した関連情報に含まれる各ノードに対しては、共通のテーマとして、「シェークスピア作品」が定義されうるので、ユーザは、ＤＢ管理装置５を操作して、図４２に示すように、５つのＡノードに対応するエントリの上に、これらエントリ以下それぞれに記憶される情報が、シェークスピア作品であることを示すエントリを新たに作成し、関連情報のテーマに基づいて、関連情報を階層化してもよい。

図４２に示す場合においては、関連情報は、エントリ「シェークスピア作品」の下位にエントリ「ハムレット著作について（Ａ４）」〜「ハムレット上演について（Ａ１３）」を含むディレクトリ構造により表現されている。
例えば、エントリ「シェークスピア作品」およびエントリ「ハムレット著作について（Ａ４）」〜「ハムレット中国語訳について（Ａ１９）」以下のエントリを、サブツリーとしてＤＢ装置６−１に記憶させ、「ハムレット・上演について（Ａ１３）」以下のエントリを、サブツリーとしてＤＢ装置６−２に記憶させるなど、ディレクトリ構造に従って関連情報をサブツリーに分割することができ、分割の結果として得られたサブツリーは、ＤＢ装置６−１〜６−ｎに、分割されて記憶されうる。

このようなときには、これら「シェークスピア作品」および「ハムレット・上演について」のディレクトリが、最上位エントリとされ、これらの最上位エントリに対しては、分類型および分類値が定義され、定義された分類型および分類値は、ＤＢ管理装置５において、図３０に示した情報テーブルにより管理され、その参照関係は、図２９に示したディレクトリツリーテーブルにより管理される。

別の例では、図４２に示したように階層化された関連情報のディレクトリ構造の内、「シェークスピア作品」およびその下の「ハムレット・著作について」および「ベニスの商人・著作について」に対応する関連情報が、ＤＢ装置６−１に記憶され、「ハムレット・日本語訳について」および「ハムレット・中国語訳について」に対応する関連情報が、ＤＢ装置６−２に記憶され、「ハムレット・上演について」に対応する関連情報が、ＤＢ装置６−３に記憶される。
なお、最上位エントリは、サブツリー内でのルート（最も上位にある）エントリなので、各ＤＢ装置６に記憶されているサブツリーごとに、ただ１つの最上位エントリが定義される。また、分類型・分類値は、この最上位エントリに対して定義される。

従って、図４２に示した例においては、「ハムレット・日本語訳について」および「ハムレット・中国語訳について」に対応する関連情報を、ＤＢ装置６−２に記憶するためには、これら２つのエントリをまとめる上位エントリ（例えば、図４３に示す「翻訳情報」に対応するエントリ）が設けられ、これを最上位エントリするサブツリーが記憶されることになる。
このように分割されたサブツリーの参照関係は、図２９に示したディレクトリテーブルを用いることにより管理され、サブツリーそれぞれに付された分類型および分類値は、図３０に示した情報テーブルを用いることにより管理される。

また、さらに、図４１に示した５つのＡノードの内、Ａ４ノード（「ハムレット・著作について」）とＡ９ノード（「ベニスの商人・著作について」）とに、「著作情報」が、関連タイプ（ノードタイプ）として定義され、Ａ１０ノード（「ハムレット・日本語訳について」）とＡ１９ノード（「ベニスの商人・中国語訳について」）とに、「翻訳情報」が、関連タイプ（ノードタイプ）として定義され、Ａ１３ノード（「ハムレット・上映について」）に、「上演情報」が関連タイプ（ノードタイプ）として定義されるようなときには、図４３に示すように、定義された関連タイプ（ノードタイプ）ごとの階層化が可能である。

例えば、図４３に示したように階層化された関連情報のディレクトリ構造の内、「シェークスピア作品」およびその下の「著作情報」に対応する関連情報が、ＤＢ装置６−１に記憶され、「翻訳情報」に対応する関連情報が、ＤＢ装置６−２に記憶され、「上演情報」に対応する関連情報が、ＤＢ装置６−３に記憶される。
このようなときには、「シェークスピア作品」、「翻訳情報」および「上演情報」のエントリが、最上位エントリとされ、これらの最上位エントリに対しては、分類型および分類値が定義され、定義された分類型および分類値は、ＤＢ管理装置５において、図３０に示した情報テーブルにより管理され、その参照関係は、図２９に示したディレクトリツリーテーブルにより管理される。

検索者（ユーザ）が、検索プログラム４２（図２４）に対して、図４１〜図４３に示したようにＤＢ装置６に記憶された関連情報に対する検索のための操作を行うと、検索プログラム４２は、検索操作の内容を解析し、さらに、この検索操作の内容に適合したツリー情報（ディレクトリツリーテーブル）および情報テーブル（図２９，図３０）の内、検索に必要とされる情報）を、ＤＢ管理装置５から得る。
さらに、検索プログラム４２は、検索操作およびツリー情報に適合した検索条件（ＬＤＡＰ操作のコマンドおよびパラメータ）を作成し、検索条件に適合するディレクトリ情報を記憶しているＤＢ装置６に対する検索を行い、検索結果を得る。
このようにして得られた検索結果は、検索プログラム４２のユーザに対して表示される。

［ＤＢシステム４における関連情報およびその検索の例（２）］
以下、ＤＢシステム４においてどのように関連情報が登録され、登録された関連情報が検索されるかについて、商品、販売店および商品販売促進のためのプログラムを示す販売情報を、さらに具体例として挙げて説明する。
図４４，図４５は、図２４に示したＤＢシステム４においてＤＢ装置６に登録されるディレクトリ構造の関連情報を例示する第４，第５の図であって、図４４は、関東地域のみの販売情報を示し、図４５は、関東地域および関西地域を含む販売情報を示す。

図２４に示したＤＢ管理装置５あるいはＰＣ１０２に対するユーザの操作により、関東地域の販売情報が、図４４に示すディレクトリ構造で表現される関連情報として登録される。
つまり、ユーザにより入力された関連情報の登録データに基づき、仮想ルートエントリの直下に、「販売情報」に関するディレクトリ情報をまとめるエントリが設けられ、このエントリの下位に、「関東地域」の販売情報に関するエントリが設けられる。
また、「関東地域」の販売情報に関して、「位置情報」、「提供情報」および「参加情報」を関連タイプ（ノードタイプ）とするエントリが設けられ、これらのエントリの下に、「店舗」、「地区」、「提供先」および「主催」などの関連役割に対応するエントリが設けられ、さらに、これらのエントリそれぞれの属性（この属性は、ＤＢ装置６それぞれに記憶されており、この属性を管理するために、独自の管理テーブルは定義、作成されない）として、「店Ａ」・「新宿」など役割を果たすメンバに関する情報（Ｔノード用ＩＤテーブル（図２１）のノードＩＤ，ノード名に対応）が登録される。

なお、図４４などに示す「役割」は、図２０に示したＡＲテーブルにおける関連性役割に対応し、「メンバ」は、それぞれのＴノードに対応する。
図２０に示した例においては、関連ノード（Ａノード）Ａ４について、メンバＴ４１が「作者」という役割を果たし、メンバＴ４２が「作品」という役割を果たしている。

図４５に示すように、販売情報が、関東地域以外の情報（関西地域の販売情報など）をさらに含むときには、仮想ルートエントリの直下に、「販売情報」のエントリが設けられ、その下に、「関東地域」および「関西地域」のエントリが設けられ、「関西地域」のエントリの下に、関連タイプ（ノードタイプ）「位置情報」、「提供情報」および「参加情報」を表すエントリが設けられる。
さらに、これらのエントリの下には、「店舗」、「提供物」、「地区」および「主催」などの役割に対応するエントリが設けられ、これらのエントリそれぞれのエントリの属性として、「店Ｂ」、「店Ｃ」、「大阪」および「キャンペーンＡ」など、役割を果たすメンバに関する情報が登録される。
例えば、図４４，図４５に示した販売情報はサブツリーに分割され、仮想ルートエントリおよびその下位にある「販売情報」以外のディレクトリ情報は、例えば、ＤＢ装置６−１（Ａ；図２４）に記憶され、「販売情報」の下位にある「関東地域」以下のディレクトリ情報は、ＤＢ装置６−２（Ｂ）に記憶され、「関西地域」以下のディレクトリ情報は、ＤＢ装置６−３（Ｃ）に記憶され、これらの地域以外のディレクトリ（図示せず）情報は、ＤＢ装置６−４（Ｄ）などに記憶される。

図４６は、図４４，図４５に示した販売情報（関連情報）の最上位エントリおよびその参照先などを示すディレクトリツリーテーブルを例示する図である。
図４７は、図４４，図４５に示した販売情報（関連情報）の最上位エントリの分類型および分類値を示す情報テーブルを例示する図である。
ＤＢ装置６−１〜６−３などに記憶されている販売情報の最上位エントリ、上位参照先のエントリ、および、分割されたディレクトリツリー（またはサブツリー）の最上位エントリ、それぞれのサブツリーに記憶されるディレクトリ情報の分類型・分類値は、ＤＢ管理装置５により、図４６および図４７に示すディレクトリツリーテーブルおよび情報テーブルを用いて管理されている。

図４８は、図４４，図４５に示した販売情報のために用いられるＧＵＩ画像を例示する図である。
図４８に示すようなＧＵＩ画像がＤＢ管理装置５あるいはＰＣ１０２の入出力装置１２６に表示され、このＧＵＩ画像に対するユーザの操作に従って、以上説明したＤＢ装置６−１〜６−３などに登録された販売情報に対する検索が行われる。

［関東地域のみの販売情報を対象とする検索］
まず、図４４に示した関東地域のみの販売情報を対象とする検索を説明する。
但し、図４４には、関東地域のみの販売情報が例示されており、実際のディレクトリ情報としては、その他の地域や販売情報以外の情報などもすべて登録・記憶されている。
検索者（ユーザ）は、検索装置４０の入出力装置１２６に表示されたＧＵＩ画像（図４８）に対して、例えば、「関東地域において、何らかの販売プログラムへの参加を通じて、店Ｂと提携している店舗」を検索するための操作を行う。

図４９は、図４６，図４７に示したディレクトリツリーテーブルおよび情報テーブルから、図２４に示した検索装置４０が、検索の対象とするＤＢ装置６を求めるための処理を示す図である。
検索装置４０は、例えば、図４９に示すように、検索者の検索要求の内容を解析し、さらに、ＤＢ管理装置５から得られたツリー情報に含まれる情報テーブル（図４７）の内容を参照し、「地域(region)」および「関東地域」が、分類型および分類値として対応付けられたサブツリーの最上位エントリｄｎ＿Ｂ（「関東地域」のディレクトリ）を得る。
さらに、検索装置４０は、ツリー情報に含まれるディレクトリツリーテーブル（図４６）の内容を検索し、最上位エントリｄｎ＿Ｂが記憶されているＤＢ装置６−２（Ｂ）を求める。

図５０は、図４８に示したような検索条件から得られ、図４４に示した関東地域のみの販売情報に対する検索のために用いられるＬＤＡＰ操作を作成する検索要求メッセージを例示する図である。
なお、図５０には、ユーザにより入力された検索要求が、ＸＭＬメッセージとして例示されており、この検索要求から、実際に検索を実行するために用いられるＬＤＡＰ操作コマンドが生成される。
操作者により入力された検索条件と、ツリー情報から得られたサブツリー最上位エントリと、それがＤＢ装置６−２（Ｂ）に記憶されているとの情報とから、「関東地域において、何らかの販売プログラムへの参加を通じて、店Ｂと提携している店舗」を検索するためのＬＤＡＰ操作（ＬＤＡＰのコマンドおよびパラメータ）を作成し、ＤＢ装置６−２（Ｂ）に対する検索処理を行う。

また、図５０には、関東地域のディレクトリ以下を記憶するＤＢ装置６−２（Ｂ；図２４）に対して、検索装置４０が、以下（１）、（２）に示すような検索を実行するためのＬＤＡＰ操作を作成する検索要求メッセージが示されている。
（１）「関連タイプ（図２２に示すＡノードのノードタイプ；関連タイプ）」が「参加情報」の全てのエントリから、直下に「役割」が「参加者」であり、「メンバ」が「店Ｂ」であるエントリをもつものを求め、その下位エントリのうち「役割」が「主催」であるエントリからメンバ属性値（メンバ名）を得る。
この処理の結果として、「プログラムＡ」が、店Ｂが参加している販売プログラムとして得られる。
（２）「関連タイプ」が「参加情報」の全てのエントリから、直下に「役割」が「主催」であり、「メンバ」が「プログラムＡ」であるエントリをもつものを求め、その下位エントリのうち「役割」が「参加者」であるエントリからメンバ属性値（メンバ名）を得る。
この処理の結果として、「店Ａ」および「店Ｂ」が販売プログラム「プログラムＡ」に参加している店舗として得られ、検索装置４０は、これらの内、検索操作の内容（図４８）に含まれる「店Ｂ」と異なる「店Ａ」を、最終的な検索結果として選択する。

［関東地域および関西地域などの販売情報を対象とする検索］
次に、図４５に示した関東地域およびそれ以外の地域の販売情報を対象とする検索を説明する。
検索者（ユーザ）は、検索装置４０の入出力装置１２６に表示されたＧＵＩ画像（図４８）に対して、例えば、「店Ａが商品の提供により参加しているキャンペーンに、地域を問わず（全ての地域において）参加している店舗」を検索するための操作を行う。

検索装置４０は、検索者の検索操作の内容を解析して、ＤＢ管理装置５から得られるツリー情報に含まれる情報テーブル（図４７）を検索するが、検索操作の内容が、地域を限定しないために、検索装置４０は、「関東地域」および「関西地域」などの地域のエントリが参照する「販売情報」のエントリ（図４６などにおいてｄｎ＿Ａ）を得る。
さらに、検索装置４０は、ディレクトリツリーテーブル（図４６）を検索し、最上位エントリｄｎ＿Ａが記憶されているＤＢ装置６−１（Ａ）を求める。

操作者により入力された検索条件と、ツリー情報から得られた最上位エントリと、それがＤＢ装置６−１（Ａ）に記憶されているとの情報とから、「店Ａが商品の提供により参加しているキャンペーンに、地域を問わず（全ての地域において）参加している店舗」を検索するためのＬＤＡＰ操作（ＬＤＡＰのコマンドおよびパラメータ）を作成し、ＤＢ装置６に対する検索処理を行う。

このようなＬＤＡＰ操作には、以下のような検索操作が含まれる。
（１）「関連タイプ（図２２に示したＡノードのノードタイプ；関連タイプ）」が「提供情報」の全てのエントリから、直下に「メンバ」が「店Ａ」であり、「役割」が「提供先」であるエントリをもつものを求め、それら下位エントリのうち「役割」が「提供物」であるエントリからメンバ属性値（メンバ名）を得る。
この処理の結果として、「商品Ａ」が、店Ａが提供している商品として得られる。
（２）「関連タイプ」が「参加情報」の全てのエントリから、直下に「メンバ」が「商品Ａ」であり、「役割」が「参加者」であるエントリをもつものを求め、その下位エントリのうち「役割」が「主催」であるエントリからメンバ属性値（メンバ名）を得る。
この処理の結果として、「キャンペーンＡ」が、商品Ａが提供されているキャンペーンプログラムとして得られる。
（３）「関連タイプ」が「参加情報」の全てのエントリから、直下に「メンバ」が「キャンペーンＡ」であり、「役割」が「主催」であるエントリをもつものを求め、その下位エントリのうち「役割」が「参加者」であるエントリからメンバ属性値（メンバ名）を得る。
この処理の結果として、検索装置４０は、「商品Ａ」および「商品Ｃ」を、キャンペーンＡに参加する店舗が提供している商品として得る。
（５）「関連タイプ」が「提供情報」の全てのエントリから、直下に「メンバ」が「商品Ａ」であり、「役割」が「提供物」であるようなエントリ、あるいは、「メンバ」が「商品Ｃ」であり、「役割」が「提供物」であるようなエントリ、をもつものを求め、さらに、それら下位エントリのうち「役割」が「提供先」であるエントリからメンバ属性値（メンバ名）を得る。
この処理の結果として、「店Ａ」および「店Ｃ」が、商品Ａまたは商品ＣをキャンペーンＡに提供している店舗として得られ、検索装置４０は、「店Ａ」，「店Ｃ」の内、検索操作の内容（図４８）に含まれる「店Ａ」と異なる「店Ｃ」を、最終的な検索結果として選択する。

［ディレクトリ構造の動的変更およびＤＢ装置６間の負荷分散］
以上、説明したように、ＤＢシステム４（図２４）においては、関連情報がディレクトリ構造で表現されるので、ＤＢ装置６間におけるサブツリー単位での分割および複製が容易である。
従って、ＤＢシステム４においては、例えば、ＤＢ装置６に記憶されているあるエントリに対するアクセスが、何らかの理由により過大になったようなときでも、そのエントリを記憶する複製装置（ミラーサーバ）を追加したり、そのエントリおよびその下位のエントリ（以下、あるエントリおよびその下位のエントリの集合をサブツリーとも記す）ごと、他のＤＢ装置６に移したりするといった負荷分散のための対策が簡単である。

以下、このようなＤＢシステム４の特徴を活かして、ＤＢ装置６間で負荷を分散し、また、ＤＢシステム４のシステム性能低下を予防するために適したディレクトリ構造の動的変更、および、ＤＢ装置６間におけるサブツリーの交換および移動を説明する。
ＤＢシステム４におけるディレクトリ構成の動的変更、および、ＤＢ装置６間におけるサブツリーの交換・移動のためには、以下のような方法が採られる。
（１）同一ＤＢ装置６内における新たなサブツリーの作成（サブツリーの新設）、および、
（２）高負荷のＤＢ装置６から、低負荷のＤＢ装置６へのサブツリーの転送、あるいは、高負荷のＤＢ装置６においてアクセスが多いサブツリーと、低負荷のＤＢ装置６においてアクセスが少ないサブツリーとの交換（サブツリーの交換・移動）。

［サブツリーの新設］
まず、ＤＢシステム４におけるサブツリーの新設を説明する。
図５１は、図２４に示したＤＢシステム４のＤＢ装置６におけるサブツリーの新設を例示する図であって、（Ａ）は、サブツリーの新設前のディレクトリ構成を示し、（Ｂ）は、サブツリーの新設後のディレクトリ構成を示す。
図５１（Ａ）に示すように、検索装置４０から、ｑｕｅｒｙＢａｓｅＤＮを検索ベースとし、フィルタｑｕｅｒｙＦｉｌｅｒを用いた検索を実行したとき、この検索条件にマッチするエントリが、あるＤＢ装置６に記憶されたディレクトリツリー（またはサブツリー）の一部に集中する場合を考える。

なお、このフィルタｑｕｅｒｙＦｉｌｅｒは、ＬＤＡＰでの検索条件であって、ここまでに示した検索操作においては、「役割」＝「提供物」、「メンバ」＝「商品Ｃ」などの条件がフィルタｑｕｅｒｙＦｉｌｅｒになっている。
このフィルタｑｕｅｒｙＦｉｌｅｒにおいては、いくつかの条件の論理積から、複雑な条件が表される。

エントリそれぞれに対して、検索操作ごとに、何回、検索条件にマッチしたかを、ＤＢ装置６が計数し、この計数結果を、ＤＢ管理装置５において集計することにより、特定の検索条件の下で、アクセス頻度が多いエントリの集合と、その上位エントリとを求めることができる。
例えば、サブツリー新設前のディレクトリ構成（図５１（Ａ））において、このような計測を行うことにより、ある検索条件（検索ベース：ｑｕｅｒｙＢａｓｅＤＮ、フィルタ：ｑｕｅｒｙＦｉｌｔｅｒ）では、図中、網掛け表示されたエントリが検索にマッチし、これらエントリへのアクセスが集中していることが検出されうる。
このようなアクセスの集中が検出されたときに、アクセスが集中するエントリの集合に上位エントリ（ｇｒｏｕｐＤＮ）を設け、これ以下のエントリを新たなサブツリーとすることにより、エントリ集合へのアクセスを局所化することができ、ＤＢシステムの性能低下を回避することができる。
さらには、アクセスが集中するサブツリーを他のＤＢ装置６との間で移動させるための準備をすることもできる。

図５２は、図５１（Ａ），（Ｂ）に示したサブツリーの新設のために用いられる検索条件管理テーブルを例示する図である。
上位エントリ（ｇｒｏｕｐＤＮ）以下のサブツリーが新設されたときには、ＤＢ管理装置５（図２４）は、図５２に示すように、検索の起点エントリ（検索ベース；ｑｕｅｒｙＢａｓｅＤＮ）と、検索に用いられたフィルタ（ｑｕｅｒｙＦｉｌｔｅｒ）と、このエントリ以下で、アクセスが集中したエントリ集合の上位に付されたエントリ（新検索ベース；ｇｒｏｕｐＤＮ）とを対応付けた検索条件管理テーブルを作成し、検索装置４０に提供する。

検索装置４０は、検索条件管理テーブルを受けて、検索条件を作成するときに、変更があったエントリ（検索ベース；ｑｕｅｒｙＢａｓｅＤＮ）以下のサブツリーに対して、フィルタに、上記の特定のフィルタ（ｑｕｅｒｙＦｉｌｔｅｒ）を論理積として含む検索が生じたときに、元のエントリ（検索ベース；ｑｕｅｒｙＢａｓｅＤＮ）以下のサブツリーにではなく、新たなエントリ（新検索ベース；ｇｒｏｕｐＤＮ）以下のサブツリーに対して、特定のフィルタ（ｑｕｅｒｙＦｉｌｔｅｒ）を除いたフィルタを用いて検索を行うことにより、検索に要する時間を短縮することができる。
フィルタに、上記の特定のフィルタ（ｑｕｅｒｙＦｉｌｔｅｒ）を含まない場合、元のエントリ（ｑｕｅｒｙＢａｓｅＤＮ）を起点エントリとし、これ以下のサブツリー全体を検索範囲とする検索を行う。
なお、サブツリー新設後も、検索条件管理テーブルを用いないときと同様に、情報テーブル（図４７）によっても、検索条件管理テーブルによっても、検索のための最上位エントリが得られないときには、検索装置４０は、ＤＢ装置６−１〜６−ｎ（Ａ〜Ｎ）において最も上位にあるディレクトリから、検索を行う。

［サブツリーの移動・交換］
図５３は、図２４に示したＤＢシステム４のＤＢ装置６−１，６−２（Ａ，Ｂ）間におけるサブツリーの交換・移動を例示する図であって、（Ａ）は、サブツリー交換前のディレクトリ構造を示し、（Ｂ）は、サブツリー交換後のディレクトリ構造を示す。
図５３（Ａ）に示すように、ＤＢ装置６−２（Ｂ）において、アクセスが集中するサブツリー（エントリｄｎ＿３以下のサブツリー）が存在し、一方、ＤＢ装置６−１（Ａ）において、アクセスがほとんどないサブツリー（エントリｄｎ＿２以下のサブツリー）が存在する場合を考える。
エントリそれぞれに対して、何回、アクセスがあったかを、ＤＢ装置６が計数し、この計数結果を、ＤＢ管理装置５において集計することにより、アクセス頻度が多いサブツリーを求めることができる。同時に、ＤＢ装置６の負荷状態を求めることができる。また、図５２に示した検索条件管理テーブルを用いて、アクセスが集中するサブツリーを求めることもできる。

このようなアクセスの集中（偏り）が検出されたとき、図５３（Ｂ）に示すように、高負荷状態のＤＢ装置６−２（Ｂ）のエントリｄｎ＿３以下のサブツリーを、ＤＢ装置６−１（Ａ）のエントリｄｎ＿Ａ−１以下のサブツリーとし、反対に、ＤＢ装置６−１（Ａ）のエントリｄｎ＿２以下のサブツリーを、ＤＢ装置６−２（Ｂ）のｄｎ＿２を最上位エントリとするサブツリーとして、サブツリーをＤＢ装置６−１，６−２（Ａ，Ｂ）の間で交換することにより、ＤＢ装置６−１，６−２（Ａ，Ｂ）間で、負荷の分散を図ることができる。
ただし、マクロなレベルでのアクセス集中・偏り（例えば、そもそも検索の対象となる頻度が少ないため、アクセス（負荷）が低くなるといった状況）を想定すると、サブツリーの移動・交換については、必ずしも検索条件管理テーブルを用いる必要はない。

サブツリーの新設（検索条件管理テーブル）では、ある時点までに発生した特定の検索条件でのアクセス集中状況に応じて、それ以降の検索処理を高速化（効率化）することを目的とする。
一方、サブツリーの移動・交換は、それぞれの検索条件に依らず、また、特定の検索条件に限らず、各サーバあるいはサブツリーに対するアクセスの絶対数（頻度）の増大や減少によって負荷の著しい偏りが発生した場合、それを解消するための処理となる。

図５４は、図５３（Ａ），（Ｂ）に示したサブツリーの交換に伴うＤＢ装置６−１，６−２（Ａ，Ｂ）についてのディレクトリツリーテーブル（図４６）の更新を示す図であって、（Ａ）は、更新前のディレクトリツリーテーブルを示し、（Ｂ）は、更新後のディレクトリツリーテーブルを示す。
なお、このようなサブツリーの交換は、図５１（Ａ），（Ｂ）に示したように新設されたサブツリーおよび既存のサブツリーについて行われうる。
このような更新が行われたときには、ＤＢ管理装置５は、図５４（Ａ），（Ｂ）に示すように、ＤＢ装置６−１，６−２（Ａ，Ｂ）についてのディレクトリツリーテーブルの内容を更新する（但し、この場合、ＤＢ装置６−１（Ａ）についてのディレクトリツリーテーブルの内容に変更はない）。
また、例えば、図５３（Ａ）に示したＤＢ装置６−１（Ａ）のディレクトリｄｎ＿１に対するアクセスが集中し、ＤＢ装置６−２（Ｂ）全体に対するアクセスが少なく、低負荷状態であるときなどには、単に、ディレクトリｄｎ＿１以下のサブツリーをＤＢ装置６−１（Ａ）からＤＢ装置６−２（Ｂ）に移動させるだけで、ＤＢ装置６間で負荷が分散されうる。

以上説明したサブツリーの移動・交換は、以下のような手順で実行される。
（１）アクセス頻度の測定：ＤＢ装置６は、仮想ルートエントリの直下から、関連情報の基本構成単位（図２６）の１階層上までのエントリについて、アクセスの回数（頻度）を計測し、ＤＢ管理装置５がこの計測値を集計する。
（２）移動・交換元のサブツリーの選択：ＤＢ管理装置５は、ＤＢ装置６それぞれにおいて、同一階層に属する複数のエントリの下のサブツリーに対するアクセスの大きな偏り（集中）を検出したときに、これらのエントリの下のサブツリーを、移動・交換元のサブツリーとして選択する。
（３）移動・交換先のＤＢ装置の選択：ＤＢ管理装置５は、移動・交換元のサブツリーを選択すると、この移動・交換元のサブツリーを下位とせず、かつ、移動・交換元のサブツリーが記憶されていたＤＢ装置６よりもアクセスの頻度（負荷）が全体として低い他のＤＢ装置６を選択する。

［第３のＤＢプログラム６２］
図５５は、図２４に示したＤＢシステム４において、サブツリーの新設および移動・交換が行われるときに、ＤＢ装置６において動作する第３のＤＢプログラム６２を示す図である。
図５５に示すように、ＤＢプログラム６２は、図３７に示した第２のＤＢプログラム６０に、情報転送部６２０およびアクセス監視部６２４を付加した構成を採る。
ＤＢプログラム６２は、これらの構成部分により、第２のＤＢプログラム６０と同様な機能の他、サブツリーの新設および移動・交換のために必要な機能を実現する。

ＤＢプログラム６２において、情報転送部６２０は、ＤＢ管理装置５からの制御に従って、図５３（Ａ），（Ｂ）に示したような、サブツリーの移動・交換のために必要とされる関連情報の転送を行う。
アクセス監視部６２４は、ＤＢ装置６に記憶されたディレクトリ情報のエントリそれぞれに対するアクセスの回数（頻度）を計測し、計測値をＤＢ管理装置５に対して送信する。

［第２のＤＢ管理プログラム５６］
図５６は、図２４に示したＤＢシステム４において、サブツリーの新設および移動・交換が行われるときに、ＤＢ管理装置５において動作する第２のＤＢ管理プログラム５６を示す図である。
図５６に示すように、第２のＤＢ管理プログラム５６は、図３１に示した第１のＤＢ管理プログラム５０に、構成変更処理部５６０、情報転送制御部５６２（情報転送手段）、ＤＢ監視部５７０、監視用ＤＢ５７２、検索条件管理部５８０、検索条件ＤＢ５８２および検索条件提供部５８４を付加した構成を採る。
ＤＢ管理プログラム５６は、これらの構成部分により、第１のＤＢ管理プログラム５０と同様な機能の他、サブツリーの新設および移動・交換のために必要な機能を実現する。

ＤＢ管理プログラム５６において、ＤＢ監視部５７０は、ＤＢ装置６それぞれから送られてきた各エントリに対するアクセス回数（頻度）およびアクセスの際に用いられたＬＤＡＰによる検索操作に関する情報（検索ベース、および、フィルタ）を集計し、集計値を監視用ＤＢ５７２に記憶する。
ＤＢ監視部５７０は、記憶したアクセス頻度およびその検索操作に関する情報の集計値を、構成変更処理部５６０に対して出力する。

構成変更処理部５６０は、ＤＢ監視部５７０から入力される各エントリに対するアクセス回数の集計値に応じて、情報転送制御部５６２を制御し、図５１（Ａ），（Ｂ）に例示したサブツリーの新設のための処理を行う。
また、構成変更処理部５６０は、各エントリに対するアクセス回数の集計値に応じて、情報転送制御部５６２を制御し、図５３（Ａ），（Ｂ）に例示したサブツリーの移動・交換のために必要な処理を行わせる。
また、構成変更処理部５６０は、情報テーブル管理部５３４および情報テーブル管理部５３４を制御して、図５４（Ａ），（Ｂ）に例示したような、サブツリーの新設および移動・変更に伴うディレクトリツリーテーブル（図４６）などの内容の変更のために必要な処理を行わせる。

検索条件管理部５８０は、サブツリーの新設および移動・変更があったときに、図５２に例示した検索条件管理テーブルを作成し、検索条件ＤＢ５８２に記憶する。
さらに、検索条件管理部５８０は、検索条件提供部５８４に対して、記憶した検索条件管理テーブルを出力する。
検索条件提供部５８４は、検索条件管理部５８０から入力された検索条件管理テーブルを、検索装置４０（検索プログラム４４；図５９）に対して提供する。

以下、アクセス回数の集計をさらに説明する。
図５７は、図５６に示したＤＢ管理プログラム５６の処理（Ｓ５６）を示すフローチャートである。
図５７に示すように、ステップ５６０（Ｓ５６０）において、ＤＢ管理プログラム５０は、初期化処理を行う。
ステップ５６２（Ｓ５６２）において、ＤＢ監視部５７０は、ＤＢ装置６のエントリそれぞれに対するアクセス回数の計測を開始する。

ステップ５６４（Ｓ５６４）において、ＤＢ装置６は、検索制御部２６４からＬＤＡＰ検索操作コマンドを受け入れる。
ステップ５６６（Ｓ５６６）において、ＤＢ監視部５７０は、ＤＢ装置６に入力された検索操作コマンドに含まれる検索条件を取得する。
ステップ５６８（Ｓ５６８）において、ＤＢ監視部５７０は、検索条件に合うエントリの情報をＤＢ装置６から取得する。
なお、Ｓ５６４〜Ｓ５６８の処理は、ＤＢ装置６で実行される検索操作に関する情報を集計するために行われ、これらの集計値はＤＢ装置６からＤＢ監視部５７０に送られる。

ステップ５７０（Ｓ５７０）において、ＤＢ監視部５７０は、検索操作に関する情報を集計するための所定の計測時間が経過したか否かを判断する。
ＤＢ管理プログラム５６は、計測時間を経過したときにはＳ５７２の処理に進み、これ以外のときにはＳ５６４の処理に進む。
ステップ５７２（Ｓ５７２）において、ＤＢ監視部５７０は、アクセス回数の計測を終了する。

ステップ５７４（Ｓ５７４）において、ＤＢ監視部５７０は、計測が開始されてから終了するまでの計測時間において、全てのエントリに対するアクセス回数、および、全てのＤＢ装置６の負荷状態を算出する。
ステップ５７６（Ｓ５７６）において、構成変更処理部５６０は、ＤＢ監視部５７０により算出された計測結果に基づき、全てのエントリについて、アクセス集中の有無を検出する。
ステップ５７８（Ｓ５７８）において、ＤＢ監視部５７０は、処理を継続するか否かを判断する。
ＤＢ管理プログラム５６は、処理を継続するときにはＳ５６０の処理に進み、これ以外のときには処理を終了する。

図５８は、複数のＤＢ装置にまたがる同一階層のエントリを例示する図である。
なお、エントリおよびサブツリーに対するアクセスの集中は、例えば、以下（１），（２）に示すような方法で検出される。
（１）所定の計測時間内で、すべての検索操作について、アクセス集中指標（アクセス集中指標＝検索条件に合うエントリ数／特定の階層に存在するエントリ数（図５１（Ａ）））を算出する。
それぞれの検索操作の実行回数が、事前に定められた回数よりも多く、かつ、算出されたアクセス集中指標が、ある閾値以下となったときには、その検索条件に対してアクセス集中が発生したと検出する。
（２）分割されたサブツリーを記憶するＤＢ装置６を計測の対象とし、サブツリーそれぞれの最上位エントリ、および、最上位エントリと同じ階層に属する全てのエントリが、操作要求に応じて検索ベースとされた回数（頻度）を、そのサブツリーのアクセス頻度として、（１）に準じた方法で、アクセスの集中を検出する。

［第２の検索プログラム４４］
図５９は、図２４に示したＤＢシステム４において、サブツリーの新設および移動・交換が行われるときに、検索装置４０において動作する第２の検索プログラム４４を示す図である。
図５９に示すように、第２の検索プログラム４４は、図３８に示した第１の検索装置４０に、検索条件変換部４４０を付加した構成を採る。
検索プログラム４４は、これらの構成部分により、第１の検索装置４０と同様な機能の他、検索条件管理テーブルを用いた検索条件の変換を行う。

検索プログラム４４において、検索条件変換部４４０は、ＤＢ管理装置５から、検索条件管理テーブル（図５２）を受け取り、検索条件作成部４２０が作成した検索条件に含まれるフィルタおよび検索対象の起点エントリ（検索ベース）が、検索条件管理テーブルに示された条件に合うか否かを判断する。
検索条件変換部４４０は、検索条件に含まれるフィルタおよび検索ベースが、検索条件管理テーブルに示された条件に合うときには、検索対象の元の起点エントリ（検索ベース；ｑｕｅｒｙＢａｓｅＤＮ）を、新しい検索起点エントリ（新検索ベース；ｇｒｏｕｐＤＮ）とし、検索条件のフィルタから検索条件管理テーブルに示されたフィルタ（ｑｕｅｒｙＦｉｌｔｅｒ）を除いた新しいフィルタに変換するように検索条件作成部４２０を制御する。

［サブツリーを新設するときのＤＢシステム４の動作］
以下、サブツリーの新設を行うときのＤＢシステム４の全体的な動作を説明する。
図５１（Ａ）を参照して既に述べたように、エントリそれぞれに対して、検索操作ごとに、何回、検索条件にマッチしたかを、ＤＢ装置６が計数し、この計数結果を、ＤＢ管理装置５において集計することにより、特定の検索条件の下で、アクセス頻度が多いエントリの集合と、その上位エントリとを求めることがきる。
このようなアクセスの集中が検出されたときに、アクセスが集中するエントリの集合に上位エントリ（ｇｒｏｕｐＤＮ）を設け、これ以下のエントリを新たなサブツリーとすることにより、エントリ集合へのアクセスを局所化することができ、ＤＢシステムの性能低下を回避することができる。
ＤＢ装置６は、各エントリに対するアクセスの回数（頻度）およびアクセスに用いられたフィルタを、ＤＢ管理装置５に通知する。
ＤＢ管理装置５は、ＤＢ装置６から得られた各エントリに対するアクセスの回数（頻度）およびアクセスに用いられたフィルタを集計する。

ＤＢ管理装置５は、あるＤＢ装置６のサブツリーに対するアクセスが大きい場合などに、図５１（Ａ），（Ｂ）に示したように、ＤＢ装置６を制御して、サブツリーの新設を行う。
さらに、ＤＢ管理装置５は、このサブツリーの新設に合うように、検索条件管理テーブル（図５２）の内容を変更する。
ＤＢ管理装置５は、内容が変更された検索条件管理テーブルを、検索装置４０に対して提供する。
検索装置４０は、検索者（ユーザ）の検索操作に従って、検索操作の内容から、検索条件を作成するときに、ＤＢ管理装置５から提供された検索条件管理テーブルを用いた変換を行い、ＤＢ装置６に対する検索を行う。

［サブツリーを移動・交換するときのＤＢシステム４の動作］
次に、サブツリーの移動・交換を行うときのＤＢシステム４の全体的な動作を説明する。
図５８を参照して既に述べたように、複数のＤＢ装置にまたがる同一階層のエントリそれぞれに対して、検索ベースとされた回数を集計することにより、サブツリーへのアクセス集中を検出することができる。
ＤＢ装置６は、各エントリが検索ベースとして利用された回数を計測し、ＤＢ管理装置５に通知する。
ＤＢ管理装置５は、それぞれのＤＢ装置の最上位エントリ、および、それら最上位エントリと同じ階層にある他のＤＢ装置の全てのエントリが検索ベースとされた回数を集計し、各サブツリーのアクセス頻度として算出する。

ＤＢ管理装置５は、あるＤＢ装置６のサブツリーに対するアクセスが大きい場合などに、図５３（Ａ），（Ｂ）に示したように、ＤＢ装置６を制御して、サブツリーの移動・交換を行う。
さらに、ＤＢ管理装置５は、このサブツリーの移動・交換に合うように、ディレクトリツリーテーブル（図４６）および情報テーブル（図４７）などの内容を変更する。
ＤＢ管理装置５は、内容が変更されたディレクトリツリーテーブルおよび情報テーブルを、検索装置４０に対して提供する。
検索装置４０は、検索者（ユーザ）の検索操作に従って、提供されたディレクトリツリーテーブルおよび情報テーブルを用いて、ＤＢ装置６に対する検索を行う。

本発明は、データベースおよびデータ検索のために利用可能である。

図１は、本発明において関連性ネットワーク型データを変換する際のデータモデルを示す図である。 図２は、記憶の対象となる一連の関連性を有するｎ個のデータを、図１に示したデータモデルに従って変換したデータ構造を示す図である。 図３は、関連ノード間の関連性を表現する方法の一例を示す図である。 図４は、第１及び第２の例のデータをノード群及び各ノード間の関連を示すエッジ群を用いて表現した関連性ネットワーク型データの構造を示す図である。 図５は、本発明の好適実施例に関するブロック図である。 図６は、本発明にかかる第１のデータベースシステム（ＤＢシステム）の構成を例示する図である。 図７は、図６に示したＤＢ装置およびＰＣのハードウエア構成を例示する図である。 図８は、図３（ａ）に例示したデータの関連を書き換えて示す図である。 図９は、図８に示したデータ構造を一般化して示す図である。 図１０は、図３（ｂ），図４に示したデータの関係を、一般化して示す図である。 図１１は、図９に示した構造を採るデータを記憶するために用いられる関連性役割（ＡＲ(Association Role)）テーブルを示す図である。 図１２は、図９に示した構造を採るデータを記憶するために用いられるＴノード用識別子（ＩＤ(Identifier)）テーブルを示す図である。 図１３は、図９に示した構造を採るデータを記憶するために用いられるＡノード用識別子（ＩＤ）テーブルを示す図である。 図１４は、図６，図７に示したＤＢ装置におけるデータ検索方法を例示する図である。 図１５は、図６，図７に示したＤＢ装置における検索の全体的な処理（Ｓ２０）を示す第１のフローチャートである。 図１６は、図１５に示した検索フィルタに基づく関連ノードの選択処理（Ｓ２２）を示すフローチャートである。 図１７は、図１５，図１６に示したノードＩＤおよびノード名取得処理（Ｓ２４）を示すフローチャートである。 図１８は、図６，図７に示したＤＢ装置において実行されるＤＢプログラム２の構成を示す図である。 図１９は、図６，図７に示したＤＢ装置（ＤＢプログラム；図１８）に対して入力されるデータと、これに含まれるデータの検索に含まれる検索条件とを例示する図である。 図２０は、ＡＲエントリ作成部（図１８）およびＡＲＤＢ管理部により作成され、ＡＲＤＢに記憶されるＡＲテーブルを例示する図である。 図２１は、ＩＤエントリ作成部（図１８）およびＩＤＤＢ管理部により作成され、ＩＤＤＢに記憶されるＴノード用のＩＤテーブルを例示する図である。 図２２は、ＩＤエントリ作成部（図１８）およびＩＤＤＢ管理部により作成されるＡノードについてのＩＤテーブルを例示する図である。 図２３は、第２のＤＢシステムの構成を例示する図である。 本発明にかかる第３のＤＢシステムの構成を例示する図である。 図２４に示したＤＢシステムにおける情報のグラフ形式の表現を例示する図である。 図２５に示した情報のディレクトリ情報ツリー形式の表現を例示する図である。 ディレクトリ構造で表現された関連情報の分割方法を例示する図である。 図２７に示したＤＢ装置（Ａ）のエントリｄｎ＿Ａ２と、ＤＢ装置（Ｎ）のエントリｄｎ＿Ｎとの参照関係を示す図である。 図２７に示したようにＤＢ装置（Ａ〜Ｎ）に分割されて記憶された関連情報を管理するために用いられるディレクトリツリーテーブルを例示する図である。 図２７，図２８に示したＤＢ装置（Ａ〜Ｎ）に記憶されているディレクトリツリー（またはサブツリー）それぞれの最上位エントリｄｎ＿Ａ〜ｄｎ＿Ｎ、および、サブツリーそれぞれに記憶されている関連情報の分類に用いられる情報テーブルを例示する図である。 図２４に示したＤＢ管理装置において動作する第１のＤＢ管理プログラムの構成を示す図である。 図３１に示したＤＢ管理プログラムが、データ入力のために用いられるコンピュータ（ＰＣ）の入出力装置（図６，図７）に表示するＧＵＩ画像を例示する図である。 図３２に示したＤＢ管理プログラムによる関連情報の登録処理（Ｓ３０）を示すフローチャートである。 図３２に示したＤＢ管理プログラムによる情報テーブル（図３０）の変更処理（Ｓ３４）を示すフローチャートである。 図３１に示したＤＢ管理プログラムによるディレクトリツリーテーブルの変更処理（Ｓ３６）を示すフローチャートである。 図３１に示したＤＢ管理プログラムの全体的な動作（Ｓ４０）を示すシーケンス図である。 図２４に示したＤＢ装置それぞれにおいて動作する第２のＤＢプログラムを示す図である。 図２４に示した検索装置において動作する検索プログラムを示す図である。 図３８に示した検索プログラムによる検索処理（Ｓ４４）を示すフローチャートである。 図３１に示したＤＢ管理プログラムおよび図３８に示した検索プログラムの全体的な処理（Ｓ５２）を示すシーケンス図である。 図２４に示したＤＢシステムにおいてＤＢ装置に登録されるディレクトリ構造の関連情報を例示する第１の図であって、フラットなディレクトリ構造を示す。 図４１に示したディレクトリ構造の関連情報を例示する第２の図である。 図４１に示したディレクトリ構造の関連情報を例示する第３の図である。 図２４に示したＤＢシステムにおいてＤＢ装置に登録されるディレクトリ構造の関連情報を例示する第４の図であって、関東地域のみの販売情報を示す。 図２４に示したＤＢシステムにおいてＤＢ装置に登録されるディレクトリ構造の関連情報を例示する第４の図であって、関東地域および関西地域を含む販売情報を示す。 図４４，図４５に示した販売情報（関連情報）の最上位エントリおよびその参照先などを示すディレクトリツリーテーブルを例示する図である。 図４４，図４５に示した販売情報（関連情報）をサブツリー分割したときの最上位エントリとその分類型および分類値を示す情報テーブルを例示する図である。 図４４，図４５に示した販売情報に対する検索のために用いられるＧＵＩ画像を例示する図である。 図４６，図４７に示したディレクトリツリーテーブルおよび情報テーブルから、図２４に示した検索装置が、検索の対象とするＤＢ装置を求めるための処理を示す図である。 図４８に示したような検索条件から得られ、図４４に示した関東地域のみの販売情報に対する検索のために用いられるＬＤＡＰ操作を作成する検索要求メッセージを例示する図である。 図２４に示したＤＢシステムのＤＢ装置におけるサブツリーの新設を例示する図であって、（Ａ）は、サブツリーの新設前のディレクトリ構成を示し、（Ｂ）は、サブツリーの新設後のディレクトリ構成を示す。 図５１（Ａ），（Ｂ）に示したサブツリーの新設のために用いられる検索条件管理テーブルを例示する図である。 図２４に示したＤＢシステムのＤＢ装置（Ａ，Ｂ）間におけるサブツリーの交換・移動を例示する図であって、（Ａ）は、サブツリー交換前のディレクトリ構造を示し、（Ｂ）は、サブツリー交換後のディレクトリ構造を示す。 図５３（Ａ），（Ｂ）に示したサブツリーの交換に伴うＤＢ装置（Ａ，Ｂ）についてのディレクトリツリーテーブル（図４６）の更新を示す図であって、（Ａ）は、更新前のディレクトリツリーテーブルを示し、（Ｂ）は、更新後のディレクトリツリーテーブルを示す。 図２４に示したＤＢシステムにおいて、サブツリーの新設および移動・交換が行われるときに、ＤＢ装置において動作する第３のＤＢプログラムを示す図である。 図２４に示したＤＢシステムにおいて、サブツリーの新設および移動・交換が行われるときに、ＤＢ管理装置において動作する第２のＤＢ管理プログラムを示す図である。 図５６に示したＤＢ管理プログラム５６の処理（Ｓ５６）を示すフローチャートである。 複数のＤＢ装置にまたがる同一階層のエントリを例示する図である。 図２４に示したＤＢシステムにおいて、サブツリーの新設および移動・交換が行われるときに、検索装置において動作する第２の検索プログラムを示す図である。

符号の説明

４・・・ＤＢシステム、
１０２・・・ＰＣ、
４０・・・検索装置、
４２，４４・・・検索プログラム、
２６０・・・検索操作受入部、
２６４・・・検索制御部、
４２０・・・検索条件作成部、
４４０・・・検索条件変換部、
４４２・・・検索結果受入部、
５・・・ＤＢ管理装置、
５０，５６・・・ＤＢ管理プログラム、
５００・・・ＵＩ部、
５０２・・・情報登録部、
５０４・・・情報送信部、
５１０・・・関連情報作成・管理部、
５１２・・・ツリー情報提供部、
５２２・・・ディレクトリツリーテーブル作成部、
５２４・・・ディレクトリツリーテーブル管理部、
５２６・・・ディレクトリツリーテーブルＤＢ、
５３２・・・情報テーブル作成部、
５３４・・・情報テーブル管理部、
５３６・・・情報テーブルＤＢ、
５６０・・・構成変更処理部、
５６２・・・情報転送制御部、
５７０・・・ＤＢ監視部、
５７２・・・監視用ＤＢ、
５８０・・・検索条件管理部、
５８２・・・検索条件ＤＢ、
５８４・・・検索条件提供部、
６・・・ＤＢ装置、
６０，６２・・・ＤＢプログラム、
６００・・・情報管理部、
６０２・・・情報ＤＢ、
６０４・・・情報通信部、
６０６・・・検索実行部、
６２０・・・情報転送部、
６２４・・・アクセス監視部、

Claims (23)

1. １つ以上の関連ノードと、１つ以上の見出ノードとを関連付けてディレクトリツリーの形式のデータベースとするデータベースシステムであって、前記関連ノードそれぞれは、１つ以上の前記見出ノードと関連付けられ、前記見出ノードそれぞれには１つ以上の情報が属し、前記関連付けられた前記関連ノードと前記見出ノードとの間それぞれに対しては、これらの間の関連を示す関連属性が定義され、
   前記関連ノードそれぞれの関連ノードエントリと、前記関連属性それぞれの関連属性エントリとを作成し、これらのエントリを、前記関連ノードと前記関連属性との関連に従って対応付けて、ディレクトリツリーを作成するディレクトリツリー作成手段と、
   前記見出ノードそれぞれに対応する情報を、前記作成された関連属性エントリに、前記見出ノードと前記関連属性との関連に従って対応付ける情報対応付手段と
   を有するデータベースシステム。
2. 前記関連属性は、前記関連ノードと前記見出ノードとの間に定義される役割を示す
   請求項１に記載のデータベースシステム。
3. 前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、
   前記ディレクトリツリーおよびサブツリーにおいて、前記関連ノードおよび前記見出ノードは、階層的に対応付けられる
   請求項１または２に記載のデータベースシステム。
4. 前記サブツリーそれぞれの最上位のエントリそれぞれと、これら最上位のエントリが参照する前記ディレクトリツリーまたは他の前記サブツリーに含まれるエントリとを対応付ける最上位エントリ対応付手段
   をさらに有する請求項３に記載のデータベースシステム。
5. 前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とをそれぞれ記憶する１つ以上の第１のデータベース装置
   を有する請求項３または４に記載のデータベースシステム。
6. ある第１のデータベース装置に記憶された情報を、他の第１のデータベース装置に転送して記憶させる情報転送手段
   をさらに有する請求項５に記載のデータベースシステム。
7. 前記情報転送手段は、前記第１のデータベース装置の動作状態に基づいて、ある第１のデータベース装置から、他の第１のデータベース装置に転送する情報を決める
   請求項６に記載のデータベースシステム。
8. 前記情報転送手段は、前記ディレクトリツリーまたは前記サブツリーに対するアクセス状態に基づいて、ある第１のデータベース装置から、他の第１のデータベース装置に転送する情報を決める
   請求項６に記載のデータベースシステム。
9. 前記第１のデータベース装置の１つ以上に記憶された情報の複製を記憶する第２のデータベース装置
   をさらに有し、
   前記最上位エントリ対応付手段は、前記第１のデータベース装置の最上位エントリと、前記第１のデータベース装置に記憶された情報の複製を記憶する前記第２のデータベース装置とをさらに対応付ける
   請求項５〜８いずれかに記載のデータベースシステム。
10. 前記ディレクトリツリーおよび前記サブツリーそれぞれには、さらに１つ以上の前記サブツリーが含まれることがあり、
    前記ディレクトリツリーおよび前記サブツリーそれぞれから、さらに前記サブツリーを作成するサブツリー作成手段
    をさらに有する請求項９に記載のデータベースシステム。
11. 前記ディレクトリツリーおよび前記サブツリーそれぞれには、前記関連ノードおよび見出しノードの分類に用いられる分類情報が定義され、
    前記前記ディレクトリツリーおよび前記サブツリーそれぞれと、これらのディレクトリツリーそれぞれに定義された分類情報とを対応付ける分類情報対応付手段
    をさらに有する請求項９または１０に記載のデータベースシステム。
12. 前記記憶された見出ノードに対応する情報を検索する検索装置
    をさらに有する請求項１１に記載のデータベースシステム。
13. 前記検索装置は、
    検索条件を受け入れる検索条件受入手段と、
    前記受け入れられた検索条件に対応する前記分類情報と対応付けられた前記ディレクトリツリーまたは前記サブツリーを検索するディレクトリツリー検索手段と、
    前記検索の結果として得られたディレクトリツリーに含まれる見出ノードに対応する情報を検索する情報検索手段と
    を有する請求項１２に記載のデータベースシステム。
14. １つ以上の関連ノードと、１つ以上の見出ノードとを関連付けてディレクトリツリーのデータベースにおける情報管理方法であって、前記関連ノードそれぞれは、１つ以上の前記見出ノードと関連付けられ、前記見出ノードそれぞれには１つ以上の情報が属し、前記関連付けられた前記関連ノードと前記見出ノードとの間それぞれに対しては、これらの間の関連を示す関連属性が定義され、
    前記関連ノードそれぞれの関連ノードエントリと、前記関連属性それぞれの関連属性エントリとを作成し、これらのエントリを、前記関連ノードと前記関連属性との関連に従って対応付けて、ディレクトリツリーを作成し、
    前記見出ノードそれぞれに対応する情報を、前記作成された関連属性エントリに、前記見出ノードと前記関連属性との関連に従って対応付ける
    情報管理方法。
15. 前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、
    前記ディレクトリツリーおよび前記サブツリーそれぞれには、さらに１つ以上の前記サブツリーが含まれることがあり、
    前記ディレクトリツリーおよび前記サブツリーそれぞれから、さらに前記サブツリーを作成する
    請求項１４に記載の情報管理方法。
16. 前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、
    前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とをそれぞれ記憶し、
    前記記憶された見出ノードに対応する情報を検索する
    請求項１４に記載の情報管理方法。
17. 検索条件を受け入れ、
    前記受け入れられた検索条件に対応する前記分類情報と対応付けられた前記ディレクトリツリーまたは前記サブツリーを検索し、
    前記検索の結果として得られたディレクトリツリーに含まれる見出ノードに対応する情報を検索する
    請求項１６に記載の情報管理方法。
18. 前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とを、複数の第１のデータベース装置に記憶し、
    ある第１のデータベース装置に記憶された情報を、他の第１のデータベース装置に転送して記憶させる
    請求項１４に記載の情報管理方法。
19. コンピュータを含み、１つ以上の関連ノードと、１つ以上の見出ノードとを関連付けてディレクトリツリーのデータベースとするデータベースシステムのプログラムであって、前記関連ノードそれぞれは、１つ以上の前記見出ノードと関連付けられ、前記見出ノードそれぞれには１つ以上の情報が属し、前記関連付けられた前記関連ノードと前記見出ノードとの間それぞれに対しては、これらの間の関連を示す関連属性が定義され、
    前記関連ノードそれぞれの関連ノードエントリと、前記関連属性それぞれの関連属性エントリとを作成し、これらのエントリを、前記関連ノードと前記関連属性との関連に従って対応付けて、ディレクトリツリーを作成するステップと、
    前記見出ノードそれぞれに対応する情報を、前記作成された関連属性エントリに、前記見出ノードと前記関連属性との関連に従って対応付けるステップと
    をコンピュータに実行させるプログラム。
20. 前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、
    前記ディレクトリツリーおよび前記サブツリーそれぞれには、さらに１つ以上の前記サブツリーが含まれることがあり、
    前記ディレクトリツリーおよび前記サブツリーそれぞれから、さらに前記サブツリーを作成するステップ
    をさらにコンピュータに実行させる請求項１９に記載のプログラム。
21. 前記ディレクトリツリーは、１つ以上のサブツリーを含み、前記ディレクトリツリーおよび前記サブツリーそれぞれには、最上位のエントリが定義され、前記サブツリーそれぞれの最上位のエントリは、前記ディレクトリツリーおよび他の前記サブツリーのエントリのいずれかを参照し、
    前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とをそれぞれ記憶するステップと、
    前記記憶された見出ノードに対応する情報を検索するステップと
    をさらにコンピュータに実行させる請求項１９に記載のプログラム。
22. 検索条件を受け入れるステップと、
    前記受け入れられた検索条件に対応する前記分類情報と対応付けられた前記ディレクトリツリーまたは前記サブツリーを検索するステップと、
    前記検索の結果として得られたディレクトリツリーに含まれる見出ノードに対応する情報を検索するステップと
    をさらにコンピュータに実行させる請求項２１に記載のプログラム。
23. 前記ディレクトリツリーおよび前記サブツリーのいずれかに従って、これらのディレクトリツリーのいずれかに含まれる見出ノードに対応する情報と、前記関連ノードに対応する情報と、前記見出ノードと前記関連ノードとの間に定義される役割とを、複数の第１のデータベース装置に記憶するステップと、
    ある第１のデータベース装置に記憶された情報を、他の第１のデータベース装置に転送して記憶させるステップと
    をさらにコンピュータに実行させる請求項１９に記載のプログラム。

Images