DE69912410T2 - Schnelles zeichenkettensuchen und -indizieren - Google Patents

Schnelles zeichenkettensuchen und -indizieren Download PDF

Info

Publication number
DE69912410T2
DE69912410T2 DE69912410T DE69912410T DE69912410T2 DE 69912410 T2 DE69912410 T2 DE 69912410T2 DE 69912410 T DE69912410 T DE 69912410T DE 69912410 T DE69912410 T DE 69912410T DE 69912410 T2 DE69912410 T2 DE 69912410T2
Authority
DE
Germany
Prior art keywords
character
node
sequence
search
nodes
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
Application number
DE69912410T
Other languages
English (en)
Other versions
DE69912410D1 (de
Inventor
Bernhard Braun
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Application granted granted Critical
Publication of DE69912410D1 publication Critical patent/DE69912410D1/de
Publication of DE69912410T2 publication Critical patent/DE69912410T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

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

Description

  • Gebiet der Erfindung
  • Diese Erfindung bezieht sich allgemein auf die Pflege von Datenbanken und insbesondere auf das Indexieren und Suchen von digitalen Datenfolgen.
  • Hintergrund
  • Seit Jahrzehnten entdecken Computerprogrammierer und Wissenschaftler neue und effizientere Wege, um Datenbanken zu pflegen und um ihren Inhalt zu durchsuchen. Gebräuchliche Techniken zum Durchführen von Suchvorgängen umfassen das lineare Suchen, Hashing und binäre Suchbäume.
  • Die lineare Suchtechnik ist das grundlegendste Verfahren zum Durchführen einer Suche nach Schlüsseln oder Folgen (der Begriff "Folge" wird verwendet, um eine Gruppe alphanumerischer oder binärer Zeichen zu beschreiben). Diese direkte Methode durchläuft eine Schleife über alle existierenden Folgen, die üblicherweise in einem Feld oder in einer linearen verknüpften Liste organisiert sind, wobei jede Folge Ki mit der angefragten Folge K verglichen wird. Eine lineare Suche kann durch den folgenden Pseudo-Code dargestellt werden:
    Figure 00010001
    wobei I(K) der Informations-Datensatz ist, der mit der Folge K verknüpft ist. Die Laufzeit einer solchen Suche beträgt unter Verwendung von O-Schreibweise (eine Funktion f(n) wird als O(g(n)) bezeichnet, wenn eine Zahl n0 existiert, derart daß f(n) ≤ const.factor·g(n) für alle n ≥ n0):
    Tlinear(n) = O(n)
  • Somit nimmt die Laufzeit einer linearen Suche proportional mit der Anzahl der Folgen n zu.
  • Wegen ihrer Einfachheit weist eine lineare Suche weniger Zusatzverarbeitung pro Zeichenvergleich auf als fortgeschrittenere Suchmethoden. Allgemein ausgedrückt ist eine lineare Suche schneller als andere Suchmethoden, wenn der zu durchsuchende Satz von Folgen klein ist. Aus Gründen der Einfachheit und Robustheit der Implementierung wird deshalb die lineare Suche häufig für Suchen in kleinem Maßstab mit n < 100 bevorzugt.
  • Ein Nachteil der linearen Suche besteht in der linearen Abhängigkeit von der Anzahl von Eingaben oder Folgen n. Die Methode der linearen Suche wird mit zunehmendem n für Anwendungen mit hoher Leistungsfähigkeit unpraktikabel. Das Durchsuchen einer Tabelle mit 10.000 Eingaben wird 1.000 mal langsamer sein als das Durchsuchen einer Tabelle mit 10 Eingaben.
  • Eine andere weit verbreitete Suchtechnik ist das Hashing. Das Hashing berechnet die Adresse oder den Ort einer gegebenen Folge direkt aus der binären Darstellung der Folge, anstatt alle Folgen vollständig zu durchsuchen wie in der linearen Suchmethode. Eine Hash-Suche ist häufig ein Prozeß mit zwei Schritten, wobei die Hash-Funktion H einen Index zurückgibt, der auf eine kleinere Liste von Folgen verweist, die mit der linearen Suchmethode durchsucht werden. Eine Hash-Suche kann in Pseudo-Code durch den folgenden Algorithmus dargestellt werden:
    Figure 00030001
    wobei die Hash-Funktion H den Index der gegebenen Folge berechnet und den Index i zurückgibt. Der Index i kann auf die alleinige passende Folge verweisen oder auf eine Liste von Folgen, die dann linear nach der passenden Folge durchsucht werden müssen.
  • Eine weit verbreitete Hash-Funktion H organisiert oder indexiert die Folgen in einer Hash-Tabelle T unter Verwendung folgender Formel:
    H(K) = (Summe aller Bytes b1, ..., bm(ASCII Codes) der Schlüsselfolge K) modulo M
    wobei M die Größe der Hash-Tabelle T bezeichnet. Offensichtlich kann nicht allgemein garantiert werden, daß die Hash-Funktion H für jede Folge eindeutig ist. Wenn zwei oder mehr verschiedene Folgen dieselbe Hash-Funktion ergeben (H(Ki) = H(Kj) für verschiedene Folgen Ki ≠ Kj) wird dies als Kollisionsfall bezeichnet. Der gebräuchlichste Weg, einen Kollisionsfall zu behandeln, besteht darin, Listen von Folgen mit identischen Hash-Werten für jede Hash-Tabelleneingabe aufrecht zu erhalten, was es erforderlich macht, eine Kollisionsliste zu durchsuchen, üblicherweise durch die lineare Suchmethode, um die gewünschte Eingabe eindeutig zu finden.
  • Im allgemeinen hängt die Laufzeit des Hashings von der durchschnittlichen Länge der Kollisionslisten ab, die wiederum von der Verteilung der Hash-Funktion H sowie von der Größe M der Hash-Tabelle abhängt. Unter der Annahme, daß die Hash-Funktion H eine nahezu perfekte Verteilung hat (d.h. die Wahrscheinlichkeit dafür, daß eine Schlüsselfolge K in den Index i = H(K) gestreut wird ist für alle i = 1 ... M gleich wahrscheinlich), kann gezeigt werden, daß die durchschnittliche Laufzeit des Hashings
    Thash (n) = O(n/M)
    sein wird. Das Ergebnis ist eine Laufzeit, die für hinreichend große Hash-Tabellengrößen M > n nahezu konstant ist. Deshalb könnte theoretisch erwartet werden, daß die Laufzeit nahezu unabhängig von n ist, vorausgesetzt, daß eine perfekte Hash-Funktion (eine unrealistische Erwartung in der Mehrzahl der in der realen Welt anzutreffenden Anwendungen) verwendet werden kann.
  • Ein Nachteil des Hashings besteht darin, daß das inhärente Erfordernis, Kollisionsfälle zu lösen, es erfordert, eine zusätzliche und manchmal langwierige Suche durchzuführen. Obwohl die durchschnittliche Suche, die eine Hash-Technik verwendet, schnell sein kann, kann die tatsächliche Zeitdauer, um eine Suche zu beenden, für bestimmte Verteilungen von Folgen beträchtlich schlechter sein. Im ungünstigsten Fall kann es passieren, daß alle Folgen in dem selben Index enden, und die Gesamtleistung der Suche wird nicht besser sein als die einer linearen Suche. In der Praxis stellt es deshalb eine schwierige Aufgabe dar, eine effiziente Hash-Funktion für eine reale Anwendung zu finden, und diese hängt signifikant von der tatsächlichen Wahrscheinlichkeitsverteilung der zu indexierenden Folgen ab.
  • Ein anderer Nachteil des Hashings besteht darin, daß es sich nicht für Wildcard-Suchen eignet. Eine Wildcard-Suche ist eine Suche, bei der eines oder mehrere Zeichen in der Suchfolge ein Wildcard-Zeichen (d. h. ein Zeichen, das ein anderes Zeichen ersetzen kann) ist. Eine Wildcard-Suche ergibt häufig mehrere passende Folgen.
  • Eine andere Technik zum Suchen ist die Methode des Suchbaums. Bevor dieser Typ der Suche durchgeführt wird, muß ein Suchbaum erzeugt werden, um die Daten zu organisieren, in denen Suchen durchgeführt werden sollen. Es wurde eine Vielzahl an Implementierungen von Suchbäumen vorgeschlagen, unter denen eine der grundlegendsten der binäre Suchbaum ist, der wie folgt definiert ist.
  • Ein (binärer) Baum T über einen Satz von Folgen K1, ..., Kn (dargestellt durch die Baumknoten) wird als ein Suchbaum bezeichnet, wenn für jeden Unterknoten T die folgende Bedingung zutrifft:
    Wert(Tl) < Wert (Tr)
    für jeden Nachfolgerknoten Tl in dem linken Unterbaum von T und jeden Knoten Tr in dem rechten Unterbaum von T, wobei Wert (T) die Folge ist, die mit dem Baumknoten T verknüpft ist.
  • Somit kann die grundlegende Suchprozedur (rekursiv) wie folgt in Pseudo-Code formuliert werden (wie üblich bezeichnet K die Folge, die gesucht wird und aus Gründen der Vereinfachung werden spezielle Fälle wie nicht existierende Schlüssel ausgelassen).
  • Figure 00060001
  • Die oben skizzierte Suchbaum-Methode führt ein Durchlaufen des Baumes mit erster Tiefe durch, was zu einer Laufzeit führt, die proportional mit der Tiefe des Baumes zunimmt. Folglich beträgt, wenn ein adäquat ausbalancierter Suchbaum gegeben ist (d. h. ein Suchbaum, dessen Blattknoten im wesentlichen gleich verteilt sind) die durchschnittliche Laufzeit
    TBaum = O(log2n)
  • Somit nimmt in der Theorie die Laufzeit logarithmisch mit der Zahl der Eingaben oder Folgen zu. Dies stellt beim Suchen in einer großen Zahl von Folgen eine erhebliche Verbesserung gegenüber der linearen Suche dar.
  • Ein Nachteil des Suchbaum-Verfahrens besteht darin, daß unter Anwendungsbedingungen die Laufzeit stark variieren kann, weil in der Praxis Suchbäume kaum ausbalanciert sind. Die Eigenschaften des Baumes hinsichtlich seiner Ausbalanciertheit hängen sehr stark von der tatsächlichen Verteilung der Folgen ab. Anspruchsvollere Methoden, beispielsweise wie AVL-Bäume, die in Van Wyk, Christopher J., Data Structures and C. Programs. Addison-Wesley Publishing, 1988, beschrieben sind, sind erfunden worden, um dieses Problem zu verringern. Derartige Methoden tendieren jedoch auch dazu, den Zusatzaufwand für die Implementierung der Verwaltung der Baumstruktur zu vergrößern. In der Praxis und in Abhängigkeit von der tatsächlichen Implementierung übertreffen baumbasierte Suchen kaum einfache lineare Suchen, außer wenn die Zahl der Eingaben einen Break-Even-Punkt von mehreren hundert Eingaben übersteigt.
  • D1 = EP-A-419889. Dieses Dokument offenbart einen Vorsilben-Suchbaum mit teilweiser Schlüsselverzweigung. Es werden verschiedene Arten von Bäumen diskutiert sowie ihre zugehörigen Probleme. Ein Trie ist ein Index-Baum, der Schlüsselwerte mit variabler Länge verwendet und wobei das Verzweigen auf irgendeiner Stufe des Trie durch nur einen Teil des Schlüssels bestimmt wird. In einem Vorsilben-Indexbaum ist eine Vorsilbenfolge der Länge p, die von der längsten Folge von Schlüsselzeichen umfaßt ist, allen Unterbäumen des Knotens gemeinsam sowie ein Dateneintragfeld zum Speichern eines Verweises auf einen Dateneintrag, dessen Schlüssel durch die Vorsilbenfolge vervollständigt wird. Die Baumstruktur umfaßt ferner eine oder mehrere Verzweigungsfelder, wenn die Vorsilbenfolge eine Vorsilbe von Schlüsseln ist, die in wenigstens einem Unterbaum des Knotens gespeichert sind.
  • Die vorliegende Erfindung überwindet die vorausgehenden Probleme durch Bereitstellen eines Verfahrens zum schnellen Indexieren und Wiederauffinden von alphanumerischen oder binären Folgen, das sowohl das allgemeine Indexieren als auch Abfragen mit teilweiser Übereinstimmung ermöglicht. Die Erfindung verwendet einen eindeutig kompaktierten Indexbaum, in dem ein Knoten verwendet werden kann, um eine Mehrzahl von Zeichen in einer Suchfolge zu durchlaufen, und kann so viele Nachfolgerknoten haben, wie individuelle Zeichen in dem zugrundeliegenden Zeichenalphabet sind (z. B. 256 für 8-Bit-basierte Zeichen). Ferner verwendet die Erfindung das Rückverfolgen (Backtracking), wenn eine Mehrzahl von Unterbäumen während einer Wildcard-Suche nach mehreren möglichen übereinstimmenden Folgen durchsucht werden muß. Die Erfindung macht sich auch das heuristische Unterbaum-Aufästeln zunutze, eine Methode, bei der Suchen mit teilweiser Überstimmung durch das Verwerfen gesamter Unterbäume beschleunigt werden können.
  • Obwohl die vorliegende Erfindung für die Verwendung mit Folgen vorgesehen ist, kann eine derartige Suchmethode verwendet werden, um irgendeine digitale, in einer Datenbank gespeicherte Information zu suchen.
  • Zusammenfassung der Erfindung
  • Die vorliegende Erfindung betrifft ein Verfahren zum Indexieren und Suchen digitaler Daten, die in der Form von Folgen gespeichert sind. Sie stellt ein Mittel zum schnellen Durchsuchen einer Datenbank bereit, um eine gegebene Suchfolge zu ermitteln. Zum Zwecke der Veranschaulichung wird in dem beschriebenen Ausführungsbeispiel die Suchmethode in Verbindung mit alphanumerischen Folgen verwendet.
  • Eine Aufgabe der Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, das, für bestimmte Anwendungen, schneller als jedes bekannte Suchverfahren ist.
  • Eine andere Aufgabe dieser Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, das, für die meisten Anwendungen, schneller als lineares Suchen, Hash-Suchen oder binäres Baumsuchen ist.
  • Eine andere Aufgabe dieser Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, welches das Suchen nach teilweisen Übereinstimmungen unterstützt, wie Wildcards auf einer Zeichenstufe.
  • Eine andere Aufgabe dieser Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, welches das generische Indexieren, einschließlich das generische Speichern teilweise spezifizierter Folgen in dem Index, unterstützt.
  • Eine andere Aufgabe dieser Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, das für Folgen mit großer Größe besonders effizient ist.
  • Eine andere Aufgabe dieser Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, das eine Robustheit gegenüber ungleichmäßig verteilten Verteilungen von Folgen aufweist.
  • Eine andere Aufgabe dieser Erfindung besteht darin, ein Verfahren zum Suchen von Folgen bereitzustellen, welches das unbegrenzte Entarten verhindert, das in binären Bäumen oder Hash-Kollisionslisten auftritt.
  • Eine andere Aufgabe dieser Erfindung besteht darin, eine Implementierung zum Suchen von Folgen bereitzustellen, die den internen Zusatzaufwand für das Verwalten von Baumstrukturen minimiert. Daher wird die beschriebene Implementierung oft sogar für Tabellen, die weniger als 100 Eingaben haben, schneller als lineare Suchen sein.
  • Eine andere Aufgabe dieser Erfindung besteht darin, eine verbesserte Methode für das logische Sperrmanagement bereitzustellen.
  • Gemäß dieser Erfindung wird ein Verfahren zum Indexieren einer Mehrzahl von Eingabefolgen vorgeschlagen, wobei jede der Mehrzahl von Eingabefolgen eine Zeichenfolge ist. In der Erfindung wird ein Suchbaum verwendet, der eine Mehrzahl verknüpfter Knoten umfaßt, die einen Wurzelknoten umfassen, eine Mehrzahl innerer Knoten, wobei jeder der Mehrzahl der inneren Knoten mit einem Zeichen oder einer Teilfolge von Zeichen verknüpft ist, und eine Mehrzahl von Blattknoten, die mit der Mehrzahl von Eingabefolgen verknüpft sind. Dabei umfaßt ferner jeder der Mehrzahl der inneren Knoten (a) einen Verweis auf einen Vaterknoten, wobei der Vaterknoten einer der anderen der Mehrzahl der inneren Knoten oder der Wurzelknoten ist, (b) ein erstes Datenfeld, das die Position eines Zeichenvergleichs enthält, die die Anzahl von Zeichen in dem Zeichen oder Teilfolge von Zeichen angibt, die mit dem einen Knoten der Mehrzahl von inneren Knoten verknüpft ist; (c) ein zweites Datenfeld, das ein Vergleichszeichen enthält, wobei das Vergleichszeichen benutzt wird um zu bestimmen, ob das Zeichen oder die Teilfolge der Zeichen, die mit dem einen der Mehrzahl. der inneren Knoten verknüpft ist, in einer Eingabefolge an einer Zeichenposition der Eingabefolge enthalten ist, die mit der Position des Zeichenvergleichs verknüpft ist; (d) einen Verweis auf wenigstens zwei Nachfolgerknoten; und (e) ein Hash-Tabellen-Datenfeld, das eine vorgegebene Anzahl von Hash-Blöcken enthält.
  • Ein erfindungsgemäßes Verfahren zum Suchen nach einer bestimmten Folge, die aus einer Mehrzahl von Zeichen besteht, in einer Mehrzahl von Folgen, wobei jede der Mehrzahl von Folgen eine Zeichenfolge ist, umfaßt folgende Schritte: Erzeugen eines Suchbaums gemäß der Erfindung, wobei die Mehrzahl der Folgen eine Mehrzahl von Eingabefolgen bildet, Bilden einer Abfrage, die mit der bestimmten Folge verknüpft ist und Durchlaufen des Suchbaums unter Verwendung der Abfrage und unter Bereitstellung eines Index zu jeder der Mehrzahl der Folgen, die mit der bestimmten Folge übereinstimmt.
  • Das erfindungsgemäße Verfahren zum Suchen nach einer bestimmten Folge kann insbesondere dann vorteilhaft sein, wenn es in Verbindung mit einem System für Personalmanagement, Finanzen, Logistik, Arbeitsablauf, Personalverwaltung, Organisationsverwaltung, Lohnbuchführung, Zeitmanagement, Mitarbeiterförderung oder einem Netzwerksystem, z. B. einen Internet- oder Intranet-System verwendet wird. Ein solches System kann insbesondere ein R/3-System sein, das von SAP, Walldorf in Deutschland erhältlich ist.
  • Einige grundlegende Aspekte der Erfindung und bevorzugte Ausführungsformen können wie folgt beschrieben werden.
  • Ein schnelles Verfahren zum Indexieren von Folgen speichert, sucht und entfernt in effizienter Weise alphanumerische oder binäre Folgen unter Verwendung eines kompakten Suchbaums. Die Zahl der Stufen in dem Suchbaum wird minimiert, wenn ein Knoten verwendet wird, der mehr als ein Zeichen repräsentiert, falls möglich. Jeder innere Knoten des Baums enthält ein Hash-Tabellenfeld für das nachfolgende Hashing, das auch die erforderliche Zeit zum Durchlaufen eines bestimmten Knotens minimiert. Es kann eine Suche nach teilweisen Übereinstimmungen durchgeführt werden, wie Wildcards auf der Zeichenstufe. Mehrere Indi zes können unabhängig und gleichzeitig in derselben Tabelle von Eingabefolgen geöffnet sein.
  • Die Erfindung und bevorzugte Ausführungsformen werden unter Bezugnahme auf die folgenden Zeichnungen beschrieben.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist eine Darstellung eines Beispiels der grundlegenden Datenstruktur eines Indexbaums, der eine Anwendung einer schnellen Folgenindexierung verkörpert.
  • 2 und 2a sind Darstellungen eines Flußdiagramms einer bevorzugten Ausführungsform der INSERT Operation.
  • 3 ist eine Darstellung der ersten Hälfte eines Beispiels einer ausgeführten INSERT Operation.
  • 4 ist eine Darstellung der zweiten Hälfte eines Beispiels einer ausgeführten INSERT Operation.
  • 5 ist eine Darstellung eines Flußdiagramms einer bevorzugten Ausführungsform der REMOVE Operation.
  • 6 ist eine Darstellung der ersten Hälfte eines Beispiels einer ausgeführten REMOVE Operation.
  • 7 ist eine Darstellung der zweiten Hälfte eines Beispiels einer ausgeführten REMOVE Operation.
  • 8 ist eine Darstellung eines Flußdiagramms einer bevorzugten Ausführungsform der exakten Übereinstimmung FIND Operation.
  • 9 und 9a sind Darstellungen eines Flußdiagramms einer bevorzugten Ausführungsform der teilweisen Übereinstimmung FIND Operation.
  • 10 ist eine Darstellung eines Beispiels einer ausgeführten teilweisen Übereinstimmung FIND Operation.
  • 11 ist eine Darstellung eines logischen Sperrmanagements unter Verwendung einer FI indexierten Sperrtabelle.
  • Detaillierte Beschreibung der Erfindung
  • Die vorliegende Erfindung wurde als verbessertes Verfahren zum Durchführen von Suchen und zum Pflegen von Datenbanken entwickelt. Die Erfindung hat gegenüber den herkömmlichen Verfahren zum Suchen und Indexieren viele Vorteile, von denen einer die Geschwindigkeit ist. Die überlegene Geschwindigkeit kann hauptsächlich auf drei Faktoren zurückgeführt werden: Robustheit gegenüber der Anzahl von Eingaben oder Schlüsselfolgen, Robustheit gegenüber der Verteilung von Schlüsselfolgen und Robustheit gegenüber der Länge von Schlüsselfolgen. Alle drei Faktoren werden im folgenden detailliert beschrieben.
  • Ein Satz von n zufälligen Schlüsselfolgen mit m Zeichen, der als
    K1 = b11 ... b1m, K2 = b21 ... b2m ... Kn = bn1 ... bnm
    bezeichnet wird, soll indexiert werden. Aus Gründen der Veranschaulichung werde der gebräuchliche Fall angenommen, in dem jedes Zeichen als ein 8-Bit-Byte kodiert ist, und daß die Länge jeder Schlüsselfolge 256 Bytes (m = 256) beträgt.
  • Die Robustheit gegenüber der Anzahl von Schlüsselfolgen bezieht sich auf die Beschränkung der inhärenten Zunahme der durchschnittlichen Laufzeit der grundlegenden Operationen INSERT, REMOVE und FIND, wenn die Anzahl der Folgen n zunimmt.
  • Das in dieser Erfindung beschriebene (und in einer bevorzugten Ausführungsform mit "FI" bezeichnete) schnelle Verfahren für Folgen durchläuft einen Indexbaum (dessen Struktur ähnlich der eines binären Baums aussieht, ausgenommen daß die inneren Knoten mehrere Unterbäume haben können, die direkt davon absteigen, anders als nur zwei) von oben nach unten, während gleichzeitig die Suchfolge von links nach rechts durchlaufen wird. Wenn das letzte Zeichen der Suchfolge erreicht wird, hat der Prozeß entweder einen Blattknoten des Indexbaums erreicht, der eine Übereinstimmung angibt, oder hat ermittelt, daß die Suchfolge gegenwärtig nicht in dem Index ist. Somit muß die durchschnittliche Gesamtzahl der Überprüfungen von Baumknoten kleiner oder gleich der durchschnittlichen Tiefe des Indexbaums sein.
  • Die im Zusammenhang mit der Erfindung verwendete durchschnittliche Tiefe des Indexbaums kann wie folgt berechnet werden. Es wird angenommen, daß der durchschnittliche Verzweigungsfaktor k des Indexbaums als die durchschnittliche Anzahl absteigender Unterbäume definiert wird, die von irgend einem inneren Knoten entspringen. Aus diesem Grund ist k kleiner oder gleich der Anzahl zugrundeliegender Zeichen in dem zugrundeliegenden Alphabet (z. B. 256 für 8 Bit). In der Praxis ist jedoch der durchschnittliche Verzweigungsfaktor wesentlich kleiner als diese Zahl, da die wirkliche Verteilung von Schlüsselfolgen üblicherweise weit davon entfernt ist, gleichmäßig verteilt zu sein. Experimentelle Ergebnisse unter Verwendung großer Sätze zufälliger wirklicher Daten zeigen, daß ein vernünftiger durchschnittlicher Verzweigungsfaktor in dem Bereich von k = 3 ... 7 für zugrundeliegende Alphabete mit 4 bis 9 Bit und Folgenlängen von 16 bis 512 Zeichen liegt.
  • Da die Anzahl innerer Knoten für jede nachfolgende Stufe eines Baums T um einen Faktor k zunimmt, kann die Gesamtzahl von Blattknoten n (gleich der gesamten Anzahl von Schlüsselfolgen) auf der letzten Stufe dargestellt werden als
    n = kTiefe(T) oder Tiefe (T) = logkn
  • Da weiterhin die durchschnittliche Laufzeit der FI-Operationen INSERT, REMOVE und FIND äquivalent zu der Baumtiefe ist, kann angegeben werden, daß
    TFI(n) = O(logkn )
    und die Ausführungszeit nimmt nur logarithmisch mit zunehmender Anzahl von Eingaben zu. Wenn beispielsweise k = 4 ist, wird jede Vervierfachung der Anzahl von Schlüsselfolgeneingaben durchschnittlich nur eine weitere zu betrachtende Stufe für diese Operationen hinzufügen.
  • Die Robustheit gegenüber der Verteilung von Schlüsselfolgen bezieht sich auf die Beschränkung der Streuung der Suchzeit für einen gegebenen Satz von Eingaben. Mit anderen Worten sollte eine Suche nach einer bestimmten Eingabe idealer Weise dieselbe Zeit benötigen wie eine Suche nach einer anderen Eingabe, insbesondere in Bezug auf den ungünstigsten Fall (d. h. der ungünstigste Fall sollte nicht mehr Zeit in Anspruch nehmen als der durchschnitt liche Fall). Aufgrund der realen Verteilungen von Schlüsselfolgen kann ein binärer Baum jedoch einige Blattknoten in der Nähe der Spitze des Indexbaums haben und andere Blattknoten in extremen Tiefen. Im ungünstigsten Fall kann ein binärer Baum bis zu dem Punkt entarten, in dem eine Suche nach manchen Eingaben genauso viel Zeit beansprucht wie eine lineare Listensuche. AVL-Bäume sind etwas besser verteilt als binäre Bäume, aber zu Lasten eines drastisch erhöhten Zusatzaufwandes für die Verwaltung zum Pflegen der Datenstruktur des Algorithmus, was wiederum dazu führt, daß die Gesamtleistung verschlechtert wird. Hashing-Algorithmen können auch unter einer unbalancierten Verteilung von Eingaben leiden. Idealer Weise sind die Eingaben gleichmäßig über die Hash-Tabelle verteilt und die Kollisionslisten sind mehr oder weniger gleichmäßig lang. In der Praxis werden manche Kollisionslisten länger sein als andere. Im ungünstigsten Fall werden alle Eingaben auf denselben Hash-Platz abgebildet und eine Hash-Suche wird äquivalent zu einer linearen Listensuche.
  • Obwohl der FI-Indexbaum im allgemeinen kein perfekt balancierter Baum ist, ist der Grad der maximalen Entartung beschränkt, weil wenigstens ein Zeichen der Folge in der Suchfolge durchlaufen wird, für jede absteigende Stufe den Baum hinunter. Daher ist die Gesamttiefe eines Baums T durch die Länge m der Schlüsselfolge beschränkt, die üblicherweise eine Zahl ist, die logarithmisch kleiner als die Gesamtzahl von Eingaben n ist.
  • Die Robustheit gegenüber der Länge der Schlüsselfolge bezieht sich auf die Abhängigkeit der Suchzeit von der durchschnittlichen Länge m der individuellen Eingaben. Dies stellt in Anwendungen wie dem logischen Sperrmanagement, wobei jede Schlüsselfolge einer gesamten Zeile der Datenbasis-Tabelle entsprechen kann, einen wichtigen Gesichtspunkt dar. In diesen Anwendungen kann es bedeutsam sein, Schlüsselfolgen zu indexieren und zu suchen, die hunderte wenn nicht gar tausende Zeichen lang sind. Bei der Verwendung gebräuchlicher Suchmethoden erfordert eine große Länge der Schlüsselfolge oft langwierige Zeichen-für-Zeichen-Vergleiche für jeden Suchschritt.
  • Das FI-Suchen hat die Fähigkeit, Schlüsselfolgen derart zu indexieren, daß jeder Suchschritt mehrere Zeichen in der Suchfolge abdecken kann. Pro Suchschritt ist nur eine einzige Zeichenüberprüfung erforderlich, unabhängig von der tatsächlichen Länge der Folge. Da die Tiefe des FI-Indexbaums T üblicherweise viel kleiner als die Zeichenlänge m ist, muß ein großer Teil der Folge nicht überprüft werden und kann während des Suchvorgangs ausgelassen werden. Durch experimentelle Ergebnisse wurde bestätigt, daß die FI-Leistung in den meisten realen Anwendungen nicht sehr mit der Länge der Schlüsselfolge variiert. FI erfordert nur, einen letzten Vergleich der Suchfolge und des Blattknotens (oder im Falle von Wildcard-Suchen der Knoten), der in der Suche gefunden wurde, durchzuführen, um zu verifizieren, daß keine falschen Antworten dabei sind.
  • Ausführungsbeispiel
  • Ein Beispiel einer grundlegenden Struktur einer bevorzugten Ausführungsform eines FI-Indexsuchbaums 2 ist in 1 veranschaulicht. In diesem besonderen Beispielsfall hat die mit dem Baum verknüpfte Datenbasis bereits die folgenden Schlüsselfolgen-Eingaben: "abcd", "cdaf", "cddh" und "gfbe". Aus Gründen der Vereinfachung und nur zu Veranschaulichungszwecken hat das diesen Schlüsselfolgen zugrundeliegende Alphabet acht Zeichen (3 Bit). Es wird angenommen, daß kleinere oder größere Alphabete (z. B. auf Basis von 8 Bit) für die meisten Anwendungen nützlicher sein können.
  • An der Spitze des Indexbaums 2 ist ein Wurzelknoten 4, der der erste Knoten ist, der bei der Initialisierung eines Indexbaums erzeugt wird. Die Blattknoten 5a, 5b, 5c und 5d sind jeweils mit den Schlüsselfolgenfeldern 6a, 6b, 6c und 6d verknüpft, die die indexierten Schlüsselfolgen enthalten, und jeweils mit den Informationsfeldern 7a, 7b, 7c und 7d, die irgendwelche zusätzlichen Daten enthalten können, die ein Benutzer mit den indexierten Schlüsselfolgen verknüpfen möchte. Es wird angenommen, daß ein Benutzer den Wunsch haben kann, eine Mehrzahl von Informationsfeldern mit einer gegebenen Schlüsselfolge zu verknüpfen. Die Schlüsselfolge kann z. B. eine Identifikationsnummer eines Arbeitnehmers sein und zusätzliche Informationsfelder können für den Namen, die Adresse, die Telefonnummer usw. des Arbeitnehmers existieren.
  • Wie bei einem binären Baum gibt es innere Knoten, die nicht mit einer bestimmten Schlüsselfolge oder mit von dem Benutzer bereitgestellter Information verknüpft sind, sondern mit Vergleichen verknüpft sind, die die Richtung zu einem gewünschten Blattknoten bereitstellen. In 1 ist nur ein innerer Knoten 8 dargestellt, aber für einen Fachmann der Computerprogrammierung ist es klar, daß Indexbäume oft eine Vielzahl innerer Knoten haben.
  • Der innere Knoten 8 beinhaltet mehrere Datenfelder. Das Elternfeld 10 verweist auf den Vaterknoten des Knotens, den Wurzelknoten 4. Das pos-Feld 11 beinhaltet Information darüber, was als Zeichenvergleichsposition (pos) des Knotens bezeichnet wird. Dieses Feld wird für jeden inne ren Knoten aufrecht erhalten, so daß die folgende Bedingung erfüllt ist: die ersten pos-Zeichen (d. h. eine Unterfolge der Länge pos) sind für alle Schlüsselfolgen, die mit Blattknoten verknüpft sind, die in dem Unterbaum enthalten sind, der von dem Knoten entspringt, identisch. Die Zeichenvergleichsposition gibt an, daß an dem nachfolgenden Knoten, der auf die gemeinsame Unterfolge folgt, ein Zeichenvergleich stattfinden muß. Er wird verwendet, um durch das Auslassen identischer Zeichenfolgen den Suchvorgang über den Indexbaum zu beschleunigen. Eine Eigenschaft des F1 Baumes ist, daß alle in den Blattknoten eines bestimmten Unterbaumes enthaltenen Folgen dieselbe Vorsilbe haben. Beispielsweise sind die Blattknoten 5b und 5c, die zusammen mit dem inneren Knoten 8 einen Unterbaum bilden, jeweils mit den Schlüsselfolgen "cdaf" und "cddh" verknüpft. Diese zwei Unterfolgen haben die Vorsilbe "cd" gemeinsam. In diesem Beispiel würde das pos-Feld 11 des inneren Knotens 8 die Zeichenvergleichsposition zwei enthalten, da dies die Länge der gemeinsamen Vorsilbe aller Folgen ist, die in dem Unterbaum enthalten sind, der von dem inneren Knoten 8 entspringt. Das Zeichen, das mit dieser Zeichenvergleichsposition verknüpft ist, ist das dritte Zeichen, das das erste Zeichen ist, das die beiden Unterbäume nicht gemeinsam haben.
  • Das Succ-Feld 12 verfolgt die aktuelle Zahl von Nachfolgerknoten. In dem Beispiel hat der innere Knoten 8 zwei Nachfolgerknoten, den Blattknoten 5b und den Blattknoten 5c. Das SuccFirst-Feld 13 ist ein Verweis auf den ersten Knoten einer doppelt verknüpften, NULL-abgeschlossenen Liste (die manchmal als Geschwister-Liste bezeichnet wird) aller Nachfolgerknoten. In dem Beispiel verweist das SuccFirst-Feld 13 des inneren Knotens 8 auf den Blattknoten 5b. Das SuccFirst-Feld 13 wird unter anderem für die REMOVE-Funktion verwendet, die weiter unten beschrieben wird.
  • Das ch-Feld 14 beinhaltet das Vergleichszeichen des Knotens. Das Vergleichszeichen ist das erste Zeichen, das einen Knoten von seinen Geschwisterknoten (die andernfalls dieselbe Unterfolge gemeinsam haben) unterscheidet.
  • Das sblPrev-Feld 15 ist eine Bezugsverknüpfung zu dem vorausgehenden (links benachbarten) Knoten der Geschwisterliste. Wenn dort kein vorausgehender Knoten der Geschwisterliste ist, ist die Bezugsverknüpfung ein NULL-Verweis. Entsprechend ist das sblNext-Feld 16 eine Bezugsverknüpfung zu dem nächsten (rechts benachbarten) Knoten der Geschwisterliste. Wenn dort kein nächster Knoten der Geschwisterliste ist, ist die Bezugsverknüpfung ein NULL-Verweis. In dem Beispiel ist das sblPrev-Feld 15 des inneren Knotens 8 eine Bezugsverknüpfung zu dem Blattknoten 5a und das sblNext-Feld 16 des inneren Knotens 8 eine Bezugsverknüpfung zu dem Blattknoten 5d.
  • Die lokale Nachfolger-Hash-Tabelle 17 wird zum Suchen und Identifizieren des korrekten, nachzufolgenden Nachfolgezweiges (d. h. des Knotens, der eine Stufe tiefer in dem Baum liegt und während einer gegebenen Suche zu durchlaufen ist) benutzt. Die lokale Nachfolger-Hash-Tabelle 17 besteht aus dem Hash-Tabellenfeld 18 und dem Hash-Next-Feld 19. Das Hash-Tabellenfeld 18 beinhaltet eine feste Anzahl von Hash-Blöcken, die Zeichenwerte darstellen. In dem Beispiel sind die acht Zeichen, die das zugrundeliegende Schlüsselfolgen-Alphabet bilden, gleichmäßig über vier Hash-Blöcke 18a, 18b, 18c und 18d verteilt worden. Da (wie oben beschrieben wurde) alle Schlüsselfolgen, die in den Blattknoten des Unterbaums enthalten sind, der von dem inneren Knoten 8 entspringt, dieselbe Start-pos- Zeichen haben (die in dem Beispiel die zwei Zeichen "cd" wären), wird das nachfolgende Zeichen (das auch als "Zeichenvergleichspositions"-Zeichen bezeichnet wird) für diese pos-Folgen (nämlich jeweils "a" und "d") in den Hash-Blöcken plaziert. In dem Beispiel sind die Zeichen "a" und "e" dem Hash-Block 18a, "b" und "f" dem Hashblock 18b, "c" und "g" dem Hash-Block 18c und "d" und "h" dem Hash-Block 18d zugeordnet. Der Hash-Block 18a hat somit eine Bezugsverknüpfung zu. dem Blattknoten 5b und der Hash-Block 18d hat einen Verweis auf den Blattknoten 5c.
  • Das HashNext-Feld 19 dient als Bezugsverweis für die Hash-Kollisionsliste. Da in dem Beispiel "c" und "g" auch demselben Hash-Block in dem Hash-Tabellenfeld des Wurzelknotens 4 zugeordnet sind und weil in einer bevorzugten Ausführungsform jeder Hash-Block einen Verweis zu nur einem anderen Knoten haben kann, ist es für den Nachfolgerknoten (des Wurzelknotens 4), dessen Vergleichszeichen "c" ist, erforderlich, auf seinen Geschwisterknoten zu verweisen, dessen Vergleichszeichen "g" ist. Somit hat das HashNext-Feld 19 des inneren Knotens 8 eine Bezugsverknüpfung zu dem Blattknoten 5d.
  • Ein Wurzelknoten kann ein Blattknoten (wenn der Indexbaum nur aus einer Eingabe besteht), oder ein innerer Knoten sein. In dem Beispiel ist der Wurzelknoten 4 ein innerer Knoten. Der Wurzelknoten 4 hat daher dieselben Felder wie der innere Knoten 8. Ein Wurzelknoten unterscheidendes Merkmal besteht darin, daß sie keinen Vaterknoten haben (somit enthält das Elternfeld des Wurzelknotens 4 einen NULL-Zeiger).
  • Die Blattknoten 5a, 5b, 5c und 5d beinhalten ebenfalls mehrere Datenfelder. In 1 wird der Blattknoten 5b als ein Beispiel eines typischen Blattknotens herangezo gen. Das Elternfeld 20, das ch-Feld 24b, das sblPrev-Feld 25 und das sblNext-Feld 26 des Blattknotens 5b sind analog zu dem Elternfeld 10, ch-Feld 14, sblPrev-Feld 15 und sblNext-Feld 16 des inneren Knotens B.
  • Das pos-Feld 21 wird auf einen speziellen Wert "unendlich" gesetzt, um es als einen Blattknoten zu unterscheiden. Der Inhalt des succ-Felds 22 ist undefiniert, da Blattknoten keine Nachfolger haben. Das Schlüsselfeld 27 verweist auf das Schlüsselfolgenfeld 6b, während das Info-Feld 28 auf das Informationsfeld 7b verweist.
  • In dem Beispiel sollte klar sein, daß die Schlüsselfolge "abcd", die einzige Schlüsselfolge, die mit dem Zeichen "a" beginnt, mit dem Blattknoten 5a verknüpft wäre, dessen ch-Feld 24a das Zeichen "a" enthält. Entsprechend ist die Schlüsselfolge "gfbe", die einzige Schlüsselfolge, die mit dem Zeichen "g" beginnt, mit dem Blattknoten 5d verknüpft, dessen ch-Feld 24d das Zeichen "g" enthält. Da es eine Mehrzahl von Schlüsselfolgen gibt, die mit dem Zeichen "c" beginnen (nämlich "cdaf" und "cddh"), können die mit diesen Schlüsselfolgen verknüpften Blattknoten keine Nachfolger des Wurzelknotens 4 sein. Vielmehr wird der innere Knoten 8 verwendet, um das erste Zeichen zu vergleichen, das die Schlüsselfolgen, die mit dem Zeichen "c" (das auch das in dem ch-Feld 14 gespeicherte Zeichen ist) beginnen, nicht gemeinsam haben. Da das pos-Feld 11 die Information bereitstellt, daß die ersten zwei Zeichen dieser Schlüsselfolgen gleich sind, wird das dritte Zeichen verwendet, um zu bestimmen, welcher Hash-Block anwendbar ist. Wenn das dritte Zeichen ein "a" ist, wird ein Verweis auf den Blattknoten 5b erzeugt. Wenn andererseits das dritte Zeichen ein "d" ist, wird ein Verweis auf den Blattknoten 5c erzeugt.
  • Initialisierung
  • Durch einen Initialisierungsprozeß wird in einem von dem Benutzer bereitgestellten Speicherbereich eine FI-Bibliothek initialisiert. Bei dem Abschluß des Initialisierungsprozesses wird eine Steuerung für den initialisierten FI-Vorgang zurückgegeben. Der Benutzer kann eine Identifizierungsfolge definieren, die auch als Blickfang bezeichnet wird, um auf einen bereitgestellten Pufferspeicher zu verweisen. Dies gewährleistet die auf-einmal-Initialisierung in einer Multiprozeß-Anwendung, wobei der Puffer üblicherweise in einem gemeinsamen Speicher residiert. In der CREATE-Operation, die eine bevorzugte Ausführungsform des Initialisierungsprozesses ist, werden die folgenden Eingabe- und Ausgabeparameter verwendet.
  • Die Eingabeparameter umfassen <buffer>, <ident>, <maxIndex>, <maxKeys>, <maxKeyLen> und <wildcardCh>. Der <buffer>-Parameter ist ein angrenzender Speicherbereich, der für die FI-Verwaltung von dem Benutzer bereitgestellt wird. <buffer> kann auch eine geteilte Speicheradresse für Multiprozeß-Anwendungen sein. Der <ident>-Parameter ist ein Blickfang, der einen FI-Vorgang eindeutig identifiziert, und wird verwendet, um mehrfache Initialisierungen in mehrfach verschraubten Anwendungen zu verhindern. Der <maxIndex>-Parameter stellt die maximale Anzahl individueller Indizes bereit, die unabhängig gehandhabt werden können. Der <maxKeys>-Parameter stellt die maximale Anzahl von Indexeinträgen (Schlüsselfolgen) bereit und ist die Summe der nicht wiederholten Einträge aller individuellen Indizes. Der <maxKeyLen>-Parameter gibt die maximale Schlüsselfolgenlänge in Bytes für die Schlüsselfolgen in allen Indizes an. Der <wildcardCh>-Parameter beinhaltet das Zeichen, das als Wildcard in einer teilweisen Übereinstimmungssuche verwendet werden soll.
  • Der Ausgabeparameter <handle> ist ein Verweis auf den neu erzeugten FI-Vorgang und wird als Steuerung (Verweis) für nachfolgende FI-Bibliotheksaufrufe verwendet.
  • Der Initialisierungsprozeß verwirklicht mehrere Aufgaben. Eine Aufgabe ist das Initialisieren einer FI-Verwaltungsstruktur in dem Speicher. Eine andere ist das Bereitstellen eines Blickfangs, um mehrfache Initialisierungen zu ermitteln (um eine Einmal-Initialisierung in Multi-Prozessen und/oder mehrfach verschraubten Umgebungen zu gewährleisten). Der Initialisierungsprozeß initialisiert ein schnelles LIFO (last in, first out) basiertes Speichermanagement, das von fester Größe ist, zum Belegen und Freigeben von Indexbaumknoten in einer im wesentlichen konstanten Zeit. Ferner wird ein Stapel innerer Knoten initialisiert, so daß Rückverfolgungspunkte gespeichert werden können, wenn der Indexbaum in Abfragen teilweiser Übereinstimmung rekursiv durchsucht wird.
  • Öffnen von Indexobjekten
  • In demselben Satz von Daten können mehrere Indizes zur gleichen Zeit geöffnet werden. Dadurch wird z. B. ermöglicht, daß invertierte Indizes gleichzeitig verwendet werden. Die OPEN-Operation erzeugt ein neues, leeres Indexobjekt in einem globalen FI-Vorgang, der zuvor durch die CREATE-Operation initialisiert wurde. Die folgenden Eingabe- und Ausgabeparameter werden in einer bevorzugten Ausführungsform der OPEN-Operation verwendet.
  • Die Eingabeparameter umfassen <fiHd>, <IdxId> und <maxKeyLen>. Der <fiHd>-Parameter ist ein globaler FI-Vorgang (der von der CREATE-Operation zurückgegeben wird). Der <IdxId>-Parameter ist ein Blickfang, der eindeutig den geöffneten Index identifiziert, und wird verwendet, um Mehrfach-Initialisierungen in Multiprozeß-Anwendungen zu verhindern, die sich Speicher teilen. Der <maxKeyLen>-Parameter gibt die maximale Schlüsselfolgenlänge für die in dem Index anzuordnenden Schlüsselfolgen in Bytes an und kann kleiner oder gleich dem Wert von <maxKeyLen> in der CREATE-Operation sein.
  • Der Ausgabeparameter <handle> ist ein Verweis auf das neu erzeugte Indexobjekt und wird als Steuerung für nachfolgende Indexoperationen verwendet.
  • INSERT Operation
  • Die INSERT-Operation fügt in ein spezifiziertes Indexobjekt eine spezifische Schlüsselfolge ein. Wie oben erwähnt wurde, sind mit jeder Schlüsselfolge in dem Index durch den Benutzer bereitgestellte Daten verknüpft.
  • Jedesmal, wenn eine Schlüsselfolge in einen Index eingefügt wird, wird intern ein neues FI-Schlüsselobjekt (d. h. ein Blatt des Indexbaums) erzeugt und eine Steuerung für den Schlüssel wird an den Aufrufer zurückgegeben. Die Steuerung kann künftig verwendet werden, um direkt auf Schlüsseleingaben in dem Indexbaum zu verweisen (z. B. für die REMOVE-Operation). Die Schlüsseleingaben selbst werden nicht in dem Indexspeicher gespeichert. Vielmehr verweist FI mittels eines von dem Benutzer bereitgestellten Verweises auf die Folge.
  • In einer bevorzugten Ausführungsform hat die einzufügende Schlüsselfolge eine Länge von wenigstens <maxKeyLen>, die in der OPEN-Operation spezifiziert wurde, und hat kein Folgen-Endzeichen. In dieser Ausführungsform sollten Folgen, die kürzer als <maxKeyLen> sind, rechts mit Leerzeichen aufgefüllt werden.
  • Es wird angemerkt, daß Ausführungsformen der Erfindung, die Folgen-Endzeichen und/oder Wildcards verwenden, das Indexieren von Schlüsselfolgen, die willkürliche binäre Daten enthalten, verkomplizieren können. Um diese Komplikationen zu überwinden, können derzeit im Stand der Technik bekannte Techniken (wie das Codieren binärer Daten in alternative Formate oder das Speichern eines <KeyLen>-Feldes mit jedem Schlüsselfolgenfeld, das die Länge der Schlüsselfolge spezifiziert) angewendet werden.
  • In einer bevorzugten Ausführungsform kann die INSERT-Operation für Folgen verwendet werden, die Wildcard-Zeichen enthalten. Im Ergebnis können gesamte Sätze von Schlüsseln mit einer einzigen Index-Insert-Operation logisch gespeichert werden. Wenn man z. B. annimmt, daß "*" ein Wildcard ist und daß auf die Operation INSERT("bcd**") ein FIND("bcdef") und FIND("bcdgh") folgt (die FIND-Operation wird weiter unten detailliert beschrieben), werden beide Abfragen dieselbe Folge "bcd**" liefern. Somit kann das Merkmal der Wildcard-Indexierung von F1 zum Zwecke der Kollisionsdetektion (z. B. das logische Sperrmanagement der Datenbank) verwendet werden. In einer bevorzugten Ausführungsform der INSERT-Operation werden die folgenden Eingabe- und Ausgabeparameter verwendet.
  • Der <idxHd>-Eingabeparameter ist die Steuerung des Indexobjekts, auf das zugegriffen wird. Der <keystr>-Eingabeparameter ist ein Zeiger auf die in den Index einzufü gende Schlüsselfolge. Der <usrInfo>-Eingabeparameter ist ein Zeiger auf Daten, die der Benutzer mit der in den Index eingefügten Schlüsselfolge verknüpfen möchte.
  • Der Ausgabeparameter <keyHandle> ist eine Steuerung für das neu eingefügte Schlüsselobjekt.
  • Die in einer bevorzugten Ausführungsform der INSERT-Operation durchgeführten Schritte sind in dem Flußdiagramm 200, das in den 2 und 2a dargestellt ist, veranschaulicht. Der erste Schritt ist das Belegen 202 eines neuen Blattknotenblocks im Speicher. Als nächstes erfolgt ein Verweis 204, in dem <t> zur Wurzel des Indexbaums gemacht wird, der durch den Eingabeparameter <idxHd> angegeben wird. Die Entscheidung 206 ermittelt, ob der Index an der Wurzel leer ist. Wenn dies der Fall ist, wird die Registrierung 208 von <newKey> als neue Wurzel des Indexbaums durchgeführt und die Operation schreitet fort zur Rückgabe 284 eines Verweises auf den neuen Blattknotenblock, der in der Belegung 202 als Ausgangsparameter <keyHandle> belegt wird.
  • Wenn andererseits bei der Entscheidung 206 ermittelt wird, daß der Index an der Wurzel nicht leer ist, bestimmt die Entscheidung 210, ob ein Blattknoten erreicht worden ist. Wenn einer erreicht worden ist, wird die Entscheidung 218 durchgeführt. Wenn andererseits noch kein Blattknoten erreicht worden ist, erfolgt in der lokalen Nachfolger-Hash-Tabelle des aktuellen Knotens das Nachschlagen 212 nach der Eingabe, die dem Schlüsselfolgen-<keyStr>-Zeichen entspricht, unmittelbar nach den ersten pos-Zeichen (wie oben erläutert bezeichnet pos die Zeichenvergleichsposition für den aktuellen Knoten). Wenn im Verlauf des Nachschlagens 212 eine entsprechende Eingabe gefunden wird, erfolgt die Zuordnung 216 des verwie senen Knotens an dieser Eingabe als aktueller Knoten (d. h. der verwiesene Knoten wird der aktuelle Knoten). Wenn andererseits im Verlauf des Nachschlagens 212 eine entsprechende Eingabe gefunden wird erfolgt die Zuordnung 214 des ersten Nachfolgerknotens (der aus dem succFirst-Feld entnommen wird) als der aktuelle Knoten. In beiden Fällen wird der aktuelle Knoten dann an die Entscheidung 210 gegeben.
  • Die Entscheidung 218 wird durchgeführt, um zu ermitteln, ob eine mit der Schlüsselfolge <keyStr> identische Schlüsselfolge bereits an dem aktuellen Knoten existiert. Wenn eine solche Schlüsselfolge bereits existiert erfolgt keine Einfügung und es erfolgt die Beendigung 220 der INSERT-Operation mit einer Fehlerbedingung. Wenn jedoch noch keine identische Schlüsselfolge existiert wird der Vergleich 222 durchgeführt, um die Länge <j> der Unterfolge zu bestimmen, welche die Schlüsselfolge <keyStr> und die mit dem aktuellen Knoten verknüpfte Schlüsselfolge gemeinsam haben. Danach erfolgt, beginnend mit dem aktuellen Knoten, das Durchlaufen 224 des Baums in Aufwärtsrichtung, indem den Links gefolgt wird, die zu jedem Vaterknoten eines Knotens weisen, bis ein Knoten <t> erreicht wird, dessen Zeichenvergleichsposition pos kleiner oder gleich der Subfolgenlänge <j> ist. Wenn dieser Knoten erreicht wird, wird die Bestimmung 230 durchgeführt, ob eine äußere Baumsuche oder eine innere Baumsuche durchgeführt wird, wie es in 2a dargestellt ist.
  • Wenn die Entscheidung 232 und die Entscheidung 234 ermitteln, daß der Knoten <t> leer ist oder daß die Vergleichsposition pos von <t> gleich <j> ist, wird eine äußere Baumsuche 240 durchgeführt. Wenn andererseits der Knoten <t> nicht leer ist und die Zeichenvergleichsposi tion pos von <t> nicht gleich <j> ist, wird die innere Baumsuche 260 durchgeführt.
  • Die äußere Baumsuche 240 beinhaltet die folgenden Schritte. Es erfolgt die Registrierung 242 des Knotens <t> als Vaterknoten des neuen Knotens. Als nächstes erfolgt die Einfügung 244 eines Zeigers auf den neuen Knoten (welcher der neue Blattknotenblock ist, der in der Belegung 202 belegt wird) in der <t>'s lokalen Nachfolger-Hash-Tabelle unter dem geeigneten Schlüsselfolgenzeichen, und irgendwelche betroffenen Felder werden aktualisiert (z. B. das hashNext-Feld oder, falls die Ausführungsform eines benutzt, das hashPrev-Feld). Die Einfügung 246 des neuen Knotens in die doppelt verknüpfte Geschwisterliste des <t>'s Nachfolgerknotens wird auch durch Aktualisieren der entsprechenden sblNext- und sblPrev-Felder durchgeführt. Um zu bestimmen, ob das Vergleichspositionszeichen des Knotens <t> ein Wildcard-Zeichen ist, wird die Entscheidung 248 durchgeführt. Wenn dies der Fall ist, wird das Wildcard-Flag (falls eines in der Ausführungsform existiert) von <t> gesetzt.
  • Die Einfügung 260 in den inneren Baum beinhaltet die folgenden Schritte. Es erfolgt das Belegen 262 eines zweiten neuen Knotenblocks von dem LIFO-Speichermanager des Index, um der neue Vaterknoten zu werden. Als nächstes erfolgt die Einfügung 264 eines Zeigers auf den neuen Blattknotenblock (der in der Belegung 202 belegt wurde) in der lokalen Nachfolger-Hash-Tabelle des zweiten neuen Knotenblocks. Die Entscheidung 266 wird durchgeführt, um zu bestimmen, ob der Knoten <t> ein NULL-Verweis ist. Wenn der Knoten <t> ein NULL-Verweis ist, erfolgt die Registrierung 268 des zweiten neuen Knotenblocks als neue Wurzel des Indexbaums. Unabhängig von dem Ergebnis der Entscheidung 266 erfolgt die Einfügung 270 des zweiten neuen Knotenblocks in die lokale Nachfolger-Hash-Tabelle seines Vaters. Die innere Baumeinfügung 260 endet mit der Einfügung 272 des zweiten neuen Knotenblocks in die doppelt verknüpfte Geschwisterliste der Nachfolgerknoten seines Vaters. Die Einfügung 272 aktualisiert auch die entsprechenden sblNext- und sblPrev-Felder.
  • Unabhängig davon, ob eine äußere Baumeinfügung 240 oder eine innere Baumeinfügung 260 erfolgt, ist der nächste Schritt das Inkrementieren 280 des Nachfolgerzählers des Vaterknotens. Im Anschluß daran wird das Setzen 282 des Wildcard-Flags des Vaterknotens durchgeführt, wenn ein Wildcard unter seinen Nachfolgerknoten ist. Schließlich erfolgt die Rückgabe 284 eines Verweises auf den neuen Blattknotenblock, der in der Belegung 202 belegt wurde, als Ausgangsparameter <keyHandle>.
  • Wie durch die obigen Schritte für das oben beschriebene Flußdiagramm 200 gezeigt wurde, schafft die Verwendung eines schnellen LIFO-Speichermanagers eine Verbesserung gegenüber dem konventionellen Speichermanagement. Die Laufzeit eines konventionellen Speichermanagements hängt im allgemeinen von der Gesamtzahl belegter Speicherblöcke ab, zumindest im ungünstigsten Fall. In einer Situation, in der eine große Anzahl von Eingaben vorhanden ist, ist die konventionelle Methode häufig in prohibitiver Weise langsam. Wie gezeigt macht sich der LIFO-Speichermanager die feste Größe der Baumknoten zunutze, was ermöglicht, die Baumknoten in einem Stapel freier Eingaben anzuordnen. Weil das Ablegen eines freien Knotens auf dem Stapel oder das Entfernen eines belegten Knoten aus dem Stapel eine einzige Stapeloperation bedingt ist die Laufzeit des LIFO-Speichermanagements unabhängig von der Anzahl belegter Knoten.
  • Beispiel einer INSERT-Operation
  • Das Folgende ist eine Kurzdarstellung eines Beispiels einer INSERT-Operation. In den 3 und 4 ist dargestellt, wie ein Beispiel einer INSERT- ("cedg") Operation in dem Indexbaum 302 durchgeführt wird, der wie der Indexbaum 2 beginnt. Zuerst durchläuft FI den Indexbaum 302, um die Stelle für das Einfügen der neuen Schlüsselfolge zu finden. FI beginnt an dem Wurzelknoten 4, dessen pos-Feld 331 angibt, daß die ersten NULL-Zeichen (d. h. keines der ersten Zeichen) für alle Schlüsselfolgen, die in dem Unterbaum enthalten sind, der von dem Wurzelknoten 4 entspringt, identisch sind. Da das erste Zeichen der einzufügenden Folge ein "c" ist, schlägt FI den Hash-Block 341 in dem Hash-Tabellenfeld 340 nach. FI folgt dem "c"-Verzweigungsverweis 350 zu dem inneren Knoten 8. Nebenbei wird angemerkt, daß es eine Hash-Kollision gäbe, wenn die einzufügende Folge ein "g" als erstes Zeichen hätte (weil sowohl "c" und "g" den Hash-Block 341 belegen), und es würde dem Verweisungslink zu dem Blattknoten 5d, der in dem hashNext-Feld 19 enthalten ist, gefolgt werden.
  • An dem inneren Knoten 8 gibt das pos-Feld 11 an, daß die Zeichenvergleichsposition pos zwei ist. Daher wird das dritte Zeichen der einzufügenden Folge, nämlich "d", betrachtet, und FI schlägt in dem Hash-Tabellenfeld 18 den Hash-Block 18d nach. FI folgt der "d"-Verzweigung 360 zu dem Blattknoten 5c.
  • Als nächstes durchläuft FI den Baumindex 302 zurück nach oben, bis ein Knoten gefunden wird, dessen Zeichenvergleichsposition pos kleiner oder gleich der Länge der Unterfolge ist, die "cedg" mit der Schlüsselfolge gemein sam hat, die mit dem Blattknoten 5c (nämlich "cddh") verknüpft ist. Daraufhin sucht FI nach einem pos-Feld, in dem pos kleiner oder gleich eins ist. Das erste, dieses Kriterium erfüllende pos-Feld, das FI während des Aufwärts-Durchlaufens durch die Vaterknotenlinks 370 und 380 findet, ist das pos-Feld 331, das zufällig ein Feld des Wurzelknotens 4 ist. Weil der Knoten nicht leer ist (siehe oben Entscheidung 232) und weil das pos-Feld 331 ein pos enthält, das ungleich eins ist (siehe oben Entscheidung 234), muß eine Einfügung 260 im inneren Baum durchgeführt werden.
  • Die 4 veranschaulicht die Transformation des Indexbaums 302 in den Indexbaum 402 während der Ausführung der Einfügung 260 im inneren Baum. Zuerst werden zwei neue Knoten, ein neuer innerer Knoten 408 und ein neuer Blattknoten 405, von dem LIFO-Speichermanager (LIFO-MM) 440 des FI belegt. Der neue innere Knoten 408 wird als Nachfolger des "c"-Verzweigungsverweises 350 des Wurzelknotens 4 eingefügt. Der alte "c"-Verzweigungsnachfolger, der der innere Knoten 8 ist, wird jetzt zum Nachfolger des "d"-Verzweigungsverweises 450 des neuen inneren Knotens 408. Ferner wird der neue Blattknoten 405 der Nachfolger des "e"-Verzweigungsverweises 460 des neuen inneren Knotens 408.
  • REMOVE-Operation
  • Die REMOVE-Operation entfernt eine bestimmte Index-Eingabe, die zuvor mittels der INSERT-Operation eingefügt wurde, durch Entfernen des zugehörigen Knotens. Die zu entfernende Index-Eingabe wird durch ihre entsprechende Schlüsselsteuerung angegeben, wie sie von der INSERT-Operation oder der FIND-Operation zurückgegeben wird.
  • In einer bevorzugten Ausführungsform der REMOVE-Operation werden die folgenden Eingabeparameter verwendet. Der <idxHd>-Eingabeparameter ist die Steuerung des Indexobjekts, aus dem die Indexeingabe zu entfernen ist. Der <keyHandle>-Eingabeparamter ist die Steuerung für die zu entfernende Eingabe (oder den zu entfernenden Knoten).
  • Unter Bezugnahme auf 5 werden in einem Flußdiagramm 500 die Schritte beschrieben, die von einer bevorzugten Ausführungsform der REMOVE-Operation durchgeführt werden. Der erste Schritt ist die Entscheidung 504, um zu bestimmen, ob der zu entfernende Knoten einen Vaterknoten hat. Wenn der Knoten keinen Vaterknoten hat, erfolgt das Setzen 506 der Wurzel des Indexbaums auf einen NULL-Verweis, wonach ein Freigeben 550 von Speicherblöcken, die zu entfernten Baumknoten gehören, erfolgt. Wenn andererseits der Knoten keinen Vaterknoten hat erfolgt das Entfernen 508 des Verweises von dem Vaterknoten auf den Knoten (das succFirst-Feld des Vaterknotens muß vielleicht auch modifiziert werden). Weiterhin erfolgt das Entfernen 510 des Knotens aus der doppelt verknüpften Geschwisterliste der Nachfolgerknoten des Vaterknotens durch Aktualisieren der entsprechenden sblNext- und sblPrev-Felder. Als nächstes erfolgt das Verringern 512 des Nachfolgerzählers des Vaterknotens. An diesem Punkt sind in dem Indexbaum keine Verweise mehr auf den entfernten Knoten. Es kann jedoch noch erforderlich sein, daß die REMOVE-Operation den Indexbaum modifiziert.
  • Die Entscheidung 512 bestimmt, ob zu dem Vaterknoten mehr als ein Nachfolgerknoten verblieben ist. Wenn zu dem Vaterknoten nicht mehr als ein Nachfolgerknoten verblieben ist wird die Entscheidung 540 durchgeführt, die ermittelt, ob das Vergleichszeichen des entfernten Kno tens ein Wildcard-Zeichen war. Wenn andererseits zu dem Vaterknoten nur ein Nachfolgerknoten verblieben ist, ist der Vaterknoten als Verzweigungspunkt hinfällig und die Entscheidung 522 ermittelt, ob ein Großvater (d. h. ein Großvater des entfernten Knotens, also der Vater des Vaterknotens) existiert. Wenn kein Großvaterknoten existiert erfolgt eine Zuordnung 524 der neuen Wurzel des Indexbaums zu dem einzigen Geschwisterteil des entfernten Knotens, wonach die Entscheidung 540 ausgeführt wird, die ermittelt, ob das Vergleichszeichen des entfernten Knotens ein Wildcard-Zeichen war. Wenn andererseits kein Großvaterknoten existiert erfolgt ein Trennen 526 des Vaterknotens von der Hash-Tabelle des Großvaterknotens. Als nächstes erfolgt die Einfügung 528 des Verweises zu dem einzigen Geschwisterteil des entfernten Knotens in der Hash-Tabelle des Großvaterknotens. Das Entfernen 530 des Vaterknotens wird durchgeführt. Der Großvaterknoten ist jetzt der neue Vaterknoten.
  • Die Entscheidung 540 ermittelt, ob das Vergleichszeichen des entfernten Knotens ein Wildcard-Zeichen war. Wenn das Vergleichszeichen des entfernten Knotens ein Wildcard-Zeichen war, erfolgt das Löschen 542 des Wildcard-Flags in dem Vaterknoten. Unabhängig davon, ob das Vergleichszeichen des entfernten Knotens, ein Wildcard-Zeichen war oder nicht, endet die REMOVE-Operation mit dem Freigeben 550 von Speicherblöcken, die zu dem (den) entfernten Baumknoten gehören.
  • Wie durch die obigen Schritte in dem Flußdiagramm 500 gezeigt wurde, führt das Entfernen von Verweisen zu einem Knoten (wie das Entfernen 510 eines Knotens aus der doppelt verknüpften Geschwisterliste) zum Freigeben 550 von Speicherblöcken. Wenn eine konventionelle, einfach verknüpfte Liste verwendet würde, würde das Entfernen eines Knotens das lineare Durchsuchen einer Geschwisterliste erfordern, bis der zu entfernende Knoten gefunden wird. Dies würde der Ausführungszeit einer REMOVE-Operation eine lineare Komponente hinzufügen. Im ungünstigsten Fall müßte die gesamte Geschwisterliste durchsucht werden. Die doppelt verknüpfte Geschwisterliste unterstützt zusammen mit dem LIFO-Speichermanagement jedoch das Löschen von Knoten ohne ein lineares Absuchen von Listen, wodurch die Gesamtleistung verbessert wird.
  • Beispiel einer REMOVE-Operation
  • Das Folgende ist eine Kurzdarstellung eines Beispiels einer REMOVE-Operation. In den 6 und 7 wird dargestellt, wie ein Beispiel einer REMOVE("cdaf")-Operation in dem Indexbaum 602, der wie der Indexbaum 2 beginnt, durchgeführt wird. Zunächst wird angenommen, daß der Benutzer die notwendige Schlüsselsteuerung <keyHandle> bereitstellt, die den zu entfernenden Blattknoten (in dem Beispiel den Blattknoten 5b) angibt. Zuerst wird der Blattknoten 5b von seinem Vaterknoten, dem inneren Knoten 8, entfernt. Weil der innere Knoten 8 jetzt nur einen Nachfolgerknoten (nämlich den Blattknoten 5c) hat, ist der innere Knoten 8 als Verzweigungspunkt hinfällig und muß entfernt werden. Deshalb werden der innere Knoten 8 und der "c"-Verzweigungsverweis 350 des Wurzelknotens 4 entfernt. Die freien Knoten, der Blattknoten 5b und der innere Knoten 8 werden an den LIFO-MM 440 zurückgegeben.
  • In 7 zeigt der Indexbaum 702 den neuen Blattknoten 710, der aus dem alten Blattknoten 5c transformiert ist. Der "c"-Verzweigungsverweis 350 des Wurzelknotens 4 wird durch den "c"-Verzweigungsverweis 750 zu dem Blattknoten 710 ersetzt. Der Blattknoten 710 übernimmt die doppelt verknüpften Geschwisterlistenverweise 760 zu dem Blattknoten 5a und dem Blattknoten 5d. Das hashNext-Feld 720 des Blattknotens 710 übernimmt die Inhalte des hashNext-Felds 19.
  • FIND-Operation (genaue Übereinstimmung)
  • Die Version Exakte-Übereinstimmung der FIND-Operation durchsucht einen bestimmten Index nach einer Eingabe, die genau mit der Suchschlüsselfolge übereinstimmt. Anders als bei Abfragen mit teilweiser Übereinstimmung hat das Wildcard-Zeichen in einer exakten Suche keine bestimmte Bedeutung. Meistens stimmt eine Index-Eingabe mit der Suchfolge überein. Nach erfolgreicher Beendigung dieser Operation wird die Schlüsselsteuerung der übereinstimmenden Indexeingabe zurückgegeben. In einer bevorzugten Ausführungsform der Version Exakte-Übereinstimmung der FIND-Operation werden die folgenden Eingabe- und Ausgabeparameter verwendet.
  • Der <idxHd>-Eingabeparameter ist die Steuerung des zu suchenden Indexobjekts. Der <keyStr>-Eingabeparameter ist der Zeiger auf die Schlüsselfolge, die in dem Index zu suchen ist. Der <keyHandle>-Ausgabeparameter ist die Steuerung für die übereinstimmende Indexeingabe.
  • Die von einer bevorzugten Ausführungsform der FIND-Operation mit exakter Übereinstimmung durchgeführten Schritte sind in dem Flußdiagramm 800 der 8 skizziert. Der erste Schritt ist ein Verweis 802 auf den Wurzelknoten des zu durchsuchenden Indexbaums. Als nächstes ermittelt die Entscheidung 804, ob der aktuelle Knoten ein innerer Knoten ist. Wenn der aktuelle Knoten kein innerer Knoten ist wird zwischen der Suchschlüsselfolge und der mit dem aktuellen Knoten verknüpften Suchschlüsselfolge ein vollständiger Folgenvergleich 820 durchgeführt. Wenn andererseits der aktuelle Knoten ein innerer Knoten ist wird die Betrachtung 806 des Suchschlüsselfolgenzeichens an der Zeichenvergleichsposition des Knotens durchgeführt. Die Rückgewinnung 808 des Zeigers auf den nächsten Knoten wird durch Verwendung der Nachfolger-Hash-Tabelle des aktuellen Knotens ausgeführt. Als nächstes erfolgt die Zuordnung 810 des nächsten Knotens, der neue aktuelle Knoten zu sein. Die Entscheidung 804 wird an dem neuen aktuellen Knoten durchgeführt.
  • Zwischen der Suchschlüsselfolge und der mit dem aktuellen Knoten verknüpften Suchschlüsselfolge wird ein vollständiger Folgenvergleich 820 durchgeführt. Wenn die Folgen nicht identisch sind erfolgt die Beendigung der Suche und es wird eine Fehlerbedingung angezeigt. Wenn andererseits die Folgen identisch sind erfolgt die Rückgabe 824 des Verweises auf den aktuellen Blattknoten als Steuerung für die Indexeingabe.
  • FIND-Operation (teilweise Übereinstimmung)
  • Die Version Teilweise-Übereinstimmung der FIND-Operation kann verwendet werden, um iterativ nach einem Satz aller Indexeingaben zu suchen, die mit einer bestimmten Suchfolge übereinstimmen, die Wildcard-Zeichen hat (in einer bevorzugten Ausführungsform der Erfindung ist das Wildcard-Zeichen standardmäßig "*"). Wenn beispielsweise die Operationen INSERT("abadc"), INSERT("abbcd"), INSERT("ba*dc"), INSERT("ba*dd"), INSERT("badac"), INSERT("badbc") und INSERT("d*a**") gegeben sind, wird die Abfrage FIND("*b*cd") mit teilweiser Übereinstimmung "abbcd" und "d*a**" liefern, weil für die Zwecke dieser besonderen Suche das erste und dritte Zeichen der Eingabefolgen irrelevant sind. In einer bevorzugten Ausführungsform der FIND-Operation in der Version mit teilweiser Übereinstimmung werden die folgenden Eingabe- und Ausgabeparameter verwendet.
  • Die Eingabeparameter umfassen <idxHd>, <keyStr>, <maxResults> und <resultBuffer>. Der <idxHd>-Paramter ist die Steuerung des zu suchenden Indexobjekts. Der <keyStr>-Parameter ist ein Zeiger auf die Schlüsselfolge, die in dem Index zu suchen ist. Der <maxResults>-Parameter ist die maximale Anzahl von Schlüsselsteuerungen, die pro Iteration der FIND-Operation zurückzugeben sind. Der <resultBuffer>-Parameter ist ein Zeiger auf einen Ergebnispufferspeicher, bei dem es sich um ein Feld von Schlüsselsteuerungen handelt, das groß genug ist, um <maxResults> Eingaben aufrecht zu erhalten.
  • Die Ausgabeparameter umfassen <actResults> und <moreResults>. Der <actResults>-Parameter gibt die aktuelle Anzahl von Schlüsseln zurück, die in dem Ergebnispuffer zurückgegeben wurden. Der <moreResults>-Parameter, der auch als Suchsteuerparameter bezeichnet wird, dient als Flag, um anzugeben, ob es mehr als <maxNumber> Ergebnisse gab.
  • Die von einer bevorzugten Ausführungsform der FIND-Operation mit teilweiser Übereinstimmung durchgeführten Schritte sind in dem Flußdiagramm 900 skizziert, das in den 9 und 9a dargestellt ist. Der erste Schritt ist die Entscheidung 904, um zu ermitteln, ob dies der erste Aufruf der FIND-Operation ist. Wenn dies der erste Aufruf der FIND-Operation ist, erfolgt die Rücksetzung 906 des lokalen Rückverfolgungsstapelzeigers <sp> zu dem Wurzelknoten des Indexbaums. Wenn dies andererseits nicht der erste Aufruf der FIND-Operation ist, erfolgt das Wiederladen 908 des Stapelzeigers, der von dem vorhergehenden Aufruf der FIND-Operation gespeichert wurde. Unabhängig davon, ob dies der erste Aufruf der FIND-Operation ist, ist der nächste Schritt die Entscheidung 910 um zu ermitteln, ob der Rückverfolgungsstapel leer ist. Wenn der Rückverfolgungsstapel leer ist wird die FIND-Operation mit der Rückgabe 994 des Ergebnis-Zwischenspeichers beendet. Wenn andererseits der Rückverfolgungsstapel nicht leer ist, erfolgt die Wiedergewinnung 911 des Wurzelknotens <t> aus der Spitze des aktuellen Stapels. Dann wird die Entscheidung 912 durchgeführt, um zu ermitteln, ob <t> ein Blattknoten ist. Wenn <t> ein Blattknoten ist erfolgt die Blattknoten-Analyse 920. Wenn andererseits <t> kein Blattknoten ist, erfolgt die innere Knotenanalyse 950.
  • Die Blattknotenanalyse 920 beginnt mit dem Vergleich 922, um zu ermitteln, ob die Suchschlüsselfolge und die mit dem Blattknoten verknüpfte Suchschlüsselfolge gleich sind, und dem Vergleich 928, um zu ermitteln, ob die Suchschlüsselfolge und die mit dem Blattknoten verknüpfte Suchschlüsselfolge übereinstimmen, wenn Wildcards in Betracht gezogen werden müssen. Wenn die zwei Folgen gleich sind oder mit Wildcards übereinstimmen erfolgt die Addition 930 der mit dem Blattknoten verknüpften Indexeingabe zu dem Ergebnis-Zwischenspeicher (d. h. die Indexeingabe wird zu dem Ergebnis-Zwischenspeicher addiert). Unabhängig davon, ob die Folgen gleich sind oder anders übereinstimmen, erfolgt die Zuordnung 931 der aktuellen Zeichenposition, die erste Zeichenposition zu sein, die kein Wildcard ist und wobei die Suchschlüsselfolge und die mit dem Blattknoten verknüpfte Suchschlüsselfolge verschieden sind. Die Blattknoten-Analyse 920 endet mit dem Beschneiden 932 des Rückverfolgungsstapels. Das Beschneiden 932 des Rückverfolgungsstapels erfolgt durch iteratives Überprüfen 933 ob (a) der Stapel nicht leer ist und (b) die Zeichenvergleichsposition <pos> des Vaterknotens größer als die Zeichenvergleichsposition <j> ist, und Entfernen 934 eines Knotens aus dem Rückverfolgungsstapels, bis wenigstens eine dieser zwei Bedingungen nicht länger erfüllt ist. Nachdem die Blattknoten-Analyse 920 endet wird die Entscheidung 910 erneut durchgeführt.
  • Die innere Knotenanalyse 950 beginnt mit der Zuordnung 952 von <ch> als dem Zeichen der Suchschlüsselfolge an der Zeichenvergleichsposition des aktuellen Knotens. Die Wildcard-Überprüfung 954 ermittelt, ob <ch> ein Wildcard-Zeichen ist. Wenn <ch> ein Wildcard-Zeichen ist endet die innere Knotenanalyse 950 mit dem Schieben 970 aller Nachfolgerknoten auf den Rückverfolgungsstapel. Das Schieben 970 führt diese Aufgabe dadurch aus, daß den Geschwister-Verweisen in der Nachfolgerliste von <t> gefolgt wird, was bedeutet, daß der gesamte Unterbaum, der von <t> entspringt, für die weitere Suche markiert wird. Wenn andererseits <ch> kein Wildcard-Zeichen ist, erfolgt das Nachschlagen 955 der Hash-Tabelle. Das Nachschlagen 955 findet den mit <ch> verknüpften Nachfolgerknoten (oder alternativ, wenn es keinen mit <ch> verknüpften Nachfolgerknoten gibt, den ersten Nachfolgerknoten) und schiebt den Knoten auf den Rückverfolgungsstapel. Als nächstes ermittelt die Entscheidung 956, ob <t> unter seinen Nachfolgerknoten ein Wildcard hat. Wenn <t> keinen Nachfolgerknoten mit Wildcard hat endet die innere Knotenanalyse 950. Wenn andererseits <t> einen Nachfolgerknoten mit Wildcard hat endet die innere Knotenanalyse 950 mit dem Schieben 958 des Wildcard-Nachfolgerknotens auf den Rückverfolgungsstapel. Nachdem die innere Knotenanalyse 950 endet, wird die Entscheidung 910 erneut durchgeführt.
  • Beispiel einer FIND-Operation (teilweise Übereinstimmung) Das Folgende ist eine Darstellung eines Beispiels einer FIND-Operation mit teilweiser Übereinstimmung. In 10 ist ein in dem Indexbaum 1002 ausgeführtes Beispiel einer FIND("*b*cd") Operation dargestellt. Der Indexbaum 1002 umfaßt die Knoten 1010, 1020, 1030, 1040, 1050, 1060, 1070, 1080, 1090, 1100, 1110 und 1120. Der Knoten 1010 ist der Wurzelknoten des Indexbaums 1002; deshalb hat er eine Zeichenvergleichsposition pos null. Der innere Knoten 1020 hat ein pos von zwei und ein Vergleichszeichen "a"; der innere Knoten 1030 hat ein pos von zwei und ein Vergleichszeichen "b"; der innere Knoten 1070 hat ein pos von vier und ein Vergleichszeichen "*" (das Wildcard-Zeichen); der innere Knoten 1080 hat ein pos von drei und ein Vergleichszeichen "d". Der Blattknoten 1040 ist ein Nachfolgerknoten des Knotens 1010 und ist mit der Schlüsselfolge "d*a**" verknüpft. Die Blattknoten 1050 und 1060 sind Nachfolgerknoten des Knotens 1020 und sind jeweils mit den Schlüsselfolgen "abadc" und "abbcd" verknüpft. Die Blattknoten 1090 und 1100 sind Nachfolgerknoten des Knotens 1070 und jeweils mit den Schlüsselfolgen "ba*dc" und "ba*dd" verknüpft. Die Blattknoten 1110 und 1120 sind Nachfolgerknoten des Knotens 1080 und sind jeweils mit den Schlüsselfolgen "badac" und "badbc" verknüpft.
  • FI beginnt die Suche an dem Wurzelknoten 1010 des Indexbaums 1002. Da für den Knoten 1010 pos gleich null ist, sieht FI nach dem ersten Zeichen der Suchschlüsselfolge "*b*cd". Dies ist ein Wildcard-Zeichen, so daß FI jeden Nachfolgerknoten des Knotens 1010 (d. h. die Knoten 1020, 1030 und 1040) auf den Rückverfolgungsstapel schiebt. Es ist zu beachten, daß der Rückverfolgungsstapel jetzt von oben (zuerst) nach unten (als letztes) die Knoten 1020, 1030 und 1040 hat. Als nächstes wird der erste Knoten in dem Rückverfolgungsstapel, der Knoten 1020, von der Spitze hervorgeholt. Da der Knoten 1020 ein pos von zwei hat wird das dritte Zeichen der Suchschlüsselfolge überprüft. Dies ist wiederum ein Wildcard-Zeichen, so daß FI jeden Nachfolgerknoten des Knotens 1020 (d. h. die Knoten 1050 und 1060) auf den Rückverfolgungsstapel schiebt. Der Rückverfolgungsstapel hat jetzt, von oben nach unten, die Knoten 1050, 1060, 1030 und 1040.
  • Als nächstes wird der Knoten 1050 von der Spitze des Rückverfolgungsstapels hervorgeholt. Da dies ein Blattknoten ist, ermittelt FI die erste Nicht-Wildcard-Zeichenposition <j>, in der sich die Suchschlüsselfolge von der Schlüsselfolge unterscheidet, die mit dem Knoten 1050 verknüpft ist. Die Schlüsselfolgen "*b*cd" und "abadc" unterscheiden sich in dem vierten Zeichen (da sie in den ersten drei Zeichen übereinstimmen ist <j> drei) und der Knoten 1050 wird als Nichtübereinstimmung verworfen. Der Knoten 1060 wird von der Spitze des Rückverfolgungsstapels hervorgeholt. Dies ist auch ein Blattknoten und FI sucht nach der ersten Nicht-Wildcard-Zeichenposition <j>, in der sich der Suchschlüssel von der Suchfolge unterscheidet, die mit dem Knoten 1060 verknüpft ist. Da jedoch "*b*cd" und "abbcd" übereinstimmen wird die mit dem Knoten 1060 verknüpfte Schlüsseleingabe die erste Addition zu dem Ergebnis-Zwischenspeicher.
  • FI ermittelt, daß es noch Knoten in dem Rückverfolgungsstapel gibt, deshalb wird der nächste Knoten, der Knoten 1030, von der Spitze hervorgeholt. Der Knoten 1030 ist zufällig ein innerer Knoten, der ein pos von zwei hat und so wird das dritte Zeichen der Suchschlüsselfolge überprüft. Dies ist wiederum ein Wildcard-Zeichen, und so schiebt FI jeden Nachfolgerknoten des Knotens 1030 (d. h. die Knoten 1070 und 1080) auf den Rückverfolgungsstapel. Der Rückverfolgungsstapel hat jetzt, von oben nach unten, die Knoten 1070, 1080, 1030 und 1040.
  • Es gibt noch Knoten in dem Rückverfolgungsstapel, und so wird der Knoten 1070 von der Spitze hervorgeholt. Der Knoten 1070 ist ein innerer Knoten, der ein pos von vier hat, und so wird das fünfte Zeichen der Suchschlüsselfolge überprüft. Das Zeichen an dieser Position ist "d", und so wird der "d"-Verzweigung 1072 des Knotens 1070 zu dem Knoten 1100 gefolgt (wobei der Knoten 1090 in dem Prozeß verworfen wird).
  • Der Knoten 1100 ist ein Blattknoten, und so ermittelt FI die erste Nicht-Wildcard-Zeichenposition <j>, in der sich die Suchschlüsselfolge von der Schlüsselfolge unterscheidet, die mit dem Knoten 1050 verknüpft ist. Die Schlüsselfolgen "*b*cd" und "ba*dd" unterscheiden sich in dem zweiten Zeichen (da sie in dem ersten Zeichen übereinstimmen ist <j> eins) und der Knoten 1100 wird als Nichtübereinstimmung verworfen. An dieser Stelle wird das heuristische Abschneiden eingesetzt, um einen zusätzlichen gesamten Unterbaum zu verwerfen. Es ist eine Eigenschaft des FI-Baums, daß sich die Schlüsselfolge auch von jedem. anderen Knoten, dessen pos des, Vaters größer als eins ist, unterscheiden muß, wenn sich die Schlüsselfolge von dem Blattknoten 1100 unterscheidet, wenn <j> gleich eins ist. Diese Eigenschaft leitet sich aus der Tatsache ab, daß alle Schlüsselfolgen, die mit einem Unterbaum verknüpft sind, eine Vorsilbe gemeinsam haben, deren Länge gleich dem pos des inneren Knotens an der Wurzel des Unterbaums ist. Da der Knoten 1030 ein pos von zwei hat können alle Knoten in dem Unterbaum, die noch in dem Rückverfolgungsstapel sind (nämlich die Knoten 1070 und 1080), verworfen werden, wodurch der Indexbaum beschnitten wird.
  • Der einzige noch in dem Rückverfolgungsstapel verbleibende Knoten, der Knoten 1040, wird hervorgeholt. Dies ist ein Blattknoten und FI sucht die erste Nicht-Wildcard-Zeichenposition <j>, in der sich die Suchschlüsselfolge von der Schlüsselfolge unterscheidet, die mit dem Knoten 1040 verknüpft ist. "*b*cd" und "d*c**" stimmen jedoch überein, so daß der mit der Sucheingabe verknüpfte Knoten 1040 dem Ergebniszwischenspeicher hinzugefügt wird. Es gibt keine zu untersuchenden Knoten mehr und der Ergebnisstapel wird zurückgegeben.
  • In 11 ist eine vorteilhafte Anwendung des FI-Verfahrens gemäß der Erfindung zum Durchführen eines logischen Sperrmanagements dargestellt. FI kann für die Detektion von Kollisionen oder das Management von Kollisionen in Datenbank-Anwendungen wie Systemen für Personal-Management, Finanzen, Logistik, Arbeitsablauf, Organisationsverwaltung und anderen Systemen angewendet werden. In solchen Anwendungen greift eine Anzahl von Benutzern, z. B. die Benutzer 1 bis 6 in 12, auf die in der Datenbank 1200 gespeicherten Daten zu. Es wird ein logisches Sperrmanagement durchgeführt, um zu verhindern, daß mehrere Benutzer gleichzeitig mit einer Anfrage oder einer Operation auf denselben Datensatz in der Datenbank 1200 zugreifen, z. B. durch Schreiben oder Löschen, wodurch der Datensatz geändert wird. Es muß gewährleistet werden, daß Änderungen der Datensätze in einer definierten Reihenfolge durch einen Benutzer nach dem anderen durchgeführt werden.
  • Um dies zu gewährleisten wird ein Sperrmanager 1201 eingerichtet, um Kollisionen zwischen Anfragen der Benutzer an die Datenbank 1200 zu detektieren. In 12 gibt es beispielsweise eine Kollision zwischen den Anfragen der Benutzer 1 und 6. Offensichtlich ist die Leistung einer Multi-User-Umgebung einer Datenbank sehr kritisch in Bezug auf die Leistung des Sperrmanagers 1201, weil aufgrund der Tatsache, daß die Anfrage jedes Benutzers den Sperrkollisionstest durchlaufen muß, bevor sie auf die Datenbank 1200 zugreift, der Sperrmanager 1201 zu einem Flaschenhals für den Durchsatz des gesamten Systems werden kann.
  • Erfindungsgemäß umfaßt ein Verfahren zur Kollisionserkennung oder zum Kollisionsmanagement von Anfragen mehrerer Benutzer, die auf eine Datenbank 1200 zugreifen, die eine Mehrzahl von Eingabefolgen enthält, insbesondere ein Verfahren zum Durchführen eines Sperrmanagements, das Aufrechterhalten einer dynamischen Sperrtabelle 1202, die die Anfragen der Benutzer enthält, wobei in der Sperrtabelle 1202 die Anfragen gemäß der Erfindung indexiert sind, insbesondere nach dem FI-Verfahren. In Verbindung mit der Anfrage eines Benutzer wird in der Sperrtabelle 1202 eine Abfrage durchgeführt, insbesondere eine FI-Suche, bevor die Anfrage des Benutzers an die Datenbank 1200 weitergeleitet wird. Der Sperrmanager 1201 hält eine FI-indexierte Sperrtabelle 1202 aufrecht, in der sich die Sperren befinden, die von den Benutzern angefragt werden.
  • Beispielsweise wird die Anfrage "**5" des Benutzers 6 zurückgewiesen, weil die Anfrage "CY5" des Benutzers 5 auf denselben Datensatz zugreift.
  • Wenn beispielsweise eine Schreibanfrage des Benutzers 1 für den Datensatz gestellt wird, der den Index "DXO" hat, wird zuerst eine Insert-Operation in der FI-indexierten Sperrtabelle 1202 durchgeführt, wodurch der Index "DXO" in den FI-Suchbaum eingefügt wird. Vorausgesetzt, daß die Insert-Operation erfolgreich durchgeführt wird und der Index "DXO" in dem FI-Suchbaum eingefügt werden konnte, kann der Benutzer 1 in dem entsprechenden Datensatz in der Datenbank 1200 einen Schreibvorgang durchführen. Wenn andererseits die Insert-Operation nicht erfolgreich war, war die Indexfolge "DXO" bereits als Blattknoten in dem FI-Suchbaum enthalten, was durch den Sperrmanager 1201 ermittelt wird. In diesem Fall wird eine Kollision angezeigt und der Schreibzugriff des Benutzers 1 auf den zugehörigen Datensatz in der Datenbank 1200 wird zurückgewiesen.
  • Wenn ein erfolgreicher Schreibzugriff auf die Datenbank 1200 beendet wird, wird in der FI-Sperrtabelle 1202 die Remove-Operation durchgeführt, wodurch der Blattknoten mit der indexierten Folge "DXO" gelöscht wird. Danach können andere Benutzer auf entsprechende Datensätze in der Datenbank 1200 zugreifen.
  • Sperren können sowohl für einzelne (d. h. vollständig spezifizierte) Datenbanktabellen-Eingaben (z. B. "AX3") als auch für gesamte Sätze von (z. B. teilweise spezifizierten) Eingaben (z. B. "B**", wobei der "*" ein Wildcard darstellt, das irgendein Buchstabe des zugrundeliegenden Alphabets ist) gesetzt werden.
  • Im Hinblick darauf, daß alle Anfragen und Zugriffe auf die Datenbank 1200 in einen einzigen FI-Suchbaum abgebildet werden, ist die Reaktion und das Leistungsvermögen des Sperrmanagers 1201 wichtig für die Gesamtleistung von Zugriffen auf die Datenbank 1200. Wenn der Sperrmanager 1201 eine FI-indexierte Sperrtabelle 1202 aufrecht erhält, resultieren daraus kurze Antwortzeiten und daraus eine gute Leistung des Sperrmanagers 1201. In dieser Hin sicht können insbesondere die folgenden Merkmale vorteilhaft sein: der Suchbaum ist als Vorsilbenbaum aufgebaut, lokale Hash-Tabellen werden verwendet, Anfragen mit teilweiser Übereinstimmung werden durchgeführt, Leistung des last-in-first-out-Speichermanagements, Durchführung des Beschneidens und/oder Durchführen des Rückverfolgens während der Suche.
  • Ein Vorteil der Erfindung besteht darin, daß in der Sperrtabelle 1202 auch teilweise spezifizierte Folgen (z. B. "ab*c" oder "*bc*") gespeichert werden können. Aus diesem Grund ist es möglich, Teile von Datensätzen, auf die durch eine einzige Indexeinfügung zugegriffen wird, in die FI-Sperrtabelle 1202 abzubilden. Daraus folgt, daß es nicht notwendig ist, individuelle Datensätze, die zum Teil enthalten sind, zu markieren, wie es in bekannten Suchalgorithmen wie linearer Suche und Hashing erforderlich ist. Die Möglichkeit, eine Index-Anfrage durchzuführen, die teilweise spezifiziert ist, verringert die erforderliche Suchzeit in der FI-Sperrtabelle 1202, zusätzlich zu den oben genannten Merkmalen des FI-Suchbaums und des darauf basierenden Suchverfahrens.
  • Vergleich mit anderen Suchmethoden
  • Im Folgenden wird ein Überblick darüber gegeben, wie sich eine aktuelle Implementierung der Erfindung, die als "FI" bezeichnet wird, mit anderen, oben beschriebenen Verfahren vergleicht. Die Tabelle 1 veranschaulicht die Zeit in Mikrosekunden für einen vollständigen INSERT/FIND/REMOVE-Zyklus, der auf einer Intel Pentium P180 Maschine auszuführen ist. Für die Zwecke dieses Vergleichs haben das FI-Programm und gebräuchlicherweise verwendete UNIX-Standard-Bibliotheken für das. Indexieren von Folgen und für das Suchen Arbeitsabläufe auf einer realen Datenbasis (in der die Eingaben nicht gleichmäßig in einem Suchbaum verteilt sind) durchgeführt. Die BTREE-Suche wurde unter Verwendung der UNIX/XPG4-tsearch(3C)-Standardbibliothek für einen binären Suchbaum durchgeführt, die Hash-Suche wurde unter Verwendung der UNIX/XPG4-hsearch(3C)-Standardbibliothek für Hash-Tabellen durchgeführt, wogegen die lineare Suche mit einer direkten, auf einer doppelt verknüpften Liste basierenden linearen Suche durchgeführt wurde.
  • Es ist festzustellen, daß die Laufzeit für die schnelle Folgenmethode in der Größenordnung von einigen 10 Mikrosekunden bleibt, sogar wenn mehr als eine Million Eingaben durchsucht werden.
  • Es wurde auch gezeigt, daß die schnelle Folgenmethode eine überlegene Leistung und Robustheit gegenüber der Größe der zu suchenden Schlüsselfolgen bereitstellt. Die Tabelle 2 veranschaulicht die Zeit in Mikrosekunden, die FI und Hash benötigen, um Suchen in Datenbanken durchzuführen, die Schlüsselfolgen unterschiedlicher Länge beinhalten. Die Laufzeit für die schnelle Folgenmethode ändert sich nur geringfügig, sogar wenn die Schlüsselfolgen um Größenordnungen größer sind.
  • In Tabelle 3 ist eine Zusammenfassung der Eigenschaften der Erfindung und anderer Suchmethoden dargestellt. Ein Plus "+" in einer Zelle gibt an, daß die Suchmethode besonders gut geeignet (oder robust) hinsichtlich der angegebenen Eigenschaft ist.
  • Obwohl fundamentale neue Merkmale der Erfindung, wie sie in Ausführungsformen hierzu angewendet werden, dargestellt und beschrieben und ausgeführt worden sind, ist es selbstverständlich, daß ein Fachmann verschiedene Weglassungen und Ersetzungen und Änderungen in Ausgestaltung und Details der Erfindung, wie hierin offenbart, machen kann, ohne vom Geist der Erfindung abzuweichen. Es ist ausdrücklich vorgesehen, daß alle Kombinationen derjenigen Elemente und/oder Verfahrensschritte, die im wesentlichen dieselbe Funktion in im wesentlichen derselben Weise erfüllen, um dieselben Ergebnisse zu erzielen, im Bereich der Erfindung liegen. Es besteht deshalb die Absicht, wie angegeben nur durch den Schutzbereich der beigefügten Patentansprüche beschränkt zu sein.
  • Tabelle 1
    Figure 00500001
  • Tabelle 2
    Figure 00500002
  • Tabelle 3
    Figure 00510001
  • Bezugszeichenliste
    • 2
    Indexbaum
    4
    Wurzelknoten
    5a
    Blattknoten
    5b
    Blattknoten
    5c
    Blattknoten
    5d
    Blattknoten
    6a
    Schlüsselfolgenfeld
    6b
    Schlüsselfolgenfeld
    6c
    Schlüsselfolgenfeld
    6d
    Schlüsselfolgenfeld
    7a
    Informationsfeld
    7b
    Informationsfeld
    7c
    Informationsfeld
    7d
    Informationsfeld
    8
    innerer Knoten
    10
    Vaterknoten
    11
    pos-Feld
    12
    succ-Feld
    13
    succFirst-Feld
    14
    ch-Feld
    15
    sblPrev-Feld
    16
    sblNext-Feld
    17
    lokale Nachfolger-Hash-Tabelle
    18
    Hash-Tabellenfeld
    18a
    Hashblock
    18b
    Hashblock
    18c
    Hashblock
    18d
    Hashblock
    19
    hashNext-Feld
    20
    Vaterfeld
    21
    pos-Feld
    22
    succ-Feld
    24a
    ch-Feld
    24b
    ch-Feld
    24c
    ch-Feld
    24d
    ch-Feld
    25
    sblPrev-Feld
    26
    sblNext-Feld
    27
    Schlüsselfeld
    28
    Feld
    200
    Flußdiagramm
    202
    Belegung
    204
    Verweis
    206
    Entscheidung
    208
    Registrierung
    210
    Entscheidung
    212
    Nachschlagen
    214
    Zuordnung
    216
    Zuordnung
    218
    Entscheidung
    220
    Beendigung
    222
    Vergleich
    224
    Durchlaufen
    230
    Bestimmung
    232
    Entscheidung
    234
    Entscheidung
    240
    Einfügung äußerer Baum
    242
    Registrierung
    244
    Einfügung
    246
    Einfügung
    248
    Entscheidung
    260
    Einfügung innerer Baum
    262
    Belegen
    264
    Einfügung
    266
    Entscheidung
    268
    Registrierung
    270
    Einfügung
    272
    Einfügung
    280
    Erhöhung
    282
    Setzen
    284
    Rückgabe
    302
    Indexbaum
    331
    pos-Feld
    340
    Hash-Tabellenfeld
    341
    Hashblock
    350
    Verzweigungsverweis
    360
    Verzweigung
    370
    Verweis
    380
    Verweis
    402
    Indexbaum
    405
    Blattknoten
    408
    innerer Knoten
    440
    Speichermanager
    460
    Verweis
    500
    Flußdiagramm
    504
    Entscheidung
    506
    Setzen
    508
    Entfernen
    510
    Entfernen
    512
    Verringern
    520
    Entscheidung
    522
    Entscheidung
    524
    Zuordnung
    526
    Trennen
    528
    Einfügen
    530
    Entfernen
    540
    Entscheidung
    542
    Löschen
    550
    Freigeben
    602
    Indexbaum
    702
    Indexbaum
    710
    Blattknoten
    720
    hashNext-Feld
    750
    Verzweigungsverweis
    760
    Verweis
    800
    Flußdiagramm
    802
    Verweis
    804
    Entscheidung
    806
    Betrachtung
    808
    Wiedergewinnung
    810
    Zuordnung
    820
    Vergleich
    822
    Beendigung
    824
    Rückgabe
    900
    Flußdiagramm
    904
    Entscheidung
    906
    Rücksetzung
    908
    Wiederladen
    910
    Entscheidung
    911
    Wiedergewinnung
    912
    Entscheidung
    920
    Blattknotenanalyse
    922
    Vergleich
    928
    Vergleich
    930
    Addition
    932
    Abschneiden
    933
    Überprüfen
    934
    Entfernen
    950
    innere Knotenanalyse
    952
    Zuordnung
    954
    Wildcard-Überprüfung
    955
    Nachschlagen
    970
    Schieben
    1002
    Indexbaum
    1010
    Knoten
    1020
    Knoten
    1030
    Knoten
    1040
    Knoten
    1050
    Knoten
    1060
    Knoten
    1070
    Knoten
    1080
    Knoten
    1090
    Knoten
    1100
    Knoten
    1110
    Knoten
    1120
    Knoten
    1200
    Datenbank
    1201
    Sperrmanager
    1202
    Sperrtabelle

Claims (28)

  1. Verfahren zum Indexieren einer Mehrzahl von Eingabefolgen, wobei jede der Mehrzahl von Eingabefolgen eine Zeichenfolge ist, unter Verwendung eines Suchbaums, wobei der Suchbaum umfaßt: eine Mehrzahl verknüpfter Knoten, die einen Wurzelknoten (4) umfassen, eine Mehrzahl innerer Knoten, wobei jeder der Mehrzahl der inneren Knoten mit einem Zeichen oder einer Teilfolge von Zeichen verknüpft ist, und eine Mehrzahl von Blattknoten (5a, 5b, 5c, 5d), die mit der Mehrzahl der Eingabefolgen verknüpft sind, wobei jeder der Mehrzahl der inneren Knoten ferner umfaßt: (a) einen Verweis auf einen Vaterknoten, wobei der Vaterknoten einer der anderen der Mehrzahl der inneren Knoten oder der Wurzelknoten (4) ist; (b) ein erstes Datenfeld, das die Position eines Zeichenvergleichs enthält, die die Anzahl von Zeichen in dem Zeichen oder der Teilfolge von Zeichen angibt, die mit dem einen Knoten der Mehrzahl von inneren Knoten verknüpft ist; (c) ein zweites Datenfeld, das ein Vergleichszeichen enthält, wobei das Vergleichszeichen benutzt wird, um zu bestimmen, ob das Zeichen oder die Teilfolge der Zeichen, die mit dem einen der Mehrzahl der inneren Knoten verknüpft ist, in einer Eingabefolge an einer Zeichenposition der Eingabefolge enthalten ist, die mit der Position des Zeichenvergleichs verknüpft ist; (d) einen Verweis auf wenigstens zwei Nachfolgerknoten; und (e) ein Hash-Tabellen Datenfeld (18), das eine vorgegebene Anzahl von Hash-Blöcken (18a, 18b, 18c, 18d) enthält.
  2. Verfahren zum Indexieren einer Mehrzahl von Folgen nach Anspruch 1, wobei die Anzahl von Zeichen in jeder der Mehrzahl der Eingabefolgen die gleiche ist.
  3. Verfahren zum Indexieren einer Mehrzahl von Folgen nach Anspruch 1 oder 2, wobei wenigstens einer der Mehrzahl der inneren Knoten einen Verweis auf einen Vaterknoten hat, der eine Position eines Zeichenvergleichs hat, die wenigstens um zwei kleiner als die Position des Zeichenvergleichs des wenigstens einen der Mehrzahl der inneren Knoten ist.
  4. Verfahren zum Indexieren einer Mehrzahl von Folgen nach einem der vorhergehenden Ansprüche, wobei jeder der Mehrzahl der inneren Knoten mit einer Stufe verknüpft ist und ferner eine Verweisverknüpfung zu wenigstens einem der Mehrzahl der verknüpften Knoten, die auch mit der Stufe verknüpft sind, umfaßt.
  5. Verfahren zum Indexieren einer Mehrzahl von Folgen nach Anspruch 4, wobei wenigstens manche der Verweisverknüpfungen eine doppelt verknüpfte Liste bilden.
  6. Verfahren zum Indexieren einer Mehrzahl von Folgen nach einem der vorhergehenden Ansprüche, wobei die Zeichenfolge eine Folge von alphanumerischen Zeichen ist und wenigstens eine der Mehrzahl der Eingabefolgen ein Wildcard-Zeichen enthält.
  7. Verfahren zum Indexieren einer Mehrzahl von Folgen nach einem der vorhergehenden Ansprüche, wobei eine Suche des Suchbaums einen Last-in-first-out Speichermanager zum Verwalten eines Stapelspeichers verwendet, der Verknüpfungen zu wenigstens manchen der Mehrzahl der verknüpften Knoten hat.
  8. Verfahren zum Indexieren einer Mehrzahl von Folgen nach Anspruch 7, wobei die Suche Zurückverfolgen verwendet.
  9. Verfahren zum Indexieren einer Mehrzahl von Folgen nach Anspruch 7 oder 8, wobei die Suche das Beschneiden des Stapelspeichers verwendet.
  10. Verfahren zum Suchen nach einer bestimmten Folge, die aus einer Mehrzahl von Zeichen besteht, in einer Mehrzahl von Folgen, wobei jede der Mehrzahl von Folgen eine Zeichenfolge ist, umfassend folgende Schritte: Erzeugen eines Suchbaums, wobei die Mehrzahl der Folgen eine Mehrzahl von Eingabefolgen bildet; Bilden einer Abfrage, die mit der bestimmten Folge verknüpft ist; und Durchlaufen des Suchbaums unter Verwendung der Abfrage und unter Bereitstellung eines Index zu jeder der Mehrzahl der Folgen, die mit der bestimmten Folge übereinstimmt, wobei die Mehrzahl der Eingabefolgen nach einem der Ansprüche 1 bis 9 indexiert ist, und wobei der Suchbaum umfaßt: eine Mehrzahl verknüpfter Knoten, die einen Wurzelknoten (4) umfassen, eine Mehrzahl innerer Knoten, wobei jeder der Mehrzahl der inneren Knoten mit einem Zeichen oder einer Teilfolge von Zeichen verknüpft ist, und eine Mehrzahl von Blattknoten (5a, 5b, 5c, 5d), die mit der Mehrzahl der Eingabefolgen verknüpft sind, wobei jeder der Mehrzahl der inneren Knoten ferner umfaßt: (a) einen Verweis auf einen Vaterknoten, wobei der Vaterknoten einer der anderen der Mehrzahl der inneren Knoten oder der Wurzelknoten (4) ist; (b) ein erstes Datenfeld, das die Position eines Zeichenvergleichs enthält, die die Anzahl von Zeichen in dem Zeichen oder der Teilfolge von Zeichen angibt, die mit dem einen Knoten der Mehrzahl von inneren Knoten verknüpft ist; (c) ein zweites Datenfeld, das ein Vergleichszeichen enthält, wobei das Vergleichszeichen benutzt wird, um zu bestimmen, ob das Zeichen oder die Teilfolge der Zeichen, die mit dem einen der Mehrzahl der inneren Knoten verknüpft ist, in einer Eingabefolge an einer Zeichenposition der Eingabefolge enthalten ist, die mit der Position des Zeichenvergleichs verknüpft ist; (d) einen Verweis auf wenigstens zwei Nachfolgerknoten; und (e) ein Hash-Tabellen Datenfeld (18), das eine vorgegebene Anzahl von Hash-Blöcken (18a, 18b, 18c, 18d) enthält.
  11. Verfahren zum Suchen nach einer bestimmten Folge nach Anspruch 10, wobei der Suchbaum nach einem der Ansprüche 2 bis 9 erzeugt wird.
  12. Verfahren zum Suchen nach einer bestimmten Folge nach Anspruch 10 oder 11, wobei die bestimmte Folge aus einer Mehrzahl alphanumerischer Zeichen und wenigstens einem Wildcard-Zeichen besteht.
  13. Verfahren zum Suchen nach einer bestimmten Folge nach einem der Ansprüche 10 bis 12, wobei das Durchlaufen einen Last-in-first-out Speichermanager zum Verwalten eines Stapelspeichers verwendet, der Verknüpfungen zu wenigstens manchen der Mehrzahl der verknüpften Knoten hat.
  14. Verfahren zum Suchen nach einer bestimmten Folge nach Anspruch 13, wobei das Durchlaufen das Zurückverfolgen verwendet.
  15. Verfahren zum Suchen nach einer bestimmten Folge nach Anspruch 13 oder 14, wobei das Durchlaufen das Beschneiden des Stapelspeichers verwendet.
  16. Verfahren zum Suchen nach einer bestimmten Folge nach einem der Ansprüche 10 bis 15, wobei die Schritte des Erzeugens eines Suchbaums und des Bildens einer Abfrage, die mit der bestimmten Folge verknüpft ist, auf einem System für Personalmanagement, Finanzen, Logistik, Arbeitsablauf, Personalverwaltung, Organisationsverwaltung, Lohnbuchführung, Zeitmanagement, Mitarbeiterförderung oder einem Netzwerksystem, zum Beispiel einem Internet- oder Intranetsystem, insbesondere einem R/3-System, durchgeführt werden.
  17. Verfahren zur Kollisionserkennung oder zum Kollisionsmanagement von Anfragen mehrerer Benutzer, die auf eine Datenbank (1200) zugreifen, die eine Mehrzahl von Eingabefolgen enthält, insbesondere ein Verfahren zum Durchführen eines Sperrmanagements, umfassend das Aufrechterhalten einer dynamischen Sperrtabelle (1202), die die Anfragen der Benutzer enthält, wobei in der Sperrtabelle (1202) die Anfragen nach Anspruch 1 indexiert sind und in der Sperrtabelle (1202) eine Abfrage durchgeführt wird, die mit einer Anfrage eines Benutzers an die Datenbank (1202) verknüpft ist, bevor die Anfrage des Benutzers an die Datenbank (1200) weitergeleitet wird.
  18. Verfahren zur Kollisionserkennung oder zum Kollisionsmanagement nach Anspruch 17, wobei die Anfragen nach einem der Ansprüche 2 bis 9 indexiert sind.
  19. Verfahren zur Kollisionserkennung oder zum Kollisionsmanagement nach Anspruch 17 oder 18, in dem die Abfrage der Sperrtabelle (1202) nach einem Verfahren gemäß einem der Ansprüche 10 bis 16 durchgeführt wird.
  20. Computerlesbares Medium, auf dem eine Mehrzahl von Anweisungen gespeichert sind, wobei die Mehrzahl der Anweisungen Anweisungen enthalten, die, wenn sie auf einem Prozessor ausgeführt, werden, den Prozessor veranlassen, die Schritte des Indexierens einer Mehrzahl von Eingabefolgen nach einem der Ansprüche 1 bis 9 durchzuführen.
  21. Computerlesbares Medium, auf dem eine Mehrzahl von Anweisungen gespeichert sind, wobei die Mehrzahl der Anweisungen Anweisungen enthalten, die, wenn sie auf einem Prozessor ausgeführt werden, den Prozessor veranlassen, die Schritte des Suchens nach einer bestimmten Folge nach einem der Ansprüche 10 bis 16 durchzuführen.
  22. Computerlesbares Medium, auf dem eine Mehrzahl von Anweisungen gespeichert sind, wobei die Mehrzahl der Anweisungen Anweisungen enthalten, die, wenn sie auf einem Prozessor ausgeführt werden, den Prozessor veranlassen, die Schritte des Durchführens einer Kollisionserkennung oder eines Kollisionsmanagements nach Anspruch 17 durchzuführen.
  23. System zum Suchen nach einer bestimmten Folge, die aus einer Mehrzahl von Zeichen besteht, in einer Mehrzahl von Folgen, wobei jede der Mehrzahl der Folgen eine Zeichenfolge ist, umfassend ein Mittel zum Erzeugen eines Suchbaums mit einer Mehrzahl verknüpfter Knoten, die einen Wurzelknoten (4) umfassen, eine Mehrzahl innerer Knoten, wobei jeder der Mehrzahl der inneren Knoten mit einem Zeichen oder einer Teilfolge von Zeichen verknüpft ist, und eine Mehrzahl von Blattknoten (5a, 5b, 5c, 5d), die mit der Mehrzahl der Eingabefolgen verknüpft sind, wobei jeder der Mehrzahl der inneren Knoten ferner umfaßt: (a) einen Verweis auf einen Vaterknoten, wobei der Vaterknoten einer der anderen der Mehrzahl der inneren Knoten oder der Wurzelknoten ist; (b) ein erstes Datenfeld, das die Position eines Zeichenvergleichs enthält, die die Anzahl von Zeichen in dem Zeichen oder der Teilfolge von Zeichen angibt, die mit dem einen Knoten der Mehrzahl von inneren Knoten verknüpft ist; (c) ein zweites Datenfeld, das ein Vergleichszeichen enthält, wobei das Vergleichszeichen benutzt wird, um zu bestimmen, ob das Zeichen oder die Teilfolge der Zeichen, die mit dem einen der Mehrzahl der inneren Knoten verknüpft ist, in einer Eingabefolge an einer Zeichenposition der Eingabefolge enthalten ist, die mit der Position des Zeichenvergleichs verknüpft ist; (d) einen Verweis auf wenigstens zwei Nachfolgerknoten; und (e) ein Hash-Tabellen Datenfeld (18), das eine vorgegebene Anzahl von Hash-Blöcken (18a, 18b, 18c, 18d) enthält, ein Mittel zum Bilden einer Abfrage, die mit der bestimmten Folge verknüpft ist; und ein Mittel zum Durchlaufen des Suchbaums zum Bereitstellen eines Index zu jeder der Mehrzahl der Folgen, die mit der bestimmten Folge übereinstimmt.
  24. System nach Anspruch 23, wobei die Anzahl von Zeichen in jeder der Mehrzahl der Eingabefolgen die gleiche ist.
  25. System nach Anspruch 23 oder 24, wobei wenigstens einer der Mehrzahl der inneren Knoten einen Verweis auf einen Vaterknoten hat, der eine Position eines Zeichenvergleichs hat, die wenigstens um zwei kleiner als die Position des Zeichenvergleichs des wenigstens einen der Mehrzahl der inneren Knoten ist.
  26. System nach einem der Ansprüche 23 bis 25, wobei jeder der Mehrzahl der inneren Knoten mit einer Stufe verknüpft ist und ferner eine Verweisverknüpfung zu wenigstens einem der Mehrzahl der verknüpften Knoten, die auch mit der Stufe verknüpft sind, umfaßt.
  27. System nach einem der Ansprüche 23 bis 26, wobei die Zeichenfolge eine Folge von alphanumerischen Zeichen ist und wenigstens eine der Mehrzahl der Eingabefolgen ein Wildcard-Zeichen enthält.
  28. System nach einem der Ansprüche 23 bis 27, umfassend eine Kollisionserkennung oder ein Kollisionsmanagement durch Verwendung einer dynamischen Sperrtabelle (1202) gemäß Anspruch 17.
DE69912410T 1998-02-26 1999-02-25 Schnelles zeichenkettensuchen und -indizieren Expired - Lifetime DE69912410T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US31285 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

Publications (2)

Publication Number Publication Date
DE69912410D1 DE69912410D1 (de) 2003-12-04
DE69912410T2 true DE69912410T2 (de) 2004-08-19

Family

ID=21858597

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69912410T Expired - Lifetime DE69912410T2 (de) 1998-02-26 1999-02-25 Schnelles zeichenkettensuchen und -indizieren

Country Status (9)

Country Link
US (1) US6047283A (de)
EP (1) EP1066570B1 (de)
JP (2) JP3735683B2 (de)
AT (1) ATE253242T1 (de)
AU (1) AU762980B2 (de)
CA (1) CA2316936C (de)
DE (1) DE69912410T2 (de)
IL (1) IL137693A (de)
WO (1) WO1999044151A1 (de)

Families Citing this family (147)

* Cited by examiner, † Cited by third party
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
US6321276B1 (en) 1998-08-04 2001-11-20 Microsoft Corporation Recoverable methods and systems for processing input/output requests including virtual memory addresses
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
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
US6751616B1 (en) 2000-01-28 2004-06-15 Oracle International Corp. Techniques for DLM optimization with re-mapping responsibility for lock management
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
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
GB2406678B (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
US6981138B2 (en) * 2001-03-26 2005-12-27 Microsoft Corporation Encrypted key cache
US7062490B2 (en) * 2001-03-26 2006-06-13 Microsoft Corporation Serverless distributed file system
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
GB2384901B (en) 2002-02-04 2004-04-21 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
US7886359B2 (en) * 2002-09-18 2011-02-08 Symantec Corporation Method and apparatus to report policy violations in messages
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
US7673344B1 (en) 2002-09-18 2010-03-02 Symantec Corporation Mechanism to search information content for preselected data
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
US8661498B2 (en) * 2002-09-18 2014-02-25 Symantec Corporation Secure and scalable detection of preselected data embedded in electronically transmitted messages
EP1548998A4 (de) * 2002-10-03 2008-02-27 In4S Inc Bitkettenpr fverfahren und einrichtung
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
US20050065965A1 (en) * 2003-09-19 2005-03-24 Ziemann David M. Navigation of tree data structures
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 (de) * 2004-02-19 2005-08-24 Sap Ag Optimierung der Sperrgranularität mittels Bereichssperren
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 (de) * 2005-01-25 2006-07-26 Sap Ag Ein zentraler Sperrdienst für Datenbankanwendungen
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
WO2006093879A2 (en) 2005-02-26 2006-09-08 Coco Communications Corporation 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
CA3074633C (en) * 2005-07-15 2022-11-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
US8275799B2 (en) * 2005-08-02 2012-09-25 The Boeing Company Methods and apparatus for information modeling
US10140387B2 (en) 2005-08-02 2018-11-27 The Boeing Company Model for managing variations in a product structure for a product
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
US7647329B1 (en) * 2005-12-29 2010-01-12 Amazon Technologies, Inc. Keymap service architecture for a distributed storage 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 (de) * 2007-03-20 2008-09-24 Sap Ag Beurteilung von Arbeitsflussgenehmigungen bei mehrschichtigen Anwendungen
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
US8180803B2 (en) * 2007-11-27 2012-05-15 Cavium, Inc. Deterministic finite automata (DFA) graph compression
US7949683B2 (en) * 2007-11-27 2011-05-24 Cavium Networks, Inc. Method and apparatus for traversing a compressed deterministic finite automata (DFA) graph
JP2011511366A (ja) * 2008-02-01 2011-04-07 ジ・オリバー・グループ・リミテッド・ライアビリティ・カンパニー データの検索および索引付けの方法およびそれを実施するシステム
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
US7996374B1 (en) 2008-03-28 2011-08-09 Symantec Corporation Method and apparatus for automatically correlating related incidents of policy violations
US8065739B1 (en) 2008-03-28 2011-11-22 Symantec Corporation Detecting policy violations in information content containing data in a character-based language
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
US8819208B2 (en) 2010-03-05 2014-08-26 Solidfire, Inc. Data deletion in a distributed data storage system
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 华为数字技术（成都）有限公司 数据重复性校验方法和装置及系统
WO2012081165A1 (ja) * 2010-12-16 2012-06-21 日本電気株式会社 データベース管理装置及びデータベース管理方法
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 任天堂株式会社 データ構造、データ構造生成方法、情報処理装置、情報処理システム、及び情報処理プログラム
US9295009B2 (en) * 2012-05-23 2016-03-22 Telefonaktiebolaget L M Ericsson (Publ) Transcendental function look-up tables for thermal noise power 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 富士ゼロックス株式会社 情報処理装置、及びプログラム
US10915233B2 (en) 2014-09-26 2021-02-09 Oracle International Corporation Automated entity correlation and classification across heterogeneous datasets
US10210246B2 (en) 2014-09-26 2019-02-19 Oracle International Corporation Techniques for similarity analysis and data enrichment using knowledge sources
US10891272B2 (en) 2014-09-26 2021-01-12 Oracle International Corporation Declarative language and visualization system for recommended data transformations and repairs
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
US20180367673A1 (en) * 2016-12-27 2018-12-20 Bronson Picket 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

Family Cites Families (7)

* Cited by examiner, † Cited by third party
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
WO1996000945A1 (en) * 1994-06-30 1996-01-11 International Business Machines Corp. Variable length data sequence matching method and apparatus
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

Also Published As

Publication number Publication date
JP2002505481A (ja) 2002-02-19
AU2835799A (en) 1999-09-15
CA2316936A1 (en) 1999-09-02
EP1066570B1 (de) 2003-10-29
JP3947202B2 (ja) 2007-07-18
ATE253242T1 (de) 2003-11-15
US6047283A (en) 2000-04-04
AU762980B2 (en) 2003-07-10
IL137693A0 (en) 2001-10-31
DE69912410D1 (de) 2003-12-04
CA2316936C (en) 2004-04-20
JP3735683B2 (ja) 2006-01-18
IL137693A (en) 2005-08-31
JP2006004439A (ja) 2006-01-05
EP1066570A1 (de) 2001-01-10
WO1999044151A1 (en) 1999-09-02

Similar Documents

Publication Publication Date Title
DE69912410T2 (de) Schnelles zeichenkettensuchen und -indizieren
DE69636761T2 (de) Speichern und wiederauffinden von geordneten schlüsselmengen in einem kompakten 0-kompletten baum
DE69530595T2 (de) System und verfahren für die x.500-datenbanknorm
DE69926305T2 (de) Rechnerlesbarer Speicher zum Speichern einer Datenbank und Indizes
EP0910829B1 (de) Datenbanksystem
DE60026229T2 (de) Verfahren und Vorrichtung für Klassifizierung von Datenpaketen
DE102016105526A1 (de) Schnelles mehrschichtiges Indexieren mit Unterstützung für dynamische Aktualisierung
DE60035432T2 (de) System zur verwaltung der rdbm fragmentierungen
WO1999017226A1 (de) Verfahren zum hinzufügen bzw. entfernen einer adresse in einem teilbesetzten, nicht-balancierten binären baum
DE60032674T2 (de) Verfahren zum Suchen von Adressen
EP3563261B1 (de) Bitsequenzbasiertes datenklassifikationssystem
EP1276056B1 (de) Verfahren zum Verwalten einer Datenbank
DE69629540T2 (de) Verfahren und Gerät zum Sortieren von Elementen
DE3736455A1 (de) Hierarchisches ablagesystem
DE2458331A1 (de) Datenverarbeitungssystem zur adressierung eines in einem sekundaerspeicher abgelegten datensatzes
DE10057634C2 (de) Verfahren zur Verarbeitung von Text in einer Rechnereinheit und Rechnereinheit
DE60307688T2 (de) Hardware-unterstützter Tupelraum
EP1372303B1 (de) Verfahren zum selektiven Auffinden und Abrufen von in einem Mobilkommunikationsnetz verfügbaren Informationen mittels eines mobilen Endgeräts
Kaporis et al. ISB-tree: A new indexing scheme with efficient expected behaviour
Orlandic et al. Analysis of compact 0-complete trees: A new access method to large databases
Comer English dictionary searching with little extra space
EP4198760A1 (de) Verfahren zur verarbeitung von signaldaten
DE102016110479B4 (de) Verfahren und Computerprogramm zum Überprüfen der Dateisystemintegrität sowie Datenverarbeitungseinrichtung hierzu
DE112021000573T5 (de) Hierarchische daten
DE1774886A1 (de) Verfahren zum Verarbeiten und Suchen von Eigenschaftssaetzen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition