How debashishcodes/student-record-management-system works
Purpose and Runtime
This is a local desktop Student Record Management System. It provides a Tkinter interface for creating, viewing, editing, deleting, and searching student records, with dashboard statistics and theme support. It runs under Python 3; Pillow supports background-image handling, while SQLite provides embedded persistence.
Primary launch command: python main.py (main.py).
Entry Point and Application Composition
main.py is the executable entry point and initializes the graphical application. The principal application flow is:
main.py → GUI/controller → model validation → SQLite data access → local database file.
The application is single-process and local-only; no network API, web server, authentication provider, or external hosted service is indicated.
Paths: main.py, gui.py, students.db.
GUI / Interaction Controller
The Tkinter UI owns user interaction and presentation: data-entry form, selectable student table, search controls, CRUD actions, dashboard metrics, status messaging, and light/dark mode. It coordinates requests from UI events, populates the table from query results, and loads selected records into the edit form.
The GUI is the control-flow boundary between users and business/data layers; it should not bypass validation or directly encode persistence behavior.
Paths: gui.py, main.py.
Student Domain and Validation
The student layer represents the core record shape: ID, name, age, course, and email. It performs required-field and format validation, including email and age-related checks, before records are persisted or updated.
Validated student data moves from GUI form inputs to database operations. Validation failures return to the UI as user-facing status or error feedback rather than reaching SQLite.
Paths: student.py, gui.py.
Persistence Layer
The database layer encapsulates SQLite operations: database/table initialization and CRUD/query behavior for student records. It is the persistence boundary used by the GUI/application layer and maps student fields to the students table.
Search queries support name, course, or email filtering. Aggregate queries support dashboard values such as total students, total courses, and latest student.
Paths: database.py, students.db.
Record Lifecycle and Data Flows
• Create/update: GUI collects form data → student.py validates → database.py inserts or updates → GUI refreshes table/dashboard and reports status.
• Read/search: GUI requests all records or a search → database.py queries SQLite → GUI renders returned rows in the table.
• Delete: GUI requires a selected record and confirmation → database.py deletes by record identity → GUI refreshes displayed state.
• Selection: Table selection supplies the selected student record to the form for editing or deletion.
Paths: gui.py, student.py, database.py.
State and Infrastructure Boundaries
Persistent state resides in the repository-local SQLite file, students.db; database schema and data are coupled to the desktop installation. UI state—form contents, current table view, selected row, theme, and status text—exists in the Tkinter process.
Material dependencies are Python 3, standard-library Tkinter and SQLite support, and Pillow/PIL for image rendering. The README references a background image, but it is not present in the supplied file tree.
Paths: students.db, gui.py, database.py.
Main entry points: gui.py Tkinter GUI Controller · database.py SQLite Data Access · student.py Student Validation · students.db Students Table
Components 11
Desktop Application
- Application Entry · Starts the local Tkinter application.
main.py - Tkinter GUI Controller · Owns forms, table, search, dashboard, theme, and user feedback.
gui.py - UI State · Form values, selected row, current view, theme, and status text.
gui.py - Student Table View · Renders query results and supplies selected records for editing or deletion.
gui.py - Dashboard Metrics · Shows totals, courses, and latest-student aggregates.
gui.py - Status & Errors · Displays validation failures and operation results.
gui.py - Pillow / PIL · Supports background-image rendering when an image is available.
Domain & Persistence
- Student Validation · Validates required fields, email, and age for student records.
student.py - SQLite Data Access · Initializes schema and encapsulates CRUD, search, and aggregate queries.
database.py - Students Table · Stores student ID, name, age, course, and email.
students.db - Local Database File · Repository-local SQLite database for the desktop installation.
students.db
Connections 13
- Application Entry → Tkinter GUI Controller: initializes
- Tkinter GUI Controller → UI State: maintains
- Tkinter GUI Controller → Student Validation: validates form data
- Student Validation → SQLite Data Access: validated records
- Tkinter GUI Controller → SQLite Data Access: read, search, delete, metrics
- SQLite Data Access → Students Table: CRUD and queries
- Students Table → Local Database File: stored in
- SQLite Data Access → Student Table View: record rows
- Student Table View → Tkinter GUI Controller: selection
- SQLite Data Access → Dashboard Metrics: aggregate results
- Student Validation → Status & Errors: validation failures
- Tkinter GUI Controller → Status & Errors: operation feedback
- Tkinter GUI Controller → Pillow / PIL: renders images