WO2008095209A1

WO2008095209A1 - Verfahren zum steuern eines relationalen datenbanksystems

Info

Publication number: WO2008095209A1
Application number: PCT/AT2007/000437
Authority: WO
Inventors: Matthias MÖSTL
Original assignee: Mediareif Möstl & Reif Kommunikations- Und Informationstechnologien Oeg
Priority date: 2007-02-06
Filing date: 2007-09-14
Publication date: 2008-08-14

Abstract

Verfahren zum Steuern eines relationalen Datenbanksystems, wobei ein abzuarbeitendes Anfragestatement, das aus Schlüsselworten zusammengesetzt ist, zunächst unter Anwendung eines rekursiven Übergangsnetzwerks (RTN) analysiert und in Steuerbefehle umgewandelt wird, mit folgenden Schritten: Definieren des RTN in einem Voreinstellungsschritt durch Bilden von voneinander unabhängigen RTN-Bausteinen, mit jeweils einem inneren, gerichteten Entscheidungsgraphen und gegebenenfalls zumindest einer rekursiven RTN-Baustein-Einsetzposition; Transformieren des abzuarbeitenden Statements in eine zugehörige RTN-Baustein-Verschachtelung; Generieren eines optimierten Zugriffsplans auf Basis dieser zugehörigen RTN-Baustein-Verschachtelung für das relationale Datenbanksystem.

Description

Verfahren zum Steuern eines relationalen Datenbanksystems

Die Erfindung betrifft ein Verfahren zum Steuern eines relationalen Datenbanksystems, wobei ein abzuarbeitendes Anfragestatement, das aus Anfrage-Sclilüsselworten zusammengesetzt ist, zunächst unter Anwendung eines rekursiven Übergangsnetzwerks (RTN) analysiert wird, indem die Übereinstimmung der Anfrage-Schlüsselworte mit dem RTN überprüft wird, und danach in einen Steuerbefehle umfassenden Zugriffsplan umgewandelt und dieser gegebenenfalls optimiert wird.

Weiters betrifft die Erfindung ein zugehöriges relationales Datenbanksystem, zugehörige Datenträger oder Trägersignale mit Steuerungsinformationen für das relationale Datenbanksystem sowie zugehörige Computerprogramme und Computeφrogrammprodukte zur Ausführung des vorgenannten Verfahrens.

Der überwiegende Teil der relationalen Datenbanksysteme basiert auf SQL, welches trotz seines hohen Verbreitungsgrades und seiner ständigen Weiterentwicklung bei komplexeren Anfragen zu Schwierigkeiten bei der Formulierung eines Anfrage-Statements fuhrt, und durch die grammatikalisch begrenzten Freiheitsgrade es zu einer unnötig komplizierten Problembeschreibung und einem daraus resultierenden nicht optimalen Zugriffscode kommt, der eine Speicher-, festplatten-zugriffs- und prozessor-intensive Abarbeitung mit sich bringt.

SQL ist eine mengenverarbeitende Anfragesprache, welche festgelegte Mengenverarbeitungsfunktionen in bestimmter, immer gleicher Reihenfolge auf frei defrnierbare Eingangsmengen für jedes Statement bzw. Sub-Statement anwendet.

Diese relative Begrenztheit in der Anwendung von SQL entsteht durch die zugrunde liegende RTN (rekursives Übergangsnetzwerk)-Logik, deren Abarbeitung entlang eines vorgegebenen Entscheidungsgraphen geschieht, der eine fixe oder weitestgehend fixe Abfolge von Schlüsselworten und die rekursive Einsetzbarkeit des gesamten Entscheidungsgraphen an bestimmten Entscheidungspositionen vorsieht, wobei nach jedem Schlüsselwort eine beschränkte Auswahl an Schlüsselworten zugelassen ist. Aufgrund dieser vorgegebenen Abfolge lässt sich die Abarbeitung des Statements nur mittels in sich geschachtelter und/oder verketteter Gesamtdurchläufe des gesamten Entscheidungsgraphen beschreiben, wobei speziell in SQL, OQL oder dgl. aufgrund der durch den Entscheidungsgraphen bedingten Reihenfolge eine Abarbeitung von vordefinierten Verarbeitungsblöcken ermöglicht wird, aber das Einführen neuer, insbesondere ihrer Reihenfolge frei wählbarerer und wiederholbarer Verarbeitungsblöcke nicht möglich ist.

Trotzdem SQL mit den oben beschriebenen, natürlich vorhandenen RTN-Einschränkungen als turing-vollständig konzipiert worden ist, lassen sich in der Praxis relativ viele Anfragen auch für den Experten nur sehr schwierig umsetzen und verursachen dadurch oft auch eine sehr lange Abarbeitungszeit gegenüber der theoretisch möglichen Abarbeitungszeit, die wegen der durch das RTN von SQL nicht zugelassenen Freiheitsgrade in der Formulierung und Verwendung von Anfragestatements nicht erreichbar ist.

Aufgabe der Erfindung ist es daher, ein Verfahren der eingangs genannten Art anzugeben, welches ein einfaches und prägnantes Beschreiben von Sachverhalten > beliebigen Schwierigkeitsgrades in einer Anfrage-Sprache und die Erstellung eines verbesserten Zugriffsplans ermöglicht, und dadurch bedingt das Anfrageergebnis schneller berechnet bzw. ausgeführt werden kann.

Weiters ist es Ziel der Erfindung, ein derartiges Verfahren anzugeben, welches die Nachvollziehbarkeit und Übersichtlichkeit von Anfragestatements für den Anwender und für Dritte erhöht sowie eine leicht durchführbare Abwandlung oder Anpassung von vorhandenen Statements ermöglicht, .z.B. wenn ausgehend von einer Fragestellung weitere ähnliche Fragestellungen erstellt werden sollen.

Um eine leichte Anwendbarkeit zu garantieren, soll das erfindungsgemäße Verfahren auch in graphischen Oberflächen optimal darstellbar sein.

Es soll das Definieren bzw. das Erweitern von neuen Verarbeitungsfunktionen für die Anwendung der dem Verfahren zugrunde liegenden Anfragesprache leicht möglich sein.

Des Weiteren ist es Ziel der Erfindung, eine Analyse eines Statements, welches den vorher angeführten Anforderungen einfach gerecht wird, schnellstmöglich durchzuführen und einen dem jeweiligen Statement entsprechenden optimalen Zugriffsplan auf eine gegebene Datenstruktur eines relationalen Datenbanksystems zu erzeugen und diesen abzuarbeiten.

Eine weitere Anforderung an die Erfindung stellt die kontextsensitive Sprachanalyse dar. Hierunter ist zu verstehen, dass ein Anwender ein Anfragestatement mit minimalen syntaktischen Regelwerken und ohne vorgegebene Logik angibt. Das System erkennt entweder gänzlich automatisch oder, bei Mehrdeutigkeiten, mittels automatischer Nachfrage beim Anwender, welcher Zugriffsplan für die zugrunde liegende Datenstruktur erstellt werden soll. Somit wird für den Anwender die leichteste Schreibweise garantiert, wobei eine Problemstellung ebenfalls auf mehrere Arten beschrieben und weiters bestmöglich optimiert werden kann. Die Definition der kontextsensitiven Deutung soll ebenfalls einfach und übersichtlich definiert und jederzeit erweiterbar sein können.

Erfmdungsgemäß wird dies beim eingangs genannten Verfahren dadurch erzielt, dass es die folgende Schritte umfasst:

Definieren des RTN in einem Voreinstellungsschritt durch Bilden von voneinander unabhängigen RTN-Bausteinen, welche eine nach Bedarf veränderbare Gesamtheit an RTN- Bausteinen ausbilden, wobei jeder RTN-Baustein zugehörige verarbeitungsrelevante RTN- Baustein-Informationen beinhaltet und einen inneren, gerichteten Entscheidungsgraphen aufweist, der unabhängig von den inneren, gerichteten Entscheidungsgraphen der anderen RTN-Bausteine definiert ist und jeweils zumindest einen Entscheidungspfad aufweist, welcher zumindest eine Entscheidungsposition beinhaltet,

wobei in jedem der RTN-Bausteine zumindest eine der Entscheidungspositionen als Schlüsselwort-Entscheidungsposition ausgebildet ist, welche ein zugehöriges Schlüsselwort beinhaltet,

und wobei bei zumindest einem Teil der RTN-Bausteine zumindest eine ihrer Entscheidungspositionen als rekursive RTN-Baustein-Einsetzposition ausgebildet ist, an welcher jeweils ein RTN-Baustein aus der Gesamtheit derselben einsetzbar ist, wobei auch jene RTN-Bausteine eingesetzt werden können, in deren inneren, gerichteten Entscheidungsgraphen zumindest eine ihrer Entscheidungspositionen als rekursive RTN- Baustein-Einsetzposition ausgebildet ist, sodass eine beliebig oftmalige rekursiv verschachtelte Einsetzmöglichkeit von RTN-Bausteinen ermöglicht wird,

Definieren von voneinander unabhängigen Entscheidungspositions- Verarbeitungsinformationen als Teilschritt des Voreinstellungsschrittes, welche unabhängig von den RTN-Bausteinen sind und welche eine nach Bedarf veränderbare Gesamtheit an Entscheidungspositions-Verarbeitungsinformationen darstellen,

und als weiteren Teilschritt des Voreinstellungsschrittes Auswählen jeweils zumindest einer der Entscheidungspositionen von zumindest einigen der RTN-Bausteine, wobei diesen ausgewählten Entscheidungspositionen jeweils zumindest eine der Entscheidungspositions- Verarbeitungsinformationen aus deren Gesamtheit zugeordnet wird,

Transformieren des abzuarbeitenden Anfragestatements in eine zugehörige RTN- Baustein- Verschachtelung, wobei diese aus ausgewählten RTN-Bausteinen besteht, welche jeweils auch mehrfach auswählbar sind,

wobei die zugehörige RTN-Baustein-Verschachtelung einen RTN-Baustein aus der Gesamtheit der RTN-Bausteine als äußersten RTN-Baustein umfasst, aus dessen Entscheidungsgraph genau einer seiner Entscheidungspfade ausgewählt wird, welcher zumindest eine Entscheidungspositionen enthält, die als rekursive RTN-Baustein- Einsetzposition ausgebildet ist, und zumindest eine weitere Entscheidungsposition enthält, die durch eine Schlüsselwort-Entscheidungsposition ausgebildet ist,

wobei die zugehörige RTN-Baustein-Verschachtelung weitere RTN-Bausteine aus der Gesamtheit der RTN-Bausteine als eingesetzte, innere RTN-Bausteine umfasst, aus deren Entscheidungsgraphen jeweils genau einer ihrer Entscheidungspfade ausgewählt wird, und welche jeweils an jenen Entscheidungspositionen des äußersten bzw. der eingesetzten inneren RTN-Bausteine eingesetzt sind, welche durch die rekursive RTN-Baustein-Einsetzposition ausgebildet sind,

und wobei die zugehörige RTN-Baustein-Verschachtelung so zusammengesetzt ist, dass beginnend mit der ersten Entscheidungsposition des äußersten RTN-Bausteins eine Übereinstimmung mit dem abzuarbeitenden Anfragestatement insofern vorliegt, dass die Schlüssel worte der Schlüsselwort-Entscheidungspositionen der jeweiligen Entscheidungspfade der für die zugehörige RTN-Baustein-Verschachtelung ausgewählten RTN-Bausteine unter Berücksichtigung der vorhandenen, rekursiven RTN-Baustein- Einsetzpositionen und deren jeweils eingesetzten inneren RTN-Bausteine, jeweils mit den Anfrage-Schlüsselworten des abzuarbeitenden Anfragestatements in deren vorliegender Reihenfolge übereinstimmen,

Generieren eines Zugriffsplans für das zugrunde liegende relationale Datenbanksystem in einem Zugriffsplan-Erstellungsschritt, indem aus der dem abzuarbeitenden

Anfragestatement zugehörigen RTN-Baustein-Verschachtelung sowie aus der Reihenfolge der Entscheidungspositions-Verarbeitungsinformationen eine Auswertung derselben vorgenommen wird und als Ergebnis dieser Auswertung der Zugriffsplan erstellt wird.

Weiters wird die Aufgabe der Erfindung durch ein relationales Datenbanksystem gelöst, welches mindestens ein Computersystem mit mindestens einer relationalen Datenbank, mindestens eine Datenverarbeitungseinheit und mindestens einen Speicher umfasst und das programmtechnisch so eingerichtet ist, dass sie nach dem vorgenannten erfindungsgemäßen Verfahren arbeitet.

Auf diese Weise wird auf den bisher angewandten hohen Strukturierungsgrad bei Anfragesprachen wie z.B. SQL, OQL, dgl. mit vorgegebenen Verarbeitungsbereichen und Verarbeitungsreihenfolgen, wie SELECT, FROM, WHERE₃ GROUP BY, HAVING, ORDER BY, LIMIT, UNION verzichtet und dadurch eine höhere Flexibilität bei der Formulierung einer Anfrage zu erhalten.

Während bei SQL es zwingend vorgeschrieben ist, im FROM-Teil der Anfrage kartesische Produkte zu bilden, im WHERE-Teil bestimmte Zeilen der kartesischen Produkte zu streichen, im GROUP BY-Teil nach bestimmten Datenfeldern zusammenzufassen, im HAVING-Teil anhand von Gruppenberechnungsergebnissen bestimmte Zeilen zu streichen, mit ORDER BY zu sortieren und mit UNION oder anderen mengenverknüpfenden Operationen Mengen nach bestimmten Kriterien zusammenzufassen, kann bei Anwendung des erfindungsgemäßen Verfahrens ohne solche Einschränkungen das Auslangen gefunden werden.

Bei SQL gemäß Stand der Technik wird zwar die erforderliche Turing- Vollständigkeit erreicht, sodass alle auf Daten bezogenen lösbaren Probleme theoretisch formulierbar sind, in der Praxis scheitert dies aber wegen der hohen Komplexität je nach Anwenderkompetenz bereits bei mittelschweren bis schwierigen Aufgaben. Hinzu kommt noch, dass ein großer Teil aller möglichen Anfragen zwar für den Experten formulierbar sind, diese aber für das jeweilige Problem nur sehr umständlich in die von gegebenen Verarbeitungsbereiche einzugliedern sind, weil dies durch vorgegebene Strukturierung und Reihenfolge z.B. bei SQL nicht anders ermöglicht wird. Nachdem es bedingt durch die geringe Anzahl an Verarbeitungsbereichen in vielen Fällen nicht möglich ist, einen direkten Weg der Mengenverarbeitung vorzugeben, bleibt es dem für diesen Zweck vorgesehenen Optimizer überlassen, viele der schlechtesten Wege zu vermeiden und für die jeweils angewandte Beschreibung, den besten Weg zu ermitteln, verglichen mit dem theoretisch bestmöglichen Weg weicht dieser aber mitunter stark von diesem ab.

Die Grundlage des erfindungsgemäßen Verfahrens wird durch die Definition und Verwendung von neuartigen RTN-Bausteinen gebildet, welche in sich abgeschlossene Einheiten bilden und deswegen von einander unabhängig sind, da diese jeweils durch einen inneren, gerichteten Entscheidungsgraphen gebildet sind. Dieser innere, gerichtete Entscheidungsgraph selbst entspricht entweder einem einzigen Entscheidungspfad oder wird durch die Überlagerung .von zumindest zwei Entscheidungspfaden gebildet. Entlang dieser Entscheidungspfade befinden sich Entscheidungspositionen, die jeweils als eine von festgelegten Grundarten ausgebildet sind, von denen eine die rekursive Einsetzbarkeit von RTN-Bausteinen ermöglicht, welche in diesem Zusammenhang als RTN-Baustein- Verschachtelung bezeichnet wird.

Zum Zwecke der Analyse eines vorgegebenen Anfragestatements und der damit verbundenen Zugriffsplan-Erstellung für eine zugrunde liegende Datenstruktur wird erfindungsgemäß eine unter Zuhilfenahme der Gesamtheit der RTN-Bausteine zusammengesetzte Anordnung und/oder Verschachtelung ermittelt, so dass die Schlüsselworte des Anfragestatements in deren vorliegender Reihenfolge ihre Entsprechung in dieser ermittelten Anordnung und/oder Verschachtelung bei Entscheidungspositions-weisem Durchlaufen derselben an den aufeinander folgenden Schlüsselwort-Entscheidungspositionen finden. Es wird jeweils ein Entscheidungspfad aus dem inneren, gerichteten Entscheidungsgraphen der für die Verschachtelung herangezogenen RTN-Bausteine ausgewählt. Dabei ist zu berücksichtigen, dass ein Durchlaufen dieser Verschachtelung nicht ein einfaches, lineares Durchlaufen eines oder mehrerer RTN-Bausteine darstellt, sondern an bestimmten der erreichten Entscheidungspositionen auf den jeweils ausgewählten Entscheidungspfaden derselben das Einsetzen von gleichen oder anderen RTN-Bausteinen vorgesehen ist, an welchen Entscheidungspositionen die jeweils eingesetzten RTN-Bausteine wiederum bis zu ihrem Ende durchlaufen werden und dann der Durchlauf beim übergeordneten RTN-Baustein fortgesetzt wird. Es kann aber jeder eingesetzte RTN-Baustein wiederum das Einsetzen und Durchlaufen eines gleichen oder anderen RTN-Bausteins an zumindest einer der Entscheidungspositionen vorschreiben, etc., was in diesem Zusammenhang als rekursiv verschachtelte Ausführung einer Aufruffunktion bedeutet.

Wesentlich beim erfϊndungsgemäßen Verfahren ist die durch die voneinander unabhängigen RTN-Bausteine ermöglichte Erweiterbarkeit derselben und deren Gesamtheit sowie die einfache Schreibweise von Statements, welche sich durch hohe Flexibilität und minimal vorgegebene Strukturierung bei der Formulierung von Anwender-Statements ergibt. Dies wird insbesondere durch die inneren, gerichteten Entscheidungsgraphen und durch die Verwendung von rekursiven RTN-Baustein-Einsetzpositionen an einigen der Entscheidungspositionen, die eine beliebig oftmalige Verschachtelung von RTN-Bausteinen ermöglichen, erzielt. . Durch die Zuordnung von Entscheidungspositions- Verarbeitungsinformationen, die, wie nachfolgend in der Beschreibung gezeigt, für eine kontextsensitive Sprachanalyse Verwendung zur Zugriffsplanerstellung finden können, zu Entscheidungspositionen in den Entscheidungsgraphen kann eine sehr hohe Genauigkeit und Optimierbarkeit bei der Erstellung von Zugriffsplänen anhand gegebener, jeweils Anfragestatements zugehörigen RTN-Baustein-Verschachtelungen erzielt werden.

Auf Basis dieser RTN-Bausteine, die für jedes Anfragestatement entsprechend angepasst oder erweitert werden können, wird erfindungsgemäß eine dem abzuarbeitenden Anfragestatement zugehörige RTN-Baustein-Verschachtelung der RTN-Bausteine ermittelt, indem unter Zuhilfenahme eines angenommen äußersten RTN-Bausteins dessen Entscheidungspfaden in Entsprechung der Anfrage-Schlüsselworte des Anfragestatements weitest möglich gefolgt wird. Kann nun allen Entscheidungspositionen eines der Entscheidungspfade dieses ausgewählten äußersten RTN-Bausteins gefolgt werden, und zwar unter Berücksichtigung jener Ausbildung, in der diese erreichten Entscheidungspositionen vorliegen, z.B. als Schlüsselwort-Entscheidungsposition, und wurden ebenfalls alle inklusive des letzten Anfrage-Schlüsselwortes des Anfragestatements erfolgreich mit den Schlüsselwort- Entscheidungspositionen verglichen, wobei an den jeweils erreichten rekursiven RTN- Baustein-Einsetzpositionen passende RTN-Bausteine, die gegebenenfalls wiederum in sich verschachtelt sind, eingesetzt wurden, ist die dabei ermittelte RTN-Baustein-Verschachtelung als abgeschlossen zu betrachten und für die weitere Analyse zur Zugriffsplan-Erstellung heranzuziehen. Kann jedoch keinem der Entscheidungspfade des gewählten äußersten RTN- Bausteins bis zum Ende gefolgt werden, weil entweder ein Anfrageschlüsselwort mit keiner korrespondierenden Schlüsselwort-Entscheidungsposition übereinstimmt oder an einer rekursiven RTN-Baustein-Einsetzposition kein passender RTN-B austein eingesetzt und dieser durchlaufen werden kann, bzw. rekursiv folgende RTN-Bausteine nicht erfolgreich durchlaufen werden können, werden solange weitere RTN-Bausteine als äußerste RTN- Bausteine herangezogen, bis jener RTN-Baustein gefunden wird, welcher in Kombination mit anderen RTN-Bausteinen eine vollkommene Übereinstimmung mit dem zugehörigen Anfragestatement, die unter Voraussetzung eines ordnungsgemäß erstellten Anfragestatements immer vorhanden ist, ergibt.

Wird mehr als eine gültige RTN-Baustein-Verschachtelung für ein zugehöriges Anfragestatement gefunden, kann vorzugsweise unter Verwendung zumindest - einer Gewichtung und/oder unter Berücksichtigung anderer Kriterien eine bestgeeignete RTN- Baustein-Verschachtelung ausgewählt werden.

Gemäß einer weiteren Ausbildung des erfindungsgemäßen Verfahrens des erfindungsgemäßen Verfahrens kann vorgesehen sein, dass zur Ermittlung des äußersten RTN-Bausteins sowie für die Ermittlung von an den Entscheidungspositionen der rekursiven RTN-Baustein-Einsetzpositionen jeweils einzusetzenden RTN-Bausteine der dem Anfragestatement zugehörigen RTN-Baustein-Verschachtelung RTN-Bausteine aus der Gesamtheit derselben durchlaufen werden, wobei bei Durchlaufen der RTN-Bausteine deren innere, gerichtete Entscheidungsgraphen durchlaufen werden, indem die entlang der Entscheidungspfade derselben vorhandenen Entscheidungspositionen erreicht werden, wobei jede der Entscheidungspositionen in Abhängigkeit von einem zugehörigen Kennzeichen entweder

eine Schlüsselwort-Entscheidungsposition ausbildet, welche einen Text, ein Sonderzeichen, eine Variable, eine Zahl, eine Konstante, einen Tabellen- oder Tabellenfeldnamen, einen Funktionsnamen od. dgl. enthält und bei Erreichen mit einem Anfrage-Schlüsselwort verglichen wird,

oder eine Sprung-Entscheidungsposition ausbildet, welche eine Sprungposition auf eine beliebige Entscheidungsposition innerhalb des inneren, gerichteten Entscheidungsgraphen des aktuellen RTN-Bausteins festlegt und diese bei Erreichen ausführt,

oder eine rekursive RTN-Baustein-Einsetzposition-Entscheidungsposition ausbildet, in welche ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt wird, welcher seinerseits wieder durchlaufen wird.

Durch diese an den Entscheidungspositionen ermöglichten Festlegungen wird erreicht, für jeden beliebigen Anwendungsfall genau angepasste RTN-Bausteine zu schaffen, mit denen die zu lösenden Fragestellungen in übersichtlicher, unkomplizierter und weiters gut optimierbarer Weise angegeben werden können.

Ein RTN-Baustein enthält einen inneren, gerichteten Entscheidungsgraphen, welcher Entscheidungsgraph entweder aus einem Entscheidungspfad oder aus der Überlagerung von zumindest zwei Entscheidungspfaden zusammengesetzt ist.

Jeder Entscheidungspfad hat definitionsgemäß - in Durchlaufrichtung gesehen - eine erste, sowie gegebenenfalls weitere, im gleichen Entscheidungspfad nachfolgende Entscheidungspositionen. Ebenso hat jeder Entscheidungspfad eine letzte Entscheidungsposition, welche in jenen Fällen der ersten Entscheidungsposition entspricht, in denen der Entscheidungspfad eine einzige Entscheidungsposition aufweist. Ansonsten ist die letzte Entscheidungsposition jene Entscheidungsposition, welche in diesem Entscheidungspfad als letzte angegeben ist und somit bei Folgen als letzte Entscheidungsposition in demselben erreicht wird.

Als erste erreichbare Entscheidungspositionen eines RTN-Bausteins sind somit die ersten Entscheidungspositionen der zum inneren, gerichteten Entscheidungsgraphen überlagerten Entscheidungspfade zu verstehen.

Eine bevorzugte Form der Analyse eines angegebenen Anfragestatements kann gemäß einer weiteren Ausfuhrungsform des erfmdungsgemäßen Verfahrens darin bestehen, dass das Transformieren des abzuarbeitenden Anfragestatements erfolgt, indem das erste Anfrage- Schlüsselwort des abzuarbeitenden Anfragestatements als Vergleichsschlüsselwort festgelegt und folgender rekursiver RTN-Baustein-Auswahlschritt angewandt wird:

Auffinden zumindest eines der RTN-B austeine aus der Gesamtheit derselben, für welchen das festgelegte Vergleichsschlüsselwort mit zumindest einer von jenen

Entscheidungspositionen übereinstimmt, die als erste Entscheidungspositionen in diesem RTN-Baustein erreichbar sind,

und Aufnehmen desselben in die dem abzuarbeitenden Anfragestatement zugehörige RTN-Baustein-Verschachtelung, sofern einer seiner Entscheidspfade in weiterer

Übereinstimmung mit den dem festgelegten Vergleichsschlüsselwort nachfolgenden Anfrage-Schlüsselworten des abzuarbeitenden Anfragestatements vollständig durchlaufen werden kann,

wobei an jenen erreichten Entscheidungspositionen, welche eine rekursive RTN-Baustein- Einsetzposition aufweisen, das dem zuletzt verglichenen Anfrage-Schlüsselwort nachfolgende Anfrage-Schlüsselwort im abzuarbeitenden Anfragestatement als Vergleichsschlüsselwort festgelegt und der rekursive RTN-Baustein-Auswahlschritt angewandt wird.

Auf diese Weise werden genau jene RTN-Bausteine aus der Gesamtheit derselben ermittelt, welche für die dem angegebenen Anfragestatement zugehörige und somit passende RTN- Baustein-Verschachtelung zu verwenden sind. Weiters wird somit der jeweilige Entscheidungspfad ausgewählt und die Position der jeweiligen RTN-Bausteine in der RTN- Baustein-Verschachtelung definiert, um diese im nachfolgenden Zugriffsplan- Erstellungsschritt diese als Grundlage weiterverarbeiten zu können.

Weitere Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen wiedergegeben. Nachfolgend wird die Erfindung anhand der in den Figuren gezeigten Ausfuhrungsbeispiele ausfuhrlich erläutert.

Fig. 1 zeigt eine schematische Darstellung eines SQL-RTNs gemäß Stand der Technik; Fig. 2, 3 zeigen eine schematische Darstellung zweier RTN-Bausteine mit Hervorhebung von als erste erreichbare Entscheidungspositionen bei Begimi des Durchlaufs der Entscheidungsgraphen von RTN-Bausteinen gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens;

Fig. 4, 5, 6, 7, 18, 19, 20 zeigen jeweils eine schematische Darstellung mehrerer RTN- Bausteine gemäß einer Ausfuhrungsform des erfindungsgemäßen Verfahrens, welche nur einen Entscheidungspfad aufweisen, aber jeweils das Ergebnis einer Zusammenfassung von anderen RTN-Bausteinen darstellen;

Fig. 8, 9, 10, 11, 12, 13 zeigen jeweils eine schematische Darstellung der Eingangsmengen- Zuweisungen von unterschiedlichen RTN-Baustein-Schachtelungen bzw. Sonderformen wie sie in Ausfuhrungsformen des erfindungsgemäßen Verfahrens zur Anwendung gelangen; Fig. 14, 15, 16, 17 zeigen jeweils eine schematische Darstellung von Gruppierungsvarianten von RTN-Bausteinen, wie sie in Ausfuhrungsformen des erfindungsgemäßen Verfahrens Anwendung finden;

Fig. 21 bis 28 zeigen jeweils eine schematische Darstellung eines RTN-Bausteins gemäß einer Ausfuhrungsform des erfindungsgemäßen Verfahrens; Fig. 29 bis 32 zeigen jeweils eine schematische Darstellung eines Verweisgrupppen-Elements mit zugehörigem Rest-Entscheidungsgraph gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens;

Fig. 33 bis 40 zeigen jeweils eine schematische Darstellung eines RTN-Bausteins gemäß einer Ausfuhrungsform des erfindungsgemäßen Verfahrens; Fig. 41 bis 45 zeigen jeweils eine schematische Darstellung eines Verweisgrupppen-Elements mit zugehörigem Rest-Entscheidungsgraph einer Ausführungsform des erfindungsgemäßen Verfahrens;

Fig. 46 und 47 zeigen jeweils die schematische Darstellung der Verschachtelung von RTN- Bausteinen gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens; Fig. 48 und 49 zeigen jeweils die schematische Darstellung der Verschachtelung von RTN- Bausteinen gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens; Fig. 50 und 51 zeigen jeweils die schematische Darstellung der Verschachtelung von RTN- Bausteinen gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens.

Ausgangspunkt für die Anwendung der Erfindung ist ein abzuarbeitendes Anfragestatement für ein relationales Datenbanksystem, das vorher im Regelfall von einem Anwender angegeben worden ist und das gemäß dem erfindungsgemäßen Verfahren analysiert wird sowie entsprechend dieser Analyse durch Anwendung des erfindungsgemäßen Verfahrens ein Zugriffsplan für die zugrunde liegende Datenstruktur erstellt wird und nach Ausführung desselben die gefragten Ergebnisse geliefert werden.

Ein derartiges abzuarbeitendes Anfragesstatement besteht zunächst aus einer Aneinanderreihung von Terminalsymbolen, das heißt, aus sichtbaren Zeichen - Buchstaben, Ziffern, Satzzeichen, Leerzeichen, etc. Kombinationen dieser Terminalsymbole ergeben die Schlüsselworte dieses Anfragestatements. Bei folgendem Anfragestatement WHERE Kunden.Nachname IN ( „ Müller", „Maier") AND VIP_Kunde = TRUE finden folgende Schlüssel worte in dieser natürlichen Reihenfolge Verwendung:

WHERE Kunden Nachname IN ( „Müller"

„Maier" ) AND VIP Kunde TRUE

In diesem Beispiel ist ersichtlich, dass sowohl Tabellennamen, Tabellenfeldnamen, Variable Werte, Zahlen, Konstanten, Vergleichsoperatoren, Sonderzeichen wie z.B. Punkt und Beistrich, Befehle und dergleichen Anfrage-Schlüsselworte darstellen.

Fig.l zeigt einen vereinfachten Entscheidungsgraphen nach dem Stand der Technik für die SELECT-Anweisung der Anfragesprache SQL, aus dem schematisch die Struktur des für SQL verwendeten RTN (rekursiven Übergangsnetzwerks) ersichtlich wird. In entsprechender weise ist das Gesamt-RTN von SQL aufgebaut. Jedes Anfragestatement wird aus einer fix vorgegebenen Abfolge von zwingend aufeinander folgend angeordneten Verarbeitungsbereichen 40, 41, 42, 43, 44, 45 mit Schlüsselworten 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 gebildet, wobei an Entscheidungspositionen 110, 111, 112, 113 - der Einfachheit halber nur für die einleitenden Schlüsselworte 24, 26, 28, 30 der Verarbeitungsbereiche 42, 43, 44 und 45 gezeigt - eine ganz bestimmte Auswahl an Schlüsselworten getroffen werden kann, um das gewünschte Anfrageergebnis zu erhalten. Eine bestimmte Gruppierung von Schlüsselworten bildet jeweils einen Verarbeitungsbereich, z.B. FROM (Schlüsselworte 22, 23), WHERE (Schlüsselworte 24, 25), GROUP BY (Schlüsselworte 26, 27) usw., wobei jeder Verarbeitungsbereich eine ihm zugeordnete Mengenverarbeitungsfunktion ausführt, z.B. FROM bildet kartesische Produkte mit der Möglichkeit spezieller JOINs.

Nach jedem einleitenden Schlüsselwort 20, 22, 24, 26, 28, 30 können weitere Schlüsselworte folgen, die in Fig.l aus Gründen der Übersichtlichkeit nicht gezeigt sind. So kann z.B. nach dem Schlüsselwort 24 „WHERE" die Schlüsselworte „(", „NOT", ein Tabellenname, ein Tabellenfeldname, definierte Funktionen usw. direkt folgen. Ein SUBSELECT, also die rekursive Anwendung des RTN immer beginnend bei SELECT (Schlüsselwort 20) z.B. durch „(" kann an vorgegebenen Entscheidungspositionen auftreten. Somit kann an diesen Stellen jeweils immer nur das gesamte RTN als eine Einheit rekursiv eingesetzt werden.

Trotz der Vielzahl an möglichen auswählbaren Schlüsselworten besteht für SQL und verwandte Anfragesprachen eine relativ starke Eingeschränktheit und es gibt eine Reihe von Anfragen, welche sich mit den vorgegebenen Verarbeitungsbereichen in der vorgegebenen Verarbeitungsreihenfolge nur sehr umständlich und langwierig umschreiben lassen und daher aus dieser umschriebenen Angabe ein komplexerer und langsamerer Zugriffsplan generiert wird als tatsächlich erforderlich.

Als Ergebnis der Erfindung wurde festgestellt, dass ein RTN genau dann die höchste Flexibilität aufweist, wenn das RTN nicht wie im Stand der Technik als eine Gesamtheit betrachtet wird, welche einen gesamten gerichteten Entscheidungsgraphen aufweist, der insgesamt hierarchisch durchlaufen wird und an bestimmten definierbaren Entscheidungspositionen des gesamten RTN' s als Gesamtheit eingesetzt werden kann, sondern durch die Verwendung von erfindungsgemäßen RTN-Bausteinen. RTN-Bausteine ermöglichen insofern die größt-mögliche Flexibilität, als dass in jedem RTN- Baustein, sofern mittels entsprechend ausgebildeter Entscheidungsposition gewünscht, ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt und durchlaufen werden kann.

Die Ausdruckskraft eines abgeschlossenen Sprach- und/oder Logiksystems, welches in einer Sprache mittels Anfragestatements Probleme und Abläufe beschreibt, ergibt sich sowohl durch die Flexibilität des zugrunde liegenden RTN' s, als auch durch die für den Anwender zur Verfügung gestellte Verfahrenslogik, welche unabhängig von dem zugrunde liegenden RTN ist. Gemäß der Erfindung wird sowohl das flexibelste, da auf RTN-B austeinen basierende RTN angegeben, als auch eine zugrunde liegende Verarbeitungslogik angewandt, die die Freiheitsgrade der syntaktischen Formulierung bestmöglich ausschöpft. Zusätzlich wird nachfolgend ein Verfahren angegeben, welches die Anfragestatements, die sowohl auf dem erfindungsgemäßen RTN als auch auf einer zugrunde liegenden Verfahrenslogik und einem zugehörigen Abstraktionsgrad basieren, automatisch in einen optimierten Zugriffsplan für eine zugrunde liegende Datenstruktur umwandelt. Auch dieses Verfahren ist als Zugriffsplan-Erstellungsschritt Teil der Erfindung.

Ausgangspunkt der folgenden Betrachtungen ist immer ein von einem Anwender formuliertes oder über eine graphische Oberfläche generiertes zu analysierendes und somit zu verarbeitendes Anfragestatement. Ein Anfragestatement erhält seine verarbeitungsfähige formale Form genau dann, wenn der Anwender seine Problemstellung, dass heißt die zu formulierende Anfrage an das relationale Datenbanksystem, mittels der durch die RTN- Bausteine erzeugbaren Kombinationen an Schlüsselworten ausdrückt, wobei durch Erweiterung und/oder Veränderung der Definition der erfindungsgemäßen RTN-Bausteine jeweils immer eine gewünschte Anpassung an die Fragestellung des Anwenders erfolgen kann.

Die Ausdruckskraft der formulierbaren Statements wird besonders dadurch erhöht und verfeinert, dass jedem RTN-Baustein verarbeitungsrelevante RTN-Baustein-Informationen zugeordnet werden können, wobei sich diese verarbeitungsrelevanten RTN-Baustein- Informationen entweder auf den RTN-Baustein als gesamten beziehen können, als auch auf einzelne Entscheidungspositionen desselben. Des Weiteren kann als verarbeitungsrelevante RTN-Baustein-Information auch die Kommunikation im Falle der Verschachtelung zweier oder mehrer RTN-Bausteine unabhängig von deren Verschachtelungstiefe und der hierarchischen Reihenfolge deren Verschachtelung verlangt werden.

Bevor eine unformale Fragestellung als ein syntaktisch korrektes Statement angegeben werden kann, ist, sofern eine Gesamtheit an definierten RTN-Bausteinen mit ihren ihnen zugeordneten verarbeitungsrelevanten RTN-Baustein-Informationen bereits vorhanden ist, zu prüfen, ob diese ausreicht, um jene gegebene unformale Fragestellung syntaktisch auszudrücken.

Sofern, wie bei Erstverwendung eines auf RTN-Bausteinen basierenden Systems zu erwarten, noch keine RTN-Bausteine definiert sind, werden diese gänzlich neu geschaffen und als Gesamtheit von RTN-Bausteinen vorgegeben.

Sobald sich für eine gewünschte Fragestellung elementare RTN-Bausteine mit ihren ihnen zugeordneten verarbeitungsrelevanten RTN-Baustein-Informationen als fehlend erweisen, kann die vorhandene Gesamtheit der RTN-Bausteine um diese benötigen RTN-Bausteine ergänzt werden.

Bedingt durch die Unabhängigkeit der erfindungsgemäßen RTN-Bausteine voneinander und durch die erlaubte rekursive RTN-Baustein-Einsetzposition in Entscheidungsgraphen ergibt sich bei der Berechnung auf der Grundlage von RTN-Bausteinen besonders bei einer hohen Anzahl derselben insbesondere an genau diesen rekursiven RTN-Baustein-Einsetzpositions- Entscheidungspositionen ein Geschwindigkeitsnachteil gegenüber der Berechnung auf Grundlage eines RTN nach dem Stand der Technik, welches jeweils nur eine begrenzte Anzahl an Möglichkeiten an den Entscheidungspositionen zulässt. Dieser Geschwindigkeitsverlust kann aber durch Anwendung eines ebenfalls nachfolgend gezeigten Verfahrens ausgeglichen werden, indem mithilfe einer Verweisgruppe und je Element zugeordneten Rest-Entscheidungsgraphen feste Zuordnungen zu bestimmten Schlüsselworten vergeben werden, sodass nicht einmal im schlechtesten Fall alle möglichen Entscheidungspfade der Gesamtheit der RTN-Bausteine geprüft werden müssen, sondern direkt der oder die verlangten RTN-Bausteine identifiziert werden kann. Somit wird vor einer formalen Formulierung einer Fragestellung ein Satz von RTN- Bausteinen entweder neu angegeben, oder ein bestehender Satz derselben, sofern dieser als nicht ausreichend empfunden wird, ergänzt oder erweitert. Dies geschieht erfindungsgemäß im folgenden Verfahrensschritt:

und wobei bei zumindest einem Teil der RTN-Bausteine zumindest eine ihrer Entscheidungspositionen als rekursive RTN-Baustein-Einsetzposition ausgebildet ist, an welcher jeweils ein RTN-Baustein aus der Gesamtheit derselben einsetzbar ist, wobei auch jene RTN-Bausteine .eingesetzt werden können, in deren inneren, gerichteten Entscheidungsgraphen zumindest eine ihrer Entscheidungspositionen als rekursive RTN- Baustein-Einsetzposition ausgebildet ist, sodass eine beliebig oftmalige rekursiv verschachtelte Einsetzmöglichkeit von RTN-Bausteinen ermöglicht wird.

Um diesen verfahrensmäßigen Voreinstellungsschritt in einem Zustand zu verdeutlichen, in welchem noch keine RTN-Bausteine definiert wurden, wird in Beispiel 1 ein einfaches abstraktes RTN angegeben, welches aus RTN-Bausteinen zusammengesetzt ist, wobei für jeden RTN-Baustein der innere, gerichtete Entscheidungsgraph und vorerst aus Gründen der Übersichtlichkeit nicht näher definierte verarbeitungsrelevante RTN-Baustein-Informationen angegeben sind, auf die erst weiter unten eingegangen wird. Beispiel 1 :

RTN-Baustein Bl_l:

- Verarbeitungsrelevante RTN-Baustein-Informationen Vl_l, Vl_2, Vl_3, ... Vl_x - RTN-Syntax: („A" I "V" "W") * „B" * "A"

RTN-Baustein Bl_2:

- Verarbeitungsrelevante RTN-Baustein-Informationen V2_l bis V2_x

- RTN-Syntax: „A" * „C" * "B"

RTN-Baustein Bl_3:

- Verarbeitungsrelevante RTN-Baustein-Informationen V3 1 bis V3_x

- RTN-Syntax: „X" [,,Y"]

RTN-Baustein Bl_4:

- Verarbeitungsrelevante RTN-Baustein-Informationen V4_l bis V4_x

- RTN-Syntax: „A" * (1) „D" [(* I)] *

RTN-Baustein Bl_5: - Verarbeitungsrelevante RTN-Baustein-Informationen V5_l bis V5_x

- RTN-Syntax: „A" "D" [* "E"]

RTN-Baustein Bl_6:

- Verarbeitungsrelevante RTN-Baustein-Informationen V6_l bis V6_x - RTN-Syntax: „X" * „B"

RTN-Baustein Bl_7:

- Verarbeitungsrelevante RTN-Baustein-Informationen V7_l bis V7_x

- RTN-Syntax: * "K" *

RTN-Baustein Bl_8:

- Verarbeitungsrelevante Informationen V8_l bis V8_x

- RTN-Syntax: * "L" * "M" Anhand der in diesem Beispiel 1 angegebenen RTN-Bausteine RTN-Baustein Bl_l bis RTN- Baustein Bl_8 kann die erfindungsgemäß verwendete rekursive RTN-Baustein- Einsetzposition, welche in der jeweiligen RTN-Syntax durch einen * gekennzeichnet wird und ein Einsetzen eines der RTN-Bausteine aus der Gesamtheit der RTN-Bausteine vorschreibt, verdeutlicht werden. Welcher konkrete RTN-Baustein an einer jeweiligen *- Entscheidungsposition, die als rekursive RTN-Baustein-Einsetzposition ausgebildet ist, in einer konkreten, einem abzuarbeitenden Anfragestatement zugehörigen RTN-Baustein- Verschachtelung eingesetzt werden soll, wird ermittelt, indem jener RTN-Baustein aus der Gesamtheit derselben gesucht wird, der im weiteren Abgleich mit den Anfrage- Schlüsselworten des Anfragestatements bis zu seiner letzten Entscheidungsposition durchlaufen werden kann.

Die Figuren Fig.21, Fig.22, Fig.23 bis Fig.28 stellen die RTN-Bausteine des Beispiels 1 BI l, Bl_2, Bl_3 bis Bl_8 mit jeweils einem inneren, gerichteten Entscheidungsgraphen 50888 mit seinen Entscheidungspositionen 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 300 grafisch dar. Der RTN-Baustein Bl_l ist mit dem Bezugszeichen 50001 versehen, der RTN-Baustein Bl_2 mit dem Bezugszeichen 50002 usw. bis RTN-Baustein Bl_8 mit dem Bezugszeichen 50008.

Jeweils idente Entscheidungspositionen in den Entscheidungsgraphen haben in den Figuren jeweils gleiche Entscheidungspositions-Nummer als Bezugszeichen zugeordnet, welche Entscheidungspositions-Nummern nachfolgend erläutert werden. Die rekursive RTN- Baustein-Einsetzposition, welche das Einsetzen eines der RTN-Bausteine aus der Gesamtheit der RTN-Bausteine verlangt, wird in den Figuren 2 bis 5, 14 bis 22, 24 bis 32, 46, 48 und 50 an den verwendeten Entscheidungspositionen mit einem * als zugehöriges Kennzeichen für diese Entscheidungsposition dargestellt und bekommt in sämtlichen Figuren die Entscheidungspositions-Nummer und somit das Bezugszeichen 300 zugewiesen.

Der oben beschriebene Voreinstellungsschritt dient der Definition von RTN-Bausteinen, wie sie an jeweils ein konkretes Anfragestatement angepasst werden können. Sobald die passende Gesamtheit der RTN-Bausteine definiert wurde oder eine bereits vorliegende Gesamtheit ausgewählt wurde, kann die Analyse von Anfragestatements sowie die Erstellung eines Zugriffsplans erfolgen.

Dies geschieht gemäß der Erfindung, indem folgende Schritte ausgeführt werden:

Transformieren des abzuarbeitenden Anfragestatements in eine zugehörige RTN- Baustein-Verschachtelung, wobei diese aus ausgewählten RTN-B austeinen besteht, welche jeweils auch mehrfach auswählbar sind,

und wobei die zugehörige RTN-Baustein-Verschachtelung so zusammengesetzt ist, dass beginnend mit der ersten Entscheidungsposition des äußersten RTN-Bausteins eine

Überemstimmung mit dem abzuarbeitenden Anfragestatement insofern vorliegt, dass die

Schlüsselworte der Schlüsselwort-Entscheidungspositionen der jeweiligen

Entscheidungspfade der für die zugehörige RTN-Baustein-Verschachtelung ausgewählten

RTN-Bausteine unter Berücksichtigung der vorhandenen, rekursiven RTN-Baustein- Einsetzpositionen und deren jeweils eingesetzten inneren RTN-Bausteine, jeweils mit den

Anfrage-Schlüsselworten des abzuarbeitenden Anfragestatements in deren vorliegender

Reihenfolge übereinstimmen, Generieren eines Zugriffsplans für das zugrunde liegende relationale Datenbanksystem in einem Zugriffsplan-Erstellungsschritt, indem aus der dem abzuarbeitenden

Bevorzugt wird festgelegt, dass zur Ermittlung des äußersten RTN-Bausteins sowie für die Ermittlung von an den Entscheidungspositionen der rekursiven RTN-Baustein- Einsetzpositionen jeweils einzusetzenden RTN-Bausteine der dem Anfragestatement zugehörigen RTN-Baustein-Verschachtelung RTN-Bausteine aus der Gesamtheit derselben durchlaufen werden, wobei bei Durchlaufen der RTN-Bausteine deren innere, gerichtete Entscheidungsgraphen durchlaufen werden,

indem die entlang der Entscheidungspfade derselben vorhandenen Entscheidungspositionen erreicht werden, wobei jede der Entscheidungspositionen in Abhängigkeit von einem zugehörigen Kennzeichen entweder

oder eine rekursive RTN-Baustein-Einsetzposition-Entscheidungsposition ausbildet, in welche bei Erreichen derselben ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt wird, welcher seinerseits wieder durchlaufen wird.

Das Durchlaufen eines RTN-Bausteins wird im Rahmen der Erfindung so verstanden, dass Entscheidungsposition für Entscheidungsposition entlang des inneren, gerichteten Entscheidungsgraphen erreicht und gemäß den vorgenannten Grundarten, also z.B. Schlüsselwort-Entscheidungsposition, Sprung-Entscheidungsposition und rekursive RTN- Baustein-Einsetzposition-Entscheidungsposition, abgearbeitet werden. Das heißt bei Erreichen z.B. einer Entscheidungsposition, welche als Grundart Schlüsselwort- Entscheidungsposition ausgebildet ist und einen Text „XXX" verlangt, wird dieser Text „XXX" mit dem korrespondierenden Anfrage-Schlüsselwort des Anfragestatements auf Übereinstimmung geprüft und sofern diese vorliegt, werden die aufgrund des Entscheidungsgraphen infrage kommenden nächsten Entscheidungspositionen gemäß ihrer Ausbildung für das nachfolgende Schlüsselwort im Anfragestatement geprüft. Liegt hingegen keine Übereinstimmung vor, wird festgestellt, dass diesem gewählten Entscheidungspfad des Entscheidungsgraphen nicht bis zu seiner letzten Entscheidungsposition gefolgt werden kann, womit, sofern vorhanden, den anderen Entscheidungspfaden des gleichen inneren, gerichteten RTN-Bausteins gefolgt wird. Wird eine rekursive RTN-Baustein-Einsetzposition erreicht, so wird ein an dieser Entscheidungsposition für die dem konkreten Anfragestatement zugehörigen RTN-Baustein-Verschachtelung einzusetzender RTN-Baustein dadurch ermittelt, dass jener RTN-Baustein aus deren Gesamtheit gesucht wird, welcher auf beschriebene Weise bis zu seiner letzten Entscheidungsposition durchlaufen werden kann. Kann an einer Entscheidungsposition, die als rekursive RTN-Baustein-Einsetzposition ausgebildet ist, kein RTN-Baustein gefunden, welches bis zu seiner letzten Entscheidungsposition durchlaufen werden kann, gilt ebenfalls, dass dieser gewählte Entscheidungspfad im inneren, gerichteten Entscheidungsgraphen nicht weiter gefolgt werden kann, und daher, sofern vorhanden, den weiteren Entscheidungspfaden desgleichen RTN-Bausteins gefolgt wird.

Durch diese Auswahlmöglichkeit an den Entscheidungspositionen kann eine gegenüber dem Stand der Technik weitaus flexiblere Gestaltung der Abfrage erreicht werden, insbesondere durch eine Möglichkeit, innerhalb eines jeden RTN-Bausteins beliebig viele Entscheidungspositionen mit einer rekursiven RTN-Baustein-Einsetzposition zu kennzeichnen. Je nach Bedarf können weitere zugehörige Kennzeichen für Entscheidungspositionen festgelegt werden. Insofern ist die Bandbreite der Definition einer Entscheidungsposition nicht auf besondere Eigenschaften oder Funktionen eingeschränkt, sondern kann unter Beachtung der syntaktischen Ordnung beliebig gewählt werden.

Der innere, gerichtete Entscheidungsgraph der RTN-Bausteine wird im Rahmen der Beschreibung durchgehend anhand einer RTN-Syntax ausgedrückt, wie sie in ähnlicher Form bei EBNF' s (Erweiterten Backus-Naur-Formen) verwendet wird, die durch eine Sprungmöglichkeit innerhalb des inneren, gerichteten Entscheidungsgraphen erweitert ist, welche bei Verwendung als Entscheidungsposition mit zugehörigem Kennzeichen in den inneren, gerichteten Entscheidungsgraphen der RTN-Bausteine angeführt wird.

Die wichtigste Abweichung gegenüber dem bekannten ENBF besteht in der Hinzufügung eines eigenen Zeichens für die rekursive RTN-Baustein-Einsetzposition, welche das Einsetzen eines der RTN-Bausteine aus der Gesamtheit der RTN-Bausteine vorschreibt.

Unter einem gerichteten Entscheidungsgraphen eines RTN-Bausteins wird ein gerichteter Graph nach Stand der Technik bezeichnet, wobei die Knoten des Graphen die Entscheidungspositionen darstellen. Ein Entscheidungspfad bezeichnet einen möglichen Weg durch den gerichteten Entscheidungsgraphen von einer innerhalb desselben als erste erreichbare Entscheidungsposition bis zu einer als letzte definierten Entscheidungsposition. Die Summe aller Entscheidungspfade ergeben daher alle Möglichkeiten, einen Entscheidungsgraphen von ersten Entscheidungspositionen bis zu letzten Entscheidungspositionen zu durchlaufen, die Überlagerung dieser verschiedenen Durchlaufmöglichkeiten über die Entscheidungspfade wird graphisch so dargestellt, dass sich an bestimmten Punkten des daraus resultierenden Entscheidungsgraphen Abzweigstellen ergeben.

Zur Kennzeichnung einer Entscheidungsposition für vorgenannte rekursive RTN-Baustein- Einsetzposition wird in der RTN-Syntax der erfindungsgemäßen RTN-Bausteine z.B. das Zeichen * verwendet. Wird an einer Entscheidungsposition eines RTN-Bausteins eine Schlüsselwort-Entscheidungsposition benötigt, so ist dieses erwartete Schlüsselwort in der RTN-Syntax z.B. unter „" zu setzen. Soll an einer Entscheidungsposition in einem RTN- Baustein eine Variable angegeben werden, wird an dieser Entscheidungsposition in der RTN- Syntax z.B. die Zeichenfolge V: und ein Name, der diese Variable aus Gründen der Übersicht kurz beschreibt, angegeben.

Um eine Optionalität einer oder mehrere Entscheidungspositionen im Entscheidungsgraphen, oder mit anderen Worten die Abzweigstellen, die sich aus der Überlagerung der möglichen Entscheidungspfade ergeben, darzustellen, wird z.B. das Zeichen [ für den Beginn einer Optionalität und das Zeichen ] für das Ende der jeweiligen Optionalität verwendet.

Um die oben beschriebene zusätzliche Sprungmöglichkeit festzulegen, sind innerhalb des Entscheidungsgraphen so genannte Sprungpositionen als Entscheidungspositionen vorgesehen, wobei eine Sprungposition auf eine andere Entscheidungsposition Innerhalb des jeweiligen inneren, gerichteten Entscheidungsgraphen weiterleiten kann.

Soll eine derartige Sprungposition innerhalb einer RTN-Syntax an einer Entscheidungsposition ausgeführt werden, so wird für die Entscheidungsposition im Entscheidungsgraphen, auf die gesprungen werden soll, mit dem Zeichen ( gefolgt von einer Nummer und dem Zeichen ) gekennzeichnet, und die Entscheidungsposition, an der ein Sprung ausgeführt werden soll, mit den Zeichen (* gefolgt von der Nummer, auf die gesprungen werden soll und dem Zeichen ) gekennzeichnet.

Um ein logisches exklusives ODER an einer oder mehrerer Entscheidungsposition in einem Entscheidungsgraphen darzustellen, wird das Zeichen ( angegeben, gefolgt jeglichen Entscheidungspositionen, welche Teile dieses obligatorisch alternativen Teil- Entscheidungspfades sind. Zur Trennung gegenüber weiteren zwischen den einzelnen, von einander unabhängigen Teil-Entscheidungspfaden in Zusammenhang mit diesem logischen exklusiven ODER wird^" das das Zeichen | angegeben, gefolgt von dem nächsten" Teil- Entscheidungspfad. Auf diese Weise können beliebig viele Teil-Entscheidungspfade mit einander durch ein ODER verknüpft werden. Als Abschluss eines derartigen logischen exklusiven ODER wird das Zeichen ) angegeben.

Fig.4 und Fig.5 zeigen beispielhaft RTN-Bausteine 50111 und 50112, welche beide jeweils einen Entscheidungspfad 50999 aufweisen und von einander unabhängig definiert sind. Diese beiden RTN-Bausteine 50111 und 50112 können aber, beispielsweise aufgrund von teilweise identen verarbeitungsrelevanten RTN-Baustein-Informationen, zu einem einzigen RTN- Baustein, im Konkreten dem RTN-Baustein Bl_l, durch Überlagerung der Zugriffspfade der beiden RTN-Bausteine zusammengefasst werden, wobei in dem zusammengefassten RTN- Baustein Bl_l die Verwendung eines logischen exklusiven ODER's für die abweichenden Teile der beiden Entscheidungspfade erforderlich ist.

Auf gleiche Weise können die RTN-Bausteine 50131 (Fig. 6) und 50132 (Fig. 7) durch Überlagerung ihrer Zugriffspfade zusammengefasst werden, im Konkreten ist dieser zusamniengefasste RTN-Baustein der RTN-Baustein Bl_3. In dieser Überlagerung der beiden RTN-Bausteine ist die Verwendung einer Optionalität erforderlich, da der RTN-Baustein 50132 eine Entscheidungsposition Schlüsselwort „Y" in seinem Entscheidungspfad 50999 enthält, die im RTN-Baustein 50131 nicht vorhanden ist.

Fig. 18, Fig. 19 und Fig. 20 zeigen die voneinander unabhängigen RTN-Bausteine 50141, 50142 und 50143, wobei der RTN-Baustein 50143 einen RTN-Baustein mit einer endlichen Anzahl an Entscheidungspositionen Schlüsselwort„D" darstellt und somit die Vielzahl aller RTN-Bausteine mit mehr als zwei Entscheidungspositionen Schlüsselwort „D" zeigen soll. Um diese ausschnittweise drei gezeigten RTN-Bausteine mittels Überlagerung ihrer Zugriffspfade 50999 zu einem RTN-Baustein, im Konkreten dem RTN-Baustein Bl_4, zusammenzufassen, ist eine optionale Sprung-Entscheidungsposition erforderlich.

Die RTN-Syntax des RTN-Bausteins Bl_4 wird demnach beim Durchlaufen dieses RTN- Bausteins, also beim Durchlaufen des inneren, gerichteten Entscheidungsgraphen dieses RTN-Bausteins, folgendermaßen gedeutet:

,,A" * (1) „D" [(*1)] *

Die erste Entscheidungsposition des inneren, gerichteten Entscheidungsgraphen des RTN- Bausteins Bl_4 schreibt somit das Schlüsselwort „A" als aktuelles Schlüsselwort in einem zu analysierenden Anfragestatement vor.

Die darauffolgende zweite Entscheidungsposition führt bei Erreichen derselben als Folge des Durchlaufens des inneren, gerichteten Entscheidungsgraphen, also nach erfolgreichem Vergleich der ersten Entscheidungsposition dieses Entscheidungsgraphen mit dem korrespondierenden Schlüsselwort des Anfragestatements, das Einsetzen eines der RTN- Bausteine aus der Gesamtheit derselben aus, welche das Durchlaufen zumindest eines oder mehrerer Bausteine veranlasst, um den im Zusammenhang mit dem zugehörigen Anfragestatement konkret einzusetzenden RTN-Baustein zu ermitteln. Dies geschieht bei Erreichen, da diese zweite Entscheidungsposition als rekursive RTN-Baustein-Einsetzposition ausgebildet ist.

Die im Entscheidungspfad nachfolgende dritte Entscheidungsposition erwartet das Schlüsselwort „D" als aktuelles Schlüsselwort im zu analysierenden Anfragestatement, welches Schlüsselwort sich nach dem schrittweisen Abgleich der Schlüsselworte desgleichen Statements mit den Entscheidungspositionen des an der zweiten Entscheidungsposition rekursiv eingesetzten RTN-Bausteins mit seinen eventuellen weiteren Verschachtelungen als aktuelles Anfrage-Schlüsselwort ergibt.

Nach erfolgreichem Abgleich der dritten Entscheidungsposition folgt eine durch [ ] festgelegte Abzweigstelle, von der ausgehend die zwei bislang an Entscheidungspositionen identen Entscheidungspfade einen voneinander unabhängigen Verlauf nehmen, was bedeutet, dass von dieser Abzweigstelle zwei unterschiedliche Entscheidungspositionen erreicht werden können. Die innerhalb dieser Abzweigmöglichkeit erste mögliche Entscheidungsposition ist die vierte Entscheidungsposition (*1), welche eine Sprungposition auf eine andere Entscheidungsposition im Entscheidungsgraphen definiert, in diesem Fall eine Sprung auf die dritte Entscheidungsposition, welche das Schlüsselwort „D" zum Gegenstand hat. Die alternative zweite mögliche Entscheidungsposition dieser Abzweigstelle ist die fünfte Entscheidungsposition, welche die rekursive RTN-Baustein-Einsetzposition, also das Einsetzen und Durchlaufen eines der RTN-Bausteine aus der Gesamtheit der RTN-Bausteine, bedeutet.

Sobald die fünfte Entscheidungsposition (rekursive RTN-Baustein-Einsetzposition *), deren Eigenschaften bei der zweiten Entscheidungsposition bereits beschrieben wurden sind, erreicht und erfolgreich abgeglichen werden kann, ist das Ende dieses RTN-Baustein Bl_4 erreicht.

Es kann daher sowohl an der zweiten als auch an der fünften Entscheidungsposition ein RTN- Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt werden, welcher selbst wiederum eine rekursive RTN-Baustein-Einsetzposition an zumindest einer Entscheidungsposition seines Entscheidungsgraphen aufweist, so kann beispielsweiche auch derselbe RTN-Baustein Bl_4 an eine oder beide der Entscheidungspositionen seines inneren, gerichteten Entscheidungsgraphen eingesetzt werden, wodurch insgesamt eine beliebig oftmalige rekursiv verschachtelte Ausführung der rekursiven RTN-Baustein-Einsetzposition ermöglicht wird. Welche der RTN-Bausteine jeweils verwendet und eingesetzt werden, ergibt sich aus dem erfolgreichem Durchlaufen eines als äußersten festgestellten RTN-Bausteins und aus dem Erreichen des letzten Schlüsselwortes das abzuarbeitenden Anfragestatements.

Ausgehend von den im Beispiel 1 definierten RTN-Bausteinen ist im nachfolgend angegebenen Bespiel 2 folgendes Anfragestatement gültig:

Beispiel 2:

Zu verarbeitende Syntax: A X X B D D D A D

Es ergibt sich für die in Beispiel 2 angegebene Syntax folgende rekursive Verschachtelung im RTN-Baustein B 1_4:

RTN-Baustein B 1_4: „A" *-Positionl „D" „D" „D" *-Position3

*-Positionl setzt den RTN-Baustein Bl_6 ein: RTN-Baustein Bl_6: „X" *-Position2 „B"

*-Position2 setzt den RTN-Baustein Bl_3 ein: RTN-Baustein B 1_4: „X"

*-Position3 setzt den RTN-Baustein Bl_5 ein: RTN-Baustein B 1_5 : „ A" ,JD"

Dieses ermittelte RTN-Baustein- Verschachtelung für Beispiel 2 ist in Fig.46 grafisch gezeigt. In dieser Figur ist die Reihenfolge des Durchlaufens der Schlüsselworte des Anfragestatements mit den in Klammern gesetzten Ziffern (1), (2), ... (9) und deren Korrespondenz zu Schlüsselwort-Entscheidungspositionen der ausgewählten RTN-Bausteine verdeutlicht.

Aus dem gezeigten Beispiel 2 ist ersichtlich, dass gemäß dem Anfragestatement eine zugehörige RTN-Baustein-Verschachtelung ermittelt wurde, welche zugehörige RTN- Baustein-Verschachtelung den RTN-Baustein Bl_4 als äußersten RTN-Baustein umfasst, aus welchem folgender Entscheidungspfad aus seinem inneren, gerichteten Entscheidungsgraphen ausgewählt wurde: „A" * „D" „D" „D" *

Weiters ist aus dem gezeigten Beispiel 2 ersichtlich, dass die zugehörige RTN-Baustein- Verschachtelung weiter eingesetzte, innere RTN-Bausteine umfasst, nämlich die RTN- Bausteine B 1 6, Bl_3 und B 1 5, von welchen ebenfalls jeweils ein Entscheidungspfad ihrer inneren, gerichteten Entscheidungsgraphen ausgewählt wurde.

Somit ergibt sich für Beispiel 2 die folgende hierarchische Verschachtelung der RTN- Bausteine mit den diesen zugeordneten, nicht näher definierten verarbeitungsrelevanten RTN- Baustein-Informationen:

RTN-Baustein Bl_4 Verarbeitungsrelevante Informationen V4_l bis V4_x RTN-Baustein Bl_6 Verarbeitungsrelevante Informationen V6_l bis V6_x

RTN-Baustein Bl_3 Verarbeitungsrelevante Informationen V3_l bis V3_x

RTN-Baustein B 1_5 Verarbeitungsrelevante Informationen V5_l bis V5_x

Fig.47 zeigt zur Verdeutlichung diese zusammengefasste hierarchische Verschachtelung der RTN-Bausteine ohne Angabe der von Schlüsselworten und rekursiven RTN-Baustein- Einsetzpositionen 300 als grafische Darstellung.

An diesem Punkt angelangt steht nun der fertig gestellte oder erweiterte bzw. geänderte Satz an RTN-Bausteinen zur Formulierung und Abarbeitung von Anfragen zur Verfügung und es kann der nachfolgende Verfahrensschritt angewandt werden, mit dem für die weitere Verarbeitung eine hohe Geschwindigkeit erzielt wird: Bilden einer von den RTN-B austeinen unabhängigen Verweisgruppe, deren Datenstuktur in Tabelle 1 beispielhaft angegeben ist und deren Elemente auf von ihrer ersten Entscheidungsposition befreiten Rest-Entscheidungsgraphen verweisen, indem für jeden RTN-Baustein unabhängig von den anderen RTN-Bausteinen folgende Unterschritte ausgeführt werden: o Bestimmen aller Entscheidungspositionen, welche als erste Entscheidungsposition im jeweiligen RTN-Baustein erreicht werden können, und Hinzufügen derselben in die RTN-Baustein-unabhängige Verweisgruppe als deren Elemente, o Bilden der Rest-Entscheidungsgraphen für alle ersten erreichbaren

Entscheidungspositionen, indem die ausgehend von der jeweils ersten Entscheidungsposition verfolgbaren Entscheidungspfade unter Weglassung dieser ersten Entscheidungsposition zusammengefasst werden und die jeweiligen verarbeitungsrelevanten Baustein-Informationen hinzugefügt wird, sodass nach Ausführen aller Unterschritte für sämtliche RTN-Bausteine die Verweisgruppe die ersten Entscheidungspositionen aller RTN-Bausteine enthält, und diese ersten Entscheidungspositionen auf die ihnen zugehörigen Rest-Entscheidungsgraphen verweisen.

Für die in Beispiel 1 angegebenen RTN-Bausteine wird die Bildung der RTN-Baustein- unabhängigen Verweisgruppe zur Erklärung für drei dieser RTN-Bausteine detailliert gezeigt:

Entscheidungsgraph von RTN-Baustein Bl_l:

(a\A" I f2)"V" f3)"W") ffl* (5) ..B» ffl* f7)"A"

Als erste Entscheidungspositionen in diesem RTN-Baustein B 1 1 können die Entscheidungsposition (1)„A" und die Entscheidungsposition (2)„V" erreicht werden.

Daher werden der unabhängigen Verweisgruppe die Entscheidungsposition (1)„A" und die Entscheidungsposition (2)„V" als Elemente hinzugefügt.

Als von der ersten Entscheidungsposition des RTN-Bausteins Bl_l (1)„A" erreichbarer Rest- Entscheidungsgraph ergibt sich daher: (4)* (5)„B" (6)* (7)„A" mit verarbeitungsrelevanter RTN-Baustein Informationen

(VRB-I) Vl_l bis Vl_x

Das Element „A" in der RTN-Baustein-unabhängigen Verweisgruppe verweist auf diesen Rest-Entscheidungsgraphen, wodurch sich ergibt:

(1)„A" -> (4)* (5)„B" (6)* (7)„A"

Als von der zweiten Entscheidungsposition des RTN-Bausteins Bl_l (2)„V" erreichbarer Rest-Entscheidungsgraph ergibt sich daher:

(3)„W" (4)* (5)„B" (6)* (7)„A" mit VRB-I Vl_l bis Vl_x

Das Element „V" in der RTN-Baustein-unabhängigen Verweisgruppe verweist auf diesen Rest-Entscheidungsgraphen, wodurch sich ergibt:

(2)„V" -> (3)„W" (4)* (5)„B" (6)* (7)„A"

Fig. 2 zeigt den RTN-Baustein 50001, der im obigen als RTN-Baustein Bl_l bezeichnet ist, mit einem inneren, gerichteten Entscheidungsgraphen 50888. Die beiden als - erste erreichbaren Entscheidungspositionen Schlüsselwort „V" und Schlüsselwort „A" sind mit dem Bezugszeichen 40000 gekennzeichnet, alle anderen, nicht als erste Entscheidungspositionen erreichbaren Entscheidungspositionen sind mit dem Bezugszeichen 40001 gekennzeichnet.

Entscheidungsgraph von RTN-Baustein Bl_2: ..A" * ..C" * "B" (der Einfachheit halber fortan ohne Nummerierung der Entscheidungspositionen)

Als erste Entscheidungspositionen in diesem RTN-Baustein B 1 2 kommt die Entscheidungsposition 1 „A" in Frage. Daher wird der unabhängigen Verweisgruppe die Entscheidungsposition „A" als Element hinzugefügt.

Als von der ersten Entscheidungsposition des RTN-Bausteins Bl_2 „A" erreichbarer Rest- Entscheidungsgraph ergibt sich daher:

* „C" * „B" mit VRB-I V2_l bis V2_x

Das Element „A" in der RTN-B austein-unabhängigen Verweisgruppe verweist auf diesen Rest-Entscheidungsgraphen, wodurch sich ergibt:

„A" -> * „C" * „B"

Fig. 3 zeigt den RTN-Baustein 50002, der im obigen als RTN-Baustein Bl_2 bezeichnet ist, mit einem inneren, gerichteten Entscheidungsgraphen 50888. Die einzige als erste erreichbare Entscheidungspositionen Schlüsselwort „A" ist mit dem Bezugszeichen 40000 benannt, alle übrigen, nicht als erste erreichbaren Entscheidungspositionen sind mit dem Bezugszeichen 40001 gekennzeichnet.

Entscheidungsgraph von RTN-Baustein Bl 3: „X" ["Y"l

Als erste Entscheidungsposition in diesem RTN-Baustein Bl_3 kommt die Entscheidungsposition 1 „X" in Frage

Daher wird der unabhängigen Verweisgruppe die Entscheidungsposition „X" als Element hinzugefügt.

Als von der ersten Entscheidungsposition des RTN-Bausteins Bl_3 „X" erreichbarer Rest- Entscheidungsgraph ergibt sich daher:

[,,Y"] mit VRB-I V3_l bis V3_x Das Element „X" in der RTN-B austein-unabhängigen Verweisgruppe verweist auf diesen Rest-Entscheidungsgraphen, wodurch sich ergibt:

„X" -> UY"]

Nach der vorstehend beschriebenen Anwendung des Verweisgruppen-bildenden Schrittes auf die Gesamtheit der in Beispiel 1 angegebenen RTN-Bausteine enthält die RTN-Baustein- unabhängige Verweisgruppe die folgenden Elemente mit den entsprechenden Verweisen auf Rest-Entscheidungsgraphen: (wobei: VRB-I= verarbeitungsrelevante RTN-Baustein-Information)

,Λ" -> * B" * „A" VRB-I: vi_ 1 bis Vl_ X

„A" -> * „C" * ,3" VRB-I: V2_ 1 bis V2_ X

„A" -> * (1) , ,D" [(*1)] * VRB-I: V4_ _1 bis V4_ X „A" -> "D" [' VRB-I: V5_ _1 bis V5_ X

V" -> „W" * : „ DJD" * „Λ Λ " VRB-I: vi_ _.1 bis Vl_ X

„X" -> [,,Y"] VRB-I: V3_ 1 bis V3_ X

„X" -> * „B" VRB-I: V6_ 1 bis V6_ X

* -> VRB-I: V7_ _1 bis V7_ X * -> "T " * "M" VRB-I: V8 1 bis V8 X

Um die Anzahl der Elemente der RTN-Baustein-unabhängigen Verweisgruppe zu verringern, können gleiche Elemente der RTN-Baustein-unabhängigen Verweisgruppe in einem Zusammenfassungsschritt zu einem einzigen Element in dieser Verweisgruppe zusammengefasst und die zugehörigen, ursprünglich mehreren und von einander unabhängigen Rest-Entscheidungsgraphen durch deren Überlagerung zu jeweils einem einzigen Rest-Entscheidungsgraphen zusammengefasst werden.

Für das Element „A" in dieser obigen Verweisgruppe, welches insgesamt viermal in derselben vorkommt, entsteht nach Zusammenfassung zu einem einzigen Element „A" in dieser RTN-Baustein-unabhängigen Verweisgruppe und Bilden des optimalen Rest- Entscheidungsgraphen durch Zusammenfassung mittels Überlagerung aller einzelnen Rest- Entscheidungsgraphen folgender neuer Rest-Entscheidungsgraph für seinen Verweis:

„A" -> ( * 03" * ,Λ" I „C" * „B" I (1) „D" [(*1)] * ) I „D" [* „E"])

Für das Element „X" in der obigen Verweisgruppe, welches insgesamt zweimal in der derselben vorkommt, entsteht nach Zusammenfassung zu einem einzigem Element „X" in dieser RTN-Baustein-unabhängigen Verweisgruppe und Bilden des optimalen Rest- Entscheidungsgraphen durch Zusammenfassung mittels Überlagerung aller einzelnen Rest- Entscheidungsgraphen folgender neuer Rest-Entscheidungsgraph für seinen Verweis:

„X" -> ( [,,Y"] I * ,3" )

Der zusammengefasste Rest-Entscheidungsgraph des Verweisgruppen-Elements „X" hat aufgrund einer seiner Entscheidungspfade, welchem erst bei erfolglosem Vergleichen mit der

Entscheidungsposition Schlüsselwort „Y" sowie der * -Entscheidungsposition, gefolgt werden kann, die Möglichkeit, den RTN-Baustein trotz dieser erfolglosen Vergleiche erfolgreich zu verlassen. Dieser zusätzliche Entscheidungspfad ergibt sich aus dem RTN-Baustein Bl_3, welcher seine zweite und gleichzeitig letzte Entscheidungsposition Schlüsselwort "Y" als optionale Entscheidungsposition gekennzeichnet hat.

Somit wird der Rest-Entscheidungsgraph des Verweisgruppen-Elements „X" nochmals so umgewandelt, dass das .Kennzeichen der Optionalität für das gesamte logische exklusive ODER gilt:

„X" -> [ („Y" | * „B" ) ]

Durch diese einfache weitere Umwandlung wird eine weitere Vereinfachung des Rest- Entscheidungsgraphen in diesen und ähnlichen Fällen erzielt, weil jetzt eindeutig geprüft wird, ob die KANN-Bestimmung entweder für die Entscheidungsposition „Y" oder die rekursive RTN-Baustein-Einsetzposition * zutrifft, und in jenen Fällen, wo die KANN- Bestimmung nicht zutrifft, kann der RTN-Baustein als erfolgreich durchlaufen gekennzeichnet werden. Für das Element * in der obigen Verweisgruppe, welches insgesamt zweimal in der derselben vorkommt, entsteht nach Zusammenfassung zu einem einzigen Element * in der RTN- Baustein-unabhängigen Verweisgruppe und Bilden des optimalen Rest-Entscheidungsgraphen durch Zusammenfassung mittels Überlagerung aller einzelnen Rest-Entscheidungsgraphen folgender neuer Rest-Entscheidungsgraph für seinen Verweis:

* -> ( „K" * I „L" * „M" )

Somit ergibt sich insgesamt folgende RTN-Baustein-unabhängige Verweisgruppe mit entsprechenden Verweisen je Element auf ihre Rest-Entscheidungsgraphen:

„A" -> ( * („B" * „A" I „C" * „B" I (1) „D" [(*1)] * ) | „D" [* „E"])

„V" -> „W" * „B" * „A" „X" -> [ ( ,,Y" I * „B" ) ]

* -> ( „K" * I „L" * „M" )

Sowohl die Elemente der Verweisgruppe als auch die ihnen zugeordneten Rest- Entscheidungsgraphen sind unabhängig von den sie bildenden angegebenen RTN-Bausteinen. Trotzdem sind die verarbeitungsrelevanten RTN-Baustein-Informationen der RTN-Bausteine in der sich durch ein zu analysierende Statement ergebenden Verschachtelung für die weitere Verarbeitung und insbesondere für die Erstellung eines Zugriffsplans weiterhin erforderlich. Das wird dadurch sichergestellt, dass bei Anwendung des obigen Zusammenfassungsschrittes auf gleiche Elemente der Verweisgruppe und deren Rest-Entscheidungsgraphen jeder Entscheidungsposition der Rest-Entscheidungsgraphen sämtliche verarbeitungsrelevante RTN-Baustein-Informationen genau eines diese Entscheidungsposition als solche enthaltenden RTN-Bausteins zugewiesen werden.

Dadurch kann bei Analyse der Syntax des zu analysierenden Statements über die Verweisgruppe und deren Rest-Entscheidungsgraphen sowohl die Verschachtelung als auch die zugehörigen verarbeitungsrelevanten RTN-Baustein-Informationen zur weiteren Verarbeitung und somit auch zum Generieren eines Zugriffsplans herangezogen werden. Die bausteinrelevanten Informationen Vl_l bis Vl_x werden in der weiteren Beschreibung der Einfachheit wegen nachfolgend als Vl bezeichnet, die bausteinrelevanten Informationen V2_l bis V2_x werden als V2 usw.

Anhand des Verweisgruppen-Elements „X" mit zugehörigem Rest-Entscheidungsgraph soll dies im nachfolgenden Beispiel verdeutlicht werden, wozu nochmals das Element „X" aus der Verweisgruppe vor Anwendung des Zusammenfassungsschritts, aber mit den verarbeitungsrelevanten RTN-Baustein-Informationen je Entscheidungsposition gezeigt wird:

"X" -> V3 [„Y" V3] Entscheidungspositionen enthaltender RTN-Baustein: B 1_3

„X" -> * V6 „B" V6 Entscheidungspositionen enthaltender RTN-Baustein: B 1_6

Nach Überlagerung dieser beiden Rest-Entscheidungsgraphen des Verweisgruppenelements „X" ergibt sich folgender neuer Rest-Entscheidungsgraph mit übernommenen verarbeitungsrelevanten RTN-Baustein-Informationen je Entscheidungsposition:

„X" -> (Y3 [„Y" V3] I * V6 „B" V6 )

Somit ergibt sich folgende Verweisgruppe mit entsprechenden Verweisen je Element auf ihre Rest-Entscheidungsgraphen, wobei allen in Rest-Entscheidungsgraphen vorkommenden Entscheidungspositionen die zugehörigen verarbeitungsrelevanten RTN-Baustein- Informationen bereits zugeordnet sind:

,Λ" →

( * Yi(„B"Yl * Vl „A" YiI „C" V2 * Y2 „B" V2 I (1) „D" V4 [(*I)] * V4) I „D"

V5[*V5„E"V5]) „V" → „W"yi*Yl„B"VL*Vi„A"Vl

„X" →

V3[(„Y"V3| *V6„B" V6)] ( „K" V7 * V7 I „L" V8 *JV8 „M" V8 )

Fig.29 zeigt das Element „A" der Verweisgruppe mit dem Bezugszeichen 50501 mit zugehörigem zusammengefassten Rest-Entscheidungsgraphen 50511. Desgleichen zeigt Fig.30 zeigt das Element „V" der Verweisgruppe mit dem Bezugszeichen 50502 mit zugehörigem zusammengefassten Rest-Entscheidungsgraphen 50512. Fig.31 zeigt das Element „X" der Verweisgruppe mit dem Bezugszeichen 50503 mit zugehörigem zusammengefassten Rest-Entscheidungsgraphen 50513 und Fig.32 stellt das Element „* der Verweisgruppe mit dem Bezugszeichen 50530 mit zusammengefassten Rest- Entscheidungsgraphen 50531 grafisch dar. Um die Übersicht zu wahren, zeigen sämtliche dieser Figuren nur die Entscheidungspositionen der inneren, gerichteten Rest- Entscheidungsgraphen ohne zugehörige verarbeitungsrelevante RTN-Baustein-Informationen.

Das Verweisgruppen-Element „X" hat als eine nachfolgende Entscheidungsposition eine Optionalität insofern angegeben, als dass ein Schlüsselwort „X" alleine ausreicht, um bei Identifizieren des Verweisgruppen-Elements „X" die Verarbeitungsfunktion V3 zu erhalten. Diese Kennzeichnung „Verarbeitungs-Funktion V3" steht zum Beispiel vor der ersten auszuführenden Entscheidungsposition seines Rest-Entscheidungsgraphen.

Wie man an dem obigen Beispiel für die Verweisgruppen-Elemente „A", „X" und „*" ersehen kann, können die endgültigen verarbeitungsrelevanten RTN-Baustein-Informationen sich mitunter erst nach . einer Reihe von in Abhängigkeit einer zu analysierenden Syntax aufgerufenen Entscheidungspositionen ergeben. Grundsätzlich ist die Kennzeichnung einer Position, an der die einer Entscheidungsposition zugeordneten verarbeitungsrelevanten RTN- Baustein-Informationen gesetzt ist, variierbar und schränkt die Erfindung nicht ein.

Der Vorteil einer zusammengefassten, also um Duplikate bereinigten und entsprechend Rest- Entscheidungsgraphen Verweisgruppe besteht in der höheren Analyse-Geschwindigkeit eines Statements.

Eine Verarbeitung ohne RTN-Baustein-unabhängige Verweisgruppe könnte beispielsweise vorschreiben, dass in einem Auswahlschritt die inneren Entscheidungsgraphen aller RTN-Bausteine anhand der Schlüsselworte durchlaufen werden, und allen möglichen Pfaden dieser Entscheidungsgraphen solange gefolgt wird, bis entweder keine Übereinstimmung mit dem jeweils gewählten Pfad durch den Entscheidungsgraphen festgestellt und der Vorgang abgebrochen wird oder der jeweils gewählte Pfad bis zum Ende durchlaufen wird,

wobei zumindest ein Teil der Entscheidungspfade an zumindest einer der Entscheidungspositionen eine rekursive RTN-Baustein-Einsetzposition aufweist, durch welche einer der RTN-Bausteine als Ergebnis der Anwendung des Auswahlschrittes auf die Gesamtheit der RTN-Bausteine durchlaufen wird, sodaß eine beliebig oftmalige rekursiv verschachtelte Ausführung des Auswahlschrittes ausgehend von der zumindest einen der Entscheidungspositionen ermöglicht wird.

Der durch Einführen und Anwenden der Verweisgruppe behobene Nachteil eines derartigen Auswahlschrittes liegt im Wegfallen einer ganzen Reihe von sonst durchzuführenden potenziell erfolglosen Durchläufen von Entscheidungsgraphen der RTN-Bausteine, da der für eine bestimmte Folge von Schlüsselworten eines Statements passende RTN-Baustein in der Vielzahl der angegebenen RTN-Bausteine in ungünstigen Fällen an mittlerer oder sogar hinterer Position zu finden ist.

Die Bildung der RTN-Baustein-unabhängigen Verweisgruppe erfolgt einmalig für ein RTN mit dem ihm zugehörigen RTN-Bausteinen und wird dann neu generiert, wenn sich zumindest einer der RTN-Bausteine des RTN' s ändern bzw. dem RTN neue RTN-Bausteine hinzugefügt oder vorhandene RTN-Bausteine entfernt werden.

Nach Bildung der RTN-Baustein-unabhängigen Verweisgruppe mit der Zuordnung von Rest- Entscheidungsgraphen für die einzelnen Elemente derselben wird ein abzuarbeitendes Statement durch verfahrensmäßiges Finden und Folgen der Elemente der Verweisgruppe und deren Rest-Entscheidungsgraphen analysiert und verschachtelt, sodass durch die bausteinrelevanten Informationen in einem nachfolgenden Schritt ein Zugriffsplan für das relationale Datenbanksystem erzeugt wird. Verfahrensmäßig werden alle Schlüsselworte des abzuarbeitenden Statements durchlaufen, indem für das an erster Stelle im abzuarbeitenden Statement stehende Schlüsselwort ein Verweisausführungsschritt ausgeführt wird, in welchem das übereinstimmende Schlüsselwort in der Verweisgruppe gesucht und bei Auffinden desselben dem zugeordneten Rest- Entscheidungsgraph derart gefolgt wird,

dass die jeweils nachfolgenden Schlüsselworte des abzuarbeitenden Statements durchlaufen werden, und allen möglichen Entscheidungspfaden des zugeordneten Rest- Entscheidungsgraphen solange gefolgt wird, bis entweder keine Übereinstimmung mit dem jeweils gewählten Entscheidungspfad festgestellt und der betreffende Verweisausführungsschritt abgebrochen wird oder der jeweils gewählte Entscheidungspfad bis zum Ende durchlaufen wird,

wobei an jenen erreichten Entscheidungspositionen des zugeordneten Rest- Entscheidungsgraphen, welche die rekursive RTN-Baustein-Einsetzposition ausbilden, der Verweisausführungsschritt rekursiv auf das nachfolgende Anfrageschlüsselwort zur Anwendung gebracht wird.

Bezug nehmend auf die in Beispiel 1 angegebenen RTN-Bausteine B 1 1 bis Bl_8 und auf die in Beispiel 2 angegebene zu analysierende Syntax „A X X B D D D A D" wird in Beispiel 3 die Analyse dieses Statements mittels der Verweisgruppe schrittweise gezeigt:

Beispiel 3:

Zu analysierende Syntax: A(I) X(2) X(3) B(4) D(5) D(6) D(7) A(8) D(9)

Nochmals sei die zu verwendende Verweisgruppe mit deren Elementen und diesen Elementen zugeordneten Rest-Entscheidungspositionen angeführt:

„A" -> ( * („B" * „A" I „C" * „B" I (1) „D" [(*1)] * ) I „D" [• „E"] ) V" -> W" * B" * A"

„X" -> [ ( ,,Y" I * „B" ) ]

-> ( „K" * I „L" * „M" ) Auffinden des an erster Stelle stehenden Schlüsselwortes ,,A"(1) in der Verweisgruppe Element „A" wird in der Verweisgruppe gefunden, daher Ausführung des Verweisausfuhrungsschrittes, also Abgleich der im Statement folgenden Schlüsselworte mit dem dem Element „A" der Verweisgruppe zugeordneten Rest-Entscheidungsgraphen.

„A" -> ( * 03" * , A" I „C" * „B" I (1) „D" [(* I)] * ) I „D" [* „E"] )

Die erste zu vergleichende Entscheidungsposition im Rest-Entscheidungsgraphen des Elements „A" in der Verweisgruppe eine *-Position, also eine Position, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt und durchlaufen werden soll.

Die aktuelle rekursive Aufrufreihenfolge sieht daher folgendermaßen aus: 1. Verweisgruppen-Element: „ A"

Wie beschrieben bedeutet dies, dass das im Statement aktuelle, also dem ersten Schlüsselwort ,,A"(1) folgende Schlüsselwort ,,X"(2) in der Verweisgruppe als rekursiver Aufruf gesucht wird.

Schlüsselwort ,,X"(2) wird in der RTN-Baustein-unabhängigen Verweisgruppe gefunden, daher wird für das aktuelle, also nächste, Schlüsselwort im Statement ,,X"(3) dem Rest- Entscheidungsgraphen dieses Elements „X" aus der Verweisgruppe gefolgt.

„X" -> [ ( „Y" | * „B" ) ]

Die aktuelle rekursive Aufrufreihenfolge sieht daher folgendermaßen aus: 1. Verweisgruppen-Element: „A" 2. Verweisgruppen-Element: „X" Die zu vergleichende Position im Rest-Entscheidungsgraphen ist: „Y", der Vergleich mit dem aktuellen Schlüsselwort ,,X"(3) des Statements ist nicht erfolgreich, daher wird dem zweiten Entscheidungspfad als aktuellen des Rest-Entscheidungsgraphen gefolgt: * „B"

Diese erste Entscheidungsposition im aktuellen Entscheidungspfad ist eine * -Position, also eine Position, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt und durchlaufen werden soll.

Das weiterhin unveränderter aktuelle Schlüsselwort ,,X"(3) im zu analysierenden Statement wird daher in der Verweisgruppe gesucht. Nachdem dieses Schlüsselwort ,,X"(3) in der Verweisgruppe als Element gefunden wurde, wird dem Rest-Entscheidungsgraphen für dieses Element „X" der Verweisgruppe gefolgt:

„X" -> [ ( „Y" | * „B" ) ]

Die aktuelle rekursive Aufrufreihenfolge sieht daher folgendermaßen aus: 1. Verweisgruppen-Element: „A"

2. Verweisgruppen-Element: „X" 3. Verweisgruppen-Element: „X"

Folgen dieses Rest-Entscheidungsgraphen für das aktuelle, also nächste, Schlüsselwort ,,B"(4) im Statement. Vergleichen des Schlüsselwortes ,,B"(4) mit der Entscheidungsposition „Y" im Rest-Entscheidungsgraphen. Da der Vergleich nicht erfolgreich ist, wird dem zweiten Entscheidungspfad als aktuellen Entscheidungspfad des Rest-Entscheidungsgraphen gefolgt. Diese erste Entscheidungsposition im aktuellen Entscheidungspfad ist eine * -Position, also eine Position, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt und durchlaufen werden soll.

Das aktuelle Schlüsselwort des zu analysierenden Statements ,,B"(4) wird NICHT in der Verweisgruppe gefunden, wodurch die * -Position des aktuellen Rest-Entscheidungsgraphen nicht erfolgreich ausgeführt wurde, und daher dem nächsten Entscheidungspfad als aktuellem Entscheidungspfad gefolgt wird.

Der dritte, aktuelle Entscheidungspfad des Rest-Entscheidungsgraphen besagt aufgrund der Optionalität des ODER₅ dass dieser RTN-Baustein durch Auffinden des Schlüsselwortes ,,X"(3) in der Verweisgruppe bereits erfolgreich durchlaufen wurde.

Nachdem der Verweisausführungsschritt erfolgreich ausgeführt werden konnte, wird die letzte Rekursion beendet und dem weiteren aktuellen Entscheidungspfad des RTN-Bausteins, welcher den Verweisausführungsschritt für seine * -Entscheidungsposition aufgerufen hat, gefolgt:

Die aktuelle rekursive Aufrufreihenfolge sieht daher folgendermaßen aus: 1. Verweisgruppen-Element: „A" 2. Verweisgruppen-Element: „X"

Die nächste Entscheidungsposition im aktuellen Entscheidungspfad der 2. Rekursionsstufe verlangt das Schlüsselwort „B", welches dem aktuellen Schlüsselwort ,,B"(4) im zu analysierenden Statement entspricht.

Durch den erfolgreichen Vergleich mit dieser letzten Position im aktuellen Entscheidungspfad wurde die * -Position der 1. Rekursionsstufe erfolgreich durchlaufen, wodurch die 2. Rekursionsstufe beendet wird.

Die nächste Entscheidungsposition im aktuellen Entscheidungspfad der 1. Rekursionsstufe erwartet das Schlüsselwort „B", welches NICHT gleich dem aktuellen Schlüsselwort ,,D"(5) des zu analysierenden Statements ist. Daher wird dem nächsten Entscheidungspfad im ODER gefolgt, dessen erste Entscheidungsposition das Schlüsselwort „C" verlangt. Da diese Entscheidungsposition ebenfalls nicht dem aktuellen Schlüsselwort ,,D"(5) des zu analysierenden Statements entspricht, wird dem dritten Entscheidungspfad im ODER gefolgt. Diese erste Entscheidungsposition im dritten Entscheidungspfad schreibt das Schlüsselwort „D" vor, aufgrund der Übereinstimmung mit dem aktuellen Schlüsselwort ,,D"(5) im zu analysierenden Statement wird diesem dritten Entscheidungspfad im ODER gefolgt. Die nächste Entscheidungsposition schreibt wieder das Schlüsselwort „D" vor, welches ebenfalls dem aktuellen, also nächsten, Schlüsselwort ,,D"(6) im abzuarbeitenden Statement entspricht. Dem aktuellen Entscheidungspfad weiter folgend, wird wiederum das Schlüsselwort „D" an der aktuellen Entscheidungsposition verlangt, welches ebenfalls dem aktuellen, also nächsten, Schlüsselwort ,,D"(7) im abzuarbeitenden Statement entspricht. Es wird wiederum die nächste Entscheidungsposition im aktuellen Entscheidungspfad der 1. Rekursionsstufe gefolgt, welche wiederum das Schlüsselwort „D" vorschreibt, wobei diese Entscheidungsposition jetzt nicht mehr dem aktuellen, also nächsten, Schlüsselwort ,,A"(8) des zu analysierenden Statements entspricht. Es gibt bei nicht erfolgreichem Vergleich mit der Entscheidungsposition, welche das Schlüsselwort „D" vorschreibt, eine alternative Entscheidungsposition, die erreicht werden kann, nämlich die Entscheidungsposition *, also eine Position, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt und durchlaufen werden soll.

Das weiterhin unveränderte aktuelle Schlüsselwort ,,A"(8) im zu analysierenden Statement wird daher in der Verweisgruppe gesucht. Nachdem dieses Schlüsselwort ,,A"(⁸) in der Verweisgruppe als Element gefunden wurde, wird dem Rest-Entscheidungsgraphen für dieses Element „A" der Verweisgruppe gefolgt:

2. Verweisgruppen-Element: „A"

Die erste Entscheidungsposition der 2. Rekursionsstufe verlangt eine *-Position, also eine Position, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt und durchlaufen werden soll. Das aktuelle, also nächste, Schlüsselwort ,,D"(9) des zu analysierenden Statements wird in der Verweisgruppe nicht gefunden, was bedeutet, dass der Vergleich für aktuelle *- Entscheidungsposition nicht erfolgreich ausgeführt wurde. Deswegen wird dem zweiten Entscheidungspfad des Rest-Entscheidungsgraphen der 2. Rekursionsstufe gefolgt, dessen erste Entscheidungsposition das Schlüsselwort „D" verlangt. Nach dem erfolgreichen Vergleich dieser Entscheidungsposition mit dem aktuellen Schlüsselwort ,,D"(9) wird das Ende des Statements ebenso festgestellt, wie auch der erfolgreiche Durchlauf sowohl der 2. und darauf folgend auch der 1. rekursiven Rekursionsstufe.

Nach Abschluss der Analyse des abzuarbeitenden Statements über die Verweisgruppe und deren Rest-Entscheidungsgraphen ergibt sich für Beispiel 3 folgendes verschachtelte Ergebnis:

„A" *(B1) „D" „D" „D" *(B3) verarbeitungsrelevante RTN-Baustein-Information V4 (Bl): „X" *(B2) „B" verarbeitungsrelevante RTN-Baustein-Information V6

(B2): "X" verarbeitungsrelevante RTN-Baustein-Information V3

(B3): "A" "D" verarbeitungsrelevante RTN-Baustein-Information V5

Definitionsgemäß werden RTN-Bausteine zugelassen, welche an der ersten Entscheidungsposition ihres inneren Entscheidungsgraphen eine * -Entscheidungsposition enthalten, also eine Entscheidungsposition, welche das Einsetzen und Durchlaufen eines der RTN-Bausteine aus der Gesamtheit der RTN-Bausteine vorschreibt.

Wird ein Statement angegeben, welches keine RTN-Bausteine mit einer *- Entscheidungsposition als ihre ersten Entscheidungspositionen enthält, so entspricht die Reihenfolge der im Statement angegebenen Schlüsselworte zwingend der Reihenfolge der Schlüsselworte in der sich ergebenden RTN-B austein-Verschachtelung mittels an *- Entscheidungspositionen eingesetzten RTN-Bausteinen. Dies soll folgendes einfache Beispiel unter Verwendung von RTN-B austeinen, die später nachfolgend beschrieben werden, darstellen:

Gegebenes Statement: (i)[ (2)WHERE (3)( (4)A (5)) (6)SELECT (7)B (8)]

Für die weitere Verarbeitung zu verwendende RTN-Baustein-Verschachtelung, welche aufgrund des obigen Statements erstellt wird:

(1)[ * * (8)] (2)WHERE *

(3)( * (5))

(4)A (6)SELECT *

(7)B

Die gemeinsame Besonderheit aller mit einer * -Entscheidungsposition an erster Stelle beginnenden RTN-Bausteine liegt darin, dass deren erste Entscheidungsposition ohne allfällige Umwandlung nicht direkt ausgewertet werden kann, da an dieser ersten, als *- Entscheidungsposition gekennzeichneten, Entscheidungsposition zwar genau ein RTN- Baustein eingesetzt wird, in diesem aber in welchem wiederum aufgrund der rekursiven RTN- Baustein-Einsetzposition. eine beliebig oftmalige Verschachtelung von RTN-Bausteinen eingesetzt werden kann.

Dies bedeutet, dass in einem angegebenen Statement den Schlüsselworten entsprechend RTN- Bausteine aus deren Gesamtheit der RTN-Bausteine identifiziert werden und deren inneren, gerichteten Entscheidungsgraphen gefolgt wird, nach Beendigung eines der identifizierten RTN-Bausteine aber im angegebenen Statement ein nachfolgendes Schlüsselwort vorhanden sein kann, welches einen RTN-Baustein mit einer * -Entscheidungsposition an erster Stelle, welche aber vorher nicht identifiziert werden konnte, aufrufen soll.

Gegebenes Statement: (I)A (2)+ (3)B (4)= (5)C Nachdem das erste Schlüsselwort des Statements (I)A einen angenommenen einfachsten RTN-Baustein mit nur einer Entscheidungsposition Schlüsselwort „A" erfolgreich durchläuft, wird das nächste Schlüsselwort (2)= in der angegebenen Syntax angetroffen. Es gibt keinen RTN-Baustein, welcher mit einer ersten Entscheidungsposition Schlüsselwort „=" beginnt, aber es ist ein RTN-Baustein mit der RTN-Syntax* „=" * vorhanden. Es kann das Schlüsselwort „=" aber nur dann ausgewertet werden, wenn die erste Entscheidungsposition * dieses RTN-Bausteins vorübergehend übersprungen bzw. entfernt wird.

Es soll für das oben gegebene Statement die folgende Verschachtelung aufgrund der angegebenen RTN-Bausteine, von welchen im konkreten Fall genau zwei eine *- Entscheidungsposition an erster Stelle vorschreiben, generiert werden:

* (4)= *

* (2)+ * (I)A

(3)B (5)C

Um bei jedem Statement die Feststellung und Verschachtelung der verwendeten RTN- Bausteine mit ihren verarbeitungsrelevanten RTN-Baustein-Informationen mittels eines Algorithmus zu ermöglichen, ist daher die Anwendung eines Umwandlungsschrittes vor der Abarbeitung des zu analysierenden Statements notwendig, wobei die RTN-Bausteine in zwei Gattungsgruppen unterteilen werden und bei jedem RTN-Baustein die entsprechende Gattungsgruppe für die weitere Verarbeitung als eine der verarbeitungsrelevanten RTN- Baustein-Informationen vermerkt wird.

Nach dem Voreinstellungsschritt, in dem die RTN-Bausteine definiert werden, wird in einem Umwandlungsschritt vor Ausführung des Verweisgruppen-bildenden Schrittes und somit jedenfalls vor Analyse eines angegebenen Statements jeder RTN-Baustein entweder einer ersten oder einer zweiten Gattungsgruppe zugeordnet, wobei die RTN-Bausteine, die mit Text, Sonderzeichen, Variable oder Zahl als erste erreichbare Entscheidungsposition beginnen, der ersten Gattungsgruppe zugeordnet und derart umgewandelt werden, dass die Entscheidungspositionen, die eine rekursive RTN-Baustein- Einsetzposition, welche das Einsetzen und Durchlaufen eines der RTN-Bausteine aus der Gesamtheit alle definierten RTN-Bausteine vorschreibt, enthalten, darauf beschränkt werden, dass das Einsetzen und Durchlaufen nur auf einen RTN-Baustein der ersten Gattungsgruppe beschränkt wird, und

die RTN-Bausteine, die mit einer rekursiven RTN-Baustein-Einsetzposition als erste erreichbare Entscheidungsposition beginnen, der zweiten Gattungsgruppe zugeordnet und derart umgewandelt werden, dass die erste Entscheidungsposition entfernt wird und

Entscheidungspositionen, die eine rekursive RTN-Baustein-Einsetzposition, welche das

Einsetzen und Durchlaufen eines der RTN-Bausteine aus der Gesamtheit alle definierten

RTN-Bausteine vorschreibt, enthalten, darauf beschränkt werden, dass das Einsetzen und Durchlaufen nur auf einen RTN-Baustein der ersten Gattungsgruppe beschränkt wird, und

allen RTN-Bausteine der ersten Gattungsgruppe und jene RTN-Bausteinen der zweiten Gattungsgruppe, welche mit einem Text, Sonderzeichen, Variable oder Zahl an der letzten Entscheidungsposition enden, eine optional ausführbare Entscheidungsposition an letzter Stelle angehängt wird, an welcher das Einsetzen und Durchlaufen eines RTN-Bausteins der zweiten Gattungsgruppe vorgeschrieben ist.

Zum Beispiel sei die Umwandlung für einen der in Beispiel 1 angegebenen RTN-Bausteine ohne * -Entscheidungsposition als erste Entscheidungsposition im inneren Entscheidungsgraphen des RTN-Bausteins gezeigt:

RTN-Baustein B 1_2:

,,/\ ,,V_^ „D Zuordnung zur ersten Gattungsgruppe -> Umgewandelte RTN-Syntax:

„A" RTN-Baustein erster Gattungsgruppe „C" RTN-Baustein erster Gattungsgruppe „B" [RTN-Baustein zweiter Gattungsgruppe] Zum Beispiel sei die Umwandlung für einen RTN-Baustein mit * -Entscheidungsposition als erste Entscheidungsposition und mit *-Entscheidungsposition als letzte Entscheidungsposition im inneren Entscheidungsgraphen des RTN-Bausteins gezeigt:

RTN-Baustein Bl_7:

* TT^"" φ

Zuordnung zur zweiten Gattungsgruppe -> Umgewandelte RTN-Syntax: „K" RTN-Baustein erster Gattungsgruppe

Zum Beispiel sei die Umwandlung für einen RTN-Baustein mit *-Entscheidungsposition als erste Entscheidungsposition und ohne * -Entscheidungsposition als letzte Entscheidungsposition im inneren Entscheidungsgraphen des RTN-Bausteins gezeigt:

RTN-Baustein B 1 8:

* L" * M"

Zuordnung zur zweiten Gattungsgruppe -> Umgewandelte RTN-Syntax:

„L" RTN-Baustein erster Gattungsgruppe „M" [RTN-Baustein zweiter Gattungsgruppe]

Die Figuren 33, 34 bis 40 zeigen die RTN-Bausteine Bl_l (50001), Bl_2 (50002), bis B1 8 (50008) mit jeweils einem inneren, gerichteten Entscheidungsgraph 50888, wie er sich je RTN-Baustein nach dem oben gezeigten Umwandlungsschritt ergibt. Die an den betroffenen Entscheidungspositionen umgewandelte * -Entscheidungsposition 300, welche nunmehr das Einsetzen und Durchlaufen eines RTN-Bausteins aus der Gesamtheit der RTN-Bausteine aus der ersten Gattungsgruppe vorschreibt, wird in allen Figuren als X-Baustein gekennzeichnet und mit der Entscheidungspositions-Nummern und somit mit dem Bezugszeichen 301 versehen. Die sämtliche den Entscheidungsgraphen der RTN-Bausteine als optional angehängten Entscheidungspositionen RTN-Baustein zweiter Gattungsgruppe werden in den Figuren als Y-Baustein gekennzeichnet und mit der Entscheidungspositions-Nummern und somit mit dem Bezugszeichen 302 versehen. Durch diesen Umwandlungsschritt wird sichergestellt, dass jedes angegebene Statement mit Algorithmen nach dem Stand der Technik in RTN-Bausteine zerlegt werden kann, also die volle Flexibilität der RTN-Bausteine bei Formulierung von Anfragen genutzt werden kann.

Nach diesem Umwandlungsschritt ergibt sich, dass jeder RTN-Baustein nach Zuordnung zu einer der Gattungsgrappen und entsprechender Umwandlung seines inneren, gerichteten Entscheidungsgraphen ausschließlich mit zumindest einem Text, zumindest einem Sonderzeichen, einer Variable oder einer Zahl beginnt und die rekursive RTN-Baustein- Einsetzposition, welche das Einsetzen und Durchlaufen eines der RTN-Bausteine aus vormals der Gesamtheit alle definierten RTN-Bausteine vorgeschrieben hat, nun das Einsetzen und Durchlaufen eines RTN-Bausteins entweder nur aus der Gesamtheit der RTN-Bausteine der ersten Gattungsgruppe oder nur aus der Gesamtheit der RTN-Bausteine der zweiten Gattungsgruppe vorschreibt.

Des Weiteren werden nach diesem Umwandlungsschritt RTN-Bausteine der zweiten Gattungsgruppe ausschließlich an letzter Entscheidungsposition eines der Entscheidungsgraphen eines RTN-Bausteins optional aufgerufen.

Die bei der Zuordnung zu Gattungsgruppen ausgeführte Umwandlung für die vorhandene RTN-Bausteine hat auf die Zuordnung der Elemente zu der RTN-Baustein-unabhängigen Verweisgruppe insofern einen Einfluss, als dass die RTN-Baustein-unabhängige Verweisgruppe in eine erste RTN-Baustein-unabhängige Verweisuntergruppe und in eine zweite RTN-Baustein-unabhängige Verweisuntergruppe aufgeteilt wird, wobei

- die als erste erreichbaren Entscheidungspositionen in den Entscheidungsgraphen aller

RTN-Bausteine der ersten Gattungsgruppe der ersten RTN-Baustein-unabhängigen Verweisuntergruppe als deren Elemente mit nach dem Umwandlungsschritt sich ergebenden zugehörigen Rest-Entscheidungsgraphen zugeordnet werden, und

RTN-Bausteine der zweiten Gattungsgruppe der zweiten RTN-Baustein-unabhängigen Verweisuntergruppe als deren Elemente mit nach dem Umwandlungs schritt sich ergebenden zugehörigen Rest-Entscheidungsgraphen zugeordnet werden. Um die Abarbeitung von an erster Stelle stehenden *-Entscheidungspositionen einfacher durchführen zu können, wird diese Einteilung in Verweisuntergruppen vorgenommen.

Durch diese beiden neu eingeführten Verweisuntergruppen wird die zusätzlich die Isomorphie zwischen den zwei Gattungsgruppen zugeordneten und entsprechend umgewandelten RTN- Bausteinen und der Verweisgruppe sichergestellt, womit die womit eine algorithmische Analyse anhand der Verweisgruppen ebenfalls einfach durchgeführt werden kann.

Für die im Beispiel 1 angegebenen RTN-Bausteine ergibt sich somit folgende RTN-B austein- unabhängige Verweisgruppe mit nachstehenden Elementen in der ersten Verweisuntergruppe mit unveränderten verarbeitungsrelevanten RTN-Baustein-Inforniationen je Entscheidungsposition:

Beispiel 4:

Elemente der ersten Verweisuntergruppe:

„A" ->

{RTN-Baustein erster Gattungsgruppe Vl („B" Vi RTN-Baustein erster Gattungsgruppe Yl „A" Vl | „C" V2 RTN-Baustein erster Gattungsgruppe V2 „B" V2 |

(1) „D" V4 [(*1)] RTN-Baustein erster Gattungsgruppe V4 ) | „D" V5 [RTN- Baustein erster . Gattungsgruppe V5 „E" V5 ]) [RTN-Baustein zweiter Gattungsgruppe]

„V" ->

„W" Vi RTN-Baustein erster Gattungsgruppe Vi „B" YJ_ RTN-Baustein erster Gattungsgruppe V\ „A" Vl [RTN-Baustein zweiter Gattungsgruppe]

„X" ->

Yl [ ( „Y" V3 I RTN-Baustein erster Gattungsgruppe V6 „B" V6 ) ] [RTN-Baustein zweiter Gattungsgruppe] Für die im Beispiel 1 angegebenen RTN-Bausteine ergibt sich somit folgende RTN-Baustein- unabhängige Verweisgruppe mit nachstehenden Elementen in der zweiten Verweisuntergruppe mit unveränderten bausteinrelevanten Informationen je Entscheidungsposition:

"K" ->

RTN-Baustein erster Gattungsgruppe V∑

„L" ->

RTN-Baustein erster Gattungsgruppe V8 „M" RTN-Baustein erster Gattungsgruppe V8_ [RTN-Baustein zweiter Gattungsgruppe]

Die Figur 41 zeigt das Element „A" (Bezugszeichen 50501) der ersten Verweisuntergruppe mit zugehörigem, sich nach dem Umwandlungsschritt ergebenden Rest- Entscheidungsgraphen 50611. Analog zeigen dies die Figuren 42 und 43 für die Elemente „V" (Bezugszeichen 50502) und „X" (50503) der ersten Verweisuntergruppe mit entsprechenden Rest-Entscheidungsgraphen 50612 und 50613. Die Figuren 44 und 45 zeigen auf gleiche Weise die Elemente „K" (Bezugszeichen 50503) und „L"( Bezugszeichen 50504) der zweiten Verweisuntergruppe mit ihren zugehörigen Rest-Entscheidungsgraphen 50614 und 50615.

Wird an einer Entscheidungsposition eines Rest-Entscheidungsgraphen, welche das Einsetzen und Durchlaufen eines RTN-Bausteins aus der Gesamtheit der RTN-Bausteine ersten Gattungsgruppe vorschreibt, das aufzusuchende Schlüsselwort nicht mehr als Element nicht mehr in einer einzigen Verweisgruppe, sondern nur mehr als Element in der ersten Verweisuntergruppe gesucht und es wird nach Auffinden desselben dem ihm zugeordneten Rest-Entscheidungsgraphen gefolgt

Gleichermaßen wird an einer Entscheidungsposition eines Rest-Entscheidungsgraphen, welche das Einsetzen und Durchlaufen eines RTN-Bausteins aus der Gesamtheit der RTN- Bausteine der zweiten Gattungsgruppe vorschreibt, das aufzusuchende Schlüsselwort in der zweiten Verweisuntergruppe als Element gesucht und es wird nach Auffinden desselben dem ihm zugeordneten Rest-Entscheidungsgraphen gefolgt.

Ein weiteres Beispiel soll die Analyse eines Statements unter Verwendung der ersten und zweiten Verweisuntergruppe, wie sie sich nach der Anwendung des Umwandlungsschrittes auf die in Beispiel 1 voneinander unabhängig definierten RTN-Bausteine ergeben, zeigen:

Beispiel 5: Zu analysierende Syntax: A(I) D(2) X(3) Y(4) L(5) X(6) K(7) A(8) D(9) M(IO) E(11)

Es wird die in Beispiel 4 gezeigte erste und zweite Versweisuntergruppe mit der ihren Elementen jeweils zugeordneten Rest-Entscheidungsgraphen verwendet.

Auffinden des an erster Stelle stehenden Schlüsselwortes ,,A"(1) in der ersten Verweisuntergruppe. Element „A" wird in der ersten Verweisuntergruppe gefunden, daher Ausführung des Verweisausführungsschrittes, also Abgleich der im Statement folgenden Schlüsselworte mit dem dem Element „A" der ersten Verweisuntergruppe zugeordneten Rest- Entscheidungsgraphen.

Die erste zu vergleichende Entscheidungsposition im Rest-Entscheidungsgraphen des Elements „A" in der ersten Verweisuntergruppe ist RTN-Baustein erster Gattungsgruppe, also eine Entscheidungsposition, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN- Baustein aus der Gesamtheit der RTN-Bausteine der ersten Gattungsgruppe eingesetzt und durchlaufen werden soll.

Die aktuelle rekursive Aufrufreihenfolge sieht daher folgendermaßen aus: 1. Element der ersten Verweisuntergruppe: „A"

Wie beschrieben bedeutet dies, dass das im Statement aktuelle, also dem ersten Schlüsselwort ,,A"(1) folgende Schlüsselwort ,,D"(2) in der ersten Verweisuntergruppe als rekursiver Aufruf gesucht wird. Schlüsselwort ,,D"(2) wird in der RTN-Baustein-unabhängigen ersten Verweisuntergruppe nicht gefunden, daher wird dem zweiten möglichen Entscheidungspfad des Rest- Entscheidungsgraphen des aktuellen Elements „A" der ersten Verweisuntergruppe gefolgt. Diese nächste Entscheidungsposition verlangt das Schlüsselwort „D", welches dem aktuellen Schlüsselwort ,,D"(2) entspricht. Daher wird für das aktuelle, also nächste, Schlüsselwort im Statement ,,X"(3) dem aktuellen Entscheidungspfad des Rest-Entscheidungsgraphen dieses Elements „A" aus der ersten Verweisuntergruppe gefolgt.

Diese nächste zu vergleichende Entscheidungsposition im Rest-Entscheidungsgraphen ist: RTN-Baustein erster Gattungsgruppe, also eine Entscheidungsposition, die eine rekursive RTN-Baustein-Einsetzposition insofern verlangt, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine der ersten Gattungsgruppe eingesetzt und durchlaufen werden soll.

Das aktuelle Schlüsselwort ,,X"(3) wird daher in der ersten Verweisuntergruppe als Element gesucht und in derselben aufgefunden.

2. Element der ersten Verweisuntergruppe: „X"

Das aktuelle, also nächste, Schlüsselwort im zu analysierenden Statement ,,Y"(4) wird daher mit der ersten Entscheidimgsposition des Rest-Entscheidungsgraphen des ersten Verweisgruppen-Elements „X" insofern erfolgreich vergleichen, als dass diese erste Entscheidungsposition des Rest-Entscheidungsgraphen das Schlüsselwort „Y" vorschreibt.

Aufgrund des Umwandlungsschrittes, welcher alle RTN-Bausteine jeweils einer ersten beziehungsweise einer zweiten Gattungsgruppe zuordnet und welcher bestimmten dieser RTN-Bausteine eine weitere, ihrer jeweils letzten Entscheidungsposition ihrer inneren, gerichteten Entscheidungsgraphen folgende optionale Entscheidungsposition RTN-Baustein zweiter Gattungsgruppe anhängt, folgt jeder vormals letzten Entscheidungsposition aller Rest- Entscheidungsgraphen von Elementen der ersten Verweisuntergruppe eine optionale Entscheidungsposition RTN-Baustein zweiter Gattungsgruppe.

Diese nächste Entscheidungsposition RTN-Baustein zweiter Gattungsgruppe im Rest- Entscheidungsgraph des aktuellen ersten Verweisuntergruppen-Elements „X" verlangt die rekursive RTN-Baustein-Einsetzposition insofern, als dass zum erfolgreichen Vergleich an dieser Entscheidungsposition ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine der zweiten Gattungsgruppe eingesetzt und durchlaufen werden soll.

Das aktuelle, also nächste Schlüsselwort ,,L"(5) des zu analysierenden Statements wird daher in der zweiten Verweisuntergruppe gesucht und dort als Element aufgefunden.

Die aktuelle rekursive Aufrufreihenfolge sieht daher folgendermaßen aus: 1. Element der ersten Verweisuntergruppe: „A" 2. Element der ersten Verweisuntergruppe: „X"

3. Element der zweiten Verweisuntergruppe: „L"

Die erste Entscheidungsposition des Rest-Entscheidungsgraphen dieses Elements „L" der zweiten Verweisuntergruppe schreibt einen RTN-Baustein erster Gattungsgruppe vor.

Das aktuelle, also nächste, Schlüsselwort ,,X"(6) im zu analysierenden Statement wird aufgrund der verlangten. rekursiven RTN-Baustein-Einsetzposition für einen RTN-Baustein der ersten Gattungsgruppe in der ersten Verweisuntergruppe gesucht und dort auch gefunden.

2. Element der ersten Verweisuntergruppe: „X"

3. Element der zweiten Verweisuntergruppe: „L"

4. Element der ersten Verweisuntergruppe: „X"

Das aktuelle Schlüsselwort ,,K"(7) wird mit dem Rest-Entscheidungsgraphen dieses ersten Verweisuntergruppen-Elements „X" auf eine mögliche übereinstimmende Entscheidungsposition verglichen. Es kann aber weder der ersten Entscheidungsposition Schlüsselwort „Y" des ersten möglichen Entscheidungspfades gefolgt werden, noch kann die erste Entscheidungsposition RTN-Baustein erster Gattungsgruppe des zweiten möglichen Entscheidungspfades erfolgreich eingesetzt werden, da das aktuelle Schlüsselwort ,,K"(7) nicht als Element der ersten Verweisuntergruppe identifiziert wird.

Der mögliche dritte Entscheidungspfad dieses Rest-Entscheidungsgraphen für das Element „X" der ersten Verweisuntergruppe schreibt optional eine Entscheidungsposition RTN- Baustein zweiter Gattungsgruppe vor. Das weiterhin unveränderte aktuelle Schlüsselwort ,,K"(7) wird daher anschließend entsprechend dieser ersten Entscheidungsposition RTN- Baustein zweiter Gattungsgruppe des dritten möglichen Entscheidungspfades in der zweiten Verweisuntergruppe erfolgreich aufgesucht.

3. Element der zweiten Verweisuntergruppe: „L"

4. Element der ersten Verweisuntergruppe: „X"

5. Element der zweiten Verweisuntergruppe: „K"

Die demnach aktuelle Entscheidungsposition ist die erste Entscheidungsposition des Rest- Entscheidungsgraphen des Elements „K" der zweiten Verweisuntergruppe, also RTN- Baustein erster Gattungsgruppe.

Das nächste aktuelle Schlüsselwort ,,A"(8) wird infolgedessen als Element in der ersten Verweisuntergruppe gesucht, und da es in dieser aufgefunden wird, wird dem Rest- Entscheidungsgraph des Elements „A" der ersten Verweisuntergruppe in der Rekursionsstufe gefolgt.

2. Element der ersten Verweisuntergruppe: „X"

3. Element der zweiten Verweisuntergruppe: „L"

4. Element der ersten Verweisuntergruppe: „X" 5. Element der zweiten Verweisuntergruppe: „K"

6. Element der ersten Verweisuntergruppe: „A"

Das nächste aktuelle Schlüsselwort ,,D"(9) wird mit der ersten Entscheidungsposition des Rest-Entscheidungsgraphen des ersten Verweisuntergruppen-Elements „A" in der 6. Rekursionsstufe deswegen nicht erfolgreich verglichen, weil diese erste Entscheidungsposition einen RTN-Baustein erster Gattungsgruppe verlangt, das aktuelle Schlüsselwort ,,D"(9) aber nicht in der ersten Verweisuntergruppe als Element aufgefunden wird.

Der zweite mögliche Entscheidungspfad des Rest-Entscheidungsgraph des ersten Verweisuntergruppen-Elements „A" verlangt das Schlüsselwort „D", welches dem aktuellen Schlüsselwort ,,D"(9) entspricht.

Dem dieser Entscheidungsposition „D" folgende aktuelle Entscheidungspfad schreibt als nächste Entscheidungsposition einen RTN-Baustein erster Gattungsgruppe vor, welcher aber nicht für das nächste aktuelle Schlüsselwort ,,M"(10) erfolgreich eingesetzt werden kann, da dass aktuelle Schlüsselwort ,,M"(10) nicht als Element in der ersten Verweisuntergruppe gefunden wird.

Die nächste mögliche Entscheidungsposition, welche auf die Entscheidungsposition Schlüsselwort „D" des_ aktuellen Entscheidungspfades des Elements „A" der ersten Verweisuntergruppe folgt, ist die optionale Entscheidungsposition RTN-Baustein zweiter Gattungsgriippe. Da das Schlüsselwort „M" auch nicht in der zweiten Verweisuntergruppe als Element aufgefunden wird und diese letzte Entscheidungsposition optional ist, gilt der Rest- Entscheidungsgraph dieses Elements „A" der ersten Verweisuntergruppe als erfolgreich durchlaufen. Daher wird die Rekursion für dieses erste Verweisuntergruppen-Element „A" beendet und es wird mit der nächsten Entscheidungsposition des Rest-Entscheidungsgraphen der nunmehr 5. Rekursionsstufe für das weitere Folgen der Entscheidungspositionen herangezogen.

3. Element der zweiten Verweisuntergruppe: „L"

4. Element der ersten Verweisuntergruppe: „X"

5. Element der zweiten Verweisuntergruppe: „K"

Der Rest-Entscheidungsgraph dieses zweiten Verweisgruppen-Elements „K" ist mit erfolgreichem Einsetzen und Durchlaufen eines RTN-Bausteins erster Gattungsgruppe abgeschlossen, da diesem Rest-Entscheidungsgraphen verfahrensgemäß beim Umwandlungsschritt keine optionale Entscheidungsposition RTN-Bausteins zweiter Gattungsgruppe angehängt wurde.

2. Element der ersten Verweisuntergruppe: „X" 3. Element der zweiten Verweisuntergruppe: „L"

4. Element der ersten Verweisuntergruppe: „X"

Der Rest-Entscheidungsgraph des ersten Verweisgruppen-Elements „X" ist mit Einsetzen und Durchlaufen eines RTN-Bausteins zweiter Gattungsgruppe erfolgreich beendet.

2. Element der ersten Verweisuntergruppe: „X"

3. Element der zweiten Verweisuntergruppe: „L"

Nachdem erfolgreich ein RTN-Baustein erster Gattungsgruppe an die entsprechende Entscheidungsposition im Rest-Entscheidungsgraphen des zweiten Verweisgruppen-Elements „L" eingesetzt wurde, wird die nächste dieser Entscheidungsposition RTN-Baustein erster Gattungsgruppe folgende Entscheidungsposition Schlüsselwort „M" des gleichen aktuellen Rest-Entscheidungsgraphen betreten. Diese Entscheidungsposition Schlüsselwort „M" wird positiv verglichen, da sie dem aktuellen Schlüsselwort ,,M"(10) entspricht. Demzufolge wird die an letzter Entscheidungsposition angehängte optionale Entscheidungsposition RTN- Baustein zweiter Gattungsgruppe für den Rest-Entscheidungsgraphen dieses Elements „L" der zweiten Verweisuntergrappe für das nächste aktuelle Schlüsselwort ,,E"(11) geprüft, welches sich aber nicht als ein Element der zweiten Verweisuntergruppe findet. Dieser negative Vergleich auf diese Entscheidungsposition beendet die 3. Rekursionsstufe positiv, da diese angehängte Entscheidungsposition nur optional ist.

2. Element der ersten Verweisuntergrappe: „X"

Nachdem der Rest-Entscheidungspfad des ersten Verweisgrappen-Elements „X" in der 2. Rekursionsstufe ebenfalls bei der letzten, verfahrensmäßig neu angehängten optionalen Entscheidungsposition RTN-Baustein zweiter Gattungsgruppe angekommen ist und der Vergleich bereits vorher negativ ausgeführt wurde, wird auch diese 2. Rekursionsstufe positiv beendet.

Die aktuelle rekursive Aufrafreihenfolge sieht daher folgendermaßen aus: 1. Element der ersten Verweisuntergrappe: „A"

Der letzte Rest-Entscheidungspfad, der noch geöffnet ist, erwatet an seiner nächsten vorgeschriebenen Entscheidungsposition das Schlüsselwort „E", welches dem weiterhin unveränderten aktuellen Schlüsselwort ,,E"(11) entspricht.

Nachdem damit das letzte Schlüsselwort des Statements analysiert wurde und auch die letzte Entscheidungsposition in der 1. Rekursionsstufe erreicht wurde, also keine weiteren Rekursionsstufen mehr offen sind, wurde das Statement erfolgreich durchlaufen und es kann nun anhand der verarbeitungsrelevanten Baustein-Informationen ein möglicher Zugriffsplan erzeugt werden, welche Erzeugung aber über den Rahmen dieses Beispiels hinausgeht.

Die fertige Verschachtelung dieses Beispiels 5 sieht für die RTN-Bausteine, wie sie in Beispiel 1 angegeben sind, folgendermaßen aus, wobei nachfolgend die Vielzahl der verarbeitungsrelevanten RTN-B austein-Informationen der einzelnen RTN-Bausteine zu „VRB-I x" zusammengefasst wird. „A" _»D" RTN-Baustein erster Gattungsgruppe (Bl) „E" VRB-I 5

(Bl): „X" „Y" RTN-Baustein zweiter Gattungsgruppe (B2) VRB-I 3

(B2): „L" RTN-Baustein erster Gattungsgruppe (BS) „M" VRB-I 8

(B3): „X" RTN-Baustein zweiter Gattungsgruppe (B4) VRB-I 3 (B4): „K" RTN-Baustein erster Gattungsgruppe (B5) VRB-I 7

(B5): „A" „D" VRB-I 5

Fig. 48 zeigt das fertig verschachtelte Beispiel 5 mit Schlüsselwort-Entscheidungspositionen und * -Entscheidungspositionen. Fig. 49 zeigt das fertig verschachtelte Beispiel 5 ohne Schlüsselwort-Entscheidungspositionen und * -Entscheidungspositionen.

Aus Gründen der Optimierung kann in jenen Fällen, in denen eine Entscheidungsposition einen RTN-Baustein erster Gattungsgruppe verlangt, dieser aber für das aktuelle Schlüsselwort nicht erfolgreich identifiziert wird, der Suchvorgang bei direkt nachfolgenden Entscheidungspositionen, welche ebenfalls RTN-Baustein erster Gattungsgruppe z.B. optional verlangen, als nicht erfolgreich gekennzeichnet werden, da der Suchvorgang für das aktuelle, in diesem Fall unveränderte, Schlüsselwort bereits zumindest einmal nicht erfolgreich war. In analoger Weise gilt dies auch für Entscheidungspositionen RTN-Baustein zweiter Gattungsgruppe, wobei dieser Fall insofern häufig auftritt, da zumindest eine gewisse Anzahl der definierten RTN-Bausteine verfahrensmäßig eine optionale Entscheidungsposition RTN-Baustein zweiter Gattungsgruppe angehängt bekommt und im Falle von rekursiven Verschachtelungen diese Entscheidungsposition mehrfach hintereinander geprüft werden kann.

Um eine automatische Analyse aller angegebenen Statements zu ermöglichen, ist die Anwendung des Umwandlungsschrittes, welcher die RTN-Bausteine einer ersten beziehungsweise einer zweiten Gattungsgruppe zuordnet, deswegen erforderlich, damit keiner der RTN-Bausteine mit einer rekursiven RTN-Baustein-Einsetzposition beginnt. Wird aber die schlüsselwortweise Verarbeitung eines gegebenen Statements über die nach dem Umwandlungsschritt zu verwendende erste und zweite Verweisuntergruppe durchgeführt, ergibt sich eine nicht richtige Verschachtelung in Bezug auf die RTN-Bausteine und damit eine falsche Verschachtelung der den RTN-Bausteinen zugeordneten verarbeitungsrelevanten RTN-Baustein-Informationen.

So soll die erwünschte Verschachtelung des im Beispiel 5 angegebenen Statements in Bezug auf die in Beispiel 1 definierten RTN-B austeine folgendes endgültiges Ergebnis aufweisen, auf das anhand der verarbeitungsrelevanten RTN-Baustein-Informationen weitere Verarbeitungsschritte ausgeführt werden können:

„A" „D" *r^; "E" VRB-I 5 (Bl): *(B2) „L" *(B3) „M" VRB-I 8

(B2): „X" „Y" VRB-I 3

(B3): *(B4) „K" *(B5) VRB-I 7

* (B4): „X" VRB-I 3

(B5): „A" „D" VRB-I 5

Fig. 50 zeigt das fertig verschachtelte Beispiel 5 in einer gewünschten Verschachtelung der RTN-Bausteine mit Schlüsselwort-Entscheidungspositionen und * -Entscheidungspositionen. Fig. 51 zeigt das fertig verschachtelte Beispiel 5 in einer gewünschten Verschachtelung der RTN-Bausteine mit Schlüsselwort-Entscheidungspositionen und * -Entscheidungspositionen.

In diesem Beispiel 5 ergibt sich in Bezug auf die definitionsgemäß zu verwendenden RTN- Bausteine aus Beispiel 1 VOR der Anwendung des Umwandlungsschrittes und Zuteilung derselben zu einer ersten oder zweiten Gattungsgruppe nur eine mögliche endgültige Verschachtelung. Diese endgültige Verschachtelung wird zur weiten Verarbeitung und damit letztendlich zur Generierung eines optimalen Zugriffsplans auf eine gegebene Datenstruktur verwendet und muss daher auf die angegebenen RTN-Bausteine VOR Anwendung des Umwandlungsschrittes Bezug nehmen. Der Umwandlungsschritt findet nur Verwendung, um eine automatische algorithmische Analyse von jeder angegebenen Syntax durchzuführen.

Speziell aber durch diese notwendige Umwandlung in die zwei Gattungsgruppen ergibt sich eine für die weitere Verarbeitung nicht zutreffende Verschachtelung der RTN-Bausteine, da jeweils ein RTN-Baustein der ersten Gattungsgruppe, wenn im Statement vorhanden, einen RTN-Baustein der zweiten Gattungsgruppe aufruft, dieser RTN-Baustein der zweiten Gattungsgruppe aber auf jedem Fall zumindest diesem aufrufenden RTN-Baustein der ersten Gattungsgruppe übergeordnet wird.

Definitionsgemäß gibt es RTN-Bausteine, welche mit einer rekursiven RTN-Baustein- Einsetzposition als erste Entscheidungsposition in ihrem inneren gerichteten

Entscheidungsgraphen beginnen und daher der zweiten Gattungsgruppe zugeordnet werden.

Bei diesen RTN-Bausteinen kann ohne weitere Kennzeichnungen bei Mehrfach-

Verschachtelungen nicht eindeutig festgestellt werden, welchen RTN-Bausteinen sie übergeordnet sind, da an einer Entscheidungsposition, welche die rekursiven RTN-Baustein- Einsetzposition verlangt, sämtliche RTN-Bausteine der ersten oder zweiten Gattungsgruppe eingesetzt werden können und dies bei Schachtelungen von RTN-Bausteinen nicht eindeutig ist.

Folgendes einfaches Beispiel soll dies anhand der in Beispiel 1 definierten RTN-Bausteine verdeutlichen:

Beispiel 6:

Zu analysierendes Statement:X(l) K(2) A(3) D(4) L(5) X(6) Y(7) M(8)

Für dieses Beispiel 6 ergeben sich folgende zwei Verschachtelungsmöglichkeiten, welche beide in Bezug auf die RTN-Bausteine in Beispiel 1 zulässig sind, sich aber durch die unterschiedlich vorliegende Reihenfolge der verarbeitungsrelevanten RTN-Baustein- Information unterscheiden. Um für jedes Statement also eine gewünschte Verschachtelung zu erzielen, ist die Einführung weiterer verarbeitungsrelevanter RTN-Baustem-Informationen notwendig, welche vorzugsweise eine erste und eine zweite Gewichtung für jeden der angegebenen RTN-Bausteine sein können. Eine solche wird später ausgeführt.

Erste mögliche Verschachtelung für Beispiel 6 unter Verwendung der RTN-Bausteine in

Beispiel 1:

*ßl) K(2) *(B2) verarbeitungsrelevante Baustein-Informationen V7

(Bl): X(I) verarbeitungsrelevante Baustein-Informationen V3

(B2): *(B3) L(5) *ß4) M(8) verarbeitungsrelevante Baustein-Informationen V8 (B3): A(3) D(4) verarbeitungsrelevante Baustein-Informationen V5

(B4): X(6) Y(7) verarbeitungsrelevante Baustein-Informationen V3

Zweite mögliche Verschachtelung für Beispiel 6 unter Verwendung der die RTN-Bausteine in Beispiel 1 :

*(B1) L(5) *(B2) M(8) verarbeitungsrelevante Baustein-Informationen V8

(B2) : *(B3) K(2) *(B4) verarbeitungsrelevante Baustein-Informationen V7

(B3): X(I) verarbeitungsrelevante Baustein-Informationen V3 (B4): A(3) D(4) verarbeitungsrelevante Baustein-Informationen V5

(B2): X(6) Y(7) verarbeitungsrelevante Baustein-Informationen V3

Wie 2xι sehen ist, kann aus beiden dieser möglichen und jeweils gültigen Verschachtelungen ein Zugriffsplan auf eine gegebene Datenstruktur erzeugt werden, wobei eben diese beiden Zugriffspläne nicht ident wären.

Um immer eine eindeutig erwünschte Verschachtelung von RTN-Bausteinen vor allem in jenen Fällen zu erhalten, in denen zumindest einer der verwendeten RTN-Bausteine ein RTN- Baustein der zweiten Gattungsgruppe ist, ist wie bereits erwähnt das Festlegen zumindest einer ersten, und optimalerweise auch einer zweiten, Gewichtung für jeden RTN-Baustein als eine seiner verarbeitungsrelevanten RTN-Baustein-Informationen erforderlich, durch welche die jeweils in Abhängigkeit der zu analysierenden Syntax erwünschte Verschachtelung der verwendeten RTN-Bausteine algorithmisch erzeugt wird.

Um eine derartige zumindest erste, und optimalerweise auch zweite Gewichtung für jeden der angegebenen RTN-Bausteine als verarbeitungsrelevante Baustein-Information derselben festzulegen, findest sich weiter unten zuerst eine konkret mögliche Anfragesprache, welche ausschließlich aus RTN-Bausteinen besteht und somit sowohl die praktische Anwendung von RTN-Bausteinen als auch eine erwünschte endgültige Verschachtelung eines Statements mit dieser zumindest ersten Gewichtung je RTN-Baustein zeigt. Die Vergabe der Gewichtungen je RTN-Baustein und ihre Wirkungsweise kanni leichter nachvollzogen werden, wenn sie nicht an einer abstrakten, sondern an einer konkreten Sprache gezeigt wird. Bevor eine solche konkrete Anfragesprache gezeigt wird, soll ein Schritt offenbart werden, welcher die Geschwindigkeit für die Analyse eines angegebenen Statements nach dem erfindungsgemäßen Verfahren, also mittels Auffinden von Schlüsselworten eines Statements in der ersten bzw. zweiten Verweisuntergruppe, welche sich nach Ausführung des Umwandlungsschrittes auf die RTN-Bausteine ergeben, und entsprechendes Folgen der Rest- Entscheidungsgraphen der jeweils identifizierten Elemente dieser Verweisuntergruppen, erhöht.

Um eine Geschwindigkeitsoptimierung zu erzielen, können alle Entscheidungspositionen von Entscheidungsgraphen der RTN-Bausteine mit einer jeweils für idente Entscheidungspositionen gleichen, eindeutigen RTN-Baustein-unabhängigen

Entscheidungspositions-Nummer versehen und aus diesen eine Menge an reservierten Schlüsselworten gebildet wird. Jene Entscheidungspositionen, die das Einsetzen einer Zahl, einer Variable bzw. eines Strings verlangen, werden ebenfalls mit einer gleichen, eindeutigen Entscheidungspositions-Nummer versehen. Analoges gilt für die beiden, mehrfach verwendbaren Entscheidungspositionen RTN-Baustein erster Gattungsgruppe und RTN- Baustein zweiter Gattungsgruppe, für diese beiden Entscheidungspositionen wird an allen eingesetzten Entscheidungspositionen in den Entscheidungsgraphen die jeweils gleiche, eindeutige Entscheidungspositions-Nummer vergeben.

Nach Angabe eines zu analysierenden Statements wird für jedes Schlüsselwort in demselben geprüft, ob dieses jeweilige Schlüsselwort des Statements in einer Menge an reservierten Schlüsselworten, also beispielsweise in einer Liste, existiert. Damit wird für jedes Schlüsselwort des Statements festgestellt, ob es sich um ein reserviertes Schlüsselwort im Simie eines Schlüsselwortes, dass an zumindest einer Entscheidungsposition aller Entscheidungsgraphen der RTN-Bausteine verlangt wird, handelt, oder, wenn nicht in dieser Menge der reservierten Schlüsselworte existent, entsprechend um eine Variable, eine Zahl bzw. einen String handelt. Jene Schlüsselworte eines Statements, welche in der Menge der reservierten Schlüsselworte aufgefunden werden, werden in demselben zu analysierenden Statement durch die Entscheidungspositions-Nummer des dieses aufgefundenen Elements der Menge, also des aufgefundenen reservierten Schlüsselwortes, ersetzt. Jene anderen Schlüsselworte des Statements, welche nicht in der Menge der reservierten Schlüsselworte existieren, bekommen, je nachdem, ob sie eine Zahl, eine Variable oder einen String darstellen, die entsprechende Entscheidungspositions-Nummer zugeordnet.

Die Analyse des angegebenen, in Entscheidungspositions-Nummern umgewandelten Statements geschieht weiterhin nach dem beschriebenen Verfahren, wobei zuvor aber die erste und die zweite Verweisuntergruppe sowie die Rest-Entscheidungsgraphen ihrer jeweiligen Elemente unter Verwendung der mit Entscheidungspositions-Nummern versehenen RTN-Bausteinen in Form von Entscheidungspositions-Nummern herangezogen wird.

Eine weitere Optimierung ist wie nachfolgend gezeigt zusätzlich möglich: Durch die Umwandlung sowohl aller vorhandenen Entscheidungspositionen in Entscheidungsgraphen als auch die Umwandlung aller Schlüsselworte in einem zu analysierenden Statement in jeweils entsprechende Entscheidungspositions-Nummern kann die erfindungsgemäße RTN-Baustein- unabhängige Verweisgruppe mit ihren beiden Verweisuntergruppen anstatt als Liste mit Elementen als zwei unabhängige Zahlen-Arrays, eines für die erste und eines die zweite Verweisuntergruppe, dargestellt werden. Die den beiden Verweisuntergruppen zugeordneten Zahlen-Arrays weisen die gleiche Anzahl an Elementen auf, wobei jedes Element über eine ihm zugeordnete eindeutige Indexnummer adressiert wird. Die kleinste Indexnummer in den beiden Zahlen-Arrays ist die kleinste verwendete Entscheidungspositions-Nummer, die größte Indexnummer entspricht der größten verwendeten Entscheidungspositions-Nummer, wobei jene Entscheidungspositions-Nummern, welche den rekursiven RTN-Baustein- Einsetzpositionen RTN-Baustein aus der Gesamtheit der RTN-Bausteine, RTN-Baustein erster Gattungsgruppe und RTN-Baustein zweiter Gattungsgruppe zugeordnet sind, nicht berücksichtigt werden müssen, da diese Entscheidungspositions-Nummern als Folge des Umwandlungsschrittes nicht als Elemente in der ersten oder zweiten Verweisuntergruppe vorhanden sind. Es verweisen aber nur jene Elemente (Indexnummern) des der ersten Verweisuntergruppe zugeordneten Zahlen-Arrays auf entsprechende Rest- Entscheidungsgraphen, welche in der ersten Verweisuntergruppe bereits als Elemente vorhanden sind und daher auf ihnen einen zugeordneten Rest-Entscheidungsgraph verweisen. Analoges gilt für das Zahlen- Array, welches der zweiten Verweisuntergruppe zugeordnet ist. Anstelle eines Arrays kann natürlich auch jede andere, dieselbe Funktion erfüllende Speicherform gewählt werden.

Zusammenfassend wird eine Optimierung dadurch erzielt, dass - jede Entscheidungsposition der inneren, gerichteten Entscheidungsgraphen der RTN-

Bausteine, welche nach Anwendung des Umwandlungsschrittes auf die RTN- Bausteine vorhanden ist, mit einer je gleicher Entscheidungsposition eindeutigen RTN-Baustein-unabhängigen Entscheidungspositions-Nummer versehen wird, und

- sowohl die erste als auch zweite Verweisuntergruppe jeweils als ein Zahlen- Array mit gleicher Anzahl an Elementen dargestellt wird, wobei Elemente des Array mit

Indexnummern adressiert werden und die kleinste Indexnummer der beiden Zahlen- Arrays die kleinste verwendete Entscheidungspositions-Nummer und die größte Indexnummer der beiden Zahlen-Arrays die größte verwendete Entscheidungspositions-Nummer ist, wobei aber - nur jene Indexnummern der der ersten bzw. zweiten Verweisuntergruppe zugeordneten Zahlen-Arrays auf entsprechende Rest-Entscheidungsgraphen verweisen, welche bereits als Elemente der ersten bzw. zweiten Verweisuntergruppe vorhanden sind, und weiters alle Entscheidungspositionen der Rest-Entscheidungsgraphen ebenfalls eine dieser Entscheidungsposition zugeordneten, eindeutigen Entscheidungspositions-Nummer zugeordnet bekommen, und

- jedem Schlüsselwort eines zu analysierenden Statements die jeweils diesem Schlüsselwort zugeordnete Entscheidungspositions-Nummer, welche auch die Entscheidungspositions-Nummer einer Variable, einer Zahl oder eines Strings sein kann, zugeordnet wird, wodurch

- bei verlangtem Identifizieren eines Schlüsselwortes des Statements in der ersten bzw. zweiten Verweisuntergruppe die diesem Schlüsselwort zugeordnete Entscheidungspositions-Nummer als Indexnummer des Zahlen-Array der ersten bzw. zweiten Verweisuntergruppe adressiert und die Existenz eines Rest- Entscheidungsgraphen für diese Indexnummer prüft, und des weiteren

- die Schlüsselworte des Statements mit den Entscheidungspositionen des Rest- Entscheidungsgraphen dadurch verglichen werden, dass die Entscheidungspositions- Nummer des jeweils aktuellen Schlüsselwortes des Statements mit der Entscheidungspositions-Nummer an der jeweiligen Entscheidungsposition des Rest- Entscheidungsgraphen verglichen wird.

Diese Zuordnung von Entscheidungspositions-Nummern zu Entscheidungspositionen in den RTN-Bausteinen und zu Schlüssel Worten eines Statements ermöglicht die Einfuhrung jeweils eines Zahlen-Arrays für die erste und die zweiter Verweisuntergruppe. Dieses Zahlen-Array ist bei der Verwendung von erfindungsgemäßen RTN-Bausteinen insbesondere deswegen sinnvoll, weil an jeder der in den Entscheidungsgraphen der RTN-Bausteinen vorkommenden * -Entscheidungspositionen eine sehr hohe, nur durch die Menge der angegebenen RTN- Bausteine beschränkte, Anzahl an Einsetzmöglichkeiten an RTN-Bausteinen besteht.

Durch die Verwendung eines Zahlen-Array anstatt einer Liste für die Elemente der ersten und zweiten Verweisuntergruppe ist es nicht mehr erforderlich, die an den *- Entscheidungspositionen gemäß einem zu analysierenden Statement einzusetzenden RTN- Bausteine dadurch aufzufinden, dass der Reihe nach die RTN-Bausteine der entweder ersten bzw. zweiten Gattungsgruppe solange geprüft werden, bis der jeweils vorgeschriebene RTN- Baustein identifiziert wird, was im ungünstigsten Fall den Vergleich mit sämtlichen RTN- Bausteinen der jeweiligen Gattungsgruppe erforderlich macht. Aufgrund der dem jeweiligen Schlüsselwort des Statements zugeordneten Entscheidungspositions-Nummer kann der einzusetzende RTN-Baustein ohne Vergleiche mit anderen RTN-Bausteinen im entsprechenden Zahlen-Array über die Indexnummer direkt adressiert und somit auf Existenz geprüft werden.

Somit wird bei Erreichen einer *-Entscheidungsposition in einem der Rest- Entscheidungsgraphen direkt die Indexnummer im Zahlen-Array der RTN-B austein- unabhängigen ersten bzw. zweiten Verweisuntergruppe adressiert und es wird getestet, ob für diese Indexnummer im Zahlen-Array, und somit für dieses Schlüsselwort im zu analysierenden Statement in der entsprechenden Verweisuntergruppe einen zu folgenden Rest-Entscheidungsgraphen existiert.

Die Entscheidungspositionen der Rest-Entscheidungsgraphen können ebenfalls durch die den jeweiligen Entscheidungspositionen eindeutig zugeordneten Entscheidungspositions- Nummern ersetzt werden, um auch an diesen Stellen statt einem String- Vergleich einen schnelleren Zahlenvergleich zu ermöglichen, der insbesondere bei ODER- Entscheidungspositionen, also bei jenen Entscheidungspositionen, an denen der Entscheidungsgraph des jeweils aktuellen RTN-Bausteins zumindest einen zweiten Entscheidungspfad zulässt, dadurch einen Geschwindigkeitsvorteil erzielt, dass die Entscheidungspositions-Nummer, die für das jeweils aktuelle Schlüsselwort im Statement nur einmal gesucht wird, diese gegebenenfalls aber zwei- oder mehrmals mit einer Entscheidungspositions-Nummer verglichen wird. Damit wird der deutlich langsamere Vergleich zweier Strings in den Rest-Entscheidungsgraphen vermieden.

In all jenen Fällen, in denen ein RTN-Bausteine der zweiten Gattungsgruppe nach erfolgreichem Beenden eines RTN-Bausteins der ersten Gattungsgruppe optional eingesetzt werden kann, ist diese Optimierung ebenfalls besonders sinnvoll, da in zumindest einigen dieser Fälle gemäß dem zu analysierenden Statement kein RTN-Baustein der zweiten Gattungsgruppe verlangt wird, da von einer insgesamt endlichen Verschachtelung ausgegangen wird. Die entsprechende Entscheidungspositions-Nummer des aktuellen Statement-Schlüsselwortes wird über die Indexnummer im Zahlen-Array der zweiten Verweisuntergruppe adressiert und es wird das Fehlen eines entsprechenden Rest- Entscheidungsgraphen für diese Indexnummer festgestellt. Die weiterfolgenden Vergleiche mit den aktuellen Rest-Entscheidungsgraphen bis zur Übereinstimmung mit dem daher unveränderten, aktuellen Schlüsselwort des zu analysierenden Statements werden ebenfalls nicht als Stringvergleich sondern als schnellerer Zahlenvergleich ausgeführt.

Ausgehend für die in Beispiel 1 definierten RTN-Bausteine würde diese einmalige Umwandlung in je Entscheidungsposition eindeutige Entscheidungspositions-Nummern folgendes bedeuten: i Beispiel 7:

Alle zumindest einmal vorkommenden Entscheidungspositionen in den Entscheidungsgraphen der RTN-Bausteine mit den diesen beliebig zugeordneten, aber jeweils eindeutigen Entscheidungspositions-Nummern: „A" -> zugeordnete Entscheidungspositions-Nummer: 1

„V" -> zugeordnete Entscheidungspositions-Nummer: 2

„W" -> zugeordnete Entscheidungspositions-Nummer: 3

„B" -> zugeordnete Entscheidungspositions-Nummer: 4

-> zugeordnete Entscheidungspositions-Nummer: 5

V" -> zugeordnete Entscheidungspositions-Nummer: 6

„Y" -> zugeordnete Entscheidungspositions-Nummer: 7

„D" -> zugeordnete Entscheidungspositions-Nummer: 8

„E" -> zugeordnete Entscheidungspositions-Nummer: 9

„„KK"" -->> zugeordnete Entscheidungspositions-Nummer: 10

T " -> zugeordnete Entscheidungspositions-Nummer: 11

M" -> zugeordnete Entscheidungspositions-Nummer: 12 Variablen, also nicht in dieser Liste vorkommenden Schlüsselworte:

-> zugeordnete Entscheidungspositions-Nummer: 0 * -Position, also eine Entscheidungsposition, welche die rekursive RTN-Baustein- Einsetzposition verlangt:

-> zugeordnete Entscheidungspositions-Nummer: 300

Entscheidungsposition, welche die rekursive RTN-Baustein-Einsetzposition für einen RTN-

Baustein erster Gattungsgruppe verlangt: -> zugeordnete Entscheidungspositions-Nummer: 301

Entscheidungsposition, welche die rekursive RTN-Baustein-Einsetzposition RTN-Baustein zweiter Gattungsgruppe verlangt:

-> zugeordnete Entscheidungspositions-Nummer: 302

Ausgehend von den oben zugeteilten Entscheidungspositions-Nummern werden die erste und die zweite RTN-Baustein-unabhängige Verweisuntergruppe, die sich nach dem Umwandlungsschritt der RTN-Bausteine in Beispiel 1 ergeben, ebenso wie die ihren Elementen entsprechend zugeordneten Rest-Entscheidungsgraphen unabhängig von den verarbeitungsrelevanten RTN-Baustein-Informationen wie folgt umgewandelt:

Elemente der ersten Verweisuntergruppe aus Beispiel 4 ohne Angabe der verarbeitungsrelevanten RTN-Baustein-Informationen an den Entscheidungspositionen in den Rest-Entscheidungsgraphen vor Umwandlung der Entscheidungspositionen in Entscheidungspositions-Nummern:

„A" ->

(RTN-Baustein erster Gattungsgruppe („B" RTN-Baustein erster Gattungsgruppe „A" I „C" RTN-Baustein erster Gattungsgruppe „B" | (1) „D" [(*1)] RTN-Baustein erster

Gattungsgruppe ) | „D" [RTN-Baustein erster Gattungsgruppe „E" ]) [RTN- Baustein zweiter Gattungsgruppe]

„V" ->

„W" RTN-Baustein erster Gattungsgruppe „B" RTN-Baustein erster Gattungsgruppe „A" [RTN-Baustein zweiter Gattungsgruppe]

„X" ->

[ ( „Y" I RTN-Baustein erster Gattungsgruppe „B" ) ] [RTN-Baustein zweiter

Gattungsgruppe]

Diese erste Verweisuntergruppe aus Beispiel 4 sieht nach Umwandlung der je Entscheidungsposition eindeutig vergebenen Entscheidungspositions-Nummer aus wie folgt:

Nr.l -> ( * (Nr.4 Nr.301 Nr.l | Nr.5 Nr.301 Nr.4 | (l) Nr.8 [(*1)] Nr.301 ) |

Nr.8 [Nr.301 Nr.9] ) [Nr.302] Nr.2 -> Nr.3 Nr.301 Nr.4 Nr.301 Nr.l [Nr.302] Nr.6 -> [ ( Nr.7 | [Nr.301 Nr.4 ) ] [Nr.302]

Somit ergibt sich für diese erste Verweisuntergruppe folgendes Zahlen-Array mit den Indexnummern 0 bis 12, in welches die Entscheidungspositions-Nummern 300, 301 und 302, die die rekursiven RTN-Baustein-Einsetzpositionen verlangen, nicht aufgenommen werden:

Nr.O -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.l -> ( * (Nr.4 Nr.301 Nr.l | Nr.5, Nr.301 Nr.4 | (1) Nr.8 [(*1)] Nr.301 ) |

Nr.3 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.4 -> (kein Rest-Entscheidungsgraph zugeordnet) Nr.5 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.6 -> [ ( NrJ | [Nr.301 Nr.4 ) ] [Nr.302]

Nr.7 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.8 -> (kein Rest-Entscheidungsgraph zugeordnet) Nr.9 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.10 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.11 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.12 -> (kein Rest-Entscheidungsgraph zugeordnet)

Elemente der zweiten Verweisuntergruppe aus Beispiel 4 ohne Angabe der verarbeitungsrelevanten Baustein-Informationen an den Entscheidungspositionen im Rest- Entscheidungsgraph vor Umwandlung der Entscheidungspositionen in Entscheidungspositions-Nummern: "K" ->

RTN-Baustein erster Gattungsgruppe

T " ->

RTN-Baustein erster Gattungsgruppe „M" RTN-Baustein erster Gattungsgruppe [RTN-Baustein zweiter Gattungsgruppe]

Diese zweite Verweisuntergruppe sieht nach Umwandlung der je Entscheidungsposition eindeutig vergebenen Entscheidungspositions-Nummer aus wie folgt:

Nr.10 -> Nr.301

Nr.ll -> Nr.301 Nr.12 [Nr.302]

Somit ergibt sich für diese zweite Verweisuntergruppe folgendes Zahlen-Array, in welches die Entscheidungspositions-Nummern 300, 301 und 302 nicht aufgenommen werden:

Nr.0 -> (kein Rest-Entscheidungsgraph zugeordnet) Nr.1 -> (kein Rest-Entscheidungsgraph zugeordnet) Nr.2 -> (kein Rest-Entscheidungsgraph zugeordnet) Nr.3 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.4 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.5 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.6 -> (kein Rest-Entscheidungsgraph zugeordnet) Nr.7 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.8 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.9 -> (kein Rest-Entscheidungsgraph zugeordnet)

Nr.10 -> Nr. 301

Nr.l l -> Nr.301 Nr.12 [Nr.302] Nr.12 -> (kein Rest-Entscheidungsgraph zugeordnet)

Als Beispiel für die schlüsselwortweise Umwandlung eines Statements in die den jeweiligen Schlüsselwort-Entscheidungspositionen zugeordneten Entscheidungspositions-Nummern laut Beispiel 7 wird nochmals die in Beispiel 2 zu analysierende Syntax herangezogen.

Zu verarbeitende Syntax VOR der Umwandlung in Entscheidungspositions-Nummern: A(I) X(2) X(3) B(4) D(5) D(6) D(7) A(8) D(9)

Zu verarbeitende Syntax NACH der Umwandlung in Entscheidungspositions-Nummern: Nr.l(l) Nr.6(2) Nr.6(3) Nr. 4(4) Nr.8(5) Nr.8(6) Nr.8(7) Nr.1(8) Nr.8(9)

Die Abarbeitung des zu analysierenden Statements ist gleich dem in Beispiel 2 gezeigten erfindungsgemäßen Verfahren. Die einzige, bereits beschriebene, Abweichung ist, dass anstatt des jeweils aktuellen Schlüsselwortes des zu analysierenden Statements als String die aktuelle Entscheidungspositions-Nummer, welche diesem jeweils aktuellen Schlüsselwort zugeordnet ist, herangezogen wird, sowie, dass das Identifizieren von Elementen in der ersten bzw. zweiten Verweisuntergruppe im zugeordneten Zahlen-Array über die Entscheidungspositions-Nummer des jeweiligen Statement-Schlüsselwortes erfolgt und die

Vergleiche an den Entscheidungspositionen der zu folgenden Rest-Entscheidungsgraphen ebenfalls mit den Entscheidungspositions-Nummern anstatt mit Strings durchgeführt werden. Insgesamt ergibt sich durch die Verwendung dieser Entscheidungspositions-Nummern, dass die syntaktische und zugriffsplan-generierende Analyse eines angegebenen Statements nach dem erfmdungsgemäßen Verfahren trotz der vervielfachten Anzahl an möglichen Entscheidungspositionen keinen Geschwindigkeitsverlust gegenüber der Verarbeitung eines Statements auf Basis eines bekannten RTN erleidet.

Eine Anfragesprache, welche durch ein RTN nach dem Stand der Technik, definiert ist, folgt schlüsselwortweise den Entscheidungspositionen genau eines gerichteten Gesamt- Entscheidungsgraphen, welcher eine relativ geringe Anzahl an als erste erreichbaren

Entscheidungspositionen enthält. An allen Entscheidungspositionen dieses einzigen Gesamt- Entscheidungsgraphen, der das RTN bildet, sind in Abhängigkeit von einem zugehörigen Kennzeichen entweder ein Text, ein Sonderzeichen, eine Variable, eine Zahl oder eine Sprungposition vorgeschrieben, oder es das rekursive Einsetzen und Durchlaufen genau des identischen Gesamt-Entscheidungsgraphen verlangt. Der Durchlauf des an einer Entscheidungsposition eines übergeordneten Gesamt-Entscheidungsgraphen eingesetzten selben Gesamt-Entscheidungsgraph kann wiederum nur an einer beschränkten Zahl an als erste erreichbare Entscheidungspositionen des Gesamt-Entscheidungsgraph begonnen werden. Daraus folgt eine beschränkte Ausdrucksfähigkeit mittels eines Statements auf Basis eines herkömmlichen RTN gegenüber jener Statements, welche die erfindungsgemäßen RTN- Bausteine verwenden.

Desgleichen ist zu ersehen, dass jedes nach dem Stand der Technik ausdrückbare Statement, auch wenn dieses sämtliche Möglichkeiten des zugrunde liegenden Gesamt- Entscheidungsgraphen in Anspruch nimmt, aufgrund der je nach Bedarf definierbaren RTN- Bausteine mit entsprechenden verarbeitungsrelevanten RTN-Baustein-Informationen ohne syntaktische oder strukturelle Veränderungen für die erfindungsgemäße Analyse übernommen werden kann. Dies ist darauf zurückzufüliren, dass bei den erfindungsgemäßen RTN- Bausteinen, welche jeweils einen von den anderen RTN-Bausteinen unabhängigen, inneren, gerichteten Entscheidungsgraphen enthalten, eine zusätzliche * -Entscheidungsposition, die das Einsetzen und Durchlaufen eines RTN-Bausteins aus der Gesamtheit der RTN-Bausteine vorschreibt, an beliebigen Entscheidungspositionen der inneren, gerichteten Entscheidungsgraphen verwendet werden kann, womit jeder Gesamt-Entscheidungsgraph vermittels der erfindungsgemäßen RTN-Bausteine mit gleichen Verarbeitungsfunktionen nachgebildet werden kann.

Um aus einem angegeben Statement einen optimalen Zugriffsplan zu erzeugen, ist die Angabe der bereits weiter oben angeführten, von einander unabhängigen verarbeitungsrelevanten Baustein-Informationen für jeden der definierten RTN-Bausteine notwendig. Zum Erreichen des größtmögliche Maßes an Flexibilität und damit des größtmöglichen Maßes an Ausdruckfähigkeit und späterer Optimierbarkeit eines zu generierenden Zugriffsplans werden eine erste und eine zweite verarbeitungsrelevante RTN- Baustein-Haupt-Informationsgruppe gebildet, wobei

- jene verarbeitungsrelevanten RTN-Baustem-Informationen, welche sich auf den jeweiligen RTN-Baustein, für den sie unabhängig von seinem inneren, gerichteten Entscheidungsgraphen definiert sind, beziehen, der ersten verarbeitungsrelevanten

RTN-Baustein-Haupt-Informationsgruppe zugeordnet werden und

- jene verarbeitungsrelevanten RTN-B austein-Informationen, welche konkreten Entscheidungspositionen in inneren gerichteten Entscheidungsgraphen der RTN- Bausteine zugeordnet werden und nur berücksichtigt werden, sobald die ihnen zugeordnete Entscheidungsposition erreicht wird, der zweiten verarbeitungsrelevanten

RTN-Baustein-Haupt-Informationsgruppe zugeordnet werden.

Um die maximale Flexibilität und bestmögliche Optimierbarkeit einer Sprache basierend auf erfindungsgemäßen RTN-Bausteinen zu ermöglichen, ist es notwendig, dass eine erste, eine zweite und eine dritte verarbeitungsrelevante RTN-Baustein-Informationsgruppe gebildet werden, wobei die verarbeitungsrelevanten RTN-Baustein-Informationen der ersten verarbeitungsrelevanten RTN-Baustein-Informations-Hauptgruppe diesen drei RTN- Baustein-Irrforrnationsgruppen derart zugeordnet werden, dass

- jene verarbeitungsrelevanten RTN-Baustein-Informationen, welche sofort bei Beginn des Durchlaufes der ihnen jeweils zugeordneten RTN-Bausteine entweder während der Analyse und RTN-B austein-mäßigen Verschachtelung eines angegebenen Statements oder auch bei nachfolgender weiterer Analyse und Generierung eines Zugriffsplans dieser sich ergebenden endgültigen Verschachtelung angewandt werden, der ersten verarbeitungsrelevanten Baustein-Informationsgruppe zugeordnet werden, und - jene verarbeitungsrelevanten RTN-Baustein-Informationen, welche nach Beginn aber vor vollständigem Durchlaufen der ihnen jeweils zugeordneten RTN-B austeine insbesondere bei der RTN-Baustein-mäßigen Verschachtelung eines zu analysierenden Statements, aber auch bei nachfolgender weiterer Analyse und Generierung eines Zugriffsplans dieser sich ergebenden endgültigen Verschachtelung angewandt werden, der zweiten verarbeitungsrelevanten Baustein-Informationsgruppe zugeordnet werden, und

- jene verarbeitungsrelevanten RTN-Baustein-Informationen, welche erst nach vollständigem Durchlaufen der ihnen jeweils zugeordneten RTN-Bausteine insbesondere bei nachfolgender weiterer Analyse und Generierung eines Zugriffsplans einer endgültigen Verschachtelung, aber auch bei der RTN-Baustein-mäßigen

Verschachtelung eines zu analysierenden Statements angewandt werden, einer dritten verarbeitungsrelevanten Baustein-Informationsgruppe zugeordnet werden.

Ebenso ist es notwendig, dass eine vierte, eine fünfte und eine sechste verarbeitungsrelevante RTN-Baustein-Informationsgruppe gebildet werden, wobei die verarbeitungsrelevanten RTN-Baustein-Informationen der zweiten verarbeitungsrelevanten RTN-Baustein- Informations-Hauptgruppe diesen drei RTN-Baustein-Informationsgruppen derart zugeordnet werden, dass

- jene verarbeitungsrelevanten RTN-Baustein-Informationen, die bei Erreichen der ihnen jeweils zugehörigen Entscheidungspositionen ausschließlich als Parameter für nachfolgende, mittels entsprechender Zuordnung festgelegte verarbeitungsrelevante RTN-Baustein-Informationen im jeweiligen Entscheidungsgraphen festgelegt werden, und somit nur vermittels verarbeitungsrelevanter¹ RTN-Baustein-Informationen der fünften oder sechsten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe an betroffenen Entscheidungspositionen zur Anwendung gebracht werden, der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe zugeordnet werden, und

- jene verarbeitungsrelevanten RTN-B austein-Informationen, die bei Erreichen der ihnen jeweils zugeordneten Entscheidungspositionen festlegen, dass sämtliche aufgrund der entsprechenden Zuordnung aufgefundenen Parameter, welche gleich den im selben Entscheidungsgraphen erreichten Entscheidungspositionen mit verarbeitungsrelevanten RTN-Baustein-Informationen der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe sind, vorzugsweise als Verarbeitungsfunktion zur Anwendung gebracht werden, der fünften verarbeitungsrelevanten RTN-Baustein-Informationsgruppe zugeordnet werden, und

- jene verarbeitungsrelevanten RTN-Baustein-Informationen, die bei Erreichen der ihnen jeweils zugeordneten Entscheidungspositionen die Anwendung genau der Parameter, welche mit Hilfe der verarbeitungsrelevanten RTN-Baustein- Informationen der vierten RTN-Baustein-Informationsgruppe in einem der dem jeweiligen RTN-Baustein in der Verschachtelung wahlweise entweder untergeordneten, übergeordneten oder benachbarten RTN-Baustein gesammelt werden, in diesem entweder untergeordneten, übergeordneten oder benachbarten RTN-Baustein jedenfalls unterbindet und diese unterbundenen Parameter als weitere Parameter des betroffenen RTN-Bausteins für eine spätere Anwendung festlegt, der sechsten verarbeitungsrelevanten Baustein-Informationsgruppe zugeordnet werden.

Des weiteren gilt, dass sowohl mehreren der erfindungsgemäß definierten RTN-Bausteine als auch mehreren der in den inneren, gerichteten Entscheidungsgraphen vorhandenen Entscheidungspositionen unabhängig davon, in welchen der RTN-Bausteine sie vorkommen, jeweils teilweise gleiche verarbeitungsrelevante RTN-Baustein-Informationen zugeordnet werden können.

Dies ist deswegen sinnvoll, da einige der verarbeitungsrelevanten RTN-Baustein- Informationen wie die erste oder die zweite Gewichtung oder auch die später gezeigte Umordnungsgewichtung für viele RTN-Bausteine idente Werte aufwesen und daher nicht alle verarbeitungsrelevanten RTN-Baustein-Informationen jeden RTN-Baustein eindeutig sein können, woraus sich kein Nachteil in der Verarbeitung ergibt. Um in einem RTN-Baustein mehrere, von einander unabhängige Parameter für eine spätere Anwendung derselben zuzulassen, wobei aber jeweils nur der jeweils in der Reihenfolge als letzter festgelegte, also letzte erreichte Parameter zur Anwendung gebracht wird, gilt, dass eine verarbeitungsrelevante RTN-Baustein-Information der fünften verarbeitungsrelevanten RTN-Baustein-Informationsgruppe genau für den Parameter von allen mittels Zuordnung für diese festgelegten Parameter der vierten verarbeitungsrelevanten RTN-Baustein- Informationsgruppe die Anwendung veranlasst, welcher durch die aufgrund einer zu analysierenden Syntax in der Reihenfolge des Durchlaufens als letzte erreichte Entscheidungsposition mit einer zugeordneten verarbeitungsrelevanten RTN-Baustein- Information der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe festgelegt wird, und somit jene vorherigen Parameter, welche im gleichen Entscheidungsgraphen durch vorher erreichte Entscheidungspositionen mit zugeordneten verarbeitungsrelevanten RTN- Baustein-Informationen der vierten verarbeitungsrelevanten RTN-Baustein- Informationsgruppe festgelegt wurden, für die zugeordnete Verarbeitung verworfen werden. Dies bedeutet, dass in jenen Fällen, in denen einem Entscheidungsgraphen gefolgt wird und in diesem Entscheidungsgraphen in Abhängigkeit der zu analysierenden Syntax zwar mehrere verarbeitungsrelevante RTN-Baustein-Informationen der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe angetroffen und als Parameter festgelegt werden, nur der in der Reihenfolge des Durchlaufens letzte dieser festgelegten Parameter bei Erreichen einer zugeordneten Entscheidungsposition im selben Entscheidungsgraphen, welche eine verarbeitungsrelevante RTN-Baustein-Informationen der fünften verarbeitungsrelevanten RTN-Baustein-Informationsgruppe enthält, angewandt wird.

Um aber je erreichten Entscheidungspositionen in einem selben Entscheidungsgraphen einen zusammengesetzten Parameter anzuwenden, ist es möglich, dass verarbeitungsrelevante RTN- Baustein-Informationen der vierten verarbeitungsrelevanten Baustein-Informationsgruppe mit einem Kennzeichen versehen werden können, welches Kennzeichen bei Erreichen der zugehörigen Entscheidungsposition im jeweils selben Entscheidungsgraphen festlegt, dass der zuletzt mittels verarbeitungsrelevanter RTN-Baustein-Informationen der vierten verarbeitungsrelevanten Baustein-Informationsgruppe ohne diesem Kennzeichnen festgelegte Parameter mit diesem weiteren Parameter nicht ersetzt sondern um diesen erweitert wird und dieser erweiterte Parameter bei der Erreichen der Entscheidungsposition, welche die zugeordnete verarbeitungsrelevante RTN-B austein-Information der fünften verarbeitungsrelevanten Baustein-Informationsgruppe enthält, zur Anwendung gebracht wird.

Somit ist das Sammeln von Parametern je nach erreichten Entscheidungspositionen in einem Entscheidungsgraphen möglich und diese gesammelten Parameter können bei einer diesen Parametern zugeordneten Entscheidungsposition mit einer verarbeitungsrelevante RTN- Baustein-Införmation der fünften verarbeitungsrelevanten Baustein-Informationsgruppe zur Anwendung gebracht werden.

Sollen innerhalb eines RTN-Bausteins mehrere von einander unabhängige verarbeitungsrelevante RTN-Baustein-Informationen der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe an jeweils unterschiedlichen Entscheidungspositionen im inneren, gerichteten Entscheidungsgraphen dieses RTN-Bausteins zur Anwendung gebracht werden, ist eine Kennzeichnung jeweils zusammengehöriger verarbeitungsrelevanter RTN- Baustein-Informationen der vierten und der fünften verarbeitungsrelevanten RTN-Baustein- Informationsgruppe an den betroffenen Entscheidungspositionen festzulegen. Dies geschieht, um diese mehreren unabhängigen Anwendungen auf zugehörige Parameter zu ermöglichen.

Es ist definitionsgemäß erlaubt, an einer einzigen Entscheidungsposition mehrere verarbeitungsrelevante RTN-Baustein-Informationen sowohl der vierten, der fünften wie auch der sechsten verarbeitungsrelevanten RTN-B austein-Informationsgruppen anzugeben. Somit wird es ermöglicht, an einer Entscheidungsposition zum Beispiel zwei von einander unabhängige Parameter mittel verarbeitungsrelevanten RTN-Baustein-Informationen der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppen festzulegen und diese Parameter je nach erreichten Entscheidungspositionen unabhängig voneinander zur Anwendung zu bringen.

Folgende Beispiele sollen diese verarbeitungsrelevanten RTN-Baustein-Informationsgruppen in gleichzeitiger Angabe einer auf der Erfindung basierenden Anfragesprache verdeutlichen: Vermittels des erfindungsgemäßen Verfahrens mit all seinen Freiheitsgraden in der Formulierung von Statements wird es möglich, eine Anfragesprache zu definieren, welche folgender Logik gehorcht:

Eine Anfragesprache, welche RTN-Bausteine als Grundlage verwendet, schreibt vor, dass jedem verwendeten RTN-Baustein zumindest eine Verarbeitungs-Eingangsmenge zugewiesen wird, auf welche Verarbeitungs-Eingangsmenge alle anzuwendenden verarbeitungsrelevanten RTN-Baustein-Informationen dieses RTN-Bausteins ausgeführt werden. Desgleichen liefert jeder der angegebenen RTN-Bausteine zumindest eine Verarbeitungs-Ausgangsmenge, also jene Menge oder Mengen, auf welche zumindest eine Verarbeitungsinformation angewandt wurde.

Eine verarbeitungsrelevante RTN-Baustein-Information der ersten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe legt daher fest, welche und wie viele Verarbeitungs- Eingangsmengen für einen RTN-Baustein, speziell ausgehend von der aktuellen sich durch ein zu analysierendes Statement ergebende Verschachtelung, verwendet werden sollen.

Mögliche Eingangsmengen eines RTN-Bausteins sind an einer rekursiven RTN-Baustein- Einsetzposition dieses RTN-Bausteins erhaltene Verarbeitungs-Ausgangsmengen des bzw. der angegebenen RTN-Bausteine, oder auch die Verarbeitungs-Eingangsmenge eines diesem RTN-Baustein übergeordneten RTN-Bausteins sowie zumindest eine der Verarbeitungs- Ausgangsmengen der des in der endgültigen Verschachtelung aller RTN-Bausteine direkten Nachbars dieses RTN-Bausteins.

Jene verarbeitungsrelevanten RTN-Baustein-Informationen, welche Werte von Elementen zumindest einer zu verarbeitenden Menge ändern oder neue, beispielsweise berechnete, Werte diesen Elementen hinzufügen, Elemente aus derselben Menge entfernen oder deren Reihenfolge verändern, werden nachfolgend Verarbeitungsfunktionen genannt.

Im Sinne der Verschachtelung benachbarte RTN-Bausteine ergeben sich durch einen diesen direkt übergeordneten RTN-Baustein, welcher die Anwendung der rekursiven RTN-Baustein- Einsetzposition, also einer Entscheidungsposition, welche das Einsetzen und Durchlaufen einer der RTN-Bausteine aus der Gesamtheit der RTN-Bausteine vorschreibt, zumindest zweimal oder auch beliebig oft verlangt.

Um das Ende jedes RTN-Bausteins und der in ihn eingesetzten RTN-Bausteine immer eindeutig zu erkennen, ist es notwendig, dass den inneren, gerichteten Entscheidungsgraphen der RTN-Bausteine jenen Entscheidungspositionen, an denen eine von vornherein nicht vorbestimmte, unbeschränkte Anzahl an aufeinander folgenden Aufrufen von rekursiven

RTN-Baustein-Einsetzpositionen durchgeführt wird, zumindest eine Entscheidungsposition, welche ein Schlüsselwort (Text, Sonderzeichen, Variable oder Zahl) verlangt, vorangestellt ist und zumindest eine Entscheidungsposition, welche ebenfalls ein Schlüsselwort verlangt, nachfolgt.

Ein Beispiel dafür ist der RTN-Baustein „Ebenen", in dem die Entscheidungsposition 300 beliebig oft aufeinander folgen kann, wobei dieser Baustein definitionsgemäß mit einem vorangehenden Schlüsselwort beginnt („[") und einen nachfolgenden Schlüsselwort („]") endet: „[" (1) * (*1) „]"

Vorausgesetzt wird eine Vielzahl an Tabellen und gespeicherten Anfragen in einem relationalen Datenbanksystem, welche nachfolgend als Mengen bezeichnet und abstrahiert werden.

Durch die Zerlegung und. das Einsetzen in RTN-Bausteine wird jedes formulierbare Statement in eine gleiche Abstraktionsform, welche auf einer Schachtelung von RTN-Bausteinen beruht, gebracht, unabhängig von der den verwendeten RTN-Bausteinen zugeordneten Verarbeitungsfunktion. Durch diese gleiche Abstraktion gilt eine Algebra für alle RTN- Bausteine und Schachtelungsmöglichkeiten.

Es kann immer eine endliche Anzahl an Grundbausteingruppen vereinbart werden, wobei für jede Grundbausteingruppe etliche Annahmen, also verarbeitungsrelevante RTN-Baustein- Informationen, vorausgesetzt werden, die gelten, solange übergeordnete oder eingesetzte RTN-Bausteine keine eigene andere Definition vorschreiben.

Beispiele für mögliche Grundbausteingruppen (Fig. 14, 15, 16, 17): Variante 1 (Fig. 14): RTN-Baustein 601 mit beliebigen Schlüsselworten 600 und genau eine Entscheidungsposition 300, in die ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt wird, wobei ein RTN-Baustein dieser Variante zumindest ein Schlüsselwort 600 entweder VOR und/oder NACH der Entscheidungsposition 300 vorschreibt

Variante 2 (Fig. 15): RTN-Baustein 602 mit beliebigen Schlüssel Worten 600 und zumindest zwei oder mehreren Entscheidungspositionen 300, wobei alle vorkommenden Entscheidungspositionen 300 jeweils durch zumindest ein Schlüsselwort getrennt sind.

Variante 3 (Fig. 16): RTN-Baustein 603, mit beliebigen Schlüsselworten 600, welche sich ausschließlich VOR und NACH der beliebig oftmalig aufrufbaren Entscheidungsposition 300 befinden.

Variante 4 (Fig. 17): RTN-Baustein 604 mit beliebigen Schlüssel Worten 600, welche sich am Beginn und am Ende des Entscheidungspfades 50999 befinden und welche eine Entscheidungsposition 300 gefolgt von einer beliebig oftmalig aufrufbaren Entscheidungsposition 300 enthalten, wobei nach der ersten Entscheidungsposition 300 beliebig viele Schlüsselworte 600 folgen können.

Alle bei der Formulierung eines beliebigen Statements sich ergebenden Schachtelungsmöglichkeiten lassen sich in diese oder weitere Varianten oder deren Kombinationen unterteilen. Gezeigt werden Abarbeitungsschritte, die in diesen Varianten jeweils angewandt werden, sofern die verwendeten RTN-Bausteine keine anderen Abarbeitungsabläufe bzw. Verarbeitungsmengen-Zuweisungen beschreiben.

Variante 1 (Fig. 8, 14)

Für jene RTN-Bausteine der Gesamtheit der RTN-Bausteine, die gemäß der in Fig. 14 dargestellten Variante 1 definiert sind, gilt folgende Verarbeitungsmengen-Zuweisung: Ist eine Entscheidungsposition 300 in einem übergeordneten RTN-Baustein vorgesehen, so wird dem an dieser Stelle eingesetzten weiteren RTN-Baustein als Verarbeitungs- Eingangsmenge jene Verarbeitungs-Eingangsmenge zugewiesen, welche dem übergeordneten RTN-Baustein zugewiesen wurde. Dieser Vorgang wird bis zum innerst-verschachtelten RTN-Baustein durchgeführt, sodass die Verarbeitungs-Eingangsmenge immer an den jeweils direkt eingesetzten RTN-Baustein an der Entscheidungsposition 300 übergeben wird. Sofern in den eingesetzten RTN-Baustein keine weiteren RTN-Bausteine eingesetzt sind, wird nun die Verarbeitungsfunktion des eingesetzten RTN-Bausteins auf die ihm zugewiesene Verarbeitungs-Eingangsmenge angewandt und die dabei gelieferte Verarbeitungs- Ausgangsmenge des eingesetzten RTN-Bausteins wird als neue Verarbeitungs- Eingangsmenge dem übergeordneten RTN-Baustein zugewiesen und sodann die Verarbeitungsfunktion des übergeordneten RTN-Bausteins ausgeführt. Das Ergebnis dieser Anwendung wird als Verarbeitungs-Ausgangsmenge des übergeordneten RTN-Bausteins ausgegeben. Dieses Prinzip lässt somit eine beliebig oftmalige Verschachtelung von RTN- Bausteinen zu.

Fig.8 zeigt demgemäß die ineinander verschachtelten RTN-Bausteine 407, 408, 409 entsprechend

RTN-Baustein 407 (Schl.w. + Entscbupos. 300)

RTN-Baustein 408 (Schl.w. + Entsch.pos. 300)

RTN-Baustein 409 (Schl.w.)

Verarbeitungs-Eingangsmenge 401 wird an RTN-Baustein 407 übergeben und danach dem eingesetzten RTN-Baustein 408 als dessen Verarbeitungs-Eingangsmenge 402 übergegeben, und diese wiederum ident als Verarbeitungs-Eingangsmenge 403 an den in den RTN-Baμstein 408 eingesetzten RTN-Baustein 409 weitergereicht.

Im innersten Verschachtelungspunkt angelangt wird nunmehr die Verarbeitungsfunktion des RTN-Bausteins 409 auf die Verarbeitungs-Eingangsmenge 403 angewandt und das dabei erhaltene Ergebnis als Verarbeitungs-Ausgangsmenge 404 als neue Verarbeitungs- Eingangsmenge an den RTN-Baustein 408 übergeben.

Nun wird die Verarbeitungsfunktion des RTN-Bausteins 408 auf die neue Verarbeitungs- Eingangsmenge 404 angewandt, wobei das erhaltene Ergebnis als Verarbeitungs- Ausgangsmenge 405 und als neue Verarbeitungs-Eingangsmenge an den RTN-Baustein 407 übergeben wird. Im nächsten Schritt wird die Verarbeitungsfunktion des nächsten äußeren RTN-Baustein, also des RTN-B austeins 407 auf seine neue Verarbeitungs-Eingangsmenge 405 angewandt und das erhaltene Ergebnis in die Verarbeitungs-Ausgangsmenge 406 des RTN-Bausteins 407 gespeichert.

Eine abweichende Definition für einzelne RTN-Bausteine ist wie oben bereits erwähnt damit aber nicht ausgeschlossen.

Variante 2 (Fig. 9, 15)

Für jene RTN-Bausteine der Gesamtheit der RTN-Bausteine, die gemäß der in Fig. 15 dargestellten Variante 2 definiert sind, gilt folgende Verarbeitungsmengen-Zuweisung: Wenn jeweils zumindest ein Schlüsselwort zwischen zwei oder mehreren Entscheidungspositionen 300 in einem übergeordneten RTN-Baustein vorkommt, dann wird den unmittelbar an den Entscheidungspositionen 300 eingesetzten RTN-Bausteinen jeweils die gleiche Verarbeitungs-Eingangsmenge, nämlich die Verarbeitungs-Eingangsmenge des übergeordneten RTN-Bausteins zugewiesen, wobei sämtliche sich ergebenden Verarbeitungs- Ausgangsmengen als Verarbeitungs-Eingangsmengen der Verarbeitungsfunktion des übergeordneten RTN-Bausteins übergeben werden, es sei denn, wenn in Ausnahmefällen der äußere und/oder zumindest einer der eingesetzten RTN-Bausteine eine andere Definition verwendet.

Fig.9 zeigt die durch ein Schlüsselwort 420 verknüpften RTN-Bausteine 418 und 419, welche in einen RTN-Baustein 417 eingesetzt sind. Anwendung findet diese Variante z.B. bei arithmetischen oder logischen Verknüpfungen von RTN-Bausteinen.

RTN-Baustein 417 (Entsch.pos. 300 + Schl.w. 420 + Entsch.pos. 300) RTN-Baustein 418 RTN-Baustein 419

Verarbeitungs-Eingangsmenge 411 wird an einen übergeordneten RTN-Baustein 417 übergeben und danach dem eingesetzten RTN-Baustein 418 als dessen Verarbeitungs- Eingangsmenge 412 übergegeben. Die zugehörige Verarbeitungsfünktion des RTN-Bausteins 418 wird anschließend auf die Verarbeitungs-Eingangsmenge 412 angewandt und in der Verarbeitungs- Ausgangsmenge 413 gespeichert.

Der RTN-Baustein 419 bekommt ebenfalls die Verarbeitungs-Eingangsmenge 411 von seinem übergeordneten RTN-Baustein 417 als Verarbeitungs-Eingangsmenge 414 übergeben. Die zugehörige Verarbeitungsfünktion des RTN-Bausteins 419 wird anschließend auf seine Verarbeitungs-Eingangsmenge 414 angewandt und in der Verarbeitungs- Ausgangsmenge 415 gespeichert.

Im nächsten Schritt erhält der übergeordnete RTN-Baustein 417 die Verarbeitungs- Ausgangsmengen 413 und 415 als seine zwei neuen Verarbeitungs-Eingangsmengen zugewiesen, auf welche seine Verarbeitungsfunktion nunmehr angewandt und nachfolgend in der einen Verarbeitungs- Ausgangsmenge 416 gespeichert wird.

Variante 3 (Fg. 10, 16):

Für jene RTN-Bausteine der Gesamtheit der RTN-Bausteine, die gemäß der in Fig. 16 dargestellten Variante 3 definiert sind, gilt folgende Verarbeitungsmengen-Zuweisung: Der übergeordnete RTN-Baustein weist einen Entscheidungspfad auf, der ein aufeinander folgendes, beliebig oftmaliges Erreichen der Entscheidungsposition 300 ermöglicht (siehe RTN 253 in Fig.6)

Für diesen Fall gilt, dass der in der Reihenfolge an erster Stelle eingesetzte RTN-Baustein die Verarbeitungs-Eingangsmenge des übergeordneten RTN-Bausteins übernimmt, weitere aufeinander folgende RTN-Bausteine jeweils die Verarbeitungs- Ausgangsmenge des Vorgängers als Verarbeitungs-Eingangsmenge verwenden, und der in der Reihenfolge letzte RTN-Baustein seine Verarbeitungs-Ausgangsmenge als Verarbeitungs-Eingangsmenge an den übergeordneten RTN-Baustein übergibt und dieser seine Verarbeitungsfunktion ausführt, es sei denn, wenn in Ausnahmefällen der äußere oder zumindest einer der eingesetzten RTN- Baustein eine andere Definition verwendet. Damit wird, wie bereits anderer Stelle erwähnt, gegenüber SQL eine wesentlich freiere Durchführung von Anfragen möglich.

Fig.10 zeigt die in einem übergeordneten RTN-Baustein 427 aufeinander folgenden RTN- Bausteine 428, 429, 430, bei denen - mit Ausnahme des ersten und des letzten RTN- Bausteins - in der angegebenen Reihenfolge der RTN-Bausteine jeweils die Verarbeitungs- Ausgangsmenge des vorhergehenden RTN-Bausteins als Verarbeitungs-Eingangsmenge des nachfolgenden RTN-Bausteins übernommen und die dem jeweiligen RTN-Baustein zugeordnete Verarbeitungsfunktion angewandt wird.

Konkret wird eine Verarbeitungs-Eingangsmenge 421 des übergeordneten RTN-Bausteins 427 als Verarbeitungs-Eingangsmenge 422 des in der Reihenfolge ersten RTN-Bausteins 428 übergeben und dessen Verarbeitungsfunktion auf diese angewandt, woraus sich eine Verarbeitungs-Ausgangsmenge 423 ergibt. Letztere wird als Verarbeitungs-Eingangsmenge 423 des zweiten RTN-Bausteins 429 weitergegeben. In gleicher Weise geschieht dies für den nachfolgenden RTN-Baustein 430 und seine sich ergebende Verarbeitungs-Eingangsmenge 424, dessen Verarbeitungs-Ausgangsmenge 425 als neue Verarbeitungs-Eingangsmenge übernommen wird, aufweiche die Verarbeitungsfunktion des übergeordneten RTN-Bausteins 427 angewandt wird, als Folge dessen eine Verarbeitungs-Ausgangsmenge 426 zurückgeliefert wird.

Eine sinnvolle mögliche Neu-Definition der Variante 3 ist durch einen RTN-Baustein 446 mit folgenden Mengen-Zuweisungs-Eigenschaften gegeben und wird in Fig. 12 gezeigt.

Der übergeordnete RTN-Baustein 446 weist wiederum einen Entscheidungspfad auf, der ein aufeinander folgendes, beliebig oftmaliges Erreichen der Entscheidungsposition 300 ermöglicht.

Gemäß Definition des speziellen RTN-Bausteins 446 gilt, dass allen an den Entscheidungspositionen 300 direkt eingesetzten RTN-Bausteinen 447, 448, 449 die Verarbeitungs-Eingangsmenge 441 des übergeordneten RTN-Bausteins 446 zugewiesen wird. Als Verarbeitungs-Eingangsmenge des übergeordneten RTN-Bausteins 446 werden die Verarbeitungs- Ausgangsmengen 442, 443, 444 sämtlicher direkt eingesetzter RTN-Bausteine 447, 448, 449 herangezogen und in der Verarbeitungs-Ausgangsmenge 445 nach Anwendung der Verarbeitungsfunktion gespeichert.

Beispiele für die möglichen Verarbeitungsfunktionen dieses RTN-Bausteins 446, festgelegt z.B. durch eigene RTN-Bausteine:

1. Alle Elemente, die sich in einer bestimmten Anzahl (mindestens, genau, maximal, ...) aller Verarbeitungs-Ausgangsmengen der eingesetzten RTN-Bausteine befinden (ANY (*) )

2. Alle Elemente, die sich in jeder Verarbeitungs-Ausgangsmenge der eingesetzten RTN- Bausteine befinden, bzw. in allen Verarbeitungs-Ausgangsmengen, bis auf zumindest/maximal/genau eine bestimmte Anzahl ( ALL (*) )

Es kann mittels eines eigenen RTN-Bausteins auch noch angegeben werden, ob Elemente, die in mehr als einer Verarbeitungs-Ausgangsmenge der eingesetzten RTN-Bausteine vorkommen, einfach oder mehrfach in die Verarbeitungs-Ausgangsmenge des übergeordneten RTN-Bausteins übernommen werden sollen.

Sind keine RTN-Bausteine als Parameter für die Verarbeitungsfunktion dieses übergeordneten RTN-Bausteins 446 angegeben, wird angenommen, dass alle Elemente, die in zumindest einer der Verarbeitungs-Ausgangsmengen 442, 443, 444 der eingesetzten RTN- Bausteine 447, 448, 449 vorkommen, ohne Duplikate ausgegeben werden sollen.

Variante 4 (Fg. 11, 13, 17):

Für jene RTN-Bausteine der Gesamtheit der RTN-Bausteine, die gemäß der in Fig. 17 dargestellten Variante 4 definiert sind, gilt folgende Verarbeitungsmengen-Zuweisung: Der übergeordnete RTN-Baustein (z.B. RTN-Baustein 457 in Fig. 11 oder RTN-Baustein 477 in Fig. 13) weist einen Entscheidungspfad auf, der nach einem oder mehreren Schlüsselworten 600 eine Entscheidungsposition 300 vorschreibt, auf die beliebig viele Schlüsselworte 600 folgen können und ein aufeinander folgendes, beliebig oftmaliges Erreichen der Entscheidungsposition 300 ermöglicht (siehe RTN 253 in Fig.6), wobei dieses durch zumindest ein Schlüsselwort 600 abgeschlossen wird.

Bei RTN-Bausteinen dieser Variante gilt, dass die erste Entscheidungsposition 300 die Daten der Verarbeitungs-Eingangsmenge des übergeordneten RTN-Bausteins verwendet und anhand der Verarbeitungs-Ausgangsmenge des eingesetzten RTN-Bausteins an der Entscheidungsposition 300 die Verarbeitungstunktion dieses RTN-Bausteins durchgeführt wird, für alle weiteren RTN-Bausteine, welche an der beliebig oft aufrufbaren Entscheidungsposition 300 eingesetzt werden, gilt für die Mengenzuweisung die für Variante 3 (Fig. 16) beschriebene Logik, wobei der erste RTN-Baustein der beliebig oft aufrufbaren Entscheidungsposition 300 die Verarbeitungs-Ausgangsmenge des RTN-Bausteins an der ersten, nicht wiederholbaren Entscheidungsposition als seine Verarbeitungs-Eingangsmenge zugewiesen bekommt. Ist das mit zumindest einem Schlüsselwort 600 gekennzeichnete Ende des übergeordneten RTN-Bausteins erreicht, kann zumindest eine weitere Verarbeitungsfunktion auf die Verarbeitungs-Ausgangsmenge des letzten RTN-Bausteins der beliebig oft aufrufbaren Entscheidungsposition 300 angewandt werden.

In Fig. 11 ist ein RTN-Baustein der Variante 4 gezeigt, welcher an der ersten Entscheidungsposition 300 des übergeordneten RTN-Bausteins 457 den RTN-Baustein 458 eingesetzt hat, welcher auf die Verarbeitungs-Eingangsmenge 452 des übergeordneten RTN- Bausteins 457 zugreift, wobei de Verarbeitungs-Eingangsmenge 452 der Verarbeitungs- Eingangsmenge 451 entspricht .

Die Verarbeitungsfunktion dieses RTN-Bausteins 457 führt eine zunächst Gruppierung je gleicher Wertemengen der Verarbeitungs-Ausgangsmenge 453 des RTN-Bausteins 458 für die Elemente der Verarbeitungs-Eingangsmenge 452 mit Verweis auf die jeweils gruppierten Elemente aus. So enthält die Verarbeitungs-Eingangsmenge 451, welche weitergegeben wird als Verarbeitungs-Eingangsmenge 452, 17 Elemente, als Ergebnis der Verarbeitungsfunktion des RTN-Bausteins 458 werden diese in der Verarbeitungs-Ausgangsmenge 453 zu fünf unterschiedlichen Elementen gruppiert, wobei jedes Element auf jeweils eine Menge mit den einzelnen Elementen, welche zusammengefasst wurden, verweist (Menge 461, 462, 463, 464, 465). Die Verarbeitungs-Ausgangsmenge 453 ist nun Verarbeitungs-Eingangsmenge für den RTN-Baustein 459. Werden durch die nachfolgenden Verarbeitungsfunktionen der eingesetzten RTN-Bausteine 459 und 460 Elemente aus der jeweiligen Verarbeitungs- Ausgangsmenge 454, 455 Elemente entfernt, so entfällt auch der Verweis auf die Mengen der zugeordneten Elemente (in Fig. 11 Menge 461 und 463). Bei Beendigung dieses RTN- Bausteins ist definiert, dass alle Elemente der zugeordneten Mengen (Mengen 462, 464, 465) der Verarbeitungs-Ausgangsmenge 465 in die Verarbeitungs-Ausgangsmenge 456 des RTN- Bausteins 457 geschrieben werden. Diese letzte Verarbeitungsfunktion wird nur ausgeführt, wenn sie über zumindest ein optionales Schlüsselwort im RTN-Baustein 457 oder durch einen nachfolgenden RTN-Baustein explizit aufgerufen wird.

In Fig. 13 ist ein RTN-Baustein der Variante 4 gezeigt, welcher an der ersten Entscheidungsposition 300 des übergeordneten RTN-Bausteins 477 den RTN-Baustein 478 eingesetzt hat, welcher auf die Verarbeitungs-Eingangsmenge 472 des übergeordneten RTN- Bausteins 477 zugreift, wobei de Verarbeitungs-Eingangsmenge 472 der Verarbeitungs- Eingangsmenge 471 entspricht .

Die Verarbeitungsfunktion dieses RTN-Bausteins 477 führt zunächst eine Gruppierung je gleicher Wertemengen der Verarbeitungs-Ausgangsmenge 473 des RTN-Bausteins 478 für die Elemente der Verarbeitungs-Eingangsmenge 472 durch, wobei jeweils gleich zu gruppierende Elemente in die gleichen, von einander unabhängigen Ausgangsdatenmengen der Verarbeitungs-Ausgangsmenge 473 geschrieben werden. Durch Vorhandensein dieses RTN-Bausteins 477 wird angenommen, dass jede Verarbeitungs-Eingangsmenge und jede Verarbeitungs-Ausgangsmenge zumindest eine Eingangsdatenmenge bzw. zumindest eine Ausgangsdatenmenge enthält, wobei Anzahl, Inhalt und Reihenfolge innerhalb der Daten-Mengen der Verarbeitungs-Eingangsmengen und der Verarbeitungs-Ausgangsmengen nicht ident sein müssen. Werden keine Eingangsdatenmengen bzw. keine Ausgangsdatenmengen beschrieben, so enthält jede Verarbeitungs-Eingangsmenge und jede Verarbeitungs-Ausgangsmenge genau eine Eingangsbzw. Ausgangsdatenmenge, welche alle Elemente beinhaltet. Sämtliche Verarbeitungsfunktionen werden unabhängig voneinander auf alle Eingangsdatenmengen der Verarbeitungs-Eingangsmengen (in Fig. 13: 473, 474) der jeweiligen RTN-Bausteine (in Fig. 13: 479, 480) angewandt und entsprechend, sofern die Ausgangsdatenmengen noch Elemente beinhalten, in die Ausgangsdatenmengen der Verarbeitungs-Ausgangsmengen 474, 475 der jeweiligen RTN-Bausteine 479, 480 geschrieben. Bei Beendigung dieses RTN-Bausteins ist definiert, dass alle Ausgangsdatenmengen der Verarbeitungs-Ausgangsmenge 475 in eine gleiche Ausgangsdatenmenge der Verarbeitungs-Ausgangsmenge 476 des RTN-Bausteins 477 geschrieben werden. Diese letzte Verarbeitungsfunktion wird nur ausgeführt, wenn sie über zumindest ein optionales Schlüsselwort im RTN-Baustein 477 oder durch einen nachfolgenden RTN-Baustein explizit aufgerufen wird.

Unter Bezugnahme auf Fig. 13 ergibt sich, dass jede Verarbeitungsfunktion eines RTN- Bausteins bezieht sich auf seine Verarbeitungs-Eingangsmengen und wird jeweils unabhängig auf alle Elemente aller Eingangsdatenmengen in seiner Verarbeitungs-Eingangsmenge ausgeführt und in gleiche bzw. andere Ausgangsdatenmengen seiner Verarbeitungs- Ausgangsmenge gespeichert. Es sei denn, ein RTN-Baustein besagt eine andere Definition.

Den RTN-Bausteinen werden Verarbeitungs-Eingangsmengen zugewiesen, es können somit RTN-Bausteine vorgesehen sein, die die Zuweisung der Verarbeitungs-Eingangsmengen zu den RTN-Bausteinen im Einzelnen beschreiben.

Eine weitere mögliche Charakterisierung der RTN-Bausteine kann folgender maßen vorgenommen werden, und wird als Beispiel dafür angegeben, dass auch hinsichtlich dieser Charakterisierung keine Einschränkung gegeben ist. Weiters werden hier Ansätze für die Abarbeitung durch eine Engine klar sichtbar.

Diese vorgenommene Charakterisierung ist in Tabelle 1 vor Anwendung des Umwandlungsschrittes auf die RTN-Bausteine und in Tabelle 2 nach Anwendung des Umwandlungsschrittes beispielhaft gezeigt.

Die Elemente der sich ergebende erste und zweite Verweisuntergruppe für diese RTN- Bausteine nach dem Umwandlungsschritt, wie sie in Tabelle 2 gezeigt sind, sind in Tabelle 3 aufgelistet, Tabelle 4 zeigt je Element in Tabelle 3 die entsprechenden Rest- Entscheidungsgraphen.

Es muss sowohl möglich sein, Kartesische Produkte als EINE Menge anzusprechen (RTN- Baustein „FROM") als auch je Element einer ersten Menge auf jeweils eine gesamte zweite Menge zu gehen, und dadurch ebenfalls ein Kartesisches Produkt zu erreichen, wobei in diesem Fall die Werte je Element der ersten Menge in Abhängigkeit der Kriterien der zweiten Menge berechnet und geliefert werden (RTN-Baustein „EBENEN").

RTN-Baustein „FROM":

Bildet ein Kartesisches Produkt für die Ergebnismenge des an der Entscheidungsposition 300 dieses RTN-Bausteins angegebenen RTN-Bausteins und stellt sie als Verarbeitungs- Eingangsmenge für den RTN-Baustein an der ersten Entscheidungsposition 300 in seinem übergeordneten RTN-Baustein „Ebenen" zur Verfügung.

RTN-Baustein „Ebenen":

Führe je Element der Verarbeitungs-Eingangsmenge des RTN-Bausteins, in dem dieser RTN- Baustein („Ebenen") enthalten ist, alle Verarbeitungsfunktionen jener RTN-Bausteine, die in diesem RTN-Baustein („Ebenen") an den Entscheidungspositionen 300 nacheinander angegeben wurden, schrittweise nacheinander aus, wobei die Verarbeitungs-Eingangsmenge jedes RTN-Bausteins die Verarbeitungs- Ausgangsmenge des unmittelbar vorhergehenden RTN-Bausteins ist. Die Besonderheit dieses RTN-Baustein der Variante 3 ist, dass dieser RTN-Baustein seine Verarbeitungs-Eingangsmenge nicht als Verarbeitungs-Eingangsmenge für den ersten in ihn eingesetzten RTN-Baustein weitergibt, sondern die Verarbeitungs- Eingangsmenge für den ersten RTN-Baustein mittels eigenem RTN-Baustein . (z.B. Verarbeitungs-Ausgangsmenge eines RTN-Bausteins „FROM") oder aus der Summe aller in diesem RTN-Baustein verwendeten Mengen bzw. Tabellen definiert wird.

Der in diesem RTN-Baustein „Ebenen" an der ersten Entscheidungsposition 300 eingesetzte RTN-Baustein nimmt als Verarbeitungs-Eingangsmenge jene Menge (Tabelle, gespeicherte Abfrage oder kartesisches Produkt), die in dem RTN-Baustein „Ebene" als Verarbeitungs- Eingangsmenge durch die Verarbeitungs-Ausgangsmenge eines bestimmten RTN-Bausteins (z.B. „FROM") definiert ist. Ist keine Verarbeitungs-Eingangsmenge für eingesetzte RTN- Bausteine in den RTN-Baustein „Ebenen" definiert, kann diese Verarbeitungs- Eingangsmenge ermittelt werden, und zwar über datenbankspezifische Eigenschaften, z.B. über Graphentheorie, die Tabelle der Relationen und alle angegebenen RTN-Bausteine „Tabellen" in diesem RTN-B austein „Ebenen", unabhängig von der Schachtelung in diesem RTN-Baustein Ebenen.

Da es beim äußersten RTN-Baustein „Ebenen" keinen umgebenden RTN-Baustein gibt, in dem dieser eingesetzt und dessen Verarbeitungs-Eingangsmenge herangezogen werden könnte, wird eine abstrakte Anfangsmenge mit einem Element herangezogen, wobei das Element in abstrakter Weise alle Zahlen, Konstanten, Buchstaben und globalen Funktionen usw. enthält.

Jeder RTN-Baustein „Ebenen" stellt sich und allen in ihm verschachtelten RTN-Bausteinen das jeweils aktuelle Element mit allen Informationen (z.B. alle Tabellenfelder) seiner Verarbeitungs-Eingangsmenge, geliefert durch den übergeordneten RTN-Baustein, zur Verfügung, wobei dadurch auch der „tiefste" geschachtelte RTN-Baustein auf diese Informationen aller RTN-Bausteinen „Ebenen" Zugriff hat.

Die Verarbeitungs-Ausgangsmenge des RTN-Bausteins „Ebenen" ist die Verarbeitungs- Ausgangsmenge des letzten RTN-Bausteins, der im RTN-Baustein „Ebenen" an der letzten wiederholbaren Entscheidungsposition 300 eingesetzt ist.

RTN-Baustein „Verarbeitung-SameParents" :

Dieser RTN-Baustein wurde in Fig. 12 gezeigt und oben stehend erläutert und ist in der Gruppe der „besonderen" Mengenzuweisungen angeführt, da seine Mengenzuweisung nicht der allgemeinen Beschreibung für Variante 3 entspricht.

Alle in diesem RTN-Baustein eingesetzten RTN-Bausteine bekommen als Verarbeitungs- Eingangsmenge NICHT die Verarbeitungs-Ausgangsmenge des unmittelbar vorhergehenden RTN-Bausteins zugewiesen, sondern die Verarbeitungs-Eingangsmenge des Verarbeitung- SameParents-Bubbles zugewiesen.

Die Verarbeitungs-Ausgangsmenge des Verarbeitung-SameParents-Bubbles sind alle Elemente aller Verarbeitungs-Ausgangsmengen aller Bausteine, die in diesem RTN-Baustein eingesetzt wurden. Je nach zusätzlichen RTN-Bausteinen als Parameter kann die Verarbeitungs-Ausgangsmenge dieses RTN-Bausteins auch nur jene Elemente beinhalten, die in allen oder einer bestimmten (genauen, mindesten oder maximalen Anzahl) vorkommen. Es kann mittels Parameter-RTN-Bausteinen auch bestimmt werden, ob jene Elemente, die in Verarbeitungs-Ausgangsmengen mehrfach vorkommen, mehrfach in der Verarbeitungs- Ausgangsmenge dieses Bausteins mehrfach gespeichert werden oder nur einfach werden oder gar nicht enthalten sein sollen.

RTN-Baustein „Verarbeitung-PrevParents-Bubble" :

Alle in diesem RTN-Baustein eingesetzten RTN-Bausteine bekommen als Verarbeitungs- Eingangsmenge die Verarbeitungs-Ausgangsmenge des unmittelbar vorhergehenden RTN- Bausteins zugewiesen, womit dieser RTN-Baustein der Mengenzuweisung gemäß Variante 3 entspricht. Dieser RTN-Baustein ermöglicht z.B., dass in einem Verarbeitung-SameParents- Bubble oder in anderen RTN-Bausteinen, welche nur eine Entscheidungsposition 300 erlauben, EIN RTN-Baustein die Verarbeitungs-Ausgangsmenge von mehreren aufeinander folgenden und schrittweise nacheinander durchgeführten Verarbeitungsfunktionen geliefert werden kann.

RTN-Baustein „BreakOn"

Jede Verarbeitungsfunktion wird auf alle Eingangs-Datenmengen in den Verarbeitungs- Eingangsmengen unabhängig voneinander ausgeführt. Soll einer Aufteilung in mehrere Daten-Mengen erfolgen, kann dies vermittels des RTN-Bausteins „BreakOn" erfolgen, wobei jeweils Elemente der Verarbeitungs-Eingangsmenge des RTN-Bausteins „BreakOn", die für die Verarbeitungs-Ausgangsmenge des an der ersten Entscheidungsposition 300 eingesetzten RTN-Bausteins die gleichen Werte liefern (im Falle von mehreren Elementen in dieser Verarbeitungs-Ausgangsmenge ist die Verwendung von „ALL" bzw. „ANY" sinnvoll), in die jeweils gleiche Datenmengen geschrieben werden.

Eine Zusammenführung in eine Datenmenge kann z.B. durch zumindest ein Schlüsselwort (z.B. „END" „BREAKON") nach einer beliebig oftmalig aufrufbaren Entscheidungsposition 300 im RTN-Baustein „BreakOn" festgelegt werden. RTN-Baustein „GroupBy":

Jedem Element der Verarbeitungs-Eingangsmengen und der Verarbeitungs-Ausgangsmengen können jeweils eine Menge an Werten zugewiesen werden.

Für viele Fragestellungen ist es notwendig, nach gleichen Werten zu gruppieren, und gegebenenfalls sich für jedes gruppierte Element jene Elemente zu merken, die zu diesem Element zusammengruppiert wurden. Das wird mit dem RTN-Baustein „GroupBy" festgelegt, wobei die Möglichkeit besteht, alle Elemente der Mengen, welche je Element zugewiesen sind, in die Verarbeitungs-Ausgangsmenge des RTN-Bausteins „GroupBy" zu schreiben und die Gruppierung damit nach erfolgten Verarbeitungsfunktionen aufzuheben. Dies kann mit zumindest einem Schlüsselwort (z.B. „END GROUPBY") nach einer beliebig oftmalig aufrufbaren Entscheidungsposition 300 festgelegt werden. Wird im Statement kein derartiges Schlüsselwort angegeben, bleibt die Gruppierung ab der ersten Verwendung für alle nachfolgenden Verarbeitungsfunktionen im jeweils übergeordneten RTN-Baustein aufrecht.

RTN-Baustein „OrderBy":

Die Elemente jeder Menge sind immer in einer bestimmten Reihenfolge angeordnet, nach der Optimierung berücksichtigt nicht jede Verarbeitungsfunktion diese Reihenfolge.

Es gibt daher einen RTN-Baustein („OrderBy"), der die Elemente aller Eingangsdaten- Mengen seiner Verarbeitungs-Eingangsmenge unabhängig voneinander nach dem angegeben Wert bzw. der Wertemenge sortiert in die Verarbeitungs-Ausgangsmenge dieses RTN- Bausteins „OrderBy" speichert

Jede sinnvolle Mengen- Verarbeitungsfunktion bzw. Werte-Berechnungsfunktion oder auch Anzeigefunktion usw. kann mittels eines RTN-Bausteins definiert und in der Anfrage durchgeführt werden. Nachfolgend einige Beispiele für Mengen-Verarbeitungs-Funktionen: RTN-Baustein „WHERE":

Dieser RTN-Baustein wird verwendet, um je Element der Verarbeitungs-Eingangsmenge festzulegen, dass dieses Element nur in die Verarbeitungs- Ausgangsmenge geschrieben wird, wenn der RTN-Baustein an der Entscheidungsposition 300 dieses RTN-Bausteins „WHERE" einen Wert ungleich Null liefert. Definitionen für den Fall, dass eine Menge an Werten geliefert wird, können mit den RTN-Bausteinen „ALL" bzw. „ANY" an der Entscheidungsposition 300 festgelegt werden.

RTN-Baustein „MIN" / „MAX":

Sollen aus einer Datenmenge jeweils nur jene Elemente gewählt werden, die den größten bzw. kleinsten Werten einer Berechnung je Element aus der Gesamtmenge entsprechen, so kann das über die RTN-Bausteine „MIN" bzw. „MAX" festgelegt werden. Sollen eine bestimmte Anzahl der größten bzw. kleinsten Werte geliefert werden, kann das über einen übergeordneten RTN-Baustein („Mengenelemente"), welcher die Anzahl der Elemente der Verarbeitungs-Ausgangsmenge seines an der Entscheidungsposition 300 eingesetzten RTN- Bausteins begrenzt, erfolgen.

RTN-Baustein „Mengenelemente begrenzend"

Soll aus der jeweils aktuellen Datenmenge einer Verarbeitungs-Ausgangsmenge nur eine bestimmte Anzahl an Elementen ausgehend von der aktuellen Sortierung geliefert werden, so kann dafür ein RTN-Baustein „Mengenelemente begrenzend", beispielsweiche durch das Schlüsselwort „#" zu erkennen, als übergeordneter RTN-Baustein verwendet werden. Dieser RTN-Baustein legt fest, dass genau das X-te Element („="), alle Elemente bis zum („<=") oder ab dem („>=") X-ten Element seiner Verarbeitungs-Eingangsmenge in seine Verarbeitungs-Ausgangsmenge übernommen wird. Es lässt sich auch eine Begrenzung auf einen bestimmten Prozentsatz in Bezug auf die Anzahl der Elemente der aktuellen Datenmenge in der Verarbeitungs-Eingangsmenge festlegen („%")•

RTN-Baustein „FIND":

Jede Verarbeitungsfunktion wird jeweils auf alle Eingangs-Datenmengen seiner Verarbeitungs-Eingangsmengen je Element ausgeführt und die Elemente der Datenmengen der Verarbeitungs-Ausgangsmenge werden als Verarbeitungs-Eingangsmenge für den übergeordneten bzw. nachfolgenden RTN-Baustein herangezogen.

Durch die Verwendung eins bestimmten RTN-Bausteins („FIND") wird festgelegt, dass die Verarbeitungs-Ausgangsmenge dieses RTN-Bausteins „FIND" unverändert der Verarbeitungs-Eingangsmenge dieses RTN-Bausteins entspricht, mit der Besonderheit, dass jene Elemente, welche sich in der Verarbeitungs-Ausgangsmenge des im RTN-Baustein „FIND" an der Entscheidungsposition 300 eingesetzten RTN-Bausteins befinden, in der Verarbeitungs-Ausgangsmenge dieses RTN-Bausteins „FIND" in gelieferter Reihenfolge markiert werden. Nachfolgende RTN-Bausteine führen ihre Verarbeitungsfunktion nun jeweils unabhängig voneinander einzeln auf die jeweils markierten Elemente in Bezug auf die nachfolgenden (RTN-Baustein „NEXT") oder vorhergehenden (RTN-Baustein „PREV") Elemente anstatt auf die gesamte Datenmenge aus. Weiterhin werden die in den Verarbeitungsfunktionen gefundenen Elemente nur markiert.

Bei Verwendung dieses JRTN-Bausteins ist eine vorherige Verwendung des RTN-Bausteins „ORDERBY" sehr sinnvoll. Soll später wieder ein Zugriff auf die gesamte Datenmenge erfolgen, kann das z.B. über eine Erweiterung im RTN-Baustein „FIND" erfolgen, welche nach einem der ersten Entscheidungsposition 300 folgenden Schlüsselwort (z.B. „:") ein beliebig oftmaliges Aufrufen der Entscheidungsposition 300 ermöglicht und danach zwingend zumindest ein Schlüsselwort vorschreibt (z.B. „END" „FIND"). Wird dieses Schlüsselwort gefunden, werden alle markierten Elemente der Verarbeitungs-Ausgangsmenge des letzten RTN- Bausteins an der beliebig oft aufrufbaren Entscheidungsposition 300 im RTN-Baustein „FIND" in die Verarbeitungs-Ausgangsmenge dieses RTN-Bausteins geschrieben und es werden keine Elemente mehr markiert, wodurch nachfolgende Verarbeitungsfunktionen wieder auf die gesamte Datenmengen zugreifen. RTN-Bausteine „NEXT" / „PREV"

Jede Verarbeitungsfunktion wird einzeln auf jedes Element in den Verarbeitungs- Datenmengen angewandt. Dadurch wird es möglich, jeweils aktuelle Elemente mit den

Werten nachfolgender („NEXT") oder vorhergehender („PREV") Elemente z.B. zu vergleichen und in Abhängigkeit dessen das jeweils aktuelle Element auszuwählen. Hat der

RTN-Baustein „NEXT" keinen übergeordneten RTN-Baustein, dann wird von der gesamten

Menge jeweils nur das X-te Element („="), alle Elemente bis zum X-ten Element („<=") oder alle Elemente ab dem X-ten Element („>=") als Verarbeitungs-Ausgangsmenge dieses RTN-

Bausteins geliefert.

RTN-Bausteine „ANY " / "ALL"

Z.B. beim RTN-Baustein „Vergleich", welcher die Verarbeitungs-Ausgangsmengen der an den beiden Entscheidungsposition 300 eingesetzten RTN-Bausteine miteinander vergleicht, kann für jene Fälle, wo zumindest einer der eingesetzten RTN-Bausteine eine Menge an Werten zurückliefert, festgelegt werden, ob ALLE („ALL") zurückgelieferten Werten oder zumindest EINER („ANY") der zurückgelieferten Werte beim Vergleich zutreffen muss. Es kann bei „ANY" auch festgelegt werden, das genau („="), zumindest („>=") oder maximal („<-") eine bestimmte Anzahl an Elementen für den Vergleich zutreffen muss. Bei „ALL" kann gesagt werden, dass der Vergleich bis auf genau („="), bis auf zumindest („<=") oder bis auf maximal („>=") X Elemente zutreffen muss.

RTN-Baustein „Zwischenmenge":

Soll die Verarbeitungs-Ausgangsmenge eines RTN-Bausteins für die weitere Verarbeitung mit anderen RTN-Bausteinen gespeichert werden, kann dies mittels eines übergeordneten

RTN-Bausteins „Zwischenmenge" erfolgen. Dieser RTN-Baustein besagt, dass seine

Verarbeitungs-Eingangsmenge temporär in die als Variablenname angegebene Menge gespeichert wird und von allen nachfolgenden RTN-Bausteinen als Verarbeitungs- Eingangsmenge verwendet werden kann.

RTN-Baustein "DO LOOP"

Es kann bei gewissen Fragestellungen gewünscht sein, dass nach jedem Element der Verarbeitungs-Eingangsmenge des RTN-Bausteins, welcher in der Entscheidungsposition 300 nach dem Schlüsselworten „DO" „:" in dem RTN-Baustein „DO LOOP" eingesetzt ist, auf welches Element die Verarbeitungsfunktion des eingesetzten RTN-Bausteins angewandt wurde, die Verarbeitungs-Ausgangsmenge des RTN-Bausteins, welches an Entscheidungsposition 300 nach dem Schlüsselwort „UNTIL" angegeben wurde, auf ungleich Null oder NULL überprüft und in Abhängigkeit dessen die Verarbeitungsfunktionen für diesen RTN-Baustein beendet werden.

Beispiel 8:

Nimm alle Firmen aus Wien, und zwar solange, bis der Umsatz2006 der gewählten Firmen insgesamt über 100.000 € beträgt.

SELECT

DO : -

WHERE (Firmen.Ort="Wien") LOOP UNTIL SUM (Firmen.Umsatz2006) > 100000

Mittels eines RTN-Bausteins „Mengen-Element-Bildend" (,„") werden die beiden Verarbeitungs-Ausgangsmengen der an den beiden Entscheidungspositionen 300 dieses RTN- Bausteins eingesetzten RTN-Bausteine zu einer gemeinsamen Verarbeitungs-Ausgangsmenge dieses RTN-Bausteins zusammengefasst. Es gibt RTN-Bausteine, welche je nach der vorhandenen endgültigen Verschachtelung unterschiedliche Verarbeitungsfunktionen auf ihre endgültig erhaltenen Verarbeitungs- Eingangsmengen ausfuhren. Folgende zwei Beispiele sollen das für zwei der aus der Gesamtheit der RTN-Bausteine betroffenen RTN-Bausteine darstellen:

Der RTN-Baustein „IF-THEN-ELSE", welcher der ersten Gattungsgruppe zuzuordnen ist, fuhrt je nach gegebener Verschachtelung eine anderer Verarbeitungsfunktion aus, welche sich aber aufgrund der gesamten den RTN-Bausteinen als verarbeitungsrelevante RTN-Baustein- Informationen zugeordneten Logik für jede vorhandene Verschachtelung bestimmen lässt:

Nachfolgend abstraktes Beispiel soll das verdeutlichen:

Beispiel 9:

Zu analysierende Syntax:

[

IF Date.Year() < 2000 THEN

FROM „Data 1990-2000" ELSE RESULTOF ( FROM „Data Aktuell" WHERE „Data Aktuell".Jahr=Date.Year() )

END IF AS Data

WHERE Data.FeldA >= IF Data.FeldB = Data.FeldC THEN 500 ELSE lOO END IF

Die endgültig erwünschte, vereinfachte und somit nicht vollkommen aufgelöste Verschachtelung dieses Statements schaut aus wie folgt:

[ (I)* (2)* ]

(1): (3)* AS Data (3): IF (4)* THEN (5)* ELSE (6)* END IF

(4): Date.Year() <= 2000 (5): FROM „Data 1990-2000" (6): RESULTOF ( (7)* (8)* ) (7): FROM „Data Aktuell"

(8): WHERE „Data Aktuell". JahrHDate.Year()

(2): WHERE (9)*

(9): (1O)* >= (H)* (10): Data.FeldA

(11): IF (12)* THEN (13)* ELSE (14)* END IF (12): Data.FeldB = Data.FeldC ' (13): 500 (14): 100

Um den Focus dieses Beispiels auf das wesentliche zu richten, ist die Verschachtelung nicht vollends aufgelöst, so werden der mehrfach verwendeten RTN-Bausteine „FROM *", „WHERE *", „* . *" usw. nicht gänzlich verschachtelt dargestellt.

Jedenfalls ist ersichtlich, dass der RTN-Baustein „IF-THEN-ELSE" an seiner ersten verwendeten Verschachtelungs-Position (3) in Abhängigkeit des aktuellen Jahres als seine Verarbeitungs-Ausgangsmenge entweder die Verarbeitungsmenge „Data 1990-2000". oder das Ergebnis der RTN-Bausteins (6)„Verarbeitung-PrevParents-Bubble"₃ welcher von der Verarbeitungsmenge „Data Aktuell" jene Elemente, also Datensätze, liefert, bei denen im Feld „Jahr" der Wert des aktuellen Jahres steht. Die gelieferte Verarbeitungs-Ausgangsmenge dieser Verschachtelungs-Position (3) wird aufgrund des dieser Verschachtelungs-Position übergeordneten RTN-Bausteins (1) „AS" nachfolgend als „Data" angesprochen.

Das zweite in dieser Verschachtelung verwendete „IF-THEN-ELSE" an der Verschachtelungs-Position (11) liefert in seiner Verarbeitungs-Ausgangsmenge in

Abhängigkeit eines elementweisen Vergleiches (12)Data.FeldB = Data.FeldC je Element seiner Verarbeitungs-Eingangsmenge entweder den Wert (13)500 oder (14)100, welcher Wert im übergeordneten RTN-Baustein (9)„Vergleich" mit für dasselbe Element an Verschachtelungs-Position (lO)Data.FeldA gelieferten Wert verglichen wird.

Ein ebenfalls von dieser Besonderheit betroffener RTN-Baustein ist der RTN-Baustein „Vergleich", welcher der zweiten Gattungsgruppe zuzuordnen ist und als eines seiner möglichen optionalen Entscheidungspositionen seines inneren gerichteten Entscheidungsgraphen das Schlüsselwort „=" enthält. Dies soll mit folgendem Beispiel als Ausschnitt eines angegebenen Statements gezeigt werden:

Beispiel 10:

Zu analysierende Syntax:

WHERE WHERE (Firmen.Ort="Wien")=Max([Veranstaltungen.Umsatz])#100

Die endgültig erwünschte Verschachtelung dieses Statements schaut aus wie folgt:

WHERE (I)*

(I) ■ (2)* = (3)*

(2): WHERE (4)*

(4): ( (5)* )

(S): (6) * (7)*

(6): (8)^! . (9)*

(S): Firmen

(9): Ort

(T): „Wien"

(3): (10)* # (H)*

(10) . MAX (12) *

(U) • ( (13)* )

(13): [ (14) * ]

(14) •^• (15)* (16)*

(15): Veranstaltungen

(16): Umsatz

(11): 100 Hier wird der RTN-Baustein „Vergleich" an der Verschachtelungs-Position (5) dazu verwendet, jeden einzelnen gelieferten Wert der Elemente der Verarbeitungs- Ausgangsmenge des RTN-Bausteins (6),,." mit seinen beiden diesem wiederum untergeordneten RTN- Bausteinen (8)Firmen und (9)0rt mit dem konstanten Wert (7)„Wien" zu vergleichen und die positiv verglichenen Elemente seiner Verarbeitungs-Ausgangsmenge hinzuzufügen.

Der gleiche der RTN-Baustein „Vergleich" wird an der Verschachtelungs-Position (1) dazu verwendet, genau jene Elemente seiner beiden für seine Verarbeitungsfunktion endgültig erhaltenen Verarbeitungs-Eingangsmengen, also die Verarbeitungs-Ausgangsmengen der ihm direkt untergeordneten RTN-Bausteine (2)„WHERE" und (3)„Mengenelemente-begrenzend", in seine Verarbeitungs-Ausgangsmenge zu übernehmen, welche in beiden seiner endgültig erhaltenen Verarbeitungs-Eingangsmengen zu finden sind.

Somit liefert die oben gezeigte Syntax als Ergebnis alle Firmen, welche aus dem Ort „Wien" sind und deren nicht näher definierter Veranstaltungs-Umsatz zu den insgesamt 100 größten Veranstaltungs-Umsätzen aller Firmen gehört. Ein gleiches Ergebnis kann natürlich auch durch anders geschriebene Statements erzielt werden, welche hier nicht gezeigt werden, da dieses Beispiel der Verdeutlichung des RTN-Bausteins „Vergleich" dient.

Weiter RTN-Bausteine, .welcher ebenfalls je nach gegebener endgültiger Verschachtelung unterschiedliche Verarbeitungsfunktionen ausführen, sind die RTN-Bausteine „Strich- Rechnen" und „Punkt-Rechen", welche aufgrund der „Punkt-Rechnung vor Strich- Rechnung"-Regel jeweils eine unterschiedliche erste und zweite Gewichtung zugewiesen haben.

Eine einfache zu analysierende Syntax SELECT Firmen.Umsatz * 1.2 liefert das Ergebnis der oben verlangten Rechen-Operation.

Für folgende zu analysierende Syntax SELECT Firmen * Abteilungen dient der RTN-Baustein „Punkt-Rechnen" nicht zur Multiplikation zweier Zahlen sondern zur Bildung eines Kartesischen Produktes, welches durch nachfolgende, beispielsweise benachbarte RTN-Bausteine eingeschränkt werden kann.

Genauso kann der RTN-Baustein „Strich-Rechnen" bei erreichter Entscheidungsposition Schlüsselwort „+" ein „UNION" (je nach gewünschter Definition auch „UNION ALL") als Verarbeitungsfiinktion auf seine beiden endgültigen Verarbeitungs-Eingangsmengen anwenden, und bei erreichter Entscheidungsposition Schlüsselwort „-" eine Verarbeitungstunktion EXCLUDE auf seine beiden endgültigen Verarbeitungs- Eingangsmengen anwenden.

So könnte eine angegebene Syntax

( WHERE (Firmen.Ort="Wien") )

( MAX (Firmen. AnzahlMitarbeiter) # 100 )

zum Beispiel nur jene Firmen aus Wien liefern, deren Mitarbeiter- Anzahl nicht zu den insgesamt 100 größten zählt.

Derartige Verschachtelungs-abhängige Verarbeitungsfunktionen in einem RTN-Baustein können einfach durch eine weitere Zuordnung der RTN-Bausteine zu neuen Gruppen erfolgen, welche mittels verarbeitungsrelevanten RTN-Baustein-Informationen diesen Sachverhalt für einzelne RTN-Bausteine festlegen.

Auf gleiche Weise kann bestimmt werden, welche RTN-Bausteine nicht direkt verschachtelt werden dürfen, bis für derartige Fälle eine sinnvolle Verarbeitungsfunktion definiert wird. Es kann ebenso aufgrund einer gegebenen Verschachtelung eine Frage gestellt werden, und zwar in jenen Fällen, wo aufgrund der angegebenen Syntax mehr als eine mögliche Deutung zulässig ist.

Einen Fall, in dem eine automatische Nachfrage beim Anwender für eine konkrete Deutung der zu analysierenden Syntax notwendig sein kann, zeigt folgendes Beispiel: Ausschnitt einer zu analysierenden Syntax: BREAKON Firmen. Ort WHERE (Firmen = 5)

Für dieses Beispiel können zumindest drei Deutungen zulässig sein, wobei ein Anwender entscheiden kann, welche dieser drei Deutungen er im Konkreten auswerten möchte:

1. mögliche Deutung:

Die weitere Analyse nur fortsetzen, wenn in der Verarbeitungs-Eingangsmenge der Menge Firmen, welche der Verarbeitungs-Eingangsmenge des RTN-Bausteins „Klammer" und somit wiederum der Verarbeitungs-Eingangsmenge „WHERE" entspricht, genau 5 Elemente (also genau 5 Firmen) enthalten sind. In diesem Fall würde die Verarbeitungs-Ausgangsmenge des RTN-Bausteins „WHERE" in jenen Fällen alle Elemente (also alle Firmen) eines Ortes liefern, wenn in diesem Ort genau 5 Elemente (also genau 5 Firmen) vorhanden sind, in allen anderen Fällen würde die Verarbeitungs-Ausgangsmenge des RTN-Bausteins

„WHERE" den Wert NULL liefern.

2. mögliche Deutung:

Liefere in der Verarbeitungs-Ausgangsmenge des RTN-Bausteins „WHERE" genau die 5. Firma der Verarbeitungs-Eingangsmenge desselben RTN-Bausteins. Somit würde die Verarbeitungs-Ausgangsmenge des RTN-Bausteins „WHERE" je Ort genau das 5. Element (also die 5. Firma - sofern zumindest 5 Firmen in diesem Ort vorhanden) anhand der aktuellen Sortierung für die weitere Verarbeitung liefern.

3. mögliche Deutung:

Liefere alle Elemente der Verarbeitungs-Eingangsmenge des RTN-Bausteins „WHERE", welche in zumindest einem (Zahlen-)Tabellenfeld der Tabelle Firmen den Wert 5 enthalten. Somit würde die Verarbeitungs-Ausgangsmenge des RTN-Bausteins „WHERE" für die weitere Verarbeitung je Ort alle Elemente der Tabelle Firmen liefern, die in zumindest einem (Zahlen-)Tabellenfeld den Wert 5 enthalten. Weitere RTN-Bausteine sind die RTN-Bausteine „Tabellen-RTN-Baustein" bzw. „Tabellenfelder-RTN-Baustein", welche die Namen aller in der aktuellen relationalen Datenbank verwendeten Tabellen und gespeicherten Abfragen bzw. Tabellen- und Abfragefelder enthält, sowie die RTN-Bausteine „Variable", „Zahl", „Konstanten" (Definieren gültiger Konstanten), „Globale Funktionen" (zum Definieren von durch den Anwender eingebettete Funktionen in einer anderen Sprache, wie z.B. „CurrentUserO"), RTN-Bausteine für Vergleiche („>", „>=", <=", „o", „=", „BETWEEN", „IN", ...), für logische Verknüpfungen („AND", „OR", „XOR", ...), für die logische Verneinung („NOT"), für die Zusammenfassung von RTN-Bausteinen („( )") für Rechenoperationen („+", „-", „*", „/", „\", „^Λ", „Mod", „SQR", „LIM", ...).

Eine bevorzugte Variante stellen RTN-Bausteine für Aggregatsfunktionen ("Count", „All", „None", „Sum", „AVG", „Percent", ...) dar, welche jeweils auf die Elemente der ihnen zugewiesenen Verarbeitungs-Eingangsmenge ausgeführt werden und je Eingangs-Datemenge genau einen Wert in ihrer Ausgangs-Datemenge zurückliefern. RTN-Bausteine für die Datenmanipulation bzw. die Datenausgabe sind notwendig, sinnvollerweise können die nach dem Stand der Technik üblichen Befehle in dieser Richtung als RTN-Bausteine übernommen werden, so z.B. „SELECT", „UPDATE", „INSERT INTO" und „DELETE". Sinnvollerweise können RTN-Bausteine, welche die in SQL verwendbaren Join- Verknüpfungen „Left-Join", „Right-Join", „Inner-Join" und „Outer-Join" definieren, eingeführt werden. Es kann RTN-Bausteine geben, welche Funktionen von OLAP, T-SQL, GEO-SQL und in anderen SQL-Erweiterungen definierte Funktionen enthalten.

Des Weiteren besteht die Möglichkeit, umwandelbare RTN-Bausteine zu definieren, wie es z.B. beim RTN-Baustein „IN" der Fall ist: Wert IN (1, 2, 3, 4, 5) kann als RTN-Baustein * „IN" „(„ * „)" definiert werden, * ,„" * ist ein eigener RTN-Baustein. Dieser RTN-Baustein IN ist ident mit Wert = ANY (1, 2, 3, 4, 5) und kann entweder in diese RTN-Bausteine umgewandelt werden oder von der Engine als solches verarbeitet werden. Gleiches gilt für mögliche RTN-Bausteine UNION (ALL), INTERSECT, EXCLUDE, welcher entweder Mengen ohne (UNION) bzw. mit (UNION ALL) Duplikaten zusammenführen, nur Elemente nehmen, die in beiden angegeben Mengen vorhanden sind (INTERSECT) oder nur Elemente nehmen, die in keiner der beiden Mengen vorhanden sind (EXCLUDE). Diese RTN-Bausteine lassen sich in Kombination der RTN-Bausteine „ANY" / „ALL" mit gegebenenfalls dem RTN-Baustein „GroupBy" darstellen und können auch in diese RTN-Bausteine umgewandelt werden.

(1, 2, 3, 4) UNION ALL (3, 4, 5, 6) = ANY (>=1) (1, 2, 3, 4), (3, 4, 5, 6) >-l wird als Standard genommen und muss nicht angeben werden.

(1, 2, 3, 4) UNION (3, 4, 5, 6) = GROUPBY ANY (>=1) (1, 2, 3, 4), (3, 4, 5, 6) kann vom Optimizer anders abgearbeitet werden

(1, 2, 3, 4) INTERSECT (3, 4, 5, 6) = ALL (1, 2, 3, 4), (3, 4, 5, 6)

(1, 2, 3, 4) EXCLUDE (3, 4, 5, 6) = ANY (=1) (1, 2, 3, 4), (3, 4, 5, 6)

Wie zu ersehen ist, lassen sich mit ANY und ALL bei mehr als zwei Mengen viel genauere Beschreibungen darstellen, als dies mit UNION usw. möglich wäre. Eine Definition dieser RTN-Baustein kann aber aus Gründen der Kompatibilität zu SQL als auch der bequemeren Anwendbarkeit erfolgen, zumal das Vorhandensein beliebig vieler RTN-Bausteine keine Nachteile bringt.

Ebenso kann bei den RTN-Bausteinen „AND", „OR" / „XOR" verfahren werden: Diese RTN-Bausteine lassen sich in Kombination der RTN-Bausteine „ANY" / „ALL" mit dem RTN-Baustein „Verarbeitung-SameParents" darstellen und können auch in diese RTN- Bausteine umgewandelt werden.

WHERE (Firmen.Branche="Verkauf ' ) AND (MAX (Firmen.[Angestellte.Count])#100)

ALL Firmen.// WHERE (Firmen.Branche="Verkauf) MAX([Angestellte.Count])#l 00 W

WHERE (Firmen.Branche="Verkauf ) OR (MAX (Firmen. [Angestellte.Count])#l 00) ANY (>=1) Firmen.// WHERE (Firmen.Branche="Verkauf) MAX([Angestellte.Count])#100

W

WHERE (Firmen.Branche="Verkauf ' ) XOR (MAX (Firmen.[Angestellte.Count])#100)

ANY (=1) Firmen.// WHERE (Firmen.Branche="Verkauf) MAX([Angestellte.Count])#100 W

WHERE (Firmen.Branche="Verkauf ) AND (Firmen.[Angestellte.Count]>100) lässt sich beispielsweise auch so darstellen, da die Verarbeitungs-Ausgangsmenge des ersten äußersten RTN-Bausteins „WHERE" dem zweiten äußersten RTN-Baustein „WHERE" als Verarbeitungs-Eingangsmenge übergeben wird: WHERE (Firmen.Branche="Verkauf ) WHERE (Firmen. [Angestellte.Count]> 100)

Weitere umwandelbare RTN-Bausteine sind beispielsweise der RTN-Baustein „Mengenelemente begrenzend", umwandelbar in den RTN-Baustein „FOR-NEXT", „IF- THEN-ELSE", umwandelbar in den RTN-Baustein „ SELECT-C ASE", der RTN-Baustein „Count", umwandelbar in die RTN-Bausteine „SUM" und „ 1 " usw.

Eine Anfrage besteht aus einem ersten Anfangs-RTN-Baustein, im konkreten dem Ebenen- RTN-Baustein, welcher eine benötigte Anzahl an RTN-Bausteinen in angegebener Reihenfolge enthält.

Definitionsgemäß gibt es RTN-Bausteine, welche mit einer Entscheidungsposition 300 im Entscheidungsgraphen beginnen. Um bei jedem Statement die verwendeten RTN-Bausteine festzustellen, ist die Anwendung eines Umwandlungsschrittes vor Ausfuhrung der Auswahlschritte auf das ersten Statements notwendig, um die RTN-Bausteine in zwei Gattungsgruppen zu unterteilen und sich für jeden RTN-Baustein die entsprechende Gattungsgruppe für die weitere Verarbeitung zu merken. In einem Umwandlungsschritt vor Ausfuhrung der Auswahlschritte wird jeder RTN-Baustein entweder einer ersten oder einer zweiten Gattungsgruppe zugeordnet wird, wobei

die RTN-Bausteine, die mit Text, Sonderzeichen, Variable oder Zahl beginnen, der ersten Gattungsgruppe zugeordnet und derart umgewandelt werden, dass die Entscheidungspositionen, die eine rekursive RTN-Baustein-Einsetzposition, deren Auswahlschritt auf alle RTN-Bausteine angewandt wird, enthalten, darauf beschränkt werden, dass der Auswahlschritt nur auf RTN-Bausteine der ersten Gattungsgruppe angewandt wird, und

die RTN-Bausteine, die mit einer rekursiven RTN-Baustein-Einsetzposition beginnen, der zweiten Gattungsgruppe zugeordnet und derart umgewandelt werden, dass die erste Entscheidungsposition entfernt wird und Entscheidungspositionen, die eine rekursive RTN- Baustein-Einsetzposition, deren Auswahlschritt auf alle RTN-Bausteine angewandt wird, enthalten, darauf beschränkt werden, dass der Auswahlschritt nur auf RTN-Bausteine der ersten Gattungsgruppe angewandt wird, und

allen RTN-Bausteine der ersten Gattungsgruppe und jene RTN-Bausteinen der zweiten Gattungsgruppe, welche mit einem Text, Sonderzeichen, Variable oder Zahl an der letzten Entscheidungsposition enden, eine optional ausführbare Entscheidungsposition an letzter Stelle angehängt wird, an welcher der Auswahlschritt nur auf RTN-Bausteine der zweiten Gattungsgruppe angewandt wird.

Dieser Umwandlungsschritt soll zur Verdeutlichung nochmals für einige der neu definierten RTN-Bausteine gezeigt werden:

Zum Beispiel sei die Umwandlung für einen RTN-Baustein ohne Entscheidungsposition 300 als erste Entscheidungsposition im Entscheidungsgraphen gezeigt:

„(" * „)" wird umgewandelt in

„(" RTN-Baustein erste Gattungsgruppe „)" [RTN-Baustein zweiter Gattungsgruppe] Zum Beispiel sei die Umwandlung für einen RTN-Baustein mit Entscheidungsposition 300 als erste Entscheidungsposition und mit Entscheidungsposition 300 als letzte Entscheidungsposition im Entscheidungsgraphen gezeigt:

* ( -L" I "\ * V" I 55 )

Wird umwandelt in

(„+" I „-") RTN-Baustein erste Gattungsgruppe

Zum Beispiel sei die Umwandlung für einen RTN-Baustein mit Entscheidungsposition 300 als erste Entscheidungsposition und ohne Entscheidungsposition 300 als letzte Entscheidungsposition im Entscheidungsgraphen gezeigt:

* „IN" „(" * „)"

Wird der zweiten Gattungsgruppe zugeordnet und umgewandelt in

„IN" „(" RTN-Baustein erste Gattungsgruppe „)" [RTN-Baustein zweiter Gattungsgruppe]

Durch diesen Umwandlungsschritt wird sichergestellt, dass jedes angegebene Statement mit Algorithmen nach dem Stand der Technik in RTN-Bausteine zerlegt werden kann, also die volle Flexibilität der RTN-Bausteine bei Formulierung von Anfragen genutzt werden kann.

Nach diesem Umwandlungsschritt beginnt jeder RTN-Baustein mit zumindest einem Text, zumindest einem Sonderzeichen, einer Variable oder einer Zahl und jeder Auswahlschritt wird nunmehr entweder nur auf RTN-Bausteine der ersten Gattungsgruppe oder nur auf RTN- Bausteine der zweiten Gattungsgruppe angewandt. Des Weiteren werden nach diesem Umwandlungsschritt RTN-Bausteine der zweiten Gattungsgruppe nur an letzter Entscheidungsposition eines Entscheidungsgraphen optional aufgerufen.

Wie vorher bereits erwähnt, ergibt sich speziell durch die notwendige Umwandlung in die zwei Gattungsgruppen eine für die weitere Verarbeitung nicht zutreffende Schachtelung der RTN-Bausteine, da jeweils ein RTN-Baustein der ersten Gattungsgruppe, wenn im Statement vorhanden, einen RTN-Baustein der zweiten Gattungsgruppe aufruft, dieser RTN-Baustein der zweiten Gattungsgruppe aber auf jedem Fall zumindest diesem aufrufenden RTN- Baustein der ersten Gattungsgruppe übergeordnet wird.

Definitionsgemäß gibt es RTN-Bausteine, welche mit einer Entscheidungsposition 300 im Entscheidungsgraphen beginnen. Bei diesen RTN-B austeinen kann bei Mehrfach- Verschachtelungen nicht eindeutig gesagt werden, welchen RTN-Bausteinen sie übergeordnet sind, da an einer Entscheidungsposition 300 sämtliche RTN-Bausteine der ersten oder zweiten Gattungsgruppe eingesetzt werden können und dies bei Schachtelungen von RTN-Bausteinen nicht eindeutig ist.

Beispiel 11:

Folgendes einfaches Beispiel soll dies verdeutlichen:

WHERE A + B / C

Im ersten Schritt wird die Schachtelung der RTN-Bausteine nach Anwendung der Auswahlschritte auf das Statement gezeigt.

WHERE RTN-Baustein erster Gattungsgruppe [RTN-Baustein zweiter Gattungsgruppe] A [RTN-Baustein zweiter Gattungsgruppe]

+ RTN-Baustein erster Gattungsgruppe

B [RTN-Baustein zweiter Gattungsgruppe]

I RTN-Baustein erster Gattungsgruppe C [RTN-Baustein zweiter Gattungsgruppe]

Es ist jetzt ersichtlich, dass für den RTN-Baustein „+" an der ersten Entscheidungsposition 300 folgende zwei Einsetz-Möglichkeiten zum Entsetzen bestehen:

* (WHERE *) + *

* (A) + * Ebenso ist gibt es für die zweite Entscheidungsposition 300 des RTN-Bausteins „+" zwei Einsetz-Möglichkeiten:

* + * (B)

Für den RTN-Baustein „/" ergeben sich folgende drei Einsetz-Möglichkeiten für seine erste Entscheidungsposition 300:

* (WHERE *

*) /

/ *

* (B) / *

Für den RTN-Baustein „/" ergeben sich nur eine Einsetz-Möglichkeit für seine zweite Entscheidungsposition 300 :

* / * (B)

Um diese einfachen sowie komplexere Fälle immer eindeutig und richtig aufzulösen, ist es notwendig, jedem RTN-Baustein eine erste und eine zweite Gewichtung zuzuweisen, wobei die Gewichtung für die einzelnen RTN-Bausteine und deren Berücksichtigung zur Umschachtelung aller im Statement gefundenen RTN-Bausteine untereinander . nach folgendem Verfahren bestimmt wird:

Jedem RTN-Baustein wird eine erste Gewichtung zugeordnet, durch welche während jedes Auswahlschrittes oder nach Anwendung alle Auswahlschritte die Verschachtelung der RTN- Bausteine in eine für die weitere Verarbeitung anwendbare Verschachtelung geändert wird, indem RTN-Bausteine mit höherer erster Gewichtung jeweils den ursprünglich übergeordneten RTN-Bausteinen übergeordnet werden, die eine vergleichsweise niedrigere erster Gewichtung aufweisen.

Die erste Gewichtung aller RTN-Bausteine der ersten Gattungsgruppe ist in Abhängigkeit von im Statement direkt übergeordneten RTN-Bausteinen der zweiten Gattungsgrappe abhängig, und die den RTN-Bausteinen der ersten Gattungsgruppe zugeordnete erste Gewichtung wird daher als Anfangs-Gewichtung bezeichnet.

Die RTN-Bausteine der ersten Gattungsgruppe weisen eine identische erste Anfangs- Gewichtung vorzugsweise mittlerer Höhe auf und diese RTN-Bausteine der ersten Gattungsgruppe nehmen bei Einsetzen in RTN-Bausteine der zweiten Gattungsgruppe deren um einen Wert, vorzugsweise eins, verminderte erste Gewichtung an.

Als Beispiel bekommt der RTN-Baustein „Tabellenfeld", wie alle anderen RTN-Bausteine der ersten Gattungsgruppe auch, eine erste Anfangs-Gewichtung 200, der RTN-Baustein „Strich-Rechen-Operationen" hat eine Gewichtung 17.

Wird geschrieben: „A" (Tabellenfeld) „+" (Strich-Rechen-Operationen) „B" (Tabellenfeld), bekommen die beiden RTN-Bausteine Tabellenfeld statt ihrer ursprünglichen ersten Anfangs- Gewichtung 200 die um 1 verminderte erste Gewichtung 17 des ihnen überzuordnenden RTN-Bausteins Strich-Rechen-Operationen zugewiesen, die beiden RTN-Bausteine Tabellenfeld erhalten also aufgrund des Statements eine Gewichtung 16 und werden beide aufgrund ihrer niedrigeren ersten Gewichtung (16) dem RTN-Baustein Strich-Rechen- Operationen (Gewichtung 16) untergeordnet.

Die erste Gewichtung für die RTN-Bausteine der zweiten Gattungsgruppe wird wie folgt bestimmt:

• Jene RTN-Bausteine der zweiten Gattungsgruppe, die ihre Verarbeitungsfunktion auf die Verarbeitungs-Ausgangsmenge einer Verarbeitungsfunktion eines RTN-Bausteins der ersten oder zweiten Gattungsgruppe ausführen, bilden eine erste

Gattungsuntergruppe der zweiten Gattungsgruppe und bekommen jeweils die gleiche erste Gewichtung zugewiesen, welche nicht die höchst-mögliche Gewichtung ist, aber höher als die erste Anfangs-Gewichtung mittlerer Höhe der RTN-Bausteine der ersten Gattungsgruppe ist.

So werden z.B. die Verarbeitungsfunktion RTN-Bausteine * „UNION" *, * „#" * und * „AS" V: Variablenname jeweils auf die Verarbeitungs-Ausgangsmenge bzw. Verarbeitungs- Ausgangsmengen der an ihren Entscheidungspositionen 300 direkt eingesetzten RTN-Bausteine erster oder zweiter Gattungsgruppe angewandt, weswegen diese RTN-Bausteine der ersten Gattungsuntergruppe der zweiten Gattungsgruppe zugeordnet werden und eine erste Gewichtung von 250 erhalten, wobei 200 die erste Gewichtung der RTN-Bausteine der ersten Gattungsgruppe ist und 255 als höchst-mögliche Gewichtung angenommen wird.

Dadurch wird sichergestellt, dass diese RTN-Bausteine der ersten Gattungsuntergruppe der zweiten Gattungsgruppe immer den RTN-Bausteinen der ersten und zweiten Gattungsgruppe übergeordnet werden, und daher defmitionsgemäß deren Verarbeitungs- Ausgangsmenge als ihre Verarbeitungs-Eingangsmenge zugewiesen bekommen.

• Jene RTN-Bausteine der zweiten Gattungsgruppe, deren Verarbeitungs- Ausgangsmenge als Verarbeitungs-Eingangsmenge für andere RTN-Bausteine der ersten oder zweiten Gattungsgruppe herangezogen werden, bilden eine zweite

Gattungsuntergruppe der zweiten Gattungsgruppe und bekommen eine jeweils unterschiedliche erste Gewichtung zugewiesen, welche in jedem Fall kleiner als die erste Anfangs-Gewichtung mittlerer Höhe der RTN-Bausteine der ersten Gattungsgruppe ist, und diese erste Gewichtung für die betroffenen RTN-Bausteine im einzelnen die vorbestimmbare Reihenfolge der Abarbeitung in Bezug auf die RTN-

Bausteine der zweiten Gattungsuntergruppe der zweiten Gattungsgruppe beschreibt, indem jeweils zuerst auszuführende RTN-Bausteine dieser Gruppe eine geringere erste Gewichtung erhalten.

So bekommt z.B. der RTN-Baustein „Punkt-Rechen-Operationen" eine erste Gewichtung 14, der RTN-Baustein „Strich-Rechen-Operationen" eine höhere erste Gewichtung 17, der RTN- Baustein „Vergleich" eine erste Gewichtung 50 und der RTN-Baustein „Bool-Kombi" eine erste Gewichtung 100.

Dies ersieht man aus der gewünschten Schachtelung von: A + B * C > D AND E = F

Alle hier angegebenen ersten Gewichtungen sind kleiner als die erst Anfangs-Gewichtung 200 der RTN-Bausteine der ersten Gattungsgruppe. Um falsche Verschachtelungen bei jenen RTN-Bausteinen erster und zweiter Gattungsgruppe, welchen nach einer Entscheidungsposition 300 eine weitere Entscheidungsposition vor der nach dem Umwandlungsschritt als optional angefügten letzten Entscheidungsposition 300 zumindest eine weitere Entscheidungsposition folgt, auszuschließen, ist die Vergabe einer zweiten Gewichtung maximaler Höhe für genau diese RTN-Bausteine notwendig. Konkrete falsche Verschachtelungen würden sich ansonsten genau dann ergeben, wenn in diesen RTN- Bausteinen an einer nicht letzten Entscheidungsposition 300 zumindest ein RTN-Baustein der ersten Gattungsuntergruppe der zweiten Gattungsgruppe eingesetzt wird, also ein RTN- Baustein, welcher eine höhere Gewichtung als die mittlere Gewichtungshöhe der RTN- Bausteine der ersten Gattungsgruppe aufweist. Diese RTN-Bausteine dürfen trotz ihrer höheren ersten Gewichtung genau solange nicht über RTN-Bausteine mit maximaler zweiter Gewichtung übergeschachtelt werden, bis diese RTN-Bausteine mit maximaler zweiter Gewichtung im Entscheidungspfad an der nach dem Umwandlungsschritt letzten, als optional eingefügten Entscheidungsposition 300 angelangt sind.

Deswegen gilt, dass alle RTN-Bausteine der ersten und zweiten Gattungsgruppe, welche nach einer Entscheidungsposition 300, welche das Einsetzen zumindest eines RTN-Bausteins aus ersten Gattungsgruppe vorschreibt, zumindest eine weitere Entscheidungsposition unabhängig von der nach dem Umwandlungsschritt gegebenenfalls vorhanden letzten optionalen Entscheidungsposition 300, welche das Einsetzen eines RTN-Bausteins aus der zweiten Gattungsgruppe vorschreibt, folgt, eine zweite, fixe Gewichtung mit höchst-möglicher Gewichtungs-Höhe zugewiesen wird.

Ein Beispiel für einen RTN-Baustein der ersten Gattungsgruppe, der definitionsgemäß keine zweite Gewichtung maximaler Höhe zugewiesen bekommt, ist der RTN-Baustein „WHERE":

„WHERE" * nach Umwandlungsschritt:

„WHERE" RTN-Baustein erster Gattungsgruppe [RTN-Baustein zweiter Gattungsgruppe]

Bei diesem RTN-Baustein folgt, außer der durch den Umwandlungsschritt angefügten letzten optionalen Entscheidungsposition 300 keine weitere Entscheidungsposition nach der ersten Entscheidungsposition 300, die zweite Gewichtung für diesen RTN-Baustein kann daher z.B. den Wert der ersten Gewichtung dieses RTN-Bausteins erhalten.

Zwei Beispiele für RTN-Bausteine, der ersten Gattungsgruppe, die definitionsgemäß eine zweite Gewichtung maximaler Höhe zugewiesen bekommten, sind der RTN-Baustein „RTN- Baustein-Zusarnmenfassend" (Klammer) und der RTN-Baustein „For-Next":

_»(" * _»)" nach Umwandlungsschritt:

„(" RTN-Baustein erster Gattungsgruppe „)" [RTN-Baustein zweiter Gattungsgruppe]

„FOR" * ,,:" * „NEXT" nach Umwandlungsschritt:

„FOR" RTN-Baustein erster Gattungsgruppe „:" RTN-Baustein erster Gattungsgruppe

„NEXT" [RTN-Baustein zweiter Gattungsgruppe]

Bei diesen RTN-Bausteinen folgt jeweils zusätzlich zu der durch den Umwandlungsschritt angefügten letzten optionalen Entscheidungsposition 300 jeweils zumindest eine Entscheidungsposition nach der jeweils ersten Entscheidungsposition 300, die zweite Gewichtung für diese RTN-Bausteine entspricht daher der höchst-möglichen Gewichtungs- Höhe, im konkreten 255.

Gleiches gilt für die RTN-Bausteine der zweiten Gattungsgruppe, beispielsweise wird dies gezeigt für den RTN-Baustein „Strich-Rechen-Operationen" und für den RTN-Baustein „Vergleich-IN":

* („+"| „-") * nach Umwandlungsschritt:

(_«+" I _»-") RTN-Baustein erster Gattungsgruppe

Bei diesem RTN-Baustein folgt, nach Umwandlungsschritt keine weitere Entscheidungsposition nach der einzigen Entscheidungsposition 300, die zweite Gewichtung für diesen RTN-Baustein kann daher z.B. den Wert der ersten Gewichtung dieses RTN- Bausteins erhalten.

* „IN" „(" * „)" nach Umwandlungsschritt: „IN" RTN-Baustein erster Gattungsgruppe [RTN-Baustein zweiter Gattungsgruppe]

Bei diesen RTN-Bausteinen folgt zusätzlich zu der durch den Umwandlungsschritt angefügten letzten optionalen Entscheidungsposition 300 eine Entscheidungsposition nach der ersten Entscheidungsposition 300, die zweite Gewichtung für diesen RTN-Baustein entspricht daher der höchst-möglichen Gewichtungs-Höhe, im konkreten 255.

Für die Bestimmung der für die weitere Verarbeitung notwendigen Schachtelung eines jeden RTN-Bausteins in Bezug auf die jeweils im Statement ihm durch die Anwendung der Auswahlschritte nach dem Umwandlungsschritt übergeordneten RTN-Bausteine gilt daher, dass die erste Gewichtung jedes RTN-Bausteins der zweiten Gattungsgruppe in der durch das Anfragestatement nach dem Umwandlungsschritt sich ergebenden Schachtelungsreihenfolge solange mit der ersten Gewichtung der jeweils übergeordneten RTN-Bausteine verglichen wird, bis derjenige RTN-Baustein mit einer höheren ersten Gewichtung oder der jeweils übergeordnete RTN-Baustein sich nicht an seiner letzten Entscheidungsposition befindet und eine zweite Gewichtung höchst-möglicher Gewichtungs-Höhe aufweist, erreicht wird und entsprechend dieser festgestellten Schachtelungsreihenfolge der dem Vergleich zugrunde liegende RTN-Baustein dem erreichten RTN-Baustein direkt untergeordnet und allen mittels der Vergleiche übersprungen vorher übergeordneten RTN-Bausteine somit übergeordnet wird.

Folgendes Beispiel soll dies verdeutlichen:

Beispiel 12: Zu analysierende Syntax:

IF A THEN WHERE B=C # 5 ELSE WHERE D=E #10 END IF # 20

Die für die weitere Verarbeitung gültige Schachtelung in diesem Beispiel 12 sieht folgendermaßen aus:

*(1.1) # *(1.2) erste Gew. 250, zweite Gew. 250

(_"U) IF *(2.1) THEN *(2.2) ELSE *(2.3) END IF erste Gew. 200, zweite Gew. 255 (=2.1) A erste Gew. 200, zweite Gew. 1 ("2.2) *(3.1) # *(3.2) erste Gew. 200, zweite Gew. 200

(=3.1) *(4.1) = *(4.2) erste Gew. 50, zweite Gew. 50 (=4.1) B erste Gew. 49 (Anfang 200), zweite Gew. 1 (=4.2) C erste Gew. 49 (Anfang 200), zweite Gew. 1

(=3.2) 5 erste Gew. 249(Anfang 200), zweite Gew. 1 (=2.3) *(5.1) # *(5.2) erste Gew. 250, zweite Gew. 250

(=5.1) *(6.1) = *(6.2) erste Gew. 50, zweite Gew. 50 (=6.1) D erste Gew. 49 (Anfang 200), zweite Gew. 1 (=6.2) E erste Gew. 49 (Anfang 200), zweite Gew. 1

(=5.2) 10 erste Gew. 249(Anfang 200), zweite Gew. 1

(=1.2) 20 erste Gew. 249(Anfang 200), zweite Gew. 1

wobei erste Ge w Erste Gewichtung zweite Gew... Zweite Gewichtung Anfang Anfangsgewichtung der RTN-Bausteine der ersten Gattungsgruppe, angegeben, sofern diese geändert durch Einsetzen in einen RTN-Baustein der zweiten Gattungsgruppe geändert wird.

Hier ist zu ersehen, dass der RTN-Baustein „#" mit seiner ersten Gewichtung 250 dem RTN- Baustein „IF-THEN-ELSE-END IF" mit seiner ersten Gewichtung 200 und seiner zweiten Gewichtung 255 erst dann übergeordnet wird, nachdem dieser seine letzte Entscheidungsposition erreicht hat.

Für die Vollständigkeit der Beschreibung dieses Beispiels 12 sei hier noch einmal die Schachtelung gezeigt, die sich in diesem Beispiel durch die Anwendung der Auswahlschritte ^■nach dem Umwandlungsschritt ergibt:

IF Aufruf: RTN-Baustein erster Gattungsgruppe

A THEN Aufruf: RTN-Baustein erster Gattungsgruppe

WHERE Aufruf: RTN-Baustein erster Gattungsgruppe B Aufruf: RTN-Baustein zweiter Gattungsgruppe Aufruf: RTN-Baustein erster Gattungsgruppe Aufruf: RTN-Baustein zweiter Gattungsgruppe

# Aufruf: RTN-Baustein erster Gattungsgruppe

ELSE Aufruf: RTN-Baustein erster Gattungsgruppe

WHERE Aufruf: RTN-Baustein erster Gattungsgruppe D Aufruf: RTN-Baustein zweiter Gattungsgruppe Aufruf: RTN-Baustein erster Gattungsgruppe

E Aufruf: RTN-Baustein zweiter Gattungsgruppe

# Aufruf: RTN-Baustein erster Gattungsgruppe

10

END IF Aufruf: RTN-Baustein zweiter Gattungsgruppe

# Aufruf: RTN-Baustein erster Gattungsgruppe

20

RTN-Bausteine der ersten Gattungsgruppe werden, unabhängig von ihrer eigenen und unabhängig von der ersten Gewichtung der ihnen übergeordneten RTN-Bausteine dem ihnen direkt übergeordneten RTN-Baustein erster oder zweiter Gattungsgruppe untergeordnet.

Beispiel 13:

Zu analysierende Syntax: WHERE A + MIN B

Dieses Beispiel 13 wird wie folgt verschachtelt:

WHERE * (Li) erste Gew. 200, zweite Gew. 200

(=1.1) *(2.1) + *(2.2) erste Gew. 50, zweite Gew. 50 (=2.1) A erste Gew. 49 (Anfang 200), zweite Gew. 1 (=2.2) MIN *(3Jj erste Gew. 49 (Anfang 200), zweite Gew. 200

(=3.1) B erste 200, zweite Gew. 1 Wie in diesem Beispiel 13 zu sehen ist, wird der RTN-Baustein „B" als RTN-Baustein der ersten Gattungsgruppe trotz seiner höheren ersten Gewichtung 200 im Vergleich zu dem ihm übergeordneten RTN-Baustein „MIN" mit seiner durch seinen übergeordneten RTN-Baustein der zweiten Gattungsgruppe „+" veränderten ersten Gewichtung 49 untergeordnet.

Wird bei Vergleich der ersten Gewichtung von RTN-Bausteinen der zweiten Gattungsgruppe ein übergeordneter RTN-Baustein mit gleicher erster Gewichtung angetroffen, so wird je nach Gattungsuntergruppe anders verfahren:

Für den Fall des Vorliegens gleicher erster Gewichtung des zu vergleichenden RTN- Bausteins zweiter Gattungsgruppe mit einem der übergeordneten RTN-Bausteine ebenfalls zweiter Gattungsuntergruppe wird der zu vergleichende RTN-Baustein diesem RTN-Baustein genau dann direkt untergeordnet wird, wenn es sich bei diesen RTN-Bausteinen um RTN- Bausteine der zweiten Gattungsuntergruppe der zweiten Gattungsgruppe handelt.

Folgendes Beispiel soll dies verdeutlichen:

Beispiel 14:

WHERE A MOD B / C \ D

WHERE *(1.1) - erste Gew. 200, zweite Gew. 200

(=1.1) *(2.1) MOD *(2.2) erste Gew. 14, zweite Gew. 14

(=2.1) A erste Gew. 13 (Anfang 200), zweite Gew. 1 (=2.2) *(3.1) I *(3.2) erste Gew. 14, zweite Gew. 14

(=3.1) B erste Gew. 13 (Anfang 200), zweite Gew. 1

(=3.2) *(4.1) \ *(4.2) erste Gew. 14, zweite Gew. 14

(=4.1) C erste Gew. 13 (Anfang 200), zweite Gew. 1

(=4.2) D erste Gew. 13 (Anfang 200), zweite Gew. 1

In diesem Beispiel 14 treffen beim Vergleich der ersten Gewichtung zweimal RTN-Bausteine der zweiten Gattungsuntergruppe der zweiten Gattungsgruppe aufeinander („/" trifft auf MOD", „\" trifft auf „/"). Aufgrund der Zuordnung zur zweiten Gattungsuntergruppe der zweiten Gattungsgruppe werden diese RTN-Bausteine jeweils untergeordnet, da definiert wird, dass die Verarbeitungs-Ausgangsmenge der untergeordneten RTN-Bausteine als Verarbeitungs-Eingangsmenge der jeweils übergeordneten RTN-Bausteine herangezogen wird. Durch die die Verwendung eines RTN-Baustein „RTN-Bausteine-Zusammenfassend", also durch das Setzten von Klammern, kann eine andere erste und zweite Gewichtung und dadurch eine andere Berechnungsreihenfolge erzielt werden.

Für den Fall des Vorliegens gleicher erster Gewichtung des zu vergleichenden RTN- Bausteins zweiter Gattungsgruppe mit einem der übergeordneten RTN-Bausteine ebenfalls zweiter Gattungsuntergruppe wird genau dann weiter mit den übergeordneten RTN- Bausteinen verglichen, wenn es sich bei den RTN-Bausteinen um RTN-Bausteine der ersten Gattungsuntergruppe der zweiten Gattungsgruppe handelt.

Folgendes Beispiel soll dies verdeutlichen:

Beispiel 15:

Nimm alle Elemente, für die A zutrifft, von dieser Menge nimm die ersten 100, speichere diese 100 Elemente in der Zwischenmenge 1 und nimm aus dieser Zwischenmenge 1 die ersten 50 Elemente.

Zu analysierende Syntax: WHERE A # 100 AS Zwischenmenge # 50

*(i.i) # *(U) erste Gew. 250, zweite Gew. 250

(=1.1) *(2.1) AS Zwischenmenge erste Gew. 250, zweite Gew. 250

(=2.1) *(3.1) # *(3.2) erste Gew. 250, zweite Gew. 250

(=3.1) WHERE V; erste Gew. 249(Anfang 200), zweite Gew. 200

M.i) A erste Gew. 200, zweite Gew. 1 (=3.2) 100 erste Gew. 249(Anfang 200), zweite Gew. 1

(=1.2) 50 erste Gew. 249(Anfang 200), zweite Gew. 1 In diesem Beispiel 15 treffen beim Vergleich der ersten Gewichtung zweimal RTN-Bausteine der ersten Gattungsuntergruppe der zweiten Gattungsgruppe aufeinander („AS" trifft auf „#", „#" trifft auf „AS")- Aufgrund der Zuordnung zur ersten Gattungsuntergruppe der zweiten Gattungsgruppe werden diese RTN-Bausteine jeweils vorgereiht, da definiert wird, dass die Verarbeitungs-Ausgangsmenge der untergeordneten RTN-Bausteine als Verarbeitungs- Eingangsmenge der jeweils übergeordneten RTN-Bausteine herangezogen wird.

Wichtig ist, dass RTN-Bausteine, welche direkt in eine Entscheidungsposition 300 eines RTN-Bausteins mit höchst-möglicher zweiter Gewichtung eingesetzt werden, nur dann RTN- Bausteinen der zweiten Gattungsgruppe untergeordnet werden, wenn es für den jeweiligen RTN-B austein erwünscht ist. Dies erfolgt verfahrensmäßig dadurch, dass jenen RTN- Bausteinen der ersten Gattungsgruppe, für die vorbestimmt wird, dass sie den RTN-Bausteine der zweiten Gattungsgruppe dann untergeordnet werden, wenn diese RTN-Bausteine der ersten Gattungsgruppe direkt in eine der Entscheidungsposition, an welcher einer aus der Gesamtheit der RTN-Bausteine einsetzbar ist, eines RTN-Bausteins, welcher eine zweite höchst-möglichen Gewichtungs-Höhe aufweist, eingesetzt werden, eine zweite Gewichtung minimaler Gewichtungshöhe zugewiesen wird, und jene RTN-Bausteine der ersten Gattungsgruppe, welche keine zweite Gewichtung minimaler Höhe aufweisen, in diesen Fällen keinen RTN-Bausteinen der zweiten Gattungsgruppe untergeordnet werden.

Zwei Beispiele sollen die Schachtelung für diese beiden möglichen Fälle zeigen, der nach dem oben beschriebenen Verfahren zu folgendem Ergebnis führt:

Beispiel 16:

1. Möglicher Fall: An der Entscheidungsposition 300 des übergeordneten RTN-Bausteins mit zweiter Gewichtung höchst-möglicher Gewichtungshöhe wird ein RTN-Baustein der ersten Gattungsgruppe mit einer zweiten Gewichtung ungleich der Gewichtung minimaler Gewichtungshöhe eingesetzt, im Beispiel das Schlüsselwort „WHERE":

[ WHERE MAX A + B / C = D ] Die für die weitere Verarbeitung gültige Verschaclitelung in diesem Beispiel 16 schaut folgendermaßen aus:

[ * (1.1) ] erste Gew. 200, zweite Gew. 255 (=1.1) WHERE *(2.1) erste Gew. 200, zweite Gew. 200

(2.1) *(3.1) = *(3.2) erste Gew. 50, zweite Gew. 50

(=3.1) MAX *(4.1) erste Gew. 49(Anfang 200), zweite Gew. 200

(=4.1) *(5.1) + *(5.2) erste Gew. 17, zweite Gew. 17

(=5.1) A erste Gew. 16(Anfang 200), zweite Gew. 1 (=5.2) * (6.1) I * (6.2) erste Gew 14. , zweite Gew. 14

(=6.2) B erste Gew. 13 (Anfang 200), zweite Gew. 1

(=6.3) C erste Gew. 13 (Anfang 200), zweite Gew. 1

(=3.2) D erste Gew. 49, zweite Gew. 200

Der RTN-Baustein „MAX" wird deswegen dem RTN-Baustein mit dem Schlüsselwort „/" untergeordnet, da sein übergeordneter RTN-Baustein „WHERE" keine Gewichtung höchstmöglicher Gewichtungshöhe aufweist.

Der RTN-Baustein „WHERE" sollte nach der globalen Definition dem RTN-Baustein mit dem Schlüsselwort „=" untergeordnet werden, in diesem Fall geschieht dies aber nicht, da sein übergeordneter RTN-Baustein „Ebenen" („[]") die zweite höchst-mögliche Gewichtungshöhe aufweist, der RTN-Baustein „WHERE" aber nicht die zweite Gewichtung minimaler Gewichtungshöhe aufweist.

Soll eine andere Schachtelung der RTN-Bausteine erfolgen, kann dies durch die Verwendung des RTN-Bausteins „RTN-Baustein-Zusammenfassend" („( )") geschehen, z.B. WHERE (MAX (A + B / C) = D), gleichwertig mit MAX A + B / C

Beispiel 17:

2. Möglicher Fall: An der Entscheidungsposition 300 des übergeordneten RTN-Bausteins mit zweiter Gewichtung höchst-möglicher Gewichtungshöhe wird ein RTN-Baustein der ersten Gattungsgruppe mit einer zweiten Gewichtung minimaler der Gewichtung eingesetzt, im Beispiel das Schlüsselwort „A":

[ A + B ]

[ *(1.1) ] erste Gew. 200, zweite Gew. 255

(=1.1) *(2.1) + *(2.2) erste Gew. 17, zweite Gew. 17

(=2.1) A erste Gew. 16 (Anfang 200), zweite Gew. 1

(=2.2) B erste Gew. 16 (Anfang 200), zweite Gew. 1

In diesem Beispiel 17 ist zu ersehen, dass der RTN-Baustein „Strich-Rechen-Operationen" dem RTN-Baustein „Tabellenfeld" (A) übergeordnet wird, da der RTN-Baustein „A" direkt in die Entscheidungsposition 300 des RTN-Bausteins „Ebenen" eingesetzt ist, der RTN- Baustein A eine zweite Gewichtung minimaler Gewichtungshöhe aufweist und der direkt übergeordnete RTN-Bausteinen „Ebenen" eine zweite Gewichtung höchst-möglicher Gewichtungshöhe aufweist.

Eine weitere Ausführungsform der Erfindung liegt in jenem Fällen vor, wo laut Statement RTN-Bausteinen der zweiten Gattungsgruppe, denen nach dem Umwandlungsschritt eine optionale Entscheidungsposition, welche auf einen RTN-Baustein aus der zweiten Gattungsgruppe vorschreibt, an genau dieser optionalen Entscheidungsposition ein .RTN- Baustein der zweiten Gattungsgruppe eingesetzt wird.

In diesen Fällen wird der an dieser letzten Entscheidungsposition eingesetzte RTN-Baustein immer und unabhängig von den ersten und zweiten Gewichtungen der beiden betroffenen RTN-Bausteine dem vormals übergeordneten RTN-Baustein übergeordnet.

Um dies zu verdeutlichen, dient folgendes Beispiel, welches besagt, dass der Wert des Feldes A in der Variable „Zwischenmenge" gespeichert werden soll, zu dieser Variable „Zwischenmenge" der Wert des Feldes B addiert werden soll und danach geprüft wird, ob dieser Wert dem Wert C entspricht und das Ergebnis dieses Vergleiches wiederum in der Variable „ErgebnisIN" gespeichert werden soll. A AS Zwischenmenge + B IN ( C ) AS ErgebnisIN

Hier wird der RTN-Baustein mit dem Schlüsselwort „+" trotz seiner niedrigeren ersten Gewichtung 17 dem RTN-Baustein mit dem Schlüsselwort „AS" mit der ersten Gewichtung 250 übergeordnet. Gleiches geschieht in Bezug auf die RTN-Bausteine mit den Schlüsselworten „IN" und „AS", wobei hier die erste Gewichtung des überzuordnenden RTN- Bausteins mit dem Schlüsselwort „AS" unabhängiger weise höher (250) ist als die erste Gewichtung (60) des RTN-Bausteins mit dem Schlüsselwort „IN"

In Übereinstimmung mit den RTN-Bausteinen lassen sich auch RTN-Baustein-Gruppen als Statements oder Teile von Statements definieren, welche z.B. ausschließlich Verarbeitungsfunktionen arithmetischer oder logischer Art beinhalten. Für diese Fälle wird vereinbart, dass allen RTN-Bausteinen der ersten und zweiten Gattungsgruppe zumindest ein RTN-Baustein zugeordnet werden kann, welche(r) überzuordnen ist bzw. sind, wenn diese RTN-Bausteine der ersten und zweiten Gattungsgruppe direkt in einer Entscheidungsposition, an welcher einer aus der Gesamtheit der RTN-Bausteine einsetzbar ist, eines RTNrBausteins mit höchst-möglicher zweiter Gewichtung eingesetzt werden. .

Auszugsweise enthalten folgende RTN-Bausteine, sofern sie direkt in eine Entscheidungsposition 300 eines RTN-Bausteins mit zweiter Gewichtung höchst-möglicher Gewichtungshöhe eingesetzt werden, unten angeführte Zuordnungen:

RTN-Baustein „Tabellenfeld": diesem RTN-Baustein kann ein „SELECT"-RTN-Baustein vorangestellt werden, sowie der RTN-Baustein „Tabelle", der den Namen der Tabelle, in der dieses Feld zu finden ist, enthält, sowie ein RTN-Baustein „Werte-Verkettung", um die beiden RTN-Bausteine „Tabelle" und „Tabellenfeld" miteinander in Bezug zu setzen.

Beispiel 18:

[ TABELLENFELDNAME ] nach Anfügung:

[ SELECT TABELLENNAME . TABELLENFELDNAME ] RTN-Baustein „Tabelle": diesem RTN-Baustein kann ein „SELECT"-RTN-Baustein für Ausgabe alle Tabellenfelder vorangestellt werden

Beispiel 19:

[ TABELLENNAME ] nach Anfügung:

[ SELECT TABELLENNAME.* ]

RTN-Bausteine, welche Rechen- oder Vergleichsoperationen ausführen: diesen RTN- Bausteinen kann ein „WHERE"-RTN-Baustein vorangestellt werden, und, falls auf nicht vorhanden, ein „SELECT"-RTN-Baustein, welcher beispielsweise alle Felder aller verwendeten Tabellen ausgibt, mit jeweils benötigten RTN-Bausteinen „Mengen-Element- Bildend" und „Werte-Verkettung".

Beispiel 20:

[ A + B ] nach Anfügung:

[ SELECT TABELLENNAME.A, TABELLENNAME.B WHERE TABELLENNAME.A + TABELLENNAME.B ]

Tabelle 1 und Tabelle 2 enthalten eine Auflistung möglicher RTN-Bausteine mit jeweils erster und zweiter Gewichtung und den Entscheidungsgraphen der RTN-Bausteine, wobei bei Durchlaufen der Entscheidungsgraphen der RTN-Bausteine an den Entscheidungspositionen die Schlüsselworte des Anfragestatements in Abhängigkeit von einem zugehörigen Kennzeichen entweder mit einem Text, einem Sonderzeichen, einer Variable, einer Zahl verglichen oder ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt wird, welcher seinerseits wieder durchlaufen wird.

Dadurch, dass an jeder Entscheidungsposition 300 immer aus der Gesamtheit der RTN- Bausteine ausgewählt werden kann, werden im Vergleich zu einer beschränkten Auswahlmöglichkeit an den Entscheidungspositionen mehr Freiheitsgrade in der Formulierung von Anfragestatements möglich. Als Beispiel sei hier der RTN-Baustein „NEXT" gezeigt, welcher aus seiner Verarbeitungs- Eingangsmenge je aktuellem Element die an der Entscheidungsposition 300 angegebenen nächsten Elemente in seiner Verarbeitungs- Ausgangsmenge zurückliefert. Würde hier anstatt der Entscheidungsposition 300 beispielsweise nur eine Zahl erlaubt werden, könnte nur die Anzahl der nächsten zu liefernden Elemente je aktuellen Element bestimmt werden, durch die Entscheidungsposition 300 könnten mittels des RTN-Bausteins „Mengenelemente-Begrenzend", an dessen erster Entscheidungsposition 300 wiederum der RTN-Baustein „ WHERE" eingesetzt ist, jene dem jeweils aktuellen Element folgenden Elemente geliefert werden, die in der Verarbeitungs- Ausgangsmenge der RTN-Bausteins „Mengenelemente-Begrenzend" stehen. Analog gilt dies für alle RTN-Bausteine, z.B. könnte mit dem RTN-Baustein „MAX" genau jenes nachfolgende Element mit dem größten, in Entscheidungsposition 300 des RTN-Bausteins „MAX" angegebenen Wert ab dem aktuellen Element gesucht werden.

Folgendes abstrahierte Beispiel soll dies verdeutlichen:

Beispiel 21 :

ORDERBY A

NEXT (WHERE B=C # 100) NEXT (MAX D # 20)

Sortiert die Menge nach dem Wert A, danach wird für jedes Element der Menge genau jene 100 Elemente geliefert, für welche der Vergleich B=C gültig ist. Von dieser Menge wird danach je Element die Menge jener nachfolgenden 20 Elemente geliefert, deren Wert D ab dem aktuellen Element zu den 20 größten gehört.

Beispiel 22:

Von der Aktie mit dem Namen Testaktie soll der Stand vom 01.01.2006 gefunden und insofern für die weitere Berechnung herangezogen werden, als dass die Anzahl der Tage, die vergangen sind, bis die Aktie seit dem Datum um 20% gestiegen ist, angezeigt werden sollen. WHERE (Aktien.Name="Testaktie") ORDERBY Aktien.Datum

FIND WHERE (Aktien.Datum=O 1.01.2006) AS StandOlOlOό SELECT NEXT (WHERE (Aktien. Stand>=StandO 10106* 1.2 # 1 ).Datum- Aktien.Datum

Beschreibung des Statements in Beispiel 22:

Die Aktie mit dem Namen „Testaktie" suchen Diese Aktien nach Datum sortieren

Suchen genau des Elementes, an dem das Datum der 01.01.2006 ist und speichern dieses

Elementes in der Variable StandOlOlOό

Ausgehend von dem durch „FIND" als aktuell markiertes Element sollen jene Aktie gesucht werden, deren Stand ausgehend vom aktuellen Element um 20% größer ist als der in der Variable StandO 10106 gespeicherte Wert.

#1 begrenzt die durch WHERE gefundenen Elemente auf das erste Element, und somit liefert

NEXT auch nur den Wert des ersten Elementes für den WHERE zutrifft.

NEXT muss verwendet werden, damit der Werte des gefundenen Elementes mit einem Wert des aktuellen Elementes verglichen werden können, im Beispiel wird die Anzahl der vergangenen Tage berechnet dadurch berechnet.

Anzeigen des Ergebnisses über das Schlüsselwort SELECT.

In diesem Zusammenhang werden beispielsweise die folgenden Kennzeichen verwendet: In [ ] angegebene Entscheidungspositionen sind nur optional auszuführen, erwartete Schlüsselworte sind unter „" angegeben, („Schlüsselwortl" | „Schlüsselwort2") steht für „Schlüsselwortl" ODER „Schlüsselwort2", * steht für die Entscheidungsposition 300 und (x) bzw. (*x) markieren jeweils Sprungpositionen von einer Stelle (*x) zu einer Stelle (x), V: Variablenname bzw. V:Zahl steht für eine frei wählbare Variable bzw. eine Zahl. Die RTN-B austeine sind in der Reihenfolge angegeben, die der Häufigkeit der Verwendung dieser RTN-Bausteine in einem Statement etwa entspricht, damit häufige RTN-Bausteϊne früher gefunden werden können und möglichst wenig Vergleiche notwendig sind. Es werden die RTN-Bausteine sowohl vor dem Umwandlungsschritt (Tabelle 1) in die zwei Gattungsgruppen als auch nach diesem Umwandlungsschritt (Tabelle 2) gezeigt.

Es wird festgestellt, dass diese Auflistung jederzeit einfach um weitere RTN-Bausteine erweitert werden kann und daher keinen Anspruch auf Vollständigkeit erhebt.

Die oben definierte konkrete Anfragesprache bietet gegenüber Anfragesprachen nach dem Stand der Technik, deren am meisten verbreiteter Vertreter die Anfragesprache SQL ist, speziell in der einfachen Formulierbarkeit von Statements und in der nachfolgenden Optimierbarkeit etliche Vorteile, welche durch sehr einfache Beispiele verdeutlicht werden sollen:

Gegeben sei eine Tabelle „Firmen", die zumindest die Felder „Firmenname" und „Ort" enthält.

Beispiel 23:

Erste Frage: Alle Firmen aus Orten mit mehr als 100 Firmen

EINE Möglichkeit der Beschreibung in SQL (Stand der Technik) : SELECT Firmen.*

FROM Firmen, (SELECT Firmen.Ort FROM Firmen GROUP BY FirmenOrt HAVING (Count(*)>100)

) AS FirmenOrteMehrAlslOO WHERE (Firmen.Ort=FirmenOrteMehrAlsl00.Ort)

Es wird die Menge der Firmen genommen, je Ort zusammengefasst und nur die Orte werden gemerkt, in denen es mehr als 100 Firmen gibt. Diese Menge wird mit der Menge der Firmen kartesisch verknüpft und es werden nur die Firmen genommen, deren Feld Ort auch in der Menge mit den Ort mit mehr als 100 Firmen zu finden ist.... Nachteil: die Menge der Orte muss gespeichert werden und die Menge der Firmen muss zweimal durchlaufen werden und einmal mit den Orten verglichen werden

EINE Möglichkeit der Beschreibung mit flexiblen RTN-Bausteinen gemäß dem erfindungsgemäßen Verfahren: SELECT Firmen.* WHERE (Firmen.Ort. WHERE ([Firmen.CounfJ>100))

Es wird die Menge der Firmen genommen, für jede Firma wird für den Ort geschaut, ob in diesem Ort mehr als 100 Firmen zu finden sind. Die gefunden Firmen werden ausgegeben. Die Abarbeitung wird durch den Optimizer natürlich wesentlich besser formuliert.

Beispiel 24:

Zweite Frage: Von jedem Ort 100 beliebige Firmen

EINE Möglichkeit der Beschreibung in SQL (Stand der Technik):

SELECT *

FROM (

SELECT Firmen.*, Row_Numberate() OVER Firmen. Ort AS FirmaOfOrt FROM Firmen

)

WHERE (FirmenOfOrt<=100)

Die Menge der Firmen durchnummerieren, je Ort neu bei 1 beginnen, das in einer Menge speichern und aus dieser Menge alle Elemente nehmen, deren Nummerierung <= 100 ist.

EINE Möglichkeit der Beschreibung mit flexiblen RTN-Bausteinen gemäß dem erfindungsgemäßen Verfahren: SELECT Firmen.* BREAKON FirmenOrt FIRST #100 Durch diese gezeigte einfachere und vor allem konkretere Formulierung der beiden Fragestellungen im Vergleich zu SQL ist auch die bessere Optimierbarkeit, also der für die Datenstruktur besser geeignete Zugriffsplan, ersichtlich.

Es folgt eine Zusammenfassung von einigen der verarbeitungsrelevanten RTN-Baustein- Informationen für die sechs angegebenen verarbeitungsrelevanten RTN-Baustein- Informationsgruppen:

Beispielsweise verarbeitungsrelevante RTN-Baustein-Informationen der ersten verarbeitungsrelevanten RTN-Baustem-Informationsgruppe sind:

- Vorläufige und endgültige Eingangsmengen-Zuweisungen für den jeweiligen RTN- Baustein nachdem die Verschachtelung derselben für ein angegebenes zu analysierende Statement festgelegt wurde

Beispielsweise verarbeitungsrelevante RTN-Baustein-Informationen der zweiten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe sind:

- oben erwähnte erste Gewichtungsgruppe oben erwähnte zweite Gewichtungsgruppe

Diese verarbeitungsrelevanten RTN-Baustein-Informationen der Gewichtungen können erst dann endgültig zum - Tragen kommen, sobald der RTN-Baustein mittels .Rest- Entscheidungsgraphen über die RTN-Baustein-unabhängige Verweisgruppe eindeutig identifiziert wurde.

Beispielsweise verarbeitungsrelevante RTN-Baustein-Informationen der dritten verarbeitungsrelevanten RTN-Baustem-Informationsgruppe kann eine

Umordnungsgewichtung je RTN-Baustein sein, welche die vorhandene Reihenfolge von benachbarten RTN-Bausteinen in einem gleichen übergeordneten RTN-Baustein umändert und dadurch einen optimierten Abarbeitungsplan geniert.

Das Ziel einer solchen Umordnungsgewichtung soll anhand des folgenden einfachen Beispiels ohne konkreten Bezug auf eine Datenstruktur gezeigt werden: Beispiel 25:

Zu analysierendes Statement:

[ SELECT *

FROM X ORDERBY A WHERE B MIN C # 5000 FIRST D # 1000

ORDERBY E MAX F # 100 ]

Der RTN-Baustein „Ebenen" hat in sich sieben RTN-Bausteine eingesetzt, welche allesamt benachbart sind:

[ (I)SELECT * (2)FROM * (3)ORDERBY * (4)WHERE * (5)* # * (6)* # * (7)ORERBY * (8)*#* ]

Die anzuwendende Verarbeitungsfunktion für den an fünfter Stelle im RTN-Bausteinen „Ebenen" eingesetzten RTN-Baustein „#" ist die Verarbeitungsfunktion „MIN" ergänzt um die Begrenzung der Anzahl der Elemente seiner Verarbeitungs-Ausgangsmenge auf 5000, also jene 5000 Elemente, deren Wert C zu den 5000 kleinsten Werten der diesem fünften eingesetzten RTN-Baustein „#" zugewiesenen Verarbeitungs-Eingangsmenge, also der

Verarbeitungs-Ausgangsmenge vierter Stelle eingesetzten RTN-Bausteins „WHERE". Gleiches Schema gilt für die in den RTN-Baustein „Ebenen" eingesetzten Positionen (6) und

(8).

Eine Umschichtung der RTN-Bausteine ist zwingend erforderlich, da der erste eingesetzte RTN-Baustein „SELECT", welcher die gewünschten Felder aller Elemente seiner Eingangsmenge zurückliefert und ausgibt, an letzter Stelle dieses RTN-Bausteins „Ebenen" ausgeführt werden soll. Ebenso ist der zweite eingesetzte RTN-Baustein „FROM" an erster Stelle in seinem direkt übergeordneten RTN-Baustein „Ebenen" einzusetzen, da dieser RTN-Baustein „FROM" die zu verwendende Datenmenge oder Datenmengen als erste Verarbeitungs-Eingangsmenge für den RTN-Baustein „Ebenen" - und somit die Verarbeitungs-Eingangsmenge für den nach durchgeführter Umordnung zweiten in diesem RTN-Baustein „Ebenen" eingesetzten RTN- Baustein - definiert.

Weiters hat für die Verarbeitungsfunktionen „WHERE", „MIN" und „MAX" eine vorhergehende Sortierung keinen Einfluss auf das Ergebnis deren Verarbeitungsfunktionen, weshalb die Sortierungen jeweils nach diesen RTN-Bausteinen ausgeführt werden können. Die Ausführung der Sortierung nach den RTN-Bausteinen „WHERE", „MIN" und „MAX", welche jeweils die Elemente ihrer Verarbeitungs-Eingangsmenge verringern, bringt dadurch einen Geschwindigkeitsgewinn, dass die gewünschte Sortierung nun auf eine vorher verkleinerte Verarbeitungs-Eingangsmenge angewandt wird.

Eine Umordnung der aufeinander folgenden im RTN-Baustein „Ebenen" eingesetzten RTN- Bausteine (4)WHERE*, welcher die Verarbeitungsfunktion „WHERE" ausführt, und (5)*#*, die Verarbeitungsfunktion „MIN" ausführt, ist nicht gestattet, das diese Umordnung zu anderen Verarbeitungs- Ausgangsmengen führen kann.

Dies soll wie folgt verdeutlich werden: WHERE B MIN C # 5000

Ausgehend von der verwendeten Verarbeitungs-Eingangsmenge werden all jene Datensätze, für die das nicht näher definierte Kriterium WHERE B zutrifft, in die Verarbeitungs-Ausgangsmenge gestellt. Somit wird diese Verarbeitungs-

Ausgangsmenge der Verarbeitungsfunktion „WHERE" als Verarbeitungs- Eingangsmenge für die Verarbeitungsfunktion „MIN C # 5000" herangezogen, welche als Verarbeitungs-Ausgangsmenge - sofern zumindest 5000 Elemente in der Verarbeitungs-Eingangsmenge vorhanden sind - jene 5000 Elemente, welche in Bezug auf die gesamten Elemente der Verarbeitungs-Eingangsmenge zu die nicht näher definierten kleinsten Werte C aufweisen. MIN C # 5000 WHERE B

In diesem Fall wird als Verarbeitungs-Ausgangsmenge das Ergebnis der ersten anzuwendenden Verarbeitungsfunktion „MIN C # 5000" für die entsprechende Verarbeitmgs-Eingangsmenge geliefert und diese Verarbeitungs-Ausgangsmenge wird als Verarbeitungs-Eingangsmenge für die Verarbeitungsfunktion „WHERE B" herangezogen.

Durch diese Darstellung ist das Unterbinden der Umordnung zwischen den Verarbeitungsfunktion „WHERE" und „MIN C # 5000" nahegelegt.

Die Verarbeitungsfunktion „FIRST" hingegen ist, wie in der Beschreibung für diesen RTN- Baustein gezeigt, von einer vorher definierten Sortierung abhängig, weshalb das ORDERBY an der zweiten im RTN-Baustein „Ebenen" eingesetzten Position nicht vor diese sechste eingesetzte Position „FIRST" vorgereiht werden kann.

Eine umgeordnete, optimierte Reihenfolge der eingesetzten RTN-Bausteine für das gegebene Beispiel 25, welche ein der angegebenen Syntax identes Ergebnis liefert, lautet daher wie folgt:

[ (I)FROM * (2)WHERE * (3)* # * (4)ORDERBY * (5)* # * (5)* # * (6)ORERBY * (7)SELECT * ]

Die im Statement angegebnen definierten Verarbeitungsfunktionen werden daher in dieser neuen, schnelleren Reihenfolge ausgeführt:

[ FROM X

WHERE B MIN C # 5000 ORDERBY A

FIRST D # 1000 MAX F # 100

ORDERBY E SELECT *

Um eine derartige Umordnung in diesem und allen weiteren formulierbaren Fällen zu erreichen, ist die Einführung einer Umordnungsgewichtung, welche jeweils nach Beenden eines eingesetzten RTN-Bausteins zum Tragen kommt, notwendig, wobei diese Umordnungsgewichtung je RTN-Baustein nach folgendem Verfahren gesetzt wird:

Es werden sechs Umordnungsgewichtungsgruppen mit jeweils zugeordneter Verfahrenslogik definiert und jedem der angegebenen RTN-Bausteine wird eine Umordnungsgewichtung dieser sechs Umordnungsgewichtungsgruppen zugewiesen.

Um für jeden RTN-Baustein eine entsprechende Umordnungsgewichtung zu erhalten, werden

- eine erste Umordnungsgewichtungsgruppe, welche einen als kleinsten definierten

Wert zugewiesen bekommt, beispielsweise den Wert 0, eine zweite Umordnungsgewichtungsgruppe, welche einen als zweit-kleinsten definierten Wert zugewiesen bekommt, beispielsweise den Wert 1, eine dritte Umordnungsgewichtungsgruppe, welche einen als dritt-größten definierten Wert zugewiesen bekommt, beispielsweise den Wert 249,

- eine vierte Umordnungsgewichtungsgruppe, welche einen als zweit-größten definierten Wert zugewiesen bekommt, beispielsweise den Wert 250, eine fünfte Umordnungsgewichtungsgruppe, welche einen als größten definierten Wert zugewiesen bekommt, beispielsweise den Wert 251, und - eine sechste Umordnungsgewichtungsgruppe, welche einen variablen Wert, der größer als der Wert der zweiten Umordnungsgewichtungsgruppe und kleiner als der Wert der dritten Umordnungsgewichtungsgruppe ist, beispielsweise Werte zwischen 2 und 248,

festgelegt.

Jene RTN-Bausteine, welche in einem direkt übergeordneten RTN-Baustein benachbart eingesetzt sind und nicht umgeordnet werden sollen, erhalten einen jeweils gleichen Umordnungsgewichtungs-Wert der sechsten Umordnungsgewichtungsgruppe. Hiermit kann sichergestellt werden, dass bei gleichem übergeordneten RTN-Baustein die Reihenfolge von beispielsweise eingesetzten RTN-Bausteinen WHERE und MIN bei aufeinander treffen nicht verändert wird.

Jene RTN-Bausteine mit einer Umordnungsgewichtung der sechsten Umordnungsgewichtungsgruppe, welche in der Reihenfolge vor RTN-Bausteine der sechsten Umordnungsgewichtungsgruppe im selben direkt übergeordneten RTN-Baustein vorgereiht werden sollen, erhalten eine höhere Umordnungsgewichtung als die diesem RTN-Baustein nachzureihenden RTN-Bausteine.

Somit kann sich definiert werden, dass bei gleichem übergeordneten RTN-Baustein die Reihenfolge von beispielsweise eingesetzten RTN-Bausteinen ORDERBY und WHERE bei aufeinander treffen im Sinne der Optimierung der folgenden Abarbeitung vertauscht wird.

Jene RTN-Bausteine, die für die verlangte Verarbeitungsreihenfolge keinesfalls vor andere RTN-Bausteine im direkt übergeordneten RTN-Baustein gereiht werden können und vor die nur beliebig nachfolgende RTN-Bausteine der vierten Umordnungsgewichtungsgruppe gereiht werden können, bekommen den Umordnungsgewichtungswert der dritten Umordnungsgewichtungsgruppe zugewiesen.

Durch diese Definition wird festgelegt, dass bei gleichem übergeordneten RTN-Baustein die Reihenfolge ORDERBY A WHERE B FIRST C FROM D MAX D genau so umgeordnet wird, dass der RTN-Baustein FROM an die erste Position in diesem übergeordneten RTN-Baustein gesetzt wird, dieser ersten Position FROM der RTN-Baustein WHERE folgt und der RTN-Baustein FIRST, für welchen die vorhergehende Sortierung relevant ist, nach dem RTN-Baustein ORDERBY, also an die vorletzte Position gesetzt wird und die nunmehr letzte Position, also der RTN-Baustein MAX, nicht mehr vor diesem RTN- Baustein FIRST geschoben wird.

Jene RTN-Bausteine, welche in demselben übergeordneten RTN-Baustein eingesetzt sind und aufgrund einer verlangen Verarbeitungsreihenfolge jedenfalls vor alle RTN-Bausteine außer vor jene vorgereihten RTN-Bausteine mit der höchsten Umordnungsgewichtung der fünften Umordnungsgewichtungsgruppe, vorgereiht werden sollen, bekommen den Umordnungsgewichtungswert der vierten Umordnungsgewichtungsgruppe zugewiesen.

Diese vierte Umordnungsgewichtungsgruppe legt so zum Beispiel fest, dass der RTN- Baustein FROM, welcher die Verarbeitungs-Eingangsmenge für seinen übergeordneten RTN- Baustein beschreibt, vor alle anderen RTN-Bausteine wie z.B. WHERE, MIN, ORDERBY, FIRST usw. gereiht und somit unabhängig von seiner vorher im übergeordneten RTN- Bausteinen belegten Position an die erste Position desselben übergeordneten RTN-Bausteins gesetzt wird.

Um jene Fälle abzubilden, in welchen in einem übergeordneten RTN-Baustein eingesetzte RTN-Bausteine nur so lange umgeordnet - also anderen bereits eingesetzten RTN-Bausteinen vorgereiht - werden sollen, bis in diesem übergeordneten RTN-Baustein eine Entscheidungsposition erreicht wird, welche ein Schlüsselwort vorschreibt, werden diesen betroffenen Schlüsselwort-Entscheidungspositionen im jeweils übergeordneten RTN-Baustein der Umordnungsgewichtungswert der fünften Umordnungsgewichtungsgruppe zugeordnet und diese Schlüsselwort-Entscheidungspositionen im Sinne des Verfahrens der Umordnung gleich wie bereits eingesetzte RTN-Bausteine in diesem übergeordneten RTN-Baustein behandelt.

Um die Notwendigkeit dieser fünften Umschichtungsgewichtungsgruppe zu erläutern, soll folgendes einfaches Beispiel mit einem übergeordneten RTN-Baustein IF (I)* THEN (2)* ELSE (3) * END IF und in diesen drei direkt eingesetzte RTN-Bausteine mit insgesamt zwei unterschiedlichen Umordnungsgewichtungen dienen:

IF H)WHEREA THEN (I)FROMB ELSE O)FROMC END IF

Das Ergebnis dieses übergeordneten RTN-Bausteins IF-THEN-ELSE-END IF ist eine Verarbeitungs-Ausgangsmenge, welche in Abhängigkeit des nicht näher definierten Kriteriums WHERE A entweder die Elemente der Datenmenge B oder die Elemente der Datenmenge C enthält. Es ist also nicht zulässig, die Reihenfolge der in diesem RTN- Baustein IF-THEN-ELSE-END IF eingesetzten RTN-Bausteine zu verändern, da das vorher angegebene und daher als erstes zu berücksichtigende Kriterium WHERE A fundamental ausschlaggebend für die Verarbeitungs-Ausgangsmenge für diesen übergeordneten RTN- Baustein IF-THEN-ELSE-END IF ist.

Der RTN-Baustein FROM, welcher immer an erster Stelle in einem ihn übergeordneten RTN- Baustein stehen soll, bekommt den Umordnungsgewichtungswert der vierten Umordnungsgewichtungsgruppe, also beispielsweise den Umordnungsgewichtungswert 250 zugewiesen.

Der RTN-Baustein WHERE, welcher dem RTN-Baustein FROM nachgereiht werden soll, bekommt einen Umordnungsgewichtungswert der sechsten Umordnungsgewichtungsgruppe zugewiesen, beispielsweise den Umordnungsgewichtungswert 200.

Die Schlüsselwort-Entscheidungsposition IF, THEN, END und IF des übergeordneten RTN- Bausteins bekommen den Umordnungsgewichtungswert der fünften Umordnungsgewichtungsgruppe zugewiesen, so zum Beispiel 251.

Durch diese Vergabe der Umordnungsgewichtungswerte ist sichergestellt, dass in diesem Beispiel sowie in allen ähnlichen Fällen keine Umordnung der eingesetzten RTN-Bausteine vorgenommen wird.

Aufgrund der Möglichkeit, die rekursive RTN-Baustein-Einsetzposition als Entscheidungspositionen in RTN-Bausteinen zu verlangen, können die in einen übergeordneten RTN-Baustein eingesetzten RTN-Bausteine eine Auswirkung auf die Umordnungsgewichtung des ihnen übergeordneten RTN-Bausteins haben, womit für diesen übergeordneten RTN-Baustein wiederum eine andere Umordnungsgewichtung für die Umreihung in seinem wiederum übergeordneten RTN-Baustein zum Tragen kommt.

So gilt für alle RTN-Bausteine, welche eine Umordnungsgewichtung ungleich der Umordnungsgewichtung der ersten Umordnungsgewichtungsgruppe haben, dass diese betroffenen RTN-Bausteine als ihre endgültige Umordnungsgewichtung genau dann die Umordnungsordnungsgewichtung der dritten Umordnungsgewichtungsgruppe zugewiesen bekommen, wenn zumindest einer der direkt oder rekursiv verschachtelt in diese als übergeordnete RTN-Bausteine eingesetzten RTN-Bausteine eine Umordnungsgewichtung der dritten Umordnungsgewichtungsgruppe haben.

Im Falle (I)ORDERBY (2)WHERE A (3)WHERE B werden jene Elemente der Verarbeitungs-Eingangsmenge, für welche das nicht näher definierte Kriterium (3)WHERE B zutrifft, als Verarbeitungs-Ausgangsmenge geliefert. Diese gelieferten Elemente werden im RTN-Baustein (I)ORDERBY als Boolean-Ergebnis der ebenfalls nicht näher definierten Verarbeitungsfunktion (I)WHERE A sortiert. Der RTN-Baustein Q)WHERE B wird daher dem RTN-Baustein (I)ORDERBY vorgereiht, trotzdem in diesem RTN-Baustein (I)ORDERBY der RTN-Baustein (2)WHERE mit einer höheren Umordnungsgewichtung als derselbe eingesetzt ist.

Ebenfalls gelten für alle RTN-Bausteine, welche nach dem Umwandlungsschritt der zweiten Gattungsgruppe zugeordnet werden sowie für alle RTN-Bausteine der ersten Gattungsgruppe, von welchen der endgültige Umordnungsgewichtungswert ausschließlich dem höchsten aller gegebenenfalls in diese RTN-Bausteine der ersten Gattungsgruppe direkt oder rekursiv eingesetzten RTN-Bausteine entsprechen soll, dass diese betroffenen RTN-Bausteine den Umordnungsgewichtungswert der zweiten Umordnungsgewichtungsgruppe zugewiesen bekommen und der für -die weitere Verarbeitung endgültige Umordnungsgewichtungswert dieser RTN-Bausteine dem höchsten Umordnungsgewichtungswert der diesen jeweils direkt oder rekursiv eingesetzten RTN-Bausteinen entspricht.

Um das zu verdeutlichen, wird folgende Verschachtelung angenommen:

ORDERBY A ( MAX B ) FIRST WHERE C # 100

Sowohl dem RTN-Baustein der ersten Gattungsgruppe ( ) als auch dem RTN-Baustein der zweiten Gattungsgruppe # werden der Umordnungsgewichtungswert der zweiten Umordnungsgewichtungsgruppe zugewiesen, und beide dieser RTN-Bausteine erhalten die jeweils höchste Umordnungsgewichtung der direkt oder rekursiv in diese RTN-Bausteine eingesetzten RTN-Bausteine.

In den fett markierten RTN-B austein () mit dem Umordnungsgewichtungswert der zweiten Umordnungsgewichtungsgruppe, beispielsweise 1, ist der RTN-Baustein MAX mit seinem Umordnungsgewichtungswert der sechsten Umordnungsgewichtungsgruppe, beispielsweise 200, und in diesen ist wiederum der Tabellen-RTN-Baustein B eingesetzt, welcher den Umordnungsgewichtungswert der zweiten Umordnungsgewichtungsgruppe, beispielsweise 1, zugeordnet hat.

Somit ergibt sich für den besagten RTN-Baustein () als endgültige Umordnungsgewichtung die größte Umordnungsgewichtung aller in diesen RTN-Baustein direkt oder rekursiv eingesetzten RTN-Bausteine, im konkreten Fall also die Umordnungsgewichtung 200 des RTN-Bausteins MAX.

Gleich wird mit dem ebenso fett markierten RTN-Baustein # verfahren, welcher anstatt seiner anfänglichen Umordnungsgewichtung der zweiten Umordnungsgewichtungsgruppe als seine endgültige Umordnungsgewichtung im Konkreten die Umordnungsgewichtung der dritten Umordnungsgewichtungsgruppe des in ihm eingesetzten RTN-Bausteins FIRST zugewiesen bekommt.

Somit treffen für die auszuführende Umordnung folgende in einem gleichen übergeordneten

RTN-Baustein eingesetzten RTN-Bausteine mit entsprechender endgültiger Umordnungsgewichtung aufeinander:

ORDERBY anfängliche Umordnungsgewichtung: 50 endgültige Umordnungsgewichtung: 50

( ) anfängliche Umordnungsgewichtung: 1 endgültige Umordnungsgewichtung: 200

# anfängliche Umordnungsgewichtung: 1 endgültige Umordnungsgewichtung: 249

Durch diese endgültigen Umordnungsgewichtungen ergibt sich also folgende neue und vor allem optierte Verschachtelung im übergeordneten RTN-Baustein:

( MAX B ) ORDERBY A FIRST WHERE C # 100 Jenen RTN-Bausteinen, für welche die Umordnungsgewichtungen der innerhalb derselben direkt oder rekursiv eingesetzten RTN-Bausteine nach dem beschrieben Verfahren gelten, für welche aber die eigene Umordnungsgewichtung in Bezug auf die ihnen übergeordneten RTN- Bausteine keinen Einfluss auf deren endgültige Umordnungsgewichtung haben soll, wird der Umordnungsgewichtungswert der ersten Umordnungsgewichtungsgruppe zugeordnet.

Ein RTN-Baustein mit einem Umordnungsgewichtungswert der ersten Umordnungsgewichtungsgruppe ist zum Beispiel der oben beschriebene RTN-Baustein Ebenen wie folgendes abstraktes einfaches Beispiel zeigen soll:

ORDERBY A MIN [ORDERBY B WHERE C FIRST D]

Innerhalb des RTN-Bausteins Ebenen wird eine verfahrensgemäße Umordnung aufgrund der Umordnungsgewichtungswerte der in diesen RTN-Baustein Ebenen eingesetzten RTN- Bausteine insofern vorgenommen, als dass der RTN-Baustein WHERE vor den RTN-Baustein ORDERBY gereiht wird.

Trotzdem in diesem RTN-Baustein Ebenen ein in diesen direkt eingesetzter RTN-Baustein, nämlich der RTN-Baustein FIRST, die Umordnungsgewichtung der dritten Umordnungsgewichtungsgruppe zugewiesen hat, wird diese Umordnungsgewichtung nicht an den RTN-Baustein Ebenen als dessen endgültige Gewichtung weitergegeben. So kann der dem RTN-Bausteinen Ebenen übergeordnete RTN-Baustein MCV vor den RTN-Baustein ORDERBY gereiht werden, wodurch sich folgende neue Ordnung der RTN-Bausteine ergibt:

MiN [WHERE C ORDERBY B FIRST D] ORDERBY A

Um gegebenenfalls noch detailreichere Umordnungen oder Umschichtungen innerhalb der ausgehend von einem analysierten Statement vorläufigen Verschachtelung der RTN- Bausteine vorzunehmen, können weitere Umordnungsgewichtungsgruppen eingeführt und diesen eine entsprechend abweichende Verfahrenslogik zur Umordnung oder Umschichtung zugewiesen werden.

So können unter anderen bestimmten Entscheidungspositionen in Entscheidungsgraphen von RTN-Bausteinen eine feste Umordnungsgewichtung für dieselben zugeordnet werden, welche dann die verfahrensmäßig erhaltene Umordnungsgewichtung für einen an diese Entscheidungsposition eingesetzten RTN-Baustein mit der festgelegten Umordnungsgewichtung dieser Entscheidungsposition übersteuert. Ebenso können Entscheidungspositionen, welche ein Schlüsselwort vorschreiben, eine andere Umordnungsgewichtung als die Umordnungsgewichtung der fünften Umordnungsgewichtungsgruppe zugeordnet werden zuordnen, um diese Schlüsselwort- Entscheidungsposition in bestimmten Fällen mit anderen Entscheidungspositionen desselben Entscheidungsgraphen zu vertauschen. Derartige hiformationen werden an den betroffenen Entscheidungspositionen der RTN-Syntax der jeweiligen RTN-Bausteine als verarbeitungsrelevante RTN-Baustein-Information der vierten, fünften oder sechsten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe gekennzeichnet.

Aufgrund dieser Ausführungen über die abarbeitungsoptimierenden Umordnungsgewichtungsgruppen ist zu ersehen, dass in zumindest einigen Fällen die endgültige Umordnungsgewichtung als verarbeitungsrelevante RTN-Baustein-Införmation erst nach Durchlaufen eines an einer * -Entscheidungsposition eingesetzten RTN-Bausteins erhalten werden kann und diese Umordnungsgewichtung daher der dritten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe zuzuordnen ist.

Der Vorteil dieser Umordnungsgewichtung ergibt sich dadurch, dass sämtliche angebaren Fälle automatisch die bestmögliche Umordnung der verschachtelten RTN-Bausteine vornehmen, welche ebenfalls gilt, wenn neue RTN-Bausteine der Gesamtheit der RTN- Bausteine hinzugefügt werden. Beispielsweise verarbeitungsrelevante RTN-Baustein-Informationen der vierten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe werden folgende zwei RTN- Bausteine angeführt:

Um für RTN-Bausteine eine unabhängige verarbeitungsrelevante RTN-B austein-Information der vierten verarbeitungsrelevante RTN-Baustein-hiformationsgruppe an zumindest einer bestimmten Entscheidungsposition seines inneren, gerichteten Entscheidungsgraphen festzulegen, kann beispielsweise das Zeichen ° zur Einleitung gefolgt von einem Namen für diese Verarbeitungsfunktion und danach wiederum das Zeichen ° zur Beendigung dieses Namens dienen.

Um für RTN-Bausteine eine unabhängige verarbeitungsrelevante RTN-Baustein-Information der fünften verarbeitungsrelevante RTN-Baustein-Informationsgruppe an zumindest einer bestimmten Entscheidungsposition seines inneren, gerichteten Entscheidungsgraphen festzulegen, kann beispielsweise die reservierte Zeichenfolge °doVA° zur Kennzeichnung dienen.

RTN-Syntax mit Kennzeichnung der verarbeitungsrelevanten RTN-Baustein-Informationen der vierten und fünften verarbeitungsrelevanten RTN-Baustein-Informationsgruppe an den betroffenen Entscheidungspositionen für die RTN-Bausteine „WHERE" und „MIN"/„MAX":

RTN-Baustein „WHERE":

RTN-Syntax: „WHERE" °where° * °doVA°

RTN-Baustein „MIN" / „MAX":

RTN-Syntax: („MIN" °min° | „MAX" °max° ) * °doVA°

Die Deutung für den RTN-Baustein „MIN'V'MAX" ergibt:

Wenn die Entscheidungsposition, welche das Schlüsselwort „MIN" verlangt, erfolgreich verglichen wird, wird als auszuführende Verarbeitungsfunktion die Verarbeitungsfunktion °min ° initialisiert. Wird hingegen im gleichen RTN-Baustein die Entscheidungsposition, welche das Schlüsselwort „MAX" verlangt, erfolgreich vergleichen, so wird als auszuführende Verarbeitungsfunktion die Verarbeitungsfunktion °max° initialisiert. Die Anwendung der jeweils initialisierten Verarbeitungsfunktionen auf die endgültige Verarbeitungs-Eingangsmenge dieses RTN-Bausteins wird aber erst nach erfolgreichem Durchlaufen des an der * -Entscheidungsposition eingesetzten RTN-Bausteins ausgeführt, da an dieser Entscheidungsposition die reservierte Zeichenfolge °do VA ° angegeben ist.

Für den RTN-Baustein WHERE kann aufgrund der eindeutig für diesen RTN-Baustein anzuwendenden Verarbeitungsfunktion auch die Initialisierung und Ausführung der Verarbeitungsfunktion an der gleichen, letzten Entscheidungsposition stehen, also könnte die RTN-Syntax des RTN-Bausteins WHERE auch wie folgt ausschauen:

RTN-Syntax: „WHERE" * °where° °doVA°

Sollen in einem RTN-Baustein zumindest zwei von einander unabhängige Verarbeitungsfunktionen an unterschiedlichen Entscheidungspositionen initialisiert und/oder durchgeführt werden, so kann dem einleitenden Zeichen ° eine Zeichenfolge (x) nachstehen, durch welche den Zusammenhang von verarbeitungsrelevanten RTN-B austein-Infbrmationen der vierten, fünften und sechsten verarbeitungsrelevantes RTN-Baustein-Informationsgruppe im gleichen Entscheidungsgraphen eines RTN-Bausteins festlegt.

Das wird beispielsweise anhand des RTN-Bausteins GroupBy gezeigt:

RTN-Syntax: "GROUPBY" °(l)GroupBy° * °(l)doVA° [":" (1) * [(*1)] "END" "GROUPBY" °(2)EndGroupBy° °(2)doVA°]

Dieser RTN-Baustein GroupBy kann - wie oben bereits für diesen RTN-Baustein beschrieben - je nach erreichten Entscheidungspositionen seines Entscheidungsgraphs die Initialisierung und spätere Anwendung einer oder zweier Verarbeitungsfunktionen mit jeweils unterschiedlichen Verarbeitungs-Eingangsmengen für diese Verarbeitungsfunktionen im gleichen RTN-Baustein GroupBy verlangen. Um eine zuvor aufgrund einer erreichten Entscheidungsposition initialisierte Verarbeitungsfunktion eines RTN-Bausteins um einen oder mehrere Parameter genau dann zu erweitern, wenn nachfolgend erreichte Entscheidungspositionen das vorschreiben, kann dem einleitenden Zeichen ° das Zeichen + nachgestellt werden.

Sollen einer gegebenenfalls bereits erweiterten Verarbeitungsfunktion eines RTN-Bausteins als zusätzliche Parameter die Verarbeitungs-Ausgangsmengen eines oder mehrerer diesem RTN-Baustein direkt untergeordneten RTN-Bausteine mitgegeben werden, so kann das durch ein in der Zeichenfolge °...° an entsprechender Stelle der Verarbeitungsfunktion eingefügtes reserviertes Zeichen ~ gefolgt von einem Namen für die zu verwendende Verarbeitungs- Ausgangsmenge eines direkt eingesetzten RTN-Bausteins und abschließend wiederum dem Zeichen ~ dargestellt werden. Jene * -Entscheidungspositionen im gleichen RTN-Baustein, welche die Verarbeitungs-Ausgangsmenge als Parameter übergeben sollen, werden mit den Zeichen °~ und einem dieser Verarbeitungs-Ausgangsmenge zugeordneten Namen, welcher wiederum durch die Zeichen ~° beendet wird, gekennzeichnet.

Ein diese Definition betreffender und oben bereits beschriebener RTN-Baustein ist der RTN- Baustein „NEXT" / „PREV":

RTN-Syntax: ("NEXT" °Next° | "PREV" °Prev°) ["(" [("=" °+ = ~Paraml~° | ">" "=" °+ >= ~Paraml~° | "<" "=" °+ <= ~Paraml~°)] * °~Paraml~° ")"] °doVA°

Als Verarbeitungsfunktion dieses RTN-Bausteins wird je nach erreichter Entscheidungsposition entweder die Verarbeitungsfunktion °Next° oder die Verarbeitungsfunktion °Prev° initialisiert. Wird aufgrund des zu analysierenden Statements eine der optionalen Entscheidungspositionen „=", „>=" oder „<=" erreicht, wird durch die Zeichenfolge °+ festgelegt, dass die vorher initialisierte Verarbeitungsfunktion dieses RTN- Bausteins, also °Next° oder °Prev°, um die entsprechenden Parameter „=", „<=" oder „>=" und der Verarbeitungs-Ausgangsmenge jener *-Entscheidungsposition, an welcher die Zeichenfolge °~Paraml~° zu finden ist, erweitert. Die mit gegebenenfalls um Parameter erweiterte, initialisierte Verarbeitungsfunktion wird nach erfolgreichem Vergleich mit der letzten Entscheidungsposition ausgeführt. In Falle einer erforderlichen Neu-Initialisierung anstatt der vorher gezeigten Erweiterung der bereits initialisierten Verarbeitungsfunktion um Parameter ist das reservierte Zeichen +, welches dem einleitenden Zeichen ° folgt, wegzulassen.

Wird in einem RTN-Baustein ausgehend von einem zu analysierenden Statement eine gleiche Entscheidungsposition aufgrund einer angewandten Sprung-Entscheidungsposition mehrfach betreten, kann festgelegt werden, dass eine dieser mehrfach erreichten Entscheidungsposition zugeordneten Verarbeitungsinformation, welche auch Parameter sein können, als Parameter um die Anzahl der erfolgreichen Vergleiche mit dieser Entscheidungsposition erweitert wird.

Es wird festgelegt, daß für jene Fälle, in denen in einem gleichen Entscheidungsgraphen eine gleiche Entscheidungsposition aufgrund einer Sprungfunktion in Kombination mit einer zu analysierenden Syntax mehrfach erreicht wird, welche Entscheidungsposition eine verarbeitungsrelevante RTN-Baustein-Information der vierten verarbeitungsrelevanten RTN- Baustein-Informationsgruppe enthält, die aus diesen zugeordneten verarbeitungsrelevanten RTN-Baustein-Informationen erhaltenen Parameter den zur Anwendung zu bringenden Parameter mit diesen Parametern erweitern und bei Erreichen einer Entscheidungsposition mit einer zugehörigen verarbeitungsrelevanten RTN-Baustein-Information der fünften verarbeitungsrelevanten RTN-Baustein-Informationsgruppe der solcherart ergänzte Parameter zur Anwendung gebracht wird.

Ein Beispiel für diese Regelung ist der bereits beschriebene RTN-Baustein „Verarbeitung- SameParents" mit folgender RTN-Syntax:

RTN-Syntax: „/" „/" (1) * °~Paraml~° [(*1)] „\" „\" °MergeToOneSet ~Paraml~° °doVA°

Dieser RTN-Baustein, welcher für alle der an seiner beliebig oft wiederholbaren *- Entscheidungsposition direkt eingesetzten RTN-Bausteine seine gleiche Verarbeitungs- Eingangsmenge weitergibt und diese nachher zu einer Verarbeitungs- Ausgangsmenge zusammenfasst, initialisiert alle Verarbeitungs-Ausgangsmengen der an seinen *- Entscheidungsposition direkt eingesetzten RTN-Bausteine als Paramter-Liste ~Paraml~. Die bei der letzten erreichten Entscheidungsposition dieses RTN-Bausteins „Verarbeitung- SameParents" zu initialisierende und auch an dieser letzten Entscheidungsposition auszuführende Verarbeitungsfunktion °MergeToOneSet° wird auf alle gesammelten Verarbeitungs-Ausgangsmengen der Parameter-Liste ~Paraml~ angewandt.

Es soll nun anhand des RTN-Bausteins „Mengenelemente begrenzend" ein RTN-Baustein gezeigt werden, welcher eine verarbeitungsrelevante RTN-Baustein-Information der sechsten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe enthält.

RTN-Syntax: °getVAOfChild° * °~Paraml~° "#" °LimitResults -Pararnl- ~Param2~° [("="

O l —O I 11^,11 M--.ll O l >₌O I M^M It — MO l <=° I »<-" 11^.110 1 O°Λ^"| f"%" °-f- %°1 *

⁰~Param2~° °doVA°

Um festzulegen, dass ein übergeordneter RTN-Baustein, welcher zumindest eine *- Entscheidungsposition in seinem inneren, gerichteten Entscheidungsgraphen aufweist, die Anwendung der Verarbeitungsfunktion einer der direkt an einer *-Entscheidungsposition eingesetzten und dadurch untergeordneten RTN-Bausteine in diesem untergeordneten RTN- Baustein unterbindet und die Verarbeitungsfunktion als zusätzlichen Parameter für die Verarbeitungsfunktion des übergeordneten RTN-Bausteins verwendet, wird die reservierte Zeichenfolge °getVAOfChild° vor der oder den betroffenen *-Entscheidungspositionen im übergeordneten RTN-Bausteins gesetzt.

Enthält einer der direkt untergeordneten RTN-Bausteine wiederum zumindest eine *- Entscheidungsposition, kann auch im übergeordneten RTN-Baustein, welcher vor einer *- Position die reservierte Zeichenfolge °getVAOfChild° enthält, mittels einer weiteren oder erweiterten reservierten Zeichenfolge aus Gründen der Optimierbarkeit festgelegt werden, dass alle rekursiv an dieser einen * -Entscheidungsposition eingesetzten RTN-Bausteine ihre Verarbeitungsfunktion nicht in ihren RTN-Bausteinen ausführen sondern als zusätzliche Parameter-Kette der Verarbeitungsfunktion des übergeordneten RTN-Bausteins geliefert werden. Unabhängig von dieser erweiterten Zeichenfolge kann eine Optimierung der fertig gestellten Verschachtelung nach Analyse eines angegebenen Statements automatisch erkannt und durchgeführt werden.

Anhand dieser gezeigten RTN-Syntax des RTN-Bausteins „Mengenelemente begrenzend" wird zuerst gezeigt, dass die an der zweiten - nach dem Umwandlungsschritt und Zuordnung zur zweiten Gattungsgruppe nunmehr ersten - Entscheidungsposition für diesen RTN- Baustein initialisierte Verarbeitungsfunktion °LimitResults° je nach weiteren, im konkreten Fall optional erreichbaren Entscheidspositionen um Paramter erweitert werden kann.

So können sich beispielsweise durch die optional erreichbaren Entscheidungspositionen in diesem RTN-Baustein „Mengenelemente begrenzend" folgende um Parameter erweiterte Verarbeitungsfunktionen für ergeben:

°LimitResults -Paraml- ~Param2~ <=° °LimitResults -Paraml- ~Param2~ >=° °LimitResults -Paraml- ~Param2- = %°

In jedem Fall wird aber aufgrund der Angabe der reservierten Zeichenfolge °getVAOfChild° die Ausführung der Verarbeitungsfunktion in dem an der ersten * -Entscheidungsposition eingesetzten RTN-Baustein unterbunden und der in diesem RTN-Baustein „Mengenelemente begrenzend" verlangten Verarbeirungsfunktion auf die Verarbeitungs-Eingangsmenge desselben als Parameter hinzugefügt.

Nachfolgendes einfaches Beispiel soll dies verdeutlichen:

WHERE A # <= 100

Der im übergeordneten RTN-Baustein „Mengenelemente begrenzend", welcher durch das Schlüsselwort „#" gekennzeichnet wird, an erster * -Entscheidungsposition eingesetzte RTN- Baustein ist der RTN-Baustein „WHERE" mit der ihm zugeordneten Verarbeitungsfunktion ⁰WHERE⁰, der an der zweiten * -Entscheidungsposition desselben übergeordneten RTN- Bausteins „Mengenelemente begrenzend" eingesetzte RTN-Baustein ist der RTN-Baustein „Zahl" ohne zugeordneter Verarbeitungsfunktion.

Da der RTN-Baustein „WHERE" aufgrund des angegebenen Statements direkt an der ersten * -Entscheidungsposition im RTN-Baustein „Mengenelemente begrenzend" eingesetzt ist, vor welcher ersten * -Entscheidungsposition aus Optimierungsgründen die reservierte

Zeichenfolge °getVAOfChild° angegeben ist, wird die Ausführung der Verarbeitungsfunktion

°WHERE° des RTN-Baustein „WHERE" in demselben unterbunden. Stattdessen wird die verlangte Verarbeitungsfunktion °WHERE° dem übergeordneten RTN-Baustein „Mengenelemente begrenzend" als zusätzlicher Parameter für seine Verarbeitungsfunktion angefügt.

Dadurch ergibt sich für das angegebene Statement folgende auszuführende Verarbeitungsfunktion im RTN-Baustein „Mengenelemente begrenzend":

°LimitResults °where „A"° <= „100" °

wobei das Schlüsselwort „A" für ein nicht näher definiertes Kriterium je Element der Verarbeitungs-Eingangsmenge des RTN-Bausteins „A" im Sinne einer weiteren rekursiven Verschachtelung steht.

Damit wird verhindert, -dass die Verarbeitungsfunktion ⁰WHERE⁰ nicht auf die gesamte Verarbeitungs-Eingangsmenge des ihm zugeordneten RTN-Bausteins „WHERE" ausgeführt wird und nachfolgend die Verarbeitungsfunktion °LimitResults° mit dem Parameter <= 100 des RTN-Bausteins „Mengenelemente begrenzend" auf die gesamte Verarbeitungs- Ausgangsmenge des RTN-Bausteins „WHERE", welche zugleich die neue Verarbeitungs- Eingangsmenge dieses RTN-Bausteins „Mengenelemente begrenzend" ist, angewandt wird.

Vielmehr wird die Verarbeitungsfunktion ⁰WHERE⁰ so lange ausgeführt, bis genau 100 Elemente in der Verarbeitungs-Eingangsmenge des RTN-Bausteins „Mengenelemente begrenzend" mit zutreffendem, nicht näher definierten Kriterium „A" gefunden werden. Ein weiteres Beispiel soll eine mögliche Optimierung im Falle einer komplexeren Verschachtelung zeigen:

// WHERE A MIN B # 500 W # 100

In diesem Beispiel wird für den RTN-Baustein „WHERE" und den um die Parameter „MIN" und „500" erweiterten RTN-Baustein „Mengenelemente begrenzend" aufgrund des beiden direkt übergeordneten, oben beschrieben, RTN-Bausteins „Verarbeitung-SameParents" die gleiche Verarbeitungs-Eingangsmenge des ihnen übergeordneten RTN-Bausteins geliefert. Die Verarbeitungs- Ausgangsmenge des RTN-Bausteins „Verarbeitung-SameParents" liefert definitionsgemäß in seiner Verarbeitungs- Ausgangsmenge jene Elemente seiner Verarbeitungs-Eingangsmenge, welche in zumindest einer der beiden an seinen *- Entscheidungspositionen direkt eingesetzten RTN-Bausteine in deren Verarbeitungs- Ausgangsmengen geliefert werden.

Der RTN-Baustein „Verarbeitung-SameParents" ist aber wiederum in den RTN-Baustein „Mengenelemente begrenzend" eingesetzt, welcher in seiner Verarbeitungs-Ausgangsrnenge die im Konkreten ersten 100 Elemente seiner Verarbeitungs-Eingangsmenge liefert.

Eine Optimierung ergibt sich also, wenn der RTN-Baustein „WHERE" mit seinem nicht näher definierten Kriterium „A" auf die Ausgabe der ersten 100 Elemente mit zutreffendem Kriterium „A" begrenzt- wird, und die Verarbeitungsfunktion „MIN B # 500" nur. dann angewandt wird, sofern die Verarbeitungs-Ausgangsmenge des benachbarten RTN-Bausteins „WHERE" weniger als 100 Elemente liefert. Die Verarbeitungsfunktion „MIN # 500" liefert, beispielsweise durch grobe Vorsortierung der Elemente seiner Verarbeitungs-Eingangsmenge, welche zumindest teilweise bei der Ausführung der Verarbeitungsfunktion „WHERE" initialisiert werden kann, nicht die 500 Elemente, für welche „MIN B" zutrifft, sondern optimalerweise genau die Anzahl der zutreffenden Elemente, die die Verarbeitungsfunktion „WHERE" für die zu erreichende Anzahl 100 im höchst-übergeordneten RTN-Baustein zu wenig liefert. Es wird angemerkt, dass eine Vielzahl aller RTN-Bausteine aus der Gesamtheit der angegebenen RTN-Bausteine zumindest eine verarbeitungsrelevanten RTN-Baustein- Information der vierten, fünften und/oder sechsten verarbeitungsrelevanten RTN-Baustein- Informationsgruppe enthalten.

Ein RTN-Baustein, für welchen keine verarbeitungsrelevanten RTN-Baustein-Information der vierten, fünften oder sechsten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe definiert ist, ist der RTN-Baustein RTN-Baustein „RTN-Baustein-Zusammenfassend" (Klammer), da dieser RTN-Baustein einzig Einfluss auf die Gewichtung und die damit verbundene hierarchischen Umschichtung der Verschachtelung hat.

Die Generierung eines sich durch diese, mit gegebenenfalls mit Parametern versehenen, initialisierten und anzuwendenden Verarbeitungsfunktionen zu einem optimalen Zugriffsplan kann weiterfolgenden Analyseschritten durchgeführt.

So kann zum Beispiel bei im gleichen übergeordneten RTN-Baustein aufeinander folgenden RTN-Bausteinen ORDERBY und FIRST festgelegt werden, dass die Verarbeitungsfunktion ORBERBY anfänglich mittels Quick-Sort grob sortiert und nur solange eine exakte Sortierung ein Teilbereichen vorgenommen wird, bis die von FIRST verlange Anzahl an Elementen gefunden wurde.

Im Sinne einer weiteren Verarbeitung kann es von Vorteil sein, dass in jenen Fällen, in denen ein RTN-Baustein zweiter Gattungsgruppe direkt in einem selben RTN-Baustein zweiter Gattungsgruppe an einer seiner Entscheidungspositionen, welche eine rekursiven RTN- Baustein-Einsetzposition vorschreibt, eingesetzt wird und diese beiden verschachtelten RTN- Bausteine zweiter Gattungsgruppe die jeweils gleichen Verarbeitungsfunktionen vorschreiben, der übergeordnete RTN-Baustein zweiter Gattungsgruppe alle aufgrund einer zu analysierenden Syntax betretenen Entscheidungspositionen des in ihm eingesetzten gleichen RTN-Bausteins zweiter Gattungsgruppe an seine letzte Entscheidungsposition anhängt und somit der an der rekursiven RTN-Baustein-Einsetzposition vormals eingesetzte gleiche RTN-Baustein zweiter Gattungsgruppe ohne Informationsverlust aus der endgültigen Verschachtelung entfernt wird.

Folgendes einfache Beispiel soll dies verdeutlichen:

Ein angegebenes Statement MIN A + B + C + D, welches nach Einlesen in die RTN- Bausteine folgende vorläufige Verschachtelung ergibt:

MIN * * + *

A

* -I- *

B

H* -1- % C

D

wird daher wie folgt neu verschachtelt:

MIN *

* -I- * -|- * -I- *

A B C D

Dadurch kann eine detailreichere weitere Analyse und insbesondere eine bessere Optimierbarkeit der Statements erreicht werden.

Ein angegebenes Statement MIN A + B - C, welches nach Einlesen in die RTN-Bausteine folgende vorläufige Verschachtelung ergibt: MIN *

* + *

A

* -

B

C

In diesem Beispiel ist der RTN-Baustein zweiter Gattungsgruppe „Strich-Rechen" an einer *- Entscheidungsposition direkt in den gleichen RTN-Baustein „Strich-Rechen" eingesetzt, wobei diese beiden gleichen RTN-Bausteine in der Verschachtelung aber unterschiedliche Verarbeitungsfunktionen vorschreiben. Deswegen ist diese vorläufige Verschachtelung nicht zu verändern und somit der endgültigen Verschachtelung gleichzusetzen.

Um die sich durch das zu verarbeitende Statement ergebende Verschachtelung der RTN- Bausteine und insbesondere deren verarbeitungsrelavente RTN-Baustein-Informationen in verarbeitungsfähig aufbereiteter Form zur Verfugung zu haben, wird festgelegt, dass erflndungsgemäße Liste eingeführt wird, wobei den inneren, gerichteten Entscheidungsgraphen der RTN-Bausteine, wie sie sich nach dem Umwandlungsschritt ergeben, anhand einer zu analysierenden Syntax verfahrensmäßig gefolgt wird und jede betretene Entscheidungsposition in diese Liste derart eingetragen wird, dass für jeden an einer rekursiven RTN-Baustein-Einsetzposition eines RTN-Bausteins identifizierten RTN-Baustein ein weiteres Element dieser Liste hinzugefügt wird, welches diesen identifizierten RTN-Baustein enthält und - und alle in einem inneren, gerichteten Entscheidungsgraphen betretenen

Entscheidungspositionen dem Element der Liste RTN-Baustein, welches den zugehörigen RTN-Baustein enthält, als Felder dieses Elementes in der betretenen Reihenfolge anfügt werden und

- sowohl die hierarchische Verschachtelung der Elemente unter Berücksichtigung beispielsweise vorhandener, vorläufiger Gewichtungen der identifizierten RTN-

Bausteine, welche ebenfalls den Elementen der Liste als Information zugeordnet sind, entsprechend neu definiert wird und die in den Elementen der Liste als Felder gespeicherten Entscheidungspositionen anhand beispielsweise einer Umordnungsgewichtung je Entscheidungsposition umgeordnet werden.

Um ein vorhandenes Statement in eine solche Liste einzulesen, wird dieser Liste für jeden identifizierten RTN-Baustein in der aufgefundenen Reihenfolge ein weiteres Element angefügt und jede Entscheidungsposition des Entscheidungsgraphen des RTN-Bausteins wird in der betretenen Reihenfolge als Feld des jeweils aktuellen Elementes der Liste angelegt.

Es wird nun eine solche Liste für folgendes Statement gezeigt:

Beispiel 26:

Zu analysierende Syntax: [ WHERE ( A = B ) MIN C # 100]

1. Element der Liste: RTN-Baustein „Ebenen" 2. Element der Liste: RTN-Baustein „WHERE"

3. Element der Liste: RTN-Baustein „Klammer"

4. Element der Liste: RTN-Baustein „Tabellen"

5. Element der Liste: RTN-Baustein „Vergleich"

6. Element der Liste: RTN-Baustein „Tabellen" 7. Element der Liste: RTN-Baustein „MIN / MAX"

8. Element der Liste: RTN-Baustein „Tabellen"

9. Element der Liste: . RTN-Baustein „Mengenelemente begrenzend"

10. Element der Liste: RTN-Baustein „Zahl"

Diesen Elementen der Liste werden nun je aktuellen RTN-Baustein sämtliche Schlüsselworte des zu analysierenden Statement in der aufgefundenen Reihenfolge zugeordnet und verwendete * -Entscheidungspositionen werden ebenfalls an den betroffenen Stellen der übergeordneten RTN-Bausteine vermerkt:

1. Element: „[„ * * „]"

2. Element: „WHERE" *

3. Element: „(" * „)"

4. Element: „A" 5. Element: =" *

6. Element: ,3"

7. Element: „MIN" *

8. Element: „C"

9. Element: „#" *

10. Element: „100"

Um die tatsächliche Verschachtelung der RTN-Bausteine für die weitere Verarbeitung als verarbeitungsfähige Information bestmöglich zur Verfügung zu haben, bekommt jedes der einen RTN-Baustein enthaltenden Elemente der Liste ein Element aus derselben als Parent zugeordnet und jene Felder dieser Elemente, welche alle betretenen Entscheidungspositionen der aufgefundenen RTN-Bausteine enthalten, die eine * -Entscheidungsposition aufrufen, zu jeweils diesem *-Entscheidungspositions-Feld ein Element aus derselben Liste als Child zugeordnet wird, wobei

- genau jenes Element einem Element als vorläufigen Parent zugeordnet wird, welches dieses direkt untergeordnete Element in Abhängigkeit der zu analysierenden Syntax und entsprechendem Folgen der des sich nach dem Umwandlungsschritt ergebenden Entscheidungsgraphen der jeweils identifizierten RTN-Bausteine, aufruft, und - jene Elemente an *-Entscheidungspositions-Feldern als vorläufige Children definiert werden, welche an diesen *-Entscheidungspositions-Feldera als RTN-Bausteine eingesetzt werden.

Die sich durch das obige Beispiel 26 ergebende Liste wird nun mit den entsprechenden vorläufigen Parent- und Child-Informationen ergänzt:

1. Element: „[„ Child: 1 Child:7 „]" vorläufiges Parent-Element: 0

2. Element: „WHERE" Child:3 vorläufiges Parent-Element: 1

3. Element: „(" Child:4 „)" vorläufiges Parent-Element: 2

4. Element: ,A" vorläufiges Parent-Element: 3

5. Element: „=" Child:6 vorläufiges Parent-Element: 4

6. Element: vorläufiges Parent-Element: 5

7. Element: „MIN" Child: 8 vorläufiges Parent-Element: 1 8. Element: C" vorläufiges Parent-Element: 7

9. Element: „#" Child:10 vorläufiges Parent-Element: 8

10. Element: „100" vorläufiges Parent-Element: 9

Um eine endgültig gewünschte Verschachtelung der RTN-Bausteine in dieser Liste zu erreichen, werden folgende Schritte genau dann ausgeführt, wenn ein RTN-Baustein der zweiten Gattungsgruppe als ein Element in der Liste angefügt wird:

Auffinden des diesem Element in der Verschachtelung endgültig überzuordnenden Elements, beispielsweise vermittels der oben beschriebenen ersten und zweiten

Gewichtung

- Hinzufügen eines neuen *-Entscheidungspositions-Feldes bei dem zuletzt angefügten Element der Liste, welches den RTN-Baustein der zweiten Gattungsgruppe enthält, an der ersten Stelle und diesem angefügten *-Entscheidungspositions-Feld jenes Element der Liste als Child zuordnen, welches vorher der Parent dieses genau Elements war, und

- das Child des letzten Feldes des aufgrund der endgültigen Verschachtelung dieses RTN-Bausteins zweiter Gattungsgruppe direkt überzuordnenden RTN-Bausteins auf das Element der Liste, welches diesen RTN-Baustein zweiter Gattungsgruppe enthält, ausbessern, und den vormaligen Parent des diesen zuletzt angefügten Element der Liste genau dieses letzte angefügte Element der Liste als Parent zuweisen.

Die endgültige Liste für dieses Beispiel 26 schaut aus wie folgt:

1. Element: „[„ Child: 1 Child:9 „]" endgültiges Parent-Element: 0

2. Element: „WHERE" Child:3 endgültiges Parent-Element: 1

3. Element: „(" Child:5 „)" endgültiges Parent-Element: 2

4. Element: ,Λ" endgültiges Parent-Element: 5

5. Element: Child:4 „=" Child:6 endgültiges Parent-Element: 3

6. Element: 13" endgültiges Parent-Element: 5

7. Element: „MIN" Child:8 endgültiges Parent-Element: 9 8. Element: C" endgültiges Parent-Element: 7

9. Element: Child:7 „#" Child:10 endgültiges Parent-Element: 1

10. Element: „100" endgültiges Parent-Element: 9

Dadurch steht eine Liste für die weitere Verarbeitung zur Verfügung, welche die Elemente und somit die RTN-Bausteine vor Anwendung des Umwandlungsschrittes mit den ihnen zugeordneten verarbeitungsrelevanten RTN-Baustein-Informationen in der durch die Gewichtungen gewünschten endgültigen Verschachtelung sowie der innerhalb der RTN- Bausteine durch die Umordnungsgewichtung optimierten Reihenfolge der Entscheidungspositionen enthält.

Die Generierung der endgültigen Verschachtelung der Liste soll durch dieses einfache Beispiel ohne Angebe konkreter Gewichtungen je RTN-Baustein und somit je Element der Liste nochmals gezeigt werden:

Beispiel 27: Zu analysierende Syntax: WHERE A+B = C

Die ersten beiden Schritte identifizieren die beiden RTN-Bausteine „WHERE" und „A" und tragen sie entsprechend in der Liste ein:

1. Element: WHERE Child:2

2.Element: A vorläufiges Parent-Element: 1

Als nächstes wird das Schlüsselwort „+" angetroffen, welches in der zweiten Verweisuntergruppe gefunden wird und somit einen RTN-Baustein der zweiten Gattungsgruppe darstellt.

1. Element: „WHERE" Child:2 2.Element: „A" vorläufiges Parent-Element: 1 3. Element: ..+" vorläufiges Parent-Element: 2

Da es bei dem 3. Element der Liste um einen RTN-Baustein der zweiten Gattungsgruppe handelt, wird als endgültig überzuordnender RTN-Baustein der RTN-Baustein „WHERE" identifiziert. Deswegen wird dem 3. Element einen neues Feld an erster Stelle angeführt und die Parent- und Child-Informationen werden wie folgt neu festgelegt:

1. Element: „WHERE" Child:3 2.Element: „A" vorläufiges Parent-Element: 3 3. Element: Child:2 „+" vorläufiges Parent-Element: 1

Das nächste Schlüsselwort „B" des Statements ist stellt einen RTN-Baustein der ersten Gattungsgruppe dar und wird als drittes Feld des dritten Elements mit entsprechender Parent- und Child-Vergabe angefügt.

1. Element: „WHERE" Child:3

2.Element: „A" vorläufiges Parent-Element:

3. Element: Child:2 „+" Child:4 vorläufiges Parent-Element: 1

4.Element: „B" vorläufiges Parent-Element: 3

Als nächstes wird das Schlüsselwort „=" verarbeitet und als RTN-Baustein zweiter Gattungsgruppe identifiziert. Aufgrund der Gewichtungen der RTN-Bausteine und somit der Elemente der Liste wird festgestellt, dass das den RTN-Baustein „=" enthaltende Element dem den RTN-Baustein „WHERE" enthaltenden RTN-Baustein Element direkt untergeordnet werden soll. Vor der Entsprechenden Anfügung eines ersten Feldes für das 5. Element und neuen Parent- und Child-Vergabe sieht die Liste aus wie folgt:

1. Element: „WHERE" Child:3

2.Element: „A" vorläufiges Parent-Element: 3 3. Element: Child:2 „+" Child:4 vorläufiges Parent-Element: 1

4.Element: „B" vorläufiges Parent-Element: 3

5. Element: „=" vorläufiges Parent-Element: 4 Nachdem die Umschichtung erfolgt ist, ergibt sich folgende Liste für Beispiel 27:

1. Element: „WHERE" Child:5 2. Element: „A" vorläufiges Parent-Element: 3. Element: Child:2 „+" Child:4 vorläufiges Parent-Element: 5 4.Element: „B" vorläufiges Parent-Element: 3 5. Element: Child:3 vorläufiges Parent-Element: 1

Nachdem das letzte Schlüsselwort des Statements, welches einen RTN-Baustein der ersten Gattungsgruppe identifiziert, verarbeitet wurde, ergibt sich folgende, für die weitere Verarbeitung aufbereitete Liste:

1. Element: „WHERE" Child:5 2.Element: „A" endgültiges Parent-Element: 3. Element: Child:2 „+" Child:4 endgültiges Parent-Element: 5 4.Element: ,3" endgültiges Parent-Element: 3

5. Element: Child:3 , =" Child:6 endgültiges Parent-Element: 1

6. Element: C" endgültiges Parent-Element: 5

Somit ist gezeigt, dass eine derartige Liste mit wenigen Suchschritten zum Auffinden und dem Austausch weniger Zahlen in einer Liste generiert wird.

Abschließend sei nochmals erwähnt, dass eine auf dem erfindungsgemäßen Verfahren beruhende Anfragesprache vielfach mehr Verschachtelungs-Konstellationen ermöglicht, als es eine herkömmliche Anfragesprache ermöglicht, die lediglich auf einem Gesamt-RTN basiert. Diese Verschachtelungs-Konstellationen, welche nach Analyse eines Statements als hierarchischer Baum für die weitere Verarbeitung vorhanden sind, erlauben einen wesentlich höheren Freiheitsgrad in der Formulierung von Anfrage- Statements und somit auch die Einführung einer Vielzahl neuer Verarbeitungsfunktionen, welche innerhalb einer Anfragesprache, welcher nur ein gesamtes RTN zugrunde liegt, nicht in dieser Komplexität definiert werden können. Des weiteren können RTN-Bausteine je nach übergeordneten, untergeordneten oder benachbarten RTN-Bausteinen eine unterschiedliche Funktion ausüben, die einen Anwender bei der Formulierung eines Statements in diesen Fällen jeweils als intuitiv logisch erscheint, also eine kontext-abhängige Deutung der Verarbeitungsfunktionen in einer deskriptiven Anfragesprache. Somit können aufgrund von verwendbaren RTN- Bausteinen unterschiedliche, für sich alleine betrachtet einander widersprechende Logiken in einem System ausgedrückt und verarbeitet werden. Durch die Möglichkeit, formal zu formulierende Fragestellungen ohne die sich durch das Vorhandensein nur eines gesamten RTN 's ergebenden Einschränkungen bzw. Umschreibungen zu formulieren, ist die Angabe eines zu verarbeitenden Statements für einen Anwender wesentlich leichter und auch die Optimierung eines Zugriffsplans auf eine gegebene relationale Datenstruktur ist besser möglich.

Es sei bemerkt, dass RTN-Bausteine eine Erweiterung von RTN' s darstellen, in einer logischen hierarch die Wurzel von Gesamt-RTN's bilden. Funktionen und Verarbeitungsfunktionen sind in dieser logischen Hierarchie wesentlich tiefer angesiedelt, jegliche Funktionen und auch defnierbare Objekte werden aufgrund eines zugrunde liegenden RTN' s zugelassen und algorithmisch gedeutet.

RTN-Bausteine werden, durch sich selbst abgeschlossen, Verarbeitungsbereiche und Verarbeitungsreihenfolgen von SQL und ähnlichen Anfragesprachen hingegen, welche durch ein Gesamt-RTN definiert sind, werden entweder durch das Antreffen eines reservierten Schlüsselwortes, das dem nächsten Befehl entspricht oder durch das Ende des zu analysierenden Statements abgeschlossen. Dies zeigt nochmals die Unabhängigkeit von erfindungsgemäßen RTN-Bausteinen zueinander.

Ebenso ist in einem aus RTN-Bausteinen bestehenden System die Einführung neuer RTN- Bausteine einfacher möglich, da neu definierte RTN-Bausteine keinen Einfluss auf bereits vorhandene RTN-Bausteine nehmen und aufgrund der verarbeitungsrelevanten RTN- Baustein-Informationen in jedem Fall das erwünschte Ergebnis für eine jeweils gegebene Verschachtelung liefern.

Abschließend werden die oben beschriebenen RTN-Bausteine, welche eine beispielhafte Gesamtheit an RTN-Bausteinen darstellen, folgendermaßen gezeigt:

Es werden die RTN-Bausteine sowohl vor dem Umwandlungsschritt (Tabelle 1) in die zwei Gattungsgruppen als auch nach diesem Umwandlungsschritt (Tabelle 2) gezeigt. Für die gezeigten RTN-Bausteine sind die RTN-Syntax, die Umordnungsgewichtung (UOrd. Gew.), sowie die erste und die zweite Gewichtung (172. Gew.) angegeben, ansonsten sind aber aus Gründen der Übersicht keine weiteren verarbeitungsrelevanten RTN-Baustein-Informationen angegeben.

Tabelle 3 zeigt die Elemente der RTN-Baustein-unabhängigen Verweisgruppe, wie sie sich auf Basis der in Tabelle 2 nach dem Umwandlungsschritt gezeigten RTN-Bausteine ergeben. Die Elemente der ersten Verweisuntergruppe sind mit X-Group gekennzeichnet und enthalten eine Entscheidungspositions-Nummer zwischen 1 und 254. Die Elemente der zweiten Verweisuntergruppe sind mit Y-Group gekennzeichnet und enthalten eine Entscheidungspositions-Nummer zwischen 255 und 322. Diese Zahlenangaben können im Rahmen der Erfindung natürlich abgeändert werden. Je Element der dieser Verweisgruppe mit ihren beiden Verweisuntergruppen ist ein Verweis auf eine Zeile in der Tabelle 4 gegeben, in welcher der zugehörige Rest-Entscheidungsgraph dieses Elements zu finden ist. Die mit den Entscheidungspositions-Nummern 246, 247 und 248 versehenen LongStringValues können für eine Liste an Schlüsselworten stehen, welche alle dem jeweils gleichen RTN-Baustein zugehörig sind, so z.B. der RTN-Baustein „Tabelle", welcher alle vorhandenen Tabellen- und gespeicherten Anfragenamen enthält (Entscheidungspositions- Nummer 246), der RTN-Baustein „Konstanten" (Entscheidungspositions-Nummer 247) und der RTN-Baustein „TabellenFeld" (Entscheidungspositions-Nummer 248)

Tabelle 4 stellt die Rest-Entscheidungsgraphen für die Elemente der Verweisgruppe aus Tabelle 3 dar, wobei diese Rest-Entscheidungsgraphen als Array gespeichert sind und je nach erfolgreichem bzw. erfolglosem Vergleich mit einer Entscheidungsposition auf die Zeile JUMP-TRUE bzw. JUMP-FALSE springen. In jenen Fällen, in denen keine Jump-False-Zeile vorhanden ist, ist die angegebene Entscheidungsposition eine Position, die erfolgreich verglichen werden muss.

Eine Erstellung der einem angegebenen Anfragestatement zugehörigen RTN-Baustein- Verschachtelung erfolgt, indem Schlüsselworten oder Gruppen von Schlüsselworten in der durch das Statement vorgegebenen Reihenfolge verarbeitungsrelevante Eigenschaften zugeordnet werden, wie es vorhergehend in der Beschreibung dargestellt ist.

In der Beschreibung wird der „rekursive RTN-Baustein-Auswahlschritt" als „Auswahlschritt" abgekürzt. Weiters wird „Verarbeitungsinformations-Enginefunktions-Zuordnungsmenge" in der Beschreibung als Zuordnungstabelle abgekürzt.

Ein Zusammenhang zwischen der RTN-Baustein-Verschachtelung und einer dieser Verschachtelung zugrunde liegenden Statements wird nun kurz festgestellt:

Für die dem angegebenen Anfragestatement zugehörige RTN-Baustein-Verschachtelung werden RTN-Bausteine ausgewählt, wobei in jedem RTN-Baustein genau ein Entscheidungspfad aus seinem Entscheidungsgraphen ausgewählt und für diesen RTN- Baustein in der jeweiligen Verschachtelungsposition als verwendeter Entscheidungspfad herangezogen wird.

Alle Schlüsselworte eines Statements finden sich dadurch in ihrer vorliegenden Reihenfolge in der zugehörigen RTN-Baustein-Verschachtelung wieder, dass an der ersten Entscheidungsposition des endgültig äußersten RTN-Bausteins beginnend allen Entscheidungspositionen desselben gefolgt wird, wobei an jeden erreichten Entscheidungspositionen, welche eine rekursive RTN-Baustein-Einsetzposition enthalten, den konkret eingesetzten RTN-Baustein aufrufen und durchlaufen. Es wird die nächste Entscheidungsposition im übergeordneten RTN-Baustein genau dann betreten, wenn der eingesetzte RTN-Baustein - und alle gegebenenfalls in diesen eingesetzten RTN-Bausteine - bis zum Ende durchlaufen wurde. Es ist zu beachten, dass für einen eingesetzten RTN- Baustein an einer rekursiven RTN-B austein-Einsetzposition (* -Entscheidungsposition) jeweils ein konkreter Entscheidungspfad aus dem Entscheidungsgraphen desselben ausgewählt wird. Wird den RTN-Bausteinen und innerhalb dieser den Entscheidungspositionen in einer endgültigen RTN-B austein-Verschachtelung nach diesem Prinzip gefolgt, enthält jede Entscheidungsposition entweder ein Schlüsselwort oder eine rekursive RTN-Baustein-Einsetzposition, in welche ein konkreter RTN-Baustein mit einem konkreten Entscheidungspfad eingesetzt ist. Werden nur die Schlüsselwort- Entscheidungspositionen ausgewählt, so enthält die erste erreichte Schlüsselwort- Entscheidungsposition das erste Schlüsselwort des zugehörigen Statements, die zweite Schlüsselwort-Entscheidungsposition das zweite Schlüsselwort des Statements usw. Dieser Zusammenhand der Schlüsselworte mit den Schlüsselwort-Entscheidungspositionen gilt unabhängig von Verschachtelungen im Sinne von über- und untergeordneten RTN- Bausteinen.

Ebenso wird nochmals angemerkt, dass es für ein Statement mitunter eine Vielzahl an möglichen Verschachtelungen gibt, wobei eine endgültige Verschachtelung mittels verarbeitungsrelevanten RTN-Baustein-Informationen wie die beschriebene erste und zweite Gewichtung je RTN-Baustein ermittelt wird. Die weiteren Schritte zur Zugriffsplan- Erstellung basieren auf dieser endgültigen Verschachtelung. Dem Fachmann steht es frei, in welcher Form die Verschachtelung für die weitere Verarbeitung gespeichert wird. In der Beschreibung wurde vorhergehend eine mögliche Variante gezeigt.

Um die Konsistenz des System der RTN-Bausteine zu wahren, wird festgelegt, dass in einer RTN-Baustein- Verschachtelung immer einen RTN-Baustein als äußerster RTN-Baustein vorhanden ist, wobei dieser RTN-Baustein ein RTN-Baustein der ersten oder der zweiten Gattungsgruppe sein kann.

Die Erstellung des Zugriffsplans für eine zugehörige Datenstruktur erfolgt vorzugsweise, indem ein angegebenes Anfragestatement in eine ihm zugehörige RTN-Baustein- Verschachtelung transformiert, und in einem nachfolgenden Schritt diese RTN-Baustein- Verschachtelung im Zugriffsplan-Erstellungsschritt durchlaufen wird. Die zugehörige RTN- Baustein- Verschachtelung wird so durchlaufen, dass bei der ersten Entscheidungsposition des äußersten RTN-Bausteins begonnen und dem ausgewählten Entscheidungspfad bis zum Ende gefolgt wird, wobei an jenen Entscheidungspositionen, welche eine rekursive RTN-Baustein- Einsetzposition und somit einen Verweis auf einen an dieser Entscheidungsposition eingesetzten RTN-Baustein enthalten, diesen eingesetzten RTN-Baustein zuerst vollständig durchlaufen, und erst danach diese Entscheidungsposition als durchlaufen gilt und somit der dieser Entscheidungsposition nachfolgenden Entscheidungsposition gefolgt wird.

Nachfolgend wird schrittweise eine weitere Implementierungsvariante gezeigt, wie die verarbeitungsrelevanten RTN-Baustein-Informationen der vierten, fünften und sechsten verarbeitungsrelevanten RTN-B austein-Informationsgruppen anders implementiert werden können, um somit auch eine kontextsensitive Syntaxanalyse zu ermöglichen. Unter kontextsensitive Syntaxanalyse wird in der Beschreibung verstanden, dass aus der Verschachtelung und der Reihenfolge der RTN-Bausteine, wie sie sich aus der Analyse eines Statements ergeben, eine mitunter unterschiedliche Anfragedeutung und somit ein unterschiedlicher Zugriffsplan erzeugt wird. Somit wird nicht einem RTN-Baustein bzw. einzelnen erreichten Entscheidungspositionen eines aufgerufenen und durchlaufenen RTN- Bausteins die jeweils gleiche Verarbeitungsfunktion zugeordnet, sondern vielmehr ergibt sich eine voreinstellbare Deutung unter Berücksichtigung einer konkreten Verschachtelung von RTN-Bausteinen. Mittels dieser Implementierungsvariante wird es möglich, eine Anfragesprache zu konstruieren, welche sich nach dem Anwender richtet, und nicht - wie derzeit insbesondere bei Anfragesprachen und Sprachen der ersten, zweiten und dritten Generation üblich - eine Sprache zur Verfügung zu haben, in welcher der Anwender durch eine konkrete Anordnung von Befehlen ein Problem dadurch beschreibt, dass bei Durchlaufen dieser Befehle eine Problemstellung beschrieben wird. Somit kann ein Anwender nicht nur die zugrunde liegende Sprache einfach nach seinen Vorstellungen und seiner Logik erweitern, sondern es können auch Verschachtelungen gedeutet werden, welche im ersten Analyseschritt für einen Algorithmus nicht deutbar sind. Dies geschieht gegebenenfalls unter vordefinierbarer, automatischer Nachfrage bei einem Anwender.

Die verarbeitungsrelevanten RTN-Baustein-Informationen der vierten, fünften und sechsten verarbeitungsrelevanten RTN-Baustein-Informationsgruppe werden nachfolgend als Entscheidungspositions- Verarbeitungsinformationen bezeichnet. Im Voreinstellungsschritt, in welchem die RTN-Bausteine definiert und zu der Gesamtheit der vorhandenen RTN-Baustein zusammengefasst werden, wird als Teilschritt desselben der Voreinstellungs-Entscheidungspositions-Verarbeitungsinformations-Definitionsschritt angewandt.

In diesem Voreinstellungs-Entscheidungspositions-Verarbeitungsinformations-

Definitionsschritt werden von einem Anwender von einander unabhängige Entscheidungspositions- Verarbeitungsinformationen erstellt, von welchen nachfolgend der Übersicht wegen nur ein unvollständiger Ausschnitt gezeigt wird:

Beispielsweise Entscheidungspositions-Verarbeitungsinformationen der ersten Entscheidungspositions- Verarbeitungsinformationsgruppe:

Init Table InitJTableField Init_Wert

SetOperation_FROM

SetOperation_WHERE

SetOperation_MIN SetOperation MAX

SetOperation_ORDERBY Extend_OrderByDesc ForChildrenJJseSameEingangsMenge ForChildren_UseSetOfPrev*

ForChildren Union

GiveResultToParent

MergeSets_Union MergeSets_UnionAll MergeSets_Intersect MergeSets_Exlude

SetztePunkt SetzteBesistrich

CaIc + Calc_- Calc_* Calc_/ Calc_\ Calc_Mod

Bool_And Bool_Or Bool_XOr BoolJMot

Bool_MustNext Bool MustPrev

Compare= Compare< Compare> Compare>= Compare<= Compareo

Die hier gezeigten Entscheidungspositions-Verarbeitungsinformationen gehören der ersten

Entscheidungspositions- Verarbeitungsinformationsgruppe an, was bedeutet, dass ihnen im

Voreinstellungs-Entscheidungspositions-Verarbeitungsinformations-Zuordnungsschritt als Teilschritt des Voreinstellungsschrittes jeweils zumindest eine, gegebenenfalls durch Auswertung Statement-kontextsensitiver Parameter auch mehrere Verarbeitungsfunktion(en) zugeordnet werden. Wird eine andere Entscheidungspositions- Verarbeitungsinformation der ersten Entscheidungspositions-Verarbeitungsinformationsgruppe in einem gleichen Entscheidungsgraphen an späterer Stelle erreicht, wird diese Entscheidungspositions- Verarbeitungsinformation, unabhängig davon, ob sie bereits ausgewertet wurde oder nicht, ab dieser und somit den nachfolgenden Entscheidungspositionen von dieser nachfolgenden Entscheidungspositions-Verarbeitungsinformation überlagert. Wird eine

Entscheidungspositions-Verarbeitungsinformation der zweiten Entscheidungspositions- Verarbeitungsinformationsgruppe im gleichen Entscheidungsgraphen erreicht, wird diese Entscheidungspositions-Verarbeitungsinformation der zweiten Entscheidungspositions- Verarbeitungsinformationsgruppe als Entscheidungspositions-Verarbeitungsinformations- Erweiterung für die jeweils aktuelle Entscheidungspositions-Verarbeitungsinformation der ersten Entscheidungspositions-Verarbeitungsinformationsgruppe berücksichtigt.

Beispielsweise Entscheidungspositions-Verarbeitungsinformationen der zweiten Entscheidungspositions- Verarbeitungsinformationsgruppe:

Param_UnionAll Param_= Param_>= Param_<= Param_o

Die Kennzeichnung, dass eine Entscheidungspositions- Verarbeitungsinformation der zweiten Entscheidungspositions- Verarbeitungsinformationsgruppe zuzuordnen ist, kann wie gezeigt über die vorangestellte Zeichenfolge „Param_" erfolgen. Somit sind alle Entscheidungspositions- Verarbeitungsinformationen, welche nicht mit dieser Zeichenfolge „Param_" beginnen, eindeutig der ersten Entscheidungspositions- Verarbeitungsinformationsgruppe zuzuordnen.

Der Fachmann andere Kennzeichnungen für die eindeutige Zuordnung der Entscheidungspositions- Verarbeitungsinformationen zu der ersten bzw. zweiten Entscheidungspositions-Verarbeitungsinformationsgruppe wählen, beispielsweise kann jeder Entscheidungspositions-Verarbeitungsinformation ein eindeutiger Zahlenwert zugeordnet werden, wobei die Zahlenwerte der Entscheidungspositions-Verarbeitungsinformationen der ersten Entscheidungspositions-Verarbeitungsinformationsgruppe unter einen festgelegten, konstanten Zahlenwert Hegen und die Zahlenwerte der zweiten Entscheidungspositions- Verarbeitungsinformationsgruppe jeweils über diesen festgelegten, konstanten Zahlenwert liegen.

Die Verwendung von Zahlenwerten ist in der Praxis sehr empfehlenswert, insbesondere um die weitere Analyse und Zugriffsplangenerierung über schnelle Zahlenvergleiche anstatt über langsame Text-Vergleiche zu ermöglichen. In der Beschreibung wird aber aufgrund der erhöhten Übersicht rein mit Text-Werten gearbeitet. Ein Anwender kann mit einer

Eingabemaske Zahlenwerte und Textwerte gleichzeitig sehen, wodurch sowohl die hohe

Übersicht in der Voreinstellung als auch die hohe Geschwindigkeit bei einer Statementanalyse gewährleistet ist.

Diese Entscheidungspositions- Verarbeitungsinformationen können mit einer jeweils eindeutigen Nummer versehen werden. Nach der Angabe von zumindest einigen der jederzeit erweiterbaren Entscheidungspositions-Verarbeitungsinformationen wird der Voreinstellungs- Entscheidungspositions-Verarbeitungsinformations-Zuordnungsschritt als Teilschritt des Voreinstellungsschrittes vom Anwender ausgeführt, in welchem zumindest jeweils eine Entscheidungsposition von zumindest ein Teil der RTN-Baustein zumindest jeweils eine Entscheidungspositions- Verarbeitungsinformation zugewiesen bekommt.

Dies soll für einige der RTN-Bausteine aus der Gesamtheit der definierten RTN-Bausteine in der RTN-Schreibweise gezeigt werden, wobei innerhalb der Zeichen ° ° jeweils Entscheidungspositions-Verarbeitungsfunktionen für die vorhergehende

Entscheidungsposition angegeben werden.

Beispielsweise RTN-Bausteine der ersten Gattungsgruppe:

RTN-Baustein „Tabelle":

RTN-Syntax: Tabellenname ⁰MtJaUe⁰ RTN-Baustein „Tabellenfeld":

RTN-Syntax: Tabellenfeldname °Init_TableField°

RTN-Baustein „Variable":

RTN-Syntax: VariablerWert °Init_ Wert°

RTN-Baustein „Kartesisches Produkt": RTN-Syntax: „FROM" °SetOperation_FROM° *

RTN-Baustein „Zeilenauswählend":

RTN-Syntax: „WHERE" °SetOperation_WHERE° *

RTN-Baustein „Extremwert": RTN-Syntax: ( „MIN" °SetOperation_MIN° ~ „MAX" °SetOperation_MAX° ) *

RTN-Baustein „Mengen-Sortierung":

RTN-Syntax: „ORDERBY" °SetOperation_OrderBy° *

RTN-Baustein „Verarbeitung_SameParents":

RTN-Syntax: „/ „/" °ForChildrenJJseSameEingangsMenge° (1) * [(*1)] „\" „\" °ForChildrenJJnian°

RTN-Baustein „Ebenen": RTN-Syntax: "[" °ForChildren_UseSetOfPrev*° (1) * [(*1)] "]" °GiveResultToParent°

RTN-Baustein „Relativer Zeilenauswählender"

RTN-Syntax: ("MUSTNEXT" °Bool_MustNext° | "MUSTPREV" °Bool_MustPrev°) *

Beispielsweise RTN-Bausteine der zweiten Gattungsgruppe:

RTN-Baustein „Mengen-Zusammenführend": RTN-Syntax: * („UNION" „ALL" * °Mer geSets JJnionAll⁰ \ "UNION" °Mer geSets _Union° * I "INTERSECT" °Mer geSets _Intersect° * | "EXCLUDE" °Mer geSets _Exclude° *)

RTN-Baustein „Werte- Verkettung": RTN-Syntax: * „." °SetztePunkt° *

RTN-Baustein „Mengen-Element-Bildend": RTN-Syntax: * ,„" °SetzteBeistrich° *

RTN-Baustein „Strich-Rechen-Operationen": RTN-Syntax: * ("+" °Calc_+° | "-" ⁰CaIcJ) *

RTN-Baustein „Punkt-Rechen-Operationen" :

RTN-Syntax: * ("*" ⁰CaIcJ⁰ | "/" ⁰CaIcJ⁰ | "\" ⁰CaIcJ⁰ | "MOD" °Calc_Mod° ) *

RTN-Baustein „Bool-Kombi"

RTN-Syntax: * ("AND" °Bool_And° | "OR" °Bool_Or° | "XOR" °Bool_XOr° ) *

RTN-Baustein „Vergleich" RTN-Syntax: * ("=" °Compare=° \ "<" °Compare<° | ">" °Compare>° \ ">" "=" °Compare>=° \ ^«"<" "=" °Compare<=° | "<" ">" °Compare<>° ) *

Es wird angemerkt, dass die Entscheidungspositions-Verarbeitungsfunktionen in den RTN- Bausteinen gänzlich unabhängig von den verarbeitungsrelevanten RTN-Baustein- Informationen der RTN-Bausteine sind. So übt weder die Zuordnung der RTN-Bausteine zu der ersten bzw. zweiten Gattungsgruppe, noch die erste oder zweite Gewichtung der RTN- Bausteine noch sonst eine andere verarbeitungsrelevante RTN-Baustein-Information einen Einiluss auf die Verwendbarkeit der Entscheidungspositions-Verarbeitungsinformationen aus, noch schränken diese die Anwendbarkeit derselben ein.

Es wird anhand einiger RTN-Bausteine die prinzipielle Wirkungsweise der Entscheidungspositions-Verarbeitungsinformationen gezeigt: Der innere, gerichtete Entscheidungsgraph des RTN-B austeins Zeilenauswählend enthält einen Entscheidungsgraphen mit zwei Entscheidungspositionen. Bei Erreichen der Entscheidungsposition „Schlüsselwort WHERE" wird die Entscheidungspositions- Verarbeitungsinformation °SetOperation_ WHERE° für diesen RTN-Baustein festgelegt. Eine Auswertung dieser Entscheidungspositions-Verarbeitungsinformation

°SetOperation_WHERE° wird im später gezeigten Zugriffsplan-Erstellungsschritt vorgenommen, an dieser Stelle wird nur erwähnt, dass die Entscheidungspositions- Verarbeitungsinformation °SetOperation_WHERE° direkt an der Entscheidungsposition °SetOperation_WHERE° sowie nach dem erfolgreichem Einsetzen und Durchlaufen eines RTN-Bausteins aus der Gesamtheit der definierten RTN-Bausteine an der zweiten Entscheidungsposition „*" ausgewertet wird.

Im RTN-Baustein Mengen-Zusammenführend ist ersichtlich, dass bei Erreichen der Entscheidungsposition „Schlüsselwort UNION" aufgrund der nachfolgenden Entscheidungsposition eine jeweils andere Entscheidungspositions- Verarbeitungsinformation initialisiert wird: Wird nachfolgend die Entscheidungsposition „Schlüsselwort ALL" erreicht, wird die Entscheidungspositions Verarbeitungsinformation °MergeSets_UnionAll° initialisiert, ansonsten wird bei erfolgreichem Einsetzen und Durchlaufen eines RTN- Bausteins an der Entscheidungsposition „*" die Entscheidungspositions- Verarbeitungsinformation °Mer geSets _Union° initialisiert.

Gleichwertig ist es möglich, den RTN-Baustein Mengen-Zusammenführend in einer der beiden folgenden RTN-Syntax-Schreibweisen anzugeben:

RTN-Baustein „Mengen-Zusammenführend": (Alternative RTN-Syntax 1)

RTN-Syntax: * („UNION" °Mer geSets _Union° [„ALL" °MergeSets_UnioiL4//°] | ¹TNTERSECT" °Intersect° | "EXCLUDE" °Exclude°) *

RTN-Baustein „Mengen-Zusammenführend": (Alternative RTN-Syntax 2) RTN-Syntax: * („UNION" ° Mer geSets JJnion⁰ [„ALL" ^oParamJJnionAU°] * | 'TNTERSECT" °Intersect° * | "EXCLUDE" °Exclude° *) In der alternativen RTN- Syntax 1 wird automatisch festgelegt, dass bei Erreichen der Entscheidungsposition „Schlüsselwort UNION" die Entscheidungspositions- Verarbeitungsinformation Union gesammelt und somit initialisiert wird. Folgt aufgrund eines angegebenen Statements dieser Entscheidungsposition „Schlüsselwort UNION" die Entscheidungsposition „Schlüsselwort ALL", erkennt ein Algorithmus automatisch, dass es sich bei den beiden Entscheidungspositions-Verarbeitungsinformationen °MergeSets_Union° und °Mer geSets JJnionAll° um jeweils eine Entscheidungspositions- Verarbeitungsinformation der ersten Entscheidungspositions-

Verarbeitungsinformationsgruppe handelt. Dies bedeutet, dass die vorherig initialisierte Entscheidungspositions-Verarbeitungsinformation, im Konkreten die Entscheidungspositions- Verarbeirungsinformation °MergeSets_Union°, unabhängig davon, ob sie in der weiteren Analyse an dieser Entscheidungsposition berücksichtigt wird, ab der nächsten Entscheidungsposition mit der Entscheidungspositions-Verarbeitungsinformation °Mer geSets JJnionAir übersteuert wird, und diese Entscheidungspositions- Verarbeitungsinformation für die nachfolgende Verarbeitung ab dieser Entscheidungsposition herangezogen wird.

In der alternativen Schreibweise RTN-Syntax 2 wird automatisch festgestellt, dass bei Erreichen der Entscheidungsposition „Schlüsselwort UNION" die Entscheidungspositions- Verarbeitungsinformation Union gesammelt und somit initialisiert wird. Wird aufgrund eines zugrunde liegenden Statements nachfolgend die Entscheidungsposition „Schlüsselwort ALL" erreicht, wird automatisch erkannt, dass die Entscheidungsposrtions- Verarbeitungsinformation °ParamJUnionAH° eine Entscheidungspositions-

Verarbeitungsinformation der zweiten Entscheidungspositions- Verarbeitungsinformationsgruppe ist und somit diese Entscheidungspositions- Verarbeitungsinformation als Entscheidungspositions-Verarbeitungsinformations-

Erweiterung für die vorherig initialisierte Entscheidungspositions- Verarbeitungsinformation, im Konkreten für die Entscheidungspositions-Verarbeitungsinformation °Mer geSets JJnion⁰ verwendet wird.

Eine weitere Möglichkeit, den RTN-Baustein Mengen-Zusammenführend in einer anderen syntaktischen Form und gleichzeitig in einer anderen Sprache darzustellen, wird mittels folgender RTN-Syntax gezeigt: RTN-Baustein „Mengen-Zusammenführend (Veränderte syntaktische Form)" RTN-Syntax: („VEREINIGE" °MergeSetsJJnion° [„MIT" „DUPLIKATEN" °ParamJJnionAll°] | „ELEMENTÜBERSCHNEIDUNG" °Intersect° | "KEINE" „ELEMENTÜBERSCHNEIDUNG" °Exclude°) „:" *

Durch diesen zusätzlichen RTN-Baustein sind aufgrund der bereits definierten RTN- Bausteine folgende zwei gleichwertige Schreibweisen möglich, um die Elemente der Tabelle Archiv_2005 mit den Elementen der Tabelle Archiv_2006 und der Tabelle Archiv_2007 ohne Duplikatsbereinigung der Datensätze zu vermischen:

Erste Schreibweise:

Archiv_2005 UNION ALL Archiv_2006 UNION ALL Archiv_2007

Zweite, gleichwertige Schreibweise:

VEREINIGE MIT DUPLIKATEN : Archiv_2005 , Archiv_2006 , Archiv_2007

Beide Schreibweisen initialisieren trotz ihrer unterschiedlichen syntaktischen Schreibweise die jeweils gleiche Entscheidungspositions- Verarbeitungsinformation °MergeSets_ UnionAll°, bzw. die Entscheidungspositions- Verarbeitungsinformation °MergeSets_Union° mit der Entscheidungspositions- Verarbeitungsfunktions-Erweiterung °Param_UnionAH° für alle ihre * -Entscheidungspositionen, wodurch automatisch ein jeweils identer, optimierter Zugriffsplan erzeugt werden kann.

Dieses Prinzip kann für alle definierten und definierbaren RTN-Bausteine angewandt werden und wird deshalb nicht für weitere RTN-Bausteine gezeigt.

Des Weiteren wird festegestellt, dass die Entscheidungspositions-Verarbeitungsinformation ° Union⁰ somit in mehreren unterschiedlichen RTN-Bausteinen sogar unterschiedlicher Gattungsgruppen angegeben ist, im Konkreten zumindest in den RTN-Bausteinen „Mengen- Zusammenführend" und „Mengen-Zusammenführend (Veränderte syntaktische Form)". Somit wird gewährleistet, dass die zugrunde liegende Anfragesprache leicht erweiterbar ist und gleiche Befehle entweder in unterschiedlicher syntaktischer Form oder in unterschiedlichen Sprachen vorliegen können. Ebenso können, wie im konkreten Fall, in einem RTN-Baustein mehrere Entscheidungspositions-Verarbeitungsinformationen initialisiert und nacheinander berücksichtigt werden, wobei gleiche Entscheidungspositions- Verarbeitungsinformationen in unterschiedlichen Bausteinen verwendet werden können.

Der RTN-Baustein Verarbeitung_SameParents, zeigt, dass die Entscheidungspositions- Verarbeitungsinformation ⁰ForChildren_UseSameEingangsMenge° ab der zweiten Entscheidungsposition „Schlüsselwort /" initialisiert und solange als aktuelle Entscheidungspositions-Verarbeitungsinformation beibehalten wird, bis die Entscheidungsposition „Schlüsselwort \" erreicht wird. Diese Entscheidungsposition „Schlüsselwort \" hat die Entscheidungspositions-Verarbeitungsinformation °Mer geSets JJnion⁰ zugeordnet. Somit gilt ab Erreichen der Entscheidungsposition „Schlüsselwort \" die Entscheidungspositions-Verarbeitungsinformation °Mer geSets _Union° als aktuelle Entscheidungspositions-Verarbeitungsinformation des RTN-Bausteins Verarbeitung_SameParents.

Durch die bislang definierten RTN-Bausteine wird folgender Ausschnitt eines Statements syntaktisch zugelassen und kann entsprechend gedeutet werden, wobei „A" und „B" jeweils ein Tabellenfeld darstellen, und „Mengel", „Menge2" und „Menge3" jeweils eine Tabelle, eine Menge oder eine Verarbeitungs-Ausgangsmenge eines RTN-Bausteins darstellen.

Beispiel: A / B

In diesem Statement-Ausschnitt wird eindeutig der RTN-Baustein Punkt-Rechnen-Operation identifiziert, an dessen beiden Entscheidungspositionen jeweils ein RTN-Baustein Tabellenfeld eingesetzt ist. Somit wird für den RTN-Baustein Punkt-Rechen-Operationen die Entscheidungspositions-Verarbeitungsinformation ⁰CaIcJ⁰ ab der Entscheidungsposition „Schlüsselwort /" festgelegt und für die zweite Entscheidungsposition „Schlüsselwort /" und die dritte Entscheidungsposition „*" im Zugriffsplan-Erstellungsschritt ausgewertet.

Ein weiteres, einfaches Beispiel, welches ein Anfragestatement darstellt, zeigt jenen Fall, in dem eine Verarbeitungsinformation erst dann endgültig zur Anwendung kommt, sobald ein aufgerufener RTN-Baustein erfolgreich durchlaufen wird: Beispiel: [ Mengel // Menge2 Menge3 W ]

Das erste Schlüsselwort dieses Statements ist das Schlüsselwort „[", für welches eine Übereinstimmung mit dem RTN-Baustein „Ebenen" an der ersten Entscheidungsposition festgestellt wird. Diese erste Entscheidungsposition des RTN-B austeins Ebenen legt die Entscheidungspositions- Verarbeitungsinformation °ForChüdren_UseSetOfPrev*° für diese erste und alle ihr am gleichen Entscheidungspfad folgenden Entscheidungspositionen bis auf Widerruf fest, also solange, bis eventuelle eine Entscheidungsposition im gleichen Entscheidungsgraphen angetroffen wird, welche eine andere Entscheidungspositions- Verarbeitungsinformation der ersten Entscheidungspositions-

Verarbeitungsinfoπnationsgruppe als ab dieser erreichten Entscheidungsposition aktuelle Entscheidungspositions- Verarbeitungsinformation festlegt. Dieser ersten

Entscheidungsposition folgt eine * -Entscheidungsposition, und in der zu analysierenden Syntax ist das aktuelle Schlüsselwort „Mengel", welche den RTN-Baustein Tabelle identifiziert erfolgreich durchläuft. Das nächste Schlüsselwort im Statement ist „/". Da der RTN-Baustein „Tabelle" erfolgreich durchlaufen wurde, wird für das Schlüsselwort „/" geprüft, ob ein RTN-Baustein der zweiten Gattungsgruppe vorhanden ist, der mit diesem Schlüsselwort an nach dem Umwandlungsschritt erster Entscheidungsposition betreten werden kann. Somit wird vorläufig den RTN-Baustein zweiter Gattungsgruppe „Strich- Rechnen-Operationen" für die aktuelle Verschachtelung angenommen. An der Entscheidungsposition „Schlüsselwort /" im RTN-Baustein „Strich-Rechen-Operationen" wird die Entscheidungspositions-Verarbeitungsinformation ⁰CaIcJ⁰ für diese und die nachfolgende Entscheidungsposition festgelegt. Das nächste Schlüsselwort in diesem Statement ist das Schlüsselwort „/". Dieses Schlüsselwort „/" wird als zweite * -Position in den RTN-Baustein „Strich-Rechen-Operationen" eingesetzt, und es wird der RTN-Baustein „Verarbeitung_SameParents" erkannt, da dieser mit dem Schlüsselwort „/" an der ersten Entscheidungsposition aufgerufen wird. Dieser ersten Entscheidungsposition des RTN- Bausteins „Verarbeitung_SameParents" ist keine Entscheidungspositions- Verarbeitungsinformation zugeordnet, weshalb für diesen RTN-Baustein an dieser ersten Entscheidungsposition „Schlüsselwort /" keine Verarbeitungsinformation festgelegt wird. Der RTN-Baustein „Verarbeitung_SameParents" verlangt an seiner zweiten Entscheidungsposition nochmals Schlüsselwort „/", wobei im aktuellen Statement das Schlüsselwort „Menge2" folgt. Somit wird der Durchlauf des RTN-Bausteins „VerarbeitungJSameParents" abgebrochen und es wird weiters festgestellt, dass in der Gesamtheit der definierten RTN-Bausteine kein weiterer RTN-Baustein der ersten Gattungsgruppe vorhanden ist, welcher ebenfalls mit dem Schlüsselwort „/" an erster Entscheidungsposition beginnt. Dem zufolge wird der Durchlauf des übergeordneten RTN- Bausteins „Strich-Rechen-Operationen" ebenfalls abgebrochen, da kein RTN-Baustein an die dritte Entscheidungsposition „*" eingesetzt und durchlaufen werden konnte. Die vorläufig initialisierte Entscheidungspositions-Verarbeitungsinformation °Calc_/° wird sowohl für diesen RTN-Baustein als auch für die aktuelle Verschachtelung verworfen. Nachdem kein weiterer RTN-Baustein der zweiten Gattungsgruppe aus der Gesamtheit der definierten RTN- Bausteine mit dem Schlüsselwort „/" an erster Entscheidungsposition vorhanden ist, wird für das Schlüsselwort „/" des Anwender-Statements, welches dem Schlüsselwort „Menge 1" folgt, ein RTN-Baustein erster Gattungsgruppe gesucht. Es wird der RTN-Baustein „VerarbeitungJSameParents" identifiziert, und es folgt ein Abgleich der nachfolgenden Entscheidungspositionen des RTN-Bausteins „Verarbeitung SameParents" mit den nachfolgenden Schlüsselworten des Statements. Die zweite Entscheidungsposition des RTN- Bausteins „Verarbeitung_SameParents" schreibt in Übereinstimmung mit dem Statement die Entscheidungsposition „/" vor, weshalb die dieser Entscheidungsposition zugeordnete Entscheidungspositions-Verarbeitungsinformation °ForChildren__UseSameEingangsmenge° sowohl für die aktuelle als auch für die nachfolgenden Entscheidungspositionen dieses RTN- Bausteins solange als aktuelle Entscheidungspositions- Verarbeitungsinformation festgelegt wird, bis eine gegebenenfalls nachfolgende Entscheidungspositions-Verarbeitungsinformation der ersten Entscheidungspositions-Verarbeitungsinformationsgruppe angetroffen wird. Dem Statement ohne weitere Erklärungen folgend, werden an zwei *-Entscheidungspositionen des RTN-Bausteins „Verarbeitung_SameParents" jeweils ein RTN-Baustein „Tabelle" eingesetzt (Schlüsselworte „Menge2" und „Menge3"). Für diese beiden Entscheidungspositionen wird jeweils die gleiche Entscheidungspositions- Verarbeitungsinformation

°ForChildren_SameParents° herangezogen und unter vorbestimmbarer Auswertung im Zugriffsplan-Erstellungsschritt berücksichtigt. Der Zugriffsplan-Erstellungsschritt wird aus Übersichtlichkeitsgründen erst an späterer Stelle in der Beschreibung im Detail ausgeführt.

Aufgrund der gegebenen Syntax wird nach dem Schlüsselwort „Menge3" das Schlüsselwort „\" erreicht. Die aktuelle und erfolgreich durchlaufene * -Entscheidungsposition im RTN- Baustein „Verarbeitung_SameParents" enthält den RTN-Baustein der ersten Gattungsgruppe „Tabelle". Es wird der in der Beschreibung vorher beschriebenen Logik entsprechend gesucht, ob diesem RTN-Baustein „Tabelle" ein RTN-Baustein der zweiten Gattungsgrappe folgt. Im Konkreten wird das aktuelle Schlüsselwort des Statements „\" als RTN-Baustein „Strich-Rechen-Operation" erkannt, welcher an seiner Entscheidungsposition „Schlüsselwort \" die Entscheidungspositions-Verarbeitungsinformation °Calc_\° für die aktuelle und alle nachfolgenden Entscheidungsposition bis auf Widerruf — also bis auf Übersteuerung - festlegt. Der Entscheidungsposition „Schlüsselwort \" im Entscheidungsgraphen des RTN- Bausteins „Strich-Rechen-Operation" folgt die Entscheidungsposition „*", welche das Einsetzen und Durchlaufen eines RTN-Bausteins aus der ersten Gattungsgruppe vorschreibt. Es wird kein RTN-Baustein der ersten Gattungsgruppe aus der Gesamtheit der bislang definierten RTN-Bausteine aufgefunden, welcher das Schlüsselwort „\" an erster Entscheidungsposition vorschreibt. Demzufolge wird der Durchlauf des RTN-Bausteins „Strich-Rechen-Operationen" abgebrochen, und die vorläufig festgelegte Entscheidungspositions-Verarbeirungsinformation °Calc_\° wird verworfen. Als aktuelles Schlüsselwort im Statement wird erneut das Schlüsselwort „\" herangezogen, welches dem Schlüsselwort „Menge3" folgt. Dieses Schlüsselwort wird als gültige Entscheidungsposition „Schlüsselwort \" im aktuellen RTN-Baustein „Verarbeitung_SameParents" erkannt und diese Entscheidungsposition wird entsprechend ausgewertet, da für sie weiterhin die Entscheidungspositions- Verarbeitungsinformation °ForChildrenJUseSameEingangsmenge ° zugewiesen ist. Als nächste Entscheidungsposition wird die Entscheidungsposition „Schlüsselwort \" erfolgreich mit dem aktuellen Schlüsselwort „\" des Statement abgeglichen und die dieser Entscheidungsposition zugeordnete Entscheidungspositions- Verarbeitungsinformation der ersten Entscheidungspositions- Verarbeitungsinformationsgruppe °ForChildren_Union° als nunmehr aktuelle Entscheidungspositions-Verarbeitungsinformation festgelegt, welche im Zugriffsplan- Erstellungsschritt berücksichtigt wird.

Nach dem erfolgreichen Abgleich mit der letzten Entscheidungsposition im RTN-Baustein „Verarbeitung_SameParents" ist dieser RTN-Baustein erfolgreich durchlaufen. Da für das nächste, aktuelle Schlüsselwort „]" im Statement weder ein RTN-Baustein der ersten noch der zweiten Gattungsgruppe identifiziert wird, wird diese Schlüsselwort „]" erfolgreich mit der letzten Entscheidungsposition des RTN-Bausteins Ebenen abgeglichen. Diese Entscheidungsposition „Schlüsselwort ]" übersteuert die vormals aktuelle Entscheidungspositions-Verarbeitungsinformation °ForChüdren_UseSetOfPrev*° mit der dieser Entscheidungsposition zugeordneten Entscheidungspositions-Verarbeitungsinformation °GiveResultToParent° und bringt diese im Zugriffsplan-Erstellungsschritt zur Anwendung.

Die endgültige Verschachtelung dieses aufgelösten Statements wird nachfolgend mit den festgelegten Entscheidungspositions-Verarbeitungsinformationen je Entscheidungsposition und je RTN-Baustein gezeigt:

[ ΨorChildren_UseSetOfi^>rev*° RTN-Baustein: Ebenen

Menge 1 °Init_Table° RTN-Baustein: Tabelle

°ForChildren_UseSetOfPrev*° RTN-Baustein: Ebenen

/ RTN-Bautein: Verarbeitung_SameParents

/ °ForChildren_UseSameEingangsMenge° RTN-Bautein: Verarbeitung_SameParents Menge2 °Init_Table° RTN-Baustein: Tabelle

°ForChildren_ UseSameEingangsMenge ° RTN-Bautein: Verarbeitung_SameParents

Menge3 °Init_Table° RTN-Baustein: Tabelle

°ForChildren_UseSωneEingangsMenge ° RTN-Bautein: Verarbeitung_SameParents

\ °ForChildren_UseSameEingangsMenge° RTN-Bautein: Verarbeitung_SameParents \ °ForChildrenJJnion° RTN-Bautein: Verarbeitung_SameParents aForChildren_UseSetOfPrev*° RTN-Baustein: Ebenen

] °GiveResultToParent° RTN-Baustein: Ebenen

Diese Darstellung enthält keine Angabe aller verarbeitungsrelevanten RTN-Baustein- Informationen, wie sie vorhergehend in der Beschreibung erläutert sind. Ebenso wird die nachfolgende Zugriffsplan-Erstellung für eine derartige Verschachtelung und zugeordneten Entscheidungspositions- Verarbeitungsinformationen je Entscheidungsposition an späterer Stelle in der Beschreibung gezeigt, um die Übersichtlichkeit zu wahren.

Ein weitere RTN-Baustein, der bei Aufruf je nach erfolgreich durchlaufenen Entscheidungspfad unterschiedliche Verarbeitungsinformationen und gegebenenfalls Verarbeitungsinformations-Erweiterungen an entsprechenden Entscheidungspositionen initialisiert, ist der gezeigte RTN-Baustein ALL/ ANY: RTN-Baustein ALL/ANY:

RTN-Syntax: („ALL" °Extend_All° | „ANY" °Extend_Any° ) ["(" ("<" "="

°Param_Comp<=° | ">" "=" °ParamjOomp>=° | "=" °ParamjOomp=° ) Y:Zah\ ")"] *

Durch Existenz dieses RTN-Bausteins sind folgende Statement-Ausschnitte möglich, die aufgrund unterschiedlich erreichter Entscheidungspositionen im gleichen RTN-Baustein ALL/ANY jeweils unterschiedliche Verarbeitungsinformationen bzw.

Verarbeitungsinformations-Erweiterungen initialisieren und entsprechend zu anderen Zugriffsplänen führen:

ALL Archiv ANY Archiv ALL (<=5) Archiv ANY (>=6) Archiv

Für den Statement-Ausschnitt ANY (>=6) Archiv wird zur Erklärung die endgültige Verschachtelung dieses aufgelösten Statements mit den festgelegten Entscheidungspositions- Verarbeitungsinformationen je Entscheidungsposition und je RTN-Baustein nachfolgend gezeigt:

ANY °Extend_Any° RTN-Baustein: ALL/ANY

( °Extend_Any° RTN-Baustein: ALL/ANY

< °Extend_Any° RTN-Baustein: ALL/ANY

= °Extend_Any° erweitert um: °Param _Comp>= RTN-Baustein: ALL/ANY

66 °°EExxtteenndd_AAnnyv°° eerrwweeiitteertrt uumm:: °°PPaarraamm CCoommpp>>==° RTN-Baustein: ALL/ANY

) °Extend_Any° erweitert um: °Param Comp>= RTN-Baustein: ALL/ANY

Archiv °Mt_ Table° RTN-Baustein: Tabelle

°Extend_Any° erweitert um: °Param _Comp>= RTN-Baustein: ALL/ANY

Liegen die RTN-Bausteine und somit auch die gesammelten Verarbeitungsinformationen je Entscheidungsposition für ein gegebenes Statement in endgültig verschachtelter Form vor, wird ein Zugriffsplan-Erstellungsschritt ausgeführt. Um einen Zugriffsplan-Erstellungsschritt anwenden zu können, sind weitere Teilschritte im Voreinstellungsschritt notwendig. Diese Teilschritte werden nachfolgend im Detail gezeigt:

RTN-Bausteine sind jeweils unabhängig voneinander definierbar. Ebenso werden RTN- Bausteine unabhängig davon erstellt, welche Verarbeitungsfunktion bzw.

Verarbeitungsfunktionen sie auf Elemente von Mengen oder Mengen sie anwenden. Um die

Kommunikation zwischen RTN-Bausteinen in einer konkret verschachtelten Form sowie die

Erstellung eines der Angabe entsprechenden, optimierten Zugriffsplans zu ermöglichen, ist es notwendig, jedem RTN-Baustein einen Verarbeitungs- Ausgangstyp zuzuweisen. Mittels dieses Typs wird festgelegt, welches Element oder welche Art von Elementen die

Verarbeitungs- Ausgangsmenge eines jeweiligen RTN-Bausteins enthält.

So liefern beispielsweise die RTN-Bausteine „Tabelle", „FROM", „WHERE", „ORDERBY" jeweils eine Tabelle oder Menge mit Datensätzen oder eine leere Menge zurück. Dies gilt für alle RTN-Bausteine, deren Verarbeitungsfunktion(en) auf Elemente ihrer Eingangsmenge anwenden bzw. eine Verarbeitungsmenge mit Datensätzen liefern.

Der RTN-Baustein „Tabellenfeld" liefert ein Tabellenfeld und je Element der Eingangsmenge den Wert des Tabellenfeldes in seiner Ausgangsmenge zurück. Weiters können Tabellenfeld beispielsweise auf Index-Nutzung und anderes Optimierungspotenzial untersucht werden.

Der RTN-Baustein „Variable" liefert einen festgelegten oder variablen Wert zurück, der sich in der Analyse, Verarbeitung, Deutung und Optimierung stark von dem Wert, den ein Tabellenfeld zurückliefert, unterscheidet. Werte können beispielsweise je Element ihrer Verarbeitungs-Eingangsmenge konstant sein und müssen nicht jeweils neu berechnet oder gesetzt werden. Ebenso liefern jene RTN-Bausteine einen Wert zurück, welche ein Berechnung für zumindest einen der ihnen mitgegebenen Werte ausführen, z.B. die RTN- Bausteine „Strich-Rechen-Operationen" und „Punkt-Rechen-Operationen"

Sämtliche RTN-Bausteine, welche einen BooP sehen Vergleich ausführen, wie z.B. die RTN- Bausteine „Bool-Kombi", „Verneinender Boolean" „Vergleich", „Vergleich-IN", aber auch der RTN-Bausteine „Relativer Zeilenauswählender Bubble", unterscheiden sich ebenfalls in der Verarbeitungs-Ausgangsmenge von den anderen RTN-Baustein. RTN-Bausteine, welche einzelne Elemente sammeln, und das gegebenenfalls je Element ihrer Verarbeitungs-Eingangsmenge, lassen sich für eine Zugriffsplan-Erstellung mitunter anders deuten und optimieren als jene RTN-Bausteine, welche jeweils nur einen Wert bzw. ein Tabellenfeld mit je Datensatz zugehörigem Feldwert liefern.

Eine weitere Besonderheit im Sinne der Deutung und der Optimierung findet sich bei jenen RTN-Bausteinen, welche Werte oder Elemente von Mengen aggregieren bzw. Operationen auf vorher aggregierte Werte oder Menge anwenden. Insbesondere diese Fälle lassen mehrfache Deutungen der Syntax zu und sind dementsprechend wichtig zu erkennen.

Zusätzlich gibt es RTN-Bausteine, die keinen bestimmten Ausgangstypen direkt festlegen können, da deren Ausgangstyp beispielsweise von deren letzter * -Entscheidungsposition festgelegt wird. Hierzu zählt zumindest der RTN-Baustein „Zusammenfassend" mit der RTN- Syntax J¹¹ * „Y^c. Wird in diesem RTN-Baustein Zusammenfassend an der *- Entscheidungsposition beispielsweise ein RTN-Baustein „Tabellenfeld", ein RTN-Baustein „Variabler Wert" oder ein RTN-Baustein „Strich-Rechen-Operationen", welcher wiederum das Ergebnis zweier oder mehrerer Werte berechnet, eingesetzt, ist der Ausgangstyp dieses RTN-Bausteins der Ausgangstyp „Tabellenfeld" bzw. „Wert". Wird an der *- Entscheidungsposition dieses RTN-Bausteins beispielsweise eine Tabelle oder ein RTN- Baustein, welcher als Ausgangstyp eine Menge liefert, eingesetzt und durchlaufen, liefert dieser RTN-Baustein „Zusammenfassend" als Ausgangstyp „Menge". Äquivalent gilt dies auch für einen an der *-Entscheidungsposition eingesetzten RTN-Baustein mit dem Ausgangstyp „Boolean" und „Menge an Werten" sowie für sämtliche andere, definierte Ausgangstypen.

Ein weiterer RTN-Baustein, dessen Ausgangtyp von dem RTN-Baustein abhängt, welcher an seiner * -Entscheidungsposition eingesetzt ist, ist der RTN-Baustein „Zwischenmengen" mit der RTN-Syntax * „AS" V:Zwischenrnengenname, welcher einen Wert, einen Boolean, eine Menge an Werten oder eine Menge mit Elementen enthält und zumindest für die Dauer der Anfrage zwischenspeichert und bereitstellt. In vielen Fällen kann eine gewünschte Deutung der Syntax nur in Abhängigkeit aus der gesamten Verschachtelung des Statements und gegebenenfalls unter Rückfrage beim Anwender erzielt werden. Dies bedeutet, dass die RTN-Baustein und vor allem die Entscheidungspositions-Verarbeitungsinformationen, die unabhängig voneinander zumindest jeweils einer Entscheidungsposition in zumindest einem Teil derselben zugewiesen sind, nicht immer die eine gleiche Engine-Verarbeitungsfunktion ausführen. Wie diese und ähnliche Fälle mittels des erfindungsgemäßen Verfahrens auflösbar sind, wird in der Beschreibung später im Detail gezeigt. Es wird darauf geachtet, dass sämtliche benötigten Schritte einzeln und für den Fachmann übersichtlich gezeigt werden.

Aufgrund der extremen Flexibilität der RTN-Bausteine und deren Verschachtelungsmöglichkeit, die durch die endlich wiederholbare rekursive RTN-B austein- Einsetzposition ermöglicht wird, können von einem Anwender auch Varianten definiert werden, die in der sich konkret ergebenden Verschachtelung zumindest vorläufig noch keine Deutung definiert haben. Um derartige Fälle zu definieren, kann der Ausgangstyp „Nicht Zulässig" für betroffene Verschachtelungen oder Kombination zweier oder mehrere RTN- Bausteine angegeben werden werden.

Nachdem sowohl jeweils voneinander unabhängige RTN-Bausteine und Entscheidungspositions-Verarbeitungsinformationen definiert wurden, als auch der

Entscheidungspositions-Verarbeitungsinformations-Zuordnungsschritt angewandt wurde, wird der nächste Teilschritt des Voreinstellungsschrittes angewandt und gezeigt. Dieser nächste, auszuführende Schritt ist der Engine-Verarbeilimgsfunktions-Erstellungsschritt. In diesem Schritt werden voneinander unabhängige Engine- Verarbeitungsfunktionen erstellt, welche im Zugriffsplan-Erstellungsschritt gegebenenfalls mit sich aus dem Statement ergebenden Parameter verwendet werden und somit insgesamt einen Zugriffsplan erstellen.

Mittels der RTN-Bausteine werden in einem Statement temporär oder auf den tatsächlichen Datenbestand endgültig anzuwendende Verarbeitungsfunktionen beschreiben. Weites wird mit den RTN-Bausteinen in der konkreten Verschachtelung festgelegt, in welcher Reihenfolge die Engine-Verarbeitungsfunktionen auszuführen sind und es wird eine Verarbeitungs-Eingangsmenge oder Verabeitungs-Eingangsmengen für die jeweiligen Engine-Verarbeitungsfünktionen anhand des Anwender-Statements im Konkreten festlegt. Somit ergeben sich zwei unterschiedliche Gruppen an Engine- Verarbeitungsfunktionen.

Nachfolgend werden einige Engine-Funktionen aus der Gesamtheit der möglichen, endlich erweiterbaren Engine-Funktionen aufgelistet.

Engine-Verarbeitungsfunktionen, welche Verarbeitungsfunktionen auf zumindest eine

Verarbeitungs-Eingangsmenge anwenden und als Ergebnis dieser Verarbeitungsfuiiktion eine

Verarbeitungs- Ausgangsmenge liefern:

GetJTableMenge Get_TableFieldValue Get_Value

BuildCartesian

SetOperation_WHERE

SetOperation_MIN SetOperation_MAX SetOperation_ORDERBY Setoperation_ORDERBY_DESCParam

SetOperationJJNION CombineValuesToSet

Return LastMenge Return_LastValue Return LasfMengeVon Werten

GroupBy_DoInGroupBy

Aggreate_SUM Aggregate_Count Aggregate_DiffrentValues Aggregate_ForElements

Calc_+ Calc_- Calc_* Calc_/ Calc_\ Calc_Mod

Bool_AND . Bool_OR Bool_XOR

Bool_IN_Left Bool_IN_Right Bool_IN_LeftRight

Bool_Value= Bool_Value> Bool_Value< Bool_Value<> Bool_Value<= BoolValue>=

Engine-Verarbeitungsfunktionen, welche Verarbeitungs-Eingangsmengen für jeweilige Verarbeitungsfünktionen in der endgültigen Verschachtelung von RTN-Bausteinen festlegen:

ForChildren_UseSameEingangsMenge ForChildren_UseSetOfPrev* Es wird angemerkt, dass die Bezeichnungen, welche diesen Engine-Funktionen zugeordnet sind, genauso willkürlich von einem Anwender im Auswahlschritt vergeben werden können, wie die Bezeichnungen der Entscheidungspositions-Verarbeitungsinformationen. Des weiteren kann auch jeder Engine-Funktion zusätzlich ein jeweils eindeutiger Wert zugeordnet werden, im die Zugriffsplan-Erstellung anhand von schnellen Zahlenvergleichen anstatt mit langsamen Text-Vergleichen durchzuführen. Engine-Funktionen und Entscheidungspositions- Verarbeitungsinformationen haben keine vorbestimmte Beziehung zueinander, was bedeutet, dass die Engine-Funktionen in Abhängigkeit der von einem Anwender angegebenen Syntax und somit in Abhängigkeit einer endgültigen Verschachtelung von RTN-Bausteinen und festgelegten Entscheidungspositions-Verarbeitungsinformationen im Zugriffsplan- Erstellungsschritt vergeben und gegebenenfalls mit Parametern versehen angeordnet werden.

Um einen kontext-sensitiven Zusammenhang zwischen den Entscheidungspositions- Verarbeitungsinformationen und den Engine-Funktionen herzustellen und daraus einen Zugriffsplan zu generieren, empfiehlt es sich, eine Verarbeitungs-Informations- Enginefunktions-Zuordnungsmenge zu definieren, aus welcher in einer konkreten Verschachtelung erkannt wird, welche Engine-Verarbeitungsfunktionen aufgrund eines angegebenen Statements bzw. einer angegebenen Syntax für jeweiligen RTN-Bausteine in einer von der endgültigen Verschachtelung unabhängigen Reihenfolge Engine- Verarbeitungsfunktionen erstellt werden.

Um diese Verarbeimngs-Informations-Enginefunktions-Zuordnungsmenge zu definieren, ist die Einführung von Verarbeitungstypen notwendig. Verarbeitungstypen fungieren als Verarbeitungs- Ausgangstypen und Verarbeitungs-Child-Typen. Dies wird nachfolgend in der Beschreibung erklärt. Jedem RTN-Baustein wird, gegebenenfalls in Abhängigkeit jener Verarbeitungstypen, welche entweder eine, zwei oder mehrere seiner eingesetzten *- Entscheidungspositionen enthält, an zumindest der letzten erreichten Entscheidungsposition ein Verarbeitungstyp zugeordnet. Einer Entscheidungsposition eines RTN-Bausteins können jeweils auch mehrere unterschiedliche, jedenfalls aber in Abhängigkeit der Verarbeitungstypen zumindest einer eingesetzten * -Entscheidungsposition oder in Abhängigkeit einer automatischer Nachfrage bei einem Anwender, Verarbeitungstypen zugeordnet werden. Diese Verarbeitungstypen werden je Entscheidungspositions- Verarbeitungsinformation zusammen mit einer Engine- Verarbeitungsfunktion in der Verarbeimngs-ImOrmations-Enginefunktions-Zuordnungsmenge gespeichert. Im

Zugriffsplan-Erstellungsschritt erfolgt je Entscheidungspositions-Verarbeitungsinformation ein Abgleich mit den Elementen dieser Menge, wodurch sowohl gegebenenfalls eine Engine- Verarbeitungsfunktion endgültig festgelegt wird, als auch ein Verarbeitungstyp als Verarbeitungs-Ausgangstyp geliefert wird.

Um Endlosschleifen zu vermeiden, ist es - ähnlich wie bei den * -Entscheidungspositionen bei den RTN-Bausteinen - notwendig, dass der Verarbeitungs-Informations-Enginefunktions- Zuordnungsmenge zumindest ein Element hinzugefügt wird, welches unabhängig von gegebenenfalls vorhandenen *-Entscheidungspositionen eines zugehörigen RTN-Bausteins, für eine Entscheidungspositions-Verarbeitungsinformation eine von gegebenenfalls vorhandenen Child-Verarbeitungstypen eine Engine-Verarbeitungsfunktion und einen zugehörigen Verarbeitungs-Ausgangstypen festlegt. Die Engine-Verarbeitungsfunktion und der Verarbeitungs-Ausgangstyp können aber in Abhängigkeit einer automatischen Nachfrage beim Anwender endgültig festgelegt werden, wobei in diesen Fällen für eine Entscheidungspositions- Verarbeitungsinformation zumindest zwei Elemente in der Verarbeilamgs-Infomiations-Enginefunktions-Zuordnungsmenge sowie je Element ein zugehöriger Text vorhanden sind. Die zugehörigen Text werden dem Anwender automatisch als Auswahlliste gezeigt und dieser kann somit die gewünschte Deutung auswählen.

Es werden folgende, jederzeit erweiterbare Verarbeitungstypen definiert und zu diesen wird vorläufig jeweils nur ein Element in der Verarbeitungs-Informations-Enginefunktions- Zuordnungsmenge erstellt. Diese Erstellung erfolgt als Teilschritt des Voreinstellungsschrittes und kann, wie der Voreinstellungsschritt selbst und alle seine Teilschritte jederzeit und unabhängig von bereits angegebenen und analysierten Statements erneut im Sinne einer Erweiterung oder Neu-Definierung der zugrunde liegenden RTN-Bausteine und deren RTN- Baustein-relevanten Informationen vorgenommen werden.

Value TableFieldValue Menge Boolean neutral

Menge Von Werten In der Beschreibung wird für den ersten Verarbeitungs-Eingangtyp Verarbeitungs- Eingangstypl und für den zweiten Verarbeitungs-Eingangtyp Verarbeitungs-Eingangstyp2 verwendet.

Um die Analyse eines Statements auszuführen, wird eine Verarbeitungsinformations- Enginefunktions-Zuordnungsmenge erstellt. In dieser Verarbeitungsinformations- Enginefunktions-Zuordnungsmenge ist für jede Verarbeitungsinformationen zumindest ein Element enthalten, wobei jedem Element zumindest

ein unabhängiges Verarbeitungs-Informationsfeld enthält, welchem eine Verarbeitungsinformation zugeordnet ist, und

ein unabhängiges, optionales Verarbeitungs-Erweiterungs-Informationsfeld enthält, welchem eine Verarbeitungs-Erweiterungs-Information zugeordnet ist, und

ein unabhängiges Engine-Funktionsfeld enthält, welchem eine Engine-Funktion zugeordnet ist.

Es wird eine Verarbeitungsinformations-Enginefunktions-Zuordnungsmenge definiert, welche nachfolgend als Tabelle dargestellt wird und weiters zumindest die folgenden Felder enthält:

In dieser Tabelle werden -folgende Abkürzungen verwendet: Entscheidungspositions- Verarbeitungsinformation: EP-VI¹ Entscheidungspositions- Verarbeitungsinformation Erweiterung EP-VI-E² Verarbeitungs-Eingangstyp 1 VA-ETl³ Verarbeitungs-Eingangstyp2 VA-ET2⁴ Engine- Verarbeitungsfunktion E-VA⁵ Verarbeitungs- Ausgangstyp VA-AT⁶ RTN-Baustein-Verschachtelung-Kommunizierer VS-Kom⁷

Sämtliche Elemente der Verarbeitungs-Informations-Enginefunktions-Zuordnungsmenge werden in der Beschreibung in diese Tabelle eingefügt und eine Auswertung der Entscheidungspositions- Verarbeitungsinformationen erfolgt in Abgleich mit dieser Tabelle. Ein Fachmann kann ebenfalls eine andere Darstellung und Speicherung der Informationen wählen, so kann diese Tabelle für die Verarbeitung zum Beispiel ein einen Graph oder in eine Liste eingelesen und somit schneller verarbeitet werden.

Auf die Spalte „RTN-Baustein-Verschachtelung-Kommunizierer" wird der Übersicht wegen später in der Beschreibung eingegangen.

Es werden in dieser anfänglich leeren Tabelle nun einige mögliche Elemente bzw. Datensätze für Entscheidungspositions-Verarbeitungsinformationen angefügt:

Es werden nochmals die RTN-Bausteine gezeigt, welche die Entscheidungspositions- Verarbeitungsinformationen enthalten, die in dieser Tabelle gezeigt sind. Jedenfalls können andere RTN-Bausteine ebenfalls eine dieser Entscheidungspositions- Verarbeitungsinformationen an zumindest einer ihrer Entscheidungspositionen zugeordnet haben.

RTN-Baustein „Tabelle": RTN-Syntax: Tabellenname °Init_Tab!e°

RTN-Baustein „Tabellenfeld":

RTN-Syntax: Tabellenfeldname °Init_TableField°

RTN-Baustein „Tabelle":

RTN-Syntax: Tabellenname °Init_Table°

RTN-Baustein „Ebenen":

RTN-Syntax: "[" °ForChildren_UseSetOfPrev*° (1) * [(^♦].)] "]" °GiveResultToParent°

Um einen Zugriffsplan zu erstellen, müssen Engine-Verarbeitungsfunktionen in einer anzuwendenden Reihenfolge angegeben werden und für jede Engine- Verarbeitungsfunktion muss angegeben werden, auf welchen Wert, Element bzw. Elemente diese angewandt werden sollen. Diese Informationen können als Parameter von Engine-Verarbeitungsfunktionen angegeben werden, wobei sowohl die Engine-Verarbeitungsfunktionen, deren Reihenfolge als auch deren Parameter automatisch aus einem Anwender-Statement erzeugt werden.

Ein mögliches Verfahren arbeitet mit einer Verarbeimngs-Iπdformations-Engmefunktions- Zuordnungsmenge wie sie beispielsweise in der obigen Tabelle dargestellt ist. Eine Befüllung dieser Verarbeitungs-Informations-Enginefunktions-Zuordnungsmenge erfolgt als Teilschritt des Voreinstellungsschrittes. Es wird ein Verfahren offenbart, welches aus einem angegebenen Statement, auf das der Auswahlschritt rekursiv angewandt wurde und für welches eine entsprechende Verschachtelung der RTN-Bausteine und deren Entscheidungspositions- Verarbeitungsinformationen bereits vorhanden ist. Dieses Verfahren ist Teil des Zugriffsplan- Erstellungsschrittes .

Das Verfahren basiert auf dem Prinzip, dass eine endgültige Verschachtelung der RTN- Bausteine mit deren Entscheidungspositionen und den je Entscheidungsposition festgelegten Entscheidungspositions- Verarbeitungsinformationen, welche entweder bei einer Entscheidungsposition festgelegt werden, oder ab einer festgelegten Entscheidungsposition bis auf Übersteuerung für alle nachfolgenden Entscheidungspositionen im gleichen Entscheidungspfad eines RTN-Bausteins gültig sind, durchlaufen wird. Es wird bei der ersten Entscheidungsposition des äußersten RTN-Bausteins begonnen und dieser sowie allen nachfolgenden Entscheidungspositionen gefolgt, wobei an jeden Entscheidungspositionen, an welchen ein RTN-Baustein aufgrund einer * -Entscheidungsposition eingesetzt ist, dieser jeweils eingesetzte RTN-Baustein durchlaufen wird, und dann der nächsten Entscheidungsposition des jeweils übergeordneten RTN-Bausteins gefolgt wird.

An jeder Entscheidungsposition aller RTN-Bausteine, welche in der gesagten Reihenfolge durchlaufen und erreicht werden, wird geprüft, ob für diese Entscheidungsposition, gegebenenfalls unter Auswertung vorbestimmbarer Parameter, eine Engine-Funktion im Zugriffsplan, gegebenenfalls mit Parametern, hinzugefügt werden soll.

Das erfindungsgemäße Verfahren zur Erstellung eines Zugriffsplans berücksichtigt sehr viele unterschiedliche auszuwertende Parameter und Schritte, weshalb dieses schrittweise vorerst anhand von einfachen Beispielen gezeigt und erweitert wird. Eine Zusammenfassung des Verfahrens erfolgt jeweils nach den Beispielen, um die Übersicht für einen Fachmann zu wahren.

Anhand des folgenden einfaches Beispiels wird der erste Teil des Verfahrens gezeigt:

Beispiel: [ TabelleA ]

Dieses einfache Beispiel ist nach Anwendung des Auswahlschrittes folgendermaßen verschachtelt und hat je Entscheidungsposition folgende Entscheidungspositions- Verarbeirungsinformation:

[°ForChildrenJJseSetOfPrev*° *(\)°ForChildrenJJseSetOfi^>rev*° ] °GiveResultsToParent°

(l)TabelleA°/HzϊjrαWe°

Erfindungsgemäß wird das erste Schlüsselwort dieser Verschachtelung des äußersten RTN- Bausteins, im Konkreten des RTN-Bausteins „Ebenen" geprüft und dem Entscheidungsgraphen, der diesem Schlüsselwort folgt, wird bis zum Ende durchlaufen.

1. [ψorChüdrenJJseSetOfiPrev*⁰

Für diese Entscheidungsposition sind kein Verarbeitungs-Eingangstypl (VA-ETl³) und kein Verarbeitungs-Eingangstyp2 (VA-ET2⁴) vorhanden, da an dieser Entscheidungsposition kein RTN-Baustein eingesetzt wurde, welcher einen Verarbeitungs-Ausgangstypen (E-VA⁵) liefert. Somit wird für aktuelle Entscheidungspositions- Verarbeitungsinformation (EP-VI¹) °ForChüdrenJJseSetOfPrev*° in der Zuordnungstabelle ein entsprechender Eintrag gesucht, wobei keine Entscheidungspositions-Verarbeitungsinformations-Erweiterung (EP-VI-E²) vorhanden ist, welcher dementsprechend wie folgt auszusehen hat:

EP-VI¹: ForChildrenJJsePrev* EP-VI-E²: VA-ETl³: VA-ET2⁴:

Ein derartiger Eintrag wird genau einmal in der Zuordnungstabelle gefunden. Somit ist für diese Verarbeitungsinformation ohne Verarbeitungs-Eingangstypen eindeutig ein Element aufgefunden worden. Die Engine-Verarbeitungsfunktion, welche als Spalte dieses Elements vorhanden ist, wird als erste Engine-Verarbeitungsfunktion initialisiert. Konkret wird die Engine- Verarbeitungsfunktion ForChildren UseSetOfPrev* als erste Engine- Verarbeitungsfunktion festgelegt.

Somit ergeben sich nach diesem ersten Schritt folgende Engine-Befehle in dieser Reihenfolge und mit diesen Parametern:

Rowl ForChildren UseSetOfPrev* keine Parameter

Für den aktuellen RTN-Baustein Ebenen wird die Engine-Befehlszeile Rowl als aktuelle Engine-Befehlszeile festgelegt.

Nachdem für diese erste Entscheidungsposition ein Eintrag in der Zuordnungstabelle gefunden wurde, wird der aktuelle Verarbeitungs-Eingangstypl (VA-ETl³) des aktuellen RTN-Bausteins Ebenen auf den Verarbeitungs-Ausgangstyp (VA-AT⁶) des zugehörigen Eintrags gesetzt. Der Verarbeitungs-Ausgangstyp (VA-AT⁶) hat für dieses Element in der Zuordnungstabelle keinen Wert stehen, womit der Verarbeitungs-Eingangstypl (VA-ETl³) weiterhin keinen Wert enthält. Der Wert des Verarbeitungs-Eingangstyp2 (VA-ETl⁴) wird entfernt.

Als zweiter Schritt wird die zweite Entscheidungsposition des äußersten RTN-Bausteinen, im Beispiel daher der * -Entscheidungsposition des RTN-Bausteins Ebenen, geprüft. Nachdem es sich bei dieser Entscheidungsposition um eine * -Entscheidungsposition handelt, wird der an dieser *-Entscheidungsposition eingesetzte RTN-Baustein Tabellen aufgerufen und dessen in der Verschachtelung festgelegter Entscheidungspfad gefolgt.

Somit wird der RTN-Baustein Tabellen mit seinem Entscheidungspfad, der für die aktuelle Verschachtelung festgelegt ist, durchlaufen und die erste Entscheidungsposition ist „Schlüsselwort: TabelleA". Dieser Entscheidungsposition ist die Entscheidungspositions- Verarbeitungsinformation °Init_Table° zugeordnet. An dieser Entscheidungsposition im RTN-Baustein Tabellen sind ebenfalls noch kein Verarbeitungs-Eingangstyp 1 , Verarbeitungs- Eingangstyp2 und Entscheidungspositions-Verarbeitungsinformations-Erweiterung zugeordnet. Das gilt analog für alle RTN-Bausteine für die erste Entscheidungsposition, sofern es sich bei diesen RTN-Bausteinen um RTN-Bausteine der ersten Gattungsgruppe handelt, also für alle RTN-Bausteine, welche an ihrer ersten Entscheidungsposition im Entscheidungspfad der aktuellen Verschachtelung keine *-Entscheidungsposition aufweisen. Deswegen wird dieser Sachverhalt nicht mehr in den weiteren Schritten erwähnt.

Es wird ein Eintrag in der Zuordnungstabelle gesucht, der folgende Kriterien zu erfüllen hat:

EP-VI¹: Init_Table

EP-VI-E²: VA-ETl³: VA-ET2⁴:

Ein entsprechender Eintrag wird in der Zuordnungstabelle aufgefunden. Diesem Eintrag ist die Engine-Verarbeitungsfunktion Get TableMenge zugeordnet. Diese wird der aktuellen und abzuarbeitenden Engine-Befehlskette hinzugefügt. Da die Entscheidungsposition „Schlüsselwort TabelleA" eine Information enthält, welche nicht in den Schlüsselworten der reservierten Schlüsselwort der RTN-Baustein-Schlüsselworte vorkommt, wird diese Information „TabelleA" als Parameter für diese Engine-Verarbeitungsinformation Get TableMenge gespeichert. Damit ergibt sich folgende Engine-Befehlskette:

Rowl ForChildren UseSetOfPrev* keine Parameter

Row2 Get TableMenge Parameter: TabelleA

Für den aktuellen RTN-Baustein Tabellen wird die Engine-Befehlszeile Row2 als aktuelle Engine-Befehlszeile festgelegt.

In der Zuordnungstabelle ist für das aufgefundene Element ein Verarbeitungs-Ausgangstyp festgelegt: Verarbeitungs-Ausgangstyp „Menge". Diese erste Entscheidungsposition enthält somit als Verarbeitungs-Eingangstypl den Verarbeitungstypen „Menge und der Wert des Verarbeitungs-Eingangstyp2 wird auf leer gesetzt. Ebenso wird der Verarbeitungs- Ausgangstyp des RTN-Bausteins Tabelle auf den Wert „Menge" gesetzt.

Im nächsten Schritt wird festgestellt, dass der RTN-Baustein Tabelle keine weitere Entscheidungsposition enthält und somit erfolgreich durchlaufen ist. Daher wird die zweite Entscheidungsposition des übergeordneten RTN-Bausteins Ebenen erfolgreich durchlaufen. Nun wird für diese zweite Entscheidungsposition geprüft, ob der bereits Verarbeitungs- Eingangstypl gesetzt ist. Dies ist noch nicht der Fall, daher wird der Verarbeitungs- Eingangstypl auf den Verarbeitungs- Ausgangstyp des in der * -Entscheidungsposition eingesetzten RTN-Bausteins, im Konkreten des RTN-Bausteins Tabellen gesetzt. Somit hat der Verarbeitungs-Eingangstypl des RTN-Bausteins Ebenen an der aktuellen, zweiten Entscheidungsposition den Verarbeitungstyp „Tabelle", der Verarbeitungs-Eingangstyp2 desselben RTN-Bausteins hat keinen Verarbeitungstyp zugewiesen.

Im nächsten Schritt wird für die aktuelle Entscheidungspositions- Verarbeitungsinformation dies RTN-Bausteins °ForChildren_UseSetOfl³rev*° ein entsprechender Eintrag in der Zuordnungstabelle gesucht, wobei keine Entscheidungspositions- Verarbeitungsinformations- Erweiterung vorhanden ist und als Verarbeitungs-Eingangstypl der Wert „Tabelle" gesetzt ist und als Verarbeitungs-Eingangstyp2 kein Wert gesetzt ist.

Ein derartiger Eintrag wird in der Zuordnungstabelle nicht gefunden, deshalb wird der Engine-Befehlskette keine neue Engine- Verarbeitungsfunktion hinzugefügt. Es wird als aber als weiterer Verfahrensschritt die letzte Engine-Befehlskettenzeile des an der *- Entscheidungsposition des eingesetzten RTN-Bausteins als Parameter für die aktuelle Engine- Verarbeitungsfunktion des aktuellen RTN-Bausteins Ebenen gesetzt. Somit ergibt sich folgende neue, vorläufige Engine-Befehlskette:

Rowl ForChildren UseSetOfPrev* Parameter: Row2

Row2 Get TableMenge Parameter: TάbelleA

Es wird die nächste Entscheidungsposition im aktuellen RTN-Baustein Ebenen erreicht, welche die Entscheidungsposition „Schlüsselwort ]" ist und folgende Entscheidungspositions- Verarbeitungsinformation festlegt: °GiveResultsToParent°

Diese Entscheidungspositions-Verarbeitungsinformation °GiveResultToParent° behält den Verarbeitungs-Eingangstypl „Menge" und den im konkreten nicht gesetzten Verarbeitungs- Eingangstyp2 bei, um ein entsprechendes Element in der Zuordnungsmenge zu finden. Dies ist nicht für alle Entscheidungspositions-Verarbeitungsinformationen gültig, wie in der Beschreibung später gezeigt wird. Deshalb wird nachfolgend eine Unterteilung der Entscheidungspositions-Verarbeitungsinformationen in zwei vorgenommen und erklärt.

In der Zuordnungstabelle wird ein Element für die Entscheidungspositions- Verarbeitungsinformation °GiveResultToParent° gefunden, welches keine Entscheidungspositions-Verarbeitungsinformations-Erweiterung, einen Verarbeitungs- Eingangstypl „Menge" und keinen Verarbeitungs-Eingangstyp2 vorschreibt.

Das in dieser Zuordnungstabelle aufgefundene Element enthält die Engine- Verarbeitungsfunktion Return Menge und schreibt den Verarbeitungs- Ausgangstyp „Menge" vor. Somit ergibt sich folgende neue, vorläufige Engine-Befehlskette:

Ro w 1 ForChildren UseSetOfPrev* Parameter: Row2

Row2 Get TableMenge Parameter: TabelleA Ro w3 Return LastMenge kein Parameter

Es wird die Engine-Befehlskettenzeile Row3 als aktuelle Engine-Befehlskettenzeile des RTN- Bausteins Ebenen festgelegt, womit die vorherig aktuelle Befehlskettenzeile Rowl dieses RTN-Bausteins übersteuert wird.

Diese Engine-Befehlskette ist nicht vollständig, da in dieser keine vollständigen Informationen vorhanden sind, in welcher Reihenfolge welche Befehle auf jeweils welche Mengen vorhanden sind. So enthält die Engine-Befehlskettenzeile Row3 keinen Parameter, welcher die Menge festlegt, die zurückgeliefert werden soll. Aufgrund des angegebenen Statements soll als Verarbeitungs-Ausgangsmenge die Menge TabelleA zurückgeliefert werden. Dies kann dadurch erzielt werden, dass in der Spalte RTN-Baustein- Verschachtelung-Kommunizierer (VS-Kom⁷) je Element einen Wert enthalten kann, welcher bei Angabe beschreibt, dass der letzte Parameter der ersten Engine-Befehlszeile eines betroffenen RTN-Bausteins als Parameter für die aktuelle Engine-Befehlszeile herangezogen werden soll. In der Beschreibung wird der Wert, der diese Information enthält, „ReturnLastCommandOfFirstVA" bezeichnet. Dieser Wert ist dem aufgefundenen Element in der Zuordnungstabelle für die Entscheidungspositions-Verarbeitungsinformation °GiveResultsToParent° mit dem Verarbeitungs-Eingangstypl „Menge" zugewiesen. Eine mögliche Umsetzung im Zugriffsplan ist, der Engine- Verarbeitungsfunktion Return_LastMenge als Parameter jeweils die Engine-Befehlskettenzeile anzugeben, welche zumindest eine Verarbeitungsmenge enthält. Demnach wird der dritten, aktuellen Engine- Befehlskettenzeile Row3 für die Engine-Verarbeitungsfunktion Return LastMenge als Parameter die erste Engine-Befehlskettenzeile desselben RTN-Bausteins Ebenen, also Rowl, zugewiesen.

Somit ergibt sich folgende, endgültige Engine-Befehlskette, gegebenenfalls weiter optimiert und abgearbeitet werden kann: Eine weitere Optimierung kann bei diesem einfachem Statement eine Low-Level-Optimierung sein, welche die Zugriffe auf die Festplatte und die Speicherverwaltung optimiert.

Rowl ForChildren UseSetOfPrev* Parameter: Row2

Row2 Get TableMenge Parameter: TabelleA Row3 Return LastMenge Parameter: Rowl

Bei der Erstellung von Zugriffsplänen gibt es einen großen Spielraum und dem Fachmann stellen einige Implementierungsmöglichkeiten sowohl für eine grundsätzliche Ausrichtung derselben als auch für die Implementierung von Engine- Verarbeitungsfunktionen zur Auswahl. In der Beschreibung wird eine konkrete Ausrichtung gezeigt, einen Zugriffsplan aus einem Anfragestatement zu erstellen und diesen Zugriffsplan entsprechend mit Zugriff und temporäre oder dauerhafte Verarbeitung auf Daten zu durchlaufen. Die Abarbeitung dieses Zugriffsplans, der durch eine Engine-Befehlskette darstellt ist, welche aus Engine- Befehlskettenzeilen bestehen, erfolgt, indem die letzte Engine-Befehlskettenzeile aufgerufen und angewandt wird. Jede Engine-Befehlszeile hat in einem konkreten Zugriffsplan eine Engine-Verarbeitungsfunktion zugeordnet und diese hat entweder keinen, einen vorbestimmten oder eine vorbestimmte oder variable Mehrzahl an Parametern zugeordnet. Diese Parameter werden im Zugriffsplan-Erstellungsschritt aufgrund einer zu analysierenden Syntax festgestellt und den entsprechenden Engine- Verarbeitungsfunktionen in zugehörigen Engine-Befehlskettenzeilen zugeordnet. Bei Aufruf einer Engine-Befehlskettenzeile wird der jeweilige Befehl angewandt, wobei ein angewandter Befehl, also eine angewandte Engine- Verarbeitungsfunktion, entweder einzeln auf Parameter angewandt wird oder als Parameter andere Engine-Befehlskettenzeilen aufruft bzw. diese Parameter für seine Engine- Verarbeitungstunktion verwendet.

Eine Abarbeitung dieser Variante eines möglichen Zugriffsplans erfolgt wie beschrieben, indem die letzte Engine-Befehlszeile mit ihren Parametern angewandt wird. Somit wird für den aktuellen Zugriffsplan die Engine-Befehlszeile Row3 angewandt, welche besagt: Return LastMenge auf die Engine-Befehlskettenzeile Rowl anwenden, also die letzte Menge aus der Engine-Befehlskettenzeile Rowl liefern. Rowl enthält als Engine- Verarbeitungsfunktion ForChildren UseSetOfPrev*, welche wiederum festgelegt, dass eine Verarbeitungs-Eingangsmenge für diese Engine-Verarbeitungsfunktion entweder bereits festgelegt ist, oder von zumindest einer der eingesetzten * -Entscheidungspositionen für diesen zugehörigen RTN-Baustein, und somit für alle nachfolgenden Parameter, welche jeweils wiederum Engine-Befehlskettenzeilen aufrufen, festgelegt werden.

Die Engine-Befehlskettenzeile Rowl hat als Parameter „Row2" festgelegt, wodurch die Engine-Befehlskettenzeile Row2 angewandt wird. Diese Engine-Befehlskettenzeile Row2 führt die Engine-Verarbeitungsfunktion Get TableMenge mit den Parameter „TabelleA" aus. Die Engine-Verarbeitungsfunktion Get TableMenge benötigt und berücksichtigt keine Verarbeitungs-Eingangsmenge sondern liefert eine Verarbeitungs-Ausgangsmenge, und zwar jene Menge bzw. Tabelle, welche als Parameter festgelegt ist. Somit liefert die Engine- Verarbeitungsfunktion Get TableMenge mit dem Parameter „TabelleA" als Verarbeitungs- Ausgangsmenge die Tabelle TabelleA bzw. alle Datensätze derselben. Diese Verarbeitungs- Ausgangsmenge wird als aktuelle Verarbeitungs-Eingangsmenge der übergeordneten, aufrufenden Engine-Befehlskettenzeile Rowl festgelegt, welche keine weiteren Parameter vorschreibt. Somit wird zur Engine-Befehlskettenzeile Row3 zurückgekehrt, welche die aktuelle Verarbeitungs-Ausgangsmenge von Rowl wiederum als seine Verarbeitungs- Ausgangsmenge festlegt und somit als endgültiges Ergebnis dieser Engine-Befehlskettenzeile und somit als endgültiges Ergebnis dieses Zugriffsplans festlegt, wobei der Zugriffsplan isomorph zum Anwender-Statement ist.

Die einfache Angabe [ TabelleA ] wurde somit in diese endgültige Engine-Befehlskette umgewandelt und beschreibt, der Angabe entsprechend, dass alle Elemente der Tabelle TabelleA geliefert und ausgegeben werden sollen. Es können also alle Tabellenfelder der TabelleA ausgegeben werden.

Ein diesem Verfahren analog folgendes, einfaches Beispiel enthält die folgende Syntax:

Beispiel:

[ TabellenfeldA ]

Die endgültige Verschachtelung für dieses Beispiel mit den je Entscheidungsposition zugewiesenen Entscheidungspositions-Verarbeitungsinformationen sieht folgendermaßen aus:

^ForChildrenJJseSetOfPrev*⁰ * °ForCMdrenJJseSetOfPrev*° ] °GiveResultsToParenf TabellenfeldA°/;j#_7α6/eF;eW°

Die Zugriffsplan-Erstellung erfolgt nach dem oben gezeigten Verfahren, wobei der Verarbeitungs-Ausgangstyp des in den RTN-Baustein Ebenen eingesetzten RTN-Baustein Tabellenfeld der Verarbeitungs-Ausgangstyp „Tabellenfeld" ist. Somit wird für die letzte Entscheidungsposition im RTN-Baustein Ebenen für die Entscheidungspositions- Verarbeitungsinformation °GiveResultsToParent° in der Zuordnungstabelle nach folgendem Element gesucht:

EP-VI¹: GiveResultsToParent

EP-VI-E²:

VA-ETl³: Tabellenfeld VA-ET2⁴:

Das aufgefundene Element in der Zuordnungsmenge hat die Engine-Verarbeitungsfunktion Return Value zugewiesen und als Verarbeitungs-Ausgangstyp den Verarbeitungstyp „Value".

Somit ergibt sich nach Auflösung und Analyse der Syntax des Beispiels folgender endgültiger, weiter optimierbarer Zugriffsplan in Form einer Engine-Befehlskette:

Rowl ForChildren UseSetOfPrev* Parameter: Row2 Row2 Get TablefieldValue Parameter: TabellenfeldA

Row3 Return LastValue Parameter: Rowl

In diesem Zugriffsplan wird als Zwischenschritt ermittelt, dass das Tabellenfeld „TabellenfeldA" einer Tabelle zugehörig ist, beispielsweise der Tabelle „TabelleA". Die Engine-Befehlskettenzeile Row3 liefert somit für jeden Datensatz der Tabelle „TabelleA" die Spalte bzw. das Tabellenfeld „TabellenfeldA".

Es wird nun der anhand dieser zwei einfachen Beispiele ein Ausschnitt des gesamten Verfahrens zusammengefasst nochmals beschreiben.

Das Verfahren setzt bei einer endgültigen RTN-Baustein-Verschachtelung an, welche sich nach Anwendung des Auswahlschrittes auf ein Statement ergibt und bei welcher je Entscheidungsposition der einzelnen, in dieser Verschachtelung verwendeten RTN-Bausteine, gegebenenfalls zumindest eine Entscheidungspositions-Verarbeitungsinformation und gegebenenfalls eine Entscheidungspositions-Verarbeitungsinformations-Erweiterung zugeordnet ist. Diese endgültige Verschachtelung wird von außen nach innen durchlaufen, es wird also die erste Entscheidungsposition des äußersten RTN-Bausteins angesprochen von den Entscheidungspositionen einzeln gefolgt, wobei bei * -Entscheidungspositionen die eingesetzten RTN-Bausteine aufgerufen und durchlaufen werden. Wird eine *- Entscheidungsposition erfolgreich durchlaufen, wird ein Eintrag für die jeweils gesetzte oder nicht gesetzte Entscheidungspositions-Verarbeitungsinformation, Entscheidungspositions- Verarbeitungsinformations-Erweiterung, Verarbeitungs-Eingangstypl und Verarbeitungs- Eingangstyp2 in der Zuordnungstabelle gesucht. Gleiches gilt, sobald eine Entscheidungsposition erreicht wird, welche keine * -Entscheidungsposition darstellt.

Bei einer erreichten Entscheidungsposition wird geprüft, ob dieser eine Entscheidungspositions- Verarbeitungsinformation und/oder eine Entscheidungspositions- Verarbeitungsinformations-Erweiterung zugeordnet ist. Wird eine Entscheidungsposition erreicht, welche keine * -Entscheidungsposition ist, wird keinesfalls ein Verarbeitungs- Eingangstypl oder ein Verarbeitungs-Eingangstyp2 festgelegt. Es können vielmehr die Entscheidungspositions-Verarbeitungsinformationen in zwei Entscheidungspositions- Verarbeitungsinformations- Verarbeitungstypen-Gruppen unterteilt werden, wobei jene Entscheidungspositions-Verarbeitungsinformationen der ersten Entscheidungspositions- Verarbeitungsinformations-Verarbeitungstyp-Gruppe zugeordnet werden, welche bei Übersteuerung einer im gleichen RTN-Baustein bereits gesetzten Entscheidungspositions- Verarbeitungsinformation die beiden Verarbeitungs-Eingangstypl und Verarbeitungs- Eingangstyp2 unverändert lassen, der ersten Entscheidungspositions- Verarbeitungsinformations- Verarbeitungstyp-Gruppe zugeordnet werden, und jene Entscheidungspositions-Verarbeitungsinformationen, die sowohl den Verarbeitungs- Eingangstypl als auch den Verarbeitungs-Eingangstyp2 zurücksetzen, der zweiten Entscheidungspositions-Verarbeitungsinformations-Verarbeitungstyp-Gruppe zugeordnet werden.

Es wird festgelegt, dass alle Entscheidungspositions- Verarbeitungsinformationen der ersten Entscheidungspositions-Verarbeitungsinformations-Verarbeitungstypen-Gruppe angehören, sofern diese nicht explizit der zweiten Entscheidungspositions- Verarbeitungsinformations- Verarbeitungstypen-Gruppe zugeordnet ist. Dies wird vorweggenommen, um die Übersichtlichkeit in der Beschreibung zu erhöhen.

Sobald eine Entscheidungsposition erfolgreich durchlaufen wird, als eine Entscheidungsposition erreicht wird, welche keine * -Entscheidungsposition darstellt, oder eine *-Entscheidungsposition den in diese eingesetzten RTN-Baustein, welcher gegebenenfalls wiederum eine * -Entscheidungsposition enthält und an dieser daher zumindest wiederum einen RTN-Baustein eingesetzt und durchlaufen hat, erfolgreich durchlaufen hat, wird für die gegebenenfalls festgelegte Entscheidungspositions-Verarbeitungsinformation, für die gegebenenfalls festgelegte Entscheidungspositions- Verarbeitungsinformations- Erweiterung und für die gegebenenfalls festgelegten Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 ein entsprechender Eintrag in der Zuordnungstabelle gesucht. Wird ein Eintrag in dieser Zuordnungstabelle gefunden, wird die Spalte RTN-Baustein- Verschachtelung-Kommunizierer (VS-Kom ) ausgewertet. Eine Auswertung dieser Spalte wird nachfolgend immer detailreicher gezeigt, es wird an dieser Stelle nur auf zwei mögliche Fälle eingegangen und erwähnt, dass in Abhängigkeit des Wertes dieser Spalte entweder eine neue Engine-Befehlskettenzeile angelegt wird, und/oder eine vorhandene Engine- Befehlskettenzeile verändert bzw. um Parameter erweitert wird oder diese verändert werden. In jenen Fällen, in denen diese Spalte VS-Kom⁷ keinen Wert enthält, wird eine neue Engine- Befehlskettenzeile angelegt, welche die Engine- Verarbeitungsfunktion festlegt, die in der Spalte Engine-Verarbeitungsfunktion Eng- V A⁵ der Zuordnungstabelle angeben ist. Sofern ein Eintrag in der Zuordnungstabelle aufgefunden wurde, wird weiters ein Verarbeitungs- Ausgangstyp in dieser Zuordnungstabelle aufgefunden, welcher entweder als Verarbeitungs- Eingangstypl oder als Verarbeitungs-Eingangstyp2 des in der Verschachtelung aktuellen RTN-Bausteins festgelegt wird, wobei diese Festlegung nach folgender Regel erfolgt:

Ist für einen RTN-Baustein keine Verarbeitungs-Eingangstypl festgelegt, wird als Verarbeitungs-Eingangstypl jene Verarbeitungstyp festgelegt, der in der Zuordnungstabelle für das aufgefundene Element als Verarbeitungs- Ausgangstyp V-AT⁶ definiert ist. Ist für einen aktuellen RTN-Baustein bereits ein Verarbeitungs-Eingangstypl festgelegt, wird der Verarbeitungs-Eingangstyp2 auf den Verarbeitungs-Ausgangstyp V-AT gesetzt. In beiden Fällen wird, sofern vorhanden, die nächste Entscheidungsposition des Entscheidungspfades des jeweils aktuellen RTN-Bausteins betreten und der Schritt mit den neuen Werten wird wiederholt. Dies geschieht solange, bis die letzte Entscheidungsposition des äußerten RTN- Baustein durchlaufen wurde, oder bis ein Element in der Zuordnungsmenge erreicht wird, welches festlegt, dass die in der Syntax angegebene Befehlsfolge, welche sich in der Verschachtelung widerspiegelt, syntaktisch zulässig aber für einen Zugriffsplan nicht zulässig ist.

Wird eine * -Entscheidungsposition erreicht und erfolgreich durchlaufen, liefert diese einen, von den im eingesetzten RTN-Baustein erreichten Entscheidungspositionen abhängigen, Verarbeitungs-Ausgangstyp zurück, welcher in dem diese *-Entscheidungsposition enthaltenden RTN-Baustein genau dann als aktueller Verarbeitungs-Eingangstypl festgelegt wird, wenn der Verarbeitungs-Eingangstypl dieses RTN-Bausteins an dieser Entscheidungsposition nicht gesetzt ist. Dies gilt auch, wenn vorher ein Verarbeitungs- Eingangstypl gesetzt war, dieser aber an einer vorhergehenden Entscheidungsposition entfernt wurde. Ist im diese *-Entscheidungsposition enthaltenden RTN-Baustein der Verarbeitungs-Eingangstypl bereits gesetzt, wird der Verarbeitungs-Ausgangstyp des an der * -Entscheidungsposition eingesetzten RTN-Bausteins als Verarbeitungs-Eingangstyp2 desselben gesetzt. Es kann vorkommen, dass ein Verarbeitungs-Ausgangstyp für ein aufgefundenes Element in der Zuordnungsmenge nicht gesetzt ist. In diesen Fällen wird der Wert entweder des Verarbeitungs-Eingangstypl oder des Verarbeitungs-Eingangstyp2 auf nicht vorhanden gesetzt.

Nachdem eine * -Entscheidungsposition in einem RTN-Baustein durchlaufen wurde und somit entweder kein Verarbeitungs-Eingangstypl, ein Verarbeitungs-Eingangstypl und gegebenenfalls ein Verarbeitungs-Eingangstyp2 zur Verfügung steht, wird für die aktuelle Entscheidungspositions-Verarbeitungsinformation ein zugehöriger Eintrag wie beschrieben in der Zuordnungstabelle gesucht. Wird ein Eintrag in der Zuordnungstabelle gefunden, erfolgt die Auswertung der Spalte RTN-Baustein-Verschachtelung-Kommunizierer (VS-Kom⁷), wodurch entweder eine neue Engine-Befehlskettenzeile angelegt wird und/oder Parameter einer vorhandenen Engine-Befehlskettenzeile verändert bzw. angepasst werden. Die Spalte VS-Kom⁷ hat entweder Einfluss auf eine Engine-Befehlskettenzeile des aktuellen RTN- Bausteins oder auf eine Engine-Befehlskettenzeile eines über- oder untergeordneten RTN- Bausteins. Dies wird nachfolgend anhand von Beispielen gezeigt.

Weiters gilt, dass das Schlüsselwort jeder Nicht-*-Entscheidungsposition eines RTN- Bausteins, welches in der Menge der reservierten Schlüsselworte, also in der Menge der Schlüsselwort, welche für definierte Schlüsselwort-Entscheidungspositionen in Entscheidungsgraphen von zumindest einem RTN-Baustein vorkommen und daher variable Schlüsselwort wie z.B. Tabellennamen, Tabellenfeldnamen, variable Werte, Systemfunktionen oder extern definierte Funktionen sind, als Parameter für eine Engine- Verarbeitungsfunktion im Zugriffsplan herangezogen wird. Hier gilt ebenfalls, dass die Spalte VS-Kom⁷ in der Zuordnungstabelle festlegt, für welche Engine-Befehlskettenzeile diese Schlüsselwort als Parameter festgelegt wird.

Jeder RTN-Baustein, der zumindest eine Engine-Befehlskettenzeile im Zugriffsplan anlegt, merkt sich eine Engine-Befehlskettenzeile als seine aktuelle Engine-Befehlskettenzeile. In jenen Fällen, in denen mehrere Engine-Befehlskettenzeilen in einem RTN-Baustein angelegt werden, erfolgt die Festlegung einer jeweils aktuellen Engine-Befehlskettenzeile ebenfalls über die Spalte VS-Kom⁷ des jeweils aufgefundenen Elements in der Zuordnungstabelle. Jeder RTN-Baustein, welcher in einer endgültigen RTN-Baustein-Verschachtelung an einer *- Entscheidungsposition eingesetzt und im Zugriffsplan-Erstellungsschritt durchlaufen wird, liefert seinem direkt übergeordneten eine Engine-Befehlskettenzeile zurück. Dieser jeweils übergeordnete RTN-Baustein fügt diese zurückgelieferte Engine-Befehlskettenzeile seiner aktuellen Engine-Befehlskettenzeile an, sofern nicht in der Spalte VS-Kom⁷ in Wert gespeichert ist, welcher etwas anderes vorschreibt. Die Spalte VS-Kom eines aufgefundenen Elements in der Zuordnungstabelle entscheidet ebenfalls, welcher der gegebenenfalls mehreren Engine-Befehlskettenzeilen, die in einem RTN-Baustein erstellt und dem aktuellen Zugriffsplan hinzugefügt wurden, diese zurückgelieferte Engine-Befehlskettenzeile des eingesetzten RTN-Bausteins angefügt wird.

Es ist ebenso möglich, dass aufgrund eines Wertes in der Spalte VS-Kom⁷ der Zuordnungstabelle für ein aufgefundenes Element festgelegt wird, dass eine durch eine Entscheidungsposition, welche keine * -Entscheidungsposition darstellt, erstellte Engine- Befehlskettenzeile eines RTN-Bausteins als gegebenenfalls zusätzlicher Parameter für eine Engine-Befehlskettenzeile festgelegt wird.

Um dies zu verdeutlichen, wird nochmals der RTN-Baustein Ebenen gezeigt: Dieser RTN- Baustein legt, wie in den beiden oberen Beispielen zur Zugriffsplan-Erstellung gezeigt ist, immer genau zwei Engine-Befehlskettenzeilen an, wobei die beiden Engine- Befehlskettenzeilen jeweils von Entscheidungspositionen erstellt werden, welche beide keine * -Entscheidungspositionen sind. Im Konkreten sind es die beiden Entscheidungspositionen „Schlüsselwort [" und „Schlüsselwort ]". Die zweite vom RTN-Baustein Ebenen angelegte Engine-Befehlskettenzeile, unabhängig in welcher Verschachtelungstiefe dieser RTN- Baustein verwendet wird, nimmt aufgrund des Wertes der Spalte VS-Kom⁷ „ReturnLastParamOfFirstVA" immer die erste Engine-Befehlskettenzeile, die dieser RTN- Baustein anlegt, als Parameter.

Ein weiteres einfaches Beispiel zeigt dieses Verfahren, wobei der RTN-Baustein Ebenen drei * -Entscheidungspositionen enthält, aber dem oben beschriebenen Verfahren fogt:

Beispiel: [ TabelleA TabelleB TabelleC ]

Die endgültige RTN-Baustein- Verschachtelung dieses Beispiels wird gezeigt: Es ist zu sehen, dass die Entscheidungspositions- Verarbeitungsinformation °ForChildren_UseSetOfl^>rev*°, welche bei der ersten Entscheidungsposition „Schlüsselwort [" des RTN-Bausteins Ebenen festgelegt wird, für alle nachfolgenden Entscheidungspositionen gilt, bis diese Entscheidungspositions-Verarbeitungsinformation bei der Entscheidungsposition „Schlüsselwort ]" mit der Entscheidungspositions-Verarbeitungsinformation °GiveResultsToParent° übersteuert wird. Somit gelten für alle drei *-Entscheidungspositionen des RTN-Bausteins Ebenen jeweils die Entscheidungspositions-Verarbeitungsinformation °ForChildren_UseSetOflPrev*°.

*(\)°ForChildrenJJseSetOfPrev*° *{2)°ForChildrenJJseSetOfPrev*° * (3 ) °ForChüdrenJJseSetOfPrev * ° ] °GiveResultsToParent°

(1) TabelleA°/HzY_7aWe^o (2) TabelleB ⁰MtJaUe⁰

(3) TabelleC°/mχ_7αWe°

Es wird die erste Entscheidungsposition des äußersten RTN-Bausteins Ebenen angesprochen und festgestellt, dass es sich um keine * -Entscheidungsposition handelt. Dieser ersten Entscheidungsposition ist eine Entscheidungspositions-Verarbeitungshiformation °ForChϊldren_ UseSetOfPrev*° zugeordnet, wobei an ersten Entscheidungsposition für den RTN-Baustein Ebenen keine Entscheidungspositions-Verarbeitungsinformations- Erweiterung, keine Verarbeitungs-Eingangstypl und keine Verarbeitungs-Eingangstyp2 zugeordnet sind. Es wird für diese Werte ein Eintrag in der Zuordnungstabelle gesucht und gefunden. Dieser aufgefundene Eintrag legt die Engine-Verarbeitungsfunktion ForChildren UseSetOfPrev* fest und diese wird als erste Engine-Befehlskettenzeile ohne Parameter angelegt.

Somit ergibt sich nach diesem ersten Schritt folgender Zugriffsplan:

Rowl ForChildren UseSetOfPrev* kein Parameter Das aufgefundene Element in der Zuordnungsmenge legt keinen Verarbeitungs-Ausgangstyp fest, womit für die nachfolgende, zweite Entscheidungsposition weiterhin kein Verarbeitungs- Eingangstypl und kein Verarbeitungs-Eingangstyp2 festgelegt sind.

Für den RTN-Baustein Ebenen wird Rowl als aktuelle Engine-Befehlskettenzeile festgelegt und es wird die zweite Entscheidungsposition des für diese RTN-B austein-Verschachtelung gewählten Entscheidungspfades durchlaufen.

Diese zweite Entscheidungsposition ist eine * -Entscheidungsposition, weshalb der in diese eingesetzte RTN-Baustein Tabellen aufgerufen und von seiner ersten Entscheidungsposition an durchlaufen wird. Die erste Entscheidungsposition dieses RTN-Baustein „Schlüsselwort TabelleA" hat die Entscheidungspositions-Verarbeitungsinformation °InitJTable° zugeordnet, für welche ein entsprechender Eintrag in der Zuordnungstabelle identifiziert wird. Der identifizierte Eintrag in der Zuordnungstabelle schreibt die Engine-Verarbeitungsfunktion Get TableMenge vor und liefert als Verarbeitungs-Ausgangstyp „Menge". Somit wird für diese Entscheidungsposition des RTN-Bausteins Tabellen eine neue Engine- Befehlskettenzeile Row2 im Zugriffsplan erstellt und diese wird als aktuelle Engine- Befehlskettenzeile für den RTN-Baustein Tabellen festgelegt. Da die erste Entscheidungsposition „Schlüsselwort TabelleA" keine * -Entscheidungsposition ist und ein Schlüsselwort enthält, welches nicht in der Menge der reservierten Entscheidungspositions- Schlüsselworte vorkommt und daher ein variables Schlüsselwort ist, den Wert „TabelleA" als Parameter verwendet. Da in der Spalte VS-Kom⁷ für das aufgefundene Element kein- Wert eingetragen ist, wird das Schlüsselwort „TabelleA" der neu angelegten Engine- Befehlskettenzeile Row2 hinzugefügt.

Somit ergibt sich nach diesem ersten Schritt folgender Zugriffsplan:

Rowl ForChildren UseSetOfPrev* kein Parameter

Row2 Get TableMenge Parameter: TabelleA

Da der RTN-Baustein Tabellen in der Verschachtelung aus nur eine Entscheidungsposition besteht, ist dieser RTN-Baustein erfolgreich durchlaufen und die zweite Entscheidungsposition des aufrufenden, übergeordneten RTN-Bausteins Ebenen ist damit erfolgreich durchlaufen. Der RTN-Baustein Tabellen legt aufgrund der Zuordnungstabelle den Verarbeitungs-Ausgangstyp „Menge" fest, welcher im RTN-Baustein Ebenen für die zweite Entscheidungsposition als Verarbeitungs-Eingangstypl festgelegt wird. Im nächsten Schritt wird der Eintrag in der Zuordnungstabelle gesucht, welche die Entscheidungspositions-Verarbeitungsinformation °ForChildrenJJseSetOflPrev*° und als Verarbeitungs-Eingangstypl „Menge" enthält. In der Zuordnungstabelle wird kein solcher Eintrag gefunden, als aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen ist daher weiterhin Rowl festgelegt. Dieser aktuellen Engine-Befehlskettenzeile Rowl wird als Parameter die aktuelle Engine-Befehlskettenzeile Row2 des an der zweiten Entscheidungsposition eingesetzten RTN-Bausteins Tabelle angefügt, wodurch sich folgender Zugriffsplan ergibt:

Rowl ForChildren UseSetOfPrev* Parameter: Row2

Row2 Get TableMenge Parameter: Tabellen

Es wird die nächste, dritte Entscheidungsposition des RTN-Bausteins Ebenen durchlaufen, welche wiederum eine *-Entscheidungsposition ist und in welcher ebenfalls ein RTN- Baustein Tabellen eingesetzt ist. Es wird in oben gezeigter Weise ein Eintrag in der Zuordnungstabelle identifiziert und eine weitere Engine-Befehlskettenzeile Row3 angelegt, welche damit als aktuelle Engine-Befehlskettenzeile des aktuellen RTN-Bausteins Tabellen gilt. Dieser eingesetzte RTN-Baustein Ebenen hat als erstes Schlüsselwort „TabelleB", welches ebenfalls nicht in der Menge der reservierten Schlüsselworte aufgefunden wird und daher als Parameter der aktuellen Engine-Befehlskettenzeile hinzugefügt wird. Dies ergibt nach diesem Schritt folgenden neuen Zugriffsplan:

Rowl ForChildren UseSetOfPrev* Parameter: Row2

Row2 Get TableMenge Parameter: TabelleA

Row3 Get TableMenge Parameter: TabelleB

Der in den RTN-Baustein an der dritten Entscheidungsposition eingesetzte RTN-Baustein Tabellen ist damit erfolgreich durchlaufen, womit die dritte Entscheidungsposition des RTN- Bausteins Ebenen ebenfalls erfolgreich durchlaufen ist. Da die dritten Entscheidungsposition des RTN-Bausteins eine *-Entscheidungsposition war und diese den Verarbeitungs- Ausgangstyp „Menge" liefert, wird geprüft, ob der Verarbeitungs-Eingangstypl an der dritten Entscheidungsposition des RTN-B austeins Ebenen gesetzt ist. Dies ist der Fall, womit der Verarbeitungs-Eingangstyp2 des RTN-Bausteins Ebenen an dieser dritten Entscheidungsposition auf den Wert „Menge" gesetzt wird. Nun wird in der Zuordnungstabelle ein Element gesucht, welches folgende Werte in den jeweiligen Spalten enthält:

EP-VI¹ : °ForChildrenJJseSetOfPrev*° EP-VI-E²: VA-ETl³: Menge

VA-ET2⁴: Menge

In der Zuordnungstabelle wird kein entsprechender Eintrag gefunden, weshalb ein weiterer Schritt ausgeführt wird, der folgendermaßen aussieht:

In jeden Fällen, in denen an einer Entscheidungsposition eine Entscheidungspositions- Verarbeitungsinformation und gegebenenfalls eine Entscheidungspositions- Verarbeitungsinformations-Erweiterung und ein jedenfalls ein Verarbeitungs-Eingangstypl und ein Verarbeitungs-Eingangstyp2 vorhanden sind, aber kein entsprechender Eintrag in der Zuordnungstabelle aufgefunden wird, wird der aktuelle Wert des Verarbeitungs-Eingangstypl auf den aktuellen Wert des Verarbeitungs-Eingangstyp2 gesetzt und der Wert Verarbeitungs- Eingangstyp2 wird auf nicht vorhanden gesetzt. Danach wird erneut ein Eintrag in der Zuordnungstabelle gesucht, welcher die aktuelle Entscheidungspositions- Verarbeitungsinformation, die gegebenenfalls gesetzte Entscheidungspositions- Verarbeitungsinformations-Erweiterung, den neu gesetzten Verarbeitungs-Eingangstypl und kein Verarbeitungs-Eingangstyp2 enthält. Wird weiterhin kein Eintrag in der Zuordnungstabelle gefunden, bleiben diese Werteänderungen für die nachfolgende Entscheidungsposition bestehen und es wird das Verfahren in beschriebener Weise fortgesetzt. Wird ein Eintag für diesen nunmehr einen Verarbeitungs-Eingangstypl gefunden, wird die Spalte VS-Kom⁷ ausgewertet und neue Engine-Befehlskettenzeile mit zugehöriger Engine-Verarbeitungsfunktion erstellt und/oder die Parameter einer Engine- Befehlskettenzeile werden verändert bzw. erweitert. In jeden Fällen, in denen an einer Entscheidungsposition eine Entscheidungspositions- Verarbeitungsinformation und gegebenenfalls eine Entscheidungspositions- Verarbeitungsinformations-Erweiterung und ein jedenfalls ein Verarbeitungs-Eingangstypl und ein Verarbeitungs-Eingangstyp2 vorhanden sind und ein Eintrag in der Zuordnungstabelle aufgefunden wird, wird Spalte VS-Kom⁷ ausgewertet und neue Engine- Befehlskettenzeile mit zugehöriger Engine-Verarbeitoigsfunktion erstellt und/oder die Parameter einer Engine-Befehlskettenzeile werden verändert bzw. erweitert. Danach wird der Verarbeitungs-Eingangstypl auf den Wert der Spalte Verarbeitungs-Ausgangstyp VA-AT⁶ gesetzt und der Wert des Verarbeitungs-Eingangstyp2 auf nicht vorhanden gesetzt. Danach wird das Verfahren für die nachfolgenden Entscheidungsposition in gezeigter Weise weitergeführt. Hierfür finden sich in der Beschreibung nachfolgend Beispiele.

Da für das momentan gezeigte Beispiel in der Zuordnungstabelle kein Eintrag für die beiden Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 gefunden wurde, bedeutet dies, dass der Wert Verarbeitungs-Eingangstypl auf den Wert von Verarbeitungs-Eingangstyp2 und der Verarbeitungs-Eingangstyp2 auf nicht vorhanden gesetzt wird. Somit wird der ursprüngliche Wert von Verarbeitungs-Eingangstypl „Menge" mit dem Wert von Verarbeitungs-Eingangstyp2 überschrieben, welcher im Konkreten ebenfalls „Menge" ist und es wird ein Eintrag in der Zuordnungstabelle für die Entscheidungspositions- Verarbeitungsinfoπnation °ForChildrenJJseSetOfPrev*° und den Verarbeitungs- Eingangstypl „Menge" gesucht. Es wird weiterhin kein Eintrag in der Zuordnungstabelle gefunden, womit die aktuelle Engine-Befehlskettenzeile Row3 des zuletzt eingesetzten und durchlaufenen RTN-Bausteins Tabellen als Parameter für die aktuelle Engine- Befehlskettenzeile Rowl des RTN-Bausteins Ebenen hinzugefügt wird.

Dies ergibt nach diesem Schritt folgenden neuen Zugriffsplan:

Rowl ForChildren UseSetOfPrev* Parameter: Row2, Row3

Row2 Get TableMenge Parameter: Tabellen Ro w3 Get TableMenge Parameter: TabelleB

Es wird die nächste Entscheidungsposition(4) im RTN-Baustein Ebenen durchlaufen, welche wiederum ein RTN-Baustein Tabellen mit dem der einzigen Entscheidungsposition zugeordneten Schlüsselwort „TabelleC" ist. Es wird wie oben beschrieben verfahren, indem entsprechende Einträge in der Zuordnungstabelle gesucht und teilweise aufgefunden werden. Ebenso wird im Zugriffsplan eine weitere Engine-Befehlskettenzeile Row4 angelegt und diese als Parameter für die Engine-Befehlskettenzeile Rowl hinzugefügt, wodurch sich folgender Zugriffsplan ergibt:

Rowl ForChildren UseSetOfPrev* Parameter: Row2, Row3, Row4

Row2 Get TableMenge Parameter: Tabellen

Row3 Get TableMenge Parameter: TabelleB Row4 Get TableMenge Parameter: TabelleC

Im nächsten Schritt wird die nächste Entscheidungsposition(5) des aktuellen RTN-Bausteins Ebenen durchlaufen, welche das Schlüsselwort „]" enthält und eine Entscheidungspositions- Verarbeitungsinformation °GiveResultsToParent° festlegt. Das Schlüsselwort „]" ist eines der reservierten RTN-Baustein-Schlüsselworte und dieses wird daher nicht als Parameter verwendet.

An dieser Entscheidungsposition(5) ist weiterhin ein Verarbeitungs-Eingangstypl mit dem Wert „Menge" und kein Verarbeitungs-Eingangstyp2 gesetzt. Die Entscheidungspositions- Verarbeitungsinformation °GiveResultsToParent° gehört der ersten Entscheidungspositions- Verarbeitungsinformations- Verarbeitungstyp-Gruppe an, weshalb diese beiden Verarbeitungs-Eingangstypen unverändert bleiben und nicht zurückgesetzt werden. Es wird nun ein Element in der Zuordnungstabelle (Zuordnungsmenge) gesucht, welches die Entscheidungspositions-Verarbeitungsinformation °GiveResultsToParent° und den Verarbeitungs-Eingangstypl „Menge" vorschreibt. Ein solches Element wird in der Zuordnungstabelle gefunden und es wird somit entsprechend ausgewertet. Es wird festgestellt, dass in der Spalte VS-Kom⁷ der Wert „ReturnLastParamOfFirstVA" eingetragen ist. Durch diesen Wert wird festgelegt, dass eine neue Engine-Befehlskettenzeile Row5 erstellt und dem Zugriffsplan hinzugefügt wird. Diese Engine-Befehlskettenzeile legt die Engine-Verarbeitungsfunktion Return LastMenge fest und bekommt aufgrund des Wertes „ReturnLastParamOfFirstVA" in der Spalte VS-Kom⁷ als Parameter die vorher aktuelle Engine-Befehlskettenzeile desselben RTN-Bausteins zugewiesen. Die vorher aktuelle Engine- Befehlskettenzeile des äußersten RTN-Bausteins Ebenen ist Rowl, die nunmehr aktuelle Engine-Befehlskettenzeile ist Row5. Somit bekommt Row5 als Parameter Rowl zugewiesen und es besteht ein gegebenenfalls weiter optimierbarer Zugriffsplan für die im Beispiel angegebene Syntax [ TabelleA TabelleB TabelleC ] , der hier gezeigt ist:

Rowl ForChildren UseSetOfPrev* Parameter: Row2, Row3, Row4

Row2 Get TableMenεe Parameter: TabelleA

Row3 Get TableMenεe Parameter: TabelleB

Row4 Get TableMenge Parameter: TabelleC

Row5 Retum LastMenε _e_ Parameter: Rowl

Eine Ausführung dieses Zugriffsplans erfolgt, indem die letzte Engine-Befehlskettenzeile aufgerufen und ausgeführt wird. So wird Row5 ausgeführt, welche einen Verweis auf die Rowl ausführt und deren Engine-Verarbeitungsfunktion besagt, dass die letzte Menge dieser Engine-Befehlskettenzeile, also jene Menge, die der letzte Parameter liefert, zurückgeliefert werden soll. In der Engine-Befehlskettenzeile Rowl findet sich eine Auflistung jeder nacheinander auszuführenden Engine-Befehlskettenzeilen, wobei gilt, dass die zurückgelieferte Verarbeitungs-Ausgangsmenge einer ausgeführten Engine- Befehlskettenzeile jeweils die Verarbeitungs-Eingangsmenge für die nächste auszuführende Engine-Befehlskettenzeile ist.

Die Engine-Verarbeitungsfunktion ForChildren UseSetOfPrev* kann erkennen, dass sämtliche Engine-Befehlskettenzeilen Tabellen darstellen und könnte somit ein kartesisches Produkt liefern. Es wäre auch möglich, dass dem Benutzer automatisch mehrere Antwortmöglichkeiten geboten werden, welche entweder die Bildung eines kartesischen Produktes bewirken würden oder beispielsweise nur jene Datensätze auswählen und zurückliefern würden, welche in allen drei Tabellen vorkommen. Dem Fachmann steht es offen, weitere Deutungsmöglichkeiten für diesen und alle ähnlichen Fälle zuzulassen und diese entsprechend zu implementieren. Es ist jedenfalls gewährleistet, dass ein Zugriffsplan vorliegt, welche immer die gleiche Struktur aufweist, wodurch ein Problem einmal gelöst und somit für sämtliche Fälle unabhängig von deren Kombination und Verschachtelungen gilt.

Ein weiteres Beispiel zeigt eine Möglichkeit, in der Zuordnungstabelle sowohl einen Verarbeitungs-Eingangstypl als auch einen Verarbeitungs-Eingangstyp2 aufzufinden und somit eine weitere Engine-Befehlskettenzeile mit einer zugehörigen Engine- Verarbeitungsfunktion festzulegen.

Beispiel: [ 3 TabelleA ]

Die zugehörige RTN-Baustein-Verschachtelung mit entsprechenden Entscheidungspositions- Verarbeitungsinformationen je Entscheidungsposition wird dargestellt:

[°ForChildren_UseSetOfPrev*° RTN-Baustein: Ebenen

*(\)^aForChildrenJJseSetOfPrev*°

*(2)°ForChildren_UseSetOfPrev*°

] °GiveResultsToParent°

(1) 3 °Init_Wert° RTN-Baustein: Variable (2) TabelleA°/«&_jrαWe^o RTN-Baustein: Tabellen

Es bleibt dem Fachmann überlassen, dem Anwender eine oder mehrere Deutungen für dieses

Beispiel zur Verfügung zu stellen. Folgende möglichen, kontextsensitiven Deutungen werden vorgeschlagen: ist:

Liefere die ersten drei Datensätze aus der TabelleA

Liefere den dritten Datensatz aus der TabelleA

Liefere alle Datensätze der TabelleA, wenn diese genau, zumindest oder maximal drei

Datensätze beinhaltet.

Um aus dieser angegebenen Syntax einen Zugriffsplan zu erstellen, wird ein neuer möglicher

Wert für die Spalte VS-Kom⁷ definiert und es werden in der Zuordnungstabelle weitere

Datensätze angelegt:

Weiterer möglicher Wert für die Spalte „RTN-Baustein- Verschachtelung-Kommunizierer" VS-Kom⁷: CreateNewRowAndAddToCurRow_ChangeParamOrder

Weiter Einträge in der Zuordnungstabelle:

Die Syntax wird nach dem oben gezeigten, erfindungsgemäßen Verfahren analysiert, wie es zusammengefasst nochmals gezeigt wird:

[°ForChildren_UseSetOfPrev*° RTN-Baustein: Ebenen

Aktuelle Entscheidungsposition RTN-Baustein Ebenen: erste Entscheidungsposition „Schlüsselwort ["

-> Suche Eintrag in Zuordnungstabelle: EP-VI¹: ForChildrenJJsePrev*

EP-VI-E²:

VA-ETl³:

VA-ET2⁴: Eintag gefunden: E-VA⁵: ForChildren UsePrev*

VA-AT⁶:

VS-Kom⁷: Angelegte Engine-Befehlskettenzeile:

Rowl: ForChildren UseSetOfPrev* kein Parameter Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen:

Rowl

Aktuelle Verarbeirungs-Eingangstypen: Verarbeitungs-Eingangstypl : kein - da kein Wert in VA-AT⁶ gesetzt Verarbeitungs-Eingangstyp2: kein wird für den aktuellen RTN-Baustein immer zurückgesetzt, wenn

Eintrag in Zuordnungstabelle gefunden wird

*{\)⁰ForChildren_UseSetOfPrev*°

*-Entscheidungsposition -> eingesetzten RTN-Baustein(l) aufrufen und durchlaufen

(Vß°Init_Wert° RTN-Baustein: Variable -> Suche Eintrag in Zuordnungstabelle:

EP-VI¹: Init_Wert

EP-VI-E²:

VA-ETl³:

VA-ET2⁴:

Eintag gefunden:

E-VA⁵: Get Value

VA-AT⁶: Value

VS-Kom⁷:

Angelegte Engine-Befehlskettenzeile: Row2: Get Value Parameter: 3

Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen:

Row2 Aktuelle Verarbeitungs-Eingangstypen:

Verarbeitungs-Eingangstypl: Value Verarbeirungs-Eingangstyp2: kein

RTN-Baustein (l)Variable durchlaufen -> Zurückgelieferte Werte: Engine-Befehlskettenzeile eingesetzter RTN-Baustein(l): Row2 Verarbeitungs-Ausgangstyp eingesetzter RTN-Baustein(l): Value

Aktuelle Entscheidungsposition RTN-Baustein Ebenen: zweite Entscheidungsposition *(1)

Verarbeitungs-Eingangstypl nicht gesetzt -> Verarbeitungs-Eingangstypl = Verarbeitungs-Ausgangstyp -> Suche Eintrag in Zuordnungstabelle:

EP-VI¹: ForChildrenJJsePrev*

EP-VI-E²: VA-ETl³: Value

VA-ET2⁴:

Kein Eintrag in der Zuordnungstabelle gefunden

-> Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 bleiben unverändert -> da aktuelle Entscheidungsposition ist *-Entscheidungsposition: Gelieferte Engine-Befehlskettenzeile des eingesetzten RTN-Bausteins (l)Variable Parameter zur aktuellen Engine-Befehlskettenzeile des RTN-Bausteins anfügen:

Erweiterter Engine-Befehlskettenzeile: Rowl: ForChildren UseSetOfPrev* Parameter: Row2

Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen: Rowl

*(2)°ForChildren_ UseSetOfPrev*⁰

^♦-Entscheidungsposition -> eingesetzten RTN-Baustein(2) aufrufen und durchlaufen

(l)TabeIleA^o//HΪ_rαWe° RTN-Baustein: Tabellen

-> Suche Eintrag in Zuordnungstabelle:

EP-VI¹: InitJTable

EP-VI-E²:

VA-ETl³:

VA-ET2⁴:

Eintag gefunden:

E-VA⁵: Get TableMenεe

VA-AT⁶: Menεe

VS-Kom⁷: Angelegte Engine-Befehlskettenzeile:

Row3: Get TableMenge Parameter: TabelleA Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen:

Row3 Aktuelle Verarbeitungs-Eingangstypen:

Verarbeitungs-Eingangstypl: Menge Verarbeitungs-Eingangstyp2: kein

RTN-Baustein (2)Tabelle durchlaufen -> Zurückgelieferte Werte:

Engine-Befehlskettenzeile eingesetzter RTN-Baustein(2): Row3 Verarbeitungs-Ausgangstyp eingesetzter RTN-Bausteύi(2): Menge

Aktuelle Entscheidungsposition RTN-Baustein Ebenen: dritte Entscheidungsposition *(2) da aktuelle Entscheidungsposition ist *-Entscheidungsρosition: Verarbeitungstypen neu setzten

Verarbeitungs-Eingangstypl gesetzt -> Verarbeitungs-Eingangstyp2= Verarbeitungs-Ausgangstyp -> Suche Eintrag in Zuordnungstabelle:

EP-VI¹: ForChildrenJJsePrev* EP-VI-E²: VA-ETl³: Value

VA-ET2⁴: Menge

Mehrere Einträge in der Zuordnungstabelle gefunden:

E-VA⁵: SetOperation_AllElements_IFMinElementsExists SetOperation_FIRST

SETOPERATION FIRST VA-AT⁶: Menge

VS-Kom⁷: CreateNewRowAndAddToCurRow

-> automatische Nachfrage beim Anwender, welche Variante gewählt und weiterverarbeitet werden soll

Beispielsweise ausgewählte Variante des Anwenders: SETOPERATION FIRST

Wert in Spalte VS-Kom⁷ gesetzt -> auswerten und verarbeiten

-> neue Engine-Befehlskettenzeile Row4 hinzufügen -> Engine-Befehlskettenzeile Row4 setzt zwei Parameter:

Parameter 1: Gelieferte Engine-Befehlskettenzeile des eingesetzten RTN-Bausteins

1

Parameter2: letzter Parameter der aktuellen Engine-Befehlskettenzeile Rowl des aktuellen RTN-Bausteins Ebenen (2)Tabelle Angelegte Engine-Befehlskettenzeile:

Row4: SetOperation FIRST Parameter: Row3,Row2

-> letzen Parameter der aktuellen Engine-Befehlskettenzeile Rowl des RTN-Bausteins Ebenen entfernen und die neue angelegten Engine-Befehlskettenzeile Row4 als Parameter anfügen.

Veränderte Engine-Befehlskettenzeile:

Rowl: ForChildren UseSetOfPrev* Parameter: Row4

da Eintrag in der Zuordnungstabelle gefunden: Verarbeitungs-Eingangstypen neu setzen: Verarbeitungs-Eingangstypl= VA-AT⁶ des gefundenen Elements in der Zuordnungsmenge: Menge

Verarbeitungs-Eingangstyp2 wird auf „nicht vorhanden" gesetzt.

Eintrag in der Zuordnungstabelle gefunden -> Verarbeitungs-Eingangstypen neu setzten:

Verarbeitungs-Eingangstypl: VA-AT⁶ : Menge

Dritte Entscheidungsposition *(3) erfolgreich durchlaufen

Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen: Rowl

-> vierte Entscheidungsposition „Schlüsselwort ]" wird ausgewertet ]°GiveResultsToParent° Neue Entscheidungspositions-Verarbeitungsinformation wird an dieser Entscheidungsposition festgelegt -> Prüfen, ob diese neue Entscheidungspositions-Verarbeitungsinformation der ersten oder der zweiten Entscheidungspositions-Verarbeitungsinformations-Verarbeitungstypen-Gruppe angehört. GiveResultsToParent gehört der ersten Entscheidungspositions-Verarbeitungsinformations-

Verarbeitungstypen-Gruppe an

-> Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 bleiben unverändert und werden nicht zurückgesetzt

Suche Eintrag in Zuordnungstabelle:

EP-VI¹: -. GiveResultsToParent

EP-VI-E²:

VA-ETl³: Menge

VA-ET2⁴: Eintrag in der Zuordnungstabelle gefunden:

E-VA⁵: Return JLastMenge

VA-AT⁶: Menge

VS-Kom⁷: ReturnLastParamOfFirstVA

Wert in Spalte VS-Kom⁷ gesetzt -> auswerten und verarbeiten

-> neue Engine-Befehlskettenzeile Row5 hinzufügen

-> Engine-Befehlskettenzeile Row5 setzt einen Parameter:

Parameter 1: aktuelle Engine-Befehlskettenzeile Rowl des aktuellen RTN-Bausteins Ebenen

Angelegte Engine-Befehlskettenzeile:

Row5: Return LastMenge Parameter: Rowl

Die Wert ReturnLastParamOfFirstVA Spalte VS-Kom⁷ schreibt vor, dass die zuletzt angelegte Engine- Befehlskettenzeile als aktuelle Engine-Befehlskettenzeile des jeweils aktuellen Engine-Befehlskettenzeile herangezogen wird.

-> Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen: Row5

Vierte und letzte Entscheidungsposition des äußersten RTN-Bausteins Ebenen erfolgreich durchlaufen.

Somit ist die Analyse des Statements [ 3 TabelleA ] erfolgreich abgeschlossen und es steht folgender endgültiger Zugriffsplan zur Verfügung: Rowl ForChildren UseSetOfPrev* Parameter: ROM>4

Row2 Get_Value Parameter: 3

Row3 Get_TableMenge Parameter: Tabellen

Row4 SetOperation First Parameter: Row3,Row2 Row5 Return_LastMenge Parameter: Rowl

Die Engine- Verarbeitungsfunktion der Engine-Befehlskettenzeile Row4 ist abhängig von der Antwort, welche der Anwender auf die automatische Fragestellung liefert. Um dem Anwender eine leicht verständliche Frage zu ermöglichen, kann in der Zuordnungstabelle eine weitere Spalte angefügt werden, welche je zugehöriger Engine- Verarbeitungsfunktion einen aussagekräftigen Text enthält, der dem Anwender dann zur Auswahl gestellt wird. Es ist weiters zu beachten, dass in den Fällen, in welchen für eine Entscheidungspositions- Verarbeitungsinformation und jeweils gegebenenfalls vorhandene Entscheidungspositions- Verarbeirungsinformations-Erweiterung, Verarbeitungs-Eingangstypl und Verarbeitungs- Eingangstyp2 unterschiedliche Werte in der Spalten E-VA⁵, VA-AT⁶ und VS- Kom⁷gespeichert sein können, womit die weitere Erstellung des Zugriffsplans mitunter je Auswahl des Anwenders unterschiedlich fortgeführt wird. Weiter Deutungen für diese und sämtliche ähnliche Fälle können dem Anwender ermöglich werden, indem entsprechend weitere Zeilen in der Zuordnungstabelle angelegt werden.

Die Abarbeitung dieses Zugriffsplans erfolgt, wie bereits beschrieben, durch Aufruf der letzten Engine-Befehlskettenzeile Row5, welche als Parameter den Durchlauf der Engine- Befehlskettenzeile Rowl vorschreibt und die Menge, welcher der letzte Parameter derselben liefert, als seine Ergebnismenge zur Verfügung stellt und somit in Tabellenform ausgibt.

Die Engine-Befehlskettenzeile Rowl verlangt die Abarbeitung der Engine-Befehlskettenzeile Row4, welche aufgrund ihrer Engine- Verarbeitungsfunktion SetOperation FIRST besagt, dass aus der Menge des ersten Parameters, also die Elemente der Menge von Row3, welche die Tabelle Firmen enthält und zurückliefert, nur die Anzahl an Elementen, welche in Row2 genannt ist, also 3, zurückliefert.

Somit wurde das Beispiel [ 3 TabelleA ] in einen Zugriffsplan umgewandelt, welcher die ersten drei Elemente bzw. Datensätze der TabelleA ausgibt. Um die Analyse von angegebenen Statements schrittweise für weitere RTN-Bausteine und von diesen unabhängige Entscheidungspositions-Verarbeitungsinformationen zu zeigen, wird der RTN-Baustein Vergleich in nächsten Beispiel gezeigt:

Beispiel:

[ TabellenfeldA ]

Zuerst wird die endgültige diesen Beispiel zugehörige RTN-Baustein-Verschachtelung mit den jeweiligen Entscheidungspositionen zugeordneten Entscheidungspositions- Verarbeitungsinformationen gezeigt, wie sie durch das erfindungsgemäße Verfahren generiert wird:

] °GiveResultsToParent°

(1) *(2) =°Compare=° *(3)°Compare=°

(2) TabellenFeldA°/Hz£_raWeF;eW°

(3) 5°Init_Value°

In dieser zugehörigen RTN-Baustein-Verschachtelung wird eine Entscheidungspositions- Verarbeitungsinformation °Compare=° verwendet, für welche keine Elemente in der Zuordnungstabelle vorhanden sind. Deswegen werden zugehörige Elemente in die Zuordnungstabelle als einmaliger Teilschritt des Voreinstellungsschrittes eingetragen:

Der Vergleich von zwei Werten enthält immer die Engine-Verarbeitungsfunktion Bool_Value=, wodurch insbesondere bei mehreren Verarbeitungs-Typen, welche einen jeweils Wert enthalten, eine Mehrzahl an Elementen in die Zuordnungstabelle eintragen werden. Da dies für mehrere Entscheidungspositions-Verarbeitungsmformationen der Fall ist, wird folgender Schritt angewandt, um die Übersichtlichkeit in der Zuordnungstabelle für den Anwender zu erhöhen:

Es wird ein weiterer Verarbeitungs-Typ festgelegt, welcher die Auflistung der Werte „Value", „TableFieldValue", „AggregatedValue", „AggregatedBefore_Value",

AggregatedBefore_Menge" und „AggregateThisValue" enthält. Dieser Verarbeitungs-Typ wird als „Collection Values" bezeichnet und kann in der Zuordnungstabelle in den Spalten

Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 eingesetzt werden. Dieser

Verarbeitungs-Typ wird eingeführt, um die Übersichtlichkeit zu wahren und kann bei Verwendung beispielsweise automatisch ein eine Mehrzahl ein Eintragen in der

Zuordnungstabelle aufgeteilt werden.

Es können weitere Verarbeitungs-Typen definiert werden, welche entweder einen unabhängigen Verarbeitungstypen oder eine Sammlung vorhandener Verarbeitungstypen darstellen. Diese können je nach Bedarf in der Zuordnungstabelle Verwendung finden.

Somit reicht es, für die Entscheidungspositions-Verarbeitungsmformation Compare= ein Element in der Zuordnungstabelle anzulegen, welches wie folgt aussieht und die vorher eingetragenen Elemente für die Entscheidungspositions-Verarbeitungsinformationen Compare= ersetzt:

Es wird nun das erfindungsgemäße Verfahren angewandt, um für das angegebene Beispiel einen zugehörigen Zugriffsplan zu erstellen. Das Verfahren wird in der offenbarten Weise angewandt und wird daher hier nur in Kurzform beschrieben:

Es wird die erste Entscheidungsposition des äußersten RTN-Bausteins durchlaufen, welche die Entscheidungspositions-Verarbeitungsinformation °ForChildren_UseSetOfPrev*° festlegt und für welche ein Eintrag in der Zuordnungstabelle ohne Verarbeitungs-Eingangstypl und ohne Verarbeitungs-Eingangstyp2 gefunden wird. Somit wird eine erste Engine- Befehlskettenzeile Rowl erstellt und diese wird als aktuelle Engine-Befehlskettenzeile des äußersten RTN-Bausteins Ebenen festgelegt.

Rowl ForChildren UseSetOfPrev* kein Parameter

Es wird die zweite Entscheidungsposition des äußersten RTN-Bausteins Ebenen durchlaufen, welche eine * -Entscheidungsposition darstellt. Somit wird der an dieser *-

Entscheidungsposition *(1) eingesetzte RTN-Baustein Vergleich aufgerufen und durchlaufen.

Die erste Entscheidungsposition des eingesetzten RTN-Bausteins Vergleich ist ebenfalls eine * -Entscheidungsposition *(2). Da es die erste Entscheidungsposition des RTN-Bausteins ist, wird eine neune Engine-Befehlskettenzeile Row2 angelegt und diese wird als aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Vergleich festgelegt. Die Engine- Befehlskettenzeile Row2 hat noch keine Engine- Verarbeitungsfunktion zugewiesen, da diese Prüfung erst vorgenommen wird, wenn der an der * -Entscheidungsposition eingesetzte RTN- Baustein aufgerufen und durchlaufen ist.

Rowl ForChildren UseSetOfPrev* kein Parameter

Row2 keine Engine- Verarbeitungsfluiktion kein Parameter

Somit wird der an dieser * -Entscheidungsposition eingesetzte RTN-Bausteinen Tabellenfeld aufgerufen und durchlaufen. Der RTN-Baustein Tabellenfeld erstellt in bereits gezeigter Weise eine neue Engine- Befehlskettenzeile Row3 und liefert dem aufrufenden RTN-Baustein Row3 als aktuelle Engine-Befehlskettenzeile des eingesetzten RTN-Bausteins und als Verarbeitungs- Ausgangstyp Tabellenfeld des eingesetzten RTN-Bausteins „TableFieldValue" zurück.

Rowl ForChildren UseSetOfPrev* kein Parameter

Row2 keine Engine- Verarbeitungsfunktion kein Parameter

Row3 Get_TableFieldValue Parameter: TabellenFeldA

Für die erste Entscheidungsposition *(2) des RTN-Bausteins Vergleich wird kein Eintrag in der Zuordnungstabelle gesucht, da dieser Entscheidungsposition keine Entscheidungspositions- Verarbeitungsinformation zugeordnet ist.

Es wird der aktuellen Engine-Befehlskettenzeile des RTN-Bausteins Vergleich die aktuelle Engine-Befehlskettenzeile des eingesetzten RTN-Bausteins (2)Tabellenfeld als Parameter zugeordnet. Diese Zuordnung erfolgt immer, wenn eine * -Entscheidungsposition eingesetzt und durchlaufen ist, wobei der Spalten- Wert VS-Kom⁷ für ein aufgefundenes Element in der

Zuordnungsmenge festlegen kann, welcher Engine-Befehlskettenzeile des übergeordneten

RTN-Bausteins die aktuelle Engine-Befehlskettenzeile des eingesetzten RTN-Bausteins als Parameter an welcher Parameter-Position zugeordnet wird.

Rowl ForChildren UseSetOfPrev* kein Parameter

Row2 keine Engine- Verarbeitungsfunktion Parameter: Row3

Row3 Get TableFieldValue Parameter: TabellenFeldA

Der eingesetzte RTN-Baustein Tabellenfeld liefert als Verarbeitungs-Ausgangstyp „Tabellenfeld" zurück. Es wird geprüft, ob im übergeordneten RTN-Baustein Vergleich der Verarbeitungs-Eingangstypl gesetzt ist. Dieser ist nicht gesetzt, daher wird der Verarbeitungs-Eingangstypl auf den Wert der Verarbeitungs-Ausgangstyp „TableFieldValue" des eingesetzten RTN-Bausteins gesetzt.

Es wird die zweite Entscheidungsposition „Schlüsselwort =" im RTN-Baustein Vergleich durchlaufen, welche die Entscheidungspositions- Verarbeitungsinformation °Compare=° festlegt. Es wird festgestellt, dass die Entscheidungspositions-Verarbeitungsinformation °Compare=° der ersten Entscheidungspositions-Verarbeitungsinformations-

Verarbeitungstypen-Gruppe angehört, welche für ihrer Elemente besagt, dass die Werte von Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 unverändert bleiben. Da an dieser Entscheidungsposition eine Entscheidungspositions-Verarbeitungsinformation vorhanden ist, wird folgender Eintrag in der Zuordnungstabelle gesucht:

EP-VI¹: Comρare=

EP-VI-E²: VA-ETl³: TableFieldValue

VA-ET2⁴:

Es wird kein zugehöriger Eintrag in der Zuordnungstabelle gefunden. Da die zweite Entscheidungsposition eine Schlüsselwort-Entscheidungsposition ist, und das an dieser Entscheidungsposition enthaltene Schlüsselwort in der Menge der reservierten Entscheidungspositions-Schlüsselworte aufzufinden ist, wird an dieser Stelle der Zugriffsplan nicht verändert.

Es wird die dritte Entscheidungsposition des RTN-Bausteins Vergleich durchlaufen. Diese dritte Entscheidungsposition ist die * -Entscheidungsposition *(3). Somit wird der an dieser Entscheidungsposition eingesetzte RTN-Baustein Variable aufgerufen und in gezeigter Weise durchlaufen. Dieser RTN-Baustein legt eine weitere Engine-Befehlskettenzeile Row4 mit zugehöriger Engine-Verarbeitungsfunktion und Parameter an:

Rowl ForChildren UseSetOfPrev* kein Parameter

Row2 keine Engine-Verarbeitungsfunktion Parameter: Row3

Row3 Get_TableFieldValue Parameter: TabellenFeldA

Row4 GetJValue Parameter: 5

Der aufgerufene RTN-Baustein Variable ist nach seiner ersten und einzigen Entscheidungsposition durchlaufen und liefert seinem übergeordneten RTN-Baustein Vergleich folgende Werte: Aktuelle Engine-Befehlskettenzeile eingesetzter RTN-Baustein: Row5

Aktueller Verarbeitungs-Ausgangstyp eingesetzter RTN-Baustein: Value

Es wird im aufrufenden RTN-Baustein geprüft, die sein Verarbeitungs-Eingangstypl bereits gesetzt ist. Der Verarbeitungs-Eingangstypl ist gesetzt, womit Verarbeitungs-Eingangstyp2 den Wert des Verarbeitungs-Ausgangstyps „Value" des eingesetzten RTN-Bausteins zugewiesen bekommt.

Es wird nun ein Eintag in der Zuordnungstabelle für die aktuelle Entscheidungspositions- Verarbeitungsinformation °Compare=° des RTN-Bausteins Vergleich und für die beiden Verarbeitungs-Eingangstypl „TableFiedlValue" und Verarbeitungs-Eingangstyp2 „Value" gesucht. Ein zugehöriger Eintag wird in der Zuordnungstabelle gefunden und ausgewertet.

Der aufgefundene Eintrag in der Zuordnungstabelle hat keinen Wert in der Spalte VS-Kom⁷, weshalb die Engine-Verarbeitungsfunktion in der aktuellen Engine-Befehlskettenzeile Row2 des RTN-Bausteins Vergleich auf Bool_Value= gesetzt wird. Weiters wird die aktuelle Engine-Befehlskettenzeile Ro w4 des zuletzt eingesetzten RTN-Bausteins Variable als Parameter der aktuellen Engine-Befehlskettenzeile des RTN-Bausteins Vergleich hinzugefügt:

Ro w 1 ForChildren UseSetOfPrev* kein Parameter

Row2 Bool Value= Parameter: Row3,Row4

Row3 Get TableFieldValue Parameter: TabellenFeldA

Row4 GetJValue Parameter: 5

Verarbeitungs-Typ „Boolean". Somit wird der sowohl der Wert Verarbeitungs-Eingangstypl als auch der Wert Verarbeitungs-Ausgangstyp des RTN-Bausteins Vergleich auf „Boolean" gesetzt und der Wert Verarbeitungs-Eingangstyp2 wird auf „nicht vorhanden" gesetzt.

Da die letzte Entscheidungsposition des RTN-Bausteins Vergleich, welcher in den RTN- Baustein Ebenen an der zweiten Entscheidungsposition *(2) eingesetzt ist, durchlaufen ist, liefert der RTN-Baustein Vergleich als sein Verarbeitungs-Ausgangstyp „Boolean" und als seine aktuelle Engine-Befehlskettenzeile die Engine-Befehlskettenzeile Row2.

Es wird für die zweite Entscheidungsposition im äußersten RTN-Baustein Ebenen ein Eintrag in der Zuordnungsmenge für folgende Werte gesucht:

EP-VI¹: ForChildren UseSetOfPrev* EP-VI-E²: VA-ETl³: Boolean VA-ET2⁴:

In den momentanen Elementen der Zuordnungstabelle wird kein zugehöriger Eintrag gefunden. Es können aber in der Zuordnungstabelle als Teilschritt des Voreinstellungsschrittes zumindest folgende zwei weitere Elemente für die Entscheidungspositions- Verarbeitungsinformation °ForChildrem_UseSetOflPrev*° angefügt werden:

In dieser Befüllung werden zwei Elemente in der Zuordnungsmenge gefunden, womit dem Anwender eine automatische Fragestellung vorgeschlagen werden kann:

1. Liefere alle Datensätze der zugehörigen Tabelle und zeige entweder alle oder nur vom Benutzer in einer weiteren Frage ausgewählte Tabellenfelder und zeige zusätzlich je Datensatz in der zugehörigen Tabelle den Wert des Bool' sehen Vergleichs. 2. Füge eine weitere Engine-Befehlskettenzeile ein, welche den Bool'schen Vergleich für alle Datensätze der Tabelle, welche eindeutig das TabellenfeldA enthält, ausfuhrt und nur jene Datensätze aus dieser Tabelle liefert, für welche der Bool'sche Vergleich TRUE liefert.

Kann das Tabellenfeld TabellenfeldA nicht eindeutig einer Tabelle zugeordnet werden, kann die zu verwendende Tabelle mittels einer weiteren automatischen Frage vom Benutzer ausgewählt werden.

Wird vom Benutzer die erste Variante gewählt, bleibt der Zugriffsplan unverändert, da im aufgefundenen Element in der Zuordnungsmenge keine Engine- Verarbeitungsfunktion und kein Wert in der Spalte VS-Kom⁷ vorhanden ist, und wird an der nächsten Entscheidungsposition „Schlüsselwort ]" weiter fortgefahren.

Wird vom Benutzer die zweite Variante gewählt, wird die Spalte VS-Kom⁷ ausgewertet, in welcher der Wert „CreateNewRowAndAddToCurRow" eingetragen ist. Das aufgefundene Element in der Zuordnungstabelle legt die Engine- Verarbeitungsfunktion SetOperation WHERE und den Verarbeitungs-Ausgangstyp „Menge" fest.

Aufgrund des Wertes „CreateNewRowAndAddToCurRow", dessen Bezeichnung willkürlich gewählt ist, werden in Kombination mit einem Wert in der Spalte Verarbeitungs- Eingangstypl und keinen Wert in der Spalte Verarbeitungs-Eingangstyp2 folgende Schritte ausgeführt:

1. Schritt: Erstelle im aktuellen RTN-Bausteine eine weitere Engine-Befehlskettenzeile und setzte als Parameter die Engine-Befehlskettenzeile, welche der zuletzt eingesetzte RTN-Baustein als seine aktuelle Engine-Befehlskettenzeile zurückliefert. Setze als zugehörige Engine-Verarbeimngsfunktion die Engine-Verarbeitungsfunktion, welche in der Spalte E-VA⁵ des aufgefundenen Eintrags in der Zuordnungstabelle steht, und setze den Wert in der Spalte VA-AT⁶ als Verarbeitungs-Eingangstypl des aktuellen

RTN-Bausteins. 2. Schritt: Setzte diese neu angelegte Engine-Befehlskettenzeile als Parameter für die aktuelle Engine-Befehlskettenzeile des aktuellen RTN-Bausteins.

Für das konkrete Beispiel bedeutet dies bei der Variante 2 folgendes:

Erstelle eine neue Engine-Befehlskettenzeile Row5 für den RTN-Baustein Ebenen mit der Engine-Verarbeitungsfunktion SetOperation_WHERE und dem Parameter Row2. Setzte als aktuellen Verarbeitungs-Eingangstypl „Menge" und füge der aktuellen Engine- Befehlskettenzeile Rowl des RTN-Bausteins Ebenen die angefügte Engine- Befehlskettenzeile Row5 hinzu:

Rowl ForChildren UseSetOfPrev* Parameter: Row5

Ro w2 Bool VaIUe= Parameter: Row3,Row4

Row3 Get_TableFieldValue Parameter: TabellenFeldA Row4 Get Value Parameter: 5

Row5 SetOperation WHERE Parameter: Row2

Die Engine-Befehlskettenzeile Rowl bleibt weiterhin die aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen.

Somit ist die zweite Entscheidungsposition *(1) des RTN-Bausteins Ebenen erfolgreich durchlaufen und es wird, die dritte Entscheidungsposition „Schlüsselwort ]" desselben RTN- Bausteins durchlaufen.

Diese dritte Entscheidungsposition legt eine neue Entscheidungspositions- Verarbeitungsinformation °GiveResultsToParent° fest. Diese Entscheidungspositions- Verarbeitungsinformation gehört der ersten Entscheidungspositions-

Verarbeitungsinformations-Verarbeitungstypen-Gruppe an, weshalb die Werte von Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 unverändert bleiben.

Abhängig davon, ob der Benutzer zuvor die erste oder die zweite Variante gewählt hat, werden jeweils zwei unterschiedliche Einträge in der Zuordnungstabelle gesucht: EP-VI¹: GiveResultsToParent

EP-VI-E²:

VA-ETl³: bei Variante 1 : Boolean bei Variante2: Menge

VA-ET2⁴:

In beiden Fällen wird ein Eintrag in der Zuordnungstabelle gefunden, aber es wird eine jeweils unterschiedliche Engine-Verarbeitungsfunktion und ein jeweils unterschiedliche Verarbeitungs- Ausgangstyp festgelegt.

In beiden Fällen ist aber der gleiche Wert in der Spalte VS-Kom⁷ „ReturnLastParamOfFirstVA" eingetragen, womit festgelegt wird, dass eine neue Engine- Befehlskettenzeile Row5 (bei Variante 1) bzw. Row6 (bei Variante2) erstellt wird und dass diese jeweils neu angelegte Engine-Befehlskettenzeile Ro w5 (bei Variante 1) bzw. Row6 (bei Variante2) als Parameter die aktuelle Engine-Befehlskettenzeile Rowl des RTN-Bausteins Ebenen festlegt. Weiters wird durch den Wert „ReturnLastParamOfFirstVA" festgelegt, dass diese zuletzt angelegte Engine-Befehlskettenzeile Row5 (bei Variantel) bzw. Row6 (bei Variante2) die aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Ebenen ist und für die weitere Verarbeitung herangezogen wird.

Da die letzte Entscheidungsposition des äußersten RTN-Bausteins Ebenen durchlaufen ist, ist die Analyse und Zugriffsplan-Erstellung für das angegebene Beispiel [ TabellenfeldA = 5 ] abgeschlossen.

Je nach gewählter Variante wird einer dieser beiden Zugriffspläne in bereits beschriebener Weise abgearbeitet:

Zugriffsplan für Variantel

Rowl ForChildren UseSetOfPrev* Parameter: Row5

Ro w2 Bool Value= Parameter: Row3,Row4 Row3 GetJTableFieldValue Parameter: TabellenFeldA

Row4 GetJValue Parameter: 5

Row5 Return LastValue Parameter: Rowl Zugriffsplan für Variante 2:

Rowl ForChildren UseSetOfPrev* Parameter: Row5

Row2 Bool Value= Parameter: Row3,Row4

Row3 Get_TableFieldValue Parameter: TabellenFeldA

Row4 Get_Value Parameter: 5

Row5 SetOperation_WHERE Parameter: Row2

Row6 Return LastMenge Parameter: Rowl

In gleicher Weise kann folgendes Beispiel in folgenden Zugriffsplan umgewandelt werden, sofern die Zuordnungstabelle um den folgenden Eintrag erweitert wird:

[ 3 TabellenFeldA = TabellenFeldB ]

Beispielsweise zu erstellender Zugriffsplan:

Rowl ForChildren UseSetOfPrev* Parameter: Row5

Row2 Get Value Parameter: 6

Row3 Bool Value= Parameter: Row4,Row5

Row4 Get_TableFieldValue Parameter: TabellenFeldA

Row5 Get_TableFieldValue Parameter: TabellenFeldB

Row6 SetOperation_First Parameter: Row3,Row2

Row7 Return_LastMenge Parameter: Rowl

Dieser Zugriffsplan würde folgende Deutung des Statements erzielen:

Liefere die ersten drei Datensätze, für welche in der zugehörigen Tabelle oder den zugehörigen Tabellen als Karteisches Produkt das Tabellenfeld TabellenfeldA den gleichen Wert wie das Tabellenfeld TabellenfeldB aufweist.

Um diese Deutung zu erzielen, wird folgender weiterer Eintrag in der Zuordnungstabelle als Teilschritt des Voreinstellungsschrittes vor der Analyse des Statements erstellt:

Um die RTN-Bausteine Zeilenauswählend („ WHERE") und Extremwert („MIN'V'MAX") in Statements verwenden zu können, werden weitere Einträge in der Zuordnungstabelle als Teilschritt des Voreinstellungsschrittes erstellt:

Eine Abarbeitung von Beispielen, deren zugehörige RTN-Baustein-Verschachtelung in zumindest einem ausgewählten Entscheidungspfad eines RTN-Bausteins die Entscheidungspositions-Verarbeitungsinformationen SetOperation_WHERE verwendet, wird nicht mehr gezeigt, da sie dem bereits beschriebenen Prinzip folgt. Es wird nur kurz auf die zwei der möglichen Deutungen des folgenden Statements eingegangen:

Beispiel: [ TabelleA WHERE 10 ]

Nachfolgend die zugehörige RTN-Baustein-Verschachtelung für dieses Beispiel:

[°ForChildren_UseSetOfPrev*° *{S)^aForChUdrenJJseSetOfPrev*° *(2)°ForChϊldrenJJseSetOfPrev*° ] °GiveResultsToParent°

(l) Tabe\\enFeldA°lnit_TableField° (2) WHERE°SetOperation_WHERE° *(3) °SetOperation_WHERE°

(3) 10°Init_Valm°

Für dieses Beispiel gibt es aufgrund der zwei aufgefundenen Einträge in der Zuordnungstabelle zwei Deutungsvarianten:

1. Liefere alle Datensätze der Tabelle TabelleA, für welche Datensätze der Wert 10 True liefert - gleichbedeutend mit: liefere alle Datensätze aus der Tabelle TabelleA

2. Liefere die ersten 10 Datensätze aus der Tabelle TabelleA

3. Liefere alle Datensätze aus der Tabelle TabelleA, sofern diese genau 10 Datensätze aufweist.

Der Bezug des RTN-Bausteins WHERE * zu dem vorhergehenden RTN-Baustein TabelleA ergibt sich daraus, dass der RTN-Baustein Ebenen die Verarbeitungs-Ausgangsrnenge des eingesetzten RTN-Bausteins Tabelle „TabelleA" als seine Verarbeitungs-Eingangsmenge festgelegt und diese somit dem an der zweiten * -Entscheidungsposition eingesetzten RTN- Baustein „WHERE" als dessen Verarbeitungs-Eingangsmenge übergibt. Die jeweiligen Zugriffspläne werden in bereits gezeigter Weise erstellt und daher nicht mehr ausgeführt. Es bleibt dem Fachmann offen, weitere Deutungsmöglichkeiten

Die weitere Befüllung der Zuordnungstabelle für die Entscheidungspositions- Verarbeitungsinformationen SetOperation_Min, SetOperation_Max, SetOperation_OrderBy usw. erfolgt im Voreinstellungsschritt durch den Anwender. Diese Befüllung wird für bereits gezeigte Gruppen nicht mehr vorgenommen, da sie dem gleichen, beschriebenen Prinzip folgen und vom Anwender an seine Bedürfnisse angepasst und jederzeit erweitert werden können.

Die Darstellung, Analyse und Verarbeitung weiterer Beispiele für sämtliche gezeigte Gruppen werden nicht mehr ausgeführt, da diese aus der Beschreibung selbst erstellt und nachvollzogen werden können.

Es wird ein weiterer RTN-Baustein mit zugehörigem Entscheidungsgraphen und an Entscheidungspositionen zugewiesenen Entscheidungspositions-Verarbeitungsinformationen gezeigt:

RTN-Baustein „Mengen-Elemente-Begrenzend": RTN-Syntax: * „#" °Extend_LimitResults° [(„=" °Param_Comp=° | „>" „=" °Param_Comp>=° | „<" „=" °Param_Comp<=° | „<" „>" °Param_Compo° )] [,,%"⁰Param_Comp%⁰] *

Des weiteren wird eine Engine-Verarbeitungsfunktion Extend LimitResults definiert, welche als Engine-Verarbeitungsfunktion keine Verarbeitungsfunktion ausführt, anstatt dessen aber als Parameter bei sämtlichen RTN-Bausteinen und somit Engine-Befehlskettenzeilen hinzugefügt werden kann. Somit können jene Engine-Befehlskettenzeilen, welche als zusätzlichen Parameter auf diese Engine-Verarbeitungsfunktion verweisen, festlegen, dass die zugehörige Engine-Verarbeitungsfunktion zwar auf alle Elemente anzuwenden ist, aber erfolgreich beendet ist, sobald die Anzahl Elemente bzw. die Elemente, welche als Parameter der diese Engine-Verarbeitungsfunktion „Extend_LimitResults" angegeben sind, gefunden wurden. Ein Beispiel, welches diesen gezeigten RTN-Baustein verwendet, sich aber auf zumindest zwei Weisen in einen optimierten Zugriffsplan umwandeln lässt, ist dieses: Hier ist zu beachten, dass aufgrund unterschiedlicher Einträge in der Zuordnungstabelle die Befehle der Engine zwar gleich arbeiten, aber der Durchlauf und die Auswertung der Parameter anders definiert werden muss:

[ WHERE TabellenFeldA = TabellenFeldB # 10 ]

Die zugehörige RTN-Baustein- Verschachtelung für dieses Beispiel wird gezeigt:

[°ForChildrenJJseSetOfPrev*° * ( 1 ) ^aForChildrenJJseSetOfPrev*° ] °GiveResultsToParent°

(1) *(2) #°Extend_LimitResults° *(3)°Extend_LimitResults° (2) WHEKE°SetOperation_WHERE° * ^:(4) "SetOperation JVHERE⁰

(4) *(5) =°Compare=° *(6)°Compare=°

(5)TabellenFeldA°Init_TableField° (6)TabellenFeldB ^o/mY_7αWeF/eM°

Die Besonderheit dieses Beispiels liegt darin, dass der RTN-Baustein „Mengenelemente- Begrenzend" („#") in der Schreibweise des Statements nur die Anzahl Elemente der Verarbeitungs- Ausgangsmenge des in diesen an der ersten * -Entscheidungsposition eingesetzten RTN-Bausteins „WHERE" zurückliefert, welche an der zweiten *- Entscheidungsposition desselben RTN-Bausteins definiert sind. Dies ist im Sinne der Zugriffsplan-Optimierung nachteilig. Vielmehr sollte im Zugriffsplan die Engine- Verarbeitungsfunktion WHERE einen Parameter enthalten, welcher besagt, dass nur diese Anzahl an Elementen von dieser Engine-Verarbeitungsfunktion geliefert werden soll. Somit kann die Engine-Verarbeitungsfunktion „WHERE" dann abbrechen, sobald die gewünschte Anzahl an Elementen gefunden wurde und diese als Verarbeitungs- Ausgangsmenge des RTN- Bausteins bzw. der Engine-Berfehlskettenzeile zurückliefern. Dies gilt analog für sämtliche weitere RTN-Bausteine bzw. Engine- Verarbeitungsfunktionen wie z.B. SetOperation_Max und SetOperationJVIin, welche nur eine definierte Anzahl Elemente mit den entweder größten oder kleinsten Feldwerten oder berechneten Werten zurückliefern. Ebenso ist der RTN- Baustein OrderBy betroffen, wenn dieser die Elemente nach einem Tabellenfeld oder berechneten Wert soll und nur eine festgelegte Anzahl Elemente zurückliefern soll. Weiteres betroffene RTN-Bausteine bzw. Engine-Verarbeitungsfunktionen werden nicht angeführt, es wird aber festgestellt, dass die Eigenschaft, Elemente in der zurückzuliefernden Anzahl zu begrenzen, eine Eigenschaft der Engine- Verarbeitungsfunktion °Extend_LimitResults° ist. Deswegen wird bei zugehörigen Elementen in der Zuordnungsmenge jeweils ein neuer Wert in die Spalte VS-Kom⁷ geschrieben, aufgrund dessen diese Optimierung für sämtliche untergeordnete RTN-Bausteine erkannt wird.

Es wird folgender neuer Eintrag in der Zuordnungstabelle vorgenommen:

Die Analyse der Verschachtelung und die Erstellung des Zugriffsplans wird nicht gänzlich gezeigt. Die Schritte werden verfahrensmäßig durchlaufen, bis einschließlich die Entscheidungsposition *(3) im RTN-Baustein Mengen-Element-Begrenzend durchlaufen wurde. Bis zu dieser Entscheidungsposition ergibt sich folgender Zugriffsplan mit folgenden Engine-Befehlskettenzeilen:

Rowl ForChildrenJJseSetOfPrev* kein Parameter

Row2 keine Enεine-Verarbeitunesfunktion Parameter: Row3

Row3 SetOρeration_WHERE Parameter: Row4

Row4 Bool_Value= Parameter: Row5,Row6

Row5 Get TableFieldValue Parameter: TabellenfeldA

Row6 Get_TableFieldValue Parameter: TabellenfeldB

Row7 Get Value Parameter: 10 Nachdem die * -Entscheidungsposition *(3) im RTN-Baustein Mengen-Element-Begrenzend durchlaufen ist, stehen folgende aktuellen Werte für diesen RTN-Baustein zur Verfügung:

Aktuelle Engine-Befehlskettenzeile des RTN-Bausteins „Mengen-Element-Begrenzend" Row2

Aktuelle Engine-Befehlskettenzeile des zuletzt eingesetzten RTN-Bausteins „Variable":

Row7

Aktuelle Entscheidungspositions-Verarbeitungsinformation des RTN-Bausteins „Mengen- Element-Begrenzend": Extend LimitResults

Aktueller Verarbeitungs-Eingangstypl des RTN-Bausteins „Mengen-Element-Begrenzend"

Menge Aktueller Verarbeitungs-Eingangstyp2 des RTN-Bausteins „Mengen-Element-Begrenzend"

Value

Somit wird ein Eintrag in Zuordnungstabelle für folgende aktuelle Werte desselben RTN- Bausteins gesucht:

EP-VI¹: Extend_LimitResults EP-VI-E²:

VA-ETl³: Menge

VA-ET2⁴: Value

Es wird ein Eintrag in der Zuordnungstabelle gefunden, welcher in der Spalte VS-Kom⁷ den Wert AddAsParamToFirstRow aufweist.

Aufgrund dieses Wertes werden für den aktuellen RTN-Baustein werden folgende Schritte ausgeführt, welche immer ausgeführt werden, wenn ein aufgefundener Eintrag in der Zuordnungstabelle einen Verarbeitungs-Eingangstypl und einen Verarbeitungs-Eingangstyp2 aufweist und in der Spalte VS-Kom⁷den willkürlich benannten Wert AddAsParamToFirstRow aufweist: 1. Setzte die Engine- Verarbeitungsfunktion der aktuellen Engine-Befehlskettenzeile des aktuellen RTN-Bausteins auf die Engine-Verarbeitungsfunktion, welche in der Zuordnungstabelle aufgefunden wurde.

2. Wähle die Engine-Befehlskettenzeile aus, welche der aktuellen Engine- Befehlskettenzeile als ersten Parameter angefügt ist und füge dieser ausgewählten Engine- Befehlskettenzeile als weiteren Parameter die aktuelle Engine-Befehlskettenzeile des aktuellen RTN-Bausteins als weiteren Parameter an.

3. Entferne den ersten Parameter der aktuellen Engine-Befehlskettenzeile des aktuellen RTN-Bausteins und füge als Parameter die Engine-Befehlskettenzeile des zuletzt eingesetzten RTN-Bausteins an.

4. Setze die ausgewählte Engine-Befehlskettenzeile, also die Engine-Befehlskettenzeile, die als erster Parameter in der aktuellen Engine-Befehlskettenzeile des aktuellen RTN- Bausteins angegeben war, als aktuelle Engine-Befehlskettenzeile des aktuellen RTN- Bausteins.

Dies bedeutet für das aktuelle Beispiel folgendes:

1. Setzten der Engine-Verarbeitungsfunktion der aktuellen Engine-Befehlskettenzeile Row2 des RTN-Bausteins Mengen-Elemente-Begrenzend auf Extend_LimitResults.

2. Auswählen der Engine-Befehlskettenzeile Row3, welche als erster Parameter der aktuellen Engine-Befehlskettenzeile Row2 des aktuellen RTN-Bausteins Mengen-Elemente- Begrenzend angegeben ist und anfügen dieser ausgewählten Engine-Befehlskettenzeile Row3 die aktuelle Engine-Befehlskettenzeile Row2 des_\ aktuellen RTN-Bausteins Mengen- s

Elemente-Begrenzend. '

\ 3. Entfernen des ersten Parameters Ro w3 der aktuellen Engine-Befehlskettenzeile Row2 des aktuellen RTN-Bausteins Mengen-Elemente-Begrenzend und anfügen der aktuellen Engine-Befehlskettenzeile Row7 des zuletzt eingesetzten RTN-Bausteins *(3) Variable. 4. Setzen der ausgewählte Engine-Befehlskettenzeile Row3 als aktuelle Engine- Befehlskettenzeile des aktuellen RTN-Bausteins Mengen-Elemente-Begrenzend und übersteuere somit die vorher aktuelle Engine-Befehlskettenzeile Row2 dieses RTN-Bausteins.

Die nunmehr aktuelle Engine-Befehlskettenzeile des RTN-Bausteins Mengen-Elemente- Begrenzend ist die Engine-Befehlskettenzeile Row3. Das Verfahren wird weiter ausgeführt, bis die dem angegebenen Statement zugehörige RTN-Baustein-Verschachtelung durchlaufen ist. Somit ergibt sich folgender endgültiger Zugriffsplan:

Rowl ForChildrenJJseSetOfPrev* Parameter: Row 3

Ro w2 Extend LimitResults Parameter: Rowl

Row3 SetOperationJWHERE Parameter: Row4, Row2

Row4 Bool_Value= Parameter: Row 5, Row 6

Row5 Get_TableFieldValue Parameter: TabellenfeldA Row6 Get_TableFieldValue Parameter: TahellenfeldB

Row7 Get_Value Parameter: 10

Row8 Return_LastMenge Parameter: Rowl

Die Engine-Verarbeitungsfunktion der Engine-Befehlskettenzeile Row3 führt bei Erreichen im verfahrensmäßigen Durchlauf des Zugriffsplans die Engine-Verarbeitungsfunktion „WHERE" auf die aktuelle Eingangs-Menge aus. Da diese Engine-Verarbeitungsfunktion als zusätzlichen Parameter „ExtendJLimitResults" aufweist, kann die Engine- Verarbeitungsfunktion dahingehend optimiert werden, dass sie erfolgreich beendet ist, sobald zehn Elemente aufgefunden wurden, für welche der Vergleich TRUE liefert.

Dies ist nur eine Variante, um eine Optimierung des Zugriffsplans zu erzielen. Ist in der Zuordnungstabelle für das zuletzt angelegte Element kein Wert in der Spalte VS-Kom⁷ vorhanden, ergibt sich mit dem gleichen Verfahren ein etwas anderer Zugriffsplan, der im Sinne der Optimierung von der Engine etwas anders gedeutet wird:

Ersetzter Eintrag in der Zuordnungstabelle:

Sofem dieser Eintrag in der Zuordnungstabelle aufgefunden wird, ergibt sich für das gleiche Beispiel folgender, gleichwertiger Zugriffsplan, für welchen die Auswertung der Parameter in der Engine aber unterschiedlich gedeutet werden muss:

[ WHERE TabellenFeldA = TabellenFeldB # 10 ]

Aufgrund des veränderten Eintags für Extend_LimitResults in der Zuordnungstabelle entsprechend generierter Zugriffsplan:

Rowl ForChüdrenJJseSetOfPrev* Parameter: Row2

Row2 Extend_LimitResults Parameter: Row3,Row7

Row3 SetOperation WHERE Parameter: Row4

Row4 Bool_Value= Parameter: Row5,Row6

Row5 GetJTableFieldValue Parameter: TabellenfeldA

Row6 Get_TableFieldValue Parameter: TabellenfeldB

Row7 Get_Value Parameter: 10

Row8 Return LastMenge Parameter: Rowl

In diesem Fall erhält die Engine- Verarbeitungsfunktion in Row3 WHERE den Parameter Extend_LimitResults 10 dadurch, dass diese Engine-Verarbeitungsfunktion von Row2, welche eben diese Beschränkung der Anzahl Elemente in der Verarbeitungs-Ausgangsmenge festlegt, die Row3 aufruft.

Es ist bei Analyse und Durchlauf des Engine-Codes für einen Algorithmus auch möglich zu erkennen, dass die Engine-Verarbeitungsfunktion „WHERE für eine begrenzte Anzahl" Elemente der Engine-Verarbeitungsfunktion „FIRST" entspricht. Entsprechend kann diese Engine-Verarbeitungsfunktion „FIRST" in der tatsächlichen Abarbeitung verwendet werden. Um weitere Beispiele zu zeigen, wird die Zuordnungstabelle um Elemente für die Entscheidungspositions-Verarbeitungsinformationen °Compare=° und °SetBeistrich° erweitert:

Es wird angemerkt, dass die Engine- Verarbeitungsfunktion jederzeit erweiterbar sind und nicht einzeln erklärt werden. Die Erstellung und Erweiterung von Engine- Verarbeitungsfunktionen obliegt dem Fachmann ebenso wie Einbindung derselben in die Zuordnungsmenge.

Aufgrund dieser unvollständigen hinzugefügten Einträge in der Zuordnungstabelle lassen sich etliche weitere Beispiele verarbeiten. Es wurde ein neuer Wert für die Spalte VS-Kom⁷ eingeführt, welcher nachfolgend in Beispielen erläutert wird.

Es werden zwei RTN-Bausteine gezeigt, welche beide die gleiche Entscheidungspositions- Verarbeitungsinformation °Compare=° bei Erreichen einer ihnen zugehörigen Entscheidungsposition festlegen:

RTN-Baustein Vergleich: RTN-Syntax: * ("=" °Compare=° | "<" °Compare<° \ ">" °Compare>° | ">" "=" °Compare>=° | "<" "=" °Compare<=° \ "<" ">" °Compare<>° ) *

RTN-Baustein Vergleich-IN:

RTN-Syntax: * "IN" °Compare=° "(" * ")"

Aufgrund der für diese beiden gezeigten RTN-Bausteine gleiche Entscheidungspositions-

Verarbeitungsinformation °Compare=° bei Erreichen der jeweils zugehörigen

Entscheidungsposition wird trotz unterschiedlicher Syntax ein jeweils gleicher Zugriffsplan erstellt.

Folgende einfache Beispiele sollen dies zeigen:

[ TabellenfeldA ]

[ TabellenfeldA IN (5) ]

[ TabellenfeldA 5,6,7 ]

[ TabellenfeldA IN (5,6,7) ]

[ 5,6,7 TabellenfeldA ]

[ 5,6,7 IN (TabellenfeldA) ]

[ TabellenfeldA, TabellenfeldB = 5,6,7 ]

[ TabellenfeldA, TabellenfeldB IN (5,6,7) ] Im letzten Fall kann mittels automatischer Nachfrage beim Anwender entschieden werden, ob eines der beiden Tabellenfelder TabellenfeldA bzw. TabellenfeldB den Wert 5,6 oder 7 enthalten muss - beide Tabellenfelder TabellenfeldA und TabellenfeldB entweder die Werte 5,6 oder 7 enthalten müssen

Es wird ein weiteres einfaches Beispiel gezeigt, welches die Auswertung des Wertes CurCommand_ChangeParamOrder in der Spalte VS-Kom⁷ zeigt:

Wird ein Element in der Zuordnungsmenge aufgefunden, welches in der Spalte VS-Kom⁷ den Wert CurCornmand ChangePararnOrder aufweist, bekommt die aktuelle Engine- Befehlskettenzeile des aktuellen RTN-Bausteins als ersten Parameter die aktuelle Engine- Befehlskettenzeile des zuletzt eingesetzten RTN-Bausteins vor dem zuvor ersten Parameter vorgereiht.

Somit wird folgendes Beispiel in den nachfolgenden Engine-Code für die Variante 1 umgewandelt:

[ 5,6,7 IN (TabellenfeldA) ] ,

Da der Benutzer bei einer automatischen Nachfrage zψischen Variante 1 (nur jene Datensätze liefern, für die die IN-Bedingung TRUE ist) und Variante2 (alle Datensätze und je Datensatz zeigen, ob die IN-Bedingung TRUE ist) wählen kann, /wird nun die erste Variante gezeigt:

Generierter Engine-Code: Variante 1

Ro w 1 ForChildrenJJseSetOfPrev* RθM>8

Row2 Bool_IN_Right

Row7,Row3

Row3 Combine ValuesToSet Parameter: Row4, Row5,Row6

Row4 GetJValue Parameter: 5

Row5 Get_Value Parameter: 6

Row6 GetJValue Parameter: 7

Row7 Get TableFieldValue Parameter: TabellenfeldA

Row8 SetOperation_WHERE Parameter: Row2 Ro w9 ReturnJLastMenge Parameter: Rowl Variante2 entspricht der Variantel mit dem Unterschied, dass die Engine-Befehlskettenzeile Row8 nicht eingefügt wird und die Engine-Befehlskettenzeile Rowl als Parameter die Engine-Befehlskettenzeile Row2 enthält.

Ein weiteres Beispiel zeigt die Flexibilität der Zuordnungstabelle und die Genauigkeit, mit der ein Anfragestatement analysiert und gedeutet werden kann:

Beispiel [ 3, 5, 7 TabelleA

Um dieses sowie alle artverwandten Statements zu deuten, werden neue Einträge als Teilschritt des Voreinstellungsschrittes in der Zuordnungstabelle angelegt:

werden, womit er

Tabelle zumindest

Die Zugriffsplan-Erstellung erfolgt nach dem gezeigten Verfahren und wird somit nicht mehr ausgeführt.

Es wird nun zwei Entscheidungspositions-Verarbeitungsinformationen gezeigt, welche der zweiten Entscheidungspositions-Verarbeitungsinformationsgruppe angehören, was bedeutet, dass bei festlegen dieser Entscheidungspositions- Verarbeitungsinformationen die beiden Werte Verarbeitungs-Eingangstypl und Verarbeitungs-Eingangstyp2 auf nicht vorhanden gesetzt werden:

Entscheidungspositions- Verarbeitungsinformationen der zweiten Entscheidungspositions- Verarbeirungsinformationsgrappe :

°SelectCase Case^c °SelectCase Else^c

Ein RTN-Baustein, welcher diese Entscheidungspositions- Verarbeitungsinformationen an zumindest einer seiner Entscheidungspositionen zugeordnet hat, wird gezeigt:

RTN-Baustein „SELECT-CASE"

RTN-Syntax: "SELECT" "CASE" °SelectCase_Select° * ":" (1) "GASE" °SelectCase_Case° [("<" "=" °Param_Comp<=° | ">" "=" °Param_Comp>=° | "="

°Param_Comp=° | "<" ">" °Param_Comp<>° )] * ":" * [(*1)] [¹¹CASE"

"ELSE" °8electCase_Else° ":'| *] "END" "SELECT"

Es werden weitere, diesen Engine- Verarbeitungsfunktionen zugehörige Einträge in der Zuordnungstabelle angelegt:

Durch den neu eingerührten Wert AddAsParamToFirstV AFunction, welcher in der Spalte VS-Kom⁷ in der Zuordnungstabelle verwendet werden kann, werden für aufgefundene Einträge, welchen diesen Wert AddAsParamToFirstV AFunction enthalten, folgende Schritte ausgeführt:

1. Erzeuge eine neue Engine-Befehlskettenzeile, welche als Engine- Verarbeitungsfunktion den aufgefundenen Wert E-VA⁵ in der Zuordnungstabelle und als Parameter die Engine-Befehlskettenzeile der den letzten bzw. die beiden zuletzt eingesetzten und durchlaufenen RTN-Bausteine festlegt. Ob dieser Engine-Befehlskettenzeile ein oder zwei Parameter angefügt werden, hängt davon ab, ob in der Zuordnungstabelle ein zusätzlich Verarbeitungs-Eingangstyp2 verlangt wird oder nur ein Verarbeitungs-Eingangstypl.

2. Füge diese neu angelegte Engine-Befehlskettenzeile als Parameter der ersten Engine- Befehlskettenzeile des aktuellen RTN-Baustems an.

Dies wird anhand des folgenden einfachen Beispiels gezeigt: [ SELECT GASE TabelleA.TabellenfeldA:

CASE 5: TabelleB CASE 10, 12: TabelleC

CASE ELSE: TabelleD

END SELECT ]

Generierter Engine-Code: Rowl ForChildrenJJseSetOfPrev* Parameter: Row8

Row2 SelectCase_SelectPart Parameter: Row3,Row4,Row7,Rowl 0

Row3 GetJTableFieldValue Parameter: TabellenfeldA

Row4 SelectCase CasePart Parameter: Row5,Row6 Row5 Get_Value Parameter: 5

Row6 GetJTableMenge Parameter: TabelleB

Row7 SelectCase_CasePart Parameter: Row8,Rowl 1

Row8 CombineValuesToSet Parameter: Row9, RowlO

Row9 Get_Value Parameter: 10

Ro WlO Get_Value Parameter: 12

Rowl l Get_TableMenge Parameter: TabelleC

Rowl2 SelectCase_ElsePart Parameter: Rowll

Rowl3 Get_TableMenge Parameter: TabelleD

Rowl4 Return LastMenge Parameter: Rowl

Die Engine-Befehlskettenzeile Row2 enthält als Parameter sowohl den ersten Wert, mit dem sämtliche Werte, die als CASE bzw. CASE ELSE-Parameter ausgewiesen sind. Die Engine- Befehlskettenzeilen Row4, Row7 und RowlO enthalten die Information, mit welchem Wert der CASE- Wert je Element der Verarbeitungs-Eingangsmenge jeweils verglichen werden soll ebenso wie die Menge bzw. Tabelle, die bei positivem Vergleich als Verarbeitungs-

Ausgangsmenge geliefert werden soll. ' i \

Sind an den * -Entscheidungsposition des) RTN-Bausteins SELECT-CASE jeweils RTN- Bausteine, die in ihrer Verarbeitungs- Ausgangsmenge Werte anstatt Mengen, also z.B. Zahlen, Tabellenfelder, Systemfunktionen /und/oder Berechnungen liefern, eingesetzt, liefert der RTN-Baustein SELECT-CASE ebenfalls einen Wert (Value).

Um den RTN-Baustein IF-THEN-ELSE verwenden zu können, wird dieser mit beispielsweise folgender RTN-Syntax der Gesamtheit der RTN-Bausteine hinzugefügt:

RTN-Baustein „IF-THEN-ELSE"

RTN-Syntax: "IF" °IfThenElse° * "THEN" * ["ELSE" *] [¹¹END" "IF"]

Es werden folgende zugehörige Elemente in der Zuordnungstabelle angefügt:

Die Analyse von Statements, welche IF-THEN-ELSE enthalten, folgen dem gezeigten Verfahren, es wird daher nur kurz ein Beispiel mit zugehörigem Zugriffscode gezeigt:

[ WHERE

TabellenfeldA

IF TabellenfeldB = TabellenfeldC THEN 10, 20, 30 ELSE 40, 50, 60 END IF ]

Generierter Engine-Code-:

Rowl ForChildren_UseSetOfPrev* Parameter: Row2

Row2 SetOperation_WHERE Parameter: Row3

Row3 Bool_IN_Right Parameter: Row4,Row5

Row4 Get_TableFieldValue Parameter: TabellenfeldA

Row5 If-Then-Else Parameter: Row6,Row9,Rowl3

Row6 Bool_Value= Parameter: ROΛV7,ROW8

Row7 Get_TableValueValue Parameter: TabellenfeldB

Row8 Get_TableValueValue Parameter: TabellenfeldC

Row9 Combine ValuesToSet Parameter: RowlO,Rowll,Rowl2

RowlO Get_Value Parameter: 10

Rowl l Get_Value Parameter: 20

Rowl2 Get_Value Parameter: 30

Rowl3 Combine ValuesToSet Parameter: Rowl4,Rowl5,Rowl6 Rowl4 GetJValue Parameter: 40

Rowl5 Get_Value Parameter: 50

Rowlβ Get_Value Parameter: 60

Rowl7 Return LastMenge Parameter: Rowl

Dieses Beispiel würde daher alle Datensätze der Verarbeitungs-Eingangsmenge des RTN- Bausteins Ebenen liefern, für welche das TabellenfeldA je Datensatz in Abhängigkeit des Vergleiches TabellenfeldB=TabellenfeldC entweder einen der Werte 10, 20 oder 30 bzw. einen der Werte 40, 50 oder 60 enthält. Die Feststellung der jeweiligen Verarbeitungs- Eingangsmenge kann dadurch erfolgen, dass die Tabelle bzw. die Tabellen gesucht werden, welche entweder eindeutig oder nach automatischer Nachfrage beim Anwender die Tabellenfelder TabellenfeldA, TabellenfeldB oder TabellenfeldC enthalten. Sofern die Verarbeitungs-Eingangsmenge des RTN-Bausteins Ebenen mehr als eine Tabelle enthält, kann vom Anwender entschieden werden, ob ein Kartesisches Produkt als diesen Tabellen gebildet werden soll oder ob z.B. mittels der Tabelle der Relationen die Beziehungen zwischen diesen Tabellen automatisch eingefügt werden sollen.

Es wird der RTN-Baustein „Zeilenzusammenfassend" (GROUPBY) mit den zugehörigen Entscheidungspositions- Verarbeitungsinformationen gezeigt:

RTN-Baustein „Zeilenzusammenfassend"

RTN-Syntax: „GROUPBY" * °SetOperation_GroupBy° [„:" (1) * [(*1)] „END" „GROUPBY" °SetOperation_EndGroupBy°]

Es werden weitere Einträge in der Zuordnungstabelle angelegt, um die Mächtigkeit einer Anfragesprache, welche auf RTN-Bausteinen basiert, und die Möglichkeiten der kontextsensitiven Analyse zu zeigen:

Aufgrund des Wertes „CreateNewRowAndAddToCurRow_NewRowIsCurRow", werden

Der aktuellen Engine-Befehlskettenzeile ijdes aktuellen RTN-Bausteins werden die

(1 letzten zwei Parameter entfernt und danach als weiterer Parameter diese neu angelegte Engine-Befehlskettenzeile zugeordnet. '! Diese neu angelegte Engine-Befehlskettenzeile wird als aktuelle Engine- Befehlskettenzeile des aktuellen RTN-Bausteins festgelegt und das Verfahren wird wie beschrieben fortgesetzt.

Es wird ein Beispiel gezeigt, welches aufgrund der kontextsensitiven Deutungsmöglichkeit auf zwei verschiedene Schreibweisen dargestellt werden kann:

Beispiel: [ WHERE TabelleA.TabellenfeldB=10 GROUPBY TabelleA.TabellenfeldA ]

[ TabelleA.TabellenfeldA. WHERE (TabelleA.TabellenfeldB=10) ]

Der Zugriffsplan-Erstellung für diese beiden Beispiele folgt jeweils dem gezeigten Verfahren und daher nicht angeführt.

Generierter Engine-Code für die erste Schreibweise des Beispiels:

Rowl ForChildrenJJseSetOfPrev* Parameter: Row2, Row8

Row2 SetOperation_WHERE Parameter: Row3

Row3 Bool_Value= Parameter: Row4,Row7

Row4 Return_TableFieldValue Parameter: Row5,Row6

Row5 Get_TableMenge Parameter: TabelleA

Row6 Get_TableValueValue Parameter: TabellenfeldB

Row7 GetJValue Parameter: 10

Row8 GroupBy_DoInGroupBy Parameter: Row9

Row9 Return_TableFieldValue Parameter: Rowl0,Rowll

RowlO Get_TableMenge Parameter: TabelleA

Rowl l Get_TableValueValue Parameter: TabellenfeldA

Rowl2 Return LastMenge Parameter: Rowl

In diesem Engine-Code ist ersichtlich, dass nur jene Datensätze aus der TabelleA als Verarbeitungs-Ausgangsmenge des RTN-Bausteins WHERE und dessen zugehöriger Engine- Befehlskettenzeile Row2 geliefert werden, welche in der Spalte TabellenfeldB den Wert 10 aufweisen. Diese Verarbeitungs-Ausgangsmenge des RTN-Bausteins WHERE (Row2) wird als neue Verarbeitungs-Eingangsmenge des übergeordneten RTN-Bausteins Ebenen (Rowl) gesehen. Die Engine-Verarbeitungsfunktion in Rowl besagt, dass die jeweils aktuelle Verarbeitungs-Eingangsmenge des RTN-Bausteins Ebenen und somit der Engine- Befehlskettenzeile Rowl als neue Verarbeitungs-Eingangsmenge des als nächstes eingesetzten RTN-Bausteins übergeben wird. Somit bekommt die Engine-Befehlskettenzeile Row8, welche die zweite * -Entscheidungsposition bzw. der zweite Parameter des RTN- Bausteins Ebenen ist, als Verarbeitungs-Eingangsmenge jene Datensätze aus der Tabelle TabelleA, in welchen das TabellenfeldB den Wert 10 aufweist. Die Engine- Verarbeitungsfunktion in Row8 führt eine Gruppierung für die Datensätze der Verarbeitungs- Eingangsmenge durch und liefert somit als seine Verarbeitungs-Ausgangsmenge alle unterschiedlichen Werte des Tabellenfeldes A, welche in der Verarbeitungs-Eingangsmenge des RTN-Bausteins GROUPBY enthalten sind. Somit werden als Verarbeitungs- Ausgangsmenge der Engine-Befehlskettenzeile Rowl die unterschiedlichen Werte in der Spalte Tabellenfeld A geliefert, sofern zumindest ein Element in dieser jeweiligen Gruppierung für das TabellenfeldB den Wert 10 aufweist.

Generierter Engine-Code für die zweite Schreibweise des Beispiels:

Rowl ForChildrenJJseSetOfPrev* Parameter: Row2

Row2 ReturnJTableFieldValue Parameter: Row3, Rowll

Row3 Get_TableMenge Parameter: TabelleA

Row4 GetJTableFieldValue Parameter: TabellenfeldA

Row5 SetOperation_WHERE Parameter: Row6

Row6 Bool_Value= Parameter: Row7,RowlO

Row7 ReturnJTableFieldValue Parameter: Row8,Row9

Row8 GetJTableMenge Parameter: TabelleA

Row9 GetJTableValueValue Parameter: TabellenfeldB

RowlO Get_Value Parameter: 10

Rowl l GroupBy DolnGroupBy Parameter: Row4,Row5

Rowl2 Return LastMenge Parameter: Rowl

In diesem Engine-Code ist ersichtlich, dass nach dem Tabellenfeld TabellenfeldA gruppiert wird und innerhalb dieser Gruppierung für die Elemente, welche jeweils den gleichen Wert im TabellenfeldA aufweisen, die Engine-Verarbeitungsfunktion WHERE angewandt wird. Somit werden als Verarbeitungs-Ausgangsmenge der Engine-Befehlskettenzeile Rowl die unterschiedlichen Werte in der Spalte TabellenfeldA geliefert, sofern zumindest ein Element in dieser jeweiligen Gruppierung für das TabellenfeldB den Wert 10 aufweist. Die nachfolgenden Beispiele verwendet den RTN-Baustein Aggregat-Parameterlos, welcher nun mit Entscheidungspositions-Verarbeitungsinformationen gezeigt und für welchen ein entsprechender Eintrag in der Zuordnungstabelle erstellt wird:

RTN-Baustein „Aggregat-Parameterlos"

RTN-Syntax: ("Count" °Aggregate_Count° | "Exists" °Aggregate_Exists° | "None" ° Aggregate _Hone °)

Weiter wird der RTN-Baustein Aggregat- 1 Parameter gezeigt: RTN-Baustein „Aggregat-1 Parameter"

RTN-Syntax: ("Sum" °AggregateJSum° | "AVG" "Aggregate _AVG^C "Return" °GiveResultToParent° ) "(" * ")"

Weitere Einträge in der Zuordnungstabelle:

Dieses Element in der Zuordnungsrabelle enthält einen neuen Verarbeitungs-Typ. Es können vom Fachmann beliebig weitere Zuordnungstypen eingeführt werden, um Deutungen von Anfragen, insbesondere kontextsensitive Deutungen, genauer zu ermöglichen. Die Anzahl der Verarbeitungs-Typen und deren (Verwendung in den Spalten VA-ETl³, VA-ET2⁴ und VA- AT⁶ in der Zuordnungstabelle haben keinen Einfluss auf das erfmdungsgemäße Verfahren. Das gleiche gilt für die Werte (Engine- Verarbeitungsfunktionen) in der Spalte E-VA⁵, da dieser in der zugehörigen Engine als (optimierbare) Befehle vorhanden sind. Ebenso können weitere Werte für die Spalte VS-Kom⁷ eingeführt und somit weitere Verfahrensschritte bei Auffinden eines zugehörigen Elements in der Zuordnungstabelle festgelegt werden.

Ein weiteres einfaches Beispiel zeigt die Verwendung und Analyse des RTN-Bausteins Zeilenzusammenfassend (GROUPBY):

Liefere alle Datensätze aus der TabelleA, für welchen je unterschiedlichen Wert TabellenfeldA mehr als 10 Datensätze in der Tabelle vorhanden sind:

Beispiel:

[ GROUPBY TabelleA.TabellenFeldA: WHERE Count>l O END GROUPBY ]

Generierter Engine-Code für dieses Beispiel:

Rowl ForChildrenJJseSetOfPrev* Parameter: Row2 Row2 GroupBy_DoInGroupBy Parameter: Row3,Row6,RowlO

Row3 RetumJTableFieldValue Parameter: Row4,Row5

Row4 Get TableMenge Parameter: TabelleA

Row5 GetJTableValueValue Parameter: TabellenfeldA

Row6 SetOperation_WHERE Parameter: Row7 Row7 Bool_Value> Parameter: Rσw8,Row9

Row8 Aggregate_Count kein Parameter

Ro w9 Get_Value Parameter: 10

RowlO GroupBy_EndGroupBy kein Parameter

Rowl 1 Return_LastMenge Parameter: Rowl

Aus diesem Zugriffsplan ist ersichtlich, dass die Engine- Verarbeitungsfunktion GROUPBY

genaue Optimierung dieses Zugriffsplans ist für den Fachmann ersichtlich und wird daher nicht weiter beschrieben.

Um weitere Beispiele und deren zugehörige Zugriffspläne zu zeigen, werden weitere Einträge in der Zuordnungstabelle erstellt:

Um diese weiteren Beispiele sowie alle dieser Gruppe zugehörigen richtig auflösen und in einen Zugriffsplan konvertieren zu können, wird in der Zuordnungstabelle eine neue Spalte eingeführt:

Spaltenname: E-VA-PrevCommand⁸

Diese Spalte wird aus Platzgründen in der Zuordnungstabelle unter den Wert der Spalte VS- Kom⁷ mittels des Trennzeichens „+" geschrieben und eine entsprechende, einfache Auswirkung dieser weiteren Spalte wird nachfolgend erklärt:

Mit diesen Einträgen in der Zuordnungstabelle lassen sich sämtliche Anfragestatement- Ausschnitte der gezeigten Art in einen Zugriffsplan umwandeln:

Count.TabelleA liefert die Anzahl Datensätze in der Tabelle TabelleA TabelleA.Count liefert die Anzahl Datensätze in der Tabelle TabelleA Count.TabellenfeldA liefert die Anzahl unterschiedlicher Werte im TabellenfeldA der

Verarbeitungs-Eingangsmenge

TabellenfeldA.Count liefert die Anzahl unterschiedlicher Werte im TabellenfeldA der 0 Verarbeitungs-Eingangsmenge TabelleA.Count.TabellenFeldA liefert die Anzahl unterschiedlicher Werte im TabellenfeldA in der

TabelleA TabelleA. TabellenFeldA.Count liefert die Anzahl unterschiedlicher Werte im TabellenfeldA in der

TabelleA 5 TabellenfeldA.CountTabelleA liefert die Anzahl Datensätze in der Tabelle TabelleA je

TabellenfeldA TabellenfeldA.TabelleA.Count liefert die Anzahl Datensätze in der Tabelle TabelleA je

TabellenfeldA TabellenfeldA.Count.TabellenfeldB liefert die Anzahl unterschiedlicher Werte im TabellenfeldB je 0 TabellenfeldA der Verarbeitungs-Eingangsmenge TabellenfeldA.TabellenfeldB.Count liefert die Anzahl unterschiedlicher Werte im TabellenfeldB je

TabellenfeldA der Verarbeitungs-Eingangsmenge TabelleA.Count.TabelleB Liefert die Anzahl Elemente in der Tabelle TabelleB je zugehörigem der Tabelle TabelleA 5

Wie angeführt, ist in der Zuordnungstabelle eine weitere Spalte „E-VA-PrevCommand⁸" angelegt. Wird ein Eintrag in der Zuordnungstabelle aufgefunden, in welchem dieser Wert gesetzt ist, wird festgelegt, dass die bislang aktuelle Engine-Befehlskettenzeile des aktuellen RTN-Bausteins ihre momentane Engine-Verarbeitungsfunktion verwirft und mit dieser neuen Engine- Verarbeitungstunktion übersteuert.

Folgende Beispiele sollen dies zeigen:

Beispiel:

[ TabelleA.Count.TabellenfeldA.TabellenfeldB ]

Deutung aufgrund der Einträge in der Zuordnungstabelle: Gruppiere je unterschiedlichem Wert des Tabellenfeld TabellenfeldA in der Tabelle TabelleA und liefere je gruppiertem Element TabellenfeldA die Anzahl unterschiedlichen Werte des Tabellenfeld TabellenfeldB

Endgültiger Zugriffsplan, der für dieses Beispiel generiert wird:

Ro wl ForChildrenJUseSetOfPrev* Parameter: Row2

Row2 ReturnJValue Parameter: Row3,Row6

Row3 Get_TableMenge Parameter: TabelleA

Row4 Aggregate_Count kein Parameter

Row5 Get_TableValueValue Parameter: TabellenfeldA

Row6 GroupBy DolnGroupBy Parameter: Row4,Row8

Row7 Get TableFieldValue Parameter: TabellenfeldB

Row8 Aggregate_ForElements Parameter: Row5,Row7

Row9 Return LastMenge Parameter: Rowl

Die Erstellung dieses Zugriffsplans erfolgt nach dem gezeigten Verfahren. Da bei zwei Elementen in der Zuordnungstabelle „E-VA-PrevCommand⁸" aufgefunden wird, wurden die entsprechenden Engine- Verarbeitungsfunktionen in den Engine-Befehlskettenzeilen Row2 und Row6 ersetzt und es wird folgender endgültiger Zugriffsplan geliefert. Es werden die

Engine-Befehlskettenzeilen Row2 und Row6 | mit den Engine- Verarbeitungsfunktionen gezeigt, bevor diese aufgrund des aufgefundenen Eintrags in der Zuordnungstabelle übersteuert wurden: I

Row2 Aggregate_ForElements ψarameter: Row3,Row6

Ro w6 AggregateJDiffrentValues Parameter: Row4,Row8

Zwei weitere Beispiele werden gezeigt, in welchen die Spalte „E-VA-PrevCommand in der Zuordnungstabelle für einige aufgefundene Elemente einen Wert und somit eine Engine- Verarbeitungsfunktion aufweisen und somit vorher gesetzte Engine-Verarbeitungsfunktionen der jeweils aktuellen Engine-Befehlskettenzeile, also jener Engine-Befehlskettenzeile, die vor der neu angelegten Engine-Befehlskettenzeile im gleichen RTN-Baustein aktuell sind, übersteuern:

Beispiel:

[ TabelleA.Count.TabellenfeldA. WHERE (TabellenfeldB=10) ]

Deutung aufgrund der Einträge in der Zuordnungstabelle:

Zähle die Anzahl der unterschiedlichen Werte im Tabellenfeld TabellenfeldA der Tabelle TabelleA, für welche je TabellenfeldA zumindest ein Datensatz im TabellenfeldB den Wert 10 aufweist.

Endgültiger Zugriffsplan, der für dieses Beispiel generiert wird:

Rowl ForChildren UseSetOfPrev* Parameter: Row2

Row2 Return Value Parameter: Row3,Row6

Row3 Get_TableMenge Parameter: TabelleA

Row4 Aggregate_Count kein Parameter

Row5 Get_TableValueValue Parameter: TabellenfeldA

Row6 Aggregate_DiffrentValues Parameter: Row4,Rowll

Row7 SetOperation_WHERE Parameter: Row8

Row8 Bool_Value= Parameter: Row9,RowlO

Row9 Get_TableFieldValue Parameter: TabellenfeldB

RowlO Get_Value Parameter: 10

Rowl l GroupBy DolnGroupBy Parameter: Row5,Row7

Rowl 2 Return_LastMenge Parameter: Rowl

In diesem Zugriffsplan wird die Engine-Verarbeitungsfunktion der Engine-Befehlskettenzeile Row2 verändert: Es wird die Engine-Befehlskettenzeile Row2 gezeigt, bevor die ihr zugehörige Engine- Verarbeitungsfunktion übersteuert wurde: Row2 Aggregate_ForElements Row3,Row4

Die Veränderung der Parameter von Engine-Befehlskettenzeilen, wie sie sich durch die Spalte VS-Kom⁷ für aufgefundene Elemente in der Zuordnungstabelle ergeben, sind in der Beschreibung angeführt und werden an dieser Stelle nicht mehr gezeigt.

Beispiel:

[ TabelleA.TabellenfeldA.Count.TabellenfeldB. WHERE (TabellenfeldC=10) ] Deutung aufgrund der momentanen Einträge in der Zuordnungstabelle:

Gruppiere nach dem Tabellenfeld TabellenfeldA in der TabelleA und liefere je gruppieren Element TabellenfeldA die Anzahl unterschiedlicher Elemente des TabellenfeldB, für welche zugehörige Datensätze einen Wert im TabellenfeldC den Wert 10 aufweisen:

Endgültiger Zugriffsplan, der für dieses Beispiel generiert wird:

Rowl ForChüdren_UseSetOfPrev* Parameter: Row2

Row2 Rerurn_Value Parameter: Row3,Row6

Row3 Get_TableMenge Parameter: TabelleA

Row4 Get_TableFieldValue Parameter: TabellenfeldA

Row5 Aggregate_Count kein Parameter

Row6 GroupBy DomGroupBy Parameter: Row4,Row8

Row7 Get TableFieldValue Parameter: TabellenfeldB

Row8 Aggregate_DiffrentValues Parameter: Row5,Rowl3

Row9 SetOperation WHERE Parameter: RowlO

RowlO Bool_Value= Parameter: Rowll, Rowl 2

Rowl l Get_TableFieldValue Parameter: TabellenfeldC

Rowl2 Get_Value Parameter: 10

Rowl 3 GroupBy_DoInGroupBy Parameter: Row7,Row9

Rowl4 Return LastMenge Parameter: Rowl

In diesem Zugriffsplan wird die Engine-Verarbeitungsfunktion der Engine-Befehlskettenzeile Row6 verändert: Es wird die Engine-Befehlskettenzeile Row6 gezeigt, bevor die ihr zugehörige Engine-Verarbeitungsfunktion übersteuert wurde: Row6 Aggregate DiffrentValues Row4,Row5

Es gilt in den oben gezeigten sowie in sämtlichen anderen Beispielen, dass TabelleA und TabelleB eine MENGE darstellen, wodurch anstatt TabelleA jeweils ein beliebiger Bubble, welcher den Verarbeitungs- Ausgangstyp „Menge" liefert, gleichwertig verwendet werden kann.

Um diese und weitere Beispiele immer in einen entsprechenden Zugriffsplan umzuwandeln, wird folgende allgemeingültige Definition eingeführt: Ist ein RTN-Baustein bis zum Ende durchlaufen worden, liefere dem übergeordneten RTN- Baustein die als erstes im eingesetzten RTN-Baustein angelegte Engine-Befehlskettenzeile als aktuelle Engine-Befehlskettenzeile des im übergeordneten RTN-Baustein zuletzt eingesetzten RTN-Baustein zurück.

Die oben gezeigten Beispiele sind äquivalent für alle Aggregats-Funktionen anwendbar, also auch für Exists, None, Sum, Percent usw. Durch die Engine-Verarbeitungsfunktionen „Aggregate_ForElements" und „AggregateJDiffrentValues" wird festgelegt, dass die Engine- Verarbeitungsfunktion, welche in einer der als Parameter angegebenen Engine- Befehlskettenzeile aufzufinden ist, entweder auf die gesamte Menge oder auf die einzelnen Elemente angewandt wird.

Eine Auswertung von Statement- Ausschnitten wie lO.TabelleA WHERE (TabelleA.TabellenFeldA>5).10

10.TabellenfeldA Tabelle A. TabellenfeldA.10

TabelleA.10.TabellenfeldA TabelleA.10.TabelleB wird dem Fachmann überlassen. Die Umsetzung für eine oder mehrere Deutungen dieser und sämtlicher ähnlicher Fälle ist für den Fachmann aus der Beschreibung erkennbar und wird daher nicht mehr angeführt.

Es kann für eine Schreibweise TabelleA.TabelleB beispielsweise als eine weitere Deutung ebenso festgelegt werden, dass eine XML-Darstellung gewählt wird und die Datensätze der TabelleB, welche über zugehörige relationale Beziehungen auf entsprechende Datensätze der TabelleA verweisen, diesen Datensätzen hierarchisch untergeordnet werden.

Weitere Deutungsvarianten sind für die gezeigten sowie für alle weiteren RTN-Bausteine und Entscheidungspositions- Verarbeitungsinformationen in der Zuordnungstabelle möglich. So kann dem Statement-Ausschnitt TabelleA.TabellenfeldA.Count mittels entsprechenden Einträgen in der Zuordnungstabelle zumindest zwei Deutungen zugeordnet werden:

Zähle die Anzahl unterschiedlicher Werte im TabellenfeldA in der TabelleA Gruppiere nach dem Tabellenfeld A in der Tabelle A und zähle je Element die Anzahl der zusammengefassten Elemente

In jenen Fällen, wo an einer Stelle einer angegebenen Syntax ein Tabellenname, ein Punkt als vordefiniertes Trennzeichen und ein Tabellenfeldname steht, muss geprüft werden, ab dieses Tabellenfeld der vorhergehenden Tabelle zugehörig ist.

Als Beispiel wird der Syntax-Ausschnitt TabelleA.TabellenfeldB verwendet und es wird davon ausgegangen, dass das TabellenfeldB nicht der TabelleA, sondern der TabelleB zugehörig ist. Wird eine derartige fehlende Tabelle festgestellt, kann eine relationale Verbindung beispielsweise mittels der Tabelle der Relationen von der TabelleA auf die TabelleB gesucht und für die Zugriffsplanerstellung berücksichtigt werden. Zumindest ein derartiges Verfahren ist im Stand der Technik beschrieben und kann dafür herangezogen werden.

Eine weitere Deutungsmöglichkeit für TabellenfeldA.TabellenfeldB kann sein, dass die beiden Werte dieser beiden Tabellenfelder zu einem String zusammengesetzt werden. Ein entsprechender Eintrag in der Zuordnungstabelle wird nicht mehr gezeigt.

Es wird ein Beispiel gezeigt, welches den RTN-Baustein „Verarbeitung_SameParents" verwendet. Für die Verarbeitung dieses RTN-Bausteins ist es notwendig, einen neuen Wert TakeSameParamsLikeFirst V AFunction für die Spalte VS-Kom⁷ einzuführen, welcher bei Auffinden eines zugehörigen Elements in der Zuordnungstabelle folgende Schritte ausführt:

1. Lege eine neue Engine-Befehlskettenzeile für den aktuellen RTN-Baustein an und füge diesem RTN-Baustein als Parameter all jene Parameter an, welche die aktuelle Engine-Befehlskettenzeile in diesem RTN-Baustein definiert hat.

2. Füge der aktuellen Engine-Befehlskettenzeile des aktuellen RTN-Bausteins diese neu angelegte Engine-Befehlskettenzeile als weiteren Parameter an.

Zugehörige Einträge in der Zuordnungstabelle:

Somit werden folgende Beispiele in die jeweiligen Zugriffspläne umgewandelt:

Beispiel:

[WHERE TabellenfeldA = // 10 20 TabellenfeldBW]

Deutung: Liefere alle Datensätze, für welche das Tabellenfeld TabellenfeldA entweder den Wert 10, 20 oder

TabellenfeldB aufweist.

Aufgrund der Elemente der Zuordnungstabelle erstellter Zugriffsplan:

Rowl ForChildrenJJseSetOfPrev* Parameter: Row2

Row2 SetOperation_WHERE Parameter: Row3

Row3 Bool_IN_Right Parameter: Row4, Row5

Row4 Get_TableFieldValue Parameter: TabellenfeldA

Row5 ForChildren_UseSameEingangsMenge Parameter: Row6,Row7,Row8,Row9

LastlsCommand

Röwo Get_Value Parameter: 10

Row7 Get_Value Parameter: 20

Row8 Get TableFieldValue Parameter: TabellenfeldB

Row9 Combine ValuesToSet Parameter: Row6,Row7,Row8

RowlO Return_LastMenge Parameter: Rowl Beispiel:

[ TabelleA.//WHERE TabellenPeldA WHERE TabellenfeldBW.Count ]

Deutung: liefere die Anzahl der Datensätze in der Tabelle, für welche das TabellenfeldA und/oder das

TabellenfeldB jeweils einen Wert o 0 und o Null aufweist.

Für dieses Beispiel generierter Zugriffsplan:

Rowl ForChildrenJtJseSetOfPrev* Parameter: Row2

Row2 Return Value Parameter: Row3, Rowll

Row3 Get_TableMenge Parameter: Tabellen

Row4 ForChildren_UseSameEingangsMenge Parameter: Row5,Row7,R

_LastIsCommand

Row5 SetOperation WHERE Parameter: Row6

Row6 GetJTableFieldValue Parameter: TabellenfeldA

Row7 SetOperation WHERE Parameter: Row8

Row8 Get_TableFieldValue Parameter: TabellenfeldB

Row9 SetOperation_UNION Parameter: Row5,Row7

RowlO Aggregate Count kein Parameter

Rowl l Aggregate_ForElements ι Row4,Rowl0

Rowl2 Return LastValue , Parameter: Rowl

Aufgrund der in der Beschreibung gezeigten Logik der einzelnen RTN-Bausteine kann das gleiche Beispiel gleichwertig auch mit folgenden Statements dargestellt werden, wodurch sich ein anderer Zugriffsplan ergibt, welcher in der Abarbeitung das selbe Ergebnis liefert:

[ TabelleA //WHERE TabellenFeldA WHERE TabellenfeldBW Count ^']

Für dieses gleichwertige Beispiel generierter Zugriffsplan:

Rowl ForChildrenJQseSetOfPrev* i Parameter: Row2,Row3,Row9

Row2 Get TableMenge ( Parameter: TabelleA

Row3 ForChildrenJUseSameEingangsMenge Parameter: Row4,Row6,Row8

_LastIsCommand

Row4 SetOperation_WHERE Parameter: Row5

Row5 Get_TableFieldValue Parameter: TabellenfeldA

Row6 SetOperationJWHERE Parameter: Row7

Row7 Get TableFieldValue Parameter: TabellenfeldB

Row8 SetOperation UNION I Parameter: Row5,Row7

Row9 Aggregate_Count kein Parameter

RowlO Return LastValue Parameter: Rowl

ISA Das gezeigte Beispiel dient einzig zur Erläuterung und kann ebenso auf mehrere andere Weisen darstellt werden, so zum Beispiel:

[ TabelleA WHERE TabellenFeldA OR TabellenfeldB Count ]

Komplexe Verwendungen des RTN-Bausteins „Verarbeitung_SameParents" sowie aller anderen RTN-B austeine sind natürlich möglich, da sie aber dem gezeigten Prinzip folgen, werden sie nicht mehr ausgeführt.

Es werden zwei weitere Einträge in der Zuordnungstabelle gezeigt, wobei einer von diesen einen Wert in der Spalte EP-VI-E² aufweist.

Ein betroffenes Statement, dessen Analyse nach dem offenbarten Verfahren erfolgt, wird ohne zugehörigen Zugriffsplan als Beispiel gezeigt:

[TabelleA ANY (>=2) TAbellenfeldA,TabellenfeldB, TabellenfeldC = 10,20,30] Deutung: Liefere alle Datensätze der Tabelle TabelleA, in welchen zumindest zwei der drei Tabellenfeld entweder den Wert 10, 20 oder 30 stehen haben.

Es wird angemerkt, dass es auch für dieses Beispiel unterschiedliche Schreibweisen und Deutungen gibt, welche aufgrund der Beschreibung für den Fachmann ersichtlich sind und daher nicht gezeigt und angeführt werden.

Es wird festgestellt, dass es mehrere Möglichkeiten gibt, Informationen in der Zuordnungstabelle zu speichern, so können unterschiedliche Spaltennamen oder eine unterschiedliche Anzahl an Spalten aufweisen, welche beispielsweise je Element jeweils festlegen, ob eine neue Engine-Befehlskettenzeile erstellt werden soll, ob Parameter vertauscht werden sollen usw. Weitere Ausfuhrungsformen für die Zuordnungstabelle sind für den Fachmann erkennbar und werden daher nicht in der Beschreibung ausgeführt.

Das hier gezeigte Verfahren kann vorzugsweise auch automatisch einen Programmcode einer Programmiersprache der dritten Generation umgewandelt werden. Dies geschieht beispielsweise, indem die Einträge in der Zuordnungstabelle als SELECT-CASE- Anweisungen konvertiert werden. Die Darstellungsform als Zuordnungstabelle wurde gewählt, da diese einfach zu erweitern und vor allem sehr übersichtlich ist.

Eine automatisch Umwandlung insbesondere der Umordnungstabelle, aber auch der RTN- Bausteine mit deren verarbeitungsrelevanten RTN-Baustein-Informationen kann jederzeit mittels eines einfachen Algorithmus erfolgen. Dies ist empfehlenswert, sobald eine sinnvolle, aber jederzeit erweiterbare Gesamtheit an RTN-Bausteinen, an Entscheidungspositions- Verarbeitungsinformationen, an Engine- Verarbeitungsfunktionen und eine sinnvolle Befüllung der Zuordnungstabelle vorhanden ist. Eine Abarbeitung eines Programmcodes ist schneller als eine Abarbeitung einer Zuordnungstabelle, die beispielsweise in ein Array eingelesen wird. Gleiches gilt für die inneren, gerichteten Entscheidungsgraphen der RTN- Bausteine und deren verarbeitungsrelevanten RTN-Baustein-Informationen.

Es bleibt dem Fachmann überlassen, weitere Spalten in der Zuordnungstabelle zu definieren und diese in das Verfahren einzubeziehen.

Es können auch weitere Verarbeitungstypen definiert werden, um die Analyse von Statements zu verfeiern. So kann unterschieden werden, ob ein Tabellenfeld, eine Variable, einer

Konstante oder eine (System)Funktion eine Zahl oder einen Text liefert. Diese

Verarbeitungstypen werden in der Zuordnungstabelle für entsprechende

Entscheidungspositions-Verarbeitungsinfomiationen definiert. So können ein

Verarbeitungstyp „Value_String" und ein Verarbeitungstyp „Value_Number" definiert werden. Weiters kann der Verarbeitungstyp „Value" die beiden Verarbeitungstypen

„Value_String" und „ValueJSTumber" zusammengefasst beinhalten. Ebenfalls kann auch der Verarbeitungstyp „Tabellenfeld" detaillierter in der Zuordnungstabelle eingetragen und verarbeitet werden, indem zum Beispiel die Verarbeitungstypen „Tabellenfeld-Boolean", „Tabellenfeld-Byte", „Tabellenfeld-Integer", „Tabellenfeld-Long", „Tabellenfeld-Text", „Tabellenfeld-Date", Tabellenfeld-Memo" usw. erstellt werden. Somit kann der Verarbeitungstyp „Tabellenfeld" eine Sammlung dieser unvollständig aufgezählten Verarbeitungstypen darstellen, um in jenen Fällen, in denen eine detaillierte Typenangabe eines Tabellenfeld keine Bedeutung hat, jeweils gleich zu behandeln. Ebenso können Verarbeitungstypen „Tabellenfeld-Index" usw. eingeführt werden, wobei die jeweilige Indizierungsart berücksichtig werden kann und somit ein Zugriffsplan erstellt werden kann, welcher diese Indizierungen ebenfalls im Optimierungsprozess berücksichtig.

Gleichfalls kann der Verarbeitungstyp „Menge" weiters in „Tabelle" und „Berechnete Menge" unterteilt werden, wobei hier wiederum, beispielsweise unter Zuhilfenahme eines Statistikmanagers, in Tabellen bzw. Mengen mit wenigen, mittleren oder vielen Datensätzen unterschieden werden kann.

Diese weiteren Unterteilungen werden nicht im Detail beschrieben, da der Fachmann diese Aufgrund der Beschreibung erkennen und entsprechend in der Zuordnungstabelle und im Zugriffsplan-Erstellungsschritt implementieren kann.

Mittels dieser und weiteren Verfeinerungen lassen sich noch detailliertere Einträge in der Zuordnungstabelle sowie eine besser angepasste kontextsensitive Syntaxanalyse vornehmen.

Eine weitere, insbesondere „Low-LeveF'-Analyse des Zugriffsplans, welcher den mittels der Zuordnungstabelle erstellten Zugriffsplan im Sinne der Speicherverwaltung, Mehrbenutzer- Fähigkeit, dauerhafter Datenkonsistenz, in der Wahl der jeweils besten Joins usw. optimiert, wird empfohlen. Diese Optimierungen sind im Stand der Technik weitgehend bekannt und somit für den Fachmann ausgehend von den jeweils erstellten Zugriffsplänen möglich.

Die innere Struktur und Befehlszeilen der jeweiligen Engine- Verarbeitungsfunktionen wird ebenfalls nicht gezeigt, da diese für den Fachmann viel Optimierungspotenzial bieten und von diesem jeweils programmiert werden können. Der extreme Vorteil einer auf RTN-Bausteinen gegenüber einer auf einem Gesamt-RTN basierenden Anwender-Sprache liegt in der extremen Überlegenheit in der Ausdruckskraft derselben. Jede zulässige Syntax, welche in einem Gesamt-RTN ermöglicht wird, kann ident mittels RTN-Bausteinen ermöglicht werden. Vielmehr können in einem Gesamt-RTN syntaktisch beschriebene, aber in ihrer Reihenfolge vorgegebene Verarbeitungsbereiche als RTN-Bausteine definiert und unabhängig von deren Reihenfolge und Verschachtelung in einem Anwender-Statement angegeben werden. Ebenso können einfach neue Verarbeitungsbereiche definiert und mit den vorhandenen beliebig kombiniert werden. Ebenso ist es durch RTN-Bausteine und deren inneren, gerichteten Entscheidungsgraphen möglich, jede Funktionalität bereits vorhandener, sehr ausgereifter Anfragesprachen, deren bekanntester Vertreter SQL ist, unverändert zu erreichen. Somit können jegliche in einer Anfragesprache bereits geschriebene Statements unverändert mittels einer Anfragesprache, die auf RTN-Bausteinen beruht, analysiert und in einen optimierbaren Zugriffsplan umgewandelt werden.

Eine weitere Optimierung des Zugriffsplans, welcher zum Beispiel Index-Felder, Statistikmanager usw. berücksichtigt, ist durch den Fachmann möglich. Dies ist aber nicht Teil der Erfindung, da sich die Erfindung auf die kontextsensitive Deutung von Anfragestatements bezieht, welchen ein auf RTN-Bausteinen basierendes RTN zugrunde liegt.

Tabelle 1

RTN-Bausteine vor Umwandlunqsschritt:

OHNE Entscheidunqsposition 300 an erster Stelle _{UOrd Gew 1 /2 Gew}

Tabellen-RTN-Baustein 200 200 / 1

Zahlen/Text-RTN-Baustein 200 200 / 1

V:Zahl,Text

Zeilenauswählender RTN-Baustein 200 200 / 200

"WHERE" *

Extremwert-RTN-Baustein 200 200 / 200

("MIN" I "MAX" ) *

Ebenen-RTN-Baustein 0 200 / 25S

T (I) * K* I)] T

RTN-Bausteine-Zusammenfassender RTN-Baustein 1 200 / 2S₅

"(" * ")"

Verarbeitung_SameParents-RTN-Baustein 200 200 / 2₅₅

"/" "/" (l) * [(*i)] "\" "\"

Verarbeitung_PrevParents-RTN-Baustein 200 200 / 255

"RESULTOF" "(" (1) * [(*1)] ")"

Mengensortier RTN-Baustein SO 200 / 25₅

"ORDERBY" *

Aggregats-RTN-Baustein, Parameterlos 249 200 /2₅₅ ("Count" I "Exists" | "None" )

Aggregats-RTN-Baustein, 1 Parameter 249 200 /200 ("Sum" 1 "AVG" I "Return" ) "(" * ")"

All/Any-RTN-Baustein 1 200 / 1

("ALL" I "ANY" ) ["(" ("<" "=" I ">" "=" I "=" ) V:Zahl ")"] *

FIND-RTN-Baustein 249 200 / 2₅₅

"FIND" * [":" (1) * [(*1)] "END" "FIND" ]

Konstanten-RTN-Baustein 200 200 / 200

NEXT/PREV-RTN-Baustein 249 200 / 255

("NEXT" I "PREV" ) "(" [("- ' I ">" "=" ] "<" "=" )] * ")"

FOR-Next-RTN-Baustein 249 200 / 255

"FOR" * ":" * "NEXT"

ReI. BoolRTN-Baustein 249 200 / 200

("FINDNEXT" I "FINDPREV" ) *

ReL Zeilenauswählender RTN-Baustein 249 200 / 200

("MUSTNEXT" I "MUSTPREV" ) *

Do-Loop Until-RTN-Baustein 249 200 / 255 "DO" (":" * "LQOP" "UNTIL" * | "UNTIL" * ":" * "LQQP")

Abs. BoolRTN-Baustein 249 200 /200

("FIRST" I ¹¹LAST" ) * ^' Wenn-Dann-RTN-Baustein 1 200 /2₅₅

"IF" * "THEN" * ["ELSE" *] ["END" "IF"]

Select-Case-RTN-Baustein 1 200 /2S5

"SELECT" "CASE" * ":" (1) "CASE" [("<" "=" | ">" "=" | "=" | "<" "> " )] * "... * [(*!)] ["CASE" "ELSE" ":" *] "END" "SELECT"

Verneinender Boolean 1 200/200

"NOT" *

SELECT-RTN-Baustein 0 200/200

"SELECT" *

Gruppenbruch-RTN-Baustein 249 200 /2₅₅

"BREAKON" * [":" (1) * [(*1)] "END" "BREAKON" ]

Zeilenzusammenfassender RTN-Baustein 200 200/255

"GROUPBY" * [":" (1) * [(*1)] "END" "GROUPBY" ]

Prozent-RTN-Baustein 20Ö 200/200

"PERCENT" *

Ebenen-Start-Eingangsmengenbilder RTN-Baustein 2₅0 200/200

"FROM" *

TabellenFeld-RTN-Baustein 200 200/1

#Zahl!

Distinct-RTN-Baustein 200 200/200

"DISTINCT" *

RTN-Bausteine vor Umwandlunqsschritt:

MIT Entscheidungsposition 300 an erster Stelle UOrd. Gew. 1./2. Gew.

Werte- Verkettungs-RTN-Baustein 1 4/4

Strich-Rechen-Operationen-RTN-Baustein 1 17/17

Punkt-Rechen-Operationen-RTN-Baustein 1 14/14

* ("*" 1¹V" I "\" I "MOD" ) *

Potenz-Rechen-Operationen-RTN-Baustein 1 10/10

Vergleichs-RTN-Baustein 1 50/50

* ("=" i "<" i ">" i »>" "=" I "<" "=" i "<" ">" ) *

Bool-Kombi-RTN-Baustein 1 100/100

* ("AND" I "OR" I "XOR" ) *

Mengenelemente-Begrenzender RTN-Baustein 249 250/250

* "#" [("=" i ">" "=" i "<" "=" i "<" ">" )] ["%"] *

Mengen-Zusammenführender RTN-Baustein I 250/250

* ("UNION" "ALL" * I "UNION" * | "INTERSECT" * | "EXCLUDE" *)

Mengenelement-Bildender-RTN-Baustein 1 30/30

Way-Part-RTN-Baustein 1 250/255

* "-" ">" * ["OVER" *]

ZwischenMengen-RTN-Baustein 249 250/250

* "AS" V:Zwischenmengenname

Vergleich-IN-RTN-Baustein 1 60/255

* "IN" "(" * ")" Mengensortier RTN-Baustein (DESC PART) ^{l 19}° ' ¹⁹⁰

* "DESC"

Tabelle 2

RTN-Bausteine nach Umwandlungsschritt: 1. Gattungsgruppe UOrd. Gew. 1./2. Gew.

Tabellen-RTN-Baustein 200 200 / 1

Zahlen/Text-RTN-Baustein 200 200 / 1

V:Zahl,Text [RTN-Baustein zweite Gattungsgruppe]

Zeilenauswählender RTN-Baustein 200 200 / 200

"WHERE" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Extremwert-RTN-Baustein 200 200 / 20ö

("MIN" I "MAX" ) RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Ebenen-RTN-Baustein 0 200 /2S5

"[" (1) RTN-Baustein erste Gattungsgruppe [(*!)] "]" [RTN-Baustein zweite Gattungsgruppe]

RTN-Bausteine-Zusammenfassender RTN-Baustein 1 200 / 2₅₅

"(" RTN-Baustein erste Gattungsgruppe ")" [RTN-Baustein zweite Gattungsgruppe]

VerarbeitungJSameParents-RTN-Baustein 200 200 /2₅₅

"/" "/" (1) RTN-Baustein erste Gattungsgruppe [(*1)] "\" "\" [RTN-Baustein zweite Gattungsgruppe]

Verarbeitung_PrevParents-RTN-Baustein 200 200 /2S5

"RESULTOF" "(" (1) RTN-Baustein erste Gattungsgruppe [(*1)] ")" [RTN-Baustein zweite Gattungsgruppe]

Mengensortier RTN-Baustein ⁵O 200 / 2S₅

"ORDERBY" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Aggregats-RTN-Baustein, Parameterlos 249 200 /2₅5

("Count" I "Exists" | "None" ) [RTN-Baustein zweite Gattungsgruppe]

Aggregats-RTN-Baustein, 1 Parameter 249 200 /200

("Sum" I "AVG" I "Return" ) "(" RTN-Baustein erste Gattungsgruppe ")" [RTN-Baustein zweite Gattungsgruppe]

AlI/Any-RTN-Baustein 1 200/ 1

("ALL" I "ANY" ) ["(" ("<" "=" I ">" "=" I "=" ) V:Zahl ")"] RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

FIND-RTN-Baustein 249 200 / 255

"FIND" RTN-Baustein erste Gattungsgfuppe [":" (1) RTN-Baustein erste Gattungsgruppe [(*1)] "END" "FIND" ] [RTN-Baustein zweite Gattungsgruppe]

Konstanten-RTN-Baustein 200 200 / 200

NEXT/PREV-RTN-Baustein 249 200 / 255

("NEXT" I "PREV" ) "(" [("=" I ">" "=" | "<" "=" )] RTN-Baustein erste Gattungsgruppe ")" [RTN-Baustein zweite Gattungsgruppe]

FOR-Next-RTN-Baustein 249 200 /255

"FOR" RTN-Baustein erste Gattungsgruppe ":" RTN-Baustein erste Gattungsgruppe "NEXT" [RTN-Baustein zweite Gattungsgruppe]

ReL BoolRTN-Baustein 249 200 /200

("FINDNEXT" I "FINDPREV" ) RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

ReI. Zeilenauswählender RTN-Baustein 249 200 / 200

("MUSTNEXT" I "MUSTPREV" ) RTN-Baustein erste Oattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Do-Loop Until-RTN-Baustein 249 200 /255

"DO" (":" RTN-Baustein erste Gattungsgruppe "LOOP" "UNTIL" RTN-Baustein erste Gattungsgruppe | "UNTIL" RTN-Baustein erste Gattungsgruppe ":" RTN-Baustein erste Gattungsgruppe "LOOP") [RTN-Baustein zweite Gattungsgruppe] Abs. BoolRTN-Baustein 249 2ÖÖ / 200

("FIRST" I "LAST" ) RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Wenn-Dann-RTN-Baustein 1 20ö / 2₅₅

"IF" RTN-Baustein erste Gattungsgruppe "THEN" RTN-Baustein erste Gattungsgruppe ["ELSE" RTN-Baustein erste Gattungsgruppe] ["END" "IF"] [RTN-Baustein zweite Gattungsgruppe]

Select-Case-RTN-Baustein 1 200 / 2SS

"SELECT" "CASE" RTN-Baustein erste Gattungsgruppe ":" (1) "CASE" [("<" "=" | ">" "=" | "=" ) "<" ">" )] RTN-Baustein erste Gattungsgruppe ":" RTN-Baustein erste Gattungsgruppe [(*1)] ["GASE" "ELSE" ":" RTN-Baustein erste Gattungsgruppe] "END" "SELECT" [RTN-Baustein zweite Gattungsgruppe]

Verneinender Boolean 1 200 / 200

"NOT" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

SELECT-RTN-Baustein 0 200 / 200

"SELECT" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Gruppenbruch-RTN-Baustein 249 200 / 2SS

"BREAKON" RTN-Baustein erste Gattungsgruppe [":" (1) RTN-Baustein erste Gattungsgruppe [(*1)] "END" "BREAKON" ] [RTN- Baustein zweite Gattungsgrappe]

Zeilenzusammenfassender RTN-Baustein 200 200 / 2₅₅

"GROUPBY" RTN-Baustein erste Gattungsgruppe [":" (1) RTN-Baustein erste Gattungsgruppe [(*1)] "END" "GROUPBY" ] [RTN- Baustein zweite Gattungsgruppe]

Prozent-RTN-Baustein 200 200 / 200

"PERCENT" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

Ebenen-Start-Eingangsmengenbilder RTN-Baustein 250 200 / 200

"FROM" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

TabellenFeld-RTN-Baustein 200 200 / 1

#Zahl!

Distinct-RTN-Baustein 200 200 / 200

"DISTINCT" RTN-Baustein erste Gattungsgruppe [RTN-Baustein zweite Gattungsgruppe]

RTN-Bausteine nach Umwandlungsschritt: 2. Gattungsgruppe UOrd. Gew. 1./2. Gew.

Werte-Verkettungs-RTN-Baustein 1 4 / 4

"." RTN-Baustein erste Gattungsgruppe

Strich-Rechen-Operationen-RTN-Baustein 1 17 / 17

("+" I "-" ) RTN-Baustein erste Gattungsgruppe

Punkt-Rechen-Operationen-RTN-Baustein 1 14 / 14

("*^■• I ^»/" i "\" I "MOD" ) RTN-Baustein erste Gattungsgruppe

Potenz-Rechen-Operationen-RTN-Baustein 1 10 / 10

"^Λ" RTN-Baustein erste Gattungsgruppe

Vergleichs-RTN-Baustein 1 50 / ₅0

(,₁₌₁₁ i „<„ i „>„ i «>» n_i, i „<,. ,ι₌i. i ..<-. ..>.. ) RTN-Baustein erste Gattungsgruppe

Bool-Kombi-RTN-Baustein 1 100 / 100

("AND" I "OR" I "XOR" ) RTN-Baustein erste Gattungsgruppe

Mengenelemente-Begrenzender RTN-Baustein 249 250 / 250

"#^» [(^»=^» i ^»>^» "=" i "<" "=" I "<" ">" )] ["%"] RTN-Baustein erste Gattungsgruppe

Mengen-Zusammenführender RTN-Baustein 1 250 /250

("UNION" "ALL" RTN-Baustein erste Gattungsgruppe | "UNION" RTN-Baustein erste Gattungsgruppe | "INTERSECT" RTN- Baustein erste Gattungsgruppe | "EXCLUDE" RTN-Baustein erste Gattungsgruppe)

Mengenelement-Bildender-RTN-Baustein 1 30 / 30

"," RTN-Baustein erste Gattungsgruppe Way-Part-RTN-Baustein l 2S0 /2S5 ^ti.^{n ■■}>«^! RTN-Baustein erste Gattungsgruppe ["OVER" RTN-Baustein erste Gattungsgruppe]

ZwischenMengen-RTN-Baustein 249 250 /2₅0

"AS" V:Zwisohenmengenname [RTN-Baustein zweite Gattungsgruppe]

Vergleich-IN-RTN-Baustein 1 60 /255

"IN" "(" RTN-Baustein erste Gattungsgruppe ")" [RTN-Baustein zweite Gattungsgruppe]

Mengensortier RTN-Baustein (DESC PART) 1 190 / 190

"DESC" [RTN-Baustein zweite Gattungsgruppe]

Tabelle 3

Elemente ! der RTN-Baustein-unabhängigen Verweisgruppe:

Entscheidungspositionsnummer + Schlüsselwort Verweis auf Rest-Entscheidungsgraph

1 - XGroup ¹WHERE¹ Liste 2: Zeile 5

;2 - XGroup 'MIN' Liste 2: Zeile 7

:3 - XGroup 'MAX' Liste 2: Zeile 6

!4 - XGroup T Liste 2: Zeile 8

6 - XGroup ¹C Liste 2: Zeile 10

8 - XGroup V Liste 2: Zeile 12

10 - XGroup 'RESULTOF¹ Liste 2: Zeile 16

11 - XGroup ¹ORDERBY¹ Liste 2: Zeile 19

12 - XGroup ¹COUNT' Liste 2: Zeile 21

=13 - XGroup ¹EXISTS¹ Liste 2: Zeile 22

14 - XGroup 'NONE' Liste 2: Zeile 20

15 - XGroup 'SUM' Liste 2: Zeile 26

16 - XGroup ¹AVG¹ Liste 2: Zeile 29

17 - XGroup 'RETURN' Liste 2: Zeile 23

18 - XGroup 'ALL' Liste 2: Zeile 33

19 - XGroup ¹ANY' Liste 2: Zeile 32

23 - XGroup 'FIND' Liste 2: Zeile 64

:26 - XGroup 'NEXT Liste 2: Zeile 72

27 - XGroup ¹PREV Liste 2: Zeile 69

;28 - XGroup 'FOR' Liste 2: Zeile 97

29 - XGroup ¹FINDNEXT' Liste 2: Zeile 102

'30 - XGroup ¹FINDPREV¹ Liste 2: Zeile 101

:31 - XGroup 'MUSTNEXT¹ Liste 2: Zeile 104

32 - XGroup 'MUSTPREV Liste 2: Zeile 103

.33 - XGroup 'DO' Liste 2: Zeile 105

36 - XGroup 'FIRST' Liste 2: Zeile 116

37 - XGroup 'LAST' Liste 2: Zeile 115

38 - XGroup 'IF' Liste 2: Zeile 117

41 - XGroup 'SELECT Liste 2: Zeile 126

43 - XGroup 'NOT' Liste 2: Zeile 191

44 - XGroup 'BREAKON' Liste 2: Zeile 193

45 - XGroup ¹GROUPBY' Liste 2: Zeile 198

46 - XGroup 'PERCENT¹ Liste 2: Zeile 203

47 - XGroup ¹FROM' liste 2: Zeile 204

48 - XGroup ^" OISTiNCT Liste 2: Zeile 205

^46 - XGrOUp LongStringValues 1 Liste 2: Zeile 1

247 - XGroup LongStringValues 2 Liste 2: Zeile 2

.248 - XGroup LongStringValues 3 Liste 2: Zeile 3 ä254 - XGroup VARIABLE Liste 2: Zeile 4

8 - YGroup T Liste 2: Zeile 211

<9 - YGroup ¹V _;Liste 2: Zeile 212

20 - YGroup '<' Liste 2: Zeile 214

21 - YGroup '=' Liste 2: Zeile 216

22 - YGroup '>' I Liste 2: Zeile 218

•49 - YGroup 7 \ Liste 2: Zeile 206

;50 - YGroup '+' 'liste 2: Zeile 208

51 - YGroup jliste 2: Zeile 207

52 - YGroup ! Liste 2: Zeile 210

.53 - YGroup 'MOD' 'liste 2: Zeile 209

54 - YGroup Liste 2: Zeile 213

^;55 - YGroup ¹AND' ;Liste 2: Zeile 224

56 - YGroup 'OR' Liste 2: Zeile 225 Entscheidungspositionsnummer + Schlüsselwort Verweis auf Rest-Entscheidungsgraph

;57 - YGroup 'XOR' Liste 2: Zeile 223

58 - YGroup '#' Liste 2: Zeile 226

!60 - YGroup 'UNION' Liste 2: Zeile 248

;61 - YGroup ¹INTERSECT' Liste 2: Zeile 251

62 - YGroup 'EXCLUDE' Liste 2: Zeile 247

63 - YGroup Liste 2: Zeile 252

.65 - YGroup ¹AS' Liste 2: Zeile 257

66 - YGroup 'IN¹ Liste 2: Zeile 258

:67 - YGroup 'DESC Liste 2: Zeile 261

Tabelle 4

Rest-Entscheidungsgraphen je Elemente der RTN-Baustein-unabhängigen Verweisgruppe aus Tabelle 3

Zeile Entscheidungspositionsnummer Jump-False Jump-True

1 MUST 255 °lnit_Table° EXIT

2 MUST 255 °lnit_SysFunction° EXIT

3 MUST _:255 °lnit_TableField° EXIT

4 MUST 255 °lnit_Value° EXIT

5 MUST _S251 * °SetOperation_Where° EXIT

6 MUST 251 •* °SetOperation_lvlax⁰ EXIT

7 MUST 251 °SetOperation_Min° EXIT

8 MUST ι251 °ForChildren_UseSetOfPrev*° JUMP:9

9 CAN 5 ELSE JUMP:8 EXIT

10 MUST :251 "noVA" JUMP:11

11 MUST 7 T EXIT

12 MUST 8 V °ForChildren_UseSameEingangslvl JUMP:13

13 MUST 251 * JUMP:14

14 CAN 9 ¹V ELSE JUMP:13 JUMP:15

15 MUST 9 ¹Y EXIT

16 MUST 6 ¹C °ForChildren_UseSetOfPrev*° JUMP.17

17 MUST j251 * JUMP:18

18 CAN 7 T ELSE :JUMP:17 EXIT

:19 ^" MUST 251 !_* °SetOperation_OrderBy° EXIT

;²p MUST 255 °Aggregate_None° EXIT

21 MUST 255 °Aggregate_Count° EXIT

Ϊ22 MUST ;255 °Aggregate_Exists° EXIT

23 MUST 6 JUMP:24

.24 MUST 251 _* JUMP:25

25 MUST :7 EXIT

^■26 MUST |6 ¹C °Aggregate_Sum° JUMP:27

27 MUST 251 _* JUMP:28

28 MUST 7 ')' EXIT

29 MUST 6 T °Aggregate_AVG° JUMP:30

30 MUST 251 JUMP:31

31 MUST 7 EXIT _ä32 CAN ;251 ELSE =JUMP:34 °Extend_Any° EXIT

=33 CAN 251 ELSE JUMP:39 Εxtend_AII° EXIT

•34 MUST .6 °Extend_Any° JUMP:35

.35 CAN 21 ELSE JUMP:44 °Param_Comp=° JUIvlP:36

:36 MUST 254 variable JUMP:37

.37 MUST 7 JUMP:38

38 MUST 251 EXIT

:39 MUST ^;6 ¹C Εxtend_AII° JUMP40

40 CAN -21 ELSE JUMP49 °Param_Comp=° JUMP:41

41 MUST 254 variable JUMP:42

42 MUST 7 . D¹ JUWIP:43

43 MUST .251 EXIT

44 CAN 20 ELSE JUMP:54 °Param_Comp=° JUMP:45

45 MUST 21 °Param_Comp<=° JUMP:46

46 MUST 254 variable JUMP:47

.47 MUST 7 ')' JUMP:48

48 MUST 251 * EXIT

49 CAN 20 ELSE JUMP:59 "Param_Comp=° JUMP:50

50 MUST .21 °Param_Comp<=° JUMP:51 Zeile Entscheidungspositionsnummer Jump-False Jump-True

51 MUST 254 variable JUMP:52

52 MUST 7 T JUMP:53

53 MUST ^'251 EXIT

54 MUST 22 ^■>^■ °Param_Comp=° JUMP:55

55 MUST 21 °Param_Comp>=° JUMP:56

56 MUST 254 variable JUMP:57

57 MUST 7 = )' JUMP:58

58 MUST 251 * EXIT

59 MUST 22 "Param_Comp=° JUMP:60

60 ^' MUST .21 °Param_Comp>=° JUMP:61

61 MUST _:254 variable JUMP:62

62 MUST 7 JUMP:63

63 MUST :251 * EXIT

64 MUST 1251 :* °Record_Find° JUMP:65

65 CAN 24 ELSE EXIT JUMP:66

66 ^' MUST ^'251 JUMP:67

67 CAN 25 ¹END' ELSE JUMP:66 JUMP.68

68 MUST 23 'FIND' °Record_EndFind° EXIT

69 MUST 6 ¹C °SetOperation_Prev° JUMP70

70 CAN 251 _* ELSE JUMP:75 JUMP:71

71 MUST 7 EXIT

72 MUST ^;6 °SetOperation_Next° JUMP73

73 CAN 251 _* ELSE JUMP:79 JUMP74

74 ^" MUST 7 y EXIT

75 CAN 20 ELSE JUMP:83 JUMP76

:76 MUST '21 °Param_Comp<=° JUMP:77

77 MUST 251 JUMP:78

78 MUST 7 ^■)^■ EXIT

79 CAN 20 ^■<^■ ELSE JUMP:86 JUMP:80

.80 MUST 21 °Param_Comp<=° JUMP:81

81 MUST 251 * JUMP:82

^!82 MUST 7 EXIT

83 CAN ^21 ;'=' ELSE JUMP:89 °Param_Comp=° JUMP:84

84 MUST =251 JUMP:85

85 MUST 7 EXIT

86 CAN 21 ELSE JUMP:93 °Param_Comp=° JUMP:87

87 MUST 251 - JUMP:88

=88 MUST 7 y EXIT

.89 MUST 22 •>' °Param_Comp=° JUMP:90

90 MUST 21 °Param_Comp>='^> JUMP:91

:91 MUST 251 _* JUMP:92

:92 MUST 7 EXIT

Ϊ93 MUST 22 >' °Param_Comp=° JUMP:94

;94 MUST 2λ °Param_Comp>=° JUMP:95

!95 MUST 251 _* JUMP:96 i96 MUST 7 EXIT

^97 MUST 251 _* "SchleifeForNext" JUMP:98

.98 MUST 24 JUMP:99

!θ9 MUST 251 _* JUMP:100

;ioo MUST ,26^* 'NEXT EXIT

.iöϊ MUST 251 ,* °Record_FindPrev° EXIT

102 MUST 251 * °Record_FindNext° EXIT

103 MUST 251 °Bool_MustPrev° EXIT

104 MUST 251 °Bool_MustNext° EXIT

105 CAN 35 'UNTIL' ELSE JUMP:110 "SchleifeDoUntil⁰ JUMP:106 Zeile Entscheidungspositionsnummer Jump-False Jump-True

106 MUST 251 JUMP:107

107 MUST 24 JUMP:108

108 MUST ;251 * JUMP:109

109 MUST ^'34 ¹LOOP' EXIT

110 MUST 24 "SchleifeDoLoop" JUMP:111

111 MUST 251 JUMP:112

112 MUST 34 ¹LOOP¹ JUMP:113

113 MUST 35 'UNTIL' JUMP:114

114 MUST 251 * EXIT

115 MUST ;251 °SetOperation_Last° EXIT

116 MUST 251 ^' * °SetOperation_First° EXIT

117 MUST 251 * "IfThenElse" JUMP:118

118 MUST 39 'THEN¹ JUMP:119

119 MUST .251 * JUMP:120

120 CAN 40 ΕLSE¹ ELSE JUMP: 122 JUMP:121

121 ML)ST :251 * JUMP: 124

122 CAN 25 ¹END¹ ELSE ΈXIT JUMP:123

123 MUST 38 ¹IF EXIT

124 CAN 25 ¹END¹ ELSE EXIT JUMP:125

125 MUST 38 ¹IF¹ EXIT

126 CAN 42 ¹CASE¹ ELSE JUMP: 192 °SelectCase_Select° JUMP: 127 j127 MUST 251 JUMP:128

128 MUST '24 JUMP:129

129 MUST 42 'CASE' °SelectCase_Case° JUMP: 130

130 CAN .251 •* ELSE JUMP:135 JUMP:131

131 MUST 24 JUMP:132

:132 MUST 251 * JUWIP:133

133 CAN 25 ¹END¹ ELSE JUMP:161 JUMP:134

;134 MUST 41 'SELECT EXIT

135 CAN Ϊ20 ^!<' ELSE JUMP: 148 JUMP:136

^;136 CAN 22 ELSE JUMP: 142 °Param_Comp<>° JUMP:137

137 MUST 251 JUMP:138

138 MUST 24 JUMP:139

139 MUST 251 JUWIP:140

140 CAN 25 ¹END' ELSE JUMP: 167 JUMP:141

141 MUST 41 ¹SELECT¹ EXIT

142 MUST 21 °Param_Comp<='^> JUMP:143

.143 MUST 251 * JUMP:144

^:144 MUST .24 ^" JUMP: 145

'145 ^" MUST 251 JUMP:146

146 CAN '25 'END' ELSE JUMP:173 JUMP:147

147 MUST 41 ¹SELECT¹ EXIT

148 CAN 22 ^•>' ELSE JUMP: 155 JUMP:149

149 MUST 21 °Param_Comp>=° JUMP:150

150 MUST 251 JUWIP:151

.151 MUST 24 JUMP:152

.152 MUST 251 JUMP: 153

153 CAN 25 ¹END¹ ELSE JUMP:179 JUMP:154

154 MUST 41 ¹SELECT' EXIT

155 MUST 21 °Param_Comp=° JUMP: 156

;156 MUST 251 * JUMP: 157

157 MUST ^24 JUMP:158

158 MUST .251 JUMP: 159

159 CAN 25 'END' ELSE JUMP:185 JUMP:160

160 MUST 41 ¹SELECT EXIT Zeile Entscheid u ngspositionsnummer Jump-False Jump-True

161 MUST 42 'CASE' °SelectCase_Case° JUMP:162

162 CAN 40 ^'.'ELSE' ELSE JUMP:130 "SeIeCtCaSe-ElSe" JUMP: 163

163 ^' MUST 24 JUMP:164

164 MUST 1251 * JUMP:165

165 MUST 25 ¹END' JUMP:166

166 MUST 41 fSELECT¹ EXIT

167 MUST 42 ¹CASE¹ °SelectCase_Case° JUMP:168

168 CAN 40 ,'ELSE¹ ELSE •JUMP:130 °SelectCase_Else° JUMP:169

169 MUST 24 ':' JUMP:170

170 MUST ,251 * JUMP:171

171 MUST .25 'END' JUMP:172

172 MUST '41 ¹¹SELECT' • EXIT

173 MUST 42 J¹CASE' °SelectCase_Case" JUMP:174

174 CAN 40 ΕLSE' ELSE JUMP:130 °SelectCase_Eise° JUMP:175

175 MUST 24 JUMP:176

176 MUST 251 JUMP:177

177 MUST 25 ¹END' JUMP:178

178 MUST 41 'SELECT¹ EXIT

179 MUST 42 ^" 'CASE' °SelectCase_Case° ,JUMP:180

180 CAN 40 'ELSE' ELSE JUMP:130 °SelectCase_Else° JUMP:181

181 MUST 24 ':' JUMP:182

182 MUST :251 * JUMP:183

183 MUST 25, ¹END¹ JUMP: 184

191 MUST :251 * °Bool_Not° EXIT

192 MUST 251 •* °Select° EXIT

193 MUST 251 * °SetOperation_BreakOn° JUMP:194

194 CAN ,24 ELSE EXIT JUMP:195

195 MUST =251 * JUMP:196

196 CAN 25 ^:'END' ELSE JUMP:195 JUMP:197

197 MUST .44 -¹BREAKON¹ - °SetOperation_EndBreakOn° EXIT

:198 MUST ;251 * °SetOperation_GroupBy° JUMP:199

199 CAN 24 ELSE EXIT JUMP:200

200 MUST 251 JUMP:201

201 CAN 25 'END' ELSE JUMP:200 JUMP:202 ϊ202 MUST 45 'GROUPBY' °SetOperation_EndGroupBy° EXIT

203 ML)ST 251 * °Calc_Percent° EXIT

204 MUST ^"251 * °SetOperation_From° EXIT

:20~5 MUST 251 * Εxtend_Distinct° EXIT

;2Ö6 MUST ;251 "SetDot" EXIT

:207 CAN 251 ELSE JUMP:253 °Calc_-° EXIT

208 MUST .251 * "CaIc.+⁰ EXIT

^■209 MUST 251 * °Calc_Mod° EXIT

:21θ^' MUST 251 * ⁰CaIc-*⁰ EXIT

;211 MUST 251 * ⁰CaIcJ⁰ EXIT

212 MUST 251 * °Calc_\° EXIT

^;213 MUST 251 °Calc_^Λ° EXIT

^:214 CAN 22 ELSE JUMP:217 °Compare<° JUMP:215

*

215 MUST 251 EXIT Zeile Entscheidungspositionsnummer Jump-False Jump-True

*

216 MUST ,251 °Compare=° EXIT j217 CAN 251 ELSE JUMP:221 °Compare<° EXIT

218 CAN 251 ELSE JUMP:219 °Compare>° EXIT

219 MUST 21 °Compare>=° JUMP:220

220 MUST 251 EXIT

221 MUST 21 °Compare<=° JUMP:222

222 MUST 251 EXIT

Ϊ223 MUST 251 °Bool_XOr° EXIT

224 MUST 251 °Bool_And° EXIT

225 MUST 251 °Bool_Or° EXIT

226 CAN 251 ELSE JUMP:227 Εxtend_LimitResults° EXIT

227 CAN 20 ELSE JUMP:230 Εxtend_LimitResuits° JUMP:228

228 CAN 22 ELSE JUMP:235 °Param_Comp<>° JUMP:229

229 CAN 251 ELSE JUMP:239 EXIT

230 CAN ^" 21 ELSE JUMP:232 °Param_Comp=° JUMP:231

=231 CAN 251 ELSE JUMP241 EXIT

232 CAN 22 ELSE JUMP:237 °Param_Comp=° JUMP:233

233 MUST 21 °Param_Comp>=° JUMP:234

234 CAN 251 ELSE ^:JUMP:243 EXIT

235 MUST 21 °Param_Comp<=° JUMP:236

236 CAN 251 ELSE JUMP:245 EXIT

^;237 MUST 59 °Param_Comp%° JUMP:238

238 MUST 251 EXIT

239 MUST 59 °Param_Comp%° JUMP:240

240 MUST 251 EXIT

241 MUST 59 °Param_Comp%° JUMP:242 i242 MUST 251 EXIT

243 MUST 59 °Param_Comp%° JUMP:244

244 MUST 251 EXIT

245 MUST 59 °Param_Comp%° JUMP:246

246 MUST 251 EXIT

^■247 MUST 251 °MergeSets_Exclude° EXIT

248 CAN 18 'ALU ELSE JUMP250 °MergeSets_Union° JUMP:249

249 MUST 251 "MergeSets_UnionAir EXIT

250 MUST 251 * °MergeSets_Union° EXIT

251 MUST 251 * °MergeSets_lntersect° EXΪT

252 MUST 251 * "SetBeistrich" EXIT

;253~ MUST 22 ^•>' "SetWayPartOVER" JUMP:254

|254 MUST 251 :* JUMP:255

255 CÄN ^:64 POVER' ELSE EXIT JUMP:256

256 MUST 251 * EXIT

257 MUST 254 variable "SaveAsSet" EXIT

258 MUST 6 T °Compare=° JUMP:259

259 MUST 251 JUMP:260

260 MUST 7 T EXIT

1261 MLJST 255 Εxtend OrderByDesc⁰ EXIT

Claims

P A T E N T A N S P R Ü C H E

1. Verfahren zum Steuern eines relationalen Datenbanksystems, wobei ein abzuarbeitendes Anfragestatement, das aus Anfrage-Schlüsselworten zusammengesetzt ist, zunächst unter Anwendung eines rekursiven Übergangsnetzwerks (RTN) analysiert wird, indem die Übereinstimmung der Anfrage-Schlüsselworte mit dem RTN überprüft wird, und danach in einen Steuerbefehle umfassenden Zugriffsplan umgewandelt und dieser gegebenenfalls optimiert wird, dadurch gekennzeichnet, dass es die folgenden Schritte umfasst:

Definieren des RTN in einem Voreinstellungsschritt durch Bilden von voneinander unabhängigen RTN-B austeinen, welche eine nach Bedarf veränderbare Gesamtheit an RTN- Bausteinen ausbilden, wobei jeder RTN-Baustein zugehörige verarbeitungsrelevante RTN- Baustein-Informationen beinhaltet und einen inneren, gerichteten Entscheidungsgraphen aufweist, der unabhängig von den inneren, gerichteten Entscheidungsgraphen der anderen RTN-Bausteine definiert ist und jeweils zumindest einen Entscheidungspfad aufweist, welcher zumindest eine Entscheidungsposition beinhaltet,

Definieren von voneinander unabhängigen Entscheidungspositions- Verarbeitungsinformationen als Teilschritt des Voreinstellungsschrittes, welche unabhängig von den RTN-Bausteinen sind und welche eine nach Bedarf veränderbare Gesamtheit an Entsclieidungspositions-Verarbeitungsinformationen darstellen,

Transformieren des abzuarbeitenden Anfragestatements in eine zugehörige RTN- Baustein-Verschachtelung, wobei diese aus ausgewählten RTN-Bausteinen besteht, welche jeweils auch mehrfach auswählbar sind,

wobei die zugehörige RTN-B austein-Verschachtelung einen RTN-Baustein aus der Gesamtheit der RTN-Bausteine als äußersten RTN-Baustein umfasst, aus dessen Entscheidungsgraph genau einer seiner Entscheidungspfade ausgewählt wird, welcher zumindest eine Entscheidungspositionen enthält, die als rekursive RTN-Baustein- Einsetzposition ausgebildet ist, und zumindest eine weitere Entscheidungsposition enthält, die durch eine Schlüsselwort-Entscheidungsposition ausgebildet ist,

und wobei die zugehörige RTN-Baustein-Verschachtelung so zusammengesetzt ist, dass beginnend mit der ersten Entscheidungsposition des äußersten RTN-Bausteins eine Übereinstimmung mit dem abzuarbeitenden Anfragestatement insofern vorliegt, dass die Schlüsselworte der Schlüsselwort-Entscheidungspositionen der jeweiligen Entscheidungspfade der für die zugehörige RTN-Baustein-Verschachtelung ausgewählten RTN-Bausteine unter Berücksichtigung der vorhandenen, rekursiven RTN-Baustein- Einsetzpositionen und deren jeweils eingesetzten inneren RTN-Bausteine, jeweils mit den Anfrage-Schlüsselworten des abzuarbeitenden Anfragestatements in deren vorliegender Reihenfolge übereinstimmen,

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass zur Ermittlung des äußersten RTN-B austeins sowie für die Ermittlung von an den Entscheidungspositionen der rekursiven RTN-Baustein-Einsetzpositionen jeweils einzusetzenden RTN-Bausteine der dem Anfragestatement zugehörigen RTN-Baustein-Verschachtelung RTN-Bausteine aus der Gesamtheit derselben durchlaufen werden, wobei bei Durchlaufen der RTN-Bausteine deren innere, gerichtete Entscheidungsgraphen durchlaufen werden,

oder eine Sprung-Entscheidungsposition ausbildet, welche eine Sprungposition auf eine beliebige Entscheidungsposition innerhalb des inneren, gerichteten Entscheidungsgraphen des aktuellen RTN-Bausteins festlegt und diese bei Erreichen ausfuhrt,

oder eine rekursive RTN-Baustein-Einsetzposition-Entscheidungsposition ausbildet, in welche bei Erreichen ein RTN-Baustein aus der Gesamtheit der RTN-Bausteine eingesetzt wird, welcher seinerseits wieder durchlaufen wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass das Transformieren des abzuarbeitenden Anfragestatements erfolgt, indem das erste Anfrage- Schlüsselwort des abzuarbeitenden Anfragestatements als Vergleichsschlüsselwort festgelegt und folgender rekursiver RTN-Baustein- Auswahlschritt angewandt wird:

Auffinden zumindest eines der RTN-Bausteine aus der Gesamtheit derselben, für welchen das festgelegte Vergleichsschlüsselwort mit zumindest einer von jenen Entscheidungspositionen übereinstimmt, die als erste Entscheidungspositionen in diesem RTN-Baustein erreichbar sind,

und Aufnehmen desselben in die dem abzuarbeitenden Anfragestatement zugehörige RTN-Baustein-Verschachtelung, sofern einer seiner Entscheidspfade in weiterer Übereinstimmung mit den dem festgelegten Vergleichsschlüsselwort nachfolgenden Anfrage-Schlüsselworten des abzuarbeitenden Anfragestatements vollständig durchlaufen werden kann,

wobei an jenen erreichten Entscheidungspositionen, welche eine rekursive RTN- Baustein-Einsetzposition aufweisen, das dem zuletzt verglichenen Anfrage- Schlüsselwort nachfolgende Anfrage-Schlüsselwort im abzuarbeitenden Anfragestatement als Vergleichsschlüsselwort festgelegt und der rekursive RTN-

Baustein- Auswahlschritt angewandt wird.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass das Auffinden und Aufnehmen des zumindest einen RTN-Bausteins im RTN-Baustein-Auswahlschritt folgendermaßen erfolgt:

Durchlaufen der inneren, gerichteten Entscheidungsgraphen der RTN-Bausteine aus der Gesamtheit derselben solange, bis jener RTN-Baustein aufgefunden wird, der vollständig durchlaufen werden kann, indem

allen möglichen Entscheidungspfaden des jeweiligen Entscheidungsgraphen solange gefolgt wird, bis entweder keine Übereinstimmung einer der Schlüsselwort-Entscheidungspositionen des jeweils gewählten Entscheidungspfades mit einem zu vergleichenden Anfrage- Schlüssel worte festgestellt und der Vorgang abgebrochen wird oder der jeweils gewählte Entscheidungspfad bis zum Ende durchlaufen wird.

5. Verfahren nach einem Ansprüche 1 bis 4, dadurch gekennzeichnet, dass den Entscheidungspositionen in der zugehörigen RTN-Baustein-Verschachtelung beim

Transformieren des abzuarbeitenden Anfragestatements Entscheidungspositions- Verarbeitungsinformationen dadurch zugeordnet werden, dass für jeden der für die zugehörige RTN-Baustein-Verschachtelung ausgewählten RTN-Bausteine jeweils folgender Schritt angewandt wird:

Überprüfen für jede Entscheidungsposition, ob dieser jeweils im zugrunde liegenden Entscheidungsgraphen bereits eine Entscheidungspositions-Verarbeitungsinformation zugeordnet ist,

und sofern dies der Fall ist, Beibehalten dieser Entscheidungspositions- Verarbeitungsinformation,

und sofern dies nicht der Fall ist, Zuordnen jener Entscheidungspositions- Verarbeitungsinformation als dieser Entscheidungsposition zugehörige Entscheidungspositions-Verarbeitungsinformation, welche bei Zurückverfolgen des Entscheidungspfades von dieser Entscheidungsposition ausgehend als erste angetroffen wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass sämtliche Entscheidungspositions-Verarbeitungsinformationen aus der Gesamtheit derselben, welche Entscheidungspositionen der inneren, gerichteten Entscheidungsgraphen zugeordnet sind, unabhängig von sowohl gegebenenfalls anderen oder gleichen Entscheidungspositions- Verarbeitungsinformationen im jeweils selben Entscheidungsgraphen als auch unabhängig von anderen oder gleichen Entscheidungspositions- Verarbeitungsinformationen der inneren, gerichteten Entscheidungsgraphen anderer RTN-Bausteine sind,

wodurch zumindest einige der Entscheidungspositions-Verarbeitungsinformationen aus der Gesamtheit derselben mehrfach an unterschiedlichen Entscheidungspositionen im gleichen inneren, gerichteten Entscheidungsgraphen und/oder mehrfach in unterschiedlichen, voneinander unabhängigen RTN-B austeinen angegeben sind.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass sämtliche der von einander unabhängigen Entscheidungspositions- Verarbeitungsinformationen eindeutig vermittels einer jeweiligen Kennzeichnung einer ersten oder einer zweiten Entscheidungspositions-Verarbeitungsinformationsgruppe zugeordnet werden,

wobei jene Entscheidungspositions-Verarbeitungsinformationen, welche bei Erreichen der ihnen jeweils zugeordneten Entscheidungsposition eine gegebenenfalls vorher im gleichen Entscheidungsgraphen festgelegte Entscheidungspositions-Verarbeitungsinformation ab der ihnen zugehörigen Entscheidungsposition im durchlaufenen Entscheidungspfad übersteuern, und dies unabhängig davon, ob die gegebenenfalls vorher festgelegten Entscheidungspositions- Verarbeitungsinformationen an zumindest einer der vorhergehenden Entscheidungspositionen ausgewertet und im Zugriffsplan-Erstellungsschritt berücksichtigt wurden, der ersten Entscheidungspositions-Verarbeitungsinformationsgruppe zugeordnet werden,

und jene Entscheidungspositions- Verarbeitungsinformationen, welche bei Erreichen einer sie festlegenden Entscheidungsposition in zumindest einem der Entscheidungsgraphen als Entscheidungspositions-Verarbeitungsinformations-Erweiterung für zumindest eine andere, aktuelle Entscheidungspositions- Verarbeitungsinformation, welcher einer erreichten Entscheidungsposition entweder im gleichen oder in einem anderen inneren, gerichteten Entscheidungsgraphen eines aufgerufenen und durchlaufenen RTN-Bausteins verwendet werden, der zweiten Entscheidungspositions-Verarbeitungsinformationsgruppe zugeordnet werden.

8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von einander unabhängige Engine-Verarbeitungsfunktionen als Teilschritt des Voreinstellungsschrittes definiert und diese zu einer Gesamtheit von Engine- Verarbeitungsfunktionen zusarnmengefasst werden, welche Engine-Verarbeitungsfunktionen unabhängig von den definierten RTN-Bausteinen und unabhängig den definierten Entscheidungspositions-Verarbeitungsinforaiationen sind und welche gegebenenfalls Parameter enthalten, die sich im Konkreten automatisch aus dem zu analysierenden Anwender-Statement im Zugriffsplan-Erstellungsschritt ergeben,

wobei zumindest ein Teil der Engine-Verarbeitungsfunktionen Verarbeitungs- oder Selektionsfunktionen auf Datensätze von Tabellen oder Mengen anwenden,

und ein anderer Teil der Engine-Verarbeitungsfunktionen Informationen für die Reihenfolge der Anwendung der Engine-Verarbeitungsfunktionen sowie eine Verarbeitungs- Eingangsmenge oder Verarbeitungs-Eingangsmengen für die jeweiligen Engine- Verarbeitungsfunktionen anhand des Anwender-Statements im Konkreten festlegen,

und wobei aus der Reihenfolge der Entscheidungspositions-Verarbeitungsinformationen und deren Verschachtelung, wie sie sich durch die Transformation alles Schlüsselworte des Anfragestatements in die zugehörige RTN-Baustein- Verschachtelung mittels der RTN- Bausteine ergibt, automatisch Engine-Verarbeitungsfunktionen mit entsprechenden Parametern und in einer konkreten Reihenfolge, die sich jeweils aus den Entscheidungspositions-Verarbeitungsinformationen ergeben, ein nachfolgend weiter optimierbarer Zugriffsplan für das relationale Datenbanksystem generiert wird.

9. Verfahren nach den einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass bei der Formulierung des Anwender-Statements sowohl benachbarte als auch ineinander verschachtelte RTN-B austeine durch einen Anwender angegeben werden, wobei jeder dieser RTN-Bausteine zumindest eine Verarbeitungs-Eingangsmenge entweder von einem der ihm übergeordneten, untergeordneten oder benachbarten RTN-Bausteine zugewiesen bekommt oder selbst eine Verarbeitungs-Eingangsmenge definiert, welche wiederum für zumindest einen der RTN-Bausteine, die im Anwender-Statement angegeben ist, als Verarbeitungs- Eingangsmenge herangezogen werden,

wobei die Zuweisung der Verarbeitungs-Eingangsmengen als verarbeitungsrelevante RTN- Baustein-Införmation, so zum Beispiel mittels Entscheidungspositions- Verarbeitungsinformation, im Voreinstellungsschritt je RTN-Baustein definiert wird.

10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass sämtliche in einem Anwender-Statement angegebenen RTN-Bausteine an zumindest einer ihrer erreichten Entscheidungsposition in ihrem inneren, gerichteten Entscheidungsgraphen zumindest eine Verarbeitungs-Ausgangsmenge liefern, welche nicht zwingend ungleich der Verarbeitungs- Eingangsmenge desselben RTN-Bausteins sein muss, sich aber in den Elementen, den Werten der Elemente und/oder der Reihenfolge derselben von dessen jeweiliger zumindest einen Verarbeitungs-Eingangsmenge unterscheiden kann.

11. Verfahren nach einem der Ansprüche 8, 9 oder 10, dadurch gekennzeichnet, dass die Verarbeitungs-Ausgangsmenge zumindest einiger der RTN-Bausteins als Verarbeitungs- Eingangsmenge für zumindest einen ihrer im Anwender-Statement benachbarten, übergeordneten oder untergeordneten RTN-Bausteine herangezogen wird.

12. Verfahren nach einem der Ansprüche 8 bis 11, dadurch gekennzeichnet, dass die Entscheidungspositions-Verarbeitungsinformationen, dessen zugehörige

Entscheidungspositionen aufgrund des Anwender-Statements in einem RTN-Baustein erreichten werden, die Engine- Verarbeitungsfunktionen, welche auf zumindest eine Verarbeitungs-Eingangsmenge ab der Entscheidungsposition des RTN-Bausteins, welche die jeweilige Entscheidungspositions-Verarbeitungsinformation enthält, angewandt werden, und somit die Elemente der Verarbeitungs-Ausgangsmenge und gegebenenfalls deren Reihenfolge des RTN-Bausteins festlegen.

13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine Mehrzahl an voneinander unabhängigen Verarbeitungs-Typen als Teilschritt des Voreinstellungsschrittes erstellt wird und diese der Gesamtheit der Verarbeitungs-Typen hinzugefügt werden,

wobei die Gesamtheit der Verarbeitungs-Typen zumindest die folgenden Elemente enthält

„Wert", „Tabellenfeld", „Tabelle/Menge", „Boolean", „Menge An Werten", "Verarbeitungs- Typ von letzter "-Position", und „Nicht Zulässig", wobei das Element „Menge An Werten" zumindest mehrere Werte, berechnete Werte und/oder Tabellenfeld- Werte darstellt

und wobei die Verarbeitungs-Typen von den RTN-Bausteinen, von den Entscheidungspositions- Verarbeitungsinformationen und Engine-Verarbeitungsfunktionen unabhängig sind.

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Gesamtheit der Verarbeitungsergebnis-Typen zumindest um die Elemente „Aggregierter Wert", „Vorher aggregierter Wert" und „Vorher aggregierte Menge" erweitert wird.

15. Verfaliren nach den Ansprüchen 8 bis 14, dadurch gekennzeichnet, dass eine von den RTN-Bausteinen, von den Entscheidungspositions- Verarbeitungsinformationen und von den Engine-Funktionen unabhängige Verarbeitungsinformations-Enginefunktions- Zuordnungsmenge erstellt wird, in welcher für jede Entscheidungspositions- Verarbeitungsinformation aus der Gesamtheit derselben jeweils zumindest ein Element vorhanden ist, wobei jedes Element dieser Verarbeiftmgsinfomations-Enginefunktions- Zuordnungsmenge zumindest

ein unabhängiges Entscheidungspositions-Verarbeitungsinformationsfeld enthält, welchem eine Entscheidungspositions-Verarbeitungsinformation zugeordnet ist, und

ein unabhängiges, optionales Entscheidungspositions-Verarbeitungsinformations- Erweiterungsfeld enthält, welchem eine Entscheidungspositions-Verarbeitungsinformations- Erweiterung zugeordnet ist, und

ein unabhängiges Engine- Verarbeitungsfunktionsfeld enthält, welchem eine Engine- Verarbeitungsfunktion zugeordnet ist, und

ein unabhängiges, optionales erstes Verarbeitungs-Eingangstyp-Feld enthält, welchem ein Element aus der Gesamtheit der Verarbeitungs-Typen zugeordnet ist, und ein unabhängiges, optionales zweites Verarbeitungs-Eingangstyp-Feld enthält, welchem ein Element aus der Gesamtheit der Verarbeitungs-Typen zugeordnet ist, und

ein unabhängiges, optionales Verarbeitungs-Ausgangstyp-Feld enthält, welchem ein Element aus der Gesamtheit der Verarbeitungs-Typen zugeordnet ist.

16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass im Zugriffsplan- Erstellungsschritt ein Zugriffsplan für die zugrunde liegende Datenstruktur erstellt wird, indem die Entscheidungspositionen der dem abzuarbeitenden Anfragestatement zugehörige RTN-Baustein-Verschachtelung anfangend von der ersten Entscheidungsposition des äußersten RTN-B austeins nacheinander durchlaufen werden und jene aufgefundenen Entscheidungspositions-Verarbeitungsinformationen, die erreichten Entscheidungspositionen jeweils zugeordnet sind, jeweils in der Verarbeirungsinfoπnations-Enginefunktions- Zuordnungsmenge gesucht und bei Auffinden in derselben eine entsprechende Engine- Befehlskettenzeile dem Zugriffsplan hinzufügen bzw. vorhandene Engine-Befehlskettenzeilen desselben verändern, wobei die zu verwendende Engine-Verarbeitungsfunktion der betroffenen Engine-Befehlskettenzeile jene Funktion beispielsweise als Wert festlegt, welche das Engine-Verarbeitungsfunktionsfeld des aufgefundene Elements enthält.

17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass jenes Element in der Verarbeiixmgsinformations-Enginefunktions-Zuordnungsmenge gesucht und gegebenenfalls aufgefunden wird, für welches die Entscheidungspositions-Verarbeitungsinformation sowie die gegebenenfalls vorhandene Entscheidungspositions-Verarbeitungsinformations- Erweiterung der jeweiligen Entscheidungsposition in der Verarbeitungsinformations- Enginefunktions-Zuordnungsmenge vorhanden ist.

18. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass jede Entscheidungsposition in der RTN-Baustein-Verschachtelung, welche dem abzuarbeitenden Anfragestatement zugehörig ist, zumindest die Werte erster Verarbeitungs- Eingangstyp und zweiter Verarbeitungs-Emgangstyp aufweisen, welche bei der Transformation jeweils nicht gesetzt sind, und welche im Zugriffsplan-Erstellungsschritt gesetzt und verändert werden können.

19. Verfahren nach Anspruch 16, 17 oder 18, dadurch gekennzeichnet, dass bei

Auffinden eines Elements in der Verarbeitungsinformations-Enginefunktions- Zuordnungsmenge ein Verarbeitungs-Ausgangstyp zurückgeliefert wird, welcher Verarbeitungs-Ausgangstyp den Wert Verarbeitungs-Ausgangstyp-Feld des aufgefundenen Elements in der Verarbeitungsinformations-Enginefunktions-Zuordnungsmenge entspricht,

und der erste Verarbeitungs-Eingangstyp jener Entscheidungsposition, für welche ein Eintrag in der Verarbeitungsinformations-Enginefunktions-Zuordnungsmenge aufgefunden wird, nachfolgenden Entscheidungsposition auf diesen Verarbeitungs-Ausgangstyp gesetzt wird, und der zweite Verarbeitungs-Eingangstyp derselben nachfolgenden Entscheidungsposition auf nicht vorhanden gesetzt wird,

wobei in jenen Fällen, in denen kein Wert im Verarbeitungs-Ausgangstyp-Feld des aufgefundenen Elements in der Verarbeitangsinformations-Enginefunktions- Zuordnungsmenge gesetzt ist, die beiden Werte erster Verarbeitungs-Eingangstyp und zweiter Verarbeitungs-Eingangstyp dieser nachfolgenden Entscheidungsposition jeweils die gegebenenfalls gesetzten Werte erster Verarbeitungs-Eingangstyp und zweiter Verarbeitungs- Eingangstyp der vorhergehenden Entscheidungsposition zugewiesen bekommen, und

wobei in jenen Fällen, in denen kein Element in der Verarbeitungsinformations- Enginefunktions-Zuordnungsmenge aufgefunden wird, die beiden Werte erster Verarbeitungs-Eingangstyp und zweiter Verarbeitungs-Eingangstyp dieser nachfolgenden Entscheidungsposition jeweils die gegebenenfalls gesetzten Werte erster Verarbeitungs- Eingangstyp und zweiter Verarbeitungs-Eingangstyp der vorhergehenden Entscheidungsposition zugewiesen bekommen.

20. Verfahren nach Anspruch 16, 17, 18 oder 19, dadurch gekennzeichnet, dass für jede nacheinander aufgerufene Entscheidungsposition genau jenes Element in der Verarbeitungsinformations-Enginefunktions-Zuordnungsmenge gesucht wird, welches die Werte Entscheidungspositions-Verarbeitungsinformation sowie die gegebenenfalls gesetzten Werte Entscheidungspositions-Verarbeitungsinformations-Erweiterung, erster Verarbeitungs- Eingangstyp und zweiter Verarbeitungs-Eingangstyp aufweist und bei Auffinden eines entsprechenden Elements der Zugriffsplan-Erstellungsschritt entsprechend den vorhergehenden Ansprüchen angewandt wird.

21. Verfahren nach einem der Ansprüche 18 bis 20, dadurch gekennzeichnet, dass bei vollständigem Durchlaufen eines eingesetzten RTN-Bausteins in der dem angegebenen

Anfragestatement zugehörigen RTN-Baustem-Verschachtelung im Zugriffsplan-

Erstellungsschritt dieser RTN-Baustein jener Entscheidungsposition, welche der

Entscheidungsposition nachfolgt, die diesen RTN-Baustein aufgerufen hat, in genau jenen

Fällen den ersten Verarbeitungs-Eingangstyp dieser Entscheidungsposition auf den letzten ersten Verarbeitungs-Eingangstyp des eingesetzten RTN-Bausteins setzt, in denen der erste

Verarbeitungs-Eingangstyp der diesen RTN-Baustein aufrufenden Entscheidungsposition nicht gesetzt ist,

und in genau jenen Fällen den Wert zweiter Verarbeitungs-Eingangstyp auf den letzten ersten Verarbeitungs-Eingangstyp des eingesetzten RTN-Bausteins setzt, in denen der erste Verarbeitungs-Eingangstyp der diesen RTN-Baustein aufrufenden Entscheidungsposition gesetzt ist, und in diesen Fällen als erster Verarbeitungs-Eingangstyp der erste Verarbeitungs- Eingangstyp der vorhergehenden Entscheidungsposition gesetzt wird.

22. Verfahren nach Anspruch 18, 19, 20 oder 21, dadurch gekennzeichnet, dass in jenen Fällen, in denen für eine Entscheidungsposition sowohl eine Entscheidungspositions- Verarbeitungsinformation, ein erster Verarbeitungs-Emgangstyp, ein zweiter Verarbeitungs- Eingangstyp sowie gegebenenfalls ein Wert für Entscheidungspositions- Verarbeitungsinformations-Erweiterung gesetzt ist, aber kein entsprechendes Element in der Verarbeiürngsinformations-Engmefunktions-Zuordnungsmenge aufgefunden werden kann, der Wert erster Verarbeitungs-Eingangstyp dieser Entscheidungsposition auf den Wert zweiter Verarbeitungs-Eingangstyp gesetzt und der Wert zweiter Verarbeitungs-Eingangstyp auf nicht vorhanden gesetzt wird, und ein entsprechender Eintrag in der Verarbeitungsinformations-Enginefunktions-Zuordnungsmenge erneut gesucht und gegebenenfalls aufgefunden wird. '

23. Verfahren nach einem der Ansprüche 15 bis 22, dadurch gekennzeichnet, dass jedes Element der Verarbeitungs-Irfoi-mations-Enginefunktions-Zuordnungsmenge um zumindest ein weiteres, optionales Feld RTN-Baustein-Engine-Kommuniziererfeld erweitert wird, mittels welchen Feldes eine vorbestimmbare Auswertung beschreibbar ist, welche Engine- Befehlskettenzeüen im Zugriffsplan erstellt und/oder verändert werden sollen.

24. Verfahren nach einem der Ansprüche 16 bis 23, dadurch gekennzeichnet, dass jeder RTN-Baustein der RTN-Baustein-Verschachtelung jene Engine-Befehlskettenzeile als seine aktuelle Engine-Befehlskettenzeile enthält, welche als erste Engine-Befehlskettenzeile in diesem RTN-Baustein erstellt wurde,

wobei bei Erstellung zumindest einer weiteren Engine-Befehlskettenzeile diese als aktuelle Engine-Befehlskettenzeile desselben RTN-B austeins gesetzt werden kann,

und wobei jeder RTN-Baustein bei erfolgreichem Durchlaufen jene Engine- Befehlskettenzeile, welche in ihm als erste erstellt wurde, diese seinem jeweils übergeordneten RTN-Baustein als aktuelle Engine-Befehlskettenzeile des zuletzt eingesetzten RTN-Bausteins liefert.

25. Verfahren nach einem der Ansprüche 16 bis 24, dadurch gekennzeichnet, dass ein im Zugriffsplan-Erstellungsschritt in der RTN-Baustein-Verschachtelung durchlaufener RTN- Baustein jene Engine-Befehlskettenzeile der aktuellen Engine-Befehlskettenzeile des übergeordneten RTN-Bausteins als Parameter anfügt, welche in diesem durchlaufenen RTN- Baustein als erste Engine-Befehlskettenzeile erstellt und dem Zugriffsplan hinzugefügt wurde.

26. Verfahren nach einem der Ansprüche 16 bis 25, dadurch gekennzeichnet, dass der Wert jener erreichten Entscheidungspositionen, welche eine Schlüsselwort- Entscheidungsposition ausbilden und eine Variable, eine Zahl, eine Konstante oder einen Funktionsnamen enthalten, der aktuellen Engine-Befehlskettenzeile des zugehörigen RTN- Baustein als Parameter angefügt werden.

27. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die entsprechend ihrer Reihenfolge im Statement und ihrer Gewichtung verschachtelten RTN- Bausteine, die bestimmten RTN-B austein-Gruppen zugeordnet wurden, jeweils in Engine- Schnittstellen-Elemente umgewandelt werden, wobei ein Engine-Schnittstellen-Element einen Satz von voneinander unabhängigen Komponenten aufweist, die entsprechend dem Verarbeitungsschritt einstellbar sind.

28. Relationales Datenbanksystem, welches mindestens ein Computersystem mit mindestens einer relationalen Datenbank, mindestens eine Datenverarbeitungseinheit und mindestens einen Speicher umfaßt, dadurch gekennzeichnet, daß die Datenverarbeitungseinheit programmtechnisch so eingerichtet ist, daß sie nach dem Verfahren nach einem der Ansprüche 1 bis 27 arbeitet.

29. Relationales Datenbanksystem nach Anspruch 28, dadurch gekennzeichnet, daß es ferner Mittel zum Einlesen von in einer Datenbanksprache angegebenen Datenbankanweisung, oder Datenbankanweisungen zur Steuerung des relationalen Datenbanksystems von einem Datenträger oder elektronischen Trägersignal nach Anspruch 28 in den Speicher aufweist.

30. Datenträger oder elektronisches Trägersignal mit in einer Datenbanksprache angegebenen Datenbankanweisung oder Datenbankanweisungen zur Steuerung und zum Einlesen in ein relationales Datenbanksystem nach Anspruch 29, dadurch gekennzeichnet, daß die auf dem Datenträger oder dem Trägersignal vorliegende Datenbankanweisung oder die vorliegenden Datenbankanweisungen umfasst, die in folgender Weise gebildet sind::

wobei in jedem der RTN-Bausteine zumindest eine der Entscheidungspositionen als Schlüsselwort-Entscheidungsposition ausgebildet ist, welche ein zugehöriges Schlüsselwort beinhaltet, und wobei bei zumindest einem Teil der RTN-B austeine zumindest eine ihrer Entscheidungspositionen als rekursive RTN-Baustein-Einsetzposition ausgebildet ist, an welcher jeweils ein RTN-Baustein aus der Gesamtheit derselben einsetzbar ist, wobei auch jene RTN-B austeine eingesetzt werden können, in deren inneren, gerichteten Entscheidungsgraphen zumindest eine ihrer Entscheidungspositionen als rekursive RTN- Baustein-Einsetzposition ausgebildet ist, sodass eine beliebig oftmalige rekursiv verschachtelte Einsetzmöglichkeit von RTN-Bausteinen ermöglicht wird,

Übereinstimmung mit dem abzuarbeitenden Anfragestatement insofern vorliegt, dass die

Schlüsselworte der Schlüsselwort-Entscheidungspositionen der jeweiligen

Reihenfolge übereinstimmen,

31. Computerprogramm, das Instruktionen aufweist, die zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 27 eingerichtet sind.

32. Computerprogrammprodukt welches ein computerlesbares Medium mit Computerprogramm-Code-Mitteln aufweist, bei dem jeweils nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des Verfahren nach einem der Ansprüche 1 bis 27 veranlaßt wird.

33. Computerprogrammprodukt, welches ein Computerprogramm auf einem elektronischen Trägersignal aufweist, bei dem jeweils nach Laden des Computerprogramms ein Computer durch das Programm zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 27 veranlaßt wird.