granularité faits RH

[Go_Ahead]

Bonjour,

J'aurais avoir des avis concernant la granularité d'une table de faits d'un DM RH.
Ce fait doit pouvoir mettre en évidence l'occupation de postes, je me demande donc quelle granularité devrais-je utiliser ? que dois je prendre en compte ?

Merci pour votre aide.

[vorace]

moi je dirai la plus fine possible, plus la granularité est fine plus ta table des faits résistera aux changements...des tables trop agrégée sont figées et si les utilisateurs décides d'ajouter une dimension, tu ne pourras pas toujours le faire...

[carlos.dacosta]

Une table de fait RH est généralement réalisée sur la transaction. Elle va te permettre de faire des comptages et des taux tel que : le nbre de jrs de vacance pris, de jrs vacances aquis, de nouveaux embauchés, de promotions, d’heures supplémentaires, de mutations, les différents montants de cotisations…
Cette table de fait doit être de type instantanée périodique, c'est-à-dire quel doit être une image récapitulative d’une table fait transactionnelle (souvent le mois pr ce type de mesure). Mais dans le cas particuliers du système RH, ta table de fait de transaction est en réalité ta dimension employé, qui en faite une dimension dite horodatée, c'est-à-dire un quel contient toute les transactions effectuées avec une date début et une date d’expiration.
Je te conseil, avant de conceptualiser quoi que ce soit, de te renseigner sur les dimensions horodatées et les tables de fait instantanées périodiques. Dans son livre « Entrepôt de données 2.0» Kimball explique bien les différentes problématiques d’un schéma multidimensionnel RH.

En espérant t’avoir aidé…


Carlos Da Costa (www.WebFOCUS-Experience.com)

[vorace]

bon livre mais il faut le digérer...trop abstrait à mon gout et pas assez technique bien que je comprends la position de Ralph Kimball qui préfère privilégier l'aspect théorique et développer les principes de la modélisation dimensionnel indépendamment de toute solution logiciel en particulier (bien que les exemples développés dans le livre sont pensé pour une BDDR) mais je n'arrive toujours pas à concrétiser cette modélisation avec les données dont je dispose...

[Go_Ahead]

Envoyé par carlos54000

Une table de fait RH est généralement réalisée sur la transaction. Elle va te permettre de faire des comptages et des taux tel que : le nbre de jrs de vacance pris, de jrs vacances aquis, de nouveaux embauchés, de promotions, d’heures supplémentaires, de mutations, les différents montants de cotisations…
Cette table de fait doit être de type instantanée périodique, c'est-à-dire quel doit être une image récapitulative d’une table fait transactionnelle (souvent le mois pr ce type de mesure). Mais dans le cas particuliers du système RH, ta table de fait de transaction est en réalité ta dimension employé, qui en faite une dimension dite horodatée, c'est-à-dire un quel contient toute les transactions effectuées avec une date début et une date d’expiration.
Je te conseil, avant de conceptualiser quoi que ce soit, de te renseigner sur les dimensions horodatées et les tables de fait instantanées périodiques. Dans son livre « Entrepôt de données 2.0» Kimball explique bien les différentes problématiques d’un schéma multidimensionnel RH.

En espérant t’avoir aidé…


Carlos Da Costa (www.WebFOCUS-Experience.com)

Bonsoir,

Pour l'instant j'ai modélisé ma table des faits comme étant l'occupation de poste. Avec comme dimension, le personnel, le type de poste, les budgets relatifs au postes, les services etc...
Pour l'instant je constate que ma table des faits contient toutes les clés avec les autres dimensions, plus date de début et fin de poste, le type d'occupation (est ce qu'il est vide ou occupé).
Voici ce que j'ai pu modéliser d'après les "maigres" besoins récoltés par notre équipe.
J'ai déjà un bouquin de ralph kimball, le dwh guide de projet, c'est une mine d'information, pas trop technique, dur à comprendre à certains moment (dimension changeante... pas encore compris comment mettre ça en oeuvre).
Mais cette table des faits contient une ligne par poste... et est donc mise à jour. Je me pose des questions comme, est ce que je dois "historiser" les données de cette table, ou bien cela ne sert il à rien ?
car l'un des but de l'historisation, c'est de pouvoir remonter dans le temps non? et donc pouvoir faire des stat par rapport au passé ?

merci pour votre aide !