Discussion :

[chatRoux62]

Bonjour à tous,

Je suis actuellement sur la conception d'un datawarehouse pour les ressources humaines d'une grande entreprise.
Mon problème est que j'ai du mal à savoir, pour certaines tables, si je dois les considérer comme des tables de faits ou de dimension.

Si j'ai bien identifié une énorme table de faits répertoriant ligne par ligne les rubriques de paie de chaque salarié tous les mois, comment dois-je considérer une table qui, par exemple, répertorie les différents emplois des salariés au cours de leur carrière dans l'entreprise ? Cette table ne contient aucune donnée numérique mais a une taille assez conséquente car j'ajoute une nouvelle ligne à chaque changement d'emploi de n'importe quel salarié avec une date d'effet car ces changements doivent être historisés. Et ceci est valable pour d'autres tables comme les stages de formation, les diplomes, les absences, la situation familiale, ...

Toutes ces informations doivent être conservées au cours du temps. Donc ma question est simple : sont-elles des tables de dimension (avec champs historisés) ou des tables de faits (même si elles ne contiennent pas de champs numériques) ?

[doc malkovich]

C'est a priori une table de fait,
tu as les axes
- employé
- emploi
- date d'effet ( de début / fin )

Donc le croisement est une table de fait ....

[chatRoux62]

Merci pour ta réponse John.

[Paul_S]

Bonjour,

Cette table ne contient aucune donnée numérique

C'est effectivement une table de faits, et vous avez probablement comme métrique, la durée (date fin - date déb) quand la date de fin n'est pas vide. Cette durée peut être exprimée suivant l'unité de votre choix (heures, jours, mois, semaines ...)
Il est ensuite possible de décliner cette mesure suivant les différentes dimensions d'analyse : catégorie, emploi, salarié, BU...

[Benoit_Durand]

une table de fait pour "le croisement" de ces dimensions
mais aussi une table de dim de référence pour les différents postes de paie:
salaire brut
charge 1
charge 2
charge 3
salaire net
...

Tous ces postes de paie ont normalement un code et un libellé qui se retrouve sur le bulletin de paie.
Historiser cette dimension pourquoi pas, je ne connais pas les différents attributs d'un poste de paie.

[zerocoolyoussef]

Ca n'empeche que parfois nous avons des tables de faits sans faits

[doc malkovich]

Ca n'empeche que parfois nous avons des tables de faits sans faits

sans métriques ou sans indicateurs oui, mais s'il n'y pas de faits ce n'est pas une table de faits ...

[chatRoux62]

Que pensez-vous ensuite du choix de la modélisation de ces tables ?

Dois-je créer une table de dimension salarié qui contient tous les champs le caractérisant à l'instant présent (son contrat en vigueur, son emploi, sa situation familiale, plus les dates d'effet pour chacun d'eux, ...) puis des tables d'historique de ces notions pour requêter sur les valeurs passées OU créer une table de dimension salarié ne contenant que les champs non historisés puis les tables d'historique contenant, par exemple, tous les contrats différents qu'un salarié a eu dans sa carrière, y compris celui actuel ?
Dans les deux cas, le lien entre la table de dimension et les tables d'historique se fait grâce au matricule du salarié.

Quelle est votre opinion sur la meilleure façon de modéliser l'entrepôt (peut-être que ce n'est aucune de ces deux solutions) sachant qu'ensuite, dans mes univers BO, l'utilisateur doit pouvoir s'y retrouver le plus rapidement et simplement possible entre les données actuelles et historisées du salarié ?

[doc malkovich]

la 1ère solution est meilleure.
oublies la 2ème, en effet si tu veux un champ non historisé et un autre champ historisé pour la date d'aujourd'hui tu seras obligé d'aller dans 2 tables. en gros il faudra jongler entre les 2 ...

tu as aussi la solution d'avoir une seule table avec l'historique + la dernière situation avec un flag qui indique quelle est l'occurence actuelle.

si tu as :
- une grosse volumétrie
- un SGBD non décisionnel / pas en colonne
je te conseille la 1ère solution pour des questions de performance.

[zerocoolyoussef]

sans métriques ou sans indicateurs oui, mais s'il n'y pas de faits ce n'est pas une table de faits ...

les faits du type évènement comment on les modélise alors??

[doc malkovich]

les faits du type évènement comment on les modélise alors??

Hum, je n'ai pas l'impression qu'on parle de la même chose
Tu peux donner un exemple ?

[zerocoolyoussef]

un exemple d'un fait d'évènement: Absence étudiant qu'on veut l'analyser par Matière , Classe , Etudiant, Date..
Qu'est ce qu'on mettra dans la table de fait?

[doc malkovich]

un exemple d'un fait d'évènement: Absence étudiant qu'on veut l'analyser par Matière , Classe , Etudiant, Date..
Qu'est ce qu'on mettra dans la table de fait?

On y mettra les axes ...
Une mesure possible sera le nombre d'occurences

sinon :
http://libd.isnetne.ch/cours/decisio...nnelle_3pp.pdf
slide 54

Il existe dans certains cas des tables de faits dans
lesquelles il n'y a pas de faits mesurés !
– Ces tables sont appelées table de faits sans fait.
• Il existe deux types de tables de faits sans fait:
– Tables de suivi d'événements
– Tables de couverture

--> dans ton cas il s'agit d'une table de couverture
et en effet on dit qu'on a des tables de faits sans fait, mais je ne trouve pas ça juste ... on a quand même un fait - dans ton cas l'absence

[zerocoolyoussef]

wé je confirme

[doc malkovich]

tu pourras en parler dans ton blog ?

[zerocoolyoussef]

oui je crois que ça intéressera beaucoup de monde

[doc malkovich]

et je mettrais surement un commentaire comme quoi dire qu'il existe des tables de faits sans faits est un non-sens

[sarrouna2010]

bjr à tous, maintenant je suis en train de faire mon mémoire de pfe sur la conception de datawarehouse de gestion de paie.est ce que quelqu'un peut me m'aider.merci bien