Partager via

Jeux d'entités (EDM)

  • Article

Dans le modèle EDM (Modèle de données d'entité), un jeu d'entités (EntitySet) est un conteneur logique pour les entités d'un même type. De même, un ensemble d'associations (AssociationSet) est un conteneur pour les associations du même type. Les jeux d'entités et les ensembles d'associations définis dans des schémas sont mappés aux tables de la base de données qui stockent les données des applications. Ils constituent la base des classes dans le modèle objet de programmation qui sera utilisé par le code d'application.

Les jeux d'entités et les ensembles d'associations définissent la portée des entités et des associations. Les conteneurs d'entités définissent quant à eux les conteneurs de stockage où sont emmagasinées les entités et les associations. Il n'existe pas d'ensembles de SimpleType. Ces types sont instanciés en tant que valeurs affectées aux propriétés d'une entité.

Un EntitySet d'un EntityType contient des instances de l'EntityType ou l'un de ses sous-types. Plusieurs EntitySet peuvent être définis à l'aide du même EntityType. Une instance d'un EntityType ne peut être membre que d'un EntitySet.

Les instances d'entités d'un EntitySet doivent remplir trois conditions :

  • Le type de l'instance d'entité est l'objet EntityType de l'EntitySet ou un sous-type de l'objet EntityType.

  • La valeur Key de chaque instance d'entité l'identifie de manière unique dans l'EntitySet.

  • L'instance d'entité n'est membre d'aucun autre EntitySet.

La syntaxe CSDL (Conceptual Schema Definition Language) ci-dessous est la déclaration d'un EntitySet nommé CustomerSet. L'EntitySet contient des instances de l'entité CustomerType :

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

Dans le segment de schéma ci-dessous, deux déclarations EntityType définissent les types d'entités Product et Supplier. Les jeux d'entités basés sur les entités Product et Supplier sont nommés comme il se doit sous leur forme plurielle : Products et Suppliers. Ces jeux d'entités sont ajoutés à la définition d'un 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>

Pour plus d'informations sur les conteneurs d'entités, voir Conteneurs d'entités (EDM).

Jeux d'entités multiples par type

Le modèle EDM (Entity Data Model) autorise la présence de plusieurs jeux d'entités par conteneur d'entités ou la définition de plusieurs conteneurs d'entités pour le même type d'entité. La définition de jeux d'entités multiples par type (MEST, Multiple Entity Sets per Type) permet aux utilisateurs de rationnaliser leur code en présence d'un partitionnement de la base de données ou dans d'autres cas de figure où plusieurs tables ont la même structure.

Les bases de données peuvent être partitionnées pour diverses raisons liées aux performances, à la disponibilité ou à la facilité de gestion. Une institution financière qui gère les comptes d'un grand nombre de clients peut partitionner ses systèmes de bases de données à des fins d'optimisation des performances en fonction de la répartition régionale des données des clients. La recherche et la mise à jour des données seront plus rapides si elles sont limitées à un sous-ensemble régional des données. Pour implémenter le modèle MEST, le scénario de partitionnement doit intervenir au sein de la même base de données. Le partitionnement de plusieurs bases de données implique en effet l'utilisation de différentes chaînes de connexion et différents contextes à la place d'un scénario MEST.

Le partitionnement peut également être utile, par exemple, pour un service informatique désireux de sauvegarder de nuit des données fréquemment sollicitées et d'archiver les données n'ayant pas servi depuis plus d'un an. Les administrateurs de base de données peuvent archiver les clients qui n'ont pas utilisé leurs données de compte depuis plus d'un an dans une table d'archive de la base de données qui contient le schéma de cette table.

Il est essentiel de bien réfléchir à la structure des associations entre types d'entités lorsque ceux-ci sont membres de plusieurs jeux d'entités. Le modèle MEST est d'autant plus simple à implémenter que cette structure a été correctement testée. Les scénarios ci-dessous ont été utilisés avec succès.

  • Dans une association un-à-plusieurs, une entité implémentée selon le modèle MEST sur la terminaison « un ۛ» de l'association doit présenter une relation avec deux jeux d'entités différents sur la terminaison « plusieurs ». Par exemple, le scénario ci-dessous peut être implémenté avec le type d'entité Customer dans deux jeux d'entités : PreferedCustomers et CreditRiskCustomers.

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

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

  • Dans une association un-à-plusieurs, un jeu d'entités sur la terminaison « un ۛ» peut être associé à une entité implémentée selon le modèle MEST sur la terminaison « plusieurs ». Par exemple, l'entité Product peut être incluse dans deux jeux d'entités et dans des associations avec l'entité ManufacturingUnit.

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

    • ManufacturingUnit <1----*> DefectiveProducts

Le modèle MEST dans un scénario « un-à-un » ou « plusieurs à plusieurs » sera difficile à implémenter lors de la conception du modèle logique et/ou du mappage du modèle logique au modèle conceptuel. La difficulté posée par le modèle MEST « un-à-un » ou « plusieurs à plusieurs » est la même qu'en présence de MEST sur la terminaison « un » et d'une relation avec le même jeu d'entités sur la terminaison « plusieurs ». Avec le « un-à-un », il est possible de créer un modèle de logique similaire aux cas « un-à-plusieurs ».

  • La conception du modèle logique correspondant au scénario de commande ci-dessous sera problématique.

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

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

Pour plus d'informations, voir Procédure : définir un modèle avec jeux d'entités multiples par type (Entity Framework).

Voir aussi

Concepts

Association (EDM)
Ensemble d'associations (EDM)
Conteneurs d'entités (EDM)
Types de modèles EDM
Types simples (EDM)

Autres ressources

Schémas et spécification de mappage (Entity Framework)