Discussion :

[metalman75]

Chers lecteurs du forum developpez, bonjour.
Je travaille dans une société de formation (en Mangement, Finances, marketing…) pour les salariés d’entreprises. Je souhaiterai developper une base de données sous access 2010 pour la gestion de nos clients et formations.
J’ai lu quelques tutorials sur votre forum et la chose la plus importante que j’ai comprise est que la phase d’analyse est cruciale avant d’entreprendre la réalisation d’une base de données.
Je souhaiterai donc solliciter votre opinion et votre aide donc sur ce sujet.
Nous proposons une centaine de formation (dans les différents domaines cités précédemment) déclinés en master professionnel et DESS (et séminaires mais cet aspect-là ne sera pas pris en charge dans notre réflexion).
Après analyse, j’ai détecté ces intervenants :
Stagiaires -> nom, prénom, date de naissance, lieu de naissance, adresse, n° téléphone, email, photo…
Entreprise (celle qui a envoyé le stagiaire)-> raison sociale, adresse, Secteur d’activité, CA, Capital social, email, adresse site Web…
Le produit -> Nature (Master ou DESS), discipline (GRH, FINANCE, MARKETING), Durée…
Nous pouvons lancer plusieurs master dans la même spécialité pour la même année, donc j’ai pensé à créer une autre table qui serait liée à la table produit et qui porterai le nom de promotion qui inclurait les infos suivantes : n° promotion, date début, date fin…
Sachant que pour un même master/DESS nous proposons plusieurs tarifications : en externat, en demi-pension et puis plusieurs autres formules en pension complète (chambre non aménagée, chambre aménagée…).
Questions :
Est-ce que mon analyse est cohérente jusque-là?
Ou dois-je inclure les tarifs selon l’option choisi (dans la table produits ?).

[f-leb]

Bonjour,

une table Promotion me semble être une bonne idée, puis on inscrit les stagiaires :
Stagiaire-1-----∞-Inscription-∞-------1-Promotion-∞-------1-Formation

Formation-∞-------1-Diplome (Master, DESS,…)
Formation-∞-------1-Specialite (management, finances, marketing,…)

[metalman75]

Merci beaucoup F-Leb pour votre aide.

donc si je comprend bien la table inscription est une table de jonction, elle permet de créer une relation plusieurs - à - plusieurs entre les tables stagaires et la table promotion ?

[f-leb]

Oui, c’est l’idée à affiner en fonction des règles de gestion :

Avant d’inclure le stagiaire dans une promotion, il va peut-être dans un premier temps s’inscrire dans une formation :

Stagiaire-1-----∞-Inscription-∞------1-Formation

Puis dans un deuxième temps, on l’inclut dans une promotion :
Stagiaire-1------∞-inclure-∞-------1-Promotion-∞-------1-Formation

Promotion(#idFormation, DateDebut, DateFin, …)
Inclure(idStagiaire, #idFormation, #DateDebut)

Avec un double -∞-----1- entre Inclure et Promotion

A voir…

[metalman75]

merci encore une fois f-leb pour votre aide très précieuse.
c'est vrai que la table inscription est une excellente idée, elle me permettrai de connaitre le nombre d'inscrit par produit (master finance, DESS marketing).

ce que je comprend moins c'est le rôle de la table indure F-leb, si vous voulez bien m'en expliciter le rôle et merci beaucoup encore une fois pour votre temps que vous consacrez à me répondre et à votre aide.

[metalman75]

ah pardon, j'ai oublié de vous demnder ce que vous vouliez dire "avec un double -∞-----1- entre Inclure et Promotion".

merci beaucoup pour votre aide encore une fois et excusez mon ignorance.

[f-leb]

Je reprends avec le schéma suivant :


Par contre, ce schéma suppose que la promotion soit connue au moment même de l’inscription (on ne peut pas renseigner Inscription.idFormation et laisser Inscription.DateDebut vide à cause de l’intégrité référentielle établie entre Inscription et Promotion).

Si au moment de l’inscription à une formation, on n’est pas encore capable de placer le stagiaire dans une promotion (parce qu’on doit attendre la clôture des inscriptions par exemple), il faudra modéliser autrement en mettant notamment en œuvre une table PLACEMENT. Dans ce cas-là, tu me dis et je reviens…

[metalman75]

merci f-leb pour votre aide.
je n'arrive pas à voir le schéma. ça met domain name unregistred.

[f-leb]

j'ai rajouté l'image en pièce-jointe dans mon précédent message

[metalman75]

bonjour f-leb.

effectivement, tu as anticipé l'existence d'une table placement. en effet, nous ne lançons une promotion dans une spécialité qu'après avoir réuni un groupe pédagogique d'au mois une dizaine d'inscrit(question de rentabilité comme tu peux présumer).

merci encore mille fois pour ta précieuse aide.

bon à week-end à toi.

[f-leb]

Bonsoir,

la tentation est grande mais on va éviter la table [Inscription] (idInscription, #idFormation, DateInscription, #idStagiaire, #idPromotion)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
idInscription	idFormation	DateInscription		idStagiaire	idPromotion
1		1		01/07/2011		3		4
2		1		24/06/2011		5

Pour la 2ème inscription, il faut attendre qu’il y ait un nombre suffisant de candidats avant de le placer… A moins qu’il n’y ait déjà plus de place pour lui, ou encore que son dossier a été rejeté, à moins que…

Ok, ce sera mieux si je rajoute un champ [EtatInscription] qui prendra sa valeur parmi {En attente, placé, refusé,…}
Tant que j’y suis, si le candidat est placé je souhaite connaître la date de placement [DatePlacement].
Ah et puis si le dossier est rejeté je souhaiterais aussi connaître le motif [MotifRefus], et puis…

[InscriptionFourreTout] (idInscription, #idFormation, DateInscription, #idStagiaire, #idPromotion, EtatInscription, DatePlacement, motifRefus,…)

Et on se débrouille dans le code pour éviter de saisir des [DatePlacement] lorsque le dossier est rejeté, de saisir un [motifRefus] lorsque le candidat est placé etc.

Et plus tard lorsqu’on fouinera dans les tables, on se demandera ce qu’il faut penser de tel candidat placé dans une promotion mais sans [DatePlacement] renseignée…

N’étant pas fan de ce genre de pratiques dans les tables Access, j’essaye d’améliorer le schéma, par exemple:


Un placement est relatif à une inscription et une seule, une inscription est suivie (ou non) d’un placement.

Voilà un schéma qui commence à devenir lisible, on sépare ce qui relève du dossier d’inscription et ce qui relève du placement du stagiaire. Sans ambiguïté, les inscriptions suivies d’un placement sont dans la table… [Placement]. Dans ce cas la promotion doit être obligatoirement renseignée (contrainte de clé étrangère avec valeur à Null non autorisée, à définir dès la conception de la table en mode Création).
Si la [DatePlacement] doit aussi être obligatoirement renseignée, on mettra également en œuvre la contrainte "Null interdit" dès la création de la table (contrainte que l’on ne pouvait implémenter dans la table fourre-tout à cause des inscriptions en attente ou refusées).

Dans le futur, il sera également plus pertinent de raccorder certaines tables à la table [Placement] plutôt qu’à la table [Inscription] (parce que leurs contenus ne concerneront que les stagiaires placés).

effectivement, tu as anticipé l'existence d'une table placement…

oui mais le schéma est encore à modifier/améliorer car tu as certainement anticipé d’autres règles de gestion sans nous en parler jusqu’à présent.
J’ai anticipé des [DatePlacement], [EtatInscription] mais quelles sont les autres données à conserver dans la base (dictionnaire de données) ?
Peut-il y avoir des dossiers rejetés ?
Peut-on placer des stagiaires non-inscrits ?
Peut-on placer des stagiaires dans des formations autres que celles qui figurent dans le dossier d’inscription ? Si oui, dans quels cas ?
Que deviennent les inscriptions si le nombre de demandes est insuffisant ?
Un candidat doit-il confirmer son inscription ? Quand ? Quelles sont les conséquences sur les données s’il ne confirme pas ?

Etc etc etc…