DE69030551T2

DE69030551T2 - Prozess und Gerät zur Handhabung zeitaufwendiger und wiederverwendbarer Abfragen in einem objekt-orientierten Datenbankverwaltungssystem

Info

Publication number: DE69030551T2
Application number: DE69030551T
Authority: DE
Inventors: Robert Low Abraham; Michael P Priven
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1989-10-23
Filing date: 1990-09-04
Publication date: 1997-11-13
Anticipated expiration: 2010-09-05
Also published as: DE69030551D1; EP0425412B1; JPH0792778B2; EP0425412A2; EP0425412A3; US5161225A; JPH03138734A

Description

Die vorliegende Erfindung betrifft ein objekt-orientiertes Datenbankverwaltungssystem, und insbesondere einen Prozeß und ein Gerät zum Behandeln von zeitaufwendigen und wiederverwendbaren Abfragen in einem objektorientierten Datenbankverwaltungssystem.
Objektorientierte Programmiersysteme und -prozesse waren schon immer Gegenstand eingehender Untersuchungen und Interesse auf dem Stand der Technik der Datenverarbeitungsumgebungen. Beim objekt-orientierten Programmieren handelt es sich um eine Rechnerprogrammpaketierungstechnik, die nutzungsinvariante und mit Leichtigkeit erweiterbare Programme vorsieht. Im Gegensatz zu bekannten funktionellen Programmierungstechniken, die sich nur schwer an neue funktionelle Forderungen und neue Datentypen anpassen lassen, sind objektorientierte Programme nutzungsinvariant und erweiterbar, wenn neue Forderungen auftauchen. Mit der immer stärker werdenden Komplexität rechnergestützter Systeme gewinnt das objektorientierte Programmieren immer stärkere Bedeutung und muß dementsprechend eingehender untersucht werden.
In einem objektorientierten Programmiersystem liegt das Hauptgewicht auf den Daten und nicht auf den Funktionen. Objektorientierte Programmiersysteme setzen sich zusammen aus einer großen Anzahl "Objekte". Ein Objekt ist eine Datenstruktur und ein Satz Operationen oder Funktionen, die auf diese Datenstruktur Zugriff nehmen können. Die Datenstruktur kann dargestellt werden als ein "Datenübertragungsblock". Der Datenübertragungsblock weist viele "Schlitze" auf, die jeweils ein "Attribut" der Daten enthalten. Das Attribut kann ein elementarer Ausdruck (z.B. eine Ganzzahl oder eine Zeichenkette) oder eine Objektreferenz sein, die ein Zeiger auf einen anderen Objektfall bzw. -fälle (in nachstehender Definition) ist. Jede Operation (Funktion), die auf die Datenstruktur zugreifen kann, heißt "Methode".
Fig. 1 zeigt eine schematische Darstellung eines Objekts, in dem ein Datenübertragungsblock in seine Methoden eingekapselt ist. Fig. 2 zeigt ein Beispiel für ein Objekt, in dem sich die Datenstruktur auf Angestelltendaten bezieht und eine Anzahl Methoden diese Datenstruktur umgibt. Eine Methode ruft z.B. das Alter der Angestellten ab. Jedes definierte Objekt wird üblicherweise dargestellt mit einer Anzahl "Fälle". Jeder Fall enthält die besondere Datenstruktur für ein bestimmtes Beispiel des Objekts. Z.B. ist ein Objekt für eine bestimmte Angestellte namens Joyce Smith ein Fall des Objekts "Angestellte".
Objektorientierte Programmiersysteme sehen zwei Primärmerkmale vor, die die Entwicklung von flexiblen und nutzungsinvarianten Programmen zulassen. Diese Merkmale werden als "Einkapselung" und "Vererbung" bezeichnet. Wie man aus Fig. 1 erkennt, wird der Datenblock von seinen Methoden (Funktionen) eingekapselt. Um jedes Datenstück ist eine Code-Wand errichtet. Der Zugriff auf den Datenblock erfolgt nur über die umgebenden Methoden. Auf diese Weise ist die Datenunabhängigkeit gewährleistet, weil auf die Datenstruktur eines Objekts nur über seine Methoden zugegriffen werden kann. Nur die zugeordneten Methoden kennen die interne Datenstruktur. Das stellt die Datenintegrität sicher.
Die Eigenschaft "Vererbung" eines objektorientierten Programmiersystens ermöglicht die Erweiterung bereits früher geschriebener Programme durch Schaffen neuer Überklassen oder Unterklassen von Objekten. Neue Objekte werden dadurch beschrieben, wie sie sich von bereits vorher existierenden Objekten unterscheiden, so daß keine ganzen Programme neu geschrieben werden müssen, um neue Datentypen oder Funktionen zu behandeln.
Fig. 3 illustriert die Eigenschaft Vererbung. Zwecks leichterer Darstellung werden die Objekte als Rechtecke anstatt als Kreise dargestellt, wobei der Objektname oben im Rechteck, der Datenblock unter dem Objektnamen und die Methode unter dem Datenblock angegeben ist. In Fig. 3 werden drei Objektklassen dargestellt als "Verkäufer", "Angestellter" und "Person", dabei ist ein "Verkäufer" eine "Art" Angestellter, der eine "Art" Person ist. Mit anderen Worten, "Verkäufer" ist eine Unterklasse von Angestellter, und Angestellter ist die Überklasse von Verkäufer. Auf ähnliche Weise ist Angestellter eine Unterklasse von Person und Person ist die Überklasse von Angestellter. Jede gezeigte Klasse beinhaltet drei Fälle. B.Soutter, W.Tipp und B.G.Blue sind Verkäufer, B.Abraham, K.Yates und R.Moore sind Angestellte, J.McEnro, R.Nader und R.Reagan sind Personen. Mit anderen Worten, ein Fall steht in Verbindung mit seiner Klasse durch die Beziehung "ist ein".
Jede Unterklasse "erbt" den Datenblock und die Methoden ihrer Überklasse. So erbt z.B. ein Verkäufer-Datenblock Alter- und Einstellungsdaten-Objekte sowie Beförderungs-Methode von der Angestellten-Überklasse. Verkäufer beinhaltet auch ein Einzelquota-Attribut und eine Provisionszahlungs-Methode.
Jeder Fall kann Zugriff nehmen auf alle Methoden und Datenblöcke seiner Überklasse, so daß z.B. B.G.Blue befördert werden kann.
In einem objektorientierten System fordert eine Routine auf hoher Stufe ein Objekt auf, daß es eine seiner Methoden durchführt, durch Senden einer "Botschaft" an das Objekt, die dem Objekt sagt, was es tun soll. Das empfangende Objekt reagiert auf die Botschaft durch Anwählen der den Namen der Botschaft implementierende Methode, Durchführen dieser Methode, und dann Zurückgeben der Steuerung zusammen mit den Ergebnissen der Methode an die aufrufende Routine auf hoher Stufe.
Objektorientierte Programmiersysteme können als Datenbankverwaltungssysteme eingesetzt werden, die auf einer Großdatenbank arbeiten können und die erweiterbar und anpassungsfähig sind. In einem objektorientierten Datenbankverwaltungssystem sind die Daten in der Datenbank organisiert und in Objektterme eingekapselt, wobei die Fälle der Objekte die Daten in der Datenbank sind. Auf ähnliche Weise kann der Datenbank-Manager als Objektsatz organisiert sein, wobei Datenbankverwaltungsoperationen durch Senden von Botschaften von einem Objekt zu einem anderen ausgeführt werden. Das Zielobjekt führt die angeforderte Aktion an seinen Attributen unter Verwendung seiner Methoden durch.
In einem objektorientierten Datenbankverwaltungssystem produziert das Ergebnis einer Datenbankabfrage ein Objekt, das "Datenstrom" genannt wird. Die Attribute eines Datenstroms beinhalten eine Liste der Namen (oder der sonstigen Identifikatoren) aller Objekte in einer Objektklasse, die die Abfrage erfüllen. Mit anderen Worten, die Datenbankattribute enthalten eine Liste der Teilmenge der Klasse, die die Suchkriterien erfüllt. In die Attribute können auch zugeordnete beschreibende Informationen eingeschlossen sein.
Wie dem Fachmann bekannt ist, sind Abfragen an sehr große Datenbanken häufig sehr zeitaufwendig. Zum Beispiel kann eine Abfrage eine Objektklasse durchsuchen müssen, die eine Million Fälle enthält, um zwanzig Fälle zu finden, die die Suchkriterien erfüllen. Leider begrenzen solche zeitaufwendigen Suchen die Einsetzbarkeit des Datenbanksystems, weil in der Regel das Datenbanksystem keine weitere Abfrage bearbeiten kann, solange eine zeitaufwendige Abfrage durchgeführt wird.
Des weiteren ist dem Fachmann bekannt, daß die Ergebnisse vieler Datenbanksuchen für künftigen Gebrauch bereitgehalten werden müssen. Wenn das Ergebnis einer Suche häufig benutzt wird, ist es erwünscht, die Suche nicht wiederholt durchführen zu müssen, um jedesmal das gleiche Ergebnis zu erhalten. Das gilt besonders für zeitaufwendige Suchen, die die Datenbank während der Suche jedesmal unzugänglich machen.
Das Dokument 15th International Conference on very large Databases, August 1989, Amsterdam, S. 433-442, betrifft Suchtechniken, die in objektorientierten Datenbanksystemen eingesetzt werden.
Es ist daher eine Aufgabe der Erfindung, einen Prozeß und ein Gerät zum Durchführen von Abfragen in einem objektorientierten Datenbankverwaltungssystem bereitzustellen, und insbesondere zum Durchführen von zeitwaufwendigen Abfragen in einem objektorientierten Datenbankverwaltungssystem.
Eine weitere Aufgabe der Erfindung ist es, einen Prozeß und ein Gerät zum Durchführen nutzungsinvarianter Abfragen in einem objektorientierten Datenbankverwaltungs system bereitzustellen.
Diese und noch weitere Aufgaben werden gelöst in einem objektorientierten Datenbankverwaltungsverfahren und -gerät gemäß den beiliegenden Ansprüchen durch Vorsehen einer neuen Objektklasse, genannt "Ständiger Datenstrom". Die Klasse Ständiger Datenstrom ist eine Unterklasse der Datenstromklasse, so daß sie alle Attribute und Methoden der Datenstromklasse erbt. Jedoch enthält die Klasse Ständiger Datenstrom eine Methode, die in der Datenstromklasse nicht vorkommt. Diese Methode sieht die Fähigkeit des Fortbestehens vor. Im einzelnen beinhaltet der Ständige Datenstrom eine Methode zum Abspeichern der Ergebnisse einer Datenbankabfrage.
Der erfindungsgemäße Ständige Datenstrom ist in der Lage, die Ergebnisse einer Suche abzuspeichern, ist jedoch in allen anderen Aspekten identisch mit normalen Datenströmen, wenn Botschaften gesendet werden, die für einen normalen Datenstrom definiert sind. Dementsprechend kann der Ständige Datenstrom als Parameter benutzt werden durch jede Botschaft, die einen Datenstrom als Ergebnis erwartet. Wenn jedoch eine Abfrage einen Ständigen Datenstrom als Objekt nennt, wird die Suche in einem Hintergrund- oder Stapelmodus durchgeführt und die Ergebnisse werden gespeichert, bis sie benötigt werden. Dabei kann eine zeitaufwendige Suche eingeleitet, im Hintergrund durchgeführt und dann gespeichert werden. Wenn der Ständige Datenstrom dann später angesprochen wird, ist er codeunabhängig für die Zugriffsmethode, ob nun die Suche unmittelbar durchgeführt wird oder bereits früher durchgeführt und gespeichert wurde. Ein ständiger Datenstrom kann auch dann eingesetzt werden, wenn die Ergebnisse einer Suche wiederholt benutzt werden sollen. Eine Botschaft kann auf den Ständigen Datenstrom zugreifen, und es ist für die Zugriffs- methode codeunabhängig, ob die Suche unmittelbar durchgeführt wird oder bereits früher durchgeführt und gespeichert wurde.
Insbesondere beinhaltet ein erfindungsgemäßer objektorientierter Datenbankmanager eine Datenstromklasse und eine Ständige Datenstromklasse. Die Datenstromklasse ist eine Objektklasse mit Datenstromattributen und Datenstrommethoden, wobei die Datenstromattribute eine Liste von Datenbankobjekten sind, die ein vorgegebenes Abfragekriterium erfüllen, und die Datenstrommethoden beinhalten Methoden zum Schaffen, Öffnen, Holen, Schließen und Löschen eines Datenstromfalls. Die Ständige Datenstromklasse ist eine Unterklasse der Datenstromklasse, so daß sie die Datenstromattribute und Datenstrommethoden erbt. Jedoch beinhalten die Ständigen Datenstromklassenattribute auch das Suchkriterium, ein Flag zum Zeigen, ob die Ergebnisse der Suche gespeichert sind, und einen Indikator auf die Speicherstelle der Suchergebnisse. Die Datenstromklasse beinhaltet auch eine "Speicherungs"- Methode zum Speichern der Ergebnisse einer Operation auf die Datenbank.
Im Betrieb akzeptiert der Datenbankmanager auf der Datenbank durchzuführende Anfragen nach Datenobjekten und es wird bestimmt, ob die akzeptierte Suche sofort durchgeführt wird und die Ergebnisse der Suche gespeichert werden. Der Fachmann versteht hier, daß diese Bestimmung in der Regel vom Anwendungsprogramm getroffen wird, das als Teil oder im Zusammenhang mit dem objektorientierten Datenbankmanager gefahren wird. Wenn die Suche sofort ausgeführt werden soll und die Ergebnisse nicht für späteren Gebrauch abgespeichert werden müssen, wird die Abfragebotschaft an die Datenstromklasse gerichtet. Wenn andererseits die Abfrage nicht sofort durchgeführt werden muß oder wenn die Ergebnisse zur weiteren Verwendung gespeichert werden müssen, schickt der Datenbankmanager die Suchabfrage an die Ständige Datenstromklasse. Die Ständige Datenstromklasse führt die Abfrage genau wie eine Datenstromklasse durch, mit dem Unterschied, daß die Abfrage Ergebnisse im Hintergrund durchführt und abspeichert, z.B. als sequentielle Datei in einer nichtflüchtigen Speichervorrichtung.
Dementsprechend kann jede Abfragefunktion entweder einen Ständigen oder einen Nichtständigen Datenstrom schaffen. Ständige Datenströme können im Hintergrund gebildet werden wenn ausreichende Systembetriebsnittel zur Verfügung stehen, und der Anwender kann inzwischen andere Arbeiten durchführen. Dem Arbeitsdurchführungsprozeß kann entweder ein regulärer Datenstrom oder ein Ständiger Datenstrom zugeführt werden. Da Ständige Datenströme genau wie Nichtständige Datenströme auf die Methoden Öffnen, Holen, Schließen und Löschen ansprechen, ist der Datenstromtyp für den Anwender eines objektorientierten Datenbankverwaltungssystems völlig codeunabhängig.
Die erfindungsgemäße Ständige Datenstromklasse kann mit einer wiederaufgreifbaren Stapel-Abfrageobjektklasse benutzt werden, die in US-Patent Nr. 425,829, mit dem Titel "Resumable Batch Query for Processing Time Consuming Queries in an Object Oriented Database Management System" beschrieben ist, dessen Offenbarung hier durch Querverweis eingeschlossen ist. Andererseits braucht die wiederaufgreifbare Stapelabfrage nicht benutzt zu werden.
Hier nachstehend soll jetzt die Erfindung anhand der beiliegenden Zeichnungen eingehender beschrieben werden.
Fig. 1 zeigt eine schematische Darstellung eines Objekts.
Fig. 2 illustriert eine schematische Darstellung eines beispielhaften Objekts.
Fig. 3 zeigt die Eigenschaft der Vererbung von Objekten.
Fig. 4 zeigt ein Blockschaltbild eines objektorientierten Rechnersystems gemäß der vorliegenden Erfindung.
Fig. 5 zeigt ein Blockschaltbild eines objektorientierten Programms gemäß der vorliegenden Erfindung.
Fig. 6 zeigt beispielhaft einen Datenstrom gemäß der vorliegenden Erfindung.
Fig. 7 zeigt einen ersten und einen zweiten Dialogbildschirm zur Durchführung einer Datenbankanfrage unter Verwendung eines Datenstroms.
Fig. 8 zeigt einen ständigen Datenstrom gemäß der vorliegenden Erfindung.
Fig. 9 zeigt einen ständigen Datenstrom und einen sequentiellen Datensatz gemäß der vorliegenden Erfindung.
In einem objektorientierten Rechnersystem wird die Arbeit durchgeführt durch Senden von Aktionsanforderungsbotschaften an ein Objekt, das (gekapselte) Daten enthält. Das Objekt wird die angeforderte Aktion an den Daten gemäß seinen vordefinierten Methoden durchführen. Der Anforderer der Aktion braucht nicht zu wissen, wie die aktuellen Daten aussehen oder wie sie das Objekt handhabt.
Eine Objektklasse definiert die Typen und Bedeutungen der Daten- und die Aktionsanforderungen (Botschaften), auf die das Objekt anspricht. Die einzelnen Daten enthaltenden Objekte heißen Fälle der Klasse. Klassen beziehen sich in der Regel auf Dinge der realen Welt. Ein später noch darzulegendes Beispiel spricht "Teile" als eine Klasse an. Die Datenelemente (Schlitze) eines Teils könnten sein eine Teilenummer, ein Status und ein Teiletyp. Die Fälle dieser Klasse stellen Einzelteile dar, jeder mit seiner eigenen Teilenummer, Status und Typinformation. Die Programme, die die angeforderten Aktionen ausführen, heißen Methoden der Klasse.
Objektklassen können als Unterklassen anderer Klassen definiert werden. Unterklassen erben alle Datenmerknale und Methoden der augenblicklichen Klasse. Sie können zusätzliche Daten und Methoden hinzufügen, und sie können Datenelemente oder Elemente der Elternklasse überschreiben (neu definieren). Während die meisten Botschaften an Objektfälle gesendet werden, wird die Botschaft, die das Schaffen eines neuen Falls fordert, an eine Objektklasse gesendet. Die Klasse bewirkt, daß ein neuer Fall geschaffen wird, und schickt einen Objektidentifikator zurück, an dem das Objekt erkannt wird.
Der Sender einer Aktionsanforderungsbotschaft braucht die genaue Klasse des Objekts, an die er seine Botschaft sendet, nicht zu kennen. Solange das Zielobjekt entweder eine Methode zum Behandeln der Botschaft definiert oder eine Elternklasse hat, die eine solche Methode definiert, wird die Botschaft mit den Daten im Objektfall und mit der Methode in seiner Klasse bzw. seiner Elternklasse behandelt. Es braucht nicht einmal ein unmittelbarer Elter zu sein, sondern kann der Elter eines Elters sein, usw. Der Sender der Methode braucht nur die Objekt-ID des empfangenden Objekts zu kennen. Diese Eigenschaft der objektorientierten Programmierung heißt "Vererbung". In der vorliegenden Erfindung wird die Eigenschaft "Vererbung" benutzt.
Nehmen wir jetzt Bezug auf Fig. 4; hier wird ein Blockschaltbild eines objektorientierten Datenbankverwaltungssystems 10 gezeigt. Das System 10 beinhaltet einen Datenprozessor 11, der ein Großrechner, ein Minicomputer oder ein Personalcomputer sein kann. Für größere Datenbanken mit einer Vielzahl von Anwendern wird in der Regel eine Großrechner eingesetzt. Wie dem Fachmann wohlbekannt ist, beinhaltet der Datenprozessor 10 eine flüchtige Datenspeichervorrichtung 13, in der Regel einen Speicher mit wahlfreiem Zugriff (RAM), der einen Arbeitsspeicher für aktive Daten und Zwischenergebnisse bereitstellt. Die Daten im RAM 13 werden gelöscht, wenn der Datenprozessor 11 abgeschaltet wird oder eine neue Anwendersitzung anfängt. System 10 beinhaltet auch eine nichtflüchtige Datenspeichervorrichtung 14 zur permanenten Objektspeicherung. Die Vorrichtung 14 kann eine Speichervorrichtung mit direktem Zugriff (DASD), ein Festplattenspeicher, ein Bandspeicher, eine löschbare Optikplatte oder eine sonstige bekannte Vorrichtung sein. Die nichtflüchtige Datenspeichervorrichtung 14 wird hier auch als "Datenbank" bezeichnet. Die flüchtige Datenspeichervorrichtung 13 wird hier auch als "Speicher" bezeichnet. Eine Daten-Endstation 15 mit einer Kathodenstrahlröhre (CRT) oder einer sonstigen Anzeigevorrichtung und eine Tastatur werden ebenfalls dargestellt.
Ein objektorientiertes Programm 12 in der Form eines objektorientierten Datenbankmanagers ist im Datenprozessor 11 ebenfalls enthalten. Der objektorientierte Datenbankmanager kann in objektorientierten Sprachen wie "C" oder "Smalltalk" oder Variationen derselben oder auch in den herkömmlichen Programmiersprachen wie FORTRAN oder COBOL programmiert sein. Die Konstruktion eines objektorientierten Datenbankmanagers ist in Fachkreisen für objektorientierte Programmiersysteme wohlbekannt und wird hier nachstehend nur allgemein beschrieben.
Nehmen wir jetzt Bezug auf Fig. 5; hier werden die Hauptkomponenten eines objektorientierten Programms (12, Fig. 4) beschrieben. Eine in weitere Einzelheiten gehende Beschreibung der Konstruktion und des Betriebs eines objektorientierten Programms ist vorgesehen in "Object Oriented Software Construction" von Betrand Meyer, erschienen im Verlag Prentice Hall, 1988, dessen Offenbarung hier durch Querverweis eingeschlossen ist.
Nehmen wir Bezug auf Fig. 5; das objektorientierte Programm 12 beinhaltet drei Primärkomponenten: Einen Botschaftsübermittler 51, eine Objektverwaltungstabelle 52 und eine Tabelle für geladene Klassen 53. Der Botschaftsübermittler 51 steuert die Verbindung zwischen den aufrufenden und den aufgerufenen Botschaften, der Objektverwaltungstabelle 52 und der Tabelle für geladene Klassen 53. Die Objektverwaltungstabelle 52 enthält eine Liste der Zeiger auf alle aktiven Objektfälle. Die Tabelle für geladene Klassen 53 enthält eine Liste der Zeiger auf alle Methoden aktiver Objektklassen.
Anhand der in Fig. 5 dargestellten Beispiels soll jetzt der Betrieb eines objektorientierten Programms 12 dargestellt werden, wobei Methode A (Block 54) eines Objekts eine Botschaft an Methode B (Block 55) eines Objekts sendet. Methode A sendet eine Botschaft an Methode B durch Aufrufen des Botschaftsübermittlers 51. Die Botschaft enthält (1) eine Objektbezugnahme auf den Fall zum Empfang der Botschaft, (2) die Methode, mit der der Objektfall aufgefordert wird, auf die eingekapselten Daten einzuwirken, und (3) etwaige Parameter, die von der empfangenden Methode benötigt werden. Botschaftsübermittler 51 findet einen Zeiger auf den Datenblock 56 des von Methode A spezifizierten Fallobjekts durch Durchsuchen der Objektverwaltungstabelle 52 nach dem Fallobjekt. Wenn das angegebene Fallobjekt nicht gefunden werden kann, fügt die Objektverwaltungstabelle 52 das Fallobjekt zur Tabelle hinzu und ruft den Fall auf, seine Daten von der Datenbank zu materialisieren. Nach Aufnahme in die Falltabelle gibt die Objektverwaltungstabelle 52 den Zeiger zurück an das materialisierte Fallobjekt.
Der Botschaftsüberbringer 51 sucht dann die Adresse für Methode B in der Tabelle für geladene Klassen 53. Wenn die Klasse des Falls nicht geladen ist, lädt ihn die Tabelle für geladene Klassen 53 jetzt, um ihre Daten zu materialisieren. Die Tabelle für geladene Klassen 53 sucht die spezifische Methode (Methode B) und gibt die Adresse der Methode an den Botschaftsüberbringer 51.
Dann ruft der Botschaftsüberbringer 51 Methode B auf, weist ihr einen Systemdatenbereich und die Parameter aus dem Aufruf zu, der von Methode A gemacht wurde, einschließlich des Zeigers. Methode B greift über den Zeiger auf den Datenblock 56 zu. Dann gibt Methode B die Steuerung an den Botschaftsüberbringer 51, der die Steuerung an die Methode A weitergibt.
Objekte können ständig oder nichtständig sein. Ein ständiges Objekt besteht aus Daten, die in nichtflüchtigen Datenspeichervorrichtungen 14 abgespeichert sind und die in den Prozessorspeicher (RAM 13) geholt werden, wenn sie zum ersten Mal von ihrer Objekt-ID angesprochen werden. Sie werden wieder zurück in die Vorrichtung 14 geschrieben, wenn eine Methode feststellt, daß alle Objektdaten in einem konsistenten Zustand sind. Das heißt dann "Festschreiben" der Daten. Herkömmliche Datenbanksysteme, z.B. D82 der IBM, beinhalten auch eine Festschreibefunktion, um sicherzustellen, daß alle Datenänderungen gleichzeitig wiedergegeben werden. Ständige Objekte werden in der US-Patentanmeldung Nr. 425,824 unter dem Titel "Persistent Data Interface for Object Oriented Programming Systems" beschrieben, deren Offenbarung hier durch Querverweis eingeschlossen ist. Nichtständige Objekte sind solche, deren Daten nicht ständig gespeichert sein müssen, und sind daher in der DASD 14 nicht vertreten.
Die vorliegende Erfindung betrifft eine Objektklasse, genannt ein "Datenstrom". Ein Datenstrom ist eine Liste der Identifikatoren aller Objekte in einer gegebenen Objektklasse und kann für jedes Glied der Klasse einige zugeordnete beschreibende Informationen enthalten. Die beschreibende Information repräsentiert in der Regel nur ein paar Attribute der zugrundeliegenden Objekte und wird für ausgedruckte Berichte oder Listen benutzt, die in einem Dialogbildschirm der Datenendstation 15 angezeigt werden. Fig. 6 illustriert eine Beispiel für einen Datenstrom "Teilenummern". Die Objekt-ID (OID) im Datenstrom ist eine Objekt-ID für jedes der aktuellen Objekte, die den Suchkriterien des Datenstroms entsprechen.
Ein Datenstrom wird aufgebaut durch eine Anfrage an eine Datenbank (wie z.B. eine relationale Datenbank). Die Anfrage enthält in der Regel Suchkriterien, so daß der Datenstrom eine Liste der Teilmenge der Klasse ist, die den Suchkriterien entspricht. Dieses Aufbauen einer Teilmenge einer Klasse kann ziemlich zeitaufwendig sein, in Abhängigkeit von den Gliedern der Klasse und der Komplexität der Suchkriterien.
Bisher waren Datenströme nichtständige Objekte. Sie repräsentieren eine Zusammenfassung von Daten in irgend einer Klasse ständiger Objekte, deren Daten sich daher in der zugrundeliegenden Datenbank finden. Damit werden die Daten im Datenstrom durch wiederholte Anfragen an die Datenbank nach dem nächsten Datensatz, der den Auswahlkriterien entspricht, gebildet. Es gibt keine Grenze für die Größe eines Datenstroms, abgesehen von den Grenzen, die durch das zugrundeliegende Datenbanksystem vorgegeben sind. Ein Datenstrom enthält in der Regel die folgenden Methoden:
Create Baut das Skelett des Datenstromobjekts auf und gibt den Datenstrom-Identifikator an die aufrufende Stelle zurück. Es erhält als Parameter alle Suchkriterien, die benutzt werden müssen, um eine Teilmenge der durchsuchten Objektklasse zu schaffen. Eine typische Botschaft zum Anfordern des Aufbaus eines Datenstroms ist:
mystream.CREATE (criterial, criteria2,...,return_code)
wobei die Werte sind wie folgt:
mystream Eine Variable, die für das vorliegende Beispiel willkürlich "mystream" genannt wurde und die durch Erklärung der Klasse des benötigten Datenstroms zugeordnet wird, z.B. durch:
mystream: type is part_number_stream;
Die Objekt-ID des neugeschaffenen Datenstroms wird in diese Variable gelegt.
criterial, etc. Die Suchkriterien, die für den besonderen Datenstromtyp definiert sind.
return code eine Variable zum Anzeigen, ob Ausnahmen aufgetreten sind.
Die Datenstromobjekt-Einsatzmittel, wie z.B. der flüchtige Speicher (RAM) zum Festhalten der Suchkriterien und sonstiger Datenstrom-Zustandsinformationen werden bei der Durchführung der Methode CREATE zugewiesen.
Open Zeigt an, daß der Datenstrom direkt anschließend benutzt wird, und bewirkt, daß der Datenstrom jede erforderliche Aktivität durchführt, um auf die gewünschten Datensätze zuzugreifen. Eine typische Botschaft zum Öffnen eines Datenstroms ist:
mystream.OPEN (return_code)
wobei die Werte sind wie folgt:
mystream Die Objekt-ID des von CREATE erzeugten Datenstroms.
return_code Eine Variable zum Anzeigen, ob eine Ausnahme vorgekommen ist.
Wenn eine OPEN-Methode aufgerufen wird, werden dem Datenstrom Datenbankbetriebsmittel zugeordnet, möglicherweise unter Aussperrung anderer Benutzer dieses Teils der Datenbank.
Get Gibt den nächsten Datensatz an den Anforderer. Eine typische Botschaft zum Abrufen eines Datensatzes ist:
mystrean.GET (stream_element, return_code)
wobei die Werte sind wie folgt:
mystream Die Objekt-ID des von CREATE erzeugten Datenstroms.
stream_element Eine Variable, die als zugehörig zu dem Typ definiert ist, der eine einzige Zeile des besonderen Datenstromtyps repräsentiert, wie z.B. eine Zeile des Datenstroms in Fig. 6.
return_code Eine Variable zum Anzeigen, ob eine Ausnahme vorgekommen ist. End-of- stream ist eine solche Ausnahme.
Wenn eine Methode GET aufgerufen wird, werden aktuelle Datenbank-Datensätze in der nichtflüchtigen Speichervorrichtung 14 (Fig. 4) gesucht und in den Speicher (RAM 13) gebracht.
Close Setzt die Datenbank wieder frei und entfernt alle Konzepte der Datenstromposition (laufende Datensatznummer) aus dem Datenstrom. Wenn dementsprechend später ein geschlossener Datenstrom wieder geöffnet wird, beginnt er am Anfang und nicht mit den "nächsten" Datensatz. Ein typisches Beispiel zum Schließen des Datenstroms ist:
mystream.CLOSE (return_code)
wobei die Werte sind wie folgt:
mystream Die Objekt-ID des von CREATE erzeugten Datenstroms.
return_code Eine variable zum Anzeigen, ob eine Ausnahme vorgekommen ist.
Wenn eine Methode CLOSE aufgerufen wird, werden die Datenbank-Einsatzmittel freigegeben.
Delete Setzt alle von Datenstrom verbrauchten Einsatzmittel frei. Eine typische Botschaft zum Löschen des Datenstroms ist:
mystream.DELETE (return_code)
dabei sind die Werte wie folgt:
mystream Die Objekt-ID des von CREATE erzeugten Datenstroms.
return_code Eine variable zum Anzeigen, ob eine Ausnahme vorgekommen ist.
Wenn die Methode DELETE aufgerufen wird, werden die Objekt-Einsatzmittel im RAM freigesetzt und die Objekt-ID des Datenstroms gilt nicht mehr.

BEISPIEL 1--DATENBANKANFRAGE OHNE STÄNDIGEN DATENSTROM

Jetzt soll eine Datenbankanfrage beschrieben werden, die nicht den ständigen Datenstrom der vorliegenden Erfindung verwendet. Am Beginn der Abfrage steht die Operation Create. In der Regel wird die Operation Create von einer Arbeitserfassungsfunktion angefordert wie z.B. von einem interaktiven Dialog. Der daraus entstehende Datenstrom wird dann an die Funktion weitergegeben, die den Datenstrom bearbeitet (Aufbau von Listenbildschirmen, Drucken von Datensätzen, Durchführen von Überprüfungen usw.). Ein typisches Szenario wäre z.B. ein Paar interaktive Dialogbildschirme im Anzeigeterminal 15, wie in Fig. 7 dargestellt ist.
Nehmen wir jetzt Bezug auf Fig. 7; der erste Dialogbildschirm fordert die Eingabe der Auswahlkriterien vom Anwender des Terminal. Nehmen wir für dieses Beispiel an, der Anwender habe keine Informationen für "Part#" und "Status", wohl aber "Plastic" für "Type" zur Suche eingegeben. Das würde eine Suche nach allen Kunststoffteilen bedeuten. Der erste Dialogbildschirm erzeugt den Datenstrom durch Weitergeben der folgenden Suchkriterien:
mystream.CREATE ("*", "*", "Plastic",myrcode)
Die Sterne werden als Joker benutzt, um anzugeben, daß für die beiden ersten Suchkriterien alle Werte gewünscht werden. Jetzt übernimmt der Datenstrom einfach die Suchkriterien aus dem Speicher (RAM), die dem Datenstromobjekt zugeordnet sind. Dann ruft der erste Dialogbildschirm den zweiten Dialogbildschirm auf und übergibt ihm die Objekt-ID des Datenstroms wie folgt:
panel2.CREATE(mystream)
Weiter unter Bezugnahme auf Fig. 7 öffnet (OPEN) der zweite Dialogbildschirm den Datenstrom und benutzt die Funktion GET zum Aufbauen einer Liste von Objekten (wie "parts"), die der Anwender behandeln (edit, delete, promote, print, usw.) kann je nach den Bedürfnissen dieser besonderen Anwendung. Die Methode OPEN stellt die Verbindung zur Datenbank her und identifiziert die zu suchenden Daten und die für die Suche benutzten Kriterien:
mystream.OPEN(myrcode)
Die Methode GET holt dann die Datensätze aus der Datenbank:
mystream.GET(mybuffer,myrcode)
Dieses GET kann möglicherweise eine lange Zeit in Anspruch nehmen, wenn eine große Anzahl Datenbankdatensätze durchsucht werden müssen, um die verhältnismäßig wenigen zu finden, die die Suchkriterien erfüllen.
Nachdem GET die Datensätze aus der Datenbank geholt hat, kann der Anwender die Arbeit ausführen, zu deren Durchführung der zweite Dialogbildschirm entworfen wurde. Z.B. kann der Anwender die Liste durchlaufen lassen und damit weitere GET Anforderungen an den Datenstrom stellen. Wenn immer der Anwender Befehle an die im Bildschirm aufgelisteten Objekte ausgibt, wird die ID des betroffenen Objekts benutzt, um die Aktionsanforderung an dieses betroffene Objekt zu schicken. In der Regel werden diese IDS dem Anwender nicht 4ezeigt, weil sie für den Anwender nicht verständlich zu sein brauchen - sie werden nur dazu benutzt, die betroffenen Objekte aufzufinden. Wenn sich der Anwender entschließt, den zweiten Bildschirm zu verlassen, schließt (CLOSE) der Dialog den Datenstrom, um die Datenbankbetriebsmittel freizugeben:
mystream.CLOSE(myrcode)
Der zweite Dialog kehrt dann zu seinem Aufrufer zurück, der der erste Dialog war.
Da der erste Dialog den Datenstrom geschaffen hat, muß er ihn jetzt auch wieder löschen (DELETE), um die Objekteinsatzmittel wieder freizugeben, wie folgt:
mystream.DELETE(myrcode)
Der Anwender kann die oben beschriebene Aktivität mit der gleichen oder einer anderen Abfrage wiederholen oder kann aus diesem Bildschirm aussteigen, um zu seinem Aufrufer zurückzukehren.
Jetzt soll die Ständige-Datenstrom-Klasse (Persistent Stream Class) der vorliegenden Erfindung beschrieben werden. Ein ständiger Datenstrom ist eine datenstromähnliche Objektklasse, die die Fähigkeit hat, die Ergebnisse einer Suche abzuspeichern, und die doch identisch mit den normalen Datenströmen erscheint, wenn Aktionsanforderungen geschickt werden, die in der normalen Datenstromspezifikation definiert sind. Die Ständige-Datenstrom-Klasse weist alle Merkmale eines Datenstroms auf, kann aber auch als Ständiges Objekt gespeichert werden. In der objektorientierten Terminologie handelt es such um eine Unterklasse von Datenströmen: Sie erbt alle Attribute und Methoden der Datenströme und sieht eine zusätzliche Funktion vor, d.i. die Fähigkeit weiterzubestehen.
Der Ständige Datenstrom der vorliegenden Erfindung kann von Anwendungen benutzt werden, die normale Datenströme erwarten, die zeitaufwendigen Datenbankdurchsuchungen können jedoch in einer Hintergrundumgebung (Stapel) durchgeführt werden. Der Ständige Datenstrom kann auch für Suchen benutzt werden, die in einer interaktiven Umgebung (Vordergrund) durchgeführt werden, deren Ergebnisse jedoch für künftige Anwendungen bereitgehalten werden müssen.
Ständige Datenströme beinhalten die gleichen Methoden wie normale Datenströme, plus eine neue Methode, genannt SAVE (Abspeichern). Für Ständige Datenströme sind die Methoden definiert wie folgt:
Create Ständige Datenströme reagieren auf die gleiche Botschaft CREATE wie normale Datenströme:
mystream.CREATE(criteria1, criteria2,...,return_code) mit dem Unterschied, daß die Variable "mystream" als erforderliche Ständige-Datenstrom-Klasse erklärt wird, wie:
mystream:type is part_number_persistent_stream;
Die Methode CREATE schafft ein Ständiges Objekt und speichert dieses Objekt in der Datenbank. Dieses Ständige Objekt wird benutzt, um die Suchkriterien zu speichern und um aufzuzeichnen, ob die Aktion SAVE durchgeführt wurde und wo die Ergebnisse der Suche abgespeichert sind. Die Ergebnisse der Suche können in jedem beliebigen nichtflüchtigen sequentiellen Speichermedium gespeichert werden, z.B. in der sequentiellen Datenspeichervorrichtung 14 (Fig. 4). Fig. 8 illustriert den Ständigen Datenstrom, der eben geschaffen wurde, und dessen Objekt-ID in "mystream" steht. Das Ständige-Datenstrom-Objekt hat eine zugewiesene und gespeicherte Objekt-ID, so daß es gefunden werden kann. Die Suchkriterien werden gespeichert, das Flag zeigt an, daß kein SAVE ausgeführt wurde und daß es noch keine sequentielle Datenmenge gibt.
Save Führt die ganze Suche durch und setzt die Ergebnisse in eine sequentielle Datenmenge. Diese Methode ist neu für Ständige Datenströme. Eine typische Botschaft zum Speichern (SAVE) eines Datenstroms ist:
mystream.SAVE(return_code)
wobei die Werte sind wie folgt:
mystream Die Objekt-ID des von CREATE erzeugten Datenstroms.
return_code Eine Variable zum Anzeigen, ob eine Ausnahme vorgekommen ist.
Vor dem SAVE sieht der Ständige-Datenstrom aus wie in Fig. 8 gezeigt ist. Die Methode SAVE weist die sequentielle Datenmenge zu und setzt ihren Namen (oder sonstigen Identifikator) in das Ständige- Datenstrom-Objekt. Dann führt sie das Aquivalent zum OPEN des normalen Datenstroms durch mit Anbinden der Datenbank zur Suche. Als nächstes führt sie wiederholte GETs von der Datenbank durch, um den nächsten Suchdatensatz abzurufen, und schreibt diesen Datensatz in die sequentielle Datenmenge. Wiederholte GETs werden durchgeführt, bis die Datenbank anzeigt, daß der letzte Suchdatensatz geholt wurde. Die Methode SAVE schließt dann die sequentielle Datenmenge und setzt den Indikator in das Ständige-Datentrom-Objekt, um anzuzeigen daß ein SAVE durchgeführt wurde. Der Ständige-Datenstrom und die sequentielle Datenmenge sehen jetzt aus wie in Fig. 9 gezeigt wird.
Open Ständige-Datenströme reagieren auf die gleiche GET Botschaft wie normale Datenströme:
mystream.GET(stream_element,return_code)
Wenn für diesen Ständigen-Datenstrom-Fall die Operation SAVE durchgeführt wurde, liest die Methode GET von der sequentiellen Datenmenge anstatt von der Datenbank. Das erfordert in der Regel viel weniger Aufwand als das Holen von der Datenbank. Wenn für diesen Ständigen-Datenstrom noch keine Operation SAVE durchgeführt wurde, verhält sich GET genau so wie bei normalen Datenströmen und ruft aus der Datenbank ab.
Close Ständige-Datenströme reagieren auf die gleiche CLOSE Botschaft wie normale Datenströme:
mystream.CLOSE(return_code)
Wenn die Operation SAVE für diesen Ständigen-Datenstrom-Fall bereits durchgeführt wurde, schaltet die Aktion CLOSE von der sequentiellen Datenmenge ab anstatt von der Datenbank. Wenn die Operation SAVE für diesen Ständigen-Datenstrom noch nicht durchgeführt wurde, verhält sich CLOSE genau so wie bei normalen Datenströmen und schaltet die Datenbankbetriebsmittel ab.
Delete Ständige Datenströme reagieren auf die gleiche DELETE Botschaft wie normale Datenströme:
mystream.DELETE(return_code)
Wenn die Operation SAVE für diesen Ständigen-Datenstrom-Fall durchgeführt wurde, löscht die Aktion DELETE die sequentielle Datenmenge und löscht dann die Ständigen-Datenstrom-Objekt-Betriebsmittel selbst. Wenn für diesen Ständigen-Datenstrom keine Operation SAVE durchgeführt wurde, verhält sich DELETE genau so wie bei normalen Datenströmen und löscht die Ständigen-Datenstrom-Objekt-Betriebsmittel. Jetzt werden die Objekteinsatzmittel freigesetzt und die Datenstrom-Objekt-ID ist nicht mehr gültig.

BEISPIEL 2--DATENBANKANFRAGE MIT STANDIGEM DATENSTROM

Jetzt wird die Datenbankabfrage der Fig. 7 beschrieben unter Verwendung von Ständigen-Datenströmen, um die Vorteile der vorliegenden Erfindung gegenüber herkömmlichen Datenströmen zu zeigen. Wie in Fig. 7 dargestellt ist, fordert der erste Dialogbildschirm die Auswahlkriterien vom Anwender der Datenendstation an und schafft (CREATE) den Datenstrom unter Weitergabe der gleichen Suchkriterien:
mystream.CREATE ("*", "*", "Plastic",myrcode)
Diesmal wurde jedoch "mystream" als Ständiger-Datenstrom erklärt und die Botschaft CREATE wird zur Ausführung in die Klasse der ständigen Datenströme geführt. Die Sterne sind wieder Joker. Für diesen neuen Fall eines Ständigen Datenstroms wird ein Datenbankdatensatz eingeschoben und seine Objekt-ID, die drei Suchkriterien, das Flag SAVED=No und ein sequentieller Datenmengen-Nullzeiger werden in den neuen Datensatz geschrieben, wie in Fig. 8 illustriert wird.
Dann bewirkt der erste Dialogbildschirm, daß die Abfrage des ersten Ständigen-Datenstroms gefahren wird. Hier muß verstanden werden, daß die Abfräge auf unterschiedliche Weise gefahren werden kann, in Abhängigkeit von dem Grund, warum ein Ständiger-Datenstrom benutzt wird. Wenn z.B. die Ergebnisse der Abfrage mehr als einmal benutzt werden, kann die Anfrage des Ständigen-Datenstroms interaktiv betrieben werden. Der Anwender kann aufgefordert werden, anzugeben, ob die Ergebnisse der Anfrage mehr als einmal benutzt werden sollen. Oder aber, wenn die Abfrageoperation eine lange Zeit erfordert, kann ein Stapel-Job (Hintergrund) gefahren werden, der die Anfrage außerhalb der Stoßzeiten durchführt. Der Anwender kann aufgefordert werden, anzugeben, ob es sich um eine zeitaufwendige Anfrage handelt. Als Alternative kann die Abfrage geprüft und eine geschätzte Durchlaufzeit berechnet werden. Wenn die geschätzte Durchlaufzeit länger als eine vorgegebene Zeit ist, kann automatisch eine Stapelabfrage ausgeführt werden.
Wenn immer die Abfrage läuft, wird eine Botschaft an den Ständigen-Datenstrom geschickt, damit er seine Methode SAVE ausführt:
mystream.SAVE(myrcode)
Wie oben beschrieben, weist die Methode SAVE eine sequentielle Datenmenge zu, setzt ihren Namen in die Datenbank, fährt die Abfrage, schreibt die Ergebnisse in die sequentielle Datenmenge und stellt das Flag auf SAVED=Yes. Eine Technik zum Implementieren der Methode SAVE ist die Anwendung der Methoden OPEN, GET und CLOSE der Eltern-Objektklasse (normale Datenströme), um zu vermeiden, daß diese Programme zweimal geschrieben werden müssen.
Als nächstes wird der zweite Dialogbildschirm in Fig. 7 aufgerufen. Wenn die Anfrage vom ersten Dialog interaktiv gefahren wurde, wird der zweite Dialog identisch mit Beispiel 1 aufgerufen. Wenn ein Hintergrund-Job die Abfrage fährt, wird typischerweise ein "job done" Dialog den zweiten Dialogbildschirm aufrufen. In jedem dieser Fälle wird der zweite Dialogbildschirm mit der gleichen Botschaft aufgerufen wie im Szenario, das ein normales Datenstrombeispiel zeigt:
panel2.CREATE(mystream)
Gemäß der Erfindung weiß der zweite Dialog nicht, daß er einen Ständigen-Datenstrom anstatt eines normalen Datenstroms erhält. Wie in Beispiel 1, öffnet (OPEN) der zweite Dialogbildschirm den Datenstrom und benutzt die Funktion GET zum Erstellen einer Liste von Objekten, die der Anwender behandeln kann:
mystream.OPEN(myrcode)
Für den Ständigen-Datenstrom frägt die Methode OPEN das SAVED-Flag in seinem Datensatz der Datenbank ab. Da SAVE durchgeführt wurde, schließt es die sequentielle Datenbank an, deren Identifikator auch in der Datenbank steht. GET holt dann die Abfrage-Datensätzte:
mystream.GET(mybuffer,myrcode)
Da der Ständige-Datenstrom abgespeichert ist, werden die Abfrageresultate aus der sequentiellen Datenmenge abgelesen. Da in dieser Datenmenge nur Datensätze enthalten sind, die der Abfrage entsprechen, ist der Aufwand für die Bearbeitung bei "Datenstromzeit" typisch erheblich geringer als für die Abfrage, die die Ergebnisse produziert hat.
Wenn für den Ständigen-Datenstrom noch keine SAVE-Methode durchgeführt wurde, wird zu diesem Zeitpunkt eine Abfrage gefahren. Zu diesem Zweck können verschiedene Techniken eingesetzt werden. Zum Beispiel kann der Abfrage-Code als Teil des Ständigen-Datenstroms vorgesehen sein. Als Alternative kann die Abfrageanforderung zu den (Normaldatenstrom) Methoden OPEN, GET und CLOSE des Elter umgeleitet werden. Alternativ dazu kann auch implizit ein SAVE als Teil der Implementierung des OPEN für den Ständigen-Datenstrom gefahren werden.
Wenn der Anwender dann den zweiten Bildschirm verläßt, schließt (CLOSE) der zweite Dialog den Datenstrom:
mystream.CLOSE(myrcode)
Bei abgespeicherten (SAVE) Ständigen-Datenströmen schaltet das von der sequentiellen Datenmenge ab. Der zweite Dialog kann dann zu seinem Aufrufer zurückkehren. Da die Ständigen- Datenströme ständig sind, ist es möglich, daß der Aufrufer die Datenströme zu diesem Zeitpunkt nicht immer löschen will. Wenn jedoch die Anwendung und/oder der Anwender beschließt, daß der Ständige-Datenstrom nicht mehr gebraucht wird, wird an den Datenstrom eine DELETE-Botschaft geschickt:
mystream.DELETE(myrcode)
Die sequentielle Datenmenge wird selbst gelöscht, der Datenbankdatensatz wird gelöscht und alle anderen Einsatzmittel werden freigegeben.
Wie oben beschrieben, sieht die Klasse der Ständigen-Datenströme der vorliegenden Erfindung die Möglichkeit vor, Abfrageergebnisse so abzuspeichern, daß die Ständigkeit bzw. Nichtständigkeit des Abfrageergebnisses für das etwaige arbeitausführende Programm, das diese Abfrageergebnisse benutzt, codeunabhängig ist. Ständige-Datenströme können im Hintergrund abgespeichert (SAVE) werden, wenn reichlich Systemeinsatzmittel vorhanden sind, wobei der interaktive Anwender im Vordergrund andere Arbeiten durchführen kann. Dem arbeitausführenden Prozeß kann entweder ein regulärer Datenstrom oder ein Ständiger-Datenstrom zugeführt werden. Er schickt die gleichen Botschaften an den Datenstrom, unabhängig davon, was für ein Datenstrom sie empfängt. Da Ständige-Datenströme auf gleiche Weise auf Open-, Get-, Close- und Delete-Botschaften reagieren wie normale Datenströme, ist die Art des Stroms für den Anwender des Datenstroms völlig codeunabhängig, wodurch vermieden wird, daß der Programmcode für unterschiedliche Datenguellentypen mehrfach geschrieben werden muß.

Claims

1. Ein Prozeß zur Handhabung zeitaufwendiger und wiederverwendbarer Abfragen in einem objekt-orientierten Datenbankverwaltungssystem, das umfaßt:

eine Datenspeichervorrichtung (Fig. 4, 14),

eine Datenbank mit Datenobjekten, die in der Datenspeichervorrichtung abgespeichert sind,

einen Datenprozessor (Fig. 4, 11), der mit der Datenspeichervorrichtung verbunden ist, und

eine objekt-orientierte Datenbankverwaltung (Fig. 4, 12), die in dem Datenprozessor arbeitet, um Abfragen nach den Datenobjekten in der Datenbank durchzuführen,

wobei dieser Prozeß dadurch gekennzeichnet ist, daß er die folgenden Schritte umfaßt:

Vorsehen einer Datenstromklasse von Objekten enthaltend eine Vielzahl von Datenstromklasse-Attributen und wenigstens eine Datenstromklassemethode, die die Operationen definiert, die an den Objekten als Reaktion auf die Abfrage ausgeführt werden können, wobei die Datenstrom klasse-Attribute eine Liste von Datenobjekten enthalten, die sich aus einer Abfrage ergeben, die von der objektorientierten Datenbankverwaltung durchgeführt wurde,

Vorsehen einer ständigen Datenstromklasse von Objekten, die als Unterklasse der Datenstromklasse organisiert ist, um dabei die Datenstromklasse-Attribute und die wenigstens eine Datenstromklassemethode zu übernehmen, und eine Vielzahl ständiger Datenstromklasse-Attribute und wenigstens eine ständige Datenstromklassemethode enthält, und diese ständigen Datenstromklasse-Attribute ferner eine Liste mit Abfragekriterien für eine Abfrage enthalten, die wenigstens eine ständige Datenstromklassemethode und wenigstens eine Methode zum Erzeugen und Speichern ständiger Objekte in der Datenspeichervorrichtung und zum Sichern der Liste der Datenobjekte, die sich aus einer Abfrage ergeben, die durch die objektorientierte Datenbankverwaltung in der Datenspeichervorrichtung durchgeführt wurde, enthält.

2. Der Prozeß gemäß Anspruch 1, dadurch gekennzeichnet, daß diese Sicherungsmethode die folgenden Schritte durchführt:

Zuweisen einer Speicherstelle in der Datenspeichervorrichtung zum dort Sichern der Liste der sich aus einer Abfrage ergebenden Datenobjekte,

Gewinnen der Liste der sich aus einer Abfrage ergebenden Datenobjekte, und

Sichern der Liste der sich aus einer Abfrage ergebenden Datenobjekte an der zugewiesenen Stelle, und

Anzeigen, daß die Liste der sich aus einer Abfrage ergebenden Datenobjekte gewonnen und gesichert ist.

3. Der Prozeß gemäß Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß die ständigen Datenstromklasse-Attribute ferner ein erstes Kennzeichen dafür, ob die Liste der sich aus einer Abfrage ergebenden Datenobjekte, in der Datenspeichervorrichtung gesichert wurden, und ein zweites Kennzeichen für die Stelle in der Speichervorrichtung, an der die Liste der sich aus einer Abfrage ergebenden Datenobjekte gesichert wurde, umfassen, wobei der Anzeigeschritt die Schritte Setzen des ersten Kennzeichens und Einsetzen der zugewiesenen Stelle in das zweite Kennzeichnen enthalten.

4. Der Prozeß gemäß Anspruch 2, dadurch gekennzeichnet, daß dieser Schritt des Gewinnens folgende Schritte umfaßt:

der Reihe nach Gewinnen jedes sich aus der Abfrage ergebenden Datenobjekts in der Datenbank, und

Sichern jedes sich aus der Abfrage ergebenden Datenobjekts in der Datenbank an der zugewiesenen Stelle in der Datenspeichervorrichtung.

5. Der Prozeß gemäß Anspruch 1, dadurch gekennzeichnet, daß er ferner folgende Schritte umfaßt:

Übernehmen einer Abfrage, die in der Datenbank der Datenobjekte durchzuführen ist,

Bestimmen, ob eine übernommene Abfrage gesichert werden soll,

Senden einer Abfragemeldung an das ständige Datenstrom klasseobjekt, wenn eine übernommene Abfrage gesichert werden soll, und

Senden einer Abfrageneldung an die Datenstromklasse, wenn eine übernommene Abfrage nicht gesichert werden soll.

6. Der Prozeß gemäß Anspruch 5, dadurch gekennzeichnet, daß der Schritt des Bestimmens die folgenden Schritte umfaßt:

Übernehmen einer Anzeige, daß eine übernommene Abfrage unverzüglich auszuführen ist, und

Bestimmen, daß eine übernommene Abfrage nicht gesichert werden soll, wenn sie unverzüglich auszuführen ist.

7. Der Prozeß gemäß Anspruch 6, dadurch gekennzeichnet, daß der Schritt des Bestimmens die folgenden Schritte umfaßt:

Übernehmen einer Anzeige, daß eine übernommene Abfrage wiederzuverwenden ist, und

Bestimmen, daß eine übernommene Abfrage zu sichern ist, wenn die übernommene Abfrage wiederzuverwenden ist.

8. Der Prozeß gemäß Anspruch 5, dadurch gekennzeichnet, daß der Schritt des Bestimmens die folgenden Schritte umfaßt:

Abschätzen der für die Bearbeitung einer übernommenen Abfrage erforderlichen Zeit, und

Bestimmen, daß eine übernommene Abfrage zu sichern ist, wenn die geschätzte Bearbeitungszeit eine vorgegebene Zeitspanne überschreitet.

9. Eine Vorrichtung zum Behandeln zeitaufwendiger und wiederverwendbarer Abfragen in einem objekt-orientierten Datenbankverwaltungssystem, enthaltend:

eine Datenspeichervorrichtung (Fig. 4, 14),

eine objekt-orientierte Datenbankverwaltung (Fig. 4, 12), die in dem Datenprozessor arbeitet, um Abfragen der Datenbank der Datenobjekte durchzuführen, wobei die Datenbankverwaltung eine Datenstromklasse von Objekten umfaßt, die eine Vielzahl von Datenstromklasse-Attributen und wenigstens eine Datenstromklassemethode beinhaltet, die die Operationen definiert, die als Reaktion auf die Abfrage an den Objekten ausgeführt werden können, wobei die Datenstromklasse-Attribute eine Liste von Datenobjekten beinhalten, die sich aus einer Abfrage ergeben, die von der objekt-orientierten Datenbankverwaltung durchgeführt wird,

wobei diese Vorrichtung dadurch gekennzeichnet ist, daß die objekt-orientierte Datenbankverwaltung eine ständige Datenstromklasse von Objekten beinhaltet, wobei diese ständige Klasse von Objekten umfaßt:

eine Vielzahl ständiger Datenstromklasse-Attribute und wenigstens eine ständige Datenstromklassemethode, und diese ständige Datenstromklasse als Unterklasse der ständigen Datenstromklasse organisiert ist um dadurch die Datenstromklasse-Attribute zu übernehmen, die ständigen Datenstromklasse-Attribute dabei ferner eine Liste der Abfragekriterien für eine Abfrage enthalten und die wenigstens eine ständige Datenstromklassemethode ferner eine Sicherungsmethode zum Erzeugen und Abspeichern eines ständigen Objekts in der Datenspeichervorrichtung und zum Sichern der Liste der sich aus einer Abfrage ergebenden Datenobjekte enthält, die aus einer durch die objektorientierte Datenbankverwaltung in der Datenspeichervorrichtung durchgeführten Abfrage entstehen.

10. Die Vorrichtung gemäß Anspruch 9, dadurch gekennzeichnet, daß die Sicherungsmethode umfaßt:

Mittel zum Zuweisen einer Speicherstelle in der Speichervorrichtung zum dort Sichern der Liste der sich aus einer Abfrage ergebenden Datenobjekte,

Mittel zum Gewinnen der Liste der sich aus einer Abfrage ergebenden Datenobjekte, und

Mittel zum Sichern der Liste der sich aus einer Abfrage ergebenden Datenobjekte an der zugewiesenen Stelle, und

Mittel zum Anzeigen, daß die Liste der sich aus einer Abfrage ergebenden Datenobjekte aufgestellt und gesichert ist.

11. Die Vorrichtung gemäß Anspruch 9 oder Anspruch 12, dadurch gekennzeichnet, daß diese ständigen Datenstromklasse-Attribute ferner ein erstes Kennzeichen dafür, ob die Liste der sich aus einer Abfrage ergebenden Datenobjekte an der Datenspeicherstelle gesichert wurden, und ein zweites Kennzeichen für die Stelle in der Speichervorrichtung, an der die Liste der sich aus einer Abfrage ergebenden Datenobjekte gesichert wurde, umfassen.

12. Die Vorrichtung gemäß Anspruch 10, dadurch gekennzeichnet, daß die Mittel zum Gewinnen umfassen

Mittel zum seriellen Gewinnen jedes sich aus der Abfrage ergebenden Datenobjekts in der Datenbank, und

die Mittel zum Sichern Mittel zum Sichern jedes sich aus der Abfrage ergebenden Datenobjekts in der Datenbank an der zugewiesenen Stelle in der Datenspeichervorrichtung beinhalten.

13. Die Vorrichtung gemäß Anspruch 9, dadurch gekennzeichnet, daß die Datenbankverwaltung ferner umfaßt:

Mittel zum Übernehmen einer Abfrage, die an der Datenbank der Datenobjekte durchzuführen ist,

Mittel zum Bestimmen, ob eine übernommene Abfrage gesichert werden soll,

Mittel zum Senden einer Abfragemeldung an das ständigen Datenstromklasseobjekt, wenn eine übernommene Abfrage zu sichern ist, und

Mittel zum Senden einer Abfragemeldung an die Datenstromklasse, wenn eine übergenommene Abfrage nicht gesichert werden soll.

14. Die Vorrichtung gemäß Anspruch 13, dadurch gekennzeichnet, daß die Mittel zum Bestimmen umfassen:

Mittel zur Übernahme einer Anzeige, daß eine übernommene Abfrage unverzüglich auszuführen ist, und

Mittel zum Bestimmen, daß eine übernommene Abfrage nicht zu sichern ist, wenn die übernommene Abfrage unverzüglich auszuführen ist.

15. Die Vorrichtung gemäß Anspruch 13, dadurch gekennzeichmet, daß die Mittel zum Bestimmen umfassen:

Mittel zur Übernahme einer Anzeige, daß die übernommene Abfrage wiederzuverwenden ist, und

Mittel zum Bestimmen, daß eine übernommene Abfrage zu sichern ist, wenn die übernommene Abfrage wiederzuverwenden ist.

16. Die Vorrichtung gemäß Anspruch 13, dadurch gekennzeichnet, daß die Mittel zum Bestimmen umfassen:

Mittel zum Abschätzen der für die Bearbeitung einer übernommenen Abfrage erforderlichen Zeit, und

Mittel zum Bestimmen, daß eine übernommene Abfrage zu sichern ist, wenn die geschätzte Bearbeitungszeit eine vorgegebene Zeitspanne überschreitet.