Abfragecode und Ausdrücke

Die Abfragen in ASYS werden nicht als SQL-Ausdrücke definiert, sondern - an die Komponenten eines SQL-Ausdrucks angelehnt - als Listen zeilenweiser Teilausdrücke für die verschiedenen Hauptbestandteile einer Datenbankabfrage angelegt. Ein Hauptgrund hierfür ist der modellbasierte Verarbeitungsmechanismus von ASYS, welcher zur Laufzeit aus modellierten Informationen ausführbaren Code generiert. Hierzu wird bei der Definition von Abfragen nicht mit den physischen Datenbanknamen von Tabellen, Sichten (Views), Attributen und (z.T.) Funktionsnamen gearbeitet, sondern mit den Modellnamen. Diese sind im ASYS-Datenmodell (Fachobejektemodell FOM) hinterlegt¹⁾. Erst zum Zeitpunkt der Ausführung werden die Modellnamen gegen die physischen Namen der Datenbank ersetzt. Ebenso werden Abfrageparameter gegen die entsprechenden Werte aus dem jeweiligen Datensatz oder der Systemumgebung ersetzt. Je nach genutzter Datenbank werden dabei auch spezifische Datenbankeigenschaften (z.B. das Datumsformat) berücksichtigt. Das Resultat dieser Verarbeitung ist ein SQL-Ausdruck, passend zur jeweils genutzten Datenbank und zum Kontext, der datenbankunabhängig definiert werden kann²⁾.

Die Hauptbestandteile einer Abfrage sind - in Analogie zu SQL-Ausdrücken:

Die beiden fett gesetzten Abschnitte einer Abfrage müssen definiert werden. Alle anderen Abschnitte können genutzt werden, sind aber nicht verpflichtend zu füllen. Allerdings besteht - je nach abgefragten Klassen - bei einem leeren CONDITIONS-Abschnitt die Gefahr, dass sehr umfangreiche Treffermengen zu Stande kommen, da die Ergebnismenge nicht gefiltert wird.

Beachten Sie die grundsätzlichen Konventionen.

Im CLASSES-Abschnitt werden die Objekte der Datenbank angegeben, welche die Quellen der abzufragenden Daten bilden. Für eine Abfrage muss mindestens ein Objekt angegeben werden, aus der die Datensätze für das Ergebnis genommen werden sollen. Die Klassen in ASYS-Abfragen entsprechen den im Fachobjektemodell (FOM) modellierten Objekten. Sie müssen in diesem Abschnitt mit dem Namen aus dem FOM eingetragen werden³⁾.

Klassen und Views im FOM

Einer Klasse im FOM sind in der Datenbank immer zwei Strukturen eindeutig zugeordnet: Eine Tabelle und eine Sicht (View). Der Unterschied zwischen beiden ist, dass in der Sicht nur die nicht als gelöscht markierten Datensätze enthalten sind während die Tabellen Zugriff auf alle Datensätze - auch die gelöscht markierten - bieten. Wird in ASYS ein Datensatz gelöscht, findet keine physische Löschung des Datensatzes in der Tabelle statt⁴⁾. Statt dessen wird der Datensatz aktualisiert, wobei ihm eine Löschmarkierung mitgegeben wird. Derartig markierte Datensätze lassen sich in der ASYS-Anwenderoberfläche, mit Abfragen oder Detaillierten Suchen nicht mehr aufrufen. Sämtliche lesenden Zugriffe finden also immer nur auf den View statt.

Um die Anzahl an Tabellen, in denen gleichartige Daten verwaltet werden etwas überschaubarer zu halten sind an einigen Stellen im FOM mehrere Views definiert, die alle von derselben Klasse erben. Hierfür ist in der jeweiligen Klasse immer ein Attribut Rolle (Ganzzahl) definiert und jeder View erbt von der Klasse in einer ganz bestimmten Rolle. In der Datenbank gibt es für diese Views eine eigene Sicht (View) aber keine eigene Tabelle. Objektbeziehungen (abhängige Daten) im FOM erfolgen sowohl zu einer Klasse als auch zu einem View. Bei der Definiton einer Abfrage ist folgendes zu beachten: Ein View kennt alle Objektbeziehungen, die direkt auf ihn verweisen sowie alle Objektbeziehungen derjenigen Klasse von der der View erbt. Eine Klasse dagegen kennt nur die Objektbeziehungen, die direkt auf sie verweisen. Für die Definition im CLASSES-Abschnitt bietet es sich daher wahrscheinlich am häufigsten an, mit den Views (und nicht den Klassen) zu arbeiten. Nur für übergreifende Abfragen (z.B. alle Betriebe oder alle Abfalltransportbeteilgten - unabhängig von ihrer Rolle) kann es ggf. manchmal sinnvoll sein, mit der Klasse zu arbeiten und die Rolle im CONDITIONS-Abschnitt selber zu berücksichtigen oder auch nicht. Bzgl. der weiteren Defintion in einer Abfrage spielt es ansonsten keine Rolle, ob mit den Klassen oder Views gearbeitet wird. Im folgenden wird daher immer nur von Klassen gesprochen.

Die Namen einer Klasse und ihrer Attribute im FOM weichen gegenüber den Namen der Tabellen/Sichten(Views) in der Datenbank und ihrer Attribute voneinander ab. Sie werden von der mittleren Schicht zur Ausführungszeit einer Abfrage aus den FOM-Namen in die Datenbanknamen übersetzt. Theoretisch können für verschiedene Datenbanken (Oracle, SQL-Server, Access) unterschiedliche Datenbanknamen für die gleichen Tabellen, Views oder Attribute definiert sein (in der Praxis wird von dieser Möglichkeit kein Gebrauch gemacht).

Sämtliche Attribute aus der Datenbank, die in den weiteren Abschnitten RESULTS, CONDITIONS, GROUP, ORDER oder HAVING verwendet werden sollen, müssen aus einer Klasse stammen, die in diesem Abschnitt eingetragen wurde! Andersherum müssen Sie daher alle Klassen, aus denen Sie Attribute in den weiteren Abfrageabschnitten verwenden wollen, in diesem Abschnitt angeben.

Viele Fachobjekte - z.B. der Entsorgerbetrieb - bestehen nicht nur aus einem Datensatz in einer Tabelle bzw. Klasse, sondern besitzen eine komplexere Struktur aus einem Hauptdatensatz und einer variablen Anzahl von mit diesem Hauptdatensatz verknüpften Unterdatensätzen in eigenen Klassen⁵⁾. Derartige hierarchische Beziehungen zwischen den Klassen bzw. Datensätzen in den Datenbanktabellen können mehrstufig sein - z.B. FKB → Entsorgerbetrieb → Entsorger → Teilanlage → zugelassener Abfall.

Die Ausgangsklasse einer Abfrage wird einfach mit ihrem FOM-Namen in diesem Abschnitt eingetragen. Die weiteren Klassen werden - soweit möglich - so eingetragen, dass die Beziehungen zwischen den Klassen über einen Klassenpfad in Punktnotiation deutlich werden:

Klasse_A
Klasse_A.Klasse_B

• Die Art der Verknüpfung zwischen den beiden Tabellen ist im FOM modelliert und wird von ASYS automatisch zur Ausführungszeit in den passende SQL-Teilausdruck übersetzt, wenn die Beziehung zwischen den Klassen in dieser Punktnotation eingetragen wird.
• Damit diese Übersetzung funktioniert, muss es auch tatsächlich eine Beziehung zwischen den beiden Klassen im FOM geben. Die Eingabehilfe bietet nur FOM-Beziehungen an.
• In vielen Fallen ist die Klasse A der übergeordnete Datensatz, die Klasse B repräsentiert untergeordnete (abhängige) Datensätze. Vielfach besteht eine 1:0..n-Beziehung, d.h. zu einem übergeordneten Datensatz der Klasse A gehören Null bis beliebig viele abhängige Datensätze. Die untergeordneten Datensätze enthalten die Information, zu welchem übergeordneten sie gehören.
• Die Punktnotation ist nicht auf zwei Klassen beschränkt. In einer Zeile kann eine komplette Kette von der Klassenwurzel bis zu einem 'Blatt' über mehrere Stufen angegeben werden (entsprechend dem obigen Beispiel: FKB.Rolle Betrieb Ent.Entsorger.Teilanlage.Abfall TA=Ata).

Hinter dem Klassenpfad in Punktnotation kann für die letzte im Pfad angegebene Klasse ein Klassenalias angegeben werden:

Klasse_A=Alias_A
Klasse_A.Klasse_B=Alias_B

Die Aliasnamen müssen innerhalb einer Abfrage eindeutig sein! Die Alias-Namen werden in den nachfolgenden Abschnitten bei der Identifizierung der Attribute der FOM-Klassen verwendet.

Herkömmliche Abfragen sind immer als Inner-Join-Ausdrücke formuliert. Darunter ist zu verstehen, dass nur Datensätze in die Auswahl kommen, die in allen in der Abfrage miteinander verknüpften Klassen einen oder mehrere Datensätze enthalten⁶⁾. Unabhängig von den selbst definierten Auswahlbedingungen für die Datensätze im CONDITIONS-Abschnitt werden nur Datensätze in die Trefferliste aufgenommen, die diese Vorbedingung erfüllen, wobei diese Auswahl automatisch von der Datenbank vorgenommen wird. Es werden also ggf. Datensätze nicht in die Trefferliste aufgenommen, die zwar alle CONDITIONS-Ausdrücke erfüllen, aber in einer oder mehreren der verknüpften Klassen keine Daten enthalten. Ob dem so ist, kann nur festgestellt werden, wenn die 'leeren' Klassen aus dem CLASSES-Abschnitt wieder entfernt würden, was meist den Zweck der Abfrage konterkariert.

Zur bedarfsweisen Überwindung der Einschränkungen eines Inner-Join erlauben die Datenbanken auch Left-Join-Ausdrücke. Hierbei werden zwei Tabellen (linke Tabelle und rechte Tabelle) so miteinander verknüpft, dass alle Datensätze aus der linken Tabelle genommen werden - unter Berücksichtigung der übrigen CONDITIONS-Ausdrücke natürlich - und aus der rechten Tabelle die Datensätze, die mit den Datensätzen der linken Tabelle verknüpft sind. Falls dabei ein Datensatz in der linken Tabelle keine verknüpften Daten in der rechten Tabelle besitzt, wird er nicht automatisch entfernt sondern die Attribute der rechten Klasse werden in der Trefferliste für den Datensatz leer gelassen.

In ASYS gibt es im Datenmodell diverse Stellen, an denen einem übergeordneten Datensatz abhängige Datensätze zugeordnet werden können aber nicht müssen. Es wird dabei immer wieder Datensätze geben, für die aus unterschiedlichen Gründen keine abhängigen Daten eingetragen sind. Wird die Tabelle der abhängigen Daten mittels Inner-Join in eine Abfrage eingebunden, fallen a priori alle Datensätze aus dem Ergebnis heraus, die in dieser abhängigen Tabelle keine Einträge aufweisen (z.B. Ansprechpartner in Betrieb oder FKB, 4.BImSchV-Nummern für Teilanlagen). Wird die abhängige Tabelle hingegen mittels Left-Join eingebunden können derartige Datensätze wieder in die Treffermenge aufgenommen werden, sofern sie die übrigen Auswahlbedingungen erfüllen.

Zur Definition einer Left-Join-Beziehung wird am Ende der Zeile ein * ergänzt:

Klasse_A=Alias_A
Klasse_A.Klasse_B=Alias_B*
Klasse_a.Klasse_B.Klasse_C=Alias_C

In diesem Beispiel ist die Klasse_B per Left-Join mit der Klasse_A verbunden. Die Klasse_C ist per Inner-Join mit der Klasse_B verknüpft. Per Left-Join verknüpfte Klassen können also selbst wieder abhängige Klassen besitzen, für die unabhängig die Inner-Join oder Left-Join-Verknüpfung eingestellt werden kann.

Beachten Sie die grundsätzlichen Konventionen.

Im RESULTS-Abschnitt wird festgelegt, welche Attribute aus den im CLASSES-Abschnitt eingetragenen Datenbankklassen in der Treffermenge erscheinen. Damit eine Abfrage ein Ergebnis liefern kann muss mindestens ein Attribut in diesem Abschnitt eingetragen werden. Jedes Attribut ist in einer Zeile einzutragen. Die Reihenfolge der Zeilen bestimmt die Reihenfolge der Spalten in der Treffermenge.

Für die Notation der Ergebnisspalten gibt es zwei Varianten - eine einfache und eine komplexere:

Die einfache Notation ist für die einfachen Anwendungsfälle vorgesehen, bei denen der Attributwert unverarbeitet in die Ergebnisspalte überführt werden soll. Die einfache Notation lautet

Klassenalias.Attributname=Attributalias

Die Eingabehilfe im Administrator hilft bei der Auswahl der bekannten Klassenaliase und anschließend bei der Auswahl der Klassenattribute der zugehörigen Klassen.

Die komplexere Notation ist immer dann zu verwenden, wenn der Attributwert verarbeitet werden muss, bevor er in die Ergebnisspalte geschrieben wird. Die komplexe Notation lautet

[*|$]Attributalias[/Typmodifikator]=[Funktion(]{%Klassenalias.Attribut%}|Konstante|#@heute#[)]

Die Eingabehilfe im Administrator unterstützt auch bei der Formulierung derartiger Ausdrücke.

Für das erste Zeichen gibt es die Alternativen * und $:

• * : Der Attributwert ist eine Ganzzahl (Integer, Long)
• $ : Der Attributwert wird als Zeichenkette (String) interpretiert (für alle Attributwerte außer Ganzzahlen zu verwenden)

Die Typangabe vor dem Aliasnamen ist eine Pflichtangabe.

Hinter dem Attributalias kann ein Typmodifikator stehen. Geben Sie hinter dem Aliasnamen das Zeichen / ein und drücken Sie Strg+Leertaste, um die zugehörige kontextsensitive Eingabehilfe aufzurufen. Sie enthält die erlaubten Typmodifikatoren samt kurzer Erläuterung.

Der Typmodifikator ist optional zu verwenden, wenn der entsprechende Ergebnisspaltentyp auf Grund des Attributtyps benötigt wird.

Die Funktion verarbeitet optional den Inhalt des Attributs, der Konstante oder des aktuellen Datums. Hinter den Funktionsnamen ist eine öffnende runde Klammer zu setzen, die zugehörige schließende Klammer kommt hinter den Funktionsparameter. Wird die Eingabehilfe nach dem Gleichheitszeichen geöffnet, bietet der Administrator eine Auswahl häufig genutzter Funktionen an⁷⁾. Die angebotenen Funktionen ergeben sich aus dem aktuell angebotenen Katalog, der durch die kontextsensitive Eingabehilfe via Strg+Leertaste aufgerufen werden kann (s. Bedienungsanleitung zu Abfragen).

Grundsätzlich lassen sich die Funktionen auch ineinander schachteln, so dass das Ergebnis der inneren Funktion ein Parameter für die äußere ist. Der Aufruf

[...]=@nvl(@substring({%Klassenalias.Attributname%}, 1, 3), '---')

liefert beispielsweise die ersten drei Zeichen des Attributs Klassenalias.Attributname oder - - -, falls das Attribut leer ist.

Weitere Funktionen werden durch die jeweilige Datenbank zur Verfügung gestellt. Sie können genauso wie die hier dokumentierten verwendet werden, allerdings gibt es keine Unterstützung durch den Repository-Administrator oder Governikus ITU. Hinsichtlich der Dokumentation sei hiermit auf Hilfeseiten der Datenbankhersteller im Internet verwiesen.

Neben einem Verweis auf ein Klassenattribut kann auch ein konstanter Wert an einen Attributalias übergeben werden. Alle Datensätze der Trefferliste werden diesen konstanten Wert in dieser Spalte aufweisen. Die auf diese Weise definierte Trefferlistenspalte wird wie jede andere Spalte ausgegeben, auch wenn den Inhalt nicht aus den Datensätzen stammt, welche die Trefferliste bilden.

Wird der Attributalias als Zeichenkette getypt ($ vor dem Aliasnamen), so ist der konstante Wert in Anführungszeichen zu setzen:

$Attributalias='Konstanter Wert'

Handelt es sich bei der Konstante um einen Boolschen Wert (true oder false), so ist der Wert in Hashmarks zu setzen:

*Attributalias=#true#  //oder #false# 

Für Datumswerte sind ebenso Hashmarks zu setzen:

$Attributalias=#01.01.1970#
$Attributalias=#@heute#

Auch wenn das letzte Beispiel kein konstanter Wert ist, da hier das jeweils aktuelle Systemdatum ausgegeben wird, so demonstriert es doch die Verwendung von Hashmarks mit Datumswerten.

Einige Funktionen sind Aggregatfunktionen. Sie werden regelmäßig genutzt, wenn eine Abfrage mit Gruppierungsanweisungen im GROUP-Abschnitt versehen ist.

Bei einer Gruppierung werden die Daten einer Gruppe zusammengefasst zu einem Datensatz in der Trefferliste. In der Trefferliste gibt es zwei Arten von Spalten:

1. Die Werte der Trefferlistenspalten nach denen gruppiert wird, sind für die alle Datensätze einer Gruppe in der Gruppierungsspalte definitionsgemäß identisch - das ist das Wesen einer Gruppierung. Für diese Spalten ist der Ausgabewert eindeutig und bedarf keiner Präzisierung.
2. Für alle Trefferlistenspalten, nach denen nicht gruppiert wird, sind die Werte pro Spalte nicht eindeutig, da jeder der Datensätze, die eine Gruppe bilden, darin einen anderen Wert enthalten kann. Hier muss der Datenbank mitgeteilt werden, wie der Spaltenwert zur Ausgabe des einen aggregierten Gruppendatensatzes in der Trefferliste ermittelt werden soll. Dafür sind die Aggregatfunktionen zu verwenden, die festlegen, wie je Gruppe der Wert der Spalte ermittelt wird. Wichtig: Bei mehreren aggregierten Spalten können die ausgegebenen Spaltenwerte aus unterschiedlichen Datensätzen einer Gruppe stammen⁸⁾!

Für den Zugriff auf die ID-Felder einer Klasse ist eine spezielle Notation zu verwenden.

Klassenalias.=Attributalias

oder

*Attributalias={%Klassenalias.#%}

In der einfachen Notation wird also einfach hinter den Klassenalias ein Punkt geschrieben. In der komplexeren Notation muss hinter dem Klassenalias noch ein # geschrieben werden.

Im CONDITIONS-Abschnitt werden Bedingungen formuliert, denen die Datensätze in der Trefferliste genügen müssen. Diese Bedingungen haben zwei Aufgaben:

1. Die Filterung der Datensätze. Es werden nur die Datensätze aus den im CLASSES-Abschnitt angegebenen Klassen in die Trefferliste aufgenommen, die allen Bedingungen genügen.
2. Die Verknüpfung von Klassen. Über derartige Bedingungen wird festgelegt, wie die Datensätze zweier Klassen, die nicht im Datenmodell bzw. im CLASSES-Abschnitt verknüpft sind, miteinander in Beziehung stehen. So lassen sich beispielsweise mit einer Bedingung die Begleitscheine und die Entsorgungsnachweise über die Nachweisnummer verknüpfen.

Eine Abfrage kann ohne Bedingungen definiert werden. Dann werden alle Datensätze der einbezogenen Klassen zu Bestandteilen der Treffermenge. Durch das Kreuzprodukt bei mehreren Klassen (s.a. die zugehörige Fußnote auf dieser Seite) - und besonders bei unverknüpften! - können dabei sehr große Treffermengen entstehen⁹⁾! In der überwiegenden Mehrzahl der sinnvollen Anwendungsfälle werden daher Bedingungen definiert werden müssen.

Es gilt:

• Jede Zeile im CONDITIONS-Abschnitt stellt eine Bedingung dar.
• Mehrere Zeilen in diesem Abschnitt werden jeweils durch den logischen Operator UND (and) miteinander verknüpft. Jeder Datensatz der Trefferliste muss daher alle Bedingungen = alle Zeilen erfüllen.
• Alternative Bedingungen mit dem logischen Operator ODER (or) sind möglich, wenn sie in eine Zeile des CONDITIONS-Abschnitt geschrieben werden.

Bedingung A
(Bedingung B or Bedingung C)
Bedingung D

Dieses abstrakte Beispiel bedeutet: Alle Datensätze der Trefferliste müssen Bedingung A und mindestens eine von Bedingung B oder Bedingung C sowie die Bedingung D erfüllen. Die ODER-Bedingung der zweiten Zeile wird vor den UND-Bedingungen zwischen den drei Zeilen ausgewertet.

Diese Bedingung der Form A und B oder C und D kann auch anders gemeint sein:

((Bedingung A and Bedingung B) or (Bedingung C and Bedingung D))

Dies bedeutet, dass mindestens eines der beiden Bedingungspärchen A und B bzw. C und D erfüllt sein muss. Diese Form muss in eine Zeile geschrieben werden, weil hier die ODER-Bedingung nach den beiden UND-Bedingungen ausgewertet werden soll. Die beiden inneren Klammerpärchen sollten immer geschrieben werden, das äußere Klammerpärchen sollte geschrieben werden, wenn diese Bedingung durch weitere ergänzt wird, um die Interpretation eindeutig zu machen.

Im CONDITIONS-Abschnitt kommen zwei unterschiedliche Platzhalternotationen regelmäßig zum Einsatz:

1. Die {%…%}-Notation steht für Attribute aus der Datenbank. Angegeben werden diese in Punktnotation (vrgl. RESULTS-Abschnitt) als Kombination aus Klassenalias und Attributname aus dem ASYS-Fachobjektemodell, also {%Klassenalias.Attributname%}. Dieser Platzhalter wird bei der Ausführung gegen die Datenbanknamen der Tabelle/View und ihres Attributs ersetzt. Die Eingabehilfe des Administrators unterstützt bei der Auswahl korrekter Klassenaliasse und Attributnamen.
   Jede Bedingung besitzt einen Bezug auf mindestens ein Attribut der Datenbank. Dazu ist immer diese Platzhalternotation in den Abfragen zu verwenden.
2. Die {*…*}-Notation steht für Abfrageparameter. Abfrageparameter sind Bedingungswerte, die erst zur Ablaufzeit der Abfrage feststehen. Bei freien Abfrage müssen diese durch den Nutzer der Abfrage festgelegt werden. Bei internen Abfragen werden sie aus dem Datensatzkontext genommen, in dem die Abfrage ausgeführt wird.
   1. Für die Parameter einer freien Abfrage kann einfach ein selbstbeschreibender Name eingesetzt werden, also {*Parametername*}. Der Name ist eindeutig je Abfrage zu vergeben.
   2. Für die Parameter aus dem Datensatzkontext ist die Punktnotation zu verwenden, also {*Klassenname.Attributname*}. Dieser Platzhalter wird bei der Ausführung gegen den Wert aus dem Datensatzkontext der Maske oder der Nachricht ersetzt. Die Eingabehilfe des Administrators unterstützt bei der Auswahl korrekter Klassen- und Attributnamen.

1. Bedingungen mit Datumswerten sind immer durch #$ am Beginn und # am Ende des Vergleichs einzurahmen. Dies aktiviert die Umformung des Datumswertes in das spezifische Datumsformat der jeweiligen Datenbank.
   1. Einzige Ausnahme: Das Datumsattribut wird mit is null oder is not null verglichen. Dann ist die Standardschreibweise ohne #$…# zu verwenden.
2. Datumsangaben sind vielfach optional. Leere Datumsfelder werden in Bedingungen als nicht erfüllt gewertet, egal welcher Vergleichswert angegeben wird. Sie müssen durch eine per ODER angehängte Zusatzbedingung wieder einbezogen werden, die explizit die Bedingung stellt, dass das Datumsfeld leer (null) ist. Diese Zusatzprüfung lässt sich durch eine Kurznotation automatisch ergänzen, wenn der Bedingung durch #?$ (anstatt #$) eingeleitet wird.
3. Mit Datumswerten kann gerechnet werden: zu bzw. von einem Datumswert lassen sich Tage (t), Monate(m) und Jahre(j) addieren bzw. subtrahieren. Auch eine Kombination dieser Verrechnungszeiträume ist möglich wenn sie per Komma separiert hintereinander geschrieben werden. Vor die jeweilige Zahl ist ein + oder - für die Berechnung zu schreiben, die Einheit (t, m oder j) ist ohne Leerzeichen hinter den Wert zu schreiben.

Beipiele (der Vergleichsoperator > ist nach Bedarf durch den jeweils passenden zu ersetzen):

Besonderheit 1.: #${%Klassenalias.Datumsattribut%} > {*Vergleichsdatum*}#
Besonderheit 1.I: {%Klassenalias.Datumsattribut%} is null ==> Vergleich gegen NULL muss nicht ausgezeichnet werden
Besonderheit 2.: #?${%Klassenalias.Datumsattribut%} > {*Vergleichsdatum*}# ==> (#${%Klassenalias.Datumsattribut%} > {*Vergleichsdatum*}#) or {%Klassenalias.Datumsattribut%} is null
Besonderheit 3.: #${%Klassenalias.Datumsattribut%}+1j > {*Vergleichsdatum*}-1t# ==> zum Wert von Attributname wird 1 Jahr addiert und beim Vergleichsdatum 1 Tag abgezogen

Eine Bedingung besteht immer aus einem Vergleich zwischen zwei Werten (bestimmte Sonderfälle werden weiter unten behandelt). Zu einem Vergleich gehört dabei immer ein Vergleichsoperator. Eine Übersicht über die gebräuchlichen Operatoren findet sich in der Anwenderhilfe zur Datenbereichssuche¹⁰⁾. Die Aufstellung zu den Operatoren in der dortigen Tabelle gilt in gleicher Weise für Abfragen¹¹⁾

Manche Werte für Vergleiche lassen sich nicht aus der Datenbank, dem aktuellen Datensatz oder als konstanter Wert festlegen. Einige kontextabhängige Werte sind mittels Funktionen über das ASYS-internen Objekt sc erreichbar und können als Abfrageparameter in der {*…*}-Notation verwendet werden. Zu den sc-Funktionen siehe die Aufstellung zum Prüfregelcode.

1. Wenn im CLASSES-Abschnitt Klassen oder Klassenbäume enthalten sind, die nicht über die dort zu verwendende Punktnotation miteinander verbunden sind (s. Ziffer 4 des dortigen Info-Kastens), dann ist dringend zu empfehlen¹²⁾, in diesem Abschnitt Bedingungen für die Verknüpfung zwischen den Klassen manuell anzugeben. Hierfür kommen insbesondere Klassenattribute in Frage, die in zumindest einer der beiden zu verknüpfenden Klassen als logischer Schlüssel (lkey-Auszeichnung im Fachobjektemodell) gekennzeichnet sind. Der kombinierte Inhalt aller Attribute einer Klasse, die als logischer Schlüssel gekennzeichnet ist, muss eindeutig unter allen Datensätzen der Klasse sein.
2. Wenn im CLASSES-Abschnitt einzelne Klassen oder Teile von Klassenbäumen mittels Left-Join angebunden werden, so ist zu beachten, dass Bedingungen auf Attribute dieser Klassen die Left-Join-Eigenschaft der Klassenverknüpfung wieder aufheben!
3. Werden Ankreuzfelder (Attribute von Typ Boolean im Fachobjektemodell, meist mit einem FL_-Präfix im Attributnamen) in Bedingungen eingebunden, so sind die zulässigen Vergleichswerte #true# und #false# (inklusive der #!) zu verwenden, also {%Klassenname.BoolschesAttribut%} = #true# (oder #false#).
4. Wird im CONDITIONS-Abschnitt mit konstanten Zeichenketten gearbeitet, so sind einige Besonderheiten zu beachten:
   1. Wird als Vergleichswert eine konstante Zeichenkette verwendet, so muss sie in einfache Hochkommata gesetzt werden: {%Klassenname.Attributname%} = 'Vergleichswert'
   2. Wird als Vergleichswert das Ergebnis einer sc-Funktion verwendet, so muss sie in einfache Hochkommata gesetzt werden: {%Klassenname.Attributname%} = '{*sc.Funktionsname*}'
   3. Wird als Vergleichswert ein Parameter {*…*} mit einem Zeichenketteninhalt verwendet, so hängt es vom Einsatzzweck der Abfrage ab, ob Hochkommata notwendig sind:
      1. Bei Abfragen für Prüfregeln, Empfängerermittlung, Vorgangssteuerung (Ausnahme: Bearbeiterermittlung) und Textformulare sind keine Hochkommata zu setzen, da sie von der ASYS-Mittelschicht automatisch eingetragen werden: {%Klassenname.Attributname%} = {*Parametername*} (oder {*Klassenname.Attributname*}).
      2. Bei freien Abfragen und Abfragen, die für die Bearbeiterermittlung einer Vorgangssteuerung eingesetzt werden, sind immer Hochkommata zu setzen: {%Klassenname.Attributname%} = '{*Parametername*}' (oder '{*Klassenname.Attributname*}').

Gruppierung bedeutet, dass alle Datensätze mit gleichem Inhalt in dem/den Gruppierungsattribut(en) zu einem Datensatz zusammengefasst werden und damit in der Trefferliste nur noch einen Datensatz bilden. Die Datensätze der Trefferliste einer Abfrage können nach einem oder mehreren Attributen gruppiert werden. Wird nicht gruppiert, bleibt dieser Abschnitt leer.

Wird gruppiert, so müssen alle Gruppierungsattribute aus Klassen stammen, die im CLASSES-Abschnitt aufgeführt sind. Die Gruppierungsattribute müssen nicht im RESULTS-Abschnitt enthalten sein (auch wenn dies in der Praxis regelmäßig der Fall ist). Sie müssen auch nicht aus nur einer Klasse kommen.

Werden mehrere Gruppierungsattribute angegeben, so werden sie in diesem Abschnitt alle in eine Zeile geschrieben und durch Kommata getrennt:

{%Klassenname.Gruppierungsattribut1%}, {%Klassenname.Gruppierungsattribut2%}, ...

1. Wie im Abschnitt RESULTS - Aggregatfunktionen erläutert, müssen alle anderen Ausgabeattribute, die nicht Gruppierungsattribute sind, durch eine Aggregatfunktion ergänzt werden, damit die Datenbank die Ausgabewerte für die Attribute in dem einen Gruppendatensatz der Trefferliste eindeutig bestimmen kann.
2. Die Gruppierung muss nicht notwendigerweise an Hand unverarbeiteter Attributwerte erfolgen. Es ist auch zulässig, den Inhalt der Gruppierungsattribute durch Funktionen zu modifizieren: @substring({%Klassenname.Attributname%}, 1, 1) gruppiert beispielsweise nach dem ersten Zeichen des Attributwertes

In diesem Abschnitt kann die Sortierung der Datensätze in der Trefferliste festgelegt werden. Die Trefferliste kann nach einem oder mehreren Attributen sortiert werden. Wird nicht sortiert, so werden die Datensätze in der Reihenfolge ausgegeben, wie die Datenbank sie zurückliefert und dieser Abschnitt bleibt leer.

Wird sortiert, so müssen alle Sortierungsattribute aus Klassen stammen, die im CLASSES-Abschnitt aufgeführt sind. Die Sortierungsattribute müssen nicht im RESULTS-Abschnitt enthalten sein (auch wenn dies häufig der Fall ist). Sie müssen auch nicht aus nur einer Klasse kommen.

Werden mehrere Sortierungsattribute angegeben, so werden sie in diesem Abschnitt alle in eine Zeile geschrieben und durch Kommata getrennt:

{%Klassenname.Sortierungsattribut1%} ASC, {%Klassenname.Sortierungsattribut2%} DESC, ...

Hinter jedem Attribut ist anzugeben, wie sortiert werden soll:

• ASC (=Ascending): Aufsteigende sortieren, die kleinsten Werte stehen in der Trefferliste zuoberst (diese Angabe ist optional, ohne Sortierangabe hinter dem Attribut wird aufsteigend (ASC) sortiert).
• DESC (=Descending): Absteigend sortieren, die größten Werte stehen in der Trefferliste zuoberst.

Achtung: Wird nach mehreren Attributen sortiert, so kommt es auf die Reihenfolge der Sortierungsattribute in diesem Abschnitt an! Alle Datensätze der Trefferliste werden zunächst nach dem ersten Sortierungsattribut sortiert. Alle Datensätze mit gleichen Werten im ersten Sortierungsattribut werden anschließend nach dem zweiten Sortierungsattribut sortiert. Entsprechend geht es mit dem dritten und allen weiteren Sortierungsattributen weiter.

Im HAVING-Abschnitt können Bedingungen definiert werden, die erst nach der Ermittlung der Treffermenge auf die Datensätze darin zur Anwendung kommen. Im Unterschied dazu werden die Bedingungen im CONDITIONS-Abschnitt auf jeden einzelnen Datensatz der Datenbank angewandt, also vor der Ermittlung der Treffermenge.

Zum Einsatz kommen HAVING-Bedingungen immer dann, wenn sich die Bedingung nicht am einzelnen Datensatz in der Datenbank, sondern erst im gefilterten und gruppierten Ergebnis prüfen lässt. Durch die Gruppierung werden Datensätze der Datenbank zu einem Gruppendatensatz in der Treffermenge zusammengefasst. Der Wert der Ausgabeattribute eines Gruppendatensatzes in der Trefferliste ergibt sich dabei erst nach Abschluss der Filterung und Gruppierung, nicht selten als Ergebnis von Aggregatfunktionen.

Aber auch hier gilt: Der Ausdrücke, die für eine HAVING-Bedingung herangezogen wird, müssen nicht im RESULTS-Abschnitt enthalten sein. Sie müssen sich aber aus den Gruppen ermitteln lassen!

Die HAVING-Bedingung(en) ist/sind in eine Zeile zu schreiben. Werden mehrere Bedingungen angegeben, so sind sie geeignet durch and (UND) und or (ODER) logisch zu verknüpfen.

Beispiele ({%Klassenname.Attributname%} soll je Beispiel nur genau ein Attribut identifizieren, also nicht mehrere aus einer oder mehreren Klassen):

1. count(*) > 10 =⇒ Gib nur Gruppen aus, die aus mehr als 10 Datensätzen gebildet wurden
2. count({%Klassenname.Attributname%}) = 0 =⇒ Gib nur Gruppen aus, die im angegebenen Attribut keinen Inhalt aufweisen
3. (count(*) > 10) and (@substring({%Klassenname.Attributname%}, 1, 1) < 'F') =⇒ Nur Gruppen mit mehr als 10 Datensätzen und aus den Gruppen 'A' bis 'E' (funktioniert nur, wenn auch @substring({%Klassenname.Attributname%}, 1, 1) im GROUP-Abschnitt eingetragen ist!)
4. (@substring({%Klassenname.Attributname%}, 1, 1) < 'F') and (@substring({%Klassenname.Attributname%}, 4, 1) <> 'T') =⇒ soll alle Gruppen mit 'A' bis 'E' an Position 1 ausgegeben, bei denen das vierte Zeichen kein 'T' ist.
   1. funktioniert nicht, wenn im GROUP-Abschnitt @substring({%Klassenname.Attributname%}, 1, 1) eingetragen ist, weil nur das Zeichen an Position 1 zur Gruppierung dient.
   2. funktioniert nicht, wenn im GROUP-Abschnitt @substring({%Klassenname.Attributname%}, 1, 4) eingetragen ist, obwohl die Gruppierung nun die ersten vier Zeichen umfasst. Beide Having-Bedinungen weichen aber mit …, 1, 1) und …, 4, 1) vom Gruppierungsausdruck mit …, 1, 4) ab.
   3. funktioniert, wenn im GROUP-Abschnitt @substring({%Klassenname.Attributname%}, 1, 1), @substring({%Klassenname.Attributname%}, 4, 1) eingetragen ist, da für beide Bedingungen eine passende Gruppierungsanweisung existiert.
   4. wenn im GROUP-Abschnitt @substring({%Klassenname.Attributname%}, 1, 4) eingetragen ist, funktioniert auch (@substring({%Klassenname.Attributname%}, 1, 4) like 'F*') and (@substring({%Klassenname.Attributname%}, 1, 4) not like '*T')

Was sind Variables? Variables-Definitionen definieren Zusatzinformationen für Parameter in Abfragen. Parameter in Abfragen sind diejenigen Werte, die erst zur Laufzeit aus den Daten eines aktuellen Datensatzes oder durch den Nutzer eingegeben werden – das sind die mit {*…*} eingefassten Namen.

Wozu dienen die? Wenn Sie Abfragen für die Nutzer definieren (freie Abfragen), so werden diese meistens nicht (nur) mit statischen Bedingungen versehen sein, sondern die Nutzer sollen eigene Werte für die Bedingungen eingeben können – z.B. ein Startdatum, einen Landeskenner etc. Mit den Variables-Definitionen lassen sich unterschiedliche Eingabeunterstützungen für die Nutzer der Abfragen definieren, um das Verständnis, wie die Eingabe von Abfrageparametern erfolgen soll, zu vereinfachen. Variables-Definitionen sind also – mit einer Ausnahme (siehe unten) – für freie Abfragen vorgesehen. Bei internen Abfragen haben sie keine Funktion.

VARIABLES erlauben es, bei freien Abfragen (und mit dem Attribut 'Value' auch für Regelabfragen) für vom Anwender auszufüllende Parameter des CONDITIONS-Abschnitts eine Reihe von Formatierungsanweisungen festzulegen, mit denen sich der Aufruf einer Abfrage benutzerfreundlicher gestalten lässt, da die vom Anwender auszufüllenden Parameter ({*Parametername*}) mit Zusatzinformationen und Formatierungen versehen werden können. Die Syntax für einzelne Formatierungsanweisungen lautet hierbei (Eingabe ohne spitze Klammern!):

<Parametername>.<Eigenschaft>=<Wert>

Für die Eintragung der Parameter und der Eigenschaften kann via Strg+Leertaste eine Eingabeunterstützung aufgerufen werden (vgl. Abfragen).

Folgende Eigenschaften können gesetzt werden:

Jede VARIABLES-Definition ist in eine Zeile zu schreiben.

In diesem Abschnitt können Abfragen angegeben werden, deren Ergebnisse während der Ausführung zusammengefasst werden.

Werden mehrere Abfrage angegeben, so werden sie in diesem Abschnitt alle in eine Zeile geschrieben und durch Kommata getrennt:

Abfrage 1, Abfrage 2, ...

SKRIPTS erlauben es, auf den in den RESULTS ermittelten Spalten und Werten (Rechen)Operationen auszuführen, die weiteren Ergebnisspalten liefern.

Angegeben wird im SKRIPTS-Abschnitt der Name der Ergebnisspalte und hinter dem Gleichheitszeichen die auszuführende Anweisung. Wie bei den RESULTS darf der Name keine Leer- oder Sonderzeichen enthalten.

Hinter dem Namen der Ergebnisspalte muss mit / getrennt der Typ angegeben werden. Wird kein Typ angegeben, wird String (Zeichenkette) verwendet. Weitere Typen neben double (Fließkommazahl) sind int (Ganzzahl) und date (Datum).

Unter RESULTS sollte ebenfalls der Typ mit angegeben werden, zumindest bei double und bei date.

Um die Resultate verwenden zu können, muss jeweils die Methode dc.get…Value(„…“) verwendet werden (dc.getDoubleValue, dc.getIntValue, dc.getMemoValue, dc.getStringValue).

Es können auch mehrere SKRIPTS in einer Abfrage verwendet werden. In diesem Fall wird jedes Skript eine Zeile geschrieben.

Die Anweisungen, die in einem SKRIPTS-Abschnitt verwendet werden, werden wie Prüfregeln, also in Java definiert. Statt der Variablen in der {% … %}-Notation wird die o.g. dc.get…-Notation verwendet.

Mit dem IN-Operator lässt sich der Wert eines Bedingungsattribut im CONDITIONS-Abschnitt mit einer Ergebnismenge einer Unterabfrage vergleichen. Die Bedingung ist erfüllt, wenn der Wert des Bedingungsattributs in der Wertemenge der Unterabfrage enthalten ist (IN) bzw. nicht enthalten ist (NOT IN). Die Unterabfrage enthält hierfür nur eine Ergebnisspalte.

{%Klassenalias.Attributname%} [NOT] IN (Unterabfrage)
{%Klassenalias.Attributname%} [NOT] IN ({%*Abfrage%}) (ab Version 7.09.00)

Die folgende Anleitung/Einschränkung gilt nur bis zur Version 7.09.00 (ab der Version 7.09.00 kann auf eine andere Abfrage verwiesen werden)
Die Unterabfrage kann nicht als Verweis auf eine andere Abfragendefinition im Repository formuliert werden. Statt dessen muss die Unterabfrage als ausführbares SQL-Statement in die Zeile des CONDITIONS-Abschnitts eingetragen werden. Die Schritte hierzu sind:

1. Formulierung der Unterabfrage im Repository-Administrator mit den üblichen Werkzeugen zur Definition einer Abfrage.
2. Übergabe der Unterabfrage an die Administrator-Client-Anwendung zum Test.
3. Wenn die Abfrage das gewünschte Ergebnis liefert, kann das ausgeführte Datenbankkommando in der Client-Anwendung im Konsolenbereich markiert und per Strg-C in die Zwischenablage kopiert werden.
4. Im Repository-Administrator kann dieses Datenbankkommando im CONDITIONS-Abschnitt eingerahmt durch ein Klammerpärchen (…) hinter den IN/NOT IN-Operator eingefügt werden.
5. Die Unterabfrage muss in einer Zeile stehen!

Mit dem UNION-Operator lassen sich zwei oder mehr Abfragen zu einer Treffermenge kombinieren s. UNION-Abschnitt ab Version 7.09.00. Die Bedingungen hierfür sind:

1. Die Abfragen müssen die gleichen Ergebnisspalten im RESULTS-Abschnitt enthalten (gleiche Alias-Namen der Attribute).
2. Die Reihenfolge der Ergebnisspalten muss übereinstimmen.
3. Die Typen der Ergebnisspalten müssen übereinstimmen (Bei gleicher Position und gleichem Aliasnamen lassen sich z.B. eine Zeichenkette und ein Ankreuzfeld nicht zusammenführen!).

{%Klassenalias.Attributname%} operator Vergleichswert UNION (UNION-Abfrage) 

Die folgende Anleitung/Einschränkung gilt nur bis zur Version 7.09.00 (ab der Version 7.09.00 gibt es einen eigenen UNION-Abschnitt)
Eine per UNION verbundene Abfrage kann nicht als Verweis auf eine andere Abfragendefinition im Repository formuliert werden. Statt dessen muss die Unterabfrage als ausführbares SQL-Statement in die letzte Zeile des CONDITIONS-Abschnitts eingetragen werden. Die Schritte hierzu sind:

1. Formulierung der UNION-Abfrage im Repository-Administrator mit den üblichen Werkzeugen zur Definition einer Abfrage.
2. Übergabe der Abfrage an die Administrator-Client-Anwendung zum Test.
3. Wenn die Abfrage das gewünschte Ergebnis liefert, kann das ausgeführte Datenbankkommando in der Client-Anwendung im Konsolenbereich markiert und per Strg-C in die Zwischenablage kopiert werden.
4. Im Repository-Administrator kann dieses Datenbankkommando im CONDITIONS-Abschnitt eingerahmt durch ein Klammerpärchen (…) hinter der letzten Bedingung eingefügt werden.
5. Die UNION-Abfrage muss in einer Zeile stehen!
6. Bei mehr als zwei UNION-Abfragen ist dieser Weg entsprechend rekursiv zu gehen, d.h. die Abfrage zweier verbundener Abfragen wird per UNION in den CONDITIONS-Abschnitt einer dritten Abfrage eingefügt.

Die ASYS-Standardkonfiguration enthält vier Beispiele einer Anwendung dieses Operators. Sie lassen sich im Filterdialog des Abfragenbaums über das Filterwort union auswählen.

Hinweis: UNION-Trefferlisten haben eine Besonderheit, welche die einzelnen Abfragen nicht aufweisen: Die Trefferliste enthält keine Duplikate, d.h. es werden automatisch alle Datensätze ausgefiltert, die in allen Ergebnisspalten identische Werte aufweisen. Derartige Datensätze werden nur einmalig ausgegeben. Die Summe der Datensätze in der UNION-Trefferliste kann daher kleiner sein, als die Summe der Datensätze addiert über die einzelnen Abfragen.

Aus der Ergebnisliste einer freien Abfrage kann automatisch in eine Maske gesprungen werden, wenn folgenden Randbedingungen eingehalten werden:

1. Der Abfrage ist eine zu öffnende Maske zugewiesen, die aus der Ergebnisliste der Abfrage heraus geöffnet werden soll.
2. Als erstes Feld im RESULTS-Abschnitt der Abfrage ist das ID-Feld der Hauptklasse der unter 1 zugewiesenen Maske anzugeben und dieses ID-Feld muss den Aliasnamen THE_ID haben. Um welche Hauptklasse es sich hierbei handelt wird neben der zu öffnenden Maske angezeigt (die Anzeige erfolgt erst, nachdem die Änderungen der Abfrage übernommen wurden).

RESULTS

*THE_ID={%Klassenalias.#%}
...

Alte Themenseite zu Ausdrücken in Abfragen

Zurück zum Seitenanfang