[AC-2010] SGBDR centre de formation

[MachA57]

Bonjour,

Merci d'avance pour vos explications dans la conception de ma base de données. Je suis débutant dans l'utilisation d'access mais ai des notions de base de données.
Voici mon projet : je souhaite mettre en place une base de données pour un centre de formation.
Voilà le fonctionnement de ce centre :
Ce centre réalise des formations d'une durée de 1 à 5 jours en matière social, fiscal, bureautique,droit, etc....
Les stagiaires sont des salariés d'entreprises.
Les formations ont lieu soit dans les locaux du centre, soit dans des salles de séminaire. Plus rarement, à la demande de certaines sociétés, le centre réalise des formations dans les locaux de la société demandeuse (en intra).
Les formations sont classées en catégories (social, fiscal, etc...).
Les formations sont dispensées par des formateurs (c'est logique non ?).
Pour chaque formation, une ou plusieurs dates (ou sessions) sont prévues au cours de l'année. Celles-ci sont réalisées (ou pas) en fonction du nombre de personnes inscrites à la formation (il n'y a pas de règle, c'est le directeur du centre qui décide).

Le centre dispose de commerciaux pour vendre les formations.
Les commerciaux réalisent parfois un devis auprès des entreprises clientes avant l'inscription du ou des salariés de celle-ci.
Ensuite, les stagiaires sont inscrits à la formation et les commerciaux doivent surveiller de recevoir en retour la convention de formation et le chèque de caution.
La formation est financée soit par l'entreprise elle-même, soit par un opca (organisme paritaire collecteur agréé). La facture est établie, pour un ou plusieurs stagiaires de la même société, soit à la société, soit à l'opca si c'est ce dernier qui la prend en charge.
Les formateurs sont rémunérés et perçoivent des remboursements de frais. ces éléments changent pour chaque session de formation. Le repas des stagiaires est également payé par le centre de formation.
Les commerciaux perçoivent des commissions pour chaque stagiaire inscrit qui est un pourcentage du montant facturé.
Parfois les stagiaires sont inscrits mais leur participation à la formation est annulée (désistement, cas de force majeur,etc...). Mais il est souhaitable de garder une trace de cette inscription.

La base de donnée doit servir à produire les différents documents d'inscription mais aussi à servir de tableau de bord pour chiffrer la marge de chaque session.

Voici en pièce jointe les tables et relations telles que j'ai conçu la BDR actuelle. Je suis preneur de toutes vos critiques et observations. merci !!!!!

[f-leb]

Bonjour,

l’énoncé a de l’allure, il y a de quoi ferrailler pendant quelques dizaines de posts

Envoyé par MachA57

La formation est financée soit par l'entreprise elle-même, soit par un opca (organisme paritaire collecteur agréé)

On sait déjà qu’une formation est demandée par une entreprise :
Formation-∞--------1-Entreprise

La formation peut être financée par un Opca :

Formation-1-------∞-FinancementOPCA-∞------1-Opca
FinancementOPCA(#idFormation, #idOpca, …) (clé primaire soulignée, clé étrangère précédée d’un #)

Si une formation est financée par un Opca, on créée une ligne dans FinancementOPCA pour cette formation. Sinon, c'est qu'elle est financée par l’entreprise demandeuse de la formation.


Concernant les lieux de formation :

Envoyé par MachA57

Les formations ont lieu soit dans les locaux du centre, soit dans des salles de séminaire. Plus rarement, à la demande de certaines sociétés, le centre réalise des formations dans les locaux de la société demandeuse (en intra).

Je verrais bien une table pour les adresses : Adresse(idAdresse, adresse1, adresse2, adresse3, CP, Ville).
Une entreprise est bien sûr localisée à une adresse :
Entreprise-∞-------1-Adresse
, mais une adresse peut aussi être celle d’un Opca, d’un stagiaire, d’un commercial etc. voire celle d’une salle de séminaire extérieure au centre.

On écrit :
Session-∞------1-LieuFormation

LieuFormation(idLieuFormation, libelléLieu, TypeLieu, nbrPlacesDispo, …)

Mais un lieu de formation est soit une salle du centre, soit une adresse (celle de l’entreprise ou de la salle de séminaire extérieure au centre).
On écrit par exemple :
SalleDuCentre-1--------1-LieuFormation-1------1-Adresse

Sinon, je pense qu’il faut une table Inscription(idInscription, DateInscription, …, #idStagiaire, #idFormation, #idCommercial, …).

Et il manque encore toute la partie devis&facturation, non ?

à+ 

[MachA57]

l’énoncé a de l’allure, il y a de quoi ferrailler pendant quelques dizaines de posts

Merci cette BDR est un défit pour moi !!!

Je me suis mal exprimé peut-être lorsque j'ai dit que la formation est financée par un OPCA : c'est vrai, mais au niveau d'une seule entreprise. Mis à part dans les formations INTRA cad dans les locaux de l'entreprise concernée, les formations dispensées regroupent les salariés de plusieurs entreprises. Le financement de la formation (opca ou entreprise) est un critère qui varie d'une entreprise à l'autre.
Pour une même session de formation regroupant donc plusieurs entreprises, on peut avoir certaines entreprises qui financent elle-mêmes la formation, et d'autres entreprises qui la font prendre en charge par leur opca.
C'est pour cela que j'avais prévu ce paramètre dans le champ Stagiaire.OPCA qui est du type OUI/NON.

La table lieu correspond a celle que vous appelez LieuFormation
La table Inscription existe : je l'ai nommée Stagiaire...peut-être n'est-ce pas très pertinent mais je n'ai pas besoin de conserver dans le temps le nom des stagiaires dans une table distincte. Si la même personne suit à nouveau une formation, on saisira de nouveau son nom et son prénom.

La table Entreprise sert pour les devis. Je devrais la renommer et ajouter une table entreprise avec les coordonnées de celles-ci non ? Par contre si je crée une table entreprise, je voudrais que lorsque on saisi un devis, le formulaire permette de saisir une nouvelle entreprise si celle-ci n'est pas encore cliente. Donc que la saisie alimente la table Devis et consulte la table entreprise et la met à jour si nouvelle entreprise.

Je n'ai pas encore réfléchi à la facturation....

[f-leb]

Ok, je comprends mieux…

Voir l’ébauche de schéma en pièce-jointe (toujours sans la partie devis&facturation qu’on pourra voir plus tard), j’y aie mit les points à débattre en évidence.

Par exemple dans le bout de schéma : Formateur-1-----1-PersonneDuCentre-1------1-Commercial,
on modélise (voir le tutoriel héritage de données) le fait qu’une personne du centre est soit un formateur, soit un commercial (il faudra encore programmer la contrainte qui fait qu’une personne du centre ne peut être les deux à la fois a priori).

Tu verras dans le tutoriel que l’on peut modéliser cette partie de plusieurs façons avec les arguments pour et contre. On peut alors aller jusqu’à tout fusionner dans une seule table Personne avec un champ TypePersonne=commercial ou formateur. C’est ce qu’il y a de plus simple pour les formulaires mais pas toujours le mieux pour la qualité des données, l’intégrité, la cohérence etc. À toi de voir en analysant les pour et les contre.

Même raisonnement sur SalleDuCentre-1-----1-LieuFormation-1-----1-Adresse.
Un lieu de formation est soit une salle de ton centre, soit une adresse (qui peut être celle d’une entreprise pour les formations en intra, ou celle d’une salle de séminaire extérieure à ton centre). Une fois de plus on peut "simplifier", fusionner les tables et on bétonne comme on peut pour que les tables conservent la cohérence sans prendre trop de poids avec des champs bêtement vides.

Pour la partie financement-financementOPCA-OPCA :
J’ai une table Financement car une entreprise peut financer plusieurs formations et une formation peut être financée par plusieurs entreprises.

Si pour un financement d’une formation, une entreprise recourt à un Opca, on crée une ligne dans la table FinancementOPCA indiquant, entre autres, l’organisme paritaire.
Si on veut se faciliter la vie dans la construction des formulaires, on fusionne là encore les tables Financement et Financement OPCA, et on tolère la présence de champs vides pour les financements sans OPCA.

La table Inscription existe : je l'ai nommée Stagiaire...peut-être n'est-ce pas très pertinent mais je n'ai pas besoin de conserver dans le temps le nom des stagiaires dans une table distincte. Si la même personne suit à nouveau une formation, on saisira de nouveau son nom et son prénom.

On autorise la redondance, au niveau statistique on confond nombre d’inscriptions et nombre de stagiaires. Les deux concepts sont mélangés mais pourquoi pas si on a bien évalué le besoin...

J'attends de voir le fruit de tes réflexions sur la partie devis&facturation

[MachA57]

Déjà, merci pour le temps consacré à la préparation de la BDR exemple jointe à ton message !

Je n'ai pas pris le temps de lire le tutoriel mais je vais m'y atteler.

Juste quelques précisions :

Le centre de formation est modeste : il ne dispose que d'une salle .
On parle de formation INTER si celle-ci a lieu dans le centre ou dans un hotel d'une autre ville. On parle de formation INTRA si celle-ci est dispensée spécifiquement pour une entreprise dans les locaux de cette entreprise.
On peut certainement du coup simplifier la partie de la BDR concernant le lieu.

Par exemple dans le bout de schéma : Formateur-1-----1-PersonneDuCentre-1------1-Commercial,

Je ne comprends pas l'intérêt de ces 3 tables...mais peut être que la réponse est dans le tutoriel.

Les entreprises ne financent qu'une session de formation à la fois. En fait, pour chaque stagiaire de chaque session qui est ouverte, le centre envoi une convention de formation à l'entreprise employeur du stagiaire. Cette convention prévoit un financement en interne ou via un opca selon les cas. Ensuite, la facture est établie à l'entreprise ou directement à l'opca si tel est le cas.

Personnellement, j'aurais rattaché les commerciaux aux entreprises et non pas aux inscriptions car chaque commercial a un ensemble d'entreprises en contact. Une entreprise n'a en contact qu'un seul commercial. Par contre, bien sûr un commercial dispose d'un portefeuille de plusieurs entreprises.
non ?

[f-leb]

Envoyé par MachA57

On peut certainement du coup simplifier la partie de la BDR concernant le lieu.

Certainement, on peut déjà supprimer ma table SalleDuCentre.

Envoyé par MachA57

Je ne comprends pas l'intérêt de ces 3 tables...mais peut être que la réponse est dans le tutoriel.

L’intérêt de la table PersonneDuCentre est de regrouper les propriétés propres à tout personnel de ton centre, qu’il soit commercial ou formateur (nom, prénom, téléphone, etc…), dans une même table. Les tables spécifiques Formateur et Commercial regroupent les propriétés spécifiques à chacune de ces deux catégories de personnel. Mais comme expliqué dans le tutoriel, on peut selon les cas faire uniquement deux tables Formateur et Commercial voire même tout fusionner dans une unique table Personnel regroupant commerciaux et formateurs.

Envoyé par MachA57

Les entreprises ne financent qu'une session de formation à la fois. En fait, pour chaque stagiaire de chaque session qui est ouverte, le centre envoi une convention de formation à l'entreprise employeur du stagiaire. Cette convention prévoit un financement en interne ou via un opca selon les cas. Ensuite, la facture est établie à l'entreprise ou directement à l'opca si tel est le cas.

Ah, ok. On efface le tableau et hop, nouvelle proposition en pièce-jointe. Je t'avais dit qu'on allait ferrailler un moment.

Envoyé par MachA57

Personnellement, j'aurais rattaché les commerciaux aux entreprises et non pas aux inscriptions car chaque commercial a un ensemble d'entreprises en contact. Une entreprise n'a en contact qu'un seul commercial. Par contre, bien sûr un commercial dispose d'un portefeuille de plusieurs entreprises.
non ?

J’ai rattaché Inscription-∞-------1-Commercial, compte tenu de :

Envoyé par MachA57

les stagiaires sont inscrits à la formation et les commerciaux doivent surveiller de recevoir en retour la convention de formation…

Le commercial rattaché à l’inscription était donc celui, à mon sens, qui devait surveiller cela.
Maintenant, tu peux aussi envisager: Entreprise-∞------1-Commercial.

[MachA57]

J'ai parcouru le tutoriel que tu m'a mentionné.
Mes connaissances insuffisantes ne m'ont pas permis n'en saisir toutes les subtilités
Cependant, je pense avoir compris les éléments essentiels.

Notre centre a 3 commerciaux et 7 formateurs. Donc, je pense qu'il n'est pas nécessaire de concevoir la base de données de façon très sophistiquée
Je pense qu'une table "Formateurs" et une table "commerciaux" est un bon choix.

Pour le financement, je pensais mettre une case à cocher "OPCA" dans la table "Inscription" avec une contrainte pour le champ Nom_opca : Si le champ OPCA = Vrai alors on saisi le code opca suivant les données de la table OPCA, si le champ OPCA = faux alors on ne peut rien saisir.

Pour le lieu de la session de formation, je pensais faire de la même manière : un champ "INTRA" à cocher. Si vrai (donc si la formation a lieu dans les locaux de l'entreprise cliente) : rien à saisir dans le champ "lieu", si faux, on saisi un lieu suivant la table "lieux" qui contiendra l'adresse du centre et des hôtels dans les autres villes.
Avec une condition on doit certainement pouvoir prévoir de créer une requête qui liste les date et nom des sessions et leur lieu, ce dernier étant soit le lieu de la table "lieux" si renseigné, soit si la case "INTRA" a été cochée, l'adresse de l'entreprise. non ?

Parfois, des inscriptions effectuées sont annulées. C'est pour cela que j'ai prévu une case à cocher dans le champ "Inscript_annulee" dans la table "inscription". Je veux garder une trace de l'inscription mais pouvoir exclure celles annulées de la requête qui affichera le chiffre d'affaires de la session.

Qu'en penses-tu ? Merci d'avance

[f-leb]

Envoyé par MachA57

Pour le financement, je pensais mettre une case à cocher "OPCA" dans la table "Inscription" avec une contrainte pour le champ Nom_opca : Si le champ OPCA = Vrai alors on saisi le code opca suivant les données de la table OPCA, si le champ OPCA = faux alors on ne peut rien saisir.

Je n'aime pas trop laisser des champs vides (ça fait Excel) mais c'est vrai que c'est plus simple.

Pour le lieu de la session de formation, je pensais faire de la même manière : un champ "INTRA" à cocher. Si vrai (donc si la formation a lieu dans les locaux de l'entreprise cliente) : rien à saisir dans le champ "lieu", si faux, on saisi un lieu suivant la table "lieux" qui contiendra l'adresse du centre et des hôtels dans les autres villes.

Ok c'est le même principe que pour les opca. J'ai un doute, si la formation a lieu dans ton centre, tu vas recopier à chaque fois son adresse dans la table Lieux ?

Avec une condition on doit certainement pouvoir prévoir de créer une requête qui liste les date et nom des sessions et leur lieu, ce dernier étant soit le lieu de la table "lieux" si renseigné, soit si la case "INTRA" a été cochée, l'adresse de l'entreprise. non ?

oui oui, pas de soucis.

Parfois, des inscriptions effectuées sont annulées. C'est pour cela que j'ai prévu une case à cocher dans le champ "Inscript_annulee" dans la table "inscription". Je veux garder une trace de l'inscription mais pouvoir exclure celles annulées de la requête qui affichera le chiffre d'affaires de la session.

ok, ça marche

Un autre doute, l'inscription est pour la formation toute entière ou pour la session seulement ?

[MachA57]

Ok c'est le même principe que pour les opca. J'ai un doute, si la formation a lieu dans ton centre, tu vas recopier à chaque fois son adresse dans la table Lieux ?

Je ne comprends pas cette question désolé...

La table "sessions" contient le champ "lieu" qui est relié à la table "lieux" (voir mon fichier). Donc, je vais saisir dans la table "lieux", la liste de nos adresses dans les hôtels ainsi que celle de notre centre. Cette saisie ne se fait qu'une seule fois puisqu'on a une relation entre la table "sessions" et la table "lieux"

Je n'aime pas trop laisser des champs vides (ça fait Excel) mais c'est vrai que c'est plus simple.

Je comprends cette remarque venant d'un spécialiste
Moi, j'ai des souvenirs lointains de mes cours d'informatique en base de données alors je fais avec ce que je connais. Maintenant, je veux bien apprendre

Un autre doute, l'inscription est pour la formation toute entière ou pour la session seulement ?

La table "formation" n'est que la liste des thèmes proposés et diverses infos comme la durée, le formateur. D'un point de vue MCD, on ne peut pas s'incrire à une formation mais à une session. La session est la ou les dates prévues, dans un lieu prévu, d'un thème de formation donné. Une formation peut avoir existé (le thème) mais n'est plus dispensé (on ne propose plus de sessions). C'est pour cela que j'avais prévu la table "formation_inactive" avec un champ OUI/NON et une relation de type 1 - 1.
Il me semble que c'est mieux de procéder ainsi(créer une table distincte) que d'inclure le champ OUI/NON dans la table "formation" pour éviter, comme tu me l'as fait remarqué, les champs vides. C'est bien cela ?
Si tu me le confirme, je devrais donc faire de même pour la table "sessions" avec le champ "Session_ouverte" (aussi de type OUI/NON).

La difficulté que je rencontre est liée à ma connaissance incomplète de ACESS. D'où par exemple ma question :

Avec une condition on doit certainement pouvoir prévoir de créer une requête qui liste les date et nom des sessions et leur lieu, ce dernier étant soit le lieu de la table "lieux" si renseigné, soit si la case "INTRA" a été cochée, l'adresse de l'entreprise. non ?

Je n'arrive pas à bien appréhender si la BDR permettra de produire les états dont j'ai besoin et si je peux faire en sorte que la saisie soit aisée pour les utilisateurs.
Je vais peut-être t'exposer l'objectif de cette base de données et les états et requêtes dont j'aurais besoin :

- Liste des formateurs, des formations (ça c simple)
- Liste des sessions ouvertes ou non avec nombre d'inscription
- Liste des nom et prénom des stagiaires présents à une session
- Edition des devis, convention de formation, factures.
- Chiffre d'affaires mensuel par commerciaux, par formation.
- Idem sous forme de graphique
- Marge restante sur chaque session totale et par commerciaux
- Idem sous forme de graphique
- Suivi des inscriptions : liste des inscription en cours sans retour de la convention de formation ou du chèque de caution
- Statistiques divers : nombre de stagiaires moyens par catégorie, par formation, par formateurs, par commerciaux, etc...

Je n'ai pas encore trop parlé de marge. La marge est pour moi, le chiffre d'affaire par session, déduction faite des frais de formateur (rémunération et frais divers), des frais de repas pour les stagiaires (le prix d'inscription comprend le repas au restaurant), les commissions des commerciaux.
Les frais de formateur changent à chaque session et sont impossibles pour moi à modéliser (trop de critères). C'est pour cela que les champs "Salaire_formateur" et "frais_formateur" sont dans la table "sessions".
Les frais de repas du groupe de stagiaire varient également pour chaque session.

[f-leb]

bonjour,

Envoyé par MachA57

Je ne comprends pas cette question désolé...

La table "sessions" contient le champ "lieu" qui est relié à la table "lieux" (voir mon fichier). Donc, je vais saisir dans la table "lieux", la liste de nos adresses dans les hôtels ainsi que celle de notre centre. Cette saisie ne se fait qu'une seule fois puisqu'on a une relation entre la table "sessions" et la table "lieux"

ok ok, c'est moi qui débloque

C'est pour cela que j'avais prévu la table "formation_inactive" avec un champ OUI/NON et une relation de type 1 - 1.
Il me semble que c'est mieux de procéder ainsi(créer une table distincte) que d'inclure le champ OUI/NON dans la table "formation" pour éviter, comme tu me l'as fait remarqué, les champs vides. C'est bien cela ?

oui mais là tu peux mettre ton champ [inactive] directement dans Formations.
[inactive]=vrai si la formation est inactive et [inactive]=faux sinon. [inactive] n'est jamais vide (faux<>null). Par contre la table formation_inactive peut être intéressante si tu as d'autres champs à compléter en cas d'annulation (dateAnnulation, motifAnnulation, RemplacementPrevue, ...)


je regarde le reste + tard.

à+

[MachA57]

Par contre la table formation_inactive peut être intéressante si tu as d'autres champs à compléter en cas d'annulation (dateAnnulation, motifAnnulation, RemplacementPrevue, ...)

Ah oui effectivement je n'y avais pas pensé :

Une formation peut etre inactive
Une session peut etre prévue mais inactive si pas assez de stagiaires
Une inscription peut etre inactive (sous-entendu, annulée)

Voici en pièce jointe la BDR modifiée

Par contre cette table "inactivité", pose le problème de la numérotation auto de la clé primaire. Car actuellement je peux avoir une session n°1 et une inscription n°1 (je peux pas avoir une formation n°1 car la clé primaire de la table "formation" est un code de type texte).
Ca me conduit à demander comment faire une numérotation automatique du type, pour un devis : DE201101, DE201102, DE201103, etc... ou pour une facture : FA201101, FA201102, etc....

[f-leb]

re moi,

Envoyé par MachA57

Une formation peut etre inactive
Une session peut etre prévue mais inactive si pas assez de stagiaires
Une inscription peut etre inactive (sous-entendu, annulée)

j'ai l'impression qu'on ne s'est pas compris sur ce coup là.
Si je prends les sessions et s'il s'agit seulement d'indiquer avec un booléen(vrai/faux) qu'une session est annulée ou pas, la table Inactivité est inutile. Il suffit de rajouter ton booléen dans la table Session:

Session(NumSession, DateSession, ..., Inactive)

Par contre, si tu as d'autres données à renseigner en cas d'annulation:

Session(NumSession, DateSession, ..., Inactive, DateAnnulation, MotifAnnulation, NouvelleDatePrevue, RemplacementPar,...)

tous les champs en gras seront bêtement vides si la session n'est pas annulée (parce que ces champs n'ont de signification qu'en cas d'annulation). C'est dans cette situation que je préconise: Session-1------1-AnnulationSession.

Je donne justement un exemple similaire ici sur une histoire de commande annulée.

Note que tu peux faire quelque chose de plus complet si tu remplaces le booléen par un champ CodeStatutSession, =1 si ok, =2 si annulée, =3 si reportée, =4 si...

Ca me conduit à demander comment faire une numérotation automatique du type, pour un devis : DE201101, DE201102, DE201103, etc... ou pour une facture : FA201101, FA201102, etc....

Le tuto qu'il faut: Numérotation personnalisée des enregistrements dans Access 2010

[f-leb]

Envoyé par MachA57

Je vais peut-être t'exposer l'objectif de cette base de données et les états et requêtes dont j'aurais besoin :

- Liste des formateurs, des formations (ça c simple)
- Liste des sessions ouvertes ou non avec nombre d'inscription
- Liste des nom et prénom des stagiaires présents à une session
- Edition des devis, convention de formation, factures.
- Chiffre d'affaires mensuel par commerciaux, par formation.
- Idem sous forme de graphique
- Marge restante sur chaque session totale et par commerciaux
- Idem sous forme de graphique
- Suivi des inscriptions : liste des inscription en cours sans retour de la convention de formation ou du chèque de caution
- Statistiques divers : nombre de stagiaires moyens par catégorie, par formation, par formateurs, par commerciaux, etc...

à vue de pif, je dirais que ton modèle comporte les données nécessaires pour gérer tout cela. Ce qui ne veut pas dire que tu obtiendra ces états&requêtes facilement, mais bon je suis assez confiant pour la suite

Les frais de formateur changent à chaque session et sont impossibles pour moi à modéliser (trop de critères). C'est pour cela que les champs "Salaire_formateur" et "frais_formateur" sont dans la table "sessions".
Les frais de repas du groupe de stagiaire varient également pour chaque session.

le salaire et frais dépendent donc de la session
session → Formation (la session "détermine" la formation)
Formation → Formateur

donc session → Formateur, à partir de la session on remonte au formateur.
Tes champs Salaire_Formateur et frais_formateur sont donc bien placés

Par contre, il faut que tu réfléchisses à certaines conséquences fâcheuses dans la situation suivante:
- un nouveau formateur remplace un autre formateur (qui part en retraite par exemple, le veinard). Si on se contente de changer le champ Formation.codeFormateur de la formation, il faut savoir qu'en l'état actuel de ta modélisation, toutes les sessions précédentes de cette formation seront attribuées à ce nouveau formateur qui vient à peine de prendre ses fonctions, tu imagines les conséquences statistiques ?
- même topo si les commerciaux changent.

[MachA57]

Merci pour ces infos. Je vais lire les tutos que tu m'a indiqué.

J'ai cogité un peu sur ta remarque concernant la gestion de l'historique des formateurs intervenant pour les formations et celui des commerciaux gérant les entreprises.

Pour l'instant, j'ai rajouté une table "dispense" intermédiaire entre les tables "Formations" et "Formateurs".
Le détail est en pièce jointe.

Qu'en penses-tu ?

Au fait, ce cas est un bon sujet d'exercice à proposer à des élèves non ?

[f-leb]

Une solution simple et bestiale consisterait à créer un pt'it peu de redondance en recopiant l'identifiant du formateur là ou c'est nécessaire.

Par exemple, on rajoute le champ Session.idFormateur. A chaque nouvelle session, le formateur en cours de la formation voit son identifiant recopié dans Session.idFormateur.
Si le formateur change, les sessions précédentes passées conservent ainsi l'identifiant du formateur.

Une autre solution:
Formation(CodeFormation, ..., #idFormateur, DateFormateurDepuis).

Dans Formation, on met toujours le formateur en cours, avec la date de sa prise de fonction.

On ajoute une table supplémentaire pour conserver l'historique des formateurs:
HistoriqueFormateur(#CodeFormation, DateDebut, DateFin, #idFormateur)

Si on change de formateur, on bascule le formateur dans la table historique et on met à jour le nouveau dans la table Formation.

Une bonne requête avec comparaison de dates permet alors de retrouver le formateur à n'importe quelle date.

[MachA57]

J'ai bien quand c'est simple mais je vais essayer de mettre en place la deuxième proposition.

Datedebut est une clé primaire dans ton exemple ???
La relation entre la table "formation" et la table "Historiqueformateur" est de type 1-1 non ?

Merci

[f-leb]

bonsoir,

DateDebut fait partie de la clé primaire, la clé primaire est sur le couple (CodeFormation, DateDebut).

Si cela te rassure, rajoute un numauto comme clé primaire:
HistoriqueFormateur(idHistoFormateur, #CodeFormation, DateDebut, DateFin, #idFormateur)
rassurant, mais bien inutile cet idHistoFormateur.

La relation est de type "un à plusieurs": Formation-1------∞-HistoriqueFormateur