Valerie Dawson

Computer Science Capstone ePortfolio | CS 499

Southern New Hampshire University

Enhancement 3: Databases

Artifact Description

For Enhancement 3, I continued developing the Hospital Management System with a focus on implementing persistent data storage using MongoDB. The artifact originated from earlier coursework but was significantly enhanced through the capstone process. Prior to this enhancement, the system stored all data in memory, meaning patient records, doctor information, appointments, and payroll data were lost when the application closed. This limitation made the system unsuitable for production use.

The artifact was selected because healthcare applications require reliable, persistent data storage with quick retrieval capabilities. Hospitals cannot afford to lose patient information or appointment schedules, making database integration critical for any real-world deployment. This enhancement transformed the system from a demonstration application into a production-viable backend capable of supporting actual hospital operations.

Justification for Inclusion

I selected this artifact for Enhancement 3 because it provided an excellent opportunity to demonstrate comprehensive database design and implementation skills essential in modern software development. The healthcare domain presents unique database challenges that allowed me to showcase multiple competencies:

Persistent Data Storage

Healthcare systems must maintain records indefinitely. By integrating MongoDB, I ensured that all patient histories, appointment records, and employee information persist across application sessions. This addresses one of the most critical requirements in healthcare IT: data permanence and reliability.

NoSQL Database Design

Rather than using traditional relational databases, I selected MongoDB for its flexibility with document-based storage. Healthcare data often includes varying attributes (not all patients have the same medical conditions or insurance types), and MongoDB's schema-less design accommodates this variability naturally. This choice demonstrates understanding of when NoSQL solutions are more appropriate than SQL databases.

Scalability

The MongoDB implementation supports horizontal scaling, allowing the system to grow from a small clinic to a large hospital network without architectural changes. This forward-thinking design reflects professional development practices where systems must accommodate future growth.

Performance Optimization

I implemented indexing strategies on frequently queried fields (doctor specialty, patient last name, appointment dates) to ensure fast data retrieval even as collections grow to thousands of records. Query optimization demonstrates understanding of how database design directly impacts application performance and user experience.

Data Integrity

The repository pattern combined with validation logic ensures data consistency. Each MongoDB collection has validation rules, and the application layer provides additional checks before data persistence. This multi-layered validation prevents data corruption and maintains referential integrity without foreign key constraints.

The enhancement improved the artifact by transforming it from a temporary, demonstration-focused system into a production-ready application with:

Skills Demonstrated

Through this enhancement, I demonstrated proficiency in:

Reflection on the Enhancement Process

Learning and Growth

Implementing MongoDB integration significantly deepened my understanding of database systems and their role in application architecture. Prior to this enhancement, my database experience was primarily academic, completing exercises from simple prompts. This project required me to design a production-quality database system, which presented challenges and learning opportunities beyond classroom exercises.

One of the most valuable lessons was understanding the differences between SQL and NoSQL databases at a practical level. While coursework explained these differences theoretically, experiencing them firsthand taught me when to choose each approach. For the Hospital Management System, MongoDB's flexibility with varying document structures made it ideal. Not all appointments have the same attributes (some are routine checkups, others are surgeries with different requirements), and MongoDB accommodates this naturally without complex table joins.

I also gained deep appreciation for the repository pattern as an abstraction layer. By isolating database operations in repository classes, I made the system database-agnostic at the business logic level. This design decision means that if future requirements demanded switching from MongoDB to PostgreSQL, only the repository implementations would need changing. All business logic would remain intact. This architectural thinking represents a shift from student mindset to professional developer mindset.

The process of designing MongoDB collections taught me to think carefully about data relationships and access patterns. Unlike relational databases where normalization rules guide design, NoSQL requires analyzing how data will be queried and structuring documents accordingly. For example, I initially planned to store doctor specialties in a separate collection but realized that embedding them in doctor documents provided better query performance for the most common use case (searching doctors by specialty).

Challenges Encountered

Challenge 1: Data Persistence and Type Mapping

The first major challenge was correctly mapping Java object types to BSON documents in MongoDB. Initially, date fields were stored as strings, which prevented proper chronological sorting and comparison. Numeric fields sometimes saved as strings, breaking mathematical operations for payroll calculations.

Solution: I researched the MongoDB Java driver documentation thoroughly and implemented explicit type handling:

This experience taught me the importance of understanding how ORMs and database drivers handle type conversions, and to never assume automatic conversions will work correctly.

Challenge 2: Appointment Conflict Detection with Database Queries

With in-memory storage, checking for appointment conflicts was straightforward: iterate through a list. With database storage, I needed to implement efficient queries that retrieved only potentially conflicting appointments rather than loading all appointments into memory.

Solution: I designed a targeted query that:

  1. Filters by doctor ID (only appointments for the specific doctor)
  2. Filters by date range (only appointments on the same day)
  3. Returns minimal data (just start/end times, not full appointment objects)
  4. Uses indexes for fast retrieval

This reduced conflict checking from potentially loading thousands of appointments to retrieving typically 5-20 relevant records. The query optimization demonstrates understanding of how to work with databases efficiently rather than treating them as simple data stores.

Challenge 3: Connection Management and Resource Leaks

Early implementations created new MongoDB connections for each operation, which quickly exhausted available connections and caused application crashes. I also initially forgot to close database cursors, leading to memory leaks during testing with large datasets.

Solution: I implemented the Singleton pattern in the MongoConnection class:

I also added connection testing in the main application startup to fail fast if MongoDB is unavailable, rather than allowing the application to start and then fail on first database operation.

Challenge 4: Data Synchronization Between Repositories

When creating appointments, I needed to ensure referenced doctors and patients existed in their respective collections. Initially, appointments could reference non-existent doctors or patients, causing null pointer exceptions when generating reports.

Solution: I implemented validation logic in the AppointmentScheduler class to verify entities exist before saving appointments. This enforces referential integrity at the application level, compensating for NoSQL's lack of foreign key constraints. The solution demonstrates understanding that data integrity is the developer's responsibility when using NoSQL databases.

Challenge 5: Environment-Specific Configuration

Developing locally with MongoDB required different connection strings than deployment environments. Hardcoding connection strings in the MongoConnection class created problems when moving between environments and posed security risks.

Solution: I externalized configuration:

This approach follows twelve-factor app principles and makes the application deployable to various environments without code changes.

Incorporation of Feedback

Throughout the enhancement process, I incorporated feedback from multiple sources:

Code Review Feedback

Early feedback indicated that my error messages were too technical and wouldn't help end users diagnose problems. I revised error handling to provide:

Performance Testing Feedback

Testing with large datasets revealed that initial query implementations were slow. I addressed this by:

Design Review Feedback

Feedback suggested that my repository interfaces were too specific to MongoDB. I generalized them to be database-agnostic:

This refactoring improved the architecture's flexibility and demonstrated my ability to incorporate feedback to improve design quality.

Meeting Course Outcomes

This enhancement directly addresses multiple course outcomes:

Course Outcome 4: Well-Founded Techniques and Tools

The MongoDB integration demonstrates my ability to use professional database technologies effectively. I applied industry-standard practices including:

These techniques are used in production systems worldwide, showing my readiness to work with professional-grade tools and deliver value through efficient data management.

Course Outcome 5: Security Mindset

Database security was a primary consideration throughout this enhancement:

The security-conscious design demonstrates my ability to anticipate vulnerabilities and implement protective measures proactively.

Course Outcome 3: Design Computing Solutions

The database design reflects careful analysis of the problem domain and algorithmic thinking:

These design decisions show my ability to evaluate computing solutions and manage trade-offs appropriately for the problem context.

Course Outcome 2: Professional Communications

Comprehensive documentation accompanies the database implementation:

The documentation ensures that other developers can understand, maintain, and extend the database layer, which is critical for collaborative development.

Database Architecture

Collections Design

The MongoDB implementation uses four primary collections:

Doctors Collection

{
  "_id": ObjectId,
  "doctorId": String,
  "firstName": String,
  "lastName": String,
  "specialty": String,
  "phone": String,
  "email": String
}

Patients Collection

{
  "_id": ObjectId,
  "patientId": String,
  "firstName": String,
  "lastName": String,
  "dateOfBirth": Date,
  "phone": String,
  "email": String,
  "address": String
}

Appointments Collection

{
  "_id": ObjectId,
  "appointmentId": String,
  "doctorId": String,
  "patientId": String,
  "appointmentDate": Date,
  "startTime": Date,
  "endTime": Date,
  "reason": String,
  "status": String
}

Employees Collection

{
  "_id": ObjectId,
  "employeeId": String,
  "name": String,
  "role": String,
  "hourlyRate": Number,
  "appointmentsCompleted": Number
}

Repository Implementation

Each collection has a dedicated repository class following a consistent pattern. The MongoDoctorRepository implements the DoctorRepository interface using the MongoDB Java driver, keeping database-specific code isolated from business logic.

Tools and Technologies Used

Future Enhancements

Email Confirmation System

A critical next enhancement will be implementing automated email notifications for patient appointments. This feature will:

This enhancement will significantly improve patient communication and reduce administrative overhead by automating a manual process currently handled by front desk staff.

Cloud Migration

While the current implementation uses MongoDB locally (MongoDB Server 8.0) for development and demonstration purposes, the architecture is designed to easily migrate to MongoDB Atlas (cloud-hosted MongoDB) for production deployment. The transition would simply require updating the connection string in the MongoConnection class. Cloud deployment would provide:

This demonstrates forward-thinking design that supports scalability from development to production environments.

Additional Future Enhancements

Conclusion

Enhancement 3 represents a critical transformation of the Hospital Management System from a demonstration application to a production-ready system with persistent, scalable data storage. Through MongoDB integration, I demonstrated mastery of NoSQL database design, connection management, query optimization, and data integrity maintenance. These skills are essential in modern software development.

The challenges encountered and overcome during this enhancement strengthened my understanding of database systems, resource management, and the importance of proper error handling. The repository pattern implementation showcases professional architectural thinking, creating a flexible foundation that supports future enhancements without requiring fundamental restructuring.

Most importantly, this enhancement demonstrates my ability to transform theoretical database knowledge into practical implementation that solves real-world problems. The Hospital Management System now maintains data reliably, queries efficiently, and scales appropriately. These qualities distinguish professional-grade applications from academic exercises. This work positions me to contribute effectively to professional development environments where robust data management is critical to application success.

← Previous: Algorithms View Code Artifacts Watch Code Review