Discussion :

[DamKre]

Bonjour,

J'ai un nouveau problème, similaire à celui récemment posté, mais néanmoins différent.

Dans une base de gestion des élèves ( oui, toujours ^^ ), on encode le comportement.
Chaque élève dispose de 120 points. Chaque faute lui fait perdre des points.

Pour ce faire, on se rend dans sa fiche, et plus précisément dans le sous-formulaire d'encodage.

Voici, par exemple ( et en simplifié ) ce que cela donne pour l'élève :

Date	Prof	Fait	Points retirés
01/09/2017	Prof1	Bavardage	1
02/09/2017	Prof1	Bavardage	2
02/09/2017	Prof2	Mange en classe	1
03/09/2017	Directeur	Bagarre	10
...	...	...	...

Le but est d'avoir une alerte chaque fois que l'élève a perdu un multiple de 20 points ( cette valeur 20 peut changer ; elle est stockée dans une table paramètres ).

Sauf erreur de ma part, la fonction mod, lancée après insertion, renseignée dans cette discussion ne convient pas : si l'élève a perdu la somme de 39 points, qu'on lui en enlève ensuite 2, Mod =/= 0 et l'alerte 40 ( 2X20 ) ne se lancera donc pas.

Voyez-vous une solution à laquelle je n'aurais pas pensé ?

Merci de votre aide !

[ClaudeLELOUP]

Bonjour,

On pourrait par exemple ajouter une colonne à cette table (SeuilFranchi).
Lorsqu’une alerte est donnée, on stockerait dans SeuilFranchi de l’enregistrement déclencheur le seuil qui a été dépassé (dans ton exemple un multiple de 20).
À chaque nouvel enregistrement, on lance un processus qui calcule :
nz(dernier SeuilFranchi) ;0) + la valeur du paramètre – somme des pénalités.
Si le résultat >0, rien ne se passe.
Si le résultat <=0, on déclenche une alerte
et on mémorise (dernier SeuilFranchi) + la valeur du paramètre dans SeuilFranchi de l’enregistrement en question.

[tee_grandbois]

Bonjour,
une autre possibilité sans stocker de résultat : la somme des points retirés divisée par la valeur du paramètre donne un nombre dont la valeur entière (Int(X)) du calcul donne le nombre de fois que l'alerte est franchie :

Code :

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

1
2
3
 select Int(Sum([nb_points])/DFirst("valeurparam","tab_param","id_param=1")) AS SeuilAlerte
...
HAVING Int(Sum([nbre_points])/ DFirst("valeurparam","tab_param","id_param=1"))>1

[ClaudeLELOUP]

Bonjour Guy,

Mais comment sais-tu que l'alerte n'a pas déjà été donnée ? Il faut mémoriser quelque part le nombre d'alertes qui ont été lancées et si ce nbre est égal à celui que tu calcules, il ne faut rien faire.

[tee_grandbois]

Bonjour Guy,

Mais comment sais-tu que l'alerte n'a pas déjà été donnée ? Il faut mémoriser quelque part le nombre d'alertes qui ont été lancées et si ce nbre est égal à celui que tu calcules, il ne faut rien faire.

Bonsoir Claude,
tu as raison il faudrait au mois un champ de stockage de la dernière alerte, une date par exemple, qui pourrait de ce fait servir de filtre pour le calcul des pénalités.

Après réflexion, la solution que je propose n'est pas adaptée et ne fonctionne pas pour le cas de figure précité par DamKre (alerte à 39 points dont on ôte ensuite 2 points) car dans ce cas aussi les 2 points vont déclencher l'alerte à une date donnée mais le point supplémentaire ne sera pas répercuté sur la date la plus proche.
La solution de Claude semble être la mieux adaptée.

[DamKre]

Bonjour à tous les deux,
Merci d'avoir pris le temps de réfléchir à ce cas.

Avant de mettre en place un champ "seuil franchi", plusieurs réflexions quant à ce qui va se passer sur le terrain :

• Il peut arriver qu'on retire une sanction ( et donc, que l'élève récupère le(s) point(s) perdu(s) ). Et ce n'est pas forcément la dernière sanction qui est annulée. Ainsi, la sanction du 5/09 peut être annulée, mais on conserve les précédentes et les suivantes.
  
  --> le champ seuil franchi est-il toujours la solution ?
• Les élèves sont sanctionnés en cas de retard à l'école. Si je veux prévoir une alerte à chaque pallier de 5 retards ( 5 ou 7 ou 12, ... ), on multiplie alors les champs "seuil franchi" : [seuilfranchi_general], [seuilfranchi_retard], [seuilfranchi_violence]...
  
  --> est-il intéressant de multiplier ainsi les champs "seuil franchi" ?

Petite idée s'inspirant alors du seuil franchi proposé par Claude :

• La procédure de lancement ( ou non ) d'alerte se fait sur sortie du sous-formulaire d'encodage.
  --> Elle tient compte des points qui ont été récupérés.
• On regarde dans le champ [TableEleves]![ChampSeuilFranchi_Comportementgénéral] la valeur du dernier seuil et la valeur des points perdus.
  
  • Si la dernière alerte était "20" et qu'on a atteint ou dépassé 40, on lance l'alerte ;
  • Si la dernière alerte était "20" et qu'on atteinte pas 40, pas d'alerte ;
  • Si la dernière alerte était "40", que l'élève a récupéré des points et qu'on est descendu en-dessous de 40, pas d'alerte ;
  • Si la dernière alerte était "40", que l'élève a récupéré des points et qu'il en a reperdu ensuite, qu'on atteint ou dépasse à nouveau "40", pas d'alerte ( l'alerte 40 ayant déjà été lancée ).
    
    --> Que pensez-vous de ce principe ?
  
  
• Y a-t-il une autre solution que d'ajouter 5-6 champs "Seuil franchi" ( un par type d'alerte ) dans la table des élèves, déjà bien chargée en différents champs ( elle en a déjà plus de 60 et je suppose que le nombre de champs est limité ^^ ) ?

Que pensez-vous de toutes ces réflexions ?
Merci du temps que vous allez passer à ce cas ;-)
Bon dimanche !

[ClaudeLELOUP]

Bonjour,

Pas simples tes punitions !

Y a-t-il une autre solution que d'ajouter 5-6 champs "Seuil franchi" ( un par type d'alerte ) dans la table des élèves, déjà bien chargée en différents champs

Dans la mesure où il y a différentes natures de pénalités avec des traitements différenciés, il faut bien mémoriser quelque part les actions qui ont été déclenchées pour chaque nature.

La procédure de lancement ( ou non ) d'alerte se fait sur sortie du sous-formulaire d'encodage.
--> Elle tient compte des points qui ont été récupérés.

C'est bien l'endroit auquel je pensais.

elle en a déjà plus de 60 et je suppose que le nombre de champs est limité ^^

limite : 255

Peux-tu montrer les relations de tes tables (si possible avec le nom des différentes colonnes) ?

[DamKre]

Re-bonjour !

Pas simples tes punitions !

Je te confirme, et la réalité de terrain te surprendrait parfois !
Je m'arrache parfois les cheveux ;-)

Peux-tu montrer les relations de tes tables (si possible avec le nom des différentes colonnes) ?

Voici une copie des tables qui concernent les procédures en discussion.



En espérant que cela t'aide à y voir plus clair ;-)

[ClaudeLELOUP]

Merci !

Ça doit mûrir...

[DamKre]

Bonjour Claude,

Je ne sais pas si tu as eu une idée à ce sujet, mais j'ai eu celle-ci entretemps :

Une table "T_Alertes_Seuils" :

Id_ASE	Id_Ele	Catégorie Alerte	Seuil franchi
1	247	Perte de points	20
2	241	Perte de points	20
3	247	Perte de points	40

A la sortie de l'encodage, on teste si le seuil a été franchi ( recherche table seuil ).

• Si oui -> on lance l'alerte PUIS on l'insère dans la table des seuils
• Si non -> on ne lance pas l'alerte

Que penses-tu de cette solution, qui ne surcharge pas la table des élèves ?

[ClaudeLELOUP]

Bonjour,

Tu parlais de plusieurs types de pénalités avec des périodicités de signalement différentes : parce qu'il mange (des pas de 20), parce qu'il arrive en retard (des pas de 5...

Et que parfois, il y a des remises de peine.

Quoi qu'il en soit, je suis convaincu que la table T_Eleves n'est pas l'endroit pour stocker les infos. (Ta nouvelle proposition semble aussi aller dans ce sens.)

[DamKre]

Re-bonjour,

Tu parlais de plusieurs types de pénalités avec des périodicités de signalement différentes : parce qu'il mange (des pas de 20), parce qu'il arrive en retard (des pas de 5...

Voici par exemple ( en simplifié ) le cas d'un élève, qu'on encoderait :

Date	Fait	Points perdus
01/09	Retard	1
02/09	Retard	1
02/09	Bavardage	1
02/09	Bagarre	5
03/09	Garde sa veste	1
05/09	Retard	1
10/09	Retard	1
10/09	Retard	2
12/09	Bavardage	1
12/09	Bavardage	2
13/09	Bagarre	5

Dans son cas, à la sortie du formulaire d'encodage, après avoir encodé ce qui suit :

• sa cote d'éducation passe de 120 à (120-21 -> ) 99
• déclenchement d'une alerte "Points perdus" car il a atteint un pallier de 20 points perdus, et ce peu importe les motifs
• déclenchement d'une alerte "Retards" car il a été en retard 5 fois

Quoi qu'il en soit, je suis convaincu que la table T_Eleves n'est pas l'endroit pour stocker les infos. (Ta nouvelle proposition semble aussi aller dans ce sens.)

La table dont je te parlais peut-elle donc convenir ?

Du coup, il me semble que ta proposition suivante, en l'adaptant, peut convenir :

On pourrait par exemple ajouter une colonne à cette table (SeuilFranchi).
Lorsqu’une alerte est donnée, on stockerait dans SeuilFranchi de l’enregistrement déclencheur le seuil qui a été dépassé (dans ton exemple un multiple de 20).
À chaque nouvel enregistrement, on lance un processus qui calcule :
nz(dernier SeuilFranchi) ;0) + la valeur du paramètre – somme des pénalités.
Si le résultat >0, rien ne se passe.
Si le résultat <=0, on déclenche une alerte
et on mémorise (dernier SeuilFranchi) + la valeur du paramètre dans SeuilFranchi de l’enregistrement en question.

On aurait dès lors là une solution ( sans doute tordue et perfectible, j'en conviens ) qui fonctionne ( quitte à l'améliorer ultérieurement ).
Y vois-tu un inconvénient ?

[ClaudeLELOUP]

Peux-tu préciser si ma synthèse est complète :

- chaque fait coûte un nombre de points, par pas de 20 points perdus, on émet une alerte ;
- de plus pour certains faits (ex. Retard), lorsque le nombre d'occurrences (rien à voir avec les points) atteint un plafond (ici 5) il faut aussi émettre une alerte ;
- d'une mise à jour à l'autre, il se peut qu'on ait supprimé des faits anciens dans la liste que tu montres.

Y a-t-il d'autres faits semblables à Retard ?

La table que tu montres est-elle complétée au jour le jour ?

À la réflexion, l'idée de la colonne « SeuilFranchi » n'est pas idéale => quid si on a mémorisé le seuil sur un enregistrement qui doit être supprimé ultérieurement ? => probablement une table avec les alertes émises.

[DamKre]

Peux-tu préciser si ma synthèse est complète :

- chaque fait coûte un nombre de points, par pas de 20 points perdus, on émet une alerte ;
- de plus pour certains faits (ex. Retard), lorsque le nombre d'occurrences (rien à voir avec les points) atteint un plafond (ici 5) il faut aussi émettre une alerte ;
- d'une mise à jour à l'autre, il se peut qu'on ait supprimé des faits anciens dans la liste que tu montres

Cela est complet.

J'ajoute au niveau de la suppression d'anciens faits que :

• c'est chose rare
• que, par exemple, si l'élève X a atteint le seuil "40", puis récupère des points, puis ré-atteint le seuil "40", inutile de faire une nouvelle alerte 40. La suivante sera 60.

Y a-t-il d'autres faits semblables à Retard ?

Ce n'est pas prévu pour le moment. Sur demande, et si les alertes telles que prévues actuellement donnent satisfaction, je pourrais prévoir d'autres alertes thématiques.

La table que tu montres est-elle complétée au jour le jour ?

Idéalement, le responsable de chaque élève devrait la compléter au jour le jour. Dans les faits, certains ne le font jamais ( ), d'autres essaient de le faire "régulièrement".

À la réflexion, l'idée de la colonne « SeuilFranchi » n'est pas idéale => quid si on a mémorisé le seuil sur un enregistrement qui doit être supprimé ultérieurement ? => probablement une table avec les alertes émises.

La table des alertes est créée. Tu me conseilles alors d'ajouter une colonne "Seuil" pour l'alerte ?
Du coup, recherche dans cette table alors ;-)


Claude, je te remercie d'ores et déjà pour le temps passé et à passer encore ( si tu le veux bien ^^ ) sur mon problème !

[ClaudeLELOUP]

j'ajoute au niveau de la suppression d'anciens faits que :

• c'est chose rare
• que, par exemple, si l'élève X a atteint le seuil "40", puis récupère des points, puis ré-atteint le seuil "40", inutile de faire une nouvelle alerte 40. La suivante sera 60.

Oui, mais il a atteint -42 à cause de 3 bagarres (10 points). Il s’est avéré que chaque fois, il était en légitime défense et on lui a finalement supprimé ces pénalités.
Il est maintenant à -12… D’ici à -60, il peut donc manger à l’aise à tous les cours ? Il me semble qu'à -20, il mérite un carton !

La table des alertes est créée. Tu me conseilles alors d'ajouter une colonne "Seuil" pour l'alerte ?

Attendons un peu l’avis de Guy.

[tee_grandbois]

Bonsoir Claude,

Attendons un peu l’avis de Guy

j'avais déjà plus ou moins lâché l'affaire aux mains d'un "Modéliseur" plus expert ... Je peux malgré tout essayer de donner un coup de main.

Cela étant, il faudrait éclaircir le point concernant la suppression d'anciens faits, car même si un évènement est chose rare, en informatique, il suffit d'une fois pour devoir le coder pour toujours ...

J'ajoute au niveau de la suppression d'anciens faits que :

c'est chose rare
que, par exemple, si l'élève X a atteint le seuil "40", puis récupère des points, puis ré-atteint le seuil "40", inutile de faire une nouvelle alerte 40. La suivante sera 60.

il faudrait que DamKre précise comment sont inscrits la suppression d'anciens faits.

si l'élève X a atteint le seuil "40", puis récupère des points, puis ré-atteint le seuil "40"

pour ce dernier cas, il suffirait de mémoriser le dernier niveau atteint et le mettre à jour le niveau uniquement si le seuil directement supérieur est atteint, un peu comme les niveaux d'impayés dans certains établissements bancaires ou la gestion de paiement des loyers en immobilier ...

[ClaudeLELOUP]

Bonjour,



Je ferais comme ceci :

À la fermeture du formulaire qui sert à gérer T_Penalités, déclencher un code qui :
- pour chaque catégorie de pénalités, calcule le score actuel ;
- compare ce score avec le dernier seuil atteint pour cette pénalité :
-- si le score est égal au dernier seuil atteint => statu quo => ne rien faire,
-- si le score est inférieur au dernier seuil atteint => il y a eu remise de peine => rétablir le seuil juste inférieur au score,
-- si le score est supérieur au dernier seuil atteint => vérifier qu’il ne dépasse pas le seuil suivant :
--- s’il ne le dépasse pas => ne rien faire,
--- s’il le dépasse, ajouter ce seuil dans dans T_Alertes et émettre un carton.

[DamKre]

Bonjour !

Merci donc de votre aide ; je m'emploie à mettre en place tout cela... ;-)