Définitions de table dans Microsoft Dataverse
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 :
- Utiliser des définitions de colonne d’image avec du code
- Utiliser les données de colonne d’image
- Exemple : opérations sur les images en utilisant le SDK Dataverse pour .NET
- Exemple : opérations sur les images en utilisant l’API Web de Dataverse
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. |
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
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é).