CPSC 304

2019 W2
Project Information

Project Description
Students in teams of 3 are required to select an application that would benefit from a database
and build a database application from start to finish.
Philosophy
Building a full database application from scratch allows you to control the process; instead of
having the pieces decided for you, you must make all of the decisions by yourself. Part of this
process is that you will see how design decisions made at the beginning will affect your final
project. We'll have some practice of some of the skills that you'll need in the tutorial, but this will
allow you to get some more in-depth practice and a feel for what it's like when you make all of
the decisions for an application.
Expectations of Group Members
Each group member must contribute meaningfully to the project. Each group member will be
expected to participate in the demo, be thoroughly familiar with the application, and be able to
answer questions from the TA.
In many cases, group members will share the same project grade; however, the instructors and
TAs reserve the right to change the grade for each participant based on a student's contributions.
For example, students who tend to be unavailable to their team, or who contribute little to the
project, cannot expect to receive a good grade, even if the rest of the group gets a good grade.
Many groups tend to be fine, but if some member(s) of your group aren't carrying their fair share
of the workload, contact your project group's TA as soon as you can. The TA will try to get all
members back on track. Don't wait until late in the project to address these problems! The earlier
you come to us, the more likely it is that we can help you in a meaningful way.
Goals

• Deciding on an application for which a database system would be required

• Modelling the domain of the application, and defining the application functionalities
• Designing and implementing the schema
• Populating the database (this should not be the main focus of the project)
• Writing the code needed to embed the database system in an application that has a
• Creating a Graphical User Interface (GUI).
Focus on the database aspects and the design of the schemas, as opposed to spending extensive
time on sample data and the GUI.
You can use JDBC, PHP, or another platform to connect your implementation to a relational
database management system. Background and setup information can be found at the end of
this document.
Avoid the examples provided in the textbook, course notes, or lectures. Don’t use any examples
that you’ve worked with before. It can’t be something from another course, the Internet, your co-
op term, your friend's work from a previous offering of the course, etc. It must be your team’s
original work. Please be aware of the plagiarism rules for this course. Don't let your teammates
down by copying work. We've had some plagiarism cases (and angry teammates) in the past. Any
instances of academic misconduct will be forwarded to the dean’s office.

Schedule
There are a number of intermediate deadlines that you must meet in order to ensure a successful
project. For every due date below, the deadline is 11:59 pm. Our Advice: Please read the
instructions carefully to make sure that you don't miss anything. Start early; don’t wait for the
few days before the deadline to get started. Ensure that the cover page is turned in with all the
milestones. The template of the cover page is available on Canvas. The project has the following
milestones:

Milestone Due date

Milestone 0 – Group Formation Jan 18
Milestone 1 – Project proposals Jan 24
Milestone 2 – ERD and Schema Feb 7
Milestone 3 - FD and Normalization Feb 28
Milestone 5 – Implementation April 5
Milestone 5 – Demos April 7 - 8

Talking to the TAs

After the “Milestone 0 – Group Formation” phase, you will be assigned a project TA who will act
as your project manager. If you have any questions about how to best proceed with your project,
then your project TA is your first point of contact. Note that your project TA will not pre-grade
anything (i.e., they will not tell you what to put for an answer to achieve a particular grade but
they can point you in the right direction and help clarify expectations). It is recommended that
you go over your milestone with your assigned project TA, and the TA can give you feedback or
answer your questions.
If you are have any concerns with your project TA, please let your instructor know as soon as
possible.
Background Information

Project Platforms

You may use any legal platform that you like, as long as:

• The final application uses a relational database to manage the data.

• You don't use an automated system to generate the code and SQL (we want you to write
these on your own).
• All other requirements are met. Ask, if in doubt.

We are providing support for Oracle from the CS machines, along with either JDBC or
PHP/web. Please note that if you choose to implement with anything other than the provided
and recommended infrastructure (e.g., running PHP on your own server), you may be asked to
submit additional information or additional checkpoints. Furthermore, no support for anything
other than the recommended software will be provided. Note that problems with non-
supported platforms will NOT be accepted as an excuse for late project
submission; use them at your own risk! That said, we've had quite a few good projects
delivered on non-supported platforms.
You can decide on the platform later, but as a preview, you can refer to some project resources
we have here.
Some other resources of interest include:

• UBC CS Department – Sharing Files

https://my.cs.ubc.ca/docs/sharing-files-your-home-directory
• UBC CVS Version Control
https://my.cs.ubc.ca/docs/how-setup-cvs-repository
• UBC SVN Version control
https://my.cs.ubc.ca/docs/how-setup-svn-repository
Milestone 0 (Form a Group)

The term project will be completed in groups of 3. Once you have found a team, click on the
People page (listed in the sidebar) and then the Groups tab. All team members must join the
same group. By default, Canvas loads 10 project groups at a time. If the listed groups are all full,
keep scrolling down the page to force Canvas to fetch the next 10 groups until you find a free
group to join.

FAQs:

• Can our team members be registered in different lecture/tutorial sections?

Yes. However, we suggest that you ensure that there is at least one available timeslot per
week where all members can meet together to work on the project. If you cannot find a
common available time, then we suggest finding other group members.

• I don't know anyone in the course. How can I find a team?

Please use the "Find a teammate" post on Piazza to find a team. You can also talk to
people in your tutorial/lecture sections. Ultimately, it is your responsibility to find a
team.

• Another student (who we do not know) joined our group on Canvas.

Let us know which group you are in and who the unfamiliar student is and we will
remove them for you.

General Pieces of Advice:

Before you commit to being in the same group, we suggest that all team members ensure they
are on the same page regarding:

• The minimum acceptable mark they wish to receive on the project

• How much time you wish to dedicate to this course (it's fine if you say not a lot but you
need to make this clear to your teammates)
• Your working style (e.g., do you like working on things in small chunks throughout the
weeks or do you prefer to start working on it in larger chunks the week before something
is due, etc.).
• How you wish to communicate (e.g., through email, in person, etc.)
Milestone 1 (Project Proposal)

An important goal of the project is to allow you to have the freedom to design your own
application. We want to let you have the freedom to concentrate on some aspects and not on
others. A consequence of this is that we won't be telling you exactly what to do.
We don't expect you to read our minds, so this is one purpose of the checkpoints. We will give
you feedback on the project and tell you if you're on track or not. Here are some rough
guidelines. We expect each project to have:

• At least 7 different entities and 7 relationships.

• A variety of rows of data--at least 10 rows per table, but preferably more. You can use a
script or program to generate thousands of rows if you like.
• A variety of simple and complex queries, including aggregated queries, and joins among
tables. These queries will be part of your application code, that is, you'll perform SQL calls
via an application interface.
• SQL statements to perform inserts, updates (with a WHERE-clause, and deletes (with a
WHERE-clause).

Just a reminder: Don’t use any examples that you’ve worked with before. For example, it can’t
be something from another course, the Internet, previous students' work, your co-op term,
etc. It must be your team’s original work.
Some projects that you may not use are:

• Any data that has been used in previous CPSC 304 classes or the textbook including, but not
limited to:
o Employee supervision (projects, managers, employees)
o A bookstore (provided as an example)
o MP3 storage (used in some previous classes)
o A school setting (students, instructors, departments, courses, etc.) -- we're going to use
this as a case study in various parts of the course
o Banking (accounts, customers)
o Airlines (flights, planes, passengers, destinations)
o Retail sales (customers, products, orders, line orders) -- instead focus on other aspects of
retail, like maybe inventory tracking, shipping, etc.
• Any projects given to you in a tutorial
• Any pre-existing project

If you are unsure, ask!

Project Platforms

Refer back to the beginning of this section for some ideas about RDBMSs (Oracle, MySQL,
Postgres, etc.) and programming languages (Java/JDBC, PHP, C++, Python, etc.) Your group
may use any legal platform that you like, as long as:

• The final application uses an RDBMS

• All other requirements are met
Deliverables
What to Turn In

All of the following items must be put together into a single PDF file. There is a docx and pdf
version of the template available on Canvas. If you are unsure about how to incorporate the
cover page into your milestone, please see your TA before the assignment due date. You need
to provide:

1. A completed cover page

2. A brief (half-page or paragraph) project description answering these questions:
o What is the domain of the application? Describe it.
o What aspects of the domain are modeled by the database?
3. Database specifications:
o What benefit does the database provide to the application?
o What functionality will the database provide?
4. Description of the application platform:
o What platform will the final project be on?
o What is your application technology stack?
5. Other comments, as appropriate, to explain your project

Sample Submission
As an example, if my group were going to turn in a banking proposal, we would submit a cover
page and something like:
“The domain that we're going to model is banking. That is, we're going to focus on the data
that is stored about accounts in a bank.
The aspects of the bank that we will be modeling will be about customers of the bank. This
includes things like the accounts that a given customer has, information specific to the
customer (e.g., the customer's name and address), and the customer's credit cards. There will
be a number of different kinds of accounts, and some of these accounts will have additional
information to let customers know if that account is right for them (e.g., a mutual fund account
will contain information about what stocks are included in the mutual fund and how the fund
performed over the past few years).
There will be two different classes of users of the system: the customers, and the bank
employees. The customers will be able to access their own accounts, and transfer money from
one account to another. They will also be able to update some of their personal information,
like their bank account password. The bank employees will be able to access all of the
customers' data - both the customer's accounts and the customer's personal information. Only
the bank employees will be able to change things like a customers' social insurance number.
Bank employees may reset a customer's account password, but may not see the password.
This project will be done using the CPSC department's Oracle database system, using Java and
JDBC. We do not anticipate using any special software or hardware.”

Rubric : Check the Milestone 1 assignment on Canvas

Milestone 2 (ERD , Schema and Normalization)

The aim is to do modelling using ER diagram and Schema for your database. While working, you
may go through several refinements but, you must only submit the final version. Each group must
provide the following:
1. A cover page

2. An E/R diagram for the database the application will use. It is OK to hand-draw it, or to
use software to draw your diagram (e.g., draw.io, GoogleDraw, Microsoft Visio, Gliffy,
maybe Word, etc.) The result should be a legible PDF or PNG document. Note that
your ER diagram must use the conventions we have discussed in class (e.g., no crow’s
feet notation). If your chosen platform does not support the conventions we discussed in
class, you must find another platform to use.

Your E/R diagram should include:

• At least 7 different entity sets excluding weak entities and ISAs.

• At least one weak entity
• At least one ISA relationship
• At least 7 different relationships. For each relationship, identify the cardinality
constraint and other constraints, such as participation constraints.
• All entities must have their keys clearly identified.

3. The schema-derived by translating from your ER diagram (above). For the translation
of the ER diagram to the relational model, follow the same instructions as for
your lectures. The process should be reasonably straightforward. For each table:

• List the table definition e.g., Table1(attr1: domain1, attr2: domain2...)

• Specify the primary key, candidate key, foreign keys, and other constraints that the
table must maintain.

Rubric : Check the Milestone 2 assignment on Canvas

Milestone 3 (FD and Normalization)

Each group must provide the following:

1. A cover page

2. Functional Dependencies (FDs)

o Identify the functional dependencies in your relations, including the ones involving
the primary keys.
o List all candidate keys.

Note: In your list of FDs, there must be some kind of valid FD other than the primary key
(PK) and candidate key (CK) in at least two relations. If you observe that no relations
have FDs other than the PK and CK(s), then you will have to intentionally add some
attributes to show valid FDs. Your schema must go through the normalization process.

3. Normalization
o Normalize each of your tables, if necessary, to be in 3NF or BCNF. Give the list of tables,
their primary keys, and foreign keys after normalization.

4. The SQL DDL to create all the tables in SQL. All primary keys and foreign keys must be
declared appropriately. Code the SQL CREATE TABLE statements with the appropriate
foreign keys, primary keys, UNIQUE constraint, etc.

5. Populate each table with at least 5 tuples. Show the instance of each relation after inserting
the tuples.

Please Note: As you start analyzing these requirements, you may notice that certain details are
missing. In this case, you may make any reasonable assumptions about them; but, if there is any
uncertainty about some requirements, you should ask your project TA before proceeding further
(or if it's more general in nature, post your question to Piazza). Furthermore, it is acceptable to
modify your design from your original project proposal, because as you progress and start
thinking more about the data and the queries that you want to answer from your application, it
is normal to find that you may need to modify the design (but don't go back and re-do or re-
submit your project proposal).

All deliverables should be in PDF format.

Rubric : Check the Milestone 3 assignment on Canvas
Milestone 4 - Implementation

The goal of this milestone is to build on what you have accomplished in the other project
checkpoints. This document will show both what you are expected to turn in, and what
functionality you should have for your project to be successful. Another goal of this project
milestone is for you to tell us what to expect at your demo.
Graphical User Interfaces (GUIs) normally require a lot of time and multiple tries to get them
right. We expect you to produce a simple but adequate interface; but it doesn't have to be
fancy. You should not spend a lot of time on the interface itself. You should concentrate on the
coding of the functionality of your project rather than the GUI. The goal of the project is to give
you some experience with SQL and JDBC or PHP. We’re more concerned with the application
programming (interfacing with a DBMS), SQL DDL, SQL DML, business requirements, design,
working effectively as a group, etc. What we are looking for here is a series of buttons where each
button will run a query. I.e., we do not want this to just be a text based user interface.
Note that while you can see what we expect you to show us at the demo in the notes below, it is
not enough to hard code the application to just run that set of specific queries - we will be looking
at your files as well to show that you've implemented the whole application that you have said that
you have. We also expect that you write queries that give you the data required without any
extraneous information. I.e., we do not want you to have your application parse through query
results. Databases are designed to be efficient at processing queries and fetching information.
Having the client fetch and process extra tuples is an unnecessary waste of time and resources.
You will hand in all your work on the project including your codebase and sample screenshots
that demonstrate the functionality of your application. We will freeze the deliverables at this point
so that groups that demo later than others do not gain an advantage. You should provide some
screenshots and sample output of your work to give your project TA a heads-up about your
upcoming demo. What you've uploaded to Canvas will be the frozen application and final
product. You cannot change it between the time that it is due and your demo.
Your group needs to submit these things:

1. Your cover page, as usual. (Important.)

2. All the code used in the application.
If your codebase is too large to submit on Canvas, submit a link to your repository. For
private repositories, ensure that sharing permissions are given your project TA and
instructor. You can find their emails in the “Contact Information” page on Canvas.
3. A single script that can be used to create all the tables and data in the database.
4. A PDF file containing:
o A short description of the final project, and what it accomplished
o A description of how your final schema differed from the schema you turned in.
§ If the final schema differed, why?
§ Note that turning in a final schema that's different from what you planned is fine, we
just want to know what changed and why.
5. A list of all SQL queries used. For SQL query requirements, check the rubric listed in
milestone 5.
6. Screenshots of the sample output of the queries
7. Lastly, include a README.txt file if there’s anything you want to add that’s not included in
your PDF file.
Group members: Verify with your group that the submission has actually taken place and
that it’s on time.

No late submissions will be accepted.

Rubric : Check the Milestone 4 assignment on Canvas.

Milestone 5 - Demo
Project Demo Protocol (Tentative)

1) Each TA books half-hour slots; we'll aim for a demo of 20-25 minutes. The extra 5 minutes
can be used as turnaround time for the next group to get settled after the current group
clears out.
• Your project TA will give you a spreadsheet or poll to allow you to sign up for a demo
time. Scheduling is a really hard problem so, groups will have to be accommodating.
In the case where you cannot find an available time to meet with your project TA,
another TA will grade your demo.

2) The next group should be ready to go before meeting with the TA; otherwise, it cuts into the
demo time. In other words, students should not use the first part of the demo to boot their
laptop and go searching for all the files they plan to use. It will help to have the SQL scripts
available to DROP, CREATE, INSERT rows, etc.

3) Right away, the TA will ask the group if anything listed in their formal specs (list of
deliverables) does NOT work. This will save a bunch of demo time, and it will help the TA
with marking the Canvas-submitted deliverables.

4) Before starting on the checklist, the TA will ask students to show that their code has not been
changed since submission on Canvas. They can ask students to re-compile the code, re-pull
from their repository or show file timestamps. They should create and populate the tables.

5) The group shows the TA that everything is working (or whatever they've got done). The TA
sees that the system is working by viewing the interface, the user's input (or selection from a
list of features/queries), and the output that gets nicely displayed. In the case of an INSERT,
UPDATE, or DELETE, the TA sees the “before” state of the table (students can use their
program, or SQL*Plus or equivalent, to display it) and the “after” state, etc.

• It may be helpful for the project groups to provide a copy of the schema and sample
data in the tables, so that the TA can verify that the queries are producing the right
output, and what to expect from any UPDATE or DELETE operation.

• Tip to Project Groups: Imagine that you are taking a road test for a driver’s licence.
The TA will ask you to walk through one query at a time, type in query inputs (if
appropriate), and check the relation instance to see if the right behaviour is observed.
The TA can ask the students to use SQL*Plus (or equivalent) to show the relation
instance. Students do not do not need to implement any “print” function in their
application.

6) Students should take the lead in the demo by showing the things that are required by our
demo checklist (see the big table below). So, it will be a “mixed” type of approach. The
group can show all the queries, etc., and the TAs can ask questions and have them modify
something, and rerun, etc.
7) The TA can ask the group one or two technical questions. Questions might be: How would
you go about changing “this” to “that”? In other words, how would you go through the steps
from edit to compile to output ... in order to implement a particular change like a new query,
a query with more/fewer fields of output, etc.? The group can describe it in words. It may
be too time-consuming and pressure-packed to have students do changes on the fly, and it
might mess up part of their demo, if it’s not asked at the end.

8) The demo will probably be marked out of a number like 12, but we won’t give the grade out
on the spot. The TAs will need to reflect upon the presentation afterwards after:
• Checking and reflecting upon their own notes
• Comparing the differences between the demo and the actual deliverables handed in
to Canvas
• Comparing the differences between the demo and the formal specifications
• Deciding whether some groups were asked harder/easier questions
• Consulting the other TAs and instructors when comparing different groups’ demos
and deliverables, when it comes to bonus marks
• etc.

9) We’re offering a small number of bonus marks; our standards are high for this.
Group won’t automatically get the bonus. The maximum bonus is 2 points.
• Having a really fancy GUI is worth 1 point.
• Implementing and demonstrating useful triggers is worth 1 point (unless the
implementation is trivial).
• Having some “wow” type of feature in their application is worth 1 point.
• TAs will discuss the bonus points with other TAs and instructors to see whether the
bonus should apply to a given situation.

Any bonus mark(s) earned will be added to the final project total. For example, let’s assume
that the project is out of 85. If you end up scoring 83/85 on the project and earn 1 bonus
point, your final project total will be 84/85.

In the event that you achieve full marks on all project milestones and also earn bonus points,
we will calculate your final course grade by allowing you to score over the allotted project
percentage. That is, the project is worth 20% of your final course grade. Let’s assume that
you have earned 2 bonus marks. When we calculate your final grade, we will use 87/85*20
when calculating your score for the project.
Here is a tentative marking scheme (we may still adjust it, but we’ll probably keep it in the
12 mark range), and it gives you an idea of approximately what we’re after. The TAs won’t tell
you ahead of time whether a given feature is “correct” or is worth a mark; so, please don’t ask.
The groups can change the order of the items below because in some cases the SELECT,
INSERT, UPDATE, DELETE, aggregation, view, etc. may depend on some other SQL
statements.

Component Number
of
Points
GUI :. GUI doesn’t need to be fancy (buttons to run a query is adequate). Really fancy 1
GUIs can be awarded a bonus point (see below).

Same Deliverables as Handed In? : The group shows the TA that the deliverables 0.5
haven’t changed from what they handed in (e.g., timestamps).

Insert Operation: Provide an interface for the user to specify some input for the 1
insert operation.
Delete Operation : Implement a cascade-on-delete situation. Provide an interface 1
for the user to specify some input for the deletion operation. Based on input, deletion
should be performed.
Update Operation: Provide an interface for the user to specify some input for the 1
update operation.
Selection - Create one query of this category and provide an interface for the user to 1
specify the selection conditions to be returned. Example:
SELECT Field_01
FROM Table_01
WHERE Field_02 >= 0
Projection - Create one query of this category and provide an interface for the user to 1
specify the projection conditions to be returned.
Example:
SELECT Field_01
FROM Table_01
Join Query : Pick one query of this category, which joins at least two tables and 1
performs a meaningful query, and provide an interface for the user to choose this query
(e.g. join the Customers and the Transactions table to find the phone numbers of all
customers who has purchased a specific item).
Aggregation query: Pick one queries that require the use of distinct aggregation 1
(min, max, average, or count are all fine).
Nested aggregation with group-by: Pick one query that finds some aggregated 1.5
value for each group (e.g. the average number of items purchased per customer).
Division query: Pick one query of this category and provide an interface for the user 2
to choose this query (e.g. find all the customers who bought all the items).
Unofficial GROUP MARK
___ / 12

Bonus Marks : Create unique features for your application that clearly go over and
above what was expected. Some examples include a really fancy GUI, implementing
useful trigger(s) and having application logic that deals with it, produces special
reports, has a “wow” factor, etc.

Keep in mind these bonus points have a HIGH standard to meet. Not all groups will
get bonus marks; possibly only a few will get 2 bonus marks (one for each feature).

Unofficial BONUS MARK

___ / 2