Discussion :

[Borowsky]

Bonjour,

Je suis en train d'étudier les possibilités de Pentaho, j'ai réussi à me créer des rapports et à utiliser la fonction Ad-hoc de la plate forme web avec mes données. J'ai aussi réussi à utiliser Google Map à travers Pentaho.

Maintenant je souhaite essayer de créer des cubes OLAP dans le but de pouvoir analyser des données via des tableaux dynamiques.
Et la je bloque un peu... Mon Datawarehouse est vraiment tout petit (6 tables extraites des tables des bases de production). Mais il est déjà pas construit comme il faudrait... A ce que j'ai vu dans certain document, il faut qu'un datawarehouse contienne une table "centrale" avec toutes les ids des tables qui lui sont raccrochées.

J'ai du mal à savoir comment concevoir ca dans ma tête

Auriez-vous des liens ou documents qui expliquerait comment construire un Datawarehouse correct avec les étapes de la conception ?

Car c'est vraiment une conception différente des bases de données relationnelles... Et ca me perturbe un peu...

Merciii d'avance

[ylarvor]

Un article qui montre la table de fait, les clé étrangère et la table de dimension avec la clé primaire.

http://blog.developpez.com/ylarvor/p...ness/#more8490

Un article qui m'avait plu à l'époque de sa parution :

http://blog.developpez.com/bi/p7422/...imensionnelle/

[Borowsky]

Merci bien, c'est un début

Quel ETL utilises-tu ?

Mon problème est que ma table de fait doit contenir des clés étrangères de tables de plusieurs bases de données différentes. Est-ce possible de créer une tables de fait dans ces conditions ?

[ylarvor]

c'est impossible et contre performant de référencer des bases de données différentes pour des clés étrangères et le principe d'un datawarehouse que tu n'as pas compris semble t'il c'est que tu dois importer toutes les tables ,via un etl,dont tu as besoin.

j'ai un peu d'expérience sur ssis en 2003. l'ancienne version. Lot dts.

[Borowsky]

Je me suis mal exprimé je crois...

Le principe du Datawarehouse est bien de contenir les données intéressantes des bases de données de production mais stockées d'une facon différente (schéma en étoile par exemple). Pour cela, il faut via un ETL récupérer les données des bases de Prod et les insérer dans un schéma différent avec une table de fait et des tables de dimension.

En passant, la table de fait peut avoir un nombre d'enregistrement assez énorme...?!

Dans mon cas, les données des bases de Prod sont dans plusieurs bases de données et je souhaiterais toutes les regrouper dans mon Datawarehouse. La table de fait de mon Datawarehouse doit donc contenir des clés étrangères qui étaient au départ dans des bases de données différentes... Même si dans mon Datawarehouse, toutes mes tables seront dans la même base.

Je ne sais pas si je suis plus clair...

Si pour résumer je dis ceci : Il faut créer une table de fait, et les tables dimensions peuvent être en gros (après triage des données) les tables des données de Prod. Est-ce correct ?

[ylarvor]

Je n'ai pas une expérience consistante en multidimensionnelle mais je peux te dire la chose suivante :

le fait que tes dimensions viennent de plusieurs bases peut être résolu simplement de la manière suivante : dans ton etl, tu crée un staging area, une base intermediaire qui accueille l'ensemble des tables de tes bases et ensuite tu te retrouves dans la situation d'un transfert / regroupement d'une base vers une autre.

il est possible que le staging area ne soit pas nécessaire mais je n'ai pas le temps de modeliser pour te repondre... alors je te propose cette solution.

si un expert peut nous répondre...

[Paul_S]

Personnellement, je créerai une table des métriques (faits) regroupant tous les n-uplets envisageables, puis une table (physique ou pas) pour chaque dimension d'analyse.
Ensuite un lien depuis la table des métriques vers les tables de dimensions (une ligne dans la table des métriques doit contenir les Id des dimensions associées, ex: code produit, id client, année, mois - pour les dimensions et CA, PR pour les métriques)
Il est donc logique (au passage) que la table des métriques ainsi dénormalisée soit importante.
L'ensemble (métriques + dimensions) est alimenté par l'ETL, avec une gestion des nouvelles valeurs de dimensions...

Si dans la table des métriques on gère les changements, (ex : client qui change de secteur) et que l'on souhaite pouvoir comparer l'état antérieur à l'état présent, alors il convient de gérer une clef complémentaire (surrogate) pour différencier les différents états sur l'ensemble de la table des métriques