Discussion :

[amiraprincesse]

bonjour, possible je ne suis pas au bon forum mais je n'arrive pas a trouver une reponse ailleur et je suis reelement coince.
je suis debutante, je cree mon 1er DW. j'utilise le shemas etoile.et la je suis avec etl. j'ai choisi kettle.
j'ai pu alimente les dimensions. c simple avec extraction et alimentation mais je ne sais pas comment alimenter la table de fait? comment faire les jointure avec les dimension et la table de fait? comment lier table de fait a dimension temps?
svp aidez moi.
merci

[Alexis.Molteni]

Bonjour,

C'est un forum sur les technos Microsoft et Kettle est un ETL open source et je ne suis pas sur que cela soit très proche de SSIS (ETL Microsoft).

Alexis Molteni

[mochi]

Ahla Amira
Ton problème est plutôt d'ordre conceptuel qui n'a pas une relation importante avec la techno que tu utilise pour ton ETL.
Ton problème c'est donc la liaison entre FAIT et DIMENSIONS
Il y a là 2 cas :
- soit tu garde les même clés que la source de donnée dans ce cas il n'y a pas de problème
- soit tu a remplacé les clés fonctionnelles par des clés techniques dans ce cas tu doit faire ce qu'on appelle des "loock up" pour récupérer les clés appropriées

si tu veut décrit moi ton prob avec plus de détails pour pouvoir t'aider

a+

[amiraprincesse]

Ahla Amira
Ton problème est plutôt d'ordre conceptuel qui n'a pas une relation importante avec la techno que tu utilise pour ton ETL.
Ton problème c'est donc la liaison entre FAIT et DIMENSIONS
Il y a là 2 cas :
- soit tu garde les même clés que la source de donnée dans ce cas il n'y a pas de problème
- soit tu a remplacé les clés fonctionnelles par des clés techniques dans ce cas tu doit faire ce qu'on appelle des "loock up" pour récupérer les clés appropriées

si tu veut décrit moi ton prob avec plus de détails pour pouvoir t'aider

a+

merci pour ta reponse, oui effictivement j'ai les mm cles ds dimension et fait mais j'ai cru que malgre sa il faut faire des jointures. on ma repondu nn c bon. mnt j'aimerai trouver un calendrier qui contient date et id pour cree la dimension date. un membre ma envoye un mais y a pas beaucoup de date. si tu peux m'aider sa sera un grand service.

[RobertCrahay]

Bonjour,
un petit commentaire au sujet de l'alimentation d'une table de faits.

Quelle que soit la suite ETL utilisée, il est d'usage de ne pas utiliser la clé opérationnelle comme clé Primaire dans une table de dimension. On crée généralement une clé de substitution sous forme d'un champ INTEGER auto-incrémenté qui sert à faire la liaison avec la table de faits. Cette clé est insérée dans la table de faits au moment de son alimentation. Cela se fait au moyen d'une fonction du genre lookup qui permet de rechercher l'enregistrement courant de la dimension à lier au fait. I y aura donc autant de lookups et d'insertions de la clé de substitution(clé étrangère dans le fait) qu'il y aura de dimensions dans le schéma étoile.
L'enregistrement de la table de dimension devrait en outre contenir un ou des champs permettant de gérer les dimensions changeantes pour le cas ou l'on utilise la techniques SCD2 (date début de validité, date de fin de validité), La fonction lookup sélectionnant l'enregistrement dont la date de fin contient une valeur NULL comme courrant. Cette technique permet de garder la trace des changements dans les attributs des dimensions.

La structure d'une table de faits devrait ressembler à:

Clé primaire Fait
Clé étrangère Dim 1
Clé étrangère Dim 2
...
Clé étrangère Dim n

mesure 1 Fait
mesure 2 Fait
...
mesure N Fait


Remarque: le lookup recherche la clé opérationnelle dans la dimension dont la date de fin de validité est NULL et insère la clé de substituion comme clé étrangère dans le fait.

Cette façon de procéder est conforme à la méthodologie de Ralph Kimball. (voir "Entrepôt de données - guide pratique de modélisation dimensionnelle - Eyrolles).

Voilà, désolé d'avoir été un peu long.

salutations.

Rob

[amiraprincesse]

bonjour, tu n'as pas ete long au contraire merci. mais moi je n'est pas utilise les cle primaire de dimnesions autoincrement, c les cle qui sont ds la base de donnees source, et j'alimente la table de fait de la bd source aussi. est ce que je dois refaire mon travail????????

[RobertCrahay]

Bonjour,
Dans l'état actuel de ma connaissance de la situation, il m'est difficile de déterminer si tout doit être refait ou non. Cela depend de divers facteurs; ampleur du travail déjà réalisé, finalité du projet: exercice ou DW devant être utilisé en production, technologie utilisée pour la base de données source, etc.
Comme le dit Mochi, le projet peut être conservé en l'état mais il ne suivra pas les règles d'usage du data warehousing. En d'autres termes, si l'on s'en tient à la démarche ETL, le E et le L sont pris en compte mais pas le T (Transform) qui permet de s'affranchir de la dépendance au système opérationnel en matière d'intégrité de données et d'invariabilité dans le temps. Dans un datawarehouse, on ne modifie jamais ce qui a été chargé précédemment et l'on n'efface jamais des données.
Pour illustrer ce qui précède, je vais essayer de donner un exemple. Supposons qu'un DW contienne dans une table de dimension "article" un numéro d'article (clé primaire), son coût de revient et son prix de vente. D'autre part imaginons une table de fait "ventes" qui utilise le numéro d'article comme clé étrangère et contienne le numéro de client, la quantité commandée, la date de vente etc.
Si on alimente le DW avec les données du système opérationnel à chaque mise à jour en écrasant simplement les valeurs anciennes et que l'on désire par exemple suivre l'évolution de la marge bénéficiaire brute au cours du temps; un problème de taille surgit, toutes les ventes anciennes vont être évaluées avec les valeurs actuelles contenues dans l'opérationnel. Cela n'a pas de sens car cela ne reflète pas la réalité historique de l'évolution de la marge bénéficiaire et par conséquent le niveau de profitabilité (le rapport entre le coût de revient et le prix de revient peut avoir changé). C'est la raison pour laquelle le data warehouse rompt avec la fameuse loi de la troisième forme normale. l'important n'est pas le gain d'espace de stockage mais l'intégrité historique des données et leur rapidité de consultation sous forme d'agrégats précalculés (raison du star schéma).
A ce stade, il ne m'appartient pas de juger de l'opportunité de tout reprendre à zéro ou non cela va dépendre de la nature des infos traitées dans ton DW et de l'usage envisagé.

NB: En ce qui concerne la dimension temps, bonnes nouvelles, cette dimension peut être créée une fois pour toutes car elle ne varie pas de par sa nature universelle. On peut la créer sous forme de fichier Excel en utilisant les fontions de date de Excel par exemple. La fonction de copie incrémentale permet de générer un fichier couvrant de nombreuses années en très peu de temps. Il suffit alors d'alimenter une table de dimension temps avec.
Pas mal d'outils d'analyse (ex. SSAS de microsoft) proposent une dimension temps avec différentes hiérarchies qui peuvent être utilisées lors de la création des outils de consultation/analyse des données. Cela permet de s'affranchir de la génération de la dimension temps.

Voilà j'espère avoir être été utile, à suivre si nécessaire.
Rob

[amiraprincesse]

merci pour la reponse, concernant mon travail je desir realiser un tableau de bord. j'ai de bases de donnees source . je les ai cree avec mysql, easyphp.
et les tables de dw aussi.
pour etl j'utilise kettle. oui c vrai je croie que j'ai fait fausse route car je perd l'historique en utilisant les cles primaires des bd ds table fait, bon je croie que je vais refaire ce qu'il faut car je n'ai pas beaucoup avancer dans l'alimentation des tables de fait. mais apres avoir corriger est ce que j'alimente la table de fait depuis les dimensions dans ce cas? et comment?j'aimerai connaitre tt les etapes qui me permettent d'alimenter les table de fait.
pour la dimension temps j'aimerai avoir plus de date, tu ma parler d'une application excel, peut tu me la decrire car le calendrier excel que j'ai je l'ai obtenu de quelqu'un.
merci

[amiraprincesse]

bjr,
c bon j'ai pu recuperer tous les champs pour alimenter table de fait mais un probleme je n'arrive pas a faire les calculs, en utilisant les commande de kettle je ne trouve pas de resultat de calcul et avec sql les fct sum et count.. on me dit elles ne sont pas reconu ds le msge d'erreur.
que faire?

[silissou]

Bonjour,
un petit commentaire au sujet de l'alimentation d'une table de faits.

Quelle que soit la suite ETL utilisée, il est d'usage de ne pas utiliser la clé opérationnelle comme clé Primaire dans une table de dimension. On crée généralement une clé de substitution sous forme d'un champ INTEGER auto-incrémenté qui sert à faire la liaison avec la table de faits. Cette clé est insérée dans la table de faits au moment de son alimentation. Cela se fait au moyen d'une fonction du genre lookup qui permet de rechercher l'enregistrement courant de la dimension à lier au fait. I y aura donc autant de lookups et d'insertions de la clé de substitution(clé étrangère dans le fait) qu'il y aura de dimensions dans le schéma étoile.
L'enregistrement de la table de dimension devrait en outre contenir un ou des champs permettant de gérer les dimensions changeantes pour le cas ou l'on utilise la techniques SCD2 (date début de validité, date de fin de validité), La fonction lookup sélectionnant l'enregistrement dont la date de fin contient une valeur NULL comme courrant. Cette technique permet de garder la trace des changements dans les attributs des dimensions.

La structure d'une table de faits devrait ressembler à:

Clé primaire Fait
Clé étrangère Dim 1
Clé étrangère Dim 2
...
Clé étrangère Dim n

mesure 1 Fait
mesure 2 Fait
...
mesure N Fait


Remarque: le lookup recherche la clé opérationnelle dans la dimension dont la date de fin de validité est NULL et insère la clé de substituion comme clé étrangère dans le fait.

Cette façon de procéder est conforme à la méthodologie de Ralph Kimball. (voir "Entrepôt de données - guide pratique de modélisation dimensionnelle - Eyrolles).

Voilà, désolé d'avoir été un peu long.

salutations.

Rob

merciiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

[sofienzioudi]

Créer une table qui alimentera la dimension temps de notre cube.

Ce script (ou genre) est maintes fois disponible sur le Web, mais je le mets ici à disposition de certains de mes participants….

use msdb
go
set nocount on
go

if not exists (select 1 from INFORMATION_SCHEMA.TABLES
where TABLE_NAME = 'DimTemps')
create table DimTemps (
DateJour date,
NoJourSemaine tinyint,
NomJourSemaine nvarchar(20),
NoJourMois tinyint,
NoJourAnnee smallint,
NoSemaine tinyint,
NoMois tinyint,
NomMois nvarchar(20),
NoTrimestre tinyint,
NomTrimestre nvarchar(20),
NoSemestre tinyint,
NomSemestre nvarchar(20),
Annee smallint
)
go


declare @dJour date

set @dJour = CONVERT (date, '01/01/2012',103)
while @dJour <= CONVERT (date, '31/12/2012',103)
begin
insert into [dbo].[DimTemps]
([DateJour]
,[NoJourSemaine]
,[NomJourSemaine]
,[NoJourMois]
,[NoJourAnnee]
,[NoSemaine]
,[NoMois]
,[NomMois]
,[NoTrimestre]
,[NomTrimestre]
,[NoSemestre]
,[NomSemestre]
,[Annee])
VALUES
(@dJour
,DATEPART(dw,@dJour)
,DATENAME(dw,@dJour)
,DAY(@dJour)
,DATEPART(dy,@dJour)
,DATEPART(ISO_WEEK ,@dJour)
,MONTH(@dJour)
,DATENAME(month,@dJour) +' ' + str(YEAR(@dJour),4)
,DATEPART(QUARTER,@dJour)
,'T' + STR(DATEPART(QUARTER,@dJour),1) + ' ' + str(YEAR(@dJour),4)
,case when MONTH(@dJour) between 1 and 6 then 1 else 2 end
,'S' + str(case when MONTH(@dJour) between 1 and 6 then 1 else 2 end,1) + ' ' + str(YEAR(@dJour),4)
,YEAR(@dJour))
set @dJour = dateadd(day,1,@dJour)
end

GO

#######################################################"
tu fais après un:
select * from DimTemps

tu vois que ta table temps est bien alimentée !