Discussion :

[yvesduc]

Cliquez sur :

"Modélisation en étoile et en flocon dans QlikView"

Ayant été dès mon premier projet confronté à plusieurs difficultés spécifiques à QlikView et n'ayant reçu aucune formation à l'époque (j'en ai reçu une depuis), je me suis retrouvé bloqué plusieurs fois. J'ai été alors amené à tout remettre à plat et à réfléchir soigneusement à mon modèle. J'ai écrit cet article à destination des débutants qui s'interrogent sur la modélisation QlikView, en essayant d'y mettre ce que moi-même j'aurais aimé trouver avant de démarrer mon premier projet. J'espère qu'il sera utile à d'autres personnes.

[yvesduc]

Il semble malheureusement que ce modèle, très séduisant sur le papier, ne soit pas forcément le plus praticable dans la réalité et qu'il faille en pratique casser la table des clés en plusieurs morceaux. Je m'explique.

Il est apparu dans mon projet que la table des clés devenait très vite la plus grosse en nombre de lignes, ce qui était prévisible, mais aussi et surtout la plus grosse tout court. Or, autant QlikView est très performant pour stocker des données fortement redondantes, ce qui est le cas des tables de données en général, autant pour la table de clés, qui contient beaucoup de valeurs distinctes (le résultat des autonumber(), notamment), QlikView patine sérieusement. En fait, la construction de la table des clés occupe déjà plus de la moitié du temps total de chargement, près de 4 minutes sur 7. À cela je vois au moins deux explications : la faible redondance des données, induisant un stockage volumeux car impossible à compacter, et le calcul des autonumber() lui-même (mais je suis incapable de départager ces deux hypothèses). Quoi qu'il en soit, je me suis aperçu que si voulais matérialiser dans la table des clés un peu plus (mais pas tout) des combinaisons possibles entre les dimensions, à partir de 5 millions de lignes je saturais la RAM (j'ai 3 Go) et QlikView rendait l'âme. Dans ce cas de figure, 80% de la consommation mémoire, comme du temps de chargement (dépassant pour le coup les 20 minutes), étaient utilisés par l'unique construction de la table des clés, c'est-à-dire uniquement la dernière instruction du script !! (hors effacement des tables temporaires)

Bref, ça ne marche pas très bien, d'autant que ma plus grosse table a seulement 1 million de lignes (c'est tout à fait raisonnable). Le fichier qvw ne fait que 30 Mo sur disque.

Un modèle en flocon, avec plusieurs tables de clés partielles, devrait permettre de découper le travail en morceaux moins gros, plus facilement digérables par QlikView, alors qu'en un seul morceau QlikView cale – ou risque de caler.

L'autre petit détail que la pratique a révélé est qu'il est important, lors de l'ajout (par JOIN) dans la table temporaire des clés, de toujours insérer les dimensions liées en même temps. Par exemple, insérer simultanément le client et son équipe commerciale, lorsque le client est rattaché à une et une seule équipe. Sans quoi il y aura des lignes sans rattachement commercial, avec tables de faits, et des lignes avec rattachement commercial, sans tables de faits. Autrement dit, des trous dans la table des clés. Donc, la construction de cette table temporaire n'est pas si triviale que ça.