Freigeben über

Tabellen mithilfe von FetchXml verknüpfen

  • Artikel

Wie in Daten mithilfe von FetchXml abfragen beschrieben, beginnen Sie Ihre Abfrage, indem Sie eine Tabelle mit dem Entitätselement auswählen.

Verwenden Sie das Link-Entitätselement, um die Daten aus verwandten Tabellen zu beschreiben, die mit Ihrer Abfrage mit den folgenden Attributen zurückgegeben werden sollen:

Attribute Kurzbeschreibung Weitere Details finden Sie in der Link-Entitäts-Elementreferenz
name Der logische Name der Bezugstabelle.
from Der logische Name der Spalte aus der zugehörigen Tabelle, die mit der in der im to-Attribut angegebenen Spalte übereinstimmt.
to Der logische Name der Spalte im übergeordneten Element, das mit der zugehörigen Tabelle abgeglichen wird, die im from-Attribut angegebenen ist.
link-type Der Typ der Linkverwendung. Das Standardverhalten ist inner, wodurch die Ergebnisse auf Zeilen mit übereinstimmenden Werten in beiden Tabellen beschränkt werden.
Andere gültige Werte sind:
- outer
- any
- not any
- all
- not all
- exists
- in
- matchfirstrowusingcrossapply
Erfahren Sie mehr über die Optionen für Linktypen
alias Stellt den Namen der zugehörigen Tabelle in den Ergebnissen dar.
intersect Gibt an, dass die link-entity zum Verknüpfen von Tabellen verwendet wird und keine Spalten zurückgibt

Die folgende Abfrage gibt beispielsweise bis zu 5 Datensätze aus den Tabellen Konto und Kontakt basierend auf der PrimaryContactId-Suchspalte im Kontodatensatz zurück:

<fetch top='5'>
   <entity name='account'>
      <attribute name='name' />
      <link-entity name='contact'
         from='contactid'
         to='primarycontactid'
         link-type='inner'
         alias='contact'>
         <attribute name='fullname' />
      </link-entity>
   </entity>
</fetch>

Die Ergebnisse sehen folgendermaßen aus:

 -----------------------------------------------------------------
 | name                             | contact.fullname           |
 -----------------------------------------------------------------
 | Litware, Inc. (sample)           | Susanna Stubberod (sample) |
 -----------------------------------------------------------------
 | Adventure Works (sample)         | Nancy Anderson (sample)    |
 -----------------------------------------------------------------
 | Fabrikam, Inc. (sample)          | Maria Campbell (sample)    |
 -----------------------------------------------------------------
 | Blue Yonder Airlines (sample)    | Sidney Higa (sample)       |
 -----------------------------------------------------------------
 | City Power & Light (sample)      | Scott Konersmann (sample)  |
 -----------------------------------------------------------------

Einschränkungen

Sie können einer Abfrage bis zu 15 link-entity-Elemente hinzufügen. Jede Link-Entität fügt der Abfrage einen JOIN hinzu und erhöht die Zeit zum Ausführen der Abfrage. Dieser Grenzwert dient dem Schutz der Leistung. Wenn Sie einer Abfrage mehr als 15 Link-Entitätselemente hinzufügen, erhalten Sie diese Fehlermeldung:

Code: 0x8004430D
Nummer: -2147204339
Meldung: Number of link entities in query exceeded maximum limit.

Untergeordnete Elemente

Innerhalb des link-entity-Elements können Sie untergeordnete Elemente genau wie beim übergeordneten Element hinzufügen, um:

n:1-Beziehungen

Das vorherige Beispiel ist eine n:1-Beziehung, bei der viele Kontodatensätze auf einen einzigen Kontaktdatensatz verweisen können. Diese Informationen werden in der n:1-Beziehung Konto „account_primary_contact“ n:1-Beziehung definiert, die die folgenden Werte hat:

Eigenschaften Wert Kommentieren
SchemaName account_primary_contact Eindeutiger Name der Beziehung.
ReferencedEntity contact Die Tabelle, auf die verwiesen wurde. Die 1 in der n:1-Beziehung.
ReferencedAttribute contactid Das primäre Schlüssel der referenzierten Tabelle.
ReferencingEntity account Die Tabelle mit einer Suchspalte, die auf die andere Tabelle verweist. Das n in der n:1-Beziehung.
ReferencingAttribute primarycontactid Der Name der Suchspalte.
RelationshipType OneToManyRelationship Eine 1:n-Beziehung, wenn sie aus der referenzierten Tabelle (1) betrachtet wird.
Eine n:1-Beziehung, wenn sie aus der referenzierten Tabelle (n) betrachtet wird

Beziehungsinformationen abrufen

Wenn Sie den XrmToolBox FetchXML Builder verwenden, können Sie sehen, wie Sie mit diesem Tool die Beziehung auswählen können, um die entsprechenden name, from und to Attributwerte festzulegen.

Sie können auch andere Tools und APIs verwenden, um Beziehungsdaten für die entsprechenden zu verwendenden name-, from- und to-Attributwerte zu suchen. Informationen zum Abrufen dieser Daten:

Eins-zu-viele-Beziehungen

n:1- und 1:n-Beziehungen sind wie zwei Seiten einer Medaille. Die Beziehung besteht zwischen den Tabellen. Die Art und Weise, wie Sie sie verwenden, hängt also davon ab, welche Tabelle die Basistabelle für Ihre Abfrage ist.

Sie können dieselben Daten wie im vorherigen Beispiel aus der Kontakttabelle mithilfe derselben Beziehung abrufen, außer von der Seite der Kontakttabelle. Verwenden Sie die Daten aus derselben Kontakt account_primary_contact 1:n-Beziehung, passen Sie die Werte jedoch für die unterschiedliche Ansicht der Beziehung an.

<fetch top='5'>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         alias='account'>
         <attribute name='name' />
      </link-entity>
   </entity>
</fetch>

Die folgende Tabelle zeigt die Link-Entität-Attributwerte in diesem Beispiel:

Attribute Wert Eigenschaft
name account Der logische Name der referenzierten Tabelle.
from primarycontactid Der Name der Suchspalte in der referenzierten Kontotabelle
to contactid Das primäre Schlüssel der referenzierten Kontakttabelle
alias account Für link-entity wird ein Wert mit einer 1:n-Beziehung empfohlen. Wenn kein Alias angegeben wird, wird ein Standardalias generiert. Wenn in diesem Beispiel kein Alias angegeben wird, werden die Daten mit einer Spalte namens account1.name zurückgegeben.
link-type Nicht festgelegt Wenn kein Wert festgelegt ist, wird standardmäßig inner verwendet

Die Ergebnisse umfassen dieselben Datensätze und Daten wie die vorherige Abfrage unter Verwendung der n:1-Beziehung, mit der Ausnahme, dass die übergeordnete Entität jetzt contact ist statt account.

 -----------------------------------------------------------------
 | fullname                   | account.name                     |
 -----------------------------------------------------------------
 | Susanna Stubberod (sample) | Litware, Inc. (sample)           |
 -----------------------------------------------------------------
 | Nancy Anderson (sample)    | Adventure Works (sample)         |
 -----------------------------------------------------------------
 | Maria Campbell (sample)    | Fabrikam, Inc. (sample)          |
 -----------------------------------------------------------------
 | Sidney Higa (sample)       | Blue Yonder Airlines (sample)    |
 -----------------------------------------------------------------
 | Scott Konersmann (sample)  | City Power & Light (sample)      |
 -----------------------------------------------------------------

Viele-zu-viele-Beziehungen

n:n-Beziehungen hängen von einer Überschneidungstabelle ab. Eine Überschneidungstabelle hat normalerweise nur vier Spalten, von denen jedoch nur zwei wichtig sind. Die beiden wichtigen Spalten stimmen mit den Primärschlüsselspalten der teilnehmenden Tabellen überein.

Beispielsweise unterstützt die TeamMembership-Überschneidungstabelle die teammembership_association n:n-Beziehung zwischen SystemUser- und Team-Tabellen. Es ermöglicht Benutzenden, mehreren Teams beizutreten, und Teams können mehrere Benutzende haben. TeamMembership hat diese Spalten: systemuserid, teamid.

Wenn Sie Informationen über Benutzende und die Teams, denen sie angehören, mithilfe der n:n-Beziehung von teammembership_association abrufen möchten, können Sie diese fetchXML-Abfrage verwenden:

<fetch top='2'>
   <entity name='systemuser'>
      <attribute name='fullname' />
      <link-entity name='teammembership'
         from='systemuserid'
         to='systemuserid'
         intersect='true' >
         <link-entity name='team'
            from='teamid'
            to='teamid'
            link-type='inner'
            alias='team'>
            <attribute name='name' />
         </link-entity>
      </link-entity>
   </entity>
</fetch>

Es gibt zwei verschachtelte Link-Entitäten.

  • Die erste verbindet systemuser mit der teammembership-Überschneidungstabelle, in der systemuserid = systemuserid.
  • Die zweite verbindet die teammembership-Überschneidungstabelle mit dem Team, wobei teamid = teamid.

Die Ergebnisse sollten in etwa so aussehen:

 --------------------------------------
 | fullname             | team.name   |
 --------------------------------------
 | FirstName LastName   | org26ed931d |
 --------------------------------------
 | # PpdfCDSClient      | org26ed931d |
 --------------------------------------

Keine Beziehung

Es ist möglich, from- und to-Attribute mithilfe von Spalten anzugeben, die nicht Teil einer definierten Beziehung sind.

Diese Abfrage findet beispielsweise Datensatzpaare, bei denen die Spalte „Name“ eines Konto-Datensatzes der Spalte „FullName“ eines Kontakt-Datensatzes entspricht, unabhängig davon, ob sie in einer der Suchspalten aufeinander verweisen.

<fetch>
   <entity name='account'>
     <attribute name='name' />
     <link-entity name='contact'
       from='fullname'
       to='name'
       link-type='inner'
       alias='contact'>
       <attribute name='fullname' />
     </link-entity>
   </entity>
 </fetch>

Hinweis

Es ist wichtig, dass die in den from- und to-Attributen angegebenen Spalten vom gleichen Typ sind, auch wenn sie nicht an einer Beziehung beteiligt sind. Die Verwendung von Spalten unterschiedlichen Typs erfordert eine Typkonvertierung, die Auswirkungen auf die Leistung haben und bei einigen Spaltenwerten fehlschlagen kann.

Die folgenden Spaltentypen können nicht in from- und to-Attributen verwendet werden:

  • Datei
  • Image
  • Feld „MultiSelect“
  • PartyList

Einige Spalten können in from- und to-Attributen verwendet werden, dies kann aber zu schlechter Leistung führen:

  • Spalten des Mehrere Textzeilen-Typs
  • Spalten des Einzelne Textzeile-Typs mit einer maximalen Länge größer als 850
  • Formel-Spalten
  • Berechnete Spalten
  • Logische Spalten

Nach Datensätzen suchen, die nicht in einem Satz enthalten sind

Mithilfe von FetchXml können Sie eine Abfrage erstellen, um Datensätze zurückzugeben, die nicht in einem Satz enthalten sind, der linke äußere Verknüpfung nutzt. Eine linke äußere Verknüpfung gibt jede Zeile zurück, die der Verknüpfung der ersten Eingabe mit der zweiten Eingabe entspricht. Es werden auch alle Zeilen aus der ersten Eingabe zurückgegeben, die in der zweiten Eingabe keine Übereinstimmung haben. Die nicht übereinstimmenden Zeilen in der zweiten Eingabe werden als Nullwerte zurückgegeben.

Sie können einen linken äußeren Join durchführen, FetchXML indem Sie das entityname Attribut in einem Bedingungselement verwenden. Das Attribut entityname ist auch für die Bedingungen, Filter und geschachtelte Filter gültig. Erfahren Sie mehr über Filter für die Entität „Link“.

Beispielsweise gibt die folgende Abfrage alle Kontaktdatensätze ohne Kontakte zurück.

<fetch>
   <entity name='account'>
      <attribute name='name' />
      <order attribute='name' />
      <link-entity name='contact'
         from='parentcustomerid'
         to='accountid'
         link-type='outer'
         alias='contact' />
      <filter type='and'>
         <condition entityname='contact'
            attribute='parentcustomerid'
            operator='null' />
      </filter>
   </entity>
</fetch>

Die folgenden Link-Entitätstypen entsprechen nicht direkt T-SQL JOIN-Operator-Typen und verwenden stattdessen Unterabfragen. Diese Typen bieten erweiterte Funktionen, mit denen Sie die Abfrageleistung verbessern und komplexere Abfragen definieren können.

Name des Dataflows Eigenschaft
exists Eine Variante von inner kann Leistungsvorteile bieten. Verwendet eine VORHANDEN-Bedingung in der where-Klausel. Verwenden Sie diese Option, wenn in den Ergebnissen nicht mehrere Kopien der übergeordneten Zeile erforderlich sind. Weitere Informationen über „Vorhanden” und „In”
in Eine Variante von inner kann Leistungsvorteile bieten. Verwendet eine IN-Bedingung in der where-Klausel. Verwenden Sie diese Option, wenn in den Ergebnissen nicht mehrere Kopien der übergeordneten Zeile erforderlich sind. Weitere Informationen über „Vorhanden” und „In”
matchfirstrowusingcrossapply Eine Variante von inner kann Leistungsvorteile bieten. Verwenden Sie diesen Typ, wenn nur ein einziges Beispiel einer übereinstimmenden Zeile aus der verknüpften Entität ausreicht und mehrere Kopien der übergeordneten Zeile in den Ergebnissen nicht erforderlich sind. Weitere Informationen über „matchfirstrowusingcrossapply“

exists und in sind Varianten von inner, die unterschiedliche Bedingungen (jeweils EXISTIERT und IN) in der where-Klausel verwenden, damit nicht mehrere Kopien der übergeordneten Zeile in den Ergebnissen zurückgegeben werden. Keiner dieser Typen gibt die Spaltenwerte der Link-Entitätszeilen zurück.

exists

Diese FetchXml- und SQL-Beispiele zeigen die mit exists angewendeten Muster.

<fetch>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         link-type='exists'>
         <filter type='and'>
            <condition attribute='statecode'
               operator='eq'
               value='1' />
         </filter>
      </link-entity>
   </entity>
</fetch>

in

Diese FetchXml- und SQL-Beispiele zeigen die mit in angewendeten Muster.

<fetch>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         link-type='in'>
         <filter type='and'>
            <condition attribute='statecode'
               operator='eq'
               value='1' />
         </filter>
      </link-entity>
   </entity>
</fetch>

Durch die Verwendung der Linktypen exists oder in kann die Größe von Zwischen- oder Endabfrageergebnissen verringert werden, insbesondere wenn viele übereinstimmende verknüpfte Zeilen für dieselben übergeordneten Zeilen vorhanden sind oder wenn mehrere Linkentitäten mit dem gleichen übergeordneten Element verwendet werden. Die Verwendung der Linktypen exists oder in kann die Leistung der Abfrage im Vergleich zum Typ inner verbessern, da kein kartesisches Produkt zurückgegeben werden muss, das alle möglichen Permutationen von Zeilen aus verschiedenen verknüpften Entitäten für jede übergeordnete Zeile enthält.

Diese Linktypen ermöglichen es möglicherweise auch Dataverse, nur die erste übereinstimmende verknüpfte Entitätszeile für jede übergeordnete Zeile zu finden, was effizienter ist als alle übereinstimmenden Zeilen in der verknüpften Entität in einer inner-Verknüpfung zu finden.

Dieser Linktyp erzeugt einen ÜBERGREIFEND ABGLEICHEN-Operator mit einer Unterabfrage mithilfe von top 1, die diesem Muster folgen:

<fetch>
   <entity name='contact'>
      <attribute name='fullname' />
      <link-entity name='account'
         from='primarycontactid'
         to='contactid'
         link-type='matchfirstrowusingcrossapply'>
         <attribute name='accountid' />
         <attribute name='name' />
      </link-entity>
   </entity>
</fetch>

Der matchfirstrowusingcrossapply-Linktyp entspricht dem Typ inner, außer dass die übergeordnete Zeile höchstens einmal zurückgegeben wird. Die übergeordnete Zeile wird nur zurückgegeben, wenn es übereinstimmende Zeilen in der verknüpften Entität gibt, aber im Gegensatz zu den Typen in und exists gibt es bei der Übereinstimmung von Zeilen Spaltenwerte aus einer der übereinstimmenden Zeilen in der verknüpften Entität zurück. Verwenden Sie dies, wenn nur ein einziges Beispiel einer übereinstimmenden Zeile aus der verknüpften Entität ausreicht und mehrere Kopien der übergeordneten Zeile in den Ergebnissen nicht erforderlich sind.

Bei Verwendung des Linktyps matchfirstrowusingcrossapply unterscheiden sich die Namen der Eigenschaften, die über die Web-API zurückgegeben werden, oder die Werte der SDK Entity.Attributes-Sammlung Keys für die zugehörigen Tabellenspalten von anderen Arten von Verknüpfungen. Normalerweise folgen diese dem Format <tablealias>.<logicalname>. Für den Linktyp matchfirstrowusingcrossapply werden jedoch die Werte SchemaName ohne das Tabellenalias-Präfix verwendet.

Wenn Sie das vorherige Abfragebeispiel mit einem anderen Linktyp verwenden, können Sie davon ausgehen, dass die Eigenschaften oder Schlüssel die folgenden Namen haben:

  • fullname
  • contactid
  • account1.accountid
  • account1.name

Aber mit dem Linktyp matchfirstrowusingcrossapply haben die Eigenschaften oder Schlüssel diese Namen:

  • fullname
  • contactid
  • AccountId
  • Name

Nächste Schritte,

Erfahren Sie, wie Sie Zeilen anordnen.

Bestellzeilen

Hinweis

Können Sie uns Ihre Präferenzen für die Dokumentationssprache mitteilen? Nehmen Sie an einer kurzen Umfrage teil. (Beachten Sie, dass diese Umfrage auf Englisch ist.)

Die Umfrage dauert etwa sieben Minuten. Es werden keine personenbezogenen Daten erhoben. (Datenschutzbestimmungen).