Listenverknüpfungen und Projektionen

Letzte Änderung: Montag, 2. August 2010

Gilt für: SharePoint Foundation 2010

Inhalt dieses Artikels
Verknüpfungen und Projektionen in Listenansichten
Verknüpfungen und Projektionen in Abfragen
Implizite Verknüpfungen ohne ein "Joins"-Element

In diesem Thema wird die Verwendung von Listenverknüpfungen und Feldprojektionen in Collaborative Application Markup Language (CAML)-definierten Ansichten und Abfragen erläutert.

Verknüpfungen und Projektionen in Listenansichten

Eine Listenansicht kann Felder aus anderen Listen enthalten, die mit der primären Liste verknüpft wurden. Das CAML-Element View implementiert diese Funktionalität mithilfe seiner untergeordneten Elemente Joins und ProjectedFields, die im Objektmodell durch die Eigenschaften Joins und ProjectedFields des SPView-Objekts dargestellt werden. (Das SPQuery-Objekt besitzt Eigenschaften mit denselben Namen. Weitere Informationen finden Sie unter Verknüpfungen und Projektionen in Abfragen.)

Listenverknüpfungen in Ansichten

Das Joins-Element enthält mindestens ein Join-Element. Jedes dieser Elemente erstellt eine innere Verknüpfung oder linke äußere Verknüpfung zwischen zwei Listen. Mindestens eine dieser Verknüpfungen muss von der übergeordneten Liste der Ansicht stammen, die als primäre Liste bezeichnet wird, und von einer anderen Liste, die als fremde Liste bezeichnet wird. Es können jedoch weitere Verknüpfungen von dieser fremden Liste zu anderen fremden Listen vorhanden sein usw. Die Anzahl der Verknüpfungen in einer Verknüpfungskette ist nicht begrenzt, die Summe der Join-Elemente, in Ketten oder nicht, darf jedoch den Wert der MaxQueryLookupFields-Eigenschaft für das SPWebApplication-Objekt nicht übersteigen, das die primäre Liste enthält. Der Systemstandardwert ist 8. Eine Liste kann direkt mit sich selbst verknüpft sein oder über eine Kette von Verknüpfungen.

Wichtig

Beim Erstellen von Listenverknüpfungen müssen einige Anforderungen beachtet werden. Es können nicht zwei beliebige Listen verknüpft werden, ohne deren Typ zu berücksichtigen. Und wenn zwei Listen verknüpft werden können, kann nicht jedes beliebige primäre und fremde Feld als das "Verknüpfung über"-Paar von Feldern verwendet werden. Das Feld in der primären Liste muss ein Nachschlagefeld sein und es muss im Feld der fremden Liste nachschlagen. Aus diesem Grund spiegeln alle Verknüpfungen vorhandene Nachschlagebeziehungen zwischen Listen wider.

Mit dem folgenden Beispielmarkup wird das Projekt einer SharePoint Foundation-Website beschrieben, das einen Club von Eltern hostet, die sich gegenseitig gebrauchte Kinderbekleidung verkaufen. Die Orders-Liste, in der die Stadt und das Land des Käufers (Kunden) und die Stadt des Verkäufers (Lieferanten) enthalten sind, soll in einer Ansicht angezeigt werden. Zur Implementierung dieser Ansicht sind zwei Ketten von linken äußeren Verknüpfungen vorhanden:

• Orders mit Member mit Cities mit States

• Orders mit Members mit Cities

Beachten Sie folgende Aspekte im Joins-Markup:

• Das Type-Attribut jedes Join-Elements kann LEFT oder INNER sein.

• Da zwei Verknüpfungen von Orders zu Members bestehen, müssen sie unterschieden werden. Dies wird durch das ListAlias-Attribut erleichtert, das der Members-Liste in der ersten Verknüpfung den Alias "customer" zuweist, in der zweiten Verknüpfung jedoch den Alias "shipper".

• Es gibt auch zwei Verknüpfungen von Member zu Cities, und sie werden auf dieselbe Art und Weise unterschieden.

• An keiner Stelle wird ein Listenalias explizit einer Liste zugeordnet. Eine Zuordnung ist nicht erforderlich, da von jeder Verknüpfung eine vorhandene Nachschlagefeldbeziehung gegenüber gestellt wird und die Definition des Nachschlagefelds die fremde Liste identifiziert.

• Die "Verknüpfung über"-Felder werden durch ein Paar von FieldRef-Elementen identifiziert. Das erste stellt das Nachschlagefeld in der primären Liste dar und identifiziert es durch seinen internen Namen. Hierzu muss ein RefType-Attribut auf ID festgelegt sein. Falls die primäre Liste der Verknüpfung nicht die übergeordnete Liste der Ansicht ist, wird diese ebenfalls durch das auf den Alias der Liste festgelegte List-Attribut identifiziert. Mit dem zweiten FieldRef-Element jedes Paars wird die fremde Liste identifiziert, wieder mithilfe des Alias, und das Fremdschlüsselfeld, bei dem es sich immer um das ID-Feld handeln muss.

<Joins>
  <Join Type='LEFT' ListAlias='customer'>
    <Eq>
      <FieldRef Name='CustomerName' RefType='Id'/>
      <FieldRef List='customer' Name='ID'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='customer_city'>
    <Eq>
      <FieldRef List='customer' Name='CityName' RefType='Id'/>
      <FieldRef List='customer_city' Name='Id'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='customer_city_state'>
    <Eq>
      <FieldRef List='customer_city' Name='StateName' RefType='Id'/>
      <FieldRef List='customer_city_state' Name='Id'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='shipper'>
    <Eq>
      <FieldRef Name='ShipperName' RefType='Id'/>
      <FieldRef List='shipper' Name='ID'/>
    </Eq>
  </Join>

  <Join Type='LEFT' ListAlias='shipper_city'>
    <Eq>
      <FieldRef List='shipper' Name='CityName' RefType='Id'/>
      <FieldRef List='shipper_city' Name='Id'/>
    </Eq>
  </Join>
</Joins>

Projektierte Felder in Ansichten

Mit dem ProjectedFields-Element werden Felder aus den fremden Listen erstellt, sodass sie in der Listenansicht verwendet werden können. Die Felder müssen dann auch im untergeordneten ViewFields-Element des View-Elements identifiziert werden.

Wenn wir beim Beispiel des Elternclubs bleiben, werden durch das folgende ProjectedFields-Element Felder für die Stadt des Kunden, das Land des Kunden und die Stadt des Lieferanten erstellt. Beachten Sie folgende Aspekte in diesem Markup:

• Die fremden Listen werden durch die Aliase identifiziert, wie es im Joins-Element definiert ist.

• Das ShowField-Attribut identifiziert, welches Feld aus der fremden Liste in der Ansicht verwendet wird.

• Das Type-Attribut besitzt immer den Wert Lookup. Daher wird vom Type-Attribut nicht der Datentyp des Felds angegeben, so wie es in der Regel im Field-Element der Fall ist. Wenn ein Field-Element ein untergeordnetes Element von ProjectedFields ist, zeigt Type nur an, ob das Join-Element (im Joins-Element, von dem das ProjectedFields-Element abhängt) auf einer vorhandenen Nachschlagebeziehung zwischen den Listen basiert. Alle Verknüpfungen müssen auf einer vorhandenen Nachschlagebeziehung basieren. Eine Liste der CAML-Feldtypen, die als projektierte Felder verwendet werden können, finden Sie weiter unten.

<ProjectedFields>
  <Field 
    Name='CustomerCity'
    Type='Lookup'
    List='customer_city'
    ShowField='Title'/>
  <Field 
    Name='CustomerCityState'
    Type='Lookup'
    List='customer_city_state'
    ShowField='Title'/>
  <Field 
    Name='ShipperCity'
    Type='Lookup'
    List='shipper_city'
    ShowField='Title'/>
</ProjectedFields>

Nur die folgenden Feldtypen können in ein ProjectedFields-Element eingeschlossen werden:

• Calculated (wie Nur-Text behandelt)

• ContentTypeId

• Counter

• Currency

• DateTime

• Guid

• Integer

• Note (nur eine Zeile)

• Number

• Text

Wie bereits zuvor erwähnt, müssen die im ProjectedFields-Element erstellten Felder im ViewFields-Element angegeben werden. Mit dem folgenden Markup wird das Beispiel fortgesetzt.

<ViewFields>
  <FieldRef Name='CustomerCity'/>
  <FieldRef Name='CustomerCityState'/>
  <FieldRef Name='ShipperCity'/>
</ViewFields>

Verknüpfungen und Projektionen in Abfragen

Verknüpfungen und projektierte Felder können auch in CAML-Abfragen verwendet werden. Auch bei dieser Verwendung sind die Verknüpfungen und projektierten Felder mit Joins- und ProjectedFields-Elementen definiert. Die Elemente sind jedoch keine untergeordneten Elemente des Query-Elements. Es handelt sich um unabhängiges XML-Markup, mit dem der Wert der SPQuery.Joins- und SPQuery.ProjectedFields-Eigenschaft des SPQuery-Objekts geformt wird, das die Abfrage darstellt.

In den meisten Fällen ist es empfehlenswert, LINQ to SharePoint-Anbieter zum Abfragen von SharePoint Foundation-Listen mit Servercode zu verwenden. Da CAML die Joins- und ProjectedFields-Elemente besitzt, können mit dem LINQ to SharePoint-Anbieter, mit dem LINQ-Abfragen in CAML-Abfragen übersetzt werden, die LINQ-Operatoren join (Join in Visual Basic) und select (Select in Visual Basic) vollständig unterstützt werden. Wenn der Code auf Clients ausgeführt werden soll, wird die Verwendung von Abfragen von SharePoint Foundation mit ADO.NET Data Services für Abfragen empfohlen.

Wenn Sie CAML-Abfragen direkt erstellen möchten und die entsprechenden Eigenschaften eines SPQuery-Objekts explizit festlegen, sollten Sie ein Tool zum Generieren der Abfragen verwenden. Sie können solche Tools finden, indem Sie zu www.bing.com navigieren und nach "CAML Query Tool" ohne Anführungszeichen suchen. Es kann nach der Veröffentlichung von Microsoft SharePoint Foundation 2010 noch einige Zeit dauern, bis die ersten Tools verfügbar sind, die die Generierung von Joins- und ProjectedFields-Elementen unterstützen.

Im folgenden Beispiel wird eine Abfrage gezeigt, die alle Bestellungen aus einer Orders-Liste zurückgibt, bei denen London als Stadt des Kunden angegeben ist. Bei dem Beispiel wird vorausgesetzt, dass die Orders-Liste ein Feld CustomerName besitzt, das in einer Customers-Liste nachschlägt, und dass die zuletzt genannte Liste ein CityName-Feld besitzt, das in einer Cities-Liste nachschlägt.

Für die Abfrage ist eine Verknüpfung von Orders zu Customers und von Customers zu Cities erforderlich, sodass der Wert der Joins-Eigenschaften wie folgt lautet:

<Joins>
  <Join Type=’LEFT’ ListAlias=’customers’>
    <Eq>
      <FieldRef Name=’CustomerName’ RefType=’Id’ />
      <FieldRef List=’customers’ Name=’ID’ />
    </Eq>
  </Join>

  <Join Type=’LEFT’ ListAlias=’customerCities’>
    <Eq>
      <FieldRef List=’customers’ Name=’CityName’ RefType=’Id’ />
      <FieldRef List=’customerCities’ Name=’ID’ />
    </Eq>
  </Join>
</Joins>

Da im Where-Abschnitt der Abfrage die Stadt des Kunden abgefragt wird, muss ein CustomerCity-Feld erstellt werden. Daher lautet der Wert von ProjectedFields wie folgt:

<ProjectedFields>
  <Field
    Name=’CustomerCity’
    Type=’Lookup’
    List=’customerCities’
    ShowField=’Title’ />
</ProjectedFields>

Als nächstes muss das Feld zur Verfügung gestellt werden, indem ein Verweis darauf dem ViewFields-Element hinzugefügt wird. Daher lautet der Wert der ViewFields-Eigenschaft wie folgt:

<ViewFields>
  <FieldRef Name='CustomerCity'/>
</ViewFields>

Schließlich wird der Wert der Query-Eigenschaft wie folgt festgelegt:

<Query>
  <Where>
    <Eq>
      <FieldRef Name='CustomerCity'/>
      <Value Type='Text'>London</Value>
    </Eq>
  </Where>
</Query>

Implizite Verknüpfungen ohne ein "Joins"-Element

Es wird die Verwendung eines expliziten Joins-Elements empfohlen, wenn die CAML-Abfrage eine Verknüpfung von Listen enthält, damit die Lesbarkeit des Markups maximiert werden kann. Dadurch wird auch die Chance maximiert, dass das Abfragemarkup mit zukünftigen Versionen von SharePoint Foundation kompatibel sein wird. Es besteht jedoch auch eine Möglichkeit, eine implizite Verknüpfung zweier Listen zu unterstützen, ohne dass ein Joins-Element verwendet wird. Sie können einfach ein ProjectedFields-Element wie oben beschrieben erstellen, das untergeordnete Field-Element muss dann jedoch ein FieldRef-Attribut an Stelle des List-Attributs besitzen. Mit dem FieldRef-Attribut wird lediglich die Nachschlagespalte in der Quellliste identifiziert. Wenn das ProjectedFields-Element ein FieldRef-Attribut an Stelle eines List-Attributs besitzt, sollte das Name-Attribut darüber hinaus einen beliebigen Wert besitzen, der nicht mit einer Spalte in der Quellliste übereinstimmt. (Wiederum ist es in diesem Markup nicht erforderlich, die Zielliste zu identifizieren, da sie in der Konfiguration der Nachschlagebeziehung angegeben ist.)

Nehmen wir beispielsweise bei denselben Listen und Nachschlagebeziehungen wie im vorherigen Abschnitt an, dass die folgende Abfrage und das folgende ViewFields-Element verwendet werden.

<Query>
  <Where>
    <Eq>
      <FieldRef Name='CustomerName'/>
      <Value Type='Text'>Hicks, Cassie</Value>
    </Eq>
  </Where>
</Query>

<ViewFields>
  <FieldRef Name='CustomerName'/>
</ViewFields>

Beachten Sie, dass das Where-Element eine implizite Verknüpfung zwischen den Listen Orders und Customers erstellt. Sie könnten diese Abfrage nur mit dem folgenden ProjectedFields-Element unterstützen. Ein Joins-Element wäre nicht erforderlich. (Beachten Sie, dass für das Name-Attribut ein beliebiger Name festgelegt wurde, der vom Namen der tatsächlichen Nachschlagespalte, der mit dem FieldRef-Attribut angegeben ist, abweicht.)

<ProjectedFields>
  <Field
    Name=’OrderingCustomer’
    Type=’Lookup’
    FieldRef=’CustomerName’
    ShowField=’Title’ />
</ProjectedFields>

Auch bei dieser Technik gilt die Anforderung, dass eine Nachschlagebeziehung zwischen der Quellspalte und der Zielliste vorhanden sein muss. Bei Verwendung dieser Technik ist darüber hinaus das Erstellen einer Verknüpfungskette nicht möglich. Sie könnten z. B. nicht das Query-Element unterstützen, das am Ende des vorherigen Abschnitts gezeigt wurde. Mit dieser Abfrage wird eine implizite doppelte Verknüpfung von Orders zu Customers zu Cities erstellt. Für eine Verknüpfungskette ist ein explizites Joins-Element erforderlich.

Siehe auch

Weitere Ressourcen

Verwalten von Daten mit LINQ to SharePoint