DE10056765A1 - Generieren von Statistiken für Datenbankabfragen mit Hilfe von Tensordarstellungen - Google Patents

Abstract

Abfrageergebnisse und Statistiken darüber werden mit Hilfe einer neuartigen Darstellung einer Relation mit n Attributen als relationaler Tensor mit n Ordnungen generiert. Die Ordnung der relationalen Tensoren entspricht den Attributen, und jede Koordinate in einer Ordnung bezieht sich auf einen Schlüsselwert des entsprechenden Attributs. Im relationalen Tensor werden numerische Werte gespeichert, wobei jeder numerische Wert eine Anzahl von Tupeln angibt, die die Attributschlüsselwerte besitzen, die der Koordinate des numerischen Wertes im Verlauf der Ordnungen des relationalen Tensors entsprechen. Diese Speicherungsdarstellung ist in verschiedenen Kontexten nützlich, um die Leistungsfähigkeit eines RDBMS-Systems zu steigern. Speziell kann in einem ersten Aspekt der Erfindung eine Tensordarstellung verwendet werden, um Statistiken für eine Benutzeranfrage zu generieren, so dass das relationale Datenbanksystem anhand der Statistik aus zwei möglichen Ansätzen einen auswählen kann, der bei der Verarbeitung der Benutzeranfrage verwendet werden soll. Außerdem kann ein Daten darstellender relationaler Tensor verwendet werden, um Ergebnisse für eine Einschränkungsoperation wie die SQL-Operationen DISTINCT, PROJECTION, EQUALS, LESS THAN, LESS THAN OR EQUAL, GREATER THAN, GREATER THAN OR EQUAL und LIKE zu erzeugen.

Description

Die vorliegende Anmeldung ist sachverwandt mit der US- Patentanmeldung Nr. 09/441,818 mit dem Titel GENERATING RESTRICTION QUERIES USING TENSOR REPRESENTATIONS, die gleichzeitig mit der vorliegenden Anmeldung (R0997-097) von Lance Amundsen et al. eingereicht wird und in ihrer Gesamtheit durch Bezugnahme in die vorliegende Anmeldung einverleibt wird.

Gegenstand der Erfindung

Die vorliegende Erfindung betrifft die Generierung von Statistiken bei der Verwaltung und Ausführung von Abfragen in relationalen Datenbanken.

Hintergrund der Erfindung

Software für relationale Datenbankverwaltungssysteme (relational database management systems - RDBMS), die mit einer SQL-Schnittstelle arbeiten (SQL = Structured Query Language - Strukturierte Abfragesprache), ist in Fachkreisen bekannt. Die SQL-Schnittstelle hat sich zu einer Standardsprache für RDBMS-Software entwickelt und wurde als solche sowohl von der American National Standards Organization (ANSI) als auch von der International Standards Organization (ISO) angenommen.

In der RDBMS-Software sind alle Daten extern in Relationen strukturiert, wobei jede Relation sich mit einem oder mehreren Attributen befasst und ein oder mehrere Datentupel umfasst, die Attributewerte miteinander assoziieren. Eine Relation kann als Tabelle mit Zeilen und Spalten dargestellt werden (und tatsächlich werden die Relationen in einer bestimmten Datenbank oft als "Tabellen" der Datenbank bezeichnet). Wenn eine Relation als Tabelle dargestellt wird, stehen in den Spalten der Tabelle die Attribute der Relation und in den Zeilen die einzelnen Tupel oder Datensätze, die unter Verwendung dieser Attribute gespeichert werden. Um die Visualisierung von Relationen auf diese Weise zu erleichtern, werden die Relationen in einem RDBMS-System im Folgenden of als "Tabellen" des betreffenden Systems bezeichnet.

Ein RDBMS-System kann zum Speichern und Bearbeiten sehr verschiedener Daten verwendet werden. Betrachten wir beispielsweise ein einfaches RDBMS-System zur Speicherung und Bearbeitung von Namens- und Adressdaten. In einem solchen System könnte eine "Name/Adresse"-Tabelle, in der Namens- und Adressattribute gespeichert sind, eine erste Spalte "Nachname" für den Nachnamen, eine zweite Spalte "Vorname" für den ersten Vornamen, eine dritte Spalte "M. I." für den Anfangsbuchstaben eines zweiten Vornamens und weitere Spalten für Adressen enthalten. Jede Zeile in der Tabelle würde den Namen und die Adressdaten für eine bestimmte Person enthalten.

Oft stehen Spalten in verschiedenen Tabellen miteinander in Beziehung. In dem obigen Beispiel könnte also die "Name/Adresse"-Tabelle eine Spalte für die Straße, eine Spalte für die Postleitzahl oder einen anderen postalischen Code (d. h. eine eindeutige Indexnummer oder Zeichenfolge, die eine allgemeine Ortsangabe einer Straßenadresse identifiziert), besitzen. In diesem Beispiel bezeichnet jede Zeile der "Name/Adresse"-Tabelle einen postalischen Code für die durch diese Zeile bezeichnete Person, aber keine Stadt. In einer zweiten Tabelle mit dem Titel "Stadt" können Städtenamen gespeichert sein, und zwar in zwei Spalten: einer ersten für den Namen der Stadt und einer zweiten für die Postleitzahl der Stadt. Zu jeder Postleitzahl kann es mehrere Personen geben, und es ist deshalb wahrscheinlich, dass die Tabelle "Name/Adresse" mehrere Einträge enthält, die die gleiche Postleitzahl bezeichnen. Ferner ist es wahrscheinlich, dass es in einer Stadt mehrere Postleitzahlen gibt, sodass die Tabelle "Stadt" wahrscheinlich mehrere Zeilen für die gleiche Stadt enthält.

Es sei darauf hingewiesen, dass die Reihenfolge der Tupel in einer Relation nicht als Merkmal der Relation betrachtet wird; das bedeutet, zwei Relationen mit dem gleichen Tupeln, aber in anderer Reihenfolge, sind für das RDBMS-System absolut äquivalent. Die Reihenfolge der Tupel wird gegebenenfalls durch Benutzerbefehle bestimmt, die eine Sortierungsweise für die Tupel festlegen. Wenn keine spezielle Sortierung angegeben ist, ist die Reihenfolge der Tupel in einer Relation nicht definiert, und Tupel aus der Relation können in beliebiger Reihenfolge ausgegeben werden.

Eine globale Datenbankorganisation wird typischerweise als Schema für die Datenbank bezeichnet. Ein Datenbankschema wird oft kompakt mit Hilfe von Tabellennamen und Namen der Tabellenspalten ausgedrückt. Das im obigen Beispiel beschriebene einfache Schema mit den Tabellen "Name/Adresse" und "Stadt" könnte folgendermaßen ausgedrückt werden:
Name/Adresse(Nachname, Vorname, M. I., Postleitzahl, . . .) Stadt(Stadt, Postleitzahl)

Ein Datenbankschema hat oft die Form eines "Sterns", in dem es eine sehr große "Muttertabelle" und viele kleine "Detailtabellen" gibt. Abfragen beinhalten typischerweise Auswahlen anhand der Attribute der Detailtabellen, z. B. der Tabelle "Stadt", in der die Städtenamen gespeichert sind, gefolgt von der Abfrage von Informationen für die ausgewählten Tupel aus der Muttertabelle, z. B. der "Name/Adresse"-Tabelle, in der Namen und Adressen von Personen gespeichert sind. Aus der obigen Beschreibung ist zu ersehen, dass zum Auffinden der Personen in einer bestimmten Stadt die Zeilen in der Tabelle "Stadt" durchsucht werden, um die Zeilen mit dem gewünschten Städtenamen zu finden, und dann die Postleitzahlen in diesen Zeilen abgerufen werden. Dann würden in der Tabelle "Name/Adresse" alle Zeilen gesucht, bei denen in der Postleitzahlenspalte die entsprechende Postleitzahl steht. Die Namen und Adressen für die ausgewählten Zeilen bezeichnen Personen, die in der gewünschten Stadt wohnen.

Bei einer typischen Art und Weise, Informationen aus einer Tabelle abzurufen, werden Indizes verwendet. Es kann zum Beispiel einen Index der Tabelle "Name/Adresse" geben, in dem alle Zeilen identifiziert werden, die einen bestimmten Wert für die Postleitzahl enthalten. Dieser Index wird separat von der Tabelle gespeichert und muss bei jeder Aktualisierung der Tabelle mit aktualisiert werden. Indizes führen deshalb zu wesentlich höheren Speicheranforderungen. Wenn kein Index vorhanden ist, kann eine Tabellenabfrage aber nur bewerkstelligt werden, indem jede Zeile der Tabelle durchsucht wird, und dafür ist eine wesentlich längere Verarbeitungszeit erforderlich. In einer Umgebung wie der Unterstützung der Entscheidungsfindung, wo Auswahlen aus einer willkürlichen Anzahl von Detailtabellen getroffen werden können, sind für eine maximale Geschwindigkeit Indizes der meisten oder aller Spalten einiger Tabellen erforderlich, sodass solche Anwendungen einen hohen Platzbedarf haben. In anderen Umgebungen werden typischerweise Kompromisse zwischen der Geschwindigkeit und der Verringerung des Speicherbedarfs eingegangen, indem zumindest für einige Spalten einer Tabelle kein Spaltenindex erzeugt wird.

Eine Art von Index ist ein Bitmap-Index, der angibt, ob ein bestimmter Wert für jede Zeile in einer bestimmten Zeile existiert. Für jede Zeile wird ein Bit verwendet. Im Bitmap- Index für den Wert "45246" in der Spalte "Postleitzahl" hat das n-te Bit den Wert 1, wenn die n-te Zeile der Tabelle "Name/Adresse" die Postleitzahl "45246" enthält, und den Wert 0, wenn diese Zeile einen anderen Wert enthält. Typischerweise gibt es für jede Spalte mehrere Bitmap- Indizes, einen für jeden von mehreren möglichen Werten, die in der Spalte stehen können (z. B. einen Index für den Wert "45246", einen zweiten Index für den Wert "45202" usw.). Eine andere Art von Index ist ein codierter Vektorindex (encoded vector index - EVI), der in der US-Patentschrift Nr. 5,706,495, ausgegeben am 6. Januar 1998 an Chadha et al., mit dem Titel ENCODED-VECTOR INDICES FOR DECISION SUPPORT AND WAREHOUSING, beschrieben ist. Diese Patentschrift wird durch Bezugnahme in die vorliegende Anmeldung einverleibt. Ein EVI dient einem ähnlichen Zweck wie ein Bitmap-Index, aber es ist nur ein einziger Index notwendig, der alle Werte in den Spalten (ob dieser nur "45246", "45206" oder anders lautet) berücksichtigt. In einem EVI der Spalte "Postleitzahl" enthält die n-te Position des EVI einen Bitcode, der mit Hilfe einer Zuordnungstabelle so decodiert werden kann, dass sich der Wert "45246" ergibt, der die Postleitzahl in der n-ten Zeile der Tabelle bezeichnet. Während also bei Verwendung eines Bitmap-Index für jeden einzelnen Schlüsselwert in einem Datenbankfeld einen eigenen Index geben muss, reicht ein einziger EVI aus, um die gleiche Information darzustellen. Ein EVI spart somit Computerspeicher, indem alle möglichen Schlüsselwerte für ein bestimmtes Feld in einem einzigen Datenbankindex gespeichert werden. Es ist aber zu beachten, dass sowohl ein Bitmap-Index als auch ein EVI-Index nur Informationen indiziert, die sich auf eine einzige Spalte der Tabelle beziehen. Diese Indizes geben nicht die Relationen zwischen Werten in verschiedenen Spalten wieder.

In SQL ist die wichtigste RDBMS-Operation, die in den obigen Beispielen beschrieben wurde, die Verknüpfung (JOIN), in diesem Fall zwischen der Tabelle "Stadt" und der Tabelle "Name/Adresse". Dies ist nur ein Beispiel für die zahlreichen Operatoren, die von einer SQL-Schnittstelle zur RDBMS-Software bereitgestellt werden. Die SQL-Schnittstelle ermöglicht es dem Benutzer, relationale Operationen mit Tabellen interaktiv, in Stapeldateien oder eingebettet in Hostsprachen wie C, COBOL usw. zu formulieren. In SQL gibt es Operatoren, mit denen der Benutzer die Daten bearbeiten kann; jeder Operator bearbeitet entweder eine oder zwei Tabellen und erzeugt als Ergebnis eine neue Tabelle. Die besondere Fähigkeit von SQL besteht darin, Informationen aus verschiedenen Tabellen oder Sichtweisen miteinander zu verknüpfen, um komplexe Verfahren wie das einfache Verfahren im obigen Beispiel in einer einzigen Anweisung auszuführen.

Die Operatoren in SQL sind von einem ursprünglichen Satz abgeleitet, der aus acht Operatoren besteht:
RESTRICT Extrahiert angegebene Tupel aus einer angegebenen Relation (d. h. ruft Zeilen aus einer Tabelle ab) unter Verwendung einer angegebenen Bedingung;
PROJECT Extrahiert angegebene Attribute einer angegebenen Relation (d. h. ruft angegebene Spalten aus einer Tabelle ab);
PRODUCT Erzeugt eine Verknüpfung zwischen zwei angegebenen Relationen, die alle möglichen Tupelkombinationen aus den beiden Relationen enthält (d. h. erzeugt eine Tabelle mit Zeilen, die durch Kombination aller Zeilen beider Tabellen erstellt wird);
UNION Erzeugt eine Relation, die aus allen Tupeln besteht, die in einer oder beiden von zwei Relationen erscheinen (d. h. erstellt eine Tabelle, die alle Zeilen enthält, die in mindestens einer der Tabellen erscheinen);
INTERSECT Erzeugt eine Relation, die aus allen Tupeln besteht, die in beiden von zwei angegebenen Relationen erscheinen (d. h. erstellt eine Tabelle, die alle Zeilen enthält, die in beiden Tabellen erscheinen);
DIFFERENCE Erzeugt eine Relation (Tabelle), die als allen Tupeln (Zeilen) besteht, die in der ersten, aber nicht in der zweiten der angegebenen Relationen (Tabellen) erscheinen;
JOIN Erzeugt eine Relation (Tabelle) aus zwei angegebenen Relationen (Tabellen), die aus allen möglichen Kombinationen - eine von jeder der beiden Relationen (Tabellen) - von Tupeln (Zeilen) besteht, so dass die zwei Tupel (Zeilen), die zu einer bestimmten Kombination beitragen, eine bestimmte Bedingung erfüllen;
DIVIDE Erzeugt eine Relation (Tabelle) aus einer ersten Relation (Tabelle) mit einem ersten und einem zweiten Attribut (Spalten) und einer zweiten Relation (Tabelle) mit einem Attribut (Spalte), indem aus der ersten Tabelle Werte des ersten Attributs (Spalte) von Tupeln (Zeilen), deren zweites Attribut (Spalte) einem Wert in der zweiten Tabelle entspricht, ausgewählt werden.

Im Hinblick auf diese grundlegenden Operationen und die daraus abgeleiteten detaillierteren Operationen, die den Gesamtumfang von SQL bilden, ist zu erwähnen, dass das Ergebnis jeder Operation eine Relation ist, die in ihrer Struktur äquivalent mit den von der Operation benutzten Relationen ist. Dies ist ein wichtiges Merkmal, da es ermöglicht, dass SQL-Operationen als verschachtelte relationale Ausdrücke geschrieben werden, wobei die Ausgabe einer Operation als Eingabe der nächsten Operation dient. Die Mächtigkeit von SQL ist zu einem großen Teil auf die Fähigkeit zurückzuführen, SQL-Operationen in der gewünschten Reihenfolge zu verbinden, um eine gewünschte Funktion auszuführen.

Als Beispiel für diese Fähigkeit kann das obige Beispiel so erweitert werden, dass eine Tabellenverknüpfung mit drei Wegen illustriert wird. Angenommen, es gibt eine Einwohnerzahltabelle, in der Einwohner von Städten identifiziert werden, und diese Einwohnerzahltabelle besitzt eine erste Spalte für den Stadtnamen und eine zweite Spalte für die Einwohner der Stadt. Mit Hilfe der Tabellen "Name/Adresse", "Stadt" und "Einwohnerzahl" ist es möglich, diejenigen Personen zu identifizieren, die in Städten mit einer Einwohnerzahl über einem bestimmten Schwellenwert wohnen. Dazu werden die Tabellen "Einwohnerzahl" und "Stadt" durch JOIN mit einem Schwellenwertkriterium für die Einwohnerzahl verknüpft, und das Ergebnis wird durch JOIN mit der Tabelle "Name/Adresse" verknüpft.

An dieser Stelle ist zu erwähnen, dass ein RDBMS-System, in dem eine SQL-Abfrage implementiert ist, das Ergebnis der einzelnen SQL-Operationen nicht in seiner Gesamtheit materialisieren muss. Wenn beispielsweise im obigen Beispiel jede in der Datenbank gespeicherte Adresse gesucht wird, die sich in einer bestimmten Stadt befindet, bedeutet dies formal die Ausführung einer RESTRICT-Operation (Beschränkung auf die gewünschte Stadt) auf die Ergebnisse einer JOIN- Operation mit den Tabellen "Name/Adresse" und "Stadt". Es wäre ineffizient, die Ergebnisse der JOIN-Operation, d. h. eine um die Städtenamen erweiterte Tabelle aller Adressen in der Tabelle "Name/Adresse", zu berechnen und dann nur die Adressen in der gewünschten Stadt auszuwählen. Effizienter wäre es, wie im obigen Beispiel beschrieben, die Einschränkung bei der Generierung jedes Tupels der JOIN- Operation anzuwenden und diejenigen Tupel, die die Bedingung nicht erfüllen, zu verwerfen. Auf diese Weise entsteht ein äquivalentes Ergebnis, ohne dass das Ergebnis der JOIN- Operation materialisiert wird.

Um Optimierungen dieser Art zu erreichen, enthält ein RDBMS- System oft eine wesentliche Logik zur Vermeidung der Matierialisierung von Zwischenergebnissen. Für solche Optimierungen verwendet ein RDBMS-System Statistiken, die die Daten beschreiben, mit denen die SQL-Operationen arbeiten. Zwei solche Statistiken zu den beschriebenen Beispielen sind eine Schlüsselbereichabschätzung und eine JOIN-Fanout-Abschätzung. Durch eine Schlüsselbereichsabschätzung wird abgeschätzt, wieviele Zeilen in einer bestimmten Tabelle eine bestimmte Bedingung erfüllen. Durch eine JOIN-Fanout-Abschätzung wird abgeschätzt, wieviele Datensätze wahrscheinlich von einer JOIN-Operation erzeugt werden. In dem zuletzt beschriebenen Beispiel würde eine solche Statistik angeben, ob es in der Datenbank eine große Zahl von Postleitzahlen für Städte, die das Einwohnerzahlkriterium erfüllen, gibt, und ob die "Name/Adresse"-Datensätze in einigen wenigen Städten konzentriert oder auf eine große Anzahl von Städten verteilt sind. Diese Statistiken wären dann nützlich bei der Entscheidung, ob es effizienter wäre, (a.) die Tabelle "Name/Adresse" durch JOIN mit der Tabelle "Stadt" zu verknüpfen, bevor eine JOIN-Operation mit der Tabelle "Einwohnerzahl" ausgeführt wird, oder (b.) vor der JOIN- Operation mit der Tabelle "Name/Adresse" zuerst die Tabellen "Stadt" und "Einwohnerzahl" mit JOIN zu verknüpfen, indem ein Zwischenergebnis mit den Postleitzahlen in den Städten, die das Einwohnerzahlkriterium erfüllen, erzeugt wird und dann die Personen in der Tabelle "Name/Adresse" ausgewählt werden, deren Postleitzahl im Zwischenergebnis erscheint. Typischerweise ist der Ansatz am effizientesten, der das kleinste Zwischenergebnis erzeugt.

Statistiken dieser Form werden oft mit Hilfe der vorhandenen Indizes für die Tabellen, mit denen SQL-Operationen ausgeführt werden, generiert. Eine Schlüsselbereichsabschätzung kann beispielsweise aus einem Bitmap-Index durchgeführt werden, indem die Anzahl der "1"- Bits im Index unter den identifizierten Schlüsselwerten gezählt werden. Da aber in modernen RDBMS-Systemen viele Spalten keinen Index besitzen, sind Schlüsselbereichs- und JOIN-Fanout-Statistiken leider oft nicht verfügbar oder fehlerhaft. Dies führt zu erheblichen Effizienzverlusten, da Abfragen aufgrund der fehlenden oder fehlerhaften Statistiken nicht auf die optimale Weise ausgeführt werden. Wie den obigen Ausführungen zu entnehmen ist, leiden moderne RDBMS-Systeme unter einer Reihe von Nachteilen, die eine optimale Leistungsfähigkeit verhindern; die wichtigsten sind der Speicherplatzbedarf für die Generierung von Indizes und wegen der resultierenden unvollständigen Indexierung das Fehlen exakter Statistiken, die bei der Optimierung von RDBMS-Operationen nützlich sein können. Was fehlt ist eine alternative Darstellung von Daten in einem RDBMS-System, die die Generierung von SQL-Ergebnissen und Statistiken zu diesen Ergebnissen erleichtert, ohne zu viel Speicherplatz zu beanspruchen.

Kurzbeschreibung der Erfindung

Nach den Prinzipien der vorliegenden Erfindung werden diese Anforderungen durch eine neuartige Darstellung einer n- Attribut-Relation als relationaler Tensor mit n Ordnungen erfüllt, wodurch die Generierung von Abfrageergebnissen erleichtert wird.

Speziell speichert ein relationales Datenbanksystem nach den Prinzipien der vorliegenden Erfindung eine Anzahl von Tupeln, die über mehrere Attribute gebildet wird, in einem relationalen Tensor höherer Ordnung. Die Ordnung der relationalen Tensoren entspricht den Attributen, und jede Koordinate in einer Ordnung bezieht sich auf einen Schlüsselwert des entsprechenden Attributs. Im relationalen Tensor werden numerische Werte gespeichert, wobei jeder numerische Wert eine Anzahl von Tupeln angibt, die die Attributschlüsselwerte besitzen, die der Koordinate des numerischen Wertes im Verlauf der Ordnungen des relationalen Tensors entsprechen. Diese Speicherungsdarstellung ist in verschiedenen Kontexten nützlich, um die Leistungsfähigkeit eines RDBMS-Systems zu steigern.

Speziell in einem ersten Aspekt der Erfindung wird ein relationaler Tensor, der Daten repräsentiert, verarbeitet, um eine Statistik für eine Benutzeranfrage zu generieren, die eine relationale Operation an mindestens einem Attribut angibt, über das der Daten darstellende, relationale Tensor gebildet wurde. In dieser Ausführungsform entscheidet sich ein relationales Datenbanksystem anhand der Statistik für einen von zwei möglichen Ansätzen, der zur Verarbeitung der Benutzeranfrage verwendet werden soll.

In einem zweiten Aspekt der vorliegenden Erfindung wird ein Daten darstellender relationaler Tensor verwendet, um Ergebnisse für eine Einschränkungsoperation wie die SQL- Operationen DISTINCT, PROJECTION, EQUALS, LESS THAN, LESS THAN OR EQUAL, GREATER THAN, GREATER THAN OR EQUAL und LIKE zu erzeugen. Gemäß diesem Aspekt verarbeitet ein relationales Datenbanksystem einen Daten darstellenden relationalen Tensor, um einen resultierenden relationalen Tensor zu erzeugen, der die Ergebnisse der Einschränkungsoperation identifiziert.

Diese und andere Merkmale und Vorteile, die die Erfindung kennzeichnen, sind in den angefügten Ansprüchen, die ein weiterer Bestandteil dieser Anmeldung sind, definiert. Um die Erfindung und die durch ihre Verwendung erreichten Vorteile und Aufgaben besser zu verstehen, sei hier auf die Zeichnung und die Verwendung der Beschreibung verwiesen, wo exemplarische Ausführungsformen der Erfindung erläutert werden.

Kurzbeschreibung der Zeichnung

Fig. 1 ist ein Blockdiagramm einer Vorrichtung gemäß einer Ausführungsform der vorliegenden Erfindung;

Fig. 2A zeigt eine Relation mit zwei Attributen in Form einer Tabelle, Fig. 2B zeigt die Tupel aus Fig. 2A in Form eines relationalen Tensors, Fig. 2C zeigt eine Relation mit drei Attributen in Form einer Tabelle, und Fig. 2D zeigt die ersten zwei Tupel aus Fig. 2C in Form eines relationalen Tensors, wobei weitere Koordinaten in der vertikalen Domäne, die zur Darstellung anderer Tupel benötigt werden, der Kürze wegen weggelassen wurden.

Fig. 3 ist ein Flussdiagramm eines Prozesses zur Erzeugung eines relationalen Tensorprodukts aus zwei relationalen Tensoren nach den Prinzipien der vorliegenden Erfindung;

Fig. 3A zeigt einen Daten darstellenden relationalen Tensor, der mit dem in Fig. 2B dargestellten identisch ist; Fig. 3B zeigt einen relationalen Auswahltensor, der in einem relationalen Tensorprodukt mit dem relationalen Tensor aus Fig. 3A benutzt wird; und Fig. 3C zeigt das Ergebnis des relationalen Tensorprodukts der relationalen Tensoren aus Fig. 3A und Fig. 3B;

Fig. 3D zeigt einen zweiten relationalen Auswahltensor, der in einem relationalen Tensorprodukt mit dem relationalen Tensor aus Fig. 3A benutzt wird, und Fig. 3E zeigt das Ergebnis des relationalen Tensors aus Fig. 3D und Fig. 3E;

Fig. 4 ist ein Flussdiagramm eines Prozesses zur Ausführung einer Einschränkungsoperation, die auf einen Daten darstellenden relationalen Tensor anwendbar ist, indem ein geeigneter relationaler Auswahltensor erzeugt und ein relationales Tensorprodukt verwendet wird, um Statistiken für die Einschränkungsoperation oder Ergebnisse der Einschränkungsoperation zu generieren;

Fig. 4A zeigt die Kombination zweier relationaler Tensoren, die auf verschiedene Ordnungen eines Daten darstellenden relationalen Tensors anwendbar sind, und Fig. 4B zeigt den resultierenden relationalen Auswahltensor;

Fig. 5 ist ein Flussdiagramm eines Prozesses zum Expandieren der Domäne(n) eines ersten Tensors, so dass dieser den Domänen eines zweiten Tensors entspricht, wie er in dem Prozess aus Fig. 4 verwendet wird;

Figur Fig. 5A zeigt einen relationalen Auswahltensor, und Fig. 5B zeigt den relationalen Auswahltensor aus Fig. 5A, nachdem dieser einer Ordnungsexpansion unterzogen wurde, so dass er dem Daten darstellenden Tensor aus Fig. 3A entspricht; und Fig. 5C zeigt einen relationalen Auswahltensor, der aus einem relationalen Tensorprodukt aus den in Fig. 4B und Fig. 5B dargestellten relationalen Auswahltensoren erzeugt wurde;

Fig. 6 ist ein Flussdiagramm eines Prozesses zur Kontraktion eines relationalen Tensors in einer angegebenen Ordnung wie in dem in Fig. 4 dargestellten Prozess für Einschränkungsoperationen des Typs PROJECTION;

Fig. 6A zeigt einen resultierenden relationalen Tensor mit zwei Ordnungen, der mit dem in Fig. 3C gezeigten identisch ist; Fig. 6B zeigt einen relationalen Tensor mit einer Ordnung, der aus dem relationalen Tensor aus Fig. 6A gemäß dem Ordnungskontraktionsprozess aus fig. 6 gebildet wurde; und Fig. 6C zeigt einen Skalar, der aus dem relationalen Tensor aus Fig. 6B gemäß dem Ordnungskontraktionsprozess aus Fig. 6 gebildet wurde;

Fig. 7 ist ein Flussdiagramm eines Prozesses zur Normalisierung eines relationalen Tensors wie in dem in Fig. 4 dargestellten Prozess für Einschränkungsoperationen des Typs DISTINCT;

Fig. 8A ist ein Flussdiagramm eines Prozesses zum Löschen von Datensätzen aus einer Relation anhand eines Einschränkungskriteriums unter Verwendung der durch den Prozess aus Fig. 4 erzeugten Statistik; Fig. 8B ist ein Flussdiagramm eines Prozesses zum Einfügen von Datensätzen einer Relation, die ein Einschränkungskriterium erfüllt, in eine zweite Relation unter Verwendung der in dem Prozess aus Fig. 4 erzeugten Statistik; und Fig. 8C ist ein Flussdiagramm eines Prozesses zum Aktualisieren von Datensätzen in einer Relation, die ein Einschränkungskriterium erfüllen; und

Fig. 9 ist ein Flussdiagramm eines Prozesses zur Berechnung einer Statistik des Fanout einer JOIN-Operation, die mit einem bestimmten JOIN-Attribut auf die erste und zweite Relation angewendet wird.

Ausführliche Beschreibung

Die Verfahren der vorliegenden Erfindung verwenden auf dem Computer implementierte Routinen zur Abfrage von Informationen aus einer Datenbank. In Fig. 1 ist ein Blockdiagramm eines Computersystems dargestellt, in dem eine Ausführungsform der vorliegenden Erfindung implementiert werden kann. Das in Fig. 1 dargestellte Computersystem ist ein IBM AS/400; dem Fachmann ist aber klar, dass das erfindungsgemäße Verfahren und die erfindungsgemäße Vorrichtung gleichermaßen auf andere Computersysteme anwendbar ist, unabhängig davon, ob das Computersystem ein kompliziertes Mehrbenutzersystem ist oder ein Einzelplatzsystem wie ein PC oder eine Workstation. Das Computersystem 100 kann also andere Arten von Computern umfassen, so z. B. IBM PCs mit OS/2 oder Microsoft Windows. Das Computersystem 100 umfasst geeigneterweise einen Prozessor 110, einen Hauptspeicher 120, einen Speicher- Controller 130, eine Zusatzspeicherschnittstelle 140 und eine Terminalschnittstelle 150, die alle über einen Systembus 160 miteinander verbunden sind. Das in Fig. 1 dargestellte Computersystem 100 kann innerhalb des Schutzbereichs der Erfindung auf verschiedene Weise abgewandelt, ergänzt oder reduziert werden, z. B. durch Hinzufügen eines Cache-Speichers oder weiterer Peripheriegeräte. Fig. 1 soll nur einige der wichtigsten Merkmale des Computersystems 100 aufzeigen.

Der Prozessor 110 führt Rechen- und Steuerfunktionen des Computersystems 100 aus und umfass eine geeignete CPU. Der Prozessor 110 kann aus einer einzigen integrierten Schaltung wie einem Mikroprozessor oder aus einer geeigneten Anzahl intergrierter Schaltungen und/oder Platinen, die zusammen die Funktionen eines Prozessors erfüllen, bestehen. Prozessor 110 führt geeigneterweise ein Computerprogramm im Hauptspeicher 120 aus.

Die Zusatzspeicherschnittstelle 140 ermöglicht es dem Computersystem 100, Informationen wie Daten aus einer relationalen Datenbank 174 auf Zusatzspeichervorrichtungen wie einer Magnetplatte (z. B. einer Festplatte oder Diskette) oder eine optischen Speicher (z. B. CD-ROM) zu speichern und von dort abzurufen. Wie in Fig. 1 zu sehen ist, ist eine geeignete Speichervorrichtung ein Direktzugriffsspeicher (DASD) 170. Der DASD 170 kann alternativ ein Diskettenlaufwerk sein, das Programme und Daten wie die relationale Datenbanktabelle 174 von einer Diskette lesen kann. In der vorliegenden Patentanmeldung wird der Begriff "Zusatzspeicher" kollektiv für alle Typen von Speichervorrichtungen wie Festplattenlaufwerke, optische Laufwerke, Bandlaufwerke usw. benutzt.

Es ist wichtig, festzuhalten, dass die vorliegende Erfindung zwar im Kontext eines voll funktionsfähigen Computersystems beschrieben wurde (und weiterhin beschrieben wird), dem aber Fachmann klar ist, dass der erfindungsgemäße Mechanismus auch als Programmprodukt zur Ausführung auf einem Computersystem separat vom Computersystem selber im Umlauf gebracht werden kann. Ein solches Programmprodukt kann auf verschiedene Weise im Umlauf gebracht werden, und die vorliegende Erfindung gilt unabhängig vom speziellen Signalträgermedium, das konkret zur Verteilung verwendet wird. Als Beispiele für Signalträgermedien seien hier angeführt: beschreibbare Datenträger wie Disketten sowie CD- ROMs und CD-RW und Übertragungsmediem wie digitale und analoge Datenverbindungen einschließlich drahtloser Übertragungsverbindungen.

Der Speichercontroller 130 ist, von einem Prozessor gesteuert, dafür zuständig, angeforderte Informationen aus dem Hauptspeicher 120 und/oder über die Zusatzspeicherschnittstelle 140 an den Prozessor zu verschieben. Für den Zweck der vorliegenden Erläuterung ist der Speichercontroller 130 als separate Einheit dargestellt; dem Fachmann ist aber klar, dass in der Praxis Teile seiner Funktionen in den Schaltungen des Prozessors 110, des Hauptspeichers 120 und/oder der Zusatzspeicherschnittstelle 140 untergebracht sein können.

Die Terminalschnittstelle 150 ermöglicht es Systemadministratoren und Programmierern, mit dem Computersystem 100 zu kommunizieren, in der Regel über programmierbare Workstations. Obwohl das in Fig. 1 dargestellte System 100 nur einen einzigen Prozessor 110 und einen einzigen Systembus 160 besitzt, kann die Erfindung selbstverständlich auch auf Computersysteme mit mehreren Prozessoren und/oder Bussen Anwendung finden. Entsprechend könnte statt des in dieser Ausführungsform verwendeten typischen, festverdrahteten Multidrop-Bus ein beliebiges Verbindungsmittel benutzt werden, das eine gerichtete Kommunikation in einer computerbezogenen Umgebung unterstützt.

In der dargestellten Ausführungsform enthält der Speicher 120 geeigneterweise ein Betriebssystem 122, ein relationales Datenbanksystem 123 und Benutzerspeicher-Pools 125. Das relationale Datenbanksystem 123 enthält eine SQL- Schnittstelle 124, bei der es sich um eine interaktive Abfrage- und Berichterstellungsschnittstelle handelt. Dem Fachmann ist klar, dass die SQL-Schnittstelle 124 sich unabhängig vom relationalen Datenbanksystem 123 an einer separaten Speicherposition befinden kann.

Die Benutzerspeicher-Pools 125 enthalten den Speicher 126 für relationale Tensoren und eine Benutzeranfrage 129.

Der Speicher 126 für die relationalen Tensoren enthält eine oder mehrere Symboltabellen 127 und eine oder mehrere zugehörige Datenstrukturen 128 in Form relationaler Tensoren. Relationale Tensoren, die im Speicher 126 für relationale Tensoren gespeichert sind, können als Index oder Alternativdarstellung für eine im Hauptspeicher 120 oder DASD 170 gespeicherte relationale Datenbanktabelle verwendet werden. Alternativ kann nach den Prinzipien der vorliegenden Erfindung eine relationale Tensorform die einzige Darstellung einiger oder aller Relationen im System sein.

Die Benutzeranfrage 129 ist eine Informationsanforderung aus der im DASD 170 gespeicherten relationalen Datenbank. Bei dem erfindungsgemäßen Verfahren muss nicht unbedingt die gesamte relationale Datenbank 120 in den Hauptspeicher 120 geladen werden, um die in der Benutzeranfrage 129 angeforderte Information zu erhalten. Statt dessen können Teile der relationalen Datenbank, z. B. bestimmte relationale Tensoren, in den Hauptspeicher 120 geladen und verarbeitet werden, um eine effiziente Möglichkeit bereitzustellen, die durch die Benutzeranfrage 129 aus dem relationalen Datenbanksystem 123 zu gewinnen.

Für den Zweck der vorliegenden Patentanmeldung versteht es sich, dass Hauptspeicher 120 im weitesten Sinne zu verstehen ist und dynamischen RAM (DRAM), Statischen RAM (SRAM), Flash Memory, Cache-Speicher usw. umfassen kann. Außerdem kann der Hauptspeicher 120 einen Teil eines Diskettenlaufwerks als Swap-Datei benutzen. Auch wenn dies in Fig. 1 nicht explizit dargestellt ist, kann der Speicher 120 aus einem einzigen Speicherkomponententyp oder aus vielen verschiedenen Speicherkomponententypen bestehen. Der Speicher 120 und die CPU 110 können beispielsweise auf mehrere verschiedene Computer verteilt sein, die kollektiv das System 100 ausmachen. Es versteht sich auch von selbst, dass Programme im Speicher 120 alle Formen von Computerprogrammen umfassen kann, einschließlich Quellcode, Zwischencode, Maschinencode und jede andere Repräsentation eines Computerprogramms.

Benutzer des relationalen Datenbanksystems 123 fordern Informationen in einer sinnvollen Form an, indem sie eine Benutzeranfrage 129 erstellen. Die Benutzeranfrage 129 ist eine Möglichkeit, das relationale Datenbanksystem 123 so abzufragen, dass nur diejenigen Informationen aus der relationalen Datenbanktabelle 174 abgerufen werden, die bestimmte Kriterien erfüllen. SQL 124 ist die Standardbefehlssprache zur Abfrage relationaler Datenbanken. SQL-Befehle werden von einem Benutzer eingegeben, um die Benutzeranfrage 129 zu erstellen, die dann typischerweise der folgenden Vorverarbeitung durch das relationale Datenbanksystem 123 unterzogen wird. Die Benutzeranfrage 129 wird auf Syntaxfehler analysiert. Die relationale Datenbanktabelle, aus der der Benutzer seine Information beziehen will, wird identifiziert. Dann wird geprüft, ob die Attribut- bzw. Feldnamen, die den Daten zugeordnet sind, in der relationalen Datenbank tatsächlich vorhanden sind. Und die SQL-Befehle in der Benutzeranfrage 129 werden von der Optimierungssoftware im relationalen Datenbanksystem 123 einer Prüfung unterzogen, um die effizienteste Verarbeitungsweise der Benutzeranforderung zu bestimmen.

In einer Ausführungsform der vorliegenden Erfindung, in der die Datenbank oder Teile davon sowohl in einem relationalen Tensor als auch in Form einer Tabellendarstellung gespeichert sind, beinhaltet die Optimierungsvorverarbeitung der Benutzeranfrage 129 durch das relationale Datenbanksystem 123 die Feststellung, ob es relationale Tensoren 126 gibt, die benutzt werden können, um die Effizienz der Beantwortung der Benutzeranfrage 129 zu steigern, indem entweder Statistiken für die Benutzeranfrage oder die Abfrageantwort selber generiert werden. Damit ein relationaler Tensor für die erfindungsgemäßen Verfahren nützlich ist, muss er über die Attribute und Relationen erstellt worden sein, die durch die Kriterien in Benutzeranforderung 129 angegeben wurden. Dies bedeutet, dass es einen relationalen Tensor für die bestimmten Felder in der bestimmten Tabelle geben muss, auf die in der Abfrage Bezug genommen wird.

Spezifische Operationen, die mit relationalen Tensoren ausgeführt werden können, werden weiter unten ausführlich beschrieben. Zuerst wird aber die Tensordarstellung für relationale Daten beschrieben, und es werden bestimmte grundlegende Operationen beschrieben, die bei der Arbeit mit relationalen Tensoren nützlich sind.

Fig. 2A zeigt eine Tabelle, in der eine Relation mit zwei Attributen betrachtet werden kann. Die in Fig. 2A verwendete Tabellendarstellung ist eine konventionelle Darstellung für relationale Daten wie oben erwähnt. Die in Fig. 2A dargestellte Relation ist mit dem oben beschriebenen Beispiel konsistent; die Tupel setzen Städtenamen mit Postleitzahlen in Beziehung. Jedes Tupel enthält ein Stadt/Staat-Attribut und ein Postleitzahlattribut. Im hier dargestellten Fall, der zum Zweck der Illustration vereinfacht ist, gibt es fünf Tupel für fünf verschiedene Postleitzahlen. Es ist zu erkennen, dass zwei der Postleitzahlen Städte in Rochester, Minnesota bezeichnen und daher der Wert des Attributs "Stadt/Staat" bei beiden gleich ist.

Fig. 2B ist eine relationale Tensordarstellung der Tupel, die in Fig. 2A im Tabellenformat dargestellt wurden. Wie in Fig. 2B zu sehen ist, besitzt diese relationale Tensordarstellung die allgemeine Form einer Matrix. Ein relationaler Tensor ist aber keine Matrix, und Operationen, die für Matrizen bekannt und definiert sind, sind in den meisten Fällen nicht auf relationale Tensoren anwendbar und umgekehrt. Grob kann gesagt werden, dass ein relationaler Tensor mit n Ordnungen ein äußeres Produkt der Domänen von n Attributen einer Relation ist. Der Begriff "relationaler Tensor" kann zur Beschreibung dieses Konstrukts verwendet werden, da es sich hierbei nicht um einen Tensor im Sinne der klassischen Mathematik handelt, auch wenn es Analogien zu einer bekannten Tensorkonstruktion gibt. Während bisher der Begriff "relationaler Tensor" verwendet wurde, wird im folgenden der Kürze wegen meist statt des vollständigen Namens "relationaler Tensor" einfach "Tensor" verwendet. Selbstverständlich ist in der vorliegenden Patentanmeldung unter "Tensor" ein "relationaler Tensor" zu verstehen und nicht das bekannte mathematische Konstrukt, das als Tensor bezeichnet wird.

In Fig. 2B ist das erste Attribut der Relation aus Fig. 2A, nämlich das Attribut "Stadt/Staat" einer ersten dimensionalen Ordnung des Tensors zugeordnet, die in diesem Fall als Zeilen dargestellt ist. Das zweite Attribut der Relation aus Fig. 2A, nämlich das Attribut "Postleitzahl" ist einer zweiten dimensionalen Ordnung des Tensors zugeordnet, die in diesem Fall als Spalten dargestellt ist. Es versteht sich von selbst, dass eine Tensordarstellung auch von einer Relation mit drei oder mehr Attributen möglich ist; in diesem Fall ist jedes Attribut einer dimensionalen Ordnung des Tensors zugeordnet.

Entlang jeder Ordnung des Tensors gibt es mehrere diskrete Koordinaten, von denen sich jede auf einen Schlüsselwert bezieht, der in dem entsprechenden Attribut eines oder mehrerer Tupel zu finden ist. Entlang der ersten Ordnung des Tensors aus Fig. 2B lauten die Koordinaten "Cincinnati, OH", "Glendale, OH", "Rochester, MN" und "Washington, DC", die eindeutige Werte des Attributs "Stadt/Staat" der dargestellten Relation sind. Entlang der zweiten Ordnung des Tensors aus Fig. 2B befinden sich die Koordinaten "45202", "45246", "55901", "20231" und "55906", die die eindeutigen Werte des Attributs "Postleitzahl" der dargestellten Relation sind. Für die weitere Referenz wird die Gruppe der Koordinaten entlang einer Ordnung eines Tensors als "Domäne" des Tensors entlang dieser Ordnung bezeichnet.

Wie den bisherigen Ausführungen zu entnehmen ist, besitzt jede Position innerhalb eines Tensors eine Koordinate entlang jeder Ordnung des Tensors, und diese Koordinaten identifizieren zusammengenommen eine eindeutige Kombination von Werten in jedem vom Tensor repräsentierten Attribut. Um die Tupel einer Relaion an jeder Koordinatenposition darzustellen, speichert der Tensor einen numerischen Wert. Der numerische Wert an einer bestimmten Koordinate stellt eine Zählung der Anzahl von Tupeln dar, die die Attributwerte besitzen, welche der Koordinate des numerischen Wertes entlang den Ordnungen des Tensors entsprechen. In dem Tensor in Fig. 2B gibt es also einen numerischen Wert "1" an den Koordinaten ("Cincinnati, OH", "45202"), der angibt, dass die Relation ein Tupel mit diesen Attributwerten enthält. An allen anderen Koordinaten entlang der Ordnung "Postleitzahl" für "Cincinnati, OH", steht der numerische Wert "0", was bedeutet, dass es keine anderen Tupel mit dem "Stadt/Staat"-Attribut "Cincinnati, OH" gibt. Entsprechend steht an jeder Koordinate, die anderen Tupeln in der Relation entspricht, d. h. bei (Glendale, OH", 45246"), ("Rochester, MN", "55901), ("Rochester, MN", "55906") und ("Washington, DC", "20231"), der numerische Wert "1". Es ist klar, dass dann, wenn die ursprüngliche Relation mehrere Tupel mit den gleichen Attributwerten für "Stadt/Staat" und "Postleitzahl" enthalten würde, numerische Werte von 2 oder größer an der entsprechenden Koordinate im Tensor aus Fig. 2B stehen würden, um anzugeben, dass es an diesen Koordinatenwerten mehrere Tupel gibt.

In Fig. 2C ist in tabellarischer Form eine Relation dargestellt, die mit den obigen Beispielen konsistent ist und drei Attribute besitzt, und zwar die Attribute "Vorname" und "Nachname" sowie ein weiteres Attribut für eine Postleitzahl. Jedes Tupel in der Relation gibt den Vor- und Nachnamen einer Person und deren Postleitzahl an.

In Fig. 2D ist ein Tensor der in Fig. 2C dargestellten Relation zu sehen. Dieser Tensor besitzt drei Ordnungen, von denen jede einem Attribut der Relation zugeordnet ist. Entlang einer ersten Ordnung sind die Koordinaten also die Domäne für das "Vorname"-Attribut, nämlich "John", "Kevin" und "Lance". Entlang einer zweiten Ordnung sind die Koordinaten die Domäne für das "Nachname"-Attribut, nämlich "Amundsen", "Kathmann" und "Smith". Entlang einer dritten Ordnung sind die Koordinaten die Domäne für das "Postleitzahl"-Attribut, nämlich "55906", "55901" usw. Dieser Tensor der Ordnung 3 ist dreidimensional dargestellt als eine Reihe von Ebenen, wobei jede Ebene einem Wert für das "Postleitzahl"-Attribut entspricht. Innerhalb jeder Ebene entspricht jede Position einem Wert für das "Vorname"- und das "Nachname"-Attribut. Die Koordinaten jeder dreidimensionalen Position entsprechen einer eindeutigen Kombination des "Vorname"-, des "Nachname"- und des "Postleitzahl"-Attributs. Es ist zu erkennen, dass in der Ebene, die dem Postleitzahlwert "55906" entspricht, der numerische Wert "1" an der Position steht, die dem Tupel ("Lance", "Amundson", "55906") entspricht; dies bedeutet, dass es in der Relation ein Tupel mit dieser Attributwertekombination gibt. An allen anderen Positionen in der Ebene, die dem Postleitzahlenwert "55906" entspricht, der numerische Wert "0" steht, was bedeutet, dass ein anderes Tupel den Postleitzahlenwert "55906" besitzt.

Es ist klar, dass eine Tensordarstellung für eine Relation mit einer beliebigen Anzahl von Attributen verwendet werden kann; die Tensordarstellung besitzt für jedes Attribut der Relation eine Ordnung. Tensoren mit 2 oder 3 Ordnungen wurden in Fig. 2B und Fig. 2D deshalb dargestellt, weil Tensoren höherer Ordnung schwierig darzustellen sind, sie können aber leicht in einem Computersystem als Matrizen dargestellt werden. Es ist auch klar, dass die Beispiele aus Fig. 2A bis Fig. 2D insofern trivial sind, als es nur eine relativ kleine Anzahl von Tupeln und eine relativ kleine Domäne in jedem der Attribute gibt; eine größere Anzahl von Tupeln und größere Domänen wären aber schwer darzustellen. Relationen mit einer größeren Anzahl von Tupeln und Tensoren mit großen Attributdomänen können aber leicht in einem Computersystem dargestellt werden.

Es ist klar, dass die Tensordarstellung einer Relation so wie oben dargestellt einige Analogien zu einer Matrix wie sie in den Prinzipien der linearen Algebra verwendet wird, aufweist. Im folgenden werden verschiedene relationale Operationen, die an einer Tensordarstellung einer Relation ausgeführt werden können, dargestellt und Analogien zu Vektor- und Matrixoperationen, die auf dem Gebiet der linearen Algebra allgemein bekannt sind, hergestellt. Zu diesen Operationen zählen die generalisierte Skalarproduktoperation, bei der in der linearen Algebra die atomische Operation der Bildung einer Summe aus den Produkten von Komponenten von Vektorräumen eine Rolle spielt. Wo die Operanden für ein generalisiertes Skalarprodukt zwei in geeigneeter Weise angeordnete Vektoren sind, ist das Ergebnis ein Skalarwert, der häufig als "inneres Produkt" oder "Skalarprodukt" der beiden Vektoren bezeichnet wird. Wenn die Operanden für ein generalisiertes Skalarprodukt zwei anders angeordnete Vektoren sind, oder wenn die Operanden für ein generalisiertes Skalarprodukt eine Matrix und ein Vektor oder zwei Matrizen sind, kann das Ergebnis ein Vektor oder eine Matrix sein, je nach Anordnung und relativer Orientierung der Operanden.

Relationale Operationen, die mit Hilfe von Tensoren ausgeführt werden, verwenden im manchen Fällen Operationen, die dem generalisierten Skalarprodukt ähnlich sind. Wie im folgenden noch zu sehen ist, müssen aber auch manche eindeutigen Operationen definiert werden, bei denen es keine Analogie in der linearen Algebra gibt.

An dieser Stelle sind einige Bemerkungen zur Verwendung relationaler Tensoren angebracht.

Ein Daten repräsentierender relationaler Tensor kann für alle Attribute der Relation, mit denen die Abfrage arbeitet, oder nur mit einer Teilmenge der Attribute der Relation gebildet werden. In beiden Fällen kann der Daten repräsentierende relationale Tensor effektiv zur Generierung von Statistiken benutzt werden, solange die in der relationalen Operation angegebenen Attribute im Daten darstellenden relationalen Tensor enthalten sind.

Wie weiter unten noch genauer zu sehen ist, kann dort, wo eine Benutzeranfrage eine Einschränkungsoperation angibt, eine Statistik für die Abfrage generiert werden, die angibt, wieviele Tupel das Kriterium erfüllen. Um die Statistik zu generieren, wird der Daten darstellende relationale Tensor verarbeitet, indem die numerischen Werte, die in dem relationalen Tensor mit den Koordinaten, die das in der Benutzeranfrage angegebene Kriterium erfüllen, gespeichert sind, aufsummiert werden. In der hier beschriebenen speziellen Ausführungsform erfolgt diese Aufsummierung dadurch, dass ein relationaler Auswahltensor gebildet wird, der das Kriterium der Benutzeranfrage repräsentiert, dann ein relationales Tensorprodukt aus dem relationalen Auswahltensor und dem Daten repräsentierenden relationalen Tensor gebildet wird, und dann der resultierende relationale Tensor zu einem Skalarwert kontrahiert wird.

In dieser beschriebenen Ausführungsform ist der relationale Auswahltensor ein relationaler Tensor mit Ordnungen, die mit den Ordnungen im Daten darstellenden relationalen Tensor kompatibel sind, und enthält nur die numerischen Werte 1 oder 0. Der relationale Auswahltensor enthält an den Koordinaten, die Tupelwerten entsprechen, welche das Kritierium in der Benutzeranfrage erfüllen, den numerischen Wert "1" und an den Koordinaten, die Tupelwerten entsprechen, welche das Kriterium in der Benutzeranfrage nicht erfüllen, den numerischen Wert "0".

In der hier beschriebenen speziellen Ausführungsform wird der relationale Auswahltensor aus mehreren atomischen Operationen gebildet, die alle wahr sein müssen, damit das in der Benutzeranfrage angegebene Kriterium erfüllt ist. Dazu werden intermediäre relationale Auswahltensoren gebildet, die jedes dieser Kriterien darstellen, und dann wird ein relationales Tensorprodukt aus de intermediären relationen Auswahltensoren gebildet, um den relationalen Auswahltensor zu bilden, der alle Kriterien der Benutzeranfrage repräsentiert. Die intermediären relationalen Auswahltensoren enthalten an allen Positionen mit Koordinaten, die den Werten entsprechen, die das im intermedlären relationalen Auswahltensor repräsentierte Kriterium erfüllen, den numerischen Wert "1" und an allen anderen Positionen den numerischen Wert "2".

In diesen speziellen Ausführungsformen wird das relationale Tensorprodukt aus den beiden relationalen Tensoren wie z. B. zwei relationalen Auswahltensoren oder einem relationalen Auswahltensor und einem Daten darstellenden relationalen Tensor gebildet, indem numerische Werte in entsprechenden Positionen der relationalen Tensoren multipliziert werden, um numerische Werte für diese Koordinate in einem resultierenden relationalen Tensor zu berechnen. In den beschriebenen Ausführungsformen müssen die relationalen Tensoren keine vollständige Entsprechung in der Domäne der Koordinaten der relationalen Tensoren entlang jeder ihrer Ordnungen aufweisen. In solchen Situationen verfügt die Erfindung über eine Methodik zur Berücksichtigung relationaler Tensoren mit nicht übereinstimmenden Domänden bei der Multiplikation relationaler Tensoren.

Außerdem können im Kontext einer Einschränkungsoperation die Ordnungen eines relationalen Auswahltensors so erweitert werden, dass sie denen eines Daten darstellenden relationalen Tensors entsprechen, wenn dies für die relationale Tensormultiplikation erforderlich ist. Dazu wird dem relationalen Auswahltensor die erforderliche Ordnung hinzugefügt und jeder Koordinatenwert in der hinzugefügten Ordnung mit einem Duplikat der vorhandenen Ordnungen des relationalen Tensors in Beziehung gesetzt.

Um den Prozess der relationalen Tensormultiplikation zu vereinfachen, können die Domänen von Koordinaten entlang der Ordnungen des relationalen Auswahltensors mit den Domänen von Koordinaten entlang der Ordnungen des Daten darstellenden relationalen Tensors abgeglichen werden, indem Koordinaten in einer Ordnung des ersten relationalen Tensors, die in der entsprechenden Ordnung des zweiten relationalen Tensors nicht gefunden werden, identifiziert und zu der Ordnung des zweiten relationalen Tensors hinzugefügt werden. Diese Operation wird dann für Koordinaten in der Ordnung des zweiten relationalen Tensors, die im ersten relationalen Tensor nicht gefunden werden, ebenfalls durchgeführt. Wenn die auf diese Weise Koordinaten in einen relationalen Tensor eingefügt werden, wird an allen Positionen des relationalen Tensors, die der hinzugefügten Koordinate entsprechen, der Wert "0" geschrieben, was bedeutet, dass die durch den relationalen Tensor gespeicherte Relation keine Tupel mit dem hinzugefügten Koordinatenwert besitzt.

Bei der Bildung eines relationalen Auswahltensors zur Verwendung mit einem Daten darstellenden relationalen Tensor kann der relationale Auswahltensor ab initio mit Ordnungen, und Koordinaten auf diesen Ordnungen, die vollständig mit dem Daten darstellenden relationalen Tensor konform sind, erzeugt werden, wodurch der Prozess der relationalen Tensormultiplikation vereinfacht wird. Alternativ kann der relationale Tensor mit einer minimalen Größe generiert werden, um die Auswahlkriterien zu repräsentieren, wobei alle Differenzen in den Ordnungen und Domänen des Auswahltensors und des Daten darstellenden relationalen Tensors während der Ordnungserweiterung und der relationalen Tensormultiplikation aufgelöst werden.

Um Statistiken für eine Einschränkungsoperation zu generieren, wird nach der relationalen Tensormultiplikation des resultierende relationale Tensors mit n Ordnungen iterativ kontrahiert, wobei in jeder Iteration der relationale Tensor mit n Ordnungen entlang einer eliminierten Ordnung kontrahiert wird, um ein Ergebnis mit n - 1 Ordnungen zu generieren. Die Werte im Ergebnis mit n - 1 Ordnungen sind mit der Summe der Werte auf der eliminierten Ordnung an der gleichen Koordinate mit n - 1 Ordnungen identisch. Um einen relationalen Tensor in einen Skalarwert umzuwandeln, wird der relationale Tensor entlang jeder seiner Ordnungen kontrahiert, bis nach der letzten Kontrahierung ein einziger Skalarwert übrig bleibt, der die Summe aller Werte an allen Koordinaten im ursprünglichen relationalen Tensor mit n Ordnungen repräsentiert.

In einer weiter unten beschriebenen detailierten Implementierung wird ein relationaler Tensor mit n Ordnungen (wobei n < 2 ist) kontrahiert, indem ein relationaler Identitätstensor mit n - 1 Ordnungen, dessen Größe mit dem Tensor mit n Ordnungen entlang der zu eliminierenden Ordnung konform ist, und n - 2 andere Ordnungen gebildet werden. Der relationale Identitätstensor enthält an jeder Position den numerischen Wert "1". Dann wird ein Matrixprodukt zwischen dem relationalen Identitätstensor mit n - 1 Ordnungen und dem zu kontrahierenden Tensor mit n Ordnungen gebildet, indem innere Produkte von Vektoren berechnet werden, die aus dem relationalen Identitätstensor und entsprechenden Vektoren des ursprünglichen relationalen Tensors mit n Ordnungen ausgewählt werden, wobei die Vektoren entlang der eliminierten Ordnung genommen und die resultierenden Skalarwerte in ein Ergebnis mit n - 1 Ordnungen ander Koordinate mit n - 1 Ordnungen, von der die Vektoren genommen wurden, geschrieben werden.

In dieser Ausführungsform wird ein relationaler Tensor einer ersten Ordnung (d. h. ein Vektor) zu einem Skalar kontrahiert, indem ein relationaler Identitätstensor (d. h. ein Vektor) einer ersten Ordnung gebildet wird, dessen Größe dem relationalen Tensor der ersten Ordnung entsprricht und an allen Positionen den numerischen Wert "1" enthält. Dann wird ein inneres Produkt zwischen dem relationalen Identitätstensor und dem ursprünglichen relationalen Tensor der ersten Ordnung gebildet, um einen Skalarwert zu erhalten.

In einer zweiten Ausführungsform gibt die Benutzeranfrage eine JOIN-Operation an, die ein Kriterium enthält, das auf Attribute von zwei Relationen angewendet wird. In dieser Ausführungsform gibt die Statistik an, wieviele Tupel von der JOIN-Operation erzeugt werden. Um die erste Statistik zu generieren, werden Daten darstellende relationale Tensoren für die erste und zweite durch JOIN zu verknüpfende Relation entlang aller Ordnungen außer derjenigen, die dem im JOIN- Kriterium bearbeiteten Attribut entspricht, kontrahiert, z. B. nach dem oben beschriebenen Verfahren, um intermediäre relationale Tensoren (d. h. Vektoren) der ersten Ordnung zu erzeugen. Die Statistik wird gebildet, indem die Produkte der numerischen Werte in entsprechenden Koordinaten in den intermediären relationalen Tensoren aufsummiert werden.

In der beschriebenen speziellen Ausführungsform werden in der Benutzeranfrage mehrere JOIN-Operationen angegebene, und es werden Statistiken für zwei oder mehr JOIN-Operationen generiert und dazu benutzt, eine Reihenfolge festzulegen, in der die JOIN-Operationen ausgeführt werden, z. B. die JOIN- Operation mit der kleinsten Statistik zuerst.

Um die Generierung von Statistiken aus intermediären relationalen Tensoren zu erleichtern werden in einer Ausführungsform die intermediären relationalen Tensoren zu einer gemeinsamen Domäne in dem vom JOIN-Kriterium bearbeiteten Attribut expandiert und dann ein inneres Produkt aus den expandierten intermediären relationalen Tensoren gebildet. Diese Expandierung der intermediären relationalen Tensoren zu einer gemeinsamen Domäne vereinfacht den nachfolgenden Schritt der Aufsummierung der Produkte entsprechender Koordinaten in den beiden relationalen Tensoren, da die expandierten relationalen Tensoren vergleichbare Koordinaten haben. Eine solche Expansion ist aber nicht unbedingt erforderlich - wenn die Domänen der relationalen Tensoren bei der Berechnung der Statistik nicht expandiert werden, werden Koordinaten, die nur in einem der beiden Tensoren gefunden werden, ignoriert.

In der beschriebenen speziellen Ausführungsform werden die Koordinaten der intermediären relationalen Tensoren nach der Domänenexpansion auf die gleiche Weise angeordnet, so dass die Berechnung der Statistik damit fortgesetzt werden kann, dass ein inneres Produkt zwischen Vektoren, die die beiden intermediären relationalen Tensoren der ersten Ordnung darstellen, gebildet wird. Die Aufsummierung kann aber auch an relationalen Tensoren durchgeführt werden, die nicht die gleiche Koordinatenanordnung besitzen.

In einer dritten Ausführungsform gibt die Benutzeranfrage eine bestimmte Operation mit Datensätzen an, die ein Einschränkungskriterium erfüllen oder nicht erfüllen. In dieser Ausführungsform gibt die Statistik an, wieviele Tupel die Einschränkung erfüllen. Die Implementierung der Operation kann durch Verwendung der Statistik optimiert werden. So kann zum Beispiel das Löschen von Datensätzen durchgeführt werden, indem jedes Tupel in einer Relation bewertet wird, um festzustellen, ob das Einschränkungskriterium erfüllt ist, und je nach Wert der Statistik (a.) entweder ein Tupel aus der Relation gelöscht wird, abhängig davon, ob das Tupel das Einschränkungskriterium erfüllt, oder (b.) ein Tupel zu einer Ersatzrelation transferiert wird, in Abhängigkeit davon, ob das Tupel das Einschränkungskriterium erfüllt. Die Einfügung von Tupeln einer ersten Relation, die ein Einschränkungskriterium erfüllt, in eine zweite Relation, beinhaltet die Generierung einer Statistik über die Anzahl der Tupel, die das Einschränkungskriterium erfüllen, und anhand dieser Zahl entweder (a.) das Durchsuchen der ersten Relation nach Tupeln, die die Einschränkung erfüllen, und Hinzufügen dieser Tupel zur zweiten Relation, oder (b.) die Duplizierung der zweiten Relation und das Löschen der Tupel, die das Einschränkungskriterium nicht erfüllen, aus dem Duplikat und das anschließende Mischen des Duplikats mit der ersten Relation. Die Aktualisierung von Tupeln in einer Relation, die ein Einschränkungskriterium erfüllt, beinhaltet die Generierung einer Statistik über die Anzahl der Tupel, die die Einschränkung erfüllen und, basierend auf dieser Zahl, entweder (a.) die Neuerstellung der Relation durch Transfer der Tupel, die das Kritierum nicht erfüllen, in eine neue Version der Relation und eine anschließende Aktualisierung des Rests, oder (b.) die direkte Aktualisierung der Tupel, die das Einschränkungskriterium erfüllen.

In der unten beschriebenen speziellen Ausführungsform wird die in dieser dritten Ausführungsform verwendete Statistik auf die gleiche Weise generiert wie oben im Zusammenhang mit der ersten Ausführungsform beschrieben.

Um Resultate für eine Abfrage mit einem Einschränkungskriterium zu generieren, wird ein relationaler Auswahltensor gebildet, der das Kriterium der Einschränkungsoperation repräsentiert, und dann wird ein relationales Tensorprodukt aus dem relationalen Auswahltensor und dem Daten darstellenden relationalen Tensor berechnet. Die Tupel, die das in der Abfrage angegebene Kriterium erfüllen, sind dann dem relationalen Tensorprodukt zu entnehmen. Der relationale Auswahltensor wird auf die oben beschriebene Weise aus mehreren Kriterien, die jeweils auf ein einziges Attribut anwendbar sind, gebildet, indem intermediäre relationale Auswahltensoren gebildet werden, die jedes solche Kriterium repräsentieren, und dann ein relationales Tensorprodukt aus den intermediären relationalen Auswahltensoren gebildet wird, um den relationalen Auswahltensor zu bilden, der die mehreren Kriterien der Benutzeranfrage repräsentiert.

Um eine Einschränkungsoperation auszuführen, bei der nur eindeutige Werte in einem oder mehreren bestimmten Attributen von Tupeln, die ein Abfragekriterium erfüllen, ausgegeben werden, z. B. die SQL-Operation SELECT DISTINCT, wird der resultierende relationale Tensor normalisiert. Die Normalisierung des relationalen Tensors beinhaltet die Ersetzung aller von null verschiedenen Werte an allen Positionen des relationalen Tensors durch den Wert 1.

Um eine Einschränkungsoperation auszuführen, bei der nur ein oder mehrere Attribute von Tupeln, die einer Abfrage entsprechen, ausgegeben werden, z. B. bei der SQL-Operation PROJECTION, wird der resultierende relationale Tensor entlang aller Ordnungen außer derjenigen, die den auszugebenden Attributen entsprechen, kontrahiert.

In Fig. 3 wird die Operation beschrieben, die als "Tensorprodukt" 100 bezeichnet wird. Allgemein ausgedrückt erzeugt die Tensorproduktoperation aus zwei Operandentensoren einen resultierenden Tensor, indem die Produkte der numerischen Werte an entsprechenden Koordinaten der beiden Tensoren generiert und die Produkte an eine entsprechende Koordinate im resultierenden Tensor geschrieben werden.

Das Tensorprodukt ist eine generalisierte Operation, die zwei Tensoren mit übereinstimmenden Ordnungen bearbeitet. Relationale Operationen, die das Tensorprodukt verwenden, enthalten Schritte zur Abgleichung der Ordnungen der Tensoren vor der Tensorproduktbildung. Die Schritte zum Angleichen der Ordnungen von Tensoren sind bei Tensoren mit unterschiedlichen Bedeutungen verschieden; die generalisierte Tensorproduktoperation gleicht die Ordnungen der Tensoren daher nicht ab, sondern erfordert vielmehr, dass die Ordnungen vor dem Aufruf des generalisierten Tensorprodukts abgeglichen werden.

In einem ersten Schritt 102 der generalisierten Tensorproduktoperation werden deshalb die Operandentensoren T1 und T2, aus denen das Tensorprodukt gebildet wird, bewertet, um festzustellen, ob sie übereinstimmende Ordnungen besitzen. Speziell werden Tensoren bewertet, um festzustellen, ob die Anzahl der Ordnungen und die Attribute, die diesen Ordnungen zugeordnet sind, identisch sind. Hier ist anzumerken, dass die Koordinaten entlang der Ordnungen der beiden Tensoren nicht identisch sein müssen, d. h. die Domänen der Tensoren entlang ihren Ordnungen müssen nicht gleich sein. Wenn die Ordnungen von Tensor T1 und Tensor T2 übereinstimmen, aber unterschiedliche Domänen besitzen, unternimmt die generalisierte Tensorproduktoperation geeignete Schritte, um die Domänen der Ordnungen bei der Berechnung des Tensorprodukts in Einklang zu bringen. Wenn aber die Ordnungen von T1 und T2 nicht übereinstimmen, wird in Schritt 104 eine Fehlermeldung ausgegeben, die besagt, dass die Ordnungen der Tensoren inkompatibel sind und dass die Tensorproduktoperation deshalb abgebrochen wird.

Angenommen, die Ordnungen der Tensoren T1 und T2 sind kompatibel, so wird in einem nächsten Schritt 106 ein resultierender Tensor Tr gebildet, der die gleichen Ordnungen und Koordinaten besitzt wie das erste Tensorargument T1. Alle numerischen Werte im resultierenden Tensor werden auf Null initialisiert. Anschließend wird in Schritt 108 eine mehrfach zu durchlaufende Schleife begonnen, in der alle Koordinaten in den Operandentensoren T1 und T2 analysiert werden, um den resultierenden Tensor zu bilden. In Schritt 108 wird ein Schleifenindex N auf den Wert 1 initialisiert.

In einem ersten Schritt 112 dieser Mehrfachschleife wird eine Koordinate in Tensor T1 entlang mit n Ordnungen ausgewählt. Dann wird in Schritt 114 der Tensor T2 bewertet, um festzustellen, ob T2 die ausgewählte Koordinate entlang der gleichen Ordnung N besitzt. Ist dies nicht der Fall, wird in Schritt 106 ein Kennzeichen zur späteren Verwendung gesetzt, das signalisiert, dass nicht beide Tensoren die gerade ausgewählte Koordinate in mit n Ordnungen besitzen. Gleichzeitig wird der aktuelle Wert von N ebenfalls in Verbindung mit dem Kennzeichen gesetzt, damit er später bei der Feststellung der Ordnung, an der das Kennzeichen gesetzt wurde, verwendet werden kann. Es ist zu erkennen, dass das Kennzeichen bereits in einem früheren Durchlauf durch Schritt 118 gesetzt worden sein kann; in diesem Fall wird der im vorigen Durchlauf durch Schritt 118 gespeicherte Wert von N nicht überschrieben. Nach Schritt 118 oder direkt nach Schritt 114, falls T2 eine übereinstimmende Koordinate auf mit n Ordnungen besitzt, wird in Schritt 118 der Schleifenindex N mit den Ordnungen der Tensoren T1 und T2 verglichen. Wenn N kleiner ist als die Ordnung der Tensoren T1 und T2, wird in Schritt 120 der Wert von N weitergezählt, und es erfolgt eine Rückkehr zu Schritt 112, um eine Koordinate von T1 entlang der nächsten Ordnung von T1 auszuwählen.

Die obigen Schritte werden wiederholt, bis in jeder Ordnung von Tensor T1 eine Koordinate ausgewählt worden ist, und festgestellt worden ist, ob es für jede dieser Koordinaten in T1 eine passende Koordinate in Tensor T2 gibt. Anschließend ist der Wert von N gleich der Ordnung der Tensoren T1 und T2. An dieser Stelle springt die Verarbeitung von Schritt 118 zu Schritt 122, wo das bei Schritt 118 erwähnte Kennzeichen bewertet wird, um festzustellen, ob in den Tensoren T1 und T2 für die aktuellen Koordinate eine Koordinatenübereinstimmung vorliegt. Wenn das Kennzeichen nicht gesetzt ist, wird die Verarbeitung mit Schritt 124 fortgesetzt, wo die ausgewählten Koordinaten in den Ordnungen der Tensoren T1 und T2 zum Abrufen numerischer Werte aus diesen beiden Tensoren benutzt werden. Die abgerufenen numerischen Werte werden dann multipliziert, und der resultierende numerische Wert wird im Ergebnistensor Tr an den ausgewählten Koordinaten gespeichert.

Nach Schritt 124 wird in Schritt 126 festgestellt, ob alle Koordinaten in Tensor T1 in der aktuellen Ordnung N (der höchsten Ordnung von T1) ausgewählt und verarbeitet worden sind. Ist dies nicht der Fall, wird die Verarbeitung mit Schritt 127 fortgesetzt, wo das in Schritt 118 gesetzte Kennzeichen gelöscht wird, falls das Kennzeichen gesetzt wurde, während N seinen aktuellen Wert hatte. Wurde das Kennzeichen gesetzt, während N einen niedrigeren Wert als den aktuellen hatte, wird das Kennzeichen nicht gelöscht. Nach Schritt 127 erfolgt eine Rückkehr zu Schritt 112, wo eine andere Koordinate in Tensor 1 entlang der aktuellen Ordnung N ausgewählt und verarbeitet wird.

Von Schritt 126 aus wird die Verarbeitung, nachdem alle Koordinaten in Tensor T1 in ihrer höchsten Ordnung ausgewählt und durch die obigen Schritte verarbeitet worden sind, mit Schritt 128 fortgesetzt, wo festgestellt wird, ob alle Koordinaten in Tensor T2 an der aktuellen Koordinate N (der höchsten Ordnung von T2) ausgewählt und verarbeitet worden sind. Ist dies nicht der Fall, wird in Schritt 130 eine Koordinate in T2 entlang mit n Ordnungen ausgewählt. Da bereits alle Koordinaten in T1 ausgewählt worden sind, ist an dieser Stelle bekannt, dass die ausgewählte Koordinate aus T2 nicht in der höchsten Ordnung von T1 zu finden ist. Demnach geht die Verarbeitung mit Schritt 132 weiter, wo festgestellt wird, ob der resultierende Tensor Tr die ausgewählten Koordinaten besitzt.

Wenn die Verarbeitung zum ersten Mal auf diese Weise Schritt bei Schritt 132 angelangt ist, besitzt der resultierende Tensor Tr die ausgewählten Koordinaten nicht, da er ursprünglich als Duplikat der Ordnungen und Koordinaten von Tensor T1 erstellt wurde. Die Verarbeitung wird deshalb mit Schritt 134 fortgesetzt, wo die ausgewählten Koordinaten zum resultierenden Tensor Tr hinzugefügt werden. Die Hinzufügung von Koordinaten für eine bestimmte Position in einen Tensor wie in diesem Schritt beinhaltet, dass zuerst eine Ordnung identifiziert wird, der eine der Koordinaten fehlt. Dann wird die Koordinate zu der Ordnung hinzugefügt, und es wird ein Duplikat aller anderen Ordnungen des Tensors erstellt. Bei der Erstellung dieses Duplikats wird an alle in den resultierenden Tensor Tr eingefügten Positionen der numerische Wert 0 geschrieben. Dieser Prozess wird für jede Ordnung, der eine der hinzuzufügenden Koordinaten fehlt, wiederholt. Nachdem alle Koordinaten gefunden oder zum resultierenden Tensosr Tr hinzugefügt worden sind, ist die erforderliche Verarbeitung für die aktuelle Koordinate abgeschlossen;

an der Position in Tr, die den hinzugefügten Koordinaten entsprechen, bleibt der Wert 0 stehen, da es hier keinen passenden Wert für die Koordinate in Tensor T1 gibt. Nach Schritt 134 kehrt die Verarbeitung deshalb wieder zu Schritt 126 und Schritt 128 zurück, wo festgestellt wird, ob alle Koordinaten in Tensor T1 und Tensor T2 ausgewählt worden sind. Ist dies nicht der Fall, wird in Schritt 130 eine andere ausgewählt, und die ausgewählte Koordinate wird in Schritt 132 bewertet, um festzustellen, ob sie im resultierenden Tensor Tr vorhanden ist.

Es ist zu erkennen, dass typischerweise die Operationen in Schritt 134 zum Hinzufügen von Koordinaten zum resultierenden Tensor Tr wesentlich mehr Positionen einfügt als die eine, die in Schritt 132 nicht gefunden wurde. Entsprechend werden in einigen nachfolgenden Durchgängen von Schritt 132 die ausgewählten Koordinaten im resultierenden Tensor Tr gefunden, obwohl sie im Operandentensor T1 fehlen. In diesem Fall geht die Verarbeitung von Schritt 132 direkt zurück zu Schritt 126.

Ist in Schritt 122 das oben erwähnte Kennzeichen gesetzt, wenn die Verarbeitung bei Schritt 122 angelangt ist, bedeutet dies, dass der Tensor T1 eine ausgewählte Koordinate entlang einer seiner Ordnungen besitzt, die in T2 nicht gefunden wurde. In diesem Fall geht die Verarbeitung ebenfalls mit Schritt 132 weiter, um zu bestätigen, dass die fehlende Koordinate in Tensor Tr eingefügt worden ist, und wenn dies nicht der Fall ist, wird sie in Schritt 134 eingefügt. Dann erfolgt eine Rückkehr zu Schritt 126 und Schritt 128, um bei Bedarf weitere Koordinaten in Tensor T1 oder T2 auszuwählen.

In den obigen Schritten wird schließlich einmal in Schritt 128 festgestelle, dass alle Koordinaten in den Tensoren T1 und T2 in der aktuellen Ordnung bereits augewählt worden sind. In diesem Fall folgt nach Schritt 128 Schritt 138, wo festgestellt wird, ob der aktuelle Wert von N größer als 1 ist. Wenn N gleich 1 ist, sind alle Positionen in allen Ordnungen der Tensoren T1 und T2 verarbeitet worden, und die Tensorproduktoperation ist abgeschlossen. Ist N hingegen größer als 1, was der Fall ist, wenn die Verarbeitung zum ersten Mal bei Schritt 136 angekommen ist, dann wird in Schritt 138 das in Schritt 118 gesetzte Kennzeichen gelöscht, falls es beim aktuellen Wert von N gesetzt wurde. Wenn der in Schritt 118 gespeicherte Wert von N signalisiert, dass das Kennzeichen bei einem niedrigeren N- Wert als dem aktuellen gesetzt wurde, wird das Kennzeichen nicht gelöscht.

Dann wird in Schritt 140 der Wert von N verringert, und die Verarbeitung kehrt zu Schritt 126 zurück, um festzustellen, ob alle Koordinaten in T1 entlang mit n Ordnungen im aktuellen Durchgang, d. h. seit der Wert von N zum letzten Mal niedriger war als der aktuelle, ausgewählt worden sind. Es ist zu erkennen, dass in dem Prozess aus Fig. 3 bei der Bewertung der Ordunungen und Koordinaten von T1 und T2 der Wert von N von 1 bis zu einem Wert, der ein Vielfaches der Anzahl der Ordnungen in T1 und T2 ist, erhöht wird. Bei jeder Wiederholung dieses Prozesses werden alle Koordinaten in allen höheren Ordnungen bewertet. Auf diese Weise gibt es einen einzigen Durchlauf durch die erste Ordnung von T1 und T2 und mehrere Durchläufe durch jede der höheren Ordnungen von T1 und T2.

Nach Abschluss dieser Durchläufe wird der einzige Durchlauf durch die erste Ordnung von T1 und T2 abgeschlossen, und die Verarbeitung geht von Schritt 128 zu Schritt 136 weiter, wo N gleich 1 ist. In diesem Fall wird die Verarbeitung mit Schritt 142 und ist abgeschlossen.

In Fig. 4 kann die Verwendung des Tensorprodukts und anderer weiter unten definierter Operationen im Kontext der Verarbeitung einer SQL-Einschränkungsoperation 150 wie SELECT, SELECT DISTINCT, PROJECT, SELECT . . . LIKE SELECT . . . FROM beschrieben werden, ebenso wie die Generierung der Statistiken für eine solche Operation.

In einem ersten Schritt 152 wird die Einschränkungsoperation in atomische Einschränkungsoperationen aufgegliedert. Dazu wird die Einschränkung umgeschrieben und in spezielle Klauseln dividiert, die durch die logische Operation "UND" verknüpft werden. Jede atomische Operation kann spezielle Kriterien enthalten, die auf Attribute einer Relation anzuwenden sind.

In einem nächsten Schritt 154 wird eine atomische Operation als Auswahltensor ausgedrückt, d. h. als ein Tensor, der nur die Werte 0 oder 1 enthält. Die Ordnungen und Koordinaten des Auswahltensors sind diejenigen, auf die in der atomischen Operation Bezug genommen wird. In Fig. 4A sind beispielsweise zwei Auswahltensoren dargestellt, die aus atomischen Operationen erzeugt worden sind. Der erste Auswahltensor 156 stellt eine atomische Operation dar, in der Tupel mit dem Stadtattributwert ""Cincinnati, OH", "Glendale, OH", "Cleveland, OH" oder "Columbus, OH" ausgewählt werden. Der zweite Auswahltensor 158 stellt eine atomische Operation dar, in der Tupel mit einem Postleitzahlattributwert von "45246" oder "55906" ausgewählt werden. Diese Tensoren haben die Ordnung 1; sie identifizieren nur Koordinatenwerten entlang der Ordnung "Stadt" bzw. "Postleitzahl". Außerdem handelt es sich bei den Koordinatenwerten, die entlang der relevanten Ordnung identifiziert werden, um diejenigen, die dem Auswahlkriterium unterliegen. Andere Koordinatenwerte sind in der relevanten Ordnung nicht enthalten.

Auswahltensoren können aus relativ einfachen atomischen Ausdrücken wie z. B. City = {"Cincinnati, OH" oder "Glendale, OH" oder "Cleveland, OH" oder "Columbus, OH"} erzeugt werden, wodurch der Auswahltensor 158 generiert werden würde. Sie können aber auch aus wesentlich komplexeren atomischen Ausdrücken einschließlich Ausdrücken, in denen keine Attributwerte identifiziert werden, generiert werden.

Ein Auswahltensor könnte zum Beispiel aus einem atomischen Ausdruck LIKE "C*" erzeugt werden; in diesem Fall würde die Domäne von Stadtwerten im Daten darstellenden Tensor, der dem Kriterium unterliegt, abgefragt werden, um alle Werte zu ermitteln, die das LIKE-Kriterium erfüllen, in diesem Fall also die Werte, die "Cincinnati, OH", "Cleveland, OH" und "Columbus, OH". Dann würde ein Auswahltensor in der Form von Tensor 158 gebildet, der diese Koordinatenwerte identifiziert und ihnen den Wert 1 zuordnet. Operatoren wie < (GREATER THAN (grösser als)), < (LESS THAN (kleiner als)), < = (GREATER THAN OR EQUAL (grösser oder gleich)) und < = (LESS THAN OR EQUAL (kleiner oder gleich)) können auf entsprechende Weise verarbeitet werden, indem die Werte in der Domäne der relevanten Ordnung des Daten darstellenden Tensors, die das Kriterium erfüllen, ermittelt werden. Zusammengesetzte Ausdrücke, die auf diesen Ausdrücken basieren, können ebenfalls verarbeitet werden, z. B. BETWEEN . . . AND . . . . ., was gleichbedeutend ist mit einer GREATER THAN EQUAL- und einer LESS THAN OR EQUAL-Operation. Außerdem können negative Einschränkungen wie NOT EQUAL (nicht gleich) auf ähnliche Weise verarbeitet werden, indem ein Auswahltensor erzeugt wird, der für jeden Wert in der Domäne für das der NOT-Einschränkung unterlieg 31859 00070 552 001000280000000200012000285913174800040 0002010056765 00004 31740ende Attribut, das im der Einschränkung unterliegenden Daten darstellenden Tensor gefunden wird, Koordinaten besitzt. Dann wird für jede Koordinate, die die Einschränkung erfüllt, der Wert 1 eingefügt.

Die Logik des Einschränkungskriteriums kann den Booleschen Operator OR (oder) oder kompliziertere Boolesche Operatoren wie XOR (exklusiv oder) enthalten. Diese können ebenso verarbeitet werden, da OR, XOR und alle anderen Booleschen Operatoren nach der Regel von Black, dass A AND B gleich (NOT ((NOT A) OR (NOT B))) ist, mit Hilfe von AND (und) beschrieben werden können. A XOR B kann ausgedrückt werden als (A AND NOT B) OR (B AND NOT A), was nach der Regel von Black äquivalent ist mit (NOT (NOT (A AND NOT B)) AND (NOT (B AND NOT A)))). Auch andere Transformationen sind möglich.

Nach der Erstellung eines Auswahltensors für eine atomische Operation in der Einschränkung wird in Schritt 160 festgestellt, ob es in der Einschränkung weitere atomische Operationen gibt. Ist dies der Fall, wird in Schritt 162 eine weitere atomische Operation ausgewählt, und in Schritt 164 wird diese atomische Operation in einen Auswahltensor umgewandelt. Auch hier enthält der Auswahltensor nur die Ordnungen und Koordinatenwerte, die dem Auswahlkriterium unterliegen.

Nach Schritt 164 werden in Schritt 166 und Schritt 168 die in den vorhergehenden Schritten erstellten Auswahltensoren aneinander angeglichen. Speziell werden durch die Operation der Expandierung relationaler Tensoren, die im Zusammenhang mit Fig. 5 beschrieben wird (im folgenden als "Ordnungsexpandierungsoperation" bezeichnet), die Ordnungen aller Tensoren expandiert, so dass sie die vom jeweils anderen Tensor benutzten Ordnungen besitzen. In Fig. 4C ist, wenn der Tensor 156 aus Fig. 4A oder der Tensor 158 aus Fig. 4B mit dem entsprechenden Tensor abgeglichen wird, das Ergebnis ein Tensor der Ordnung 2 mit der in Fig. 4C dargestellten Form. Die Interpretation des Tensors aus Fig. 4C ergibt, dass jeder Wert einen der vier in Fig. 4A angegebenen Städtenamen und einen der beiden in Fig. 4B angegebenen Postleitzahlenwerte bezeichnet.

In Fig. 5 kann die Operation 210 zum Expandieren des ersten Tensors T1, so dass er mit einem zweiten Tensor T2 konform ist, ausführlicher erläutert werden. Diese Operation beinhaltet eine Duplizierung der vorhandenen Ordnungen des ersten Tensors für jede Koordinate in jeder Ordnung des zweiten Tensors, die im ersten Tensor nicht gefunden wird. Diese Operation entspricht im Großen und Ganzen der Durchführung einer Matrixmultiplikation des ersten Tensors T1 mit einem Identitätstensor, der an allen Positionen nur den numerischen Wert 1 besitzt, und der alle Ordnungen und Koordinaten von T1 sowie alle zusätzlichen Ordnungen und Koordinaten, die nur in T2, aber nicht in T1 vorhanden sind, besitzt.

Eine prozedurale Beschreibung dieses Prozesses ist in Fig. 5 zu sehen. In einem ersten Schritt 212 wird eine Ordnung von T2 ausgewählt, und in Schritt 214 wird T1 bewertet, um festzustellen, ob die ausgewählte Ordnung vorhanden ist. Ist dies nicht der Fall, dann wird in Schritt 216 die ausgewählte Ordnung zu T1 hinzugefügt, indem die Datenstruktur von T1 entsprechend modifiziert wird. In Schritt 218 wird den zuvor vorhandenen Ordnungen in T1 (d. h. denen, die vor der Hinzufügung einer Ordnung in Schritt 216 vorhanden waren) ein Koordinatenwert aus der ausgewählten Ordnung T2 zugeordnet. Dann wird in Schritt 220 festgestellt, ob die ausgewählte Ordnung in T2 weitere Koordinatenwerte besitzt. Ist dies der Fall, werden in Schritt 222 die zuvor vorhandenen Ordnungen von T1 dupliziert, und dem Duplikat wird ein Koordinatenwert der ausgewählten Ordnung von T2 zugeordnet. Dann kehrt die Verarbeitung zu Schritt 220 zurück, um festzustellen, ob es in der ausgewählten Ordnung von T2 noch weitere Koordinatenwerte gibt, die keinem Duplikat der Ordnungen von T1 zugeordnet sind. Wenn dies der Fall ist, kehrt die Verarbeitung zu Schritt 222 zurück. Diese beiden Schritte werden wiederholt, bis jedem Koordinatenwert in der ausgewählten Ordnung von T2 ein Duplikat der zuvor vorhandenen Ordungen von T1 zugeordnet worden ist.

Nachdem in den Schritten 220 und 222 der Prozess der Duplizierung zuvor vorhandener Ordnungen von T1 abgeschlossen worden ist, wird in Schritt 224 festgestellt, ob alle Ordnungen von T2 bewertet worden sind. Die Verarbeitung wird auch von Schritt 214 aus direkt mit Schritt 224 fortgesetzt, falls T1 die ausgewählte Ordnung in T2 besitzt. In Schritt 224 wird festgestellt, ob es Ordnungen von T2 gibt, die noch nicht ausgewählt worden sind. Wenn dies der Fall ist, kehrt die Verarbeitung von Schritt 224 zu Schritt 212 zurück, um eine andere Ordnung von T2 auszuwählen, und der oben beschriebene Prozess wird wiederholt. Wenn alle Ordnungen in T2 ausgewählt worden sind, ist Tensor T1 soweit expandiert worden, dass er mit Tensor T2 konform ist, und der Prozess ist abgeschlossen (Schritt 226).

Als zweites Beispiel für den Prozess der Expandierung der Ordnungen eines Auswahltensors kann auf den Auswahltensor in Fig. 5A verwiesen werden. Dieser Tensor enthält eine einzige Ordnung für das Postleitzahlattribut und wählt alle Tupel mit der Postleitzahl "45246", "55901", "20231" oder "55906" aus. Würde dieser Tensor so expandiert, dass er beispielsweise mit dem Daten darstellenden Tensor in Fig. 3A konform ist, wäre das Resultat ein Tensor wie in Fig. 5B. Es ist zu erkennen, dass dieser Tensor für jeden der vier Koordinatenwerte in der Ordnung "Stadt" des Tensosrs aus Fig. 3A ein Duplikat der einzigen Domäne des Tensors aus Fig. 5A enthält. Es wird außerdem bestätigt, dass die Auswirkung einer Tensormultiplikation zwischen dem Auswahltensor aus Fig. 5B und dem Daten darstellenden Tensor aus Fig. 3A darin besteht, dass diejenigen Tupel ausgewählt werden, die einen der vier im Zusammenhang mit Fig. 5A erwähnten Postleitzahlencode besitzen.

Wieder in Fig. 4 wird, nach den Schritten 166 und 168, in denen die Auswahltensoren so expandiert wurden, dass sie miteinander konform sind, in Schritt 170 ein Tensorprodukt aus den Auswahltensoren gebildet. Es kann bestätigt werden, dass dieses Tensorprodukt einen resultierenden Tensor erzeugt, der den kollektiven Effekt der Auswahltensoren, die als Operanden der Tensorproduktoperation verwendet werden, repräsentiert. So wäre beispielsweise das Tensorprodukt aus dem Auswahltensors aus Fig. 4B und dem Auswahltensor aus Fig. 5B ein Auswahltensor wie in Fig. 5C. Dieser Auswahltensor würde nur diejenigen Tupel auswählen, die einen der im Zusammenhang mit Fig. 5A genannten Stadtwerte und einen der im Zusammenhang mit Fig. 5B genannten Postleitzahlen und eine der Postleitzahlwertreferenzen aus Fig. 5C besitzen.

Nach Schritt 170 erfolgt eine Rückkehr zu Schritt 160, um gegebenenfalls weitere atomische Operationen auszuführen, die aus dem ursprünglichen Auswahlkritierium gewonnen wurden. Wenn alle atomischen Operationen verarbeitet worden sind, wird die Verarbeitung der Einschränkungsoperation mit Schritt 172 fortgesetzt, wo der resultierende Auswahltensor gemäß dem weiter unten im Zusammenhang mit Fig. 5 beschriebenen Prozess so expandiert wird, dass er mit dem Daten darstellenden Tensor für die Relation, die der Einschränkungsoperation unterzogen wird, konform ist. Dann wird in Schritt 174 durch die im Zusammenhang mit Fig. 3 beschriebene Operation ein Tensorprodukt aus dem expandierten Auswahltensor und dem Daten darstellenden Tensor gebildet. Das Resultat ist wie erwähnt ein neuer Daten darstellender Tensor, der nur diejenigen Tupel repräsentiert, die die Einschränkung erfüllen.

Nach Schritt 174 können verschiedene Operationen mit dem neu erstellten Daten darstellenden Tensor ausgeführt werden. Eine erste Operation 176, die ausgeführt werden kann und die unter Bezugnahme auf die Schritte 178 bis 184 beschrieben wird, ist die Erstellung von Statistiken über das Einschränkungskriterium, speziell über die Anzahl der Tupel in der identifizierten Relation, die das Auswahlkriterium erfüllen. Um die Statistik zu erzeugen, wird in Schritt 178 eine Ordnung des in Schritt 174 gebildeten Tensorprodukts ausgewählt, und in Schritt 180 wird eine relationale Tensorkontraktionsoperation, im folgenden allgemein als Tensorkontraktionsoperation oder einfach als Kontraktionsoperation bezeichnet, verwendet, um den Tensor entlang dieser Ordnung zu kontrahieren. Diese Kontraktionsoperation wird im Folgenden unter Bezugnahme auf Fig. 6 beschrieben. Nachdem der Tensor entlang einer Ordnung kontrahiert worden ist, wird in Schritt 182 festgestellt, ob es im Tensor noch nicht kontrahierte Ordnungen gibt, und wenn dies der Fall ist, kehrt der Prozess zu Schritt 178 zurück, um eine nicht kontrahierte Ordnung auszuwählen und die Kontraktionsoperation aus Fig. 6 für diese Ordnung auszuführen. Das Ergebnis dieser Schleife besteht letztlich darin, dass der in Schritt 174 erzeugte Daten repräsentierende Tensor zu einem Skalarwert kontrahiert wird, der die Anzahl der Tupel in der durch den Tensor repräsentierten Relation angibt. Dieses skalare Ergebnis ist die gewünschte Statistik, wie in Schritt 184 zu sehen ist.

In Fig. 6 können Details der Kontraktionsoperation erklärt werden. Die Kontraktionsoperation eliminiert eine Ordnung aus einem Tensor, indem die Ordnung eliminiert wird und alle numerischen Werte aus der eliminierten Ordnung in die verbleibenden Ordnungen aufgenommen werden. Die Kontraktion hat einen ähnlichen Effekt wie die Matrixoperation der Multiplikation von Vektorräumen, die den Ordnungen des Tensors mit entsprechenden Covektorräumen entsprechen; dabei werden die numerischen Werte von der kontrahierten Ordnung aufsummiert und in die anderen Ordnungen aufgenommen.

Ein erster Schritt der in Fig. 6 dargestellten Kontraktionsoperation 230 besteht darin, festzustellen, ob die Ordnung des Tensors größer als 1 ist. Zuerst werden alle Tensoren kontrahiert, indem einfach die Summe aller numerischen Werte an allen Koordinatenwerten im Tensor berechnet wird wie in Schritt 234. Der resultierende numerische oder skalare Wert wird dann in Schritt 236 als Ergebnis der Kontraktionsoperation ausgegeben.

Tensoren der Ordnung 2 oder einer höheren Ordnung werden nicht zu Skalaren, sondern zu Tensoren der nächst niedrigeren Ordnung kontrahiert. Die dazu erforderlichen Schritte beginnen bei Schritt 238, wo ein resultierender Tensor erzeugt wird, der in seinen Ordnungen und Koordinaten mit dem Eingabetensor konform ist, dem aber die zu kontrahierende Ordnung fehlt. Dann wird in Schritt 240 eine bestimmte Position entlang diesen Ordnungen ausgewählt; speziell wird die Position ausgewählt, indem Koordinaten entlang jeder der Ordnungen des Tensors, die nicht eliminiert werden sollen, ausgewählt werden. In Schritt 242 werden alle numerischen Werte in der zu eliminierenden Ordnung, die an Positionen mit den ausgewählten Koordinaten stehen, zu einer skalaren Summe aufsummiert. In Schritt 244 wird diese Summe an den ausgewählten Koordinaten in den resultierenden Tensor eingefügt. In Schritt 246 wird festgestellt, ob es andere eindeutige Koordinatensätze in den nicht eliminierten Ordnungen gibt, die noch ausgewählt werden müssen. Wenn dies der Fall ist, kehrt die Verarbeitung zu Schritt 240 zurück, um einen neuen Koordinatensatz auszuwählen. Wenn alle Koordinaten ausgewählt und auf diese Weise verarbeitet worden sind, sind alle numerischen Werte in der eliminierten Ordnung in die verbleibenden Ordnungen komprimiert worden. Demnach ist in diesem Fall in Schritt 248 die Kontraktionsoperation abgeschlossen, wobei der in Schritt 238 erzeugte resultierende Tensor das Ergebnis der Kontraktionsoperation darstellt.

In Fig. 6A bis 6C ist ein praktisches Beispiel des Kontraktionsprozesses hilfreich. Fig. 6A zeigt einen Daten darstellenden Tensor, z. B. den Daten darstellenden Tensor, der durch den im Zusammenhang mit Fig. 3C beschriebenen Prozess erzeugt wird. In Fig. 6B ist der Tensor der Ordnung 1 dargestellt, der durch den Prozess aus Fig. 6 erzeugt wird, wenn der Tensor aus Fig. 6A durch Eliminierung der Ordnung "Postleitzahl" komprimiert wird. Es ist zu erkennen, dass die numerischen Werte an allen Koordinaten entlang der Ordnung "Postleitzahl" des Tensors aus Fig. 6A in die entsprechenden Positionen in dem Tensor der Ordnung 1 aus Fig. 6B aufsummiert worden sind. In Fig. 6C ist der Skalar dargestellt, der durch eine weitere Komprimierung des Tensors aus Fig. 6B erzeugt wird; der Skalarwert ist die Summe der numerischen Werte in jeder der Koordinaten der Ordnung "Stadt/Staat" des Tensors aus Fig. 6B.

In Fig. 4 ist eine andere Operation dargestellt, die ausgeführt werden kann, nachdem ein Daten darstellender Tensor, der die Tupel, die ein Einschränkungskriterium erfüllen, darstellt, und zwar handelt es sich um die Materialisierung dieser Ergebnisse auf eine gewünschte Art und Weise (Schritt 186). Die Ergebnisse können beispielsweise in Form einer einfachen Liste oder Tabelle der Tupel, die das Einschränkungskriterium erfüllen, materialisiert werden. Diese kann leicht aus einem Daten darstellenden Tensor wie dem oben beschriebenen generiert werden. Durch eine SQL-Abfrage können aber auch komplexere Operationen zur Materialisierung angegeben werden, die gemäß Fig. 5 verarbeitet werden.

Eine solche Operation ist die Auswahlabfrage PROJECTION, die anfordert, dass Daten nur für einen bestimmten Attributwert oder bestimmte Attributwerte ausgegeben werden sollen. In Schritt 188 wird festgestellt, ob in der Benutzerabfrage eine solche PROJECTION-Operation angegeben ist. Wenn dies der Fall ist, werden in Schritt 190 bis 194 Schritte unternommen, um den in Schritt 174 erzeugten Tensor so zu kontrahieren, dass er nur die angeforderten Attribute der Relation darstellt. Speziell wählt der Prozess in Schritt 190 eine Ordnung des Daten darstellenden Tensors aus, die von den in der PROJECTION-Operation angeforderten Ordnungen verschieden ist. Dann wird in Schritt 192 der Daten darstellende Tensor entlang der ausgewählten Ordnung kontrahiert wie im Zusammenhang mit Fig. 6 beschrieben. Schließlich wird in Schritt 194 festgestellt, ob es weitere zu kontrahierende Ordnungen gibt, und wenn dies der Fall ist, wird die Verarbeitung mit Schritt 190 fortgesetzt. Diese Abfolge der Schritte 190, 192 und 194 wird wiederholt, bis alle Ordnungen außer der PROJECTION-Ordnung aus dem Daten darstellenden Tensor eliminiert worden sind, wobei die numerischen Werte aus diesen Ordnungen in die verbleibenden Ordungen aufgenommen werden. Die Ergebnisse der PROJECTION- Operation können dann direkt aus dem Daten darstellenden Tensor realisiert werden.

Eine zweite Operation, die mit den Ergebnissen einer Einschränkungsoperation ausgeführt werden kann, ist eine DISTINCT-Auswahlabfrage, bei der angefordert wird, dass nur verschiedene Tupel ausgegeben werden. In Schritt 196 wird festgestellt, ob in der Benutzerabfrage eine solche DISTINCT-Operation angegeben ist, und wenn dies der Fall ist, wird in Schritt 198 eine Tensornormalisierungsoperation ausgeführt, um den in Schritt 174 erzeugten Tensor so zu normalisieren, dass er nur die einmaligen Tupel der Relation, die das Auswahlkriterium erfüllen, darstellt. Speziell werden in Schritt 198 alle numerischen Werte, die größer als 1 sind, durch den Wert 1 ersetzt, so dass der Tensor, wenn er in Form von Tupeln oder als Datenstrom realisiert wird, keine doppelten Tupel enthält.

Nach den Verarbeitungsschritten von PROJECTION und/oder DISTINCT werden in Schritt 200 die Ergebnisse der Einschränkungsoperation materialisiert, z. B. indem Tupel, eine Tabelle oder ein anderes geeignetes Ausgabeformat erzeugt wird.

In Fig. 7 kann der Prozess 260 der Normalisierung eines relationalen Tensors, auch einfach als Normalisierungsprozess bezeichnet, erläutert werden. Dieser Prozess gewährleistet, dass jeder numerische Wert im Tensor, der größer als 1 ist, auf den Wert 1 normalisiert wird. Auf diese Weise wird in Schritt 262 ein Satz von Koordinaten entlang aller Ordnungen des Eingabetensors ausgewählt, und in Schritt 264 wird festgestellt, ob der numerische Wert an den ausgewählten Koordinaten größer als 1 ist. Wenn dies der Fall ist, wird in Schritt 266 der ausgewählte numerische Wert durch 0 ersetzt. Nach Schritt 266 oder direkt nach Schritt 264, falls der numerische Wert an der aktuellen Koordinate 0 oder 1 ist, wird in Schritt 268 festgestellt, ob es noch unverarbeitete Positionen im Eingabetensor gibt. Der Prozess aus Fig. 7 durchläuft alle Koordinaten in einem Tensor, um sicherzustellen, dass der Tensor vollständig normalisiert wird. Wenn alle Koordinaten normalisiert worden sind, ist der Prozess abgeschlossen, und nach Schritt 268 geht die Kontrolle an Schritt 270 über, wodurch signalisiert wird, dass der Normalisierungsprozess abgeschlossen ist.

In Fig. 8A bis 8C werden verschiedene Szenarien beschrieben, in denen mit dem Prozess aus Fig. 4 berechnete Statistiken bei der Steigerung der Effizienz von Datenbankaktualisierungen nützlich sein können. Diese Szenarien können jetzt ausgearbeitet werden.

In Fig. 8A können Statistiken zum Löschen von Datensätzen benutzt werden (Schritt 280). In einem ersten Schritt 282 wird festgestellt, ob es einen Tensor gibt, der für die im Auswahlkriterium der Löschoperation verwendeten Ordnungen und Koordinaten definiert ist. Wenn dies nicht der Fall ist, wird in Schritt 284 die Löschoperation auf konventionelle Weise ausgeführt, z. B. indem alle Datensätze in der Relation durchsucht werden und diejenigen gelöscht werden, die das Auswahlkriterium erfüllen. Wenn aber ein geeigneter Tensor zur Verfügung steht (Schritt 286), dann wird die im Zusammenhang mit Fig. 4 beschriebene Einschränkungsoperation aufgerufen, um einen resultierenden Tensor für die Analyse zu generieren. Speziell wird die Anzahl der Treffer der Einschränkungsoperation in Schritt 288 als Eingabe für eine Entscheidung verwendet. Wenn die Anzahl der Treffer einen Schwellenwert nicht erreicht (Schritt 290), wird die konventionelle Löschverarbeitung in Schritt 292 durchgeführt. Wenn die Statistik aber den Schwellenwert überschreitet (Schritt 294), wird in Schritt 296 zum Löschen der identifizierten Datensätze die Relation neu erstellt, wobei nur diejenigen Tupel verwendet werden, die das Einschränkungskriterium nicht erfüllen. Wo ein größerer Prozentsatz der Datensätze einer Relation gelöscht werden, kann die Neuerstellung der Relation nur mit den verbleibenden Datensätzen effizienter sein als das Löschen der Datensätze aus der vorhandenen Relation. Dieser Ansatz wird in dem Prozess in Fig. 8A genutzt, wo die Statistik den in Schritt 288 festgelegten Schwellenwert überschreitet.

In Fig. 8B kann die Statistik auch dazu benutzt werden, ausgewählte Datensätze aus einer zweiten Relation in eine erste Relation einzufügen (Schritt 296). In einem ersten Schritt 298 wird festgestellt, ob es einen Tensor gibt, der für die im Kriterium zur Auswahl der Datensätze verwendeten Ordnungen und Koordinaten definiert ist. Wenn dies nicht der Fall ist, wird in Schritt 300 die Einfügungsoperation auf konventionelle Weise ausgeführt, z. B. indem die zweite Relation durchsucht wird und passende Datensätze an das Ende der ersten Relation angehängt werden. Wenn aber geeignete Tensoren zur Verfügung stehen (Schritt 302), dann wird die im Zusammenhang mit Fig. 4 beschriebene Einschränkungsoperation aufgerufen, um einen resultierenden Tensor für die Analyse zu generieren. Und zwar wird die Anzahl der Treffer der Einschränkungsoperation in Schritt 304 als Eingabe für eine Entscheidung verwendet. Wenn die Anzahl der Treffer einen Schwellenwert nicht erreicht (Schritt 306), erfolgt in Schritt 308 eine konventionelle Verarbeitung, bei der zuerst die erste Relation nach Tupeln durchsucht wird, die das Kriterium erfüllen, und diese Tupel dann zu der zweiten Relation hinzugefügt werden. Wenn die Statistik aber den Schwellenwert überschreitet (Schritt 310), wird in Schritt 312 der gesamte zweite Tensor dupliziert, dann werden die Tupel, die das Kriterium nicht erfüllen, gelöscht, und schließlich wird das Ergebnis an den ersten Tensor angehängt. Es ist klar, dass dieser Ansatz effizienter sein kann als das Verschieben der einzelnen Datensätze, wenn die meisten Tupel in der zweiten Relation in die erste Relation kopiert werden müssen.

In Fig. 8C kann die Statistik auch zur Aktualisierung von Datensätzen einer Relation, die ein Einschränkungskriterium erfüllen, benutzt werden (Schritt 320). In einem ersten Schritt 322 wird festgestellt, ob es einen Tensor gibt, der für die in der Operation verwendeten Ordnungen und Koordinaten definiert ist. Wenn dies nicht der Fall ist, wird die Tensoraktualisierungsoperation auf konventionelle Weise ausgeführt, z. B. indem die Tupel, die das Auswahlkriterium erfüllen, bei ihrem Auffinden aktualisiert werden. Wenn aber geeignete Tensoren zur Verfügung stehen (Schritt 326), dann wird die im Zusammenhang mit Fig. 4 beschriebene Einschränkungsoperation aufgerufen, um einen resultierenden Tensor für die Analyse zu generieren. Dann wird die Anzahl der Treffer der Einschränkungsoperation in Schritt 328 als Eingabe für eine Entscheidung verwendet. Wenn die Anzahl der Treffer einen Schwellenwert nicht erreicht (Schritt 330), erfolgt in Schritt 332 eine konventionelle Verarbeitung, beider zuerst die erste Relation nach Tupeln durchsucht wird, die das Kriterium erfüllen, und diese Tupel dann aktualisiert werden. Wenn die Statistik aber den Schwellenwert überschreitet (Schritt 334), wird in Schritt 336 der gesamte Tensor neu erstellt, und dabei werden die Tupel, die das Auswahlkriterium nicht erfüllen, weggelassen. Diese Operation kann effizienter sein als der konventionelle Ansatz der Schritte 324 und 332.

In Fig. 9 kann auch eine Statistik für andere Operationen generiert werden, bei denen keine Einschränkung beteiligt ist. Speziell ist in Fig. 9 ein Prozess 340 zum Generieren von JOIN-Fanout-Statistiken für eine JOIN-Operation mit zwei Relationen dargestellt. Diese Statistiken geben an, wieviele Tupel bei der Ausführung der JOIN-Operation erzeugt werden. Solche Statistiken können zur Optimierung der Ausführung einer JOIN-Operation verwendet werden. Zum Beispiel wenn eine mehrfache JOIN-Operation vom Benutzer angefordert wird, beispielsweise wenn eine erste Relation nach einem bestimmten Attribut mit einer zweiten Relation verknüpft werden soll und dann die zweite Relation nach einem bestimmten Attribut mit einer dritten Relation verknüpft werden soll, ist es von Vorteil, den JOIN-Fanout, d. h. die Anzahl der Zwischenergebnisse, die bei der Verknüpfung der ersten und zweiten Relation entstehen, im Vergleich zu dem JOIN-Fanout bei der Verknüpfung der zweiten und dritten Relation zu kennen. Wie bereits erwähnt ist es bei der Verarbeitung einer zusammengesetzten SQL-Abfrage allgemein ausgedrückt am effizientesten, zuerst die Teile der Abfrage auszuführen, die als Ergebnis die wenigsten Tupel liefert, da auf diese Weise die Anzahl der Zwischenergebnisse, die erzeugt, gespeichert und in nachfolgenden Teilen der Abfrage verarbeitet werden müssen, minimiert wird. Demnach kann eine JOIN-Fanout-Statistik, die die Anzahl der bei der JOIN- Verknüpfung zweier bestimmter Relationen nach einem bestimmten Attribut entstehen, bei der Festlegung der richtigen Art und Weise der Verarbeitung der JOIN- und anderer damit zusammenhängender Operationen in einer zusammengesetzten SQL-Abfrage sein.

Um Tensordarstellungen zur Berechnung einer JOIN-Fanout- Statistik für eine JOIN-Verknüpfung der durch die Tensoren T1 und T2 dargestellten Relationen nach einem angegebenen Attribut zu verwenden, wird in einem ersten Schritt 342 festgestellt, ob die Tensoren T1 und T2 beide Ordnungen enthalten, die dem JOIN-Attribut entsprechen. Wenn dies nicht der Fall ist, können T1 und T2 nicht mit JOIN verknüpft werden, und es wird eine Fehlermeldung ausgegeben (Schritt 344). Wenn T1 und T2 die erforderliche Ordnung besitzen, wird eine Folge von Schritten ausgeführt, um T1 und T2 entlang aller anderen Ordnungen zu kontrahieren. Speziell wird in Schritt 346 festgestellt, ob T1 Ordnungen außer der JOIN-Ordnung besitzt. Wenn dies der Fall ist, wird in Schritt 348 eine der anderen Ordnungen ausgewählt, und in Schritt 350 wird die im Zusammenhang mit Fig. 6 beschriebene Kontraktionsoperation verwendet, um T1 entlang der ausgewählten Ordnung zu kontrahieren. Dann kehrt die Verarbeitung zu Schritt 346 zurück, um festzustellen, ob noch weitere Ordnungen zu kontrahieren sind. Dieser Prozess wird fortgesetzt, bis T1 auf einen Tensor der Ordnung 1 kontrahiert worden ist, der die Ordnung besitzt, nach der die JOIN-Operation ausgeführt werden soll. Nun wird das gleiche mit Tensor T2 durchgeführt. Speziell wird in Schritt 352 festgestellt, ob T2 Ordnungen außer der JOIN-Ordnung besitzt. Wenn dies der Fall ist, wird in Schritt 354 eine der anderen Ordnungen ausgewählt, und in Schritt 356 wird die im Zusammenhang mit Fig. 6 beschriebene Kontraktionsoperation verwendet, um T2 entlang der ausgewählten Ordnung zu kontrahieren. Dann kehrt die Verarbeitung zu Schritt 352 zurück, um festzustellen, ob noch weitere Ordnungen zu kontrahieren sind. Dieser Prozess wird fortgesetzt, bis T2 ebenfalls auf einen Tensor der Ordnung 1 kontrahiert worden ist, der die Ordnung besitzt, nach der die JOIN-Operation ausgeführt werden soll.

Die kontrahierten Versionen von T1 und T2 sind dann zur Verwendung bei der Berechnung der JOIN-Fanout-Statistik bereit. Die zum Generieren dieser Statistik verwendete Operation weist Gemeinsamkeiten mit einem inneren Produkt zweier Vektoren auf. Bei einem inneren Produkt werden einander entsprechende Komponenten zweier Vektoren multipliziert und die Produkte zu einem Skalarwert aufsummiert. Im Kontext von zwei Tensoren T1 der Ordnung 1 wäre dies eine vollständige Beschreibung der Schritte zur Berechnung eines JOIN-Fanout, sofern die Tensoren die gleichen Domänen entlang ihrer gemeinsamen Ordnung haben sollen und entlang dieser Ordnung die gleiche Koordinatenanordnung haben sollen. In einem verallgemeinerten Fall kann es aber sein, dass dies nicht zutrifft. Deshalb werden die Operationen, die zum Berechnen der JOIN-Fanout-Statistik für die beiden Tensoren erforderlich sind, hier unabhängig von der Domäne und der Anordnung dieser Domäne in den beiden Tensoren beschrieben.

In einem ersten Schritt 358 wird die JOIN-Fanout-Statistik auf den Wert 0 initialisiert. Dann wird in Schritt 360 eine Koordinate von T1 in der JOIN-Ordnung ausgewählt, und in Schritt 362 wird festgestellt, ob T2 eine passende Koordinate in der JOIN-Ordnung besitzt. Wenn dies der Fall ist, werden in Schritt 364 die numerischen Werte an diesen Koordinaten multipliziert, und das Produkt wird zum aktuellen Wert der JOIN-Fanout-Statistik addiert. Anschließend, oder direkt nach Schritt 362, wenn es keine passende Koordinate in T2 gibt, wird in Schritt 366 festgestellt, ob es Koordinaten von T1 gibt, die noch nicht ausgewählt worden sind. Wenn dies der Fallist, kehrt die Verarbeitung zu Schritt 366 zurück, um diese zusätzlichen Koordinaten auszuwählen. Nachdem alle Koordinaten von T1 ausgewählt und verarbeitet worden sind, geht die Verarbeitung mit Schritt 366 bis Schritt 368 weiter, wo die Koordinaten von T2 verarbeitet werden.

In Schritt 368 wird festgestellt, ob es Koordinaten von T2 gibt, die noch nicht ausgewählt worden sind. Wenn dies der Fall ist, wird die Verarbeitung mit Schritt 370 fortgesetzt, wo eine Koordinate von T2 in der JOIN-Ordnung ausgewählt wird. Dann wird in Schritt 372 festgestellt, ob T1 eine passende Ordnung außer der JOIN-Ordnung besitzt. Wenn dies der Fall ist, werden in Schritt 374 die numerischen Werte an diesen Koordinaten multipliziert, und das Produkt wird zum aktuellen Wert der JOIN-Fanout-Statistik addiert.

Anschließend, oder direkt nach Schritt 372, falls es in T1 keine passende Koordinate gibt, wird in Schritt 368 wieder festgestellt, ob alle Koordinaten von T2 ausgewählt und verarbeitet worden sind. Nachdem alle Koordinaten von T2 ausgewählt und verarbeitet worden sind, wird die Verarbeitung mit Schritt 376 fortgesetzt, und die berechnete JOIN-Fanout-Statistik wird ausgegeben und kann jetzt bei der Entscheidung darüber, wie die JOIN-Operation ausgeführt werden soll, verwendet werden.

Die Erfindung in ihren weiter gefassten Aspekten ist nicht auf die spezifischen Details, die repräsentative Vorrichtung und das repräsentative Verfahren sowie das dargestellte und beschriebene Beispiel beschränkt. Abweichungen von solchen Details sind deshalb möglich, ohne dass dies eine Abweichung vom Geist oder Umfang des allgemeinen erfindungsgemäßen Konzept des Anmelders darstellt.

Claims (57)

1. Ein Verfahren zur Durchführung einer Abfrage mit einem Kriterium in einem relationalen Datenbanksystem, umfassend:
die Speicherung einer Relation, die mehrere über mehrere Attribute gebildete Tupel umfasst, in einem relationalen Tensor mit mehreren Ordnungen, wobei die Ordnungen des relationalen Tensors einzelnen Attributen entsprechen, und Koordinaten entlang einer Ordnung des relationalen Tensors Werten der betreffenden Attribute entsprechen, und numerische Werte an Koordinatenpositionen indem relationalen Tensor eine Zählung der Tupel in der Relation, die die Attributwerte besitzen, die den Koordinaten des numerischen Wertes entlang den Ordnungen des relationalen Tensors entsprechen, darstellen,
Verarbeiten des relationalen Tensors mit mehreren Ordnungen, um eine Statistik zu dem Kriterium in der Benutzeranfrage zu generieren, und
Ausführen der Abfrage im Speicher eines Computersystems, wobei der relationale Tensor verwendet wird, um aus zwei möglichen Ansätzen anhand der Statistik denjenigen auszuwählen, der bei der Verarbeitung der Abfrage verwendet werden soll.

2. Das Verfahren nach Anspruch 1, wobei die Statistik für die Benutzerabfrage generiert wird, indem numerische Werte an Koordinatenpositionen, die ein Kriterium in der Benutzeranfrage erfüllen, aufsummiert werden.

3. Das Verfahren nach Anspruch 1, wobei die Abfrage die Löschung von Tupeln, die das Kriterium erfüllen, aus der Relation anfordert und die Durchführung basierend auf der Statistik entweder (a.) das Löschen eines Tupels aus der Relation in Abhängigkeit davon, ob das Tupel das Einschränkungskriterium erfüllt, oder (b.) den Transfer eines Tupels in eine Ersatzrelation in Abhängigkeit davon, ob das Tupel das Einschränkungskriterium erfüllt, beinhaltet.

4. Das Verfahren nach Anspruch 1, wobei die Abfrage die Einfügung von Tupeln, die das Einschränkungskriterium erfüllen, in eine zweite Relation anfordert und die Ausführung der Abfrage basierend auf der Statistik entweder (a.) das Durchsuchen der Relation nach Tupeln, die das Einschränkungskriterium erfüllen und das Hinzufügen dieser Tupel zur zweiten Relation oder (b.) das Duplizieren der Relation und das Löschen der Tupel, die das Einschränkungskriterium nicht erfüllen, und das anschließende Mischen des Duplikats mit der zweiten Relation beinhaltet.

5. Das Verfahren nach Anspruch 1, wobei die Abfrage die Aktualisierung von Tupeln, die das Einschränkungskriterium erfüllen, in der Relation anfordert und die Ausführung der Abfrage basierend auf der Statistik entweder (a.) die Neuerstellung der Relation durch Transfer der Tupel, die das Einschränkungskriterium nicht erfüllen, in eine neue Version der Relation und die anschließende Aktualisierung des Rests, oder (b.) die direkte Aktualisierung der Tupel in der Relation, die das Einschränkungskritierium erfüllen, beinhaltet.

6. Das Verfahren nach Anspruch 1, wobei die Abfrage eine JOIN-Operation anhand von Attributen von zwei Relationen anfordert, wobei die erste und die zweite Relation als erster und zweiter relationaler Tensor mit mehreren Ordnungen dargestellt wird, und die Generierung der Statistik folgenden Schritt umfasst: Bilden von intermediären relationalen Tensoren aus dem ersten und dem zweiten relationalen Tensor und Aufsummieren der Produkte der numerischen Werte in entsprechenden Koordinaten in den intermediären Tensoren.

7. Das Verfahren nach Anspruch 1, wobei die Abfrage mehrere JOIN-Operationen angibt, und außerdem Statistiken für die mehrfachen JOIN-Operationen generiert werden, wobei die Ausführung der Abfrage basierend auf der Statistik für die mehreren JOIN-Operationen die Ermittlung einer Ordnung, in der die JOIN-Operationen ausgeführt werden, und die Ausführung der JOIN-Operationen in dieser Ordnung beinhaltet.

8. Das Verfahren nach Anspruch 1, wobei die Abfrage eine Einschränkungsabfrage mit einem Kriterium umfasst.

9. Das Verfahren nach Anspruch 8, wobei die Abfrage eine Abfrage mit Operationen aus der Gruppe von SQL- Operationen, zu der DISTINCT, PROJECTION, EQUALS, LESS THAN, LESS THAN OR EQUAL, GREATER THAN, GREATER THAN OR EQUAL und LIKE zählen, beinhaltet.

10. Das Verfahren nach Anspruch 8, wobei das Generieren der Statistik folgende Schritte umfasst:
Bilden eines relationalen Auswahltensors, der das Kriterium der Einschränkungsabfrage darstellt, und
Bilden eines relationalen Tensorprodukts aus dem relationalen Auswahltensor und dem relationalen Tensor mit mehreren Ordnungen, in dem die Relation gespeichert ist, und
Umwandeln des relationalen Tensorprodukts in einen Skalarwert.

11. Das Verfahren nach Anspruch 10, wobei die Bildung eines relationalen Auswahltensors die Bildung des relationalen Auswahltensors aus einer Mehrzahl von Kriterien, die aus dem Kriterium der Einschränkungsabfrage abgeleitet sind, beinhaltet.

12. Das Verfahren nach Anspruch 11, wobei die Bildung des relationalen Auswahltensors folgende Schritte umfasst:
Bilden eines intermediären relationalen Auswahltensors, der jedes der mehreren Kriterien repräsentiert, und
Bilden eines relationalen Tensorprodukts aus den intermediären relationalen Auswahltensoren, um den relationalen Auswahltensor zu bilden, der die Mehrzahl von Kriterien, die aus dem Kriterium der Einschränkungsanforderung abgeleitet sind, repräsentiert.

13. Das Verfahren nach Anspruch 10, wobei der relationale Auswahltensor ein relationaler Tensor ist, der Ordnungen besitzt, die mit Ordnungen im relationalen Tensor mit mehreren Ordnungen, der die Relation speichert, kompatibel sind und nur die numerischen Werte eins oder null enthält.

14. Das Verfahren nach Anspruch 13, wobei der relationale Auswahltensor an den Koordinaten, die Tupelwerten entsprechen, welche das Kritierium in der Benutzeranfrage erfüllen, den numerischen Wert eins und an den Koordinaten, die Tupelwerten entsprechen, welche das Kriterium in der Benutzeranfrage nicht erfüllen, den numerischen Wert null enthält.

15. Das Verfahren nach Anspruch 10, wobei das relationale Tensorprodukt aus zwei relationalen Tensoren, gebildet wird, indem numerische Werte in entsprechenden Koordinaten der relationalen Tensoren multipliziert werden, um numerische Werte zu für diese Koordinate in einem resultierenden relationalen Tensor zu erzeugen.

16. Das Verfahren nach Anspruch 15, wobei die relationalen Tensoren, aus denen das relationale Tensorprodukt gebildet wird, in der Domäne der Koordinaten der relationalen Tensoren entlang jeder ihrer Ordnungen keine vollständige Übereinstimmung aufweisen und wobei die Bildung des relationalen Tensorprodukts außerdem die Bearbeitung relationaler Tensoren mit nicht übereinstimmenden Domänen beinhaltet.

17. Das Verfahren nach Anspruch 10, wobei Ordnungen des relationalen Auswahltensors so expandiert werden, dass sie denen des relationalen Tensors mit mehreren Ordnungen entsprechen, indem dem relationalen Auswahltensor eine benötigte Ordnung hinzugefügt und jedem Koordinatenwert in der hinzugefügten Ordnung ein Duplikat der vorhandenen Ordnungen des relationalen Auswahltensors zugeordnet wird.

18. Das Verfahren nach Anspruch 17, wobei die Domänen von Koordinaten entlang der Ordnungen des relationalen Auswahltensors mit den Domänen von Koordinaten entlang der Ordnungen des relationalen Tensors mit mehreren Ordnungen abgeglichen werden, indem Koordinaten in einer Ordnung des relationalen Tensors, die in der entsprechenden Ordnung des relationalen Tensors mit mehreren Ordnungen nicht gefunden werden, identifiziert und zu der Ordnung des zweiten relationalen Tensors hinzugefügt werden.

19. Das Verfahren nach Anspruch 18, wobei an alle Positionen des relationalen Auswahltensors, die hinzugefügten Koordinaten entsprechen, der Wert null geschrieben wird.

20. Das Verfahren nach Anspruch 10, wobei die Domänen von Koordinaten entlang der Ordnungen des relationalen Tensors mit mehreren Ordnungen mit den Domänen von Koordinaten entlang der Ordnungen des relationalen Auswahltensors abgeglichen werden, indem Koordinaten in einer Ordnung des relationalen Tensors mit mehreren Ordnungen, die in der entsprechenden Ordnung des relationalen Auswahltensors nicht gefunden werden, identifiziert und zu der Ordnung des relationalen Auswahltensors hinzugefügt werden.

21. Das Verfahren nach Anspruch 10, so angepasst, dass Statistiken für eine Einschränkungsoperation gebildet werden, in der nur die Ausgabe eindeutiger Werte in einem oder mehreren bestimmten Attributen von Tupeln, die einer Abfrage entsprechen, angefordert wird, außerdem umfassend die Normalisierung eines Ergebnisses des Tensorprodukts, indem alle von null verschiedenen Werte in allen Positionen des Ergebnisses durch den Wert eins ersetzt werden.

22. Das Verfahren nach Anspruch 1, wobei die Abfrage die SQL-Operation SELECT DISTINCT beinhaltet.

23. Das Verfahren nach Anspruch 1, wobei die Abfrage die SQL-Operation SELECT LIKE beinhaltet.

24. Das Verfahren nach Anspruch 10, so angepasst, dass eine Einschränkungsoperation, in der nur die Ausgabe eines oder mehrerer Attribute von Tupeln, die einer Abfrage entsprechen, angefordert wird, außerdem umfassend Kontrahieren eines Ergebnisses des Tensorprodukts entlang aller Ordnungen außer derjenigen, die den auszugebenden Attributen entspricht.

25. Das Verfahren nach Anspruch 24, wobei die Abfrage die SQL-Operation PROJECTION beinhaltet.

26. Das Verfahren nach Anspruch 10, wobei das Umwandeln des relationalen Tensorprodukts in einen Skalarwert die Kontraktion des relationalen Tensorprodukts entlang einer eliminierten Ordnung durch Erzeugung eines resultierenden relationalen Tensors, der die eliminierte Ordnung nicht besitzt, und Speicherung der Werte im resultierenden relationalen Tensor, die mit der Summe der Werte entlang der eliminierten Ordnung an den gleichen Koordinaten identisch sind, beinhaltet.

27. Das Verfahren nach Anspruch 26, wobei die Konvertierung des relationalen Tensorprodukts in einen Skalarwert die Kontraktion des relationalen Tensorprodukts entlang jeder seiner Ordnungen beinhaltet, bis nach der letzten Kontraktion ein einziger Skalarwert erzeugt wird, der die Summe aller Werte an allen Koordinaten im relationalen Tensorprodukt repräsentiert.

28. Eine Vorrichtung zur Durchführung einer Abfrage mit einem Kriterium in einem relationalen Datenbanksystem, umfassend:
einen Computer mit einem Hauptspeicher und einer daran angeschlossenen Datenspeichervorrichtung, wobei die Datenspeichervorrichtung eine relationale Datenbank speichert, die eine oder mehrere Relationen umfasst, von denen jede ein oder mehrere Tupel über ein oder mehrere Attribute umfasst,
wobei die relationale Datenbank einen relationalen Tensor mit mehreren Ordnungen enthält, wobei die Ordnungen des relationalen Tensors einzelnen Attributen entsprechen, und Koordinaten entlang einer Ordnung des relationalen Tensors Werten der betreffenden Attribute entsprechen, und numerische Werte an Koordinatenpositionen in dem relationalen Tensor eine Zählung der Tupel in der Relation, die die Attributwerte besitzen, die den Koordinaten des numerischen Wertes entlang den Ordnungen des relationalen Tensors entsprechen, darstellen,
einen Prozessor, der den relationalen Tensor mit mehreren Ordnungen verarbeitet, um eine Statistik über das Kriterium in der Benutzeranfrage zu generieren und die Abfrage im Hauptspeicher eines Computersystems mit Hilfe des relationalen Tensors ausführt, indem in Abhängigkeit von der Statistik aus zwei möglichen Ansätzen einer ausgewählt wird, der bei der Verarbeitung der Abfrage verwendet werden soll.

29. Die Vorrichtung nach Anspruch 28, wobei die Statistik für die Benutzerabfrage generiert wird, indem numerische Werte an Koordinatenpositionen, die ein Kriterium in der Benutzeranfrage erfüllen, aufsummiert werden.

30. Die Vorrichtung nach Anspruch 28, wobei die Abfrage die Löschung von Tupeln, die das Kriterium erfüllen, aus der Relation anfordert und die Durchführung basierend auf der Statistik entweder (a.) das Löschen eines Tupels aus der Relation in Abhängigkeit davon, ob das Tupel das Einschränkungskriterium erfüllt, oder (b.) den Transfer eines Tupels in eine Ersatzrelation in Abhängigkeit davon, ob das Tupel das Einschränkungskriterium erfüllt, beinhaltet.

31. Die Vorrichtung nach Anspruch 28, wobei die Abfrage die Einfügung von Tupeln, die das Einschränkungskriterium erfüllen, in eine zweite Relation anfordert und die Ausführung der Abfrage entweder (a.) das Durchsuchen der Relation nach Tupeln, die das Einschränkungskriterium erfüllen und das Hinzufügen dieser Tupel zur zweiten Relation oder (b.) das Duplizieren der Relation und das Löschen der Tupel, die das Einschränkungskriterium nicht erfüllen, und das anschließende Mischen des Duplikats mit der zweiten Relation beinhaltet.

32. Die Vorrichtung nach Anspruch 28, wobei die Abfrage die Aktualisierung von Tupeln, die das Einschränkungskriterium erfüllen, in der Relation anfordert und die Ausführung der Abfrage basierend auf der Statistik entweder (a.) die Neuerstellung der Relation durch Transfer der Tupel, die das Einschränkungskriterium nicht erfüllen, in eine neue Version der Relation und die anschließende Aktualisierung des Rests, oder (b.) die direkte Aktualisierung der Tupel in der Relation, die das Einschränkungskritierium erfüllen, beinhaltet.

33. Die Vorrichtung nach Anspruch 28, wobei die Abfrage eine JOIN-Operation anhand von Attributen von zwei Relationen anfordert, wobei die erste und die zweite Relation als erster und zweiter relationaler Tensor mit mehreren Ordnungen dargestellt wird, und die Generierung der Statistik folgenden Schritt umfasst: Bilden von intermediären relationalen Tensoren aus dem ersten und dem zweiten relationalen Tensor und Aufsummieren der Produkte der numerischen Werte in entsprechenden Koordinaten in den intermediären Tensoren.

34. Die Vorrichtung nach Anspruch 28, wobei die Abfrage mehrere JOIN-Operationen angibt, und außerdem Statistiken für die mehrfachen JOIN-Operationen generiert werden, wobei die Ausführung der Abfrage basierend auf der Statistik für die mehreren JOIN-Operationen die Ermittlung einer Ordnung, in der die JOIN-Operationen ausgeführt werden, und die Ausführung der JOIN-Operationen in dieser Ordnung beinhaltet.

35. Die Vorrichtung nach Anspruch 28, wobei die Abfrage eine Einschränkungsabfrage mit einem Kriterium umfasst.

36. Die Vorrichtung nach Anspruch 35, wobei die Abfrage eine Abfrage mit Operationen aus der Gruppe von SQL- Operationen, zu der DISTINCT, PROJECTION, EQUALS, LESS THAN, LESS THAN OR EQUAL, GREATER THAN, GREATER THAN OR EQUAL und LIKE zählen, beinhaltet.

37. Die Vorrichtung nach Anspruch 35, wobei das Generieren der Statistik folgende Schritte umfasst:
Bilden eines relationalen Auswahltensors, der das Kriterium der Einschränkungsabfrage darstellt, und
Bilden eines relationalen Tensorprodukts aus dem relationalen Auswahltensor und dem relationalen Tensor mit mehreren Ordnungen, in dem die Relation gespeichert ist, und
Umwandeln des relationalen Tensorprodukts in einen Skalarwert.

38. Die Vorrichtung nach Anspruch 37, wobei die Bildung eines relationalen Auswahltensors die Bildung des relationalen Auswahltensors aus einer Mehrzahl von Kriterien, die aus dem Kriterium der Einschränkungsabfrage abgeleitet sind, beinhaltet.

39. Die Vorrichtung nach Anspruch 38, wobei die Bildung des relationalen Auswahltensors folgende Schritte umfasst:
Bilden eines intermediären relationalen Auswahltensors, der jedes der mehreren Kriterien repräsentiert, und
Bilden eines relationalen Tensorprodukts aus den intermediären relationalen Auswahltensoren, um den relationalen Auswahltensor zu bilden, der die Mehrzahl von Kriterien, die aus dem Kriterium der Einschränkungsanforderung abgeleitet sind, repräsentiert.

40. Die Vorrichtung nach Anspruch 37, wobei der relationale Auswahltensor ein relationaler Tensor ist, der Ordnungen besitzt, die mit Ordnungen im relationalen Tensor mit mehreren Ordnungen, der die Relation speichert, kompatibel sind und nur die numerischen Werte eins oder null enthält.

41. Die Vorrichtung nach Anspruch 40, wobei der relationale Auswahltensor an den Koordinaten, die Tupelwerten entsprechen, welche das Kritierium in der Benutzeranfrage erfüllen, den numerischen Wert eins und an den Koordinaten, die Tupelwerten entsprechen, welche das Kriterium in der Benutzeranfrage nicht erfüllen, den numerischen Wert null enthält.

42. Die Vorrichtung nach Anspruch 37, wobei das relationale Tensorprodukt aus zwei relationalen Tensoren, gebildet wird, indem numerische Werte in entsprechenden Koordinaten der relationalen Tensoren multipliziert werden, um numerische Werte zu für diese Koordinate in einem resultierenden relationalen Tensor zu erzeugen.

43. Die Vorrichtung nach Anspruch 42, wobei die relationalen Tensoren, aus denen das relationale Tensorprodukt gebildet wird, in der Domäne der Koordinaten der relationalen Tensoren entlang jeder ihrer Ordnungen keine vollständige Übereinstimmung aufweisen und wobei die Bildung des relationalen Tensorprodukts außerdem die Bearbeitung relationaler Tensoren mit nicht übereinstimmenden Domänen beinhaltet.

44. Die Vorrichtung nach Anspruch 37, wobei Ordnungen des relationalen Auswahltensors so expandiert werden, dass sie denen des relationalen Tensors mit mehreren Ordnungen entsprechen, indem dem relationalen Auswahltensor eine benötigte Ordnung hinzugefügt und jedem Koordinatenwert in der hinzugefügten Ordnung ein Duplikat der vorhandenen Ordnungen des relationalen Auswahltensors zugeordnet wird.

45. Die Vorrichtung nach Anspruch 44, wobei die Domänen von Koordinaten entlang der Ordnungen des relationalen Auswahltensors mit den Domänen von Koordinaten entlang der Ordnungen des relationalen Tensors mit mehreren Ordnungen abgeglichen werden, indem Koordinaten in einer Ordnung des relationalen Tensors, die in der entsprechenden Ordnung des relationalen Tensors mit mehreren Ordnungen nicht gefunden werden, identifiziert und zu der Ordnung des zweiten relationalen Tensors hinzugefügt werden.

46. Die Vorrichtung nach Anspruch 45, wobei an alle Positionen des relationalen Auswahltensors, die hinzugefügten Koordinaten entsprechen, der Wert null geschrieben wird.

47. Die Vorrichtung nach Anspruch 37, wobei die Domänen von Koordinaten entlang der Ordnungen des relationalen Tensors mit mehreren Ordnungen mit den Domänen von Koordinaten entlang der Ordnungen des relationalen Auswahltensors abgeglichen werden, indem Koordinaten in einer Ordnung des relationalen Tensors mit mehreren Ordnungen, die in der entsprechenden Ordnung des relationalen Auswahltensors nicht gefunden werden, identifiziert und zu der Ordnung des relationalen Auswahltensors hinzugefügt werden.

48. Die Vorrichtung nach Anspruch 37, wobei eine Einschränkungsoperation ausgeführt wird, die die Ausgabe nur eindeutiger Werte in einem oder mehreren bestimmten Attributen von Tupeln, die einer Abfrage entsprechen, anfordert, wobei der Prozessor ein Ergebnis des Tensorprodukts normalisiert, indem alle von null verschiedenen Werte an allen Positionen des Ergebnisses durch den Wert eins ersetzt werden.

49. Die Vorrichtung nach Anspruch 28, wobei die Abfrage die SQL-Operation SELECT DISTINCT beinhaltet.

50. Die Vorrichtung nach Anspruch 28, wobei die Abfrage die SQL-Operation SELECT LIKE beinhaltet.

51. Die Vorrichtung nach Anspruch 37, wobei eine Einschränkungsoperation ausgeführt wird, in der nur eines oder mehrere Attribute von Tupeln, die eine Abfrage erfüllen, angefordert wird, wobei der Prozessor ein Ergebnis des Tensorprodukts entlang allen Ordnungen außer derjenigen, die den auszugebenden Attributen entspricht, kontrahiert wird.

52. Die Vorrichtung nach Anspruch 51, wobei die Abfrage die SQL-Operation PROJECTION beinhaltet.

53. Die Vorrichtung nach Anspruch 37, wobei das Umwandeln des relationalen Tensorprodukts in einen Skalarwert die Kontraktion des relationalen Tensorprodukts entlang einer eliminierten Ordnung durch Erzeugung eines resultierenden relationalen Tensors, der die eliminierte Ordnung nicht besitzt, und Speicherung der Werte im resultierenden relationalen Tensor, die mit der Summe der Werte entlang der eliminierten Ordnung an den gleichen Koordinaten identisch sind, beinhaltet.

54. Die Vorrichtung nach Anspruch 53, wobei die Konvertierung des relationalen Tensorprodukts in einen Skalarwert die Kontraktion des relationalen Tensorprodukts entlang jeder seiner Ordnungen beinhaltet, bis nach der letzten Kontraktion ein einziger Skalarwert erzeugt wird, der die Summe aller Werte an allen Koordinaten im relationalen Tensorprodukt repräsentiert.

55. Ein Programmprodukt umfassend:
eine relationale Datenbank, die eine oder mehrere Relationen umfasst, wobei jede Relation ein oder mehrere Tupel über ein oder mehrere Attribute umfasst, und die relationale Datenbank einen relationalen Tensor mit mehreren Ordnungen enthält, wobei Ordnungen des relationalen Tensors einzelnen Attributen und Koordinaten entlang einer Ordnung des relationalen Tensors Werten des entsprechenden Attributs entsprechen, und wobei numerische Werte an Koordinatenpositionen im relationalen Tensor eine Zählung der Tupel in einer Relation, die den Attributwert besitzen, der den Koordinaten des numerischen Wertes entlang der Ordnungen des relationalen Tensors entspricht, repräsentieren,
ein relationales Datenbanksystem, das daran angepasst ist, den relationalen Tensor mit mehreren Ordnungen zu verarbeiten, um im Hauptspeicher eines Computersystems mit Hilfe des relationalen Tensors eine Statistik über das Kriterium in der Benutzeranfrage zu generieren, indem in Abhängigkeit von der Statistik aus zwei möglichen Ansätzen einer ausgewählt wird, der bei der Verarbeitung der Abfrage verwendet werden soll, und
ein Signalträgermedium, das den relationalen Tensor und das relationale Datenbanksystem enthält.

56. Das Programmprodukt nach Anspruch 55, wobei das Signalträgermedium Übertragungsmedien umfasst.

57. Das Programmprodukt nach Anspruch 55, wobei das Signalträgermedium Aufzeichnungsmedien umfasst.