Présentation
La logique de calcul d'un modèle relationnel repose sur deux principes clés :
Seuls les champs de la requête actuelle et les champs associés sont utilisés dans le calcul. (Si une requête ne contient des champs que d'une seule table logique, les autres tables logiques du modèle relationnel ne sont pas incluses dans le calcul.)
Le modèle préserve l'intégrité des données des champs de mesure.
Ce diagramme illustre le flux de traitement général. Par rapport aux jointures physiques directes, le modèle relationnel empêche efficacement l'expansion des données :
Cette présentation simplifie la logique de traitement du modèle relationnel. En pratique, des facteurs tels que la cardinalité, les taux de correspondance des données et les types de champs déclenchent différentes méthodes de traitement. Consultez les exemples suivants pour plus de détails.
Exemples
Configuration du modèle
Champs de la table de données
|
Table principale : Cases |
Table secondaire : Population |
|
|
|
Structure du modèle relationnel
Où :
Clé de jointure : Medical Institution = Medical Institution
Relation de jointure : N:N
Taux de correspondance des données : Partial Match: Partial Match
Configuration des graphiques et méthodes de calcul
Requête sur une seule table
Configuration du graphique
|
Dimension |
Institution médicale (table Population), Année (table Population) |
|
Mesure |
Somme de la population (table Population) |
Données résultantes
Requête multi-tables (dimensions uniquement)
Configuration du graphique
|
Dimension |
Mois (table Cas), Année (table Population) |
|
Mesure |
- |
Données résultantes
Logique de jointure interne
L'utilisation d'une jointure
INNER JOINimplique que, lorsqu'un graphique ne contient que des dimensions, seules les données correspondantes sont considérées comme pertinentes. Les données non appariées, telles que celles des institutions médicales D et E, sont ignorées.-
Le système joint les deux tables sur le champ « Institution médicale » à l'aide d'une jointure
INNER JOINpour créer une table intermédiaire. Après déduplication, le système affiche les données résultantes.Institution (Cas)
Mois (Cas)
Institution (Population)
Année (Population)
A
1
A
2020
A
1
A
2019
B
1
B
2020
B
1
B
2019
C
1
C
2020
C
1
C
2019
A
2
A
2020
A
2
A
2019
B
2
B
2020
B
2
B
2019
C
2
C
2020
C
2
C
2019
A
1
A
2020
A
1
A
2019
Requête multi-tables (mesures uniquement)
Configuration du graphique
|
Dimension |
- |
|
Mesure |
Somme du nombre de cas (table Cas), Somme de la population (table Population) |
Données résultantes
Logique de calcul
Lorsqu'une requête ne contient que des mesures et aucune dimension, l'agrégation produit une seule ligne de données.
Dans ce scénario, le système agrège séparément les mesures de la
Cases tableet de laPopulation table, puis concatène les résultats.
Requête multi-tables (dimensions et mesures)
Exemple 1 : Dimension de la table de gauche, mesure de la table de droite
Configuration du graphique
|
Dimension |
Institution médicale (table Cas) |
|
Mesure |
Somme de la population (table Population) |
Données résultantes
Étapes de calcul
Étape 1 : La combinaison de dimensions est calculée à partir du champ de dimension dans le graphique, Medical Institution (Cases table), et de la clé de jointure issue de la table de la mesure, Medical Institution (Population table).
Comme cette requête inclut une mesure provenant de la Population table, cette étape conserve toutes les valeurs de dimension de cette table. Cela garantit l'intégrité de la mesure lors des calculs ultérieurs.
|
Institution (Population) |
Institution (Cas) |
|
A |
A |
|
B |
B |
|
C |
C |
|
E |
- |
Étape 2 : La combinaison de dimensions est ensuite jointe à la Population table pour créer une table intermédiaire. Étant donné que seule la combinaison de dimensions est jointe et que chaque institution médicale y est unique, aucune explosion de données ne se produit.
|
Institution (Population) |
Institution (Cases) |
Population (Population) |
|
A |
A |
100 |
|
B |
B |
80 |
|
C |
C |
70 |
|
A |
A |
110 |
|
B |
B |
75 |
|
C |
C |
90 |
|
- |
E |
60 |
|
- |
E |
60 |
Étape 3 : agrégez la table intermédiaire selon la dimension utilisée dans le graphique pour obtenir le résultat final.
Comme l'« Établissement médical E » de la table Population ne correspond à aucune entrée de la table Cases, le résultat contient une ligne dont la valeur de la dimension Medical Institution est nulle.
Exemple 2 : Dimension de la table de gauche, mesure de la table de droite (incorrect)
Configuration du graphique
|
Dimension |
Year (Cases table) |
|
Mesure |
Sum of Population (Population table) |
Données résultantes
Étapes de calcul
Étape 1 : la combinaison de dimensions est calculée à partir du champ de dimension du graphique, Year (Cases table), et de la clé de jointure de la table de la mesure, Medical Institution (Population table). Pour plus de clarté, la colonne Medical Institution (Cases table) est également affichée ici.
Cette requête incluant une mesure issue de la table Population, cette étape conserve toutes les valeurs de dimension de cette table. Cela garantit l'intégrité de la mesure lors des calculs ultérieurs.
|
Institution (Population) |
Institution (Cases) |
Year (Cases) |
|
A |
A |
2019 |
|
A |
A |
2020 |
|
B |
B |
2020 |
|
C |
C |
2020 |
|
E |
- |
- |
Dans la table Cases , l'« Établissement médical A » possède des enregistrements pour 2019 et 2020. Par conséquent, la combinaison de dimensions contient deux lignes pour « A » dans le champ Medical Institution (Population table).
Étape 2 : joignez ensuite la combinaison de dimensions à la table Population pour créer une table intermédiaire.
|
Year (Cases) |
Institution (Population) |
Population (Population) |
|
2019 |
A |
100 |
|
2020 |
A |
100 |
|
2020 |
B |
80 |
|
2020 |
C |
70 |
|
2019 |
A |
110 |
|
2020 |
A |
110 |
|
2020 |
B |
75 |
|
2020 |
C |
90 |
|
- |
E |
60 |
|
- |
E |
60 |
La jointure des deux lignes dupliquées « A » de la combinaison de dimensions avec la table Population duplique les données de population de l'« Établissement médical A », ce qui provoque une explosion des données.
Étape 3 : agrégez ensuite la table intermédiaire selon la dimension utilisée dans le graphique pour produire le résultat final.
Dans ce scénario, une explosion des données se produit même avec un modèle relationnel. Pour éviter ce type de problème, nous vous recommandons les actions suivantes :
Configurez correctement les clés de jointure : dans cet exemple, vous devez définir
Medical InstitutionetYearcomme clé de jointure composite. Cela empêche l'explosion des données lors de la génération de la table intermédiaire à l'étape 2.Utilisez des dimensions et des mesures issues de la même table logique lorsque les requêtes inter-tables ne sont pas nécessaires : dans cet exemple, interroger
Medical InstitutionetPopulationuniquement depuis latable Populationproduira les résultats corrects.
Exemple 3 : Dimension de la table de droite, mesure de la table de gauche (incorrect)
Configuration du graphique
|
Dimension |
Year (Population table) |
|
Mesure |
Sum of Number of Covered Areas (Cases table) |
Données résultantes
Étapes de calcul
Étape 1 : la combinaison de dimensions est calculée à partir du champ de dimension du graphique, Year (Population table), et de la clé de jointure de la table de la mesure, Medical Institution (Cases table). Pour plus de clarté, la colonne Medical Institution (Population table) est également affichée ici.
Cette requête incluant une mesure issue de la table Cases, cette étape conserve toutes les valeurs de dimension de cette table. Cela garantit l'intégrité de la mesure lors des calculs ultérieurs.
|
Institution (Cases) |
Institution (Population) |
Year (Population) |
|
A |
A |
2020 |
|
A |
A |
2019 |
|
B |
B |
2020 |
|
B |
B |
2019 |
|
C |
C |
2020 |
|
C |
C |
2019 |
|
D |
- |
- |
Dans la table Population, les établissements médicaux A, B et C disposent chacun d'enregistrements pour les années 2019 et 2020. Cette situation génère deux lignes pour « A », deux pour « B » et deux pour « C » au sein de la combinaison de dimensions dans le champ Établissement médical (table des cas). L'établissement médical E issu de la table de population n'est pas apparié.
Étape 2 : La combinaison de dimensions est ensuite jointe à la table des cas afin de créer une table intermédiaire.
|
Institution (Cases) |
Year (Population) |
Covered areas (Cases) |
|
A |
2020 |
1 |
|
A |
2019 |
1 |
|
B |
2020 |
1 |
|
B |
2019 |
1 |
|
C |
2020 |
2 |
|
C |
2019 |
2 |
|
A |
2020 |
1 |
|
A |
2019 |
1 |
|
B |
2020 |
1 |
|
B |
2019 |
1 |
|
C |
2020 |
2 |
|
C |
2019 |
2 |
|
D |
- |
1 |
|
A |
2020 |
1 |
|
A |
2019 |
1 |
La jonction des lignes dupliquées pour les établissements médicaux A, B et C dans la combinaison de dimensions avec la table des cas entraîne une duplication des données relatives au Nombre de zones couvertes, provoquant ainsi une explosion des données.
Étape 3 : La table intermédiaire est ensuite agrégée selon la dimension utilisée dans le graphique pour produire le résultat final.
Cette requête calcule incorrectement la somme du Nombre de zones couvertes pour les établissements médicaux A, B et C en raison des duplications. La cause et les recommandations sont identiques à celles de l'exemple 2.
Configurez correctement les clés de jointure : Vous devez définir
Établissement médicaletAnnéecomme clé de jointure composite.Utilisez des dimensions et des mesures issues de la même table logique lorsque les requêtes inter-tables ne sont pas nécessaires : Vous devez interroger
AnnéeetNombre de zones couvertesuniquement depuis latable des cas.
Comparaison avec la modélisation physique
Dans les versions précédentes, Quick BI utilisait la modélisation physique pour les ensembles de données. Cette approche offre une interface visuelle permettant de configurer les jointures et de fusionner plusieurs tables en une seule table large.
Avec la modélisation physique, vous devez explicitement définir le type de jointure, tel que left join, inner join ou full join. Cela nécessite une compréhension approfondie de vos données et un prétraitement garantissant leur intégrité et leur unicité. À défaut, vous risquez des problèmes graves, tels qu'une explosion des données.
Exemple détaillé
Configuration du modèle
Champs des tables de données
|
Table Cases |
Table Population |
|
|
|
Structure du modèle physique
Table large du modèle physique
Étant donné que le champ « Medical Institution » contient des valeurs non uniques, une explosion sévère des données se produit après la modélisation physique. Par exemple, dans la figure ci-dessous, la « Population (Population table) » pour l'« Medical Institution » « A » et l'« Year (Population table) » « 2019 » est comptabilisée à tort trois fois.
Configuration du graphique et calcul
Exemple 1
Configuration du graphique
|
Dimension |
Medical Institution (Cases table) |
|
Mesure |
Sum of Population (Population table) |
Données résultantes
Résultat correct
Exemple 2
Configuration du graphique
|
Dimension |
Year (Cases table) |
|
Mesure |
Sum of Population (Population table) |
Données résultantes
Résultat correct
Inconvénients de la modélisation physique
Avec la modélisation physique, vous devez valider l'exactitude du modèle. Lorsque les données contiennent des valeurs non uniques ou sont manquantes, vous devez prendre des mesures supplémentaires pour éviter les erreurs de données, telles que :
Utilisez SQL pour agréger les données non uniques avant de créer une jointure.
Utilisez une fonction LOD pour spécifier la granularité d'agrégation et éviter les calculs incorrects.
Utilisez SQL pour compléter les données manquantes ou ajustez le type de jointure afin de tenir compte des lacunes dans les données et d'éviter toute perte.
Ces opérations requièrent une expertise en SQL, ce qui les rend difficiles d'accès pour les utilisateurs métier non techniques. Le processus de modélisation physique est également fastidieux et complexe, nécessitant une vérification répétée des résultats.
Dans la modélisation physique, joindre davantage de tables augmente le risque d'explosion des données et complique le dépannage. Pour minimiser les jointures, vous créez généralement un modèle distinct pour chaque scénario d'analyse. Toutefois, cela entraîne une prolifération des ensembles de données à mesure que les scénarios se multiplient, rendant la gouvernance et la maintenance plus difficiles au fil du temps.
Modèle relationnel : cas particuliers
Gestion des champs inter-tables
Un champ inter-table est un champ calculé qui exploite des données issues de plusieurs tables logiques. Il n'appartient à aucune table logique spécifique et fait l'objet d'une catégorie distincte au sein du jeu de données.
Le calcul des champs inter-tables implique systématiquement plusieurs tables logiques, le résultat dépendant des relations de jointure définies par les mesures et les dimensions de la requête. En raison de cette dépendance, ces champs ne peuvent être évalués que dans un contexte de requête précis ; il est donc impossible de prévisualiser leurs données au niveau détaillé.
Champs inter-tables post-agrégation
Pour créer un champ inter-table post-agrégation, commencez par agréger les champs de chaque table individuellement, puis appliquez une opération arithmétique inter-tables (addition, soustraction, multiplication ou division) sur ces résultats agrégés.
Par exemple :
Pour évaluer ce champ, Quick BI calcule d'abord SUM([Number of people(Table of Numbers)]) à partir de la table des effectifs, puis SUM([Coverage Area(Medical institution)]) à partir de la table des cas, générant ainsi les deux tables intermédiaires suivantes :
|
Établissement médical (table des cas) |
SUM(Number of people (table des effectifs)) |
|
A |
210 |
|
B |
155 |
|
C |
160 |
|
- |
120 |
|
Établissement médical (table des cas) |
SUM(Number of covered areas (table des cas)) |
|
A |
3 |
|
B |
2 |
|
C |
4 |
|
D |
1 |
Quick BI joint ensuite ces deux tables intermédiaires et effectue la division pour obtenir le résultat final.
Champs inter-tables au niveau détaillé
Créez un champ inter-table au niveau détaillé en appliquant un calcul inter-tables sur les champs bruts des différentes tables, avant toute étape d'agrégation.
Par exemple :
Pour évaluer ce champ, Quick BI joint d'abord la « table des cas » et la « table des effectifs » via leurs clés de jointure afin de produire la table intermédiaire suivante :
|
Établissement médical (table des cas) |
Nombre de zones couvertes (table des cas) |
Établissement médical (table des effectifs) |
Nombre de personnes (table des effectifs) |
|
A |
1 |
A |
110 |
|
A |
1 |
A |
100 |
|
B |
1 |
B |
75 |
|
B |
1 |
B |
80 |
|
C |
2 |
C |
90 |
|
C |
2 |
C |
70 |
|
A |
1 |
A |
110 |
|
A |
1 |
A |
100 |
|
B |
1 |
B |
75 |
|
B |
1 |
B |
80 |
|
C |
2 |
C |
90 |
|
C |
2 |
C |
70 |
|
A |
1 |
A |
110 |
|
A |
1 |
A |
100 |
Quick BI applique ensuite la division sur cette table intermédiaire, puis agrège les résultats selon les dimensions du graphique pour produire le résultat final :
Gestion des constantes
Dans un modèle relationnel, Quick BI traite les constantes (telles que le texte brut ou les littéraux numériques) comme des champs inter-tables, mais leur mode de calcul diffère de celui des autres champs inter-tables.
Par exemple, si vous créez une constante '1' dans un jeu de données en modèle relationnel, le champ apparaît dans la catégorie « Champs inter-tables » :
Constantes dans les calculs mono-table
Dans ce cas, Quick BI considère la constante comme un champ appartenant à la table logique concernée. Le calcul suit alors le chemin de requête mono-table, comme illustré ci-dessous :
Constantes dans les calculs multi-tables
Ce scénario introduit une ambiguïté : associer la constante à différentes tables modifierait les résultats du calcul et pourrait provoquer des comportements inattendus.
Pour éviter ces problèmes, Quick BI traite la constante comme un champ inter-table. Elle perd ainsi son association avec les dimensions de toutes les tables et ne participe pas à l'agrégation. L'effet est illustré ci-dessous :
