JP3752945B2 - ディレクトリ検索システム及び方法、ディレクトリ検索プログラムを記録したコンピュータ読取可能な記録媒体 - Google Patents
ディレクトリ検索システム及び方法、ディレクトリ検索プログラムを記録したコンピュータ読取可能な記録媒体 Download PDFInfo
- Publication number
- JP3752945B2 JP3752945B2 JP2000039682A JP2000039682A JP3752945B2 JP 3752945 B2 JP3752945 B2 JP 3752945B2 JP 2000039682 A JP2000039682 A JP 2000039682A JP 2000039682 A JP2000039682 A JP 2000039682A JP 3752945 B2 JP3752945 B2 JP 3752945B2
- Authority
- JP
- Japan
- Prior art keywords
- entry
- search
- index
- key
- attribute
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、データベースなどの検索を行うディレクトリ検索システムおよび方法、ディレクトリ検索用プログラムを記録したコンピュータ読み取り可能な記録媒体に関し、特に、ディレクトリサービスにおいてエントリを検索するディレクトリ検索システムおよび方法、インデックス用プログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【０００２】
【従来の技術】
ディレクトリ検索システムは、ディレクトリ階層上に管理されるデータのデータベースの検索を高速に行うために用いられるシステムである。ディレクトリ検索システムは、２分探索木やハッシュ表のような仕組みを保持している。この仕組みをインデックスという。インデックスは、データを特定するためのキーに基づいて構成されている。ディレクトリ検索システムは、検索条件として指定されたキーの値によってインデックスを探索してデータを特定する。
【０００３】
特開昭６０−２５４３２５号公報にはディレクトリ検索システムの一例が開示されている。その公報に開示されているディレクトリ検索システムは、インデックスを主記憶装置上に保持している。このディレクトリ検索システムは、データを特定するキーによってインデックスを検索してそのデータの位置情報を取得し、２次記憶装置上の目的のデータにアクセスする。一般的に、主記憶装置は２次記憶装置よりもはるかにアクセス速度が速い。そのため、このようなディレクトリ検索システムを用いることによって、２次記憶装置（外部記憶装置）上に大量のデータが格納されていても目的のデータに高速にアクセスすることができる。
通常、このようなインデックスは１種類のキーに基づいて構成されている。また、ディレクトリ検索システムでは１種類のキーに対して複数のインデックスを検索しなければならない場合もある。この場合、１種類のキーについて複数のインデックスを検索するため、検索に時間がかかってしまうという問題があった。特開平３−７００４９号公報には、この問題を解決するディレクトリ検索システムが開示されている。図１５は、この公報で開示されたディレクトリ検索システムの構成を示すブロック図である。
【０００４】
このディレクトリ検索システムは、レコード処理の開始を指示する処理開始指示装置１００１とディレクトリ情報処理手段１００２と併合インデックス作成手段１００５と併合インデックス読込手段１００６と作業ファイル１００７とディレクトリファイル１００９とを備えている。
【０００５】
ディレクトリ情報処理手段１００２は、併合インデックス作成指示手段１００３と併合インデックス読込指示手段１００４とを備えている。ディレクトリファイル１００９は、データベースのデータの管理情報を記憶するためのものである。ディレクトリファイル１００９は、データの管理情報の部分集合である幾つかのサブファイルから成るサブファイル群１０１３と、利用者インデックス１０１０と、グループ共有インデックス１０１１と、システム共有インデックス１０１２とを備えている。利用者インデックス１０１０は利用者毎に作成されており、ディレクトリファイル内に多数記憶されている管理情報レコードのうち、その利用者のみが利用できるデータの管理情報レコードを管理している。グループ共有インデックス１０１１は複数の利用者から構成されるグループ毎に作成されており、グループに属する利用者のみが利用できるデータの管理情報レコードを管理している。システム共有インデックス１０１２は１つだけ作成されており、全利用者が利用できるデータの管理情報レコードを管理している。
【０００６】
このディレクトリ検索システムは以下のように動作する。まず、処理開始指示装置１００１からディレクトリ情報処理手段１００２に対し処理開始が要求されると、併合インデックス作成指示手段１００３は、入力された処理指示者名に基づいて併合インデックス作成手段１００５に対し併合インデックスを作成するように指示する。
【０００７】
すると、併合インデックス作成手段１００５は、ディレクトリファイル１００９内の処理指示者の利用者インデックス１０１０と処理指示者が属するグループ共有インデックス１０１１とシステム共有インデックス１０１２とを読み込み、これらを併合して作業ファイル１００７上に併合インデックス１００８を作成する。次に、併合インデックス読込指示手段１００４は、併合インデックス読込手段１００６に対し併合インデックス１００８を読込むように指示する。併合インデックス読込手段１００６は管理情報レコードを特定するキーである管理情報レコード名を用いて併合インデックス１００８から該当する管理情報レコードの位置情報を読み、それをディレクトリ情報処理手段１００２へ渡す。ディレクトリ情報処理手段１００２は渡された管理情報レコードの位置情報により目的の管理情報レコードをサブファイルから読込む。
【０００８】
このディレクトリ検索システムでは、データを探索するためのキーとなる管理情報レコード名から目標とする管理情報レコードを読み込むのに、３つのインデックスを別々に探索しなければならなかったところを、３つのインデックスを併合し、併合されたインデックスを１回探索するだけでインデックスレコードを求めることができるので、検索時間を短縮することができる。このように、ディレクトリ検索システムでは、インデックスを探索する時間を短縮することが１つの課題となっている。
【０００９】
また、ディレクトリ検索システムでは、データを検索するときに数種類のキーを用いる場合が多い。この場合、従来のディレクトリ検索システムでは、それぞれのキーに対応したインデックスを１つずつ探索しなければならないため、データの検索時間が長くなってしまうという問題があった。
【００１０】
数種類のキーから一度にデータを探索することができる２分探索木がいくつか提案されている。この２分探索木の１つにケイ−ディー・ツリー（以降 ｋ−ｄｔｒｅｅ）がある。ｋ−ｄ ｔｒｅｅは、アイ・イー・イー・イー・トランザクションズ・オン・ソフトウェア・エンジニアリング、第ＳＥ−５巻、第４号、３３３〜３４０頁（ＩＥＥＥ ＴＲＡＮＳＡＣＴＩＯＮＳ ＯＮ ＳＯＦＴＷＡＲＥ ＥＮＧＩＮＥＥＲＩＮＧ、ＶＯＬ．ＳＥ−５、ＮＯ．４、ＪＵＬＹ １９７９、Ｐａｇｅｓ ３３３−３４０．）に掲載されたマルチディメンジョナル・バイナリ・サーチ・ツリーズ・イン・データベース・アプリケーションズ（Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｂｉｎａｒｙ Ｓｅａｒｃｈ Ｔｒｅｅｓ ｉｎ Ｄａｔａｂａｓｅ Ａｐｐｌｉｃａｔｉｏｎｓ）と題するジョン．Ｌ．ベントレー（Ｊｏｈｎ Ｌ． Ｂｅｎｔｌｅｙ）による論文に記載されている。
【００１１】
このｋ−ｄ ｔｒｅｅは、２分探索木の各ノードに検索するデータのエントリが有する複数のキー値を格納できるように拡張されたものである。ｋ−ｄ ｔｒｅｅでは、ツリーの格段毎に各キーが順番に分岐条件として用いられる。例えば、キーがその人の名前、年齢、電話番号であるとすると、第１段目では名前が分岐条件として用いられ、第２段目では年齢が分岐条件として用いられ、第３段目は電話番号が分岐条件として用いられ、第４段目以降も名前、年齢、電話番号がこの順番で分岐条件として用いられる。
【００１２】
図１６は、ｋ−ｄ Ｔｒｅｅの基本的な構成を示す図である。このｋ−ｄ ｔｒｅｅは、ある会社の社員を探索するためのツリーである。このツリーでは、社員の名前と年齢とが、社員を検索するためのキーとなる。
【００１３】
図１６に示すように、根（以降 ルート）のノード１０１には、Ｓａｔｏ氏（Ｓａｔｏ、２２）が格納されている。Ｓａｔｏは名前を表し、２２は年齢を表す。このツリーの第１段目では、名前で枝が分岐する。ルートにおける名前の頭文字はＳであるので、名前の頭文字のアルファベットがＡ〜Ｒである人は左へ分岐し、名前の頭文字のアルファベットがＳ〜Ｚである人は右へ分岐する。したがって、Ｅｎｄｏ氏（Ｅｎｄｏ、２８）は左へ分岐してノード１０２に格納され、Ｕｅｄａ氏（Ｕｅｄａ、３４）は右へ分岐してノード１０３に格納される。ツリーの第２段目では年齢によって枝が分岐する。年齢が分岐元のノードに格納されている年齢より下の人は左に分岐し、年齢が分岐元のノードに格納されている年齢以上の人は右に分岐する。したがって、Ｉｉｊｉｍａ氏（Ｉｉｊｉｍａ、２０）は左へ分岐してノード１０４に格納され、Ａｏｋｉ氏（Ａｏｋｉ、３２）は右に分岐してノード１０５に格納される。第３段目では、第１段目と同様に名前のアルファベットで枝が分岐する。したがって、Ｄｏｉ氏（Ｄｏｉ、２２）は左へ分岐してノード１０６に格納され、Ｋａｔｏ氏（Ｋａｔｏ、２５）は右へ分岐してノード１０７に格納される。そして、Ｎａｋａｉ氏（Ｎａｋａｉ、３７）はノード１０５から右に分岐してノード１０８に格納される。
【００１４】
ｋ−ｄ ｔｒｅｅでは、指定されていないキーによって分岐されている段において枝の選択は行われない。例えば、年齢が検索条件として指定されていない場合には、２段目ではノード１０４およびノード１０５の両方へ進むようにする。
以上述べたように、ｋ−ｄ ｔｒｅｅでは、数種類のキーを用いて一度にデータの検索が行えるので、検索時間を短縮することができる。
【００１５】
しかし、このようなｋ−ｄ ｔｒｅｅでは、木のデータの分布が不均衡である場合に検索条件によって検索時間に偏りがあるという問題があった。ｋ−ｄ Ｆｒｅｅを改良して、木のデータ分布が不均衡な場合でも検索時間が安定する２分探索木として、エッチ・ビー・ツリー（以降 ｈＢ ｔｒｅｅ）がある。ｈＢ ｔｒｅｅは、１９９０年１２月、エー・シー・エム・トランザクションズ・オン・データベース・システムズ、第１５巻、第４号、６２４〜６５８頁（ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ ＤａｔａｂａｓｅＳｙｓｔｅｍｓ、Ｖｏｌ．１５、Ｎｏ．４、 Ｄｅｃｅｍｂｅｒ １９９０、Ｐａｇｅｓ ６２５−６５８．）に掲載されたザ・エッチ・ビー・ツリー：マルチディメンジョナル・インデックシング・メソッド・ウィズ・グッド・ギャランティード・パフォーマンス（Ｔｈｅ ｈＢ Ｔｒｅｅ： Ａ Ｍｕｌｔｉａｔｔｒｉｂｕｔｅ Ｉｎｄｅｘｉｎｇ Ｍｅｔｈｏｄ ｗｉｔｈ Ｇｏｏｄ Ｇｕａｒａｎｔｅｅｄ Ｐｅｒｆｏｒｍａｎｃｅ）と題するデビッド．Ｂ．ロメット（Ｄａｖｉｄ Ｂ． Ｌｏｍｅｔ）らによる論文に記載されている。
【００１６】
ｋ−ｄ ｔｒｅｅは、オブジェクト単位でインデックスを管理しているが、ｈＢ ｔｒｅｅは、複数のオブジェクトを含む所定の範囲でインデックスを管理している。この所定の範囲をブリックという。各ブリックには、前述のｋ−ｄ ｔｒｅｅ方式のインデックスが格納されている。ブリック内におけるオブジェクトの数が所定の値を越えた場合、そのブリックは分割される。分割されたブリック同士は２分探索木方式で接続され、その木におけるノードとなる。そのブリックにより構成された２分探索木のリーフ部分には、各オブジェクトの情報が格納される。このｈＢ ｔｒｅｅで目的のオブジェクトを検索するときには、まず、検索条件を満たすブリックが探索され、そのブリック内のｋ−ｄ ｔｒｅｅを検索して目的のオブジェクトの情報が格納されるリーフが探索される。
【００１７】
図１７は、図１６のｋ−ｄ ｔｒｅｅで示された社員の分布状態を示すマップである。このマップは、縦軸が年齢であり、横軸が名前となっている。図１７に示すように、アルファベットＳをｘ３とし、アルファベットＩをｘ２とし、年齢２８をｙ１とする。マップ上のエリアは、年齢２８以上かつ名前の頭文字がＡの領域３０１と、年齢２８以上で名前の頭文字がＢ〜Ｒの領域３０２と、年齢２８以下で名前の頭文字がＡ〜Ｈの領域３０３と、年齢２８以下で名前の頭文字がＩ〜Ｒの領域３０４と、名前の頭文字がＳ〜Ｚの領域３０５とに分割されている。図１８は、これらの社員の構成をｈＢ ｔｒｅｅで表した図である。このｈＢ ｔｒｅｅは、ノード２０１〜２０３と、リーフ２０４〜２０８とから構成されている。ノード２０１〜２０３は、それぞれｈＢ ｔｒｅｅのブリックを表すものであり、それぞれをブリックａ、ブリックｂ、ブリックｃとする。図１８のｈＢｔｒｅｅでは、図１６におけるマップの各領域を元にブリックａ、ｂ、ｃを構成する。ブリックａは、マップ全体を指すものであるとし、ブリックｂは、領域３０１、３０２、３０５を指すものであるとし、ブリックｃは、領域３０３、３０４を指すものであるとする。
【００１８】
領域３０３、３０４には、Ｉｉｊｉｍａ氏、Ｄｏｉ氏、Ｋａｔｏ氏が含まれている。この３氏は、図１６のｋ−ｄ ｔｒｅｅにおけるノード１０４以下に格納されている。したがって、ブリックｂには、図１６のｋ−ｄ ｔｒｅｅのノード１０４以下の部分がｋ−ｄ ｔｒｅｅ方式で管理されている。
【００１９】
また、領域３０１、３０２、３０５には、Ｓａｔｏ氏、Ｅｎｄｏ氏、Ｕｅｄａ氏、Ａｏｋｉ氏、Ｎａｋａｉ氏が含まれている。この５人は、図１６のｋ−ｄ ｔｒｅｅにおけるノード１０１、１０２、１０３、１０５、１０８に格納されている。したがって、ブリックｃには、それらのノード１０１、１０２、１０３、１０５、１０８から構成される部分がｋ−ｄ ｔｒｅｅ方式で管理されている。
ブリックａは、ブリックｂへ分岐するかブリックｃへ分岐するかを決定するためのものである。図１６のｋ−ｄ ｔｒｅｅによれば、ブリックｂへ分岐するかブリックｃへ分岐するかは、ノード１０１またはノード１０２によって決定されるため、ブリックａ内のｋ−ｄ ｔｒｅｅは、ノード１０１とノード１０２から構成され、そのｋ−ｄ ｔｒｅｅの葉には、選択すべきブリック名が指定されている。
【００２０】
リーフ２０４〜リーフ２０８には、Ｅ、Ｄ、Ｃ、Ｂ、Ａのリーフ名がそれぞれに付与されており、図１７に示す領域３０１〜３０５に含まれる社員についての情報が格納されている。リーフ２０４には領域３０３に含まれるＤｏｉ氏（Ｄｏｉ、２２）に関する情報が格納され、リーフ２０４には領域３０４に含まれるＩｉｊｉｍａ氏（Ｉｉｊｉｍａ、２０）、Ｋａｔｏ氏（Ｋａｔｏ、２２）に関する情報が格納される。以下リーフ２０７、２０８には領域３０２、３０５に含まれる社員に関する情報が格納される。
【００２１】
また、ブリックｂ、ｃは前述のとおり、ｋ−ｄ ｔｒｅｅ方式により構成されるが、そのツリーの葉には、そのリーフ２０４〜２０８のうち選択すべきリーフ名が指定されている。また、該当するオブジェクトがない場合は、その葉は外部ノードであるとしてｅｘｔが指定される。各ブリックの各ノードにあるｘ１、ｘ２、ｘ３、ｙ１は、それぞれ図１８に示すように、アルファベットのＡ、アルファベットのＩ、アルファベットのＳ、年齢の２８を示し、各ノードにおける分岐条件を示す。
【００２２】
以上述べたように、データを検索する２分探索木をｈＢ ｔｒｅｅとすることによって、複数のオブジェクトを管理するブリックを２分探索木のノードとして木の枝の状態を均一化することができるため、安定した検索時間を得ることができる。なお、上述のような複数のキーから構成されたマルチキーをキーとしてデータを特定するための２分探索木から構成されるインデックスをマルチキーインデックスという。
【００２３】
一方、特開平１０−２８９１３９号公報に開示されているようなディレクトリサーバでは、各ファイルの媒体情報を一元管理して保存しておき、クライアントからの検索要求や更新要求があった場合、一元管理してある媒体情報の検索や更新などを行う。この媒体情報の管理などにも、上述のようなディレクトリ検索システムが用いられている。
【００２４】
また、媒体情報の管理を始めとして、個人情報管理やネットワーク管理などに利用される汎用のディレクトリサービスでは、組織や個人、コンピュータ、プリンタなど、様々な資源が管理対象となる。ディレクトリ検索システムは、それらの資源をエントリとして、資源間の関係に基づいてディレクトリ階層を形成し、それらのエントリの属性（以降 アトリビュート）をキーとしたインデックスを探索することによって、それらのエントリを検索することができる仕組みを提供している。
【００２５】
このようなディレクトリ検索システムの一例が特願平１１−４３２５９号出願で示されている。このディレクトリ検索システムは、エントリが有するアトリビュートについての検索条件であるフィルタ条件とディレクトリ階層に基づいて設定される検索範囲であるスコープ条件とを利用者が指定することによってエントリを検索するシステムである。
【００２６】
図１９は、この出願で示されているディレクトリ検索システムの構成を示すブロック図である。このディレクトリ検索システムは、入力装置１と、データ処理装置８と、記憶装置９と、出力装置４とから構成される。入力装置１は、キーボード等の利用者からの要求を入力するためのものである。データ処理装置８はプログラム制御により動作し、記憶装置９が記憶する情報の検索を行う。出力装置４はディスプレイ装置や印刷装置等であり、データ処理装置８が行った処理の結果を出力する。記憶装置９は、エントリ／アトリビュート記憶部３１と、複合インデックス記憶部３５と、先祖関係記憶部３４とを備えている。
【００２７】
エントリ／アトリビュート記憶部３１は、全てのエントリの情報と、その各エントリが有する属性であるアトリビュートの情報を記憶する。
【００２８】
複合インデックス記憶部３５は、各エントリがエントリ／アトリビュート記憶部３１におけるディレクトリ上の何階層目の何番目にあるかという複合したデータを、２分探索木により構成されるインデックスやハッシュ表等の形式で記憶している。
【００２９】
図２０は、ある会社の組織をディレクトリ階層で表す図である。このディレクトリ階層は４層から構成される。階層１は会社、階層２は部門、階層３は課、階層４は社員の層となっている。会社４０１には、営業部門４０２と開発部門４０３とがある。営業部門４０２には国内営業課４０４と海外営業課４０５、開発部門４０３には企画課４０６と製造課４０７という課がある。各課にはそれぞれの人４０８〜４１５が配属されている。
【００３０】
先祖関係記憶部３４は、各エントリの先祖関係を記憶している。図２１は、先祖関係記憶部３４に記憶されている先祖関係を表す先祖関係表を示す図である。この表は、各行にはエントリ／アトリビュート記憶部３１が記憶する各エントリのうち、先祖を有するエントリが各ディレクトリ階層毎に並べられている。また、この表の各列には、エントリ／アトリビュート記憶部３１が記憶する各エントリのうち、子孫を有するエントリが各ディレクトリ階層毎に並べられている。この表上でチェックされているところは、列のエントリが、行のエントリの先祖になっているということを示している。例えば、Ｕｅｄａ氏の先祖は、会社４０１と、営業部門４０２と、海外営業課４０５であるということが、この表からわかるようになっている。
【００３１】
データ処理装置８は、エントリ管理手段２１と、フィルタ検索手段２７と、スコープ判定手段２８とから構成される。エントリ管理手段２１は、エントリやアトリビュートの登録・削除・更新の処理を行う。フィルタ検索手段２７は、利用者が指定した検索条件にしたがってエントリの検索を行う。スコープ判定手段２８は、フィルタ検索手段２３が検索したエントリが利用者が指定した検索範囲に入っているかどうか調べてエントリを絞り込む。
【００３２】
まず、利用者からの要求が、エントリやアトリビュートの更新要求、削除要求、登録要求のいずれかの要求であった場合のディレクトリ検索システムの動作について説明する。入力装置１からその要求が入力されると、エントリ管理手段２１は、その要求がアトリビュート更新要求ならばエントリ／アトリビュート記憶部３１に格納されているエントリのアトリビュートを更新する。
【００３３】
また、その要求がＩＤ更新又は削除要求ならば、エントリ管理手段２１は、複合インデックス記憶部３５に記憶されているエントリのＩＤを更新または削除し、先祖関係記憶部３４の先祖関係表におけるそのエントリに関係する箇所のチェックも更新または削除する。また、その要求がエントリまたはアトリビュートの削除要求ならば、エントリ管理手段２１は、エントリ／アトリビュート記憶部３１に格納されたデータの中から該当するエントリ又はアトリビュートを削除する。また、その要求がエントリまたはアトリビュートの登録要求ならば、エントリ管理手段２１は、エントリ／アトリビュート記憶部３１に登録要求されたエントリまたはアトリビュートを登録する。
【００３４】
その要求がＩＤ更新又は登録要求の場合、エントリ管理手段２１は、複合インデックス記憶部３５にエントリのＩＤを追加し、先祖関係記憶部３４の先祖関係表の該当箇所にもチェックする。上述の処理が終了したら、エントリ管理手段２１は処理終了を出力装置４に通知し、出力装置４は処理結果を表示する。
【００３５】
次にアトリビュートをキーとして、エントリを検索する場合の動作について説明する。入力装置１から与えられた検索要求がフィルタ検索手段２７に入力されると、フィルタ検索手段２７は、指定された検索条件であるフィルタ条件にしたがってエントリ／アトリビュート記憶部３１に格納されているエントリの検索を行う。検索条件を満たしたエントリは、フィルタ検索手段２７によって一時集合（不図示）に格納される。その後、スコープ判定手段２８は、一時集合に格納されたエントリのうち検索範囲に入っているエントリを先祖関係記憶部３４の先祖関係表を参照することによって抽出し、結果集合（不図示）に格納する。その後、フィルタ検索手段２７は、結果集合に格納されたエントリについて複合インデックス記憶部３５にアクセスしてそのエントリのディレクトリ情報を取得し、その検索結果を出力装置４に出力する。
【００３６】
以上述べたように、このディレクトリ検索システムでは、フィルタ検索手段２７によってエントリ／アトリビュート記憶部３１よりエントリを検索した後に、その検索されたエントリの中から、スコープ判定手段２８によって、検索範囲に入っているエントリを抽出している。よって、フィルタ検索手段２７において検索されたエントリに中には検索範囲外にあるエントリも含まれている場合があり、それらのエントリの検索が結果的に無駄となり、検索時間が長くなってしまうという問題点があった。
【００３７】
また、このようなアトリビュートによるエントリのフィルタ検索では、エントリのアトリビュートに文字列や数値が含まれていた場合、文字列や数値の全一致検索だけではなく、部分一致検索もすることができるディレクトリ検索システムが要求される。
【００３８】
また、特開平１０−１８７７４５号公報では、エントリのアトリビュートに文字列や数値がフィルタ条件として含まれている場合に、その文字列の部分一致検索を行うことができるディレクトリ検索システムが開示されている。しかしながらこの公報に開示された従来のディレクトリ検索システムでは、アトリビュートの全一致検索用のインデックスと、部分一致検索用のインデックスを別々に備えることが必要となる。さらに、部分一致検索用のインデックスでは、格納されるアトリビュートが膨大な数にのぼるため、インデックスの大きさも大きくなる。そのため、文字列の部分一致検索が可能な従来のディレクトリ検索システムでは、それらのインデックスをできるだけ統合して、インデックスに使用される記憶装置の容量をできるだけ抑制することが課題となっている。
【００３９】
【発明が解決しようとする課題】
上述のような従来のディレクトリ検索システムは以下に示す３つの問題点を有している。
（１） 数種類のキーからデータを検索する場合には複数のインデックスを必要とするため、複数のインデックスを主記憶装置または２次記憶装置上に展開させなければならないので大容量の記憶装置が必要である。また、複数のインデックスを検索するので検索時間が長くなってしまう。
（２） ディレクトリサービスにおいてディレクトリ検索システムを用いてエントリを検索する場合、フィルタ条件に基づいてエントリの検索を行うフィルタ処理と、検索範囲に基づいてエントリの絞り込みを行うスコープ処理とが別々に実行される。そのため、フィルタ処理において検索されたエントリが、検索範囲外である場合があり、フィルタ処理において行われた検索処理が一部無駄となり、検索時間が長くなってしまう。
（３） アトリビュートの部分一致の検索が可能な従来のディレクトリ検索システムでは、アトリビュートの全一致検索用のインデックスと、部分一致検索用のインデックスという複数のインデックスが必要である。また、部分一致検索用のインデックスは、格納されるアトリビュートが膨大な数にのぼるため、インデックスのサイズも大きくなる。よって、アトリビュートの部分一致の検索が可能な従来のディレクトリ検索システムでは、大容量の記憶装置が必要となってしまう。
【００４０】
よって、本発明は、キーが２種類以上指定された場合でも、インデックスを記憶するのに必要な記憶容量を少なくし、検索時間を短縮することができるディレクトリ検索システムを提供することを目的とする。
【００４１】
また、本発明は、検索条件および検索範囲の両方について検索を行わなければならない場合でも、検索時間を短縮することができるディレクトリ検索システムを提供することを目的とする。
【００４２】
また、本発明は、エントリのアトリビュートに文字列が含まれていて、その文字列の部分一致検索を行う場合でも、できるだけインデックスを記憶するのに必要な記憶容量を少なくするディレクトリ検索システムを提供することを目的とする。
【００４３】
【課題を解決するための手段】
上記問題点を解決するために、本発明では、複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索システムであって、
前記各エントリの管理情報と前記各エントリの全ての属性とを前記ディレクトリ階層順に記憶するエントリ／アトリビュート記憶手段と、
エントリを識別するための識別子からエントリの前記ディレクトリ階層における階層番号および階層別番号を導き出すためのインデックスを記憶するエントリインデックス記憶手段と、
検索条件として指定された属性値を満たすエントリの識別子を取得するために前記各エントリの複数の属性から成るマルチキーをキーとする２分探索木から構成されるマルチキーインデックスを記憶するアトリビュートインデックス記憶手段と、
前記エントリインデックス記憶手段および前記アトリビュートインデックス記憶手段を管理するマルチキーインデックス管理手段と、
前記マルチキーインデックス管理手段を介して検索条件を満たすエントリの識別子を前記マルチキーインデックスから取得し前記マルチキーインデックスから取得した識別子に基づいて検索条件を満たすエントリの階層番号および階層別番号を前記マルチキーインデックス管理手段を介して前記エントリインデックス記憶手段から取得し該階層番号および階層別番号に基づいて検索条件を満たすエントリの管理情報を前記エントリ／アトリビュート記憶手段から取得するフィルタ検索手段とを備える。
【００４４】
本発明のディレクトリ検索システムでは、アトリビュートインデックス記憶手段が記憶するインデックスが、複数のキーによって一度に探索可能なマルチキーインデックスとなっているので、複数のインデックスを備える必要がないため、アトリビュートからエントリを検索するためのインデックスに必要な記憶容量を少なくことができる。また、複数のインデックスを検索する必要がないので検索時間を短縮することができる。
【００４５】
本発明の他のディレクトリ検索システムは、複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索システムであって、
前記各エントリの管理情報と前記各エントリの全ての属性とを前記ディレクトリ階層順に記憶するエントリ／アトリビュート記憶手段と、
エントリを識別するための識別子からエントリの前記ディレクトリ階層における階層番号および階層別番号を検索するためのインデックスを記憶するエントリインデックス記憶手段と、
検索条件として指定された属性値を満たすエントリの識別子を取得するために前記各エントリの複数の属性から成るマルチキーをキーとする２分探索木から構成され前記２分探索木の各ノードに格納されているエントリの前記階層番号および前記階層別番号が付与されているマルチキーインデックスを記憶するアトリビュートインデックス記憶手段と、
前記エントリインデックス記憶手段および前記アトリビュートインデックス記憶手段を管理するマルチキーインデックス管理手段と、
前記ディレクトリ階層における検索範囲が指定されていた場合に、検索条件として指定された属性の値に基づいて前記マルチキーインデックス管理手段を介して前記検索条件を満たすエントリを検索する途中に通過する前記各ノードに付与されている階層番号および階層別番号を有するエントリが前記検索範囲に入っているか否かを各エントリの先祖関係からチェックし、該チェックの結果において前記検索範囲に含まれていなかったエントリを検索条件を満たすエントリから除外した後で、残りのエントリが前記検索範囲に含まれているか否かの判定を行うスコープ／フィルタ統合検索手段とを備える。
【００４６】
本発明のディレクトリ検索システムでは、フィルタ検索とスコープ判定の処理を統合するスコープ／フィルタ統合検索手段を備えることにより、フィルタ検索に含まれていてスコープ判定に含まれないエントリにアクセスすることがなくなるため、エントリの検索時間を短縮することができる。
【００４７】
本発明のディレクトリ検索システムでは、マルチキーインデックスの探索時にスコープの絞り込みを行い、スコープの判定処理の負荷を軽減しているため、スコープ判定処理の負荷を軽減してエントリの検索時間を短縮することができる。
本発明の他のディレクトリ検索システムは、指定された文字列の中から所定の文字数の部分文字列をすべて抽出する部分文字列操作手段をさらに備え、
前記アトリビュートインデックス記憶部は前記部分文字列操作手段によって抽出された部分文字列をキーとするマルチキーインデックスを記憶しており、
前記マルチキーインデックス管理手段は、前記検索条件として文字列が含まれていた場合、前記部分文字列操作手段によって該文字列から抽出された少なくとも１つの部分文字列によって前記マルチキーインデックスの探索を行い、各部分文字列毎の前記マルチキーインデックスの探索結果となったエントリのうち、すべての部分文字列についての探索結果に含まれるエントリを検索条件を満たすエントリとする。
【００４８】
本発明のディレクトリ検索システムでは、文字列から所定の文字数の部分文字列を抽出する部分文字列操作手段と、すべての部分文字列の検索結果に含まれるエントリを検索結果であると判断するマルチキーインデックス管理手段とを備えることによって、同一のインデックスで全文字列および部分文字列の検索を行うことができるため、インデックスに必要な記憶容量を少なくすることができる。
【００４９】
【発明の実施の形態】
次に、本発明の実施形態のディレクトリ検索システムについて図面を参照して詳細に説明する。全図において、同一の符号がつけられている構成要素は、すべて同一のものを示す。
【００５０】
（第１の実施形態）
まず、本発明の第１の実施形態のディレクトリ検索システムについて説明する。本実施形態のディレクトリ検索システムは、図２０の会社４０１の組織を管理するデータベースに用いられているものとする。図１は、本実施形態のディレクトリ検索システムの構成を示すブロック図である。図１に示すように、本実施形態のディレクトリ検索システムは、入力装置１とデータ処理装置２と記憶装置３と出力装置４とから構成されている。
【００５１】
入力装置１は、キーボード等であり、利用者からの要求を入力し、その要求をデータ処理装置２に出力している。出力装置４は、ディスプレイ装置や印刷装置等の出力装置であり、データ処理装置３から処理の終了通知を受け取って処理結果を表示する。データ処理装置２は、エントリ管理手段２１と、マルチキーインデックス管理手段２２と、フィルタ検索手段２３と、スコープ判定手段２４とを備えている。また、記憶装置３は、エントリインデックス記憶部３１とアトリビュートインデックス記憶部３２とエントリ/アトリビュート記憶部３３とを備えている。
【００５２】
エントリ/アトリビュート記憶部３３は、全てのエントリの管理情報と各エントリが有する全てのアトリビュートとを記憶している。各エントリは、ディレクトリ階層の形態で記憶されており、ディレクトリのルートであるベースエントリの管理情報の格納場所と各エントリの階層番号および階層別番号が分かれば、各エントリの管理情報の格納場所を特定でき、各エントリの管理情報にアクセスすることができる。本実施形態のディレクトリ検索システムでは、図２０のディレクトリ階層の各エントリの管理情報と各エントリが有する全てのアトリビュートとを記憶している。
【００５３】
エントリインデックス記憶部３１は、エントリを識別するための識別子（以降ＤＮ：Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ）に基づいて作成されたインデックスを記憶している。このインデックスを検索することによって各エントリの階層番号と階層別番号とを取得することができる。
【００５４】
アトリビュートインデックス記憶部３２は、各エントリが有するアトリビュートをキーとして構成されたインデックスを記憶している。このインデックスは、前述のｈＢ ｔｒｅｅ方式を用いたマルチキーインデックスとなっており、複数のアトリビュートをキーとしてエントリを検索することができるようになっている。本実施形態のディレクトリ検索システムでは、アトリビュートインデックス記憶部３２に記憶されるマルチキーインデックスは、図１８の様になる。
【００５５】
エントリ管理手段２１は、入力装置１からエントリの登録・削除・ＩＤ更新要求やアトリビュートの登録・削除・更新要求を入力した場合、エントリ／アトリビュート記憶部３３に対してエントリやアトリビュートの登録・削除・更新を行う。さらに、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介して、エントリインデックス記憶部３１およびアトリビュートインデックス記憶部３２の登録、削除、更新を行う。
【００５６】
フィルタ検索手段２３は、入力装置１からエントリの検索要求を入力した場合、指定されたフィルタ条件を満たすエントリの検索を行う。スコープ判定手段２４は、フィルタ検索手段２３によって検索されたエントリが、指定された検索範囲であるスコープ条件を満たすかどうかを判定する。スコープ判定手段２４は、エントリ／アトリビュート記憶部３３のエントリのディレクトリ階層を参照することによってその判定を行う。
【００５７】
マルチキーインデックス管理手段２２は、フィルタ検索手段２３やエントリ管理手段２１からの要求により、エントリインデックス記憶部３１やアトリビュートインデックス記憶部３２が記憶するインデックスの管理や探索を行う。
【００５８】
次に、本実施形態のディレクトリ検索システムの動作について図２、図３、図１８を参照して詳細に説明する。図２は、エントリやアトリビュートの更新要求が入力された場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【００５９】
利用者が入力装置１に対し、エントリやアトリビュートの更新要求を入力した場合、入力装置１はその要求をエントリ管理手段２１へ出力する。すると、エントリ管理手段２１は、その要求がエントリの更新要求であるか否かを判定する（ステップＡ１）。もし、その要求がエントリの更新要求であれば、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１が記憶するインデックスを更新する（ステップＡ２）。その後、エントリ管理手段２１は、エントリ／アトリビュート記憶部３３に記憶されているエントリの更新を行う（ステップＡ３）。ステップＡ２、Ａ３の処理終了後、エントリ管理手段２１は処理終了を出力装置４に通知し、出力装置４は処理結果を出力する（ステップＡ４）。
【００６０】
ステップＡ１において、入力装置１からの要求がエントリの更新要求ではない場合、その要求はアトリビュートの更新要求である。エントリ管理手段２１は、アトリビュートインデックス記憶部３２において更新しようとするアトリビュートにインデックスが付与されているか否かを判定する（ステップＡ５）。更新しようとするアトリビュートにインデックスが付与されていれば、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介してアトリビュートインデックス記憶部３２に記憶されるアトリビュートのインデックスを更新する（ステップＡ６）。エントリ管理手段２１は、エントリ／アトリビュート記憶部３３に記憶されるアトリビュートを更新する（ステップＡ７）。そして、ステップＡ６、Ａ７の処理終了後、エントリ管理手段２１は処理終了を出力装置４に通知し、出力装置４は処理結果を表示する（ステップＡ４）。
【００６１】
ステップＡ５において、更新しようとするアトリビュートにインデックスが付与されていない場合、ステップＡ６の処理は実行されずに、ステップＡ７において、エントリ／アトリビュート記憶部３３のアトリビュートの更新のみが行われる。
【００６２】
ステップＡ６において、アトリビュートのインデックスを更新する際の動作について説明する。前述のように、アトリビュートインデックス記憶部３２は、図１８に示す社員の名前と年齢とをキーとしたマルチキーインデックスを記憶している。なお、更新されるアトリビュートは、社員の名前と年齢であり、更新されるアトリビュート値は（Ｏｚａｗａ、２４）であるとする。
【００６３】
このマルチキーインデックスでは、ブリックａから探索が開始される。ブリックａでは、「Ｏ」とｘ３（Ｓ）とが比較され、「２４」とｙ１（２８）とが比較されることによって、ブリックｂが選択される。ブリックｂでは、「Ｏ」とｘ２（Ｉ）とが比較され、リーフ２０５が選択される。リーフ２０５に（Ｏｚａｗａ、２４）のアトリビュート値を有するエントリのＤＮが格納される。
【００６４】
図３は、エントリを検索する場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。利用者が入力装置１に対しエントリの検索要求を入力した場合、入力装置１はその要求をフィルタ検索手段２３へ出力する。フィルタ検索手段２３は、エントリの検索要求が入力されるとマルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１のインデックスを探索する（ステップＢ１）。そのインデックスのルートであるベースエントリのエントリ／アトリビュート記憶部３３における格納場所を取得する（ステップＢ２）。そして、フィルタ検索手段２３はフィルタ条件が含まれているか否かを調べる（ステップＢ３）。もし、検索要求にフィルタ条件が含まれていれば、フィルタ検索手段２３は、フィルタ条件となっているアトリビュートにインデックスが付与されているかを調べる（ステップＢ６）。
【００６５】
フィルタ条件となっているアトリビュートにインデックスが付与されていれば、フィルタ検索手段２３は、マルチキーインデックス管理手段２２を介してそのフィルタ条件のアトリビュートの値によってマルチキーインデックスの探索を行い、フィルタ条件を満たすエントリのＤＮを得る。（ステップＢ７）。そして、フィルタ検索手段２３は、マルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１が記憶するインデックスを探索してステップＢ７において検索されたエントリのＤＮからそのエントリの階層番号と階層別番号を得る（ステップＢ８）。フィルタ検索手段２３は、エントリ／アトリビュート記憶部３３からステップＢ８において得られたベースエントリの格納場所とエントリの階層番号および階層別番号とからエントリの格納場所を割り出し、そのエントリの情報を取得する（ステップＢ９）。
【００６６】
ステップＢ６において、フィルタ条件となっているアトリビュートにインデックスが付与されていない場合には、フィルタ検索手段２３は、データベースの検索機能などを利用して、エントリ／アトリビュート記憶部３３からフィルタ条件を満たすエントリの検索を行って（ステップＢ１０）、ステップ９に移行する。
ステップＢ９の後およびステップＢ３において検索要求にフィルタ条件が含まれていなかったときは、本実施形態のディレクトリ検索システムの動作はスコープ判定手段２４に移行する。スコープ判定手段２４は、検索要求にスコープ条件が含まれているかを調べる（ステップＢ４）。スコープ判定手段２４は、入力装置１から入力された検索要求にスコープ条件が含まれていれば、エントリ／アトリビュート記憶部３３のディレクトリ階層をたどってステップＢ９で取得されたエントリが、スコープ条件を満たしているか否かの判定を行う（ステップＢ１１）。そして、スコープ判定手段２４は、スコープ条件を満たしているエントリをエントリ／アトリビュート記憶部３３にアクセスして取得し、検索結果を出力装置４に出力する（ステップＢ５）。
【００６７】
ステップＢ７において、アトリビュートのインデックスを更新する際の動作について詳細に説明する。前述のように、アトリビュートインデックス記憶部３２は、図１８に示す社員の名前と年齢とをキーとしたマルチキーインデックスを記憶している。フィルタ条件は、名前がＡかＫで始まることと年齢が３０歳以下であることとする。
【００６８】
マルチキーインデックスでは、ブリックａから探索が開始される。ブリックａでは、ルートにおいて「Ａ」および「Ｋ」とｘ３（Ｓ）とが比較され、左の枝が選択される。続いて、次のノードで「３０歳以下」とｙ１（２８）とが比較され、ここでは両者の大小関係が不明なので両方の枝が選択される。したがって、ブリックａでは、ブリックｂとブリックｃの両方が選択される。
【００６９】
ブリックｂでは、ルートにおいて、「Ａ」および「Ｋ」とｘ２（Ｉ）とが比較され、ここでは両者の関係が不明なので両方の枝が選択される。したがって、ブリックｂでは、リーフＤ、Ｅが選択される。
【００７０】
ブリックｂでは、ルートにおいて「Ａ」および「Ｋ」とｘ３（Ｓ）とが比較され、左の枝が選択される。続いて、次のノードで「３０歳以下」とｙ１（２８）とが比較され、ここでは両者の大小関係が不明なので両方の枝が選択される。しかし、左の枝には外部ノード（ｅｘｔ）が指定されているので、左の枝についての探索はここでストップする。右の枝については、「Ａ」および「Ｋ」とｘ１（Ａ）とが比較され、リーフＢが選択される。そして、選択されたリーフＢ、Ｄ、Ｅに登録されたエントリの中から、フィルタ条件を満たす（Ａｏｋｉ、３２）が抽出され、この（Ａｏｋｉ、３２）のエントリのＤＮがフィルタ検索手段２３に出力される。
【００７１】
本実施形態のディレクトリ検索システムでは、各エントリのアトリビュートに基づいて構成されるインデックスが、ｈＢ ｔｒｅｅ方式のマルチキーインデックスであるため、複数のアトリビュートがフィルタ条件として指定されたときでも、複数のインデックスを保持する必要がなくなる。そのため、本実施形態のディレクトリ検索システムでは、インデックスを記憶するための記憶容量を小さくすることができる。
【００７２】
また、本実施形態のディレクトリ検索システムでは、前述のように各エントリのアトリビュートに基づいて構成されるアトリビュートのインデックスが、複数のアトリビュートをキーとするｈＢ ｔｒｅｅ方式のマルチキーインデックスとなっている。そのため、本実施形態のディレクトリ検索システムでは、複数のアトリビュートがフィルタ条件として指定されたときでもインデックスの探索を１回で済ませることができる。そのため、本実施形態のインデックスシステムでは、複数のアトリビュートを探索する場合に複数のインデックスを検索したり何度も同じエントリにアクセスする必要がなくなるため、エントリの検索時間を短縮することができる。
【００７３】
（第２の実施形態）
次に、本発明の第２の実施形態のディレクトリ検索システムについて説明する。図４は、本実施形態のディレクトリ検索システムの構成を示すブロック図である。図４を参照すると、本実施形態のディレクトリ検索システムは、入力装置１と、データ処理装置５と、記憶装置６と、出力装置４とから構成されている。データ処理装置５は、図１に示すデータ処理装置２が備えるフィルタ検索手段２３とスコープ判定手段２４とが、スコープ／フィルタ統合検索手段２５に置き換えられたものである。また、記憶装置６は、図１に示す記憶装置３の構成要素に加え、先祖関係記憶部３４をさらに備えている。
【００７４】
アトリビュートインデックス記憶部３２は、図５に示すｈＢ ｔｒｅｅ形式のマルチキーインデックスを備える。このマルチキーインデックスは、ノード５０１〜５０３と、リーフ２０４〜２０８とから構成される。ノード５０１〜ノード５０３は、それぞれがブリックａ、ｂ、ｃである。ブリックａ、ｂ、ｃ内のインデックスの各ノードには、各ノードに格納されているキーの値を有するエントリの階層番号および階層別番号が付与されている。
【００７５】
スコープ／フィルタ統合検索手段２５は、マルチキーインデックス管理手段２２を介して指定されたフィルタ条件に基づいてアトリビュートインデックス記憶部３２に記憶されているマルチキーインデックスの探索を行うとともに、スコープ条件が指定されている場合には先祖関係記憶部３４が記憶する先祖関係表を用いてスコープ判定も同時に行う。また、スコープ／フィルタ統合検索手段２５は、スコープ判定を行った結果を記録するためのスコープ表を備える。図６は、本実施形態のディレクトリ検索システムにおけるスコープ／フィルタ統合検索手段２５が備えるスコープ表である。スコープ表の各行は、図２０のディレクトリ階層の各階層番号を表しており、スコープ表の各列は、スコープ左外（Ｌｅｆｔ−Ｏｕｔ、以降Ｌ−Ｏ）、スコープ右外（Ｌｅｆｔ−Ｉｎ、以降Ｌ−Ｉ）、スコープ右内（Ｒｉｇｈｔ−Ｉｎ、以降Ｒ−Ｉ）、スコープ右外（Ｒｉｇｈｔ−Ｏｕｔ、以降Ｒ−Ｏ）とに区切られている。
【００７６】
エントリの階層別番号がＬ−Ｏ、Ｒ−Ｏに書き込まれているということは、そのエントリはスコープ条件の範囲外にあることを意味している。また、エントリの階層別番号がＬ−Ｉ、Ｒ−Ｉに書き込まれているということは、そのエントリはスコープ条件の範囲内にあることを意味している。
【００７７】
本実施形態のディレクトリ検索システムの動作を図７、図８を参照して詳細に説明する。図７は、エントリやアトリビュートの更新要求があった場合のディレクトリ検索システムの動作を示すフローチャートである。なお、図７におけるステップＡ１、Ａ４〜Ａ７の動作は、図２におけるエントリ管理手段２１の動作と同一のため、説明は省略する。
【００７８】
ステップＡ１において、利用者からの要求がエントリの更新である場合、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１に記憶されるエントリの更新を行う（ステップＡ２）。そして、エントリ管理手段２１は、先祖関係記憶部３４のエントリの更新にともなって変化したエントリの先祖関係に基づいて先祖関係表を更新する（ステップＣ１）。その後、エントリ管理手段２１は、エントリ／アトリビュート記憶部３３に記憶されるエントリの更新を行う（ステップＡ３）。
【００７９】
図８は、エントリの検索を行う場合の本実施形態のディレクトリ検索システム動作を示すフローチャートである。ステップＢ１、Ｂ２、Ｂ６、Ｂ９、Ｂ１０における動作は、図３に示す動作と同一であるため、これらのステップにおける動作の説明は省略する。
【００８０】
ステップＢ３で検索要求にフィルタ条件が含まれており、ステップＢ６でフィルタ条件となっているアトリビュートにインデックスが付与されている場合には、スコープ／フィルタ統合検索手段２５は、検索要求にスコープ条件が含まれているかを調べる（ステップＤ１）。
【００８１】
もし、検索要求にスコープ条件が含まれている場合、スコープ／フィルタ統合検索手段２５は、マルチキーインデックス管理手段２２を介してフィルタ条件に基づいてアトリビュートインデックス記憶部３２が記憶するインデックスを探索するとともに、インデックス探索途中で先祖関係記憶部３４の先祖関係表を参照してインデックスの各ノードの分岐条件となっているアトリビュート値を有するエントリがスコープの範囲内にあるエントリであるかどうかを調べ、スコープ表を作成する（ステップＤ２）。ステップＤ２においてフィルタ条件を満すエントリを検索後、それらのエントリの中からスコープ条件を満たすエントリをスコープ表から求める。スコープ表からスコープ条件を満たしているかどうか判断できないエントリについては、先祖関係記憶部３４の先祖関係表を参照してスコープ判定を行う（ステップＤ３）。
【００８２】
ステップＤ１においてスコープ条件が含まれていない場合には、第１の実施形態のディレクトリ検索システムと同様にアトリビュートインデックス記憶部３２のインデックスを探索のみを行う（ステップＢ７）。ステップＤ３またはステップＢ７の終了後、ステップＤ３またはステップＢ７において検索されたエントリの階層番号および階層別番号をエントリインデックス記憶部３１のインデックスを探索して得る（ステップＢ８）。そして、エントリ／アトリビュート記憶部３３から検索結果のエントリの管理情報を取得する（ステップＤ４）。
【００８３】
また、ステップＢ４において、検索要求にスコープ条件が含まれている場合には、スコープ／フィルタ統合手段２５は、先祖関係記憶部３４の先祖関係表を参照してスコープの判定を行う（ステップＤ３）。ステップＤ３、Ｂ４、Ｄ４終了後、スコープ／フィルタ統合手段２５は、エントリ／アトリビュート記憶部３３にアクセスして最終的な検索結果のエントリの管理情報を取得し、出力装置４にそれらの管理情報を出力する（ステップＢ５）。
【００８４】
アトリビュートインデックス記憶部３２の記憶するマルチキーインデックスでは、前述のように、ブリック５０１〜５０３のインデックスのノードには、各ノードの分岐条件となっているキー値をアトリビュートとして有するエントリの階層番号および階層別番号が付与されている。
【００８５】
ステップＤ２において、スコープ／フィルタ統合検索手段２５は、フィルタ条件となっているアトリビュートをキーとするインデックスがアトリビュートインデックス記憶部３２に存在している場合に、マルチキーインデックス管理手段２２を介してアトリビュートインデックス記憶部３２に記憶されるインデックスを探索する。そして、各ブリックのインデックスのノードを通過する際に、そのノードに付与されている階層番号および階層別番号を有するエントリが、スコープ条件の範囲内かどうかを先祖関係記憶部３４の先祖関係表を参照して調べ、その結果に基づいてスコープ表を更新する。
【００８６】
例えば、フィルタ条件が年齢３０歳以上であることであり、スコープ条件が営業部門であるとする。スコープ／フィルタ統合検索手段２５は、アトリビュートインデックス記憶部３２のマルチキーインデックスを年齢３０歳以上で探索する。スコープ／フィルタ統合検索手段２５は、その探索途中でノードを通過する際に、そのノードに付与されている階層番号および階層別番号を有するエントリがスコープ条件となっている営業部門に属しているかどうかをスコープ表にチェックしていく。階層番号４および階層別番号１のＳａｔｏ氏と階層番号４および階層別番号２のＥｎｄｏ氏とは、営業部門に属しているので、スコープ条件の範囲内にある。したがって、スコープ／フィルタ統合検索手段２５は、スコープ表の階層番号４およびＬ−Ｉ、Ｒ−Ｉのところに階層別番号１、２を書き込む。さらに、階層番号４および階層別番号５のＡｏｋｉ氏は、営業部門に属していないので、スコープ条件の範囲外である。したがって、スコープ／フィルタ統合検索手段２５は、スコープ表の階層番号４でＲ−Ｏのところに階層別番号５が書き込む。以上の結果から、階層番号４における各エントリのうち、階層別番号が１、２であるエントリはスコープ条件の範囲内であり、階層別番号が５であるエントリはスコープ条件の範囲外であることがわかる。
【００８７】
フィルタ条件によるマルチキーインデックスの探索は、最終的にリーフＡ、Ｂ、Ｃが選択され、そこに登録されているエントリから３０歳以上のＡｏｋｉ氏、（階層別番号５）、Ｎａｋａｉ氏（階層別番号８）、Ｕｅｄａ氏（階層別番号３）が抽出される。この中からスコープ条件の範囲外である階層別番号５のＡｏｋｉ氏は検索結果から除外される。
【００８８】
本実施形態のディレクトリ検索システムでは、フィルタ条件を満たすエントリの検索中にスコープの絞り込みを行うことで、スコープ判定の負担を軽減することができる。また、本実施形態のディレクトリ検索システムでは、フィルタ検索とスコープ判定の処理を統合することにより、結果的にスコープ判定に含まれないエントリにアクセスすることがなくなるため、エントリの検索時間を短縮することができる。
【００８９】
（第３の実施形態）
次に、本発明の第３の実施形態のディレクトリ検索システムについて説明する。図９は、本実施形態のディレクトリ検索システムの構成を示すブロック図である。本実施形態のディレクトリ検索システムは、入力装置１と、出力装置４と、記憶装置６と、データ処理装置７とから構成されている。データ処理装置７は図４のデータ処理装置５の構成要素に加えて、部分文字列操作手段２６を備えている。部分文字列操作手段２６は、マルチキーインデックス管理手段２２からの指示により、文字列を分解する。
【００９０】
本実施形態のディレクトリ検索システムでは、名前の部分一致検索を行うため、各社員の名前から抽出された３文字の部分文字列をキーとする。図１０は、図２０のディレクトリ階層における社員の名前から抽出された３文字の部分文字列と年齢とから成るマルチキーの分布状態を示すマップである。このマップは、縦軸が年齢で、横軸が名前の先頭のアルファベットとなっている。
【００９１】
図１０に示すように、アルファベットＳをｘ３とし、アルファベットＩをｘ２とし、アルファベットＥをｘ１とし、年齢２８をｙ１とする。マップ上のエリアは、年齢２８以上かつ名前の頭文字がＡ〜Ｄの領域７０１と、年齢２８以上かつ名前の頭文字がＥ〜Ｒの領域７０２と、年齢２８未満で名前の頭文字がＡ〜Ｈの領域７０３と、年齢２８未満で名前の頭文字がＩ〜Ｒの領域７０４と、名前の頭文字がＳ〜Ｚの領域７０５とに分割されている。
【００９２】
図１１は、本実施形態のディレクトリ検索システムにおけるアトリビュートインデックス記憶部３２のマルチキーインデックスを示す図である。このマルチキーインデックスは、ノード６０１〜６０３と、リーフ６０４〜６０８とから構成されている。ノード６０１〜６０３は、それぞれがブリックａ、ブリックｂ、ブリックｃである。図１１のｈＢ ｔｒｅｅでは、図１０におけるマップの各領域を元にブリックａ、ｂ、ｃを構成する。ブリックａは、マップ全体を指すものであるとし、ブリックｃは、領域７０１、７０２、７０５を指すものであるとし、ブリックｂは、領域７０３、７０４を指すものであるとする。
【００９３】
このマルチキーインデックスは、まずフィルタ条件として指定されたアトリビュートの値が、マップ上のどの領域の属するかを探索する。ブリックａでは、ｘ３（Ｓ）とｙ１（２８）とを分岐条件として、フィルタ条件として指定されたアトリビュートの値が、領域７０１、７０２、７０５に含まれるか領域７０３、７０４に含まれるかを切り分ける。そして、ブリックｂでは、フィルタ条件として指定されたアトリビュートの値の含まれる領域が、領域７０３なのか領域７０４なのかを切り分ける。ブリックｃでは、フィルタ条件として指定されたアトリビュートの値の含まれる領域が、領域７０１なのか領域７０２領域７０５なのかを切り分ける。
【００９４】
リーフ６０４〜６０８にはそれぞれ領域７０３、７０４、７０１、７０２、７０５に含まれる各要素のＤＮが登録されている。同一のリーフ内に格納され、同じエントリのＤＮを指す要素は、マルチキーインデックス管理手段２２によってキー併合されて登録されている。例えば、各マルチキー（ＩＩＪ、２０）、（ＩＪＩ、２０）、（ＪＩＭ、２０）、（ＩＭＡ、２０）は、同じリーフ６０８に格納され、同じエントリであるＩｉｊｉｍａ氏を指すので（ＩＩＪ＋ＩＪＩ＋ＪＩＭ＋ＩＭＡ、２０）というふうにマルチキーインデックス管理手段２２によってキー併合されて登録されている。
【００９５】
次に、本実施形態のディレクトリ検索システムの動作を図１２、図１３を参照して詳細に説明する。図１２は、エントリまたはアトリビュートの更新を行う場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。図１２のステップＡ１〜Ａ５、Ａ７、Ｃ１の動作は、第２の実施形態のディレクトリ検索システムにおけるエントリ管理手段２１の動作と同一であるため、これらのステップの動作の説明は省略する。
【００９６】
ステップＡ５において、利用者からの要求がインデックスが付与されているアトリビュートの更新要求であった場合、マルチキーインデックス管理手段２１は、アトリビュートに文字列が含まれているかを調べる（ステップＥ１）。
【００９７】
もし含まれていれば、マルチキーインデックス管理手段２２は、部分文字列操作手段２６を介して文字列から３文字の部分文字列を抽出する（ステップＥ２）。例えば、更新要求のあったアトリビュートの値が、（Ｔｓｕｊｉ、３０）であった場合、文字列「ｔｓｕｊｉ」から「ｔｓｕ」と「ｓｕｊ」と「ｕｊｉ」を抽出する。すると、マルチキーインデックス管理手段２２は、（ｔｓｕ、３０）、（ｓｕｊ、３０）、（ｕｊｉ、３０）の３つのマルチキーを作成し、これらのマルチキーによってアトリビュートインデックス記憶部のマルチキーインデックスを探索する。そして、各マルチキーのうち、探索結果が同一のリーフとなったマルチキーがある場合、マルチキーインデックス管理手段２２は、それらのマルチキーのキー併合を行いアトリビュートインデックス記憶部３２のインデックスを更新する（ステップＥ３）。例えば、上述のマルチキー（ｔｓｕ、３０）、（ｓｕｊ、３０）、（ｕｊｉ、３０）は、すべて、リーフ６０８に格納されるようになるので、（ｔｓｕ＋ｓｕｊ＋ｕｊｉ、３０）のように、キー併合を行って（ｔｓｕｊｉ、３０）のエントリのＤＮをリーフ６０８に格納する。
【００９８】
その後、マルチキーインデックス管理手段２２は、エントリ／アトリビュート記憶部３３に新しく追加されたエントリのアトリビュートを更新する（ステップＡ７）。ステップＥ１において、指定されたアトリビュートに部分文字列が含まれていなかった場合、マルチキーインデックス管理手段は、そのアトリビュートに基づいて、アトリビュートインデックス記憶部３２に格納されたインデックスを更新し（ステップＡ６）、ステップＡ７に進む。
【００９９】
図１３は、エントリの検索要求があった場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。図１３において、ステップＢ１〜Ｂ１０、Ｄ１〜Ｄ４の動作は、図８におけるそれらのステップの動作と同一であるため、それらのステップの動作の説明は省略する。
【０１００】
ステップＢ３でフィルタ条件が指定されており、ステップＢ６でインデックスが付与されていた場合、マルチキーインデックス管理手段２２は、部分文字列のインデックスが含まれているかを調べる（ステップＦ１）。もし含まれていれば、部分文字列操作文字手段２６は、その部分文字列から所定の文字数の部分文字列を抽出する（ステップＦ２）。例えば、「ＮＡＫＡ」という文字列を含む名前を持つエントリを検索する場合、所定の文字数が３文字であるとすると、部分文字列操作手段２６は「ＮＡＫＡ」から「ＮＡＫ」および「ＡＫＡ」を抽出する。
その後、本実施形態のインデックスシステムの動作は、スコープ／フィルタ統合検索手段２５に移行する。ステップＦ１において部分文字列のインデックスが含まれていない場合には、ステップＦ２の処理はスキップされる。
【０１０１】
ブリックａ、ｂ、ｃ内のインデックスの内部ノードには、第２の実施形態のディレクトリ検索システムと同様にスコープの絞り込みで使用されるエントリの階層番号および階層別番号が付与されている。リーフ６０４〜６０８には、キー併合により同じエントリを指しているマルチキーがキー併合されて管理されている。「ＮＡＫ」による探索では、リーフ６０５と６０７とにたどりついて（ＮＡＫ＋ＫＡＩ、３７）のエントリが選択される。［ＡＫＡ］による探索ではリーフ６０４と６０６にたどりついて（ＡＫＡ、３７）のエントリが選択される。これらのエントリは、同じＮａｋａｉ氏を示すので、Ｎａｋａｉ氏が検索結果となって、出力装置４に出力される。
【０１０２】
また、本実施形態のディレクトリ検索システムでは、「Ｎａｋａｉ」のような全文字列検索を行う場合でも、同様な動作で上述のマルチキーインデックスを探索してＮａｋａｉ氏の情報を取得することができる。
【０１０３】
以上述べたように、本実施形態のディレクトリ検索システムでは、文字列から所定の文字数の部分文字列を抽出する部分文字列操作手段２６と、すべての部分文字列の検索結果に含まれるエントリを検索結果であると判断するマルチキーインデックス管理手段２２とを備えることによって、同一のインデックスで全文字列および部分文字列の検索を行うことができるため、インデックスの記憶に要する記憶容量を少なくすることができる。
【０１０４】
また、本実施形態のディレクトリ検索システムでは、部分文字列をキーとするインデックスについて、同一のリーフの登録される同一のエントリについてのマルチキーがあった場合には、それらのマルチキーをキー併合するため、リーフに登録されるマルチキーの数を減らすことができるため、インデックスを記憶するための記憶容量を小さくすることができる。
【０１０５】
なお、上記第１、第２、第３の実施形態のディレクトリ検索システムでは、アトリビュートインデックス記憶部が格納するインデックスをｈＢ ｔｒｅｅの形態としたマルチキーインデックスであるとして構造および動作を説明したが、本発明はこれに限定されるものではなく、マルチキーインデックスをｋ−ｄ ｔｒｅｅまたは他の形態のマルチキーインデックスとしても良い。
【０１０６】
また、図１４に示すように、第１、第２、第３の実施形態のディレクトリ検索システムは、データ更新またはデータ検索を実行するためのプログラムを記録した記録媒体７を備えていてもよい。
【０１０７】
第１の実施形態のディレクトリ検索システムでは、記録媒体７は、フィルタ条件とを満たすエントリをマルチキーインデックスから検索する処理と、エントリやアトリビュートの登録や削除や更新が行われる場合に、ディレクトリ階層およびマルチキーインデックスに対しても登録や削除や更新を行う処理とを行うプログラムを記録している。
【０１０８】
また、第２の実施形態のディレクトリ検索システムでは、記憶媒体７は、ディレクトリ階層におけるスコープ条件が指定されていた場合にフィルタ条件を満たすエントリをマルチキーインデックスを検索する途中に通過する各ノードに付与されている階層番号および階層別番号を有するエントリがスコープ条件に入っているか否かを各エントリの先祖関係からチェックする処理と、そのチェックの結果においてスコープ条件に含まれていなかったエントリをフィルタ条件を満たすエントリから除外した後で、残りのエントリがスコープ範囲に含まれているか否かの判定を行う処理と、利用者からエントリの登録や削除や更新が行われた場合には、ディレクトリ階層の登録や削除や更新を行うとともにマルチキーインデックスの２分探索木の各ノードに付与されている階層番号および階層別番号の登録や削除や更新を行う処理とを行うプログラムを記録している。
【０１０９】
また、第３の実施形態のディレクトリ検索システムでは、記録媒体７は、検索条件として指定された属性値が文字列であった場合、その文字列の中から所定の文字数の部分文字列をすべて抽出する処理と、
フィルタ条件として指定された属性値が文字列であった場合にその文字列から抽出された少なくとも１つの部分文字列によって所定の文字数の部分文字列をキーの１つとするマルチキーインデックスの探索を行い、各部分文字列毎のマルチキーインデックスの探索結果となったエントリのうちすべての部分文字列についての探索結果に含まれるエントリをフィルタ条件を満たすエントリとする処理と、利用者から属性となっている文字列の更新要求があった場合にその文字列から抽出された所定の文字数の部分文字列のうちの探索結果が同一になる部分文字列についてはキー併合を行ってその部分文字列が指すエントリの識別子を格納する場所を同一とする処理とを行うためのプログラムを記録している。記録媒体７としては磁気ディスク、半導体メモリまたはその他の記録媒体が用いられる。
【０１１０】
【発明の効果】
以上述べたように、本発明のディレクトリ検索システムは、以下に示す３つの効果を有している。
（１） アトリビュートインデックス記憶部が記憶するインデックスが、複数のキーによって一度に探索可能なマルチキーインデックスとなっているため、アトリビュートからエントリを検索するためのインデックスを記憶するのに必要な記憶容量を少なくことができる。また、複数のインデックスを検索する必要がないので、検索時間を短縮することができる。
（２） マルチキーインデックスの探索時にスコープの絞り込みを行い、スコープの判定処理の負荷を軽減しているため、スコープ判定処理の負荷を軽減してエントリの検索時間を短縮することができる。また、フィルタ検索とスコープ判定の処理を統合することにより、結果的にスコープ判定に含まれないエントリにアクセスすることがなくなるため、エントリの検索時間を短縮することができる。
（３） 文字列から所定の文字数の部分文字列を抽出する部分文字列操作手段と、すべての部分文字列の検索結果に含まれるエントリを検索結果であると判断するマルチキーインデックス管理手段とを備えることによって、同一のインデックスで全文字列および部分文字列の検索を行うことができるため、インデックスを記憶するのに必要な記憶容量を少なくすることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態のディレクトリ検索システムの構成を示すブロック図である。
【図２】エントリやアトリビュートの更新要求が入力された場合の本発明の第１の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図３】エントリを検索する場合の本発明の第１の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図４】本発明の第２の実施形態のディレクトリ検索システムの構成を示すブロック図である。
【図５】本発明の第２の実施形態のディレクトリ検索システムにおけるアトリビュートインデックス記憶部が記憶するマルチキーインデックスを示す図である。
【図６】本発明の第２の実施形態のディレクトリ検索システムにおけるスコープ／フィルタ検索手段が記憶するスコープ表を示す図である。
【図７】エントリまたはアトリビュートの更新を行う場合の本発明の第２の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図８】エントリの検索を行う場合の本発明の第２の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図９】本発明の第３の実施形態のディレクトリ検索システムの構成を示すブロック図である。
【図１０】本発明の第３の実施形態のディレクトリ検索システムにおけるアトリビュートインデックス記憶部が記憶するマルチキーインデックスを示す図である。
【図１１】ある会社の社員の名前の部分文字列を抽出した場合の各部分文字列と年齢とから構成されるマルチキーの分布を示すマップを示す図である。
【図１２】エントリまたはアトリビュートを更新する場合の本発明の第３の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図１３】本発明の第３の実施形態のディレクトリ検索システムのエントリまたはアトリビュートの検索時における動作を示すフローチャートである。
【図１４】本発明の第１、第２、第３の実施形態のディレクトリ検索システムが記録媒体を備えている場合の構成を示すブロック図である。
【図１５】特開平３−７００４９号公報に開示されたディレクトリ検索システムの構成を示すブロック図である。
【図１６】ｋ−ｄ ｔｒｅｅの基本的な構成を示す図である。
【図１７】ある会社の社員の名前と年齢とから構成されるマルチキーの分布状態を示すマップである。
【図１８】ある会社の社員の構成をｈＢ ｔｒｅｅの形態で表した図である。
【図１９】特願平１１−４３２５９号出願に記載された従来のディレクトリ検索システムの構成を示すブロック図である。
【図２０】ある会社の組織をディレクトリ階層で表す図である。
【図２１】従来のディレクトリ検索システムの先祖関係記憶部が記憶する先祖関係表を示す図である。
【符号の説明】
１ 入力装置
２、５、７、８ データ処理装置
３、６、９ 記憶装置
４ 出力装置
２１ エントリ管理手段
２２ マルチキーインデックス管理手段
２３、２７ フィルタ検索手段
２４、２８ スコープ判定手段
２５ スコープ／フィルタ統合検索手段
２６ 部分文字列操作手段
３１ エントリインデックス記憶部
３２ アトリビュートインデックス記憶部
３３ エントリ／アトリビュート記憶部
３４ 先祖関係記憶部
３５ 複合インデックス記憶部
１０１〜１０８ ノード
２０４〜２０８、６０４〜６０８ リーフ
２０１〜２０３、５０１〜５０３、６０１〜６０３ ノード
３０１〜３０５、７０１〜７０５ 領域
４０１ 会社
４０２ 営業部門
４０３ 開発部門
４０４ 国内営業課
４０５ 海外営業課
４０６ 企画課
４０７ 製造課
４０８〜４１５ 社員
１００１ 処理開始指示装置
１００２ ディレクトリ情報処理手段
１００３ 併合インデックス作成指示手段
１００４ 併合インデックス読込指示手段
１００５ 併合インデックス作成手段
１００６ 併合インデックス読込手段
１００７ 作業ファイル
１００８ 併合インデックス
１００９ ディレクトリファイル
１０１０ 利用者インデックス
１０１１ グループ共有インデックス
１０１２ システム共有インデックス
１０１３ サブファイル群
Ａ１〜Ａ７、Ｂ１〜Ｂ１１、Ｃ１ ステップ
Ｄ１〜Ｄ４、Ｅ１〜Ｅ３、Ｆ１、Ｆ２ ステップ
【発明の属する技術分野】
本発明は、データベースなどの検索を行うディレクトリ検索システムおよび方法、ディレクトリ検索用プログラムを記録したコンピュータ読み取り可能な記録媒体に関し、特に、ディレクトリサービスにおいてエントリを検索するディレクトリ検索システムおよび方法、インデックス用プログラムを記録したコンピュータ読み取り可能な記録媒体に関する。
【０００２】
【従来の技術】
ディレクトリ検索システムは、ディレクトリ階層上に管理されるデータのデータベースの検索を高速に行うために用いられるシステムである。ディレクトリ検索システムは、２分探索木やハッシュ表のような仕組みを保持している。この仕組みをインデックスという。インデックスは、データを特定するためのキーに基づいて構成されている。ディレクトリ検索システムは、検索条件として指定されたキーの値によってインデックスを探索してデータを特定する。
【０００３】
特開昭６０−２５４３２５号公報にはディレクトリ検索システムの一例が開示されている。その公報に開示されているディレクトリ検索システムは、インデックスを主記憶装置上に保持している。このディレクトリ検索システムは、データを特定するキーによってインデックスを検索してそのデータの位置情報を取得し、２次記憶装置上の目的のデータにアクセスする。一般的に、主記憶装置は２次記憶装置よりもはるかにアクセス速度が速い。そのため、このようなディレクトリ検索システムを用いることによって、２次記憶装置（外部記憶装置）上に大量のデータが格納されていても目的のデータに高速にアクセスすることができる。
通常、このようなインデックスは１種類のキーに基づいて構成されている。また、ディレクトリ検索システムでは１種類のキーに対して複数のインデックスを検索しなければならない場合もある。この場合、１種類のキーについて複数のインデックスを検索するため、検索に時間がかかってしまうという問題があった。特開平３−７００４９号公報には、この問題を解決するディレクトリ検索システムが開示されている。図１５は、この公報で開示されたディレクトリ検索システムの構成を示すブロック図である。
【０００４】
このディレクトリ検索システムは、レコード処理の開始を指示する処理開始指示装置１００１とディレクトリ情報処理手段１００２と併合インデックス作成手段１００５と併合インデックス読込手段１００６と作業ファイル１００７とディレクトリファイル１００９とを備えている。
【０００５】
ディレクトリ情報処理手段１００２は、併合インデックス作成指示手段１００３と併合インデックス読込指示手段１００４とを備えている。ディレクトリファイル１００９は、データベースのデータの管理情報を記憶するためのものである。ディレクトリファイル１００９は、データの管理情報の部分集合である幾つかのサブファイルから成るサブファイル群１０１３と、利用者インデックス１０１０と、グループ共有インデックス１０１１と、システム共有インデックス１０１２とを備えている。利用者インデックス１０１０は利用者毎に作成されており、ディレクトリファイル内に多数記憶されている管理情報レコードのうち、その利用者のみが利用できるデータの管理情報レコードを管理している。グループ共有インデックス１０１１は複数の利用者から構成されるグループ毎に作成されており、グループに属する利用者のみが利用できるデータの管理情報レコードを管理している。システム共有インデックス１０１２は１つだけ作成されており、全利用者が利用できるデータの管理情報レコードを管理している。
【０００６】
このディレクトリ検索システムは以下のように動作する。まず、処理開始指示装置１００１からディレクトリ情報処理手段１００２に対し処理開始が要求されると、併合インデックス作成指示手段１００３は、入力された処理指示者名に基づいて併合インデックス作成手段１００５に対し併合インデックスを作成するように指示する。
【０００７】
すると、併合インデックス作成手段１００５は、ディレクトリファイル１００９内の処理指示者の利用者インデックス１０１０と処理指示者が属するグループ共有インデックス１０１１とシステム共有インデックス１０１２とを読み込み、これらを併合して作業ファイル１００７上に併合インデックス１００８を作成する。次に、併合インデックス読込指示手段１００４は、併合インデックス読込手段１００６に対し併合インデックス１００８を読込むように指示する。併合インデックス読込手段１００６は管理情報レコードを特定するキーである管理情報レコード名を用いて併合インデックス１００８から該当する管理情報レコードの位置情報を読み、それをディレクトリ情報処理手段１００２へ渡す。ディレクトリ情報処理手段１００２は渡された管理情報レコードの位置情報により目的の管理情報レコードをサブファイルから読込む。
【０００８】
このディレクトリ検索システムでは、データを探索するためのキーとなる管理情報レコード名から目標とする管理情報レコードを読み込むのに、３つのインデックスを別々に探索しなければならなかったところを、３つのインデックスを併合し、併合されたインデックスを１回探索するだけでインデックスレコードを求めることができるので、検索時間を短縮することができる。このように、ディレクトリ検索システムでは、インデックスを探索する時間を短縮することが１つの課題となっている。
【０００９】
また、ディレクトリ検索システムでは、データを検索するときに数種類のキーを用いる場合が多い。この場合、従来のディレクトリ検索システムでは、それぞれのキーに対応したインデックスを１つずつ探索しなければならないため、データの検索時間が長くなってしまうという問題があった。
【００１０】
数種類のキーから一度にデータを探索することができる２分探索木がいくつか提案されている。この２分探索木の１つにケイ−ディー・ツリー（以降 ｋ−ｄｔｒｅｅ）がある。ｋ−ｄ ｔｒｅｅは、アイ・イー・イー・イー・トランザクションズ・オン・ソフトウェア・エンジニアリング、第ＳＥ−５巻、第４号、３３３〜３４０頁（ＩＥＥＥ ＴＲＡＮＳＡＣＴＩＯＮＳ ＯＮ ＳＯＦＴＷＡＲＥ ＥＮＧＩＮＥＥＲＩＮＧ、ＶＯＬ．ＳＥ−５、ＮＯ．４、ＪＵＬＹ １９７９、Ｐａｇｅｓ ３３３−３４０．）に掲載されたマルチディメンジョナル・バイナリ・サーチ・ツリーズ・イン・データベース・アプリケーションズ（Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｂｉｎａｒｙ Ｓｅａｒｃｈ Ｔｒｅｅｓ ｉｎ Ｄａｔａｂａｓｅ Ａｐｐｌｉｃａｔｉｏｎｓ）と題するジョン．Ｌ．ベントレー（Ｊｏｈｎ Ｌ． Ｂｅｎｔｌｅｙ）による論文に記載されている。
【００１１】
このｋ−ｄ ｔｒｅｅは、２分探索木の各ノードに検索するデータのエントリが有する複数のキー値を格納できるように拡張されたものである。ｋ−ｄ ｔｒｅｅでは、ツリーの格段毎に各キーが順番に分岐条件として用いられる。例えば、キーがその人の名前、年齢、電話番号であるとすると、第１段目では名前が分岐条件として用いられ、第２段目では年齢が分岐条件として用いられ、第３段目は電話番号が分岐条件として用いられ、第４段目以降も名前、年齢、電話番号がこの順番で分岐条件として用いられる。
【００１２】
図１６は、ｋ−ｄ Ｔｒｅｅの基本的な構成を示す図である。このｋ−ｄ ｔｒｅｅは、ある会社の社員を探索するためのツリーである。このツリーでは、社員の名前と年齢とが、社員を検索するためのキーとなる。
【００１３】
図１６に示すように、根（以降 ルート）のノード１０１には、Ｓａｔｏ氏（Ｓａｔｏ、２２）が格納されている。Ｓａｔｏは名前を表し、２２は年齢を表す。このツリーの第１段目では、名前で枝が分岐する。ルートにおける名前の頭文字はＳであるので、名前の頭文字のアルファベットがＡ〜Ｒである人は左へ分岐し、名前の頭文字のアルファベットがＳ〜Ｚである人は右へ分岐する。したがって、Ｅｎｄｏ氏（Ｅｎｄｏ、２８）は左へ分岐してノード１０２に格納され、Ｕｅｄａ氏（Ｕｅｄａ、３４）は右へ分岐してノード１０３に格納される。ツリーの第２段目では年齢によって枝が分岐する。年齢が分岐元のノードに格納されている年齢より下の人は左に分岐し、年齢が分岐元のノードに格納されている年齢以上の人は右に分岐する。したがって、Ｉｉｊｉｍａ氏（Ｉｉｊｉｍａ、２０）は左へ分岐してノード１０４に格納され、Ａｏｋｉ氏（Ａｏｋｉ、３２）は右に分岐してノード１０５に格納される。第３段目では、第１段目と同様に名前のアルファベットで枝が分岐する。したがって、Ｄｏｉ氏（Ｄｏｉ、２２）は左へ分岐してノード１０６に格納され、Ｋａｔｏ氏（Ｋａｔｏ、２５）は右へ分岐してノード１０７に格納される。そして、Ｎａｋａｉ氏（Ｎａｋａｉ、３７）はノード１０５から右に分岐してノード１０８に格納される。
【００１４】
ｋ−ｄ ｔｒｅｅでは、指定されていないキーによって分岐されている段において枝の選択は行われない。例えば、年齢が検索条件として指定されていない場合には、２段目ではノード１０４およびノード１０５の両方へ進むようにする。
以上述べたように、ｋ−ｄ ｔｒｅｅでは、数種類のキーを用いて一度にデータの検索が行えるので、検索時間を短縮することができる。
【００１５】
しかし、このようなｋ−ｄ ｔｒｅｅでは、木のデータの分布が不均衡である場合に検索条件によって検索時間に偏りがあるという問題があった。ｋ−ｄ Ｆｒｅｅを改良して、木のデータ分布が不均衡な場合でも検索時間が安定する２分探索木として、エッチ・ビー・ツリー（以降 ｈＢ ｔｒｅｅ）がある。ｈＢ ｔｒｅｅは、１９９０年１２月、エー・シー・エム・トランザクションズ・オン・データベース・システムズ、第１５巻、第４号、６２４〜６５８頁（ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ ＤａｔａｂａｓｅＳｙｓｔｅｍｓ、Ｖｏｌ．１５、Ｎｏ．４、 Ｄｅｃｅｍｂｅｒ １９９０、Ｐａｇｅｓ ６２５−６５８．）に掲載されたザ・エッチ・ビー・ツリー：マルチディメンジョナル・インデックシング・メソッド・ウィズ・グッド・ギャランティード・パフォーマンス（Ｔｈｅ ｈＢ Ｔｒｅｅ： Ａ Ｍｕｌｔｉａｔｔｒｉｂｕｔｅ Ｉｎｄｅｘｉｎｇ Ｍｅｔｈｏｄ ｗｉｔｈ Ｇｏｏｄ Ｇｕａｒａｎｔｅｅｄ Ｐｅｒｆｏｒｍａｎｃｅ）と題するデビッド．Ｂ．ロメット（Ｄａｖｉｄ Ｂ． Ｌｏｍｅｔ）らによる論文に記載されている。
【００１６】
ｋ−ｄ ｔｒｅｅは、オブジェクト単位でインデックスを管理しているが、ｈＢ ｔｒｅｅは、複数のオブジェクトを含む所定の範囲でインデックスを管理している。この所定の範囲をブリックという。各ブリックには、前述のｋ−ｄ ｔｒｅｅ方式のインデックスが格納されている。ブリック内におけるオブジェクトの数が所定の値を越えた場合、そのブリックは分割される。分割されたブリック同士は２分探索木方式で接続され、その木におけるノードとなる。そのブリックにより構成された２分探索木のリーフ部分には、各オブジェクトの情報が格納される。このｈＢ ｔｒｅｅで目的のオブジェクトを検索するときには、まず、検索条件を満たすブリックが探索され、そのブリック内のｋ−ｄ ｔｒｅｅを検索して目的のオブジェクトの情報が格納されるリーフが探索される。
【００１７】
図１７は、図１６のｋ−ｄ ｔｒｅｅで示された社員の分布状態を示すマップである。このマップは、縦軸が年齢であり、横軸が名前となっている。図１７に示すように、アルファベットＳをｘ３とし、アルファベットＩをｘ２とし、年齢２８をｙ１とする。マップ上のエリアは、年齢２８以上かつ名前の頭文字がＡの領域３０１と、年齢２８以上で名前の頭文字がＢ〜Ｒの領域３０２と、年齢２８以下で名前の頭文字がＡ〜Ｈの領域３０３と、年齢２８以下で名前の頭文字がＩ〜Ｒの領域３０４と、名前の頭文字がＳ〜Ｚの領域３０５とに分割されている。図１８は、これらの社員の構成をｈＢ ｔｒｅｅで表した図である。このｈＢ ｔｒｅｅは、ノード２０１〜２０３と、リーフ２０４〜２０８とから構成されている。ノード２０１〜２０３は、それぞれｈＢ ｔｒｅｅのブリックを表すものであり、それぞれをブリックａ、ブリックｂ、ブリックｃとする。図１８のｈＢｔｒｅｅでは、図１６におけるマップの各領域を元にブリックａ、ｂ、ｃを構成する。ブリックａは、マップ全体を指すものであるとし、ブリックｂは、領域３０１、３０２、３０５を指すものであるとし、ブリックｃは、領域３０３、３０４を指すものであるとする。
【００１８】
領域３０３、３０４には、Ｉｉｊｉｍａ氏、Ｄｏｉ氏、Ｋａｔｏ氏が含まれている。この３氏は、図１６のｋ−ｄ ｔｒｅｅにおけるノード１０４以下に格納されている。したがって、ブリックｂには、図１６のｋ−ｄ ｔｒｅｅのノード１０４以下の部分がｋ−ｄ ｔｒｅｅ方式で管理されている。
【００１９】
また、領域３０１、３０２、３０５には、Ｓａｔｏ氏、Ｅｎｄｏ氏、Ｕｅｄａ氏、Ａｏｋｉ氏、Ｎａｋａｉ氏が含まれている。この５人は、図１６のｋ−ｄ ｔｒｅｅにおけるノード１０１、１０２、１０３、１０５、１０８に格納されている。したがって、ブリックｃには、それらのノード１０１、１０２、１０３、１０５、１０８から構成される部分がｋ−ｄ ｔｒｅｅ方式で管理されている。
ブリックａは、ブリックｂへ分岐するかブリックｃへ分岐するかを決定するためのものである。図１６のｋ−ｄ ｔｒｅｅによれば、ブリックｂへ分岐するかブリックｃへ分岐するかは、ノード１０１またはノード１０２によって決定されるため、ブリックａ内のｋ−ｄ ｔｒｅｅは、ノード１０１とノード１０２から構成され、そのｋ−ｄ ｔｒｅｅの葉には、選択すべきブリック名が指定されている。
【００２０】
リーフ２０４〜リーフ２０８には、Ｅ、Ｄ、Ｃ、Ｂ、Ａのリーフ名がそれぞれに付与されており、図１７に示す領域３０１〜３０５に含まれる社員についての情報が格納されている。リーフ２０４には領域３０３に含まれるＤｏｉ氏（Ｄｏｉ、２２）に関する情報が格納され、リーフ２０４には領域３０４に含まれるＩｉｊｉｍａ氏（Ｉｉｊｉｍａ、２０）、Ｋａｔｏ氏（Ｋａｔｏ、２２）に関する情報が格納される。以下リーフ２０７、２０８には領域３０２、３０５に含まれる社員に関する情報が格納される。
【００２１】
また、ブリックｂ、ｃは前述のとおり、ｋ−ｄ ｔｒｅｅ方式により構成されるが、そのツリーの葉には、そのリーフ２０４〜２０８のうち選択すべきリーフ名が指定されている。また、該当するオブジェクトがない場合は、その葉は外部ノードであるとしてｅｘｔが指定される。各ブリックの各ノードにあるｘ１、ｘ２、ｘ３、ｙ１は、それぞれ図１８に示すように、アルファベットのＡ、アルファベットのＩ、アルファベットのＳ、年齢の２８を示し、各ノードにおける分岐条件を示す。
【００２２】
以上述べたように、データを検索する２分探索木をｈＢ ｔｒｅｅとすることによって、複数のオブジェクトを管理するブリックを２分探索木のノードとして木の枝の状態を均一化することができるため、安定した検索時間を得ることができる。なお、上述のような複数のキーから構成されたマルチキーをキーとしてデータを特定するための２分探索木から構成されるインデックスをマルチキーインデックスという。
【００２３】
一方、特開平１０−２８９１３９号公報に開示されているようなディレクトリサーバでは、各ファイルの媒体情報を一元管理して保存しておき、クライアントからの検索要求や更新要求があった場合、一元管理してある媒体情報の検索や更新などを行う。この媒体情報の管理などにも、上述のようなディレクトリ検索システムが用いられている。
【００２４】
また、媒体情報の管理を始めとして、個人情報管理やネットワーク管理などに利用される汎用のディレクトリサービスでは、組織や個人、コンピュータ、プリンタなど、様々な資源が管理対象となる。ディレクトリ検索システムは、それらの資源をエントリとして、資源間の関係に基づいてディレクトリ階層を形成し、それらのエントリの属性（以降 アトリビュート）をキーとしたインデックスを探索することによって、それらのエントリを検索することができる仕組みを提供している。
【００２５】
このようなディレクトリ検索システムの一例が特願平１１−４３２５９号出願で示されている。このディレクトリ検索システムは、エントリが有するアトリビュートについての検索条件であるフィルタ条件とディレクトリ階層に基づいて設定される検索範囲であるスコープ条件とを利用者が指定することによってエントリを検索するシステムである。
【００２６】
図１９は、この出願で示されているディレクトリ検索システムの構成を示すブロック図である。このディレクトリ検索システムは、入力装置１と、データ処理装置８と、記憶装置９と、出力装置４とから構成される。入力装置１は、キーボード等の利用者からの要求を入力するためのものである。データ処理装置８はプログラム制御により動作し、記憶装置９が記憶する情報の検索を行う。出力装置４はディスプレイ装置や印刷装置等であり、データ処理装置８が行った処理の結果を出力する。記憶装置９は、エントリ／アトリビュート記憶部３１と、複合インデックス記憶部３５と、先祖関係記憶部３４とを備えている。
【００２７】
エントリ／アトリビュート記憶部３１は、全てのエントリの情報と、その各エントリが有する属性であるアトリビュートの情報を記憶する。
【００２８】
複合インデックス記憶部３５は、各エントリがエントリ／アトリビュート記憶部３１におけるディレクトリ上の何階層目の何番目にあるかという複合したデータを、２分探索木により構成されるインデックスやハッシュ表等の形式で記憶している。
【００２９】
図２０は、ある会社の組織をディレクトリ階層で表す図である。このディレクトリ階層は４層から構成される。階層１は会社、階層２は部門、階層３は課、階層４は社員の層となっている。会社４０１には、営業部門４０２と開発部門４０３とがある。営業部門４０２には国内営業課４０４と海外営業課４０５、開発部門４０３には企画課４０６と製造課４０７という課がある。各課にはそれぞれの人４０８〜４１５が配属されている。
【００３０】
先祖関係記憶部３４は、各エントリの先祖関係を記憶している。図２１は、先祖関係記憶部３４に記憶されている先祖関係を表す先祖関係表を示す図である。この表は、各行にはエントリ／アトリビュート記憶部３１が記憶する各エントリのうち、先祖を有するエントリが各ディレクトリ階層毎に並べられている。また、この表の各列には、エントリ／アトリビュート記憶部３１が記憶する各エントリのうち、子孫を有するエントリが各ディレクトリ階層毎に並べられている。この表上でチェックされているところは、列のエントリが、行のエントリの先祖になっているということを示している。例えば、Ｕｅｄａ氏の先祖は、会社４０１と、営業部門４０２と、海外営業課４０５であるということが、この表からわかるようになっている。
【００３１】
データ処理装置８は、エントリ管理手段２１と、フィルタ検索手段２７と、スコープ判定手段２８とから構成される。エントリ管理手段２１は、エントリやアトリビュートの登録・削除・更新の処理を行う。フィルタ検索手段２７は、利用者が指定した検索条件にしたがってエントリの検索を行う。スコープ判定手段２８は、フィルタ検索手段２３が検索したエントリが利用者が指定した検索範囲に入っているかどうか調べてエントリを絞り込む。
【００３２】
まず、利用者からの要求が、エントリやアトリビュートの更新要求、削除要求、登録要求のいずれかの要求であった場合のディレクトリ検索システムの動作について説明する。入力装置１からその要求が入力されると、エントリ管理手段２１は、その要求がアトリビュート更新要求ならばエントリ／アトリビュート記憶部３１に格納されているエントリのアトリビュートを更新する。
【００３３】
また、その要求がＩＤ更新又は削除要求ならば、エントリ管理手段２１は、複合インデックス記憶部３５に記憶されているエントリのＩＤを更新または削除し、先祖関係記憶部３４の先祖関係表におけるそのエントリに関係する箇所のチェックも更新または削除する。また、その要求がエントリまたはアトリビュートの削除要求ならば、エントリ管理手段２１は、エントリ／アトリビュート記憶部３１に格納されたデータの中から該当するエントリ又はアトリビュートを削除する。また、その要求がエントリまたはアトリビュートの登録要求ならば、エントリ管理手段２１は、エントリ／アトリビュート記憶部３１に登録要求されたエントリまたはアトリビュートを登録する。
【００３４】
その要求がＩＤ更新又は登録要求の場合、エントリ管理手段２１は、複合インデックス記憶部３５にエントリのＩＤを追加し、先祖関係記憶部３４の先祖関係表の該当箇所にもチェックする。上述の処理が終了したら、エントリ管理手段２１は処理終了を出力装置４に通知し、出力装置４は処理結果を表示する。
【００３５】
次にアトリビュートをキーとして、エントリを検索する場合の動作について説明する。入力装置１から与えられた検索要求がフィルタ検索手段２７に入力されると、フィルタ検索手段２７は、指定された検索条件であるフィルタ条件にしたがってエントリ／アトリビュート記憶部３１に格納されているエントリの検索を行う。検索条件を満たしたエントリは、フィルタ検索手段２７によって一時集合（不図示）に格納される。その後、スコープ判定手段２８は、一時集合に格納されたエントリのうち検索範囲に入っているエントリを先祖関係記憶部３４の先祖関係表を参照することによって抽出し、結果集合（不図示）に格納する。その後、フィルタ検索手段２７は、結果集合に格納されたエントリについて複合インデックス記憶部３５にアクセスしてそのエントリのディレクトリ情報を取得し、その検索結果を出力装置４に出力する。
【００３６】
以上述べたように、このディレクトリ検索システムでは、フィルタ検索手段２７によってエントリ／アトリビュート記憶部３１よりエントリを検索した後に、その検索されたエントリの中から、スコープ判定手段２８によって、検索範囲に入っているエントリを抽出している。よって、フィルタ検索手段２７において検索されたエントリに中には検索範囲外にあるエントリも含まれている場合があり、それらのエントリの検索が結果的に無駄となり、検索時間が長くなってしまうという問題点があった。
【００３７】
また、このようなアトリビュートによるエントリのフィルタ検索では、エントリのアトリビュートに文字列や数値が含まれていた場合、文字列や数値の全一致検索だけではなく、部分一致検索もすることができるディレクトリ検索システムが要求される。
【００３８】
また、特開平１０−１８７７４５号公報では、エントリのアトリビュートに文字列や数値がフィルタ条件として含まれている場合に、その文字列の部分一致検索を行うことができるディレクトリ検索システムが開示されている。しかしながらこの公報に開示された従来のディレクトリ検索システムでは、アトリビュートの全一致検索用のインデックスと、部分一致検索用のインデックスを別々に備えることが必要となる。さらに、部分一致検索用のインデックスでは、格納されるアトリビュートが膨大な数にのぼるため、インデックスの大きさも大きくなる。そのため、文字列の部分一致検索が可能な従来のディレクトリ検索システムでは、それらのインデックスをできるだけ統合して、インデックスに使用される記憶装置の容量をできるだけ抑制することが課題となっている。
【００３９】
【発明が解決しようとする課題】
上述のような従来のディレクトリ検索システムは以下に示す３つの問題点を有している。
（１） 数種類のキーからデータを検索する場合には複数のインデックスを必要とするため、複数のインデックスを主記憶装置または２次記憶装置上に展開させなければならないので大容量の記憶装置が必要である。また、複数のインデックスを検索するので検索時間が長くなってしまう。
（２） ディレクトリサービスにおいてディレクトリ検索システムを用いてエントリを検索する場合、フィルタ条件に基づいてエントリの検索を行うフィルタ処理と、検索範囲に基づいてエントリの絞り込みを行うスコープ処理とが別々に実行される。そのため、フィルタ処理において検索されたエントリが、検索範囲外である場合があり、フィルタ処理において行われた検索処理が一部無駄となり、検索時間が長くなってしまう。
（３） アトリビュートの部分一致の検索が可能な従来のディレクトリ検索システムでは、アトリビュートの全一致検索用のインデックスと、部分一致検索用のインデックスという複数のインデックスが必要である。また、部分一致検索用のインデックスは、格納されるアトリビュートが膨大な数にのぼるため、インデックスのサイズも大きくなる。よって、アトリビュートの部分一致の検索が可能な従来のディレクトリ検索システムでは、大容量の記憶装置が必要となってしまう。
【００４０】
よって、本発明は、キーが２種類以上指定された場合でも、インデックスを記憶するのに必要な記憶容量を少なくし、検索時間を短縮することができるディレクトリ検索システムを提供することを目的とする。
【００４１】
また、本発明は、検索条件および検索範囲の両方について検索を行わなければならない場合でも、検索時間を短縮することができるディレクトリ検索システムを提供することを目的とする。
【００４２】
また、本発明は、エントリのアトリビュートに文字列が含まれていて、その文字列の部分一致検索を行う場合でも、できるだけインデックスを記憶するのに必要な記憶容量を少なくするディレクトリ検索システムを提供することを目的とする。
【００４３】
【課題を解決するための手段】
上記問題点を解決するために、本発明では、複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索システムであって、
前記各エントリの管理情報と前記各エントリの全ての属性とを前記ディレクトリ階層順に記憶するエントリ／アトリビュート記憶手段と、
エントリを識別するための識別子からエントリの前記ディレクトリ階層における階層番号および階層別番号を導き出すためのインデックスを記憶するエントリインデックス記憶手段と、
検索条件として指定された属性値を満たすエントリの識別子を取得するために前記各エントリの複数の属性から成るマルチキーをキーとする２分探索木から構成されるマルチキーインデックスを記憶するアトリビュートインデックス記憶手段と、
前記エントリインデックス記憶手段および前記アトリビュートインデックス記憶手段を管理するマルチキーインデックス管理手段と、
前記マルチキーインデックス管理手段を介して検索条件を満たすエントリの識別子を前記マルチキーインデックスから取得し前記マルチキーインデックスから取得した識別子に基づいて検索条件を満たすエントリの階層番号および階層別番号を前記マルチキーインデックス管理手段を介して前記エントリインデックス記憶手段から取得し該階層番号および階層別番号に基づいて検索条件を満たすエントリの管理情報を前記エントリ／アトリビュート記憶手段から取得するフィルタ検索手段とを備える。
【００４４】
本発明のディレクトリ検索システムでは、アトリビュートインデックス記憶手段が記憶するインデックスが、複数のキーによって一度に探索可能なマルチキーインデックスとなっているので、複数のインデックスを備える必要がないため、アトリビュートからエントリを検索するためのインデックスに必要な記憶容量を少なくことができる。また、複数のインデックスを検索する必要がないので検索時間を短縮することができる。
【００４５】
本発明の他のディレクトリ検索システムは、複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索システムであって、
前記各エントリの管理情報と前記各エントリの全ての属性とを前記ディレクトリ階層順に記憶するエントリ／アトリビュート記憶手段と、
エントリを識別するための識別子からエントリの前記ディレクトリ階層における階層番号および階層別番号を検索するためのインデックスを記憶するエントリインデックス記憶手段と、
検索条件として指定された属性値を満たすエントリの識別子を取得するために前記各エントリの複数の属性から成るマルチキーをキーとする２分探索木から構成され前記２分探索木の各ノードに格納されているエントリの前記階層番号および前記階層別番号が付与されているマルチキーインデックスを記憶するアトリビュートインデックス記憶手段と、
前記エントリインデックス記憶手段および前記アトリビュートインデックス記憶手段を管理するマルチキーインデックス管理手段と、
前記ディレクトリ階層における検索範囲が指定されていた場合に、検索条件として指定された属性の値に基づいて前記マルチキーインデックス管理手段を介して前記検索条件を満たすエントリを検索する途中に通過する前記各ノードに付与されている階層番号および階層別番号を有するエントリが前記検索範囲に入っているか否かを各エントリの先祖関係からチェックし、該チェックの結果において前記検索範囲に含まれていなかったエントリを検索条件を満たすエントリから除外した後で、残りのエントリが前記検索範囲に含まれているか否かの判定を行うスコープ／フィルタ統合検索手段とを備える。
【００４６】
本発明のディレクトリ検索システムでは、フィルタ検索とスコープ判定の処理を統合するスコープ／フィルタ統合検索手段を備えることにより、フィルタ検索に含まれていてスコープ判定に含まれないエントリにアクセスすることがなくなるため、エントリの検索時間を短縮することができる。
【００４７】
本発明のディレクトリ検索システムでは、マルチキーインデックスの探索時にスコープの絞り込みを行い、スコープの判定処理の負荷を軽減しているため、スコープ判定処理の負荷を軽減してエントリの検索時間を短縮することができる。
本発明の他のディレクトリ検索システムは、指定された文字列の中から所定の文字数の部分文字列をすべて抽出する部分文字列操作手段をさらに備え、
前記アトリビュートインデックス記憶部は前記部分文字列操作手段によって抽出された部分文字列をキーとするマルチキーインデックスを記憶しており、
前記マルチキーインデックス管理手段は、前記検索条件として文字列が含まれていた場合、前記部分文字列操作手段によって該文字列から抽出された少なくとも１つの部分文字列によって前記マルチキーインデックスの探索を行い、各部分文字列毎の前記マルチキーインデックスの探索結果となったエントリのうち、すべての部分文字列についての探索結果に含まれるエントリを検索条件を満たすエントリとする。
【００４８】
本発明のディレクトリ検索システムでは、文字列から所定の文字数の部分文字列を抽出する部分文字列操作手段と、すべての部分文字列の検索結果に含まれるエントリを検索結果であると判断するマルチキーインデックス管理手段とを備えることによって、同一のインデックスで全文字列および部分文字列の検索を行うことができるため、インデックスに必要な記憶容量を少なくすることができる。
【００４９】
【発明の実施の形態】
次に、本発明の実施形態のディレクトリ検索システムについて図面を参照して詳細に説明する。全図において、同一の符号がつけられている構成要素は、すべて同一のものを示す。
【００５０】
（第１の実施形態）
まず、本発明の第１の実施形態のディレクトリ検索システムについて説明する。本実施形態のディレクトリ検索システムは、図２０の会社４０１の組織を管理するデータベースに用いられているものとする。図１は、本実施形態のディレクトリ検索システムの構成を示すブロック図である。図１に示すように、本実施形態のディレクトリ検索システムは、入力装置１とデータ処理装置２と記憶装置３と出力装置４とから構成されている。
【００５１】
入力装置１は、キーボード等であり、利用者からの要求を入力し、その要求をデータ処理装置２に出力している。出力装置４は、ディスプレイ装置や印刷装置等の出力装置であり、データ処理装置３から処理の終了通知を受け取って処理結果を表示する。データ処理装置２は、エントリ管理手段２１と、マルチキーインデックス管理手段２２と、フィルタ検索手段２３と、スコープ判定手段２４とを備えている。また、記憶装置３は、エントリインデックス記憶部３１とアトリビュートインデックス記憶部３２とエントリ/アトリビュート記憶部３３とを備えている。
【００５２】
エントリ/アトリビュート記憶部３３は、全てのエントリの管理情報と各エントリが有する全てのアトリビュートとを記憶している。各エントリは、ディレクトリ階層の形態で記憶されており、ディレクトリのルートであるベースエントリの管理情報の格納場所と各エントリの階層番号および階層別番号が分かれば、各エントリの管理情報の格納場所を特定でき、各エントリの管理情報にアクセスすることができる。本実施形態のディレクトリ検索システムでは、図２０のディレクトリ階層の各エントリの管理情報と各エントリが有する全てのアトリビュートとを記憶している。
【００５３】
エントリインデックス記憶部３１は、エントリを識別するための識別子（以降ＤＮ：Ｄｉｓｔｉｎｇｕｉｓｈｅｄ Ｎａｍｅ）に基づいて作成されたインデックスを記憶している。このインデックスを検索することによって各エントリの階層番号と階層別番号とを取得することができる。
【００５４】
アトリビュートインデックス記憶部３２は、各エントリが有するアトリビュートをキーとして構成されたインデックスを記憶している。このインデックスは、前述のｈＢ ｔｒｅｅ方式を用いたマルチキーインデックスとなっており、複数のアトリビュートをキーとしてエントリを検索することができるようになっている。本実施形態のディレクトリ検索システムでは、アトリビュートインデックス記憶部３２に記憶されるマルチキーインデックスは、図１８の様になる。
【００５５】
エントリ管理手段２１は、入力装置１からエントリの登録・削除・ＩＤ更新要求やアトリビュートの登録・削除・更新要求を入力した場合、エントリ／アトリビュート記憶部３３に対してエントリやアトリビュートの登録・削除・更新を行う。さらに、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介して、エントリインデックス記憶部３１およびアトリビュートインデックス記憶部３２の登録、削除、更新を行う。
【００５６】
フィルタ検索手段２３は、入力装置１からエントリの検索要求を入力した場合、指定されたフィルタ条件を満たすエントリの検索を行う。スコープ判定手段２４は、フィルタ検索手段２３によって検索されたエントリが、指定された検索範囲であるスコープ条件を満たすかどうかを判定する。スコープ判定手段２４は、エントリ／アトリビュート記憶部３３のエントリのディレクトリ階層を参照することによってその判定を行う。
【００５７】
マルチキーインデックス管理手段２２は、フィルタ検索手段２３やエントリ管理手段２１からの要求により、エントリインデックス記憶部３１やアトリビュートインデックス記憶部３２が記憶するインデックスの管理や探索を行う。
【００５８】
次に、本実施形態のディレクトリ検索システムの動作について図２、図３、図１８を参照して詳細に説明する。図２は、エントリやアトリビュートの更新要求が入力された場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【００５９】
利用者が入力装置１に対し、エントリやアトリビュートの更新要求を入力した場合、入力装置１はその要求をエントリ管理手段２１へ出力する。すると、エントリ管理手段２１は、その要求がエントリの更新要求であるか否かを判定する（ステップＡ１）。もし、その要求がエントリの更新要求であれば、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１が記憶するインデックスを更新する（ステップＡ２）。その後、エントリ管理手段２１は、エントリ／アトリビュート記憶部３３に記憶されているエントリの更新を行う（ステップＡ３）。ステップＡ２、Ａ３の処理終了後、エントリ管理手段２１は処理終了を出力装置４に通知し、出力装置４は処理結果を出力する（ステップＡ４）。
【００６０】
ステップＡ１において、入力装置１からの要求がエントリの更新要求ではない場合、その要求はアトリビュートの更新要求である。エントリ管理手段２１は、アトリビュートインデックス記憶部３２において更新しようとするアトリビュートにインデックスが付与されているか否かを判定する（ステップＡ５）。更新しようとするアトリビュートにインデックスが付与されていれば、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介してアトリビュートインデックス記憶部３２に記憶されるアトリビュートのインデックスを更新する（ステップＡ６）。エントリ管理手段２１は、エントリ／アトリビュート記憶部３３に記憶されるアトリビュートを更新する（ステップＡ７）。そして、ステップＡ６、Ａ７の処理終了後、エントリ管理手段２１は処理終了を出力装置４に通知し、出力装置４は処理結果を表示する（ステップＡ４）。
【００６１】
ステップＡ５において、更新しようとするアトリビュートにインデックスが付与されていない場合、ステップＡ６の処理は実行されずに、ステップＡ７において、エントリ／アトリビュート記憶部３３のアトリビュートの更新のみが行われる。
【００６２】
ステップＡ６において、アトリビュートのインデックスを更新する際の動作について説明する。前述のように、アトリビュートインデックス記憶部３２は、図１８に示す社員の名前と年齢とをキーとしたマルチキーインデックスを記憶している。なお、更新されるアトリビュートは、社員の名前と年齢であり、更新されるアトリビュート値は（Ｏｚａｗａ、２４）であるとする。
【００６３】
このマルチキーインデックスでは、ブリックａから探索が開始される。ブリックａでは、「Ｏ」とｘ３（Ｓ）とが比較され、「２４」とｙ１（２８）とが比較されることによって、ブリックｂが選択される。ブリックｂでは、「Ｏ」とｘ２（Ｉ）とが比較され、リーフ２０５が選択される。リーフ２０５に（Ｏｚａｗａ、２４）のアトリビュート値を有するエントリのＤＮが格納される。
【００６４】
図３は、エントリを検索する場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。利用者が入力装置１に対しエントリの検索要求を入力した場合、入力装置１はその要求をフィルタ検索手段２３へ出力する。フィルタ検索手段２３は、エントリの検索要求が入力されるとマルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１のインデックスを探索する（ステップＢ１）。そのインデックスのルートであるベースエントリのエントリ／アトリビュート記憶部３３における格納場所を取得する（ステップＢ２）。そして、フィルタ検索手段２３はフィルタ条件が含まれているか否かを調べる（ステップＢ３）。もし、検索要求にフィルタ条件が含まれていれば、フィルタ検索手段２３は、フィルタ条件となっているアトリビュートにインデックスが付与されているかを調べる（ステップＢ６）。
【００６５】
フィルタ条件となっているアトリビュートにインデックスが付与されていれば、フィルタ検索手段２３は、マルチキーインデックス管理手段２２を介してそのフィルタ条件のアトリビュートの値によってマルチキーインデックスの探索を行い、フィルタ条件を満たすエントリのＤＮを得る。（ステップＢ７）。そして、フィルタ検索手段２３は、マルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１が記憶するインデックスを探索してステップＢ７において検索されたエントリのＤＮからそのエントリの階層番号と階層別番号を得る（ステップＢ８）。フィルタ検索手段２３は、エントリ／アトリビュート記憶部３３からステップＢ８において得られたベースエントリの格納場所とエントリの階層番号および階層別番号とからエントリの格納場所を割り出し、そのエントリの情報を取得する（ステップＢ９）。
【００６６】
ステップＢ６において、フィルタ条件となっているアトリビュートにインデックスが付与されていない場合には、フィルタ検索手段２３は、データベースの検索機能などを利用して、エントリ／アトリビュート記憶部３３からフィルタ条件を満たすエントリの検索を行って（ステップＢ１０）、ステップ９に移行する。
ステップＢ９の後およびステップＢ３において検索要求にフィルタ条件が含まれていなかったときは、本実施形態のディレクトリ検索システムの動作はスコープ判定手段２４に移行する。スコープ判定手段２４は、検索要求にスコープ条件が含まれているかを調べる（ステップＢ４）。スコープ判定手段２４は、入力装置１から入力された検索要求にスコープ条件が含まれていれば、エントリ／アトリビュート記憶部３３のディレクトリ階層をたどってステップＢ９で取得されたエントリが、スコープ条件を満たしているか否かの判定を行う（ステップＢ１１）。そして、スコープ判定手段２４は、スコープ条件を満たしているエントリをエントリ／アトリビュート記憶部３３にアクセスして取得し、検索結果を出力装置４に出力する（ステップＢ５）。
【００６７】
ステップＢ７において、アトリビュートのインデックスを更新する際の動作について詳細に説明する。前述のように、アトリビュートインデックス記憶部３２は、図１８に示す社員の名前と年齢とをキーとしたマルチキーインデックスを記憶している。フィルタ条件は、名前がＡかＫで始まることと年齢が３０歳以下であることとする。
【００６８】
マルチキーインデックスでは、ブリックａから探索が開始される。ブリックａでは、ルートにおいて「Ａ」および「Ｋ」とｘ３（Ｓ）とが比較され、左の枝が選択される。続いて、次のノードで「３０歳以下」とｙ１（２８）とが比較され、ここでは両者の大小関係が不明なので両方の枝が選択される。したがって、ブリックａでは、ブリックｂとブリックｃの両方が選択される。
【００６９】
ブリックｂでは、ルートにおいて、「Ａ」および「Ｋ」とｘ２（Ｉ）とが比較され、ここでは両者の関係が不明なので両方の枝が選択される。したがって、ブリックｂでは、リーフＤ、Ｅが選択される。
【００７０】
ブリックｂでは、ルートにおいて「Ａ」および「Ｋ」とｘ３（Ｓ）とが比較され、左の枝が選択される。続いて、次のノードで「３０歳以下」とｙ１（２８）とが比較され、ここでは両者の大小関係が不明なので両方の枝が選択される。しかし、左の枝には外部ノード（ｅｘｔ）が指定されているので、左の枝についての探索はここでストップする。右の枝については、「Ａ」および「Ｋ」とｘ１（Ａ）とが比較され、リーフＢが選択される。そして、選択されたリーフＢ、Ｄ、Ｅに登録されたエントリの中から、フィルタ条件を満たす（Ａｏｋｉ、３２）が抽出され、この（Ａｏｋｉ、３２）のエントリのＤＮがフィルタ検索手段２３に出力される。
【００７１】
本実施形態のディレクトリ検索システムでは、各エントリのアトリビュートに基づいて構成されるインデックスが、ｈＢ ｔｒｅｅ方式のマルチキーインデックスであるため、複数のアトリビュートがフィルタ条件として指定されたときでも、複数のインデックスを保持する必要がなくなる。そのため、本実施形態のディレクトリ検索システムでは、インデックスを記憶するための記憶容量を小さくすることができる。
【００７２】
また、本実施形態のディレクトリ検索システムでは、前述のように各エントリのアトリビュートに基づいて構成されるアトリビュートのインデックスが、複数のアトリビュートをキーとするｈＢ ｔｒｅｅ方式のマルチキーインデックスとなっている。そのため、本実施形態のディレクトリ検索システムでは、複数のアトリビュートがフィルタ条件として指定されたときでもインデックスの探索を１回で済ませることができる。そのため、本実施形態のインデックスシステムでは、複数のアトリビュートを探索する場合に複数のインデックスを検索したり何度も同じエントリにアクセスする必要がなくなるため、エントリの検索時間を短縮することができる。
【００７３】
（第２の実施形態）
次に、本発明の第２の実施形態のディレクトリ検索システムについて説明する。図４は、本実施形態のディレクトリ検索システムの構成を示すブロック図である。図４を参照すると、本実施形態のディレクトリ検索システムは、入力装置１と、データ処理装置５と、記憶装置６と、出力装置４とから構成されている。データ処理装置５は、図１に示すデータ処理装置２が備えるフィルタ検索手段２３とスコープ判定手段２４とが、スコープ／フィルタ統合検索手段２５に置き換えられたものである。また、記憶装置６は、図１に示す記憶装置３の構成要素に加え、先祖関係記憶部３４をさらに備えている。
【００７４】
アトリビュートインデックス記憶部３２は、図５に示すｈＢ ｔｒｅｅ形式のマルチキーインデックスを備える。このマルチキーインデックスは、ノード５０１〜５０３と、リーフ２０４〜２０８とから構成される。ノード５０１〜ノード５０３は、それぞれがブリックａ、ｂ、ｃである。ブリックａ、ｂ、ｃ内のインデックスの各ノードには、各ノードに格納されているキーの値を有するエントリの階層番号および階層別番号が付与されている。
【００７５】
スコープ／フィルタ統合検索手段２５は、マルチキーインデックス管理手段２２を介して指定されたフィルタ条件に基づいてアトリビュートインデックス記憶部３２に記憶されているマルチキーインデックスの探索を行うとともに、スコープ条件が指定されている場合には先祖関係記憶部３４が記憶する先祖関係表を用いてスコープ判定も同時に行う。また、スコープ／フィルタ統合検索手段２５は、スコープ判定を行った結果を記録するためのスコープ表を備える。図６は、本実施形態のディレクトリ検索システムにおけるスコープ／フィルタ統合検索手段２５が備えるスコープ表である。スコープ表の各行は、図２０のディレクトリ階層の各階層番号を表しており、スコープ表の各列は、スコープ左外（Ｌｅｆｔ−Ｏｕｔ、以降Ｌ−Ｏ）、スコープ右外（Ｌｅｆｔ−Ｉｎ、以降Ｌ−Ｉ）、スコープ右内（Ｒｉｇｈｔ−Ｉｎ、以降Ｒ−Ｉ）、スコープ右外（Ｒｉｇｈｔ−Ｏｕｔ、以降Ｒ−Ｏ）とに区切られている。
【００７６】
エントリの階層別番号がＬ−Ｏ、Ｒ−Ｏに書き込まれているということは、そのエントリはスコープ条件の範囲外にあることを意味している。また、エントリの階層別番号がＬ−Ｉ、Ｒ−Ｉに書き込まれているということは、そのエントリはスコープ条件の範囲内にあることを意味している。
【００７７】
本実施形態のディレクトリ検索システムの動作を図７、図８を参照して詳細に説明する。図７は、エントリやアトリビュートの更新要求があった場合のディレクトリ検索システムの動作を示すフローチャートである。なお、図７におけるステップＡ１、Ａ４〜Ａ７の動作は、図２におけるエントリ管理手段２１の動作と同一のため、説明は省略する。
【００７８】
ステップＡ１において、利用者からの要求がエントリの更新である場合、エントリ管理手段２１は、マルチキーインデックス管理手段２２を介してエントリインデックス記憶部３１に記憶されるエントリの更新を行う（ステップＡ２）。そして、エントリ管理手段２１は、先祖関係記憶部３４のエントリの更新にともなって変化したエントリの先祖関係に基づいて先祖関係表を更新する（ステップＣ１）。その後、エントリ管理手段２１は、エントリ／アトリビュート記憶部３３に記憶されるエントリの更新を行う（ステップＡ３）。
【００７９】
図８は、エントリの検索を行う場合の本実施形態のディレクトリ検索システム動作を示すフローチャートである。ステップＢ１、Ｂ２、Ｂ６、Ｂ９、Ｂ１０における動作は、図３に示す動作と同一であるため、これらのステップにおける動作の説明は省略する。
【００８０】
ステップＢ３で検索要求にフィルタ条件が含まれており、ステップＢ６でフィルタ条件となっているアトリビュートにインデックスが付与されている場合には、スコープ／フィルタ統合検索手段２５は、検索要求にスコープ条件が含まれているかを調べる（ステップＤ１）。
【００８１】
もし、検索要求にスコープ条件が含まれている場合、スコープ／フィルタ統合検索手段２５は、マルチキーインデックス管理手段２２を介してフィルタ条件に基づいてアトリビュートインデックス記憶部３２が記憶するインデックスを探索するとともに、インデックス探索途中で先祖関係記憶部３４の先祖関係表を参照してインデックスの各ノードの分岐条件となっているアトリビュート値を有するエントリがスコープの範囲内にあるエントリであるかどうかを調べ、スコープ表を作成する（ステップＤ２）。ステップＤ２においてフィルタ条件を満すエントリを検索後、それらのエントリの中からスコープ条件を満たすエントリをスコープ表から求める。スコープ表からスコープ条件を満たしているかどうか判断できないエントリについては、先祖関係記憶部３４の先祖関係表を参照してスコープ判定を行う（ステップＤ３）。
【００８２】
ステップＤ１においてスコープ条件が含まれていない場合には、第１の実施形態のディレクトリ検索システムと同様にアトリビュートインデックス記憶部３２のインデックスを探索のみを行う（ステップＢ７）。ステップＤ３またはステップＢ７の終了後、ステップＤ３またはステップＢ７において検索されたエントリの階層番号および階層別番号をエントリインデックス記憶部３１のインデックスを探索して得る（ステップＢ８）。そして、エントリ／アトリビュート記憶部３３から検索結果のエントリの管理情報を取得する（ステップＤ４）。
【００８３】
また、ステップＢ４において、検索要求にスコープ条件が含まれている場合には、スコープ／フィルタ統合手段２５は、先祖関係記憶部３４の先祖関係表を参照してスコープの判定を行う（ステップＤ３）。ステップＤ３、Ｂ４、Ｄ４終了後、スコープ／フィルタ統合手段２５は、エントリ／アトリビュート記憶部３３にアクセスして最終的な検索結果のエントリの管理情報を取得し、出力装置４にそれらの管理情報を出力する（ステップＢ５）。
【００８４】
アトリビュートインデックス記憶部３２の記憶するマルチキーインデックスでは、前述のように、ブリック５０１〜５０３のインデックスのノードには、各ノードの分岐条件となっているキー値をアトリビュートとして有するエントリの階層番号および階層別番号が付与されている。
【００８５】
ステップＤ２において、スコープ／フィルタ統合検索手段２５は、フィルタ条件となっているアトリビュートをキーとするインデックスがアトリビュートインデックス記憶部３２に存在している場合に、マルチキーインデックス管理手段２２を介してアトリビュートインデックス記憶部３２に記憶されるインデックスを探索する。そして、各ブリックのインデックスのノードを通過する際に、そのノードに付与されている階層番号および階層別番号を有するエントリが、スコープ条件の範囲内かどうかを先祖関係記憶部３４の先祖関係表を参照して調べ、その結果に基づいてスコープ表を更新する。
【００８６】
例えば、フィルタ条件が年齢３０歳以上であることであり、スコープ条件が営業部門であるとする。スコープ／フィルタ統合検索手段２５は、アトリビュートインデックス記憶部３２のマルチキーインデックスを年齢３０歳以上で探索する。スコープ／フィルタ統合検索手段２５は、その探索途中でノードを通過する際に、そのノードに付与されている階層番号および階層別番号を有するエントリがスコープ条件となっている営業部門に属しているかどうかをスコープ表にチェックしていく。階層番号４および階層別番号１のＳａｔｏ氏と階層番号４および階層別番号２のＥｎｄｏ氏とは、営業部門に属しているので、スコープ条件の範囲内にある。したがって、スコープ／フィルタ統合検索手段２５は、スコープ表の階層番号４およびＬ−Ｉ、Ｒ−Ｉのところに階層別番号１、２を書き込む。さらに、階層番号４および階層別番号５のＡｏｋｉ氏は、営業部門に属していないので、スコープ条件の範囲外である。したがって、スコープ／フィルタ統合検索手段２５は、スコープ表の階層番号４でＲ−Ｏのところに階層別番号５が書き込む。以上の結果から、階層番号４における各エントリのうち、階層別番号が１、２であるエントリはスコープ条件の範囲内であり、階層別番号が５であるエントリはスコープ条件の範囲外であることがわかる。
【００８７】
フィルタ条件によるマルチキーインデックスの探索は、最終的にリーフＡ、Ｂ、Ｃが選択され、そこに登録されているエントリから３０歳以上のＡｏｋｉ氏、（階層別番号５）、Ｎａｋａｉ氏（階層別番号８）、Ｕｅｄａ氏（階層別番号３）が抽出される。この中からスコープ条件の範囲外である階層別番号５のＡｏｋｉ氏は検索結果から除外される。
【００８８】
本実施形態のディレクトリ検索システムでは、フィルタ条件を満たすエントリの検索中にスコープの絞り込みを行うことで、スコープ判定の負担を軽減することができる。また、本実施形態のディレクトリ検索システムでは、フィルタ検索とスコープ判定の処理を統合することにより、結果的にスコープ判定に含まれないエントリにアクセスすることがなくなるため、エントリの検索時間を短縮することができる。
【００８９】
（第３の実施形態）
次に、本発明の第３の実施形態のディレクトリ検索システムについて説明する。図９は、本実施形態のディレクトリ検索システムの構成を示すブロック図である。本実施形態のディレクトリ検索システムは、入力装置１と、出力装置４と、記憶装置６と、データ処理装置７とから構成されている。データ処理装置７は図４のデータ処理装置５の構成要素に加えて、部分文字列操作手段２６を備えている。部分文字列操作手段２６は、マルチキーインデックス管理手段２２からの指示により、文字列を分解する。
【００９０】
本実施形態のディレクトリ検索システムでは、名前の部分一致検索を行うため、各社員の名前から抽出された３文字の部分文字列をキーとする。図１０は、図２０のディレクトリ階層における社員の名前から抽出された３文字の部分文字列と年齢とから成るマルチキーの分布状態を示すマップである。このマップは、縦軸が年齢で、横軸が名前の先頭のアルファベットとなっている。
【００９１】
図１０に示すように、アルファベットＳをｘ３とし、アルファベットＩをｘ２とし、アルファベットＥをｘ１とし、年齢２８をｙ１とする。マップ上のエリアは、年齢２８以上かつ名前の頭文字がＡ〜Ｄの領域７０１と、年齢２８以上かつ名前の頭文字がＥ〜Ｒの領域７０２と、年齢２８未満で名前の頭文字がＡ〜Ｈの領域７０３と、年齢２８未満で名前の頭文字がＩ〜Ｒの領域７０４と、名前の頭文字がＳ〜Ｚの領域７０５とに分割されている。
【００９２】
図１１は、本実施形態のディレクトリ検索システムにおけるアトリビュートインデックス記憶部３２のマルチキーインデックスを示す図である。このマルチキーインデックスは、ノード６０１〜６０３と、リーフ６０４〜６０８とから構成されている。ノード６０１〜６０３は、それぞれがブリックａ、ブリックｂ、ブリックｃである。図１１のｈＢ ｔｒｅｅでは、図１０におけるマップの各領域を元にブリックａ、ｂ、ｃを構成する。ブリックａは、マップ全体を指すものであるとし、ブリックｃは、領域７０１、７０２、７０５を指すものであるとし、ブリックｂは、領域７０３、７０４を指すものであるとする。
【００９３】
このマルチキーインデックスは、まずフィルタ条件として指定されたアトリビュートの値が、マップ上のどの領域の属するかを探索する。ブリックａでは、ｘ３（Ｓ）とｙ１（２８）とを分岐条件として、フィルタ条件として指定されたアトリビュートの値が、領域７０１、７０２、７０５に含まれるか領域７０３、７０４に含まれるかを切り分ける。そして、ブリックｂでは、フィルタ条件として指定されたアトリビュートの値の含まれる領域が、領域７０３なのか領域７０４なのかを切り分ける。ブリックｃでは、フィルタ条件として指定されたアトリビュートの値の含まれる領域が、領域７０１なのか領域７０２領域７０５なのかを切り分ける。
【００９４】
リーフ６０４〜６０８にはそれぞれ領域７０３、７０４、７０１、７０２、７０５に含まれる各要素のＤＮが登録されている。同一のリーフ内に格納され、同じエントリのＤＮを指す要素は、マルチキーインデックス管理手段２２によってキー併合されて登録されている。例えば、各マルチキー（ＩＩＪ、２０）、（ＩＪＩ、２０）、（ＪＩＭ、２０）、（ＩＭＡ、２０）は、同じリーフ６０８に格納され、同じエントリであるＩｉｊｉｍａ氏を指すので（ＩＩＪ＋ＩＪＩ＋ＪＩＭ＋ＩＭＡ、２０）というふうにマルチキーインデックス管理手段２２によってキー併合されて登録されている。
【００９５】
次に、本実施形態のディレクトリ検索システムの動作を図１２、図１３を参照して詳細に説明する。図１２は、エントリまたはアトリビュートの更新を行う場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。図１２のステップＡ１〜Ａ５、Ａ７、Ｃ１の動作は、第２の実施形態のディレクトリ検索システムにおけるエントリ管理手段２１の動作と同一であるため、これらのステップの動作の説明は省略する。
【００９６】
ステップＡ５において、利用者からの要求がインデックスが付与されているアトリビュートの更新要求であった場合、マルチキーインデックス管理手段２１は、アトリビュートに文字列が含まれているかを調べる（ステップＥ１）。
【００９７】
もし含まれていれば、マルチキーインデックス管理手段２２は、部分文字列操作手段２６を介して文字列から３文字の部分文字列を抽出する（ステップＥ２）。例えば、更新要求のあったアトリビュートの値が、（Ｔｓｕｊｉ、３０）であった場合、文字列「ｔｓｕｊｉ」から「ｔｓｕ」と「ｓｕｊ」と「ｕｊｉ」を抽出する。すると、マルチキーインデックス管理手段２２は、（ｔｓｕ、３０）、（ｓｕｊ、３０）、（ｕｊｉ、３０）の３つのマルチキーを作成し、これらのマルチキーによってアトリビュートインデックス記憶部のマルチキーインデックスを探索する。そして、各マルチキーのうち、探索結果が同一のリーフとなったマルチキーがある場合、マルチキーインデックス管理手段２２は、それらのマルチキーのキー併合を行いアトリビュートインデックス記憶部３２のインデックスを更新する（ステップＥ３）。例えば、上述のマルチキー（ｔｓｕ、３０）、（ｓｕｊ、３０）、（ｕｊｉ、３０）は、すべて、リーフ６０８に格納されるようになるので、（ｔｓｕ＋ｓｕｊ＋ｕｊｉ、３０）のように、キー併合を行って（ｔｓｕｊｉ、３０）のエントリのＤＮをリーフ６０８に格納する。
【００９８】
その後、マルチキーインデックス管理手段２２は、エントリ／アトリビュート記憶部３３に新しく追加されたエントリのアトリビュートを更新する（ステップＡ７）。ステップＥ１において、指定されたアトリビュートに部分文字列が含まれていなかった場合、マルチキーインデックス管理手段は、そのアトリビュートに基づいて、アトリビュートインデックス記憶部３２に格納されたインデックスを更新し（ステップＡ６）、ステップＡ７に進む。
【００９９】
図１３は、エントリの検索要求があった場合の本実施形態のディレクトリ検索システムの動作を示すフローチャートである。図１３において、ステップＢ１〜Ｂ１０、Ｄ１〜Ｄ４の動作は、図８におけるそれらのステップの動作と同一であるため、それらのステップの動作の説明は省略する。
【０１００】
ステップＢ３でフィルタ条件が指定されており、ステップＢ６でインデックスが付与されていた場合、マルチキーインデックス管理手段２２は、部分文字列のインデックスが含まれているかを調べる（ステップＦ１）。もし含まれていれば、部分文字列操作文字手段２６は、その部分文字列から所定の文字数の部分文字列を抽出する（ステップＦ２）。例えば、「ＮＡＫＡ」という文字列を含む名前を持つエントリを検索する場合、所定の文字数が３文字であるとすると、部分文字列操作手段２６は「ＮＡＫＡ」から「ＮＡＫ」および「ＡＫＡ」を抽出する。
その後、本実施形態のインデックスシステムの動作は、スコープ／フィルタ統合検索手段２５に移行する。ステップＦ１において部分文字列のインデックスが含まれていない場合には、ステップＦ２の処理はスキップされる。
【０１０１】
ブリックａ、ｂ、ｃ内のインデックスの内部ノードには、第２の実施形態のディレクトリ検索システムと同様にスコープの絞り込みで使用されるエントリの階層番号および階層別番号が付与されている。リーフ６０４〜６０８には、キー併合により同じエントリを指しているマルチキーがキー併合されて管理されている。「ＮＡＫ」による探索では、リーフ６０５と６０７とにたどりついて（ＮＡＫ＋ＫＡＩ、３７）のエントリが選択される。［ＡＫＡ］による探索ではリーフ６０４と６０６にたどりついて（ＡＫＡ、３７）のエントリが選択される。これらのエントリは、同じＮａｋａｉ氏を示すので、Ｎａｋａｉ氏が検索結果となって、出力装置４に出力される。
【０１０２】
また、本実施形態のディレクトリ検索システムでは、「Ｎａｋａｉ」のような全文字列検索を行う場合でも、同様な動作で上述のマルチキーインデックスを探索してＮａｋａｉ氏の情報を取得することができる。
【０１０３】
以上述べたように、本実施形態のディレクトリ検索システムでは、文字列から所定の文字数の部分文字列を抽出する部分文字列操作手段２６と、すべての部分文字列の検索結果に含まれるエントリを検索結果であると判断するマルチキーインデックス管理手段２２とを備えることによって、同一のインデックスで全文字列および部分文字列の検索を行うことができるため、インデックスの記憶に要する記憶容量を少なくすることができる。
【０１０４】
また、本実施形態のディレクトリ検索システムでは、部分文字列をキーとするインデックスについて、同一のリーフの登録される同一のエントリについてのマルチキーがあった場合には、それらのマルチキーをキー併合するため、リーフに登録されるマルチキーの数を減らすことができるため、インデックスを記憶するための記憶容量を小さくすることができる。
【０１０５】
なお、上記第１、第２、第３の実施形態のディレクトリ検索システムでは、アトリビュートインデックス記憶部が格納するインデックスをｈＢ ｔｒｅｅの形態としたマルチキーインデックスであるとして構造および動作を説明したが、本発明はこれに限定されるものではなく、マルチキーインデックスをｋ−ｄ ｔｒｅｅまたは他の形態のマルチキーインデックスとしても良い。
【０１０６】
また、図１４に示すように、第１、第２、第３の実施形態のディレクトリ検索システムは、データ更新またはデータ検索を実行するためのプログラムを記録した記録媒体７を備えていてもよい。
【０１０７】
第１の実施形態のディレクトリ検索システムでは、記録媒体７は、フィルタ条件とを満たすエントリをマルチキーインデックスから検索する処理と、エントリやアトリビュートの登録や削除や更新が行われる場合に、ディレクトリ階層およびマルチキーインデックスに対しても登録や削除や更新を行う処理とを行うプログラムを記録している。
【０１０８】
また、第２の実施形態のディレクトリ検索システムでは、記憶媒体７は、ディレクトリ階層におけるスコープ条件が指定されていた場合にフィルタ条件を満たすエントリをマルチキーインデックスを検索する途中に通過する各ノードに付与されている階層番号および階層別番号を有するエントリがスコープ条件に入っているか否かを各エントリの先祖関係からチェックする処理と、そのチェックの結果においてスコープ条件に含まれていなかったエントリをフィルタ条件を満たすエントリから除外した後で、残りのエントリがスコープ範囲に含まれているか否かの判定を行う処理と、利用者からエントリの登録や削除や更新が行われた場合には、ディレクトリ階層の登録や削除や更新を行うとともにマルチキーインデックスの２分探索木の各ノードに付与されている階層番号および階層別番号の登録や削除や更新を行う処理とを行うプログラムを記録している。
【０１０９】
また、第３の実施形態のディレクトリ検索システムでは、記録媒体７は、検索条件として指定された属性値が文字列であった場合、その文字列の中から所定の文字数の部分文字列をすべて抽出する処理と、
フィルタ条件として指定された属性値が文字列であった場合にその文字列から抽出された少なくとも１つの部分文字列によって所定の文字数の部分文字列をキーの１つとするマルチキーインデックスの探索を行い、各部分文字列毎のマルチキーインデックスの探索結果となったエントリのうちすべての部分文字列についての探索結果に含まれるエントリをフィルタ条件を満たすエントリとする処理と、利用者から属性となっている文字列の更新要求があった場合にその文字列から抽出された所定の文字数の部分文字列のうちの探索結果が同一になる部分文字列についてはキー併合を行ってその部分文字列が指すエントリの識別子を格納する場所を同一とする処理とを行うためのプログラムを記録している。記録媒体７としては磁気ディスク、半導体メモリまたはその他の記録媒体が用いられる。
【０１１０】
【発明の効果】
以上述べたように、本発明のディレクトリ検索システムは、以下に示す３つの効果を有している。
（１） アトリビュートインデックス記憶部が記憶するインデックスが、複数のキーによって一度に探索可能なマルチキーインデックスとなっているため、アトリビュートからエントリを検索するためのインデックスを記憶するのに必要な記憶容量を少なくことができる。また、複数のインデックスを検索する必要がないので、検索時間を短縮することができる。
（２） マルチキーインデックスの探索時にスコープの絞り込みを行い、スコープの判定処理の負荷を軽減しているため、スコープ判定処理の負荷を軽減してエントリの検索時間を短縮することができる。また、フィルタ検索とスコープ判定の処理を統合することにより、結果的にスコープ判定に含まれないエントリにアクセスすることがなくなるため、エントリの検索時間を短縮することができる。
（３） 文字列から所定の文字数の部分文字列を抽出する部分文字列操作手段と、すべての部分文字列の検索結果に含まれるエントリを検索結果であると判断するマルチキーインデックス管理手段とを備えることによって、同一のインデックスで全文字列および部分文字列の検索を行うことができるため、インデックスを記憶するのに必要な記憶容量を少なくすることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態のディレクトリ検索システムの構成を示すブロック図である。
【図２】エントリやアトリビュートの更新要求が入力された場合の本発明の第１の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図３】エントリを検索する場合の本発明の第１の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図４】本発明の第２の実施形態のディレクトリ検索システムの構成を示すブロック図である。
【図５】本発明の第２の実施形態のディレクトリ検索システムにおけるアトリビュートインデックス記憶部が記憶するマルチキーインデックスを示す図である。
【図６】本発明の第２の実施形態のディレクトリ検索システムにおけるスコープ／フィルタ検索手段が記憶するスコープ表を示す図である。
【図７】エントリまたはアトリビュートの更新を行う場合の本発明の第２の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図８】エントリの検索を行う場合の本発明の第２の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図９】本発明の第３の実施形態のディレクトリ検索システムの構成を示すブロック図である。
【図１０】本発明の第３の実施形態のディレクトリ検索システムにおけるアトリビュートインデックス記憶部が記憶するマルチキーインデックスを示す図である。
【図１１】ある会社の社員の名前の部分文字列を抽出した場合の各部分文字列と年齢とから構成されるマルチキーの分布を示すマップを示す図である。
【図１２】エントリまたはアトリビュートを更新する場合の本発明の第３の実施形態のディレクトリ検索システムの動作を示すフローチャートである。
【図１３】本発明の第３の実施形態のディレクトリ検索システムのエントリまたはアトリビュートの検索時における動作を示すフローチャートである。
【図１４】本発明の第１、第２、第３の実施形態のディレクトリ検索システムが記録媒体を備えている場合の構成を示すブロック図である。
【図１５】特開平３−７００４９号公報に開示されたディレクトリ検索システムの構成を示すブロック図である。
【図１６】ｋ−ｄ ｔｒｅｅの基本的な構成を示す図である。
【図１７】ある会社の社員の名前と年齢とから構成されるマルチキーの分布状態を示すマップである。
【図１８】ある会社の社員の構成をｈＢ ｔｒｅｅの形態で表した図である。
【図１９】特願平１１−４３２５９号出願に記載された従来のディレクトリ検索システムの構成を示すブロック図である。
【図２０】ある会社の組織をディレクトリ階層で表す図である。
【図２１】従来のディレクトリ検索システムの先祖関係記憶部が記憶する先祖関係表を示す図である。
【符号の説明】
１ 入力装置
２、５、７、８ データ処理装置
３、６、９ 記憶装置
４ 出力装置
２１ エントリ管理手段
２２ マルチキーインデックス管理手段
２３、２７ フィルタ検索手段
２４、２８ スコープ判定手段
２５ スコープ／フィルタ統合検索手段
２６ 部分文字列操作手段
３１ エントリインデックス記憶部
３２ アトリビュートインデックス記憶部
３３ エントリ／アトリビュート記憶部
３４ 先祖関係記憶部
３５ 複合インデックス記憶部
１０１〜１０８ ノード
２０４〜２０８、６０４〜６０８ リーフ
２０１〜２０３、５０１〜５０３、６０１〜６０３ ノード
３０１〜３０５、７０１〜７０５ 領域
４０１ 会社
４０２ 営業部門
４０３ 開発部門
４０４ 国内営業課
４０５ 海外営業課
４０６ 企画課
４０７ 製造課
４０８〜４１５ 社員
１００１ 処理開始指示装置
１００２ ディレクトリ情報処理手段
１００３ 併合インデックス作成指示手段
１００４ 併合インデックス読込指示手段
１００５ 併合インデックス作成手段
１００６ 併合インデックス読込手段
１００７ 作業ファイル
１００８ 併合インデックス
１００９ ディレクトリファイル
１０１０ 利用者インデックス
１０１１ グループ共有インデックス
１０１２ システム共有インデックス
１０１３ サブファイル群
Ａ１〜Ａ７、Ｂ１〜Ｂ１１、Ｃ１ ステップ
Ｄ１〜Ｄ４、Ｅ１〜Ｅ３、Ｆ１、Ｆ２ ステップ
Claims (14)
- 複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索システムであって、
前記各エントリの管理情報と前記各エントリの全ての属性とを前記ディレクトリ階層順に記憶するエントリ／アトリビュート記憶手段と、
エントリを識別するための識別子からエントリの前記ディレクトリ階層における階層番号および階層別番号を導き出すためのインデックスを記憶するエントリインデックス記憶手段と、
検索条件として指定された属性値を満たすエントリの識別子を取得するために前記各エントリの複数の属性から成るマルチキーをキーとする２分探索木から構成されるマルチキーインデックスを記憶するアトリビュートインデックス記憶手段と、
前記エントリインデックス記憶手段および前記アトリビュートインデックス記憶手段を管理するマルチキーインデックス管理手段と、
前記マルチキーインデックス管理手段を介して検索条件を満たすエントリの識別子を前記マルチキーインデックスから取得し、前記マルチキーインデックスから取得した識別子に基づいて検索条件を満たすエントリの階層番号および階層別番号を前記マルチキーインデックス管理手段を介して前記エントリインデックス記憶手段から取得し、該階層番号および階層別番号に基づいて検索条件を満たすエントリの管理情報を前記エントリ／アトリビュート記憶手段から取得するフィルタ検索手段とを備えるディレクトリ検索システム。 - 前記エントリおよび前記属性の登録や削除や更新が要求された場合に、前記エントリ／アトリビュート記憶手段が記憶する前記エントリおよび前記属性の登録や削除や更新を行うとともに、前記マルチキーインデックス管理手段を介して前記エントリインデックス記憶手段に記憶されるインデックスと前記アトリビュートインデックス記憶手段に記憶されるマルチキーインデックスとに対しても登録や削除や更新を行うエントリ管理手段をさらに備える請求項１記載のディレクトリ検索システム。
- 複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索システムであって、
前記各エントリの管理情報と前記各エントリの全ての属性とを前記ディレクトリ階層順に記憶するエントリ／アトリビュート記憶手段と、
エントリを識別するための識別子からエントリの前記ディレクトリ階層における階層番号および階層別番号を検索するためのインデックスを記憶するエントリインデックス記憶手段と、
検索条件として指定された属性値を満たすエントリの識別子を取得するために前記各エントリの複数の属性から成るマルチキーをキーとする２分探索木から構成され前記２分探索木の各ノードに格納されているエントリの前記階層番号および前記階層別番号が付与されているマルチキーインデックスを記憶するアトリビュートインデックス記憶手段と、
前記エントリインデックス記憶手段および前記アトリビュートインデックス記憶手段を管理するマルチキーインデックス管理手段と、
前記ディレクトリ階層における検索範囲が指定されていた場合に、検索条件として指定された属性の値に基づいて前記マルチキーインデックス管理手段を介し
て前記検索条件を満たすエントリを検索する途中に通過する前記各ノードに付与されている階層番号および階層別番号を有するエントリが前記検索範囲に入っているか否かを各エントリの先祖関係からチェックし、該チェックの結果において前記検索範囲に含まれていなかったエントリを検索条件を満たすエントリから除外した後で、残りのエントリが前記検索範囲に含まれているか否かの判定を行うスコープ／フィルタ統合検索手段とを備えるディレクトリ検索システム。 - エントリの登録や削除や更新要求があった場合には前記エントリ／アトリビュート記憶手段が記憶するエントリの登録や削除や更新を行うとともに前記マルチキーインデックス管理手段を介して前記エントリインデックス記憶手段に記憶されるインデックスの登録や削除や更新を行い前記マルチキーインデックスの２分探索木の各ノードに付与されている階層番号および階層別番号についての更新も行うエントリ管理手段をさらに備える請求項３記載のディレクトリ検索システム。
- 指定された文字列の中から所定の文字数の部分文字列をすべて抽出する部分文字列操作手段をさらに備え、
前記アトリビュートインデックス記憶部は前記部分文字列操作手段によって抽出された部分文字列をキーとするマルチキーインデックスを記憶しており、
前記マルチキーインデックス管理手段は、前記検索条件として文字列が含まれていた場合、前記部分文字列操作手段によって該文字列から抽出された少なくとも１つの部分文字列によって前記マルチキーインデックスの探索を行い、各部分文字列毎の前記マルチキーインデックスの探索結果となったエントリのうち、すべての部分文字列についての探索結果に含まれるエントリを検索条件を満たすエントリとする請求項１から４のいずれか１項記載のディレクトリ検索システム。 - 属性となっている文字列の更新要求があった場合に、前記部分文字列操作手段から抽出された部分文字列のうち探索結果が同一になる部分文字列については、キー併合を行って該部分文字列が指すエントリの識別子を格納する場所を同一とする請求項５記載のディレクトリ検索システム。
- 複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、該各エントリの属性をキーとするインデックスを用いてエントリを検索するディレクトリ検索方法であって、
エントリが有する複数の属性から成るマルチキーをキーとするエントリを特定するための２分探索木から構成され、前記各エントリを格納する前記２分探索木の各ノードに前記各エントリの前記ディレクトリ階層における階層番号および階層別番号がそれぞれ付与されているマルチキーインデックスを作成し、
前記ディレクトリ階層における検索範囲が指定されていた場合に、検索条件として指定された属性の値に基づいて前記検索条件を満たすエントリを検索する途中に通過する前記各ノードに付与されている階層番号および階層別番号を有するエントリが前記検索範囲に入っているか否かを各エントリの先祖関係からチェックし、
該チェックの結果において前記検索範囲に含まれていなかったエントリを検索条件を満たすエントリから除外した後で、残りのエントリが前記検索範囲に含まれているか否かの判定を行うディレクトリ検索方法。 - エントリの登録や削除や更新が行われた場合には、ディレクトリ階層の登録や削除や更新を行うとともに、前記マルチキーインデックスの２分探索木の各ノードに付与されている階層番号および階層別番号の登録や削除や更新も行う請求項７記載のディレクトリ検索方法。
- 前記マルチキーインデックスは、所定の文字数の部分文字列をキーとしており、
検索条件として指定された属性値が文字列であった場合、該文字列の中から所定の文字数の部分文字列をすべて抽出し、
検索条件として指定された属性値が文字列であった場合、該文字列から抽出された少なくとも１つの部分文字列によって前記マルチキーインデックスの探索を行い、各部分文字列毎の前記マルチキーインデックスの探索結果となったエントリのうち、すべての部分文字列についての探索結果に含まれるエントリを検索条件を満たすエントリとする請求項７または８記載のディレクトリ検索方法。 - 属性となっている文字列の更新要求があった場合に、前記部分文字列操作手段から抽出された部分文字列のうち探索結果が同一になる部分文字列については、キー併合を行って該部分文字列が指すエントリの識別子を格納する場所を同一とする請求項９記載のディレクトリ検索方法。
- 複数の資源を管理するために該各資源をエントリとして該各資源間の関係に基づいてディレクトリ階層を構成し、前記各エントリが有する複数の属性から成るマルチキーをキーとするエントリを特定するための２分探索木から構成され前記各エントリを格納する前記２分探索木の各ノードに前記ディレクトリ階層における前記各エントリの階層番号および階層別番号がそれぞれ付与されているマルチキーインデックスを用いてエントリを検索するディレクトリ検索システムに備えられ、
前記ディレクトリ階層における検索範囲が指定されていた場合に検索条件として指定された属性の値に基づいて前記検索条件を満たすエントリを前記マルチキーインデックスを検索する途中に通過する前記各ノードに付与されている階層番号および階層別番号を有するエントリが前記検索範囲に入っているか否かを各エントリの先祖関係からチェックする処理と、
該チェックの結果において前記検索範囲に含まれていなかったエントリを前記検索条件を満たすエントリから除外した後で、残りのエントリが前記検索範囲に含まれているか否かの判定を行う処理とをコンピュータに実行させるためのプログラムを記録した機械読み取り可能な記録媒体。 - 利用者からエントリの登録や削除や更新が行われた場合には、前記ディレクトリ階層の登録や削除や更新を行うとともに前記２分探索木の各ノードに付与されている階層番号および階層別番号の登録や削除や更新も行う処理をコンピュータに実行させるためのプログラムをさらに記録した請求項１１記載の機械読み取り可能な記録媒体。
- 検索条件として指定された属性値が文字列であった場合、該文字列の中から所定の文字数の部分文字列をすべて抽出する処理と、
検索条件として指定された属性値が文字列であった場合に該文字列から抽出された少なくとも１つの部分文字列によって前記所定の文字数の部分文字列をキーの１つとするマルチキーインデックスの探索を行い、前記各部分文字列毎の前記マルチキーインデックスの探索結果となったエントリのうちすべての部分文字列についての探索結果に含まれるエントリを前記検索条件を満たすエントリとする処理とをコンピュータに実行させるためのプログラムをさらに記録した請求項１１または１２記載の機械読み取り可能な記録媒体。 - 利用者から属性となっている文字列の更新要求があった場合に前記文字列から抽出された部分文字列のうちの探索結果が同一になる部分文字列についてはキー併合を行って該部分文字列が指すエントリの識別子を格納する場所を同一とする処理をコンピュータに実行させるためのプログラムをさらに記録した請求項１３記載の機械読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000039682A JP3752945B2 (ja) | 2000-02-17 | 2000-02-17 | ディレクトリ検索システム及び方法、ディレクトリ検索プログラムを記録したコンピュータ読取可能な記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000039682A JP3752945B2 (ja) | 2000-02-17 | 2000-02-17 | ディレクトリ検索システム及び方法、ディレクトリ検索プログラムを記録したコンピュータ読取可能な記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001229060A JP2001229060A (ja) | 2001-08-24 |
| JP3752945B2 true JP3752945B2 (ja) | 2006-03-08 |
Family
ID=18563209
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000039682A Expired - Fee Related JP3752945B2 (ja) | 2000-02-17 | 2000-02-17 | ディレクトリ検索システム及び方法、ディレクトリ検索プログラムを記録したコンピュータ読取可能な記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3752945B2 (ja) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU2004202360B2 (en) * | 2002-07-23 | 2004-09-16 | Samsung Electronics Co., Ltd | Index structure of metadata, method for providing indices of metadata, and metadata searching method and apparatus using the indices of metadata |
| WO2004010333A1 (en) * | 2002-07-23 | 2004-01-29 | Samsung Electronics Co., Ltd. | Encoded multi-key index data stream structure |
| JP2005534102A (ja) * | 2002-07-23 | 2005-11-10 | サムスン エレクトロニクス カンパニー リミテッド | メタデータのインデックス構造と記録媒体 |
| AU2004202362B2 (en) * | 2002-07-23 | 2004-09-16 | Samsung Electronics Co., Ltd | Index structure of metadata, method for providing indices of metadata, and metadata searching method and apparatus using the indices of metadata |
| AU2004202361B2 (en) * | 2002-07-23 | 2004-09-16 | Samsung Electronics Co., Ltd | Index structure of metadata, method for providing indices of metadata, and metadata searching method and apparatus using the indices of metadata |
| AU2004202364B2 (en) * | 2002-07-23 | 2004-09-16 | Samsung Electronics Co., Ltd | Index structure of metadata, method for providing indices of metadata, and metadata searching method and apparatus using the indices of metadata |
| EP1515247B1 (en) * | 2002-07-23 | 2007-06-27 | Samsung Electronics Co., Ltd. | Metadata searching method and apparatus using indices of metadata |
| US20120109990A1 (en) * | 2009-07-07 | 2012-05-03 | Nec Corporation | Information search system, information management device, information search method, information management method, and recording medium |
| JP5659880B2 (ja) * | 2011-03-08 | 2015-01-28 | 富士通株式会社 | 処理装置、分散処理システム、及び処理プログラム |
| CN108572953B (zh) * | 2017-03-07 | 2023-06-20 | 上海颐为网络科技有限公司 | 一种词条结构的合并方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04250568A (ja) * | 1991-01-25 | 1992-09-07 | Casio Comput Co Ltd | レコード検索装置 |
| JP2583010B2 (ja) * | 1993-01-07 | 1997-02-19 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 多層インデックス構造におけるローカルインデックステーブル及び大域インデックステーブルの間の一貫性を維持する方法 |
| JPH09223159A (ja) * | 1996-02-16 | 1997-08-26 | Nec Corp | 複合オブジェクト集合に対するデータベースアクセス方式 |
-
2000
- 2000-02-17 JP JP2000039682A patent/JP3752945B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001229060A (ja) | 2001-08-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4866495B2 (ja) | データベースシステムにおいて結合質問を実行する方法及び装置 | |
| US7558802B2 (en) | Information retrieving system | |
| EP0437159B1 (en) | Method for identifying documents having a particular attribute using a vector relational characteristical object | |
| US8224861B2 (en) | Coupled node tree splitting/conjoining method and program | |
| JP3914662B2 (ja) | データベース処理方法及び実施装置並びにその処理プログラムを記憶した媒体 | |
| EA007209B1 (ru) | Способ управления ключами в базе данных, база данных и способ организации базы данных | |
| EP1208478A1 (en) | Value-instance-connectivity computer-implemented database | |
| JP3752945B2 (ja) | ディレクトリ検索システム及び方法、ディレクトリ検索プログラムを記録したコンピュータ読取可能な記録媒体 | |
| US20060080282A1 (en) | Data management method and storage medium storing data management program | |
| JPH04260945A (ja) | ファイル・アクセス装置及びファイル・アクセス方法 | |
| JPH08235040A (ja) | データファイル管理システム | |
| Kvet | Database Block Management using Master Index | |
| JP4112282B2 (ja) | 関係データベース構築装置および方法 | |
| US20070078888A1 (en) | Method and System for Managing An Index Arrangement for a Directory | |
| JP2008065716A (ja) | データ管理装置、データ管理方法及びデータ管理プログラム | |
| JP2002140218A (ja) | データ処理方法、コンピュータ読み取り可能な記録媒体及びデータ処理装置 | |
| JP2000242538A (ja) | ディレクトリ検索システム、ディレクトリ検索方法およびディレクトリ検索用プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP4228267B2 (ja) | 集合属性検索システム、集合属性検索方法および集合属性検索プログラム | |
| JP3980326B2 (ja) | データ管理方法およびコンピュータ読み取り可能な記録媒体 | |
| JPH07121417A (ja) | データ管理装置 | |
| JP4014417B2 (ja) | 全文検索装置 | |
| JPS59146339A (ja) | 情報検索方式 | |
| JP2001134573A (ja) | 類似データ検索方法，類似データ検索装置，および類似データ検索用プログラム記録媒体 | |
| JPH11312166A (ja) | データベース管理装置 | |
| JP2001282823A (ja) | ディレクトリシステム、その管理方法、その管理方法を実施するためのプログラムを記録した記録媒体およびディレクトリシステムの検索方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041117 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20041119 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20041119 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050106 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20050106 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050106 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20051122 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051205 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091222 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091222 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101222 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101222 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111222 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111222 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121222 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121222 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131222 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |