Course: CPT310: Database Systems & Management
Project Type: Relational Database Design & Implementation
Final Project Grade: 87.52%
Project Overview
The Online Food Ordering Database was a cumulative database project developed throughout CPT310. The project followed the database development process, from stakeholder identification and Entity-Relationship modeling through normalization, relational database implementation, data population, trigger implementation, testing, and technical documentation.
For the final project, I created an Online Food Ordering Database using MySQL and phpMyAdmin within a local XAMPP environment. The database was designed to support customer orders, restaurant and menu management, employee management, payment processing, and employee activity auditing.
Database Environment
The final database environment used:
XAMPP Control Pane
MySQL Database Server
phpMyAdmin
CreateDB.sql
PopulateData.sql
Apache and MySQL were run through XAMPP, while phpMyAdmin provided the interface for creating, populating, and verifying the database.
Database Structure
The final implementation contained nine tables:
Together, these tables represented the major data components required for an online food ordering environment.
The database incorporated relational table structures, primary and foreign key relationships, database constraints, and triggers to connect and manage the stored information.
SQL Implementation
Two SQL scripts were created for the final project.
CreateDB.sql
The CreateDB.sql script was designed to recreate the Online Food Ordering Database from scratch. It created the database tables, established primary and foreign key relationships, created the employee audit table, and implemented insert and delete triggers for tracking employee activity.
PopulateData.sql
The PopulateData.sql script populated the database with representative sample records.
The data included customers, restaurants, menu items, employees, departments, orders, order items, and payment information. The sample records were structured to simulate the types of information that could appear within an actual online food ordering system while maintaining the relationships established by the database's foreign keys.
Database Testing & Verification
After creating and populating the database, I performed several verification steps through phpMyAdmin.
I confirmed that the required tables had been generated and then inspected records across the customer, restaurant, menu item, order, payment, and employee tables.
I also tested the employee auditing functionality. Records within tbl_employee_audit demonstrated that employee insert activity was automatically recorded, providing evidence that the implemented trigger functionality was operating as intended.
Technical Documentation
A major component of the final project was the creation of a detailed User Guide.
I documented the complete process for recreating and testing the database, including:
The guide included screenshots of the database environment and resulting records so that another user could follow the documented process and reproduce the implementation.
This portion of the project received a Distinguished rating and full credit from my instructor.
Skills Demonstrated
"You did a solid job overall; however, there are a few important issues to address."
Instructor Miguel Kanto
My instructor, Miguel Kanto, identified both strengths and areas for improvement within the final submission.
The User Guide received a Distinguished rating for its comprehensive instructions for running CreateDB.sql and PopulateData.sql. My written communication and APA formatting also received Distinguished ratings.
The primary areas for improvement involved the completeness and accuracy of the final SQL implementation. The use of AUTO_INCREMENT for primary keys did not align with the specific assignment requirements. Additionally, the final script did not contain the required CREATE VIEW statements.
This feedback highlighted the importance of validating not only whether a database functions, but whether every component of the final implementation satisfies the exact project specification.
Reflection
This project gave me experience working through multiple stages of relational database development rather than focusing on SQL statements in isolation. I worked with database requirements, relationships, normalization, tables, constraints, sample data, triggers, testing, and documentation as parts of one larger system.
One of the strongest lessons I took from the project was the value of reproducibility. Creating a database during development is different from creating scripts and documentation that allow someone else to rebuild that database from scratch.
My User Guide was one of the strongest parts of the project because I documented the implementation visually and provided a structured verification process. The screenshots allowed me to demonstrate that records were successfully populated across multiple tables and that the employee audit functionality generated records as expected.
The instructor feedback also gave me a clearer understanding of where my final validation process could have been stronger. While I successfully demonstrated much of the database functionality, some assignment-specific requirements were missing or incorrectly implemented in the final SQL scripts.
What I Would Do Differently
If I were rebuilding the Online Food Ordering Database today, I would introduce a more rigorous validation process before considering the project complete.
First, I would convert the grading rubric and assignment requirements into a technical checklist. Before submission, I would verify each required table, relationship, constraint, view, trigger, and script against that checklist. This would have helped me identify the missing CREATE VIEW statements before submitting the final implementation.
I would also pay closer attention to assignment-specific implementation requirements. The feedback regarding AUTO_INCREMENT demonstrated that a common database design technique may still be inappropriate when a project's specification requires a different approach.
Finally, I would perform a clean-environment test of the final deliverables. I would start with an empty database environment, execute only CreateDB.sql, execute PopulateData.sql, and then systematically verify every required component against the original project requirements.
This project helped me understand that database quality involves more than whether the system appears to work. Completeness, reproducibility, requirements compliance, and systematic testing are equally important parts of delivering a reliable database implementation.
0 comments