Cardinalité et intégrité référentielle
La configuration d’une source de données, quelle que soit la manière dont vous combinez les données, exige de comprendre la structure des données de chaque table et la façon dont elles peuvent être combinées. Vous devez prendre en considération plusieurs éléments clés :
- Niveau de détail : degré de détail des données, leur granularité. On peut envisager ce paramètre en répondant à la question « Qu’est-ce qui définit une ligne ? ». Pour plus d’informations sur la granularité, voir Structurer les données pour l’analyse
- Champ partagé : au moins un champ peut être utilisé pour constituer le lien entre les tables. Pour une jointure, ces champs définissent la clause de jointure. Dans les tables connexes, ils établissent la relation.
- Cardinalité : indique combien il y a de valeurs uniques (grand nombre ou petit nombre) pour le champ partagé (caractère unique). Pour plus d’informations, consultez la section suivante.
- Intégrité référentielle : une valeur dans une table est garantie avoir une correspondance dans l’autre table. En d’autres termes, il ne peut pas y avoir un enregistrement dans une table qui n’a pas d’enregistrement correspondant dans l’autre table. Pour plus d’informations, voir ci-dessous.
Cardinalité
La cardinalité dans une colonne ou un champ unique indique à quel point les valeurs ont un caractère unique. Une cardinalité faible signifie qu’il n’y a que quelques valeurs uniques (comme dans un champ de couleur des yeux). Une cardinalité élevée signifie qu’il y a beaucoup de valeurs uniques (comme dans un champ de numéros de téléphone).
La cardinalité entre les tables est similaire, mais se réfère à la question de savoir si une ligne d’une table pourrait être liée à plus dune ligne dans une autre table. (Il est important de se rappeler que la cardinalité ne s’intéresse pas à la question d’éventuelles données manquantes dans l’une ou l’autre table. La présence ou l’absence de données manquantes est l’intégrité référentielle. Bien que ces concepts fonctionnent de pair, il s’agit de deux attributs différents de la relation.)
On distingue plusieurs options : un-à-un, un-à-plusieurs, plusieurs-à-un ou plusieurs-à-plusieurs.
Un-à-un
Exemple : chaque voiture a sa propre plaque d’immatriculation et une plaque d’immatriculation est spécifique à une voiture individuelle. Voiture-à-plaque est une relation de type un-à-un. Notez que même si une voiture n’est pas enregistrée ou qu’un numéro de plaque d’immatriculation n’a pas encore été attribué à une voiture, cet écart est décrit par l’intégrité référentielle. Une voiture ne peut avoir qu’une seule plaque d’immatriculation et une plaque d’immatriculation ne peut être attribuée qu’à une seule voiture, de sorte que la cardinalité reste un-à-un. |
 |
Un-à-plusieurs ou Plusieurs-à-un
Exemples : de nombreux employés ont le même manager. Employés-à-Manager est une relation de type plusieurs-à-un. Manager-à-employé est une relation de type un-à-plusieurs. |
|
Plusieurs-à-plusieurs
Exemples : un acteur joue dans de nombreux films et un film a beaucoup d’acteurs. Acteur-à-film est une relation de plusieurs-à-plusieurs. Plusieurs livres peuvent être achetés dans la même transaction et un livre peut être acheté plusieurs fois. ISBN-à-IDCommande est une relation de type plusieurs-à-plusieurs. |
 |
La cardinalité peut être spécifiée dans les paramètres Options de performances. Pour plus d’informations, consultez Optimiser les requêtes relationnelles à l’aide d’options de performance.
Intégrité référentielle
Un concept associé, appelé Intégrité référentielle, signifie qu’une ligne dans une table aura toujours une ligne correspondante dans l’autre table, déterminée par la valeur de leurs champs partagés. Si la base de données ne contient aucun enregistrement pour les voitures sans plaques d’immatriculation ou les plaques d’immatriculation sans voitures, cette relation a une intégrité référentielle.
Dans Tableau, l’intégrité référentielle est configurée de chaque côté de la relation. Dans les paramètres Options de performances, Certains enregistrements correspondent signifie qu’il n’y a pas (ou vous ne savez pas s’il y a) intégrité référentielle. Tous les enregistrements correspondent signifie qu’il y a intégrité référentielle. Le paramètre par défaut est de ne pas présupposer l’intégrité référentielle (Certains enregistrements correspondent).
Pour plus d’informations, consultez Optimiser les requêtes relationnelles à l’aide d’options de performance.
Testez-vous
Pouvez-vous définir la cardinalité et l’intégrité référentielle de chaque diagramme ? Pouvez-vous traduire en mots ?
Exemple :
si nous avons défini la table gauche comme des livres et la table droite comme des auteurs liés sur AuthorID, traduisez le diagramme en mots :
- Un livre peut avoir plusieurs auteurs (les enregistrements violets montrent une ligne dans la table des livres sur la gauche correspondant à plusieurs enregistrements dans la table des auteurs sur la droite).
- Aucun auteur n’a plus d’un livre (chaque enregistrement d’auteur à droite ne correspond qu’à un seul enregistrement de livre sur la gauche).
- Il n’y a pas de livres sans auteurs (tous les enregistrements à gauche correspondent à un enregistrement à droite).
- Certains auteurs peuvent ne pas avoir de livres (l’enregistrement de l’auteur en gris sur la droite n’a pas d’enregistrement de livre correspondant sur la gauche.)
Cliquez sur chaque section ci-dessous pour la développer.
Pourquoi est-ce important ?
La configuration correcte des paramètres de cardinalité ou d’intégrité référentielle peut augmenter les performances grâce à l’optimisation des requêtes. Des configurations incorrectes peuvent par contre entraîner des problèmes d’agrégation en raison de la perte ou de la duplication des données. Les paramètres d’Options de performances par défaut sont Plusieurs pour la cardinalité et Certains enregistrements correspondent pour l’intégrité référentielle. Vous ne pouvez les ajuster que si vous êtes sûr des caractéristiques correctes de vos données.
Pour plus d’informations sur la façon dont Tableau gère chaque paramètre, voir Ce que signifient les paramètres de cardinalité et d’intégrité référentielle.
Exemple dans Tableau
Explorons ce qui se passe lorsque la cardinalité est mal configurée.
Remarque : l’exemple suivant utilise un sous-ensemble de tables de l’Ensemble de données Bookshop. Vous pouvez télécharger le classeur d’accompagnement, ou télécharger les données brutes pour créer les sources de données vous-même. Les tables utilisées sont Book, Info et Edition dans Bookshop.xlsx (en ne conservant que quelques champs) et LibraryProfile et Catalog dans BookshopLibraries.xlsx.
Les tables Book et Info ont une relation de un-à-un. Info consiste essentiellement en des colonnes supplémentaires pour la table Book. Pour cette raison, alors qu’elles pourraient être reliées, il est logique d’utiliser une jointure pour créer une nouvelle table logique contenant toutes les colonnes. La table Edition a une relation de plusieurs-à-un avec cette table combinée étant donné qu’il peut y avoir plusieurs éditions pour un seul livre, généralement avec des formats différents. (Notez que le diagramme ci-dessous montre la relation entre le tableau Book+Info et Edition, il s’agit donc d’une relation un-à-plusieurs.)
Edition est lié à Catalog en tant que relation un-à-plusieurs sur ISBN. Les tables Catalog et LibraryProfile ont une relation de plusieurs-à-plusieurs sur Library ID. Le point clé est que la table LibraryProfiles a plusieurs lignes par bibliothèque, une pour chaque type de personnel (bibliothécaire, assistant de bibliothèque, technicien de bibliothèque). Pour plus d’informations sur la structure de ces tables, voir l’Ensemble de données Bookshop.
Paramètres adéquats
Lorsque la relation Catalog-LibraryProfile est correctement définie, nous pouvons créer une visualisation simple qui montre le nombre d’employés dans chaque bibliothèque pour plusieurs livres. Il s’agit d’un visualisation extrêmement simple, mais il est utile d’illustrer ce point. Idle Hour Library compte 130 employés, quel que soit le livre dont nous parlons. On distingue trois valeurs pour le type de personnel, de sorte que chaque total est composé de trois enregistrements (le nombre entre parenthèses).
Nombre d’employés par bibliothèque et titre. (Les nombres entre parenthèses indiquent le nombre d’enregistrements dans chaque repère.)
Paramètres incorrects : un-à-un
Lorsque la relation est définie à tort comme de type un-à-un, dans la visualisation, chaque titre dans Catalog est effectivement associé avec un seul enregistrement dans la table LibraryProfile (comme indiqué par le nombre d’enregistrements entre parenthèses).
Nombre d’employés par bibliothèque et titre. (Les nombres entre parenthèses indiquent le nombre d’enregistrements dans chaque repère.)
Ci-dessus, nous pouvons voir que chaque bibliothèque affiche seulement son nombre minimum d’employés. (Voir les nombres en caractères gras dans la visualisation ci-dessous. Le plus faible nombre d’employés est le nombre reflété dans la visualisation Staff Count.)
Répartition du personnel par type et bibliothèque.
Pour plus d’informations sur la façon dont les relations deviennent des jointures contextuelles pour une visualisation, consultez Présentation de la nouvelle modélisation des données dans Tableau(Le lien s’ouvre dans une nouvelle fenêtre) sur le blog Tableau.
Paramètre incorrect : jointure
Bien qu’il existe des façons de contourner ce genre de problème (les expressions de niveau de détail en étant un exemple courant), la jointure de tables présentant une granularité différente ou une cardinalité de type « plusieurs » peut générer la duplication d’éléments. Ici, le nombre d’employés est exact pour les titres qui n’ont qu’un seul format, mais pour les livres qui ont deux formats dans la table Editions, le comptage en double se transmet également au nombre d’employés (notez que le nombre d’enregistrements entre parenthèses est de 6 au lieu des 3 corrects).
Nombre d’employés par bibliothèque et titre. (Les nombres entre parenthèses indiquent le nombre d’enregistrements dans chaque repère.)
Paramètre incorrect : présupposer l’intégrité référentielle incorrectement
Dire à Tableau qu’il y a intégrité référentielle (tous les enregistrements correspondent) lorsque ce n’est pas le cas peut entraîner des valeurs abandonnées. Ici, ces deux visualisations sont similaires, mais celle sur la droite provient d’une source de données configurée de manière à présupposer l’intégrité référentielle. Cette visualisation a perdu les valeurs null. Bien que cela puisse ne poser aucun problème dans certaines circonstances, il est important de comprendre ce que ces valeurs null représentent. Ici, lorsque la visualisation affiche le nombre d’éditions dans chaque bibliothèque, les valeurs null indiquent deux éditions qui sont présentes dans la table Edition mais qui ne sont détenues par aucune bibliothèque. Il pourrait s’agir d’un oubli important, et c’est un oubli qu’une présupposition incorrecte de l’intégrité référentielle ne verrait pas.
Explorez le classeur et ses sources de données pour voir quels autres problèmes peuvent découler de tables mal combinées.
Incidences sur les performances
Si une mauvaise configuration de ces paramètres peut entraîner des données manquantes ou dupliquées, pourquoi Tableau permet-il de les changer ? Dans de nombreux cas, vous pouvez et devriez laisser les paramètres par défaut : utiliser une relation plutôt qu’une jointure pour les tables, laisser la cardinalité sur plusieurs-à-plusieurs, et ne pas présupposer l’intégrité référentielle. Cela vaut tout particulièrement si vous n’êtes pas sûr de ce que les paramètres devraient être.
Toutefois, la cardinalité et l’intégrité référentielle sont des options de performances parce qu’il peut y avoir des implications de performance pour les paramètres par défaut. Si vous êtes sûr de la structure de vos données, configurer les paramètres corrects peut réduire la durée d’exécution de la requête afin d’améliorer la vitesse.
Dans les coulisses
Remarque : cette section utilise des analogies avec d’autres techniques de combinaison de données pour fournir un cadre conceptuel seulement. Il ne s’agit pas d’une description technique de la façon dont Tableau utilise les paramètres de performances pour les relations.
Cardinalité
La cardinalité de la relation a des répercussions lors de l’agrégation. On peut l’envisager en termes de fusion. La fusion des données interroge deux sources de données indépendamment. Chaque source de données est agrégée comme nécessaire au niveau de détail souhaité pour la vue indépendamment de l’autre source de données. Pour les relations, le paramètre de cardinalité influe sur le fait que l’agrégation se produit avant ou après la jointure.
Dans l’exemple ci-dessus, le paramètre Plusieurs signifie que le nombre d’employés pour chaque bibliothèque est agrégé avant la combinaison de ces données avec les informations du livre, veillant ainsi à ce que chaque livre ait les bons nombres. Lorsque la cardinalité a été incorrectement définie sur Un, le nombre d’employés n’a pas été agrégé avant sa combinaison avec les données de livre, ce qui a généré des valeurs incorrectes.
Notez que non seulement les valeurs incorrectes sont affichées, mais toutes les valeurs sont attribuées au type de personnel Bibliothécaires, bien qu’elles proviennent des trois types de personnel. Une mauvaise configuration de ce paramètre peut entraîner des valeurs imprévisibles et incorrectes. Ce filtrage des résultats ne se produit que lorsqu’un champ d’une autre table de l’autre côté de la relation mal définie est utilisé dans la vue.
Toutefois, si les valeurs sont uniques, Tableau est libre de supprimer l’agrégation de pré-jointure si elle optimise la requête.
Intégrité référentielle
Bien que l’intégrité référentielle se réfère à un paramètre pour les relations, on peut l’envisager en termes de types de jointure. Une jointure externe complète conservera tous les enregistrements, qu’il y ait ou non une correspondance dans l’autre table, mais cela a un coût au niveau des performances. Si vous craignez la perte éventuelle d’enregistrements, une jointure externe est plus sûre. C’est ainsi que les tables sont traitées lorsqu’il n’y a pas nécessairement d’intégrité référentielle (Certains enregistrements correspondent).
Une jointure interne ne conservera que les enregistrements où il y a correspondance des deux tables, en abandonnant les enregistrements qui n’apparaissent pas dans chaque table. Si vous savez qu’une jointure interne n’éliminera pas les données nécessaires, elle est plus efficace. Si les options de performances sont définies sur Tous les enregistrements correspondent, l’intégrité référentielle est présupposée et les jointures sont exécutées sans tenir compte des valeurs sans correspondance.
Un paramètre d’intégrité référentiel incorrect peut avoir un effet de type filtre sur les données combinées, supprimant les valeurs sans correspondance. Pour plus d’informations sur le pouvoir de conserver des enregistrements sans correspondance, consultez Poser des questions à travers plusieurs tables connexes dans le blog Tableau. Pour plus d’informations sur les types de jointure, consultez Lier vos données.
Conserver les paramètres par défaut
Si les performances de votre analyse sont acceptables, nous vous encourageons fortement à laisser les paramètres Options de performances par défaut sur « plusieurs-à-plusieurs » et à ne pas présupposer l’intégrité référentielle. La puissance des relations vient de leur capacité à fournir des résultats exacts et appropriés dans le contexte, sur la base des tables utilisées pour l’analyse. La modification de ces paramètres supprime la flexibilité sémantique des relations.