Skip to main content

📊 Smart Campus Database Documentation

🏗️ Database Overview​

The Smart Campus application uses MongoDB with Mongoose ODM for data management. The database follows a microservices-oriented design with clear separation of concerns and consistent naming conventions.

🔧 Common Features​

  • Soft Delete: All models use mongoose-delete plugin for soft deletion
  • Timestamps: Most models include createdAt and updatedAt fields
  • Plural Collections: All collections use plural naming (e.g., users, classrooms)

📋 Database Models​

1. 👥 Users Collection (users)​

Purpose: Central user management for students, teachers, and administrators

{
  firstName: String (required),
  middleName: String (optional),
  lastName: String (optional),
  gender: String (enum: ["male", "female"]),
  dob: Date,
  email: String (required),
  password: String (required),
  address: String,
  contactNo: String,
  nfcTag: String, // For NFC-based attendance
  role: String (required, enum: ["admin", "student", "teacher"]),
  college: String,
  courseName: String,
  branch: String,
  parentContactNo: String, // Students only
  semester: Number (enum: [1,2,3,4,5,6,7,8]) // Students only
}

2. 📚 Subjects Collection (subjects)​

Purpose: Academic subject definitions

{
  name: String (required),
  code: String (required)
}

3. 🏫 Classrooms Collection (classrooms)​

Purpose: Physical classroom management with NFC scanner integration

{
  roomNumber: Number (required),
  capacity: Number (required),
  isLab: Boolean (default: false),
  scanner: ObjectId → scanners (required)
}

4. 📡 Scanners Collection (scanners)​

Purpose: NFC scanner device management

{
  name: String (required),
  macAddress: String,
  isActive: Boolean (default: true)
}

5. 📅 TimeTables Collection (timeTables)​

Purpose: Class schedule definition linking subjects, classrooms, and teachers

{
  subject: ObjectId → subjects (required),
  startTime: Date (required),
  endTime: Date (required),
  classroom: ObjectId → classrooms (required),
  teacher: ObjectId → users (required),
  teacherEntryTime: Date,
  teacherExitTime: Date
}

6. 👨‍🎓 StudentTimeTable Collection (studentTimeTable)​

Purpose: Links students to specific timetable entries and tracks presence status

{
  student: ObjectId → users (required),
  timeTable: ObjectId → timeTables (required),
  isMarkedPresent: Boolean (default: false)
}

7. ✅ Attendance Collection (attendance)​

Purpose: Records actual attendance events with timing details

{
  user: ObjectId → users (required),
  timeTable: ObjectId → timeTables (required),
  timeOfAttendance: Date (default: Date.now),
  isLate: Boolean (default: false)
}

8. 📊 NfcReaderEntries Collection (nfcReaderEntries)​

Purpose: Raw NFC scan data logging

{
  entryTime: Date (default: Date.now),
  nfcTag: String (required),
  scanner: String → scanner (required)
}

Note: Has time-based index for efficient queries

9. 📝 Assignments Collection (assignments)​

Purpose: Assignment content management (basic implementation)

{
  content: String (default: "")
}

🔗 Entity Relationship Diagram​

🔄 Data Flow Architecture​

NFC Attendance Processing Flow​

Database Query Patterns​

🎯 Key Design Patterns​

1. Role-Based User Model​

  • Single users collection handles all user types
  • Role field determines permissions and available fields
  • Students have additional fields (semester, parentContactNo)

2. Timetable-Centric Architecture​

  • timeTables is the central scheduling entity
  • Links subjects, classrooms, teachers, and time slots
  • studentTimeTable creates many-to-many relationship with students

3. Dual Attendance System​

  • studentTimeTable.isMarkedPresent: Quick boolean flag
  • attendance: Detailed records with timing and late status

4. Asynchronous Processing​

  • Raw NFC data immediately persisted
  • Business logic processed in background
  • Parallel job execution for performance

5. Soft Delete Pattern​

  • All models support soft deletion
  • Data integrity maintained for historical records
  • Easy restoration of accidentally deleted data

📈 Performance Considerations​

Indexes​

  • nfcReaderEntries has time-based index: { entryTime: 1 }
  • Consider adding compound indexes for frequent queries:
    • users: { nfcTag: 1, role: 1 }
    • timeTables: { classroom: 1, startTime: 1, endTime: 1 }
    • studentTimeTable: { student: 1, timeTable: 1 }

Query Optimization​

  • Use Promise.all() for parallel database operations
  • Population strategy for related documents
  • Time-window queries for timetable matching

🔒 Security & Data Integrity​

Access Control​

  • Role-based authorization in routes
  • User creation restricted to admin/teachers
  • Soft delete prevents accidental data loss

Data Validation​

  • Required fields enforced at schema level
  • Enum validation for roles and semesters
  • Reference integrity through ObjectId relationships

Audit Trail​

  • Timestamps on all relevant models
  • NFC entry logging for debugging
  • Comprehensive error logging in workers

This documentation provides a complete overview of your Smart Campus database structure. The design supports efficient attendance tracking through NFC technology while maintaining data integrity and audit capabilities.