Preliminary Proposal

Due by the beginning of class on May 27

Page organization

Goals and motivation
What to turn in
Sample description
Sample specification

Goals and motivation

The 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.

Since we don't expect you to read our minds, this is one purpose of the checkpoints - we give you feedback on the project and tell you if you're on track to do well and if not how to get there, without penalizing you for not being able to read our minds.

However, for those who want a bit more of an idea of what's an acceptable project, we offer the following rough guidelines. We expect that each application should eventually have:

At least 5 entities and 5 relationships
The ability to handle multiple classes of users (eg. customers and bank employees)
At least 10 queries that users will be able to ask via the application interface.

As well, you can use the project from a previous term as a guideline for what is complex enough for a sucessful project. You may not model UBC's data (discussed in lecture), employee supervision (discussed in textbook), a book store (project topic in this example), MP3 storage (discussed in class), or project given to you in tutorial. Additionally, this must be a new project - you may not reuse a pre-existing project.

What to turn in

Each group must turn in a hard copy of the following at the beginning of the lecture.

A cover page

Project description: what is the domain, what aspects of the domain will be modeled by the database.

An E/R diagram for the database the application will use. (I suggest using Microsoft Visio or the online Gliffy to draw your ER diagram, but hand drawn diagrams are fine. You may hand those in at the beginning of class if you don't want to scan them in. However, make sure you retain a copy for yourself as we will not be returning them). Your E/R diagram should include:

At least 5 entity sets. For each entity set:
- There will likely be a numeric attribute. This suggestion is designed to help with the discovery of the primary key. However, you may find that some entities do not require it.
- Identify candidate keys, and the primary key. Each entity must have a primary key
At least 5 relationships. For each relationship, identify the cardinality constraint and other constraints, such as participation constraints.

What are the application specifications (i.e., what functionality will the system provide)? Take a look here for some examples.

What platforms do you plan for the final project be on (i.e., Oracle, Java). Note that you are allowed to use any programming language or relational database that you please, as long as you create an application for a relational database, and that you meet all of the other requirements, and you do all programming and query writing yourself (e.g., you can't use a platform that's going to write your SQL for you). At this time, we plan on offering suport for Oracle from the CS machines, along with either JDBC or PHP/web. If, however, you decide to go with anything other than the provided infrastructure (including doing PHP on your own server), you may be required to submit additional information or submit to additional checkpoints. However no support will be available for anything other than the recommended software.

Other, more specific comments if appropriate.

Sample description of the project

As an example, if I were going to turn in a banking proposal, I might submit something like the following for the project description:

The domain that I'm going to model is going to be the banking domain; i.e., the kind of information that is stored about the accounts in one bank.
The aspects of the bank that I will be modelling will be the information relevant to the customer information in the bank. This includes things like the 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 on what stocks are included in the mutual fund and how the fund performed over the past year).
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 accounts and the customer personal information. Only the bank employees will be able to change things like the customers' SIN. Bank employees may reset the customers' account passwords, but may not see them.
This project will be done using the CS department's oracle database and using Java and JDBC. I do not anticipate using any special software or hardware.

Sample specification of the project

In the above banking proposal, I might have the following specification:

Transfer Funds

User: Customer

Input: customer's uid, from-account number, to-account number, amount

Output: "OK" or "Denied"

Basic Case: Check that both accounts belong to the customer. Check that the from-account has sufficient funds to be transferred. Subtract the amount from the from-account and add the amount to the to-account. Return "OK".

Exceptions:

If either one of the accounts don't belong to the customer, transaction is aborted and "Denied" is returned.

If the from-account doesn't have sufficient funds, transaction is aborted and "Denied" is returned.

Check here for more examples of application specifications.