JP3735683B2 - 高速探索サーチ及びインデクシング法 - Google Patents
高速探索サーチ及びインデクシング法 Download PDFInfo
- Publication number
- JP3735683B2 JP3735683B2 JP2000533833A JP2000533833A JP3735683B2 JP 3735683 B2 JP3735683 B2 JP 3735683B2 JP 2000533833 A JP2000533833 A JP 2000533833A JP 2000533833 A JP2000533833 A JP 2000533833A JP 3735683 B2 JP3735683 B2 JP 3735683B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- character
- string
- nodes
- search
- 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 - Lifetime
Links
- 238000000034 method Methods 0.000 title claims abstract description 118
- 230000008569 process Effects 0.000 claims description 23
- 238000013138 pruning Methods 0.000 claims description 9
- 238000001514 detection method Methods 0.000 claims description 5
- 238000011161 development Methods 0.000 claims description 2
- VLKZOEOYAKHREP-UHFFFAOYSA-N n-Hexane Chemical compound CCCCCC VLKZOEOYAKHREP-UHFFFAOYSA-N 0.000 claims 3
- 230000009021 linear effect Effects 0.000 description 28
- 238000003780 insertion Methods 0.000 description 20
- 230000037431 insertion Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 15
- 230000006870 function Effects 0.000 description 12
- 238000009826 distribution Methods 0.000 description 10
- 230000001351 cycling effect Effects 0.000 description 5
- KDYFGRWQOYBRFD-UHFFFAOYSA-N succinic acid Chemical compound OC(=O)CCC(O)=O KDYFGRWQOYBRFD-UHFFFAOYSA-N 0.000 description 4
- 230000008901 benefit Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- MXNKUBJIXVVNPY-UNYLCCJPSA-N N(2)-carboxyethyl-2'-deoxyguanosine Chemical compound C1=NC=2C(=O)NC(NC(C)C(O)=O)=NC=2N1[C@H]1C[C@H](O)[C@@H](CO)O1 MXNKUBJIXVVNPY-UNYLCCJPSA-N 0.000 description 1
- 206010033546 Pallor Diseases 0.000 description 1
- 238000009825 accumulation Methods 0.000 description 1
- 230000009471 action Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 230000007850 degeneration Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000010494 dissociation reaction Methods 0.000 description 1
- 230000005593 dissociations Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 238000010845 search algorithm Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000010561 standard procedure Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000009827 uniform distribution Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
- G06F16/31—Indexing; Data structures therefor; Storage structures
- G06F16/316—Indexing structures
- G06F16/322—Trees
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
- Y10S707/99936—Pattern matching access
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99938—Concurrency, e.g. lock management in shared database
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Golf Clubs (AREA)
- Calculators And Similar Devices (AREA)
Description
【０００１】
発明の属する技術分野
本発明は一般にデータ保守に、より詳しくはデジタルデータストリングの探索サーチ及びインデクシング法に関する。
【０００２】
背景技術
ここ数１０年コンピュータプログラマ及び科学者が、データベースを保守し、それ等の内容を探索するため新しく、そして、効率的な手法を発見してきている。探索を行うための標準的技術は、リニアな探索、ハッシング及び２進探索ツリーを含む。
【０００３】
リニアな探索技術は、キー、又はストリングを行うための最も基本的な手法である（用語“ストリング”は、アルファニューメリック又は２進キャラクタのグループを記述するため用いられる）。当該の直線的な方法メソッドは、すべての現存のストリングに対してループ動作する。前記のすべての現存のストリングは、通常、アレイ又はリニアなリンク連結リストとして組織化され、各ストリングＫｉをリクエストされるＫと比較する。リニアな探索は、下記の擬似コードにより表現され得る；
ここで Ｉ（Ｋ）は、ストリングＫに関連する情報レコードである。
【０００４】
そのような探索の実行時間は、Ｏ−記法（Ｎｏｔａｔｉｏｎ）を使用すると（関数ｆ（ｎ）はＯ（ｇ（ｎ）である）― すべてのｎ≧ｎＯ に対して
ｆ（ｎ）≦ｃｏｎｓｔ．ｆａｃｔｏｒ・ｇ（ｎ） が成立つようなｎOが存在する場合）、
Ｔlinear（ｎ）＝Ｏ（ｎ）
こうして、リニア探索の実行時間はストリングの数ｎと共に比例的に増大する。
【０００５】
単純性、簡易性のためリニア探索は、より進んだ探索方法より少ないオーバーヘッドを有する。一般的にいえば、リニア探索は、探索すべきストリングのセットが小である場合、他の探索方法により高速である。従ってインプリメンテーションの容易性及びロバストネスのため、ｎ＜１００である際の小規模探索に対してリニアな探索は優先される。
【０００６】
リニア探索の不都合は、エントリ又はストリングの数ｎへのリニアな依存性である。リニア探索方法は、増大するｎに対して、高性能アプリケーション向けに非現実的になる。１０，０００―エントリテーブルを探索することは、１０―エントリテーブルより１，０００倍遅くなる。
【０００７】
探索に対する他の普及している技術はハッシングである。ハッシングは、リニア探索方法におけるようにすべてのストリングをあまり残さず探索しつくすというよりむしろストリングの２進表示から直接、所定ストリングのアドレス又はロケーションを計算するものである。ハッシング探索は、しばしば２段階ステッププロセスであり、ここで、ハッシング関数Ｈは、リニア探索方法を用いて探索されるストリングの小さいリストを参照するインデックス索引をリターンする。ハッシング探索は、擬似コードで次のアルゴリズムにより表現される。
【０００８】
ｉ＝Ｈ（Ｋ）
ＲＥＴＵＲＮ Ｔ（ｉ）
ここでハッシング関数Ｈは、所定のストリングのインデックス索引、リターンインデックス索引ｉを計算する。インデックスｉはマッチングストリングのみに関与ないし参照し得、又はストリングの１つのリストをレファレンス参照し得、該ストリングのリストは次いでマッチングストリングに対してリニアに探索されねばならない。
【０００９】
通常使用されるハッシング関数Ｈは下記の式を用いてハッシュ表Ｔ内へのストリングの編成組織化又はインデクシングを行う：
Ｈ（Ｋ）＝（キーストリングＫの総バイトｂ1，…，ｂm（ＡＳＣＩＩコード）の和）ｍｏｄｕｌｏ Ｍ
ここでＭはハッシュ表Ｔのサイズを表す。明らかにハッシュ関数Ｈは、一般に、各ストリングに対して固有―意であることが保証され得ない。２以上のストリングにより、同じハッシュ関数が生じる場合には、（異なるストリングＫi≠Ｋjに関して（Ｈ（Ｋi）＝Ｈ（Ｋj）が生じる場合には）衝突ケースの発生と称される。衝突ケースに対処する最も普通の手法は、リクエストされたエントリを見出すべく通常リニア探索方法により、衝突リストの探索を要する各々のハッシュ表エントリに対して同一のハッシュ値を有するストリングのリストを維持保持することである。
【００１０】
一般にハッシングの実行時間は、衝突リストの平均長さに依存し、前記の衝突リストの平均長さは、ハッシュ関数Ｈの分布のみならず、ハッシュ表サイズＭにも依存する。ハッシュ関数Ｈがほぼ完全な分布（すなわち、任意のキーストリングＫがインデックスｉ＝Ｈ（Ｋ）へ分散、分布される確率がすべてのｉ＝１…Ｍに対して等しい起こり易さである）を有するものと仮定すると、ハッシングの平均実行時間は次のようになる。
【００１１】
Ｔhash（ｎ）＝Ｏ（ｎ／Ｍ）
その結果は、十分大きなハッシュ表サイズＭ＞ｎ、に対してほぼ一定である実行時間である。
【００１２】
従って、理論上、実行時間は、ほぼｎに無関係であると期待され得る。ここでは完全なハッシュ関数（大多数の実世界アプリケーションにおける非現実的な期待）を使用し得るならばの条件付きである。
【００１３】
ハッシングの欠点は、衝突のケースを分解する固有の必要性により、付加的で、時には長たらしい検索の行われることが要求される。ハッシング技術を利用する平均探索が迅速であるが、探索を完結する実際の時間長さは、所定のストリング分布に対して最も一層より悪くなり得る。最悪のケースでは、すべてのストリングが、同じインデックスにて終わることが起こり得て、探索の総合的性能が、リニアな探索の場合より良好なものとならない。従って実際上、実時間世界アプリケーションに対して効率的なハッシュ関数を見出すことは、困難なタスクであり、インデクシングすべきストリングの実際の確率分布に著しく依存する。
【００１４】
ハッシングのもう１つの欠点は、ワイルドカード探索に役立たないことである。ワイルドカード探索は、そこにて探索ストリングにおける１つ以上のキャラクタがワイルドカードキャラクタであるようなものである（すなわち、他の任意のキャラクタにとって代わり得るキャラクタである）。ワイルドカード探索は、しばしば多重マッチングストリングをリターンする。
【００１５】
探索の他の方法は探索ツリー方法である。その種探索が実行される前に、その上にて探索を実行すべきデータを編成組織化するために探索ツリーを生成しなければならない。探索ツリーインプリメンテーションの種々のものが提案されており、その中で最も基本的なものは、２進探索ツリーであり、この２進探索ツリーは、次のように規定される。
【００１６】
（ツリー節点ノードにより表される）ストリングの１セットＫ1，…，Ｋnにわたる（２進）ツリーＴは、次の条件が成立つ場合、探索ツリーと称される、すなわち、いずれのサブ節点ノードＴに対しても、そして、Ｔの左のサブツリーにおけるいずれの下降するノードＴ1に対しても、また、右のサブツリーにおけるいずれのＴrに対しても、下記が成立つ場合；
ｖａｌｕｅ（Ｔ1）＜ｖａｌｕｅ（Ｔr）、ここで ｖａｌｕｅ（Ｔ）は、ツリー節点ノードＴに関連するストリング値であって、探索ツリーと称される。
【００１７】
こうして基本的な探索手続きを（再帰的に）擬似コードで次のように定式化できる（通常のように、Ｋは探索されているストリングを表し、そして、非存在のキーのような特別な場合は、簡単化のため省略し得る）：
上述の探索ツリーは、―方法メソッドは、深さ優先―ツリー―トラバース走査を実行し、それにより、ツリーの深さに比例して増大する実行時間を生じる。従って、適当にバランスされた探索ツリーの条件下で（すなわち、それのリーフ節点ノードが実質的に均に分布しているツリー）平均実行時間は次の通りである。
【００１８】
Ｔtree＝Ｏ（ｌｏｇ2ｎ）
こうして，理論上、平均実行時間は、エントリ、又はストリングの数と共に対数的に増大する。このことは、多数のエントリに亘って探索する場合、リニア探索に対しての実質的改善を成す。
【００１９】
探索ツリー方法の１つの欠点は、フィールド条件下で、実行時間は大いに変化し得る、それというのは実際上、探索ツリーはめったにバランスされないからである。ツリーのバランシング特性は、著しく、実際のストリング分布に依存する。前記問題を最小化するため、下記刊行物に記載されている、ＡＶＵ ツリー（tree）のような複雑な方法が案出されている、すなわち、
Van Wyk， Christopher J., 著述 Data Structures and C. Programms， Addison-wesley Publishing， １９８８年。
【００２０】
しかしながら、そのような方法は、またツリー構造管理のためインプリメンテーション上のオーバーヘッドを増大させる傾向を呈する。実際上、アクチュアルのインプリメンテーションに依存して、ツリーをベースとする探索は、簡単なリニア探作を凌駕することはないーエントリの数が幾１００のブレークイーブンポントを越えないならば。
【００２１】
本発明は、ジュエネリックインデクシング及びパーシャルマッチ問い合わせを支援するアルファニューメリック又は２進ストリングの高速インデクシング及び検索取出のための方法を提供することにより前述の問題を克服する。本発明は特有一義的コンパクトツリーを利用し、ここで、１つの節点ノードが、１つの探索ストリングにて複数のキャラクタをステップ的に走査するため使用され得、そして、基礎となるストリングアルファベット内に存在するキャラクタ（例えば８ビットーベースーキャラクタに対して２５６）と同じ数の後継者サクセッサー節点ノードを有し得る。更にワイルドカード探索中可能な多重マッチングストリングのため複数のサブツリーないしツリーを探索する必要がある場合、本発明はバックトラッキングを使用する。また、本発明はヒューリスティックサブツリー枝刈り（ｐｒｕｎｉｎｇ）すなわち、それによりパーシャルマッチ探索をサブツリー全体の破棄により加速し得る方法を利用する。
【００２２】
本発明は、ストリングを使用したケースに主に適用されるが、そのような探索はデータベース中に記憶されている任意のデジタル情報を探索するため使用し得る。
【００２３】
発明の要約
本発明は、ストリングの形態で記憶されている高速探索及びインデクシング法に関する。この発明は所定の問い合わせストリングにマッチングするようデータベースを迅速に探索するための手段を提供する。開示された実施例では探索方法メソッドは、図解のためアルファニューメリックストリングに関連付けて利用される。
【００２４】
本発明の目的とするところは、所定のアプリケーションに対していずれの公知の方法よりも高速の、ストリング探索方法を提供することにある。
【００２５】
本発明の目的とするところは、大抵のアプリケーションに対してリニア探索ハッシュ探索、又は２進ツリー探索より高速のストリング探索方法を提供することである。
【００２６】
本発明の他の目的とするところはキャラクタレベルでのワイルドカードのようなパーシャルマッチングをサポートするストリング探索方法を提供することにある。
【００２７】
本発明の他の目的とするところは、インデックス内でパーシャル部分的に指定されたストリングのジェネリック記憶を含めたジェネリックインデキシングをサポートするストリング探索のための方法を提供することにある。
【００２８】
本発明の他の目的とするところは、大きなストリングサイズに特に効率的なストリング探索方法を提供することにある。
【００２９】
本発明の他の目的とするところは、不均一に分布されたストリング分布に対してロバストネスを有するストリング探索方法を提供することにある。
【００３０】
本発明の他の目的とするところは、２進ツリー又はハッシング衝突リストにて生じる際限のない縮退を防止するストリング探索方法を提供することにある。
【００３１】
本発明の他の目的とするところは、内部ツリー構造管理オーバーヘッドを最小化するストリング探索方法を提供することにある。従って、１００エントリより少ないエントリを有するテーブルに対しても、開示されたインプリメンテーションは、しばしばリニア探索より高速になる。
【００３２】
本発明の他の目的とするところはロジカルロックマネージメント（ｌｏｃｋ ｍａｎａｇｅｍｅｎｔ）の改善された方法を提供することにある。
【００３３】
本発明によれば、複数のストリングエントリをインデクシング方法が提案され、ここで、前記の複数のストリングエントリの各１つが複数キャラクタの１つのストリングである。本発明によれば探索ツリーを使用することにより複数のストリングエントリのインデクシングを行う方法であって、前記の複数のストリングエントリのうちの各１つが複数キャラクタの１つのストリングであるようにした当該のインデクシング方法において、前記探索ツリーは、連結リンクされた節点を有し、前記の連結された節点ノードは、１つの根節点及び複数の内部節点ノード並びに複数のリーフ節点ノードを有し、前記の内部節点ノードは、１つのキャラクタ又はキャラクタのサブストリングに関連付けられており、また前記のリーフ節点ノードは、前記の複数のストリングエントリに関連付けられており、ここで、前記の複数の内部節点ノードの各々は、更に、下記の要素（ａ）〜（ｅ）を有し、すなわち
（ａ） 親節点に対する参照を有し、ここで前記親節点ノードは、前記複数の内部ツリー節点ノードのうちの他の１つのもの又は、前記根節点ノードであり、
（ｂ） キャラクタ比較位置を含む第１データフィールドを有し、前記キャラクタ比較位置は、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタの数を指示するものであり、
（ｃ） 比較キャラクタを含む第２データフィールドを有し、前記比較キャラクタは、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタが、前記キャラクタ比較位置に関連する前記ストリングエントリの１つのキャラクタ位置にて１つのストリングエントリ内に含まれているか否かを決定するため使用され、
（ｄ） 可変的な個数の少なくとも２つの後継者ノードへの参照を有し、
（ｅ） ツリーのトラバース走査の間に後継者ノードの中の高速ハッシュ探索を可能にするための相応の親節点ノードの後継者ノードへの参照を有するハッシュ表アレイを有し、さらに所定数のハッシュバケットを有し、
キャラクタのストリングは、アルファニューメトリックキャラクタの１つのストリングであり、複数のエントリのうちの少なくとも１つが１つのワイルドカードキャラクタを有し、このワイルドカードキャラクタはキャラクタのストリングの任意の可変的な位置に又は複数のストリングエントリのうちの少なくとも１つの任意の可変的な位置に位置決めされる。
【００３４】
又、本発明によれば複数のストリングの中から、複数のキャラクタから成る所定のストリングを探索する方法であって、前記複数ストリングの各々が複数キャラクタの１つのストリングであるようにした当該の探索方法において、前記方法は、下記ステップを有する、すなわち、
請求項１から８までのうちいずれか１項の方法により探索ツリーを生成するステップを有し、ここで、前記の複数のストリングは複数のストリングエントリを形成するものであり、
前記の所定のストリングに関連する問い合わせを形成するステップ
前記の問い合わせを利用して前記探索ツリーをトラバース走査して前記の所定のストリングにマッチングする前記複数ストリングの任意のものに１つのインデックス索引を与えるステップを有するのである。
【００３５】
本発明による所定のストリングを探索する方法を次の事項に関連して使用すれば特に有利である、すなわち、ヒューマンリソースマネージメント、ファイナンシャルズ、ビジネスワークフロー、人事マネージメント、ペイロールアカウンティング、タイムマネージメント、人事開発又はネットワーク、例えば、インターネット又はイントラネット、システムに関連して使用すれば特に有利である。そのようなシステムは、特にドイツ連邦共和国のＳＡＰ、ＷａｌｌｄｏｉｆからのＲ／３システムであり得る。
【００３６】
本発明のいくつかの基本的側面及び有利な実施例は、次のようなものである。
【００３７】
高速のストリングインデクシング方法は、効率的に、コンパクトな探索ツリーを利用して、アルファニューメリック又は２進ツリーを記憶し、探索し、そして除去する。探索ツリーにおけるレベルの数は、可能であれば、１つより多くのキャラクタを表す１つの節点ノードにより最小化される。ツリーの各内部節点ノードは、順次ハッシングに対するハッシュ表アレイを有し、このハッシュ表アレイはまた、１つの所定の節点ノードをトラバースするのに必要とされる時間を最小化する。キャラクタレベルにおけるワイルドカードのようなパーシャルマッチングのため探索を実行し得る。ストリングエントリの同じテーブル上にて、独立的に、且つ、同時に多重のインデクスをオープンし得る。
【００３８】
本発明及び実施例は以下の図を参照しながら説明される。
【００３９】
図の簡単な説明
図１は高速ストリングインデクシングのアプリケーションを具現化するインデクスツリーの基本的データ構造の例を示す概念図である。
【００４０】
図２及び図２ａは、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートの図である。
【００４１】
図３は、実行されているＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの１事例の第１半部の概念図である。
【００４２】
図４は、実行されているＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの１事例の第２半部の概念図である。
【００４３】
図５は、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【００４４】
図６は、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の１事例の第１半部に対するフローチャートを表す図である。
【００４５】
図７は、実行されているＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の１事例の第２半部に対するフローチャートを表す図である。
【００４６】
図８は、Ｅｘａｃｔ Ｍａｔｃｈ ＦＩＮＤ ＯｐｅｒａｔｉｏｎのＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【００４７】
図９及び図９ａは、 Ｐａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの有利な実施例に対するフローチャートを表わす図である。
【００４８】
図１０は、実行されているＰａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの事例を表す概略図である。
【００４９】
図１１は、ＦＩ ｉｎｄｅｘｅｄ ｌｏｃｋ ｔａｂｌｅ を使用したロジカルロックマネージメントを表わす概念図である。
【００５０】
発明の詳細な説明
本発明は探索を行いデータベースを保持するための改善された方法を開発したものである。本発明は、従来の探索及びインデクシングに比して多くの利点を有する。そのうちの１つは、スピードであり、優れたスピードは主に、３つのファクタに帰せられ得る。エントリ又はキーストリングの数に対するロバストネス、キーストリング分布に対するロバストネス及びキーストリング長さに対するロバストネス。それ等のすべての３つのファクタを以下に詳細に説明する。
【００５１】
Ｋ1＝ｂ11・・1m，Ｋ2＝ｂ21・・2m，・ Ｋn＝ｂn1・・nm により表されるランダムのｍ―キャラクタキーストリングｎ個の１セットをインデクシングするものとする。
【００５２】
図解目的のため、各キャラクタが８ビットバイトとしてコード化されている通常のケースを仮定し、各キーストリングの長さが２５６バイト（ｍ＝２５６）であると仮定する。
【００５３】
キーストリングの数に対するロバストネスは、ストリングの数ｎが増大するに従って、ＩＮＳＥＲＴ， ＲＥＭＯＶＥ,及びＦＩＮＤの基本動作ｏｐｅｒａｔｉｏｎｓの平均実行時間が固有的に増大するのを制限することに関連する。
【００５４】
本発明において、開示された高速ストリング方法（好適実施例中では“ＦＩ”と称される）は、インデクスツリーをトップからボトムへトラバース走査し（それの構造は、次のことを除いて２進ツリーのそれと類似している、すなわち、内部ノードがそこから直接下降している、単に２というよりむしろ多重のサブツリーを有し得ることを除いて類似する一方、同時に左から右へ探索ストリングをステップ的に走査して進む。探索ツリーの最後のキャラクタに到達すると、プロセスはマッチングを指示する探索ツリーのリーフ節点ノードに到達しているか、又は探索ストリングが現在インデクス中に存在していないことを検出している。こうして、ツリー節点ノード検査の平均総数は、インデクスツリーの平均深さと等しいか、それより小でなければならない。
【００５５】
本発明に関連して利用される探索ツリーの平均深さは次のように計算し得る。探索ツリーの平均ブランチングファクタＫは、任意の内部節点ノードから発する子孫下降サブツリーの平均数として定義付けられ得る。従って、Ｋは、基礎となるアルファベットにおける基礎となるキャラクタの数と等しいか、又はそれより小である（例えば、８ビットに対して２５６）。しかしながら、実際上、平均ブランチングファクタは、当該の数より著しく小である、それというのは、キーストリングの実世界分布は、通常均一分布とは程遠いものであるからである。ランダムな実世界データの大きなセットを用いての実験結果の示すところによれば、リズナブルなブランチングファクタは、４〜９ビットの基礎となるアルファベット及び１６〜５１２のキャラクタのストリング長さに対して Ｋ＝３…７のレインジ内にある。
【００５６】
内部節点ノードの数はツリーＴの各後続レベルに対してＫのファクタだけ増大するので、最終レベルでの（キーストリングの総数に等しい）リーフ節点ノードｎの総数は、次のように表され得る。
【００５７】
ｎ＝ｋdepth(T) 又は ｄｅｐｔｈ（Ｔ）＝ｌｏｇKｎ
更にＦＩ ｏｐｅｒａｔｉｏｎｓ ＩＮＳＥＲＴ， ＲＥＭＯＶＥ 及び Ｆ ＩＮＤ の平均実行時間がツリーの深さに等価であるので次のように表され得る。
【００５８】
ＴFI（ｎ）＝Ｏ（ｌｏｇKｎ）そして実行時間は、エントリの数の増大と共に対数的にのみ増大する。例えば、Ｋ＝４の場合、キーストリングエントリの数の４倍になるごとに、平均してそれらの考慮されるべき動作ｏｐｅｒａｔｉｏｎｓ に対して唯もう１つのレベルが加えられるだけである。
【００５９】
キーストリング分布に対するロバストネスは、エントリの所定のセットに対して探索時間の分散偏差を制限することに関連する。換言すれば、１つの任意の所定のエントリに対する探索は、理想的には他の任意のエントリごとに最悪のケースに関してーに対する探索と同じ時間量を取るべきである（すなわち、最悪のケースは平均ケースより遙かに多くの時間をとるべきではない）。しかしながらキーストリングの実世界分布に基づき、１つの２進ツリーがインデクスツリーのトップの近傍でいくつかのリーフ節点ノード及び極度の深さのところで他のリーフ節点ノードを有し得る。最悪のケースにて、２進ツリーは、そこにて、いくつかのエントリに対する探索がリニアリスト探索と同じ時間のかかるポイントへ縮退し得る。ＡＶＬツリーは、２進ツリーより幾らか良好に分布されるが、アルゴリズムのデータ構造を維持するのに劇的に増大する管理オーバーヘッドを代償にして行われるものであり、これにより、総合的な性能が悪化する。ハッシングアルゴリズムはまた、エントリのバランスされていない分布をも来し得る。理想的には、エントリはハッシングテーブルを横切って均一に分布され、そして、衝突リストは、多かれ少なかれ均一の長さである。実際上、或衝突リストは、他のものより長い。最悪のケースでは、すべてのエントリが、同じハッシュスロットにマッピングされ、１つのハッシュ探索は、１つのリニアリスト探索に等価なものとなる。
【００６０】
ＦＩインデクスツリーが概して完全にバランスされたツリーではないけれども、最大縮退の度合いが制限される。それというのは、少なくとも１つのストリングキャラクタが、ツリーを降下する各下降ステップに対して探索ストリングにて、トラバースされるからである。こうして、ツリーＴの総合深さは、キーストリング長さｍにより制限され、このキーストリング長さは、通常エントリｎの総数より対数的に小さい数である。
【００６１】
キーストリング長さに対するロバストネスは、個別のエントリの平均長さｍへの探索時間の依存性を制限することに関連する。このことは、ロジカルロックマネージメント（ｌｏｃｋ ｍａｎａｇｅｍｅｎｔ）のようなアプリケーションにおいては重要な配慮事項であり、ここでは各キーストリングが、全データベーステーブルラインに相応し得る。それ等のアプリケーションでは、数１０００ではなくとも数１００のキャラクタの長さであるキーストリングをインデクシングし探索することが重要であり得る。従来の探索方法を用いる場合、大きなキーストリング長さは、しばしば、各探索ステップに対して長ったらしいキャラクタごとの比較を必要とする。
【００６２】
ＦＩは、各探索ステップが探索ストリングにて多重キャラクタをカバーし得るようにして、キーストリングをインデクシングし得る能力を有する。実際のストリング長さに無関係に、各探索ごとに唯一の単一のキャラクタ検査しか必要でない。ＦＩインデクスツリーＴの深さが通常ストリング長さｍより遙かに小さいので、ストリングの大部分を、検査する必要がなく、探索プロセス中スキップし得る実験の結果により確認されたところによれば、大抵の実世界アプリケーションにて、ＦＩ性能がキーストリング長さと共に大して変わらない。ＦＩは、誤ったリターンの無いことを検証するのに、探索ストリング及びリーフ節点ノード（又はワイルド探索の場合における節点ノード）の１つのファイナル比較をしさえすればよい。
【００６３】
図示の実施例
ＦＩインデクシングツリー２の有利な実施例の基本構造例が図１に示してある。
【００６４】
当該の図解においてツリーに関連するデータベースは次のよなストリングエントリを有する。“ａｂｃｄ”，“ｃｄａｆ”，“ｃｄｄｈ”，及び“ｇｆｂｅ”．
簡単のため、及び図解目的のためだけにそれのキーストリングに対する基礎となるアルファベットは８つのキャラクタ（３ビット）を有する。注目すべきことには、比較的に小又は大のアルファベット（例えば８ビットに基づく）が大抵のアプリケーションにとって有用である。
【００６５】
インデクスツリー２のトップには根節点ルートノード４が位置付けられ、このルートノード４は、インデクスツリーの初期設定の際生成される第１ノードである。リーフノード５ａ，５ｂ，５ｃ，及び５ｄは、キーストリングフィールド６ａ，６ｂ，６ｃそして６ｄ並びに情報フィールド７ａ，７ｂ，７ｃ，７ｄに関連付けられ、それらのキーストリングフィールドは、インデクシングされるキーストリングを含み、前記情報フィールドは、ユーザがインデクシングされるキーストリングと関連付けたい任意の付加データを含む。注目すべきことには、ユーザは、複数情報フィールドを１つの所定のキーストリングと関連付けたいと願う。例えばキーストリングは、従業員識別番号であり得、別個の情報フィールドは、従業員氏名、アドレス、電話番号等であり得る。
【００６６】
２進ツリーにおけるように、内部節点ノードが存在し、それ等の内部ノード節点ノードは、所定のキーストリング又はユーザ提供の情報に関連付けられているのではなく、比較に関連付けられており、この比較は、所望のリーフノードへ向かっての方向、指示を与えるものである。図１には唯一の内部ノード節点８が示されているが、コンピュータプログラミングの当業者にとって、明らかなようにインデクスツリーがしばしば多数の内部ノードを有する。
【００６７】
内部ノード節点は、いくつかのデータフィールドを含む。親フィールド１０は当該節点の親ノード、ルート、根ノード４を参照する。Ｐｏｓ ｆｉｅｌｄ １１は、キャラクタ比較位置（ｐｏｓ）と称されるものについての情報を含む。このフィールドは各内部ノード節点に対して次の条件が充足されるように維持される、すなわち、第１のｐｏｓキャラクタ（すなわち、長さｐｏｓのサブストリング）は、その節点ノードから発するサブツリー内に含まれているリース節点ノードに関連するすべてのキーストリングに対して、同一であるとの条件が充足されるように維持される。キャラクタ比較位置が指示しているところによれば、キャラクタ比較が、共通のサブストリングにつづく後続の節点ノードにて行われるべきであるということである。キャラクタ比較位置は、同一のキャラクタシーケンスをスキップすることにより、インデクスツリーに亘って探索プロセスを加速するため使用される。Ｆ１ツリーの性質によれば、１つの所定のサブツリーのリーフ節点ノードに含まれているすべてのストリングが同じプレフィックスを有する。例えば、リーフ節点ノード５ｂ、５ｄは内部節点ノード８と共に１つのサブツリーを構成し、それぞれキーストリング“ｃｄａｆ”及び“ｃｄｄｈ”に関連付けられる。それ等の２つのサブストリングは、プレフィックス“ｃｄ”を共用する。この例では、内部節点ノード８のｐｏｓフィールドはキャラクタキャラクタ比較位置数２を含むこととなる、というのは、これは、内部節点ノード８から発するサブストリングに含まれるすべてのストリングの長さであるからである。当該のキャラクタ比較位置に関連するキャラクタは、第３キャラクタであり、この第３キャラクタは、２つのサブストリングが共通に有しない第１のキャラクタである。
【００６８】
Ｓｕｃｃフィールド１２は、後継者節点ノードの現在、瞬時番号のトラックをキープする。事例では、内部節点ノード８は、２つの後継者リニア８ｂ及びリーフ節点ノード５ｃを有する。ＳｕｃｃＦｉｒｓｔフィールド１３は、すべての後継者ノード節点ノードの２重にリンクされたＮＵＬＬ−終端されたリスト（時により、サイブリングリストと称される）の第１のノードに対する参照である。事例中内部ノード８のＳｕｃｃＦｉｒｓｔフィールド１３は、リーフ節点ノード５ｂを参照する。ＳｕｃｃＦｉｒｓｔフィールド１３は、他のものの中で、ＲＥＭＯＶＥ機能のために用いられ、これについては以下説明する。
【００６９】
ＣＨフィールド１４は節点ノードの比較キャラクタを有する。比較キャラクタは、或１つの節点ノードをサイブリングノードから区別、識別する第１のキャラクタである（これは他の点では同じストリングを共有する）。
【００７０】
ＳｂｌＰｒｅｖ フィールド１５は、サイブリングリストの先行（左隣）の節点ノードへの参照リンクである。サイブリングリストの先行節点ノードがない場合、（リファレンス）リンクは、ＮＵＬＬ（零）リファレンスである。同様に、ｓｂｔＮｅｘｔフィールド１６は、サイブリングリストの次の（右隣）ノードへのサイブリングリストの次の節点ノードがない場合、参照リンクは、零参照である。事例では、内部節点ノードへの参照リンクであり、内部節点ノード８のフィールド１６は、リーフ節点ノード５ｄへの参照リンクである。
【００７１】
ローカル後継者ハッシュ表１７は、追従すべき適正な後継者ブランチの探索及び識別に使用される（すなわち、所定の探索中進行すべきツリーを更に１レベル下る）。ローカル後継者ハッシュ表１７は、ハッシュ表アレイ１８及びフィールド１９からなる。ハッシュ表アレイ１８は、キャラクタ値を表すハッシュバケットの固定数を含む。事例では基礎を成すキーストリングを構成する８つのキャラクタが４つのハッシュバケット１８ａ、１８ｂ，１８ｃ及び１８ｄを横切って均一に分布している。上述のように内部ノード８から発するサブツリーのリファレンス節点ノードに含まれるすべてのキーストリングが同じスタートｐｏｓキャラクタを有するので、これは、事例中２つのキャラクタ“ｃｄ”となる、それ等のｐｏｓストリングに対する後続のキャラクタ、これもまたキャラクタ比較位置キャラクタ、すなわち、それぞれ“ａ”及び“ｄ”はハッシュバケット内に置かれる。事例中キャラクタ“ａ”及び“ｅ”は、ハッシュバケット１８ａ割り当てられており、“ｂ”及び“ｆ”はハッシュバケット１８ｂに、そして、“ｃ”及び“ｇ”は、ハッシュバケット１８ｃに、そして、“ｄ”及び“ｈ２は、ハッシュバケット１８ｄに割り当てられている。こうしてハッシュバケット１８ａは、リーフ節点ノード５ｂへの参照リンクを有し、ハッシュバケット１８ｄは、リーフ節点ノード５ｃへの参照を有する。
【００７２】
ＨａｓｈＮｅｘｔフィールド１９は、ハッシュ衝突リストに対する参照リンクとして用いられる。事例中“ｃ”及び“ｇ”もまた、ルート根節点ノード４のハッシュ表アレイ中に同じハッシュバケットを有するので、そして１つの有利な実施例では各ハッシュバケットが唯一の他のノード節点にのみ参照を有し得るので、後継者ノード節点、ルート根節点ノード―それの比較キャラクタが“ｃ”であるーがそれの比較キャラクタが“ｇ”であるサイブリング節点ノードを参照することが必要である。こうして、内部ノード８のｈａｓｈＮｅｘｔフィールド１９は、リーフ節点ノード５ｄへの参照リンクを有する。
【００７３】
１つのリーフ節点ノードは、リーフ節点ノードであり得、（インデクスツリーが唯一のエントリからなる場合）、又は１つの内部ノードであり得る。事例中リーフ節点ノード４は、１つの内部節点ノードである。こうして、ルート根節点ノード４は、内部節点ノード８と同じフィールドを有しない（こうしてルート根節点ノード４の親フィールドは零ポイント（ＮＵＬＬ ｐｏｉｎｔｅｒ）リーフ節点ノード５ａ，５ｂ，５ｃを有する）。及び５ｄもまた、いくつかのデータフィールドを含む。図１に関連して述べると、リーフ節点ノード５ｂは、典型的リーフ節点ノードの１例として挙げられている。リーフ節点ノード５ｂの親フィールド２０，ｃｈフィールド２４ｂ、ｓｂｌｐｒｅｖフィールド２５，及びｓｂｌＮｅｘｔフィールド２６は、内部ノード８の親フィールド１０，ｃｈフィールド１４，ｓｂｌｐｒｅｖフィールド１５，及びｓｂｌＮｅｘｔフィールド１６に類似する。Ｐｏｓフィールド２１は、それを１つのリーフ節点ノードとして識別するため“無限”“ｉｎｆｉｎｉｔｅ”、１つの特別な値にセットされる。ｓｕｃｃフィールドの内部は不確実である。リーフ節点ノードは後継者を有しないからである。キーフィールド２７は、キーストリングフィールド６ｂを参照し、一方ｉｎｆｏフィールド２８は、情報フィールド７ｂを参照する。
【００７４】
事例中明らかになることは、キーストリング“ａｂｃｄ”キャラクタ“ａ”でスタートする唯一のキーストリングは、リーフ節点ノード５ａに関連付けられ、ｃｈフィールド２４ａは、キャラクタ“ａ”を含む。同様７に、キーストリングキャラクタ“ｇ”でスタートする唯一のキーストリングは、リーフ節点ノード５６ｄに関連付けられ、該リーフ節点ノードのｃｈフィールド２４ｄはキャラクタ“ｇ”を含む。キャラクタ“ｃ”でスタートする複数のキーストリング、すなわち、“ｃｄａｆ”及び“ｃｄｄｈ”）、があるので、それ等のキーストリングに関連するリーフ節点ノードはルート根節点ノード４の後継者になり得る。むしろ、内部節点ノード８は、キャラクタ“ｃ”をもってスタートするキーストリング（これはフィールド１４内に記憶されているキャラクタである）が共有していない第１のキャラクタは、どのハッシュバケットが適用可能であるかを決めるために使用される。第３のキャラクタが“ａ”である場合、リーフ節点ノード５ｂに参照が成される。他方、第３のキャラクタが“ｄ”である場合、参照は、リーフ節点ノード５ｃになされる。
【００７５】
初期設定
ライブラリィは初期設定プロセスを介してユーザにより供給されるメモリエリア内に初期設定される。初期設定が完了完結すると、初期設定されたＦＩインデクスに対するハンドルがリターンされる。ユーザは、供給されたメモリバッファを参照すべくアイキャッチャ（ｅｙｅｃａｔｃｈｅｒ）として知られている識別子ストリングを規定し得る。このことにより、マルチプロセスアプリケーションにおける１度での初期設定が保証され、ここでバッファは、通常共通メモリ内に常駐する。次の入力及び出力パラメータは、クリエイト動作に置いて使用され、この動作は、初期設定の有利な実施例態様である。
【００７６】
入力パラメータは、＜ｂｕｆｆｅｒ＞、＜ｉｄｅｎｔ＞、＜ｍａｘＩｎｄｅｘ＞、＜ｍａｘＫｅｙｓ＞、＜ｍａｘＫｅｙＬｅｎ＞、及び＜ｗｉｌｄｃａｒｄＣｎ＞を含む。＜ｂｕｆｆｅｒ＞パラメータは、ＦＩ管理のためにユーザにより供給される順次メモリエリアである。＜ｂｕｆｆｅｒ＞はまた、マルチプロセスアプリケーションに対する共有のメモリアドレスであり得る。＜ｉｄｅｎｔ＞パラメータはＦＩインスタンスを特有―意的に識別するアイキャッチャ（ｅｙｅｃａｔｃｈｅｒ＞であり、マルチスレッドアプリケーションにおける多重初期設定を阻止するため使用される。＜ｍａｘＩｎｄｅｘ＞パラメータは、独立にハンドルし得る個別インデックスの最大数を与える。＜ｍａｘＫｅｙｓ＞パラメータは、インデックスにエントリ（キーストリング）の最大数を与え、すべての個別のインデックスの非繰り返し和である。＜ｍａｘＫｅｙＬｅｎ＞パラメータは、すべてのインデックスにおいて、キーストリングに対して、バイトで、最大キーストリング長さを与える。＜ｗｉｌｄｃａｒｄＣｈ＞パラメータは、パーシャルマッチング探索に対するワイルドカードとして使用されるキャラクタを含む。
【００７７】
出力パラメータ＜ｈａｎｄｌｌｅ＞は、新たにクリエイト（生成）されるＦＩインスタンスであり、後続のＦＩライブラリィコールに対するハンドル（参照）として使用される。
【００７８】
初期設定プロセスは、いくつかの目的を達成する。１つの目的は、メモリにおけるＦＩ管理構造を初期設定することである。もう１つの目的は任意の多重の初期設定を検出ためアイキャッチャを提供することである（マルチプロセス及び／又は、マルチスレッド環境における一度での初期設定を確保するため）。また、初期設定プロセスは、固定サイズの高速ＬＩＦＯ（ｌａｓｔｉｎ、 ｆｉｒｓｔ ｏｕｔ）に基づくメモリマネージメントを初期化し、実質的に一定時間でインデクスツリーノード割当てをアロケートし、フリー解放するものである。更に、内部ノードスタックが初期設定され、その結果パーシャルマッチング問い合わせにてインデクスツリーを再帰的にサーチする際ハッシュフラグポイントを記憶し得る。
【００７９】
インデクスオブジェクトのオープニング
多重インデクスは同時にデータの同じセット上にオープンされ得、この同じセットにより、インデックスが同時に使用され得る。ＯＰＥＮ Ｏｐｅｒａｔｉｏｎは、ＣＲＥＡＴＥ Ｏｐｅｒａｔｉｏｎ により先に初期設定されたグローバルなＦＩインスタンス内に１つの新たな空のインデクスオブジェクトをクリエイト生成する。次の入力及び出力パラメータは、ＯＰＥＮ Ｏｐｅｒａｔｉｏｎ の有利な実施例において使用される。
【００８０】
入力パラメータは＜ｆｉＨｄ＞、＜ＩｄｘＩｄ＞、及び＜ｍａｘＫｅｙＬｅｎ＞を含む。＜ｆｉＨｄ＞ ｐａｒａｍｅｔｅｒは、グローバルｆｉインスタンス（ＣＲＥＡＴＥ Ｏｐｅｒａｔｉｏｎによりターンされる）。＜ＩｄｘＩｄ＞は、オープンされつつあるインデクスを特有一義的に識別するアイキャッチャであり、メモリを共有するマルチプロセスアプリケーションにおける多重初期設定を阻止するために使用される。＜ｍａｘＫｅｙＬｅｎ＞パラメータは、インデクス中に置かれるべきキーストリングに対してバイトにて、最大のキーストリングを与えるものであり、ＣＲＥＡＴＥ ｏｐｅｒａｔｉｏｎにおける＜ｍａｘＫｅｙＬｅｎ＞の値に等しいか、又はそれにより小である。
【００８１】
出力パラメータ＜ｈａｎｄｌｅ＞は、新たにクリエイト生成されるインデクスオブジェクトに対する参照であり、後続のインデクス動作に対するハンドル処理である。
【００８２】
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎは、指定されたキーストリングを指定されたインデクスオブジェクト中に挿入する。前述のように、ユーザにより供給されるデータは、インデクスにおける各キーストリングに関連付けられる。
【００８３】
１つのキーストリングが１つのインデクス中に挿入される度ごとに、１つの新たなＦＩキーオブジェクト（すなわちインデクスツリーのリーフ）が内部的に生成され、そして、キーに対するハンドルがコールする者、コーラー（ｃａｌｌｅｒ）にリターンされる。該ハンドルは、インデクスツリー内でキーエントリを参照するため使用され得る（例えば ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎのため）。キーストリング自体は、インデクスメモリ内に記憶されない。むしろ、ＦＩは、ユーザにより供給される参照を介してストリングを参照する。
【００８４】
有利な実施例では、挿入すべきストリングはＯＰＥＮ Ｏｐｅｒａｔｉｏｎにより指定された少なくとも＜ｍａｘＫｅｙＬｅｎ＞の長さを有し、ストリング終端キャラクタを有しない。この実施例では、＜ｍａｘＫｅｙＬｅｎ＞より短いストリングは、右側が空白文字キャラクタでパディングされるべきである。
【００８５】
留意すべきことには、ストリング終端キャラクタ及び／又はワイルドカードを使用する本発明の実施例は、任意の２進データを含むキーストリングのインデクシングを複雑化し得る。現在公知の技術（代替選択的オルタナティブ、フォーマットにおける２進データのコーディング又はキーストリングの長さを指定する各キーストリングフィールドをもっての＜ＫｅｙＬｅｎ＞の蓄積）がそのような複雑性を克服するため使用され得る。
【００８６】
有利な実施例では、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ を、ワイルドカードキャラクタを含むストリング上に使用し得、その結果キーセット全体を単一の挿入オペレーション動作によりロジカルに記憶し得る。例えば“＊”がワイルドカードであり、動作オペレーション ＩＮＳＥＲＴ（“ｂｃｄ＊＊”）にＦＩＮＤ（“ｂｃｄｅｆ”）及びＦＩＮＤ（“ｂｃｄｇｈ”）が続くものと仮定すると、（ＦＩＮＤ Ｏｐｅｒａｔｉｏｎは以下詳述する）、両問い合わせにより、“ｂｃｄ＊＊”が与えられる。こうして、ＦＩのワイルドカードを衝突検出目的のため（例えば、データベースのロジカルロックマネージメント）のため使用し得る。次の入力、出力パラメータは、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例にて使用される。
【００８７】
＜ｉｄｘＨｄ＞入力パラメータはアクセスされているインデクスオブジェクトのハンドルである。＜ＫｅｙＳｔｒ＞入力パラメータは、インデクス中に挿入されるべきキーストリングに対するポインタである。＜ｕｓｒＩｎｆｏ＞入力パラメータは、インデクス中に挿入されているキーストリングと関連付けたいとユーザが願うデータに対するポインタである。
【００８８】
出力パラメータ＜ＫｅｙＨａｎｄｌｅ＞は、新たに挿入されるキーオブジェクトに対する１つのハンドルである。
【００８９】
ＩＮＳＥＲＴ ｏｐｅｒａｔｉｏｎの有利な実施例により実行されるステップは、フローチャート２００に概略が示されており、これは、図２及び図２ａに示されている。第１ステップは、メモリ内での１つの新たなリーフノードブロックのアロケーション２０２である。次に参照２０４は、＜ｔ＞を、入力パラメータ＜ｉｄｘＨｄ＞により参照されるインデクスツリーの根ルートにすることによりなされる。
【００９０】
判定２０６は、インデクスがルートにて空であるか否かを判定する。ＹＥＳの場合、＜ｎｅｗＫｅｙ＞のレジストレーション２０８がインデクスツリーの新たなルート根としてなされ、オペレーション動作は、出力パラメータ＜ＫｅｙＨａｎｄｌｅ＞として、アプリケーション２０２にてアロケート割り当てされた新たなリーフノードブロックに対する参照のリターン２８４へ進む。
【００９１】
他方では、デシジョン２０６にてインデクスが根にて空でないことが判明した場合、判定２１０は、１つのリーフノードに到達したか否かを判定する。ＹＥＳの場合には、判定２１８が実行される。他方ではＮＯの場合には、ルックアップ２１２過程が、第１のｐｏｓキャラクタ（上述のようにｐｏｓは現在ノード節点に対するキャラクタ比較位置を表す）の後直ちにキーストリング＜ＫｅｙＳｔｒ＞キャラクタに相応するエントリに対する現在ノード節点のローカル後継者ハッシュ表にて実行され、１つの相応のエントリがルックアップ２１２にて見出された場合、現在ノード節点としてそのエントリにて参照されたノード節点のアサインメント２１６過程が生起する（すなわち、参照されたノード節点が現在ノード節点となる）。他方では、ルックアップ２１２のプロセス中にて相応のエントリが見出されない場合、現在ノード節点として第１の後継者ノード節点（ｓｕｃｃＦｉｒｓｔ フィールドから取られた）のアサインメント２１４過程が生起する。いずれのケースにおいても、次いで現在ノード節点が判定２１０へ与えられる。
【００９２】
判定２１８は、キーストリング＜Ｋｅｙ Ｓｔｒ＞に一致する１つのキーストリングが既に現在ノード節点にて存在しているか否かを判定するため実行される。そのようなキーストリングに既に存在する場合、挿入過程が生起せず、そして、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の終端ターミネーション２２０過程がエラー条件と共に生起する。同一のキーストリングが既に存在しない場合には、比較２２２は、現在ノードに関連するキーストリング及びキーストリング＜ＫｅｙＳｔｒ＞により共有されるサブストリングの長さ＜ｊ＞を決定するため実行される。次いで、現在ノード節点からスタートして、ツリーのトラバース走査２２４過程が、それぞれのノード節点の親ノード節点をポイントするリンクをたどることにより上方に向かって生起進行していって、ついには、ノード＜ｔ＞に到達するようになり、このノード節点＜ｔ＞のキャラクタ比較位置ｐｏｓは、サブストリング長さ＜ｊ＞に等しい、又は、それより小である。このノード節点に到達すると、外部又は内部ツリー挿入を実行すべきかの判定２３０が、図２ａに示すように実行される。
【００９３】
判定２３２及び２３４により、ノード＜ｔ＞が空であるか、又は＜ｔ＞の比較位置ｐｏｓが＜ｊ＞に等しいことが判定された場合、内部ツリー挿入２４０が実行される。これに反し＜ｔ＞が空でなく、そして、＜ｔ＞の比較位置が＜ｊ＞に等しくない場合、内部ツリー挿入インサート２６０が実行される。
【００９４】
外部ツリー挿入２４０は、次のステップを含む。新たなノード節点の親ノード節点＜ｔ＞のレジストレーション２４２過程ステップが実行される。新たなノード節点（これは、アロケーション２０２においてアロケートされた新たなリーフノード節点ブロックである）へのポインタの挿入２４４は、適当なキーストリングキャラクタのもとで＜ｔ＞のローカル後継者ハッシュ表にて実行され、そして、任意の悪影響を受けたフィールドが更新される（例えば、ｈａｓｈＮｅｘｔ フィールド又は、実施例で使用される場合には、ｈａｓｈＰｒｅｖ フィールド）。＜ｔ＞の後継者ノード節点の２重にリンクされたサイブリングリスト内への新たなノード節点の挿入２４６もまた、適当なｓｂｌＮｅｘｔ及びｓｂｌＰｒｅｖ フィールドを更新することにより実行される。判定２４８は、ノード節点＜ｔ＞の比較位置がワイルドカードキャラクタであるか否かを判定するため実行される。ＹＥＳの場合＜ｔ＞のワイルドカードフラグ（実施例中に存在するならば）がセットされる。
【００９５】
内部ツリー挿入２６０は次のステップを含む。新たなノード節点ブロックのアロケーション２６２が実行される。次に、新たなリーフ節点ブロック（これはアロケーション２０２にてアロケートされたものである）へのポインタの挿入２６４が第２の新たなノード節点ブロックのローカルサクセッサ後継者ハッシュ表にて実行される。判定２６６は、ノード＜ｔ＞がＮＵＬＬ参照であるか否か判定するため実行される。ＹＥＳの場合は、インデクスツリーの新たな根としての第２の新たなノード節点ブロックのレジストレーションが実行される。判定２６６の結果如何に係わらず、第２の新たなノード節点ブロックの、それの親のローカル後継者ハッシュ表内への挿入２７０が実行される。内部ツリー挿入２６０は第２の新たなノード節点ブロックの、それの親の後継者ノード節点の２重にリンクされたサイブリングリスト内への挿入２７２をもって終了する。挿入２７２もまた、適当なｓｂｌＮｅｘｔ及びｓｂ１ Ｐｒｅｖフィールドを更新する。
【００９６】
出力ツリー挿入２４０又は、入力ツリー挿入２６０過程が実行されるかに係わりなく、次のステップは、親ノード節点の後継者カウンタのインクリメント２８０である。それに引き続いて、親ノードのワイルドカードフラグのセッティング２８２は、１つのワイルドカードがそれの後継者ノード節点間にある場合には実行される。アロケーション２０２にてアロケーション割当られた新たなリーフノード節点への参照のリターン２８４が出力パラメータ＜ＫｅｙＨａｎｄｌｅ＞ として実行される。
【００９７】
上述のようなフローチャート２００に対する上述のステップにより示されているように、高速ＬＩＦＯメモリマネージャの使用により、従来のメモリマネージメントに対する改良がクリエイト創出される。従来のメモリマネージメントの実行時間が、概して、少なくとも最悪のケースにおいて、アロケーション割当られたメモリブロックの総数に依存する。多数のエントリが存在する状況では、従来方法は禁止的に低速である。ＬＩＦＯメモリマネージャは、示されているように、ツリーノード節点の固定サイズを利用し、これによりツリーノード節点がフリー、自由なエントリのスタック上に置かれ得る。スタック上に自由なフリーノードを、プッシュすること、又はアロケートされたノードをスタックから除去することが単一のスタックオペレーション動作に含まれるので、ＬＩＦＯメモリマネージメントの実行時間がアロケーション割当られたノード節点の数に無関係である。
【００９８】
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの事例
次いでＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の１例の概略を説明する。図３及び図４に関連して述べると、そこに示されたＩＮＳＥＲＴ （“ｃｅｄｇ”）Ｏｐｅｒａｔｉｏｎ の１事例がインデクスツリー３０２上で実行され、このインデクスツリーは、インデクスツリー２と同じようにスタートする。ＦＩは、新たなキーストリングに対する挿入の場所を見出すためインデクスツリー３０２をトラバース走査する。ＦＩは、根ノード節点４でスタートし、この根ノード節点４のｐｏｓフィールド３３１は、最初の第１の零キャラクタが、根ノード節点４から発するサブツリー内に含まれているすべてのキーストリングに対して同一である（すなわち、第１のキャラクタのどれもが同一でない）ことを指示する。こうして、挿入すべきストリングの第１キャラクタが“ｃ”であるので、ＦＩハッシュ表配列３４０内でハッシュバケット３４１をルックアップする。ＦＩは内部ノード節点８への“ｃ”ブランチ参照３５０過程を引き続いて行う。更に留意すべきことには、挿入ストリングが第１のキャラクタとして“ｇ”を有するならば、ハッシュ衝突が生じることとなり（それというのは、“ｃ”と“ｇ”の双方がハッシュバケット３４１を占めることとなるからである）、そして、ｈａｓＮｅｘｔ フィールド１９に含まれるリーフノード節点５ｄへの参照リンクをたどることとなるからである。
【００９９】
内部ノード節点８にて、ｐｏｓフィールド１１は、キャラクタ比較位置ｐｏｓが２であることを指示する。こうして、挿入すべきストリングの第３のキャラクタ、すなわち、“ｄ”が考慮され、ＦＩはハッシュ表配列１８にてハッシュバケット１８ｄをルックアップする、ＦＩはリーフノード節点５ｃへの“ｄ”ブランチ３６０過程を実行する。
【０１００】
次いで、ＦＩは、次のようなノードを見出すまでツリーインデックス３０２を再びバックアップ方向にトラバース走査する、すなわち、その比較位置ｐｏｓが、サブストリングの長さに等しいか、それより、小であるノードを見出すまでトラバース走査するものであり、当該のサブストリングは、“ｃｅｄｇ”がリーフノード５ｃに関連付けられたキーストリング（すなわち、“ｃｄｄｈ”）と共有するのである。結論付けられることは、ＦＩは、そこにてｐｏｓが１に等しいか、それより小であるｐｏｓフィールドを探す。ＦＩが親ノード節点リンク３７０及び３８０を通してそれの上向きのトラバース走査上にて見出す、当該の基準を充足する第１のｐｏｓフィールドは、ｐｏｓフィールド３３１であり、このｐｏｓフィールドは、根ノード節点４の１つのフィールドであり得る。ノード節点が空でなく（上記の判定２３２）そして、ｐｏｓフィールド３３１が１に等しくない（上記の判定２３４）ので、内部ツリー挿入２６０は、実行される必要がある。
【０１０１】
図４は、内部ツリー挿入２６０の実行の際のインデクスツリー４０２へのインデクスツリー３０２の変換を示す。第１に２つの新たなノード節点である、新たな内部ノード節点４０８及び新たなリーフノード節点４０５がＦＩのＬＩＦＯメモリマネージャ（ＬＩＦＯ―ＭＭ）４４０からアロケーション割当られる。新たな内部ノード節点４０８がノード節点４の“ｃ”ブランチ参照３５０の後継者として挿入される。古い“ｃ”ブランチのサクセッサ継承者−これは内部ノード節点８であるーは今や新たな内部ノード節点４０８の“ｄ”ブランチ参照４５０のサクセッサ継承者になる。更に新たにリーフノード４０５は、新たな内部ノード節点４０８の“ｅ”ブランチとなる。
【０１０２】
ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎは、関連付けられたノード節点をリムーブ除去することにより、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ により先に挿入された１つの所定のインデクスエントリをリムーブ除去するものである。リムーブ除去すべきインデクスエントリは、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ又はＦＩＮＤ Ｏｐｅｒａｔｉｏｎによりリターンされるような、それの相応のキーハンドルにより指定される。
【０１０３】
次の入力パラメータはＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ又はＦＩＮＤ Ｏｐｅｒａｔｉｏｎの有利な実施例において使用される。＜ｉｄｘＨｄ＞入力パラメータは、そこからインデクスエントリを除去すべきインデクスオブジェクトのハンドル処理である。（ＫｅｙＨａｎｄｌｅ＞入力パラメータは、除去すべきインデクスエントリ（又はノード節点）に対するハンドルである。
【０１０４】
図５に関連して述べると、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例により実行されるステップは、フローチャート５００に概略が示されている。第１のステップは、除去すべきノード節点が、親ノード節点を有するか否かを判定することである。ＮＯの場合には、ＮＵＬＬ参照へのインデクスツリーの根のセッティング５０６過程が実行され、その後、除去されたツリーノード節点に属するメモリブロック８のフリー解放５５０が実行される。他方では、ノード節点が１つの親ノード節点が有する場合、親ノード節点に対する当該ノード節点への参照を除くステップ５０８（親ノード節点のｓｕｃｃＦｉｒｓｔ フィールドもまたモデファイし得る）が実行される。更に、親ノード節点の後継者ノード節点の２重連結されたサイブリングリストからのノード節点の除去５１０が適当なｓｂｌＮｅｘｔ ｓｂｌＰｒｅｖ フィールドを更新することにより実行される。次に親ノード節点のサクセッサ後継者カウンタのデクリメント５１２が実行される。このポイントにて、インデクスツリー中には除去されたノード節点への参照がもはや無い。しかしながら、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ は、インデクスツリーをモデファイする必要が起こり得る。
【０１０５】
判定５２０は、親ノード節点が１つより多くの後継者ノード節点を左に有するかを判定する。ＹＥＳの場合には、除去されたノード節点の比較キャラクタがワイルドカードであったか否かを判定する。他方では親ノード節点が唯一の後継者ノード節点のみを左に有する場合には、親ノード節点は、ブランチングポイントとしてもはや使いものにならず、判定５２２は、グランドペアレント（すなわち、除去されたノード節点のグランドペアレント、また、親ノード節点の親）が存在するか否かを判定する。グランドペアレントノード節点が存在しない場合、インデクスツリーの新しい根のアサインメント割当５２４が除去されたノード節点の唯一のサイブリングに与えられ、その後、除去されたノード節点の唯一のサイブリングの比較キャラクタがワイルドカードであったか否かの判定５４０が実行される。他方では、グランドペアレントが存在する場合には、グランドペアレントノードハッシュ表からの親ノードの連結分離５２１が実行される。次に除去されたノード節点の唯一のサイブリングへの参照の挿入５２８がグランドペアレントにて実行される。親ノード節点の除去５３０が実行される。グランドペアレントは今や新たな親ノードとなる。
【０１０６】
判定５４０は、除去されたノード節点の比較キャラクタがワイルドカードであったか否かを判定する。ＹＥＳの場合、ワイルドカードフラグの削除５４２が親ノード節点にて実行される。除去されたノード節点の比較ｖｒｋがワイルドカードであったか否かに拘わらず、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ は、除去されたツリーノード節点に属するメモリブロックのフリー解放５５０で終了する。
【０１０７】
フローチャート５００で上述のステップで示されているように、ノード節点へのリンクの除去（２重リンクされたサイブリングリストからのノード節点の除去５１０のような）によりメモリブロックのフリー解放５５２が生ぜしめられる。従来のシングルリンク、単一連結されたリストが使用された場合には１つのノード節点を除くには、除去すべきノード節点が見出されるまでにサイブリングリストを直線的にサーチすることが必要となる。このことにより、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎの実行時間に対して直線的成分が生成されることとなる。最悪の場合には、サイブリングリスト全体をサーチしなければならなくなる。しかしながら、２重に連結されたサイブリングリストは、ＬＩＦＯメモリと相俟って、いずれの直線的リストスキャニングなしでもノードの削除をサポートし、それにより全体的性能を改善する。
【０１０８】
ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の事例
次にＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎの１事例の概略を説明する。図６及び図７について説明すると、ＲＥＭＯＶＥ（“ｃｄａｆ”） Ｏｐｅｒａｔｉｏｎの１事例がインデクスツリー６０２上へ実行され、これはインデクスツリー２と同じようにスタートする。先ず、仮定されていることによれば、ユーザは、除去すべきリーフノード節点（事例中のリーフノード節点５ｂ）を識別する必要なキーハンドル＜ＫｅｙＨａｎｄｌｅ＞を供給する。リーフノード５ｂは、先ず、内部ノード節点８から除去される。内部ノード節点は、今や唯一の後継者ノード節点（すなわち、リーフノード節点５ｃ）を有するので、内部ノード節点は、ブランチングポイントとしてもはや使用されなくなり、除去する必要がある。従って、内部ノード節点８及び根ノード節点４の“ｃ”のブランチ参照３５０が除去される。フリー解放ノード、リーフノード節点５ｂ及び内部ノード節点８は、ＬＩＦＯ―ＭＭ４４０にリターンされる。
【０１０９】
図７に関連して述べると、インデクスツリー７０２は、古いリーフノード節点５ｃから変換された、新たなリーフノード節点７１０を有する。根ノード節点４の“ｃ”ブランチ参照３５０は、リーフノード７１０への“ｃ”ブランチ参照７５０により置換される。リーフノード７１０は、リーフノード５ａ及び５ｄを有する２重リンクされたサイブリングリスト７６０を継承インヘリタンスする。リーフノード７１０の ＨａｓｈＮｅｘｔ フィールド７２０は、ｈａｓｈＮｅｘｔ フィールド１９のコンテンツを継承インヘリタンスする。
【０１１０】
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｅｘａｃｔ Ｍａｔｃｈ）（精確なマッチン グ）
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｅｘａｃｔ Ｍａｔｃｈ）の精確なマッチングーバージョンは、サーチキーストリングを精確にマッチングするエントリに対する指定されたインデクスをサーチする。パーシャルマッチング問い合わせと異なって、ワイルドカードキャラクタは、精確なサーチにおいて特別な意味を有しない。せいぜい、１つのインデクスエントリは、サーチストリングをマッチングする。当該のオペレーション動作が成功を収めて完結すると、マッチングインデクスエントリのＫｅｙＨａｎｄｌｅがリターンされる。次の入力、出力パラメータは、ＦＩＮＤ ＯｐｅｒａｔｉｏｎのＥｘａｃｔ Ｍａｔｃｈ ｖｅｒｓｉｏｎ の精確なマッチングーバージョンの有利な実施例において使用される。
【０１１１】
＜ｉｄｘＨｄ＞入力パラメータは、サーチすべきインデクスオブジェクトのハンドルである。＜ＫｅｙＳｔｒ＞入力パラメータは、インデクスに対してサーチされているキーストリングに対するポインタである。＜ＫｅｙＨａｎｄｌｅ＞出力パラメータは、マッチングインデクスエントリに対するハンドルである。
【０１１２】
図８について述べれば、 ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｅｘａｃｔ Ｍａｔｃｈ）の精確なマッチングーバージョンの有利な実施例により実行されるステップは、フローチャート８００に概略が示されている。第１のステップは、サーチされているインデクスツリーの根ノード節点への参照８０２である。
【０１１３】
次に、判定８０４は、現在ノードが内部ノードであるか否かを判定する。ＮＯの場合には、完結したストリング比較８２０が、サーチキーストリングと、現在ノードに関連したキーストリングとの間で実行される。現在ノードが内部ノードである場合には、ノードのキャラクタ比較位置にてサーチキーストリングキャラクタの考慮検討８０６がなされる。次のノードへのポインタの検索８０８が、現在ノードの後継者ハッシュ表を使用することにより実施される。次に新たな現在ノードとなるべき次のノードのアサインメント割当８１０が実行される。判定８０４は、新たな現在ノードに対して実行される。
【０１１４】
サーチキーストリングと、現在ノードに関連したキーストリングとの間で完結したストリング比較８２０が実行される。 ストリングが同一でない場合、サーチの終端ターミネーション８２２が実行され、エラーコンディションが立てられる。他方では、ストリングが同一である場合、インデクスエントリに対するハンドルとして現在リーフノードへの参照のリターン８２４が実行される。
【０１１５】
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｐａｒｔｉａｌ Ｍａｔｃｈ）
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｐａｒｔｉａｌ Ｍａｔｃｈ）を、すべてのインデクスエントリのセットに対して反復的に、ワイルドカードキャラクタを有する１つの指定されたサーチストリングマッチングをスキャンするため使用し得る（本発明の有利な実施例ではワイルドカードキャラクタは略称では“＊”である。例えば、オペレーション動作Ｏｐｅｒａｔｉｏｎ ＩＮＳＥＲＴ（“ａｂａｄｃ”）、ＩＮＳＥＲＴ（ａｂｂｃｄ“）、ＩＮＳＥＲＴ（”ｂａ＊ｄｃ）、ＩＮＳＥＲＴ（“ｂａ＊ｄｄ）、ＩＮＳＥＲＴ（“ｂａｄａｃ”）、ＩＮＳＥＲＴ（“ｂａｄｂｃ”）、及びＩＮＳＥＲＴ（“ｄ＊ａ＊＊”）の条件下で、パーシャルマッチング問い合わせ検出ｐａｒｔｉａｌ ｍａｔｃｈ ｑｕｅｒｙ ＦＩＮＤ（“＊ｂ＊ｃｄ”）により“ａｂｂｃｄ”及び“ｄ＊ａ＊＊”が与えられる。それというのは、ストリングエントリの第１，第２キャラクタは、当該の特定の目的に重要でないからである。次の入力、出力パラメータがＦＩＮＤＯｐｅｒａｔｉｏｎのパーシャルマッチングバージョン ｐａｒｔｉａｌ ｍａｔｃｈ ｖｅｒｓｉｏｎ の有利な実施例において使用される。
【０１１６】
入力パラメータは＜ｉｄｘＨｄ＞、＜ＫｅｙＳｔｒ＞、＜ｍａｘＲｅｓｕｌｔｓ＞及び＜ｒｅｓｕｌｔｓＢｕｆｆｅｒ＞を含む。＜ｉｄｘＨｄ＞パラメータは、サーチすべきインデクシングオブジェクトのハンドルである。＜ＫｅｙＳｔｒ＞パラメータは、インデクスにてサーチされているキーストリングに対するポインタである。＜ｍａｘＲｅｓｕｌｔｓ＞パラメータはＦＩＮＤ Ｏｐｅｒａｔｉｏｎの繰り返しごとにリターンされるべきキーハンドルの最大数である。＜ｒｅｓｕｌｔＢｕｆｆｅｒ＞は結果バッファに対するポインタであり、これは、＜ｍａｘＲｅｓｕｌｔｅ＞エントリまでホールドするのに十分な大きさのキーハンドルの配列である。
【０１１７】
出力パラメータは＜ａｃｔＲｅｓｕｌｔｓ＞及び＜ｍｏｒｅＲｅｓｕｌｔｓ＞を含む＜ａｃｔＲｅｓｕｌｔｓ＞パラメータは、結果バッファにおいてリターンされるキーの実際の数をリターンする。＜ｍｏｒｅＲｅｓｕｌｔｓ＞パラメータ、また、サーチコントロールパラメータとも称され、＜ｍａｘＮｕｍｂｅｒ＞結果より多くのものがあったか否かを指示するためのフラグとして用いられる。
【０１１８】
ｐａｒｔｉａｌ Ｍａｔｃｈ ＦＩＮＤ Ｏｐｅｒａｔｉｏｎの有利な実施例により実行されるステップがフローチャート９００にて概略が示されており、これは図９及び図９ａに示されている。第１のステップは、これがＦＩＮＤ Ｏｐｅｒａｔｉｏｎのコール（ｃａｌｌ）であるか否かを判定するための判定９０４である。ＹＥＳの場合、インデクスツリーの根節点ノードへのローカルバックトラッキングスタックポインタ＜ｓｐ＞のリセット９０６が実行される。他方、ＮＯの場合、ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ の先行コール呼出から先にセーブされたスタックポインタのリロード９０８が実行される。ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ の最初のコールであっても、なくても、次のステップは、バックトラッキングスタックが空であるか否かを判定すること９１０である。ＹＥＳの場合、ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ は、結果バッファのリターン９９４で終わる。他方では、否定の場合は、現在スタックトップからのツリーノード＜ｔ＞の検索９１１が実行される。次いで＜ｔ＞がリーフノードであるか否かを判定する判定９１２が実行される。ＹＥＳである場合、リーフノード解析９２０が実行される。他方ＮＯの場合、内部ノード解析９５０が実行される。
【０１１９】
リーフノード解析９２０は、サーチキーストリング及びリーフノードに関連するキーストリングが同じであるかを判定する比較９２２及びワイルドカードが考慮される際サーチキーストリング及びリーフノードに関連するキーストリングが同じであるか否かを判定する比較９２８からスタートする。２つのストリングが同じであるか、又はワイルドカードとマッチングする場合、リーフノードに関連するインデクスエントリの結果バッファへの加算９３０が、実行される（すなわち、インデクスエントリが結果バッファに加えられる）。ストリングが同じであるか、又はマッチングをしているかに拘わらず、サーチキーストリング及びリーフストリングに関連するキーストリングが相異なる場合にてワイルドカードでない第１キャラクタ位置であるべきとき現在キャラクタ位置のアサインメント９３１が実行される。リーフノード解析９２０は、バックトラックスタックの枝刈り９３２で終わる。バックトラックスタックの枝刈り９３２は反復的に次のことをチェック９３３すること及び除去９３４により実行され、すなわち、（ａ）スタックが空でないか否か、そして（ｂ）親ノードのキャラクタ比較位置＜ｐｏｓ＞がキャラクタ比較位置＜ｊ＞より大であるか否かのチェック９３３により実行され、そのことは、そして、それ等の２つの条件のうちの少なくとも１つがもはや充足されなくなるまでバックトラックスタックからのノードの除去９３４が実行されるのである。リーフノード解析９２０が終わった後、判定９１０が再び実行される。
【０１２０】
内部ノード解析９５０は、現在ノードのキャラクタ比較位置にて＜ｃｈ＞をサーチキーストリングキャラクタであるとのアサインメント９５２をもってスタートする。ワイルドカード チェック９５４は、＜ｃｈ＞がワイルドカードキャラクタであるか否かを判定する。ＹＥＳの場合、ワイルドカードは、バックトラックスタック上へのすべての後継者ノードのプッシュ９７０で終わる。プッシュ９７０は＜ｔ＞の後継者リスト内のサイブリングーリンク過程をたどることにより、当該タスクを成し遂げ、このことの意味することは、＜ｔ＞から下降するサブツリー全体が更なるサーチに対してマーキングされるということである。他方で、＜ｃｈ＞がワイルドカードキャラクタでない場合は、ハッシュ表のルックアップ９５５が実行される。ルックアップ９５５は、＜ｃｈ＞に関連する後継者ノード（又は、代替選択的に＜ｃｈ＞に関連する後継者ノードが存在しない場合は、第１の後継者ノード）を見出し、ノードをバックトラックスタック上にプッシュする。次に、判定９５６は、＜ｔ＞がそれの後継者ノード内にワイルドカードを有しているか否かを判定する。＜ｔ＞がワイルドカードを有していない場合には、内部ノード解析９５０は終了する。他方＜ｔ＞がワイルドカードを有している場合には内部ノード解析９５０はバックトラックスタック上へのワイルドカードノードのプッシュ９５８で終わる。内部ノード解析９５０が終わった後、判定９１０が再び実行される。
【０１２１】
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ ( ｐａｒｔｉａｌ Ｍａｔｃｈ ) の事例
次にＰａｒｔｉａｌ Ｍａｔｃｈ ＦＩＮＤ Ｏｐｅｒａｔｉｏｎの１事例の概略を説明する。図１０に関して述べると、ＦＩＮＤ（“＊ｂ＊ｃｄ”）ｏｐｅｒａｔｉｏｎ がインデクスツリー１００２上にて実行される様子が示されている。インデクスツリー１００２は、ノード１０１０，１０２０，１０３０，１０４０，１０５０，１０６０，１０７０，１０８０，１０９０，１１００，及び１１２０を比較する。ノード１０１０は、インデクスツリー１００２の根ノードである；従って、キャラクタ比較位置ｐｏｓ零を有する。内部ノード１０２０はｐｏｓ２及びキャラクタ“ａ”を有する；内部ノード１０３０はｐｏｓ２及びキャラクタ“ｂ”を有する；内部ノード１０７０はｐｏｓ４及び比較キャラクタ“＊”（ワイルドカードキャラクタ）を有する。内部ノード１０８０はｐｏｓ３及びキャラクタ“ｄ”を有する。リーフノード１０４０は、ノード１０１０の後継者ノードであり、キーストリング“ｄ＊ａ＊＊”に関連付けられている。リーフノード１０５０及び１０６０は、ノード１０２０の後継者ノードであり、それぞれキーストリング“ａｂａｄｃ”及び“ａｂｂｃｄ”に関連付けられている。リーフノード１０９０及び１１００はノード１０７０の後継者ノードであり、キーストリング“ｂａ＊ｄｃ”及び“ｂａ＊ｄｄ”に関連付けられている。リーフノード１１１０及び１１２０はノード１０８０の後継者ノードであり、それぞれキーストリング“ｂａｄａｃ”及び“ｂａｄｂｃ”に関連付けられている。
【０１２２】
ＦＩは、インデクスツリー１００２の根ノード１０１０におけるサーチをスタートする。ｐｏｓは、ノード１０１０に対して零であるのでＦＩは、サーチキーストリング“＊ｂ＊ｃｄ”の第１のキャラクタに注目する。これはワイルドカードキャラクタであり、而して、ＦＩは、ノード１０１０の各々の後継者ノード（すなわちノード１０２０，１０３０，及び１０４０）をバックトラッキングスタック上へプッシュする。留意すべきことには、バックトラッキングスタックは、トップ（最初）からボトム（最後）へ向かって、ノード１０２０，１０３０，及び１０４０を有する。バックトラッキングスタックにおける第１のノード、ノード１０２０は、トップからポップされる。ノード１０２０はｐｏｓ２を有するので、サーチキーストリングの第３キャラクタが評価される。これは、再度ワイルドカードキャラクタであり、而して、ＦＩは、ノード１０２０の各後継者ノード（則ちノード１０５０，１０６０）をバックトラックスタック上へプッシュする。バックトラックスタックは今やトップからボトムへ向かってノード１０５０，１０６０，１０３０，及び１０４０を有する。
【０１２３】
次いでノード１０５０はバックトラックスタックのトップからポップされる。これはリーフノードであるので、ＦＩは、第１の非ワイルドカードキャラクタ位置＜ｊ＞を判定し、ここでは、サーチキーストリングはノード１０５０に関連付けられたキーストリングとは相異なる。キーストリング“＊ｂ＊ｃｄ”及び“ａｂａｄｃ”は、第４のキャラクタにて差異があり（それ等は最初の３つのキャラクタに対してマッチングし、＜ｊ＞は３であるから）、そしてノード１０５０は、ミスマッチとして破棄される。ノード１０６０は、バックトラックスタックのトップからポップされる。これもまた、リーフノードであり、ＦＩは第１の非ワイルドカードキャラクタ位置＜ｊ＞を求め、ここで、サーチキーは、ノード１０６０に関連付けられたキーストリングとは異なる。しかしながら、“＊ｂ＊ｃｄ”及び“ａｂｂｃｄ”はマッチングし、而して、ノード１０６０に関連するキーエントリが結果バッファへの第１の加算になる。
【０１２４】
ＦＩは、バックトラックスタックにおいてなおスタックがあることを判定し、しかして、次のノード、ノード１０３０はトップからポップされる。ノード１０３０は、ｐｏｓ２を有する内部ノードになり、而して、サーチキーストリングの第３キャラクタが評価される。これはまた、ワイルドカードであり、而して、ＦＩはノード１０３０の各後継者ノード（則ち、ノード１０７０及び１０８０）をバックトラックスタック上へプッシュする。バックトラックスタックは、今やトップからボトムへ向かってノード１０７０，１０８０，１０３０，及び１０４０を有する。
【０１２５】
バックトラッキングスタックにおいて、なおノードがあり、而して、ノード１０７０は、トップからポップされる。ノード１０７０はｐｏｓ４を有する内部ノードであり、而してサーチキーストリングの第５キャラクタが評価される。この位置におけるキャラクタは“ｄ”であり、而して、ノード１０７０の“ｄ”ブランチ１０７２は、ノード１１００へ向けられる（プロセスにおけるノード１０９０破棄）。
【０１２６】
ノード１１００はリーフノードであり、而して、ＦＩは、第１の非ワイルドカードキャラクタ位置＜ｊ＞を判定し、ここで、サーチキーストリングは、ノード１０５０に関連するキーストリングとは異なる。キーストリング“＊ｂ＊ｃｄ”及び“ｂａ＊ｄｄ”は、第２のキャラクタにて相違なり、（それというのは、それ等は第１のキャラクタに対してマッチングするから＜ｊ＞は１である）そしてノード１１００はミスマッチとして破棄される。このポイントにおいてこそ発見的ヒューリスティックな枝刈り（ｐｒｕｎｉｎｇ）が付加的なサブツリー全体を破棄するため使用される。キーストリングがリーフノード１１００とは異なるー＜ｊ＞が１に等しい時―場合には、それの親ノードのｐｏｓが１より大である他のいずれのノードとも異ならなければならないということは、ＦＩツリーの性質、特性である。この性質、特性は、次のことに由来、導出される、すなわち、サブツリーに関連するすべてのキーストリングが、サブツリーの根における内部ノードのｐｏｓに等しい長さを有するプレフィックスを共有することに由来、導出される。従って、ノード１０３０は、ｐｏｓ２を有するので、バックトラッキングスタック内になお存在するサブツリー中のすべてのノード（すなわちノード１０７０及び１０８０）が破棄され得、それによりインデクスツリーが枝刈り（ｐｒｕｎｉｎｇ）される。
【０１２７】
バックトラッキングスタックにおいてなお残っている唯一のノード、ノード１０４０が、ポップされる。これはリーフノードであり、ＦＩは、第１の非ワイルドカードキャラクタ位置＜ｊ＞を求め、ここで、サーチキーは、ノード１０４０に関連するキーストリングとは異なる。しかしながら、“＊ｂ＊ｃｄ”及び“ｄ＊ｃ＊＊”はマッチングし、而してノード１０４０に関連するキーエントリは、結果バッファに加算される。考慮すべきノードはもはやなく、そして、結果スタックがリターンされる。
【０１２８】
図１１にはロジカルロックマネージメントを実行するためのＦＩメソッドを有利に利用する事例が表されている。ＦＩメソッドを、ヒューマンリソースマネージメント、ファイナンシャルズ、ロジスティックス、ビジネスワークフロー、組織マネージメント、及び他のシステムにおけるようなデータベースアプリケーションにおいて、衝突検出又は衝突マネージメントのため使用し得る。そのようなアプリケーションにおいて、多数のユーザ、例えば図１１中ユーザ１〜６は、データベース１２００にて記憶されているデータをアクセスする。ロジカルロックマネージメントは、いくつかのユーザがそこにてデータセットが変更訂正されるリクエスト又はオペレーションをもってデータベース中の同じデータセットへのアクセスするのを阻止するために実行され、前記のリクエスト又はオペレーション操作では、データセットは、例えば、書込又は削除により変更される。保証されなければならないのは、相次いでのユーザにより当該のデータセットの変更が所定の順序で実行されることである。
【０１２９】
このことを保証するためデータベース１２００への複数ユーザのリクエスト間の衝突を検出するためロックマネージャ１２０１が確立される。図１１例中、例えばユーザ１と６との間に衝突が起こる。明らかに、１つのデータベースのマルチユーザ環境の性能が、ロックマネージャ１２０１の性能に関してクリティカルである、それというのは、データベースのアクセス前に各ユーザのリクエストがロック衝突テストに合格しなければならないことに鑑みて、ロックマネージャ１２０１がシステム全体のスループットのボトルネックになり得るからである。本発明によれば、複数のストリングエントリを含めて、データベース１２００をアクセスするいくつかのユーザの複数リクエストの衝突検出、又は衝突マネージメントの方法メソッド、例えば、ロックマネージメントを実行するための方法メソッドは、ユーザのリクエストを含めてダイナミックロックテーブル１２０１のメンテナンスを包含し、前記のダイナミックロックテーブル１２０１では、リクエストは、本発明により、例えばＦＩメソッドによりインデクシングされる。１つのユーザのリクエストに関連して、ロックテーブル１２０２への問い合わせが、ユーザのリクエストがデータベース１２００に伝達される前に、例えば、ＦＩにより、実行される。ロックマネージャ１２０１は、ＦＩインデクシングされるロックテーブル１２０２を維持し、ここにはユーザによりリクエストされるロックが常駐する。
【０１３０】
例えば、ユーザ６のリクエスト“＊＊５＊”は、同じデータセットをアクセスするユーザの５つのリクエスト“ＣＹ５”の故に拒絶される。
【０１３１】
例えば、インデクシング“ＤＸＯ”を有するデータセットへのユーザ１の書込リクエストがある場合、先ず、ＦＩインデクシングされるロックテーブルへの挿入インサートオペレーション動作が実行され、それにより、インデクス“ＤＸＯ”インサートが、ＦＩサーチツリー内に挿入される。インサート動作オペレーションが成功を収めて実行され、インデクス“ＤＸＯ”がサーチツリー中に挿入され得たならば、ユーザ１はデータベース１２００における相応のデータセットへの書込アクセスを実行し得る。ところが、インサートオペレーション動作が、成功しなかった場合、インデクスーストリング“ＤＫＯ”は既にＦＩサーチツリー内にリーフノードとして含まれ、このことはロックマネージャ１２０１により検出される。この場合において、衝突が指示され、データベース１２００における関連するデータセットへのユーザ１の書込アクセスが否認される
データベース１２００への成功を収めた書込アクセスが終了ｆｉｎｉｓｈｅｄされる場合、除去オペレーション動作は、ＦＩロックテーブル１２０２において実行され、これにより、インデクシングされたストリング“ＤＸＯ”を有するリーフツリーが削除される。その後、他のユーザは、データベース１２００における相応のデータセットをアクセスし得る。
【０１３２】
単一の（すなわち、フルに指定された）データベーステーブルエントリ（例えば“ＡＸ３”）に対してのみならず、セット全体である（すなわち部分的パーシャルに指定された）エントリ（例えば、“Ｂ＊＊”ここで“＊”は基礎となるアルファベットの任意の文字であるワイルドカードを表す）に対してもロックを付与し得る。
【０１３３】
データベース１２００へのすべてのリクエスト及びアクセスが単一のＦＩサーチツリー内にマッチングされることに鑑みて、ロックマネージャ１２０１のレスポンス及び性能がデータベース１２００へのアクセスの総合的性能にとって重要である。ロックマネージャ１２０１がインデクシングされたロックテーブル１２０２を維持する場合、短いレスポンスタイム、ひいてはロックマネージャ１２０１の良好な性能が結果的に生じる。この点に関し、例えば、次の特徴事項は有利であり得る；サーチツリーはプレフィックスツリーとして構成され、ローカルハッシュ表が使用され、パーシャルにマッチングされたリクエストが実行され得ること、ＬＩＦＯメモリマネージメントの性能、サーチ期間中の枝刈り（ｐｒｕｎｉｎｇ）及び／又はバックトラッキングの実行である。
【０１３４】
本発明の利点は、ロックテーブル１２０１においてまた、部分的に指定されたストリング（例えば“ａｂ＊ｃ”又は“＊ｂｃ＊”）をも記憶し得ることである。従って、ＦＩロックテーブル１２０２内へのシングルインデクスインサートによりアクセスされるデータセットの部分をマッチングすることが可能である。直線的サーチ及びハッシングのような公知のサーチアルゴリズムにおいて必要なように、当該部分内に含まれる個々のデータセットをマークする必要がない。パーシャルに指定されたインデクスリクエストを実行し得る可能性により、ＦＩサーチの上述の特徴及びそれに基づくサーチメソッドのほかにさらにＦＩロックテーブル１２０２における所要のサーチ時間が低減される。
【０１３５】
他のサーチメソッドとの比較
次に、どのように本発明のアクチュアルなインプリメンテーション、−“ＦＩ”と称されるーが上述の他のサーチメソッドに比較されるかを展望的に示す。表１は、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ Ｐ１８０ ｍａｃｈｉｎｅ 上にて１つの完全な ＩＮＳＥＲＴ/ＦＩＮＤ/ＲＥＭＯＶＥ ｃｙｃｌｅ が実行される時間μｓ（マイクロ秒）を示す。この比較のためＦＩプログラム及び通常使用されるＵＮＩＸスタンダードストリングインデクシング及びサーチライブラリィは実世界データベース上でサイクルを実行した（ここで、エントリはサーチツリーでは均一に分布していない）。ＢＴＲＥＥ サーチは、ＵＮＩＸ/ＸＰＧ４ ｔｓｅａｒｃｈ（３Ｃ） Ｓｔａｎｄａｒｄ ｈａｓｈ ｌｉｂｒａｒｙを用いて実行された。一方 ＬＩＮＥＡＲ ｓｅａｒｃｈ は、直線的２重連結されたリストバスリニアサーチで実行された。
【０１３６】
留意すべきことには高速ストリングメソッドに対する実行時間が、数１０μｓの大きさに留まる。―１００万エントリにわたるサーチの場合でも―。
【０１３７】
また明らかになっていることは、高速ストリングメソッドはサーチすべきキーストリングの大きさに対する優れた性能及びロバストネスを提供する。表２は、種々の長さのキーストリングを含むデータベース上へのＦＩ及びＨＡＳＨがサーチを実行するため時間μｓを示す。高速ストリングメソッドに対する実行時間は、キーストリングが数オーダの大きさ分も一層より大である場合でさえも、たんにわずかしか変化しない。
【０１３８】
本発明及び他のメソッドの特徴の要約を表３に示す。１つのセルにおけるプラス“＋”は、サーチメソッドが指示された特徴に特に適する（又はロバストである）ことを指示する。
【０１３９】
本発明の実施例に適用された本発明の基本的な新規な特徴を示してあり、説明し、指摘してあるが、本発明の精神を逸脱することなく、ここに開示されたような、本発明の形態及び詳細上の種々の省略、過程及び変更がなされ得る。明示されているところによれば、同じ成果を達成するため、実質的に同じ手法で、同じ機能を実行する要素及び／又は方法ステップの一切の組合せは、本発明の範囲内に入る。従って、添付されたクレームの範囲により指示されているものは、そこに指示されたいくつかの限定的な態様に限って規定されているに過ぎない。
【０１４０】
【表１】
【０１４１】
【表２】
【０１４２】
【表３】
【図面の簡単な説明】
【図１】 高速ストリングインデクシングのアプリケーションを具現化するインデクスツリーの基本的データ構造の例を示す概念図である。
【図２】 ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートの図である。
【図２ａ】 ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートの図である。
【図３】 実行されているＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの１事例の第１半部の概念図である。
【図４】 実行されているＩＮＳＥＲＴ Ｏｐｅｎａｔｉｏｎの１事例の第２半部の概念図である。
【図５】 ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【図６】 ＲＥＭＯＶＥ Ｏｐｅｎａｔｉｏｎ の１事例の第１半部に対するフローチャートを表す図である。
【図７】 実行されているＲＥＭＯＶＥ Ｏｐｅｎａｔｉｏｎ の１事例の第２半部に対するフローチャートを表す図である。
【図８】 Ｅｘａｃｔ Ｍａｔｃｈ ＦＩＮＤ ＯｐｅｒａｔｉｏｎのＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【図９】 Ｐａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの有利な実施例に対するフローチャートを表わす図である。
【図９ａ】 Ｐａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの有利な実施例に対するフローチャートを表わす図である。
【図１０】 実行されているＰａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの事例を表す概略図である。
【図１１】 ＦＩ ｉｎｄｅｘｅｄ ｌｏｃｋ ｔａｂｌｅ を使用したロジカルロジックマネージメントを表す概念図である。
【符号の説明】
２ インデクスツリー
４ 根ノード
５ａ リーフノード
５ｂ リーフノード
６ａ キーストリングフィールド
６ｂ キーストリングフィールド
６ｃ キーストリングフィールド
６ｄ キーストリングフィールド
７ａ 情報フィールド
７ｂ 情報フィールド
７ｃ 情報フィールド
７ｄ 情報フィールド
８ 内部ノード
１０ 親ノード
１１ ｐｏｓ フィールド
１２ ｓｕｃｃ フィールド
１３ ｓｕｃｃＦｉｒｓｔ フィールド
１４ ｃｈ フィールド
１５ ｓｂｌＰｒｅｖ フィールド
１６ ｓｂｌＮｅｘｔ フィールド
１７ ローカルサクセッサハッシュ表
１８ ハッシュ表配列
１８ａ ハッシュバケット
１８ｂ ハッシュバケット
１８ｃ ハッシュバケット
１８ｄ ハッシュバケット
１９ ｈａｓｈＮｅｘｔ フィールド
２０ ｐａｒｅｎｔ フィールド
２１ ｐｏｓ フィールド
２２ ｓｕｃｃ フィールド
２４ａ ｃｈ フィールド
２４ｂ ｃｈ フィールド
２４ｃ ｃｈ フィールド
２４ｄ ｃｈ フィールド
２５ ｓｐｌＰｒｅｖ フィールド
２６ ｓｂｌＮｅｘｔ フィールド
２７ キーフィールド
２８ フィールド
２００ フローチャート
２０２ アロケーション
２０４ 参照
２０６ 判定
２０８ レジストレーション
２１０ レジストレーション
２１２ ルックアップ
２１４ アサインメント
２１６ アサインメント
２１８ アサインメント
２２０ 終端
２２２ 比較
２２４ トラバース横断
２３０ 判定
２３２ 判定
２３４ 判定
２４０ 外部ツリー構成
２４２ レジストレーション
２４４ 挿入
２４６ 挿入
２４８ 判定
２６０ 内部ツリー挿入
２６２ アロケーション
２６４ 挿入
２６６ 判定
２６８ レジストレーション
２７０ 挿入
２７２ 挿入
２８０ インクリメント
２８２ セッティング
２８４ リターン
３０２ インデクスツリー
３３１ ｐｏｓフィールド
３４０ ハッシュ表配列
３４１ ハッシュバケット
３５０ 参照
３６０ ブランチ
３７０ リンク
３８０ リンク
４０２ インデクスツリー
４０５ リーフノード
４０８ 内部ノード
４４０ メモリマネージャ
４６０ 参照
５００ フローチャート
５０４ 判定
５０６ セッティング
５０８ 除去
５１０ 除去
５１２ デクリメント
５２０ 判定
５２２ 判定
５２４ アサインメント割当
５２６ 連結、解離
５２８ 挿入
５３０ 除去
５４０ 判定
５４２ 削除
５５０ フリー解放
６０２ インデクスツリー
７０２ インデクスツリー
７１０ リーフノード
７２０ ｈａｓｈＮｅｘｔ フィールド
７５０ 参照
７６０ リンク
８００ フローチャート
８０２ 参照
８０４ 割当
８０６ 考慮
８０８ 検索
８１０ アサインメント
８２０ 比較
８２２ 終端
８２４ リターン
９００ フローチャート
９０４ 判定
９０６ リセット
９０８ リロード
９１０ 判定
９１１ 検索
９１２ 検索
９２０ リーフノード解析
９２２ 比較
９２８ 比較
９３０ 加算
９３１ アサインメント
９３２ 枝刈り（ｐｒｕｎｉｎｇ）
９３３ チェッキング
９３４ 除去
９５０ 内部ノード解析
９５２ アサインメント
９５４ ワイルドカード チェック
９５５ ルックアップ
９７０ プッシュ
１００２ インデクスツリー
１０１２ ノード
１０２０ ノード
１０３０ ノード
１０４０ ノード
１０５０ ノード
１０６０ ノード
１０７０ ノード
１０８０ ノード
１０９０ ノード
１１００ ノード
１１１０ ノード
１１２０ ノード
１２００ データベース
１２０１ ロックマネージャ
１２０２ ロックテーブル
発明の属する技術分野
本発明は一般にデータ保守に、より詳しくはデジタルデータストリングの探索サーチ及びインデクシング法に関する。
【０００２】
背景技術
ここ数１０年コンピュータプログラマ及び科学者が、データベースを保守し、それ等の内容を探索するため新しく、そして、効率的な手法を発見してきている。探索を行うための標準的技術は、リニアな探索、ハッシング及び２進探索ツリーを含む。
【０００３】
リニアな探索技術は、キー、又はストリングを行うための最も基本的な手法である（用語“ストリング”は、アルファニューメリック又は２進キャラクタのグループを記述するため用いられる）。当該の直線的な方法メソッドは、すべての現存のストリングに対してループ動作する。前記のすべての現存のストリングは、通常、アレイ又はリニアなリンク連結リストとして組織化され、各ストリングＫｉをリクエストされるＫと比較する。リニアな探索は、下記の擬似コードにより表現され得る；
【０００４】
そのような探索の実行時間は、Ｏ−記法（Ｎｏｔａｔｉｏｎ）を使用すると（関数ｆ（ｎ）はＯ（ｇ（ｎ）である）― すべてのｎ≧ｎＯ に対して
ｆ（ｎ）≦ｃｏｎｓｔ．ｆａｃｔｏｒ・ｇ（ｎ） が成立つようなｎOが存在する場合）、
Ｔlinear（ｎ）＝Ｏ（ｎ）
こうして、リニア探索の実行時間はストリングの数ｎと共に比例的に増大する。
【０００５】
単純性、簡易性のためリニア探索は、より進んだ探索方法より少ないオーバーヘッドを有する。一般的にいえば、リニア探索は、探索すべきストリングのセットが小である場合、他の探索方法により高速である。従ってインプリメンテーションの容易性及びロバストネスのため、ｎ＜１００である際の小規模探索に対してリニアな探索は優先される。
【０００６】
リニア探索の不都合は、エントリ又はストリングの数ｎへのリニアな依存性である。リニア探索方法は、増大するｎに対して、高性能アプリケーション向けに非現実的になる。１０，０００―エントリテーブルを探索することは、１０―エントリテーブルより１，０００倍遅くなる。
【０００７】
探索に対する他の普及している技術はハッシングである。ハッシングは、リニア探索方法におけるようにすべてのストリングをあまり残さず探索しつくすというよりむしろストリングの２進表示から直接、所定ストリングのアドレス又はロケーションを計算するものである。ハッシング探索は、しばしば２段階ステッププロセスであり、ここで、ハッシング関数Ｈは、リニア探索方法を用いて探索されるストリングの小さいリストを参照するインデックス索引をリターンする。ハッシング探索は、擬似コードで次のアルゴリズムにより表現される。
【０００８】
ｉ＝Ｈ（Ｋ）
ＲＥＴＵＲＮ Ｔ（ｉ）
ここでハッシング関数Ｈは、所定のストリングのインデックス索引、リターンインデックス索引ｉを計算する。インデックスｉはマッチングストリングのみに関与ないし参照し得、又はストリングの１つのリストをレファレンス参照し得、該ストリングのリストは次いでマッチングストリングに対してリニアに探索されねばならない。
【０００９】
通常使用されるハッシング関数Ｈは下記の式を用いてハッシュ表Ｔ内へのストリングの編成組織化又はインデクシングを行う：
Ｈ（Ｋ）＝（キーストリングＫの総バイトｂ1，…，ｂm（ＡＳＣＩＩコード）の和）ｍｏｄｕｌｏ Ｍ
ここでＭはハッシュ表Ｔのサイズを表す。明らかにハッシュ関数Ｈは、一般に、各ストリングに対して固有―意であることが保証され得ない。２以上のストリングにより、同じハッシュ関数が生じる場合には、（異なるストリングＫi≠Ｋjに関して（Ｈ（Ｋi）＝Ｈ（Ｋj）が生じる場合には）衝突ケースの発生と称される。衝突ケースに対処する最も普通の手法は、リクエストされたエントリを見出すべく通常リニア探索方法により、衝突リストの探索を要する各々のハッシュ表エントリに対して同一のハッシュ値を有するストリングのリストを維持保持することである。
【００１０】
一般にハッシングの実行時間は、衝突リストの平均長さに依存し、前記の衝突リストの平均長さは、ハッシュ関数Ｈの分布のみならず、ハッシュ表サイズＭにも依存する。ハッシュ関数Ｈがほぼ完全な分布（すなわち、任意のキーストリングＫがインデックスｉ＝Ｈ（Ｋ）へ分散、分布される確率がすべてのｉ＝１…Ｍに対して等しい起こり易さである）を有するものと仮定すると、ハッシングの平均実行時間は次のようになる。
【００１１】
Ｔhash（ｎ）＝Ｏ（ｎ／Ｍ）
その結果は、十分大きなハッシュ表サイズＭ＞ｎ、に対してほぼ一定である実行時間である。
【００１２】
従って、理論上、実行時間は、ほぼｎに無関係であると期待され得る。ここでは完全なハッシュ関数（大多数の実世界アプリケーションにおける非現実的な期待）を使用し得るならばの条件付きである。
【００１３】
ハッシングの欠点は、衝突のケースを分解する固有の必要性により、付加的で、時には長たらしい検索の行われることが要求される。ハッシング技術を利用する平均探索が迅速であるが、探索を完結する実際の時間長さは、所定のストリング分布に対して最も一層より悪くなり得る。最悪のケースでは、すべてのストリングが、同じインデックスにて終わることが起こり得て、探索の総合的性能が、リニアな探索の場合より良好なものとならない。従って実際上、実時間世界アプリケーションに対して効率的なハッシュ関数を見出すことは、困難なタスクであり、インデクシングすべきストリングの実際の確率分布に著しく依存する。
【００１４】
ハッシングのもう１つの欠点は、ワイルドカード探索に役立たないことである。ワイルドカード探索は、そこにて探索ストリングにおける１つ以上のキャラクタがワイルドカードキャラクタであるようなものである（すなわち、他の任意のキャラクタにとって代わり得るキャラクタである）。ワイルドカード探索は、しばしば多重マッチングストリングをリターンする。
【００１５】
探索の他の方法は探索ツリー方法である。その種探索が実行される前に、その上にて探索を実行すべきデータを編成組織化するために探索ツリーを生成しなければならない。探索ツリーインプリメンテーションの種々のものが提案されており、その中で最も基本的なものは、２進探索ツリーであり、この２進探索ツリーは、次のように規定される。
【００１６】
（ツリー節点ノードにより表される）ストリングの１セットＫ1，…，Ｋnにわたる（２進）ツリーＴは、次の条件が成立つ場合、探索ツリーと称される、すなわち、いずれのサブ節点ノードＴに対しても、そして、Ｔの左のサブツリーにおけるいずれの下降するノードＴ1に対しても、また、右のサブツリーにおけるいずれのＴrに対しても、下記が成立つ場合；
ｖａｌｕｅ（Ｔ1）＜ｖａｌｕｅ（Ｔr）、ここで ｖａｌｕｅ（Ｔ）は、ツリー節点ノードＴに関連するストリング値であって、探索ツリーと称される。
【００１７】
こうして基本的な探索手続きを（再帰的に）擬似コードで次のように定式化できる（通常のように、Ｋは探索されているストリングを表し、そして、非存在のキーのような特別な場合は、簡単化のため省略し得る）：
【００１８】
Ｔtree＝Ｏ（ｌｏｇ2ｎ）
こうして，理論上、平均実行時間は、エントリ、又はストリングの数と共に対数的に増大する。このことは、多数のエントリに亘って探索する場合、リニア探索に対しての実質的改善を成す。
【００１９】
探索ツリー方法の１つの欠点は、フィールド条件下で、実行時間は大いに変化し得る、それというのは実際上、探索ツリーはめったにバランスされないからである。ツリーのバランシング特性は、著しく、実際のストリング分布に依存する。前記問題を最小化するため、下記刊行物に記載されている、ＡＶＵ ツリー（tree）のような複雑な方法が案出されている、すなわち、
Van Wyk， Christopher J., 著述 Data Structures and C. Programms， Addison-wesley Publishing， １９８８年。
【００２０】
しかしながら、そのような方法は、またツリー構造管理のためインプリメンテーション上のオーバーヘッドを増大させる傾向を呈する。実際上、アクチュアルのインプリメンテーションに依存して、ツリーをベースとする探索は、簡単なリニア探作を凌駕することはないーエントリの数が幾１００のブレークイーブンポントを越えないならば。
【００２１】
本発明は、ジュエネリックインデクシング及びパーシャルマッチ問い合わせを支援するアルファニューメリック又は２進ストリングの高速インデクシング及び検索取出のための方法を提供することにより前述の問題を克服する。本発明は特有一義的コンパクトツリーを利用し、ここで、１つの節点ノードが、１つの探索ストリングにて複数のキャラクタをステップ的に走査するため使用され得、そして、基礎となるストリングアルファベット内に存在するキャラクタ（例えば８ビットーベースーキャラクタに対して２５６）と同じ数の後継者サクセッサー節点ノードを有し得る。更にワイルドカード探索中可能な多重マッチングストリングのため複数のサブツリーないしツリーを探索する必要がある場合、本発明はバックトラッキングを使用する。また、本発明はヒューリスティックサブツリー枝刈り（ｐｒｕｎｉｎｇ）すなわち、それによりパーシャルマッチ探索をサブツリー全体の破棄により加速し得る方法を利用する。
【００２２】
本発明は、ストリングを使用したケースに主に適用されるが、そのような探索はデータベース中に記憶されている任意のデジタル情報を探索するため使用し得る。
【００２３】
発明の要約
本発明は、ストリングの形態で記憶されている高速探索及びインデクシング法に関する。この発明は所定の問い合わせストリングにマッチングするようデータベースを迅速に探索するための手段を提供する。開示された実施例では探索方法メソッドは、図解のためアルファニューメリックストリングに関連付けて利用される。
【００２４】
本発明の目的とするところは、所定のアプリケーションに対していずれの公知の方法よりも高速の、ストリング探索方法を提供することにある。
【００２５】
本発明の目的とするところは、大抵のアプリケーションに対してリニア探索ハッシュ探索、又は２進ツリー探索より高速のストリング探索方法を提供することである。
【００２６】
本発明の他の目的とするところはキャラクタレベルでのワイルドカードのようなパーシャルマッチングをサポートするストリング探索方法を提供することにある。
【００２７】
本発明の他の目的とするところは、インデックス内でパーシャル部分的に指定されたストリングのジェネリック記憶を含めたジェネリックインデキシングをサポートするストリング探索のための方法を提供することにある。
【００２８】
本発明の他の目的とするところは、大きなストリングサイズに特に効率的なストリング探索方法を提供することにある。
【００２９】
本発明の他の目的とするところは、不均一に分布されたストリング分布に対してロバストネスを有するストリング探索方法を提供することにある。
【００３０】
本発明の他の目的とするところは、２進ツリー又はハッシング衝突リストにて生じる際限のない縮退を防止するストリング探索方法を提供することにある。
【００３１】
本発明の他の目的とするところは、内部ツリー構造管理オーバーヘッドを最小化するストリング探索方法を提供することにある。従って、１００エントリより少ないエントリを有するテーブルに対しても、開示されたインプリメンテーションは、しばしばリニア探索より高速になる。
【００３２】
本発明の他の目的とするところはロジカルロックマネージメント（ｌｏｃｋ ｍａｎａｇｅｍｅｎｔ）の改善された方法を提供することにある。
【００３３】
本発明によれば、複数のストリングエントリをインデクシング方法が提案され、ここで、前記の複数のストリングエントリの各１つが複数キャラクタの１つのストリングである。本発明によれば探索ツリーを使用することにより複数のストリングエントリのインデクシングを行う方法であって、前記の複数のストリングエントリのうちの各１つが複数キャラクタの１つのストリングであるようにした当該のインデクシング方法において、前記探索ツリーは、連結リンクされた節点を有し、前記の連結された節点ノードは、１つの根節点及び複数の内部節点ノード並びに複数のリーフ節点ノードを有し、前記の内部節点ノードは、１つのキャラクタ又はキャラクタのサブストリングに関連付けられており、また前記のリーフ節点ノードは、前記の複数のストリングエントリに関連付けられており、ここで、前記の複数の内部節点ノードの各々は、更に、下記の要素（ａ）〜（ｅ）を有し、すなわち
（ａ） 親節点に対する参照を有し、ここで前記親節点ノードは、前記複数の内部ツリー節点ノードのうちの他の１つのもの又は、前記根節点ノードであり、
（ｂ） キャラクタ比較位置を含む第１データフィールドを有し、前記キャラクタ比較位置は、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタの数を指示するものであり、
（ｃ） 比較キャラクタを含む第２データフィールドを有し、前記比較キャラクタは、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタが、前記キャラクタ比較位置に関連する前記ストリングエントリの１つのキャラクタ位置にて１つのストリングエントリ内に含まれているか否かを決定するため使用され、
（ｄ） 可変的な個数の少なくとも２つの後継者ノードへの参照を有し、
（ｅ） ツリーのトラバース走査の間に後継者ノードの中の高速ハッシュ探索を可能にするための相応の親節点ノードの後継者ノードへの参照を有するハッシュ表アレイを有し、さらに所定数のハッシュバケットを有し、
キャラクタのストリングは、アルファニューメトリックキャラクタの１つのストリングであり、複数のエントリのうちの少なくとも１つが１つのワイルドカードキャラクタを有し、このワイルドカードキャラクタはキャラクタのストリングの任意の可変的な位置に又は複数のストリングエントリのうちの少なくとも１つの任意の可変的な位置に位置決めされる。
【００３４】
又、本発明によれば複数のストリングの中から、複数のキャラクタから成る所定のストリングを探索する方法であって、前記複数ストリングの各々が複数キャラクタの１つのストリングであるようにした当該の探索方法において、前記方法は、下記ステップを有する、すなわち、
請求項１から８までのうちいずれか１項の方法により探索ツリーを生成するステップを有し、ここで、前記の複数のストリングは複数のストリングエントリを形成するものであり、
前記の所定のストリングに関連する問い合わせを形成するステップ
前記の問い合わせを利用して前記探索ツリーをトラバース走査して前記の所定のストリングにマッチングする前記複数ストリングの任意のものに１つのインデックス索引を与えるステップを有するのである。
【００３５】
本発明による所定のストリングを探索する方法を次の事項に関連して使用すれば特に有利である、すなわち、ヒューマンリソースマネージメント、ファイナンシャルズ、ビジネスワークフロー、人事マネージメント、ペイロールアカウンティング、タイムマネージメント、人事開発又はネットワーク、例えば、インターネット又はイントラネット、システムに関連して使用すれば特に有利である。そのようなシステムは、特にドイツ連邦共和国のＳＡＰ、ＷａｌｌｄｏｉｆからのＲ／３システムであり得る。
【００３６】
本発明のいくつかの基本的側面及び有利な実施例は、次のようなものである。
【００３７】
高速のストリングインデクシング方法は、効率的に、コンパクトな探索ツリーを利用して、アルファニューメリック又は２進ツリーを記憶し、探索し、そして除去する。探索ツリーにおけるレベルの数は、可能であれば、１つより多くのキャラクタを表す１つの節点ノードにより最小化される。ツリーの各内部節点ノードは、順次ハッシングに対するハッシュ表アレイを有し、このハッシュ表アレイはまた、１つの所定の節点ノードをトラバースするのに必要とされる時間を最小化する。キャラクタレベルにおけるワイルドカードのようなパーシャルマッチングのため探索を実行し得る。ストリングエントリの同じテーブル上にて、独立的に、且つ、同時に多重のインデクスをオープンし得る。
【００３８】
本発明及び実施例は以下の図を参照しながら説明される。
【００３９】
図の簡単な説明
図１は高速ストリングインデクシングのアプリケーションを具現化するインデクスツリーの基本的データ構造の例を示す概念図である。
【００４０】
図２及び図２ａは、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートの図である。
【００４１】
図３は、実行されているＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの１事例の第１半部の概念図である。
【００４２】
図４は、実行されているＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの１事例の第２半部の概念図である。
【００４３】
図５は、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【００４４】
図６は、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の１事例の第１半部に対するフローチャートを表す図である。
【００４５】
図７は、実行されているＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の１事例の第２半部に対するフローチャートを表す図である。
【００４６】
図８は、Ｅｘａｃｔ Ｍａｔｃｈ ＦＩＮＤ ＯｐｅｒａｔｉｏｎのＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【００４７】
図９及び図９ａは、 Ｐａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの有利な実施例に対するフローチャートを表わす図である。
【００４８】
図１０は、実行されているＰａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの事例を表す概略図である。
【００４９】
図１１は、ＦＩ ｉｎｄｅｘｅｄ ｌｏｃｋ ｔａｂｌｅ を使用したロジカルロックマネージメントを表わす概念図である。
【００５０】
発明の詳細な説明
本発明は探索を行いデータベースを保持するための改善された方法を開発したものである。本発明は、従来の探索及びインデクシングに比して多くの利点を有する。そのうちの１つは、スピードであり、優れたスピードは主に、３つのファクタに帰せられ得る。エントリ又はキーストリングの数に対するロバストネス、キーストリング分布に対するロバストネス及びキーストリング長さに対するロバストネス。それ等のすべての３つのファクタを以下に詳細に説明する。
【００５１】
Ｋ1＝ｂ11・・1m，Ｋ2＝ｂ21・・2m，・ Ｋn＝ｂn1・・nm により表されるランダムのｍ―キャラクタキーストリングｎ個の１セットをインデクシングするものとする。
【００５２】
図解目的のため、各キャラクタが８ビットバイトとしてコード化されている通常のケースを仮定し、各キーストリングの長さが２５６バイト（ｍ＝２５６）であると仮定する。
【００５３】
キーストリングの数に対するロバストネスは、ストリングの数ｎが増大するに従って、ＩＮＳＥＲＴ， ＲＥＭＯＶＥ,及びＦＩＮＤの基本動作ｏｐｅｒａｔｉｏｎｓの平均実行時間が固有的に増大するのを制限することに関連する。
【００５４】
本発明において、開示された高速ストリング方法（好適実施例中では“ＦＩ”と称される）は、インデクスツリーをトップからボトムへトラバース走査し（それの構造は、次のことを除いて２進ツリーのそれと類似している、すなわち、内部ノードがそこから直接下降している、単に２というよりむしろ多重のサブツリーを有し得ることを除いて類似する一方、同時に左から右へ探索ストリングをステップ的に走査して進む。探索ツリーの最後のキャラクタに到達すると、プロセスはマッチングを指示する探索ツリーのリーフ節点ノードに到達しているか、又は探索ストリングが現在インデクス中に存在していないことを検出している。こうして、ツリー節点ノード検査の平均総数は、インデクスツリーの平均深さと等しいか、それより小でなければならない。
【００５５】
本発明に関連して利用される探索ツリーの平均深さは次のように計算し得る。探索ツリーの平均ブランチングファクタＫは、任意の内部節点ノードから発する子孫下降サブツリーの平均数として定義付けられ得る。従って、Ｋは、基礎となるアルファベットにおける基礎となるキャラクタの数と等しいか、又はそれより小である（例えば、８ビットに対して２５６）。しかしながら、実際上、平均ブランチングファクタは、当該の数より著しく小である、それというのは、キーストリングの実世界分布は、通常均一分布とは程遠いものであるからである。ランダムな実世界データの大きなセットを用いての実験結果の示すところによれば、リズナブルなブランチングファクタは、４〜９ビットの基礎となるアルファベット及び１６〜５１２のキャラクタのストリング長さに対して Ｋ＝３…７のレインジ内にある。
【００５６】
内部節点ノードの数はツリーＴの各後続レベルに対してＫのファクタだけ増大するので、最終レベルでの（キーストリングの総数に等しい）リーフ節点ノードｎの総数は、次のように表され得る。
【００５７】
ｎ＝ｋdepth(T) 又は ｄｅｐｔｈ（Ｔ）＝ｌｏｇKｎ
更にＦＩ ｏｐｅｒａｔｉｏｎｓ ＩＮＳＥＲＴ， ＲＥＭＯＶＥ 及び Ｆ ＩＮＤ の平均実行時間がツリーの深さに等価であるので次のように表され得る。
【００５８】
ＴFI（ｎ）＝Ｏ（ｌｏｇKｎ）そして実行時間は、エントリの数の増大と共に対数的にのみ増大する。例えば、Ｋ＝４の場合、キーストリングエントリの数の４倍になるごとに、平均してそれらの考慮されるべき動作ｏｐｅｒａｔｉｏｎｓ に対して唯もう１つのレベルが加えられるだけである。
【００５９】
キーストリング分布に対するロバストネスは、エントリの所定のセットに対して探索時間の分散偏差を制限することに関連する。換言すれば、１つの任意の所定のエントリに対する探索は、理想的には他の任意のエントリごとに最悪のケースに関してーに対する探索と同じ時間量を取るべきである（すなわち、最悪のケースは平均ケースより遙かに多くの時間をとるべきではない）。しかしながらキーストリングの実世界分布に基づき、１つの２進ツリーがインデクスツリーのトップの近傍でいくつかのリーフ節点ノード及び極度の深さのところで他のリーフ節点ノードを有し得る。最悪のケースにて、２進ツリーは、そこにて、いくつかのエントリに対する探索がリニアリスト探索と同じ時間のかかるポイントへ縮退し得る。ＡＶＬツリーは、２進ツリーより幾らか良好に分布されるが、アルゴリズムのデータ構造を維持するのに劇的に増大する管理オーバーヘッドを代償にして行われるものであり、これにより、総合的な性能が悪化する。ハッシングアルゴリズムはまた、エントリのバランスされていない分布をも来し得る。理想的には、エントリはハッシングテーブルを横切って均一に分布され、そして、衝突リストは、多かれ少なかれ均一の長さである。実際上、或衝突リストは、他のものより長い。最悪のケースでは、すべてのエントリが、同じハッシュスロットにマッピングされ、１つのハッシュ探索は、１つのリニアリスト探索に等価なものとなる。
【００６０】
ＦＩインデクスツリーが概して完全にバランスされたツリーではないけれども、最大縮退の度合いが制限される。それというのは、少なくとも１つのストリングキャラクタが、ツリーを降下する各下降ステップに対して探索ストリングにて、トラバースされるからである。こうして、ツリーＴの総合深さは、キーストリング長さｍにより制限され、このキーストリング長さは、通常エントリｎの総数より対数的に小さい数である。
【００６１】
キーストリング長さに対するロバストネスは、個別のエントリの平均長さｍへの探索時間の依存性を制限することに関連する。このことは、ロジカルロックマネージメント（ｌｏｃｋ ｍａｎａｇｅｍｅｎｔ）のようなアプリケーションにおいては重要な配慮事項であり、ここでは各キーストリングが、全データベーステーブルラインに相応し得る。それ等のアプリケーションでは、数１０００ではなくとも数１００のキャラクタの長さであるキーストリングをインデクシングし探索することが重要であり得る。従来の探索方法を用いる場合、大きなキーストリング長さは、しばしば、各探索ステップに対して長ったらしいキャラクタごとの比較を必要とする。
【００６２】
ＦＩは、各探索ステップが探索ストリングにて多重キャラクタをカバーし得るようにして、キーストリングをインデクシングし得る能力を有する。実際のストリング長さに無関係に、各探索ごとに唯一の単一のキャラクタ検査しか必要でない。ＦＩインデクスツリーＴの深さが通常ストリング長さｍより遙かに小さいので、ストリングの大部分を、検査する必要がなく、探索プロセス中スキップし得る実験の結果により確認されたところによれば、大抵の実世界アプリケーションにて、ＦＩ性能がキーストリング長さと共に大して変わらない。ＦＩは、誤ったリターンの無いことを検証するのに、探索ストリング及びリーフ節点ノード（又はワイルド探索の場合における節点ノード）の１つのファイナル比較をしさえすればよい。
【００６３】
図示の実施例
ＦＩインデクシングツリー２の有利な実施例の基本構造例が図１に示してある。
【００６４】
当該の図解においてツリーに関連するデータベースは次のよなストリングエントリを有する。“ａｂｃｄ”，“ｃｄａｆ”，“ｃｄｄｈ”，及び“ｇｆｂｅ”．
簡単のため、及び図解目的のためだけにそれのキーストリングに対する基礎となるアルファベットは８つのキャラクタ（３ビット）を有する。注目すべきことには、比較的に小又は大のアルファベット（例えば８ビットに基づく）が大抵のアプリケーションにとって有用である。
【００６５】
インデクスツリー２のトップには根節点ルートノード４が位置付けられ、このルートノード４は、インデクスツリーの初期設定の際生成される第１ノードである。リーフノード５ａ，５ｂ，５ｃ，及び５ｄは、キーストリングフィールド６ａ，６ｂ，６ｃそして６ｄ並びに情報フィールド７ａ，７ｂ，７ｃ，７ｄに関連付けられ、それらのキーストリングフィールドは、インデクシングされるキーストリングを含み、前記情報フィールドは、ユーザがインデクシングされるキーストリングと関連付けたい任意の付加データを含む。注目すべきことには、ユーザは、複数情報フィールドを１つの所定のキーストリングと関連付けたいと願う。例えばキーストリングは、従業員識別番号であり得、別個の情報フィールドは、従業員氏名、アドレス、電話番号等であり得る。
【００６６】
２進ツリーにおけるように、内部節点ノードが存在し、それ等の内部ノード節点ノードは、所定のキーストリング又はユーザ提供の情報に関連付けられているのではなく、比較に関連付けられており、この比較は、所望のリーフノードへ向かっての方向、指示を与えるものである。図１には唯一の内部ノード節点８が示されているが、コンピュータプログラミングの当業者にとって、明らかなようにインデクスツリーがしばしば多数の内部ノードを有する。
【００６７】
内部ノード節点は、いくつかのデータフィールドを含む。親フィールド１０は当該節点の親ノード、ルート、根ノード４を参照する。Ｐｏｓ ｆｉｅｌｄ １１は、キャラクタ比較位置（ｐｏｓ）と称されるものについての情報を含む。このフィールドは各内部ノード節点に対して次の条件が充足されるように維持される、すなわち、第１のｐｏｓキャラクタ（すなわち、長さｐｏｓのサブストリング）は、その節点ノードから発するサブツリー内に含まれているリース節点ノードに関連するすべてのキーストリングに対して、同一であるとの条件が充足されるように維持される。キャラクタ比較位置が指示しているところによれば、キャラクタ比較が、共通のサブストリングにつづく後続の節点ノードにて行われるべきであるということである。キャラクタ比較位置は、同一のキャラクタシーケンスをスキップすることにより、インデクスツリーに亘って探索プロセスを加速するため使用される。Ｆ１ツリーの性質によれば、１つの所定のサブツリーのリーフ節点ノードに含まれているすべてのストリングが同じプレフィックスを有する。例えば、リーフ節点ノード５ｂ、５ｄは内部節点ノード８と共に１つのサブツリーを構成し、それぞれキーストリング“ｃｄａｆ”及び“ｃｄｄｈ”に関連付けられる。それ等の２つのサブストリングは、プレフィックス“ｃｄ”を共用する。この例では、内部節点ノード８のｐｏｓフィールドはキャラクタキャラクタ比較位置数２を含むこととなる、というのは、これは、内部節点ノード８から発するサブストリングに含まれるすべてのストリングの長さであるからである。当該のキャラクタ比較位置に関連するキャラクタは、第３キャラクタであり、この第３キャラクタは、２つのサブストリングが共通に有しない第１のキャラクタである。
【００６８】
Ｓｕｃｃフィールド１２は、後継者節点ノードの現在、瞬時番号のトラックをキープする。事例では、内部節点ノード８は、２つの後継者リニア８ｂ及びリーフ節点ノード５ｃを有する。ＳｕｃｃＦｉｒｓｔフィールド１３は、すべての後継者ノード節点ノードの２重にリンクされたＮＵＬＬ−終端されたリスト（時により、サイブリングリストと称される）の第１のノードに対する参照である。事例中内部ノード８のＳｕｃｃＦｉｒｓｔフィールド１３は、リーフ節点ノード５ｂを参照する。ＳｕｃｃＦｉｒｓｔフィールド１３は、他のものの中で、ＲＥＭＯＶＥ機能のために用いられ、これについては以下説明する。
【００６９】
ＣＨフィールド１４は節点ノードの比較キャラクタを有する。比較キャラクタは、或１つの節点ノードをサイブリングノードから区別、識別する第１のキャラクタである（これは他の点では同じストリングを共有する）。
【００７０】
ＳｂｌＰｒｅｖ フィールド１５は、サイブリングリストの先行（左隣）の節点ノードへの参照リンクである。サイブリングリストの先行節点ノードがない場合、（リファレンス）リンクは、ＮＵＬＬ（零）リファレンスである。同様に、ｓｂｔＮｅｘｔフィールド１６は、サイブリングリストの次の（右隣）ノードへのサイブリングリストの次の節点ノードがない場合、参照リンクは、零参照である。事例では、内部節点ノードへの参照リンクであり、内部節点ノード８のフィールド１６は、リーフ節点ノード５ｄへの参照リンクである。
【００７１】
ローカル後継者ハッシュ表１７は、追従すべき適正な後継者ブランチの探索及び識別に使用される（すなわち、所定の探索中進行すべきツリーを更に１レベル下る）。ローカル後継者ハッシュ表１７は、ハッシュ表アレイ１８及びフィールド１９からなる。ハッシュ表アレイ１８は、キャラクタ値を表すハッシュバケットの固定数を含む。事例では基礎を成すキーストリングを構成する８つのキャラクタが４つのハッシュバケット１８ａ、１８ｂ，１８ｃ及び１８ｄを横切って均一に分布している。上述のように内部ノード８から発するサブツリーのリファレンス節点ノードに含まれるすべてのキーストリングが同じスタートｐｏｓキャラクタを有するので、これは、事例中２つのキャラクタ“ｃｄ”となる、それ等のｐｏｓストリングに対する後続のキャラクタ、これもまたキャラクタ比較位置キャラクタ、すなわち、それぞれ“ａ”及び“ｄ”はハッシュバケット内に置かれる。事例中キャラクタ“ａ”及び“ｅ”は、ハッシュバケット１８ａ割り当てられており、“ｂ”及び“ｆ”はハッシュバケット１８ｂに、そして、“ｃ”及び“ｇ”は、ハッシュバケット１８ｃに、そして、“ｄ”及び“ｈ２は、ハッシュバケット１８ｄに割り当てられている。こうしてハッシュバケット１８ａは、リーフ節点ノード５ｂへの参照リンクを有し、ハッシュバケット１８ｄは、リーフ節点ノード５ｃへの参照を有する。
【００７２】
ＨａｓｈＮｅｘｔフィールド１９は、ハッシュ衝突リストに対する参照リンクとして用いられる。事例中“ｃ”及び“ｇ”もまた、ルート根節点ノード４のハッシュ表アレイ中に同じハッシュバケットを有するので、そして１つの有利な実施例では各ハッシュバケットが唯一の他のノード節点にのみ参照を有し得るので、後継者ノード節点、ルート根節点ノード―それの比較キャラクタが“ｃ”であるーがそれの比較キャラクタが“ｇ”であるサイブリング節点ノードを参照することが必要である。こうして、内部ノード８のｈａｓｈＮｅｘｔフィールド１９は、リーフ節点ノード５ｄへの参照リンクを有する。
【００７３】
１つのリーフ節点ノードは、リーフ節点ノードであり得、（インデクスツリーが唯一のエントリからなる場合）、又は１つの内部ノードであり得る。事例中リーフ節点ノード４は、１つの内部節点ノードである。こうして、ルート根節点ノード４は、内部節点ノード８と同じフィールドを有しない（こうしてルート根節点ノード４の親フィールドは零ポイント（ＮＵＬＬ ｐｏｉｎｔｅｒ）リーフ節点ノード５ａ，５ｂ，５ｃを有する）。及び５ｄもまた、いくつかのデータフィールドを含む。図１に関連して述べると、リーフ節点ノード５ｂは、典型的リーフ節点ノードの１例として挙げられている。リーフ節点ノード５ｂの親フィールド２０，ｃｈフィールド２４ｂ、ｓｂｌｐｒｅｖフィールド２５，及びｓｂｌＮｅｘｔフィールド２６は、内部ノード８の親フィールド１０，ｃｈフィールド１４，ｓｂｌｐｒｅｖフィールド１５，及びｓｂｌＮｅｘｔフィールド１６に類似する。Ｐｏｓフィールド２１は、それを１つのリーフ節点ノードとして識別するため“無限”“ｉｎｆｉｎｉｔｅ”、１つの特別な値にセットされる。ｓｕｃｃフィールドの内部は不確実である。リーフ節点ノードは後継者を有しないからである。キーフィールド２７は、キーストリングフィールド６ｂを参照し、一方ｉｎｆｏフィールド２８は、情報フィールド７ｂを参照する。
【００７４】
事例中明らかになることは、キーストリング“ａｂｃｄ”キャラクタ“ａ”でスタートする唯一のキーストリングは、リーフ節点ノード５ａに関連付けられ、ｃｈフィールド２４ａは、キャラクタ“ａ”を含む。同様７に、キーストリングキャラクタ“ｇ”でスタートする唯一のキーストリングは、リーフ節点ノード５６ｄに関連付けられ、該リーフ節点ノードのｃｈフィールド２４ｄはキャラクタ“ｇ”を含む。キャラクタ“ｃ”でスタートする複数のキーストリング、すなわち、“ｃｄａｆ”及び“ｃｄｄｈ”）、があるので、それ等のキーストリングに関連するリーフ節点ノードはルート根節点ノード４の後継者になり得る。むしろ、内部節点ノード８は、キャラクタ“ｃ”をもってスタートするキーストリング（これはフィールド１４内に記憶されているキャラクタである）が共有していない第１のキャラクタは、どのハッシュバケットが適用可能であるかを決めるために使用される。第３のキャラクタが“ａ”である場合、リーフ節点ノード５ｂに参照が成される。他方、第３のキャラクタが“ｄ”である場合、参照は、リーフ節点ノード５ｃになされる。
【００７５】
初期設定
ライブラリィは初期設定プロセスを介してユーザにより供給されるメモリエリア内に初期設定される。初期設定が完了完結すると、初期設定されたＦＩインデクスに対するハンドルがリターンされる。ユーザは、供給されたメモリバッファを参照すべくアイキャッチャ（ｅｙｅｃａｔｃｈｅｒ）として知られている識別子ストリングを規定し得る。このことにより、マルチプロセスアプリケーションにおける１度での初期設定が保証され、ここでバッファは、通常共通メモリ内に常駐する。次の入力及び出力パラメータは、クリエイト動作に置いて使用され、この動作は、初期設定の有利な実施例態様である。
【００７６】
入力パラメータは、＜ｂｕｆｆｅｒ＞、＜ｉｄｅｎｔ＞、＜ｍａｘＩｎｄｅｘ＞、＜ｍａｘＫｅｙｓ＞、＜ｍａｘＫｅｙＬｅｎ＞、及び＜ｗｉｌｄｃａｒｄＣｎ＞を含む。＜ｂｕｆｆｅｒ＞パラメータは、ＦＩ管理のためにユーザにより供給される順次メモリエリアである。＜ｂｕｆｆｅｒ＞はまた、マルチプロセスアプリケーションに対する共有のメモリアドレスであり得る。＜ｉｄｅｎｔ＞パラメータはＦＩインスタンスを特有―意的に識別するアイキャッチャ（ｅｙｅｃａｔｃｈｅｒ＞であり、マルチスレッドアプリケーションにおける多重初期設定を阻止するため使用される。＜ｍａｘＩｎｄｅｘ＞パラメータは、独立にハンドルし得る個別インデックスの最大数を与える。＜ｍａｘＫｅｙｓ＞パラメータは、インデックスにエントリ（キーストリング）の最大数を与え、すべての個別のインデックスの非繰り返し和である。＜ｍａｘＫｅｙＬｅｎ＞パラメータは、すべてのインデックスにおいて、キーストリングに対して、バイトで、最大キーストリング長さを与える。＜ｗｉｌｄｃａｒｄＣｈ＞パラメータは、パーシャルマッチング探索に対するワイルドカードとして使用されるキャラクタを含む。
【００７７】
出力パラメータ＜ｈａｎｄｌｌｅ＞は、新たにクリエイト（生成）されるＦＩインスタンスであり、後続のＦＩライブラリィコールに対するハンドル（参照）として使用される。
【００７８】
初期設定プロセスは、いくつかの目的を達成する。１つの目的は、メモリにおけるＦＩ管理構造を初期設定することである。もう１つの目的は任意の多重の初期設定を検出ためアイキャッチャを提供することである（マルチプロセス及び／又は、マルチスレッド環境における一度での初期設定を確保するため）。また、初期設定プロセスは、固定サイズの高速ＬＩＦＯ（ｌａｓｔｉｎ、 ｆｉｒｓｔ ｏｕｔ）に基づくメモリマネージメントを初期化し、実質的に一定時間でインデクスツリーノード割当てをアロケートし、フリー解放するものである。更に、内部ノードスタックが初期設定され、その結果パーシャルマッチング問い合わせにてインデクスツリーを再帰的にサーチする際ハッシュフラグポイントを記憶し得る。
【００７９】
インデクスオブジェクトのオープニング
多重インデクスは同時にデータの同じセット上にオープンされ得、この同じセットにより、インデックスが同時に使用され得る。ＯＰＥＮ Ｏｐｅｒａｔｉｏｎは、ＣＲＥＡＴＥ Ｏｐｅｒａｔｉｏｎ により先に初期設定されたグローバルなＦＩインスタンス内に１つの新たな空のインデクスオブジェクトをクリエイト生成する。次の入力及び出力パラメータは、ＯＰＥＮ Ｏｐｅｒａｔｉｏｎ の有利な実施例において使用される。
【００８０】
入力パラメータは＜ｆｉＨｄ＞、＜ＩｄｘＩｄ＞、及び＜ｍａｘＫｅｙＬｅｎ＞を含む。＜ｆｉＨｄ＞ ｐａｒａｍｅｔｅｒは、グローバルｆｉインスタンス（ＣＲＥＡＴＥ Ｏｐｅｒａｔｉｏｎによりターンされる）。＜ＩｄｘＩｄ＞は、オープンされつつあるインデクスを特有一義的に識別するアイキャッチャであり、メモリを共有するマルチプロセスアプリケーションにおける多重初期設定を阻止するために使用される。＜ｍａｘＫｅｙＬｅｎ＞パラメータは、インデクス中に置かれるべきキーストリングに対してバイトにて、最大のキーストリングを与えるものであり、ＣＲＥＡＴＥ ｏｐｅｒａｔｉｏｎにおける＜ｍａｘＫｅｙＬｅｎ＞の値に等しいか、又はそれにより小である。
【００８１】
出力パラメータ＜ｈａｎｄｌｅ＞は、新たにクリエイト生成されるインデクスオブジェクトに対する参照であり、後続のインデクス動作に対するハンドル処理である。
【００８２】
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎは、指定されたキーストリングを指定されたインデクスオブジェクト中に挿入する。前述のように、ユーザにより供給されるデータは、インデクスにおける各キーストリングに関連付けられる。
【００８３】
１つのキーストリングが１つのインデクス中に挿入される度ごとに、１つの新たなＦＩキーオブジェクト（すなわちインデクスツリーのリーフ）が内部的に生成され、そして、キーに対するハンドルがコールする者、コーラー（ｃａｌｌｅｒ）にリターンされる。該ハンドルは、インデクスツリー内でキーエントリを参照するため使用され得る（例えば ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎのため）。キーストリング自体は、インデクスメモリ内に記憶されない。むしろ、ＦＩは、ユーザにより供給される参照を介してストリングを参照する。
【００８４】
有利な実施例では、挿入すべきストリングはＯＰＥＮ Ｏｐｅｒａｔｉｏｎにより指定された少なくとも＜ｍａｘＫｅｙＬｅｎ＞の長さを有し、ストリング終端キャラクタを有しない。この実施例では、＜ｍａｘＫｅｙＬｅｎ＞より短いストリングは、右側が空白文字キャラクタでパディングされるべきである。
【００８５】
留意すべきことには、ストリング終端キャラクタ及び／又はワイルドカードを使用する本発明の実施例は、任意の２進データを含むキーストリングのインデクシングを複雑化し得る。現在公知の技術（代替選択的オルタナティブ、フォーマットにおける２進データのコーディング又はキーストリングの長さを指定する各キーストリングフィールドをもっての＜ＫｅｙＬｅｎ＞の蓄積）がそのような複雑性を克服するため使用され得る。
【００８６】
有利な実施例では、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ を、ワイルドカードキャラクタを含むストリング上に使用し得、その結果キーセット全体を単一の挿入オペレーション動作によりロジカルに記憶し得る。例えば“＊”がワイルドカードであり、動作オペレーション ＩＮＳＥＲＴ（“ｂｃｄ＊＊”）にＦＩＮＤ（“ｂｃｄｅｆ”）及びＦＩＮＤ（“ｂｃｄｇｈ”）が続くものと仮定すると、（ＦＩＮＤ Ｏｐｅｒａｔｉｏｎは以下詳述する）、両問い合わせにより、“ｂｃｄ＊＊”が与えられる。こうして、ＦＩのワイルドカードを衝突検出目的のため（例えば、データベースのロジカルロックマネージメント）のため使用し得る。次の入力、出力パラメータは、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例にて使用される。
【００８７】
＜ｉｄｘＨｄ＞入力パラメータはアクセスされているインデクスオブジェクトのハンドルである。＜ＫｅｙＳｔｒ＞入力パラメータは、インデクス中に挿入されるべきキーストリングに対するポインタである。＜ｕｓｒＩｎｆｏ＞入力パラメータは、インデクス中に挿入されているキーストリングと関連付けたいとユーザが願うデータに対するポインタである。
【００８８】
出力パラメータ＜ＫｅｙＨａｎｄｌｅ＞は、新たに挿入されるキーオブジェクトに対する１つのハンドルである。
【００８９】
ＩＮＳＥＲＴ ｏｐｅｒａｔｉｏｎの有利な実施例により実行されるステップは、フローチャート２００に概略が示されており、これは、図２及び図２ａに示されている。第１ステップは、メモリ内での１つの新たなリーフノードブロックのアロケーション２０２である。次に参照２０４は、＜ｔ＞を、入力パラメータ＜ｉｄｘＨｄ＞により参照されるインデクスツリーの根ルートにすることによりなされる。
【００９０】
判定２０６は、インデクスがルートにて空であるか否かを判定する。ＹＥＳの場合、＜ｎｅｗＫｅｙ＞のレジストレーション２０８がインデクスツリーの新たなルート根としてなされ、オペレーション動作は、出力パラメータ＜ＫｅｙＨａｎｄｌｅ＞として、アプリケーション２０２にてアロケート割り当てされた新たなリーフノードブロックに対する参照のリターン２８４へ進む。
【００９１】
他方では、デシジョン２０６にてインデクスが根にて空でないことが判明した場合、判定２１０は、１つのリーフノードに到達したか否かを判定する。ＹＥＳの場合には、判定２１８が実行される。他方ではＮＯの場合には、ルックアップ２１２過程が、第１のｐｏｓキャラクタ（上述のようにｐｏｓは現在ノード節点に対するキャラクタ比較位置を表す）の後直ちにキーストリング＜ＫｅｙＳｔｒ＞キャラクタに相応するエントリに対する現在ノード節点のローカル後継者ハッシュ表にて実行され、１つの相応のエントリがルックアップ２１２にて見出された場合、現在ノード節点としてそのエントリにて参照されたノード節点のアサインメント２１６過程が生起する（すなわち、参照されたノード節点が現在ノード節点となる）。他方では、ルックアップ２１２のプロセス中にて相応のエントリが見出されない場合、現在ノード節点として第１の後継者ノード節点（ｓｕｃｃＦｉｒｓｔ フィールドから取られた）のアサインメント２１４過程が生起する。いずれのケースにおいても、次いで現在ノード節点が判定２１０へ与えられる。
【００９２】
判定２１８は、キーストリング＜Ｋｅｙ Ｓｔｒ＞に一致する１つのキーストリングが既に現在ノード節点にて存在しているか否かを判定するため実行される。そのようなキーストリングに既に存在する場合、挿入過程が生起せず、そして、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の終端ターミネーション２２０過程がエラー条件と共に生起する。同一のキーストリングが既に存在しない場合には、比較２２２は、現在ノードに関連するキーストリング及びキーストリング＜ＫｅｙＳｔｒ＞により共有されるサブストリングの長さ＜ｊ＞を決定するため実行される。次いで、現在ノード節点からスタートして、ツリーのトラバース走査２２４過程が、それぞれのノード節点の親ノード節点をポイントするリンクをたどることにより上方に向かって生起進行していって、ついには、ノード＜ｔ＞に到達するようになり、このノード節点＜ｔ＞のキャラクタ比較位置ｐｏｓは、サブストリング長さ＜ｊ＞に等しい、又は、それより小である。このノード節点に到達すると、外部又は内部ツリー挿入を実行すべきかの判定２３０が、図２ａに示すように実行される。
【００９３】
判定２３２及び２３４により、ノード＜ｔ＞が空であるか、又は＜ｔ＞の比較位置ｐｏｓが＜ｊ＞に等しいことが判定された場合、内部ツリー挿入２４０が実行される。これに反し＜ｔ＞が空でなく、そして、＜ｔ＞の比較位置が＜ｊ＞に等しくない場合、内部ツリー挿入インサート２６０が実行される。
【００９４】
外部ツリー挿入２４０は、次のステップを含む。新たなノード節点の親ノード節点＜ｔ＞のレジストレーション２４２過程ステップが実行される。新たなノード節点（これは、アロケーション２０２においてアロケートされた新たなリーフノード節点ブロックである）へのポインタの挿入２４４は、適当なキーストリングキャラクタのもとで＜ｔ＞のローカル後継者ハッシュ表にて実行され、そして、任意の悪影響を受けたフィールドが更新される（例えば、ｈａｓｈＮｅｘｔ フィールド又は、実施例で使用される場合には、ｈａｓｈＰｒｅｖ フィールド）。＜ｔ＞の後継者ノード節点の２重にリンクされたサイブリングリスト内への新たなノード節点の挿入２４６もまた、適当なｓｂｌＮｅｘｔ及びｓｂｌＰｒｅｖ フィールドを更新することにより実行される。判定２４８は、ノード節点＜ｔ＞の比較位置がワイルドカードキャラクタであるか否かを判定するため実行される。ＹＥＳの場合＜ｔ＞のワイルドカードフラグ（実施例中に存在するならば）がセットされる。
【００９５】
内部ツリー挿入２６０は次のステップを含む。新たなノード節点ブロックのアロケーション２６２が実行される。次に、新たなリーフ節点ブロック（これはアロケーション２０２にてアロケートされたものである）へのポインタの挿入２６４が第２の新たなノード節点ブロックのローカルサクセッサ後継者ハッシュ表にて実行される。判定２６６は、ノード＜ｔ＞がＮＵＬＬ参照であるか否か判定するため実行される。ＹＥＳの場合は、インデクスツリーの新たな根としての第２の新たなノード節点ブロックのレジストレーションが実行される。判定２６６の結果如何に係わらず、第２の新たなノード節点ブロックの、それの親のローカル後継者ハッシュ表内への挿入２７０が実行される。内部ツリー挿入２６０は第２の新たなノード節点ブロックの、それの親の後継者ノード節点の２重にリンクされたサイブリングリスト内への挿入２７２をもって終了する。挿入２７２もまた、適当なｓｂｌＮｅｘｔ及びｓｂ１ Ｐｒｅｖフィールドを更新する。
【００９６】
出力ツリー挿入２４０又は、入力ツリー挿入２６０過程が実行されるかに係わりなく、次のステップは、親ノード節点の後継者カウンタのインクリメント２８０である。それに引き続いて、親ノードのワイルドカードフラグのセッティング２８２は、１つのワイルドカードがそれの後継者ノード節点間にある場合には実行される。アロケーション２０２にてアロケーション割当られた新たなリーフノード節点への参照のリターン２８４が出力パラメータ＜ＫｅｙＨａｎｄｌｅ＞ として実行される。
【００９７】
上述のようなフローチャート２００に対する上述のステップにより示されているように、高速ＬＩＦＯメモリマネージャの使用により、従来のメモリマネージメントに対する改良がクリエイト創出される。従来のメモリマネージメントの実行時間が、概して、少なくとも最悪のケースにおいて、アロケーション割当られたメモリブロックの総数に依存する。多数のエントリが存在する状況では、従来方法は禁止的に低速である。ＬＩＦＯメモリマネージャは、示されているように、ツリーノード節点の固定サイズを利用し、これによりツリーノード節点がフリー、自由なエントリのスタック上に置かれ得る。スタック上に自由なフリーノードを、プッシュすること、又はアロケートされたノードをスタックから除去することが単一のスタックオペレーション動作に含まれるので、ＬＩＦＯメモリマネージメントの実行時間がアロケーション割当られたノード節点の数に無関係である。
【００９８】
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの事例
次いでＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の１例の概略を説明する。図３及び図４に関連して述べると、そこに示されたＩＮＳＥＲＴ （“ｃｅｄｇ”）Ｏｐｅｒａｔｉｏｎ の１事例がインデクスツリー３０２上で実行され、このインデクスツリーは、インデクスツリー２と同じようにスタートする。ＦＩは、新たなキーストリングに対する挿入の場所を見出すためインデクスツリー３０２をトラバース走査する。ＦＩは、根ノード節点４でスタートし、この根ノード節点４のｐｏｓフィールド３３１は、最初の第１の零キャラクタが、根ノード節点４から発するサブツリー内に含まれているすべてのキーストリングに対して同一である（すなわち、第１のキャラクタのどれもが同一でない）ことを指示する。こうして、挿入すべきストリングの第１キャラクタが“ｃ”であるので、ＦＩハッシュ表配列３４０内でハッシュバケット３４１をルックアップする。ＦＩは内部ノード節点８への“ｃ”ブランチ参照３５０過程を引き続いて行う。更に留意すべきことには、挿入ストリングが第１のキャラクタとして“ｇ”を有するならば、ハッシュ衝突が生じることとなり（それというのは、“ｃ”と“ｇ”の双方がハッシュバケット３４１を占めることとなるからである）、そして、ｈａｓＮｅｘｔ フィールド１９に含まれるリーフノード節点５ｄへの参照リンクをたどることとなるからである。
【００９９】
内部ノード節点８にて、ｐｏｓフィールド１１は、キャラクタ比較位置ｐｏｓが２であることを指示する。こうして、挿入すべきストリングの第３のキャラクタ、すなわち、“ｄ”が考慮され、ＦＩはハッシュ表配列１８にてハッシュバケット１８ｄをルックアップする、ＦＩはリーフノード節点５ｃへの“ｄ”ブランチ３６０過程を実行する。
【０１００】
次いで、ＦＩは、次のようなノードを見出すまでツリーインデックス３０２を再びバックアップ方向にトラバース走査する、すなわち、その比較位置ｐｏｓが、サブストリングの長さに等しいか、それより、小であるノードを見出すまでトラバース走査するものであり、当該のサブストリングは、“ｃｅｄｇ”がリーフノード５ｃに関連付けられたキーストリング（すなわち、“ｃｄｄｈ”）と共有するのである。結論付けられることは、ＦＩは、そこにてｐｏｓが１に等しいか、それより小であるｐｏｓフィールドを探す。ＦＩが親ノード節点リンク３７０及び３８０を通してそれの上向きのトラバース走査上にて見出す、当該の基準を充足する第１のｐｏｓフィールドは、ｐｏｓフィールド３３１であり、このｐｏｓフィールドは、根ノード節点４の１つのフィールドであり得る。ノード節点が空でなく（上記の判定２３２）そして、ｐｏｓフィールド３３１が１に等しくない（上記の判定２３４）ので、内部ツリー挿入２６０は、実行される必要がある。
【０１０１】
図４は、内部ツリー挿入２６０の実行の際のインデクスツリー４０２へのインデクスツリー３０２の変換を示す。第１に２つの新たなノード節点である、新たな内部ノード節点４０８及び新たなリーフノード節点４０５がＦＩのＬＩＦＯメモリマネージャ（ＬＩＦＯ―ＭＭ）４４０からアロケーション割当られる。新たな内部ノード節点４０８がノード節点４の“ｃ”ブランチ参照３５０の後継者として挿入される。古い“ｃ”ブランチのサクセッサ継承者−これは内部ノード節点８であるーは今や新たな内部ノード節点４０８の“ｄ”ブランチ参照４５０のサクセッサ継承者になる。更に新たにリーフノード４０５は、新たな内部ノード節点４０８の“ｅ”ブランチとなる。
【０１０２】
ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ
ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎは、関連付けられたノード節点をリムーブ除去することにより、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ により先に挿入された１つの所定のインデクスエントリをリムーブ除去するものである。リムーブ除去すべきインデクスエントリは、ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ又はＦＩＮＤ Ｏｐｅｒａｔｉｏｎによりリターンされるような、それの相応のキーハンドルにより指定される。
【０１０３】
次の入力パラメータはＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ又はＦＩＮＤ Ｏｐｅｒａｔｉｏｎの有利な実施例において使用される。＜ｉｄｘＨｄ＞入力パラメータは、そこからインデクスエントリを除去すべきインデクスオブジェクトのハンドル処理である。（ＫｅｙＨａｎｄｌｅ＞入力パラメータは、除去すべきインデクスエントリ（又はノード節点）に対するハンドルである。
【０１０４】
図５に関連して述べると、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例により実行されるステップは、フローチャート５００に概略が示されている。第１のステップは、除去すべきノード節点が、親ノード節点を有するか否かを判定することである。ＮＯの場合には、ＮＵＬＬ参照へのインデクスツリーの根のセッティング５０６過程が実行され、その後、除去されたツリーノード節点に属するメモリブロック８のフリー解放５５０が実行される。他方では、ノード節点が１つの親ノード節点が有する場合、親ノード節点に対する当該ノード節点への参照を除くステップ５０８（親ノード節点のｓｕｃｃＦｉｒｓｔ フィールドもまたモデファイし得る）が実行される。更に、親ノード節点の後継者ノード節点の２重連結されたサイブリングリストからのノード節点の除去５１０が適当なｓｂｌＮｅｘｔ ｓｂｌＰｒｅｖ フィールドを更新することにより実行される。次に親ノード節点のサクセッサ後継者カウンタのデクリメント５１２が実行される。このポイントにて、インデクスツリー中には除去されたノード節点への参照がもはや無い。しかしながら、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ は、インデクスツリーをモデファイする必要が起こり得る。
【０１０５】
判定５２０は、親ノード節点が１つより多くの後継者ノード節点を左に有するかを判定する。ＹＥＳの場合には、除去されたノード節点の比較キャラクタがワイルドカードであったか否かを判定する。他方では親ノード節点が唯一の後継者ノード節点のみを左に有する場合には、親ノード節点は、ブランチングポイントとしてもはや使いものにならず、判定５２２は、グランドペアレント（すなわち、除去されたノード節点のグランドペアレント、また、親ノード節点の親）が存在するか否かを判定する。グランドペアレントノード節点が存在しない場合、インデクスツリーの新しい根のアサインメント割当５２４が除去されたノード節点の唯一のサイブリングに与えられ、その後、除去されたノード節点の唯一のサイブリングの比較キャラクタがワイルドカードであったか否かの判定５４０が実行される。他方では、グランドペアレントが存在する場合には、グランドペアレントノードハッシュ表からの親ノードの連結分離５２１が実行される。次に除去されたノード節点の唯一のサイブリングへの参照の挿入５２８がグランドペアレントにて実行される。親ノード節点の除去５３０が実行される。グランドペアレントは今や新たな親ノードとなる。
【０１０６】
判定５４０は、除去されたノード節点の比較キャラクタがワイルドカードであったか否かを判定する。ＹＥＳの場合、ワイルドカードフラグの削除５４２が親ノード節点にて実行される。除去されたノード節点の比較ｖｒｋがワイルドカードであったか否かに拘わらず、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ は、除去されたツリーノード節点に属するメモリブロックのフリー解放５５０で終了する。
【０１０７】
フローチャート５００で上述のステップで示されているように、ノード節点へのリンクの除去（２重リンクされたサイブリングリストからのノード節点の除去５１０のような）によりメモリブロックのフリー解放５５２が生ぜしめられる。従来のシングルリンク、単一連結されたリストが使用された場合には１つのノード節点を除くには、除去すべきノード節点が見出されるまでにサイブリングリストを直線的にサーチすることが必要となる。このことにより、ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎの実行時間に対して直線的成分が生成されることとなる。最悪の場合には、サイブリングリスト全体をサーチしなければならなくなる。しかしながら、２重に連結されたサイブリングリストは、ＬＩＦＯメモリと相俟って、いずれの直線的リストスキャニングなしでもノードの削除をサポートし、それにより全体的性能を改善する。
【０１０８】
ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の事例
次にＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎの１事例の概略を説明する。図６及び図７について説明すると、ＲＥＭＯＶＥ（“ｃｄａｆ”） Ｏｐｅｒａｔｉｏｎの１事例がインデクスツリー６０２上へ実行され、これはインデクスツリー２と同じようにスタートする。先ず、仮定されていることによれば、ユーザは、除去すべきリーフノード節点（事例中のリーフノード節点５ｂ）を識別する必要なキーハンドル＜ＫｅｙＨａｎｄｌｅ＞を供給する。リーフノード５ｂは、先ず、内部ノード節点８から除去される。内部ノード節点は、今や唯一の後継者ノード節点（すなわち、リーフノード節点５ｃ）を有するので、内部ノード節点は、ブランチングポイントとしてもはや使用されなくなり、除去する必要がある。従って、内部ノード節点８及び根ノード節点４の“ｃ”のブランチ参照３５０が除去される。フリー解放ノード、リーフノード節点５ｂ及び内部ノード節点８は、ＬＩＦＯ―ＭＭ４４０にリターンされる。
【０１０９】
図７に関連して述べると、インデクスツリー７０２は、古いリーフノード節点５ｃから変換された、新たなリーフノード節点７１０を有する。根ノード節点４の“ｃ”ブランチ参照３５０は、リーフノード７１０への“ｃ”ブランチ参照７５０により置換される。リーフノード７１０は、リーフノード５ａ及び５ｄを有する２重リンクされたサイブリングリスト７６０を継承インヘリタンスする。リーフノード７１０の ＨａｓｈＮｅｘｔ フィールド７２０は、ｈａｓｈＮｅｘｔ フィールド１９のコンテンツを継承インヘリタンスする。
【０１１０】
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｅｘａｃｔ Ｍａｔｃｈ）（精確なマッチン グ）
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｅｘａｃｔ Ｍａｔｃｈ）の精確なマッチングーバージョンは、サーチキーストリングを精確にマッチングするエントリに対する指定されたインデクスをサーチする。パーシャルマッチング問い合わせと異なって、ワイルドカードキャラクタは、精確なサーチにおいて特別な意味を有しない。せいぜい、１つのインデクスエントリは、サーチストリングをマッチングする。当該のオペレーション動作が成功を収めて完結すると、マッチングインデクスエントリのＫｅｙＨａｎｄｌｅがリターンされる。次の入力、出力パラメータは、ＦＩＮＤ ＯｐｅｒａｔｉｏｎのＥｘａｃｔ Ｍａｔｃｈ ｖｅｒｓｉｏｎ の精確なマッチングーバージョンの有利な実施例において使用される。
【０１１１】
＜ｉｄｘＨｄ＞入力パラメータは、サーチすべきインデクスオブジェクトのハンドルである。＜ＫｅｙＳｔｒ＞入力パラメータは、インデクスに対してサーチされているキーストリングに対するポインタである。＜ＫｅｙＨａｎｄｌｅ＞出力パラメータは、マッチングインデクスエントリに対するハンドルである。
【０１１２】
図８について述べれば、 ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｅｘａｃｔ Ｍａｔｃｈ）の精確なマッチングーバージョンの有利な実施例により実行されるステップは、フローチャート８００に概略が示されている。第１のステップは、サーチされているインデクスツリーの根ノード節点への参照８０２である。
【０１１３】
次に、判定８０４は、現在ノードが内部ノードであるか否かを判定する。ＮＯの場合には、完結したストリング比較８２０が、サーチキーストリングと、現在ノードに関連したキーストリングとの間で実行される。現在ノードが内部ノードである場合には、ノードのキャラクタ比較位置にてサーチキーストリングキャラクタの考慮検討８０６がなされる。次のノードへのポインタの検索８０８が、現在ノードの後継者ハッシュ表を使用することにより実施される。次に新たな現在ノードとなるべき次のノードのアサインメント割当８１０が実行される。判定８０４は、新たな現在ノードに対して実行される。
【０１１４】
サーチキーストリングと、現在ノードに関連したキーストリングとの間で完結したストリング比較８２０が実行される。 ストリングが同一でない場合、サーチの終端ターミネーション８２２が実行され、エラーコンディションが立てられる。他方では、ストリングが同一である場合、インデクスエントリに対するハンドルとして現在リーフノードへの参照のリターン８２４が実行される。
【０１１５】
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｐａｒｔｉａｌ Ｍａｔｃｈ）
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ（Ｐａｒｔｉａｌ Ｍａｔｃｈ）を、すべてのインデクスエントリのセットに対して反復的に、ワイルドカードキャラクタを有する１つの指定されたサーチストリングマッチングをスキャンするため使用し得る（本発明の有利な実施例ではワイルドカードキャラクタは略称では“＊”である。例えば、オペレーション動作Ｏｐｅｒａｔｉｏｎ ＩＮＳＥＲＴ（“ａｂａｄｃ”）、ＩＮＳＥＲＴ（ａｂｂｃｄ“）、ＩＮＳＥＲＴ（”ｂａ＊ｄｃ）、ＩＮＳＥＲＴ（“ｂａ＊ｄｄ）、ＩＮＳＥＲＴ（“ｂａｄａｃ”）、ＩＮＳＥＲＴ（“ｂａｄｂｃ”）、及びＩＮＳＥＲＴ（“ｄ＊ａ＊＊”）の条件下で、パーシャルマッチング問い合わせ検出ｐａｒｔｉａｌ ｍａｔｃｈ ｑｕｅｒｙ ＦＩＮＤ（“＊ｂ＊ｃｄ”）により“ａｂｂｃｄ”及び“ｄ＊ａ＊＊”が与えられる。それというのは、ストリングエントリの第１，第２キャラクタは、当該の特定の目的に重要でないからである。次の入力、出力パラメータがＦＩＮＤＯｐｅｒａｔｉｏｎのパーシャルマッチングバージョン ｐａｒｔｉａｌ ｍａｔｃｈ ｖｅｒｓｉｏｎ の有利な実施例において使用される。
【０１１６】
入力パラメータは＜ｉｄｘＨｄ＞、＜ＫｅｙＳｔｒ＞、＜ｍａｘＲｅｓｕｌｔｓ＞及び＜ｒｅｓｕｌｔｓＢｕｆｆｅｒ＞を含む。＜ｉｄｘＨｄ＞パラメータは、サーチすべきインデクシングオブジェクトのハンドルである。＜ＫｅｙＳｔｒ＞パラメータは、インデクスにてサーチされているキーストリングに対するポインタである。＜ｍａｘＲｅｓｕｌｔｓ＞パラメータはＦＩＮＤ Ｏｐｅｒａｔｉｏｎの繰り返しごとにリターンされるべきキーハンドルの最大数である。＜ｒｅｓｕｌｔＢｕｆｆｅｒ＞は結果バッファに対するポインタであり、これは、＜ｍａｘＲｅｓｕｌｔｅ＞エントリまでホールドするのに十分な大きさのキーハンドルの配列である。
【０１１７】
出力パラメータは＜ａｃｔＲｅｓｕｌｔｓ＞及び＜ｍｏｒｅＲｅｓｕｌｔｓ＞を含む＜ａｃｔＲｅｓｕｌｔｓ＞パラメータは、結果バッファにおいてリターンされるキーの実際の数をリターンする。＜ｍｏｒｅＲｅｓｕｌｔｓ＞パラメータ、また、サーチコントロールパラメータとも称され、＜ｍａｘＮｕｍｂｅｒ＞結果より多くのものがあったか否かを指示するためのフラグとして用いられる。
【０１１８】
ｐａｒｔｉａｌ Ｍａｔｃｈ ＦＩＮＤ Ｏｐｅｒａｔｉｏｎの有利な実施例により実行されるステップがフローチャート９００にて概略が示されており、これは図９及び図９ａに示されている。第１のステップは、これがＦＩＮＤ Ｏｐｅｒａｔｉｏｎのコール（ｃａｌｌ）であるか否かを判定するための判定９０４である。ＹＥＳの場合、インデクスツリーの根節点ノードへのローカルバックトラッキングスタックポインタ＜ｓｐ＞のリセット９０６が実行される。他方、ＮＯの場合、ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ の先行コール呼出から先にセーブされたスタックポインタのリロード９０８が実行される。ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ の最初のコールであっても、なくても、次のステップは、バックトラッキングスタックが空であるか否かを判定すること９１０である。ＹＥＳの場合、ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ は、結果バッファのリターン９９４で終わる。他方では、否定の場合は、現在スタックトップからのツリーノード＜ｔ＞の検索９１１が実行される。次いで＜ｔ＞がリーフノードであるか否かを判定する判定９１２が実行される。ＹＥＳである場合、リーフノード解析９２０が実行される。他方ＮＯの場合、内部ノード解析９５０が実行される。
【０１１９】
リーフノード解析９２０は、サーチキーストリング及びリーフノードに関連するキーストリングが同じであるかを判定する比較９２２及びワイルドカードが考慮される際サーチキーストリング及びリーフノードに関連するキーストリングが同じであるか否かを判定する比較９２８からスタートする。２つのストリングが同じであるか、又はワイルドカードとマッチングする場合、リーフノードに関連するインデクスエントリの結果バッファへの加算９３０が、実行される（すなわち、インデクスエントリが結果バッファに加えられる）。ストリングが同じであるか、又はマッチングをしているかに拘わらず、サーチキーストリング及びリーフストリングに関連するキーストリングが相異なる場合にてワイルドカードでない第１キャラクタ位置であるべきとき現在キャラクタ位置のアサインメント９３１が実行される。リーフノード解析９２０は、バックトラックスタックの枝刈り９３２で終わる。バックトラックスタックの枝刈り９３２は反復的に次のことをチェック９３３すること及び除去９３４により実行され、すなわち、（ａ）スタックが空でないか否か、そして（ｂ）親ノードのキャラクタ比較位置＜ｐｏｓ＞がキャラクタ比較位置＜ｊ＞より大であるか否かのチェック９３３により実行され、そのことは、そして、それ等の２つの条件のうちの少なくとも１つがもはや充足されなくなるまでバックトラックスタックからのノードの除去９３４が実行されるのである。リーフノード解析９２０が終わった後、判定９１０が再び実行される。
【０１２０】
内部ノード解析９５０は、現在ノードのキャラクタ比較位置にて＜ｃｈ＞をサーチキーストリングキャラクタであるとのアサインメント９５２をもってスタートする。ワイルドカード チェック９５４は、＜ｃｈ＞がワイルドカードキャラクタであるか否かを判定する。ＹＥＳの場合、ワイルドカードは、バックトラックスタック上へのすべての後継者ノードのプッシュ９７０で終わる。プッシュ９７０は＜ｔ＞の後継者リスト内のサイブリングーリンク過程をたどることにより、当該タスクを成し遂げ、このことの意味することは、＜ｔ＞から下降するサブツリー全体が更なるサーチに対してマーキングされるということである。他方で、＜ｃｈ＞がワイルドカードキャラクタでない場合は、ハッシュ表のルックアップ９５５が実行される。ルックアップ９５５は、＜ｃｈ＞に関連する後継者ノード（又は、代替選択的に＜ｃｈ＞に関連する後継者ノードが存在しない場合は、第１の後継者ノード）を見出し、ノードをバックトラックスタック上にプッシュする。次に、判定９５６は、＜ｔ＞がそれの後継者ノード内にワイルドカードを有しているか否かを判定する。＜ｔ＞がワイルドカードを有していない場合には、内部ノード解析９５０は終了する。他方＜ｔ＞がワイルドカードを有している場合には内部ノード解析９５０はバックトラックスタック上へのワイルドカードノードのプッシュ９５８で終わる。内部ノード解析９５０が終わった後、判定９１０が再び実行される。
【０１２１】
ＦＩＮＤ Ｏｐｅｒａｔｉｏｎ ( ｐａｒｔｉａｌ Ｍａｔｃｈ ) の事例
次にＰａｒｔｉａｌ Ｍａｔｃｈ ＦＩＮＤ Ｏｐｅｒａｔｉｏｎの１事例の概略を説明する。図１０に関して述べると、ＦＩＮＤ（“＊ｂ＊ｃｄ”）ｏｐｅｒａｔｉｏｎ がインデクスツリー１００２上にて実行される様子が示されている。インデクスツリー１００２は、ノード１０１０，１０２０，１０３０，１０４０，１０５０，１０６０，１０７０，１０８０，１０９０，１１００，及び１１２０を比較する。ノード１０１０は、インデクスツリー１００２の根ノードである；従って、キャラクタ比較位置ｐｏｓ零を有する。内部ノード１０２０はｐｏｓ２及びキャラクタ“ａ”を有する；内部ノード１０３０はｐｏｓ２及びキャラクタ“ｂ”を有する；内部ノード１０７０はｐｏｓ４及び比較キャラクタ“＊”（ワイルドカードキャラクタ）を有する。内部ノード１０８０はｐｏｓ３及びキャラクタ“ｄ”を有する。リーフノード１０４０は、ノード１０１０の後継者ノードであり、キーストリング“ｄ＊ａ＊＊”に関連付けられている。リーフノード１０５０及び１０６０は、ノード１０２０の後継者ノードであり、それぞれキーストリング“ａｂａｄｃ”及び“ａｂｂｃｄ”に関連付けられている。リーフノード１０９０及び１１００はノード１０７０の後継者ノードであり、キーストリング“ｂａ＊ｄｃ”及び“ｂａ＊ｄｄ”に関連付けられている。リーフノード１１１０及び１１２０はノード１０８０の後継者ノードであり、それぞれキーストリング“ｂａｄａｃ”及び“ｂａｄｂｃ”に関連付けられている。
【０１２２】
ＦＩは、インデクスツリー１００２の根ノード１０１０におけるサーチをスタートする。ｐｏｓは、ノード１０１０に対して零であるのでＦＩは、サーチキーストリング“＊ｂ＊ｃｄ”の第１のキャラクタに注目する。これはワイルドカードキャラクタであり、而して、ＦＩは、ノード１０１０の各々の後継者ノード（すなわちノード１０２０，１０３０，及び１０４０）をバックトラッキングスタック上へプッシュする。留意すべきことには、バックトラッキングスタックは、トップ（最初）からボトム（最後）へ向かって、ノード１０２０，１０３０，及び１０４０を有する。バックトラッキングスタックにおける第１のノード、ノード１０２０は、トップからポップされる。ノード１０２０はｐｏｓ２を有するので、サーチキーストリングの第３キャラクタが評価される。これは、再度ワイルドカードキャラクタであり、而して、ＦＩは、ノード１０２０の各後継者ノード（則ちノード１０５０，１０６０）をバックトラックスタック上へプッシュする。バックトラックスタックは今やトップからボトムへ向かってノード１０５０，１０６０，１０３０，及び１０４０を有する。
【０１２３】
次いでノード１０５０はバックトラックスタックのトップからポップされる。これはリーフノードであるので、ＦＩは、第１の非ワイルドカードキャラクタ位置＜ｊ＞を判定し、ここでは、サーチキーストリングはノード１０５０に関連付けられたキーストリングとは相異なる。キーストリング“＊ｂ＊ｃｄ”及び“ａｂａｄｃ”は、第４のキャラクタにて差異があり（それ等は最初の３つのキャラクタに対してマッチングし、＜ｊ＞は３であるから）、そしてノード１０５０は、ミスマッチとして破棄される。ノード１０６０は、バックトラックスタックのトップからポップされる。これもまた、リーフノードであり、ＦＩは第１の非ワイルドカードキャラクタ位置＜ｊ＞を求め、ここで、サーチキーは、ノード１０６０に関連付けられたキーストリングとは異なる。しかしながら、“＊ｂ＊ｃｄ”及び“ａｂｂｃｄ”はマッチングし、而して、ノード１０６０に関連するキーエントリが結果バッファへの第１の加算になる。
【０１２４】
ＦＩは、バックトラックスタックにおいてなおスタックがあることを判定し、しかして、次のノード、ノード１０３０はトップからポップされる。ノード１０３０は、ｐｏｓ２を有する内部ノードになり、而して、サーチキーストリングの第３キャラクタが評価される。これはまた、ワイルドカードであり、而して、ＦＩはノード１０３０の各後継者ノード（則ち、ノード１０７０及び１０８０）をバックトラックスタック上へプッシュする。バックトラックスタックは、今やトップからボトムへ向かってノード１０７０，１０８０，１０３０，及び１０４０を有する。
【０１２５】
バックトラッキングスタックにおいて、なおノードがあり、而して、ノード１０７０は、トップからポップされる。ノード１０７０はｐｏｓ４を有する内部ノードであり、而してサーチキーストリングの第５キャラクタが評価される。この位置におけるキャラクタは“ｄ”であり、而して、ノード１０７０の“ｄ”ブランチ１０７２は、ノード１１００へ向けられる（プロセスにおけるノード１０９０破棄）。
【０１２６】
ノード１１００はリーフノードであり、而して、ＦＩは、第１の非ワイルドカードキャラクタ位置＜ｊ＞を判定し、ここで、サーチキーストリングは、ノード１０５０に関連するキーストリングとは異なる。キーストリング“＊ｂ＊ｃｄ”及び“ｂａ＊ｄｄ”は、第２のキャラクタにて相違なり、（それというのは、それ等は第１のキャラクタに対してマッチングするから＜ｊ＞は１である）そしてノード１１００はミスマッチとして破棄される。このポイントにおいてこそ発見的ヒューリスティックな枝刈り（ｐｒｕｎｉｎｇ）が付加的なサブツリー全体を破棄するため使用される。キーストリングがリーフノード１１００とは異なるー＜ｊ＞が１に等しい時―場合には、それの親ノードのｐｏｓが１より大である他のいずれのノードとも異ならなければならないということは、ＦＩツリーの性質、特性である。この性質、特性は、次のことに由来、導出される、すなわち、サブツリーに関連するすべてのキーストリングが、サブツリーの根における内部ノードのｐｏｓに等しい長さを有するプレフィックスを共有することに由来、導出される。従って、ノード１０３０は、ｐｏｓ２を有するので、バックトラッキングスタック内になお存在するサブツリー中のすべてのノード（すなわちノード１０７０及び１０８０）が破棄され得、それによりインデクスツリーが枝刈り（ｐｒｕｎｉｎｇ）される。
【０１２７】
バックトラッキングスタックにおいてなお残っている唯一のノード、ノード１０４０が、ポップされる。これはリーフノードであり、ＦＩは、第１の非ワイルドカードキャラクタ位置＜ｊ＞を求め、ここで、サーチキーは、ノード１０４０に関連するキーストリングとは異なる。しかしながら、“＊ｂ＊ｃｄ”及び“ｄ＊ｃ＊＊”はマッチングし、而してノード１０４０に関連するキーエントリは、結果バッファに加算される。考慮すべきノードはもはやなく、そして、結果スタックがリターンされる。
【０１２８】
図１１にはロジカルロックマネージメントを実行するためのＦＩメソッドを有利に利用する事例が表されている。ＦＩメソッドを、ヒューマンリソースマネージメント、ファイナンシャルズ、ロジスティックス、ビジネスワークフロー、組織マネージメント、及び他のシステムにおけるようなデータベースアプリケーションにおいて、衝突検出又は衝突マネージメントのため使用し得る。そのようなアプリケーションにおいて、多数のユーザ、例えば図１１中ユーザ１〜６は、データベース１２００にて記憶されているデータをアクセスする。ロジカルロックマネージメントは、いくつかのユーザがそこにてデータセットが変更訂正されるリクエスト又はオペレーションをもってデータベース中の同じデータセットへのアクセスするのを阻止するために実行され、前記のリクエスト又はオペレーション操作では、データセットは、例えば、書込又は削除により変更される。保証されなければならないのは、相次いでのユーザにより当該のデータセットの変更が所定の順序で実行されることである。
【０１２９】
このことを保証するためデータベース１２００への複数ユーザのリクエスト間の衝突を検出するためロックマネージャ１２０１が確立される。図１１例中、例えばユーザ１と６との間に衝突が起こる。明らかに、１つのデータベースのマルチユーザ環境の性能が、ロックマネージャ１２０１の性能に関してクリティカルである、それというのは、データベースのアクセス前に各ユーザのリクエストがロック衝突テストに合格しなければならないことに鑑みて、ロックマネージャ１２０１がシステム全体のスループットのボトルネックになり得るからである。本発明によれば、複数のストリングエントリを含めて、データベース１２００をアクセスするいくつかのユーザの複数リクエストの衝突検出、又は衝突マネージメントの方法メソッド、例えば、ロックマネージメントを実行するための方法メソッドは、ユーザのリクエストを含めてダイナミックロックテーブル１２０１のメンテナンスを包含し、前記のダイナミックロックテーブル１２０１では、リクエストは、本発明により、例えばＦＩメソッドによりインデクシングされる。１つのユーザのリクエストに関連して、ロックテーブル１２０２への問い合わせが、ユーザのリクエストがデータベース１２００に伝達される前に、例えば、ＦＩにより、実行される。ロックマネージャ１２０１は、ＦＩインデクシングされるロックテーブル１２０２を維持し、ここにはユーザによりリクエストされるロックが常駐する。
【０１３０】
例えば、ユーザ６のリクエスト“＊＊５＊”は、同じデータセットをアクセスするユーザの５つのリクエスト“ＣＹ５”の故に拒絶される。
【０１３１】
例えば、インデクシング“ＤＸＯ”を有するデータセットへのユーザ１の書込リクエストがある場合、先ず、ＦＩインデクシングされるロックテーブルへの挿入インサートオペレーション動作が実行され、それにより、インデクス“ＤＸＯ”インサートが、ＦＩサーチツリー内に挿入される。インサート動作オペレーションが成功を収めて実行され、インデクス“ＤＸＯ”がサーチツリー中に挿入され得たならば、ユーザ１はデータベース１２００における相応のデータセットへの書込アクセスを実行し得る。ところが、インサートオペレーション動作が、成功しなかった場合、インデクスーストリング“ＤＫＯ”は既にＦＩサーチツリー内にリーフノードとして含まれ、このことはロックマネージャ１２０１により検出される。この場合において、衝突が指示され、データベース１２００における関連するデータセットへのユーザ１の書込アクセスが否認される
データベース１２００への成功を収めた書込アクセスが終了ｆｉｎｉｓｈｅｄされる場合、除去オペレーション動作は、ＦＩロックテーブル１２０２において実行され、これにより、インデクシングされたストリング“ＤＸＯ”を有するリーフツリーが削除される。その後、他のユーザは、データベース１２００における相応のデータセットをアクセスし得る。
【０１３２】
単一の（すなわち、フルに指定された）データベーステーブルエントリ（例えば“ＡＸ３”）に対してのみならず、セット全体である（すなわち部分的パーシャルに指定された）エントリ（例えば、“Ｂ＊＊”ここで“＊”は基礎となるアルファベットの任意の文字であるワイルドカードを表す）に対してもロックを付与し得る。
【０１３３】
データベース１２００へのすべてのリクエスト及びアクセスが単一のＦＩサーチツリー内にマッチングされることに鑑みて、ロックマネージャ１２０１のレスポンス及び性能がデータベース１２００へのアクセスの総合的性能にとって重要である。ロックマネージャ１２０１がインデクシングされたロックテーブル１２０２を維持する場合、短いレスポンスタイム、ひいてはロックマネージャ１２０１の良好な性能が結果的に生じる。この点に関し、例えば、次の特徴事項は有利であり得る；サーチツリーはプレフィックスツリーとして構成され、ローカルハッシュ表が使用され、パーシャルにマッチングされたリクエストが実行され得ること、ＬＩＦＯメモリマネージメントの性能、サーチ期間中の枝刈り（ｐｒｕｎｉｎｇ）及び／又はバックトラッキングの実行である。
【０１３４】
本発明の利点は、ロックテーブル１２０１においてまた、部分的に指定されたストリング（例えば“ａｂ＊ｃ”又は“＊ｂｃ＊”）をも記憶し得ることである。従って、ＦＩロックテーブル１２０２内へのシングルインデクスインサートによりアクセスされるデータセットの部分をマッチングすることが可能である。直線的サーチ及びハッシングのような公知のサーチアルゴリズムにおいて必要なように、当該部分内に含まれる個々のデータセットをマークする必要がない。パーシャルに指定されたインデクスリクエストを実行し得る可能性により、ＦＩサーチの上述の特徴及びそれに基づくサーチメソッドのほかにさらにＦＩロックテーブル１２０２における所要のサーチ時間が低減される。
【０１３５】
他のサーチメソッドとの比較
次に、どのように本発明のアクチュアルなインプリメンテーション、−“ＦＩ”と称されるーが上述の他のサーチメソッドに比較されるかを展望的に示す。表１は、Ｉｎｔｅｌ Ｐｅｎｔｉｕｍ Ｐ１８０ ｍａｃｈｉｎｅ 上にて１つの完全な ＩＮＳＥＲＴ/ＦＩＮＤ/ＲＥＭＯＶＥ ｃｙｃｌｅ が実行される時間μｓ（マイクロ秒）を示す。この比較のためＦＩプログラム及び通常使用されるＵＮＩＸスタンダードストリングインデクシング及びサーチライブラリィは実世界データベース上でサイクルを実行した（ここで、エントリはサーチツリーでは均一に分布していない）。ＢＴＲＥＥ サーチは、ＵＮＩＸ/ＸＰＧ４ ｔｓｅａｒｃｈ（３Ｃ） Ｓｔａｎｄａｒｄ ｈａｓｈ ｌｉｂｒａｒｙを用いて実行された。一方 ＬＩＮＥＡＲ ｓｅａｒｃｈ は、直線的２重連結されたリストバスリニアサーチで実行された。
【０１３６】
留意すべきことには高速ストリングメソッドに対する実行時間が、数１０μｓの大きさに留まる。―１００万エントリにわたるサーチの場合でも―。
【０１３７】
また明らかになっていることは、高速ストリングメソッドはサーチすべきキーストリングの大きさに対する優れた性能及びロバストネスを提供する。表２は、種々の長さのキーストリングを含むデータベース上へのＦＩ及びＨＡＳＨがサーチを実行するため時間μｓを示す。高速ストリングメソッドに対する実行時間は、キーストリングが数オーダの大きさ分も一層より大である場合でさえも、たんにわずかしか変化しない。
【０１３８】
本発明及び他のメソッドの特徴の要約を表３に示す。１つのセルにおけるプラス“＋”は、サーチメソッドが指示された特徴に特に適する（又はロバストである）ことを指示する。
【０１３９】
本発明の実施例に適用された本発明の基本的な新規な特徴を示してあり、説明し、指摘してあるが、本発明の精神を逸脱することなく、ここに開示されたような、本発明の形態及び詳細上の種々の省略、過程及び変更がなされ得る。明示されているところによれば、同じ成果を達成するため、実質的に同じ手法で、同じ機能を実行する要素及び／又は方法ステップの一切の組合せは、本発明の範囲内に入る。従って、添付されたクレームの範囲により指示されているものは、そこに指示されたいくつかの限定的な態様に限って規定されているに過ぎない。
【０１４０】
【表１】
【表２】
【表３】
【図面の簡単な説明】
【図１】 高速ストリングインデクシングのアプリケーションを具現化するインデクスツリーの基本的データ構造の例を示す概念図である。
【図２】 ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートの図である。
【図２ａ】 ＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートの図である。
【図３】 実行されているＩＮＳＥＲＴ Ｏｐｅｒａｔｉｏｎの１事例の第１半部の概念図である。
【図４】 実行されているＩＮＳＥＲＴ Ｏｐｅｎａｔｉｏｎの１事例の第２半部の概念図である。
【図５】 ＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【図６】 ＲＥＭＯＶＥ Ｏｐｅｎａｔｉｏｎ の１事例の第１半部に対するフローチャートを表す図である。
【図７】 実行されているＲＥＭＯＶＥ Ｏｐｅｎａｔｉｏｎ の１事例の第２半部に対するフローチャートを表す図である。
【図８】 Ｅｘａｃｔ Ｍａｔｃｈ ＦＩＮＤ ＯｐｅｒａｔｉｏｎのＲＥＭＯＶＥ Ｏｐｅｒａｔｉｏｎ の有利な実施例に対するフローチャートを表す図である。
【図９】 Ｐａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの有利な実施例に対するフローチャートを表わす図である。
【図９ａ】 Ｐａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの有利な実施例に対するフローチャートを表わす図である。
【図１０】 実行されているＰａｒｔｉａｌ Ｍａｔｃｈ Ｆｉｎｄ Ｏｐｅｒａｔｉｏｎの事例を表す概略図である。
【図１１】 ＦＩ ｉｎｄｅｘｅｄ ｌｏｃｋ ｔａｂｌｅ を使用したロジカルロジックマネージメントを表す概念図である。
【符号の説明】
２ インデクスツリー
４ 根ノード
５ａ リーフノード
５ｂ リーフノード
６ａ キーストリングフィールド
６ｂ キーストリングフィールド
６ｃ キーストリングフィールド
６ｄ キーストリングフィールド
７ａ 情報フィールド
７ｂ 情報フィールド
７ｃ 情報フィールド
７ｄ 情報フィールド
８ 内部ノード
１０ 親ノード
１１ ｐｏｓ フィールド
１２ ｓｕｃｃ フィールド
１３ ｓｕｃｃＦｉｒｓｔ フィールド
１４ ｃｈ フィールド
１５ ｓｂｌＰｒｅｖ フィールド
１６ ｓｂｌＮｅｘｔ フィールド
１７ ローカルサクセッサハッシュ表
１８ ハッシュ表配列
１８ａ ハッシュバケット
１８ｂ ハッシュバケット
１８ｃ ハッシュバケット
１８ｄ ハッシュバケット
１９ ｈａｓｈＮｅｘｔ フィールド
２０ ｐａｒｅｎｔ フィールド
２１ ｐｏｓ フィールド
２２ ｓｕｃｃ フィールド
２４ａ ｃｈ フィールド
２４ｂ ｃｈ フィールド
２４ｃ ｃｈ フィールド
２４ｄ ｃｈ フィールド
２５ ｓｐｌＰｒｅｖ フィールド
２６ ｓｂｌＮｅｘｔ フィールド
２７ キーフィールド
２８ フィールド
２００ フローチャート
２０２ アロケーション
２０４ 参照
２０６ 判定
２０８ レジストレーション
２１０ レジストレーション
２１２ ルックアップ
２１４ アサインメント
２１６ アサインメント
２１８ アサインメント
２２０ 終端
２２２ 比較
２２４ トラバース横断
２３０ 判定
２３２ 判定
２３４ 判定
２４０ 外部ツリー構成
２４２ レジストレーション
２４４ 挿入
２４６ 挿入
２４８ 判定
２６０ 内部ツリー挿入
２６２ アロケーション
２６４ 挿入
２６６ 判定
２６８ レジストレーション
２７０ 挿入
２７２ 挿入
２８０ インクリメント
２８２ セッティング
２８４ リターン
３０２ インデクスツリー
３３１ ｐｏｓフィールド
３４０ ハッシュ表配列
３４１ ハッシュバケット
３５０ 参照
３６０ ブランチ
３７０ リンク
３８０ リンク
４０２ インデクスツリー
４０５ リーフノード
４０８ 内部ノード
４４０ メモリマネージャ
４６０ 参照
５００ フローチャート
５０４ 判定
５０６ セッティング
５０８ 除去
５１０ 除去
５１２ デクリメント
５２０ 判定
５２２ 判定
５２４ アサインメント割当
５２６ 連結、解離
５２８ 挿入
５３０ 除去
５４０ 判定
５４２ 削除
５５０ フリー解放
６０２ インデクスツリー
７０２ インデクスツリー
７１０ リーフノード
７２０ ｈａｓｈＮｅｘｔ フィールド
７５０ 参照
７６０ リンク
８００ フローチャート
８０２ 参照
８０４ 割当
８０６ 考慮
８０８ 検索
８１０ アサインメント
８２０ 比較
８２２ 終端
８２４ リターン
９００ フローチャート
９０４ 判定
９０６ リセット
９０８ リロード
９１０ 判定
９１１ 検索
９１２ 検索
９２０ リーフノード解析
９２２ 比較
９２８ 比較
９３０ 加算
９３１ アサインメント
９３２ 枝刈り（ｐｒｕｎｉｎｇ）
９３３ チェッキング
９３４ 除去
９５０ 内部ノード解析
９５２ アサインメント
９５４ ワイルドカード チェック
９５５ ルックアップ
９７０ プッシュ
１００２ インデクスツリー
１０１２ ノード
１０２０ ノード
１０３０ ノード
１０４０ ノード
１０５０ ノード
１０６０ ノード
１０７０ ノード
１０８０ ノード
１０９０ ノード
１１００ ノード
１１１０ ノード
１１２０ ノード
１２００ データベース
１２０１ ロックマネージャ
１２０２ ロックテーブル
Claims (23)
- 探索ツリーを使用することにより複数のストリングエントリのインデクシングを行う方法であって、前記の複数のストリングエントリのうちの各１つが複数キャラクタの１つのストリングであるようにした当該のインデクシング方法において、前記探索ツリーは、連結リンクされた節点を有し、前記の連結された節点ノードは、１つの根節点（４）及び複数の内部節点ノード並びに複数のリーフ節点ノード（５ａ，５ｂ，５ｃ，５ｄ）を有し、前記の内部節点ノードは、１つのキャラクタ又はキャラクタのサブストリングに関連付けられており、また前記のリーフ節点ノードは、前記の複数のストリングエントリに関連付けられており、ここで、前記の複数の内部節点ノードの各々は、更に、下記の要素（ａ）〜（ｅ）を有し、すなわち
（ａ） 親節点に対する参照を有し、ここで前記親節点ノードは、前記複数の内部ツリー節点ノードのうちの他の１つのもの又は、前記根節点ノード（４）であり、
（ｂ） キャラクタ比較位置を含む第１データフィールドを有し、前記キャラクタ比較位置は、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタの数を指示するものであり、
（ｃ） 比較キャラクタを含む第２データフィールドを有し、前記比較キャラクタは、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタが、前記キャラクタ比較位置に関連する前記ストリングエントリの１つのキャラクタ位置にて１つのストリングエントリ内に含まれているか否かを決定するため使用され、
（ｄ） 可変的な個数の少なくとも２つの後継者ノードへの参照を有し、
（ｅ） ツリーのトラバース走査の間に後継者ノードの中の高速ハッシュ探索を可能にするための相応の親節点ノードの後継者ノードへの参照を有するハッシュ表アレイ（１８）を有し、さらに所定数のハッシュバケット（１８ａ，１８ｂ，１８ｃ，１８ｄ）を有し、
キャラクタのストリングは、アルファニューメトリックキャラクタの１つのストリングであり、前記の複数のエントリのうちの少なくとも１つが１つのワイルドカードキャラクタを有し、該ワイルドカードキャラクタはキャラクタのストリングの任意の可変的な位置に又は複数のストリングエントリのうちの少なくとも１つの任意の可変的な位置に位置決めされることを特徴とするインデクシング法。 - 前記の複数のストリングエントリの各々におけるキャラクタの数が同じである、請求項１記載の方法。
- 前記の複数の内部ノードのうちの少なくとも１つが、１つのキャラクタ比較位置を有する親節点ノードに対する参照を有し、前記のキャラクタ比較位置は前記複数の内部ノードのうちの少なくとも１つのキャラクタ比較位置より少なくとも２だけ少ないものである、請求項１又は２記載の方法。
- 前記複数の内部節点ノードの各々が１つのレベルに関連付けられ、更に、前記レベルにも関連付けられた前記の複数のリンク連結された節点ノードのうちの少なくとも１つの参照リンクを有する、請求項１から３までのうちいずれか１項記載の方法。
- 前記参照リンクのうちの少なくともいくつかが２重リンク結合されたリストを形成するようにした、請求項４記載の方法。
- 前記探索ツリーの或１つの探索が、前記の複数の連結リンクされた節点ノードのうちの少なくともいくつかへの連結リンクを有する１つのスタックをマネージするための後入れ先出しメモリマネージャを利用する、請求項１から５までのうちいずれか１項記載の方法。
- 前記探索は、バックトラッキングを利用することを特徴とする請求項６記載の方法。
- 前記探索は、前記スタックの枝刈り（ｐｒｕｎｉｎｇ）を含む、請求項６又は７記載の方法。
- 複数のストリングの中から、複数のキャラクタから成る所定のストリングを探索する方法であって、前記複数ストリングの各々が複数キャラクタの１つのストリングであるようにした当該の探索方法において、前記方法は、下記ステップを有する、すなわち、
請求項１から８までのうちいずれか１項の方法により探索ツリーを生成するステップを有し、ここで、前記の複数のストリングは複数のストリングエントリを形成するものであり、
前記の所定のストリングに関連する問い合わせを形成するステップと、
前記の問い合わせを利用して前記探索ツリーをトラバース走査して前記の所定のストリングにマッチングする前記複数ストリングの任意のものに１つのインデックス索引を与えるステップを有することを特徴とする探索方法。 - 前記探索ツリーは、請求項２から８までのうちいずれか１項記載の方法により生成されるようにした、請求項９記載の方法。
- 前記の所定のストリングは、複数のアルファニュートリックキャラクタ及び少なくとも１つのワイルドカードから成るようにした、請求項９又は１０記載の方法。
- 前記のトラバース走査プロセスは、前記の複数の連結リンクされた節点ノードのうち少なくともいくつかへの連結ノードを有する１つのスタックをマネージするための後入れ先出しメモリマネージャを利用する、請求項９から１１までのうちいずれか１項記載の方法。
- 前記トラバース走査プロセスは、バックトラキングを利用する、請求項１２記載の方法。
- 前記トラバース走査は、前記スタックの枝刈り（ｐｒｕｎｉｎｇ）を利用するようにした、請求項１２又は１３記載の方法。
- 請求項９から１４までのうちいずれか１項記載の、複数のストリングの中から、複数のキャラクタからなる所定のストリングを探索する方法において、探索ツリーを生成し、前記の所定のストリングに関連する問い合わせを形成するステップは、次の事項上へ実行される、すなわち、ヒューマンリソースマネージメント、ファイナンシャルズ、ロジスティックスビジネスワークフロー、人事マネージメント、組織マネージメント、ペイロールアカウンティング、タイムマネージメント、人事開発又はネットワーク、例えばインターネット又はイントラネット、システム、例えばＲ／３システム上へ実行される、請求項９から１４までのうちいずれか１項記載の方法。
- 複数のインストラクションの記憶されているコンピュータによりリード可能な（ｃｏｍｐｕｔｅｒ―ｒｅａｄａｂｌｅ）媒体において、
前記の複数のインストラクションは、プロセッサにより実行されると、前記プロセッサをして下記のステップを実行させるインストラクションを含む、すなわち、
請求項の１から８のうちいずれか１項記載の方法により、複数のストリングエントリのインデクシングをするステップを実行させるステップを有することを特徴とするコンピュータによりリード可能な媒体。 - 複数のインストラクションの記憶されているコンピュータによりリード可能な（ｃｏｍｐｕｔｅｒ―ｒｅａｄａｂｌｅ）媒体において、
前記の複数のインストラクションは、プロセッサにより実行されると、前記プロセッサをして下記のステップを実行させるインストラクションを含む、すなわち、
請求項の９から１５のうちいずれか１項記載の方法により、所定のストリングの探索サーチを実行させるステップを有することを特徴とするコンピュータによりリード可能な媒体。 - 複数のストリングの中から、複数のキャラクタから成る１つの所定のストリングを探索するシステムであって、前記の複数のストリングの各々が、複数キャラクタの１つのストリングであるようにした当該の探索システムにおいて、
前記探索システムは、下記要件を有し、すなわち、
探索ツリーを生成する手段を有し、前記探索ツリーは、下記節点ノードを有し、すなわち、１つの根節点ノード（４）及び複数の内部節点ノード並びに、複数のリーフ節点ノード（５ａ，５ｂ，５ｃ，５ｄ，）を有し、前記の内部節点ノードは、１つのキャラクタ又はキャラクタのサブストリングに関連付けられており、前記のリーフ節点ノード（５ａ，５ｂ，５ｃ，５ｄ）はまた、前記のストリングエントリに関連付けられており、ここで、前記の複数の内部節点ノードの各々は、更に、下記の要素（ａ）〜（ｅ）を有し、すなわち、
（ａ） 親節点ノードに対する参照を有し、ここで前記親節点ノードは、前記複数の内部ツリー節点ノードのうちの他の１つのもの又は、前記根節点ノード（４）であり、
（ｂ） キャラクタ比較位置を含む第１のデータフィールドを有し、前記キャラクタ比較位置は、前記キャラクタ又は、前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタの数を指示するものであり、
（ｃ） 比較キャラクタを含む第２データフィールドを有し、前記比較キャラクタは、前記キャラクタ又は前記複数の内部節点ノードのうちの前記の１つに関連するキャラクタのサブストリングにおけるキャラクタが、前記キャラクタ比較位置に関連するストリングエントリの１つのキャラクタ位置にて１つのストリングエントリ内に含まれているか否かを決定するため使用され、
（ｄ） 可変的な個数の少なくとも２つの後継者ノードへの参照を有し、
（ｅ） ツリーのトラバース走査の間に後継者ノードの中の高速ハッシュ探索を可能にするための相応の親節点ノードの後継者ノードへの参照を有するハッシュ表アレイ（１８）を有し、さらに所定数のハッシュバケット（１８ａ，１８ｂ，１８ｃ，１８ｄ）を有し、
キャラクタのストリングは、アルファニューメトリックキャラクタの１つのストリングであり、前記の複数のエントリのうちの少なくとも１つが１つのワイルドカードキャラクタを有し、該ワイルドカードキャラクタはキャラクタのストリングの任意の可変的な位置に又は複数のストリングエントリのうちの少なくとも１つの任意の可変的な位置に位置決めされ；
前記の１つの所定のストリングに関連付けられた問い合わせを提出するための手段を有し；
前記の１つの所定のストリングにマッチングする前記の複数のストリングのうちの任意の１つにインデックスを提供するためのツリートラバース走査手段を有するようにした、複数のストリングの中から、複数のキャラクタから成る１つの所定のストリングを探索するシステム。 - 前記の複数のストリングエントリの各々におけるキャラクタの数が同じである、請求項１８記載のシステム。
- 前記の複数の内部ノードのうちの少なくとも１つが、或１つのキャラクタ比較位置を有する親節点ノードに対する参照を有し、前記のキャラクタ比較位置は前記複数の内部ノードのうちの少なくとも１つのキャラクタ比較位置より少なくとも２だけ少ないものである、請求項１８又は１９記載のシステム。
- 前記複数の内部節点ノードの各々が１つのレベルに関連付けられ、更に、前記レベルにも関連付けられた前記の複数のリンク連結された節点ノードのうちの少なくとも１つの参照リンクを有する、請求項１８から２０までのうちいずれか１項記載のシステム。
- 前記の所定のストリングは複数のアルファニューメリックキャラクタ及び少なくとも１つのワイルドカードから成る、請求項１８から２１までのうちいずれか１項記載のシステム。
- ダイナミックロックテーブル（１２０２）を用いた衝突検出又は衝突マネージメントを有する、請求項１８から２２までのうちいずれか１項記載のシステム。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/031,285 | 1998-02-26 | ||
| US09/031,285 US6047283A (en) | 1998-02-26 | 1998-02-26 | Fast string searching and indexing using a search tree having a plurality of linked nodes |
| PCT/EP1999/001210 WO1999044151A1 (en) | 1998-02-26 | 1999-02-25 | Fast string searching and indexing |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005178627A Division JP3947202B2 (ja) | 1998-02-26 | 2005-06-17 | 複数のストリングエントリを含むデータベースをアクセスするいくつかのユーザのリクエストの衝突検出又は衝突マネージメントのための方法、とりわけ、ロックマネージメントのための方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002505481A JP2002505481A (ja) | 2002-02-19 |
| JP3735683B2 true JP3735683B2 (ja) | 2006-01-18 |
Family
ID=21858597
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000533833A Expired - Lifetime JP3735683B2 (ja) | 1998-02-26 | 1999-02-25 | 高速探索サーチ及びインデクシング法 |
| JP2005178627A Expired - Lifetime JP3947202B2 (ja) | 1998-02-26 | 2005-06-17 | 複数のストリングエントリを含むデータベースをアクセスするいくつかのユーザのリクエストの衝突検出又は衝突マネージメントのための方法、とりわけ、ロックマネージメントのための方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2005178627A Expired - Lifetime JP3947202B2 (ja) | 1998-02-26 | 2005-06-17 | 複数のストリングエントリを含むデータベースをアクセスするいくつかのユーザのリクエストの衝突検出又は衝突マネージメントのための方法、とりわけ、ロックマネージメントのための方法 |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US6047283A (ja) |
| EP (1) | EP1066570B1 (ja) |
| JP (2) | JP3735683B2 (ja) |
| AT (1) | ATE253242T1 (ja) |
| AU (1) | AU762980B2 (ja) |
| CA (1) | CA2316936C (ja) |
| DE (1) | DE69912410T2 (ja) |
| IL (1) | IL137693A (ja) |
| WO (1) | WO1999044151A1 (ja) |
Families Citing this family (149)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6507678B2 (en) * | 1998-06-19 | 2003-01-14 | Fujitsu Limited | Apparatus and method for retrieving character string based on classification of character |
| US6594701B1 (en) | 1998-08-04 | 2003-07-15 | Microsoft Corporation | Credit-based methods and systems for controlling data flow between a sender and a receiver with reduced copying of data |
| US6321276B1 (en) | 1998-08-04 | 2001-11-20 | Microsoft Corporation | Recoverable methods and systems for processing input/output requests including virtual memory addresses |
| US6360220B1 (en) * | 1998-08-04 | 2002-03-19 | Microsoft Corporation | Lock-free methods and systems for accessing and storing information in an indexed computer data structure having modifiable entries |
| US6321232B1 (en) * | 1998-12-18 | 2001-11-20 | Xerox Corporation | Method for creating a geometric hash tree in a document processing system |
| US6625592B1 (en) * | 1999-08-10 | 2003-09-23 | Harris-Exigent, Inc. | System and method for hash scanning of shared memory interfaces |
| US6493813B1 (en) * | 1999-10-15 | 2002-12-10 | Neocore, Inc. | Method for forming a hashing code |
| US6675157B1 (en) * | 1999-11-01 | 2004-01-06 | International Business Machines Corporation | System and method for balancing binary search trees |
| US7246120B2 (en) | 2000-01-28 | 2007-07-17 | Oracle International Corporation | Techniques for achieving higher availability of resources during reconfiguration of a cluster |
| US6920454B1 (en) | 2000-01-28 | 2005-07-19 | Oracle International Corporation | Techniques for DLM optimization with transferring lock information |
| US6529906B1 (en) * | 2000-01-28 | 2003-03-04 | Oracle Corporation | Techniques for DLM optimization with re-mastering events |
| US6751616B1 (en) | 2000-01-28 | 2004-06-15 | Oracle International Corp. | Techniques for DLM optimization with re-mapping responsibility for lock management |
| US6675163B1 (en) * | 2000-04-06 | 2004-01-06 | International Business Machines Corporation | Full match (FM) search algorithm implementation for a network processor |
| US6556990B1 (en) * | 2000-05-16 | 2003-04-29 | Sun Microsystems, Inc. | Method and apparatus for facilitating wildcard searches within a relational database |
| US6963876B2 (en) | 2000-06-05 | 2005-11-08 | International Business Machines Corporation | System and method for searching extended regular expressions |
| US6611837B2 (en) | 2000-06-05 | 2003-08-26 | International Business Machines Corporation | System and method for managing hierarchical objects |
| FR2811101B1 (fr) * | 2000-07-03 | 2002-09-20 | Axicare | Procede de traitement de donnees structurees utilisant un langage informatique oriente objet |
| US6553370B1 (en) * | 2000-10-04 | 2003-04-22 | Lsi Logic Corporation | Flexible search engine having sorted binary search tree for perfect match |
| GB2406679B (en) * | 2000-11-30 | 2005-05-18 | Coppereye Ltd | Database |
| US7406443B1 (en) * | 2000-12-18 | 2008-07-29 | Powerloom | Method and system for multi-dimensional trading |
| US7047420B2 (en) * | 2001-01-17 | 2006-05-16 | Microsoft Corporation | Exclusive encryption |
| US20020099583A1 (en) * | 2001-01-24 | 2002-07-25 | Matusek Lawrence W. | Architecture and techniques for providing product configurations to an enterprise resource planner |
| US6738779B1 (en) | 2001-02-21 | 2004-05-18 | Telecom Italia S.P.A. | Apparatus for and method of multiple parallel string searching |
| US7043637B2 (en) | 2001-03-21 | 2006-05-09 | Microsoft Corporation | On-disk file format for a serverless distributed file system |
| US7062490B2 (en) * | 2001-03-26 | 2006-06-13 | Microsoft Corporation | Serverless distributed file system |
| US6981138B2 (en) * | 2001-03-26 | 2005-12-27 | Microsoft Corporation | Encrypted key cache |
| US6785677B1 (en) | 2001-05-02 | 2004-08-31 | Unisys Corporation | Method for execution of query to search strings of characters that match pattern with a target string utilizing bit vector |
| US6785699B1 (en) * | 2001-05-04 | 2004-08-31 | Lsi Logic Corporation | Prefix comparator |
| US6988124B2 (en) | 2001-06-06 | 2006-01-17 | Microsoft Corporation | Locating potentially identical objects across multiple computers based on stochastic partitioning of workload |
| US6751627B2 (en) * | 2001-07-23 | 2004-06-15 | Networks Associates Technology, Inc. | Method and apparatus to facilitate accessing data in network management protocol tables |
| US8249885B2 (en) * | 2001-08-08 | 2012-08-21 | Gary Charles Berkowitz | Knowledge-based e-catalog procurement system and method |
| US20030084031A1 (en) * | 2001-10-31 | 2003-05-01 | Tarquini Richard P. | System and method for searching a signature set for a target signature |
| GB2391679B (en) | 2002-02-04 | 2004-03-24 | Zentian Ltd | Speech recognition circuit using parallel processors |
| US6842750B2 (en) * | 2002-03-27 | 2005-01-11 | Lsi Logic Corporation | Symbolic simulation driven netlist simplification |
| US6941314B2 (en) * | 2002-04-15 | 2005-09-06 | Lsi Logic Corporation | User selectable editing protocol for fast flexible search engine |
| US6931413B2 (en) * | 2002-06-25 | 2005-08-16 | Microsoft Corporation | System and method providing automated margin tree analysis and processing of sampled data |
| US6934252B2 (en) * | 2002-09-16 | 2005-08-23 | North Carolina State University | Methods and systems for fast binary network address lookups using parent node information stored in routing table entries |
| US7472114B1 (en) * | 2002-09-18 | 2008-12-30 | Symantec Corporation | Method and apparatus to define the scope of a search for information from a tabular data source |
| US8661498B2 (en) * | 2002-09-18 | 2014-02-25 | Symantec Corporation | Secure and scalable detection of preselected data embedded in electronically transmitted messages |
| US7886359B2 (en) * | 2002-09-18 | 2011-02-08 | Symantec Corporation | Method and apparatus to report policy violations in messages |
| US8225371B2 (en) | 2002-09-18 | 2012-07-17 | Symantec Corporation | Method and apparatus for creating an information security policy based on a pre-configured template |
| US8041719B2 (en) * | 2003-05-06 | 2011-10-18 | Symantec Corporation | Personal computing device-based mechanism to detect preselected data |
| US7673344B1 (en) * | 2002-09-18 | 2010-03-02 | Symantec Corporation | Mechanism to search information content for preselected data |
| JP4091604B2 (ja) * | 2002-10-03 | 2008-05-28 | 株式会社インフォーエス | ビットストリングの照合方法および装置 |
| US7315862B1 (en) * | 2002-12-20 | 2008-01-01 | Nortel Networks Limited | Concurrent lock-free access to a record by write and read processes |
| US7451144B1 (en) * | 2003-02-25 | 2008-11-11 | At&T Corp. | Method of pattern searching |
| US7774191B2 (en) * | 2003-04-09 | 2010-08-10 | Gary Charles Berkowitz | Virtual supercomputer |
| US7447786B2 (en) * | 2003-05-09 | 2008-11-04 | Oracle International Corporation | Efficient locking of shared data that is accessed for reads in a cluster database |
| US20050065964A1 (en) * | 2003-09-19 | 2005-03-24 | Ziemann David M. | Update of a tree-based database |
| CA2453973A1 (en) * | 2003-12-23 | 2005-06-23 | Daniel A. Rose | On-demand creation of posix locale source |
| CA2453971C (en) * | 2003-12-23 | 2009-08-11 | Daniel A. Rose | On-demand creation of java locale source |
| US7379952B2 (en) * | 2004-01-30 | 2008-05-27 | Oracle International Corporation | Techniques for multiple window resource remastering among nodes of a cluster |
| EP1566744A1 (en) * | 2004-02-19 | 2005-08-24 | Sap Ag | Optimising lock granularity using range locking |
| US7536467B2 (en) * | 2004-04-20 | 2009-05-19 | Microsoft Corporation | Peer-to-peer (P2P) mobility system, and method |
| US8176051B2 (en) * | 2004-05-27 | 2012-05-08 | International Business Machines Corporation | Search via fast case insensitive ASCII tree |
| US20060036627A1 (en) * | 2004-08-06 | 2006-02-16 | Roger Deran | Method and apparatus for a restartable hash in a trie |
| CN100442277C (zh) * | 2004-08-24 | 2008-12-10 | 侯方勇 | 优化哈希树完整性校验的方法 |
| US8301788B2 (en) * | 2004-09-10 | 2012-10-30 | Cavium, Inc. | Deterministic finite automata (DFA) instruction |
| US8560475B2 (en) | 2004-09-10 | 2013-10-15 | Cavium, Inc. | Content search mechanism that uses a deterministic finite automata (DFA) graph, a DFA state machine, and a walker process |
| US8392590B2 (en) * | 2004-09-10 | 2013-03-05 | Cavium, Inc. | Deterministic finite automata (DFA) processing |
| EP1684194A1 (en) * | 2005-01-25 | 2006-07-26 | Sap Ag | A central lock service for database applications |
| US20060167845A1 (en) * | 2005-01-25 | 2006-07-27 | International Business Machines Corporation | Selection of optimal plans for FIRST-N-ROW queries |
| US7539694B1 (en) | 2005-02-04 | 2009-05-26 | Marvell International Ltd. | Concurrently searching and manipulating binary trees |
| US20060184549A1 (en) * | 2005-02-14 | 2006-08-17 | Rowney Kevin T | Method and apparatus for modifying messages based on the presence of pre-selected data |
| US8011003B2 (en) * | 2005-02-14 | 2011-08-30 | Symantec Corporation | Method and apparatus for handling messages containing pre-selected data |
| US8683020B2 (en) * | 2005-02-26 | 2014-03-25 | Coco Communications Corp. | Naming system layer |
| US20060200469A1 (en) * | 2005-03-02 | 2006-09-07 | Lakshminarayanan Chidambaran | Global session identifiers in a multi-node system |
| US7209990B2 (en) * | 2005-04-05 | 2007-04-24 | Oracle International Corporation | Maintain fairness of resource allocation in a multi-node environment |
| US7634407B2 (en) * | 2005-05-20 | 2009-12-15 | Microsoft Corporation | Method and apparatus for indexing speech |
| CA2975694C (en) | 2005-07-15 | 2020-12-08 | Indxit Systems, Inc. | Systems and methods for data indexing and processing |
| US20070027848A1 (en) * | 2005-07-29 | 2007-02-01 | Microsoft Corporation | Smart search for accessing options |
| US8402007B2 (en) * | 2005-08-02 | 2013-03-19 | The Boeing Company | Methods and apparatus for creating and utilizing templates in connection with information modeling |
| US10140387B2 (en) | 2005-08-02 | 2018-11-27 | The Boeing Company | Model for managing variations in a product structure for a product |
| US8275799B2 (en) * | 2005-08-02 | 2012-09-25 | The Boeing Company | Methods and apparatus for information modeling |
| US8095549B2 (en) * | 2005-10-05 | 2012-01-10 | Intel Corporation | Searching for strings in messages |
| US7809568B2 (en) * | 2005-11-08 | 2010-10-05 | Microsoft Corporation | Indexing and searching speech with text meta-data |
| US7831428B2 (en) * | 2005-11-09 | 2010-11-09 | Microsoft Corporation | Speech index pruning |
| US7831425B2 (en) * | 2005-12-15 | 2010-11-09 | Microsoft Corporation | Time-anchored posterior indexing of speech |
| US8589574B1 (en) * | 2005-12-29 | 2013-11-19 | Amazon Technologies, Inc. | Dynamic application instance discovery and state management within a distributed system |
| US7702640B1 (en) * | 2005-12-29 | 2010-04-20 | Amazon Technologies, Inc. | Stratified unbalanced trees for indexing of data items within a computer system |
| US20070214153A1 (en) * | 2006-03-10 | 2007-09-13 | Mazzagatti Jane C | Method for processing an input particle stream for creating upper levels of KStore |
| US20070220069A1 (en) * | 2006-03-20 | 2007-09-20 | Mazzagatti Jane C | Method for processing an input particle stream for creating lower levels of a KStore |
| US8238351B2 (en) * | 2006-04-04 | 2012-08-07 | Unisys Corporation | Method for determining a most probable K location |
| US20070282816A1 (en) * | 2006-06-05 | 2007-12-06 | Shing-Jung Tsai | Method and structure for string partial search |
| US7895211B2 (en) * | 2006-11-03 | 2011-02-22 | International Business Machines Corporation | Method and system for reinserting a chain in a hash table |
| EP1973054A1 (en) * | 2007-03-20 | 2008-09-24 | Sap Ag | Workflow authorizations evaluation in multi-layered applications |
| US7822927B1 (en) * | 2007-05-14 | 2010-10-26 | Emc Corporation | Dynamically configurable reverse DNLC lookup |
| US7823761B2 (en) * | 2007-05-16 | 2010-11-02 | The Invention Science Fund I, Llc | Maneuverable surgical stapler |
| US20090006402A1 (en) * | 2007-06-28 | 2009-01-01 | Holger Bohle | Methods and systems for the dynamic selection of a locking strategy |
| US8819217B2 (en) * | 2007-11-01 | 2014-08-26 | Cavium, Inc. | Intelligent graph walking |
| US7949683B2 (en) * | 2007-11-27 | 2011-05-24 | Cavium Networks, Inc. | Method and apparatus for traversing a compressed deterministic finite automata (DFA) graph |
| US8180803B2 (en) * | 2007-11-27 | 2012-05-15 | Cavium, Inc. | Deterministic finite automata (DFA) graph compression |
| JP2011511366A (ja) * | 2008-02-01 | 2011-04-07 | ジ・オリバー・グループ・リミテッド・ライアビリティ・カンパニー | データの検索および索引付けの方法およびそれを実施するシステム |
| US8065739B1 (en) | 2008-03-28 | 2011-11-22 | Symantec Corporation | Detecting policy violations in information content containing data in a character-based language |
| US7996374B1 (en) | 2008-03-28 | 2011-08-09 | Symantec Corporation | Method and apparatus for automatically correlating related incidents of policy violations |
| US7996373B1 (en) | 2008-03-28 | 2011-08-09 | Symantec Corporation | Method and apparatus for detecting policy violations in a data repository having an arbitrary data schema |
| US8131729B2 (en) * | 2008-06-12 | 2012-03-06 | International Business Machines Corporation | System and method for best-fit lookup of multi-field key |
| US8826443B1 (en) | 2008-09-18 | 2014-09-02 | Symantec Corporation | Selective removal of protected content from web requests sent to an interactive website |
| JP5339507B2 (ja) * | 2008-10-01 | 2013-11-13 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 木構造を探索する方法 |
| US8473523B2 (en) | 2008-10-31 | 2013-06-25 | Cavium, Inc. | Deterministic finite automata graph traversal with nodal bit mapping |
| US8613040B2 (en) * | 2008-12-22 | 2013-12-17 | Symantec Corporation | Adaptive data loss prevention policies |
| US8280723B1 (en) * | 2009-01-29 | 2012-10-02 | Intuit Inc. | Technique for comparing a string to large sets of strings |
| CN101807188A (zh) * | 2009-02-18 | 2010-08-18 | 北京金远见电脑技术有限公司 | 用于任意规模词典的完美哈希函数构造方法及系统 |
| JP4852621B2 (ja) * | 2009-03-03 | 2012-01-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | プログラム中のオブジェクトの割り付け場所を追跡する方法、並びにそのコンピュータ・システム及びコンピュータ・プログラム |
| US8176080B2 (en) * | 2009-03-06 | 2012-05-08 | Hewlett-Packard Development Company, L.P. | Desensitizing character strings |
| US8935752B1 (en) | 2009-03-23 | 2015-01-13 | Symantec Corporation | System and method for identity consolidation |
| US8671265B2 (en) | 2010-03-05 | 2014-03-11 | Solidfire, Inc. | Distributed data storage system providing de-duplication of data using block identifiers |
| CN102193941B (zh) * | 2010-03-12 | 2013-09-18 | 富士通株式会社 | 数据处理装置和为值串形式索引值建立索引的方法 |
| US8204887B2 (en) | 2010-08-27 | 2012-06-19 | Hewlett-Packard Development Company, L.P. | System and method for subsequence matching |
| US8577891B2 (en) * | 2010-10-27 | 2013-11-05 | Apple Inc. | Methods for indexing and searching based on language locale |
| US8407245B2 (en) * | 2010-11-24 | 2013-03-26 | Microsoft Corporation | Efficient string pattern matching for large pattern sets |
| CN102024046B (zh) * | 2010-12-14 | 2013-04-24 | 华为数字技术（成都）有限公司 | 数据重复性校验方法和装置及系统 |
| JPWO2012081165A1 (ja) * | 2010-12-16 | 2014-05-22 | 日本電気株式会社 | データベース管理装置及びデータベース管理方法 |
| US20120222051A1 (en) * | 2011-02-25 | 2012-08-30 | Microsoft Corporation | Shared resource access verification |
| US20120254251A1 (en) * | 2011-03-03 | 2012-10-04 | The Governors Of The University Of Alberta | SYSTEMS AND METHODS FOR EFFICIENT TOP-k APPROXIMATE SUBTREE MATCHING |
| US8493249B2 (en) | 2011-06-03 | 2013-07-23 | Microsoft Corporation | Compression match enumeration |
| US9251289B2 (en) | 2011-09-09 | 2016-02-02 | Microsoft Technology Licensing, Llc | Matching target strings to known strings |
| US8626543B2 (en) * | 2011-10-08 | 2014-01-07 | Sap Ag | Tracing software execution of a business process |
| US9838269B2 (en) | 2011-12-27 | 2017-12-05 | Netapp, Inc. | Proportional quality of service based on client usage and system metrics |
| US9054992B2 (en) | 2011-12-27 | 2015-06-09 | Solidfire, Inc. | Quality of service policy sets |
| JP5912714B2 (ja) * | 2012-03-21 | 2016-04-27 | 任天堂株式会社 | データ構造、データ構造生成方法、情報処理装置、情報処理システム、及び情報処理プログラム |
| EP2853049B1 (en) * | 2012-05-23 | 2019-01-09 | Telefonaktiebolaget LM Ericsson (publ) | Thermal noise floor estimation |
| US8688685B2 (en) * | 2012-06-15 | 2014-04-01 | Sap Ag | Accelerated searching of substrings |
| US9400816B1 (en) * | 2013-02-28 | 2016-07-26 | Google Inc. | System for indexing collections of structured objects that provides strong multiversioning semantics |
| WO2014165040A1 (en) | 2013-03-13 | 2014-10-09 | Veriscape, Inc. | Dynamic memory management for a virtual supercomputer |
| US9826463B2 (en) | 2013-12-18 | 2017-11-21 | Qualcomm Incorporated | Hash partial matching for discovery |
| US20150244795A1 (en) | 2014-02-21 | 2015-08-27 | Solidfire, Inc. | Data syncing in a distributed system |
| CN105096294B (zh) * | 2014-04-30 | 2019-01-18 | 西门子医疗保健诊断公司 | 用于对尿液沉渣图像的待处理区块进行区块检索的方法和装置 |
| JP6390239B2 (ja) | 2014-07-25 | 2018-09-19 | 富士ゼロックス株式会社 | 情報処理装置、及びプログラム |
| US10891272B2 (en) | 2014-09-26 | 2021-01-12 | Oracle International Corporation | Declarative language and visualization system for recommended data transformations and repairs |
| US10210246B2 (en) * | 2014-09-26 | 2019-02-19 | Oracle International Corporation | Techniques for similarity analysis and data enrichment using knowledge sources |
| US10976907B2 (en) | 2014-09-26 | 2021-04-13 | Oracle International Corporation | Declarative external data source importation, exportation, and metadata reflection utilizing http and HDFS protocols |
| US10216966B2 (en) * | 2015-02-25 | 2019-02-26 | Netapp, Inc. | Perturb key technique |
| US10540512B2 (en) * | 2015-09-29 | 2020-01-21 | International Business Machines Corporation | Exception preserving parallel data processing of string and unstructured text |
| US10706608B2 (en) | 2016-01-19 | 2020-07-07 | Nvidia Corporation | Tree traversal with backtracking in constant time |
| RU2620996C1 (ru) * | 2016-02-18 | 2017-05-30 | Акционерное общество "Лаборатория Касперского" | Способ поиска входной строки в дереве поиска с индексацией используемых при построении дерева строк |
| US10929022B2 (en) | 2016-04-25 | 2021-02-23 | Netapp. Inc. | Space savings reporting for storage system supporting snapshot and clones |
| US10241998B1 (en) * | 2016-06-29 | 2019-03-26 | EMC IP Holding Company LLC | Method and system for tokenizing documents |
| US10642763B2 (en) | 2016-09-20 | 2020-05-05 | Netapp, Inc. | Quality of service policy sets |
| WO2018125267A1 (en) * | 2016-12-27 | 2018-07-05 | Obie Tech, Llc | Enhanced communication using variable length strings of alphanumerics, symbols, and other input |
| US10810472B2 (en) | 2017-05-26 | 2020-10-20 | Oracle International Corporation | Techniques for sentiment analysis of data using a convolutional neural network and a co-occurrence network |
| US10459810B2 (en) | 2017-07-06 | 2019-10-29 | Oracle International Corporation | Technique for higher availability in a multi-node system using replicated lock information to determine a set of data blocks for recovery |
| US10885056B2 (en) | 2017-09-29 | 2021-01-05 | Oracle International Corporation | Data standardization techniques |
| US10936599B2 (en) | 2017-09-29 | 2021-03-02 | Oracle International Corporation | Adaptive recommendations |
| US11270339B1 (en) * | 2018-08-21 | 2022-03-08 | Amdocs Development Limited | System, method, and computer program for using full and partial dynamic customer criteria sets for targeting promotions |
| US11068541B2 (en) | 2019-02-15 | 2021-07-20 | International Business Machines Corporation | Vector string search instruction |
| US11119999B2 (en) | 2019-07-24 | 2021-09-14 | Sap Se | Zero-overhead hash filters |
| EP4095640A1 (en) * | 2021-05-26 | 2022-11-30 | Volvo Autonomous Solutions AB | Method and system for controlling a plurality of vehicles, in particular autonomous vehicles |
| CN114090570B (zh) * | 2021-09-29 | 2024-08-27 | 北京信息科技大学 | 一种基于基数树与哈希表结合的数据存储方法及装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5202986A (en) * | 1989-09-28 | 1993-04-13 | Bull Hn Information Systems Inc. | Prefix search tree partial key branching |
| US5745902A (en) * | 1992-07-06 | 1998-04-28 | Microsoft Corporation | Method and system for accessing a file using file names having different file name formats |
| US5787430A (en) * | 1994-06-30 | 1998-07-28 | International Business Machines Corporation | Variable length data sequence backtracking a trie structure |
| US5613110A (en) * | 1995-01-05 | 1997-03-18 | International Business Machines Corporation | Indexing method and apparatus facilitating a binary search of digital data |
| US5748952A (en) * | 1995-05-10 | 1998-05-05 | International Business Machines Corporation | System and method for avoiding complete index tree traversals in sequential and almost sequential index probes |
| US5778361A (en) * | 1995-09-29 | 1998-07-07 | Microsoft Corporation | Method and system for fast indexing and searching of text in compound-word languages |
| US5893086A (en) * | 1997-07-11 | 1999-04-06 | International Business Machines Corporation | Parallel file system and method with extensible hashing |
-
1998
- 1998-02-26 US US09/031,285 patent/US6047283A/en not_active Expired - Lifetime
-
1999
- 1999-02-25 AU AU28357/99A patent/AU762980B2/en not_active Expired
- 1999-02-25 DE DE69912410T patent/DE69912410T2/de not_active Expired - Lifetime
- 1999-02-25 AT AT99908946T patent/ATE253242T1/de not_active IP Right Cessation
- 1999-02-25 EP EP99908946A patent/EP1066570B1/en not_active Expired - Lifetime
- 1999-02-25 CA CA002316936A patent/CA2316936C/en not_active Expired - Lifetime
- 1999-02-25 IL IL13769399A patent/IL137693A/xx not_active IP Right Cessation
- 1999-02-25 JP JP2000533833A patent/JP3735683B2/ja not_active Expired - Lifetime
- 1999-02-25 WO PCT/EP1999/001210 patent/WO1999044151A1/en active IP Right Grant
-
2005
- 2005-06-17 JP JP2005178627A patent/JP3947202B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| IL137693A (en) | 2005-08-31 |
| WO1999044151A1 (en) | 1999-09-02 |
| JP2002505481A (ja) | 2002-02-19 |
| US6047283A (en) | 2000-04-04 |
| ATE253242T1 (de) | 2003-11-15 |
| CA2316936A1 (en) | 1999-09-02 |
| DE69912410T2 (de) | 2004-08-19 |
| AU2835799A (en) | 1999-09-15 |
| EP1066570A1 (en) | 2001-01-10 |
| IL137693A0 (en) | 2001-10-31 |
| CA2316936C (en) | 2004-04-20 |
| JP2006004439A (ja) | 2006-01-05 |
| AU762980B2 (en) | 2003-07-10 |
| EP1066570B1 (en) | 2003-10-29 |
| JP3947202B2 (ja) | 2007-07-18 |
| DE69912410D1 (de) | 2003-12-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3735683B2 (ja) | 高速探索サーチ及びインデクシング法 | |
| US8060521B2 (en) | Systems and methods of directory entry encodings | |
| CA2237161C (en) | Storage and retrieval of ordered sets of keys in a compact 0-complete tree | |
| Coffman Jr et al. | File structures using hashing functions | |
| CN111801665B (zh) | 用于大数据应用的分层局部敏感哈希(lsh)分区索引 | |
| US20070005589A1 (en) | Method and apparatus for document clustering and document sketching | |
| AU2004225060B2 (en) | A computer implemented compact 0-complete tree dynamic storage structure and method of processing stored data | |
| WO1999052098A2 (en) | Deletion of ordered sets of keys in a compact 0-complete tree | |
| Lin et al. | Learning augmented binary search trees | |
| Ferragina et al. | Optimal on-line search and sublinear time update in string matching | |
| US20120054196A1 (en) | System and method for subsequence matching | |
| Ferragina et al. | Learned monotone minimal perfect hashing | |
| Orlandic et al. | Analysis of compact 0-complete trees: A new access method to large databases | |
| Comer | English dictionary searching with little extra space | |
| Masud et al. | A hashing technique using separate binary tree | |
| Arslan | Efficient approximate dictionary look-up for long words over small alphabets | |
| Gonzalez | Online Dictionary Structures | |
| Tamassia et al. | Basic data structures | |
| Shishibori et al. | Improvement of binary digital search trees using hierarchical structures | |
| Kar | Construction of optimal indexes | |
| Egdø | Iterators for the trie data structure |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041217 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050314 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050322 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050617 |
|
| 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: 20050902 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20051003 |
|
| 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: 20091104 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091104 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101104 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111104 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111104 Year of fee payment: 6 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121104 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121104 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131104 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |