Base pour stockage d'informations sur des candidatures

[CinePhil]

Envoyé par ccanu

- table Candidats avec comme champs : titre, nom, prénom, adresse et tel
- table Offres d'emploi avec : date de la candidature, poste convoité, date de refus (qui pourra être une date ou le statut "engagé")

Plusieurs remarques sur ces premières tables :
1) La description de la table 'Offres d'emploi' correspond plutôt à une table de 'Candidatures'.
2) Toujours mettre une clé primaire de type NumAuto dans les tables représentant des entités identifiables (comme c'est le cas ici, avec cette succincte description, mais on verra plus tard que ce n'est peut-être pas le cas pour la seconde table...).
3) Je mettrais plutôt une colonne DateReponse et une autre TypeReponse (refus, convocation à un entretien, engagement). Les types de réponses pourraient d'ailleurs être externalisés dans une autre table et on aurait alors dans la table Candidatures l'identifiant du type de réponse et non pas le texte.

Ce que j'aimerais ajouter, c'est :
- la date de transfert vers la personne du département concerné
- le nom de cette dernière
- la date d'invitation à un entretien (et ensuite pouvoir calculer le temps entre le réception de la candidature et l'entretien et/ou le refus)
- le statut (en ligne, par adresse, stage)

4) La date de transfert est un attribut de la candidature, donc à mettre dans la table 'Candidatures'
5) Les noms des personnes qui vont traiter les candidatures ne doivent pas figurer dans la table Candidatures mais dans une table annexe (appelons-la PersonnelRH) à laquelle sera associée la table Candidatures. Cette dernière recevra alors l'identifiant de la personne au lieu de son nom.
6) La date d'invitation à un entretien... tiens ! j'y avais pensé plus haut ! .
Si vous voulez calculer une différence de dates, il faut stocker les deux informations. Donc dans la table Candidatures, on met DateReceptionCandidature et DateEntretien.

A savoir, je peux mettre comme clés double :
- table Candidats : nom et prénom
- table Offres : date et poste

Pour quoi faire si compliqué ?
Comme dit plus haut : une clé primaire de type NumAuto sera amplement suffisante.

Il me faut tout de meme un champ similaire pour relier les deux tables car je ne pense pas créer une table Postuler.

Pourquoi pas ?
Ne gérez-vous pas les offres d'emploi en plus des candidatures ?
Relisez les messages plus anciens dans lesquels j'avais déjà abordé cette idée...

mettre une clé triple dans la table Candidats : nom, prénom et date de réception

Vous mélangez encore !
Un candidat, c'est une personne. Il a sans doute une date de naissance mais une date de réception... ce n'est pas un produit quand même !

mettre le statut dans la table Offres

Parle t-on des offres (pourvue, lancée, en étude) ou des candidatures (enregistrée, répondue, convocation, acceptée...) ?

je pense d'ailleurs mettre toutes les autres infos (référent, entretien ...) dans la table Offres.

Idem ci-dessus...
Dans le principe c'est ce qu'il faut faire mais le référent (la personne du service RH qui traite la candidature/offre ?), externalisez les noms et mettez l'identifiant en clé étrangère dans la table.

je souhaite faire une liste déroulante pour le statut mais je ne retrouve plus comment faire... (Access est en allemand, ca n'est pas des plus facile !)

Euh... là ce n'est plus de la conception mais de la mise en forme dans un formulaire. Voir tutoriels sur les formulaires.

Je voulais faire une requête pour relier les 2

Les deux quoi ?

[Simplifi]

hello
puisqu'on recommence, je pense que la date dans la table candidat doit être la date de le première inscription de ce candidat (effectivement, on ne risque plus rien des doublons)
cette table candidat doit aussi avoir un N° (entier), c'est plus facile pour faire les liens, ce N° est indexé et bien sûr sans doublon (c'est vai aussi que je ne suis pas d'accord avec Cinéphil)

pour faire le lien entre les deux tables il suffit de rajouter le N° de candidat dans la table des offres/candidatures

PS: en recommencant, pense à ne pas appeler tes tables et tes champs avec de noms à problème:
- offres d'emploi à remplacer par Offres
- date de candidature par date_candidature
- ne pas utiliser date tout seul, c'est une fonction Access
- pas de tiret (6) c'est une opération (moins) ni de + ou * ni /
- pas non plus de ( ou de [ dans les noms

courage

[CinePhil]

Envoyé par Simplifi

cette table candidat doit aussi avoir un N° (entier), c'est plus facile pour faire les liens, ce N° est indexé et bien sûr sans doublon (c'est vai aussi que je ne suis pas d'accord avec Cinéphil)

Euh... c'est exactement ce que je préconise ! Une clé primaire entière auto-incrémentée, c'est à dire de type NumAuto en Access.

[ccanu]

@CinePhil :

1) J'ai en effet mis "Candidatures" à la place d'Offres d'emploi.

2) J'ai enlevé ma clé triple et mis une clé primaire NumAuto (tapée moi meme et non automatique) dans les deux tables.

3) et 6) Si je fais tout d'abord, DateReponse puis TypeReponse puis DateReceptionCandidature et DateEntretien, ca me parait beaucoup ! J'ai mis DateReception dans les 2 tables pour le moment.
La DateEntretien est dans la table Candidatures, ce qui je pense, règle le problème, non ?

5) Dans ma nouvelle table PersonnelRH, je dois alors mettre comme champ : NumAuto, NomPersonnel. Est-ce que cela suffit ?!

Ne gérez-vous pas les offres d'emploi en plus des candidatures ?

Je ne comprends pas très bien

(@ Simplifi : Je pense plutôt faire le lien avec le NumAuto qui sera le N° du candidat)

Vous mélangez encore !
Un candidat, c'est une personne. Il a sans doute une date de naissance mais une date de réception... ce n'est pas un produit quand même !

C'est ce qui identifie le candidat chez nous mais avec le NumAuto, le problème est réglé !

Parle t-on des offres (pourvue, lancée, en étude) ou des candidatures (enregistrée, répondue, convocation, acceptée...) ?

Je parlais des candidatures dont le statut serait Online, Adresse ou Stage.

Dans le principe c'est ce qu'il faut faire mais le référent (la personne du service RH qui traite la candidature/offre ?), externalisez les noms et mettez l'identifiant en clé étrangère dans la table.

Le référent est la personne à qui nous transférons la candidature.
Une personne de la RH la travaille et la transfère ensuite au référent.
Référent = champ que j'ai mis dans la table Candidatures pour le moment.

liste déroulante

Eh bien j'ai cherché mais comme dit précédemment, mon Access est en allemand donc je n'ai plus vraiment de repères !


@ Simplifi et CinePhil

relier les 2

J'entendais relier les 2 tables par une requête, le champ NumAuto fera alors le lien.
A ce sujet, je ne retrouve plus comment faire les liaisons 0-1-n ... Lorsque l'on clique sur la liaison entre les deux tables, j'ai donc 3 possibilités mais avec l'allemand, je n'arrive pas à saisir laquelle correspond à quoi !

[ccanu]

Question, le NumAuto, c'est bien la clé primaire qui se met automatiquement dans Access quand il n'existe aucune clé primaire décidé par l'utilisateur ?

Parce-que lorsque j'entre NumAuto, ca n'est pas si logique.

J'ai donc ID - comme me le préconisait Access - avec "valeur automatique" (AutoWert) en type de champ. Est-ce correct ?

[CinePhil]

Envoyé par ccanu

3) et 6) Si je fais tout d'abord, DateReponse puis TypeReponse puis DateReceptionCandidature et DateEntretien, ca me parait beaucoup ! J'ai mis DateReception dans les 2 tables pour le moment.
La DateEntretien est dans la table Candidatures, ce qui je pense, règle le problème, non ?

On peut faire comme ça oui.

5) Dans ma nouvelle table PersonnelRH, je dois alors mettre comme champ : NumAuto, NomPersonnel. Est-ce que cela suffit ?!

Oui si vous n'avez pas d'autres informations à gérer concernant le PersonnelRH.

Je ne comprends pas très bien

Les candidatures vont être spontanées pour un poste souhaité par le candidat ou répondre à une offre d'emploi proposée par l'entreprise.
Ne gérez-vous pas ces offres d'emploi ?
Si oui, ne faut-il pas lier les candidatures aux offres ?

(@ Simplifi : Je pense plutôt faire le lien avec le NumAuto qui sera le N° du candidat)

Oui, c'est le principe de la clé étrangère.

Le référent est la personne à qui nous transférons la candidature.
Une personne de la RH la travaille et la transfère ensuite au référent.
Référent = champ que j'ai mis dans la table Candidatures pour le moment.

Si j'ai bien compris, le référent est une personne extérieure à la RH ?
Elle peut alors être externalisée dans une autre table, comme le personnel RH.
Une candidature est envoyée à un référent, un référent peut recevoir plusieurs candidatures. Donc l'identifiant du référent va en tant que clé étrangère dans la table Candidatures.
Si vous gérez également les offres d'emploi, je pense que ces référents sont potentiellement ceux qui font les offres d'emploi ? Donc vous pourrez relier les offres d'emploi aux référents.

A ce sujet, je ne retrouve plus comment faire les liaisons 0-1-n ... Lorsque l'on clique sur la liaison entre les deux tables, j'ai donc 3 possibilités mais avec l'allemand, je n'arrive pas à saisir laquelle correspond à quoi !

Ne pratiquant pas l'allemand, je ne peux vous aider en la matière. Cependant, si vous trouvez un tutoriel français avec des photos d'écran Access, les options sont en principe dans le même ordre dans toutes les langues.
En français, la première option fait une jointure INNER JOIN, c'est à dire qu'elle prend les lignes des deux tables pour lesquelles il y a une correspondance entre les champs concernés par la jointure. La deuxième fait une jointure LEFT OUTER JOIN, c'est à dire qu'elle prend toutes les lignes de la première table et affiche la correspondance, quand elle existe, dans la deuxième table (NULL pour les colonnes de la table 2 dans le cas contraire).
La troisième fait une jointure RIGHT OUTER JOIN, c'est à dire l'inverse de la précédente.

Bon courage.

[CinePhil]

Envoyé par ccanu

Question, le NumAuto, c'est bien la clé primaire qui se met automatiquement dans Access quand il n'existe aucune clé primaire décidé par l'utilisateur ?

Parce-que lorsque j'entre NumAuto, ca n'est pas si logique.

J'ai donc ID - comme me le préconisait Access - avec "valeur automatique" (AutoWert) en type de champ. Est-ce correct ?

Si "AutoWert" veut dire numérotation auto incrémentée oui c'est ça.
Il suffit de créer une table bidon, d'y ajouter une colonne id en "AutoWert", de saisir quelques lignes dans la table et de voir si effectivement cette colonne id prend bien un entier auto-incrémenté.

[ccanu]

Les candidatures vont être spontanées pour un poste souhaité par le candidat ou répondre à une offre d'emploi proposée par l'entreprise.
Ne gérez-vous pas ces offres d'emploi ?
Si oui, ne faut-il pas lier les candidatures aux offres ?

En fait, un candidat peut soit poser une candidature spontanée, soit répondre à une offre d'emploi.
En fait, dans la table Candidatures, il y a le champ "Bewerbung als" (= Postule en tant que) et je mettrai à ce sujet soit le nom de l'offre d'emploi (ex : comptable), soit Initiativ (= candidature spontanée).

Si j'ai bien compris, le référent est une personne extérieure à la RH ?

Tout à fait. Par contre, ils n'ont pas accès à la base de données.
C'est juste pour notre information, si jamais on ne retrouve plus une candidature, savoir où elle est partie !! Et si un candidat appelle, savoir où sa candidature en est.
Donc pas besoin de nouvelle table.

liaisons 0-1-n

Oui je vois très bien, c'est la même chose en allemand
Donc 1) correspond à 0, 2) à 1 et 3) à n ... si j'ai bien compris !
Donc au final :
Un candidat peut postuler à plusieurs candidatures donc Candidat -1-n- Candidatures - 1-1- PersonnelRH.
Ou bien j'ai tout faux ???

A ce sujet, le lien entre les trois est ID, est-ce correct comme cela ou dois-je créer un lien différent entre Candidatures et PersonnelRH ?

"AutoWert"

Superbe, c'est tout à fait ca


Donc au final, il me reste à faire les liaisons (requêtes) entre les tables et puis ensuite la mise en forme ... ?

[CinePhil]

Envoyé par ccanu

En fait, un candidat peut soit poser une candidature spontanée, soit répondre à une offre d'emploi.
En fait, dans la table Candidatures, il y a le champ "Bewerbung als" (= Postule en tant que) et je mettrai à ce sujet soit le nom de l'offre d'emploi (ex : comptable), soit Initiativ (= candidature spontanée).

Bon, apparemment, vous ne souhaitez pas gérer les offres d'emploi avec votre base de données (date de soumission, état en cours soldée ou abandonnée, référent, poste à pourvoir, date clôture et autres caractéristiques). Je n'insiste plus.

Tout à fait. Par contre, ils n'ont pas accès à la base de données.
C'est juste pour notre information, si jamais on ne retrouve plus une candidature, savoir où elle est partie !! Et si un candidat appelle, savoir où sa candidature en est.
Donc pas besoin de nouvelle table.

Ce n'est pas le fait qu'ils n'aient pas accès à la base de données qui va conduire le fait qu'une table est nécessaire ou pas ! Vos candidats non plus n'ont pas accès à la BDD ! La table supplémentaire est destinée à éviter les erreurs de saisie (un personnel RH saisit Shmit et l'autre Schmidt alors que c'est la même personne en réalité) et à ne pas dupliquer des informations (ça fait partie de la normalisation d'une base de données). Un référent peut recevoir plusieurs candidatures donc le référent est une entité du MCD et normalement il faut une table 'Referents'.

[quote]Oui je vois très bien, c'est la même chose en allemand
Donc 1) correspond à 0, 2) à 1 et 3) à n ... si j'ai bien compris ![quote]Pas tout à fait...
Dans les trois cas il peut y avoir de 1 ligne de la table 1 vers n lignes de la table 2. La différence est dans la réponse retournée par la requête. Dans le premier cas il n'y aura que les lignes en corespondance alors que dans les deux autres il y aura toutes les lignes d'au moins une table. D'ailleurs cette notion est à utiliser dans les requêtes avec jointure mais pas dans le schéma des relations entre les tables d'Access.

Donc au final :
Un candidat peut postuler à plusieurs candidatures donc
Candidat -1-n- Candidatures - 1-1- PersonnelRH.

C'est bon.

A ce sujet, le lien entre les trois est ID, est-ce correct comme cela ou dois-je créer un lien différent entre Candidatures et PersonnelRH ?

Personnellement, je n'utilise jamais deux fois le même nom de colonne, même dans des tables différentes.
Moi je ferais :
Candidats(CanId, CanNom, ...)
PersonnelRh(RhId, RhNom, ...)
Candidatures(CR_IdCandidat, CR_IdPersonnelRh, ...)

[ccanu]

il faut une table 'Referents'

Table Referents créée avec le nom et le tel du référent ainsi que le ID comme clé primaire comme pour les autres.

Candidats(CanId, CanNom, ...)
PersonnelRh(RhId, RhNom, ...)
Candidatures(CR_IdCandidat, CR_IdPersonnelRh, ...)

J'ai bien changé les noms des clés primaires des tables Candidats et Candidatures.
Par contre, je sais que ca peut paraitre stupide mais je n'ai jamais vu ce CR_ ... Qu'est-ce que cela représente ? Dois-je l'entrer comme cela dans mon champ en tant que clé double ?

Candidat -1-n- Candidatures - 1-1- PersonnelRH.

Et si on continue PersonnelRH - 1-1 - Referents ?

[CinePhil]

Envoyé par ccanu

Par contre, je sais que ca peut paraitre stupide mais je n'ai jamais vu ce CR_ ... Qu'est-ce que cela représente ? Dois-je l'entrer comme cela dans mon champ en tant que clé double ?

J'ai pour habitude de donner un nom de colonne qui comprend en initiales des lettres de la table à laquelle elle appartient : Table Candidats(CanId, ...)
La table Candidature étant en quelque sorte une table de liaison entre les candidats et les référents, j'ai pensé faire une clé double et prendre ainsi comme préfixe des noms de colonnes CR qui sont les deux initiales des tables liées. Mais vous pouvez tout à fait adopter un autre système de nommage.
Vous pouvez aussi considérer que Candidatures est une entité et lui mettre sa propre clé primaire auto-incrémentée.

Et si on continue PersonnelRH - 1-1 - Referents ?

Euh... pas forcément non.
Est-ce que le référent aura toujours à faire à la même personne du service RH ? Et vice versa ?
En fait le lien entre le référent et la personne du service RH qui lui a transmis la candidature se trouve à l'aide des liaisons entre les autres tables :
Le référent se demande "Par qui est passée cette candidature au service RH ?" Réponse via la table candidature qui contient l'identifiant de cette personne.
Si vous avez créé une table Referents, vous avez maintenant l'identifiant du référent dans la table candidature également. Pas besoin de lien entre les référents et les membres de la RH. Ce qui n'interdit pas qu'ils puissent avoir des relations personnelles entre eux mais cela ne nous regarde pas comme disait un célèbre commentateur de foot français !

[ccanu]

La table Candidature étant en quelque sorte une table de liaison entre les candidats et les référents, j'ai pensé faire une clé double et prendre ainsi comme préfixe des noms de colonnes CR qui sont les deux initiales des tables liées. Mais vous pouvez tout à fait adopter un autre système de nommage.

D'accord, c'est beaucoup plus clair
Il n'y a donc pas besoin que la clé double de Candidature soit en "NumAuto" ? J'ai essayé de mettre les deux champs en "AutoWert" (dc "valeur automatique") mais il me dit que je ne peux en mettre qu'un seul sous cette forme ...
J'ai donc pour le moment laissé le CanId et le CR_CanId en NumAuto et les autres (PersonnelRhId et ReferentId) en Texte.

Est-ce que le référent aura toujours à faire à la même personne du service RH ? Et vice versa ?

Non en effet. La personne RH aura à faire avec plusieurs référents et le référent aura à faire plusieurs RH.

Donc je récapitule

Candidats (CanId, Nom, Prénom, Adresse ...)
- 1 - n - (donc troisième option dans mon truc de requête ? lier donc une ligne de Candidats avec toutes les données de Candidature)
Candidatures (CR_CanId, CR_PersonnelRhId, date de réception, statut (ici, encore souci de la liste déroulante), ReferentId ...)
- 1 - 1 - (option 1) ****
PersonnelRh (PersonnelRhId, Nom, Tel)
Pas de liaison
Referent (ReferentId, Nom, Tel)

est-ce bon ?

*** Je viens de me dire :
- une candidature peut être travaillée par plusieurs RH
- un RH peut travailler plusieurs candidatures
Les cardinalités ne sont pas plutôt - n - n - et je dois alors créer une association "Travailler" ????

J'ai fait 2 requêtes différentes.

Quelle est la marche à suivre maintenant ?

Ce qui n'interdit pas qu'ils puissent avoir des relations personnelles entre eux

Je leur en parlerai