(57)【要約】リレーショナルデータベースにおいてデータを調整し且つディレクトリサービスデータベースをサーチする方法及びシステムが提供される。特に、これのみというわけではないが、リレーショナルデータベースにおいてＸ．５００又はＬＤＡＰサービスを実現又は実施するシステム及びディレクトリが提供される。本発明はコンポーネントとしてテーブル内にデータタイプを格納し且つ所望のデータエントリに対するコンポーネントをサーチするデータベース構成を包含している。【特許請求の範囲】
【請求項１】
データベースにおいてデータを配列させる方法において、
データを格納するために適合されており且つ各データエントリに対して１つの行を持っている第一テーブルを作成し、
データコンポーネントを格納するために適合されおり且つ前記データの各コンポーネントに対して１つの行を持っている第二テーブルを作成する、
ことを包含している方法。
【請求項２】
請求項１において、前記データが構造型データタイプである方法。
【請求項３】
請求項１において、前記データがストリングデータタイプである方法。
【請求項４】
請求項１において、前記データがＸ．５０９証明書であるか又はそれを表わしている方法。
【請求項５】
請求項１において、前記データのコンポーネントがチェックサム又はフィンガープリントである方法。
【請求項６】
請求項１において、前記データベースが電子的ディレクトリサービスシステムの一部である方法。
【請求項７】
請求項６において、前記電子的ディレクトリサービスシステムがＸ．５００及びＬＤＡＰサービスシステムを有している方法。
【請求項８】
データ格納配列を持っているデータベースにおいて、
複数個の列を持っている少なくとも１つの行を包含しているサーチテーブル、
コンポーネント識別子列を包含している複数個の列を持っている少なくとも１つの行を包含しているサブサーチテーブル、
を有しているデータベース。
【請求項９】
請求項８において、前記サーチテーブルの列が「ＥＩＤ，ＡＩＤ，ＶＩＤ，Ｎｏｒｍ」の形態であり、ＥＩＤがそれに対して値が属しているオブジェクトを識別し、ＡＩＤはその値の属性タイプを識別し、ＶＩＤは１つのエントリにおける可能な数の属性値のうちの１つを識別するデータベース。
【請求項１０】
請求項８において、前記サーチテーブルの列が「ＥＩＤ，ＡＩＤ，ＶＩＤ，ＣＩＤ，Ｎｏｒｍ」の形態にあり、ＥＩＤはそれに対して値が属するオブジェクトを識別し、ＡＩＤは前記値の属性タイプを識別し、ＶＩＤは１つのエントリにおける可能な数の属性値のうちの１つを識別し、且つＣＩＤはコンポーネント識別子を識別するデータベース。
【請求項１１】
請求項８において、更に、前記サブサーチテーブルに対する記述又は参照が設けられている複数個の列を持っている少なくとも１つの行を包含しているサブ属性テーブルを有しているデータベース。
【請求項１２】
請求項１１において、前記サブ属性テーブルの列が「ＣＩＤ，ＳＹＮ，ＤＥＳＣ，ＯＢＪＥＣＴ　ＩＤ，ＦＬＡＧＳ」の形態にあるデータベース。
【請求項１３】
データ格納配列を持っているデータベースにおいて、
オブジェクト間の関係を定義する階層に向けられており且つオブジェクトあたり１つの行を有する形態とされている第一テーブル、
各オブジェクト内に１個又はそれ以上の値を定義するオブジェクトに向けられており且つ値当たり１つの行を有する形態とされている第二テーブル、
１つ又はそれ以上の選択したコンポーネントの値に向けられており且つ各値の各コンポーネントに対し１つの行を有する形態とされている第三テーブル、
を有しているデータベース。
【請求項１４】
データベースに関するディレクトリサービス要求を実施するディレクトリサービスシステムにおいて、
データを格納する構成とされており各データエントリに対し１つの行を持っている第一テーブル、
データコンポーネントを格納する構成とされており前記データの各コンポーネントに対して１つの行を持っている第二テーブル、
を有しているディレクトリサービスシステム。
【請求項１５】
請求項１４において、前記データが構造型データタイプであるディレクトリサービスシステム。
【請求項１６】
請求項１４において、前記データがストリングデータタイプであるディレクトリサービスシステム。
【請求項１７】
請求項１４において、Ｘ．５００か又はＬＤＡＰであるディレクトリサービスシステム。
【請求項１８】
データ格納配列を持っているディレクトリサービスシステムにおいて、
オブジェクト間の関係を定義する階層に向けられており且つオブジェクトあたり１つの行を有する形態とされている第一テーブル、
各オブジェクト内に１つ又はそれ以上の値を定義するオブジェクトに向けられており且つ値当たり１つの行を有する形態とされている第二テーブル、
値の１つ又はそれ以上の選択したコンポーネントに向けられており且つ各値の各コンポーネントに対して１つの行を有する形態とされている第三テーブル、
を有しているディレクトリサービスシステム。
【請求項１９】
請求項１８において、前記データが構造型データタイプであるディレクトリサービスシステム。
【請求項２０】
請求項１８において、前記データがストリングデータタイプであるディレクトリサービスシステム。
【請求項２１】
請求項１８において、Ｘ．５００か又はＬＤＡＰであるディレクトリサービスシステム。
【請求項２２】
与えられたデータエントリに対してデータベースをサーチする方法において、前記データベースはデータを格納すべく適合されており且つ各エントリに対して１つの行を持っている第一テーブルと、データコンポーネントを格納すべく適合されており且つ前記データの各コンポーネントに対して１つの行を持っている第二テーブルとを具備しており、
与えられたデータエントリのコンポーネントを決定し、
前記コンポーネントを探し出すために前記第二テーブルに関して正確又は初期的なマッチングのうちの１つを実行し、
前記探し出したコンポーネントとマッチングする前記与えられたデータエントリをリターンする、
ことを包含している方法。
【請求項２３】
請求項２２において、前記データベースが電子的ディレクトリサービスシステムの一部である方法。
【請求項２４】
請求項２２において、前記電子的ディレクトリサービスシステムがＸ．５００及びＬＤＡＰサービスシステムを有している方法。
【請求項２５】
請求項２２において、前記データがＸ．５０９証明書、及び／又はデータのチェックサム、及び／又はデータのフィンガープリントであるか又はそれを表わす方法。
【請求項２６】
請求項２３において、前記コンポーネントが前記データのチェックサム又はフィンガープリントである方法。
【請求項２７】
請求項２６において、前記サーチが前記フィンガープリント又はチェックサムを探し出すためにサーチテーブルを使用して行われる方法。
【請求項２８】
請求項２７において、更に、前記チェックサム又はフィンガープリントのコンポーネントがサーチされる方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はディレクトリサービスの分野に関するものである。更に詳細には、本発明はサーチにおいて使用されるデータベース配列におけるテーブル構造に対してリレーショナルデータベースにおける例えばＸ．５００又はＬＤＡＰ等の電子的ディレクトリサービスの適用及びデータベースサーチ方法に関するものである。
【０００２】
【従来の技術】
リレーショナルデータベース管理システム（ＲＤＢＭＳ）はデータを格納し且つ処理するための適用に対してのファシリティを提供している。ＲＤＢＭＳが提供する多数の特徴の中で、データの完全性、一貫性、並行性、インデックス用メカニズム、クエリィ（照会）最適化、リカバリィ（回復）、ロールバック、セキュリティ（安全性）がある。ＲＤＢＭＳは、又、性能チューニング、インポート／エクスポート、バックアップ、監査及びアプリケーション開発用の多数のツールを提供している。
【０００３】
ＲＤＢＭＳはデータの殆どの大規模マネージャに好適な選択である。ＲＤＢＭＳは容易に入手可能であり且つ信頼性があり且つ多数の有用な管理ツールを包含していることが知られている。ＲＤＢＭＳをインストールする大きな基礎、従ってこれらのシステムをラン即ち稼動させるための人的及び手順における大量の既存の熟練及び投資が存在しており、従ってデータマネージャは新しいシステムを取得する場合にこれを使用することを期待する。殆どのリレーショナルデータベース製品は業界標準ＳＱＬ（構造化照会言語）をサポートしている。
【０００４】
オブジェクト指向型システムに向かっての動きも存在しており、それは任意的に複雑なデータ項目を取扱うための能力及びデータ拡張性を提供する。更に、多くの会社及び政府機関は相互接続されていない多数のデータベースアプリケーションを有している。データマネージャは、彼等がそれらのデータを統合することを可能とさせ且つデータの管理を簡単化させることを可能とするソリューション即ち解決法を探している。電子的ディレクトリはこれらの目的を達成するツールをデータマネージャに提供するものである。幾つかの電子的ディレクトリは標準化されている。Ｘ．５００は電子的ディレクトリに対する国際的標準である（ＣＣＩＴＴ８９又はＩＴＵ９３）。これらの標準は非常に柔軟性があり且つ汎用的なディレクトリのサービス、プロトコル及び情報モデルを定義している。Ｘ．５００はデータがかなり静的（例えば、電話帳）である情報システムに対して適用可能であるが、分散型（例えば、組織又は組を横断し）、拡張可能（例えば、名前、住所、肩書き、デバイス等を格納）、オブジェクト指向型（即ち、データに関して規則を施行すること）及び／又は遠隔的にアクセスされるものとすることが必要な場合がある。Ｘ．５００及びそれと関連する標準等の電子的ディレクトリはデータマネージャがその目的を達成することを可能とする枠組及びある程度の機能性を提供している。
【０００５】
典型的に、データマネージャはオブジェクト指向型システムの全ての柔軟性を具備するが、現在のＳＱＬ製品の安定性、堅牢性、移植性及び費用効果性と結合されたリレーショナルシステムにおいて内在するスケーラビリティ即ち拡縮性及び性能をシステムが達成することが可能であるようにＳＱＬ製品を使用して例えばＸ．５００ディレクトリ等の電子的ディレクトリを実現することを所望する。
【０００６】
電子的ディレクトリ具体例の１つの例は米国特許出願第０９／４２７，２６７号及びそれの対応するオーストリア特許７１２４５１において記載されており、それらの特許出願及び特許を引用によってその全体を本明細書に取込む。この具体例に対するサーチ戦略においては、概念的レベルにおいて、例えばＮＡＭＥ、ＤＡＴ、ＴＲＥＥ等の階層テーブルを階層におけるオブジェクト間の関係を維持するために使用している。これらの階層テーブルはオブジェクト当たり１つの行に従って配列されている。例えばＳＥＡＲＣＨ（サーチ）及びＥＮＴＲＹ（エントリ）等のオブジェクトテーブルが１つのオブジェクト内における値を管理する。これらのオブジェクトテーブルは値当たり１つの行に従って配列されている。全てのオブジェクトは階層テーブルにおいて対応する行を有しており且つ全ての属性値は該オブジェクトテーブルにおいて対応する行を有している。この具体例においては、オブジェクトをサーチするために使用されるオブジェクトテーブルは（ＥＩＤ，ＡＩＤ，ＶＩＤ，Ｎｏｒｍ）の形態の行を包含しており、尚ＥＩＤはその値が属するオブジェクトを識別し、ＡＩＤはその値の属性タイプを識別し、ＶＩＤは１つのエントリにおける可能な数の属性値のうちの１つを識別し、Ｎｏｒｍ（ノルム）はシンタックス正規化値を包含している。例えば属性等の属性テーブルが属性タイプに関する情報を定義する。使用されている属性テーブルは（ＡＩＤ，ＳＹＸ，ＤＥＳＣ，ＯＢＪＥＣＴ　ＩＤ）の形態の行を包含している。
【０００７】
電子的ディレクトリ実現に対する改良は、複雑なデータタイプに対するデータベースを調節し且つサーチするために達成することが可能であることが判明した。
【０００８】
【課題を解決するための手段】
本発明は、格納されているデータ内に包含されているコンポーネントの１つ、格納されているデータの識別子及び／又は格納されているデータの処理等の何等かの形態の兆候を使用してデータタイプに対する格納及び／又はサーチに関するものである。この実現例は、データエントリに関する情報、例えばこれに制限するわけではないが個別的なコンポーネントを表わすコンポーネント識別子（ＣＩＤ）情報を包含するデータベースの特定のエントリに対してサーチを行う助けとなるか又は有用であると考えられる所定の情報及び／又はサーチのために使用される１個の多値コンポーネント又は複数個の多値コンポーネントを表わすコンポーネント値識別子情報（ＣＶＩＤ）を格納する新たなサーチ及び／又は属性テーブルを付加することによって複雑なデータタイプのサーチを簡単化させる。これらの新たなテーブルは、本明細書においては、サブサーチテーブル及び／又はサブ属性テーブルと呼称するものであり、それらは値のコンポーネントを格納すべく作用し且つ個別的なコンポーネント及び／又は多値コンポーネントのサーチを簡単化させる。然しながら、このようなテーブルは任意の名前で参照することが可能である。
【０００９】
１実施例においては、本発明はデータベースにおいてデータをアレンジ即ち配列又は調節する方法を提供している。本方法はデータを格納すべく適合されており且つ各データエントリに対して１つの行を持っている第一テーブルを作成し、且つデータコンポーネントを格納すべく適合されており且つ格納したデータタイプの各コンポーネントに対して１つの行を持っている第二テーブルを作成することを包含している。好適には、該データは構造型データタイプ又はストリングデータである。
【００１０】
本発明は、又、データ格納配列を持っているデータベース及び／又はディレクトリを提供している。本明細書の残部にわたってデータベースについて参照するが、本発明はディレクトリサービスシステムにも等しく適用されるものである。データ格納装置は、オブジェクト間の関係を定義するヒエラルキー即ち階層に向けられており且つオブジェクト当たり１つの行を有する形態とされている第一テーブル、各オブジェクト内において１つ又はそれ以上の値を定義するオブジェクトへ向けられており且つ値当たり１つの行を有する形態とされている第二テーブル、値の１つ又はそれ以上の選択したコンポーネント又は表示に向けられており且つ各値の各コンポーネントに対して１つの行を有する形態とされている第三テーブルを包含している。好適には、該データベースは、例えばＸ．５００又はＬＤＡＰサービスシステム等のディレクトリサービスシステムの一部である。本発明は、又、与えられたデータエントリに対するデータベースをサーチする方法を提供している。この実施例においては、データベースはデータを格納すべく適合されており且つ各データエントリに対して１つの行を有している第一テーブル、及びデータコンポーネント又は表示を格納すべく適合されており且つ格納されているデータの各コンポーネントに対して１つの行を有している第二テーブルを具備している。サーチ方法は与えられたデータエントリのコンポーネント又は表示を決定し、該コンポーネント又は表示を探し出すために該第二テーブルに関して正確な又は初期的なマッチングの１つを実行し、且つ探し出したコンポーネント又は表示とマッチングする与えられたデータエントリをリターンすることを包含している。
【００１１】
本明細書全体にわたり、「コンポーネント」という用語は、その代わりに又はそれに加えて、例えば逆インデックス又はポインタ又はフィンガープリント又はチェックサム又は比較的大きなデータの何等かの適宜のより小さな表示等の値の「表示」を包含することが可能である。
【００１２】
【発明の実施の形態】
図１ａはデータベース構成の例示的な実現例を示しており且つ本発明方法及び装置を適用することが可能なデータベースの１つのタイプに過ぎない。このデータベース構成のより詳細な説明は米国特許出願第０９／４２７，２６７号において見出すことが可能であり、尚、その全体を引用によって本明細書に取込む。図１ｂは図１ａのデータベース構成のより詳細な具体例を示している。通常、データベースを持っているディレクトリをサーチする場合に、サーチ引数がどこからサーチを開始するか（ベースオブジェクト）、サーチの範囲（サブセット）、サーチへ適用すべき条件（フィルタ）、及びサーチからどのような情報をリターンさせるべきであるか（選択）を定義する。該フィルタは例えばＡＮＤ、ＯＲ、ＮＯＴ等の演算子によって接続されている１つ又はそれ以上のフィルタ項目（即ち条件）の組み合わせである。
【００１３】
通常のサーチサービスの場合には、フィルタが、例えばサーチテーブルであるオブジェクトテーブルにおける値及び属性に対して適用される。一般的なフィルタの１つの例は「ＮＯＲＭ　ＬＩＫＥ　‘％ＲＩＣＫ　ＨＡＲＶＥＹ％’」である。特定のサーチサービスの場合には（以下により詳細に説明する）、データタイプの特定のコンポーネントをアドレスするコンポーネント識別子を包含するＳＱＬステートメントに文節を付加することが可能であり、且つ正確又は初期的（又は「で開始する」）フィルタがサーチテーブルの代わりにサブサーチテーブル内のコンポーネントへ適用される。このような文節の１つの例は「ＡＮＤ　ＣＩＤ＝Ｎ」であり、且つ正確なフィルタの１つの例は「ＮＯＲＭ＝‘ＲＩＣＫ　ＨＡＲＶＥＹ’」である。
【００１４】
図１ｂを参照すると、論理設計１及び物理設計２のテーブル構造は、サーチテーブル３、サブサーチテーブル４、属性テーブル５、サブ属性テーブル６を包含している。サーチテーブル３及び属性テーブル５は米国特許出願第０９／４２７，２６７号に記載されているサーチテーブル及び属性テーブルに類似しておりここにおいてのより詳細な説明は割愛する。サブサーチテーブル４はサーチの速度及び信頼性を改善するために使用される１個又はそれ以上のコンポーネントを包含する形態とさせることが可能である。例えば、サブサーチテーブル４はＣＩＤフィールド７及びＣＶＩＤフィールド８を包含することが可能である。ＣＩＤフィールド４はデータタイプのコンポーネントをサーチするツール（又はインデックス）として作用し、且つＣＶＩＤフィールド８は多値コンポーネントサーチ用のツール（又はインデックス）として作用する。本発明に基づく方法は上述したテーブルのうちの１つ又はそれ以上と共に使用することが可能であるが、好適には、特定のサーチクエリィに対して選択が存在するように各テーブルが設けられる。
【００１５】
属性テーブル５はサーチテーブル３における情報を記述するか又は参照し、且つサブ属性テーブル６はサブサーチテーブル４における情報を記述するか又は参照する。サブ属性テーブル６は属性テーブル５と同様のフィールドを有しているが、ＣＩＤフィールド９をＡＩＤフィールド１０と置換させている。ＣＩＤフィールド９はサブサーチテーブル４における１個又はそれ以上のコンポーネントを識別するために使用される。
【００１６】
サブサーチテーブル４は、好適には、複雑なデータタイプのコンポーネント又はサーチ性能を改善する情報を格納する。サブサーチテーブル内に格納されるその他のコンポーネントはデータベースの管理能力を改善するものとすることが可能である。換言すると、データエントリにおける全ての値がサブサーチテーブル内に包含されていることは条件ではない。
【００１７】
図２及び３を参照して、データベースをサーチする方法について説明する。サーチ例としては、ベースオブジェクト及び全部の３つのサーチ１１、１レベルサーチ１２、サブツリーサーチ１３を包含している。これらのサーチのより詳細な説明は米国特許出願第０９／４２７，２６７号において見出すことが可能である。ベースオブジェクトの範囲及び全体的なツリー１１を有するサーチはサーチテーブル３を使用する。ベースオブジェクトの範囲又は全体的なツリー１１を有しており且つ格納されているコンポーネントを利用することが可能なサーチはサブサーチテーブル４を使用する。１レベル１２の範囲を有しているサーチはＤＩＴテーブル１４とサーチテーブル３の間のジョイン即ち結合を使用する。１レベル１２の範囲を有しており且つ格納されているコンポーネントを利用することが可能なサーチはＤＩＴテーブル１４とサブサーチテーブル４との間のジョインを使用する。サブツリー１３の範囲を有しているサーチはツリーテーブル１５とサーチテーブル３との間のジョインを使用する。サブツリー１３の範囲を有しており且つ格納されているコンポーネントを利用するサーチはツリーテーブル１５とサブサーチテーブル４との間のジョインを使用する。
【００１８】
例示するために所望のサーチ引数が一般的なフィルタで構成されている場合には、ベースオブジェクト及び全体的ツリーサーチ１１はサーチテーブル３を使用し、１レベルサーチ１２はＤＩＴテーブル１４及びサーチテーブル３を使用し、且つサブツリーサーチ１３はツリーテーブル１５およびサーチテーブル３を使用する。このようなサーチに対するＳＱＬステートメントの１例は以下のものとすることが可能である。
【００１９】
【数１】
2004506963.tif 000002
【００２０】
然しながら、このようなサーチにおいて、適用したフィルタが、例えば、高度に反復性のデータストリング、データストリングの一部又は構造化データタイプのコンポーネントに対するものである場合には、データベースは多数の値を介してスキャンせねばならない場合があるのでそのサーチは遅く且つ非効率的なものである場合がある。
【００２１】
このようなサーチの効率を改善する１つの態様は、サブサーチテーブルを使用し且つ格納されているデータと関連する１個又はそれ以上のコンポーネントをサーチすることである。このような場合においては、データベースはストリング又は構造におけるコンポーネントに対するインデックスを使用することが可能な場合があり、従って多数の値をスキャンすることを回避する。このようなサーチに対するＳＱＬステートメントの１つの例は以下のようなものである。
【００２２】
【数２】
2004506963.tif 000003
【００２３】
この具体例においては、ベースオブジェクト及び全体的ツリーサーチ１１はサブサーチテーブル４を使用し、１レベルサーチ１２はＤＩＴテーブル１４及びサブサーチテーブル４を使用し、且つサブツリーサーチ１３はツリーテーブル１５及びサブサーチテーブル４３を使用する。この例においては、使用されるフィルタは格納されているデータのコンポーネントを参照し、そのことはインデックスを使用することを許容し且つより高速でより効率的なサーチとなる。この例において使用されるインデックスはＣＩＤ＝ｘを包含している。
【００２４】
構造化属性
本発明に基づく方法は種々のその他の適用例において使用することが可能である。１つの適用例はセキュリティ分野であり、その場合には標準化した証明書を格納するためにディレクトリが認証局によって益々使用されている。このような証明書の１つの例はＸ．５０９証明書である。Ｘ．５０９等の証明書は、多数のコンポーネントを包含しているので「複雑」な属性と呼ぶことが可能である。然しながら、本発明はこれらのタイプの証明書のみに制限されるべきものではない。本発明はコンポーネントを具備する任意の形態の情報と共に使用することが可能であることが理解される。
【００２５】
このような証明書を格納する場合には、証明書の検索が迅速且つ信頼性のあるものであるように（即ち、所望の証明書が実際に検索される）、どのようにして証明書を格納するかについての考慮がなされるべきである。本発明方法及びデータベース構成は、例えば連続番号、満了日及び発行者等の証明書内のデータのコンポーネントのうちの１つ又はそれ以上を見つけ出し且つ管理することによってこのことを達成する。
【００２６】
図４はＸ．５０９証明書への本発明の適用を示している。説明の便宜上、各テーブルの小さな部分のみを示してある。証明書２０は模式的に示してあり、且つ説明の便宜上、フィールド２１における発行者、フィールド２２における有効性情報、フィールド２３における連続番号、フィールド２４におけるバージョン番号、フィールド２５における主体情報（例えば、ｒｉｃｋ　ｈａｒｖｅｙ）等の情報のみを示してある。この例の場合には、サーチテーブル３が、証明書２０の各コンポーネント即ちフィールドの正規化した値を分離するスペース（好適には２個）と共に１つの行内に配列されている。このサーチテーブルは、更に、全体的な証明書を表わす正規化した値を包含している。サブサーチテーブル４が１つ又はそれ以上の行（２６，２７，２８，２９，３０）と共に配列されており、１つの行は証明書２０における１つのコンポーネント即ちフィールドに対応している。然しながら、注意すべきことであるが、サブサーチテーブル４は証明書２０において識別されているすべてのフィールドを包含することが必要なものではない。
【００２７】
この実施例に対する具体例を例示するために、簡単な証明書が、例えば連続番号、満期日、所有者名等の、クレジットカードを保持している場合と同様の情報から構成されているものと仮定する。この簡単な証明書は３個のコンポーネント即ちフィールドを有しており、即ち番号フィールドと、日付フィールドと、ストリングフィールドとを有している。この簡単化した例においては、サーチテーブル３（図１ｂにおける形態）で格納される証明書２０の正規化した値は以下の通りである。
【００２８】
【数３】
2004506963.tif 000004
【００２９】
サーチテーブル４は、例えば、３個の行、即ち該証明書の各コンポーネントに対して１個づつを格納することが可能である。該サブサーチテーブルの各行は以下に示すように図１ｂの形態にある。
【００３０】
【数４】
2004506963.tif 000005
【００３１】
尚、ｘｘ，ｙｙ，ｚｚは、例えばＥＩＤ、ＡＩＤ、ＶＩＤ等の特定のテーブル構成におけるフィールドに対応する整数である。
【００３２】
サーチテーブル３を使用する「ＲＩＣＫ　ＨＡＲＶＥＹ」に対して発行された証明書に対するサーチは以下のＳＱＬステートメントを使用することが可能である。
【００３３】
【数５】
2004506963.tif 000006
【００３４】
尚、一般的なフィルタは「ＮＯＲＭ　ＬＩＫＥ　‘％ＲＩＣＫ　ＨＡＲＶＥＹ％’」である。然しながら、このようなサーチに対してサーチテーブル３を使用することは遅い場合がある。何故ならば、各エントリに対するストリングの各コンポーネントが検査されねばならず且つサーチされ且つ検索されているストリングが所望のエントリである確実性の程度のためである。何故ならば、平坦化させた表示は非構造化テキスト表示であり境界を有していないからである。
【００３５】
正確な又は初期的なフィルタを適用する場合にサブサーチテーブル４が使用され且つサーチ引数に対してコンポーネント識別子が付加される場合には「ＲＩＣＫ　ＨＡＲＶＥＹ」に対して発行された証明書に対するサーチはより効率的なものである。この場合には、以下のＳＱＬステートメントを使用することが可能である。
【００３６】
【数６】
2004506963.tif 000007
【００３７】
尚、「ＮＯＲＭ＝‘ＲＩＣＫ　ＨＡＲＶＥＹ’」がフィルタであり、ＡＩＤ＝２７が証明書に対する属性識別子であり、且つＣＩＤ＝４が主体に対するコンポーネント識別子である。
【００３８】
上の例においては、コンポーネント識別子（即ちインデックス）ＣＩＤ＝４を有するサーチが使用されている。何故ならば、それはインデックスＣＩＤ＝４がカード保持者の名前を表わすストリングであることがサブサーチテーブル４のデザインから又はサブ属性テーブル６から既知であるからである。インデックスＣＩＤが４に設定される且つフィルタが「ＮＯＲＭ＝‘ＲＩＣＫ　ＨＡＲＶＥＹ’」である場合のクエリィはＲｉｃｋ　Ｈａｒｖｅｙの証明書をリターン即ち返すべきである。このクエリィはより良好なものであると考えられる。何故ならば、それはサーチをより高速なものとさせ且つそのサーチが正確な証明書を見つけ出す確実性の程度を増加させる適切なインデックスを利用することが可能だからである。注意すべきことであるが、サブサーチテーブルデザインにおけるキャラクタ／文字又は数字の実際の指定は任意であり、且つ特定の適用例に適するどのような態様にでも設計することが可能である。
【００３９】
再度図４を参照して、本発明に基づく方法の別の具体例について説明する。この具体例においては、サーチテーブル３Ａはチェックサム又はフィンガープリントを包含するように調整又は配列されたサーチテーブルである。サーチテーブル３Ａは何等かの属性タイプ、例えば二進に関する正確なマッチングのために使用されるので、このサーチテーブルにおける値はフィンガープリント又はチェックサムの値とすることが可能である。このことは格納することが必要とされるデータはより少ないので、サーチテーブルにおける格納をより効率的なものとさせる。
【００４０】
ストリング属性
本発明は、又、例えばストリングデータタイプ等の複雑でないデータタイプに対して使用することも可能である。ストリングデータタイプの例としては、マルチワード文章、テキストのマルチラインパラグラフ、及びマルチライン郵便アドレス等がある。この場合には、簡単な文章である属性値は以下の如くにしてサーチテーブルにおける単一の行内に格納することが可能である。
【００４１】
【数７】
2004506963.tif 000008
【００４２】
尚、列（又はフィールド）は（ＥＩＤ，ＡＩＤ，ＶＩＤ，ＮＯＲＭ）として定義されている。「ＷＯＲＤ」に対するストリングデータタイプをサーチするクエリィは部分的なワード「％ＷＯＲＤ％」に対する行を探すことが関与し、そのことは比較的遅いサーチであると考えられる。このようなデータのサーチを改善するために、ストリングをサブサーチテーブル４内におけるコンポーネントとして格納し、従ってストリング「ＭＡＮＹ　ＷＯＲＤ　ＳＥＮＴＥＮＣＥ」は以下の如くにして３つの行内に格納される。
【００４３】
【数８】
2004506963.tif 000009
【００４４】
尚、列は、夫々、（ＥＩＤ，ＡＩＤ，ＶＩＤ，ＣＩＤ，ＣＶＩＤ，ＮＯＲＭ）として定義されている。この例においては、適用されるフィルタはサーチテーブル３の代わりにサブサーチテーブル４を使用し、以下のＳＱＬステートメントを「ＷＯＲＤ」に対するサーチのために使用することが可能である。
【００４５】
【数９】
2004506963.tif 000010
【００４６】
その結果は著しく速いサーチである。何故ならば、上述した如く、部分的なワード「％ＷＯＲＤ％」を探すのではなく「ＷＯＲＤ」の正確なマッチを探すものだからである。
【００４７】
別のインデックス
本発明は、又、あるタイプのクリエィに対する性能を増加させる目的のために与えられている属性に対して１個又はそれ以上のインデックスを付加することが可能である問題に対して一般的な適用可能性を有している。インデックスを付加することは、例えば、逆インデックス等の属性を見つけ出すための異なる経路を提供する。この場合には、サブサーチテーブル内に１つのコンポーネントが存在するに過ぎない場合がある。該コンポーネントは、事実上、その属性値の別の形態を表わす。
【００４８】
特に、このサブサーチテーブルは、「ｅｎｄ　ｉｎ」サーチ問題、即ち格納されているデータの初期的部分が比較的高度に反復性である（例えば、著名な名前、ＭＡＣアドレス、電話番号、完全に資格が与えられたファイル名等）である値に対してのサーチを行う場合に、その値の逆の形態を格納しそれにより属性に関して逆にしたインデックスを有する効果を与えることによって問題に対処することが可能である。例えば、図５を参照すると、電話番号３１がサーチテーブル３２内にエンターされ、且つその電話番号は、又、逆の形態でサブサーチテーブル３３内にエンターされる。勿論、本発明のこの側面は逆の形態に制限されるものではなく、それは、例えば電話番号のエリアコードを別個のコンポーネントとして取扱うこと等の与えられた状態又はサーチに対して適切な任意のその他の妥当なデータエントリ形態とすることが可能である。
【００４９】
典型的に電話番号の終わりの部分である電話の内線に対してのサーチを行う場合には、サーチは「＊１２３４」（＊はワイルドカード）に対するストリングサーチとして表わすことが可能である。サーチテーブル３２のみが使用される場合には、そのサーチの性能は遅い。何故ならば、インデックスは「ｂｅｇｉｎ　ｗｉｔｈ」（で開始）又は「正確」なサーチに対してのみ可能だからである。然しながら、サーチテーブル３３内に逆に格納されている属性の場合には、例えば「４３２１＊」等の等価なサーチを行うためにサブサーチテーブルを使用することが可能であり、そのことは非常に高速であると考えられる。
【００５０】
より詳細には、サーチテーブル３２は以下の如くにある人に対する電話番号を格納する場合がある。
【００５１】
【数１０】
2004506963.tif 000011
【００５２】
且つ、サブサーチテーブル３３内には以下のものが格納される。
【００５３】
【数１１】
2004506963.tif 000012
【００５４】
且つ「１２３４」で終了する電話番号を見つけ出すためのＳＱＬステートメントは以下の形態のものとすることが可能である。
【００５５】
【数１２】
2004506963.tif 000013
【００５６】
サブサーチテーブル３３をサーチすることは、サーチテーブル３２をサーチすることよりも所望の記録をより速く検索することとなる。何故ならば、そのサーチは「４３２１」に対する初期的なマッチ（即ち「ｂｅｇｉｎ　ｗｉｔｈ」（で開始））に対するものであり、それはより速いサーチだからである。
【００５７】
別のインデックスの別の例は例えば写真又はオーディオ等の二進値のチェックサムの格納である。
【００５８】
別のインデックスの更に別の例は、例えば写真のより小さな表示等のデータのより小さな表示であるフィンガープリントの格納である。
【００５９】
本発明をＸ．５００ディレクトリサービスシステムを参照して開示したが、本発明はこのシステム及び本明細書に開示した方法に制限されるべきものではない。本明細書を全体的に読むことによって理解されるように、本発明は多数の異なるディレクトリサービスシステムにおいて適用又は実現することが可能であり又多様な方法を使用することが可能である。
【図面の簡単な説明】
【図１ａ】本発明に基づく例示的なデータベースの原理及び概念的構成を示した概略図。
【図１ｂ】サブサーチテーブル及びサブ属性テーブルを包含する本発明に基づく例示的なデータベースの論理的デザイン及び物理的デザインを示した概略図。
【図２】本発明に基づく高次サーチ方法を示した概略図。
【図３】本発明に基づく低次サーチ方法を示した概略図。
【図４】例示的なＸ．５０９証明書及び対応するサーチ及びサブサーチテーブルの例を示した概略図。
【図５】電話番号データコンポーネントに関連した例示的なサーチ及びサブサーチテーブルを示した概略図。
【図１ａ】
2004506963.tif 000014
【図１ｂ】
2004506963.tif 000015
【図２】
2004506963.tif 000016
【図３】
2004506963.tif 000017
【図４】
2004506963.tif 000018
【図５】
2004506963.tif 000019
【国際公開パンフレット】
2004506963.tif 000020
2004506963.tif 000021
2004506963.tif 000022
2004506963.tif 000023
2004506963.tif 000024
2004506963.tif 000025
2004506963.tif 000026
2004506963.tif 000027
2004506963.tif 000028
2004506963.tif 000029
2004506963.tif 000030
2004506963.tif 000031
2004506963.tif 000032
2004506963.tif 000033
2004506963.tif 000034
2004506963.tif 000035
2004506963.tif 000036
2004506963.tif 000037
2004506963.tif 000038
2004506963.tif 000039
2004506963.tif 000040
2004506963.tif 000041
2004506963.tif 000042
2004506963.tif 000043
2004506963.tif 000044
2004506963.tif 000045
2004506963.tif 000046
【国際公開パンフレット（コレクトバージョン）】
2004506963.tif 000047
【国際調査報告】
2004506963.tif 000048
2004506963.tif 000049
2004506963.tif 000050
2004506963.tif 000051