SQL Tables

Course Tables β€” SQL Education | DataSosi
SQL Education · Course Tables · Reference Guide

Your Course Tables

The eleven tables you will use throughout this SQL Education course β€” a complete college administration database with real-world structure, relationships, and data.

These are the tables you will use for this SQL Education course. Together they form a realistic college administration database called education_admin_sql_course, made up of eleven connected tables covering campuses, departments, instructors, programs, students, terms, courses, sections, teaching assignments, enrollments, grades, attendance, tuition payments, and advising sessions. This is the most comprehensive dataset in the SQL course series β€” designed to support advanced query writing, complex multi-table analysis, and real institutional data scenarios.
11 Tables
Full Foreign Key Structure
No coding background required

What These Tables Are For

  • Work with a fully normalised, real-world college administration database across 11 connected tables
  • Understand how Foreign Keys chain through multiple tables to represent complex institutional relationships
  • Practise education SQL query writing on data that mirrors what you would encounter in actual higher education systems
  • Build, populate, and query a complete database from scratch using the SQL code provided in each section
Click any section header to open or close it

The campuses table is the geographic foundation of the database. It records the three locations where the college operates: two physical campuses in British Columbia and one virtual online campus. The campus_id is referenced by both the departments and sections tables, making it a key anchor in the database hierarchy.

Why this table matters

Every department belongs to a campus, and every course section is delivered at a campus. This table allows you to trace any course or student activity all the way back to a physical or virtual location β€” a common real-world reporting need in institutional databases.

The Data
campus_idcampus_namecityprovince_statecountrycampus_type
1Main CampusVictoriaBritish ColumbiaCanadaUrban
2Westshore CampusLangfordBritish ColumbiaCanadaRegional
3Online CampusRemoteBritish ColumbiaCanadaVirtual
Column Breakdown
Column NameData TypeConstraintsExplanation
campus_idINTPRIMARY KEYUnique identifier for each campus. Referenced by departments and sections tables.
campus_nameVARCHAR(100)NoneThe official name of the campus location.
cityVARCHAR(50)NoneThe city where the campus is located. Online campus uses “Remote”.
province_stateVARCHAR(50)NoneThe province or state. All campuses are in British Columbia.
countryVARCHAR(50)NoneThe country. All campuses are in Canada.
campus_typeVARCHAR(50)NoneThe type of campus: Urban, Regional, or Virtual.

The departments table defines the five academic units that organise the college’s academic offerings. Each department belongs to a campus and a faculty, and is referenced by the instructors, programs, and courses tables. Understanding this table is essential for any query that groups or filters data by academic area.

Why this table matters

The department_id flows through much of the database β€” it links campuses to instructors, programs, and courses. Many education queries will ask you to aggregate data by department, which requires joining through this table from multiple directions.

The Data
department_iddepartment_namefaculty_namecampus_id
1Business AdministrationFaculty of Management1
2EducationFaculty of Social and Applied Sciences1
3Information TechnologyFaculty of Management2
4Health StudiesFaculty of Social and Applied Sciences1
5Professional StudiesContinuing Studies3
Column Breakdown
Column NameData TypeConstraintsExplanation
department_idINTPRIMARY KEYUnique identifier for each department. Referenced by instructors, programs, and courses.
department_nameVARCHAR(100)NoneThe official name of the academic department.
faculty_nameVARCHAR(100)NoneThe faculty or school the department belongs to.
campus_idINTFOREIGN KEY β†’ campusesThe campus where the department is based. Links to the campuses table.

The instructors table stores information about the five teaching staff members. Each instructor belongs to a department, has a hire date, an employment type (Full-Time or Contract), and an active flag. This table is referenced by the teaching_assignments table, which connects instructors to the course sections they teach.

Why this table matters

The active_flag column (stored as BOOLEAN) is a real-world pattern used to soft-delete records without physically removing them. You will encounter this pattern frequently when writing education queries that filter for currently active staff only.

The Data
instructor_idfirst_namelast_namedepartment_idhire_dateemployment_typeemailactive_flag
1EmmaCarter22020-08-15Full-Timeemma.carter@college.ca1
2JamesPatel12019-01-10Full-Timejames.patel@college.ca1
3SophiaNguyen32021-09-01Contractsophia.nguyen@college.ca1
4DanielBrown42018-07-05Full-Timedaniel.brown@college.ca1
5OliviaMartin52022-02-14Contractolivia.martin@college.ca1
Column Breakdown
Column NameData TypeConstraintsExplanation
instructor_idINTPRIMARY KEYUnique identifier for each instructor. Referenced by teaching_assignments.
first_nameVARCHAR(50)NoneThe instructor’s first name.
last_nameVARCHAR(50)NoneThe instructor’s last name.
department_idINTFOREIGN KEY β†’ departmentsThe department the instructor belongs to.
hire_dateDATENoneThe date the instructor was hired. Useful for seniority and tenure calculations.
employment_typeVARCHAR(30)NoneEither Full-Time or Contract.
emailVARCHAR(100)NoneThe instructor’s institutional email address.
active_flagBOOLEANNone1 = currently active. 0 = no longer active. All five instructors are currently active.

The programs table defines the five credential offerings available at the college. Each program belongs to a department, has a credential type (Degree, Masters, Diploma, or Certificate), a duration in years, and an active flag. Students are linked to a program through their record in the students table.

Why this table matters

The program_id appears in the students table as a Foreign Key. This allows you to answer questions like “how many active students are enrolled in each credential type?” β€” a query that joins students to programs and uses GROUP BY credential_type.

The Data
program_idprogram_namecredential_typedepartment_idduration_yearsactive_flag
101Bachelor of Business AdministrationDegree141
102Master of Arts in LeadershipMasters221
103Diploma in Applied Data AnalyticsDiploma321
104Certificate in Health AdministrationCertificate411
105Certificate in Project ManagementCertificate511
Column Breakdown
Column NameData TypeConstraintsExplanation
program_idINTPRIMARY KEYUnique identifier for each program. Referenced by the students table.
program_nameVARCHAR(100)NoneThe full official name of the credential program.
credential_typeVARCHAR(50)NoneThe level of credential: Degree, Masters, Diploma, or Certificate.
department_idINTFOREIGN KEY β†’ departmentsThe department that owns and delivers this program.
duration_yearsINTNoneThe standard length of the program in years: 1, 2, or 4.
active_flagBOOLEANNone1 = currently offered. All five programs are active.

The students table holds demographic and enrollment information for all eight students in the database. Students come from Victoria, Vancouver, Calgary, Toronto, Langford, Surrey, and Burnaby. Their statuses vary: Active, Inactive, and Graduated β€” making this table ideal for practising status-based filtering and cohort analysis.

Why this table matters

The student_id is one of the most frequently used Foreign Keys in the database β€” it appears in enrollments, tuition_payments, and advising_sessions. The variety of student statuses (Active, Inactive, Graduated) and admission dates across two intakes (September 2023 and January 2024) makes this table rich for education analytical queries.

The Data
student_idfirst_namelast_namegenderdate_of_birthcityprovince_stateadmission_dateprogram_idstudent_status
1001AvaWilsonFemale2002-03-14VictoriaBritish Columbia2023-09-01101Active
1002LiamJohnsonMale2001-06-21VancouverBritish Columbia2023-09-01103Active
1003MiaThompsonFemale1999-11-08CalgaryAlberta2024-01-08102Active
1004NoahDavisMale2000-01-19TorontoOntario2023-09-01101Active
1005IsabellaMooreFemale2003-05-27LangfordBritish Columbia2024-01-08104Active
1006EthanTaylorMale2002-07-30SurreyBritish Columbia2023-09-01103Inactive
1007CharlotteAndersonFemale2001-09-12BurnabyBritish Columbia2024-01-08105Active
1008LucasThomasMale1998-12-03KelownaBritish Columbia2023-09-01102Graduated
Column Breakdown
Column NameData TypeConstraintsExplanation
student_idINTPRIMARY KEYUnique identifier. Referenced by enrollments, tuition_payments, and advising_sessions.
first_nameVARCHAR(50)NoneStudent’s first name.
last_nameVARCHAR(50)NoneStudent’s last name.
genderVARCHAR(20)NoneStudent’s gender: Male or Female in this dataset.
date_of_birthDATENoneDate of birth in YYYY-MM-DD format. Useful for age calculations.
cityVARCHAR(50)NoneThe city the student is from β€” spans 7 cities across Canada.
province_stateVARCHAR(50)NoneThe province. Most students are from BC; one from Alberta, one from Ontario.
admission_dateDATENoneThe date the student was admitted. Two intakes: September 2023 and January 2024.
program_idINTFOREIGN KEY β†’ programsThe program the student is enrolled in.
student_statusVARCHAR(30)NoneCurrent status: Active (6), Inactive (1), or Graduated (1).

The terms table defines the three academic terms in the 2024/2025 academic year. Each term has a start date, an end date, and an academic year label. The term_id is referenced by both the sections and tuition_payments tables, linking when courses run to when fees are due.

Why this table matters

Date-based filtering is one of the most common real-world SQL tasks. Using start_date and end_date, you can practise queries like “find all sections running in Fall 2024” or “identify students with outstanding payments from Spring 2025” β€” the kind of institutional reporting that education SQL is built for.

The Data
term_idterm_namestart_dateend_dateacademic_year
1Fall 20242024-09-032024-12-202024/2025
2Spring 20252025-01-062025-04-182024/2025
3Summer 20252025-05-052025-08-152024/2025
Column Breakdown
Column NameData TypeConstraintsExplanation
term_idINTPRIMARY KEYUnique identifier for each term. Referenced by sections and tuition_payments.
term_nameVARCHAR(50)NoneThe human-readable name of the term: Fall 2024, Spring 2025, Summer 2025.
start_dateDATENoneThe first day of the academic term.
end_dateDATENoneThe last day of the academic term.
academic_yearVARCHAR(20)NoneThe academic year label. All three terms fall within 2024/2025.

The courses table lists the six courses offered by the college. Each course has a unique code (e.g., BUSA101), a name, a department, a credit hour value, and a level (Undergraduate or Graduate). The courses table is referenced by the sections table, which assigns courses to specific terms and campuses.

Why this table matters

The course_code column is a real-world pattern β€” institutional databases almost always store both a numeric ID and a human-readable code. At the education level, you will practise queries that search or filter by course code, join sections to courses, and report on delivery by level (Undergraduate vs Graduate).

The Data
course_idcourse_codecourse_namedepartment_idcredit_hourscourse_level
201BUSA101Introduction to Business13Undergraduate
202EDUC510Leadership in Education23Graduate
203DATA210SQL for Data Analytics33Undergraduate
204HLTH300Health Systems Administration43Undergraduate
205PROJ220Project Planning Fundamentals53Undergraduate
206BUSA203Principles of Accounting13Undergraduate
Column Breakdown
Column NameData TypeConstraintsExplanation
course_idINTPRIMARY KEYUnique numeric identifier. Referenced by the sections table.
course_codeVARCHAR(20)NoneThe alphanumeric course code used in timetables and transcripts (e.g., BUSA101).
course_nameVARCHAR(100)NoneThe full official name of the course.
department_idINTFOREIGN KEY β†’ departmentsThe department responsible for delivering the course.
credit_hoursINTNoneThe number of credit hours. All six courses carry 3 credit hours.
course_levelVARCHAR(20)NoneEither Undergraduate or Graduate. EDUC510 is the only Graduate-level course.

The sections table represents individual scheduled offerings of a course. A single course can have multiple sections across different terms or campuses. Each section specifies the delivery mode (In-Person, Online, or Hybrid), the room or virtual space, and the maximum capacity. Sections are referenced by both teaching_assignments and enrollments.

Why this table matters

The sections table is the operational centre of the scheduling system. It connects courses to terms and campuses, making it the table you join through whenever you want to answer questions like “which courses ran online in Fall 2024?” or “how many seats were available in hybrid sections?”

The Data
section_idcourse_idterm_idcampus_idsection_numberdelivery_moderoom_namemax_capacity
30120111A01In-PersonRoom 20135
30220313OL1OnlineVirtual40
30320611A02In-PersonRoom 10530
30420223OL2OnlineVirtual25
30520422W01HybridRoom 1220
30620523OL3OnlineVirtual30
Column Breakdown
Column NameData TypeConstraintsExplanation
section_idINTPRIMARY KEYUnique identifier for each section. Referenced by teaching_assignments and enrollments.
course_idINTFOREIGN KEY β†’ coursesThe course being offered in this section.
term_idINTFOREIGN KEY β†’ termsThe term in which this section runs.
campus_idINTFOREIGN KEY β†’ campusesThe campus where this section is delivered.
section_numberVARCHAR(10)NoneThe section identifier used in timetables (e.g., A01, OL1, W01).
delivery_modeVARCHAR(30)NoneHow the section is delivered: In-Person, Online, or Hybrid.
room_nameVARCHAR(50)NoneThe physical room or “Virtual” for online sections.
max_capacityINTNoneThe maximum number of students that can enroll in this section.

The teaching_assignments table links instructors to the sections they teach. Each row represents one instructor assigned to one section, with a date of assignment and a teaching role. All six assignments in this dataset are Lead Instructor roles. Note that instructor 2 (James Patel) is assigned to two sections β€” 301 and 303 β€” which is a realistic pattern that supports workload analysis queries.

Why this table matters

This table completes the chain from instructor to course to student. By joining teaching_assignments β†’ sections β†’ enrollments β†’ students, you can answer questions such as “which students are being taught by James Patel?” without any direct link between those tables β€” a classic multi-hop JOIN scenario.

The Data
assignment_idsection_idinstructor_idassigned_dateteaching_role
40130122024-08-15Lead Instructor
40230232024-08-20Lead Instructor
40330322024-08-15Lead Instructor
40430412024-12-01Lead Instructor
40530542024-12-01Lead Instructor
40630652024-12-01Lead Instructor
Column Breakdown
Column NameData TypeConstraintsExplanation
assignment_idINTPRIMARY KEYUnique identifier for each teaching assignment record.
section_idINTFOREIGN KEY β†’ sectionsThe section being taught. Links to the sections table.
instructor_idINTFOREIGN KEY β†’ instructorsThe instructor assigned to teach the section.
assigned_dateDATENoneThe date the instructor was formally assigned to the section.
teaching_roleVARCHAR(30)NoneThe role of the instructor. All records show Lead Instructor.

The enrollments table records which students are registered in which sections. With 9 records across 8 students and 6 sections, this dataset includes students enrolled in multiple sections, a withdrawn student, and records with both Completed and In Progress statuses β€” giving you realistic variety for status-based filtering and completion analysis.

Key Concept β€” The Central Linking Table

Enrollments sits at the heart of the entire database. It connects students to sections, and through sections to courses, terms, campuses, and instructors. The grades and attendance tables also reference enrollment_id β€” so this table is the pivot point for any query that brings together academic performance, attendance, and student identity.

The Data
enrollment_idstudent_idsection_idenrollment_dateenrollment_statusfinal_status
50110013012024-08-25EnrolledCompleted
50210023022024-08-26EnrolledCompleted
50310043012024-08-24EnrolledCompleted
50410013032024-08-25EnrolledCompleted
50510063022024-08-27EnrolledWithdrawn
50610033042024-12-20EnrolledCompleted
50710053052024-12-22EnrolledIn Progress
50810073062024-12-23EnrolledIn Progress
50910083042024-12-18EnrolledCompleted
Column Breakdown
Column NameData TypeConstraintsExplanation
enrollment_idINTPRIMARY KEYUnique identifier. Referenced by grades and attendance tables.
student_idINTFOREIGN KEY β†’ studentsThe student registering in the section.
section_idINTFOREIGN KEY β†’ sectionsThe section the student is registering in.
enrollment_dateDATENoneThe date the student registered for the section.
enrollment_statusVARCHAR(30)NoneCurrent registration status. All records show Enrolled.
final_statusVARCHAR(30)NoneOutcome: Completed (5), In Progress (2), or Withdrawn (1).

The grades table records the final assessment result for each completed or withdrawn enrollment. With 7 grade records across a range from A+ (91) to F (52), this table supports performance analysis, grade distribution queries, and pass/fail classification using CASE WHEN. Note that In Progress enrollments do not yet have grade records.

Important note

Not every enrollment has a grade record β€” only those with a final_status of Completed or Withdrawn. In Progress enrollments (507, 508) have no grade yet. This is intentional and reflects how real institutional systems work. When joining grades to enrollments, always consider whether you need LEFT JOIN or INNER JOIN depending on whether you want to include ungraded records.

The Data
grade_idenrollment_idassessment_typescoremax_scoreletter_gradegrade_date
601501Final Grade86.00100.00A2024-12-18
602502Final Grade91.00100.00A+2024-12-19
603503Final Grade74.00100.00B2024-12-18
604504Final Grade88.00100.00A2024-12-19
605505Final Grade52.00100.00F2024-11-20
606506Final Grade84.00100.00A-2025-04-15
607509Final Grade89.00100.00A2025-04-15
Column Breakdown
Column NameData TypeConstraintsExplanation
grade_idINTPRIMARY KEYUnique identifier for each grade record.
enrollment_idINTFOREIGN KEY β†’ enrollmentsThe enrollment this grade belongs to. Links back to the student and section.
assessment_typeVARCHAR(50)NoneThe type of assessment. All records show “Final Grade”.
scoreDECIMAL(5,2)NoneThe numeric score out of max_score. Ranges from 52.00 to 91.00 in this dataset.
max_scoreDECIMAL(5,2)NoneThe maximum possible score. All records show 100.00.
letter_gradeVARCHAR(5)NoneThe letter grade equivalent: A+, A, A-, B, or F.
grade_dateDATENoneThe date the grade was submitted.

The attendance table records individual attendance events for enrolled students. Each row logs one student’s attendance on one date, including whether they were present or absent and how many minutes they attended. With 9 records spanning both Fall 2024 and Spring 2025 sessions, this table is ideal for attendance rate calculations and at-risk student identification.

Why this table matters

Connecting attendance to grades through the enrollments table is one of the most valuable analytical patterns in institutional data. You can use this table to answer questions like “do students with absences tend to score lower?” β€” a classic education SQL analytical scenario that joins attendance, grades, and students through enrollments.

The Data
attendance_idenrollment_idattendance_dateattendance_statusminutes_attended
7015012024-09-10Present180
7025012024-09-17Present180
7035022024-09-10Present120
7045032024-09-10Absent0
7055042024-09-11Present180
7065052024-09-12Absent0
7075062025-01-15Present120
7085072025-01-16Present150
7095082025-01-16Present120
Column Breakdown
Column NameData TypeConstraintsExplanation
attendance_idINTPRIMARY KEYUnique identifier for each attendance record.
enrollment_idINTFOREIGN KEY β†’ enrollmentsThe enrollment this attendance record belongs to.
attendance_dateDATENoneThe date of the class session.
attendance_statusVARCHAR(20)NoneEither Present (7 records) or Absent (2 records).
minutes_attendedINTNoneMinutes present: 180, 150, or 120 for present; 0 for absent.

The tuition_payments table records financial transactions between students and the college. Each row represents one student’s tuition for one term, including the amount billed, the amount paid, payment status, and payment method. With three different payment statuses (Paid, Partially Paid, Outstanding), this table supports financial reporting and accounts receivable queries.

Why this table matters

Financial data is one of the most queried domains in institutional administration. You will use this table to calculate outstanding balances (amount_billed minus amount_paid), identify students with payment issues, and join financial status to academic status β€” an education reporting scenario common in real college systems.

The Data
payment_idstudent_idterm_idpayment_dateamount_billedamount_paidpayment_statuspayment_method
801100112024-08-304500.004500.00PaidCredit Card
802100212024-09-024200.004200.00PaidBank Transfer
803100412024-08-294500.003000.00Partially PaidCredit Card
804100612024-09-054200.000.00OutstandingN/A
805100322025-01-045200.005200.00PaidBank Transfer
806100522025-01-052500.001250.00Partially PaidDebit Card
807100722025-01-062200.002200.00PaidCredit Card
Column Breakdown
Column NameData TypeConstraintsExplanation
payment_idINTPRIMARY KEYUnique identifier for each payment record.
student_idINTFOREIGN KEY β†’ studentsThe student the payment belongs to.
term_idINTFOREIGN KEY β†’ termsThe term the tuition covers.
payment_dateDATENoneThe date the payment was made or recorded.
amount_billedDECIMAL(10,2)NoneThe total amount the student was billed for the term.
amount_paidDECIMAL(10,2)NoneThe amount actually paid. 0.00 for Outstanding records.
payment_statusVARCHAR(30)NonePaid (3), Partially Paid (2), or Outstanding (1).
payment_methodVARCHAR(30)NoneCredit Card, Bank Transfer, Debit Card, or N/A for Outstanding.

The advising_sessions table logs meetings between students and their advisors. Each record includes the student, the advisor’s name, the date and type of session, session notes, and whether a follow-up is required. With five records covering four session types across academic and financial support contexts, this table is useful for student services queries and at-risk student reporting.

Why this table matters

The follow_up_required BOOLEAN column is another real-world institutional pattern. Queries that identify students needing follow-up and then join to their payment status or grade records create a holistic student support picture β€” the kind of insight that education SQL is designed to generate quickly from complex multi-table structures.

The Data
advising_session_idstudent_idadvisor_namesession_datesession_typesession_notesfollow_up_required
9011001Karen Lewis2024-10-03Academic PlanningDiscussed course selection for next term0
9021002Michael Chen2024-10-08Career AdvisingReviewed analytics internship options0
9031006Karen Lewis2024-10-15Academic SupportAttendance concerns and risk of withdrawal1
9041005Sarah Bennett2025-02-02Financial AdvisingDiscussed tuition payment options1
9051007Michael Chen2025-02-10Program AdvisingConfirmed certificate completion requirements0
Column Breakdown
Column NameData TypeConstraintsExplanation
advising_session_idINTPRIMARY KEYUnique identifier for each advising session record.
student_idINTFOREIGN KEY β†’ studentsThe student who attended the session.
advisor_nameVARCHAR(100)NoneThe name of the advisor: Karen Lewis, Michael Chen, or Sarah Bennett.
session_dateDATENoneThe date the advising session took place.
session_typeVARCHAR(50)NoneThe type of advising: Academic Planning, Career Advising, Academic Support, Financial Advising, or Program Advising.
session_notesVARCHAR(255)NoneA brief summary of what was discussed in the session.
follow_up_requiredBOOLEANNone1 = follow-up needed (sessions 903 and 904). 0 = no follow-up needed.

Quick Reference β€” All 11 Tables

The complete education_admin_sql_course database at a glance.

Campuses

3 rows β€” Main, Westshore, Online. PK: campus_id (1–3).

Departments

5 rows across 3 faculties. PK: department_id (1–5).

Instructors

5 rows β€” Full-Time and Contract. PK: instructor_id (1–5).

Programs

5 rows β€” Degree, Masters, Diploma, Certificates. PK: program_id (101–105).

Students

8 rows β€” Active, Inactive, Graduated. PK: student_id (1001–1008).

Terms

3 rows β€” Fall/Spring/Summer 2024/25. PK: term_id (1–3).

Courses

6 rows β€” 5 Undergraduate, 1 Graduate. PK: course_id (201–206).

Sections

6 rows β€” In-Person, Online, Hybrid. PK: section_id (301–306).

Teaching Assignments

6 rows β€” all Lead Instructor. PK: assignment_id (401–406).

Enrollments

9 rows β€” Completed, In Progress, Withdrawn. PK: enrollment_id (501–509).

Grades

7 rows β€” A+ to F. PK: grade_id (601–607).

Attendance

9 rows β€” Present and Absent. PK: attendance_id (701–709).

Tuition Payments

7 rows β€” Paid, Partially Paid, Outstanding. PK: payment_id (801–807).

Advising Sessions

5 rows β€” 4 session types, 2 follow-ups. PK: advising_session_id (901–905).

PRIMARY KEY FOREIGN KEY BOOLEAN DECIMAL DATE VARCHAR JOIN LEFT JOIN GROUP BY HAVING CASE WHEN SUBQUERY CTE SHOW TABLES SET FK CHECKS