(57)【要約】要約書なし。【特許請求の範囲】
【請求項１】
データベースサービスクエリーを処理する方法において、
１つ又はそれ以上のフィルタ項目を具備するフィルタを包含しているサービスクエリーを受取り、
前記フィルタを展開し、
各フィルタ項目に対して条件テストを適用して前記フィルタ項目がＮＯＴ連結語を包含しているか否か且つ前記フィルタ項目が２つのタイプのフィルタ項目のうちの１つであるか否かを判別する、
ことを包含している方法。
【請求項２】
請求項１において、前記２つのタイプのフィルタ項目がタイプのみのフィルタ項目及びタイプ及び値のフィルタ項目を包含している方法。
【請求項３】
請求項２において、タイプのみのフィルタ項目と関連するＮＯＴ連結語を評価するために論理的方法論を適用する方法。
【請求項４】
請求項３において、前記論理的方法論が減算方法を有している方法。
【請求項５】
請求項２において、タイプ及び値のフィルタ項目と関連するＮＯＴ連結語が前記フィルタ項目内にプッシュされ、前記フィルタ項目内のオペレータを変化させる方法。
【請求項６】
請求項１において、前記条件テストが、更に、各フィルタ項目を真であると予め評価することが可能であるか否かを判別することを包含している方法。
【請求項７】
請求項１において、前記条件テストが、更に、前記展開した項目を無視することが可能であるように各フィルタ項目を偽であると予め評価することが可能であるか否かを判別することを包含している方法。
【請求項８】
請求項１において、前記フィルタを最小組の項目へ展開させる方法。
【請求項９】
ディレクトリサービス構成において、
各テーブルがサーチサービスにおける任意のデータを格納する複数個の行及び列を具備しており、前記テーブルのうちの少なくとも１つが少なくとも１つのフィルタ項目を具備するフィルタを分解するために使用する情報を具備している複数個のテーブル、
各フィルタを展開した項目へ展開する手段、
各フィルタ項目がＮＯＴ連結語を包含しているか否か及び各フィルタ項目が２つのタイプのフィルタ項目のうちの１つであるか否かを判別する条件テスト手段、
を有しているディレクトリサービス構成。
【請求項１０】
請求項９において、前記２つのタイプのフィルタ項目がタイプのみのフィルタ項目とタイプ及び値のフィルタ項目とを有しているディレクトリサービス構成。
【請求項１１】
請求項１０において、タイプのみのフィルタ項目と関連するＮＯＴ連結語を評価するために論理的方法論が適用されるディレクトリサービス構成。
【請求項１２】
請求項１１において、前記論理的方法論が減算方法を有しているディレクトリサービス構成。
【請求項１３】
請求項１０において、タイプ及び値のフィルタ項目と関連するＮＯＴ連結語が前記フィルタ項目内にプッシュされ、前記フィルタ項目内のオペレータを変化させるディレクトリサービス構成。
【請求項１４】
請求項９において、前記条件テスト手段が、更に、各フィルタ項目を真であると予め評価することが可能であるか否かを判別するディレクトリサービス構成。
【請求項１５】
請求項９において、前記条件テスト手段が、更に、前記展開した項目を無視することが可能であるように、各フィルタ項目を偽であるとして予め評価することが可能であるか否かを判別するディレクトリサービス構成。
【請求項１６】
請求項９において、前記条件テスト手段が、更に、前記展開した項目を無視することが可能であるように、各フィルタ項目を真であるとして予め評価することが可能であるがＮＯＴ連結語により反転されているか否かを判別するディレクトリサービス構成。
【請求項１７】
データベースサービスクエリーを処理する方法において、
サービスクエリーを受取り、
フィルタを前記サービスクエリーに対して適用しゼロ又はそれ以上のフィルタ項目を発生し、
各フィルタ項目に対して条件テストを適用して前記フィルタ項目のフォームを決定する、
ことを包含している方法。
【請求項１８】
請求項１７において、前記条件テストが、前記フィルタ項目がタイプのみのフィルタ項目であるか否かを判別する方法。
【請求項１９】
請求項１８において、更に、前記フィルタ項目がタイプのみのフォームである場合に論理的方法論に従って前記フィルタ項目を評価することを包含している方法。
【請求項２０】
請求項１９において、前記論理的方法論が減算方法を包含している方法。
【請求項２１】
請求項２０において、前記減算方法がＡＮＳＩ  ＳＱＬ「ｅｘｃｅｐｔ」句の使用を包含している方法。
【請求項２２】
請求項２０において、前記減算方法が各フィルタ項目をより少ない数又はゼロのＮＯＴ設定連結語を包含しているフォームへ変換させる方法。
【請求項２３】
請求項１７において、前記条件テストが、前記フィルタ項目がタイプ及び値のフィルタ項目であるか否かを判別する方法。
【請求項２４】
請求項２３において、前記フィルタ項目がタイプ及び値のフォームである場合に、前記フィルタ項目を表わすＳＱＬを少なくとも１つのテーブルジョインを包含する場合のある評価すべき式へ付加する方法。
【請求項２５】
請求項２３において、前記フィルタ項目が前記タイプ及び値のフィルタ項目の反転したものである場合には、前記ＮＯＴ連結語を前記フィルタ項目内へプッシュする方法。
【請求項２６】
請求項２５において、更に、前記プッシュしたＮＯＴ連結語をオペレータに対して適用することを包含している方法。
【請求項２７】
請求項２６において、前記プッシュしたＮＯＴを適用するステップが前記オペレータを反転させることにより実行させる方法。
【請求項２８】
ディレクトリサービス構成において、
各テーブルが複数個の行及び列を具備しており、且つ任意のデータを格納し、前記テーブルのうちの少なくとも１つがサーチサービスにおいてフィルタを分解するために使用される情報を具備している複数個のテーブル、
フィルタ項目がタイプのみのフィルタ項目か又はタイプ及び値のフィルタ項目であるか否かを判別する条件テスター、
を有しているディレクトリサービス構成。
【請求項２９】
コンピュータプログラムプロダクトにおいて、
その上に具現化されているコンピュータが読取可能なプログラムコードを具備しているコンピュータによって使用可能な媒体、
を有しており、前記コンピュータによって読取可能なプログラムコードが前記フィルタ項目がタイプのみのフィルタ項目か又はタイプ及び値のフィルタ項目かを判別するためにフィルタの各フィルタ項目に対して条件テストを適用するためのものであり、且つ前記フィルタはディレクトリサービス構成のサーチサービスと相互作用を行うべく適合されているコンピュータプログラムプロダクト。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースの動作性能に関するものであって、更に詳細には、ディレクトリサービスが与えられる場合のその性能に関するものである。
【背景技術】
【０００２】
データマネージャは相互接続されていないアプリケーションからのデータを統合させ且つそのデータの管理を簡単化させるためのツールとして電子ディレクトリを利用する。幾つかの電子ディレクトリは例えばＸ．５００又はＬＤＡＰ等の標準化されており、且つ迅速に情報を格納し且つ検索するために例えばサーチサービス等の種々のサービスを提供する。Ｘ．５００又はＬＤＡＰサーチサービスは、適用可能である場合には、どこからサーチを開始するか（ベースオブジェクト）、サーチの範囲（サブセット）、サーチに適用する条件（フィルタ）及びどのような情報を介すべきか（選択）を表わす引き数を使用して実施される。更に、例えば時間限界、寸法限界等のフラッグがパスされて、存在する場合に、エイリアス（ａｌｉａｓｅ）をデリファレンス（ｄｅｒｅｆｅｒｅｎｃｅ）すべきであるか否かを表わす（ｓｅａｒｃｈＡｌｉａｓｅ）。
【０００３】
フィルタは空の場合もあり、単一のフィルタ項目からなる場合もあり、又は連結語（例えば、ＡＮＤ、ＯＲ、ＮＯＴ）を使用するフィルタ項目の複合式である場合もある。これらの連結語は任意の複雑なフィルタを形成するために使用することが可能である。例えば、ユーザは、サラリー（ｓａｌａｒｙ）が６０，０００ドルを超えており且つデータベースにリストされている携帯電話（ｍｏｂｉｌｅ  ｐｈｏｎｅ）を有しているか、又はその組織のあるオフィス（「Ｍｅｌｄ」で開始するか又は「Ｓｙｄ」で開始する）内には存在しないその組織のマネージャ（ｍａｎａｇｅｒ）の肩書き（ｔｉｔｌｅ）（存在する場合）を探し出すためにディレクトリに質問を所望する場合がある。
【０００４】
このような要求はサーチクエリーにより実施することが可能であり、その場合に、
【０００５】
【数０】
2005510777.tif 000002
【０００６】
であり、この式は、又、論理式として表わすことが可能であり、
【０００７】
【数１】
2005510777.tif 000003
【０００８】
尚、フィルタ項目は文字（Ａ，Ｂ，Ｃ，Ｄ，Ｅ）によって表わされており、且つ連結語は、ＡＮＤ連結語に対して「．」、ＯＲ連結語に対して「＋」、ＮＯＴ連結語に対して「！」によって表わされている。
【０００９】
データベースがメタデータデザインを有する場合には、上の式１は以下の形式の自己ジョインが関与するＳＱＬステートメントへ変換させることが可能である。
【００１０】
【数２】
2005510777.tif 000004
【００１１】
尚、「ｅｉｄ」はサーチにより返されるエントリ識別子を表わすために使用され、且つ（ａ），（ｂ），（ｃ），（ｄ），（ｅ）はフィルタ項目の各々に対する関連するＳＱＬを表わしている。
【００１２】
少なくともユーザの観点からは、クエリーに対して比較的迅速な応答を有することが通常望ましい。勿論、サーチ可能な数百満個のエントリが存在する可能性のあるリレーショナルデータベースと関連して稼動しているＳＱＬを基礎としたＸ．５００又はＬＤＡＰアプリケーションにおいては、応答時間は重要である。ＳＱＬステートメントを処理するのにかかる時間は、通常、図１に示したように、複雑性が増加するに従い迅速に増加する。この効果は、ＳＱＬがＮＯＴ連結語を包含する場合に最も顕著である。この複雑性における増加は、又、時間限界又は寸法限界に到達する前に結果が返されることがないという危険性を発生する。その結果、このようなアプリケーションの開発者は、比較的な複雑なＳＱＬステートメントを回避する傾向となる。
【００１３】
ＯＲ連結語を包含する項目の最適化
ブール論理等の論理原理を使用して、任意的に複雑なサーチフィルタを多数の比較的より簡単な項目へ展開させることが可能である。通常、このことは、複雑なサーチフィルタにおける括弧を除去することが関与し、「項目の和」としても知られる「ＡＮＤのＯＲ」である式となる。複雑なフィルタサーチを展開させることは、又、ＮＯＴ連結語を分散させて各ＮＯＴ連結語が単一のフィルタ項目に適用されることとなる場合がある。
【００１４】
以下の式３においてフィルタ内のＮＯＴ連結語を展開する例においては、
【００１５】
【数３】
2005510777.tif 000005
【００１６】
以下のフィルタ項目となり、
【００１７】
【数４】
2005510777.tif 000006
【００１８】
尚、！Ａは１つのフィルタ項目であり且つ！Ｂは別のフィルタ項目である。同様に、以下の式５のフィルタにおけるＮＯＴ連結語を展開すると、
【００１９】
【数５】
2005510777.tif 000007
【００２０】
以下のフィルタ項目となる。
【００２１】
【数６】
2005510777.tif 000008
【００２２】
このフィルタ項目は、更に、括弧を取除くことにより展開させることが可能であり、且つその結果より得られるフィルタ項目は以下の式７におけるＡ．Ｂ．Ｃ．及びＡ．Ｂ．！Ｄ．！Ｅである。
【００２３】
【数７】
2005510777.tif 000009
【００２４】
式７となる上の展開は、２つのフィルタ項目をＯＲ処理していることを示している。式４及び７の各フィルタ項目を処理し且つデュープリケートを無視しながらアプリケーションによりその結果を加算させることが可能である。これは多数の利点を有しており、即ち、
ａ  より簡単なＳＱＬステートメントの発生はサーチのより速い処理となり、
ｂ  以下に説明し且つ引用によりその全体を本明細書に取込むアメリカ特許出願第０９／４２７，２６６号においてより詳細に記載されているより効率的なＳＱＬステートメント及び向上させたＮＯＴ連結語処理、
ｃ  データベースサービスクエリーが実施される場合に寸法限界及び時間限界を課し且つチェックする能力は、しばしば、性能の改善に繋がる、
等である。
【００２５】
ＡＮＤ連結語を包含する項目の最適化
複雑なフィルタサーチを多数のより簡単なフィルタ項目へ展開した後に、ＡＮＤ連結語のみを包含する結果的に得られたフィルタ項目が、尚且つ、ＳＱＬステートメントへ変換された場合に比較的非効率的な表現となる場合がある。例えば、式
【００２６】
【数８】
2005510777.tif 000010
【００２７】
は、次の形態のＳＱＬステートメントへ変換させることが可能である。
【００２８】
【数９】
2005510777.tif 000011
【００２９】
然しながら、上の式７によって例示されるように、フィルタ項目は１つを超えるＡＮＤ連結語を得る場合があり、且つ通常、式９にＡＮＤ連結語が多ければ多い程、特に処理応答時間を考える場合に、結果的に得られるＳＱＬステートメントはより効率が悪い場合がある。
【００３０】
ＳＱＬステートメントの複雑性を減少させる１つの方法は「フラットニング（ｆｌａｔｔｅｎｉｎｇ）」即ち平坦化として知られている。入れ子型ＳＱＬステートメントは、ＳＱＬストーメントをフラットニングすることにより減少させることが可能である。例えば、ステートメント９は次の形態のＳＱＬステートメントを生成するためにフラットニングさせることが可能である。
【００３１】
【数１０】
2005510777.tif 000012
【００３２】
このステートメント１０は多数のセルフジョイン（各ＡＮＤ連結語に対して１つ）を有しており、且つクエリーオプティマイザーがより強い句を最初に処理することを可能とし、従ってクエリーを評価するのに必要な全体的な処理時間を減少させる。
【００３３】
ＮＯＴ連結語が関与する式は、ＬＥＦＴ  ＪＯＩＮを包含するフラットニングしたクエリーとなる場合がある。これらのジョインは、通常、処理するのに時間がかかり、従ってこのようなクエリーの「フラットニング」は改善が必要であると考えられる。
【００３４】
例えば、次の式、
【００３５】
【数１１】
2005510777.tif 000013
【００３６】
は次の形態のフラットニングさせたＳＱＬステートメントへ変換させることが可能である。
【００３７】
【数１２】
2005510777.tif 000014
【００３８】
フィルタ項目が１つを超えるＮＯＴフィルタ項目を包含している場合、例えばＡ．！Ｂ．！Ｃ等の場合、フラットニングしたクエリーは各ＮＯＴに対してＬＥＦＴ  ＪＯＩＮを包含するが、又、ＮＯＴフィルタ項目の各組合わせに対してジョインを包含している。このことは非常に複雑なものとなる場合がある。従って、サービスクエリー性能を改善する態様で比較的複雑なＳＱＬステートメントを回避することの必要性が存在している。
【発明の開示】
【発明が解決しようとする課題】
【００３９】
本発明は、１つの実施例の側面において、改善したサービスクエリー性能が得られるデータベースサービスクエリーを処理する方法を提供するものである。
【課題を解決するための手段】
【００４０】
この実施例においては、本方法は、１つ又はそれ以上のフィルタ項目を具備するフィルタを包含するサービスクエリーを受取り、該フィルタを展開し、且つ各フィルタ項目に対して少なくとも１つの条件テストを提供することを包含している。テスト条件の１例は、各フィルタ項目がＮＯＴ連結語を包含しており且つ第一形態又は第二形態のいずれかであるかを判別することを包含している。該第一形態はタイプのみの形態とすることが可能であり、且つ該第二形態はタイプ及び値の形態とすることが可能である。
【００４１】
該条件テストの別の例は、該フィルタ項目が真であるとして予め評価することが可能であるか否かを判別し、又は該フィルタ項目が偽であるとして予め評価し、それにより全体的な展開した項目を無視することが可能であるか否かを判別することを包含している。
【００４２】
本発明は、別の実施例においては、各々が複数個の行及び列を具備しており且つ任意のデータを格納しそのうちの少なくとも１つのテーブルがサーチサービスにおいてフィルタを分解するために使用される情報を具備するサーチ（ｓｅａｒｃｈ）テーブルである複数個のテーブルと、展開された項目となる各フィルタ項目を展開する手段と、フィルタ項目のＮＯＴが第一形態か又は第二形態の一方であるか否かを判別する手段とを有するディレクトリサービス構成を提供している。該第一形態はタイプのみの形態とすることが可能であり、且つ第二形態はタイプ及び値の形態とすることが可能である。
【００４３】
該条件テスト手段は、更に、該フィルタ項目が真であるとして予め評価することが可能であるか否か、又は該フィルタ項目が偽であるとして予め評価することが可能であるか否かを判別することが可能である。該フィルタ項目が偽であると判別される場合には、全体的な展開された項目を無視することが可能である。
【００４４】
別の実施例においては、本発明はデータベースサービスクエリーを処理する方法を提供し、その場合に、フィルタをサービスクエリーに適用してゼロ又はそれ以上のフィルタ項目を発生し、且つ各フィルタ項目に関して条件テストを使用して該フィルタ項目のフォーム（ｆｏｒｍ）即ち形態を決定する。好適には、該条件テストは、フィルタ項目の形態がタイプのみの形態であるか又はフィルタ項目の形態がタイプ及び値の形態のいずれであるかを判別する。該フィルタ項目がタイプのみの形態である場合には、該フィルタ項目は例えばＡＮＳＩ  ＳＱＬ「ｅｘｃｅｐｔ」句等の減算方法に従って評価される。好適には、該減算方法は、フィルタ項目を評価する式をより少ない数又はゼロのＮＯＴ連結語を包含する形態へ変換させる。
【００４５】
上述した実施例の方法は、更に、該フィルタ項目の形態がタイプ及び値の形態であるか否かを判別し、且つ該フィルタ項目を表わすＳＱＬクエリー言語を評価されるべき式へ付加することを包含している。この処理は、少なくとも１つのテーブルジョイン操作を包含する場合がある。
【００４６】
該フィルタ項目の形態がタイプ及び値の形態のＮＯＴである場合には、該ＮＯＴ連結語は該フィルタ項目内にプッシュ即ち押し込められる。
【００４７】
本発明の別の実施例は、各テーブルが複数個の行及び列を具備しており且つ任意のデータを格納し、そのうちの少なくとも１つのテーブルがサーチサービスにおいてフィルタを分解するために使用される情報を具備しているサーチ（ｓｅａｒｃｈ）テーブルである複数個のテーブルと、フィルタ項目がタイプのみであるか又はタイプ及び値であるかを判別するための条件テスト手段とを包含しているディレクトリサービス構成を提供する。
【００４８】
その他の実施例は、フィルタ項目がタイプのみであるか又はタイプ及び値であるか否かを判別するためにフィルタの各フィルタ項目に対して条件テストを適用するためにその上に具現化されているコンピュータによって読取可能なプログラムコード及びコンピュータによって読取可能なシステムコードを具備しているコンピュータによって使用可能な媒体を包含しているコンピュータプログラムプロダクトを包含しており、該フィルタはディレクトリサービス構成及び／又はコンピュータプログラムプロダクトのサーチサービスに対して適用されるべく適合されている。この実施例においては、該コンピュータプログラムプロダクトは、フィルタ項目がタイプのみの形態であるか又はタイプ及び値の形態であるか否かを判別するためにフィルタの各フィルタ項目に対して条件テストを適用するためにその上に具現化されているコンピュータによって読取可能なプログラムコード及びコンピュータによって読取可能なシステムコードを具備しているコンピュータによって使用可能な媒体を包含しており、該フィルタはディレクトリサービス構成のサーチサービスに対して適用されるべく適合されている。
【００４９】
本発明は、又、データベースサービスクエリーを処理する方法を提供しており、その場合に、フィルタ項目を具備するフィルタを展開し、フィルタ項目を予め評価し、且つ該フィルタ項目を評価するステップが設けられている。
【００５０】
データベースサービスクエリーを処理する方法は、複数個のフィルタ項目を発生するサービスクエリーに対してフィルタを適用し、且つ比較的大きな項目を処理する前に比較的小さな項目を処理することを包含している。
【００５１】
定義
当業者の理解に加えて、以下の用語及び語句は、又、以下のものを包含している。
【００５２】
「フィルタ」という用語は、ディレクトリサーチに対して適用される条件を表わす式を参照する。フィルタの１例は上の式３において与えられている！（Ａ．Ｂ）である。
【００５３】
「展開した項目」又は「フィルタ項目」という語句は展開された「フィルタ」の１つ又はそれ以上のコンポーネントを参照する。展開された項目の例は上の式７において与えられているＡ．Ｂ．Ｃ又はＡ．Ｂ．！Ｄ．！Ｅを包含している。
【００５４】
「フィルタ項目」という語句は「フィルタ」又は「フィルタ項目」のいずれかのコンポーネントの一部を参照し、又は例えば（Ｘ＋Ｙ）等の式を参照する場合がある。フィルタ項目の例は式１０３のコンポーネントＡ又はＢ又は式１０７又は例えば（Ｘ＋Ｙ）等の式のコンポーネントＡ，Ｂ，Ｃ，！Ｄ又は！Ｅを包含している。
【００５５】
注意すべきことであるが、コンポーネントＡ，Ｂ，Ｃ，Ｄ，Ｅ又はその他の証印、本明細書にわたって使用されるコンポーネント又は数字は、ディレクトリサービス及び／又はディレクトリサービスクエリー（例えば、式０において表わされているクエリー）を表わすために使用される。
【発明を実施するための最良の形態】
【００５６】
ＮＯＴ連結語を包含する項目の最適化
本発明に基づく方法は、２つのタイプのフィルタ項目又はフィルタ項、１）タイプのみ（が存在する）フィルタ項目、及び２）タイプ及び値のフィルタ項目が存在することを実現している。注意すべきことであるが、以下に説明する種々の実施例はタイプのみのフィルタ項目又はタイプ及び値のフィルタ項目を説明する場合がある。理解すべきことであるが、フィルタ項はフィルタ項目又はフィルタ項目の結合に対して置換させることが可能であり、且つフィルタ項は本発明に基づく方法により実現することが可能である。
【００５７】
タイプのみのフィルタ項目は例えば「ｓｕｒｎａｍｅ  ｐｒｅｓｅｎｔ」等の「ｐｒｅｓｅｎｔ」オペレータを包含している。タイプ及び値のフィルタ項目は属性と、オペレータと、値とを包含しており、例えばｓｕｒｎａｍｅ＝ＨＡＲＶＥＹである。値を必要とするオペレータは＝、＞＝、＜＝及びサブストリングを包含している。
【００５８】
図２は比較的簡単な形態での本発明の１実施例に基づく動作の流れを例示している。ディレクトリサービスクエリーは多数のフィルタ項に展開させることが可能であり、そのうちのいずれかは異なる程度の複雑性を有することが可能である。本発明に基づく方法はフィルタ項目がタイプのみであるか又はタイプ及び値のフィルタ項目であるか否かに関し、且つ該フィルタ項目がＮＯＴ連結語により操作されるものであるか否かに関し該フィルタ項における各フィルタ項目に対しての判別を包含している。フィルタ項目がタイプのみ又はタイプ及び値であることの判別は、ここでは、条件テストとして知られている。
【００５９】
ＮＯＴ連結語を具備するフィルタ項目がタイプのみのフィルタ項目である場合には、論理的方法論を使用してＳＱＬにおけるＮＯＴを回避するフィルタ項目を評価又は処理することが可能である。この論理的方法論は、以下の式１７に表わした減算方法又はフィルタ項目がＮＯＴ連結語を包含することがないように式を展開することが可能な任意のその他の適宜の方法論とすることが可能である。
【００６０】
ＮＯＴ連結語を具備するフィルタ項目がタイプ及び値のフィルタ項目である場合には、本発明は該ＮＯＴ連結語を外側のＳＱＬにおいてＮＯＴを回避するフィルタ項目内へ
プッシュ即ち押込む。適用される減算方法が、ＮＯＴ連結語により操作されている属性（タイプ）が存在する属性に対するテストを包含することを考慮に入れる限り、減算方法を使用することも可能である。このことについては図５を参照して以下に更に詳細に説明する。
【００６１】
上述した更なる評価又は処理について参照するが、本発明の方法論は「条件テスト」をＮＯＴ連結語を有する各フィルタ項目に対して適用することを理解すべきである。
【００６２】
ＮＯＴ処理と関連する１つの考慮事項は、その属性（タイプ）を包含することのないエントリに対してタイプ及び値のフィルタ項目を適用することは未定義であるということである。この考慮事項をより良く理解するために、以下に多数の例について詳細に説明する。図３を参照すると、データベースにおけるエントリＥ１，Ｅ２，Ｅ３が与えられ、各々はサーチ可能な情報を包含しており、且つ夫々参照番号１０，１１，１２で示されている。エントリＥ１，Ｅ２，Ｅ３が格納されているデータベースにおいて情報をサーチすることを所望するユーザは、所望の情報を検索するために１つ又はそれ以上のフィルタを利用することが可能である。
【００６３】
例えば、１つのサーチＳ１はフィルタ項目Ｂ１を具備するフィルタを包含する場合があり、従ってＲｉｃｋで開始する一般的な名前を有するエントリに対するサーチ（ｃｎ＝ｒｉｃｋ：＊、尚「＊」は任意のその他の証印を表わしている）がエントリＥ１，Ｅ２，Ｅ３に対して適用される。このサーチＳ１はエントリＥ１及びＥ２が識別されることとなる。何故ならば、これらのエントリにおいては、ｃｎ＝ｒｉｃｋ又はｒｉｃｋｙだからである。
【００６４】
別のサーチＳ２はフィルタ項目！Ｂ１を具備するフィルタを包含している場合があり、従ってＮＯＴ  Ｂ１に対するサーチ（ＮＯＴ（ｃｎ＝ｒｉｃｋ＊））がエントリＥ１，Ｅ２，Ｅ３に対して適用される。このサーチＳ２はＥ３が識別されることとなる。何故ならば、Ｅ３がｒｉｃｋ＊で開始する値を有することのない一般的な名前を包含する唯一のエントリだからである。このサーチの場合には、エントリの全てが一般的な名前を包含しているので上述した考慮事項は処理される。更に、Ｓ１はＳ２の反転であり且つエントリの全てを考慮し、従ってこれらのサーチはタイプのみのフィルタ項目での逆サーチということが可能であり、それは次のように表わすことが可能である。
【００６５】
【数１３】
2005510777.tif 000015
【００６６】
別の例においては、再度図３を参照すると、サーチＳ３はフィルタ項目Ｂ２を具備するフィルタを包含する場合があり、従って５より大きな靴寸法（ｓｈｏｅ  ｓｉｚｅ＞５）でのエントリに対するサーチがＥ１，Ｅ２，Ｅ３に対して適用される。このサーチは、エントリＥ１が識別されることとなる。何故ならば、Ｅ１は、靴の寸法及び５より大きな靴の寸法を定義する唯一のエントリだからである。
【００６７】
別のサーチＳ４はフィルタ項目！Ｂ２を具備するフィルタを包含しており、従ってＮＯＴ  Ｂ２に対するサーチ（ＮＯＴ５より大きな靴寸法）がエントリＥ１，Ｅ２，Ｅ３に対して適用される。このサーチはエントリが識別されるマッチングを発生することはない。何故ならば、このフィルタ項目はエントリＥ１に対して決定可能な結果を与えるに過ぎないからである。このフィルタをエントリＥ２及びＥ３に対して適用することは未定義である。何故ならば、これらのエントリは靴寸法属性を有するものではないからである。
【００６８】
フィルタ項目！Ｂ２を具備するサーチＳ４の結果は該フィルタの適用が「未定義」であるエントリを包含することが不可能であるので、サーチＳ３及びＳ４は互いに反転即ち逆のものではなく且つ全ての可能なエントリをカバーするものではなく、従って以下の如くに表わすことが可能である。
【００６９】
【数１４】
2005510777.tif 000016
【００７０】
このことから、これらのフィルタ項目はタイプ及び値のフィルタ項目であることを理解することが可能である。
【００７１】
図２に例示したように「ｐｒｅｓｅｎｔ」に対するテストはバイナリーであるので、タイプのみのフィルタの場合には複雑性を存在しない。例えば、フィルタ項目Ｂ３「ｓｈｏｅ  ｓｉｚｅ  ｐｒｅｓｅｎｔ」を有するフィルタを包含するサーチＳ５はエントリＥ１が識別されることとなる。何故ならＥ１が靴寸法属性を有する唯一のエントリだからである。
【００７２】
別のサーチＳ６はフィルタ項目！Ｂ３「ｎｏｔ  ｓｈｏｅ  ｓｉｚｅ  ｐｒｅｓｅｎｔ」を有するフィルタを包含しており、それはエントリＥ２及びＥ３が識別されることとなる。何故ならば、「ｎｏｔ」サーチは定義可能であり、即ちその属性を有することのないエントリが定義可能な結果を与える。
【００７３】
このことから、サーチＳ５及びＳ６はタイプのみのフィルタ項目での逆サーチであるということが可能であり且つ以下の如くに表わすことが可能である。
【００７４】
【数１５】
2005510777.tif 000017
【００７５】
ＮＯＴ連結語を有するタイプのみのフィルタ項目の認識
タイプのみのフィルタ項目サーチの場合、各エントリにフィルタ項目が適用され、その結果が真又は偽であるようなバイナリー論理が存在している。次に、図４を参照すると、矩形１３内の区域はディレクトリ内のエントリの総数を示しており、一方円Ａ及びＢは例示的なフィルタＡ及びＢを適用するサーチを満足するエントリを示している。２つの円１４の交差部の左側の区域は、フィルタ項目Ａが「タイプのみ」のフィルタ項目である場合に、フィルタ項Ａ．！Ｂ．でのサーチを満足するエントリを示している。
【００７６】
ＮＯＴ連結語でのタイプのみのフィルタの評価
本発明は、フィルタ項又はフィルタ項目がＮＯＴ連結語を包含することがないように式を展開する論理的方法論を使用してタイプのみのフィルタ項又はＮＯＴ連結語を有するフィルタ項目を評価又は処理することが可能である。該論理的方法論は、減算方法又はフィルタ項目がＮＯＴ連結語を包含することがないように式を展開することが可能な任意の適宜のその他の方法論とすることが可能である。説明の便宜上、本発明を減算方法を使用して説明する。減算方法は、ＡＮＳＩ  ＳＱＬ「ｅｘｃｅｐｔ」句又はその他の適宜の方法を使用するデータベースにより実施することが可能である。一方、フィルタ又はフィルタ項を展開させることが可能であり且つディレクトリアプリケーションがＮＯＴ連結語を除去するためにフィルタ又はフィルタ項に関して減算方法を実施することが可能である。この代替方法はＮＯＴ連結語を包含するフィルタ又はフィルタ項をＮＯＴ連結語を包含することのない２つの（又はより多くの）より小さなフィルタ項へ分解することを包含している。例えば、次の形態のフィルタ項、
【００７７】
【数１６】
2005510777.tif 000018
【００７８】
を以下の如くに表わすことが可能であり、
【００７９】
【数１７】
2005510777.tif 000019
【００８０】
尚、「Ａ」及び「Ａ．Ｂ」はより小さなフィルタ項である。これらのフィルタ項を処理することは、フィルタ項目「Ａ」を満足するデータベースディレクトリ内のエントリのエントリ識別子（ＥＩＤ）を見つけ出し且つそれらをメモリ内に格納することを包含している。フィルタ項「Ａ．Ｂ」を満足するエントリのＥＩＤが見つけ出され且つフィルタ項目Ａの格納されているＥＩＤから減算してオリジナルのフィルタ又はフィルタ項Ａ．！Ｂを満足するＥＩＤを発生する。
【００８１】
更に、比較的小さいものと考えられるフィルタ項又はフィルタ項目を最初に処理することが可能である。従って、図４からのフィルタ項Ａ．Ｂが処理される場合に、より少ないエントリが返され、従ってこのフィルタ項Ａ．Ｂは、例えば、「ｅｘｃｌｕｄｅ  ｌｉｓｔ」を形成するために最初に実施することが可能である。次いで、フィルタ項目Ａを処理することが可能であり且つ「ｅｘｃｌｕｄｅ  ｌｉｓｔ」（排除リスト）内に内エントリをサーチの結果としてリストすることが可能である。
【００８２】
ＮＯＴ連結語を有するタイプ及び値のフィルタ項目の認識
本発明は、論理的方法論を使用してＮＯＴ連結語を有するタイプ及び値のフィルタ項又はフィルタ項目を評価又は処理することが可能である。上述したように、タイプ及び値のフィルタ項目においては、このようなフィルタ項目はタイプのみのフィルタ項目よりもより複雑なものである場合があると理解される。何故ならば、このようなフィルタ項目は幾つかのエントリに対して未定義の結果を発生する場合があるからである。タイプ及び値のフィルタ項目を処理する場合に、各エントリに対するフィルタ項目の評価に対し３つの可能な結果が存在している。
【００８３】
１）属性が存在し且つ値がフィルタ項目とマッチ、
２）属性が存在し且つ値がフィルタ項目とマッチせず、又は
３）属性が存在せず、従って特定のエントリに対してフィルタ項目を適用することの結果は未定義である。
【００８４】
図５において、矩形１３内の区域はディレクトリ内のエントリの総数を示している。内側の円１５はフィルタ項目Ｂを満足するエントリを示しており、一方外側の円１６はフィルタ項目Ｂ＊を満足するエントリを示している（尚、Ｂ＊＝Ｂ  ｐｒｅｓｅｎｔ（存在））。フィルタ項である、
【００８５】
【数１８】
2005510777.tif 000020
【００８６】
がフィルタ項目Ａの陰線区域１７内のエントリに対して未定義であり、それはフィルタ項目Ｂがこれらのエントリ内には存在しないからであることを理解することが可能である。このことは図３及びエントリの幾つかに対して結果が「未定義」であった上述したサーチＳ４に関して詳細に説明したものと比較的類似した状況である。式１８のサーチフィルタにより返されるエントリは、フィルタ項目Ａ及びＢ＊の交差しているがフィルタ項目Ａ及びＢの交差部１９を除去した三日月状の区域１８によって示されるエントリである。
【００８７】
ＮＯＴ連結語を有するタイプ及び値のフィルタ項目の評価
ＮＯＴ連結語を有するタイプ及び値のフィルタ項目の部分を評価するために論理的方法論を使用することが可能である。該論理的方法論は、以下の式２０に示した減算方法又はフィルタ項目がＮＯＴ連結語を包含することがない式に展開することが可能な任意のその他の適宜の方法論とすることが可能である。以下の式において、フィルタ項Ａ．！Ｂはタイプ及び値のフィルタ項目であるフィルタ項目！Ｂを包含しており、即ち、
【００８８】
【数１９】
2005510777.tif 000021
【００８９】
このフィルタ項を更に以下の如く展開することが可能であり、
【００９０】
【数２０】
2005510777.tif 000022
【００９１】
尚、Ｂ＊はＢ  ｐｒｅｓｅｎｔ（存在）を表わしており且つフィルタ項目が未定義である場合のエントリを除去するために使用される。
【００９２】
式１９のフィルタ項において、フィルタ項目（！Ｂ）はタイプ及び値のフィルタ項目であり、従って、
【００９３】
【数２１】
2005510777.tif 000023
【００９４】
これは式１４に比較的類似している。
【００９５】
フィルタ項目Ａが弱く（多くのエントリの場合にそうである）又はＢが式２０において共通である（多くのエントリ内に存在している）場合には、式１７で表わされる減算方法は効率的でない場合がある。何故ならば、それは弱い項が関与するジョイン式となるからである。フィルタ項内にフィルタ項目の１つを超えるＮＯＴ連結語が存在している場合、例えばＡ．！Ｂ．！Ｃである場合には、減算方法はＡ．Ｂ＊．Ｃ＊−Ａ．Ｂ−Ａ．Ｃを評価せねばならない。この場合には、ジョインオペレータの数がフィルタ項コンポーネントのうちの１つが弱いものである可能性を増加させ且つ最適なものとは考えられないサーチ性能となる場合がある。
【００９６】
ＮＯＴ連結語を有するタイプ及び値のフィルタ項目を評価する別の実施例が存在しており、それは、ある場合においては、減算方法を使用するよりも一層効率的なものである場合がある。この実施例においては、フィルタ項目を処理する場合に反転即ち逆のオペレータを使用する。例示すると、メタデータデザインにおいては、フィルタ項における属性及び値をフィルタ項を表すＳＱＬステートメント内に包含させることが可能である。この方法論理を使用して、タイプ及び値のフィルタ項目からの未定義結果は自動的にアドレスされる。何故ならば、データベース内のサーチテーブルレイアウトがそれらの属性識別子（ＡＩＤ）及び値（ＮＯＲＭＫＥＹ及びＮＯＲＭ）により行を識別するからである。その結果、フィルタ項目は次式の如くに表わすことが可能であり、
【００９７】
【数２２】
2005510777.tif 000024
【００９８】
又は、フィルタ項目に適用されるＮＯＴ連結語が存在する場合には、そのフィルタ項目を次式の如く表わすことが可能である。
【００９９】
【数２３】
2005510777.tif 000025
【０１００】
然しながら、ＮＯＴ連結語はフィルタ項目内に「プッシュ」即ち押込むことが可能であり且つ以下の如くにしてオペレータに対して適用することが可能である。
【０１０１】
【数２４】
2005510777.tif 000026
【０１０２】
ＮＯＴ連結語をフィルタ項目内に「プッシュ」する場合に、そのオペレータを反転即ち逆にすることが可能である。このことはフィルタ項目のＮＯＴ連結語を負のステートメント（例えば、６００００より大きなサラリーを包含することのない全てのエントリに対して捜索）から正のステートメント（例えば、６００００より小さいか又は等しい値を有するサラリー属性を包含することのない全てのエントリを捜索）へ変換させることを可能とする。
【０１０３】
例えば、フィルタ項目、
【０１０４】
【数２５】
2005510777.tif 000027
【０１０５】
は以下のようにＳＱＬ  ＷＨＥＲＥ句において表わすことが可能である。
【０１０６】
【数２６】
2005510777.tif 000028
【０１０７】
同様に、ＮＯＴ連結語を包含するフィルタ項目を以下の如くに表わすことが可能であり、
【０１０８】
【数２７】
2005510777.tif 000029
【０１０９】
且つＳＱＬ  ＷＨＥＲＥ句において以下の如くに表わすことが可能である。
【０１１０】
【数２８】
2005510777.tif 000030
【０１１１】
注意すべきことであるが、フィルタ項目内の「＞」オペレータはＳＱＬステートメントにいて「＜＝」オペレータへ変換されている。
【０１１２】
上のフィルタ項目の場合、サラリー属性を有することのないエントリはフィルタ項目「ＡＩＤ＝７」を満足することはなく、従ってフィルタ項目がこれらのエントリに対して適用される複雑性は存在しない。
【０１１３】
同様に、フィルタ項目、
【０１１４】
【数２９】
2005510777.tif 000031
【０１１５】
はＳＱＬ  ＷＨＥＲＥ句において次の如くに表わすことが可能である。
【０１１６】
【数３０】
2005510777.tif 000032
【０１１７】
図６はＮＯＴ連結語を有するタイプ及び値のフィルタ項目を評価する別の方法に基づいて実行前にＳＱＬクエリーを構築する方法を模式的に示している。この実施例においては、正のＳＱＬクエリーバッファ６０１及び負のＳＱＬクエリーバッファ６０２ｎが設けられている。負のクエリーバッファは別のブロックとして例示してある。何故ならば、それらは、典型的に、ＯＲオペレータにより分離されているからである。正のクエリーバッファ６０１は、フィルタ項目及び／又は正のＳＱＬクエリーにより表わされる結果のために設けることが可能である。正のＳＱＬクエリーの多く又は全てを正のクエリーバッファ６０１内に包含させることが可能である。ＮＯＴ連結語を有するタイプ及び値のフィルタ項目は正のＳＱＬクエリーバッファ内に存在している。
【０１１８】
負のＳＱＬクエリーバッファ６０２乃至ｎは、ＮＯＴ連結語を有するフィルタ項目の処理から発生する減算ＳＱＬクエリーの各々を格納するためである。
【０１１９】
この実施例においては、ＮＯＴ連結語が処理され、従ってＮＯＴ連結語は可及的に最も低いレベルへプッシュ即ち押し込められ、従って各ＮＯＴ連結語はクエリーがランされる場合に単一の比較に対して適用される。その後に、「属性存在」を包含するＮＯＴ連結語を有するタイプのみのフィルタ項目を論理的方法論（例えば、上述したような減算方法）を使用して処理することが可能であり、且つＮＯＴ連結語を有するタイプ及び値のフィルタ項目は、そのフィルタ項目を正のフィルタ項目とさせるためにそのオペレータを反転即ち逆にし且つ属性識別子コンポーネント（ＡＩＤ＝＜ｖａｌｕｅ＞）を包含させることにより処理することが可能である。これにより、「オペレータ」がその相補的なオペレータへ変化され、従って、例えば、「＞＝」オペレータは「＜」オペレータとなり「＜＝」オペレータは「＞」となり、サブストリングはＮＯＴサブストリングとなり、且つ「＝」オペレータは「！＝」又は「＜＞」オペレータとなることを意味する。当業者によって公知の如くその他のオペレータが存在しており、従って前の例は単にガイドとして使用すべきものである。
【０１２０】
図７は本発明に基づく方法の別の実施例を示している。この実施例においては、ディレクトリサービスクエリー（ステップ７０１）が初期化され、従ってフィルタはクエリーの実行期間中に適用され、多数のフィルタ項又は項目７０２（１乃至ｎ）を発生し、それらは全て異なる程度の複雑性を有する場合がある。次いで、フィルタ項目に関してテスト条件（ステップ７０３）が課される。即ち、各フィルタ項又はフィルタ項目がタイプのみか又はタイプ及び値のフィルタ項又はフィルタ項目であるか否かについての判別が行われる。
【０１２１】
フィルタ項目がタイプのみのパス７０４であることが判明すると、即ち任意にＤ＝Ｂ＊、尚Ｂ＊はＢが存在することを意味する、従って以下に詳細に説明する減算方法を使用してＳＱＬを負のＳＱＬクエリーバッファへ付加する。そのフィルタ項目がタイプ及び値、即ちパス７０６であることが判明すると、即ち任意的にＢ！＝Ｂ＊であると、ＳＱＬがテーブルジョインを包含する場合のある正のＳＱＬクエリーバッファへ付加される（パス７０７）。より好適には、ＮＯＴ連結語がフィルタ項目内にプッシュされる（パス７０８）。次いで、ＳＱＬの構築が完了したか否か又はそのフィルタ項目が展開されたか否かについての判別が行われる（ステップ７１０）。ステップ７１０に対する回答が「ＮＯ」である場合には、該条件テストが次のフィルタ項目に対して適用される（ステップ７０３）。７１０に対する回答が「ＹＥＳ」である場合には、更なる処理を行うことが可能である（ステップ７０５）。本発明によれば、パス７０７を介して１つ又はそれ以上のフィルタ項目を処理させ及び／又は１つ又はそれ以上のフィルタ項目をパス７０８を介して処理させることも可能である。ＮＯＴ連結語を包含することのないフィルタ項目はパス７０７を追従し且つＳＱＬを正のＳＱＬクエリーバッファへ付加させることが可能である。
【０１２２】
図８は本発明に基づく方法の更に別の実施例を示している。図８は３つの処理ステップ、即ち展開、事前評価及び評価が実施される方法の具体例を示している。
【０１２３】
ディレクトリサービスクエリーが初期化され（ステップ８０１）、従って複雑なフィルタ項を有するフィルタが適用される（ステップ８０２）。このフィルタは複雑なフィルタ項を有しており、次いで、展開される（ステップ８０３）。次いで、展開した項の更なる展開が可能であるか及び／又は望ましいか否かについての判別が行われる。このことを行う１つの態様は、ステップ８０３における展開から発生した展開された項が括弧の付けられた項を包含しているか否かを判別することである。１つ又はそれ以上の括弧が付けられた項を包含している場合には、その展開した項を再度展開させる（ステップ８０３，８０４）。展開した項が１つ又はそれ以上の括弧の付いた項を包含するものでなく及び／又は展開した項の現在の展開が充分であるか又は完了したものと考えられる場合には、異なる程度の複雑性を有する展開から発生したフィルタ項目が展開された項の和を形成する（ステップ８０６）。
【０１２４】
１組の展開した項を有しており、次のステップ、即ち事前評価を実施することが可能である。この事前評価プロセスは、就中、その結果が既知である項を評価することの必要性を除去することを検討する。例えば、フィルタ項目がデータベース内に存在しないことが既知であった属性を包含している場合には、その結果は既に真又は偽のいずれかであることが既に既知であると考える。ステップ８０７において各展開した項を取り、各フィルタ項目が識別され（ステップ８０８）、且つステップ８０８からの各フィルタ項目及び／又はステップ８０７からの展開した項をテストして、そのフィルタ項目及び／又は展開した項の結果が既に既知であるか否かを判別する（ステップ８０９）。その結果が既知である場合には、パス８１０に追従し、且つ該既知のフィルタ項目又は展開した項を再度テストして、その結果が真であるか又は偽であるかを判別する（ステップ８１１）。該フィルタ項目の結果が偽である場合には、その評価は終了する（ステップ８１２）。該フィルタ項目の結果が真である場合には、パス８１３を追従し、且つ該既知及び真のフィルタ項目を除去する（ステップ８１４）。次いで、パス８１５を追従する。
【０１２５】
例示するために、以下の式において、
【０１２６】
【数３１】
2005510777.tif 000033
【０１２７】
フィルタ項目Ｂ＝０、例えばこの処理が空のストリングを探す場合、であることが既知である場合には、式３１はゼロに対して評価し（即ち、その結果は既知であり且つ偽である）、且つ８１２へのパスを追従することが可能であり且つこのプロセスはそのフィルタ項目又は展開した項に対して終了される。次いで、このプロセスはその他の展開した項又はフィルタ項目に対して継続することが可能である。フィルタ項目Ｂ＝１、例えばオブジェクトクラスが存在する場合、であることが既知である場合には、式３１は、
【０１２８】
【数３２】
2005510777.tif 000034
【０１２９】
と評価され（即ち、その結果は既知であり且つ真である）、従って本プロセスは図８におけるステップ８１４においてフィルタ項目か「Ｂ」を除去することが可能である。
【０１３０】
フィルタ項目Ｃが未定義である、例えばＣが特定の値より大きな靴の寸法を探しているが、そのデータベース内には靴寸法の属性が存在しない場合、が既知である場合には、フィルタ項目！Ｃも未定義である。この場合には、展開された式３２はゼロに評価し（即ち、その結果は既知であり且つ偽である）且つパス８１２を追従することが可能であり且つ本プロセスはそのフィルタ項目又は展開した項に対して終了される。
【０１３１】
フィルタ項目及び／又は展開した項がステップ８０９において既知でない場合には、パス８１６が追従され、且つ更なる評価が必要であるか否かの更なる判別が行われる（ステップ８１７）。更なる事前評価が必要とされるか又は必要であると判別される場合には、パス８１９を追従してステップ８０８に到達し、そこで上述したプロセスが繰返し行われる。更なる既知のフィルタ項目及び／又は展開した項が存在しない場合には、パス８１８が追従され、且つ残りのフィルタ項目は、正のフィルタ項目及び負のフィルタ項目をグループ化する態様で並び替えられる（ステップ８２０）。更に、正のフィルタ項目と負のフィルタ項目とを別々にグループ化することは、１組の展開した最小項を得ることが可能であるので望ましいことである（ステップ８２１）。例示するために、フィルタ項、
【０１３２】
【数３３】
2005510777.tif 000035
【０１３３】
を並び替えて以下の１組の展開した最小項を得ることが可能である。
【０１３４】
【数３４】
2005510777.tif 000036
【０１３５】
更なる事前評価を必要でない場合には、本発明の次のステップである評価が行われる。
【０１３６】
並び替えたグループ内の各フィルタ項目をテストして、フィルタ項目が１つ又はそれ以上のＮＯＴ連結語を包含するか否かを判別する（ステップ８２２及び８２３）。テスト中のフィルタ項目がＮＯＴ連結語を包含するものでない場合には、パス８２４が追従され、且つ次いで、フィルタ項目と等置されるＳＱＬが正のＳＱＬクエリーバッファへ付加される（図６のバッファ６０１に類似）（ステップ８２５）。ＳＱＬが該バッファへ付加された後に、評価すべき更なるフィルタ項目が存在するか否かの判別が行われる（ステップ８２７）。
【０１３７】
ステップ８２３において、フィルタ項目が１つ又はそれ以上のＮＯＴ連結語を包含するものでない場合には、パス８２８が追従され、且つ図２に関連して説明したものと同様のテスト条件が実施される（ステップ８２９）。そのテストは、フィルタ項目がタイプのみのフィルタ項目であるか又はタイプ及び値のフィルタ項目であるか否かを判別する。そのフィルタ項目がタイプ及び値であると判別されると（パス８３１）、ＮＯＴ連結語が該オペレータ内に「プッシュ」され、且つこのＮＯＴ項と等しいＳＱＬが正のＳＱＬクエリーバッファへ付加される（ステップ８３２）。
【０１３８】
ＳＱＬが該バッファへ付加された後に、評価すべき更なるフィルタ項目が存在するか否かの判別が行われる（ステップ８２７）。このステップ８２９において、フィルタ項目がタイプのみのフィルタ項目である場合には（パス８３０）、減算方法を使用してそのフィルタ項目を評価し、且つそのフィルタ項目に等しいＳＱＬが負のＳＱＬクエリーバッファへ付加される（図６におけるバッファ６０２，６０３，６０ｎに類似）（ステップ８３３）。
【０１３９】
ＳＱＬが該バッファへ付加された後に、評価すべき更なるフィルタ項目が存在するか否かの判別が行われる（ステップ８２７）。
【０１４０】
ステップ８２７において、更なるフィルタ項目を評価することが必要である場合には、パス８３４が追従され且つステップ８２２からプロセスが繰返し行われる。更なるフィルタ項目が評価を必要としない場合には（パス８３５）、ＳＱＬが実行され（ステップ８３５）且つフィルタ項目が評価される（ステップ８３７）。
【０１４１】
実行ステップ８３６は多数の態様で実施することが可能である。１つの方法はＡＮＳＩ「ＳＱＬ  ＥＸＣＥＰＴ」コネクタを使用して負及び正のＳＱＬ部分式を一緒に評価することである。
【０１４２】
別の方法は、負及び正のＳＱＬ式を別々に評価させ且つアプリケーションが減算自身を行わせることである。
【０１４３】
更に別の方法は、負のＳＱＬをＯＲ連結語により分離されているバッファ内へ配置させ、各負のバッファを評価し、且つその結果を「ｅｘｃｌｕｄｅ  ｌｉｓｔ」内に配置させることを包含している。このことは評価すべき多数の比較的より小さなＳＱＬ式を与える。次いで、正のＳＱＬ式を評価し且つ、「ｅｘｃｌｕｄｅ  ｌｉｓｔ」内に存在しない場合には、「結果リスト」内に配置させることが可能である。このことは、正の結果を回収しながら減算を行うことを可能とする。
【０１４４】
図９は本発明に基づく更に別の実施例のフローチャートである。ディレクトリサービスクエリーが初期化され、フィルタが適用され且つ展開された項が得られる（ステップ９０１，９０２）。各フィルタ項目９０３を取り、テスト９０４を実施して、そのフィルタ項目の結果が既に既知であるか否かを判別する。この実施例は、フィルタ項目を参照するものであるが、展開した項に対しても同様に適用可能である。その結果が既知である場合には、パス９０５が追従され、且つその既知のフィルタ項目が再度テストされて、既知のフィルタ項目９０３が真であるか又は偽であるかを判別する（ステップ９０６）。その既知のフィルタ項目が偽である場合には、そのフィルタ項目が廃棄され（ステップ９０７）且つ評価プロセスがそのフィルタ項に対して終了される（ステップ９０８）。その既知のフィルタ項目９０３が真である場合には、パス９０９が追従され且つ次いでテストを実施して、更なるフィルタ項目が処理を必要とするか否かを判別する（ステップ９１０）。
【０１４５】
ステップ９０４において、フィルタ項目が既知でない場合には、パス９１１が追従され、且つテストを実施して、そのフィルタ項目がＮＯＴ連結語を包含するか否かを判別する（ステップ９１２）。該フィルタ項目がＮＯＴ連結語を包含するものでない場合には、パス９１３が追従され且つ該フィルタ項目に等しいＳＱＬが正のＳＱＬクエリーバッファへ付加される（図６のバッファ６１０と同様）（ステップ９１４）。ＳＱＬをバッファへ付加した後に、テストを実施して、更なるフィルタ項目が処理を必要とするか否かを判別する（ステップ９１０）。
【０１４６】
ステップ９１２において、フィルタ項目がＮＯＴ連結語を包含するものでない場合には、パス９１６が追従され、且つ図２に関して説明したものと同様のテスト条件が実施される（ステップ９１７）。そのテストは、該フィルタ項目がタイプのみのフィルタ項目であるか又はタイプ及び値のフィルタ項目であるかを判別する。そのフィルタ項目がタイプ及び値のフィルタ項目である場合には、ＮＯＴ連結語がＳＱＬ内に「プッシュされ」、且つこのＮＯＴ連結語と等しいＳＱＬが正のＳＱＬクエリーバッファへ付加される（図６のバッファ６０１と同様）（ステップ９２０）。ＳＱＬが該バッファへ付加された後に、テストを実施して更なるフィルタ項目が処理を必要とするか否かを判別する（ステップ９１０）。
【０１４７】
ステップ９１７において、該フィルタ項目がタイプのみのフィルタ項目である場合には、該フィルタ項目に等しいＳＱＬが負のＳＱＬクエリーバッファへ付加される（図６におけるバッファ６０２，６０３，６０ｎと同様）（ステップ９２１）。そのＳＱＬを該バッファへ付加した後に、テストを実施して更なるフィルタ項目が処理を必要とするか否かを判別する（ステップ９１０）。
【０１４８】
上述したように、ステップ９１０において、該テストは、更なるフィルタ項目が評価を必要とするか否かを判別する。更なる評価が必要とされる場合には、パス９２２が追従され且つステップ９０３からのプロセスが繰返される。更なる項目が評価を必要としない場合には、ＳＱＬが、好適には、図８におけるステップ８３６と同様の態様で実施され（ステップ９２４）、結果を与える（ステップ９２５）。
【０１４９】
基本的に、且つ要約すると、本発明はディレクトリサービスの項が２つの異なるタイプのフィルタ項目を包含している（潜在的に）ことを実現している。従って、本発明はフィルタ項目の各タイプを判別し、例えば、夫々、タイプ及び値の項目に対する式１７，２０又は２４及び／又は本明細書において記載した実現例に従って適宜の評価を選択し、且つこのような態様で、ディレクトリサービスの最適化又は改良した処理を決定する。
【０１５０】
注意すべきことであるが、本発明は説明した実施例にのみ制限されるべきものではない。当業者は、本発明を比較的多数の異なる且つ変化する状態において実現することが可能であることを理解する。
【図面の簡単な説明】
【０１５１】
【図１】処理時間−ＳＱＬステートメントの複雑性を例示したグラフ図。
【図２】本発明に基づく方法の一部の動作の流れを示した概略図。
【図３】データベースにおけるエントリの概略図。
【図４】データの第一形態組の概略図。
【図５】データの第二形態組の概略図。
【図６】本発明の１実施例に基づくＳＱＬクエリーの１つの形態に対するＳＱＬクエリーバッファの例示的なブロック図。
【図７】本発明に基づく方法の一部の別の動作の流れを示したフローチャート。
【図８】本発明に基づく方法の一部の別の動作の流れのフローチャート。
【図９】本発明に基づく方法の一部の別の動作の流れのフローチャート。
【図１】
2005510777.tif 000037
【図２】
2005510777.tif 000038
【図３】
2005510777.tif 000039
【図４】
2005510777.tif 000040
【図５】
2005510777.tif 000041
【図６】
2005510777.tif 000042
【図７】
2005510777.tif 000043
【図８】
2005510777.tif 000044
【図９】
2005510777.tif 000045