DE10039537A1 - Verbesserung der mehrdimensionalen Umstrukturierung beim Hinzufügen oder Entfernen von Dimensionen und Dimensionsmitgliedern - Google Patents

Abstract

Ein Verfahren, eine Einrichtung und ein Erzeugnis zur Verbesserung der mehrdimensionalen Umstrukturierung beim Hinzufügen oder Entfernen von Dimensionen oder Dimensionsmitgliedern. In einem Computer wird ein Befehl zur Durchführung einer Datenbankoperation in einer relationalen Datenbank, die auf einem Datenspeicher, der mit dem Computer verbunden ist, gespeichert ist, ausgeführt. Es wird festgestellt, dass eine mehrdimensionale Datenbank geändert wurde. Anschließend wird festgestellt, dass in der geänderten mehrdimensionalen Datenbank Änderungen in einer oder mehreren ursprünglichen Tabellen in einer relationalen Datenbank, die der mehrdimensionalen Datenbank entspricht, erforderlich sind. Die Änderungen werden in einer oder mehreren neuen Tabellen zusammengefasst, indem Daten aus den ursprünglichen Tabellen in die neuen Tabellen kopiert werden.

Description

QUERVERWEIS AUF WEITERE PATENTANMELDUNGEN

Diese Anwendung bezieht sich auf die folgenden gleichzeitig schwebenden und gemeinsam erteilten Patentanmeldungen:

Anmeldung Nr. 09/385,317 mit dem Titel "IMPROVING MULTI- DIMENSIONAL RESTRUCTURE PERFORMANCE BY SELECTING A TECHNIQUE TO MODIFY A RELATIONAL DATABASE BASED ON A TYPE OF RESTRUCTURE", eingereicht am 30. August 1999 von Daniel M. DeKimpe et al.

Anmeldung Nr. 09/356,647 mit dem Titel "IMPROVING PERFORMANCE OF TABLE INSERTION BY USING MULTIPLE TABLES OR MULTIPLE THREADS", eingereicht am 19. Juli 1999 von Daniel M. DeKimpe et al.

Anmeldung Nr. 09/356,471 mit dem Titel "EXTENSION OF DATA DEFINITION LANGUAGE (DDL) CAPABILITIES FOR RELATIONAL DATABASES FOR APPLICATIONS ISSUING DDL STATEMENTS", eingereicht am 19. Juli 1999 von Daniel M. DeKimpe et al.

Anmeldung Nr. 09/356,059 mit dem Titel "EXTENSION OF DATA DEFINITION LANGUAGE (DDL) CAPABILITIES FOR RELATIONAL DATABASES FOR APPLICATIONS ISSUING DDL AND DML STATEMENTS", eingereicht am 19. Juli 1999 von Daniel M. DeKimpe et al.

Anmeldung Nr. 09/356,644 mit dem Titel "EXTENSION OF DATA DEFINITION LANGUAGE (DDL) CAPABILITIES FOR RELATIONAL DATABASES FOR APPLICATIONS ISSUING MULTIPLE UNITS OF WORK", eingereicht am 19. Juli 1999 von Daniel M. DeKimpe et al.

Auf diese Anmeldungen wird im vorliegenden Dokument verwiesen.

HINTERGRUND DER ERFINDUNG 1. Anwendungsbereich der vorliegenden Erfindung

Die vorliegende Erfindung bezieht sich im allgemeinen auf Datenbank-Verwaltungssysteme für Computer und im besonderen auf eine Verbesserung der mehrdimensionalen Umstrukturierung beim Hinzufügen oder Entfernen von Dimensionen und Dimensionsmitgliedern.

2. Beschreibung der verwandten Fachgebiete

Die Software von relationalen Datenbank-Verwaltungssystemen (RDBMS), die eine Schnittstelle mit einer strukturierten Abfragesprache (SQL) verwenden, ist dem Fachmann auf diesem Gebiet bekannt. Die Schnittstelle SQL hat sich zu einer Standardsprache für RDBMS-Software entwickelt und wurde demzufolge sowohl vom American National Standards Institute (ANSI) als auch von der International Standards Organization (ISO) aufgenommen.

RDBMS-Software wird normalerweise von Datenbanken verwendet, die sich aus herkömmlichen Datentypen zusammensetzen, welche sich leicht in Tabellen strukturieren lassen. Allerdings weisen RDBMS-Produkte Beschränkungen hinsichtlich spezifischer Datenansichten für den Benutzer auf. Folglich werden für RDBMS-Produkte sogenannte "front-ends" entwickelt, so dass die aus einer RDBMS geladenen Daten angehäuft, zusammengefasst, konsolidiert, summiert, betrachtet und analysiert werden können. Diese sogenannten "front-ends" bieten jedoch nicht ohne weiteres die Möglichkeit, Daten in einer "mehrdimensionalen Datenanalyse" zu konsolidieren, betrachten und analysieren. Dieser Funktionalitätstyp ist auch unter der Bezeichnung "analytische online-Verarbeitung" (OLAP) bekannt.

OLAP besteht normalerweise aus mehreren spekulativen "was, wenn"- und/oder "warum"-Datenmodellszenarien, die von einem Computer ausgeführt werden. Innerhalb dieser Szenarien werden die Werte von Schlüsselvariablen oder Parametern geändert, manchmal sogar des öfteren, um mögliche Schwankungen in den gemessenen Daten zu berücksichtigen. Zusätzliche Daten werden daraufhin in einer Animation des Datenmodells synthetisiert. Dazu gehört häufig eine Konsolidierung angenommener und tatsächlicher Daten gemäß mehr als einem Konsolidierungspfad bzw. mehr als einer Dimension.

Der Begriff Datenkonsolidierung bezeichnet den Prozeß, in dem Daten zu wesentlichem Wissen zusammengefasst, oder synthetisiert, werden. Die höchste Ebene in einem Datenkonsolidierungspfad wird als die Dimension dieser Daten bezeichnet. Eine gegebene Datendimension stellt eine bestimmte Datenperspektive dar, die im entsprechenden Konsolidierungspfad enthalten ist. Normalerweise gibt es mehrere unterschiedliche Dimensionen, anhand derer ein gegebener Datenpool analysiert werden kann. Diese pluralistische Perspektive (Multi-Dimensional Conceptual View) scheint die Art und Weise wiederzugeben, wie die meisten Geschäftsleute ihr Unternehmen ansehen. Jede dieser Perspektiven wird als komplementäre Datendimension betrachtet. Eine gleichzeitige Analyse mehrerer Datendimensionen wird als mehrdimensionale Datenanalyse bezeichnet.

Die OLAP-Funktionalität ist durch ihre dynamische mehrdimensionale Analyse konsolidierter Daten charakterisiert, die unter anderem folgende analytische und navigationsbezogenen Aktivitäten des Endbenutzers umfasst:

• - Kalkulation und Modellierung in mehreren Dimensionen, über Hierarchien und/oder Mitglieder hinweg;
• - Trendanalyse oder aufeinanderfolgende Zeitperioden;
• - Separate Betrachtung von Untergruppen auf dem Bildschirm;
• - Vordringen in tieferliegende Konsolidierungsebenen;
• - Zugriff auf zugrundeliegende Detaildaten und
• - Rotation zu neuen Dimensionsvergleichen im Darstellungsbereich.

OLAP wird häufig in einem Client/Server-Mehrbenutzermodus implementiert und hat zum Ziel, unabhängig von der Datenbankgröße und -komplexität eine schnelle Reaktionszeit auf Datenbankzugriffe zu bieten. Zwar haben einige Anbieter OLAP-Systeme mit RDBMS-Produkten als Speichermanager in ihrem Produktangebot, doch waren solche Angebote bislang aus mehreren Gründen nicht erfolgreich.

Ein mehrdimensionales OLAP-System hat mehrere Dimensionen und Mitglieder innerhalb der Dimensionen. Die Daten für diese Dimensionen und Mitglieder lassen sich in einer Tabelle speichern. Werden diese Dimensionen anschließend geändert, so werden auch die Daten in der Tabelle geändert. Insbesondere heißt das, dass eine Vielzahl an Zeilen in einem einzigen Arbeitsschritt aus der Tabelle einer relationalen Datenbank gelöscht (entfernt) werden kann. Das Löschen vieler Zeilen auf einmal kann mehrere Probleme hervorrufen. Zunächst kann aufgrund der großen zu löschenden Datenmengen die Leistung gering sein, weil der Datenbankmanager alle Änderungen protokolliert. Zweitens kann der Speicherplatz für die Protokolle des Datenbankmanagers knapp werden. Einige Datenbankmanager haben eine Obergrenze für die Größe der Protokolldatei einer Transaktion. Wenn eine ausreichende Anzahl an Zeilen gelöscht wird, dann wird diese maximale Protokolldateigröße erreicht.

Daher besteht auf diesem Gebiet Bedarf an einer höheren mehrdimensionalen Umstrukturierungsleistung beim Hinzufügen oder Entfernen von Dimensionen und Dimensionsmitgliedern.

ZUSAMMENFASSUNG DER VORLIEGENDEN ERFINDUNG

Um die Beschränkungen des oben beschriebenen Standes der Technik zu beseitigen und um weitere Beschränkungen zu beseitigen, die bei der anschließenden Lektüre der vorliegenden Spezifikation sichtbar werden, beschreibt die vorliegende Erfindung eine Methode, ein Gerät und ein Produkt zur Verbesserung der mehrdimensionalen Umstrukturierung beim Hinzufügen oder Entfernen von Dimensionen und Dimensionsmitgliedern.

Entsprechend einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wird in einem Computer ein Befehl ausgeführt, welcher bewirkt, dass in einer relationalen Datenbank, die in einem Datenspeicher gespeichert ist, eine Datenbankoperation durchgeführt wird. Es wird bestimmt, dass eine mehrdimensionale Datenbank geändert wird. Danach wird bestimmt, dass die geänderte mehrdimensionale Datenbank Änderungen in einer oder mehreren ursprünglichen Tabellen in einer relationalen Datenbank entsprechend der mehrdimensionalen Datenbank erfordert. Die Änderungen werden in eine oder mehrere neue Tabellen eingearbeitet, indem Daten aus den ursprünglichen Tabellen in die neuen Tabellen hineinkopiert werden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

In allen Zeichnungen beziehen sich gleiche Referenzziffern auf gleiche Komponenten.

Fig. 1 ist ein Blockdiagramm, das eine Hardware-Umgebung veranschaulicht, die zur Implementierung eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung verwendet wird.

Fig. 2 ist ein Diagramm, das die grundlegende Struktur (konzeptionelle Strukturen oder Outline) einer mehrdimensionalen Datenbank gemäß der vorliegenden Erfindung veranschaulicht.

Fig. 3 ist ein Diagramm, das die logische Struktur einer mehrdimensionalen Datenbank gemäß der vorliegenden Erfindung veranschaulicht.

Fig. 4 ist ein Diagramm, das eine Struktur zur Speicherung mehrdimensionaler Daten in einer relationalen Datenbankstruktur gemäß der vorliegenden Erfindung veranschaulicht.

Fig. 5 ist ein Diagramm, das die konzeptionelle Struktur einer mehrdimensionale Datenbank gemäß der vorliegenden Erfindung veranschaulicht.

Fig. 6 ist ein Diagramm, das die konzeptionelle Struktur einer mehrdimensionale Datenbank gemäß der vorliegenden Erfindung veranschaulicht.

Fig. 7 ist ein Flußdiagramm, das die Schritte veranschaulicht, die vom Verwaltungssystem des relationalen Speichers bei der Verwendung des Kopierverfahrens ausgeführt werden.

Fig. 8A und 8B sind Flußdiagramme, die die Schritte veranschaulichen, die vom Verwaltungssystem des relationalen Speichers bei der Bestimmung, ob das Kopierverfahren oder das Löschverfahren verwendet werden soll, ausgeführt werden.

Fig. 9 ist ein Blockdiagramm, welches eine verbesserte Leistung beim Einfügen von Tabellen durch Verwendung mehrerer Tabellen oder mehrerer Threads veranschaulicht und

Fig. 10 ist ein Blockdiagramm, welches das Verwaltungssystem des relationalen Speichers unter Verwendung von N Threads zur Umverteilung von Daten zwischen N Faktentabellen veranschaulicht.

AUSFÜHRLICHE BESCHREIBUNG EINES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS

In der nachfolgenden Beschreibung eines bevorzugten Ausführungsbeispiels wird auf die beigefügten Zeichnungen verwiesen, die einen Bestandteil der Beschreibung bilden und die musterhaft ein spezifisches Ausführungsbeispiel darstellen, in dem sich die Erfindung umsetzen läßt. Es wird darauf hingewiesen, dass auch andere Ausführungsbeispiele möglich sind und strukturelle und funktionale Änderungen vorgenommen werden können, ohne vom Grundprinzip der vorliegenden Erfindung abzuweichen.

Übersicht

Die vorliegende Erfindung umfasst ein OLAP-System, das auf eine breite Palette mehrdimensionaler Berichterstellungs- und Analyseanwendungen ausgelegt ist. Das OLAP-System basiert sowohl auf die Software Essbase OLAP von Hyperion Software als auch auf die Software DB2 RDBMS von IBM. Das Anwendungsbeispiel der vorliegenden Erfindung verwendet zahlreiche Komponenten des Essbase-OLAP-Systems von Hyperion Software, darunter auch Komponenten, die den Datenzugriff, die Navigation, die Anwendungserstellung und -verwaltung und die Datenkalkulation ermöglichen. Das Anwendungsbeispiel der vorliegenden Erfindung umfasst jedoch auch neue Elemente, die Datenbankoperationen ausführen, beispielsweise die Speicherung und das Laden von Daten für das OLAP-System in einer relationalen Datenbank. Das Anwendungsbeispiel der vorliegenden Erfindung ersetzt das integrierte Verwaltungssystem des mehrdimensionalen Datenspeichers im Essbase-OLAP-System von Hyperion Software durch ein Verwaltungssystem für den relationalen Speicher auf der Basis der Software DB2 RDBMS von IBM. Das Verwaltungssystem für den relationalen Speicher ermöglicht es dem OLAP-System, Daten direkt in eine relationale Datenbank einzuspeichern.

Die in der vorliegenden Erfindung verwendete relationale Datenbank bietet die Kapazität führender relationaler Datenbanken in der Industrie und läßt sich mit bekannten Tools zur RDBMS-Systemverwaltung, für Backup und Wiederherstellung verwenden. Sie hat außerdem den Vorteil, dass sie unter Verwendung der strukturierten Standardabfragesprache (SQL) Zugriff auf Daten ermöglicht. Darüber hinaus ist die vorliegende Erfindung auf Anwendungen mit sehr großen Datenmengen ausgelegt. Nicht zuletzt kann die vorliegende Erfindung dazu eingesetzt werden, um die bestehenden RDBMS- Fähigkeiten von IT-Experten optimal auszuschöpfen.

Die vorliegende Erfindung unterscheidet sich wesentlich von ROLAP-Produkten des bisherigen Standes der Technik. ROLAP- Produkt des bisherigen Standes der Technik sind beispielsweise für Anwendungen ungeeignet, in denen komplexe Kalkulationen, Schreib/Lese-Unterstützung oder viele Benutzer gleichzeitig erforderlich sind. Darüber hinaus ist für ROLAP-Produkte des bisherigen Standes der Technik viel Personal erforderlich, um Anwendungen zu entwickeln und einzurichten.

In der vorliegenden Erfindung sind diese Beschränkungen nicht anzutreffen. Da die vorliegende Erfindung die Software Essbase OLAP von Hyperion Software mit der Software DB2 RDBMS von IBM kombiniert, ermöglicht sie einen einfacheren Aufbau, zuverlässigere Kalkulationen sowie flexiblen Datenzugriff und eine Skalierbarkeit des Benutzerzugriffs. Wesentliche Vorteile der vorliegenden Erfindung gegenüber ROLAP sind: Leistung, automatische Tabellen-, Index- und Zusammenfassungsverwaltung, zuverlässige Analysekalkulationen, Schreib- und Lesezugriff durch mehrere Benutzer, und Sicherheit.

Hinsichtlich ihrer Leistung ist die vorliegende Erfindung auf Reaktionsschnelligkeit unabhängig von der Datenbankgröße ausgelegt, die in Sekunden messbar ist. ROLAP-Produkte des bisherigen Standes der Technik messen die Reaktionszeit in Einheiten von je zehn Sekunden, Minuten oder gar Stunden. Hinsichtlich der automatischen Tabellen-, Index- und Zusammenfassungsverwaltung erstellt und verwaltet die vorliegende Erfindung automatisch Tabellen und Indizes in einem Sternschema in der relationalen Datenbank. Die vorliegende Erfindung kann das Sternschema auch mit Kalkulationsdaten füllen. ROLAP-Produkte des bisherigen Standes der Technik erfordern ganze Teams von Datenbankarchitekten, um hunderttausende von Zusammenfassungstabellen manuell zu verwalten, um eine akzeptable Endbenutzerleistung zu erreichen.

Im Hinblick auf zuverlässige analytische Kalkulationen ist die vorliegende Erfindung auf die Erstellung hochschneller Datenaggregationen (Einnahmen pro Woche, Monat, Quartal und Jahr), Matrixkalkulationen (prozentuale Anteile an der Gesamtsumme), dimensionsübergreifende Kalkulationen (Marktanteil und Produktanteil) und verfahrensabhängiger Kalkulationen (Einteilungen, Prognosen) ausgelegt. ROLAP- Produkte des bisherigen Standes der Technik haben weniger zuverlässige Kalkulationsfähigkeiten.

Im Hinblick auf den Schreib- und Lesezugriff durch mehrere Benutzer ist die vorliegende Erfindung auf einen Schreib- und Lesezugriff durch mehrere Benutzer ausgelegt, wodurch operationelle OLAP-Anwendungen wie Budgetierung, Planung, Prognosen, Modellierung, "was, wenn"-Funktionen usw. möglich sind. Andererseits sind ROLAP-Produkte des bisherigen Standes der Technik nur lesbar.

Im Hinblick auf ihre Sicherheit ist die vorliegende Erfindung auf eine hohe Datensicherheit bis hin zur einzelnen Datenzelle ausgelegt. ROLAP-Produkte des bisherigen Standes der Technik bieten entweder keinerlei Sicherheit oder aber eine nur beschränkte Sicherheit auf Anwendungsebene.

Die Funktionalität der vorliegenden Erfindung ist die gleiche wie die der Software Essbase OLAP von Hyperion Software. Sie umfasst komplexe OLAP-Kalkulationen, umfassende OLAP- Navigationsfunktionen, einen weitreichenden Datenbankzugriff sowie Schreib/Lese-Funktionen für mehrere Benutzer. Darüber hinaus ist eine Kombination mit Front-End-Tools, Systemmanagement-Tools und Anwendungen von Hyperion Software und führenden Fremdanbietern möglich. Berater- und Schulungsfirmen, die sich ein Wissen über die Software Essbase OLAP von Hyperion Software angeeignet haben, können sofort ihre Erfahrungen und Kenntnisse auf die vorliegende Erfindung anwenden.

Zwar beschreibt die vorliegende Spezifikation die Verwendung der Software DB2 RDBMS von IBM, doch weiß der Fachmann auf diesem Gebiet, dass die vorliegende Erfindung auch mit DB2, Oracle, Informix, Sybase oder anderer RDBMS-Software kombiniert und auch auf Computern ausgeführt werden kann, auf denen IBM OS/2, Microsoft Windows NT, IBM-AIX, Hewlett-Packard HP-UX, Sun Solaris und andere Betriebssysteme installiert sind.

Hardware-Umgebung

Fig. 1 ist ein Blockdiagramm, das eine Hardware-Umgebung veranschaulicht, die zur Implementierung des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung verwendet wird. In der Hardware-Umgebung wird eine Client/Server- Architektur gezeigt, die einen OLAP-Client-Computer 100 umfasst, der an einen OLAP-Servercomputer 102 gekoppelt ist. In der Hardware-Umgebung können der OLAP-Client 100 und der OLAP-Server 102 unter anderem einen Prozessor, einen Speicher, eine Tastatur oder einen Bildschirm umfassen und lokal oder entfernt mit festen und/oder beweglichen Datenspeichereinrichtungen und/oder Datenkommunikationsgeräten verbunden sein. Jeder der Computer 100 und 102 könnte über die Datenkommunikationseinrichtungen auch mit anderen Computersystemen verbunden sein. Der Fachmann auf diesem Gebiet weiß, dass eine beliebige Kombination der obigen Komponenten oder eine beliebige Anzahl verschiedener Komponenten, Peripheriegeräte und anderer Geräte zusammen mit den Computern 100 und 102 verwendet werden kann. Der Fachmann auf diesem Gebiet weiß auch, dass die vorliegende Erfindung nicht nur auf mehrere Computer, die in einem Netz miteinander verbunden sind, angewandt werden kann, sondern auch auf einen einzelnen Computer.

Die vorliegende Erfindung wird typischerweise unter Verwendung eines oder mehrerer Computerprogramme implementiert, von denen jedes unter der Steuerung eines Betriebssystems ausgeführt wird. Beispiele für solche Betriebssysteme sind OS/2, Windows, DOS, AIX, UNIX, MVS usw. Die vorliegende Erfindung veranlaßt die Computer 100 und 102, die gewünschten Funktionen gemäß Beschreibung im vorliegenden Dokument auszuführen.

Entsprechend kann unter Verwendung der vorliegenden Spezifikation die Erfindung als Maschine, Prozeß oder Produkt implementiert werden, indem eine Standardprogrammierung und/oder technische Verfahren eingesetzt werden, um Software, Firmware, Hardware oder eine Kombination daraus zu erstellen.

Im allgemeinen sind die Computerprogramme und/oder das Betriebssystem in einem computerlesbaren Gerät oder Medium enthalten, beispielsweise einem Speicher, Datenspeichergerät und/oder einer Datenkommunikationsverbindung, wodurch ein Computerprogrammprodukt oder Produkt gemäß der vorliegenden Erfindung entsteht. Entsprechend bezeichnen die Begriffe "Produkt" und "Computerprogrammprodukt" in diesem Dokument ein Computerprogramm, auf das von jedem beliebigen computerlesbaren Gerät oder Medium aus zugegriffen werden kann.

Darüber hinaus bestehen das Computerprogramm und das Betriebssystem aus Anweisungen, die, wenn sie von den Computern 100 und 102 gelesen und ausgeführt werden, die Computer 100 und 102 veranlassen, die nötigen Schritte zur Implementierung und/oder Verwendung der vorliegenden Erfindung auszuführen. Unter der Steuerung des Betriebssystems können die Computerprogramme aus dem Speicher, den Datenspeichereinrichtungen und/oder Kommunikationseinrichtungen in die Speicher der Computer 100 und 102 geladen werden, um sie für die jeweiligen Operationen zu verwenden. Der Fachmann auf diesem Gebiet weiß, dass in dieser Konfiguration zahlreiche Abwandlungen möglich sind, ohne vom Grundprinzip der vorliegenden Erfindung abzuweichen.

In dem in Fig. 1 gezeigten Beispiel umfasst die vorliegende Erfindung ein Netzwerkschnittstellenprogramm 104 und ein OLAP- Clientprogramm 106, das vom OLAP-Client 100 ausgeführt wird; sowie ein Netzwerkschnittstellenprogramm 108, ein OLAP-Agent- Programm 110, ein OLAP-Engine-Programm 112, ein relationales Speicherverwaltungsprogramm (RSM) 114 und ein DB2- Serverprogramm 116, das vom OLAP-Server 102 ausgeführt wird. Das DB2-Serverprogramm 116 wiederum führt verschiedene Datenbankoperationen aus, darunter beispielsweise Suchoperationen, Abfragen, Einfügeoperationen, Aktualisierungsoperationen und Löschoperationen in einer oder mehreren relationalen Datenbanken 118, die in einer entfernten oder lokalen Datenspeichereinrichtung gespeichert sind.

Die vorliegende Erfindung verwendet eine Reihe von Komponenten des Essbase-OLAP-Systems von Hyperion Software, darunter die Netzwerkschnittstelle 104, den OLAP-Client 106, die Netzwerkschnittstelle 108, den OLAP-Agent 110 und die OLAP- Engine 112. Diese Komponenten ermöglichen den Datenzugriff, die Navigation, die Anwendungserstellung, das Anwendungsmanagement und die Datenkalkulation. Der relationale Speichermanager 114 und der DB2-Server 116 enthalten jedoch auch neue Elemente, die für das OLAP-System in einer relationalen Datenbank auf Daten zugreifen (d. h. sie speichern und laden).

Der Fachmann auf diesem Gebiet weiß, dass die in Fig. 1 dargestellte Hardware-Umgebung nicht auf die vorliegende Erfindung beschränkt sein soll. Der Fachmann auf diesem Gebiet weiß, dass auch andere Hardware-Umgebungen verwendet werden können, ohne vom Prinzip der vorliegenden Erfindung abzuweichen.

Geplante Struktur der mehrdimensionalen Datenbank

Fig. 2 ist ein Diagramm, das die geplante Struktur einer mehrdimensionalen Datenbank 200 gemäß der vorliegenden Erfindung veranschaulicht. Eine Dimension 202, 214 oder 222 ist ein strukturelles Attribut, das heißt eine Liste von Mitgliedern, von denen alle in der Wahrnehmung des Benutzers einen ähnlichen Typ aufweisen. Zum Beispiel sind das Jahr 1997 204 und alle Quartale Q1 206, Q2 208, Q3 210, Q4 212 Mitglieder der Zeitdimension 202. Darüber hinaus wird jede der Dimensionen 202, 214 oder 222 selbst als Mitglied der mehrdimensionalen Datenbank 200 angesehen.

Logische Struktur der mehrdimensionalen Datenbank

Fig. 3 ist ein Diagramm, das die logische Struktur einer mehrdimensionalen Datenbank 300 gemäß der vorliegenden Erfindung veranschaulicht. Im allgemeinen ist die mehrdimensionale Datenbank 300 als mehrdimensionales Array angeordnet, so dass sich jede Datengruppe am Schnittpunkt der Mitglieder befindet, die diese Datengruppe definieren. Das Array umfasst eine Gruppe von Datenzellen, die durch die Dimensionen der Daten angeordnet werden. Eine Tabellenkalkulation stellt beispielsweise ein zweidimensionales Array dar, wobei die Datenzellen in Spalten und Zeilen angeordnet sind, und jede Datenzelle ist eine Dimension. Ein dreidimensionales Array läßt sich als Würfel darstellen, wobei jede Dimension eine Kante bildet. Höherdimensionale Arrays (auch als Cubes oder Hypercubes bekannt) haben keine physikalische Metapher, aber sie organisieren die Daten so, wie dies von den Benutzern gewünscht wird.

Eine Dimension verhält sich wie ein Index zur Angabe von Werten innerhalb des Würfels. Wird ein Mitglied der Dimension ausgewählt, definieren die verbleibenden Dimensionen, in denen einige (oder alle) Mitglieder ausgewählt sind, einen untergeordneten Würfel, in dem die Anzahl der Dimensionen um eins reduziert wird. Wenn für alle außer zwei Dimensionen ein einziges Mitglied ausgewählt ist, definieren die verbleibenden beiden Dimensionen eine Tabellenkalkulation (oder eine "Scheibe" oder eine "Seite"). Wenn für alle Dimensionen ein einziges Mitglied ausgewählt ist, dann wird eine einzelne Zelle definiert. Dimensionen bieten eine sehr genaue, intuitive Möglichkeit der Organisation und Auswahl von Daten zur Suche, Untersuchung und Analyse von Daten.

Ein einzelner Datenpunkt oder eine Zelle existiert am. Schnittpunkt, der durch Auswahl eines Mitglieds aus jeder Dimension in einem Würfel definiert wird. In dem in Fig. 3 dargestellten Beispielwürfel sind die Dimensionen Zeit, Produkt und Messgrößen. Der Würfel ist dreidimensional, und jede Dimension (also Zeit, Produkt und Messgrößen) wird durch eine Achse des Würfels dargestellt. Der Schnittpunkt der Dimensionsmitglieder (d. h. die Zeit 302, 1997 304, Q1 306, Q2 308, Q3 310, Q4 312, Produkt 314, A 316, B 318, C 320, Messgrößen 322, Umsatz 324, Kosten 326 und Gewinn 328) wird durch die Zellen in der mehrdimensionalen Datenbank dargestellt, die den genauen Schnittpunkt entlang aller Dimensionen angeben, die einen einzelnen Datenpunkt eindeutig bestimmen. Der Schnittpunkt von Q2 308, Produkt 314 und Kosten 326 beispielsweise enthält den Wert 369, der die Kosten aller Produkte im zweiten Quartal 1997 darstellt.

Würfel besitzen im allgemeinen in jeder Dimension Hierarchien von Datenbeziehungen, die auf Formeln basieren. Bei der Konsolidierung werden alle diese Datenbeziehungen für eine oder mehrere Dimensionen berechnet. Ein Beispiel für eine Konsolidierung ist die Summierung aller Umsätze im ersten Quartal. Zwar handelt es sich bei diesen Beziehungen im Normalfall um Additionen, es läßt sich jedoch jedes beliebige Rechenverhältnis oder jede beliebige Formel definieren.

Mitglieder einer Dimension werden in eine Rechenoperation einbezogen, bei der eine konsolidierte Summe, eine Gesamtsumme, für ein Elternmitglied erzeugt wird. Kinder können selbst konsolidierte Ebenen darstellen, was wiederum erforderlich macht, dass sie Kinder besitzen. Ein Mitglied kann ein Kind für mehr als ein Elternteil sein, und mehrere Elternteile eines Kindes liegen möglicherweise nicht auf derselben hierarchischen Stufe, wodurch komplexe Mehrfachverknüpfungen über mehrere hierarchische Stufen hinweg innerhalb einer beliebigen Dimension möglich sind.

Drilling, also die Herstellung einer Verbindung zu einer über- oder untergeordneten Ebene, ist ein spezifisches analytisches Verfahren, bei dem der Benutzer zwischen mehreren Datenebenen (z. B. der Ebene der Zusammenfassung (oben) und der detailgenauesten (unten)) navigiert. Die Drilling-Pfade können durch die Hierarchien innerhalb von Dimensionen oder anderen Beziehungen, die innerhalb oder zwischen Dimensionen dynamisch sein können, definiert werden. Bei der Anzeige von Daten für Umsatz 324 für das Jahr 1997 304 in Fig. 3 ergäbe die Drilling-Operation nach unten in die Dimension Zeit 302 die Anzeige der Mitglieder Q1 306, Q2 308, Q3 310 und Q4 312.

Struktur einer relationalen Datenbank

Fig. 4 ist ein Diagramm, das eine Struktur zur Speicherung mehrdimensionaler Daten in einer relationalen Datenbankstruktur gemäß der vorliegenden Erfindung veranschaulicht. In der vorliegenden Erfindung werden Daten nicht in einem speziellen mehrdimensionalen Datenspeicher, wie er im Elternteil '724 beschrieben ist, sondern in einem Sternschema 400 in der relationalen Datenbank 118 gespeichert. Um jedoch mit der Software Essbase OLAP von Hyperion Software richtig zu arbeiten, arbeiten der relationale Speichermanager 114 und der DB2-Server 116 der vorliegenden Erfindung zusammen, um die Struktur und die Funktionen, die im Elternteil '724 ausgeführt werden, zu emulieren, auch wenn zur Speicherung der mehrdimensionalen Daten eine andere Datenbank verwendet wird.

In der vorliegenden Erfindung werden die mehrdimensionalen Daten in einem Sternschema 400 in der relationalen Datenbank 118 gespeichert. Ein Sternschema 400 ist eine Gruppe relationaler Tabellen, die mehrere Haupttabellen 402 bis 422 und damit zusammenhängende Dimensionstabellen 414, 416 und 418 enthalten, wobei die Dimensionstabellen 414 und 416 die Haupttabellen 402 bis 422 über gemeinsame Spalten schneiden, wobei die Dimensionstabelle 418 eine Spalte in den Haupttabellen 402 bis 422 besitzt, die mit jeder ihrer Zeilen übereinstimmt. Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung bietet eine Ansicht mehrerer Partitionen als einzelne Tabelle. Insbesondere bezieht sich der Begriff "Partition", wie er in der vorliegenden Beschreibung verwendet wird, nicht unbedingt auf Partitionen, wie sie von einem standardmäßigen relationalen Datenbanksystem definiert werden, sondern vielmehr auf die Partitionierung von Daten in einzelnen Haupttabellen, die im bevorzugten Ausführungsbeispiel der vorliegenden Erfindung verwendet werden. Ein Sternschema 400 hat gegenüber der Speicherung von Informationen in traditionellen RDBMS-Tabellen, wie sie in der online-Transaktionsverarbeitung (OLTP) verwendet werden, mehrere Vorteile.

Da ein Sternschema 400 einfach aufgebaut ist und nur wenige Tabellen besitzt, beschränkt es die zur Verarbeitung von Datenbankoperationen erforderliche Komplexität auf ein Mindestmaß. Dies hat eine Leistungserhöhung zur Folge und gewährleistet korrekte Ergebnisse in Datenbankoperationen.

Darüber hinaus ist die Verwendung eines Sternschemas 400 ein gut bekanntes Standardmodell, und viele relationale Datenbanken 118 sind speziell dafür optimiert. Durch die Übernahme dieses Standardmodells profitiert die vorliegende Erfindung automatisch von jeder solchen Optimierung.

Im Beispiel von Fig. 4 stellen die Kästen und Ellipsen Faktentabellen 402 bis 422 und Dimensionstabellen 414, 416 und 418 dar. Die Verbindungen zwischen den Kästen 402 bis 422 und 414 und 416 stellen Sternverbindungen zwischen Tabellen dar. Die Faktentabellen 402 bis 422 werden auch als Faktentabellen bezeichnet. Somit umfasst das Sternschema 400 die Faktentabellen 402 bis 422, die entsprechend der angegebenen relationalen oder bedingten Operationen mit einer oder mehreren Dimensionstabellen, TIME 414 und PRODUCT 416, verbunden sind. Die Faktentabellen 402 bis 422 enthalten Datenwerte, während die Dimensionstabellen TIME 414, PRODUCT 416 und MEASURES 418 Mitgliederinformationen enthalten. Folglich sind die Dimensionstabellen 414, 416 und 418 relativ klein und die Faktentabellen 402 bis 422 normalerweise relativ groß.

Die Dimensionstabellen TIME 414 und PRODUCT 416 werden normalerweise anhand einer Äquivalenzbedingung mit den Faktentabellen 402 bis 422 verknüpft. In diesem Beispiel eines Sternschemas 400 gibt es keine Verknüpfungsbedingungen zwischen den Dimensionstabellen TIME 414, PRODUCT 416 und MEASURES 418 selbst.

Im bevorzugten Ausführungsbeispiel wird eine Dimension, die als sogenannte Ankerdimension bezeichnet wird, anders behandelt als die anderen Dimensionen, die als sogenannte Nicht-Anker-Dimension bezeichnet werden; das heißt, alle Mitglieder werden auf Spalten in den Faktentabellen 402 bis 422 abgebildet. In Fig. 4 beispielsweise ist die Dimension MEASURES 418 die Ankerdimension. In jeder der Faktentabellen 402 bis 422 (d. h. SALES 408 und 428, COSTS 410 und 430 und PROFITS 412 und 432) gibt es für jedes der Mitglieder SALES, COSTS und PROFITS der Dimension MEASURES 418 eine Spalte. Die Faktentabellen 402 bis 422 enthalten ebenfalls eine Spalte, TIME 404 und 424 und PRODUCT 406 und 426 für jede zweite Nicht-Anker-Dimension, TIME 414 und PRODUCT 416.

Zwar werden in Fig. 4 mehrere Faktentabellen dargestellt, doch weiß der Fachmann auf diesem Gebiet, dass das Verfahren der vorliegenden Erfindung auch auf eine einzelne Faktentabelle angewandt werden kann.

Faktentabelle

Im bevorzugten Ausführungsbeispiel der vorliegenden Erfindung gibt es N Faktentabellen für jeden Würfel (d. h. FACT TABLE-1 und FACT TABLE-N zusammen mit den Ellipsen in Fig. 4; diese veranschaulichen mehrere Faktentabellen). Die Faktentabellen enthalten die tatsächlichen Datenwerte des Würfels. Insbesondere enthält jede Faktentabelle einen Datenblock, der ein Teil des Würfels ist. Die Faktentabellen 402 bis 422 besitzen eine Dimensionsspalte, die jeder Nicht-Anker- Dimensionstabelle 414 und 416 entsprechen. Die Dimensionsspalten der Faktentabellen 402 bis 422 enthalten relationale Mitgliederkennungen, und die Nicht-Anker- Dimensionstabellen 414 und 416 enthalten die Abbildung zwischen diesen relationalen Mitgliederkennungen und den Mitgliedernamen sowie mehrdimensionale Mitgliederkennungen. Die Datenwerte in den Faktentabellen 402 bis 422 werden durch die relationalen Mitgliederkennungen von jeder der Dimensionsspalten indexiert. Eine Zeile in der Faktentabelle 402 beispielsweise enthält alle Datenwerte für eine einmalige Kombination von Mitgliedern aus den unterschiedlichen Nicht- Anker-Dimensionstabellen 414 und 416. Die Dimensionsspalten 404 und 406 enthalten relationale Mitgliederkennungen, die den mehrdimensionalen Mitgliederkennungen entsprechen, und die Mitgliederspalten 408, 410 und 412 enthalten Datenwerte. Die erste Zeile im Beispiel von Fig. 4 enthält beispielsweise für jedes Produkt und für alle Zeiten einen Umsatz von 3500, Kosten von 2500 und einen Gewinn von 1000. Die zweite Zeile im Beispiel von Fig. 4 enthält für Produkt A im Jahr 1997 einen Umsatz von 1650, Kosten von 1200 und einen Gewinn von 450.

Die Faktentabellen 402 bis 422 enthalten nur Zeilen für gültige Kombinationen von Mitgliedern der Nicht-Anker- Dimensionen. Wenn also beispielsweise ein bestimmtes Produkt in einem Jahr nicht verkauft wird, gibt es keinen Umsatz, keine Kosten und keinen Gewinn für einen bestimmten Zeitabschnitt für dieses Produkt in diesem Jahr. Folglich enthalten die Faktentabellen 402 bis 422 keine Zeilen für diese Kombinationen.

Dimensionstabellen

Wie oben bereits beschrieben wurde, gibt es für jede im Würfel definierte Dimension eine Dimensionstabelle. Der Zweck der Dimensionstabellen besteht darin, alle bezüglich der Mitglieder einer bestimmten Dimension relevanten Informationen bereitzustellen.

Jede Dimensionstabelle enthält eine Zeile für jedes in der dazugehörigen Dimension definierte Mitglied. Zu beachten ist, dass der Dimensionsname selbst als Mitglied betrachtet wird, da er die oberste Ebene der Hierarchie für diese Dimension darstellt. Es gibt folgende Spalten:

Mitgliedername

Dies ist der Mitgliedername, also der vom Benutzer eingegebene Name für jedes Mitglied. Der Wert des Mitgliedernamens wird auf einen Wert NULL gesetzt, wenn dieses Mitglied gelöscht wird. Wenn die Kennung RelMemberID erforderlich ist, wird die Kennung RelMemberID, die einem Mitgliedernamen entspricht, der ein Nullwert ist, wiederverwendet.

RelMemberName

Dies ist der relationale Mitgliedername. Er wird lediglich in der Ankerdimensionstabelle verwendet (weil Mitglieder aus dieser Dimension auf Spalten in der Faktentabelle 402 abgebildet werden). In dieser Spalte müssen daher gültige relationale Spaltennamen enthalten sein. Deshalb kann diese Spalte bei Bedarf Mitgliedernamen enthalten, die gegenüber den in MemberName enthaltenen geändert wurden.

RelMemberId

Dies ist die relationale Mitgliederkennung. Hier ist eine Kennzahl für jedes Mitglied enthalten, die verwendet wird, um auf Daten in der relationalen Datenbank zuzugreifen. Diese Zahl kommt in der Dimensionstabelle nur einmal vor. Die Spalte wird verwendet, um die Dimensionstabelle mit der Faktentabelle zu verbinden. Die Mitglieder behalten während ihrer gesamten Lebensdauer immer die gleiche relationale Mitgliederkennung. Eine relationale Mitgliederkennung kann wiederverwendet werden, wenn ein Mitglied gelöscht und ein anderes Mitglied angelegt wird.

MemberId

Dies ist die mehrdimensionale Mitgliederkennung. Dieses Feld enthält eine Kennzahl, die dem Mitglied von Essbase zugeordnet wird. Wird eine Würfeldefinition in Essbase und die Struktur der Essbase- Datenbank geändert, kann dieser Wert von Essbase geändert werden. Dies ist ein Wert NULL, wenn MemberName ein Wert NULL ist.

Der Wert von MemberName wird normalerweise von der konzeptionellen Struktur übernommen. Der Wert von MemberId wird von der Software Essbase OLAP von Hyperion Software zugeordnet und von dieser Software dazu verwendet, um auf mehrdimensionale Daten zuzugreifen, die in den dichten Datenblöcken in einer mehrdimensionalen Datenbank 300 gespeichert sind. Das Feld RelMemberId ist die gemeinsame Spalte zwischen den Nicht-Anker-Dimensionstabellen 414 und 416 und den Faktentabellen 402 bis 422, die verwendet wird, um die Tabellen 402, 414, und 416 und 422, 414 und 416 zu verbinden und um auf Daten in der relationalen Datenbank 118 (d. h. Faktentabelle 402) zuzugreifen. Der Wert von MemberId der intern von der Software Essbase OLAP von Hyperion Software verwendet wird, wird abgebildet auf RelMemberId, das von der relationalen Datenbank 118 verwendet wird, um auf Daten zuzugreifen.

Zugriff auf mehrdimensionale Daten

Um auf mehrdimensionale Daten in der relationalen Datenbank 118 zuzugreifen, kommuniziert ein Benutzer mit dem OLAP- Client-Programm 106, das vom OLAP-Client 100 ausgeführt wird. Diese Kommunikation führt zu einer Anforderung (d. h. zu einem Befehl), eine Datenbankoperation zu bilden, die an den OLAP- Agent 110 und/oder an die OLAP-Engine 112 übertragen und vom OLAP-Server 102 über die Netzwerkschnittstellenprogramme 104 und 108 ausgeführt wird. Der OLAP-Agent 110 kommuniziert mit der OLAP-Engine 112, und die OLAP-Engine 112 führt über den relationalen Speichermanager 114 Funktionen aus, um von einem Datenspeichermanager aus auf die mehrdimensionalen Daten zuzugreifen. In der Software Essbase OLAP von Hyperion Software werden Daten angefordert, indem ein oder mehrere verteilte Indexschlüssel angegeben werden (d. h. ein verteilter Indexschlüssel ist eine Kodierung eines Mitglieds aus jeder verteilten Dimension), die einen oder mehrere dichte Datenblöcke in der mehrdimensionalen Datenbank 300 bezeichnen.

In der vorliegenden Erfindung umfassen diese verteilten Indexschlüssel Kombinationen eines MemberId für jede verteilte Dimension, die intern in der Software Essbase OLAP von Hyperion Software verwendet wird. Der relationale Speichermanager 114 gibt an die OLAP-Engine 112 den Befehl aus, den verteilten Indexschlüssel zu trennen und auf eine Liste von MemberIds zu setzen. Der relationale Speichermanager 114 bildet die MemberIds über die betreffenden Nicht-Anker- Dimensionstabellen 414 und 416 in der relationalen Datenbank 118 ab auf die RelMemberIds, die in der relationalen Datenbank 118 verwendet werden. Danach werden die RelMemberIds verwendet, um auf die betreffenden Nicht-Anker- Dimensionstabellen 414 und 416 in der relationalen Datenbank 118 zuzugreifen. Die resultierenden Zeilen der Nicht-Anker- Dimensionstabellen 414 und 416 werden zu entsprechenden Zeilen in den Faktentabellen 402 bis 422 zusammengefasst.

Wie oben bereits angeführt wurde, enthält jede Faktentabelle mehrere Datenblöcke. Wenn das OLAP-Client-Programm 106 über den OLAP-Agent 110 und die OLAP-Engine 112 einen Befehl an die relationale Datenbank ausgibt, dann schreibt oder liest das OLAP-Client-Programm 106 Daten aus einem einzigen Datenblock. Wenn also der relationale Speichermanager 114 MemberIds auf RelMemberIds abbildet, bestimmt der relationale Speichermanager 114 auch, welche der Faktentabellen 402 bis 422 die Daten enthält, die dem Datenblock entsprechen, auf den zugegriffen werden soll. Es wird also nur auf eine der Faktentabellen 402 bis 422 zugegriffen, um auf einen Befehl zu antworten. Die Zeilen der ausgewählten Faktentabelle 402 bis 422, die somit die Kriterien der verteilten Indexschlüssel erfüllt, werden vom DB2-Server 116 an den relationalen Speichermanager 114 zurückgesendet.

Die zurückgesendeten Zeilen enthalten RelMemberIds, gefolgt von Werten für jedes der Mitglieder der Ankerdimension (z. B. der Dimension MEASURES 418 in Fig. 4). Der relationale Speichermanager 114 konvertiert daraufhin die RelMemberIds in MemberIds und formatiert die Zeilen aus der Faktentabelle 402 in einen dichten Datenblock um. Die umformatierten Zeilen werden an die OLAP-Engine 112 weitergeleitet, die zum Schluß die gewünschten Daten an den OLAP-Client 106 ausgibt.

Ein weiterer Vorteil des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung besteht darin, dass der relationale Speichermanager 114 eine Ansicht der Faktentabellen als einzelne Faktentabelle ermöglicht. Ein Benutzer kann eine individuell zugeschnittene Anwendung schreiben, um spezielle Informationen aus dieser Ansicht auszuwählen. Die individuell zugeschnittene Anwendung weiß deshalb nicht, dass die Daten auf mehrere Tabellen verteilt partitioniert wurden. Das heißt, um die individuell zugeschnittenen Anwendungen gegen diese Partitionierung von Daten abzuschirmen, erstellt der relationale Speichermanager 114 eine Ansicht der partitionierten Faktentabellen (d. h. "UNION SELECT"), die bei der Abfrage (SELECT) so aussieht und sich genauso verhält wie eine einzelne Faktentabelle. Darüber hinaus kommuniziert die individuell zugeschnittene Anwendung direkt mit dem DB2-Server 116 und muß nicht mit dem relationalen Speichermanager 114 kommunizieren. Um diese Ansicht bereitstellen zu können, wählt der relationale Speichermanager 114 alle Zeilen aus jeder Faktentabelle aus (SELECT) und verbindet die Zeilen in einer UNION-Operation, um eine Ansicht einer einzigen Faktentabelle zu erzeugen. Die Verwendung mehrerer Faktentabellen ist somit transparent.

Auf diese Weise können die relationalen Datenbanken 118 verwendet werden, um mehrdimensionale Daten in einer mehrdimensionalen Datenbank 300 zu emulieren. Darüber hinaus ist der DB2-Server 116 durch die Konvertierung zwischen den MemberIds der verteilten Indexschlüssel und den RelMemberIds in der Lage, die Daten in der relationalen Datenbank 118 als dichte Datenblöcke für die Software Essbase OLAP von Hyperion Software zu behandeln, während in Wirklichkeit die Daten in einer relationalen Datenbank 118 gehalten werden.

In einem anderen Ausführungsbeispiel werden die MemberIds und die RelMemberIds unter Verwendung zweier Speicher-Arrays aufeinander abgebildet. Das Array, das verwendet wird, um MemberIds auf RelMemberIds abzubilden, besitzt ein Element für jedes MemberId, das die entsprechende RelMemberId enthält. Das Array, das verwendet wird, um RelMemberIds auf MemberIds abzubilden, besitzt ein Element für jedes RelMemberId, das die entsprechende MemberId enthält. Diese Arrays werden erzeugt, nachdem die konzeptionelle Struktur erstellt wurde, und sie werden jedesmal, wenn der relationale Speichermanager 114 die mehrdimensionale Datenbank initialisiert oder "öffnet", sowie nach jeder Neustrukturierung eines Umrisses neu gebildet.

Im Modell einer mehrdimensionalen Datenbank der Software Essbase OLAP von Hyperion Software werden die dichten Datenblöcke der mehrdimensionalen Datenbank nach den numerischen Werten ihrer verteilten Indexschlüssel sortiert. In der vorliegenden Erfindung behält der relationale Speichermanager 114 die Reihenfolge der dichten Datenblöcke bei, indem er die verteilten Indexschlüssel in einer Schlüsseltabelle speichert. Der relationale Speichermanager 114 enthält zusätzliche Informationen zu jedem dichten Datenblock in der Schlüsseltabelle. Im einzelnen gehören zu diesen Informationen der Status (z. B. Nutzung) sowie Zeitstempel (z. B. Alter).

Änderungen der konzeptionellen Struktur

Wenn die konzeptionelle Struktur geändert wird, ändert sich auch der Inhalt der relationalen Datenbank 118. Insbesondere kann bei der Änderung eines Umrisses die Software Essbase OLAP von Hyperion Software die MemberIds für die in der konzeptionellen Struktur definierten Mitglieder ändern. Wenn dies geschieht, werden die MemberIds in den Dimensionstabellen 414, 416 und 418 entsprechend aktualisiert. Wird ein Mitglied aus der konzeptionellen Struktur gelöscht, wird die betreffende Zeile der Dimensionstabelle 414, 416 oder 418 durch Aktualisierung der MemberId und des MemberName zu NULL- Werten als verfügbar gekennzeichnet. Wenn ein Mitglied in der konzeptionellen Struktur eingefügt wird, wird für das Mitglied ein RelMemberId gesucht. Verwendet wird ein RelMemberId in einer verfügbaren Tabelle (d. h. ein RelMemberId, das einem MemberName mit einem NULL-Wert entspricht). Wenn kein solches RelMemberId verfügbar ist, wird für das neu hinzugefügte Mitglied ein neues RelMemberId angelegt.

Verbesserung der mehrdimensionalen Neustrukturierung beim Hinzufügen oder Entfernen von Dimensionen und Dimensionsmitgliedern

Ein bevorzugtes Ausführungsbeispiel der vorliegenden Erfindung stellt einen relationalen Speichermanager 114 bereit, der beim Hinzufügen von Nicht-Anker-Dimensionen oder Anker- Dimensionsmitgliedern oder beim Entfernen von Nicht-Anker- Dimensionen oder Anker-Dimensionsmitgliedern die mehrdimensionale Neustrukturierung verbessert. In den folgenden Beispielen bezeichnet der Begriff "Dimension" eine Nicht-Anker-Dimension, während eine Ankerdimension als Ankerdimension bezeichnet wird. Die bevorzugten Ausführungsbeispiele verbessern die Leistung und verringern die Wahrscheinlichkeit des Auftretens von Beschränkungen des Datenbankmanagers für einige Szenarien der Neustrukturierung, wie aus der nachfolgenden Beschreibung hervorgeht.

Für eine mehrdimensionale Datenbank gibt es mehrere Szenarien, in denen sehr viele Mitglieder, die jeweils Zeilen in einer Faktentabelle entsprechen, gelöscht werden. Aus diesem Grund gibt es mehrere Szenarien, in denen die damit zusammenhängenden Datenbankprobleme einer niedrigen Leistung und knapper Protokollkapazität auftreten. In einem Szenario beispielsweise wird eine Dimension (verteilt oder dicht) gelöscht. In einem anderen Szenario werden mehrere Dimensionsmitglieder gelöscht.

Fig. 5 ist ein Diagramm, das eine konzeptionelle Struktur 500 einer mehrdimensionalen Datenbank gemäß der vorliegenden Erfindung veranschaulicht. Die konzeptionelle Struktur 500 einer mehrdimensionalen Datenbank umfasst eine Regionsdimension 502, eine Produktdimension 520, eine Farbdimension 540 und eine Messgrößendimension 550. Die Mitglieder der Regionsdimension 502 sind folgende: Region 502, Nord 504, Süd 506, Ost 508 und West 510. Entsprechend sind die Mitglieder der Produktdimension folgende: Produkt 520, Schläger 522 und Ball 524. Die Mitglieder der Farbdimension 540 sind: Farbe 540, Rot 542 und Blau 544. Die Mitglieder der Messgrößendimension sind: Messgrößen 550, Umsatz 552 und Kosten 554.

Die nachstehende Tabelle 1 ist eine Faktentabelle, die der konzeptionellen Struktur von Fig. 5 entspricht, und wird in der nachfolgenden Beschreibung zugrunde gelegt.

In Tabelle 1 gibt es Spalten mit Daten für die Dimensionen Region, Produkt und Farbe. Des weiteren ist in diesem Beispiel die Dimension Messgrößen 550 eine Nicht-Anker-Dimension. Somit gibt es Spalten für die Mitglieder (Umsatz 552 und Kosten 554) der Ankerdimension Messgrößen 550. Zu beachten ist, dass Messgrößen auch ein Mitglied der Dimension Messgrößen 550 ist, aber das Mitglied Messgrößen hat keine entsprechende Spalte in Tabelle 1. Insbesondere kann eine Dimension verwendet werden, um eine Summe darzustellen (z. B. der Umsätze oder Kosten) oder eine Aufstellung zusammenzustellen (z. B. wenn eine Summe der Dimensionsmitglieder nicht sinnvoll ist). In diesem Beispiel wird die Dimension Messgrößen 550 als Aufstellung (Kennzeichnung) behandelt, die verwendet wird, um die Umsatz- und Kostenmitglieder zusammenzustellen. Der Fachmann auf diesem Gebiet erkennt jedoch, dass die Dimension Messgrößen 550 als Summe behandelt werden und eine Spalte in Tabelle 1 mit Daten, beispielsweise zur Summe der Umsätze oder Kosten, haben könnte. Ein weiteres Beispiel ist die letzte Zeile von Tabelle 1. Dort ist die Region als ein Elternteil aller Regionen eine Summe der anderen Regionen.

Außerdem gilt es zu beachten, dass die Spalte für die Dimension Zeit nicht in Verwendung ist. In diesem Beispiel wurde die Dimension Zeit in der konzeptionellen Struktur 500 gelöscht, und deshalb ist die Spalte für die Dimension Zeit nicht in Verwendung. Insbesondere gestatten es die meisten RDBMSs nicht, dass Spalten in einer Tabelle gelöscht werden. Wenn also eine Dimension gelöscht wird, wird die dazugehörige Spalte beibehalten. Dazu kommt, wenn eine Dimension (beispielsweise Zeit) aus der mehrdimensionalen Datenbank (z. B. Würfel) gelöscht wird, hat die mehrdimensionale Datenbank eine Dimension weniger, d. h. der Würfel wird zu einem Quadrat. Jedoch ergaben die Daten in der mehrdimensionalen Datenbank ursprünglich einen Sinn hinsichtlich der gelöschten Dimension (z. B. Umsatz von roten Schlägern in der nördlichen Region in einem bestimmten Zeitabschnitt). Wenn also eine Dimension gelöscht wird, werden die zu einem bestimmten Mitglied der Dimension gehörenden Daten beibehalten. Normalerweise werden die zu einem Elternteil oder einer Dimension selbst gehörenden Daten beibehalten (Daten, die beispielsweise zum Mitglied Zeit gehören, können beibehalten werden). In diesem Beispiel wurden die Daten, die zum Mitglied Zeit gehören, beibehalten, und deshalb gehören die Werte für die Spalte Zeit alle zu Zeit.

Wir fahren mit diesem Beispiel fort. In einem Szenario wird die Region Dimension 502 gelöscht. Wenn ein Benutzer eine Dimension löscht, dann bestimmt der Benutzer auch ein Dimensionsmitglied, das beibehalten wird. Wie oben bereits beschrieben wurde, bleibt die Spalte für Region in der Faktentabelle als Tabelle 1 abgebildet. In diesem Szenario löscht der relationale Speichermanager 114 alle Zeilen in der Tabelle außer diejenigen für das eine Mitglied in dieser Dimension, für das der Benutzer festgelegt hat, dass es beibehalten werden soll. Ein Benutzer gibt beispielsweise an, dass die Regionsdimension 502 gelöscht werden soll, während die Daten für das Regionsdimensionsmitglied 502 beibehalten werden sollen. Angesichts der Aufgabe, alle Daten außer den Daten des Regionsdimensionsmitglieds zu entfernen, besteht eine Lösung für den relationalen Speichermanager 114 darin, ein Statement SQL DELETE auszugeben, das alle Zeilen entfernt, die keine Region in der Regionsspalte enthalten (d. h. alle Zeilen für Nord, Süd, Ost und West), und die entsprechenden Änderungen in der Datenbank vorzunehmen. In bezug auf Tabelle 1 würde die letzte Zeile der Tabelle beibehalten werden, wie dies aus der folgenden Tabelle 2 hervorgeht:

In einem anderen Szenario werden die Dimensionsmitglieder Ost und West gelöscht. Wenn ein Benutzer zahlreiche Mitglieder aus einer Dimension herauslöscht, löscht der relationale Speichermanager 114 alle Zeilen in der Faktentabelle, die diesen Mitgliedern entsprechen. Angenommen, ein Benutzer löscht die Dimensionsmitglieder Ost und West 506 und 508, dann werden etwa 40% der Daten in der Faktentabelle gelöscht (nämlich die Daten für Ost und West).

Zwar ist diese Löschmethode einfach und funktioniert manchmal gut, doch sobald viele Mitglieder aus großen Tabellen herausgelöscht werden, verringert sich die Leistung der Löschmethode aufgrund der großen Mengen an gelöschten Zeilen und der für die Protokollierung benötigten CPU- und I/O- Ressourcen. Ein weiteres Problem, das mit dieser Löschmethode einhergeht, ist die Tatsache, dass die meisten RDBMS aufgrund der begrenzten Protokollierungskapazität in ihren Transaktionsmengen begrenzt sind. Eine RDBMS kann die Protokolldateigröße beispielsweise auf 2 Gigabytes beschränken. Wenn folglich mehr als 2 Gigabyte Protokollkapazität benötigt werden, um eine Transaktion aufzuzeichnen, schlägt die Transaktion fehl, sobald diese Protokolldateigröße überschritten wird.

Die Kopiermethode ist eine Lösung, die die Probleme einer geringeren Leistung vermeidet und gleichzeitig die Wahrscheinlichkeit verringert, dass die Protokollkapazität nicht ausreicht. Bei dieser Lösung erzeugt der relationale Speichermanager 114 eine neue Tabelle, die alle Spalten enthält, die aus der ursprünglichen Tabelle beibehalten werden sollen, sowie alle neuen Spalten, die hinzugefügt werden sollen. Danach legt der relationale Speichermanager 114 fest, dass keine Protokollierung erfolgen soll (sofern der Datenbankmanager diese Funktion unterstützt).

Beispielsweise kann das Statement NOT LOGGED INITIALLY vorhanden sein. Das Statement NOT LOGGED INITIALLY teilt der RDBMS 118 mit, dass die erste Transaktion einer Tabelle nicht protokolliert werden soll. Das heißt, wenn wir die erste Kopiertransaktion nicht protokollieren und die Transaktion fehlschlägt, dann kann die RDBMS die Transaktion einfach rückgängig machen, indem die Tabelle ignoriert wird, und dann ist kein Protokoll erforderlich. Verschiedene RDBMSs bieten unterschiedliche Methoden zur Beschränkung der Protokollierung an, die die Kopiermethode nutzen kann. Durch das Ausschalten der Protokollierung erhält das RDBMS 118 eine höhere Leistung, ohne dass dadurch die Integrität der Transaktionen beeinträchtigt wird. In diesem Sinne erstellt der relationale Speichermanager 114 die neue Tabelle mit dem Statement NOT LOGGED INITIALLY. Dies erhöht die Neustrukturierungsleistung, indem das RDBMS 118 davon abgehalten wird, die I/O- oder CPU- Ressourcen für eine Protokolldatei zu verwenden.

Wenn bei der Kopiermethode nur die Daten des Regionsdimensionsmitglieds 502 beibehalten werden sollen, kopiert der relationale Speichermanager 114 die Regionsdaten aus der ursprünglichen Tabelle in die neue Tabelle, indem er das Statement INSERT mit einer Unterauswahl verwendet. Diese Art von INSERT-Statement ermöglicht Verschiebungen zwischen zwei Tabellen und macht es überflüssig, Daten in einer ursprünglichen Tabelle zu suchen, die Daten im Speicher einer Anwendung zu speichern und die Daten aus dem Speicher in eine neue Tabelle zu verschieben. Der relationale Speichermanager 114 nimmt die Änderungen in der Datenbank vor. Als nächstes löscht der relationale Speichermanager 114 die ursprüngliche Tabelle. Zum Schluß gibt der relationale Speichermanager der neuen Tabelle den ursprünglichen Namen.

Diese Vorgehensweise hat mehrere Vorteile. Erstens wird die Leistung erhöht. Angenommen, die Daten sind gleichmäßig auf Regionen verteilt (z. B. Regionen Nord, Süd, Ost und West). Wenn alle Daten außer denen für "Region" mit der Löschmethode aus der Datenbank gelöscht werden, sind 80% der Daten gelöscht. Werden jedoch nur die Daten für "Region" kopiert, werden nur 20% der Daten mit der Kopiermethode der vorliegenden Erfindung kopiert. Das heißt, durch Reduzierung der manipulierten Datenmenge wird die Leistung erhöht. Zweitens, wenn sich das Kopieren ohne Protokollierung durchführen läßt, werden die erforderlichen CPU- und I/O- Ressourcen reduziert, und das Problem der Begrenzung der RDBMS-Protokolldateigröße wird vermieden.

In einem anderen Szenario werden die Dimensionsmitglieder Ost und West 506 und 508 gelöscht. In diesem Fall heißt das, wenn der relationale Speichermanager 114 die Kopiermethode verwendet, werden etwa 60% der Daten (also für die Region Nord und Süd) kopiert, und wenn er die Löschmethode verwendet, werden etwa 40% der Daten (also für Ost und West) gelöscht.

Wenn eine Dimension gelöscht wird, wird ihre dazugehörige Spalte in der Faktentabelle nicht mehr verwendet. Eine häufige RDBMS-Beschränkung ist, dass Spalten aus relationalen Tabellen nicht gelöscht werden können. Deshalb bleibt bei der Löschmethode die nicht verwendete Spalte in der Tabelle erhalten. Bei der Kopiermethode ist das Statement CREATE TABLE, das die neue Faktentabelle erstellt, so aufgebaut, dass die neue Faktentabelle die unnötigen Spalten nicht enthält. Das spart Platz in der Datenbank, wenn die neue Faktentabelle verwendet wird, und verringert die Anzahl der Daten, die für jede Zeile verändert wird.

Wenn darüber hinaus eine Dimension in eine mehrdimensionale Datenbank eingefügt wird, muß die Faktentabelle in der relationalen Datenbank um eine Spalte ergänzt werden, und der Benutzer muß ein Mitglied für diese Dimension angeben, mit dem die aktuellen Daten im Würfel verbunden werden sollen. Fig. 6 ist ein Diagramm, das eine konzeptionelle Struktur einer mehrdimensionalen Datenbank gemäß der vorliegenden Erfindung veranschaulicht. Die konzeptionelle Struktur 600 ähnelt der konzeptionellen Struktur 500 (Fig. 5), außer dass eine andere Dimension hinzugefügt wurde. Genauer gesagt wurde eine Kanaldimension 602 mit den Dimensionsmitgliedern Kanal 602, Versandbestellung 604 und Partner 606 hinzugefügt. Sobald die Kanaldimension 602 hinzugefügt wurde, wird die Faktentabelle in der relationalen Datenbank (dargestellt in Tabelle 3) entsprechend angepaßt.

Wenn ein Ankerdimensionsmitglied hinzugefügt wird, muß in die Faktentabelle der relationalen Datenbank eine Spalte eingefügt werden, und der relationale Speichermanager 114 weist die RDBMS an, alle auf diese Weise neu hinzugefügten Spalten mit NULL-Werten zu initialisieren. Es ist zu beachten, dass, wenn ein Mitglied einer Nicht-Anker-Dimension hinzugefügt wird, keine neue Spalte in die Faktentabelle eingefügt werden muß. Wenn diesem Mitglied Daten zugeordnet werden, führt das dazu, dass der Faktentabelle Zeilen hinzugefügt werden.

Wenn bei der Löschmethode eine Kanaldimension hinzugefügt würde, würde der relationale Speichermanager 114 die neue Spalte in die Faktentabelle einfügen und ihre Zeilen mit dem Identifyer, der das angegebene Mitglied darstellt, initialisieren. Das führt dazu, dass jede Zeile in den Faktentabellen bearbeitet und von der RDBMS protokolliert wird. Die untenstehende Tabelle 3 ist eine Faktentabelle, die der konzeptionellen Struktur von Fig. 6 entspricht, wenn die Löschmethode verwendet wird.

Tabelle 3

In der Tabelle gibt es Spalten mit Daten für die Dimensionen Region, Produkt, Farbe und Kanal. Die Spalte für die Dimension Zeit ist nicht in Verwendung, jedoch ist für jede Zeile in der Tabelle ein Mitglied angegeben. Darüber hinaus ist die Dimension 550 Messgröße in diesem Beispiel eine Ankerdimension, und deshalb besitzen Umsatz und Kosten in der Tabelle eigene Spalten. Die Dimension Kanal 602 bewirkt, dass in die Tabelle mit einem angegebenen Mitglied eine Spalte eingefügt wird. Das heißt, bevor die Dimension Kanal 602 eingefügt wird, wurden die Daten in der mehrdimensionalen Datenbank einem Kanal zugeordnet, und deshalb werden alle Daten der mehrdimensionalen Datenbank nach dem Einfügen der Dimension Kanal 602 diesem Kanal zugeordnet. Für dieses Beispiel wurde das Partnermitglied angegeben.

Wenn bei der Kopiermethode eine Kanaldimension hinzugefügt würde, würde der relationale Speichermanager 114 die neue Spalte in die Faktentabelle(n) einfügen und die entsprechende Spalte in den Faktentabelle(n) mit dem Identifyer, der das angegebene Mitglied darstellt, initialisieren. Das führt dazu, dass jede Zeile in den Faktentabellen bearbeitet und von der RDBMS protokolliert wird. Die obenstehende Tabelle 3 ist eine Faktentabelle, die der konzeptionellen Struktur von Fig. 6 entspricht, wenn die Löschmethode verwendet wird. Das Statement SELECT INTO, das in den neuen Faktentabellen enthalten ist, kann so aufgebaut werden, dass jede Spalte, die einer neu hinzugefügten Dimension entspricht, automatisch mit dem passenden Identifyer für das angegebene Mitglied initialisiert wird. Die nachstehende Tabelle 4 ist eine Faktentabelle, die der konzeptionellen Struktur von Fig. 6 entspricht, wenn die Kopiermethode verwendet wird.

Tabelle 4

Tabelle 4 ähnelt Tabelle 3, jedoch ist die nicht in Verwendung befindliche Spalte für die Dimension Zeit nicht enthalten, was Speicherplatz einspart. Die Kopiermethode spart nicht nur Speicherplatz, der sonst von gelöschten Dimensionen und Mitgliedern eingenommen wird, sondern gewährleistet, dass der relationale Speichermanager 114 stets genügend Spalten zur Verfügung hat und keine Spaltenfehlzuordnungen auftreten. Insbesondere gibt es für jedes RDBMS eine begrenzte Anzahl von Spalten, die für eine Tabelle definiert werden können. Ein RDBMS läßt es im allgemeinen nicht zu, dass der Datentyp einer Spalte verändert wird. Da das bevorzugte Ausführungsbeispiel des relationalen Speichermanagers 114 der vorliegenden Erfindung andere Datentypen für Dimensionsspalten (z. B. 4- Byte-Ganzzahlen) und Mitgliedsspalten für Ankerdimensionen (z. B. 8-Byte-GLEITKOMMA) verwendet, wird die Anzahl der Dimensionen und Ankerdimensionsmitglieder mit der Löschmethode manchmal künstlich begrenzt. Wenn beispielsweise die RDBMS nur 255 Spalten pro Tabelle unterstützt, ist ein Modell mit fünf Dimensionsspalten und 245 Mitgliedsspalten von Ankerdimensionen leicht in der Lage, fünf weitere Dimensionen aufzunehmen. Wenn jedoch die 245 Mitgliedsspalten von Ankerdimensionen das Ergebnis einer Reduzierung der Ankerdimensionsmitglieder von 250 auf 245 sind, gibt es fünf nicht verwendete Spalten des falschen Datentyps, womit es nicht mehr möglich wäre, weitere Dimensionsspalten hinzuzufügen.

Bei der Kopiermethode enthält das SQL-Statement, das erzeugt wird, um Daten aus der ursprünglichen in die neue Tabelle zu kopieren, eine WHERE-Bedingung (als Bestandteil einer Unterbedingung), die Daten ausschließt, die nicht kopiert werden sollen. Diese Bedingung gibt beispielsweise an, dass Daten, die gelöschten Mitgliedern entsprechen, nicht kopiert werden sollen. Normalerweise reicht diese eine SQL-Bedingung aus, um festzustellen, welche Daten genau nicht kopiert werden sollen. Wird jedoch eine große Anzahl an Mitgliedern gelöscht, überschreitet die erzeugte SQL-Bedingung die maximale Größe der SQL-Bedingung für das RDBMS. Um dazu in der Lage zu sein, erzeugt der relationale Speichermanager 114 eine SQL- Bedingung, die möglichst viele Daten ausschließt, ohne die Größenbeschränkung der SQL-Bedingung zu überschreiten (d. h. die maximale Anzahl an Zeichen, die in einer SQL-Bedingung enthalten sein können), Einige unerwünschte Daten werden in die neue Tabelle kopiert. Sobald diese Daten in die neue Tabelle kopiert wurden, entfernt der relationale Speichermanager 114 diese außerhalb liegenden Daten mit Hilfe der Bedingung DELETE SQL.

Fig. 7 ist ein Flußdiagramm, das die Schritte veranschaulicht, die bei der Verwendung der Kopiermethode vom relationalen Speichermanager 114 ausgeführt werden. In Block 700 empfängt der relationale Speichermanager 114 eine Information, dass eine oder mehrere Nicht-Anker-Dimensionen oder Nicht-Anker-Dimensionsmitglieder gelöscht wurden oder dass eine oder mehrere Nicht-Anker-Dimensionen oder Anker- Dimensionsmitglieder hinzugefügt wurden. Es kann beispielsweise eine Nicht-Anker-Dimension gelöscht werden, oder ein Nicht-Anker-Dimensionsmitglied kann gelöscht werden, oder eine Nicht-Anker-Dimension kann hinzugefügt werden, oder ein Anker-Dimensionsmitglied kann hinzugefügt werden, oder es kann eine Kombination aus Lösch- und Einfügeoperationen stattfinden.

In Block 702 erstellt der relationale Speichermanager 114 eine neue Tabelle. Er verwendet dabei alle Spalten, die aus der ursprünglichen Tabelle beibehalten werden sollen, sowie alle neuen Spalten, die für neue Dimensionen und Ankerdimensionsmitglieder hinzugefügt werden sollen. Das heißt, Spalten, die nicht in Verwendung sind (wenn also dazugehörige Dimensionen oder Dimensionsmitglieder gelöscht wurden), werden nicht in die neue Tabelle aufgenommen. Die neue Tabelle enthält außerdem solche Spalten, die den hinzugefügten Dimensionen und Ankerdimensionsmitgliedern entsprechen. In Block 704 gibt der relationale Speichermanager 114 an, dass keine Protokollierung erfolgen soll. Zu beachten ist, dass in Systemen, in denen diese Option nicht zur Verfügung steht, der relationale Speichermanager 114 diesen Schritt nicht ausführt. In Block 706 fügt der relationale Speichermanager 114 unter Verwendung der Bedingung INSERT Daten aus der ursprünglichen Tabelle in die neue Tabelle ein und initialisiert alle neu hinzugefügten Spalten mit entsprechenden Kennungen (Identifyern). Im einzelnen wird eine Bedingung WHERE im Statement INSERT verwendet, um Zeilen in die neue Faktentabelle zu kopieren. Bei Vorhandensein mehrerer Faktentabellen läßt sich die Bedingung WHERE parallel an mehreren Faktentabellen ausführen, wie aus der nachfolgenden Beschreibung unter Verweis auf Fig. 10 hervorgeht. Außerdem läßt sich die Bedingung WHERE auch mit anderen Operationen (z. B. Hashing) kombinieren, woraus zusätzliche Vorteile erwachsen.

In Block 708 stellt der relationale Speichermanager 114 fest, ob nur die erforderlichen Daten kopiert wurden, ohne eine Größenbegrenzung der Bedingung SQL zu überschreiten. Wenn nur die erforderlichen Daten kopiert wurden, ohne eine Größenbegrenzung der Bedingung SQL zu überschreiten, fährt der relationale Speichermanager 114 fort an Block 712, ansonsten fährt der relationale Speichermanager 114 fort an Block 710. In Block 710 löscht der relationale Speichermanager 114 unnötige Daten in der neuen Tabelle. In Block 712 nimmt der relationale Speichermanager 114 die Änderungen in der Datenbank vor. In Block 714 löst sich der relationale Speichermanager 114 von der ursprünglichen Tabelle. In Block 716 benennt der relationale Speichermanager 114 die ursprüngliche Tabelle in den ursprünglichen Tabellennamen um.

Die in den Blöcken 700-714 von Fig. 7 dargestellten Schritte werden als eine einzige Arbeitseinheit betrachtet. Somit findet der für Block 710 beschriebene Schritt auf Anwendungsebene statt. Die Methoden, die eingesetzt werden, um Schritte auf Anwendungsebene durchzuführen, werden in den oben angegebenen Anwendungen näher beschrieben. Sie haben folgende Titel: "EXTENSION OF DATA DEFINITION LANGUAGE (DDL) CAPABILITIES FOR RELATIONAL DATABASES FOR APPLICATIONS ISSUING DDL STATEMENTS", angemeldet am 19. Juli 1999 von Daniel M. DiKimpe et al., Anwaltsaktenzeichen ST9-99-081; "EXTENSION OF DATA DEFINITION LANGUAGE (DDL) CAPABILITIES FOR RELATIONAL DATABASES FOR APPLICATIONS ISSUING DDL AND DML STATEMENTS", angemeldet am 19. Juli 1999 von Daniel M. DiKimpe et al., Anwaltsaktenzeichen ST9-99-095; und "EXTENSION OF DATA DEFINITION LANGUAGE (DDL) CAPABILITIES FOR RELATIONAL DATABASES FOR APPLICATIONS ISSUING MULTIPLE UNITS OF WORK", angemeldet am 19. Juli 1999 von Daniel M. DiKimpe et al., Anwaltsaktenzeichen ST9-99-103.

Im Einzelfall hängt die Frage, ob die Kopiermethode oder die Löschmethode schneller ist, davon ab, welcher prozentuale Anteil von Zeilen gelöscht und welcher Datenbankmanager verwendet wird. Zu diesem Zweck stellt der relationale Speichermanager 114 fest, welche dieser Methoden schneller ist, und verwendet dann die entsprechende Methode.

Im Einzelfall wählt der relationale Speichermanager 114 die Kopiermethode, wenn Dimensionen oder Ankerdimensionsmitglieder hinzugefügt werden. In diesen Fällen muß der relationale Speichermanager 114 auf jede Zeile der Tabelle zugreifen, um jeder Dimension den jeweiligen Identifyer hinzuzufügen oder um jedem Ankerdimensionsmitglied einen NULL-Wert hinzuzufügen.

Darüber hinaus können nicht verwendete Spalten, die zu Dimensionen oder Ankerdimensionsmitgliedern gehören, bei der Kopiermethode wiederverwendet werden. In diesem Fall muß der relationale Speichermanager 114 auf jede Zeile der Tabelle zugreifen, um jeder Dimension den jeweiligen Identifyer hinzuzufügen oder um jedem Ankerdimensionsmitglied einen NULL- Wert hinzuzufügen.

Beim Löschen von Nicht-Anker-Dimensionen oder Nicht-Anker- Dimensionsmitgliedern analysiert der relationale Speichermanager 114 die Änderung des Umrisses und stellt fest, ob es schneller wäre, Zeilen aus der aktuellen Faktentabelle zu löschen, oder ob es schneller wäre, eine neue Faktentabelle zu erstellen und die aufrecht zu erhaltenden Daten in die neue Faktentabelle zu kopieren. Jetzt stellt der relationale Speichermanager 114 fest, welcher prozentuale Anteil an Zeilen gelöscht wird. Liegt der zu löschende prozentuale Anteil an Zeilen unter einem bestimmten Schwellenwert, verwendet der relationale Speichermanager 114 die Löschmethode und löscht die Zeilen aus der Tabelle. Wird der Schwellenwert erreicht, verwendet der relationale Speichermanager 114 die Kopiermethode. In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung wurde der Schwellenwert festgestellt, indem beide Methoden gemessen wurden, um festzustellen, wann die Kopiermethode und wann die Löschmethode schneller ist. Der Fachmann auf diesem Gebiet weiß jedoch, dass dieser Schwellenwert auch anders festgesetzt werden kann.

Jetzt schätzt der relationale Speichermanager 114, wieviele Daten in der Faktentabelle verbleiben, indem er zuerst schätzt, wieviel Prozent der Daten für jede Dimension beibehalten werden. Wenn eine Dimension gelöscht wird, folgt daraus, dass die Daten für alle Mitglieder aus der Dimension gelöscht werden, mit Ausnahme der Daten für das angegebene Mitglied. In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung schätzt der relationale Speichermanager 114, dass die für eine Dimension verbleibenden Daten, die gelöscht werden, gleich 1/N sind, wobei N für die Anzahl der Mitglieder in einer Dimension steht. Die Dimension Region hat beispielsweise fünf Mitglieder (also Region, Nord, Süd, Ost, West). Wird die Dimension Region gelöscht, schätzt der relationale Speichermanager 114, dass ein Fünftel der Daten in der Faktentabelle verbleiben. Das Produkt aus der Anzahl der Mitglieder in jeder gelöschten Dimension wird gleich R gesetzt. Wenn beispielsweise eine Dimension mit fünf Mitgliedern und eine weitere Dimension mit drei Mitgliedern gelöscht werden, dann ist R = 5 mal 3 = 15. Dann ist die Datenmenge, die für alle gelöschten Dimensionen übrig bleibt, gleich 1/R, was auch als Dimensionsschätzung bezeichnet wird und die im vorliegenden Beispiel gleich 1/15 ist.

Wenn Nicht-Anker-Dimensionsmitglieder gelöscht werden, dann schätzt der relationale Speichermanager 114 die verbleibenden Daten, indem er die Anzahl der verbleibenden Mitglieder durch die ursprüngliche Anzahl der Mitglieder teilt. Wenn beispielsweise 3 von 10 Mitgliedern aus einer Nichtankerdimension herausgelöscht werden, verbleiben 7 Mitglieder. Das bedeutet, 70% bleiben übrig.

Als nächstes multipliziert der relationale Speichermanager 114 den für jede Dimension verbleibenden prozentualen Anteil der Daten. Das geschieht, weil das Löschen der Zeilen kumulativ ist. Wenn 50% der Mitglieder einer Dimension gelöscht werden, dann bleiben nur 50% der ursprünglichen Daten der Tabelle übrig. Werden dann jedoch 50% der Mitglieder einer zweiten Dimension ebenfalls gelöscht, dann bleiben nur 50% der verbleibenden Daten der Tabelle übrig, d. h. nur 25% der ursprünglichen Daten bleiben übrig.

Die nachstehende Tabelle 5 veranschaulicht diese Kalkulation:

Werden 2 Mitglieder von Dimension 1 und 4 Mitglieder von Dimension 3 gelöscht, so sind die in der Tabelle verbleibenden Daten = 0,80.1,00.0,60.1,00 = 0,48 (d. h. 48% der ursprünglichen Daten).

Darüber hinaus bestimmt der relationale Speichermanager 114, ob er die Kopiermethode oder die Löschmethode anwendet, indem er die Anzahl nicht verwendeter Spalten in der Tabelle ermittelt. Wenn beispielsweise zahlreiche nicht verwendete Spalten gibt, bestimmt der relationale Speichermanager 114, dass es besser ist, die Kopiermethode zu verwenden, weil die neue Tabelle keine nicht verwendeten Spalten enthält, was Speicherplatz spart und den Umfang der Daten reduziert, die vom RDBMS in späteren Tabellenoperationen bearbeitet werden. Wenn es nur wenige nicht in Verwendung befindliche Spalten in der Tabelle gibt, entscheidet der relationale Speichermanager 114, dass die Löschmethode verwendet werden kann.

Die Fig. 8A und 8B sind Flußdiagramme, in denen die Schritte veranschaulicht werden, die der relationale Speichermanager 114 durchläuft, wenn er entscheidet, ob er die Kopiermethode oder die Löschmethode einsetzt. In Block 800 stellt der relationale Speichermanager 114 fest, ob irgendwelche Dimensionen oder Ankerdimensionsmitglieder hinzugefügt wurden. Wenn ja, fährt der relationale Speichermanager 114 bei Block 802 fort, ansonsten fährt der relationale Speichermanager 114 bei Block 804 fort.

In Block 802 stellt der relationale Speichermanager 114 fest, ob die Summe der Nicht-Anker- und Ankerdimensionsmitglieder geringer oder gleich einer RDBMS-Spaltengrenze ist. Wenn ja, fährt der relationale Speichermanager 114 bei Block 816 fort und verwendet die Kopiermethode, ansonsten fährt der relationale Speichermanager 114 bei Block 818 fort und meldet, dass die Umstrukturierung nicht erfolgreich war. Wenn Dimensionen oder Ankerdimensionsmitglieder hinzugefügt wurden, fügt 114 eine neue Spalte in die Faktentabelle ein und initialisiert in jeder Zeile die Spaltenwerte für die eingefügte Spalte auf NULL. Da zur Initialisierung der Spaltenwerte auf NULL ein Zugriff auf jede Zeile der Tabelle erforderlich ist, entscheidet der relationale Speichermanager 114, dass die Kopiermethode besser geeignet ist als die Löschmethode. Ist jedoch die für eine neue Tabelle erforderliche Anzahl von Spalten höher als die Spaltengrenze des RDBMS, kann die neue Tabelle nicht erstellt werden, und die Umstrukturierung (d. h. das Einfügen von Dimensionen oder Ankerdimensionsmitgliedern) ist nicht erfolgreich.

Wir fahren mit dem Flußdiagramm fort. In den Blöcken 804 bis 810 schätzt der relationale Speichermanager 114 die verbleibende Datenmenge, nachdem eine oder mehrere Nicht- Anker-Dimensionen oder Dimensionsmitglieder gelöscht wurden. In Block 804 multipliziert der relationale Speichermanager 114 die Anzahl der Mitglieder in jeder gelöschten Dimension, was in einem Wert R resultiert. Wenn beispielsweise die Dimension Region (mit 5 Mitgliedern) und die Dimension Produkt (mit 3 Mitgliedern) gelöscht würden, ergäbe sich R = 5 mal 3 = 15 (d. h. R = 3.5 = 15).

In Block 806 häuft der relationale Speichermanager 114 einen prozentualen Anteil der Mitglieder an, die für jede Dimension mit gelöschten Mitgliedern aufrechterhalten werden. Das resultiert in einem Wert 5, der auch als Dimensionsmitgliedsschätzung bezeichnet wird. Das heißt, S ist das Produkt des prozentualen Anteils von Mitgliedern, die für jede Dimension aufrechterhalten werden, in der Mitglieder gelöscht wurden. Die Ankerdimensionsmitglieder sind hier nicht enthalten, da sie Spalten betreffen und sich nicht darauf auswirken, ob sich die Anzahl der Zeilen sich ändert. In Block 808 wird der gesamte prozentuale Anteil von Mitgliedern, die in einer Tabelle aufrechterhalten werden, berechnet, was in einem Wert T resultiert. T entspricht S geteilt durch R (d. h. S/R).

In Block 810 stellt der relationale Speichermanager 114 fest, ob T unterhalb eines Schwellenwerts liegt. Liegt T unterhalb eines Schwellenwerts, fährt der relationale Speichermanager 114 bei Block 816 fort und verwendet die Kopiermethode. Ansonsten fährt der relationale Speichermanager 114 bei Block 812 fort.

In Block 812 prüft der relationale Speichermanager 114, wieviele Spalten nicht in Verwendung sind. Sind viele Spalten nicht in Verwendung, fährt der relationale Speichermanager 114 bei Block 818 fort und verwendet die Kopiermethode. Sind nur wenige Spalten nicht in Verwendung, fährt der relationale Speichermanager 114 bei Block 814 fort und verwendet die Löschmethode. Der Fachmann auf diesem Gebiet weiß, dass die großen und kleinen Werte mit unterschiedlichen Methoden ermittelt werden können. Der prozentuale Anteil beispielsweise kann vom Benutzer ausgewählt werden, möglicherweise auf der Grundlage der bisherigen Zugriffe usw. Der prozentuale Anteil ist davon abhängig, in welchem Umfang die mehrdimensionale Datenbank vor der nächsten Umstrukturierung verwendet wird.

Zwar beziehen sich die obigen Beispiele auf eine einzelne Tabelle, doch läßt sich das Verfahren der vorliegenden Erfindung auch auf mehrere Tabellen anwenden. Wenn die mehrdimensionale Datenbank mehrere Faktentabellen hat, werden mehrere Threads (einer pro Tabelle) und mehrere Verbindungen (einer pro Tabelle) verwendet, um die neuen Tabellen zu erstellen und zu füllen.

Wie aus der obigen Beschreibung in bezug auf Fig. 4 hervorgeht, umfasst in einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung das Sternschema N Faktentabellen, die mit mehreren Dimensionstabellen verbunden sind. Jede Faktentabelle enthält die Daten für mehrere Datenblöcke. Darüber hinaus enthält eine Schlüsseltabelle Informationen über die Datenblöcke. Im einzelnen bestehen diese Informationen aus Statusangaben (Angaben zur Nutzung), Zeitstempeln (Altersangaben) und einem Blockschlüssel (d. h. der spärliche Indexschlüssel, der aus Mitgliederkennungen besteht). Wenn eine neue mehrdimensionale Datenbank erstellt wird, erstellt der relationale Speichermanager 114 die N Faktentabellen des Sternschemas. Durch die Erstellung der N Faktentabellen ist der relationale Speichermanager 114 in der Lage, Operationen in den N Faktentabellen und der separaten Schlüsseltabelle parallel auszuführen, was eine effizientere Datenbankverarbeitung zur Folge hat. Insbesondere ist der relationale Speichermanager 114 mit der Kopiermethode in der Lage, neue Faktentabellen zu erstellen und parallel dazu unter Verwendung von Threads Daten in sie zu kopieren. In einem anderen Ausführungsbeispiel kann das Sternschema aus einer Faktentabelle, mehreren Dimensionstabellen und einer Schlüsseltabelle bestehen. In diesem Szenario ist ein paralleler Zugriff auf Faktentabelle und Schlüsseltabelle möglich, was zu einer effizienteren Verarbeitung führt.

Der relationale Speichermanager 114 verwendet bei der Durchführung von Eingabe-/Ausgabeoperationen (z. B. INSERT) gleichzeitige Threads mit separaten Datenbankverbindungen. Die Anwendungen (z. B. das Client-Programm OLAP, 106) senden verschiedene Befehle aus, nämlich einen an jeden Thread. Am Anfang erzeugt der relationale Speichermanager 114 für jede Sitzung, die vom OLAP-Rechner 112 gestartet wurde, einen einzelnen Thread mit einer einzelnen Verbindung zur relationalen Datenbank. Der OLAP-Rechner 112 beginnt eine Sitzung für jede Anwendung, die Befehle an den OLAP-Rechner 112 sendet. Wenn beispielsweise vier Anwendungen Befehle an den OLAP-Rechner 112 senden, erzeugt der relationale Speichermanager 114 vier separate Threads, von denen jeder eine andere Verbindung aufweist.

Wenn der relationale Speichermanager am Anfang einen Befehl erhält, nur Daten zu lesen, verwendet der relationale Speichermanager 114 den einzelnen Thread, um die Daten in den Faktentabellen und in der Schlüsseltabelle zu lesen. Wenn der relationale Speichermanager einen Befehl erhält, nur Daten zu schreiben, erzeugt der relationale Speichermanager 114 mehrere Threads (nämlich einen für jede Faktentabelle und die Schlüsseltabelle) mit mehreren Verbindungen (nämlich einen für jede Faktentabelle und die Schlüsseltabelle).

Eine Verbindung beruht auf dem Konzept einer relationalen Datenbank. Dieses Konzept sieht vor, eine Anwendung zu befähigen, Befehle an die relationale Datenbank zu senden. Ein Thread ist ein Konzept eines Betriebssystems, in dem ein Programmteil unabhängig von anderen Programmteilen ausgeführt werden kann. Betriebssysteme, die Multi-Threading unterstützen, ermöglichen es Programmierern, Programme zu entwickeln, deren Thread-haltige Programmteile gleichzeitig ausgeführt werden können.

Um gleichzeitige Operationen zu ermöglichen, verwendet der relationale Speichermanager 114 N unabhängige Threads, um auf N Faktentabellen zuzugreifen, und einen weiteren Thread, um auf die Schlüsseltabelle zuzugreifen. Jeder Thread erhält eine RDBMS-Verbindung zu genau einer der Tabellen aufrecht (d. h. zu den Faktentabellen und zur Schlüsseltabelle). Dadurch kann der relationale Speichermanager 114 gleichzeitig in mehrere Blöcke schreiben.

Der relationale Speichermanager 114 verwendet eine Hashing- Funktion (eine Funktion zur Aufteilung) auf der Grundlage von Dimensionskennungen, um festzustellen, in welcher Faktentabelle Zeilen gespeichert werden sollen. In dieser Erfindung wird die Hashing-Funktion zur Bedingung WHERE des Statements INSERT, das verwendet wird, um Zeilen in die neuen Faktentabellen zu kopieren, hinzugefügt.

Fig. 9 ist ein Blockdiagramm, das das Einfügen von Tabellen durch Verwendung mehrerer Tabellen oder mehrerer Threads veranschaulicht. Im folgenden Beispiel schreibt der OLAP- Client 106 Daten in die Faktentabellen 920 (d. h. er kopiert sie oder fügt sie ein). Wie aus der Darstellung in Fig. 9 hervorgeht, erhält der relationale Speichermanager 900 im Speicher einen Cache 910 aufrecht. Des weiteren werden die Faktentabellen 920, die Nicht-Anker-Dimensionstabellen 924, die Ankerdimensionstabelle 926 und die Schlüsseltabelle 916 im permanenten Speicher gespeichert.

Wenn Daten geschrieben werden sollen, werden am Anfang ein Datenblock und sein spärlicher Indexschlüssel von einem Rechner für die mehrdimensionale Datenbank (MDCE) (der Teil des OLAP-Rechners 112 ist) an den relationalen Speichermanager 900 gesendet, wo diese in den permanenten Speicher geschrieben werden. Dieser MDCE greift immer auf einen Datenblock für eine Transaktion zu, wobei ein Datenblock den Daten in einer Faktentabelle entspricht. Zu beachten ist, dass der MDCE meherere Befehle von verschiedenen Anwendungen empfängt. Der MD 08108 00070 552 001000280000000200012000285910799700040 0002010039537 00004 07989CE verwendet einen separaten Thread für jeden Befehl, wenn er mit dem relationalen Speichermanager 114 kommuniziert. Wenn der MDCE jedoch Daten für eine Anwendung anfordert, unterbricht der MDCE die Verarbeitung für diese Anwendung, bis alle Daten eingegangen sind. Nach dem Empfang eines Befehls vom MDCE kopiert der relationale Speichermanager 900 die gewünschten Daten in einen speicherresidenten Cache 910 und gibt die Steuerung zurück an den MDCE.

Der Cache 910 enthält Faktentabellendaten 912 sowie Schlüsseltabellendaten 914. Die Daten 912 enthalten Daten aus den Faktentabellen 920, die als Antwort auf eine Datenanfrage des OLAP-Client 106 zur Verfügung gestellt werden. Diese Daten gibt der relationale Speichermanager 900 an den OLAP-Rechner 112 aus, der wiederum die Daten an den OLAP-Client 106 weitersendet. Zusätzlich können die Daten 912 solche Daten enthalten, die in die Faktentabellen 920 geschrieben werden sollen.

Die Schlüsseltabellendaten 914 enthalten Einträge, wobei jeder Eintrag Statusangaben (Angaben zur Nutzung), Zeitstempel (Altersangaben) und einen Blockschlüssel (d. h. der spärliche Indexschlüssel, der aus Mitgliederkennungen besteht), enthält. Der Blockschlüssel ist ein spärlicher Indexschlüssel, der eine Kombination einer Mitgliederkennung für jede spärliche Dimension umfasst, die intern in der Software Essbase OLAP von Hyperion Software verwendet wird.

Nachdem der MDCE einen Befehl zur Datenübertragung (d. h. zum Kopieren von Daten aus dem Cache in die relationale Datenbank) ausgibt oder wenn ein vorbestimmter Datenumfang für die Faktentabellen in den Cache geschrieben wurde (d. h. es sind "schmutzige" oder geänderte Datenblöcke im Cache), wird eine Gruppe von Datenblöcken ausgewählt, die in die Faktentabellen 920 geschrieben werden sollen. Eine Hashing-Funktion stellt fest, welche Zeilen entsprechend den Datenblöcken in welcher der N Faktentabellen enthalten sein sollen. Die Gruppe der spärlichen Dimensionskennungen, die in einer Hashing-Funktion verwendet werden, können vom spärlichen Indexschlüssel, der einen Datenblock kennzeichnet, abgeleitet werden. Die Hashing- Funktion bildet die Mitgliederkennungen des spärlichen Indexschlüssels auf RelMemberIds ab, fügt diese RelMemberIds hinzu und paßt N entsprechend an. Dadurch ist es jedem der N Threads 922, die Daten in die und aus den Faktentabellen 920 verschieben, möglich, festzustellen, in welche Zeilen der entsprechenden Faktentabelle 920 geschrieben werden soll. Darüber hinaus wird der Thread 918 verwendet, um parallel zu den N Threads 922 entsprechend der Zeilen die Einträge der Schlüsseltabelle 916 zu manipulieren. Auf diese Weise werden Daten unter Verwendung der N Threads 922 und des Threads 918 gleichzeitig in die relationale Datenbank geschrieben.

Wenn also der MDCE angibt, dass eine Transaktion ausgeführt werden soll, werden alle Cache-Daten, die nicht in eine der Faktentabellen 920 geschrieben wurden, in die entsprechenden Faktentabellen 920 und in die Schlüsseltabelle 916 geschrieben, und das RDBMS 118 erhält den Befehl, alle empfangenen Daten zu übertragen. Entsprechend gilt, dass, wenn eine vorbestimmte Anzahl "schmutziger" Datenblöcke im Cache ist, diese Datenblöcke in die entsprechenden Faktentabellen 920 und in die Schlüsseltabelle 916 geschrieben werden.

Diese Zuordnung mehrerer Threads, von denen jeder seine eigene Datenbankverbindung aufweist, für jede Faktentabelle und die Schlüsseltabelle gewährleistet, dass die Faktentabelle und die Schlüsseltabelle des Sternschemas des relationalen Speichermanagers 900 gleichzeitig bearbeitet werden kann, ohne dass es im RDBMS 118 zu Störungen kommt.

Der relationale Speichermanager kann N neue Faktentabellen erstellen und die Daten aus den ursprünglichen Faktentabellen in die neuen Faktentabellen kopieren. Dazu verwendet der relationale Speichermanager N gleichzeitige Threads und Verbindungen sowie eine für jede neue Faktentabelle.

Fig. 10 ist ein Blockdiagramm, das den relationalen Speichermanager 114 veranschaulicht. Dieser verwendet N Threads, um Daten zwischen N Faktentabellen neu zu verteilen. Dazu erstellt der relationale Speichermanager 114 N neue Faktentabellen 1000 und kopiert daraufhin die Daten aus den ursprünglichen Faktentabellen 1002 in die neuen Faktentabellen 1000. Im einzelnen startet der relationale Speichermanager N Threads 1004 gleichzeitig, um die Neuverteilung durchzuführen. Jeder der N Threads 1004 speichert Daten in einer der Faktentabellen 1000. Auch kann jeder der Threads Daten aus jeder der Faktentabellen 1002 abrufen. Jeder Thread erkennt die Zeilen, die in der entsprechenden neuen Faktentabelle 1000 gespeichert werden sollen. Deshalb ruft jeder Thread diese Zeilen aus den ursprünglichen Faktentabellen 1002 ab, um sie in der entsprechenden neuen Faktentabelle 1000 zu speichern.

In einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung werden die Daten mit dem Befehl INSERT gemäß einer Unterbedingung verschoben. Dieser Befehl INSERT ermöglicht Datenverschiebungen zwischen zwei Tabellen und macht es überflüssig, Daten aus einer ursprünglichen Faktentabelle abzurufen, die Daten im Speicher einer Anwendung zu speichern und die Daten aus dem Speicher in eine neue Faktentabelle zu verschieben. Danach führt jeder der N Threads N INSERT-Befehle mit einer Unterbedingung an jeder der ursprünglichen Faktentabellen aus. Die Unterbedingung sucht die entsprechenden Zeilen aus jeder der ursprünglichen Faktentabellen. Der INSERT-Befehl hingegen fügt diese Zeilen entsprechend diesem Thread in die neue Faktentabelle ein.

Wenn die Kopiermethode verwendet wird, können die Unterbedingungen so miteinander verknüpft werden, dass das Umverteilen, Löschen und Hinzufügen mit einer Gruppe von INSERT-Befehlen, die parallel zueinander ausgeführt werden, erreicht werden kann.

Wenn mehrere Faktentabellen existieren, müssen Zeilen möglicherweise innerhalb der Faktentabellen umverteilt werden, was mit einem Hashing-Verfahren geschieht, um festzustellen, zu welcher Faktentabelle eine bestimmte Zeile gehört. Ist das der Fall, können Zeilen aus einer ursprünglichen Faktentabelle in die jeweilige neue Faktentabelle verschoben werden, indem ein Ausdruck erstellt wird, der in der Bedingung WHERE des Befehls SELECT INTO, der verwendet wird, um Zeilen aus einer ursprünglichen Faktentabelle in die jeweilige neue Faktentabelle zu verschieben, das Hashing-Verfahren repräsentiert.

Schluß

Damit ist die Beschreibung des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung abgeschlossen. Um das Prinzip der vorliegenden Erfindung anzuwenden, kann jeder beliebige Computertyp wie beispielsweise Großrechner, Minicomputer, Personalcomputer oder eine beliebige Computerkonfiguration wie beispielsweise ein Timesharing- Großrechner, ein LAN-Netz oder ein unabhängiger PC verwendet werden.

Die obige Beschreibung eines bevorzugten Ausführungsbeispiels der vorliegenden Erfindung dient lediglich zur Veranschaulichung. Sie darf nicht als beschränkend angesehen werden. Innerhalb der obigen Beschreibung sind zahlreiche Änderungen und Abweichungen möglich. Der Anwendungsbereich der vorliegenden Erfindung wird nicht durch diese ausführliche Beschreibung, sondern vielmehr durch die anhängigen Ansprüche abgegrenzt.

Claims (45)

1. Ein Verfahren zur Ausführung eines Befehls in einem Computer, wobei der Befehl zur Ausführung einer Datenbankoperation in einer relationalen Datenbank dient, die in einem Datenspeicher gespeichert ist, der wiederum an den Computer angeschlossen ist, wobei das Verfahren die folgenden Schritte umfasst:
Feststellung, dass eine mehrdimensionale Datenbank geändert wurde;
Feststellung, dass in der geänderten mehrdimensionalen Datenbank Änderungen in einer oder mehreren ursprünglichen Tabellen in einer relationalen Datenbank, die der mehrdimensionalen Datenbank entspricht, erforderlich sind; und
Eintragung der Änderungen in eine oder mehrere neue Tabellen, indem Daten aus den ursprünglichen Tabellen in die neuen Tabellen kopiert werden.

2. Das Verfahren gemäß Anspruch 1, wobei die Feststellung, dass eine mehrdimensionale Datenbank geändert wurde, auch die Feststellung umfasst, dass eine oder mehrere Nicht- Anker-Dimensionen oder Nicht-Anker-Dimensionsmitglieder gelöscht wurden.

3. Das Verfahren gemäß Anspruch 1, wobei die Feststellung, dass eine mehrdimensionale Datenbank geändert wurde, auch die Feststellung umfasst, dass eine oder mehrere Nicht- Anker-Dimensionen oder Anker-Dimensionsmitglieder hinzugefügt wurden.

4. Das Verfahren gemäß Anspruch 1, wobei das Kopieren weiterhin das Erstellen der einen oder mehreren neuen Tabellen unter Verwendung aller Spalten, die aus der ursprünglichen Tabelle beibehalten werden sollen, sowie aller neuen Spalten, die für neue Dimensionen und Ankerdimensionsmitglieder hinzugefügt werden sollen, umfasst.

5. Das Verfahren gemäß Anspruch 1, wobei das Kopieren weiterhin das Ausschalten der Protokollierung in einer anfänglichen Transaktion umfasst.

6. Das Verfahren gemäß Anspruch 1, wobei das Kopieren weiterhin das Einfügen von Daten aus der ursprünglichen Tabelle in die neue Tabelle mit Hilfe eines Einfügebefehls mit Unterbedingung umfasst.

7. Das Verfahren gemäß Anspruch 7, wobei die Unterbedingung eine WHERE-Bedingung enthält.

8. Das Verfahren gemäß Anspruch 1, wobei das Kopieren weiterhin die Initialisierung einer der ursprünglichen Tabelle neu hinzugefügten oder wiederverwendeten Spalte umfasst, wobei die neue Tabelle einen Wert NULL enthält.

9. Das Verfahren gemäß Anspruch 1, das weiterhin den Schritt des Löschens nicht benötigter Daten aus der neuen Tabelle umfasst.

10. Das Verfahren gemäß Anspruch 1, das weiterhin den Schritt der Entfernung der ursprünglichen Tabelle umfasst.

11. Das Verfahren gemäß Anspruch 1, das weiterhin den Schritt der Umbenennung der neuen Tabelle in den ursprünglichen Tabellennamen umfasst.

12. Das Verfahren gemäß Anspruch 1, das mehrere ursprüngliche Tabellen und mehrere neue Tabellen enthält, wobei dieses Verfahren weiterhin das gleichzeitige Kopieren von Daten aus jeder der ursprünglichen Tabellen in jede der neuen Tabellen mit separaten Threads umfasst.

13. Das Verfahren gemäß Anspruch 12, wobei jeder Thread eine eigene Datenbankverbindung aufrechterhält.

14. Das Verfahren gemäß Anspruch 12, das weiterhin den Schritt einer Feststellung umfasst, welche Daten für welche Tabelle vorgesehen sind, wozu eine Hashing- Funktion verwendet wird, die auf einer Gruppe von Dimensionskennungen basiert, die Dimensionen in der mehrdimensionalen Datenbank kennzeichnen.

15. Das Verfahren gemäß Anspruch 14, wobei das Kopieren weiterhin den Schritt des Verschiebens von Daten aus den ursprünglichen Tabellen in die neuen Tabellen unter Verwendung eines Einfügebefehls mit Unterbedingung umfasst, die die Hashing-Funktion angibt.

16. Eine Einrichtung, die dazu dient, in einem Computer einen Befehl auszuführen, wobei diese Einrichtung folgendes umfasst:
einen Computer, an den ein Datenspeicher angeschlossen ist, in dem eine relationale Datenbank gespeichert werden kann;
ein oder mehrere Computerprogramme, die vom Computer ausgeführt werden, wobei diese Computerprogramme dazu dienen, festzustellen, dass eine mehrdimensionale Datenbank geändert wurde, sowie festzustellen, dass die geänderte mehrdimensionale Datenbank Änderungen in einer oder mehreren ursprünglichen Tabellen in einer relationalen Datenbank entsprechend der mehrdimensionalen Datenbank bedarf, und wobei diese Computerprogramme außerdem dazu dienen, die Änderungen in eine oder mehrere neue Tabellen einzufügen, indem die entsprechenden Daten aus den ursprünglichen Tabellen in die neuen Tabellen kopiert werden.

17. Die Einrichtung gemäß Anspruch 16, wobei die Feststellung, dass eine mehrdimensionale Datenbank geändert wurde, auch die Feststellung umfasst, dass eine oder mehrere Nicht-Anker-Dimensionen oder Nicht-Anker- Dimensionsmitglieder gelöscht wurden.

18. Die Einrichtung gemäß Anspruch 16, wobei die Feststellung, dass eine mehrdimensionale Datenbank geändert wurde, auch die Feststellung umfasst, dass eine oder mehrere Nicht-Anker-Dimensionen oder Anker- Dimensionsmitglieder hinzugefügt wurden.

19. Die Einrichtung gemäß Anspruch 16, wobei das Kopieren weiterhin die Erstellung einer oder mehrerer neuer Tabellen umfasst, und zwar unter Verwendung aller Spalten, die aus der ursprünglichen Tabelle beibehalten werden sollen, sowie aller neuer Spalten, die für neue Dimensionen und Ankerdimensionsmitglieder hinzugefügt werden sollen.

20. Die Einrichtung gemäß Anspruch 16, wobei das Kopieren weiterhin das Ausschalten der Protokollierung bei einer Ersttransaktion umfasst.

21. Die Einrichtung gemäß Anspruch 16, wobei das Kopieren weiterhin unter Verwendung eines Einfügebefehls mit Unterbedingung das Einfügen von Daten aus der ursprünglichen Tabelle in die neue Tabelle umfasst.

22. Die Einrichtung gemäß Anspruch 21, wobei die Unterbedingung eine WHERE-Bedingung umfasst.

23. Die Einrichtung gemäß Anspruch 16, wobei das Kopieren weiterhin die Initialisierung einer der ursprünglichen Tabelle neu hinzugefügten oder darin wiederverwendeten Spalte mit einer geeigneten Kennung in der neuen Tabelle umfasst.

24. Die Einrichtung gemäß Anspruch 16, wobei zusätzlich das Löschen unnötiger Daten aus der neuen Tabelle enthalten ist.

25. Die Einrichtung gemäß Anspruch 16, wobei zusätzlich die Beseitigung der ursprünglichen Tabelle enthalten ist.

26. Die Einrichtung gemäß Anspruch 16, wobei zusätzlich die Umbenennung der neuen Tabelle in den ursprünglichen Tabellennamen enthalten ist.

27. Die Einrichtung gemäß Anspruch 16, wobei es mehrere ursprüngliche Tabellen und mehrere neue Tabellen gibt und wobei es weiterhin möglich ist, Daten aus jeder der ursprünglichen Tabellen in jede der neuen Tabellen gleichzeitig zu kopieren, wobei jede der neuen Tabellen einen eigenen Thread besitzt.

28. Die Vorrichtung gemäß Anspruch 27, wobei jeder Thread eine eigene Datenbankverbindung aufrechterhält.

29. Die Vorrichtung gemäß Anspruch 27, wobei zusätzlich ein Schritt enthalten ist, in dem festgestellt wird, welche Daten in welche Tabellen gestellt werden, wozu eine Hashing-Funktion verwendet wird, die auf einer Gruppe von Dimensionskennungen basiert, die Dimensionen in der mehrdimensionalen Datenbank kennzeichnen.

30. Die Vorrichtung gemäß Anspruch 29, wobei das Kopieren weiterhin den Schritt des Verschiebens von Daten aus den ursprünglichen Tabellen in die neuen Tabellen unter Verwendung eines Einfügebefehls mit Unterbedingung umfasst, die die Hashing-Funktion angibt.

31. Ein Erzeugnis, das ein Programmspeichermedium umfasst, das von einem Computer gelesen werden kann und eine oder mehrere Anweisungen enthält, die vom Computer ausgeführt werden können, um Schritte gemäß der vorliegenden Erfindung auszuführen, beispielsweise, um in einer relationalen Datenbank, die in einem Datenspeicher gespeichert ist, der mit dem Computer verbunden ist, eine Datenbankoperation durchzuführen, wobei dieses Verfahren die folgenden Schritte umfasst:
Feststellung, dass eine mehrdimensionale Datenbank geändert wurde;
Feststellung, dass die geänderte mehrdimensionale Datenbank Änderungen in einer oder mehreren ursprünglichen Tabellen in einer relationalen Datenbank entsprechend der mehrdimensionalen Datenbank erfordert; und
Einarbeitung der Änderungen in eine oder mehrere neue Tabellen, indem Daten aus den ursprünglichen Tabellen in die neuen Tabellen kopiert werden.

32. Ein Erzeugnis gemäß Anspruch 31, wobei die Feststellung, dass eine mehrdimensionale Datenbank geändert wurde, auch die Feststellung umfasst, dass eine oder mehrere Nicht- Anker-Dimensionen oder Nicht-Anker-Dimensionsmitglieder gelöscht wurden.

33. Ein Erzeugnis gemäß Anspruch 31, wobei die Feststellung, dass eine mehrdimensionale Datenbank geändert wurde, auch die Feststellung umfasst, dass eine oder mehrere Nicht- Anker-Dimensionen oder Anker-Dimensionsmitglieder hinzugefügt wurden.

34. Ein Erzeugnis gemäß Anspruch 31, wobei das Kopieren weiterhin die Erstellung einer oder mehrerer neuer Tabellen umfasst, und zwar unter Verwendung aller Spalten, die aus der ursprünglichen Tabelle beibehalten werden sollen, sowie aller neuer Spalten, die für neue Dimensionen und Ankerdimensionsmitglieder hinzugefügt werden sollen.

35. Ein Erzeugnis gemäß Anspruch 31, wobei das Kopieren weiterhin das Ausschalten der Protokollierung bei einer Ersttransaktion umfasst.

36. Ein Erzeugnis gemäß Anspruch 31, wobei das Kopieren weiterhin unter Verwendung eines Einfügebefehls mit Unterbedingung das Einfügen von Daten in die neue Tabelle umfasst.

37. Ein Erzeugnis gemäß Anspruch 36, wobei die Unterbedingung einen WHERE-Befehl umfasst.

38. Ein Erzeugnis gemäß Anspruch 31, wobei das Kopieren weiterhin die Initialisierung einer der ursprünglichen Tabelle neu hinzugefügten Spalte oder einer darin wiederverwendeten Spalte umfasst, wobei diese Spalten eine geeignete Kennung in der neuen Tabelle bekommen.

39. Ein Erzeugnis gemäß Anspruch 31, wobei zusätzlich ein Schritt zum Löschen unnötiger Daten aus der neuen Tabelle enthalten ist.

40. Ein Erzeugnis gemäß Anspruch 31, wobei zusätzlich ein Schritt zur Beseitigung der ursprünglichen Tabelle enthalten ist.

41. Ein Erzeugnis gemäß Anspruch 31, wobei zusätzlich ein Schritt zur Umbenennung der neuen Tabelle in den ursprünglichen Tabellennamen enthalten ist.

42. Ein Erzeugnis gemäß Anspruch 31, wobei es mehrere ursprüngliche Tabellen und mehrere neue Tabellen gibt, wobei weiterhin ein Schritt enthalten ist, in dem gleichzeitig Daten aus jeder der ursprünglichen Tabellen in jede der neuen Tabellen kopiert werden, wobei jede der neuen Tabellen einen eigenen Thread besitzt.

43. Ein Erzeugnis gemäß Anspruch 42, wobei jeder Thread eine eigene Datenbankverbindung aufrechterhält.

44. Ein Erzeugnis gemäß Anspruch 42, wobei zusätzlich ein Schritt enthalten ist, in dem festgestellt wird, welche Daten in welche Tabellen gehen, wozu eine Hashing- Funktion verwendet wird, die auf einer Gruppe von Dimensionskennungen basiert, die Dimensionen in der mehrdimensionalen Datenbank kennzeichnen.

45. Ein Erzeugnis gemäß Anspruch 44, wobei das Kopieren weiterhin unter Verwendung eines Einfügebefehls mit Unterbedingung die Verschiebung von Daten aus den ursprünglichen Tabellen in die neuen Tabellen umfasst, wobei die Unterbedingung die Hashing-Funktion definiert.