Base de données gestion formation

[Sixers33]

Bonjour, je suis nouveau sur ce forum et je demande votre aide svp!

Voila mon problème: Je travaille pour une compagnie de formation et on m'a demandé de créer une base de données afin d'enregistrer les formations données. Exemple, quand on donne une formation, nous remplissons une feuille de liste de présence avec le titre du cours, le code de cours, la date et l'heure, le formateur et son matricule, le centre de formation impliqué ainsi que le local . Puis nous inscrivons le nom du participant, son matricule, l'usine d'ou il vient et il signe cette feuille comme preuve de sa participation à cette formation. Mon patron voudrait qu'après chacune formation, nous ajoutions les informations dans la base de données afin d'avoir un suivi sur QUI a suivi QUELLE formation exactement. Donc, un participant pourra suivre plusieurs formation, donnés par différents formateurs à différents endroits.

J'ai pensé faire genre 6 tables : Employés, Cours, Endroit, Formateur, Période, Résultat mais je ne suis pas sur si c'est justifié. J'aimerais svp votre aide sur quelle table je devrais faire, Je joint un exemple de feuille de présence pour vous donné une idée des informations . Dite le moi si vous avez besoin de plus d'informations! Et merci à l'avance pour votre aide!

[bredelet]

Bonjour

Ta base de donnees n'est pas si complexe.

Dans tes tables, je remplacerais Endroit avec Centre de Formation (Centre si tu as besoin de faire court).

A quoi te sert Periode? Dans la fiche ou dans ta description je ne vois pas l'interet de cette table.

Maintenant que tu as tes tables, tu dois remplir leur champs. Dis-nous ce que tu penses mettre.

[Sixers33]

Merci pour la réponse!

En fait, Période était pour la date et l'heure de la formation, mais je pourrais peut-etre ajouter ces infos sous Cours Je pense a mes champs et je vous en reparle!

[CinePhil]

Quand on se lance dans la création d'une base de données, il faut commencer par la CONCEPTION. Tiens ! C'est justement le forum dans lequel tu postes !

1) A partir du cahier des charges, déterminer quelles sont les entités à gérer.
Au vu de ce que tu as écrit, je vois des :
- Participants
- Formateurs
- Cours
- Centres de formation
- Locaux

J'ai à peu près la même liste que la tienne :

Employés, Cours, Endroit, Formateur, Période, Résultat

La période et le résultat sont des attributs d'une formation.

2) Etablir les associations entre les entités.
La partie importante de ton texte en ce domaine est la suivante :

QUI a suivi QUELLE formation exactement. Donc, un participant pourra suivre plusieurs formation, donnés par différents formateurs à différents endroits.

a) "Qui a suivi quelle formation / un participant pourra suivre plusieurs formation"
En disant ça autrement, un Employé peut ou pas suivre jusqu'à plusieurs Cours.
Nous avons donc l'association :
Employés -0,n----Suivre----0,n- Cours

b) "donnés par différents formateurs à différents endroits"
Un détail qui a son importance et qui n'est pas super clair dans ta description :
Est-ce que 1 formation = 1 cours ?
Pour le moment je suppose que oui.
Nous avons ici deux associations :
- Formateur -0,n----Délivrer----0,n- Cours
- Cours -0,n----Se dérouler----0,n- Lieux

J'arrête là pour ce soir et te laisse continuer à réfléchir.
Si tu es perdu, n'hésite pas à consulter la méthode Merise.

[bredelet]

Oui il faut regarder les relations, mais comme les entites etaient a peu pres bien je ne les ai pas evoquees.

A moins que ca soit reutilise ailleurs, je ne vois pas l'avantage d'avoir les deux tables "Centre de Formation" et "Locaux" car tu vas avoir une relation 1-1 entre les deux.

Par contre tu as retire la table Resultats, je ne suis pas sur d'avoir suivi.
* Quelle est la difference entre Cours et Formation? (l'un pourrait etre pour le cours dispense par le formateur, l'autre pour la formation suivie par un employe)
* Si Resultats est un attribut de Formation, alors il doit y avoir une relation 1-n entre Formation et Employe (Participant). En effet un seul attribut ne peut pas contenir tous les resultats de tous les employes qui ont suivi le cours. Donc un enregistrement de Formation correspond a un seul employe.

Ma proposition est au contraire de garder une table separee pour les resultats, avec une relation 1-n entre Resultat et Cours ainsi qu'une relation 1-n entre Resultat et Employe. Il y a aussi une relation 1-n entre Cours et Formateur, une relation 1-n entre Cours et Centre de Formation et une relation n-n entre Cours et Employe (plusieurs employes assistent a un cours, chaque employe suit plusieurs cours).

[Lou Pitchoun]

Salut,

Tu devrais commencer par regarder l'index Access.

Tu y aurais trouvé 2 super articles sur la gestion de planning.... de formation !! qui peuvent te mettre sur la voie pour créer la base.

http://jeannot45.developpez.com/arti...stionplanning/
http://jeannot45.developpez.com/arti...ionplanningv2/

[Sixers33]

Merci pour votre aide, cela devient de plus en plus clair!

Voici alors mes tables/champs que j'ai pensé:

Participants (Matricule, Prénom, Nom, Usine/service, commentaires)

Cours (Code_cours, Titre cours, Session, Durée, Date, Heure)

1ière question : Je pourrais donner le même cours à une autre date et heure de cette façon?

Je continue

Centre (ID, Usine, Édifice, Local)

Formateurs (ID, Prénom, Nom)

Résultats (Rés. théorique, Rés. pratique, commentaires)

Question : Je doit donner une clé pour cette table? si oui je ne voit pas quoi mettre)

Maintenant, si vous pensez que cette structure est bonne, est-il possible d'avoir un formulaire ou j'indique le cours avec TOUS les participants d'un coup? (Un genre de champ "multi-entrées") Et si j'utilise cette structure et que je donne le même cours à deux dates différentes, ils se comptabiliseront ensemble ou seront deux cours distincts?

Encore une fois merci pour votre aide!

[Sixers33]

Voici aussi les relations que j'ai pensé:

Cours --N--------1-- Formateurs (Un cours est donné par un seul formateur à la fois, mais un formateur peut donner plusieurs cours)

Cours --N--------1-- Résultats

Cours --N--------1-- Centre (Le même cours peut être donné a plusieurs endroits, MAIS a un seul a la fois)

Cours --N--------N-- Participants

Participants --N--------1-- Résultats


Cela a du sens vous croyez?

[Sixers33]

Après analyse, voici mon questionnement :

Étant donné que le même cours peut être donné à des dates différentes, je devrais alors faire une table horaire avec les champs Date et heure non? avec comme relations :

Cours --N--------1-- Horaire



Ca fait beaucoups de questions!

[bredelet]

Si "Code cours" est le meme pour un cours donne a deux dates differentes, alors tu ne peux pas l'utiliser comme clef avec ton schema. Deux options:

1- Ajoute un compteur a la table et utilise-le comme clef
2- Utilise Code cours + Date + Heure comme clef (ou Code cours + Session si c'est unique)

Pour Resultat, la clef peut etre un compteur ou bien composee de Matricule participant, ID formateur et ID cours.

Pour le formulaire oui c'est possible.

[CinePhil]

Moi je différencierais le cours de la session de formation.
Un cours est un enseignement donné.
Une session de formation est un cours donné à une certaine date, par un certain formateur, à un certain nombre de participants, dans un certain lieu.

Donc on aurait plutôt les tables :
Cours (Code_cours, Titre cours, Durée, ...)
Session(Session_Id, Session_Date, Session_Heure, Session_FK_Local, Session_FK_Formateur_ID, ...)
Participer(Participer_FK_MatParticipant, Participer_FK_Session_Id, Participer_Resultat, ...)

Par ailleurs, si tu as plusieurs locaux dans tes centres de formation, il te faut éclater en deux tables. C'est pour ça que j'ai mis ci-dessus la clé étrangère 'Session_FK_Local'.

Sinon tu es sur la bonne voie.

[bredelet]

D'accord en general avec CinePhil.

[Sixers33]

Ouais, c'est bon d'avoir une table "Session"
Alors je recapitule:


Participants (Matricule, Prénom, Nom, Usine/service, commentaires)

Cours (Code_cours, Titre cours, Session, Durée)

Formateurs (ID, Prénom, Nom)

Résultats (Rés. théorique, Rés. pratique, commentaires)

Session (ID_Session, Participants, Cours,Formateurs, Date, heure, Usine, Édifice, Local)

Je n'ai donc plus besoin de la table Centre, puisque la date, l'heure, l'usine, l'édifice et le local sera unique pour chaque Session

Ca commence a prendre forme et je vous en remerçie!

Vous me perdez avec votre table PARTICIPER!!!!

[bredelet]

L'avantage de la table Centre c'est que tu n'as pas a repeter "Usine, Edifice, Local" pour toutes les sessions situees dans le meme local. A toi de voir.

[CinePhil]

Ca ne me semble toujours pas top !

Envoyé par Sixers33

Cours (Code_cours, Titre cours, Session, Durée)

Supprime la colonne Session.

Session (ID_Session, Participants, Cours,Formateurs, Date, heure, Usine, Édifice, Local)

Vous me perdez avec votre table PARTICIPER!!!!

Comment individualises-tu les participants en les mettant dans la session ?
Tu es bien obligé de créer une association entre la session et les participants.
C'est le but de la table Participer.
Et du coup les résultats de la formation reçue par un participant lors d'une session sont des données qui sont portées par l'association Participer et donc incluses dans la table Participer.
Donc vire la table Résultats.

Je n'ai donc plus besoin de la table Centre, puisque la date, l'heure, l'usine, l'édifice et le local sera unique pour chaque Session

Ce qui compte pour une session, c'est le plus petit élément de localisation, donc le local. Par contre, comme c'est une clé étrangère dans la table Session, il vaut mieux pour la lecture que tu associe à cet Id de local un nom et probablement un rattachement à un édifice --> usine.
Si la notion de centre de formation n'a pas de raison d'être parce qu'elle se rattache toujours à une partie d'une usine, vire là.
Mais peut-être que c'est une notion plus large, du genre "Centre de Formation du Sud-Ouest" situé dans l'usine de Toulouse mais qui couvre assure aussi les formations pour les usines de Bordeaux, Pau et Tarbes.
A toi de voir ce que tu as besoin de gérer.

[Sixers33]

Daccord, je comprend

Alors:

Participants (Matricule, Prénom, Nom, Usine/service, commentaires)

Cours (Code_cours, Titre cours, Durée)

Formateurs (ID, Prénom, Nom)

Session (ID_Session, Cours, Formateurs, Participer ID, Date, heure, Usine, Édifice, Local)

Mon essai pour Participer: (Si je comprend bien, cette table servira à "grouper" les participants et à inscrire leurs résultats)

Participer (Participer_ID, Participants, Résultat pratique, Résultat théorique)

Je ne suis pas sur de comprendre cette dernière table...car je ne comprend pas trop comment cette table va se "remplir", J'entre plusieurs participants dans le même Participer_ID?

[CinePhil]

Envoyé par Sixers33

Session (ID_Session, Cours, Formateurs, Participer ID, Date, heure, Usine, Édifice, Local)

Non ! L'association entre Session et Participants est de type (n,m) :
Participants -0,n----Participer----0,n- Sessions
C'est pour ça qu'on fat une table associative qui prend pour clé primaire le couple constitué par les deux clés primaires des deux tables Participants et Sessions.
Participants (Matricule, Prénom, Nom, Usine/service, commentaires)
Session (ID_Session, Cours, Formateur, Date, heure, Local)
Participer(Matricule, ID_Session, Résultat pratique, Résultat théorique)

Je vois seulement maintenant que dans Participants tu as mis une colonne Usine/Service.
Il vaudrait peut-être mieux éclater tout ça :
Usines(Usine_ID, Usine_Nom, ...)
Services(Serv_ID, Serv_Nom, Serv_FK_Usine_ID, ...)
Edifices(Ed_Id, Ed_Nom, Ed_FK_Usine_ID, ...)
Locaux(Loc_Id, Loc_Nom, Loc_FK_Edifice_Id, ...)

Et donc :
Participants (Matricule, Prénom, Nom, Service, commentaires)
Session (ID_Session, Cours, Formateur, Date, heure, Local)

On doit approcher du bout là !

[bredelet]

Oui en pratique quand tu as un enregistrement Session

Session (ID_Session, Cours, Formateurs, Participer ID, Date, heure, Usine, Édifice, Local)

tu ne peux pas mettre plus de 1 Participer_ID dans cet enregistrement, donc ta table n'est pas bonne. Toi tu veux plusieurs participants relies a l'aide de Participer a la session.

Il faut donc faire le lien dans l'autre sens:

Session (ID_Session, Cours, Formateur, Date, heure, Local)
Participer(Matricule, ID_Session, Résultat pratique, Résultat théorique)

Maintenant un lien Participer correspond a un seul participant et a une seule session, mais il peut y avoir plusieurs participants a une session. Donc c'est bon.

[Sixers33]

En fait, Usine /service sert seulement à savoir d'ou vient le participant (De quelle usine ou de quel service de sous traitance externe)

Pour la table Participer, je comprend bien maintenant, merci

Pour l'endroit de session, il faut savoir l'usine (pas la même Usine / service d'ou vient le participant) ou se passe la formation, son édifice et son local, ces informations sont uniques pour chaque session

Je comprend bien ton analyse, sauf les termes du genre Loc_FK_Edifice_Id, que signifie FK?

C'est plus clair?
en tout cas, merci pour vos réponses super rapides!!!

[CinePhil]

FK = Foreign Key, c'est à dire clé étrangère en bon français. C'est pour repérer facilement dans la table les colonnes qui sont des clés étrangères.
C'est ma méthode de nommage à moi.
- Pour une colonne d'identifiant :[Initiales de la table][Id] (ou [Index]). Exemple : LocId ou LocIndex

- Pour une clé étrangère : [Initiales de la table][_FK_][Clé primaire de l'autre table] (ou [Instance de l'entité])
Exemple : Loc_FK_EdId ou Loc_FK_Edifice

- Pour une colonne simple : [Initiales de la table][Nom de la colonne]
Exemple : LocNom

L'expert SQLPro suggère une rigueur encore plus grande dans le nommage dans un de ses articles.