Relations de table

Les relations de table définissent la relation entre les lignes dans la base de données. Au niveau le plus simple, l’ajout d’une colonne de recherche à une table crée une relation 1 à N (un-à-plusieurs) entre les deux tables et vous permet de placer cette colonne de recherche dans un formulaire. Avec la colonne de recherche, les utilisateurs peuvent associer plusieurs lignes enfant de cette table à une seule ligne de table parent.

Outre la définition de la relation entre les lignes, les relations de tables 1 à N fournissent également des données pour résoudre les questions suivantes :

• Lorsque je supprime une ligne, les lignes liées à celle-ci doivent-elles également être supprimées ?
• Lorsque j’attribue une ligne, dois-je également attribuer toutes les lignes associées à cette ligne au nouveau propriétaire ?
• Comment rationaliser le processus de saisie de données lorsque je crée une ligne liée dans le contexte d’une ligne existante ?
• Comment les personnes qui consultent une ligne devraient-elles pouvoir afficher les lignes associées ?

Les tables peuvent également participer à une relation N à N (plusieurs-à-plusieurs) dans laquelle un nombre quelconque de lignes des deux tables peuvent être associés.

Décider s’il faut utiliser des relations de table ou des connexions

Les relations de table sont des métadonnées qui apportent des modifications à la base de données. Ces relations permettent aux requêtes de récupérer les données associées de façon efficace. Utilisez les relations de table pour définir les relations formelles qui définissent la table ou qui peuvent être utilisées par la majorité des lignes. Par exemple, une opportunité sans prospect n’est pas utile. La table Opportunité comporte également une relation N à N avec la table Concurrent. Cela permet à plusieurs concurrents d’être ajoutés à l’opportunité. Vous pouvez recueillir ces données et créer un rapport qui affiche les concurrents.

Il existe d’autres types moins formels de relations entre les lignes, qui sont appelées connexions. Par exemple, il peut être utile de savoir si deux contacts sont mariés, ou s’ils sont amis en dehors de travail, ou si un contact a travaillé pour un autre compte. La plupart des entreprises ne génèrent pas de rapports en utilisant ce type d’informations ou ne les demandent pas, et il n’est probablement pas intéressant de créer une relation de table. Pour plus d’informations : Configurer des rôles de connexion

Types de relations de table

Lorsque vous examinez l’explorateur de solutions, vous pouvez comprendre qu’il existe trois types de relations de table. En réalité, il n’en existe que deux, comme illustré dans le tableau suivant.

Le type de relation N à 1 (plusieurs-à-un) existe dans l’interface utilisateur, car le concepteur montre une vue groupée par tables. Les relations 1:N existent réellement entre tables et font référence à chaque table comme une table principale/actuelle ou une table associée. La table associée, parfois appelée table enfant, possède une colonne de recherche qui permet de stocker une référence à une ligne à partir de la table principale, parfois appelée table parente. Une relation N à 1 est simplement une relation 1 à N affichée à partir de la table associée.

Comportement des relations de table

Les comportements pour les tables associées sont importantes, car elle permet de garantir l’intégrité des données et peut automatiser les processus d’entreprise de votre entreprise.

Préserver l’intégrité des données

Certaines tables sont destinées à prendre en charge d’autres tables. Elles ne sont pas pertinentes seules. Elles ont généralement une colonne de recherche requise à associer à la table principale qu’elles prennent en charge. Que se passe-t-il lorsqu’une ligne principale est supprimée ?

Vous pouvez utiliser le comportement de relation pour définir ce qu’il se passe aux lignes associées en fonction des règles de votre entreprise. Pour plus d’informations : Ajouter un comportement des relations avancées

Automatiser les processus d’entreprise

Imaginons que vous avez un nouveau vendeur et que vous voulez lui attribuer un certain nombre de comptes actuellement attribués à un autre vendeur. Chaque ligne de compte peut avoir un certain nombre d’activités de tâches associées. Vous pouvez aisément trouver les comptes actifs que vous souhaitez réattribuer et les attribuer au nouveau vendeur. Mais que se produirait-il pour les activités de tâches associées aux comptes ? Souhaitez-vous ouvrir chaque tâche et déterminer si elle doit également être attribuée au nouveau vendeur ? Probablement pas. Par contre, vous pouvez laisser la relation appliquer automatiquement des règles standard. Ces règles s’appliquent uniquement aux lignes de tâches associés aux comptes que vous réattribuez. Vous avez les choix suivants :

• Réattribuer toutes les tâches actives.
• Réattribuer toutes les tâches.
• Ne réattribuer aucune tâche.
• Réattribuer toutes les tâches actuellement attribuées à l’ancien propriétaire des comptes.

La relation peut contrôler la façon dont les actions exécutées sur une ligne pour la ligne de table principale sont mises en cascade vers une des lignes de table associées.

Comportements

Il existe plusieurs types de comportements qui peuvent être appliqués lorsque certaines actions se produisent.

Actions

Voici les actions qui peuvent déclencher certains comportements :

Relations de tables parents

Chaque paire de tables qui sont éligibles à une relation 1 à N peuvent avoir plusieurs relations 1 à N entre elles. Cependant, en général une seule de ces relations peut être considérée comme une relation de tables parentale.

Une relation de table parentale est une relation de table 1 à N dans laquelle l’une des options de mise en cascade de la colonne Parental du tableau suivant est true.

Par exemple, si vous créez une table personnalisée et si vous ajoutez une relation de table 1 à N à l’entité Compte dans laquelle votre table personnalisée est la table associée, vous pouvez configurer les actions afin que cette relation de table utilise les options dans la colonne Parental. Si vous ajoutez ensuite une autre relation de table 1 à N à votre table personnalisée en tant que table de référencement, vous pouvez uniquement configurer les actions pour qu’elles utilisent les options de la colonne Non parental.

Généralement, cela signifie que pour chaque paire de tables, il n’existe qu’une relation parentale. Dans certains cas la recherche sur la table associée peut autoriser une relation à plusieurs types de tables.

Par exemple, si une table a une recherche de clients qui peut faire référence à une table Contact ou Compte. Il existe deux relations de tables 1 à N parentales distinctes.

Une table d’activité similaire possède un ensemble de relations de table parentales pour les tables pouvant être associées à l’aide de la colonne de recherche Concernant.

Limitations de comportements que vous pouvez définir

En raison des relations parentales, souvenez-vous de certaines limitations lorsque vous définissez des relations de table.

• Une table personnalisée ne peut pas être la table principale dans une relation avec une table système associée dont les actions se propagent. Cela signifie qu’il est impossible d’avoir une relation avec une action Tout en cascade, Cascade active ou Cascade propriétaire entre une table personnalisée principale et une table système associée.
• Aucune nouvelle relation ne peut être définie avec l’action Tout en cascade, Cascade active ou Cascade propriétaire si la table associée dans cette relation existe déjà en tant que table associée dans une autre relation dont l’action est Tout en cascade, Cascade active ou Cascade propriétaire. Cela empêche les relations qui créent une relation à plusieurs parents.

Nettoyage des droits d’accès hérités

L’utilisation des comportements en cascade Apparenter à nouveau et Partager est utile lorsque vous souhaitez fournir un accès aux lignes de tables associées. Mais il peut y avoir un changement de processus ou de conception qui nécessite une modification des paramètres de comportement en cascade.

Lorsqu’une relation de table utilise Apparenter à nouveau ou Partager et que le comportement en cascade est modifié en Sans mise en cascade, la relation de table empêche toute nouvelle modification d’autorisation de se répercuter sur les tables enfants associées. En outre, les autorisations héritées qui ont été accordées alors que le comportement en cascade était actif doivent être révoquées.

Le nettoyage des droits d’accès hérités est un travail système qui nettoie les droits d’accès hérités qui restent après le changement du comportement en Sans mise en cascade. Ce nettoyage n’affectera aucun utilisateur qui a reçu directement l’accès à une table, mais supprimera l’accès de toute personne qui a reçu l’accès par héritage uniquement.

Voici comment fonctionne le nettoyage des droits d’accès hérités :

1. Identifie et collecte toutes les tables qui étaient dans une relation en cascade avec le parent mis à jour.
2. Identifie et collecte les utilisateurs qui ont obtenu l’accès aux tables associées via l’accès hérité.
3. Vérifie les utilisateurs qui ont reçu un accès direct à une table associée et les supprime de la collection.
4. Supprime l’accès hérité pour les utilisateurs collectés sur les tables collectées.

Une fois le nettoyage exécuté, les utilisateurs qui ont pu accéder aux tables associées uniquement grâce à la fonction de mise en cascade ne peuvent plus accéder aux lignes, ce qui garantit une plus grande sécurité. Il existe des cas où le nettoyage peut échouer. En savoir plus sur comment nettoyer l’accès hérité

Voir aussi

Surveiller les tâches système
Créer et modifier des relations 1:N (un-à-plusieurs) ou N:1 (plusieurs-à-un)
Création de relations de table plusieurs-à-plusieurs