Définitions de table dans Microsoft Dataverse

  • Article

Chaque table fournit la possibilité de stocker des données structurées. Pour les développeurs, les tables correspondent aux classes que vous utilisez lorsque vous travaillez avec des données dans Microsoft Dataverse.

Noms de table

Chaque table a un nom unique défini lors de sa création. Ce nom est présenté de différentes façons :

Nom de la propriété Description
SchemaName Généralement une version du nom logique Pascal. Par exemple : Compte
CollectionSchemaName Forme plurielle du nom de schéma. par exemple, Comptes
LogicalName Toute version minuscule du nom de schéma. Par exemple : compte
LogicalCollectionName Toute version minuscule du nom de schéma de la collection. par exemple, comptes
EntitySetName Utilisé pour identifier des collections avec l’API Web. Par défaut, il s’agit du même nom que le nom de collection logique.
Il est possible de modifier le nom du jeu d’entités en mettant à jour les définitions par programmation, mais cette opération doit être effectuée uniquement avant que du code d’API Web soit écrit pour la table. Pour plus d’informations : Nom du jeu d’entités

Notes

EntitySetName est automatiquement généré en mettant EntityName au pluriel. Exemple : EntityName : Car EntitySetName : Cars. Lors de la création manuelle d’une nouvelle table, EntitySetName peut être changé. L’objet EntitySetName créé par le système sera toujours le pluriel de EntityName et ne pourra pas être modifié via l’interface client. Cela inclut les tables système ainsi que les tables créées pour plusieurs à plusieurs intersections de relations.

Lorsque vous créez une table personnalisée, le nom que vous choisissez est ajouté à la valeur de préfixe de personnalisation de l’éditeur de solutions associé à la solution avec laquelle la table a été créée. Hormis le nom du jeu d’entités, vous ne pouvez pas modifier les noms d’une table après sa création. Si vous souhaitez que les noms soient cohérents pour les éléments de définition dans votre solution, vous devez les créer dans le contexte d’une solution que vous créez et qui est associée à un éditeur de solutions qui contient le préfixe de personnalisation que vous souhaitez utiliser. Plus d’informations : Éditeur de solutions

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

Nom Description
DisplayName Généralement, il est identique au nom du schéma, mais il peut inclure des espaces. Par exemple : Compte
DisplayCollectionName Forme plurielle du nom complet. par exemple, Comptes
Description Courte phrase décrivant la table, à savoir Entité commerciale qui représente un client ou un prospect. Société facturée dans les transactions professionnelles.

Voici les valeurs localisables qui sont utilisées pour faire référence aux tables dans une application. Ces valeurs peuvent être modifiées à tout moment. Pour ajouter ou modifier les valeurs localisées, consultez Traduire le texte de tables, de formulaires et de colonnes personnalisées dans d’autres langues.

Clé primaire

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

Par défaut, toutes les tables disposent d’un seule colonne d’identificateur unique GUID nommé : <table logical name>Id.

Nom principal

La valeur de propriété PrimaryNameAttribute est le nom logique de la colonne qui stocke la valeur de chaîne qui identifie l’enregistrement de table. Il s’agit de la valeur qui est affichée dans un lien pour ouvrir l’enregistrement dans une interface utilisateur.

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

Notes

Les tables n’ont pas toutes un nom principal. Certaines tables ne sont pas destinées à être affichées dans une interface utilisateur.

Images d’entité

La valeur de propriété PrimaryImageAttribute est le nom logique de la colonne image qui a été choisie pour représenter l’enregistrement de l’entité. Cette image peut être affichée dans une application.

Exemple : La table Contact, plus précisément sa colonne EntityImage peut stocker une image du contact.

Notes

C’est différent de l’icône affichée pour une table dans les applications pilotées par modèle. La propriété IconVectorName contient le nom de la ressource Web SVG qui la définit.

Pour plus d’informations :

Types de tables

Les fonctions et le comportement des tables dépendent de plusieurs propriétés de la table. La plupart de ces propriétés sont relativement simples et ont des noms descriptifs. Les quatre propriétés qui nécessitent plus d’explications sont les suivantes : Ownership, tables Activity, table Activityparty et tables Child.

Propriété de table

Les tables peuvent être classées d’après le mode de propriété des données qui s’y trouvent. Il s’agit d’un concept important lié à la manière dont la sécurité est appliquée aux tables. Ces informations sont dans la propriété OwnershipType. Le tableau suivant décrit les différents types de propriété :

Type de propriété Description
Professionnel Les données appartiennent à la division. L’accès aux données peut être contrôlé au niveau de la division.
Aucun(e) Données non détenues par une autre table.
Organisation Données détenues par l’organisation. L’accès aux données est contrôlé au niveau de l’organisation.
Utilisateur ou équipe Données détenues par un utilisateur ou une équipe. Les actions pouvant être effectuées sur ces enregistrements peuvent être contrôlées à un niveau utilisateur.

Quand vous créez des tables, les seules options de propriété sont Organisation et Utilisateur ou équipe. Une fois votre choix d’option effectué, vous ne pouvez pas le modifier. Choisissez Utilisateur ou Équipe pour le contrôle le plus granulaire sur les individus autorisés à voir ou exécuter des actions sur les enregistrements. Choisissez Organisation lorsque ce niveau de contrôle est inutile.

Tables d’activité

Une activité est une tâche effectuée, ou à effectuer, par un utilisateur. Une activité est une action pour laquelle on peut placer une entrée dans le calendrier.

Les activités sont modélisées différemment des autres genres de tables qui stockent des données d’entreprise. Les données relatives aux activités sont fréquemment affichées ensemble dans une liste ; pourtant chaque type d’activité exige des propriétés uniques. Plutôt que d’avoir une seule table Activity avec toutes les propriétés possibles, il existe différents genres de tables d’activité, chacun d’eux héritant des propriétés d’une table ActivityPointer de base. Pour ces tables, la propriété IsActivity sera true.

Tableau Description
Rendez-vous Engagement représentant un intervalle de temps avec heures de début/fin et durée.
Email Activité effectuée via des protocoles de courrier électronique.
Télécopie 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 Activité de suivi de la livraison d’une lettre. L’activité peut contenir la copie électronique de la lettre.
PhoneCall Activité de suivi d’un appel téléphonique.
RecurringAppointmentMaster Rendez-vous principal d’une série de rendez-vous périodiques.
Activité sociale Utilisation interne uniquement.
Tâche Activité générique représentant le travail à effectuer.

Chaque fois que quelqu’un crée l’un de ces genres d’enregistrements de table d’activité, un enregistrement de table ActivityPointer correspondant est créé avec la même valeur de colonne d’identificateur unique ActivityId. Vous ne pouvez pas créer, mettre à jour ou supprimer des instances de la table ActivityPointer, mais vous pouvez les récupérer. C’est ce qui permet tous les types d’activités à présenter dans une liste.

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

Table ActivityParty

Cette table sert à ajouter une structure aux colonnes PartyListType de table d’activité qui incluent des références à d’autres tables. Vous utiliserez cette table lors de la définition des valeurs pour des colonnes de table d’activité telles que Email.to ou PhoneCall.from. Dans l’table ActivityParty, vous définissez la colonne ParticipationTypeMask pour définir le rôle joué par la référence. Les rôles comprennent Sender``ToRecipient, Organizer etc.

Vous pouvez interroger la table ActivityParty, 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 associée. Pour plus d’informations :

Tables Child

Les tables dont la propriété IsChildEntity est true n’auront jamais aucun privilège défini et n’auront jamais comme propriétaire Utilisateur ou équipe. Les opérations qui peuvent être effectuées sur une entité enfant sont liées à une table à laquelle elles sont associées par le biais d’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, PostComment, PostLike et PostRole sont chacune des enfants de la table Post.

Clés

Chaque définition de clé secondaire décrit un ou plusieurs colonnes qui, ensemble, identifient une instance de table de manière unique. Les clés secondaires s’appliquent généralement uniquement à l’intégration avec des systèmes externes. Vous pouvez définir des clés secondaires pour identifier un enregistrement. Cela est utile si vous intégrez des données avec un système qui ne prend pas en charge les clés d’identifiants uniques. Vous pouvez définir une valeur de colonne unique ou une combinaison de valeurs de colonnes afin d’identifier de manière unique une table. L’ajout d’une clé secondaire applique une contrainte d’unicité sur ces colonnes. Vous ne pourrez pas créer ou mettre à jour un autre enregistrement de table pour qu’elle ait les mêmes valeurs.

Pour plus d’informations :

États de la table

La plupart des tables ont deux propriétés pour assurer le suivi de l’état d’un enregistrement. Il s’agit de StateCode, appelée Statut dans les applications basées sur un modèle et de StatusCode, appelée Raison du statut dans les applications basées sur un modèle.

Ces deux colonnes contiennent un groupe d’options qui affichent les valeurs valides. Les valeurs de colonne StateCode et StatusCode sont liées afin que seules certaines options StatusCode soient valides pour un StateCode donné.

Cela peut varier par table, mais voici le modèle commun pour de nombreuses tables et le comportement par défaut pour les tables personnalisées :

Choix/Options StateCode Choix/Options StatusCode
0 : Actif 1 : Actif
1 : Inactif 2 : Inactif

Certaines tables ont des groupes d’options différents.

Exemple : table PhoneCall, StateCode et StatusCode

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

L’ensemble des codes d’état valides pour une table n’est pas personnalisable, mais les codes de statut le sont. Vous pouvez ajouter plus d’options StatusCode pour un StateCode correspondant.

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

Pour plus d’informations :

Voir aussi

Tables Dataverse

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).