Recherche de cours detaillé sur la BI

[Melvine]

Salut,

Je recherche un cours détaillé voir un bouquin sur la BI (pas forcement le bouquin de ralph Kimball, j'ai l'impression qu'il est trop orienter à
l'americaine, avec des exemples ,qui ne me parle pas forcement).

Ce que je recherche,c'est l'aspect conception,
les tables de dimension ?
par exemple la dim_temps, que contient elle,
toute les dates du calendrier ?toutes les plages horaires ?

La table de fait ,
contient elle une clé primaire ?
je pense que oui,sinon comment historiés le même produit

Qu'est qu'une ligne dans la table de fait ?
si par exemple nous avons un datamart sur les ventes de produit

Keyfact,idproduit,idtemps,quantité, ???
j'ai du mal à voir le lien entre les dimension et les indicateurs de la table des fait ?
est-ce que dans c'est au moment d'extraire les donnes,
qu'on aggrege et calucul le total des ventes,le ca
ou alors cela est stocké dans la table des faits ?

Si une âme charitable pouvait m'aider,
m'orienter

Merci.

PS : j'ai regarder sur le site,
les cours sont trop théorique,
on n'aborde jamais ces aspects,
il n'y a pas de cas pratique

[Feyrehr]

Bonjour,

Pour ce type de demande, je te conseille de demander à ton moteur de recherche préféré :
- Les livres blancs (réalisés par des sociétés de service, souvent markétés, mais bien documentés)
- Les mémoires et rapports universitaires (parfois trop théoriques ou 'idéalistes')

exemple pris au hasard sur le net :
http://alma.univ-nantes.fr/promotion...rancheteau.pdf

Le plus dur, c'est de bien identifier un juste un fait.

Et pour la demande sur les dates, effectivement avoir un calendrier complet est mieux, si tu dois gérer les jours fériés, ou des contraintes internationales. Mais ca prend du temps à renseigner.
Tout dépend de ton besoin.

[Melvine]

merci
c'est un peu plus concret
mais ça ne repond pas à toutes mes questions,
un cas simple
je veux analyser les ventes des commerciaux
donc j'aurai un table de fait
qui contiendra comme clé de dimension,
id ventes,id client,id produit,id date,id vendeur,id region
et comme fait
je souhaiterai mesurer les ventes par produit,par client,par région
les ventes par commerciaux,
les meilleurs vendeur par produit,client,régions

et ce qui m'intrigue
c'est quel fait j'aurai
les données je les aggrege au moment de l'alimentation de la table des fait ?
ou au moment de la realisation des rapports ?

si un vendeur à vendu deux produit à deux client
donc j'aurai dans la table des faits deux ligne ?
et donc si je souhaite la total de vente de ce vendeur ;
je l'aurai dans la table des faits ?
pour chacune des lignes ?

[Feyrehr]

Le principe, c'est qu'il faut éviter la transformation des données, et notamment, l'agrégation dans le DW. Il faut considérer l'information à son degré le plus fin (la granularité) et partir de cette base pour déployer sur les dimensions.
Le fait que tu demandes, serait 'suivi des ventes', éventuellement, 'suivi des factures'. Dans ce dernier cas, le niveau le plus fin, c'est la ligne de facture.

Pour revenir à la question, tu n'agrèges rien dans ta base. C'est l'outil de reporting ou d'analyse qui le fera. L'interêt de ces outils, c'est de basculer de dimension : suivi par vendeur, par région, par date, par produit, etc...

Pour te rendre compte par toi-même, va sur le site de QlikView. Ils ont une partie démonstration. Tu comprend alors le principe du fait, des dimensions, des axes, des hiérarchies, etc.

[kalyparker]

Pour revenir à la question, tu n'agrèges rien dans ta base. C'est l'outil de reporting ou d'analyse qui le fera. L'interêt de ces outils, c'est de basculer de dimension : suivi par vendeur, par région, par date, par produit, etc...

ça dépends, si la granularité la plus fine contient quelques milliards de lignes, je ne suis pas sure que tu ai le courage d'attendre que ton outils de restit te ramène ton résultat
C'est là que les tables d'aggregats entre en jeux

Mais pour revenir au sujet, je suis d'accord avec Feyrehr sur le fait que tu devrais récupérer quelques livres blanc.
La conception d'un data warehouse n'est pas quelques choses qu'on apprend en 5'
Kimball et Inmon ont posé les bases et présentent 2 philosophies différentes, après l'implémentation d'un dataware va dépendre de l'entreprise, du contexte et du besoin !

Sinon tu as toujours quelques tutos qui sont dispo sur le site, même si certains ont quelques années, la philosophie reste la même

[Melvine]

ok
donc ce qui signifiai que j'aurai autant de ligne que de ventes pour un produit dans la table de fait + les infos concernant le vendeur ,la région sur la même ligne

et c'est qu'une fois le rapport fait que je vais agréger les données dans ma requête