Qlik Community

Groupe des Utilisateurs Francophones

Vous êtes francophone? Ce groupe est pour vous. Venez découvrir comment démarrer avec Qlik Sense et QlikView, poser vos questions et partager vos tutos et astuces avec les membres de notre communauté.

Highlighted
Not applicable

Contexte de dates

Bonjour,

Je suis en développement d'une application et je rencontre un problème avec des contextes de temps différents dans mon modèle.

Le modèle rend compte de l'activité d'étude/octroi/décision de cartes de fidélité ainsi que des financements/commandes effectuées avec ces cartes.

J'ai donc des tables de faits :

- une table des demandes/etudes

- une table des décisions finales d'octroi

- une table des incomplets (une étude renvoyée par le client mais dont il manque 1 élément avant de donner la décision)

- une table des financements

J'ai des tables de dimensions :

- une table Temps étude

- une table temps incomplet

- une table temps décision

- une table financement

J'ai une table de liaison :

Entre ma table étude et ma table financement car toute les cartes qui font des achats ne sont pas forcément répertoriées dans la tables des études (cartes trop ancienne et dont on a pas repris l'historique de leur création)

Mon soucis :

J'ai plusieurs contexte de temps différents (temps études, temps décision, temps incomplet éventuel, temps financement). Si j'essaie de faire un seul et même tableau où je veux avoir en dimension une unité de temps (par exemple 12 mois d'une année) et en éléments de faits les études, les ouvertures, les financements, j'ai des problèmes.

En effet, si j'utilise le temps étude, il ne va me sélectionner que les décisions et les financements issues de ces études (ça peut-être utile dans une vision générationnelle mais pas pour mon cas)

Il me faudrait une sorte de "temps générique", qui prendrait bien de manière non obligatoirement liée, ces faits. Su un mois précis, je peux avoir X demandes, Y ouvertures, Z financements sans qu'il y ait forcément un lien de cause à effet entre ces faits (les ouvertures faites dans un mois ne proviennent pas forcément des études du même mois et les financements peuvent même provenir d'études non répertoriés car trop ancienne).

Avez-vous déjà été confrontés à ce genre de soucis.

Je vous joint un exemple fort réduit de mon modèle, que j'ai rendu "anonyme", afin de mieux expliquer mon soucis.

Merci d'avance.

12 Replies
martin59
Valued Contributor II

Re: Contexte de dates

Bonjour,

Vous êtes face à un problème assez récurrent dans le domaine décisionnel et pas toujours évident.

Il y a plusieurs solutions à cela, selon moi la plus simple serait de passer par un calendrier complétement indépendant du reste.

Pour ce faire, vous devez récupérer tout d'abord la plus petite de toutes vos dates en utilisant les fonctions min(Date) sur chacune de vos tables puis grâce à la fonction RangeMin(MinDateEtude, MinDateDecision, MinDateFinancement, ...).

Vous pouvez ensuite faire de même pour récupérer la date la plus récente en utilisant les fonctions max() et RangeMax() ou la date du jour avec la fonction today().

A partir de là vous pourrez créer un calendrier allant de la plus petite date récupérée à la plus grande avec l'instruction AutoGenerate(). Cette table ne doit être liée à aucune des autres tables de votre modèle.

Une fois construite, les champs de cette table pourront servir de listes de sélections (Mois, Année...) et vous les utiliserez par le biais de vos formules en utilisant le Set Analysis de cette manière sum({<DateFinancement=P(Date)>} MonChamp).

N'hésitez pas si je n'ai pas été assez clair, mais j'espère vous avoir aiguillé quelque peu...

Martin Favier

Not applicable

Re: Contexte de dates

Bonjour,

Je rencontre aussi ce problème actuellement, je me suis permise de tester votre solution dans une petite application faite rapidement dans ce but (et jointe à cette réponse).

J'ai 2 tables de fait : COMMANDE et FACTURE, chacune ayant une date sur laquelle le fait s'exprime (même principe que sroussez donc).

J'ai créé rapidement une table DATE, qui n'est pas un calendrier complet, mais simplement une liste de date. Cette table n'est liée à aucune autre. Est-il important d'avoir un calendrier créé comme vous l'indiquez ?

Ce que je veux tester, c'est afficher mon nb de commandes et mon nb de factures par jour dans un même tableau.

J'utilise en dimension la date générique et en expression la formule de set analysis que vous avez conseillée => j'obtiens par jour le nombre total de commandes et le nombre total de factures, ce qui n'est pas ce que je veux obtenir. Aurais-je fait une erreur dans mes expressions ?

Par contre, quand je sélectionne une date dans la liste de sélection, j'obtiens les bons chiffres (ex pour le 09/09).

Pour remédier à ce problème, j'avais testé d'autres solutions auparavant mais je ne sais pas si elles sont correctes et/ou recommandées :

1) Utiliser un if dans l'expression : =count(if(DATE = DAT_CDE, COUNT_CDE)) => cela fonctionne

Mais je sais que l'utilisation de if n'est pas recommandée dans les expressions au profit du set analysis, car le if peut être moins performant, surtout si l'application contient un nombre important de données ?

2) Passer par une table d'aggrégation qui regroupe tous les faits sur une même date (dans mon exemple, COMMANDE_AGG) : cela fonctionne également

De la même façon que pour le if, si j'ai une application qui contient un nombre important de données, passer par une table d'aggrégation n'est peut-être pas une bonne solution, car elle vient encore augmenter le poids de l'application ?

Merci de votre retour,

J'imagine que mon test et votre retour pourra aussi être utile à sroussez.

Not applicable

Re: Contexte de dates

Je suis absent(e) du bureau jusqu'au 07/11/2012

I am out of the office and get back to you when I return.

Remarque : ceci est une réponse automatique à votre message "[Groupe des

Utilisateurs Francophones] - Re: Contexte de dates" envoyé le 6/11/12

13:55:21.

C'est la seule notification que vous recevrez pendant l'absence de cette

personne.

This message and any attachments (the "message") is

intended solely for the intended addressees and is confidential.

If you receive this message in error,or are not the intended recipient(s),

please delete it and any copies from your systems and immediately notify

the sender. Any unauthorized view, use that does not comply with its purpose,

dissemination or disclosure, either whole or partial, is prohibited. Since the internet

cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS

(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.

Do not print this message unless it is necessary,consider the environment.

martin59
Valued Contributor II

Re: Contexte de dates

Bonjour Amandine,

En effet, selon les cas, une solution sera plus adaptée qu'une autre. Je vais essayer de vous éclairer sur chacun de vos points.

Ce que je veux tester, c'est afficher mon nb de commandes et mon nb de factures par jour dans un même tableau.

J'utilise en dimension la date générique et en expression la formule de set analysis que vous avez conseillée => j'obtiens par jour le nombre total de commandes et le nombre total de factures, ce qui n'est pas ce que je veux obtenir. Aurais-je fait une erreur dans mes expressions ?

Par contre, quand je sélectionne une date dans la liste de sélection, j'obtiens les bons chiffres (ex pour le 09/09).

Le Set Analysis ne prend jamais compte des dimensions d'un tableau ou d'un graphique. Vous ne pourrez donc pas, avoir une dimension (quelque soit son type) et en tenir compte dans votre formule grâce au Set Analysis. La fonction if() pourrait effectivement être une solution dans ce cas...

1) Utiliser un if dans l'expression : =count(if(DATE = DAT_CDE, COUNT_CDE)) => cela fonctionne

Mais je sais que l'utilisation de if n'est pas recommandée dans les expressions au profit du set analysis, car le if peut être moins performant, surtout si l'application contient un nombre important de données ?

Vous avez raison, l'utilisation du if() est vivement déconseillée avec les fonctions d'aggrégation car elle nécessite énormément de mémoire et peut rapidement vous générer des ralentissements notables sur l'application.

2) Passer par une table d'aggrégation qui regroupe tous les faits sur une même date (dans mon exemple, COMMANDE_AGG) : cela fonctionne également

De la même façon que pour le if, si j'ai une application qui contient un nombre important de données, passer par une table d'aggrégation n'est peut-être pas une bonne solution, car elle vient encore augmenter le poids de l'application ?

La table d'aggregat n'est pas la bonne solution car vous dupliquez la donnée pour répondre à un calcul que vous avez imaginé. Et celle-ci ne servira que dans ce cas... Vous ne pourrez pas créé une infinité de tables d'aggrégats si vous souhaitez cette donnée sur d'autres niveaux de détail.

Dans votre cas, la meilleure solution serait de créer une grosse table de fait qui serait la concaténation des deux.

Vous pouvez réaliser cela de cette manière :

Commande_Facture:

LOAD * FROM COMMANDE;

Concatenate (Commande_Facture)

LOAD * FROM FACTURE;

Dans ce cas, vous devez préter attention aux noms de vos champs, les champs indiquant la même donnée doivent porter le même nom.

Le champ Date doit également porter le même nom, que l'on soit sur une date de facture ou une date de commande.

Lorsque vous serez sur des données de commande, les champs spécifiques à la facturation seront nuls, et inversement.

Au niveau de la compression des données, les champs portant le même nom seront compressés encore plus finement que s'ils étaient dans deux tables différentes.

J'espère vous avoir aidé et être assez clair.

Martin Favier

Not applicable

Re: Contexte de dates

Je suis absent(e) du bureau jusqu'au 07/11/2012

I am out of the office and get back to you when I return.

Remarque : ceci est une réponse automatique à votre message "[Groupe des

Utilisateurs Francophones] - Re: Contexte de dates" envoyé le 6/11/12

15:15:40.

C'est la seule notification que vous recevrez pendant l'absence de cette

personne.

This message and any attachments (the "message") is

intended solely for the intended addressees and is confidential.

If you receive this message in error,or are not the intended recipient(s),

please delete it and any copies from your systems and immediately notify

the sender. Any unauthorized view, use that does not comply with its purpose,

dissemination or disclosure, either whole or partial, is prohibited. Since the internet

cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS

(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.

Do not print this message unless it is necessary,consider the environment.

Employee
Employee

Re: Contexte de dates

Bonjour Amandine,

Je prend en route votre échange avec Martin Favier.

Votre problème à la base est plus fonctionnel que technique et somme toute assez classique : quel vision doit-on adopter sur des données commerciales (commandes) et/ou comptables (factures), sachant que selon l’un ou l’autre cas la vision n’est pas la même et qu’on veut pouvoir suivre les 2 en parallèle? En effet, toute commande n’est pas facturée à la même date. Donc comptabiliser le nombre de commandes et de factures par jour revient à considérer une échelle de temps « absolu » sur laquelle on va positionner des dates de commandes et des dates de factures, même si ces 2 écritures n’ont pas de rapport direct entre elles pour la raison évoquée précédemment.

Quand on va être confronté à cette situation, plusieurs problèmes surviennent alors :

- On a 2 tables de faits : des commandes et des factures. On veut pouvoir comparer les 2 et voir leur évolution sur l’espace temps. Quel axe temps choisir ? Celui de la commande ou celui de la facture ?

- On a les mêmes dimensions rattachées aux 2 tables de faits. Comment gérer cette situation, QlikView n’acceptant pas les modèles en boucle (exemple, la dimension produit est rattachée à la table des commandes et la même dimension produit est rattachée à la table des factures. S’il en va de même pour toute autre dimension comme le temps, cela produit une boucle et une erreur au chargement dans QlikView)?

Plusieurs réponses sont alors possibles. Martin les a évoquées au travers des formules et des regroupement de tables de faits.

o On privilégie un métier au détriment de l’autre : Si votre besoin correspond à une vision de performance commerciale, c’est la commande qui fera référence. Sinon, s’il s’agit d’une vision comptable, c’est la facturation. Dans le cas de la performance commerciale, on rattacherait la table de la dimension Temps à la date de commande et les données de facturation ne deviendraient plus qu’un critère d’analyse complémentaire. Dans cette situation, on peut alors conserver 2 tables de faits distinctes, rattachées entre elles par une clé de jointure QlikView telle que par exemple, un numéro de facture inséré dans chaque ligne de commande. Les tables de dimension y compris l’axe temps, sont alors toutes rattachées à la table de faits des commandes. La deuxième table de faits est rattachée à la première par la clé et elle est souvent réduite à sa plus simple expression tel qu’un montant, une date, un mode de facturation, etc. Cette situation privilégie le métier mais ne permet pas de comparer à périmètre de temps constant un montant ou un volume de facturation et un montant ou un volume de commande(s). On évite le piège des modèles en boucle.

o S’il ne s’agit ni de l’un ni de l’autre mais simplement de vouloir évaluer un volume ou un montant de commandes et de factures qui n’ont pas de rapport précis sur un axe temps « absolu », la meilleure solution consiste alors à fusionner les 2 tables de faits par simple concaténation. Cela correspond à la dernière réponse de Martin Favier. Ceci est assez surprenant quand on commence à utiliser QlikView parce que notre manière de raisonner est héritée des environnements relationnels. On ne mélange pas les choux avec les carottes. Mais QlikView est une base de données vectorielle. Donc il ne conservera que les valeurs distinctes sur les champs et reconstruira les relations entre champs par des jeux de vecteurs (pointeurs) dans sa mécanique interne. Ceci sous-entend qu’on peut très bien fusionner des tables qui n’ont pas les mêmes champs sans aucun excédent notable de volumétrie et en garantissant des performances optimales. C’est très puissant parce qu’on peut comparer alors des choux avec des carottes en utilisant les mêmes critères de sélection. In extenso à cette méthode, on utilise aussi la notion de table de liens permettant par exemple de relier des tables de faits qui n’ont pas les mêmes champs et des niveaux de granularité différents. Mais avec le recul, on a parfois des problèmes de performance en forte volumétrie sur cette dernière méthode. Dans ce cas, et pour revenir à notre problème de base lié à un espace temps commun, on chargera les commande et les factures dans la même table de faits (load * from commande ; concatenate load * from factures en renommant la date de commande et la date de facture en un seul champ date. La dimension temps est alors rattachée à ce champ date. Pour un point de temps donné, vous aurez donc toutes les comptabilisations de commandes et de factures qui vous intéressent même si elles n’ont pas de lien entre elles si ce n’est la date (ce ne seront pas forcément toutes les factures de la même commande si on ne facture pas tout à la même date).

Cdt.

Christophe Jouve

Pre-sales solutions consultant

Direct: +33 1 55 62 65 54

Mobile: +33 6 76 24 22 47

Email: Christophe.Jouve@qlik.com

QlikTech France

93 avenue Charles de Gaulle

92200 Neuilly sur Seine

qlik.com<http://www.qlik.com/>

18 octobre 2012 | De la Business Intelligence à la Business Discovery...

http://www.qlikview.fr/BDWT-Paris

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

Not applicable

Re: Contexte de dates

Je suis absent(e) du bureau jusqu'au 07/11/2012

I am out of the office and get back to you when I return.

Remarque : ceci est une réponse automatique à votre message "[Groupe des

Utilisateurs Francophones] - Re: Contexte de dates" envoyé le 6/11/12

16:47:06.

C'est la seule notification que vous recevrez pendant l'absence de cette

personne.

This message and any attachments (the "message") is

intended solely for the intended addressees and is confidential.

If you receive this message in error,or are not the intended recipient(s),

please delete it and any copies from your systems and immediately notify

the sender. Any unauthorized view, use that does not comply with its purpose,

dissemination or disclosure, either whole or partial, is prohibited. Since the internet

cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS

(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.

Do not print this message unless it is necessary,consider the environment.

Not applicable

Re: Contexte de dates

Bonjour,

Merci pour toutes ces réponses.

En effet, le cas d'Amandine est un peu une synthèse de ma problèmatique et ses questions comme vos réponses sont fort intéressantes.

Mais ce sont vos propos, Mr Jouve, qui m'ont interpellés et je suis d'accord avec vous, c'est plus un problème fonctionnel à la base que technique.

Ceci m'amène donc à mieux préciser justement le contexte dans lequel s'applique mes données et le besoin de mes utilisateurs pour mieux poser ma question.

On pourrait résumer l'activité que je dois suivre à 2 macro process :

- un macro process de demande :

il rend compte d'une demande initiale et de son déroulé jusqu'à une décision finale. Cette activité se décline donc via des données de dimensions diverses :

- temporelles : date étude - date éventuel d'un incomplet - date d'une décision

- de produit :

- de canal : c'est le vecteur (magasin - internet etc..) où est faite la demande

- de lieu : quel magasin, quel région, quelle ville etc...

- un macro process de financement :

il rend compte de l'activité de financement des cartes de fidélité. Cette activité se décline donc via des données de dimensions diverses :

- temporelles : date du financement

- de produit :

- de canal : c'est le vecteur (magasin - internet etc..) où est faite le financement

- de lieu : quel magasin, quel région, quelle ville etc...

Les besoins de mes clients internes :

Suivre l'activité de ces 2 process par (entre autres) le biais des dimensions précédemment citées

ET NON PAS suivre l'activité d'une carte de fidélité bien précise.

C'est quelquechose de très important. En effet, une carte bien précise, peut être ouverte à une date précise, sur un produit précis, via un canal déterminé, dans un magasin déterminé et ensuite faire ses financements sur de multiples dates différentes, sur de multiples canaux différents (une carte ouverte en magasin peut financer sur le web etc..), dans des lieux différents (carte ouverte dans un magasin et faisant ses commande ensuite dans un autre)

On va bien donc suivre les éléments caractéristiques des 2 macros process (notion de demande, notion d'incomplet, notion de décision, notion de financement)

en les enrichissant avec des éléments de dimensions.

J'aurais donc tout aussi bien à avoir à faire un tableau du type :


J-1Mois en coursMois M-1Année en coursAnnée A-1Projection à fin d'année sur base de la production des 6 derniers mois glissants
Demande




Acceptation




Financement


que


JanvierFévrierMarsAvrilMaiJuinJuilletAoûtSeptembreOctobreNovembreDécembre
Demande










Acceptation










Financement








en pouvant enrichir ces visions par une sélection d'une offre produit bien déterminée, d'un canal déterminé, d'un magasin déterminé, d'un commercial déterminé etc...

C'est une analyse PHOTOGRAPHIQUE des données. Je regarde des faits donc le lien principal est l'aspect TEMPOREL, sans forcément un lien de causalité entre eux. Une ouverture d'un mois donné peut provenir ou non d'une demande faite ce même mois et un financement peut provenir d'une acceptation faite l'année dernière.

Mais je peux également à avoir à faire une analyse de l'efficacité d'un process via une vision GENERATIONNELLE de l'actvité :


JanvierFévrierMarsAvrilMaiJuinJuilletAoûtSeptembreOctobreNovembreDécembre
Demande










Acceptation










% acceptation







Ici je regarde l'activité en fonction d'UN SEUL CONTEXTE TEMPOREL. La base est la période de demande et ensuite je lie tous les évênement qui ont ce contexte (par exemple toute les acceptations dont la date d'étude est comprise dans cet intervalle de temps)

Donc ceci m'amène à vos propos :

Comment puis-je, dans un même modèle, exprimer des contextes de temps qui sont basés sur une notion "générique" temporel ou sur une notion d'un contexte précis ?

Est-ce, Amandine, de votre côté, des besoins similaires ? Nos actvités me semblent assez proche.

De manière générale, je penses que c'est une problèmatique qui doit se présenter assez souvent non ?

Merci d'avance pour votre aide.

martin59
Valued Contributor II

Re: Contexte de dates

Bonjour,

Dans le cas que vous décrivez ci-dessus, ma proposition de réponse avec la concaténation des deux tables devrait bien fonctionner.

L'avez-vous essayé ?

Prenez surtout bien soin à renommer vos champs de la même manière entre la table des commandes et celles des factures (en particulier le champ date).

Martin Favier