DocScoDoc/docs/DonneesModuleAssiduite.md

Document expérimental sur les données du module Assiduité de ScoDoc

Dans ce document je (Matthias Hartmann) détaillerais plusieurs méthodes pour enregistrer les données du module Assiduité et les utiliser. Je mettrai à jour ce document et je l'utiliserai lors de l'implémentation du cahier des charges.

Pour la suite du document je nomme plage l'objet représentant une absence/présence sur une période donnée.

Dans les diagrammes:

• les noms précédés par ? sont des valeurs optionnelles.
• les noms précédés par # sont des clés externes.
• les noms précédés par $ sont des clés primaires.

---

dev note (11/10/22): Les types des données ne sont pas forcément les bons, je n'ai pas encore regardé comment était organisée la BDD de ScoDoc

Représentation d'une assiduité et d'un justificatif

voir l'API ScoDoc -> ScoDoc9 API

Représentation des données (Version 4)

classDiagram

    class assiduites{
      $assiduiteid : Integer
      #etuid : Integer
      date_debut : DateTime
      date_fin : DateTime,
      etat : String
      #module?: Integer
      
    }
    class justificatifs{
      $justifid : Integer
      #etuid : Integer
      date_debut : DateTime
      date_fin : DateTime
      fichier? : Integer
      raison? : String
      #etat : Integer DEFAULT=0
    }
    class etat_justificatif{
      $etat_id : Integer
      desc : String
    }
    justificatifs --> etat_justificatif

Explications de la représentation

• Dans cette version, les objets en base de données suivent la représentation fait en json (dans l'API)
• Le fichier justificatif est toujours stocker sur le serveur et en base il est stocker sous la forme d'un identifiant unique.
• le champs etat de la table justificatif est une clé étrangère vers la table etat_justificatif qui contient les différents états (attente, validé, modifié, en cours . . . ), Cette table permettra aux utilisateurs d'ajouter eux même des états en fonction de leurs besoins. (deux états seront obligatoires : 0[Non Validé] 1[Validé] mais leurs noms pourront être changés.)

Représentation des données (Version 3)

classDiagram

    class plage{
      plage_id : Integer
      date_debut : DateTime
      date_fin : DateTime
      #etuid : Integer
      type : String
      ? #module_id : Integer
      ? #enseignant_id : Integer
    }
    class justificatif{
      $#etuid : Integer
      $date_debut : DateTime
      $date_fin : DateTime
      attachement : String
      #etat : Integer DEFAULT=0
    }
    class etat_justificatif{
      $etat_id : Integer
      desc : String
    }
    justificatif --> etat_justificatif

Explications de la représentation

• Dans cette représentation, une plage est complètement dissociée d'une formation / département. Elle repose uniquement sur un étudiant en particulier. On peut néanmoins spécifier l'enseignant et le module concerné par l'absence dans le but de produire des statistiques.
• Du coté des justificatifs, on a désormais un attribut etat plutôt qu'un booléen. Cet attribut est une clé étrangère lié à la table etat_justificatif. Cela permet alors d'avoir plusieurs états (Validé, Refusé, En Attente, Incomplet...) l'état 0 étant Pas encore étudié par exemple.

Problèmes de la représentation

• On utilise une nouvelle table pour stocker les différents états. A moins que cette table ne puisse être modifiée par les administrateurs de ScoDoc (ajouter des états pour des cas précis par IUT), on créer une table pour enregistrer des données statiques.

Améliorations potentielles

• A la place d'une table dans la BDD, on pourrait directement hard coder les états de justificatifs. Les états seront plus simple à accéder mais on perd l'aspect modification au cas par cas.

Représentation des données (Version 2)

classDiagram
    class plage{
      id_plage : Integer
      date_debut : DateTime
      date_fin : DateTime
      #id_dept : Integer
      #formsemestre_id : Integer
      #etuid : Integer
      type : String
      ? #id_module : Integer
      ? #id_enseignant : Integer
    }
    class justificatif{
      $#etuid : Integer
      $date_debut : DateTime
      $date_fin : DateTime
      attachement : String
      valide : bool DEFAULT=False
    }

Problèmes liés à la représentation

• L'export de la base de donnée avec les justificatif devient plus complexe (car on doit aller chercher les fichiers du dossier justificatifs)
• Même problème que la version 1 pour les requêtes

Représentation des données ( Version 1)

classDiagram
    class plage{
      id_plage : Integer
      date_debut : DateTime
      date_fin : DateTime
      #id_dept : Integer
      #formsemestre_id : Integer
      #etuid : Integer
      type : String
      ? #id_module : Integer
      ? #id_enseignant : Integer
    }
    class justificatif{
      #$id_plage : Integer 
      attachement : Blob
      valide : bool DEFAULT=False
    }
            

Problèmes liés à la représentation

• Quasiment l'ensemble des données sont stockées dans un même tuple
  Conséquence : chaque requête utilisant les données sera longue et lourde pour le gestionnaire de BDD
• Le stockage sour la forme de blob est très lourd pour la bdd ( cf : Benchmark des différentes méthode de stockage de fichier binaire sur progresql )
• Un justificatif doit être donné pour chaque absence (par exemple un arrêt maladie de plusieurs jours est présent dans la base autant de fois que l'étudiant a été absence à un cours )

Avantages liés à la représentation

• Peu ou pas de jointure à faire
• Ensemble des données facilement accessibles
• Une absence (plage: type=absence) est justifiée si un justificatif (justificatifs : idPlage={idAbsence}) est présent dans la base. Une absence peut être justifiée(par un étudiant par exemple) mais pas forcément validé par le corps enseignant / administratif. (justificatifs : valide=Faux)
• l'objet justificatif permet de stocker un fichier / un texte servant de justification (justificatifs : attachement={Blob}). L'utilisation d'un Blob permet de stocker virtuellement n'import quel type de fichier dans la bdd.

Améliorations potentielles

• Stocker les fichiers justificatifs dans un dossier sur le serveur plutôt que dans la base de donnée. On aurait alors une sauvegarde uniquement d'une chaîne de caractères (le chemin du fichier / la justification textuelle) au lieu de Blob prenant beaucoup de place et étant lourds à traiter.
  Le problème est qu'on perd la facilité d'accès et les vérifications opérées automatiquement par le gestionnaire de base de donnée.
• Définir une durée de validité pour chaque justificatif au lieu de lier le justificatif à une plage. (et donc lier un justificatif à un étudiant)
  Le problème est qu'on perd de la simplicité de selection (utilisation de l'id de la plage dans un cas et utilisation de 2 datetime dans un autre) Mais au moins on a pas besoin d'entrer plusieurs fois un même justificatif.