topic Re: modélisation en flocon in Francophones

modélisation en flocon

Thu, 16 May 2013 17:28:18 GMT

Bonsoir ,

est ce qu'il y a un inconvénient d'utuliser la modélisation en flocon sur Qlikview ???

Merci d'avance

Re: modélisation en flocon

Wed, 22 May 2013 09:00:19 GMT

Bonjour Chma9ma9,

D'après "Qlikview 11 for Developers" les inconvénients de la modélisation en flocon sont les suivants :

- temps de réponse moyen

- modèle peu flexible

- complexité du script

J'ajouterai :

Chaque relation entre deux tables va ajouter un certain temps de réponse. Plus vous aurez de liens moins le temps de réponse sera optimal. De plus, avec un schéma en étoile vous risquez de rencontrez des problèmes de boucle à chaque ajout de nouvelle table au modèle.

Cordialement,

Benoit

Re: modélisation en flocon

amauryviseo — Wed, 22 May 2013 09:43:31 GMT

Bonjour à vous deux,

Je ne partage pas totalement l'avis du bouquin "Qlikview 11 for Developers"

Que le modèle en flocon donne un temps de réponse moyen voire catastrophique quand on possède des tables de faits très volumineuses, et quand la profondeur de l'arbre associatif est profond on sera tous d'accord là dessus

Le modèle en étoile (de mon point de vue) a 2 intérêts majeurs :

1) Permettre de gérer une (très) grosse volumétrie en utilisant une table de faits dite "centralisée"

2) Projetter plusieurs axes (de temps notamment) sur le même...On peut ainsi facilement mixer des indicateurs avec le même axe temps

Je ne vois pas pourquoi un modèle en flocon ne serait pas flexible...Il est au contraire beaucoup plus proche du modèle dit "fonctionnel", permet de mieux voir les associations entre tables...

Si le bouquin veut dire par là que cela peut plus facilement créer des boucles dans le modèle...La réponse est OUI...Mais ce sont des rares cas...Au contraitre l'ajout d'un attribut est simplifié, rapide dans un modèle en flocon il suffit de le rajouter dans le LOAD

Ce qu'on oublie trop souvent dans ces préconisations (alors que c'est le fondement même de QlikView !) c'est que ces deux modèles ne permettent pas de répondre aux mêmes questions... Et cela est dû à l'associativité, à la relation entre les données (Je peux donner des exemples simples pour lllustrer mes propos)

De plus un modèle en étoilé a l'énorme inconvenient de mettre au même niveau toutes les données perdant ainsi les hierarchies entre les dimensions et les faits !

Donc oui il faut garder dans la tête qu'un modèle en étoile répond aux problématiques de volumétrie...C'est donc plutot un datamodel de compromis car l'exploration de données reste simplifiée (dans le sens limitée)...Dans ce cas privilégier un modèle en flocon mais le temps de réponse et la mémoire prise (si la volumétrie est élevée)

En esperant ne pas avoir apporté de la confusion..

Re: modélisation en flocon

Wed, 22 May 2013 12:02:04 GMT

Amaury,

Je pense que nous sommes d'accord.

Les points :

- modèle peu flexible

- complexité du script

Font référence au problème des boucles dans le modèle.

Je ne vois pas pourquoi un modèle en flocon ne serait pas flexible...Il est au contraire beaucoup plus proche du modèle dit "fonctionnel", permet de mieux voir les associations entre tables...

Je pense que le modèle flocon est plus simple à construire mais aussi à comprendre car il est plus proche du modèle fonctionnel.

Mais lorsque les problèmes de boucles apparaissent le modèle devient très vite plus complexe.

Re: modélisation en flocon

Anonymous — Tue, 11 Feb 2014 14:24:44 GMT

Bonjour à vous tous,

De mon point de vue personnel, la fléxibilité d'un modèle que ça soit étoile ou flocon dépend surtout de comment le modèle a été construit (type des clès primaire, volumétrie ...) avec un avantage bien sûre pour le modèle en étoile.

Dans le décisionnel, il est préférable de faire un modèle en étoile au lieu du flocon, Le flocon c'est quand on veut analyser plus d'un fait en même temps.

Sur Qlikview, un modèle avec des boucles est un modèle mal fait tout simplement.

Re: modélisation en flocon

Tue, 11 Feb 2014 14:46:37 GMT

Il y a beaucoup de batailles de chapelle. QlikView permet beaucoup de modélisations possibles.

En flocon: il y aura moins d'utilisation mémoire mais plus de liens.

Les liens: ils sont efficaces dans QV (réalisés via les pointeurs et non les clefs qu'on nous oblige à mettre entier)

Résultat: on trouve de tout dans la communauté. Certains vont dire (pas plus de 2 ou 3 jointures, certains vont militer pour un modèle aussi normalisé que possible)

Je pense qu'il faut que ton modèle donne des résultats justes !! Et ce n'est pas flocon ou étoile qui fera la différence.

Fabrice

Re: modélisation en flocon

martin59 — Wed, 12 Feb 2014 20:18:51 GMT

Complètement d'accord avec Fabrice !

Il faut éviter de se faire des nœuds au cerveau pour des broutilles.

Le tout est de trouver le bon équilibre entre ses propres compétences, le temps de développement et la complexité à maintenir.

Si vos résultats sont justes avec un bon temps de réponse, il ne faut pas chercher plus loin

Martin Favier

Re: modélisation en flocon

septo888 — Thu, 13 Feb 2014 10:58:56 GMT

Personnellement quand je démarre une application je ne me pose jamais la question de savoir si je vais me lancer dans une modélisation en flocon ou en étoile. Je charge simplement mes tables, je fais mes associations et jointures. Cette façon de faire va en principe me créer une modélisation en flocon. Mais progressivement à force d’enrichir mon script et de contourner les boucles je me retrouve très souvent avec au final une modélisation en Etoile. Celle-ci se forme petit à petit et naturellement.

Re: modélisation en flocon

Thu, 13 Feb 2014 11:11:38 GMT

Bonjour à tous

la modélisation dénormalisée en étoile est la base de tout modèle BI traditionnel

mais avec QV la non-dénormalisation rigoureuse ne pose pas de pb dû au fonctionnement associatif de QV et on peut donc trouver des mesures dans les tables de dimension.

On reste assez proche du modèle "normal"

Alors flocon ou étoile est largement dépendant des besoins des utilisateurs.

Pour ma part j'utilise toujours une table centrale (comme une table de faits) où je stocke toutes mes clés qui pointent autant vers les dimensions que sur une table (ou plusieurs) de faits

exemple

Christian