12 Replies Latest reply: Mar 26, 2013 8:57 AM by Benjamin DEMOUSTIER RSS

    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.

        • Re: Contexte de dates
          Martin FAVIER

          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

            • 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.

                • 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.

                  • Re: Contexte de dates
                    Martin FAVIER

                    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

                      • 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.

                      • Re: Contexte de dates
                        Christophe JOUVE

                        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.

                          • 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.

                            • 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.

                                • Re: Contexte de dates
                                  Martin FAVIER

                                  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

                                    • Re: Contexte de dates

                                      Merci également pour toutes ces réponses, elles sont très riches en information.

                                       

                                      Je me rends compte à présent qu'il s'agit avant tout d'un problème fonctionnel plus que technique.

                                       

                                      J'ai effectivement des besoins assez similaires à ceux de Mr Roussez, réaliser 2 analyses différentes : l'une en photographique, selon un axe temporel générique (par mois), l'autre en "générationnel", comme le nomme Mr Roussez.

                                       

                                      D'un côté, je souhaite pouvoir mesurer la performance commerciale, selon l'axe de temps des commandes. De l'autre côté, je souhaite pouvoir mesurer chaque fait (les commandes, les factures, etc...) de manière indépendante.

                                       

                                      Comment faire cela au travers d'un seul modèle QlikView ?

                                       

                                      Comme vous me l'indiquez, pour faire une analyse indépendante de mes indicateurs par mois, vous me conseillez de faire une table qui concatène tous mes faits. Effectivement cela fonctionne, je l'ai testé dans mon exemple.

                                       

                                      Mais si je tranforme mon modèle en une seule et unique grosse table, je perds alors la possibilité de faire du générationnel, d'observer tous mes faits par exemple selon le contexte des commandes.

                                       

                                      De plus, la volumétrie engendrée par une seule et même table de faits ne risque-t-elle pas de devenir trop importante à gérer ? J'ai fait un calcul, si je réunis tous mes faits que je désirerais observer sur une même axe temporel, j'arrive à 6 000 000 de lignes sur une année et ceci n'est qu'une estimation... Sur 6 années de profondeur, cela ferait 36 000 000 de lignes dans une seule table, pour QV y aura-t-il un problème de performance ? (pour exprimer les différents calculs).

                                       

                                      Si je ne tiens pas compte de ce problème de volumétrie mais uniquement de mon besoin, faire à la fois du photographique et du générationnel, j'ai l'impression que le modèle d'une seule table unique ne fonctionnerait pas.

                                       

                                      C'est pourquoi j'avais pensé à conserver mon modèle de base, avec les liens "classiques" entre COMMANDES et FACTURES, pour pouvoir faire des analyses selon un contexte précis (commercial, comptable), et avoir des tables d'aggrégation pour pouvoir réaliser mes analyses photographiques.

                                       

                                      Je suis bien consciente que la table d'aggrégation vient dupliquer mes données et qu'il m'en faudra autant que j'aurais de niveaux d'analyse ; mais je ne vois pas comment répondre à mon besoin en faisant autrement, et notamment en passant par une grosse table unique concaténant tous les faits.

                                       

                                      Il est possible que je fasse fausse route, quand pensez-vous ?

                                       

                                      Je pense que ce raisonnement pourrait s'appliquer aussi à l'application de Mr Roussez. Il a besoin des 2 visions également, comment y répondre en 1 une seule table de fait ? Dans son cas, conserver son modèle de base + avoir des tables d'aggrégation ne serait-elle pas non plus la meilleure solution ?

                                        • Re: Contexte de dates
                                          Martin FAVIER

                                          Bonjour Amandine,

                                           

                                          Je vais essayer de répondre à vos questions point par point...

                                           

                                          Mais si je tranforme mon modèle en une seule et unique grosse table, je perds alors la possibilité de faire du générationnel, d'observer tous mes faits par exemple selon le contexte des commandes.

                                           

                                          Logiquement vous ne devriez pas avoir d'impact négatif à ce niveau, veillez bien à ce que vos données identiques entre tables de faits soient bien reprises dans la même colonne en réutilisant les mêmes noms de champs.

                                           

                                          De plus, la volumétrie engendrée par une seule et même table de faits ne risque-t-elle pas de devenir trop importante à gérer ? J'ai fait un calcul, si je réunis tous mes faits que je désirerais observer sur une même axe temporel, j'arrive à 6 000 000 de lignes sur une année et ceci n'est qu'une estimation... Sur 6 années de profondeur, cela ferait 36 000 000 de lignes dans une seule table, pour QV y aura-t-il un problème de performance ? (pour exprimer les différents calculs).

                                           

                                          Pour QlikView, que vos données soient dans plusieurs tables ou une seule, il n'y a pas de différence majeure au niveau des performances. 36 millions de lignes ne me semble vraiment pas énorme à charger, reste à voir votre nombre de champs et la puissance de votre machine cependant...

                                           

                                          Si je ne tiens pas compte de ce problème de volumétrie mais uniquement de mon besoin, faire à la fois du photographique et du générationnel, j'ai l'impression que le modèle d'une seule table unique ne fonctionnerait pas.

                                           

                                          C'est pourquoi j'avais pensé à conserver mon modèle de base, avec les liens "classiques" entre COMMANDES et FACTURES, pour pouvoir faire des analyses selon un contexte précis (commercial, comptable), et avoir des tables d'aggrégation pour pouvoir réaliser mes analyses photographiques.

                                           

                                          Je suis bien consciente que la table d'aggrégation vient dupliquer mes données et qu'il m'en faudra autant que j'aurais de niveaux d'analyse ; mais je ne vois pas comment répondre à mon besoin en faisant autrement, et notamment en passant par une grosse table unique concaténant tous les faits.

                                           

                                          Il est possible que je fasse fausse route, quand pensez-vous ?

                                           

                                          Je pense que vous faîtes fausse route, très rares sont les cas de figures où nous devons utiliser des tables d'aggrégats dans QlikView. Votre problématique est avant tout une problématique métier, je n'ai pas assez de détail pour vous répondre plus précisemment sur la méthode à utiliser.

                                           

                                          Martin Favier

                              • Re: Contexte de dates
                                Benjamin DEMOUSTIER

                                Bonjour,

                                 

                                On doit aussi pouvoir créer un calendrier avec le script ci-dessous et ensuite analyser commande et facture avec la TempDate comme axe pricipal et compter les commande dont la date de commande = tempdate, les factures dont Date de facture=Tempdate,etc...

                                 

                                 

                                Let varMinDate = Num('1/1/2000');

                                Let varMaxDate = Num('31/12/2020');

                                TempCalendar:

                                LOAD

                                $(varMinDate) + Iterno()-1 As Num,

                                Date($(varMinDate) + IterNo() - 1) as TempDate

                                AutoGenerate 1 While $(varMinDate) + IterNo() -1 <= $(varMaxDate);

                                calendar:

                                LOAD

                                YearName(TempDate) as Tempyearname,

                                MonthName(TempDate) as TempMonthname,

                                Month(TempDate) as TempMonths

                                Resident TempCalendar

                                Order By TempDate ASC;

                                 

                                Cordialement