DE3588007T2

DE3588007T2 - Verwaltungssystem für relationale datenbank.

Info

Publication number: DE3588007T2
Application number: DE3588007T
Authority: DE
Inventors: Val Joseph Huber
Original assignee: Wang Laboratories Inc
Current assignee: WANG LABORATORIES Inc BILLERICA MASS US
Priority date: 1985-01-11
Filing date: 1985-12-23
Publication date: 1995-10-26
Anticipated expiration: 2005-12-24
Also published as: JPH06236305A; JPH06282473A; EP0187373A3; JPS61221819A; JPH06236304A; EP0187373B1; EP0187373A2; JP2955289B2; JPH06236303A; CA1268259C; DE3588007D1; CA1249375A; CA1301366C

Description

Die Erfindung bezieht sich auf den Betrieb von Datenverarbeitungssystemen, insbesondere auf die Verwaltung von im Speicher solcher Systeme gespeicherten relationalen Datenbänken. Die Erfindung betrifft ferner Einrichtungen zum Vereinfachen der interaktiven Benutzung, der Wiedergewinnung zusammengehöriger Datensätze sowie der Fehlerbearbeitung und der Aktualisierung solcher relationaler Datenbänke.

STAND DER TECHNIK

Die Erfindung wird in einem Datenverarbeitungssystem verwendet, das ein oder mehrere Endgeräte oder Konsolen aufweist, die Anzeigeeinrichtungen und Signaleingabegeräte, z.B. Tastaturen, bereitstellen, und das in einem Speicher physische Datensätze bereithält, die als wenigstens eine relationale Datenbank modelliert sind.
Unter den einzelnen Endbenutzern des Datenverarbeitungssystems und der Datenbank-Datensätze sind bestimmte Benutzer, z.B. Büroangestellte und Manager, keine Programmierer. Solche Benutzer möchten in der Lage sein, die System-Endgeräte zum Betrachten angezeigter Darstellungen der im Speicher des Datenverarbeitungssystems gespeicherten Datensätze, zum Auswählen spezieller Datensätze oder spezieller Teile von Datensätzen zum Betrachten, Entfernen oder Modifizieren von Datensätzen im Speicher oder zum Hinzufügen neuer physischer Datensätze in den Speicher zu benutzen. Zu diesen Zwecken müssen die physischen Datensätze abgerufen, im physikalischen Speicher für den Zugriff bereitgestellt und wiedergewonnen (kopiert) werden, und Darstellungen der wiedergewonnenen Datensätze müssen für den Benutzer an einem der Endgeräte in einem vorbestimmten Anzeigeformat angezeigt werden.
Um diese Benutzung der gespeicherten Datenbank-Datensätze zu ermöglichen, müssen im Datenverarbeitungssystem codierte Anweisungen gespeichert sein, die bei ihrer Ausführung durch das Datenverarbeitungssystem die Anzeige von Darstellungen der physischen Datensätze sowie Darstellungen von durch den Benutzer über die Tastatur eingegebenen Signalen in einem speziellen Format am Sichtgerät verursachen. Ferner müssen codierte Anweisungen gespeichert sein, die bei ihrer Ausführung durch das Datenverarbeitungssystem die Interpretierung der durch den Benutzer über die Tastatur eingegebenen Signale verursachen und die Wiedergewinnung und die Modifikation der physischen Datensätze der gespeicherten Datenbank in Antwort auf solche Eingangssignale bewirken.
Derartige Anweisungen, die für eine bestimmte Benutzung der Datensätze einer speziellen Datenbank ausgelegt sind, bilden zusammen eine als "Datenbank-Anwendungsprogramme" bekannte Programmklasse, also Programme, die vom Endbenutzer des Datenverarbeitungssystems zur Ausführung der von ihm gewünschten Anwendung an den gespeicherten physischen Datensätze einer speziellen Datenbank benutzt werden.
Die Erstellung solcher Anwendungsprogramme hat üblicherweise Wochen oder Monate Aufwand seitens eines Anwendungsprogrammierers erfordert, gefolgt von zusätzlichen Wochen bei der Auffindung und Beseitigung von Programmfehlern, um das Programm bei der Benutzung zuverlässig und relativ fehlerfrei zu machen.
Es sind daher Mittel wünschenswert, welche die Erstellung und den Betrieb solcher Datenbank-Anwendungsprogramme vereinfachen, und es ist Aufgabe meiner Erfindung, solche Mittel zu schaffen.
Wie in der Fachwelt bekannt, befassen sich die Benutzer (oder Programmierer) eines Datenverarbeitungssystems nicht direkt mit den im Systemspeicher gespeicherten physischen Datensätzen, sondern mit einem Modell solcher Datensätze, das bei Bedarf von Programmen geliefert wird, die im Systemspeicher gespeichert sind und bei Bedarf vom Prozessor ausgeführt werden.
Gemäß Fig. 1 sind die physischen Datensätze auf physikalischen Datenträgern gespeichert, vorteilhafterweise als magnetische Signale auf Magnetplatten 24, die einen Sekundärspeicher 16 bilden. Auf den Platten 24 sind die magnetischen Signale physikalisch in einer Weise organisiert, die in der Fachwelt auf dem Gebiet der Verwaltung solcher Speichermedien bekannt sind. Die spezielle Organisation solcher Signale und die speziellen Einrichtungen zum Auffinden und Kopieren derselben in den Hauptspeicher 14 sind in hohem Maße von den hardwaremäßigen Merkmalen der verwendeten speziellen Speichermedien abhängig.
Es sind mehrere Modelle der Datensätze vorgesehen, die verschiedene Abstraktionsgrade gegenüber den zugrunde liegenden gespeicherten physischen Datensätze aufweisen. Diese sind (gemäß Fig. 1) in kurzen Worten folgende: die "externe" Ansicht (26 oder 28), in welcher der Benutzer "externe" oder "logische" Datensätze sieht; die "konzeptionelle" Ansicht (30), in der "konzeptionelle" Datensätze gesehen werden, wobei jede externe Ansicht eine Teilmenge der konzeptionellen Ansicht ist; und die "interne" Ansicht (32), in der "interne" oder "gespeicherte" Datensätze gesehen werden.
Es ist klar, daß, wenn das Datenverarbeitungssystem die Datensätze jeder der in Fig. 1 dargestellten Ansichten konstruiert und zur Benutzung anbietet, diese Datensätze zu diesem Zeitpunkt (während dieser Benutzung) innerhalb des Datenverarbeitungssystems durch physikalische Signale dargestellt sind, die von den auf den Platten 24 gespeicherten magnetischen Signalen abgeleitet sind. Beim Abschluß einer solchen Benutzung sind die konstruierten Datensätze im System 10 nicht mehr physikalisch dargestellt. Dagegen bleiben die eigentlichen physischen Datensätze, die auf den Platten 24 gespeichert sind, jederzeit auf den Platten, unabhängig davon, ob sie benutzt werden oder nicht, bis sie entfernt oder modifiziert werden.
Die Signale, welche die in den verschiedenen Ansichten 26, 28, 30 und 32 gesehenen Datensätze darstellen, sind von den durch das Datenverarbeitungssystem auf dem Datenträger 24 gespeicherten physischen Datensätzen durch den Betrieb eines Datenbank-Verwaltungssystems abgeleitet, mit anderen Worten, durch die Ausführung geeigneter gespeicherter Programme durch den Prozessor 12. Wie in der konzeptionellen Darstellung der Fig. 2 zu erkennen, werden die physischen Datensätze auf den Datenträgern 24 durch das Datenverarbeitungssystem physikalisch geschrieben, kopiert und entfernt mit Steuerung durch ein als Zugriffsmethode bekanntes Programmelement in einer der Fachwelt bekannten und nicht Teil der vorliegenden Erfindung bildenden Weise. Die Zugriffsmethode wird als Methode betrachtet, die dem Datenbank-Verwaltungssystem "gespeicherte" oder "interne" Datensätze liefert, die den physischen Datensätzen entsprechen und von ihnen abgeleitet sind.
Die "interne" Ansicht wird vom Benutzer der Datenbank nicht gesehen (wenngleich sie einem das System benutzenden Programierer bekannt sein kann). Der Prozessor 12, der nach anderen Teilen des Programms des Datenbank-Verwaltungssystems arbeitet, konstruiert aus den gespeicherten oder internen Datensätzen die Datensätze der konzeptionellen Ansicht und ihre Teilmengen, nämlich die externen Ansichten. Die Definitionen der konzeptionellen Datensätze sind unabhängig von der Speicherstruktur oder der Strategie, welche die Zugriffsmethode zur wirkungsvollen Auffindung und Wiedergewinnung der physischen Datensätze anwendet.
Datensätze in einer Datenbank können mit anderen Datensätzen in der Datenbank in Beziehung stehen, und diese Beziehung ist für den Benutzer der Datenbank von Interesse. Die Beziehung wird selbst als ein Objekt in der Datenbank dargestellt.
Für die Fachwelt auf dem Gebiet der Datenbankverwaltung versteht es sich, daß die konzeptionellen Datensätze einer Datenbank und die Beziehungen zwischen ihnen in einer von drei möglichen Weisen organisiert oder modelliert werden können, die als relationale, hierarchische und Netzwerk-Modelle bekannt sind.
Die vorliegende Erfindung bezieht sich auf die Verwaltung der Datensätze einer Datenbank, die als relationale Datenbank modelliert ist.
Die Datensätze einer relationalen Datenbank sind konzeptionell als Tabellen organisiert (die auch als "Relationen" bezeichnet werden). Gemäß Fig. 3 umfaßt eine Tabelle (Relation) einer relationalen Datenbank eine Vielzahl von Zeilen; jede Zeile ist ein Datensatz (oder Tuple) mit einer Vielzahl von Feldern. Alle Zeilen einer bestimmten Tabelle haben die gleiche Anzahl Felder. Die Felder der Datensätze sind in Spalten angeordnet; eine Spalte wird auch als Attribut bezeichnet. Die Elemente einer Spalte sind alle Elemente einer Klasse solcher Elemente, die als Domäne bezeichnet wird, und die Spalte wird nach einer Spaltenüberschrift benannt (Domänenamen). Jeder Datensatz umfaßt ein oder mehrere Felder, deren Inhalt ein Index oder Schlüssel ist, der zur eindeutigen Kennzeichnung des Datensatzes verwendet wird.
Ein kritisches Merkmal einer relationalen Datenstruktur besteht darin, daß Beziehungen zwischen Zeilen (Tuplen) allein durch Datenwerte in Spalten dargestellt sind, die aus einer gemeinsamen Domäne stammen, statt in Form des realen Ortes der zusammengehörigen Datensätze auf der Platte.
Relationale Datenbänke haben verschiedene Vorteile gegenüber den beiden alternativen Modellen. Während, allgemein gesprochen, hierarchische und Netzwerk-Datenbänke so organisiert sind, daß die Bearbeitung jeweils eines Datensatzes und die Erzielung jeweils eines einzelnen zugehörigen Datensatzes wirkungsvoll ausgeführt werden können, sind relationale Datenbänke so organisiert, daß die Bearbeitung jeweils einer Datensatz-Gruppe und die Erzielung jeweils einer Gruppe zugehöriger Datensätze wirkungsvoll ausgeführt werden können.

VERWALTUNG EINER RELATIONALEN DATENBANK

Es ist ein wichtiges Merkmal des relationalen Modells, daß die Tabellen (Relationen), wenn sie bestimmte Forderungen erfüllen, als mathematische Elemente, auch Relationen genannt, betrachtet werden können, für deren Behandlung bereits ein strenges mathematisches Verfahren existiert. Folglich können Operationen an den Tabellen in Form dieser mathematischen Theorie analysiert werden, ein Vorteil für das klare Verständnis der Wirkungen solcher Operationen. Insbesondere ermöglicht die Darstellung der Daten in der Form von gleichmäßig definierten Gruppen eine entsprechende Gleichmäßigkeit in der Gruppe der Operatoren, welche die Gruppe transformieren, was die Aufgabe vereinfacht, Programmteile zum Steuern eines Datenverarbeitungssystems bei der Transformierung solcher Gruppen bereitzustellen.
Aufgabe der Erfindung ist es, diesen Vorteil auf ihn nicht aufweisende Merkmale einer Datenbankpflege auszudehnen, indem eine bestimmte Relation bereitgestellt wird.
Die Erfindung ist im Anspruch 1 angegeben.
Ein Datenverarbeitungssystem umfaßt eine Tastatur für Eingangssignale, ein Sichtgerät, Speichervorrichtungen, die Signale liefern, welche eine Vielzahl von Treffer-Datensätzen darstellen, die als Relationen in einer relationalen Datenbank organisiert sind, einen Arbeitsspeicher, und einen Prozessor mit Einrichtungen zum Steuern des Sichtgerätes, zum Lesen und Schreiben aus und in den Arbeitsspeicher, und zum Ansprechen auf die Eingangssignale. Der Prozessor verfügt ferner über eine Zugriffseinrichtung zum Abrufen von Treffer- Datensatz-Signalen aus der Datenbank und zum Speichern abgerufener Treffer-Datensatzsignale im Arbeitsspeicher.
Gemäß einem ersten Merkmal der zum Schutz beanspruchten Erfindung, das sich auf die Vorrichtung zum Verwalten einer relationalen Datenbank bezieht, zeichnet sich das Datenverarbeitungssystem aus durch eine Einrichtung im Arbeitsspeicher, die für ein vordefiniertes Anzeigeformat repräsentative Formatsignale und Cursorsignale liefert, die für einen nach einem Ziel, das wenigstens eine der Relationen in der Datenbank umfaßt, definierten Cursor repräsentativ sind, und durch eine Einrichtung für relationale Operatoren, die Signale liefert, die für eine Ergebnisbeziehung repräsentativ sind, wobei die Zugehörigkeit zu ihr über die Tastatur aufzählbar und interaktiv definiert ist.
Die Operator-Einrichtung umfaßt eine Cursorannahme-Einrichtung zum Akzeptieren der Cursorsignale aus dem Arbeitsspeicher. Die Systemzugriffseinrichtung spricht auf die Cursorannahme-Einrichtung in der Weise an, daß sie aus dem Ziel- Treffer-Datensatz durch den Cursor spezifizierte Signale abruft.
Die Einrichtung für relationale Operatoren umfaßt ferner eine Einrichtung zum Definieren des Bildschirmbildes zum Annehmen der Formatsignale aus dem Arbeitsspeicher und zum Definieren und Speichern von Bildschirmbildsignalen, die ein Biddschirmbild repräsentieren, in Antwort auf die Formatsignale und auf die abgerufenen Treffer-Datensatz-Signale. Der Prozessor reagiert auf die Operator-Einrichtung durch die Steuerung des Anzeigegerätes in der Weise, daß eine Darstellung der gespeicherten Bildschirmbildsignale angezeigt und die gespeicherten Bildschirmbildsignale entsprechend den bestimmten bzw. aufzählenden Signalen von der Tastatur modifiziert werden, welche während einer solchen Anzeige eingegeben werden, wobei bestimmte der abgerufenen Treffer-Datensätze bestimmt werden.
Die Operator-Einrichtung umfaßt ferner eine Einrichtung, die von den modifizierten Bildschirmbildsignalen und den Cursorsignalen Ausgangssignale ableitet, welche eine Ergebnisrelation definieren, bei der die Zugehörigkeit zu ihr enumerativ definiert wird, und die Ausgangssignale im Arbeitsspeicher speichert.
Weitere Aufgaben, Merkmale und Vorteile ergeben sich aus der nachstehenden Beschreibung einer bevorzugten Ausführungsform meiner Erfindung im Zusammenhang mit den Zeichnungen, in denen zeigt:
Fig. 1 und 2 konzeptionelle Darstellungen der Beziehung zwischen den eine Datenbank bildenden physischen Datensätzen und dem Benutzer des Datenverarbeitungssystems,
Fig. 3 die Komponenten einer üblichen Relation einer relationalen Datenbank,
Fig. 4 ein vereinfachtes Blockschaltbild eines Datenverarbeitungssystems, in dem die Erfindung angewendet wird,
Fig. 5 die Tastatur des Datenverarbeitungssystems gemäß Fig. 4,
Fig. 6 eine konzeptionelle Darstellung der Zuweisung von Datenspeicherplatz im Datenverarbeitungssystem gemäß Fig. 4,
Fig. 6a die Zuweisung eines Teils des Datenspeicherteils der Speichervorrichtung des Datenverarbeitungssystems gemäß Fig. 4,
Fig. 6b eine konzeptionelle Darstellung der Zuweisung von Arbeitsspeicherplatz im Datenverarbeitungssystem gemäß Fig. 4,
Fig. 7 eine konzeptionelle Darstellung der Zuweisung von Programmspeicherplatz im Datenverarbeitungssystem gemäß Fig. 4,
Fig. 7a die Zuweisung eines Teils des Programmspeicherteils der Speichervorrichtung des Datenverarbeitungssystems gemäß Fig. 4,
Fig. 7b eine konzeptionelle Darstellung der Zuweisung von Programmspeicherplatz im Datenverarbeitungssystem gemäß Fig. 4,
Fig. 8a und 8b ein verwendetes spezielles Bildschirmformat und die Kombination desselben Formats mit Darstellungen von Treffer-Datensätzen aus der Datenbank zur Definition eines Bildschirmbildes,
Fig. 9 eine konzeptionelle (Black Box-)Darstellung der Einrichtung für relationale Operatoren,
Fig. 10 und 11 detailliertere konzeptionelle Darstellungen von Teilen der Fig. 6,
Fig. 12 vereinfachte Ansichten von angewendeten Bildschirmformattypen,
Fig. 13 und 14 detailliertere Darstellungen bestimmter Bildschirmformate,
Fig. 15 eine detailliertere Darstellung eines Teils von Fig. 6,
Fig. 16 eine konzeptionelle Darstellung von Operationen, die das Datenverarbeitungssystem gemäß Fig. 4 mit Steuerung durch spezielle, im Programmspeicher gespeicherte Signale an Signalen im Datenspeicher des Systems durchführt,
Fig. 17 eine konzeptionelle Darstellung der Beziehungen zwischen bestimmten, beispielhaften Datenbank-Datensätzen,
Fig. 18, 19, 20 und 21 detaillierte Darstellungen bestimmter im Betrieb verwendeter Bildschirmformate,
Fig. 22 eine detailliertere Darstellung eines Teils von Fig. 6a,
Fig. 23 und 24 eine detaillierte Darstellung bestimmter weiterer im Betrieb verwendeter Bildschirmformate, und
Fig. 25 eine detailliertere Darstellung des WZFETCH- Bausteins in Fig. 7b.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Allgemeines über das Datenverarbeitungssystem

Das Datenverarbeitungssystem 10 gemäß Fig. 4 umfaßt einen Prozessor 12 mit einem Hauptspeicher 14. In Form einer oder mehrerer Platten ist ein Sekundärspeicher 16 vorgesehen. Der Hauptspeicher 14 und der Sekundärspeicher 16 bilden zusammen eine Speichervorrichtung 17. Die Beschreibung der vorliegenden Erfindung befaßt sich nicht mit Einzelheiten der Übertragung von Programmteile oder Daten darstellenden Signalen zwischen Haupt- und Sekundärspeicher, weil dies auf dem Gebiet der Verwaltung von Datenverarbeitungssystemen bekannt ist und die vorliegende Erfindung nicht hierzu gehört. Es wird angenommen, daß Signale in allen Teilen der Speichervorrichtung 17 für den Prozessor 12 verfügbar sind.
Ein oder mehrere solcher an den Prozessor 12 angeschlossener Endgeräte oder Konsolen weisen je einen Kathodenstrahlröhren- Bildschirm als Sichtgerät 18 und eine Tastatur als Signaleingabegerät 20 auf. Andere Signaleingabegeräte, z.B. Maus, Berührungsbildschirm, Sprachbetätigung u.dgl., werden von der Erfindung in Betracht gezogen. Wenn die Erfindung in einem großen Datenverarbeitungssystem ausgeführt wird, können im System zusätzliche Prozessoren, z.B. Ein-/Ausgabe-Prozessoren, vorhanden sein, und die Operationen, die hier als vom "Prozessor" ausgeführt bezeichnet sind, können tatsächlich auf solche Prozessoren verteilt sein. Solche Einzelheiten haben keinen Einfluß auf den Umfang der Erfindung.

Tastatur und Funktionstasten

Gemäß Fig. 5 sieht die Tastatur 20 die üblichen Tasten einer Schreibmaschinentastatur, die insgesamt mit 200 bezeichnet sind, und eine Leertaste 202 vor. Im oberen Abschnitt der Tastatur 20 sind 16 Tasten 204 in Vierergruppen angeordnet. Diese Tasten werden als PF-Tasten (Tasten mit programmierter Funktion) bezeichnet. Jeder ist eine Zahl zwischen 1 und 16 zugeordnet, und jede zeigt die ihr zugeordnete Zahl an. Unter Verwendung der Umschalttaste liefern diese Tasten 32 mögliche programmierte Funktionen. Außerdem weist die Tastatur 20 eine Eingabe-Taste 206 und einen Block Steuertasten 208 für eine Bildschirm-Schreibmarke auf. (Die Bildschirm-Schreibmarke wird üblicherweise "Cursor" genannt, jedoch wird dieser Ausdruck in der vorliegenden Beschreibung nicht für dieses Organ benutzt, um Verwechslungen mit dem "Cursor" zu vermeiden, der beim Abrufen mehrerer Datensätze aus einer relationalen Datenbank benutzt wird.)

Speichervorrichtung 17

In der nachstehenden Beschreibung wird die Übereinkunft beachtet, daß Wörter, die mit "@" beginnen, Namen von Zeigern zu Datenstrukturen oder zu Elementen in der Speichervorrichtung 17 sind; daß Wörter, die mit "$" beginnen, Namen von Parametern für bestimmte Programmteile sind; und daß Wörter, die mit "#" enden, Namen von Indexen für Elemente in Listen oder Mengen in Datenstrukturen sind. Elemente in einer Datenstruktur sind mit Wörtern benannt, die mit dem Namen der Datenstruktur (oder einer Abkürzung desselben) beginnen, gefolgt von einem Punkt: z.B. ist "qry.source" (Abfrage Quelle) ein Speicherelement (oder, in einigen Fällen, die in einem solchen Speicherelement gespeicherten Signal), mit dem Namen "source" (Quelle) und eingeschrieben in die Datenstruktur "QUERY" (Abfrage). Mit "DO" (Tue) beginnende Wörter sind Namen von Bausteinen im Abrufprogramm. Mit "WZ" beginnende Wörter sind Namen von externen Prozeduren, die vom Abrufprogramm aufgerufen werden.
Die Speichervorrichtung 17 des Datenverarbeitungssystems 10 wird von der Konzeption her als in einen Programmspeicher und einen Datenspeicher unterteilt betrachtet. Die (in Fig. 7 dargestellten) Inhalte des Programmspeichers werden zuerst kurz beschrieben; die Inhalte des (in Fig. 6 dargestellten) Datenspeichers werden beschrieben; jeder Baustein der Fig. 7 wird dann detaillierter beschrieben, und die Arbeitsweise des Datenverarbeitungssystems 10 hinsichtlich der Datenstrukturen und entsprechend den Bausteinen wird dann beschrieben.

Programmspeicher

In Fig. 7 sind die im Programmspeicher vorgesehenen Programmbausteine konzeptionell dargestellt, mit Angabe der in jeden Baustein eingegebenen signifikanten Parameter und der Aufrufe zwischen den Bausteinen. Außerdem sind in bestimmten Fällen die von den Bausteinen rückübertragenen Parameter angegeben.
Es leuchtet ohne weiteres ein, daß solche Bausteine und Parameter durch reale Signale dargestellt sind, und daß im Betrieb der Prozessor 12 aus dem Programmspeicher Signale kopiert, die zweckdienliche Programmteile darstellen, und solche Signale zur Steuerung des physikalischen Zustands von Hardwareorganen im System 10 benutzt, so daß die dargestellte Operation real ausgeführt wird. Es versteht sich in ähnlicher Weise, daß wenn ein Baustein als einen anderen Baustein "aufrufend" beschrieben wird, in Wirklichkeit das Datenverarbeitungssystem 10, das entsprechend dem ersten Baustein arbeitet, auf den zweiten Baustein zugreift und seine Signale kopiert, um eine weitere Operation entsprechend dem zweiten Baustein zu steuern.

Kurze Beschreibung des Programmspeichers

Betriebssystem

- Im Programmspeicherteil der Speichervorrichtung 17 sind Signale vorgesehen, die ein Betriebssystemprogramm 100 darstellen, das nicht Teil der Erfindung ist und beliebig ausgelegt sein kann, jedoch eine Zugriffsmethode 102 bieten muß, die zum Steuern des Datenverarbeitungssystems 10 für den Abruf von Treffer-Datensätzen aus der Datenbank in der Speichervorrichtung 17 geeignet ist, derart, daß Treffer- Datensätze in der Datenbank modifiziert oder entfernt und neue Datensätze zur Datenbank hinzugefügt werden können. Außerdem muß das Betriebssystem 100 ein Programm für die Steuerung des Sichtgerätes 18 und der Tastatur 20 aufweisen und muß insbesondere in der Lage sein, auf einen zweckdienlichen Befehl ("Schreibe/Lese Bildschirm") in einem Abrufprogramm durch Übersenden von Signalen an das Sichtgerät 18 zu antworten, die ein gespeichertes Bildschirmbild darstellen, Tastatureingangssignale zu empfangen, das gespeicherte Bildschirmbild in Übereinstimmung mit diesen zu modifizieren, und außerdem bestimmte Tastatureingangssignale zu speichern.

Abrufprogramm

- Der Programmspeicher 17 liefert ferner Signale, die ein "Abrufprogramm" darstellen, das Programmteile für den Betrieb des Datenverarbeitungssystems aufruft. Bei der hier beschriebenen und in Fig. 7, 7a und 7b dargestellten Ausführungsform heißt das Abrufprogramm PACE RUN, jedoch kann das Programm für die erfindungsgemäße Relationsoperator-Einrichtung von anderen Programmen zur Pflege relationaler Datenbänke aufgerufen werden. Einzelheiten eines solchen Programms gehören, außer im hier beschriebenen Umfang, nicht zur Erfindung.
Abrufprogramme können auch andere Programme sein, wenn in ihnen Einrichtungen vorgesehen sind, welche die Abruffunktion im allgemeinen in der für PACE RUN beschriebenen Weise ausführen. Insbesondere sind der DD Programmbaustein DD Definition 500 und der Programmbaustein Anwendungs-Konstruktion 508 gemäß Fig. 16 ebenfalls Abrufprogramme.
Die Datenstrukturen und die Bausteine, für die entsprechend Fig. 6a und 7a Speicherplätze zugewiesen sind, sind anhand Fig. 6 und 7 weiter beschrieben.
Die Informationen, die zu Beginn vom Benutzer des Endgerätes an das Abrufprogramm übermittelt werden müssen, umfassen eine Bezeichnung der Datenbank, auf die zugegriffen werden soll, eine Bezeichnung der Bildschirmdatei, auf die zugegriffen werden soll, und in einigen Fällen einen Cursor. (In anderen Fällen ist ein Cursor in einer dann erläuterten Weise bereitgestellt.) Wie es auf dem Gebiet der Verwaltung von relationalen Datenbänken einleuchtet, ist ein Cursor eine Anweisung (oder eine von der Implementierung abhängige Datenstruktur, die von einer solchen Anweisung abgeleitet ist), die eine Gruppe von aus der realen Datenbank abzurufenden Treffer-Datensätzen definiert und während des Vorgangs der Wiedergewinnung der Treffer-Datensätze innerhalb der Gruppe eine Position kennzeichnet.
Innerhalb des Abrufprogramms (PACE RUN) sind vorgesehen ein Baustein 103 DO OPEN DATABASE (ERÖFFNE DATENBANK), 105 DO OPEN SCREEN FILE (ERÖFFNE SCHIRMDATEI), 107 DSC, 108 DO QUERY (ABFRAGE), 112 DO PXI (PXI) und 126 DO UPDATE (AKTUALISIERUNG).
Ein Baustein 104 WZOPEN DATABASE (WZERÖFFNE DATENBANK) wird vom Baustein 103 aufgerufen, ein Baustein 106 WZOPEN SCREEN FILE (WZERÖFFNE SCHIRMDATEI) wird vom Baustein 105 aufgerufen, und ein Baustein 110 WZOPEN CURSOR (WZERÖFFNE CURSOR) wird vom Baustein 108 DO QUERY aufgerufen. Ein Baustein 114 WZPXI wird vom Baustein 112 DOPXI (TUEPXI) aufgerufen, und der Baustein 124 WZDISP wird vom Baustein 114 WZPXI aufgerufen. Die Bausteine 116 WZSCRLOD, 118 WZRETRIEVE (WZWIEDERGEWINNUNG) und 120 WZSCRIO werden vom Baustein 124 WZDISP angefordert. WZFORMS (WZFORMULARE) 122 wird von WZSCRIO 120 angefordert. Ferner wird ein Baustein 128 WZSELECT (WZANWAHL) vom Baustein 114 angefordert und fordert sowohl den Baustein 120 WTSCRIO als auch den Baustein 110 OPEN CURSOR an. Ein Baustein 126 DO UPDATE wird ebenfalls von DOPXI unter noch zu beschreibenden Bedingungen angefordert, und die Bausteine 115 WZINSERT (WZEINFÜGEN), WZMODIFY (WZMODIFIZIEREN) und WZDELETE (WZENTFERNEN) werden vom Baustein 126 aufgerufen. Einzelheiten der in Fig. 7 dargestellten Programmbausteine und der Arbeitsweise des Datenverarbeitungssystems 10 mit Steuerung durch sie darstellende Signale werden im Nachstehenden beschrieben.

Datenspeicherung

Gemäß Fig. 6 ist der Datenspeicherteil der Speichervorrichtung 17 konzeptionell unterteilt in die Datenbank-Speichervorrichtung, welche Signale liefert, die jene Treffer-Datensätze darstellen, welche eine oder mehr relationale Datenbänke bilden, und in den Arbeitsspeicher. Wie schon erläutert, sind die Einzelheiten der Datenbank-Speichervorrichtung für den Benutzer des Datenverarbeitungssystems 10 nicht sichtbar und werden nicht weiter beschrieben. Beim gezeigten Beispiel liefert der Arbeitsspeicher Signale, welche zwei Arten von Datenstrukturen darstellen: die Signale, die jene mit durchgezogenen Linien gezeichneten darstellen, sind in der Speichervorrichtung 17 gemäß meiner Erfindung vorgesehen, bevor der Betrieb gemäß meiner Erfindung beginnt; Signale, die Strukturen darstellen, welche mit gestrichelten Linien gezeichnet sind, werden in den Speicher verbracht oder es wird ihnen Speicherplatz zugeteilt während des Betriebs des Datenverarbeitungssystems 10 gemäß den in Fig. 7 dargestellten Programmteilen, wie nachstehend beschrieben wird.

Schirmdatei 151: PSCR, PSMP, POP und PDEF

Signale, die eine Schirmdatei-Datenstruktur 151 darstellen, sind in der Speichervorrichtung 17 vorgesehen und liefern Signale für vordefinierte Anzeigeformate. Die Schirmdatei 151 kann Teil des Benutzer(Abruf-)programms sein. Sie kann Anzeigeformatsignale für mehr als eine Zielrelation liefern; für die Zwecke dieser Beschreibung sei jedoch angenommen, daß sie ausgelegt ist für die Anzeige von Treffer-Datensätzen aus einer bestimmten Zielrelation (Grundtabelle oder Ansicht) innerhalb der benannten Datenbank. Es kann mehr als eine Schirmdatei vorgesehen sein, wenn auf mehr als eine Zielrelation zugegriffen werden soll.
Die Schirmdatei 151 umfaßt eine PDEF-Tabelle 153, die Speicherplatz für Signale bietet, die das anfängliche Schirmformat darstellen, auf das zugegriffen werden soll. Die Schirmdatei 151 umfaßt ferner eine Tabelle Prozedur Schirmdefinition (PSCR) 152; das Element @pscr ist ein Zeiger auf die PSCR 152. In der PSCR 152 sind Signale gespeichert, die sich auf eine Vielzahl Schirmformate beziehen, wobei die Signale für jeden Schirm durch den Schirmindex (screen#) lokalisiert werden. In der PSCR 152 sind für jeden Schirm Signale vorhanden, die den Schirmtyp (oder Betriebsartindikator) darstellen, ein Zeiger @scr zu einem (weiter unten im Zusammenhang mit Fig. 8, 12 und 13 zu beschreibenden) Schirmformat 166, und die Namen einer Prozedur Schirmmap (PSMP) und einer Prozedur Operatortabelle (POP), die dem Schirm zugeordnet sind. In der Schirmdatei 151 sind außerdem für jeden in PSCR 152 indizierten Schirm Signale vorgesehen, die ein Schirmformat 166, eine POP-Tabelle 156, eine PSMP 154 und einen Teil 155 der For-Display-List (Zur-Anzeige-Liste) darstellen.
Die POP-Tabelle 156 für ein bestimmtes Schirmformat 166 ist in Einzelheiten in Fig. 10 dargestellt. In der POP-Tabelle 156 sind für jedes Schirmformat 166 Signale vorgesehen, welche Informationen über die Operationen darstellen, die während der Anzeige eines solchen Schirms über die Tastatur 20 angewählt werden können; dazu gehören Operationen, die an der Ergebnisrelation auszuführen sind, welche während der Anzeige dieses Schirmformats interaktiv definiert wurde, sowie weitere Operationen, wie Rollen von Darstellungen von Treffer-Datensätzen und Übergänge auf andere Schirmformate. Die Tabelle ist nach dem noch zu beschreibenden, FPFkey genannten Wert eines Speicherelementes indiziert, und für jeden derartigen Wert ist eine "oper" genannte Datenstruktur vorgesehen, die über die Operation informiert, die mittels einer Funktionstaste auf der Tastatur 20 in einer noch zu erläuternden Weise anwählbar ist. "oper" enthält den "oper"-Namen (an das Abrufprogramm zurückzuschreibender Text), die auszuführende(n) Aktion(en), und ggfs. der Bildschirmname des für die Aktion zu verwendenden Bildschirmformats. In der POP-Tabelle für den Bildschirm LISTE ist ein "oper" für jede der Operationen Hinzufügen, Modifizieren, Entfernen und Zurück vorhanden. Andere Bildschirme können POP-Tabellen haben, die "oper" für mehr oder weniger Operationen enthalten. Bei der Auslegung der POP-Tabelle können auch andere Operationen vorgesehen werden.
Die Prozedur Bildschirmmap (PSMP) 154 für ein bestimmtes Bildschirmformat 166 enthält Signale, die eine Liste der Namen der Betrachtungsfelder darstellen, welche an der Anzeige erscheinen sollen, wenn das Bildschirmformat zum Anzeigen von Treffer-Datensätzen aus der Datenbank benutzt werden soll. Diese Informationen werden beim Ausfüllen der Zur-Anzeige- Liste 155/174 verwendet. Ferner bietet PSMP 154 für ein bestimmtes Bildschirmformat 166 ein Bildschirmbegrenzungssignal, das die Anzahl der Treffer-Datensätze definiert, die zur gleichen Zeit auf einem solchen Bildschirm angezeigt werden können.

Bildschirmformate

Gemäß Fig. 12 kann jede Bildschirmdatei Signale enthalten, die bis zu sechs Bildschirmformate darstellen (die in Fig. 6 zusammen als Formate 166 dargestellt sind). Es gibt jedoch nur zwei Grundtypen. Die Formate sind in Fig. 12 schematisch dargestellt, so daß die Unterschiede zwischen den beiden Typen bequem erfaßt werden können. Das Bildschirmformat LIST (LISTE) 400 ist ausgelegt für Darstellungen vieler Treffer- Datensätze aus der Datenbank-Zielrelation und bietet daher Platz für die in Spalten angeordneten Felder solcher Treffer. Es können weniger als alle möglichen Felder angezeigt werden. Das Bildschirmformat DISPLAY (ANZEIGE) 402 ist ausgelegt für die Darstellung eines einzelnen Treffer-Datensatzes aus der Datenbank-Zielrelation und kann mehr Felder dieses Treffer- Datensatzes zeigen. Die Formate der Bildschirme SELECT (AN- WAHL) (404) und ADD (HINZUFÜGEN), MODIFY (MODIFIZIEREN), DELETE (ENTFERNEN) (406) sind im Grunde den Formaten des Bildschirms DISPLAY ähnlich, insoweit Darstellungen der Felder eines einzelnen Datensatzes oder der Namen der Felder eines einzelnen Datensatzes gezeigt werden, wobei Unterschiede noch zu beschreiben sind.

Bildschirmformat LIST

Das Bildschirmformat LIST 400 ist in Fig. 8a und 8b in Einzelheiten dargestellt.
Fig. 8a zeigt das Bildschirmformat LIST 400 in der Form, in der es anfänglich in der Bildschirmdatei 151 vorhanden ist. Vorgesehen ist der Titel 300 des Bildschirms, zusammen mit dem Namen der Zielrelation bei 310 und einem feststehenden Text bei 302. Unter dem feststehenden Text stehen Spaltenüberschriften und Leerräume für die Anzeige von Treffer-Datensätzen. Eine Linie 304 unterteilt den Bildschirm in obere und untere Abschnitte 306 und 308. Unter der Linie 304 werden im unteren Abschnitt 308 die Zahlen spezieller Funktionstasten unter den 16 Tasten 204 der Tastatur 20 (Fig. 5) angezeigt, zusammen mit dem Namen der ENTER(EINGABE)-Taste 206 der Tastatur 20. Den Tastenbezeichnungen zugeordnet sind die Namen anwählbarer Operationen. Im unteren Abschnitt 308 des Bildschirmformats sind nicht alle der 16 möglichen Funktionstasten angegeben; der Grund hierfür ist, daß während der Anzeige des Bildschirms LIST nur eine kleinere Anzahl Operationen anwählbar ist. Unter den angegebenen befindet sich die Funktionstaste 204-16: Return (Zurück). Die Betätigung der Taste 204-4: Prev (Vorh.) bewirkt die erneute Anzeige, unter weiterer Benutzung des gegenwärtigen Formats, eines zuvor angezeigten Bildschirminhalts; die Betätigung der Taste 204-4 mit der Umschalttaste bewirkt die Anzeige des ersten Bildschirminhalts von Treffer-Datensätzen in der Liste. In ähnlicher Weise bewirkt die Betätigung der Taste 204-5 die Anzeige des nächsten Bildschirminhalts, und die Betätigung der Taste 205-5 mit der Umschalttaste bewirkt die Anzeige des letzten Bildschirminhalts der Treffer. Die Tasten 204-4 und 204-5 rollen somit den Abschnitt 306. Die Betätigung der Taste 204-7 bewirkt die Anzeige des (nachstehend beschriebenen) Bildschirmformats SELECT (ANWAHL). Die Betätigung der Tasten 204-8 und 204-9 bewirkt die Anzeige von einem oder mehreren Treffer-Datensätzen, die der Benutzer durch Bewegen der Bildschirm-Schreibmarke ausgewählt hat, in den noch zu beschreibenden Bildschirmformaten DELETE (ENTFERNEN) und MODIFY (MODIFIZIEREN). (Wenn mehr als ein Treffer-Datensatz angewählt worden ist, werden sie nacheinander auf dem angewählten Bildschirm angezeigt.) Die Betätigung der Taste 204-6 bewirkt die Anzeige des (weiter unten beschriebenen) Bildschirmformats ADD (HINZUFÜGEN). Die Betätigung der ENTER-Taste 206 (auf der Tastatur 20, Fig. 5) bewirkt eine Umschaltung auf das Bildschirmformat DISPLAY, in dem ein bestimmter Treffer-Datensatz dargestellt ist.
Die angezeigten Tastenidentifizierer, einschließlich der Funktionstasten-Nummern und der Tastennamen, mit den Namen der entsprechenden Operationen, bieten Darstellungen einer Vielzahl von anwählbaren Operationen, einschließlich solcher Operationen, die an Elementen der Ergebnisrelation auszuführen sind, welche, wie noch beschrieben wird, von der Relationsoperator-Einrichtung bereitzustellen ist.
In Fig. 8b sind unter den Spaltenüberschriften die abgerufenen Treffer-Datensätze dargestellt.

Weitere Formate

In Fig. 13 und 14 sind die übrigen Bildschirmformate mit größeren Einzelheiten als in Fig. 12 dargestellt.
Fig. 13 zeigt das Bildschirmformat DISPLAY (ANZEIGE) 402, mit Darstellungen der Felder eines einzelnen Treffer-Datensatzes. Dieses Bildschirmformat wird nach Betätigung der ENTER-Taste 206 (auf der Tastatur 20, Fig. 5) gezeigt, während das Format LIST angezeigt ist. Die Namen der Felder im Datensatz sind links von den Werten der Felder angegeben. Anwählbare Operationen sind im unteren Abschnitt 308 des Formats angezeigt. Die Betätigung der Funktionstaste 204-16 (Return) bewirkt einen Rücksprung zu einer Ansicht des Bildschirmformats LIST. Die Betätigung der Funktionstasten 204-6 (Add), 204-8 (Delete) und 204-9 (Modify) ermöglicht es dem Benutzer, denselben Treffer-Datensatz, der im Bildschirmformat DISPLAY angezeigt ist, in einem der Formate 406 anzusehen, so daß die angegebene Operation durchgeführt werden kann.
Das Bildschirmformat SELECT (ANWAHL) 404, das während der Anzeige des LIST-Formats durch Betätigen der Funktionstaste 204-7 gezeigt wird, ist von ähnlicher Anordnung wie das Format 402, jedoch sind die Werte einiger oder aller Felder durch Fragezeichen und Leerstellen dargestellt. Dieser Bildschirm ermöglicht es dem Benutzer, die Bildschirm-Schreibmarke auf ein bestimmtes Feld (offenes Element) zu bringen und in das Feld einen kennzeichnenden Wert einzugeben zu dem Zweck, aus der Ziel-Relation (die bei 310 benannt ist) in der Datenbank Treffer-Datensätze abzurufen, die diesen Wert im angewählten Feld aufweisen. Es kann mehr als ein Feld so gekennzeichnet werden.
Fig. 14 zeigt die Bildschirmformate Update (Aktualisieren) 406. Das Bildschirmformat ADD 406-1 ist dem Bildschirmformat SELECT ähnlich, aber der Benutzer muß in diesem Fall alle Felder ausfüllen, die zur Bildung eines neuen, der Ziel-Relation (bei 310 benannt) der Datenbank hinzuzufügenden Treffer- Datensatzes notwendig sind. Das Bildschirmformat MODIFY 406-2 ist dem Format DISPLAY 402 ähnlich, jedoch sind die Darstellungen der Werte der Felder hervorgehoben (oder auf andere Weise von den Attributnamen verschieden) dargestellt, um anzuzeigen, daß der Benutzer diese Werte modifizieren kann, zu dem Zweck, in der Datenbank den auf dem Bildschirm dargestellten Treffer-Datensatz zu ändern. Das Bildschirmformat DELETE 406-3 ist ebenfalls dem Format DISPLAY 402 ähnlich, jedoch umfassen die anwählbaren Operationen "Delete" (Entfernen) oder "Skip record" (Überspringe Datensatz.

Cursor 158

Mit erneutem Bezug auf Fig. 6: Einen Cursor darstellende Signale sind bei 158 gespeichert, mit einem Zeiger @cursor. Der im Speicherelement 158 dargestellte spezielle Cursor kann entweder vom Abrufprogramm bereitgestellt oder von einem anfänglichen Cursor in einer noch zu beschreibenden Weise abgeleitet oder auf noch andere Weise definiert sein. Wie weiter oben angegeben, ist ein Cursor eine Anweisung (oder eine von einer solchen Anweisung abgeleitete, von der Implementierung abhängige Datenstruktur), die eine aus einer Ziel-Relation in der Datenbank abzurufende Gruppe von Datensätzen definiert und innerhalb der Gruppe während des Vorgangs der Wiedergewinnung der Datensätze eine Position kennzeichnet.

Weitere Datenstrukturen

Weiter mit Bezug auf Fig. 6: Speicherplätze für die Datenstrukturen Task Common Area Gemeinsamer Aufgabenbereich (TCOM) 160, QUERY (Abfrage) 162, Seen-List (Gesehen Liste) 176, ATAB 172, For-Display-List (Teil Zwei) 174, DBUSER 173 und FOR 164 werden, wie noch beschrieben wird, während des Betriebes des Datenverarbeitungssystems 10 zugeteilt. Außerdem wird, wie noch beschrieben wird, Speicherplatz für einen System-Pufferspeicher 168 während des Betriebs zugewiesen.

Beschreibung der Programmbausteine und der Wechselwirkung mit der Speichervorrichtung

WZOPEN DATABASE 104 (WZEröffnung Datenbank)

Das Datenverarbeitungssystem 10 arbeitet mit Steuerung durch Signale, die das Programmelement WZOPEN DATABASE 104, das über das Abrufprogramm aufgerufen wird, in bezug auf eine spezielle Datenbank (durch den Parameter $database benannt) darstellen. Die Informationen darüber, auf welche Datenbank letzten Endes zugegriffen werden soll, kommen vom Benutzer des Endgerätes des Datenverarbeitungssystems. Bei Arbeiten nach dem Baustein 104 weist das Datenverarbeitungssystem 10 Speicherplätze in der Speichervorrichtung 17 der Datenstruktur DBUSER 173 zu, die Zeiger auf Listen von Deskriptoren von Datenbank-Datensätzen, Dateien, Beziehungen und Ansichten und weitere für die eröffnete Datenbank einschlägige Daten darstellende Signale liefert. Derartige Deskriptoren liefern Signale für die Definition der konzeptionellen Datensätze der Ebene 30 (Fig. 1) in Form der gespeicherten oder internen Treffer-Datensätze der Ebene 32. Das Datenverarbeitungssystem 10 weist dann in der Speichervorrichtung 17 Speicherplätze für Signale zu, welche die Struktur Task Common Area (TCOM) 160 darstellen, der Speicherplätze für verschiedene, in der nachfolgenden Operation zu benutzende Zeiger, insbesondere für den Zeiger @for-display-list, der auf die For-Display- List (Teil Zwei) 174 zeigt, und den Zeiger @dbuser enthält, der auf die Datenstruktur DBUSER 173 zeigt.
Von Vorstehendem abgesehen, ist die Prozedur der Eröffnung einer Datenbank, damit aus ihr Treffer-Datensätze abgerufen werden können, der Fachwelt auf dem Gebiet der Datenbankverwaltung bekannt und wird hier nicht speziell beschrieben.

WZOPEN SCREEN FILE 106 (WZEröffnung Bildschirmdatei)

Das Datenverarbeitungssystem 10 arbeitet nach Signalen, welche das Programmelement WZOPEN SCREEN FILE 106 darstellen, das vom Abrufprogramm aufgerufen wurde, in bezug auf den Parameter $screen-file (der letzten Endes vom Benutzer geliefert wird). Der Parameter $screen-file benennt die spezielle Bildschirmdatei 151, auf die zugegriffen werden soll. Sind im Hauptspeicher 14 keine Signale vorhanden, welche die erwähnte spezielle Bildschirmdatei darstellen, lädt das Datenverarbeitungssystem 10 PSCR 152 darstellende Signale aus dem Sekundärspeicher 16, zu diesem Zeitpunkt mit Steuerung durch den Baustein WZOPEN SCREEN FILE 106. Diese Operation ist nicht Teil der Erfindung.

DO DSC 107 (Tue DSC)

Im Betrieb nach Signalen, die den Baustein DO DSC 107 (Tue DSC) im Abrufprogramm darstellen, definiert das Datenverarbeitungssystem 10 einen Anfangscursor und bringt ihn darstellende Signale in die Datenstruktur CURSOR 158 in der Speichervorrichtung 17. Der Cursor wird auf ein Ziel definiert, das wenigstens eine der Relationen in der benannten Datenbank aufweist. Das Ziel kann entweder eine Grundtabelle (die in der Speichervorrichtung durch eine gesonderte gespeicherte Datei dargestellt ist) oder eine Ansicht sein (die eine Tabelle[n-Relation] ist, die nicht selbständig existiert, sondern von einer oder mehreren Grundtabellen abgeleitet ist).

DO OUERY 108 (Abfrage)

Der Baustein DO QUERY 108 im Abrufprogramm dient für die Zwecke der vorliegenden Erfindung nur zur Steuerung des Datenverarbeitungssystems 10 beim Aufrufen des Bausteins WZOPEN CURSOR 110 und des Bausteins DOPXI 112.

OPEN CURSOR (Eröf fne Cursor)

Der Baustein WZOPEN CURSOR (@cursor, $qid) 110 wird zum Steuern des Datenverarbeitunssystems 10 beim Eröffnen des Cursors verwendet, der durch Signale in der Datenstruktur 158 definiert ist. Die Prozedur der Eröffnung eines Cursors zum Zwekke des Abrufs mehrerer, durch den Cursor definierter Treffer- Datensätze ist in der Fachwelt auf dem Gebiet der Datenbankverwaltung bekannt und wird hier nicht in Einzelheiten beschrieben.
Bei der hier beschriebenen speziellen Ausführungsform weist das Datenverarbeitungssystem 10 bei Steuerung durch den Baustein WZOPEN CURSOR 110 darstellende Signale Speicherplätze innerhalb der Speichervorrichtung 17 der Datenstruktur QUERY 162 zu, entsprechend dem durch @cursor adressierten Cursor. Eine einzelne Datenstruktur QUERY entspricht einem einzelnen Cursor. Auf die Datenstruktur QUERY 162 verweist @qry; er enthält Signale, die den Zeiger @sysbuf darstellen, der auf den Systempufferspeicher 168 hinweist, den Zeiger @pxiscr, der auf das Bildschirmformat zeigt, das beim Arbeiten nach meinem Relationsoperator zu benutzen ist, oder auf den zuletzt benutzten Bildschirm (um Rücksprünge zu ermöglichen), den Zeiger @seen-list, der auf Seen-List 176 (noch zu beschreiben) zeigt, und andere Zeiger. Ferner speichert die Datenstruktur QUERY 162 ein "oper" genanntes Datenelement, einen Listen-Zwischenspeicher genannten Zwischenspeicher und das Datenelement "source", die alle nachstehend beschrieben werden.
Mit Steuerung durch den Baustein WZOPEN CURSOR 110 schreibt das Datenverarbeitungssystem 10 den Identifizierer "qid" für QUERY zurück. Im weiteren Betrieb mit Steuerung durch den Baustein WZOPEN CURSOR 110 wählt das Datenverarbeitungssystem 10 eine Zugriffsstrategie aus, die beim Abrufen physischer Treffer-Datensätze aus der Datenbank 150, wie durch den Cursor definiert, zu benutzen ist. Der Vorgang der Auswahl einer Zugriffsstrategie ist der Fachwelt auf dem Gebiet der Datenbankverwaltung bekannt und wird hier nicht beschrieben.

DO PXI 112 (Tue PXI)

Im Betrieb mit Steuerung durch den Baustein DO QUERY 108 darstellende Signale ruft das Datenverarbeitungssystem 10 den Baustein DOPXI (screen#) 112 auf und nach Ausführung hier nicht zur Sache gehöriger Operationen den Baustein WZPXI ($screen-file, screen#, $qid) 114. "$Screen-file" ist ein Parameter zur Benennung der Bildschirmdatei, auf die Bezug zu nehmen ist; "screen#" ist ein Index zum speziellen Bildschirmformat innerhalb der Bildschirmdatei. Wie in Verbindung mit der Bildschirmdatei 151 angegeben, wird der Name des zu adressierenden Anfangsbildschirms durch das Abrufprogramm geliefert, und den Namen darstellende Signale sind in "initial-screen" (Anfangsbildschirm) in PDEF 153 der Bildschirmdatei 151 gespeichert. Die Namen von in nachfolgenden Operationen zu adressierenden Bildschirmen werden in einer nachstehend beschriebenen Weise bereitgestellt. Wie oben angegeben, ist "qid" der Identifizierer von QUERY. Die Operation entsprechend WZPXI wird nachstehend beschrieben; sie schreibt einen Wert zurück, indem sie diesen Wert darstellende Signale in die Datenstruktur ATAB 172 (Fig. 6) bringt. Dieser Wert stellt eine der Operationen Hinzufügen, Modifizieren, Entfernen oder Zurück dar; weitere Operationen können ebenfalls vorgesehen werden. Außerdem kann WZPXI die Zeichen von "opername" darstellende Signale in das Speicherelement 170 zurückschreiben, auf den durch $oper-name hingewiesen wird; auf Wunsch wird dieser Zeiger durch das Abrufprogramm geliefert. Die Werte in ATAB 172 oder/und die den "oper-name" bildenden Zeichen stehen dem Abrufprogramm für weitere Tests zur Verfügung; sie können unter verschiedenen Umständen benutzt werden, was hier nicht zur Sache gehört.
Nach Rücksprung aus WZPXI testet das Datenverarbeitungssystem 10 mit Steuerung durch DOPXI die Signale, die den Wert darstellen, der von WZPXI in die Datenstruktur ATAB 172 zurückgeschrieben wurde. Für die Aktionen Hinzufügen, Modifizieren oder Entfernen ruft das Datenverarbeitungssystem 10 mit Steuerung durch DOPXI entsprechende Programmbausteine auf (dargestellt durch den Baustein DO UPDATE (Aktualisieren) 126 und den Baustein WZINSERT, DELETE, MODIFY 115 (Einfügen, Entfernen, Modifizieren (der durch den Baustein 126 aufgerufen wird)), um die angegebene Operation auszuführen.

WZPXI 114

Mit Steuerung durch den Baustein WZPXI ($Screen-file, screen#, $qid) 114 testet das Datenverarbeitungssystem 10 die Signale, welche den Bildschirmtyp (Betriebsart-Indikator) des Bildschirms darstellen, auf den durch "initial screen" in PDEF 152 hingewiesen wird (für die erste Iteration von WZPXI), oder den Bildschirmtyp des Bildschirms, auf den (für nachfolgende Iterationen) durch qry.@pxiscr hingewiesen wird.
Für den Augenblick wird die Möglichkeit außer Acht gelassen, daß der Bildschirmtyp SELECT (Auswahl) ist (er wird weiter unten beschrieben). Wenn der Bildschirmtyp entweder LIST (Liste) oder DISPLAY (Anzeige) ist, wird der Baustein WZDISP 124 aufgerufen. Die Operation entsprechend dem Baustein WZDISP 124 wird nachstehend beschrieben. Bei dieser Operation werden Darstellungen von einem oder mehreren, durch den Cursor definierten Treffer-Datensätzen entweder im Bildschirmformat DISPLAY (ein Treffer) oder LIST (mehrere Treffer) angezeigt. Wenn eine solche Operation beendet ist, wurden Signale in gry.oper gebracht, die eine durch Betätigen einer Funktionstaste durch den Endgerätbenutzer ausgewählte Operation darstellen.
Wenn das Datenverarbeitungssystem 10 aus dem Baustein WZDISP 124 zurückspringt, testet es im weiteren Betrieb entsprechend dem Baustein WZPXI 114 die im Speicherelement qry.action (in qry.oper) gespeicherten Signale. Bestimmte Aktionen (einschließlich eines nachstehend beschriebenen Übergangs auf einen DISPLAY-Bildschirm) können durch das Datenverarbeitungssystem 10 im weiteren Betrieb entsprechend dem Baustein WZPXI 114 ausgeführt werden; eine solche Operation umfaßt das Rücksetzen von qry.@pxiscr und qry.pxiscr# zur Verfolgung des Übergangs. Andernfalls kopiert das weiter durch den Baustein WZPXI 114 gesteuerte Datenverarbeitungssystem 10 Signale, welche qry.oper-name (in qry.oper) aus der Datenstruktur QUERY 162 in den Speicherplatz 170, auf den durch $oper-name verwiesen wird, bringt die Aktion darstellende Signale in ATAB 172, setzt qry.source, um anzugeben, ob Auswahl durch den Bildschirm DISPLAY, durch den Bildschirm LIST vom Cursor, durch den Bildschirm LIST aufgrund der markierten Bildschirmliste, oder durch den Bildschirm SELECT. Die durch Signale in $oper-name und ATAB 172 dargestellte Operation kann Hinzufügen, Modifizieren, Entfernen oder Zurück sein. (Die Möglichkeit, daß die Operation Auswahl ist, wird nachstehend beschrieben.)

WZDISP 124

Im Betrieb entsprechend dem Baustein WZDISP 124 hinsichtlich der Parameter $qid und $starting-lr# (lr# = Auflisten Datensatz-Nr, gespeichert in qry.List-Buffer; starting-lr# kommt aus WZPXI, basierend auf dem Bildschirmzustand), ruft das Datenverarbeitungssystem 10 den Baustein WZSCRLOD ($qid, @scr) 116 auf, um, wie noch beschrieben wird, die Zur-Anzeige-Liste zu vervollständigen, und ruft dann den Baustein WZ- RETRIEVE (qry. source) 118 auf, um einen anzuzeigenden Treffer-Datensatz auf zurufen. Die Operation entsprechend WZRETRIEVE (Wiedergewinnen) wird weiter unten beschrieben. Beim Bildschirm LIST (Liste) wird WZRETRIEVE mehrmals aufgerufen; Treffer-Datensätze werden einzeln abgerufen, bis entweder ein voller Bildschirm wiedergewonnen worden ist (definiert durch das Bildschirmbegrenzungssignal in PSMP 154 für den Bildschirm), oder keine Treffer-Datensätze mehr zur Wiedergewinnung vorhanden sind, das heißt, alle durch den Cursor definierten Treffer-Datensätze wurden abgerufen. Beim Abrufen jedes Treffer-Datensatzes werden seinen Schlüssel darstellende Signale in Seen-List 176 geschrieben.
Nach Rücksprung aus dem Baustein WZRETRIEVE 118 und im weiteren Betrieb entsprechend dem Baustein WZDISP 124, ruft das Datenverarbeitungssystem 10 den Baustein WZSCRIO 120 auf, um die Anzeige von Darstellungen der abgerufenen Treffer-Datensätze zu bewirken. Die Operation entsprechend WZSCRIO wird weiter unten beschrieben. Nach Rücksprung aus dem Baustein WZSCRIO 120 testet das Datenverarbeitungssystem 10 im weiteren Betrieb entsprechend dem Baustein WZDISP 124 die in qry. action (in qry.oper) gespeicherten Signale.
Ist die Aktion ein Übergang vom DISPLAY- zum LIST-Format (angewählt durch Betätigung der Funktionstaste 204-16: Zurück im DISPLAY-Format 402, Fig. 13) oder vom LIST- zum DISPLAY-Format (angewählt durch Betätigung der ENTER-Taste 206 der Tastatur 20, LIST-Format, Fig. 8), rücksetzt das Datenverarbeitungssystem 10 qry.@pxiscr und @scr, um auf den neuen Bildschirm zu zeigen; der Index qry.pxiscr# wird zur Verfolgung der Übergänge zwischen Bildschirmformaten benutzt. Bei einer solchen Übergangsoperation, im weiteren Betrieb entsprechend WZDISP und den daraus abgerufenen Bausteinen, zeigt das Datenverarbeitungssystem 10 entsprechend dem Bildschirmtyp des von den Rücksetzzeigern angegebenen Bildschirmformats Darstellungen des (der) abgerufenen Treffer-Datensatzes (-Datensätze) im geeigneten Bildschirmformat an.
Ist die Aktion in qry.action Next (Nächstes), Previous (Vorheriges), First (Erstes) oder Last (Letztes), wird die angegebene Rolloperation vom Datenverarbeitungssystem 10 im Betrieb entsprechend dem Baustein WZDISP 124 ausgeführt. Next oder Previous bewirkt, daß das nächste oder das vorherige Bild mit Darstellungen der Treffer-Datensätze angezeigt wird; First oder Last bewirkt, daß das erste oder das letzte Bild angezeigt wird. Soll ein vorheriges Bild angezeigt werden, werden die Treffer-Datensätze unter Benutzung der in Seen- List 176 gespeicherten Schlüssel gesucht; andernfalls müssen Treffer-Datensätze unter Benutzung der Datenstruktur QUERY 162 abgerufen werden. Diese Operationen bewirken das Rollen der angezeigten Liste von Treffer-Datensätzen.
Es leuchtet ein, daß er Benutzer aufeinanderfolgende Roll - oder Übergangsoperationen zwischen den Bildschirmformaten LIST und DISPLAY unbegrenzt wählen kann, ohne ein Rückspringen des Datenverarbeitungssystems 10 aus dem Baustein WZDISP 124 zu verursachen. Die Funktionstaste Return (Zurück) bewirkt ein Rückspringen auf das zuvor angezeigte Bildschirmformat, soweit vorhanden (nach Angabe durch qry.pxiscr#) oder sonst ein Rückspringen auf das Abrufprogramm.

WZSCRLOD 116

Im Betrieb entsprechend dem Baustein WZSCRLOD ($qid, @scr) 116 greift das Datenverarbeitungssystem 10 auf die geeignete Tabelle POP 156 und auf PSMP 154 für das spezielle, durch @scr adressierte Bildschirmformat 166 zu und füllt den rechten Teil der For-Display-List aus. Gemäß Fig. 15 wird der linke Teil der For-Display-List durch die Datenstruktur 155 in der Bildschirmdatei 151 bereitgestellt; für jedes auf dem Bildschirm anzuzeigende Ansichtsfeld werden der Ort (Zeile und Spalte auf dem Bildschirm), die Länge und andere zweckdienliche Informationen bereitgestellt. Der rechte Teil wird durch die Datenstruktur 174 bereitgestellt; für jedes Ansichtsfeld werden der Speicherplatz, die Länge, der Typ und weitere zweckdienliche Informationen über den Treffer-Datensatz bereitgestellt. Der Teil 174 liefert somit die Adressen der anzuzeigenden Treffer-Datensätze; bei einem Bildschirmformat LIST verweisen diese Adressen auf den qry.List-Buffer (Listenpufferspeicher), wogegen bei einem Bildschirmformat DISPLAY die Adressen zum Systempufferspeicher 168 zeigen. Die Anzeige von Darstellungen von Attributnamen als Überschriften 303, von Ansichtsnamen als Ansichtstitel 310, die geeigneten Funktionstasten 204 für die während der Anzeige des speziellen Bildschirmformats 166 wählbaren Operationen und weiterer Informationen wird durch das Bildschirmformat 166 geliefert.

WZRETRIEVE 118

Im Betrieb entsprechend dem Baustein WZRETRIEVE (qry.source) 118 ruft das Datenverarbeitungssystem 10 unter Berücksichtigung der Signale in qry.source die Zugriffsmethode 102 des Betriebssystems 100 auf. Die Zugriffsmethode 102 reagiert auf Signale, die das Datenverarbeitungssystem 10 im Betrieb entsprechend dem Baustein WZRETRIEVE 118 liefert, derart, daß das Datenverarbeitungssystem 10 aus dem Ziel innerhalb der benannten Datenbank 150 einen durch den Cursor spezifizierten Treffer-Datensatz abruft und den abgerufenen Treffer-Datensatz darstellende Signale im Systempufferspeicher 168 speichert.
Weil bei dem Bildschirm LIST (der eine Vielzahl von Treffer- Datensätzen anzeigt) der Systempufferspeicher 168 nur einen Treffer-Datensatz hält, werden die abgerufenen Treffer darstellende Signale durch das entsprechend dem Baustein WZDISP 124 arbeitende Datenverarbeitungssystem 10 in den qry.List- Buffer (Listenpufferspeicher) kopiert. WZRETRIEVE wird mehrmals ausgeführt, bis keine vom Cursor definierte Treffer- Datensätze mehr vorhanden sind, oder bis genügend Treffer- Datensätze abgerufen worden sind, um den Bildschirm zu füllen, entsprechend der Bestimmung durch den Bildschirmbegrenzungsindikator in PSMP 154.

WZSCRIO

Im Betrieb entsprechend dem Baustein WZSCRIO (@qry = $qid, @scr) 120 ruft das Datenverarbeitungssystem 10 den Baustein WZFORMS (@for-display-list) 122 auf, um die Treffer-Datensätze, auf welche die For-Display-List (Fig. 15) zeigt, für die Anzeige gegenüber dem Benutzer mit dem Bildschirmformat zu kombinieren, auf das @scr zeigt. Die Operation des Datenverarbeitungssystems 10 entsprechend WZFORMS (Formulare) wird weiter unten beschrieben. Wenn eine solche Operation beendet ist, sind Signale in for.fpf-key gebracht worden und das gespeicherte Bildschirmbild kann entsprechend vom Benutzer eingegebener Signale modifiziert worden sein. Nach Rücksprung von WZFORMS benutzt das weiter entsprechend WZSCRIO arbeitende Datenverarbeitungssystem 10 die in for.fpf-key gespeicherten Signale (Beschreibung weiter unten) als Index zu den Signalen in der Datenstruktur POP-Tabelle 156 für den angezeigten Bildschirm, und kopiert daraus Signale, die das Element "oper" darstellen, das "oper-name" und "action" enthält, entsprechend der Funktionstasten-Nummer, in das Speicherelement qry.oper in der Datenstruktur QUERY 162.
Die in qry.oper gespeicherten Signale sind Ausgangssignale der Relationsoperator-Einrichtung und sind repräsentativ für die vom Benutzer gewählte Operation.
Im weiteren Betrieb entsprechend dem Baustein WZSCRIO 120 modifiziert das Datenverarbeitungssystem 10 die Seen-List 176 durch Markieren von Datensätzen (durch Setzen eines Flags in der "Markierung"-Spalte der Liste gemäß Fig. 11), die durch den Benutzer des Endgeräts, wie nachstehend beschrieben, bestimmt worden sind. Das Verarbeitungssystem 10 springt vom Baustein WZSCRIO 120 auf den Baustein WZDISPO 124 zurück.

WZFORMS

Mit Steuerung durch den Baustein WZFORMS (@for-display-list, @scr) 122 benutzt das Datenverarbeitungssystem 10 die die Adressen in der For-Display-List 155/174 darstellenden Signale, um die Signale für die Treffer-Datensätze aus dem adressierten Pufferspeicher zu erhalten und sie mit den Signalen des vordefinierten Anzeigeformats der Bildschirmdatei 151 zu kombinieren, um das Bildschirmformat 166 zu modifizieren und dadurch ein sich daraus ergebendes gespeichertes Schirmbild zu definieren. Für den Bildschirm LIST werden die Treffer-Datensatz-Signale aus dem qry.List-Buffer genommen; für den Bildschirm DISPLAY wird ein einzelner Treffer-Datensatz aus dem Systempufferspeicher 168 genommen.
Mit weiterer Steuerung durch WZFORMS 122 ruft das Datenverarbeitungssystem das Betriebssystem-Programm 100 auf und arbeitet entsprechend den darin enthaltenen Anzeigesteuersignalen zur Steuerung des Sichtgerätes 18 in der Weise, daß eine Darstellung des in 166 gespeicherten, sich ergebenden Bildschirmbildes angezeigt wird. Während dieser Anzeige aktiviert das Datenverarbeitungssystem ferner die Tastatur 20. Der Benutzer der Konsole oder des Endgerätes kann die Tastatur 20 zur Eingabe von Signalen benutzen.
Wenn auf dem Bildschirm LIST die Bildschirm-Schreibmarke vom Benutzer neben die Darstellung eines speziellen Treffer-Datensatzes positioniert und eine Funktionstaste 204 betätigt wird, wird dieser Treffer-Datensatz implizit als bestimmt angenommen. Alternativ kann der Benutzer neben einem oder mehreren Treffer-Datensätzen ein "X" oder ein anderes Zeichen zur Bestimmung derselben schreiben.
Die vom Benutzer eingegebenen Tastatursignale werden vom Datenverarbeitungssystem im Betrieb entsprechend dem Betriebssystem 100 interpretiert, um das gespeicherte Bildschirmbild zu modifizieren. Ein der betätigten Funktionstaste entsprechendes Signal wird ebenfalls gespeichert. Nach Rücksprung von WZFORMS und mit Steuerung durch WZSCRIO und WZDISP interpretiert das Datenverarbeitungssystem 10 die vom Benutzer eingegebenen Tastatursignale als Aufzählungssignale, die bestimmte der abgerufenen Treffer-Datensätze, deren Darstellungen angezeigt werden, aufzählen, und als Operationswahlsignale, die aus der Vielzahl von wählbaren Operationen eine auswählen. Auswählbare Operationen werden für jedes Bildschirmformat definiert, enthalten aber stets den Rücksprung.
Im weiteren Betrieb entsprechend dem Baustein WZFORMS 122 kopiert das Datenverarbeitungssystem die gespeicherten, die Funktionstasten-Nummer darstellenden Signale in das Datenspeicherelement for.fpf-key in der Datenstruktur FOR 164.
Sobald die Funktionstasten-Signale nach for.fpf-key kopiert worden sind, springt das Datenverarbeitungssystem vom Baustein WZFORMS 122 auf den Baustein WZSCRIO 120 zurück.

Arbeitsweise

Im Betrieb entsprechend den Signalen, welche die beschriebenen Bausteine und Datenstrukturen darstellen, wählt der Benutzer des Endgerätes vom Datenverarbeitungssystem eine zu adressierende Datenbank und eine für den Zweck zu benutzende (für eine spezielle Grundtabelle oder Ansicht definierte) Bildschirmdatei aus. Dies kann interaktiv über die Tastatur oder über ein Abrufprogramm geschehen. Die Datenbank 150 und die Bildschirmdatei 151 werden durch das Datenverarbeitungssystem 10 eröffnet, das für die Datenstruktur DBUSER 173 und die Datenstruktur TCOM 160 Speicherplatz zuweist. Der Benutzer erstellt eine Anfrage an die Datenbank, die durch einen Cursor dargestellt wird. Das Datenverarbeitungssystem 10 eröffnet den Cursor und weist der Datenstruktur QUERY 162 Speicherplatz zu, bestimmt die Strategie zum Abrufen von Treffer- Datensätzen aus der Datenbank 150, und definiert qid.
Im Betrieb entsprechend WZPXI mit einem durch screen# indizierten Bildschirmformat LIST ruft das Datenverarbeitungssystem 10 den Baustein WZDISP (qid) 124 auf. Im Betrieb entsprechend WZDISP ruft das Datenverarbeitungssystem 10 WZRE- TRIEVE (qry.source) auf, das dann die Zugriffsmethode 102 im Betriebssystem 100 adressiert, um aus dem Ziel einen durch den Cursor definierten Treffer-Datensatz darstellende Signale abzurufen und sie im Systempufferspeicher 168 zu speichern. Für einen Bildschirm LIST werden mehrere Treffer-Datensätze abgerufen, und ihre Signale werden im qry.List-Buffer gespeichert.
Nach Rücksprung von WZRETRIEVE, ruft das Datenverarbeitungssystem 10 zur Vervollständigung der For-Display-List 155/174 den Baustein WZSCRLOD 116 auf, danach den Baustein WZSCRIO 120; im Betrieb entsprechend diesem Baustein ruft das Datenverarbeitungssystem 10 den Baustein WZ-FORMS 122 auf. Im Betrieb entsprechend WZFORMS benutzt das Datenverarbeitungssystem 10 die Adressensignale in der For-Display-List 155/174, um die Signale für das vordefinierte Anzeigeformat aus dem Bildschirmformat LIST 400, die bei 166 in der Bildschirmdatei 151 gespeichert sind, mit den abgerufenen Treffer-Datensatz- Signalen zu kombinieren, die in qry. List-Buffer gespeichert sind, um das Bildschirmformat LIST zu modifizieren und dadurch ein als Ergebnis gespeichertes Bildschirmbild zu definieren.
Im Betrieb entsprechend dem Betriebssystem 100 steuert das Datenverarbeitungssystem 10 dann das Sichtgerät 18 in der Weise, daß es eine Darstellung des definierten Ergebnis- Bildschirmbildes anzeigt. Während dieser Anzeige aktiviert das System 10 die Tastatur 20. Der Benutzer kann die Tastatur 20 zur Abgabe von Aufzählsignalen benutzen, die bestimmte der abgerufenen Treffer-Datensätze, deren Darstellungen angezeigt sind, bestimmen. Durch Betätigen einer Funktiosntaste stellt der Benutzer ferner Operationswahlsignale bereit, die aus der Vielzahl anwählbarer Operationen, die auf dem Bildschirm LIST angezeigt werden, eine auswählen.
Wenn unter der Annahme, daß einige Datensätze aufgezählt worden sind, eine Funktionstaste betätigt wird, arbeitet das Datenverarbeitungssystem 10 entsprechend dem Betriebssystem 100 und modifiziert das definierte Bildschirmbild entsprechend den vom Benutzer eingegebenen Signalen. Weiterhin bewirkt das Datenverarbeitungssystem 10, daß Signale, welche die Nummer der betätigten Funktionstaste darstellen, gespeichert werden.
Im weiteren Betrieb entsprechend dem Baustein WZFORMS 122 kopiert das Datenverarbeitungssystem 10 die Funktionstastensignale in das Datenspeicherelement for.fpf-key in der Datenstruktur FOR 164. Nach Rücksprung von WZFORMS und im weiteren Betrieb entsprechend dem Baustein WZSCRIO 120 benutzt das Datenverarbeitungssystem 10 die in for.fpf-key gespeicherten Signale als Index zur Datenstruktur POP-Tabelle 156, die dem Bildschirm LIST entspricht, und kopiert daraus die Signale der "oper", die der betätigten Funktionstaste entspricht, in das Speicherelement qry.oper in der Datenstruktur QUERY 162. Die Signale in qry.oper-action sind Ausgangssignale der Relationsoperator-Einrichtung, die für die vom Benutzer gewählte Operation repräsentativ sind. Im weiteren Betrieb entsprechend dem Baustein WZSCRIO 120 setzt das Datenverarbeitungssystem 10 Flags in der Seen-List 176, die bestimmte Datensätze, wie sie im modifizierten Bildschirmbild angegeben sind, kennzeichnen.
Nach Rücksprung von WZSCRIO und im weiteren Betrieb entsprechend dem Baustein WZDISP 124 testet das Datenverarbeitungssystem 10 die in qry.oper-action gespeicherten Signale. Wenn die Aktion Next, Previous, First, Last, Return (von Display zu List) oder Display ist, kann das System 10 die angewählte Operation während des Betriebs entsprechend dem Baustein WZDISP 124 ausführen. Diese Aktionen können so oft wie vom Benutzer gewünscht und in beliebiger Folge angewählt werden, um es dem Benutzer zu ermöglichen, von gewünschten Treffer- Datensätzen eine Anzeige zu erhalten, bevor eine Gruppe bestimmt wird und Operationen wie Modifizieren und Entfernen an den ausgewählten Treffern durchgeführt werden.
Ist die Aktion keine der Aktionen Next, Previous, First, Last, Return zu LIST von DISPLAY oder zu DISPLAY von LIST, kehrt das Datenverarbeitungssystem 10 zum Baustein WZPXI 114 zurück. Ist die Aktion Modifizieren, Entfernen oder Hinzufügen (oder eine andere Aktion, die in der POP-Tabelle definiert, hier aber nicht beschrieben ist), springt der Baustein WZPXI 114 zur Interpretation der Aktion zum Abrufprogramm zurück. Das bei der vorliegenden Ausführungsprogramm dargestellte Abrufprogramm ruft die Bausteine 126 und 115 auf, um die Operationen Modifizieren, Entfernen und Hinzufügen mit den zweckdienlichen Bildschirmformaten aus der Bildschirmdatei 151 auszuführen.
Bestimmt der Benutzer mehr als einen Treffer-Datensatz auf einem Bildschirm LIST und betätigt dann eine Funktionstaste, mit der Entfernen oder Modifizieren angewählt wird, wird von jedem bestimmten Datensatz eine Darstellung auf dem angegebenen Bildschirm angezeigt, bis alle angezeigt worden sind.
Als Folge der gerade beschriebenen Operation ergibt sich eine bestimmte Relation, die von dem Anfangscursor interaktiv abgeleitet ist, der vom Abrufprogramm in Übereinstimmung mit den vom Benutzer über die Tastatur 20 eingegebenen Aufzählsignalen bereitgestellt wird. Die aufgezählte Relation (eines Elementes) kann vom Benutzer über den Bildschirm LIST definiert werden, indem, wie beschrieben, die Bildschirm-Schreibmarke neben die Darstellung eines Treffer-Datensatzes gebracht und eine Funktionstaste betätigt wird; alternativ kann die aufgezählte Relation (eines oder mehrerer Elemente) durch die Eingabe eines Zeichens neben der Darstellung eines oder mehrerer Treffer-Datensätze und durch Betätigen einer Funktionstaste definiert werden. Schließlich führt die Betätigung einer Funktionstaste durch den Benutzer während der Anzeige des Bildschirms DISPLAY zur Definition einer bestimmten Relation, die den angezeigten einzelnen Treffer-Datensatz umfaßt. Ferner ist ein Ausgangssignal vorgesehen, das für eine vom Benutzer aus den angezeigten anwählbaren Operationen ausgewählte Operation repräsentativ ist. In allen diesen Fällen ist die bestimmte Relation durch Signale spezifiziert, die einen "modifizierten Cursor" darstellen, welcher die aufgezählten Merker in der Seen-List umfaßt. Ein weiterer Betrieb entsprechend dem Abrufprogramm, das den "modifizierten Cursor" und die angewählte Operation darstellende Signale empfängt, ist somit von der Weise unabhängig, in der die Aufzählung bzw. Bestimmung durchgeführt wurde.

Bildschirm SELECT (Auswahl)

Zusätzlich zu der Einrichtung zum Definieren einer bestimmten Ergebnisrelation ist gemäß meiner Erfindung eine Einrichtung zum interaktiven Definieren einer charakteristisch definierten Ergebnisrelation vorgesehen, d.h. einer Relation, bei der die Zugehörigkeit zu ihr in Form von Treffer-Datensatz-Attributen definiert ist, die explizit definiert und im Datenbank- Ziel vorhanden sind. Dies geschieht mittels des Bildschirmformats SELECT 404 und des Bausteins WZSELECT 128 in Verbindung mit schon beschriebenen Elementen.
Mit nochmaligem Bezug auf Fig. 7: Im Programmteil der Speichervorrichtung 17 im Datenverarbeitungssystem 10 sind Signale vorgesehen, die einen weiteren Programmbaustein WZSELECT 128 darstellen. Arbeitet das Datenverarbeitungssystem 10 entsprechend dem Baustein WZPXI 114, wie schon beschrieben wurde, überprüft es die Signale, welche den Bildschirmtyp (Betriebsartindikator) des Schirms darstellen, der durch screen# in der (durch qry.@pxiscr angegebenen) Bildschirmdatei 151 indiziert ist. Ist der Bildschirm ein SELECT-Bildschirm, ruft WZPXI den Baustein WZSELECT 128 auf. Qry.@pxiscr ist so gesetzt, daß es einen SELECT-Bildschirm während des Betriebes entsprechend dem Baustein WZDISP 124 angibt, wenn der Benutzer während der Anzeige des LIST-Bildschirms die Funktionstaste 204-7 betätigt. WZPXI benutzt den Wert von qry.pxiscr# zur Verfolgung der Übergänge zwischen dem Bildschirm SELECT und den Bildschirmen LIST/DISPLAY.
Hinsichtlich der die Eingabeparameter @qry und @cursor darstellenden Signale arbeitet des Datenverarbeitungssystem 10 entsprechend dem Baustein WZSELECT 128 und ruft den Baustein WZSCRIO 120 auf, um das Bildschirmformat SELECT 404 (Fig. 13) anzuzeigen. Das Format umfaßt die Namen der Zielrelation und der Ansichtsfelder für die Zielrelation.
Im Betrieb entsprechend dem Baustein WZSCRIO 120 ruft das Datenverarbeitungssystem 10 den Baustein WZFORMS 122 auf und arbeitet diesem entsprechend in der beschriebenen Weise, um eine Darstellung des Bildschirmformats SELECT 404 mit dem Ziel-Ansichtsnamen bei 310 und den Namen der Ansichtsfelder im Teil 306 anzuzeigen. Der Ansichtsname und die Ansichtsfeldnamen sind universelle Elemente. Jeder Wert eines Attributs (Feldes), der zuvor zum Teil des Cursors gemacht wurde, z.B. ein Suchkriterium, ist auf dem SELECT-Bildschirm neben dem Feldnamen dargestellt; die übrigen Felder sind leer.
Die Felder, ob leer oder zuvor eingegebene Suchkriterien anzeigend, sind offene Elemente, d.h. der Benutzer kann in die offenen Elemente charakterisierende Elemente einschreiben. Der Benutzer kann die Bildschirm-Schreibmarke zu einem gewünschten Feld bringen und unter Benutzung der Schreibmaschinentasten 200 der Tastatur 20 (Fig. 5) einen Wert zur Erzeugung charakterisierender Signale eingeben. Die Anzeige wird entsprechend geändert. Bei Bedarf kann dies bei mehr als einem der angezeigten Felder ausgeführt werden. Die vom Benutzer in die offenen Elemente eingegebenen charakterisierenden Werte liefern neue Suchkriterien, die den Cursor hinsichtlich der Attribute der Treffer-Datensätze in der Zielrelation der benannten Datenbank weiter verfeinern oder charakterisieren.
Schließlich betätigt der Benutzer eine der den angezeigten auswählbaren Operationen entsprechenden Funktionstasten. Zu den auswählbaren Operationen auf dem SELECT-Bildschirm gehören List, Delete und Modify. Die Signale, welche die betätigte Funktionstaste darstellen, werden in der weiter oben beschriebenen Weise in for.fpf-key gespeichert, und das entsprechend dem Baustein WZSCRIO 120 in der weiter oben beschriebenen Weise arbeitende Datenverarbeitungssystem 10 kopiert die POP.oper-Signale für die betätigte Taste nach qry. oper.
Im weiteren Betrieb entsprechend dem Baustein WZSELECT 128 leitet das Datenverarbeitungssystem 10 jedoch durch Modifizieren der Signale der Datenstruktur CURSOR 158 einen neuen Cursor ab, der die vom Benutzer in die angezeigten Ansichtsfelder eingegebenen charakterisierenden Werte widerspiegelt. Das Datenverarbeitungssystem 10 schließt dann den anfänglichen Cursor (durch Aufrufen und Arbeiten entsprechend einem nicht dargestellten, jedoch herkömmlich ausgelegten zweckdienlichen Baustein), und ruft dann den Baustein WZOPEN CUR- SOR 110 auf. Im Betrieb entsprechend den Signalen des Bausteins 110 weist das Datenverarbeitungssystem 10 Speicherplatz für eine neue Datenstruktur QUERY 162 zu, die dem neuen (modifizierten alten) Cursor entspricht. Das Datenverarbeitungssystem 10 kehrt dann vom Baustein WZSELECT 128 zum Baustein WZPXI 114 zurück. Das Datenverarbeitungssystem 10 setzt qry.source so, daß der Bildschirmtyp gezeigt wird, auf den qry. @pxiscr verweist.
Das Ergebnis der Operation entsprechend dem Baustein WZSELECT ist die interaktive Erstellung einer Ergebnisrelation, die charakteristisch definiert ist, d.h. mit Attributen, die in den Treffer-Datensätzen der Zielrelation der Datenbank explizit dargestellt sind. Ferner sind Ausgangssignale bereitgestellt, die für eine Operation repräsentativ sind, welche der Benutzer aus den angezeigten auswählbaren Operationen ausgewählt hat, zu denen Operationen gehören, die das Datenverarbeitungssystem 10 an der Ergebnisrelation ausführen kann. Wenn durch die betätigte Funktionstaste die Operation LIST gewählt wurde, ruft WZPXI, abhängig vom Bildschirmtyp des LIST-Bildschirms, den Baustein WZDISP 124 in der weiter oben beschriebenen Weise auf, um auf dem LIST-Bildschirm die vom neudefinierten Cursor definierten Treffer-Datensätze anzuzeigen. Der Benutzer kann nunmehr enumerativ eine vom neudefinierten Cursor abgeleitete Relation definieren. Hat die betätigte Funktionstaste entweder Entfernen oder Modifizieren gewählt, werden Darstellungen der Treffer-Datensätze, die durch den neudefinierten Cursor spezifiziert sind, sequentiell auf dem zugehörigen Bildschirm angezeigt, wodurch es dem Benutzer möglich ist, eine solche Aktion bei jedem Treffer- Datensatz in der Datenbank auszuführen.
Bei bevorzugten Ausführungsformen umfaßt die Relationsoperator-Einrichtung meiner Erfindung eine Einrichtung zur Ausgabe eines Ausgangssignals, das eine Operation repräsentiert, die aus einer dem Benutzer angezeigten Vielzahl von auswählbaren Operationen ausgewählt wurde, zusammen mit einer Einrichtung zum Erstellen einer Ergebnisrelation, bei der die Zugehörigkeit zu ihr über die Tastatur enumerativ und interaktiv definiert wird, und eine Einrichtung zur Erstellung einer Ergebnisrelation, bei der die Zugehörigkeit zu ihr über die Tastatur charakteristisch und interaktiv definiert wird. Jedoch kann jede der Einrichtungen zur Erstellung einer Ergebnisrelation ohne die andere vorgesehen sein, und dadurch können beträchtliche Vorteile bei der interaktiven Pflege von relationalen Datenbanken verwirklicht werden.
Sind Einrichtungen zur Definition sowohl von enumerativ als auch von charakteristisch definierten Ergebnisrelationen vorzusehen, muß der Baustein WZPXI 114 Signale bereitstellen, die Befehle in der nachstehend genannten allgemeinen Form darstellen (die Terminologie entspricht keiner der Standard- Programmiersprachen):
Setze PXI-verarbeitete Aktion = ja
Schleife während PXI-Verarbeitung der Aktion = ja
Überprüfe Bildschirmtyp des durch qry.@pxiscr adressierten Bildschirms
Wenn Typ SELECT, aufrufe WZSELECT (dadurch wird qry.action gesetzt)
Wenn Typ DISPLAY oder LIST, aufrufe WZDISP (dadurch wird qry.action gesetzt)
Überprüfe qry.action
Wenn Aktion Select, List oder Display, hole zugehörigen Bildschirm (und Schleife)
sonst, wenn andere Aktion, setze PXI-verarbeitete Aktion = nein (verlasse Schleife)
Rückspringe zu DOQUERY.
Im Betrieb entsprechend dem Abrufprogramm, das die hier beschriebenen Bausteine für den Betrieb meiner Relationsoperator-Einrichtung aufgerufen hat, kann das Datenverarbeitungssystem 10 Signale, welche die mit Funktionstaste gewählte Operation darstellen, aus $oper-name bekommen. Derartige Signale sind auch in der Datenstruktur ATAB 172 vorgesehen. (Die Signale stehen aus die vorliegende Beschreibung nicht betreffenden Gründen in zwei Formen zur Verfügung.) Das Datenverarbeitungssystem 10 kann dann weitere Operationen mit Steuerung durch das Abrufprogramm weiterausführen.
Die Relationsoperator-Einrichtung hat eine Ergebnisrelation geliefert, interaktiv abgeleitet aus dem Anfangscursor, den das Abrufprogramm in Übereinstimmung mit den vom Benutzer über die Tastatur 20 eingegebenen Signalen bereitgestellt hat. Die Ergebnisrelation kann entweder eine enumerativ definierte Relation sein, die durch einen "modifizierten Cursor", der die aufzählenden Signale umfaßt (in der Seen-List 176 gemäß Fig. 11 als Merker dargestellt) oder eine charakteristisch definierte Relation, die durch die Signale des modifizierten Cursors in der Datenstruktur CURSOR 158 definiert ist.
In jedem Fall hat die interaktiv definierte Ergebnisrelation die Merkmale einer im Kontext von relationalen Datenbanken definierten Relation, d.h. daß weitere Operationen, die für die Benutzung bei Relationen ausgelegt und erstellt sind, an der Ergebnisrelation ausgeführt werden können. Insbesondere können die Datensätze der Ergebnisrelation mit Steuerung durch für die Wiedergewinnung von Datensätzen in einer Relation ausgebildeten Bausteinen abgerufen werden. Außerdem kann die Ergebnisrelation durch das Abrufprogramm in jeder gewünschten Weise bearbeitet werden, ohne Berücksichtigung der speziellen Weise, in der sie definiert wurde, wodurch das Abrufprogramm unabhängig von der angewandten physischen Struktur ist, die angewendet wurde (Tastatur, Tastbildchirm o.dgl.), ebenso wie davon, ob die Ergebnisrelation enumerativ oder charakteristisch definiert wurde. Dies bietet große Flexibilität bei der Benutzung solcher Ergebnisrelationen.
Es wird nunmehr Bezug genommen auf Fig. 9, in der meine Relationsoperator-Einrichtung konzeptionell als "black box" dargestellt ist. Die Eingaben in die Black-Box sind die Cursorsignale, die, wie schon beschrieben, durch das Abrufprogramm geliefert werden (oder durch den Baustein WZSELECT 128 in dem Sonderfall definiert sind, wenn, wie beschrieben, der Anfangsbildschirm ein SELECT-Bildschirm ist), und Anzeigeformatsignale, die vordefiniert und in der Bildschirmdatei 151 gespeichert sind. Die Signale von der Tastatur 20 sind ein weiterer Eingang in die Black-Box, die eine Ergebnisrelation darstellende Ausgangssignale erzeugt, zusammen mit einer ausgewählten Operation (aus jenen Operationen, die dem Benutzer zur Auswahl durch Funktionstastenbetätigung vorgehalten werden). Die die Ergebnisrelation darstellenden Signale sind in der Datenstruktur CURSOR 158 ebenso wie in Seen-List 176 (für die enumerativ definierten Ergebnisrelation) gespeichert; die die ausgewählten Operationen darstellenden Signale sind in den Datenstrukturen ATAB 172 und $oper-name 170 gespeichert.
Weil die Relationsoperator-Einrichtung meiner Erfindung effektiv eine Eingangsrelation (die durch den Cursor definiert ist) in eine Ergebnisrelation umwandelt, ist diese Operator- Einrichtung den bekannten relationalen Operatoren sehr ähnlich, die für Operationen an Tabellen relationaler Datenbanken, nämlich PROJECT (Projektion), SELECT (Auswahl) und JOIN (Verbinden). (Weitere relationale Operatoren sind ebenfalls durch verschiedene Autoren definiert worden.) Ein notwendiges Merkmal eines relationalen Operators ist, daß er Operationen an einer Relation ausführt, um eine andere Relation zu bilden, an der selbst durch einen relationalen Operator Operationen ausgeführt werden können. Dieses Merkmal ist auf andere (mathematische) Weise als Anweisung ausgedrückt, daß die Menge möglicher Relationen durch die Operation eines relationalen Operators geschlossen wird. Es wird darauf hingewiesen, daß die Ergebnisrelation keine physische oder Grundtabelle innerhalb der Datenbank sein braucht, aber mit der Definition einer Relation übereinstimmen muß.
Die Operator-Einrichtung meiner Erfindung erfüllt diese Forderung und kann somit als relationaler Operator betrachtet werden. Dieses Merkmal der Operator-Einrichtung ermöglicht es, diese Einrichtung als Teil einer Folge von relationalen Operatoren zu benutzen. Ferner ist es möglich, aus der Datenbank die Datensätze der Ergebnisrelation zu holen, unter Anwendung derselben Operation, die zum Holen von Datensätzen einer beliebigen, durch einen Cursor in üblicher Weise definierten Relation benutzt wird. Dies erspart Aufwand beim Programmieren und vereinfacht die Arbeitsweise.
Jedoch definiert jeder normale Operator bei Anwendung auf eine Relation implizit eine Ergebnis- oder Produktrelation, wobei die Zugehörigkeit zu ihr durch den Wert eines der Attribute in der durch den Cursor definierten Anfangsrelation bestimmt ist. Das heißt, die Zugehörigkeit zur Ergebnisrelation ist "charakteristisch" definiert mittels eines Charakteristikums oder eines Attributs der Datensätze, die in der Datenbank explizit vorhanden sind. Zum Beispiel ist es möglich, aus einer Tabelle von Kunden die mit grünen Haaren nur dann AUSZUWÄHLEN, wenn die Haarfarbe als ein Attribut für diese Relation definiert worden ist.
Dagegen sorgt meine Relationsoperator-Einrichtung für eine Ergebnisrelation, bei der die Zugehörigkeit zu ihr "enumerativ" definiert ist, das heißt, mittels Abzählung durch den Benutzer über die Tastatur, und eine solche Zugehörigkeit kann daher unabhängig von den in der gespeicherten Datenbank explizit definierten und vorhandenen Attributen der Treffer- Datensätze sein, aber, vielleicht nur in Kenntnis des Benutzers, von einem Merkmal des dem Datensatz zugrunde liegenden Objekts abhängig sein.
Meine neuartige Operator-Einrichtung ermöglicht es daher, eine vom Benutzer bestimmte willkürliche Menge interaktiv zu konstruieren und danach die Menge als Element der Relationsklasse zu behandeln, mit all den Vorteilen, die sich daraus für die Datenbehandlung ergeben. In herkömmlichen Datenverwaltungssystemen konnte eine Tabelle bestimmter Elemente erstellt werden, jedoch nur durch für diesen Zweck ausgelegtes explizites Programmieren (im Anwenderprogramm), und die konstruierte Tabelle konnte dann nicht als Element der Relationengruppe behandelt werden. Folglich konnten beispielsweise die Datensätze nicht durch Benutzen derselben Operation abgerufen werden, die zum Abrufen von Datensätzen in den Relationen benutzt wurde; statt dessen mußte ein zusätzlicher Programmbaustein für diesen Zweck vorgesehen werden.
Ferner sorgt meine Operator-Einrichtung für eine interaktive Definition einer Ergebnisrelation, bei der die Zugehörigkeit zu ihr charakteristisch definiert ist in Form eines in der Datenbank explizit definierten und vorhandenen Attributs eines Treffer-Datensatzes. Eine solche interaktive Definition wird dadurch viel einfacher gemacht, als es bei Benutzung herkömmlicher Mittel möglich gewesen ist.
Eine spezielle Ausführungsform der vorliegenden Erfindung umfaßt spezielle Datenstrukturdefinitionen und Programmbausteine, die auf einem WANG-Rechner 100 VS-100 (virtueller Speicher) ablauffähig sind. Ein Quellencode für die speziellen Datenstrukturvereinbarungen und Programmbausteine ist im beigefügten Microfiche-Anhang vorgesehen, der 439 Bilder auf 9 Microficheblättern aufweist.

ABRUF VON ZUSAMMENGEHÖRIGEN DATENSÄTZEN

Ein oder mehrere an Prozessoren 12 angeschlossene Endgeräte oder Konsolen weisen je einen Kathodenstrahlröhren-Bildschirm als Sichtgerät 18 und eine Tastatur als Signaleingabegerät 20 auf. Andere Signaleingabegeräte, z.B. Maus, Tastbildschirm, Sprachbetätigung u.dgl., werden von der Erfindung berücksichtigt. Wird die Erfindung in einem großen Datenverarbeitungssystem angewandt, können im System zusätzliche Prozessoren vorhanden sein, z.B. als Ein/Ausgabe-Prozessoren, und die hier als von den "Prozessoren" ausgeführt bezeichneten Operationen können tatsächlich auf solche Prozessoren verteilt sein. Solche Einzelheiten beeinträchtigen den Umfang der Erfindung nicht.
Die bei dieser Ausführungsform der Erfindung zu benutzende Tastatur mit Funktionstasten und die Speichervorrichtung 17 sind dieselben, die weiter oben im Zusammenhang mit Fig. 1 und 5 beschrieben wurden.
Die Datenstrukturen und Bausteine, für die gemäß Fig. 6a und 7a Speicherplatz zugewiesen ist, sind im einzelnen weiter oben im Zusammenhang mit Fig. 6 und 7 beschrieben.
Die Bausteine im Programmspeicherteil der Speichervorrichtung 17 gemäß Fig. 7a werden zum Steuern der Arbeitsweise des Datenverarbeitungssystems 10 hinsichtlich der in Fig. 6a gezeigten Datenstrukturen benutzt. Die Arbeitsweise des so gesteuerten Systems 10 ist so, daß Darstellungen einer durch den Cursor in der Datenstruktur 158 definierten Gruppe Treffer-Datensätze in der Datenbank 150 gemäß Fig. 6a dem Benutzer des Endgerätes am Sichtgerät 18 vorgehalten werden in einem Bildschirmformat 166, das aus einer Gruppe Bildschirmformate in der Bildschirmdatei-Datenstruktur 151 in einer Weise ausgewählt wird, die in Verbindung mit Fig. 6 und 7 beschrieben wurde.
Das Bildschirmformat ermöglicht eine Anzeige von Darstellungen der Treffer-Datensätze in einer Form, die es dem Benutzer ermöglicht, durch Betätigen der Tastatur 20 einige oder alle der dargestellten Treffer-Datensätze für die Ausführung weiterer Operationen auszuwählen. Außerdem ermöglicht es das Bildschirmformat, dem Benutzer Darstellungen einer Vielzahl von auswählbaren Operationen anzuzeigen, die durch das Datenverarbeitungssystem ausführbar sind. Diese Darstellungen werden in Verbindung mit Identifizierern der Funktionstasten 204 (ebenso wie der ENTER-Taste 206) angezeigt, die zum Auswählen einer Operation betätigt werden können. Das Datenverarbeitungssystem 10 ruft die definierten Treffer-Datensätze ab und kombiniert die abgerufenen Treffer-Datensätze mit dem Bildschirmformat, um ein gespeichertes Bildschirmbild zu definieren, und zeigt dann mit Steuerung durch das Betriebssystem 100 eine Darstellung eines solchen Bildes auf dem Sichtgerät 18 an.
Während einer solchen Anzeige ist die Tastatur 20 aktiviert, und Eingangssignale von der Tastatur erzeugen abzählende oder charakterisierende Signale. Im Betrieb mit Steuerung durch die Bausteine gemäß Fig. 7a leitet das System 10 von solchen Eingabesignalen, zusammen mit den Signalen des Cursors der Datenstruktur 158, Signale ab, die eine Ergebnisrelation definieren, die entweder enumerativ oder charakteristisch definiert ist.
Außerdem sorgen andere über die Tastatur 20 während einer solchen Anzeige eingegebene Signale für Operationswahlsignale, die eine Operation aus einer Vielzahl auswählbarer Operationen auswählt, welche durch das Datenverarbeitungssystem durchführbar sind.
Solche abgeleitete Signale (die sowohl die Ergebnisrelation definieren und eine Operation auswählen) sind in der Datenspeichervorrichtung 17 gespeichert und stehen zur Benutzung bei der weiteren Steuerung des Datenverarbeitungssystems 10 in Übereinstimmung mit dem Abrufprogramm zur Verfügung.
Gemäß einem ersten Merkmal dieses Teils der Erfindung wird die vorstehend beschriebene Relationsoperator-Einrichtung sequentiell bei mehr als einer Bildschirmdatei und mehr als einer Datenbank verwendet, derart, daß die interaktive Konstruktion und Ausführung eines Anwenderprogramms zur Datenbankpflege ausgeführt wird.
Die Arbeitsweise entsprechend diesem ersten Merkmal meiner Erfindung wird zuerst im Überblick, danach näher beschrieben.
Es wird auf Fig. 16 verwiesen. In dieser konzeptionellen Ansicht sind die Operationen des Datenverarbeitungssystems 10 hinsichtlich der Arbeitsspeicher- und Datenbank-Speicherteile der Speichervorrichtung 17 mit aufeinanderfolgender Steuerung durch bestimmte Programmbausteine dargestellt. Es versteht sich, daß während einer solchen Arbeitsweise die jeden Programmbaustein darstellenden Signale aus dem Programmspeicherteil kopiert und zur Steuerung des physikalischen Zustands verschiedener Hardwarekomponenten des Systems 10 benutzt werden, um die gewünschten realen Operationen auszuführen. Aus Gründen der Einfachheit ist in dieser Figur das Datenverarbeitungssystem selbst nicht explizit dargestellt. Jedoch stellen die mit "greift zu auf" bezeichneten Linien eine Operation des Prozessors 12 zum Lesen (Empfangen von Signalen von) den dargestellten Speicherstrukturen in der Speichervorrichtung 17 dar; die mit "bildet" bezeichneten Linien stellen eine Operation des Prozessors 12 zur Zuweisung von Speicherplatz für und Einschreiben in die dargestellten Speicherstrukturen der Speichervorrichtung 17 dar. Die angegebenen Eingaben von der Tastatur 20 verstehen sich als Eingangssignale von der Tastatur 20 an den Prozessor 12. Die Parameter $screen-file und $database sind als entsprechende Werte dieser Parameter darstellende Signale zu verstehen, die in zweckdienlicher Weise in den Prozessor 12 eingegeben werden.

Überblick

Gemäß meiner Erfindung sind die Signale, welche die Bildschirmdatei DD 502, die Meta-Meta-Datenbank 504, die Bildschirmdatei AB 510 und die @Default-Bildschirmgruppe 511 darstellen, in der Speichervorrichtung 17 vor Beginn der Operation enthalten. Gemäß Fig. 16 arbeitet das Datenverarbeitungssystem 10 zuerst mit Steuerung durch einen ersten Programmbaustein (DD Definition) 500 hinsichtlich einer ersten Bildschirmdatei (Bildschirmdatei DD) 502 und einer ersten Datenbank 504, die beide weiter unten beschrieben werden. Mit Vorteil verwendet das Datenverarbeitungssystem die Relationsoperator-Einrichtung meiner gleichzeitigen Anmeldung und empfängt Eingangssignale von der Tastatur 20, die von dem entsprechend dem Baustein 500 arbeitenden Datenverarbeitungssystem 10 interpretiert werden, um Signale abzuleiten und im Datenbankspeicherteil zu speichern, die eine zweite Datenbank 506 darstellen, welche weiter unten beschrieben wird.
Als nächstes arbeitet das Datenverarbeitungssystem 10 mit Steuerung durch einen zweiten Programmbaustein (Anwendungskonstruktion) 508 hinsichtlich einer zweiten Bildschirmdatei (Bildschirmdatei AB) 510 und einer "@DEFAULT" genannten Bildschirmgruppe 511, die beide noch beschrieben werden, und hinsichtlich der Datenbank 506, die während des vorangegangenen Schrittes aufgebaut wurde. Mit Vorteil verwendet das Datenverarbeitungssystem 10 die Relationsoperator-Einrichtung meiner gleichzeitigen Anmeldung und empfängt Eingangssignale von der Tastatur 20, die von dem entsprechend dem Baustein 508 arbeitenden Datenverarbeitungssystem 10 interpretiert werden, um Signale abzuleiten und im Arbeitsspeicher zu speichern, die eine weiter unten beschriebene dritte Bildschirmdatei 512 darstellen.
Schließlich arbeitet das Datenverarbeitungssystem 10 entsprechend einem Interpretierprogramm, z.B. dem weiter oben beschriebenen Baustein PACE RUN 514, hinsichtlich der konstruierten Bildschirmdatei 512 und der dritten Datenbank 516, wobei es die weiter oben beschriebene Relationsoperator-Einrichtung verwendet, um eine interaktive Pflege und Benutzung der Datenbank 516 ab dem Systemendgerät zu ermöglichen. Die konstruierte Bildschirmdatei 512 funktioniert somit als Anwenderprogramm für die interaktive Benutzung der Datenbank 516, wie nachstehend beschrieben wird.
Die erste Datenbank 504 ist eine Meta-Meta-Datenbank, das heißt, sie umfaßt eine universelle Beschreibung einer beliebigen Datenbankdefinition (Meta-Datenbank). Sie enthält Relationen, deren Treffer-Datensätze universelle Definitionen der Elemente einer Datenbank sind: Dateien, Ansichten, Datensätze und Beziehungen. Im Betrieb des Datenverarbeitungssystems 10 entsprechend dem Baustein 500 liefert der Benutzer Relationsnamen, Spalten- oder Domänennamen, Attributdefinitionen, Feldlängen und Feldtypen sowie alle notwendigen Informationen über die spezielle Datenbank 516, deren Treffer-Datensätze schließlich vom Benutzer unter Benutzung des Anwenderprogramms gehandhabt werden. Die somit vom Benutzer gelieferte und die Datenbank 506 bildende Definition der speziellen Datenbank 516 kann als "Meta-Datenbank" bezeichnet werden, das heißt, als eine Beschreibung einer speziellen Datenbank. Die Meta-Datenbank 506 ist selbst eine relationale Datenbank.
Durch die Verwendung der Relationsoperator-Einrichtung kann der Datendefinitionsprozeß, wie weiter oben beschrieben, mit Vorteil interaktiv und nicht verfahrensorientiert durchgeführt werden. Der Benutzer braucht keine Datendefinitionssprache lernen oder sich Namen von Datenelementen oder Operationen merken. Somit sind Nichtprogrammierer in der Lage, Datendefinitionen auszuführen.
Ferner kann auch die Definition der erzeugten Bildschirmdatei 512 mit Vorteil interaktiv und nicht verfahrensorientiert durch Anwendung meiner Relationsoperator-Einrichtung verwirklicht und somit von Nichtprogrammierern ausgeführt werden. Ein Nichtprogrammierer ist somit effektiv in der Lage, ein Anwenderprogramm zu erstellen.
Wenn das erzeugte Anwenderprogramm abgearbeitet wird (wenn also die erzeugte Bildschirmdatei 512 verwendet wird, um eine interaktive Pflege der Datenbank 516 zu ermöglichen), enthält ferner gemäß einem anderen Merkmal meiner vorliegenden Erfindung die Vielzahl von Operationen, die auf der Anzeige dargestellt und mittels einer Funktionstaste 204 auswählbar sind, zusätzlich zu den in meiner gleichzeitigen Anmeldung beschriebenen Operationen einen weiteren Operationstyp, der generell als "Abstieg"-Operation bezeichnet wird. Diese Operation ermöglicht es dem Benutzer, eine Anzeige von Treffer- Datensätzen, die sich auf anfänglich angezeigte Treffer-Datensätze beziehen, bequem in einer noch zu beschreibenden Weise zu erzielen.

Datendiktionär

Auf dem Gebiet der Datenbankverwaltung sind Datendiktionäre oder Beschreibungen von Datenbänken allgemein bekannt und können auf mehrfache Weise aufgebaut werden. Ein Datendiktionär besteht aus Deskriptoren von Datenattributen, z.B. Feldnamen und Feldlängen. Insbesondere sind im Datendiktionär Grundtabellen, Felder, Schlüssel, Dateien und Ansichtstabellen der Datenbank definiert.
Ferner stellten einige herkömmliche Datendiktionäre für eine relationale Datenbank Definitionen der Beziehungen zwischen den Tabellen (Relationen) oder in einigen Fällen den Datensätzen und der Datenbank bereit.

Beziehungen

In Fig. 17 sind bestimmte Datensätze einer imaginären Datenbank als Beispiel dargestellt. Es sei angenommen, daß diese Datenbank Tabellen (Relationen) aufweist mit den Namen Kunde, Auftrag, Artikel und Teilenummer. Weitere Tabellen können vorhanden sein.
Ein Datensatz aus der Kunden-Tabelle (die viele solcher Kunden-Datensätze umfaßt) enthält die Felder mit den Namen Kunden-Nr., Kundenname, Adresse und Kontostand sowie weitere Felder, die hier nicht zur Sache gehören. Es sei angenommen, daß die Kunden-Nr. ein eindeutiger Schlüssel in der Kunden- Tabelle ist, das heißt, daß sein Wert einen Kunden eindeutig identifiziert. Ein Datensatz aus der Auftrags-Tabelle (die viele solcher Auftrags-Datensätze umfaßt) enthält die Felder Kunden-Nr., Auftrags-Nr. und Auftragsdatum, sowie weitere Felder, die hier nicht zur Sache gehören. Es leuchtet ein, daß wenn der Wert der Kunden-Nr. eines Kunden-Datensatzes die gleiche ist wie die Kunden-Nr. eines Auftrags-Datensatzes, dieser Umstand benutzt werden kann, um den Kunden-Datensatz mit dem Auftrags-Datensatz oder umgekehrt in Beziehung zu setzen. Der Umstand, daß ein Feld Kunden-Nr. in jedem Kunden- Datensatz und in jedem Auftrags-Datensatz vorhanden ist, bringt die Kunden-Tabelle mit der Auftrags-Tabelle in Beziehung. Weil viele Auftrags-Treffer-Datensätze mit einem einzelnen Kunden-Treffer-Datensatz in Beziehung stehen können, wird der Kunden-Datensatz als "Vater" oder "Eigentümer" und der Auftrags-Datensatz als "Sohn" oder "Element" definiert.
Ein Datenbankverwaltungsprogramm mit einer Datenbank, in der bereits eine Kunden-Tabelle vorgesehen ist, kann eine Auftrags-Tabelle mit den Feldern Auftrags-Nr. und Auftragsdatum definieren. Um eine Beziehung zwischen der Auftrags-Tabelle und der Kunden-Tabelle herzustellen, ist es notwendig, daß der Auftrags-Datensatz ferner die Kunden-Nr. des Kunden enthält, auf den sich dieser Auftrags-Datensatz bezieht. Wenn dieses Feld nicht bereits in der Auftrags-Tabelle definiert ist, muß es zur Unterstützung der Beziehung hinzugefügt werden.
Mit weiterem Bezug auf Fig. 17: Ein Artikel-Datensatz ist auf einen Auftrags-Datensatz durch zwei Felder bezogen: die Kunden-Nr. und die Auftrags-Nr. Beider Werte müssen gleich sein, wenn ein spezieller Artikel-Datensatz mit einem speziellen Auftrags-Datensatz in Beziehung gesetzt wird. Auf einen einzelnen Auftrags-Datensatz können viele Artikel-Datensätze bezogen sein. Ein Teile-Datensatz kann auf einen Artikel-Datensatz über die Teile-Nr. bezogen sein; viele Artikel-Datensätze können mit einem einzelnen Teile-Datensatz in Beziehung stehen.

Beziehungsattribute

Aus dem Stand der Technik ist bekannt, daß eine Beziehung durch die Attribute definiert ist:
Name des Vater-Datensatzes, Name des Sohn-Datensatzes,
Gruppe von Vater-Beziehungsfeldern (muß ein definierter eindeutiger Schlüssel sein),
Gruppe von Sohn-Beziehungsfeldern, Integritätsregeln (nachstehend beschrieben).
Beispielsweise sind die Vater-Beziehungsfelder im Auftrags- Datensatz gemäß Fig. 17 die Kunden-Nr. und die Auftrags-Nr. Diese sind auch die Sohn-Beziehungsfelder im Artikel-Datensatz.
Daher enthält der Definitionsvorgang für eine Beziehung folgende Schritte:
1. Definieren der Vater-Beziehung und der Vater-Beziehungsfelder.
2. Während der Definition der Felder in der zukünftigen Sohn-Relation, Spezifizieren der Vater-Tabelle für die Beziehung. Die Vater-Tabelle muß in jedem Treffer-Datensatz einen definierten eindeutigen Schlüssel aufweisen.
3. Spezifizieren, welcher eindeutige Schlüssel (von evtl. mehreren vorhandenen) in den Treffer-Datensätzen der Vater-Tabelle für die Beziehung zu benutzen ist. Die Felddefinitionen dieses Schlüssels werden in die Definition der Sohn-Tabelle kopiert.
4. Definieren von Integritätsregeln für die Beziehung. Diese können als Standardregeln vorgesehen sein oder durch den Benutzer modifiziert werden.
5. Definieren der Felder in der Sohn-Tabelle, die nicht an der Beziehung beteiligt sind.
Integritätsregeln bestimmen die Hinzufügung, Änderung oder Entfernung von Datensätzen in zusammengehörigen Tabellen. Wenn beispielsweise Beziehungen zwischen Kunden- und Auftrags-Tabellen in einer Datenbank definiert werden, kann eine Integritätsregel so definiert sein, daß ein Treffer-Datensatz nicht in die Auftrags-Tabelle hinzugefügt werden kann, wenn nicht ein Treffer-Datensatz bereits in der Kunden-Tabelle vorhanden ist, auf die der hinzugefügte Auftrags-Datensatz bezogen werden kann.
Gemäß meiner Erfindung sind zwei weitere Attribute einer Beziehung definiert, und sie darstellende Signale sind im Datendiktionär gespeichert, nämlich die Aufstiegs- und Abstiegsnamen der Beziehung. Der Aufstiegsname bezeichnet die Beziehung, wenn der Benutzer die Sohn-Datensätze sieht; der Abstiegsname wird benutzt, wenn der Benutzer die Vater-Datensätze sieht. Beim Ansehen der Auftrags-Tabelle kann der Name der Beziehung "Kunde" sein; beim Ansehen der Kunden-Tabelle kann der Name der Beziehung "Aufträge" sein. (Beachte, daß die Beziehung zwischen einem (Kunden) und vielen (Aufträgen) besteht.)
Jedoch brauchen die Namen der Beziehungen nicht notwendigerweise die gleichen wie die Namen der zusammengehörigen Tabellen sein. Wenn beispielsweise eine Angestellten-Tabelle und eine Manager-Tabelle als Sohn und Vater zusammengehören, kann der Name der aufsteigenden Beziehung "unterstellt wem" sein, wogegen der Name der absteigenden Beziehung "überwacht wen" sein kann.
Aus Gründen der Zweckmäßigkeit wird der Ausdruck "absteigend" gelegentlich verwendet, um Operationen generell zu bezeichnen, die in der Ablaufzeit hinsichtlich tatsächlicher Treffer-Datensätze ausgeführt werden, verbunden mit der Betrachtung der Beziehung von beiden Seiten.
Gemäß Fig. 16 ist gemäß meiner Erfindung für jede Relation (Grundtabelle oder Ansicht) in der Datenbank 516 ein Relationsdeskriptor 570 vorgesehen, der Signale liefert, welche den Namen der Relation und andere zugehörige Informationen darstellen, z.B. die Namen der Felder in ihr, die Feldtypen, die Feldlängen u.dgl.
Wenn alle Attribute definiert worden sind, weist das Datenverarbeitungssystem 10 der Gruppe von Attributen jeder definierten Beziehung eine Beziehungs-ID-Nr. zu. Diese Attribute darstellende Signale sind in einem Beziehungsattribut-Speicher 520 im Datendiktionär 506 innerhalb der Speichervorrichtung 17 gespeichert und durch die Beziehungs-ID-Nr. indiziert. Für jede Beziehung, an der die Relation partizipiert, ist die Beziehungs-ID-Nr. im Deskriptor 570 für diese Relation enthalten.

Baustein Datendefinition 500

Es wird nun meine Erfindung näher betrachtet und auf Fig. 16 verwiesen. Der Programmspeicherteil der Speichervorrichtung 17 stellt einen Programmbaustein 500 bereit, genannt DD Definition.
Der Baustein DD Definition kann als Abrufprogramm zum Abrufen der in Fig. 7a dargestellten Bausteine (ausgenommen PACE RUN) ausgebildet sein. Das heißt, im Betrieb mit Steuerung durch den Baustein 500, kann das Datenverarbeitungssystem 10 entsprechend den in meiner gleichzeitigen Anmeldung beschriebenen Bausteinen arbeiten, die eine interaktive Definition von enumerativ definierten Ergebnisrelationen mit Auswahl einer der auswählbaren Operationen ermöglicht.
Bei Aufruf durch den Baustein DD Definition 500 arbeitet die Relationsoperator-Einrichtung gemäß meiner gleichzeitigen Anmeldung hinsichtlich der Bildschirmdatei 502 in der Datenspeichervorrichtung 17, die eine Gruppe Bildschirmformate liefert, die geeignet sind, vom Endgerätebenutzer eine Definition der Datenbank 506 zu erlangen, und hinsichtlich des Meta-Diktionärs 504. Die Bildschirmdatei 502 umfaßt Bildschirmformate 503 des Typs LIST, DISPLAY und MODIFY, mit zugeordneten Steuersignalen 505 (POP-Tabellen, Bildschirmmaps u.dgl.), alle wie vorstehend beschrieben.
(Ein Bildschirm LIST zeigt eine Liste Treffer-Datensätze an, wogegen ein Bildschirm DISPLAY vollständigere Informationen (größere Anzahl Felder) über einen einzelnen Treffer-Datensatz anzeigt.)
Fig. 18 zeigt aus der Bildschirmdatei 502 ein Bildschirmformat LIST, das zum Anzeigen einer Liste aller vorhandenen Tabellen (Kunde, Artikel, Auftrag und Teile-Nr. genannt) in einem Datenbankbeispiel, zusammen mit den ersten 30 Zeichen jedes Tabellen-Kommentarfeldes benutzt wird. Wenn bei dieser Anzeige die Funktionstaste 204-10 der Tastatur 20 betätigt wird, erfolgt Übergang auf die Anzeige des vollständigen Kommentarfeldes für eine bestimmte Tabelle (mit Aufzählung in der in meiner gleichzeitigen Anmeldung beschriebenen Weise) unter Benutzung des DISPLAY-Formats. Mittel für die Ausführung dieses Übergangs wurden weiter oben beschrieben. Die Betätigung der Funktionstaste 204-6 führt zum Übergang auf die Anzeige eines Bildschirmformats ADD gemäß Fig. 19 aus der Bildschirmdatei 502, ebenfalls durch weiter oben beschriebene Mittel.
Bei Anzeige des Bildschirms LIST gemäß Fig. 6 verursacht die Betätigung der Funktionstaste 204-1 (Erweiterte Funktionen) einen Übergang zur Anzeige des Bildschirms Advanced LIST (Erweiterte Liste) mit Darstellungen der einer weiteren Vielzahl wählbarer Operationen zugeordneten Funktionstasten 204 (Fig. 20). (Wenngleich weiter oben nicht explizit beschrieben, wird dieser Übergang vom Baustein WZPXI 114 in einer Weise vollzogen, die der für ähnliche Übergänge ähnlich ist.) Unter dieser Vielzahl wählbarer Operationen befinden sich mehrere Operationen, die das Definieren von Beziehungen betreffen, in denen die aufgelisteten Tabellen partizipieren. Insbesondere ist eine wählbare Operation für "Beziehung Erstellen" vorgesehen.
Die Betätigung der Funktionstaste 204-6 für Beziehung Erstellen während der Anzeige des Bildschirms Tabellen Advanced LIST führt zu einem Übergang in die Anzeige eines (nicht dargestellten) Bildschirmformats, das dem Benutzer die Definition der Attribute der Beziehung ermöglicht. (Bei alternativen Ausführungsformen kann auf diese Funktion von einem Bildschirm LIST Fields (Listenfelder) aus zugegriffen werden.) Solche Attribute darstellende Signale werden durch das Datenverarbeitungssystem 10 im Datendiktionär 506 innerhalb der Datenstruktur 520, unter "Beziehungsattribute", mit Indexierung durch die Beziehungs-ID-Nr. gespeichert.
Im Betrieb entsprechend dem Benennungsbaustein 526 des Bausteins DD Definition 500 greift das Datenverarbeitungssystem 10 innerhalb des Datendiktionärs 506 auf die Definitionen der beiden zusammengehörigen Tabellen zu, ruft die Namen der Tabellen auf und weist der Beziehung die Namen der Tabellen als Standard-Aufstiegs- und -Abstiegsnamen zu.
Die Betätigung der Funktionstaste 204-9 beim Anzeigen des Bildschirms Advanced LIST verursacht einen Übergang zum Bildschirm DISPLAY RELATIONSHIP (Anzeige Beziehung) (Fig. 21). Dieser Bildschirm zeigt Darstellungen der Zeichen der zugewiesenen Aufstiegs- und Abstiegsnamen der Beziehung. Während der Anzeige dieses Bildschirms führt die Betätigung der Funktionstaste 204-9 (Modifizieren) zu einem Übergang zu einem Bildschirmformat MODIFY (über Mittel, die in meiner gleichzeitigen Anmeldung beschrieben sind). In diesem Format sind Darstellungen der Zeichen der Aufstiegs- und Abstiegsnamen in offenen Bereichen angezeigt, also in Bereichen, die vom Benutzer über die Tastatur 20 geändert werden können. Der Benutzer kann dann Schreibmaschinentasten 200 der Tastatur 20 benutzen und modifizierte Beziehungsnamen darstellende Signale eingeben. Signale, welche die Zeichen der zugewiesenen (Standard-)Namen oder, wenn vorhanden, der modifizierten Namen darstellen, sind im Datenelement 524 der durch die ID-Nr. indizierten Datenstruktur Beziehungsattribute 520 im Datendiktionär 506 der Datenbank 516 gespeichert. Die Namen der Relationen, die durch Attribute 520 zusammengehören, sind in 527 gespeichert.
Wenn der Aufbau des Datendiktionärs 506 beendet ist, kann die Operation entsprechend dem nächsten Baustein 508 beginnen.

Baustein Anwendungskonstruktion 508

In Weiterführung der detaillierteren Betrachtung meiner Erfindung: Ein Baustein Anwendungskonstruktion 508 ist im Programmspeicherteil der Speichervorrichtung 17 vorgesehen. Im Betrieb entsprechend diesem Baustein kann das Datenverarbeitungssystem 10 auch mit Vorteil den relationalen Operator meiner gleichzeitigen Anmeldung verwenden, der Operationen hinsichtlich der Meta-Datenbank 506 und der Bildschirmdatei AB 510 (Fig. 16) ausführt. Jedoch können die Operationen, die das Datenverarbeitungssystem 10 zur Erfüllung der nachstehend beschriebenen Funktionen ausführt, auch von anderen zweckdienlichen Einrichtungen durchgeführt werden. Grob gesagt, im Betrieb entsprechend dem Baustein Anwendungskonstruktion baut das DV-System 10 in der Speichervorrichtung 17 eine spezielle Bildschirmdatei 512 auf, die an die Pflege einer oder mehrerer Zielrelationen in der Datenbank 516 angepaßt ist. Diese Operation wird nun näher untersucht.
Der Betrieb entsprechend dem Baustein 508 beginnt, nachdem der Endgerätebenutzer eine Datenbank ausgewählt hat. Die Datenbank muß definiert worden sein, das heißt, ihre Meta-Datenbank oder Datendiktionär 506 muß definiert und sie bzw. ihn darstellende Signale müssen in der Speichervorrichtung 17 in der weiter oben beschriebenen Weise gespeichert worden sein, und insbesondere müssen die Aufstiegs- und Abstiegsnamen aller definierten Beziehungen definiert und Darstellungen der Zeichen der Namen in 524 gespeichert worden sein.
Mit Steuerung durch den Baustein Anwendungskonstruktion 508 führt das Datenverarbeitungssystem 10 Operationen an den Eingangsparametern $database und $screen-file aus. Der spezielle Wert von $database bezeichnet die vom Anwenderprogramm zu verwaltende Datenbank 516. Es wird auf den Datendiktionär 506 für diese Datenbank zugegriffen. Der spezielle Wert von $screen-file bezeichnet die Bildschirmdatei AB 510.
Zugegriffen wird auch auf die @Default-Bildschirmgruppe 511. Die Bildschirmgruppe 511 liefert archetypische (Vorgabe)- Bildschirmformate 521 für jeden Bildschirmtyp (LIST, DISPLAY, SELECT, ADD, MODIFY, DELETE) und, jedem Bildschirmformat zugeordnet, eine archetypische POP-Tabelle 509. Die archetypischen Bildschirmformate sind den in Fig. 8, 13 und 14 dargestellten ähnlich, es fehlen ihnen jedoch spezifische Darstellungen des Namens der Zielrelation und der Namen der Spalten oder Domänennamen sowie andere Informationen bezüglich der Funktionstasten. Derartige Darstellungen sind durch offene Elemente ersetzt. Die POP-Tabelle 509 spezifiziert diejenigen Funktionstasten 204, die in einem bestimmten Format dargestellt werden können und enthalten, wie weiter oben beschrieben, für jede Funktionstaste Signale, die für die Ausführung der von dieser Taste gewählten Operation notwendig sind. Die POP-Tabelle ist nicht vollständig, insoweit Funktionstasten für absteigende Operationen, wie weiter unten beschrieben, in einer späteren Phase hinzugefügt werden können.
Weil die Bildschirmgruppe 511 getrennt von der Bildschirmdatei AB 510 vorgesehen ist, können die Formate 523 vom Benutzer insgesamt aufbereitet werden; beispielsweise kann die Sprache des feststehenden Textes geändert werden. Einem bestimmten Datendiktionär 506 ist eine bestimmte @ Default-Bildschirmgruppe 511 zugeordnet.
Die Bildschirmdatei 510, die vom Datenverarbeitungssystem 10 nach Aufruf durch den Baustein Anwendungskonstruktion 508 entsprechend den Bausteinen gemäß Fig. 7a bearbeitet wird, stellt AB-Bildschirmformate 523 bereit, die für die Anzeige von aus dem Datendiktionär 506 abgerufenen Treffer-Datensätzen benutzt wird, sowie mit ihnen verbundene Steuersignale 525, die POP-Tabellen, Bildschirmmaps, Zur-Anzeige-Listen und andere Datenstrukturen umfassen, wie weiter oben beschrieben wurde.
Zuerst entsprechend dem Baustein Anzeige 550 des Bausteins Anwendungskonstruktion 508 arbeitend und die Eingabeparameter $database benutzend, welche die Datenbank 516 bezeichnen, ruft das Datenverarbeitungssystem 10 (mit Vorteil die Relationsoperator-Einrichtung gemäß meiner gleichzeitigen Anmeldung verwendend) aus dem Datendiktionär 506 Signale auf, die eine Liste von Namen von Relationen (Grundtabellen oder Ansichten) in der Datenbank 516 darstellen. Darstellungen der Namen werden in einem ersten Bildschirmformat aus den AB-Formaten 523 angezeigt, wie in Fig. 23 dargestellt. Durch Positionieren der Bildschirm-Schreibmarke und Betätigen der ENTER-Taste 206 (Fig. 5) kann der Benutzer eine Anfangstabelle wählen.
Weiter im Betrieb entsprechend dem Baustein 550 des Bausteins 508 benutzt das Datenverarbeitungssystem 10 den Namen der gewählten Anfangstabelle, um vom Deskriptor 570 für diese Tabelle eine Liste von Beziehungs-ID-Nr. für Beziehungen zu erhalten, in denen diese Tabelle partizipiert. Die Beziehungskennummern (ID-Nr) werden zum Indizieren der Datenstruktur 520 im Datendiktionär 506 und zum Aufrufen von Signalen benutzt, welche die Namen der zusammengehörigen Tabellen aus 527 darstellen. Darstellungen der Namen werden in einem zweiten Bildschirmformat aus den AB-Formaten 523 angezeigt, wie es in Fig. 24 dargestellt ist.
Durch Betätigen der ENTER-Taste 206 und Positionieren der Bildschirm-Schreibmarke mittels der Tasten 208 (Fig. 5) kann der Benutzer eine oder mehrere zusammengehörige Tabellen (Relationen) zum Einbinden in das Anwendungsprogramm auswählen. Bei der vorliegenden Beschreibung ist die Tabelle, die anfänglich angezeigt wird (oder deren Namen anfänglich angezeigt wird), als die "Ausgangs"relation bezeichnet, wogegen eine angewählte zusammengehörige Tabelle, die später angezeigt wird (oder deren Name später angezeigt wird) als "Bestimmungs"relation bezeichnet wird.
Dieser Vorgang wird wiederholt, entweder bis keine zusammengehörenden Tabellen nicht angewählt sind, oder bis der Benutzer die Funktionstaste 204-6 Create Program (Erzeuge Programm) während der Anzeige des in Fig. 24 dargestellten Bildschirmformats betätigt.
Die archetypischen Bildschirmformate 521 in der Bildschirmgruppe 511 werden als nächstes zwecks Änderung kopiert. Signale, welche die vom Benutzer während zuvor beschriebenen Anzeigen ausgeführten Auswahlen darstellen, werden dann von dem entsprechend dem Baustein Erzeuge Bildschirmformat 552 arbeitenden Datenverarbeitungssystem 10 zum Modifizieren der kopierten archetypischen Bildschirmformate 521 benutzt, um Bildschirmgruppen für alle ausgewählten Tabellen zu definieren. Eine Bildschirmgruppe 522 ist für die "Ausgangs"relation vorgesehen und eine Bildschirmgruppe 532 wird für jede "Bestimmungs"relation erzeugt. Die im Datendiktionär 506 gespeicherten Signale werden aufgerufen und zu diesem Zeitpunkt für die Darstellung von Bildschirmfeldern, Spaltenüberschriften, Aufforderungszeichen und anderen feststehenden Text benutzt. Die modifizierten Bildschirmformate 522 und 532 werden als Teil der konstruierten Bildschirmdatei 512 gespeichert.
Außerdem sind im Baustein Erzeuge Bildschirmdatei 552 Mittel vorgesehen zum Konstruieren innerhalb der Bildschirmdatei 512 und mit Bezug auf die archetypischen POP 509 und den Datendiktionär 506 der zugehörigen Steuersignale bei 530 und 534, die POP(Prozedur Operation) -Tabellen, PSMPS (Prozedur Bildschirmmaps) und andere Elemente umfassen, die in meiner gleichzeitigen Anmeldung näher beschrieben sind, und den definierten Bildschirmgruppen zugeordnet sind und für die einwandfreie Benutzung solcher Bildschirmgruppen erforderlich sind. Zum Beispiel werden solche, im Datendiktionär gespeicherte Signale, wie jene, die Art und Länge der Felder definieren, aufgerufen und zum Konstruieren einer passenden Bildschirmabbildung benutzt.
Bei diesem Vorgang werden die Beziehungsattribute von 520 in dreifacher Weise benutzt. Erstens werden die Bildschirmformate 522 in der Bildschirmgruppe für die Ausgangsrelation so modifiziert, daß die Darstellung einer Funktionstaste 204 in Verbindung mit dem Namen der Beziehung (von 524) mit der Bestimmungsrelation angezeigt wird. Weil der Name der Ausgangsrelation bekannt ist, kann der passende Aufstiegs-/Abstiegsname für die Richtung der Beziehung ausgewählt werden. Ferner wird die POP-Tabelle in den Steuersignalen 530 für jedes Bildschirmformat 522 so modifiziert, daß es Signale enthält, die eine für diese Funktionstaste definierte Operation darstellt. Die oper.action ist "descend# via screen#" (Abstiegs- Nr. über Bildschirm-Nr.); der oper.name ist der Name der Beziehung, kopiert aus dem Datenspeicherelement 524. Jede Abstiegsoperation ist eindeutig durch "descend#" gekennzeichnet, die eine (weiter unten beschriebene) eindeutige PDSC- Datenstruktur 538 indiziert. Auf einem bestimmten Bildschirmformat kann mehr als ein absteigender Übergang definiert sein; jeder ist durch eine eindeutige descend# in der pop.oper.action gekennzeichnet.
Zweitens wird in der Bildschirmdatei 512 eine zusätzliche Bildschirmgruppe 532 durch Modifizieren einer Kopie der archetypischen Bildschirmgruppe 521 in Übereinstimmung mit den Informationen im Datendiktionär 506 konstruiert, welche, wie weiter oben beschrieben, die Bestimmungsrelation (Bildschirmfelder, Relationsname, Spaltennamen u.dgl.) beschreiben. Geeignete POP, PSMP und andere Steuerdatenstrukturen werden definiert und sie darstellende Signale werden in der Bildschirmdatei 512 bei 534 gespeichert.
Drittens erzeugt das entsprechend dem Baustein Anwendungskonstruktion 508 arbeitende Datenverarbeitungssystem 10 (durch Zuweisung von Speicherplatz und Speichern von Signalen in ihm) eine PDSC-Datenstruktur 538 in der Bildschirmdatei 512. Eine bestimmte PDSC-Datenstruktur wird für jeden gewählten Übergang von einer ersten oder "Ausgangs"relation zu einer zweiten oder "Bestimmungs"relation und, wie oben angegeben, durch eine eindeutige descend# gekennzeichnet.
Gemäß Fig. 22 umfaßt die PDSC-Datenstruktur 538 zwei Teile 540 und 542. Im Teil 540 sind Signale vorgesehen, die Steuerinformationen darstellen. Im zweiten Teil sind Signale vorgesehen, die einen Cursor darstellen, der nach der Bestimmungsrelation definiert, aber nicht vollständig spezifiziert ist. Der Auswahlbereich oder die "Verwendungsklausel" dieses Cursors enthält einen oder mehrere Speicherplätze, durch Parameter @1, @2, ... gekennzeichnet, wogegen die Signale des Steuerteils 540 vom Datenverarbeitungssystem 10 (zu einem späteren Zeitpunkt, wie noch erläutert wird) verwendet werden, um in die Speicherplätze zu bringende Signale zu erhalten, die Werte für diese Parameter darstellen. Insbesondere müssen die "Vater"-Beziehungsfelder in den Cursor an den Speicherplätzen @1, @2, ... kopiert werden, um über diesen Cursor die zugehörigen " Sohn" -Treffer-Datensätze abzurufen. Beim Aufbauen der PDSC-Datenstruktur 538 wird die Spezifikation der Felder, die durch die Parameter @1, @2, ... gekennzeichnet sind, und der Steuerinformationssignale im Teil 540 von den Attributen der bei 520 im Datendiktionär 506 der Speichervorrichtung 17 gespeicherten Beziehung abgeleitet. Die Aufgabe der Parameter @1, @2, ... wird aus dem Folgenden deutlich.
Die PDSC-Datenstruktur 538 ist in der aufgebauten Bildschirmdatei 512 gespeichert.
Durch die Auswahl einer Anfangstabelle aus der Anzeige gemäß Fig. 23 definiert der Benutzer einen Wert für die "Initial Table" (Anfangstabelle) in der Datenstruktur PDEF 153 der Bildschirmdatei 512. Eine Standardreihenfolge der Bildschirmformatpräsentation wird durch das Datenverarbeitungssystem 10 beim Arbeiten entsprechend dem Baustein Erzeuge Bildschirmformat 552 definiert.
Vorteilhafterweise kann im Baustein Anwendungskonstruktion 508 ein weiterer Baustein "Screen Edit" (Bildschirmaufbereitung) 554 vorgesehen sein. Wird während der Anzeige des Bildschirmformats gemäß Fig. 23 die Funktionstaste 204-9 "Edit Screen Sets" (Aufbereite Bildschirmgruppen) betätigt, arbeitet das Datenverarbeitungssystem 10 entsprechend diesem Baustein, und mit dessen Steuerung werden dem Benutzer Darstellungen der Bildschirmformate 522 und 532 in "Prototyp"form angezeigt, das heißt, mit spezifischen Überschriften und Relationsnamen aus dem Datendiktionär 506, aber mit X oder anderen Symbolen für die Darstellung der Treffer-Datensätze. Zu diesem Zeitpunkt werden tatsächlich keine Treffer-Datensätze aus der Datenbank 516 abgerufen. Für die Bearbeitung des Aussehens der Bildschirmformate sind entsprechende Mittel vorgesehen. Außerdem kann die Reihenfolge der Formatpräsentation durch den Benutzer geändert werden. Die Darstellung der Funktionstasten auf jedem Format kann ebenfalls verändert werden. Um beispielsweise die Entfernung von Treffer-Datensätzen zu einem späteren Zeitpunkt zu verhindern, kann die Funktionstaste für die Entfern-Operation aus dem Format weggelassen werden.

Interpretation des konstruierten Programms

Nach vollständiger Definition der aufgebauten Bildschirmdatei 512 und nach Speicherung der sie darstellenden Signale im Arbeitsspeicherteil der Speichervorrichtung 17 bildet die aufgebaute Bildschirmdatei 512 effektiv ein Anwendungsprogramm für die interaktive, nicht verfahrensorientierte Pflege der Datenbank 516, für die sie aufgebaut wurde. Wenn dieses Anwendungsprogramm benutzt werden soll, muß ein Interpretierprogramm verwendet werden; insbesondere dient der in meiner gleichzeitigen Anmeldung beschriebene Baustein PACE RUN als solches Interpretierprogramm. Zum Zwecke der Interpretierung der die "descends" (Abstiege) darstellenden Signale sind im Programmspeicherteil der Speichervorrichtung 17 zwei zusätzliche (in meiner gleichzeitigen Anmeldung nicht beschriebene) Programmbausteine vorgesehen: Baustein PXIDSC 600 und Baustein WZFETCH(qid) 602. Außerdem ruft der Baustein DO DSC 107 im Abrufprogramm den Baustein DO QUERY 108 auf.
Der Baustein WZFETCH 602 (Hole) ruft den Baustein WZRETRIEVE 118 (Abrufen) auf, um aus der Datenbank 516 einen einzelnen Treffer-Datensatz wiederzugewinnen, ohne ihn anzuzeigen. Der Parameter "qid" kennzeichnet die beim Abruf zu benutzende Abfrage. Andere spezielle Merkmale des Bausteins FETCH gehören hier nicht zur Sache.
Bei der Abarbeitung des konstruierten Anwendungsprogramms greift das Datenverarbeitungssystem 10 im Betrieb entsprechend dem Baustein PACE RUN in der in meiner gleichzeitigen Anmeldung beschriebenen Weise auf die Bildschirmdatei 512 zu und eröffnet sie. Die in PDEF 153 gespeicherten Signale werden für den Zugriff auf ein anfängliches Bildschirmformat 522 und eine Ausgangsrelation (Anfangstabelle) aus der Datenbank 516 benutzt. Wenn das Format während der vorhergegangenen Operation des Datenverarbeitungssystems entsprechend dem Baustein 508 Anwendungskonstruktion so modifiziert wurde, enthält das anfängliche Bildschirmformat eine Darstellung einer Funktionstaste 204 für einen absteigenden Übergang auf eine Anzeige einer zugehörigen Relation. Durch den Cursor 158 definierte Treffer-Datensätze werden aus der anfänglichen Zielrelation abgerufen und mit dem anfänglichen Bildschirmformat zu einem gespeicherten Bildschirmbild kombiniert.
Wie in meiner gleichzeitigen Anmeldung beschrieben, wird das gespeicherte Bildschirmbild angezeigt und Signale, die entweder eine Aufzählung oder eine charakteristische Auswahl einer Ergebnisrelation darstellen, werden über die Tastatur 20 eingegeben und im Arbeitsspeicher 17 gespeichert. Eingangssignale, die eine Auswahl einer Operation durch Betätigen einer Funktionstaste 204 auf der Tastatur 20 darstellen, werden in der Datenstruktur FOR 164 im Datenelement for.fpf-key gespeichert.
Wenn die vom Benutzer über die Tastatur 20 eingegebenen Operationswahlsignale die Betätigung der einer spezifischen absteigenden Operation entsprechenden Funktionstaste 204 darstellen, kopiert das entsprechend dem Baustein WZSCRIO 120 arbeitende Datenverarbeitungssystem 10 die die pop.oper für diese Funktionstaste darstellenden Signale in QUERY.oper, wie weiter oben unter Bezugnahme auf meine gleichzeitige Anmeldung erläutert wurde. Die oper.action für diese Funktionstaste ist "descend# via screen#", welche die spezielle PDSC- Struktur 538 in der Bildschirmdatei 512 identifiziert, die diesem absteigenden Übergang entspricht. Das Datenverarbeitungssystem 10 kehrt dann zum Baustein DO PXI 112 zurück, wobei die die Aktion "descend#" darstellenden Signale im Datenelement ATAB 172 gespeichert werden.
Wenn das Datenverarbeitungssystem 10 entsprechend dem Baustein DO PXI 112 arbeitet, überprüft es die Signale in ATAB 172, wie in meiner gleichzeitigen Anmeldung beschrieben. In diesem Falle arbeitet das Datenverarbeitungssystem 10 in Antwort auf Signale, welche die Aktion "descend#" darstellen, weiter entsprechend dem Baustein PXIDSC 600, um den Baustein FETCH(qid) 602 auf zurufen, der den Baustein RETRIEVE 118 abruft.
Wenn das Datenverarbeitungssystem 10 entsprechend dem Baustein RETRIEVE 118 und entsprechend den gespeicherten Signalen arbeitet, welche die Ergebnisrelation (entweder die markierten Datensätze in der Seen-List 170 oder den modifizierten Cursor in der Datenstruktur 158, wie weiter oben beschrieben) definieren, kopiert es aus der Datenbank 516 Signale, welche den ersten Treffer-Datensatz in der Ergebnisrelation darstellen. Weil die Ergebnisrelation von der "Ausgangs"relation her definiert ist, ist der in Antwort auf FETCH wiedergewonnene Treffer-Datensatz ein Element der Ausgangsrelation, definiert durch die modifizierte, durch qid gekennzeichnete Abfrage. Der abgerufene Datensatz wird nicht angezeigt; er wird im Systempufferspeicher 168 (Fig. 6a) gespeichert. Nach dem Abrufen des Datensatzes ruft PXIDSC 600 den Baustein DO DSC 107 auf.
Beim Arbeiten entsprechend dem Baustein DO DSC 107 und beim Zugriff auf den ersten Teil 540 der PDSC-Datenstruktur 538 kopiert das Datenverarbeitunssystem 10 aus dem abgerufenen Treffer-Datensatz Signale, welche die Werte der Beziehungsfelder darstellen, in die durch die entsprechenden Parameter @1, @2, ... angegebenen Plätze im zweiten Abschnitt 542 der PDSC 538, wie es durch den ersten Teil 540 definiert wurde. Die kopierten Felder sind die Schlüssel, die sowohl in den Vater-Datensätzen wie in den zugehörigen Sohn-Datensätzen vorhanden sind, wie weiter oben beschrieben wurde. Daher bewirken die Werte dieser Felder die Definition der Treffer- Datensätze in der Bestimmungsrelation, welche zugehörig sind. Diese Operation vervollständigt den durch PDSC 538 vorgesehenen Cursor. Der Cursor ist nunmehr vollständig definiert nach der "Bestimmungs"relation.
Signale, die den vollständigen Cursor aus PDSC 538 darstellen, werden nunmehr in eine Datenstruktur CURSOR 158 gebracht, und der Baustein DO QUERY wird aufgerufen, um den Cursor zu eröffnen und eine neue Datenstruktur QUERY 162, die dem neuen Cursor entspricht, zu definieren, wie dies in meiner gleichzeitigen Anmeldung beschrieben wurde. (Der nach der "Ausgangs"relation definierte Cursor bleibt offen.) Auf die gegenwärtige Bildschirmdatei wird weiter zugegriffen; die neue screen# (Bildschirm-Nr.) ergibt sich aus der absteigenden Aktion (descend# via screen#). Die Arbeitsweise des Datenverarbeitungssystems entsprechend diesem Baustein in bezug auf einen bestimmten Cursor wurde im einzelnen in meiner gleichzeitigen Anmeldung beschrieben.
Das Ergebnis im vorliegenden Fall ist, daß die Datensätze in der "Bestimmungs"relation, definiert durch den Cursor (aus PDSC 538 und vervollständigt mit spezifischen Beziehungsfeldwerten aus dem abgerufenen Treffer-Datensatz von der "Ausgangs"relation), sequentiell aus der Datenbank 516 abgerufen werden, mit einem Bildschirmformat der Bildschirmgruppe 532 in der Bildschirmdatei 512 kombiniert und für den Benutzer am Sichtgerät 18 angezeigt werden. Der Benutzer kann in der in meiner gleichzeitigen Anmeldung beschriebenen Weise Funktionstasten 204 betätigen, um die Treffer-Datensätze, deren Darstellungen angezeigt werden, zu modifizieren. Beispielsweise kann der Benutzer Treffer aktualisieren oder entfernen oder neue zur "Bestimmungs"relation der Datenbank 516 hinzufügen.
Wenn der Benutzer die gewünschte Anzahl Treffer-Datensätze in der "Bestimmungs"relation betrachtet und alle gewünschten Operationen an ihnen ausgeführt hat, bewirkt die Betätigung der Funktionstaste Zurück 204-16, daß vom Baustein DO QUERY 108 auf das Programm zurückgekehrt wird, das ihn aufgerufen hat. Wenn alle Treffer-Datensätze in der Bestimmungsrelation betrachtet worden sind, wird alternativ ein solcher Rücksprung automatisch durch Entstapeln der Rekursion ausgeführt. Der nächste Treffer-Datensatz der "Ausgangs"relation wird dann durch den Baustein FETCH 602 aufgerufen. Der Abstiegsvorgang wird dann für die Treffer-Datensätze von der "Bestimmungs"relation wiederholt, die zum nächsten Treffer-Datensatz der "Ausgangs"relation gehören. Wenn alle zusammengehörigen Treffer-Datensätze für alle Treffer-Datensätze der Ausgangsrelation betrachtet worden sind, wird die Arbeitsweise entsprechend dem Baustein WZPXI 114 in bezug auf den Cursor für die Ausgangsrelation wiederaufgenommen. Der Bildschirm LIST wird erneut angezeigt, wobei auf ihm Elemente der Ausgangsrelation dargestellt sind.

Arbeitsweise

Ein Beispiel der vorstehend angegebenen Arbeitsweise wird nun anhand der beispielhaften Datensätze gemäß Fig. 17 beschrieben.
Im Betrieb entsprechend dem Baustein DD Definition 500 und bereit zur Eingabe von Signalen über die Tastatur 20, baut das Datenverarbeitungssystem 10 einen Datendiktionär 506 für die Datenbank "Verkäufe" 516 auf. Während dieser Konstruktion definiert der Benutzer eine Beziehung zwischen den Kunden- Datensätzen und den Auftrags-Datensätzen. Die Kunden-Tabelle ist als Vatertabelle definiert; das Feld Kunden-Nr. ist als das Vaterbeziehungs-Feld definiert. Diese Definitionen darstellende Signale sind im Attributspeicher 520 gespeichert. "Kunde" ist als der aufsteigende Name und "Aufträge" als der absteigende Name der Beziehung gespeichert, und die Zeichen dieser Namen darstellende Signale sind bei 524 gespeichert. Diesen Attributen ist eine Beziehungs-ID-Nr. zugeordnet, die ein Index zum Beziehungsattributspeicher 520 ist. Die ID-Nr. ist in einem Deskriptor 570 für die Kunden-Tabelle und auch in einem Deskriptor 570 für die Auftrags-Tabelle gespeichert.
Wenn das Datenverarbeitungssystem 10 als nächstes entsprechend dem Baustein Anwendungskonstruktion 508 arbeitet und in Übereinstimmung mit Eingangssignalen von der Tastatur 20, greift es auf die Bildschirmdatei AB 510 und den Datendiktionär 506 für die Datenbank "Verkäufe" 516 zu. Entsprechend dem Baustein 550 arbeitend und unter Verwendung des relationalen Operators meiner gleichzeitigen Anmeldung zeigt das Datenverarbeitungssystem 10 eine Liste von Tabellennamen (Kunde, Auftrag, Artikel und Teile-Nr.), die aus dem Datendiktionär 506 aufgerufen wurden, in einem Format (wie das in Fig. 23 dargestellte) aus der Bildschirmdatei AB 510 an. Die Kunden-Tabelle wird vom Benutzer als Anfangstabelle gewählt. Diese Tabelle darstellende Signale sind in "Anfangstabelle" der Datenstruktur PDEF 153 gespeichert.
Weiter entsprechend dem Baustein 550 arbeitend, greift das Datenverarbeitungssystem 10 auf den Deskriptor 570 der Kunden-Tabelle im Datendiktionär 506 zu und unter Benutzung der darin gefundenen Beziehungs-ID-Nr. (oder Nrn.) auf den Beziehungsattributspeicher 520. Der Name jeder Tabelle in der Datenbank 516, die mit der Kunden-Tabelle zusammengehört (in diesem Falle nur eine, die Auftrags-Tabelle), wird im Sichtgerät 18 in einem Format ähnlich dem in Fig. 24 dargestellten angezeigt. Die Auftrags-Tabelle wird vom Benutzer als eine zusammengehörige Tabelle gewählt, die in das Anwendungsprogramm aufzunehmen ist.
Das Bildschirmformat LIST wird vom Benutzer als Anfangsbildschirm gewählt. Dieses Format darstellende Signale sind in "Anfangsbildschirm" der Datenstruktur PDEF 153 gespeichert. Entsprechend dem Baustein 552 arbeitend, greift das Datenverarbeitungssystem 10 unter Bezug auf den Datendiktionär 506 auf die §Default-Bildschirmgruppe 511 zu und kopiert und modifiziert die Formate 521 und die POP-Tabellen 509. (Zu diesem Zeitpunkt werden auch weitere Steuerdatenstrukturen, z.B. Bildschirmmaps, konstruiert.) Insbesondere wird das archetypische LIST-Format für die Kunden-Tabelle so modifiziert, daß es eine Funktionstaste vorsieht (z.B. die Funktionstaste 204- 11), die den Zeichen "Aufträge" zugeordnet ist, aus dem Datenelement 524 abgerufen und durch die Beziehungs-ID-Nr. indiziert ist. Die POP-Tabelle für diesen Bildschirm wird so modifiziert, daß sie eine pop.oper "descend#1 via screen#" aufweist. (Der Wert von screen# ist durch den Benutzer zuweisbar; es wird angenommen, daß der LIST-Bildschirm für die absteigende Operation gewählt wird.) Für descend#1 wird eine Datenstruktur PDSC 538 aufgebaut. Diese PDSC-Struktur enthält in ihrem ersten Teil 540 das Paar "@1, customer.customer#". Das heißt, die Kundennummer des Kunden-Datensatzes ist das Beziehungsfeld für diese Beziehung und ergibt sich aus den Signalen, die in den Attributen für die Beziehung zwischen Kunden- und Auftrags-Tabellen gespeichert sind, indiziert durch die Beziehungs-ID-Nr. Im zweiten Teil 542 der PDSC 538 ist ein Cursor vorgesehen, der nach der Auftrags-Tabelle der Datenbank 516 definiert ist, aber ein unvollständiges Beziehungsfeld aufweist, und durch @1 angegeben ist.
Schließlich werden die archetypischen Bildschirmgruppen-Formate 521 und die zugehörigen POP-Tabellen 509 kopiert und so modifiziert, daß für die Bestimmungsrelation die Formate 532 und die Steuersignale 534 entstehen. Der übrige Teil der aufgebauten Bildschirmdatei 512 (wenn vorhanden) ist konstruiert und wird vom Benutzer nach Wunsch verändert.
Zu einem späteren Zeitpunkt initiiert ein Benutzer des Endgerätes vom Datenverarbeitungssystem eine Operation entsprechend PACE RUN 514 und der konstruierten Bildschirmdatei 512. Entsprechend den Signalen in der Datenstruktur PDEF 153 und unter Verwendung des relationalen Operators meiner gleichzeitigen Anmeldung, führt das Datenverarbeitungssystem 10 Operationen zur Anzeige des Bildschirmformats LIST aus den Formaten 522 mit Treffer-Datensätzen aus der Kunden-Tabelle aus. Diese Anzeige weist unter den Darstellungen der wählbaren Operationen die Zeichen "11) Aufträge" auf. Der Benutzer bestimmt spezielle aufgelistete Kunden-Treffer-Datensätze in einer in meiner gleichzeitigen Anmeldung beschriebenen Weise und betätigt die Funktionstaste 204-11. In der in meiner gleichzeitigen Anmeldung beschriebenen Weise werden die eine Betätigung dieser Funktionstaste darstellenden Signale zum Abrufen aus der POP-Tabelle für das Bildschirmformat LIST 522 der entsprechenden pop.oper verwendet, die in qry.oper kopiert wird. Die qry.oper-Aktion ist "descend#1 via LIST screen"; diese wird in die Datenstruktur ATAB 172 kopiert.
Entsprechend PACE RUN arbeitend verwendet das Datenverarbeitungssystem 10 die "descend#1" darstellenden Signale zum Zugriff auf die Datenstruktur PDSC 538, die für diese absteigende Operation zuvor aufgebaut worden ist. Der erste der bestimmten Kunden-Datensätze (aus dem Anfangsbildschirm LIST) wird aus der Datenbank 516 geholt und im Systempufferspeicher 168 gespeichert. Der Wert seines Feldes Kunden-Nr. wird in den durch @1 angegebenen Speicherplatz im PDSC-Teil 542 kopiert, wodurch der Cursor vervollständigt wird. Sodann wird der Baustein DO QUERY 108 für eine Operation an diesem Cursor in einer in meiner gleichzeitigen Anmeldung beschriebenen Weise aufgerufen. Auftrags-Treffer-Datensätze, für die das Beziehungsfeld Kunden-Nr. den Wert hat, der vom Kunden-Datensatz im Systempufferspeicher kopiert wurde, werden abgerufen und dem Benutzer gegenüber in einem Bildschirmformat LIST 532 angezeigt.
Der Benutzer kann an den aufgelisteten Auftrags-Treffer-Datensätzen Operationen in der in meiner gleichzeitigen Anmeldung beschriebenen Weise ausführen. Insbesondere kann der Benutzer solche Treffer-Datensätze modifizieren oder entfernen, oder der Benutzer kann neue Treffer-Datensätze hinzufügen (jedoch abhängig von den Integritätsregeln im Beziehungsattributspeicher 520, die in einer hier nicht beschriebenen Weise erzwungen werden). Sobald alle diese gewünschten Operationen ausgeführt sind, wird der nächste bestimmte Kunden-Datensatz aus dem Anfangsbildschirm LIST geholt, und seine Kunden-Nr. wird in den Speicherplatz @1 des Cursorteils 542 der Datenstruktur PDSC 538 kopiert. Die durch diesen Cursor definierten Auftrags-Treffer-Datensätze werden dann abgerufen. Dieser Vorgang setzt sich fort, bis er bei allen bestimmten Kunden-Datensätzen aus dem Anfangsbildschirm LIST durchgeführt worden ist.
Somit können die Operationen, welche Benutzer meistens an einer Datenbank auszuführen wünschen, alle durchgeführt werden, interaktiv und nicht verfahrensorientiert, durch die Operation des Anwendungsprogramms in Form der aufgebauten Bildschirmdatei 512.
Die Arbeitsweise des Datenverarbeitungssystems gemäß meiner Erfindung bietet somit besonders einfache Mittel für den Nichtprogrammierer zum Erstellen eines Anwendungsprogramms für die interaktive, nicht verfahrensorientierte Pflege einer relationalen Datenbank, einschließlich bequem auszuführender Übergänge auf die Anzeige beliebiger Datensätze, die mit anfänglich angezeigten Datensätzen in Beziehung stehen. Die Erstellung von Anwendungsprogrammen dieser Komplexität und Flexibilität hat bisher den Einsatz von hochqualifizierten Programmierern während einer beträchtlichen Zeitspanne erfordert, und das Endprodukt ist häufig nicht so gut für die eigentlichen Zwecke des Endbenutzers geeignet, wie es durch den Einsatz meiner Erfindung erzielt werden kann.

INTERAKTIVE FEHLERBEHANDLUNGSEINRICHTUNG

Die Programmbausteine, denen gemäß dieser Fig. 7b Speicherplatz im Programmspeicher zugewiesen ist, sind vorstehend vollständig beschrieben worden, ausgenommen der Baustein WZ- FETCH (WZHOLE) 602. Dieser Baustein wird hier näher als weiter oben unter dem Titel WIEDERGEWINNUNG ZUSAMMENGEHÖRIGER DATENSÄTZE beschrieben, wo dieser Baustein dargestellt, aber nur kurz beschrieben ist.
Gemäß Fig. 6b wurden die Datenstrukturen, denen Speicherplatz im Arbeitsspeicher gemäß Fig. 7b zugewiesen ist, vorstehend beschrieben, mit einigen Ausnahmen, die nachstehend beschrieben werden. Insbesondere weist die Datenstruktur TCOM 160 Signale auf, welche die Datenstruktur Status (Zustand) 700 darstellen, und die Datenstruktur QUERY 162 weist ferner Signale auf, die eine Holposition (qry.fch-pos 707) und einen Zeiger @pgm-buf darstellen. Im Arbeitsspeicher ist ein Programmpufferspeicher 703 vorgesehen, auf den @pgmbuf in der Datenstruktur QUERY 162 zeigt. Im Arbeitsspeicher ist eine Datenstruktur Nachrichtendatei 702 vorgesehen. Eine Struktur Datendiktionär 506, die weiter oben unter dem Titel WIEDERGE- WINNUNG VON ZUSMAMENGEHÖRIGEN DATENSÄTZEN näher beschrieben wurde, liefert Beziehungsattribute 520 für jede in der Datenbank definierte Beziehung und Deskriptoren 570 für jede Relation (Tabelle) in der Datenbank. Bei der bevorzugten Ausführungsform ist der Datendiktionär selbst als eine relationale Datenbank modelliert und im Datenbankspeicher vorgesehen, jedoch ist dies für die vorliegende Erfindung nicht wesentlich.
In Fig. 25 ist die Struktur dar Einrichtung WZFETCH 602 näher dargestellt. Im Betrieb entsprechend WZFETCH ist ein erforderliches Eingangssignal zum Datenverarbeitungssystem 10 gemäß Fig. 4 der Parameter $qid, der die Abfrage 162 (Fig. 6b) (und als natürliche Folge den Cursor) kennzeichnet, die den bzw. die speziellen Treffer-Datensätze spezifiziert, der bzw. die aus der physischen Datenbank 150 abzurufen sind. Ohne diesen Parameter kann das Datenverarbeitungssystem nicht entsprechend WZFETCH arbeiten. Außerdem sind drei optionale Parameter vorhanden: $screen-file, screen# (oder $screen-name) und $errors-only. Die ersten beiden dieser Parameter identifizieren die zur Steuerung des Sichtgerätes 18 zu benutzenden speziellen Bildschirmformatsignale (166 gemäß Fig. 6b). Der Parameter $errors-only (nur Fehler) kann einen von zwei Werten (ja oder nein) haben und seine Bedeutung wird nachstehend erläutert.
WZFETCH umfaßt drei Strukturen: einen Haupt-Baustein 704, einen Interaktiv-Baustein 706 und einen Nicht-Interaktiv-Baustein 708.
Wenn entsprechend dem Haupt-Baustein 704 arbeitend, überprüft das Datenverarbeitungssystem 10, ob die Parameter $ screenfile und screen# darstellenden Signale WZFETCH zugeleitet worden sind, und ob der Wert des Parameters $errors-only "ja" oder "nein" ist. Erkannt werden die nachstehenden Bedingungen.
Wenn kein Bildschirmformat identifiziert worden ist, arbeitet das Datenverarbeitungssystem 10 zuerst entsprechend dem Nicht-Interaktiv-Baustein 708. Ist ein Bildschirmformat identifiziert worden und ist $errors-only = ja, überprüft das dann durch den Haupt-Baustein 704 gesteuerte Datenverarbeitungssystem 10 Signale, die in der Statusstruktur 700 der Datenstruktur TCOM 160 (Fig. 6b) vorgesehen sind. Diese Signale werden in einer noch zu beschreibenden Weise bereitgestellt. Zeigt der durch diese Signale dargestellte Wert einen Fehler an, der zuvor in einer noch zu beschreibenden Weise festgestellt wurde, arbeitet das Datenverarbeitungssystem 10 weiter entsprechend dem Interaktiv-Baustein 706. Zeigt der durch die Statusstruktur-Signale dargestellte Wert keinen Fehler an, arbeitet das Datenverarbeitungssystem 10 weiter entsprechend dem Nicht-Interaktiv-Baustein 708.
Wenn schließlich ein Bildschirmformat identifiziert worden ist und $errors-only = nein ist, arbeitet das Datenverarbeitungssystem 10 weiter mit Steuerung durch den Interaktiv-Baustein 706.
Der Nicht-Interaktiv-Baustein 708 ruft den Baustein WZ- RETRIEVE 118 (Fig. 7b) auf; wie weiter oben erläutert und gemäß meiner gleichzeitigen Anmeldung, ruft das entsprechend dem Baustein 118 arbeitende Datenverarbeitungssystem 10 die Betriebssystem-Zugriffsmethode auf, um aus der Datenbank 150 Signale zu kopieren, die einen durch den gegenwärtigen Cursor definierten Treffer-Datensatz darstellen. Die kopierten Signale werden in den Systempufferspeicher 168 (Fig. 6b) gebracht. Nach Rückkehr zum Nicht-Interaktiv-Baustein 708 kopiert das Datenverarbeitungssystem 10 die abgerufenen Signale in den Programmpufferspeicher 703 (Fig. 6b) und erhöht die qry.fch-pos-Signale in 707. Das System 10 kehrt dann zur Arbeitsweise entsprechend dem Baustein zurück, der, wie weiter unten beschrieben wird, WZFETCH aufgerufen hatte.
Wenn das Datenverarbeitungssystem 10 alternativ nach dem Interaktiv-Baustein 706 arbeitet, leitet es zuerst von den Eingangsparametern $screen-file- und $screen# Signale für den Zugriff auf die zum Steuern des Sichtgerätes 18 zu benutzenden Bildschirmformatsignale 166 ab. Wenn zu diesem Zeitpunkt notwendig, ruft das Datenverarbeitungssystem 10 den Baustein WZ OPEN SCREEN-FILE 106 (Fig. 7b) auf. Als nächstes überprüft das Datenverarbeitungssystem 10 die Signale, welche die Status-Datenstruktur 700 in TCOM 160 bilden.
Zeigen diese Signale nicht an, daß zuvor ein Fehler (in einer noch zu beschreibenden Weise) festgestellt wurde, ruft das Datenverarbeitungssystem 10 den Baustein WZRETRIEVE 118 auf, z.B. im Nicht-Interaktiv-Baustein 708, um aus der Datenbank 150 Signale zu kopieren, die einen Treffer-Datensatz darstellen, der durch die durch $qid identifizierte Abfrage spezifiziert wurde und auf die qry.fch-pos zeigt. Das System 10 kopiert dann die Signale aus dem Systempufferspeicher 168, in den sie vom System 10 während des Arbeitens entsprechend WZ- RETRIEVE gebracht wurden, in den Programmpufferspeicher 703 und erhöht die Signale, welche qry.fch-pos 707 bilden.
Wenn die Signale der Status-Datenstruktur bei 700 angeben, daß zuvor ein Fehler festgestellt wurde, kopiert das Datenverarbeitungssystem 10 Signale, welche den zuvor aus dem Systempufferspeicher 168 in den Programmpufferspeicher 703 abgerufenen Treffer-Datensatz darstellen. WZRETRIEVE wird nicht aufgerufen.
In beiden Fällen arbeitet das Datenverarbeitungssystem 10 dann entsprechend den in meiner gleichzeitigen Anmeldung näher beschriebenen Bausteinen WZSCRLOD 116 und WZSCRIO 120 des Bildschirm-Dienstprogramms, die das Datenverarbeitungssystem mit dem Sichtgerät 18 so steuern, daß sie Darstellungen des Treffer-Datensatzes im Programmpufferspeicher 703 anzeigen.
Im Falle eines Fehlers wird ein von den Zustandssignalen bei 700 abgeleitetes Fehlerparametersignal von dem entsprechend den Bildschirm-Dienstprogrammbausteinen arbeitenden Datenverarbeitungssystem 10 verwendet, um aus der Nachrichtendatei 702 Signale zu kopieren, die anzeigbare Zeichen darstellen, welche eine dem bestimmten Fehler entsprechende Fehlermeldung bilden. Somit werden Darstellungen des Treffer-Datensatzes und der Fehlermeldung entsprechend den Formatsignalen 166 am Sichtgerät 18 angezeigt.
Wie in meiner gleichzeitigen Anmeldung erläutert, werden in jedem Interaktiv-Fall ein Bildschirmbild darstellende Signale gespeichert und vom durch das Betriebssystem 100 gesteuerten Datenverarbeitungssystem 10 zum Steuern des Sichtgerätes 18 verwendet. Zu diesem Zeitpunkt kann der Dialogbenutzer des Datenverarbeitungssystems Tasten auf der Tastatur 20 betätigen, welche die gespeicherten Bildschirmbildsignale modifizieren und eine gewählte Operation darstellende Operationswahlsignale eingeben.
Wenn das Datenverarbeitungssystem entsprechend dem Baustein WZSCRIO 120 und dem von diesem aufgerufenen Baustein WZFORMS 122 arbeitet, werden Fehler des Typs festgestellt, der weiter oben als Verletzung von Feldbedingungen beschrieben wurde. Wenn der Benutzer beispielsweise eine Änderung des Bildschirms versucht, um Darstellungen von alphabetischen Zeichen in einem Feld zu zeigen, das im Deskriptor 570 für den Datensatz als numerisch spezifiziert ist, wird dieser Fehler entdeckt, und dem Benutzer gegenüber wird eine Darstellung einer Nachricht (aus der Nachrichtendatei 702) angezeigt. Bis zur interaktiven Korrektur dieses Fehlers kehrt das System 10 nicht aus der Arbeitsweise entsprechend WZFORMS 122 zurück.
Nach Rücksprung von den Bildschirm-Dienstprogrammbausteinen rücksetzt das Datenverarbeitungssystem die Signale der Status-Datenstruktur 700, die keinen Fehler auf der Integritäts- Ebene anzeigen, und springt auf den Interaktiv-Baustein 706 zurück. Zu diesem Zeitpunkt sind in qry.oper Signale vorhanden, welche die betätigte Funktionstaste 204 der Tastatur 20 darstellen.
Im weiteren Betrieb entsprechend dem Interaktiv-Baustein 706 überprüft das Datenverarbeitungssystem 10 die Signale, welche die vom Dialogbenutzer gewählte Operation darstellen (Eingabe durch eine betätigte Funktionstaste 204). Bestimmte Operationen (Rollen der Anzeige, Überspringen, Wiederholen, Weiter sowie andere Operationen, die hier nicht zur Sache gehören), können vom Datenverarbeitungssystem 10 ausgeführt werden, während es entsprechend dem Interaktiv-Baustein 706 arbeitet. Bei anderen muß das Datenverarbeitungssystem 10 zu einem vorausgehenden Baustein zurückkehren. FETCH liefert stets $ Status-Signale (Abfrageende oder Erfolg).
Es wird nun die Arbeitsweise entsprechend WZFETCH beschrieben. Es wird auf Fig. 7b verwiesen. Abgesehen von der absteigenden Operation, die hier nicht beschrieben wird, ist der Zusammenhang, in dem das Datenverarbeitungssystem 10 entsprechend WZFETCH arbeitet, ganz allgemein der, in dem ein modifizierter Cursor während einer vorhergehenden Operation des Datenverarbeitungssystems entsprechend dem relationalen Operator meiner gleichzeitigen Anmeldung geschaffen wurde. Der modifizierte Cursor spezifiziert eine Ergebnisrelation von Treffer-Datensätzen. Ferner hat der Dialogbenutzer eine Funktionstaste 204 der Tastatur 20 betätigt, die eine der Übergangsoperationen anwählt, die vom System 10 nicht bearbeitet werden können, wenn es entsprechend den Bausteinen WZDISP, WZSELECT oder WZPXI gemäß Fig. 7b arbeitet. Insbesondere sind solche Operationen Übergänge zu den Bildschirmformaten 166 Hinzufügen, Modifizieren oder Entfernen oder ein absteigender Übergang zur Anzeige von zusammengehörigen Treffer-Datensätzen, wie es weiter oben unter dem Titel WIEDERGEWINNUNG VON ZUSAMMENGEHÖRIGEN DATENSÄTZEN beschrieben wurde.
Beim Betrieb in diesem Zusammenhang kehrt das Datenverarbeitungssystem 10 zum Baustein DO PXI in PACE RUN oder zu anderen Abrufprogrammen zurück. Signale, die einen modifizierten Cursor und eine gewählte Operation darstellen, sind im Arbeitsspeicher vorhanden.
Wenn das Datenverarbeitungssystem 10 entsprechend dem Baustein DO PXI 112 arbeitet, überprüft es die die gewählte Operation darstellenden Signale. Ist die Operation ein Abstieg, wird sie wie weiter oben beschrieben abgearbeitet. Ist die Aktion ein Übergang zu den Bildschirmformaten Hinzufügen, Modifizieren oder Entfernen, ruft DO PXI, immer noch in PACE RUN oder einem anderen Abrufprogramm, den Baustein DO UPDATE 126 auf.
Der Fall mit dem Bildschirm Hinzufügen wird in Einzelheiten hier nicht beschrieben. Kurz gesagt: Ein Standard-Hinzu-Bildschirm kann mit Vorteil vom Benutzer interaktiv definiert werden, wobei bestimmte offene Felder mit charakterisierenden Informationen darin angezeigt werden. Zu diesem Zweck arbeitet das System 10 entsprechend WZFETCH, aber statt einen Treffer-Datensatz aus der Datenbank 150 abzurufen, ruft es einen Standard-Datensatz (800) ab, der charakterisierende Standardinformationen enthält.
Bei den Bildschirmformaten Modifizieren oder Entfernen 166 ruft das entsprechend dem Baustein DO UPDATE 126 arbeitende Datenverarbeitungssystem 10 WZFETCH auf. Wenn der Statuswert Abfrageende ist, kehrt das System 10 zum Baustein DO PXI 112 zurück.
Wenn der Übergang zu einem Bildschirm Modifizieren oder Entfernen vom Benutzer während der Betrachtung eines Bildschirmformats Anzeige 166 gewählt wurde, das eine Darstellung eines einzelnen Treffer-Datensatzes anzeigt, wird das Datenverarbeitungssystem 10 entsprechend WZFETCH arbeiten, um diesen Treffer-Datensatz für die Anzeige im Bildschirmformat Modifizieren oder Entfernen zu erhalten. Das Bildschirmformat Modifizieren oder Entfernen wird vom Datenverarbeitungssystem 10 beim Arbeiten entsprechend dem Interaktiv-Baustein 706 verwendet; die Darstellung des Treffer-Datensatzes wird für den Benutzer angezeigt. Bei einer Modifizier-Operation kann der Benutzer die Felder des dargestellten Treffer-Datensatzes interaktiv modifizieren und durch Betätigen der Eingabe-Taste 206 die Operation zum Modifizieren der entsprechenden Treffer-Datensatz-Signale in der Datenbank anwählen. (Es sei darauf hingewiesen, daß die Änderung der Darstellung an sich nicht die physischen Datensätze in der Datenbank verändert; dies muß in einer getrennten Operation, nach deren Freigabe, geschehen, wie noch zu beschreiben ist.) Alternativ kann der Benutzer die Funktionstaste 204-1 zum Überspringen des Datensatzes oder die Funktionstaste Zurück 204-16 betätigen.
Das Datenverarbeitungssystem 10 kehrt dann zum Baustein DO UPDATE 126 zurück, der den Baustein WZUPDATE 115 aufruft. Für die Zwecke der vorliegenden Beschreibung sei angenommen, daß der Baustein WZUPDATE 115 Einrichtungen für die Durchführung sowohl von Modifizier- als auch von Entfern-Operationen bereitstellt. Im Betrieb entsprechend dem Baustein 126 greift das Datenverarbeitungssystem 10 auf Integritätsbedingungen bildende Signale vom Datendiktionär-Attributspeicher 520 zu (vorteilhafterweise sind solche Signale zuvor in den Arbeitsspeicher kopiert worden). Das Datenverarbeitungssystem 10 verwendet solche Integritätsbedingungssignale zusammen mit Benutzereingaben darstellenden Signalen (Operationswahl, mit Änderung des Treffer-Datensatzes bei einer Modifizier-Operation), um die Gültigkeit der angewählten Operation zu überprüfen. Die Signale im Programmpufferspeicher 703 bilden den Treffer-Datensatz, in bezug auf den die Operation ausgeführt werden wird.
Wenn die angewählte Operation nicht gültig ist, wird sie nicht ausgeführt; jedoch werden die Fehlerbedingung darstellende Signale durch das System 10 generiert und in der Status-Datenstruktur 700 in TCOM 160 gespeichert; danach kehrt das System 10 nach DO UPDATE zurück. Der zu diesem Zeitpunkt festgestellte Fehlertyp wurde weiter oben bei dem Beispiel beschrieben, wie ein Vater-Treffer-Datensatz zu entfernen sei, mit dem Sohn-Treffer-Datensätze durch eine Beziehung verbunden sind, wenn die Beziehungsattribute 520 eine solche Entfernung verhindern.
Außerdem werden vorteilhafterweise zu diesem Zeitpunkt andere Fehler ebenfalls festgestellt. Zum Beispiel kann ein bestimmter Treffer-Datensatz "blockiert" sein (nicht verfügbar sein, weil ein anderer Dialogbenutzer über ein anderes Endgerät Operationen an ihm ausführt), so daß die Operation, wenngleich gültig, zu diesem Zeitpunkt nicht durchgeführt werden kann. Es kann wünschenswert sein, die Operation nach einem kurzen Zeitintervall erneut zu versuchen.
Wenn die Operation gültig ist und durchgeführt werden kann, führt das entsprechend dem Baustein WZUPDATE arbeitende System 10 die Operation aus und springt zu DO UPDATE zurück.
Das entsprechend dem Baustein DO UPDATE 126 arbeitende Datenverarbeitungssystem 10 ruft WZFETCH auf. Wie schon beschrieben wurde, überprüft das entsprechend WZFETCH arbeitende System 10 die Status-Datenstruktur und kopiert in Antwort auf eine Fehlerbedingung die den zuvor abgerufenen Treffer-Datensatz bildenden Signale vom Systempufferspeicher 168 (in den sie bei der anfänglichen Wiedergewinnung während der früheren WZFETCH-Operation gebracht worden sind) in den Programmpufferspeicher 703. Die Bausteine für die Bildschirm-Dienstprogramme werden aufgerufen, wie weiter oben beschrieben, um das Sichtgerät 18 für die Anzeige des zuvor aufgerufenen Treffer- Datensatzes zusammen mit einer Fehlermeldung von der Nachrichtendatei 702 zu steuern. Vorteilhafterweise blinkt bzw. blinken das bzw. die Felder in der Anzeige, die mit einem Fehler behaftet waren.
Der Dialogbenutzer kann die Fehlermeldung lesen und die Eingabe korrigieren. Sobald der Benutzer entweder die Eingabe- Taste oder eine der Funktionstasten 204-1 oder 204-16 betätigt hat, kehrt das System 10 von einer Operation entsprechend WZFETCH zum Baustein DO UPDATE 126 zurück. Wie zuvor beschrieben ruft der Baustein 126 den Baustein WZUPDATE 115 auf; das System 10 gibt die gewählte Operation frei (und die modifizierten Treffer-Datensatz-Signale für eine Modifizier- Operation) und führt die gewählte Operation aus, wenn der Fehler korrigiert worden ist.
Der Parameter $errors-only wird in der folgenden Weise verwendet. In einigen Fällen kann es erwünscht sein, dem Dialogbenutzer eine anwählbare Operation, z.B. "Alles Entfernen", anzubieten, bei der eine Vielzahl von Treffer-Datensätzen (vorteilhafterweise definiert durch eine Ergebnisrelation aus einer vorherigen Operation) insgesamt aus der Datenbank 150 zu entfernen ist. Der Benutzer braucht nicht jeden Treffer- Datensatz zu sehen, bevor er entfernt wird, wenn die Operation bezüglich dieses Treffer-Datensatzes gültig ist. Wenn jedoch die Operation hinsichtlich eines der Treffer-Datensätze ungültig ist, ist es wünschenswert, daß der Benutzer diesen Treffer zusammen mit einer Fehlermeldung sehen kann, so daß die Operation in bezug auf diesen Datensatz korrigiert oder übersprungen und bei den übrigen Datensätzen ausgeführt werden kann. Wie weiter oben beschrieben, kann es alternativ bei einem Datenverarbeitungssystem, in dem viele Dialogbenutzer zur gleichen Zeit auf die Treffer-Datensätze in der Datenbank 150 zugreifen, vorkommen, daß ein bestimmter Treffer- Datensatz zu einem bestimmten Zeitpunkt nicht abgerufen werden kann. In einem solchen Fall ist es wünschenswert, dem Dialogbenutzer die Wahl einer Wiederhol-Operation zu ermöglichen, die, wenn erfolgreich, dem System die Weiterführung der Operation ermöglicht.
Zu diesem Zweck ruft der Baustein DO UPDATE 126 den Baustein WZ FETCH 602 und den Baustein WZ UPDATE 115 wechselweise auf, bis die angewählte Operation hinsichtlich aller durch den Cursor spezifizierten Treffer-Datensätze ausgeführt worden ist. Signale, die einen "Ja"-Wert des Parameters $errors-only darstellen, werden vom System 10 beim Arbeiten entsprechend dem Baustein WZFETCH 602 verwendet. Beim Arbeiten entsprechend dem Haupt-Baustein 704 verwendet das System 10 in Antwort auf solche Signale die die Status-Struktur in TCOM 160 bildenden Signale. Wenn der durch diese Signale dargestellte Wert anzeigt, daß beim Ausführen der angewählten Operation an dem zuvor abgerufenen Treffer-Datensatz keine Fehler aufgetreten sind, arbeitet das System 10 entsprechend dem Nicht- Interaktiv-Baustein 708, um den nächsten Treffer-Datensatz abzurufen, ihn darstellende Signale in den Programmpufferspeicher zu bringen und die qry.fch-pos-Signale 707 zu inkrementieren. Die Operation wird dann hinsichtlich des neu abgerufenen Treffer-Datensatzes freigegeben.
Wenn jedoch die die Status-Datenstruktur 700 bildenden Signale eine Fehlerbedingung aus der vorhergehenden Operation des Systems 10 entsprechend WZUPDATE 115 anzeigen, wird das entsprechend dem Haupt-Baustein 704 arbeitende System 10 den Interaktiv-Baustein 706 aufrufen. Wie weiter oben beschrieben, werden die den zuvor abgerufenen Treffer-Datensatz bildenden Signale in den Programmpufferspeicher 703 kopiert, und die Bausteine der Bildschirm-Dienstprogramme werden das Sichtgerät 18 so steuern, daß es Darstellungen eines solchen Treffer-Datensatzes und eine Fehlermeldung aus der Datei 702 entsprechend dem durch screen# spezifizierten Format 166 anzeigt.
Nach der Eingabe von Signalen, einschließlich eines Operationswahlsignals durch den Dialogbenutzer, löscht das System 10 aus der Status-Struktur 700 die Angabe des zuvor festgestellten Integritätspegelfehlers und kehrt nach DO UPDATE zurück, der den Baustein WZ UPDATE 115 aufruft. Wenn die Signale vom Dialogbenutzer den Fehler korrigiert haben (oder Wiederholung oder Überspringen oder andere zweckdienliche Operationen gewählt haben), kann das System die entsprechende Aktion ausführen und die Operation entsprechend den übrigen Treffer-Datensätzen fortsetzen. Wenn nein, gibt das System 10 die Operation erneut nicht frei und bringt entsprechende Signale in die Status-Struktur 700. Eine Rückkehr zu DO PXI oder zu einem anderen Abrufprogramm ist erst möglich, nachdem der Fehler korrigiert worden ist. Somit braucht kein Teil von DO PXI oder eines anderen Abrufprogramms Einrichtungen zur Bearbeitung solcher Fehler vorsehen.
Es ist festzustellen, daß die Einrichtungen und die Operation entsprechend meiner Erfindung einem Dialogbenutzer besonders zweckdienliche Mittel zum Korrigieren von Eingabefehlern in einer großen Anzahl Fälle bereitstellen. Die Feststellung des Fehlers und die Dialogeinrichtungen zu seiner Korrektur werden auf der Abfrage-Zugriffs-Ebene der Arbeitsweise des Datenverarbeitungssystems bereitgestellt. Dies bietet besondere Vorteile, wenn ein Programmierer ein interaktives Datenbank- Pflegeprogramm aufbaut, das weitere, an den Treffer-Datensätzen der Datenbank auszuführende Operationen umfaßt, die Modifizier- oder Entfern-Operationen verwenden, da sich der Programmierer um diese Fehlerebene nicht kümmern braucht.

Claims

1. Vorrichtung (10) zur Verwaltung einer relationalen Datenbasis, in der Relationen (150) gespeichert sind, von denen jede eine Vielzahl von Zeilen, jede Zeile eine Vielzahl von Feldern umfaßt,

wobei die Relationen Bedingungen erfüllen, die ausreichen, um Operationen an den durch Relationenanalyse zu modellierenden und analysierenden Relationen zu ermöglichen, und umfassend

eine Zielspezifiziereinrichtung (158) zum Spezifizieren einer Zielrelation in Abhängigkeit von einem Zielspezifiziersignal, und

einer Anzeigevorrichtung (18) zum Anzeigen von Zeilen einer Zielrelation,

gekennzeichnet durch

- eine Einrichtung (20) zum interaktiven Empfangen von Bezeichnungssignaleingaben, die während der Anzeige von Zeilen einer Zielrelation interaktiv eingegeben werden und eine Zeilenteilgruppe der angezeigten Zeilen einer Relation definieren,

- ein jeder Zeile zugeordnetes Markierfeld zum Speichern der Bezeichnungssignaleingabe, und

- eine Einrichtung zum Bilden einer neuen, nicht in den gespeicherten Relationen enthaltenen Relation (176), wobei die neu gebildete Relation die Zeilen und nur die Zeilen der so markierten Zeilenteilgruppe enthält und die neue Relation die genannten ausreichenden Bedingungen erfüllt.