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

Modélisation d'un marché ouvert pour l'éducation

Se tenir au courant des dernières évolutions technologiques est nécessaire si vous souhaitez progresser sur le marché du travail concurrentiel d'aujourd'hui. Dans cet article, nous allons créer un modèle de données pour les portails en ligne qui offrent une plate-forme plus attrayante pour apprendre de nouvelles compétences, en utilisant Native Monks comme guide.

Présentation

Dans l'un de nos articles récents, nous avons construit un modèle de données de travail pour un portail d'apprentissage en ligne, et nous avons expliqué comment les cours peuvent être divisés en leçons enregistrées/transcriptions et mis à la disposition des étudiants. Cependant, certains préfèrent apprendre directement des enseignants lors de sessions personnelles plus engageantes. Contrairement aux plates-formes telles que Udemy et Coursera, Native Monks permet aux étudiants d'embaucher des enseignants (soit localement, soit en ligne) et d'acquérir des compétences directement auprès d'eux dans des cours individuels administrés en ligne ou en personne.

Exigences

Étant donné que la plateforme permet aux étudiants de rechercher des enseignants selon leurs propres critères, elle accorde une grande importance à la constitution du profil des enseignants. En d'autres termes, la plateforme recueille autant d'informations que possible auprès des enseignants afin de pouvoir fournir de meilleures recommandations de recherche aux étudiants.

Les enseignants de la plateforme peuvent se spécialiser dans n'importe quel domaine, comme la technologie, la cuisine, les arts, l'entretien et le service, etc. Les compétences qui nécessitent beaucoup de travail et d'explications sont souvent enseignées aux étudiants en personne, tandis que celles qui sont relativement simples sont mieux administrées en ligne via des conférences vidéo que les étudiants peuvent acheter auprès de leurs instructeurs sélectionnés.

Avec ces exigences à l'esprit, nous avons divisé l'ensemble de notre modèle de données en trois domaines principaux :

  1. Création d'un profil pour les enseignants
  2. Gestion et engagement des étudiants
  3. Gestion des leçons enregistrées

Examinons de plus près chacun de ces domaines.

Modèle de données




Domaine 1 :Création d'un profil pour les enseignants

Cette zone de la plateforme concerne la collecte d'informations de base auprès des enseignants, telles que leurs préférences pour les étudiants, l'emplacement, la disponibilité, le niveau de confort, etc. Lorsque les élèves naviguent sur la plateforme, une liste d'enseignants qui correspondent le mieux à leurs préférences leur est présentée. Il existe une variété de tableaux dans ce domaine dont nous parlerons ci-dessous.

teacher table :stocke des informations de base sur les instructeurs. La plupart des colonnes de ce tableau sont explicites, mais développons quelques-unes qui ne sont peut-être pas aussi évidentes :

  • max_travel_distance — représente la distance maximale qu'un enseignant peut parcourir pour rencontrer un élève. Une valeur de zéro indique que l'enseignant ne peut pas se déplacer pour enseigner aux élèves.
  • cost_to_travel - stocke une valeur soumise par un enseignant indiquant les frais supplémentaires qu'il facturera pour se déplacer pour rencontrer un élève.
  • profile_image - stocke la photo de profil d'un enseignant. Étant donné que les enseignants ne sont pas tenus de publier des photos de profil, la valeur par défaut est null si aucune alternative n'est spécifiée.
  • teaching_since — stocke une valeur représentant l'année au cours de laquelle l'instructeur a commencé à enseigner. Cela permet aux élèves d'avoir une meilleure idée de l'expérience d'un enseignant.
  • brief_description — stocke une brève description de l'enseignant.
  • timezone_id - stocke les informations de fuseau horaire pour un enseignant, permettant aux étudiants et

teacher_teaching_location table :stocke les préférences de localisation d'un enseignant, qu'il doit spécifier lors de la création de son profil. Certains enseignants préfèrent administrer les cours chez eux ou chez leurs élèves, mais d'autres préfèrent organiser des cours dans un lieu public, comme une bibliothèque ou un centre communautaire à proximité.

  • id — la clé primaire de cette table.
  • teacher_id — identifie l'enseignant auquel appartiennent ces préférences de localisation.
  • teaching_location_type_id — le type d'endroit où l'enseignant souhaite donner la leçon :en ligne, chez l'enseignant, chez l'élève ou dans un endroit neutre.
  • address_id — une colonne référencée qui stocke l'adresse complète du lieu de la réunion.

exp_level_teach_teacher tableau :les enseignants sont également invités à préciser les niveaux d'expertise avec lesquels ils sont à l'aise d'enseigner (débutant, intermédiaire, expert).

student_comfortability tableau :certains enseignants sont mal à l'aise d'enseigner à certains groupes d'âge, comme les personnes âgées. Ainsi, le portail permet aux enseignants de répertorier également leurs préférences pour les élèves en ce qui concerne l'âge et le sexe.

teacher_availability tableau :stocke la disponibilité de l'enseignant pour les deux prochaines semaines, et jusqu'à un mois à l'avance. Ces détails sont modifiés périodiquement par les enseignants.

  • id — la clé primaire de cette table.
  • teacher_id — identifie l'enseignant pour qui ces informations sont stockées.
  • start_date_time - stocke la date et l'heure de début lorsque l'enseignant est disponible pour enseigner.
  • duration_in_min — indique le temps dont dispose l'instructeur pour enseigner, en minutes.

teacher_earning table :stocke les taux de facturation des enseignants. Pour l'instant, nous avons créé des colonnes pour spécifier les taux de facturation pour les conférences de 30, 60, 90 et 120 minutes.

Domaine n° 2 :Gestion et engagement des étudiants

Cet espace est dédié au suivi des rendez-vous entre élèves et professeurs. Comme le tableau pour les enseignants dans la première matière, il existe un tableau pour les étudiants (bien nommé student ) dans ce domaine. Toutes les colonnes de ce tableau sont assez simples, nous n'allons donc pas nous plonger dans celles-ci.

Un autre tableau est intitulé teacher_reservation . C'est le tableau réel qui suit les rendez-vous entre les étudiants et les enseignants. Lorsqu'un étudiant sélectionne un enseignant particulier, il peut voir la disponibilité de cet instructeur. Ils sont tenus de sélectionner un ou plusieurs créneaux disponibles pour effectuer une réservation auprès du professeur. De plus, l'étudiant doit spécifier un lieu d'enseignement en fonction des préférences de son enseignant sélectionné. Une fois que l'étudiant a rempli sa partie du formulaire, la réservation est envoyée à l'enseignant pour examen et approbation. Clarifions certaines des colonnes de ce tableau :

  • id — la clé primaire de la table. Donne une identité unique à une demande de réservation individuelle.
  • student_id — identifie l'étudiant effectuant la réservation.
  • teacher_id — identifie l'enseignant pour qui la réservation est demandée.
  • teacher_teaching_location_id - stocke des informations sur l'endroit où l'étudiant souhaite suivre des cours. Cet emplacement doit correspondre à l'un de ceux spécifiés par l'enseignant dans ses préférences.

Domaine n° 3 :Gestion des cours enregistrés

Ce portail permet aux enseignants de télécharger des leçons enregistrées. Chaque session est associée à un coût d'abonnement que les étudiants doivent payer avant d'être autorisés à y assister. Chaque abonnement est accompagné d'une date d'expiration, de sorte qu'une session reste ouverte jusqu'à l'expiration de l'abonnement de l'étudiant.

recorded_lesson table :stocke les informations de base sur les sessions enregistrées.

  • id — clé primaire du tableau qui attribue un numéro unique à une leçon individuelle enregistrée.
  • subject - stocke la ligne d'objet ou le titre d'une leçon.
  • lesson_category_id — une colonne référencée qui représente la catégorie à laquelle appartient une leçon (par exemple, voyage, cuisine, physique, etc.).
  • teacher_id — identifie l'instructeur qui a préparé et téléchargé cette leçon.
  • lesson_description — colonne descriptive qui stocke une brève description de la leçon.
  • video_location — généralement, les vidéos sont stockées sur les systèmes de fichiers du serveur et leurs emplacements sont stockés dans cette colonne. Les fichiers sont invoqués et mis à la disposition des utilisateurs sur demande.
  • lesson_transcript - stocker une transcription complète de la vidéo (s) pour cette leçon.
  • cost_to_subscribe — stocke le prix qu'un étudiant doit payer pour s'abonner à la vidéo.

lesson_subscription table :stocke les informations de base sur les abonnements des étudiants.

  • id — la clé primaire de cette table.
  • student_id — identifie l'élève qui s'est abonné à cette leçon.
  • recorded_lesson_id — identifie la leçon à laquelle l'élève s'est abonné.
  • subscription_date — stocke la date à laquelle l'abonnement a commencé. Il s'agit généralement de la même date que celle à laquelle le paiement a été effectué pour l'abonnement.
  • is_lifetime_subscription - de nombreuses leçons sont accompagnées d'un abonnement à vie, ce qui signifie qu'une leçon restera avec vous pour toujours une fois que vous aurez payé la leçon. Si la valeur stockée dans cette colonne est "Y", il n'y a pas de date d'expiration pour l'abonnement.
  • subscription_expiring_on — enregistre la date d'expiration de l'abonnement. S'il s'agit d'un abonnement à vie, cette colonne stocke une valeur nulle.

Résumé

L'apprentissage permet aux gens de faire avancer leur carrière, d'améliorer leur vie et de poursuivre le travail qu'ils aiment. Cette application contribuera à réduire l'écart entre la demande et l'offre de professionnels et créera une communauté d'apprentissage en ligne où chacun pourra explorer, apprendre et enseigner.

Quelles fonctionnalités supplémentaires souhaitez-vous ajouter à ce modèle de données ? Nous serions ravis de connaître votre avis !