Vos applications Qlik créent-elles sans cesse des clés synthétiques ?

Les clés synthétiques et les références circulaires, c'est Qlik qui associe exactement ce qu'on lui a fourni. Elles apparaissent parce que les données arrivent sans dimensions conformes ni vraies clés, et chaque application doit donc les inventer.

Vos applications Qlik créent-elles sans cesse des clés synthétiques ?

La plateforme d'automatisation de data warehouse à laquelle font confiance les équipes data de tous les secteurs

Petr Beles Petr Beles Co-Founder · Publié dans Solutions aux défis des outils BI LinkedIn

Cela vous semble familier ?

  • Le visionneur de modèle de données est rempli de tables $Syn que personne n'a voulu créer.
  • Un rechargement signale une référence circulaire et une table finit faiblement couplée.
  • Le début de chaque script de chargement est un bloc de renommages, d'instructions QUALIFY et de tables de liens.
  • Ajouter une seule nouvelle table à une application casse des associations qui fonctionnaient la veille.

Une clé synthétique, c’est Qlik qui fait exactement ce qu’il doit faire avec les tables qu’on lui a fournies. Quand plusieurs tables partagent plusieurs noms de champs, le moteur doit bien les associer d’une manière ou d’une autre.

Ce que les clés synthétiques vous disent

  • Plusieurs tables partagent plusieurs champs. Qlik construit une table $Syn pour chaque combinaison, et le visionneur de modèle de données s’en remplit.
  • Deux chemins mènent à la même table. C’est une référence circulaire, et Qlik couple faiblement une table pour briser la boucle.
  • Les correctifs sont structurels. Tables de liens, faits concaténés, QUALIFY, renommage avec AS, clés composites construites avec AutoNumber.
  • Chaque correctif est local. Il règle cette application, et l’application suivante sur les mêmes sources recommence à zéro.

Chacune est une clé qui aurait dû exister avant que les données n’arrivent dans Qlik.

Pourquoi cela retombe sur vous

  • Les extraits sont arrivés avec les noms de champs que chaque système source utilisait, quels qu’ils soient.
  • Personne en amont n’a décidé quel CustomerID désigne le client, alors c’est au script de chargement de le faire.
  • Vous pouvez renommer un champ dans Qlik. Vous ne pouvez pas rendre conforme la dimension dont il provient.

Le travail se fait au mauvais endroit

  • Décider comment les tables sont reliées est un travail de warehouse. Dans Qlik, il est refait dans le script de chargement de chaque application.
  • 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 la couche dimensionnelle nativement dans la base de données dont vous disposez déjà, qu’il s’agisse de Snowflake, Databricks, SQL Server, Fabric, Oracle ou PostgreSQL.

  • Des dimensions conformes signifient une seule table client et une seule clé client, partagées par chaque table de faits.
  • Les clés de substitution permettent des jointures sur un seul champ, il ne reste donc rien que Qlik doive synthétiser.
  • Des faits à une granularité déclarée remplacent la table de liens que vous mainteniez à la main.
  • Le script de chargement devient un simple LOAD depuis des tables finies, sans bloc de renommages en tête.
  • Une nouvelle application part du modèle, pas d’une copie du dernier correctif.

Ce qu’il faut demander

Pas « Qlik crée sans cesse des clés synthétiques », mais :

« Nos applications ont besoin de tables de liens et de champs renommés, parce que les commandes, les factures et les expéditions portent chacune leurs propres clés client et date. Le warehouse peut-il fournir des dimensions conformes avec des clés de substitution, pour que chaque application charge le même schéma en étoile ? »

Si la réponse est que rendre ces dimensions conformes prendrait un trimestre d’ingénierie, c’est exactement l’objection que Datavault Builder lève.

Voyez-le fonctionner sur vos propres données

Réservez une démo gratuite et apportez le rapport qui vous pose le plus de problèmes.

Réserver une démo gratuite

Trois étapes vers des chiffres qui concordent

  1. Extraire la logique existante

    Rassemblez les calculs, jointures et filtres qui vivent aujourd’hui dans vos rapports.

  2. La centraliser en un seul endroit

    La logique passe une seule fois dans le modèle du warehouse, et chaque rapport lit la même définition.

  3. Des chiffres qui concordent

    Chaque rapport affiche le même chiffre, et « d’où vient ce chiffre » a une réponse visible.

Comment Datavault Builder fournit à votre rapport un modèle prêt à l'emploi

  • Le modèle arrive prêt à l'emploi

    Datavault Builder génère le vault et le schéma en étoile pour qu’ils s’exécutent nativement dans la base de données dont vous disposez déjà : SQL Server, Azure SQL, Synapse, Fabric, Snowflake, Databricks ou BigQuery.

  • Le travail quitte le rapport

    Pas de fusion, pas de parsing, pas de correspondance approximative. Ce travail a disparu du rapport.

  • Les sources arrivent intégrées

    Les clients de l’ERP, du CRM et de la boutique en ligne sont rapprochés en un seul ensemble de dimensions conformes. La jointure a lieu une fois dans le warehouse, et non à nouveau dans chaque rapport.

  • Un historique interrogeable

    Chaque modification est conservée à son arrivée, vous pouvez donc produire des rapports sur l’état passé comme sur l’état actuel, même lorsque le système source écrase ses propres enregistrements.

  • Chaque chiffre a son lineage

    La logique gagne un lineage, donc « d’où vient ce chiffre » a une réponse visible.

  • Évolutions gérées en amont

    Les dimensions à évolution lente sont gérées en amont sous forme de satellites du vault, pas approximées.

Reconnu par BARC dans The Data Fabric Survey 26

Rencontrez notre expert

Vingt minutes avec notre Sales Director, et une réponse honnête sur l’adéquation avec votre situation.

Matt Collett

Matt Collett

Sales Director

Que recherchez-vous ?

En soumettant, vous acceptez notre Politique de confidentialité.

Autres problèmes traités dans cette série

  • Vos applications Qlik et vos rapports Power BI affichent-ils des chiffres différents ?

    Ni Qlik ni Power BI n’a tort. Chacun a sa propre logique de chargement, ses propres définitions et son propre lineage, donc la même métrique est calculée deux fois et personne ne peut rapprocher les résultats. Les règles ont leur place dans un modèle de warehouse gouverné que les deux outils lisent.

  • Nettoyez-vous les mêmes données dans chaque script de chargement Qlik ?

    Les mêmes MAPPING LOAD, corrections de chaînes et dédoublonnages sont réécrits dans chaque application et chaque couche QVD, et les copies divergent. Le nettoyage est répété script par script parce qu’aucune couche de warehouse intégrée ne le fait une seule fois.

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

    Le Set Analysis est précis pour de vraies comparaisons. La plupart des longues expressions de votre application existent parce que le modèle n’a jamais fourni l’historique, les flags ou une granularité unique, et le graphique les reconstruit donc à chaque sélection.