Vos expressions Set Analysis Qlik sont-elles trop longues et trop lentes ?

Le Set Analysis est le bon outil pour une vraie comparaison, comme cette année par rapport à l’an dernier. C’est aussi là que finit le correctif quand il manque quelque chose au modèle, et c’est ce second usage qui ralentit l’application.

Ce que remplacent les longues expressions

• L’historique. Des modificateurs de date et Aggr qui reconstruisent l’état qu’avait un enregistrement en mars dernier.
• Les flags. Des conditions If() dans l’expression qui décident de ce qui compte comme actif ou valide, à chaque calcul.
• La granularité. Aggr et Only qui annulent la duplication d’une table contenant deux granularités à la fois.
• Les relations manquantes. Des modificateurs imbriqués comme {<Year={2024}>} combinés à P(), qui font ce que ferait une vraie dimension.

Chacune est évaluée par graphique, par sélection, par utilisateur. C’est cela, l’attente.

Pourquoi cela retombe sur vous

• Chaque expression était, cette semaine-là, le chemin le plus rapide vers un chiffre correct.
• La logique vit dans le .qvf, donc personne en dehors de l’application ne peut la relire ni la réutiliser.
• Vous pouvez simplifier l’expression. Vous ne pouvez pas ajouter l’historique que le modèle n’a jamais conservé.

Le travail se fait au mauvais endroit

• Historique, flags et granularité relèvent du warehouse. En Set Analysis, ils sont recalculés à chaque sélection.
• Ce travail a sa place dans un endroit central : un data warehouse ou un data hub, construit une fois et lu par chaque application.
• Si cela semble coûteux, l’estimation suppose probablement des pipelines construits à la main. Une plateforme d’automatisation spécialisée les génère à partir d’un modèle, ce qui change à la fois le coût et le délai.

Ce qui change quand le modèle arrive prêt à l’emploi

Datavault Builder génère le vault et le schéma en étoile nativement dans la base de données que vous utilisez déjà, notamment SQL Server, Azure SQL, Oracle, Snowflake et Databricks.

• L’historique est conservé sous forme de satellites, et les tables point in time répondent à « où en était-on en mars » par une jointure.
• Les flags sont des colonnes, calculées une fois dans le warehouse plutôt que dans chaque expression.
• Une seule granularité par table de faits, ce qui supprime d’emblée l’essentiel du travail d’Aggr.
• Des dimensions conformes donnent aux modificateurs d’ensemble de vrais champs sur lesquels sélectionner.
• Il ne reste que de vraies comparaisons, assez courtes pour qu’un collègue puisse les relire.

Ce qu’il faut demander

Pas « le dashboard est lent », mais :

« Notre Set Analysis reconstruit l’état à une date passée et les flags de statut à chaque sélection. Le warehouse peut-il nous fournir une table point in time et les flags sous forme de colonnes, pour que les expressions deviennent de simples sommes ? »

Cela distingue le Set Analysis dont vous avez réellement besoin de celui que vous utilisez comme rustine.