Entitätenmengen (EDM)

Im Entitätsdatenmodell (EDM) ist ein EntitySet ein logischer Container für Entitäten eines einzelnen Typs. In gleicher Weise stellt ein AssociationSet einen Container für Zuordnungen desselben Typs dar. In Schemas definierte Entitätenmengen und Zuordnungssätze werden Tabellen in der Datenbank zugeordnet, in denen die Daten für Anwendungen gespeichert werden. Entitätenmengen und Zuordnungssätze bilden die Grundlage für Klassen im Objektmodell, das zum Programmieren des Anwendungscodes verwendet wird.

Entitätenmengen und Zuordnungssätze definieren den Bereich von Entitäten und Zuordnungen. Entitätencontainer definieren die Speichercontainer, die Entitäten und Zuordnungen enthalten. Es gibt keine Sätze von SimpleType. Diese Typen werden als Werte instanziiert, die den Eigenschaften einer Entität zugewiesen sind.

Ein EntitySet für einen EntityType enthält die Instanzen des EntityType oder eines zugehörigen Untertyps. Es kann mehr als ein EntitySet definiert werden, wenn derselbe EntityType verwendet wird. Die Instanz eines EntityType kann nur ein Member von genau einem EntitySet sein.

Entitätsinstanzen in einem EntitySet müssen drei Bedingungen erfüllen:

  • Der Typ einer Entitätsinstanz ist entweder der EntityType des EntitySet oder ein Untertyp des EntityType.

  • Der Key-Wert der jeweiligen Entitätsinstanz dient zur eindeutigen Kennzeichnung innerhalb des EntitySet.

  • Die Entitätsinstanz ist kein Member eines anderen EntitySet.

Die folgende CSDL-Syntax (konzeptionelle Schemadefinitionssprache) ist die Deklaration eines EntitySet mit dem Namen CustomerSet. Das EntitySet enthält Instanzen der Entität CustomerType:

<EntitySet Name="CustomerSet" EntityType="CustomerType"/>

Im folgenden Schemasegment definieren zwei EntityType-Deklarationen die Entitätstypen Product und Supplier. Die auf den Entitäten Product und Supplier basierenden Entitätenmengen werden den jeweiligen Pluralformen entsprechend benannt: Products und Suppliers. Diese Entitätenmengen werden der Definition eines EntityContainer hinzugefügt.

<?xml version="1.0" encoding="utf-8"?>
<Schema xmlns:cg="https://schemas.microsoft.com/ado/2006/04/codegeneration"
    xmlns:edm="https://schemas.microsoft.com/ado/2006/04/edm"
    xmlns="https://schemas.microsoft.com/ado/2006/04/edm"
    Namespace="MyCompany.LOBSchema" Alias="Self">

<EntityType Name="Product">
    <Key>
      <PropertyRef Name="ProductID" />
    </Key>
    <Property Name="ProductID" Type="Int32" Nullable="false" />
    <Property Name="ProductName" Type="String" Nullable="false" />
    <Property Name="UnitPrice" Type="Decimal" Nullable="true" />
    <Property Name="UnitsInStock" Type="Int16" Nullable="true" />
</EntityType>

<EntityType Name="Supplier">
    <Key>
      <PropertyRef Name="SupplierID" />
    </Key>
    <Property Name="SupplierID" Type="Int32" Nullable="false" />
    <Property Name="CompanyName" Type="String" Nullable="false" />
    <Property Name="ContactName" Type="String" Nullable="true" />
    <Property Name="HomePage" Type="String" Nullable="true" />
</EntityType>

<EntityContainer Name="LOB-Data">
    <EntitySet Name="Products" EntityType="Product" />
    <EntitySet Name="Suppliers" EntityType="Supplier" />
</EntityContainer>

</Schema>

Weitere Informationen über Entitätencontainer finden Sie unter Entitätencontainer (EDM) .

Mehrere Entitätenmengen pro Typ

Mit dem Entity Data Model (EDM) lassen sich Entitätenmengen innerhalb eines oder mehrerer Entitätencontainer für denselben Entitätstyp definieren. Das Definieren mehrerer Entitätenmengen pro Typ (Multiple Entity Sets per Type, MEST) ermöglicht die Optimierung des Codes, wenn Datenbanken Partitionierungen aufweisen oder in vergleichbaren Szenarios, in denen mehrere Tabellen über dieselbe Struktur verfügen.

Datenbanken können partitioniert werden, um beispielsweise die Leistung, die Verfügbarkeit oder die Verwaltbarkeit zu verbessern. Ein Finanzinstitut, das Konten für eine große Kundenzahl verwaltet, kann seine Datenbanksysteme z. B. durch eine regionale Verteilung der Kundendaten partitionieren, um die Leistung zu erhöhen. Das Durchsuchen und Aktualisieren der Daten nimmt weniger Zeit in Anspruch, wenn die Daten auf eine regionale Teilmenge beschränkt sind. Für die Implementierung von MEST muss das Partitionierungsszenario innerhalb derselben Datenbank stattfinden. Wenn die Partitionierung mehrere Datenbanken enthält, sind anstelle eines MEST-Szenarios verschiedene Verbindungszeichenfolgen und Kontexte erforderlich.

Ein anderes Szenario, in dem Partitionierung sinnvoll sein kann, wäre beispielsweise eine IT-Abteilung, die häufig verwendete Daten nachts sichern möchte, wobei Daten, auf die seit mehr als einem Jahr nicht zugegriffen wurde, archiviert werden sollen. Die Datenbankadministratoren können Kunden, die ihre Kontodaten seit über einem Jahr nicht verwendet haben, in einer entsprechenden Tabelle innerhalb derselben Datenbank mit demselben Tabellenschema archivieren.

Es ist wichtig, die Strukturen von Zuordnungen zwischen Entitätstypen zu beachten, die Member von mehreren Entitätenmengen sind. Die einfachste Weise, MEST zu implementieren, ist, dies entsprechend einer bereits getesteten Struktur auszuführen. Die folgenden Szenarios wurden erfolgreich eingesetzt.

  • Bei einer 1:n-Zuordnung sollte eine Entität, die an dem "einfachen" Ende der Zuordnung als MEST implementiert wurde, am "vielfachen" Ende mit zwei verschiedenen Entitätenmengen in Beziehung stehen. Beispielsweise kann das folgende Szenario mit dem Customer-Entitätstyp in zwei Entitätenmengen implementiert werden: PreferedCustomers und CreditRiskCustomers.

    • PreferedCustomers <1-----*> Orders

    • CreditRiskCustomers <1-----*> CreditReports

  • Bei einer 1:n-Zuordnung kann eine Entitätenmenge am "einfachen" Ende einer am "vielfachen" Ende als MEST implementierten Entität zugeordnet sein. Beispielsweise kann die Product-Entität in zwei Entitätenmengen und in Zuordnungen mit der ManufacturingUnit-Entität enthalten sein.

    • ManufacturingUnit <1-----*> Products

    • ManufacturingUnit <1----*> DefectiveProducts

MEST ist in einem "1:1"- oder "m:n"-Szenario schwierig zu implementieren, wenn das logische Modell entworfen wird und/oder wenn das logische Modell dem konzeptionellen Modell zugeordnet wird. Mit MEST tritt in einem "1:1"- oder "m:n"-Szenario das gleiche Problem auf wie in dem Fall, dass MEST an dem "einfachen" Ende in Beziehung zur selben Entität am "vielfachen" Ende steht. Mit 1:1 ist es möglich, ein logisches Modell zu erstellen, das den Fällen für 1:n ähnelt.

  • Im folgenden Auftragsszenario treten beim Entwerfen des logischen Modells Probleme auf.

    • PreferedCustomers <1-----*> Orders

    • CreditRiskCustomers <1-----*> Orders

Weitere Informationen finden Sie unter Gewusst wie: Definieren eines Modells mit mehreren Entitätenmengen pro Typ (Entity Framework) .

Siehe auch

Konzepte

Zuordnung (EDM)
Zuordnungssätze (EDM)
Entitätencontainer (EDM)
Entity Data Model-Typen
Einfache Typen (EDM)

Weitere Ressourcen

Schemas und Mappingspezifikation (Entity Framework)