Verkettete Projektion
Projektion - Kurzfassung
Zweck: Ermöglicht das Verketten von Projektionen und Joins, um einen bestimmten Rückgabewert bereitzustellen.
Die Verkettete Projektion ermöglicht das Verketten von Projektionen und Joins, um einen bestimmten Rückgabewert bereitzustellen.
Ähnlich wie beim Verketten von Wertauflösern (s. Verketteter Wertauflöser) geben die verketteten Elemente den jeweiligen Rückgabewert an die nachfolgende Stufe als Bezugsobjekt (z. B. für dort definierte Projektionen) weiter.
Innerhalb der Kette können sämtliche Projektionen eingesetzt werden, außer die Collection Projektion und die Verkettete Projektion selbst.
Die Verkettete Projektion kann allerdings durchaus innerhalb einer Collection Projektion eingesetzt werden, um mehrwertige Rückgabewerte aus der Kette als Listenwert zu "bündeln".
Außerdem können alle Typen von Joins verkettet werden, um "fremde" Inhalte in den Kontext der Kette einzubeziehen.
►HINWEIS◄ Werden innerhalb derselben Suche mehrere Verkettete Projektion-Instanzen eingesetzt, die sinngemäß gleichartige Joins beinhalten, werden diese in der Datenbankabfrage nicht etwa redundant angelegt. Stattessen wird auch dann mehrfach auf einen gemeinsam genutzten Join zugegriffen, wenn jede Verkettete Projektion einen unterschiedlichen Namen für den "Join Alias" verwendet. Allerdings werden sehr wohl redundante Joins verwendet, wenn eine Verkettete Projektion einen Join beinhaltet, dessen Konfiguration identisch mit einer expliziten Konfiguration in der "Joins"-Aufzählung der Suche ist.
Konfiguration
Parameter |
Typ |
Beschreibung |
Name |
String |
Der optionale Parameter Name kann verwendet werden, um der Projektion einen (Alias-)Namen zuzuweisen.
|
Verkettung |
Elemente |
Die Verkettung ist initial immer leer (s. Screenshot oben), was zur Laufzeit einen Fehler (NullPointerException) verursacht. Ein Klick auf das große Für Elemente einer bestehenden Kette erscheint, wenn sich der Mauszeiger nähert, am unteren und oberen Rand ein kleines Um Elemente aus einer bestehenden Kette zu entfernen, kann die Funktionen "Wert entfernen" im Kontextmenü verwendet werden. Das Kontextmenü bietet außerdem die üblichen "Operatoren" für die Zwischenablage ("Ausschneiden", "Kopieren" und nach dem Kopieren oder Ausschneiden auch "Einfügen") von Lobster Data Platform / Orchestration an, die für einzelne Elemente der Kette angewendet werden können. Unabhängig von der Anzahl der Elemente in der Kette definiert das letzte Element der Kette den Rückgabewert. |
|
Beispiele
Einfaches Beispiel: "Besitzer"-Konto einer Entität hinzuziehen
In einer Tupel-Suche für einen beliebigen Entitätstyp soll das komplette Firmenkonto für dessen "Besitzer" als komplexer Wert einer Spalte ausgegeben werden.
Konfiguration:
Der Screenshot rechts zeigt eine Verkettete Projektion, die als einziges Element einen Datenobjekt Join mit der folgenden Parametrierung enthält:
►HINWEIS◄ Wie der Typhinweis am unteren Rand andeutet, liefert der Datenobjekt Join ein "Firmenkonto" (sofern vorhanden), das hier mangels Nachfolger-Element auch für die Verkettete Projektion insgesamt gilt. |
|
Variante:
Ausgehend von vorherigen Anwendungsfall soll die Tupel-Spalte anstelle des gesamten Kontos nun doch nur einen verketteter String mit ausgewählten Adressmerkmalen den "Besitzer" kennzeichnen.
Konkret sollen die Felder "Name" (name1) und "Kontonummer" (accNumber) getrennt durch einen Unterstrich (_) erscheinen.
Konfiguration:
Ausgehend vom wie oben konfigurierten Datenobjekt Join (owner), der das komplette Firmenkonto für den "Besitzer" der Entität liefert, wird die Kette wie rechts abgebildet um zwei Projektionen (als Nachfolger) verlängert:
Die Verkettete Projektion liefert nun insgesamt Text. |
|
Komplexerer Anwendungsfall: "Besitzer des Besitzers" identifizieren
Ausgehend vom vorherigen Beispiel soll eine weitere Tupel-Spalte hinzugefügt werden, die nach dem Schema der "Variante" den Besitzer der Besitzer-Firma der Entität im Kontext der Suche über seine Adressmerkmale identifiziert.
Konfiguration:
Die im Screenshot rechts abgebildete Verkettete Projektion kann ausgehend von einer Kopie der oben als "Variante" bezeichneten Projektion mit folgenden Änderungen erstellt werden:
►HINWEIS◄ Die Kopie der bestehenden Datenobjekt Join-Instanz kann hier ohne Änderungen verwendet werden, weil die folgenden Bedingungen erfüllt sind:
|
|
Erweiterung:
Die Suche soll nun noch eine Bedingung beinhalten, die sicherstellt, dass mindestens eines der in der ONE_OVER_ONE-Projektion verketteten Adressmerkmale gefüllt ist.
Konfiguration:
►ANMERKUNGEN◄
In der Datenabfrage wird nicht etwa für jede Datenobjekt Join-Instanz ein eigenständiger Join generiert. Das wären immerhin "Firmenkonto"-Joins nur für die ONE_OVER_ONE-Spalte und die zughörige Bedingung.
Konkret wird für jede Besitzer-Ebene ein "Firmenkonto"-Join mehrfach genutzter LEFT OUTER JOIN verwendet und für den Zugriff auf die zugehörige Adresse ein weiterer.
Durch Kopieren, Einfügen und Anpassen sind die benötigten Varianten recht bequem "herzustellen", wenn eine Verkettete Projektion mit den beiden Joins einmal aufgebaut ist.
Natürlich könnte man auch die beiden "Firmenkonto"-Joins "zentral" anlegen und je Verwendung über zwei allgemeine "Join Alias"-Namen (z. B. owner, ownersOwner) adressieren. Mit Blick auf die Performance zur Laufzeit bietet das aber keinen wesentlicher Vorteil, solange nicht beide Methoden gleichzeitig eingesetzt werden. Wenn je "Firmenkonto"-Join nur eine zentrale Definition angelegt ist, vermeidet man das Risiko, dass individuelle Anpassungen an ursprünglich identischen Join-Konfigurationen vorgenommen werden. Dadurch könnte sich die Anzahl der in der Datenbankabfrage generierten Joins erhöhen.