Conception de votre modèle de données

Objectifs de formation

Une fois cette unité terminée, vous pourrez :

• Concevoir un modèle de données pour de grandes quantités de données.
  
• Décrire les trois types de biais de données et comment les éviter.
  
• Étendre un modèle de données pour inclure des objets externes.
  

Planifier votre modèle de données

Les données sont l'un des éléments clés de toute application. Les utilisateurs créent constamment des données. Toute la journée. Tous les jours. Tellement, Tellement de données. Soudain, votre organisation a accumulé des millions d'enregistrements, des milliers d'utilisateurs et des giga-octets de données stockées.

Ces grandes quantités de données (LDV) peuvent conduire à des performances stagnantes, notamment des requêtes, des recherches et des vues de liste plus lentes et une actualisation plus lente de Sandbox. Vous pouvez éviter cette situation difficile si votre plan tient compte des LDV en amont et conçoit vos modèles de données pour favoriser l'évolutivité dès le début.

Tout sur les biais de données

L'une des clés de la gestion des grandes quantités de données pour optimiser les performances consiste à concevoir soigneusement la propriété des enregistrements afin d'éviter tout biais de données. Un biais de données survient lorsque plus de 10 000 enregistrements enfant sont associés aux mêmes enregistrements parents au sein d'une organisation.

Planifiez votre modèle de données avec suffisamment de comptes pour maintenir le nombre d'enregistrements enfants par parent en dessous de ce seuil, et distribuez les nouveaux enregistrements enfants sur ces comptes lors de leur création. Si vous n'utilisez pas ces stratégies, trois types de biais de données peuvent survenir et avoir une incidence négative sur les performances : le biais de données de compte, le biais de propriété et le biais de référence.

Biais de données de compte

Certains objets Salesforce, tels que les comptes et les opportunités, possèdent des relations de données spéciales qui maintiennent l'accès aux enregistrement parents et enfants dans des modèles de partage privé. Un trop grand nombre d'enregistrements enfants associés au même objet parent dans l'une de ces relations provoque un biais de données de compte. Imaginez que vous ayez un certain nombre de contacts non attribués et que vous les placiez sur un compte nommé « Non attribué ». Cela peut créer des problèmes au niveau du verrouillage de l'enregistrement et des performances de partage.

Verrouillage de l'enregistrement

Voici un autre scénario : Vous êtes en train de mettre à jour un grand nombre de contacts sur le même compte dans plusieurs threads. Pour chaque mise à jour, le système verrouille à la fois le contact en cours de modification et son compte parent afin de préserver l'intégrité dans la base de données. Même si chaque verrouillage est maintenu pendant un temps très bref, comme toutes les mises à jour essayent de verrouiller le même compte, il existe un risque élevé qu'une mise à jour échoue parce que la précédente verrouille encore le compte.

Problèmes de partage

Il existe une dynamique similaire en ce qui concerne le partage. Selon la manière dont votre partage est configuré, lorsque vous faites quelque chose qui semble simple, comme modifier le propriétaire d'un compte, vous pouvez être amené à examiner chaque enregistrement enfant du compte et à régler également son partage. Cela peut inclure le recalcul de la hiérarchie des rôles et des règles de partage. Et si nous parlons de centaines de milliers d'enregistrements enfants, cela peut impliquer un temps considérable.

Biais de propriété

Lorsqu'un grand nombre d'enregistrements avec le même type d'objets sont la propriété d'un utilisateur unique, ce déséquilibre provoque un biais de propriété. Comme chaque enregistrement doit avoir un propriétaire, il semble que la solution naturelle consiste à biaiser ces enregistrements sur un propriétaire générique, tel que le « Non attribué » susmentionné. Mais cela peut provoquer des problèmes de performances en raison des calculs du partage nécessaires pour gérer la visibilité de ces enregistrements.

Lorsque le propriétaire biaisé figure dans la hiérarchie des rôles, des opérations telles que les suppressions ou les mises à jour de propriétaires doivent supprimer le partage de l'ancien propriétaire et de tous les utilisateurs parent au sein de la hiérarchie des rôles, et de tous les utilisateurs disposant d'un accès par l'intermédiaire des règles de partage. C'est la raison pour laquelle les changements de propriété tendent à être les changements transactionnels les plus coûteux dans le système.

Dans certains cas, il est tout simplement impossible d'éviter un biais de propriété. Dans certains cas, il est préférable de s'assurer que le propriétaire biaisé n'a aucun rôle. De cette manière, vous éloignez l'utilisateur et ses enregistrements de la hiérarchie des rôles et de ses règles de partage associées.

Biais de référence

Un biais de référence survient lorsqu'un grand nombre d'enregistrements sont associés à un enregistrement unique dans l'objet de référence (l'objet sur lequel vous effectuez des recherches). Comme vous pouvez placer des champs de référence sur tous les objets de Salesforce, un biais de référence peut créer des problèmes pour tous les objets au sein de votre organisation.

Si vous vous retrouvez avec un biais de référence et que vous avez une mise en œuvre personnalisée extrêmement complexe, vous pourriez créer un problème sans même vous en rendre compte. En envisageant soigneusement vos possibilités de gestion des biais de référence, vous pouvez éviter les problèmes de verrouillage sur les champs de référence pour vous assurer que votre architecture est en mesure de s'ajuster à la croissance de votre organisation.

Pourquoi les biais de référence sont-ils tellement néfastes ? Les champs de référence dans Salesforce sont essentiellement des relations de clés étrangères entre des objets. Chaque fois qu'un enregistrement est inséré ou mis à jour, Salesforce doit verrouiller les enregistrements cibles qui sont sélectionnés pour chaque champ de référence. Cela assure la préservation de l'intégrité lorsque les données sont enregistrées dans la base de données.

Dans des circonstances normales, les opérations d'enregistrement sont exécutées si rapidement que vous ne subissez pas de verrouillages. Mais lorsque vous ajoutez simultanément un code personnalisé et de grandes quantités de données, vous pouvez faire face à des exceptions de verrouillage qui provoquent des échecs lorsque vous essayez d'insérer ou de mettre à jour des enregistrements.

Comme il n'existe pas d'outils spécifiquement conçus pour identifier les biais de référence, retrouver problèmes d'architecture revient vite à chercher une aiguille dans une meule de foin. Il est important de ne pas oublier qu'un biais de référence, dans certains modèles d'utilisation, peut ne provoquer aucun problème, et il est donc préférable d'effectuer une recherche en fonction des modèles qui provoqueront des problèmes. Vous devez évaluer des objets avec un grand nombre d'enregistrements et une importante activité simultanée d'insertions et de mises à jour.

Utilisation d'objets externes

Une autre stratégie pour les grandes quantités de données consiste à utiliser des objets externes, ce qui évite d'avoir à entrer les données dans Salesforce. Avec une stratégie de hiérarchisation des données qui répartit les données sur plusieurs objets et les apporte sur demande depuis un autre objet ou un magasin externe, vous évitez à la fois le stockage de grandes quantités de données dans votre organisation et les problèmes de performance associés aux grandes quantités de données.

Les objets externes sont similaires à des objets personnalisés, sauf qu'ils se mappent sur des données qui sont stockées hors de votre organisation Salesforce, permettant aux utilisateurs et à la plateforme Force.com d'effectuer des recherches sur les données externes et d'interagir avec celles-ci.

En accédant aux données d'enregistrement à la demande, les objets externes reflètent toujours l'état actuel des données externes. Vous n'avez pas besoin de gérer une copie de ces données dans Salesforce, et vous ne gaspillez donc pas de stockage ni de ressources à maintenir la synchronisation des données. Il est préférable d'utiliser les objets externes quand vous disposez d'une grande quantité de données que vous ne pouvez pas ou ne souhaitez pas stocker dans votre organisation, et que vous n’avez besoin d’utiliser qu’une petite quantité de ces données à la fois.

Une source de données externes spécifie la manière d'accéder à un système externe. Salesforce Connect utilise des sources de données externes pour accéder à des données qui sont stockées à l'extérieur de votre organisation Salesforce. Files Connect utilise des sources de données externes pour accéder à des systèmes de contenu tiers. Les sources de données externes possèdent des objets externes associés, que vos utilisateurs et la plateforme Force.com utilisent pour interagir avec les données et le contenu externe.

Recherche d'objet externe

Les objets externes prennent en charge les relations de recherche standard, qui peuvent utiliser les ID d'enregistrement Salesforce de 18 caractères pour associer les enregistrements connexes entre eux. Mais souvent, les données qui sont stockées hors de votre organisation Salesforce ne comportent pas ces ID d'enregistrement. De sorte que deux types spéciaux de relations de recherche sont disponibles pour les objets externes : les références externes et les références indirectes.

Ces références externes et références indirectes comparent les valeurs d'un champ spécifique sur l'objet parent aux valeurs d'un champ de relation sur l'objet enfant. Lorsque les valeurs correspondent, les enregistrements sont associés les uns aux autres.

Utilisez une relation de référence externe lorsque le parent est un objet externe. Une relation de référence externe associe un objet enfant standard, externe ou personnalisé à un objet parent externe. Les valeurs du champ de l'ID externe standard de l'objet externe parent sont comparées aux valeurs du champ de relation de référence externe. Pour un objet externe enfant, les valeurs du champ de relation de référence externe proviennent du nom de la colonne externe spécifié.

Utilisez une relation de référence indirecte lorsque les données externes ne comportent pas d'ID d'enregistrement Salesforce. Une relation de référence indirecte associe un objet enfant externe à un objet parent standard ou personnalisé. Lorsque vous créez un champ de relation de référence indirecte sur un objet externe, vous spécifiez le champ de l'objet parent et le champ de l'objet enfant pour qu'ils correspondent l'un à l'autre, en sélectionnant un champ d'ID externe unique personnalisé sur l'objet parent pour qu'il corresponde au champ de relation de référence indirecte de l'enfant, et dont les valeurs sont déterminées par le nom de colonne externe spécifiée.

Voici une répartition des types de relations disponibles pour les objets externes :

Vous connaissez maintenant les points importants à garder à l'esprit (et à éviter) lorsque vous créez l'architecture de votre organisation pour de grandes quantités de données. Vous pouvez également engager un architecte des Services stratégiques de Salesforce pour vous aider à concevoir la meilleure manière de gérer la configuration initiale et la croissance au fil du temps. Dans l'unité suivante, nous émettrons des requêtes LDV et des recherches dans la préparation

Ressources

• Développeur Salesforce : Éviter les biais de données de compte pour optimiser les performances
• Développeur Salesforce : Gestion des biais de référence dans Salesforce pour éviter les exceptions de verrouillage d'enregistrement
• Aide Salesforce : Définition d'objets externes
• PDF : Conception de l'accès aux enregistrements à l'échelle de l'entreprise
• Développeur Salesforce : Présentation des objets et champs Salesforce/objets externes