creation d'un entrepot [Résolu]

[hawat23]

Bonjour,

Je découvre actuellement tout ce qui tourne autour du BI et j'ai la problématique de créer un entrepot pour pouvoir générer des rapports.

J'aimerais que les requetes pour generer les rapports soient tres simple (un minimum ou pas de jointure et pas de calculs dans mes requetes (style group by et sum, ...)).
Par contre ca ne me derange pas qu'il y ait des calculs complexes dans mon ETL pour remplir des colonnes (enfin, si c'est correct de faire comme ca) ou dans une vue de mon entrepot.

Mes rapports a créer contiennent les colonnes suivantes:
- Vendeur
- chiffre d'affaire pour la periode
- progression par rapport a l'annee precedente pour la periode

Les periodes possibles sont:
- jour
- mois
- periode entre deux dates

La periode est un parametre a saisir par l'utilisateur.

J'ai une idée mais elle ne convient pas . La voici:

Ma table de faits contient:
idVente(PK) - Vendeur - nom de la vente - montant total de la vente - date

Dans ce cas je ne vois pas ce que pourrait contenir ma table de dimension. En effet, la dimension date est dégénérée dans ma table de fait.

Ensuite, lors de ma creation de rapport je requete sur mon entrepot et je calcul dans cette requete la progression par rapport a la periode rentrée par l'utilisateur.

Probleme: Dans cette solution il faut créer des requêtes assez complexes dans la generation de mon rapport (j'utilise Jasper). Ca me plait pas du tout vu qu'un utilisateur non informaticien doit etre capable de comprendre ces requetes pour creer d'autres rapports dans le meme style

Est-ce que vous auriez une solution qui permet de simplifier les requetes (en déportant par exemple la complexité dans des vues ou autres solutions)?
Autre idée, est ce que ca se fait de faire des calculs complexes lors de l'utilisation d'un ETL. Dans ce cas il y a peut etre une solution pour déporter la complexité coté ETL.

J'ai l'impression que le probleme est que l'utilisateur peut saisir 2 dates afin de generer son rapport. ca empeche tout calcul generique sur lequel je pourrais me baser pour faire mes rapports.
Par exemple si je devais juste afficher le chiffre d'affaire par mois et par trimestre, il serait simple de faire le calcul en amont. Dans mon cas, comment faire?

Merci d'avance pour vos reponses,

Chris

[Jean_Paul_XX]

Bonjour,

Je reprends si vous permettez votre post pour tenter de reformuler votre besoin :
Dans l'idéal votre configuration est la suivante.
Vos dimensions utiles :

• Temps (Année / Trimestre / Mois / Semaine / Jour)
• Vendeur (Agence / Vendeur)
• etc...

Les mesures souhaitées :

• CA
• Evolution % A/A-1
• Eventuellement Nbre de ventes
• etc...

Les filtres préalables à la consultation :

• Un vendeur
• Une période (date à date)

A partir de ces éléments, vous pouvez mettre en place une structure multi-dimensionnelle simple, qui exprimera vos différentes mesures au sein de votre référentiel de dimensions. La structure peut être physique (M-OLAP), ou bien logique (R-OALP).
Ce choix doit être validé en tenant compte de :

• La granularité (finesse) de restitution désirée et par voie de conséquence,
• La volumétrie de vos données.
• Le nombre d'utilisateurs consultant le cube décisionnel.
• Votre infrastructure technique et ressources matérielles.
• etc ...

En d'autres termes, la construction de votre entrepôt de données est une confirmation du choix du mode de restitution choisi. Pour schématiser, dans un cas vous charger l'entrepôt de données et soignez la procédure d'alimentation, dans l'autre vous chargez l'outil de BI choisi et apportez des transformations simples aux données interrogées. Vous pouvez bien entendu, combiner les deux aspects.


En ce qui concerne la possibilité pour des utilisateurs non-informaticiens de s'approprier les requêtes, je comprends votre désapprobation à priori.
L'expérience prouve que les utilisateurs se répartissent en 3 catégories distinctes :

• Le 1% qui va effectivement rentrer conceptuellement dans la solution décisionnelle Concevoir des requêtes (profil technicien ou key-user)

Les 99% restants se répartissent en :

• Consommateurs qui naviguent au travers des rapports fournis,
• Utilisateurs qui valorisent les filtres, modifient l'aspect d'un rapport, rajoutent éventuellement une colonne... tout ceci sans toucher à la 'mécanique' de la requête (groupages, agrégations ...)

Dans votre cas, il me semble que les besoins se situent plus sur la troisième catégorie. Oubliez-donc la partie technique qui ne doit théoriquement pas les impacter.


Espérant répondre à vos attentes,

[hawat23]

Merci pour votre réponse. Apres avoir comparé les possibilités je vais plutot partir sur du ROLAP, c'est à dire sgbd relationnelle + requetes SQL.

Peux-tu me valider la cohérence de mon modèle?

L'entrepot:

Table de fait de vente:
- idVente (PK)
- montant
- id_vendeur (FK)
- id_agence (FK)
- id_produit (FK)
- date

Table Vendeur:
- id_vendeur
- nom
- prenom

Table Agence
- id_agence
- nom
- departement
- etc...

Table produit
- id_produit
- nom_produit
- famille_produit

Vue magasin1 (base du premier rapport):
- id_vendeur
- nom_vendeur
- prenom_vendeur
- montant_vente
- nom_produit
- date

Vue magasin2 (base du deuxieme rapport):
- id_agence
- nom_agence
- montant_vente
- date

Voilà, je m'arrete là pour le principe.

En fait j'ai l'impression de refaire du relationnel pour l'entrepot. Je pense faire comme ça afin de gérer les "evolutions lentes" des dimensions produit, vendeur et agence.
En effet, si on prend par exemple la table vendeur, si le nom du vendeur change (femme qui se marie) alors je trouve ca simple de juste changer le nom dans une table lié à la table de fait par une foreign key.

Ensuite pour les magasins, il me serve à eviter de devoir gérer les jointures dans mes requete SQL.

Enfin, Tous les calculs complexes seront dans mes requetes SQL (comme Evolution % A/A-1).

Qu'est ce que vous en pensez? Quels sont les defauts?

Merci d'avance,

Chris

[yphilogene]

Envoyé par hawat23

En fait j'ai l'impression de refaire du relationnel pour l'entrepot.

Les termes "relationnel" et "dimensionnel" sont parfois utilisés pour exprimer différentes idées, à tel point qu'il faille à chaque fois préciser de quoi on parle.

Tel que je le comprends lorsque je vous lis, par "relationel" vous entendez tables et jointures comme il en existe dans des systèmes transactionnels. Dans un entrepôt de données, selon Ralph Kimball, le best practice est de construire des tables en les organisant suivant une structure en étoile: une table de faits au milieu, et les tables de dimensions gravitant autour. Cette structure peut se complexifier avec l'ajout d'une deuxieme table de faits et le partage des tables de dimensions communes. C'est ce qu'on appelle faire une modélisation en étoile ou encore faire une modélisation "dimensionnelle".

Donc, pour moi, votre modélisation suit parfaitement ces recommandations. Vous modélisez de façon dimensionnelle, mais techniquement, ça reste des tables et des jointures.

Le but de l'ETL est de transporter vos données de vos tables sources vers vos tables de votre entrepôt. Il est donc évident que la majeur partie de l'intelligence se situe dans les processus ETL. Personnellement, je préfère prémâcher le travail dans l'ETL et faire ensuite des requêtes simples et rapides, plutôt que me contenter du minimum dans l'ETL pour ensuite faire des requêtes avec calculs (le langage SQL n'est pas adapté aux calculs, ce n'est que mon avis).

Enfin, plus vous serez amené à faire des rapports avec des croisements et calculs complexes, plus l'utilité d'un cube vous semblera évidente. Heureusement, les technologies B.I. actuelle propose des outils de modélisation de type cube sans pour autant avoir à en générer. Je connais le DMR chez Cognos par exemple.

J'aimerais bien connaître les équivalents chez la concurrence si certains d'entre vous ont envie d'en parler.

[Jean_Paul_XX]

Bonjour à tous et à toutes


hawat23 : Ton modèle de données semble logique. Cependant, je ne comprend pas très bien la nécessite des vues 'Magasin'. Si le but recherché, est de permettre une certaine 'historisation' liée à l'évolution des dimensions (exemple cité du nom de la femme qui se marie), alors dans ce cas, plusieurs techniques peuvent être également utilisées :
- Intégrer les informations nominatives dans la table de faits (étant donné sa 'simplicité'), sous forme de libellé court (ex : formuler une PK sous la forme Id vendeur + un nom court sur 20 car), Idem pour l'agence et le produit.
- Fixer une contrainte ne permettant pas l'altération d'un couple Id_vendeur/Nom vendeur en amont ...
- etc ...
Cela dépend de ta volumétrie et de la fréquence de changement des valeurs de tes dimensions.
Si aucune historisation n'est nécessaire, alors dans ce cas, la mise en oeuvre de tes vues est inutile.

Une remarque sur les comparaisons A/A-1. Là également, plusieurs possibilités dépendant de ta config et sollicitant soit la base de données, soit le moteur de requêtes. Dans le premier cas, il s'agit de mettre en place des requêtes imbriquées, dans le second de travailler sur le dataset renvoyé par la requête.


Tout ceci mis à part, bonne mise en oeuvre !
Au fait, quel est ton environnement (OS, Base, requêteur ...) ?


yphilogene : (joli prénom...)
LE DMR Cognos me semble être fortement aparrenté à un modèle R-OLAP, non ?
Deux autres éditeurs sont spécialisés dans cette technologie : Microstrategy (un pionnier historique), et Latitudes-bi (plus récent, à la techno web).

JPP

[yphilogene]

Envoyé par Jean_Paul_XX

yphilogene : (joli prénom...)
LE DMR Cognos me semble être fortement aparrenté à un modèle R-OLAP, non ?
Deux autres éditeurs sont spécialisés dans cette technologie : Microstrategy (un pionnier historique), et Latitudes-bi (plus récent, à la techno web).

Le DMR de Cognos est du R-OLAP. Il permet de construire un modèle de données qui s'utilise comme un cube sans pour autant en créer. Dans la pratique, il faut construire un modèle relationel (vues de tables et jointures), puis on rajoute une couche par dessus, avec des "objets dimensionnels".

J'ai regardé un peu les démos de Microstrategy... Les outils de tous les éditeurs commencent franchement à se ressembler! Pourvu que Cognos/IBM ne s'égare dans cette mode du Flash dans les rapports qui semble se répandre...

[hawat23]

Finallement j'ai opté pour un entrepot sans magasins.
Mes requetes SQL sont un peu complexe mais définir des vues ne simplifier pas grand chose.

Pour mon environnement, c'est spagobi, jasper report et postgres.

En tout cas, merci pour votre aide. Ca m'a permit de voir que j'etait plutot dans le vrai

[hawat23]

Oui c'est bon. Mais comment conclure? On peut changer l'etat de la file de discussion?

[Fleur-Anne.Blain]

Vous disposez d'un bouton en bas de votre discussion

Envoyé par hawat23

Oui c'est bon. Mais comment conclure? On peut changer l'etat de la file de discussion?