Définitions de table dans Microsoft Dataverse

Les définitions de table dans Microsoft Dataverse décrivent la structure et le comportement de chaque table qui stocke des données structurées. Cet article explique comment travailler avec les définitions de table par programmation, notamment les noms de table, les clés, le propriétaire et les états. Pour les développeurs, les tables correspondent aux classes que vous utilisez lors de l’utilisation de données dans Microsoft Dataverse.

Le Kit de développement logiciel (SDK) pour .NET la classe EntityMetadata et le type d’entité EntityMetadata de l’API web contiennent les propriétés qui définissent des tables.

Note

Lorsque vous récupérez des définitions de table à l’aide de l’API web, les données de la réponse utilisent le type complexe ComplexEntityMetadata. La différence est que les ManyToManyRelationships, Keys, ManyToOneRelationships, OneToManyRelationships et Attributes sont des collections (tableaux), et non des propriétés de navigation à valeur de collection. Utilisez le type d’entité EntityMetadata lors de la création ou de la mise à jour de tables à l’aide de l’API web.

Noms de table

Chaque table a un nom unique que vous définissez lors de sa création. Vous voyez ce nom de plusieurs façons :

Nom de la propriété Description Example
SchemaName En règle générale, une version en casse Pascal du nom logique. Account
CollectionSchemaName Forme plurielle du nom de schéma. Accounts
LogicalName Toutes les versions minuscules du nom du schéma. account
LogicalCollectionName Toute version minuscule du nom de schéma de la collection. accounts
EntitySetName Permet d’identifier les collections avec l’API web. Par défaut, il est identique au nom de la collection logique.
Vous pouvez modifier le nom du jeu d’entités en mettant à jour par programmation la définition de la table. Apportez cette modification avant d’écrire un code d’API web pour la table. Pour plus d’informations, consultez Nom de l’ensemble d’entités.		 accounts

Note

Lorsque vous créez une table personnalisée avec du code, vous devez ajouter le préfixe de personnalisation de l’éditeur de solution au SchemaName Dataverse ne vérifie pas qu’il s’agit du préfixe de personnalisation correct , uniquement qu’il a un préfixe de personnalisation. Veillez à utiliser le préfixe correct, car vous ne pouvez pas le modifier ultérieurement.

CollectionSchemaName, LogicalName, LogicalCollectionName et EntitySetName les valeurs sont générées à l’aide de la valeur SchemaName.

Chaque table possède également trois propriétés qui peuvent afficher des valeurs localisées :

Nom Description Example
DisplayName Généralement, il est identique au nom du schéma, mais il peut inclure des espaces. Compte
DisplayCollectionName Forme plurielle du nom d'affichage. Comptes
Description Une courte phrase décrivant le tableau. Entreprise qui représente un client ou un client potentiel. L’entreprise qui est facturée dans les transactions commerciales.

Utilisez ces valeurs localisables pour faire référence aux tables d’une application. Vous pouvez modifier ces valeurs à tout moment. Pour ajouter ou modifier des valeurs localisées, consultez Traduire le texte personnalisé de tableau, de formulaire et de colonne dans d’autres langues.

Clé primaire

La PrimaryIdAttribute valeur de propriété est le nom logique de la colonne qui sert de clé primaire pour la table.

Par défaut, toutes les tables incluent une seule colonne d’identificateur unique GUID nommée <table logical name>Id.

Nom principal

La PrimaryNameAttribute valeur de propriété est le nom logique de la colonne qui stocke la valeur de chaîne identifiant l’enregistrement de table. Cette valeur apparaît dans des liens qui ouvrent l’enregistrement dans une interface utilisateur.

Exemple : la table Contact utilise la colonne FullName comme colonne de nom principal.

Note

Toutes les tables n’ont pas de valeur de propriété PrimaryNameAttribute. Certaines tables ne sont pas destinées à être affichées dans une interface utilisateur.

Images de table

La valeur de propriété PrimaryImageAttribute est le nom logique de la colonne d'image que vous choisissez pour représenter l’enregistrement d’entité. Une application peut afficher cette image.

Exemple : la colonne EntityImage de la table de contacts peut stocker une image du contact.

Note

Cette image est différente de l’icône affichée par les applications basées sur des modèles pour un tableau. La IconVectorName propriété contient le nom de la ressource web SVG qui définit l’icône.

Pour plus d’informations, reportez-vous aux rubriques suivantes :

Types de tables

Les fonctionnalités et le comportement des tables dépendent de plusieurs propriétés de table. La plupart de ces propriétés sont relativement simples et ont des noms descriptifs. Quatre propriétés qui nécessitent une explication supplémentaire sont : propriété des tables, tables d’activité, table Activityparty et tables enfants.

Propriété de la table

Vous pouvez catégoriser les tables en fonction de leur propriété des données. Ce concept est important pour comprendre comment assurer la sécurité des tables. La OwnershipType propriété contient ces informations. Le tableau suivant décrit les différents types de propriété :

Type de propriété Description
BusinessOwned Les données appartiennent à l’unité commerciale. Vous pouvez contrôler l’accès aux données au niveau de l’unité commerciale.
None Les données n'appartiennent pas à une autre table.
OrganizationOwned Les données appartiennent à l’organisation. Vous pouvez contrôler l’accès aux données au niveau de l’organisation.
UserOwned Les données appartiennent à un utilisateur ou à une équipe. Vous pouvez contrôler les actions qui peuvent être effectuées sur ces enregistrements au niveau de l’utilisateur.
Filtered (préversion) Les enregistrements n’ont aucun propriétaire. Vous pouvez contrôler l’accès via des privilèges de rôle de sécurité en fonction des filtres qui évaluent les valeurs de colonne.

Lorsque vous créez de nouvelles tables, les seules options de propriété sont : OrganizationOwned, UserOwned ou Filtered (aperçu). Vous ne pouvez pas modifier cette option après avoir fait un choix.

Choisissez UserOwned quand les enregistrements nécessitent un propriétaire utilisateur ou d’équipe, une affectation et un partage. Choisissez OrganizationOwned quand l’accès au niveau de l’organisation est suffisant. Choisissez Filtered (version préliminaire) quand vous avez besoin d’un accès au niveau des lignes en fonction des valeurs de colonne, avec les autorisations accordées via les filtres de rôle de sécurité. Les enregistrements dans les Filtered tables n’ont aucun propriétaire et ne peuvent pas être attribués ou partagés.

Vous pouvez également appliquer des filtres d’enregistrement aux tables OrganizationOwned et UserOwned pour contrôler l’accès au niveau des lignes en fonction des valeurs de colonne sans modifier leur OwnershipType. Ces tables conservent leur modèle de propriété existant.

En savoir plus sur la propriété des enregistrements filtrés :

Tables d’activité

Une activité est une tâche qu’un utilisateur effectue ou prévoit d’effectuer. Une activité est n’importe quelle action pour laquelle vous pouvez effectuer une entrée sur un calendrier.

Les activités sont modélisées différemment des autres types de tables qui stockent des données métier. Les données sur les activités sont fréquemment affichées ensemble dans une liste, mais chaque type d’activité nécessite des propriétés uniques. Au lieu d’utiliser une table d’activité unique avec chaque propriété possible, utilisez des types distincts de tables d’activité.

Chacune de ces tables hérite des propriétés d’une table ActivityPointer de base ( type d’entité ActivityPointer de l’API Web). Ces tables ont la IsActivity propriété définie sur true.

Tableau /
Type d'entité		 Nom d'affichage Description
adx_inviteredemption /
adx_inviteredemption		 Utilisation de l’invitation Contient des informations sur l’acceptation d’une invitation.
adx_portalcomment /
adx_portalcomment		 Commentaire du portail Une activité qui est utilisée pour partager des informations entre l’utilisateur et le client sur le portail.
Rendez-vous /
Rendez-vous		 Rendez-vous Période représentant un intervalle avec heures de début/fin et durée.
chat /
conversation		 Conversation dans Teams Réservé exclusivement à un usage interne. Entité qui stocke les données d’association d’enregistrements Dynamics 365 avec le chat Microsoft Teams.
Messagerie électronique /
email		 Adresse e-mail Activité effectuée via des protocoles de courrier électronique.
Télécopie /
télécopie		 Fax Activité qui vérifie le résultat d’un appel et le nombre de pages d’une télécopie, et qui stocke éventuellement la copie électronique du document.
Lettre /
lettre		 Lettre Activité de suivi de la livraison d’une lettre. L’activité peut contenir la copie électronique de la lettre.
PhoneCall /
appel téléphonique		 Appel téléphonique Activité de suivi d’un appel téléphonique.
RecurringAppointmentMaster /
recurringappointmentmaster		 Rendez-vous périodique Rendez-vous principal d’une série de rendez-vous périodiques.
SocialActivity /
activité sociale		 Activité sociale Réservé exclusivement à un usage interne.
Tâche /
tâche		 Tâche Activité générique représentant le travail à effectuer.

Lorsqu’un utilisateur crée l’un de ces types d’enregistrements de table d’activité, le système crée un enregistrement de table correspondant ActivityPointer avec la même ActivityId valeur de colonne d’identificateur unique. Vous ne pouvez pas créer, mettre à jour ou supprimer des instances de la ActivityPointer table, mais vous pouvez les récupérer. Cette conception vous permet de présenter tous les types d’activités dans une liste.

Vous pouvez créer des tables d’activité personnalisées qui se comportent de la même façon.

Table ActivityParty

Utilisez la table ActivityParty ( type d’entité activityparty de l’API web) pour ajouter une structure aux colonnes de la table PartyListType d’activité qui incluent des références à d’autres tables. Utilisez ce tableau lors de la définition de valeurs pour les colonnes de table d’activité comme Email.to ou PhoneCall.from. Définissez la colonne participationtypemask pour définir le rôle joué par la référence. Les rôles incluent Sender, ToRecipient, Organizer et bien plus encore.

Vous pouvez interroger la ActivityParty table, mais vous ne pouvez pas créer, récupérer, mettre à jour ou supprimer une partie d’activité en dehors de l’activité à laquelle elle est liée.

Tables Child

Les tables où la IsChildEntity propriété est vraie n’ont jamais de privilèges définis et ne sont jamais détenues par l’utilisateur ou l’équipe. Les opérations que vous pouvez effectuer sur une table enfant sont liées à une table à laquelle elles sont associées via une relation plusieurs-à-un. Les utilisateurs peuvent effectuer des opérations sur des tables enfants uniquement s’ils peuvent effectuer la même opération sur la table associée. Les tables enfants sont supprimées automatiquement quand l’enregistrement de table dont elles dépendent est supprimé.

Par exemple, Comment (PostComment) et Like (PostLike) sont des tables enfants de la table Post.

Clés secondaires

Chaque définition de clé alternative décrit une ou plusieurs colonnes en combinaison qui identifient un enregistrement de manière unique. En règle générale, vous appliquez des clés alternatives uniquement pour l’intégration avec des systèmes externes. Cette fonctionnalité est précieuse si vous intégrez des données à un système qui ne prend pas en charge les clés d’identificateur uniques GUID. Vous pouvez définir une valeur de colonne unique ou une combinaison de valeurs de colonne pour identifier de manière unique une table. L’ajout d’une autre clé applique une contrainte d’unicité sur ces colonnes. Vous ne pouvez pas créer ou mettre à jour un autre enregistrement dans la même table pour avoir les mêmes valeurs.

Pour plus d’informations, reportez-vous aux rubriques suivantes :

États de la table

La plupart des tables ont deux propriétés pour suivre l’état d’un enregistrement. Ces propriétés sont StateCode, qui apparaissent sous forme d’état dans les applications basées sur des modèles, et StatusCode, qui apparaît en tant que motif d’état dans les applications basées sur des modèles.

Les deux propriétés contiennent un ensemble de choix qui affichent les valeurs valides. Les valeurs StateCode et StatusCode sont liées afin que seuls certains choix StatusCode soient valides pour un StateCode donné.

Ce lien peut varier selon la table, mais le modèle courant pour de nombreuses tables, et la valeur par défaut pour les tables personnalisées, est ce modèle :

Choix du Code d'État Choix de codes de statut
0 : Actif 1 : Actif
1 : Inactif 2 : Inactif

Certaines tables ont différents ensembles de choix.

Exemple : PhoneCall table StateCode et StatusCode choix

StateCode StatusCode
0 : Ouvrir 1 : Ouvrir
1 : Terminé 2 : Fabriqué
4 : Reçu
2 : Annulé 3 : Annulé

Vous ne pouvez pas personnaliser l’ensemble de codes d’état valides pour une table, mais vous pouvez personnaliser les codes d’état. Vous pouvez ajouter plus d’options StatusCode pour un StateCode correspondant.

Pour les tables personnalisées, vous pouvez définir davantage de critères pour les transitions valides entre les états.

Pour plus d’informations, reportez-vous aux rubriques suivantes :

Voir aussi

Tables Dataverse

  • Dernière mise à jour :