Zugehörige Informationen | |||
Abfragecode und Ausdrücke, Ausdrücke in Prüfregeln, Ausdrücke in Skripten, Reguläre Ausdrücke | Allgemeine Bedienungshinweise | — | — |
Abfragen |
Diese Seite informiert über die Möglichkeiten der Formulierung von Abfragecode.
Die Bedienung der Administrator-Maske zur Definition einer Abfrage wird hier nicht erklärt!
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) hinterlegt1). 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 kann2).
Die Hauptbestandteile einer Abfrage sind - in Analogie zu SQL-Ausdrücken:
Abschnitt | Inhalt | Anmerkung zum Administrator/Repository für ASYS V6.x/7.x |
---|---|---|
CLASSES | Klassen (Tabellen oder Views) des ASYS-Fachobjektemodells, deren Attribute in den nachfolgenden Abschnitten verwendet werden inkl. ihrer Beziehung und einem beliebigen Alias–Namen. (FROM-Abschnitt in SQL) | → Tab-Reiter Code 1 |
RESULTS | Ergebnisse, die zurückgeliefert werden sollen inkl. ihres beliebigen Alias–Namens. (SELECT-Abschnitt in SQL) | → Tab-Reiter Code 1 |
CONDITIONS | Bedingungen, die berücksichtigt werden sollen (WHERE-Klausel in SQL). | → Tab-Reiter Code 1 |
GROUP | Gruppierungsanweisung (GROUP BY-Klausel in SQL) | → Tab-Reiter Code 1 |
ORDER | Sortieranweisung für die Ergebnisse (ORDER BY-Klausel in SQL) | → Tab-Reiter Code 2 |
HAVING | Bedingungen, die Ergebnisse von SQL-Funktionen auswerten (HAVING-Klausel in SQL). | → Tab-Reiter Code 2 |
VARIABLES | Nur für freie Abfragen: Formatierungsanweisungen für im CONDITIONS-Bereich verwendete Parameter | → Tab-Reiter Code 2 |
VARIABLES.Value | Nur für Regelabfragen: Ermittlung eines Parameter-Wertes über eine ASYS-Funktion | → Tab-Reiter Code 2 |
UNION | Abfragenverknüpfung (UNION select…) | → Tab-Reiter Code 2 |
SCRIPTS | Anweisungen zur Erzeugung zusätzlicher Ergebnisspalten aus den ermittelten Daten (Beispiele s.u.). | → Tab-Reiter Code 2 |
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.
Verwenden Sie für die in den nachfolgend erläuterten Abschnitten einzutragenden Codefragmente ausschließlich Standardzeichen des Alphabets!
Deutsche Sonderzeichen (äÄ, öÖ, üÜ, ß) sind unbedingt zu vermeiden, da die nicht als Platzhalter für Datenbankattribute dienenden Bestandteile der Abfragendefinition unverändert in die generierten SQL-Kommandos an die Datenbank durchgereicht werden. Die Datenbanken können aber die vom lateinischen Standardalphabet abweichenden Zeichen meist nicht korrekt verarbeiten.
Die Alias-Namen für Tabellen und Views (Abschnitt CLASSES) bzw. für Attribute (Abschnitt RESULTS) dürfen nur aus Ziffern, Standardbuchstaben und dem Unterstrich (_) bestehen.
Leerzeichen, Satzzeichen (!?,;. etc.) und Sonderzeichen (&%$§ etc.) sind nicht erlaubt!
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 werden3).
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 statt4). 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 Klassen5). 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
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.
Wir empfehlen, in jedem Fall Aliasnamen zu vergeben! (ohne Angabe eines Aliasnamen, vergibt der Administrator beim Verlassen des Eingabefeldes automatisch einen Aliasnamen XX[Zahl]) In der Praxis haben sich 3-Zeichen-Aliasnamen bewährt, weil einerseits genügend eindeutige dreibuchstabige Zeichenkombinationen zur Verfügung stehen und andererseits bei geeigneter Wahl der Buchstabenfolge der Name der Klassen hinreichend selbsterklärend abgekürzt werden kann.
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 enthalten6). 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 $:
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 an7). 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.
Alle Ergebnisspalten, die nicht in der Gruppierungsanweisung aufgeführt sind, müssen mit einer Aggregatfunktion definiert werden!
Bei einer Gruppierung werden die Daten einer Gruppe zusammengefasst zu einem Datensatz in der Trefferliste. In der Trefferliste gibt es zwei Arten von Spalten:
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:
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 entstehen9)! In der überwiegenden Mehrzahl der sinnvollen Anwendungsfälle werden daher Bedingungen definiert werden müssen.
Es gilt:
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:
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 Datenbereichssuche10). Die Aufstellung zu den Operatoren in der dortigen Tabelle gilt in gleicher Weise für Abfragen11)
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.
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%}, ...
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:
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):
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:
Eigenschaft | Bedeutung / Wert |
---|---|
Aliasname | Für die vom Nutzer einzutragenden Abfrageparameter kann ein Aliasname vergeben werden. Hintergrund: Die Abfrageparameter werden dem Anwender in einer kleinen zweizeiligen Tabelle angeboten, die nach dem Namen der Parameter sortiert ist. Um die Parameter in eine fachlich sinnvolle Reihenfolge bringen zu können, musste bislang i.d.R. mit vorangestellten Ziffern gearbeitet werden, die in der Tabelle als Überschriften mit angezeigt werden. Über den Aliasnamen kann eine sinnvollere Beschriftung (auch mit Leerzeichen) für die Abfrageparameter erfolgen, ohne die Sortierung der Parameter - weiterhin nach den im CONDITIONS-Abschnitt vergebenen Parameternamen - zu beeinflussen. |
Default | Default-Wert, der bei Auswahl der Abfrage für diesen Parameter als Wert vorgeschlagen wird. Wird hinter <Parametername>.Default= mit Strg+Leer die Kontexthilfe aufgerufen, so öffnet sich eine Auswahlliste der Skriptdefinitionen, die für die Defaultwertermittlung von freien Abfragen definiert wurden. |
Type | Datentyp: Mögliche Einträge sind String (Zeichenkette; Default, wenn kein Type definiert wird), Date (Datum), Boolean (Ankreuzfeld), Double (Fließkommazahl). Je nachdem, welcher Typ angegeben wird verändert sich das Verhalten an der Oberfläche. Date: Eingabe wird auf korrektes Datum überprüft. Es kann ein Datum aus einem Kalender ausgewählt werden. Boolean: Anzeige als Checkbox; nur true oder false sind möglich. Double: Eingabe wird auf korrekte Zahl überprüft. |
Info | Tooltiptext, der bei Auswahl des Parameters erscheint. |
SQD | Name einer anderen Abfrage. Diese wird bei der Auswahl der Abfrage ausgeführt und füllt eine Auswahlliste, aus der der Anwender dann einen Wert auswählen kann. Überregelt bei Auswahl des Datentyps Date die Anzeige des Kalenders und zeigt stattdessen die Auswahlliste. |
RegExp | Regular Expression, die vor der Ausführung der Abfrage für den Parameterwert kontrolliert wird. Wird die Regular Expression nicht eingehalten, erhält der Anwender eine Mitteilung und muss den Wert anpassen. |
Value (nur für Regelabfragen) | Es gibt die Möglichkeit, für Parameter aus dem CONDITIONS-Bereich einer Regelabfrage den Parameter vor Ausführung der Abfrage über eine ASYS-Funktion ermitteln zu lassen. Zur Verfügung stehen hierbei die im Kapitel Prüfregeln aufgeführten ASYS-Funktionen. Besonderheit: Der Zugriff auf Daten des zugrunde liegenden Datenkontextes hat hierbei immer über die dc-Funktionen zu erfolgen (z.B. dc.getDateValue('Klassenname.Attributname')); die {*…*}-Notation kann hierfür nicht verwendet werden! Diese Funktionaliät wird für die Regelabfragen der Standardprüfpläne umfangreich genutzt. Beispiele können dort eingesehen werden (z.B. in der Abfrage: IKA STD BGS AVV gefaehrlich) |
ZeitraumVon ZeitraumBis | Nur für Datumsfelder in freien Abfragen, wenn für eine Datumsangabe zwei Parameter (Zeitraum von … bis …) gefüllt werden müssen. Sorgt dafür, dass bei der Ausführung der Abfrage die Funktionalität zur Jahres-, Quartals- und Monatsauswahl angeboten wird. Das Parameter-Pärchen aus 'Beginn des Zeitraum' und 'Ende des Zeitraums' wird durch Angabe der gleichen Zahl bei 'ZeitraumVon' und 'ZeitraumBis' zusammengeführt. |
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.
Hinweis: Der Abschnitt SKRIPTS kann in Abfragen für 'erweiterte Textformulare' nicht verwendet werden!
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:
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:
{%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:
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:
RESULTS
*THE_ID={%Klassenalias.#%} ...
Alte Themenseite zu Ausdrücken in Abfragen
Weitere Informationen zu diesem Thema | ||||||||||||||||
Abfragen | ||||||||||||||||
landesspezifische Zusatzinformationen: | SH | HH | NI | HB | NW | HE | RP | BW | BY | SL | BE | MV | ST | BB | TH | SN |