DE10056763A1 - Generieren von Einschränkungsabfragen mit Hilfe von Tensordarstellungen - Google Patents
Generieren von Einschränkungsabfragen mit Hilfe von TensordarstellungenInfo
- Publication number
- DE10056763A1 DE10056763A1 DE10056763A DE10056763A DE10056763A1 DE 10056763 A1 DE10056763 A1 DE 10056763A1 DE 10056763 A DE10056763 A DE 10056763A DE 10056763 A DE10056763 A DE 10056763A DE 10056763 A1 DE10056763 A1 DE 10056763A1
- Authority
- DE
- Germany
- Prior art keywords
- tensor
- relational
- orders
- coordinates
- selection
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2452—Query translation
- G06F16/24528—Standardisation; Simplification
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99932—Access augmentation or optimizing
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99933—Query processing, i.e. searching
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
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,737 mit dem Titel GENERATING
STATISTICS QUERIES USING TENSOR REPRESENTATIONS, die
gleichzeitig mit der vorliegenden Anmeldung (RO997-093) von
Lance Amundsen et al. eingereicht wird und in ihrer
Gesamtheit durch Bezugnahme in die vorliegende Anmeldung
einverleibt wird.
Die vorliegende Erfindung betrifft die Generierung von
Statistiken bei der Verwaltung und Ausführung von Abfragen in
relationalen Datenbanken.
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 Bespiel
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)
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, mit dem
Unterschied, dass hier nur ein einziger Index benötigt wird,
um alle in der Spalte vorkommenden Werte zu erfassen
(gleichgültig, ob diese Werten nun "45246", "45202" oder
anders lauten). 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:
Extrahiert angegebene Tupel aus einer
angegebenen Relation (d. h. ruft Zeilen aus
einer Tabelle ab) unter Verwendung einer
angegebenen Bedingung;
Extrahiert angegebene Attribute einer
angegebenen Relation (d. h. ruft angegebene
Spalten aus einer Tabelle ab);
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);
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 erscheint);
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);
Erzeugt eine Relation (Tabelle), die als allen
Tupeln (Zeilen) besteht, die in der ersten,
aber nicht in der zweiten der angegebenen
Relationen (Tabellen) erscheinen;
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;
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
Populationstabelle, in der Einwohner von Städten
identifiziert werden, und diese Populationstabelle 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.
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 Benutzerabfrage 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.
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.
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.
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 aufzeige.
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 Mehrpunktbusses 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 Benutzerabfrage 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 Benutzerabfrage 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 Benutzerabfrage 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 Speicher 120 im weitesten Sinne zu verstehen ist
und dynamischen RAM (DRAM), statischen RAM (SRAM), Flash-
Speicher, 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
Benutzerabfrage 129 erstellen. Die Benutzerabfrage 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
Benutzerabfrage 129 zu erstellen, die dann typischerweise der
folgenden Vorverarbeitung-Verarbeitung durch das relationale
Datenbanksystem 123 unterzogen wird. Die Benutzerabfrage 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 Benutzerabfrage 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
Benutzerabfrage 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
Benutzerabfrage 129 zu steigern, indem entweder Statistiken
für die Benutzerabfrage 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, mm" 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. Inder 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 den 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 intermediä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 der Ordnung n 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 der Ordnung n-1 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 der Ordnung n ausgewählt
werden, wobei die Vektoren entlang der eliminierten Ordnung
genommen und die resultierenden Skalarwerte in ein Ergebnis
der Ordnung n-1 an der Koordinate der Ordnung n-1, 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 entspricht 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 Kriterium 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 der Ordnung N 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 der Ordnung N 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
der Ordnung N 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 der ausgewählten Koordinate 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 der Ordnung N 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 ausgewä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 der Ordnung N 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 < (GRÖSSER
ALS), < (KLEINER ALS), < = (GRÖSSER ODER GLEICH) und < =
(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 unterliegende 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
bereits 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 Fallist, 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 Tensors 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 Benutzeranfrage eine
solche PROJECTION-Operation angegeben ist, und wenn dies der
Fallist, werden in den Schritten 190 bis 194 Schritte
unternommen, um den in Schritt 174 erzeugten Tensor so zu
kontrahieren, dass er nur die angeforderten Attribute der
Relation repräsentiert. 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. Und zwar 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, bei
der 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 T1 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 T1 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-Stätistik
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 (42)
1. Ein Verfahren zur Durchführung einer Abfrage 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 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, und
Durchführung der Abfrage im Speicher eines Computersystems mit Hilfe des relationalen Tensors.
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 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, und
Durchführung der Abfrage im Speicher eines Computersystems mit Hilfe des relationalen Tensors.
2. Das Verfahren nach Anspruch 1, wobei die Abfrage eine
Einschränkungsabfrage mit einem Kriterium umfasst.
3. Das Verfahren nach Anspruch 2, 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.
4. Das Verfahren nach Anspruch 2, wobei die Durchführung der
Abfrage die Bildung eines relationalen Auswahltensors, der
das Kriterium der Einschränkungsabfrage repräsentiert, und
die Bildung eines relationalen Tensorprodukts aus dem
relationalen Auswahltensor und dem relationalen Tensor mit
mehreren Ordnungen, der die Relation speichert,
beinhaltet.
5. Das Verfahren nach Anspruch 4, 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.
6. Das Verfahren nach Anspruch 5, wobei die Bildung des
relationalen Auswahltensors folgendes umfasst:
die Bildung eines intermediären relationalen Auswahltensors, der jedes der mehreren Kriterien repräsentiert, beinhaltet, und
die Bildung 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.
die Bildung eines intermediären relationalen Auswahltensors, der jedes der mehreren Kriterien repräsentiert, beinhaltet, und
die Bildung 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.
7. Das Verfahren nach Anspruch 4, 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.
8. Das Verfahren nach Anspruch 7, 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.
9. Das Verfahren nach Anspruch 4, 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.
10. Das Verfahren nach Anspruch 9, 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.
11. Das Verfahren nach Anspruch 4, 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.
12. Das Verfahren nach Anspruch 11, 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.
13. Das Verfahren nach Anspruch 12, wobei an alle Positionen
des relationalen Auswahltensors, die hinzugefügten
Koordinaten entsprechen, der Wert null geschrieben wird.
14. Das Verfahren nach Anspruch 4, 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.
15. Das Verfahren nach Anspruch 4, so angepasst, dass eine
Einschränkungsoperation ausgeführt wird, 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.
16. Das Verfahren nach Anspruch 1, wobei die Abfrage die SQL-
Operation SELECT DISTINCT beinhaltet.
17. Das Verfahren nach Anspruch 1, wobei die Abfrage die SQL-
Operation SELECT LIKE beinhaltet.
18. Das Verfahren nach Anspruch 4, 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
das Kontrahieren eines Ergebnisses des Tensorprodukts
entlang aller Ordnungen außer derjenigen, die den
auszugebenden Attributen entspricht.
19. Das Verfahren nach Anspruch 18, wobei die Abfrage die SQL-
Operation PROJECTION beinhaltet.
20. Eine Vorrichtung zur Durchführung einer Abfrage 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 anhand eines oder mehrerer 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 die Abfrage mit Hilfe des gespeicherten relationalen Tensors im Hauptspeicher des Computers ausführt.
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 anhand eines oder mehrerer 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 die Abfrage mit Hilfe des gespeicherten relationalen Tensors im Hauptspeicher des Computers ausführt.
21. Die Vorrichtung nach Anspruch 20, wobei die Abfrage eine
Einschränkungsabfrage mit einem Kriterium umfasst.
22. Die Vorrichtung nach Anspruch 21, 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.
23. Die Vorrichtung nach Anspruch 21, wobei der Prozessor die
Abfrage durchführt, indem er einen relationalen
Auswahltensor bildet, der das Kriterium der
Einschränkungsabfrage repräsentiert, und ein relationales
Tensorprodukt aus dem relationalen Auswahltensor und dem
relationalen Tensor mit mehreren Ordnungen, der die
Relation speichert, bildet.
24. Die Vorrichtung nach Anspruch 23, 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.
25. Die Vorrichtung nach Anspruch 24, wobei die Bildung des
relationalen Auswahltensors die Bildung eines
intermediären relationalen Auswahltensors, der jedes der
mehreren Kriterien repräsentiert, und
die Bildung 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,
beinhaltet.
26. Die Vorrichtung nach Anspruch 23, 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.
27. Die Vorrichtung nach Anspruch 26, 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.
28. Die Vorrichtung nach Anspruch 23, 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.
29. Die Vorrichtung nach Anspruch 28, 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.
30. Die Vorrichtung nach Anspruch 23, 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.
31. Die Vorrichtung nach Anspruch 30, 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.
32. Die Vorrichtung nach Anspruch 31, wobei an alle Positionen
des relationalen Auswahltensors, die hinzugefügten
Koordinaten entsprechen, der Wert null geschrieben wird.
33. Die Vorrichtung nach Anspruch 23, 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.
34. Die Vorrichtung nach Anspruch 23, 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.
35. Die Vorrichtung nach Anspruch 34, wobei die Abfrage die
SQL-Operation SELECT DISTINCT beinhaltet.
36. Die Vorrichtung nach Anspruch 34, wobei die Abfrage die
SQL-Operation SELECT LIKE beinhaltet.
37. Die Vorrichtung nach Anspruch 20, 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.
38. Die Vorrichtung nach Anspruch 37, wobei die Abfrage, die
SQL-Operation PROJECTION beinhaltet.
40. 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 an das Abrufen von Daten aus der relationalen Datenbank angepasst ist, und
ein Signalträgermedium, das den relationalen Tensor und das relationale Datenbanksystem enthält.
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 an das Abrufen von Daten aus der relationalen Datenbank angepasst ist, und
ein Signalträgermedium, das den relationalen Tensor und das relationale Datenbanksystem enthält.
41. Das Programmprodukt nach Anspruch 40, wobei das
Signalträgermedium Übertragungsmedien umfasst.
42. Das Programmprodukt nach Anspruch 40, wobei das
Signalträgermedium Aufzeichnungsmedien umfasst.
43. Einen Speicher zur Speicherung von Daten für den Zugriff
durch ein relationales Datenbanksystem, wobei das
relationale Datenbanksystem Daten aus einer relationalen
Datenbank abruft, die zumindest zum Teil in diesem
Hauptspeicher gespeichert ist, wobei die relationale
Datenbank eine oder mehrere Relationen umfasst, von denen
jede ein oder mehrere Tupel über ein oder mehrere
Attribute umfasst, und wobei der Hauptspeicher folgendes
umfasst:
einen 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 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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/441,818 | 1999-11-17 | ||
US09/441,818 US6502089B1 (en) | 1999-11-17 | 1999-11-17 | Generating restriction queries using tensor representations |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10056763A1 true DE10056763A1 (de) | 2001-05-31 |
DE10056763B4 DE10056763B4 (de) | 2010-01-21 |
Family
ID=23754415
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10056763A Expired - Fee Related DE10056763B4 (de) | 1999-11-17 | 2000-11-11 | Generieren von Einschränkungsabfragen mit Hilfe von Tensordarstellungen |
Country Status (2)
Country | Link |
---|---|
US (1) | US6502089B1 (de) |
DE (1) | DE10056763B4 (de) |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3940542B2 (ja) * | 2000-03-13 | 2007-07-04 | 株式会社ルネサステクノロジ | データプロセッサ及びデータ処理システム |
US6564204B1 (en) * | 2000-04-14 | 2003-05-13 | International Business Machines Corporation | Generating join queries using tensor representations |
US7051078B1 (en) * | 2000-07-10 | 2006-05-23 | Cisco Technology, Inc. | Hierarchical associative memory-based classification system |
US20020199184A1 (en) * | 2001-05-31 | 2002-12-26 | Cezeaux Thomas Edward | Real-time monitoring and blocking of content |
US6920460B1 (en) * | 2002-05-29 | 2005-07-19 | Oracle International Corporation | Systems and methods for managing partitioned indexes that are created and maintained by user-defined indexing schemes |
US7574447B2 (en) * | 2003-04-08 | 2009-08-11 | United Parcel Service Of America, Inc. | Inbound package tracking systems and methods |
US7143107B1 (en) * | 2003-06-26 | 2006-11-28 | Microsoft Corporation | Reporting engine for data warehouse |
US7321888B2 (en) * | 2003-09-11 | 2008-01-22 | International Business Machines Corporation | Method and system for dynamic join reordering |
US7305404B2 (en) | 2003-10-21 | 2007-12-04 | United Parcel Service Of America, Inc. | Data structure and management system for a superset of relational databases |
US20050267821A1 (en) * | 2004-05-14 | 2005-12-01 | United Parcel Service Of America, Inc. | Address validation mode switch |
WO2006083694A2 (en) * | 2005-01-28 | 2006-08-10 | United Parcel Service Of America, Inc. | Registration and maintenance of address data for each service point in a territory |
US7610397B2 (en) * | 2005-02-28 | 2009-10-27 | International Business Machines Corporation | Method and apparatus for adaptive load shedding |
US7565342B2 (en) * | 2005-09-09 | 2009-07-21 | International Business Machines Corporation | Dynamic semi-join processing with runtime optimization |
US20120005045A1 (en) | 2010-07-01 | 2012-01-05 | Baker Scott T | Comparing items using a displayed diagram |
US8914353B2 (en) * | 2011-12-20 | 2014-12-16 | Sap Se | Many-core algorithms for in-memory column store databases |
US10936569B1 (en) | 2012-05-18 | 2021-03-02 | Reservoir Labs, Inc. | Efficient and scalable computations with sparse tensors |
US10185745B2 (en) | 2017-03-16 | 2019-01-22 | International Business Machines Corporation | Managing a stream computing environment using a projected database object |
US20180268001A1 (en) | 2017-03-16 | 2018-09-20 | International Business Machines Corporation | Managing a database management system using a set of stream computing data |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE69032576T2 (de) * | 1990-02-27 | 1999-04-15 | Oracle Corp | Dynamische Optimierung eines einzelnen relationalen Zugriffs |
US5560007A (en) * | 1993-06-30 | 1996-09-24 | Borland International, Inc. | B-tree key-range bit map index optimization of database queries |
US5706495A (en) | 1996-05-07 | 1998-01-06 | International Business Machines Corporation | Encoded-vector indices for decision support and warehousing |
US5943668A (en) * | 1997-06-30 | 1999-08-24 | International Business Machines Corporation | Relational emulation of a multi-dimensional database |
-
1999
- 1999-11-17 US US09/441,818 patent/US6502089B1/en not_active Expired - Fee Related
-
2000
- 2000-11-11 DE DE10056763A patent/DE10056763B4/de not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
DE10056763B4 (de) | 2010-01-21 |
US6502089B1 (en) | 2002-12-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69910219T2 (de) | Transformation der perspektive auf tabellen von relationalen datenbanken | |
DE10028688B4 (de) | Methode, System und Programm für eine Verbindungsoperation in einer mehrspaltigen Tabelle sowie in Satellitentabellen mit doppelten Werten | |
DE60130475T2 (de) | Durchführung von kalkulationen eines tabellenkalkulationstyps in einem datenbanksystem | |
DE60004385T2 (de) | Verfahren und systeme um olap hierarchien zusammenfassbar zu machen | |
DE10056763A1 (de) | Generieren von Einschränkungsabfragen mit Hilfe von Tensordarstellungen | |
DE60035432T2 (de) | System zur verwaltung der rdbm fragmentierungen | |
DE69615230T2 (de) | Relationales Datenbanksystem und Verfahren mit grosser Verfügbarkeit der Daten bei der Umstrukturierung von Tabellendaten | |
DE69509118T2 (de) | Implementierungsunabhängige erweiterbare abfragearchitektur für systeme zur informationswiederauffindung | |
DE69031028T2 (de) | System zum physikalischen Entwurf von Datenbanken | |
DE69602364T2 (de) | Rechnersystem um semantische objektmodelle von existierenden relationellen datenbanksystemen herzustellen | |
DE69128958T2 (de) | Schneide- und Klebefilterung von unbegrenzten, dynamischen, unmodifizierbaren Datenströmen | |
DE68916486T2 (de) | Verfahren zur Durchführung von Operationen in einem relationalen Datenbankverwaltungssystem. | |
DE68926849T2 (de) | Struktur und Verfahren zur Anordnung rekursiv abgeleiteter Daten in einer Datenbank | |
DE60121231T2 (de) | Datenverarbeitungsverfahren | |
DE69935657T2 (de) | Verfahren und gerät zum optimieren der querygenerierung durch selektives verwenden von zusätzen oder schlüsselwerten | |
DE69329265T2 (de) | Graphischer Datenbankzugriff | |
DE69838158T2 (de) | Auf die Anzahl von in den Tabellen gespeicherten Datensätzen basiertes Ordnen von Verbindungen | |
DE68929132T2 (de) | Datenbankverwaltungssystem und Verfahren hierfür | |
DE3688529T2 (de) | Verfahren zur Auffrischung von Mehrspaltentabellen in einer relationellen Datenbank mit Mindestinformation. | |
DE69227948T2 (de) | Verfahren und Gerät um ein dynamisches Lexikon in ein Textinformationsauffindungssystem zu integrieren | |
DE3856055T2 (de) | Verfahren und Einrichtung, um gleichzeitigen Zugriff zu indizierten sequentiellen Dateien zu ermöglichen | |
DE69510743T2 (de) | Intelligentes Datenarchiv | |
DE60208778T2 (de) | Datenstruktur für informationssysteme | |
DE10103574A1 (de) | Aggregierte Prädikate und Suche in einem Datenbankverwaltungssystem | |
DE69710309T2 (de) | System für betriebliche veröffentlichung und speicherung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8120 | Willingness to grant licences paragraph 23 | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee | ||
R079 | Amendment of ipc main class |
Free format text: PREVIOUS MAIN CLASS: G06F0017300000 Ipc: G06F0016000000 |