Discussion :

[marchand_de_sable]

Bonjour à tous.

Je travail actuellement à la modélisation d'un infocentre de ressource humaine et de paiement, et je coince un peu... (vous vous en serez douté)

En fait, l'Infocentre existe déjà mais il est basé sur la base de données du progiciel utilisé dans ma boîte (la base est pratiquement importée telle quelle).
Or cette base (ou plutôt son modèle) n'est pas du tout adaptée pour le requètage.
Les requètes seront pour des rapports fonctionnels plutôt que d'analyse, mais je dois me débrouiller pour optimiser la simplicité d'utilisation et le temps de réponse plutôt que la "beauté" et la "propreté" du modèle.
C'est pour ça que je me positionne dans le forum BI plutôt que SGBD.

Mon problème est que toutes les données (ou presque) de ma bases sont historiques et évoluent à des rythmes +/- réguliers et +/- fréquents. Encore novice en la matière, je ne maîtrise pas vraiment la gestion des dimensions changeantes.
Parmis ces dimensions, on trouvera par exemple : la carrière, la situation familiale, l'adresse, les coordonnées bancaires et bien d'autres... Toute peuvent évidemment évoluer dans le temps.
Ces infos sont dans des tables qui contiennent un champ Date_début et un champ Date_fin.
Ce que je veux, c'est avoir la situation en vigueur à un instant donné sans avoir à tester ces champs pour chaque dimension.
Je pensais faire une table qui, pour une date donnée, regrouperait les identifiants de ces dimensions. Cela signifie qu'à chaque évolution d'une des dimensions, il me faut ajouter une occurence dans cette table. En gros, ça serait comme une table de faits sans faits ! Ou disons que le fait serait un instantanné de l'état des dimensions à un instant donné.

Quelque chose me dit que c'est bancal... Qu'en pensez-vous ?
Avez-vous des suggestion ?

[EDIT]On peut aussi voir ça comme une dimension qui aurait différentes hiérarchies... Mais je trouve quand même ça bancal...[/EDIT]

[brunolf]

Tu peut gérer les dimensions changeantes en employant des surrogates Key.

Il s'agit de clé techniques permettant de conserver un historique de ta dimension.


par ex :

L'employé martin dupond est célibataire et ce marie en janvier 2007

-> dans ta base de prod tu as dans ta table employé :

Matricule Nom Prénom Statut Marital Date Début Date Fin
000001 Dupond Martin C 01/01/2000 15/01/2007
000001 Dupond Martin M 15/01/2007

Dans ton datawarehouse, tu va ajouter une clé technique appelée Surrogate Key :

SK Matricule Nom Prénom Statut Marital Date Début Date Fin
001 000001 Dupond Martin C 01/01/2000 15/01/2007
002 000001 Dupond Martin M 15/01/2007

-> Il te faudra ensuite alimenter tes tables de fait avec la surrogate key applicable à la date du fait : tu pourras ensuite faire des requêtes avec des jointures strictes entre tes tables de faits et tes référentiels en te basant sur les SK.

ça peut paraitre un peut complexe à mettre en oeuvre, mais en général on retrouve les fonctions de générations de surrogate key dans la plupart des ETL du marché.

[marchand_de_sable]

Merci pour tes exmplications.
J'avais vu ce principe, mais je n'étais pas sûr de bien saisir comment l'appliquer. Je ne voyais pas l'utilité d'ajouter un champ date dans la dimension, à partir du moment où à un instant donné, la table de fait pointe vers la bonne occurrence de cette dimension (...

Mais finalement, ça revient au même que ce que je proposais dans mon 1er message, non ?
Ou alors y'a une subtilité qui m'échappe encore...

Mais ce qui m'embête encore, c'est que j'ai pas vraiment de fait à étudier, si ce n'est la situation général d'un agent à un instant donné. Toutes les situation devant être historisées, à chaque évolution d'une de mes dimensions, je dois ajouter une occurrence dans ma "fausse" table de fait. Du coup, là où j'ai +/- 50 000 agents à traiter, avec, pour chacun, environs 4 occurrences dans chacune des 15 dimensions qui le qualifient, je vais me retrouver avec plusieurs millions de lignes dans la table de fait...
Les requêtes seront effectivement plus simple à faire (c'est un des buts recherchés), mais niveau rapidité d'exécution (qui est le 2ème objectif), je risque de payer ça très cher, non ???.....

ça peut paraitre un peut complexe à mettre en oeuvre, mais en général on retrouve les fonctions de générations de surrogate key dans la plupart des ETL du marché.

Malheureusement, ma boîte ne veut pas entendre parler d'ETL, donc tout ça devrat se faire dans des scripts persos...

[brunolf]

Mais finalement, ça revient au même que ce que je proposais dans mon 1er message, non ?
Ou alors y'a une subtilité qui m'échappe encore...

La différence, c'est que dans mon exemple, je ne créé pas de "table de faits sans faits"... mais vu que tu n'as pas réellement de faits ... ça reviens à peu pres au même.

Toutes les situation devant être historisées, à chaque évolution d'une de mes dimensions, je dois ajouter une occurrence dans ma "fausse" table de fait. Du coup, là où j'ai +/- 50 000 agents à traiter, avec, pour chacun, environs 4 occurrences dans chacune des 15 dimensions qui le qualifient, je vais me retrouver avec plusieurs millions de lignes dans la table de fait...
Les requêtes seront effectivement plus simple à faire (c'est un des buts recherchés), mais niveau rapidité d'exécution (qui est le 2ème objectif), je risque de payer ça très cher, non ???.....

Ca te donne une table de faits (sans faits ) de 3 000 000 de lignes... rien de bien dramatique... si tout ça est bien indexé et que tu ne fais pas tourner ta base de donnée sur une antiquité, ça ne devrait pas poser de problème.

-> dans le monde du datawarehouse, on peut considérer que 3M d'enregistrements, c'est une petite volumétrie.

Malheureusement, ma boîte ne veut pas entendre parler d'ETL, donc tout ça devrat se faire dans des scripts persos...

Bon courage... C'est pour une question de prix de logiciels ? ont-ils envisagé un ETL Open Source genre Talend Open Studio ? (je n'y connais pas grand chose en open source, je suis plutot spécialisé cognos)
-> Le problème à tout écrire sous forme de scripts est que l'on perd un temps fou en maintenance (on avait des scripts java pour alimenter le Dwh dans ma boite avant la mise en place d'un ETL )

[marchand_de_sable]

C'est quoi une "grosse" volumétrie ??
Parce que je ne vais pas avoir que ça comme table de fait. J'ai une table dans la base de production qui contient plus de 80 000 000 de lignes. Je ne sais pas encore exactement comment tout ça va s'articuler, mais je crains que ma table de faits sans faits ne soit que la partie immergée de l'iceberg.

je suis plutot spécialisé cognos

Mais c'est intéressant ça !! Tu connaîs Impromptu ou tu utilises plutôt ReportNet/CognosConnection, etc ??
Parce que mon Infocentre va être exploité via Impromptu 7. Je me demande parfois si au lieu de revoir le modèle de l'Infocentre, je ne devrais pas "simplement" faire mes manipulations dans un catalogue. Si tu as un avis sur la question, je suis preneur.

C'est pour une question de prix de logiciels ? ont-ils envisagé un ETL Open Source genre Talend Open Studio ?

C'est en partie pour une questionde prix, mais pas uniquement. J'ai proposé l'utilisation de logiciels open source, mais je ne travaille pas dans ce qu'on appelle une jeune entreprise dynamique. Lorsque j'ai abordé la question avec le service d'exploitation informatique, j'ai bien senti qu'ils n'étaient pas chauds pour installer et gérer ça, et que ça allait coincer.... Je n'insisterais que si je ne peux pas faire autrement (c'est moi qui gère la modélistation, l'alimentation et la restitution des données...tout un programme).

[brunolf]

Une grosse volumétrie, c'est une notion très relative... ça dépend énormément de ton architecture de BD et des ressources matérielles à ta disposition... la volumétrie te posera plus vite des pb sur mysql que sur du terradata...

Personnellement, je travaille sur de l'Oracle, ma plus grosse ta "pèse" 14 Go pour 22 millions de lignes... Par rapport à certains datawarehouse, ça peut paraitre petit, mais avec cette volumétrie, il faut déjà faire les choses correctement si tu ne veux pas avoir de mauvaise surprise.

Mais c'est intéressant ça !! Tu connaîs Impromptu ou tu utilises plutôt ReportNet/CognosConnection, etc ??

Je travaille actuellement sur Reportnet et sur la mise en place de C8, mais on a encore de l'impromptu qui traine un peu partout. -> j'ai débuté sur impromptu 5... une vraie galère !

Je me demande parfois si au lieu de revoir le modèle de l'Infocentre, je ne devrais pas "simplement" faire mes manipulations dans un catalogue.

Je sais que chez nous, l'appli TRH est livrée avec un catalogue impromptu et des rapports ... donc ce doit être gérable de traiter ça dans le catalogue... Mais je pense qu'il s'agit en fait d'un mix : l'éditeur a, à mon avis, créé des tables de restitutions pour que les perfs ne soient pas trop mauvaises... on se rapproche donc de ce que tu envisage de faire.

c'est moi qui gère la modélistation, l'alimentation et la restitution des données...tout un programme

C'est mon cas également, et dis toi que tu as de la chance : j'ai connu des projets on je ne devait traiter que la partie restitution... l'alimentation étant traitée par une autre équipe, d'une SSII concurrente en plus : une vraie galère ! On passait notre temps à nous renvoyer la balle pour des pb de perfs... C'est une chance de maitriser tout le projet, de l'alimentation à la restitution.

[marchand_de_sable]

dis toi que tu as de la chance

Mouais, j'irais pas jusque là... Parce que du coup, j'ai pas vraiment d'aide ni de soutien...

Sinon, désolé de traîner pour la réponse, mais là je suis en vacances ;-)
(et je me galère avec un clavier español)

Plus de nouvelles la semaine prochaine...

[marchand_de_sable]

L'infocentre est hébergé sur Oracle 9i, sur un serveur qui lui est entièrement dédié. A ce niveau-là, je pense qu'il y a pire.

Par contre, il y aura effectivement du ménage à faire au niveau de l'indexation qui laisse à désirer.... Ma plus grosse table (+/- 80 millions de ligne) contient 10 indexes différents, portant sur 14 champs différents. Je ne suis pas expert DB, mais d'après ce que j'ai lu, autant d'index risquent plus de pénaliser les performances que l'inverse.

Mais je pense qu'il s'agit en fait d'un mix : l'éditeur a, à mon avis, créé des tables de restitutions pour que les perfs ne soient pas trop mauvaises... on se rapproche donc de ce que tu envisage de faire.

Ici, à part le calcul d'aggrégats (pour la majorité inutiles, et qui prennent 80% du temps de chargement), je ne vois pas vraiment de modifications ou d'ajouts par rapport au schéma de la base du progiciel.
Niveau performance, créer un filtre dans mon catalogue qui teste toutes les différentes date d'effet et de fin, ça sera plus intéressant que de créer la table dont je parlais au début de topic ?

D'une manière générale, vu qu'aucune contrainte d'intégrité n'est appliquée dans mon infocentre, je pensais créer (ou recréer) des tables pour "consolider" les données. Mais je me dis qu'avec les nouveaux traitements au chargement, etc., ça peut prendre du temps à mettre en place (surtout sans ETL, aucune doc sur les scripts de chargement actuels...). De plus, ça peut ajouter un certain nombre de jointures dans les requêtes, et donc altérer les perfs. Je me demande donc si je n'ai pas intérêt à TOUT traiter dans mon catalogue. Sauf que je ne sais pas l'impact que ça peut avoir sur les performances...
Peut-être qu'avec ta longue expérience d'Impromptu, tu sauras me renseigner sur les "bienfaits" ou inconvénients d'un catalogue fourni et complexe.