Création d'une CVthèque - Demande d'aide concernant les relations entre les tables

**Kochka** · 07/01/2011, 18h04

Bonjour,

Actuellement, je travaille dans un cabinet de recrutement. On me demande de créer une CVthèque. Jusqu'ici je ne faisais qu'enregistrer les CV et les informations dans un fichier Excel... Bien entendu, Access serait une solution beaucoup mieux car mes collègues pourraient faire une recherche en autonomie.

J'ai créé une architecture sur Access 2003 de la future CVthèque. Mais, étant débutante, je me demande si j'ai bien compris les relations entre les tables.
Voici un aperçu de ce que j'ai construit (je me suis appuyée sur une discussion du forum de décembre dernier) :

L'idée que j'ai est d'enregistrer toutes les informations contenues dans le CV reçu, le poste pour lequel le candidat postule. Par la suite, je créerai un formulaire de recherche afin que les collègues puissent ressortir certains CV en fonction de ce qu'ils recherchent (selon le secteur professionnel, le profil, le rayon, le niveau de formation, la mobilité, la région, le département).

Voilà, j'espère que mes explications sont suffisamment claires... Pouvez-vous m'indiquer les problèmes que vous détectez ?

Je vous remercie par avance des conseils que vous pourriez m'apporter.

**Boubker_023** · 08/01/2011, 12h50

Sans rien te cacher, il est difficile de suivre toutes les relations. L'idéal aurait été soit de poster ta BDD, soit de faire des tests pour aller droit aux relations quii posent problème. Même étant aussi dans le même domaine, j'ai eu du mal à faire un tour complet des relations en imaginant comment fonctionnent nos Cabinets. Je me permets da faire quelques remarques dans un but de simplification:
- j'enlèverai bien la table TypePermisObtenus
- je mettrai IDPermis dans table Candidat ce qui permettra une sélection au moyen d'une liste déroulante
- Table PermisObtenu composée de : IDPermis, LibellePermis ou Ctegoris
-Table LangueParlee est en relation +eurs à +eurs avec Candidat à revoir
- je verrai la table Niveau en relation avec la table Langue
TableLangueParlee: IDCandidat, IDLangue
Table Langue: IDLangue, LibelleLangue, IDNiveauLangue
Table NiveauLangue: IDNiveauLangue, IDLangue, LibelleNiveau
- les tables Secteur et RayonGD, je les verrai en relation avec la seule table ExpProf
- dans la table ExpProf, je rajouterai bien la FonctionOccupee
Attend tes réactions.
Bon courage à +

**Kochka** · 08/01/2011, 18h10

Bonjour,

Tout d'abord merci pour tes remarques

! J'ai modifié les relations en conséquence. Effectivement, cela simplifie les choses !

Pour ce qui est de mettre en lien la BDD, la voici en pièce jointe au cas où, mais je vais la compléter...
Là je vais faire des essais pour savoir où cela cloche (car j'ai sûrement fais des oublis...). Je fais créer un formulaire et enregistrer un CV pour voir si ça marche! Je croise les doigts !

Je te tiens au courant et j'espère revenir avec de bonnes nouvelles

**f-leb** · 09/01/2011, 20h55

bonjour à tous les deux, et bienvenue Kochka,

les relations sont encore à l'envers

...

Écrivons: CANDIDAT-------parler----------LANGUE

Un {CANDIDAT} peut {parler} plusieurs {LANGUE}

Une {LANGUE} peut être {parler} par plusieurs {CANDIDAT}

{parler} est une association de type "plusieurs à plusieurs" qui nous vaudra une table supplémentaire PARLER_LANGUE dans le schéma des relations Access.

le niveau dépend du candidat et de la langue, on peut compléter:
CANDIDAT-------parler(NiveauLangue)----------LANGUE

ce qui nous donne le schéma:

Même raisonnement pour les formations je suppose.

Par contre, la partie gauche du schéma semble avoir été tissée par Spiderman

. On a du mal à comprendre ce que tu as voulu représenter. Quelques explications sur tes règles de gestion ne seraient pas de trop.

à +

**Boubker_023** · 10/01/2011, 10h55

Bonjour Kochka et f-leb
j'ai regardé ton fichier et je pense qu'il sera difficile qu'il puisse t'aider à répondre à tes préoccupations professionnelles pour la raison suivante: il y a un problème dans sa structure dans la mesure où il y a me semble t-il mélange entre les possibilités de stockage qu'offrent les tables et ce que l'on peut en tirer comme données (simples ou croisées) au moyen de relations bien ficelées et requêtes bien construites.
Au risque de devancer les choses (intérrogation à juste titre de f-leb sur les règles de gestion!), je me permets de schématiser le processus:

on est en présence à chaque fois d'un candidat pour un poste donné ou d'une candidature spontannée pour un éventuel poste
marqué par un certain nombre de caractéristiques (civilité, résidence, coordonnées...)
qui peut avoir une ou plusieurs formations, y compris linguistiques
qui peut avoir une ou plusieurs expériences
qui postule à un poste donné (répond par exemple à une annonce ou se propose pour un poste identique à ses précédentes fonctions ou même plus; un D.A.F ou un D.C qui postule au poste de DG par exemple)
entre temps il aurait subi un entretien d'évaluation avec un Consultant

A ce niveau, il va falloir construire tes tables sur la base de cette proposition:

une T_Candidat avec toutes les informations personnelles
une T_langues (comme expliqué par f-leb)
une T_Formation repectant les conditions d'une relation +eurs à +eurs
une T_Permis
une T_Expériences pour le candidat
une T_Mobilité ou T_Rayon et qui renseignerait sur les prédispositions du candidat à une mobilité Départ, Région, Nationale ou même Internationale
une T_Secteur d'activité
Une T_Postes à pourvoir

Toutes les tables auront une relation avec ta principale table, la T_Candidat.

J'arrive enfin au profil et je pense qu'on ne peut le représenter qu'au moyen d'une ou +eurs Requêtes en croisant les données car à chaque fois il faut extraire de tes tables des Candidats qui remplissent en même temps un certain nombre d'exigences (formulées généralement par le Client!): personne, formation, expérience, compétences, disponibilité, mobilité en s'appuiyant sue les résultats de l'entretien et d'éventuels tests (personnalité).
Maintenant, je pense si tout le monde est d'accord sur ce schéma, on peut y aller, sous l'oeil vigilent de f-leb, dans la construction de ta BDD.
Salutations cordiales

**Kochka** · 11/01/2011, 13h47

Bonjour Boubker_023 et f-leb !

Merci pour tous vos conseils, c'est vraiment sympa de m'aider.

Pour ce qui est de la toile d'araignée, je suis d'accord

Voilà ce que je voulais représenter :
- Un candidat a plusieurs expériences professionnelles --> la table "Expériences professionnelles".
- Par ses diverses expériences, il a occupé successivement des postes différents (de vendeur à directeur en passant par responsable ou chef de département) --> la table "Profil"
- Par ses diverses expériences, il a occupé 1 niveau de poste (exemple responsable de rayon), mais il peut l'avoir exercé sur un rayon A de telle date à telle date, puis sur le rayon B de telle date à telle date --> la table "Rayon_GD"

Mais je pense que j'ai complexifié les choses.

Lors de la recherche, le client nous demande un candidat correspondant au poste qu'il cherche à pourvoir.
Mes collègues vont donc faire une recherche selon le secteur professionnel (la grande distribution par ex.), selon un profil (= niveau de responsabilités), un rayon (alimentaire, non-alimentaire...), la mobilité de la personne (ville, région, département, nationale), le département et la région éventuellement.

Je vais retravailler sur mon schéma et les relations entre les tables cet après-midi.

Bonne après-midi et à bientôt !

**Kochka** · 12/01/2011, 21h50

Bonjour,

Alors j'ai modifié la BDD... Elle ressemble moins à une toile d'araignée

mais j'ai un doute sur mon raisonnement.

J'ai regroupé dans la table Expérience professionnelle : le secteur d'activité et le niveau de poste. Je me suis dis que pour 1 expérience pro, il n'y avait qu'1 secteur et qu'1 niveau de poste. Par contre, dans 1 expérience pro, le candidat peut s'occuper de plusieurs rayons.

Qu'en pensez-vous ?

Je vous en remercie par avance.

A bientôt !

**Boubker_023** · 13/01/2011, 22h06

Bonsoir kochka
j'ai jeté un petit regard sur ta BDD et surtout les relations. La table Postule devrait avoir son propre identifiant. Vous gardez ID_Candidature pour la liaison avec la table CANDIDAT ( relation 1 à +eurs).

Dans ta table EXPERIENCE_PRO, je comprends que ID_Rayon_Commerce ne sera renseigné que pour les métiers de la Grande Distribution.

En attendant ton feed back, j'ai profité d'une alitement suite à une grippe pour avancer un peu dans le projet. Je te fais donc part d'un compte rendu de ma petite contribution que je te propose à titre d'inspiration ( ce n'est pas encore bien ficelé).

Attends de tes nouvelles
Bon courage et à bientôt

**Kochka** · 15/01/2011, 11h06

Boubker,

Bon rétablissement surtout ! J'espère que ça va mieux.

J'ai modifié ma BDD entre temps, je vais étudier ton fichier avec attention (

) pour bien comprendre les choses et m'en inspirer.

Je te tiens au courant le plus rapidement possible !

A bientôt !

**Kochka** · 24/01/2011, 20h37

Cela prend un peu plus de temps que prévu...

Mais j'y suis presque !

**f-leb** · 24/01/2011, 20h45

(bave d'impatience)

**mujon** · 06/05/2011, 14h18

Bonjours à tous, je suis actuellement en stage RH au sein d'un cabinet de recrutement et j'ai pour idée de faire la même chose : créer une CVthèque - candidathèque pour la boite. Est ce que tu as réussi alors à faire ta base de données sous Access ? Sinon je veux bien que tu me montres, kochka (si c'est possible bien entendu !!), le schéma des relations entres les tables que tu as fait. Je pense que ça pourrait beaucoup maider

Je te remercie par avance pour ton aide et espère une réponse.

Cordialement,
Mathieu.