CS 499 Milestone Four
Enhancement Three: Databases
The artifact I selected for this enhancement is my Grazioso Salvare rescue-dog dashboard, originally created in CS 340: Client/Server Development during 2025 C-5 (September - October). The application combines a Python CRUD module, MongoDB, and a Dash interface that allows shelter staff to view animal records, apply Water Rescue, Mountain/Wilderness, and Disaster/Tracking filters, compare outcomes in a pie chart, and display the selected animal on a map. The original project demonstrated how a database-backed application could turn the shelter's rescue criteria into useful information, but it also left several areas where the database layer could be made safer, more reliable, and easier to evaluate.
I selected this artifact because it represents more than storing records in a database. It shows how database design, application logic, and a user-facing dashboard work together to support a real organizational need. For this enhancement, I moved database and dashboard credentials out of the executable source, added environment-based configuration and basic staff authentication, and created MongoDB schema validation for required fields, data types, and valid ranges. I also replaced the original maximum-plus-one record-number approach with an atomic counter and a unique index, which prevents duplicate record numbers when multiple inserts occur close together. These changes strengthened the artifact without replacing MongoDB, rewriting the dashboard, or adding features that were outside the approved scope.
The enhancement also addressed query behavior and database efficiency. I added a compound index using sex_upon_outcome followed by age_upon_outcome_in_weeks because the rescue filters use an exact sex value and an age range. I then used MongoDB explain results instead of assuming that the index improved the query. In the representative test, the original collection scan examined 1,000 documents to return 97 records. After the index was added, MongoDB used an indexed scan and examined 97 keys and 97 documents to return the same 97 records. The case-insensitive breed expression still remains a residual filter, so I documented that limitation rather than claiming the index solves the entire query. Additional improvements included bounded reads, safer projections, explicit invalid-filter behavior, stable table columns, named map fields, and empty-state handling for the table, chart, and map.
The completed enhancement follows the plan I established in Module One and supports the outcomes I expected it to address. Outcome Three is demonstrated through the index design, explain-plan comparison, schema rules, atomic allocation, and the tradeoffs involved in preserving the original breed filtering. Outcome Four is supported through the practical use of Python, PyMongo, MongoDB, Dash, automated testing, and reproducible evidence to improve an existing application. Outcome Five is also a strong part of the enhancement because credentials are no longer stored in the enhanced source, missing configuration fails clearly, dashboard access requires authentication, invalid documents are rejected at the database boundary, and empty update or delete selectors are refused. I do not have any updates to my outcome-coverage plan because the completed work supports Outcomes Three, Four, and Five as intended and complements the first two enhancements in the final ePortfolio.
Working through this enhancement reinforced that database quality depends on more than whether a query returns the expected records. One challenge was deciding where validation should occur. Application checks are still useful, but enforcing important rules in MongoDB provides another boundary when data reaches the collection through a different path. The atomic record counter was another useful improvement because the original approach appeared correct during ordinary single-user testing but could create duplicates under concurrent inserts. The final test suite covered database integration, authentication, invalid records, rescue filters, and concurrent record creation to confirm that the updated design worked reliably.
Visual verification also uncovered a small issue that the earlier automated tests did not reveal. The map callback returned valid content, but the browser layout allowed the map container to collapse to zero width. I corrected the layout and added a regression test before capturing the final dashboard evidence. That experience was a good reminder that database results, automated tests, and the visible application all need to be checked together. Overall, this enhancement better represents my current understanding of database integrity, secure configuration, query evaluation, concurrency, testing, and technical tradeoffs. It belongs in my ePortfolio because it shows how I can take a working database application, identify focused weaknesses, and improve them with measurable evidence while keeping the original purpose and structure recognizable.
MongoDB explain() Evidence
The compound index was measured rather than assumed. Both runs used the same query against the same 1,000-document dataset.
Before index
"stage": "COLLSCAN"
"nReturned": 97
"totalKeysExamined": 0
"totalDocsExamined": 1000
After index
"stage": "IXSCAN"
"indexName": "idx_rescue_sex_age"
"nReturned": 97
"totalKeysExamined": 97
"totalDocsExamined": 97