About This Page

This page will be continually updated throughout the DB project. We do our best to not modify our requirements after releasing it. However, sometimes we add clarifications or other changes. We will note them like this:

Details on the DB project coming soon.

Project Overview

This project will use peer feedback and individual deliverables. See the expectations for more on how this works. In particular, the section on Don’t Break the Build is important here.

In this project, we’re going to be building a relatively small database system to model a real-world situation. We are also going to be using some modern software enginering techniques of unit tests, continuous integration, topic branches, merge requests, and modern code review.

This project will be done in iterations. Every week, you will need to do the following:

• Create a topic branch in Git for the current iteration (e.g. db1-dev)
• Create a merge request in GitLab
• Adapt our written test cases to automated unit tests
• Implement or revise the functionality we ask for
• Give feedback to your teammates
• Improve your code and tests between lab day and final merge day
• Merge your code into the master branch
• Tag the commit that you wish to be graded on the master branch (e.g. db1).

Teams

Check your section’s myCourses for your group assignments. Everyone will be given a partner to work with (sometimes a group of three). If you ever shrink to just you, let us know immediately.

Teams have been randomly assigned by the instructor. You will have this team for the entirety of the database project and will be changing teams partway through the semester for other projects.

In the first week, you need to meet with your team and decide who gets which project. We suggest deciding at random, but it’s up to the group.

Iterations

There are multiple deliverables across 4 iterations, including the setup, each of which will be must be tagged in gitlab for grading. See each section for details.

The Project

The scope of this projects will evolve throughout the semester, just like real software. Specifically, what you’ll be delivering is an API as a set of Python methods that interact with a relational database via SQL to do various tasks within this project. Within a typical web system, this is the innermost layer that would be called by your business logic and would usually map closely to an API. Figuring out which API method signatures is where most of your design thinking will go.

We will not be giving you your schema. We will not tell you what your columns should be, how many tables to use, etc. This is intentional. While learning about database as technology, we want you to learn schema design.

Expectation: Clean separation between test and src

In terms of files, anything in the src/ will be deployed to production. Anything in the tests/ folder are just part of development. Therefore, if you have say, a SELECT query that would be used in the real system, then that goes in the src/ folder. Likewise, if you have an INSERT that loads test data, then that logic goes in tests/.

Expectation: Thorough test cases and readable output

You will list the name of the test (use descriptive names), the result of the test, including success/ failure. Format your output so it is easy to read! For example, if you are running a test, then you would output text to the console such as:

>Running test 1 (Create User: Bob)
>Command successful
>Checking if Bob now exists
>Result successful

This is not the exact output you need to follow, but follow the intent of clarity in output logging. This will also help you in debugging! Some tests will require multiple steps to perform. Read the test cases carefully, so you can understand the sequence and dependencies.

Setup

The setup for each project is the same. See DB Project Setup Instructions.

Project: Ride Sharing

See Rideshare Project for details.

Project: Chat System

See Chat Project for details.

Project: Library System

See Library Project for details.