The project identified four major spreadsheet limitations: 1) Data duplication across multiple files, 2) Inefficient queries requiring manual searching, 3) Data inconsistency when updates don't propagate, and 4) Limited accessibility for real-time information.
The project set specific performance targets: 90% reduction in data entry time, 100% elimination of duplicate data, real-time query response in less than 1 second, and support for 1,000+ concurrent users.
The project followed a 5-step systematic approach: 1) Analyze current spreadsheet structure, 2) Design normalized database, 3) Develop migration tools, 4) Create query interface, and 5) Implement validation systems.
School schedules involve complex overlapping systems: students are in multiple groups (classes, English levels, tech tracks, clubs) simultaneously, with different temporal structures and 5+ simultaneous affiliations per student.
The project created a Data Flow Diagram (DFD) to show system workflow and an Entity Relationship Diagram (ERD) to show database structure. The DFD addresses data flow issues, while the ERD solves structural problems.
The database was designed with 17 normalized tables organized into three layers: Security Layer (top), Core Data (middle), and Connection Hub (bottom). The key principle is that everything connects through the central Schedule Entries table.
A Telegram bot was developed as the functional prototype, supporting commands like /whereis (find student location), /schedule (show daily schedule), and /tomorrow (display tomorrow's schedule), demonstrating query efficiency improvements.
The project used Python for programming, SQLite for the database, Telegram for the bot platform, Pandas for data transformation, and Flask for API integration and web framework.
The manual spreadsheet method for finding a student's location takes 5-10 minutes across multiple files, while the database system provides responses in less than 1 second through optimized queries.
Future development includes: 1) Full system deployment replacing spreadsheets, 2) Parent/student web portal, 3) AI scheduling optimization, and 4) Analytics dashboard for data-driven insights.
The project estimated a 3-month implementation timeline: Month 1 for data migration and system setup, Month 2 for portal development and staff training, and Month 3 for full implementation and optimization.
The DFD addresses: 1) Centralized data flow (vs scattered spreadsheet files), 2) Automated synchronization (updates propagate instantly), 3) Single source of truth (eliminates duplicate entries), and 4) Real-time validation (catches errors immediately).
Core tables include: students, teachers, subjects (centralized entities), schedule_entries (main scheduling table), and audit_log (comprehensive change tracking). Relationship tables handle student_subjects and student_groups connections.
The database is organized into three conceptual layers: 1) Security Layer (users, audit_log), 2) Core Data (people, places, groups), and 3) Connection Hub (schedule_entries, time_management, special_groups).
Students belong to multiple simultaneous groups: 1) Primary class groups (4A, 4B), 2) English proficiency groups (E1-E6), 3) Technology track groups, 4) Olympiad groups, and 5) Extracurricular activities, each potentially in separate spreadsheets.
Technical solutions include: 1) Structured design prevents duplication, 2) API layer provides real-time access, 3) Data migration transforms spreadsheets, 4) Query optimization enables sub-second responses, and 5) Real-time updates ensure synchronization.
Current limitations cause: 1) Administrative staff spend significant time reconciling information, 2) Room changes require updates in multiple files, 3) Parents/students lack real-time access, and 4) Manual searching takes 5-10 minutes.
The project scope included: 1) Problem analysis and requirements, 2) System design (DFD/ERD), 3) Functional prototype (Telegram bot), and 4) Implementation plan with timeline and technology stack.