Ce document présente une vue d'ensemble de la notation et des conventions relatives aux diagrammes des relations des entités (ERD) Salesforce pour vous aider à interpréter clairement les modèles de données produits disponibles dans la galerie de modèles de données.

Un ERD, également appelé modèle de données, est une représentation graphique d'un système d'information. Il montre les relations entre les personnes, les objets, les lieux, les concepts et les événements de ce système. C'est un modèle logique qui transmet la structure fonctionnelle des données. Dans les ERD Salesforce, les entités sont généralement mappées avec un objet de la base de données Salesforce.

Une entité est une chose ou un objet important, réel ou conceptuel, sur lequel l'information doit être connue ou détenue.

Les entités sont représentées dans les diagrammes sous forme de cases avec des coins arrondis. Chaque case d'entité fournit généralement deux étiquettes (le cas échéant) :

• Le nom logique de l'entité (p. ex. « Entité Salesforce » dans l'exemple présenté ici). Cela peut correspondre à l'étiquette au singulier de l'objet Salesforce représenté, mais pas toujours.
• Le nom d'API « physique » ou le nom du développeur de l'objet dans votre organisation Salesforce (p. ex. « Nom d'API » dans l'exemple). Généralement, pour des objets de package géré, le nom d'API répertorié dans le diagramme n'inclut pas l'espace de noms du package géré (« vlocity_ins** », par exemple), sauf si Salesforce ou Industry Cloud utilise plusieurs packages gérés. La fin du nom d'API des objets de package géré indique le type d'objet personnalisé utilisé : « **c » pour les objets personnalisés habituels et les paramètres personnalisés, « **mdt » pour les métadonnées personnalisées, « **x » pour les objets externes.

Les cases d'entité peuvent également répertorier un ou plusieurs attributs représentatifs des attributs de cette entité. Un attribut est précédé d'un caractère « # » ou « - ».

• Un « # » indique un attribut qui fait partie de la clé unique logique de l'entité. Dans l'exemple de diagramme, « Attribut de clé utilisateur » est considéré comme la clé primaire utilisateur de l'entité.
• Un « • » indique un attribut non clé.

Chaque diagramme de relation d'entité illustre le modèle de données Salesforce du point de vue d'un cloud spécifique tel que Sales Cloud, Service Cloud ou Marketing Cloud. La palette de couleurs du diagramme reflète le nuage en évidence. Tous les clouds Industry tels que Financial Service Cloud, Health Cloud et Media Cloud utilisent le même schéma de couleurs Industry.

La couleur d'une entité donnée sur le diagramme a également une signification spécifique. La couleur du nuage de focus est indiquée en utilisant sa couleur de marque Salesforce, avec quelques exemples ci-dessous.

La section suivante examinera les différentes mises en forme d'entité en référence à l'exemple de légende Sales Cloud ci-dessous :

Une entité avec les couleurs du focus cloud représente un objet fourni avec la licence de ce cloud.

Une entité avec un remplissage blanc et une bordure noire représente un objet fourni avec une licence différente de celle de focus Cloud et qui n'est pas étendue par la licence focus Cloud. Les entités Compte et Contact affichées dans un ERD Sales ou Service Cloud, par exemple, sont affichées en blanc avec une bordure noire, car ces objets sont disponibles avec une licence de plate-forme.

Une entité avec un remplissage gris clair et une bordure noire représente un objet fourni avec une licence différente de celle du focus Cloud, mais le focus Cloud étend cet objet. Par exemple, Commerce Cloud étend l'objet de base Product2 avec des champs supplémentaires. Les extensions comprennent des champs, des relations et des types d'enregistrement supplémentaires.

Les entités sans frontière sont virtuelles. Utilisées dans un diagramme, ces cases reconnaissent l'existence d'une entité dans le modèle logique du domaine, mais l'entité n'est pas implémentée en tant qu'objet physique dans Salesforce. Les données de cette entité devraient être accédées via des appels d'API externes ou Salesforce Connect dans la solution déployée.

Les entités avec une bordure en tirets sont modélisées en tant que types d'enregistrement dans Salesforce. Dans l'exemple présenté ici, les sous-types Compte professionnel, Compte de facturation, Compte consommateur et Compte de service ont une bordure en tirets, car ils sont mappés avec les types d'enregistrement livrés avec le package géré Communications Cloud.

Les entités avec une bordure en pointillés sont virtuelles. Ni les types d'enregistrement ni un objet séparé ne sont utilisés pour différencier ces sous-types dans la solution Salesforce. Ces sous-types représentent logiquement un concept du domaine qui aide à illustrer la fonctionnalité du modèle de données.

Un sous-type d'entité est la définition d'un sous-ensemble de ses occurrences. Lorsqu'un ensemble de sous-types est ajouté dans une entité supertype, l'entité supertype représente les attributs et les relations communs, tandis que les entités sous-types affichent les attributs et les relations spécifiques au sous-type. Dans la notation du diagramme, les sous-types sont mutuellement exclusifs, ce qui signifie que tout enregistrement unique doit appartenir à un seul sous-type.

Les sous-types peuvent avoir des sous-types imbriqués qui différencient davantage les occurrences. Les sous-types des diagrammes sont logiques, mais ils peuvent être mappés avec une représentation physique de l'une des trois façons suivantes. La solidité de la bordure de l'entité du sous-type définit comment le sous-type est implémenté dans le modèle de données Salesforce.

Les entités de sous-type avec une bordure continue ont un objet réel qui suit les occurrences de ce sous-type. Dans l'exemple présenté ici, le sous-type Utilisateur externe de Contact a une bordure solide, car les Contacts enregistrés en tant qu'Utilisateurs externes sont suivis avec un enregistrement dans l'objet Utilisateur.

Une relation est une association nommée et significative entre deux entités.

Les marques et le texte sur ou autour des lignes décrivent la cardinalité, le caractère facultatif et le sens de la relation.

La cardinalité indique le nombre relatif d'occurrences de chaque côté de la relation. Dans la notation, les extrémités d'une ligne de relation indiquent la cardinalité de la relation à cette extrémité. Une patte d'oie à une extrémité indique que de nombreuses occurrences d'entité à cette extrémité peuvent être associées à chaque occurrence à l'extrémité opposée. L'absence de patte d'oie à une extrémité indique qu'au plus une occurrence d'entité à cette extrémité peut être associée à une occurrence donnée à l'autre extrémité.

Salesforce prend en charge deux types de champ de relation : les champs de référence et les champs parent-enfant (alias principal-détails). Les champs Parent-Enfant sont semblables à des références obligatoires, mais ils appliquent un couplage supplémentaire entre les entités associées. Les enregistrements du côté multiple de la relation sont supprimés en cascade lorsque l'enregistrement parent est supprimé. De plus, la visibilité des enregistrements de détail est contrôlée par la visibilité de l'enregistrement parent.

Pour illustrer la différence entre une relation enfant-parent et une relation de référence, les DRE Salesforce empruntent la notation diamant à UML. Un diamant du côté singulier d'une relation signifie que l'entité de ce côté joue le rôle principal dans la relation. L'entité du côté multiple d'une telle relation est le détail ou l'entité enfant et peut être considérée comme contenue dans l'entité parente.

L'option indique si la relation est requise ou non pour une occurrence à chaque extrémité. En tant que concept, l'optionnalité est étroitement liée à la cardinalité et la notation reflète cette proximité. L'option est indiquée à chaque extrémité d'une relation par un cercle ou une barre en travers de la ligne à l'autre extrémité de la relation. Pourquoi à l'autre bout de la relation ? Pour inclure la marge d'optionnalité du même côté de la ligne que la cardinalité.

Du côté multiple (c’est-à-dire patte d’oie) de la relation, il y a presque toujours un cercle sur la ligne. Cela signifie qu'il peut y avoir de zéro à plusieurs occurrences du côté multiple de la relation pour chaque occurrence du côté singulier de la relation.

Du côté singulier de la relation, un cercle et une barre indiquent une relation facultative pour l'entité située du côté patte d'oie de la relation. Le cercle et la barre signifient qu'il peut y avoir zéro ou une occurrence du côté singulier de la relation pour chaque occurrence du côté multiple.

Alternativement, du côté singulier de la relation, les barres doubles indiquent une relation requise pour l'entité du côté multiple de la relation. Les barres doubles signifient qu'il doit y avoir une et une seule occurrence du côté singulier de la relation pour chaque occurrence du côté multiple.

Le caractère facultatif d'une relation peut être indiqué comme obligatoire, même si la relation physique sous-jacente dans Salesforce est facultative. Par exemple, le champ AccountId dans Contact est physiquement une relation facultative, mais si vous ignorez Contacts privés, la relation directe d'un Contact à un Compte est logiquement requise. L'indicateur d'optionnalité est utilisé avec précaution. Dans la plupart des cas, le caractère facultatif indiqué dans la DRE reflète le caractère facultatif sous-jacent de la relation.

Au-delà de la cardinalité et de l'optionnalité, chaque relation entre deux entités exprime une signification particulière qui distingue cette relation des autres relations entre les deux mêmes entités. Les noms de fin de relation, tels que « partie de » et « composée de » dans le diagramme ci-dessus, définissent la nature de la relation.

Lorsque vous combinez la cardinalité, l'optionnalité et les noms de fin d'une relation, ils peuvent être utilisés pour former une phrase qui décrit la relation.

De gauche à droite : Chaque (peut/doit) être <nom de fin 1> (un et un seul / un ou plusieurs) .

De droite à gauche : Chaque (peut/doit) être <nom de fin 2> (un et un seul / un ou plusieurs) .

Par exemple,

De gauche à droite : « Chaque contact doit être principalement un contact pour un seul et unique compte. » De droite à gauche : « Chaque Compte peut être représenté principalement par un ou plusieurs Contacts. »

Les lignes de relation ont un code couleur. Les relations ajoutées par le cloud en focus pour le diagramme sont dessinées dans une couleur. Les lignes noires représentent une relation fournie avec une licence différente de celle du focus Cloud.

Les relations peuvent exister entre deux occurrences de la même entité. C'est ce qu'on appelle une relation récursive. Une ligne de relation courbe est utilisée pour indiquer des relations récursives.

Généralement, les DRE Salesforce excluent la plupart des règles métiers pour se concentrer sur la structure du modèle de données, mais une relation mutuellement exclusive est une règle métier qui est informative pour la structure. Une relation mutuellement exclusive indique qu'une seule des relations incluses dans l'arc sera utilisée pour une occurrence donnée. Notez que deux, trois relations ou plus peuvent participer à la même relation mutuellement exclusive. Une phrase décrivant la relation mutuellement exclusive présentée ici pourrait être la suivante : « Chaque entité peut être une instance d'une et d'une seule Première autre entité ou d'une et d'une seule Deuxième autre entité. »

Notez que dans les DRE Salesforce, une ligne de relation rompue qui passe par l'arc ne fait pas partie de la relation mutuellement exclusive.

Les DRE produits Salesforce officiels respectent les conventions de présentation pour plus de lisibilité. Ces conventions de présentation comprennent les suivantes :

• Les lignes de relation doivent toujours être droites.
• Les lignes de relation doivent être tracées verticalement ou horizontalement. Dans de rares cas où cela n'est pas possible, utilisez une ligne droite sur une diagonale.
• Afin de garder les lignes de relation droites, les cases d'entité peuvent être redimensionnées (plus hautes ou plus larges) pour fournir un point de destination aux relations entre les deux entités. Les entités les plus importantes (qui ont plus de relations atterrissant sur elles) sont affichées en plus grand sur le diagramme renforçant leur importance.
• Tout au long d’une même DRE, les pattes d’oie sur les relations doivent être toujours à gauche et/ou en haut de la ligne de relation (présentation à l’envers) – ou toujours à droite et/ou en bas de la ligne de relation (présentation à droite et à l’envers). Cette convention apporte de la clarté, car elle aboutit à des entités similaires réunies dans la même zone du diagramme, ce qui est utile pour comprendre les entités. L'utilisation de la présentation à l'envers entraîne l'affichage de diagrammes à l'envers avec des entités enfants au-dessus ou à gauche des entités parentes. Cependant, cela garantit que les entités les plus spécifiques du diagramme se situent en haut à gauche du diagramme, ce qui rend les diagrammes plus distincts et reconnaissables. L'utilisation de la convention de présentation côté droit entraîne la présence des mêmes entités communes en haut à gauche de chaque diagramme, mais les entités enfants sont sous ou à droite des entités parentes.

En respectant étroitement ces conventions de présentation, vous obtenez un diagramme clair et facile à lire.

Assurez-vous de consulter la galerie de modèles de données Salesforce qui suit cette norme.