Database
 sql >> Base de données >  >> RDS >> Database

Un modèle de base de données pour une plateforme MOOC

Si vous utilisiez une plateforme d'apprentissage en ligne MOOC comme edX ou Coursera, comment la maintiendriez-vous organisée ? Dans cet article, nous examinerons un modèle de base de données qui ferait l'affaire.

Vous avez probablement entendu parler du MOOC (Massive Open Online Course), un moyen tendance d'apprendre en ligne. Et si ce n'est pas le cas, considérez un programme MOOC comme des matières universitaires avec tous les supports, tests et commentaires disponibles en ligne. Deux des fournisseurs de MOOC en ligne les plus populaires sont Coursera (fondé par l'Université de Stanford) et edX (fondé par le Massachusetts Institute of Technology et l'Université de Harvard). En collaboration avec d'autres universités et partenaires, ils proposent des centaines de cours à des millions d'apprenants dans le monde entier.

Dans cet article, nous discuterons d'une version simplifiée d'un modèle de base de données que nous pourrions utiliser pour exécuter ce type de service. Tout d'abord, parlons du fonctionnement réel des MOOC d'un point de vue non technique.

Comment fonctionnent les plateformes MOOC ?

Personnellement, j'ai utilisé Coursera et j'en ai été très satisfait. Par conséquent, mes commentaires dans cet article concernent principalement le modèle de Coursera, bien que je pense qu'edX suit un schéma similaire.

Quel est le modèle commercial ?

L'idée est très simple. Les partenaires – principalement des universités – créent du matériel pour les cours en ligne, qui sont généralement basés sur les offres de leur campus. Ces supports peuvent inclure des conférences vidéo, des lectures, des quiz, des discussions, des projets, des tests en ligne et parfois des devoirs finaux. Une grande partie du matériel est basé sur la vidéo, de sorte que les apprenants obtiennent cette « touche humaine ». J'ai apprécié certains cours non seulement à cause de ce qui était enseigné, mais aussi à cause des conférenciers.

Les étudiants doivent regarder ou lire le matériel fourni, effectuer des devoirs, répondre à des quiz et passer des tests. Habituellement, il y a aussi un ou plusieurs devoirs de projet, et les notes de tous ces devoirs constituent la note finale. Si leur note finale est supérieure à un certain score (par exemple 70 %), les étudiants réussissent le cours et reçoivent un certificat. Certains certificats sont gratuits; d'autres exigent un paiement relativement faible. Il en va de même pour les cours.

Les cours connexes peuvent être organisés en grandes entités appelées spécialisations. L'achèvement de la spécialisation donne à l'étudiant un autre certificat (ainsi qu'un ensemble de compétences plus complet) et peut être moins coûteux que de suivre chaque cours séparément.

Tous les cours et spécialisations peuvent avoir des sessions différentes. Certains auront de nouvelles sessions chaque mois, tandis que d'autres auront une nouvelle session chaque année. Il existe également des cours disponibles sur demande.

Les certifications en ligne n'ont pas encore le même poids qu'un certificat universitaire, mais elles y aspirent. Certains cours sont déjà approuvés pour le crédit universitaire, et les programmes d'études en ligne sont également une réalité maintenant.

Combien y a-t-il de partenaires, de cours et d'étudiants ?

La réponse simple est "beaucoup". Les cours se mesurent en milliers, les partenaires en centaines et les étudiants en millions - de presque tous les pays du monde.

À quels changements peut-on s'attendre pour les MOOC ?

Ce qui est bien avec les MOOC, c'est qu'ils peuvent s'adapter rapidement au changement. Ils ne sont pas limités par les règlements de l'État ou de l'université et n'ont pas à attendre l'approbation. C'est très important, surtout pour les cours liés à l'informatique. Certains cours et spécialisations n'auront pas de nouvelles sessions :d'autres nouveaux cours apparaîtront et les cours existants subiront diverses mises à jour.

Le modèle de base de données MOOC




J'ai divisé le modèle de données MOOC en trois domaines :

  • Course details
  • Specialization details
  • Student participation

Et il y a trois tables autonomes :

  • institution
  • lecturer
  • student

Les tableaux autonomes sont utilisés comme sources de données pour divers tableaux dans les domaines. Étant donné que les domaines contiennent la majeure partie de la logique, je vais d'abord les expliquer, puis passer aux tableaux autonomes.

Cours et matériel

Bien que les gens soient généralement la partie la plus importante de toute transaction, je ferai une exception ici. Sans supports de cours, il n'y aurait pas de cours et donc pas d'intérêt pour notre plateforme MOOC. Dans "Détails des cours", j'ai regroupé tous les tableaux qui décrivent les cours, les institutions associées, les partenaires et les matériaux.

Le tableau le plus important de cette section est le course table. Les attributs sont :

  • name – un nom de cours unique
  • commitment – une description textuelle de l'engagement probable, par ex. "5 semaines d'études, 5-7 heures/semaine"
  • description – une description du cours
  • specialization_id – une référence à la spécialisation concernée, le cas échéant. Les cours ne peuvent faire partie que d'une seule spécialisation. Certains cours ne sont affiliés à aucune spécialisation, cet attribut n'est donc pas obligatoire.
  • min_grade – la note minimale requise pour réussir un cours. Habituellement, cela sera mesuré en pourcentage. Sur la plupart des cours Coursera, c'est 70 %.
  • course_price – les frais que vous paierez pour un cours.
  • active – un interrupteur marche/arrêt qui indique si un cours aura des sessions futures. Les cours actifs auront de nouvelles sessions, contrairement aux cours inactifs.

Notez que le course la table est nommée course:Course details . C'est parce que j'ai utilisé le course table à nouveau ailleurs pour rendre le modèle plus clair. Pour ce faire, j'ai utilisé les options "Copier" et "Coller comme raccourci" de Vertabelo.

Chaque cours est composé de quelques chapitres. Dans Coursera, les étudiants ont généralement une semaine pour terminer chaque chapitre. Une liste de toutes les sous-sections ou chapitres du cours est stockée dans le chapter table. Le course_id l'attribut est une référence au course table; chapter_no est le numéro ordinal d'un chapitre de ce cours. Ces deux attributs forment ensemble la clé alternative de la table. Le dernier attribut, description , stocke une description détaillée pour chaque chapitre.

Chaque chapitre est composé de conférences vidéo, de lectures, de quiz, de tests et de projets. Nous ne créerons pas de structures séparées dans la base de données pour stocker différents types de matériaux. Au lieu de cela, nous stockerons des liens vers ces matériaux. Et c'est là que le material table entre. Les attributs de cette table sont :

  • chapter_id – une référence au chapitre concerné
  • material_no – un numéro ordinal attribué à divers matériaux de chapitre. Avec le chapter_id , cet attribut forme la clé alternative (unique) de la table.
  • material_type_id – est une référence au material_type tableau
  • mandatory – une valeur booléenne qui indique si le matériel est obligatoire ou facultatif (c'est-à-dire pour un crédit supplémentaire)
  • max_points – le nombre maximum de points que l'étudiant peut obtenir après avoir terminé ce matériel. Si aucun point n'est attribué, nous utiliserons simplement "0" comme valeur.

Le material_type table est un dictionnaire de tous les types de matériaux possibles. Le seul attribut à côté de la clé primaire est type_name et bien sûr il ne doit contenir que des valeurs uniques. Certains types de matériel attendus sont "conférence vidéo" , "lire" , "questionnaire" , "tester" , "examen final" et "affectation de projet" .

Le on_course tableau relie chaque cours au(x) conférencier(s) enseignant ce cours. Il ne contient que sa clé primaire et une paire de clés étrangères (lecturer_id et course_id ). La paire de clés étrangères constitue la clé unique de la table.

De la même manière, course_created_by met en relation un cours avec toutes les institutions qui ont participé à sa création.

Spécialisations

Les cours autonomes sont excellents, mais pour maîtriser une nouvelle compétence, vous aurez besoin de plus d'un cours. Les spécialisations sont un pas dans cette direction. Il s'agit d'une série de cours, souvent quatre ou cinq, et d'un projet final où vous pouvez appliquer les compétences que vous avez acquises. Tous les tableaux liés à la spécialisation se trouvent dans les Specialization details région.

La specialization table est la table centrale de cette section. Pour chaque spécialisation, nous stockerons un name unique et description . La specialization_discount est le montant qu'un étudiant économisera s'il s'inscrit à l'ensemble de la spécialisation plutôt qu'aux cours autonomes individuellement. Comme précédemment, le active L'attribut est un simple interrupteur marche/arrêt qui indique si la spécialisation aura des sessions futures ou non.

Notez que la specialization table apparaît également deux fois dans notre modèle. À l'intérieur de cette zone, il est nommé specialization:Specialization details .

Le on_specialization et specialization_created_by les tables ont le même objectif et suivent la même logique que le on_course et course_created_by les tables. Bien sûr, cette fois, ils s'occuperont des spécialisations plutôt que des cours.

Étudiants

Et enfin nous arrivons à la section des étudiants. Dans la rubrique Student participation domaine, nous conserverons les enregistrements des étudiants, des sessions et des performances des étudiants.

Chaque cours et spécialisation peut avoir plus d'une session, nous devrons donc stocker quand chaque cours et spécialisation commence et quand il se termine. Pour les cours, c'est très simple. Chaque nouvelle session n'est qu'une nouvelle instance du même cours. Une nouvelle session de spécialisation est une nouvelle instance de l'ensemble de la spécialisation et de tous ses cours.

N'oubliez pas que les étudiants peuvent s'inscrire à un cours d'une spécialisation ou à tous. Les course_sessions et specialization_session les tableaux nous fournissent cette information. Outre les dates, ils ne contiennent que des clés étrangères du course et specialization_table les tables. Une date de début de clé étrangère paire forme la clé unique dans les deux tables.

Les sessions de cours peuvent également faire partie des sessions de spécialisation, nous devrons donc ajouter une clé étrangère (non obligatoire).

Le status dictionnaire répertorie tous les statuts possibles liés aux performances des étudiants pendant un cours. Quelques statuts possibles sont "abandonné" , "réussi" et "échec" .

Nous utiliserons le enrolled_course table pour stocker chaque inscription à n'importe quelle session de cours. Cette table contient deux clés étrangères, student_id et course_session_id , et ensemble, ils forment la clé alternative (unique) de la table. Les autres attributs du tableau sont :

  • enrollment_date – la date à laquelle un étudiant s'est inscrit à ce cours
  • status_id – une référence au status dictionnaire; cela enregistre les performances d'un étudiant sur ce cours
  • status_date – la date à laquelle un statut a été attribué
  • final_grade – la note (en pourcentage) que l'étudiant a obtenue pour ce cours
  • certificate_ID – un numéro d'identification du certificat que la plateforme génère lorsqu'un étudiant réussit le cours
  • certificate_location – un lien vers l'emplacement exact où le certificat est stocké

Le enrolled_specialization le tableau suit la même logique que le enrolled_course table. La différence est qu'il associe les étudiants à des spécialisations plutôt qu'à des cours.

Nous utiliserons le student_results table pour stocker les performances des étudiants sur des supports de cours spécifiques. Pour chaque matériau (material_id ) et l'inscription de chaque étudiant (enrolled_course_id ) nous pourrions avoir plus d'une tentative. Par conséquent, la attempt L'attribut est le nombre ordinal de la tentative de chaque élève. Ces trois attributs forment ensemble la clé alternative de la table.

Dans ce tableau, le attempt_link est l'emplacement de chaque instance de tests ou de projets soumis par les étudiants. Nous pouvons supposer que pour chaque tentative, nous générerons un "nouveau" test avec des questions choisies au hasard. Si le matériel ne nécessite pas de réponses des étudiants, le lien n'existera pas et nous stockerons une valeur NULL ici.

Enfin, le student_results la table stocke quand un étudiant started et ended une tentative et le score atteint. Il peut également stocker les résultats de performance sur les devoirs non notés ainsi que les vidéos qu'ils ont regardées et quand, quels documents ils ont lus, etc.

Établissements

L'institution table est un catalogue simple qui répertorie toutes les institutions qui ont créé des cours ou dont les enseignants sont impliqués dans les cours.

Conférenciers

Nous pourrions utiliser un tableau beaucoup plus détaillé ici, mais stocker le prénom et le nom de chaque conférencier, son titre et le nom de son université est suffisant pour nos besoins. Sans surprise, tout cela est conservé dans le lecturer tableau.

Étudiants

Je terminerai l'aperçu du tableau avec l'student table. Encore une fois, nous avons juste besoin d'attributs de base ici, et ils devraient être explicites.

Comment pourrions-nous améliorer ce modèle ?

Ce modèle prend en charge les fonctionnalités de base nécessaires à la création d'une plateforme MOOC. Pourtant, vous pouvez probablement facilement penser à de nombreux ajouts utiles. En voici quelques-unes :

  • Langue du cours et sous-titres pour les cours vidéo
  • Classement automatique
  • Étudiants révisant et notant les devoirs des autres
  • Aide financière
  • Une option qui permet aux étudiants de reprendre un cours après l'avoir abandonné

Il convient également de mentionner que, selon Wikipedia "... Les serveurs de base de données de Coursera (fonctionnant sur RDS) répondent à 10 milliards de requêtes SQL, et Coursera dessert environ 500 To de trafic par mois." C'était en 2013. Un vrai modèle de base de données MOOC pourrait ressembler à celui présenté dans cet article, mais il y a encore beaucoup de travail à faire sur la modélisation et l'infrastructure !

Dans cet article, j'ai essayé de montrer la complexité du modèle qui se cache derrière une plateforme MOOC. Je me suis principalement concentré sur Coursera et edX comme exemples. Ce modèle contient 18 tables, mais il ne fait qu'effleurer la surface. N'hésitez pas à commenter et à partager les améliorations que vous souhaiteriez implémenter dans le modèle. Si vous pensez que j'ai raté quelque chose d'important, n'hésitez pas à me le faire savoir !

Vous aimez apprendre en ligne ? Essayez LearnSQL.com – des cours SQL interactifs, disponibles dans votre navigateur.