Modélisation des Données
Ce document présente la modélisation des données utilisée dans le projet Moodle. La base de données MongoDB étant orientée documents, nous avons adopté une approche de modélisation adaptée à ce paradigme, tout en maintenant des relations cohérentes entre les différentes entités.
Schéma Général de la Base de Données
Le diagramme UML ci-dessous représente les principales entités de notre base de données et leurs relations :
Description des Entités Principales
Utilisateur (User)
C'est l'entité principale représentant les utilisateurs du système. Elle contient les informations de base sur chaque utilisateur, telles que :
ine: Identifiant National Étudiant
email: Adresse email unique
name: Nom de famille
firstname: Prénom
role: Rôle de l'utilisateur (étudiant, enseignant, admin, eseignant & administrateur)
Elle contient également des références vers les cours auxquels l'utilisateur a accès et les notifications reçues. Ces références sont stockées dans des tableaux pour un accès rapide et simple. En effet, il suffit de récupérer dans ces tableaux les _id des entités associées pour les retrouver dans la base de données. Cela permet aussi de garder des informations qui ne sont pas uniquement liées entité de référence, mais aussi à l'utilisateur.
Cours (Course), Relation Utilisateur-Cours (UserCourse) et Compétence (Skill)
Cours
Représente les cours disponibles dans le système. Chaque cours possède :
code: Code unique du cours, correspondant au code de l'UE
title: Titre du cours
date: Date de création du cours
skills: Liste des compétences associées au cours
content: Liste des contenus pédagogiques associés
UserCourse
Ce type d'entité permet de gérer l'accès des utilisateurs aux cours. Il contient une référence au cours via son _id ainsi que la dernière date d'accès de l'utilisateur à ce cours.
Catégorie (Category) et type de contenu (Content, Post, Assignment, Forum)
La gestion du contenu pédagogique est structurée autour de catégories qui possèdent chacune un ensemble de contenus.
Le principe est simple une catégorie peut contenir plusieurs contenus de manière embedded ainsi que son ordre dans le cours
Chaque catégorie est ensuite lié à un cours via son _id.
Les contenus peuvent être de différents types :
Content: Contenu générique (texte, image, vidéo, etc.)
Post: Publication dans un forum
Assignment: Devoir à rendre
Forum: Discussions et échanges entre utilisateurs
Forum
Représente les forums de discussion associés aux cours. Chaque forum peut contenir un sujet de discussion (thread) et des messages associés. Les forums permettent aux utilisateurs d'échanger sur les cours, de poser des questions et de partager des informations.
Chaque forum est lié à un cours via son code, ce qui permet de regrouper les discussions par cours.
Chaque sujet de discussion (thread) possède :
title: Titre du sujet
date: Date de création du sujet
OP_id: Identifiant de l'utilisateur qui a créé le sujet
messages: Liste des messages associés au sujet, chaque message ayant un auteur, une date et un contenu textuel.
last_message_date: Date du dernier message posté dans le sujet
last_message_author_id: Identifiant de l'auteur du dernier message
Notification (Notification) et relation avec l'utilisateur (UserNotification)
Notification
Cette classe permet de stocker toutes les informations relatives aux notifications envoyées aux utilisateurs. Une notification peut contenir des informations telles que :
l'ajout d'un nouveau cours
l'inscription / désinscription à un cours
un message dans un forum
un nouveau devoir
un rappel de devoir
UserNotification
Afin de gérer les notifications pour chaque utilisateur, nous avons créé un type UserNotification qui permet de stocker l' _id de la notification et son état de lecture (read). Cette entité permet de lier une notification à un utilisateur spécifique et de savoir si elle a été lue ou non.
Approche Document vs Relationnel
Bien que MongoDB soit une base de données NoSQL orientée documents, nous avons maintenu une structure relationnelle logique entre nos entités. Ce choix permet :
Flexibilité: Les documents peuvent évoluer sans nécessiter de migrations complexes
Performance: Les requêtes fréquentes sont optimisées par la structure des documents
Cohérence: Les relations entre entités sont clairement définies
Imbrication vs Référencement
Nous avons fait les choix suivants :
Imbrication pour les données fréquemment accédées ensemble (ex: notifications dans le profil utilisateur)
Référencement pour les relations complexes ou les données volumineuses (ex: les devoirs associés à un cours)
Gestion des Fichiers
Pour le stockage des fichiers (PDF, images, etc.), nous utilisons GridFS qui :
Découpe les fichiers volumineux en chunks
Stocke les métadonnées séparément
Permet un streaming efficace
Évolution du Modèle de Données
Le modèle de données a été conçu pour évoluer facilement :
Ajout de nouveaux champs sans impact sur l'existant
Extension possible pour de nouvelles fonctionnalités (ex: système de badges, évaluations par les pairs)
Support pour différents types de contenu pédagogique
Optimisations
Plusieurs optimisations ont été mises en place :
Indexation sur les champs fréquemment recherchés (email, ine, course_code)
Projection pour limiter les données retournées dans les requêtes volumineuses
Agrégation pour les statistiques et tableaux de bord
Mise en cache des données fréquemment accédées (ex: profil utilisateur)
Sécurité des Données
La sécurité des données est assurée par :
Hachage des mots de passe avec bcrypt
Validation des données côté serveur
Contrôle d'accès basé sur les rôles utilisateur
Sanitization des entrées pour prévenir les injections