DE69533193T2 - Paralleles verarbeitungssystem zum durchlaufen einer datenbank - Google Patents

Paralleles verarbeitungssystem zum durchlaufen einer datenbank Download PDF

Info

Publication number
DE69533193T2
DE69533193T2 DE69533193T DE69533193T DE69533193T2 DE 69533193 T2 DE69533193 T2 DE 69533193T2 DE 69533193 T DE69533193 T DE 69533193T DE 69533193 T DE69533193 T DE 69533193T DE 69533193 T2 DE69533193 T2 DE 69533193T2
Authority
DE
Germany
Prior art keywords
file
files
data
thread
physical
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69533193T
Other languages
English (en)
Other versions
DE69533193D1 (de
Inventor
Richard K. Roth
Jay R. Poulos
Douglas F. Kunkel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Application granted granted Critical
Publication of DE69533193D1 publication Critical patent/DE69533193D1/de
Publication of DE69533193T2 publication Critical patent/DE69533193T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • G06F16/24532Query optimisation of parallel queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99931Database or file accessing
    • Y10S707/99933Query processing, i.e. searching

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Numerical Control (AREA)

Description

  • Bereich der Erfindung
  • Die vorliegende Erfindung betrifft die Technik der Datenverarbeitung und insbesondere ein Verfahren zum Durchlaufen einer großen Datenbank auf der Grundlage von benutzerdefinierten Kriterien, zum Abrufen von Daten aus der Datenbank auf der Grundlage der benutzerdefinierten Kriterien und zur Bereitstellung von Daten in einem vom Benutzer angegebenen Format.
  • Der Erfindung zugrunde liegender allgemeiner Stand der Technik
  • Ein ständiges Problem, dem sich ein Benutzer einer großen Datenbank gegenüber sieht, ist die Frage, wie sich auf benötigte Daten wirksam und in einem geeigneten Format zugreifen lässt. Im Allgemeinen erfasst und speichert ein großes Unternehmen laufend Daten in vielen verschiedenen Formaten für vielerlei Verwendungszwecke. Viele dieser Dateien werden im Allgemeinen als Transaktions- oder Ereignisdateien bezeichnet, weil jeder Eintrag oder jeder Satz von Einträgen Daten bezüglich eines einzelnen Ereignisses oder einer einzelnen Transaktion enthält, das/die unabhängig von anderen Ereignissen oder Transaktionen in der Datei vorkommen kann.
  • Beispielsweise könnte eine große Einzelhandelskette Datenbanken verwalten, welche Kundendaten, die Adressen, Telefonnummern usw. beinhalten, sowie Kontenhistorie-Daten umfassen, die für jeden Kunde eine Liste mit jedem gekauften Artikel, dem Datum des Kaufs, dem Preis und der Zahlungsart beinhalten könnten. Solche Dateien, die täglich oder wöchentlich aktualisiert werden und mehrere Jahre mit Transaktionen umfassen können, sind bei großen Unternehmen natürlich ziemlich umfangreich. Als solches werden diese Dateien im Allgemeinen auf externen Speichereinheiten wie zum Beispiel Bandlaufwerken und Plattenlaufwerken gespeichert.
  • Die bloße Größe von beispielweise einer 3 Jahre umfassenden Kontenhistorie-Datei in Verbindung mit der Tatsache, dass die Datei auf verhältnismäßig langsamen externen Speichereinheiten gespeichert ist, macht das Abrufen und die Verarbeitung von Daten von diesen Dateien zu einer zeitintensiven Aufgabe. Folglich werden solche Dateien in ihrer ursprünglichen Form nicht oft verwendet. Stattdessen möchte ein Unternehmen im Allgemeinen die Daten in diesen Dateien auswerten und Zusammenfassungsdateien, beispielsweise des Gesamtbetrags der in einem bestimmten Zeitraum getätigten Käufe, bilden.
  • Folglich erstellt ein Unternehmen temporäre "Zusammenfassungsdateien", die Daten enthalten, die Ereignis- oder Transaktionsdateien entnommen werden. Diese Zusammenfassungsdateien werden dann bei der Erfassung neuer Ereignisse oder Transaktionen aktualisiert. Wenn eine Transaktionsdatei zum Beispiel Daten über die Gehaltsabrechnung enthält, die die von jedem Angestellten auf ein Projekt verwendete Stundenzahl sowie sein Gehalt angibt, könnte eine Zusammenfassungsdatei erzeugt werden, um die laufende Summe der Stunden festzuhalten, die jeder Angestellte an jedem einzelnen Projekt gearbeitet hat. Wenn neue Gehaltsabrechnungseinträge in die Transaktionsdatei eingegeben werden, wird die Zusammenfassungsdatei aktualisiert, indem die neuen Transaktionsdaten einfach zu den zuvor gespeicherten Summen in der Zusammenfassungsdatei hinzugefügt werden.
  • Wenn ein Benutzer Daten in Bezug auf die Stunden anfordert, die der Angestellte John Smith an jedem. seiner Projekte gearbeitet hat, greift das System folglich auf die Zusammenfassungsdatei und nicht die ursprüngliche Gehaltsabrechnungs-Transaktionsdatei zu, um die angeforderten Daten bereitzustellen. Das System braucht daher höchstens die Einträge der letzten Tage zu durchsuchen, um die Zusammenfassungsdatei zu aktualisieren und die aktuellsten angeforderten Daten zu erhalten. Dies verringert die Verarbeitungszeit.
  • Solche Systeme, die auf "Zusammenfassungsdateien" beruhen, haben jedoch bestimmte Nachteile. Wenn beispielsweise die Art der Daten, die der Benutzer wünscht, nicht in der Zusammenfassungsdatei verwaltet wird, kann man die Information nicht ohne weiteres erhalten. Erstellern von "Zusammenfassungsdateien" wird dabei die nicht unwesentliche Auflage gemacht, dass sie zukünftige Daten und geschäftliche Erfordernisse vorwegnehmen oder abschätzen müssen und diese zusammenfassenden Daten jederzeit verfügbar halten müssen.
  • Ein zusätzliches Problem tritt auf, wenn Daten in den Zusammenfassungsdateien rückwirkend geändert werden müssen. Nehmen wir beispielsweise an, dass die Beilegung eines Tarifstreits mit der Gewerkschaft zu einer rückwirkenden Lohnerhöhung von 7.00 USD/Std. auf 8.00 USD/Std. geführt hat. Bei dem vorstehenden System nach dem Stand der Technik muss eine Lohndifferenz berechnet werden, und anschließend müssen alle Zusammenfassungsdateien, die Daten enthalten, welche sich von den Gehaltsdaten ableiten, angepasst werden, damit sich die Auswirkung der rückwirkenden Änderung darin niederschlägt.
  • Folglich leiden Systeme nach dem Stand der Technik aufgrund dessen, dass ihre Ausgabedaten auf dem Inhalt von Zusammenfassungsdateien und nicht dem Inhalt der ursprünglichen Transaktions- oder Ereignisdateien beruhen, an einem ihnen eigenen Mangel an Flexibilität. Als solches besteht ein Bedarf an einem System, das Daten aus den ursprünglichen Transaktions- oder Ereignisdateien schnell in einem gewünschten Format zusammenstellen kann.
  • Price Waterhouse, Geneva View Processor Architecture/Test Objectives, Release 3, erschienen am 14.04.1993, legt ein Verfahren zum Betreiben eines Rechnersystems offen, um eine oder mehrere physische Dateien einer Ereignisdatenbank zu durchlaufen, das die Verfahrensschritte umfasst, die in dem der kennzeichnenden Beschreibung vorausgehenden Teil von Anspruch 1 dargelegt sind.
  • Zusammenfassung der Erfindung
  • Die Erfindung stellt ein Verfahren zum Betreiben eines Rechnersystems, wie es in Anspruch 1 dargelegt ist, und eines Parallelverarbeitungssystem, wie es in Anspruch 6 dargelegt ist, bereit.
  • Die bevorzugte Ausführungsform der Erfindung stellt ein Parallelverarbeitungssystem bereit, um Ereignis- oder Transaktionsdatenbanken zu durchlaufen, das umfangreiche Ereignis- oder Transaktionsdateien schnell und wirksam verarbeiten kann und dadurch die Notwendigkeit der Verwaltung von Zusammenfassungsdateien verringert.
  • Ein Satz von Suchalgorithmen wird in einer Logiktabelle angegeben, die verwendet wird, um einen Satz von physischen Dateien zu durchlaufen, welche einzelne Ereignisse oder Transaktionen enthalten. Die Logiktabelle stellt eine Ausführungsform einer "nichtprozeduralen" Programmiersprache dar. In Übereinstimmung mit der vorliegenden Erfindung wäre es jedoch möglich, eine Logiktabelle in einer "prozeduralen" Programmiersprache wie zum Beispiel "Pascal" oder "C" auszudrücken.
  • Jedes einzelne Ereignis oder jede einzelne Transaktion wird als logischer Datensatz bezeichnet. Der Satz von ähnlich formatierten logischen Datensätzen wird als logische Datei bezeichnet. Eine logische Datei könnte beispielsweise ein Satz logischer Datensätze sein, die Daten in Bezug auf Kaufereignisse (zum Beispiel Kreditkartenkäufe) enthalten, die über einen Zeitraum, beispielsweise 3 Jahre, stattfinden. Diese logische Datei "Kaufhistorie" könnte beispielsweise 3 physische Dateien umfassen: die physische Datei 1, die Käufe im aktuellen Kalenderjahr (Jahr 0) beinhaltet, die physische Datei 2, die Käufe im vorhergehenden Kalenderjahr (Jahr –1) beinhaltet, und die physische Datei 3, die Käufe in dem diesem Jahr vorausgehenden Kalenderjahr beinhaltet (Jahr –2). Die physischen Dateien können auf Band oder Platte gespeichert werden.
  • Jede physische Datei in einer logischen Datei wird entsprechend einem jeweiligen Suchalgorithmus von einem anderen Thread durchsucht. In einem Mehrprozessorsystem können einzelne Threads auf getrennten Prozessoren ausgeführt werden. Wenn die Anzahl der Prozessoren gleich der Anzahl der Threads oder größer ist, kann der Suchalgorithmus eines jeden Thread seine jeweilige physische Datei parallel zu den Algorithmen der anderen Threads durchlaufen. Wenn es beispielsweise 3 Threads und 3 Prozessoren gibt, durchlaufen alle 3 Threads ihre jeweiligen physischen Dateien parallel. Außerdem werden selbst dann, wenn die Anzahl der Threads höher als die Anzahl der Prozessoren ist, zumindest einige der Suchalgorithmen parallel ausgeführt. Wenn es beispielsweise 4 Threads in einem System gibt, das drei Prozessoren hat, müssen sich die Threads die Prozessoren so teilen, dass jeweils immer nur 3 Threads in Ausführung befindlich sein können.
  • Der Suchalgorithmus wird in einer Logiktabelle aus einer oder mehreren Sichtweisen erzeugt. Eine Sichtweise wird als ein bestimmter Satz von Parametern festgelegt, die auf einer logischen Datei beruhen, um eine Auszugsdatei zu bilden. Als solches könnte eine Sichtweise angeben, dass bestimmte Daten oder Klassen von Daten aus den logischen Datensätzen der logischen Datei abgerufen, in einer bestimmten Weise verarbeitet und in einem bestimmten Format in eine Auszugsdatei geschrieben werden sollen. In einer typischen Anwendung kann es viele Sichtweisen geben, die in Bezug auf eine einzige logische Datei festgelegt werden, und viele verschiedene logische Dateien, die für einen Benutzer von Interesse sind.
  • Alle Sichtweisen, die in Bezug auf verschiedene logische Dateien und verschiedene physische Dateien festgelegt werden können, werden in eine kombinierte Logiktabelle aufgenommen. Die Logiktabelle wird in "Sätzen" angeordnet, wobei jeder Satz einer anderen physischen Datei und daher einem anderen Thread entspricht. Ein bestimmter Satz enthält jede Sichtweise, die Daten aus der physischen Datei benötigt, die diesem Satz entspricht.
  • Die Logiktabelle wird in Maschinencode umgesetzt, wobei der Maschinencode den Suchalgorithmus für jeden Thread bildet und jeder Thread an seiner jeweiligen physischen Datei Operationen ausführt. Die Threads werden dann entsprechend ihres jeweiligen Maschinencodes parallel ausgeführt, um die physischen Dateien zu durchlaufen, die die logischen Datensätze enthalten. Da der mittels des Maschinencodes realisierte Suchalgorithmus für jeden Thread alle Daten, die von allen Sichtweisen benötigt werden, der jeweiligen physischen Datei entnimmt, wird jede physische Datei, ungeachtet der Anzahl der festgelegten Sichtweisen oder der Anzahl der logischen Dateien, die durchsucht werden, nur einmal durchlaufen. Indem die physischen Dateien parallel durchsucht werden und indem jede physische Datei ungeachtet der Anzahl der Sichtweisen nur einmal durchlaufen wird, wird die Verarbeitungszeit für das Durchlaufen einer großen Datenbank gemäß der vorliegenden Erfindung folglich erheblich verringert. Dadurch wird es möglich, Daten aus den ursprünglichen Ereignis- oder Transaktionsdateien statt aus Zusammenfassungsdateien zu beziehen.
  • Nehmen wir beispielsweise an, dass ein Benutzer auf der Grundlage von Daten, die in der vorstehend beschriebenen logischen Datei "Kaufhistorie" enthalten sind, drei gesonderte Berichte erstellen möchte, wobei der Bericht Nr. 1 alle Käufe von Personen mit Namen John Smith während der Jahre 0 bis einschließlich –2 nach Artikelnummer auflistet, der Bericht Nr. 2 alle Käufe in den Jahren 0 bis einschließlich –1, die 500 US-Dollar übersteigen, nach Kundenname auflistet und der Bericht Nr. 3 für jeden Kunden die aufgelaufene Summe seiner Kreditkartenkäufe während des laufenden Jahres (0) auflistet.
  • Eine Logiktabelle wird erzeugt, die in drei Sätze getrennt wird, einen für jede der drei physischen Dateien der logischen Datei "Kaufhistorie".
  • Eine Definition einer Sichtweise für den Bericht Nr. 1 würde erzeugt und in jedem der drei Sätze gespeichert werden, da der Bericht Nr. 1 Daten aus jeder der drei physischen Dateien benötigt. Die Definition einer Sichtweise für den Bericht Nr. 1, die in jeden der drei Sätze kopiert würde, könnte die folgenden Parameter enthalten: Rufe alle Einträge in der physischen Datei ab, deren Feld "Kunde" John Smith lautet, stelle den Inhalt des Felds "Kunde" aller abgerufenen Einträge in die Spalte 1 einer Auszugsdatei für die Sichtweise 1, stelle den Inhalt des Felds "Artikel" aller abgerufenen Einträge in die Spalte 2, stelle den Inhalt des Felds "Preis" aller abgerufenen Einträge in die Spalte 3 und sortiere die abgerufenen Einträge nach dem Inhalt des Felds "Artikel".
  • Eine Definition einer Sichtweise für den Bericht Nr. 2 würde erzeugt und nur in dem ersten und dem zweiten Satz gespeichert werden, weil der Bericht Nr. 2 nur aus der physischen Datei 1 (Jahr 0) und der physischen Datei 2 (Jahr –1) Daten benötigt. Die Definition einer Sichtweise für den Bericht Nr. 2, die in jeden der ersten beiden Sätze kopiert würde, könnte die folgenden Parameter enthalten: Rufe alle Einträge in der physischen Datei ab, bei denen der Inhalt des Felds "Preis" größer als 500 US-Dollar ist, stelle den Inhalt des Felds "Kunde" aller abgerufenen Einträge in die Spalte 1 einer Auszugsdatei für die Sichtweise 2, stelle den Inhalt des Felds "Artikel" aller abgerufenen Einträge in die Spalte 2, stelle den Inhalt des Felds "Preis" aller abgerufenen Einträge in die Spalte 3, und sortiere die abgerufenen Einträge nach dem Inhalt des Felds "Kunde".
  • Eine Definition einer Sichtweise für den Bericht Nr. 3 würde erzeugt und nur in dem ersten Satz gespeichert werden, da der Bericht Nr. 3 nur aus der physischen Datei 1 (Jahr 0) Daten benötigt. Die Definition einer Sichtweise für den Bericht Nr. 3, die nur in dem ersten Satz vorhanden wäre, könnte die folgenden Parameter enthalten: Rufe alle Einträge in der physischen Datei ab, stelle den Inhalt des Felds "Kunde" aller abgerufenen Einträge in die Spalte 1 einer Auszugsdatei für die Sichtweise 3, stelle den Inhalt des Felds "Artikel" aller abgerufenen Einträge in die Spalte 2 der Auszugsdatei, stelle den Inhalt des Felds "Preis" aller abgerufenen Einträge in die Spalte 3 der Auszugsdatei, stelle in Vorbereitung der Berechnung der laufenden Summe, die vorstehend erörtert wurde, eine "0" in die Spalte 4, sortiere die abgerufenen Einträge nach dem Inhalt des Felds "Kunde", und stelle in die Spalte 4 eines jeden Eintrags der Auszugsdatei die Summe des Inhalts des Felds "Preis" (Spalte 3) des Eintrags und des Inhalts der Spalte 4 für den vorhergehenden Eintrag für den in der Spalte 1 des Eintrags ausgewiesenen Kunden.
  • Die vorstehenden Definitionen von Sichtweisen in der Logiktabelle würden dann für jeden von drei Threads, einen Thread für jeden Satz der Logiktabelle, in Maschinencodebefehle umgesetzt werden. Jeder der drei Threads würde seine jeweilige physische Datei wie folgt durchlaufen: Der Thread 1 würde die physische Datei 1 durchlaufen. Der Thread 1 würde auf den ersten Eintrag der physischen Datei 1 zugreifen und die folgenden Schritte durchführen:
    • 1. Wenn das Feld mit dem Kundennamen auf John Smith lautet, stelle den Inhalt des Felds "Kunde" in die Spalte 1 eines Auszugseintrags, stelle den Inhalt des Felds "Artikel" in die Spalte 2, stelle den Inhalt des Felds "Preis" in die Spalte 3, erfasse die Sortierfelder in Vorbereitung der Sortierung des Eintrags mit vorhergehenden Einträgen nach dem Inhalt des Felds "Artikel", und schreibe die Auszugseinträge in eine Auszugsdatei für die Sichtweise 1;
    • 2. wenn der Inhalt des Felds "Preis" größer als 500 ist, stelle den Inhalt des Felds "Kunde" in die Spalte 1 eines Auszugseintrags, stelle den Inhalt des Felds "Artikel" in die Spalte 2, stelle den Inhalt des Felds "Preis" in die Spalte 3, sortiere den Eintrag mit vorhergehenden Einträgen für die Sichtweise 2 nach dem Inhalt des Felds "Kunde", und schreibe die entnommenen Einträge in eine Auszugsdatei für die Sichtweise 2;
    • 3. stelle den Inhalt des Felds "Kunde" in die Spalte 1 eines Auszugseintrags, stelle den Inhalt des Felds "Artikel" in die Spalte 2, stelle den Inhalt des Felds "Preis" in die Spalte 3, erfasse die Sortierfelder in Vorbereitung der Sortierung des Eintrags mit vorhergehenden Einträgen für die Sichtweise 3 nach dem Inhalt des Felds "Kunde", stelle in Vorbereitung der Berechnung der laufenden Summe, die vorstehend erörtert wurde, eine "0" in die Spalte 4, und schreibe die entnommenen Einträge in eine Auszugsdatei für die Sichtweise 3; und
    • 4. wiederhole die Schritte 1 bis einschließlich 3 für alle restlichen Einträge in der physischen Datei 1.
  • Der Thread 2 würde die physische Datei 2 durchlaufen. Der Thread 2 würde auf den ersten Eintrag der physischen Datei 2 zugreifen und die folgenden Schritte durchführen:
    • 1. Wenn das Feld "Kunde" auf John Smith lautet, stelle den Inhalt des Felds "Kunde" in die Spalte 1 eines Auszugseintrags, stelle den Inhalt des Felds "Artikel" in die Spalte 2, stelle den Inhalt des Felds "Preis" in die Spalte 3, erfasse die Sortierfelder in Vorbereitung der Sortierung des Eintrags mit vorhergehenden Einträgen nach dem Inhalt des Felds "Artikel", und schreibe die entnommenen Einträge in eine Auszugsdatei für die Sichtweise 1;
    • 2. wenn der Inhalt des Felds "Preis" größer als 500 ist, stelle den Inhalt des Felds "Kunde" in die Spalte 1 eines Auszugseintrags, stelle den Inhalt des Felds "Artikel" in die Spalte 2, stelle den Inhalt des Felds "Preis" in die Spalte 3, erfasse die Sortierfelder in Vorbereitung der Sortierung des Eintrags mit vorhergehenden Einträgen für die Sichtweise 2 nach dem Inhalt des Felds "Kunde", und schreibe die entnommenen Einträge in eine Auszugsdatei für die Sichtweise 2; und
    • 3. wiederhole die Schritte 1 bis 2 für alle restlichen Einträge in der physischen Datei 2.
  • Der Thread 3 würde die physische Datei 3 durchlaufen. Der Thread 3 würde auf den ersten Eintrag der physischen Datei 3 zugreifen und die folgenden Schritte durchführen:
    • 1. Wenn das Feld "Kunde" auf John Smith lautet, stelle den Inhalt des Felds "Kunde" in die Spalte 1 eines Auszugseintrags, stelle den Inhalt des Felds "Artikel" in die Spalte 2, stelle den Inhalt des Felds "Preis" in die Spalte 3, erfasse die Sortierfelder in Vorbereitung der Sortierung des Eintrags mit vorhergehenden Einträgen nach dem Inhalt des Felds "Artikel", und schreibe die entnommenen Einträge in eine Auszugsdatei für die Sichtweise 1; und
    • 2. wiederhole den Schritt 1 für alle restlichen Einträge in der physischen Datei 3.
  • Sobald die Threads die vorstehende Prozedur beendet haben, wird jede Auszugsdatei entsprechend den von jeder Definition einer Sichtweise angegebenen Sortierfeldern gespeichert. Füge dann für jeden Eintrag in der Auszugsdatei für die Sichtweise 3 den Inhalt der Spalte 3 des Eintrags zum Inhalt der Spalte 4 des vorhergehenden Eintrags hinzu. Speichere anschließend das Ergebnis in der Spalte 4 des Eintrags, außer wenn der Eintrag der erste Eintrag in der Auszugsdatei für den in der Spalte 1 des Eintrags ausgewiesenen Kunden ist.
  • Jeder der vorstehenden drei Threads würde unabhängig von den jeweils anderen arbeiten, und wenn das System mindestens 3 Prozessoren enthielte, würde jeder der drei Threads parallel arbeiten. wie vorstehend gezeigt wurde, wird auf jeden Eintrag einer jeden physischen Datei nur einmal zugegriffen, obwohl beispielsweise der Thread 1 drei gesonderte Berichte erzeugt.
  • Da die physischen Dateien auf externen Einheiten wie zum Beispiel Bandlaufwerken und Plattenlaufwerken gespeichert werden, überschreitet der Zeitraum, der notwendig ist, um auf einen bestimmten Eintrag in einer physischen Datei zuzugreifen, bei weitem den Zeitraum, den der Thread benötigt, um die Daten zu verarbeiten, sobald sie abgerufen wurden. Indem auf jeden Eintrag der physischen Datei nur einmal zugegriffen wird und auf Einträge ungeachtet der Anzahl der in Bezug auf die physische Datei festgelegten Sichtweisen in der Reihenfolge zugegriffen wird, in der sie physisch erfasst wurden, wird als solches die Verarbeitungszeit verringert. Indem die Dateien parallel verarbeitet werden, wird die Verarbeitungszeit überdies noch weiter verringert.
  • Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird die Verarbeitungszeit durch die Ausführung einer Funktion in Form von einer überlappten Ein-/Ausgabe (E/A) der vorliegenden Erfindung noch mehr verringert.
  • Für jeden Thread wird ein Satz von Eingabepufferspeichern bereitgestellt, wobei jeder Satz von Eingabepufferspeichern einen oder mehrere Eingabepufferspeicher enthält, wobei jeder Eingabepufferspeicher einen Datenblock hält und die Übertragung von Datenblöcken von dem physischen Medium in die Eingabepufferspeicher in der gleichen Reihenfolge stattfindet, in der Blöcke auf dem physischen Medium gespeichert werden, um die Verzögerungen so klein wie möglich zu halten, die auf das Schalten von einem Block zum nächsten zurückzuführen sind. Gemäß einer Ausführungsform der vorliegenden Erfindung wird die Größe des Datenblocks in Abhängigkeit von der Art des physischen Mediums ausgewählt, in dem sich die physische Datei befindet. Die Größe des Datenblocks wird gleich der maximalen Größe gesetzt, die von seinem jeweiligen physischen Medium abgerufen werden kann, ohne dass ein Zugriffsarm mechanisch bewegt werden muss, wenn die Daten auf Platte gespeichert sind.
  • Indem die Größe des Datenblocks auf diese weise ausgewählt wird, ruft das System der vorliegenden Erfindung die Höchstmenge an Daten in einen Eingabepufferspeicher in der geringstmöglichen Verarbeitungszeit ab.
  • Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird eine Vielzahl von Eingabepufferspeichern in jedem Satz von Eingabepufferspeichern bereitgestellt, um den Zeitraum für den Datenabruf noch weiter zu minimieren. Nachdem sein Datenblock in den ersten Eingabepufferspeicher geladen wurde, während andere Datenblöcke in die nächsten Eingabepufferspeicher geladen werden, durchläuft gemäß dieser Ausführungsform der vorliegenden Erfindung der Thread, der der physischen Datei für diesen Satz von Eingabepufferspeichern entspricht, den ersten Eingabepufferspeicher entsprechend seinem Verarbeitungsalgorithmus, wodurch sich der Abruf von Datenblöcken und der Suchlauf folglich überlappen. Optimalerweise wird die Anzahl der Eingabepufferspeicher in dem Satz von Eingabepufferspeichern so gewählt, dass bis zu dem Zeitpunkt, zu dem der Thread den letzten der Eingabepufferspeicher durchlaufen hat, bereits wieder ein neuer Datenblock aus der physischen Datei in den ersten Eingabepufferspeicher geladen worden ist. Folglich braucht der Thread nicht darauf zu warten, dass Datenblöcke in die Pufferspeicher geladen werden, bevor er mit der Verarbeitung des Datenblocks beginnen kann.
  • Gemäß einer weiteren Ausführungsform der vorliegenden Erfindung wird ein Satz von Ausgabepufferspeichern für jede Auszugsdatei, auf die von der Logiktabelle verwiesen wird, bereitgestellt. Jeder Satz von Ausgabepufferspeichern enthält wiederum einen oder mehrere Ausgabepufferspeicher, wobei jeder der Ausgabepufferspeicher einen Datenblock hält. Die Größe des Datenblocks wird in Abhängigkeit von der Art des physischen Mediums ausgewählt, in dem sich die entsprechende Auszugsdatei befindet, wie vorstehend mit Bezug auf die Eingabepufferspeicher beschrieben wurde. Eine Vielzahl von Ausgabepufferspeichern kann bereitgestellt werden, um die Verarbeitungsgeschwindigkeit noch weiter zu erhöhen, indem man ermöglicht, dass in einen Pufferspeicher geschrieben wird, während ein anderer gefüllt wird.
  • Kurze Beschreibung der Zeichnungen
  • 1 zeigt ein der Veranschaulichung dienendes Prozessorsystem gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 2 zeigt eine der Veranschaulichung dienende logische Datei gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 2A zeigt die logischen Datensätze der logischen Datei von 2 ausführlicher.
  • 2B zeigt eine der Veranschaulichung dienende Referenztabelle gemäß der vorliegenden Erfindung.
  • 3 zeigt eine Logiktabelle gemäß der vorliegenden Erfindung.
  • 4 zeigt eine Auszugsdatei gemäß der vorliegenden Erfindung.
  • 5 zeigt eine Bildschirmanzeige mit Standardparametern für die Definition von Sichtweisen (View Definition Standard Parameters screen) gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 6 zeigt eine Bildschirmanzeige mit allgemeinen Spaltenparametern für die Definition von Sichtweisen (View Definition General Column Parameters screen) gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 7 zeigt eine Bildschirmanzeige zur Spaltenberechnung für die Definition von Sichtweisen (View Definition Column Calculations screen) gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 8 zeigt eine Bildschirmanzeige mit allgemeinen Sortierparametern für die Definition von Sichtweisen (View Definition General Sort Parameters screen) gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 9 zeigt eine Bildschirmanzeige mit allgemeinen Auswahlparametern für die Definition von Sichtweisen (View Definition General Selection Parameters screen) gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 10 zeigt eine Bildschirmanzeige mit Spaltenauswahlparametern für die Definition von Sichtweisen (View Definition Column Selection Parameters screen) gemäß einer Ausführungsform der vorliegenden Erfindung.
  • Die 11A bis 11D zeigen die Logiktabelle von 3 ausführlicher.
  • 11E zeigt einen der Veranschaulichung dienenden Teil der Logiktabelle von 3, der eine Suchoperation in einer Referenztabelle ausführt.
  • 12 zeigt die Ablage im Eingabepufferspeicher gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 13 zeigt die Ablage im Ausgabepufferspeicher gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 14 zeigt ein Merkmal der vorliegenden Erfindung in Form von einer Teilmenge einer Referenztabelle.
  • 15 zeigt das Merkmal in Form der Teilmenge der Referenztabelle der vorliegenden Erfindung ausführlicher.
  • 16 veranschaulicht die Erzeugung von Maschinencode aus einer Logiktabelle.
  • Ausführliche Beschreibung der Erfindung
  • Bezug nehmend auf 1 kann ein Prozessorsystem gemäß der vorliegenden Erfindung einen IBM-Großrechner 1 (der beispielsweise 3 Prozessoren A, B, C enthält) enthalten, der mit einer Vielzahl von externen Speichereinheiten wie zum Beispiel einem Diskettenlaufwerk 2, einem Festplattenlaufwerk 3 und den Bandlaufwerken 4, 5 verbunden ist.
  • Die Prozessoren durchsuchen eine Ereignis-(oder Transaktions)Datenbank gemäß einer oder mehrerer Definitionen von Sichtweisen, die in einer Logiktabelle enthalten sind.
  • Wie vorstehend erörtert wurde, ist eine Ereignisdatenbank eine Datenbank, die Dateien enthält, welche Daten in Bezug auf Ereignisse speichern. Eine Ereignisdatenbank kann eine Vielzahl von logischen Dateien enthalten, wobei jede logische Datei eine Vielzahl von logischen Datensätzen enthält. Eine logische Datei kann sich wiederum in einer Vielzahl von physischen Dateien befinden. Ein Beispiel für eine logische Datei könnte eine Datei sein, die Datensätze zur Kaufhistorie enthält. Bezug nehmend auf 2 kann sich eine logische Datei "Kaufhistorie" 10 in der physischen Datei 11, der physischen Datei 12 und der physischen Datei 13 befinden. Bezug nehmend auf 2A könnte die logische Datei "Kaufhistorie" 10 Spalten haben für: den Kundennamen 20, das Ladengeschäft 21, die Menge 22, den Artikel 23 und den Preis 24. Jede Zeile der logischen Datei 10 ist ein anderer logischer Datensatz der Kaufhistorie. Zwar ist es in den 2 und 2a nicht gezeigt, doch sollte es sich von selbst verstehen, dass jede physische Datei logische Datensätze enthalten kann, die zu mehreren verschiedenen logischen Dateien gehören können.
  • Die physische Datei 11 könnte beispielsweise alle logischen Datensätze (Einträge) der logischen Datei "Kaufhistorie" für das laufende Kalenderjahr (Jahr 0) enthalten, während die physische Datei 12 alle Einträge der logischen Datei "Kaufhistorie" für das letzte Kalenderjahr (Jahr –1) enthält und die physische Datei 13 alle Einträge der logischen Datei "Kaufhistorie" für das vorletzte Kalenderjahr (Jahr –2) enthält.
  • Gemäß der vorliegenden Erfindung können über Ereignis- und Transaktionsdatenbanken hinaus auch Referenztabellen durchsucht werden. Referenztabellen enthalten keine Ereignis- oder Transaktionsdaten, sondern Referenzdaten. Während eine Ereignisdatenbank beispielsweise Daten über Kundentransaktionen für eine Ladenkette enthalten könnte, könnte eine Referenztabelle den Standort eines jeden Ladengeschäfts der Kette und die Namen der Filialleiter in jedem Ladengeschäft angeben. Bezug nehmend auf 2B enthält ein in der Referenztabelle enthaltenes Ladengeschäft 15 Spalten für die Nummer des Ladengeschäfts 25, den Standort 26 und den Filialleiter 27.
  • Wie vorstehend erklärt wurde, umfasst eine Ereignisdatenbank eine Reihe von logischen Dateien, und jede logische Datei kann in einer oder mehreren physischen Dateien gespeichert werden. Gemäß der vorliegenden Erfindung werden die physischen Dateien der Ereignisdatenbank parallel durchsucht, um die Leistungsfähigkeit zu erhöhen. Entsprechend einem Suchlauf in einer bestimmten physischen Datei wird eine jede einer Vielzahl von Definitionen von Sichtweisen, die sich auf diese physische Datei beziehen, mittels der Logiktabelle mit den anderen verknüpft, um einen einzigen Suchalgorithmus zu bilden. Dieser Algorithmus wird einmal auf die ganze physische Datei angewendet, um Suchergebnisse für alle Definitionen von Sichtweisen für die physische Datei zu erhalten, wobei die Ergebnisse des Suchlaufs entsprechend den Definitionen der Sichtweisen verarbeitet und in dafür vorgesehene Auszugsdateien geschrieben werden.
  • Eine Logiktabelle wird erzeugt, die die Art und Weise steuert, in der die logische(n) Datei(en) verarbeitet werden. Die Logiktabelle stellt eine Ausführungsform einer nichtprozeduralen Programmiersprache dar. Entsprechend der vorliegenden Erfindung könnte die Logiktabelle jedoch in einer prozeduralen Programmiersprache wie zum Beispiel "Pascal" oder "C" ausgedrückt werden. Zusätzlich zu logischen Dateien kann eine Logiktabelle auch eine Vielzahl von Referenztabellen durchsuchen. wie vorstehend erklärt wurde, enthalten Referenztabellen im Gegensatz zu logischen Dateien keine Ereignisdatensätze. Stattdessen enthalten sie Referenzdaten, mit denen sich Daten aus Ereignisdateien von den logischen Datensätzen leichter übergeben und auswerten lassen.
  • Bezug nehmend auf 3 besteht eine Logiktabelle 30 aus mehreren Einträgen. Jeder Eintrag enthält ein Funktionscode-Feld 34, und im Allgemeinen wird hier auf die Einträge oder Zeilen der Logiktabelle mit ihrem Funktionscode-Feld verwiesen.
  • Die Logiktabelle kann in eine Vielzahl von "Sätzen" unterteilt werden. Ein Funktionscode-Feld "ES" (eine ES-Zeile) gibt das Ende eines Satzes an. 3 zum Beispiel zeigt eine beispielhafte Logiktabelle in einer "nichtprozeduralen Programmiersprache" mit 3 Sätzen, wobei ein erster Satz der physischen Datei 11, ein zweiter Satz der physischen Datei 12 und ein dritter Satz 33 der physischen Datei 13 der logischen Datei "Kaufhistorie" entspricht. Wie nachstehend ausführlicher beschrieben wird, entspricht jeder Satz einem anderen Thread in dem Parallelverarbeitungssystem.
  • Ein Funktionscode-Eintrag "NR" ("new request" (neue Anforderung)) gibt den Beginn einer neuen Sichtweise an. Wie nachstehend erörtert wird, verfeinern nachfolgende Einträge, die zwischen zwei NR-Zeilen erscheinen können, diese Sichtweise noch weiter. Jede neue Anforderung ("NR") in der Logiktabelle hat eine entsprechende Definition einer Sichtweise.
  • Eine Definition einer Sichtweise legt die Art und Weise fest, in der eine bestimmte logische Datei verarbeitet wird. Außerdem steuert die Definition einer Sichtweise die Art und Weise, in der die Ergebnisse des Suchlaufs für den Benutzer formatiert werden. Entsprechend einer Ausführungsform der vorliegenden Erfindung erzeugt ein Benutzer eine Definition einer Sichtweise, indem er mehrere Bildschirmanzeigen verwendet. Sobald die Definition einer Sichtweise erzeugt wurde, wird sie in die Logiktabelle in eine NR-Zeile und eine oder mehrere zusätzliche Zeilen in der Logiktabelle aufgenommen.
  • Ein Menü für die Definition von Sichtweisen ermöglicht einem Benutzer, eine Liste von bereits vorhandenen Definitionen von Sichtweisen anzuzeigen, eine bestimmte vorhandene Definition einer Sichtweise anzuzeigen oder eine neue Definition einer Sichtweise zu erzeugen. Das Menü für die Definition von Sichtweisen kann eine Vielzahl von Bildschirmanzeigen wie zum Beispiel diejenigen, die nachstehend mit Bezug auf die 5 bis 10 erörtert werden, umfassen. Auf diese Bildschirmanzeigen kann entweder von einem Hauptmenü (nicht gezeigt) oder aus anderen Bildschirmanzeigen zugegriffen werden. Auf die in 6 gezeigte Bildschirmanzeige mit allgemeinen Spaltenparametern für die Definition von Sichtweisen kann beispielsweise von der Bildschirmanzeige mit Standardparametern für die Definition von Sichtweisen von 5 zugegriffen werden, indem aus dem Menü 46 im unteren Bereich von 5 die Zahl "21" eingegeben wird.
  • Bei der Erzeugung einer neuen Definition einer Sichtweise oder der Bearbeitung einer vorhandenen Definition einer Sichtweise gelangt der Benutzer zu einer Bildschirmanzeige mit Standardparametern für die Definition von Sichtweisen, die die Standardparameter aufführt, die auf die Definition der Sichtweise angewendet werden. Bezug nehmend auf 5 gibt die Bildschirmanzeige mit Standardparametern für die Definition von Sichtweisen den logischen Datensatz Nr. 40, den Datenbereich des Suchlaufs 41 und die Auszugsdatei Nr. 42 an.
  • Um festzulegen, welche Spalten in die Auszugsdatei aufgenommen werden, wird auf die Bildschirmanzeige mit allgemeinen Spaltenparametern für die Definition von Sichtweisen zugegriffen. Jede Spalte in der Definition der Sichtweise wird ausgewiesen und fortlaufend nummeriert. Bezug nehmend auf 6 weist ein Spaltenkennungs-(ID-)Feld 50 die Nummer der Spalte (z. B. 1 bis 999) aus, deren Attribute im restlichen Teil der Bildschirmanzeige angegeben werden. Das Feld 51 mit der Bezeichnung "Feld-Nr." bezeichnet das Feld aus dem logischen Datensatz oder der Referenztabelle, das in der Spalte erscheint. Überdies können eine Spaltenüberschrift 52, die Spaltenbreite 53 usw. von dieser Bildschirmanzeige aus angegeben werden.
  • Bezug nehmend auf 7 ermöglicht eine Bildschirmanzeige zur Spaltenberechnung für die Definition von Sichtweisen, dass Berechnungen den Spalten zugeordnet werden, die in der Bildschirmanzeige mit allgemeinen Spaltenparametern für die Definition von Sichtweisen angegeben sind: Das Spalten-ID-Feld 60 bezeichnet die Spalte, in der der berechnete wert erscheinen soll, und die Felder "Operator" 61, "Code" 62 und "wert" 63 geben die durchzuführende Berechnung an. Das Feld "Operator" 61 stellt Symbole für Addition, Subtraktion, Multiplikation und Division bereit. Das Feld "Code" stellt Bezeichnungen für den aktuellen Spaltenwert (CL), den vorherigen Spaltenwert (PL) oder eine Konstante (CO) bereit. Das Feld "Wert" 63 gibt den Wert einer im Feld "Code" 62 angegebenen Konstanten an. Nehmen wir beispielsweise an, dass ein Benutzer die laufende Summe der Spalte 3 in der Spalte 4 verzeichnen möchte. Bezug nehmend auf 7 könnte dies wie folgt durchgeführt werden: Die Spaltenkennung(-ID) wäre die Spalte 4, im ersten Eintrag würde der Operator "+" und der Code "CL 03" lauten, und in einem zweiten Eintrag würde der Operator "+" und der Code "PL 04" lauten.
  • Bezug nehmend auf 8 wird eine Bildschirmanzeige mit allgemeinen Sortierparametern für die Definition von Sichtweisen zur Steuerung der Sortierebenen für die Definition der Sichtweise verwendet. Die "Sortierebenen" der Definition einer Sichtweise geben die Spalte aus dem logischen Datensatz oder der Referenzdatei an, nach der die Suchergebnisse sortiert werden. Wenn das Sortierfeld 70 von 8 beispielsweise "Kundenname" lautet, werden die Suchergebnisse beim Schreiben in die Auszugsdatei nach dem Kundennamen sortiert. wenn ein zweites Sortierfeld 70 als Ladengeschäft-Nummer festgelegt wäre, würden die Suchergebnisse zuerst nach dem Kundennamen und dann nach der Nummer des Ladengeschäfts sortiert werden.
  • Um bestimmte Daten aus der Auszugsdatei auszuschließen, ruft der Benutzer die Bildschirmanzeige mit allgemeinen Auswahlparametern für die Definition von Sichtweisen (9) auf. Diese Bildschirmanzeige erlaubt dem Benutzer, logische Datensätze mit Feldern, die ausgewählte Daten enthalten, in die Auszugsdatei aufzunehmen oder aus ihr auszuschließen. Wenn der Benutzer bespielsweise an Transaktionen unter US-$ 200 nicht interessiert wäre, würde die Feldziffer für das Feld "Betrag" des Transaktionsdatensatzes in das Feld 90 "FLD NUM" eingegeben werden, das Feld 81 "Auswahl von" würde auf "0" gesetzt werden, das Feld 82 "Auswahl bis" würde auf "200" gesetzt werden, und das Feld 83 "Aufnehmen/ausschließen" würde auf "E" für "Ausschließen" ("exclude") gesetzt werden. In den Fällen, in denen mehr als ein Auswahlkriterium für eine einzelne "Feldziffer" festgelegt wird, wird die "ODER"-Logik auf die Suchergebnisse angewendet. In den Fällen, in denen verschiedene Feldziffern festgelegt werden, wird die "UND"-Logik angewendet. Nehmen wir beispielsweise an, der Benutzer wäre nur an Transaktionen interessiert, bei denen der im Ladengeschäft 93 verkaufte Artikel einen Preis von US-$ 10 oder US-$ 1050 hatte. Unter der Annahme, dass Z04 das Feld "Ladengeschäft" und H22 das Feld "Preis" darstellt, und Bezug nehmend auf 9 kann das vorstehende Beispiel wie folgt ausgeführt werden: Wenn die Daten im Feld H22 des logischen Datensatzes (Eintrags) entweder 10 oder 1050 lauten und die Daten im Feld Z04 dieses Eintrags 93 lauten, wird dieser Eintrag in die Auszugsdatei aufgenommen.
  • Bezug nehmend auf 10 funktioniert eine Bildschirmanzeige mit Spaltenauswahlparametern in der gleichen weise wie die Bildschirmanzeige mit allgemeinen Auswahlparametern, außer dass die Bildschirmanzeige mit Spaltenauswahlparametern dem Benutzer ermöglicht, Daten von einer bestimmten Spalte aufzunehmen oder auszuschließen, indem er eine Spaltenkennung 85 angibt.
  • Mit einem einfachen Beispiel lassen sich die vorstehenden Merkmale vielleicht leichter veranschaulichen. Nehmen wir an, ein Benutzer möchte ein Dokument erstellen, das für die letzten 3 Jahre für jeden Kunden jeden gekauften Artikel, den Kaufbetrag und die Adresse sowie die Nummer des Ladengeschäfts auflistet, in dem der Artikel gekauft wurde.
  • Der Benutzer würde das Menü "Standardparameter für die Definition einer Sichtweise" aufrufen und die Kennung für die logische Datei "Kaufhistorie" eingeben. In 2a ist dies in der Tabelle (LR) das Nummernfeld 40. Im Feld 41 für den aktiven Datenbereich würde der Benutzer 01011991-99999999 (1. Januar 1991 bis heute) eingeben. Die restlichen Einträge könnten auf den gezeigten Standardwerten bleiben.
  • Der Benutzer würde dann die Bildschirmanzeige mit allgemeinen Spaltenparametern für die Definition von Sichtweisen (6) aufrufen. Für die Spaltenkennung 001 (Spalte 1) wird der Code für "Kunde", "PH 20" (logischer Datensatz der Kaufhistorie (L. R. 20), in das Feld Nummer 51 eingegeben. Im Feld 52 "Spaltenüberschrift" kann der Benutzer "KUNDE" ("CUSTOMER") eingeben. Der Benutzer drückt dann "1" für "neue Spalte" und gibt die Daten für die Spalte 2 (ID: 002) ein: Feld 51 = PH 23, was für "Artikel" steht; Feld 52 = "ARTIKEL" ("ITEM"); dann wieder "1", um Daten für die Spalte 3 (ID: 003) einzugeben: Feld 51 = PH 24 (was für "Preis" steht); Feld 52 = "PREIS" ("PRICE"); dann wieder "1", um Daten für die Spalte 4 (ID: 004) einzugeben: Feld 51 = PH 21 (was für "Ladengeschäft" steht); Feld 52 = "LADENGESCHÄFT NR." ("STORE NO"). Der Benutzer drückt dann "1", um Daten für die Spalte 5 (ID: 005) einzugeben. Da die fünfte Spalte die Spalte für die Adressen der Ladengeschäfte ist, würde das Feld Nr. 51 auf die Spalte 2 (Standort 26) der Referenztabelle "Ladengeschäft" 15 (RS 26) Bezug nehmen, und der Nachschlagepfad 54 wäre PH 21, d. h. stelle die Adresse oder den Standort (RS 26) für die Nummer des Ladengeschäfts (PH 21) in die fünfte Spalte. Die Spaltenüberschrift im Feld 53 könnte beispielsweise "STANDORT DES LADENGESCHÄFTS" lauten.
  • Der Benutzer würde dann die Bildschirmanzeige mit allgemeinen Sortierparametern für die Definition von Sichtweisen (8) aufrufen. Das Feld 70 "Sortiere" würde als PH 20 (Kunde) festgelegt werden, um anzuzeigen, dass die Auszugsdatei nach dem Kundennamen sortiert wird.
  • Eine resultierende Auszugsdatei für das obige Beispiel würde 5 Spalten mit der Bezeichnung KUNDE, ARTIKEL, PREIS, LADENGESCHÄFT NR. UND STANDORT DES LADENGESCHÄFTS aufweisen. Die sich ergebenden Einträge, die aus der logischen Datei "Kaufhistorie" und der Referenztabelle "Ladengeschäft" abgerufen werden, werden nach dem Kundennamen aufgelistet, wie in 4 gezeigt ist.
  • Eine Definition einer Sichtweise, die in der vorstehend beschriebenen Weise festgelegt wurde, wird automatisch in verschiedene Einträge in der Logiktabelle umgesetzt. Die Umwandlung der in die Bildschirmanzeigen der Sichtweisen (5 bis 10) eingegebenen Daten in eine Logiktabelle wird nun beschrieben, wobei nochmals das vorstehend beschriebene und in den 3 bis 10 veranschaulichte Beispiel verwendet wird. 11 zeigt die Logiktabelle von 3 ausführlicher.
  • Gemäß 11 umfasst jede Zeile einer Logiktabelle eine Vielzahl von Feldern. Das erste Feld 100 enthält die Nummer der Zeile der Logiktabelle. Das zweite Feld ist das Feld DDname 101, das die physische Datei angibt, die die Quelle der logischen Datensätze für die Sichtweise ist. Der Wert dieses Feldes wird aus der Tabellen-(LR-)Nummer 40 der Bildschirmanzeige mit den Standardparametern (5) erzeugt. Dieses Feld hat denselben Wert für jede Zeile eines Satzes in der Logiktabelle. Das dritte Feld lautet "Sichtweisennummer" 103 und enthält die Nummer der Sichtweise (das Element 45 in 5), die vom Prozessorsystem jeder Sichtweise fortlaufend zugewiesen wird.
  • Bezug nehmend auf 5, werden die Einträge im Menü "Standardparameter" wie folgt in Einträge in der Logiktabelle umgewandelt. Eine neue Anforderungszeile wird erstellt, indem in das Funktionscodefeld 104 "NR" eingegeben wird. Die automatisch erzeugte Nummer der Sichtweisen-Definition wird in das Sichtweisennummernfeld 103 für jede Zeile eingegeben, die zu dieser Sichtweise gehört. Der Wert des Feldes Tabellen-(LR-)Nummer 40 wird in die Felder 101 und 107 einer jeden Zeile der Logiktabelle überführt, wobei das Feld 101 die physische Datei angibt, in der sich die logischen Datensätze befinden, und das Feld 107 die Art des logischen Datensatzes angibt. Der Wert des Feldes 41 für den aktiven Datenbereich dient zur Feststellung, welche physischen Dateien des logischen Datensatzes für diese Sichtweise benötigt werden. Wenn mehr als eine physische Datei für die Sichtweise benötigt wird, werden alle Zeilen für die Sichtweise in die anderen Sätze kopiert, wie nachstehend erklärt wird. Das Feld 42 für die Kennung der Auszugsdatei wird in ein entsprechendes Auszugsdatei-Nummernfeld im Werte-Feld 120 der NR-Zeile kopiert.
  • Bezug nehmend auf die Bildschirmanzeige mit allgemeinen Spaltenparametern von 6 wird jedes Spaltenkennungsfeld 50 in eine getrennte Zeile der Logiktabelle kopiert. Bezug nehmend auf 11 enthält die Zeile 2 einen Funktionscode "DT", um anzugeben, dass diese Zeile eine Spalte festlegt, deren Inhalt aus dem logischen Datensatz abgerufen werden soll. Das Sortierspaltennummernfeld 105 gibt an, dass die Zeile 3 die erste Spalte der Auszugsdatei festlegt (Spaltenkennung 001 vom Feld 50 von 6). Das Feld 108 "Feldnummer" wird vom Feld 51 "Feldnummer" der Bildschirmanzeige mit den allgemeinen Spaltenparametern abgeleitet. Die Zeile 2 enthält auch Daten in Bezug auf das Format der Spalte im Werte-Feld 120, zum Beispiel die Spaltenbreite für die Spalte 1 vom Spaltenbreitenfeld 53. Die Zeilen 3 bis 5 geben in ähnlicher Weise den Inhalt der Spalten 2, 3 und 4 der Auszugsdatei an.
  • Die Zeile 6 enthält die Daten bezüglich der Sortierkriterien, die im Menü mit den allgemeinen Sortierparametern von 8 angegeben werden. Der Funktionscode KT gibt an, dass die Auszugsdatei nach einem Feld aus einem logischen Datensatz sortiert wird. Das Sortierspaltenfeld 105 gibt die Sortiernummer (in diesem Fall "1" an, weil es die erste Sortierung ist) an, und das Feld Nr. 108 gibt das Feld des logischen Datensatzes an, nach dem die Auszugsdatei sortiert wird. Diesen Eintrag erhält man aus dem Sortierfeld 70 der Bildschirmanzeige mit den allgemeinen Sortierparametern von 8.
  • Die Zeile 7 ist eine Zeile eines Schreibdatensatzes (WR). Die WR-Zeile weist das System an, eine Datenzeile in die Auszugsdatei zu schreiben, die in der vorhergehenden NR-Zeile (Zeile 1) angegeben ist.
  • Die Zeile 8 ist eine NR-Zeile für eine zweite Sichtweise (Sichtweise Nr. 2). Die Definition dieser Sichtweise ist in den Zeilen 8 bis 20 enthalten. Die Zeile 21 gibt das Ende des Satzes (ES) an. Damit sind die Einträge in der Logiktabelle für die physische Datei 11 abgeschlossen.
  • Die Zeile 21 beginnt einen zweiten Satz, der der physischen Datei 12 der logischen Datei 10 entspricht. In dem Beispiel von 11 gab der in das Feld 41 des Standardparameter-Menüs für die Sichtweise 1 eingegebene aktive Datenbereich an, dass die zweite physische Datei des logischen Datensatzes für den Suchlauf benötigt würde. Folglich werden die Definitionen der Sichtweisen der Zeilen 1 bis 7 des Satzes 1 automatisch in die Zeilen 22 bis 28 des Satzes 2 kopiert. Das Feld DDname 101 wird jedoch geändert, um die physische Datei 12 statt der physischen Datei 11 auszuweisen. Da der aktive Datenbereich der Sichtweise 2 keine Daten von der physischen Datei 2 benötigt, werden die Zeilen 8 bis 20 nicht in den Satz 2 kopiert. Ebenso erscheint die Sichtweise 3 nur in dem zweiten Satz, da der aktive Datenbereich der Sichtweise 3 Daten von der physischen Datei 2, aber nicht von der physischen Datei 1 benötigt. Die Zeile 40 ist eine Ende-der-Logiktabelle-Zeile (EN), die angibt, dass das Ende der Logiktabelle erreicht wurde.
  • Um einige der anderen vorstehend mit Bezug auf die 5 bis 10 erörterten Funktionen auszuführen, werden zusätzliche Funktionsfelder bereitgestellt. Zum Beispiel können in der Bildschirmanzeige mit allgemeinen Auswahlparametern oder der Bildschirmanzeige mit Spaltenauswahlparametern angegebene Auswahlwerte, die einen einzelnen Wert auswählen, unter Verwendung eines Funktionscodes "SE" angewendet werden, der die Feld-Nummer 80 oder 90 (der 9 oder 10) in das Feld Nummer 108 eingibt und den auszuwählenden Wert in das Werte-Feld 120 eingibt. Ebenso können in der Bildschirmanzeige mit allgemeinen Auswahlparametern oder der Bildschirmanzeige mit Spaltenauswahlparametern angegebene Auswahlwerte, die einen Wertebereich angeben, mit Hilfe eines Funktionscodes "ST" angewendet werden, der die Feld-Nummer 80 in das Feld Nummer 108 eingibt und den auszuwählenden oder den auszuschließenden Wertebereich in das Werte-Feld 120 eingibt. Um die allgemeinen Auswahlparameter anzuwenden, folgt die ST- oder die SE-Zeile unmittelbar auf die NR-Zeile. Um Spaltenauswahlparameter anzuwenden, geht die ST- oder die SE-Zeile der DT-Zeile unmittelbar voraus, die die Spalte erzeugt.
  • Das Aufnehmen/Ausschließen-Feld (83, 93) der Menüs mit den allgemeinen und den Spaltenauswahlparametern wird mit Hilfe des GO-TO-TRUE-Felds 140 und des GO-TO-FALSE-Felds 141 realisiert. Wenn wir beispielsweise einen logischen Datensatz (Eintrag) mit Hilfe der vorstehend erörterten ST- oder SE-Zeilen ausschließen möchten, kann die Ausschlussfunktion mit eine Sprunganweisung GO-TO-FALSE zur nachfolgenden Zeile und einer Sprunganweisung GO-TO-TRUE zur nächsten NR-Zeile (der nächsten Sichtweise) ausgeführt werden. Wenn der logische Datensatz die von der ST- oder der SE-Zeile angegebenen Auswahlkriterien erfüllt, springt der Thread folglich zur nächsten NR-Zeile, und der Eintrag wird ausgeschlossen. Andernfalls schaltet der Thread zur nächsten Zeile der Logiktabelle. Ebenso kann eine Aufnahmefunktion mit einer Sprunganweisung GO-TO-FALSE zur nächsten NR-Zeile und einer Sprunganweisgung GO-TO-TRUE zur nachfolgenden Zeile ausgeführt werden.
  • Wenn die vorstehenden Funktionen mit Hilfe von Daten aus einer Referenztabelle anstelle des logischen Datensatzes ausgeführt werden sollen, ist die Prozedur ähnlich. Bevor eine Referenztabelle verwendet werden kann, müssen jedoch eine oder mehrere Nachschlagefunktionen ausgeführt werden, um die Daten in der Referenztabelle mit den Daten des logischen Datensatzes in Beziehung zu setzen.
  • Nehmen wir beispielsweise an, dass der Benutzer zusammen mit jeder Nummer eines Ladengeschäfts, die der logischen Datei "Kaufhistorie" 10 entnommen wurde, den entsprechenden Standort des Ladengeschäfts in der Spalte 5 anzeigen möchte. Die Daten über den Standort des Ladengeschäfts sind in der Referenztabelle "Ladengeschäft" 15 enthalten. Bezug nehmend auf 11A wird in der Zeile 2 (die in der Spalte 100 angegeben wird) ein Funktionscode "BC" (Spalte 104) verwendet, um den Zugriff auf eine Referenztabelle zu bezeichnen, der die Adresse des Ladengeschäfts zu entnehmen ist. Die Referenztabellen-Nummer der Referenztabelle "Ladengeschäft" wird in das Feld "Wert" 120 eingegeben, und das Nachschlagefeld 109 wird auf "Y" gesetzt. In der Zeile 3 weist dann ein Funktionscode "BT" (Spalte 104), der mit der im Feld 108 angegebenen Feld-Nr. verwendet wird, die Spalte des logischen Datensatzes aus, aus der der Schlüssel erstellt werden soll, d. h. die Spalte mit der Nummer des Ladengeschäfts, die durch den Code "20" dargestellt wird. Mit dem aktuellen Inhalt der Spalte "Ladengeschäft Nr." wird anschließend ein Eintrag in der Referenztabelle "Ladengeschäft" nachgeschlagen. Wenn der Inhalt der Spalte "Ladengeschäft Nr." beispielsweise das Ladengeschäft Nr. 9 ausweisen würde, würde in der Zeile 4 ein Funktionscode "RL" (Spalte 104) verwendet werden, um einen Suchlauf in der Referenztabelle "Ladengeschäft" nach dem Eintrag für das Ladengeschäft 9 zu starten und den ganzen Eintrag für das Ladengeschäft 9 aus der Referenztabelle "Ladengeschäft" zu lesen.
  • Schließlich weist in der Zeile 5 ein Funktionscode "DL" (der dem Funktionscode "DT" entspricht, der vorstehend mit Bezug auf aus logischen Datensätzen abgerufene Daten beschrieben wurde) das System an, ein ausgewähltes Feld aus dem abgerufenen Referenztabelleneintrag als Inhalt der Spalte 5 (Sortierspalte 105 = 5) zu speichern. Das ausgewählte Feld aus dem abgerufenen Eintrag wird in der Spalte 108 ausgewiesen. In diesem Beispiel enthält das Feld "20" des Referenztabelleneintrags Daten über den Standort des Ladengeschäfts. Da der Funktionscode "DL" nur für Spalten gilt, die aus Daten der Referenztabelle erzeugt wurden, weiß das System, dass der Inhalt der Spalte 108 das ausgewählte Feld des abgerufenen Referenztabelleneintrags ausweist.
  • Nochmals Bezug nehmend auf 3 enthält die Logiktabelle eine Vielzahl von Sätzen. Jeder Satz kann wiederum eine Vielzahl von Sichtweisen enthalten. Jeder der Vielzahl der Sichtweisen muss der physischen Datei entsprechen, auf die der Satz verweist. Wie vorstehend mit Bezug auf 5 erklärt wurde, kann die Definition einer Sichtweise auch Datumsbeschränkungen enthalten. Wenn die Definition einer bestimmten Sichtweise zum Beispiel eine Datumsbeschränkung mit der Anweisung, nur Dateien für das laufende Jahr zu durchsuchen, enthielte, würde diese Definition der Sichtweise nur in dem ersten Satz erscheinen. Wenn die Definition einer zweiten Sichtweise keine Datumsbeschränkung hätte, würden die Definition dieser Sichtweise sowie alle nachfolgenden Einträge für die Definition dieser Sichtweise automatisch in den zweiten und den dritten Satz kopiert werden (unter der Annahme, dass die logische Datei 3 physische Dateien hat).
  • Jeder Satz der Logiktabelle entspricht einem getrennten "Thread". Ein Thread ist ein einzelner fortlaufender Steuerungsfluss. Als solches kann ein einzelner Thread zu einem bestimmten Zeitpunkt nur einen einzigen Ausführungspunkt haben, d. h., ein einzelner Thread kann höchstens immer nur einen Befehl ausführen. Wenn man jedoch mehrere Threads vorsieht, kann ein einzelnes Programm mehrere Ausführungspunkte haben, einen für jeden Thread. Gemäß der vorliegenden Erfindung werden eine Vielzahl von Threads, einer für jeden Satz in der Logiktabelle, parallel ausgeführt.
  • Wenn eine Logiktabelle beispielsweise drei Threads (d. h. drei Sätze) und der Rechner drei Prozessoren hat, kann jeder Thread von einem anderen Prozessor ausgeführt werden. Da jeder Thread einer anderen physischen Datei 11 bis 13 der logischen Datei 10 entspricht, kann jeder Thread seine jeweilige physische Datei 11 bis 13 parallel mit den anderen Threads verarbeiten und dadurch die Leistungsfähigkeit erheblich steigern.
  • Sobald die Logiktabelle erzeugt wurde, arbeitet sie im Wesentlichen als ein Quellenprogramm, dessen Konsistenz die Art und Weise steuert, in der das System die Datenbank verarbeitet, wobei die Felder GO-TO-TRUE und GO-TO-FALSE den Ablauf steuern, nach dem die Zeilen der Logiktabelle vom System realisiert werden.
  • Genauer gesagt, die Einträge in der Logiktabelle werden wie folgt in Maschinencode übersetzt: Bezug nehmend auf 16 hat jede Zeile 31 der Logiktabelle 30 einen ihr angefügten Adressvorsatz 32, der der Anfangsadresse 320 eines Maschinencode-Segments entspricht, das die Befehle zur Realisierung der Zeile der Logiktabelle umfasst. Der Vorsatz 32 einer jeden Zeile der Logiktabelle gestattet den Codesegmenten 300 den Zugriff auf die Logiktabelle und die Verwendung der Felder der Zeilen 31 der Logiktabelle als Daten.
  • Für jeden Thread, der die Maschinencode-Befehle umfasst, die aus seinem jeweiligen Satz der Logiktabelle erzeugt wurden, erfolgt entsprechend der Folge von Befehlen, die in der Logiktabelle erzeugt wurden, wie vorstehend beschrieben wurde, ein einziger Durchlauf durch die jeweilige physische Datei. Während dieses einzigen Durchlaufs werden alle Sichtweisen in dem entsprechenden Satz in einer Abfolge verarbeitet, die von den Einträgen in der Logiktabelle, insbesondere den Feldern GO-TO-TRUE/GO-TO-FALSE 140 bis 141 der Zeilen der Logiktabelle, vorgegeben wird.
  • Nehmen wir beispielsweise Bezug auf die Logiktabelle von 11, in der die Zeilen 1 bis 6 im Satz 31 die Sichtweise 1 und die Zeilen 8 bis 20 eine Sichtweise 2 bilden; im Satz 32 werden die Zeilen 22 bis 28 von den Zeilen 1 bis 6 kopiert und legen die Sichtweise 1 fest, und die Zeilen 29 bis 38 legen eine Sichtweise 3 fest. Jede der Zeilen 1 bis 40 wird in Segmente des Maschinencodes 300 umgesetzt, wie in 16 veranschaulicht ist.
  • Der Thread 1 ist der physischen Datei 11 zugeordnet und entspricht dem Satz 31, der die Sichtweisen 1 und 2 enthält. Der Thread 1 greift auf einen ersten Eintrag der physischen Datei 11 zu und führt die folgenden Schritte durch:
    • 1. Lege die Auszugsdatei Nr. 01 für die Sichtweise 1 fest (Zeile 1 "nr"); erzeuge einen Auszugseintrag für die Sichtweise 1, indem: das Feld "Kunde" 20 in die Spalte 1 des Auszugseintrags gestellt wird (Zeile 2 "DT"); das Feld "Artikel" 23 in die Spalte 2 des Auszugseintrags gestellt wird (Zeile 3 "DT"), das Feld "Preis" 24 in die Spalte 3 des Auszugseintrags gestellt wird (Zeile 4 "DT"); das Feld "Ladengeschäft Nummer" 21 in die Spalte 4 des Auszugseintrags gestellt wird (Zeile 4 "DT"); der Kundenname 20 (Zeile 5 "KT") in Vorbereitung der Sortierung des Auszugseintrags mit Auszugseinträgen, die zuvor in die Auszugsdatei geschrieben wurden, in das Feld "Sortierschlüssel" gestellt wird; der Auszugseintrag an die richtige Stelle in der festgelegten Auszugsdatei geschrieben wird (Zeile 7 "WR");
    • 2. lege die Auszugsdatei Nr. 02 für die Sichtweise 2 fest (Zeile 8 "nr"); erzeuge einen Auszugseintrag für die Sichtweise 2, indem die Anweisungen der Zeilen 8 bis 19 (nicht gezeigt) ausgeführt werden; schreibe den Auszugseintrag an die richtige Stelle in der Auszugsdatei 02 (Zeile 20 "WR"); und
    • 3. wiederhole die Schritte 1 und 2 für den nächsten Eintrag in der physischen Datei 11.
  • Der Thread 2 ist der physischen Datei 12 zugeordnet und entspricht dem Satz 32, der die Sichtweisen 1 und 3 enthält. Der Thread 2 arbeitet parallel zum Thread 1, wobei er auf einen ersten Eintrag der physischen Datei 12 zugreift und die folgenden Schritte durchführt:
    • 1. Lege die Auszugsdatei Nr. 01 für die Sichtweise 1 fest (Zeile 22 "nr"); erzeuge einen Auszugseintrag für die Sichtweise 1, indem: das Feld "Kunde" 20 in die Spalte 1 des Auszugseintrags gestellt wird (Zeile 23 "DT"); das Feld "Artikel" 23 in die Spalte 2 des Auszugseintrags gestellt wird (Zeile 24 "DT"), das Feld "Preis" 24 in die Spalte 3 des Auszugseintrags gestellt wird (Zeile 25 "DT"); das Feld "Ladengeschäft Nummer" 21 in die Spalte 4 des Auszugseintrags gestellt wird (Zeile 26 "DT"); der Kundenname 20 (Zeile 27 "KT") in Vorbereitung der Sortierung des Auszugseintrags mit Auszugseinträgen, die zuvor in die Auszugsdatei geschrieben wurden, in das Feld "Sortierschlüssel" gestellt wird; der Auszugseintrag an die richtige Stelle in der festgelegten Auszugsdatei geschrieben wird (Zeile 28 "WR");
    • 2. lege die Auszugsdatei Nr. 03 für die Sichtweise 3 fest (Zeile 29 "nr"); erzeuge einen Auszugseintrag für die Sichtweise 3, indem die Anweisungen der Zeilen 30 bis 38 (nicht gezeigt) ausgeführt werden; schreibe den Auszugseintrag an die richtige Stelle in der Auszugsdatei 03 (Zeile 38 "WR"); und
    • 3. wiederhole die Schritte 1 und 2 für den nächsten Eintrag in der physischen Datei 12.
  • Sobald die Threads die vorstehende Prozedur abgeschlossen haben, wird jede Auszugsdatei entsprechend den Sortierfeldern sortiert, die von jeder Definition einer Sichtweise angegeben werden.
  • Folglich wird ein benutzerspezifisches Programm erzeugt, mit dem eine logische Datei einer Ereignisdatenbank durchlaufen wird. Indem einzelne Threads für jede einzelne physische Datei erzeugt werden, die in dem logischen Datensatz durchsucht wird, können außerdem einige oder alle der physischen Dateien von einzelnen Threads gleichzeitig verarbeitet werden, wodurch sich die Geschwindigkeit, mit der die Datenbank durchsucht wird, erhöht. Überdies wird die Verarbeitungszeit weiter verringert, weil jede physische Datei ungeachtet der Anzahl der in Bezug auf jede physische Datei festgelegten Sichtweisen nur einmal durchlaufen wird.
  • Die Verarbeitungszeit wird durch eine leistungsfähige Verwaltung der Eingabepufferspeicher, der Ausgabepufferspeicher und der Referenzdateiinformationen noch weiter herabgesetzt. Indem eine Funktion in Form von einer überlappten Ein-/Ausgabe gemäß einer Ausführungsform der vorliegenden Erfindung genutzt wird, wird insbesondere die gesamte Verarbeitungszeit für das Durchlaufen einer logischen Datei verringert, indem die Größe der Eingabe- und Ausgabepufferspeicher nach der Art des physischen Mediums gewählt wird, in dem die physischen Dateien der logischen Datei gespeichert werden. Indem im Hauptspeicher ein Referenztabellen-Teilsatz erzeugt wird, der nur ausgewählte Teile der Referenztabellen enthält, die von der Logiktabelle benötigt werden, kann außerdem die Notwendigkeit, von externen Speichereinheiten auf Referenztabellen zugreifen zu müssen, erheblich reduziert und in manchen Fällen völlig überflüssig gemacht werden.
  • Sobald die Logiktabelle erzeugt wurde (aber bevor der Maschinencode erzeugt oder die logischen Datensätze verarbeitet wurden), werden die Eingabe- und Ausgabepufferspeicher für den Prozess zugeordnet.
  • Um den logischen Datensatz 10 zu verarbeiten, müssen die in den physischen Dateien 11 bis 13 enthaltenen Ereignisdaten von ihrem externen Medium (z. B. einem Festplatten- oder Bandlaufwerk) in die Eingabepufferspeicher im Hauptspeicher geladen werden.
  • Gemäß einer Ausführungsform der vorliegenden Erfindung wird die Verarbeitungszeit weiter verringert, indem eine Funktion in Form von einer überlappten Ein-/Ausgabe für die Eingabepufferspeicher bereitgestellt wird. Bezug nehmend auf 12 wird für jeden Satz 31 bis 33 der Logiktabelle 30 ein Satz von Eingabepufferspeichern 200 zugeordnet, so dass jeder Thread an einem getrennten Satz von Eingabepufferspeichern Operationen ausführt. Gemäß einer Ausführungsform der vorliegenden Erfindung wird für jeden Thread eine Vielzahl von Pufferspeichern 220, 230, 240, 250 bereitgestellt, und jeder Pufferspeicher 220 bis 240 hält einen Datenblock 300n .
  • Die Größe eines Datenblocks 300n wird in Abhängigkeit von den physischen Eigenschaften der physischen Datei 11 gewählt, um eine weitere Verringerung der Verarbeitungszeit zu ermöglichen. Eine der zeitaufwändigsten Aufgaben bei der Verarbeitung einer großen Datei sind Datenübertragungen an und von externen Einheiten. Darüber hinaus ist die zeitaufwändigste Aufgabe in Verbindung mit einer Übertragung an/von einem Platten- oder Bandlaufwerk die Bewegung der mechanischen Komponenten des Laufwerks selbst.
  • Indem Datenblöcke von der physischen Datei in die Eingabepufferspeicher in derselben Reihenfolge übertragen werden, in der sie abgelegt werden, werden Verzögerungen in Verbindung mit dem Schalten von einem Block zum nächsten als solches auf ein Minimum herabgesetzt.
  • Sobald der Thread den Block 3001 in den Pufferspeicher 220 lädt, beginnt die Verarbeitung des Inhalts des Pufferspeichers 220. Während der Thread 1 den Inhalt des Pufferspeichers 220 verarbeitet, füllt jedoch ein anderer Prozessor in dem System den Pufferspeicher 230 mit dem Block 3002 . Bis der Thread 1 mit der Verarbeitung des Blocks 3004 fertig ist, wurde der Pufferspeicher 220 optimalerweise schon mit dem Block 5 neu geladen. Die Verarbeitungsgeschwindigkeit wird als Folge dieser Funktion in Form der überlappten Ein-/Ausgabe gemäß einer Ausführungsform der vorliegenden Erfindung weiter verbessert.
  • Auf der Grundlage der Logiktabelle werden neben der Zuordnung von Eingabepufferspeichern auch Sätze von Ausgabepufferspeichern 400 zugeordnet, wie in 13 gezeigt ist. Jeder Satz von Ausgabepufferspeichern 500 entspricht einer einzelnen Auszugsdatei. wie vorstehend erörtert wurde, legt jede Sichtweise eine Auszugsdatei fest, um die Ergebnisse des Prozesses für diese Sichtweise festzuhalten. Die Nummer der Auszugsdatei wird aus der Bildschirmanzeige mit Standardparametern für die Definition von Sichtweisen ausgewählt und erscheint in einem Feld "Auszugsdatei Nr." des Werte-Felds 120 der entsprechenden NR-Zeile der Logiktabelle. Ein Satz von Ausgabepufferspeichern 500 wird für jede in der Logiktabelle festgelegte Auszugsdatei zugeordnet.
  • Da die Ausgabepufferspeicher 500 nicht nach der Thread-Nummer, sondern nach der Nummer der Auszugsdatei getrennt sind, kann der Ausgabepufferspeicher 500 für eine Auszugsdatei Daten von vielen verschiedenen Threads und von vielen verschiedenen Sichtweisen halten. Alle Daten für eine bestimmte Sichtweise werden vorzugsweise jedoch in den Satz von Ausgabepufferspeichern 500 einer einzigen Auszugsdatei geschrieben, da diese Daten schließlich in eine einzige Ausgabedatei geschrieben werden.
  • Bezug nehmend auf 13 enthält die Auszugsdatei 1000 einen Satz von Ausgabepufferspeichern 500. Der Satz von Ausgabepufferspeichern 500 enthält wiederum eine Vielzahl von Pufferspeichern 520, 530, 540, 550. Wie bei den Pufferspeichern 220 bis 250 von 12 hält jeder der Pufferspeicher 520 bis 550 einen einzigen Datenblock, wobei die Größe des Datenblocks in Abhängigkeit von der Art des physischen Mediums festgelegt wird, auf das die Auszugsdatei 1000 geschrieben wird.
  • Die Auszugsdatei 1000 wird wie folgt verarbeitet. Ein Zeiger 560 zeigt anfangs zum Beispiel auf den Pufferspeicher 520. Während der Zeiger 560 auf den Pufferspeicher 520 zeigt, schreibt ein Thread, der gerade eine Schreibfunktion (WR-Zeile der Logiktabelle) in die Auszugsdatei 1000 ausführt, Daten an den nächsten verfügbaren Speicherplatz im Pufferspeicher 520. Wenn dieser Thread feststellt, dass der Pufferspeicher 520 voll ist, bewegt er den Zeiger auf den Pufferspeicher 530 und leitet dann eine Übertragung des Datenblocks im Pufferspeicher 520 an ein festgelegtes externes Medium ein.
  • Während der Inhalt des Pufferspeichers 520 auf ein externes Medium 580 geschrieben wird, können Daten folglich immer noch in den Pufferspeicher 530 geschrieben werden. Da die Größe der Pufferspeicher 520 bis 550 in Abhängigkeit von den physischen Eigenschaften des externen Mediums 580 festgelegt wird, wird der für die Übertragung von Daten aus dem Pufferspeicher 520 bis 550 erforderliche Zeitraum überdies auf ein Minimum herabgesetzt.
  • Wie vorstehend dargelegt wurde, wird die Verarbeitungszeit gemäß einer anderen Ausführungsform der vorliegenden Erfindung weiter verringert, indem im Hauptspeicher ein Referenztabellen-Teilsatz erzeugt wird, der nur ausgewählte Teile der Referenztabellen enthält, die von der Logiktabelle benötigt werden, wodurch die Notwendigkeit, von externen Speichereinheiten auf Referenztabellen zugreifen zu müssen, reduziert oder überflüssig gemacht und die Verarbeitungszeit verringert wird.
  • Nachdem die Eingabe- und Ausgabepufferspeicher zugeordnet wurden, wie vorstehend beschrieben wurde (und bevor der Maschinencode erzeugt und durchsucht wird), lädt das System die benötigten Daten ganz oder teilweise aus den Referenztabellen in den Hauptspeicher. Ebenso wie logische Datensätze werden Referenztabellen auf externen Medien wie zum Beispiel Festplatten oder auf Band gespeichert. Sobald die Logiktabelle erzeugt wurde, stellt das System fest, welche Spalten von welchen Referenztabellen benötigt werden, um den Prozess abzuschließen. Sobald diese Feststellung erfolgt ist, bildet das System einen Referenztabellen-Teilsatz im Hauptspeicher, der nur die Spalten der Referenztabellen enthält, die zur Verarbeitung benötigt werden.
  • Bezug nehmend auf 14 nehmen wir an, dass eine Logiktabelle 600 Zeilen enthält, die auf die Referenztabelle "Region" 700 und die Referenztabelle "Ladengeschäft" 800 verweisen. Die Referenztabelle "Region" 700 enthält Spalten für "Ladengeschäft", "Region", "durchschnittliches Einkommen" und "durchschnittliches Alter". Die Referenztabelle "Ladengeschäft" 800 enthält Spalten für "Ladengeschäft", "Standort" und "Filialleiter". Nehmen wir an, dass die Logiktabelle 600 nur Zeilen enthält, die auf die Spalten "Ladengeschäft" und "Filialleiter" der Referenztabelle "Ladengeschäft" und auf die Spalten "Ladengeschäft", "Region" und "Einkommen" der Referenztabelle "Region" verweisen.
  • Gemäß der vorstehend erwähnten Ausführungsform der vorliegenden Erfindung wird ein Referenztabellen-Teilsatz 900 im Speicher erzeugt, der einen Teil "Ladengeschäft-Tabelle" 910 und einen Teil "Region-Tabelle" 920 enthält, wobei die Spalten "Ladengeschäft" und "Filialleiter" der Referenztabelle "Ladengeschäft" 800 im Teil "Ladengeschäft-Tabelle" 910 und die Spalten "Ladengeschäft", "Region" und "Einkommen" der Referenztabelle "Region" 800 im Teil "Region-Tabelle" 920 gespeichert werden.
  • Wenn eine benötigte Referenztabelle nicht in den für den Referenztabellen-Teilsatz 900 zugeteilten Platz passt, wird auf diese Referenztabelle während des Suchlaufs vom physischen Speicher aus zugegriffen.
  • Indem so viele der benötigten Referenztabellen wie möglich in dem Referenztabellen-Teilsatz 900 gespeichert werden, wird die Verarbeitungszeit weiter verringert, da die Notwendigkeit entfällt, Daten während des Suchlaufs von einem externen Medium abzurufen.
  • Sobald der Referenztabellen-Teilsatz 900 erzeugt wurde, wird für jeden Thread ein Satz von Verarbeitungsparameter-Zeigern gebildet. Jeder Thread 950 enthält einen Verarbeitungsparameter-Zeiger 960 für jede Referenztabelle (910, 920) in dem Referenztabellen-Teilsatz 900, die dieser Thread benötigt, um seinen Suchlauf durchzuführen. In dem in 14 gezeigten Beispiel enthält die Logiktabelle drei Sätze, den Satz1 610, der dem Thread1 950 entspricht und die Referenztabelle "Region" benötigt, den Satz2 620, der dem Thread2 950 entspricht und die Referenztabelle "Ladengeschäft" sowie die Referenztabelle "Region" benötigt, und den Satz3 630, der dem Thread3 950 entspricht und keine Referenztabelle in dem Referenztabellen-Teilsatz 900 benötigt.
  • Die Verarbeitungsparameter-Zeiger 960 werden anfangs auf die Stelle in der Mitte ihrer jeweiligen Tabellen in dem Referenztabellen-Teilsatz gesetzt. Am ersten Punkt in dem Suchlauf, an dem auf eine Referenztabelle zugegriffen wird, d. h. der ersten RL-Zeile des Satzes in der Logiktabelle, wird auf den Eintrag an der Stelle in der Mitte zugegriffen. Wenn der Eintrag nicht der Anforderung entspricht, wird der Verarbeitungsparameter-Zeiger 960 auf eine Stelle in der Mitte zwischen der vorherigen Position und dem Anfang des Referenztabellenteils (910 oder 920) bewegt, wenn die vorherige Position zu niedrig war, und an eine Stelle in der Mitte zwischen der vorherigen Position und dem Ende des Referenztabellenteils (910 oder 920), wenn die vorherige Position zu hoch war, bis der richtige Eintrag erreicht wird. Auf diese Weise wird durch einen Teil des Referenztabellen-Teilsatzes ein Binärsuchlauf durchgeführt, um den angeforderten Eintrag aufzufinden.
  • Bezug nehmend auf 15 wird die Referenztabelle "Ladengeschäft" 800 an den Adressplätzen OFF-103hex im externen Medium 1000 lokalisiert, und die Referenztabelle "Region" 700 wird an den Adressplätzen 9FF-A07hex im externen Medium 1001 lokalisiert. Wenn die Referenztabelle "Ladengeschäft" 800 und die Referenztabelle "Region" 700 in den Referenztabellen-Teilsatz 900 kopiert werden, werden die Ergebnisse der vorstehend erwähnten Binärsuche für jeden Referenztabellen-Speicherplatz 985 vorab in einen ersten und einen zweiten Vorsatz 981, 982 dieses Speicherplatzes 985 codiert.
  • Da beispielsweise der Referenztabellen-Speicherplatz auf halbem weg zwischen dem Referenztabellen-Speicherplatz 101 und dem Anfang des Teils 910 "Ladengeschäft-Tabelle" der Speicherplatz 100 ist, lautet der erste Vorsatz 981 des Referenztabellen-Speicherplatzes 101 "100". Ebenso lautet der zweite Vorsatz 981 des Referenztabellen-Speicherplatzes 101 "102", da der Referenztabellen-Speicherplatz auf halbem Weg zwischen dem Referenztabellen-Speicherplatz 101 und dem Ende des Teils 910 "Ladengeschäft-Tabelle" der Speicherplatz 102 ist.
  • Anfangs werden die Verarbeitungsparameter-Zeiger 960 auf die Stelle in der Mitte ihrer jeweiligen Referenztabellenteile 910, 920 gesetzt, d. h. auf 101hex für die Referenztabelle "Ladengeschäft" und auf A03hex für die Referenztabelle "Region".
  • Wenn der Thread 2 zum ersten Mal auf den Referenztabellen-Teilsatz für die Tabelle "Ladengeschäft" zugreift, greift er auf den Speicherplatz 101hex zu. Nehmen wir beispielsweise an, dass der Thread 2 entsprechend den Einträgen des zweiten Satzes der Logiktabelle nach einer entsprechenden Adresse des Ladengeschäfts Nummer 94 sucht.
  • Wenn der Speicherplatz 101 Hex den Eintrag für das Ladengeschäft 94 hat, wird der Standort des Ladengeschäfts abgerufen, und der Zeiger 960 für den Teil 910 "Ladengeschäft-Tabelle" bleibt auf 101hex. Wenn der Speicherplatz 101hex beispielsweise jedoch den Eintrag für das Ladengeschäft 74 hat, wird der Zeiger 960 auf den Wert gesetzt, der in dem zweiten Vorsatz des Speicherplatzes 101hex gespeichert ist (der, wie vorstehend beschrieben wurde, einer Stelle in der Mitte zwischen 101hex und 103hex entspricht), und der Prozess wird wiederholt, bis der Eintrag für das Ladengeschäft 94 aufgefunden wird.
  • Durch das Hinzufügen des ersten und des zweiten Vorsatzes zum Referenztabellen-Teilsatz wird die Verarbeitungsgeschwindigkeit des Systems gemäß der vorliegenden Erfindung folglich noch weiter erhöht, da dadurch die Notwendigkeit entfällt, während des Suchvorgangs den nächsten Speicherplatz des Referenztabellen-Teilsatzes zu berechnen, auf den entsprechend dem Binärsuchlauf zugegriffen werden soll.
  • Zwar wurde die vorliegende Erfindung vorstehend im Hinblick auf die Erzeugung von Sichtweisen aus einer einzigen logischen Datei beschrieben, doch ist es gemäß der vorliegenden Erfindung auch möglich, eine übergeordnete Sichtweise zu erzeugen, die Daten aus einer Vielzahl von logischen Dateien enthält. Gemäß diesem Aspekt der vorliegenden Erfindung wird für jede logische Datei eine Logiktabelle erzeugt, wobei jede Logiktabelle einzelne Sichtweisen enthält, die die Daten ihrer jeweiligen logischen Datensätze festlegen und formatieren. Jede Sichtweise in der übergeordneten Sichtweise legt dieselbe Auszugsdatei für die Ausgabe fest, und jede Sichtweise in der übergeordneten Sichtweise hat überdies mindestens ein Feld mit den anderen Sichtweisen in der übergeordneten Sichtweise gemein.
  • Jede Logiktabelle wird zu Maschinencode verarbeitet und als Suchalgorithmus auf ihre jeweiligen logischen Dateien angewandt, wie vorstehend beschrieben wurde. Nachdem alle in der übergeordneten Sichtweise festgelegten logischen Dateien durchlaufen wurden, wird die festgelegte Auszugsdatei für die übergeordnete Sichtweise nach der Nummer der Sichtweise und dem gemeinsamen Feld der Sichtweisen der übergeordneten Sichtweise sortiert und in einer festgelegten Ausgabedatei gespeichert. Nehmen wir beispielsweise an, dass das gemeinsame Feld der Sichtweisen der übergeordneten Sichtweise ein Feld "Kundenname" war, dann hätte die Ausgabedatei das folgende Format:
    CUSTOMER 1 ... VIEW 1 EXTRACT FILE OUTPUT
    CUSTOMER 1 ... VIEW 2 EXTRACT FILE OUTPUT
    .
    .
    .
    CUSTOMER 1 ... VIEW N EXTRACT FILE OUTPUT
    CUSTOMER 2 ... VIEW 1 EXTRACT FILE OUTPUT
    CUSTOMER 2 ... VIEW 2 EXTRACT FILE OUTPUT
    CUSTOMER 2 ... VIEW 3 EXTRACT FILE OUTPUT
    .
    .
    .
    CUSTOMER 2 ... VIEW N EXTRACT FILE OUTPUT
  • In der vorstehenden Weise kann eine Ausgabedatei erzeugt werden, die Daten von einer Vielzahl von Sichtweisen enthält. Sobald diese Ausgabedatei (oder jedwede Auszugsdatei, die in der vorstehend beschriebenen Weise erzeugt wurde) erzeugt wurde, kann der Inhalt der Datei natürlich in herkömmlicher Weise verarbeitet werden, um Berichte oder andere Dokumente in jedem gewünschten Format zu erzeugen.

Claims (16)

  1. Verfahren zum Betreiben eines Rechnersystems (1), das zwei oder mehr Prozessoren hat, um zwei oder mehr physische Dateien (11, 12, 13) einer Transaktions- oder Ereignisdatenbank zu durchlaufen, wobei die physischen Dateien einer oder mehreren logischen Dateien (10) entsprechen, wobei das Verfahren die folgenden Schritte umfasst a) Erzeugen von einer oder mehreren Definitionen von Sichtweisen, wobei jede Definition einer Sichtweise einen Satz von Verarbeitungsparametern für ausgewählte Dateien der zwei oder mehr physischen Dateien (11, 12, 13) festlegt; b) Erzeugen einer Logiktabelle (600) und c) Umwandeln des Satzes von Parametern für jede Definition einer Sichtweise in eine jeweilige Vielzahl von Einträgen in einer Logiktabelle; dadurch gekennzeichnet, dass die Logiktabelle so erzeugt wird, dass sie einen Satz von Logiktabellen (610, 620, 630) für jede der zwei oder mehr physischen Dateien enthält und dass das Verfahren des Weiteren die folgenden Schritte umfasst: d) Kopieren der Vielzahl der Einträge in der Logiktabelle in die Sätze von Logiktabellen, die den ausgewählten der zwei oder mehr physischen Dateien entsprechen, welche den Sätzen von Parametern entsprechen, die von jeder Definition einer Sichtweise festgelegt werden; e) Zuordnen eines jeweiligen Thread einer Vielzahl von Threads (950) zu jedem Satz von Logiktabellen; f) Umwandeln der Einträge in der Logiktabelle eines jeden Thread der Vielzahl von Threads, die einer jeden Definition einer Sichtweise entsprechen, welche jedem Thread zugeordnet ist, in einen Befehlssatz für jeden Thread; und g) Ausführen eines jeden Thread entsprechend seinem Befehlssatz: um auf jeden Eintrag seiner jeweiligen physischen Datei der zwei oder mehr physischen Dateien zuzugreifen, um auf der Grundlage der Definitionen von Sichtweisen, die dem Thread zugeordnet sind, Daten aus dem Eintrag abzurufen, und um die abgerufenen Daten auf der Grundlage der Definitionen von Sichtweisen, die dem Thread zugeordnet sind, in einer oder mehreren Auszugsdateien zu speichern, wobei mindestens zwei der Vielzahl der Threads parallel arbeiten.
  2. Verfahren nach Anspruch 1, wobei sich die zwei oder mehr Dateien (11, 12, 13) auf einem oder mehreren externen Medien (2, 3, 4, 5) befinden.
  3. Verfahren nach Anspruch 2, wobei das eine oder die mehreren externen Medien ein oder mehrere Bandlaufwerke (4, 5), ein Diskettenlaufwerk (2), ein Festplattenlaufwerk (3), ein optisches Laufwerk, einen Blasenspeicher und einen Flash-Speicher enthalten.
  4. Verfahren nach Anspruch 2, das des Weiteren die folgenden Schritte umfasst: Zuordnen eines Satzes von Eingabepufferspeichern (200) zu jeder der zwei oder mehr Dateien, wobei jeder Satz von Eingabepufferspeichern zwei oder mehr Eingabepufferspeicher (220, 230, 240, 250) enthält; Abrufen von Datenblöcken aus jeder der zwei oder mehr Dateien in jeweilige der zwei oder mehr Eingabepufferspeicher in derselben Reihenfolge, in der auch die Datenblöcke auf dem physischen Medium abgelegt werden.
  5. verfahren nach Anspruch 2, das des Weiteren die folgenden Schritte umfasst: a) Zuordnen eines Satzes von Ausgabepufferspeichern (500) zu jeder der einmalig oder mehrfach vorhandenen Auszugsdateien, wobei jeder Satz von Ausgabepufferspeichern einen oder mehrere Ausgabepufferspeicher (520, 530, 540, 550) enthält; und wobei der Schritt der Ausführung eines jeden Thread, um die abgerufenen Daten in einer oder mehreren Auszugsdateien zu speichern, des Weiteren die folgenden Schritte beinhaltet: b) Speichern der von jedem Thread abgerufenen Daten in einem aktuellen der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher, die einer der einmalig oder mehrfach vorhandenen Auszugsdateien zugeordnet sind; c) Feststellen, ob der aktuelle der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher voll ist, und wenn festgestellt wird, dass der aktuelle der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher voll ist, 1) Einleiten einer Übertragung des Inhalts des aktuellen der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher in seine zugehörige Auszugsdatei und 2) Festlegen eines anderen der Ausgabepufferspeicher als den aktuellen Ausgabepufferspeicher der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher.
  6. Parallelverarbeitungssystem (1), um eine logische Datei (10) einer Transaktions- oder Ereignisdatenbank zu durchlaufen, wobei die logische Datei zwei oder mehr physische Dateien (11, 12, 13) enthält, wobei das Parallelverarbeitungssystem Folgendes umfasst: einen Eingabepufferspeicher, um Datenblöcke aus den zwei oder mehr physischen Dateien abzurufen; einen Ausgabepufferspeicher, um Datenblöcke in einer oder mehreren Auszugsdateien zu speichern; eine Logiktabelle (600), die einen oder mehrere Sätze von Verarbeitungsparametern (610, 620, 630) speichert, wobei jeder Satz von Verarbeitungsparametern einer jeweiligen Definition einer Sichtweise entspricht, wobei jede Definition einer Sichtweise Kriterien für den Abruf von Daten aus einer oder mehreren physischen Dateien der logischen Datei festlegt, wobei jede Definition einer Sichtweise darüber hinaus ein Format einer vorgesehenen der Auszugsdateien festlegt; dadurch gekennzeichnet, dass: die Logiktabelle mindestens zwei Sätze von Logiktabellen (610, 620, 630) enthält, wobei jeder Satz von Logiktabellen einer jeweiligen Datei der zwei oder mehr physischen Dateien zugeordnet ist, wobei jeder Satz von Logiktabellen den jeweiligen Satz von Verarbeitungsparametern enthält, der jeder Definition einer Sichtweise zugeordnet ist, welche Kriterien für den Abruf von Daten aus der jeweiligen physischen Datei festlegt, die dem Satz von Logiktabellen zugeordnet ist; ein entsprechender Thread (950) jedem Satz von Logiktabellen zugeordnet ist, wobei jeder Thread die Sätze von Verarbeitungsparametern ausführt, die zu seinem jeweiligen Satz von Logiktabellen gehören, wobei jeder Thread in Folge auf Einträge aus der physischen Datei zugreift, die seinem jeweiligen Satz von Logiktabellen zugeordnet ist, wobei jeder Thread jeden seiner Sätze von Verarbeitungsparametern auf jeden Eintrag, auf den zugegriffen wird, in der Weise anwendet, dass auf jeden Eintrag nur einmal zugegriffen wird, wobei jeder Thread Daten aus jedem Eintrag, auf den zugegriffen wurde, entsprechend seiner Sätze von Verarbeitungsparametern abruft und die abgerufenen Daten über den Ausgabepufferspeicher in den vorgesehenen Auszugsdateien in den jeweiligen Formaten speichert, die von den Definitionen der Sichtweisen festgelegt werden, welche den Sätzen der Verarbeitungsparameter entsprechen.
  7. System nach Anspruch 6, wobei der Eingabepufferspeicher einen entsprechenden Satz von Eingabepufferspeichern (200) für jeden Thread enthält, wobei jeder entsprechende Satz von Eingabepufferspeichern einen oder mehrere Eingabepufferspeicher (220, 230, 240, 250) enthält, wobei jeder Eingabepufferspeicher einen abgerufenen Datenblock speichert, wobei die Größe des Datenblocks in Abhängigkeit von einem physischen Medium gewählt wird, von dem der Datenblock abgerufen wurde.
  8. System nach Anspruch 6, wobei der Ausgabepufferspeicher einen entsprechenden Satz von Ausgabepufferspeichern (500) für jede Auszugsdatei enthält, wobei jeder entsprechende Ausgabepufferspeicher einen oder mehrere Ausgabepufferspeicher (520, 530, 540, 550) enthält, wobei jeder Ausgabepufferspeicher einen Datenblock zur Speicherung in der Auszugsdatei hält, die dem entsprechenden Ausgabepufferspeicher zugeordnet ist, wobei die Größe eines jeden Datenblocks in Abhängigkeit von einem physischen Medium gewählt wird, in dem sich die Auszugsdatei befindet.
  9. System nach Anspruch 7, wobei der Thread, der dem einen oder mehreren Eingabepufferspeichern eines jeden Satzes von Eingabepufferspeichern zugeordnet ist, so ausgelegt ist, dass er seine Sätze von Verarbeitungsparametern an einem aktuellen der einmalig oder mehrfach vorhandenen Eingabepufferspeicher ausführt, während ein anderer Prozessor einen nächsten Datenblock aus der einen der zwei oder mehr Dateien abruft, die dem Thread zugeordnet ist.
  10. System nach Anspruch 8, wobei jeder Thread so ausgelegt ist, dass er vor der Speicherung der abgerufenen Daten in dem Satz von Ausgabepufferspeichern, der der vorgesehenen Auszugsdatei entspricht, feststellt, ob ein aktueller Ausgabepufferspeicher des Satzes von Ausgabepufferspeichern, der der vorgesehenen Auszugsdatei entspricht, voll ist, und wenn der aktuelle Ausgabepufferspeicher nicht voll ist, die abgerufenen Daten in dem aktuellen Ausgabepufferspeicher speichert, und wenn der aktuelle Ausgabepufferspeicher voll ist, eine Übertragung des Inhalts des aktuellen der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher in die vorgesehene Auszugsdatei einleitet und einen anderen der Ausgabepufferspeicher als den aktuellen der einmalig oder mehrfach vorhandenen Ausgabepufferspeicher festlegt.
  11. System nach Anspruch 7, wobei jeder Satz von Eingabepufferspeichern (200) eine Vielzahl von Eingabepufferspeichern (220, 230, 240, 250) enthält.
  12. System nach Anspruch 8, wobei jeder Satz von Ausgabepufferspeichern (500) eine Vielzahl von Ausgabepufferspeichern (520, 530, 540, 550) enthält.
  13. System nach Anspruch 7, wobei das physische Medium entweder ein Bandlaufwerk (4, 5), ein Diskettenlaufwerk (2), ein Festplattenlaufwerk (3), ein optisches Laufwerk, einen Blasenspeicher und einen Flash-Speicher beinhaltet.
  14. System nach Anspruch 8, wobei das physische Medium entweder ein Bandlaufwerk (4, 5), ein Diskettenlaufwerk (2), ein Festplattenlaufwerk (3), ein optisches Laufwerk, einen Blasenspeicher und einen Flash-Speicher beinhaltet.
  15. Verfahren nach Anspruch 1, wobei die Logiktabelle als eine "nichtprozedurale" Programmiersprache ausgeführt wird.
  16. System nach Anspruch 6, wobei die Logiktabelle als eine "nichtprozedurale" Programmiersprache ausgeführt wird.
DE69533193T 1994-08-31 1995-08-30 Paralleles verarbeitungssystem zum durchlaufen einer datenbank Expired - Lifetime DE69533193T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/299,225 US5666524A (en) 1994-08-31 1994-08-31 Parallel processing system for traversing a transactional database
US299225 1994-08-31
PCT/US1995/010946 WO1996007149A1 (en) 1994-08-31 1995-08-30 Parallel processing system for traversing a data base

Publications (2)

Publication Number Publication Date
DE69533193D1 DE69533193D1 (de) 2004-07-29
DE69533193T2 true DE69533193T2 (de) 2005-07-28

Family

ID=23153865

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69533193T Expired - Lifetime DE69533193T2 (de) 1994-08-31 1995-08-30 Paralleles verarbeitungssystem zum durchlaufen einer datenbank

Country Status (10)

Country Link
US (1) US5666524A (de)
EP (1) EP0777884B1 (de)
JP (1) JP4160632B2 (de)
KR (1) KR100402913B1 (de)
AT (1) ATE269992T1 (de)
AU (1) AU698148B2 (de)
CA (1) CA2198735C (de)
DE (1) DE69533193T2 (de)
RU (1) RU2182357C2 (de)
WO (1) WO1996007149A1 (de)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5842200A (en) * 1995-03-31 1998-11-24 International Business Machines Corporation System and method for parallel mining of association rules in databases
JP3842319B2 (ja) * 1995-11-08 2006-11-08 富士通株式会社 情報検索システム
US5768532A (en) * 1996-06-17 1998-06-16 International Business Machines Corporation Method and distributed database file system for implementing self-describing distributed file objects
US5930791A (en) * 1996-12-09 1999-07-27 Leu; Sean Computerized blood analyzer system for storing and retrieving blood sample test results from symmetrical type databases
WO1998043193A2 (en) * 1997-03-21 1998-10-01 University Of Maryland Spawn-join instruction set architecture for providing explicit multithreading
US6539388B1 (en) * 1997-10-22 2003-03-25 Kabushika Kaisha Toshiba Object-oriented data storage and retrieval system using index table
US6327587B1 (en) 1998-10-05 2001-12-04 Digital Archaeology, Inc. Caching optimization with disk and/or memory cache management
US6601058B2 (en) 1998-10-05 2003-07-29 Michael Forster Data exploration system and method
AU1991400A (en) * 1999-01-19 2000-08-07 British Telecommunications Public Limited Company Data selection system and method therefor
GB2349961A (en) * 1999-05-08 2000-11-15 Int Computers Ltd Analysing data files to produce summaries therefrom
US8428996B2 (en) * 2001-06-11 2013-04-23 Ebay Inc. Method and system automatically to support multiple transaction types, and to display seller-specific transactions of various transaction types in an integrated, commingled listing
US20050261914A1 (en) * 2002-07-19 2005-11-24 Microsoft Corporation Method and system for managing long running transactions
US7555540B2 (en) 2003-06-25 2009-06-30 Microsoft Corporation Media foundation media processor
US20050108021A1 (en) * 2003-07-31 2005-05-19 Greg Anderson System and method for routing and managing service requests
US7289974B2 (en) * 2003-09-05 2007-10-30 Sap Ag System and method for data reconciliation
JPWO2005086003A1 (ja) * 2004-03-08 2008-01-24 アネックスシステムズ株式会社 データベース・システム
US20060004846A1 (en) * 2004-06-16 2006-01-05 Bmc Software, Inc. Low-overhead relational database backup and restore operations
US7720751B2 (en) * 2004-10-12 2010-05-18 Natural Decision Systems, Inc. System and method of continuous assurance for internal control
US7676427B1 (en) 2004-10-12 2010-03-09 Natural Decision Systems, Inc. System and method of continuous assurance
US7827554B2 (en) * 2005-06-20 2010-11-02 Microsoft Corporation Multi-thread multimedia processing
US8244718B2 (en) * 2006-08-25 2012-08-14 Teradata Us, Inc. Methods and systems for hardware acceleration of database operations and queries
US9424315B2 (en) 2007-08-27 2016-08-23 Teradata Us, Inc. Methods and systems for run-time scheduling database operations that are executed in hardware
US8862625B2 (en) 2008-04-07 2014-10-14 Teradata Us, Inc. Accessing data in a column store database based on hardware compatible indexing and replicated reordered columns
US8458129B2 (en) 2008-06-23 2013-06-04 Teradata Us, Inc. Methods and systems for real-time continuous updates
US7966343B2 (en) 2008-04-07 2011-06-21 Teradata Us, Inc. Accessing data in a column store database based on hardware compatible data structures
KR100938183B1 (ko) * 2007-10-19 2010-01-21 한국과학기술정보연구원 병렬화를 이용한 스크래치 디스크의 파일 삭제 장치 및이를 이용한 파일 삭제 방법과 이를 실행하기 위한프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체
US20100153300A1 (en) * 2008-07-11 2010-06-17 Logical Information Machines, Inc. Derivative trading strategy backtesting machine
US8775398B2 (en) * 2009-06-01 2014-07-08 Ebay Inc. Method and system for determining an order of presentation of search results
EP2449484B1 (de) * 2009-06-30 2019-01-09 Koninklijke Philips N.V. Relevanz-feedback für inhaltsbasierten bildabruf
CN103473321A (zh) 2013-09-12 2013-12-25 华为技术有限公司 数据库管理方法与系统
US20160292751A1 (en) * 2015-03-31 2016-10-06 Carrier Services Group, Inc. Product valuation system and method
KR200488297Y1 (ko) 2017-10-18 2019-01-09 이혜경 볼 마커 겸용 골프 볼 라이너
US11132225B2 (en) * 2019-03-29 2021-09-28 Innoplexus Ag System and method for management of processing task across plurality of processors
KR20220120068A (ko) 2021-02-22 2022-08-30 김태열 골프용 볼 마커
US11586621B1 (en) * 2022-01-27 2023-02-21 Snowflake Inc. Parallel scan of single file using multiple threads

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4631673A (en) * 1985-01-22 1986-12-23 International Business Machines Corporation Method for refreshing multicolumn tables in a relational data base using minimal information
US4918593A (en) * 1987-01-08 1990-04-17 Wang Laboratories, Inc. Relational database system
US4805099A (en) * 1987-04-17 1989-02-14 Wang Laboratories, Inc. Retrieval of related records from a relational database
US4876643A (en) * 1987-06-24 1989-10-24 Kabushiki Kaisha Toshiba Parallel searching system having a master processor for controlling plural slave processors for independently processing respective search requests
JPH022459A (ja) * 1987-12-11 1990-01-08 Hewlett Packard Co <Hp> 問合わせ処理方法
DE69032418T2 (de) * 1989-09-08 1999-02-25 Digital Equipment Corp Privatspeicher für Fäden in einem multifaden digitalen Datenverarbeitungssystem
JPH04335471A (ja) * 1991-05-13 1992-11-24 Nec Corp データベース参照処理方式
JPH04364549A (ja) * 1991-06-12 1992-12-16 Hitachi Ltd ファイル格納方式とアクセス方式
DE4133123A1 (de) * 1991-10-05 1993-04-08 Basf Ag Verwendung von copolymerisaten aus langkettigen olefinen und maleinsaeureanhydrid in form der halbamide mit morpholin als leimungsmittel fuer papier
JPH05307566A (ja) * 1992-04-30 1993-11-19 Nippon Telegr & Teleph Corp <Ntt> 並列処理型内容検索装置

Also Published As

Publication number Publication date
JPH10509816A (ja) 1998-09-22
EP0777884A4 (de) 1998-05-20
CA2198735A1 (en) 1996-03-07
EP0777884A1 (de) 1997-06-11
CA2198735C (en) 2006-08-15
ATE269992T1 (de) 2004-07-15
KR970705795A (ko) 1997-10-09
JP4160632B2 (ja) 2008-10-01
AU3418795A (en) 1996-03-22
DE69533193D1 (de) 2004-07-29
WO1996007149A1 (en) 1996-03-07
EP0777884B1 (de) 2004-06-23
RU2182357C2 (ru) 2002-05-10
AU698148B2 (en) 1998-10-22
KR100402913B1 (ko) 2004-03-26
US5666524A (en) 1997-09-09

Similar Documents

Publication Publication Date Title
DE69533193T2 (de) Paralleles verarbeitungssystem zum durchlaufen einer datenbank
DE3382808T2 (de) Datenbankzugriffsverfahren mit einem benutzerfreundlichen Menü
EP0910829B1 (de) Datenbanksystem
DE69736748T2 (de) Editierumgebung für objektmodelle und verfahren zu deren anwendung
DE68927216T2 (de) System zur verwaltung von hierarchischen informationen in einem digitalen datenverarbeitungssystem
DE69333408T2 (de) Ein Computer-System und Verfahren zum interaktiven Verwalten eines verteilten Datenbanksystems
EP0855062B1 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
DE60208778T2 (de) Datenstruktur für informationssysteme
DE3883733T2 (de) Bedienungsverfahren eines elektronischen Datenverarbeitungssystems zum Dokumententransfer zwischen Endbenutzern.
DE68925746T2 (de) Versionen-Verwaltungswerkzeug
DE4218025C2 (de) Vorrichtung und Verfahren zur automatischen Zuordnung von Datenspeichereinrichtungen in einem Computersystem
DE3889574T2 (de) Benutzerführung für Transaktionen.
DE69031028T2 (de) System zum physikalischen Entwurf von Datenbanken
DE3852384T2 (de) Adaptives Hilfs-/Dialogsystem.
DE60121231T2 (de) Datenverarbeitungsverfahren
DE68927743T2 (de) Sortier-/Mischausgabe
DE10028688B4 (de) Methode, System und Programm für eine Verbindungsoperation in einer mehrspaltigen Tabelle sowie in Satellitentabellen mit doppelten Werten
DE60121827T2 (de) Vorrichtung und verfahren zur wiedergewinnung von daten
DE60035432T2 (de) System zur verwaltung der rdbm fragmentierungen
DE3855706T2 (de) Automatisierte Rechnung von Materialien
DE69126795T2 (de) Dateienverwaltungssystem mit graphischer benutzerschnittstelle zum aufstellen von fragen
DE19842688B4 (de) Verfahren zum Filtern von Daten, die von einem Datenanbieter stammen
DE69628374T2 (de) Datenverwaltungssystem
DE60118973T2 (de) Verfahren zum abfragen einer struktur komprimierter daten
DE19959765B4 (de) Datei-Editor für mehrere Datenuntermengen

Legal Events

Date Code Title Description
8327 Change in the person/name/address of the patent owner

Owner name: INTERNATIONAL BUSINESS MACHINES CORP., ARMONK, N.Y

8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)