Discussion :

[mira12]

Bonjour,

Je me lance également dans la création du cvthèque via access.
outre le stockage des candidature, l'idéal serait qu'on puisque également gérer les candidatures.
J'ai commencé à créer mes tables et les relations en m'inspirant du travail de kochka.:
creation-cvtheque-demande-daide-concernant-relations-entre-tables

N'étant pas sure de mes relations ni du fait de regrouper tous les éléments du processus de gestion au sein d'une même table (gestion des candidatures)

Je voulais avoir votre avis.

Cordialement

Mira12

[Richard_35]

Bonjour Mira12,

Je ne vois qu'une seule anomalie : il faut lier Formation à Niveau_Formation via Id_Formation (1---∞).

Ah si !... une autre anomalie : il faut ouvrir un fil à part entière. Les modos te le signaleront sans doute, peut-être même en déplaçant ton post dans un nouveau fil.

[mira12]

Merci Richard.

Je ne maitrise pas tout à fait access. Du coup, l'histoire d'ouvrir un fil à part entière, des modos et le déplacement du post ne me parle absolument pas. qu'est ce que ça veut dire?
je modifie ma liaison au niveau de la formation de suite.

encore une fois merci

[mira12]

autant pour moi je viens de comprendre après recherche sur le net que l'histoire du modos et compagnie concernant le postage de mon message sur ce site et non les relations de ma BDD. lol
j'essaie de trouver une solution pour le poster.

[mira12]

pensez vous qu'il faille décomposer la table gestion candidature de tel sorte à séparer les différentes étapes du processus de recrutement ou le fait de les laisser ensemble est une meilleure idée?

[f-leb]

Bonjour,

Quelle est la signification de la partie candidat-postule-candidature-direction ?

Essaye d’énoncer des règles de gestion du style :
Une {candidature} {est déposée} par une {personne}.
Une {personne} peut {déposer} plusieurs {candidature}.

Personne----déposer-----candidature

{déposer} étant une association de type "un à plusieurs"

Une {candidature} {concerne} un {PosteOuvert}
Un {PosteOuvert} peut {être concerné} par plusieurs {candidature}

Candidature----concerner-----PosteOuvert

{concerner} étant également une association de type "un à plusieurs"

Etc…

Concernant la gestion des candidatures, je dirais qu’il faut mettre en œuvre la notion d’{Entretien} :

Candidature----convoquer------Entretien


Ne manqueraient-ils pas des renseignements comme le résultat de la candidature (embauche ou refus) ?

[mira12]

Bonsoir,

Mon langage est peut être erroné…
En fait, je voulais mettre en place une BDD qui me permettrait de gérer les candidatures en fonction des postes à promouvoir des différentes directions.

Dans mon entreprise on est organisé en direction. Chaque direction à des postes spécifique.

Je voulais donc faire un lien avec des tables qui exprimeraient :

qu’un candidat pouvait postuler au sein de plusieurs directions pour des postes différents et/ou au sein de la même direction à un poste différent.

Pour ce qui est de la notion d’entretien serait-il plus judicieux de créer une nouvelle table entretien qui serait reliée à la table candidat ?

J’ai eu la même réflexion concernant le résultat de la candidature cet après midi. J’ai rajouté un champ : embauché et date d’embauche dans ma table gestion candidature. Je ne sais pas si c’est l’idéal…

Autre dilemme, j’ai l’impression que ma BDD est mal construite. J’ai essayé de remplir les champs de mes tables et je remarque que je n’ai pas de lien avec mes différents id. c'est-à-dire que pour connaitre le poste et ou la direction auquel un candidat à postulé, je suis obligé de retaper, par exemple l’id_postule… dans la table direction.

Je me demandais donc si lors de la saisie des données on ne pouvait pas regrouper les tables pour y entrer l’ensemble des infos ou tous simplement si je ne me suis pas tromper dans mes bidouilles.

[f-leb]

bonjour mira12,

Dans mon entreprise on est organisé en direction. Chaque direction à des postes spécifiques.

Direction------avoir-------Poste
Direction-1--------∞-Poste

… en fonction des postes à promouvoir des différentes directions.

Poste------etre-------PosteAPromouvoir
Poste-1----------1-PosteAPromouvoir
(ou peut-être plus simplement un champ booléen [APromouvoir] dans la seule table Poste)


Une personne peut déjà occuper un poste depuis une date :

Personne-------occuper----------Poste
……….......…………..|
…………….......……..|
…….....……..…DateDepuis

Personne-1-------∞-OccuperPoste-∞---------1-Poste

OccuperPoste(#idPersonne, #idPoste, DateDepuis)

… gérer les candidatures en fonction des postes à promouvoir des différentes directions

Personne------déposer-----Candidature------concerner-------PosteAPromouvoir

Personne-1-------∞-Candidature-∞--------1-PosteAPromouvoir (ou Poste avec booléen [APromouvoir])

Pour ce qui est de la notion d’entretien serait-il plus judicieux de créer une nouvelle table entretien qui serait reliée à la table candidat ?

On convoque une personne pour entretien dans le cadre de sa candidature à un poste, donc oui je verrais bien une table Entretien selon le schéma :

Candidature-------convoquer--------Entretien

Candidature-1-------∞-Entretien

…J’ai rajouté un champ : embauché et date d’embauche dans ma table gestion candidature. Je ne sais pas si c’est l’idéal…

Idéalement, on créé une table CandidatureAcceptee :
Candidature-1--------1-CandidatureAcceptee

CandidatureAcceptee(#idCandidature, DateAcceptation, DateEmbauche, …)

Puis selon le même principe :
Candidature-1--------1-CandidatureRefusee

CandidatureRefusee(#idCandidature, DateRefus, MotifRefus, …)


Pratiquement et plus simplement, tu rajoutes un champ [StatutCandidature] ={à l’étude, acceptée, refusée,…} dans la table Candidature.
Puis tu rajoutes à la suite des champs DateAcceptationOuRefus, DateEmbauche, MotifRefus,… quitte à transformer la table Candidature en gruyère (DateEmbauche qui reste vide si la candidature est refusée par exemple).

Oualou…

[mira12]

Bonjour Fabien,

D'abord merci beaucoup pour le tutoriel et les explications.

Je modifie en fonction de vos conseils et explications.

[mira12]

Re Bonjour,

J'ai retravaillé mes tables et relations en fonction de vos conseils.
Je me demande si tout est opérationnel?

Ensuite, une question qui revient:
Access reproduit il les numeros automatiques des id (clef des tables) mises en relations dans les différentes tables ou faut il les retaper à chaque fois?

le coté pratique serait qu'il soit repris automatiquement. Mais j'ai l'impression que dans mon projet ce n'est pas le cas.

Merci d'avance

Amira

[f-leb]

Bonjour,

il manque quelques clés…

(clé primaire soulignée, clés étrangères précédées d’un #)

ParlerLangue(#idLangue, #idCandidat, #idNiveauLangue)


La partie Formation m’intrigue…

Si je reprends l’idée, il y a des institutions où les candidats sont formés :

Candidat------former------Institution

Candidat-1------∞-FormationCandidat-∞------1-Institution

avec FormationCandidat(idFormCand, #idCandidat, #idFormation, DateDebut, TypeFormation,…)


La formation du candidat est éventuellement sanctionnée par un ou plusieurs diplômes :
FormationCandidat-----sanctionner-----Diplome

SanctionnerDiplome(#idFormCand, #idDiplome, AnneeObtention, Mention, …)


Certains candidats peuvent passer des diplômes sans avoir suivi de formations reconnues (candidats libres ou autres) :

Candidat-----passer-----Diplome

PasserDiplome(#idCandidat, #idDiplome, AnneeDiplome, MentionDiplome,…)


Bon, tout ça est à adapter selon ton besoin…

Access reproduit il les numeros automatiques des id (clef des tables) mises en relations dans les différentes tables ou faut il les retaper à chaque fois?

J’ai pas compris Retaper quoi, qui, comment ?

[mira12]

Bonjour Fabien,

Long silence depuis quelques jours de ma part.

Je te remercie pour l'éclairage sur les clefs primaires et secondaires.

Ma question des id, je pense, sera résolu via les clefs secondaires.

J'explique plus en détails: quand on remplie les enregistrements des tables, je me demandais s'il faillait que je ressaisisse, par exemple, la référence de l'id cansidature de la table candidature au sein de la colonne id candidature de la table entretien.

[f-leb]

bonjour Amira,

Candidature-1-------∞-Entretien

Hé bien oui, c’est le principe de la clé étrangère Entretien.idCandidature qui référence la clé primaire Candidature.idCandidature et qu’il faut bien renseigner (un entretien sans candidature n’ayant aucun sens, Entretien.idCandidature ne peut être à Null).

Mais ceci doit rester transparent pour l’utilisateur qui renseignera cette clé étrangère par l’intermédiaire d’une liste déroulante (par exemple) dans un formulaire où Entretien.idCandidature sera masqué (car cet identifiant est purement artificiel et sans signification pour l’utilisateur).

Les assistants d'Access devraient t’aider à réaliser ce genre de formulaires.

[hacenehadjebar]

Bonjour Mira,

As-tu réussi?

[ninig]

Je dois en faire une pour mon service qui comprend plusieurs directions, accepteriez vous de m'aider si vous avez réussi la vôtre ? ça serait sympa merci

Bonjour,

Je me lance également dans la création du cvthèque via access.
outre le stockage des candidature, l'idéal serait qu'on puisque également gérer les candidatures.
J'ai commencé à créer mes tables et les relations en m'inspirant du travail de kochka.:
creation-cvtheque-demande-daide-concernant-relations-entre-tables

N'étant pas sure de mes relations ni du fait de regrouper tous les éléments du processus de gestion au sein d'une même table (gestion des candidatures)

Je voulais avoir votre avis.

Cordialement

Mira12