Discussion :

[Yamina62]

Bonjour,

je dois créer une base de données pour gérer des formations . ce qui m'effraie c que j'ai X formations sur X sites sur X groupes sur X types d'apprenants. J'ai tenté d'utiliser le modèle de gestion de projet, mais je n'arrive pas à m'en sortir. Pouvez vous m'aider a trouver un téléchargement d'autre modèle (formation) que j'adapterais à mes besoins.
merci de votre aide

[marot_r]

Je n'ai pas dowload à te proposer mais voici comment je ferai en gardant cela ultra simple :

Table Formateur :
ClefFormateur
Autres info

Table Site :
ClefSite
Autres info

Table Type :
ClefType
Autres info

Table Groupe :
ClefGroupe
Autres info

Table Personne :
ClefPersonne
Autres info

Table Formation :
ClefFormateur
ClefSite
ClefType
ClefGroupe
ClefPersonne
Autres info (ex : date de formation)

Relation d'intégrité entre :
Formation et Formateur sur CleFormateur
Formation et Site sur CleSite
Formation et Groupe sur CleGroupe
Formation et Personne sur ClePersonne

Évidement c'est très très simple comme modèle.

A+

[Yamina62]

Pfff !! j'ai galéré avant de trouver sur le forum comment te remercier pour ta réponse.

Désolée, j'ai envoyé un msg privé.

Encore merci

Yamina

[marot_r]

Citation:
Envoyé par Yamina62
. de ta réponse, surtout que je suis autodidacte...

C'est ainsi que je suis entrain de la construire, sauf que j'ai ajouté le champ Site dans la table formation.

Un volume de formations sur 2 années et énorme.

Mon souci est que pour une formation de 27 groupes, chaque groupe est constitué de 15 apprenants. Si je rentre les noms des apprenants (via la liste déroulante prise dans la Table apprenants), le nombre des enregistrements rien que pour cette formation sera de 405 !!! Ma base données va-t-elle supporter ces centaines d'enregistrements ??

Merci encore de ton aide

Yamina

J'ai des BD qui utilise environ 100 000 enregistrements sans problème.

La vraie limitation de Access est que la BD ne peut pas dépasser 2 Go mais pour un usage courrant, c'est généralement bien suffisant.

A+
__________________
Vous voulez une réponse rapide et efficace à vos questions téchniques ? Ne les posez pas en message privé mais dans le forum, vous bénéficiez ainsi de la compétence et de la disponibilité de tous les contributeurs.

[Yamina62]

Bonjour René

j'ai bien avancé sur la base de ta réponse. Petit conseil à te demander :

Mon groupe 1 composé de 12 apprenants aura 5 sessions de formation étalées sur 3 mois, par ex. Ma question :

dois-je encore créer une table (sessions) avec date début et date de fin et la relier à la table (groupe) mais à quel champ ? Peur de tout mélanger en considérant que je vais avoir X groupes nommés 1 (sur plusieurs thèmes de formation)

merci et bonne journée

Yamina

[marot_r]

Probablement, si tes sessions indépendantes des groupes et que par exemple plusieurs grooupes peuvent participer à la même cession.

Dans ces cas là voilà comment on procède habituellement :

Table Session
ClefSession (numéro auto)
DateDebutSession
DateFinSession
Autres infos sur sessions

Table AssSessionGroupe
ClefAssSessionGroupe (optionnelle si tu définie un clef composée de ClefGroupe et ClefSession)
ClefGroupe
ClefSession

Avec une realtion d'intégrité entre Session et AssSessionGroupe
Avec une realtion d'intégrité entre Grouope et AssSessionGroupe

Cette architecture permet de regrouper les informations sur les sessions en une seule place. Si tu décides de changer les dates, tous les groupes se retrouvent automatiquement à avoir la nouvelle date.

La structure "idéale" pour une base de données est la "Troisième Forme Normale". Quand tu appliques ce modèle avec rigueur tu obtiens ceci : une information n'est qu'à une et une seule place. Chaque fois que tu as besoin de cette information ailleurs tu va la chercher là où elle est avec une référence (c-à-d une jointure dans une requête).

Dans l'exemple ci-dessus ton information est la date des sessions, et la référence est ClefSession de la table AssSessionGroupe. Avec ClefSession tue peux trouver la date.

Comme toutes les règles, il faut parfois savoir s'en affranchir. Par exemple tes sessions ont peut-être lieux dans plusieurs ville et une même ville peut peut-être accueillir plusieurs sessions. Si tu appliques strictement le modèle, tu devrais avoir une table des villes et n'avoir qu'une référence sur la table des villes dans ta table session.

La question est de savoir si tu devrais réellement avoir cette table. Mettons que tu a 3 villes et qu'elles ne changent jamais ou très très rarement. Il n'est peut-être pas intéressant d'avoir une table de référence des villes. Un champ "ville" de type texte dans la table session peut peut-être suffire dans ce cas et une liste déroulante dans le formulaire.

À contrario, tu pourrais avoir 2000 villes et en ajouter ou en retrancher régulièrement. Là il faudrait sans doute avoir une table des villes avec une relation d'intégrité pour être sur de ne pas retirer de la liste une ville qui accueille déjà des sessions.

C'est un dosage un peu délicat au début mais garde en tête que la structure idéeale est "une seule place pour l'information" après tu décides ou pas de t'éliogner de l'idéal.

A+