Base pour stockage d'informations sur des candidatures

[ccanu]

En fait, il ny'a pas beaucoup de doublons donc je pourrais les supprimer à la main simplement. Le truc, c'est que certains candidats postulent plusieurs fois dans l'année et je ne peux donc pas supprimer à chaque fois le doublon... Ce que je peux faire, c'est rajouter un chiffre ou une lettre au prénom mais bon, c'est pas super pro je trouve ...

[CinePhil]

Envoyé par ccanu

Le truc, c'est que certains candidats postulent plusieurs fois dans l'année et je ne peux donc pas supprimer à chaque fois le doublon...

Et voilà, vous êtes arrivés à la limite de votre méthode de conception... qui n'en est pas une !
Parce qu'on discute ici dans la partie Conception du forum, je me permets d'intervenir.
Avant de se lancer de but en blanc à importer les tables et à faire au fur et à mesure que ce que l'on découvre des possibilités d'Access, il ne serait pas inutile de se familiariser un minimum avec le concept des bases de données qui est quand même bien différent d'une simple feuille Excel.

Un coup d'oeil sur les tutoriels Bases de données et Conception, méthode Merise, me semble utile.

Revenons à votre problème...

Vous avez des candidats qui posent une à plusieurs candidatures.
Celles-ci sont traitées par des membres du personnel de la RH et par des responsables.
Les candidatures sont d'un certain type (courrier, internet...) et concernent un certain poste convoité.

Voilà un début de réflexion qui permet de souligner des entités qui ont de fortes chances de devenir des tables dans la future base de données.

Ces entités sont associées elles :
Candidats -1,n----Poser----1,1- Candidatures
Ce qui signifie qu'un candidat peut poser une à plusieurs candidatures et qu'une candidature n'est posée que par un et un seul candidat.

Ce qui se traduira par la création des tables suivantes :
Candidats(CanId, CanNom, CanPrenom, ...)
Candidatures(CatuId, CatuDate, ...)
Poser(Po_FK_IdCandidat, Po_FK_IdCandidature, ...)

Les colonnes soulignées correspondent à la clé primaire de chaque table.
FK dans la table Poser signifie que ce sont des clés étrangères (Foreign Key) qui permettront de faire correspondre les candidats et leur(s) candidature(s).
Les ... signifient qu'il y a sans doute d'autres colonnes de données à prévoir (date de traitement, résultat, date de réponse...)

De la même façon, vous pouvez faire une association entre les candidatures et les postes. Mais je suppose que ce poste peut être proposé par l'entreprise dans une offre d'emploi mais aussi qu'il peut y avoir des candidatures spontanées pour un poste d'ingénieur ou autre sans qu'il y ait une offre préalable. Vous aurez donc peut-être aussi à créer une table pour les offres d'emploi et une différente pour les postes. Il y aurait alors les associations :
Candidatures -1,1----Répondre----0,n- Offres
Candidatures -0,n----Concerner----0,n- Postes
Offres -1,1----Couvrir----0,n- Postes

Bon courage !

[ccanu]

Pour le dernier paragraphe, je considère simplement que une candidature spontanée correspond au poste Initiativ.

Merci beaucoup en tous cas pour cet exposé même si cela signifie qu'il faille que je recommence tout mon travail ... ! je vais peut-être simplement faire 2 bases différentes ! Puisque la mise en place de votre base ne part pas de mes tableaux existants. Cependant, je peux simplement commencer une nouvelle base à 0 sans mes informations existantes.

Par contre, dans la création des 3 tables (candidat, canditature et poser), on ne prend pas en compte le fait qu'elles soient travaillées par la RH et d'autres responsables. Malgré tout, seule la RH aura accès à la base pour inscrire les informations (nom, prénom, date de transfert vers un responsable ...) donc chacun la même interface (sauf si on veut faire + sophistiqué en mettant la personne qui inscrit les candidatures et celle qui les transfère et travaille).

[CinePhil]

Mon modèle n'interdit pas de reprendre les feuilles Excel existantes !
Il faut, là encore, le faire avec méthode. L'avantage de cette méthode est qu'en plus elle va vous faire utiliser les techniques des requêtes pour alimenter la nouvelle base de données et qu'en peu de temps vous aurez assimilé pas mal de choses.

Donc pour importer les données existantes (il va y avoir des similitudes avec ce qui a déjà été proposé avant moi donc tout n'est peut-être pas à refaire)...

1) Importer des feuilles Excel
a) Importer une feuille dans une table temporaire Access, sans mettre de clé primaire.
b) Ajouter la colonne pour le type de candidature.
c) Faire une requête Mise à Jour pour ajouter en une seule fois le type à cette colonne.
d) Importer une autre feuille Excel en ajoutant les données à la même table temporaire Access. La colonne 'type de candidature' ne sera pas renseignée automatiquement pour ces nouvelles lignes ajoutées.
e) Modifier la requête précédemment créée en demandant de mettre à jour le type de candidature avec le nouveau libellé du type seulement pour les lignes où le type est vide
f) Refaire d) et e) autant de fois qu'il y a de tables à importer.

2) Remplissage d'une table n'ayant pas de clé étrangère (a priori, la table Candidats ne devrait pas en avoir)
a) Créer une requête qui va extraire les informations relatives aux candidats (nom, prénom, adresse, ...) en les triant par nom, prénom.
b) Vérifier s'il y a des doublons potentiels (nom, prénom) en comparant les autres informations (date de naissance, adresse, téléphone...)
c) Déterminer les colonnes qui permettent d'identifier de manière distincte chaque individu (le couple [nom + prénom] est potentiellement insuffisant mais peut-être qu'en y ajoutant la date de naissance à condition qu'elle soit systématiquement renseignée, ce sera suffisant)
d) Afficher les propriétés de la requête et mettre la propriété 'Valeurs distinctes' à 'oui', ce qui aura pour effet de ne plus afficher les doublons. Noter le nombre de lignes du résultat.
e) Transformer la requête en requête Ajout de données, choisir comme table de destination la table Candidats et indiquer les colonnes destination
f) Exécuter la requête et vérifier que le nombre de lignes importées est correct. Si vous avez pensé, lors de la création de la table, à mettre une clé primaire en NuméroAuto, cette colonne se sera renseignée automatiquement.
g) Procéder de la même manière avec toutes les tables ne comportant pas de clé étrangère.

Pour remplir les tables qui comportent des clés étrangères c'est presque pareil sauf qu'il faut faire une liaison dans la requête entre la table temporaire et la table qui délivre la clé étrangère.
Vous avez donc une table temporaire qui ressemble aux feuilles Excel et un certain nombre de tables de données qui, comme la table Candidats, comporte une clé primaire numérique auto-incrémentée ; à chaque numéro correspond un candidat dont vous avez les informations dans votre table temporaire.
Reprenons l'association :
Candidats -1,n----Poser----1,1- Candidatures
Nous avons vu que la table Candidatures va comporter en clé étrangère l'identifiant du candidat et nom pas, comme dans la table temporaire actuelle, son nom, son prénom et autres renseignements personnels qui eux se trouvent de manière unique dans la table Candidats.
Construisons la requête...
a) Créer une requête en mode Création
b) Choisir la table temporaire et la table Candidats
c) Faite une liaison entre le champ 'nom' de la table 'Candidats' et le champ 'nom' de la table temporaire. Idem pour les autres champs permettant d'identifier de manière distincte les candidats dans la table temporaire (dans l'hypothèse précédente, le triplet [nom + prénom + datenaissance]
d) Mettre dans la requête les colonnes de la table temporaire qui correspondent aux données des candidatures (date réception, résultat, date d'envoi de la réponse...) + la colonne d'identifiant du candidat de la table candidat + les colonnes permettant d'identifier de manière distincte les candidats mais cette fois extraites de la table Candidats
e) Exécuter la requête. Vous devriez obtenir, pour les colonnes existant à la fois dans la table temporaire et dans la requête, les mêmes lignes que dans la table temporaire + la colonne d'identifiant du candidat.
f) Après avoir vérifié que les données sont correctes, supprimez de la requête les colonnes de la table Candidats permettant d'identifier de manière distincte les candidats (toujours [nom + prénom + datenaissance]). Notez le nombre de lignes du résultat.
g) Transformez la requête en requête ajout avec comme table destination 'Candidatures' et exécutez-là. Vérifiez le nombre de lignes créées. Vous devriez avoir la clé primaire numérique auto-incrémentée et la clé étrangère correspondant à l'identifiant du candidat dans la table Candidats + bien sûr toutes les colonnes portant des informations relatives aux candidatures qui sont correctement renseignées.

S'il y a plusieurs clés étrangères dans la table à remplir, il faut faire les liens nécessaires entre la table temporaire et les tables qui délivrent la clé étrangère.

Bon courage !

[Simplifi]

hello
pas trop d'accord avec toi CinePhil, dans les relations 1 à n pas besoin de table intermédiaire, il suffit de référencer le candidat dans la table des candidature!
mais ça ne résoud pas le problème qui nous interressait et qui est d'avoir une clef qui ait une vraie fonction anti-doublon

Ccanu, ta réponse montre qu'à distance, je n'ai pas bien identifié le pb: en effet un candidat peut postuler plusieurs fois
est ce qu'il est autorisé à postuler plusieurs fois pour le même poste? peut être pas, dans ce cas une clef triple, nom, prénom, projet fera l'affaire

quand à la proposition de CinePhil, tu peux l'employer valablement si le taux de candidatures multiple est significatif. En effet, cette séparation va te permettre de ne pas ressaisir le nom et le prénom du candidat, ce qui est une économie de temps et de source d'erreur. Si c'est trois fois par an .... à toi de juger

[ccanu]

A la limite, je peux ne pas faire de table intermédiaire en effet ... En fait, le mieux serait une clé triple (on peut ?) avec nom prénom et date de candidature car le poste n'évitera pas les doublons. Je pense qu'en effet, vu que c'est maximum 3 à 4 fois par an, ça n'est pas nécessaire de construire une table intermédiaire.

Dans tous les cas, le plus simple serait-il de tout recommencer du début avec des tables vides ou bien de transformer l'existante avec la seule table en deux tables différentes ?

(d'ailleurs, je peux effacer les tables temporaires ? et les requêtes ?)

[Simplifi]

hello
vu ta dernière réponse, la clef triple me semble la bonne solution tant en fonctionnalités qu'en rapidité

@cinéphil: comment faire pour interdire les doublons comme ceux de Claire:
jamais deux triplets identique, nom, prénom, date

bien sûr, si on externalise les nom, prénom, dans une table candidat avec une clef double, on résoud la première moitié du pb, ensuite avec une clef double candidat, date on résoud la deuxième moitié

existe-t-il une autre solution que les clef multiples pour ça ? (à part la recherche SQL et le message VB)

[CinePhil]

Envoyé par Simplifi

@cinéphil: comment faire pour interdire les doublons comme ceux de Claire:
jamais deux triplets identique, nom, prénom, date

Si c'est une clé primaire triple, la base de données n'autorisera jamais de doublon sur cette clé.

Si ce n'est pas la clé primaire, je ne sais pas si Access accepte les contraintes d'unicité multi-colonnes.

Dernière solution : le contrôle par programme à la saisie en utilisant l'événement BeforeUpdate.

[Pierre Fauconnier]

Bonjour.

Je suis assez d'accord avec l'esprit des interventions de Cinephil.

1. concevoir les tables Access, indépendamment de ce qui existe dans Excel
2. Avec Access, créer les tables, requêtes, formulaires et états, sans importer les données Excel
3. Tester et valider le travail avec des données de test
4. Préparer l'importation des données dans Excel
5. importer les données


Pour ce qui est de la clé primaire, les clés multi-champs sont délicates à manier dans les relations. Personnellement, je préfère de loin une clé primaire numérique autoincrémentée.

Je pense sincèrement qu'en dehors d'un travail passant par les étapes reprises plus haut, c'est le merdier assuré à très court terme.

[CinePhil]

Envoyé par Pierre Fauconnier

Pour ce qui est de la clé primaire, les clés multi-champs sont délicates à manier dans les relations. Personnellement, je préfère de loin une clé primaire numérique autoincrémentée.

Oui pour les tables représentant des entités du MCD mais non pour les tables associatives car ajouter une clé numérique autoincrémentée dans une telle table n'empêche plus l'unicité des lignes.

Un exemple :
Candidats -0,n----Postuler----0,n- OffresEmplois
Un candidat peut postuler ou pas pour jusqu'à plusieurs offres.
Une offre peut être postulée ou pas par jusqu'à plusieurs candidats.

Ce qui donne les tables :
Candidats(CanId, ...)
OffresEmplois(OEId, ...)
Postuler (Pos_FK_Candidat, Pos_FK_Offre, ...)

Si je remplace la clé primaire double par l'ajout d'une clé primaire auto-incrémentée, je n'interdis plus à un candidat de postuler plusieurs fois pour la même offre d'emploi.

[Simplifi]

hello à tous
Je suis assez d'accord avec vous sur le nécessité de partir de zéro voir même de repartir de zéro
Néanmoins, pour le débutant, c'est rarement le cas et surtout c'est pas facile
D'autant plus que certains responsables demandent des résultats immédiats
J'ai moi même, pour des clients anciens, pris sur moi de rebatir leur application à partir de rien, parce qu'elle avait pas trop bien évoluée, un pe à cause de mon incompétence, mais aussi à cause d'impératifs immédiats, de lubies de décideurs, d'impressions d'économie sur le moment
N'empêche que ça m'a pris pas mal de temps, et surtout que je n'aurais même pas su poser ce cahier des charges au départ.

@Claire, si tu veux, après cette première impression, étudier et batir une solution ex nihilo, tout le forum sera là pour te donner un coup de main

[Pierre Fauconnier]

C'est vrai que cela a l'air plus simple et plus rapide de transposer Excel en Access.

Mais en Excel, on n'a pas les liaisons entre les tables, donc il faut quand même reconstruire une série de choses sur base de clés primaires qui n'existent pas dans Access, par exemple.

La philosophie de travail est totalement différente. Souvent, dans Excel, on travaille directement dans les tables (ou via des userform programmés), on loupe les problèmes d'intégrité référentielle, ...

Repenser les objectifs permet d'améliorer sensiblement l'outil, et je pense qu'il est faux de croire que cela prend plus de temps...

Ce qui prend du temps, c'est d'apprendre Access, mais cette étape sera nécessaire de toute manière...

A chaque fois que j'ai travaillé sans repenser l'outil, et en tentant de transposer Excel en Access, je m'en suis mordu les doigts très vite, et j'ai quand même dû recommencer le boulot ex nihilo => perte de bien plus de temps...

Mais ce n'est là que mon avis.

J'ai rebondi dans le fil parce que, au vu de ce que tu as expliqué à Claire, elle va de toute façon devoir apprendre Access, et que, à mon avis, apprendre Access sur base d'un transfert Excel n'est pas un bon point de départ

[ccanu]

Re-bonjour,

Je vais donc repartir de zéro et faire comme suit :

- je crée directement les bases sur Access
- pas d'importation pour le moment, voire pas d'importations du tout de fichiers Excess

Est-ce correct si je fais comme suit ? :

- 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é")

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)

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

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

Qu'en pensez-vous ?

[ccanu]

Je viens de commencer et j'ai pensé à :

- mettre une clé triple dans la table Candidats : nom, prénom et date de réception
- mettre le statut dans la table Offres.
- je pense d'ailleurs mettre toutes les autres infos (référent, entretien ...) dans la table Offres.
- 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 !)

[ccanu]

J'ai également entré le champ date de réception dans la table Offres.

Je voulais faire une requête pour relier les 2 mais je crois que mes capacités en allemand sont plus restreintes que ce que je ne pensais. Pourriez-vous m'indiquer la marche à suivre ? peut-être pourrais-je retrouver les traductions ...