Je suis nouvelle sur Qlik et j'aurai besoin de votre aide.
Dans mon modèle, j'ai créé un table de fait de type creuse réunissant les données de deux tables différentes, ma table A dont la dimension temps est au niveau Annee_Mois et une table B dont la dimension temps est au niveau trimestre.
J'ai crée ensuite deux tables de type calendrier, une avec une clé "Anne_Mois" pour faire le lien avec les données de la table de fait issues de la table A et une avec une cle "Trimestre_Code" pour faire le lien avec les données de la table de faits issues de la table B.
Première question, est ce que créer deux tables de dimension calendrier est la bonne méthode quand les données de type temps ne sont pas au même niveau de granularité ?
Qlik me génère une référence circulaire entre les deux tables calendriers au niveau de plusieurs champ qui ont les mêmes noms dans les deux tables : [ANNEE] et [TRIMESTRE_LIBELLE]. Pour supprimer la référence circulaire j'ai décidé de renommer les champs de la table calendrier (celle avec la granularité trimestre) en intégrant dans le nom des champs la source des données (ex : VENTE_TRIMESTRE_LIBELLE).
J'aimerai également savoir si c'est la bonne méthode.
Tu es sur la bonne voie. Quand on a deux tables avec des niveaux de granularité différents (mois vs trimestre), il est courant de créer deux tables de calendrier séparées. Ainsi, chaque table de faits se rattache au bon niveau de temps.
La référence circulaire que tu as rencontrée est normale — Qlik n’aime pas quand deux tables exposent des champs avec les mêmes noms. Renommer les champs dans l’un des calendriers (comme tu l’as fait avec VENTE_TRIMESTRE_LIBELLE) est une bonne façon d’éviter ce problème.
Par la suite, si tu as besoin d’analyser en même temps les deux granularités (par exemple mois et trimestre dans le même graphique), l’approche serait d’ajouter un “master calendar” ou une table de pont commune par-dessus. Mais si tes analyses restent séparées (certaines au mois, d’autres au trimestre), alors deux calendriers avec des noms de champs distincts fonctionnent très bien.
J’espère que ça clarifie les choses !
Live and Breathe Qlik & AWS. Follow me on my LinkedIn | Know IPC Global at ipc-global.com
Dans ton cas, si tu travailles uniquement avec la granularité de la table B sur certaines visualisations, le plus simple est de créer une dimension dédiée (par exemple [Type_Logement_B]) directement dans ton script ou ta table de faits. Ainsi, ton volet de filtre affichera uniquement les valeurs qui existent réellement dans cette source (“Collectif” et “Individuel”), sans mélanger avec “Collectif et résidence” qui vient de la table A.
Les autres méthodes que tu as listées (tester Null() dans l’expression du filtre ou gérer ça uniquement au niveau des visualisations) fonctionnent aussi, mais elles ajoutent de la complexité côté front-end. En général, clarifier les dimensions dans le modèle de données rend l’utilisation plus intuitive et évite les surprises.
Donc ma préférence : séparer les champs de type logement par source au niveau du modèle (comme tu as fait pour tes calendriers), et ensuite tu décides lequel utiliser selon le contexte de ton analyse.
Live and Breathe Qlik & AWS. Follow me on my LinkedIn | Know IPC Global at ipc-global.com
Tu es sur la bonne voie. Quand on a deux tables avec des niveaux de granularité différents (mois vs trimestre), il est courant de créer deux tables de calendrier séparées. Ainsi, chaque table de faits se rattache au bon niveau de temps.
La référence circulaire que tu as rencontrée est normale — Qlik n’aime pas quand deux tables exposent des champs avec les mêmes noms. Renommer les champs dans l’un des calendriers (comme tu l’as fait avec VENTE_TRIMESTRE_LIBELLE) est une bonne façon d’éviter ce problème.
Par la suite, si tu as besoin d’analyser en même temps les deux granularités (par exemple mois et trimestre dans le même graphique), l’approche serait d’ajouter un “master calendar” ou une table de pont commune par-dessus. Mais si tes analyses restent séparées (certaines au mois, d’autres au trimestre), alors deux calendriers avec des noms de champs distincts fonctionnent très bien.
J’espère que ça clarifie les choses !
Live and Breathe Qlik & AWS. Follow me on my LinkedIn | Know IPC Global at ipc-global.com
Je n'ai pas besoin pour le moment de faire des analyses en même temps avec les deux granularités mais je garde l'idée de la Master Calendar dans un coin de ma tête si jamais la demande évolue.
Dans ma table A j'ai une dimension [type_logement] avec deux valeurs possibles ('Collectif et résidence','Individuel') et dans ma table B j'ai aussi une dimension [type_logement] avec deux valeurs possibles également ('Collectif', 'Individuel'). Dans ma table de fait je me retrouve donc avec trois valeurs possibles pour la dimension [type_logement] : 'Collectif et résidence',''Collectif' et 'Individuel'.
Sur une feuille j'ai des graphiques et des tables qui utilisent les données de la table de faits en provenance de la table d'origine B (celle avec la granularité au trimestre). J'aimerai savoir quel est la bonne méthode pour filtrer le volet de filtre 'Type_Logement' pour qu'il n'affiche que les deux valeurs correspondant au type_logement présent dans la table d'orgine B : ('Collectif', 'Individuel')
Je vois plusieurs méthode possible :
- créer dans la table de fait deux dimension [Ventes_Type_Logement] et [Permis_type_logement]
- Garder une seule dimension et au niveau du volet filtre définir une expression en testant la valeur Null() sur une colonne présente dans ma table d'origine A et pas dans la B
- Au niveau visualisation créer deux éléments principaux un qui filtre sur les types de logements pour les permis et un deuxième qui filtre sur les types de logement pour les ventes.
Dans ton cas, si tu travailles uniquement avec la granularité de la table B sur certaines visualisations, le plus simple est de créer une dimension dédiée (par exemple [Type_Logement_B]) directement dans ton script ou ta table de faits. Ainsi, ton volet de filtre affichera uniquement les valeurs qui existent réellement dans cette source (“Collectif” et “Individuel”), sans mélanger avec “Collectif et résidence” qui vient de la table A.
Les autres méthodes que tu as listées (tester Null() dans l’expression du filtre ou gérer ça uniquement au niveau des visualisations) fonctionnent aussi, mais elles ajoutent de la complexité côté front-end. En général, clarifier les dimensions dans le modèle de données rend l’utilisation plus intuitive et évite les surprises.
Donc ma préférence : séparer les champs de type logement par source au niveau du modèle (comme tu as fait pour tes calendriers), et ensuite tu décides lequel utiliser selon le contexte de ton analyse.
Live and Breathe Qlik & AWS. Follow me on my LinkedIn | Know IPC Global at ipc-global.com
J'aurai une nouvelle question en lien avec la création de ma table de fait de type table creuse.
Suite à un changement dans les données sources collectées pour la construction de mon modèle, je me rend compte que les deux tables A et B utilisées pour remplir ma table de fait ne partagent plus aucune dimension en commun.
Je me demande donc si l'utilisation d'une table creuse est pertinente dans ce cas ou bien s'il ne vaut pas mieux créer deux tables de faits séparées chacune liée au calendrier qui lui correspond ?
La modélisation avec des tables creuses étant nouvelle pour moi, j'aimerai comprendre dans quel cas elle est vraiment pertinente par rapport à une modélisation en étoile "classique".
