Der Screenshot rechts zeigt die Konfiugration für die CSV Suche mit Projektionen und Joins:

• Die erste Feldprojektion greift direkt auf das Feld "Benutzername" (username) im Benutzerkonto zu.
  
  

• Die zweite Feldprojektion greift direkt auf das Feld "Besitzer"(ownerId) im Benutzerkonto zu.
  
  

• Die dritte Feldprojektion bezieht sich per Join Alias cmp auf die "Besitzer"-Firma, um deren Adressfeld "Kontonummer" (address.accNumber) zurückzugeben.

Die Zuordnung der "Besitzer"-Firma je Benutzer regelt der Datenobjekt Join:

• Als Datenobjekt ist der Entitätstyp "Firmenkonto" (CompanyAccount) ausgewählt.
  
  

• Als Join Alias wurde willkürlich der Name cmp (als Kürzel für "Company") zugeordnet. In weniger übersichtlichen Szenarien wäre sicherlich ein aussagekräftigerer Alias-Name (z. B. ownerCompany) empfehlenswert.
  
  

• Als Join Typ ist "Inner" ausgewählt, da unsere Liste nur Benutzer enthalten soll, für die die Join Bedingung erfüllt ist.
  
  

• Die Optional-Option wurde abgewählt, damit der "Inner"-Join auch dann einschränkend wirkt, falls sich keine der Ausgabespalten ausdrücklich auf den cmp-Alias bezieht (s. "Variante" unten).
  
  

• Die Join Bedingung verlangt, dass die Referenz im Feld "Besitzer" (ownerId) mit der "ID" einer Firma (cmp.id) übereinstimmen muss, damit diese im Suchergebnis dem Benutzer zugeordnet wird.

Im Abfragekonfigurator kann man für die bestehende Konfiguration den "Suchtyp" von CSV Suche auf Suche umstellen. Dadurch fallen die Projektionen weg und es verbleibt nur der rechts abgebildete Datenobjekt Join:

• Da wir die Optional-Option abgewählt haben, wirkt der Join Typ "Inner" auch ohne Vorhandensein einer Projektion, die sich auf den Alias cmp bezieht, einschränkend für die Suche als Ganzes. In der Ergebnisliste erscheinen nur Benutzerkonten, die sich auf eine konkrete "Besitzer"-Firma beziehen.
  
  

• Würde die Optional-Option ausgewählt, dann könnten in der Ergebnisliste ggf. auch Benutzer enthalten sein, denen kein "Besitzer" zugeordnet ist oder die sich auf ein Firmenkonto als "Besitzer" beziehen, das nicht (mehr) existiert. In diesem Fall hätte der Datenobjekt Join dann auch keinerlei Einfluss mehr auf das Ergebnis, da er weder Projektionen "füttert" noch als Einschränkung wirkt. Er wird deshalb datenbankseitig auch nicht abgebildet, obwohl er in der Konfiguration enthalten ist.

Als minimalen Informationsumfang sollte die CSV-Suche drei Projektionen für Ausgabespalten beinhalten:

• Die erste Feldprojektion bezieht sich auf das "Name" (name) Feld, also den Schlüsselwert für die Erkennung von "Duplikaten".
  
  

• Die zweite Feldprojektion gibt die "ID" (id) des Zuordnungskriteriums an, das in der Ergebniszeile als Original gewertet wird.
  
  

• Die dritte Feldprojektion soll die alternative "ID" (alias.id) eines identifizierten "Duplikats" mit demselben Namen angeben. Die Duplikatsuche stützt sich hier auf einen Datenobjekt Join mit dem Join Alias alias.
  
  

  • Man könnte den Datenobjekt Join als "SELF JOIN" bezeichnen, da er sich im Parameter Datenobjekt auf denselben Entitätstyp bezieht, den die Suche selbst adressiert (hier: Zuordnungskriterium).

• • Der Join Typ "Inner" stellt in Verbindung mit der abgewählten Optional-Option sicher, dass im Ergebnis nur Zeilen ausgegeben werden, für die der alias einen Wert beisteuert.
    
    

  • Die Join Bedingung (Details s. unten) soll sicherstellen, dass der Join jedem Zuordnungskriterium alle anderen Zuordnungskriterien zuordnet, für die derselbe "Name" (name) angegeben ist.

Der Screenshot rechts zeigt die Join Bedingung, die das Kriterium für für die Zuordnung von Duplikaten als Such-Verknüpfung, mit einer UND-Verknüpfung aus zwei Instanzen der Feld Einschränkung abbildet:

• Die erste Feld Einschränkung stellt sicher, dass ein Abgleich für das Feld "ID" (id vs. alias.id) keine Übereinstimmung (!=) ergibt. Sonst würde der SELF JOIN jedes Zuordnungskriterium als Duplikat von sich selbst ausweisen.
  
  

• Die zweite Feld Einschränkung stellt sicher, dass das Feld "Name" (name vs. alias.name) übereinstimmt.

Nur wenn beide Bedingungen erfüllt sind soll der alias-Datensatz dem übergeordneten Datensatz zugeordnet werden.

►WICHTIG◄ Soweit die Suche in einem Kontext ausgeführt wird, in dem Zugriffsbeschränkungen für das Lesen (="Suchen") von Zuordnungskriterien anwendbar sind, ist zu berücksichtigen, dass diese nur die Hauptebene der Suche (also die "linke" Seite des Joins) betreffen. Der Abgleich erfolgt also nicht nach dem Schema "alle Zuordnungskriterien" vs. "alle (anderen) Zuordnungskriterien". Vielmehr wird nur geprüft, ob es für alle lesbaren Zuordnungskriterien irgendwelche Duplikate (alias) hinsichtlich des Namens gibt. Da für die alias-Seite des Vergleichs ("rechts" im Join) keine Zugriffseinschränkungen berücksichtigt werden, weist die Suche ggf. auch Duplikate aus, die "nicht lesbare" Zuordnungskriterien betreffen.