Guidelines for the class project

Here are some guidelines that should help you make project decisions. Of the following, the first four guidelines are the most important.

Team: Choose your project team (minimum four people) very, very carefully. When choosing partners, you should look at the obvious factors: preferred database system, programming environment, applications, etc. However, please also take the time to make sure that your goals, style of working, target grade, etc., also match those of your partners. The early programming homeworks should provide some help in allowing you to judge the abilities of your potential partners. Do not be shy in interviewing them! Every semester, I stress the importance of picking your team carefully, and every semester there are at least a couple of groups that are probably best described as dysfunctional, so let me repeat: Choose your project team very, very carefully! I give you full freedom to choose the classmates with whom you'd like to work. On the flip side, I will absolutely not serve as an arbiter of any group disputes that arise, short of those involving academic dishonesty. I am also asked every semester if it is OK to work in a smaller group. The answer is no. While I know that many students may be more productive working in groups of two or even alone, a major objective of the course is to make sure students know how to work in a group.

Effective use: Try to make effective use of as much of the course material as possible. As we progress through this course, try to incorporate what we learn into your projects. For example, use joins, aggregates, cursors, different transaction isolation levels, indexes, etc. While it is certainly not necessary that your project use each and every topic covered in class, in most nontrivial applications one can find use for most of these topics. If you have trouble figuring out how some topic is applicable to your project, stop by during office hours.

Completeness: The project must be complete and stable enough for a good demonstration at the end of the course. This requirement is very important. If you are unable to give a reasonable demonstration, your project grade will suffer greatly. I cannot stress this point enough. A demonstration in which only five simple tasks work is far better than one in which nothing works but there are many complex and fascinating tasks that "almost work." When planning your work, make sure you get the simple stuff working before tackling more ambitious tasks.

Database size: All project databases must be of nontrivial size. You may interpret nontrivial based on your application. However, (1) there should be at least 10 nontrivial relations; and (2) the total number of attributes times the total number of tuples should be at least 5000. (These are guidelines only; if you feel your application warrants exceptions, come see me during office hours.)

Practicality: The application you build should be of practical use to a sizeable community (at least in the forseeable future).

Innovation: The more innovative ideas you include in your project, the more credit you will receive. It is perfectly OK to build "yet another or" but if you include some innovative ideas, you'll get more credit.

Miscellany: In addition to the above, your project grade will take into account factors such as teamwork, overall effort, timeliness, answers to questions about the project, justification of design decisions, and intermediate and final project reports.

Code release: You are strongly encouraged to release your project code under an open source license (such as GNU GPL). However, your grade will NOT depend on your choice in this regard. (That is, you are not required to release your code and the decision is completely up to you.)

Sudarshan S. Chawathe