Discussion :

[Seperpiou]

Bonjour,

J'ai un petit soucis pour modéliser correctement des tables historisées afin de pouvoir faire des requêtes concluantes.

Pour comprendre il faut que j'explique le fonctionnement RH (je vais essayer d'être clair).

Je travaille chez un client dans la fonction publique sur un infocentre RH. En simplifiant beaucoup, les personnes ont une qualité (pour simplifier il sont soit titulaires, soit contractuels) avec une date de début et une date de fin. S'ils sont contractuels, ils ont donc un contrat avec une date de début et une date de fin. Les titulaires n'ont pas de donnée contrat.

Je fais une requête qui va chercher leur matricule (identifiant qui sert à joindre les tables), leur qualité et leur contrat à une date donnée. S'ils sont titulaires, la case contrat est vide est c'est bien normal.

Mon soucis vient d'un cas de figure où un titulaire, à la date du rapport, a été par le passé contractuel. A ce moment là le salarié ne remonte pas du tout. Je comprends pourquoi il ne remonte pas mais je ne vois pas comment résoudre ce problème et le faire apparaître sur le rapport.

J'ai longuement cherché sur le net mais je n'est pas trouvé de solutions répondant à mon problème. J'ai cité un exemple mais ce cas de figure peut se retrouver dans pas mal de situation dans le cas d'informations RH car on a toujours une notion historique (date de début et date de fin). Comment gérer cela ?

Merci d'avance pour vos réponse.

PS : j'ai mis un petit schéma (basique) des tables dont je parle.
PS2 : je suis travaille sur Cognos.

[Glutinus]

Relier la table contrat à la table qualité au lieu de la relier à la table personne ?

[Seperpiou]

Merci pour la réponse. Je ne pense pas que ce soit possible. En fait j'ai une 20aine de tables qui sont jointes à celle de l'état civil de la même façon que qualité et contrat (affectation, carrière indiciaire, ancienneté, temps de travail...) avec toujours une date de début et de fin. Donc relier les 2 tables entre elles ne résoudrait pas le problème.

[Seperpiou]

De plus les dates de début et de fin de chaque table n'ont rien à voir entre elles. Il peut très bien avoir un nouveau contrat en conservant la même qualité (donc pas de nouvelle date de début pour qualité).

[donino]

Il faudrait peut etre préciser pourquoi ces matricules ne remontent pas, car comme on ne dispose pas de la requête difficile de deviner. Je suppose que cette requête a un filtre de type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

date debut qualité >= date rapport && date fin qualité <= date rapport

et également

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

date debut contrat>=date rapport && date fin contrat <= date rapport

L'accés à la table contrat est il en jointure externe? Je suppose que oui sinon je ne vois pas comment les agents qui n'ont jamais été contractuels remonteraient. Mais dans ce cas il faudrait qu'on sache pourquoi ceux qui ont été contractuels et ne le sont plus ne remontent pas, car même si le 2em filtre ci dessus retourne faux ça ne devrait pas bloquer... Il faudrait donc un peu plus d'infos.

Sinon de manière générale comme tu peux le constater ce type de modélisation de référentiel historisé n'est pas du tout adapté au décisionnel, et tout particulièrement dans le domaine RH: quoi que l'utilisateur fasse il sera toujours poursuivi par ces date-deb date-fin sur toutes les tables impliquées, des problématiques de jointure externes etc. pour créer des rapports.

Une bonne solution est l'utilisation de la technique des situations chères à Ralph Kimball. Dans ton exemple, créer une table "Situation matricule" qui contient 2 clés étrangères techniques (Situation contrat et Situation qualité) , l'identifiant matricule, et date-deb/date-fin. Toute la complexité est reportée sur la création de cette table, les rapports sont ensuite un vrai bonheur à construire puisque il n'y a plus de dates dans les jointures. Pour information l'entrepôt RH du plus gros employeur public français a été construit en partie avec cette méthode.

[Seperpiou]

Merci pour ta réponse intéressante !

En effet la requête est construite avec les filtres que tu as indiqué. Il s'agit de jointures externe qui permettent de remonter les titulaires sans contrat. Pour les titulaires ayant eu un contrat, la requête réalise la jointure sur les anciens contrat et vu qu'il n'y en a aucun qui correspond au filtre appliqué, les lignes sont supprimées (c'est ce que j'en ai déduis) supprimant du coup le matricule concerné (pas de jointure sur du vide !).

L'utilisation de clés étrangères (surrogate key ?) me paraît vraiment intéressante mais assez difficile à mettre en place au vu du nombre de tables (et donc de clés). De plus, la construction et l'alimentation des tables repose sur une solution propriétaire (du progiciel RH utilisé) et cette solution me paraît compliquée à implémenter dans ce cas là.

Tu as raison, je me rends compte maintenant de la difficulté d'utiliser ce type de référentiel historisé mais je ne trouve pas de solution qui me paraît satisfaisante par rapport aux contraintes.

[donino]

Effectivement je comprends le problème, le filtre est appliqué après la jointure externe et donc ne remonte pas les matricules qui n'ont plus de contrat actif. Si quand un contrat n'est plus renouvelé le système générait une ligne "aucun contrat" avec date de fin illimitée ça fonctionnerait, mais visiblement ça n'est pas le cas D'ailleurs la discontinuité de ce référentiel contrats est assez particulière en ce sens, tu ne devrais heureusement pas rencontrer ce problème sur les autres tables de ton projet.

D'un point de vue SQL tu devrais pouvoir t'en sortir en changeant de point de départ: il faut partir de la table contrats et faire une jointure externe sur les matricules puis qualité, alors que si j'ai bien compris actuellement la table "maitre" de départ est le matricule. ça devrait faire le job, maintenant comment expliquer cela à Cognos c'est une autre histoire

[Seperpiou]

Merci beaucoup de ton aide ! J'avais pensé à la même solution de créer des occurrences fictives à vide ce qui permet d'avoir des jointures fonctionnelles quelle que soit la donnée et la population requêtée. La mise en place ne va pas forcément être facile mais je vais proposer on verra bien !

[donino]

C'est en effet une bonne solution, ceci dit puisque elle implique des alimentations spécifiques il vaut mieux que ce soit clair: elle ne fonctionnera que pour les requêtes simples, même si il s'agit juste d'un infocentre il faut je pense bien se mettre d'accord avec le client sur cet aspect.

Par exemple une requête apparemment anodine comme: "Dénombrer les matricules passés du grade A au grade B en 2011, répartis par Direction régionale et Domaine métier" sera extrêmement difficile à obtenir: au delà du calcul du flux de grade, le fait que la requête porte sur l'année implique que l'on ne dispose plus d'une date pivot comme évoquée dans les filtres plus hauts, et on doit donc croiser les dates des 3 historiques entre elles (4 avec le flux) c'est absolument infernal.

Bien peu sont sensibilisés à ce problème: pour l'anecdote une moa sirh s'était faite accompagner directement par un éditeur reconnu du BI pour modéliser son entrepôt RH, afin que celui ci colle le mieux possible à l'outil. Les consultants de l'éditeur, peu habitués à la conduite de projet et qui n'avaient pas pris la peine de faire un vrai prototype, se sont aperçus horrifiés une fois l'entrepôt alimenté que leur outil, aussi puissant soit il ne pourrait jamais exploiter le modèle en l'état. L'éditeur en question a été grillé un bon moment avec toute une branche de la BI

[Seperpiou]

Oui je suis bien conscient de la difficulté de réaliser des requêtes "complexes" ou sur des période car synchroniser les informations devient impossibles.

Pour aller plus loin, j'aimerai me renseigner sur les solutions pour construire quelque chose de plus performant (avec des clés étrangères par exemple...) et adapté aux problématiques RH. Aurais tu des ouvrages ou des sites à me conseiller sur le sujet (le must serais orienté RH mais bon...)? Cela me sera sûrement utile pour la suite !