[AC-2010] Gestion de classe enseignant

[mamat59]

bonjour, je me casse la tête depuis qqs temps sur access ...
pour me faciliter la tache, je souhaite gérer pas mal de choses sur ma classe, notamment les TP:

J'ai donc créé les tables :
* Elèves
* TP : nom, support, n° de la série
* Séances : date des séances disponibles pour les TPs (une série de TP court sur plusieurs semaines, avec une rotation des groupes sur chaque TP)

C'est quand je dois "mélanger" tout ça que ça se complique!
(peut-être ai-je une ambition démesurée):
>Je souhaiterai attribuer un groupe à chaque élève (sachant que les groupes changent au cours de l'année selon la série)
>Je voudrais rentrer l'ordre des TP (toujours par série) pour chaque groupe (et tant qu'à faire, vérifier que tous les TPs sont faits par tous les groupes et que le même TP n'est pas fait en même temps par 2 groupes)
>enfin, dans un formulaire, je souhaiterai choisir : la série puis le groupe puis le TP pour enfin pouvoir noter et mettre une observation sur chaque élève du groupe.

Avez-vous déjà vu quelque chose qui ressemblait à ça? ou y a t-il qqchose qui s'en rapprocherait?

Merci par avanc

[f-leb]

Bonjour collègue,

c'est un sujet pour moi ça!

... et c'est pas gagné, je joins un schéma et un fichier pour voir.

Essaye de remplir les tables "à la main" pour voir si le schéma convient.

On suppose que les tables Eleve et TP sont remplies.

Ensuite, on remplit les tables :
- Serie,
- SerieTP, où tu mets les différents TP de ta série
- tu planifies les rotations (1 rotation=1 séance à une date)
- Groupe, tu crées les groupes 1, 2, ... pour la série
- CompositionGroupe, j'ai mis un index Unique=Oui sur (idSerie, idEleve) pour éviter de mettre un même élève dans deux groupes différents pour la même série.
- reste PlanningPassage dont le remplissage pourra être automatisé, avec un index Unique=Oui sur (idSerie, NumGroupe, idTP) car dans une série, un groupe ne fait un TP qu'une seule fois.

Tu testes, tu me dis si le schéma convient et on complètera avec les évaluations.

[mamat59]

Merci pour cette réponse!
je vais essayer ce soir et mets les avancées...

[mamat59]

Voilà : testé avec 6 élèves, 3 groupes, 2 séries de 3 TP... tout marche (voir planning TP en screenshot)

La technique de relations type "plusieurs à plusieurs" en passant par des tables intermédiaires! déjà fait mais pas à ce point (je débute sans formation initiale...)


Le must maintenant :
Pouvoir rentrer tous à travers des formulaires (en choisissant avant la série!) sans avoir à rentrer les codes -clés!- mais en ayant directement accès aux groupes, aux TPs...)

Et en dernier : pouvoir pour chaque élève : renter une note, des remarques sur le compte-rendu...


Après j'essaierai de me débrouiller pour me rapproprier tout ça et faire ma gestion de classe complètement via Access

Merci grandement en tout vas pour le coup de main!!

Je mets mon fichier

[f-leb]

bonsoir,

petite correction à apporter sur la table PlanningPassage:

- clé primaire sur les 4 champs (NumRotation, idSerie, NumGroupe, idTP)
- deux contraintes d'unicité (propriété "Unique"=Oui, cf tableau des index ci-joint)

Contrainte Unicité sur (idSerie, NumGroupe, idTP)

Code :

1
2
3
4
NumRotation   idSerie   NumGroupe   idTP
   1             1          1        12
   2             1          1        8
   3             1          1        12  <--impossible, le groupe 1 a déjà réalisé le TP n°12 à une rotation précédente.

Contrainte Unicité2 sur (idSerie, NumRotation, NumGroupe)

Code :

1
2
3
4
NumRotation   idSerie   NumGroupe   idTP
   1             1          1        12
   2             1          1        8
   2             1          1        14  <--impossible, lors de la rotation 2, le groupe 1 ne peut réaliser deux TP à la fois (n°14 et n°8).

je réfléchis à la suite, à +.

[f-leb]

Concernant les évaluations (voir pièces-jointes).

Le schéma est un peu lourd mais au moins, grâce au jeu de l’intégrité référentielle, tu ne risques pas de noter un élève sur un TP qu’il n’a jamais réalisé

[alassanediakite]

salut
f-leb puis-je avoir une explication des rôles des tables "planingpassag" et "rotation". Le schéma ne peut-il pas être simple en évitant trop de jointures?
Merci d'avance.

[f-leb]

Salut Alassane,

Une rotation = une séance
Par exemple, pour la 1ère série de TP si on imagine 3 TP dans une classe avec 3 groupes, on peut organiser un système tournant sur 3 rotations et proposer le planning de passage suivant :

Code :

1
2
3
4
5
6
7
8
9
        | Rotation 1 | Rotation 2 | Rotation 3 |
Série 1 | 01/09/2011 | 08/09/2011 | 15/09/2011 |
--------|------------|------------|------------|
  TP 1  |   Gr. 1    |   Gr. 2    |   Gr. 3    |
--------+------------+------------+------------+
  TP 2  |   Gr. 2    |   Gr. 3    |   Gr. 1    |
--------+------------+------------+------------+
  TP 3  |   Gr. 3    |   Gr. 1    |   Gr. 2    |
--------+------------+------------+------------+

D’où la table PlanningPassage(Numrotation, idSerie, NumGroupe, idTP)

Envoyé par alassanediakite

Le schéma ne peut-il pas être simple en évitant trop de jointures?

Oui, on peut…mais il ne faut pas passer à côté des conséquences. Et puis que signifie "trop de jointures" dans un SGBD qui est conçu justement à faire des jointures à tour de bras ?

Si le schéma est avec tout plein de traits -∞------1- partout, c’est aussi pour imposer un certain nombre de contraintes d’intégrité uniquement par le jeu de l’intégrité référentielle.

Exemples de boulettes évitées uniquement grâce au schéma :
- Planifier une 4ème rotation dans une série de TP qui n’en comporte que 3
- Planifier le groupe 4 dans une série avec 3 groupes
- Planifier un TP qui n’est pas prévue dans la série
- Noter un élève sur un TP qu’il n’a jamais réalisé (un élève lésé=2 parents sur le dos)
- Etc.

Après je suis prêt à discuter sur une autre alternative "plus simple" mais je ne comprends pas où est le problème avec ces jointures que tu trouves trop nombreuses mais qui se construisent pourtant en 3 clics de souris dans la fenêtre des relations. Quelque chose qui m’échappe … un problème au niveau des requêtes ? de l’IHM ?

[alassanediakite]

Salut Fabien
je propose ça...

[f-leb]

Re,

Ok, je vois, c’est vrai qu’il y a moins de traits et qu’une mouche qui voudrait traverser la fenêtre des relations d’Access a beaucoup moins de chance de s’emmêler dans les filets -∞-----1- de mon schéma .

Mais du coup…

Envoyé par f-leb

Exemples de boulettes évitées uniquement grâce au schéma :
- Planifier une 4ème rotation dans une série de TP qui n’en comporte que 3
- Planifier le groupe 4 dans une série avec 3 groupes
- Planifier un TP qui n’est pas prévue dans la série
- Noter un élève sur un TP qu’il n’a jamais réalisé (un élève lésé=2 parents sur le dos)
- Etc.

En dehors des formulaires, on autorise la saisie de telles boulettes.

Alors je sais qu’autoriser la saisie en dehors des formulaires ne fait pas très pro mais il faut remettre l’application dans le contexte professionnel dans lequel nous évoluons avec mamat59 (@mamat59 : à partir de maintenant je vais écrire "on" mais tu n’hésites pas à me corriger si je raconte des bêtises à ton sujet).

Développer n’est pas notre métier, il s’agit d’applications personnelles (et souvent jetables à chaque réforme imposée par la grande Maison Ednat, c’est pour dire si on a que ça à fou#@¤).

Bref, on n’a pas toujours l’occasion et/ou le temps de finaliser les applications avec tous les contrôles, formulaires et sécurités que requièrent normalement les applications professionnels. On bricole un peu quoi …

Et il y a 2, 3 trucs qu’on ne peut tolérer comme :

Envoyé par f-leb

- Noter un élève sur un TP qu’il n’a jamais réalisé (un élève lésé=2 parents sur le dos

Voire des boulettes encore plus sensibles qui pourraient nous amener au peloton d’exécution (j’ai par exemple développé une petite appli de gestion spécifique sur le tas concernant près de 300 élèves de mon établissement et qui m’a empêché de dormir quelques nuits).

Bref, si par le jeu de l’intégrité référentielle je peux interdire, et ceci quel que soit la face par laquelle j’attaque la base, de saisir ce genre de boulettes, je le fais même si mes schémas semblent avoir été tissés par Spiderman. Question de survie, les données d'abord, je blinde avec normalisation, intégrité référentielle, index, CHECK, triggers(Access 2010) et tout le toutim…

Mais sinon, c’est quoi le problème avec les schémas "spiderman" ? Ou quel est l’avantage d’un schéma "plus simple" ?

Bien à toi,

Fabien

[alassanediakite]

Salut Fabien et Mamat
Ces deux points...

Exemples de boulettes évitées uniquement grâce au schéma :
- Planifier une 4ème rotation dans une série de TP qui n’en comporte que 3
- Planifier un TP qui n’est pas prévue dans la série

...sont bien gérés par mon schéma.

J'ai pas bien compris ce point...

- Planifier le groupe 4 dans une série avec 3 groupes

Sur ce point...

- Noter un élève sur un TP qu’il n’a jamais réalisé (un élève lésé=2 parents sur le dos)

...il faut au préalable une donnée (ex: liste de présence au TP) pour justifier qu'il a participé ou non. Votre champ "commentaire" de la table "compterendu" peut bien faire cela.
Pour le reste je vous rappelle (je ne sais plus de quelle loi) qu'en bases de données l'utilisateur n'a accès aux données qu'à travers les vues. De plus, pour un débutant il faut être simple!

[mamat59]

Bonjour!!
j'essaye au fur et à mesure vos schémas avec mes 2 premières rotations de TP!!
L'entrée des données en mode feuille est un peu rébarbatif!
j'ai essayé de faire des formulaires (il faut que je creuse encore un peu dans les sous formulaires et dans l'automatisation de certaines rentrées?)... à voir...

Merci en tout cas pour vos coups de main!
je vous tiens au courant de la suite!

[f-leb]

bonsoir à tous,

@Alassane,

je reprends un bout de ton schéma :


Dans CompteRenduTP(idComposition, idPlanning, note), et en dehors des formulaires, tu n’as aucun contrôle de cohérence sur le couple (idComposition, idPlanning).
Tu peux donc saisir la note d’un élève n°5 appartenant au groupe n°3 sur une ligne de planning avec un groupe n°4 constitué des élèves n°2,3 et 6. L’élève n°5 s’en tire bien mais il est noté sur un TP qu’il n’a pas réalisé d’après le planning.

Tu peux me rétorquer que la saisie doit se faire uniquement par l’intermédiaire des formulaires mais imposer une programmation sans faille à un débutant pour préserver la cohérence de ses données, ce n’est pas un cadeau non plus.


Je persiste et signe, le compte-rendu concerne un groupe de TP prévu dans mon planning et concernera forcément un élève de ce groupe.
Tant pis si les mouches s’engluent dans la toile tissée par les -1----∞-, ceinture et bretelles pour les données, surtout celles du débutant.

Envoyé par alassanediakite

De plus, pour un débutant il faut être simple!

Bon conseil, faisons simple…

Envoyé par f-leb

Code :

D’où la table PlanningPassage(Numrotation, idSerie, NumGroupe, idTP)

Comment faire plus simple pour le codage de ce planning ? ça se lit naturellement, lors de la 1ère rotation de la 1ère série, le groupe 1 passe sur le TP 1 etc…

Supposons maintenant que je veuille une requête qui me retourne la moyenne des notes obtenues pour chaque TP (regroupement sur idTP et moyenne sur Note):

Code :

1
2
3
4
NomTP	     MoyenneNote
TPmachin	12,8
TPTruc		11,4
…

Avec ton schéma, les tables qui participent à la requête sont :


La même avec mon schéma :


Laquelle est la "plus simple" ?

[alassanediakite]

Salut Fabien
Mes excuses pour la lenteur.
Pouvez-vous me donner la requête qui donne...

Code :

1
2
3
4
5
6
7
8
9
| Rotation 1 | Rotation 2 | Rotation 3 |
Série 1 | 01/09/2011 | 08/09/2011 | 15/09/2011 |
--------|------------|------------|------------|
  TP 1  |   Gr. 1    |   Gr. 2    |   Gr. 3    |
--------+------------+------------+------------+
  TP 2  |   Gr. 2    |   Gr. 3    |   Gr. 1    |
--------+------------+------------+------------+
  TP 3  |   Gr. 3    |   Gr. 1    |   Gr. 2    |
--------+------------+------------+------------+

Pour les deux solution: entre un effort de bonne programmation au début et des galères permanent dans l'exploitation que préférez-vous?
En plus si on fait le calcule des poids des données et indexes on verra que votre schéma pourra doubler le mien.
@+

[f-leb]

Bonsoir Alassane,

En plus si on fait le calcule des poids des données et indexes on verra que votre schéma pourra doubler le mien.

Doubler ? Et pourquoi pas tripler tant qu’on y est … C’est quoi le mode de calcul ?

On peut rappeler avant de considérer les index comme des poids morts qu’ils servent avant tout à accélérer les recherches.
Et quand on compte le nombre d’index sur nos deux schémas :
- Schéma Fabien : 13 index répartis dans 9 tables, dont 3 dans PlanningPassage
- Schéma Alassane : idem, 13 index répartis dans 8 tables (table Rotation supprimée !?), on ne dépasse pas deux index par table.

En "simplifiant" mon schéma, les numéros auto rajoutés idcomposition, idserieTP, idPlanning deviennent autant d’index supplémentaires (voir la discussion toute fraîche ici)

Quant au "poids des données", de quoi parle-t-on là encore ? De la taille du fichier mdb ou accdb, du volume des tables ?

Pour les deux solutions: entre un effort de bonne programmation au début et des galères permanent dans l'exploitation que préférez-vous?

Mais … où donc vois-tu des galères dans l’exploitation ?

PS : quant au tableau, je l’ai réalisé avec une requête analyse croisée. Pourquoi cette question ?