K-12 class-based (the baseline)
Who uses it: Developer building a first school management system
Student (id, name, grade_level)
Class (id, teacher_id, subject, room) — a fixed group
Enrollment (id, student_id, class_id, year)
Teacher (id, department_id, name)
Students belong to a class for the whole year
Why this works: K-12 schools assign students to a fixed class for the year, so enrollment is relatively static — the schema is simplest here because a student's class rarely changes mid-term, unlike a university.
University with course sections
Who uses it: Team building a higher-ed registration system
Course (id, department_id, code, credits) — the catalog entry
Section (id, course_id, teacher_id, term, schedule, capacity)
Enrollment links a student to a specific Section, not the Course
Prerequisites modeled as a Course-to-Course self relation
Capacity enforced per section
Why this works: Universities split Course (the catalog) from Section (a specific offering this term) — enrollment points at a section, which is what lets the same course run multiple times with different teachers, schedules, and capacities.
Online courses
Who uses it: Team building an LMS or MOOC platform
Course (id, title, self_paced) with Lesson and Module children
Enrollment (id, student_id, course_id, progress, completed_at)
Progress tracked per lesson, not just per course
No fixed term — enrollment is open-ended
Certificate issued on completion
Why this works: Online learning replaces the term and section model with progress tracking — the diagram adds lessons and a progress field, because the key data is how far through the material each student is, not which physical class they're in.
Detailed gradebook
Who uses it: Team where assignment-level grading matters
Assignment (id, course_id, name, weight, max_score)
Submission (id, enrollment_id, assignment_id, score, submitted_at)
Final Grade is computed from weighted submissions
Late penalties tracked on the submission
Grade history preserved for appeals
Why this works: A real gradebook records every assignment submission, not just a final grade — the diagram adds Assignment and Submission so the final grade is derived from weighted parts, making it auditable and appealable.
CS course ER-diagram assignment
Who uses it: Student handing in a database-design assignment
Start from the baseline schema and rename to match the assignment prompt
Add cardinality labels (1..N, N..M) on every relationship line
Annotate primary and foreign keys explicitly on each entity
Include a short design-decision note (why Enrollment, why grades on Enrollment)
Export as PNG to attach to the submission
Why this works: For a class assignment, the diagram is the deliverable — instructors grade the reasoning, so make the resolver-table decision, key markings, and cardinality all explicitly visible on the diagram. The design notes are what separates a passing answer from a good one.
School admin dashboard schema (read model)
Who uses it: Team building admin reports on top of the transactional schema
Views or read tables: StudentTermSummary, ClassRoster, CoursePassRate
Rolled up from Enrollment + Grade for query performance
Refreshed daily or on grade-post events
Kept separate from write-side entities to protect transactional integrity
Powers principal / registrar dashboards without heavy JOINs
Why this works: Once the transactional schema is stable, admin reporting benefits from a small read model — precomputed summaries by student-term, class roster, or per-course pass rate. This keeps the write side clean while making dashboards fast; the diagram makes the split explicit.
