Praxis Cafe

Expectation: Based on a real-world business problem, create an application using a SQL database and another higher-level language (such as: python, C#, or java). The database must have 5 tables that connect in some way.

Duration: ~2.5 months (2 weeks of coding)

Team Size: 5

Roles:

• Project manager
• Lead SQL developer

Programs Used:

• Google Docs and Slides
• Lucidchart
• SQL Postgres
• Python Tkinter on VScode editor

This project was developed for UWB’s CSS 475 Database Systems course. I took this course as a free elective because I thought the knowledge of manipulating and creating databases could become useful in the future.

I developed this business problem from my time working in a local bakery, and proposed it to my team to be the problem we solved for the assignment.

Problem:

The problem at our restaurant is that our employees have to work in two systems when they could be working in one. Currently, one system is the register where employees input the customer’s order and take their payment information. The second system is where the employees need to manually input all of the orders for the day (again) so that management can look back and see how the sales were.

What’s Wanted:

Management would like to see the sales per day, and what platform the sales were made in (walkin, phone order or externally from food ordering services), but currently they can only see the orders made (not by the means or time).

Solution:

Turning the two system model into one database would make the cafe more efficient and save employees more time at the end of the day. Ultimately, our solution is to create a new system that combines the disconnected systems into one.

We will provide a GUI application for an easier interface for employees to use, which will enable us to take real time orders from customers. We will be able to connect the sales items table to the register system so that employees can keep track of order details.

For the visuals we decided to use the provided assets from Python Tkinter to alleviate some stress from the time crunch and current learning curve the team was working against.

This is the databases’ final structural design. It was built by the whole team. To make sure the design was up to par, I took the design to the teacher to discuss any errors, as well as discuss how to make it better and relayed the information to the team to discuss and make the changes together.

If there was more time the team and I discussed making these extra developments:

• Allow users to update completed orders in the application. Currently we put in a safety measure to ask the employee to confirm the order to make sure there are no mistakes.
• Have different levels of employee access. By allowing managers to have more access than regular café workers when running queries.
• Order statuses. Say if an order is completed or canceled.
• Allow for more complicated queries to be done in the application. Such as searching by specific dates and items or employee.

• When presenting CS related content, it is not necessary to relay all of the structural details to the audience. Even though there may be important key notes when building, the proper functionality matters more to the stakeholders.
• When on a time crunch it is important to divide up the responsibilities to each of the team members’ strengths. As well as check in to make sure that there is constant communication so that you can help fix any errors that may have developed.
• When fixing a project, it is okay to not have the whole team with you when receiving feedback. There were many times when I went to the professor alone to understand the mistakes we made. I took notes and relayed the information to the team on how we could proceed to fix the program.