Discussion :

[TipTopp]

Bonjour à tous,

En attendant un développement au niveau de la DSI de mon entreprise et pour le besoin opérationnel de mon service j'ai entrepris de créer une base de donnée qui sera alimentée par différents extracts de nos systèmes et dont la restitution des données se fera essentiellement via Qlikview.

Bien qu'ayant quelques connaissances théoriques sur les BDD mon expérience reste très limitée, c'est pourquoi je préfère m'assurer auprès de vous que ce que je fais est viable
Je ne pense pas que ce soit très complexe mais j'ai beaucoup de questionnement de débutant.

Je situe le sujet:

On reçoit tous les mois des extracts de systèmes différents qui n'ont pas été conçus pour nos besoins. On doit donc retravailler ces extracts pour obtenir les données qui nous intéressent. C'est ces données qu'il faut que j'organise au sein d'une base. Celle-ci est de nature base de donnée décisionnelle, puisque l'idée principale c'est de naviguer dans ces données via Qlikview. Je sais donc qu'il est préférable que mon modèle soit un modèle en étoile. Je précise également que l'on veut historiser les données.

Toutefois pour la conception je me perds un peu et j'aurais bien besoin que vous m'aidiez à me recadrer

Dans les données qui nous intéressent il y a:

Des données clients :

"statique" : c'est à dire que dans le temps ces données resteront les mêmes, par exemple "type client", donc normalement pas d'historique. Table de dimension

mensuelle : c'est à dire que tous les mois ces données sont suceptibles de changer, par exemple nombre de produit. On souhaite un historique. C'est une table de fait

Des données comptes :

"statique" : c'est à dire que dans le temps ces données resteront les mêmes, par exemple "type compte" et donc normalement pas d'historique. Table de dimension

mensuelle : c'est à dire que tous les mois ces données sont suceptibles de changer, par exemple le CA mensuel. On souhaite un historique. Ce serait la table de fait principale

quotidienne : c'est à dire que tous les jours ces données sont suceptibles de changer, par exemple le CA quotidien. On souhaite un historique. C'est une table de fait

Enfin, j'ai deux tables OPD et CC qui sont issues (champs calculés) principalement des données mensuelles liées au compte mais aussi des données mensuelles liées au client

La mise à jour de la base se fait mensuellement. Elle doit nous donner un vue mensuelle et quotidienne.

Pour pas partir de rien, voilà un premier modèle. C'est très schématique mais c'est parce que mes interrogations, que je vais vous exposer plus bas, sont vraiment structurelles.




Questions :
1. Quand j'ai commencé à réfléchir au modèle, j'ai raisonné en terme de poids de fichier. C'est pourquoi j'ai souhaité faire deux tables différentes client/compte afin de séparer les données qui sont purement au niveau client des données qui sont du niveaux du compte et d'éviter ainsi la répétition d'information.
J'ai suivi le même raisonnement lorsque j'ai décidé de faires des tables différentes pour les données "statiques" et les données mensuelles et quotidiennes afin de ne pas répéter plusieurs fois la même information.
Me confortez vous dans ce choix? ou est-ce un mauvais raisonnement?

2. Si oui, dois je lier la table Quotidien_compte à la table Mensuel_Compte ? ou alors lier la table Quotidien_Compte à la table Compte? Je n'arrive pas à me représenter les impacts d'un tel choix.

3. Comment représenter le temps? Jusqu'à maintenant les membres de mon équipe ont pris l'habitude de travailler avec ANNEE et MOIS, je suis donc parti pour inclure ces variables comme des dimensions dans mes tables.
Mais vaut-il mieux créer une table TEMPS (ID_Date,ANNEE,MOIS,JOUR) ?
Mais alors comment je mets cela en oeuvre dans les tables à vue mensuelle? (C'est à dire qu'elles non pas de date pour les lier à la table TEMPS, mais directement le MOIS et l'ANNEE). Vous me direz que je peux mettre la date de fin de mois mais cela pose ensuite probleme car les données sont associes à un jour et non plus au mois.

Voilà ce sont mes trois questions majeures pour l'instant... vous l'aurez compris je suis très débutant dans ce domaine... si vous pouviez m'éclaicir un peu

J'espère avoir foruni assez d'éléments pour la compréhension de mon sujet, sinon n'hésitez pas à me demander des précisions.

Merci beaucoup à tous ceux qui prendront le temps de me lire et/ou de me répondre!

TipTopp

[bstevy]

Je vais pas répondre à tout, tout de suite, car y'a beaucoup à discuter.
Dans l'idée, ton raisonnement ne me parait pas trop mauvais.

Ce qui me perturbe, c'est surtout ton point 2.
Pour moi, Mensuel_Compte n'est qu'une vue agregée de Quotidien_compte ; ou il y a quelque chose que je n'ai pas très bien saisi dans ta description.
Enfin, si c'est effectivement le cas, tu te retrouves en fait dans la situation Datawarehouse+Datamart. De ce fait, tu as l'ensemble de tes tables de dimension qui devrait être liées à Quotidien_compte en tant que table de fait détail, et les mêmes dimensions liées à Mensuel_Compte en tant que table de fait agregée.

La question sous jacente est quels sont justement tes faits dans ces tables ? sont ce les mêmes en version agrégée dans mensuel ? ou sont ils vraiment différent ?

[Invité]

Salut,

J'ai un peu lu en diagonale, mais une petite réaction sur les tables "quotidiennes" et "mensuelles" - il me semble d'ailleurs que c'est ton point 3) :

Pour ton fait "CA" par exemple, tu peux stocker les données au jour dans une seule table de fait. Tu fait une seule table dimension Temps (Année, Mois, Date).
La FK Date de ta table de fait sera liée à PK_Date de ta dim Temps.
Puis dans Qlikview, l'utilisateur pourra naviguer à la date, et/ou au Mois, et/ou à l'année... Ca s'aggrégera tout seul (pour le mois sélectionné, ca va sommer tous les faits "jour" liés à ce mois).


Il me semble !