Share via

Set di entità (EDM)

  • Articolo

In Entity Data Model (EDM), un EntitySet è un contenitore logico per entità di un singolo tipo. Analogamente, un AssociationSet è un contenitore per associazioni dello stesso tipo. I set di entità e di associazioni definiti in schemi vengono mappati a tabelle nel database in cui sono archiviati i dati per le applicazioni. I set di entità e di associazioni costituiscono l'elemento di base delle classi nel modello a oggetti di programmazione che verrà utilizzato dal codice dell'applicazione.

I set di entità e i set di associazioni definiscono l'ambito di entità e associazioni, mentre i contenitori di entità definiscono i contenitori di archiviazione che contengono entità e associazioni. Non vi sono set di SimpleType. Di questi tipi vengono create istanze come valori assegnati alle proprietà di un'entità.

Un oggetto EntitySet per un oggetto EntityType contiene istanze dell'oggetto EntityType o uno qualsiasi dei relativi sottotipi. È possibile definire più oggetti EntitySet utilizzando lo stesso oggetto EntityType. Un'istanza di un oggetto EntityType può essere solo un membro di un oggetto EntitySet.

Le istanze dell'entità in un oggetto EntitySet devono soddisfare tre condizioni:

  • Il tipo dell'istanza dell'entità è EntityType di EntitySet o qualsiasi sottotipo di EntityType.

  • Il valore Key di ogni istanza dell'entità la identifica in modo univoco in EntitySet.

  • L'istanza dell'entità non è un membro di altri oggetti EntitySet.

La sintassi CSDL (Conceptual Schema Definition Language) seguente rappresenta la dichiarazione di un oggetto EntitySet denominato CustomerSet. EntitySet contiene istanze dell'entità CustomerType:

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

Nel segmento di schema seguente due dichiarazioni di EntityType definiscono i tipi di entità Product e Supplier. I set di entità basati su entità Product e Supplier sono denominati in modo appropriato nelle rispettive forme plurali, ovvero Products e Suppliers. Questi set di entità vengono aggiunti alla definizione di un oggetto EntityContainer.

<?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>

Per ulteriori informazioni sui contenitori di entità, vedere Contenitori di entità (EDM).

Più set di entità per tipo

Entity Data Model (EDM) consente di definire più set di entità all'interno di un singolo contenitore di entità o più contenitori di entità per lo stesso tipo di entità. La definizione di più set di entità per tipo (MEST, Multiple Entity Sets per Type) consente agli utenti di semplificare il codice quando i database sono partizionati o in altri scenari in cui più tabelle hanno la stessa struttura.

I database vengono partizionati per diversi motivi, quali prestazioni, disponibilità o gestibilità. Un'istituzione finanziaria che gestisce account per un numero elevato di clienti potrebbe partizionare i propri sistemi di database ai fini delle prestazioni tramite una distribuzione regionale dei dati dei clienti. La ricerca e l'aggiornamento dei dati risulterà più rapida se limitata a un sottoinsieme regionale dei dati. Per implementare MEST, il partizionamento deve verificarsi all'interno dello stesso database. Se il partizionamento viene eseguito tra database diversi, saranno necessari stringhe di connessione e contesti diversi anziché uno scenario MEST.

Un altro scenario in cui il partizionamento potrebbe risultare utile è costituito dal caso in cui un reparto IT desidera eseguire ogni notte il backup dei dati utilizzati di frequente, archiviando i dati a cui non si accede da oltre un anno. Gli amministratori di database potrebbero archiviare i clienti che non hanno utilizzato i propri account per oltre un anno in una tabella di archivio nello stesso database con lo stesso schema di tabella.

È importante considerare la struttura delle associazioni tra tipi di entità membri di più set di entità. MEST rappresenta lo scenario di più semplice implementazione in base alla struttura sottoposta a test. Gli scenari seguenti sono stati utilizzati correttamente.

  • In un'associazione uno-a-molti, un'entità implementata come MEST nel lato "uno" di un'associazione deve avere una relazione con due set di entità diversi nel lato "molti". Lo scenario seguente, ad esempio, può essere implementato con il tipo di entità Customer in due set di entità: PreferedCustomers e CreditRiskCustomers.

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

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

  • In un'associazione uno-a-molti, un set di entità nel lato "uno" può avere un'associazione con un'entità implementata come MEST nel lato "molti". L'entità Product, ad esempio, può essere inclusa in due set di entità e nelle associazioni con l'entità ManufacturingUnit.

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

    • ManufacturingUnit <1----*> DefectiveProducts

L'implementazione MEST in uno scenario "uno-a-uno" o "molti-a-molti" risulterà difficile in caso di progettazione del modello logico e/o di mapping del modello logico al modello concettuale. Il problema di un'implementazione MEST uno-a-uno o molti-a-molti è analogo all'implementazione di MEST nel lato "uno" con una relazione con lo stesso set di entità nel lato "molti". In uno scenario uno-a-uno è possibile creare un modello logico simile ai casi degli scenari "uno-a-molti".

  • Nello scenario di ordini seguente si verificheranno problemi in caso di progettazione del modello logico.

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

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

Per ulteriori informazioni, vedere Procedura: definire un modello con più set di entità per tipo (Entity Framework).

Vedere anche

Concetti

Associazione (EDM)
Set di associazioni (EDM)
Contenitori di entità (EDM)
Tipi EDM (Entity Data Model)
Tipi semplici (EDM)

Altre risorse

Specifica di schemi e mapping (Entity Framework)