DE69935657T2

DE69935657T2 - Verfahren und gerät zum optimieren der querygenerierung durch selektives verwenden von zusätzen oder schlüsselwerten

Info

Publication number: DE69935657T2
Application number: DE69935657T
Authority: DE
Inventors: Piotr Jacek Houston KRYCHNIAK
Original assignee: Computer Associates Think Inc
Current assignee: CA Inc
Priority date: 1998-11-03
Filing date: 1999-11-03
Publication date: 2007-12-13
Anticipated expiration: 2019-11-04
Also published as: CA2325863A1; DE69935657D1; AU2473100A; ZA200003317B; IL137127A; JP2004520633A; EP1049997A1; BR9906714A; AU755859B2; WO2000028439A1; ATE358297T1; EP1049997B1; CN1292125A; IL137127A0; US6192357B1; EP1049997A4

Description

Die vorliegende Erfindung betrifft Abfragen von Daten in einer Datenbank, und konkreter ein Verfahren zum Auswählen geeigneter Abfrageparameter, um eine Abfrage effizient durchzuführen.
Datenbanken speichern Daten üblicherweise in einer oder mehreren Faktentabellen, die Instanzdaten irgendeiner Art darstellen, zusammen mit Dimensionstabellen, die Attribute für Daten in den Faktentabellen definieren. Wie in 1 gezeigt, weisen die Faktentabellen Spalten auf, von denen jede ein Element einer bestimmten Dimension darstellt, die eben dieser Instanz zugeordnet ist, und eine oder mehrere Kennzahlen (Measure)-Spalten, die Daten enthalten, die sich auf diese bestimmte Instanz beziehen. Häufig sind die Kennzahlen Werte, welche auf irgendeine Weise aggregiert werden können, wenn Datensätze in den Faktendaten in Gruppen zusammengefasst sind. Zum Beispiel könnten die Eingaben addiert oder gemittelt werden. Allerdings könnte das nicht der Fall sein, und "Kennzahlendaten" in gewissen Kennzahlenspalten in den Faktentabellen könnten nur ein willkürlicher String oder eine andere Art von Wert sein, welcher nicht aggregiert werden kann. Diese Erfindung funktioniert mit jedem Typ von Faktentabelle, solange sie auf eine oder mehrere Dimensionen mit Attributen bezogen ist.
Dimensionen stellen ein eingegrenztes Set von Einheiten innerhalb einer Klasse dar, jede mit einem oder mehreren Attributen, welche auf eine gemeinsame Art klassifiziert werden können. Eine Dimension wird normalerweise in einer Dimensionstabelle dargestellt, wobei eine oder mehrere Spalten in der Tabelle jede Einheit in der Dimension eindeutig identifizieren, das ist bekannt als der Schlüsselwert oder die Schlüsselwerte. Schlüsselwerte sind häufig willkürliche Bezeichner, welche den Einheiten in der Dimen sion gegeben sind, um sie eindeutig zu identifizieren. Andere Spalten in der Tabelle, darunter möglicherweise eine der Schlüsselspalten, sehen unterschiedliche Attribute für jede der Einheiten vor. Diese Attributwerte können verwendet werden, um die Eingaben in der Dimensionstabelle auf unterschiedlichen Ebenen zu gruppieren, und um Daten aus der Faktentabelle entsprechend ihren Attributen zu extrahieren oder zu aggregieren.
Aus Gründen von Platzeffizienz, und um Redundanz zu vermeiden, die zu Inkonsistenzen in der Datenbank führen könnte, werden nur die Schlüsselwerte für jede Dimension in den Faktendatentabellen gespeichert. Es wäre anzumerken, dass interne Repräsentationen mit einer eins-zu-eins Entsprechung mit den Schlüsselwerten in eben dieser Dimension in den Faktentabellen gespeichert werden könnten, falls das effizienter wäre. Diese würden vom Benutzer nie eingesehen. In einem derartigen Fall kann die interne Repräsentation für die Zwecke dieser Erörterung als der Schlüsselwert betrachtet werden.
Abfragebeispiele werden in dieser Patentanmeldung in der Sprache SQL gebracht, da diese bei weitem die verbreitetste Abfragesprache ist, die heute verwendet wird. Allerdings ist klar, dass die Erfindung, die hier beschrieben ist, auf gleich effiziente Weise mit anderen Abfragesprachen implementiert werden kann.
Wenn eine Abfrage nach den Daten in der Datenbank unter Verwendung der vom Benutzer angeforderten Attributwerte durchgeführt wird, müssen die Dimensionstabellen in der Abfrage beinhaltet sein, wie in dem folgenden Beispiel:
In dieser Art von Abfrage werden die in der Abfrage spezifizierten Tabellen an allen gemeinsamen Feldern in jeder der Tabellen miteinander verknüpft. In dem oben angeführten Beispiel ist das Feld key1 der Tabelle dim1 und der Faktentabelle gemeinsam. Das Feld key2 ist der Tabelle dim2 und der Faktentabelle gemeinsam. Das Feld key3 ist der Tabelle dim3 und der Faktentabelle gemeinsam.
Unter Verwendung einer derartigen Join-Verknüpfung wird eine Eingabe in der Ausgabetabelle für alle Kombinationen von Eingaben in beiden der zwei verknüpften Tabellen erstellt, in welchen das verknüpfte Feld in jeder Tabelle dasselbe ist. Das verknüpfte Feld erscheint nur einmal in der verknüpften Ausgabetabelle. Zum Beispiel ergibt Verknüpfen der zwei Tabellen, die in 2A und 2B gezeigt sind, die Ausgabetabelle, die in 2C gezeigt ist.
Wenn allerdings zuerst ein Abbilden der in jeder Dimension ausgewählten Attributwerte auf die Schlüsselwerte dieser Dimension ausgeführt wird, ist es nicht nötig, die Dimensionstabellen mit den Faktentabellen in der Abfrage zu verknüpfen, da sich alle nötige Information in der Faktentabelle befindet. Zum Beispiel kann die Abfrage wie folgt lauten:
Das wird häufig weitaus effizienter sein als die äquivalente Attributlogikabfrage, abhängig davon, wie die Datenbank mit der Abfrage umgeht, da die Dimensionstabellen nicht in der Abfrage beinhaltet sein müssen. Ferner könnte eine Datenbank-Engine in der Lage sein, mit Schlüsselwerten effizienter umzugehen als mit Attributen, auf Grund verschiedener Optimierungen.
Datenbanken könnten zum Beispiel durch Indizieren der Faktentabelle mit Schlüsselwert in jeder Dimension optimiert werden. Die geeigneten Faktendaten, die in das resultierende Datenset einzuschließen sind, können dann sehr schnell durch Scannen durch die Eingaben nach jedem Schlüssel in dem Index gefunden werden, da die Indices, die einem bestimmten Schlüssel zugeordnet sind, konsekutiv angeordnet sind.
Wenn ein derartiges indexbasiertes Optimierungsschema von der Datenbank verwendet wird, wird die folgende Art von Abfrage häufig vorteilhafter zu verwenden sein, selbst bei Abfragen nach Schlüsselwerten:
Ungeachtet dessen, welche Abfragelogik von üblichen Datenbankabfrage-Tools verwendet wird, verwenden sie alle dieselben Transformationen von der Anforderung in die geeignete SQL-Abfrage, ungeachtet der Anzahl an Eingaben, welche auf Verwenden der ausgewählten Abfragelogik durchsucht werden. Zum Beispiel ergeben, in einigen Situationen, getroffene Auswahlen, besonders auf höheren Ebenen in Dimensionen, eine große Anzahl an Datensätzen von einer Dimensionstabelle, auf welche die Auswahlkriterien zutreffen. Zum Beispiel könnte man nach allen Aktienfonds aller Investmentfonds am Markt fragen. Tatsächlich könnte es hunderte von Dimensionseingaben geben, auf welche das Auswahlkriterium zutrifft. Wenn das Datenbankabfrage-Tool automatisch eingestellt ist, die ausgewählten Dimensions-Attributeingaben in Schlüsselwerte in der Fonds-Dimension zu transformieren, würden die Dimensionen durchsucht, um Schlüsselwerte zu finden, auf die das Auswahlkriterium zutrifft. Eben diese Eingaben würden dann der Abfrage hinzugefügt, unter Verwendung einer "IN"-Liste, wie oben gezeigt. Ein Problem entsteht, wenn die Anzahl der Schlüsselwerte sehr groß wird. Die meisten Datenbanksysteme setzen der Anzahl der Werte in einer einzigen "IN"-Liste eine Grenze, und das Abfrage-Tool muss daher die Abfrage in eine Anzahl an Abfragen teilen, nach welchen die Datenbank durchsucht wird. Ferner könnte es, selbst wenn die Dimensionen nicht indiziert sind, tatsächlich länger dauern, eine Abfrage mit einer signifikanten Anzahl an Schlüsselwerten unter Verwendung nur der Faktentabelle durchzuführen, als die Abfrage unter Verwendung der wenigen abgefragten Attributwerte durchzuführen, und unter Einbringen der Dimensionen in die Abfrage. Zum Beispiel könnte es für eine Datenbank-Engine nahezu gleich schnell sein, einen Attributwert in der zugeordneten Dimensionstabelle aufzusuchen und zu prüfen, um festzustellen, ob er zutrifft, wie es sein könnte, festzustellen, ob ein Schlüsselwert zutrifft. Wenn es signifikant mehr Schlüsselwerte in der äquivalenten Abfrage gibt als die Anzahl an Attributwerten, würde es nahezu mit Sicherheit schneller sein, die Attributwerte in der zugeordneten Dimension aufzusuchen, als alle Schlüsselwerte zu prüfen, um festzustellen, ob einer von ihnen zutrifft.
Es zeigt sich, dass ein Abfrage-Tool erforderlich ist, das zwischen alternativen Abfragestrukturen wählen kann, abhängig von den tatsächlich abgefragten Attributen.
Chaudhuri, S. und Dayal, U., "An Overview of Data Warehousing and OLAP Technology" (SIGMOD Record, Vol. 26, No. 1, Seiten 65 bis 74, März 1997) beschreibt eine Datenbank, die aus einer einzigen Faktentabelle und einer einzigen Tabelle für jede Dimension besteht. Jedes Tupel in der Faktentabelle besteht in einem Zeiger zu jeder der Dimensionen, welche ihre multidimensionalen Koordinaten bereitstellen, und speichert die numerischen Kennzahlen (Measures) jener Koordinaten. Jede Dimensionstabelle besteht aus Spalten, die Attributen der Dimension entsprechen. Chaudhuri et al. beinhaltet eine Übersicht relevanter Literatur zur Transformation komplexer SQL-Abfragen.
KURZDARSTELLUNG DER ERFINDUNG
Gemäß der vorliegenden Erfindung ist Folgendes vorgesehen: Verfahren nach Anspruch 1; Vorrichtung nach Anspruch 6; und ein computerlesbares Medium nach Anspruch 11.
Ein bevorzugtes Beispiel sieht ein Verfahren vor zum Erzeugen von Abfragen aus Datenanforderungen, welche Attribute von einer oder mehreren Dimensionen einbeziehen, wobei die entsprechenden Schlüsselwerte für die Attribute bestätigt werden, und danach eine Entscheidung getroffen wird, ob Attributlogik oder Schlüsselwertlogik in der Abfrage verwendet werden soll, abhängig von der Anzahl der Schlüsselwerte und Attribute, die nötig sind, um die Abfrage durchzuführen. Vorzugsweise basiert die Abfrage auf einer Anforderung nach Daten, welche einen oder mehrere der Attributwerte aus einer oder mehrerer der Dimensionen spezifizieren.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt drei generische Relationstabellen und eine entsprechende Faktentabelle mit Beispielcharakter.
2A und 2B zeigen zwei Tabellen mit Beispielcharakter.
2C zeigt eine Verknüpfung der zwei in 2A und 2B gezeigten Tabellen.
3 zeigt Komponenten eines Systems gemäß einer ersten Ausführungsform der Erfindung.
4 ist ein Flussdiagramm, das einen Auswahlalgorithmus gemäß einer ersten Ausführungsform der Erfindung darstellt.
AUSFÜHRLICHE BESCHREIBUNG
Eine konkrete Ausführungsform der vorliegenden Erfindung wird nun mit Bezug auf 3 bis 4 beschrieben.
Wie in 3 gezeigt, ist ein Abfragegenerator 20 vorgesehen als ein Objekt auf einem Applikationsserver 2. Der Abfragegenerator nimmt externe Anforderungen an und erzeugt SQL-Abfragen aus denselben. Diese SQL-Abfragen werden danach an eine Datenbank-Engine 4 gesendet, welche die angeforderten Daten von einer Datenbank 6 bezieht. Die zurückgegebenen Daten werden dann von der Datenbank-Engine an den Anwendungsserver zurückgesendet und entweder an den Anfordernden zurückgegeben oder verarbeitet und an eine andere Stelle gesendet, zum Beispiel zu einem Displayserver 10.
Der Applikationsserver speichert auch Repliken 12 der Dimensionen, die in der Datenbank gespeichert sind, welche die Faktendaten betreffen, die bezogen werden sollen. Wenn eine Anforderung, die ein oder mehrere Attribute einbezieht, von dem Abfragegenerator empfangen wird, durchsucht der Abfragegenerator die Dimensionseingaben und identifiziert alle erforderlichen Schlüsselwerte. Das könnte auch unter Verwendung von Abfragen an den Datenbankserver geschehen, wäre jedoch weitaus ineffizienter.
Der Abfragegenerator 20 entscheidet danach, wie die Abfrage erzeugt werden sollte, unter Verwendung der folgenden Logik, welche als ein Flussdiagramm in 4 dargestellt ist.
Für jede der Dimensionen wird es, wenn die Anzahl der Schlüsselwerte unter einem gewissen empirisch bestimmten Schwellenwert liegt, als wahrscheinlich erachtet, dass es effizienter ist, die Schlüsselwerte einfach mit den Werten in der Faktentabelle zu vergleichen, um die Resultate der Abfrage zu erhalten. Für dieses System, an welchem die Ausführungsform von den Anmeldern implementiert worden ist, wurde ein idealer Wert für diese Schwelle bei 30 gefunden. Die Abfrage, die in diesem Fall generiert wird, beinhaltet nicht die Dimensionen und wird einfach nach den Faktendaten durchgeführt (bezeichnet als eine Abfrage "ohne" bezogen auf die Dimension, da die Dimension nicht erforderlich ist.) Zum Beispiel könnte die folgende Abfrage erzeugt werden.
Wenn allerdings die Anzahl der Schlüssel die gewisse vorbestimmte Schwelle übersteigt, variiert die erzeugte Abfrage abhängig davon, ob es einen Index zur Dimension für die Faktentabelle gibt oder nicht.
Wie oben erörtert, kann, wenn die Dimension indiziert ist, ein Schlüsselwert von dieser Dimension sehr schnell auf geeignete Eingaben in der Faktentabelle abgebildet werden, welche den Schlüsselwert verkörpern.
Wenn der Dimensionsschlüssel indiziert ist, wird ein Vergleich durchgeführt, um festzustellen, ob die Anzahl an Schlüsselwerten, welche in der Abfrage erscheinen, die Anzahl an Attributwerten, multipliziert mit einer gewissen vorbestimmten Konstante A, ebenfalls empirisch bestimmt, überschreitet. Für das System, an welchem diese Ausführungsform von den Anmeldern implementiert worden ist, wurde ein idealer Wert bei 30 gefunden, wenngleich anzumerken wäre, dass dieser Wert mit dem oben erörterten Schwellenwert in keinem Zusammenhang steht.
Wenn die Anzahl an Schlüsselwerten diesen Wert übersteigt, wird für wahrscheinlich erachtet, dass Attributlogik effizienter ist, und es wird eine Attributabfrage erzeugt. Zum Beispiel wird eine Abfrage "mit Join" erzeugt, welche die folgenden Terme beinhaltet. Der Begriff "mit Join" bezieht sich darauf, dass eine Join-Verknüpfung zwischen der Faktentabelle und eben dieser Dimensionstabelle, wie mit Bezug auf 2A bis 2C erörtert, durchgeführt wird. Es wäre anzumerken, dass alle attributbasierten Abfragen bezogen auf diese Dimension Abfragen "mit Join" sind, da die Attributwerte nicht ohne Rückgriff auf die Dimensionstabelle bestätigt werden können.
Wenn allerdings die Anzahl an Schlüsselwerten die Anzahl an Attributwerten, multipliziert mit der Konstante A, nicht übersteigt, wird eine schlüsselwertbasierte Abfrage "mit Join" erzeugt, welche die Dimension in der Abfrage beinhaltet, unter Verwendung des optimierten Indizierens der Datenbank-Engine. Die Abfrage könnte die folgenden Terme beinhalten:
Wenn eben diese Dimension nicht indiziert ist, wird es weniger von Vorteil sein, die Schlüsselwerte zu verwenden, sofern es überhaupt von Vorteil ist. Zum Beispiel könnte es für eine Datenbank-Engine nahezu gleich schnell sein, einen Attributwert in der zugeordneten Dimensionstabelle aufzusuchen und zu prüfen, um festzustellen, ob er zutrifft, wie es wäre, festzustellen, ob ein Schlüsselwert zutrifft. Daher wird in diesem Fall eher ein einfacher Vergleich der Anzahl an Schlüsselwerten mit der Anzahl an Attributwerten durchgeführt, als der lange Weg des Erstellens eines empirischen Koeffizienten beschritten. Ein derartiger Koeffizient könnte allerdings, wenn geeignet, verwendet werden, abhängig von der Datenbank-Engine.
Wenn die Anzahl an Schlüsselwerten größer ist als die Anzahl an Attributwerten, welche in der Abfrage für diese Dimension verwendet würden, wird eine Attributabfrage "mit Join" für diese Dimension in der Abfrage verwendet. Andernfalls wird eine Schlüsselwerteabfrage "ohne Join" für diese Dimension verwendet, da kein Vorteil darin besteht, die Dimension in die Suche einzuschließen, da sie nicht indiziert ist.
Dieser Auswahlalgorithmus wird für jede Dimension wiederholt, und die Abfrage wird danach geeignet erzeugt und an die Datenbankabfrage-Engine weitergeleitet.
Selbstverständlich könnten, abhängig von den verschiedenen Eigenschaften der Abfrage in jeder der Dimensionen, unterschiedliche Join-Verknüpfungen in jeder Dimension ausgeführt werden. Einige Dimensionen könnten in der Abfrage beinhaltet sein und andere nicht. Ferner könnten einige der Dimensionen Attributlogik beinhalten und andere nicht. Zum Beispiel könnte die folgende vollständige Abfrage erzeugt werden, wobei die erste Dimension und die dritte Dimension in der Abfrage beinhaltet wären, wobei die erste Schlüsselwertlogik verwenden könnte und die zweite Attributwertlogik:
Einige Anforderungen sind komplexer als die bisher beschriebenen Fälle. Zum Beispiel treten "multiple keeps"-Anforderungen auf, wenn ein Benutzer mehrere getrennte Auswahlen ("Keeps") aus einer Dimension ausführt. Die Abfrage, die in diesem Fall erzeugt wird, muss ODER-Logik in der WHERE-Klausel verwenden, um diese Situation zu modellieren. Nehmen wir also an, ein Benutzer hat zum Beispiel bei Auswählen aus Dimension dim1 mehrere "Keeps" ausgeführt. Der erste Keep hat Attribute attr1 und attr2 einbezogen, während der zweite Keep Attribute attr3 und attr4 einbezogen hat. Die erzeugte Abfrage sollte wie folgt lauten:
Gemäß dieser Ausführungsform, bei Abfragen dieser Art, wird jedes in der attributbasierten Abfrage bezeichnete Attribut als ein Attribut in dem obigen Algorithmus gezählt. Die äquivalente Abfrage unter Verwendung von Schlüsselwerten ist von demselben an früherer Stelle beschriebenen Format, mit einer einfachen "IN"-Liste, und es gibt daher keine zusätzliche Komplexität beim Erstellen der Anzahl der Schlüsselwerte.
Ein noch komplexeres Szenario tritt auf, wenn der Benutzer eine Kennzahl (Measure) auswählt, die eine "Base"-Berechnung beinhaltet (d.h. "etw" wie Share). Das verlangt typischerweise (eine) zusätzliche Auswahl(en) "hinter den Kulissen" aus der gegebenen Dimension. Die Schlüssellogik löst diese Situation durch zusätzliche Schlüsselwerte in der Liste der Schlüssel für die Dimension. Die Attributlogik muss ein zusätzliches ODER noch dazu zu der Syntax ausführen, bezogen auf die mehreren "Keeps". Angenommen, dass (noch dazu zu den mehreren "Keeps" aus dem obigen Beispiel) der Benutzer eine "Base"-Berechnung auswählt, die zusätzliche Auswahl in Dimension dim1 verlangt, etwa aus attr5. Die Abfrage wird wie folgt aussehen:
Eine derartige Situation wird in dem "multiple keeps"-Szenario auf ähnliche Weise behandelt.
Es wäre anzumerken, dass eine Sternverknüpfungsoption in Verbindung mit der Attributelogikoption verwendet werden kann, wobei einige Dimensionen eine Sternverknüpfung auf Basis einer indizierten Dimension verwenden, und einige Dimensionen die Standardattributlogik verwenden. Angenommen, dass ein einfacher Fall von Attributlogik für Dimension dim1 verwendet wird, so könnte die Abfrage wie folgt aussehen:
In dem System dieser Ausführungsform erlauben Benutzerprofile, die Daten, die an den Benutzer zurückgegeben werden, in Subsets zu unterteilen. Der Benutzer hat nur Zugriff auf jene Datensätze, die einzusehen der Benutzer berechtigt ist. Base verwendet einen Filtermechanismus, um das zu erreichen. Vom Standpunkt der Attributlogik aus betrachtet ist das Benutzerprofil ein Set von Dimensionsauswahlen, die das Datensubset bestimmen, auf das der Benutzer zugreifen kann.
Angenommen, dass das Benutzerprofil für Dimension dim1 definiert, dass der Benutzer nur auf jene Datensätze zugreifen kann, bei denen sich die Werte von Attribut attrK in der gegebenen Werteliste befinden, könnte die Abfrage, die von der Attributlogik erzeugt wird, wie folgt aussehen:
Jeder genannte Attributwert wird in dem Algorithmus dieser Ausführungsform der Erfindung als ein einziger Attributwert behandelt.
Die Attributlogik wird von partitionierten Faktensets nicht beeinträchtigt. Im Fall physikalischer Partitionen wird jede Partition unter Verwendung einer Aggregattabelle definiert. Typischerweise wird eine Abfrage auf jede Partition unter Verwendung der beschriebenen Logik gerichtet.
Während bevorzugte Ausführungsformen der vorliegenden Erfindung illustriert und beschrieben worden sind, wird es in Durchschnittsfachkreisen klar sein, dass Änderungen und Modifikationen vorgenommen werden können, ohne von der Erfindung, wie sie beansprucht ist, abzuweichen. Verschiedene Merkmale der vorliegenden Erfindung sind in den folgenden Ansprüchen ausgeführt.

Claims

Verfahren zur Erzeugung einer Abfrage, die dazu verwendet werden soll, um Daten aus einer Datenbank zu erhalten, wobei die Datenbank eine oder mehrere Faktentabellen und mindestens eine Dimensionstabelle umfasst; wobei jede Dimensionstabelle Daten bereitstellt, die eine Dimension darstellen, und die Daten Attributwerte in einem Satz von Attributen für einen Satz von Einheiten umfassen, wobei jede Einheit durch einen Schlüsselwert identifiziert wird und die Faktentabellen Dateneingaben umfassen, wobei jede Dateneingabe einer Einheit aus jeder der Dimensionen zugeordnet ist; dadurch gekennzeichnet, dass das Verfahren für jede Dimension die folgenden Schritte umfasst: Herstellen aller Schlüsselwerte in der Dimension, die den Attributwerten in der Dimension zugeordnet sind; Auswählen, ob ein Schlüsselwert oder ein Attributwert in dieser Dimension als eine Funktion der Anzahl der Schlüsselwerte und der Anzahl der Attributwerte in der Dimension abgefragt werden soll; und Erzeugen der Teile der Abfrage entsprechend dieser Dimension durch Verwendung von Attributwerten, wenn eine Attributwertabfrage ausgewählt wurde; Erzeugen der Teile der Abfrage entsprechend dieser Dimension durch Verwendung von Schlüsselwerten, wenn eine Schlüsselwertabfrage ausgewählt wurde.
Verfahren nach Anspruch 1, wobei der Schritt des Auswählens, ob ein Schlüsselwert oder ein Attributwert abgefragt wird, den Schritt des Vergleichs der Anzahl der Schlüsselwerte mit einem Schwellenwert umfasst und, wenn die Anzahl der Schlüsselwerte geringer ist als ein zuvor festgelegter Wert, der Teil der Abfrage entsprechend jener Dimension durch eine Schlüsselwertabfrage in einer Faktentabelle implementiert wird.
Verfahren nach Anspruch 2, wobei bei einer Anzahl der Schlüsselwerte in der Dimension, die höher ist als der zuvor festgelegte Schwellenwert, der Teil der Abfrage entsprechend der Dimension durch Verwendung von Attributwerten implementiert wird, wenn das Verhältnis der Schlüsselwerte zu den Attributwerten, das notwendig ist, um die Abfrage zu implementieren, unterhalb eines gewissen Verhältniswertes liegt, und Implementieren durch Verwenden von Schlüsselwerten, wenn das Verhältnis oberhalb des Verhältniswertes liegt.
Verfahren nach Anspruch 3, wobei der Verhältniswert in Abhängigkeit davon, ob die Dimension indiziert ist, variiert.
Verfahren nach Anspruch 3, wobei bei einer Implementierung des Teiles der Abfrage Verwendung von Schlüsselwerten der Teil der Abfrage unter Anwendung lediglich der Faktentabelle implementiert wird, wenn die Dimension nicht indiziert ist, und die Abfrage implementiert wird durch Zusammenfügen der Faktentabelle mit der entsprechenden Dimensionstabelle und Abfragen des Dimensionsschlüssels in der zusammengefügten Dimensionstabelle, wenn die Dimension indiziert ist.
Vorrichtung zur Erzeugung einer Abfrage, um Daten aus einer Datenbank zu erhalten, wobei die Datenbank eine oder mehrere Faktentabellen und mindestens eine Dimensionstabelle umfasst; wobei jede Dimensionstabelle Daten bereitstellt, die eine Dimension darstellen und die Daten Attributwerte in einem Satz von Attributen für einen Satz von Einheiten umfassen und jede Einheit durch einen Schlüsselwert identifiziert wird; wobei die Faktentabellen Dateneingaben um fassen und jede Dateneingabe einer Einheit aus jeder der Dimensionen zugeordnet ist; dadurch gekennzeichnet, dass die Vorrichtung umfasst: Mittel zum Erstellen aller Schlüsselwerte in jeder Dimension, die den Attributwerten in der Dimension zugeordnet sind; Mittel zum Auswählen, ob ein Schlüsselwert oder ein Attributwert in dieser Dimension als eine Funktion der Anzahl der Schlüsselwerte und der Anzahl der Attributwerte in der Dimension abgefragt werden soll; und Mittel zum Erzeugen der Teile der Abfrage entsprechend der Dimension durch Verwendung von Attributwerten, wenn eine Attributwertabfrage ausgewählt wurde; Mittel zum Erzeugen der Teile der Abfrage entsprechend der Dimension durch Verwendung von Schlüsselwerten, wenn eine Schlüsselwertabfrage ausgewählt wurde.
Vorrichtung nach Anspruch 6, wobei die Mittel zum Auswählen, ob ein Schlüsselwert oder ein Attributwert abgefragt werden sollen, Mittel zum Vergleichen der Anzahl der Schlüsselwerte mit einem Schwellenwert umfassen und, wenn die Anzahl der Schlüsselwerte geringer ist als ein zuvor festgelegter Wert, der Teil der Abfrage, der der Dimension entspricht durch Verwendung einer Schlüsselwertabfrage in einer Faktentabelle implementiert wird.
Vorrichtung nach Anspruch 7, wobei bei einer Anzahl der Schlüsselwerte in der Dimension, die über dem zuvor festgelegten Schwellenwert liegt, der Teil der Abfrage, der der Dimension entspricht durch Verwendung von Attributwerten implementiert wird, wenn das Verhältnis der Schlüsselwerte zu den Attributwerten, welches notwendig ist, um die Abfrage zu implementieren, unterhalb eines gewissen Verhältniswertes liegt, und Implementieren durch Verwenden von Schlüsselwerten, wenn das Verhältnis oberhalb dieses Verhältniswertes liegt.
Vorrichtung nach Anspruch 8, wobei der Verhältniswert in Abhängigkeit davon variiert, ob die Dimension indiziert ist.
Vorrichtung nach Anspruch 8, wobei der Teil der Abfrage unter Verwendung lediglich der Faktentabelle implementiert wird, wenn der Teil der Abfrage durch Verwendung von Schlüsselwerten implementiert wird, wenn die Dimension nicht indiziert ist, und die Abfrage durch Zusammenfügen der Faktentabelle mit der entsprechenden Dimensionstabelle implementiert wird und durch Abfragen des Dimensionsschlüssels in der kombinierten Dimensionstabelle, wenn die Dimension indiziert ist.
Computerlesbares Medium, umfassend die Anweisungen, die den Computer dazu veranlassen, ein Verfahren gemäß einem der Ansprüche 1 bis 5 durchzuführen, sofern dieses durch einen dafür geeigneten Computer ausgeführt wird.