Modeling an Open Marketplace for Education

Keeping up with the latest changes in technology is necessary if you want to get ahead in today’s competitive job market. In this article, we’ll build a data model for online portals that offer a more engaging platform for learning new skills, using Native Monks as our guide.

Introduction

In one of our recent articles, we built a working data model for an e-learning portal, and we explained how courses can be split into recorded/transcript lessons and made available to students. However, there are some who’d prefer to learn directly from teachers in more engaging, personal sessions. Unlike platforms such as Udemy and Coursera, Native Monks allows students to hire teachers (either locally or online) and to learn skills directly from them in one-on-one classes that are administered either online or in person.

Requirements

Since the platform allows students to search for teachers according to their own criteria, it places a great deal of emphasis on profile building for teachers. In other words, the platform collects as much information as it can from teachers so it can provide better search recommendations to students.

Teachers on the platform may specialize in any field, such as technology, cooking, arts, maintenance and service, and so on. Skills that require a great deal of work and explanation are often taught to students in person, while those that are relatively simple are better administered online via video lectures that students can purchase from their selected instructors.

With these requirements in mind, we’ve split our entire data model into three major subject areas:

1. Profile building for teachers
2. Student management and engagements
3. Recorded lesson management

Let’s take a closer look at each of these areas.

Data Model

Subject Area #1: Profile Building for Teachers

This area of the platform concerns collecting basic information from teachers, such as their preferences for students, location, availability, comfort level, and so on. When students browse the platform, they are shown a list of teachers who best match their given preferences. There are a variety of tables in this area that we’ll discuss below.

teacher table: stores basic information about instructors. Most of the columns in this table are self-explanatory, but let’s elaborate on a few that may not be as obvious:

• max_travel_distance — represents the maximum distance a teacher is able to travel to meet with a student. A value of zero indicates that the teacher can’t travel to teach students.
• cost_to_travel — stores a value submitted by a teacher signifying the additional fees they will charge for traveling to meet with a student.
• profile_image — stores a teacher’s profile picture. Since teachers are not required to post profile pictures, the value defaults to null if an alternative is not specified.
• teaching_since — stores a value representing the year in which the instructor began teaching. This allows students to get a better feel for a teacher’s experience.
• brief_description — stores a brief description about the teacher.
• timezone_id — stores the time zone information for a teacher, allowing students and

teacher_teaching_location table: stores a teacher’s location preferences, which they must specify when building their profile. Some teachers prefer to administer lessons at their own place or at their student’s place, but others would rather hold lectures in a public area, such as a nearby library or community center.

• id — the primary key for this table.
• teacher_id — identifies the teacher to whom these location preferences belong.
• teaching_location_type_id — the type of location where the teacher would like to administer the lesson: online, the teacher’s place, the student’s place, or some neutral location.
• address_id — a referenced column that stores the complete address of the meeting location.

exp_level_teach_teacher table: teachers are also asked to specify the expertise levels at which they are comfortable teaching (beginner, intermediate, expert).

student_comfortability table: some teachers are uncomfortable teaching certain age groups, such as the elderly. Thus, the portal allows teachers to also list their preferences for students with respect to age and gender.

teacher_availability table: stores the teacher’s availability for the next two weeks, and up to a month in advance. These details are modified by teachers on a periodic basis.

• id — the primary key for this table.
• teacher_id — identifies the teacher for whom this information is stored.
• start_date_time — stores the start date and time when the teacher is available to teach.
• duration_in_min — indicates how much time the instructor has for teaching, in minutes.

teacher_earning table: stores billing rates for teachers. For now, we’ve created columns to specify the billing rates for 30-, 60-, 90-, and 120-minute lectures.

Subject Area# 2: Student Management and Engagements

This area is dedicated to keeping track of appointments between students and teachers. Like the table for teachers in the first subject area, there is a table for students (aptly named student) in this subject area. All of the columns in this table are fairly straightforward, so we won’t dive into those.

Another table is titled teacher_reservation. This is the actual table that tracks appointments between students and teachers. When a student selects a particular teacher, they get to see that instructor’s availability. They are required to select one or more available slots to make a reservation with the teacher. In addition, the student must specify a teaching location based on the preferences for their selected teacher. Once the student completes their portion of the form, the reservation is sent to the teacher for review and approval. Let’s clarify some of the columns for this table:

• id — the primary key for the table. Gives a unique identity to an individual reservation request.
• student_id — identifies the student making the reservation.
• teacher_id — identifies the teacher for whom the reservation is being requested.
• teacher_teaching_location_id — stores information about the location where the student would like to attend classes. This location must match one of those specified by the teacher in their preferences.

Subject Area #3: Recorded Lesson Management

This portal allows teachers to upload recorded lessons. Each session is tagged with a subscription cost that students must pay before they’re allowed to attend. Each subscription comes with an expiration date, so a session remains open for viewing until the student’s subscription expires.

recorded_lesson table: stores basic information about recorded sessions.

• id — primary key for the table that assigns a unique number to an individual recorded lesson.
• subject — stores the subject line or title of a lesson.
• lesson_category_id — a referenced column that represents the category to which a lesson belongs (e.g., travel, cooking, physics, etc.).
• teacher_id — identifies the instructor who prepared and uploaded this lesson.
• lesson_description — descriptive column that stores a brief description about the lesson.
• video_location — typically, videos are stored on server file systems, and their locations are stored in this column. Files are invoked and made available to users when requested.
• lesson_transcript — store a complete transcript of the video(s) for this lesson.
• cost_to_subscribe — stores the price that a student must pay to subscribe to the video.

lesson_subscription table: stores basic information about student subscriptions.

• id — the primary key for this table.
• student_id — identifies the student who subscribed to this lesson.
• recorded_lesson_id — identifies the lesson to which the student subscribed.
• subscription_date — stores the date when the subscription began. It is usually the same date as when the payment was made for the subscription.
• is_lifetime_subscription — many lessons come with lifetime subscription, meaning that a lesson will remain with you forever once you’ve paid for the lesson. If the value stored in this column is ‘Y’, there is no expiration date for the subscription.
• subscription_expiring_on — stores the date when the subscription will expire. If it is a lifetime subscription, this column stores a value of null.

Summary

Learning empowers people to advance their careers, improve their lives, and pursue the work they love. This application will help reduce the gap between demand and supply for professionals and will create an online learning community where anyone can explore, learn, and teach.

What additional features would you like to add to this data model? We’d love to hear your thoughts!