QueryView-Element (EntitySetMapping)

Im Entitätsdatenmodell (EDM) definiert das QueryView-Element in einem EntitySetMapping ein schreibgeschütztes Mapping zwischen einer Entität im konzeptionellen Modell und einer Entität im Speichermodell. Dieses Mapping der Abfragesicht wird mithilfe einer Entity SQL-Abfrage definiert, die im Speichermodell ausgewertet wird. Der Ergebnissatz wird als Entität im konzeptionellen Modell ausgedrückt. Da Abfragesichten schreibgeschützt sind, können die durch Abfragesichten definierten Typen nicht mit herkömmlichen Aktualisierungsbefehlen aktualisiert werden. Diese Typen können mithilfe von Änderungsfunktionen aktualisiert werden. Weitere Informationen finden Sie unter Gewusst wie: Zuordnen von Änderungsfunktionen zu gespeicherten Prozeduren.

Sie können Abfragesichten definieren, um die folgenden Szenarien zu ermöglichen:

• Definieren einer Entität im konzeptionellen Modell, die nicht alle Eigenschaften der Entität im Speichermodell einschließt. Dies schließt Eigenschaften ein, die keine Standardwerte haben und keine null-Werte unterstützen.

• Zuordnen von berechneten Spalten im Speichermodell zu Eigenschaften von Entitätstypen im konzeptionellen Modell.

• Definieren eines Mappings, bei dem die Bedingungen, die für die Partitionierung von Entitäten im konzeptionellen Modell verwendet werden, nicht auf Gleichheit basieren. Wenn Sie ein bedingtes Mapping mithilfe des Condition-Elements festlegen, muss die angegebene Bedingung gleich dem angegebenen Wert sein. Weitere Informationen finden Sie unter Condition-Element (MappingFragment).

• Zuordnen derselben Spalte im Speichermodell zu mehreren Typen im konzeptionellen Modell.

• Zuordnen mehrerer Typen zu derselben Tabelle.

• Definieren von Zuordnungen im konzeptionellen Modell, die nicht auf Fremdschlüsseln im relationalen Schema basieren.

• Verwenden benutzerdefinierter Geschäftslogik, um die Werte von Eigenschaften im konzeptionellen Modell festzulegen. Sie können beispielsweise den Zeichenfolgenwert "T" in der Datenquelle einem booleschen Wert true im konzeptionellen Modell zuordnen.

• Definieren bedingter Filter für Abfrageergebnisse.

• Erzwingen von geringeren Dateneinschränkungen im konzeptionellen Modell als im Speichermodell. Sie können beispielsweise für eine Eigenschaft im konzeptionellen Modell festlegen, dass sie NULL-Werte annehmen kann, auch wenn die zugeordnete Spalte null-Werte nicht unterstützt.

Die folgenden Aspekte gelten, wenn Sie Abfragesichten für Entitäten definieren:

• Abfragesichten sind schreibgeschützt. Sie können Entitäten nur mit Änderungsfunktionen aktualisieren.

• Wenn Sie eine Entität durch eine Abfragesicht definieren, müssen Sie auch alle verknüpften Entitäten durch Abfragesichten definieren.

• Wenn Sie eine m:n-Zuordnung einer Entität im Speichermodell zuordnen, die eine Linktabelle im relationalen Schema darstellt, müssen Sie ein QueryView-Element im AssociationSetMapping-Element für diese Linktabelle definieren. Weitere Informationen finden Sie unter QueryView-Element (AssociationSetMapping).

• Abfragesichten müssen für alle Typen in einer Typhierarchie definiert werden. Dazu stehen Ihnen folgende Möglichkeiten zur Verfügung:

  • Mit einem einzelnen QueryView-Element, das eine einzelne Entity SQL-Abfrage angibt, die eine Union aller Entitätstypen in der Hierarchie zurückgibt.

  • Mit einem einzelnen QueryView-Element, das eine einzelne Entity SQL-Abfrage angibt, die den CASE-Operator verwendet, um einen speziellen Entitätstyp in der Hierarchie auf Basis einer bestimmten Bedingung zurückzugeben.

  • Mit einem zusätzlichen QueryView-Element für einen bestimmten Typ in der Hierarchie. Verwenden Sie in diesem Fall das TypeName-Attribut des QueryView-Elements, um den Entitätstyp für jede Sicht anzugeben.

• Wenn eine Abfragesicht definiert ist, kann das StorageSetName-Attribut für das EntitySetMapping-Element nicht angegeben werden.

• Wenn eine Abfragesicht definiert ist, kann das EntitySetMapping-Element nicht gleichzeitig Property-Mappings enthalten.

Im folgenden Beispiel wird eine Abfragesicht für den Product-Entitätstyp im "AdventureWorks Sales"-Modell definiert.

<EntitySetMapping Name="Product">
  <QueryView>
      SELECT VALUE AdventureWorksModel.Product(P.ProductID,
      P.Name, P.ProductNumber, P.Color, P.ListPrice, P.Size, P.Weight,
      P.Style)
      FROM Person.Product as P
  </QueryView>
</EntitySetMapping>

Da die Abfrage nur eine Untermenge der Mitglieder des Product-Typs im Speichermodell zurückgibt, wurde der Product-Typ im "AdventureWorks Sales"-Modell auf der Basis dieses Mappings wie folgt geändert:

  <EntityType Name="Product">
  <Key>
    <PropertyRef Name="ProductID" />
  </Key>
  <Property Name="ProductID" Type="Int32" Nullable="false" />
  <Property Name="Name" Type="String" Nullable="false" MaxLength="50" Unicode="true" FixedLength="false" />
  <Property Name="ProductNumber" Type="String" Nullable="false" MaxLength="25" Unicode="true" FixedLength="false" />
  <Property Name="Color" Type="String" MaxLength="15" Unicode="true" FixedLength="false" />
  <Property Name="ListPrice" Type="Decimal" Nullable="false" Precision="19" Scale="4" />
  <Property Name="Size" Type="String" MaxLength="5" Unicode="true" FixedLength="false" />
  <Property Name="Weight" Type="Decimal" Precision="8" Scale="2" />
  <Property Name="Style" Type="String" MaxLength="2" Unicode="true" FixedLength="true" />
</EntityType>

Der Product-Typ im Speichermodell des Beispiels zum "AdventureWorks Sales"-Modell wurde für dieses Beispiel nicht geändert.

Siehe auch

Konzepte

Entity Data Model-Mappingszenarios (Anwendungsszenarios)
EntitySetMapping-Element (MSL)