| | 1 | = About: Courses Management System = |
| | 2 | |
| | 3 | == Team members: |
| | 4 | |
| | 5 | - Viktor Petrovski 231150 |
| | 6 | |
| | 7 | - Aleksandar Nikoloski 231082 |
| | 8 | |
| | 9 | - Martin Mitevski 231112 |
| | 10 | |
| | 11 | == Short description: |
| | 12 | |
| | 13 | The Courses Management System (CMS) is a relational database platform designed to support the full academic lifecycle of a higher-education institution. The database contains data about members (students and teachers), academic programs, courses and their editions, semester enrollments, exercises and exam assessments, grades, lecture materials, announcements, direct messaging between members, and surveys. The system consolidates these concerns into a single, coherent data model. Two security mechanisms are built into the design: member passwords are stored as SCRAM-SHA-256 hashes, and semester enrollment records are protected by a blockchain-inspired SHA-256 hash chain that makes retroactive tampering detectable. The intended application is a web-based course management platform serving a higher-education institution, with roles for students, teachers, and administrators. |
| | 14 | |
| | 15 | == Detailed description: |
| | 16 | |
| | 17 | The CMS manages the complete academic workflow of a higher-education institution within a single PostgreSQL database. At its core, the system distinguishes between abstract courses (a course as defined in a catalog) and course editions (a concrete offering of that course in a specific academic year and semester). This separation allows the institution to maintain a stable course catalog while independently scheduling and managing each semester's offerings. |
| | 18 | Members of the system are either students or teachers. A student is enrolled in exactly one academic program, and that program defines a curriculum — a set of courses recommended across semesters, some mandatory and some elective. Courses may have prerequisites, forming a directed dependency graph across the catalog. Teachers are assigned to course editions, and students who qualify may serve as teaching assistants to teachers. |
| | 19 | Each semester, a student's enrollment is recorded as a Semester Enrollment, which lists the course editions the student is taking that term. Final grades are recorded separately per student per course edition. Assessment is handled through two mechanisms: exercises (assignments with deadlines, submissions, and grading) and exams (scheduled events composed of individual problems, supporting multiple attempts per student with per-problem answers and points). |
| | 20 | Course editions also host lecture materials, announcements (which support threaded replies), and surveys (with defined options and student responses). Members can exchange direct private messages with one another. |
| | 21 | Password security is implemented via SCRAM-SHA-256 hashing. Semester enrollment records are made tamper-evident through a blockchain-inspired hash chain: each record stores the SHA-256 hash of the previous enrollment record for the same student, chained with the current record's data. Both mechanisms are planned for detailed implementation in Phase 5 as the advanced topic. |
| | 22 | |
| | 23 | == Who is the database and project intended for? |
| | 24 | |
| | 25 | The database and application are intended to be owned and operated by a higher-education institution — such as a faculty or university — and provided as an internal service to its students, teachers, and administrative staff. The institution is responsible for maintaining the course catalog, academic programs, and member accounts. |
| | 26 | |
| | 27 | == What problems does it solve? |
| | 28 | |
| | 29 | Higher-education institutions typically rely on a fragmented set of tools for course scheduling, enrollment tracking, assessment, communication, and grading. The CMS consolidates all of these into one system, reducing administrative overhead, eliminating data inconsistencies that arise from maintaining multiple disconnected databases, and providing a single source of truth for academic records. The tamper-evident enrollment chain additionally addresses the integrity concern of retroactive modification of official enrollment records. |
| | 30 | |
| | 31 | == What types of users will have access? |
| | 32 | |
| | 33 | Three user roles interact with the system: students (who enroll in courses, submit exercises, attempt exams, respond to surveys, and communicate with teachers), teachers (who manage course content, grade submissions, post announcements, and conduct exams), and administrators (who manage the member registry, academic programs, and course catalog). Teaching assistants are students who additionally take on a supporting teaching role for a specific teacher. |
| | 34 | |
| | 35 | == How is it different from existing solutions? |
| | 36 | |
| | 37 | General-purpose learning management systems such as Moodle or Canvas cover some of the same ground, but they are not designed around a structured relational academic data model. They typically lack first-class support for academic program curricula with prerequisite chains, per-semester enrollment records as auditable entities, or fine-grained exam modeling with per-problem attempts and answers. The CMS is designed from the ground up as a data-model-first system, with integrity and auditability as primary concerns, and with the blockchain-inspired enrollment chain as a novel addition not present in standard LMS platforms. |
| | 38 | |
| | 39 | == Is it a web, mobile, and/or desktop application? |
| | 40 | |
| | 41 | The intended application is a web-based platform, accessible from both desktop and mobile browsers. |
| | 42 | |
