[Base] Travail préparatoire pour un avancement de grade

[TempsX]

Bonsoir à tous
J'ai comme projet d'aider le gestionnaire RH dans son travail de préparation d'avancement de grade de plusieurs dizaines d'agents territoriaux (330 en 2010). Comme tout projet, j'ai abordé la première étude de modélisation avec AnalyseSI mais le code généré n'étant pas spécifiquement compatible HSQLDB sauf au prix d'adaptations fastidieuses, je préfère attaquer la base de données en mode ébauche avec les règles de gestion suivantes :

Code : Tout sélectionner

1. tout agent dispose d'un grade
2. tout agent est posté dans une unité de niveau 1
3. tout agent occupe une fonction 
4. tout agent qui est intégré dans la base est candidat au grade supérieur (mais les agents saisis qui renonceraient restent dans la base pour éviter la saisie éventuelle de leurs informations l'année suivante)
5. toute unité de niveau 1dépend fonctionnellement d'une unité supérieure de regroupement de niveau 2
6. dans chaque type d'avancement il y a des conditions à remplir fixées annuellement : soit une ancienneté dans le grade précédent, soit un créneau d'âge, soit une limite d'age
7. chaque agent est apprécié selon des critères de notation et d'aptitude. Un avis et un classement est ensuite donné par grade.
8. chaque agent est reçu en entretien préalable par le gestionnaire RH et l'entretien se traduit par une mention favorable ou non.
9. chaque agent est classé par le responsable de chaque unité de niv2
10. tous les classements de niveau 2 sont fusionnés par le RH en un classement unique par grade et par ordre de mérite
11. La commission paritaire se réunit en fin d'année et arrête les listes.

Sur la conception de la base, voilà quelques attendus (il y a matière sur le forum pour trouver pas mal de réponses) :

Code : Tout sélectionner

20. j'ai mis la quasi-totalité des champs sur « non » pour la « saisie requise » à l'exclusion bien entendu des clés primaires dans le souci d'éviter toute erreur d'intégrité des données car à l'usage je trouve les erreurs SQL peu voire pas explicites du tout quand on débute. 
21. j'ai ajouté des colonnes dans la perspective d'une évolution future
22. la base doit s'ouvrir en pleine page sur un menu principal ( vraisemblablement switchboard encore que la mise en page est très restrictive)
23. tous les formulaires doivent s'ouvrir en pleine page et être fermés après utilisation
24. les navigations se feront par des boutons explicites
25. j'ai laissé les relations sur « aucune action » mais j'ai cru comprendre qu'il valait mieux utiliser « supprimer la cascade » et « mettre à jour la cascade » afin que la base n'enfle pas trop

Comme il s'agit de ne pas brûler d'étapes et de ne pas vouloir avoir fini avant de commencer, je fournis ma base en V0 avec juste l'architecture des tables et les relations. Mon projet étant assez ciblé et spécifique, il peut ne pas intéresser grand monde mais selon vous, les tables et les relations sont-elles cohérentes avec les règles de gestion que j'ai posées plus haut ?


Nota, sous Linux je n'arrive pas à conserver la disposition des tables dans la fenêtre « relations » si bien qu'elles sont toutes accolées à la réouverture ce qui me contraint à les réorganiser à chaque fois. Ce phénomène n'existe pas sous windows. Je viens d'installer la OO3.3 officielle mais le phénomène est identique

[jeanmimi]

Bonjour,

les tables et les relations sont-elles cohérentes avec les règles de gestion que j'ai posées plus haut ?

En testant une première ébauche de formulaire, il semble que ça fonctionne.

[Dude]

Salut,

J'ai comme projet d'aider le gestionnaire RH dans son travail de préparation d'avancement de grade

Euh ? Vous n'avez pas de SIRH dans votre CT ? Ce genre de document doit se faire dans tout bon module "carrières".

[TempsX]

En testant une première ébauche de formulaire, il semble que ça fonctionne.

Merci d'avoir vérifié que mon squelette n'est pas trop bancal pour le moment.
A ce jour, la lecture du forum m'a permis de créer un formulaire de saisie de données pour une table principale avec des données d'une autre table (cf formulaire de saisie des unités dans la base jointe). Cela fonctionne très bien car la table Unité permet de stocker l'ID de la table TypeUnité. Mais je me pose la question de la réalisation d'un formulaire unique bâti à partir de l'ID_Matricule de la table Personnel et que j'ai placé comme "liant" dans 6 autres tables. L'idée étant d'avoir un formulaire de saisie unique pour toutes les informations qui concernent une seule personne. Je vais prendre le temps de décortiquer ton exemple.

Salut, Euh ? Vous n'avez pas de SIRH dans votre CT ? Ce genre de document se faire dans tout bon module "carrières".

Si mais il ressemble davantage au Centre Beaubourg qu'à la colonne Vendôme mais surtout, il ne rend pas ce service. On travaille encore avec des tableaux calc aussi longs que peu commodes à analyser.

EDIT 1 : je viens de regarder le formulaire de JM et j'ai constaté que l'on pouvait mettre plusieurs affectations pour un seul personnel. Or chaque personnel ne peut être affecté que sur un poste. Dans ce cas n'y a-t il pas plutôt interet à mettre l'identifiant ID_Affectation dans la table Personnel et supprimer l'identifiant ID_Matricule de la table Affectation ? c'est un casse-tête !! La même remarque pourrait aussi s'appliquer à la table Prise de Fonction et à quasi toutrs les tables pour lesquelles j'ai mis ID_Matricule

EDIT 2 ; je viens de revoir les attributs des tables. Je pense qu'elles sont figées maintenant

[jeanmimi]

on pouvait mettre plusieurs affectations pour un seul personnel

J'ai supposé que l'affectation pouvait changer en fonction du temps selon le champ Date.

[TempsX]

Bonsoir à tous
Je continue sur min temps libre la poursuite de ma base de données. J'ai donc revu la conception des tables selon une approche qui me semble plus cohérente. La table "personel" est la table centrale avec des clés secondaires. Je souhaite créer un formulaire de saisie (F_SaisePersonnel) des informations principales relatives à chaque personnel dans laquelle on trouve des données d'état-civil, de service, d'affectation et de promotion.
Ayant lu les différents tuto, j'ai créé une ébauche mais je n'arrive pas à relier les différents sous-formulaires (T_Affectation, T_Promotion, T_Avancement) au formulaire principal (T_personnel) si bien qu'il manque des informaitons dans la T_personnel.

Merci de vos conseils

[jeanmimi]

Bonjour,
Une macro m'empêche de me connecter à la base !

[TempsX]

Effectivrement, il y avait une macro au démarrage pour lancer le formulaire d'acceuil. Ma base étant > 500 ko, j'ai supprimé le formulaire principal pour l'alléger. D'où l'erreur. La grosseur inattendue venait simplement du fait que j'avais utilisé des fichiers images comme fond de formulaire. En changeant l'extension .odb en .zip, j'ai constaté que les images étaient toujours présentes bien que ne les utilisant plus. En les supprimant, ma base à fondu de 90%. A retenir ....

J'ai ajouté deux autres formulaires qui fonctionnent correctement sur le principe "formulaire/sous-formulaire" en application des tutos que j'ai pu consulter sur le forum. Pour mon formulaire de saisie des données du personnel, je fais appel à des données de plusieurs tables. Quand les tables sont reliées directement à la table principale, je n'ai pas de problème. Quand il y a une table intermédiaire, je n'y arrive plus. C'est par exemple le cas des affectations. Je continue néanmoins mon apprentissage par la méthode empirique.

[Loopingss]

Bonjour.
Je crains qu'il n'y ait une erreur dans la construction de votre base et de ses relations. A moins que PY Samyn ou d'autres grands connaisseurs de Base me donnent tord.
Si l'on considère le dernier fichier que vous avez mis en ligne, de même que la copie d'écran quelques posts auparavant, vous affectez à votre table "personnel" des liens vars d'autres tables.
Ceci fait vous établissez une relation 1->n, par exemple de la table "Entretien RH" (1) vers la table "Personnel"(n).
Or c'est l'inverse. Chaque "Personnel"(1) pourra avoir plusieurs "Entretien RH" (n), etc ...
C'est dans "Entretien RH" que vous devez faire le lien avec l'Id unique de "Personnel".
Il en va de même pour les autres relations.
COOordialement.

[jeanmimi]

mais je n'arrive pas à relier les différents sous-formulaires

Comme l'a vu Loopings, la version actuelle ne permet plus ce que faisait la version 0 il y a quelques jours.

[TempsX]

Merci à tous les deux. Je rebâtis les tables à partir de l'ID_Matricule. Faire et défaire c'est toujuors travailler