Partager via

Définitions de table dans Microsoft Dataverse

Chaque table offre la possibilité de stocker des données structurées. Pour les développeurs, les tables correspondent aux classes que vous utilisez lors de l’utilisation de données dans Microsoft Dataverse.

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é Descriptif
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 Toutes les versions minuscules du nom du schéma. Par exemple, compte
LogicalCollectionName Toute version minuscule du nom de schéma de la collection. Par exemple, les comptes
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 programme les définitions. Mais effectuez cette modification uniquement avant d’écrire un code d’API web pour la table. Pour plus d’informations, consultez Nom de l’ensemble d’entités.

Note

EntitySetName est généré automatiquement en transformant le EntityName en pluriel de ce nom. Exemple : EntityName : Car EntitySetName : Cars. Lors de la création manuelle d’une nouvelle table, le EntitySetName peut être modifié. Les EntitySetName créés par le système sont toujours le pluriel du EntityName et vous ne pouvez pas les modifier via l'interface client. Cette règle s’applique aux tables système et aux tables créées pour les relations de type plusieurs-à-plusieurs.

Lorsque vous créez une table personnalisée, la valeur de préfixe de personnalisation de l’éditeur de solution précède le nom que vous choisissez. Vous ne pouvez pas modifier les noms d’une table après la création, à l’exception du nom du jeu d’entités. Si vous souhaitez des noms cohérents pour les éléments de définition de votre solution, créez-les dans le contexte d’une solution que vous créez associée à un éditeur de solution qui contient le préfixe de personnalisation que vous souhaitez utiliser. Pour plus d’informations, consultez l’éditeur de solution.

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

Nom Descriptif
DisplayName En règle générale, identique au nom du schéma, mais peut inclure des espaces. Par exemple, Compte
DisplayCollectionName Forme plurielle du nom d'affichage. 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.

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 un lien qui ouvre l’enregistrement dans une interface utilisateur.

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

Note

Chaque table n’a pas de 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 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, consultez :

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 les suivantes : Propriété, Tables d’activité, Table Activityparty et Tables Enfants.

Propriété de 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é Descriptif
Métier Les données appartiennent à l’unité commerciale. L’accès aux données peut être contrôlé au niveau de l’unité commerciale.
Aucun Les données n'appartiennent pas à une autre table.
Organisation Les données appartiennent à l’organisation. L’accès aux données est contrôlé au niveau de l’organisation.
Utilisateur ou équipe Les données appartiennent à un utilisateur ou à une équipe. Les actions pouvant être effectuées sur ces enregistrements peuvent être contrôlées à un niveau utilisateur.

Lorsque vous créez de nouvelles tables, les seules options de propriété sont les suivantes : Organisation ou Utilisateur ou Équipe. Vous ne pouvez pas modifier cette option après avoir fait un choix. Choisissez l’utilisateur ou l’équipe pour le contrôle le plus précis sur qui peut afficher ou effectuer des actions sur les enregistrements. Choisissez Organisation quand ce niveau de contrôle n’est pas nécessaire.

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. Ces tables ont la IsActivity propriété définie sur true.

Table Descriptif
Rendez-vous Engagement représentant un intervalle de temps avec les heures de début et de fin et la durée.
E-mail Activité envoyée par e-mail.
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 Activité de suivi de la livraison d’une lettre. L’activité peut contenir la copie électronique de la lettre.
Appel téléphonique Activité de suivi d’un appel téléphonique.
RecurringAppointmentMaster Rendez-vous principal d’une série de rendez-vous périodiques.
SocialActivity Réservé exclusivement à un usage interne.
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 ce tableau pour ajouter une structure aux colonnes de 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. Dans la table ActivityParty, 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. Pour plus d’informations, consultez :

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, PostComment, PostLikeet PostRole sont chacun des enfants de la Post table.

Keys

Chaque définition de clé alternative décrit une ou plusieurs colonnes en combinaison qui identifient de manière unique une table. En règle générale, vous appliquez des clés alternatives uniquement pour l’intégration avec des systèmes externes. Définissez d’autres clés pour identifier un enregistrement de manière unique. 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 de table pour avoir les mêmes valeurs.

Pour plus d’informations, consultez :

É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, consultez :

Voir aussi

Tables Dataverse

  • Last updated on