CS340 Project Plan Dashboard

Rose - User & Access Control Module
Authentication, Roles, Audit Logging
المصادقة، الأدوار، سجل المراجعة
Phases 2-5
MySQL, Node.js
Independent Module
Phase 2 - EER Diagram
Design
Define entities: USER, ROLE, AUDIT_LOG with relationships and constraints.
  • Use diagrams.net or Lucidchart
  • Define keys and relationships
  • Add constraints (unique email, hashed password)
  • Team checkpoint for verification
Tools Needed
  • diagrams.net (draw.io) OR Lucidchart (EER diagram)
  • Phase 1 requirements (roles + audit/log requirement)
Steps to Complete Phase 2
  1. Define entities: USER (stores identity + credentials), ROLE (optional table) OR role attribute inside USER, AUDIT_LOG (stores user activity)
  2. Define keys: USER: user_id as PK, AUDIT_LOG: log_id as PK, If ROLE is separate: role_id as PK
  3. Add relationships: USER (1) - (M) AUDIT_LOG ("a user generates many logs; each log belongs to one user")
  4. Add constraints: Every USER must have a role (Citizen/Admin/Provider), Email must be unique, Credentials required (password stored hashed), AUDIT_LOG must reference a valid USER
  5. Team checkpoint (quick review): One teammate verifies cardinalities, Another teammate verifies roles match Phase 1
Phase 3 - Relational Design
Schema
Map entities to tables, define foreign keys and constraints.
  • USER and AUDIT_LOG tables
  • Decide role representation (ENUM or table)
  • Add NOT NULL and UNIQUE constraints
  • Share USER PK definition with team
Tools Needed
  • Google Docs / Word (write schema + explanation)
  • Optional: dbdiagram.io (visual relational schema)
Steps to Complete Phase 3
  1. Map entities to tables: USER(user_id PK, email UNIQUE, full_name, role, password_hash, created_at), AUDIT_LOG(log_id PK, user_id FK, action, timestamp, metadata)
  2. Decide role representation (team decision): Option A (simpler for CS340): role is an ENUM-like attribute in USER, Option B: ROLE table + FK in USER, Choose one and keep consistent everywhere
  3. Add constraints: email UNIQUE NOT NULL, password_hash NOT NULL, user_id FK in AUDIT_LOG with ON DELETE behavior (team chooses: CASCADE or RESTRICT)
  4. Write short mapping explanation: Why audit log is separate (multi-entry history, security, traceability)
  5. Integration alignment: Share final USER(user_id) definition with other members so they reference the correct PK name/type
Phase 4 - SQL Implementation
Development
Write DDL scripts, insert test data, and validate integrity.
  • Create tables with MySQL
  • Insert ≥10 users and 10-30 audit logs
  • Test referential integrity
  • Export schema.sql and seed.sql
Tools Needed
  • DBMS: MySQL (likely for CS340) + MySQL Workbench OR phpMyAdmin
  • Optional: VS Code + SQL file (schema.sql, seed.sql)
Steps to Complete Phase 4
  1. Write DDL scripts: CREATE TABLE user (...), CREATE TABLE audit_log (...) with FK referencing USER
  2. Choose FK delete rule (team-consistent): Recommended: AUDIT_LOG.user_id → USER.user_id ON DELETE CASCADE (keeps DB clean) OR RESTRICT (keeps logs as evidence, but requires strategy). Pick one based on team policy
  3. Insert test data: Insert ≥10 users, Insert ≥10 - 30 logs with different actions: LOGIN_SUCCESS, LOGIN_FAIL, CREATE_FAMILY_MEMBER, BOOK_APPOINTMENT, ALERT_GENERATED
  4. Verify integrity: Try inserting a log with a non-existing user_id (should fail), Try inserting duplicate email (should fail)
  5. Export scripts: Deliver schema.sql + seed.sql to the team repo
Phase 5 - Application & Queries
Deployment
Implement backend endpoints, RBAC, and audit logging.
  • Node.js/Express backend with MySQL
  • Implement /auth/register, /auth/login
  • Role-based access control middleware
  • 5 basic + 5 advanced SQL queries
Tools Needed
  • Backend: Node.js with Express.js
  • Database: MySQL, Database Connector: mysql2 (Node.js)
  • Password Security: bcrypt
  • API Testing: Postman or browser
  • Development Environment: VS Code
Steps to Complete Phase 5
  1. Backend Endpoints (Minimum Required): Implement Express routes: POST /auth/register (Registers a new user and stores hashed credentials), POST /auth/login (Authenticates user credentials), GET /admin/audit-logs (Retrieves all audit logs - Admin access only)
  2. Login Validation Flow: 1. Receive email and password from request body, 2. Query USER table by email, 3. Compare password using bcrypt.compare(), 4. Return authentication success or failure response. This flow must be logged in the audit table
  3. Role-Based Access Control (RBAC): Implement Express middleware that checks user role after authentication and allows or denies access based on role. Example: Only users with role Admin can access /admin/audit-logs
  4. Audit Log Insertion: Audit logging must occur automatically. On every login attempt: Insert a row into AUDIT_LOG with user_id, action (LOGIN_SUCCESS / LOGIN_FAILED), timestamp. For major system actions owned by other modules: Provide a shared helper function: logAction(user_id, action, metadata) for other team members to call from their modules
  5. SQL Queries Requirement (CS340): 5 Basic Queries (Insert new user, Select user by email, Insert audit log, Select audit logs for user, Update user role) and 5 Advanced Queries (Count login attempts per user, Filter failed login attempts in last 7 days, Join USER and AUDIT_LOG, Retrieve top 5 most active users, Detect suspicious activity)
Raghad - Family & Medical History Module
Family structure and medical history management
هيكل الأسرة وإدارة التاريخ الطبي
Phases 2-5
MySQL, Node.js
Feeds Risk Module
Phase 2 - EER Diagram
Design
Define FAMILY_MEMBER and HEALTH_EVENT entities with relationships.
  • FAMILY_MEMBER with PK family_member_id
  • HEALTH_EVENT with PK event_id
  • Relationships: USER → FAMILY_MEMBER → HEALTH_EVENT
  • Team checkpoint with Rose and Shoug
Tools Needed
  • diagrams.net (draw.io) or Lucidchart (EER modeling)
  • Phase 1 reference: Add/Edit Family Member screen, Add Health Event requirement (FR-02)
Steps to Complete Phase 2
  1. Define entities: FAMILY_MEMBER (Represents individuals within a user's family), HEALTH_EVENT (Represents recorded health conditions/events)
  2. Define primary keys: FAMILY_MEMBER: family_member_id (PK), HEALTH_EVENT: event_id (PK)
  3. Define relationships: USER (1) (M) FAMILY_MEMBER (a user can have multiple family members), FAMILY_MEMBER (1) (M) HEALTH_EVENT (a family member can have multiple health events)
  4. Add constraints: Every FAMILY_MEMBER must belong to exactly one USER, Every HEALTH_EVENT must belong to exactly one FAMILY_MEMBER, onset_age must be a non-negative integer, severity should use controlled values (Low / Medium / High)
  5. Team checkpoint: Confirm USER.user_id naming with Rose, Confirm severity values match what Shoug expects for risk logic
Phase 3 - Relational Design
Schema
Map entities to tables, define foreign keys and constraints.
  • FAMILY_MEMBER and HEALTH_EVENT tables
  • Define foreign keys to USER and FAMILY_MEMBER
  • Add is_hereditary field for risk analysis
  • Share table definitions with Shoug
Tools Needed
  • Docs/Word (schema + explanation)
  • Optional: dbdiagram.io for relational visualization
Steps to Complete Phase 3
  1. Map entities to tables: FAMILY_MEMBER(family_member_id PK, user_id FK, relation, gender, dob), HEALTH_EVENT(event_id PK, family_member_id FK, condition, onset_age, severity, is_hereditary)
  2. Define foreign keys: FAMILY_MEMBER.user_id → USER.user_id, HEALTH_EVENT.family_member_id → FAMILY_MEMBER.family_member_id
  3. Add design decisions: Include is_hereditary (BOOLEAN) to support risk analysis, Store dob instead of age to keep data consistent over time
  4. Write short mapping explanation: FAMILY_MEMBER represents family structure, HEALTH_EVENT captures time-based medical history per individual
  5. Integration alignment: Share final table definitions with Shoug so alert aggregation queries align
Phase 4 - SQL Implementation
Development
Write CREATE TABLE statements, insert test data, and validate.
  • Create FAMILY_MEMBER and HEALTH_EVENT tables
  • Add ENUM or CHECK constraints for severity
  • Insert ≥10 family members and ≥20 health events
  • Validate referential integrity
Tools Needed
  • MySQL Workbench or phpMyAdmin
  • SQL files: schema.sql, seed.sql
Steps to Complete Phase 4
  1. Write CREATE TABLE statements: Create FAMILY_MEMBER first, Create HEALTH_EVENT with FK constraint
  2. Add constraints: NOT NULL on: user_id, family_member_id, condition, ENUM or CHECK constraints for: severity (Low / Medium / High), FK constraints with referential integrity enforced
  3. Insert test data: Insert ≥10 family members across multiple users, Insert ≥20 health events: mix hereditary and non-hereditary varying onset ages and severity levels
  4. Validation checks: Attempt inserting a health event with invalid family_member_id → must fail, Ensure each family member has at least one event (for demo clarity)
  5. Export scripts: Provide team with schema + seed data SQL
Phase 5 - Application & Queries
Deployment
Implement backend API endpoints and required SQL queries.
  • POST /family-members, POST /health-events
  • GET /medical-history endpoint
  • 5 basic + 5 advanced SQL queries
  • Log integration with Rose's module
Tools Needed
  • Backend: Node.js + Express
  • DB Connector: mysql2
  • Testing: Postman and/or basic UI forms
  • Editor: VS Code
Steps to Complete Phase 5
  1. Backend API Endpoints (Minimum): Implement Express routes: POST /family-members (Adds a new family member for a user), POST /health-events (Records a health event for a family member), GET /medical-history?family_member_id=... (Retrieves all health events for a given family member)
  2. SQL Queries Requirement (CS340): 5 Basic Queries (Insert a family member, Insert a health event, Select all family members for a user, Select health events for a family member, Update a health event), 5 Advanced Queries (Join FAMILY_MEMBER and HEALTH_EVENT, Filter hereditary conditions only, Count conditions per family member, Find earliest onset age per condition, List family members with more than N conditions)
  3. Data Flow for Other Modules: This module feeds data into Risk Alerts & Analysis (Shoug), It does not generate alerts itself, Only provides clean, structured medical data
  4. Logging Integration (With Rose's Module): After major actions, log events: After adding family member: logAction(user_id, "ADD_FAMILY_MEMBER", { family_member_id }), After adding health event: logAction(user_id, "ADD_HEALTH_EVENT", { family_member_id, condition })
  5. Summary: This module establishes the core family and medical data layer of Sillah, demonstrating proper relational modeling, referential integrity, advanced SQL queries, and clean integration with analytics and alerts
Shoug - Risk Alerts & Analysis Module
Detection, alerts, and aggregation logic
الكشف، التنبيهات، ومنطق التجميع
Phases 2-5
MySQL, Node.js
Depends on Medical Data
Phase 2 - EER Diagram
Design
Define ALERT entity with relationships to FAMILY_MEMBER and HEALTH_EVENT.
  • ALERT entity with PK alert_id
  • Relationship: FAMILY_MEMBER (1) (M) ALERT
  • Connect to HEALTH_EVENT aggregation
  • Add status and risk_level constraints
Tools Needed
  • diagrams.net (draw.io) / Lucidchart (EER diagram)
  • Phase 1 reference: Risk Alerts screen, "Generate Risk Alert" requirement (FR-03), Alert history (FR-06)
Steps to Complete Phase 2
  1. Define entity: ALERT with attributes: alert_id (PK), family_member_id (FK), risk_level (Low/Moderate/High), description, created_date, status (Active/Resolved)
  2. Define relationship: FAMILY_MEMBER (1) (M) ALERT (a family member can receive multiple alerts over time)
  3. Connect to Health Events (conceptual reference): ALERT is derived from HEALTH_EVENT aggregation. In EER, you can show this as a relationship "derived_from" (optional), or explain in text: risk_level is computed from HEALTH_EVENT records
  4. Add constraints: status ∈ {Active, Resolved}, risk_level ∈ {Low, Moderate, High}, every ALERT must reference a valid family member
  5. Team checkpoint: Confirm shared key name: family_member_id, Confirm "risk level" values match Phase 1 wording
Phase 3 - Relational Design
Schema
Create ALERT table schema, define foreign keys and constraints.
  • ALERT table with PK alert_id
  • Foreign key to FAMILY_MEMBER
  • ENUM for risk_level and status
  • Confirm PK names with medical module
Tools Needed
  • Docs/Word (schema + explanation)
  • Optional: dbdiagram.io for relational diagram
Steps to Complete Phase 3
  1. Create ALERT table schema: ALERT(alert_id PK, family_member_id FK, risk_level, description, created_date, status)
  2. Define foreign key: ALERT.family_member_id → FAMILY_MEMBER.family_member_id
  3. Decide if you need event-level linkage (optional, advanced): If you want each alert tied to specific events: create ALERT_EVENT(alert_id FK, event_id FK) (bridge table). If you want simplest implementation (recommended for speed): keep only family_member_id (alerts are per family member)
  4. Write short mapping explanation: Why ALERT is separate from HEALTH_EVENT: alerts are computed outcomes, stored as history, supports "View Alert History"
  5. Integration alignment: Confirm FAMILY_MEMBER PK name/type with the medical module owner, Keep types consistent (e.g., INT)
Phase 4 - SQL Implementation
Development
Write DDL, insert sample alerts, and validate referential integrity.
  • CREATE TABLE ALERT with constraints
  • Use ENUM for risk_level and status
  • Insert sample alerts across family members
  • Validate with non-existing family_member_id
Tools Needed
  • MySQL Workbench / phpMyAdmin
  • SQL scripts: schema.sql + seed.sql
Steps to Complete Phase 4
  1. Write DDL: CREATE TABLE ALERT (...) with PK, FK, NOT NULL constraints, optional CHECK constraints (if DB supports; MySQL 8 supports CHECK but historically ignored—safe alternative is ENUM)
  2. Recommended: risk_level as ENUM('Low','Moderate','High'), status as ENUM('Active','Resolved')
  3. Insert sample alerts: Create alerts across multiple family members, Include variety: different risk levels, some resolved, some active, different timestamps
  4. Validate referential integrity: attempt insert with non-existing family member_id → must fail
  5. Export scripts: Provide the team with create table SQL and seed data inserts
Phase 5 - Application & Queries
Deployment
Risk scoring logic, backend endpoints, and alert generation flow.
  • Risk detection must remain preventive and educational
  • GET /alerts, POST /alerts/generate, PATCH /alerts/:id/resolve
  • 5 basic + 5 advanced SQL queries
  • Log integration with Rose's module
Tools Needed
  • Backend: Node.js with Express.js
  • Database: MySQL, DB Connector: mysql2 (Node.js)
  • Testing: Postman and/or basic UI pages
  • Development Environment: VS Code
Steps to Complete Phase 5
  1. Define Risk Logic (Simple & Explainable): Risk detection must remain preventive and educational, not diagnostic. The logic should be transparent and easy to justify during demo
  2. Risk Scoring Rules: Each health event contributes to total risk score: +2 points if condition is hereditary, +1 point if onset_age < 40, +1 point if severity level is High. Risk Level Classification: 0-2 points → Low, 3-4 points → Moderate, ≥5 points → High
  3. Backend API Endpoints: GET /alerts?user_id=... (Retrieves alert history for all family members belonging to user), POST /alerts/generate?family_member_id=... (Analyzes health events and generates new alert), PATCH /alerts/:id/resolve (Marks existing alert as Resolved)
  4. SQL Queries Requirement: 5 Basic Queries (Insert new alert, Select alerts for family member, Update alert status, Delete alert, Select active alerts), 5 Advanced Queries (Aggregate health events to compute risk score, Generate risk levels using CASE, Join FAMILY_MEMBER and ALERT, Analyze alert trends, Detect repeated hereditary conditions)
  5. Logging Integration: Each major alert action must be logged using Rose's shared logging utility: After generating alert: logAction(user_id, "ALERT_GENERATED", { family_member_id, risk_level }), After resolving alert: logAction(user_id, "ALERT_RESOLVED", { alert_id })
Yara - Appointments, Clinics & Awareness Module
Clinic browsing, appointment booking, awareness content
تصفح العيادات، حجز المواعيد، محتوى التوعية
Phases 2-5
MySQL, Node.js
Depends on USER table
Phase 2 - EER Diagram
Design
Define CLINIC, APPOINTMENT, AWARENESS_CONTENT entities and relationships.
  • CLINIC: clinic_id PK, name, specialty, location
  • APPOINTMENT: appointment_id PK, user_id FK, clinic_id FK
  • AWARENESS_CONTENT: content_id PK, topic, description
  • Relationships: USER→APPOINTMENT, CLINIC→APPOINTMENT
Tools Needed
  • diagrams.net (draw.io) / Lucidchart (EER diagram)
  • Phase 1 reference (screens: Clinic Booking + Awareness Hub)
Steps to Complete Phase 2
  1. Define entities: CLINIC: stores clinic details (name, specialty, location), APPOINTMENT: booking records, AWARENESS_CONTENT: educational content
  2. Define primary keys: CLINIC: clinic_id (PK), APPOINTMENT: appointment_id (PK), AWARENESS_CONTENT: content_id (PK)
  3. Add relationships + cardinality: USER (1) (M) APPOINTMENT (one user can book many appointments), CLINIC (1) (M) APPOINTMENT (one clinic can have many appointments), AWARENESS_CONTENT is standalone (no required relationship)
  4. Add constraints: APPOINTMENT must reference a valid USER and CLINIC (FK + total participation), Appointment status should be controlled values (e.g., Pending/Confirmed/Cancelled), Date/time must be mandatory
  5. Team checkpoint: One teammate confirms FK relationships match the global USER table, Another teammate confirms appointment workflow matches Phase 1 screens
Phase 3 - Relational Design
Schema
Map entities to relations, define foreign keys and constraints.
  • CLINIC, APPOINTMENT, AWARENESS_CONTENT tables
  • APPOINTMENT with user_id and clinic_id FKs
  • Appointment time as DATETIME column
  • Confirm USER.user_id type with Rose
Tools Needed
  • Docs/Word for schema explanation
  • Optional: dbdiagram.io for relational diagram
Steps to Complete Phase 3
  1. Map entities to relations: CLINIC(clinic_id PK, name, specialty, location), APPOINTMENT(appointment_id PK, user_id FK, clinic_id FK, appointment_datetime, status, created_at), AWARENESS_CONTENT(content_id PK, topic, title, description, created_at)
  2. Decide appointment time design: Recommended: appointment_datetime as a single DATETIME column (cleaner than separate date/time)
  3. Define foreign keys: APPOINTMENT.user_id → USER.user_id, APPOINTMENT.clinic_id → CLINIC.clinic_id
  4. Write brief mapping justification: APPOINTMENT is the linking entity between USER and CLINIC, Awareness content is separate because it's informational and not transactional
  5. Integration alignment: Confirm with Rose the exact USER.user_id type (INT/UUID) so FK types match
Phase 4 - SQL Implementation
Development
Write CREATE TABLE statements, insert test data, and validate.
  • Create CLINIC, APPOINTMENT, AWARENESS_CONTENT tables
  • Add constraints (NOT NULL, UNIQUE, FK)
  • Insert ≥10 clinics and ≥10-20 appointments
  • Validate with non-existing IDs
Tools Needed
  • MySQL Workbench or phpMyAdmin
  • SQL files in repo: schema.sql, seed.sql
Steps to Complete Phase 4
  1. Write CREATE TABLE statements: Create CLINIC first, Create USER table reference must already exist (from Rose's module), Create APPOINTMENT with both foreign keys, Create AWARENESS_CONTENT
  2. Add constraints: status NOT NULL (use controlled values), appointment_datetime NOT NULL, clinic.name NOT NULL, Optional UNIQUE rule (team decision): prevent double booking per clinic/time: UNIQUE(clinic_id, appointment_datetime)
  3. Insert test data: ≥10 clinics (diverse specialties + locations), ≥10 - 20 appointments (different users/clinics/status), 10 awareness content items (topics: heart health, diabetes, nutrition, screening, genetics)
  4. Validation checks: Attempt appointment insert with non-existing clinic_id → should fail, Attempt appointment insert with non-existing user_id → should fail, Ensure seed data follows FK rules
  5. Export scripts: Provide team with module scripts + sample insert statements
Phase 5 - Application & Queries
Deployment
Implement backend endpoints, core workflow, and SQL queries.
  • GET /clinics, POST /appointments, GET /appointments, GET /awareness
  • Core workflow: select clinic → choose date/time → insert appointment
  • 5 basic + 5 advanced SQL queries
  • Log integration with Rose's module
Tools Needed
  • Backend: Node.js with Express.js
  • Database: MySQL, Database Connector: mysql2
  • Testing: Postman and/or basic UI forms
  • Development Environment: VS Code
Steps to Complete Phase 5
  1. Backend Endpoints (Minimum Required): Implement Express routes: GET /clinics (Retrieves list of available clinics), POST /appointments (Books new appointment for user), GET /appointments?user_id=... (Retrieves all appointments booked by specific user), PATCH /appointments/:id (Updates appointment status - Cancel / Confirm), GET /awareness (Retrieves health awareness content)
  2. Core Workflow: 1. User selects a clinic, 2. User chooses an available date and time, 3. Application inserts a new row into the APPOINTMENT table, 4. User can view appointment status (Pending / Confirmed / Cancelled). This workflow directly maps to the Clinic Booking and Awareness Hub screens defined in Phase 1
  3. SQL Queries Requirement (CS340): 5 Basic Queries (Insert new appointment, Select all clinics, Select appointments for specific user, Update appointment status, Select all awareness content), 5 Advanced Queries (Join appointments with clinic details, Filter appointments by date range, Count appointments per clinic, List clinics with zero appointments, Identify most booked clinic specialties)
  4. Logging Integration (With User & Access Control Module): After booking or canceling an appointment, log the action using Rose's shared helper function: logAction(user_id, "BOOK_APPOINTMENT", { clinic_id, Appointment_datetime })
  5. Summary: This phase demonstrates CRUD operations through Node.js backend, relational joins and aggregation queries, proper handling of transactional data (appointments), and clean integration with authentication and logging modules
Shared Work & Collaboration
Tasks to be done together and dependencies
المهام التي يجب القيام بها معًا والتبعيات
Zero Blocking Strategy
The project uses a dependency-free strategy where each member owns a self-contained feature module that appears in all phases. The only shared agreement is on primary key names (e.g., user_id, family_member_id). No shared table ownership.
Fixed Shared Skeleton
From Phase 1, the global entities are locked: USER, FAMILY_MEMBER, HEALTH_EVENT, ALERT, APPOINTMENT, CLINIC, AWARENESS_CONTENT, AUDIT_LOG. These names cannot be changed by anyone.
Rose's Collaboration Points
  • Needs from team: Confirm role list: Citizen/Admin/HealthcareProvider, Confirm DBMS and naming convention
  • Team needs from Rose: Final USER schema (PK + data types), Shared helper: logAction(user_id, action, metadata)
Raghad's Collaboration Points
  • Needs from team: Confirm USER.user_id naming with Rose, Confirm severity values match what Shoug expects for risk logic
  • Team needs from Raghad: Final table definitions + data types for FAMILY_MEMBER and HEALTH_EVENT, Query list labeled as Basic vs Advanced
Shoug's Collaboration Points
  • Needs from team: Confirm HEALTH_EVENT fields that exist: condition, onset_age, severity, is_hereditary, Confirm family_member_id naming
  • Team needs from Shoug: Final ALERT schema + data types, Risk scoring rules (short paragraph) for documentation, Query list marked Basic vs Advanced
Yara's Collaboration Points
  • Needs from team: Confirm USER.user_id format (INT vs UUID) with Rose, Confirm agreed status values (e.g., Pending/Confirmed/Cancelled)
  • Team needs from Yara: Final table definitions + data types for CLINIC/APPOINTMENT/AWARENESS_CONTENT, Query list labeled as Basic vs Advanced
Project Notes & Important Points
Important: Zero Blocking Strategy
All work can happen in parallel because each phase is designed to be independent.

• Phase 2: Each member draws their own EER fragment.
• Phase 3: Tables reference only agreed PK names.
• Phase 4: SQL scripts are separate.
• Phase 5: Queries operate on owned tables.

This ensures no one is blocked waiting for others to complete their work.
Individual Contribution Statement
Each member can write: "I independently designed and implemented the [Module Name], including conceptual modeling, relational mapping, SQL implementation, and application-level queries."

This is exactly what instructors want to see - clear individual contributions that demonstrate full understanding of the entire development process from design to implementation.
Required Tools & Software
Database Tools
  • MySQL Database - Primary DBMS for the project, used by all modules
  • MySQL Workbench / phpMyAdmin - Database management tools for SQL implementation
Backend Development
  • Node.js + Express - Backend framework for implementing API endpoints
  • VS Code - Primary code editor for development
  • Postman - API testing tool for backend endpoints
Design & Diagramming
  • Diagrams.net / Lucidchart - For creating EER diagrams in Phase 2
  • dbdiagram.io - Optional tool for visual relational schemas
Documentation
  • Google Docs / Word - For writing schema explanations and documentation
  • SQL files - schema.sql, seed.sql for database scripts