Discussion :

[mikaspart75]

Bonjour,

Je viens parmi vous, pour vous demander votre aide concernant la conception d'une base de données sous MySQL, qui va répondre aux besoins d'un
formulaire de candidature sur un site web.
En fait, je suis actuellement période de stage en tant que développeur web. Parmi mes missions, est d'ajouter une autre page de candidature sur le site internet de l'entreprise qui va gérer les demandes d'emploi. Au même temps on me demande de créer une base de données dans laquelle, on va enregistrer les différentes candidature et les candidats y compris les fichiers envoyer avec la candidature(cv et lettre de motivation).
Mon problème, je n'arrive pas à concevoir le bon modèle qui va répondre d'une manière efficiente et efficace au besoins du site.

Dans un premier temps, je me dis de créer trois tables:

Candidat(idContact, nom, premon, date de naissance, tel, email...etc)
Poste(idPoste, nom,...)
fichier(idFichier, nom, taille, dateEnvoi, chemin..) // Pour enregistrer les cv et lettres

Après, je suis un peu perdu, par rapport à rajouter, si c'est une réponse à une offre d'emploi, ou candidature spontanée, en plus je suis un peu stressé, car c'est mes premiers jours en stage, et c'est ma première mission, je dois leurs présenté mon modele et ma conception, rien que ça ça me stresse.

Je vous demande votre aide, et je vous remercie par avance, pour le temps que vous aller prendre pour me répondre.

Cordialement

[CinePhil]

Bonjour,
Votre demande est-elle toujours d'actualité ou avez-vous avancé ?

[mikaspart75]

Bonjour CinePhil,

Je vous remercie d'avoir déplacé ma question dans le le forum qu'il faut, et d'avoir penché sur mon problème. Alors, j'ai un peu avancé dans ma conception, mais il reste quand même des zones d'ombre, je joint mon mcd, et dites moi ce que vous pensez, par contre, je voudrai rajouter une table administrateur qui comportera les attributs suivants: id_admin, identifiant/Email, mot_de_passe, cette table va permettre à l'administrateur de se connecter, et de récupérer toutes les informations concernant les candidats, qui ont envoyé leurs candidatures sur le site internet.

je ne vois, pas comment faire les relations et les associations qu'il faut, car, un candidat ne peut pas être administrateur. J'ai pensé à faire Admin (o,n)---> (0,n)candidats, mais je ne sais pas trop, si ça va répondre au besoin exprimer ci-dessus.

Merci de votre aide.

[escartefigue]

Bonjour

Quelques remarques d'ordre général :

Vous n'avez pas mentionné les règles de gestion, or c'est la première des choses à faire.
Référez vous aux autres sujets pour trouver la démarche à suivre.
La présentation devrait être du type :
- R001 : un candidat joint à minima un fichier à sa candidature
- R002 : un fichier de candidature est join par un et un seul candidat
- R003 :


Tout attribut doit être en dépendance fonctionnelle de l'identifiant
Sauf si vous avez un et un seul téléphone par candidat ce qui est très restrictif, la bonne modélisation consiste à créer une entité-type supplémentaire, en lien avec CANDIDAT, pour gérer les téléphones et encore une autre, en lien avec TELEPHONE pour typer les téléphones

CANDIDAT 0,n --- posseder --- TELEPHONE 1,1 --- typer --- 0,n TYPE_TEL

Idem pour les adresses

De même, la spécialité devrait faire l'objet d'une entité-type en relation 0,n ou 1,n avec le candidat, comme vous l'avez fait pour les langues
CANDIDAT 0,n --- avoir --- 0,n SPECIALITE


Il existe une norme pour coder les adresses
Cette norme est régie par la poste, deux variantes : l'une pour les adresses en France, l'autre pour celles à l'étranger.
Il s'agit de 6 au 7 lignes de 38 caractères chacune.
Ne stockez pas de donnée calculée
L'âge par exemple ne doit pas être stocké, il sera calculé grâce à la date de naissance


Le typage des données doit être fait avec soin
Vous n'avez choisi que des types varchar (ou text), or, ce choix n'est judicieux que pour les données dont la longueur maximale est significative et qui varie beaucoup d'une occurrence à une autre, mais reste stable dans le temps pour une même occurrence. Pour les colonnes dont la longueur maximale est faible (moins de 15 à 20 caractères), préférez du char de longueur fixe.


Entité-type LANGUE
Le niveau est probablement celui du candidat pour la langue, auquel cas l'attribut niveau est à déplacer dans la relation "parler"


Entité-type FICHIER
15 caractères c'est beaucoup trop court pour un chemin d'accès
Le type de document doit être le résultat d'un lien entre l'entité-type fichier et une nouvelle entité-type "TYPE_DOCUMENT"